History of Ghostscript versions 9.n

Contact Us
Download
History of Ghostscript Versions 9.xx

## Table of contents

> - Version 9.52 (2020-03-19)
> - Version 9.50 (2019-10-15)
> - Version 9.27 (2019-04-03)
> - Version 9.26 (2018-11-20)
> - Version 9.25 (2018-09-13)
> - Version 9.24 (2018-09-03)
> - Version 9.23 (2018-03-21)
> - Version 9.22 (2017-10-04)
> - Version 9.21 (2017-03-16)
> - Version 9.20 (2016-09-26)
> - Version 9.19 (2016-03-23)
> - Version 9.18 (2015-09-23)
> - Version 9.16 (2015-03-30)
> - Version 9.15 (2014-09-22)
> - Version 9.14 (2014-03-26)
> - Version 9.10 (2013-08-27)
> - Version 9.09 (2013-08-21)
> - Version 9.07 (2013-02-14)
> - Version 9.06 (2012-07-31)
> - Version 9.05 (2012-02-08)
> - Version 9.04 (2011-08-05)
> - Version 9.02 (2011-03-30)
> - Version 9.01 (2011-02-07)
> - Version 9.00 (2010-09-14)

This document is a record of changes in Ghostscript releases numbered 9.xx. For earlier versions, see the the history documents:

> History of Ghostscript versions 8.n
> History of Ghostscript versions 7.n
> History of Ghostscript versions 6.n
> History of Ghostscript versions 5.n
> History of Ghostscript versions 4.n
> History of Ghostscript versions 3.n
> History of Ghostscript versions 2.n
> History of Ghostscript versions 1.n

For other information, see the Ghostscript overview.

## Version 9.52 (2020-03-19)

Highlights in this release include:

- The 9.52 release replaces the 9.51 release, after a problem was reported with 9.51 which warranted the quick turnaround. Thus, like 9.51, 9.52 is primarily a maintenance release, consolidating the changes we introduced in 9.50.

- We have continued our work on code hygiene for this release, with a focus on the static analysis tool Coverity (from Synopsys, Inc) and we have now adopted a policy of maintaining zero Coverity issues in the Ghostscript/GhostPDL source base.

- IMPORTANT: In consultation with a representative of (OpenPrinting) it is our intention to deprecate and, in the not distant future, remove the OpenPrinting Vector/Raster Printer Drivers (that is, the `opvp` and `oprp` devices).

  If you rely on either of these devices, please get in touch with us, so we can discuss your use case, and revise our plans accordingly.

- IMPORTANT: We have forked LittleCMS2 into LittleCMS2mt (the "mt" indicating "multi-thread"). LCMS2 is not thread safe, and cannot be made thread safe without breaking the ABI. Our fork will be thread safe, and include performance enhancements (these changes have all be been offered and rejected upstream). We will maintain compatibility between Ghostscript and LCMS2 for a time, but not in perpetuity. If there is sufficient interest, our fork will be available as its own package separately from Ghostscript (and MuPDF).

- The usual round of bug fixes, compatibility changes, and incremental improvements.

For a list of open issues, or to report problems, please visit bugs.ghostscript.com.

### Incompatible changes

#### Included below are incompatible changes from recent releases (the specific release in question listed in parentheses). We include these, for now, as we are aware that not everyone upgrades with every release.

- (9.52) As of 9.52, the Windows binaries released by the Ghostscript development team are built with Microsoft Visual Studio 2019. As a result Microsoft Windows XP and earlier are no longer supported by these binaries. This does not imply we are, or will start relying upon features only available in VS2019, so the `nmake` Makefiles will continue to allow older Visual Studio versions (back to VS2005) to build Ghostscript.

- (9.52) `-dALLOWPSTRANSPARENCY`: The transparency compositor (and related features), whilst we are improving it, remains sensitive to being driven correctly, and incorrect use can have unexpected/undefined results. Hence, as part of improving security we limited access to these operators, originally using the `-dSAFER` feature. As we made "SAFER" the default mode, that became unacceptable, hence the new option `-dALLOWPSTRANSPARENCY` which enables access to the operators.

- (9.50) There are a couple of subtle incompatibilities between the old and new SAFER implementations. Firstly, as mentioned in the 9.50 release notes, SAFER now leaves standard Postcript functionality unchanged (except for the file access limitations). Secondly, the interaction with `save`/`restore` operations, see SAFER.

  Important Note for Windows Users:
  The file/path pattern matching is case sensitive, even on Windows. This is a change in behaviour compared to the old code which, on Windows, was case insensitive. This is in recognition of changes in Windows behaviour, in that it now supports (although does not enforce) case sensitivity.

- (9.27) The process of "tidying" the Postscript name space should have removed only non-standard and undocumented operators. Nevertheless, it is possible that any integrations or utilities that rely on those non-standard and undocumented operators may stop working, or may change behaviour.

  If you encounter such a case, please contact us (either the #ghostscript IRC channel, or the gs-devel mailing list would be best), and we'll work with you to either find an alternative solution or return the previous functionality, if there is genuinely no other option.

  One case we know this has occurred is GSView 5 (and earlier). GSView 5 support for PDF files relied upon internal use only features which are no longer available. GSView 5 will still work as previously for Postscript files. For PDF files, users are encouraged to look at MuPDF.

### Changelog

2020-03-14 15:07:37 +0000
Chris Liddell <chris.liddell@artifex.com>
eec073529fb8dc0c3bb6d612b61bf483d135c9cf

> Bug 702217: Reinstate dynamic libs LDFLAGS for MacOS
> With the significant revamp of the platform detection functions in configure
> the LDFLAGS for building the gs shared library on MacOS went astray. This
> puts them back in.
> configure.ac

2020-03-16 09:06:16 +0000
Ken Sharp <ken.sharp@artifex.com>
a9cd9959372b9f14b493b87df57664ea831c5d80

> Repair device subclassing after fill+stroke commit
> Bug 702221 "Ghostscript 9.51 - SIGFPE when -dFirstPage or -dLastPage is set"
> The fill+stroke commit had an error with the default method for handling
> fill_stroke_path which passed the subclassing device as a parameter to
> the child, instead of passing the child device. This caused seg faults,
> floating point exceptions, hangs, and possibly other problems.
> In addition the object filtering device had been modified to pass the
> fill+stroke method to the default handler, instead of checking to see
> if vector operations should be dropped.
> This commit fixes both problems.
> base/gdevoflt.c
> base/gdevsclass.c

2020-03-14 10:56:43 +0000
Chris Liddell <chris.liddell@artifex.com>
f712440a2f251ae06277ec4a5ffe8ce7599aa4d8

> Add ARCH_MAX_SIZE_T to configure's arch.h prototype
> arch/arch_autoconf.h.in

2020-03-14 10:53:15 +0000
Chris Liddell <chris.liddell@artifex.com>
214d16924543fb3116a031463052e8b0eff3f1ae

> Don't fail on missing freetype for auxtools run
> When cross compiling, we shouldn't fail the recursive call to configure if
> there's no freetype - since it's not required for auxtools.
> configure.ac

2020-03-02 17:10:43 +0000
Robin Watts <Robin.Watts@artifex.com>
15f5f8bad503e9d3e63db9c3ca395deffd6b1e20

> Fix 16bit blending problem.
> Seen with:
> gs -sDEVICE=psdcmyk16 -o out%d.psd -r72 -dMaxBitmap=2000M
> tests_private/pdf/forms/v1.5/proxy_vol_1_number_1_1.pdf
> on page 3.
> base/gxblend.c

2020-03-02 11:04:32 +0000
Robin Watts <Robin.Watts@artifex.com>
f6e3e9238bb5cf7fe44c3c845be286a3314ed905

> Fix 64bit non-console windows build.
> The creation of the text window was truncating the pointer to
> long (32bit) size. No idea how we've been getting away with this
> in the past. I can only assume this has been exposed by
> differences in the runtime lib with vs2019 as compared to
> earlier versions.
> psi/dwtext.c

2020-03-02 09:02:51 +0000
Chris Liddell <chris.liddell@artifex.com>
ffe0e5cf33feee7672e5f4281f0c0b0ff66bddda

> Add mention of deprecating/removing opvp/oprp devices
> doc/History9.htm
> doc/News.htm

2020-02-26 15:22:04 +0000
Robin Watts <Robin.Watts@artifex.com>
dbaddcf6e251229a1506f2df33844365df39de44

> Fix signed issue in 16bit alpha blending fill_rectangle routines.
> As seen by the central spot in the pink region of page 1 of:
> gs -sDEVICE=psdcmyk16 -o out%d.psd -dMaxBitmap=2000M
> tests_private/pdf/pdf_1.7_ATS_EXXPA1DC_PDFACT.pdf
> base/gxblend.c

2020-02-26 15:09:35 +0000
Ken Sharp <ken.sharp@artifex.com>
4ad8020c3cb63345dd76119e8978c3353940a68e

> pdfwrite - Fix indeterminism with QL shading tests
> When creating a new colour space to put in a PDF file we perform various
> tests to see if its a space we have already written, to prevent writing
> duplicate spaces (we perform similar tests for most resources).
> In some cases, when we write the resource to a file, we create an MD5
> hash and compare those to see if the resources are the same. In the
> case of colour spaces, however, they are retained in memory and so we
> use a different method. We 'serialise' the colour space. This is not the
> same as writing it to the PDF file, and its a graphics library thing not
> a pdfwrite function. Basically this writes out the content of the
> various C structures. The stream we use is an in-memory stream.
> Unfortunately, for Separation colour spaces, there was a fault in the
> function which writes the colour space name, and it was writing out
> the bytes forming the address of the name instead of the actual string.
> This could, very rarely, mean that we would mis-identify a new colour
> space as being the same as an old colour space, and so would reuse the
> old space instead of creating a new one.
> I've checked the DeviceN code and it does not suffer the same problem.
> base/gscsepr.c

2020-02-26 13:03:56 +0000
Robin Watts <Robin.Watts@artifex.com>
3cb8b3a403450d617b2b96ec0349bb99ce0d8379

> Fix the overflow case in 16 bit saturation blending.
> As seen with the second apple of the bottom row of page 1
> of:
> gs -sDEVICE=psdcmyk16 -r72 -o out%d.psd -dMaxBitmap=2000M
> ../tests_private/pdf/PDF_1.7_ATS/AIX4G1C3.pdf
> base/gxblend.c

2020-02-25 17:10:51 +0000
Julian Smith <jules@op59.net>
5d4305e916d3f75492d03dfd79ab1aaedf9545e3

> Fix for bug 702150: make pl_main_run_file_utf8() check for error from s_process_read_buf().
> Avoids infinite loop in:
> ./membin/gpcl6 -sDEVICE=ppmraw -o /dev/null .
> pcl/pl/plmain.c

2020-02-25 18:24:55 +0000
Julian Smith <jules@op59.net>
2c6efee0f594ad29394bf8a303f21d85dcb1d70a

> minor improvements to toolbin/squeeze2text.py.
> toolbin/squeeze2text.py

2020-02-26 08:25:13 +0000
Robin Watts <Robin.Watts@artifex.com>
ef5dfe7e3b3858bdfb20c168b4818c4d65fb932f

> CID 354310: Remove pointless unsigned comparison with 0.
> base/gxblend.c

2020-02-26 08:11:49 +0000
Chris Liddell <chris.liddell@artifex.com>
29335f43967a0f089d6f2f37883a22f1516f7bde

> CID 354291: Add error handling for inability to allocate
> Coverity complained about setting dash.pattern = NULL and "Passing "&dash"
> to "gstate_copy_dash", which dereferences null "dash.pattern" which is either
> wrong, or *very* misleading. We assume that it means that gx_set_dash() *may*
> access that pointer.
> In truth, this can never happen in these circumstances.
> Nevertheless, in gx_set_dash() is we have a NULL mem (allocator) pointer and the
> dash pattern pointer is NULL at the point we have to copy into it, then throw
> an error.
> base/gsline.c

2020-02-25 19:59:03 -0800
Ray Johnston <ray.johnston@artifex.com>
1d0889b9fcf3a5d5012fad021b4c53828879016e

> Fix bug 702139 - clist clipping bug.
> When characters are filled as paths, the fill_adjust may be set to 0.
> Clip paths are supposed to match fill paths, i.e. the 'any part of pixel'
> rule, so we need fill_adjust of 0.5 (not 0). The most foolproof way to fix
> this is to set it in the reader when processing 'begin_clip' and restore
> it when handling the end_clip.
> There are many progressions with this change, but it also exposes some
> cases where the change in clipping allows other elements to be seen that
> were previously hidden. Those few instances are minor and mostly seem to
> occur when page mode differs from clist mode. Examination of some of those
> cases shows that the clip path with clist mode now matches page mode and
> other elements (e.g. images) differ in extent between page and clist mode.
> base/gxclrast.c

2020-02-25 19:39:50 +0000
Robin Watts <Robin.Watts@artifex.com>
86f81e9b799b66207c699768616a6e3ba3c311c3

> Fix gx_default_copy_alpha_hl_color for 16 bit operation.
> The code to write the composite data back to buffers to be sent
> to copy_alpha was getting the first byte of each 16 bit pair
> wrong in the 16bit data case.
> Also, when we 'restart' after skipping a zero byte in the 16bit
> case we need to skip 2 bytes per pixel, not one.
> This can be seen when running:
> gs -r72 -o out%d.psd -sDEVICE=psdcmyk16 -dMaxBitmap=2000M
> ../tests_private/comparefiles/js.pdf
> base/gdevdbit.c

2020-02-25 18:19:07 +0000
Robin Watts <Robin.Watts@artifex.com>
635303ca7d8a36b3dabc9afbd9132f4b9a36dce5

> Fix psdcmyk16 blending issue.
> Use uint32_t rather than int to avoid signedness issues.
> Seen in the psdcmyk16 page mode rendering of
> tests_private/comparefiles/Bug692766.pdf
> (bad colors in 4th rgb circle intersection test).
> base/gxblend.c

2020-02-25 15:57:36 +0000
Robin Watts <Robin.Watts@artifex.com>
a00c75369e082798d82202a2b64d8e4b484d0c11

> Fix coverity issues 354292 and 354293.
> Don't bother testing an unsigned value for clipping against 0.
> base/gxblend.c

2020-02-25 08:58:32 +0000
Chris Liddell <chris.liddell@artifex.com>
32f3d6703a7e5c6582c066837783c6697e98b1ca

> Replace 0 with NULL for pointer validation/setting.
> Also make validation an explicit comparison with NULL i.e.:
> "if (mem != NULL)" rather than "if (mem)".
> base/gsline.c

2020-02-24 17:30:54 +0000
Julian Smith <jules@op59.net>
6c1002cc251907e702fd5db9dc81365a964816c6

> Add support for multiple squeezes in one run.
> E.g. MEMENTO_SQUEEZES=115867-1..+3,119928-1..+3 ...
> This is equivalent running multiple times with MEMENTO_FAILAT set to 115866,
> 115867, 11588, 119927, 119928, 119929.
> base/memento.c

2020-02-24 10:38:53 +0000
Julian Smith <jules@op59.net>
39557bd53eee75a8b8f762457ce57a5437e79d6c

> Fix for MEMENTO_FAILAT=119928: only call gs_grestoreall_for_restore() if vmsave->gsave not NULL.
> Also fix error cleanup in gs_gsave_for_save(), otherwise this fix breaks
> previous fix for MEMENTO_FAILAT=115802.
> [Thanks to chrisl for this and various other recent fixes.]
> Fixes:
> MEMENTO_FAILAT=119928 LD_LIBRARY_PATH=../libbacktrace/.libs ./membin/gpdl -sDEVICE=bit -o /dev/null examples/tiger.eps
> base/gsstate.c
> psi/isave.c

2020-02-24 11:21:53 +0000
Julian Smith <jules@op59.net>
60507d492507817bb5ae14a17a01d19c50d41e0a

> toolbin/squeeze2text.py: improve log output.
> With -p, if there is gap in 'Memory squeezing @ <N>' output (because of calls
> to free()), output next <N>.
> Also flush log output to avoid looking like we've hung.
> toolbin/squeeze2text.py

2020-02-24 21:00:21 -0800
Michael Vrhel <michael.vrhel@artifex.com>
3a9ea36465e97ce729c5ab26dc8e0d1435b7b246

> Fix issue with fts_14_1416.pdf and psdcmyk16
> This was missed in the fix. Affected only 16 bit devices.
> http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=b1ac0686eea6adcf2db8cabf7858796494b4459d
> base/gxblend.c

2020-02-24 20:05:49 +0000
Robin Watts <Robin.Watts@artifex.com>
8f3320f9b6214907d24a4a9f77638b199aa95f8e

> Fix Ink names leaking.
> The cause of the leak was a typo in gx_final_DeviceN.
> Once this is fixed, we hit a problem where ink names are set
> to be a pointer to a static empty string, which can't be
> freed. Change to using NULL to mean empty ink name.
> base/gscdevn.c

2020-02-24 12:01:43 -0800
Robin Watts <Robin.Watts@artifex.com>
b28d57e7422d2d4df8c805342ad01dfc6c6e1232

> Memento/Valgrind tweak.
> Ensure we mark the contents of a block readable before we
> look for pointers in it, and don't overrun the end.
> base/memento.c

2020-02-24 12:57:28 +0000
Robin Watts <Robin.Watts@artifex.com>
0822ac2a5f1f02315a783504fccf615a55cf494f

> Squash some unused variable warnings.
> base/claptrap-planar.c
> base/gp_unifs.c
> base/gxclpath.c
> gpdl/tifftop.c

2020-02-24 12:14:23 +0000
Robin Watts <Robin.Watts@artifex.com>
82a2d6356858c0a4ab9ff7fa294c0380d04aa9e3

> pdf14_{fill_stroke_path,clist_fill_stroke_path_pattern_setup} cleanups.
> Use a nicer method of breaking const (to avoid warnings). Ensure
> that we always put everything back as it was when we leave the
> functions, even if we have an error.
> Remove needless cleanup code to handle functions that can never
> return an error to us returning an error.
> base/gdevp14.c

2020-02-24 12:35:30 +0000
Robin Watts <Robin.Watts@artifex.com>
b1ff23ccf08707af544de59d6c59971d0c17098c

> pdf14_clist_fill_stroke_path_pattern_setup overprint fix.
> Only enable CompatibleOverprint for the stroke part of stroke/fill
> patterns if we are in a subtractive space.
> base/gdevp14.c

2020-02-24 11:24:28 +0000
Robin Watts <Robin.Watts@artifex.com>
389324fd827e1172eb358b616a32af5fcb2633f6

> Squash some warnings with gs_swapcolors_quick breaking const.
> At various places in the code, we call gs_swapcolors_quick where
> we only have a const pgs.
> Properly, we should copy the pgs to a non-const pgs, and then use
> that, but that would be a performance hit.
> In all cases, we change the graphics state, then restore it before
> exit, so effectively it is const over the entire call of the
> enclosing procedure.
> Rather than having lots of small hacky casts removing const, we
> push the const breakage into gs_swapcolors_quick itself where we
> do it in the "approved" way using a union.
> base/gdevp14.c
> base/gsstate.c
> base/gxfill.c
> base/gxgstate.h
> devices/vector/gdevpdfd.c

2020-02-24 10:10:25 +0000
Robin Watts <Robin.Watts@artifex.com>
449433ff6689c603a56186dbde5721f6139aa939

> Avoid floating point in gxblend.c
> Use fixed point in preference.
> base/gxblend.c

2020-02-24 08:23:59 +0000
Ken Sharp <ken.sharp@artifex.com>
6badfb362efe0fb4f0c3df106a33ecd5b0265ef7

> Implement OPM tracking in pdfwrite
> More than somewhat to my surprise, the release testing of 9.51 revealed
> that pdfwrite was not tracking the state of overprint mode (OPM). It
> could be set by setdistillerparams, and in no other way.
> This commit adds tracking the OPM in the graphics state, removes the
> old overprint_mode variable from the device, but preserves the ability
> to alter the OPM using setdistillerparms.
> This also alters the initial state of OPM, the distiller params
> reference states that the 'factory default' of OPM is 1, but the PDF
> Reference says that the initial state of OPM is 0. We need to start
> with the correct setting of OPM so we change it form 1 to 0
> in gs_pdfwr.ps.
> In passing, cast a const gs_gstate * to a gs_gstate * when used by
> gs_swapcolours_quick, in order to avoid a compiler warning.
> This causes a small number of progressions in files using OPM (which is
> rare, its even rarer to actually alter it during the course of the file)
> Resource/Init/gs_pdfwr.ps
> devices/vector/gdevpdfb.h
> devices/vector/gdevpdfd.c
> devices/vector/gdevpdfg.c
> devices/vector/gdevpdfx.h

2020-02-20 16:24:12 -0800
Michael Vrhel <michael.vrhel@artifex.com>
3dc65600d6d4eb060398f06f148cfe4f07a82439

> Bug 702117 Knockout groups containing non-isolated groups
> So this ended up being rather complicated. The first issue was that
> we were not setting the backdrop properly for non-isolated groups that
> reside in knockout groups. When that was fixed, it was revealed that we
> were not doing the recompositing operation for non-isolated knockout groups. This meant
> that the backdrop was getting applied twice effectively (once in the original
> fill and then again when the group was popped). The only file that showed
> this issue was the crazy Altona page with the many overlapping groups. Customer
> file added to provide a clearer case in the regression tests.
> base/gdevp14.c
> base/gxblend.c
> base/gxblend1.c

2020-02-20 17:09:41 +0000
Julian Smith <jules@op59.net>
416baca7c4bcf0b1794b7b1647250bf09adaee9d

> Fix MEMENTO_FAILAT=115867 - segv in i_unregister_root() after failure in i_register_root().
> In pl_main_delete_instance(), don't call gs_unregister_root() if
> minst->device_root is NULL.
> Also in pl_top_create_device(), check return from
> gs_register_struct_root(). But this doesn't appear to make any difference to
> the handling of the memento error.
> Fixes:
> MEMENTO_FAILAT=115867 LD_LIBRARY_PATH=../libbacktrace/.libs ./membin/gpdl -sDEVICE=bit -o /dev/null examples/tiger.eps
> pcl/pl/plmain.c

2020-02-20 16:51:56 +0000
Robin Watts <Robin.Watts@artifex.com>
4eb54af16c69ef36371291bd43f853865adea1eb

> Fix deep color group compose issue.
> In commit bb7d57e84e9fe I reordered parameters to keep 8/16
> branches consistent, and missed one case.
> base/gxblend.c

2020-02-20 15:27:07 +0000
Robin Watts <Robin.Watts@artifex.com>
a2276988137021618bb3ca440aba50e126160bcd

> Remove needless "isolated" parameter from pdf14_mark_rect routines.
> The value was carefully plumbed through (only in the 8bit case) in
> a recent commit, but was never actually used. Remove it a) because
> it's pointless passing a variable we don't use, and b) because it's
> another difference between 8 and 16 bit versions.
> base/gxblend.c

2020-02-20 15:21:30 +0000
Robin Watts <Robin.Watts@artifex.com>
9ddcae93fe1629e81d36b17b7fec9de787b411cc

> Fix typing mistake in 16bit transparency.
> When promoting from 8 to 16 bit, shape and src_alpha become
> uint16_ts rather than bytes.
> base/gxblend.c

2020-02-20 15:06:38 +0000
Robin Watts <Robin.Watts@artifex.com>
7de8fe5a49df0f9154fa707a934e39c012c3cc2a

> Fix more overprint problems with deep color transparency.
> Again, overprint changes to the 8 bit paths had not been
> pulled across to the 16 bit path.
> base/gxblend.c

2020-02-19 07:10:40 +0000
Julian Smith <jules@op59.net>
2d3f8c01231d52a5595e2727b31b8044188a5af8

> Added toolbin/squeeze2text.py, for processing output from MEMENTO_SQUEEZEAT=...
> An alternative to squeeze2html.pl, outputing just summary information.
> toolbin/squeeze2text.py

2020-02-20 11:18:11 +0000
Julian Smith <jules@op59.net>
777d79315e0094bef83d241bc0d5683ea6775a55

> Fix for MEMENTO_FAILAT=115802: make gs_gsave_for_save() call gs_gsave() so it can restore after error.
> Previously, zsave() called gs_gsave_for_save() then gs_gsave(), but if
> gs_gsave() failed we ended up with SEGV in finalise code.
> To allow zsave() to restore things after gs_gsave() failure, we would need to
> add an include of base/gxgstate.h.
> Instead we remove the call of gs_gsave() from zsave() and append it to
> gs_gsave_for_save(), where things can be easily restored if it fails.
> [There are no other callers of gs_gsave_for_save().]
> Fixes:
> MEMENTO_FAILAT=115802 LD_LIBRARY_PATH=../libbacktrace/.libs ./membin/gpdl -sDEVICE=bit -o /dev/null examples/tiger.eps
> base/gsstate.c
> psi/zvmem.c

2020-02-18 09:44:51 +0000
Julian Smith <jules@op59.net>
6db4560f1e31bb92321894e0d008d310aa600097

> Avoid leaks if we get alloc failure when closing down (found by memento).
> In gs_main_finit(), ignore gs_error_VMerror from interp_reclaim(). Such error
> ultimately comes from gs_vmreclaim() calling context_state_load(), but the
> missing info doesn't seem to be required for gs_main_finit() to carry on.
> Fixes:
> MEMENTO_FAILAT=147801 LD_LIBRARY_PATH=../libbacktrace/.libs ./membin/gpdl -sDEVICE=bit -o /dev/null examples/tiger.eps
> psi/imain.c

2020-02-13 17:40:51 +0000
Robin Watts <Robin.Watts@artifex.com>
eb726fb4d2597cfcd4986dd9c105cf1ab71d09e3

> Fix image_color_icc_prep to properly align planar buffers.
> base/gxicolor.c

2020-02-13 10:50:10 +0000
Robin Watts <Robin.Watts@artifex.com>
e01371e00caa8f5d08ef150a6f594c93ca495be2

> Enable CAL for gxicolor halftoning.
> Looks like the calling code was unfinished, and the build
> changes were not done.
> Also, squash some warnings.
> base/gxicolor.c
> base/gximono.c
> base/lib.mak
> devices/gdevtsep.c

2020-02-17 15:57:47 +0000
Chris Liddell <chris.liddell@artifex.com>
c4e7cddc4d053f2850e697696e2498180547961a

> Ensure the memory entry in a cloned gstate is correct.
> In theory, we could end up cloning a graphics state with one allocator, then
> assigning the "memory" entry in the cloned state to that of the state we are
> cloning.
> In practice the two have (so far) been the same, but that is not guaranteed.
> base/gsstate.c

2020-02-14 11:08:57 +0000
Chris Liddell <chris.liddell@artifex.com>
239e70cd02491bab1cce9092c07c959427358646

> Fix segfault cleaning up after gstate clone failure.
> For me this happens with MEMENTO_FAILAT=112447 and for Julian it happens with
> MEMENTO_FAILAT=115905.
> Basically, the order of events was that we'd allocate a new gstate, copy the
> contents of the existing gstate to the new one, then copy the dash pattern
> (which could fail) and copy the "client_data" (which could and, in this case,
> did fail). When either of those failed, we'd jump to the error handling and
> exit with the error.
> The problem is that, by jumping to the "fail" label, we skip over all the code
> that fixes up the reference counts (and various other things) to account for
> the newly created gstate.
> This commit reorders things so we allocate the gstate, copy the client data,
> copy the dash pattern, *then* assign the contents of the old gstate to the new
> one, and carry on. Thus, by the time the gstate contents are copied, the
> function cannot fail, and everything is sure to be correctly setup.
> In the event that either the dash pattern or the client data fail to allocate,
> the new gstate is still filled with NULLs, except for the subset of
> "gs_gstate_parts" which are allocated and setup correctly so we can safely
> free the graphics state object before returning the error.
> Also, use NULL for pointer validation instead of 0.
> base/gsstate.c

2020-02-18 17:43:18 -0800
Michael Vrhel <michael.vrhel@artifex.com>
db5b51109ddee39b17b2ff2c2ac12f41a70785ef

> Make sure pattern fills use proper alpha settings
> Fix for regression of fts_28_2804.pdf pdfwrite output rendering
> with fill-stroke commit. This also fixes the rendering of fts_25_2526.pdf
> Bug 702033. Required a minor change in the XPS interpreter to make
> sure that patterns did not have their opacity double applied.
> base/gdevp14.c
> xps/xpstile.c

2020-02-19 17:20:09 +0000
Robin Watts <Robin.Watts@artifex.com>
cddd44e1bfcdaba1c289c3d83645613d136e5e3e

> Bug 702105: Premature EOF Infinite loop in interpolated imagemask stream.
> Fix supplied by Peter Cherepanov. Many thanks.
> base/simscale.c

2020-02-19 16:58:06 +0000
Robin Watts <Robin.Watts@artifex.com>
59089ab66b3faaa683bb3aeb0bf856b7aa284f9b

> Fix "blue gradients" seen with psdrgb device.
> Since the fill/stroke commit went in, some files have been showing
> gradients in the wrong colours. For instance this one, spotted in
> release testing:
> gs -sDEVICE=psdrgb -r72 -dMaxBitmap=2000M -o out%d.psd
> ../tests_private/comparefiles/Layout.pdf
> Bisecting the fill/stroke branch back, it seems the commit that
> caused it is the one that stops psdrgb using 'devn' colors.
> This causes gradients to drop to using the color_info.comp_bits and
> comp_shift information, which the psd devices don't fill in.
> The fix here is to make psd_prn_open call the standard function for
> setting up these values.
> devices/gdevpsd.c

2020-02-13 14:48:05 -0800
Nancy Durgin <nancy.durgin@artifex.com>
25cd0c72b98f9efc6968254d1e3a2f33ec376369

> Bug701972 -- fix pdfwrite image downscaling bug
> Calculate the bits on the row using the input image width,
> not the output image width.
> I had to add an extra argument to a few functions to propagate the info
> down to where it is needed.
> Note obscure case involving calling psdf_setup_image_to_mask_filter()
> for a Type 4 image and CompatibilityLevel < 1.3. This change just
> adds the extra input_width arg, which doesn't change whatever it was
> doing before. If there is a bug lurking here, it seems unlikely
> anybody cares?
> devices/vector/gdevpdfi.c
> devices/vector/gdevpsdf.h
> devices/vector/gdevpsdi.c
> devices/vector/gdevpsds.c
> devices/vector/gdevpsds.h

2020-02-12 09:22:55 -0800
Nancy Durgin <nancy.durgin@artifex.com>
e9523603ac713e365702b81c228edcaaac667dc4

> Set the BitsPerComponent for alt stream in pdfwrite
> Add this to the image[1] code where it was missing
> This fixes bug where compressed images were correct, but if
> -dEncodeGrayImages=false was used, then they were truncated.
> This is related to trimmed/rescaled image for Bug701972.
> See the sample trim-nobug.pdf attached to that bug.
> devices/vector/gdevpdfi.c

2020-02-18 19:25:24 +0000
Robin Watts <Robin.Watts@artifex.com>
924f7ea07c7773a3b1510c6206c9a34227e4b39e

> Bug 702131: Fix overprint in additive spaces.
> We should only enter CompatibleOverprint blend mode if we
> are in an subtractive space. This stops pdf14 trying to honour
> drawn_comps even in additive spaces.
> base/gdevp14.c

2020-02-14 14:02:24 -0800
Ray Johnston <ray.johnston@artifex.com>
d98b553c829fad94cd4338910468d2b1b6ee64f7

> Fix bug 702079: SEGV with clist and PCL caused by wrong color in images.
> The clist_image_plane_data function was called with the dev_color for a band
> being type <pattern> when the image had type <pure>, but the code was not
> calling cmd_put_drawing_color to update the bands for the image because uses_color
> was false. Add rop3_uses_S(pgs0>log_op) as well as (||) rop3_uses_T(pgs->log_op)
> when CombineWitColor is true.
> Note that extra calls to cmd_put_drawing_color before an image are low cost
> and do nothing if the current device color is already the same.
> base/gxclimag.c

2020-02-18 09:48:07 -0800
Michael Vrhel <michael.vrhel@artifex.com>
4f55464d5c1640075a67a8b50557a48766783e08

> Bug 702128 : clist pdf14 overprint state
> This change ensures that gxdso_overprint_active
> gets the proper state information.
> When the clist writer is active with the pdf14 device, the writer maintains
> the current overprint state (as the writer has no access to the pdf14 member variables)
> and must know what to put in the clist.
> When the clist writer is not present (i.e. page mode), the pdf14 device
> maintains the information.
> base/gdevp14.c

2020-02-18 11:46:45 +0000
Robin Watts <Robin.Watts@artifex.com>
f1887408860910c19c980f05fd0f8fc93b5f06a1

> Bug 702068 continued: Fix smasked images with masks.
> Release testing has shown up another case that needs help.
> gs/bin -sDEVICE=ppmraw -o out.ppm -r300 -dMaxBitmap=1G
> tests_private/pdf/sumatra/1901_-_tiling_inconsistencies.pdf
> This shows horizontal white lines in the "Next" "Up" "Previous"
> images at the top of the page.
> Investigation shows this is due to the images having Masks as well
> as SMasks.
> The Mask image is run to a 1 bit memory device, which means that
> the gxdso to check if we are in an SMask doesn't work. We work
> around this by introducing a new flag to gs_pixel_image_common
> that we can set to indicate that we are within an smask. We set
> this when we set the masked image up (using the gxdso), and check
> it when we come to do the gridfitting.
> base/gsiparam.h
> base/gxclrast.c
> base/gximage.c
> base/gximage3.c
> base/gxipixel.c

2020-02-17 19:31:50 +0000
Robin Watts <Robin.Watts@artifex.com>
51a0be1a6ac3bae2dc1b8bcdd91f58f76b9132c9

> Sync deep colour blending with recent changes to 8 bit blending.
> Release testing reveals problems with deep color blending and
> overprint. This is because changes were made to the 8bit
> branches of gxblend.c that weren't fully reflected in the
> 16bit branches.
> Reapply those changes here.
> While we're at it, address some other minor code cleanups,
> including keeping the ordering of parameters the same between 8
> and 16 bit to avoid confusion in future.
> The command that showed the inital problem was:
> bin/gswin32c.exe -o out.psd -sDEVICE=psdcmyk16 tests_private/comparefiles/Bug695916.pdf
> where the image of the Earth did not appear.
> base/gxblend.c

2020-02-17 13:27:10 +0000
Robin Watts <Robin.Watts@artifex.com>
b7faa941d09db8856378e45d4f5c81b5f93e5f90

> Bug 702130: Fix JPEG memory failure problems.
> The SEGV reported by Memento squeezing (which oddly is at 113600
> for me, rather than Julian's higher number) is caused by jpeglib
> calling 'mem_term' on something that failed to 'mem_init'.
> The fix is to use gs_memory_chunk_unwrap rather than target/release,
> and to check whether mem == cmem to see whether that actually did
> unwrap.
> This runs us into a further problem, where we are freeing the
> custom memory descriptor using a gc memory pointer, where it was
> allocated using a non gc one.
> Rather than just changing the free to use the non gc one, we take
> the opportunity to ensure that ALL the blocks are in non gc memory.
> JPEGlib will take poorly to its memory being gc'd away, and none
> of it needs to subject to gc.
> Credit goes largely to Chris for this fix.
> base/sjpegc.c

2020-02-14 18:44:53 +0000
Robin Watts <Robin.Watts@artifex.com>
619c0231952c20cc14f0eaf603e0cb01aa937eff

> Bug 702124 (continued): Avoid FP errors leading to empty pattern cells.
> The limited accuracy of floats can cause pattern cells to appear to
> be empty when they are not.
> Avoid adding the (often large) tx and ty components in until after we
> have calculated the width/heights.
> base/gsptype1.c

2020-02-14 18:43:00 +0000
Robin Watts <Robin.Watts@artifex.com>
8edb1b1e7bb84ff4598819fe078eb0ed2c4948d5

> Bug 702124: Avoid VMerror when a pattern cell height is 0.
> We detect buffer_height == 0 and take it to mean that we can't
> get a large enough buffer for even a single scanline. Actually
> it can mean that the pattern cell was empty, which gives a
> spurious error.
> base/gxmclip.c

2020-02-14 17:08:12 +0000
Julian Smith <jules@op59.net>
6beaf42d25f3969b6dc3d8e1b1795017708000c5

> Fix segv after memento squeeze in psdf_DCT_filter().
> Fixes:
> MEMENTO_FAILAT=117152 LD_LIBRARY_PATH=../libbacktrace/.libs ./membin/gpdl -sDEVICE=bit -o /dev/null examples/tiger.eps
> devices/vector/gdevpsdu.c

2020-02-13 14:54:42 +0000
Julian Smith <jules@op59.net>
8d052b3de78b8034daed23e668758c76a8d8c478

> Fixed double free after alloc failure in gs_lib_ctx_set_icc_directory*() (found by memento).
> After we've freed p_ctx->profiledir we need to set it to NULL otherwise if we
> return an error it will be freed a second time when we close down.
> Fixes:
> MEMENTO_FAILAT=101810 LD_LIBRARY_PATH=../libbacktrace/.libs ./membin/gpdl -sDEVICE=bit -o /dev/null examples/tiger.eps
> base/gslibctx.c

2020-02-12 11:12:37 +0000
Julian Smith <jules@op59.net>
dbde03ca37da96a94f4b7a6f0ba22a47a7bc2cb1

> Fixed leak on error in gs_fapi_ufst_init() (found by memento).
> Fixes:
> MEMENTO_FAILAT=22 LD_LIBRARY_PATH=../libbacktrace/.libs ./membin/gpdl -sDEVICE=bit -o /dev/null examples/tiger.eps
> base/fapiufst.c

2020-02-13 19:48:01 +0000
Robin Watts <Robin.Watts@artifex.com>
08695f8ccebb0d25eb2a5933ecee92281eefc1be

> Bug 702121: PCL performance degradation
> Henry chased the cause down to commit b399f84, an attempt to
> fix Bug 700624. Looking at that code now, it has a silly typo
> in it, that was causing it not be triggered in cases when it
> should have been. Fixed here.
> base/gxpcmap.c

2020-02-13 11:11:40 -0800
Robin Watts <Robin.Watts@artifex.com>
e2cdef26db058e84c2cf4dff5f638e669f961b52

> Alternative fix for leaks after error in gs_main_init_with_args01()
> When memory squeezing gpdl, Julian found leaks in the gpdl
> startup of the postscript interpreter when allocations failed
> in gs_main_init_with_args01().
> Here, we fix the problem by making the psitop.c layer within gpdl
> call the appropriate shutdown code when we catch the error. This
> moves gpdl to being consistent with other users of the gs_main
> layer.
> Memento memory squeezing around the point of failure (event 2035)
> now shows this to be OK.
> MEMENTO_SQUEEZEAT=2034 ./membin/gpdl -sDEVICE=bit -o /dev/null examples/tiger.eps
> gpdl/psitop.c

2020-02-13 18:47:37 +0000
Robin Watts <Robin.Watts@artifex.com>
bbecd13cc34f3dcdcedd726e7de12c988da9794a

> Revert "Fix leaks after error in gs_main_init_with_args01() (found by memento)."
> This reverts commit f35924926cb35f08be5a12ded4a00eb2f42aed3e.
> When memory squeezing gpdl, Julian found leaks in the gpdl
> startup of the postscript interpreter when allocations failed
> in gs_main_init_with_args01().
> The initial fix attempted was to make gs_main_init_with_args01()
> closedown the interpreter on such errors. This worked for the
> tested cases, but hid problems with non-memory related errors
> (such as not being able to open a file specified on the command
> line) when called by gs (rather than gpdl).
> The change attempted resulted in gs_main_finit() being called
> twice as gs (and other users of the gs_main APIs) expect to have
> to call gs_main_finit() to shut down after gs_main_init_with_args01()
> returns an error code.
> The real problem is that gpdl is not doing this in the same way as
> other callers.
> The gs_main layer has existed for donkeys years, so it's probably
> best that we just take it as fixed and don't require callers to
> start changing stuff now.
> Accordingly, I am reverting the attempted fix here, and will
> try a different fix for it that only affects gpdl shortly.
> psi/imainarg.c

2020-02-11 16:48:24 -0800
Ray Johnston <ray.johnston@artifex.com>
68be233f36feb045e442a18c4f4e4d2ced52b197

> Change to improve memory and speed (Bug 702099)
> As described in the bug, the patch to disable high-level images in
> pattern-clists when Interpolate is true is no longer needed (hasn't
> been since 2015), and it causes the memory and performance problems
> with this type of file.
> base/gxclimag.c

2020-02-12 15:10:54 -0800
Michael Vrhel <michael.vrhel@artifex.com>
2dea734a6184668511758fe1929a1d3166df85b6

> Bug 702114 non-isolated group in knockout group
> Make sure to use the parents backdrop as our backdrop when we
> push a non-isolated group that resides in a knockout group.
> Note though that this apparently is not the case if we are
> constructing a soft mask.
> base/gdevp14.c

2020-02-12 10:54:47 -0800
Michael Vrhel <michael.vrhel@artifex.com>
9af467b71198710bc42509e00b730a716b8e4828

> Bug 702113 Softmask with transfer function
> In a couple spots we look at the value of the background value
> of the softmask to decide if we really need the softmask in
> areas outside the group bounding box. These checks were not
> considering the impact of the transfer function.
> base/gdevp14.c

2020-02-12 11:37:33 +0000
Chris Liddell <chris.liddell@artifex.com>
9557cdc0b00894bc4c2c1fccb1f19c33fd7eb499

> Dates etc for 9.51 RC1
> Makefile.in
> base/gscdefs.h
> doc/DLL.htm
> doc/Deprecated.htm
> doc/Develop.htm
> doc/Devices.htm
> doc/Drivers.htm
> doc/Fonts.htm
> doc/History9.htm
> doc/Install.htm
> doc/Internal.htm
> doc/Language.htm
> doc/Lib.htm
> doc/Make.htm
> doc/News.htm
> doc/Ps-style.htm
> doc/Ps2epsi.htm
> doc/Psfiles.htm
> doc/Readme.htm
> doc/Release.htm
> doc/SavedPages.htm
> doc/Source.htm
> doc/Unix-lpr.htm
> doc/Use.htm
> doc/VectorDevices.htm
> doc/WhatIsGS.htm
> doc/gs-vms.hlp
> doc/sample_downscale_device.htm
> doc/subclass.htm
> doc/thirdparty.htm
> man/dvipdf.1
> man/gs.1
> man/gslp.1
> man/gsnd.1
> man/pdf2dsc.1
> man/pdf2ps.1
> man/pf2afm.1
> man/pfbtopfa.1
> man/printafm.1
> man/ps2ascii.1
> man/ps2epsi.1
> man/ps2pdf.1
> man/ps2pdfwr.1
> man/ps2ps.1
> psi/winint.mak

2020-02-11 11:11:47 -0800
Ray Johnston <ray.johnston@artifex.com>
ad317d8d436f3ae282597631464313666451747f

> Fix bug 702060: clip_transform_pixel_region was ignoring the 'transpose' flag.
> base/gxclip.c

2020-02-12 00:24:25 +0800
Sebastian Rasmussen <sebras@gmail.com>
1c6bfa12cccb726974aa1c3ad5c4887600f7331d

> Update jbig2dec stuff for 0.18 release.
> jbig2dec/CHANGES
> jbig2dec/jbig2.h
> jbig2dec/jbig2dec.1

2020-02-12 00:27:41 +0800
Sebastian Rasmussen <sebras@gmail.com>
70f094ae147afdbbcfcff3351f3ec13db6a84c42

> jbig2dec: Sync memento from ghostscript.
> jbig2dec/memento.c

2020-02-10 16:19:49 +0000
Julian Smith <jules@op59.net>
f35924926cb35f08be5a12ded4a00eb2f42aed3e

> Fix leaks after error in gs_main_init_with_args01() (found by memento).
> Fixes various memento failures starting with:
> MEMENTO_FAILAT=2034 LD_LIBRARY_PATH=../libbacktrace/.libs ./membin/gpdl -sDEVICE=bit -o /dev/null examples/tiger.eps
> psi/imainarg.c

2020-02-10 16:11:31 +0000
Julian Smith <jules@op59.net>
2704441705cb115b352350252480dbb2505d9767

> Memento: show backtrace when we start failing.
> base/memento.c

2020-02-10 16:11:06 +0000
Julian Smith <jules@op59.net>
c736329f36c2258011162c97eec59818fb6f147e

> Fixed segv after alloc failure in ps_impl_allocate_interp_instance() (found by memento).
> Fixes:
> MEMENTO_FAILAT=2017 LD_LIBRARY_PATH=../libbacktrace/.libs ./membin/gpdl -sDEVICE=bit -o /dev/null examples/tiger.eps
> gpdl/psitop.c

2020-02-10 16:00:29 +0000
Julian Smith <jules@op59.net>
f1cb9e832424a1185fe081e2238b2ba42f805318

> Fixed leak in xps_impl_allocate_interp_instance() (found by memento).
> Fixes:
> MEMENTO_FAILAT=2011 LD_LIBRARY_PATH=../libbacktrace/.libs ./membin/gpdl -sDEVICE=bit -o /dev/null examples/tiger.eps
> xps/xpstop.c

2020-02-10 15:40:01 +0000
Julian Smith <jules@op59.net>
59dba1a5a0f2d45c18249697b3429c250ae7311a

> Fixed segv on error in gs_cspace_new_scrgb() (found by memento).
> Fixes:
> MEMENTO_FAILAT=2006 LD_LIBRARY_PATH=../libbacktrace/.libs ./membin/gpdl -sDEVICE=bit -o /dev/null examples/tiger.eps
> base/gscspace.c

2020-02-10 15:30:18 +0000
Julian Smith <jules@op59.net>
95378885483aa68969417c84e59be4eb1ad0f05e

> Fixed segv on error in gsicc_set_iccsmaskprofile() (found by memento).
> Fixes:
> MEMENTO_FAILAT=1951 LD_LIBRARY_PATH=../libbacktrace/.libs ./membin/gpdl -sDEVICE=bit -o /dev/null examples/tiger.eps
> base/gsicc_manage.c

2020-02-10 12:21:24 +0000
Julian Smith <jules@op59.net>
691d2e37fc9f06bf6fb0ed009a880f4d40a86f48

> Fixed leak on error in xps_impl_allocate_interp_instance() (found by memento).
> Fixes:
> MEMENTO_FAILAT=1938 LD_LIBRARY_PATH=../libbacktrace/.libs ./membin/gpdl -sDEVICE=bit -o /dev/null examples/tiger.eps
> xps/xpstop.c

2020-02-10 11:40:59 +0000
Julian Smith <jules@op59.net>
450eb91a0af4901b1f9a259cc69d8976113cbadb

> Fix error handling in xps_impl_allocate_interp_instance() (detected by memento).
> Handle error from gs_font_dir_alloc(), and moved all cleanup to end.
> Fixes:
> MEMENTO_FAILAT=1937 LD_LIBRARY_PATH=../libbacktrace/.libs ./membin/gpdl -sDEVICE=bit -o /dev/null examples/tiger.eps
> xps/xpstop.c

2020-02-10 11:21:37 +0000
Julian Smith <jules@op59.net>
33130c86c4d46bafe7613e3b4b114481c30d17ad

> Fix segv in gsicc_alloc_link() error handling (detected by memento).
> Set up placeholder values in *result before trying to set result->lock, so that
> gs_free_object() works without segv.
> Fixes:
> MEMENTO_FAILAT=431 LD_LIBRARY_PATH=../libbacktrace/.libs ./membin/gpdl -sDEVICE=bit -o /dev/null examples/tiger.eps
> base/gsicc_cache.c

2020-02-07 19:01:01 +0000
Julian Smith <jules@op59.net>
da2759cd587e2a67134db469cb143643469f09f5

> Fix leak on error in gsicc_profile_new() (detected by memento).
> Fixes:
> MEMENTO_FAILAT=369 ./membin/gpdl -sDEVICE=bit -o /dev/null examples/tiger.eps
> base/gsicc_manage.c

2020-02-07 19:38:55 +0000
Robin Watts <Robin.Watts@artifex.com>
0ddc921923d36c19480223f3d92c19aee03df961

> Pull in a couple of memento fixes from Sebastian.
> base/memento.c

2019-09-29 16:59:29 +0200
Sebastian Rasmussen <sebras@gmail.com>
df70f85ce3f5dd300b5ce75b348e78dff528c2f4

> jbig2dec: Invite user to define MEMENTO in CFLAGS.
> Previously we invited the user to define MEMENTO in jbig2_priv.h.
> The problem with doing that is that the flag is enabled for all .c
> modules, except memento.c. This implies that while memento's wrapper
> functions are called, the versions being called are the ones that
> have memento features disabled.
> Setting CFLAGS=-DMEMENTO while configuring/building is the better
> option as CFLAGS will affect all .c modules.
> jbig2dec/jbig2_priv.h

2019-09-29 16:55:51 +0200
Sebastian Rasmussen <sebras@gmail.com>
20009c9e35eca1d66f0c1d2fadb9956304692156

> jbig2dec: Fix compilation issues with memento build.
> jbig2dec/memento.c

2019-10-17 12:11:54 +0200
Sebastian Rasmussen <sebras@gmail.com>
5fde8364de28bc44965a57f1dd0190c0966bccb4

> jbig2dec: Fix memento interfering with allocator callback names.
> Memento changes the names of the callbacks when they are set, but
> not when the structure is defined in the command line tool. Work
> around this by including memento prior to the structure being
> defined so that memento changes the names in both places.
> The alternative would be changing the jbig2dec API yet again.
> jbig2dec/jbig2dec.c

2020-02-08 03:18:09 +0800
Sebastian Rasmussen <sebras@gmail.com>
22665fbc3ff92c46952b07fcb99b8102e0fabde5

> jbig2dec: Sync memento from ghostscript.
> jbig2dec/memento.c
> jbig2dec/memento.h

2020-01-11 01:51:19 +0100
Sebastian Rasmussen <sebras@gmail.com>
ebe1bfef330f4568c6ef394571cf800604dff277

> Bug 702097: Import security fixes for OpenJPEG.
> Upstream has merged two security fixes. At the moment there is
> no new upstream release, so we merge the two fixes downstream:
> * Fix for upstream issue #1228, registered as CVE-2020-6851:
> https://github.com/uclouvain/openjpeg/commit/024b8407392cb0b82b04b58ed256094ed5799e04
> "opj_j2k_update_image_dimensions(): reject images whose coordinates are beyond INT_MAX (fixes #1228)"
> * Fix for upstream issue #1231, registered as CVE-2020-8112:
> https://github.com/uclouvain/openjpeg/commit/05f9b91e60debda0e83977e5e63b2e66486f7074
> "opj_tcd_init_tile(): avoid integer overflow
> That could lead to later assertion failures.
> Fixes #1231 / CVE-2020-8112"
> openjpeg/src/lib/openjp2/j2k.c
> openjpeg/src/lib/openjp2/tcd.c

2020-02-06 11:47:48 +0000
Julian Smith <jules@op59.net>
c6d8dcf8448235895759fb7e3268105c4092a194

> clusterpush.pl: exclude all *-bin and *-obj directories.
> toolbin/localcluster/clusterpush.pl

2020-02-07 14:27:12 +0000
Julian Smith <jules@op59.net>
e507f7e272cfe94099ed6a395a3fa584d56fd3aa

> Fixed memento leak when squeezed in gs_main_init1().
> Fixes leaked blocks in:
> MEMENTO_FAILAT=202 ./membin/gs -sDEVICE=bit -o /dev/null examples/tiger.eps
> Also in context_state_alloc(), ensure pcst->memory is valid even if we return
> an error.
> psi/icontext.c
> psi/imain.c

2020-02-07 12:33:56 +0000
Robin Watts <Robin.Watts@artifex.com>
0e9f7fc153d92cbed9a4f1fcf60778176888625d

> Bug 702100: Followup: Fix arch.h for OS-X to include size_t changes.
> Our fix for Bug 702100 meant we were using newly defined size_t
> limits from arch.h. While these were generated correctly for
> things using arch.h, they were missed out of one of the
> pregenerated files in the arch directory, namely the OS-X one.
> Add those back here.
> Thanks to Peter Skarpetis for reporting this.
> arch/osx-x86-x86_64-ppc-gcc.h

2020-02-06 15:08:55 +0000
Robin Watts <Robin.Watts@artifex.com>
e193b5dc14a6029b2648a5712c154499d819186f

> Bug 702100: Fix memory limit to be based on size_t not long.
> I missed this when converting from longs to size_ts. This
> resulted on different maximums for linux and windows 64bit
> builds, due to the different size of longs on those two
> platforms.
> Update the debugging printfs to make use of the PRIdSIZE macros
> rather than truncating.
> base/gsalloc.c
> base/gsmalloc.c
> base/std.h

2020-02-06 14:39:10 +0000
Robin Watts <Robin.Watts@artifex.com>
3ac7d3c0ed5a339c8e2fe25c43feac92b9813b1b

> Sync memento between mupdf and gs.
> base/memento.c

2020-02-06 13:02:33 +0000
Robin Watts <Robin.Watts@artifex.com>
d185c5afea23e937edda368491d382650001f5b4

> Memento: Remove MEMENTO_SQUEEZE_BUILD from the code.
> Rather than relying on building with MEMENTO_SQUEEZE_BUILD,
> instead nobble the pthread based threading functions themselves
> to check Memento_squeezing in MEMENTO builds.
> a) This means less pollution of the code overall as the changes
> are restricted to just one module.
> b) This will stop me forgetting to build with MEMENTO_SQUEEZE_BUILD
> and not understanding the results - EVERY SINGLE TIME.
> c) It means a single MEMENTO build can be used both for
> memory squeezing (of single-threaded runs) and normal memento
> testing (of both single- and multi-threaded runs).
> base/gp_psync.c
> base/gsicc_cache.c
> base/gsicc_lcms2.c
> base/gsicc_lcms2mt.c
> base/gsicc_manage.c
> base/gslibctx.c
> base/gsmalloc.c
> base/memento.c
> base/memento.h
> base/sjpx_openjpeg.c
> psi/imain.c

2020-02-06 11:06:38 +0000
Julian Smith <jules@op59.net>
f40471ba6312a89cda81c23c1690dfbdbbc2722f

> Fix MEMENTO_FAILAT=352 in gsicc_cache_new()
> Ensure that result's fields are initialised before we attempt to allocate
> result->lock. Otherwise if the latter fails and we attempt to clean up,
> icc_linkcache_finalize() will get a SEGV.
> base/gsicc_cache.c

2018-10-31 20:22:11 +0100
Sebastian Rasmussen <sebras@gmail.com>
37fae2058eb7216c60801dfdbd5b9c987446866a

> Re-apply fix for bug 700088 lost in openjpeg 2.3.1 upgrade.
> The original commit message read:
> Bug 700088: Report error if all wanted J2K components are not decoded.
> Ghostscript used to attempt to use even the undecoded components.
> The source code for upstream's opj_decompress tool avoided this by
> a workaround along with a comment indicating that this ought to be
> done in the library (so all clients, e.g. Ghostscript will benefit
> from it). With this commit the library will error out if not all
> requested components are successfully decoded. Thus Ghostscript
> will no longer crash.
> Reported in https://github.com/uclouvain/openjpeg/issues/1158
> sent upstream in https://github.com/uclouvain/openjpeg/pull/1164
> and finally committed in e66125fe260deee49fdf6e9978d9bd29871dd5bb
> openjpeg/src/lib/openjp2/j2k.c

2020-02-05 11:53:57 +0000
Robin Watts <Robin.Watts@artifex.com>
56e3ed1abc84ef0c8a718b458a5734b016e7b8cc

> jbig2dec: Simplify jbig2_arith_decode.
> Previously we passed in an int * to get errors back, and
> used the return code for 0 or 1. Now we use the return code
> for 0, 1 or -ve for error.
> This saves between 1% and 2% of gs runtime for decoding
> tests/pdf/Jbig2_042_06.pdf.
> jbig2dec/jbig2_arith.c
> jbig2dec/jbig2_arith.h
> jbig2dec/jbig2_arith_iaid.c
> jbig2dec/jbig2_arith_int.c
> jbig2dec/jbig2_generic.c
> jbig2dec/jbig2_refinement.c

2020-02-04 11:10:41 +0000
Robin Watts <Robin.Watts@artifex.com>
db24ea3579f2fb6feef7eef98b7163ce6879ef98

> Bug 702068 continued: Revised handling of images within smasks.
> In an earlier commit, (Jan 27th, f6f8b8de) I updated the gridfitting
> logic so that Images within SMask definitions were gridfitted. This
> solved the original complaint.
> Sadly, this caused problems with other things (thanks to Ken for
> spotting them). Files sometimes use an image in an smask, and then
> another "matching" image masked by that smask. The upshot of my
> new code was that we'd treat them differently. 'Stretching' the
> SMasked image, and not stretching the underlying image could cause
> moire effects.
> The solution, implemented here, is to apply gridfitting to images
> both in SMask definitions and usage.
> base/gdevp14.c
> base/gdevp14.h
> base/gxdevsop.h
> base/gxipixel.c

2020-02-03 11:06:48 +0000
Robin Watts <Robin.Watts@artifex.com>
93ff4543685f8692db40a8911ad4605124b3433c

> jbig2dec: Fix OSS-Fuzz issue 20493
> The maximum x gbat works out as 126, where GBW is 32.
> This makes right = GBW - gmax huge. Clip the value to
> avoid problems.
> Thanks for OSS-Fuzz for reporting.
> jbig2dec/jbig2_arith.c

2020-02-04 11:33:02 +0000
Ken Sharp <ken.sharp@artifex.com>
a8572b92d6839abc60ecce6fae7a23b8b3a6bbbd

> Fix test of uninitialised value in halftone screens
> This is a result of bug #702077 and commit :
> http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=f434497caaf2624caabbbc62f36b745e096e95b5
> There's nothing wrong with the commit, but a 64-bit release build on
> Linux, using the customer file and 720 dpi, resulted in an infinite
> loop. Valgrind suggested this was due to an uninitialised variable.
> The problem here was that the code assumed that the first iteration
> looking for the best match would succeed. However, because the halftone
> has a Frequency of 1 the value of 'W' exceeded the maximum of a short,
> which led to use running round the loop without finding a valid halftone.
> Because we didn't find a valid halftone we would not set phcp to the
> values in 'p' (which is set by gx_compute_cell_values) and so we would
> test phcp->C which was uninitialised, and could end up going round the
> loop retrying with different values of rt endlessly.
> This commit simply short-circuits this by checking to see if we have
> at least one valid match (rt is not 1) or that we have set phcp to p
> (better is true). If we have done neither of these, then exit
> immediately with an error to prevent testing phcp->C.
> base/gshtscr.c

2020-02-03 16:29:59 +0000
Julian Smith <jules@op59.net>
b439a0a33f637254a831b3e76525002df3d41774

> jbig2dec: Fix OSS-Fuzz issue 20505.
> Previous code could overflow if w >= 2^32 - 32, breaking behaviour of 'if'
> statements and causing incorrect behaviour (including assert failures).
> The fix is due to sebras - change expressions such as (x + 32 > w) to (w - x <
> 32) to avoid overflow for very large w. (We know at all times that x <= w.)
> Thanks for OSS-Fuzz for reporting.
> jbig2dec/jbig2_mmr.c

2020-02-03 11:06:48 +0000
Robin Watts <Robin.Watts@artifex.com>
ece7a0b952d5dbca2a04682f38199444cb1ea16f

> jbig2dec: Fix OSS-Fuzz issue 20493
> The maximum x gbat works out as 126, where GBW is 32.
> This makes right = GBW - gmax huge. Clip the value to
> avoid problems.
> Thanks for OSS-Fuzz for reporting.
> jbig2dec/jbig2_generic.c

2020-02-03 10:54:09 +0000
Ken Sharp <ken.sharp@artifex.com>
f434497caaf2624caabbbc62f36b745e096e95b5

> PDF interpreter - don't abort stream on halftone errors
> Bug #702077 "Rangecheck error @720 dpi in sethalftone with SimpleDot"
> The supplied PDF file has a legal but stupid Halftone, it has a type 5
> halftone that does not specify a child halftone for each ink, for those
> inks that it does specify it uses the same halftone for all of them, and
> the child haftone has a /Frequency and /Angle of 1.
> Chris suggests this is a Harlequin Rip specific halftone which is
> intended not to be used, but to be replaced by something in the rip. Of
> course this means that the PDF file is now device-specific because any
> conforming PDF consumer which halftones should use the crazy halftone
> in the file which will lead to terrible output.
> However, poor quality isn't the complaint here, its the fact that we
> simply cannot create a halftone tile large enough to produce a 1 lpi
> screen at 720 dpi, so we throw an error.
> I believe this is a reasonable error, so I'm not going to try and
> change it. Instead this commit runs sethalftone in a stopped context
> and, if it fails, does not abort the current content stream but instead
> emits a warning and carries on.
> Resource/Init/pdf_draw.ps

2020-02-03 10:15:30 +0000
Robin Watts <Robin.Watts@artifex.com>
6a32a890b95355165cbaf79ff679c2f774b41d26

> Update msvc.mak to cope with new nmake version.
> psi/msvc.mak

2020-01-30 19:08:55 -0800
Ray Johnston <ray.johnston@artifex.com>
a3bc57e11d62227a73e9d86d804966740a6a2196

> Fix SEGV with -ZB debug in gx_image1_plane_data
> Discovered while debugging. If the buffer is used "in place" without
> copying, the 'buffer' pointer in the debug loop would be NULL. Instead
> use the penum->buffer.
> base/gxidata.c

2020-01-29 15:34:58 +0000
Robin Watts <Robin.Watts@artifex.com>
1c5a25063d6041902442334f633840bd8660451e

> Further optimisations to jbig2_decode_generic functions.
> Carry 'window' of pixel data across scanlines, and read
> samples from it.
> Write pixel data back in whole bytes rather than single bits.
> Sadly, for cases where the adaptive pixels are non-standard we
> need to write back after every pixel in case the adaptive
> pixels read from it.
> Profiling shows the time spent in the hotspot with jbig2_042_08.pdf
> drops from 56% to 43% with this optimisation.
> Particular thanks to Sebastian for spotting various issues with
> this.
> jbig2dec/jbig2_generic.c

2020-01-29 15:21:53 +0000
Robin Watts <Robin.Watts@artifex.com>
0e84a5f7ca660af4de1afb5bce79f6262b44ebd1

> Solve warnings in jbig2_image.h.
> Move some static inlines into the only file they are called
> from rather than having them in the header.
> jbig2dec/jbig2_generic.c
> jbig2dec/jbig2_image.h

2020-01-30 09:39:40 +0000
Ken Sharp <ken.sharp@artifex.com>
e852e56f0413d5ecb70a83fc03d78ad4a0561433

> More 'trailing white space' fixes.
> base/gxblend.c

2020-01-30 09:12:13 +0000
Ken Sharp <ken.sharp@artifex.com>
97868a9e6c787ea988f43952ae5d4236e142db13

> Fix trailing white spaces in a number of places.
> Since I use the Git commit hooks to verify no white space problems I
> can't merge master into the pdfi branch without first fixing these.
> base/gp_unifs.c
> base/gscolor2.c
> base/gscspace.c
> base/gsovrc.c
> base/gxblend.c
> base/gxccache.c
> base/gxclthrd.c
> contrib/gdevlx32.c

2020-01-29 15:10:06 +0000
Julian Smith <jules@op59.net>
3b2ae21ca594934728f623667db1a002286193ea

> Fix plane_strip_copy_rop() to use correct color depth when processing the plane.
> Temporarily change mdev->color_info.depth to mdev->planes[plane].depth
> so that things work when we process the plane. E.g. this fixes bug where
> mem_gray8_rgb24_strip_copy_rop() was overwriting into the line_ptrs[] array.
> Fixes segv in:
> ./bin/gs -sOutputFile=foo -dGraphicsAlphaBits=4 -dTextAlphaBits=4 -dMaxBitmap=10000 -sDEVICE=psdrgb -r300 -Z: -sDEFAULTPAPERSIZE=letter -dNOPAUSE -dBATCH -K2000000 -dClusterJob -dJOBSERVER ../fts_27_2709.pdf
> base/gdevmpla.c

2020-01-27 15:50:44 +0000
Robin Watts <Robin.Watts@artifex.com>
f6f8b8de526266eebd850e43bf1d0037b6f62e4c

> Bug 702068: Fix 'cracks' appearing around transparently blended regions.
> As part of rendering SMasks, we take the bbox for the region, and round
> it up to make the buffer in pdf14. If (as is frequently the case) the
> SMask contents are an image, the PS rendering of that image can result
> in it rounding DOWN (due to "any part of a pixel" vs "pixel centre
> covered"). This can result in 'cracks' around the edge of smasked
> groups.
> The fix, implemented here, is to extend the logic that "gridfits"
> images within pattern accumulator to also cover smasks.
> To make this work we add a new gx_dev_spec_op to detect whether we are
> in an smask definition.
> base/gdevp14.c
> base/gdevp14.h
> base/gxdevsop.h
> base/gxipixel.c

2020-01-29 12:40:14 +0000
Robin Watts <Robin.Watts@artifex.com>
e22376d9226b02ac8cb7951264dae2f3c1bc0b7f

> jbig2dec: Fix OSS-Fuzz issue 20358
> Avoid a signed/unsigned comparison which was implicitly casting
> gmax=-1 to unsigned, and hence making right larger than it should
> have been.
> Apply similar fixes to equivalent places in the code.
> jbig2dec/jbig2_generic.c

2020-01-29 11:00:18 +0000
Robin Watts <Robin.Watts@artifex.com>
dc48809733f2eec9ab96c012f62c9dd3a7c06c90

> Tweak stdpre.h's definition of inline.
> Ensure it's actually set when possible, in particular for
> VS.
> base/stdpre.h

2020-01-28 17:54:28 +0000
Robin Watts <Robin.Watts@artifex.com>
2450ea4feb89996e1107bb79d44a049bab5b971e

> MSVC makefile tweaks for VS2019.
> Spot a new version of nmake, as supplied with the latest version
> of the platform tools.
> Cope with both Community and Professional versions of VS2019.
> psi/msvc.mak

2020-01-29 10:00:39 +0000
Ken Sharp <ken.sharp@artifex.com>
cb456c92a550e1af70a4e268b2f5b02f2df5b8c6

> Fix jbig2dec compilation when inline is not defined.
> VS 2008 defines __inline but not inline, later versions of Visual Studio
> do define inline, but apparently also permit __inline (presumably for
> backwards compatibility).
> Since we now use inline for performance purposes in jbig2_image.h its
> vital that inline is defined. Here we modify the win32 config file to
> define inline in terms of __inline for VS 2008 and above, unless inline
> is already defined in which case we use it as is. For VS 2005
> Ghostscript defines inline as nothing, so we do the same.
> Finally, add a last-ditch definition of inline (as nothing) to jbig2.h
> to cover any build environment where inline is still undefined, so that
> the code will at least compile.
> jbig2dec/config_win32.h
> jbig2dec/jbig2.h

2020-01-29 05:04:34 +0800
Sebastian Rasmussen <sebras@gmail.com>
440dca503ee663290227334415f0c482e87b4ad7

> Bug 702041: Recognize pre-multiplied alpha when decoding with OpenJPEG.
> The bug's attached PDF has an annotation where the apperance stream consists of
> a JPEG2000 image with a softmask embedded in the image data (SMaskInData is
> non-zero). The JPEG2000 bitstream provides all three RGB channels and has both
> non-pre-multiplied and pre-multiplied alpha. The last alpha channel defined in
> the bitstream happens to be the pre-multiplied alpha. Having more than than a
> single alpha channel is not allowed according to PDF 2.0 if SMaskInData is
> non-zero. So the JPEG2000 bitstream (and by inference the PDF file) is arguably
> broken.
> Adobe Acrobat renders the annotation as a mostly transparent image consisting
> of a few hand-scribbled lines, but Ghostscript renders the annotation as a
> solid black square. So a workaround to match Acrobat is needed even if the PDF
> is broken.
> OpenJPEG hides that the JPEG2000 bitstream has multiple alpha channels by
> discarding all alpha channels except the last one defined, so Ghostscript can
> only get at the pre-multipled alpha channel. Previously the OpenJPEG glue layer
> therefore didn't recognize any alpha channels at all. The PDF interpreter has
> its own JPX cdef header decoder in Resources/Init/pdf_draw.ps and it _did_
> recognize that the file contained an alpha channel. This mismatch between the
> OpenJPEG glue layer and the PDF interpreter meant that no alpha channel data
> was propagated to the transparency compositor. It assumed that the alpha
> channel was fully opaque and because the RGB channels are all zero the
> annotation was rendered as a solid black square.
> Now that pre-multiplied alpha channels are recognized both in the OpenJPEG glue
> layer and in the PDF interpreter the pre-multiplied alpha channel data which
> contains the hand-scribbling is propagated to the transparency compositor which
> therefore can render the annotation similar to Acrobat.
> base/sjpx_openjpeg.c

2020-01-28 10:48:34 +0000
Robin Watts <Robin.Watts@artifex.com>
0e529d11fa270f8a40ebc2512cfb19cf8d3b0e50

> Remove "STANDARD_SLOW_VERSION" define from openjpeg makefile.
> This was added (apparently) to workaround a bug causing SEGVs
> in the optimised code. Sadly, this also halves the speed of the
> code.
> We have updated openjpeg since, so it shouldn't be necessary.
> Tests with the cluster seem to bear this out.
> base/openjpeg.mak

2020-01-28 17:35:37 +0000
Robin Watts <Robin.Watts@artifex.com>
9156c43b44b64c3928d2ef20f15d56bd44c6f897

> gpdl: Update j2k reading code to spot modified header.
> The JP2K spec says we should spot "jP ", where previously
> we'd only been spotting "jP\1a\1a". No idea where that
> latter one came from, but presumably we've been seeing it
> in some files. Make the code cope with both.
> gpdl/jp2ktop.c

2020-01-27 11:05:38 -0800
Ray Johnston <ray.johnston@artifex.com>
85cf3b3a7befbed4811d9460dc6a4637f929f8ab

> Fix bug 702065: Multiple rendering threads run slower.
> The image_render_color_DeviceN would remap colors using gx_remap_ICC
> which would get the link from the icclink_cache every time. This would
> temporarily lock the mutex for the cache which apparently caused delays.
> This would only occur in devices that support spot colors, when the page
> used transparency due to gx_device_uses_std_cmap_procs returning false in
> this case.
> The change refactors gx_remap_ICC to produce gx_remap_ICC_with_link that
> can be used by image_render_color_DeviceN with an icc_link that is retained
> in the image enum. The gs_image_class_4_color function is changed to get the
> icc_link for the image_enum before checking the for std cmap procs so that
> it will be available during image_render_color_DeviceN.
> base/gsicc.c
> base/gsicc.h
> base/gxicolor.c

2020-01-28 10:47:04 +0000
Robin Watts <Robin.Watts@artifex.com>
fe9e85d882ade3ebd55c4da0baf1f10d4bb8542d

> Remove stray defines from CAL makefile.
> When I created the CAL makefile, I copied bits of it from elsewhere.
> I obviously copied in a few stray defines. Remove those.
> base/cal.mak

2020-01-27 13:07:00 -0800
Ray Johnston <ray.johnston@artifex.com>
ad285b8ae3e1871db43d35e87f49e1d099eaf047

> Fix devn code that failed to check for allocation returning NULL
> Discovered while fixing Coverity CID 353647. pdf14_spot_get_color_comp_index
> failed to check, and since that code was copied from code in this file,
> it had the same problem.
> base/gdevdevn.c

2020-01-27 13:01:28 -0800
Ray Johnston <ray.johnston@artifex.com>
6efb69c6ae71b10b492ca194f92bfae17310c481

> Fix Coverity ID 353647: Possible out of bounds access
> The testing where separations were added in pdf14_spot_get_color_comp_index
> was wrong since it failed to take into account the process colorants.
> Also I found that the allocation of sep_name was not checked for NULL which
> could lead to dreferencing location 0 if the allocation failed. Note that
> there were other instances of this in gdevdevn.c which will be fixed in a
> separate commit.
> base/gdevp14.c

2020-01-23 11:19:45 -0800
Ray Johnston <ray.johnston@artifex.com>
089bff145f277d66afe4a3d9e19441aeccaed235

> Fix bug 702062: Opacity being applied twice.
> If an image has an SMask, the alpha was applied twice, during painting of
> the transparency group and again when the transparencygroup was popped.
> Thanks to Michael Vrhel for the analysis and suggested cure.
> If the device has PreserveSMask (e.g., pdfwrite) the SMask will be processed
> by the device and we should not push the group, nor change the opacity.
> Resource/Init/pdf_draw.ps

2020-01-27 10:12:24 -0800
Robin Watts <Robin.Watts@artifex.com>
17411adec88c3a846c10cb583cb261f50ca878d6

> Fix OSS-Fuzz issue 20332: buffer overflow in jbig2_image_compose.
> With extreme values of x/y/w/h we can get overflow. Test for this
> and exit safely.
> Thanks for OSS-Fuzz for reporting.
> jbig2dec/jbig2_image.c

2020-01-23 14:45:15 +0000
Robin Watts <Robin.Watts@artifex.com>
430b6a3eacd9648d029887081e99b3a3f0bba3c7

> Further optimisation to jbig2_decode_generic_template0_TPGDON.
> When the "standard" values for gbat are used, the pixel lookups
> simplify nicely. Optimise for this case.
> This brings the time spent in this function down to 17% (from 22%)
> for JBig2_042_08.pdf.
> jbig2dec/jbig2_generic.c

2020-01-23 12:55:27 +0000
Robin Watts <Robin.Watts@artifex.com>
94d8ea178fa7c36ad7b844d6d0912b6e090a35e2

> Further optimisations to jbig2_decode_generic_template0_TPGDON.
> Add a function to get a 'run' of pixels, and call that.
> This takes the time spent in this function from 29% to 22% for
> Jbig2_042_08.pdf.
> jbig2dec/jbig2_generic.c
> jbig2dec/jbig2_image.h

2020-01-23 12:09:08 +0000
Robin Watts <Robin.Watts@artifex.com>
124ef6a255de0a2816cce32c4fba0852eac1beb3

> jbig2dec: Optimise jbig2_decode_generic_template0_TPGDON
> Decodes of JBig2_042_08.pdf (the worst comparing file to
> luratech in terms of time) show significant time in that
> function (45%). With this patch that drops to 29%.
> jbig2dec/jbig2_generic.c
> jbig2dec/jbig2_image.h

2020-01-25 19:05:09 +0000
Julian Smith <jules@op59.net>
a2f9e74ece1690520cb77d7761cf0a5ddaa98474

> Coverity 94484: try different spacing in coverity annotation.
> base/gsbitcom.c

2020-01-24 18:08:22 +0000
Robin Watts <Robin.Watts@artifex.com>
34518a9aeaece63d97eda9b802824581846e289e

> jbig2dec: Fix whitespace issues from jbig2_image.c
> Introduced because I edited this in MuPDF and copied it back across.
> jbig2dec/jbig2_image.c

2020-01-24 18:00:13 +0000
Robin Watts <Robin.Watts@artifex.com>
c1565a04a938408fe31c862f10ef91f9ab5a14b1

> jbig2dec: reintroduce gcc attribute that got dropped by accident.
> jbig2dec/jbig2_priv.h

2020-01-24 17:04:27 +0000
Julian Smith <jules@op59.net>
a2e8041383100db54d1ea949d1b2648330f5188a

> Coverity 94484: added some asserts derived from bits_compress_scaled()'s preconditions.
> These are enough to demonstrate to the reader that Coverity 94484's
> negative_shift warning is spurious - in_shift_initial cannot be negative.
> base/gsbitcom.c

2020-01-23 17:12:55 +0000
Julian Smith <jules@op59.net>
409baa5cc81b8d184dceb52c06c9a80c5dcd61d6

> Coverity 94484: added annotation to avoid negative_shift issue.
> base/gsbitcom.c

2020-01-22 12:24:43 +0000
Julian Smith <jules@op59.net>
77b7cce9253863ac48ef6eb9821880250c7e1307

> jbig2dec/jbig2_mmr.c: optimised jbig2_find_changing_element().
> This was a hotspot after optimsation of jbig2_compose_image.
> Rather than step through each bit in turn, we now look 8, 16 and 32-bit at a
> time.
> jbig2dec/jbig2_mmr.c

2020-01-23 10:39:30 +0000
Robin Watts <Robin.Watts@artifex.com>
079117d95a3f07587624d6fd9ca388b300d0759e

> jbig2dec: Insert missing "inline" in templating.
> When using static inline templating to optimise a file, it's
> generally best to actually use static inline, and not just
> static.
> jbig2dec/jbig2_image.c

2020-01-23 10:39:04 +0000
Robin Watts <Robin.Watts@artifex.com>
f8e918106400220ffe21aef6ef1d491a42991475

> Squash some double -> fixed warnings.
> base/gdevp14.c

2020-01-21 18:16:37 +0000
Robin Watts <Robin.Watts@artifex.com>
b1b3c83af56412a06eeade1ea26a4db10de923a5

> Optimise jbig2_compose_image.
> Work at byte level rather than bit level, and use static inline
> templating methods to generate optimised versions for each
> different operator.
> jbig2dec/jbig2_image.c
> jbig2dec/jbig2_priv.h

2020-01-22 09:54:25 -0800
Ray Johnston <ray.johnston@artifex.com>
bd73d0c1d0c42fd1671b56f1277b5e9f25391907

> Bug 702052: MaxSpots > 58 caused exception with tiffsep device.
> The MaxSpots devn parameter was allowed to be set according the the
> capability of the tiffsep device (up to 60), but an array to hold the
> equivalent CMYK parameter information was not that large. Get rid of
> the MAX_DEVICE_PROCESS_COLORS #define and use the device num_std_colorants
> and color_info.max_components to determine the maximum number of spot
> colorants possible for this and PageSpotColors and update the Devices.htm
> document to reflect the actual limit.
> Also to reduce potential mischief, add range check error limits on the
> DeviceN params based on the device component support, not the absolute max.
> base/gdevdevn.c
> base/gdevdevn.h
> doc/Devices.htm

2020-01-22 17:53:24 +0000
Robin Watts <Robin.Watts@artifex.com>
8d548e306ae773e228dba331e614dd4cca2c56c7

> Bug 702057: Avoid division by zero in old scan converter.
> base/gxdtfill.h

2020-01-21 11:19:33 -0800
Michael Vrhel <michael.vrhel@artifex.com>
ba331d45f8e5be7723ff7bca9450f09c28910464

> Bug 702053: Overprint precision issue
> AR assumes for the purposes of overprint mode that a color
> value that is less that 0.5/255 is essentially zero. Also
> fix an issue in the Compatible overprint blend mode when
> overprint mode is enabled.
> base/gscspace.c
> base/gxblend.c

2020-01-21 17:41:52 +0000
Chris Liddell <chris.liddell@artifex.com>
d6569b95a29bf86dbdca0bc95e095acaad003525

> Fix segfaults in transparent patterns with -Z@
> One gc'ed member (buf) of the structure for patterns with transparency was not
> being initialised after allocation, meaning a debug build (which adds a
> validation step to the garbager) would attempt to follow an uninitialised
> pointer.
> Adding the relevant initialisation meant almost identical code in two places,
> so use the pre-existing function insteading of duplicating the code.
> Segfaults spotted in weekly debug-Z@ test.
> base/gxpcmap.c

2020-01-20 17:01:38 +0000
Chris Liddell <chris.liddell@artifex.com>
a0df672b0b65110d81f1e143b2e3681d660df8d2

> Bug 702054: Fix threaded render segfault with shared ICC profiles
> When creating the devices for individual rendering threads, if we cannot share
> the ICC profiles, we also cannot share the device icc_struct. In such a case,
> have each rendering thread device also create its own icc_struct.
> base/gxclthrd.c

2020-01-20 14:23:50 +0000
Julian Smith <jules@op59.net>
df228c8f42962d696861cfc79f7b114ac887d3c4

> Coverity 341118: avoid stat()/opendir() race in gp_enumerate_files_next_impl().
> base/gp_unifs.c

2020-01-20 12:32:26 +0000
Julian Smith <jules@op59.net>
30f86d215ac5abba5cfe86f0307d642274b850e4

> Coverity 350947: check return from gdev_prn_get_bits().
> Also changed some fns from void to int so we can propogate any error.
> contrib/gdevlx32.c

2020-01-20 12:31:00 +0000
Julian Smith <jules@op59.net>
bf2fcdc76fe0cec69e48f82e10144441b498a6b2

> Coverity 94484: assert that shift is >= 0.
> Have ran gs on 6,000 test files with some code that aborts if this shift is
> -ve, and nothing failed.
> base/gsbitcom.c

2020-01-17 12:58:14 +0000
Chris Liddell <chris.liddell@artifex.com>
144077b38b07119a0a5293ff8f3fc9e44f2813e1

> Bug 702049: Handle format strings in pipe OutputFiles
> When we implemented the new file access controls, we didn't realise that piped
> output files could include formatted strings: "|md5sum > %03d.txt", for example.
> This just tweaks the gs_add_control_path() logic so it will go through both
> the formatted string section *and* the pipe output section (rather than one or
> the other).
> base/gslibctx.c

2020-01-17 11:32:10 +0000
Chris Liddell <chris.liddell@artifex.com>
bb8c4e0dbc304e404a09e9e6f9551e1e504822bb

> Improve handling of current directory permissions
> Tweak the file access permissions code to allow file names with a current
> directory prefix to match "bare" file names - i.e. "file.ps" == "./file.ps".
> This improves compatibility with the "-P" command line option, as well as
> better matching user expectations.
> base/gpmisc.c

2020-01-15 16:05:45 +0000
Chris Liddell <chris.liddell@artifex.com>
05d44f258a727d86b9d7d9cbe04e43f3e741a636

> Bug 702037: Handle empty path from PDF text clip modes
> When using one of the clipping Tr modes (4 to 7), if there is no valid
> current point (i.e. no glyphs have been drawn, and no other previous operation
> has established a current point), Acrobat ignores the operation, whilst gs was
> treating that (as in Postscript) as an empty clip.
> We now check for a valid current point before calling clip during the ET
> handling.
> Resource/Init/pdf_ops.ps

2020-01-16 09:33:47 -0800
Ray Johnston <ray.johnston@artifex.com>
dfdf07b07d4fd83fc606d50eaa7132fc9ea7a1ce

> Coverity 353342: supposed Null pointer dereferences in gxclpath.c
> Strange that it griped about passing pdevc_stroke to cmd_put_drawing_color,
> but not earlier where it was passed to gx_default_fill_stroke_path.
> Fix (hopefully) by checking for NULL color pointers before ANY use.
> base/gxclpath.c

2020-01-15 12:23:21 -0800
Ray Johnston <ray.johnston@artifex.com>
27a3bf0bc16f492538434a9b1bfdbd588e29cedc

> Fix coverity CID 353343.
> Remove ppcs. When the code was changed to write the pgs->color[0],
> the ppcs param was never removed.
> base/gxclrast.c

2020-01-15 12:08:22 -0800
Michael Vrhel <michael.vrhel@artifex.com>
39eff9a56b2077d1a9adb48dfefd38e5e94b59c6

> Make -dUseFastColor occur even when source color space is ICC based
> The exception will be the CIELAB color space, the PS CIE color spaces,
> named color, and DeviceN ICC profiles.
> base/gsicc_cache.c
> base/gsicc_manage.c
> base/gsicc_manage.h
> doc/Use.htm

2020-01-15 11:33:45 -0800
Michael Vrhel <michael.vrhel@artifex.com>
1b7690cdd644fd690c2480a88da62be6131e79ab

> Coverity 353370 dead code removal
> base/gdevp14.c

2020-01-15 13:42:33 +0000
Julian Smith <jules@op59.net>
4872417c26e9133e1f39fc5f9a361053aaee87a7

> Coverity 350199: mark cf_encode_2d() as not tainting <lbuf> buffer.
> After annotating cf_encode_1d(), this coverity issue appears to have changed
> to worrying about cf_encode_2d(). Would have expected a new issue to have been
> generated.
> base/scfe.c

2020-01-15 11:09:53 +0000
Chris Liddell <chris.liddell@artifex.com>
c58f4c538404527cac25b549453f5b805652b445

> Fix dependency for custom freetype config header
> I'd missed the dependency to make sure the required directories were created
> before attempting to copy the custom header into one of those directories.
> base/lib.mak

2020-01-14 11:05:22 +0000
Julian Smith <jules@op59.net>
22618fc2fde49c8fc24ed7e88e98f9677e689c85

> Coverity 350199: Final attempt to convince coverity that cf_encode_1d() doesn't taint lbuf.
> base/scfe.c

2020-01-13 13:42:21 +0000
Chris Liddell <chris.liddell@artifex.com>
d824fb03a6653856dfe6e304bab8fe67a2c8f1f9

> Bug 689279: Disable bitmap glyphs in freetype
> The font in the XPS file has both outline and bitmap glyphs, and with such fonts
> freetype ends up marking them as "bitmap" and "non-scalable" fonts, so when we
> attempt to set a size for glyph scaling not equivalent to the included bitmaps,
> freetype throws an error.
> The file works with (a default build) of mupdf because mupdf disables freetype's
> bitmap font support at build time. It is not possible to force freetype to
> ignore bitmap glyphs at run time.
> This commit adopts a similar approach to mupdf, and disables bitmap glyph
> support using a custom options header file.
> base/freetype.mak
> base/gsftopts.h
> base/lib.mak

2020-01-13 09:54:41 -0800
Michael Vrhel <michael.vrhel@artifex.com>
67559bed1c0dceb2a1a59be0349e3465a1361743

> Fix error handling issue found by Coverity
> base/gdevp14.c

2020-01-13 18:18:57 +0000
Julian Smith <jules@op59.net>
defe1d994b52100f535cb9e6a7e6a4f4255d2b2b

> Coverity 350199: another attempt to quieten coverity.
> Will clean up annotations once we've found one that works.
> base/scfe.c

2020-01-13 16:48:32 +0000
Julian Smith <jules@op59.net>
3704918f3a987e95e7d06fc025de2dce04bab5e8

> Coverity 350199: further attempt to quieten coverity using -tainted_data_sink tag.
> base/scfe.c

2020-01-12 15:43:51 -0800
Michael Vrhel <michael.vrhel@artifex.com>
4ad96e96f1f929e444fdb0e220d2b05c1dde1bf1

> Fix defects reported from fill-stroke3 merge
> base/gdevp14.c
> base/gscspace.c
> base/gsovrc.c

2020-01-11 12:14:48 -0800
Michael Vrhel <michael.vrhel@artifex.com>
05c41c0dedaa512419f15798cbc3da92b6a90bbc

> Squashed commit fill-stroke3 branch
> This branch had several contributors including Robin Watts,
> Ken Sharp and Ray Johnston.
> The intent was to add a "fill and stroke" path device method
> to ensure we get proper rendering when doing fill/stroke
> methods with overprint and transparency. In addition,
> adding the method made it possible for pdfwrite to match
> the original pdf source file if it also had fill/stroke methods.
> The interaction with overprint and transparency led to significant
> changes in parts of the code related to those sections. In particular,
> overprint was reworked to ensure that the overprint compositor and
> the transparency compositor were aware if it was to be using
> the overprint drawn_comps for stroke or for fill. The code was
> rewritten so that the overprint compositor actions only occurred when
> an actual operation occurred (e.g. fill, stroke, image, text) as opposed
> to every time that the overprint graphic state values changed.
> When there is a fill-stroke operation with transparency, depending upon the
> graphic state values, a non-isolated knockout group may be pushed. From this,
> an issue with knockout groups within knockout groups was revealed, which was
> related to the backdrop selection. The backdrop selection code was simplified.
> Resource/Init/pdf_ops.ps
> base/gdbflags.h
> base/gdevdflt.c
> base/gdevepo.c
> base/gdevflp.c
> base/gdevmem.h
> base/gdevmplt.c
> base/gdevnfwd.c
> base/gdevoflt.c
> base/gdevp14.c
> base/gdevp14.h
> base/gdevsclass.c
> base/gdevsclass.h
> base/gscdevn.c
> base/gscolor.c
> base/gscolor2.c
> base/gscolor3.c
> base/gscpixel.c
> base/gscsepr.c
> base/gscspace.c
> base/gscspace.h
> base/gsdcolor.h
> base/gsdevice.c
> base/gsdparam.c
> base/gsdps1.c
> base/gsicc.c
> base/gsicc_manage.c
> base/gsimage.c
> base/gsovrc.c
> base/gsovrc.h
> base/gspaint.c
> base/gspaint.h
> base/gspath.c
> base/gspcolor.c
> base/gsptype1.c
> base/gsptype2.c
> base/gsstate.c
> base/gstext.c
> base/gstrans.h
> base/gxblend.c
> base/gxblend1.c
> base/gxccache.c
> base/gxclimag.c
> base/gxclip.c
> base/gxclip.h
> base/gxclipm.c
> base/gxclist.c
> base/gxclist.h
> base/gxclpath.c
> base/gxclpath.h
> base/gxclrast.c
> base/gxclrect.c
> base/gxcmap.c
> base/gxdevcli.h
> base/gxdevice.h
> base/gxdevsop.h
> base/gxfill.c
> base/gxgstate.h
> base/gxpaint.c
> base/gxpaint.h
> base/gxpath.h
> base/gxpath2.c
> base/gxpcmap.c
> base/gxpcolor.h
> base/gxstroke.c
> base/lib.mak
> devices/gdevpsd.c
> devices/vector/gdevpdfb.h
> devices/vector/gdevpdfd.c
> devices/vector/gdevpdfg.c
> devices/vector/gdevpdfg.h
> devices/vector/gdevpdfx.h
> lcms2mt/ChangeLog
> lcms2mt/Projects/VC2010/lcms2mt.rc
> lcms2mt/config.guess
> psi/int.mak
> psi/zcolor.c
> psi/zpaint.c

2020-01-10 16:50:08 +0000
Robin Watts <Robin.Watts@artifex.com>
5faf010d8e043d77ff10f3deee466e9fb2dc7b7e

> Bug 702032: Fix overflow problem in scan converter.
> Very wide regions to be filled (> 0x80000000) can cause problems
> with overflow in clipping calculations, causing regions to be
> filled 'the wrong way' (i.e. from -ve to x rather than from x to
> +ve).
> Fix this by tweaking calculations to promote to 64bit 1 step
> earlier than before.
> base/gxscanc.c

2020-01-10 11:56:54 +0000
Julian Smith <jules@op59.net>
419f528cf8625a7e2989068324e962c498c255ef

> Coverity 94984: disabled code that had no affect other than to cause a coverity issue.
> contrib/gdevgdi.c

2020-01-09 17:14:57 +0000
Julian Smith <jules@op59.net>
e3c394504318a9a6774d65c386842d3f568126ce

> Coverity 94488: improved detection of uninitialised Jbig2HuffmanEntry.
> When checking for an incorrect uninitialised entry, test for /either/ of
> <flags> and <PREFLEN> being -1.
> Previously we tested for /all/ of <flags>, <PREFLEN> and <entry->u.RANGELOW>
> being -1, which made coverity think that the following code could be run with
> PREFLEN=-1, which then triggers issue about illegal shifts.
> [It seems that <entry->u.RANGELOW> can be -1 in normal operation, so have
> excluded from the new test.]
> jbig2dec/jbig2_huffman.c

2020-01-09 15:09:58 +0000
Julian Smith <jules@op59.net>
a9c19743cf5bc787ebbcbbff58c5cce0c923d0cc

> Coverity 94740: added /* Fall through. */ comment.
> contrib/lips4/gdevl4r.c

2020-01-09 15:07:21 +0000
Julian Smith <jules@op59.net>
7ee0bc7749eb7c2726bb593637de7653e2b62f10

> Coverity 94747: removed 'if' with duplicate code.
> contrib/lips4/gdevl4v.c

2020-01-09 14:40:54 +0000
Julian Smith <jules@op59.net>
ccd8370b09531128634b3f5bab76b1de426ab116

> Coverity 94809: added /* Fall through. */ comment.
> contrib/eplaser/gdevescv.c

2020-01-09 14:26:05 +0000
Julian Smith <jules@op59.net>
f563ab707b6068a653fb917974fb1e6a88c068d8

> Coverity 121439: use gx_color_index instead of uint, to avoid overflow when shifting.
> contrib/pcl3/eprn/eprnrend.c

2020-01-09 14:21:01 +0000
Julian Smith <jules@op59.net>
3acc9babb87048dda29ab766ca41750fc6f58eaf

> Coverity 94905: disabled code that had no affect other than to cause a coverity issue.
> contrib/gdevgdi.c

2020-01-09 11:32:11 +0000
Julian Smith <jules@op59.net>
bd6f5232dbaaa372b9fdcdb98134af8096c807be

> Coverity 95087: use cast to indicate intermediate integer division is expected.
> contrib/japanese/gdevmjc.c

2020-01-09 12:17:49 +0000
Chris Liddell <chris.liddell@artifex.com>
78773b740b3c0095fb4c5df59390f0eea84a6a49

> Docs: Fix a link to a long gone file.
> Reword the "What if I'm writing documentation?" so it makes some sense.
> doc/Readme.htm

2019-12-17 15:50:13 +0000
Chris Liddell <chris.liddell@artifex.com>
1075fd1caba19e642c9713c3a07961c0a3f0f88d

> Improve the English in section on Unicode TTFs
> doc/Use.htm

2020-01-08 12:13:35 +0000
Julian Smith <jules@op59.net>
af1fe01f44f528fb1322cfcf1b48aa5e1aa76059

> Coverity 95007: propogate error from eprn_check_colour_info().
> contrib/pcl3/eprn/gdeveprn.c
> contrib/pcl3/eprn/gdeveprn.h
> contrib/pcl3/src/gdevpcl3.c

2020-01-08 14:25:52 +0000
Julian Smith <jules@op59.net>
e0a0c0ca0e16e8b598a7839011df4c3374ab561d

> clusterpush.pl: also exclude luratech* directories.
> toolbin/localcluster/clusterpush.pl

2020-01-08 13:08:07 +0000
Julian Smith <jules@op59.net>
aba372d8efa1ffdb11a496474f519b0015b31031

> Coverity 94665: removed unnecessary if and refactored expression.
> contrib/gdevdj9.c

2020-01-08 13:04:41 +0000
Julian Smith <jules@op59.net>
5e1685812864cfde94a5c0daee0cae3307078aa7

> Coverity 94713: added {...} to match indentation.
> contrib/lips4/gdevl4v.c

2020-01-08 13:02:35 +0000
Julian Smith <jules@op59.net>
3b727b709f40d6b93e874680ab307aa124de5422

> Coverity 94729: oki4w_print_page()'s compress_code is always 2.
> Simplified code accordingly, and removed static fn oki_compress() as no longer
> referenced.
> contrib/gdevop4w.c

2020-01-08 12:41:57 +0000
Julian Smith <jules@op59.net>
4e4edd2161b4b7f3ccb23a90a8ca90dccffd078c

> Coverity 94757: avoid 'if (foo) return code; return code;' construct.
> This code is slightly odd, and didn't want to make major changes, so have ended
> up with odd-looking extended expression whose actual value we ignore.
> contrib/gdevbjc_.c

2020-01-08 12:31:50 +0000
Julian Smith <jules@op59.net>
cef68e9a0ca0be10f08e415785f8b8fac37d7828

> Coverity 94778: added missing {...}.
> contrib/lips4/gdevl4v.c

2020-01-08 12:28:15 +0000
Julian Smith <jules@op59.net>
c517f26773cd3a63f029b1bf6e275b227e3af5e8

> Coverity 94811: added break in switch block.
> contrib/gdevlx32.c

2020-01-08 12:25:54 +0000
Julian Smith <jules@op59.net>
0c84b20c653444310c979a5df78542e9671a6692

> Coverity 94846: don't dereference <data> without checking it isn't NULL.
> contrib/pcl3/src/pclgen.c

2020-01-08 12:18:02 +0000
Julian Smith <jules@op59.net>
87c48dabcdb64262fc0d24ed81b38d28e7545cb2

> Coverity 95006: improved use preprocessor to hopefully fix this warning.
> contrib/opvp/gdevopvp.c

2020-01-08 11:58:50 +0000
Julian Smith <jules@op59.net>
4c1e5ac5d9def3cbe25c52c63a3d5ba11f2603ac

> Coverity 121439: avoid overflow when shifting.
> contrib/pcl3/eprn/eprnrend.c

2020-01-08 11:58:14 +0000
Julian Smith <jules@op59.net>
f71ebb708947e57eaf7cd33b319ec0676e03ba2e

> Coverity 121442: avoid overflow when shifting.
> contrib/opvp/gdevopvp.c

2020-01-08 11:41:50 +0000
Julian Smith <jules@op59.net>
4bb071925d68398f8efb493c6b529e897a9bc356

> Coverity 350199: fix coverity annotation arg number.
> base/scfe.c

2020-01-07 19:43:07 +0000
Robin Watts <Robin.Watts@artifex.com>
d24553cea74bda19ae7e3dd5a60302fdc49d1fb2

> Fix indentation problems in examples in API.htm
> doc/API.htm

2020-01-06 16:30:17 +0000
Ken Sharp <ken.sharp@artifex.com>
147591b7a8390d0e98418851b60ac67e659cf2f1

> PDF interpreter - don't abort on errors in JBIG2 globals
> This was due to Julian's work on comparing jbig2dec with Luratech.
> The test file 'normal_716.pdf' and the cluster test file
> jbig2_null_segments_and_glyphs.pdf throw errors when trying to read
> the JBIG2 globals dictionary. Luratech doesn't cache the globals, while
> jbig2dec does, and the problem was that jbig2dec was returning an error
> at a point where the PDF interpreter wasn't able to ignore it, while
> Luratech deferred the error to a later point, at a time when the
> interpreter could, and did, ignore it.
> This meant that Luratech continued to render any further content on the
> page while jbig2dec did not, resulting in diffs.
> This commit simply runs the global context extraction in a stopped
> context. If it fails we clean up the stack and exit, which (effectively)
> defers the error to the same point as the Luratech decoder.
> Resource/Init/pdf_base.ps

2020-01-06 12:56:52 +0000
Robin Watts <Robin.Watts@artifex.com>
9a2414c7f88ef07cb9297bdeb3236cdba44c25ad

> Bug 702018: Fix CAL build crash in tiffsep1.
> The SSE code for CAL currently only copes with a maximum of 4
> planes. Ensure the device falls back to non-CAL code in such
> cases.
> devices/gdevtsep.c

2020-01-06 11:40:37 +0000
Robin Watts <Robin.Watts@artifex.com>
1085ead1dd22e3908c341df160a722e71a9c7cfe

> Fix VS2019 project getting many x64 builds wrong.
> windows/GhostPDL.sln

2020-01-06 08:22:00 +0000
Chris Liddell <chris.liddell@artifex.com>
c53f9d984015b65bf234d65befa552fe9d18c886

> Bug 702019: fix dependencies for cups devs and gdevp14
> Any "printer" device depends on the low level 'page' device (page.dev),
> unaccountably, the cups devices (cups and pwgraster) did not have that
> dependency in the makefiles.
> Also, the PDF transparency compositor now (and for some time) has also depended
> upon page.dev, so update the makefiles for that, too.
> base/lib.mak
> devices/devs.mak

2020-01-04 20:04:03 -0800
Ray Johnston <ray.johnston@artifex.com>
d1aa5fdfdbea4c55445ee1bdbe08b822a1bd7a8c

> Further refinement for Bug 701880. Make tiffsep better match pbmraw
> The previous change attempted to fix the y-phase, but this was not a
> 180 degree rotation, so it caused the primary angle of the pattern to
> shift by 90 degrees. A better correspondence is achieved by inverting
> the polarity of the thresholds. This is slightly "darker" than pbmraw
> but the angle and phase matches pbmraw closely.
> Note that the phase using the CAL module does not match the non-CAL
> or pbmraw, but the angle of the pattern does match.
> devices/gdevtsep.c

2020-01-03 09:56:29 -0800
Ray Johnston <ray.johnston@artifex.com>
372c862f2050d82248316f54156e5bb33dd7520a

> Fix Bug 701845. The devicen device would confuse transparency.
> The devicen device defines 32-bit depth, but 0 components and no
> standard process colors or names. This confused the pdf14 device into
> writing a clist with 1-component (gray), but then because the icc_profile
> had 4 components, would try and use 4 component when reading.
> Fix by making it 32-bit CMYK, and also fix to write a valid PCX by
> converting the 32-bit CMYK to 24-bit RGB on output. PCX cannot handle
> 32-bit CMYK. Prior to this, 32-bit CMYK would fail showpage with a
> rangecheck error.
> base/gdevdevn.c

2020-01-03 15:51:00 +0000
Robin Watts <Robin.Watts@artifex.com>
9608d275bd750b189dd52681791f31617a640817

> Use CAL halftoning in tiffsep1 post processing.
> A quick back to back test with/without cal using:
> bin/gswin32c.exe -sDEVICE=tiffsep1 -o out.tif -r600 -dMaxBitmap=80000000
> examples/tiger.eps
> shows timings of 1.142s vs 1.297s on my machine.
> devices/devs.mak
> devices/gdevtsep.c

2020-01-03 15:52:41 +0000
Robin Watts <Robin.Watts@artifex.com>
59ed026565b5be1bd055d0fbd1b066b8c07274e0

> Squash warnings (dropped from earlier commit).
> These warnings were supposed to have been squashed a few
> commits ago, but somehow got lost in a rebase. Thus they
> were mentioned in the commit message, but didn't make it
> in.
> Avoid problems with 'errno' being a special thing that
> shouldn't be used as a parameter name.
> Explicitly cast time_t to long for printing.
> base/gsioram.c
> base/mkromfs.c
> base/pack_ps.c

2020-01-03 10:21:18 +0000
Ken Sharp <ken.sharp@artifex.com>
d7d012bfe6c8f248db8b8474743618c53318ce40

> PDF interpreter - increase robustness in face of invalid annotations
> Bug #702016 "Invalid annotation causing an error"
> The PDF file has an annotation where the creating application has
> inserted the appearance stream directly into the annotation dictionary.
> This breaks the code which attempts to parse the annotation dictionary
> from an indirect reference into a dictionary object.
> This commit tries to recover from such egregiously broken situations by
> running the 'oforce' in a stopped context. This is complicated firstly
> by the fact that we parse the annotation dictionary in two places, once
> to check it for the presence of transparency and once to actually draw
> it (if we are rendering annotations).
> In addition, the code could potentially leave anything on the stack, so
> we can't use a mark/cleartomark pair to tidy up. Instead, use a
> (hopefully) unique name object, create it on the stack and in the case
> of an error, unwind the stack back to the expected name.
> Finally, report the error to the user in a more or less meaningnful way.
> Resource/Init/pdf_main.ps

2019-12-13 12:40:44 +0000
Robin Watts <Robin.Watts@artifex.com>
92031bd1fb9084088a657b7d83339bf499dcc7d2

> Update Visual Studio solution to VS2019.
> Our belief is that this should work in all versions of VS from
> 2010 onwards.
> By moving to VS2019, we lose support totally for Windows XP prior
> to SP3. If this is a problem, either build using the Makefile, or
> pull the old VS2005 solution out of git and use that. If customers
> find this to be a problem, we can maintain the old VS2005 solution
> alongside the new one with minimal effort.
> Default builds lose support for Windows XP SP3/Windows Server 2003,
> but the new "ReleaseXP", "DebugXP" and "MementoXP" configurations
> will target these platforms (assuming the v141 tools have been
> installed too).
> These "XP" binaries will be build into {,debug,mem}objxp directories
> and will produce binaries with an 'XP' suffix: i.e.
> {,debug,mem}bin/{gs,gpcl6,gxps,gpdl}win{32,32}{,c}xp.exe.
> psi/msvc.mak
> windows/All.vcxproj
> windows/GhostPDL.sln
> windows/ghostpcl.vcxproj
> windows/ghostpcl.vcxproj.filters
> windows/ghostpdl.vcxproj
> windows/ghostpdl.vcxproj.filters
> windows/ghostscript.vcxproj
> windows/ghostscript.vcxproj.filters
> windows/ghostxps.vcxproj
> windows/ghostxps.vcxproj.filters

2019-12-16 18:18:47 +0000
Robin Watts <Robin.Watts@artifex.com>
10d2678613d5a93bedc094a62b1b98972871f464

> Tweak windows Makefiles to know about VS2017 and VS2019.
> These builds have only been tested with "DEVSTUDIO=" (i.e.
> relying on the paths to the compilers etc having been set up
> in advance, such as happens when building from within the IDE
> using the supplied solution). Logic has been added for
> command like nmake builds, but this hasn't been tested.
> Update the makefiles to avoid using flags that aren't supported
> in later versions.
> base/msvccmd.mak
> base/msvclib.mak
> psi/msvc.mak

2020-01-02 11:01:03 +0000
Robin Watts <Robin.Watts@artifex.com>
00cd7c475b173e5cdce7e1e4ff3f0880e1e70583

> Squash warnings
> Don't define STRICT multiple times.
> Explicitly cast time_t's in printfs.
> Avoid warnings due to errno being a #defined thing.
> base/windows_.h

2019-12-26 13:14:43 -0800
Ray Johnston <ray.johnston@artifex.com>
bf689ee0bff720f202ebc98f301c765f34e2c1fa

> Bug 701880: tiffsep1 threshold_from_order caused dots in full white.
> For patterns with > 256 dots, threshold_from_order would put in 0 value
> cells which would then always be imaged. Change this device to (finally)
> use the gx_ht_construct_threshold used by the fast_ht thresholding code
> so that it should match the other devices, such as pbmraw.
> Also vertically invert the use of the threshold array to match the dots
> of the other devices.
> Add missing dependencies for gdevtsep.c in devs.mak
> devices/devs.mak
> devices/gdevtsep.c

2019-12-19 09:22:32 -0800
Nancy Durgin <nancy.durgin@artifex.com>
97ac0f6ef4010e0a49bf6f8f4515c32a5695df68

> PDF interpreter -- take out manually drawn rectfill
> We can now just draw the rectangle directly with rectfill.
> Whatever issue ken ran into 5 years ago no longer applies.
> See also Bug 693731
> Resource/Init/pdf_draw.ps

2019-12-18 14:46:26 +0000
Ken Sharp <ken.sharp@artifex.com>
719bf1f2c4104d933767d37e62489535e8ba9a17

> pdfwrite - use correct FontFile key
> This was found as part of bug #701997, even if we set -dCompatibilityLevel
> to 1.1, so that type 1 fonts are not converted to type 2 (1c, CFF) we
> would still write out a FontFile3 key, instead of the correct
> FontFile key.
> Ghostscript doesn't care about this, but Acrobat refuses to parse the
> font from the file when it has the wrong FontFile key.
> The test we were using was incorrect anyway, we were checking
> ResourcesBeforeUsgae and we should have been checking HaveCFF because
> if HaveCFF is true we would convert type 1 to CFF, and if it isn't we
> wouldn't.
> devices/vector/gdevpdtb.c

2019-12-16 09:52:13 +0000
Ken Sharp <ken.sharp@artifex.com>
bb47dd4128481c2e62bbd6b5e354da8299f2f16b

> PDF interpreter - use PDFDocEncoding for fonts in text annotations
> Bug #701889 ""
> We were often not applying PDFDocEncoding to fonts when we used them to
> draw text for annotations. This commit re-encodes the selected font
> which will give a better result.
> We probably should also check for UTF16-BE text and use the FallBack
> CIDFont in that case, but we'll wait for an example before trying to
> code that.
> Resource/Init/pdf_draw.ps

2019-12-14 19:13:27 +0000
Ken Sharp <ken.sharp@artifex.com>
c3b184c41144a2650e5520643bbb1cff42c18acc

> PDF interpreter - fix line ending positions on Line annotations
> Bug #701889 "Annotation objects missing or incorrectly interpreted when appearance stream missing"
> The calculation of the position of the line ending was incorrect, and
> we were applying the wrong LE entry to each end of the line.
> Resource/Init/pdf_draw.ps

2019-12-14 15:24:57 +0000
Ken Sharp <ken.sharp@artifex.com>
1246085e17ee35928f737f1fbf69d69fe6b7a2ae

> PDF interpreter - Add arrows to /CL lines in FreeText annotations
> Bug #701889 "Annotation objects missing or incorrectly interpreted when appearance stream missing"
> Add arrowheads to the ends of callout lines.
> Resource/Init/pdf_draw.ps

2019-12-13 15:13:58 +0000
Ken Sharp <ken.sharp@artifex.com>
acccfd2fe90e25534e7d492ca2378dc32269e48e

> PDF interpreter - Fix multi-line FreeText annotation with /Rotate 270
> The calculation of the 'width' of the container for the text was
> incorrect, as was the starting x co-ordinate. Fixed here.
> Resource/Init/pdf_draw.ps

2019-12-13 11:55:15 +0000
Ken Sharp <ken.sharp@artifex.com>
5e5f7b41c080bdbd15fac5afbd09052a83e81a01

> PDF interpreter - apply /C to more annotation types
> Bug #701889 "Annotation objects missing or incorrectly interpreted when appearance stream missing"
> Seems we also need to apply the /C colour to Polygon, Square and Circle
> annotations before drawing them.
> Resource/Init/pdf_draw.ps

2019-12-13 11:23:28 +0000
Ken Sharp <ken.sharp@artifex.com>
4940c5cb80916017d3ee0c9b53475323cf5ebbd6

> PDF interpreter - more annotation improvements
> Bug #701889 "Annotation objects missing or incorrectly interpreted when appearance stream missing"
> Apply the /RD array (if present) to the annotation /Rect before using
> the Rect to draw the border.
> We were using the /C array in drawborder to set the colour before
> stroking the border, there are two problems with this; firstly the /C
> array is not used to specify a border colour, secondly we need to set
> the colour for certain objects irrespective of whether they have a
> border.
> Remove annotsetcolor from drawborder and apply it to Squiggly, Strikeout,
> Underline, Highlight, Line and Ink annotations in order to set the
> colour before drawing the annotation. The specification says that this
> is used for; the border of a Link annotation, the title bar of a
> pop-up annotation's pop-up and the background of the annotation's icon
> when closed, but in fact Acrobat also uses it to set the colour for all
> the annotation types listed above.
> There may still be more work needing done here, but this matches all the
> test cases I currently have.
> Resource/Init/pdf_draw.ps

2019-12-12 17:04:17 +0000
Ken Sharp <ken.sharp@artifex.com>
d95dd7a23f25e73042f3c8e6043c83285387d0a1

> PDF interpreter - apply RD array to Circle, Square and FreeText, apply Rotate to FreeText
> Bug #701889 "Annotation objects missing or incorrectly interpreted when appearance stream missing"
> The /RD array makes certain kinds of annotations be drawn in a smaller
> area. Although the spec does not mention it, Acrobat applies the
> /Rotate key if found to the text in a FreeText annotation.
> Still more to do on the text; we are nto fitting the text correctly
> when Rotate is 270, not certain why. Also we are not drawing Borders
> when we should, some text is missing and text is in the wrong colour
> (due to not applying /DS)
> Resource/Init/pdf_draw.ps

2019-12-12 19:47:18 +0000
Robin Watts <Robin.Watts@artifex.com>
f25987c838ea9437b60f8b3b93f90e187013b641

> Tweak CAL makefile to include new intrinsics headers in dependencies.
> base/cal.mak

2019-12-12 15:44:30 +0000
Robin Watts <Robin.Watts@artifex.com>
321cf6026a05e31140a87cc83a2653b048550df4

> Fix arch.h dependency in cal build.
> This was causing parallel makes of CAL enabled builds to
> fail.
> base/cal.mak

2019-11-29 17:48:29 +0000
Robin Watts <Robin.Watts@artifex.com>
b6f6adb5448fda1f33db4c92c030709618e4ee54

> Support for YCbCr, LogL, LOGLUV and paletted TIFFs.
> YCbCr TIFFs have to use TIFFRGBAImage as for the old JPEG
> encapsulation.
> gpdl/tifftop.c

2019-11-28 22:32:43 +0000
Robin Watts <Robin.Watts@artifex.com>
ae1cee743e56a7b654d9dbb2ea88ed90d48d298d

> Further fixes for GPDL TIFF.
> Support JPEG encoded TIFFs (both old and new formats).
> Old JPEG format requires the whole image to be decoded to an
> RGBAImage in memory at once; looks like that's just a limitation
> of libtiff. This is particularly annoying because it looks like
> the internals of libtiff are prepared to do scanline extraction
> as you'd hope, but aren't exposed to the outside world.
> base/msvclib.mak
> base/tiff.mak
> configure.ac
> gpdl/gpdl.mak
> gpdl/tifftop.c
> psi/msvc.mak

2019-12-12 17:26:02 +0000
Robin Watts <Robin.Watts@artifex.com>
ef66198ade77d5d551b3045cd36bed81c0b04f54

> Changes to libtiff for gpdl.
> 1) Ensure that libtiff doesn't mess with 'boolean' in GS builds
> on Windows. Without this, the jpeg structures used by our JPEG
> lib build are different in size when called from gs and libtiff,
> resulting in runtime errors.
> 2) Update libtiff so that it can correctly call into the jpeg
> library so that memory operations happen from our pools, not
> malloc/free. Slightly horrid in that this is more complex with
> OJPEG than JPEG files.
> tiff/libtiff/tif_jpeg.c
> tiff/libtiff/tif_ojpeg.c
> tiff/libtiff/tif_open.c
> tiff/libtiff/tiffio.h
> tiff/libtiff/tiffiop.h

2019-11-28 10:52:49 +0000
Robin Watts <Robin.Watts@artifex.com>
0c248ced8997dfe8f253a07fc6cc5f47837ca12e

> Fixes for GPDL TIFF support.
> Support tiled TIFFs, planar TIFFs, and TIFFs where the resolution
> isn't properly specified.
> gpdl/tifftop.c

2019-12-12 14:33:27 +0000
Chris Liddell <chris.liddell@artifex.com>
76bd0d75823a571130f340ab6231e064d1f997f7

> Move pdf_info.ps into lib (from toolbin)
> And add it to the list of files to install on Unix systems.
> Also, tweak the comments in pdf_info.ps to reflect its new home.
> base/unixinst.mak
> lib/pdf_info.ps

2019-12-12 14:26:30 +0000
Chris Liddell <chris.liddell@artifex.com>
e39d57f23585b6fe71db5433dc205459be7a3c22

> Tweak to handle .shellarguments throwing an error
> .shellarguments for quite some time has thrown an undefined error if Ghostscript
> is not invoked with the '--' option, so handle that.
> toolbin/pdf_info.ps

2019-12-12 14:16:41 +0000
Chris Liddell <chris.liddell@artifex.com>
72f6dd34cd0732cb7cdd9246d5063fc0f70ce79b

> Add hex string representation of font names
> Mainly CIDFonts come up with multibyte characters in their names, hence making
> the normal Postscript string pretty meaningless. This adds a hex string
> representation which can be used in Fontmap.GS or cidfmap for subsitution.
> toolbin/pdf_info.ps

2019-12-12 13:07:46 +0000
Chris Liddell <chris.liddell@artifex.com>
bcb6fb284fcbe776d9ddd44f98d196da7df2c054

> Add NDEBUG to the optimised build flags
> Without that, asserts get included in an optimised build, which we don't want.
> base/unix-gcc.mak
> base/unixansi.mak
> configure.ac
> psi/msvc.mak

2019-12-10 15:37:35 +0000
Chris Liddell <chris.liddell@artifex.com>
044848a1752273471e9deab826045eca82030d62

> Reinstate basic regular expression compatibility
> In Basic Regular Expressions `+' is an ordinary character, use `*' instead.
> This also maintains consistency with the equivalent code a few lines above in
> the file.
> jbig2dec/autogen.sh

2019-12-09 03:00:42 +0000
Ken Sharp <ken.sharp@artifex.com>
35828fce7ad795c546831520b7a57ef233453b43

> txtwrite - don't close the device on media size changes
> Bug #701971 "txtwrite incomplete for certain files and differs when stdout versus file is output"
> The problem is nothing to do with stdout vs file. The difference is due
> to the fact that the input PDF file has multiple pages with different
> media sizes. When the media size is changed the default put_params()
> method closes and reopens the device. When the txtwrite device is
> closed it closes its output file. Re-opening the device opens a new
> file, if the filename doesn not have a %d then the sam file is opened
> which will of course truncate it.
> Writing to stdout obviously doesn't have this behaviour when the output
> file is closed.
> We don't need to close the txtwrite device when the media size changes
> so here we patch the 'is_open' flag to prevent the default method
> from closing the device.
> devices/vector/gdevtxtw.c

2019-12-06 21:45:09 +0000
Chris Liddell <chris.liddell@artifex.com>
b46142c94bde32f620bda18e3bc5912fbf999446

> Bug 701973: Fix gssprintf.c includes for PRI macros
> The header inclusion in gssprintf.c meant the definitions of the PRI macros
> for string formatting could be inconsistent with other source files.
> Adding the appropriate headers in the correct order resolves that issue.
> base/gssprintf.c
> base/lib.mak

2019-12-06 21:44:13 +0000
Chris Liddell <chris.liddell@artifex.com>
a4c78f01d9a1bd9862b575f33aa48afddd167005

> Fix configure based build for post-Sun Solaris releases
> base/stdint_.h
> configure.ac

2019-12-07 15:02:15 +0000
Ken Sharp <ken.sharp@artifex.com>
3bf992e26006c8af9e137822159eb7c7540462c0

> PDF interpreter - Accept /ColorSpace as well as /CS in group attribute dictionary
> Again, no bug report, the customer has asked that the file be kept
> confidential
> The problem is due to a group attribute dictionary for an SMask. The
> dictionary is required to contain a /CS (colour space) entry in order
> to correctly set the background. In this case, however, the dictionary
> contains a /ColorSpace entry.
> I've chosen to implement treating the /ColorSpace as a /CS entry, this
> is not what Acrobat does, but mimicking Acrobat's behaviour is more or
> less impossible for us. We do emit a warning.
> Resource/Init/pdf_draw.ps

2019-12-06 18:43:28 +0000
Ken Sharp <ken.sharp@artifex.com>
539fe73419fdf00ffd7747a2cf890e56bc6f0504

> PDF interpreter - cope with legal but sub-optimal indirect /Pattern
> No bug, the report is from a customer who wants the file to be treated
> confidentially.
> The files uses a Pattern colour space, which it defines in a highly
> peculiar fashion:
> stream
> ....
> /CS0 cs /P0 scn
> ....
> endstream
> CS0 is defined as:
> /CS0 22 0 R
> and object 22 is:
> 22 0 obj
> [ 23 0 R ]
> endobj
> 23 0 obj
> /Pattern
> endobj
> The PDF interpreter wasn't prepared to handle the name being an indirect
> reference.
> Resource/Init/pdf_draw.ps

2019-11-21 09:54:53 -0800
Ray Johnston <ray.johnston@artifex.com>
5dfca9b93a17806e11d54068a6e5b9705f3b6bc6

> Fix problem with setup_trans being undone by grestore
> Noticed with text from Bug688728.pdf, but the offending method was
> also an issue with 'sh' and 'image' operations where the setup_trans
> invocation was withing a gsave ... grestore. The BlendMode and other
> graphics state parameters would be reset by the grestore.
> Also some places could get errors from pathbbox and/or strokepath
> due to a non-invertable matrix, so errors from these now just emit
> an empty bbox [ 0 0 0 0 ].
> Resource/Init/pdf_draw.ps
> Resource/Init/pdf_main.ps
> Resource/Init/pdf_ops.ps

2019-12-05 12:50:26 +0000
Chris Liddell <chris.liddell@artifex.com>
fbd776580b26bdf27bcf5778dea94b446c786f67

> Coverity ID 351435: reduce buffer size passed to strncat()
> Fixes an (unlikely) potential buffer overflow
> base/gp_unix.c

2019-12-04 12:23:02 +0000
Chris Liddell <chris.liddell@artifex.com>
53ab3ecee8a60d412c2bf1406340bf9cb228e106

> Bug 701969: Fix fontconfig path permissions handling
> The paths from fontconfig to be added to the permit file reading list was not
> having the trailing directory separator added to indicate we want to allow
> the directory to be read.
> Also, tweak the path/filename splitting (for the permit file read list) when
> parsing the cidfmap so it matches the improved version in gs_fonts.ps
> Resource/Init/gs_cidfm.ps
> base/gp_unix.c

2019-12-02 18:24:09 +0000
Ken Sharp <ken.sharp@artifex.com>
c25d59001421845d0ff74735388d450d62b459d5

> PDF interpreter - improve /Polygon annotation appearance creation
> Bug #701889 "Annotation objects missing or incorrectly interpreted when appearance missing"
> Another case of failing to stroke the border of an annotation if it had
> no interior colour. We still don't support the 'Cloudy' Border Effect.
> Resource/Init/pdf_draw.ps

2019-12-02 17:59:34 +0000
Ken Sharp <ken.sharp@artifex.com>
11f6202373fc546cc10d08acfb5ca0463df20437

> PDF interpreter - generate callout (/CL) lines for FreeText annots
> Bug #701889 "Annotation objects missing or incorrectly interpreted when appearance is missing"
> FreeText annotations can have a /CL (callout) entry, which defines a
> line to be drawn to the point referenced by the text.
> This is a first pass at the problem, Acrobat generates arrow heads for
> the callout lines, this patch does not.
> Resource/Init/pdf_draw.ps

2019-12-02 17:19:00 +0000
Ken Sharp <ken.sharp@artifex.com>
182e228cee6b30c6e2f00d8abd20a6791d44323f

> PDF interpreter - improve /Square annotation appearance creation
> Bug #701889 "Annotation objects missing or incorrectly interpreted when appearance stream missing"
> First of probably several changes. In this case we were failing to
> stroke the border of a /Square annotation if it had no interior colour
> (we did not render the annotation at all).
> In addition, when element 3 of the Border array was 0 we were still
> drawing a Border, which we should not do (this didn't show up until we
> fixed the problem above).
> Resource/Init/pdf_draw.ps

2019-12-01 22:04:21 +0000
Chris Liddell <chris.liddell@artifex.com>
c535c0c879162ccd7c88c5b8cc6c3a0847c0babe

> Create devdevs.tr correctly
> devdevs.tr is an interim list of output and core library "devs" that gets
> created and then used, ultimately, to create the gconfig.h header file
> (which has the bulid configuration of the graphics library), and the linker
> scripts.
> When devdevs.tr required creation, we were always appending to the file (if it
> already existed), not overwriting it, meaning the list would grow indefinitely,
> and contain duplicates.
> This looks like a typo: the first line of devdevs.tr creation used a '-a'
> echogs paramater, rather than the '-w' parameter.
> I think this should solve the problem.
> base/gs.mak

2019-12-01 21:55:48 +0000
Chris Liddell <chris.liddell@artifex.com>
aa4fa650fa837a6f7b22caad33699bbbf9156bc1

> Bug 701957: Explicitly disable webp and ztsd for libtiff
> configure.ac

2019-11-29 08:42:15 -0800
Ray Johnston <ray.johnston@artifex.com>
c2b492ad627bdcb476fa3cd15a1c31cc3b6b788d

> Fix typo (inadvertent paste) in devices/gdevjbig2.c from f63270230 commit
> devices/gdevjbig2.c

2019-11-29 14:40:47 +0000
Julian Smith <jules@op59.net>
8636935ac086f56464f0541ed735f1016f2c3895

> Coverity 94659: removed cp_num - was allocated but never actually used.
> contrib/opvp/gdevopvp.c

2019-11-29 14:35:25 +0000
Julian Smith <jules@op59.net>
a3f284624a68dcb1ecb72dcf307b42d194e78de1

> Coverity 94653: fixed incorrect if() that was logically dead code.
> contrib/lips4/gdevl4v.c

2019-11-29 14:15:57 +0000
Julian Smith <jules@op59.net>
ff02f8741f71830e7a4795645680a16b9d7ae106

> Coverity 94652: return error from opvp_image_plane_data() rather than segv.
> contrib/opvp/gdevopvp.c

2019-11-29 12:40:02 +0000
Julian Smith <jules@op59.net>
f977255de00bb71f5c2627b8692912bb3263ee48

> Coverity 94645: added '/* Fall through. */ comments to switch statements.
> This should convince Coverity that the fall-through's are intentional.
> contrib/lips4/gdevl4r.c

2019-11-29 12:38:10 +0000
Julian Smith <jules@op59.net>
f877f5bc792206085f9edf4143983d4156fb3ae5

> Coverity 94638: added '/* Fall through. */ comments to switch statements.
> This should convince Coverity that the fall-through's are intentional.
> contrib/gdevmd2k.c

2019-11-29 12:33:51 +0000
Julian Smith <jules@op59.net>
39286afa21126c193fcd0f3ccc0800f7c0662ed0

> Coverity 94616: added '/* Fall through. */ comments to switch statements
> This should convince Coverity that the fall-through's are intentional.
> contrib/gdevgdi.c

2019-11-29 12:30:57 +0000
Julian Smith <jules@op59.net>
1c899fc1100f21f6e24096375e2daac26b23f33b

> Coverity 94608: added '/* Fall through. */ comments to switch statements.
> This should convince Coverity that the fall-through's are intentional.
> contrib/lips4/gdevl4v.c

2019-11-29 12:10:19 +0000
Julian Smith <jules@op59.net>
adbf399b79b3e6b645e98acd53f42f9fd5ca9174

> Coverity 94601: avoid out-of-bounds access of gendata->dev->hoffset[] if newhead < 0.
> contrib/gdevlx32.c

2019-11-29 11:41:05 +0000
Julian Smith <jules@op59.net>
1d04fe90a4c3b82e1286a1b341cdb89a96625715

> Coverity 94490: check return codes in opvp_fill_mask().
> contrib/opvp/gdevopvp.c

2019-11-28 18:26:56 +0000
Julian Smith <jules@op59.net>
fbd78a0467afb2c66a41d55ee9b3aee0a7a01d7b

> Coverity 94511: Use full range of frac when source is 8-bit.
> Essentially we use frac2byte() and byte2frac(), instead of frac2cv() and
> cv2frac(). This ensures we use full range of frac with the transfer fns.
> Note that this change is untested. It is based on observation and discussion
> between gs develpoers. This code has not been modified since initial import.
> contrib/opvp/gdevopvp.c

2019-11-28 17:00:08 +0000
Julian Smith <jules@op59.net>
a537e5bd4252abdbdc3f90dfdce8dc9fb621b38d

> Coverity 94505: converted macros into static fns.
> This should avoid Coverity worrying about bits 8-15 always being zero in a call
> of write_short().
> contrib/gdevmd2k.c

2019-11-28 16:34:49 +0000
Julian Smith <jules@op59.net>
35e0c3f70ba2646b4bdfb41663a708a8594eeb68

> Coverity 94553: fixed possible copy&paste error in lips4_image_out().
> Use Len_rle instead of Len inside RLE block.
> contrib/lips4/gdevl4r.c

2019-11-28 16:08:23 +0000
Julian Smith <jules@op59.net>
792c922fc83aed63090fb37ffc823e75ec8f9c5c

> Coverity 95077: fixed various scan-build issues with contrib/japanese/gdevmjc.c.
> Some of these will correspond to coverity issues also.
> contrib/japanese/gdevmjc.c

2019-11-28 15:44:05 +0000
Julian Smith <jules@op59.net>
efff831b1f3a00c69a32b4edd48614d583f9034a

> Coverity 95077: removed unused assignment to <H> variable.
> contrib/japanese/gdevmjc.c

2019-11-28 12:05:43 +0000
Julian Smith <jules@op59.net>
94190ff3e48c36a8538a3aba252e2b56909f6984

> Coverity 95034: avoid warnings about ignoring return from gs_note_error().
> contrib/pcl3/src/gdevpcl3.c

2019-11-28 11:32:14 +0000
Julian Smith <jules@op59.net>
c9f669385954f205d395cbacb2b611d659b3ebf9

> Coverity 350199: add '-tainted_data_return' annotation.
> This makes this annotation match what has worked elsewhere.
> base/scfe.c

2019-11-28 14:36:52 +0000
Chris Liddell <chris.liddell@artifex.com>
fd2b1946fe5a4a8c029324c15f9bd606a489f543

> Include the source file libtiff webp compression support
> If the webp lib is available, it could cause linker failures if we don't
> include the source file.
> base/tiff.mak

2019-11-28 11:29:03 +0000
Chris Liddell <chris.liddell@artifex.com>
874ef8cf7f0af2efae3d7fb6598013be5d277384

> Enable jpeg support in libtiff if possible
> base/tiff.mak
> configure.ac
> psi/msvc.mak

2019-11-27 15:29:04 +0000
Julian Smith <jules@op59.net>
15f3faeffff7d1b2658b824262314091f7af088b

> Coverity 95034: move code so that we have one less call to pcl_cm_is_differential().
> fixes scan-build issue, e.g.:
> scan-build -o ../scan-build-out make sanitize
> contrib/pcl3/src/gdevpcl3.c

2019-11-27 15:27:25 +0000
Julian Smith <jules@op59.net>
6e8c15137a70012776c1b163d7480e1a2cc7c61b

> Coverity 95034: removed use of guard() macro.
> Instead use static fn to convert error codes, with explicit inline code.
> contrib/pcl3/src/gdevpcl3.c

2019-11-27 14:29:41 +0000
Julian Smith <jules@op59.net>
7e1c4da27805ab9b545bc8ab5b0747c37b69454c

> Coverity 95034: refactor pcl3_print_page() to avoid leaks.
> contrib/pcl3/src/gdevpcl3.c

2019-11-27 13:11:29 +0000
Julian Smith <jules@op59.net>
1df794e69d9f29dae215e50cf328ccad40fe29e8

> Coverity 95027: fix off-by-one when bounds-checking against LIPS_MEDIACHAR_MAX.
> contrib/lips4/gdevl4r.c

2019-11-27 12:52:17 +0000
Julian Smith <jules@op59.net>
e9ccb4139c5f3fb89a5f4d6554e73323dbf73641

> Coverity 94957: Call dlclose() to avoid leaks of handles from dlopen().
> contrib/opvp/gdevopvp.c

2019-11-27 11:39:28 +0000
Julian Smith <jules@op59.net>
e4dcc70672b447df52b0a3c7976ab6ece280841e

> Coverity 350199: mark cf_encode_1d() as not tainting lbuf.
> This may work better than the previous annotation.
> base/scfe.c

2019-11-26 12:04:54 -0800
Ray Johnston <ray.johnston@artifex.com>
334132f45320ef35b54032c053c100d07e02ec98

> Fix problems seen with m8510 device and improve gdev_prn_copy_scan_lines
> Previous patch made this device pay attention to return code from the
> gdev_prn_copy_scan_lines, which caused the all_devices test to get an error.
> Also this device would get an ioerror if the page width was not a multiple
> of 8. Fix m8510_output_run to round up when setting out_end, bullet proof
> check of count so we don't try and print with a negative count.
> Also fix gdev_prn_copy_scan_lines to return count == 0 if the starting
> line is past the end of the page, and fill lines past end of page with
> zeroes if the count did not fill it (or if there was an error from
> gdev_prn_get_bits).
> base/gdevprn.c
> devices/gdev8510.c

2019-11-26 14:43:58 +0000
Robin Watts <Robin.Watts@artifex.com>
23b4705f975ee0d4288ad47e62ffb8737ced48a8

> GPDL PNG support
> gpdl/gpdl.mak
> gpdl/jp2ktop.c
> gpdl/pngtop.c
> pcl/pl/plimpl.c
> windows/ghostpdl.vcproj

2019-11-26 14:35:05 +0000
Robin Watts <Robin.Watts@artifex.com>
b772aaf901a3cd37baf5c06eb141c689829bf673

> Bug 701949: Add 'omitEOD' flag to RLE compressor and use for PXL.
> It turns out that some printers (Samsung ML-2250 and Canon
> ImageRunner iRC2380i at least) object to the EOD byte appearing
> in RLE data in PXL streams.
> Ken kindly checked the PXL spec for me, and found that: "The PXL
> spec does say a control code of -128 is ignored and not included
> in the decompressed data and the byte following a control byte
> of 128 (I assume they mean -128 here) is treated as the next
> control byte. And PCL only uses RLE data for images, so they do
> know how much data they expect."
> Thus, the conclusion we reached is that PCL/PXL don't need
> (indeed, really does not want) the EOD byte.
> The Postscript spec clearly defines the EOD byte though. Rather
> than break the streams for postscript, we introduce a flag
> 'omitEOD' that can be set for the encoder when we want to produce
> a stream for use with PCL/PXL.
> base/srle.c
> base/srlx.h
> devices/vector/gdevpx.c
> psi/zfilter.c

2019-11-27 13:27:35 +0000
Chris Liddell <chris.liddell@artifex.com>
c9ed069d86f291dc3118ee96f76765432ac478e3

> Update thirdparty.htm to reflect updated libs
> doc/thirdparty.htm

2019-11-26 14:39:02 +0000
Chris Liddell <chris.liddell@artifex.com>
79ac3f84060fbd5447219264ab0bcf89c7caa2cf

> Update Freetype to 2.4.10
> Plus makefile updates to support it
> Bug 701288: Handle SEAC ligature glyph metrics correctly.
> As originally intended, a Type 1 SEAC charstring would be used for an accented
> glyph (like an a-caron, or u-umlaut) where the advance with of the SEAC glyph
> is the same as that of the 'base' glyph ('a' or 'u').
> It this case, it is not uncommon for the SEAC to skip using an (H)SBW op code
> and rely on the one from the base glyph.
> But out of spec fonts also use SEAC glyphs ligature glyphs (like 'oe' or 'fi'),
> and in those cases the overall advance width is greater than that of the 'base'
> glyph.
> In this case, we have to allow for the SEAC glyph having included an (H)SBW and
> if it has, retain those values, rather than those from the base glyph.
> Rename file and make file change to match
> Avoids file name clash with freetype 2.4.10
> Work around a change in the zlib API for 1.2.11
> where it's used in the Freetype/zlib interface debugging code.
> base/freetype.mak
> base/lcupsi.mak
> cups/libs/filter/cupsraster.c
> freetype/CMakeLists.txt
> freetype/ChangeLog
> freetype/ChangeLog.20
> freetype/ChangeLog.21
> freetype/ChangeLog.22
> freetype/ChangeLog.23
> freetype/ChangeLog.24
> freetype/ChangeLog.25
> freetype/ChangeLog.26
> freetype/ChangeLog.27
> freetype/ChangeLog.28
> freetype/ChangeLog.29
> freetype/Jamfile
> freetype/Jamrules
> freetype/Makefile
> freetype/README
> freetype/README.git
> freetype/autogen.sh
> freetype/builds/amiga/README
> freetype/builds/amiga/include/config/ftconfig.h
> freetype/builds/amiga/include/config/ftmodule.h
> freetype/builds/amiga/makefile
> freetype/builds/amiga/makefile.os4
> freetype/builds/amiga/smakefile
> freetype/builds/amiga/src/base/ftdebug.c
> freetype/builds/amiga/src/base/ftsystem.c
> freetype/builds/ansi/ansi-def.mk
> freetype/builds/ansi/ansi.mk
> freetype/builds/beos/beos-def.mk
> freetype/builds/beos/beos.mk
> freetype/builds/beos/detect.mk
> freetype/builds/cmake/iOS.cmake
> freetype/builds/cmake/testbuild.sh
> freetype/builds/compiler/ansi-cc.mk
> freetype/builds/compiler/bcc-dev.mk
> freetype/builds/compiler/bcc.mk
> freetype/builds/compiler/emx.mk
> freetype/builds/compiler/gcc-dev.mk
> freetype/builds/compiler/gcc.mk
> freetype/builds/compiler/intelc.mk
> freetype/builds/compiler/unix-lcc.mk
> freetype/builds/compiler/visualage.mk
> freetype/builds/compiler/visualc.mk
> freetype/builds/compiler/watcom.mk
> freetype/builds/compiler/win-lcc.mk
> freetype/builds/detect.mk
> freetype/builds/dos/detect.mk
> freetype/builds/dos/dos-def.mk
> freetype/builds/dos/dos-emx.mk
> freetype/builds/dos/dos-gcc.mk
> freetype/builds/dos/dos-wat.mk
> freetype/builds/exports.mk
> freetype/builds/freetype.mk
> freetype/builds/link_dos.mk
> freetype/builds/link_std.mk
> freetype/builds/mac/README
> freetype/builds/mac/freetype-Info.plist
> freetype/builds/mac/ftmac.c
> freetype/builds/modules.mk
> freetype/builds/os2/detect.mk
> freetype/builds/os2/os2-def.mk
> freetype/builds/os2/os2-dev.mk
> freetype/builds/os2/os2-gcc.mk
> freetype/builds/symbian/bld.inf
> freetype/builds/symbian/freetype.mmp
> freetype/builds/toplevel.mk
> freetype/builds/unix/aclocal.m4
> freetype/builds/unix/config.guess
> freetype/builds/unix/config.sub
> freetype/builds/unix/configure
> freetype/builds/unix/configure.ac
> freetype/builds/unix/configure.raw
> freetype/builds/unix/detect.mk
> freetype/builds/unix/freetype-config.in
> freetype/builds/unix/freetype2.m4
> freetype/builds/unix/ft-munmap.m4
> freetype/builds/unix/ftconfig.in
> freetype/builds/unix/ftsystem.c
> freetype/builds/unix/install-sh
> freetype/builds/unix/install.mk
> freetype/builds/unix/ltmain.sh
> freetype/builds/unix/unix-cc.in
> freetype/builds/unix/unix-def.in
> freetype/builds/unix/unix-dev.mk
> freetype/builds/unix/unix-lcc.mk
> freetype/builds/unix/unix.mk
> freetype/builds/unix/unixddef.mk
> freetype/builds/vms/LIBS.OPT_IA64
> freetype/builds/vms/_LINK.OPT_IA64
> freetype/builds/vms/ftconfig.h
> freetype/builds/vms/ftsystem.c
> freetype/builds/vms/vmslib.dat
> freetype/builds/wince/ftdebug.c
> freetype/builds/wince/vc2005-ce/freetype.vcproj
> freetype/builds/wince/vc2005-ce/index.html
> freetype/builds/wince/vc2008-ce/freetype.vcproj
> freetype/builds/wince/vc2008-ce/index.html
> freetype/builds/windows/detect.mk
> freetype/builds/windows/ftdebug.c
> freetype/builds/windows/vc2005/freetype.sln
> freetype/builds/windows/vc2005/freetype.vcproj
> freetype/builds/windows/vc2005/index.html
> freetype/builds/windows/vc2008/freetype.sln
> freetype/builds/windows/vc2008/freetype.vcproj
> freetype/builds/windows/vc2008/index.html
> freetype/builds/windows/vc2010/freetype.vcxproj
> freetype/builds/windows/vc2010/freetype.vcxproj.filters
> freetype/builds/windows/vc2010/index.html
> freetype/builds/windows/visualc/freetype.dsp
> freetype/builds/windows/visualc/freetype.sln
> freetype/builds/windows/visualc/freetype.vcproj
> freetype/builds/windows/visualc/index.html
> freetype/builds/windows/visualce/freetype.dsp
> freetype/builds/windows/visualce/freetype.vcproj
> freetype/builds/windows/visualce/index.html
> freetype/builds/windows/w32-bcc.mk
> freetype/builds/windows/w32-bccd.mk
> freetype/builds/windows/w32-dev.mk
> freetype/builds/windows/w32-gcc.mk
> freetype/builds/windows/w32-icc.mk
> freetype/builds/windows/w32-intl.mk
> freetype/builds/windows/w32-lcc.mk
> freetype/builds/windows/w32-mingw32.mk
> freetype/builds/windows/w32-vcc.mk
> freetype/builds/windows/w32-wat.mk
> freetype/builds/windows/win32-def.mk
> freetype/configure
> freetype/devel/ft2build.h
> freetype/devel/ftoption.h
> freetype/docs/CHANGES
> freetype/docs/CUSTOMIZE
> freetype/docs/DEBUG
> freetype/docs/DOCGUIDE
> freetype/docs/INSTALL
> freetype/docs/INSTALL.ANY
> freetype/docs/INSTALL.CROSS
> freetype/docs/INSTALL.GNU
> freetype/docs/INSTALL.UNIX
> freetype/docs/INSTALL.VMS
> freetype/docs/MAKEPP
> freetype/docs/TODO
> freetype/docs/VERSIONS.TXT
> freetype/docs/formats.txt
> freetype/docs/freetype-config.1
> freetype/docs/raster.txt
> freetype/docs/reference/README
> freetype/docs/reference/ft2-auto_hinter.html
> freetype/docs/reference/ft2-base_interface.html
> freetype/docs/reference/ft2-basic_types.html
> freetype/docs/reference/ft2-bdf_fonts.html
> freetype/docs/reference/ft2-bitmap_handling.html
> freetype/docs/reference/ft2-bzip2.html
> freetype/docs/reference/ft2-cache_subsystem.html
> freetype/docs/reference/ft2-cff_driver.html
> freetype/docs/reference/ft2-cid_fonts.html
> freetype/docs/reference/ft2-computations.html
> freetype/docs/reference/ft2-error_code_values.html
> freetype/docs/reference/ft2-error_enumerations.html
> freetype/docs/reference/ft2-font_formats.html
> freetype/docs/reference/ft2-gasp_table.html
> freetype/docs/reference/ft2-glyph_management.html
> freetype/docs/reference/ft2-glyph_stroker.html
> freetype/docs/reference/ft2-glyph_variants.html
> freetype/docs/reference/ft2-gx_validation.html
> freetype/docs/reference/ft2-gzip.html
> freetype/docs/reference/ft2-header_file_macros.html
> freetype/docs/reference/ft2-header_inclusion.html
> freetype/docs/reference/ft2-incremental.html
> freetype/docs/reference/ft2-index.html
> freetype/docs/reference/ft2-lcd_filtering.html
> freetype/docs/reference/ft2-list_processing.html
> freetype/docs/reference/ft2-lzw.html
> freetype/docs/reference/ft2-mac_specific.html
> freetype/docs/reference/ft2-module_management.html
> freetype/docs/reference/ft2-multiple_masters.html
> freetype/docs/reference/ft2-ot_validation.html
> freetype/docs/reference/ft2-outline_processing.html
> freetype/docs/reference/ft2-parameter_tags.html
> freetype/docs/reference/ft2-pcf_driver.html
> freetype/docs/reference/ft2-pfr_fonts.html
> freetype/docs/reference/ft2-properties.html
> freetype/docs/reference/ft2-quick_advance.html
> freetype/docs/reference/ft2-raster.html
> freetype/docs/reference/ft2-sfnt_names.html
> freetype/docs/reference/ft2-sizes_management.html
> freetype/docs/reference/ft2-system_interface.html
> freetype/docs/reference/ft2-t1_cid_driver.html
> freetype/docs/reference/ft2-toc.html
> freetype/docs/reference/ft2-truetype_engine.html
> freetype/docs/reference/ft2-truetype_tables.html
> freetype/docs/reference/ft2-tt_driver.html
> freetype/docs/reference/ft2-type1_tables.html
> freetype/docs/reference/ft2-user_allocation.html
> freetype/docs/reference/ft2-version.html
> freetype/docs/reference/ft2-winfnt_fonts.html
> freetype/docs/reference/site/404.html
> freetype/docs/reference/site/assets/fonts/font-awesome.css
> freetype/docs/reference/site/assets/fonts/material-icons.css
> freetype/docs/reference/site/assets/fonts/specimen/FontAwesome.ttf
> freetype/docs/reference/site/assets/fonts/specimen/FontAwesome.woff
> freetype/docs/reference/site/assets/fonts/specimen/FontAwesome.woff2
> freetype/docs/reference/site/assets/fonts/specimen/MaterialIcons-Regular.ttf
> freetype/docs/reference/site/assets/fonts/specimen/MaterialIcons-Regular.woff
> freetype/docs/reference/site/assets/fonts/specimen/MaterialIcons-Regular.woff2
> freetype/docs/reference/site/assets/images/favicon.png
> freetype/docs/reference/site/assets/images/icons/bitbucket.1b09e088.svg
> freetype/docs/reference/site/assets/images/icons/github.f0b8504a.svg
> freetype/docs/reference/site/assets/images/icons/gitlab.6dd19c00.svg
> freetype/docs/reference/site/assets/javascripts/application.d9aa80ab.js
> freetype/docs/reference/site/assets/javascripts/lunr/lunr.da.js
> freetype/docs/reference/site/assets/javascripts/lunr/lunr.de.js
> freetype/docs/reference/site/assets/javascripts/lunr/lunr.du.js
> freetype/docs/reference/site/assets/javascripts/lunr/lunr.es.js
> freetype/docs/reference/site/assets/javascripts/lunr/lunr.fi.js
> freetype/docs/reference/site/assets/javascripts/lunr/lunr.fr.js
> freetype/docs/reference/site/assets/javascripts/lunr/lunr.hu.js
> freetype/docs/reference/site/assets/javascripts/lunr/lunr.it.js
> freetype/docs/reference/site/assets/javascripts/lunr/lunr.ja.js
> freetype/docs/reference/site/assets/javascripts/lunr/lunr.jp.js
> freetype/docs/reference/site/assets/javascripts/lunr/lunr.multi.js
> freetype/docs/reference/site/assets/javascripts/lunr/lunr.nl.js
> freetype/docs/reference/site/assets/javascripts/lunr/lunr.no.js
> freetype/docs/reference/site/assets/javascripts/lunr/lunr.pt.js
> freetype/docs/reference/site/assets/javascripts/lunr/lunr.ro.js
> freetype/docs/reference/site/assets/javascripts/lunr/lunr.ru.js
> freetype/docs/reference/site/assets/javascripts/lunr/lunr.stemmer.support.js
> freetype/docs/reference/site/assets/javascripts/lunr/lunr.sv.js
> freetype/docs/reference/site/assets/javascripts/lunr/lunr.th.js
> freetype/docs/reference/site/assets/javascripts/lunr/lunr.tr.js
> freetype/docs/reference/site/assets/javascripts/lunr/tinyseg.js
> freetype/docs/reference/site/assets/javascripts/lunr/wordcut.js
> freetype/docs/reference/site/assets/javascripts/modernizr.1f0bcf2b.js
> freetype/docs/reference/site/assets/stylesheets/application-palette.224b79ff.css
> freetype/docs/reference/site/assets/stylesheets/application.982221ab.css
> freetype/docs/reference/site/ft2-auto_hinter.html
> freetype/docs/reference/site/ft2-base_interface.html
> freetype/docs/reference/site/ft2-basic_types.html
> freetype/docs/reference/site/ft2-bdf_fonts.html
> freetype/docs/reference/site/ft2-bitmap_handling.html
> freetype/docs/reference/site/ft2-bzip2.html
> freetype/docs/reference/site/ft2-cache_subsystem.html
> freetype/docs/reference/site/ft2-cff_driver.html
> freetype/docs/reference/site/ft2-cid_fonts.html
> freetype/docs/reference/site/ft2-color_management.html
> freetype/docs/reference/site/ft2-computations.html
> freetype/docs/reference/site/ft2-error_code_values.html
> freetype/docs/reference/site/ft2-error_enumerations.html
> freetype/docs/reference/site/ft2-font_formats.html
> freetype/docs/reference/site/ft2-gasp_table.html
> freetype/docs/reference/site/ft2-glyph_management.html
> freetype/docs/reference/site/ft2-glyph_stroker.html
> freetype/docs/reference/site/ft2-glyph_variants.html
> freetype/docs/reference/site/ft2-gx_validation.html
> freetype/docs/reference/site/ft2-gzip.html
> freetype/docs/reference/site/ft2-header_file_macros.html
> freetype/docs/reference/site/ft2-header_inclusion.html
> freetype/docs/reference/site/ft2-incremental.html
> freetype/docs/reference/site/ft2-index.html
> freetype/docs/reference/site/ft2-layer_management.html
> freetype/docs/reference/site/ft2-lcd_rendering.html
> freetype/docs/reference/site/ft2-list_processing.html
> freetype/docs/reference/site/ft2-lzw.html
> freetype/docs/reference/site/ft2-mac_specific.html
> freetype/docs/reference/site/ft2-module_management.html
> freetype/docs/reference/site/ft2-multiple_masters.html
> freetype/docs/reference/site/ft2-ot_validation.html
> freetype/docs/reference/site/ft2-outline_processing.html
> freetype/docs/reference/site/ft2-parameter_tags.html
> freetype/docs/reference/site/ft2-pcf_driver.html
> freetype/docs/reference/site/ft2-pfr_fonts.html
> freetype/docs/reference/site/ft2-properties.html
> freetype/docs/reference/site/ft2-quick_advance.html
> freetype/docs/reference/site/ft2-raster.html
> freetype/docs/reference/site/ft2-sfnt_names.html
> freetype/docs/reference/site/ft2-sizes_management.html
> freetype/docs/reference/site/ft2-system_interface.html
> freetype/docs/reference/site/ft2-t1_cid_driver.html
> freetype/docs/reference/site/ft2-truetype_engine.html
> freetype/docs/reference/site/ft2-truetype_tables.html
> freetype/docs/reference/site/ft2-tt_driver.html
> freetype/docs/reference/site/ft2-type1_tables.html
> freetype/docs/reference/site/ft2-user_allocation.html
> freetype/docs/reference/site/ft2-version.html
> freetype/docs/reference/site/ft2-winfnt_fonts.html
> freetype/docs/reference/site/images/favico.ico
> freetype/docs/reference/site/index.html
> freetype/docs/reference/site/javascripts/extra.js
> freetype/docs/reference/site/search/search_index.json
> freetype/docs/reference/site/sitemap.xml
> freetype/docs/reference/site/sitemap.xml.gz
> freetype/docs/reference/site/stylesheets/extra.css
> freetype/docs/release
> freetype/include/freetype/config/ftconfig.h
> freetype/include/freetype/config/ftheader.h
> freetype/include/freetype/config/ftmodule.h
> freetype/include/freetype/config/ftoption.h
> freetype/include/freetype/config/ftstdlib.h
> freetype/include/freetype/freetype.h
> freetype/include/freetype/ftadvanc.h
> freetype/include/freetype/ftbbox.h
> freetype/include/freetype/ftbdf.h
> freetype/include/freetype/ftbitmap.h
> freetype/include/freetype/ftbzip2.h
> freetype/include/freetype/ftcache.h
> freetype/include/freetype/ftchapters.h
> freetype/include/freetype/ftcid.h
> freetype/include/freetype/ftcolor.h
> freetype/include/freetype/ftdriver.h
> freetype/include/freetype/fterrdef.h
> freetype/include/freetype/fterrors.h
> freetype/include/freetype/ftfntfmt.h
> freetype/include/freetype/ftgasp.h
> freetype/include/freetype/ftglyph.h
> freetype/include/freetype/ftgxval.h
> freetype/include/freetype/ftgzip.h
> freetype/include/freetype/ftimage.h
> freetype/include/freetype/ftincrem.h
> freetype/include/freetype/ftlcdfil.h
> freetype/include/freetype/ftlist.h
> freetype/include/freetype/ftlzw.h
> freetype/include/freetype/ftmac.h
> freetype/include/freetype/ftmm.h
> freetype/include/freetype/ftmodapi.h
> freetype/include/freetype/ftmoderr.h
> freetype/include/freetype/ftotval.h
> freetype/include/freetype/ftoutln.h
> freetype/include/freetype/ftparams.h
> freetype/include/freetype/ftpfr.h
> freetype/include/freetype/ftrender.h
> freetype/include/freetype/ftsizes.h
> freetype/include/freetype/ftsnames.h
> freetype/include/freetype/ftstroke.h
> freetype/include/freetype/ftsynth.h
> freetype/include/freetype/ftsystem.h
> freetype/include/freetype/fttrigon.h
> freetype/include/freetype/fttypes.h
> freetype/include/freetype/ftwinfnt.h
> freetype/include/freetype/internal/autohint.h
> freetype/include/freetype/internal/cffotypes.h
> freetype/include/freetype/internal/cfftypes.h
> freetype/include/freetype/internal/ftcalc.h
> freetype/include/freetype/internal/ftdebug.h
> freetype/include/freetype/internal/ftdrv.h
> freetype/include/freetype/internal/ftgloadr.h
> freetype/include/freetype/internal/fthash.h
> freetype/include/freetype/internal/ftmemory.h
> freetype/include/freetype/internal/ftobjs.h
> freetype/include/freetype/internal/ftpic.h
> freetype/include/freetype/internal/ftpsprop.h
> freetype/include/freetype/internal/ftrfork.h
> freetype/include/freetype/internal/ftserv.h
> freetype/include/freetype/internal/ftstream.h
> freetype/include/freetype/internal/fttrace.h
> freetype/include/freetype/internal/ftvalid.h
> freetype/include/freetype/internal/internal.h
> freetype/include/freetype/internal/psaux.h
> freetype/include/freetype/internal/pshints.h
> freetype/include/freetype/internal/services/svbdf.h
> freetype/include/freetype/internal/services/svcfftl.h
> freetype/include/freetype/internal/services/svcid.h
> freetype/include/freetype/internal/services/svfntfmt.h
> freetype/include/freetype/internal/services/svgldict.h
> freetype/include/freetype/internal/services/svgxval.h
> freetype/include/freetype/internal/services/svkern.h
> freetype/include/freetype/internal/services/svmetric.h
> freetype/include/freetype/internal/services/svmm.h
> freetype/include/freetype/internal/services/svotval.h
> freetype/include/freetype/internal/services/svpfr.h
> freetype/include/freetype/internal/services/svpostnm.h
> freetype/include/freetype/internal/services/svprop.h
> freetype/include/freetype/internal/services/svpscmap.h
> freetype/include/freetype/internal/services/svpsinfo.h
> freetype/include/freetype/internal/services/svsfnt.h
> freetype/include/freetype/internal/services/svttcmap.h
> freetype/include/freetype/internal/services/svtteng.h
> freetype/include/freetype/internal/services/svttglyf.h
> freetype/include/freetype/internal/services/svwinfnt.h
> freetype/include/freetype/internal/sfnt.h
> freetype/include/freetype/internal/t1types.h
> freetype/include/freetype/internal/tttypes.h
> freetype/include/freetype/internal/wofftypes.h
> freetype/include/freetype/t1tables.h
> freetype/include/freetype/ttnameid.h
> freetype/include/freetype/tttables.h
> freetype/include/freetype/tttags.h
> freetype/include/ft2build.h
> freetype/modules.cfg
> freetype/src/Jamfile
> freetype/src/autofit/Jamfile
> freetype/src/autofit/afangles.c
> freetype/src/autofit/afangles.h
> freetype/src/autofit/afblue.c
> freetype/src/autofit/afblue.cin
> freetype/src/autofit/afblue.dat
> freetype/src/autofit/afblue.h
> freetype/src/autofit/afblue.hin
> freetype/src/autofit/afcjk.c
> freetype/src/autofit/afcjk.h
> freetype/src/autofit/afcover.h
> freetype/src/autofit/afdummy.c
> freetype/src/autofit/afdummy.h
> freetype/src/autofit/aferrors.h
> freetype/src/autofit/afglobal.c
> freetype/src/autofit/afglobal.h
> freetype/src/autofit/afhints.c
> freetype/src/autofit/afhints.h
> freetype/src/autofit/afindic.c
> freetype/src/autofit/afindic.h
> freetype/src/autofit/aflatin.c
> freetype/src/autofit/aflatin.h
> freetype/src/autofit/aflatin2.c
> freetype/src/autofit/aflatin2.h
> freetype/src/autofit/afloader.c
> freetype/src/autofit/afloader.h
> freetype/src/autofit/afmodule.c
> freetype/src/autofit/afmodule.h
> freetype/src/autofit/afpic.c
> freetype/src/autofit/afpic.h
> freetype/src/autofit/afranges.c
> freetype/src/autofit/afranges.h
> freetype/src/autofit/afscript.h
> freetype/src/autofit/afshaper.c
> freetype/src/autofit/afshaper.h
> freetype/src/autofit/afstyles.h
> freetype/src/autofit/aftypes.h
> freetype/src/autofit/afwarp.c
> freetype/src/autofit/afwarp.h
> freetype/src/autofit/afwrtsys.h
> freetype/src/autofit/autofit.c
> freetype/src/autofit/module.mk
> freetype/src/autofit/rules.mk
> freetype/src/base/Jamfile
> freetype/src/base/basepic.c
> freetype/src/base/basepic.h
> freetype/src/base/ftadvanc.c
> freetype/src/base/ftapi.c
> freetype/src/base/ftbase.c
> freetype/src/base/ftbase.h
> freetype/src/base/ftbbox.c
> freetype/src/base/ftbdf.c
> freetype/src/base/ftbitmap.c
> freetype/src/base/ftcalc.c
> freetype/src/base/ftcid.c
> freetype/src/base/ftcolor.c
> freetype/src/base/ftdbgmem.c
> freetype/src/base/ftdebug.c
> freetype/src/base/fterrors.c
> freetype/src/base/ftfntfmt.c
> freetype/src/base/ftfstype.c
> freetype/src/base/ftgasp.c
> freetype/src/base/ftgloadr.c
> freetype/src/base/ftglyph.c
> freetype/src/base/ftgxval.c
> freetype/src/base/fthash.c
> freetype/src/base/ftinit.c
> freetype/src/base/ftlcdfil.c
> freetype/src/base/ftmac.c
> freetype/src/base/ftmm.c
> freetype/src/base/ftobjs.c
> freetype/src/base/ftotval.c
> freetype/src/base/ftoutln.c
> freetype/src/base/ftpatent.c
> freetype/src/base/ftpfr.c
> freetype/src/base/ftpic.c
> freetype/src/base/ftpsprop.c
> freetype/src/base/ftrfork.c
> freetype/src/base/ftsnames.c
> freetype/src/base/ftstream.c
> freetype/src/base/ftstroke.c
> freetype/src/base/ftsynth.c
> freetype/src/base/ftsystem.c
> freetype/src/base/fttrigon.c
> freetype/src/base/fttype1.c
> freetype/src/base/ftutil.c
> freetype/src/base/ftver.rc
> freetype/src/base/ftwinfnt.c
> freetype/src/base/rules.mk
> freetype/src/bdf/Jamfile
> freetype/src/bdf/bdf.h
> freetype/src/bdf/bdfdrivr.c
> freetype/src/bdf/bdfdrivr.h
> freetype/src/bdf/bdferror.h
> freetype/src/bdf/bdflib.c
> freetype/src/bzip2/Jamfile
> freetype/src/bzip2/ftbzip2.c
> freetype/src/bzip2/rules.mk
> freetype/src/cache/Jamfile
> freetype/src/cache/ftcache.c
> freetype/src/cache/ftcbasic.c
> freetype/src/cache/ftccache.c
> freetype/src/cache/ftccache.h
> freetype/src/cache/ftccback.h
> freetype/src/cache/ftccmap.c
> freetype/src/cache/ftcerror.h
> freetype/src/cache/ftcglyph.c
> freetype/src/cache/ftcglyph.h
> freetype/src/cache/ftcimage.c
> freetype/src/cache/ftcimage.h
> freetype/src/cache/ftcmanag.c
> freetype/src/cache/ftcmanag.h
> freetype/src/cache/ftcmru.c
> freetype/src/cache/ftcmru.h
> freetype/src/cache/ftcsbits.c
> freetype/src/cache/ftcsbits.h
> freetype/src/cache/rules.mk
> freetype/src/cff/Jamfile
> freetype/src/cff/cff.c
> freetype/src/cff/cffcmap.c
> freetype/src/cff/cffcmap.h
> freetype/src/cff/cffdrivr.c
> freetype/src/cff/cffdrivr.h
> freetype/src/cff/cfferrs.h
> freetype/src/cff/cffgload.c
> freetype/src/cff/cffgload.h
> freetype/src/cff/cffload.c
> freetype/src/cff/cffload.h
> freetype/src/cff/cffobjs.c
> freetype/src/cff/cffobjs.h
> freetype/src/cff/cffparse.c
> freetype/src/cff/cffparse.h
> freetype/src/cff/cffpic.c
> freetype/src/cff/cffpic.h
> freetype/src/cff/cfftoken.h
> freetype/src/cff/module.mk
> freetype/src/cff/rules.mk
> freetype/src/cid/Jamfile
> freetype/src/cid/ciderrs.h
> freetype/src/cid/cidgload.c
> freetype/src/cid/cidgload.h
> freetype/src/cid/cidload.c
> freetype/src/cid/cidload.h
> freetype/src/cid/cidobjs.c
> freetype/src/cid/cidobjs.h
> freetype/src/cid/cidparse.c
> freetype/src/cid/cidparse.h
> freetype/src/cid/cidriver.c
> freetype/src/cid/cidriver.h
> freetype/src/cid/cidtoken.h
> freetype/src/cid/module.mk
> freetype/src/cid/rules.mk
> freetype/src/cid/type1cid.c
> freetype/src/gxvalid/Jamfile
> freetype/src/gxvalid/README
> freetype/src/gxvalid/gxvalid.c
> freetype/src/gxvalid/gxvalid.h
> freetype/src/gxvalid/gxvbsln.c
> freetype/src/gxvalid/gxvcommn.c
> freetype/src/gxvalid/gxvcommn.h
> freetype/src/gxvalid/gxverror.h
> freetype/src/gxvalid/gxvfeat.c
> freetype/src/gxvalid/gxvfeat.h
> freetype/src/gxvalid/gxvfgen.c
> freetype/src/gxvalid/gxvjust.c
> freetype/src/gxvalid/gxvkern.c
> freetype/src/gxvalid/gxvlcar.c
> freetype/src/gxvalid/gxvmod.c
> freetype/src/gxvalid/gxvmod.h
> freetype/src/gxvalid/gxvmort.c
> freetype/src/gxvalid/gxvmort.h
> freetype/src/gxvalid/gxvmort0.c
> freetype/src/gxvalid/gxvmort1.c
> freetype/src/gxvalid/gxvmort2.c
> freetype/src/gxvalid/gxvmort4.c
> freetype/src/gxvalid/gxvmort5.c
> freetype/src/gxvalid/gxvmorx.c
> freetype/src/gxvalid/gxvmorx.h
> freetype/src/gxvalid/gxvmorx0.c
> freetype/src/gxvalid/gxvmorx1.c
> freetype/src/gxvalid/gxvmorx2.c
> freetype/src/gxvalid/gxvmorx4.c
> freetype/src/gxvalid/gxvmorx5.c
> freetype/src/gxvalid/gxvopbd.c
> freetype/src/gxvalid/gxvprop.c
> freetype/src/gxvalid/gxvtrak.c
> freetype/src/gxvalid/module.mk
> freetype/src/gxvalid/rules.mk
> freetype/src/gzip/Jamfile
> freetype/src/gzip/ftgzip.c
> freetype/src/gzip/infblock.c
> freetype/src/gzip/infcodes.c
> freetype/src/gzip/inflate.c
> freetype/src/gzip/rules.mk
> freetype/src/lzw/Jamfile
> freetype/src/lzw/ftlzw.c
> freetype/src/lzw/ftzopen.c
> freetype/src/lzw/ftzopen.h
> freetype/src/lzw/rules.mk
> freetype/src/otvalid/Jamfile
> freetype/src/otvalid/module.mk
> freetype/src/otvalid/otvalid.c
> freetype/src/otvalid/otvalid.h
> freetype/src/otvalid/otvbase.c
> freetype/src/otvalid/otvcommn.c
> freetype/src/otvalid/otvcommn.h
> freetype/src/otvalid/otverror.h
> freetype/src/otvalid/otvgdef.c
> freetype/src/otvalid/otvgpos.c
> freetype/src/otvalid/otvgpos.h
> freetype/src/otvalid/otvgsub.c
> freetype/src/otvalid/otvjstf.c
> freetype/src/otvalid/otvmath.c
> freetype/src/otvalid/otvmod.c
> freetype/src/otvalid/otvmod.h
> freetype/src/otvalid/rules.mk
> freetype/src/pcf/Jamfile
> freetype/src/pcf/pcf.h
> freetype/src/pcf/pcfdrivr.c
> freetype/src/pcf/pcfdrivr.h
> freetype/src/pcf/pcferror.h
> freetype/src/pcf/pcfread.c
> freetype/src/pcf/pcfutil.c
> freetype/src/pfr/Jamfile
> freetype/src/pfr/module.mk
> freetype/src/pfr/pfr.c
> freetype/src/pfr/pfrcmap.c
> freetype/src/pfr/pfrcmap.h
> freetype/src/pfr/pfrdrivr.c
> freetype/src/pfr/pfrdrivr.h
> freetype/src/pfr/pfrerror.h
> freetype/src/pfr/pfrgload.c
> freetype/src/pfr/pfrgload.h
> freetype/src/pfr/pfrload.c
> freetype/src/pfr/pfrload.h
> freetype/src/pfr/pfrobjs.c
> freetype/src/pfr/pfrobjs.h
> freetype/src/pfr/pfrsbit.c
> freetype/src/pfr/pfrsbit.h
> freetype/src/pfr/pfrtypes.h
> freetype/src/pfr/rules.mk
> freetype/src/psaux/Jamfile
> freetype/src/psaux/afmparse.c
> freetype/src/psaux/afmparse.h
> freetype/src/psaux/cffdecode.c
> freetype/src/psaux/cffdecode.h
> freetype/src/psaux/module.mk
> freetype/src/psaux/psarrst.c
> freetype/src/psaux/psarrst.h
> freetype/src/psaux/psaux.c
> freetype/src/psaux/psauxerr.h
> freetype/src/psaux/psauxmod.c
> freetype/src/psaux/psauxmod.h
> freetype/src/psaux/psblues.c
> freetype/src/psaux/psblues.h
> freetype/src/psaux/psconv.c
> freetype/src/psaux/psconv.h
> freetype/src/psaux/pserror.c
> freetype/src/psaux/pserror.h
> freetype/src/psaux/psfixed.h
> freetype/src/psaux/psfont.c
> freetype/src/psaux/psfont.h
> freetype/src/psaux/psft.c
> freetype/src/psaux/psft.h
> freetype/src/psaux/psglue.h
> freetype/src/psaux/pshints.c
> freetype/src/psaux/pshints.h
> freetype/src/psaux/psintrp.c
> freetype/src/psaux/psintrp.h
> freetype/src/psaux/psobjs.c
> freetype/src/psaux/psobjs.h
> freetype/src/psaux/psread.c
> freetype/src/psaux/psread.h
> freetype/src/psaux/psstack.c
> freetype/src/psaux/psstack.h
> freetype/src/psaux/pstypes.h
> freetype/src/psaux/rules.mk
> freetype/src/psaux/t1cmap.c
> freetype/src/psaux/t1cmap.h
> freetype/src/psaux/t1decode.c
> freetype/src/psaux/t1decode.h
> freetype/src/pshinter/Jamfile
> freetype/src/pshinter/module.mk
> freetype/src/pshinter/pshalgo.c
> freetype/src/pshinter/pshalgo.h
> freetype/src/pshinter/pshglob.c
> freetype/src/pshinter/pshglob.h
> freetype/src/pshinter/pshinter.c
> freetype/src/pshinter/pshmod.c
> freetype/src/pshinter/pshmod.h
> freetype/src/pshinter/pshnterr.h
> freetype/src/pshinter/pshpic.c
> freetype/src/pshinter/pshpic.h
> freetype/src/pshinter/pshrec.c
> freetype/src/pshinter/pshrec.h
> freetype/src/pshinter/rules.mk
> freetype/src/psnames/Jamfile
> freetype/src/psnames/module.mk
> freetype/src/psnames/psmodule.c
> freetype/src/psnames/psmodule.h
> freetype/src/psnames/psnamerr.h
> freetype/src/psnames/psnames.c
> freetype/src/psnames/pspic.c
> freetype/src/psnames/pspic.h
> freetype/src/psnames/pstables.h
> freetype/src/psnames/rules.mk
> freetype/src/raster/Jamfile
> freetype/src/raster/ftmisc.h
> freetype/src/raster/ftraster.c
> freetype/src/raster/ftraster.h
> freetype/src/raster/ftrend1.c
> freetype/src/raster/ftrend1.h
> freetype/src/raster/module.mk
> freetype/src/raster/raster.c
> freetype/src/raster/rasterrs.h
> freetype/src/raster/rastpic.c
> freetype/src/raster/rastpic.h
> freetype/src/raster/rules.mk
> freetype/src/sfnt/Jamfile
> freetype/src/sfnt/module.mk
> freetype/src/sfnt/pngshim.c
> freetype/src/sfnt/pngshim.h
> freetype/src/sfnt/rules.mk
> freetype/src/sfnt/sfdriver.c
> freetype/src/sfnt/sfdriver.h
> freetype/src/sfnt/sferrors.h
> freetype/src/sfnt/sfnt.c
> freetype/src/sfnt/sfntpic.c
> freetype/src/sfnt/sfntpic.h
> freetype/src/sfnt/sfobjs.c
> freetype/src/sfnt/sfobjs.h
> freetype/src/sfnt/sfwoff.c
> freetype/src/sfnt/sfwoff.h
> freetype/src/sfnt/ttbdf.c
> freetype/src/sfnt/ttbdf.h
> freetype/src/sfnt/ttcmap.c
> freetype/src/sfnt/ttcmap.h
> freetype/src/sfnt/ttcmapc.h
> freetype/src/sfnt/ttcolr.c
> freetype/src/sfnt/ttcolr.h
> freetype/src/sfnt/ttcpal.c
> freetype/src/sfnt/ttcpal.h
> freetype/src/sfnt/ttkern.c
> freetype/src/sfnt/ttkern.h
> freetype/src/sfnt/ttload.c
> freetype/src/sfnt/ttload.h
> freetype/src/sfnt/ttmtx.c
> freetype/src/sfnt/ttmtx.h
> freetype/src/sfnt/ttpost.c
> freetype/src/sfnt/ttpost.h
> freetype/src/sfnt/ttsbit.c
> freetype/src/sfnt/ttsbit.h
> freetype/src/smooth/Jamfile
> freetype/src/smooth/ftgrays.c
> freetype/src/smooth/ftgrays.h
> freetype/src/smooth/ftsmerrs.h
> freetype/src/smooth/ftsmooth.c
> freetype/src/smooth/ftsmooth.h
> freetype/src/smooth/ftspic.c
> freetype/src/smooth/ftspic.h
> freetype/src/smooth/module.mk
> freetype/src/smooth/rules.mk
> freetype/src/smooth/smooth.c
> freetype/src/tools/afblue.pl
> freetype/src/tools/apinames.c
> freetype/src/tools/docmaker/content.py
> freetype/src/tools/docmaker/docbeauty.py
> freetype/src/tools/docmaker/docmaker.py
> freetype/src/tools/docmaker/formatter.py
> freetype/src/tools/docmaker/sources.py
> freetype/src/tools/docmaker/tohtml.py
> freetype/src/tools/docmaker/utils.py
> freetype/src/tools/ftfuzzer/README
> freetype/src/tools/ftfuzzer/ftfuzzer.cc
> freetype/src/tools/ftfuzzer/ftmutator.cc
> freetype/src/tools/ftfuzzer/rasterfuzzer.cc
> freetype/src/tools/ftfuzzer/runinput.cc
> freetype/src/tools/glnames.py
> freetype/src/tools/update-copyright-year
> freetype/src/truetype/Jamfile
> freetype/src/truetype/module.mk
> freetype/src/truetype/rules.mk
> freetype/src/truetype/truetype.c
> freetype/src/truetype/ttdriver.c
> freetype/src/truetype/ttdriver.h
> freetype/src/truetype/tterrors.h
> freetype/src/truetype/ttgload.c
> freetype/src/truetype/ttgload.h
> freetype/src/truetype/ttgxvar.c
> freetype/src/truetype/ttgxvar.h
> freetype/src/truetype/ttinterp.c
> freetype/src/truetype/ttinterp.h
> freetype/src/truetype/ttobjs.c
> freetype/src/truetype/ttobjs.h
> freetype/src/truetype/ttpic.c
> freetype/src/truetype/ttpic.h
> freetype/src/truetype/ttpload.c
> freetype/src/truetype/ttpload.h
> freetype/src/truetype/ttsubpix.c
> freetype/src/truetype/ttsubpix.h
> freetype/src/type1/Jamfile
> freetype/src/type1/module.mk
> freetype/src/type1/rules.mk
> freetype/src/type1/t1afm.c
> freetype/src/type1/t1afm.h
> freetype/src/type1/t1driver.c
> freetype/src/type1/t1driver.h
> freetype/src/type1/t1errors.h
> freetype/src/type1/t1gload.c
> freetype/src/type1/t1gload.h
> freetype/src/type1/t1load.c
> freetype/src/type1/t1load.h
> freetype/src/type1/t1objs.c
> freetype/src/type1/t1objs.h
> freetype/src/type1/t1parse.c
> freetype/src/type1/t1parse.h
> freetype/src/type1/t1tokens.h
> freetype/src/type1/type1.c
> freetype/src/type42/Jamfile
> freetype/src/type42/module.mk
> freetype/src/type42/rules.mk
> freetype/src/type42/t42drivr.c
> freetype/src/type42/t42drivr.h
> freetype/src/type42/t42error.h
> freetype/src/type42/t42objs.c
> freetype/src/type42/t42objs.h
> freetype/src/type42/t42parse.c
> freetype/src/type42/t42parse.h
> freetype/src/type42/t42types.h
> freetype/src/type42/type42.c
> freetype/src/winfonts/Jamfile
> freetype/src/winfonts/fnterrs.h
> freetype/src/winfonts/module.mk
> freetype/src/winfonts/rules.mk
> freetype/src/winfonts/winfnt.c
> freetype/src/winfonts/winfnt.h
> freetype/vms_make.com

2019-11-26 17:45:08 +0000
Chris Liddell <chris.liddell@artifex.com>
36cbd382b160ee4951d1911f85a4fa0723dd8db3

> Update openjpeg to 2.3.1
> openjpeg/.gitignore
> openjpeg/.travis.yml
> openjpeg/CHANGELOG.md
> openjpeg/INSTALL.md
> openjpeg/NEWS.md
> openjpeg/appveyor.yml
> openjpeg/doc/Doxyfile.dox.cmake.in
> openjpeg/src/bin/CMakeLists.txt
> openjpeg/src/bin/common/CMakeLists.txt
> openjpeg/src/bin/common/color.c
> openjpeg/src/bin/common/color.h
> openjpeg/src/bin/common/format_defs.h
> openjpeg/src/bin/common/opj_apps_config.h.cmake.in
> openjpeg/src/bin/common/opj_getopt.c
> openjpeg/src/bin/common/opj_getopt.h
> openjpeg/src/bin/common/opj_string.h
> openjpeg/src/bin/jp2/CMakeLists.txt
> openjpeg/src/bin/jp2/convert.c
> openjpeg/src/bin/jp2/convert.h
> openjpeg/src/bin/jp2/convertbmp.c
> openjpeg/src/bin/jp2/convertpng.c
> openjpeg/src/bin/jp2/converttif.c
> openjpeg/src/bin/jp2/index.c
> openjpeg/src/bin/jp2/index.h
> openjpeg/src/bin/jp2/opj_compress.c
> openjpeg/src/bin/jp2/opj_decompress.c
> openjpeg/src/bin/jp2/opj_dump.c
> openjpeg/src/bin/jp2/windirent.h
> openjpeg/src/bin/jp3d/CMakeLists.txt
> openjpeg/src/bin/jp3d/convert.c
> openjpeg/src/bin/jp3d/convert.h
> openjpeg/src/bin/jp3d/getopt.c
> openjpeg/src/bin/jp3d/getopt.h
> openjpeg/src/bin/jp3d/opj_jp3d_compress.c
> openjpeg/src/bin/jp3d/opj_jp3d_decompress.c
> openjpeg/src/bin/jp3d/tcltk/LPI_JP3D_VM.tcl
> openjpeg/src/bin/jp3d/tcltk/README
> openjpeg/src/bin/jp3d/tcltk/Thumbs.db
> openjpeg/src/bin/jp3d/tcltk/decoder.tcl
> openjpeg/src/bin/jp3d/tcltk/encoder.tcl
> openjpeg/src/bin/jp3d/tcltk/logoLPI.gif
> openjpeg/src/bin/jp3d/windirent.h
> openjpeg/src/bin/jpip/CMakeLists.txt
> openjpeg/src/bin/jpip/README
> openjpeg/src/bin/jpip/opj_dec_server.c
> openjpeg/src/bin/jpip/opj_jpip_addxml.c
> openjpeg/src/bin/jpip/opj_jpip_test.c
> openjpeg/src/bin/jpip/opj_jpip_transcode.c
> openjpeg/src/bin/jpip/opj_server.c
> openjpeg/src/bin/jpip/opj_viewer/dist/manifest.txt
> openjpeg/src/bin/jpip/opj_viewer/src/ImageManager.java
> openjpeg/src/bin/jpip/opj_viewer/src/ImageViewer.java
> openjpeg/src/bin/jpip/opj_viewer/src/ImageWindow.java
> openjpeg/src/bin/jpip/opj_viewer/src/ImgdecClient.java
> openjpeg/src/bin/jpip/opj_viewer/src/JPIPHttpClient.java
> openjpeg/src/bin/jpip/opj_viewer/src/MML.java
> openjpeg/src/bin/jpip/opj_viewer/src/PnmImage.java
> openjpeg/src/bin/jpip/opj_viewer/src/RegimViewer.java
> openjpeg/src/bin/jpip/opj_viewer/src/ResizeListener.java
> openjpeg/src/bin/jpip/opj_viewer_xerces/dist/manifest.txt.in
> openjpeg/src/bin/jpip/opj_viewer_xerces/src/ImageViewer.java
> openjpeg/src/bin/jpip/opj_viewer_xerces/src/ImageWindow.java
> openjpeg/src/bin/jpip/opj_viewer_xerces/src/JP2XMLparser.java
> openjpeg/src/bin/jpip/opj_viewer_xerces/src/OptionPanel.java
> openjpeg/src/bin/jpwl/CMakeLists.txt
> openjpeg/src/bin/jpwl/convert.c
> openjpeg/src/bin/jpwl/convert.h
> openjpeg/src/bin/jpwl/index.c
> openjpeg/src/bin/jpwl/index.h
> openjpeg/src/bin/jpwl/opj_jpwl_compress.c
> openjpeg/src/bin/jpwl/opj_jpwl_decompress.c
> openjpeg/src/bin/jpwl/windirent.h
> openjpeg/src/bin/mj2/CMakeLists.txt
> openjpeg/src/bin/mj2/meta_out.c
> openjpeg/src/bin/mj2/meta_out.h
> openjpeg/src/bin/mj2/mj2_to_metadata.c
> openjpeg/src/bin/mj2/mj2_to_metadata.dtd
> openjpeg/src/bin/mj2/mj2_to_metadata.h
> openjpeg/src/bin/mj2/mj2_to_metadata.sln
> openjpeg/src/bin/mj2/mj2_to_metadata.vcproj
> openjpeg/src/bin/mj2/mj2_to_metadata_Notes.doc
> openjpeg/src/bin/mj2/opj_mj2_compress.c
> openjpeg/src/bin/mj2/opj_mj2_decompress.c
> openjpeg/src/bin/mj2/opj_mj2_extract.c
> openjpeg/src/bin/mj2/opj_mj2_wrap.c
> openjpeg/src/bin/mj2/readme.txt
> openjpeg/src/bin/wx/CMakeLists.txt
> openjpeg/src/bin/wx/OPJViewer/CMakeLists.txt
> openjpeg/src/bin/wx/OPJViewer/OPJViewer.iss
> openjpeg/src/bin/wx/OPJViewer/Readme.txt
> openjpeg/src/bin/wx/OPJViewer/about/about.htm
> openjpeg/src/bin/wx/OPJViewer/about/opj_logo.png
> openjpeg/src/bin/wx/OPJViewer/source/OPJAbout.cpp
> openjpeg/src/bin/wx/OPJViewer/source/OPJChild.ico
> openjpeg/src/bin/wx/OPJViewer/source/OPJChild16.xpm
> openjpeg/src/bin/wx/OPJViewer/source/OPJDialogs.cpp
> openjpeg/src/bin/wx/OPJViewer/source/OPJThreads.cpp
> openjpeg/src/bin/wx/OPJViewer/source/OPJViewer.cpp
> openjpeg/src/bin/wx/OPJViewer/source/OPJViewer.h
> openjpeg/src/bin/wx/OPJViewer/source/OPJViewer.ico
> openjpeg/src/bin/wx/OPJViewer/source/OPJViewer.rc
> openjpeg/src/bin/wx/OPJViewer/source/OPJViewer16.xpm
> openjpeg/src/bin/wx/OPJViewer/source/about_htm.h
> openjpeg/src/bin/wx/OPJViewer/source/build.h
> openjpeg/src/bin/wx/OPJViewer/source/icon1.xpm
> openjpeg/src/bin/wx/OPJViewer/source/icon2.xpm
> openjpeg/src/bin/wx/OPJViewer/source/icon3.xpm
> openjpeg/src/bin/wx/OPJViewer/source/icon4.xpm
> openjpeg/src/bin/wx/OPJViewer/source/icon5.xpm
> openjpeg/src/bin/wx/OPJViewer/source/imagjpeg2000.cpp
> openjpeg/src/bin/wx/OPJViewer/source/imagjpeg2000.h
> openjpeg/src/bin/wx/OPJViewer/source/imagmxf.cpp
> openjpeg/src/bin/wx/OPJViewer/source/imagmxf.h
> openjpeg/src/bin/wx/OPJViewer/source/license.txt
> openjpeg/src/bin/wx/OPJViewer/source/opj_logo.xpm
> openjpeg/src/bin/wx/OPJViewer/source/readmeafter.txt
> openjpeg/src/bin/wx/OPJViewer/source/readmebefore.txt
> openjpeg/src/bin/wx/OPJViewer/source/wxj2kparser.cpp
> openjpeg/src/bin/wx/OPJViewer/source/wxjp2parser.cpp
> openjpeg/src/lib/CMakeLists.txt
> openjpeg/src/lib/openjp2/CMakeLists.txt
> openjpeg/src/lib/openjp2/bench_dwt.c
> openjpeg/src/lib/openjp2/dwt.c
> openjpeg/src/lib/openjp2/image.c
> openjpeg/src/lib/openjp2/j2k.c
> openjpeg/src/lib/openjp2/jp2.c
> openjpeg/src/lib/openjp2/openjpeg.h
> openjpeg/src/lib/openjp2/opj_intmath.h
> openjpeg/src/lib/openjp2/pi.c
> openjpeg/src/lib/openjp2/t1.c
> openjpeg/src/lib/openjp2/t2.c
> openjpeg/src/lib/openjp2/tcd.c
> openjpeg/src/lib/openjp2/thread.c

2019-11-26 13:19:03 +0000
Chris Liddell <chris.liddell@artifex.com>
107babf6d3652ed9bcf26b20823ac935ba86634b

> Update expat to 2.2.9
> And small makefile tweak to support it.
> base/expat.mak
> expat/CMake.README
> expat/CMakeLists.txt
> expat/Changes
> expat/ConfigureChecks.cmake
> expat/Makefile.am
> expat/Makefile.in
> expat/README.md
> expat/acinclude.m4
> expat/aclocal.m4
> expat/cmake/expat-config.cmake.in
> expat/cmake/mingw-toolchain.cmake
> expat/configure
> expat/configure.ac
> expat/conftools/ac_c_bigendian_cross.m4
> expat/conftools/ar-lib
> expat/conftools/ax-append-compile-flags.m4
> expat/conftools/ax-append-flag.m4
> expat/conftools/ax-append-link-flags.m4
> expat/conftools/ax-check-compile-flag.m4
> expat/conftools/ax-check-link-flag.m4
> expat/conftools/ax-require-defined.m4
> expat/conftools/config.guess
> expat/conftools/config.sub
> expat/conftools/expatcfg-compiler-supports-visibility.m4
> expat/conftools/install-sh
> expat/conftools/ltmain.sh
> expat/conftools/missing
> expat/doc/Makefile.am
> expat/doc/Makefile.in
> expat/doc/reference.html
> expat/examples/Makefile.in
> expat/examples/elements.c
> expat/examples/elements.vcxproj
> expat/examples/elements.vcxproj.filters
> expat/examples/outline.c
> expat/examples/outline.vcxproj
> expat/examples/outline.vcxproj.filters
> expat/expat.sln
> expat/expat_config.h
> expat/expat_config.h.cmake
> expat/expat_config.h.in
> expat/fix-xmltest-log.sh
> expat/lib/Makefile.am
> expat/lib/Makefile.in
> expat/lib/asciitab.h
> expat/lib/expat.h
> expat/lib/expat.vcxproj
> expat/lib/expat.vcxproj.filters
> expat/lib/expat_external.h
> expat/lib/expat_static.vcxproj
> expat/lib/expat_static.vcxproj.filters
> expat/lib/expatw.vcxproj
> expat/lib/expatw.vcxproj.filters
> expat/lib/expatw_static.vcxproj
> expat/lib/expatw_static.vcxproj.filters
> expat/lib/iasciitab.h
> expat/lib/internal.h
> expat/lib/latin1tab.h
> expat/lib/libexpat.def
> expat/lib/libexpatw.def
> expat/lib/loadlibrary.c
> expat/lib/nametab.h
> expat/lib/siphash.h
> expat/lib/utf8tab.h
> expat/lib/winconfig.h
> expat/lib/xmlparse.c
> expat/lib/xmlrole.c
> expat/lib/xmlrole.h
> expat/lib/xmltok.c
> expat/lib/xmltok.h
> expat/lib/xmltok_impl.c
> expat/lib/xmltok_impl.h
> expat/lib/xmltok_ns.c
> expat/test-driver-wrapper.sh
> expat/tests/Makefile.in
> expat/tests/benchmark/Makefile.in
> expat/tests/benchmark/benchmark.c
> expat/tests/benchmark/benchmark.sln
> expat/tests/benchmark/benchmark.vcxproj
> expat/tests/chardata.c
> expat/tests/chardata.h
> expat/tests/memcheck.c
> expat/tests/memcheck.h
> expat/tests/minicheck.c
> expat/tests/minicheck.h
> expat/tests/runtests.c
> expat/tests/runtests.sln
> expat/tests/runtests.vcxproj
> expat/tests/runtests.vcxproj.filters
> expat/tests/structdata.c
> expat/tests/structdata.h
> expat/tests/xmltest.sh
> expat/win32/README.txt
> expat/win32/build_expat_iss.bat
> expat/win32/expat.iss
> expat/xmlwf/Makefile.am
> expat/xmlwf/Makefile.in
> expat/xmlwf/codepage.c
> expat/xmlwf/ct.c
> expat/xmlwf/filemap.h
> expat/xmlwf/readfilemap.c
> expat/xmlwf/unixfilemap.c
> expat/xmlwf/win32filemap.c
> expat/xmlwf/xmlfile.c
> expat/xmlwf/xmlfile.h
> expat/xmlwf/xmlmime.c
> expat/xmlwf/xmltchar.h
> expat/xmlwf/xmlurl.h
> expat/xmlwf/xmlwf.c
> expat/xmlwf/xmlwf.vcxproj
> expat/xmlwf/xmlwf.vcxproj.filters
> expat/xmlwf/xmlwf_helpgen.py
> expat/xmlwf/xmlwf_helpgen.sh
> expat/xmlwf/xmlwin32url.cxx

2019-11-26 13:13:11 +0000
Chris Liddell <chris.liddell@artifex.com>
f25387684b5df27653e7f89a67e04d6151b92d02

> Update libpng to 1.6.37
> base/png.mak
> libpng/ANNOUNCE
> libpng/AUTHORS
> libpng/CHANGES
> libpng/CMakeLists.txt
> libpng/INSTALL
> libpng/LICENSE
> libpng/Makefile.am
> libpng/Makefile.in
> libpng/README
> libpng/TODO
> libpng/TRADEMARK
> libpng/aclocal.m4
> libpng/arm/arm_init.c
> libpng/arm/filter_neon.S
> libpng/arm/filter_neon_intrinsics.c
> libpng/arm/palette_neon_intrinsics.c
> libpng/autogen.sh
> libpng/compile
> libpng/config.guess
> libpng/config.h.in
> libpng/config.sub
> libpng/configure
> libpng/configure.ac
> libpng/contrib/conftest/pngcp.dfa
> libpng/contrib/examples/iccfrompng.c
> libpng/contrib/examples/pngpixel.c
> libpng/contrib/gregbook/readpng2.c
> libpng/contrib/libtests/makepng.c
> libpng/contrib/libtests/pngimage.c
> libpng/contrib/libtests/pngstest.c
> libpng/contrib/libtests/pngunknown.c
> libpng/contrib/libtests/pngvalid.c
> libpng/contrib/libtests/readpng.c
> libpng/contrib/libtests/tarith.c
> libpng/contrib/libtests/timepng.c
> libpng/contrib/oss-fuzz/Dockerfile
> libpng/contrib/oss-fuzz/README.txt
> libpng/contrib/oss-fuzz/build.sh
> libpng/contrib/oss-fuzz/libpng_read_fuzzer.cc
> libpng/contrib/oss-fuzz/newcc
> libpng/contrib/pngminus/CHANGES.txt
> libpng/contrib/pngminus/CMakeLists.txt
> libpng/contrib/pngminus/LICENSE.txt
> libpng/contrib/pngminus/Makefile
> libpng/contrib/pngminus/README.txt
> libpng/contrib/pngminus/makefile.std
> libpng/contrib/pngminus/makefile.tc3
> libpng/contrib/pngminus/png2pnm.bat
> libpng/contrib/pngminus/png2pnm.c
> libpng/contrib/pngminus/png2pnm.sh
> libpng/contrib/pngminus/pngminus.bat
> libpng/contrib/pngminus/pngminus.sh
> libpng/contrib/pngminus/pnm2png.bat
> libpng/contrib/pngminus/pnm2png.c
> libpng/contrib/pngminus/pnm2png.sh
> libpng/contrib/pngsuite/README
> libpng/contrib/pngsuite/bad_interlace_conversions.txt
> libpng/contrib/pngsuite/ibasn0g08.png
> libpng/contrib/pngsuite/ibasn0g16.png
> libpng/contrib/pngsuite/ibasn2c08.png
> libpng/contrib/pngsuite/ibasn2c16.png
> libpng/contrib/pngsuite/ibasn3p08.png
> libpng/contrib/pngsuite/ibasn4a08.png
> libpng/contrib/pngsuite/ibasn4a16.png
> libpng/contrib/pngsuite/ibasn6a08.png
> libpng/contrib/pngsuite/ibasn6a16.png
> libpng/contrib/pngsuite/iftbbn2c16.png
> libpng/contrib/pngsuite/iftbbn3p08.png
> libpng/contrib/pngsuite/iftbgn2c16.png
> libpng/contrib/pngsuite/iftbgn3p08.png
> libpng/contrib/pngsuite/iftbrn2c08.png
> libpng/contrib/pngsuite/iftbwn0g16.png
> libpng/contrib/pngsuite/iftbwn3p08.png
> libpng/contrib/pngsuite/iftbyn3p08.png
> libpng/contrib/pngsuite/iftp0n0g08.png
> libpng/contrib/pngsuite/iftp0n2c08.png
> libpng/contrib/pngsuite/iftp0n3p08.png
> libpng/contrib/pngsuite/iftp1n3p08.png
> libpng/contrib/pngsuite/interlaced/README
> libpng/contrib/pngsuite/interlaced/ibasn0g01.png
> libpng/contrib/pngsuite/interlaced/ibasn0g02.png
> libpng/contrib/pngsuite/interlaced/ibasn0g04.png
> libpng/contrib/pngsuite/interlaced/ibasn3p01.png
> libpng/contrib/pngsuite/interlaced/ibasn3p02.png
> libpng/contrib/pngsuite/interlaced/ibasn3p04.png
> libpng/contrib/pngsuite/interlaced/iftbbn0g01.png
> libpng/contrib/pngsuite/interlaced/iftbbn0g02.png
> libpng/contrib/pngsuite/interlaced/iftbbn0g04.png
> libpng/contrib/powerpc-vsx/README
> libpng/contrib/powerpc-vsx/linux_aux.c
> libpng/contrib/testpngs/makepngs.sh
> libpng/contrib/tools/chkfmt
> libpng/contrib/tools/makesRGB.c
> libpng/contrib/tools/pngcp.c
> libpng/contrib/tools/pngfix.c
> libpng/contrib/visupng/PngFile.c
> libpng/contrib/visupng/PngFile.h
> libpng/contrib/visupng/VisualPng.c
> libpng/depcomp
> libpng/example.c
> libpng/install-sh
> libpng/intel/filter_sse2_intrinsics.c
> libpng/intel/intel_init.c
> libpng/libpng-manual.txt
> libpng/libpng.3
> libpng/libpngpf.3
> libpng/mips/filter_msa_intrinsics.c
> libpng/mips/mips_init.c
> libpng/missing
> libpng/png.5
> libpng/png.c
> libpng/png.h
> libpng/pngconf.h
> libpng/pngdebug.h
> libpng/pngerror.c
> libpng/pngget.c
> libpng/pnginfo.h
> libpng/pngmem.c
> libpng/pngpread.c
> libpng/pngpriv.h
> libpng/pngread.c
> libpng/pngrio.c
> libpng/pngrtran.c
> libpng/pngrutil.c
> libpng/pngset.c
> libpng/pngstruct.h
> libpng/pngtest.c
> libpng/pngtrans.c
> libpng/pngwio.c
> libpng/pngwrite.c
> libpng/pngwtran.c
> libpng/pngwutil.c
> libpng/powerpc/filter_vsx_intrinsics.c
> libpng/powerpc/powerpc_init.c
> libpng/projects/owatcom/pngconfig.mak
> libpng/projects/visualc71/README.txt
> libpng/projects/vstudio/README.txt
> libpng/projects/vstudio/zlib.props
> libpng/scripts/README.txt
> libpng/scripts/def.c
> libpng/scripts/descrip.mms
> libpng/scripts/libpng-config-head.in
> libpng/scripts/libpng.pc.in
> libpng/scripts/makefile.32sunu
> libpng/scripts/makefile.64sunu
> libpng/scripts/makefile.bor
> libpng/scripts/makefile.cegcc
> libpng/scripts/makefile.clang
> libpng/scripts/makefile.clang-asan
> libpng/scripts/makefile.darwin
> libpng/scripts/makefile.freebsd
> libpng/scripts/makefile.gcc
> libpng/scripts/makefile.gcc-asan
> libpng/scripts/makefile.hp64
> libpng/scripts/makefile.hpgcc
> libpng/scripts/makefile.hpux
> libpng/scripts/makefile.knr
> libpng/scripts/makefile.linux
> libpng/scripts/makefile.linux-opt
> libpng/scripts/makefile.mips
> libpng/scripts/makefile.msc
> libpng/scripts/makefile.msys
> libpng/scripts/makefile.ne12bsd
> libpng/scripts/makefile.netbsd
> libpng/scripts/makefile.openbsd
> libpng/scripts/makefile.sco
> libpng/scripts/makefile.sggcc
> libpng/scripts/makefile.sgi
> libpng/scripts/makefile.so9
> libpng/scripts/makefile.solaris
> libpng/scripts/makefile.solaris-x86
> libpng/scripts/makefile.std
> libpng/scripts/makefile.sunos
> libpng/scripts/makefile.tc3
> libpng/scripts/options.awk
> libpng/scripts/pnglibconf.dfa
> libpng/scripts/pnglibconf.h.prebuilt
> libpng/scripts/symbols.def
> libpng/test-driver

2019-11-26 12:13:13 +0000
Chris Liddell <chris.liddell@artifex.com>
9282c39e6150befd80793b3221864c9f1f814b66

> Update libtiff to 4.1.0
> Add in portability changes to tiffiop.h
> Portability tiffiop.h
> Remove globals from tif_pixarlog.c
> tiff/CMakeLists.txt
> tiff/ChangeLog
> tiff/HOWTO-RELEASE
> tiff/Makefile.am
> tiff/Makefile.in
> tiff/Makefile.vc
> tiff/README.md
> tiff/README.vms
> tiff/RELEASE-DATE
> tiff/SConstruct
> tiff/TODO
> tiff/VERSION
> tiff/aclocal.m4
> tiff/build/Makefile.in
> tiff/config/compile
> tiff/config/config.guess
> tiff/config/config.sub
> tiff/config/depcomp
> tiff/config/install-sh
> tiff/config/ltmain.sh
> tiff/config/missing
> tiff/config/mkinstalldirs
> tiff/config/test-driver
> tiff/configure
> tiff/configure.ac
> tiff/configure.com
> tiff/contrib/Makefile.in
> tiff/contrib/addtiffo/Makefile.in
> tiff/contrib/addtiffo/addtiffo.c
> tiff/contrib/addtiffo/tif_overview.c
> tiff/contrib/addtiffo/tif_ovrcache.c
> tiff/contrib/dbs/Makefile.in
> tiff/contrib/dbs/tiff-bi.c
> tiff/contrib/dbs/tiff-grayscale.c
> tiff/contrib/dbs/tiff-palette.c
> tiff/contrib/dbs/tiff-rgb.c
> tiff/contrib/dbs/xtiff/Makefile.in
> tiff/contrib/dbs/xtiff/xtiff.c
> tiff/contrib/iptcutil/Makefile.in
> tiff/contrib/iptcutil/iptcutil.c
> tiff/contrib/mfs/Makefile.in
> tiff/contrib/pds/Makefile.in
> tiff/contrib/pds/README
> tiff/contrib/pds/tif_imageiter.c
> tiff/contrib/pds/tif_imageiter.h
> tiff/contrib/pds/tif_pdsdirread.c
> tiff/contrib/pds/tif_pdsdirwrite.c
> tiff/contrib/ras/Makefile.in
> tiff/contrib/ras/tif2ras.c
> tiff/contrib/stream/Makefile.in
> tiff/contrib/tags/Makefile.in
> tiff/contrib/tags/README
> tiff/contrib/tags/xtif_dir.c
> tiff/contrib/win_dib/Makefile.in
> tiff/contrib/win_dib/Makefile.w95
> tiff/contrib/win_dib/README.tiff2dib
> tiff/contrib/win_dib/Tiffile.cpp
> tiff/html/Makefile.am
> tiff/html/Makefile.in
> tiff/html/addingtags.html
> tiff/html/bugs.html
> tiff/html/build.html
> tiff/html/document.html
> tiff/html/images.html
> tiff/html/images/Makefile.in
> tiff/html/index.html
> tiff/html/libtiff.html
> tiff/html/man/Makefile.in
> tiff/html/man/TIFFReadDirectory.3tiff.html
> tiff/html/man/TIFFWriteDirectory.3tiff.html
> tiff/html/man/TIFFmemory.3tiff.html
> tiff/html/v3.4beta007.html
> tiff/html/v3.4beta016.html
> tiff/html/v3.4beta018.html
> tiff/html/v3.4beta024.html
> tiff/html/v3.4beta028.html
> tiff/html/v3.4beta029.html
> tiff/html/v3.4beta031.html
> tiff/html/v3.4beta032.html
> tiff/html/v3.4beta033.html
> tiff/html/v3.4beta034.html
> tiff/html/v3.4beta035.html
> tiff/html/v3.4beta036.html
> tiff/html/v3.5.1.html
> tiff/html/v3.5.2.html
> tiff/html/v3.5.3.html
> tiff/html/v3.5.4.html
> tiff/html/v3.5.5.html
> tiff/html/v3.5.6-beta.html
> tiff/html/v3.5.7.html
> tiff/html/v3.6.0.html
> tiff/html/v3.6.1.html
> tiff/html/v3.7.0.html
> tiff/html/v3.7.0alpha.html
> tiff/html/v3.7.0beta.html
> tiff/html/v3.7.0beta2.html
> tiff/html/v3.7.1.html
> tiff/html/v3.7.2.html
> tiff/html/v3.7.3.html
> tiff/html/v3.7.4.html
> tiff/html/v3.8.0.html
> tiff/html/v3.8.1.html
> tiff/html/v3.8.2.html
> tiff/html/v3.9.0beta.html
> tiff/html/v3.9.1.html
> tiff/html/v3.9.2.html
> tiff/html/v4.0.0.html
> tiff/html/v4.0.1.html
> tiff/html/v4.0.10.html
> tiff/html/v4.0.2.html
> tiff/html/v4.0.3.html
> tiff/html/v4.0.4.html
> tiff/html/v4.0.4beta.html
> tiff/html/v4.0.5.html
> tiff/html/v4.0.6.html
> tiff/html/v4.0.7.html
> tiff/html/v4.0.8.html
> tiff/html/v4.0.9.html
> tiff/html/v4.1.0.html
> tiff/libtiff/CMakeLists.txt
> tiff/libtiff/Makefile.am
> tiff/libtiff/Makefile.in
> tiff/libtiff/Makefile.vc
> tiff/libtiff/SConstruct
> tiff/libtiff/libtiff.def
> tiff/libtiff/mkg3states.c
> tiff/libtiff/t4.h
> tiff/libtiff/tif_aux.c
> tiff/libtiff/tif_close.c
> tiff/libtiff/tif_codec.c
> tiff/libtiff/tif_color.c
> tiff/libtiff/tif_compress.c
> tiff/libtiff/tif_config.h.cmake.in
> tiff/libtiff/tif_config.h.in
> tiff/libtiff/tif_config.wince.h
> tiff/libtiff/tif_dir.c
> tiff/libtiff/tif_dir.h
> tiff/libtiff/tif_dirinfo.c
> tiff/libtiff/tif_dirread.c
> tiff/libtiff/tif_dirwrite.c
> tiff/libtiff/tif_dumpmode.c
> tiff/libtiff/tif_error.c
> tiff/libtiff/tif_extension.c
> tiff/libtiff/tif_fax3.c
> tiff/libtiff/tif_fax3.h
> tiff/libtiff/tif_flush.c
> tiff/libtiff/tif_getimage.c
> tiff/libtiff/tif_jbig.c
> tiff/libtiff/tif_jpeg.c
> tiff/libtiff/tif_luv.c
> tiff/libtiff/tif_lzma.c
> tiff/libtiff/tif_lzw.c
> tiff/libtiff/tif_next.c
> tiff/libtiff/tif_ojpeg.c
> tiff/libtiff/tif_open.c
> tiff/libtiff/tif_packbits.c
> tiff/libtiff/tif_pixarlog.c
> tiff/libtiff/tif_predict.c
> tiff/libtiff/tif_predict.h
> tiff/libtiff/tif_print.c
> tiff/libtiff/tif_read.c
> tiff/libtiff/tif_stream.cxx
> tiff/libtiff/tif_strip.c
> tiff/libtiff/tif_swab.c
> tiff/libtiff/tif_thunder.c
> tiff/libtiff/tif_tile.c
> tiff/libtiff/tif_unix.c
> tiff/libtiff/tif_version.c
> tiff/libtiff/tif_warning.c
> tiff/libtiff/tif_webp.c
> tiff/libtiff/tif_win32.c
> tiff/libtiff/tif_write.c
> tiff/libtiff/tif_zip.c
> tiff/libtiff/tif_zstd.c
> tiff/libtiff/tiff.h
> tiff/libtiff/tiffconf.h.cmake.in
> tiff/libtiff/tiffconf.h.in
> tiff/libtiff/tiffconf.vc.h
> tiff/libtiff/tiffconf.wince.h
> tiff/libtiff/tiffio.h
> tiff/libtiff/tiffio.hxx
> tiff/libtiff/tiffiop.h
> tiff/libtiff/tiffvers.h
> tiff/m4/libtool.m4
> tiff/man/Makefile.in
> tiff/man/TIFFClose.3tiff
> tiff/man/TIFFDataWidth.3tiff
> tiff/man/TIFFError.3tiff
> tiff/man/TIFFFieldDataType.3tiff
> tiff/man/TIFFFieldName.3tiff
> tiff/man/TIFFFieldPassCount.3tiff
> tiff/man/TIFFFieldReadCount.3tiff
> tiff/man/TIFFFieldTag.3tiff
> tiff/man/TIFFFieldWriteCount.3tiff
> tiff/man/TIFFFlush.3tiff
> tiff/man/TIFFGetField.3tiff
> tiff/man/TIFFOpen.3tiff
> tiff/man/TIFFPrintDirectory.3tiff
> tiff/man/TIFFRGBAImage.3tiff
> tiff/man/TIFFReadDirectory.3tiff
> tiff/man/TIFFReadEncodedStrip.3tiff
> tiff/man/TIFFReadEncodedTile.3tiff
> tiff/man/TIFFReadRGBAImage.3tiff
> tiff/man/TIFFReadRGBAStrip.3tiff
> tiff/man/TIFFReadRGBATile.3tiff
> tiff/man/TIFFReadRawStrip.3tiff
> tiff/man/TIFFReadRawTile.3tiff
> tiff/man/TIFFReadScanline.3tiff
> tiff/man/TIFFReadTile.3tiff
> tiff/man/TIFFSetDirectory.3tiff
> tiff/man/TIFFSetField.3tiff
> tiff/man/TIFFWarning.3tiff
> tiff/man/TIFFWriteDirectory.3tiff
> tiff/man/TIFFWriteEncodedStrip.3tiff
> tiff/man/TIFFWriteEncodedTile.3tiff
> tiff/man/TIFFWriteRawStrip.3tiff
> tiff/man/TIFFWriteRawTile.3tiff
> tiff/man/TIFFWriteScanline.3tiff
> tiff/man/TIFFWriteTile.3tiff
> tiff/man/TIFFbuffer.3tiff
> tiff/man/TIFFcodec.3tiff
> tiff/man/TIFFcolor.3tiff
> tiff/man/TIFFmemory.3tiff
> tiff/man/TIFFquery.3tiff
> tiff/man/TIFFsize.3tiff
> tiff/man/TIFFstrip.3tiff
> tiff/man/TIFFswab.3tiff
> tiff/man/TIFFtile.3tiff
> tiff/man/fax2ps.1
> tiff/man/fax2tiff.1
> tiff/man/libtiff.3tiff
> tiff/man/pal2rgb.1
> tiff/man/ppm2tiff.1
> tiff/man/raw2tiff.1
> tiff/man/tiff2bw.1
> tiff/man/tiff2pdf.1
> tiff/man/tiff2ps.1
> tiff/man/tiff2rgba.1
> tiff/man/tiffcmp.1
> tiff/man/tiffcp.1
> tiff/man/tiffcrop.1
> tiff/man/tiffdither.1
> tiff/man/tiffdump.1
> tiff/man/tiffgt.1
> tiff/man/tiffinfo.1
> tiff/man/tiffmedian.1
> tiff/man/tiffset.1
> tiff/man/tiffsplit.1
> tiff/nmake.opt
> tiff/port/CMakeLists.txt
> tiff/port/Makefile.am
> tiff/port/Makefile.in
> tiff/port/Makefile.vc
> tiff/port/_strtol.h
> tiff/port/_strtoul.h
> tiff/port/dummy.c
> tiff/port/getopt.c
> tiff/port/lfind.c
> tiff/port/libport.h
> tiff/port/snprintf.c
> tiff/port/strcasecmp.c
> tiff/port/strtol.c
> tiff/port/strtoll.c
> tiff/port/strtoul.c
> tiff/port/strtoull.c
> tiff/test/CMakeLists.txt
> tiff/test/Makefile.am
> tiff/test/Makefile.in
> tiff/test/ascii_tag.c
> tiff/test/check_tag.c
> tiff/test/common.sh
> tiff/test/custom_dir.c
> tiff/test/defer_strile_loading.c
> tiff/test/defer_strile_writing.c
> tiff/test/fax2tiff.sh
> tiff/test/images/README.txt
> tiff/test/images/lzw-single-strip.tiff
> tiff/test/images/miniswhite-1c-1b.g3
> tiff/test/long_tag.c
> tiff/test/raw_decode.c
> tiff/test/refs/o-tiff2ps-EPS1.ps
> tiff/test/refs/o-tiff2ps-PS1.ps
> tiff/test/refs/o-tiff2ps-PS2.ps
> tiff/test/refs/o-tiff2ps-PS3.ps
> tiff/test/rewrite_tag.c
> tiff/test/short_tag.c
> tiff/test/strip.c
> tiff/test/strip_rw.c
> tiff/test/test_arrays.c
> tiff/test/test_arrays.h
> tiff/test/testtypes.c
> tiff/test/tiff2ps-EPS1.sh
> tiff/test/tiff2ps-PS1.sh
> tiff/test/tiff2ps-PS2.sh
> tiff/test/tiff2ps-PS3.sh
> tiff/test/tiffcp-lzw-scanline-decode.sh
> tiff/test/tifftest.h
> tiff/tools/CMakeLists.txt
> tiff/tools/Makefile.in
> tiff/tools/Makefile.vc
> tiff/tools/fax2ps.c
> tiff/tools/fax2tiff.c
> tiff/tools/pal2rgb.c
> tiff/tools/ppm2tiff.c
> tiff/tools/raw2tiff.c
> tiff/tools/rgb2ycbcr.c
> tiff/tools/thumbnail.c
> tiff/tools/tiff2bw.c
> tiff/tools/tiff2pdf.c
> tiff/tools/tiff2ps.c
> tiff/tools/tiff2rgba.c
> tiff/tools/tiffcmp.c
> tiff/tools/tiffcp.c
> tiff/tools/tiffcrop.c
> tiff/tools/tiffdither.c
> tiff/tools/tiffdump.c
> tiff/tools/tiffgt.c
> tiff/tools/tiffinfo.c
> tiff/tools/tiffmedian.c
> tiff/tools/tiffset.c
> tiff/tools/tiffsplit.c

2019-11-25 15:14:51 +0000
Julian Smith <jules@op59.net>
aa13e1a3fac84ada2b676f9c5fcffb30f5df74dd

> Coverity 351088: check for errors in px_begin_error_page().
> Had to change px_begin_error_page()'s API to use out-parameter, so that return
> value is error code.
> pcl/pxl/pxerrors.c
> pcl/pxl/pxerrors.h
> pcl/pxl/pxtop.c

2019-11-25 14:42:05 +0000
Julian Smith <jules@op59.net>
34fc5a7613eea288a8426d3be425c93647954668

> Coverity 351086: Fix out-of-bounds access to score[2].
> gpdl/psitop.c

2019-11-25 19:48:50 +0000
Robin Watts <Robin.Watts@artifex.com>
a570a05622cb178c031db64711b412cf640038b2

> Coverity 350201, 350191: Add some notes to the code.
> Coverity spots that pdf14_fill_path checks for ppath being
> NULL in one branch, hence assumes that it can be NULL in all
> cases. Furthermore it spots that it is passed into
> gx_default_fill_path, which can in some circumstances, dereference
> it without checking it first.
> The reason for this is that fill_path can permissibly be called
> with a NULL path if we want to fill the given clipping path. This
> is only used for shadings and patterns, which is exactly the case
> checked for within gx_default_fill_path and pdf14_fill_path.
> We'll resolve this with a 'false positive' in Coverity, but have
> added the comments for the benefit of future readers.
> Coverity spots the same thing in pdf14_stroke_path, but there it
> really makes no sense for ppath to be NULL, so just eliminate the
> check.
> Credit to Julian Smith for the investigation on this.
> base/gdevp14.c

2019-11-25 18:30:33 +0000
Robin Watts <Robin.Watts@artifex.com>
fee6b609fbb8d1f0744f98ee3bf930c1fd733660

> Fix indeterminism in gdevp201.c
> The printers herein read 1bpp data from gs, and then compressed
> in terms of bytes. For the case where w%8 != 0, we'd have
> uninitialised bits. Solve this by masking the last byte of each
> line as appropriate.
> Also, ensure that we don't 'overread' lines, check the return
> code from the get_bits call, and blank any lines of the buffer
> required to bring us up to a multiple of the stripe height.
> contrib/japanese/gdevp201.c

2019-11-25 09:44:29 -0800
Robin Watts <Robin.Watts@artifex.com>
f3b0a9e346a97b23f1f7e016944be514c8b0ec78

> Fix indeterminism in gdevatx.c
> The compression used by this device relies on compressing pairs of
> bytes; as such we have to be careful that when we offset to the end
> of the line we don't move inot uninitialised data.
> We fix this here by blanking an extra byte, and being smarter about
> where we start the search for trailing empties from.
> This should resolve the differences we see in the all-devs test.
> devices/gdevatx.c

2019-11-25 16:12:17 +0000
Robin Watts <Robin.Watts@artifex.com>
8a589c19d62884388cb9eff7d12bfba568e667ca

> Fix incorrect transform in gpdl/pwgtop.c
> gpdl/pwgtop.c

2019-11-22 19:43:46 +0000
Robin Watts <Robin.Watts@artifex.com>
79e11b98dc078fcd92cda588ab6157a4aa14d0f0

> Add Jpeg2000 "language" interpreter for gpdl.
> gpdl/gpdl.mak
> gpdl/jp2ktop.c
> pcl/pl/plimpl.c
> windows/ghostpdl.vcproj

2019-11-25 15:59:00 +0000
Robin Watts <Robin.Watts@artifex.com>
113792dd347ac7b9436b9517aca91e1153fb230d

> Ensure oki4w device properly closes device.
> This was causing indetermisms in cluster runs.
> contrib/gdevop4w.c

2019-11-25 14:50:05 +0000
Robin Watts <Robin.Watts@artifex.com>
12eef95ef9ed7a086ca02f06ef93acce9c9a2676

> Remove FIXME and associated dead code in pwgtop.c
> This should solve coverity 351087.
> gpdl/pwgtop.c

2019-11-25 14:46:56 +0000
Robin Watts <Robin.Watts@artifex.com>
ab089bf9511ccaa30a33d6e269ab0dae98ff5517

> Fix coverity #351085; toff_t's are unsigned.
> The tiff lib uses a 'seek' function that apes 'fseek' in that
> it takes a whence field. In order for the whence field to be
> useful for 'SEEK_SET' (and half the cases of SEEK_CURR), it
> needs to be able to take negative offsets. The tiff seek
> function only passes positive offsets though as it uses an
> unsigned type.
> It is therefore pointless to test against 0.
> gpdl/tifftop.c

2019-11-22 15:31:47 +0000
Chris Liddell <chris.liddell@artifex.com>
e056194328312f724089d52398e88c5a6a2fe277

> Windows installer: offer to uninstall previous installations
> If the installer detects previous gs installations (from the registry keys), an
> additional page will appear in the installer, giving the user the option of
> uninstalling each existing installation in turn - it allows uninstall a given
> install, not uninstall it, or cancel out of uninstalling the remaining ones.
> psi/nsisinst.nsi

2019-11-22 18:12:11 +0000
Julian Smith <jules@op59.net>
e9ff39ee82680ea1719ddf99cf3809e26df0c946

> Coverity 351050: avoid buffer overflow warning.
> For simplicity, have used a temp four-character buffer filled in by
> parse_file_access_string(), then snprintf() to append gp_fmode_binary_suffix
> safely.
> psi/zfile.c

2019-11-22 18:08:05 +0000
Julian Smith <jules@op59.net>
354715346deed252ef7db53160b61d04bd630a2f

> Coverity 351049: avoid buffer overflow warning.
> We're actually safe because gp_fmode_binary_suffix is max one-character long,
> but Coverity doesn't know that.
> base/gxclfile.c

2019-11-22 18:05:35 +0000
Julian Smith <jules@op59.net>
b8c8a6410658fdfe57ad5de4ae57fdc4cbece2ab

> Coverity 351048: avoid buffer overflow warning.
> We're actually safe because gp_fmode_binary_suffix is max one-character long,
> but Coverity doesn't know that.
> base/gxclist.c

2019-11-22 17:45:51 +0000
Julian Smith <jules@op59.net>
882793bc7f35f21f7857e216966c0b777140a87c

> Coverity 350209: fix bad return path in handle_dash_c().
> Also refactored a little.
> pcl/pl/plmain.c

2019-11-22 10:43:43 -0800
Michael Vrhel <michael.vrhel@artifex.com>
8f611a6c45fafbea495206773eccf3028cfb4765

> Bug 701625 Treat CMY color space as additive
> Our support of CMY devices is currently not ideal with
> respect to proper color management and the transparency
> imaging model as described in Bug 697965. My plan is
> to make a psd cmy based device and get things working
> properly in terms of spot colors and ICC color management.
> This will take a bit of effort and likely have a bug
> tail. For now for Bug 701625 an easy solution is to
> treat the color space as additive. In this case, the
> output looks reasonable.
> cups/gdevcups.c

2019-11-22 11:42:29 +0000
Julian Smith <jules@op59.net>
f734274b455c321a4089d8ee7efa7511656ae9c6

> Removed gp_fprintf(pstream, "") call that has no affect.
> This was causing gcc warning because gp_fprintf() is now checked by gcc for
> printf format warnings.
> devices/gdevmgr.c

2019-11-21 18:39:21 +0000
Julian Smith <jules@op59.net>
17a947dcc56fee115d7b416de7648289b04185f8

> Fix some -W -Wall warnings about printf format type mismatches.
> contrib/gdevhl12.c
> jbig2dec/jbig2.c
> jbig2dec/jbig2_segment.c

2019-11-21 17:47:53 +0000
Julian Smith <jules@op59.net>
cbd8765cc2e5d67eae3d412a7584f37a9e02f2e9

> Bug 701932: fixed up head dependencies for pxstate_h.
> pcl/pxl/pxl.mak

2019-11-21 17:16:27 +0000
Julian Smith <jules@op59.net>
3ee9bb6efff8929ff8df4fb7ca42001c2aeacdf6

> Coverity 350198: fixed jbig2_error() printf format / type mismatches.
> Unfortunately stdint_.h isn't available to jbig2dec code so we can't use
> PRIdSIZE. Have instead used %li with a cast to long.
> [This commit addresses all printf warnings from gcc -W -Wall; it probably fixes
> multiple similar coverity issues.]
> jbig2dec/jbig2_symbol_dict.c

2019-11-21 17:11:43 +0000
Julian Smith <jules@op59.net>
67a59c12667bbdddf67e78d9496f94b34d55e702

> Coverity 350195: check return from process_row().
> pcl/pcl/rtraster.c

2019-11-21 17:01:55 +0000
Julian Smith <jules@op59.net>
3819f5121013dd93dd3653475e686d8f6df9b068

> Coverity 350189: explicitly ignore return from hpgl_arg_c_int().
> We already initialised variable 'type', and we don't mind whether
> hpgl_arg_c_int() changes it before we switch on it. So cast hpgl_arg_c_int()'s
> return to void to stop Coverity from warning.
> pcl/pcl/pgconfig.c

2019-11-21 16:52:32 +0000
Julian Smith <jules@op59.net>
3b8f96dbe2dc0ab0cdbbf076cdb88e21c91639a5

> Coverity 350185: fix printf format type mismatch.
> Unfortunately stdint_.h isn't available to jbig2dec code so we can't use
> PRIdSIZE. Have instead used %li with a cast to long.
> jbig2dec/jbig2_generic.c

2019-11-21 16:49:51 +0000
Julian Smith <jules@op59.net>
4b31b05c2db5967c00d0b08023167935bbb3d015

> If gcc, make gcc check jbig2_error()'s format string agrees with types of parameters.
> jbig2dec/jbig2_priv.h

2019-11-21 16:23:32 +0000
Julian Smith <jules@op59.net>
1098cdd54a46dca9ca976b750ba25d0b714dfd9f

> Add a --enable-mkromfs-quiet configure option.
> Sets MKROMFS_FLAGS=-q and pass to all invocations of mkromfs.
> [Makefile.in and configure.ac changes by chrisl]
> Makefile.in
> base/lib.mak
> configure.ac

2019-11-21 12:52:41 +0000
Julian Smith <jules@op59.net>
1f60fa73b7c6b5acfae75b6e4a1fede2b75ea1c4

> mkromfs: added -q option to reduce verbose diagnostics.
> base/mkromfs.c

2019-11-15 16:45:33 +0000
Julian Smith <jules@op59.net>
3e01cc30c90094bcbef2966f1048c504e6b5361e

> configure.ac: add -W -Wall to sanitize builds if supported.
> configure.ac

2019-11-21 13:41:37 +0000
Julian Smith <jules@op59.net>
b93f218d418827b689c61b37941ffd4eef0c0d84

> Mark gp_fprintf() with gcc's __attribute__ ((format (__printf__, 2, 3))).
> This makes gcc check types match the format string.
> base/gp.h

2019-11-21 13:40:45 +0000
Julian Smith <jules@op59.net>
87cd6160bf654a164469e75a9df7cc7b690b5aaa

> Coverity 350172: fix gp_fprintf() call to use PRIdSIZE for ptrdiff_t.
> contrib/japanese/gdevp201.c

2019-11-21 12:24:48 +0000
Julian Smith <jules@op59.net>
53a370b272a89df418ea563f1abde7d774579105

> Coverity 350169: avoid buffer overflow when writing to cups->pageSizeRequested.
> cups/gdevcups.c

2019-11-20 19:30:55 +0000
Julian Smith <jules@op59.net>
7fe9289f10c47fe7557375c23b54cd87e521d11c

> Bug 701932: moved more global_* into px_state_s.
> Specifically:
> gs_point global_char_shear;
> gs_point global_char_scale;
> float global_char_bold_value;
> float global_char_angle;
> pcl/pxl/pxpthr.c
> pcl/pxl/pxstate.h

2019-11-20 19:16:48 +0000
Julian Smith <jules@op59.net>
810c897c51e28dcdd589e1561af36769e72e0893

> Bug 701932: moved more global_* into px_state_s.
> Specifically:
> static pcl_parser_state_t global_pcl_parser_state;
> static hpgl_parser_state_t global_gl_parser_state;
> static bool global_this_pass_contiguous = false;
> static bool global_pass_first = true;
> pcl/pxl/pxparse.c
> pcl/pxl/pxpthr.c
> pcl/pxl/pxpthr.h
> pcl/pxl/pxstate.c
> pcl/pxl/pxstate.h

2019-11-20 17:39:58 +0000
Julian Smith <jules@op59.net>
d48555f7777a983e0d15972f3838bb5583e20657

> Bug 701932: moved global_pcs into px_state_s.
> pcl/pxl/pxpthr.c
> pcl/pxl/pxpthr.h
> pcl/pxl/pxsessio.c
> pcl/pxl/pxstate.c
> pcl/pxl/pxstate.h

2019-11-20 12:42:16 +0000
Julian Smith <jules@op59.net>
4db291eb31b4dc8c6864e438acdd9283c3347671

> Coverity 350170: cope with -ve from gs_vsprintf().
> pcl/pcl/pcstatus.c

2019-11-22 13:02:39 +0000
Chris Liddell <chris.liddell@artifex.com>
0bc5d53fa1c0d7832008d1ae8e0e6804bf5f9e9e

> Windows (un)installer: Fix case for registry key removal
> psi/nsisinst.nsi

2019-11-22 10:30:14 +0000
Chris Liddell <chris.liddell@artifex.com>
efafc6f95b0bfedf63efafc55416846974a67bcc

> "Promote" gpdl from experimental to actual product
> Really, add gpdl to the default targets list.
> Makefile.in
> base/gs.mak
> base/unix-gcc.mak
> configure.ac
> psi/msvc.mak

2019-11-22 11:49:02 +0000
Ken Sharp <ken.sharp@artifex.com>
0243f6288ca26b2985f0778040feebae7322ac0b

> Coverity ID 94736
> This was partially addressed in a previous commit (2 years ago) but
> because the 'contrib' folder wasn't included in the ananlysis, this
> second instance of the same problem didn't show up.
> contrib/gdevcd8.c

2019-11-21 15:18:29 -0800
Michael Vrhel <michael.vrhel@artifex.com>
d9d92ab6b774914d81f63c8e19d78e4022ad9976

> Bug 701357: Fix color document
> Getting proper encoding of _ character requires use of
> [T1]{fontenc} and lmodern.
> doc/GS9_Color_Management.pdf
> doc/GS9_Color_Management.tex

2019-11-21 14:06:50 -0800
Michael Vrhel <michael.vrhel@artifex.com>
0129596f6cf2d090ed46f9a9c8189ab60b56735f

> Bug 700929: Pass object type rendering intent settings to pdf14 device
> base/gdevp14.c

2019-11-21 18:45:55 +0000
Robin Watts <Robin.Watts@artifex.com>
e0c2e4d8f43d6e83a0a04e6d2c350d2d7fc1e7a6

> gpdl: Fixup some warnings.
> gpdl/gpdl.mak
> gpdl/jpgtop.c
> gpdl/pwgtop.c
> gpdl/tifftop.c

2019-11-20 19:02:47 +0000
Robin Watts <Robin.Watts@artifex.com>
23ea32bf2bd205c44c9a7979b3a187199e47da59

> gpdl: Add 'jbig2' language implementation.
> gpdl/gpdl.mak
> gpdl/jbig2top.c
> pcl/pl/plimpl.c
> windows/ghostpdl.vcproj

2019-11-20 19:01:31 +0000
Robin Watts <Robin.Watts@artifex.com>
0c30c4cda3c2487ce52f79a952e3d0febef1d8bd

> Remove some dead code/variables from tifftop.c
> gpdl/tifftop.c

2019-11-21 11:20:49 -0800
Michael Vrhel <michael.vrhel@artifex.com>
7043e985298f75291e1fc25ad272140be31ffe6d

> Ghostscript Bug 701324. Improved robustness of lcms2mt
> lcmsmt will give up if it can't find the perceptual MLUT.
> This fix will have it check to see if the colorimetric or
> saturation intents are present also.
> lcms2mt/src/cmsio1.c

2019-11-21 10:45:59 -0800
Michael Vrhel <michael.vrhel@artifex.com>
aa30c0798d32decfd99ff8149553221917d4301e

> Use gp_fwrite instead of fwrite.
> base/gsicc_manage.c

2019-11-21 08:40:02 -0800
Michael Vrhel <michael.vrhel@artifex.com>
4640b5abd48430bfc76cc4e98cd626aa64075537

> Bug 701717 Remove redundant check.
> base/gdevp14.c

2019-11-19 15:40:02 +0000
Chris Liddell <chris.liddell@artifex.com>
9189e54333d33104a0de8aa92b1c5a7662762048

> JBIG2_CFLAGS/JPX_CFLAGS handling and remove commented out code
> The JBIG2_CFLAGS and JPX_CFLAGS allow a user to tweak the CFLAGS specific to
> the JBIG2 and JPX/JPEG2000 decoders respectively.
> There was also some commented out code that, with the above tweak, is no
> longer required to be there.
> configure.ac

2019-11-06 13:29:19 +0000
Chris Liddell <chris.liddell@artifex.com>
84a1bd8c73d740022877a5911851b8521ecc7458

> Bug 701440: only include libs calling pkg-config for freetype
> Only have the -l options, not the -L ones because they confuse genconf
> configure.ac

2019-11-06 12:43:09 +0000
Chris Liddell <chris.liddell@artifex.com>
aaea09a9a0e357b2784536b8476f4ab4fee19b64

> Allow configure to set size etc for size_t in arch.h
> arch/arch_autoconf.h.in
> configure.ac

2019-11-06 11:30:17 +0000
Chris Liddell <chris.liddell@artifex.com>
64a35dc73ee8256421b1dd2760be0c73c05eadb8

> Bug 701439: use pkg-config for libidn
> If pkg-config is available, and knows about libidn, use it to get the CFLAGS and
> LIBS, otherwise fall back to the AC_CHECK_LIB/AC_CHECK_HEADER method
> configure.ac

2019-11-06 10:44:16 +0000
Chris Liddell <chris.liddell@artifex.com>
317c0154a8141b8dde6e303f1e18a95e01f8ee33

> Bug 701689: CPPFLAGS for aux tools when cross-compiling
> Introduce CPPFLAGSAUX
> Credit to Marvin Schmidt
> configure.ac

2019-10-29 12:45:17 +0000
Chris Liddell <chris.liddell@artifex.com>
c7c6043bde1517e8fd6d645d7c34142aec462248

> Spaces should be tab
> base/gs.mak

2019-10-21 10:45:56 +0100
Chris Liddell <chris.liddell@artifex.com>
2d84ecc57837785b566ebd9d5909ba9edc9d697f

> Use caller defined pkg-config and cups-config unconditionally
> In an effort to better handle cross-compilation, we use a check combining
> AC_PATH_TOOL() and AC_PATH_PROG() - where AC_CHECK_TOOL() will first attempt to
> find the requested tool *with* a target-triplet prefix (for example,
> "x86_64-linux-gnu-pkg-config") and if that fails, it will fall back to the
> unadorned tool (e.g. "pkg-config"). If we are cross-compiling, and both
> AC_PATH_TOOL() and AC_PATH_PROG() return the same value, we assume that
> AC_PATH_TOOL() has fallen back to the default, non-cross-compile version, and we
> disable using the given tool.
> We do this for both pkg-config and cups-config.
> This does not work well for every cross-compile environment, however, since not
> all use the convention of the target triplet prefix.
> We already allowed the caller to specify both a pkg-config and cups-config to
> use, but we still applied the above outlined test.
> Now, when the tool is explicitly specified, do *not* do the
> AC_PATH_TOOL()/AC_PATH_PROG(), assume the caller knows what they are doing, and
> just go ahead and use it.
> Additionally, for cups-config, if the caller explicitly specified a cups-config,
> and/or explicitly set --enable-cups then make not finding the cups libraries a
> configure hard fail. By default, we'll still just warn, and exclude the cups
> devices.
> configure.ac

2019-10-18 09:46:03 +0100
Chris Liddell <chris.liddell@artifex.com>
327dc8943c0aac1c7be7a1fb6e93346b61cd0900

> Bug #699331: better support for cross-compiling
> This is mainly moving from using uname to identify the the target platform,
> to using the 'host' value to identify the target platform, and 'host' and
> 'build' values to know when we're cross-compiling.
> There are also a couple of tweaks related to cross-compiling to MSYS.
> Also, make double sure API symbols are always visible. This affects builds with
> gcc and compatible compilers.
> Remove use of $cross_compiling variable
> Credit to djcj for most of the changes
> .gitignore
> Makefile.in
> autogen.sh
> base/gp_unix.c
> base/gsutil.c
> base/lib.mak
> base/unix-dll.mak
> configure.ac
> pcl/pl/pjparse.c
> psi/iapi.h

2019-11-21 14:58:49 +0000
Chris Liddell <chris.liddell@artifex.com>
e20cd8d8fc1f40bf4218c18e545ca4ddb175c348

> Remove gprf device from Windows makefile
> psi/msvc.mak

2019-11-21 11:05:36 +0000
Chris Liddell <chris.liddell@artifex.com>
7a56ef4aed70a50bcd7731b61e59850e98d08a4d

> Ensure paths from Fontmap end in a directory separator
> Since it's normal for multiple font files to be grouped together in a directory,
> we strip the file name off, and add just the directory to the permit read list,
> rather than flood the list with every font file.
> The problem is, we weren't appending the directory separator character showing
> the directory was reading permitted.
> This commit does that.
> Also, add extra detail to the documentation about this aspect of file
> permissions lists.
> Resource/Init/gs_fonts.ps
> doc/Fonts.htm
> doc/Use.htm

2019-11-20 15:24:28 -0800
Michael Vrhel <michael.vrhel@artifex.com>
5e60fc862a73898ce048730d0c23c00b9ddb5578

> Bug 701660 Trans. Text knockout missing ET
> The file has contents that look like this
> BT
> stuff
> BT
> stuff
> ET
> more stuff
> The first BT meets the conditions to push the text group.
> Unfortunately it is missing the ET, so the group is never popped.
> These fixes will make sure that if we are in a text group and
> encounter another BT we popped the current text group.
> base/gdevp14.c
> base/gstrans.h

2019-11-20 13:15:18 +0000
Ken Sharp <ken.sharp@artifex.com>
d7118262b44939688c9143c278b8c76c6c620171

> Remove trailing whitespace
> gpdl/tifftop.c
> pcl/pcl/pcfrgrnd.c
> pcl/pxl/pxpthr.c

2019-11-20 12:32:06 +0000
Robin Watts <Robin.Watts@artifex.com>
31c4abe348de980ff7922e28f05cc3f788fab29a

> Remove gproof device.
> configure.ac
> devices/devs.mak
> devices/gdevgprf.c
> windows/ghostscript.vcproj

2019-11-20 11:04:43 +0000
Julian Smith <jules@op59.net>
1a5a05cf164f6657e3cc52f6fa31524ed190b981

> Coverity 95049: stop coverity taints for jbig2_get_int16() etc.
> jbig2dec/jbig2.c

2019-11-20 10:34:33 +0000
Julian Smith <jules@op59.net>
9a26c1ee0ef8db26ba79f6804a4f09e1c88cb234

> Coverity 350210: removed superflous extra param to jbig2_error().
> jbig2dec/jbig2_segment.c

2019-11-20 10:24:09 +0000
Julian Smith <jules@op59.net>
9d8f69e1e37475775917e71ba9bf82b7a2098942

> Coverity 350166: stop coverity taint warnings for get_u32_big_endian().
> base/gsiorom.c

2019-11-20 10:19:46 +0000
Julian Smith <jules@op59.net>
09d9c492f135ceeb6d95323c1b340b1fc03f15ad

> Coverity 341108: removed special coverity comment that didn't work.
> base/gp_unifs.c

2019-11-20 10:13:03 +0000
Julian Smith <jules@op59.net>
d79e80b43f388d1e9dd53d86466e04bdb2e6be25

> Coverity 102214: stop coverity worrying about pl_get_int16() etc.
> These fns use byte swapping, which makes coverity think that they return
> tainted data, and also that they taint the input buffer.
> pcl/pl/plvalue.c

2019-11-19 17:58:10 +0000
Julian Smith <jules@op59.net>
b74cf2eff085b9270d26818e9064450ac4da41f9

> Coverity 350199: try to stop coverity from thinking skip_white_pixels() taints buffer.
> base/scfe.c

2019-11-19 17:30:52 +0000
Julian Smith <jules@op59.net>
763a96187a286432e3c90b564a2031278e3688d0

> Coverity 350190, 350208: make raster unsigned, to avoid sign extension issue.
> base/gsovrc.c

2019-11-19 19:13:40 +0000
Robin Watts <Robin.Watts@artifex.com>
1759596a7499d27e3d289bbff4c45f9206ad4798

> Followon to fix for bug 701877.
> This changes the 'extern' definitions for
> {Single,Double,Treble,Quad}GlyphList to be more correct. This
> enables us to use the simple castless form in the initialisations.
> This works nicely in Visual Studio, and will hopefully assuage
> Coverity.
> devices/vector/gdevpdfu.c
> devices/vector/gdevtxtw.c

2019-11-19 16:35:50 -0800
Michael Vrhel <michael.vrhel@artifex.com>
c5eb242fa82585aa21371919ca4a7a2d4d4effc3

> Make sure blend mode is passed to tile with pdfi
> base/gxpcmap.c
> base/gxpcolor.h
> psi/zpcolor.c

2019-11-19 18:13:08 +0000
Robin Watts <Robin.Watts@artifex.com>
69bdf79e10370ed16a17a346690fd630272f7346

> gpdl: Add tiff "interpreter" to gpdl.
> Makefile.in
> configure.ac
> gpdl/gpdl.mak
> gpdl/tifftop.c
> pcl/pl/plimpl.c
> psi/msvc.mak
> windows/ghostpdl.vcproj

2019-11-19 18:11:55 +0000
Robin Watts <Robin.Watts@artifex.com>
b5956ac8be8c923ad9e9fd3045724a5579cf4dce

> gpdl: Fix compiler flags for pwgtop.c
> Don't need to pass the JPEG include directory here.
> gpdl/gpdl.mak

2019-11-19 18:10:54 +0000
Robin Watts <Robin.Watts@artifex.com>
0329372164611fdff22f8c02201ff1fbbf94aae7

> gpdl: Fix jpeg/pwg behaviour with varying resolutions.
> I thought this worked before, but tests revealed that it was
> broken.
> gpdl/jpgtop.c
> gpdl/pwgtop.c

2019-11-18 11:36:30 +0000
Robin Watts <Robin.Watts@artifex.com>
cd8747382f47393efd0f0013700a8294c0ded15c

> Slight reorganisation of gpdl interpreter files.
> Rather than having each different "language" have a 'top' file
> in gpdl/foo/footop.c, move them to be gpdl/foo.c. Extra directories
> seem overkill at this point, and it simplifies the Makefile
> slightly.
> Also, rename IMG to JPG.
> Makefile.in
> gpdl/gpdl.mak
> gpdl/jpgtop.c
> gpdl/psitop.c
> gpdl/pwgtop.c
> pcl/pl/plimpl.c
> windows/ghostpdl.vcproj

2019-11-19 16:40:16 +0000
Julian Smith <jules@op59.net>
e1b7dbc95945ef2afa38faeebfda56830f2762ab

> Coverity 350182: check for error before dereferencing ptr from gs_cspace_build_ICC().
> This allows us to remove the check for pcs == NULL after pcs has already been
> dereferenced, which was the coverity issue.
> Also fixed gs_cspace_build_ICC() to return gs_error_VMerror if
> gs_cspace_alloc() fails - was returning zero with *ppcspace out-param set to
> NULL. Have checked that all callers don't rely on the out-param being NULL to
> indicate error. Though some of them make no checks at all.
> base/gdevp14.c
> base/gsicc.c

2019-11-19 16:07:23 +0000
Julian Smith <jules@op59.net>
e93430d762400247cdc4550be403a1f7c291112d

> Coverity 350180: change gp_fmode_binary_suffix from char[] to char*.
> Am hoping this will persuade Coverity that it is zero-terminated and not
> zero-length, and thus safe to pass to strncat().
> base/gp.h
> base/gp_dosfs.c
> base/gp_ntfs.c
> base/gp_os2fs.c
> base/gp_unifn.c
> base/gp_vms.c

2019-11-19 15:19:16 +0000
Julian Smith <jules@op59.net>
bb2c2fbbc96b1f2de8e454ecb2adf3e58ddb52c3

> Coverity 341108: disable mktemp() SECURE_TEMP issue, as mkstemp() not available.
> base/gp_unifs.c

2019-11-19 14:50:01 +0000
Julian Smith <jules@op59.net>
a4c44cc7579ab80a1d49d721fad48e1ed9bbe976

> Coverity 323321: remove unused goto label and 'code' variable from template_mem_transform_pixel_region_render_landscape().
> The label and variable appear to have been copied from a similar function, but
> they are never used, and actually it looks like this fn can't fail.
> base/gdevdrop.c

2019-11-19 13:06:48 +0000
Julian Smith <jules@op59.net>
f804ebfa526bd36a808319225488fe9de416f350

> Coverity: add additional annotation to jbig2_get_uint32().
> Coverity thinks that jbig2_get_uint32() taints the buffer that it is passed,
> which causes coverity issues in calling code.
> So this commit adds an addional coverity annotation to ensure the buffer is not
> tainted.
> Am not 100% sure how to specify multiple annotations, but apparently doing
> things like '// coverity[ foo, bar ]' does not work, so we put the new
> annotation in a separate comment.
> jbig2dec/jbig2.c

2019-11-19 12:26:18 +0000
Ken Sharp <ken.sharp@artifex.com>
7ff87e872888da0f5cfd392b3f8b90fa7ad0e27c

> Fix the Lexmark contributed device
> Bug #701905 "heap-buffer-overflow at contrib/gdevlx32.c:1509 in convbuf"
> The problem here is actually much earlier. In encode_bw_buf() there is a
> comment (line 1771) about starting before the first non-white pixels
> in order to "give the head a little more room to accelerate properly".
> If the first non-white pixel is less than 3 pixels from the left edge
> of the raster, this will cause the calculation of 'left' to become
> negative. It seems to me this will immediately corrupt the data. In
> addition right is calculated in a similar fashion, if right is also
> close to the right edge of the raster, then we can end up with numcols
> being more than the width of the raster.
> This argument is passed to convbuf() and that tries to read off the end
> of the input data, because numcols exceeds the bytes in the raster.
> I'm pretty dubious about this whole piece of code but since I don't
> have a printer to test with I'm reluctant to make major changes. This
> commit simply clamps left to 0 and right to the right edge of the
> raster. The comment implies that the extra spacing probably isn't useful
> and certainly suggests that removing it won't be harmful.
> contrib/gdevlx32.c

2019-11-18 17:36:54 +0000
Julian Smith <jules@op59.net>
7e50bda19813d11555ff1ab4f7cb5c3e55ff0653

> Coverity 341025: removed unreachable line of code.
> pcl/pl/plmain.c

2019-11-18 17:34:49 +0000
Julian Smith <jules@op59.net>
05cfc3afb00404ddfd3c1eac635f369491995e5b

> Coverity 331894: check return from gs_bbox_transform().
> pcl/pl/plchar.c

2019-11-18 17:32:05 +0000
Julian Smith <jules@op59.net>
81e179af142575eab21633b2023e752e1e244c9a

> Coverity 331893: check return code from gs_bbox_transform().
> base/gxclimag.c

2019-11-18 17:28:42 +0000
Julian Smith <jules@op59.net>
d57aff5bbdb206f00e4b0cb3b324616be10d358e

> Coverity 323321: avoid dead code.
> base/gdevdrop.c

2019-11-18 15:24:44 +0000
Julian Smith <jules@op59.net>
3aa36ebc3df83d339695fff58a73332d5304c47d

> Coverity 323317, 323320: avoid dead code.
> Fixes coverity errors for transform_pixel_region_render_landscape() and
> transform_pixel_region_render_skew().
> base/gdevdflt.c

2019-11-18 14:49:38 +0000
Julian Smith <jules@op59.net>
4a1a4e8ad165e678d3affab483460ec8b926d5dd

> Coverity 261213: make pxPassthrough_pcl_state_nonpage_exceptions() check return from pcl_set_graphics_state().
> Also changed pxPassthrough_pcl_state_nonpage_exceptions() to return an int, and
> made all of its callers check the return value.
> pcl/pxl/pxpthr.c
> pcl/pxl/pxpthr.h

2019-11-18 14:38:10 +0000
Julian Smith <jules@op59.net>
1ee350a81d5799785ab53b3eece6e853cc4c607b

> Coverity 261210: wrap call of pcl_mark_page_for_path() in hpgl_call().
> pcl/pcl/pgdraw.c

2019-11-18 12:31:33 +0000
Julian Smith <jules@op59.net>
884690a576e16043e674efb9d047a00760ac8443

> Coverity 135902: remove support for USE_MAP_TYPE_IN_SPECIFICATION.
> We now always treat map type 0 as map type 1. As suggested by henrystyles.
> This will fix coverity issue.
> pcl/pcl/pctext.c

2019-11-18 12:20:17 +0000
Julian Smith <jules@op59.net>
9763a006f7c566e92f60e799fb2270c09807e9c8

> Coverity 135902: Fixed indentation in char_is_printable().
> This commit has no output from 'git diff -w', and is in preparation for next
> commit that fixes coverity issue.
> pcl/pcl/pctext.c

2019-11-15 16:55:22 +0000
Julian Smith <jules@op59.net>
dd84fd3a36d0ef809ed697ed12f1bb04655a0388

> Coverity 102254: avoid integer division when calculating double value.
> It's possible that this could alter behaviour, but clusterpush showed no
> additional regressions.
> pcl/pcl/pctext.c

2019-11-18 12:08:38 +0000
Julian Smith <jules@op59.net>
a631e0d40337da58ba596a9499b71c1d7888c9d5

> Coverity 126570: build_foreground(): return error if pindexed is NULL.
> Previously we would dereference pindexed which would inevitably SEGV.
> pcl/pcl/pcfrgrnd.c

2019-11-18 11:25:16 +0000
Julian Smith <jules@op59.net>
6fbd278d11e9ea567ea2dce0c7aa02e706d9a9e2

> Coverity: try using C++ comment style for 'coverity[ -tainted_data_return ]'
> E.g. for:
> https://scan4.coverity.com/reports.htm#v46841/p11408/fileInstanceId=69767421&defectInstanceId=11904740&mergedDefectId=95049
> jbig2dec/jbig2.c

2019-11-18 14:55:29 +0000
Ken Sharp <ken.sharp@artifex.com>
e05d0e17c75adab181413c8bf5bf6760c76683e4

> 'fix' buffer overrun in eps9mid device leading to SEGV
> Bug #701853 "Segmentation fault at base/gsbitops.c:121 in bits_fill_rectangle"
> The actual fault here is considerably earlier in the actual sequence of
> execution.
> The device(s) check for consecutive unchanged raster lines, and only
> emit new lines when two lines differ. In addition under some conditions
> the device can 'consolidate' runs by OR'ing the data in a raster with
> the same data in the next raster (I don't understand why this is needed)
> In order to ensure that there is sufficient data (24 rasters) for the
> process to complete safely the raster data is copied into a buffer which
> is allocated large enough, and is set to zero if less lines than 24 are
> read from the device.
> However the code doing the OR'ing wasn't using this memory, it was using
> the single scan line pulled from the device to check whether consecutive
> lines are the same. This caused it to run off the end of that buffer and
> overwrite the 'line_ptrs' member of the device structure. *Much* later
> we would attempt to use the corrupted data and that would cause a SEGV.
> fixed by making the code OR'ing the lines use the workign buffer, as
> (I think) it should.
> devices/gdevepsn.c

2019-11-17 19:48:10 +0000
Ken Sharp <ken.sharp@artifex.com>
da03855bf9ca18eab05d4ac870d73f457758a77f

> txtwrite - fix buffer overflow
> Bug #701877 "heap-buffer-overflow at devices/vector/gdevtxtw.c:2114 in txt_add_fragment"
> We were trying to read too many entries from the enumerator 'Widths'
> array, because we were reading the number of Unicode code points,
> instead of the number of character codes.
> At the same time.....
> re-instate the code which uses & on the glyph lists and casts them to
> appropriate pointers. While gcc happily works with the code that was
> modified to make Coverity happy, Visual Studio absolutely does not.
> In order to make Visual Studio happy we do need the crazy pointers and
> casting. I think this is wrong, but this way works on both compilers
> and I couldn't find any other construction which did.
> devices/vector/gdevtxtw.c

2019-11-16 10:00:58 +0000
Ken Sharp <ken.sharp@artifex.com>
0aa9d4f8237f7a0b459fc567e76ab8f0c4c2eebd

> Coverity ID 350946
> Not checking the return from gdev_prn_get_bits in two places
> Again, no way for me to see this CID on the Coverity web interface.
> contrib/gdevlx7.c

2019-11-16 09:55:36 +0000
Ken Sharp <ken.sharp@artifex.com>
ea274a722040b1186374a96d61715ae96d58c36b

> Coverity IDs 350943, 350942 and 350947
> Not checking the return value from gdev_prn_get_bits() in three places.
> Again, cannot see this on the Coverity web interface.
> contrib/gdevlx32.c

2019-11-16 09:52:40 +0000
Ken Sharp <ken.sharp@artifex.com>
3a913d9dc801508b19a8d5605e785852e1bfb082

> Coverity ID 350944
> Not checking the return value from gdev_prn_get_bits()
> Slightly worryingly, I have the email from Coverity describing this
> as a new issue, but I cannot persuade the Coverity web interface to
> display it.
> contrib/gdevmd2k.c

2019-11-16 09:48:23 +0000
Ken Sharp <ken.sharp@artifex.com>
8bf3152fe37368b49dcd23535a407c632d7157d2

> Coverity IDs 350945 and 350948
> In these routines code can only ever be 0 (OK) or 1 (error). So instead
> of testing for code < 0 we need to test for code > 0 for an error.
> devices/gdevicov.c

2019-11-16 09:31:32 +0000
Ken Sharp <ken.sharp@artifex.com>
5a4c29eeea1f0b63cc0b2fff3a1ca0f5b2d143b6

> Coverity IDs 350163, 350949
> previous fix for 350163 missed additional unchecked use of xps_fseek()
> In addition; copying the cleanup code was not a complete fix, because
> the existing cleanup code had a resource leak which Coverity did not
> previously complain about.....
> Fix that too
> xps/xpsjxr.c

2019-11-15 18:50:56 +0000
Robin Watts <Robin.Watts@artifex.com>
7fc7881b00a43fe1017e593846a0baf28e8837db

> Add simple PWG "interpreter" for gpdl.
> base/spwgd.c
> gpdl/gpdl.mak
> gpdl/pwg/pwgtop.c
> pcl/pl/plimpl.c
> windows/ghostpdl.vcproj

2019-11-15 18:49:23 +0000
Robin Watts <Robin.Watts@artifex.com>
161adc70e0d6625618c5a6afcb5e04161acc2e2c

> Squash a warning about an ininitialised variable.
> jpegxr/cw_emit.c

2019-11-15 18:48:55 +0000
Robin Watts <Robin.Watts@artifex.com>
b8de03bdb8696517bff0259e827ece4f5746663c

> Squash a float -> int warning.
> contrib/japanese/gdevlbp3.c

2019-11-15 18:48:26 +0000
Robin Watts <Robin.Watts@artifex.com>
58bee0ad2c67888a52fa02e31de3120673525fda

> Squash a double -> float warning.
> contrib/gdevdj9.c

2019-11-13 18:08:20 +0000
Robin Watts <Robin.Watts@artifex.com>
372e4f29d3fcbfeaa83a5ee8cc530cbb948edab7

> Squash a warning in gdevcif due to dropping const.
> devices/gdevcif.c

2019-11-15 17:30:23 +0000
Ken Sharp <ken.sharp@artifex.com>
194c53ed02d657159a7be894b6d4b54ce1f435d4

> Coverity ID 350163 unchecked return value
> Check the return value of xps_fseek and throw an error if it fails.
> xps/xpsjxr.c

2019-11-15 12:32:50 +0000
Julian Smith <jules@op59.net>
83c6e520ee6eddeaa1e548e519eb1b42941e3153

> Coverity 102206: use snprintf() to avoid unsafe strcpy() and strcat().
> pcl/pl/pjparse.c

2019-11-15 12:24:36 +0000
Julian Smith <jules@op59.net>
76c088b2b5468c1551c4636dc9d20f5b1ea5da36

> Coverity 102205: cast ushort to final expression type (long) before bit-shift, to avoid sign extension.
> pcl/pl/pllfont.c

2019-11-15 11:49:17 +0000
Julian Smith <jules@op59.net>
b51e2be557128054b0f1e8f6eb4c3b7de506cca2

> Coverity 102204: cast byte to long to avoid possible sign extension.
> pcl/pcl/pcwhtidx.c

2019-11-15 11:30:34 +0000
Julian Smith <jules@op59.net>
dd95eb235f00a600f8b8b99b8929e597283fa96c

> Coverity 102189: removed less-than-zero comparison of unsigned.
> pcl/pl/plfont.c

2019-11-15 11:27:53 +0000
Julian Smith <jules@op59.net>
95706a3ced4f1cfa50b2ea48f0095ed9423bafe5

> Coverity 102173: removed unnecessary comparisons against hpgl_rm_character.
> pcl/pcl/pgdraw.c

2019-11-15 14:22:04 +0000
Ken Sharp <ken.sharp@artifex.com>
5f24a32f0cc4513dfb9825900d561b3a6771b87c

> Coverity ID 350216 - prevent dangling pointer
> The variable pdcs is declared an immediately initialised to be
> dsc->dcs2. Coverity correctly points out that if dsc->page_count is 1
> we enter dsc_alloc_string, which can call dsc_reset() where,
> if dsc->dcs2 is set, it will be freed and dsc->dcs2 will be set to
> Null, leaving pdcs dangling.
> By deferring the assignment of pdcs until it is actuallused we can
> be certain that it is valid.
> psi/dscparse.c

2019-11-15 13:28:38 +0000
Ken Sharp <ken.sharp@artifex.com>
de9dc99614f86e4aaa0a447766a58447e76ca8c1

> Attempted fix for Coverity ID 350194
> Thanks to Robin for pointing me at the right bit of code.
> There was a pointer cast and address of (&) on an array which was
> already a pointer. This is, of course, silly, so remove the cast and
> &.
> At the same time, the quad_glyph_list was using signed shorts to hold
> the Unicode points, when it should have been using unsigned shorts, so
> fix that here too.
> devices/vector/gdevagl.h
> devices/vector/gdevtxtw.c

2019-11-15 08:26:36 +0000
Chris Liddell <chris.liddell@artifex.com>
0ea433a1a172298eda11203d698ce6fe69be58d2

> Support CIDFSubstFont being a path/file
> Preivously, to use a custom CIDFont substitute in a custom location, it was
> necessary to both both CIDFSubstPath (for the location) and CIDFSubstFont
> (the file name).
> We'll now check the CIDFSubstFont value and if it looks like it includes a path
> (i.e. contains a directory/file separator string) then we'll use it as is,
> ignoring the CIDFSubstPath
> Resource/Init/gs_cidfm.ps

2019-11-14 13:22:11 +0000
Chris Liddell <chris.liddell@artifex.com>
51aff033bdc8744adfd86ce8b35ef00f23621de2

> Bug 701903: (ps2write) clean up image enumerator streams.
> At the end of an image (especially if the "end" is because of an error
> condition) make sure we clean up any streams created for the handling of the
> image data.
> This saves leaving the streams around for gc to cleanup, and avoids a problem
> where a special purpose stream (for color images) holds a reference to a
> color space and graphics state either or both of which could be freed by a
> Postscript restore before the garbager gets called to deal with unreferenced
> objects.
> devices/vector/gdevpdfi.c

2019-11-14 11:20:40 +0000
Ken Sharp <ken.sharp@artifex.com>
33f4f0c0ba5449fd535061e785090bc57849ae51

> PDF interpreter - don't ignore SUBSTFONT
> The PDF interpreter attempts to find a 'better' match for missing fonts
> by using a list of TrueType mappings (eg ArialMT, CourierNew) and a
> list of mappings (gs_font.ps, /.substitutefaces)
> Failing to find a match there it attempts to use the FontDescriptor
> Flags if present. As far as I can see that basically means we use
> Times-Roman for serif fonts and Helvetica for sans serif.
> This commit checks to see if SUBSTFONT is set. If it is we ignore all
> this nonsense and simply use the substitute font the user told us to.
> Otherwise we continue as before.
> The diff is actually very simple, but the routine was very large so
> I decided to move the actual substitution code out into a separate
> function, to simplify the logic in pdffindfont which makes the
> differences appear substantial. All that has really changed is that the
> code to do the substitution, after checking for the existence of a
> FontDescriptor, checks to see if SUBSTFONT is defined. If it is we
> behave as if the font had no FontDescriptor and use the normal font
> substitution machinery.
> Resource/Init/pdf_font.ps

2019-11-07 15:36:55 +0000
Robin Watts <Robin.Watts@artifex.com>
98a8b291b135d49ffca23d9a289786971cf33a12

> img language implementation
> JPEGs only at this point.
> Makefile.in
> gpdl/gpdl.mak
> gpdl/image/imagetop.c
> pcl/pl/plimpl.c
> psi/msvc.mak
> windows/ghostpdl.vcproj

2019-11-07 15:36:55 +0000
Robin Watts <Robin.Watts@artifex.com>
91b104936ec55b3f1f22673d7e286ff67e4e2475

> Public build changes to accommodate private URF support.
> This includes build rubrik for devices to generate URF files
> (urfgray, urfrgb, urfcmyk), a decompression filter for the
> rle variant used in URF files and a urf "language" interpreter
> implementation for gpdl.
> Note, this is only the build framework for these things. The
> actual implementation code lives in the private 'urf'
> git module, and will be activated automatically as part of
> the build if it is in position at configure time.
> Makefile.in
> base/lib.mak
> base/unix-gcc.mak
> configure.ac
> devices/devs.mak
> gpdl/gpdl.mak
> pcl/pl/plimpl.c
> psi/int.mak
> psi/msvc.mak
> psi/zfilter.c
> windows/ghostpdl.vcproj
> windows/ghostscript.vcproj

2019-11-13 16:35:05 +0000
Ken Sharp <ken.sharp@artifex.com>
af558a708b40a78eef9c0bc5b2ae229d771a3537

> pdfwrite - Fix XMP emission
> Bug #701895 "Ghostscript should leave the rdf:description rdf:about attribute empty (XMP Metadata)"
> See the bug thread, it appears this value should be empty and this
> commit makes that change.
> devices/vector/gdevpdfe.c

2019-11-11 20:14:36 -0800
Ray Johnston <ray.johnston@artifex.com>
f63270230f329c6e89375af18d2bf2930421174a

> Fix devices that ignore return codes from gdev_prn get_bits & copy_scan_lines
> Discovered these when working on bug 701845 'devicen' device. Checking
> uncovered a plethora of other places that used one of these functions
> assuming success.
> Also the gdev_prn_copy_scan_lines had places that assumed the return code
> was a valid line_count, so if negative, could memset many lines in front of
> an allocated buffer.
> The code in a few of these usages is strange, and we don't have a way to
> check them, so this may not match the original intent.
> Also, while perusing all of these files, check devices for alloc's that
> assume success and fix them (usually return gs_error_VMerror).
> base/gdevdevn.c
> devices/gdev3852.c
> devices/gdev4081.c
> devices/gdev4693.c
> devices/gdev8510.c
> devices/gdevatx.c
> devices/gdevbit.c
> devices/gdevbj10.c
> devices/gdevbmp.c
> devices/gdevccr.c
> devices/gdevcdj.c
> devices/gdevcfax.c
> devices/gdevcif.c
> devices/gdevclj.c
> devices/gdevcljc.c
> devices/gdevdjtc.c
> devices/gdevdm24.c
> devices/gdevepsc.c
> devices/gdevepsn.c
> devices/gdevescp.c
> devices/gdevgprf.c
> devices/gdevhl7x.c
> devices/gdevicov.c
> devices/gdevifno.c
> devices/gdevimgn.c
> devices/gdevjbig2.c
> devices/gdevjpx.c
> devices/gdevl31s.c
> devices/gdevlbp8.c
> devices/gdevlj56.c
> devices/gdevlp8k.c
> devices/gdevlxm.c
> devices/gdevmgr.c
> devices/gdevn533.c
> devices/gdevokii.c
> devices/gdevpbm.c
> devices/gdevpdfimg.c
> devices/gdevperm.c
> devices/gdevphex.c
> devices/gdevpjet.c
> devices/gdevpsim.c
> devices/gdevrinkj.c
> devices/gdevsppr.c
> devices/gdevstc.c
> devices/gdevtifs.c
> devices/gdevtknk.c
> devices/gdevtsep.c
> devices/gdevwpr2.c
> devices/gdevxcf.c
> devices/gdevxcmp.c

2019-11-13 13:51:27 +0000
Julian Smith <jules@op59.net>
97277fcf0f70d482481ac329ce473e5687e7a935

> Bug 701906: Fix duplicate call to tiff_from_filep() that caused leak of TIFF object.
> The code in tiff_rgb_print_page() did tfdev->tif = tiff_from_filep(), but
> then calls gdev_tiff_begin_page() which does the same thing, overwriting the
> original tfdev->tif.
> Also changed tiff12_print_page() as it looks to have the same problem.
> This fixes:
> ./sanbin/gs -dBATCH -dNOPAUSE -dSAFER -sOutputFile=tmp -sDEVICE=tiff48nc ../bug-701906.pdf
> devices/gdevtfnx.c

2019-11-13 14:03:25 +0000
Ken Sharp <ken.sharp@artifex.com>
6690c60c3e1be875134150fa4909bff0de7d583f

> pdfwrite - For PDF input, copy any UserUnit to the output
> If the input is PDF, and the input file uses the ugly UserUnit hack to
> work around MediaBox limits in Acrobat, and the CompatibilityLevel of
> the output is at least PDF 1.6, then do not apply the UserUnit to the
> MediaBox and do not scale the content. Instead pass the value of
> UserUnit to the pdfwrite device and insert it into the output page.
> We use a special_op to inquire whether the device would like us to pass
> it the UserUnit. The pdfwrite device checks the current PDF level
> being emitted and either returns true, or false if too low a level is
> requested.
> If it returns true the PDF interpreter does not apply the UserUnit
> scaling but instead uses a second special_op to inform the device what
> of the value of UserUnit.
> The pdfwrite device adds any non-unity value of UserUnit to the page
> dictionary when emitting it.
> If -dNoUserUnit is set we neither apply the UserUnit scaling nor pass it
> to the device.
> Resource/Init/pdf_draw.ps
> Resource/Init/pdf_main.ps
> devices/vector/gdevpdf.c
> devices/vector/gdevpdfb.h
> devices/vector/gdevpdfp.c
> devices/vector/gdevpdfx.h

2019-11-12 15:51:23 +0000
Julian Smith <jules@op59.net>
9e1d2f76cabf84576424af0c38dceef5881c2b21

> jbig2_hd_new(): return error if params->GRAYMAX is large enough that N wraps to zero.
> This was noticed when investigating coverity warnings about params->GRAYMAX
> being tainted.
> jbig2dec/jbig2_halftone.c

2019-11-12 15:48:50 +0000
Julian Smith <jules@op59.net>
e6d0fcd87934f01d4fb3c3029558fea134fbd086

> Attempt to quieten coverity complaints about tainted data from jbig2_get_int32() and jbig2_get_uint32().
> E.g. see Coverity p11408:94824.
> jbig2dec/jbig2.c

2019-11-12 11:22:41 +0000
Julian Smith <jules@op59.net>
d11a43b64a2e623aebdfa34f8ee992887dc5b2b2

> Coverity p11408:350203: Stop coverity overflow warning about array of floats.
> &lutatobparts->matrix->cu.u points to something the size of three floats,
> but add_matrixwithbias() takes pointer to nine floats, which makes coverity
> complain.
> This fix changes things so that we pass a pointer to something nine floats in
> size, which satisfies coverity.
> base/gsicc_create.c

2019-11-12 10:29:16 +0000
Chris Liddell <chris.liddell@artifex.com>
24ec06a27df63297796a379c95ee5d4b39040410

> Bug 701894: fix the '--' and co options
> The --, -+ and -@ need to add the file argument to the permit read list
> before attempting to open and interpret them.
> psi/imainarg.c

2019-11-11 13:45:59 +0000
Julian Smith <jules@op59.net>
592fb032180aac0fc22a7c860ef116b38da8ca71

> Coverity p11408:350214: fix use of uninitialised 'file'.
> base/gpmisc.c

2019-11-11 13:41:29 +0000
Julian Smith <jules@op59.net>
7da60037b788bec4217f6ee7017e238f541714ae

> Coverity p11408:350217: avoid memcpy() with same buffers.
> pcl/pcl/pcindxed.c

2019-11-11 12:44:26 +0000
Julian Smith <jules@op59.net>
658e14023fa84232c569ecc5528b77fd35bcf290

> Coverity p11408:350197: fix issue by initialising 'file' to NULL.
> base/gpmisc.c

2019-11-11 11:17:57 +0000
Julian Smith <jules@op59.net>
11f8439f49a3704bb4506e02382a0e697e5edf8e

> Coverity p11408:350178: Stop coverity overflow warning about array of floats.
> base/gsicc_create.c

2019-11-11 12:00:20 +0000
Chris Liddell <chris.liddell@artifex.com>
a1747b9267b4aac28e256820c5cea37af299af86

> Make lack of freetype a hard error
> configure.ac

2019-10-24 10:09:55 +0100
Chris Liddell <chris.liddell@artifex.com>
37a322fb93c5cd1e96a4cad2ffccdc397f7c0ea5

> Reinstate Apple devices (gdevadmp.c) as contrib devices
> configure.ac
> contrib/contrib.mak
> contrib/gdevadmp.c

2019-11-11 10:21:13 +0000
Chris Liddell <chris.liddell@artifex.com>
aad7bcab6a3aedc4e2bfecd7b1e6bf893c299d0e

> Better solution for commit 68aeff88e95c
> This is a simplified (and fixed) solution for the problem addressed in commit
> 68aeff88e95c: instead of assiging to the 'fixed' type, then converting to
> ufixed (wrongly, in the original commit), just go straight to ufixed.
> This solves coverity issues: 350493 and 350492
> base/gxhintn.c

2019-11-11 10:42:11 +0000
Chris Liddell <chris.liddell@artifex.com>
2de09275898086e903a19812fd78e73381f7e71e

> Bug 695873: reverse search to auto-set GenericResourceDir
> A -I path like:
> /path/to/Resources/share/ghostscript/9.15/Resource/Init
> Would cause us to wrongly set GenericResourceDir and the ICCProfilesDir because
> in both cases we'd search the path for the string 'Resource', and end up using:
> /path/to/Resource
> To work better, this uses the new and non-standard rsearch operator to search
> the path backwards.
> I opted not to include the trailing directory separator at this stage because
> that complicates matters with platforms that uses different directory
> separators (Unix vs Windows vs OpenVMS, for example)
> Resource/Init/gs_lev2.ps
> Resource/Init/gs_res.ps

2019-11-09 12:51:05 -0800
Ray Johnston <ray.johnston@artifex.com>
c198ac5dcb26fadc53074525cabb413e5395cdba

> Clear out gs_gstate at the start of clist playback.
> There are some elements of the (stack based) gs_gstate that were not being
> set by either GS_STATE_INIT_VALUES_CLIST, or gs_gstate_initialize, so set
> the entire structure to 0 before setting the values we care about. This
> was prompted by a customer that has made modifications to the clist playback
> that relied on gs_gstate.color[0/1].color_space being NULL or valid, but
> since it is so quick and only happens once per band, go ahead and do it.
> base/gxclrast.c

2019-11-09 10:27:22 +0000
Ken Sharp <ken.sharp@artifex.com>
7174b69e6c0027277fe1a9ece341c3380fe7979d

> Fix PDF 2.0 /Square annotation appearance generation
> All the routines to generate annotation appearances are supposed to
> return a boolean value indicating whether an annotation has a valid
> Appearance (returns true, caller must run the appearance stream) or
> the appearance has been generated (false, caller must not attempt to
> run the appearance stream).
> The /Square annotation was failing to return false if there was no
> appearance and one had been generated.
> Resource/Init/pdf_draw.ps

2019-11-08 17:40:37 +0000
Julian Smith <jules@op59.net>
ba5b47dc979ca1590f280f482d432705e9b535bf

> Coverity p11408:350177: avoid use of uninitialised state.start.x.
> Probably not a problem in practise because we can't get gs_pe_closepat without
> earlier gs_pe_moveto or similar.
> base/gdevvec.c

2019-11-08 17:21:38 +0000
Julian Smith <jules@op59.net>
4a3401e5e4f5828c67d7c65f77a3bb0106753649

> Coverity p11408:350167: fixed use of uninitialised gp_file*.
> base/gpmisc.c

2019-11-08 16:40:00 +0000
Julian Smith <jules@op59.net>
f44249d69a36fa7233504bdb137af9ff5008ec37

> Coverity Coverity p11408:350165: try to stop coverity warning about array of floats.
> Coverity complains about passing &float to something that assumes it is
> float[9]. Trying explicit cast of base object to float*.
> base/gsicc_create.c

2019-11-08 16:25:01 +0000
Julian Smith <jules@op59.net>
2029235dc8997314c1925e5786212a6c7331f0cf

> Coverity p11408:350164: only call memcpy() if buffers are different.
> We could use memmove() instead, but this makes things a little clearer.
> pcl/pcl/pcindxed.c

2019-11-08 12:31:08 +0000
Julian Smith <jules@op59.net>
5605c6c6a9677013560a6a3c947f4b100eae4e09

> Coverity p11408:350160: attempt to avoid coverity issues when calling pl_dict_put().
> Coverity doesn't like hard-coded 32 for the size of 'short
> unicode_fontname[16]', so use sizeof().
> pcl/pl/pllfont.c

2019-11-08 15:13:50 +0000
Ken Sharp <ken.sharp@artifex.com>
95151ae3c3c63100bc7ae958f59b8096e7a0f211

> Improve handling of microscopic fonts with text rendering mode 3
> Bug #701875 "empty TIFF-file is generated when using -r300, correct output with -r72"
> In the past we've seen PDF producers set the text rendering mode to 3
> and then (goodness knows why) set a CTM where one of the scale factors
> is 0. In this case the scale factor isn't 0 but its absolutely minute,
> 5.3x10-6.
> This evades our existing code, so here we improve it; we check to see
> if the CTM scales in either direction by a really small amount instead
> of 0 (0.000001).
> In addition, we previously tried to patch up the CTM and use it anyway
> but really this is only going to make sense is one scale factor is
> tiny (or 0) and the other is sensible. If that's not the case then
> any displacement due to drawing the text will also be tiny. So lets
> simply ignore it.
> Resource/Init/pdf_ops.ps

2019-11-08 12:47:59 +0000
Chris Liddell <chris.liddell@artifex.com>
0f7653fd4f1d1c5bf36719efcd8464eafcd46faf

> Bug 701870: Use object number from Font rather than FontDescriptor
> In case where two CIDFont /Font objects share a /FontDescriptor, because the
> /Font objects can contain different details like /CIDSystemInfo contents and
> /CIDToGIDMap, if we use the object number from the /FontDescriptor to validate
> the instance of the font we should use, we can end up reusing a (Postscript)
> font when we shouldn't. This can result in garbled or missing glyphs.
> Resource/Init/pdf_font.ps

2019-11-08 12:08:52 +0000
Robin Watts <Robin.Watts@artifex.com>
6882df85d37819d849476cf2b4822a90e64d9b24

> Add a couple of FIXMEs to the xps interpreter.
> xps/xpsimage.c
> xps/xpstop.c

2019-11-08 12:08:24 +0000
Robin Watts <Robin.Watts@artifex.com>
b7fac758d046c82d65fa69dd2c4bc0f1cf9712bc

> Remove unused gpdlpsi.mak file.
> gpdl/psi/gpdlpsi.mak

2019-11-08 11:32:41 +0000
Julian Smith <jules@op59.net>
328d27b3cccc89c4ff60529106489a9a635f0f72

> Bug 701854: bj10v_print_page(): increase buffer by one byte to give space for sentinel.
> Fixes:
> ./sanbin/gs -r928 -sOutputFile=tmp -sDEVICE=bj10v ../bug-701854.ps
> contrib/japanese/gdev10v.c

2019-11-07 10:08:35 +0000
Chris Liddell <chris.liddell@artifex.com>
68aeff88e95ccfd1af430fe180597d624ad9f47e

> Old Type 1 hinter: protect against signed overflow
> To avoid overflow during hinting, we tweak the balance of the size of the
> coordinates and the scaling in the hinter (this is only dealing with coords
> so large that hinting is largely pointless anyway).
> But the code that does that didn't protect against signed overflow in the
> starting coordinates.
> This is a naive protection to prevent an infinite (or near so) loop, but
> a) it's old code that shouldn't be in use anymore, and b) in practice it will
> make no difference to rendering with coordinates that large.
> base/gxhintn.c

2019-11-06 14:17:33 +0000
Chris Liddell <chris.liddell@artifex.com>
713645137a2fc483e5509bfd0f92d7311faeb614

> Some more transparency ops doc tweaks
> doc/Language.htm

2019-11-07 16:55:15 +0000
Julian Smith <jules@op59.net>
6c3af6e12e4448b519d2b48c2047c0c83b3cf082

> Coverity issue 102147:323319: transform_pixel_region_render_skew(): don't return pointer to local data.
> base/gdevdflt.c

2019-11-07 16:18:32 +0000
Julian Smith <jules@op59.net>
66878fb30f37b06a532fdce39991f31642cdb09b

> Bug 701856: fix bad bracketting in original fix.
> devices/gdevepsn.c

2019-11-07 16:13:06 +0000
Julian Smith <jules@op59.net>
76db3df8090127482960b742f15831e59816a05e

> Coverity issue 102147: initialise gx_device_color::type.
> Might fix Coverity issue in base/gxiscale.c.
> base/gxiscale.c

2019-11-07 12:34:24 +0000
Julian Smith <jules@op59.net>
9caccf9f09e06324f07822cc55e1737d881c6eb3

> Bug 701856: fixed buffer overflow in devices/gdevepsn.c.
> Need to protect aginst overflow with high x_dpi when using local
> graphics_modes_24[] or graphics_modes_9[] arrays.
> Fixes:
> ./sanbin/gs -dBATCH -dNOPAUSE -r914 -sOutputFile=tmp -sDEVICE=eps9high ../bug-701856.pdf
> devices/gdevepsn.c

2019-11-07 11:57:35 +0000
Julian Smith <jules@op59.net>
018003614ad80910ca2c009eb1d523e8015756bc

> Bug 701849: Fix buffer overflow in devices/gdevhl7x.c.
> High values of pdev->x_pixels_per_inch result in Summary::pageWidth being
> greater than Summary::previousData's fixed size of 1500 bytes, which causes
> buffer overflow in resetPreviousData() (and possibly other places too).
> So have changed to initSummary() to allocate Summary::previousData using
> gs_malloc(), and added freeSummary() to clean up.
> Fixes:
> ./sanbin/gs -r968 -dFitPage -dUseCropBox -sPAPERSIZE=legal -sOutputFile=tmp -sDEVICE=hl7x0 ../bug-701849.pdf
> devices/gdevhl7x.c

2019-11-06 15:25:12 +0000
Julian Smith <jules@op59.net>
7da3de0c7662491fa2a0b6f5a638848bcf13a5fa

> Bug 701847: make pj_common_print_page() work with any line_size.
> Much of the code used to be hard-coded for fixed LINE_SIZE.
> Fixes:
> ./sanbin/gs -dBATCH -dNOPAUSE -sOutputFile=tmp -sDEVICE=lj250 ../bug-701847.pdf
> devices/gdevpjet.c

2019-11-06 14:44:13 +0000
Julian Smith <jules@op59.net>
494eeedf73d13fac5710e56f3a8fb2e7e2379d73

> Bug 701846: fix use of uninitialised data in clj_media_size().
> If param_read_float_array() fails, fres.data[] is unset. The values to use are
> always in res[].
> Fixes:
> ./sanbin/gs -dBATCH -dNOPAUSE -dSAFER -dFIXEDMEDIA -sOutputFile=tmp -sDEVICE=cljet5pr ../bug-701846.pdf
> devices/gdevclj.c

2019-11-06 12:41:28 +0000
Julian Smith <jules@op59.net>
4f6bc662909ab79e8fbe9822afb36e8a0eafc2b7

> Bug 701844: fixed output buffer size worst case in lp8000_print_page().
> Fixes:
> ./sanbin/gs -dBATCH -dNOPAUSE -dSAFER -dFIXEDMEDIA -sPAPERSIZE=legal -sOutputFile=tmp -sDEVICE=lp8000 ../bug-701844.pdf
> devices/gdevlp8k.c

2019-11-06 16:46:44 +0000
Ken Sharp <ken.sharp@artifex.com>
ce681338646435ca064ab2d1b8bde1614e5ed3f1

> PDF interpreter - preserve colour space on Image XObjects with Do
> No bug number the customer file is large and looks confidential.
> The problem is that the PDF file sets a custom colour space, then
> draws an image, the image is in a different colour space (DeviceRGB),
> the file then sets a new colour in the original space.
> The PDF interpreter was changing the colour space in order to draw
> the image, but was not resetting it afterwards, which meant that the
> attempt to set the colour failed as the colour space was inappropriate.
> I'm *amazed* this hasn't arisen before, its so clearly wrong.
> This commit gets the colour space before executing the image, and puts
> it back again afterwards. We have to be careful to do the restoration
> in a stopped context because this code can be called when drawing a
> glyph, and we are not permitted to change colour space while in an
> uncoloured glyph, it throws an error.
> In addition, the appearance generation for /Square annotations (and
> other types) was setting the colour space to white and filling the
> annotation rectangle, even if the /IC (Interior Color) key was not
> present. Acrobat appears not to do this so I've modified the code to
> not fill the annotation if there is no /IC in the annotation dictionary.
> Resource/Init/pdf_draw.ps

2019-11-06 11:56:07 +0000
Julian Smith <jules@op59.net>
4e713293de84b689c4ab358f3e110ea54aa81925

> Bug 701843: avoid divide by zero in devices/gdevepsc.c:epsc_print_page().
> Fixes:
> ./sanbin/gs -dBATCH -dNOPAUSE -dSAFER -r8 -dNOCIE -dFitPage -sOutputFile=tmp -sDEVICE=epsonc ../bug-701843.pdf
> devices/gdevepsc.c

2019-11-06 11:46:10 +0000
Julian Smith <jules@op59.net>
f70ab2044429fe4b991801476ea3f4b4a5c0cdf4

> Bug 701843: avoid divide by zero caused by custom resolution being too low.
> Fixes:
> ./sanbin/gs -dBATCH -dNOPAUSE -dSAFER -r8 -dNOCIE -dFitPage -sOutputFile=tmp -sDEVICE=eps9mid ../bug-701843.pdf
> devices/gdevepsn.c

2019-11-06 11:18:55 +0000
Julian Smith <jules@op59.net>
ce2afc4f02617dee51f3322ae8386c4b46047c18

> Bug 701842: avoid buffer overflow in lxm5700m_print_page().
> Fixes:
> ./sanbin/gs -dBATCH -sOutputFile=tmp -sDEVICE=lxm5700m ../bug-701842.ps
> devices/gdevlxm.c

2019-11-05 18:18:50 +0000
Robin Watts <Robin.Watts@artifex.com>
027c546e0dd11e0526f1780a7f3c2c66acffe209

> Bug 701842: Fix misindexing in gxicolor.c
> We were incorrectly decrementing position per-component, rather
> than per-pixel (in 2 places).
> Also, take care of some whitespace oddities.
> base/gxicolor.c

2019-11-05 15:02:23 +0000
Julian Smith <jules@op59.net>
1159afbcad927e1a32008b0ab87e257fc21da8e2

> Ensure strncpy() terminates when called from pjl_parsed_filename_to_string().
> Passing strlen()+1 to strncpy() ensures that it will terminate the
> string. Possibly not required here because the code always terminates the
> string, but this might fix coverity issue 102147.
> pcl/pl/pjparse.c

2019-11-05 14:59:56 +0000
Robin Watts <Robin.Watts@artifex.com>
67b4efc310af7bf9d30f84a70c6b9858ab138e3d

> Bug 701809: Fix out oob access in transform_pixel_region.
> When collating pixels to write out using copy_color,
> we can only write within our array. Clip maxx/minx accordingly.
> base/gdevdflt.c

2019-11-05 14:54:22 +0000
Robin Watts <Robin.Watts@artifex.com>
02c566b4b5f3f60ff8ebd7f4523722c39c2d72e7

> Memento: Unlock a block with valgrind before checking it.
> This avoids false positives on closedown.
> base/memento.c

2019-11-05 13:36:04 +0000
Julian Smith <jules@op59.net>
f38c6b08c6582872af25fc669a5fd3bde9f32753

> Bug 701831: fixed buffer overflow in bjc_compress().
> Fixes:
> ./sanbin/gs -dBATCH -dNOPAUSE -sOutputFile=tmp -sDEVICE=bjc800 ../bug-701831.ps
> devices/gdevcdj.c

2019-11-05 12:03:23 +0000
Julian Smith <jules@op59.net>
b25cad42dc869e8e9d7ea58adae2c8baba0ee25d

> Bug 701830: avoid buffer overflow in lips_rle_encode().
> Worst case for lips_rle_encode() is 2*Length+2, so adjust corresponding alloc
> to match.
> Fixes:
> ./sanbin/gs -dBATCH -dNOPAUSE -r489 -dFitPage -sOutputFile=tmp -sDEVICE=lips4 ../bug-701830.eps
> contrib/lips4/gdevl4r.c

2019-11-05 10:49:58 +0000
Chris Liddell <chris.liddell@artifex.com>
e7118494be4162b8c2c06d8b7d4cb2d7ebb57f61

> Add -dALLOWPSTRANSPARENCY to the documentation.
> doc/Use.htm

2019-11-05 09:45:27 +0000
Chris Liddell <chris.liddell@artifex.com>
485904772c5f0aa1140032746e5a0abfc40f4cef

> Bug 701841: remove .forceput from /.charkeys
> When loading Type 1 or Truetype fonts from disk, we attempt to extend the glyph
> name table to include all identifiable glyph names from the Adobe Glyph List.
> In the case of Type 1 fonts, the font itself (almost always) marks the
> CharStrings dictionary as read-only, hence we have to use .forceput for that
> case.
> But for Truetype fonts, the CharStrings dictionary is created internally and is
> not read-only until *after* we have fully populated it (including the extended
> glyph names from the AGL), hence there is no need for .forceput, and no need to
> carry the security risk of using it.
> Replace with regular put.
> Resource/Init/gs_ttf.ps

2019-11-04 14:23:30 +0000
Chris Liddell <chris.liddell@artifex.com>
94d8955cb7725eb5f3557ddc02310c76124fdd1a

> Bug 701818: better handling of error during PS/PDF image
> In the xps device, if an error occurred after xps_begin_image() but before
> xps_image_end_image(), *if* the Postscript had called 'restore' as part of the
> error handling, the image enumerator would have been freed (by the restore)
> despite the xps device still holding a reference to it.
> Simply changing to an allocator unaffected save/restore doesn't work because
> the enumerator holds references to other objects (graphics state, color space,
> possibly others) whose lifespans are inherently controlled by save/restore.
> So, add a finalize method for the XPS device's image enumerator
> (xps_image_enum_finalize()) which takes over cleaning up the memory it allocates
> and also deals with cleaning up references from the device to the enumerator
> and from the enumerator to the device.
> devices/vector/gdevxps.c

2019-10-31 15:30:19 +0000
Chris Liddell <chris.liddell@artifex.com>
39b4cdb491c3e09434f5d2b9c334a898fb569850

> Update docs for current state of transparency ops
> doc/Language.htm

2019-10-31 10:19:01 +0000
Chris Liddell <chris.liddell@artifex.com>
d1eac80695b2c6f2a85942a82518715549541969

> Add the ability to allow transparency ops in Postscript
> -dALLOWPSTRANSPARENCY on the command line will prevent the undefining of the
> non-standard gs Postscript transparency operators.
> Driving these operators in the wrong way can cause undefined behavior, hence
> not allowing them normally.
> Also, use a better condition for dropping the transparency ops in:
> examples/transparency_example.ps
> Resource/Init/gs_init.ps
> Resource/Init/pdf_main.ps
> examples/transparency_example.ps

2019-11-05 08:50:45 +0000
Ken Sharp <ken.sharp@artifex.com>
27409d99b069e434c6863f43456cf8985bbdf7f8

> Fix the quad glyph table
> This might fix Coverity ID 350194. Even if it doesn't it is incorrect
> so fix the initialisation of the table.
> devices/vector/gdevagl.c

2019-11-05 08:48:10 +0000
Ken Sharp <ken.sharp@artifex.com>
407c98a38c3a6ac1681144ed45cc2f4fc374c91f

> txtwrite - guard against using GS_NO_GLYPH to retrieve Unicode values
> Bug 701822 "Segmentation fault at psi/iname.c:296 in names_index_ref"
> Avoid using a glyph with the value GS_NO_GLYPH to retrieve a glyph
> name or Unicode code point from the glyph ID, as this is not a valid
> ID.
> devices/vector/gdevtxtw.c
> psi/zbfont.c

2019-11-04 16:12:04 +0000
Julian Smith <jules@op59.net>
af004276fd8f6c305727183c159b83021020f7d6

> Bug 701829: ep_print_image(): protect against memcmp() beyond buffer.
> Fixes:
> ./sanbin/gs -dBATCH -dNOPAUSE -r12 -sOutputFile=tmp -sDEVICE=escp ../bug-701829.pdf
> devices/gdevcdj.c

2019-11-01 11:55:23 -0700
Ray Johnston <ray.johnston@artifex.com>
4f73e8b4d578e69a17f452fa60d2130c5faaefd6

> Fix bugs 701787, 701806, 701810. Problems with cdj970 device.
> As Robin mentioned in bug 701787, the device was changing resolution AFTER
> the device had been opened and all of the buffers configured.
> Move the "one time" initial setup into the open function, leaving the code
> to write the header in the print_page function. Presumably that only needs
> to be written once even if there are multiple pages.
> Also add a check for valid resolutions since it appears that the intent was
> to have the "Quality" parameter set up 300 or 600 dpi. Other deskjet devices
> have this type of check.
> Add a gs_closedevice if the Quality is changed since this will change the
> resolution and thus the page buffer geometry.
> Lastly, fix cdj970_put_params so that errors are not ignored for all but the
> last (which happened to be BlackCorrect).
> These changes prevent the bugs cited, but remain untested except for some
> parameter testing to make sure bad values don't cause memory violations. It
> does seem that some parameter values that are out of range (like Quality) are
> ignored, but that may be intentional.
> contrib/gdevdj9.c

2019-11-04 15:32:04 +0000
Julian Smith <jules@op59.net>
eaba1d97b62831b42c51840cc8ee2bc4576c942e

> Bug 701828: make dot24_print_page() return error instead of divide by zero.
> Fixes:
> ./sanbin/gs -dBATCH -dNOPAUSE -dSAFER -r2 -sOutputFile=tmp -sDEVICE=necp6 ../bug-701828.pdf
> devices/gdevdm24.c

2019-11-04 13:00:04 +0000
Julian Smith <jules@op59.net>
a6f7464dddc689386668a38b92dfd03cc1b38a10

> Bug 701827: fixed incorrect buffer expansion in lxm5700m_print_page().
> Fixes:
> ./sanbin/gs -dBATCH -dNOPAUSE -r425 -dFitPage -sOutputFile=tmp -sDEVICE=lxm5700m ../bug-701827.eps
> devices/gdevlxm.c

2019-11-04 12:30:33 +0000
Julian Smith <jules@op59.net>
2793769ff107d8d22dadd30c6e68cd781b569550

> Bug 701819: fixed ordering in if expression to avoid out-of-bounds access.
> Fixes:
> ./sanbin/gs -dBATCH -dNOPAUSE -r965 -sOutputFile=tmp -sDEVICE=pcx16 ../bug-701819.pdf
> devices/gdevpcx.c

2019-11-01 18:09:30 +0000
Julian Smith <jules@op59.net>
366ad48d076c1aa4c8f83c65011258a04e348207

> Bug 701815: avoid uninitialised bytes being >7, which broke indexing.
> Fixes:
> ./sanbin/gs -dBATCH -dNOPAUSE -sOutputFile=tmp -sDEVICE=jetp3852 ../bug-701815.pdf
> devices/gdev3852.c

2019-11-01 14:55:16 +0000
Robin Watts <Robin.Watts@artifex.com>
ec065fd285f8064ac34cc160106dd730569ebc75

> Clear eol padding bits in "atx" devices.
> This upsets the blank line detection and therefore can randomly
> change the output.
> devices/gdevatx.c

2019-11-01 14:26:52 +0000
Robin Watts <Robin.Watts@artifex.com>
e4dce29961108c6fef5c02bf4d5e527b265bf8d8

> Mask eol padding bits for pngmono device in CLUSTER builds.
> devices/gdevpng.c

2019-11-01 14:24:08 +0000
Robin Watts <Robin.Watts@artifex.com>
9076e48cf91ba6bf4e939b0562c53e6cbb62282e

> Fix previous planm eol masking fix.
> The previous attempt to fix the masking of eol padding bits
> for planm would have failed in the width == multiple of 8 case.
> Also make it dependent on CLUSTER here.
> devices/gdevplan.c

2019-11-01 12:38:41 +0000
Robin Watts <Robin.Watts@artifex.com>
1126deff06d81d4fa1975ea0ed3a3b64e9cf0661

> Update "planm" device to clear eol padding bits.
> This should avoid md5 changes in the alldevs cluster test.
> devices/gdevplan.c

2019-11-01 12:22:55 +0000
Robin Watts <Robin.Watts@artifex.com>
bcb881e566d90ae43648085ff1edfdcddcd6eb50

> Fix "cif" device in CLUSTER builds.
> Use a hardcoded "clusterout" filename for embedding rather
> than the real one in CLUSTER builds. This stops the md5sum
> from changing randomly.
> devices/gdevcif.c

2019-11-01 10:26:44 +0000
Ken Sharp <ken.sharp@artifex.com>
aadb53eb834b3def3ef68d78865ff87a68901804

> Tiffsep and Tiffsep1 - abort on multi-page input wtithout %d OutputFile
> Bug #701821 "Segmentation fault at tiff//libtiff/tif_dirinfo.c:513 in TIFFFindField"
> The tiffsep and tiffsep1 only set 'code' to an error when an attempt is
> made to write a second output file without using %d in the OutputFile
> specification.
> This causes problems later when attempting to process the files. The
> devices should exit without trying to further process the pages under
> these conditions and this commit returns immediately on error.
> The other devices like this already return immediately on error, it
> looks like the code here was copied between devices without realising
> that the tiffsep and tiffsep1 devices didn't exit when the error
> condition was set.
> devices/gdevtsep.c

2019-10-31 19:47:13 +0000
Robin Watts <Robin.Watts@artifex.com>
9c196bb7f6873b4fe43a649fc87cba363c6af8e5

> Fix devicen device for new file security world.
> Again, update the code to allow spot files to be written.
> base/gdevdevn.c

2019-10-31 19:24:44 +0000
Robin Watts <Robin.Watts@artifex.com>
a6e36c29b69b4d15aac872e37303dcf9cb8d7739

> Update spotcmyk device for new file access security.
> This device writes the data to a file, then reads it back in,
> and writes out various spot ".pcx" files. Accordingly we
> need to make the file readable too, and then make the .pcx
> files writable.
> base/gdevdevn.c

2019-10-31 18:21:01 +0000
Robin Watts <Robin.Watts@artifex.com>
dbdb5f8527007b482d4e6037b558dbf3e6a06d3a

> Fix spurious rangechecks from cljet5pr device.
> The device would rangecheck whenever it was called with a
> param list that didn't contain HWResolution. Now, if it's
> not given an HWResolution, look at the device's current
> value.
> devices/gdevclj.c

2019-10-31 17:42:48 +0000
Robin Watts <Robin.Watts@artifex.com>
f5673b5a50f141440329c62ee5b53eefcd585a3f

> pdfimg: Avoid ID's varying by filename in CLUSTER builds.
> This was upsetting the alldevs runs.
> devices/gdevpdfimg.c

2019-10-31 17:01:42 +0000
Julian Smith <jules@op59.net>
b5bc53eb7223f8999882a5d8e2e35c27fe7a0b57

> Bug 701788: added comment about asn/valgrind detecting leaks in fontconfig.
> base/gp_unix.c

2019-10-31 16:22:01 +0000
Robin Watts <Robin.Watts@artifex.com>
255eef0a7d9d24962ebbcbb4b1858e44b803f16b

> mgr4 device: clear any unused trailing bits for each line.
> This avoids valgrind errors and varying md5sums in the alldevs
> cluster test.
> devices/gdevmgr.c

2019-10-31 16:21:06 +0000
Robin Watts <Robin.Watts@artifex.com>
351a2251b4a80fa31ac15229036318b01d124532

> Squash warning caused by previous fix.
> Include the correct header for 'free' before using it.
> contrib/eplaser/gdevescv.c

2019-10-31 13:12:47 +0000
Julian Smith <jules@op59.net>
f54414c8b15b2c27d1dcadd92cfe84f6d15f18dc

> Bug 701808: return error from okiibm_print_page1() if x_dpi too high.
> Avoids asan error in:
> ./sanbin/gs -dBATCH -dNOPAUSE -dSAFER -r599 -sOutputFile=tmp -sDEVICE=okiibm ../bug-701808.pdf
> devices/gdevokii.c

2019-10-31 15:36:22 +0000
Robin Watts <Robin.Watts@artifex.com>
464107095e614d54417ffd2bedbdc852efee0961

> Update lbp8 device to not use a fixed sized buffer for line data.
> devices/gdevlbp8.c

2019-10-31 14:25:25 +0000
Robin Watts <Robin.Watts@artifex.com>
5eaccd845c9957dff754ebfdde417fe5d82e5e82

> Update vdb.pl script to latest version.
> toolbin/vdb.pl

2019-10-31 14:17:38 +0000
Robin Watts <Robin.Watts@artifex.com>
0d998f17c495a12b04904113ff676c7427089883

> Fix gdevescv for operation with Memento.
> Blocks returned by system malloc can't be freed by Memento_free.
> Also, avoid a problem in CLUSTER builds.
> contrib/eplaser/gdevescv.c

2019-10-31 11:55:38 +0000
Julian Smith <jules@op59.net>
714e8995cd582d418276915cbbec3c70711fb19e

> Bug 701807: avoid buffer overflow in tiff12_print_page().
> Fixes:
> ./sanbin/gs -r650 -sOutputFile=tmp -sDEVICE=tiff12nc ../bug-701807.pdf
> devices/gdevtfnx.c

2019-10-31 10:33:10 +0000
Robin Watts <Robin.Watts@artifex.com>
c64d06deea998199a0e30180fd884286b4b2256c

> Nobble various uses of "time" in the code in CLUSTER builds.
> This causes the bjccolor device at least to give indeterminate
> results. Nobbling the rest won't hurt.
> contrib/eplaser/gdevescv.c
> contrib/gdevbjca.c
> devices/gdevpdfimg.c
> devices/gdevtifs.c
> devices/vector/gdevpdfe.c
> devices/vector/gdevpsu.c

2019-10-31 10:31:24 +0000
Robin Watts <Robin.Watts@artifex.com>
bf72f1a3dd5392ee8291e3b1518a0c2c5dc6ba39

> Fix valgrind problems with gdevbjca.c
> 2 problems here. Firstly, we could access off the end of a row
> while looking for runs. Change the indexing to fix this.
> Secondly, we could overrun our gamma tables due to unexpectedly
> large values. Add some clamping.
> contrib/gdevbjca.c

2019-10-31 10:29:32 +0000
Robin Watts <Robin.Watts@artifex.com>
fa7f0cde80ce734ddc22bde34d121c1be5c7deb4

> Fix various incorrect casts in contrib devices.
> Various contrib devices cast a gx_color_index (a 32 or 64
> bit value typically containing 24 bits of data) down to
> a gx_color_value before manipulating it. This is a typo,
> copied into several places in the code. Correct it here.
> contrib/gdevcd8.c
> contrib/gdevdj9.c
> contrib/japanese/gdevmjc.c

2019-10-31 10:17:09 +0000
Robin Watts <Robin.Watts@artifex.com>
f1fd4a73480c5a2f900b1541b45a62ffcc75e12d

> Fix warnings when building contrib on windows.
> MSVC is much more sensitive to casting types than gcc is, it
> seems. Accordingly avoid making doubles when we want floats, and
> make all casts down to int (or byte) explicit.
> base/gxdevice.h
> contrib/gdevbjc_.c
> contrib/gdevbjc_.h
> contrib/gdevcd8.c
> contrib/gdevdj9.c
> contrib/gdevgdi.c
> contrib/gdevln03.c
> contrib/gdevlx32.c
> contrib/gdevmd2k.c
> contrib/gdevop4w.c
> contrib/japanese/gdev10v.c
> contrib/japanese/gdevalps.c
> contrib/japanese/gdevespg.c
> contrib/japanese/gdevmjc.c
> contrib/japanese/gdevnpdl.c
> contrib/japanese/gdevrpdl.c
> contrib/lips4/gdevl4r.c
> contrib/lips4/gdevlips.h
> contrib/pcl3/eprn/mediasize.c
> contrib/pcl3/eprn/mediasize.h
> contrib/pcl3/src/gdevpcl3.c
> contrib/pcl3/src/pclcap.c
> contrib/pcl3/src/pclgen.c
> devices/gdevphex.c

2019-10-30 17:40:18 +0000
Robin Watts <Robin.Watts@artifex.com>
67a101f3eb888bc651cc13bfb06280a669a84967

> Fix contrib.mak to work on windows.
> Building Debug-contrib|win32 will currently attempt to run
> contrib.mak 3 times due to poor commenting out of make lines.
> For me, this manifested itself as new instances of Visual
> Studio starting up and attempting to "upgrade" the makefile.
> contrib/contrib.mak

2019-10-29 17:16:03 +0000
Robin Watts <Robin.Watts@artifex.com>
4fcbece468706e0e89ed2856729b2ccacbc112be

> Avoid some devices dying due to inappropriate resolutions.
> contrib/japanese/gdev10v.c
> contrib/japanese/gdevalps.c

2019-10-29 16:01:39 +0000
Robin Watts <Robin.Watts@artifex.com>
19cebe708b9ee3d9e0f8bcdd79dbc6ef9ddc70d2

> Avoid division by zero with bj10v device.
> When called with a low resolution, we can end up dividing by zero.
> Spot this in the open call and give a rangecheck error.
> contrib/japanese/gdev10v.c

2019-10-29 17:28:53 +0000
Julian Smith <jules@op59.net>
849e74e5ab450dd581942192da7101e0664fa5af

> Bug 701799: avoid out-of-range array access in mj_color_correct().
> Code is obscure, so this fix merely avoids out-of-range access in the simplest
> way possible, without understanding what the code is trying to do.
> Fixes:
> ./sanbin/gs -sOutputFile=tmp -sDEVICE=mj6000c ../bug-701799.pdf
> contrib/japanese/gdevmjc.c

2019-10-29 16:49:13 +0000
Julian Smith <jules@op59.net>
89f58f1aa95b3482cadf6977da49457194ee5358

> Bug 701794: check for x_dpi out of range in epsc_print_page().
> Avoids out-of-bounds of local arrays graphics_modes_9 and graphics_modes_24.
> Larger diff than would like, because can't return error from within
> declarations in old-style C.
> Fixes:
> ./sanbin/gs -r680 -sOutputFile=tmp -sDEVICE=epsonc ../bug-701794.pdf
> devices/gdevepsc.c

2019-10-29 16:20:56 +0000
Julian Smith <jules@op59.net>
863ada11f9a942a622a581312e2be022d9e2a6f7

> Bug 701793: check we are within buffer before comparing buffer contents.
> Fixes:
> ./sanbin/gs -sOutputFile=tmp -sDEVICE=mj700v2c ../bug-701793.pdf
> contrib/japanese/gdevmjc.c

2019-10-29 15:49:25 +0000
Julian Smith <jules@op59.net>
9f39ed4a92578a020ae10459643e1fe72573d134

> Bug 701792: Avoid going beyond buffer in GetNumSameData() and GetNumWrongData().
> GetNumSameData() compared buffer contents before checking that we are still
> within bounds of buffer, which caused the bug.
> Have made similar fix to GetNumWrongData() because it has similar error.
> Fixes address sanitizer error in:
> ./sanbin/gs -sOutputFile=tmp -sDEVICE=lips4v ../bug-701792.pdf
> contrib/lips4/gdevlips.c

2019-10-29 14:13:25 +0000
Julian Smith <jules@op59.net>
d31e25ed5b130499e0d880e4609b1b4824699768

> Bug 701788: include space for string terminator in call to malloc in cif_print_page().
> Fixes ./sanbin/gs -sOutputFile=tmp -sDEVICE=cif ../bug-701788.pdf
> devices/gdevcif.c

2019-10-28 17:29:34 -0600
Henry Stiles <henry.stiles@artifex.com>
6e6c69487094b877bc56fcc07b9840f6e5b95925

> Bug #701803, fix missing Greek symbols.
> New symbol set ISO/IEC 8859-7 Latin/Greek alphabet added.
> pcl/pl/plsymbol.c

2019-10-28 10:37:46 -0700
Michael Vrhel <michael.vrhel@artifex.com>
7870f4951bcc6a153f317e3439e14d0e929fd231

> Bug 701795: Segv due to image mask issue
> base/gxblend.c

2019-10-28 14:56:56 +0000
Julian Smith <jules@op59.net>
1e6b2518ed4b130ad649b96bf914558e642e414d

> clusterpush.pl: also exclude sanbin and sanobj directories.
> toolbin/localcluster/clusterpush.pl

2019-10-28 14:41:35 +0000
Julian Smith <jules@op59.net>
a2df79b5fdf97e1e33503634910ad08672bcee39

> Added support for MEMENTO_BREAKAT, equivalent to (gdb) call Memento_breakAt(...).
> It can be more convenient to specify this on the command line rather than
> manually stop in gdb.
> base/memento.c

2019-10-28 14:37:48 +0000
Julian Smith <jules@op59.net>
450da26a76286a8342ec0864b3d113856709f8f6

> Bug 701785: fixed sanitizer heap-buffer-overflow in lprn_is_black().
> In contrib/lips4/gdevlprn.c:lprn_is_black(), it seems that bpl is not
> necessarily a multiple of lprn->nBw, so we need to explicitly avoid straying
> into the next line's data.
> This also avoids accessing beyond our buffer if we are already on the last
> line, and so fixes the sanitizer error.
> Fixes:
> ./sanbin/gs -sOutputFile=tmp -sDEVICE=lips2p ../bug-701785.pdf
> contrib/lips4/gdevlprn.c

2019-10-27 19:44:35 -0700
Ray Johnston <ray.johnston@artifex.com>
93cb0c0adbd9bcfefd021d59c472388f67d3300d

> Fix Bug 701786: jetp3852 stack corruption caused by width/resolution
> This "contrib" driver has a questionable design where it collects the raster
> data from the graphics library into a stack based array, but the size of the
> array cannot accomodate high resolutions or wide pages. Issue an error and
> fail (without stack corruption).
> devices/gdev3852.c

2019-10-26 17:14:23 +0100
Ken Sharp <ken.sharp@artifex.com>
2c2dc335c212750e0fb8ae157063bc06cafa8d3e

> Color Laserjet device - properly check params
> Bug #701796 "Segmentation fault at devices/gdevclj.c:269 in clj_media_size"
> The test in clj_media_size() as incorrect, it didn't signal an error if
> there was no HWResolution in the param list. This left the parameter
> 'fres' undefined leading to a potential invalid memory read, or a
> divide-by-zero error.
> This commit returns an error if we get a param list with no HWResolution
> I'm not absolutely certain if this is correct, but at least signalling
> an error is better than a seg fault.
> devices/gdevclj.c

2019-10-26 15:43:38 +0100
Ken Sharp <ken.sharp@artifex.com>
bfeff28bb56ee4424ac78619792c18bf4f5104ef

> Coverity ID #126579 take 2
> Commit 13b3c67366aef69beed5f9c7e058c59a03714997 addressed this, but
> there were 2 instances and that only fixed one. Fix the other here.
> devices/vector/gdevpdfg.c

2019-10-26 15:04:26 +0100
Ken Sharp <ken.sharp@artifex.com>
aba3375ac24f8e02659d9b1eb9093909618cdb9f

> Prevent a heap-buffer overrun
> Bug #701791 "global-buffer-overflow at devices/gdevpjet.c:177 in pj_common_print_page"
> We were not setting the unused bytes at the end of a line to 0, which
> later caused us to read uninitialised data from the line, and attempt
> to use that as the index into an 8-byte table. If the uninitialised
> data was greater than 16 then we would read off the end of the table.
> Its 'probably' benign since we aren't using tis data, and we probably
> won't try to read from an invalid address, but its poor practice and
> its easily fixed. Setting the buffer to 0x00 before we start ensures
> that any padding bytes are in the valid range for the table.
> devices/gdevpjet.c

2019-10-25 18:48:05 +0100
Robin Watts <Robin.Watts@artifex.com>
4b9e86a33b237740df682369300f1a9507dc63c5

> Memento: Fix annoyance with %p
> Windows displays %p without a leading 0x. Linux adds a leading 0x.
> Use a macro to give consistent results on all platforms.
> base/memento.c

2019-10-25 13:52:44 +0100
Chris Liddell <chris.liddell@artifex.com>
17ad4a12dd40799655b71a93de1209a6a0f24204

> Coverity issues: Assignment of overlapping union members
> Strictly speaking assigning one element of union to another, overlapping
> element of a different size is undefined behavior, hence assign to intermediate
> variables before setting the other element in the union.
> Coverity #: 350159, 350173, 350205, 350176, 350215, 350192
> base/gsfunc4.c
> base/gsparam.c
> pcl/pcl/pgparse.c
> psi/zfont2.c
> psi/ztype.c

2019-10-25 13:30:56 +0100
Chris Liddell <chris.liddell@artifex.com>
62a1c3cdbb374d2f90b00f7aa276be50961c580a

> Tweak the section on building with Visual Studio
> doc/Make.htm

2019-10-24 10:15:19 +0100
Chris Liddell <chris.liddell@artifex.com>
e80779ae9f53fac617d1416f7075a1b1b7f7688c

> Reduce confusion about contrib.mak dependency
> We have two contri.mak files, one in devices/ and one in contrib/, both have
> dependency declarations:
> CONTRIB_MAK=...
> This changes the devices/contrib.mak to use:
> DCONTRIB_MAK=...
> Prepending the 'D' to avoid the two getting muddled.
> devices/contrib.mak

2019-10-25 13:53:31 +0100
Robin Watts <Robin.Watts@artifex.com>
9ae928f80e70e04e89f0c36a7b58332fb0a9b19d

> Fix CAL ETS compiler flags.
> base/cal.mak

2019-10-24 15:04:58 +0100
Julian Smith <jules@op59.net>
9001678252cc6c4e45251db70b83daae39b7d4ec

> Bug 697545 (Memory Squeezing): fixed hpgl_polyfill_using_current_line_type() leak on error.
> Need to always call hpgl_grestore().
> Fixes this leak:
> MEMENTO_FAILAT=15840 ./membin/gpcl6 -sDEVICE=pbmraw -o /dev/null ../pcl5cfts/fts.1552
> pcl/pcl/pgdraw.c

2019-10-24 08:31:38 -0700
Robin Watts <Robin.Watts@artifex.com>
d6746f08c592057dfd3abe1b957c8b23971508cc

> Memento tweaks: libbacktrace warning/instructions.
> If we can't load libbacktrace.so, give a warning that backtraces
> will be cryptic.
> Add info to memento.h about where people can get libbacktrace
> from, how to build it, and where to install it.
> Also add some code from Julian Smith to call gdb to extract
> backtrace data; this doesn't work for me, so it's disabled
> by default for now.
> base/memento.c
> base/memento.h

2019-10-23 13:29:38 -0700
Nancy Durgin <nancy.durgin@artifex.com>
de22d4d177a5911310d4af0777e87a8809a1622c

> Change pdf implementation to use CalGray and CalRGB
> It was previously mapping these to DeviceGray and DeviceRGB for some
> reason.
> See tests_private/pdf/PDF_1.7_FTS/fts_08_0829.pdf for example where this
> matters.
> Resource/Init/pdf_ops.ps

2019-10-21 17:37:59 +0100
Robin Watts <Robin.Watts@artifex.com>
a1cd6ee4a3724fbf70718483aa702c7af0f0a6cc

> Use CAL implementation of ETS in WITH_CAL builds.
> base/cal.mak
> base/ets.h
> base/gxdownscale.c
> base/lib.mak

2019-09-27 11:16:23 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
a44d0ce727f2095fbbedb8bf6b1e062fca3c8f01

> Bug 697545 : Prevent memory leaks in gx_cpath_assign_preserve.
> Update functionality to propagate error codes correctly and release path segments.
> Error created using :-
> MEMENTO_FAILAT=15840 ./membin/gpcl6 -sDEVICE=pbmraw -o /dev/null ./tests_private/pcl/pcl5cfts/fts.1552
> base/gxacpath.c
> base/gxcpath.c

2019-09-26 15:08:02 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
4637eeae2415b593d84bb60dbac5369eb2ecc54b

> Bug 697545 : Prevent memory leaks in hpgl_LB.
> Update code to propagate error codes correctly and prevent font leaks.
> Error created using :-
> MEMENTO_FAILAT=19935 ./membin/gpcl6 -sDEVICE=pbmraw -o /dev/null ./tests_private/pcl/pcl5cfts/fts.1480
> pcl/pcl/pglabel.c

2019-09-26 11:49:08 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
dc3b7d7f6882e1ed1ff41083ff22893efc5c5afa

> Bug 697545 : Prevent memory leaks in hpgl_EP.
> Update code to propagate error codes correctly and prevent graphic state leaks.
> Error created using :-
> MEMENTO_FAILAT=15166 ./membin/gpcl6 -sDEVICE=pbmraw -o /dev/null ./tests_private/pcl/pcl5cfts/fts.1470
> base/gxstroke.c
> pcl/pcl/pgpoly.c

2019-10-23 14:08:02 +0100
Julian Smith <jules@op59.net>
3ff1490e231c8b02ce77386a75f23ac76e97cc29

> Bug 697545 (Memory Squeezing): fixed owl.pcl leak in hpgl_draw_current_path().
> In pcl/pcl/pgdraw.c:hpgl_draw_current_path() case hpgl_char_fill_edge, ensure
> that we call hpgl_grestore() before looking at error from (*fill) (pgs).
> Fixes leak at 10093 in:
> MEMENTO_SQUEEZEAT=1 membin/gpcl6 -sDEVICE=bit -o /dev/null pcl/examples/owl.pcl
> pcl/pcl/pgdraw.c

2019-10-23 15:08:29 +0100
Julian Smith <jules@op59.net>
5ce07cab3d1e9e38401cfaddd0312bd06f48422b

> Fix hpgl_call_and_check() macro to not define <code> local variable.
> This can conflict with surrounding code. Use <hpgl_call_and_check_code>
> instead, which should be unique enough.
> pcl/pcl/pgmisc.h

2019-10-23 10:02:02 +0100
Chris Liddell <chris.liddell@artifex.com>
1bb7a148bc6a4e4a8736d27a937465aab95069e5

> Revision for a34130a136fa that will actually work
> The Coverity report was misleading, and I missed a compiler warning with
> commit a34130a136fa.
> This resolves the compiler warning, and should keep coverity happy.
> base/gstype42.c

2019-10-23 09:39:11 +0100
Chris Liddell <chris.liddell@artifex.com>
6d7243cea061373f592a6d9113626393ff0eb7d8

> Coverity ID 350179: Add buffer size check for string
> Before we append chars to a string buffer, check it's large enough
> base/genconf.c

2019-10-23 09:22:14 +0100
Chris Liddell <chris.liddell@artifex.com>
a34130a136fa9a61af3991224438dbf31b834767

> Coverity ID 350219: Fix mistake in TTF post table handling
> Mistakenly passing a pointer into a macro, rather than the variable.
> base/gstype42.c

2019-10-11 10:20:04 +0100
Robin Watts <Robin.Watts@artifex.com>
5573498b2d9abe918794d377729edeab6b28e1fb

> Add arch.h dependency for CAL.
> base/cal.mak

2019-10-21 15:12:57 -0700
Ray Johnston <ray.johnston@artifex.com>
a7fe4b47d438c78af0fc03adf030d465cfe0ba4f

> Apply DOPS to "bare" PS operator in PDF's
> PDF 1.2 defined a PS operator that could be used in streams to execute
> PostScript. This went away with PDF 1.3 2nd edition spec., but Ghostscript
> retained the functionality. In commit e7086fc6 we disabled the execution
> of Subtype /PS streams (requiring -dDOPS to enable them), but the "PS"
> operator, that sends PostScript strings to the underlying Postscript
> interpreter remained unaffected, leading to Bug 700176 exploit.
> This patch also disables the "PS" operator unless -dDOPS is specified.
> Using -dDOPS is *NOT* recommended, although the fixes for Bug700176
> should prevent that particular exploit.
> Resource/Init/pdf_main.ps
> doc/Use.htm

2019-10-22 10:57:59 +0100
Ken Sharp <ken.sharp@artifex.com>
b4521b891de48d7f62be739d02749c4aeca2fde8

> Fix dvipdf script
> Bug #701771 "dvipdf script broken"
> Apparently the script requires a trailing '-'
> lib/dvipdf

2019-10-22 09:32:05 +0100
Ken Sharp <ken.sharp@artifex.com>
7c836caa3e05a286ac56f39ed45dab65eb979ee9

> Update genfontmap.ps for SAFER default
> Bug #701766 " genfontmap.ps Unrecoverable error, exit code 1"
> The genfontmap.ps program, supplied as part of the support tools in
> 'toolbin' rather than Ghostscript proper, relies on the non-standard
> PostScript extension operator '.sort'.
> As part of the security hardening, as many non-standard operators as
> possible were removed from Ghostscript when SAFER is set, including
> .sort, and with version 9.50 SAFER becomes the default.
> This commit simply updates the genfontmap.ps program to check that it
> is being run with NOSAFER, emits a warning and exits if this is not the
> case. Also update the comments to indicate why we are doing this.
> toolbin/genfontmap.ps

2019-10-17 11:51:59 +0100
Chris Liddell <chris.liddell@artifex.com>
95e76aad97b1b1c2da51f7fc7e904168fadb1399

> Remove the 136 LL3 font set fontmap files
> The fontmap for the type 1 136 set is now in the repo with the font files
> lib/Fontmap.URW-136.T1
> lib/Fontmap.URW-136.TT

2019-10-17 11:39:18 +0100
Chris Liddell <chris.liddell@artifex.com>
164db4ba0d766e591884079d6fb21ab63829549d

> Fontmap: cope better with bare filename maps
> We don't automatically add FontResourceDir to the libfile search path, so a
> name to plain file name mapping will only work if the directory containing the
> file is explicitly added to the search path. For example:
> /Dingbats (d050000l.pfb) ;
> With this change, in addition to the search path and the bare file name, we'll
> also try opening the file in the FontResourceDir, so users can use such custom
> mappings simply by adding the font files to the FontResourceDir (usually:
> Resource/Font).
> Resource/Init/gs_fonts.ps

2019-10-19 11:06:46 +0100
Ken Sharp <ken.sharp@artifex.com>
618c3867b8edec9d0ea757949c926d4290995ac7

> Pattern handling- relax a heuristic
> Bug #701753 "Error reading a content stream" with pdf using Type3 font"
> This file uses a type 3 font with a FontMatrix more usually found in
> type 1 font; [0.001 0 0 0.001 0 0]. It is also a coloured font, and
> uses a Pattern colour space with a Shading function to colour the text.
> The Pattern cell, when scaled by the Font Matrix, results in a mapping
> of the step matrix to device space where the matrix determinant is less
> than 1/1,000,000. We detect this as a degenerate matrix and throw an
> error.
> Acrobat renders an empty page.
> So relax this heuristic further from 10^-6 to 10^-9, this allows the
> file to render and doesn't cause any changes in our regression tests.
> Of course, at this cell size, the pattern renders blank, just as it
> does with Acrobat.
> base/gsptype1.c

2019-10-16 08:18:59 -0700
Ray Johnston <ray.johnston@artifex.com>
7acf36de36e6972be8a892078d214eea8e311cdd

> Fix bug 699457: Parameter range checking wrong (would not spot bad values).
> devices/gdevtsep.c

2019-10-16 08:04:34 -0700
Ray Johnston <ray.johnston@artifex.com>
1170f928cc98b64a26edc275b66f081be9079cbb

> Fix bug 701719: Parens seem wrong -- fixed for clarity.
> base/gxclthrd.c

2019-10-16 16:12:50 +0100
Chris Liddell <chris.liddell@artifex.com>
928ae0dbcf9a2307bb33ba8d2abd83274fc34a7d

> Change a URL string to a an href link in the footers.
> doc/API.htm
> doc/C-style.htm
> doc/DLL.htm
> doc/Deprecated.htm
> doc/Develop.htm
> doc/Devices.htm
> doc/Drivers.htm
> doc/Fonts.htm
> doc/History9.htm
> doc/Install.htm
> doc/Internal.htm
> doc/Language.htm
> doc/Lib.htm
> doc/Make.htm
> doc/News.htm
> doc/Ps-style.htm
> doc/Ps2epsi.htm
> doc/Psfiles.htm
> doc/Readme.htm
> doc/Release.htm
> doc/Source.htm
> doc/Unix-lpr.htm
> doc/Use.htm
> doc/VectorDevices.htm
> doc/WhatIsGS.htm
> doc/sample_downscale_device.htm
> doc/thirdparty.htm

2019-10-16 06:52:51 -0700
Ray Johnston <ray.johnston@artifex.com>
65dbe88e660adcfba315fe559fcd7fd97628ee49

> Fix bug 701718: Use separate 'if' in clist_fillpage.
> The intent was to return the error code if clist_close_writer_and_init_reader
> failed, THEN run clist_finish_page and similarly return if that fails.
> base/gxclrect.c

2019-10-16 06:43:04 -0700
Ray Johnston <ray.johnston@artifex.com>
e22ef03cdd31263ba1266f3d53aef7be4467e405

> Fix bug 701715. Problem in thresh_remap.c binary output.
> I never use binary output -- just -p for PostScript output, so this
> was untested.
> toolbin/halftone/thresh_remap/thresh_remap.c

2019-08-15 11:39:51 +0100
Chris Liddell <chris.liddell@artifex.com>
8a3309451ded2335b7f7ab5ebf1c19eebad8b32c

> Bring master up to date with 9.50 branch
> docs, dates etc
> Dates and versions for 9.28 RC 1
> Date for 9.28 rc2
> Doc updates, changelog, news etc
> Update to note explicitly case sensitivity on Windsows
> In News.htm and History9.htm
> Dates, docs, etc for 9.28 rc3
> Dates and docs for 9.28 rc4
> Small changelog tweak
> Change version to 9.50
> Update changelog
> Fix a mistake in the news section
> Dates etc for 9.50 release
> Plus a comment on going to 9.50, rather than 9.28.
> base/version.mak
> doc/DLL.htm
> doc/Deprecated.htm
> doc/Develop.htm
> doc/Devices.htm
> doc/Drivers.htm
> doc/Fonts.htm
> doc/History9.htm
> doc/Install.htm
> doc/Internal.htm
> doc/Language.htm
> doc/Lib.htm
> doc/Make.htm
> doc/News.htm
> doc/Ps-style.htm
> doc/Ps2epsi.htm
> doc/Psfiles.htm
> doc/Readme.htm
> doc/Release.htm
> doc/SavedPages.htm
> doc/Source.htm
> doc/Unix-lpr.htm
> doc/Use.htm
> doc/VectorDevices.htm
> doc/WhatIsGS.htm
> doc/gs-vms.hlp
> doc/sample_downscale_device.htm
> doc/subclass.htm
> doc/thirdparty.htm
> man/dvipdf.1
> man/gs.1
> man/gslp.1
> man/gsnd.1
> man/pdf2dsc.1
> man/pdf2ps.1
> man/pf2afm.1
> man/pfbtopfa.1
> man/printafm.1
> man/ps2ascii.1
> man/ps2epsi.1
> man/ps2pdf.1
> man/ps2pdfwr.1
> man/ps2ps.1

2019-10-15 09:27:39 +0100
Chris Liddell <chris.liddell@artifex.com>
ac5c8747c9f9e2710a315ff25d41a7b9a592b583

> Version number, to dovetail with release
> Resource/Init/gs_init.ps
> base/version.mak

2019-10-14 18:29:10 +0100
Chris Liddell <chris.liddell@artifex.com>
e7488d8a4d2bb48d6285d4ba3db1539206f0e67f

> Have warning honor -dQUIET
> Have the warning about calling .lockfileaccess or .setsafe when the controls are
> already in place honor the -dQUIET/-q command line params.
> Resource/Init/gs_init.ps

2019-10-14 18:07:29 +0100
Chris Liddell <chris.liddell@artifex.com>
75275c5c001699b32dfdc1d7d7977c8c4c9f2c80

> Add words about .currentpathcontrolstate operator
> doc/Language.htm

2019-10-14 10:20:19 +0100
Chris Liddell <chris.liddell@artifex.com>
74e468866b53e1a11d641549841b06027266ce39

> Update docs on SAFER
> to reflect that SAFER is now the default, and remove the comments about making
> SAFER the default "in the future".
> doc/Use.htm

2019-10-11 15:10:41 +0100
Ken Sharp <ken.sharp@artifex.com>
72ab3591097a2e5ae5201f4a28d3560b019a1019

> PDF interpreter - handle ObjStm with contents which are non-delimited
> No bug number, confidential file supplied by a customer.
> This is in the same area as commit
> d9889892feaac3ca09f85d9bbdc001b1aec50cc3
> In this case the file is actually completely valid and exposes a flaw
> in our processing of ObjStm streams. We 'tokenise' the entire contents
> of the ObjStm, for performance reasons, when we first need to read an
> object from it. This caused problems if we read too many objects which
> was dealt with in the commit above.
> In this case, however, what we have is objects which do not have any
> delimiter, so the tokeniser carries straight on, instead of stopping
> when it reaches the end of the object (as given by the difference
> between successive offsets). For example, if we have three null objects
> then the (decompressed) stream would read nullnullnull, each object
> has a different offset and the length of each is given by subtracting
> one offset from the next.
> What we were reading was, literally, nullnullnull which of course is not
> legal.
> This commit leverages off the code in the commit to fix the extra
> objects and uses the same approach, we set up a ReusableStream on the
> decompressed ObjStm so we can seek around in it, then read each object
> by seeking to the offset, setting up a SubFileDecode (so we stop at the
> end of the object) and reading the object.
> That works as well for this case, albeit with a (negligible in this
> case) performance penalty). We check at the end of reading the objects
> individually, and if we don't have enough objects then we raise a
> warning.
> Resource/Init/pdf_base.ps

2019-10-11 12:06:07 +0100
Ken Sharp <ken.sharp@artifex.com>
fbe920c86d42919620a425d0933d9dcbfaa1c3cb

> PDF interpreter - do not unconditionally restore state in update_alpha
> Bug #701644 "Error: /unregistered in --.pdfexectoken--"
> The problem is caused by the insanely complicated (and inefficient)
> way the file is constructed. We have a SMask in a Group, which is
> enclosed within another Group.
> When we call start a transparency mask we call pdf_prepare_drawing()
> which calls pdf_update_alpha(). Crucially this is called after we have
> entered a substream for an enclosing Group, but it does not begin a
> new substream.
> However, pdf_update_alpha() assumes that if the smask_id has changed
> then a new viewer state has been saved, and the first thing it does
> is restore that state. If no such state has been saved (as here) then
> the code to restore the viewer state sees this as an error (which it is)
> We fix this by checking to see if a viewer state has been pushed before
> trying to restore to it.
> devices/vector/gdevpdfg.c

2019-10-10 17:13:16 +0100
Ken Sharp <ken.sharp@artifex.com>
9dddc61852d012b867e0353c7897b9c5301e17e6

> PDF interpreter - Ignore invalid MediaBox array
> Again, no bug, the specimen file is a confidential customer file.
> The file contains, on page 60, an invalid MediaBox:
> /MediaBox[ 0 0 612 792 0 0 720 917]
> The 8 values were unloaded onto the stack, but only 4 were consumed
> leading to errors later in processing. This commit checks the length
> of the array and if it isn't exactly 4 then it exits and uses the
> current page size instead.
> Resource/Init/pdf_main.ps

2019-10-10 15:51:13 +0100
Ken Sharp <ken.sharp@artifex.com>
d305e46c4af1af14dfe79f7ebab6d2edf168f068

> PDF interpreter - match observed Acrobat processing of Widget annots
> No bug for this, arising from a customer file.
> It appears Acrobat does not render Widget annotations unless the
> annotation dictionary contains a /FT and a /T key, either directly in
> the annotation dictionary or inherited from a Form Definition Field
> dictionary (via the AcroForm /Fields entry).
> This commit checks annotations to see if they are Widgets, then checks
> to see if both /FT sand /T are present. If either is missing we walk
> back up the FDF heirarchy using the /Parent key, storing any FT or T
> keys in the annotation dictionary as we go.
> We don't actually care what the associated values are, we only care if
> they keys are present, so reversing the lookup is acceptable here.
> We then re-test the annotation dictionary for the presence of both keys
> and if either is missing we do not render the annotation.
> Resource/Init/pdf_draw.ps

2019-10-10 10:15:49 +0100
Chris Liddell <chris.liddell@artifex.com>
797ddfc6ef5f0cdfba664f550fe57acc43f309bb

> Fix the logic for permitted directories
> The logic to match a permitted path ending in a directory separator with any
> file in that directory (but only that directory) was wrong, causing us to
> reject such cases.
> base/gpmisc.c

2019-10-10 09:29:48 +0100
Ken Sharp <ken.sharp@artifex.com>
d45d594ea5660976a21106ea864eb879801827b1

> ps2write - restore missing %%PageTrailer comment
> Bug #701659 "Missing %%PageTrailer commen"
> An oversight in commit 96c381cce28c27eac182549441a6c5025b0dcdd6
> caused the comment to be omitted.
> devices/vector/gdevpdf.c

2019-10-09 16:45:31 +0100
Ken Sharp <ken.sharp@artifex.com>
34774ab185f17186b26949f5fee118dee9114d3a

> PDF interpreter - fix /None case of Line Ending style
> Bug #701622 "pdfwrite device fails with annotation appearance"
> This is, in fact, nothing at all to do with pdfwrite. The problem is
> that, when generating an Appearance stream for a /Line Annotation which
> is defined without an Appearance stream, the /None line ending style
> was not popping the copy of the annotation dictionary.
> This led to an error in the annotation. If a previous annotation used
> transparency, then this would cause the compositor to get confused,
> because we would start the transparency in the Line annotation, but
> the error meant we would not close the transparency group.
> Resource/Init/pdf_draw.ps

2019-10-07 00:02:27 +0100
Ken Sharp <ken.sharp@artifex.com>
b2c1beac237865bde26c7fa921d24d17ecda6fab

> pdfwrite - preserve rendering intent
> bug #701487 "Renedring intent not preserved by pdfwrite"
> The pdfwrite device was not previously handling rendering intent changes
> this commit adds a rendering_intent member to the pdfwrite device
> structure, initialises it to 1 (absolute colorimetric) and then tracks
> changes to the graphics state, emitting /RI entries in ExtGSatet
> dictionaries as required.
> This shows a number of small progressions in the test suite, and marked
> progressions with icc_v4_profile.pdf and icc_rendering_intent.pdf.
> devices/vector/gdevpdfb.h
> devices/vector/gdevpdfg.c
> devices/vector/gdevpdfx.h

2019-10-06 17:42:53 +0100
Ken Sharp <ken.sharp@artifex.com>
faef233630240edfc3ad9f5ea154b5b32ed51c75

> pdfwrite - Use CA and ca for text with transparency
> Bug #701631 "pdfwrite: mishandling of alphas with Text render mode 2"
> The problem is in both the PDF interpreter and pdfwrite. In the past
> the PDF interpreter has never been able to create a fill+stroke
> primitive, because PostScript doesn't support that. However we added
> the ability for pdfwrite to maintain text rendering modes, for reasons
> of quality, which breaks that assumption.
> Although we added the stroke and fill constant alpha to the C graphics
> state when we moved the PDF graphics state into the C graphics state,
> nothing actually ever used them. Instead the PDF interpreter sets a
> single 'opacity' alpha channel, based on whether the current operation
> is a stroke or a fill. Because we could not emit a combined operation
> this worked as we would set the opacity separately for each operation.
> Of course for pdfwrite this doesn't work, and looking to the future
> when the fill+stroke primitive is available in the graphics library,
> we will need to do away with the opacity.alpha and properly use the
> fill and stroke alphas stored in the graphics state. For now, however,
> we need to continue to use the opacity.alpha, but when we are handling
> text (in pdfwrite) actually use the values of stroke and fill alpha
> instead of opacity.alpha.
> So add a 'for_text' boolean to all the routines whihch need to set or
> update the alpha, and when writing the ExtGState, if we are handling
> text then use CA and ca instead of opacity.alpha.
> This has also mean altering the XPS interpreter so that it sets the
> stroke and fill alphas as well as opacity.alpha, otherwise pdfwrite
> doesn't know which value to use for text operations.
> devices/vector/gdevpdfd.c
> devices/vector/gdevpdfg.c
> devices/vector/gdevpdfg.h
> devices/vector/gdevpdft.c
> devices/vector/gdevpdts.c
> devices/vector/gdevpdtt.c
> xps/xpscolor.c
> xps/xpsimage.c
> xps/xpsopacity.c

2019-10-05 14:49:18 +0100
Ken Sharp <ken.sharp@artifex.com>
21a10f9e2cb9134c351fd568fc73222f2917e159

> PDF interpreter - Improve PreserveAnnots
> PreserveAnnots currenlty works in conjunction with ShowAnnotTypes, but
> We should really have a separate control for this.
> This commit adds a new /PreserveAnnotTypses (must be set from PostScript
> in the same way as ShowAnnotTypes). PreserveAnnots and PreserveAnnotTypes
> only work with a device which can preserve Annotations (currently this
> is the pdfwrite device only).
> If the device supports Annotation preservation, and PreserveAnnots is
> true (the default0 then for each annotation we consult the Types array,
> if the annotation is to be preserved then we pass it to the device. If
> not, then we pass the annotation to the 'draw' routines which will
> render teh annotation instead.
> Using the two separate controls allows us to selectively control, by
> type, whther annotations are preserved, rendered, or simply ignored
> altogether.
> Also fix an omission, and some typos, in the documentation for
> ShowAnnots in Use.htm
> Resource/Init/pdf_draw.ps
> doc/Use.htm
> doc/VectorDevices.htm

2019-10-07 18:41:10 +0100
Chris Liddell <chris.liddell@artifex.com>
61c489110685f7cab8cbbbca7b15d9b5cb2463d0

> Bug 701657: Allocate "memory" device in immovable gc memory
> Devices are supposed to be allocated in memory that cannot relocate (i.e.
> non-gc memory or an immovable allocation). The memory device accessible from
> Postscript (makeimagedevice/makewordimagedevice) was being created in regular,
> relocatable gc memory.
> This caused an invalid memory access when cleaning up subclassed devices, as the
> one device in the chain may have moved. So switch to using an immovable
> allocation.
> base/gsdevmem.c

2019-10-01 10:35:48 +0100
Chris Liddell <chris.liddell@artifex.com>
2d990b065c228802b3913602b4309165e42c08e9

> Fix memory corruption setting a halftone
> When setting a new halftone in the graphics state, we try to re-use the data
> from the existing device halftone.
> The problem is that the device halftone can have higher component indices than
> there are components in the new halftone we are creating. In this case, we can
> end up writing off the end of the components array for the new halftone
> structure.
> Simply check that the new halftone has enough components before doing the
> duplication.
> base/gsht.c

2019-09-30 13:40:35 +0100
Ken Sharp <ken.sharp@artifex.com>
f03bac8ec2dabfff5583bf6afdd2b77f1885f8ef

> pdfwrite - don't honour /Producer key in DOCINFO pdfmark
> Bug #701639 "pdfwrite should not honour the /Producer key in DOCINFO pdfmark"
> The Producer in the document information dictionary (and XML Metadata)
> is defined quite clearly as the application which produced the PDF file
> from its native format.
> Ghostscript uses the Producer key (if present in the pdfmark) to set
> the Producer, but it should not do so. Adobe Acrobat Distiller (at
> least the end user version) does not permit this value to be altered.
> On reflection we can see why; in the case of a problem with a PDF file
> its important to know which application created it, and we should not
> let PostScript obscure that (we already do not pass the Producer
> information on when the input is PDF).
> The code did already attempt to overwrite any Producer string which
> contained 'Distiller' (I have no idea why) and that code contained an
> error which could lead to an invalid Document Information dictionary
> being created.
> This commit removes the ability for DOCINFO pdfmarks to alter the
> Producer, which obviously fixes the bug.
> However..... it is actually important for our commercial customers to
> be able to set this value. A problem with a PDF file created by one of
> our customer's products should be reported to that customer, not us, as
> we will not be able to investigate the problem while our customer
> should be able to. At the very least our customer will know how to
> retrieve the configuration of Ghostscript being used.
> So permit the commercial version of Ghostscript to set the /Producer
> from a pdfmark.
> devices/vector/gdevpdfm.c

2019-09-27 13:26:01 +0100
Chris Liddell <chris.liddell@artifex.com>
77f79475fd0419d16f1efe7812a44a9720fef10b

> Bug 701634: Correctly handle file name of "\0"
> Attempting to open a file with a filename string starting with a NULL
> character should be treated the same as if the string was zero length.
> Not doing so created a broken file object leading to several operations
> resulting in a segfault.
> Also, add cleanup in the event of such an error, freeing memory allocated in
> preparing the gs stream object.
> base/sfxcommon.c
> psi/zfile.c

2019-09-27 00:05:37 +0100
Robin Watts <Robin.Watts@artifex.com>
ef597bf4a05814a97d05866868f9b96b98746ae9

> Correct Memento usage example in header.
> base/memento.h

2019-09-26 10:47:01 +0100
Chris Liddell <chris.liddell@artifex.com>
7db398d549a03ff5d37ec991eb60f01378eac88d

> Revised comment for 8992f00edfd1c39154c013489de2a01d2e9a92ee
> Make it clearer why the revised behaviour is required.
> base/gstiffio.c

2019-09-26 09:34:02 +0100
Chris Liddell <chris.liddell@artifex.com>
8992f00edfd1c39154c013489de2a01d2e9a92ee

> Bug 701313: Disable libtiff callbacks when libtiff is shared
> It seems that libtiff uses global variables to store the error/warning callbacks
> so if two callers in the exe are using the libtiff shared lib, very bad things
> happen (usually a segfault).
> So, if that's how we're linked, set the callbacks to NULL.
> base/gstiffio.c

2019-09-03 18:37:21 -0700
Ray Johnston <ray.johnston@artifex.com>
6293a99abfdc73b8881b2090cd7b01a1fbef5370

> Fix pdf14_accum for DeviceN target devices such as display
> Also fix display device for DeviceN (-dDisplayFormat=16#a0800).
> Not sure when, but it had bit-rotted.
> The pdf14_accum device now has the DeviceN devn_params available since
> it now includes gx_devn_prn_device_common (rather than gx_prn_device_common).
> A pdf14_accum_CMYKSpot device is added that is used when the target device
> has more than 4 components. The pdf14_accum_CMYKSpot keeps the target device
> (e.g. display) device equiv_cmyk_colors and devn_params updated as the clist
> is being written.
> base/gdevp14.c
> base/gscdevn.c
> base/lib.mak
> devices/gdevdsp.c

2019-09-25 04:57:22 -0700
Robin Watts <Robin.Watts@artifex.com>
74787042b3259d51538d31556c38239d72539e3f

> Run toolbin/headercompile.pl and update dependencies in Makefiles.
> Move the definition of x_pixel within the headers to ensure
> gdevcmp.h stands alone.
> Include a ufst header to ensure that gxfapiu.h stands alone.
> base/gxfapiu.h
> base/lib.mak
> base/tiff.mak
> devices/contrib.mak
> devices/devs.mak
> devices/gdevx.h
> devices/gdevxcmp.h
> psi/int.mak
> toolbin/headercompile.pl

2019-09-25 14:35:00 +0100
Robin Watts <Robin.Watts@artifex.com>
eb7802dc979aaa0e9e43310de0f1e8dcc7b31b2c

> Bug 578865: Fix typo
> Fix typo in previous commit.
> base/gdevp14.c

2019-09-19 12:07:00 +0100
Robin Watts <Robin.Watts@artifex.com>
73bd448d2ebabad9ee31053abf897325a639cba1

> Bug 578865: Push transparency group for non idempotent shadings.
> Shadings that write the same pixels more than once can be
> rendered incorrectly for blendmodes that aren't idempotent
> (or for non solid opacities). In such cases, push a transparency
> group so that the shading can be written just once, and
> then safely blended.
> Note that this doesn't capture shadings that are rendered
> via zshfill.
> base/gdevp14.c
> base/gstparam.h

2019-09-23 18:52:16 +0100
Robin Watts <Robin.Watts@artifex.com>
1d1d6dc851e23edb36ac6e5db1bdf0edbba262bd

> Knockout groups should knockout the group alpha (and shape) too.
> When marking within a knockout group, for each pixel we mark, we
> throw away the current colorant values in the destination, and
> base the calculations of the new colorant values on the stored
> backdrop values.
> We were failing to do this for the group alpha and shape
> calculations. This could lead to the group alpha getting out of
> sync with the actual colorant values. We were seeing this with
> shadings (particularly gradient shadings) where the shadings
> paint some pixels more than once.
> This becomes much more obvious with the forthcoming commit to
> use knockout groups for shadings with either transparency or
> non-idempotent blend modes.
> base/gdevp14.c

2019-09-24 15:48:54 +0100
Chris Liddell <chris.liddell@artifex.com>
05e794d14a2853c45a08d5c49d50d1fa5cadaf6c

> Cope with .setsafe(global) being called when already 'SAFER'
> As we default to SAFER file controls now, we want to cope with .setsafe and
> .setsafeglobal being called either when already SAFER, or called multiple times.
> This means adding a .currentpathcontrolstate operator so we don't try to
> influence the path control lists after control is activated.
> Resource/Init/gs_init.ps
> psi/zfile.c

2019-09-24 09:18:47 +0100
Chris Liddell <chris.liddell@artifex.com>
5ca729649efc3b041237b8b45bd2d011b70143ff

> tiffsep(1): Cope with .tiff ending as well as .tif
> devices/gdevtsep.c

2019-09-23 20:04:49 +0100
Robin Watts <Robin.Watts@artifex.com>
d1daff4546ae8fae46fc4acb8b0bef013753488a

> Recast validate to use gs_file_name_check_separator.
> Avoid using gp_file_name_directory_separator, as windows can
> have 2 different directory separators.
> base/gpmisc.c

2019-09-23 18:05:00 +0100
Chris Liddell <chris.liddell@artifex.com>
3f4fc81482ecfef51adb4af98f6ac214c7e64bdb

> Remove spurious call to gp_validate_path_len()...
> ...in gx_device_open_output_file()
> There is no need to validate the path in gx_device_open_output_file() as it will
> be done at a lower level (gp_fopen) for paths that require it (we only validate
> *after* the Postscript style %device% paths have been expanded into 'real'
> paths).
> This also interacts badly with the revised handling of formatted string
> file names, hence remove it.
> base/gsdevice.c

2019-09-23 17:56:34 +0100
Chris Liddell <chris.liddell@artifex.com>
f874c5b9d2d5a3798dc00e53149c4a470ce5da01

> Fix tiffsep(1) interaction with file permissions lists
> The previous solution didn't quite work, when using formatted strings for
> output file names (i.e. output-%d.tif).
> This adds a dedicated gs_remove_outputfile_control_path() to mirror
> gs_add_outputfile_control_path() and uses those for the dynamic adding and
> removing of separation output file names.
> base/gslibctx.c
> base/gslibctx.h
> devices/gdevtsep.c

2019-09-23 17:11:47 +0100
Robin Watts <Robin.Watts@artifex.com>
a1c253838b0e1ccbadc5c0bdb6e3bde59b3b00a1

> Update path validation to accept multiple *'s as special case.
> Previously we interpretted multiple *'s as meaning the same as
> single *'s. Now we use them to mean "just those chars that
> might be created by the use of a %...{d,x,u,i,o,X} format
> specifier".
> base/gpmisc.c
> doc/Use.htm

2019-09-23 16:41:09 +0100
Robin Watts <Robin.Watts@artifex.com>
3147ffb314f344520fb22c8bc57d4afcdc3c9c62

> Improve OutputFile handling of %d etc.
> Only accept %d (and friends) (as opposed to anything starting with %).
> Only accept legal combinations of flags/widths/precision etc.
> Generate a more conservative wildcard.
> base/gslibctx.c

2019-09-23 09:25:27 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
a38bf66e8e041f21ebb25492e576262a55b318b1

> Bug 697545 : Prevent memory leaks and SEGV in pcl_font_header.
> Update pcl_font_header to avoid freeing uninitialised font structure and also
> double freeing the font.
> Error created using :-
> MEMENTO_FAILAT=17247 ./membin/gpcl6 -sDEVICE=pbmraw -o /dev/null ./tests_private/pcl/pcl5cfts/fts.0573
> pcl/pcl/pcsfont.c

2019-09-22 20:11:00 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
893018e1c7aca3218555701208cc41daee34b8c4

> Bug 697545 : Prevent memory leaks in pcl_execute_macro.
> Prevent memory leaks on error.
> Error created using :-
> MEMENTO_FAILAT=15270 ./membin/gpcl6 -sDEVICE=pbmraw -o /dev/null ./tests_private/pcl/pcl5cfts/fts.1100
> pcl/pcl/pcmacros.c

2019-09-20 12:38:02 -0700
Ray Johnston <ray.johnston@artifex.com>
adc3adfdf30f625444203a7c624c3fa123cfddd2

> Slight improvement to "permit-file-***" parameter documentation.
> doc/Use.htm

2019-09-20 11:17:53 -0700
Ray Johnston <ray.johnston@artifex.com>
829bfe72c69091da7f0d7c1243a7647114619070

> Fix tiffsep and tiffsep1 with new file access control and SAFER mode
> The tiffsep and tiffsep1 synthesize output file names with the outputfile
> and the separation color name, but the 'open' of these filenames would
> fail since they were not included on the permit_file_writing list.
> Add the full filename before opening, and remove the names after closing.
> devices/gdevtsep.c

2019-09-20 11:53:10 -0700
Robin Watts <Robin.Watts@artifex.com>
baad48ab4b35dc9edf0317a1773d9efc7631f2d7

> Squash stupid const warning.
> base/gslibctx.c

2019-09-20 19:42:01 +0100
Robin Watts <Robin.Watts@artifex.com>
3aa9b059018bb49ddf67a87ddd87e01157143b99

> Squash some "const" warnings.
> pcl/pl/plmain.c

2019-09-19 11:51:40 +0100
Robin Watts <Robin.Watts@artifex.com>
a09321624369d215a733fb991bf48c300c90107a

> Remove some needlessly passed parameters.
> For I am a bear of tiny brain, and such things confuse me.
> base/gdevp14.c

2019-09-20 17:49:57 +0100
Robin Watts <Robin.Watts@artifex.com>
02108ce46f9beafbfa733598164a6ad254ada7ca

> Fix "permit-file-xxxx" handling.
> Ray spotted that gs_add_explicit_control_path was adding 17
> to arg before using it. 17 happens to be the right amount
> to add for "--permit-file-read=", but the wrong amount for
> write/control/all.
> Update the code to call it with the correct arg pointer
> to start with.
> Also, update a couple of routines to cope with being called
> with NULL strings.
> Also use enum values in switch rather than 0, 1, 2.
> base/gslibctx.c
> pcl/pl/plmain.c
> psi/imainarg.c

2019-09-18 20:40:42 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
c0df83637a6234f804bef5a7ef31fe1bc5b66d78

> Bug 697545 : Prevent SEGV in append_macro.
> Prevent SEGV if append_macro is called with a NULL pointer and safe guarded
> calls to chunk_resize_object and chunk_object_size. Also resolved leak when
> resetting macros.
> Error created using :-
> MEMENTO_FAILAT=14839 ./membin/gpcl6 -sDEVICE=pbmraw -o /dev/null ./tests_private/pcl/pcl5cfts/fts.1060
> base/gsmchunk.c
> pcl/pcl/pcmacros.c
> pcl/pcl/pcparse.c

2019-09-19 11:02:48 +0100
Chris Liddell <chris.liddell@artifex.com>
071b96290c5e524291bb33b132e2cea3efd5f98e

> Make missing jbig2 decoder fatal error.
> If we have neither Luratech nor jbig2dec, have configure fail, unless
> explicitly run with --without-jbig2dec
> configure.ac

2019-09-18 17:18:29 +0100
Ken Sharp <ken.sharp@artifex.com>
d9889892feaac3ca09f85d9bbdc001b1aec50cc3

> PDF interpreter - handle ObjStm containing more objects than declared
> There's no bug number for this one, I can't easily create a reduced file
> without inadvertently fixing the problem, and I don't want to put the
> customer file into Bugzilla.
> The problem is that the file contains an ObjStm (a compressed stream
> containing a sequence of PDF objects) which contains more objects than
> the stream declares. Not only that, but the extra object is neither the
> first nor the last object, so its not trivial to ignore.
> Most consumers handle ObjStm constructs by using the 'catalog' at the
> head of the stream to find the offset of each object in the stream and
> then reposition to that object and read a single PDF object (note that
> objects in an ObjStm do not begin with 'obj' and do not end with
> 'endobj') which is IMO putting a lot of faith in the consumer's
> ability to detect a single object.
> For performance reasons Ghostscript's PDF interpreter reads *all* the
> objects in the ObjStm immediately and stores them, thus trading memory
> use for performance (we only need to read and decompress the objects
> once). This approach is totally defeated when there are more objects
> than expected, because we don't know which object relates to which
> object number (no 'x y obj' in an ObjStm).
> In this commit we spot the discrepancy; if there are too few objects we
> exit immediately with an error (technically we could do something about
> this too, provided the missing object is never used). If there are extra
> objects then we move to a fallback.
> We discard all the objects we've read, then use the offsets in the
> 'catalog' to calculate the position and length of each object in the
> ObjStm. We position the file pointer to the start of the object and
> use a SubFileDecode filter to limit the number of bytes read to the
> difference between the offsets. We then use the existing code to read
> all the objects in that stream. If we get more than one then we discard
> all but the first.
> Repeat the above until we reach the last object in the catalog; that has
> no known length so just read from there to the end of the stream.
> The complications are all around getting the objects on the stack in
> the order expected by the code which follows, and defines the actual
> objects.
> Resource/Init/pdf_base.ps

2019-09-18 14:28:32 +0100
Robin Watts <Robin.Watts@artifex.com>
107aae1f353db3b62f8b714c5100ec7bc180f2fb

> Tri/QuadriLinear changes for lcms2mt.
> Add a mechanism so that we can force lcms2mt to use
> TriLinear (or QuadriLinear) interpolation for specific
> transforms. This is primarily useful so we can get
> "best case" transforms which we can use as a baseline
> for our accelerations.
> The use of TriLinear/QuadriLinear is governed by a new
> cmsFLAG bit, passed in to link creation. Unfortunately,
> these flag bits are not passed all the way down to where
> we actually need them. To avoid having to add an extra
> flags argument in many places, I stash the flags in a
> new field in the cmsContext. This is safe, if not entirely
> pretty, as each context will only be used in a single
> thread at a time. If this was a function used for more
> than just testing, we'd consider doing it in the neater
> (but more invasive) way.
> lcms2mt/include/lcms2mt.h
> lcms2mt/src/cmscnvrt.c
> lcms2mt/src/cmsintrp.c
> lcms2mt/src/cmsopt.c
> lcms2mt/src/lcms2_internal.h

2019-09-16 11:32:33 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
0b05dca78aaa456ba7b55b853917a4ae68a6fd38

> Bug 697545 : Prevent memory leaks in show_char_background.
> Prevent memory leaks on error and then later releasing graphic state.
> Error created using :-
> MEMENTO_FAILAT=15988 ./membin/gpcl6 -sDEVICE=pbmraw -o /dev/null ./tests_private/pcl/pcl5cfts/fts.0891
> pcl/pcl/pctext.c

2019-09-17 10:37:58 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
f40631e7592ed1287b2121840b3345acb1bdb1a8

> Bug 697545 : Prevent leak in gx_image_enum_begin.
> Prevent leak in gx_image_enum_begin by freeing clip_dev.
> Error created using :-
> MEMENTO_FAILAT=15565 ./membin/gpcl6 -sDEVICE=pbmraw -o /dev/null ./tests_private/pcl/pcl5cfts/fts.0954
> base/gxipixel.c

2019-09-17 09:02:49 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
91d18aec6a19a0d3b341701d10355278f4703fdd

> Bug 697545 : Prevent SEGV in download_pcl_pattern.
> The pattern is consumed by pl_dict_put during errors so remove second attempt to free it.
> Error created using :-
> MEMENTO_FAILAT=15501 ./membin/gpcl6 -sDEVICE=pbmraw -o /dev/null ./tests_private/pcl/pcl5cfts/fts.0954
> pcl/pcl/pcuptrn.c

2019-09-17 11:42:13 +0100
Chris Liddell <chris.liddell@artifex.com>
8c5348ae5fc35b449aa68eb6668cb6cbc6f345e0

> Fix file permissions interaction with '@' command line
> If an options file (prefixed '@' on the command line) followed something that
> required initialising the Postscript interpreter (such as a '-c' option),
> opening the file would potentially fail because file permissions had been
> activated by the interpreter.
> Add and remove the file from the permit reading list before attempting to open
> it.
> base/gsargs.c

2019-09-16 15:10:46 +0100
Chris Liddell <chris.liddell@artifex.com>
955c431ab611efd9a74e62a762cdc1ab9f64e14a

> Add explicit "flush" after warning message.
> The warning messages could get trampled on (due to buffering) by messages on
> stderr, flushing ensures the warning is emitted as intended.
> Resource/Init/gs_init.ps

2019-09-13 09:33:20 +0100
Chris Liddell <chris.liddell@artifex.com>
2b3ed0ea5d07005e64badfb9212911a725fefb94

> Have .setsafe/.setsafeglobal undefine operators
> In SAFER, we undefine certain delicate operators (mostly transparency related
> ones), but we weren't doing so if SAFER was enabled using .setsafe
> This means some rejigging to keep NOSAFER and DELAYBIND working.
> Resource/Init/gs_init.ps

2019-09-12 14:23:10 +0100
Chris Liddell <chris.liddell@artifex.com>
b3a1114d04a82e534d915b125eb34de21317993a

> If set, add PCLFONTSOURCE value to permit_file_reading list
> pcl/pl/pjparse.c

2019-09-11 13:07:02 +0100
Chris Liddell <chris.liddell@artifex.com>
0350a0ab56e7b180d62af9423313d6c70345b386

> Bug 701561: 'reduce' paths before adding to permit lists
> Before attempting to open files, we pre-process the requested file name to
> remove surplus/unnecessary elements: i.e. './././file' would be reduced to just
> './file', or '../dir/../dir/../dir/file' would be reduced to '../dir/file'.
> The 'reduced' path is what we try to open, hence it is also what we check
> against the file permissions list before we allow files to be accessed.
> That being so, we should also 'reduce' paths as we add them to the permissions
> lists - thus the permissions list creation and checking are consistent.
> base/gslibctx.c
> base/lib.mak

2019-09-15 12:18:48 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
511260d72a4b6df9bd2ba48e022f7c3921b547cb

> Bug 697545 : Propagate error codes from pcl_break_underline correctly.
> The code has been updated to correctly propagate error codes from all
> instances of pcl_break_underline.
> pcl/pcl/pccprint.c
> pcl/pcl/pcfont.h
> pcl/pcl/pcpage.c
> pcl/pcl/pcpatrn.c
> pcl/pcl/pcpatxfm.c
> pcl/pcl/pctext.c
> pcl/pcl/pcursor.c

2019-09-11 14:10:27 -0700
Ray Johnston <ray.johnston@artifex.com>
c917d64d73fae679d445b233662e0ef4480078f6

> Fix Bug 696333. Allow large bitmaps in clist when writing tile cache.
> When writing bits to update the tile cache, we don't need to restrict to
> a single command buffer as with the copy_mono and copy_color commands.
> Progressions on:
> tests_private/comparefiles/Bug694385.pdf.psdcmyk.300.1..gs
> tests_private/pdf/sumatra/2028_-_invisible_patterns.pdf.psdcmyk.300.1..gs
> tests_private/ps/ps3cet/09-47B.PS.pdf.pkmraw.300.0..gs_pdf
> tests_private/ps/ps3fts/176-01.ps.psdcmyk.300.1..gs
> base/gxclbits.c
> base/gxcldev.h
> base/gxclrect.c

2019-09-12 10:37:42 -0700
Ray Johnston <ray.johnston@artifex.com>
d79d17251261637b672f8518144ffffc42e1eb0e

> Fix SEGV with flp device and PCL with clist mode and large BandHeight.
> If the 'clist_init' fails initially (with rangecheck) due to the buffer
> space too small for the BandHeight specified, we loop in the caller after
> increasing the buffer size, but clist_init left "is_open" false when failing.
> Add save_is_open in gdev_prn_setup_as_command_list so that we can restore it
> if the clist_init eventually suceeds.
> The SEGV was with image_data because re-opening the flp device reset the
> "obsolete" procs to the default, so flp_image_data was replaced by the
> gx_default_image_data, but no begin_image had been performed (flp_begin_image
> skipped this since we were not yet at the FirstPage).
> base/gdevprn.c
> base/gxclist.c

2019-09-16 18:53:49 +0200
Sebastian Rasmussen <sebras@gmail.com>
8b0ed52ead9605cae14939362dbf9cdf22b9746c

> Update jbig2dec stuff for 0.17 release.
> jbig2dec/CHANGES
> jbig2dec/jbig2.h
> jbig2dec/jbig2dec.1

2019-09-16 18:48:36 +0200
Sebastian Rasmussen <sebras@gmail.com>
79e2d671b672f3bc4cca09808dd683b71eff702a

> jbig2dec: Use the same contact information everywhere.
> jbig2dec/README
> jbig2dec/configure.ac.in
> jbig2dec/jbig2dec.1

2019-09-16 16:12:32 +0100
Paul Vojta <vojta@math.berkely.edu>
7e49d51de2b14f9a4ca873135ba3c8d7aa56256f

> Documentation - fix some typos
> Bug #701589 "Minor documentation problems in 9.28-rc2"
> Thanks to Paul Vojta for pointing these out. Unfortunately we cannot use the
> supplied patch, as it includes alterations to History9.htm, which is auto-
> generated from the commit logs. The remaining changes are applied here.
> doc/Language.htm
> doc/Use.htm

2019-09-11 12:18:51 +0100
Chris Liddell <chris.liddell@artifex.com>
e3d2cd4b2f13573962105d1761e7bb58d5f079c9

> Bug 701563: pdfwrite annotation pdfmark /Border key
> Despite the spec saying the values for the /Border key are in user space
> coordinates, Distiller appears to pass the values through to the output PDF
> untouched (no rescaling - unlike the values for /Rect, also in user space,
> according to the spec, which it does scale/translate). Ghostscript/pdfwrite
> did scale the /Border values.
> This just changes pdfwrite to write the values out unchanged.
> devices/vector/gdevpdfm.c

2019-09-16 09:56:52 +0100
Ken Sharp <ken.sharp@artifex.com>
4ca426a86125b7bf2f52c00fbba1cef1395ea011

> Documentation - add a note about SAFER for PDF/X ICC profiles
> Bug #701553 "Examples of PDF/X and PDF/A conversion should be updated for Ghostscript 9.28"
> ICC profiles required for PDF/X and PDF/A output need to be readable
> in order to work when -dSAFER is true (the new default). This wasn't
> clear from the documentation, so add a note about it.
> As noted in the bug report, it is possible to embed the profile in the
> PostScript code, but as Chris says this is probably beyond reasonable
> expectations of the average user; they simply won't change the example
> and will then complain that it isn't correct. Users capable of making
> this work almost certainly have enough knowledge to realise they can
> do this instead of making the profile readable.
> doc/VectorDevices.htm

2019-09-13 10:28:37 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
e0238104296a361d2dfcc678075e32f4c2070c52

> Bug 697545 : Propagate error codes from pcl_set_cap_x and pcl_set_cap_y correctly.
> The code has been updated to correctly propagate error codes from all instances
> of pcl_set_cap_x and pcl_set_cap_y.
> pcl/pcl/pcfontpg.c
> pcl/pcl/pcjob.c
> pcl/pcl/pcpage.c
> pcl/pcl/pcsfont.c
> pcl/pcl/pcstatus.c
> pcl/pcl/pcursor.c
> pcl/pcl/pcursor.h
> pcl/pcl/rtgmode.c

2019-09-12 07:59:03 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
29f3e8d45595f443170bf13290404be4d34b5a2e

> Bug 697545 : Propagate error codes from pcl_do_CR and pcl_do_LF correctly.
> The code has been updated to correctly propagate error codes from all instances
> of pcl_do_CR and pcl_do_LF.
> pcl/pcl/pcfontpg.c
> pcl/pcl/pcparse.c
> pcl/pcl/pctext.c
> pcl/pcl/pcursor.c
> pcl/pcl/pcursor.h

2019-09-12 19:41:47 +0100
Robin Watts <Robin.Watts@artifex.com>
afe11ca136aa173541ed0df09b8c189d2344f381

> Fix various printer devices to properly call spec ops.
> Various printer devices (psd, psdcmykog, tiffsep, tiffscaled)
> were passing the spec ops on to gx_default_dev_spec_op rather
> than gdev_prn_dev_spec_op.
> The most obvious implication of this was that we'd sometimes
> get a warning about printer devices having a private spec op.
> devices/gdevcmykog.c
> devices/gdevpsd.c
> devices/gdevtsep.c

2019-09-12 17:09:50 +0100
Robin Watts <Robin.Watts@artifex.com>
3b2ad1f24d2e9705481f9feb6835aa3e851726ac

> Bug 701568 followup: Fix RLE compressor.
> The previous fix to the RLE compressor reveals an additional
> existing issue to do with us not checking whether we have
> space in the buffer to write the EOD byte.
> Fixed here.
> base/srle.c

2019-09-12 09:35:01 +0100
Robin Watts <Robin.Watts@artifex.com>
68c7275d4a580dca6c0ed3798f3717eea3513403

> Bug 701568: Fix gdevpx.c RLE stream handling.
> The current code in pclxl_write_image_data_RLE passes
> lines of data to the RLE compression routine. It tells
> each invocation of that routine that this is the "last"
> block of data, when clearly it is not.
> Accordingly, the compression routine inserts the "EOD" byte
> into the stream, and returns EOFC.
> Independently of the return value used, having multiple EOD
> bytes in the data is clearly wrong. Update the caller to only
> pass "last" in for the last block.
> The code still returns EOFC at the end of the data, so update
> this final call to accept (indeed, expect) that return value
> there.
> devices/vector/gdevpx.c

2019-09-10 14:22:32 +0100
Robin Watts <Robin.Watts@artifex.com>
13a560a4d13d51e4dd9f7dd48b27a6ebe681f877

> Update CAL makefile for NEON cms functions (correction)
> Add NEON flags and includes.
> base/cal.mak

2019-09-10 14:22:32 +0100
Robin Watts <Robin.Watts@artifex.com>
61cff6434022bb4c444bd500da0628302abfb35e

> Update CAL makefile for NEON cms functions.
> base/cal.mak

2019-09-10 20:26:38 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
be793aa94180e06135fd7fec36b6f6ab9ab67519

> Bug 697545 : Prevent memory leaks in gx_image_enum_begin.
> Prevent memory leaks on error and then later releasing graphic state.
> Error created using :-
> MEMENTO_FAILAT=15242 ./membin/gpcl6 -sDEVICE=pbmraw -o /dev/null ./tests_private/pcl/pcl5cfts/fts.0720
> base/gxipixel.c
> pcl/pcl/pcparse.c

2019-09-09 21:41:16 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
08c1e576fc09fcc7fdf5cd935d91fdfea1e7f0f9

> Bug 697545 : Propagate error code in pcl_enter_graphics_mode.
> Propagate error code in pcl_enter_graphics_mode to prevent trying to use an
> uninitialised variable later leading to SEGV.
> Error created using :-
> MEMENTO_FAILAT=15210 ./membin/gpcl6 -sDEVICE=pbmraw -o /dev/null ./tests_private/pcl/pcl5cfts/fts.0720
> pcl/pcl/rtgmode.c

2019-09-10 09:04:46 -0700
Ray Johnston <ray.johnston@artifex.com>
8675b40266cbf9771a08f4178a6009cfd17e0ba1

> Fix bug 701550, problem with forall on strings.
> Hard to believe, but this problem has existed since at least version 3.33.
> The 'string_continue' function altered the size which was used to decide if
> there were still characters to be processed BEFORE invoking the 'push(#)' macro.
> If the 'push(1)' encountered a full stack segment, it would return stackoverflow
> so that the operand stack could be extended. This meant that the decision to
> stop enumerating the string would end early (depending on how many times the
> stackoverflow occurred).
> Usually the procedure of the forall would either consume the character (reducing
> the stack), or add an element to the stack triggering the stack extension before
> the next execution of string_continue, but -c "401 string { dup } forall count ="
> results in only 800 stack elements (rather than 802 as expected).
> psi/zgeneric.c

2019-09-08 13:30:52 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
d9e1d9474e5e21fe8ed9a451b91c48233e629eee

> Bug 697545 : Prevent memory leaks and memory corruption.
> Prevent several memory leaks in pcl_enter_graphics_mode by releasing graphic state.
> Also prevent memory corruption by propagating error code from pcl_set_drawing_color.
> Error created using :-
> MEMENTO_FAILAT=14648 ./membin/gpcl6 -sDEVICE=pbmraw -o /dev/null ./tests_private/pcl/pcl5cfts/fts.0861.new
> pcl/pcl/pcdraw.c
> pcl/pcl/rtgmode.c

2019-09-09 14:19:33 +0100
Robin Watts <Robin.Watts@artifex.com>
bc48c29c5e86e6c528e23140c71ecfb58588333f

> Optimise Eval{5,6,7,8}Inputs{,Float}.
> Only use 1 Temporary array, and avoid needless work in the
> 0xFFFF cases.
> lcms2mt/src/cmsintrp.c

2019-09-09 11:03:59 +0100
Robin Watts <Robin.Watts@artifex.com>
63e1fd40674a4f89f6593098cf100382061753e5

> Tweak Eval4InputsFloat for speed.
> Move to the Pentachoronal Interpolation algorithm.
> lcms2mt/src/cmsintrp.c

2019-09-06 18:04:17 +0100
Robin Watts <Robin.Watts@artifex.com>
1cc72912138544dcf00ed0dbc77ceaf47de04e91

> Tweak Eval4Inputs for speed.
> In coding the SSE version for CAL, I spotted a slightly
> preferable test that allows us to capture some special
> cases for free. These special cases accelerate some
> useful cases including:
> * C=M=Y=K (such as when all 0 = white?)
> * C=M=Y (such as when pure black)
> * M=Y=K (possibly useful in case we ever have profiles that
> store K first).
> lcms2mt/src/cmsintrp.c

2019-09-06 17:10:22 +0100
Robin Watts <Robin.Watts@artifex.com>
3f46434c0fe3707f53a825f39fa1bab8c0875c03

> Update CAL initialisation to register second lcms2mt plugin.
> The first plugin deals with transformations. The second deals
> with interpolation.
> base/gsicc_lcms2mt.c

2019-06-13 01:35:36 +0200
Sebastian Rasmussen <sebras@gmail.com>
b5e5ed8620f348e0fa619171d6f05a966a4bcf83

> jbig2dec: Validate coordinates when add image onto page.
> Detected by Coverity in CID 94850.
> jbig2dec/jbig2_page.c

2019-06-12 18:55:16 +0200
Sebastian Rasmussen <sebras@gmail.com>
ccc1a52f59194193450747e41006982d322c43a5

> jbig2dec: Avoid extending page image beyond INT_MAX pixels high.
> Detected by Coverity in CID 95080.
> jbig2dec/jbig2_page.c

2019-06-12 18:52:44 +0200
Sebastian Rasmussen <sebras@gmail.com>
758951f873b4b80de3c11294c3bc76ca0d6144d7

> jbig2dec: Validate range of Huffman Table range values.
> Detected by Coverity in CID 94835.
> jbig2dec/jbig2_huffman.c

2019-06-07 13:29:40 +0200
Sebastian Rasmussen <sebras@gmail.com>
cd815dfe5e8db6e997466765218c80bb54902234

> jbig2dec: Avoid double checks for negative coordinates.
> Negative coordinates are already handled prior in the function
> by falling back to the unoptimized case.
> This was detected by Coverity in CID 303984 and CID 303985.
> jbig2dec/jbig2_image.c

2019-07-03 02:27:40 +0200
Sebastian Rasmussen <sebras@gmail.com>
1ae9b9b92bfa6fef04a50b8f27c3dc6e9e03fba0

> jbig2dec: A small collection of code cleanups.
> * Refer to Jbig2ArithCx for memsetting in case it ever changes.
> * Fix typo.
> * Avoid using local variable when unnecessary.
> jbig2dec/jbig2.c
> jbig2dec/jbig2_symbol_dict.c
> jbig2dec/jbig2_text.c

2019-06-21 15:02:14 +0200
Sebastian Rasmussen <sebras@gmail.com>
14cc5cb07861b8bd8c3a2cfd1d7ac21dd98fa202

> jbig2dec: Add all ubc test files.
> jbig2dec/test_jbig2dec.py

2019-06-14 03:27:31 +0200
Sebastian Rasmussen <sebras@gmail.com>
49a6ff2b166a4cda4d7b8c9d8192bb6f419c7ca3

> Bug 701197: jbig2dec: Fix incorrectly computed halftone skip mask.
> Halftone regions using a skip mask and negative horizontal grid origin
> offsets caused issues due to multiplying signed and unsigned integers.
> The mixed types expression was computed unsigned unsigned arithmetic
> before being converted back to a signed integer. This meant that an
> expected negative value became positive.
> Several of the test files mentioned in the README rendered incorrectly,
> e.g. 200-6-45.jb2. With this fix all files render correctly again.
> jbig2dec/jbig2_halftone.c

2019-06-14 15:09:12 +0200
Sebastian Rasmussen <sebras@gmail.com>
8719833a6a4242880ad8b81cb8fe19e03667af52

> jbig2dec: Avoid duplicate declarations of Huffman tables in test code.
> This is done by moving the tables into a separate compilation module and
> declaring the tables extern in the header file that is used elsewhere.
> base/jbig2.mak
> jbig2dec/Makefile.am
> jbig2dec/Makefile.unix
> jbig2dec/jbig2_hufftab.c
> jbig2dec/jbig2_hufftab.h
> jbig2dec/msvc.mak
> windows/ghostscript.vcproj
> windows/ghostscript_rt.vcxproj

2019-06-14 14:51:01 +0200
Sebastian Rasmussen <sebras@gmail.com>
d75727a7fd5efb2245c7b0d0b33ee8611446c150

> jbig2dec: Fix leak of huffman decoder state in test code.
> jbig2dec/jbig2_huffman.c

2019-06-14 14:50:09 +0200
Sebastian Rasmussen <sebras@gmail.com>
b3f859987f152e13ab141143234f686749f2caf7

> jbig2dec: Declare internal data array static.
> jbig2dec/jbig2_arith.c

2019-06-14 14:47:44 +0200
Sebastian Rasmussen <sebras@gmail.com>
49fa7d21bc555a96e19318b56301185f12f68c55

> jbig2dec: Fix leak of log message in command line tool.
> jbig2dec/jbig2dec.c

2019-06-21 15:02:02 +0200
Sebastian Rasmussen <sebras@gmail.com>
314250a3126243a228249ebf1e6272c0beaec9d6

> jbig2dec: Verify file hashes of test files during testing.
> Previously jbig2dec would accept any file with the same name.
> jbig2dec/test_jbig2dec.py

2019-06-14 14:49:21 +0200
Sebastian Rasmussen <sebras@gmail.com>
a9b92d33e7ed5e06d0728d6a1be771d8b464c50e

> jbig2dec: Expect test files to reside inside jbig2dec directory.
> jbig2dec/test_jbig2dec.py

2019-06-14 15:18:45 +0200
Sebastian Rasmussen <sebras@gmail.com>
8b3ffd237746e2bab2867ad460e8635a79cd5916

> jbig2dec: Indent test code by spaces like the rest of the code.
> jbig2dec/test_jbig2dec.py

2019-06-14 22:18:14 +0200
Sebastian Rasmussen <sebras@gmail.com>
2e957c0b1afc6d2d705c9d075fc55db2de5df854

> jbig2dec: Make tests expect that some test files return white image.
> Previously these tests would just error out and jbig2dec would not
> return any output file at all. Now, jbig2dec parses as much as
> possible, while emitting warning/error messages. In the case of a
> few of the test files the end result is a white image.
> jbig2dec/test_jbig2dec.py

2019-06-14 15:15:53 +0200
Sebastian Rasmussen <sebras@gmail.com>
1c5c3a1f14c85582d09ab58f55b1fd83435b6562

> jbig2dec: Indent Makefiles with tabs like the rest of the Makefiles.
> base/jbig2.mak

2019-09-03 23:54:52 +0100
Robin Watts <Robin.Watts@artifex.com>
5a6832ca60dfc34cb9a0680590cbd086f528fd22

> Implement HyperPentahedral interpolation within lcms2mt.
> This accelerates conversions from 4 component spaces, such as
> CMYK.
> base/gxfill.c
> lcms2mt/src/cmsintrp.c

2018-10-31 20:22:11 +0100
Sebastian Rasmussen <sebras@gmail.com>
1c6d485f4ba59072fba1a73f8f61071b00d7a7e6

> Bug 700088: Report error if all wanted J2K components are not decoded.
> Ghostscript used to attempt to use even the undecoded components.
> The source code for upstream's opj_decompress tool avoided this by
> a workaround along with a comment indicating that this ought to be
> done in the library (so all clients, e.g. Ghostscript will benefit
> from it). With this commit the library will error out if not all
> requested components are successfully decoded. Thus Ghostscript
> will no longer crash.
> Reported in https://github.com/uclouvain/openjpeg/issues/1158
> sent upstream in https://github.com/uclouvain/openjpeg/pull/1164
> and finally committed in e66125fe260deee49fdf6e9978d9bd29871dd5bb
> openjpeg/src/bin/jp2/opj_decompress.c
> openjpeg/src/lib/openjp2/j2k.c

2019-09-03 12:34:55 -0700
Michael Vrhel <michael.vrhel@artifex.com>
b7d32c453538bee41c34f8a77a3feb1dcc0ce759

> Undo commit 95f7befcec1b30fd5014c8ad616485d32901ce33 for release
> Proper handling of the page group color space is going to require
> a more complex solution whereby we ensure that we do the final
> alpha blending in the page group color space and not the target
> device color space.
> base/gstrans.c

2019-09-03 08:52:16 -0700
Michael Vrhel <michael.vrhel@artifex.com>
40934a68930a1d6a41a26df694e1e50fe3c60202

> Add -sBlendColorProfile into Use.htm
> doc/Use.htm

2019-09-03 18:15:56 +0100
Robin Watts <Robin.Watts@artifex.com>
e63504054baea4275af88e95418b5282c4394685

> Avoid potential UMR with arg checking in arg sanitization code.
> base/gslibctx.c

2019-09-02 17:16:45 +0100
Robin Watts <Robin.Watts@artifex.com>
cfdb64eec150da48dea5063b14ae7596e6b7050a

> Proper fix for deep color overprint.
> The previous fix confused memset and memcpy. Properly write the
> (native endian) 16 bit color values into the big endian buffer.
> base/gsovrc.c

2019-09-02 12:59:33 +0100
Robin Watts <Robin.Watts@artifex.com>
eeeb033d21f22b128900ebc998668c87be725f7d

> Fix deep color mattes.
> As seen with the content vanishing when rendering
> tests_private/pdf/sumatra/uninitialized_value_with_JPX_images.pdf
> to psdcmyk16. The Softmask on the image has a Matte of [1,1,1]
> and the calculations in the current code overflow, meaning that
> it comes out as completely white.
> We resort to 64bit to avoid the overflow. Mattes are vanishingly
> rare, so speed shouldn't be an issue. We can revisit if we ever
> find a case that matters.
> base/gdevp14.c

2019-08-31 12:45:47 +0100
Robin Watts <Robin.Watts@artifex.com>
5569e2b2057a25ff1fe0b2b5106e71f2b5142f5c

> Update overprint hl_color code to cope with 16bit devices too.
> base/gsovrc.c

2019-08-31 12:16:40 +0100
Robin Watts <Robin.Watts@artifex.com>
51dbfc90fdc681f4500b498cec52056fb0d2224b

> Fix deep color transparency overprint.
> The component copy loop at the end of the blend could fail to copy
> enough entries.
> base/gxblend.c

2019-08-30 15:16:34 +0100
Robin Watts <Robin.Watts@artifex.com>
1e48a71a99beb5870edadf0754e2c3bcf6a86f87

> Avoid overflow in deep color luminosity calculations.
> Resort to 64bit as scale calculations are not constrained
> to the usual 16bit range.
> base/gxblend.c

2019-08-29 10:02:49 +0100
Chris Liddell <chris.liddell@artifex.com>
59660b5d998b53df383192aee71b7439a424be47

> Fix clearing of the drag and drop file list
> Because we have to store the list of file names from drag and drop events, in
> order to correctly add and remove them from the permit file read list, we also
> want to clear the lists before we destroy the "text" window object.
> The problem is, this happens after we shutdown Ghostscript and unload the dll.
> This moves that clearing of the list into function that we call before we
> shut down.
> psi/dwmain.c
> psi/dwtext.c
> psi/dwtext.h

2019-08-28 10:14:52 +0100
Chris Liddell <chris.liddell@artifex.com>
94742723659fb4bba6b50ad29123d4ff38a9ebd6

> Fix path permissions added from cidfmap.
> From the cidfmap, we accumulate a list of unique directory paths a we process
> cidfmap and then add them - when I did that code, I forgot that to allow access
> to the directory, we need a trailing directory separator.
> Add that before calling .addcontrolpath
> Resource/Init/gs_cidfm.ps

2019-08-27 16:49:30 +0100
Chris Liddell <chris.liddell@artifex.com>
4135d3b50a66dc67eb7f4f4ad360fdf703783141

> Fix font file finding with -P
> In trying to reproduce the issue that inspired commit dea69cd04964, I noticed
> that font file searching wasn't working correctly with -P specified on the
> command line.
> Previously, it could just end up with us not finding a font we should have, but
> with dea69cd04964 it would result in a typecheck error.
> This ensures the stack is always how it should be after the findlibfile
> call
> Resource/Init/gs_fonts.ps

2019-08-22 16:10:03 +0100
Chris Liddell <chris.liddell@artifex.com>
2b9ab0d54ab2299b3db94e57f45cfc52f6045e62

> Make it clear: file/path matching is always case sensitive
> even on Windows.
> doc/Use.htm

2019-08-29 19:50:08 +0100
Robin Watts <Robin.Watts@artifex.com>
cc2cbb8c78acdff736a966eb40ca22a6a7c52b26

> Fix overflow in 16bit blending calculations.
> The blending code uses the following construction in
> several places:
> src_scale = ...; /* a value between 0 and 0x10000 */
> tmp = (y-z) * src_scale + 0x8000;
> foo = x + (tmp>>16);
> Where x,y,z, are all expected to be in the 0...0xffff range.
> Due to y-z having a sign bit, this can overflow a 32 bit tmp.
> We therefore sacrifice a bit of accuracy in src_scale to get
> correctness.
> base/gxblend.c
> base/gxblend1.c

2019-08-28 14:13:27 +0100
Robin Watts <Robin.Watts@artifex.com>
8c5059661a48e2e17d0f15c7c6936510192728b6

> Remove outdated FIXME's.
> base/gdevp14.c

2019-08-28 12:50:36 +0100
Robin Watts <Robin.Watts@artifex.com>
f531552c99a04f003412f7a83d4661e927f88d40

> Bug 701446: Avoid divide by zero in shading.
> The previous commit for this bug was enough to solve the problem
> for ppmraw, but not, it seems, for other devices. This addresses
> the division by zero more directly.
> base/gxshade6.c

2019-08-27 20:13:02 +0100
Robin Watts <Robin.Watts@artifex.com>
25f7cb4da347610dd49bd8001746605f1a29caa8

> Fix deep color transparency saturation blending.
> Problem seen with:
> tests_private/pdf/PDF_1.7_FTS/fts_25_2513.pdf.psdcmyk16.300.1
> base/gxblend.c

2019-08-27 17:45:57 +0100
Robin Watts <Robin.Watts@artifex.com>
b9e4b4e4d97a2f0c32596fed0342fb83773a56c2

> Bug 701446: Avoid division by zero in gx_shade_trapezoid
> Remove some incorrect clipping code.
> base/gxshade6.c

2019-08-27 15:54:36 +0100
Robin Watts <Robin.Watts@artifex.com>
0d46b4f51b5efba7e72b7d45517d0fba642477aa

> Exit early from gx_shade_trapezoid in more cases.
> A zero height trap isn't plotted, so we can bail out early in
> that case.
> base/gxshade6.c

2019-08-26 17:02:03 +0100
Robin Watts <Robin.Watts@artifex.com>
42f386a85d3998310f0317501b54780ffbe6dc6b

> Fix deep colour transparency "uncompositing".
> Uncompositing a group uses a scale factor that is greater in range
> than we'd like; we need to resort to 64bit to do this to avoid
> losing accuracy.
> This solves problems seen in:
> tests_private/comparefiles/Bug689918.pdf.psdcmyk16.300.1
> base/gxblend.c

2019-08-27 14:26:41 +0100
Chris Liddell <chris.liddell@artifex.com>
dea69cd04964b27a08c8b340476d58031cb9e517

> Handle relative FONTPATH values
> Prior to 9.21 (specifically: 8abd22010eb4db0fb1b10e430d5f5d83e015ef70), relative
> paths for FONTPATH worked, but did so due to a logic fault with how we search
> for "lib" files.
> When attempting to open file names specified on the command line, we used a
> flag set in the command line handling (starting_arg_file) to know whether the
> lib file searching logic should try to open the file name directly (as well as
> trying the file combined with each path in the search path).
> In versions prior to commit 8abd22010eb4 that flag (starting_arg_file) could
> remain set to true, even after the command line file(s) had been opened. This
> represented a (minor) security risk. Commit 8abd22010eb4 ensured the flag was
> properly (re)set, and that caused relative paths for FONTPATH stopped working.
> Rather than reintroduce the security risk, update the code that checks whether
> the font files exist so it explicitly tries the file name directly, rather than
> assuming .libfile (or findlibfile, in this case) does that automatically.
> Also remove an extraneous (but benign) dup of the font name.
> Resource/Init/gs_fonts.ps

2019-08-27 15:27:05 +0100
Ken Sharp <ken.sharp@artifex.com>
5d10fde23ccd74c2721e4870c5914fe7373a7816

> pdfwrite - fix corner case with Color Conversion
> Bug #701456 "Ghostscript creates broken PDF file after color conversion"
> The test file is, essentially weird. The image on page 3 is not a single
> image, its a series of images, all of which are in a /Indexed /DeviceRGB
> colour space.
> In addition, these images are drawn on *top* of another set of images
> (thereby completely obscuring them). These images are also drawn in
> /Indexed /DeviceRGB. However, these images are in fact monochrome, the
> Indexed space consists of 2 colours. This means that (highly unusually)
> we have a DeviceRGB image with 1 Bit Per Component.
> This caused problems for the pdfwrite compression filter chooser because
> it chose (and configured) a compression scheme suitable for 1 BPC data
> and then actually output 8 BPC data. This led to the compression filter
> writing too little data.
> Fix this here by setting the BPC to 8 if we are doing colour conversion,
> and have the colour conversion setup code use the original value in the
> image enumerator (the conversion code *does* need to know the input is
> 1 BPC).
> devices/vector/gdevpdfi.c

2019-08-27 11:36:35 +0100
Ken Sharp <ken.sharp@artifex.com>
02c252f00e7bbc9a9a23d0a0996e88ba1839f127

> PDF interpreter - more /Mask strangeness in Acrobat
> Bug #701468 " More weirdness with images containing invalid /Mask values"
> In order to render this file as per Acrobat, we need to ignore the /Mask
> array. However, in order to render bug 689717 correctly we need to fix
> the /Mask array.
> Both cases are 1 BitsPerComponent DeviceGray images, the only difference
> is the actual /Mask values. Bug 689717 has [255 255] while 701468 has
> [243 255]. We can differentiate based on whether we have DeviceGray
> 1 BPC image, where the Mask values are not the same. In the case they
> are different we use the existing technique of calculating the maximum
> value and using that (for both, so there is no range). Where there is a
> range (ie not a single colour) this is clearly unusable in a 2-colour
> image, so ignore the /Mask altogether.
> Resource/Init/pdf_draw.ps

2019-08-26 15:28:33 +0100
Robin Watts <Robin.Watts@artifex.com>
3554f0fc4dadebad2e816adbd7cf4a548f76de74

> Fix deep colour knockout logic.
> Problem seen with:
> tests_private/pdf/PDF_1.7_FTS/fts_25_2507.pdf.psdcmyk16.72.0
> base/gxblend.c

2019-08-26 14:34:46 +0100
Robin Watts <Robin.Watts@artifex.com>
5280581fd0c075da7dc0632937e294a9fa3fe736

> Squash a couple of warnings.
> base/gdevmem.c
> base/gdevp14.c

2019-08-26 14:01:39 +0100
Robin Watts <Robin.Watts@artifex.com>
2e872508d683302b556a160004a9ca3d64e7b4f1

> Fix SoftLight blending in deep color transparency.
> As seen with:
> gs -sDEVICE=psdcmyk16 -r72 -dMaxBitmap=80000000 -o out.psd
> tests_private/pdf/PDF_1.7_FTS/fts_09_0919.pdf
> base/gxblend.c

2019-08-26 11:28:40 +0100
Robin Watts <Robin.Watts@artifex.com>
1fe43c3ba4423631129925d789c936b9e461d1d6

> Fix problems with pngalpha and deep color transparency filling.
> The pngalpha device is created with a depth of 32, with 3 color
> components; this was confusing pdf14 into thinking that more
> than 8 bits per color were being used, and so deep color buffers
> were required.
> To fix this we update the logic to be smarter; in cases where we
> don't have a clear determination based on bits alone, we look
> at the max_color and max_gray values. Because this code is now
> more complex than before, we pull it into a shared function.
> base/gdevdflt.c
> base/gdevmem.c
> base/gdevp14.c
> base/gdevprn.c
> base/gsptype1.c
> base/gstrans.c
> base/gxclthrd.c
> base/gxdevcli.h

2019-08-23 15:06:17 +0100
Robin Watts <Robin.Watts@artifex.com>
0ac36b1eb87a919d3df19b7fb555d277d959396b

> Fix deep color transparency issue.
> Fix overflow in art_pdf_composite_knockout_16, seen in:
> tests_private/comparefiles/Bug690546.pdf.psdcmyk16.72.0
> base/gdevp14.c
> base/gxblend.c

2019-08-22 18:24:49 +0100
Robin Watts <Robin.Watts@artifex.com>
cda2b1e057951dc4687c4d2ad489100d1ea6ea4b

> Fix deep color transparent pattern problems.
> Transparency buffers are held as native endian. Pattern cache
> tiles are held as big endian. When we make pattern cache tiles
> from transparency buffers we therefore need a conversion.
> base/gdevp14.c
> base/gxblend.c
> base/gxp1fill.c
> base/gxpcolor.h

2019-08-25 19:35:14 +0200
Till Kamppeter <till.kamppeter@gmail.com>
4e220de447dc5cc79a00e8bb57b69c6ea242fe75

> "cups"/"pwgraster" output device: Do not output LUTs with CUPS_DEBUG set
> This change lets complete LUTs in the debug output only be listed when
> CUPS_DEBUG2 is set and not already with CUPS_DEBUG.
> cups/gdevcups.c

2019-08-25 19:08:52 +0200
Till Kamppeter <till.kamppeter@gmail.com>
30575d50af5f8dd17ef20ccbbf2b2d8afae51589

> "cups"/"pwgraster" output device: Prefer the page size requested by user
> Without special scaling/cropping options ("fit-to-page", "fill",
> "crop-to-fit΅, ...) PDF and PostScript files printed with CUPS will be
> printed with the page sizes of the document's pages and not the size
> requested by the user via the "PageSize" or "media" option. This
> allows correct printing of jobs with differently sized pages on
> printers which have the appropriate sizes loaded without need of
> manual intervention. Therefore the CUPS output device is matching each
> input page against the sizes listed in the PPD to generate a correct
> page geometry for the printer for each page.
> Problem is if there are several equally-sized page size entries in the
> PPD. Without further guiding always the first match is used, making
> access to special functions provided by the others (like
> full-bleed/borderless printing) inaccessible.
> This commit adds the functionality of the user-requested page size
> (via "PageSize" or "media" option) being preferred under the matching
> page sizes, so that if for example a user selects a full-bleed version
> of the desired page size and sends a photo, the photo gets rendered
> and printed with the page geometry which the PPD reports for the
> full-bleed version.
> Nothing changes if the size of the user-requested page size does not
> match the size of the input page at all.
> cups/gdevcups.c

2019-08-25 12:45:27 +0200
Till Kamppeter <till.kamppeter@gmail.com>
3283e6d5ce389f5b6d5ebf4adb309b1259a5fe1d

> "cups"/"pwgraster" output device: Small fix on size matching improvements
> This is a fix for one little oversight on the changes to support matching
> the input page size against the imageable areas of the PPD's page sizes.
> This completes the fix of bug 701438.
> cups/gdevcups.c

2019-08-24 23:11:10 +0200
Till Kamppeter <till.kamppeter@gmail.com>
3e09cede82a3b8c5c7a6e30a5934336f20dfa1f8

> "cups"/"pwgraster" output device: Improved page size matching with PPD
> Applied the following improvements for finding the correct page size
> of the PPD file for the input page:
> - Do not try to match by page size name, the input files do not
> contain page size names.
> - Do not only match the input page size against the actual media sizes
> reported by the PPD but also to the imageable areas. Media size match
> is preferred but if there is no media size match, we accept also
> a match of the imageable area. In case of a match of the imageable
> area we position the input page in the imageable area of the output
> page.
> - More debug output.
> - In case of a custom page size (no match with PPD sizes) the page
> size name in the CUPS Raster output is a correct "Custom.XXXxYYY"
> and not the default page size name.
> This should fix bug #701438.
> cups/gdevcups.c

2019-08-23 18:09:32 +0200
Till Kamppeter <till.kamppeter@gmail.com>
2d6bb6e69feb0a75be98d03f550258d4b7540aef

> "cups"/"pwgraster" output device: Reduced page size comparison tolerances
> Before each page gets rendered its size is compared to the page sizes
> of the PPD file to select the actual page size for the output. Reduced
> the tolerances from 7% for the long edge and 5% for the short edge to
> 1%, as before easily wrong sizes got picked (See also bug 701438).
> cups/gdevcups.c

2019-08-23 10:11:05 +0100
Chris Liddell <chris.liddell@artifex.com>
5ab40cc018d8ac76758cebc7b4962e9b19fffc86

> Windows Installer: cope with COMPILE_INITS=0
> We default to COMPILE_INITS=1, and that was the only case that the installer
> handled - i.e. building the installer with COMPILE_INITS=0 would install an
> executable that wouldn't work without extra action (-I.. or similar).
> This changes the installer compiler invocation, and the installer creation
> so it behaves as it does now with COMPILE_INITS=1, but with COMPILE_INITS=0 the
> installer will write the path to Resource/Init into the GS_LIB registry
> key.
> psi/nsisinst.nsi
> psi/winint.mak

2019-08-22 23:30:34 +0200
Till Kamppeter <till.kamppeter@gmail.com>
863d77f731c6144dcf139e06e64a857754d8327f

> "cups"/"pwgraster" output device: Produce more debug output
> When building with CUPS_DEBUG now debug output for the process of
> matching the page geometry with the PPD file's page sizes is
> produced.
> cups/gdevcups.c

2019-08-22 08:58:01 +0100
Chris Liddell <chris.liddell@artifex.com>
24478335925f891673160893513fac43b0334c48

> Handle explicit '\' escaping in path matching
> As well as having to cope with both '/' and '\' as directory separators on
> Windows, it turns out we also need to cope with the backslash separator being
> explicitly escaped ("\\") - the explicit is added by the Postcript path
> templating code in gs_init.ps.
> I don't want to change templating code because that would likely have
> implications in a lot of other places.
> base/gpmisc.c

2019-08-22 10:51:28 +0100
Robin Watts <Robin.Watts@artifex.com>
7c9794ee644a904527006922e4fc387ad33be2a4

> Better CMYK conversion for bmpcmp
> toolbin/bmpcmp.c
> toolbin/bmpcmptab.h

2019-08-21 17:49:32 +0100
Robin Watts <Robin.Watts@artifex.com>
079ea7d9e0c713a7834fc8f08d52ce42e6a03666

> Update bmpcmp.c to read psdrgb rather than psdbgr.
> toolbin/bmpcmp.c

2019-08-21 15:33:27 +0100
Chris Liddell <chris.liddell@artifex.com>
935408d6205742e40471b18d7f0f1fe4febc437c

> Fix commit ec0b35fed3de: "Handle directory separators..."
> The logic in the above fix was wrong.
> base/gpmisc.c

2019-08-21 14:28:20 +0100
Robin Watts <Robin.Watts@artifex.com>
4041906852365a602c2f9e011703e4174bdc8040

> Bug 701451: Fix clist color_usage calculations for shadings.
> Or rather, don't attempt to calculate them badly, and just
> use the safe "all colors" value.
> base/gxclrect.c

2019-08-21 10:10:51 +0100
Ken Sharp <ken.sharp@artifex.com>
cd1b1cacadac2479e291efe611979bdc1b3bdb19

> PDF interpreter - review .forceput security
> Bug #701450 "Safer Mode Bypass by .forceput Exposure in .pdfexectoken"
> By abusing the error handler it was possible to get the PDFDEBUG portion
> of .pdfexectoken, which uses .forceput left readable.
> Add an executeonly appropriately to make sure that clause isn't readable
> no mstter what.
> Review all the uses of .forceput searching for similar cases, add
> executeonly as required to secure those. All cases in the PostScript
> support files seem to be covered already.
> Resource/Init/pdf_base.ps
> Resource/Init/pdf_draw.ps
> Resource/Init/pdf_font.ps
> Resource/Init/pdf_main.ps
> Resource/Init/pdf_ops.ps

2019-08-21 10:56:02 +0100
Chris Liddell <chris.liddell@artifex.com>
ec0b35fed3de9f313c7c992844daac5f3f28618d

> Handle directory separators in access control matching
> On Windows, we end up dealing with a mishmash of "/" and "\" as directory
> separators, so a simple equality check isn't sufficient.
> Since there is already (platform specific) function for checking whether a
> string (or part thereof) is a directory separation, use it.
> base/gpmisc.c

2019-08-20 21:50:18 -0700
Michael Vrhel <michael.vrhel@artifex.com>
453ef45209143ecf3c3e25dafd9fbe6698e2c5a1

> Disable use of alternate tint transform ICC profile
> A prior commit introduced the use of color management
> if the DeviceN or Separation device had an ICC profile
> associated with the colorants. While there is an argument
> for doing this, it is not the standard behavior seen in
> AR. Disabling for now and will likely turn this into a
> command line option.
> base/gxcmap.c

2019-08-20 18:48:49 +0100
Robin Watts <Robin.Watts@artifex.com>
cc656558a289fa28dbb491d70478fd18973b287a

> Fix crashes in RAW_DUMP debug code.
> Dump the buffer before freeing the device, or the pointer will no
> longer be valid.
> Also, don't access through ppatdev14 when we know it's NULL.
> base/gdevp14.c

2019-08-20 18:47:09 +0100
Robin Watts <Robin.Watts@artifex.com>
633c454261c95e3d1771ad93b7bd6c481119c0d0

> Fix deep color transparency pattern copying problem.
> The following test:
> tests/pdf/pattrans_solid_nonrect.pdf.psdcmyk16.300.1..gs
> among others, was showing problems, due to us treating the offset
> as bytes rather than shorts.
> base/gxp1fill.c

2019-08-20 14:29:33 +0100
Robin Watts <Robin.Watts@artifex.com>
69b066540069330a8a046039b93e1dcadecfa153

> Avoid signed overflow in deep transparency calculations.
> base/gxblend.c

2019-08-20 12:24:03 +0100
Robin Watts <Robin.Watts@artifex.com>
825f77eabdbfaa9d566d38c4b2be918143cd5778

> Fix overflow in deep color blending.
> Multiplying a 16bit unsigned value with a 16 bit signed value
> in a 32bit int means we lose the sign bit. Sacrifice a bit of
> accuracy to avoid that.
> base/gxblend.c

2019-08-20 10:10:28 +0100
Ken Sharp <ken.sharp@artifex.com>
885444fcbe10dc42787ecb76686c8ee4dd33bf33

> make .forceput inaccessible
> Bug #701343, #701344, #701345
> More defensive programming. We don't want people to access .forecput
> even though it is no longer sufficient to bypass SAFER. The exploit
> in #701343 didn't work anyway because of earlier work to stop the error
> handler being used, but nevertheless, prevent access to .forceput from
> .setuserparams2.
> Resource/Init/gs_lev2.ps
> Resource/Init/gs_pdfwr.ps

2019-08-19 10:03:57 +0100
Chris Liddell <chris.liddell@artifex.com>
9dae3b271e781c076e49d94dc8590ed95e3f38c9

> Handle drag'n'drop file name/paths
> Because we now run by default with the file access permission active,
> we need to do additional work for Windows drag and drop files, so they don't
> throw an invalidaccess error (since we implement drag and drop by sending
> characters to the gs console to do '(file) run').
> The problem is, we cannot add the file to read list, send the characters to the
> console, and remove the file from the read list because, although SendMessage()
> blocks until the message is handles, WriteConsoleInput() does not block until
> the console buffers are consumed (i.e. it is asynchronous). So, there is no
> certainty when the final SendMessage() in WM_DROPFILES case is finished that
> Ghostcript will actually have run the file.
> So, we create a list of dropped file names, add them to the permit read list,
> when the next WM_DROPFILES event happens, or a WM_DESTROY event, we drop
> file names from the permit read list before, if necessary, adding the current
> ones.
> psi/dwimg.c
> psi/dwmain.c
> psi/dwmainc.c
> psi/dwtext.c
> psi/dwtext.h

2019-08-16 15:43:32 +0100
Robin Watts <Robin.Watts@artifex.com>
6c18c7092e8945dcd932226bfea790c842ae21a0

> Squash warnings in claptrap.
> Thanks to William Bader for highlighting these.
> base/claptrap-planar.c

2019-08-16 15:28:49 +0100
Robin Watts <Robin.Watts@artifex.com>
89f63112bd8ef15ba7df1fca5b962561c1f756c8

> Squash warning in gdevpsd.c
> Thanks to William Bader for spotting this.
> devices/gdevpsd.c

2019-08-16 13:08:14 +0100
Robin Watts <Robin.Watts@artifex.com>
f74553992b28ca536d62aa93cf9208bb7aa670b3

> Squash some compiler warnings.
> base/gslibctx.c
> base/gslibctx.h
> devices/gdevpdfimg.c
> devices/vector/gdevpdfu.c
> pcl/pl/plmain.c

2019-08-16 11:45:01 +0100
Chris Liddell <chris.liddell@artifex.com>
924f701fdc990ac981fb08c4f6c21c668b8b74ef

> Fix X11 device ICC profile memory leaks
> When the x11 devices are running in "buffered mode" (i.e. we render to a
> pixmap, then blit the pixmap to the X11 Window), we create a memory device
> which actually does the rendering.
> The memory device takes a reference to the ICC profiles from the x11 device
> and it is reference counted.
> Firstly, we always incremented the reference count, ignoring the posibility
> that we were resizing an existing memory device rather than creating a new one.
> Secondly, when shutting down the x11 device, we ignored posibility that
> buffering was in force, and failed to free the memory device - most of the
> memory was hoovered up by the garbager, but the ICC profile data isn't in
> gc memory, hence showing a leak.
> So, fix the memory device ICC reference counting, and reconfigure the device
> as non-buffering before we shut it down.
> devices/gdevxini.c

2019-08-15 17:06:02 +0100
Chris Liddell <chris.liddell@artifex.com>
79350a5f0fc9514746f34ff0820f0b6a89f67117

> Add -dNOSAFER for Windows installer cidfmap creation
> psi/nsisinst.nsi

2019-08-15 11:35:15 +0100
Chris Liddell <chris.liddell@artifex.com>
443e60cd379c3a8b5fca89b59280573b2c651e33

> Bump the version number for release.
> Resource/Init/gs_init.ps
> base/version.mak

2019-08-15 14:36:55 +0100
Ken Sharp <ken.sharp@artifex.com>
f1ae75eb9d43d9773915ab66b0c97086d0252257

> ps2write - don't password encrypt PostScript output!
> Noticed while testing the args commit; if we set -sOwnerPassword (to
> create a password-protected PDF file), but select (e)ps2write as the
> device, then the resulting PostScript file would have all the streams
> (in a PDF sense) encrypted with PDF password encryption.
> Unsurprisingly, this result in a completely unusable PostScript file.
> Lets not permit that....
> devices/vector/gdevpdfp.c

2019-10-15 10:03:54 +0100
Chris Liddell <chris.liddell@artifex.com>
d2897b976cf065874516f9f8e2a040965b2a384b

> Remove RC string for real release
> base/gscdefs.h

2019-10-15 08:54:21 +0100
Chris Liddell <chris.liddell@artifex.com>
18eedc30986ed2dfaf2357c0b0ca962532ace896

> Dates etc for 9.50 release
> Plus a comment on going to 9.50, rather than 9.28.
> base/version.mak
> doc/DLL.htm
> doc/Deprecated.htm
> doc/Develop.htm
> doc/Devices.htm
> doc/Drivers.htm
> doc/Fonts.htm
> doc/History9.htm
> doc/Install.htm
> doc/Internal.htm
> doc/Language.htm
> doc/Lib.htm
> doc/Make.htm
> doc/News.htm
> doc/Ps-style.htm
> doc/Ps2epsi.htm
> doc/Psfiles.htm
> doc/Readme.htm
> doc/Release.htm
> doc/SavedPages.htm
> doc/Source.htm
> doc/Unix-lpr.htm
> doc/Use.htm
> doc/VectorDevices.htm
> doc/WhatIsGS.htm
> doc/gs-vms.hlp
> doc/sample_downscale_device.htm
> doc/subclass.htm
> doc/thirdparty.htm
> man/dvipdf.1
> man/gs.1
> man/gslp.1
> man/gsnd.1
> man/pdf2dsc.1
> man/pdf2ps.1
> man/pf2afm.1
> man/pfbtopfa.1
> man/printafm.1
> man/ps2ascii.1
> man/ps2epsi.1
> man/ps2pdf.1
> man/ps2pdfwr.1
> man/ps2ps.1

2019-10-15 08:48:43 +0100
Chris Liddell <chris.liddell@artifex.com>
80f8dff6c57620dd5acae9ebc5b9ab64674b88f0

> Fix a mistake in the news section
> doc/History9.htm
> doc/News.htm

2019-10-14 18:29:10 +0100
Chris Liddell <chris.liddell@artifex.com>
24a66f42d67d83714ad971347488c0246e3e8f7c

> Have warning honor -dQUIET
> Have the warning about calling .lockfileaccess or .setsafe when the controls are
> already in place honor the -dQUIET/-q command line params.
> Resource/Init/gs_init.ps

2019-10-14 18:10:31 +0100
Chris Liddell <chris.liddell@artifex.com>
dad10464de52d344287843ca872b56c8e7f33ccb

> Update changelog
> doc/History9.htm

2019-10-14 18:07:29 +0100
Chris Liddell <chris.liddell@artifex.com>
f2e2a3fe85d64cabde82d0f6eb982643bc6e8427

> Add words about .currentpathcontrolstate operator
> doc/Language.htm

2019-10-14 10:28:15 +0100
Chris Liddell <chris.liddell@artifex.com>
ad5b08d8be2e7a91599d3bbbc6aa841144662239

> Change version to 9.50
> Resource/Init/gs_init.ps
> base/version.mak
> doc/DLL.htm
> doc/Deprecated.htm
> doc/Develop.htm
> doc/Devices.htm
> doc/Drivers.htm
> doc/Fonts.htm
> doc/History9.htm
> doc/Install.htm
> doc/Internal.htm
> doc/Language.htm
> doc/Lib.htm
> doc/Make.htm
> doc/News.htm
> doc/Ps-style.htm
> doc/Ps2epsi.htm
> doc/Psfiles.htm
> doc/Readme.htm
> doc/Release.htm
> doc/SavedPages.htm
> doc/Source.htm
> doc/Unix-lpr.htm
> doc/Use.htm
> doc/VectorDevices.htm
> doc/WhatIsGS.htm
> doc/gs-vms.hlp
> doc/sample_downscale_device.htm
> doc/subclass.htm
> doc/thirdparty.htm
> man/dvipdf.1
> man/gs.1
> man/gslp.1
> man/gsnd.1
> man/pdf2dsc.1
> man/pdf2ps.1
> man/pf2afm.1
> man/pfbtopfa.1
> man/printafm.1
> man/ps2ascii.1
> man/ps2epsi.1
> man/ps2pdf.1
> man/ps2pdfwr.1
> man/ps2ps.1

2019-10-14 10:20:19 +0100
Chris Liddell <chris.liddell@artifex.com>
1937e14f17e5de54b57d0e911e828639d197a08c

> Update docs on SAFER
> to reflect that SAFER is now the default, and remove the comments about making
> SAFER the default "in the future".
> doc/Use.htm

2019-10-10 09:29:48 +0100
Ken Sharp <ken.sharp@artifex.com>
9c63f39ead4aab30addf213f0ab6843ac87b56cf

> ps2write - restore missing %%PageTrailer comment
> Bug #701659 "Missing %%PageTrailer commen"
> An oversight in commit 96c381cce28c27eac182549441a6c5025b0dcdd6
> caused the comment to be omitted.
> devices/vector/gdevpdf.c

2019-10-07 18:41:10 +0100
Chris Liddell <chris.liddell@artifex.com>
1d89e1aa9cf65e5345a1f009b6d317db024719fe

> Bug 701657: Allocate "memory" device in immovable gc memory
> Devices are supposed to be allocated in memory that cannot relocate (i.e.
> non-gc memory or an immovable allocation). The memory device accessible from
> Postscript (makeimagedevice/makewordimagedevice) was being created in regular,
> relocatable gc memory.
> This caused an invalid memory access when cleaning up subclassed devices, as the
> one device in the chain may have moved. So switch to using an immovable
> allocation.
> base/gsdevmem.c

2019-10-02 00:01:17 +0200
Sebastian Rasmussen <sebras@gmail.com>
458f715b0d59278f0788e0c89ee5eb04d48871ef

> Update jbig2dec stuff for 0.17 release.
> jbig2dec/CHANGES

2019-10-01 10:35:48 +0100
Chris Liddell <chris.liddell@artifex.com>
f8ba9e017cdfab836f62853629d75f484127342e

> Fix memory corruption setting a halftone
> When setting a new halftone in the graphics state, we try to re-use the data
> from the existing device halftone.
> The problem is that the device halftone can have higher component indices than
> there are components in the new halftone we are creating. In this case, we can
> end up writing off the end of the components array for the new halftone
> structure.
> Simply check that the new halftone has enough components before doing the
> duplication.
> base/gsht.c

2019-09-30 13:40:35 +0100
Ken Sharp <ken.sharp@artifex.com>
1681c7ebb5a338002d5f7dd8da9bffda675f0656

> pdfwrite - don't honour /Producer key in DOCINFO pdfmark
> Bug #701639 "pdfwrite should not honour the /Producer key in DOCINFO pdfmark"
> The Producer in the document information dictionary (and XML Metadata)
> is defined quite clearly as the application which produced the PDF file
> from its native format.
> Ghostscript uses the Producer key (if present in the pdfmark) to set
> the Producer, but it should not do so. Adobe Acrobat Distiller (at
> least the end user version) does not permit this value to be altered.
> On reflection we can see why; in the case of a problem with a PDF file
> its important to know which application created it, and we should not
> let PostScript obscure that (we already do not pass the Producer
> information on when the input is PDF).
> The code did already attempt to overwrite any Producer string which
> contained 'Distiller' (I have no idea why) and that code contained an
> error which could lead to an invalid Document Information dictionary
> being created.
> This commit removes the ability for DOCINFO pdfmarks to alter the
> Producer, which obviously fixes the bug.
> However..... it is actually important for our commercial customers to
> be able to set this value. A problem with a PDF file created by one of
> our customer's products should be reported to that customer, not us, as
> we will not be able to investigate the problem while our customer
> should be able to. At the very least our customer will know how to
> retrieve the configuration of Ghostscript being used.
> So permit the commercial version of Ghostscript to set the /Producer
> from a pdfmark.
> devices/vector/gdevpdfm.c

2019-09-30 09:16:28 +0100
Chris Liddell <chris.liddell@artifex.com>
a27af00c8727ec4eaf0f4730963b8a81aab8590d

> Small changelog tweak
> doc/History9.htm

2019-09-30 08:33:08 +0100
Chris Liddell <chris.liddell@artifex.com>
84864d86363a3e5b53f4b75fae7c850c2c22e5ee

> Dates and docs for 9.28 rc4
> base/gscdefs.h
> base/version.mak
> doc/DLL.htm
> doc/Deprecated.htm
> doc/Develop.htm
> doc/Devices.htm
> doc/Drivers.htm
> doc/Fonts.htm
> doc/History9.htm
> doc/Install.htm
> doc/Internal.htm
> doc/Language.htm
> doc/Lib.htm
> doc/Make.htm
> doc/News.htm
> doc/Ps-style.htm
> doc/Ps2epsi.htm
> doc/Psfiles.htm
> doc/Readme.htm
> doc/Release.htm
> doc/SavedPages.htm
> doc/Source.htm
> doc/Unix-lpr.htm
> doc/Use.htm
> doc/VectorDevices.htm
> doc/WhatIsGS.htm
> doc/gs-vms.hlp
> doc/sample_downscale_device.htm
> doc/subclass.htm
> doc/thirdparty.htm
> man/dvipdf.1
> man/gs.1
> man/gslp.1
> man/gsnd.1
> man/pdf2dsc.1
> man/pdf2ps.1
> man/pf2afm.1
> man/pfbtopfa.1
> man/printafm.1
> man/ps2ascii.1
> man/ps2epsi.1
> man/ps2pdf.1
> man/ps2pdfwr.1
> man/ps2ps.1

2019-09-27 13:26:01 +0100
Chris Liddell <chris.liddell@artifex.com>
55fef678a69b921b548d5e1ffb93d9162fedfdc3

> Bug 701634: Correctly handle file name of "\0"
> Attempting to open a file with a filename string starting with a NULL
> character should be treated the same as if the string was zero length.
> Not doing so created a broken file object leading to several operations
> resulting in a segfault.
> Also, add cleanup in the event of such an error, freeing memory allocated in
> preparing the gs stream object.
> base/sfxcommon.c
> psi/zfile.c

2019-09-26 10:47:01 +0100
Chris Liddell <chris.liddell@artifex.com>
51e6a6103f9fa51e14c737e134bcef8a3daf7ef8

> Revised comment for 8992f00edfd1c39154c013489de2a01d2e9a92ee
> Make it clearer why the revised behaviour is required.
> base/gstiffio.c

2019-09-26 09:34:02 +0100
Chris Liddell <chris.liddell@artifex.com>
833fc0371d2ca44ca603b2fd1a42fa1ef820f7eb

> Bug 701313: Disable libtiff callbacks when libtiff is shared
> It seems that libtiff uses global variables to store the error/warning callbacks
> so if two callers in the exe are using the libtiff shared lib, very bad things
> happen (usually a segfault).
> So, if that's how we're linked, set the callbacks to NULL.
> base/gstiffio.c

2019-09-24 15:48:54 +0100
Chris Liddell <chris.liddell@artifex.com>
cfd109650c2328300b21f7e5853c0e4bec669876

> Cope with .setsafe(global) being called when already 'SAFER'
> As we default to SAFER file controls now, we want to cope with .setsafe and
> .setsafeglobal being called either when already SAFER, or called multiple times.
> This means adding a .currentpathcontrolstate operator so we don't try to
> influence the path control lists after control is activated.
> Resource/Init/gs_init.ps
> psi/zfile.c

2019-09-24 09:18:47 +0100
Chris Liddell <chris.liddell@artifex.com>
45013b96f1e7ef06c64028122ec8870f3a71335d

> tiffsep(1): Cope with .tiff ending as well as .tif
> devices/gdevtsep.c

2019-09-23 20:04:49 +0100
Robin Watts <Robin.Watts@artifex.com>
6aea104cc48170a4064a12e89c72a898c6bd5967

> Recast validate to use gs_file_name_check_separator.
> Avoid using gp_file_name_directory_separator, as windows can
> have 2 different directory separators.
> base/gpmisc.c

2019-09-23 18:05:00 +0100
Chris Liddell <chris.liddell@artifex.com>
f1a661c69f78ea42828f94fe829163d20bcf7706

> Remove spurious call to gp_validate_path_len()...
> ...in gx_device_open_output_file()
> There is no need to validate the path in gx_device_open_output_file() as it will
> be done at a lower level (gp_fopen) for paths that require it (we only validate
> *after* the Postscript style %device% paths have been expanded into 'real'
> paths).
> This also interacts badly with the revised handling of formatted string
> file names, hence remove it.
> base/gsdevice.c

2019-09-23 17:56:34 +0100
Chris Liddell <chris.liddell@artifex.com>
eed7d85ac16ae516e1c4e51bcdea3924a973da5e

> Fix tiffsep(1) interaction with file permissions lists
> The previous solution didn't quite work, when using formatted strings for
> output file names (i.e. output-%d.tif).
> This adds a dedicated gs_remove_outputfile_control_path() to mirror
> gs_add_outputfile_control_path() and uses those for the dynamic adding and
> removing of separation output file names.
> base/gslibctx.c
> base/gslibctx.h
> devices/gdevtsep.c

2019-09-23 17:11:47 +0100
Robin Watts <Robin.Watts@artifex.com>
76ca3dd29559dd72da3f154e2ba18f86cd46fff6

> Update path validation to accept multiple *'s as special case.
> Previously we interpretted multiple *'s as meaning the same as
> single *'s. Now we use them to mean "just those chars that
> might be created by the use of a %...{d,x,u,i,o,X} format
> specifier".
> base/gpmisc.c
> doc/Use.htm

2019-09-23 16:41:09 +0100
Robin Watts <Robin.Watts@artifex.com>
dfc93423545c8a9a927b1f240ba4bdc22b39f0b6

> Improve OutputFile handling of %d etc.
> Only accept %d (and friends) (as opposed to anything starting with %).
> Only accept legal combinations of flags/widths/precision etc.
> Generate a more conservative wildcard.
> base/gslibctx.c

2019-09-20 12:38:02 -0700
Ray Johnston <ray.johnston@artifex.com>
cd3db03d3e04c9146b596280d6da76cec23f60a6

> Slight improvement to "permit-file-***" parameter documentation.
> doc/Use.htm

2019-09-20 11:17:53 -0700
Ray Johnston <ray.johnston@artifex.com>
4baa696cc3498ae834052440f9f9d9fc0b8ad122

> Fix tiffsep and tiffsep1 with new file access control and SAFER mode
> The tiffsep and tiffsep1 synthesize output file names with the outputfile
> and the separation color name, but the 'open' of these filenames would
> fail since they were not included on the permit_file_writing list.
> Add the full filename before opening, and remove the names after closing.
> devices/gdevtsep.c

2019-09-20 11:53:10 -0700
Robin Watts <Robin.Watts@artifex.com>
41d79063acee7244f5990d2a8e19c567e24051af

> Squash stupid const warning.
> base/gslibctx.c

2019-09-20 19:42:01 +0100
Robin Watts <Robin.Watts@artifex.com>
b58f45daa9007f482a49132cbfaa47c8b86ce7d5

> Squash some "const" warnings.
> pcl/pl/plmain.c

2019-09-20 17:49:57 +0100
Robin Watts <Robin.Watts@artifex.com>
0e7039d7a83a7e35b8b41d59d7fb9a8b4fda7fb0

> Fix "permit-file-xxxx" handling.
> Ray spotted that gs_add_explicit_control_path was adding 17
> to arg before using it. 17 happens to be the right amount
> to add for "--permit-file-read=", but the wrong amount for
> write/control/all.
> Update the code to call it with the correct arg pointer
> to start with.
> Also, update a couple of routines to cope with being called
> with NULL strings.
> Also use enum values in switch rather than 0, 1, 2.
> base/gslibctx.c
> pcl/pl/plmain.c
> psi/imainarg.c

2019-09-19 11:02:48 +0100
Chris Liddell <chris.liddell@artifex.com>
18316aba11fafc57ee77dbd7774b2c88b964a9d9

> Make missing jbig2 decoder fatal error.
> If we have neither Luratech nor jbig2dec, have configure fail, unless
> explicitly run with --without-jbig2dec
> configure.ac

2019-09-18 09:24:25 +0100
Chris Liddell <chris.liddell@artifex.com>
569a551f2a57f6e6c1e692f6b834c765dcbe7cfa

> Dates, docs, etc for 9.28 rc3
> base/gscdefs.h
> base/version.mak
> doc/DLL.htm
> doc/Deprecated.htm
> doc/Develop.htm
> doc/Devices.htm
> doc/Drivers.htm
> doc/Fonts.htm
> doc/History9.htm
> doc/Install.htm
> doc/Internal.htm
> doc/Language.htm
> doc/Lib.htm
> doc/Make.htm
> doc/News.htm
> doc/Ps-style.htm
> doc/Ps2epsi.htm
> doc/Psfiles.htm
> doc/Readme.htm
> doc/Release.htm
> doc/SavedPages.htm
> doc/Source.htm
> doc/Unix-lpr.htm
> doc/Use.htm
> doc/VectorDevices.htm
> doc/WhatIsGS.htm
> doc/gs-vms.hlp
> doc/sample_downscale_device.htm
> doc/subclass.htm
> doc/thirdparty.htm
> man/dvipdf.1
> man/gs.1
> man/gslp.1
> man/gsnd.1
> man/pdf2dsc.1
> man/pdf2ps.1
> man/pf2afm.1
> man/pfbtopfa.1
> man/printafm.1
> man/ps2ascii.1
> man/ps2epsi.1
> man/ps2pdf.1
> man/ps2pdfwr.1
> man/ps2ps.1

2019-09-17 11:42:13 +0100
Chris Liddell <chris.liddell@artifex.com>
2ff44c7c8a09dd1c6b7cd750323ee4087b5cebc5

> Fix file permissions interaction with '@' command line
> If an options file (prefixed '@' on the command line) followed something that
> required initialising the Postscript interpreter (such as a '-c' option),
> opening the file would potentially fail because file permissions had been
> activated by the interpreter.
> Add and remove the file from the permit reading list before attempting to open
> it.
> base/gsargs.c

2019-09-12 14:23:10 +0100
Chris Liddell <chris.liddell@artifex.com>
3695b7f576c607bd3627e6e28dc982fdf68b1b32

> If set, add PCLFONTSOURCE value to permit_file_reading list
> pcl/pl/pjparse.c

2019-09-11 13:07:02 +0100
Chris Liddell <chris.liddell@artifex.com>
4196e26a9cf3c8afd6c069a789ac649019ae096a

> Bug 701561: 'reduce' paths before adding to permit lists
> Before attempting to open files, we pre-process the requested file name to
> remove surplus/unnecessary elements: i.e. './././file' would be reduced to just
> './file', or '../dir/../dir/../dir/file' would be reduced to '../dir/file'.
> The 'reduced' path is what we try to open, hence it is also what we check
> against the file permissions list before we allow files to be accessed.
> That being so, we should also 'reduce' paths as we add them to the permissions
> lists - thus the permissions list creation and checking are consistent.
> base/gslibctx.c
> base/lib.mak

2019-09-11 14:10:27 -0700
Ray Johnston <ray.johnston@artifex.com>
3d55799ea64088e08fc2783012957035c77a66ca

> Fix Bug 696333. Allow large bitmaps in clist when writing tile cache.
> When writing bits to update the tile cache, we don't need to restrict to
> a single command buffer as with the copy_mono and copy_color commands.
> Progressions on:
> tests_private/comparefiles/Bug694385.pdf.psdcmyk.300.1..gs
> tests_private/pdf/sumatra/2028_-_invisible_patterns.pdf.psdcmyk.300.1..gs
> tests_private/ps/ps3cet/09-47B.PS.pdf.pkmraw.300.0..gs_pdf
> tests_private/ps/ps3fts/176-01.ps.psdcmyk.300.1..gs
> base/gxclbits.c
> base/gxcldev.h
> base/gxclrect.c

2019-09-12 10:37:42 -0700
Ray Johnston <ray.johnston@artifex.com>
1613502f83ddba352cc8e98e7dd3182c9d7732bc

> Fix SEGV with flp device and PCL with clist mode and large BandHeight.
> If the 'clist_init' fails initially (with rangecheck) due to the buffer
> space too small for the BandHeight specified, we loop in the caller after
> increasing the buffer size, but clist_init left "is_open" false when failing.
> Add save_is_open in gdev_prn_setup_as_command_list so that we can restore it
> if the clist_init eventually suceeds.
> The SEGV was with image_data because re-opening the flp device reset the
> "obsolete" procs to the default, so flp_image_data was replaced by the
> gx_default_image_data, but no begin_image had been performed (flp_begin_image
> skipped this since we were not yet at the FirstPage).
> base/gdevprn.c
> base/gxclist.c

2019-09-16 18:53:49 +0200
Sebastian Rasmussen <sebras@gmail.com>
f2d03f59e04a053c14285d8dbdd869bf9a4435e7

> Update jbig2dec stuff for 0.17 release.
> jbig2dec/CHANGES
> jbig2dec/jbig2.h
> jbig2dec/jbig2dec.1

2019-09-16 18:48:36 +0200
Sebastian Rasmussen <sebras@gmail.com>
8da8fbaeb6074161bc3a9b22e89265f5942db0d9

> jbig2dec: Use the same contact information everywhere.
> jbig2dec/README
> jbig2dec/configure.ac.in
> jbig2dec/jbig2dec.1

2019-09-16 16:12:32 +0100
Paul Vojta <vojta@math.berkely.edu>
6c6e19334062d12189612b84f53fe393a7808f74

> Documentation - fix some typos
> Bug #701589 "Minor documentation problems in 9.28-rc2"
> Thanks to Paul Vojta for pointing these out. Unfortunately we cannot use the
> supplied patch, as it includes alterations to History9.htm, which is auto-
> generated from the commit logs. The remaining changes are applied here.
> doc/Language.htm
> doc/Use.htm

2019-09-11 12:18:51 +0100
Chris Liddell <chris.liddell@artifex.com>
90bdf83d696562e4136b8f565cac06cc32b161ae

> Bug 701563: pdfwrite annotation pdfmark /Border key
> Despite the spec saying the values for the /Border key are in user space
> coordinates, Distiller appears to pass the values through to the output PDF
> untouched (no rescaling - unlike the values for /Rect, also in user space,
> according to the spec, which it does scale/translate). Ghostscript/pdfwrite
> did scale the /Border values.
> This just changes pdfwrite to write the values out unchanged.
> devices/vector/gdevpdfm.c

2019-09-16 09:56:52 +0100
Ken Sharp <ken.sharp@artifex.com>
a9e997cb97a274bebfc028e8831a43d6f66be0f9

> Documentation - add a note about SAFER for PDF/X ICC profiles
> Bug #701553 "Examples of PDF/X and PDF/A conversion should be updated for Ghostscript 9.28"
> ICC profiles required for PDF/X and PDF/A output need to be readable
> in order to work when -dSAFER is true (the new default). This wasn't
> clear from the documentation, so add a note about it.
> As noted in the bug report, it is possible to embed the profile in the
> PostScript code, but as Chris says this is probably beyond reasonable
> expectations of the average user; they simply won't change the example
> and will then complain that it isn't correct. Users capable of making
> this work almost certainly have enough knowledge to realise they can
> do this instead of making the profile readable.
> doc/VectorDevices.htm

2019-09-12 19:41:47 +0100
Robin Watts <Robin.Watts@artifex.com>
cea41505580dfe55234bd4972fbb09af5e2e6bb8

> Fix various printer devices to properly call spec ops.
> Various printer devices (psd, psdcmykog, tiffsep, tiffscaled)
> were passing the spec ops on to gx_default_dev_spec_op rather
> than gdev_prn_dev_spec_op.
> The most obvious implication of this was that we'd sometimes
> get a warning about printer devices having a private spec op.
> devices/gdevcmykog.c
> devices/gdevpsd.c
> devices/gdevtsep.c

2019-09-12 17:09:50 +0100
Robin Watts <Robin.Watts@artifex.com>
89f3d6001728678755aca8c5a02e57bba72a0813

> Bug 701568 followup: Fix RLE compressor.
> The previous fix to the RLE compressor reveals an additional
> existing issue to do with us not checking whether we have
> space in the buffer to write the EOD byte.
> Fixed here.
> base/srle.c

2019-09-12 09:35:01 +0100
Robin Watts <Robin.Watts@artifex.com>
f394c0722d3415ba03f57dc32dcd8484d3173b62

> Bug 701568: Fix gdevpx.c RLE stream handling.
> The current code in pclxl_write_image_data_RLE passes
> lines of data to the RLE compression routine. It tells
> each invocation of that routine that this is the "last"
> block of data, when clearly it is not.
> Accordingly, the compression routine inserts the "EOD" byte
> into the stream, and returns EOFC.
> Independently of the return value used, having multiple EOD
> bytes in the data is clearly wrong. Update the caller to only
> pass "last" in for the last block.
> The code still returns EOFC at the end of the data, so update
> this final call to accept (indeed, expect) that return value
> there.
> devices/vector/gdevpx.c

2019-09-10 09:04:46 -0700
Ray Johnston <ray.johnston@artifex.com>
6cd0b941d86fe54b7e818e563dc702a147bab95a

> Fix bug 701550, problem with forall on strings.
> Hard to believe, but this problem has existed since at least version 3.33.
> The 'string_continue' function altered the size which was used to decide if
> there were still characters to be processed BEFORE invoking the 'push(#)' macro.
> If the 'push(1)' encountered a full stack segment, it would return stackoverflow
> so that the operand stack could be extended. This meant that the decision to
> stop enumerating the string would end early (depending on how many times the
> stackoverflow occurred).
> Usually the procedure of the forall would either consume the character (reducing
> the stack), or add an element to the stack triggering the stack extension before
> the next execution of string_continue, but -c "401 string { dup } forall count ="
> results in only 800 stack elements (rather than 802 as expected).
> psi/zgeneric.c

2019-08-15 15:54:04 +0100
Chris Liddell <chris.liddell@artifex.com>
f560f3c468ac187eca8cd55ee46a46e2924e0924

> Doc updates, changelog, news etc
> Update to note explicitly case sensitivity on Windsows
> In News.htm and History9.htm
> doc/History9.htm
> doc/News.htm
> doc/Use.htm

2019-09-05 09:09:38 +0100
Chris Liddell <chris.liddell@artifex.com>
cc86598152465c85dfca5ba265608931672f730f

> Date for 9.28 rc2
> base/gscdefs.h
> base/version.mak
> doc/DLL.htm
> doc/Deprecated.htm
> doc/Develop.htm
> doc/Devices.htm
> doc/Drivers.htm
> doc/Fonts.htm
> doc/History9.htm
> doc/Install.htm
> doc/Internal.htm
> doc/Language.htm
> doc/Lib.htm
> doc/Make.htm
> doc/News.htm
> doc/Ps-style.htm
> doc/Ps2epsi.htm
> doc/Psfiles.htm
> doc/Readme.htm
> doc/Release.htm
> doc/SavedPages.htm
> doc/Source.htm
> doc/Unix-lpr.htm
> doc/Use.htm
> doc/VectorDevices.htm
> doc/WhatIsGS.htm
> doc/gs-vms.hlp
> doc/sample_downscale_device.htm
> doc/subclass.htm
> doc/thirdparty.htm
> man/dvipdf.1
> man/gs.1
> man/gslp.1
> man/gsnd.1
> man/pdf2dsc.1
> man/pdf2ps.1
> man/pf2afm.1
> man/pfbtopfa.1
> man/printafm.1
> man/ps2ascii.1
> man/ps2epsi.1
> man/ps2pdf.1
> man/ps2pdfwr.1
> man/ps2ps.1

2018-10-31 20:22:11 +0100
Sebastian Rasmussen <sebras@gmail.com>
350a5cd8b7bddee3fa914c914dd40a685fed54e7

> Bug 700088: Report error if all wanted J2K components are not decoded.
> Ghostscript used to attempt to use even the undecoded components.
> The source code for upstream's opj_decompress tool avoided this by
> a workaround along with a comment indicating that this ought to be
> done in the library (so all clients, e.g. Ghostscript will benefit
> from it). With this commit the library will error out if not all
> requested components are successfully decoded. Thus Ghostscript
> will no longer crash.
> Reported in https://github.com/uclouvain/openjpeg/issues/1158
> sent upstream in https://github.com/uclouvain/openjpeg/pull/1164
> and finally committed in e66125fe260deee49fdf6e9978d9bd29871dd5bb
> openjpeg/src/bin/jp2/opj_decompress.c
> openjpeg/src/lib/openjp2/j2k.c

2019-09-03 12:34:55 -0700
Michael Vrhel <michael.vrhel@artifex.com>
b944e875baed62e718eee8e7ad2b351cd4f4aa07

> Undo commit 95f7befcec1b30fd5014c8ad616485d32901ce33 for release
> Proper handling of the page group color space is going to require
> a more complex solution whereby we ensure that we do the final
> alpha blending in the page group color space and not the target
> device color space.
> base/gstrans.c

2019-09-03 08:52:16 -0700
Michael Vrhel <michael.vrhel@artifex.com>
ebfe16357f3484209e69d6788cc52b20dbdb81a0

> Add -sBlendColorProfile into Use.htm
> doc/Use.htm

2019-09-03 18:15:56 +0100
Robin Watts <Robin.Watts@artifex.com>
bbdfaa56b00f2ba556476f0265e65e4ad370f641

> Avoid potential UMR with arg checking in arg sanitization code.
> base/gslibctx.c

2019-09-02 17:16:45 +0100
Robin Watts <Robin.Watts@artifex.com>
00d4696ea2de6c48a57d5a4ce0c3bbfd99201e3a

> Proper fix for deep color overprint.
> The previous fix confused memset and memcpy. Properly write the
> (native endian) 16 bit color values into the big endian buffer.
> base/gsovrc.c

2019-09-02 12:59:33 +0100
Robin Watts <Robin.Watts@artifex.com>
c6d448b3fe616fdc2ba1e52766c9a4417e4e738f

> Fix deep color mattes.
> As seen with the content vanishing when rendering
> tests_private/pdf/sumatra/uninitialized_value_with_JPX_images.pdf
> to psdcmyk16. The Softmask on the image has a Matte of [1,1,1]
> and the calculations in the current code overflow, meaning that
> it comes out as completely white.
> We resort to 64bit to avoid the overflow. Mattes are vanishingly
> rare, so speed shouldn't be an issue. We can revisit if we ever
> find a case that matters.
> base/gdevp14.c

2019-08-31 12:45:47 +0100
Robin Watts <Robin.Watts@artifex.com>
4c1f255c2e825ab5e0a3d0f7bfa88538c7cbb912

> Update overprint hl_color code to cope with 16bit devices too.
> base/gsovrc.c

2019-08-31 12:16:40 +0100
Robin Watts <Robin.Watts@artifex.com>
373787ee145e906c8d19d5ccda84b4f267db2010

> Fix deep color transparency overprint.
> The component copy loop at the end of the blend could fail to copy
> enough entries.
> base/gxblend.c

2019-08-30 15:16:34 +0100
Robin Watts <Robin.Watts@artifex.com>
361c4dd1e18ca0675173c0ad0104ffb910e93bb4

> Avoid overflow in deep color luminosity calculations.
> Resort to 64bit as scale calculations are not constrained
> to the usual 16bit range.
> base/gxblend.c

2019-08-29 10:02:49 +0100
Chris Liddell <chris.liddell@artifex.com>
51d57fafbdc021c8c73475db505156f77e96ce39

> Fix clearing of the drag and drop file list
> Because we have to store the list of file names from drag and drop events, in
> order to correctly add and remove them from the permit file read list, we also
> want to clear the lists before we destroy the "text" window object.
> The problem is, this happens after we shutdown Ghostscript and unload the dll.
> This moves that clearing of the list into function that we call before we
> shut down.
> psi/dwmain.c
> psi/dwtext.c
> psi/dwtext.h

2019-08-28 10:14:52 +0100
Chris Liddell <chris.liddell@artifex.com>
ad0532e379a9eb6eb8a6fc0a6305679b25cd9ecb

> Fix path permissions added from cidfmap.
> From the cidfmap, we accumulate a list of unique directory paths a we process
> cidfmap and then add them - when I did that code, I forgot that to allow access
> to the directory, we need a trailing directory separator.
> Add that before calling .addcontrolpath
> Resource/Init/gs_cidfm.ps

2019-08-27 16:49:30 +0100
Chris Liddell <chris.liddell@artifex.com>
f0fedf1f77a9fe70627355b45fdb809e83df3568

> Fix font file finding with -P
> In trying to reproduce the issue that inspired commit dea69cd04964, I noticed
> that font file searching wasn't working correctly with -P specified on the
> command line.
> Previously, it could just end up with us not finding a font we should have, but
> with dea69cd04964 it would result in a typecheck error.
> This ensures the stack is always how it should be after the findlibfile
> call
> Resource/Init/gs_fonts.ps

2019-08-22 16:10:03 +0100
Chris Liddell <chris.liddell@artifex.com>
5c28996d19d5e10cb177e72c47037ec0c7b3e4d5

> Make it clear: file/path matching is always case sensitive
> even on Windows.
> doc/Use.htm

2019-08-29 19:50:08 +0100
Robin Watts <Robin.Watts@artifex.com>
24532ce9371fd1f69dd343cbd6ac8187a86c5c96

> Fix overflow in 16bit blending calculations.
> The blending code uses the following construction in
> several places:
> src_scale = ...; /* a value between 0 and 0x10000 */
> tmp = (y-z) * src_scale + 0x8000;
> foo = x + (tmp>>16);
> Where x,y,z, are all expected to be in the 0...0xffff range.
> Due to y-z having a sign bit, this can overflow a 32 bit tmp.
> We therefore sacrifice a bit of accuracy in src_scale to get
> correctness.
> base/gxblend.c
> base/gxblend1.c

2019-08-28 14:13:27 +0100
Robin Watts <Robin.Watts@artifex.com>
ca52028b90a09d056190548c41ae0b9a9fbadb4e

> Remove outdated FIXME's.
> base/gdevp14.c

2019-08-28 12:50:36 +0100
Robin Watts <Robin.Watts@artifex.com>
bd59dc145252282d8f586c36082e63a0eba95c15

> Bug 701446: Avoid divide by zero in shading.
> The previous commit for this bug was enough to solve the problem
> for ppmraw, but not, it seems, for other devices. This addresses
> the division by zero more directly.
> base/gxshade6.c

2019-08-27 20:13:02 +0100
Robin Watts <Robin.Watts@artifex.com>
9a32a379933f4ba27ff1ad5734ec8c24c42eb513

> Fix deep color transparency saturation blending.
> Problem seen with:
> tests_private/pdf/PDF_1.7_FTS/fts_25_2513.pdf.psdcmyk16.300.1
> base/gxblend.c

2019-08-27 17:45:57 +0100
Robin Watts <Robin.Watts@artifex.com>
68af4dbc7ca2d6bfdbe938b840799cb8883c973e

> Bug 701446: Avoid division by zero in gx_shade_trapezoid
> Remove some incorrect clipping code.
> base/gxshade6.c

2019-08-27 15:54:36 +0100
Robin Watts <Robin.Watts@artifex.com>
4be058791ae19131f19a8303364be53619abc280

> Exit early from gx_shade_trapezoid in more cases.
> A zero height trap isn't plotted, so we can bail out early in
> that case.
> base/gxshade6.c

2019-08-26 17:02:03 +0100
Robin Watts <Robin.Watts@artifex.com>
9423e84178071f16b83d18412b22b0b479b1938b

> Fix deep colour transparency "uncompositing".
> Uncompositing a group uses a scale factor that is greater in range
> than we'd like; we need to resort to 64bit to do this to avoid
> losing accuracy.
> This solves problems seen in:
> tests_private/comparefiles/Bug689918.pdf.psdcmyk16.300.1
> base/gxblend.c

2019-08-27 14:26:41 +0100
Chris Liddell <chris.liddell@artifex.com>
131768114453972469296658b795406b79630538

> Handle relative FONTPATH values
> Prior to 9.21 (specifically: 8abd22010eb4db0fb1b10e430d5f5d83e015ef70), relative
> paths for FONTPATH worked, but did so due to a logic fault with how we search
> for "lib" files.
> When attempting to open file names specified on the command line, we used a
> flag set in the command line handling (starting_arg_file) to know whether the
> lib file searching logic should try to open the file name directly (as well as
> trying the file combined with each path in the search path).
> In versions prior to commit 8abd22010eb4 that flag (starting_arg_file) could
> remain set to true, even after the command line file(s) had been opened. This
> represented a (minor) security risk. Commit 8abd22010eb4 ensured the flag was
> properly (re)set, and that caused relative paths for FONTPATH stopped working.
> Rather than reintroduce the security risk, update the code that checks whether
> the font files exist so it explicitly tries the file name directly, rather than
> assuming .libfile (or findlibfile, in this case) does that automatically.
> Also remove an extraneous (but benign) dup of the font name.
> Resource/Init/gs_fonts.ps

2019-08-27 15:27:05 +0100
Ken Sharp <ken.sharp@artifex.com>
98310063bdbe8c67bcfe84e2c648cfa286a05738

> pdfwrite - fix corner case with Color Conversion
> Bug #701456 "Ghostscript creates broken PDF file after color conversion"
> The test file is, essentially weird. The image on page 3 is not a single
> image, its a series of images, all of which are in a /Indexed /DeviceRGB
> colour space.
> In addition, these images are drawn on *top* of another set of images
> (thereby completely obscuring them). These images are also drawn in
> /Indexed /DeviceRGB. However, these images are in fact monochrome, the
> Indexed space consists of 2 colours. This means that (highly unusually)
> we have a DeviceRGB image with 1 Bit Per Component.
> This caused problems for the pdfwrite compression filter chooser because
> it chose (and configured) a compression scheme suitable for 1 BPC data
> and then actually output 8 BPC data. This led to the compression filter
> writing too little data.
> Fix this here by setting the BPC to 8 if we are doing colour conversion,
> and have the colour conversion setup code use the original value in the
> image enumerator (the conversion code *does* need to know the input is
> 1 BPC).
> devices/vector/gdevpdfi.c

2019-08-27 11:36:35 +0100
Ken Sharp <ken.sharp@artifex.com>
aee3b922087674ddd7c64444988018fafc3da127

> PDF interpreter - more /Mask strangeness in Acrobat
> Bug #701468 " More weirdness with images containing invalid /Mask values"
> In order to render this file as per Acrobat, we need to ignore the /Mask
> array. However, in order to render bug 689717 correctly we need to fix
> the /Mask array.
> Both cases are 1 BitsPerComponent DeviceGray images, the only difference
> is the actual /Mask values. Bug 689717 has [255 255] while 701468 has
> [243 255]. We can differentiate based on whether we have DeviceGray
> 1 BPC image, where the Mask values are not the same. In the case they
> are different we use the existing technique of calculating the maximum
> value and using that (for both, so there is no range). Where there is a
> range (ie not a single colour) this is clearly unusable in a 2-colour
> image, so ignore the /Mask altogether.
> Resource/Init/pdf_draw.ps

2019-08-26 15:28:33 +0100
Robin Watts <Robin.Watts@artifex.com>
ad22dcaa078fd16f2ac395f65b6ad87ba24c8903

> Fix deep colour knockout logic.
> Problem seen with:
> tests_private/pdf/PDF_1.7_FTS/fts_25_2507.pdf.psdcmyk16.72.0
> base/gxblend.c

2019-08-26 14:34:46 +0100
Robin Watts <Robin.Watts@artifex.com>
4cda7bfc8cc8c5c4dcd36167191012aa379100ac

> Squash a couple of warnings.
> base/gdevmem.c
> base/gdevp14.c

2019-08-26 14:01:39 +0100
Robin Watts <Robin.Watts@artifex.com>
7b5166b5c65703abb02c15a31c9f8341f54d1470

> Fix SoftLight blending in deep color transparency.
> As seen with:
> gs -sDEVICE=psdcmyk16 -r72 -dMaxBitmap=80000000 -o out.psd
> tests_private/pdf/PDF_1.7_FTS/fts_09_0919.pdf
> base/gxblend.c

2019-08-26 11:28:40 +0100
Robin Watts <Robin.Watts@artifex.com>
5875be5edeb034787a11760c9330cac039f13044

> Fix problems with pngalpha and deep color transparency filling.
> The pngalpha device is created with a depth of 32, with 3 color
> components; this was confusing pdf14 into thinking that more
> than 8 bits per color were being used, and so deep color buffers
> were required.
> To fix this we update the logic to be smarter; in cases where we
> don't have a clear determination based on bits alone, we look
> at the max_color and max_gray values. Because this code is now
> more complex than before, we pull it into a shared function.
> base/gdevdflt.c
> base/gdevmem.c
> base/gdevp14.c
> base/gdevprn.c
> base/gsptype1.c
> base/gstrans.c
> base/gxclthrd.c
> base/gxdevcli.h

2019-08-23 15:06:17 +0100
Robin Watts <Robin.Watts@artifex.com>
6e7283fa5bcea9ffbe4bb9da440dd8fa4820e4d6

> Fix deep color transparency issue.
> Fix overflow in art_pdf_composite_knockout_16, seen in:
> tests_private/comparefiles/Bug690546.pdf.psdcmyk16.72.0
> base/gdevp14.c
> base/gxblend.c

2019-08-22 18:24:49 +0100
Robin Watts <Robin.Watts@artifex.com>
628c9741323ea69b0be8e4008a81b1db3d644ab8

> Fix deep color transparent pattern problems.
> Transparency buffers are held as native endian. Pattern cache
> tiles are held as big endian. When we make pattern cache tiles
> from transparency buffers we therefore need a conversion.
> base/gdevp14.c
> base/gxblend.c
> base/gxp1fill.c
> base/gxpcolor.h

2019-08-25 19:35:14 +0200
Till Kamppeter <till.kamppeter@gmail.com>
be4da9d67cbec784be740086681f96a63496ae48

> "cups"/"pwgraster" output device: Do not output LUTs with CUPS_DEBUG set
> This change lets complete LUTs in the debug output only be listed when
> CUPS_DEBUG2 is set and not already with CUPS_DEBUG.
> cups/gdevcups.c

2019-08-25 19:08:52 +0200
Till Kamppeter <till.kamppeter@gmail.com>
0e28c843e56d1be4638bf9d84a499794534ea0d9

> "cups"/"pwgraster" output device: Prefer the page size requested by user
> Without special scaling/cropping options ("fit-to-page", "fill",
> "crop-to-fit΅, ...) PDF and PostScript files printed with CUPS will be
> printed with the page sizes of the document's pages and not the size
> requested by the user via the "PageSize" or "media" option. This
> allows correct printing of jobs with differently sized pages on
> printers which have the appropriate sizes loaded without need of
> manual intervention. Therefore the CUPS output device is matching each
> input page against the sizes listed in the PPD to generate a correct
> page geometry for the printer for each page.
> Problem is if there are several equally-sized page size entries in the
> PPD. Without further guiding always the first match is used, making
> access to special functions provided by the others (like
> full-bleed/borderless printing) inaccessible.
> This commit adds the functionality of the user-requested page size
> (via "PageSize" or "media" option) being preferred under the matching
> page sizes, so that if for example a user selects a full-bleed version
> of the desired page size and sends a photo, the photo gets rendered
> and printed with the page geometry which the PPD reports for the
> full-bleed version.
> Nothing changes if the size of the user-requested page size does not
> match the size of the input page at all.
> cups/gdevcups.c

2019-08-25 12:45:27 +0200
Till Kamppeter <till.kamppeter@gmail.com>
a5ccd009fd632e058b4f0bc2849cfc293b39d1f2

> "cups"/"pwgraster" output device: Small fix on size matching improvements
> This is a fix for one little oversight on the changes to support matching
> the input page size against the imageable areas of the PPD's page sizes.
> This completes the fix of bug 701438.
> cups/gdevcups.c

2019-08-24 23:11:10 +0200
Till Kamppeter <till.kamppeter@gmail.com>
a0284b5ac8c59014eab90c5a5ec388cd1676b79d

> "cups"/"pwgraster" output device: Improved page size matching with PPD
> Applied the following improvements for finding the correct page size
> of the PPD file for the input page:
> - Do not try to match by page size name, the input files do not
> contain page size names.
> - Do not only match the input page size against the actual media sizes
> reported by the PPD but also to the imageable areas. Media size match
> is preferred but if there is no media size match, we accept also
> a match of the imageable area. In case of a match of the imageable
> area we position the input page in the imageable area of the output
> page.
> - More debug output.
> - In case of a custom page size (no match with PPD sizes) the page
> size name in the CUPS Raster output is a correct "Custom.XXXxYYY"
> and not the default page size name.
> This should fix bug #701438.
> cups/gdevcups.c

2019-08-23 18:09:32 +0200
Till Kamppeter <till.kamppeter@gmail.com>
ee43ff891b51f0ccec3ba38d538d3e23441ed439

> "cups"/"pwgraster" output device: Reduced page size comparison tolerances
> Before each page gets rendered its size is compared to the page sizes
> of the PPD file to select the actual page size for the output. Reduced
> the tolerances from 7% for the long edge and 5% for the short edge to
> 1%, as before easily wrong sizes got picked (See also bug 701438).
> cups/gdevcups.c

2019-08-23 10:11:05 +0100
Chris Liddell <chris.liddell@artifex.com>
0311b61d5df67cd98e2c2d23ef3cec1cc4faa800

> Windows Installer: cope with COMPILE_INITS=0
> We default to COMPILE_INITS=1, and that was the only case that the installer
> handled - i.e. building the installer with COMPILE_INITS=0 would install an
> executable that wouldn't work without extra action (-I.. or similar).
> This changes the installer compiler invocation, and the installer creation
> so it behaves as it does now with COMPILE_INITS=1, but with COMPILE_INITS=0 the
> installer will write the path to Resource/Init into the GS_LIB registry
> key.
> psi/nsisinst.nsi
> psi/winint.mak

2019-08-22 23:30:34 +0200
Till Kamppeter <till.kamppeter@gmail.com>
137a0bda39f861600488b5a11c63914854c454c8

> "cups"/"pwgraster" output device: Produce more debug output
> When building with CUPS_DEBUG now debug output for the process of
> matching the page geometry with the PPD file's page sizes is
> produced.
> cups/gdevcups.c

2019-08-22 08:58:01 +0100
Chris Liddell <chris.liddell@artifex.com>
09b53ebdc674f9f6e7a9c445e92617312dd93ab3

> Handle explicit '\' escaping in path matching
> As well as having to cope with both '/' and '\' as directory separators on
> Windows, it turns out we also need to cope with the backslash separator being
> explicitly escaped ("\\") - the explicit is added by the Postcript path
> templating code in gs_init.ps.
> I don't want to change templating code because that would likely have
> implications in a lot of other places.
> base/gpmisc.c

2019-08-22 10:51:28 +0100
Robin Watts <Robin.Watts@artifex.com>
f1692a288f1a17930f0b71e540908398a17d5366

> Better CMYK conversion for bmpcmp
> toolbin/bmpcmp.c
> toolbin/bmpcmptab.h

2019-08-21 17:49:32 +0100
Robin Watts <Robin.Watts@artifex.com>
c8aaf3b7bc4232997d434170827fffd6887fc88f

> Update bmpcmp.c to read psdrgb rather than psdbgr.
> toolbin/bmpcmp.c

2019-08-21 15:33:27 +0100
Chris Liddell <chris.liddell@artifex.com>
9ba1827e220cd49a6732c04fcf3e55a268014377

> Fix commit ec0b35fed3de: "Handle directory separators..."
> The logic in the above fix was wrong.
> base/gpmisc.c

2019-08-21 14:28:20 +0100
Robin Watts <Robin.Watts@artifex.com>
7d0206d2b118b26f6d87ba8f09d077eba417e4c9

> Bug 701451: Fix clist color_usage calculations for shadings.
> Or rather, don't attempt to calculate them badly, and just
> use the safe "all colors" value.
> base/gxclrect.c

2019-08-21 10:10:51 +0100
Ken Sharp <ken.sharp@artifex.com>
320ec9672b987a765324f89450de08b70aafbcd3

> PDF interpreter - review .forceput security
> Bug #701450 "Safer Mode Bypass by .forceput Exposure in .pdfexectoken"
> By abusing the error handler it was possible to get the PDFDEBUG portion
> of .pdfexectoken, which uses .forceput left readable.
> Add an executeonly appropriately to make sure that clause isn't readable
> no mstter what.
> Review all the uses of .forceput searching for similar cases, add
> executeonly as required to secure those. All cases in the PostScript
> support files seem to be covered already.
> Resource/Init/pdf_base.ps
> Resource/Init/pdf_draw.ps
> Resource/Init/pdf_font.ps
> Resource/Init/pdf_main.ps
> Resource/Init/pdf_ops.ps

2019-08-21 10:56:02 +0100
Chris Liddell <chris.liddell@artifex.com>
e5660f15f5fd4615254acec7ed403b4a7984cb09

> Handle directory separators in access control matching
> On Windows, we end up dealing with a mishmash of "/" and "\" as directory
> separators, so a simple equality check isn't sufficient.
> Since there is already (platform specific) function for checking whether a
> string (or part thereof) is a directory separation, use it.
> base/gpmisc.c

2019-08-20 21:50:18 -0700
Michael Vrhel <michael.vrhel@artifex.com>
596e9baa1b24b0a9dac4d8bad1ea80cd23dcab79

> Disable use of alternate tint transform ICC profile
> A prior commit introduced the use of color management
> if the DeviceN or Separation device had an ICC profile
> associated with the colorants. While there is an argument
> for doing this, it is not the standard behavior seen in
> AR. Disabling for now and will likely turn this into a
> command line option.
> base/gxcmap.c

2019-08-20 18:48:49 +0100
Robin Watts <Robin.Watts@artifex.com>
7547a2fc593e3a0bb8ea72f661389cd908c382f7

> Fix crashes in RAW_DUMP debug code.
> Dump the buffer before freeing the device, or the pointer will no
> longer be valid.
> Also, don't access through ppatdev14 when we know it's NULL.
> base/gdevp14.c

2019-08-20 18:47:09 +0100
Robin Watts <Robin.Watts@artifex.com>
421727ed068b3f41fdbd9657d759397610fe8821

> Fix deep color transparency pattern copying problem.
> The following test:
> tests/pdf/pattrans_solid_nonrect.pdf.psdcmyk16.300.1..gs
> among others, was showing problems, due to us treating the offset
> as bytes rather than shorts.
> base/gxp1fill.c

2019-08-20 14:29:33 +0100
Robin Watts <Robin.Watts@artifex.com>
f9052f1debff2168d5a2606fa35bcaaf6f6f2ec7

> Avoid signed overflow in deep transparency calculations.
> base/gxblend.c

2019-08-20 12:24:03 +0100
Robin Watts <Robin.Watts@artifex.com>
898c9e5f06bb44ec3fd262b47eeaa5028e18773f

> Fix overflow in deep color blending.
> Multiplying a 16bit unsigned value with a 16 bit signed value
> in a 32bit int means we lose the sign bit. Sacrifice a bit of
> accuracy to avoid that.
> base/gxblend.c

2019-08-20 10:10:28 +0100
Ken Sharp <ken.sharp@artifex.com>
85c9d6de80ba57deeee289238aa1c0202f584c3c

> make .forceput inaccessible
> Bug #701343, #701344, #701345
> More defensive programming. We don't want people to access .forecput
> even though it is no longer sufficient to bypass SAFER. The exploit
> in #701343 didn't work anyway because of earlier work to stop the error
> handler being used, but nevertheless, prevent access to .forceput from
> .setuserparams2.
> Resource/Init/gs_lev2.ps
> Resource/Init/gs_pdfwr.ps

2019-08-19 10:03:57 +0100
Chris Liddell <chris.liddell@artifex.com>
3ba6d871c70398cfbd15b619127bf13ddea13282

> Handle drag'n'drop file name/paths
> Because we now run by default with the file access permission active,
> we need to do additional work for Windows drag and drop files, so they don't
> throw an invalidaccess error (since we implement drag and drop by sending
> characters to the gs console to do '(file) run').
> The problem is, we cannot add the file to read list, send the characters to the
> console, and remove the file from the read list because, although SendMessage()
> blocks until the message is handles, WriteConsoleInput() does not block until
> the console buffers are consumed (i.e. it is asynchronous). So, there is no
> certainty when the final SendMessage() in WM_DROPFILES case is finished that
> Ghostcript will actually have run the file.
> So, we create a list of dropped file names, add them to the permit read list,
> when the next WM_DROPFILES event happens, or a WM_DESTROY event, we drop
> file names from the permit read list before, if necessary, adding the current
> ones.
> psi/dwimg.c
> psi/dwmain.c
> psi/dwmainc.c
> psi/dwtext.c
> psi/dwtext.h

2019-08-16 15:43:32 +0100
Robin Watts <Robin.Watts@artifex.com>
d2e36e8ef01546aaee0cd0531fbc0fa932b23b99

> Squash warnings in claptrap.
> Thanks to William Bader for highlighting these.
> base/claptrap-planar.c

2019-08-16 15:28:49 +0100
Robin Watts <Robin.Watts@artifex.com>
e34d5606835fc587e222b80bf9cac1bc40c4790b

> Squash warning in gdevpsd.c
> Thanks to William Bader for spotting this.
> devices/gdevpsd.c

2019-08-16 13:08:14 +0100
Robin Watts <Robin.Watts@artifex.com>
f416b415e8e3a25446b66bf1a6253f86be0366de

> Squash some compiler warnings.
> base/gslibctx.c
> base/gslibctx.h
> devices/gdevpdfimg.c
> devices/vector/gdevpdfu.c
> pcl/pl/plmain.c

2019-08-15 11:39:51 +0100
Chris Liddell <chris.liddell@artifex.com>
9ead927968ff8104e1a81df1590fced74927639d

> Dates and versions for 9.28 RC 1
> base/gscdefs.h
> doc/DLL.htm
> doc/Deprecated.htm
> doc/Develop.htm
> doc/Devices.htm
> doc/Drivers.htm
> doc/Fonts.htm
> doc/History9.htm
> doc/Install.htm
> doc/Internal.htm
> doc/Language.htm
> doc/Lib.htm
> doc/Make.htm
> doc/News.htm
> doc/Ps-style.htm
> doc/Ps2epsi.htm
> doc/Psfiles.htm
> doc/Readme.htm
> doc/Release.htm
> doc/SavedPages.htm
> doc/Source.htm
> doc/Unix-lpr.htm
> doc/Use.htm
> doc/VectorDevices.htm
> doc/WhatIsGS.htm
> doc/gs-vms.hlp
> doc/sample_downscale_device.htm
> doc/subclass.htm
> doc/thirdparty.htm
> man/dvipdf.1
> man/gs.1
> man/gslp.1
> man/gsnd.1
> man/pdf2dsc.1
> man/pdf2ps.1
> man/pf2afm.1
> man/pfbtopfa.1
> man/printafm.1
> man/ps2ascii.1
> man/ps2epsi.1
> man/ps2pdf.1
> man/ps2pdfwr.1
> man/ps2ps.1

2019-08-15 11:35:56 +0100
Chris Liddell <chris.liddell@artifex.com>
ae7dea2b9bd068f61b6aef312a7f4cbc9860cac3

> Revision date
> base/version.mak

2019-08-15 17:06:02 +0100
Chris Liddell <chris.liddell@artifex.com>
2f8e2423c860e89b325675dc1311819179740c76

> Add -dNOSAFER for Windows installer cidfmap creation
> psi/nsisinst.nsi

2019-08-15 14:36:55 +0100
Ken Sharp <ken.sharp@artifex.com>
226fb24dbe4f844b8c7531be3eccc2bfae1a103d

> ps2write - don't password encrypt PostScript output!
> Noticed while testing the args commit; if we set -sOwnerPassword (to
> create a password-protected PDF file), but select (e)ps2write as the
> device, then the resulting PostScript file would have all the streams
> (in a PDF sense) encrypted with PDF password encryption.
> Unsurprisingly, this result in a completely unusable PostScript file.
> Lets not permit that....
> devices/vector/gdevpdfp.c

## Version 9.50 (2019-10-15)

Highlights in this release include:

- The change to version 9.50 (rather than the intended 9.28) follows recognition of the extent and importance of the file access control redesign/reimplementation outlined below.

- The file access control capability (enable with `-dSAFER`) has been completely rewritten, with a ground-up rethink of the design. For more details, see: SAFER.

  It is important to note that `-dSAFER` now only enables the file access controls, and no longer applies restrictions to standard Postscript functionality (specifically, restrictions on `setpagedevice`. If your application relies on these Postscript restrictions, see OLDSAFER, and please get in touch, as we do plan to remove those Postscript restrictions unless we have reason not to.

  IMPORTANT: File access controls are now enabled by default. In order to run Ghostscript without these controls, see NOSAFER

Important Note for Windows Users: See below under Incompatible Changes

- IMPORTANT: We are in the process of forking LittleCMS. LCMS2 is not thread safe, and cannot be made thread safe without breaking the ABI. Our fork will be thread safe, and include performance enhancements (these changes have all be been offered and rejected upstream). We will maintain compatibility between Ghostscript and LCMS2 for a time, but not in perpetuity. Our fork will be available as its own package separately from Ghostscript (and MuPDF).

- The usual round of bug fixes, compatibility changes, and incremental improvements.

- Special thanks to Akira Kakuto, Paul Wessel, William Bader, Nelson H. F. Beebe and everyone else who put time and effort into testing this new release.

For a list of open issues, or to report problems, please visit bugs.ghostscript.com.

### Incompatible changes

- There are a couple of subtle incompatibilities between the old and new SAFER implementations. Firstly, as mentioned above, SAFER now leaves standard Postcript functionality unchanged (except for the file access limitations). Secondly, the interaction with `save`/`restore` operations, see SAFER.

  Important Note for Windows Users:
  The file/path pattern matching is case sensitive, even on Windows. This is a change in behaviour compared to the old code which, on Windows, was case insensitive. This is in recognition of changes in Windows behaviour, in that it now supports (although does not enforce) case sensitivity.

- The following is not strictly speaking new to 9.50, as not much has changed since 9.27 in this area, but for those who don't upgrade with every release:

  The process of "tidying" the Postscript name space should have removed only non-standard and undocumented operators. Nevertheless, it is possible that any integrations or utilities that rely on those non-standard and undocumented operators may stop working, or may change behaviour.

  If you encounter such a case, please contact us (either the #ghostscript IRC channel, or the gs-devel mailing list would be best), and we'll work with you to either find an alternative solution or return the previous functionality, if there is genuinely no other option.

  One case we know this has occurred is GSView 5 (and earlier). GSView 5 support for PDF files relied upon internal use only features which are no longer available. GSView 5 will still work as previously for Postscript files. For PDF files, users are encouraged to look at MuPDF.

### Changelog

2019-10-14 18:07:29 +0100
Chris Liddell <chris.liddell@artifex.com>
f2e2a3fe85d64cabde82d0f6eb982643bc6e8427

> Add words about .currentpathcontrolstate operator
> doc/Language.htm

2019-10-14 10:28:15 +0100
Chris Liddell <chris.liddell@artifex.com>
ad5b08d8be2e7a91599d3bbbc6aa841144662239

> Change version to 9.50
> Resource/Init/gs_init.ps
> base/version.mak
> doc/DLL.htm
> doc/Deprecated.htm
> doc/Develop.htm
> doc/Devices.htm
> doc/Drivers.htm
> doc/Fonts.htm
> doc/History9.htm
> doc/Install.htm
> doc/Internal.htm
> doc/Language.htm
> doc/Lib.htm
> doc/Make.htm
> doc/News.htm
> doc/Ps-style.htm
> doc/Ps2epsi.htm
> doc/Psfiles.htm
> doc/Readme.htm
> doc/Release.htm
> doc/SavedPages.htm
> doc/Source.htm
> doc/Unix-lpr.htm
> doc/Use.htm
> doc/VectorDevices.htm
> doc/WhatIsGS.htm
> doc/gs-vms.hlp
> doc/sample_downscale_device.htm
> doc/subclass.htm
> doc/thirdparty.htm
> man/dvipdf.1
> man/gs.1
> man/gslp.1
> man/gsnd.1
> man/pdf2dsc.1
> man/pdf2ps.1
> man/pf2afm.1
> man/pfbtopfa.1
> man/printafm.1
> man/ps2ascii.1
> man/ps2epsi.1
> man/ps2pdf.1
> man/ps2pdfwr.1
> man/ps2ps.1

2019-10-14 10:20:19 +0100
Chris Liddell <chris.liddell@artifex.com>
1937e14f17e5de54b57d0e911e828639d197a08c

> Update docs on SAFER
> to reflect that SAFER is now the default, and remove the comments about making
> SAFER the default "in the future".
> doc/Use.htm

2019-10-10 09:29:48 +0100
Ken Sharp <ken.sharp@artifex.com>
9c63f39ead4aab30addf213f0ab6843ac87b56cf

> ps2write - restore missing %%PageTrailer comment
> Bug #701659 "Missing %%PageTrailer commen"
> An oversight in commit 96c381cce28c27eac182549441a6c5025b0dcdd6
> caused the comment to be omitted.
> devices/vector/gdevpdf.c

2019-10-07 18:41:10 +0100
Chris Liddell <chris.liddell@artifex.com>
1d89e1aa9cf65e5345a1f009b6d317db024719fe

> Bug 701657: Allocate "memory" device in immovable gc memory
> Devices are supposed to be allocated in memory that cannot relocate (i.e.
> non-gc memory or an immovable allocation). The memory device accessible from
> Postscript (makeimagedevice/makewordimagedevice) was being created in regular,
> relocatable gc memory.
> This caused an invalid memory access when cleaning up subclassed devices, as the
> one device in the chain may have moved. So switch to using an immovable
> allocation.
> base/gsdevmem.c

2019-10-02 00:01:17 +0200
Sebastian Rasmussen <sebras@gmail.com>
458f715b0d59278f0788e0c89ee5eb04d48871ef

> Update jbig2dec stuff for 0.17 release.
> jbig2dec/CHANGES

2019-10-01 10:35:48 +0100
Chris Liddell <chris.liddell@artifex.com>
f8ba9e017cdfab836f62853629d75f484127342e

> Fix memory corruption setting a halftone
> When setting a new halftone in the graphics state, we try to re-use the data
> from the existing device halftone.
> The problem is that the device halftone can have higher component indices than
> there are components in the new halftone we are creating. In this case, we can
> end up writing off the end of the components array for the new halftone
> structure.
> Simply check that the new halftone has enough components before doing the
> duplication.
> base/gsht.c

2019-09-30 13:40:35 +0100
Ken Sharp <ken.sharp@artifex.com>
1681c7ebb5a338002d5f7dd8da9bffda675f0656

> pdfwrite - don't honour /Producer key in DOCINFO pdfmark
> Bug #701639 "pdfwrite should not honour the /Producer key in DOCINFO pdfmark"
> The Producer in the document information dictionary (and XML Metadata)
> is defined quite clearly as the application which produced the PDF file
> from its native format.
> Ghostscript uses the Producer key (if present in the pdfmark) to set
> the Producer, but it should not do so. Adobe Acrobat Distiller (at
> least the end user version) does not permit this value to be altered.
> On reflection we can see why; in the case of a problem with a PDF file
> its important to know which application created it, and we should not
> let PostScript obscure that (we already do not pass the Producer
> information on when the input is PDF).
> The code did already attempt to overwrite any Producer string which
> contained 'Distiller' (I have no idea why) and that code contained an
> error which could lead to an invalid Document Information dictionary
> being created.
> This commit removes the ability for DOCINFO pdfmarks to alter the
> Producer, which obviously fixes the bug.
> However..... it is actually important for our commercial customers to
> be able to set this value. A problem with a PDF file created by one of
> our customer's products should be reported to that customer, not us, as
> we will not be able to investigate the problem while our customer
> should be able to. At the very least our customer will know how to
> retrieve the configuration of Ghostscript being used.
> So permit the commercial version of Ghostscript to set the /Producer
> from a pdfmark.
> devices/vector/gdevpdfm.c

2019-09-30 09:16:28 +0100
Chris Liddell <chris.liddell@artifex.com>
a27af00c8727ec4eaf0f4730963b8a81aab8590d

> Small changelog tweak
> doc/History9.htm

2019-09-27 13:26:01 +0100
Chris Liddell <chris.liddell@artifex.com>
b0574cdb5b427690ac8d95679930c9f6cc1bdffb

> Bug 701634: Correctly handle file name of "\0"
> Attempting to open a file with a filename string starting with a NULL
> character should be treated the same as if the string was zero length.
> Not doing so created a broken file object leading to several operations
> resulting in a segfault.
> Also, add cleanup in the event of such an error, freeing memory allocated in
> preparing the gs stream object.
> base/sfxcommon.c
> psi/zfile.c

2019-09-26 10:47:01 +0100
Chris Liddell <chris.liddell@artifex.com>
cce67ebf4c209ae3cbcc671e944596c64a3d7fc9

> Revised comment for 8992f00edfd1c39154c013489de2a01d2e9a92ee
> Make it clearer why the revised behaviour is required.
> base/gstiffio.c

2019-09-26 09:34:02 +0100
Chris Liddell <chris.liddell@artifex.com>
24c9f7f4a8d3e85e572094b4aedddbeeb02d5ef1

> Bug 701313: Disable libtiff callbacks when libtiff is shared
> It seems that libtiff uses global variables to store the error/warning callbacks
> so if two callers in the exe are using the libtiff shared lib, very bad things
> happen (usually a segfault).
> So, if that's how we're linked, set the callbacks to NULL.
> base/gstiffio.c

2019-09-24 15:48:54 +0100
Chris Liddell <chris.liddell@artifex.com>
c40963eb024265ab28f4f897401ad7a050ca9425

> Cope with .setsafe(global) being called when already 'SAFER'
> As we default to SAFER file controls now, we want to cope with .setsafe and
> .setsafeglobal being called either when already SAFER, or called multiple times.
> This means adding a .currentpathcontrolstate operator so we don't try to
> influence the path control lists after control is activated.
> Resource/Init/gs_init.ps
> psi/zfile.c

2019-09-24 09:18:47 +0100
Chris Liddell <chris.liddell@artifex.com>
7d70bd4338291c99234dd0078b5cdc85178c0540

> tiffsep(1): Cope with .tiff ending as well as .tif
> devices/gdevtsep.c

2019-09-23 20:04:49 +0100
Robin Watts <Robin.Watts@artifex.com>
2f713b99e1a626ba4b7b1be8cc715043bb4e0f0a

> Recast validate to use gs_file_name_check_separator.
> Avoid using gp_file_name_directory_separator, as windows can
> have 2 different directory separators.
> base/gpmisc.c

2019-09-23 18:05:00 +0100
Chris Liddell <chris.liddell@artifex.com>
31df729a821d1683381493b96c2ecced9da1e5e2

> Remove spurious call to gp_validate_path_len()...
> ...in gx_device_open_output_file()
> There is no need to validate the path in gx_device_open_output_file() as it will
> be done at a lower level (gp_fopen) for paths that require it (we only validate
> *after* the Postscript style %device% paths have been expanded into 'real'
> paths).
> This also interacts badly with the revised handling of formatted string
> file names, hence remove it.
> base/gsdevice.c

2019-09-23 17:56:34 +0100
Chris Liddell <chris.liddell@artifex.com>
ca553d6d3ec0fa1455cf400629e08db90658aa85

> Fix tiffsep(1) interaction with file permissions lists
> The previous solution didn't quite work, when using formatted strings for
> output file names (i.e. output-%d.tif).
> This adds a dedicated gs_remove_outputfile_control_path() to mirror
> gs_add_outputfile_control_path() and uses those for the dynamic adding and
> removing of separation output file names.
> base/gslibctx.c
> base/gslibctx.h
> devices/gdevtsep.c

2019-09-23 17:11:47 +0100
Robin Watts <Robin.Watts@artifex.com>
205e2f529e6da569ec764ebb4aeddc41c66a8860

> Update path validation to accept multiple *'s as special case.
> Previously we interpretted multiple *'s as meaning the same as
> single *'s. Now we use them to mean "just those chars that
> might be created by the use of a %...{d,x,u,i,o,X} format
> specifier".
> base/gpmisc.c
> doc/Use.htm

2019-09-23 16:41:09 +0100
Robin Watts <Robin.Watts@artifex.com>
dd19ec5348723a5c70ff728911f856caa518166b

> Improve OutputFile handling of %d etc.
> Only accept %d (and friends) (as opposed to anything starting with %).
> Only accept legal combinations of flags/widths/precision etc.
> Generate a more conservative wildcard.
> base/gslibctx.c

2019-09-20 12:38:02 -0700
Ray Johnston <ray.johnston@artifex.com>
da7486fc4b00eee956200d45fb340dc62c8e3bcb

> Slight improvement to "permit-file-***" parameter documentation.
> doc/Use.htm

2019-09-20 11:17:53 -0700
Ray Johnston <ray.johnston@artifex.com>
0222263e4fe03b29e9eb4141f7866fa8261d416a

> Fix tiffsep and tiffsep1 with new file access control and SAFER mode
> The tiffsep and tiffsep1 synthesize output file names with the outputfile
> and the separation color name, but the 'open' of these filenames would
> fail since they were not included on the permit_file_writing list.
> Add the full filename before opening, and remove the names after closing.
> devices/gdevtsep.c

2019-09-20 11:53:10 -0700
Robin Watts <Robin.Watts@artifex.com>
41d79063acee7244f5990d2a8e19c567e24051af

> Squash stupid const warning.
> base/gslibctx.c

2019-09-20 19:42:01 +0100
Robin Watts <Robin.Watts@artifex.com>
b58f45daa9007f482a49132cbfaa47c8b86ce7d5

> Squash some "const" warnings.
> pcl/pl/plmain.c

2019-09-20 17:49:57 +0100
Robin Watts <Robin.Watts@artifex.com>
0e7039d7a83a7e35b8b41d59d7fb9a8b4fda7fb0

> Fix "permit-file-xxxx" handling.
> Ray spotted that gs_add_explicit_control_path was adding 17
> to arg before using it. 17 happens to be the right amount
> to add for "--permit-file-read=", but the wrong amount for
> write/control/all.
> Update the code to call it with the correct arg pointer
> to start with.
> Also, update a couple of routines to cope with being called
> with NULL strings.
> Also use enum values in switch rather than 0, 1, 2.
> base/gslibctx.c
> pcl/pl/plmain.c
> psi/imainarg.c

2019-09-19 11:02:48 +0100
Chris Liddell <chris.liddell@artifex.com>
18316aba11fafc57ee77dbd7774b2c88b964a9d9

> Make missing jbig2 decoder fatal error.
> If we have neither Luratech nor jbig2dec, have configure fail, unless
> explicitly run with --without-jbig2dec
> configure.ac

2019-09-18 09:24:25 +0100
Chris Liddell <chris.liddell@artifex.com>
0557d5d6628279fc526e9d87f05433800ce1b025

> Dates etc for 9.28 rc3
> base/gscdefs.h
> base/version.mak
> doc/DLL.htm
> doc/Deprecated.htm
> doc/Develop.htm
> doc/Devices.htm
> doc/Drivers.htm
> doc/Fonts.htm
> doc/History9.htm
> doc/Install.htm
> doc/Internal.htm
> doc/Language.htm
> doc/Lib.htm
> doc/Make.htm
> doc/News.htm
> doc/Ps-style.htm
> doc/Ps2epsi.htm
> doc/Psfiles.htm
> doc/Readme.htm
> doc/Release.htm
> doc/SavedPages.htm
> doc/Source.htm
> doc/Unix-lpr.htm
> doc/Use.htm
> doc/VectorDevices.htm
> doc/WhatIsGS.htm
> doc/gs-vms.hlp
> doc/sample_downscale_device.htm
> doc/subclass.htm
> doc/thirdparty.htm
> man/dvipdf.1
> man/gs.1
> man/gslp.1
> man/gsnd.1
> man/pdf2dsc.1
> man/pdf2ps.1
> man/pf2afm.1
> man/pfbtopfa.1
> man/printafm.1
> man/ps2ascii.1
> man/ps2epsi.1
> man/ps2pdf.1
> man/ps2pdfwr.1
> man/ps2ps.1

2019-09-17 11:42:13 +0100
Chris Liddell <chris.liddell@artifex.com>
2ff44c7c8a09dd1c6b7cd750323ee4087b5cebc5

> Fix file permissions interaction with '@' command line
> If an options file (prefixed '@' on the command line) followed something that
> required initialising the Postscript interpreter (such as a '-c' option),
> opening the file would potentially fail because file permissions had been
> activated by the interpreter.
> Add and remove the file from the permit reading list before attempting to open
> it.
> base/gsargs.c

2019-09-12 14:23:10 +0100
Chris Liddell <chris.liddell@artifex.com>
3695b7f576c607bd3627e6e28dc982fdf68b1b32

> If set, add PCLFONTSOURCE value to permit_file_reading list
> pcl/pl/pjparse.c

2019-09-11 13:07:02 +0100
Chris Liddell <chris.liddell@artifex.com>
4196e26a9cf3c8afd6c069a789ac649019ae096a

> Bug 701561: 'reduce' paths before adding to permit lists
> Before attempting to open files, we pre-process the requested file name to
> remove surplus/unnecessary elements: i.e. './././file' would be reduced to just
> './file', or '../dir/../dir/../dir/file' would be reduced to '../dir/file'.
> The 'reduced' path is what we try to open, hence it is also what we check
> against the file permissions list before we allow files to be accessed.
> That being so, we should also 'reduce' paths as we add them to the permissions
> lists - thus the permissions list creation and checking are consistent.
> base/gslibctx.c
> base/lib.mak

2019-09-11 14:10:27 -0700
Ray Johnston <ray.johnston@artifex.com>
3d55799ea64088e08fc2783012957035c77a66ca

> Fix Bug 696333. Allow large bitmaps in clist when writing tile cache.
> When writing bits to update the tile cache, we don't need to restrict to
> a single command buffer as with the copy_mono and copy_color commands.
> Progressions on:
> tests_private/comparefiles/Bug694385.pdf.psdcmyk.300.1..gs
> tests_private/pdf/sumatra/2028_-_invisible_patterns.pdf.psdcmyk.300.1..gs
> tests_private/ps/ps3cet/09-47B.PS.pdf.pkmraw.300.0..gs_pdf
> tests_private/ps/ps3fts/176-01.ps.psdcmyk.300.1..gs
> base/gxclbits.c
> base/gxcldev.h
> base/gxclrect.c

2019-09-12 10:37:42 -0700
Ray Johnston <ray.johnston@artifex.com>
1613502f83ddba352cc8e98e7dd3182c9d7732bc

> Fix SEGV with flp device and PCL with clist mode and large BandHeight.
> If the 'clist_init' fails initially (with rangecheck) due to the buffer
> space too small for the BandHeight specified, we loop in the caller after
> increasing the buffer size, but clist_init left "is_open" false when failing.
> Add save_is_open in gdev_prn_setup_as_command_list so that we can restore it
> if the clist_init eventually suceeds.
> The SEGV was with image_data because re-opening the flp device reset the
> "obsolete" procs to the default, so flp_image_data was replaced by the
> gx_default_image_data, but no begin_image had been performed (flp_begin_image
> skipped this since we were not yet at the FirstPage).
> base/gdevprn.c
> base/gxclist.c

2019-09-16 18:53:49 +0200
Sebastian Rasmussen <sebras@gmail.com>
f2d03f59e04a053c14285d8dbdd869bf9a4435e7

> Update jbig2dec stuff for 0.17 release.
> jbig2dec/CHANGES
> jbig2dec/jbig2.h
> jbig2dec/jbig2dec.1

2019-09-16 18:48:36 +0200
Sebastian Rasmussen <sebras@gmail.com>
8da8fbaeb6074161bc3a9b22e89265f5942db0d9

> jbig2dec: Use the same contact information everywhere.
> jbig2dec/README
> jbig2dec/configure.ac.in
> jbig2dec/jbig2dec.1

2019-09-16 16:12:32 +0100
Paul Vojta <vojta@math.berkely.edu>
6c6e19334062d12189612b84f53fe393a7808f74

> Documentation - fix some typos
> Bug #701589 "Minor documentation problems in 9.28-rc2"
> Thanks to Paul Vojta for pointing these out. Unfortunately we cannot use the
> supplied patch, as it includes alterations to History9.htm, which is auto-
> generated from the commit logs. The remaining changes are applied here.
> doc/Language.htm
> doc/Use.htm

2019-09-11 12:18:51 +0100
Chris Liddell <chris.liddell@artifex.com>
90bdf83d696562e4136b8f565cac06cc32b161ae

> Bug 701563: pdfwrite annotation pdfmark /Border key
> Despite the spec saying the values for the /Border key are in user space
> coordinates, Distiller appears to pass the values through to the output PDF
> untouched (no rescaling - unlike the values for /Rect, also in user space,
> according to the spec, which it does scale/translate). Ghostscript/pdfwrite
> did scale the /Border values.
> This just changes pdfwrite to write the values out unchanged.
> devices/vector/gdevpdfm.c

2019-09-16 09:56:52 +0100
Ken Sharp <ken.sharp@artifex.com>
a9e997cb97a274bebfc028e8831a43d6f66be0f9

> Documentation - add a note about SAFER for PDF/X ICC profiles
> Bug #701553 "Examples of PDF/X and PDF/A conversion should be updated for Ghostscript 9.28"
> ICC profiles required for PDF/X and PDF/A output need to be readable
> in order to work when -dSAFER is true (the new default). This wasn't
> clear from the documentation, so add a note about it.
> As noted in the bug report, it is possible to embed the profile in the
> PostScript code, but as Chris says this is probably beyond reasonable
> expectations of the average user; they simply won't change the example
> and will then complain that it isn't correct. Users capable of making
> this work almost certainly have enough knowledge to realise they can
> do this instead of making the profile readable.
> doc/VectorDevices.htm

2019-09-12 19:41:47 +0100
Robin Watts <Robin.Watts@artifex.com>
cea41505580dfe55234bd4972fbb09af5e2e6bb8

> Fix various printer devices to properly call spec ops.
> Various printer devices (psd, psdcmykog, tiffsep, tiffscaled)
> were passing the spec ops on to gx_default_dev_spec_op rather
> than gdev_prn_dev_spec_op.
> The most obvious implication of this was that we'd sometimes
> get a warning about printer devices having a private spec op.
> devices/gdevcmykog.c
> devices/gdevpsd.c
> devices/gdevtsep.c

2019-09-12 17:09:50 +0100
Robin Watts <Robin.Watts@artifex.com>
89f3d6001728678755aca8c5a02e57bba72a0813

> Bug 701568 followup: Fix RLE compressor.
> The previous fix to the RLE compressor reveals an additional
> existing issue to do with us not checking whether we have
> space in the buffer to write the EOD byte.
> Fixed here.
> base/srle.c

2019-09-12 09:35:01 +0100
Robin Watts <Robin.Watts@artifex.com>
f394c0722d3415ba03f57dc32dcd8484d3173b62

> Bug 701568: Fix gdevpx.c RLE stream handling.
> The current code in pclxl_write_image_data_RLE passes
> lines of data to the RLE compression routine. It tells
> each invocation of that routine that this is the "last"
> block of data, when clearly it is not.
> Accordingly, the compression routine inserts the "EOD" byte
> into the stream, and returns EOFC.
> Independently of the return value used, having multiple EOD
> bytes in the data is clearly wrong. Update the caller to only
> pass "last" in for the last block.
> The code still returns EOFC at the end of the data, so update
> this final call to accept (indeed, expect) that return value
> there.
> devices/vector/gdevpx.c

2019-09-10 09:04:46 -0700
Ray Johnston <ray.johnston@artifex.com>
6cd0b941d86fe54b7e818e563dc702a147bab95a

> Fix bug 701550, problem with forall on strings.
> Hard to believe, but this problem has existed since at least version 3.33.
> The 'string_continue' function altered the size which was used to decide if
> there were still characters to be processed BEFORE invoking the 'push(#)' macro.
> If the 'push(1)' encountered a full stack segment, it would return stackoverflow
> so that the operand stack could be extended. This meant that the decision to
> stop enumerating the string would end early (depending on how many times the
> stackoverflow occurred).
> Usually the procedure of the forall would either consume the character (reducing
> the stack), or add an element to the stack triggering the stack extension before
> the next execution of string_continue, but -c "401 string { dup } forall count ="
> results in only 800 stack elements (rather than 802 as expected).
> psi/zgeneric.c

2019-08-15 15:54:04 +0100
Chris Liddell <chris.liddell@artifex.com>
e62f684be3d80bb5599a669ddca3ee1b544100d8

> Doc updates, changelog, news etc
> Update to note explicitly case sensitivity on Windsows
> In News.htm and History9.htm
> doc/History9.htm
> doc/News.htm
> doc/Use.htm

2019-09-05 09:09:38 +0100
Chris Liddell <chris.liddell@artifex.com>
cc86598152465c85dfca5ba265608931672f730f

> Date for 9.28 rc2
> base/gscdefs.h
> base/version.mak
> doc/DLL.htm
> doc/Deprecated.htm
> doc/Develop.htm
> doc/Devices.htm
> doc/Drivers.htm
> doc/Fonts.htm
> doc/History9.htm
> doc/Install.htm
> doc/Internal.htm
> doc/Language.htm
> doc/Lib.htm
> doc/Make.htm
> doc/News.htm
> doc/Ps-style.htm
> doc/Ps2epsi.htm
> doc/Psfiles.htm
> doc/Readme.htm
> doc/Release.htm
> doc/SavedPages.htm
> doc/Source.htm
> doc/Unix-lpr.htm
> doc/Use.htm
> doc/VectorDevices.htm
> doc/WhatIsGS.htm
> doc/gs-vms.hlp
> doc/sample_downscale_device.htm
> doc/subclass.htm
> doc/thirdparty.htm
> man/dvipdf.1
> man/gs.1
> man/gslp.1
> man/gsnd.1
> man/pdf2dsc.1
> man/pdf2ps.1
> man/pf2afm.1
> man/pfbtopfa.1
> man/printafm.1
> man/ps2ascii.1
> man/ps2epsi.1
> man/ps2pdf.1
> man/ps2pdfwr.1
> man/ps2ps.1

2018-10-31 20:22:11 +0100
Sebastian Rasmussen <sebras@gmail.com>
350a5cd8b7bddee3fa914c914dd40a685fed54e7

> Bug 700088: Report error if all wanted J2K components are not decoded.
> Ghostscript used to attempt to use even the undecoded components.
> The source code for upstream's opj_decompress tool avoided this by
> a workaround along with a comment indicating that this ought to be
> done in the library (so all clients, e.g. Ghostscript will benefit
> from it). With this commit the library will error out if not all
> requested components are successfully decoded. Thus Ghostscript
> will no longer crash.
> Reported in https://github.com/uclouvain/openjpeg/issues/1158
> sent upstream in https://github.com/uclouvain/openjpeg/pull/1164
> and finally committed in e66125fe260deee49fdf6e9978d9bd29871dd5bb
> openjpeg/src/bin/jp2/opj_decompress.c
> openjpeg/src/lib/openjp2/j2k.c

2019-09-03 12:34:55 -0700
Michael Vrhel <michael.vrhel@artifex.com>
b944e875baed62e718eee8e7ad2b351cd4f4aa07

> Undo commit 95f7befcec1b30fd5014c8ad616485d32901ce33 for release
> Proper handling of the page group color space is going to require
> a more complex solution whereby we ensure that we do the final
> alpha blending in the page group color space and not the target
> device color space.
> base/gstrans.c

2019-09-03 08:52:16 -0700
Michael Vrhel <michael.vrhel@artifex.com>
ebfe16357f3484209e69d6788cc52b20dbdb81a0

> Add -sBlendColorProfile into Use.htm
> doc/Use.htm

2019-09-03 18:15:56 +0100
Robin Watts <Robin.Watts@artifex.com>
bbdfaa56b00f2ba556476f0265e65e4ad370f641

> Avoid potential UMR with arg checking in arg sanitization code.
> base/gslibctx.c

2019-09-02 17:16:45 +0100
Robin Watts <Robin.Watts@artifex.com>
00d4696ea2de6c48a57d5a4ce0c3bbfd99201e3a

> Proper fix for deep color overprint.
> The previous fix confused memset and memcpy. Properly write the
> (native endian) 16 bit color values into the big endian buffer.
> base/gsovrc.c

2019-09-02 12:59:33 +0100
Robin Watts <Robin.Watts@artifex.com>
c6d448b3fe616fdc2ba1e52766c9a4417e4e738f

> Fix deep color mattes.
> As seen with the content vanishing when rendering
> tests_private/pdf/sumatra/uninitialized_value_with_JPX_images.pdf
> to psdcmyk16. The Softmask on the image has a Matte of [1,1,1]
> and the calculations in the current code overflow, meaning that
> it comes out as completely white.
> We resort to 64bit to avoid the overflow. Mattes are vanishingly
> rare, so speed shouldn't be an issue. We can revisit if we ever
> find a case that matters.
> base/gdevp14.c

2019-08-31 12:45:47 +0100
Robin Watts <Robin.Watts@artifex.com>
4c1f255c2e825ab5e0a3d0f7bfa88538c7cbb912

> Update overprint hl_color code to cope with 16bit devices too.
> base/gsovrc.c

2019-08-31 12:16:40 +0100
Robin Watts <Robin.Watts@artifex.com>
373787ee145e906c8d19d5ccda84b4f267db2010

> Fix deep color transparency overprint.
> The component copy loop at the end of the blend could fail to copy
> enough entries.
> base/gxblend.c

2019-08-30 15:16:34 +0100
Robin Watts <Robin.Watts@artifex.com>
361c4dd1e18ca0675173c0ad0104ffb910e93bb4

> Avoid overflow in deep color luminosity calculations.
> Resort to 64bit as scale calculations are not constrained
> to the usual 16bit range.
> base/gxblend.c

2019-08-29 10:02:49 +0100
Chris Liddell <chris.liddell@artifex.com>
51d57fafbdc021c8c73475db505156f77e96ce39

> Fix clearing of the drag and drop file list
> Because we have to store the list of file names from drag and drop events, in
> order to correctly add and remove them from the permit file read list, we also
> want to clear the lists before we destroy the "text" window object.
> The problem is, this happens after we shutdown Ghostscript and unload the dll.
> This moves that clearing of the list into function that we call before we
> shut down.
> psi/dwmain.c
> psi/dwtext.c
> psi/dwtext.h

2019-08-28 10:14:52 +0100
Chris Liddell <chris.liddell@artifex.com>
ad0532e379a9eb6eb8a6fc0a6305679b25cd9ecb

> Fix path permissions added from cidfmap.
> From the cidfmap, we accumulate a list of unique directory paths a we process
> cidfmap and then add them - when I did that code, I forgot that to allow access
> to the directory, we need a trailing directory separator.
> Add that before calling .addcontrolpath
> Resource/Init/gs_cidfm.ps

2019-08-27 16:49:30 +0100
Chris Liddell <chris.liddell@artifex.com>
f0fedf1f77a9fe70627355b45fdb809e83df3568

> Fix font file finding with -P
> In trying to reproduce the issue that inspired commit dea69cd04964, I noticed
> that font file searching wasn't working correctly with -P specified on the
> command line.
> Previously, it could just end up with us not finding a font we should have, but
> with dea69cd04964 it would result in a typecheck error.
> This ensures the stack is always how it should be after the findlibfile
> call
> Resource/Init/gs_fonts.ps

2019-08-22 16:10:03 +0100
Chris Liddell <chris.liddell@artifex.com>
5c28996d19d5e10cb177e72c47037ec0c7b3e4d5

> Make it clear: file/path matching is always case sensitive
> even on Windows.
> doc/Use.htm

2019-08-29 19:50:08 +0100
Robin Watts <Robin.Watts@artifex.com>
24532ce9371fd1f69dd343cbd6ac8187a86c5c96

> Fix overflow in 16bit blending calculations.
> The blending code uses the following construction in
> several places:
> src_scale = ...; /* a value between 0 and 0x10000 */
> tmp = (y-z) * src_scale + 0x8000;
> foo = x + (tmp>>16);
> Where x,y,z, are all expected to be in the 0...0xffff range.
> Due to y-z having a sign bit, this can overflow a 32 bit tmp.
> We therefore sacrifice a bit of accuracy in src_scale to get
> correctness.
> base/gxblend.c
> base/gxblend1.c

2019-08-28 14:13:27 +0100
Robin Watts <Robin.Watts@artifex.com>
ca52028b90a09d056190548c41ae0b9a9fbadb4e

> Remove outdated FIXME's.
> base/gdevp14.c

2019-08-28 12:50:36 +0100
Robin Watts <Robin.Watts@artifex.com>
bd59dc145252282d8f586c36082e63a0eba95c15

> Bug 701446: Avoid divide by zero in shading.
> The previous commit for this bug was enough to solve the problem
> for ppmraw, but not, it seems, for other devices. This addresses
> the division by zero more directly.
> base/gxshade6.c

2019-08-27 20:13:02 +0100
Robin Watts <Robin.Watts@artifex.com>
9a32a379933f4ba27ff1ad5734ec8c24c42eb513

> Fix deep color transparency saturation blending.
> Problem seen with:
> tests_private/pdf/PDF_1.7_FTS/fts_25_2513.pdf.psdcmyk16.300.1
> base/gxblend.c

2019-08-27 17:45:57 +0100
Robin Watts <Robin.Watts@artifex.com>
68af4dbc7ca2d6bfdbe938b840799cb8883c973e

> Bug 701446: Avoid division by zero in gx_shade_trapezoid
> Remove some incorrect clipping code.
> base/gxshade6.c

2019-08-27 15:54:36 +0100
Robin Watts <Robin.Watts@artifex.com>
4be058791ae19131f19a8303364be53619abc280

> Exit early from gx_shade_trapezoid in more cases.
> A zero height trap isn't plotted, so we can bail out early in
> that case.
> base/gxshade6.c

2019-08-26 17:02:03 +0100
Robin Watts <Robin.Watts@artifex.com>
9423e84178071f16b83d18412b22b0b479b1938b

> Fix deep colour transparency "uncompositing".
> Uncompositing a group uses a scale factor that is greater in range
> than we'd like; we need to resort to 64bit to do this to avoid
> losing accuracy.
> This solves problems seen in:
> tests_private/comparefiles/Bug689918.pdf.psdcmyk16.300.1
> base/gxblend.c

2019-08-27 14:26:41 +0100
Chris Liddell <chris.liddell@artifex.com>
131768114453972469296658b795406b79630538

> Handle relative FONTPATH values
> Prior to 9.21 (specifically: 8abd22010eb4db0fb1b10e430d5f5d83e015ef70), relative
> paths for FONTPATH worked, but did so due to a logic fault with how we search
> for "lib" files.
> When attempting to open file names specified on the command line, we used a
> flag set in the command line handling (starting_arg_file) to know whether the
> lib file searching logic should try to open the file name directly (as well as
> trying the file combined with each path in the search path).
> In versions prior to commit 8abd22010eb4 that flag (starting_arg_file) could
> remain set to true, even after the command line file(s) had been opened. This
> represented a (minor) security risk. Commit 8abd22010eb4 ensured the flag was
> properly (re)set, and that caused relative paths for FONTPATH stopped working.
> Rather than reintroduce the security risk, update the code that checks whether
> the font files exist so it explicitly tries the file name directly, rather than
> assuming .libfile (or findlibfile, in this case) does that automatically.
> Also remove an extraneous (but benign) dup of the font name.
> Resource/Init/gs_fonts.ps

2019-08-27 15:27:05 +0100
Ken Sharp <ken.sharp@artifex.com>
98310063bdbe8c67bcfe84e2c648cfa286a05738

> pdfwrite - fix corner case with Color Conversion
> Bug #701456 "Ghostscript creates broken PDF file after color conversion"
> The test file is, essentially weird. The image on page 3 is not a single
> image, its a series of images, all of which are in a /Indexed /DeviceRGB
> colour space.
> In addition, these images are drawn on *top* of another set of images
> (thereby completely obscuring them). These images are also drawn in
> /Indexed /DeviceRGB. However, these images are in fact monochrome, the
> Indexed space consists of 2 colours. This means that (highly unusually)
> we have a DeviceRGB image with 1 Bit Per Component.
> This caused problems for the pdfwrite compression filter chooser because
> it chose (and configured) a compression scheme suitable for 1 BPC data
> and then actually output 8 BPC data. This led to the compression filter
> writing too little data.
> Fix this here by setting the BPC to 8 if we are doing colour conversion,
> and have the colour conversion setup code use the original value in the
> image enumerator (the conversion code *does* need to know the input is
> 1 BPC).
> devices/vector/gdevpdfi.c

2019-08-27 11:36:35 +0100
Ken Sharp <ken.sharp@artifex.com>
aee3b922087674ddd7c64444988018fafc3da127

> PDF interpreter - more /Mask strangeness in Acrobat
> Bug #701468 " More weirdness with images containing invalid /Mask values"
> In order to render this file as per Acrobat, we need to ignore the /Mask
> array. However, in order to render bug 689717 correctly we need to fix
> the /Mask array.
> Both cases are 1 BitsPerComponent DeviceGray images, the only difference
> is the actual /Mask values. Bug 689717 has [255 255] while 701468 has
> [243 255]. We can differentiate based on whether we have DeviceGray
> 1 BPC image, where the Mask values are not the same. In the case they
> are different we use the existing technique of calculating the maximum
> value and using that (for both, so there is no range). Where there is a
> range (ie not a single colour) this is clearly unusable in a 2-colour
> image, so ignore the /Mask altogether.
> Resource/Init/pdf_draw.ps

2019-08-26 15:28:33 +0100
Robin Watts <Robin.Watts@artifex.com>
ad22dcaa078fd16f2ac395f65b6ad87ba24c8903

> Fix deep colour knockout logic.
> Problem seen with:
> tests_private/pdf/PDF_1.7_FTS/fts_25_2507.pdf.psdcmyk16.72.0
> base/gxblend.c

2019-08-26 14:34:46 +0100
Robin Watts <Robin.Watts@artifex.com>
4cda7bfc8cc8c5c4dcd36167191012aa379100ac

> Squash a couple of warnings.
> base/gdevmem.c
> base/gdevp14.c

2019-08-26 14:01:39 +0100
Robin Watts <Robin.Watts@artifex.com>
7b5166b5c65703abb02c15a31c9f8341f54d1470

> Fix SoftLight blending in deep color transparency.
> As seen with:
> gs -sDEVICE=psdcmyk16 -r72 -dMaxBitmap=80000000 -o out.psd
> tests_private/pdf/PDF_1.7_FTS/fts_09_0919.pdf
> base/gxblend.c

2019-08-26 11:28:40 +0100
Robin Watts <Robin.Watts@artifex.com>
5875be5edeb034787a11760c9330cac039f13044

> Fix problems with pngalpha and deep color transparency filling.
> The pngalpha device is created with a depth of 32, with 3 color
> components; this was confusing pdf14 into thinking that more
> than 8 bits per color were being used, and so deep color buffers
> were required.
> To fix this we update the logic to be smarter; in cases where we
> don't have a clear determination based on bits alone, we look
> at the max_color and max_gray values. Because this code is now
> more complex than before, we pull it into a shared function.
> base/gdevdflt.c
> base/gdevmem.c
> base/gdevp14.c
> base/gdevprn.c
> base/gsptype1.c
> base/gstrans.c
> base/gxclthrd.c
> base/gxdevcli.h

2019-08-23 15:06:17 +0100
Robin Watts <Robin.Watts@artifex.com>
6e7283fa5bcea9ffbe4bb9da440dd8fa4820e4d6

> Fix deep color transparency issue.
> Fix overflow in art_pdf_composite_knockout_16, seen in:
> tests_private/comparefiles/Bug690546.pdf.psdcmyk16.72.0
> base/gdevp14.c
> base/gxblend.c

2019-08-22 18:24:49 +0100
Robin Watts <Robin.Watts@artifex.com>
628c9741323ea69b0be8e4008a81b1db3d644ab8

> Fix deep color transparent pattern problems.
> Transparency buffers are held as native endian. Pattern cache
> tiles are held as big endian. When we make pattern cache tiles
> from transparency buffers we therefore need a conversion.
> base/gdevp14.c
> base/gxblend.c
> base/gxp1fill.c
> base/gxpcolor.h

2019-08-25 19:35:14 +0200
Till Kamppeter <till.kamppeter@gmail.com>
be4da9d67cbec784be740086681f96a63496ae48

> "cups"/"pwgraster" output device: Do not output LUTs with CUPS_DEBUG set
> This change lets complete LUTs in the debug output only be listed when
> CUPS_DEBUG2 is set and not already with CUPS_DEBUG.
> cups/gdevcups.c

2019-08-25 19:08:52 +0200
Till Kamppeter <till.kamppeter@gmail.com>
0e28c843e56d1be4638bf9d84a499794534ea0d9

> "cups"/"pwgraster" output device: Prefer the page size requested by user
> Without special scaling/cropping options ("fit-to-page", "fill",
> "crop-to-fit΅, ...) PDF and PostScript files printed with CUPS will be
> printed with the page sizes of the document's pages and not the size
> requested by the user via the "PageSize" or "media" option. This
> allows correct printing of jobs with differently sized pages on
> printers which have the appropriate sizes loaded without need of
> manual intervention. Therefore the CUPS output device is matching each
> input page against the sizes listed in the PPD to generate a correct
> page geometry for the printer for each page.
> Problem is if there are several equally-sized page size entries in the
> PPD. Without further guiding always the first match is used, making
> access to special functions provided by the others (like
> full-bleed/borderless printing) inaccessible.
> This commit adds the functionality of the user-requested page size
> (via "PageSize" or "media" option) being preferred under the matching
> page sizes, so that if for example a user selects a full-bleed version
> of the desired page size and sends a photo, the photo gets rendered
> and printed with the page geometry which the PPD reports for the
> full-bleed version.
> Nothing changes if the size of the user-requested page size does not
> match the size of the input page at all.
> cups/gdevcups.c

2019-08-25 12:45:27 +0200
Till Kamppeter <till.kamppeter@gmail.com>
a5ccd009fd632e058b4f0bc2849cfc293b39d1f2

> "cups"/"pwgraster" output device: Small fix on size matching improvements
> This is a fix for one little oversight on the changes to support matching
> the input page size against the imageable areas of the PPD's page sizes.
> This completes the fix of bug 701438.
> cups/gdevcups.c

2019-08-24 23:11:10 +0200
Till Kamppeter <till.kamppeter@gmail.com>
a0284b5ac8c59014eab90c5a5ec388cd1676b79d

> "cups"/"pwgraster" output device: Improved page size matching with PPD
> Applied the following improvements for finding the correct page size
> of the PPD file for the input page:
> - Do not try to match by page size name, the input files do not
> contain page size names.
> - Do not only match the input page size against the actual media sizes
> reported by the PPD but also to the imageable areas. Media size match
> is preferred but if there is no media size match, we accept also
> a match of the imageable area. In case of a match of the imageable
> area we position the input page in the imageable area of the output
> page.
> - More debug output.
> - In case of a custom page size (no match with PPD sizes) the page
> size name in the CUPS Raster output is a correct "Custom.XXXxYYY"
> and not the default page size name.
> This should fix bug #701438.
> cups/gdevcups.c

2019-08-23 18:09:32 +0200
Till Kamppeter <till.kamppeter@gmail.com>
ee43ff891b51f0ccec3ba38d538d3e23441ed439

> "cups"/"pwgraster" output device: Reduced page size comparison tolerances
> Before each page gets rendered its size is compared to the page sizes
> of the PPD file to select the actual page size for the output. Reduced
> the tolerances from 7% for the long edge and 5% for the short edge to
> 1%, as before easily wrong sizes got picked (See also bug 701438).
> cups/gdevcups.c

2019-08-23 10:11:05 +0100
Chris Liddell <chris.liddell@artifex.com>
0311b61d5df67cd98e2c2d23ef3cec1cc4faa800

> Windows Installer: cope with COMPILE_INITS=0
> We default to COMPILE_INITS=1, and that was the only case that the installer
> handled - i.e. building the installer with COMPILE_INITS=0 would install an
> executable that wouldn't work without extra action (-I.. or similar).
> This changes the installer compiler invocation, and the installer creation
> so it behaves as it does now with COMPILE_INITS=1, but with COMPILE_INITS=0 the
> installer will write the path to Resource/Init into the GS_LIB registry
> key.
> psi/nsisinst.nsi
> psi/winint.mak

2019-08-22 23:30:34 +0200
Till Kamppeter <till.kamppeter@gmail.com>
137a0bda39f861600488b5a11c63914854c454c8

> "cups"/"pwgraster" output device: Produce more debug output
> When building with CUPS_DEBUG now debug output for the process of
> matching the page geometry with the PPD file's page sizes is
> produced.
> cups/gdevcups.c

2019-08-22 08:58:01 +0100
Chris Liddell <chris.liddell@artifex.com>
09b53ebdc674f9f6e7a9c445e92617312dd93ab3

> Handle explicit '\' escaping in path matching
> As well as having to cope with both '/' and '\' as directory separators on
> Windows, it turns out we also need to cope with the backslash separator being
> explicitly escaped ("\\") - the explicit is added by the Postcript path
> templating code in gs_init.ps.
> I don't want to change templating code because that would likely have
> implications in a lot of other places.
> base/gpmisc.c

2019-08-22 10:51:28 +0100
Robin Watts <Robin.Watts@artifex.com>
f1692a288f1a17930f0b71e540908398a17d5366

> Better CMYK conversion for bmpcmp
> toolbin/bmpcmp.c
> toolbin/bmpcmptab.h

2019-08-21 17:49:32 +0100
Robin Watts <Robin.Watts@artifex.com>
c8aaf3b7bc4232997d434170827fffd6887fc88f

> Update bmpcmp.c to read psdrgb rather than psdbgr.
> toolbin/bmpcmp.c

2019-08-21 15:33:27 +0100
Chris Liddell <chris.liddell@artifex.com>
9ba1827e220cd49a6732c04fcf3e55a268014377

> Fix commit ec0b35fed3de: "Handle directory separators..."
> The logic in the above fix was wrong.
> base/gpmisc.c

2019-08-21 14:28:20 +0100
Robin Watts <Robin.Watts@artifex.com>
7d0206d2b118b26f6d87ba8f09d077eba417e4c9

> Bug 701451: Fix clist color_usage calculations for shadings.
> Or rather, don't attempt to calculate them badly, and just
> use the safe "all colors" value.
> base/gxclrect.c

2019-08-21 10:10:51 +0100
Ken Sharp <ken.sharp@artifex.com>
320ec9672b987a765324f89450de08b70aafbcd3

> PDF interpreter - review .forceput security
> Bug #701450 "Safer Mode Bypass by .forceput Exposure in .pdfexectoken"
> By abusing the error handler it was possible to get the PDFDEBUG portion
> of .pdfexectoken, which uses .forceput left readable.
> Add an executeonly appropriately to make sure that clause isn't readable
> no mstter what.
> Review all the uses of .forceput searching for similar cases, add
> executeonly as required to secure those. All cases in the PostScript
> support files seem to be covered already.
> Resource/Init/pdf_base.ps
> Resource/Init/pdf_draw.ps
> Resource/Init/pdf_font.ps
> Resource/Init/pdf_main.ps
> Resource/Init/pdf_ops.ps

2019-08-21 10:56:02 +0100
Chris Liddell <chris.liddell@artifex.com>
e5660f15f5fd4615254acec7ed403b4a7984cb09

> Handle directory separators in access control matching
> On Windows, we end up dealing with a mishmash of "/" and "\" as directory
> separators, so a simple equality check isn't sufficient.
> Since there is already (platform specific) function for checking whether a
> string (or part thereof) is a directory separation, use it.
> base/gpmisc.c

2019-08-20 21:50:18 -0700
Michael Vrhel <michael.vrhel@artifex.com>
596e9baa1b24b0a9dac4d8bad1ea80cd23dcab79

> Disable use of alternate tint transform ICC profile
> A prior commit introduced the use of color management
> if the DeviceN or Separation device had an ICC profile
> associated with the colorants. While there is an argument
> for doing this, it is not the standard behavior seen in
> AR. Disabling for now and will likely turn this into a
> command line option.
> base/gxcmap.c

2019-08-20 18:48:49 +0100
Robin Watts <Robin.Watts@artifex.com>
7547a2fc593e3a0bb8ea72f661389cd908c382f7

> Fix crashes in RAW_DUMP debug code.
> Dump the buffer before freeing the device, or the pointer will no
> longer be valid.
> Also, don't access through ppatdev14 when we know it's NULL.
> base/gdevp14.c

2019-08-20 18:47:09 +0100
Robin Watts <Robin.Watts@artifex.com>
421727ed068b3f41fdbd9657d759397610fe8821

> Fix deep color transparency pattern copying problem.
> The following test:
> tests/pdf/pattrans_solid_nonrect.pdf.psdcmyk16.300.1..gs
> among others, was showing problems, due to us treating the offset
> as bytes rather than shorts.
> base/gxp1fill.c

2019-08-20 14:29:33 +0100
Robin Watts <Robin.Watts@artifex.com>
f9052f1debff2168d5a2606fa35bcaaf6f6f2ec7

> Avoid signed overflow in deep transparency calculations.
> base/gxblend.c

2019-08-20 12:24:03 +0100
Robin Watts <Robin.Watts@artifex.com>
898c9e5f06bb44ec3fd262b47eeaa5028e18773f

> Fix overflow in deep color blending.
> Multiplying a 16bit unsigned value with a 16 bit signed value
> in a 32bit int means we lose the sign bit. Sacrifice a bit of
> accuracy to avoid that.
> base/gxblend.c

2019-08-20 10:10:28 +0100
Ken Sharp <ken.sharp@artifex.com>
85c9d6de80ba57deeee289238aa1c0202f584c3c

> make .forceput inaccessible
> Bug #701343, #701344, #701345
> More defensive programming. We don't want people to access .forecput
> even though it is no longer sufficient to bypass SAFER. The exploit
> in #701343 didn't work anyway because of earlier work to stop the error
> handler being used, but nevertheless, prevent access to .forceput from
> .setuserparams2.
> Resource/Init/gs_lev2.ps
> Resource/Init/gs_pdfwr.ps

2019-08-19 10:03:57 +0100
Chris Liddell <chris.liddell@artifex.com>
3ba6d871c70398cfbd15b619127bf13ddea13282

> Handle drag'n'drop file name/paths
> Because we now run by default with the file access permission active,
> we need to do additional work for Windows drag and drop files, so they don't
> throw an invalidaccess error (since we implement drag and drop by sending
> characters to the gs console to do '(file) run').
> The problem is, we cannot add the file to read list, send the characters to the
> console, and remove the file from the read list because, although SendMessage()
> blocks until the message is handles, WriteConsoleInput() does not block until
> the console buffers are consumed (i.e. it is asynchronous). So, there is no
> certainty when the final SendMessage() in WM_DROPFILES case is finished that
> Ghostcript will actually have run the file.
> So, we create a list of dropped file names, add them to the permit read list,
> when the next WM_DROPFILES event happens, or a WM_DESTROY event, we drop
> file names from the permit read list before, if necessary, adding the current
> ones.
> psi/dwimg.c
> psi/dwmain.c
> psi/dwmainc.c
> psi/dwtext.c
> psi/dwtext.h

2019-08-16 15:43:32 +0100
Robin Watts <Robin.Watts@artifex.com>
d2e36e8ef01546aaee0cd0531fbc0fa932b23b99

> Squash warnings in claptrap.
> Thanks to William Bader for highlighting these.
> base/claptrap-planar.c

2019-08-16 15:28:49 +0100
Robin Watts <Robin.Watts@artifex.com>
e34d5606835fc587e222b80bf9cac1bc40c4790b

> Squash warning in gdevpsd.c
> Thanks to William Bader for spotting this.
> devices/gdevpsd.c

2019-08-16 13:08:14 +0100
Robin Watts <Robin.Watts@artifex.com>
f416b415e8e3a25446b66bf1a6253f86be0366de

> Squash some compiler warnings.
> base/gslibctx.c
> base/gslibctx.h
> devices/gdevpdfimg.c
> devices/vector/gdevpdfu.c
> pcl/pl/plmain.c

2019-08-15 11:39:51 +0100
Chris Liddell <chris.liddell@artifex.com>
9ead927968ff8104e1a81df1590fced74927639d

> Dates and versions for 9.28 RC 1
> base/gscdefs.h
> doc/DLL.htm
> doc/Deprecated.htm
> doc/Develop.htm
> doc/Devices.htm
> doc/Drivers.htm
> doc/Fonts.htm
> doc/History9.htm
> doc/Install.htm
> doc/Internal.htm
> doc/Language.htm
> doc/Lib.htm
> doc/Make.htm
> doc/News.htm
> doc/Ps-style.htm
> doc/Ps2epsi.htm
> doc/Psfiles.htm
> doc/Readme.htm
> doc/Release.htm
> doc/SavedPages.htm
> doc/Source.htm
> doc/Unix-lpr.htm
> doc/Use.htm
> doc/VectorDevices.htm
> doc/WhatIsGS.htm
> doc/gs-vms.hlp
> doc/sample_downscale_device.htm
> doc/subclass.htm
> doc/thirdparty.htm
> man/dvipdf.1
> man/gs.1
> man/gslp.1
> man/gsnd.1
> man/pdf2dsc.1
> man/pdf2ps.1
> man/pf2afm.1
> man/pfbtopfa.1
> man/printafm.1
> man/ps2ascii.1
> man/ps2epsi.1
> man/ps2pdf.1
> man/ps2pdfwr.1
> man/ps2ps.1

2019-08-15 11:35:56 +0100
Chris Liddell <chris.liddell@artifex.com>
ae7dea2b9bd068f61b6aef312a7f4cbc9860cac3

> Revision date
> base/version.mak

2019-08-15 17:06:02 +0100
Chris Liddell <chris.liddell@artifex.com>
2f8e2423c860e89b325675dc1311819179740c76

> Add -dNOSAFER for Windows installer cidfmap creation
> psi/nsisinst.nsi

2019-08-15 14:36:55 +0100
Ken Sharp <ken.sharp@artifex.com>
226fb24dbe4f844b8c7531be3eccc2bfae1a103d

> ps2write - don't password encrypt PostScript output!
> Noticed while testing the args commit; if we set -sOwnerPassword (to
> create a password-protected PDF file), but select (e)ps2write as the
> device, then the resulting PostScript file would have all the streams
> (in a PDF sense) encrypted with PDF password encryption.
> Unsurprisingly, this result in a completely unusable PostScript file.
> Lets not permit that....
> devices/vector/gdevpdfp.c

2019-08-13 14:43:51 +0100
Chris Liddell <chris.liddell@artifex.com>
fd14a8e3701a7f75d758a1e536bcafbddeb70289

> Document the new SAFER/file access controls
> The documentation for the old SAFER remains in place (noted as deprecated) until
> we actually remove it. Document accessing the old SAFER functionality
> (-dOLDSAFER).
> Generally, tidy up the HTML/formatting of the parameter and operator lists
> in Use.htm and Language.htm - mainly making indenting even and consistent.
> List .setpdfwrite as deprecated
> Include setting the target of the first parameter of gsapi_new_instance() to
> NULL before calling it, and fix the examples in API.htm
> doc/API.htm
> doc/Language.htm
> doc/Use.htm
> doc/VectorDevices.htm
> doc/style.css

2019-08-13 14:40:45 +0100
Chris Liddell <chris.liddell@artifex.com>
79a06b45e784e6839b2b2129cd2620ea606254e1

> Enable new 'SAFER' protection by default.
> We'll now run by default with file access controls enabled. SAFER (and
> .setsafe) now *only* enables file access controls. The old SAFER functionality
> is (temporarily) available by specifying "-dSAFER -dOLDSAFER" on the command
> line, or "-dOLDSAFER" before the call to .setsafe.
> Resource/Init/gs_init.ps

2019-08-13 08:28:06 +0100
Chris Liddell <chris.liddell@artifex.com>
9883f2a931407503778bb94948b47480eff858b2

> Add null file to the permit writing list
> base/gslibctx.c

2019-08-12 12:21:50 +0100
Chris Liddell <chris.liddell@artifex.com>
7abf720f46dd9ff6018b7f29141ba0573016d59d

> Use enum values for shutting down the file access lists
> base/gslibctx.c

2019-08-09 14:43:17 +0100
Chris Liddell <chris.liddell@artifex.com>
d86ecec686d77e69f7c4a10df9da8c4cd8336a03

> Tweak to better handle undefined transparency ops
> examples/transparency_example.ps

2019-08-08 10:46:39 +0100
Chris Liddell <chris.liddell@artifex.com>
7ca1bb5794997e0dba059a5be6f85a9eaefc915d

> Fix gs_add_explicit_control_path()
> it was always adding to the "read" list, rather than the list requested by the
> parameter.
> base/gslibctx.c

2019-08-08 10:33:18 +0100
Chris Liddell <chris.liddell@artifex.com>
34dac4d2a1b195536fcb9d796168cd1360c0e500

> Don't bind and undefine .copytree
> .copytree is a Postscript proc that calls itself recursively, hence we cannot
> bind it nor undefine it.
> Resource/Init/gs_setpd.ps

2019-08-06 09:32:32 +0100
Chris Liddell <chris.liddell@artifex.com>
4d53f6ee868205c76950027e76a27f0278513a39

> Tweak the interaction of file permissions and -I
> The new file permissions code differentiates between 'path', 'path/' and
> 'path/*', whilst the old -I code did not.
> This slightly modifies how the -I stuff drives the file permissions stuff so it
> works (more) like the previous -I behaviour.
> The remaining difference is that the new code always treats '*' as a wildcard,
> where the old code would permit '*' as a 'real' character in a path.
> Resource/Init/gs_init.ps

2019-08-15 09:52:04 +0100
Ken Sharp <ken.sharp@artifex.com>
00af0eb11b82c4dfddbe91bcb70caed2e61a1cc8

> pdfwrite/ps2write/pdfimage - record args used
> Following on from commit 813d7e96c8733f85d59a62732171cf7cedfc087d this
> adds functionality to the pdfwrite and pdfimage families of devices to
> actually write the args that were used to generate the output file into
> the final output file, as comments.
> Output files are somewhat larger with this commit, but only very small
> files are in any way significantly larger. We do have a number of such
> files in our test suite which exhibit larger output ( > 5%increase).
> devices/gdevpdfimg.c
> devices/vector/gdevpdf.c
> devices/vector/gdevpdfu.c
> devices/vector/gdevpdfx.h

2019-08-12 16:30:46 +0100
Robin Watts <Robin.Watts@artifex.com>
813d7e96c8733f85d59a62732171cf7cedfc087d

> Capture args to feed to pdfwrite.
> To facilitate debugging, we want a way to pickle the gs invocation
> used into device output (for devices that want it).
> We therefore amend the argument processing logic to pass arguments
> to gs_lib_ctx, where they will are 'sanitized' and stored in a list.
> This list can then be accessed by a device.
> We are careful to sanitize the args so as not to reveal paths or
> secret passwords/code etc. Essentially we never store any filenames
> or string values stored (except for certain whitelisted -s options).
> It is likely that we'll want to expand the whitelisted values in
> future.
> base/gsargs.c
> base/gsargs.h
> base/gslibctx.c
> base/gslibctx.h
> pcl/pl/plmain.c
> psi/imainarg.c

2019-08-14 16:47:36 +0100
Robin Watts <Robin.Watts@artifex.com>
8ba95fb06387572160fee5e4c1e51d972401566e

> Fix gs_lib_ctx memory calls to use the correct memory pointer.
> base/gslibctx.c

2019-08-14 08:03:45 -0700
Ray Johnston <ray.johnston@artifex.com>
ddddd71785d058b036775566d36d6848c9817f80

> Fix -F____ and -f____ to actually run the file ____.
> Commit 7ecbfda9 broke -F completely since it requires the file to run to
> immediately follow the switch, and -f____ use to run the file, but since
> gs_add_control_path returns 0 as long as there was no error, the code
> never called argproc. Also, argproc already does the add_control_path
> and remove_control_path, so simplify -f and -F code.
> Also gs_add_outputfile_control_path was ignoring the return code when
> adding the full pipe string as a path, so fix it.
> Note that plmain ignores the return code from gs_remove_control_path,
> but that should be OK.
> base/gslibctx.c
> psi/imainarg.c

2019-08-12 13:53:29 +0100
Robin Watts <Robin.Watts@artifex.com>
3eb2b1337260a17274588d377032e1f9953062fd

> Squash double -> int warning message with explicit cast.
> base/gxblend.c

2019-08-13 11:54:36 +0100
Robin Watts <Robin.Watts@artifex.com>
8b5af0e2db28be36d96de97eb1a145d5716ffea3

> Tweak lcms to optimise the pipeline before consulting plugins.
> This allows us to recognise identity transforms before selecting
> one of our optimised lookup functions. Firstly, however optimised
> our code is, we aren't going to beat the identity code. Secondly,
> lcms doesn't calculate the tables for identity transforms, so
> our code can fall in a heap here.
> lcms2mt/src/cmsxform.c

2019-08-13 16:05:37 +0100
Ken Sharp <ken.sharp@artifex.com>
15d95340389f0f46bd214803ec19685c0a738a0e

> Deprecate .setpdfwrite
> The .setpdfwrite operator nowadays does nothing more than increase the
> VM threshold, which is relatively pointless so we're going to remove it.
> In this commit; add a warning message to the .setpdfwrite operator so
> that anyone using it will be warned. Remove usage from the various
> shell scripts we provide.
> Resource/Init/gs_pdfwr.ps
> lib/dvipdf
> lib/ps2pdfwr
> lib/ps2pdfxx.bat

2019-08-12 16:06:21 +0100
Ken Sharp <ken.sharp@artifex.com>
8cc13d54850af14a07e72f73cca20e96ed01fd03

> PDF interpreter - ignore visibility of annotations for devices which support them
> No bug for this, arose from a Stack Overflow question, but its a FAQ
> as well.
> It used to be the case that the PDF interpreter would (and should)
> render files containing annotations with the Print and NoView flags
> differently, depending on whether the destination was to be rendered
> or sent to a high level device. This is controlled with the -dPrinted
> flag to determine whether annotations should be treated as for a Print
> device or a View device.
> This doesn't make a lot of sense for pdfwrite though. We really want to
> keep the Annotation 'as is' and let the viewer or printer of the output
> PDF file deal with it.
> In the past we've moved the annotation handling for pdfwrite and,
> technically, for any device which directly supports annotations from
> 'drawannot' to 'preserveannot'. Now that we've done that, it makes some
> sense to have the 'preserveannot' code no longer check the annotation's
> visibility, but simply preserve it as you would expect. NOTE we do check
> the visibility state of annotations that we don't know how to handle.
> These will not be preserved as annotations, but will be drawn into the
> page contents, so we don't want to render any which should be invisible.
> Such annotations are still affected by -dPritned.
> Resource/Init/pdf_draw.ps

2019-08-09 15:57:54 +0100
Ken Sharp <ken.sharp@artifex.com>
368bc91bf0bba66f31204e1ee57da7c9b70b32bb

> pdfwrite - fix a minor error
> I don't think this causes any actual problems, but the correct return
> should be 0, not an error, when we can't find a Pattern resource.
> devices/vector/gdevpdfi.c

2019-08-09 15:56:45 +0100
Ken Sharp <ken.sharp@artifex.com>
9a871de445eaed295748a3b489e138e87b9e0b65

> Transparency compositor - forward unhandled special_ops to target device
> Noticed while doing earlier work. The pdf14 device only passed on a few
> specific gxdso_ special_op types to the target device, the remainder
> were sent to the default handler. This seems wrong and caused problems
> for my new gxdso at the time. Instead of it going through the pdf14
> device and ending up at pdfwrite (or the default handler for other
> devices) it was always going to the default handler and never making
> it to pdfwrite when rendering transparency.
> The pdf14 device should instead handle any gxdso_ special_ops that vary
> depending on rendering. For instance the JPEG passthrough should *not*
> be passed to the target device, the pdf14 device needs to have the
> uncompressed image data to render it to the compositor buffer.
> This commit adds handlers for such gxdso_ special ops, and passes all
> the remaining unhandled ones to the target device for processing.
> For some reason this causes diffs in halftones, I have no idea why. but
> they don't seem like problems.
> base/gdevp14.c
> base/gxdevsop.h

2019-08-09 17:14:42 +0100
Chris Liddell <chris.liddell@artifex.com>
1ca2c331684ca2912c431771d1aac8bc5cb42e76

> Fix line endings (file had some '\r' line endings).
> Resource/Init/pdf_draw.ps

2019-08-08 09:07:09 +0100
Ken Sharp <ken.sharp@artifex.com>
e9e253e1dbc87d6ef772936130076e1ba3b81867

> pdfwrite - don't permit fallback font substitution with PDF/A
> Bug #701373 "PDFA fails to validate by Preflight"
> The inptu is a PDF file which is missing two fonts, Helvetica and
> Calibri. For both fonts we use /Helvetica as a substitute. For the
> missing Helvetica font this is correct, but for the missing Calibri font
> this leads to problem when creating PDF/A otuput files.
> Firstly, we now have two different fonts, with differing /Widths which
> are potentially attempting to reference the same glyphs from a single
> font. Secondly, no matter what we do, the /Widths from the Calibri font
> are not going to match the actual glyph metrics from Helvetica.
> Since there is no possible way to deal with the second problem, because
> either the metrics won't match the /Widths, or the text will be misplaced
> if we use Widths that are not those from Calibri, there is no point in
> trying to tackle the first problem.
> So here we introduce a new special_op 'EventInfo' which passes a single
> name to the device. The name is the name of the event which occurred. For
> now this can only be 'SubstitutedFont'. The only device which handles
> this event is pdfwrite, all other devices simply ignore it. The pdfwrite
> device checks to see if it is creating a PDF/A otuptu file, and if it is
> then it emits a warnign and aborts the production of PDF/A.
> Resource/Init/pdf_font.ps
> base/gdevdflt.c
> base/gdevp14.c
> base/gxdevsop.h
> devices/vector/gdevpdfi.c
> psi/zdevice.c

2019-06-14 16:52:28 -0700
Michael Vrhel <michael.vrhel@artifex.com>
009d44b855dcda9d0d9ecf5ca20944504648eebe

> CompatibleOverprint Mode
> Ray did the interpreter work on this and Michael did the graphics
> library portion.
> For the interpreter:
> When OP is set, change to CompatibleOverprint mode, but don't push a
> transparency group or change opacityalpha when the current blendmode
> is Normal or Compatible. This was determined based on the note on page
> 568 of the PDF 1.7 spec (section 7.6.3 in the area titled "Compatibility
> with Opaque Printing"). It states:
> Note: It is not necessary to create such an implicit transparency
> group if the current blend mode is Normal; simply substituting
> the CompatibleOverprint blend mode while painting the object
> produces equivalent results. There are some additional cases in
> which the implicit transparency group can be optimized out.
> After painting, if the group was pushed, pop the group, and restore the
> opacityalpha and shapealpha,then restore the blendmode (if it was
> CompatibleOverprint).
> NB, we don't attempt to optimize any other groups hinted at in
> Adobe's comment.
> In addition, if we are going to an output device that handles transparency
> compositor actions do not do any of the above stuff.
> For the graphics library:
> When doing blending in non-isolated groups with compatible overprint
> the non-drawn colors must be corrected during the fill rectangles to
> ensure that the proper amount is maintained with the changing group
> alpha values. This is poorly documented in the specification.
> In addition, the spec is poorly written in terms of how the blend
> computation is performed for overprint compatible.
> The spec claims the following:
> If the overprint mode is 1 (nonzero overprint mode) and the
> current color space and group color space are both DeviceCMYK,
> then only process color components with nonzero values replace
> the corresponding component values of the backdrop. All other
> component values leave the existing backdrop value unchanged.
> That is, the value of the blend function B(Cb,Cs) is the source
> component cs for any process (DeviceCMYK) color component whose
> (subtractive) color value is nonzero; otherwise it is the
> backdrop component cb. For spot color components, the value is
> always cb.
> The equation for compositing is
> ar*Cr = (1-as)*Cb + as*[(1-ab)*Cs+ab*B(Cb,Cs)]
> Now if I simply set B(cb,cs) to cb for the case when the
> DevieCMYK value (with opm true) is zero I get
> ar*Cr = (1-as)*Cb + as*[(1-ab)*Cs+ab*Cb]
> But what I am seeing with AR is
> ar*Cr = (1-as)*Cb + as*[(1-ab)*Cb+ab*Cb] = (1-as)*Cb + as*Cb = Cb
> which is what I think we want.
> The description in the spec is confusing as it says
> "then only process color components with nonzero values replace
> the corresponding component values of the backdrop. All other
> component values leave the existing backdrop value unchanged"
> which makes sense for overprinting,
> vs.
> "That is, the value of the blend function B(Cb,Cs) is the source
> component cs for any process (DeviceCMYK) color component whose
> (subtractive) color value is nonzero; otherwise it is the
> backdrop component cb."
> Which is NOT the same thing as leaving the backdrop unchanged
> with the compositing equation
> ar*Cr = (1-as)*Cb + as*[(1-ab)*Cs+ab*B(Cb,Cs)]
> For this to work, we need to carry out the operation during
> the mixing of the source with the blend result. Essentially
> replacing that mixing with the color we have here.
> Resource/Init/pdf_draw.ps
> Resource/Init/pdf_main.ps
> Resource/Init/pdf_ops.ps
> base/gdevp14.c
> base/gdevp14.h
> base/gstrans.h
> base/gxblend.c
> base/gxclpath.c

2019-08-07 10:24:49 -0700
Ray Johnston <ray.johnston@artifex.com>
d8f05309d5e54b6e75c2b78af9c0bcf5f62b493c

> Bug 701308: Fix clip transpose logic that resulted in garbled output.
> This seems like it should have showed up earlier, but when the clip
> rectangle list was transposed, the _t1 and _s1 clip_fill_rectangle_
> functions were confused about the coordinates being sent to the target
> device fill_rectangle.
> Also during debug, I found that if the clip list consisted of more than
> a single rectangle, clip_get_clipping_box was only using the first rect,
> rather than accumulating the outer_box for the entire list.
> base/gxclip.c

2019-08-06 12:44:49 +0100
Ken Sharp <ken.sharp@artifex.com>
ff856d0c44ce7d3f4d204f4a405857a6a6672a80

> pdfwrite - handle nested Patterns inside a transparency Group
> Bug #701181 "Incorrect output after ghostscript processing of a PDF file"
> The PDF file is constructed in a somewhat sub-optimal fashion. Each
> background square 'grid' is a Form, each Form draws the content by
> filling the area with a solid colour, and then drawing white lines
> across it. The white lines (actually rectangles) are drawn using a
> Pattern.
> So far so good, however the Pattern simply executes a Form, that Form
> then fills another rectangle, with another Pattern, its this final
> pattern which does the drawing.
> This is two levels of indirection more than required.
> Normally this isn't a problem because we don't attempt to preserve
> Forms from PDF files (and this is one example of why we don't). But....
> If the file involves transparency Groups, then we must use a Form
> XObject for the Group.
> In this case the CTM of the first pattern is the CTM of the 'enclosing
> context', ie the Form, but the CTM of the second pattern is also the
> CTM of the 'enclosing context', but now that means the first pattern,
> not the Group.
> To cater for this we track the number of patterns defined since the last
> Form definition. If its 0 (ie this is the first pattern since a Form
> definition) then we just use the CTM. If its greatre than 0, however,
> then we 'undo' the scaling applied by pdfwrite, in order to get back to
> the CTM of the enclosing pattern.
> Its possible that more extreme examples (patterns inside patterns
> inside groups inside patterns inside groups) might still not be entirely
> correct, but we have no examples of this (Patterns inside patterns are
> relatively rare). If we find any we can revisit this.
> devices/vector/gdevpdfb.h
> devices/vector/gdevpdfi.c
> devices/vector/gdevpdft.c
> devices/vector/gdevpdfv.c
> devices/vector/gdevpdfx.h

2019-08-05 17:50:04 +0100
Ken Sharp <ken.sharp@artifex.com>
f69b63a3dc3bb7671df956587fe2520f8badab88

> PDF interpreter - cope with strangely constructed Pages trees
> Bug #700953 "Error: /execstackoverflow in --.systemvar--"
> The pre-interpretation scan of the Pages tree looking for loops in the
> tree structure uses recursion; if a Pages tree is badly constructed it
> is possible to recurse enough times to cause an overflow of the exec
> stack.
> We can cope with this by aborting the scan and continuing to interpret
> and render the PDF file, because the regular processing of PDF file
> doesn't use recursion.
> Of course, this does mean that we lose the check for loops in the Pages
> tree (at least, loops beyond the point where we overflow the exec stack)
> but both conditions are rare, so I think its worth doing.
> We do still raise a warning.
> Resource/Init/pdf_main.ps

2019-08-05 10:05:58 +0100
Ken Sharp <ken.sharp@artifex.com>
fd915a81c605a52f58855bd233c19aaa373b2f69

> pdfwrite - improve CIDFont generation
> Bug 701010 "Low Printer VM and gswinc32.exe crashing on postscript file with Korean text"
> The problem in this case is that the PostScript uses a CIDFont with two
> descendant fonts. PDF only permits a single descendant font in a CIDFont
> so pdfwrite can't simply copy the font 'as is'.
> Instead we create a type 0 font (CIDFont) for each descendant and switch
> between them as required.
> The problem here is that the code for retrieving an existing Type 0
> CIDFont for a given descendant in the PostScript assumed that the name
> of the CIDFont would be of the form /FontName-CMapName, and the font
> we have here does not match that.
> In fact, I'm not at all sure that this is *ever* the case, certainly
> none of our test files seem to exercise this (bearing in mind that its
> the Type 0 CIDFont generated by pdfwrite that we are checking against
> and I can see no code that created a name of that form).
> So what was happening was that every time the PostScript CIDFont
> switched descendants, we generated a new Yype 0 font, along with all the
> attendant structures, such as a ToUnicode CMap (256kB on its own). In
> fact the first line of text in the file switches descendants 26 times,
> leading to us creating something like 21 MB of extra font information.
> We now extend the check so that if the name is not FontName-CMapName we
> check the FontName and the CMap Name (which we do also store) separately
> and if they match we reuse the existing Type 0 font.
> The supplied test file now runs to completion, all 217 pages, with a
> peak memory usage of ~22.8MB whereas it previously exhausted memory,
> using ~2GB, at page 111. In addition the resulting PDF file is around
> 95% smaller and the performance is noticeably improved on this file.
> devices/vector/gdevpdtt.c

2019-08-02 15:18:26 +0100
Chris Liddell <chris.liddell@artifex.com>
5b85ddd19a8420a1bd2d5529325be35d78e94234

> Bug 701394: protect use of .forceput with executeonly
> Resource/Init/gs_type1.ps

2019-07-31 13:34:06 +0100
Chris Liddell <chris.liddell@artifex.com>
3ed82a40fd4b49728c79955319b6d67d1e092006

> Add a way to record the selected cmap
> (for the pdfi branch)
> base/fapi_ft.c
> base/gxfapi.h
> pcl/pl/plfapi.c
> psi/zfapi.c
> xps/xpsfapi.c

2019-08-01 08:55:31 +0100
Chris Liddell <chris.liddell@artifex.com>
1eb609f130c397144702097f4d987f3b956770f9

> Add 'post' table name lookup to TTF in graphics lib
> Make Mac Roman glyph ordering available to 'clients'
> (in support of the pdfi branch)
> base/gstype42.c
> base/gxfont42.h

2019-07-31 15:04:37 +0100
Ken Sharp <ken.sharp@artifex.com>
788958decad94b7b3f7a478cfb57724323041bf5

> Fix Separation and DeviceN Alternate colour space generation
> Bug #701369 "PB with Pantone color in pdfwrite"
> When converting to a specified colour space, if we encounter a DeviceN
> or Separation space, we leave the spot inks in place but change the
> alternate space to the defined colour conversion space, and generate a
> new tint transform which approximates the original colours.
> However there was a logical error in the code, which only became
> apparent if TransferFunctionInfo was set to something other than 'Apply'
> Normally this doesn't happen, but commit
> 2e68cc460dbe349f68b81082ff7344db48eb4820 changed the behvaiour when
> we are doing colour conversion to prevent us trying to apply a transfer
> function to a SMask, which we can't do.
> This then exposed the fact that we were not copying the concretized
> samples to the client_colour structure, but we were reading them *back*
> from the client_colour structure to set the low and high values in the
> generated tint transform function.
> The solution is to copy the components from the concretized colour
> outside the if clause testing the TransferFunctionInfo.
> This fix continues to work properly with the file from bug #700052
> devices/vector/gdevpdfg.c

2019-07-24 12:36:35 -0700
Ray Johnston <ray.johnston@artifex.com>
4367024d102c6363ba7536227790564466ec9ddc

> Fix debug PDF14_OPCODE_NAMES -- PDF14_BEGIN_TRANS_PAGE_GROUP was missing.
> base/gstrans.h

2019-07-23 14:48:32 +0100
Robin Watts <Robin.Watts@artifex.com>
9a8e9c6f7bd45531a1b01eb0d697a6dc48cde2b0

> Add arm option to clusterpush.pl
> toolbin/localcluster/clusterpush.pl

2019-07-22 12:18:52 -0600
Henry Stiles <henry.stiles@artifex.com>
4de965abeddf859b91937314bc7e86de25acb729

> Bug #701339, fixes total pattern length of 0.
> Fallback to the default path code if the total pattern length is 0.
> This can happen because PCL XL represents pattern length elements as
> integers not floats.
> devices/vector/gdevpx.c

2019-07-22 19:33:44 +0100
Robin Watts <Robin.Watts@artifex.com>
a628e509caf40ddec3d016dd9ff6379f12be7cc1

> Ensure pdf14_put_image linebuf is long enough to avoid overrun.
> The assumption is that we can write in 32byte lumps, so we may
> overrun the actual amount we need by 28 bytes. Allow for this.
> base/gdevp14.c

2019-07-21 16:26:28 +0100
Robin Watts <Robin.Watts@artifex.com>
4d8b6c57ef7272d41fb389a4dc9546f078ba3b2d

> Rework CAL cflags.
> Cope with building for machines that have SSE4.2, but not AVX2,
> that crash on SSE4.2 code compiled with the -mavx2 flag.
> Makefile.in
> base/cal.mak
> configure.ac

2019-07-22 13:07:59 +0100
Ken Sharp <ken.sharp@artifex.com>
909a87a15b5f8fede1f6bfeac2005327a7ca1601

> Permit extra widths on space glyphs (PDF Tw value) even for xyshow
> For the benefit of the pdfi interpreter. With the PDF in PostScript
> current interpreter, we apply Widths using a cshow procedure. The pdfi
> interpreter instead uses the x_widths and y_widths arrays, intended for
> use with the PostScript xyshow operator instead.
> However, the existing code doesn't add the extra width to space glyphs
> if we have TEXT_REPLACE_WIDTHS set (ie an xyshow).
> Here we move the code for the additional width out of the 'else'
> clause in show_move() so that we always have the value available. We
> then apply the dx and/or dy values in both cases.
> We also need to relax the 'invalid' checking which is performed at a
> higher level in the code (gx_device_text_begin) because this combination
> is explicitly barred there and returns an error.
> base/gstext.h
> base/gxchar.c

2019-07-20 11:34:46 -0700
Robin Watts <Robin.Watts@artifex.com>
239d9035a011c212b015951bb2d75114ba11bee0

> Add cal operation to clusterpush.pl
> toolbin/localcluster/clusterpush.pl

2019-07-20 19:34:00 +0100
Robin Watts <Robin.Watts@artifex.com>
0d4dcb839b679a01f38aac2156c2bb87a819b0d4

> Squash warnings in CAL build.
> base/gxblend.c
> base/gximono.c

2019-07-18 15:47:54 +0100
Robin Watts <Robin.Watts@artifex.com>
e5faf407dcb7c9679537313cebd55a747098f6f8

> Bug 701296: Fix Interpolation in Indexed spaces with UseFastColor
> The get_color_handler logic was being called with pcs = Indexed, and
> so doing pcs = pcs->base_space. Then it was checking that pcs == the
> concrete space, seeing that it was, and deciding it could then use
> the device colors direct. The problem is that pcs->base_space is a
> greyscale space, so when running to (say) an rgb output, we have the
> wrong color data.
> We now check for the number of components being as we expect, and
> for the space being one of our 'default' ones before choosing to
> take the 'fast' route.
> base/gsicc_manage.c
> base/gsicc_manage.h
> base/gxiscale.c

2019-07-17 10:25:45 -0700
Michael Vrhel <michael.vrhel@artifex.com>
c0e588f679fca92d92045049fd60846b57da899c

> Fix crash when RAW_PATTERN_DUMP is enabled
> RAW_PATTERN_DUMP is used to help debug pattern issues.
> Crash introduced when changes were made to file i/o.
> Easy to overlook since this is rarely enabled.
> base/gxpcmap.c

2018-07-26 14:35:48 -0700
Michael Vrhel <michael.vrhel@artifex.com>
c7499c426c0307880e9a34a577492d99a976c15b

> Introduce CAL based transparency accelerations.
> Authored by Michael Vrhel.
> base/cal.mak
> base/gdevp14.c
> base/gdevp14.h
> base/gstrans.c
> base/gxblend.c
> base/gxblend.h
> base/gxblend1.c
> base/lib.mak

2018-07-03 11:36:07 -0700
Michael Vrhel <michael.vrhel@artifex.com>
2533344c1bad749e81c3cef91e770ba4ea5a1a1d

> Introduce CAL based SSE4.2 and AVX2 optimisations.
> Authored by Michael Vrhel.
> base/cal.mak
> base/gsicc_lcms2mt.c
> base/gxicolor.c
> base/lib.mak
> psi/msvc.mak

2019-07-17 07:14:21 -0700
Robin Watts <Robin.Watts@artifex.com>
2682485aefb808e5dca7191b980aa83880821dcc

> Update configure for CAL to spot AVX2 as well.
> configure.ac

2019-07-16 12:04:04 +0100
Robin Watts <Robin.Watts@artifex.com>
58d1db5850d470856f8c83af9a573b9c5c18e519

> Move cal_context into gs_lib_ctx core.
> This avoids us having to repeatedly init/fin the CAL lib.
> base/gdevdrop.c
> base/gslibctx.c
> base/gslibctx.h
> base/gxicolor.c
> base/gxidata.c
> base/gximage.h
> base/gximono.c
> base/lib.mak
> base/siscale_cal.c

2019-07-17 10:19:47 +0100
Robin Watts <Robin.Watts@artifex.com>
47cd6503f34921c840df7c96faa9d957603521e7

> Bug 701323: Skip oversize TIFF checks in BigTIFF mode.
> If we have -dUseBigTIFF, then we don't need to check that
> we don't exceed 4Gig.
> This appears to work, but I don't have any code that will
> actually load and show me a >4Gig TIFF!
> devices/gdevtsep.c

2019-07-15 18:43:04 +0100
Robin Watts <Robin.Watts@artifex.com>
efce71ac4d500231296d1c84f62077666e0966a1

> Fix SEGV seen in saved-pages-test run.
> The following job:
> membin/gs -Ilib -sOutputFile=out.%04d.psd --saved-pages-test
> -dMaxBitmap=10000 -sDEVICE=psdrgb -r300 -Z: -sDEFAULTPAPERSIZE=letter
> -dNOPAUSE -dBATCH -K2000000 -dClusterJob -dJOBSERVER
> /home/regression/cluster/tests_private/comparefiles/Bug691425.pdf
> SEGVs due to a buffer overrun.
> We are attempting to copy a list of up to GX_DEVICE_MAX_SEPARATIONS
> spot colors for the page into a list that's only GX_SOFT_MAX_SPOTS
> long.
> We just extend the storage here to cope.
> base/gxclist.h

2019-07-15 11:50:27 +0100
Robin Watts <Robin.Watts@artifex.com>
105891fadfa649a7b0e3196cc6b0a9865fbf3cac

> Fix SEGV seen in -dUseCIEColor testing.
> The following test fails with a SEGV in overnight testing:
> tests_private/ps/ps3cet/30-07.PS.psdcmyk.300.1
> I can reproduce the problem with this call:
> membin/gs -Ilib -sOutputFile=out.%d.psd -dUseCIEColor -dMaxBitmap=10000
> -sDEVICE=psdcmyk -r300 -Z: -sDEFAULTPAPERSIZE=letter -dNOPAUSE -dBATCH
> -K2000000 -dClusterJob -dJOBSERVER -dCETMODE %rom%Resource/Init/gs_cet.ps
> tests_private/ps/ps3cet/30-07.PS
> (with a hacked version of Memento so that blocks aren't all put into
> their own chunk).
> The problem is that when a shading is built it contains a set of
> params, one of which is a reference to the cie_joint_caches
> structure. This structure is held in a chunk of memory allocated
> from pgs->memory. This entire chunk of memory goes away when an
> l2restore happens. The built shading, however, is referenced by
> a PS object that can (and does) outlive this.
> When a gc happens, it follows the pointer as part of the enumeration
> and crashes due to it having been freed already.
> The fix implemented here, is to add a new graphics lib entrypoint
> that returns a reference to a copy of the current caches, allocated
> in a given memory space; we use that to get a reference to the
> caches in the same memory space (and hence with the same lifespan
> as) the shading.
> base/gscie.c
> base/gscie.h
> psi/zshade.c

2019-07-12 16:53:58 +0100
Robin Watts <Robin.Watts@artifex.com>
7e9df44328a8a6796a83331a4ab5f9b31091a02c

> Fix SEGV with psdcmykog device and files with > 7 spots.
> Example invocation:
> membin/gs -Ilib -sOutputFile=out.%d.psd -dMaxBitmap=10000
> -sDEVICE=psdcmykog -r600 -Z: -sDEFAULTPAPERSIZE=letter
> -dNOPAUSE -dBATCH -K2000000 -dClusterJob -dJOBSERVER
> ./tests_private/comparefiles/Bug693541.pdf
> The PDF14 buffers are set up to have dev->color_info.num_components
> planes. When these buffers are written into, components 0 to num_spots-1
> inclusive are written. If num_spots > num_components, we overwrite
> data.
> Devices such as psdcmyk expand num_components to accomodate the
> number of spots found on the page. Devices such as psdcmykog
> do not; they stick with the number of spots they know about to
> start with (i.e. 2).
> Accordingly, if we run a file through with (say) 11 spots on the
> page, with a psdcmykog device, the pdf14 device is setup with
> num_comps = 7 (6+alpha), but the number of spots is taken as
> the number of spots on the page (11), and thus we have memory
> overwrites.
> The fix attempted here is to set the number of spots to be
> num_comps - number_of_standard_comps.
> base/gdevp14.c
> base/gdevp14.h

2019-07-03 20:24:24 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
6b0aab1de02cfc44515ff05f70be066bcac7f504

> Bug 697545 : Prevent memory leaks in transfer_raster_row.
> Prevent several memory leaks in transfer_raster_row by releasing graphic state.
> Error created using :-
> MEMENTO_FAILAT=15010 ./membin/gpcl6 -sDEVICE=pbmraw -o /dev/null ./tests_private/pcl/pcl5cfts/fts.0670
> pcl/pcl/rtraster.c

2019-07-10 14:19:23 +0100
Robin Watts <Robin.Watts@artifex.com>
3bce47c5094c4e200d2200ebd1b081a4dd943215

> Fix CAL halftoning crash due to unaligned data buffer.
> base/gdevp14.c

2019-07-09 14:00:36 +0100
Robin Watts <Robin.Watts@artifex.com>
0c6f6eb9bd630d594aae0ef7b58aa75253bf52ed

> Reference count image colorspaces in XPS.
> This avoids leaks.
> xps/xpsanalyze.c
> xps/xpscolor.c
> xps/xpsglyphs.c
> xps/xpsgradient.c
> xps/xpsimage.c
> xps/xpsjpeg.c
> xps/xpsjxr.c
> xps/xpspath.c
> xps/xpspng.c
> xps/xpstiff.c
> xps/xpstop.c

2019-07-08 19:40:28 +0100
Robin Watts <Robin.Watts@artifex.com>
ab4cea734dca75cde0ad5d39ad2964c9343e8c91

> XPS: Avoid leaking scanline buffer on jpeg decompression.
> xps/xpsjpeg.c

2019-07-08 11:33:55 +0100
Chris Liddell <chris.liddell@artifex.com>
5c1311ed4dbfb159c9b2304c26b9311834a72bd4

> Remove a couple of macros
> base/gxchar.c

2019-07-08 19:20:18 +0100
Robin Watts <Robin.Watts@artifex.com>
a116672f813da107719df28057b624ce434e163c

> Fix leak of buffer from scaler.
> This was being hidden by gc, but shows up in xps.
> base/siscale.c

2019-07-08 17:30:01 +0100
Robin Watts <Robin.Watts@artifex.com>
23f28069c8b342cc03de65d8b90029a4b3548010

> Really fix CAL makeflags for NEON and SSE.
> Makefile.in
> base/cal.mak

2019-07-08 17:29:40 +0100
Robin Watts <Robin.Watts@artifex.com>
c0d136b659b6e54017f57877068206bee62e1fa1

> Fix typo in PRI definitions.
> base/stdint_.h

2019-07-08 16:49:17 +0100
Ken Sharp <ken.sharp@artifex.com>
f0c043ead481dd780c916ddd088baf7abe2a2665

> pdfwrite - fix a memory leak
> pcs is a local variable and when it goes out of scope if it still holds
> a reference to the colour space, it will leak.
> devices/vector/gdevpdfb.c

2019-07-08 16:38:09 +0100
Robin Watts <Robin.Watts@artifex.com>
a77d1aef180a2dce12cefc039f7fc3dffd69af98

> Fix CAL NEON detection.
> configure.ac

2019-07-08 15:46:55 +0100
Robin Watts <Robin.Watts@artifex.com>
c454bf4c1e6eb6d64508234dbdd6f29ceea184c3

> Bug 701284: Fix more path leakages, this time in pdf14.
> base/gdevp14.c

2019-07-08 14:58:36 +0100
Robin Watts <Robin.Watts@artifex.com>
0ca58b97aa19d25ede275cc6447dc32815205263

> Bug 701284: Fix clipping path memory leaks
> base/gxclrast.c
> base/gxcpath.c

2019-07-06 18:34:47 +0100
Robin Watts <Robin.Watts@artifex.com>
9d410dc41277401d48f4dd94dd50391c4a4c79b0

> Fix CAL builds to pass appropriate compiler flags
> Makefile.in
> configure.ac

2019-07-05 19:36:34 +0100
Robin Watts <Robin.Watts@artifex.com>
c734f19d7780cac16b89ced9924ad18bf1c1b380

> Fix memory leak in pdf14_tile_pattern_fill in non-GC languages.
> base/gdevp14.c

2019-07-05 19:35:58 +0100
Robin Watts <Robin.Watts@artifex.com>
d181151975f0ee13162cc03865c0cc5f58931823

> Fix memory leaks seen in XPS; pattern cache and start_part.
> xps/xpstop.c

2019-07-05 19:35:28 +0100
Robin Watts <Robin.Watts@artifex.com>
f19453e0f1ced6eb0273f4eabc4e618553c49925

> xps_free_font wasn't freeing font->data causing leaks.
> xps/xpsfont.c

2019-07-05 19:34:56 +0100
Robin Watts <Robin.Watts@artifex.com>
e05305f8d8e6222250f18daf9b437b7faee8ebee

> Destructors should cope with NULL.
> base/gxpcmap.c

2019-07-04 18:52:08 +0100
Robin Watts <Robin.Watts@artifex.com>
dd2bd7b4ca1886a4f3c58afbdacbb93831c57e1b

> Bug 701284: Fix leak of pdf14device in xps.
> The pdf14device is created and then "retained". This is required
> for gs, because postscript can call "currentdevice" and get a
> non reference counted pointer to a device. It is cleared up
> correctly because of gc.
> Other languages have no gc, and so leak. The fix is to enable
> those languages to get the pdf14device "unretained". We add an
> graphics lib call to allow this to happen.
> Transparent Patterns also create pdf14devices, which are again
> retained, despite not needing to be. In gs this causes no problems
> as they are cleared by the restore, but in other languages they
> leak. We make them unretained here, with no ill effects.
> base/gstrans.c
> base/gstrans.h
> base/gxpcmap.c
> psi/zpcolor.c
> psi/ztrans.c
> xps/xpspage.c

2019-07-04 08:47:15 +0100
Chris Liddell <chris.liddell@artifex.com>
47a4fab32690cd2f0aba92f37fc7f03b4069460a

> Bug 701288: Handle SEAC ligature glyph metrics correctly.
> As originally intended, a Type 1 SEAC charstring would be used for an accented
> glyph (like an a-caron, or u-umlaut) where the advance with of the SEAC glyph
> is the same as that of the 'base' glyph ('a' or 'u').
> It this case, it is not uncommon for the SEAC to skip using an (H)SBW op code
> and rely on the one from the base glyph.
> But out of spec fonts also use SEAC glyphs ligature glyphs (like 'oe' or 'fi'),
> and in those cases the overall advance width is greater than that of the 'base'
> glyph.
> In this case, we have to allow for the SEAC glyph having included an (H)SBW and
> if it has, retain those values, rather than those from the base glyph.
> freetype/src/psaux/psintrp.c

2019-07-02 17:15:12 +0100
Robin Watts <Robin.Watts@artifex.com>
491a1637f11c84ad47d83d35eba510ac6d0c47f0

> Move to size_t in allocations.
> base/gsalloc.c
> base/gsalloc.h
> base/gsmalloc.c
> base/gsmalloc.h
> base/gsmchunk.c
> base/gsmdebug.h
> base/gsmemory.c
> base/gsmemory.h
> base/gsmemret.c
> base/gsnogc.c
> base/gsstype.h
> base/gxalloc.h
> base/gxobj.h
> base/mkromfs.c
> psi/ilocate.c

2019-07-03 18:16:25 +0100
Robin Watts <Robin.Watts@artifex.com>
25fbeb3e1f4ba5ca7ecafd7a24b7be4079113e7c

> Squash warning in compile time assert.
> psi/iapi.c

2019-07-03 18:01:01 +0100
Robin Watts <Robin.Watts@artifex.com>
7dfee126567be1859f4ca1637c256b4179a571b8

> Fix missing const with fs_file_open_printer.
> base/gslibctx.c

2019-07-03 18:00:28 +0100
Robin Watts <Robin.Watts@artifex.com>
378fd9840e957c3a160665483cc537d6f6e860bf

> Squash some build warnings with debug prints.
> base/gsicc_cache.c
> base/gsicc_profilecache.c

2019-07-03 15:39:15 +0100
Robin Watts <Robin.Watts@artifex.com>
e3dd119d53361d09fa30ca13cce4a97869ba0f8d

> Add printf format specifier macros for size_t.
> Sadly, it is not enough to have definitions that match
> the sizes; gcc will give a warning if the types don't match.
> base/stdint_.h

2019-07-03 15:23:46 +0100
Robin Watts <Robin.Watts@artifex.com>
761a8b513a28a9c4f4f1e83150556e7407f0d74a

> Add size_t definitions to genarch.
> arch/windows-arm-msvc.h
> arch/windows-x64-msvc.h
> arch/windows-x86-msvc.h
> base/genarch.c

2019-06-27 16:48:06 +0100
Robin Watts <Robin.Watts@artifex.com>
d306e93d487a6539804c6343986bcbca2ecc37a8

> Rework ROP transparency
> Rework ROP behaviour with transparency based upon the results
> from roptest.pxl seen on an HP printer.
> The old style ROP transparency code used to treat white pixels
> as special. The new style code does everything in boolean logic
> by modifying the ROP that is used when S or T pixels are set to
> be transparent.
> This enables us to rip out several cases from the ROP
> processing loops, as we never need to check for transparent
> pixel values anymore.
> base/gdevdrop.c
> base/gdevmpla.c
> base/gdevmr1.c
> base/gdevmr2n.c
> base/gdevmr8n.c
> base/gdevmrop.h
> base/gdevplnx.c
> base/gsroprun.c
> base/gsroprun24.h
> base/gsroprun8.h
> base/gsropt.h
> base/gxdcolor.c
> base/gxipixel.c
> devices/vector/gdevpdfi.c
> devices/vector/gdevpx.c

2019-06-26 18:51:31 +0100
Robin Watts <Robin.Watts@artifex.com>
054f4df9b5f8bb09c252841f0c3256b9adc60f0a

> Add another couple of SSE ROP cases.
> base/gsroprun.c
> base/gsroprun8.h
> base/gsropt.h

2018-01-11 17:57:29 +0000
Robin Watts <robin.watts@artifex.com>
82e2843149b32e61cfde7861ac67a51014538f4f

> ROP optimisation: Fold 24bpp ROPs down to 8 bit where possible.
> This increases line length.
> base/gsroprun.c
> base/gsroprun8.h
> base/gsropt.h

2019-07-02 17:29:54 +0100
Robin Watts <Robin.Watts@artifex.com>
470897e484fb0bfaa8553e0ccd5b9db91eda008b

> Avoid warning due to casting int to double.
> Use size_t properly, and no call to abs is required.
> devices/vector/gdevpdfe.c

2019-07-02 17:14:33 +0100
Robin Watts <Robin.Watts@artifex.com>
6c986cd9f93008992344d2cd5be224af13e1c980

> Squish an annoying implicit cast warning.
> Do it explicitly.
> base/gsicc_cache.c

2019-07-02 17:13:48 +0100
Robin Watts <Robin.Watts@artifex.com>
45e765e59a45b46dcb05e8c729689a7c0574a48c

> Fix some warnings caused by the gs FS api commit.
> base/gp.h
> base/gp_dvx.c
> base/gp_msprn.c
> base/gp_mswin.c
> base/gp_os2.c
> base/gp_os2.h
> base/gp_os9.c
> base/gp_unix.c
> base/gp_winfs2.c
> base/gslibctx.h

2019-07-01 21:31:03 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
f209fb3a0f50cd0a9974d8627a4ac7f358f60c8a

> Bug 697545 : Prevent SEGV in check_pattern_rendering.
> Prevent SEGV by checking for check_pattern_rendering being called with NULL pattern.
> Error created using :-
> MEMENTO_FAILAT=16764 ./membin/gpcl6 -sDEVICE=pbmraw -o /dev/null ./tests_private/pcl/pcl5cfts/fts.0825
> pcl/pcl/pcpatrn.c

2019-07-01 21:08:30 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
e6c50c878d622974e7bb2438327e5363b9419875

> Bug 697545 : Prevent SEGV due to double freeing.
> On error pl_dict_put now consumes the new value so these extra calls
> to free memory are no longer needed.
> Error created using :-
> MEMENTO_FAILAT=1987 ./membin/gpcl6 -sDEVICE=pbmraw -o /dev/null ./tests_private/pcl/pcl5cfts/fts.0825
> pcl/pcl/pcsymbol.c
> pcl/pl/pllfont.c

2019-07-02 15:36:07 +0100
Chris Liddell <chris.liddell@artifex.com>
5ef3a531d00715c2b8bcfd38401515d4f60bfec5

> Rejig order of operations from commit 47b1b7f971a76
> I'd forgotten that setcolorspace would blow away the current color, so we need
> to get two sets of current color values, before setting the fill and stroke
> color spaces, and then setting the file and stroke colors.
> Resource/Init/pdf_ops.ps

2019-06-24 13:23:34 +0100
Robin Watts <Robin.Watts@artifex.com>
93fc44b3426cd771ee0a9358da805cd2ac93a649

> Fix gsapi exposure through the DLL.
> Lots of functions that should have been exposed, weren't.
> psi/dpmain.c
> psi/dwdll.c
> psi/dwdll.h
> psi/gsdll32.def
> psi/gsdll32metro.def
> psi/gsdll64.def
> psi/gsdll64metro.def
> psi/gsdllARM32metro.def

2019-06-19 18:43:33 +0100
Robin Watts <Robin.Watts@artifex.com>
e6966d10ec319a25ad91e4aa53a783edede7b62b

> Add gsapi call to introduce new 'Filing Systems' to gs.
> Still to do - Example?
> base/gdevpipe.c
> base/gp.h
> base/gp_mshdl.c
> base/gp_msprn.c
> base/gp_os2pr.c
> base/gpmisc.c
> base/gsdevice.c
> base/gslibctx.c
> base/gslibctx.h
> base/stdpre.h
> doc/API.htm
> pcl/pl/plapi.c
> pcl/pl/plapi.h
> psi/iapi.c
> psi/iapi.h

2019-07-02 11:12:04 +0100
Chris Liddell <chris.liddell@artifex.com>
e585a31732e966f1508b64f04cacbaf8ede65c68

> Fix an out-of-date comment about devices in gstates
> base/gsstate.c

2019-07-02 11:06:03 +0100
Chris Liddell <chris.liddell@artifex.com>
47b1b7f971a760ff311bf3c3d8a02e2a2d53ac7d

> PDF interp: use initgraphics for initial color(space)
> Previously, the PDF interpreter explicitly set the initial color and color space
> for each page ('0 g 0 G') despite initgraphics being called, and also setting
> the color(space)s correctly.
> Unfortunately, removing that completely causes problems with pdfwrite's
> transparency handling, so we reuse the already installed values in place
> of explicitly setting absolute values.
> This should allow for preview-latex's (slightly hacky) method of custom coloring
> 'special' PDFs for previewing.
> Resource/Init/pdf_ops.ps

2019-06-25 10:43:30 +0100
Chris Liddell <chris.liddell@artifex.com>
94cc50cf64e0899c5d415e6ac1e6ea725fc13502

> Fix DELAYBIND
> We now undefine a *lot* of non-standard/internal operators (and other things) as
> we go, and often we rely on bind to ensure that the names are replaced with the
> operator objects rather than names.
> This falls over when DELAYBIND is in force, and the call to .bindnow happens
> *after* the undefining occurs.
> To solve this, all the undefining happens through a procedure: .addtoundeflist.
> Under normal operation, that simply undefines as we go, and things work the same
> as always.
> Under DELAYBIND .addtoundeflist accumulates a list of names to undefine, and the
> dictionaries from where they should be removed, and on the .bindnow call, then
> .applyundeflist is called which rattles through the lists removing the names
> from the dictionaries.
> Resource/Init/gs_btokn.ps
> Resource/Init/gs_cet.ps
> Resource/Init/gs_cidfn.ps
> Resource/Init/gs_dps2.ps
> Resource/Init/gs_epsf.ps
> Resource/Init/gs_fapi.ps
> Resource/Init/gs_fonts.ps
> Resource/Init/gs_img.ps
> Resource/Init/gs_init.ps
> Resource/Init/gs_lev2.ps
> Resource/Init/gs_ll3.ps
> Resource/Init/gs_res.ps
> Resource/Init/gs_resmp.ps
> Resource/Init/gs_setpd.ps
> Resource/Init/gs_ttf.ps
> Resource/Init/pdf_main.ps

2019-07-02 10:36:18 +0100
Chris Liddell <chris.liddell@artifex.com>
871b8d8d5a26205a7a3c05ea9abf060a272fd6fb

> Tweak path access control logic
> Correctly handle the difference between permitted paths of the forms:
> 'path', 'path/' and 'path/*'.
> The previous code effectively treated 'path/' and 'path/*' the same.
> base/gpmisc.c

2019-06-20 12:24:04 +0100
Chris Liddell <chris.liddell@artifex.com>
1b83ee86dc775a9d7972d94041e226893983b264

> File access control: handle non-null terminated paths
> Add an access control checking API call that can take a non-null terminated
> string (i.e. takes a string and length).
> The reason being the strings returned from gp_enumerate_files* are not null
> terminated, and we need to filter them by permissions.
> base/gp.h
> base/gpmisc.c

2019-07-01 15:27:05 +0100
Ken Sharp <ken.sharp@artifex.com>
56158b2c2d8fb9bd5e5bbb9be645fb88231c4898

> Fix buffer overrun in mswinpr2 device
> Bug #701281 "ACTIONABLE_HEAP_CORRUPTION when try print with -sOutputFile"
> The mswinprs2 device uses the very old 16-bit GetProfileStringW() API
> call to get the 'Devices' in order to look for a specified printer.
> The code however assumes that the buffer length passed is in bytes, and
> in fact it should be in wchar_. This means that a sufficiently large
> Devices section could overrun the buffer, as it thinks there are more
> wchar_t available than there are.
> in addition, if the section is very large we could run out of space in
> the string altogether, and then would be unable to find the designated
> printer.
> This commit alters the code so that the length passed to GetProfileStringW
> is in wchar_t and also examines the returned length. If the returned
> length indicates possible truncation of the return, then we free the
> buffer, increase its size by 4Kb and try again. Repeatedly until we
> either exhaust memory or get a large enough buffer.
> devices/gdevwpr2.c

2019-06-18 21:21:10 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
90ae60d1669ebf01228d05cdb58c248a2f971d07

> Bug 697545 : Prevent memory leaks in pcl_define_symbol_set.
> Cleanup symbol set for all error returns.
> Error created using :-
> MEMENTO_FAILAT=15206 ./membin/gpcl6 -sDEVICE=pbmraw -o /dev/null ./tests_private/pcl/pcl5cfts/fts.0460
> pcl/pcl/pcsymbol.c
> pcl/pl/pldict.c

2019-06-25 15:28:48 +0100
Ken Sharp <ken.sharp@artifex.com>
12ffa0f40b6849d97c1e4dc49287bca56f513f7f

> pdfwrite - fix an error path
> This turned up while working on the PDF interpreter in C. Previously we
> had no examples which exercised this error pathway, because it was only
> used by PCL and none of our PCL examples threw an error here.
> If we've started accumulating a CharProc, then we have started a pdf
> substream. If we get an error, then we need to terminate that substream
> before returning (the caller can't know that the substream was begun).
> devices/vector/gdevpdtt.c

2019-06-11 19:04:21 +0100
Robin Watts <Robin.Watts@artifex.com>
4f59b4dc4f512839fd73718de535da99c6085da3

> First steps for using SSE for ROPs.
> base/gsroprun.c
> base/gsroprun8.h
> base/gsropt.h

2018-04-19 12:45:14 +0100
Robin Watts <robin.watts@artifex.com>
140a9359f3cc6739c7caf0796430bc3112cb3cd5

> Initial import of CAL.
> Makefile.in
> base/cal.mak
> base/gdevdrop.c
> base/gs.mak
> base/gxicolor.c
> base/gxidata.c
> base/gximage.h
> base/gximono.c
> base/gxiscale.c
> base/lib.mak
> base/siscale_cal.c
> base/sisparam.h
> base/unix-gcc.mak
> base/winlib.mak
> configure.ac
> psi/msvc.mak
> windows/ghostscript.vcproj

2019-06-24 16:35:31 +0100
Ken Sharp <ken.sharp@artifex.com>
dd75f619d0ae98e21e30ad89d2e7d2cd4277cc2e

> Preparatory work for the PDF interpreter in C
> Currently the pdfwrite device assumes that a font with FontType 3
> (ft_user_defined) *will* require an exit to the interpreter. The
> CharProc capture is set up so that this happens in a complicated dance.
> When we have the PDF interpreted in C we do not need to exit to the
> interpreter, and so we need to capture the CharProc in the same way we
> do for PCL 'user defined' fonts (eg the HPGL stick font and PCL bitmap
> fonts).
> Obviously to be able to do this we need to be able to differentiate
> between a PostScript type 3 font (or a type 3 font built by the PostScript
> PDF interpreter) and a type 3 font built by the C PDF interpreter. So
> the first thing we do is add a new ft_PDF_user_defined font tyep.
> Then update the graphics library so that it treats the PDF type 3 font
> in exactly the same way as it does a PostScript type 3 font.
> In the pdfwrite device, in general we want to treat a PDF type 3 font
> as being the same as a PS type 3.
> Finally, in pdf_text_process() the bulk of the real work. If we have a
> ft_PDF_user_defined font, then set 'early_accumulator' which means we
> push the accumulator early, because we won't need to exit to the
> interpreter. This means that in the 'early_accumulator' branch we need
> to account for the possibility that the text operation won't be a
> 'TEXT_FROM_CHARS' (it always is for PCL, which is why this didn't need
> to be handled before). There was also some bad error handling in here,
> we do a gs_gsave() which is undone by a gs_grestore() in comp[ete_charproc()
> but if we had an error before that we would not undo the gs_gsave whhich
> could lead to ridiculous levels of nested gsaves.
> base/gstext.c
> base/gxchar.c
> base/gxftype.h
> base/gxpaint.c
> devices/vector/gdevpdtc.c
> devices/vector/gdevpdtd.c
> devices/vector/gdevpdte.c
> devices/vector/gdevpdtf.c
> devices/vector/gdevpdti.c
> devices/vector/gdevpdts.c
> devices/vector/gdevpdtt.c

2019-06-22 10:49:31 +0100
Ken Sharp <ken.sharp@artifex.com>
9055511a9ca3600ee8680ea2b35b2f31f708bd40

> Improve -dFILTERIMAGE
> Previously if we were supplied too much image data, we could read off
> the end of the supplied data and consume input that should have been
> interpreted.
> This limits the consumption of data so that we don't read more than we
> expected.
> NB! We still don't support type 3 images, as that requires us to process
> 2 images at once.
> base/gdevoflt.c

2019-06-19 19:11:43 +0100
Robin Watts <Robin.Watts@artifex.com>
4f3f5aeb40be1562f05864705b0a04fbccae6fec

> Remove unused gsapi functions.
> gsapi_get_device_memory and gsapi_set_device aren't used, so
> do away with them.
> psi/dwdll.h
> psi/dwnodll.c
> psi/gsdll2.def
> psi/gsdll32.def
> psi/gsdll32metro.def
> psi/gsdll64.def
> psi/gsdll64metro.def
> psi/gsdllARM32metro.def
> psi/iapi.c
> psi/iapi.h

2019-06-19 18:43:09 +0100
Robin Watts <Robin.Watts@artifex.com>
c1500bb8ed62224e8b372fca76ed8e411cc447d1

> More gp_file vs FILE fixes.
> base/gp_vms.c
> contrib/pcl3/src/pcl3opts.c
> contrib/pscolor/test.c

2019-06-20 19:22:24 +0100
Ken Sharp <ken.sharp@artifex.com>
ae73b49631e657b5ed5c3bf7936febf64a3f8b3c

> Fix Indexed 'install' procedure
> The Install procedure for Indexed spaces was calling the 'install'
> procedure for its base space. This is incorrect. Colour spaces are
> supposed to be set from the lowest (most 'base') to the highest. So the
> Indexed space's base space should already be set, and installed. Trying
> to set it again is a bad thing and can cause Seg Faults.
> However, the PCL interpreter relies on the Indexed space doing this,
> contrary to the expected behaviour it does not set the base space before
> setting the Indexed space, and relies on the Indexed space to 'install'
> the base space.
> Setting the base space caused unexpected (and inexplicable) differences
> in halftoned output. I 'suspect' that this is because it sets the three
> initial components of pgs->color[0].ccolor, whereas the previous code
> only resulted in setting the initial value.
> So instead, call the base space's 'install' procedure directly, this
> doesn't set the colour values (which gs_setcolorspace does) and results
> in no differences.
> For me this resolves the crashes that were being seen in the 32-bit
> builds of Ghostscript and shows no differences.
> base/gscolor2.c
> pcl/pcl/pcindxed.c

2019-06-19 15:14:46 +0100
Robin Watts <Robin.Watts@artifex.com>
108dd018b746d33ad06a7ee863fae56cbeb1fd80

> "Fix" contrib and test uses of gp_fopen.
> Here we fix a lot of contrib devices that had been broken by the
> changes to gp_file. I believe they all should work OK now.
> One of the routines was calling lib_fopen in an unsupported way; this
> can't easily be fixed, so we just call gp_fopen instead now.
> We also "fix" some test code that was calling gp_fopen and then doing
> things that we can't easily do with a gp_file *. This code has reverted
> to using FILE *'s and fopen - this might cause issues on compilation as
> this code is untested, but it's better than compiling to give code that
> crashes.
> base/gp_vms.c
> contrib/japanese/dviprlib.c
> contrib/japanese/dviprlib.h
> contrib/japanese/gdevdmpr.c
> contrib/pscolor/test.c
> devices/vector/gdevtxtw.c
> psi/gserver.c

2019-06-19 12:51:38 +0100
Robin Watts <Robin.Watts@artifex.com>
2c6484de7376ce4e24d87f1eb4c6f76360c9b928

> Fix debug code to call gp_fopen correctly.
> These were missed during the conversion to gp_file.
> base/gdevp14.c
> base/gsicc_create.c
> base/gsicc_lcms2.c
> base/gsicc_lcms2mt.c
> base/gsicc_manage.c
> base/gsicc_manage.h
> base/gsroprun.c
> base/gxblend.c
> base/gxblend.h
> base/gxblend1.c
> base/gxpcmap.c

2019-06-19 09:42:10 +0100
Chris Liddell <chris.liddell@artifex.com>
b38aad870c573f7cafe99a95c3b931c1dc6cd132

> Remove some debug code
> Resource/Init/gs_init.ps

2019-06-18 10:54:47 +0100
Chris Liddell <chris.liddell@artifex.com>
d4d7d6948e41c2573b47645191dbb7e3877f0597

> Fix up some coverity issues, and other warnings
> CIDs: 341120, 341119, 341118, 341117, 341116, 341115, 341114, 341113, 341112,
> 341111, 341110, 341109, 341108, 341107, 341106, 341105, 341104, 341103, 341102,
> 341101.
> Mostly examples of gp_fseek and sscanf ignoring return values.
> base/gp_unifs.c
> base/mkromfs.c
> contrib/pcl3/eprn/pagecount.c
> contrib/pcl3/src/gdevpcl3.c
> contrib/pcl3/src/pclgen.c
> contrib/pcl3/src/pclgen.h
> devices/gdevdfax.c
> devices/gdevpsd.c
> devices/vector/gdevpdf.c
> devices/vector/gdevxps.c
> pcl/pl/pjparse.c
> pcl/pl/plmain.c
> psi/imainarg.c
> psi/iutil.c
> xps/xpszip.c

2019-06-14 09:10:45 +0100
Chris Liddell <chris.liddell@artifex.com>
29da5d218dac7e0975c03a81982fdc33b5eba20d

> Make sure font Decoding is in the correct VM mode
> Resource/Init/gs_fntem.ps

2019-06-14 09:10:04 +0100
Chris Liddell <chris.liddell@artifex.com>
35b8b94e3ac3cced1b415c92b091c6959240755e

> Remove stray exec and some pointless immediate evaluations
> Resource/Init/gs_fapi.ps

2019-06-14 09:16:53 +0100
Ken Sharp <ken.sharp@artifex.com>
adc94490502a360c3bdf8843888f784d57066c0e

> PDF interpreter - improve repair of broken PDF files
> If a file had a startxref token which was not followed by any further
> actual tokens (eg nothing but % comment lines) then the repair code
> failed to account for this, and ended up trying to pop non-existent
> objects from the stack.
> This is because the code did not test the result of the 'token' operator
> to ensure that a token had been read, it assumed one would be. In this
> commit we check the result and, if its 'false' (no token read) we don't
> attempt to pop the non-existent token from the stack, but instead follow
> the existing error path and resort to scanning the PDF file for the
> trailer dictionary.
> In addition to fixing the customer reported file, this also fixes the
> existing test suite file
> tests_private/pdf/sumatra/repairing_leaks_object.pdf
> Resource/Init/pdf_rbld.ps

2019-06-12 15:35:11 +0100
Chris Liddell <chris.liddell@artifex.com>
8522db03fde6b1b514beed9d66faa839f24ebdc4

> Make .pdfexectoken not an operator
> In a previously round of security fixes, I made .pdfexectoken an operator. That
> turns out to cause problems because we (normally) attempt to recover from errors
> in PDF files, so we don't want .pdfexectoken to cleanup the stacks in the event
> of an error.
> In addition, the original problem this solved is solved in a more robust way
> (executeonly on the transient procedures).
> Resource/Init/pdf_base.ps

2019-06-11 20:29:53 +0200
Sebastian Rasmussen <sebras@gmail.com>
094b9caade51b718a20b8d326fff9e0f93166cd4

> Bug 698777: jbig2dec: Update information in README.
> jbig2dec/README

2019-06-10 17:22:04 +0100
Robin Watts <Robin.Watts@artifex.com>
20a6ddad3cd42796c913ab94583fc0f0e5870281

> Fix gpdl SAFER operation.
> -sOutputFile=foo was having the pass set as "=foo" due to
> me forgetting to increment the pointer. This resulted in
> many thousands of errors in the weekly SAFER test.
> pcl/pl/plmain.c

2019-06-10 16:24:41 +0100
Ken Sharp <ken.sharp@artifex.com>
ee8ab38bab473ff1457e7f966b2733f0c829bcb1

> PDF interpreter - don't execute newpath when ending text blocks
> Bug 701178 - "PDF missing two bounding boxes on process"
> The missing rectangles are defind in the content stream between a
> number of BT/ET text blocks, and only finally stroked after all the
> text has been emitted.
> Because we execute a newpath when ending a text block (to avoid dangling
> path elements from text), and prior path elements are lost.
> This commit only executes a newpath when the text rendering mode is one
> of the 'clip' modes, as that is handled differently, and we need the
> newpath.
> Its a pretty poor way to output the paths, and I suspect that it would
> likely run into trouble with the text clipping modes, but since those
> aren't used here its hard to tell.
> Resource/Init/pdf_ops.ps

2019-06-07 13:58:25 +0100
Ken Sharp <ken.sharp@artifex.com>
8eaa0856399c9b621db17e96c8f7be1e0241ab8b

> Fix AES-256 decryption when using owner key
> The code for computing the decryption key for AES-256 encrypted PDF
> files was incorrect. When computing the validation check we correctly
> used the owner key if it was supplied, but for computing the actual
> decryption key we always treated the supplied password as the user
> password.
> psi/zpdf_r6.c

2019-06-05 09:55:46 +0100
Ken Sharp <ken.sharp@artifex.com>
b31fb3c0cd7ab223d870fa1e0fb231d911b19984

> Modify the new gp_file API so that gp_fread etc match fread
> The new gp_fread() and gp_fwrite() have a parameter list which (more or
> less) matches the list for the C run-time functions fread() and fwrite()
> However, the return values do not match the returned values from the
> C runtime functions. This is because, internally, the gp_file structure
> has function pointers which only take 3 parameters instead of 4. This
> is handled by multiplying the size of the record by the number of records
> to be read/written, and then reading that many bytes.
> Since the underlying functions are (at this time) the C runtime functions
> this means that th returned value becomes the number of bytes read
> (or written) instead of the number of *records* read/written.
> This commit modifies that internal API so that the gp_file member
> functions take 4 parameters (thus matching both gp_fread and fread)
> and pass them to the underlying functions. The return value is then
> the number of records, as expected.
> Should we ever encounter an implementation which doesn't match the
> C runtime fread() we could implement it by multiplying the size by the
> count (as was done prior to this commit) and then, assuming the return
> value was the number of bytes read, dividing the return value by the
> size, in order to retrieve the number of records read.
> base/gp.h
> base/gpmisc.c

2019-06-07 12:11:57 +0100
Michael Vrhel <michael.vrhel@artifex.com>
ee8864ae09ff0017e5503bde1f5b52538759babc

> Ensure that separation CMYK source colors managed
> This is the separation version of the DeviceN commit
> http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=0b9c45fa86f7736e7fec170a135efa83636283ba
> base/gdevp14.c
> base/gscsepr.c
> base/gsequivc.c
> base/gxcmap.c
> base/gxcmap.h

2019-06-01 11:09:05 +0100
Ken Sharp <ken.sharp@artifex.com>
d5e123d42718370c144a62ba10a7b715cc88b81a

> Graphics library - match gsaves with grestores
> Auditing as part of the pdfi work, when the graphics library executes
> a gs_gsave() it should match it with a gs_grestore(), even in the case
> of an error.
> In addition, if gs_setcolorspace failed in image_PaintProc() it would
> leak the pattern enumerator. Because this is only called from PCL
> the memory is not garbage collected.
> base/gsptype1.c
> base/gxchar.c

2019-06-03 18:28:18 +0100
Robin Watts <Robin.Watts@artifex.com>
c9a832653a91ddcdd1220fe9fbbc58839eade4aa

> Fix leak in gs_lib_ctx_fin.
> When freeing gs_lib_ctx, don't remove the mem->gs_lib_ctx pointers
> until after we have finished using them. This avoids a leak.
> base/gslibctx.c

2019-06-03 14:19:54 +0100
Robin Watts <Robin.Watts@artifex.com>
7b052ff372bbd325676d2e1a57dfd71c33c9f677

> Update gpdl with new file access permissions.
> This basically involves duplicating the changes from Chris'
> gs commit. Part of this promotes a couple of static functions
> to being global ones so both implementations can call them.
> base/gslibctx.c
> base/gslibctx.h
> pcl/pl/plmain.c
> psi/imainarg.c

2019-05-29 15:56:20 -0700
Ray Johnston <ray.johnston@artifex.com>
650c49424529fca922519ee9cdf2086eee5cfb70

> Fix broken DEBUG build. Add standalone gs_log_error to mkromfs.c
> This function is invoked for DEBUG builds by gs_note_error. We define
> an equivalent local version so we don't have to include gsmisc.obj
> (as for other utility functions such as outprintf).
> base/mkromfs.c

2019-05-29 13:20:39 +0100
Chris Liddell <chris.liddell@artifex.com>
f5c0159d993418a8900a84e5fd946e83bdaeec73

> Fix dfaxhigh/low device with new gp_file API.
> Arose in the "all devices" cluster test
> devices/gdevdfax.c

2019-05-07 11:30:15 +0100
Chris Liddell <chris.liddell@artifex.com>
7ecbfda92b4c8dbf6f6c2bf8fc82020a29219eff

> Add use of new file access permissions to PS interp
> (this is a squash of several commits from filesec branch)
> Use errno to indicate invalidfileaccess
> Integrate fontconfig with file access controls
> fontconfig API has a call to retrieve all the directories about which fontconfig
> knows, so we can get those, and add them to the paths from which we're permitted
> to read.
> Add (most of) the Postscript "managed" paths....
> ...to the access controls.
> GenericResourceDir, ICCProfilesDir (reading) and temporary file directories for
> read/write/control.
> Add paths/files from C to the file access controls
> The -I paths, environment variables and build time paths.
> The command line specified output file, permit writing.
> Lastly, the command line specified input file is added to the readable list,
> interpreted, and then removed from the list.
> Add the FONTPATH path list to permit read access control list.
> I opted to do this in Postscript because the list is (normally) a colon
> separated list of paths, which we split into an array of paths (in Postscript) -
> it seems sensible to do this only once, both for storage and permissions.
> Add a non-standard string 'reverse search" operator
> The search operator searches for the first occurrence of a character code in a
> string (i.e. searches forwards from the start of the string), 'rsearch' finds
> the last instance of a character code (i.e. search backwards from the end of
> the string).
> Fix gp_open_scratch_file_rm for access permissions
> i.e. the same as gp_open_scratch_file
> Handle clist file 'rewind' failures
> 'Rewinding' clist files may involved closing and recreating the temporary files,
> which conceivably can fail, but the clist procs rewind method was a void
> function, so couldn't return an error.
> It now can, and does return an error, and we handle the error.
> Add file permissions support for piped output.
> Paths from Fontmap to PermitReading list
> cidfmap paths, add to PermitReading list
> Add command line options for path access control addition
> --permit-file-read
> --permit-file-write
> --permit-file-control
> --permit-file-all
> They all take a separated list of paths (the usual platform specific ':' or ';'
> separator), and to the respective access control lists - the final 'all' option
> adds the paths to all the control lists.
> Add file access control to the 'gp_stat' method.
> This is complicated by the need to add the memory allocator context to the
> gp_stat parameters. To facilitate this, I've added a gs_memory_t pointer to the
> gx_io_device structure, which is set during the io device initialisation at
> startup.
> mkromfs: Add dummy gp_stat_impl for Windows - saves quite a bit of pointless
> build upheaval
> Add file access protection to file enumeration.
> The low level implementation of Postscript's filenameforall (*_enumerate_files)
> needs to also honour file access protection.
> This is has been complicated by requiring a gs_memory_t to be available where
> it wasn't previously (in order to access the gs_lib_ctx and the file permissions
> lists therein).
> Temp
> Resource/Init/gs_cidfm.ps
> Resource/Init/gs_fonts.ps
> Resource/Init/gs_init.ps
> base/gdevpipe.c
> base/gp.h
> base/gp_dosfe.c
> base/gp_mshdl.c
> base/gp_msprn.c
> base/gp_mswin.c
> base/gp_ntfs.c
> base/gp_os2fs.c
> base/gp_os2pr.c
> base/gp_unifs.c
> base/gp_unix.c
> base/gp_vms.c
> base/gpmisc.c
> base/gsiodev.c
> base/gsiodevs.c
> base/gsiodisk.c
> base/gsioram.c
> base/gsiorom.c
> base/gxclfile.c
> base/gxclio.h
> base/gxclist.c
> base/gxclmem.c
> base/gxclread.c
> base/gxiodev.h
> base/gxp1fill.c
> base/lib.mak
> base/mkromfs.c
> base/stat_.h
> pcl/pl/pjparse.c
> pcl/pl/pllfont.c
> psi/imain.c
> psi/imainarg.c
> psi/zdevcal.c
> psi/zfile.c
> psi/ziodev.c
> psi/ziodev2.c
> psi/ziodevsc.c
> psi/zstring.c

2019-03-07 18:03:00 +0000
Robin Watts <Robin.Watts@artifex.com>
9de16a6637b73e35f79d2d622de403b24e6502f2

> Move FILE * operations behind new gp_file * API.
> (squash of commits from filesec branch)
> Most of this commit is donkeywork conversions of calls from
> FILE * -> gp_file *, fwrite -> gp_fwrite etc. Pretty much every
> device is touched, along with the clist and parsing code.
> The more interesting changes are within gp.h (where the actual
> new API is defined), gpmisc.c (where the basic implementations
> live), and the platform specific levels (gp_mswin.c, gp_unifs.c
> etc where the platform specific implementations have been
> tweaked/renamed).
> File opening path validation
> All file opening routines now call a central routine for
> path validation.
> This then consults new entries in gs_lib_ctx to see if validation
> is enabled or not. If so, it validates the paths by seeing if
> they match.
> Simple C level functions for adding/removing/clearing paths, exposed
> through the gsapi level.
> Add 2 postscript operators for path control.
> <name> <string> .addcontrolpath -
> Add the given <string> (path) to the list of paths for
> controlset <name>, where <name> can be:
> /PermitFileReading
> /PermitFileWriting
> /PermitFileControl
> (Anything else -> rangecheck)
> - .activatepathcontrol -
> Enable path control. At this point PS cannot make any
> more changes, and all file access is checked.
> base/gdebug.h
> base/gdevdevn.c
> base/gdevp14.c
> base/gdevpccm.c
> base/gdevpccm.h
> base/gdevpipe.c
> base/gdevprn.c
> base/gdevprn.h
> base/gdevvec.c
> base/gdevvec.h
> base/gp.h
> base/gp_dosfs.c
> base/gp_dvx.c
> base/gp_mshdl.c
> base/gp_msprn.c
> base/gp_mswin.c
> base/gp_ntfs.c
> base/gp_os2.c
> base/gp_os2fs.c
> base/gp_os2pr.c
> base/gp_os9.c
> base/gp_unifs.c
> base/gp_unix.c
> base/gp_vms.c
> base/gp_win32.c
> base/gp_winfs.c
> base/gp_winfs2.c
> base/gpmisc.c
> base/gpmisc.h
> base/gsargs.c
> base/gsargs.h
> base/gsdevice.c
> base/gsicc_create.c
> base/gsicc_lcms2.c
> base/gsicc_lcms2mt.c
> base/gsicc_manage.c
> base/gsinit.c
> base/gsiodev.c
> base/gsiodevs.c
> base/gsiodisk.c
> base/gsioram.c
> base/gsiorom.c
> base/gslib.h
> base/gslibctx.c
> base/gslibctx.h
> base/gsmemory.h
> base/gsmisc.c
> base/gsroprun.c
> base/gstiffio.c
> base/gstiffio.h
> base/gxblend.c
> base/gxblend1.c
> base/gxclfile.c
> base/gxdevice.h
> base/gxiodev.h
> base/gxpcmap.c
> base/lib.mak
> base/msvctail.mak
> base/sfxcommon.c
> base/sfxfd.c
> base/sfxstdio.c
> base/stdpre.h
> base/stream.h
> base/tiff.mak
> base/winlib.mak
> contrib/contrib.mak
> contrib/eplaser/gdevescv.c
> contrib/gdevbjc_.c
> contrib/gdevbjc_.h
> contrib/gdevbjca.c
> contrib/gdevcd8.c
> contrib/gdevdj9.c
> contrib/gdevgdi.c
> contrib/gdevhl12.c
> contrib/gdevln03.c
> contrib/gdevlx32.c
> contrib/gdevlx7.c
> contrib/gdevmd2k.c
> contrib/gdevop4w.c
> contrib/gdevxes.c
> contrib/japanese/dviprlib.c
> contrib/japanese/gdev10v.c
> contrib/japanese/gdevalps.c
> contrib/japanese/gdevdmpr.c
> contrib/japanese/gdevespg.c
> contrib/japanese/gdevfmlbp.c
> contrib/japanese/gdevfmpr.c
> contrib/japanese/gdevj100.c
> contrib/japanese/gdevlbp3.c
> contrib/japanese/gdevmjc.c
> contrib/japanese/gdevml6.c
> contrib/japanese/gdevnpdl.c
> contrib/japanese/gdevp201.c
> contrib/japanese/gdevrpdl.c
> contrib/lips4/gdevl4r.c
> contrib/lips4/gdevl4v.c
> contrib/lips4/gdevlprn.c
> contrib/lips4/gdevlprn.h
> contrib/opvp/gdevopvp.c
> contrib/pcl3/eprn/eprnparm.c
> contrib/pcl3/eprn/gdeveprn.c
> contrib/pcl3/eprn/pagecount.c
> contrib/pcl3/eprn/pagecount.h
> contrib/pcl3/src/gdevpcl3.c
> contrib/pcl3/src/pcl3opts.c
> contrib/pcl3/src/pclgen.c
> contrib/pcl3/src/pclgen.h
> contrib/pcl3/src/pclscan.c
> cups/gdevcups.c
> devices/contrib.mak
> devices/devs.mak
> devices/gdev3852.c
> devices/gdev4081.c
> devices/gdev4693.c
> devices/gdev8510.c
> devices/gdevatx.c
> devices/gdevbit.c
> devices/gdevbj10.c
> devices/gdevbmp.c
> devices/gdevbmp.h
> devices/gdevbmpc.c
> devices/gdevccr.c
> devices/gdevcdj.c
> devices/gdevcfax.c
> devices/gdevchameleon.c
> devices/gdevcif.c
> devices/gdevclj.c
> devices/gdevcljc.c
> devices/gdevcmykog.c
> devices/gdevcslw.c
> devices/gdevdfax.c
> devices/gdevdjet.c
> devices/gdevdjtc.c
> devices/gdevdljm.c
> devices/gdevdljm.h
> devices/gdevdm24.c
> devices/gdevepsc.c
> devices/gdevepsn.c
> devices/gdevescp.c
> devices/gdevfax.c
> devices/gdevfax.h
> devices/gdevfpng.c
> devices/gdevgprf.c
> devices/gdevhl7x.c
> devices/gdevicov.c
> devices/gdevifno.c
> devices/gdevijs.c
> devices/gdevimgn.c
> devices/gdevjbig2.c
> devices/gdevjpeg.c
> devices/gdevjpx.c
> devices/gdevl31s.c
> devices/gdevlbp8.c
> devices/gdevlj56.c
> devices/gdevlp8k.c
> devices/gdevlxm.c
> devices/gdevmgr.c
> devices/gdevmiff.c
> devices/gdevn533.c
> devices/gdevo182.c
> devices/gdevokii.c
> devices/gdevpbm.c
> devices/gdevpcx.c
> devices/gdevpdfimg.c
> devices/gdevperm.c
> devices/gdevphex.c
> devices/gdevpjet.c
> devices/gdevplan.c
> devices/gdevplib.c
> devices/gdevpng.c
> devices/gdevpsd.c
> devices/gdevpsd.h
> devices/gdevpsim.c
> devices/gdevpxut.c
> devices/gdevpxut.h
> devices/gdevrinkj.c
> devices/gdevsj48.c
> devices/gdevstc.c
> devices/gdevtfax.c
> devices/gdevtfax.h
> devices/gdevtfnx.c
> devices/gdevtifs.c
> devices/gdevtifs.h
> devices/gdevtknk.c
> devices/gdevtsep.c
> devices/gdevupd.c
> devices/gdevwpr2.c
> devices/gdevxcf.c
> devices/rinkj/rinkj-byte-stream.c
> devices/rinkj/rinkj-byte-stream.h
> devices/vector/gdevpdf.c
> devices/vector/gdevpdfo.c
> devices/vector/gdevpdfp.c
> devices/vector/gdevpdfu.c
> devices/vector/gdevpdfx.h
> devices/vector/gdevpsu.c
> devices/vector/gdevpsu.h
> devices/vector/gdevpx.c
> devices/vector/gdevtxtw.c
> devices/vector/gdevxps.c
> pcl/pl/pjparse.c
> pcl/pl/pl.mak
> pcl/pl/plapi.c
> pcl/pl/plapi.h
> pcl/pl/plmain.c
> pcl/pl/plmain.h
> pcl/pl/plparams.c
> pcl/pl/pltop.h
> psi/files.h
> psi/iapi.c
> psi/iapi.h
> psi/imain.c
> psi/imain.h
> psi/imainarg.c
> psi/imainarg.h
> psi/iminst.h
> psi/int.mak
> psi/psapi.c
> psi/zfile.c
> windows/ghostscript.vcproj
> xps/ghostxps.h
> xps/xpsjxr.c
> xps/xpstop.c
> xps/xpszip.c

2019-05-28 16:08:26 +0100
Chris Lidell <chris.liddell@artifex.com>
808021913baf763e07cc9eabc3716bfa507380ff

> Bug 701083(2): Write the new key/value to DecodeParms
> There was a lengthy block of code that handled PDFs with buggy DCTDecode
> dictionaries with a missing, or incorrect Height entry. Since we now have a
> second key/value needing added to the DecodeParms and in two places, I've
> split that into a more general procedure, so we can add multiple new keys in
> one step.
> This is used to add/patch the Height key, and add the new ErrsAsEOD key
> (telling the CCITT fax decode filter to treat an error as a EOD).
> Resource/Init/pdf_draw.ps

2019-05-27 19:00:06 +0100
Robin Watts <Robin.Watts@artifex.com>
1a344ed8506e46e77a0c58aed57de69ce8f54a20

> Bug 701083: Add key to treat errors as end of data when decoding images.
> This specifically only applies to the CCITT decode filter at the
> moment, but the key will be in place for all image decoders to look
> at if required.
> A following commit will cause the PDF interpreter to set this key
> in the DecodeParms.
> base/scfd.c
> base/scfparam.c
> base/scfx.h

2019-05-27 15:33:27 +0100
Chris Liddell <chris.liddell@artifex.com>
c1739dcc6a8ceda1a5091c1b7dc8bb4870c6c76b

> Fix a couple more compiler warnings.
> psi/imain.c

2019-05-24 14:32:59 +0100
Chris Liddell <chris.liddell@artifex.com>
e2e83fb18feeae8786c16c0c309f9c1efdea2614

> Bug 700956: don't free text enumerator in error condition
> Some errors mean the graphics library will decrement the reference count,
> potentially freeing, the text enumerator. So, on return to the interpreter
> don't try to free it.
> In these cases we can safely rely on the garbager to clean up the memory if the
> graphics library didn't.
> psi/zchar.c

2019-05-24 09:50:49 +0100
Chris Liddell <chris.liddell@artifex.com>
f8b9b5d02f2ba59256c92f6015eda02cb5d16c9e

> Fix a trivial (probably benign) compiler warning
> psi/imain.c

2019-05-23 11:09:50 +0100
Chris Liddell <chris.liddell@artifex.com>
c1844f1adbd7e1b215dde46d6211a84af5cea8a4

> Fix FONTPATH font file enumeration
> As part of improving security, we had replaced the reference using the name
> .scanfontheaders to find the array of headers for file types to scan with
> the immediatetly evaluated //.scanfontheaders in gs_fonts.ps
> That doesn't work correctly because the array is redefined multiple times
> as we add support for various font types during initialisation.
> Fix it by replacing the immediate evaluation with explicitly using the name key
> /.scanfontheaders to pull the array from systemdict.
> Resource/Init/gs_cff.ps
> Resource/Init/gs_fonts.ps
> Resource/Init/gs_ttf.ps

2019-05-23 11:18:06 +0100
Chris Liddell <chris.liddell@artifex.com>
e42161d209e220aa84615b0af7efc7507f0f5397

> Fix crash when the default font can't be found.
> Making .loadfontloop into an operator messes up the error condition recovery
> when we've had to fall back to the default font, and even that is not
> available (i.e. when GenericResourceDir is set to somewhere that isn't actually
> a viable resource directory).
> Resource/Init/gs_fonts.ps

2019-05-22 19:07:07 -0600
Henry Stiles <henry.stiles@artifex.com>
c2d78d6fd563bb3137991ce9f74ec2379e0de9aa

> Remove unnecessary but harmless conditional from the last commit.
> pcl/pcl/pctop.c

2019-05-22 13:36:31 -0600
Henry Stiles <henry.stiles@artifex.com>
690adf6efb53e61e965e6f37cd78b060b2fdb233

> Fix bug 701045 - infinite loop in pcl parser.
> The recent work to remove the specialized PL cursor code and replace
> it with streams removed end of data detection PCL depended on. End of
> data is now detected by the PCL parser by requiring a minimum number
> of bytes on the next call to the parser. If the required number of
> bytes are not provided the parser signals end of data by advancing the
> read pointer to the end of the buffer.
> The change precipitated some reorganization in how RTL is initialized,
> as well.
> pcl/pcl/pcl.mak
> pcl/pcl/pcmacros.c
> pcl/pcl/pcparse.c
> pcl/pcl/pcparse.h
> pcl/pcl/pcsfont.c
> pcl/pcl/pctop.c
> pcl/pxl/pxpthr.c

2019-03-28 17:21:02 -0600
Henry Stiles <henry.stiles@artifex.com>
1058e51507f4dfb483c104dd83e77375e62181b4

> Fix bug #700844, crash with very long font path.
> A long font path, specified by setting the environment variable
> PCLFONTSOURCE, resulted in buffer overflows in both PJL and PCL. Also,
> simplify the logic to load fonts in PCL because it is not
> necessary to parse a path list, a single path has been already been
> parsed in PJL.
> Related coverity id's addressed with this change are: 102193, 102206,
> 102208, and 102210.
> pcl/pl/pjparse.c
> pcl/pl/pllfont.c

2019-03-11 11:18:23 -0600
Henry Stiles <henry.stiles@artifex.com>
7a5637d2248501998ca9bb16bc51c93dd15a2d0d

> Remove unnecessary include file left from a test.
> pcl/pl/plfont.c

2019-05-22 18:04:52 +0100
Robin Watts <Robin.Watts@artifex.com>
3a9bb467fa9ff18ca398081c32edddc6732ce75e

> Add gpdl to default products for clusterpush.pl
> toolbin/localcluster/clusterpush.pl

2019-05-22 17:58:25 +0100
Robin Watts <Robin.Watts@artifex.com>
979f09479916c799d5df30df85c6caa30f86bffc

> Add nopdfwrite to clusterpush.pl
> toolbin/localcluster/clusterpush.pl

2019-05-21 07:39:49 -0700
Nancy Durgin <nancy.durgin@artifex.com>
dd4be3eb2b28ff67dc3ee6e636bf7024bf9d1003

> Add check for gs_error_handled for pattern handling
> Some clients (specifically gpdfi) can now return gs_error_handled if
> they already took care of everything in the PaintProc call. In this
> case, just do all the cleanup as for any other error, but it's not
> really an error, so return error code 0.
> This wll be needed for pdfi when merged in, should have no affect on current
> code.
> base/gxpcmap.c

2019-05-20 12:32:13 +0100
Robin Watts <Robin.Watts@artifex.com>
2b925a84a9cbbeabba391d50f08b7064688298c2

> Add gsapi_set_param to iapi.h as well.
> This keeps the gs and gpdl implementations of gsapi in sync.
> psi/iapi.c
> psi/iapi.h

2019-05-20 13:07:13 +0100
Robin Watts <Robin.Watts@artifex.com>
8aa6f8ce98e19ddc1a30b924169abf091748c1a9

> Fix warnings in pjparse.c
> pcl/pl/pjparse.c
> pcl/pl/pl.mak

2019-05-17 18:51:13 +0100
Robin Watts <Robin.Watts@artifex.com>
b932ec31114e4e7a7ace0089cb87ddb70dc7732f

> Add gsapi_set_param to gpdl gsapi.
> This takes an enumerated type and values, to allow programmatic
> setting equivalent to -d and -s on the command line.
> These should only be called between jobs, and then with care.
> Values are set in the device parameters and then passed to each
> language implementation in turn.
> pcl/pl/plapi.c
> pcl/pl/plapi.h
> pcl/pl/plmain.c
> pcl/pl/plmain.h
> pcl/pl/pltop.h

2019-05-16 19:59:58 +0100
Robin Watts <Robin.Watts@artifex.com>
dc9c23ed944f653e384fd12fbaf6328e8bab8a33

> PJL GSSET and GSSETSTRING
> Add GSSET and GSSETSTRING PCL commands for setting device
> parameters/language parameters from PJL.
> pcl/pl/pjparse.c
> pcl/pl/plmain.c
> pcl/pl/plmain.h

2019-05-18 13:52:25 +0100
Ken Sharp <ken.sharp@artifex.com>
85c99aa093d4e26b9f40c0a4eb686a7f5b2b2d64

> pdfwrite - fix ColorConversionStrategy
> No bug number, this arose from a question asked on Stack Overflow.
> At some point I removed the enumerated value ccs_UseDeviceDependentColor
> but I failed to remove the name "UseDeviceDependentColor" from the
> list of strategy names. This meant that setting ColorConversionStrategy
> to anything except LeaveColorUnchanged was 'out by 1' in the enumerated
> data type.
> This led (for example) to Gray being treated as RGB for the purposes
> of the output colour space.
> devices/vector/gdevpsdf.h

2019-05-08 08:19:55 -0700
Michael Vrhel <michael.vrhel@artifex.com>
95f7befcec1b30fd5014c8ad616485d32901ce33

> Make sure transparency page group is isolated
> Per the spec, the page group should be treated as an isolated
> group. This allows the page group to specify a blending color space.
> This resulted in over 90 pages of bmpcmp diffs. I went over all
> of them. They are progressions. Most are very minor color differences
> as we end up doing the blending and drawings in different color spaces
> compared to prior to the commit
> base/gstrans.c

2019-05-17 14:37:30 -0700
Michael Vrhel <michael.vrhel@artifex.com>
ebe7cd2b5a7a000c5ebf0bfa061f872faaf098e3

> Handle trans group knockouts properly if page group is isolated
> Page groups by definition have to be isolated. A fix for this to
> ensure that the proper group color space is used for the page group
> revealed a problem when the source PDF actually indicated the page
> group was isolated. This led to an incorrect selection of subsequent
> backdrops for any knockout groups contained.
> base/gdevp14.c
> base/gdevp14.h

2019-05-17 11:20:45 +0100
Ken Sharp <ken.sharp@artifex.com>
ee8a1c574198351d3ec1b181428d3d0159b4f80a

> PDF interpreter - ignore errors in some faulty FreeText annotations
> Bug #701058 "Can not convert pdf to tiff"
> The PDF file has a FreeText annotation with no appearance stream and
> faults in the Annotation dictionary.
> Firstly (not perhaps strictly a fault) the /Contents key has a string
> value with nothing in it. This isn't exactly an error, but it makes the
> annotation pointless.
> More seriously the /DA key contains:
> (//Helvetica 12 Tf 0 g)
> The double // on the font name means we end up with an empty name
> on the stack, which causes errors.
> In this commit:
> Execute the DA processing in a stopped context, so that if it fails we
> don't throw an error.
> Surround the DA processing with a mark so that we can clear the stack if
> it leaves anything behind.
> Surround all of that with a 'gstate...setgstate' or 'gstate...pop'. If
> we get an error this allows us to restore the graphics state to the
> point before we did the DA processing. If we didn't get an error then
> we can just discard the saved gstate.
> Finally, check the length of the Contents string. If its 0, don't even
> try to draw it. If its more than 0, but less than 4, then don't attempt
> to check for UTF16 (2 byte BOM + 2 bytes for character means a minimum
> of 4 bytes).
> This results in slightly different output from pdfwrite with one file,
> tests_private/pdf/sumatra/1331_-_prints_garbled.pdf, which results in
> very small (single pixel) differences at 72 dpi.
> Resource/Init/pdf_draw.ps

2019-05-17 09:15:48 +0100
Chris Liddell <chris.liddell@artifex.com>
2b4f54e13d9a5346e1c4c0a3a577d27065e67313

> Remove the redundant -E and -A command line params
> The functionality for both are now (and have been for a *long* time!) accessed
> via -Z# and -Z@ respectively.
> This solves a clash for -E with the other language implementations.
> doc/Use.htm
> psi/imainarg.c

2019-05-11 09:24:38 +0100
Ken Sharp <ken.sharp@artifex.com>
29fc52982904f7b24349f7fe369f614b3081ce90

> DeviceN - handle out of memory errors
> When altering the DeviceN colour space handling in the PostScript
> interpreter to use C strings instead of name indices, I neglected to
> consider the possibility of a failure to allocate memory for the string.
> This commit just catches the fault and returns a VM error to the
> interpreter.
> psi/zcolor.c

2019-05-10 14:49:29 +0100
i3v <i3v@mail.ru>
55d04ff91a70a2cba1a1c15407c94f936c5f91f4

> Documentation - fix various typos in VectorDevices.htm
> Bug #701021 "Typos in VectorDevices.htm"
> Fixes supplied by 'i3v'.
> doc/VectorDevices.htm

2019-05-10 09:32:26 +0100
Chris Liddell <chris.liddell@artifex.com>
3db10c55b3ef621770bf6e93dfc1605e766adef2

> Improve test for PS resources in romfs
> Previously, although we always built a romfs, building gs with COMPILE_INITS=0
> meant we included a romfs which was devoid of content, and an attempt to find
> the status of the device would return 'gs_error_unregistered'. We used this
> to determine whether to automatically add '%rom%Resource/Init' to the default
> search path.
> In the gpdl case (for the sake of PCL and XPS), we always have a usable romfs
> (even with COMPILE_INITS=0) for the ICC profiles, so the above test gave a
> false positive: gs would add the romfs to the search path, despite there being
> no usable Postscript resources in it.
> So, revise the test to explicitly check for Resource/Init/gs_init.ps on the
> romfs. If the romfs is, indeed, empty, it will still return
> 'gs_error_unregistered', but in the gpdl case, it will return
> 'gs_error_undefinedfilename', and we correctly skip adding the romfs path to
> the search paths for Postscript resources
> psi/imain.c

2019-05-08 13:23:26 +0100
Chris Liddell <chris.liddell@artifex.com>
d2809b15153eedbbe1bfb43fc259bf674e353f42

> Add an (interim) --enable-gpdl configure option
> This adds gpdl to the default target list for make.
> Mainly to get the .so build usable without having edit the makefiles.
> This will be deprecated when gpdl is always in the default target list.
> Makefile.in
> configure.ac

2019-05-09 09:49:56 +0100
Ken Sharp <ken.sharp@artifex.com>
d0d7b8d3866aecafac3601ebd9b4b5d83f4fbe91

> Fix some compiler warnings
> and remove some #if directives accidentally included in a commit
> base/gscdevn.c
> devices/vector/gdevpdfc.c
> psi/zcolor.c

2019-05-08 14:28:41 +0100
Ken Sharp <ken.sharp@artifex.com>
86a81b823950c712ac03e0139449045a81672d01

> pdfwrite - extend DeviceN attributes dictionary generation
> Now that we cater for the /Process dictionary in a DeviceN attributes
> dictionary (and the Subtype) we need to emit those from pdfwrite too.
> devices/vector/gdevpdfc.c

2019-05-08 14:27:23 +0100
Ken Sharp <ken.sharp@artifex.com>
2019db2e552653bd0c27377d500de1041c9fd0bc

> PostScript colour space handling
> We were not catering for a /Subtype in a DeviceN attributes dictionary
> having a value which is a string type not a name type. I can't quite
> see how we are ending up with a string type here, since the PDF file
> has it as a name, but it does. Dealing with both resolves many errors.
> The second change is more far-reaching; when processing an attributes
> dictionary for a DeviceN colour space we may need to create colour
> spaces for the Process dictionary /ColorSpace and for any of the entries
> in the Colorants dictionary. We were doing that by calling
> zsetcolorspace() which mostly works well, however there is one
> optimisation which can cause a problem; if the target space is the same
> as the current *interpreter* colour space, then zsetcolorspace()
> simply returns.
> The problem is that if we are halfway through processing a DeviceN
> space then we haven't set the interpreter space to the new colour space
> array yet which can mean that we incorrectly detect one of the target
> spaces as being the same as the current space. This leads to us trying
> to use the current space in the graphics state (the DeviceN space) as
> the target space, with unfortunate consequences.
> So create a new version of zsetcolorspace which doesn't do that
> optimisation and use that when processing the various target spaces in
> the DeviceN attributes dictionary.
> psi/zcolor.c

2019-05-07 12:52:25 +0100
Ken Sharp <ken.sharp@artifex.com>
0d75869134c69963406500b536fb1bb1c97c8621

> Separation - change ink name to be a C string instead of name index
> As indicated in previous commits, change the stored ink name in the
> colour space structure params.separation from a numeric value
> (gs_separation_name) into a C string.
> We never have to pass these back to the interpreter, so we allocate the
> storage using the non-GC allocater.
> base/gscdevn.c
> base/gscsepr.c
> base/gscspace.h
> base/gsequivc.c
> base/gsicc_cache.c
> base/gxcmap.c
> devices/vector/gdevpdfc.c
> devices/vector/gdevpdfg.c
> psi/zcolor.c

2019-05-06 16:51:26 +0100
Ken Sharp <ken.sharp@artifex.com>
97253bf54a701d5e433378df953e066d009afde0

> DeviceN - change ink names to be C strings instead of name indices
> As indicated in previous commits, change the stored ink names in the
> colour space structure params.device_n from numeric values
> (gs_separation_name) into C strings.
> We never have to pass these back to the interpreter, so we allocate the
> storage using the non-GC allocater, which simplifies things for the
> array which used to store the indices and now stores the pointers to the
> C strings.
> base/gscdevn.c
> base/gscspace.h
> base/gsequivc.c
> base/gsicc_cache.c
> base/gsicc_manage.c
> base/gxcmap.c
> devices/vector/gdevpdfc.c
> devices/vector/gdevpdfg.c
> psi/zcolor.c

2019-04-07 19:54:57 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
880a700f691f444c483053f48b3c0b0f3a920883

> Bug 697545 : Prevent SEGV caused by double freeing.
> Prevent running finalize for devices with a custom finalize.
> Error created using :-
> MEMENTO_FAILAT=1767 ./membin/gpcl6 -sDEVICE=pbmraw -o /dev/null ./tests_private/pcl/pcl5cfts/fts.0270
> base/gdevdflt.c
> base/gspaint.c

2019-05-02 08:00:46 -0700
Michael Vrhel <michael.vrhel@artifex.com>
284ba1a6491088ab8ea9985f5df882c43bd3ca12

> Use deviceN attributes process color color space
> If the DeviceN color space includes an attributes entry and
> it has a process color space, and the color space is of the proper
> type use that as the source color for the process components. If
> instead the alternate tint transform color space is the correct type
> use that as a hint. If neither work then set to the defined default_cmyk
> source color space. If all fail due to issues with ICC profiles then
> the CMYK source process colorants will pass through to the output device.
> base/gdevp14.c
> base/gscdevn.c
> base/gsequivc.c
> base/gsicc.c
> base/gxcmap.c
> base/gxcmap.h

2019-05-06 13:46:42 +0100
Ken Sharp <ken.sharp@artifex.com>
754b4eb77d24ff0273b530aa748bbf925b715d9c

> Ensure correct memory allocation of Colorant strings
> I'm not happy with using ref_to_string() as it doesn't seem to behave
> entirely as I would expect, so modify the code to explicitly allocate
> the memory used to store the Colorant name.
> Also fix a compiler warning.
> psi/zcolor.c

2019-05-06 09:10:22 +0100
Ken Sharp <ken.sharp@artifex.com>
76022c9c27a0f4031553cf3a5eb2c009b26b19be

> DeviceN - store C strings for Colorant names, not name indices
> For DeviceN spaces with an attributes dictionary containing a
> Colorants dictionary we were storing the Colorant names as a name index
> (index into the interpreter name table). Additionally we store a
> procedure callback to recover the C string from the name index.
> This is problematic for several reasons; firstly it requires all the
> interpreters to either have a name table or some close equivalent so
> that a C string can be recovered from a numeric value.
> Secondly the lifetime of the string is divorced from the lifetime of the
> C structure using it. Because there's no easy way for the interpreter to
> know when the graphics library has freed the colour space structure
> the interpreter is forced to retain the relationship between the name
> index and the C string until the job is completed.
> Both of these will be problems for the new PDF interpreter, so this is
> step 1 in altering this. After this we will still need to change the
> storage of the DeviceN and Separation ink names, which are handled the
> same way.
> base/gscdevn.c
> base/gscdevn.h
> base/gxcdevn.h
> devices/vector/gdevpdfc.c
> devices/vector/gdevpdfg.c
> psi/zcolor.c

2019-05-03 17:35:49 +0100
Ken Sharp <ken.sharp@artifex.com>
8b407511d2fad0108a76c6b46dc54a1770ea3ade

> fix commit c2d50885614481ebf542578e69ce4bcbbfea6532
> don't retest code, and fix some compiler warnings
> base/gscdevn.h
> psi/zcolor.c

2019-05-03 13:27:22 +0100
Ken Sharp <ken.sharp@artifex.com>
c2d50885614481ebf542578e69ce4bcbbfea6532

> DeviceN - handle attributes Subtype and cleaning up
> Previously we were ignoring the /Subtype in the attributes dictionary
> of a DeviceN colour space (if attributes were present). We may need to
> be able to tell the difference (now that we handle /Process) because
> the values associated with the process components must be stored in
> their natural form (eg subtractive for CMYK, additive for RGB) when
> the Subtype is NChannel.
> The remainder of the commit tidies up naming; previously we had a
> structure called gs_devicen_attributes, which was used to store the
> Colorants entry form an attributes dictionary. Since we now handle
> other aspects of the attributes dictionary as well, this was misleading
> so the structure has been renamed throughout as gs_devicen_colorant
> (since each structure defines only one colorant, the plural name was
> also misleading). Apparently pdfwrite is the only client for this
> currently anyway.
> Finally, moved the 'devn_process_space' from the general graphics
> state colour space structure into the DeviceN params structure, as its
> only relevant to DeviceN (and indeed only a DeviceN with an attributes
> dictionary which contains a /Process entry)
> base/gscdevn.c
> base/gscdevn.h
> base/gscspace.c
> base/gscspace.h
> base/gxcdevn.h
> devices/vector/gdevpdfc.c
> devices/vector/gdevpdfg.c
> psi/zcolor.c

2019-05-02 16:40:18 +0100
Ken Sharp <ken.sharp@artifex.com>
22d88ad48409a130007976ae26536cc9d99c16d9

> Fix an oversight in DeviceN attributes processing
> If we have no Colorants entry we still want to check for a Process
> entry, but to do so we need to signal to setcolorspace_cont(), the
> routine which calls this one, that we do want to keep processing the
> colour space.
> psi/zcolor.c

2019-05-02 13:12:28 +0100
Ken Sharp <ken.sharp@artifex.com>
7c70031f8be95585bcf439d12e552d386e4e2125

> Capture the /Components from a DeviceN /Process dictionary
> Following on from commit 5e84879db91fdc8569a85a394def391695152720 and
> Michael's commit c6ac30d231946062b41c56df375b240583e75b35 this adds
> code to check for the existence of a /Process dictionary in the
> attributes dictionary (if present) of a DeviceN colour space.
> Also fixed/added a few comments to the existing code and did some
> tidying up of error return handling.
> psi/zcolor.c

2019-05-01 10:06:41 -0700
Michael Vrhel <michael.vrhel@artifex.com>
c6ac30d231946062b41c56df375b240583e75b35

> Add holder for process color names in DeviceN color space parameters
> As part of the work to use the DeviceN attributes process dictionary
> we need to have a place to store the colorant names. They will
> be stored as an array of C strings in the pcs->params.device_n structure.
> This commit adds them to the structure and frees them during the color
> space finalization.
> base/gscdevn.c
> base/gscspace.h

2019-05-01 17:49:03 +0100
Ken Sharp <ken.sharp@artifex.com>
5e84879db91fdc8569a85a394def391695152720

> Process DeviceN attributes dictionary, /Process dictionary, /ColorSpace
> PostScript PDF interpreter changes; retrieve the Process dictionary
> from the DeviceN attributes dictionary (if present). Extract the
> ColorSpace, resolve the ColorSpace (turns any references into actual
> objects), and store the result back in the Process dictionary. Finally
> store the Process dictionary in the attributes dictionary which we
> pass to setcolorspace.
> PostScript interpreter, C changes; add a new 'stage' for DeviceN
> colour space handling. In stage 3, check for the existence of an
> attributes dictionary, then a /Process dictionary, and a /ColorSpace
> entry. Retrieve the entry. Set up a new continuation procedure
> 'devicenprocess_cont'. The continuation procedure calls zsetcolorspace()
> to set the /ColorSpace as the current space. On returning, retrieve
> the current color space, attach it to the DeviceN graphics state colour
> space and finish.
> Still to do; process /Components, add the equivalent code to pdfi,
> check pdfwrite to see if we can handle this. Tidy up comments.
> Committing now so Michael can carry on with the CMS work.
> Resource/Init/pdf_draw.ps
> psi/zcolor.c

2019-05-01 13:17:25 +0100
Robin Watts <Robin.Watts@artifex.com>
6742ad7d26dc7bb8cc33aef9f96f86d892d4a424

> Valgrind: image_render_interpolate_landscape_icc.
> Don't color convert the unprocessed margins of the buffer.
> These areas are never inited, so a warning is given. No
> harm is done as they are never actually rendered, but it's
> faster and cleaner to skip them too.
> base/gxiscale.c

2019-04-30 15:13:25 -0700
Michael Vrhel <michael.vrhel@artifex.com>
04db6ace1fb97dcef79d9bdbb01a1c8a63c55d88

> Add a devn_process_space to color gs_color_space_s
> This is in preparation for having the process color
> space as defined in the DeviceN (NChannel) Process
> dictionary.
> base/gscspace.c
> base/gscspace.h

2019-04-30 11:49:07 -0700
Michael Vrhel <michael.vrhel@artifex.com>
e1f9edfcafc3f73f43b85afacb8d788f7e573cf6

> Add methods to detect pure process colors in Sep and DeviceN color spaces
> When the colors in the separation or Devicen color space consist all of
> one particular process color model, we would like to consider the use
> of the alternate tint transform color space as an indication of the intent
> for these color spaces (assuming the attributes information was not there).
> For example, if we had a DeviceN color space
> of [Cyan Magenta] and the alternate tint transform color space was a
> CMYK ICC color space, that would be a hint that we should treat the color
> as being in that space. This commit provides us with the information as
> to the colorants all being in one particular process space which is
> a requirement.
> base/gscdevn.c
> base/gscsepr.c
> base/gscspace.h

2019-04-30 15:26:11 +0100
Robin Watts <Robin.Watts@artifex.com>
b380b655b64a37a77b98dab881ff0aad0c62586e

> Nobble pdfwrite genrated /ID entries in cluster tests.
> Avoid having the /ID values depend on the output filename
> in cluster testing. This should allow us to compare the
> results of pdfwriting between gs and gpdl. It also removes
> one more thing to get right when trying to manually reproduce
> cluster results.
> devices/vector/gdevpdf.c

2019-04-30 10:40:20 +0100
Robin Watts <Robin.Watts@artifex.com>
fd5758e4d55c510fa4ad0047c10b13cf928cfb74

> Make pdfwrite fileID calculations consistent on cluster.
> Nobble the timing calculations under CLUSTER builds, so
> we get consistent results.
> Also, move to using realtime, rather than usertime (as the goal
> is to have something different each time).
> devices/gdevpdfimg.c
> devices/vector/gdevpdf.c

2019-04-29 17:58:42 -0700
Michael Vrhel <michael.vrhel@artifex.com>
35c40cdaa2f79432f01733d3f69f95947db5d60b

> Change implementation of gsicc_support_named_color
> gsicc_support_named_color now will have available all the names
> in the DeviceN color space. If there are no spot names
> in the list, it will return false ensuring that the process colors
> will be color managed.
> base/gscdevn.c
> base/gscsepr.c
> base/gsicc_cache.c
> base/gsicc_cache.h

2019-04-29 18:39:23 +0100
Robin Watts <Robin.Watts@artifex.com>
8026e11e50306a51dc3bb6f2bdc57f34986acd62

> Fix undefined behaviour in rops.
> We were indexing off the end of a static table. Annyoingly,
> valgrind has failed to pick this up for years.
> base/gsroprun.c

2019-04-29 11:14:06 +0100
Ken Sharp <ken.sharp@artifex.com>
0bafbd9c1273fab0dc79fd20db0ffc4443683f96

> PDF interpreter - Decode ToUnicode entries of the form /Identity-H/V
> Bug #701003 "Text searchability broken due to omission of /ToUnicode /Identity-H"
> The PDF references from 1.2 too 2.0 all state that the value associated
> with a ToUnicode key in a FontDescriptor must be a stream object. However
> this file (and one case seen previously, bug 687351) have FontDescriptor
> dictionaries where the value associated with a /ToUnicode key is a
> name object, in both cases /Identity-H.
> Although this is clearly not legal, Acrobat not only tolerates it, it
> actually uses it for search/copy/paste (see bug 701003 for details).
> Without the key Acrobat is unable to successfully search the output file.
> We can't simply preserve the name object as a ToUnicode value; when
> handling ToUnicode we actually decode the CMap and build a
> GlyphNames2Unicode map (an internal representation of the G2U data
> produced by the Microsoft PostScript printer driver). When writing the
> output file we use that information to get a Unicode value for each
> character we write, and build a new ToUnicode CMap using that.
> This commit tackles the problem by pre-scanning for a name object and
> then checking to see if its Identity-H or Identity-V (although we have
> not seen an Identity-V, there seems no reason why it wouldn't be
> equally valid). If we find either of these then we construct a
> GlyphNames2Unicode table for all possible values (0 - 65535) and store
> that with the font as normal. When we write the output file we only
> write the required entries for the subset font, so we write a now
> completely legal ToUnicode CMap, and Acrobat is equally happy with that
> as the original name.
> If the ToUnicode value isn't a name object, or isn't one of the
> identities then we proceed as before. This means we will print a
> warning for non conforming ToUnicode entries and ignore them.
> Resource/Init/pdf_font.ps

2019-04-28 19:59:12 -0700
Michael Vrhel <michael.vrhel@artifex.com>
0b9c45fa86f7736e7fec170a135efa83636283ba

> Have CMYK colors in DeviceN color spaces color managed when going to CMYK devices
> The current code was only doing color management of DeviceN CMYK when going to
> the separation device (e.g. tiffsep and psdcmyk). It should also be doing this
> for pure CMYK devices like tiff32nc etc. With RGB devices we will be going through
> the alternate tint transform. The would only pertain to DeviceN color spaces composed
> of only process colors (e.g. [Cyan Magenta]). If a spot color was included we would
> be going through the alternate tint transform for a device like tiff32nc.
> So with this commit if you have a command line like
> -sDEVICE=tiff32nc -sDefaultCMYKProfile=src_cmyk.icc -o output.tif -f input.pdf
> it will treat the CMYK values in the DeviceN color space the same as a DeviceCMYK
> source color and make use of the src_cmyk.icc profile to handle those. As mentioned
> this worked with psdcmyk and tiffsep but not standard CMYK devices.
> base/gxcmap.c

2019-04-01 20:30:23 +0100
Robin Watts <Robin.Watts@artifex.com>
68511243fb4817e8170023d1d6922956325a139d

> Move transfer functions to 16 bits.
> This means that in 'deep' modes, we sample them in 257 places
> (0000,0100,....ff00,ffff) rather than 256 (00,01,...ff), and
> in 16 bits rather than 8. We also interpolate them on reading.
> This in turn increases the size of the data put into the clist.
> base/gdevp14.c
> base/gstparam.h
> base/gstrans.c
> base/gstrans.h
> base/gxblend.c

2019-04-26 21:24:28 -0700
Michael Vrhel <michael.vrhel@artifex.com>
e2507c443fcd1456ff65695901339fc96f4bbf73

> Fix improper logic in named color support
> base/gscdevn.c

2019-04-26 16:47:29 -0700
Michael Vrhel <michael.vrhel@artifex.com>
fb9f948ec79d18c2574a9a0bdaf9ab1aeee21e58

> And one more fix to the named color blending.
> Fixing issues introduced in previous commit.
> base/gsicc_cache.c

2019-04-26 11:25:19 -0700
Michael Vrhel <michael.vrhel@artifex.com>
e1a534e843743230019de57a36a04129347a505e

> Fix named color blending
> Named color blending was not working the way intended. This was clearly visible
> when pushing a gradient through. This now does a reasonable result blending
> the first colorant with white and then subsequent colorants with the current
> colorant.
> base/gsicc_cache.c

2019-04-26 14:40:22 +0100
Chris Liddell <chris.liddell@artifex.com>
6fcd76043a6fe69ca2b8ecac498f9ca79829931f

> Bug 700973: CIDFont substitution: avoid multiply applying metrics
> findCIDFont: we make various efforts to produce a synthetic font style
> (bold, light, italic etc) if the actual type face style is not available.
> In these cases, we have to avoid reusing an existing CIDFont substitute because
> the CDevProc will have been 'hooked' to apply the width metrics drawn from the
> PDF file. We want to, if at all possible, use the CIDFont as originally loaded.
> Resource/Init/pdf_font.ps

2019-04-25 17:20:12 +0100
Ken Sharp <ken.sharp@artifex.com>
cb1414723d95c6813e8e44a8c0529f0063998378

> pdfwrite - handle user-defined PCL fonts with character codes > 256
> Bug #700996 "PCL Files Processing failure"
> The problem is that we cannot handle a character code in excess of 256
> in a PDF Font (we would have to create a CIDFont, which is too much
> work). This was causing us to fail to attach a PDF font to the current
> (user-defined PCL) font. When we later tried to retrieve the font
> that caused a seg fault.
> If we simply return an error when there is no attached font then the
> fallback machinery will take us through generating an image instead.
> This, however, caused the original file not to work properly, text was
> going missing. Forcing 'early accumulator' to be 0 so that we created a
> new font resolved the problem. Its better, however to remove that entire
> section of code, since it now has no purpose.
> This commit results in a PDF file with the correct appearance. A number
> of out test suite files exhibit small differences, particularly at
> low (75 dpi) resolution, but nothing is actually incorrect.
> devices/vector/gdevpdti.c
> devices/vector/gdevpdtt.c

2019-04-24 12:27:16 -0700
Michael Vrhel <michael.vrhel@artifex.com>
7b1d3a9fcc40d0dd2dc779830abe21da83183c11

> Fix two issues in replace color management.
> Always do replacement for this demo implementation and
> use get_color_mapping_procs_subclass to get the device
> color mapping procs. The old method had an issue with
> overprint compositor and psdcmyk device.
> base/gsicc_replacecm.c

2019-04-24 11:20:57 -0700
Michael Vrhel <michael.vrhel@artifex.com>
29d227c79fa8554e65eb1e081a81cbcb13b76b8a

> Avoid double free in replace color management code
> base/gsicc_replacecm.c

2019-04-24 10:27:25 -0700
Michael Vrhel <michael.vrhel@artifex.com>
2f947ad5c32968cb113cb3ba4958e239dcf730a5

> Use space in calls to gs_strtok
> base/gsicc_manage.c

2019-04-23 21:32:00 -0700
Michael Vrhel <michael.vrhel@artifex.com>
8881a51d55df7df70f4e0083be8569e09213dfba

> Fix several warnings and issues from last commit.
> base/gscsepr.c
> base/gsicc_cache.c
> base/gxcmap.c

2019-04-24 10:48:07 +0100
Robin Watts <Robin.Watts@artifex.com>
7f34ef8c946be47d5a5dcc412b3da608a0066c44

> Fix typo in 16bit code in gxblend.c
> src_shape needs to be 16bits, not a byte now.
> base/gxblend.c

2019-04-23 20:11:24 -0700
Michael Vrhel <michael.vrhel@artifex.com>
fea343608ce813156ae8ffc2ea6d42fc5f198e64

> Add support for named color when going to separation devicen_icc_cmyk
> When going through named color processing with the target device either
> tiffsep or psdcmyk, cmap_devicen_direct and cmap_devicen_halftoned were
> doing an additional cmyk icc mapping. This mapping was needed to ensure
> that CMYK values matched DeviceN mapping values of CMYK+Spot where the Spot
> value was 0 percent. With the use of named color mapping, we want to avoid this
> icc mapping. Fixing this issue involved adding a boolean value to the DeviceN and Separation
> color space params to indicate if the spot colorant(s) are supported by the
> named color profile. This determination is made during the install of the
> device so that it need only be done once. To do that, we needed to add a
> method, gsicc_support_named_color, in gsicc_cache.c, which goes with
> gsicc_transform_named_color, to indicate if the spot colorant is defined in
> the data that we are using. Tested with tiff24, tiff32 and psdcmyk to ensure
> named color mapping is occurring and that no additional mapping occurs after
> that.
> base/gscdevn.c
> base/gscsepr.c
> base/gscspace.h
> base/gsicc_cache.c
> base/gsicc_cache.h
> base/gxcmap.c

2019-02-19 16:38:26 +0000
Robin Watts <Robin.Watts@artifex.com>
f0f2fa2a084758bcf99409ce19c2c1f93dc04d32

> Deep color transparency
> Previously, all transparency blending has been done using the
> pdf14 compisitor working in 8 bits. Here, we extend it to be
> capable of working in 16 bits.
> When the compositor is created, it looks at the underlying device;
> if that device uses more than 8 bits per component (plus 8 bits
> for tags, if tags are in use), then we use 'deep' (i.e. 16 bit
> per component) pdf14 buffers.
> base/gdevdflt.c
> base/gdevmem.c
> base/gdevp14.c
> base/gdevp14.h
> base/gdevprn.c
> base/gsptype1.c
> base/gstrans.h
> base/gxblend.c
> base/gxblend.h
> base/gxblend1.c
> base/gxclrect.c
> base/gxclthrd.c
> base/gxcolor2.h
> base/gxp1fill.c
> base/gxpcolor.h

2019-04-22 15:33:02 +0100
Robin Watts <Robin.Watts@artifex.com>
ba8ff34e302ec3e65bd47b14796dcfaef157527f

> Hack bmpcmp to accept 16bpc PSD files.
> We ignore the bottom bytes of the pixel data.
> toolbin/bmpcmp.c

2019-04-19 08:16:57 +0100
Chris Liddell <chris.liddell@artifex.com>
d8db95fb00af2fb543439242d3ac122aead88c94

> Fix some structure element name confusion in base/sjbig2_luratech.c
> A previous commit slightly modified some of memory management for jbig2 global
> data. In mirroring those changes to the Luratech version of the code, a couple
> of places were left with the structure element names from the jbig2dec version.
> base/sjbig2_luratech.c

2019-04-16 19:30:02 +0100
Robin Watts <Robin.Watts@artifex.com>
b399f849ce1aa391da1abeb23fd32e376b56e522

> Bug 700624: Fix "full" pattern fills with gaps between cells.
> GS has an optimisation in it, whereby if an uncolored pattern fill
> is completely full (the mask is full of 1's), it doesn't bother to
> store the mask. When such a pattern is filled, the code knows just
> to fill the whole thing.
> Sadly, this optimisation breaks down when the cells have an X or Y
> step that means there should be gaps between the instances. GS
> currently fills the whole thing, gaps and all.
> To fix this, we either need to fix all the different fill routines
> to cope with this case, or (as I have done here), disable the
> optimisation in the case when the X and Y step is larger than the
> 'size' of the pattern cell.
> base/gxpcmap.c

2019-04-18 16:58:41 +0100
Chris Liddell <chris.liddell@artifex.com>
d86210973df93ccca0befd56afba2132da925ebc

> Bug 700986: Remove the crazy md5 file copying nonsense
> To preserve building as a standalone test exe, we avoided using Ghostscript
> includes in the md5 source and header files, but dynamically add them to
> copies of the files during the build. Since we no longer need/care for the
> stand alone exe, remove the build complication, and just include the header
> file normally.
> base/gsmd5.h
> base/lib.mak
> base/md5main.c
> doc/Develop.htm
> windows/ghostscript.vcproj
> windows/ghostscript_rt.vcxproj

2019-04-18 14:24:04 +0100
Alexander Grahn <a.grahn@fzd.de>
a3be0c9d86981313d8724f6c29f2feaa07152976

> Bug #700984 "BMC pdfmark: BMC keyword missing from content stream (patch included)"
> Not sure how this has gone unnoticed for so long. The 'BMC' keyword was
> missing from the emission of the content of the pdfmark. The EMC and
> BDC pdfmarks seem to be OK.
> Thanks to Alexander Grahn for identifying the problem and supplying a
> patch to resolve it.
> devices/vector/gdevpdfm.c

2019-04-18 11:18:35 +0100
Ken Sharp <ken.sharp@artifex.com>
a7cccaac16e6fc252496ab630f7423262e05756d

> Fix commit d89bae568d5015144e5d68fea8221543111e119e
> Commit d89bae568d5015144e5d68fea8221543111e119e contained an oversight
> which unfortunately was missed due to the testing cluster being in a
> state of flux.
> Its possible for fonts to have a Subtype of Type1C as well as the
> noted CIDFontType0C and CIDFontType1C, and we need to cater for that
> as well.
> This mostly affected some of the Ghent Working Group test files, and
> not much else, so I've chosen just to push an addditional commit.
> Resource/Init/pdf_font.ps

2019-04-17 15:53:14 +0100
Ken Sharp <ken.sharp@artifex.com>
d89bae568d5015144e5d68fea8221543111e119e

> PDF interpreter - change detection of CFF CIDFont types
> Bug #700982 "Error: unrecognized font file starts with <01000D02>"
> The code in pdf_font.ps to detect font types, and call an appropriate
> font loader works (in part) by reading the first 4 bytes from the font
> stream, and then using that as the key for a dictionary where the
> values are the font loading procedures.
> Most font types have a 'magic number' or similar at the start of the
> font data, but CFF fonts do not. In fact the header of a CFF font is
> highly variable, the only thing we can rely on being the font version
> byte (0x01), the remaining 3 bytes are variable.
> We've tackled this previously by simply adding more different varieties
> of string values, but this seems nonsensical. There are too many
> possible values for this to work reliably.
> Ideally I'd recode this to use the CIDFont Subtype to select the
> correct font loader, but that would mean recoding all of this, which is
> more work than I want to tackle in this code. Instead I've chosen to
> only have one single 'tag' in the dictionary, and I've extended the code
> handling the case where we don't find a tag in the dictionary.
> Previously this checked to see if the first two bytes of the string
> were <8001> and otherwise failed. I've modified this so that if the
> bytes are not <8001> then we check the dictionary /Subtype key. If its
> not present or isn't either CIDFontType0C or 1C then we still throw
> an error. Otherwise we discard the string we read, replace it with the
> one and only string we have stored in the font_tag_dict dictionary and
> proceed.
> If there is ever a version 2 of the CFF specification this will fail,
> but we can add a check for the version number if that ever happens
> (seems highly unlikely).
> Resource/Init/pdf_font.ps

2019-04-16 09:20:44 +0100
Ken Sharp <ken.sharp@artifex.com>
cf58dd08435d89e5f205127c518595c0d7441535

> Documentation - describe the ink_cov device
> Following up from a question on Stack Overflow, the ink_cov device isn't
> actually described anywhere. Add a description of the device and how its
> output differs from the inkcov device.
> At the same time, add the inkcov device(s) to the table of contents in
> devices.htm and also add the bit and bbox devices which were not listed
> in the TOC.
> doc/Devices.htm

2019-04-15 08:25:08 +0100
Ken Sharp <ken.sharp@artifex.com>
5fa1928af0eb110115d34eb4c43bb529dda6f697

> PDF interpreter - synthesise appearance for text Widget comb fields
> Bug #700967 "Warning Combed form fields are not yet implemented"
> Comb fields draw a string into a series of 'combs' or boxes, one
> character per box. As usual there are no guidelines in the specification
> as to how to draw the individual characters.
> I've chosen to centre each character in the box it is draw in, because
> drawing it from the origin of the box tends to cause collisions with the
> vertical/horizontal lines delineating the box itself (in the one example
> file I have). This may cause slightly odd appearance if a field uses
> mixed upper/lower case, as the text will jump up and down vertically.
> The example file supplied has a fault, one of the comb fields has a
> value (/V) string which is longer than the /MaxLen value for the field.
> This indicates to me a fault with the form filling application which
> should not permit this. Acrobat truncates the string, I've chosen to
> not render the string at all, and emit a warning on the back channel.
> None of our test suite files show any differences at all; either we
> don't have an examples of this kind of field already, or they all have
> appearance streams.
> Resource/Init/pdf_ops.ps

2019-04-12 09:53:44 +0100
Chris Liddell <chris.liddell@artifex.com>
6d8e1957175ec98443a6bc0d8c3cda6bfdced801

> Bug 700968: Fix TTF Format 4 (segmented) cmap parsing
> The format 4 parsing was incorrect, but in a manner only exposed by reading
> an out of spec cmap.
> The spec implies that the character codes in the cmap segments should be non-
> overlapping, and the segments should be in order of lowest-to-highest codes.
> We were imposing (*not* enforcing) that condition, but forcing the start code
> of the current segment to be greater than size of the range of codes we've
> already read. This, basically, has no effect on fonts that adhere correctly
> to the spec.
> The fonts embedded in the files for Bug 700968 do not conform to the spec. For
> example, the 'Z_C00002.tmp' font has the first 92 segments in the cmap with
> start code and end code both set to 33. The above imposing of the no-overlap
> and order of segments meant that when we got past those first 92 segments, we
> were forcibly using character codes 92 and upwards.
> Removing the code imposing those conditions causes these files to render
> correctly, and shows no regressions in our existing test suite.
> Resource/Init/gs_ttf.ps

2019-04-11 12:16:57 -0700
Nancy Durgin <nancy.durgin@artifex.com>
adc75668cc254ead4929748fdb5ca988353f91eb

> Change s_jbig2decode_release() to free the global context in some cases
> Basically, if state->global_struct is NULL, it means the library should
> free the global_ctx when it's done with it. This is the case when used in
> gpdf (C implementation of PDF).
> If the state->global_struct is non-NULL, then it is a memory-managed
> value that the interpreter will eventually clean up. This is the case
> when used in gs (PS implementation of PDF).
> base/sjbig2.c
> base/sjbig2_luratech.c

2019-04-11 08:49:14 -0700
Nancy Durgin <nancy.durgin@artifex.com>
fd3730fa8429f1ea58b2f5a5bfc1eecd3f835247

> Change s_jbig2decode_set_global_data to take a separate pointer for global_ctx
> This is so gpdf can pass NULL for the 'gd' pointer, since it doesn't care
> about garbage collection.
> base/sjbig2.c
> base/sjbig2.h
> base/sjbig2_luratech.c
> base/sjbig2_luratech.h
> psi/zfjbig2.c

2019-04-10 14:23:39 +0100
Chris Liddell <chris.liddell@artifex.com>
06c920713e11bce9bd541bbf9bf294b2ba16aee8

> Bug 700952: re-introduce over/underflow workaround
> Commit 355434f4b1bbe8c4f98cafad5a6868aa2f0eaae1 reverted a workaround that
> compensated for over/underflow in Freetype's TTF hinting (related to freedom
> and projection vector calculations). That problem no longer exists in recent
> Freetype releases, and the workaround actually caused other issues to occur
> with hinting.
> What wasn't obvious was that the workaround also protected over/underflow
> issues relating to the unitsPerEm value.
> So this re-instates the workaround, but bases the decision on how the final
> scale is distributing between the Freetype "size" and the Freetype matrix on
> the unitsPerEm value (this is relevant for all font types as, for non-TTF,
> font types, Freetype derives the unitsPerEm from the FontMatrix (for PS type
> fonts).
> Also fixes Bug 700875
> base/fapi_ft.c

2019-04-10 14:51:12 +0100
Chris Liddell <chris.liddell@artifex.com>
35d9fc4d2a9dd85fc8497cb68389ec6eded73fcb

> Update the copyright string.
> base/gscdefs.h

2019-04-10 13:54:57 +0800
Sebastian Rasmussen <sebras@gmail.com>
08b91a2141df36d2f733e1822601ad06941674f2

> Detect system jbig2dec library using pkg-config if available.
> Otherwise fall back to traditional presence checking.
> configure.ac

2019-04-10 20:06:04 +0800
Sebastian Rasmussen <sebras@gmail.com>
9f111ddc1cdb3cee329fb71e6ce4fd31c150f039

> jbig2dec: Improve jbig2dec-specific gitignore.
> jbig2dec/.gitignore

2019-04-10 13:48:05 +0800
Sebastian Rasmussen <sebras@gmail.com>
d72c6cdcd686a7dd0836f8a3afc4e23b5bb45144

> jbig2dec: Add pkg-config file and allow for it to be installed.
> jbig2dec/Makefile.am
> jbig2dec/configure.ac.in
> jbig2dec/jbig2dec.pc.in

2019-04-10 18:23:26 +0800
Sebastian Rasmussen <sebras@gmail.com>
300dd807b47d48b7b8368ca7b6db3db0312fa19b

> jbig2dec: Check that header version matches library version.
> jbig2dec/jbig2.c
> jbig2dec/jbig2.h

2019-04-10 18:00:35 +0800
Sebastian Rasmussen <sebras@gmail.com>
a2f646ac8a07e7d019ddcb9e0ca2bdff1f5c740f

> jbig2dec: Expose version number in header.
> Since the version number should only be specified in one location,
> the public jbig2dec header, autogen.sh will not regenrate the
> autoconf input file configure.ac.
> jbig2dec/autogen.sh
> jbig2dec/config_win32.h
> jbig2dec/configure.ac.in
> jbig2dec/jbig2.h
> jbig2dec/jbig2dec.c

2019-04-10 13:44:23 +0800
Sebastian Rasmussen <sebras@gmail.com>
90e56e3d9195f1aa19977629f2d3d3b4ec4d72cf

> jbig2dec: Add empty m4 directory to silence libtool warning.
> jbig2dec/Makefile.am

2019-04-10 13:40:08 +0800
Sebastian Rasmussen <sebras@gmail.com>
cb4d8dee4974e85b8c54f553520bded6fabd7b74

> jbig2dec: Silence automake warning about setting CFLAGS directly.
> Setting AM_CFLAGS is added to CFLAGS, adding the wanted XCFLAGS.
> jbig2dec/Makefile.am

2019-04-10 13:39:05 +0800
Sebastian Rasmussen <sebras@gmail.com>
f25171c4fc2a5e7cd6bd9ab0b96a5133c038425d

> jbig2dec: Silence automake warning about ar use.
> jbig2dec/configure.ac

2019-03-05 18:09:20 +0800
Sebastian Rasmussen <sebras@gmail.com>
9f1959fb44a4da0506c8ef7a8cbb0ccbef4cceea

> jbig2dec: Fix bug where realloc returns NULL.
> jbig2dec/jbig2_image.c

2019-04-10 05:11:16 +0800
Sebastian Rasmussen <sebras@gmail.com>
67c9175c4a601a447b22e84251ec8c33ac827277

> jbig2: Avoid integer overflow in custom allocator.
> base/sjbig2.c

2019-04-10 05:10:29 +0800
Sebastian Rasmussen <sebras@gmail.com>
a69dd377c6f07e08ea4f895eabb974c92adccab4

> jbig2: Print messages from jbig2dec, do not just count them.
> base/sjbig2.c

2019-04-03 11:01:18 -0700
Ray Johnston <ray.johnston@artifex.com>
1fb3a69df53754f6a000152606f52b2f4a658b97

> Fix crash reported by customer #531 with multi-threaded rendering.
> This was a race condition where threads were continuing to be started
> while we were tearing threads down. This doesn't occur with most usages
> because we render the entire page, but with the customer's device, it
> stops reading before the last line, but the multi-threading rendering
> logic tried to keep starting threads (up to NumRenderingThreads) to
> have later bands available.
> The solution is to wait for all threads to be in the "THREAD_DONE"
> state before freeing the threads.
> Also, since the color_usage_array of the main thread is shared by the
> rendering threads, wait until the threads are shut down before freeing
> that.
> base/gxclist.c
> base/gxclthrd.c

2019-03-19 13:49:49 +0000
Chris Liddell <chris.liddell@artifex.com>
d9055d0a350ca7681fb8f4854ed4f1c3bf7ed570

> Bring master up to date with 9.27 release branch
> Product string, dates etc for 9.27 release candidate
> News and changelog for 9.27 release candidate
> Update product string, dates etc for 9.27 release
> News/History9.htm revisions also.
> base/version.mak
> doc/DLL.htm
> doc/Deprecated.htm
> doc/Develop.htm
> doc/Devices.htm
> doc/Drivers.htm
> doc/Fonts.htm
> doc/History9.htm
> doc/Install.htm
> doc/Internal.htm
> doc/Language.htm
> doc/Lib.htm
> doc/Make.htm
> doc/News.htm
> doc/Ps-style.htm
> doc/Ps2epsi.htm
> doc/Psfiles.htm
> doc/Readme.htm
> doc/Release.htm
> doc/SavedPages.htm
> doc/Source.htm
> doc/Unix-lpr.htm
> doc/Use.htm
> doc/VectorDevices.htm
> doc/WhatIsGS.htm
> doc/gs-vms.hlp
> doc/sample_downscale_device.htm
> doc/subclass.htm
> doc/thirdparty.htm
> man/dvipdf.1
> man/gs.1
> man/gslp.1
> man/gsnd.1
> man/pdf2dsc.1
> man/pdf2ps.1
> man/pf2afm.1
> man/pfbtopfa.1
> man/printafm.1
> man/ps2ascii.1
> man/ps2epsi.1
> man/ps2pdf.1
> man/ps2pdfwr.1
> man/ps2ps.1

2019-04-04 10:44:50 +0100
Chris Liddell <chris.liddell@artifex.com>
12e31a72ffe1d2da30bf2c1976795b72ccd320b2

> Update jbig2dec stuff for 0.16 release
> jbig2dec/CHANGES
> jbig2dec/config_win32.h
> jbig2dec/configure.ac
> jbig2dec/jbig2dec.1

2019-04-03 03:28:01 -0700
Robin Watts <Robin.Watts@artifex.com>
76c6de5428936c8fdb7269d7fcc31d4bdc83d745

> Fix problems with "typedef struct foo_s foo;" redefinitions.
> In the header revamp, I'd left various places where we
> use the above formulation in more than one location. This
> is fine with all the C compilers I tested it on, but seems
> to update gcc 4.1.2.
> This effect can be seen on later gcc's by using
> "-std=gnu89 -pedantic".
> This commit tweaks the code to avoid redefinitions of this
> kind.
> base/gsfont.h
> base/gsgdata.h
> base/gspath.h
> base/gspenum.h
> base/gxchar.h
> base/gxdevcli.h
> base/gxfont.h
> base/gxiodev.h
> base/gxpath.h
> base/gxtext.h
> base/lib.mak
> psi/imemory.h

2019-04-03 08:37:41 +0100
Ken Sharp <ken.sharp@artifex.com>
7146b7292e27acc54d23b48472f6851ae9b51d8c

> Fix PDFX_def.ps
> Bug #700942
> For some reason Git did a merge with this file when I made the change,
> and it messed it up. Since we don't test these files, it didn't get
> noticed.
> lib/PDFX_def.ps

2019-04-02 10:55:27 +0100
Ken Sharp <ken.sharp@artifex.com>
2c97be9f328babb7b544ab3610e6fce05e30cdc8

> pdfwrite - change the example PDF/A and PDF/X scripts
> From Bug #700930 "Typo in example command for PDF/X-3 in VectorDevices.htm"
> The reporter claimed that the (mis-spelled) command didn't work, which
> was not surprising, since it contained a typo. After fixing the
> documentation the reporter claimed that the command didn't work. This
> is true and was missed because of the misleading title.
> The PDFX_def.ps file was mistakenly pulling the ProcessColorModel from
> systemdict, which would only be set if this was set on the command line.
> The real problem is the fact that our setpagedevice/currentpagedevice
> code doesn't truly reflect the device setup, so changes to the
> ProcessColorModel caused by setting ColorConversionStrategy are not
> reflected in the values returned by currentpagedevice.
> This commit updates PDFX_def.ps to chaeck the ColorConversionStrategy
> instead, which is more reliable, and then use the ProcessColorModel
> from the currentpagedevice as a fallback if ColorConversionStrategy
> is not set. (actually this should not be possible)
> Update PDFA_def.ps similarly; although it was using the currentpagedvice
> this is not a reliable method.
> Finally; reformat the files, add some extra comments describing what the
> code is doing, make it clearer that these files *should* be customised
> and add additional some basic instruction on customising them.
> lib/PDFA_def.ps
> lib/PDFX_def.ps

2019-04-02 08:26:09 +0100
Ken Sharp <ken.sharp@artifex.com>
978b03b453245c2a48abaee5addea3b7e025a2ed

> Fix another typo.
> HTML is annoyingly impossible to spell-check :-(
> doc/VectorDevices.htm

2019-04-01 16:15:21 +0100
Ken Sharp <ken.sharp@artifex.com>
2983be3f871e480b6567f5ce5c16206a026851fe

> PS interpreter - prevent user code overriding some commad line switches
> Bug #700935 "defining BATCH causes typecheck in ifelse"
> A (surprisingly large) number of command line switches are checked at
> various points in gs_init.ps, but use the 'current' definition of the
> key, rather than explicitly checking systemdict, which is where the
> command line controls are stored.
> This meant that user code could (deliberately or accidentally) override
> the system definition and cause errors or unexpected behaviour.
> Resource/Init/gs_init.ps

2019-04-01 16:12:33 +0100
Ken Sharp <ken.sharp@artifex.com>
34a94a5d72f8a339cad4c2e2140519c33b58de79

> tiffsep devices - add TIFFDateTime to get_params
> We need to add this parameter to both put_params and get_params, or it
> will not work properly.
> devices/gdevtsep.c

2019-04-01 13:30:57 +0100
Ken Sharp <ken.sharp@artifex.com>
87e4b35c9fc15434d710f86aa265501cad61c34f

> Tiff devices - Honour the TIFFDateTime parameter
> The TIFFDateTime switch can be used to disable writing the date and
> time into the tags of TIFF files. However, the tiffg3, tiffg4, tiffsep
> and tiffsep1 devices weren't honouring the parameter.
> I believe this also affected the tiff32 and tiff8 devices, all the
> tiffscaled devices and teh tiffcrle device.
> Although gdevtfax.c read the parameter, it didn't transfer it to the
> devcie structure. The tiffsep and tiffsep1 devices didn't even read it.
> I can't help thinking that having our tiff support spread over 19
> different devices and 3 source files
> devices/gdevtfax.c
> devices/gdevtsep.c

2019-04-01 10:58:11 +0100
Ken Sharp <ken.sharp@artifex.com>
b987c511229ba0b70e6a7691366d530fa8db7444

> pdfwrite - completely remove the old colour management
> Also remove all references (I hope) from the documentation.
> While we're changing the docs, remove references to ps2pdf where we are
> really referring to pdfwrite, rewrite the information on LZW Encoding,
> update the 'Opitimize' distiller param note, add some covering words
> about the faxt that pdfwrite doesn't permit the full range of options
> in the LCMS2 implementation that rendering devices do, note that the
> example PDFX_def.ps needs to be modified (cribbed from PDF/A).
> devices/vector/gdevpdfg.c
> devices/vector/gdevpdfi.c
> devices/vector/gdevpdfp.c
> devices/vector/gdevpsdf.h
> doc/VectorDevices.htm

2019-04-01 08:20:52 +0100
Ken Sharp <ken.sharp@artifex.com>
f5bd9757cffeb8b173cdde161b39abd381e325c3

> Documentation changes
> Bug #700930 "Ghostscript - Typo in example command for PDF/X-3 in VectorDevices.htm"
> doc/VectorDevices.htm
> lib/PDFX_def.ps

2019-03-29 15:43:14 +0000
Robin Watts <Robin.Watts@artifex.com>
086390943b223cd726d7f63ad076b48e57ceae0f

> Fix Downscaler ETS brokenness.
> We are only supposed to use ETS if requested. We pass in a flag to
> say whether to use it - probably best, on balance, not to ignore it.
> base/gxdownscale.c

2019-03-28 10:36:53 +0000
Chris Liddell <chris.liddell@artifex.com>
3929dbaed570ba58cccbf600ba58158ab4fafd8a

> Revise gs.c to use the gsapi API.
> It's probably better if our own code reflects the way we recommend others to
> code.
> psi/gs.c

2019-03-28 09:21:37 +0000
Chris Liddell <chris.liddell@artifex.com>
a87c116174ef574465ab12493ef6d0c575bda60d

> Fix sefault with 'so' build.
> The loaders were passing an unitialise pointer into gsapi_new_instance()
> meaning we might try to dereference the pointer to get to the shared portion
> of the library context.
> Initialise the pointer to NULL.
> Apply the same fix to everywhere that uses gsapi_new_instance.
> pcl/pl/plwmainc.c
> pcl/pl/realmain.c
> psi/apitest.c
> psi/dmmain.c
> psi/dpmain.c
> psi/dwmain.c
> psi/dwmainc.c
> psi/dxmain.c
> psi/dxmainc.c
> toolbin/halftone/gen_stochastic/gen_stochastic.c

2019-03-27 14:41:13 +0000
Chris Liddell <chris.liddell@artifex.com>
9723b898561c3cd7b9f207c9976994671940df56

> Update thirdparty.htm: Freetype and jbig2dec versions
> doc/thirdparty.htm

2019-03-27 08:08:04 +0000
Chris Liddell <chris.liddell@artifex.com>
a21912a4c7c2a0cbc79c1a86df77b63bcae850fb

> Add license file for cups/libcups
> cups/LICENSE.txt

2019-03-26 16:26:11 +0000
Ken Sharp <ken.sharp@artifex.com>
cdd481e5406b8fd07f0cc9b771adfd6877028d96

> Fix valgrind error with PXL patterns and high level devices
> Bug #700573 " Uninitialised colors used in path plotting"
> When the current colour space is a pattern, and the saved high level
> colour space is also a pattern, we were checking every possible
> component of ccolor.paint.values in both spaces against each other.
> The problem is that in gx_hld_save_color we set almost all the values to
> 0, but then copy a single uninitialised value into the 0th index.
> This leads to a valgrind error. Henry points out that the PostScript
> interpreter has a hack specifically to work around this in zcolor.c,
> zsetcolor() at around line 313.
> This is wasteful, its far better (IMO) to rearrange the logic in
> gx_hld_saved_color_equal(), we already bail out early if the colour
> spaces are not equal. If the spaces are patterns, then there's no point
> in comparing the device components, instead compare the pattern IDs
> *before* we compare the device components, if they are the same then
> return true, if they are different return false.
> This avoids us having to check 2 sets of 64 values, and also avoids us
> having to set 64 values every time we create a pattern.
> base/gxhldevc.c
> psi/zcolor.c

2019-03-26 15:14:49 +0000
Chris Liddell <chris.liddell@artifex.com>
519326a98c1d2172da280305fef0a3a52ddc65bc

> Tweak the pcl/LICENSE to make a little more sense
> It hadn't been revised really for the "new" directory structure.
> It will probably benefit from a more substantial revisit, but for now, this
> makes it less confusing.
> pcl/LICENSE

2019-03-26 09:23:56 +0000
Chris Liddell <chris.liddell@artifex.com>
db96dc02a83e45d2997315e52e77cb4c283c09ce

> Reword the 'greeting' to reflect the open source license.
> Resource/Init/gs_init.ps

2019-03-26 09:13:42 +0000
Chris Liddell <chris.liddell@artifex.com>
0371b3cef0e28fa603437faf983c7be8f2160214

> Fix 'greeting' and include COPYING in install
> The greeting message still referenced the obsolete 'PUBLIC' file. And
> doc/COPYING was missing from the list of files for install.
> Resource/Init/gs_init.ps
> base/unixinst.mak

2019-03-26 10:51:36 +0000
Chris Liddell <chris.liddell@artifex.com>
686204e73479a5fde722ca00a851cfb7f0d4186a

> Bug 700897: fix validation of -M and -N parameters.
> psi/imainarg.c

2019-03-25 19:35:07 -0700
Michael Vrhel <michael.vrhel@artifex.com>
81d801a07450227eee573aac5fc9259862b4a568

> Fix tiffsep_cmyk_cs_to_cm in tiffsep device
> When we were doing just a single or a couple spot colorants using something like
> -c "<< /SeparationColorNames [(Pantone 137 CVU)] /SeparationOrder [(Pantone 137 CVU)]>>
> setpagedevice" the colorants mappings were not getting properly cleared by
> tiffsep_cmyk_cs_to_cm causing fillpage to not clear out the page.
> devices/gdevtsep.c

2019-03-25 09:01:51 +0000
Ken Sharp <ken.sharp@artifex.com>
c70dc7911aaf559eeec0ced48f8504e24ba39b8a

> Coverity ID 337243 - remove dead code
> devices/vector/gdevpdfp.c

2019-03-23 10:29:59 +0000
Ken Sharp <ken.sharp@artifex.com>
4dc1cb5197292f3fa7548353c4208f507ca3b310

> Another trailing white space fix
> base/gdevp14.c

2019-03-23 10:26:29 +0000
Ken Sharp <ken.sharp@artifex.com>
8946e4418257a99ea029283405bc23b75a02e0a5

> PDF Interpreter - fix leading and trailing white spaces in pdf_draw.ps
> Commit 09c656e066777bd69bbd1902e6163fe3a8a39406 included some
> leading and trailing white spaces.
> Resource/Init/pdf_draw.ps

2019-03-20 13:55:54 +0000
Chris Liddell <chris.liddell@artifex.com>
f1fccd62b5d1010ecec2817b1b67f3b74b145d02

> tiffscaled: correctly select the downscaler when using ETS
> When tiffscaled uses ETS for the halftoning, and it's downscaling, we have to
> select the downscaling "core" based on the factor.
> base/gxdownscale.c

2019-03-19 17:49:14 +0100
Knut Petersen <knut_petersen@t-online.de>
eec855c9baeaa73c0208ed439fbbf1a0d48a447e

> Fix e005c87e09f67f37ce4ae2f80f24cf9182e86d8d
> Signed-off-by: Knut Petersen <knut_petersen@t-online.de>
> Resource/Init/pdf_font.ps

2019-03-19 10:06:38 -0700
Michael Vrhel <michael.vrhel@artifex.com>
2d67148ab19d5e278ec4dbe9929839a37f9961b7

> Bug 700744 Documentation typo.
> doc/GS9_Color_Management.pdf
> doc/GS9_Color_Management.tex

2019-03-19 08:32:46 -0700
Michael Vrhel <michael.vrhel@artifex.com>
09c656e066777bd69bbd1902e6163fe3a8a39406

> Bug 700686 Matte premultiplied images
> The undoing of the matte pre-blend must occur in the image color space. As such
> the group that the interpreter pushes must be that color space and we must make sure
> that we undo the pre-blend before any conversions for the group color space.
> Resource/Init/pdf_draw.ps
> base/gdevp14.c
> base/gxblend.c
> base/gxblend.h

2019-03-19 09:25:48 -0700
Ray Johnston <ray.johnston@artifex.com>
db24f253409d5d085c2760c814c3e1d3fa2dac59

> Fix lib/pdf2dsc.ps to use documented Ghostscript pdf procedures.
> We eliminated GS_PDF_ProcSet and pdfdict, but runpdfbegin, dopdfpages,
> and runpdfend are still available.
> lib/pdf2dsc.ps

2019-03-19 08:34:05 -0700
Ray Johnston <ray.johnston@artifex.com>
332c74c6ffe84acfc0fa80a99f6590a4be9f561b

> Fix bug 700719: SEGV with very large XStep/YStep and transparent patterns.
> At high resolutions, the bonkers XStep/YStep for the pattern could confuse
> the tile_by_steps_trans logic, and could overflow a 32-bit signed int causing
> a sign flip. Protect from this by checking to make sure we only fill within
> the fill_trans_buffer->rect.
> base/gxp1fill.c

2019-03-19 14:35:43 +0000
Ken Sharp <ken.sharp@artifex.com>
c5b92cc2dc9a20c8b6ba204f1e5a5e292bc53846

> Fix FillOrder tag for the TiffG3 and TiffG4 devices
> Bug #700255 "Option FillOrder doesn't work anymore"
> Commit 0ef309305417776a9f8b8cd143fbf3c5e89456b2 added the FillOrder
> switch to the 'tiff' class of devices, but the fax Tiff devices already
> processed that switch, and the commit did not remove the processing
> from those devices.
> This led to us trying to us ending up with the parameter in the params
> list twice when we executed get_params (once from the tiff device
> processing and once from the tiff fax device processing).
> When we then next execute a 'put_param', the list has a duplicate
> entry for FillOrder. We stop processing when we find the first entry,
> which means the second entry never gets processed, leading to an
> unused entry in the list, and that throws an error.
> The simplest way to fix this is to remove the duplicate 'get_param()'
> processing from the tiff fax devices, leaving it up to the generic
> Tiff device.
> devices/gdevtfax.c

2019-03-19 13:12:25 +0000
Chris Liddell <chris.liddell@artifex.com>
5eebbe1be2b097e541b14fecbd5a154c2cba1519

> Bump version number for release
> Resource/Init/gs_init.ps
> base/version.mak

## Version 9.27 (2019-04-03)

IMPORTANT: It is our intention, within the next 12 months (ideally sooner, in time for the next release) to make SAFER the default mode of operation. For many users this will have no effect, since they use SAFER explicitly, but some niche uses which rely on SAFER being disabled may need to start explicitly adding the "-dNOSAFER" option.

Highlights in this release include:

- We have extensively cleaned up the Postscript name space: removing access to internal and/or undocumented Postscript operators, procedures and data. This has benefits for security and maintainability.

- We have added a new "product": "gpdl". This is a rethink/redesign of the old "language_switch" product (pspcl6), and includes all the interpreters we develop based on the Ghostscript graphics library: Postscript, PDF, PCL6, PXL and XPS. This is experimental, and should be considered of beta testing quality, and thus is not built by default: it can be built by using the "experimental" target.

  `gpdl` uses a heuristic to judge the file type being passed to it. In general, it supports most of the widely used command line options for each interpreter, but compatibility is not complete (the practicalities of swapping interpreters means it is unlikely that full parity of command line options will be possible).

- Fontmap can now reference invidual fonts in a TrueType Collection for font subsitution. Previously, a Fontmap entry could only reference a TrueType collection and use the default (first) font. Now, the Fontmap syntax allows for specifying a specific index in a TTC. See the comments at the top of (the default) Fontmap.GS for details.

- IMPORTANT: We are in the process of forking LittleCMS. LCMS2 is not thread safe, and cannot be made thread safe without breaking the ABI. Our fork will be thread safe, and include performance enhancements (these changes have all be been offered and rejected upstream). We will maintain compatibility between Ghostscript and LCMS2 for a time, but not in perpetuity. Our fork will be available as its own package separately from Ghostscript (and MuPDF).

- The usual round of bug fixes, compatibility changes, and incremental improvements.

For a list of open issues, or to report problems, please visit bugs.ghostscript.com.

### Incompatible changes

- The process of "tidying" the Postscript name space should have removed only non-standard and undocumented operators. Nevertheless, it is possible that any integrations or utilities that rely on those non-standard and undocumented operators may stop working, or may change behaviour.

  If you encounter such a case, please contact us (either the #ghostscript IRC channel, or the gs-devel mailing list would be best), and we'll work with you to either find an alternative solution.

  One case we know this has occurred is GSView 5 (and earlier). GSView 5 support for PDF files relied upon internal use only features which are no longer available. GSView 5 will still work as previously for Postscript files. For PDF files, users are encouraged to look at MuPDF.

### Changelog

2019-04-03 09:27:46 +0100

2019-04-03 09:27:46 +0100
Chris Liddell <chris.liddell@artifex.com>
ef23f2457ff6c215d99189a0f78bf28f42d5f98c

> Update product string, dates etc for 9.27 release
> News/History9.htm revisions also.
> base/gscdefs.h
> base/version.mak
> doc/DLL.htm
> doc/Deprecated.htm
> doc/Develop.htm
> doc/Devices.htm
> doc/Drivers.htm
> doc/Fonts.htm
> doc/History9.htm
> doc/Install.htm
> doc/Internal.htm
> doc/Language.htm
> doc/Lib.htm
> doc/Make.htm
> doc/News.htm
> doc/Ps-style.htm
> doc/Ps2epsi.htm
> doc/Psfiles.htm
> doc/Readme.htm
> doc/Release.htm
> doc/SavedPages.htm
> doc/Source.htm
> doc/Unix-lpr.htm
> doc/Use.htm
> doc/VectorDevices.htm
> doc/WhatIsGS.htm
> doc/gs-vms.hlp
> doc/sample_downscale_device.htm
> doc/subclass.htm
> doc/thirdparty.htm
> man/dvipdf.1
> man/gs.1
> man/gslp.1
> man/gsnd.1
> man/pdf2dsc.1
> man/pdf2ps.1
> man/pf2afm.1
> man/pfbtopfa.1
> man/printafm.1
> man/ps2ascii.1
> man/ps2epsi.1
> man/ps2pdf.1
> man/ps2pdfwr.1
> man/ps2ps.1

2019-03-19 14:53:24 +0000
Chris Liddell <chris.liddell@artifex.com>
5c3344f40f95c4c8fd806265e4e6191d98e06be5

> News and changelog for 9.27 release candidate
> doc/History9.htm
> doc/News.htm

2019-03-19 13:49:49 +0000
Chris Liddell <chris.liddell@artifex.com>
0e3084881a3f2b40ed17a9f71713304bcbf5c976

> Product string, dates etc for 9.27 release candidate
> base/gscdefs.h
> doc/DLL.htm
> doc/Deprecated.htm
> doc/Develop.htm
> doc/Devices.htm
> doc/Drivers.htm
> doc/Fonts.htm
> doc/History9.htm
> doc/Install.htm
> doc/Internal.htm
> doc/Language.htm
> doc/Lib.htm
> doc/Make.htm
> doc/News.htm
> doc/Ps-style.htm
> doc/Ps2epsi.htm
> doc/Psfiles.htm
> doc/Readme.htm
> doc/Release.htm
> doc/SavedPages.htm
> doc/Source.htm
> doc/Unix-lpr.htm
> doc/Use.htm
> doc/VectorDevices.htm
> doc/WhatIsGS.htm
> doc/gs-vms.hlp
> doc/sample_downscale_device.htm
> doc/subclass.htm
> doc/thirdparty.htm
> man/dvipdf.1
> man/gs.1
> man/gslp.1
> man/gsnd.1
> man/pdf2dsc.1
> man/pdf2ps.1
> man/pf2afm.1
> man/pfbtopfa.1
> man/printafm.1
> man/ps2ascii.1
> man/ps2epsi.1
> man/ps2pdf.1
> man/ps2pdfwr.1
> man/ps2ps.1

2019-04-03 03:28:01 -0700
Robin Watts <Robin.Watts@artifex.com>
d832f46edd65968e795f5f419107eb33a7a3e09f

> Fix problems with "typedef struct foo_s foo;" redefinitions.
> In the header revamp, I'd left various places where we
> use the above formulation in more than one location. This
> is fine with all the C compilers I tested it on, but seems
> to update gcc 4.1.2.
> This effect can be seen on later gcc's by using
> "-std=gnu89 -pedantic".
> This commit tweaks the code to avoid redefinitions of this
> kind.
> base/gsfont.h
> base/gsgdata.h
> base/gspath.h
> base/gspenum.h
> base/gxchar.h
> base/gxdevcli.h
> base/gxfont.h
> base/gxiodev.h
> base/gxpath.h
> base/gxtext.h
> base/lib.mak
> psi/imemory.h

2019-03-29 15:43:14 +0000
Robin Watts <Robin.Watts@artifex.com>
0750e5fa1e3c988f07d3fb5adedfb0896e7b400c

> Fix Downscaler ETS brokenness.
> We are only supposed to use ETS if requested. We pass in a flag to
> say whether to use it - probably best, on balance, not to ignore it.
> base/gxdownscale.c

2019-03-28 09:21:37 +0000
Chris Liddell <chris.liddell@artifex.com>
1f602898555e969542760ac86b4e250c411e9f8c

> Fix sefault with 'so' build.
> The loaders were passing an unitialise pointer into gsapi_new_instance()
> meaning we might try to dereference the pointer to get to the shared portion
> of the library context.
> Initialise the pointer to NULL.
> Apply the same fix to everywhere that uses gsapi_new_instance.
> pcl/pl/plwmainc.c
> pcl/pl/realmain.c
> psi/apitest.c
> psi/dmmain.c
> psi/dpmain.c
> psi/dwmain.c
> psi/dwmainc.c
> psi/dxmain.c
> psi/dxmainc.c
> toolbin/halftone/gen_stochastic/gen_stochastic.c

2019-03-27 14:41:13 +0000
Chris Liddell <chris.liddell@artifex.com>
4be4e4195c88d195502e3e093f0177534af0439c

> Update thirdparty.htm: Freetype and jbig2dec versions
> doc/thirdparty.htm

2019-03-27 08:08:04 +0000
Chris Liddell <chris.liddell@artifex.com>
6d6a868110e7b1258f6586593f4e6405a1b0dcc3

> Add license file for cups/libcups
> cups/LICENSE.txt

2019-03-26 15:14:49 +0000
Chris Liddell <chris.liddell@artifex.com>
10eddb8d2b327bfb78c23863577a80b40860f920

> Tweak the pcl/LICENSE to make a little more sense
> It hadn't been revised really for the "new" directory structure.
> It will probably benefit from a more substantial revisit, but for now, this
> makes it less confusing.
> pcl/LICENSE

2019-03-26 09:23:56 +0000
Chris Liddell <chris.liddell@artifex.com>
bb161b7be76b71a99cb1761bcea7b9c13cf987fb

> Reword the 'greeting' to reflect the open source license.
> Resource/Init/gs_init.ps

2019-03-26 09:13:42 +0000
Chris Liddell <chris.liddell@artifex.com>
076c127d2a1d697d9d02cf6bce70f5a692e11846

> Fix 'greeting' and include COPYING in install
> The greeting message still referenced the obsolete 'PUBLIC' file. And
> doc/COPYING was missing from the list of files for install.
> Resource/Init/gs_init.ps
> base/unixinst.mak

2019-03-26 10:51:36 +0000
Chris Liddell <chris.liddell@artifex.com>
6cc71a794e784887fc7d41ebd87473e7a065e87d

> Bug 700897: fix validation of -M and -N parameters.
> psi/imainarg.c

2019-03-25 19:35:07 -0700
Michael Vrhel <michael.vrhel@artifex.com>
f53e124de64baf9306ee55e5fda46d77091ad176

> Fix tiffsep_cmyk_cs_to_cm in tiffsep device
> When we were doing just a single or a couple spot colorants using something like
> -c "<< /SeparationColorNames [(Pantone 137 CVU)] /SeparationOrder [(Pantone 137 CVU)]>>
> setpagedevice" the colorants mappings were not getting properly cleared by
> tiffsep_cmyk_cs_to_cm causing fillpage to not clear out the page.
> devices/gdevtsep.c

2019-03-25 09:01:51 +0000
Ken Sharp <ken.sharp@artifex.com>
76ada9e73edaf0cf661f5af85d58580caae9f882

> Coverity ID 337243 - remove dead code
> devices/vector/gdevpdfp.c

2019-03-23 10:29:59 +0000
Ken Sharp <ken.sharp@artifex.com>
06ed92ab4efddaea02069b2411aef401f8c7e5ce

> Another trailing white space fix
> base/gdevp14.c

2019-03-23 10:26:29 +0000
Ken Sharp <ken.sharp@artifex.com>
c7de4cdfeda7916359303ad0731752918835a876

> PDF Interpreter - fix leading and trailing white spaces in pdf_draw.ps
> Commit 09c656e066777bd69bbd1902e6163fe3a8a39406 included some
> leading and trailing white spaces.
> Resource/Init/pdf_draw.ps

2019-03-21 16:42:06 +0000
Chris Liddell <chris.liddell@artifex.com>
7e0a16411957a2809d61be966af6c08c9a735d84

> Revert "Update psd devices to only do one pass while rendering."
> This reverts commit d2d32bcee1cb1b28494ba9b572afa53ef84391af.
> Experiment for release testing.
> devices/gdevpsd.c

2019-03-20 13:55:54 +0000
Chris Liddell <chris.liddell@artifex.com>
3c981b6987fb6a30c1911aaa3aeb6535ce92882c

> tiffscaled: correctly select the downscaler when using ETS
> When tiffscaled uses ETS for the halftoning, and it's downscaling, we have to
> select the downscaling "core" based on the factor.
> base/gxdownscale.c

2019-03-19 17:49:14 +0100
Knut Petersen <knut_petersen@t-online.de>
2e866aca0186d8847512686b80b2eca12988ba3f

> Fix e005c87e09f67f37ce4ae2f80f24cf9182e86d8d
> Signed-off-by: Knut Petersen <knut_petersen@t-online.de>
> Resource/Init/pdf_font.ps

2019-03-19 10:06:38 -0700
Michael Vrhel <michael.vrhel@artifex.com>
d66449d30e13b4a5d71559d373ab00985b0bd3c1

> Bug 700744 Documentation typo.
> doc/GS9_Color_Management.pdf
> doc/GS9_Color_Management.tex

2019-03-19 08:32:46 -0700
Michael Vrhel <michael.vrhel@artifex.com>
20de9c4570bc556505069ff91c121cfb3d2f5984

> Bug 700686 Matte premultiplied images
> The undoing of the matte pre-blend must occur in the image color space. As such
> the group that the interpreter pushes must be that color space and we must make sure
> that we undo the pre-blend before any conversions for the group color space.
> Resource/Init/pdf_draw.ps
> base/gdevp14.c
> base/gxblend.c
> base/gxblend.h

2019-03-19 09:25:48 -0700
Ray Johnston <ray.johnston@artifex.com>
ebbb3ec7d20b5f4c444eb11fc9835e07229ccbd9

> Fix lib/pdf2dsc.ps to use documented Ghostscript pdf procedures.
> We eliminated GS_PDF_ProcSet and pdfdict, but runpdfbegin, dopdfpages,
> and runpdfend are still available.
> lib/pdf2dsc.ps

2019-03-19 08:34:05 -0700
Ray Johnston <ray.johnston@artifex.com>
52b4d7918e5792e1fb040f1ba72bd71b9f9ec0a9

> Fix bug 700719: SEGV with very large XStep/YStep and transparent patterns.
> At high resolutions, the bonkers XStep/YStep for the pattern could confuse
> the tile_by_steps_trans logic, and could overflow a 32-bit signed int causing
> a sign flip. Protect from this by checking to make sure we only fill within
> the fill_trans_buffer->rect.
> base/gxp1fill.c

2019-03-19 14:35:43 +0000
Ken Sharp <ken.sharp@artifex.com>
e0e9e32357debd5610bca37a804f1bde62f77844

> Fix FillOrder tag for the TiffG3 and TiffG4 devices
> Bug #700255 "Option FillOrder doesn't work anymore"
> Commit 0ef309305417776a9f8b8cd143fbf3c5e89456b2 added the FillOrder
> switch to the 'tiff' class of devices, but the fax Tiff devices already
> processed that switch, and the commit did not remove the processing
> from those devices.
> This led to us trying to us ending up with the parameter in the params
> list twice when we executed get_params (once from the tiff device
> processing and once from the tiff fax device processing).
> When we then next execute a 'put_param', the list has a duplicate
> entry for FillOrder. We stop processing when we find the first entry,
> which means the second entry never gets processed, leading to an
> unused entry in the list, and that throws an error.
> The simplest way to fix this is to remove the duplicate 'get_param()'
> processing from the tiff fax devices, leaving it up to the generic
> Tiff device.
> devices/gdevtfax.c

Chris Liddell <chris.liddell@artifex.com>
2e843b2dd9a6ae935c9e00ba127302123cb9121e

> Bug 700815(2): Fix the end-of-data condition.
> The end-of-data condition in the charstring interpreter that checks for SEACs
> was allowing an extra byte to read off the end of the string.
> In addition, we also want to handle the out-of-data condition for a (g)subr
> gracefully.
> base/gxtype1.c

2019-03-19 08:53:10 +0000
Chris Liddell <chris.liddell@artifex.com>
b66ebe07ae5c1fb4ef94f9051e537d69eb789896

> Bug 700815(1): Init gsubrNumberBias in Type 1 fonts and eexec decoder
> The gsubrNumberBias is only used for Type 2 fonts, but the structure and
> charstring interpreter are shared between Type 1 and 2 fonts, so we still need
> to set gsubrNumberBias for Type 1 fonts (always 0 for Type 1).
> Secondly, full initialise the eexec decoder state, along with some stack
> variables during eexec decode setup.
> This fixes most of the valgrind errors in Bug 700815, but not all.
> psi/zfont1.c
> psi/zmisc1.c

2019-03-18 10:45:12 +0000
Chris Liddell <chris.liddell@artifex.com>
e005c87e09f67f37ce4ae2f80f24cf9182e86d8d

> Bug 700678: Check for embedded font when substituting
> When we apply a font name mapping, make sure that the ultimate font we load
> comes from disk, and is not embedded in the job.
> To aid differentiating between a substitute CIDfont (cidfmap), a "real" CIDFont
> resource, and an embedded CIDFont, add a /ResourcePath key to CIDFont resource
> dictionaries (susbsitute CIDFonts contain /Path key).
> Resource/Init/gs_cidfn.ps
> Resource/Init/pdf_font.ps

2015-11-29 08:10:37 -0600
Chris Liddell <chris.liddell@artifex.com>
5edf847476e7a3e342422013283f984e38b52cd9

> Bug 695903: Augment fontmap syntax to allow TTCs to work 'properly'.
> Support dictionary entries in Fontmap, so a fontmap file can contain a map to
> specific fonts in a TTC.
> The romfs inlines the fontmap definitions, and ends up parsing them before
> we've bootstrapped the Level 2 world properly so the '<<...>>' dictionary
> syntax not only is not defined but also cannot even be parsed.
> So, temporarily enable Level 2 parsing, and include local definitions of the
> names '<<' and '>>' to work as you'd expect.
> Resource/Init/Fontmap.GS
> Resource/Init/gs_fonts.ps
> Resource/Init/gs_res.ps
> Resource/Init/gs_ttf.ps

2019-03-19 09:18:09 +0000
Ken Sharp <ken.sharp@artifex.com>
6a49a201c82106e97148553a8394b74e6c656858

> PDF interpreter - fix commit 33414cb5930ee715a23b75eb37e919b6f15f96c0
> There was a logical error in the prior commit which caused all PDF files
> with a /Info dictionary to signal an error.
> This rearranges the code to have the correct logic flow, properly
> producing an error only for the broken specimen file.
> Resource/Init/pdf_main.ps

2019-03-18 19:30:43 +0000
Ken Sharp <ken.sharp@artifex.com>
33414cb5930ee715a23b75eb37e919b6f15f96c0

> PDF interpreter - check the type of the Info dictionary before use
> Bug #700820 " GPL Ghostscript 9.26: Unrecoverable error, exit code 1"
> The problem here is that the trailer dictionary has an entry for the
> /Info dictionary, but the object it poitns to is not a dictionary.
> For most purposes this doesn't matter, but when the devce is pdfwrite
> we try to maintain the information in that dictionary.
> This commit tests the type of the object referenced by the key in the
> trailer dictionary and if the object isn't a dictionary we don't try to
> use it. We do flag an error though.
> Resource/Init/pdf_main.ps

2019-03-18 11:54:40 +0000
Ken Sharp <ken.sharp@artifex.com>
b4e343d201e337478973824995c0bbc25955b36e

> Silence a compiler warning
> This is actually a false positive, the code is:
> if ((code = glyph_show_setup(i_ctx_p, &glyph)) != 0)
> return code;
> if ((code = gs_glyphshow_begin(igs, glyph, imemory_local, &penum)) < 0)
> return code;
> and the warning is against gs_glyphshow_begin. However glyph is actually
> initalised in the line above by glyph_show_setup. There are paths to
> exit that routine without setting glyph, but they all return non-zero
> exit codes.
> I suspect the return macros in glyph_show_setup and co are confusing
> the compiler.
> To silence the compiler warning, simply initialise the variable.
> psi/zcharx.c

2019-03-18 11:13:51 +0000
Ken Sharp <ken.sharp@artifex.com>
9b11ad14c36103f3446680efa71d25a216177ccd

> Initialise another variabel to silence valgrind
> Following on from 086d30c38cb351e95941a950ddadd300e23cd8a4
> The last.count member gets tested in pdfmark_adjust_parent_count, even
> when last.id is 0, so we need to initialise that too.
> devices/vector/gdevpdfm.c

2019-03-18 10:14:48 +0000
Ken Sharp <ken.sharp@artifex.com>
086d30c38cb351e95941a950ddadd300e23cd8a4

> pdfwrite - don't write an incomplete Outline entry
> Bug #700816 "Valgrind shows problems with pdfmarks"
> The file in question has a recursive Outline entry, which eventually
> leads to an execstackoverflow. This causes the pdfwrite device to be
> closed, which leads to it closing and writing the Outkine tree as part
> of the cleanup. Because of the way the /OUT pdfmark works, this means
> there is a dangling reference (because the last /OUT pdfmark had a
> child, but we haven't yet received the child data).
> There was in fact already code to deal with this, and not write out
> the final outline entry. However it relied upon an uninitialised value
> being 0, which of course it usually isn't.
> Fixed by initialising the value to 0, which should avoid the valgrind
> warning, and prevents us writing an invalid Outline tree entry as well.
> devices/vector/gdevpdfm.c

2019-03-18 09:47:35 +0000
Ken Sharp <ken.sharp@artifex.com>
1f30baee070ea9da1de1cb479e3a5c49c0514267

> Check error codes for configuration errors with the pdfwrite family
> Bug #800819 "Incorrect parameter value for sColorConversionStrategy is silently ignored."
> The low level parameter checking for the pdfwrite family wasn't
> honouring error returns from certain kinds of parameters, most notably
> those involving lists of permitted values (eg ColorConversionStrategy)
> This commit throws an error for those cases.
> This causes one file in the regression test suite 'pt.ps' to throw an
> error with the ps2write device. This is because the PostScript program
> contains an invocation of setdistillerparams which sets the
> ColorImageFilter (and GrayImageFilter) to Flate instead of DCT. Level 2
> PostScript doesn't include the Flate filter, that is a level 3 addition
> so we now throw an error on that file.
> devices/vector/gdevpdfp.c
> devices/vector/gdevpsdp.c

2019-03-14 15:21:40 -0700
Nancy Durgin <nancy.durgin@artifex.com>
03019418e745d215beeea1c5b141524eec8346eb

> Alternate way to process that whitelist at end of scanner.
> This version doesn't assume there is a --oper-- form on the list, so
> it works with "functions" (procedures) that as well as with operators.
> toolbin/scan_ps_dicts.ps

2019-03-14 14:17:41 -0700
Nancy Durgin <nancy.durgin@artifex.com>
4163949fa861188f647b7106e181a8121522012f

> Make sure all references to .sort are executeonly so it can be undef'd
> .findfontvalue and .loadttfonttables still had some references
> Note: .sort is currently only undef'd in SAFER mode
> Resource/Init/gs_ttf.ps

2019-03-14 14:13:15 -0700
Nancy Durgin <nancy.durgin@artifex.com>
d2f3830b364788a88ea6233f8255cc507f483048

> Add a bunch of extensions to whitelist
> Also, the logic for "functions", which don't have the --oper-- form
> on the whitelist, is currently broken, so just put everything
> on the operator list until that's sorted (if ever).
> toolbin/scan_ps_dicts.ps

2019-03-14 09:40:18 -0700
Nancy Durgin <nancy.durgin@artifex.com>
40c5fae8604fb6f7916beed8b5c5081e29da8cef

> Remove some code that was checking for .setglobal to be defined
> .setglobal, .currentglobal and .gsheck are all defined in psi/zvmem2.c
> This code seems to be leftover from a time when that might not have been
> the case, but it's unnecessary and confusing now. The comment in the
> C code indicates they are always defined even for language level 1.
> Resource/Init/gs_init.ps

2019-03-14 08:57:11 -0700
Nancy Durgin <nancy.durgin@artifex.com>
5503e225ade2de26fd9e41e63cd3d26b14c3878b

> Whitelist some more operators that are in the PLRM
> Not sure why the Ray's automated extraction didn't pick these up?
> toolbin/scan_ps_dicts.ps

2019-03-13 14:53:41 -0700
Nancy Durgin <nancy.durgin@artifex.com>
fbcda19eb6c8cdba96a6315dfb6f8d241c667259

> Remove UserObjects from whitelist
> This is in the PLRM, but it's not an operator and it's not going to
> show up in the scan unless 'defineuserobject' has previously been run.
> toolbin/scan_ps_dicts.ps

2019-03-13 08:51:06 -0700
Nancy Durgin <nancy.durgin@artifex.com>
ad63987d8d4395423513e55008f6ecdcd31f9f26

> Move .makeoperator docs from Language.htm to Internal.htm.
> It is now an internal operator
> Remove it from whitelist in scan_ps_dicts.ps
> This has already been undef'd (after initialization), just fixing the
> documentation.
> This commit also adds a new "Internal.htm" documentation file, and
> hopefully fixes up the links to it in Readme.htm
> doc/Internal.htm
> doc/Language.htm
> doc/Readme.htm
> toolbin/scan_ps_dicts.ps

2019-03-13 15:18:57 +0000
Ken Sharp <ken.sharp@artifex.com>
c633d492cef7de24dafcecceb6efca982b1ad8be

> Coverity IDs 279970 and 279971
> Add some casts to prevent implicit casting promoting unsigned values to
> signed values.
> Moost places had already been handled, but three had been missed.
> devices/gdevdsp.c

2019-03-13 14:25:47 +0000
Ken Sharp <ken.sharp@artifex.com>
58e490fec4909b18151e25bd55c9e9f91512a007

> Fix (non-PostScript) processing of -d switch with radix
> The -d switch can take a radix as part of the value assigned to a
> named switch. For example -dDisplayFormat=16#20808 is described in the
> display device documentation as selecting CMYK rendering.
> The implementation in plmain.c was completely broken and returned the
> error "Malformed base value for radix" for any switch using '#'.
> The first problem is that we increment the pointer 'v' after checking
> 'c' to see if its a number. That means when its not a number (ie #) we
> have moved v on past the # character. So the test for *v being '#'
> fails.
> Later we use 'val' which has been initialised to the '#' symbol in the
> string. We check to see its a number or A->F or a->f and if its not
> then we throw an error. Of course its initially pointing at '#' so
> it fails immediately.
> pcl/pl/plmain.c

2019-03-08 11:51:31 -0800
Ray Johnston <ray.johnston@artifex.com>
9da9391c8f0a1414be45201c79e5cc649a125341

> Add "print" operator to whitelist in scan_ps_dicts.ps
> toolbin/scan_ps_dicts.ps

2019-03-08 11:40:28 -0800
Ray Johnston <ray.johnston@artifex.com>
805ca20a78cd837b5d6a30ad7d0df0828aa5de38

> Add final section that reports any whitelisted operators that are not seen.
> By setting the whitelist entry to //false initially, and the //true when
> the operator is encountered in the scan, we can report elements that are in
> the whitelist that probably don't need to be there (they've already been
> undef'ed).
> Also for operators, since they may be encountered in a dict in "bare" form,
> or may be seen in packedarray procedures with "--" in front and back, we
> check for either having been encountered by pulling out the "bare" form
> and checking if that whitelist entry has been seen.
> toolbin/scan_ps_dicts.ps

2019-03-11 08:16:47 -0600
Henry Stiles <henry.stiles@artifex.com>
8bc9b0e335b0b69d5b174835a92270903c1dd830

> Fix Bug #700575 valgrind problem with decode_char.
> Previously PCL stored the character code when encoding and returned it
> upon decode. This was only implemented properly for TrueType fonts,
> ie. Intellifont or bitmap fonts did not set the character which
> resulted in an unitialized read. Ostensibly (for PCL/XL) high level
> devices pass the character back upon decode, so it is only necessary
> to return the passed in value and we can dispense with storing the
> last character.
> pcl/pl/plchar.c
> pcl/pl/plfont.c
> pcl/pl/plfont.h

2019-03-11 08:32:15 +0000
Ken Sharp <ken.sharp@artifex.com>
b881341b3d9993d88a1b395b552f28e62d0abc20

> Fix a typo in an error message
> Reported by Michael Witten via email. There was a typo in the error
> message when the number of entries in an xref table didn't match the
> value associated with the /Size key in the trailer dictionary.
> Resource/Init/pdf_main.ps

2019-03-08 11:55:27 +0000
Ken Sharp <ken.sharp@artifex.com>
6deec5bffda4b7b3e2f7daa4801150e469b4be95

> reformat a conditional to avoid a compiler warning
> gcc was giving a false warning on 'glyph' being used uninitialised,
> which is not (I believe) the case. I could fix it by initialising the
> variable, but instead lets remove the annoying multiple calls in an if
> clause.
> I'm not certain this will silence the warning.
> psi/zcharx.c

2019-03-07 16:51:04 +0000
Chris Liddell <chris.liddell@artifex.com>
3c8bc1663619afa6dcf74c287801408508c504b1

> Bug 700701: stack cleanup for all 'show' operator family.
> The exec stack cleanup done in 'show' needs applied to all the other similar
> operators.
> psi/zchar.c

2019-03-07 13:39:58 -0800
Nancy Durgin <nancy.durgin@artifex.com>
32258b5f0fe0db14142a6487c46121afa65c2538

> Add 'min' and 'max' back in
> These are harmless and redundant, but they have been around a long
> time and are documented in Language.htm, so it seems better to keep
> them than to break stuff.
> Internal code all uses .min and .max instead, so yes there are two
> versions of the same thing...
> Resource/Init/gs_init.ps

2019-03-07 13:28:29 -0800
Nancy Durgin <nancy.durgin@artifex.com>
9f811276ed9eb29a1dc8284159a2995e9be4dabf

> Fix the test for which whitelisted operators were found, to check boolean
> toolbin/scan_ps_dicts.ps

2019-03-07 11:07:30 -0800
Ray Johnston <ray.johnston@artifex.com>
3d3e0f2788fd3403bf5ac8d31b732f1404cca4aa

> Add a check to scan_ps_dicts.ps to report whitelist entries that aren't found.
> toolbin/scan_ps_dicts.ps

2019-03-07 12:38:33 -0800
Nancy Durgin <nancy.durgin@artifex.com>
9a835217e1f61272f8830eac643f689ba041902e

> Change to use a list of operator/function names and add to dict later
> - can break out the lists by category (standard vs extensions)
> - adds the "--" around operators dynamically
> - can put non-operators (functions) in a separate list if desired
> - changed the value in the dict to //false
> toolbin/scan_ps_dicts.ps

2019-03-07 10:29:17 -0800
Nancy Durgin <nancy.durgin@artifex.com>
9302928bf518f3ce3e739f1ea428e5f82729d7d9

> Undef .pdfcharkeys in gs_ttf.ps
> Change references to immediate evaluation and undef at end of file
> Resource/Init/gs_ttf.ps

2019-03-07 10:29:01 -0800
Nancy Durgin <nancy.durgin@artifex.com>
36e629576399a596b930878dad0438f9c9a19dd6

> Add some ghostscript extensions to whitelist
> toolbin/scan_ps_dicts.ps

2019-03-07 08:30:38 -0800
Nancy Durgin <nancy.durgin@artifex.com>
ccf0be61013372c4c449f0b760fa00ac0b20245f

> Change shellarguments to .shellarguments and document it.
> Resource/Init/gs_init.ps
> doc/Language.htm
> lib/gslp.ps
> lib/pf2afm.ps
> lib/pfbtopfa.ps
> lib/pphs.ps
> lib/printafm.ps
> lib/rollconv.ps
> lib/viewcmyk.ps
> lib/viewpbm.ps
> lib/viewpcx.ps
> lib/viewraw.ps
> lib/viewrgb.ps
> toolbin/pdf_info.ps

2019-03-06 13:57:56 -0800
Nancy Durgin <nancy.durgin@artifex.com>
b5a3721b36da0a1a28cb6d132d2c6ae11e1592c0

> Undef .confirm, .confirmread
> There was a reference in doc/SavedPages.htm to .confirmread which has
> been changed in 314c6b9026efbcada4e48b11c9a173a5e91d779c
> to use standard postscript.
> 1) Rearranged code so things are defined before use.
> 2) Change all references to immediate evaluation.
> 3) undef
> Resource/Init/gs_init.ps
> Resource/Init/gs_setpd.ps

2019-03-06 16:11:43 -0700
Henry Stiles <henry.stiles@artifex.com>
f6ddc968966327f3bc24d1edc6a25c0f7ef82cd4

> Remove the ownership document.
> This hasn't been kept up to date, most of the information can be found
> in Bugzilla by looking at default assignee per component.
> doc/who_owns_what.txt

2019-03-06 16:08:56 -0700
Henry Stiles <henry.stiles@artifex.com>
2b100b794af3da27c127212af96bf4668fbda89b

> Bug #700671 - error code not propagated back.
> In attempt to clean up after an error PCL was stepping on the original
> error code resulting in the interpreter continuing without fonts.
> pcl/pcl/pctop.c

2019-03-06 15:30:14 -0700
Henry Stiles <henry.stiles@artifex.com>
b731a0d961516bd42b510e1ae036cca109b0ccdb

> Bug #700671 fix file mode.
> The file mode was incorrectly specified to include 'b' with the
> sfopen(), the stream code adds another 'b' because it is always
> binary. This can cause a crash on Windows 10 (see bug #696101).
> Further gp_file_rb should only be used with gp_fopen().
> pcl/pl/plfont.c

2019-03-06 13:41:07 -0800
Ray Johnston <ray.johnston@artifex.com>
314c6b9026efbcada4e48b11c9a173a5e91d779c

> Rework a saved-pages example to use standard PostScript (not .confirmread)
> doc/SavedPages.htm

2019-03-06 13:38:08 -0800
Nancy Durgin <nancy.durgin@artifex.com>
b9947ecde3bb1cd265ab24e5fd5086ae9f09bdc4

> Tweak whitelist of scan_ps_dicts.ps, add some color ops
> - remove statusdict
> - add some standard operators that aren't in the PLRM (related to color)
> toolbin/scan_ps_dicts.ps

2019-03-06 10:28:52 -0800
Nancy Durgin <nancy.durgin@artifex.com>
882aec138f3b734182f7494c69cf8c67d72aba77

> Undef deprecated min,max,unread and clean up undef of .unread
> min, max and unread have been deprecated since like 2001. Deleted
> their definitions. This broke vasaley.ps test file, but I edited it
> to define its own "min".
> Changed existing uses of 'unread' to '.unread', 'min' to '.min', 'max'
> to '.max'.
> Made sure all uses of .unread are executeonly.
> Resource/Init/gs_fonts.ps
> Resource/Init/gs_img.ps
> Resource/Init/gs_init.ps
> Resource/Init/gs_type1.ps

2019-03-06 10:22:25 -0800
Ray Johnston <ray.johnston@artifex.com>
ee9e9f283c82eed181d5a11c7bea3735090fd680

> Add whitelist to scan_ps_dicts.ps
> Note that unfortunately, we have to have operators both in the 'bare'
> form and the display form e.g. (exit) (--exit--).
> toolbin/scan_ps_dicts.ps

2019-03-05 13:18:10 -0800
Nancy Durgin <nancy.durgin@artifex.com>
f5e8f8118bdca7ecae547a1d33d10ae1ec97d646

> Don't define SAFERUndefinePostScriptOperators unless in SAFER
> Previously if SAFER not true, then this would be defined and never undefined.
> Resource/Init/gs_init.ps

2019-03-05 15:47:16 -0800
Ray Johnston <ray.johnston@artifex.com>
77152d4b71cf542f3c4cb610ad97c3a4d4efa65b

> Initial version of utility to scan dictionaries for operators
> toolbin/scan_ps_dicts.ps

2019-02-28 14:57:55 -0800
Nancy Durgin <nancy.durgin@artifex.com>
a45e3a9bf7b878c6f4e4a840ade4e64b5c56cd80

> Cleaned up dead code related to .savelocalstate
> .savelocalstate was part of display postscript (gs_dps.ps), so it is
> no longer defined. Cleaned up conditional code that is now dead code.
> Resource/Init/gs_init.ps

2019-02-28 14:22:32 -0800
Nancy Durgin <nancy.durgin@artifex.com>
097bb257147f45e5d1c15278cb95b7d19a147ac8

> Undef .makeinternaldict in gs_init.ps
> This used to be used more in gs_dps.ps, when multiple contexts were supported.
> Downgraded it from an operator to a function. It's now only used in one
> place, so undef right after use.
> Resource/Init/gs_init.ps

2019-02-28 12:50:34 -0800
Nancy Durgin <nancy.durgin@artifex.com>
def941fa84d55e9ffdd76dec5009440904cf792b

> Undef .getpath in gs_init.ps
> This was another case where the operator is defined in C and was put
> into the level2dict for no apparent reason. The code that uses it (in
> pdf_ops.ps and pdf_draw.ps) didn't have level2dict available on the
> dictstack when it defined the operators, so it wasn't getting bound.
> Solution is to take .getpath out of level2dict. Added zupath_op_defs
> for it and fixed makefile. Then can easily undef it.
> Resource/Init/gs_init.ps
> psi/int.mak
> psi/zupath.c

2019-02-28 10:41:44 -0800
Nancy Durgin <nancy.durgin@artifex.com>
f26771b927e154c63101a08c9ca6ecef564e80a3

> Undef .useloresscreen in gs_init.ps
> Change to immediate evaluation and undef after use.
> Resource/Init/gs_init.ps

2019-02-28 09:10:29 -0800
Nancy Durgin <nancy.durgin@artifex.com>
15e29a6e26dca230b9f35ec9bfa92de37a6f7c8c

> Undef .setdefaultbgucr in gs_init.ps
> This is just used locally. Change to immediate evaluation and undef after use.
> Resource/Init/gs_init.ps

2019-02-27 15:21:57 -0800
Nancy Durgin <nancy.durgin@artifex.com>
b8a02cc76747e78e86ad5a127d1aec832b1b7566

> Undef .beginpage, .endpage in gs_init.ps
> Make sure all uses are executeonly.
> After all the other cleanups, these are now easily undefined.
> Resource/Init/gs_init.ps
> Resource/Init/gs_setpd.ps

2019-02-27 14:25:08 -0800
Nancy Durgin <nancy.durgin@artifex.com>
c7b85fa9d84d5c9304c783461d5c8b91d580bfbb

> Undef .mergespecial,.requiredattrs dictionaries in gs_setpd.ps
> These are only used locally, but contain some functions (such as
> InputAttributes) which were exposed.
> Change to immediate evaluation and undef at end of file.
> Resource/Init/gs_setpd.ps

2019-02-27 13:58:55 -0800
Nancy Durgin <nancy.durgin@artifex.com>
c2ad80deefb2b5af6b432cf4aa9942303fff17b3

> Undef .clearerror in gs_init.ps
> Move definition above use, make all uses immediate evaluation and undef.
> Resource/Init/gs_init.ps
> Resource/Init/gs_res.ps

2019-02-27 13:28:49 -0800
Nancy Durgin <nancy.durgin@artifex.com>
359306748b1aee2497d650b82a5222df2d99e702

> Undef .type11mapcid, .type9mapcid
> Made sure all uses were bind and executeonly, then can undef.
> Note that the "CIDWProc" in pdf_font.ps wasn't bound. I didn't see
> any reason for that, so I bound it.
> Resource/Init/gs_cidfn.ps
> Resource/Init/gs_init.ps
> Resource/Init/pdf_font.ps

2019-02-27 12:42:11 -0800
Nancy Durgin <nancy.durgin@artifex.com>
af2c7b51e110d831e1c133e2635b2bad8e2e7dc8

> Undef EPSBoundingBoxInit in gs_init.ps
> This is only referenced during initialization. Undef after use.
> Resource/Init/gs_init.ps

2019-02-27 11:40:03 -0800
Nancy Durgin <nancy.durgin@artifex.com>
34c34b9d9cc51bb90bf1e7c761bb917fcd094734

> Undef .unstoppederrorhandler in gs_init.ps
> Change to immediate evaluation and undef right after use.
> Resource/Init/gs_init.ps

2019-03-04 07:14:31 +0000
Ken Sharp <ken.sharp@artifex.com>
7cb19e8362925329feed688db308aa3e5b935d0a

> Coverity ID 33608
> We weren't acting on a return value. If we get an error, which I believe
> should actually be impossible in this case, we might potentially have
> an invalid object being pointed to by an array.
> Just in case, if we get an error here, discard the array we just
> allocated and propagate the error.
> psi/istack.c

2019-03-04 07:05:21 +0000
Ken Sharp <ken.sharp@artifex.com>
c38992507901fb8a3991ae61f5301f28719230b7

> Coverity ID 333611
> The error handling code in the run length encode filter confuses
> Coverity because it relies on a series of 'got' operations that jump
> into a block of otherwise unreachable code.
> The code is (IMO) ugly and confusing, so refactor it to avoid the
> 'if (0)' blocks. This results in many fewer goto labels, and simpler
> code.
> base/srle.c

2019-03-04 07:02:31 +0000
Ken Sharp <ken.sharp@artifex.com>
ff41c469b656224fb90083e8f622af21952266d9

> Coverity ID 333614 sign extension
> An intermediate calculation results in a cast to 'int' which is then
> promoted (on 64-bit systems) to an unsigned long long. If the top bit
> of the intermediate value is set, then all the top bits of the final
> value will be set.
> Do an explicit cast to an unsigned to avoid this.
> devices/gdevxalt.c

2019-03-04 06:09:15 +0000
Ken Sharp <ken.sharp@artifex.com>
00909869edf9f38af985086495e310ed2ea6b916

> Coverity IDs 333615, 333613, 333610, 333606
> Recent changes ot the code (extra chacking of the return value from
> gs_matrix_invert are causing Coverity to regard unchecked return codes
> from this routine as a problem.
> Add return code checks (or cast to void) to pacify.
> contrib/eplaser/gdevescv.c
> contrib/lips4/gdevl4v.c
> contrib/opvp/gdevopvp.c
> devices/vector/gdevpdtt.c

2019-03-04 05:54:56 +0000
Ken Sharp <ken.sharp@artifex.com>
a7ab9861741f1aad06f4932c92b1a27fc13e230e

> Coverity ID #333616
> Add a comment to the default case so that Coverity can tell that we
> fall through to the next case deliberately.
> base/srle.c

2019-03-02 15:04:33 -0800
Michael Vrhel <michael.vrhel@artifex.com>
d5bc9bd2a548e6c12dd8224b6d18615d050a5731

> Only use plug-in clone if transform is not identity
> lcms will if it finds the table is essentially the identity set
> the transform to a copy operation. If this is the case, then
> just use that operation as it will be as fast as things can get.
> lcms2mt/src/cmsxform.c

2019-02-26 17:22:21 +0000
Robin Watts <Robin.Watts@artifex.com>
79ce761f39aac21c270d8fb19142f5f8146440d2

> Bug 700606: Fix problem with interpolated indexed >8bit images.
> In the initial decode of the line, all but the first pixel of the
> line is getting a value 0.
> We look to be wrongly applying the nth map function to the nth
> pixel, when the nth map function is intended for the nth component
> of the pixel. Given we are only processing indexed images at this
> point, we therefore always want the 0th map function.
> base/gxiscale.c

2019-02-26 19:38:12 -0800
Nancy Durgin <nancy.durgin@artifex.com>
6931f9b2fe9aa8d6ffcdbfece50ffde0ac8d00e8

> Undef /.generate_dir_list_templates, /.generate_dir_list_templates_with_length
> Made these operators due to length. Made sure all uses are executeonly.
> Undef in gs_init.ps
> Resource/Init/gs_fonts.ps
> Resource/Init/gs_init.ps
> Resource/Init/gs_res.ps

2019-02-26 15:46:24 -0800
Nancy Durgin <nancy.durgin@artifex.com>
ebea5737da47a55e0838b9472bc05d209717d670

> Undef .internalstopped in gs_init.ps
> This is used all over the place, tons of edits. Making it an operator
> didn't work (something to do with the stack during an error I think --
> fails on tests_private/ps/ps3fts/141-01.ps).
> So I made all the references be immediate evaluation, then can undef
> in gs_init.ps.
> Resource/Init/gs_btokn.ps
> Resource/Init/gs_cidfm.ps
> Resource/Init/gs_cidfn.ps
> Resource/Init/gs_cidtt.ps
> Resource/Init/gs_cmap.ps
> Resource/Init/gs_diskn.ps
> Resource/Init/gs_fonts.ps
> Resource/Init/gs_frsd.ps
> Resource/Init/gs_init.ps
> Resource/Init/gs_lev2.ps
> Resource/Init/gs_res.ps
> Resource/Init/gs_setpd.ps
> Resource/Init/gs_type1.ps
> Resource/Init/pdf_base.ps
> Resource/Init/pdf_main.ps
> Resource/Init/pdf_ops.ps
> Resource/Init/pdf_rbld.ps

2019-02-26 14:34:08 -0800
Nancy Durgin <nancy.durgin@artifex.com>
239d82b8b382afd435f3b48025954715633da9a9

> Fixed previous undef of .stopped
> The .stopped operator had been previously undef'd, but all the usages
> weren't executeonly so it still shows up in the operator scan. Made usages
> executeonly so .stopped is more thoroughly gone.
> Resource/Init/gs_init.ps

2019-02-26 13:13:21 -0800
Nancy Durgin <nancy.durgin@artifex.com>
a4dbb260b6525e65d9bbe894591a79830afe191e

> Undef .numicc_components and .set_outputintent in gs_init.ps
> These are defined as C operators and used in pdf_main.ps. For some
> reason they were defined in ll3dict, and during their use in
> pdf_main.ps, ll3dict wasn't on the dictstack, so they didn't get
> bound, meaning they couldn't easily be undef'd.
> The solution I picked was to take them out of ll3dict, as I see no
> reason for them to be there. That's a change to the C code (zicc.c).
> I also renamed the structure to be zicc_op_defs instead of
> zicc_ll3_op_defs, to eliminate any confusion. That required a
> makefile change (int.mak).
> After those changes, undef'ing in gs_init.ps is easy.
> Resource/Init/gs_init.ps
> psi/int.mak
> psi/zicc.c

2019-02-26 09:58:03 -0800
Nancy Durgin <nancy.durgin@artifex.com>
94a78ca611ccc59383e5c4ea4beba4a13f4d4afd

> Undef .runresource in gs_init.ps
> Change to immediate evaluation (used in gs_res.ps) and undef.
> Resource/Init/gs_init.ps
> Resource/Init/gs_res.ps

2019-02-26 09:53:37 -0800
Nancy Durgin <nancy.durgin@artifex.com>
81c820ac5154751b248bdc91d0416d1eec354be2

> Undef .PurgeDict in gs_init.ps
> This was already used with immediate evaluation, so just undef it.
> Resource/Init/gs_init.ps

2019-02-21 15:13:50 -0800
Nancy Durgin <nancy.durgin@artifex.com>
2aa1452450845649105c752c246a7a9c9b93b479

> Undef .registererror and .registererror2 in gs_init.ps
> .registererror2 is only used locally. Move code so it's defined before use.
> Change to immediate evaluation and undef right afterwards.
> .registererror is only used during initialization (not used in any
> procedure definitions), though it's also used in gs_dps2.ps in the same way.
> Undef after the uses.
> Resource/Init/gs_init.ps

2019-02-21 13:22:20 -0800
Nancy Durgin <nancy.durgin@artifex.com>
23f68c46dd32cc955aec10bfc1c13438bb89a166

> Undef .execute in gs_init.ps
> Used locally, had to rearrange some code.
> Change to immediate evaluation and undef after use.
> Resource/Init/gs_init.ps

2019-02-21 10:40:58 -0800
Nancy Durgin <nancy.durgin@artifex.com>
d17c277a2e847990fccab18de357afea87024065

> Undef .printerror_long in gs_init.ps
> Some whitespace changes and moved code around.
> This is only used locally.
> Change to immediate evaluation and undef after use.
> Resource/Init/gs_init.ps

2019-02-21 09:07:51 -0800
Nancy Durgin <nancy.durgin@artifex.com>
be56100b1ecf53092c9d678e4783b5660eb3e47e

> Clean up and rearrange some code related to SAFER
> Add some comments about which ones are extensions and to separate the code.
> Make the temporary stuff not be operators (no need).
> Resource/Init/gs_init.ps

2019-02-21 08:53:51 -0800
Nancy Durgin <nancy.durgin@artifex.com>
bdd92585f4a0aaa734053a5755e556ed61c8545d

> Undef .locksafeglobal, .locksafe_userparams in gs_init.ps
> Both of these are only used locally in gs_init.ps. Undef right after use.
> Resource/Init/gs_init.ps

2019-02-25 14:55:40 +0000
Chris Liddell <chris.liddell@artifex.com>
a3b526cafb940890aff47dd9933777b88321b3ce

> Bug 700678: Check for embedded font when substituting
> When we apply a font name mapping, make sure that the ultimate font we load
> comes from disk, and is not embedded in the job.
> Resource/Init/gs_fonts.ps

2019-02-25 19:16:03 +0000
Robin Watts <Robin.Watts@artifex.com>
d2d32bcee1cb1b28494ba9b572afa53ef84391af

> Update psd devices to only do one pass while rendering.
> Previously, PSD devices would loop over each component in the file
> and then over each line in the file. For non-page mode rendering
> therefore, we would render each page as many times as there were
> components.
> Change the logic here to loop over each component, then over each
> line.
> This means we seek within the file as we write, but we already
> impose restrictions on the output for this device to ensure that
> we don't write multiple pages to the same file, so this is no
> great loss.
> devices/gdevpsd.c

2019-02-25 19:51:16 -0800
Michael Vrhel <michael.vrhel@artifex.com>
4c741f6ff9b1ab8a0fb433af9db8d7b0db335318

> Have lcms2mt clone method check for transform plug-ins
> When cloning a transform, it is necessary to see if there
> are any plugins that should be used with the new data types.
> lcms2mt/src/cmsxform.c

2019-02-24 22:01:04 -0800
Ray Johnston <ray.johnston@artifex.com>
d683d1e6450d74619e6277efeebfc222d9a5cb91

> Bug 700585: Obliterate "superexec". We don't need it, nor do any known apps.
> We were under the impression that the Windows driver 'PScript5.dll' used
> superexec, but after testing with our extensive suite of PostScript file,
> and analysis of the PScript5 "Adobe CoolType ProcSet, it does not appear
> that this operator is needed anymore. Get rid of superexec and all of the
> references to it, since it is a potential security hole.
> Resource/Init/gs_init.ps
> psi/icontext.c
> psi/icstate.h
> psi/zcontrol.c
> psi/zdict.c
> psi/zgeneric.c

2019-02-22 13:43:15 -0800
Michael Vrhel <michael.vrhel@artifex.com>
1bc4205dca71ca075af6ca95aa53a33f5a724586

> Bug 700584 Cups device
> The RGBW color space needs to have the white value mapped properly during the encode process.
> cups/gdevcups.c

2019-02-21 13:01:24 -0800
Michael Vrhel <michael.vrhel@artifex.com>
f89824ec77691e80b954fd0e783fc41cf6246599

> Bug 692405 X11 device
> The X11 device copy_color proc was accessing indices outside its 16 value cache
> causing improper color drawing for the cmyk2 device. For the cmyk4 device, the
> bit manipulations mapping to rgb were incorrect.
> devices/gdevxalt.c

2019-02-21 19:12:18 +0000
Robin Watts <Robin.Watts@artifex.com>
dd60ff8ba5030f078eccabe26a617374c1c2961f

> Improve bounding box return for clip list accumulator.
> This should hopefully reduce the amount of work the scan converter
> has to do every time it writes to the clip list accumulator; in
> particular the clist should set this up so that we don't needlessly
> scan convert lines outside the current band.
> base/gxacpath.c

2019-02-21 14:20:40 +0000
Robin Watts <Robin.Watts@artifex.com>
02b6572798cfa75f1b77cfa666748add0ae7db31

> Bug 700643: Rejig scan converter - back off in high memory cases.
> Group scan converter calling logic together, and call it through
> a single gx_scan_convert_and_fill function.
> Have the scan converter bale if the required memory is larger than
> an arbitrary size (currently 1Meg). We subdivide the path into
> bands and retry.
> base/gxfill.c
> base/gxscanc.c
> base/gxscanc.h

2019-02-19 16:37:53 +0000
Robin Watts <Robin.Watts@artifex.com>
ed1d07fb8c324dea9988359bbcc400979155ffa8

> Avoid buffer overflow in transparency buffer dump debug.
> base/gdevp14.c

2019-02-18 17:48:32 +0000
Robin Watts <Robin.Watts@artifex.com>
f5a93cd8ca658ce80234319e7355335086c71872

> Tweak "device_encodes_tags" to avoid const warnings.
> base/gxdevcli.h

2019-02-22 12:28:23 +0000
Chris Liddell <chris.liddell@artifex.com>
a82601e8f95a2f2147f3b3b9e44ec2b8f3a6be8b

> Bug 700576(redux): an extra transient proc needs executeonly'ed.
> Resource/Init/gs_res.ps

2019-02-21 07:35:41 -0800
Nancy Durgin <nancy.durgin@artifex.com>
70e04b6d103193dd1eb1e7748cb6fb231c0482cf

> Undef .setsafeglobal
> Only used in gs_init.ps, undef right after use.
> Resource/Init/gs_init.ps

2019-02-19 15:03:16 -0800
Nancy Durgin <nancy.durgin@artifex.com>
04e71e429c83dead2c5e69bf126b5c8cf1c18167

> Undef .vmreclaim in gs_init.ps
> This was tricky because it can be used in showpage, which wasn't bound.
> Previous commit makes it possible to bind showpage.
> It's used for debugging in the memento build, but this is useful so I
> needed to maintain that functionality.
> Also used in gs_lev2.ps, so make sure that is bound.
> Since this operator is defined in C in the level2dict, it needs to
> be undef'd from both systemdict and level2dict.
> Resource/Init/gs_init.ps
> Resource/Init/gs_lev2.ps

2019-02-19 14:56:31 -0800
Nancy Durgin <nancy.durgin@artifex.com>
9a6d754d60409d4ff3832d83801b1d3f96303932

> Make it possible to .bind showpage and copypage
> A bunch of operators were being redefined later in other code, so that
> binding showpage and copypage picked up the wrong versions. I think
> historically this was due to the way level2/level3 support was
> implemented. Since we no longer support level1 postscript, we can
> clean some of this up.
> The cleanup involves moving some operators from other files into
> gs_init.ps and also removing duplicate (level1) definitions when applicable.
> - Move 'initgraphics' operator definition from gs_cspace.ps
> - Move .currentnumcopies, .beginpage, .endpage from gs_setpd.ps
> - Move 'copypage' definition down near showpage, so code is in right places
> There are no changes to the code within the moved functions, other than to
> make them .bind executeonly.
> Resource/Init/gs_cspace.ps
> Resource/Init/gs_init.ps
> Resource/Init/gs_setpd.ps

2019-02-19 08:38:08 -0800
Nancy Durgin <nancy.durgin@artifex.com>
214fdd5625c81afa4e2c206eb3e54f1f0435580f

> Undef .getdefaulthalftone in gs_init.ps
> Used in gs_init.ps and gs_ll3.ps. Change to immediate evaluation and undef.
> Resource/Init/gs_init.ps
> Resource/Init/gs_ll3.ps

2019-02-19 09:29:48 -0800
Nancy Durgin <nancy.durgin@artifex.com>
eb5b4c273d42584d560d5d923565fcb4a07ff02d

> Undef .bindoperators in gs_init.ps
> We undef in different places depending on whether BINDNOW is true or not.
> Resource/Init/gs_init.ps

2019-02-18 12:11:45 -0800
Ray Johnston <ray.johnston@artifex.com>
be86d2ff2f0f0ea0e365707f3be0fa0c9e7315ee

> Bug 700599: Issue an error message if an ExtGstate is not found.
> Previously, this was silently ignored. Only issue a single warning,
> and respect PDFSTOPONERROR to prevent continuing with potentially
> incorrect output.
> Note that tests_private/pdf/uploads/bug696410.pdf also now gets this
> error message (ExtGState" instead of ExtGState in object 10).
> Resource/Init/pdf_draw.ps

2019-02-20 09:54:28 +0000
Chris Liddell <chris.liddell@artifex.com>
ed9fcd95bb01f0768bf273b2526732e381202319

> Bug 700576: Make a transient proc executeonly (in DefineResource).
> This prevents access to .forceput
> Solution originally suggested by cbuissar@redhat.com.
> Resource/Init/gs_res.ps

2019-02-20 09:50:13 +0000
Chris Liddell <chris.liddell@artifex.com>
73d1a911f4c8b19c19d37a963c39b01a181b46e1

> Update to iclude TOC overflow solution
> Also, remove the RS/6000 reference, and just reference IBM AIX
> doc/Make.htm

2019-02-19 19:34:59 -0800
Michael Vrhel <michael.vrhel@artifex.com>
e1d09836703104ca5ac8cb94a47f2ce27bee28cd

> Macro removal
> Get rid of two macros in the halftone tile creation code.
> One was replaced with an inline function. The other was simple
> enough and used only in two spots to just use directly.
> base/gxcht.c

2019-02-13 12:01:54 -0800
Michael Vrhel <michael.vrhel@artifex.com>
ba2043a548559d184cbfe90ca9884734dba6efdc

> Bug 700584: cups device
> The cups device has a pile of different color spaces. It is up to the cups device to
> ensure that the color is handled properly for these. RGBA should certainly be treated
> as a 32 3 component color similar to our pngalpha device. RGBW will be treated the same way.
> Note that I looked at the output using Mike Sweet's rasterview program. I suspect there
> probably is some work that needs to be done on that viewer to ensure proper viewing of
> this type of data. With this patch gs is doing all it can.
> cups/gdevcups.c

2019-02-14 15:14:50 -0800
Nancy Durgin <nancy.durgin@artifex.com>
1521304bd0da395fd11a950ab82a40deebc1f8c4

> Undef .makepathtemplate in gs_init.ps
> Only used locally. Change to immediate evaluation and undef.
> Resource/Init/gs_init.ps

2019-02-14 15:10:28 -0800
Nancy Durgin <nancy.durgin@artifex.com>
8512e98984c6d1be2bcefd0493fc5c4dd26f118e

> Undef .uservar in gs_init.ps
> It was already an operator. Make sure all uses are executeonly and undef.
> Resource/Init/gs_init.ps
> Resource/Init/gs_statd.ps
> Resource/Init/gs_trap.ps

2019-02-14 14:23:46 -0800
Nancy Durgin <nancy.durgin@artifex.com>
53a8955c422713ef6794f39de823a03d2f056790

> Undef .userdict in gs_init.ps
> It was already an operator. Make sure all uses are executeonly and undef.
> Resource/Init/gs_dps2.ps
> Resource/Init/gs_init.ps
> Resource/Init/gs_lev2.ps
> Resource/Init/gs_trap.ps

2019-02-14 13:40:08 -0800
Nancy Durgin <nancy.durgin@artifex.com>
7cd5f3cb820f75bc6ad636f09504918d96c9ba63

> Undef .growdict and .growdictlength in gs_init.ps
> Changed uses to immediate evaluation, undef with the others.
> Resource/Init/gs_fonts.ps
> Resource/Init/gs_init.ps

2019-02-14 13:12:17 -0800
Nancy Durgin <nancy.durgin@artifex.com>
4ae191913f5c3260d780108217c63d161f49272a

> Undef .putdeviceprops in gs_init.ps
> This is only used by /putdeviceprops, but I don't understand what's
> going on with error handling and the comment about backward compatibility.
> Both .putdeviceprops and putdeviceprops were already operators.
> Just undef .putdeviceprops with the other operators, after making sure
> everything is executeonly.
> Resource/Init/gs_init.ps

2019-02-14 11:58:00 -0800
Nancy Durgin <nancy.durgin@artifex.com>
9a4acb441374641ba820648e5ae098ce9e5ae9d6

> Undef .promptmsg in gs_init.ps
> There used to be some code related to readline in lib/gs_rdlin.ps
> that would redfine the .promptmsg, but that code is now gone.
> There doesn't seem to be any reason to keep .promptmsg any more.
> If somebody wants to redefine /prompt, that is still fine and is
> documented in the PLRM.
> Change to use immediate evaluation and then undef it.
> Resource/Init/gs_init.ps

2019-02-14 11:39:08 -0800
Nancy Durgin <nancy.durgin@artifex.com>
e187134ce58a398d46cb0065929ecbe9b40b6d7c

> Undef .packtomark in gs_init.ps
> This is used in a bunch of other files. Changed all those to
> immediate evaluation.
> Resource/Init/gs_btokn.ps
> Resource/Init/gs_init.ps
> Resource/Init/gs_res.ps
> Resource/Init/gs_ttf.ps
> Resource/Init/pdf_base.ps
> Resource/Init/pdf_sec.ps

2019-02-16 15:27:43 +0000
Ken Sharp <ken.sharp@artifex.com>
3ba38b60a2380a8fbac7d315da5dfeaaf3d4cf21

> Fix some compiler warnings
> Noticed in a regression run where warnings were not swallowed. When
> using 'C' Keys we should use the function which searches dictionaries
> using a 'C' string instead of a byte string (which may not be null
> terminated).
> devices/vector/gdevpdfj.c

2019-02-16 11:14:57 +0000
Ken Sharp <ken.sharp@artifex.com>
6c4ef58b66dadf546cbc7370ebbabe5505acc7ed

> PS interpreter - properly restore exec stack after error in zshow
> Bug #700618 "Ghostscript - Invalid read in op_show_finish_setup()"
> The problem occurs some time before the actual seg fault. The test file
> is overly complex (not uncommon for fuzzed files), a simpler file would
> be:
> /S 80 string def
> 108 480 moveto
> { 1 S show
> } loop
> This runs in a loop, showing an empty string. But each iteration of the
> loop leaves an object on the exec stack. Eventually we reach the stack
> limit. The internals of 'show' require us to be able to push an object
> (actually, 2 objects) on to the operand stack, so this results in a
> stack overflow.
> Although zshow() checks the return code properly, it does not reset the
> exec stack pointer in the case of an error (it adds up to 11 objects
> to the exec stack itself). For a fatal error this isn't a problem, but
> stack overflow is non-fatal; the interpreter can increase the stack size
> and retry.
> This is where the problem exhibits. When we retry zshow() we have left
> entries on the exec stack, in particular a 'mark', because we didn't
> rewind the exec stack on error. We then try to use that to locate an
> enumerator stored on the exec stack, but because we didn't complete the
> setup, what we find is garbage.
> The solution is simply to restore the exec stack pointer on error,
> before we return. We should also free the enumerator to prevent a
> (saved by garbage collection) memory leak. So also initialise the
> pointer to NULL, so we can safely free it, even if we didn't get round
> to allocating it.
> There are 2 error conditions in this code, we need to update both.
> psi/zchar.c

2019-02-14 10:20:03 -0800
Ray Johnston <ray.johnston@artifex.com>
205591753126802da850ada6511a0ff8411aa287

> Fix bug 700585: Restrict superexec and remove it from internals and gs_cet.ps
> Also while changing things, restructure the CETMODE so that it will
> work with -dSAFER. The gs_cet.ps is now run when we are still at save
> level 0 with systemdict writeable. Allows us to undefine .makeoperator
> and .setCPSImode internal operators after CETMODE is handled.
> Change previous uses of superexec to using .forceput (with the usual
> .bind executeonly to hide it).
> Resource/Init/gs_cet.ps
> Resource/Init/gs_dps1.ps
> Resource/Init/gs_fonts.ps
> Resource/Init/gs_init.ps
> Resource/Init/gs_ttf.ps
> Resource/Init/gs_type1.ps

2019-02-14 10:16:18 -0800
Nancy Durgin <nancy.durgin@artifex.com>
4250323f0c5e85f43bd82255c846f98869a46354

> Remove undef of /odef from the SAFER list.
> Oops, this change crept in on an earlier commit. No need to include in
> the SAFER list since it's being undef'ed in the main list.
> Resource/Init/gs_init.ps

2019-02-14 10:09:00 -0800
Nancy Durgin <nancy.durgin@artifex.com>
e8acf6d1aa1fc92f453175509bfdad6f2b12dc73

> Undef /odef in gs_init.ps
> Made a new temporary utility function in gs_cet.ps (.odef) to use instead
> of /odef. This makes it fine to undef odef with all the other operators in
> gs_init.ps
> This punts the bigger question of what to do with .makeoperator, but it
> doesn't make the situation any worse than it already was.
> Resource/Init/gs_cet.ps
> Resource/Init/gs_init.ps

2019-02-13 14:03:29 -0800
Nancy Durgin <nancy.durgin@artifex.com>
3e6e57c0a80948f322b9842add4a7ab86915cdc6

> Undef /obind from gs_init.ps
> This is only used in gs_typ32.ps, just undef with all the other things in
> gs_init.ps
> Resource/Init/gs_init.ps

2019-02-13 13:54:25 -0800
Nancy Durgin <nancy.durgin@artifex.com>
533f78554f194524abb55183d370e64354caa329

> Deleted definition of /execute, which wasn't used anywhere.
> As far as I can tell... It's extremely challenging to try to grep for uses of
> this word.
> Resource/Init/gs_init.ps

2019-02-13 09:36:29 -0800
Nancy Durgin <nancy.durgin@artifex.com>
c5ed6a1f8583068484b4c138fb1e0e1ef1ad2a3f

> Undef /runlibfile0 in gs_init.ps
> This is just used temporarily.
> Change to immediate evaluation and undef right after use.
> Resource/Init/gs_init.ps

2019-02-13 08:43:00 -0800
Nancy Durgin <nancy.durgin@artifex.com>
e0b0c12518bc58020efda5ca3d1e4888b33060b2

> Delete /ppstack, which is defined in gs_init.ps and not used anywhere
> Resource/Init/gs_init.ps

2019-02-13 08:29:39 -0800
Nancy Durgin <nancy.durgin@artifex.com>
b26b5ec2be0a924981a47c8a66b1cfe936170129

> Remove 'copystring', which was only used in one place
> Just put the code in-line.
> Resource/Init/gs_fonts.ps
> Resource/Init/gs_init.ps

2019-02-12 14:00:29 -0800
Nancy Durgin <nancy.durgin@artifex.com>
25c744f8a7761676d7790f513ca138eaaed2c366

> Undef .set/.currentfilladjust, re-def .set/.currentfilladjust2
> The .setfilladjust, .currentfilladjust were just wrappers around the
> '2' versions. They were used in only a couple places, and were just
> dupping/popping the extra args, so I replaced these with equivalent
> uses of the underlying operators.
> These were "compatibility" operators for .setfilladjust2 and
> .currentfilladjust2, which do the same basic thing but take two values
> (x,y) instead of 1.
> Robin wants these to be official extensions because they are useful
> for testing, so I have taken out the code that undef's .setfilladjust2
> and .currentfilladjust2. We need to add documentation for these.
> Resource/Init/gs_init.ps
> Resource/Init/pdf_ops.ps

2019-02-12 10:41:34 -0800
Nancy Durgin <nancy.durgin@artifex.com>
509cb1f2103a2b35efe463271a94b2c33ed6b838

> Undef /printgreeting in gs_init.ps
> Only used locally. Undef right after use.
> Resource/Init/gs_init.ps

2019-02-13 15:15:33 +0000
Robin Watts <robin.watts@artifex.com>
0e0981f84562bff97f45e401c704289544d4f523

> Avoid buffer overread in pcl ccittfax decompression.
> If you:
> make gpcl6debugvg
> valgrind --track-origins=yes debugbin/gpcl6 -sOutputFile=test.pdf
> -dMaxBitmap=400000000 -sDEVICE=pdfwrite -r75 -Z: -dNOPAUSE
> -dBATCH -K2000000 -dClusterJob
> tests_private/customer_tests/bug693269.prn
> Then we get valgrind errors in cf_decode_eol.
> The cause is that process_ccitt_compress is making the read buffer
> 4 bytes too long, due to forgetting to remove the allowance for the
> 4 bytes used for the header word.
> The fix is simply to adjust the buffer size.
> pcl/pcl/rtraster.c

2019-02-09 13:34:17 +0100
Sebastian Rasmussen <sebras@gmail.com>
660eaabf87a143b5217dc875550968883d8e4fc0

> Bug 700554: jbig2: Use custom allocator for jbig2dec/luratech decoders.
> base/sjbig2.c
> base/sjbig2.h
> base/sjbig2_luratech.c
> base/sjbig2_luratech.h
> psi/zfjbig2.c

2019-02-09 13:34:38 +0100
Sebastian Rasmussen <sebras@gmail.com>
0d942b34ae4a5385f5cd3cfa9b2c708f56c65860

> jbig2dec: Return allocator once it is retired.
> jbig2dec/CHANGES
> jbig2dec/jbig2.c
> jbig2dec/jbig2.h

2019-02-12 17:27:56 +0000
Chris Liddell <chris.liddell@artifex.com>
0fb8c19f9b848fb691dc067a0feebbfee539672b

> Bug 700564: Tweak to fix shared libjpeg
> A custom header include wasn't protected by proprocessor directives.
> And remove one not required inclusion.
> base/sjpegc.c
> devices/gdevpdfimg.c

2019-02-12 08:04:39 -0800
Nancy Durgin <nancy.durgin@artifex.com>
ecf45905a555386c157967aefc986c94002b3c6d

> Undef .pdfcharkeys from gs_ttf.ps
> Used locally. Change to immediate evaluation and undef.
> Resource/Init/gs_ttf.ps

2019-02-07 14:22:14 -0800
Nancy Durgin <nancy.durgin@artifex.com>
05dddc4d150b372eecd28817b8441694843b64d8

> Move code around to prepare for more undef'ing
> Moved code so things are declared before referenced.
> No changes to the code, just moved it around in the file.
> Resource/Init/gs_ttf.ps

2019-02-07 14:02:49 -0800
Nancy Durgin <nancy.durgin@artifex.com>
e7faf522a5f5a770659cf4d1c9cd7f3362eb9b4d

> Undef .findcmap, .pdfmapsymbolic in gs_ttf.ps
> Used locally. Change to immediate evaluation and undef.
> Resource/Init/gs_ttf.ps

2019-02-07 13:53:00 -0800
Nancy Durgin <nancy.durgin@artifex.com>
9a0db357352e338fe8432ec1e18aa901aed61fdd

> Undef .loadttcidfont, .loadpdfttfont in gs_ttf.ps
> These are used in pdf_font.ps. Need to rearrange the order of things
> in the Makefiles so that gs_ttf.ps is included before pdf_font.ps in
> obj/iconfig.h. This also meant moving gs_mgl_e.ps, though I wonder if
> it could be moved up with the other encodings (gs_mex_e.ps,
> gs_mro_e.ps, etc). I didn't look into right now -- it would be a lot
> of Makefile hacking.
> After makefile change: change .loadttcidfont and .loadpdfttfont to
> operators, make sure their usage is executeonly, and undef in
> gs_init.ps.
> Resource/Init/gs_init.ps
> Resource/Init/gs_ttf.ps
> psi/int.mak

2019-02-12 09:15:54 +0000
Chris Liddell <chris.liddell@artifex.com>
355434f4b1bbe8c4f98cafad5a6868aa2f0eaae1

> Bug 700533: Undo FT over/underflow workaround
> Older versions of Freetype had a problem with overflow (and underflow) in the
> Truetype hinting code. That was resolved some time ago with the addition of
> (or handling of) the F_dot_P value.
> In the file associaited with this issue, the glyph offset is caused by this
> workaround.
> Thus the workaround is no longer required, and as it actually causes a problem,
> it is hereby removed.
> base/fapi_ft.c

2019-02-11 07:40:02 -0800
Robin Watts <Robin.Watts@artifex.com>
fd643f053ea4a311a9e61a10069cfe8747aa950c

> Bug 700577: Follow on fix.
> If the matrix inversion fails, set values for tmat as well as smat.
> devices/vector/gdevpdtt.c

2019-02-11 09:31:04 +0000
Chris Liddell <chris.liddell@artifex.com>
0038d98e024edb55a844f8371e62eacbbeb6f6a6

> Bug 700582: Handle disabled streams in s_file_available()
> and s_file_read_seek()
> base/sfxstdio.c

2019-02-06 17:30:00 +0000
Chris Liddell <chris.liddell@artifex.com>
52196a78714e632c2c4001edffc65285346ac998

> Ensure uses of true/false/null are immiediately evaluated
> Resource/Init/gs_cet.ps
> Resource/Init/gs_epsf.ps
> Resource/Init/gs_init.ps
> Resource/Init/gs_lev2.ps
> Resource/Init/gs_pdfwr.ps
> Resource/Init/gs_setpd.ps
> Resource/Init/pdf_base.ps
> Resource/Init/pdf_draw.ps
> Resource/Init/pdf_font.ps
> Resource/Init/pdf_main.ps
> Resource/Init/pdf_ops.ps

2019-02-10 17:56:23 -0800
Michael Vrhel <michael.vrhel@artifex.com>
08ffa461bbf0914757c11be28c99829dcdae5a38

> Bug 696318 psdcmykog issues
> The psdcmykog device has to ignore certain postscript color settings since
> it does not support any colorants other than the cmykog ones.
> I tested with a file that had Artifex Green and Artifex Orange to
> ensure that rendered properly still after this fix.
> devices/gdevpsd.c

2019-02-10 19:10:26 -0700
Henry Stiles <henry.stiles@artifex.com>
aaf522721db34addf48ae1cc64d559bddbcc1c02

> Improve function naming and simplify initialization and destructor.
> No expected differences.
> pcl/pxl/pximage.c

2019-02-08 04:08:08 +0100
Sebastian Rasmussen <sebras@gmail.com>
d9edb5a256b00e787d72462320112ef39bfa27b3

> Without enough prefix codes, a Huffman table cannot be generated.
> Previously this was treated as a warning, possibly allowing access
> to uninitialized prefix code entries.
> jbig2dec/jbig2_text.c

2019-02-08 04:03:40 +0100
Sebastian Rasmussen <sebras@gmail.com>
e4a0d6264627ece2a2c09da9d81d21b6b2158481

> Make sure to indicate error upon unexpected OOB.
> jbig2dec/jbig2_text.c

2018-12-07 18:12:48 +0100
Sebastian Rasmussen <sebras@gmail.com>
a89d75c1a059093aab4218046a9f258e86a5ab5f

> Clarify the element size of GR_stats when memsetting.
> In case Jbig2ArithCx ever changes, but it is unlikely.
> jbig2dec/jbig2_symbol_dict.c

2019-02-08 04:15:41 +0100
Sebastian Rasmussen <sebras@gmail.com>
f2cadf483f44518ddae68c3146ae77f205f7e11b

> Use common pattern for error detection.
> Previously the code used a non-standard variant, but it is better
> to do error detection the same way everywhere.
> jbig2dec/jbig2_halftone.c

2018-12-07 18:12:23 +0100
Sebastian Rasmussen <sebras@gmail.com>
6238141c4564df091515fac92e3c35275d5ce26f

> Bug 700384: Indicate error upon error, do not just warn.
> Building a Huffman table failed, this was correctly detected,
> but success was indicated to the caller causing a reference
> template to be left uninitialized, which later on caused the
> generic refinement region decoder attempt to use this
> uninitialized data. This was reported by MSAN.
> Thanks to oss-fuzz for reporting.
> jbig2dec/jbig2_text.c

2019-01-24 03:55:57 +0100
Sebastian Rasmussen <sebras@gmail.com>
a0421f035fd418d27fd2df80b896d97d3d6e87ea

> Bug 694247: Do not confuse openjpeg input buffer usage with size.
> Previously s_opjd_accumulate_input() populated the openjpeg input data
> buffer and adjusted the buffer size and usage fields accordingly. The
> openjpeg callbacks for reading, skipping and seeking confused these two
> fields and used the buffer size instead of the buffer usage. This meant
> that there was a risk of reading uninitialized data.
> base/sjpx_openjpeg.c

2019-01-25 15:49:56 +0100
Sebastian Rasmussen <sebras@gmail.com>
9a317d2ddfb82ad584a91540fca80db36c6440c7

> Add sanitize variant of gpdl target.
> base/unix-end.mak

2019-02-07 18:18:59 +0000
Robin Watts <robin.watts@artifex.com>
38c864f6300ccb2664c3d8707ef41564645742e4

> Fix Memento_find when running under valgrind.
> base/memento.c

2019-02-07 20:00:55 +0000
Robin Watts <robin.watts@artifex.com>
046cd2e7fc5c6a11a5e59835b06a70f3b65f9eb1

> Ensure that gs_matrix_invert always has its return checked.
> If you do:
> make gsdebugvg
> valgrind --track-origins=yes debugbin/gs -sOutputFile=test.ps
> -dMaxBitmap=400000000 -sDEVICE=ps2write -r300 -Z: -dNOPAUSE
> -dBATCH -K2000000 -dClusterJob comparefiles/Bug694772.pdf
> then you get:
> Conditional jump or move depends on uninitialised value(s)
> at 0x945795: gs_matrix_multiply (gsmatrix.c:88)
> by 0x7E568B: pdf_calculate_text_size (gdevpdtt.c:2352)
> by 0x7E58DD: pdf_update_text_state (gdevpdtt.c:2386)
> by 0x7D2E28: pdf_process_string (gdevpdte.c:679)
> by 0x7D079E: pdf_process_string_aux (gdevpdte.c:79)
> by 0x7D68D1: process_plain_text (gdevpdte.c:1582)
> by 0x7E902C: pdf_text_process (gdevpdtt.c:3566)
> by 0x956BEC: gs_text_process (gstext.c:595)
> by 0xB445A0: op_show_continue_pop (zchar.c:583)
> by 0xB42B95: zshow (zchar.c:71)
> by 0xB11AD6: do_call_operator (interp.c:86)
> by 0xB14B0D: interp (interp.c:1300)
> Uninitialised value was created by a stack allocation
> at 0x7E57EA: pdf_update_text_state (gdevpdtt.c:2373)
> This is because a matrix inversion fails and is uncaught.
> base/gshtscr.c
> devices/vector/gdevpdfi.c
> devices/vector/gdevpdtc.c
> devices/vector/gdevpdtt.c
> devices/vector/gdevpx.c
> devices/vector/gdevtxtw.c
> devices/vector/gdevxps.c
> pcl/pxl/pximage.c

2019-02-07 17:30:48 +0000
Robin Watts <robin.watts@artifex.com>
1c247504269f70d07ce95104440a36f34f1a68a0

> Bug 700577: Ensure text enum initialisation sets reqired flags
> The default begin_text function initialises various things like
> charpath_flag and is_pure_color. The PCL interpreter then calls
> directly into the graphics lib for string measurement etc, and
> this depends on these flag.
> Sadly, not all text enumerator initialisations set these flags;
> in particular if we have the flp device in effect, the subclass
> begin_text function is used and that does not init those values.
> The simplest solution appears to be to amend
> gs_text_enum_init_dynamic to always set these flags as required.
> base/gstext.c
> base/gxchar.c

2019-01-31 16:34:30 -0800
Michael Vrhel <michael.vrhel@artifex.com>
f10f2900633674746f6a8155200f24db51449523

> Bug 696318: psdrgb device
> With certain postscript files, the psdrgb device was getting its process
> color model changed causing significant confusion for the device.
> devices/gdevpsd.c

2019-02-06 21:36:54 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
5daf81e0edb5dee2911bf419fa2423b2588449ab

> Bug 697545 : Prevent numerous memory leaks.
> Cleanup font for all error returns.
> Error created using :-
> MEMENTO_FAILAT=21465 ./membin/gpcl6 -sDEVICE=pbmraw -dMaxBitmap=2000 -o /dev/null ./tests_private/pcl/pcl5cfts/fts.0282
> pcl/pcl/pcsfont.c

2019-02-06 09:51:49 -0800
Ray Johnston <ray.johnston@artifex.com>
8da995af1f586f2f90cac274aa738cd8dad3759f

> Undef check_r6_password and PDFexecform
> Immediate binding and undef for check_r6_password.
> Move PDFexecform from gs_lev2.ps to pdf_draw.ps (the only place it was
> used), and put it and .PDFexecform in pdfdict. PDFexecform and
> .PDFexecform don't need odef -- just make them executeonly (even though
> they will be hidden in pdfdict).
> Also change the initial size of pdfdict to just over the actual size
> (it was growing to > 400 maxlength).
> Resource/Init/gs_lev2.ps
> Resource/Init/pdf_draw.ps
> Resource/Init/pdf_main.ps
> Resource/Init/pdf_ops.ps
> Resource/Init/pdf_sec.ps

2019-02-07 08:48:53 -0800
Nancy Durgin <nancy.durgin@artifex.com>
060c83126ad016a691f6ef1b43d5232956ddc128

> Undef /.loadttfont, /.loadwofffont, /.loadwofftables from gs_ttf.ps
> Used locally, so change to immediate evaluation and undef.
> Resource/Init/gs_ttf.ps

2019-02-06 15:35:05 -0800
Nancy Durgin <nancy.durgin@artifex.com>
bdc3e6b7201c2a73eeae60cf4cfffb843f5034ea

> Reorder code to prep for future cleanup
> Resource/Init/gs_ttf.ps

2019-02-06 14:36:01 -0800
Nancy Durgin <nancy.durgin@artifex.com>
dd3b403b72931b9ef52630665fc418ad96075197

> Undef .readttdata,.nname in gs_ttf.ps
> Used locally. Use immediate evaluation and undef.
> Resource/Init/gs_ttf.ps

2019-02-06 14:34:01 -0800
Nancy Durgin <nancy.durgin@artifex.com>
46ec997913d63b6c7d3ac666484c1a04551a082b

> Undef .printtab in gs_ttf.ps
> Used locally, so change to immediate evaluation and undef.
> Resource/Init/gs_ttf.ps

2019-02-06 14:28:17 -0800
Nancy Durgin <nancy.durgin@artifex.com>
91bf6eef15c30efd90c4e98cc4b95e9e7f85a763

> Undef .pickcmap, .pickcmap_with_xlatmap, .pickcmap_with_no_xlatmap in gs_ttf.ps
> .pickcmap uses immediate evaluation on the other two, so just undef them.
> Make .pickcmap an operator because it's a big function. Make sure all uses
> are executeonly. Undef in gs_init.ps.
> Resource/Init/gs_init.ps
> Resource/Init/gs_ttf.ps

2019-02-06 13:01:26 -0800
Nancy Durgin <nancy.durgin@artifex.com>
715541a5c7390508d923d48e2eda4417b82a2710

> Undef .makesfnts in gs_ttf.ps
> Large procedure, so made it an operator. Make sure all references are
> executeonly. Undef in gs_init.ps.
> Resource/Init/gs_init.ps
> Resource/Init/gs_ttf.ps

2019-02-06 11:47:15 -0800
Nancy Durgin <nancy.durgin@artifex.com>
ce52f184357a8043c0b314f2e8319237b75c29ae

> Undef .ttkeys in gs_ttf.ps
> Used locally -- change to immediate evaluation and undef at end of file.
> Resource/Init/gs_ttf.ps

2019-02-06 10:12:34 -0800
Nancy Durgin <nancy.durgin@artifex.com>
c58684b54be4190a8f1ce3d92200f420aefba9dd

> Undef .is_ttf_or_otf, .is_woff from gs_ttf.ps
> Only used locally, changed to immediate evaluation.
> Also moved some of the related things that were already undef'd, to be
> handled together.
> Resource/Init/gs_ttf.ps

2019-02-07 07:12:36 -0800
Michael Vrhel <michael.vrhel@artifex.com>
7cc8aeb7bf93deab5d86aeeca6c5b22a3890345d

> Bug 700571 SoftMask Matte rendering
> Fix for multiple issues with the removal of the preblended transparency
> that can exist with the softmask
> base/gdevp14.c
> base/gdevp14.h
> base/gxblend.c

2019-02-04 11:36:19 -0800
Robin Watts <Robin.Watts@artifex.com>
28f825c642a9af53136a7e661c6026db53604b76

> Workaround Shading/clist valgrind issues with trans_device.
> When shading into the clist the code has to cope with 2 devices;
> the target device, and the 'trans_device', which is updated to
> use the source colorspace for the shading.
> The number of components can vary between the two, meaning that
> the shading code has to be passing (say) 1 component around,
> but the call into the clist will attempt to write (say) 3 components.
> The clist appears to cope with this mismatch on reading (and I
> haven't found a case where we write too few components), so for
> now, just add a hacky PACIFY_VALGRIND section to clear the
> spare color components.
> base/gxshade6.c

2019-02-05 15:22:15 -0800
Nancy Durgin <nancy.durgin@artifex.com>
6c8a539b2a2c199bcde37acc652b882239407c47

> Undef .is_hex_digit, .pop3ex, .popfex from gs_ttf.ps
> These were already used with immediate evaluation, so just need to undef.
> Resource/Init/gs_ttf.ps

2019-02-05 14:06:06 -0800
Nancy Durgin <nancy.durgin@artifex.com>
ebfacf80bf673dbaa7e742687f4d319cd1b8dd11

> Undef .loadttfontdict, which undefs a bunch of internal procedures
> Changed to immediate evaluation of the dict. Undef dict at end of file.
> Eliminates a bunch of internal procedures.
> Resource/Init/gs_ttf.ps

2019-02-05 12:19:00 -0800
Nancy Durgin <nancy.durgin@artifex.com>
402c16dec171424700639d8aa41009dbc57b66a7

> Remove undef of /postalias that was supposed to be removed after v9.09
> There are no remaining references to "postalias", so this appears to be
> dead/unneeded code, as indicated by the comment.
> Resource/Init/gs_ttf.ps

2019-02-05 12:12:42 -0800
Nancy Durgin <nancy.durgin@artifex.com>
3575fc86cfcffcec935023238a2d6d0ae62875ca

> Undef .findttfontname and .findwoffname from gs_ttf.ps
> Move code so defined before use. Use immediate evaluation. Undef locally.
> Resource/Init/gs_ttf.ps

2019-02-05 12:07:36 -0800
Nancy Durgin <nancy.durgin@artifex.com>
4e051acc94b70a952ba2f2baa7209df3a2924bb6

> Undef .findseg from gs_ttf.ps
> Used locally. Immediate ref and undef in file.
> Resource/Init/gs_ttf.ps

2019-02-05 11:54:12 -0800
Nancy Durgin <nancy.durgin@artifex.com>
1bebd7f9f299026de62868e72f70979460080a27

> Undef .fill_identity_cmap, .definettcidfont in gs_ttf.ps
> Local definition -- use immediate evaluation and then undef.
> Resource/Init/gs_ttf.ps

2019-02-05 09:28:48 -0800
Nancy Durgin <nancy.durgin@artifex.com>
9876fb74118b91ec87a34673735bcd89900ad66a

> Undef .charkeys from gs_ttf.ps
> - This is a huge procedure, so I made it an operator rather than using
> immediate evaulation
> - Make sure all uses are executeonly
> - Undef in gs_init.ps
> Resource/Init/gs_init.ps
> Resource/Init/gs_ttf.ps

2019-02-05 09:25:17 -0800
Nancy Durgin <nancy.durgin@artifex.com>
3c12cbfa2585c4af7173e6045c2339f051574b3c

> Undef .addglyph from gs_ttf.ps
> - this already only had immediate references
> - undef at end of gs_ttf.ps
> Resource/Init/gs_ttf.ps

2019-02-06 11:17:27 +0000
Robin Watts <robin.watts@artifex.com>
1ca42001f0ae456aa3ec080e88719e2d4b4f8131

> Tweak cff_write_Encoding to avoid writing badly formed table.
> The following:
> make gsdebugvg
> valgrind --track-origins=yes debugbin/gs -sOutputFile=/dev/null
> -dMaxBitmap=400000000 -sDEVICE=pdfwrite -r72 -Z: -dNOPAUSE
> -dBATCH -K2000000 -dClusterJob Bug691693.pdf
> results in valgrind warnings:
> Use of uninitialised value of size 8
> at 0x53F0B6: deflate_slow (in ghostpdl/bin/gs)
> by 0x53CDA5: deflate (in ghostpdl/bin/gs)
> by 0x6CB1B7: s_zlibE_process (in ghostpdl/bin/gs)
> by 0x6B35F0: swritebuf (in ghostpdl/bin/gs)
> by 0x6B31EB: s_process_write_buf (in ghostpdl/bin/gs)
> by 0x6B28E5: spputc (in ghostpdl/bin/gs)
> by 0x6B2CE1: sputs (in ghostpdl/bin/gs)
> by 0x7E3A43: type2_put_hintmask (in ghostpdl/bin/gs)
> by 0x7E4704: psf_convert_type1_to_type2 (in ghostpdl/bin/gs)
> by 0x7D9770: cff_put_CharString (in ghostpdl/bin/gs)
> by 0x7DAB9B: cff_write_CharStrings (in ghostpdl/bin/gs)
> by 0x7DC58B: psf_write_type2_font (in ghostpdl/bin/gs)
> Uninitialised value was created by a stack allocation
> at 0x7DAF8E: cff_write_Encoding (in ghostpdl/bin/gs)
> Investigation shows that cff_write_Encoding is outputting a table
> with uninitialised bytes in that. Not only that, in such cases
> it can clearly omit some valid data.
> Conceptually, the routine starts with an empty index table, with
> uninitialised values. For each of the possible 256 entries within
> the font, it attempts to encode the char to get the glyph index.
> If this fails, then the glyph is not encoded, so not mentioned in
> the table.
> Assuming it is encoded, it finds the index for that glyph within
> the subset. If there is no index, then it is not in the subset, so
> no entry in the table.
> If there is an index, we look up the glyph name. If there is no
> glyph name, we choose not to encode the glyph in the table. This
> is the (first) case which is causing us problems.
> Finally, we check to see if the encoded index fits into the simple
> (0..255) table without clashing with a previously encoded glyph;
> if so, we insert it into the index table (incrementing the number
> of entries we have inserted), if not, we have to resort to using a
> supplement entry.
> The code then assumes that the first 'actual_enc' bytes of index
> make up the table. This is sadly not the case.
> In the test given above, this routine is called several times, one
> of which demonstrates that this assumption is false.
> While the entries do yield a set of index values that form a prefix
> within the table (from 0 to 20), number 14 has no glyph name. This
> results in byte 14 of the table having a garbage value in, and
> (more worryingly), because actual_enc is only incremented to 20,
> we don't write the final entry of the table at all, effectively
> dropping a glyph.
> It is possible that something has gone wrong earlier in the process
> and that this should be a fatal error, but observation of the code
> shows that if we use a supplement, because a j maps to a previously
> used i, we'll similarly miscount the length of the table.
> A better solution, seems to me, to be to keep track of the maximum
> encoded value that has gone into the index table, and to ensure
> that every value within that table has a defined value.
> The table is initialised with 0's, as Chris informs me that the CIF
> SID for .notdef is 0.
> We make matching changes to cff_Encoding_size.
> devices/vector/gdevpsf2.c

2019-02-06 09:54:22 +0000
Ken Sharp <ken.sharp@artifex.com>
0cf2aa5cdb1d7392cd4a6b11a30625be91ef9be0

> PDF interpreter - reset colour space after starting a Group
> Bug #700572 "PDF to TIFF - only borders left after conversion - no errors"
> The problem is that the PDF file does not set a fill (or indeed stroke)
> colour space or colour before beginning to draw on the canvas. Thus it
> relies upon the default colour values.
> Because the page has a transparency Group, and the Group has a Colour
> space, we set the colour space before we begin rendering. The defined
> colour space of the group is an ICCBased space with four components.
> The PDF Reference is clear that the default colour for an ICCBased space
> is that all the components should be 0. This results in us drawing all
> the filled elements in 0 0 0 0, or white.
> We need to set the colour space before we define the group for the
> transparency compositor, because the code relies upon the colour space
> of the group being current at the time the group is 'defined'.
> Grabbing the current colour space, before setting the group space, and
> then setting it back again afterwards, effectively a gsave/grestore but
> only for the colour space fixes this problem. This causes differences in
> 7 test files, which I believe are progressions.
> Resource/Init/pdf_draw.ps

2019-02-05 07:31:05 -0800
Nancy Durgin <nancy.durgin@artifex.com>
8d0253fdeb73bdb021f665e7c5478d6e1f41898e

> Delete .makemodifiedfont
> This goes with .definemodifiedfont, which was previously deleted.
> Neither of these functions are referenced anywhere, so removing completely.
> Resource/Init/gs_fonts.ps

2019-01-31 15:06:54 -0800
Nancy Durgin <nancy.durgin@artifex.com>
d0883434eb7fd7239048b404dab884803a42f52d

> Undef .FontDirectory
> - It was already an operator. Make it executeonly.
> - Make sure all uses are executeonly.
> - Undef in gs_init.ps
> Resource/Init/gs_fonts.ps
> Resource/Init/gs_init.ps

2019-01-31 12:10:48 -0800
Nancy Durgin <nancy.durgin@artifex.com>
cea599bca413609c288a43c7b1d765b53f200083

> Undef .substitutefont and .substitutefontname
> Used in gs_fonts.ps and pdf_font.ps
> - make it an operator
> - make sure all procedures that use it are executeonly
> - undef in gs_init.ps
> Resource/Init/gs_fonts.ps
> Resource/Init/gs_init.ps

2019-01-31 11:58:21 -0800
Nancy Durgin <nancy.durgin@artifex.com>
c52e82d2eeae0eb498eef80c1a86d788fe0b117d

> Undef .loadinitialfonts
> Defined in gs_fonts.ps and used in gs_init.ps. Undef right after use in
> gs_init.ps.
> Resource/Init/gs_init.ps

2019-02-04 16:56:51 +0000
Robin Watts <robin.watts@artifex.com>
c5fd7dc0f3c706eddd59488a33fc334a2860da49

> Ensure return code of gs_bbox_transform_inverse always checked.
> Spotted this while debugging something else.
> base/gdevbbox.c
> base/gdevbbox.h
> base/gsdevmem.c
> base/gslib.c
> base/gsshade.c
> base/gxp1fill.c
> base/gxshade1.c
> base/gxshade6.c
> xps/xpsopacity.c

2019-02-01 10:48:31 +0000
Robin Watts <robin.watts@artifex.com>
2d5b86f0acf37fcb6176817580c2d3bb745e27d2

> Avoid valgrind error in gs_shading_A_fill_rectangle_aux
> The following sequence:
> make gsdebugvg
> debugbin/gs -sOutputFile=test.pdf -dMaxBitmap=400000000
> -sDEVICE=pdfwrite -r72 -Z: -dNOPAUSE -dBATCH -K2000000 -dClusterJob
> /home/marcos/cluster/tests_private/comparefiles/Bug695746.pdf
> valgrind --track-origins=yes debugbin/gs -sOutputFile=/dev/null
> -dMaxBitmap=400000000 -sDEVICE=ppmraw -r72 -Z: -dNOPAUSE -dBATCH
> -K2000000 -dClusterJob test.pdf
> produces valgrind errors:
> ==31466== Conditional jump or move depends on uninitialised value(s)
> ==31466== at 0x47873B: gs_shading_A_fill_rectangle_aux (gxshade1.c:256)
> ==31466== by 0x478B6A: gs_shading_A_fill_rectangle (gxshade1.c:301)
> ==31466== by 0x476374: gs_shading_do_fill_rectangle (gsshade.c:477)
> ==31466== by 0x4748DB: gx_dc_pattern2_fill_rectangle (gsptype2.c:243)
> ==31466== by 0xA442ED: gx_default_fill_path (gxfill.c:707)
> ==31466== by 0xA75F9C: gx_fill_path (gxpaint.c:52)
> ==31466== by 0x94D38A: do_fill (gspaint.c:318)
> ==31466== by 0x94D488: fill_with_rule (gspaint.c:352)
> ==31466== by 0x94D4D7: gs_fill (gspaint.c:363)
> ==31466== by 0xB64A36: zfill (zpaint.c:27)
> ==31466== by 0xB10E74: do_call_operator (interp.c:86)
> ==31466== by 0xB143DA: interp (interp.c:1410)
> ==31466== Uninitialised value was created by a stack allocation
> ==31466== at 0x4784DC: gs_shading_A_fill_rectangle_aux (gxshade1.c:216)
> These are due to the inversion of a matrix failing, and the error
> being ignored.
> Fix the error handling in the function; if the inversion fails, just
> don't render anything and exit. Returning an error causes content to
> be lost from cluster test files.
> As a side effect of this, fix gsicc_release_link to follow the
> general rule for destructors that they should accept NULL without
> error.
> base/gsicc_cache.c
> base/gsmatrix.c
> base/gxshade1.c

2019-02-03 12:09:52 +0000
Chris Liddell <chris.liddell@artifex.com>
556bb1c7110ee65af5c38a32610c8dfdd9aedc43

> Add non-packed capability to packps
> For creating opdfread.h we normally strip comments and whitespace from the
> Postscript, but that makes reading debugging the opdfread Postscript even more
> unpleasant than it has to be.
> This adds a "-d" option ("don't pack") to pack_ps.c.
> Also adds a subtarget for opdfread.h that means invoking make thus:
> make DEBUG_OPDFREAD=1
> will create opdfread.h without stripping whitespace and comments, so the output
> from ps2write is only baroque and less wilfully horrific.
> base/pack_ps.c
> devices/devs.mak

2019-02-03 12:09:04 +0000
Chris Liddell <chris.liddell@artifex.com>
7f86b6a5add79b7a32d216f5095e93112ff58506

> Add copyright notice to source file
> devices/gdevpdfimg.c

2019-02-04 17:01:42 +0000
Ken Sharp <ken.sharp@artifex.com>
dc685b7525c9ccea3ee59bacd6d6f25ab22d174a

> pdfwrite - use the correct enumerator when handling PCL bitmap fonts
> Bug #700562 "Valgrind reveals use of unitialised value in text code"
> This is a follow-on from commit c47512e5e638d903d69925f7ebab4de2aa3f481f
> again what we have is confusion over *which* of the two enumerators we
> should be using, when we are converting fonts which we can't preserve
> into type 3 fonts.
> For non-PCL cases we don't need the text enumerator for the 'default'
> show functions, so we specifically set pdev->pte to NULL (at around line
> 3477 in gdevpdtt.c). However for PCL bitmap fonts, or the GL/2 stick
> font, we do need the 'default' enumerator which we create in order to
> process the 'BuildGlyph' for the character.
> So we need to make sure we are using the correct enumerator when we try
> to read back the 'returned_glyph'.
> devices/vector/gdevpdtt.c

2019-02-03 14:44:02 -0700
Henry Stiles <henry.stiles@artifex.com>
0495abb3605831147f39691701030405b44cd5d0

> Fix 700565 - SetHalftoneMethod parsing is wrong.
> The parameter numbering was off by one and the check for object type
> should not have exited the command.
> Also change the operator to not report missing attributes. This
> results in changes to error test files in the Quality Logic suite,
> however, we did not match the HP error report previously and don't
> plan to do so. Oddly, HP reports a C file and line number in the
> report, we suspect this is a bug.
> pcl/pxl/pxink.c

2019-02-04 10:39:19 +0000
Ken Sharp <ken.sharp@artifex.com>
cfc80a96f5ba682d86ce2ee1375cfca5b5941fea

> type 3 masked image - pacify valgrind with pdfwrite
> Bug #693814 "Valgrind reports uninitialised value(s) in pdf written image streams"
> The valgrind warnings are real, but essentially benign. If the wisth of
> the mask data for a type 3 masked image is not a multiple of 8, then we
> do not completely write to each bit of the final byte of mask data.
> When writing the mask data to a PDF file, we obviously write the entire
> last byte, which causes valgrind to (correctly) complain about using
> uninitialised data. Of course the uninitialised bits are never actually
> used, even by the PDF consumer.
> We could put a PACIFY_VALGRIND around this line, but writing
> uninitialised bytes means we could run the same input twice and get two
> slight different PDF files, which would flag as a diff in our testing.
> It would also annoy the 'reproducible builds' people, potentially.
> Since its only a single byte, just clear it for reproducibility, even
> when we aren't running valgrind.
> base/gximage3.c

2019-02-02 16:21:48 +0000
Ken Sharp <ken.sharp@artifex.com>
ca8246f639c73127fd05b674679864a9bf2eb0d2

> XPS interpreter - address a valgrind problem
> Bug #700557 "valgrind error pdfwriting text from an xps file"
> The fault is not in pdfwrite, its the XPS interpreter. The pdfwrite
> device copies a font, which involves calling gs_c_name_glyph() to
> retrieve the name of a given glyph. The expectation (because this is
> making a copy of a font) is that the returned string will be persistent
> and not managed by the font or pdfwrite.
> In the PostScript interpreter this is managed by adding the glyph name
> to the PostScript name table, which is persistent to the end of job and
> then freed.
> Now, the XPS interpreter supplies a routine xps_true_callback_glyph_name
> which is called to retrieve the glyph name. If there is a POST table in
> the font, and it has names, and we can read it, we allocate some memory
> and copy the name there before returning a pointer to that memory.
> If there is a POST table, but its a format which has no names, or which
> we cannot deal with, then the code simply made a buffer, printed a
> dummy name into it, and returned that. The problem is that as soon as
> we return, the buffer we created on the stack goes out of scope leading
> to the valgrind error.
> It appears that in XPS (and PCL where this code originated) there is no
> mechanism like ht name table, and so even when we can find a name in the
> POST table, we allocate memory for it, and allow it to leak!!
> See the comment at around line 263 of xpsttf.c, and note that this is
> the same code as in pl_glyph_name() in plfont.c
> Since this memory leak already happens for the case where the POST
> table can be read, I've (reluctantly) chosen to do the same in the case
> where we simply invent a glyph (PCL doesn't do this). I'm not happy
> about it, and the owners of the relevant interpreters really ought to
> fix this properly IMO, or we should rewrite the 'copy_glyph' method
> from the fonts so that it owns the memory for the name, but this would
> be a huge undertaking.
> xps/xpsttf.c

2019-02-01 13:07:29 -0800
Michael Vrhel <michael.vrhel@artifex.com>
11338176d31567a5d63e49d6f91ccac7db706716

> Rename pdf14 parent_color_info_procs to parent_color_info
> As Ray pointed out, this structure has more than just procs in it.
> base/gdevp14.c
> base/gdevp14.h

2019-01-31 11:31:30 -0800
Ray Johnston <ray.johnston@artifex.com>
4ec9ca74bed49f2a82acb4bf430eae0d8b3b75c9

> Hide pdfdict and GS_PDF_ProcSet (internal stuff for the PDF interp).
> We now keep GS_PDF_ProcSet in pdfdict, and immediately bind pdfdict
> where needed so we can undef it after the last PDF interp file has
> run (pdf_sec.ps).
> Resource/Init/pdf_base.ps
> Resource/Init/pdf_draw.ps
> Resource/Init/pdf_font.ps
> Resource/Init/pdf_main.ps
> Resource/Init/pdf_ops.ps
> Resource/Init/pdf_sec.ps

2019-02-01 14:45:18 +0000
Ken Sharp <ken.sharp@artifex.com>
78b321cdcbc22df928f3af2772473435e4d0695a

> txtwrite - fix use of incorrect index for recording Widths
> When scanning multi-byte CIDFont text, we were using the text enumerator
> 'index' to store the widths of glyphs. However this is incorrect when
> the CIDFont uses multiple bytes; the index is the byte count into the
> input string, not the numebr of characters processed.
> Use TextBufferIndex instead, which is correctly updated to track the
> character index in the string, not the byte index.
> devices/vector/gdevtxtw.c

2019-01-31 19:14:49 +0000
Robin Watts <robin.watts@artifex.com>
52cbdabc0627bbeb918ffeb5f0fe15a6922a8322

> Bug 700306: Fix values returned by bbox device.
> The "any part of a pixel" code in the new scan converter holds a
> "cursor" position that determines where edges intersect with
> the scanlines. The leftmost and rightmost positions of intersection
> are held in this as values of type fixed.
> The "null" cursor position is represented by using maximal/minimal
> values. Unfortunately, I used {max,min}_int_in_fixed, rather than
> {max,min}_fixed, which meant they weren't nearly as maximal/minimal
> as they ought to have been.
> This meant that the logic for inserting the real left/right hand
> edges went wrong, and we output spurious positions into the
> edgebuffer table. This in turn caused larger spans to be filled
> to the underlying device than expected, hence upsetting the bbox.
> For all other devices, there was no problem because overly large
> or small values are clipped away.
> base/gxscanc.c

2019-01-30 15:09:45 -0800
Nancy Durgin <nancy.durgin@artifex.com>
e1f3eb6e848498a085fbec7333cbe2a22d7be318

> Undef .growfontdict
> - make it an operator
> - make sure all procedures that use it are executeonly
> - undef in gs_init.ps
> Resource/Init/gs_fonts.ps
> Resource/Init/gs_init.ps
> Resource/Init/gs_type1.ps

2019-01-30 14:49:10 -0800
Nancy Durgin <nancy.durgin@artifex.com>
052d8d2afc14b14efa46632f355ee24b273760f1

> Undef .fontnameproperties
> Used in a gs_fonts.ps and pdf_font.ps. Immediate evaluation and undef in
> gs_init.ps.
> Resource/Init/gs_fonts.ps
> Resource/Init/gs_init.ps
> Resource/Init/pdf_font.ps

2019-01-30 13:54:06 -0800
Nancy Durgin <nancy.durgin@artifex.com>
7b5031745ae7f00f9d6c653bf647330e1e1f5a9b

> Undef .findfontname
> Only used locally, so use immediate evaluation.
> Resource/Init/gs_fonts.ps

2019-01-30 13:40:45 -0800
Nancy Durgin <nancy.durgin@artifex.com>
64cc22e15f680418c539f0f1d286168bc6d1cf75

> Undef .definenativefontmap
> Only used locally, so use immediate evaluation.
> Resource/Init/gs_fonts.ps

2019-01-30 13:38:02 -0800
Nancy Durgin <nancy.durgin@artifex.com>
829a8c85112193116f39928568e8bf56138b7410

> Undef .definemodifiedfont
> This was a random procedure not actually used anywhere...
> Resource/Init/gs_fonts.ps

2019-01-30 12:14:52 -0800
Nancy Durgin <nancy.durgin@artifex.com>
865e68569b194992ab097006f2884c1dc1e83d05

> Undef .definefakefonts
> All the comments seem to say not to bind this one, but immediate evaluation
> should be fine.
> Undef in gs_init.ps after all uses.
> Resource/Init/gs_fonts.ps
> Resource/Init/gs_init.ps

2019-01-30 12:09:43 -0800
Nancy Durgin <nancy.durgin@artifex.com>
430e219ea17a2650577d70021399c4ead05869e0

> Undef .completefont
> - make it an operator
> - make sure all procedures that use it are executeonly
> - undef in gs_init.ps
> Resource/Init/gs_fonts.ps
> Resource/Init/gs_init.ps
> Resource/Init/gs_ttf.ps

2019-01-30 09:51:54 -0800
Nancy Durgin <nancy.durgin@artifex.com>
cdcb56ed5af686ab2e368587506f12ba071ff41e

> Undef .buildnativefontmap
> - make it an operator
> - make sure all procedures that use it are executeonly
> - undef in gs_init.ps
> Resource/Init/gs_fonts.ps
> Resource/Init/gs_init.ps
> Resource/Init/gs_res.ps

2019-01-30 09:40:25 -0800
Nancy Durgin <nancy.durgin@artifex.com>
fe316c21cb1c9a192da58158155a56f46f1f753a

> Undef .origdefinefont, .origundefinefont, .origfindfont
> I don't understand why these need to be defined (in gs_res.ps) but things
> break if they are not. So just undef them in gs_init.ps after all the
> initialization is complete.
> Resource/Init/gs_init.ps
> Resource/Init/gs_res.ps

2019-01-30 09:05:55 -0800
Nancy Durgin <nancy.durgin@artifex.com>
d68c6d816d5d584ce340f9d4c827279cc4321125

> Remove .glyphwidth implementation, since it isn't used anywhere
> Deleted C implementation.
> Made finish_stringwidth() static since it no longer needs to be exported
> to zglyphwidth().
> psi/ichar.h
> psi/zchar.c
> psi/zcharx.c

2019-01-30 08:14:58 -0800
Nancy Durgin <nancy.durgin@artifex.com>
d74962183f1929ebfab7db119d97ca0b82eb3816

> Undef .findfontop
> This needs to stay an operator (based on the comments), so have to undef it
> in gs_init.ps.
> Resource/Init/gs_init.ps

2019-01-29 21:05:41 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
412a279721c0f17d496147f3b87de873123a530e

> Bug 697545 : Prevent numerous memory leaks.
> Saving the desired_implmentation ensures that the correct cleanup routines are called.
> Error created using :-
> MEMENTO_FAILAT=1846 ./membin/gpcl6 -sDEVICE=pbmraw -dMaxBitmap=2000 -o /dev/null ./tests_private/pcl/pcl5cfts/fts.0270
> pcl/pl/plmain.c

2019-01-30 09:30:37 -0800
Michael Vrhel <michael.vrhel@artifex.com>
9bf4dddd99987b45375972ee95d061cc7d3d393f

> Bug 696600: psdcmykog device_procs
> My earlier fix caused massive problems with any transparency files.
> This should fix all the issues.
> devices/gdevcmykog.c

2019-01-29 11:50:21 -0800
Ray Johnston <ray.johnston@artifex.com>
f075b380de5c2826055d092f2e4616ed6da89e87

> Fix debug message 'v' output num_components_new with spot colors.
> The debug message was before the new_num_components was adjusted for
> num_spots.
> base/gdevp14.c

2019-01-28 09:58:51 -0800
Ray Johnston <ray.johnston@artifex.com>
0dcbfa4a999fcfe154c313e1a63855b7c0355a8e

> Bug 700493: Search parent Resources, if not found in Local or Page
> The spec mentions that the Page Resources are inherited by a Form
> Xobject (not recommended), but Adobe and mupdf find, and use, the
> Resource definition in a parent (ancestor) Xobject. Recursively
> search the parent Resources ONLY if it isn't found in the Form's
> Resources or the Page Resources (which may include Resources of
> ancestors of the Page).
> Resource/Init/pdf_base.ps
> Resource/Init/pdf_main.ps

2019-01-28 10:09:10 -0800
Ray Johnston <ray.johnston@artifex.com>
647992061fc815d29982ecbc1ad76e3e86cc714f

> Fix Bug 694190 for cmykspot and custom put_image functions (fix SEGV)
> When we get an error in the PDF interpreter, we can end up in the put_image
> function. This check belongs in the two other pdf14 put_image functions.
> base/gdevp14.c

2019-01-18 09:33:45 -0800
Ray Johnston <ray.johnston@artifex.com>
0530328c8d16e69557f8bdeafcd40d8a75f5e994

> Fix SEGV found with broken PDF interpreter and Bug690770.pdf
> Found accidentally when I was working on a PDF interpreter change, when
> closing the pdf14 device, the smaskcolor->ref_count was decremented, but
> that object had already been freed (stale pointer). The free was by a
> "restore", so the smaskcolor needs to be in stable_memory so that it
> will be protected from the restore. Similarly for the "profiles" of that
> structure (and free both with stable_memory).
> base/gdevp14.c

2019-01-29 08:31:06 -0800
Nancy Durgin <nancy.durgin@artifex.com>
13faebdf8817a99e1476736687ca2d75c002fb25

> Fixed some issues with htmldiff.pl
> 1) I am using pngize=0. My version of bmpcmp automatically outputs in
> png format. I think this reveals a bug related to file suffixes?
> Anyway, I added an "outsuffix" variable and at least for my situation,
> it now works. I don't know if this is a general fix or not.
> 2) The metafile string was built with $imstr, which isn't a defined
> variable? Changed this to be $imstr1. How did this ever work?
> toolbin/htmldiff.pl

2019-01-29 14:31:03 +0000
Robin Watts <robin.watts@artifex.com>
7c8f63f6765254367cb85e3bd0f3b9b1388237c7

> Bug 693814: Fix valgrind error in pdf_image_plane_data_alt.
> Valgrind is not smart enough to realise that <undefined_value> * 0 =
> defined 0.
> Thus, initialise raster to 0.
> This makes the following command run without warnings:
> valgrind --track-origins=yes bin/gs -sOutputFile=out.pdf
> -dMaxBitmap=400000000 -sDEVICE=pdfwrite -r300 -Z:
> -dNOPAUSE -dBATCH -K2000000 -dClusterJob
> /home/marcos/cluster/tests_private/comparefiles/Bug692226.ps
> base/gximage3.c

2019-01-29 12:51:09 +0000
Robin Watts <robin.watts@artifex.com>
14ccdd48a3ba6f546e024a21c3837dc258d1f79d

> Bug 700512: Fix error from image_render_icc16.
> If we render a skewed image using image_render_icc16, and the first
> two pixels on the line have identical source values, the current
> code would forget to do the color mapping. This would result in
> a "Fatal" error coming back from the underlying pixel plot routine
> which causes the whole program to exit.
> The fix is simply to insist that the first pixel on a row must
> always be mapped.
> base/gxi12bit.c

2019-01-28 15:07:07 -0800
Robin Watts <Robin.Watts@artifex.com>
7eff21255ed7b053bb78e7654793c63943b10a01

> Avoid valgrind problems with copy_landscape.
> The copy_landscape routine uses memflip8x8 to transpose 8 lines
> of data to be 8 columns of data.
> At the end of the line, unless the width is a multiple of 8, we
> therefore end up accessing uninitialised data. This trips
> valgrind.
> We therefore introduce a special case variant for the end of the
> line, where we mask off the undefined bits.
> This can be seen by doing:
> make vg
> bin/gs -sOutputFile=test.ps -dMaxBitmap=400000000 -sDEVICE=ps2write
> -r300 -Z: -dNOPAUSE -dBATCH -K2000000 -dClusterJob
> /home/marcos/cluster/tests_private/comparefiles/Bug691740.pdf
> valgrind --track-origins=yes bin/gs -sOutputFile=/dev/null
> -dMaxBitmap=400000000 -sDEVICE=pkmraw -r300 -Z: -dNOPAUSE
> -dBATCH -K2000000 -dClusterJob test.ps
> base/gsutil.c
> base/gsutil.h
> base/gxifast.c

2019-01-28 09:43:17 -0800
Robin Watts <Robin.Watts@artifex.com>
c79f5245d24398b6f024e5e8611882a10b2799b0

> Fix strange valgrind problem; compiler error?
> On peeves, the following commands produce valgrind warnings:
> make vg
> bin/gs -sOutputFile=out.ps -dMaxBitmap=400000000 -sDEVICE=ps2write
> -r300 -Z: -dNOPAUSE -dBATCH -K2000000 -dClusterJob
> /home/marcos/cluster/tests_private/comparefiles/Bug691112.pdf
> valgrind --track-origins=yes bin/gs -sOutputFile=/dev/null
> -dMaxBitmap=400000000 -sDEVICE=ppmraw -r300 -Z: -dNOPAUSE
> -dBATCH -K2000000 -dClusterJob out.ps
> Debugging shows that the "run_len" member of the RLE stream state
> is not being initialised. As far as I can tell, it really out to
> be.
> Changing the code to use the (neater, IMHO) mechanism of initing
> the stream state by calling the template init function seems to
> solve this. I cannot for the life of me see why this should make
> a difference, but this is a better way to work in any case.
> base/gxclutil.c

2019-01-28 20:21:24 -0800
Michael Vrhel <michael.vrhel@artifex.com>
659cb78748c9f4bb4e5f45a1c07872176fba7e57

> Bug 696600: psdcmykog device issues
> The psdcmykog device is a DeviceN color based device but unlike psdcmyk and
> tiffsep it can't change its color characteristics. It remains as
> a 6 color cmykog device. Postsript files can change the maxseparations
> (example 29-07E.PS) The gdevdevn code will, if it
> detects a change occured, close the device and reopen (see
> devn_printer_put_params) possibly resetting the color info. tiffsep
> and psdcmyk, when reopened, will reset their color characteristics based upon
> the content of the page, avoiding any issues upon the reopen. Here we
> will need to make sure to set the color information to avoid problems.
> devices/gdevcmykog.c

2019-01-27 17:40:25 -0700
Henry Stiles <henry.stiles@artifex.com>
7c3c69932c9b12526a54830cca745ceb21aebdec

> Bug 700492 - xl readImage IllegalAttributeValue.
> Support switching compression schemes within a single image. We now
> allow switching between lossless modes (uncompressed, rle and
> delta-row) but do not allow changing to jpeg compression.
> Interleaving lossy and lossless compression within a single image is
> not expected in practice.
> pcl/pxl/pximage.c

2019-01-28 10:45:58 -0800
Michael Vrhel <michael.vrhel@artifex.com>
6476023744d256b12ea11bff3e121104df99f426

> Bug 695046: icc profile not found
> When the code is compiled without compile inits the icc profiles
> associated with enumerated color spaces in jpx images could not
> be found.
> base/gsicc_manage.c
> base/gsicc_manage.h

2019-01-28 14:16:35 +0000
Robin Watts <robin.watts@artifex.com>
c52f058c6d5c912d9d9da609929b4cd306e2760e

> pdfwrite: Avoid valgrind errors when comparing image lines.
> Within pdf_dump_converted_image we compare scanlines of image data
> to the next one. Unfortunately, if scanlines aren't an exact number
> of bytes wide, we have uninitialised bits at the end, which can a)
> cause spurious mismatches, and b) cause valgrind errors, such as
> seen with the following:
> make vg
> valgrind --track-origins=yes bin/gs -sOutputFile=out.ps
> -dMaxBitmap=400000000 -sDEVICE=ps2write -r300 -Z: -dNOPAUSE
> -dBATCH -K2000000 -dClusterJob
> /home/marcos/cluster/tests_private/comparefiles/Bug690237.pdf
> Here we simply use a modified line comparison routine to test
> the exact set of bits required.
> devices/vector/gdevpdfd.c

2019-01-22 09:37:43 +0000
Robin Watts <robin.watts@artifex.com>
b092266152f2c43f7f5bb195bf9ef37afa46996b

> Fix buffer overread in cmd_compress_bitmap.
> The following commands:
> make debugvg
> debugbin/gs -sOutputFile=/dev/null -dMaxBitmap=400000000 -sDEVICE=ppmraw
> -r300 -Z: -dNOPAUSE -dBATCH -K2000000 -dClusterJob out2.ps
> cause a read of uninitialised data in cmd_compress_bitmap.
> Painstaking debugging shows that the problem is due to an overread
> at the end of a bitmap line.
> cmd_put_bits is called with 408 bits of bitmap data. This passes the
> details into clist_bitmap_bytes, and is told that uncompressed_raster
> should be 448 bits.
> It then passes this side into cmd_compress_bitmap, which causes the
> buffer overread.
> The interesting point is that this call is:
> status = cmd_compress_bitmap((stream_state *) & sstate, data,
> uncompressed_raster << 3 /*width_bits */ ,
> raster, height, &w);
> which suggests that at some point in the past we were passing the
> correct value of width_bits in, and we then changed to passing
> the wrong width in.
> Sadly, there is no hint in the commit record as to WHY this changed.
> This line dates back to the earliest commit we have in source control
> in 1998, so it looks like it hasn't changed for a while.
> This is only the first part of the problem, though; once in
> cmd_compress_bitmap, the value is fed into bitmap_raster() which again
> rounds it up so it reads off the end of the defined data.
> We therefore rework cmd_compress_bitmap. We specifically only compress
> the actual bits of data that we have, and ensure that any padding bits
> (or bytes) are correctly sent as constant zeros.
> As well as assugaging valgrind, and preventing potential genuine
> (if unlikely) buffer overreads, this ensures that we should get
> repeatable results on each successive run.
> base/gxclbits.c

2019-01-23 16:13:17 +0000
Robin Watts <robin.watts@artifex.com>
f78601f3d8df7ed16550d834cbf2c440804a6f41

> Rework RunLengthEncoder.
> The existing RunLengthEncoder relies on being able to read ahead
> a few bytes, and then decide that it wants to ask the caller for
> more data.
> Unfortunately, this means that the clist cmd_compress_bitmap routine
> can only call it in the "here is all the data in a solid block" case,
> not in the "here is the data a line at a time" case.
> This will become even more of a limitation when I rework
> cmd_compress_bitmap to avoid overrun reads in a future commit.
> The primary difference here is that we never backtrack on our reads
> within the compression routine. We keep the last 1, 2 or 3 bytes
> read in the state as n0, n1 and n2, and we insert literal bytes into a
> array within the state for copying out later.
> Because we now allow cmd_compress_bitmap to run in cases when it
> didn't before, we trip over a bug in there. If height > 0 and
> raster < width_bytes (for instance when raster = 0, so we can repeat
> the same line several times), on 64bit builds the pointer
> arithmetic goes wrong, and we end up accessing illegal memory.
> Fix with a simple cast to int.
> base/gxclbits.c
> base/srle.c
> base/srlx.h

2019-01-28 09:37:36 +0000
Ken Sharp <ken.sharp@artifex.com>
290ad1e4321ee46d34e7f6fdc6936e909092f7d5

> txtwrite - forcibly disable interpolation
> Bug #700525 "/unknownerror in --imagemask-- on txtwrite device"
> If we have interpolation on, and we get an imagemask, then the rendering
> code tries to use get_bits() to perform the interpolation. This
> obviously doesn't work with a non-rendering device.
> The simplest solution is to disable interpolation, which isn't in any
> even useful on a non-rendering device.
> devices/vector/gdevtxtw.c

2019-01-17 15:11:56 -0800
Nancy Durgin <nancy.durgin@artifex.com>
946025aa4219d2a386ff0ca5b48e7be71d86b81f

> Undef/hide internal operators in gs_typ42.ps
> Undef internal .type42build, only used locally.
> Make %Type42BuildChar and %Type42BuidlGlyph executeonly to properly hide
> .type42execchar.
> Resource/Init/gs_typ42.ps

2019-01-17 14:28:28 -0800
Nancy Durgin <nancy.durgin@artifex.com>
9be4230804851ee1cba0aebc97e98f12bc885593

> Undef/hide internal operators from gs_type1.ps
> /.loadfont1 -- used locally, rearranged code so def is before use
> /.type1build -- end of file has some optional code (it may skip to EOF),
> so I just undef'd it in gs_init.ps
> Made %Type1BuildChar, %Type1BuildGlyph, %Type2BuildChar, %Type2BuildGlyph
> executeonly to properly hide .type1execchar and .type2execchar.
> Resource/Init/gs_init.ps
> Resource/Init/gs_type1.ps

2019-01-17 12:18:26 -0800
Nancy Durgin <nancy.durgin@artifex.com>
e6feb75ec94d7102440a2b86ce16841b3e3023af

> Undef/hide internal operators in gs_cidfn.ps
> /.checkfonttype
> /.loadcidfontresource
> /.readglyphdata
> Make %Type9BuildGlyph and %Type11BuildGlyph funcs executeonly to
> properly hide the '.type*execchar' operators that they call.
> Resource/Init/gs_cidfn.ps

2019-01-17 09:31:17 -0800
Nancy Durgin <nancy.durgin@artifex.com>
95ac05d50f5af5f81f0ab2e0e0731a65ad59085e

> undef .composefontdict from gs_cmap.ps
> Resource/Init/gs_cmap.ps
> Resource/Init/gs_init.ps

2019-01-16 12:55:22 -0800
Nancy Durgin <nancy.durgin@artifex.com>
2905c901244a3c105560a48ae3047196961920d7

> Undef internal operators from gs_cff.ps
> - rearranged some code in gs_cff.ps to have things defined before used
> - /.init_wOFF_otto_font_file is only used locally, undef right after use
> - /.init_otto_font_file is used by pdf_fonts.ps, undef in gs_init.ps
> /.init_otto_font_file was being defined after it was used, because
> gs_cff.ps was run after pdf_fonts.ps. Need to define before using, in
> order to be able to undef, so had to change psi/int.mak to load
> gs_cff.ps before pdf_fonts.ps. Also moved around the cff.dev dependencies
> accordingly.
> NOTE: To see what order the files will be loaded, you can look at
> obj/iconfig.h which is generated by the makefile magic. You can also
> look at the INITFILES array in gs_init.ps, which the stuff in
> iconfig.h eventually generates.
> Resource/Init/gs_cff.ps
> Resource/Init/gs_init.ps
> psi/int.mak

2019-01-23 12:00:30 -0800
Nancy Durgin <nancy.durgin@artifex.com>
e7ff64cf9b756278f19c87d295ee0fd95c955c05

> Fixed bug caused by the way .checksetparams was undef'd
> Previously, had undef'd it by making it an operator.
> Now just use an immediate reference and undef it in the gs_lev2.ps file.
> This fixes bug introduced in commit fe4c47d8e25d6366ecbb5ff487348148b908a89e.
> Undef'ing .checksetparams by making it an operator doesn't work right because
> errors report .checksetparams as the offending function instead of
> the operator that uses it (setsystemparams in this case).
> This caused an error in file /tests_private/ps/ps3cet/27-09.PS on page 3,
> where it reports the offending function of some error-handling tests.
> Reporting function should be 'setsystemparams', not '.checksetparams' on
> this page.
> Resource/Init/gs_init.ps
> Resource/Init/gs_lev2.ps

2019-01-24 15:33:37 +0000
Ken Sharp <ken.sharp@artifex.com>
e51c447b690c233b6299e68f9c031a32c61cc263

> pdfwrite - detecting duplicate images, check for pending masks
> Bug #700495 "gs/gpdl difference with pdfwrite"
> This exhibits with gpdl but not gs because, for some unknown reason, the
> MD5 sums from gpdl differ in a few cases from those returned by GS,
> I have no idea why.
> But that's not the problem, so I'm ignoring it for now.
> The real problem is that when we have an image which has an associated
> Mask or SMask, when checking to see if it is a duplicate of a prior
> image, we were not checking to see if the prior image also had a Mask
> or SMask (as appropriate) which could lead to us emitting an image
> with a missing mask.
> We cater for that now in smask_image_check. Also not strictly part of
> this problem, when we did add a Mask or SMask to a stream cos object, we
> didn't invalidate its MD5, which could mean it would match a later image
> when it should not. So set the md5_valid flag to 0 when we add a mask
> entry to the cos object.
> On the cluster this show progressions with two files, image-qa.ps and
> 692217.pdf (drop shadows were previously missing)
> Note that the previous output for image-qa.ps was incorrect with both
> gs *and* gpdl.
> devices/vector/gdevpdfi.c
> devices/vector/gdevpdfj.c

2019-01-24 08:45:51 +0000
Chris Liddell <chris.liddell@artifex.com>
3c952a9bde27766af4832435e62fcb659df1ee1f

> Bug 700500: Check Type 3 fonts for transparency
> The transparency checking code didn't check Type 3 font resources for
> transparency settings, thus we could miss those, and fail to push the
> compositor device.
> Resource/Init/pdf_base.ps
> Resource/Init/pdf_main.ps

2019-01-23 18:59:19 -0800
Michael Vrhel <michael.vrhel@artifex.com>
f5cb0ef75fc11bb65a63a1af35ee2edc94656bb4

> Bug 693787 Valgrind issue
> An error code was not returned when it was encountered
> leading to the use of uninitialized values.
> base/gxshade4.c

2019-01-23 11:52:19 -0800
Michael Vrhel <michael.vrhel@artifex.com>
aad16609bbc3476c56fa8ab8b52b64c1653594d4

> Bug 693816 Valgrind issue
> During CMYK color space install unset the device color
> to ensure that any of the overprint checking is not
> invoked with unknown values.
> psi/zcolor.c

2019-01-22 13:34:32 -0800
Michael Vrhel <michael.vrhel@artifex.com>
4cf03307489c9c27da77607821598ded1aa14e73

> Bug 694243 Valgrind issue
> During the creation of the transparency buffer information we were
> exiting if the width or height were zero. We needed to fill in
> a few more items (like the width and the height) before doing so
> as they are tested elsewhere.
> base/gdevp14.c

2019-01-11 13:36:36 +0000
Chris Liddell <chris.liddell@artifex.com>
49c8092da88ef6bb0aa281fe294ae0925a44b5b9

> Remove .forcedef, and harden .force* ops more
> Remove .forcedef and replace all uses with a direct call to .forceput instead.
> Ensure every procedure (named and trasient) that calls .forceput is
> executeonly.
> Resource/Init/gs_dps1.ps
> Resource/Init/gs_init.ps
> Resource/Init/gs_lev2.ps
> Resource/Init/gs_ll3.ps
> Resource/Init/gs_res.ps
> Resource/Init/gs_statd.ps

2019-01-09 14:24:07 +0000
Chris Liddell <chris.liddell@artifex.com>
2768d1a6dddb83f5c061207a7ed2813999c1b5c9

> Undefine a bunch of gs_fonts.ps specific procs
> Also reorder and add some immediate evaluation, so it still works with the
> undefining.
> Resource/Init/gs_dps1.ps
> Resource/Init/gs_fonts.ps
> Resource/Init/gs_res.ps

2018-12-18 10:42:10 +0000
Chris Liddell <chris.liddell@artifex.com>
59d8f4deef90c1598ff50616519d5576756b4495

> Harden some uses of .force* operators
> by adding a few immediate evalutions
> Resource/Init/gs_dps1.ps
> Resource/Init/gs_fonts.ps
> Resource/Init/gs_init.ps

2018-12-15 09:08:32 +0000
Chris Liddell <chris.liddell@artifex.com>
99f13091a3f309bdc95d275ea9fec10bb9f42d9a

> Bug700317: Fix logic for an older change
> Unlike almost every other function in gs, dict_find_string() returns 1 on
> success 0 or <0 on failure. The logic for this case was wrong.
> psi/interp.c

2018-12-13 15:28:34 +0000
Chris Liddell <chris.liddell@artifex.com>
2db98f9c66135601efb103d8db7d020a672308db

> Any transient procedures that call .force* operators
> (i.e. for conditionals or loops) make them executeonly.
> Resource/Init/gs_diskn.ps
> Resource/Init/gs_dps1.ps
> Resource/Init/gs_fntem.ps
> Resource/Init/gs_fonts.ps
> Resource/Init/gs_init.ps
> Resource/Init/gs_lev2.ps
> Resource/Init/gs_pdfwr.ps
> Resource/Init/gs_res.ps
> Resource/Init/gs_setpd.ps
> Resource/Init/pdf_base.ps
> Resource/Init/pdf_draw.ps
> Resource/Init/pdf_font.ps
> Resource/Init/pdf_main.ps
> Resource/Init/pdf_ops.ps

2018-12-05 12:22:13 +0000
Chris Liddell <chris.liddell@artifex.com>
13b0a36f8181db66a91bcc8cea139998b53a8996

> Sanitize op stack for error conditions
> We save the stacks to an array and store the array for the error handler to
> access.
> For SAFER, we traverse the array, and deep copy any op arrays (procedures). As
> we make these copies, we check for operators that do *not* exist in systemdict,
> when we find one, we replace the operator with a name object (of the form
> "/--opname--").
> psi/int.mak
> psi/interp.c
> psi/istack.c
> psi/istack.h

2019-01-23 11:45:16 +0000
Ken Sharp <ken.sharp@artifex.com>
c47512e5e638d903d69925f7ebab4de2aa3f481f

> pdfwrite - sort out a type confusion
> Bug #700490 "gs_text_enum_t used as pdf_text_enum_t"
> There seems to have been 2 sources of confusion here; this falls into
> the 'how did this ever work' category.
> The problem only occurs when we are forced to go to a bitmap font, which
> for PostScript and PDF input is very rare, but for PCL there are several
> font types we cannot support and so we must make bitmapped fonts for
> them.
> We use a pointer in the pdfwrite device structure to store a pointer to
> the text enumerator, but we store the *wrong* enumerator. We store
> pte_default, which is the enumerator we just created for the standard
> test processing. We don't need to store that one, its available as the
> argument to all the procedures. What we need access to is the original
> text enumerator, the pdfwrite one, and its that one we should be storing
> in the device structure.
> There was similar confusion in pdf_text_set_cache, which set penum to
> 'pte' casting it to a pdf_text_enum * in the process. This is clearly
> wrong in the case of making a bitmap font, because we made a standard
> text enumerator and passed that in, so 'pte' won't be a pdf text
> enumerator.
> Now it is possible to exercise a different code path and arrive at
> pdf_text_set_cache with a pdf_text_enumerator. There is no other way
> to arrive here.
> So we check pdev->pte (where we would have stored the original pdf
> text enumerator) and if its not NULL we use it as a pdf text enumerator.
> If it is NULL, then we believe the enumerator pte should he a pdf
> text enumerator and cast it as such. Also add a check to ensure that
> the enumerator from the arguments *is* a pdf_text enumerator to avoid
> this confusion in future.
> Finally, clean up a couple of minor compiler warnings in passing.
> devices/vector/gdevpdtt.c

2019-01-22 17:31:33 +0000
Robin Watts <robin.watts@artifex.com>
79589242c72d432f06c7a5f545989362564ab57e

> Add a couple of helpful perl scripts for valgrind testing.
> vdb.pl automates the running of valgrind jobs under gdb, and
> multiplexes the output from valgrind and gdb together.
> vgbatch.pl automates the running of a list of "cluster like"
> tests under valgrind.
> toolbin/vdb.pl
> toolbin/vgbatch.pl

2019-01-21 16:57:10 +0000
Robin Watts <robin.watts@artifex.com>
882343089e6c9ec2a4ce574cd7198281706b2f21

> Fix valgrind problem in pdfwrite.
> The following command:
> gs -sOutputFile=out2.ps -dMaxBitmap=400000000 -sDEVICE=ps2write -r72
> -Z: -dNOPAUSE -dBATCH -K2000000 -dClusterJob
> /home/marcos/cluster/tests_private/comparefiles/Bug690837.pdf
> shows problems where we call dash_pattern_eq on uninitialised data.
> It looks very much to me like pdf_load_viewer_state fails to copy
> the dash data, despite allocating space for it. We fix that here.
> Also, we never check whether the allocation fails or not. Add some
> error checking.
> devices/vector/gdevpdfg.c

2019-01-19 12:45:45 +0000
Robin Watts <robin.watts@artifex.com>
f612df16597bbae73707d0dc9a90235b3de26c6e

> Preemptively fix more potential valgrind problems.
> Again, while we know that a+b = a|b when (a&b)==0 (ignoring
> overflow), valgrind is not that smart, and can hence incorrectly
> get undefinedness calculations wrong.
> Fix cases in gdevm2 that look wrong, in the same way as the
> previous commit fixed gdevm1.
> base/gdevm2.c

2019-01-19 04:32:18 -0800
Robin Watts <Robin.Watts@artifex.com>
d1a355ecf8adfce6758638aa79bc9f5338fc1e64

> Bug 693784: Tweak copy_mono code for valgrind.
> We are smart enough to know that doing a+b is the same as
> doing a|b when (a&b)=0 (ignoring overflow). Valgrind is not.
> Accordingly our "bit fetching and skewing" code, when run
> under valgrind can introduce spurious "undefined" status
> to bits when it should not.
> The fix is just to use | when we really mean |.
> This makes:
> debugbin/gs -sOutputFile=out.pkm -dMaxBitmap=400000000
> -sDEVICE=pkmraw -r300 -sDEFAULTPAPERSIZE=letter
> -dNOPAUSE -dBATCH -K1000000 -dClusterJob -dJOBSERVER
> tests/Ghent_V3.0/010_CMYK_OP_x3.pdf
> run to completion with no valgrind warnings.
> base/gdevm1.c

2019-01-17 14:27:07 +0000
Robin Watts <robin.watts@artifex.com>
8176af6bdcf8c9d3e80862965d02ed4e71b02236

> Bug 693747: Fix valgrind problem.
> In the image scaling code, we use interpolate_scaled_expanded_height
> to calculate a value that will only be used if abs_interp_limit > 1.
> The setup code only bothers to initialise the values used for this
> calculation if abs_interp_limit > 1, hence valgrind complains that
> this is using undefined values.
> The simple fix is to only calculate the values if they might be
> used.
> base/gxiscale.c

2019-01-16 17:56:39 +0000
Robin Watts <robin.watts@artifex.com>
1d0582d65fcb8760628c80a25cd0ff6a0d2db65b

> GPDL: Tweak PS device init for subclassing.
> Subclassing doesn't work with gpdl. For example:
> gpdl -sDEVICE=pdfwrite -o out.pdf -dFirstPage=3 lib/image-qa.ps
> The device is correctly subclassed on an open, but then we use
> zcurrentoutputdevice to find the device for us to setdevice it.
> This finds the childmost (i.e. pdfwrite) device, rather than
> first_lastpage.
> Here, we use zcurrentdevice instead.
> psi/imain.c

2019-01-16 15:34:53 +0000
Robin Watts <robin.watts@artifex.com>
6cee9657ff63ed555e6092f7eded544189d078d5

> Valgrind: tweak sample_unpack functions to avoid false positive UMRs.
> The "sample_unpack" template functions rely on unpacking whole
> bytes at a time. Sometimes, the ends of these buffers of bytes
> may have bits that are (intentionally, and permissibly) undefined.
> Update the code so that in PACIFY_VALGRIND builds we cope with
> these undefined bits, and carry the undefinedness over into the
> output.
> base/gxsamplp.h

2019-01-16 15:10:56 +0000
Chris Liddell <chris.liddell@artifex.com>
4cf2ad7ad15bd52472a342c979bdd48315c43155

> Update source/header file copyright notice to 2019
> Makefile.in
> Resource/CIDFont/ArtifexBullet
> Resource/ColorSpace/DefaultCMYK
> Resource/ColorSpace/DefaultGray
> Resource/ColorSpace/DefaultRGB
> Resource/ColorSpace/TrivialCMYK
> Resource/ColorSpace/sGray
> Resource/ColorSpace/sRGB
> Resource/Decoding/FCO_Dingbats
> Resource/Decoding/FCO_Symbol
> Resource/Decoding/FCO_Unicode
> Resource/Decoding/FCO_Wingdings
> Resource/Decoding/Latin1
> Resource/Decoding/StandardEncoding
> Resource/Decoding/Unicode
> Resource/Encoding/CEEncoding
> Resource/Encoding/ExpertEncoding
> Resource/Encoding/ExpertSubsetEncoding
> Resource/Encoding/NotDefEncoding
> Resource/Encoding/Wingdings
> Resource/Init/FCOfontmap-PCLPS2
> Resource/Init/Fontmap.GS
> Resource/Init/gs_agl.ps
> Resource/Init/gs_btokn.ps
> Resource/Init/gs_cff.ps
> Resource/Init/gs_cidcm.ps
> Resource/Init/gs_ciddc.ps
> Resource/Init/gs_cidfm.ps
> Resource/Init/gs_cidfn.ps
> Resource/Init/gs_cidtt.ps
> Resource/Init/gs_cmap.ps
> Resource/Init/gs_cspace.ps
> Resource/Init/gs_dbt_e.ps
> Resource/Init/gs_diskn.ps
> Resource/Init/gs_dps1.ps
> Resource/Init/gs_dps2.ps
> Resource/Init/gs_dscp.ps
> Resource/Init/gs_epsf.ps
> Resource/Init/gs_fapi.ps
> Resource/Init/gs_fntem.ps
> Resource/Init/gs_fonts.ps
> Resource/Init/gs_frsd.ps
> Resource/Init/gs_icc.ps
> Resource/Init/gs_il1_e.ps
> Resource/Init/gs_init.ps
> Resource/Init/gs_lev2.ps
> Resource/Init/gs_ll3.ps
> Resource/Init/gs_mex_e.ps
> Resource/Init/gs_mgl_e.ps
> Resource/Init/gs_mro_e.ps
> Resource/Init/gs_pdf_e.ps
> Resource/Init/gs_pdfwr.ps
> Resource/Init/gs_res.ps
> Resource/Init/gs_resmp.ps
> Resource/Init/gs_setpd.ps
> Resource/Init/gs_statd.ps
> Resource/Init/gs_std_e.ps
> Resource/Init/gs_sym_e.ps
> Resource/Init/gs_trap.ps
> Resource/Init/gs_ttf.ps
> Resource/Init/gs_typ32.ps
> Resource/Init/gs_typ42.ps
> Resource/Init/gs_type1.ps
> Resource/Init/gs_wan_e.ps
> Resource/Init/pdf_base.ps
> Resource/Init/pdf_draw.ps
> Resource/Init/pdf_font.ps
> Resource/Init/pdf_main.ps
> Resource/Init/pdf_ops.ps
> Resource/Init/pdf_rbld.ps
> Resource/Init/pdf_sec.ps
> Resource/SubstCID/CNS1-WMode
> Resource/SubstCID/GB1-WMode
> Resource/SubstCID/Japan1-WMode
> Resource/SubstCID/Korea1-WMode
> arch/arch_autoconf.h.in
> arch/windows-arm-msvc.h
> arch/windows-x64-msvc.h
> arch/windows-x86-msvc.h
> base/all-arch.mak
> base/assert_.h
> base/bench.c
> base/claptrap-impl.h
> base/claptrap.h
> base/ctype_.h
> base/dirent_.h
> base/dos_.h
> base/echogs.c
> base/errno_.h
> base/ets.h
> base/ets_tm.h
> base/expat.mak
> base/fapi_bs.mak
> base/fapi_ft.c
> base/fapibstm.c
> base/fapiufst.c
> base/fcntl_.h
> base/freetype.mak
> base/gconf.c
> base/gconf.h
> base/gdbflags.h
> base/gdebug.h
> base/gdevabuf.c
> base/gdevbbox.c
> base/gdevbbox.h
> base/gdevdbit.c
> base/gdevdcrd.c
> base/gdevdcrd.h
> base/gdevddrw.c
> base/gdevddrw.h
> base/gdevdevn.c
> base/gdevdevn.h
> base/gdevdevnprn.h
> base/gdevdflt.c
> base/gdevdgbr.c
> base/gdevdrop.c
> base/gdevdsha.c
> base/gdevemap.c
> base/gdevepo.c
> base/gdevepo.h
> base/gdevflp.c
> base/gdevflp.h
> base/gdevhit.c
> base/gdevkrnlsclass.c
> base/gdevkrnlsclass.h
> base/gdevm1.c
> base/gdevm16.c
> base/gdevm2.c
> base/gdevm24.c
> base/gdevm32.c
> base/gdevm4.c
> base/gdevm40.c
> base/gdevm48.c
> base/gdevm56.c
> base/gdevm64.c
> base/gdevm8.c
> base/gdevmem.c
> base/gdevmem.h
> base/gdevmpla.c
> base/gdevmpla.h
> base/gdevmplt.c
> base/gdevmplt.h
> base/gdevmr1.c
> base/gdevmr2n.c
> base/gdevmr8n.c
> base/gdevmrop.h
> base/gdevmrun.c
> base/gdevmrun.h
> base/gdevmx.c
> base/gdevnfwd.c
> base/gdevoflt.c
> base/gdevoflt.h
> base/gdevp14.c
> base/gdevp14.h
> base/gdevpccm.c
> base/gdevpccm.h
> base/gdevpipe.c
> base/gdevplnx.c
> base/gdevplnx.h
> base/gdevppla.c
> base/gdevppla.h
> base/gdevprn.c
> base/gdevprn.h
> base/gdevpxat.h
> base/gdevpxen.h
> base/gdevpxop.h
> base/gdevrops.c
> base/gdevsclass.c
> base/gdevsclass.h
> base/gdevvec.c
> base/gdevvec.h
> base/gen_ordered.c
> base/gen_ordered.h
> base/genarch.c
> base/genconf.c
> base/gendev.c
> base/genht.c
> base/gp.h
> base/gp_dosfe.c
> base/gp_dosfs.c
> base/gp_dvx.c
> base/gp_getnv.c
> base/gp_mktmp.c
> base/gp_msdll.c
> base/gp_msdos.c
> base/gp_mshdl.c
> base/gp_mslib.c
> base/gp_mspol.c
> base/gp_msprn.c
> base/gp_mswin.c
> base/gp_mswin.h
> base/gp_nsync.c
> base/gp_ntfs.c
> base/gp_nxpsprn.c
> base/gp_os2.c
> base/gp_os2.h
> base/gp_os2fs.c
> base/gp_os2pr.c
> base/gp_os9.c
> base/gp_paper.c
> base/gp_psync.c
> base/gp_stdia.c
> base/gp_stdin.c
> base/gp_strdl.c
> base/gp_unifn.c
> base/gp_unifs.c
> base/gp_unix.c
> base/gp_upapr.c
> base/gp_vms.c
> base/gp_wgetv.c
> base/gp_win32.c
> base/gp_wpapr.c
> base/gp_wsync.c
> base/gp_wutf8.c
> base/gp_wxpsprn.cpp
> base/gpcheck.h
> base/gpgetenv.h
> base/gpmisc.c
> base/gpmisc.h
> base/gpsync.h
> base/gs.mak
> base/gs_dll_call.h
> base/gs_mgl_e.h
> base/gs_mro_e.h
> base/gsalloc.c
> base/gsalloc.h
> base/gsalpha.c
> base/gsalpha.h
> base/gsalphac.c
> base/gsalphac.h
> base/gsargs.c
> base/gsargs.h
> base/gsbitcom.c
> base/gsbitmap.h
> base/gsbitops.c
> base/gsbitops.h
> base/gsbittab.c
> base/gsbittab.h
> base/gsccode.h
> base/gsccolor.h
> base/gscdef.c
> base/gscdefs.h
> base/gscdevn.c
> base/gscdevn.h
> base/gscedata.c
> base/gscedata.h
> base/gscencs.c
> base/gscencs.h
> base/gschar.c
> base/gschar.h
> base/gschar0.c
> base/gscicach.c
> base/gscicach.h
> base/gscie.c
> base/gscie.h
> base/gsciemap.c
> base/gscindex.h
> base/gsclipsr.c
> base/gsclipsr.h
> base/gscms.h
> base/gscolor.c
> base/gscolor.h
> base/gscolor1.c
> base/gscolor1.h
> base/gscolor2.c
> base/gscolor2.h
> base/gscolor3.c
> base/gscolor3.h
> base/gscompt.h
> base/gscoord.c
> base/gscoord.h
> base/gscparam.c
> base/gscpixel.c
> base/gscpixel.h
> base/gscpm.h
> base/gscrd.c
> base/gscrd.h
> base/gscrdp.c
> base/gscrdp.h
> base/gscrypt1.c
> base/gscrypt1.h
> base/gscscie.c
> base/gscsel.h
> base/gscsepr.c
> base/gscsepr.h
> base/gscspace.c
> base/gscspace.h
> base/gscssub.c
> base/gscssub.h
> base/gsdcolor.h
> base/gsdevice.c
> base/gsdevice.h
> base/gsdevmem.c
> base/gsdll.h
> base/gsdllwin.h
> base/gsdparam.c
> base/gsdps1.c
> base/gsdsrc.c
> base/gsdsrc.h
> base/gsequivc.c
> base/gsequivc.h
> base/gserrors.h
> base/gsexit.h
> base/gsfcid.c
> base/gsfcid2.c
> base/gsfcmap.c
> base/gsfcmap.h
> base/gsfcmap1.c
> base/gsflip.c
> base/gsflip.h
> base/gsfname.c
> base/gsfname.h
> base/gsfont.c
> base/gsfont.h
> base/gsfont0.c
> base/gsfont0c.c
> base/gsform1.h
> base/gsfunc.c
> base/gsfunc.h
> base/gsfunc0.c
> base/gsfunc0.h
> base/gsfunc3.c
> base/gsfunc3.h
> base/gsfunc4.c
> base/gsfunc4.h
> base/gsgc.h
> base/gsgcache.c
> base/gsgcache.h
> base/gsgdata.c
> base/gsgdata.h
> base/gsgstate.c
> base/gsgstate.h
> base/gshsb.c
> base/gshsb.h
> base/gsht.c
> base/gsht.h
> base/gsht1.c
> base/gsht1.h
> base/gshtscr.c
> base/gshtx.c
> base/gshtx.h
> base/gsicc.c
> base/gsicc.h
> base/gsicc_cache.c
> base/gsicc_cache.h
> base/gsicc_cms.h
> base/gsicc_create.c
> base/gsicc_create.h
> base/gsicc_lcms2.c
> base/gsicc_lcms2mt.c
> base/gsicc_manage.c
> base/gsicc_manage.h
> base/gsicc_monitorcm.c
> base/gsicc_nocm.c
> base/gsicc_profilecache.c
> base/gsicc_profilecache.h
> base/gsicc_replacecm.c
> base/gsimage.c
> base/gsimage.h
> base/gsimpath.c
> base/gsinit.c
> base/gsio.h
> base/gsiodev.c
> base/gsiodevs.c
> base/gsiodisk.c
> base/gsioram.c
> base/gsiorom.c
> base/gsiorom.h
> base/gsipar3x.h
> base/gsiparam.h
> base/gsiparm3.h
> base/gsiparm4.h
> base/gsjconf.h
> base/gsjmorec.h
> base/gslib.c
> base/gslib.h
> base/gslibctx.c
> base/gslibctx.h
> base/gsline.c
> base/gsline.h
> base/gslparam.h
> base/gsmalloc.c
> base/gsmalloc.h
> base/gsmatrix.c
> base/gsmatrix.h
> base/gsmchunk.c
> base/gsmchunk.h
> base/gsmdebug.h
> base/gsmemory.c
> base/gsmemory.h
> base/gsmemraw.h
> base/gsmemret.c
> base/gsmemret.h
> base/gsmisc.c
> base/gsnamecl.c
> base/gsnamecl.h
> base/gsncdummy.c
> base/gsncdummy.h
> base/gsnogc.c
> base/gsnogc.h
> base/gsnotify.c
> base/gsnotify.h
> base/gsovrc.c
> base/gsovrc.h
> base/gspaint.c
> base/gspaint.h
> base/gsparam.c
> base/gsparam.h
> base/gsparam2.c
> base/gsparams.c
> base/gsparams.h
> base/gsparamx.c
> base/gsparamx.h
> base/gspath.c
> base/gspath.h
> base/gspath1.c
> base/gspath2.h
> base/gspcolor.c
> base/gspcolor.h
> base/gspenum.h
> base/gspmdrv.c
> base/gspmdrv.h
> base/gspmdrv.rc
> base/gsptype1.c
> base/gsptype1.h
> base/gsptype2.c
> base/gsptype2.h
> base/gsrect.h
> base/gsrefct.h
> base/gsromfs0.c
> base/gsrop.c
> base/gsrop.h
> base/gsroprun.c
> base/gsroprun1.h
> base/gsroprun24.h
> base/gsroprun8.h
> base/gsropt.h
> base/gsroptab.c
> base/gsserial.c
> base/gsserial.h
> base/gsshade.c
> base/gsshade.h
> base/gssprintf.h
> base/gsstate.c
> base/gsstate.h
> base/gsstrl.h
> base/gsstrtok.h
> base/gsstruct.h
> base/gsstype.h
> base/gstext.c
> base/gstext.h
> base/gstiffio.c
> base/gstiffio.h
> base/gstparam.h
> base/gstrans.c
> base/gstrans.h
> base/gstrap.c
> base/gstrap.h
> base/gstype1.c
> base/gstype1.h
> base/gstype2.c
> base/gstype42.c
> base/gstypes.h
> base/gsuid.h
> base/gsutil.c
> base/gsutil.h
> base/gswin.rc
> base/gsxfont.h
> base/gx.h
> base/gxacpath.c
> base/gxalloc.h
> base/gxalpha.h
> base/gxarith.h
> base/gxband.h
> base/gxbcache.c
> base/gxbcache.h
> base/gxbitfmt.h
> base/gxbitmap.h
> base/gxbitops.h
> base/gxblend.c
> base/gxblend.h
> base/gxblend1.c
> base/gxccache.c
> base/gxccman.c
> base/gxcdevn.h
> base/gxchar.c
> base/gxchar.h
> base/gxchrout.c
> base/gxchrout.h
> base/gxcht.c
> base/gxcid.h
> base/gxcie.h
> base/gxcindex.h
> base/gxclbits.c
> base/gxcldev.h
> base/gxclfile.c
> base/gxclimag.c
> base/gxclio.h
> base/gxclip.c
> base/gxclip.h
> base/gxclip2.c
> base/gxclip2.h
> base/gxclipm.c
> base/gxclipm.h
> base/gxclipsr.h
> base/gxclist.c
> base/gxclist.h
> base/gxcllzw.c
> base/gxclmem.c
> base/gxclmem.h
> base/gxclpage.c
> base/gxclpage.h
> base/gxclpath.c
> base/gxclpath.h
> base/gxclrast.c
> base/gxclread.c
> base/gxclrect.c
> base/gxclthrd.c
> base/gxclthrd.h
> base/gxclutil.c
> base/gxclzlib.c
> base/gxcmap.c
> base/gxcmap.h
> base/gxcolor2.h
> base/gxcomp.h
> base/gxcoord.h
> base/gxcpath.c
> base/gxcpath.h
> base/gxcspace.h
> base/gxctable.c
> base/gxctable.h
> base/gxcvalue.h
> base/gxdcconv.c
> base/gxdcconv.h
> base/gxdcolor.c
> base/gxdcolor.h
> base/gxdda.h
> base/gxdevbuf.h
> base/gxdevcli.h
> base/gxdevice.h
> base/gxdevmem.h
> base/gxdevndi.c
> base/gxdevrop.h
> base/gxdevsop.h
> base/gxdht.h
> base/gxdhtres.h
> base/gxdhtserial.c
> base/gxdhtserial.h
> base/gxdither.h
> base/gxdownscale.c
> base/gxdownscale.h
> base/gxdtfill.h
> base/gxfapi.c
> base/gxfapi.h
> base/gxfapiu.c
> base/gxfapiu.h
> base/gxfarith.h
> base/gxfcache.h
> base/gxfcid.h
> base/gxfcmap.h
> base/gxfcmap1.h
> base/gxfill.c
> base/gxfill.h
> base/gxfillsl.h
> base/gxfilltr.h
> base/gxfillts.h
> base/gxfixed.h
> base/gxfmap.h
> base/gxfont.h
> base/gxfont0.h
> base/gxfont0c.h
> base/gxfont1.h
> base/gxfont42.h
> base/gxfrac.h
> base/gxftype.h
> base/gxfunc.h
> base/gxgetbit.h
> base/gxgstate.h
> base/gxhintn.c
> base/gxhintn.h
> base/gxhintn1.c
> base/gxhldevc.c
> base/gxhldevc.h
> base/gxht.c
> base/gxht.h
> base/gxht_thresh.c
> base/gxht_thresh.h
> base/gxhtbit.c
> base/gxhttile.h
> base/gxhttype.h
> base/gxi12bit.c
> base/gxi16bit.c
> base/gxiclass.h
> base/gxicolor.c
> base/gxidata.c
> base/gxifast.c
> base/gximag3x.c
> base/gximag3x.h
> base/gximage.c
> base/gximage.h
> base/gximage1.c
> base/gximage3.c
> base/gximage3.h
> base/gximage4.c
> base/gximask.c
> base/gximask.h
> base/gximono.c
> base/gxiodev.h
> base/gxiparam.h
> base/gxipixel.c
> base/gxiscale.c
> base/gxline.h
> base/gxlum.h
> base/gxmatrix.h
> base/gxmclip.c
> base/gxmclip.h
> base/gxobj.h
> base/gxoprect.c
> base/gxoprect.h
> base/gxp1fill.c
> base/gxp1impl.h
> base/gxpaint.c
> base/gxpaint.h
> base/gxpath.c
> base/gxpath.h
> base/gxpath2.c
> base/gxpcache.h
> base/gxpcmap.c
> base/gxpcolor.h
> base/gxpcopy.c
> base/gxpdash.c
> base/gxpflat.c
> base/gxrplane.h
> base/gxsample.c
> base/gxsample.h
> base/gxsamplp.h
> base/gxscanc.c
> base/gxscanc.h
> base/gxshade.c
> base/gxshade.h
> base/gxshade1.c
> base/gxshade4.c
> base/gxshade4.h
> base/gxshade6.c
> base/gxstate.h
> base/gxstdio.h
> base/gxstroke.c
> base/gxsync.c
> base/gxsync.h
> base/gxtext.h
> base/gxtmap.h
> base/gxttf.h
> base/gxttfb.c
> base/gxttfb.h
> base/gxtype1.c
> base/gxtype1.h
> base/gxxfont.h
> base/gzacpath.h
> base/gzcpath.h
> base/gzht.h
> base/gzline.h
> base/gzpath.h
> base/gzspotan.c
> base/gzspotan.h
> base/gzstate.h
> base/ijs.mak
> base/instcopy
> base/jbig2.mak
> base/jerror_.h
> base/jmemcust.c
> base/jmemcust.h
> base/jpeg.mak
> base/jpegxr.mak
> base/lcms2.mak
> base/lcms2mt.mak
> base/lcups.mak
> base/lcupsi.mak
> base/ldf_jb2.mak
> base/lib.mak
> base/locale_.h
> base/lwf_jp2.mak
> base/malloc_.h
> base/math_.h
> base/memory_.h
> base/mkromfs.c
> base/msvccmd.mak
> base/msvclib.mak
> base/msvctail.mak
> base/openjpeg.mak
> base/openvms.mak
> base/openvms.mmk
> base/pack_ps.c
> base/pcwin.mak
> base/pipe_.h
> base/png.mak
> base/png_.h
> base/ramfs.c
> base/ramfs.h
> base/sa85d.c
> base/sa85d.h
> base/sa85x.h
> base/saes.c
> base/saes.h
> base/sarc4.c
> base/sarc4.h
> base/sbcp.c
> base/sbcp.h
> base/sbtx.h
> base/scanchar.h
> base/scantab.c
> base/scf.h
> base/scfd.c
> base/scfdgen.c
> base/scfdtab.c
> base/scfe.c
> base/scfetab.c
> base/scfparam.c
> base/scfx.h
> base/scommon.h
> base/sdcparam.c
> base/sdcparam.h
> base/sdct.h
> base/sdctc.c
> base/sdctd.c
> base/sdcte.c
> base/sddparam.c
> base/sdeparam.c
> base/seexec.c
> base/setjmp_.h
> base/sfilter.h
> base/sfilter1.c
> base/sfilter2.c
> base/sfxboth.c
> base/sfxcommon.c
> base/sfxfd.c
> base/sfxstdio.c
> base/shc.c
> base/shc.h
> base/sidscale.c
> base/sidscale.h
> base/siinterp.c
> base/siinterp.h
> base/simscale.c
> base/simscale.h
> base/siscale.c
> base/siscale.h
> base/sisparam.h
> base/sjbig2.c
> base/sjbig2.h
> base/sjbig2_luratech.c
> base/sjbig2_luratech.h
> base/sjpeg.h
> base/sjpegc.c
> base/sjpegd.c
> base/sjpege.c
> base/sjpx_luratech.c
> base/sjpx_luratech.h
> base/sjpx_none.c
> base/sjpx_openjpeg.c
> base/sjpx_openjpeg.h
> base/slzwc.c
> base/slzwd.c
> base/slzwe.c
> base/slzwx.h
> base/smd5.c
> base/smd5.h
> base/smtf.h
> base/spdiff.c
> base/spdiffx.h
> base/spngp.c
> base/spngpx.h
> base/spprint.c
> base/spprint.h
> base/spsdf.c
> base/spsdf.h
> base/srdline.h
> base/srld.c
> base/srle.c
> base/srlx.h
> base/ssha2.c
> base/ssha2.h
> base/sstring.c
> base/sstring.h
> base/stat_.h
> base/std.h
> base/stdint_.h
> base/stdio_.h
> base/stdpre.h
> base/stream.c
> base/stream.h
> base/strimpl.h
> base/string_.h
> base/strmio.c
> base/strmio.h
> base/stub.mak
> base/szlibc.c
> base/szlibd.c
> base/szlibe.c
> base/szlibx.h
> base/szlibxx.h
> base/tiff.mak
> base/time_.h
> base/ttcalc.c
> base/ttcalc.h
> base/ttcommon.h
> base/ttconf.h
> base/ttconfig.h
> base/ttfinp.c
> base/ttfinp.h
> base/ttfmain.c
> base/ttfmemd.c
> base/ttfmemd.h
> base/ttfoutl.h
> base/ttfsfnt.h
> base/ttinterp.c
> base/ttinterp.h
> base/ttload.c
> base/ttload.h
> base/ttmisc.h
> base/ttobjs.c
> base/ttobjs.h
> base/tttables.h
> base/tttype.h
> base/tttypes.h
> base/ugcclib.mak
> base/unistd_.h
> base/unix-aux.mak
> base/unix-dll.mak
> base/unix-end.mak
> base/unix-gcc.mak
> base/unixansi.mak
> base/unixhead.mak
> base/unixinst.mak
> base/unixlink.mak
> base/valgrind.h
> base/version.mak
> base/vms_x_fix.h
> base/vmsmath.h
> base/windows_.h
> base/winlib.mak
> base/winplat.mak
> base/winrtsup.cpp
> base/winrtsup.h
> base/wrfont.c
> base/wrfont.h
> base/write_t1.c
> base/write_t1.h
> base/write_t2.c
> base/write_t2.h
> base/x_.h
> base/zlib.mak
> configure.ac
> devices/contrib.mak
> devices/devs.mak
> devices/gdev3852.c
> devices/gdev4081.c
> devices/gdev8510.c
> devices/gdev8bcm.c
> devices/gdev8bcm.h
> devices/gdevatx.c
> devices/gdevbit.c
> devices/gdevbj10.c
> devices/gdevbjc.h
> devices/gdevbjcl.c
> devices/gdevbjcl.h
> devices/gdevbmp.c
> devices/gdevbmp.h
> devices/gdevbmpc.c
> devices/gdevccr.c
> devices/gdevcdj.c
> devices/gdevcfax.c
> devices/gdevchameleon.c
> devices/gdevcif.c
> devices/gdevclj.c
> devices/gdevcljc.c
> devices/gdevcmykog.c
> devices/gdevcslw.c
> devices/gdevdfax.c
> devices/gdevdjet.c
> devices/gdevdjtc.c
> devices/gdevdljm.c
> devices/gdevdljm.h
> devices/gdevdm24.c
> devices/gdevdsp.c
> devices/gdevdsp.h
> devices/gdevdsp2.h
> devices/gdevepsc.c
> devices/gdevepsn.c
> devices/gdevescp.c
> devices/gdevfax.c
> devices/gdevfax.h
> devices/gdevfpng.c
> devices/gdevgprf.c
> devices/gdevhl7x.c
> devices/gdevicov.c
> devices/gdevijs.c
> devices/gdevimgn.c
> devices/gdevjbig2.c
> devices/gdevjpeg.c
> devices/gdevjpx.c
> devices/gdevl31s.c
> devices/gdevlbp8.c
> devices/gdevlj56.c
> devices/gdevlp8k.c
> devices/gdevlxm.c
> devices/gdevmeds.c
> devices/gdevmeds.h
> devices/gdevmgr.c
> devices/gdevmgr.h
> devices/gdevmiff.c
> devices/gdevn533.c
> devices/gdevo182.c
> devices/gdevokii.c
> devices/gdevpbm.c
> devices/gdevpcl.c
> devices/gdevpcl.h
> devices/gdevpcx.c
> devices/gdevpe.c
> devices/gdevperm.c
> devices/gdevphex.c
> devices/gdevpjet.c
> devices/gdevplan.c
> devices/gdevplib.c
> devices/gdevplib.h
> devices/gdevpm.h
> devices/gdevpng.c
> devices/gdevpsd.c
> devices/gdevpsd.h
> devices/gdevpsim.c
> devices/gdevpxut.c
> devices/gdevpxut.h
> devices/gdevrinkj.c
> devices/gdevsj48.c
> devices/gdevsnfb.c
> devices/gdevsppr.c
> devices/gdevstc.c
> devices/gdevstc.h
> devices/gdevstc1.c
> devices/gdevstc2.c
> devices/gdevstc3.c
> devices/gdevstc4.c
> devices/gdevtfax.c
> devices/gdevtfax.h
> devices/gdevtfnx.c
> devices/gdevtifs.c
> devices/gdevtifs.h
> devices/gdevtknk.c
> devices/gdevtrac.c
> devices/gdevtsep.c
> devices/gdevupd.c
> devices/gdevwpr2.c
> devices/gdevx.c
> devices/gdevx.h
> devices/gdevxalt.c
> devices/gdevxcf.c
> devices/gdevxcmp.c
> devices/gdevxcmp.h
> devices/gdevxini.c
> devices/gdevxres.c
> devices/gxfcopy.c
> devices/gxfcopy.h
> devices/minftrsz.c
> devices/minftrsz.h
> devices/rinkj/evenbetter-rll.c
> devices/rinkj/evenbetter-rll.h
> devices/rinkj/rinkj-byte-stream.c
> devices/rinkj/rinkj-byte-stream.h
> devices/rinkj/rinkj-config.c
> devices/rinkj/rinkj-config.h
> devices/rinkj/rinkj-device.c
> devices/rinkj/rinkj-device.h
> devices/rinkj/rinkj-dither.c
> devices/rinkj/rinkj-dither.h
> devices/rinkj/rinkj-epson870.c
> devices/rinkj/rinkj-epson870.h
> devices/rinkj/rinkj-screen-eb.c
> devices/rinkj/rinkj-screen-eb.h
> devices/vector/gdevagl.c
> devices/vector/gdevagl.h
> devices/vector/gdevpdf.c
> devices/vector/gdevpdfb.c
> devices/vector/gdevpdfb.h
> devices/vector/gdevpdfc.c
> devices/vector/gdevpdfc.h
> devices/vector/gdevpdfd.c
> devices/vector/gdevpdfe.c
> devices/vector/gdevpdfg.c
> devices/vector/gdevpdfg.h
> devices/vector/gdevpdfi.c
> devices/vector/gdevpdfj.c
> devices/vector/gdevpdfk.c
> devices/vector/gdevpdfm.c
> devices/vector/gdevpdfo.c
> devices/vector/gdevpdfo.h
> devices/vector/gdevpdfp.c
> devices/vector/gdevpdfr.c
> devices/vector/gdevpdft.c
> devices/vector/gdevpdfu.c
> devices/vector/gdevpdfv.c
> devices/vector/gdevpdfx.h
> devices/vector/gdevpdt.c
> devices/vector/gdevpdt.h
> devices/vector/gdevpdtb.c
> devices/vector/gdevpdtb.h
> devices/vector/gdevpdtc.c
> devices/vector/gdevpdtd.c
> devices/vector/gdevpdtd.h
> devices/vector/gdevpdte.c
> devices/vector/gdevpdtf.c
> devices/vector/gdevpdtf.h
> devices/vector/gdevpdti.c
> devices/vector/gdevpdti.h
> devices/vector/gdevpdts.c
> devices/vector/gdevpdts.h
> devices/vector/gdevpdtt.c
> devices/vector/gdevpdtt.h
> devices/vector/gdevpdtv.c
> devices/vector/gdevpdtv.h
> devices/vector/gdevpdtw.c
> devices/vector/gdevpdtw.h
> devices/vector/gdevpdtx.h
> devices/vector/gdevpsdf.h
> devices/vector/gdevpsdi.c
> devices/vector/gdevpsdp.c
> devices/vector/gdevpsds.c
> devices/vector/gdevpsds.h
> devices/vector/gdevpsdu.c
> devices/vector/gdevpsf.h
> devices/vector/gdevpsf1.c
> devices/vector/gdevpsf2.c
> devices/vector/gdevpsfm.c
> devices/vector/gdevpsft.c
> devices/vector/gdevpsfu.c
> devices/vector/gdevpsfx.c
> devices/vector/gdevpsu.c
> devices/vector/gdevpsu.h
> devices/vector/gdevpx.c
> devices/vector/gdevtxtw.c
> devices/vector/gdevxps.c
> devices/vector/opdfread.ps
> devices/vector/whitelst.c
> devices/vector/whitelst.h
> gpdl/gpdl.mak
> gpdl/psi/gpdlpsi.mak
> gpdl/psi/psitop.c
> gpdl/pspcl6_gcc.mak
> gpdl/pspcl6_msvc.mak
> ijs/Makefile.am
> ijs/configure.ac
> ijs/ijs.c
> ijs/ijs.h
> ijs/ijs_client.c
> ijs/ijs_client.h
> ijs/ijs_client_example.c
> ijs/ijs_exec_unix.c
> ijs/ijs_exec_win.c
> ijs/ijs_server.c
> ijs/ijs_server_example.c
> ijs/unistd_.h
> ios/ios_arch-arm.h
> ios/ios_arch-x86.h
> jbig2dec/config_win32.h
> jbig2dec/jbig2.c
> jbig2dec/jbig2.h
> jbig2dec/jbig2_arith.c
> jbig2dec/jbig2_arith.h
> jbig2dec/jbig2_arith_iaid.c
> jbig2dec/jbig2_arith_iaid.h
> jbig2dec/jbig2_arith_int.c
> jbig2dec/jbig2_arith_int.h
> jbig2dec/jbig2_generic.c
> jbig2dec/jbig2_generic.h
> jbig2dec/jbig2_halftone.c
> jbig2dec/jbig2_halftone.h
> jbig2dec/jbig2_huffman.c
> jbig2dec/jbig2_huffman.h
> jbig2dec/jbig2_hufftab.h
> jbig2dec/jbig2_image.c
> jbig2dec/jbig2_image.h
> jbig2dec/jbig2_image_pbm.c
> jbig2dec/jbig2_image_png.c
> jbig2dec/jbig2_image_rw.h
> jbig2dec/jbig2_mmr.c
> jbig2dec/jbig2_mmr.h
> jbig2dec/jbig2_page.c
> jbig2dec/jbig2_page.h
> jbig2dec/jbig2_priv.h
> jbig2dec/jbig2_refinement.c
> jbig2dec/jbig2_refinement.h
> jbig2dec/jbig2_segment.c
> jbig2dec/jbig2_segment.h
> jbig2dec/jbig2_symbol_dict.c
> jbig2dec/jbig2_symbol_dict.h
> jbig2dec/jbig2_text.c
> jbig2dec/jbig2_text.h
> jbig2dec/jbig2dec.c
> jbig2dec/memcmp.c
> jbig2dec/os_types.h
> jbig2dec/pbm2png.c
> lib/FCOfontmap-PCLPS3
> lib/FCOfontmap-PS3
> lib/Fontmap.ATB
> lib/Fontmap.ATM
> lib/Fontmap.OS2
> lib/Fontmap.SGI
> lib/Fontmap.Sol
> lib/Fontmap.URW-136.T1
> lib/Fontmap.URW-136.TT
> lib/Fontmap.Ult
> lib/Fontmap.VMS
> lib/align.ps
> lib/caption.ps
> lib/cat.ps
> lib/cid2code.ps
> lib/docie.ps
> lib/font2pcl.ps
> lib/gs_ce_e.ps
> lib/gs_il2_e.ps
> lib/gs_kanji.ps
> lib/gs_ksb_e.ps
> lib/gs_lgo_e.ps
> lib/gs_lgx_e.ps
> lib/gs_wl1_e.ps
> lib/gs_wl2_e.ps
> lib/gs_wl5_e.ps
> lib/gslp.ps
> lib/gsnup.ps
> lib/image-qa.ps
> lib/jispaper.ps
> lib/lines.ps
> lib/mkcidfm.ps
> lib/pdf2dsc.ps
> lib/pfbtopfa.ps
> lib/ppath.ps
> lib/pphs.ps
> lib/prfont.ps
> lib/ps2ai.ps
> lib/ps2epsi.ps
> lib/rollconv.ps
> lib/stcinfo.ps
> lib/stcolor.ps
> lib/stocht.ps
> lib/traceimg.ps
> lib/traceop.ps
> lib/uninfo.ps
> lib/viewcmyk.ps
> lib/viewgif.ps
> lib/viewmiff.ps
> lib/viewpbm.ps
> lib/viewpcx.ps
> lib/viewps2a.ps
> lib/viewraw.ps
> lib/viewrgb.ps
> lib/winmaps.ps
> lib/zeroline.ps
> pcl/pcl/pcbiptrn.c
> pcl/pcl/pcbiptrn.h
> pcl/pcl/pccid.c
> pcl/pcl/pccid.h
> pcl/pcl/pccolor.c
> pcl/pcl/pccoord.h
> pcl/pcl/pccprint.c
> pcl/pcl/pccsbase.c
> pcl/pcl/pccsbase.h
> pcl/pcl/pcdict.h
> pcl/pcl/pcdither.c
> pcl/pcl/pcdither.h
> pcl/pcl/pcdraw.c
> pcl/pcl/pcdraw.h
> pcl/pcl/pcfont.c
> pcl/pcl/pcfont.h
> pcl/pcl/pcfontpg.c
> pcl/pcl/pcfontst.h
> pcl/pcl/pcfrgrnd.c
> pcl/pcl/pcfrgrnd.h
> pcl/pcl/pcfsel.c
> pcl/pcl/pcfsel.h
> pcl/pcl/pcht.c
> pcl/pcl/pcht.h
> pcl/pcl/pcident.c
> pcl/pcl/pcident.h
> pcl/pcl/pcimpl.c
> pcl/pcl/pcindxed.c
> pcl/pcl/pcindxed.h
> pcl/pcl/pcjob.c
> pcl/pcl/pcl.mak
> pcl/pcl/pcl_top.mak
> pcl/pcl/pclookup.c
> pcl/pcl/pclookup.h
> pcl/pcl/pcmacros.c
> pcl/pcl/pcmisc.c
> pcl/pcl/pcmtx3.c
> pcl/pcl/pcmtx3.h
> pcl/pcl/pcommand.c
> pcl/pcl/pcommand.h
> pcl/pcl/pcpage.c
> pcl/pcl/pcpage.h
> pcl/pcl/pcpalet.c
> pcl/pcl/pcpalet.h
> pcl/pcl/pcparam.h
> pcl/pcl/pcparse.c
> pcl/pcl/pcparse.h
> pcl/pcl/pcpatrn.c
> pcl/pcl/pcpatrn.h
> pcl/pcl/pcpattyp.h
> pcl/pcl/pcpatxfm.c
> pcl/pcl/pcpatxfm.h
> pcl/pcl/pcrect.c
> pcl/pcl/pcsfont.c
> pcl/pcl/pcstate.h
> pcl/pcl/pcstatus.c
> pcl/pcl/pcsymbol.c
> pcl/pcl/pcsymbol.h
> pcl/pcl/pctext.c
> pcl/pcl/pctop.c
> pcl/pcl/pctop.h
> pcl/pcl/pctpm.h
> pcl/pcl/pcuptrn.c
> pcl/pcl/pcuptrn.h
> pcl/pcl/pcursor.c
> pcl/pcl/pcursor.h
> pcl/pcl/pcwhtidx.c
> pcl/pcl/pcwhtidx.h
> pcl/pcl/pcxfmst.h
> pcl/pcl/pgchar.c
> pcl/pcl/pgcolor.c
> pcl/pcl/pgconfig.c
> pcl/pcl/pgdraw.c
> pcl/pcl/pgdraw.h
> pcl/pcl/pgfdata.c
> pcl/pcl/pgfdata.h
> pcl/pcl/pgfont.c
> pcl/pcl/pgfont.h
> pcl/pcl/pgframe.c
> pcl/pcl/pggeom.c
> pcl/pcl/pggeom.h
> pcl/pcl/pginit.c
> pcl/pcl/pginit.h
> pcl/pcl/pglabel.c
> pcl/pcl/pglfill.c
> pcl/pcl/pgmand.h
> pcl/pcl/pgmisc.c
> pcl/pcl/pgmisc.h
> pcl/pcl/pgparse.c
> pcl/pcl/pgpoly.c
> pcl/pcl/pgstate.h
> pcl/pcl/pgvector.c
> pcl/pcl/rtgmode.c
> pcl/pcl/rtgmode.h
> pcl/pcl/rtmisc.c
> pcl/pcl/rtmisc.h
> pcl/pcl/rtraster.c
> pcl/pcl/rtraster.h
> pcl/pcl/rtrstcmp.c
> pcl/pcl/rtrstcmp.h
> pcl/pcl/rtrstst.h
> pcl/pl/pjparse.c
> pcl/pl/pjparse.h
> pcl/pl/pjparsei.c
> pcl/pl/pjtop.c
> pcl/pl/pjtop.h
> pcl/pl/pl.mak
> pcl/pl/plalloc.c
> pcl/pl/plapi.c
> pcl/pl/plapi.h
> pcl/pl/plchar.c
> pcl/pl/plchar.h
> pcl/pl/pldebug.h
> pcl/pl/pldict.c
> pcl/pl/pldict.h
> pcl/pl/pldraw.c
> pcl/pl/pldraw.h
> pcl/pl/plfapi.c
> pcl/pl/plfapi.h
> pcl/pl/plfont.c
> pcl/pl/plfont.h
> pcl/pl/plftable.c
> pcl/pl/plftable.h
> pcl/pl/plht.c
> pcl/pl/plht.h
> pcl/pl/plimpl.c
> pcl/pl/pllfont.c
> pcl/pl/pllfont.h
> pcl/pl/plmain.c
> pcl/pl/plmain.h
> pcl/pl/plparams.c
> pcl/pl/plparams.h
> pcl/pl/plparse.h
> pcl/pl/plromfs.mak
> pcl/pl/plsymbol.c
> pcl/pl/plsymbol.h
> pcl/pl/pltop.c
> pcl/pl/pltop.h
> pcl/pl/pluchar.c
> pcl/pl/plufont.c
> pcl/pl/plufstlp.c
> pcl/pl/plufstlp.h
> pcl/pl/plufstlp1.c
> pcl/pl/plulfont.c
> pcl/pl/plvalue.c
> pcl/pl/plvalue.h
> pcl/pl/plvocab.c
> pcl/pl/plvocab.h
> pcl/pl/plwimg.c
> pcl/pl/plwimg.h
> pcl/pl/plwmainc.c
> pcl/pl/plwreg.c
> pcl/pl/plwreg.h
> pcl/pl/plwres.h
> pcl/pl/realmain.c
> pcl/pxl/pxasm.ps
> pcl/pxl/pxattr.h
> pcl/pxl/pxbfont.c
> pcl/pxl/pxbfont.h
> pcl/pxl/pxbfont.ps
> pcl/pxl/pxcet.txt
> pcl/pxl/pxdict.h
> pcl/pxl/pxdiff.txt
> pcl/pxl/pxenum.h
> pcl/pxl/pxerrors.c
> pcl/pxl/pxerrors.h
> pcl/pxl/pxffont.c
> pcl/pxl/pxfont.c
> pcl/pxl/pxfont.h
> pcl/pxl/pxfts.txt
> pcl/pxl/pxgstate.c
> pcl/pxl/pxgstate.h
> pcl/pxl/pximage.c
> pcl/pxl/pximpl.c
> pcl/pxl/pxink.c
> pcl/pxl/pxl.mak
> pcl/pxl/pxlib.txt
> pcl/pxl/pxoper.h
> pcl/pxl/pxpaint.c
> pcl/pxl/pxparse.c
> pcl/pxl/pxparse.h
> pcl/pxl/pxptable.c
> pcl/pxl/pxptable.h
> pcl/pxl/pxpthr.c
> pcl/pxl/pxpthr.h
> pcl/pxl/pxsessio.c
> pcl/pxl/pxspec.txt
> pcl/pxl/pxstate.c
> pcl/pxl/pxstate.h
> pcl/pxl/pxstream.c
> pcl/pxl/pxsymbol.ps
> pcl/pxl/pxsymbol.psc
> pcl/pxl/pxsymbol.psh
> pcl/pxl/pxtag.h
> pcl/pxl/pxtop.c
> pcl/pxl/pxvalue.c
> pcl/pxl/pxvalue.h
> pcl/tools/pxlasm.py
> pcl/tools/pxldis.py
> pcl/tools/suite.tcl
> psi/bfont.h
> psi/btoken.h
> psi/dmmain.c
> psi/dmmain.r
> psi/dpmain.c
> psi/dscparse.c
> psi/dscparse.h
> psi/dstack.h
> psi/dwdll.c
> psi/dwdll.h
> psi/dwimg.c
> psi/dwimg.h
> psi/dwmain.c
> psi/dwmain.rc
> psi/dwmainc.c
> psi/dwnodll.c
> psi/dwreg.c
> psi/dwreg.h
> psi/dwres.h
> psi/dwtext.c
> psi/dwtext.h
> psi/dwtrace.c
> psi/dwtrace.h
> psi/dxmain.c
> psi/dxmainc.c
> psi/estack.h
> psi/files.h
> psi/ghost.h
> psi/gs.c
> psi/gsdll.c
> psi/gsdll2.rc
> psi/gsdll32.rc
> psi/gserver.c
> psi/gsos2.rc
> psi/ialloc.c
> psi/ialloc.h
> psi/iapi.c
> psi/iapi.h
> psi/iastate.h
> psi/iastruct.h
> psi/ibnum.c
> psi/ibnum.h
> psi/ichar.h
> psi/ichar1.h
> psi/icharout.h
> psi/icid.h
> psi/icie.h
> psi/icolor.h
> psi/iconf.c
> psi/iconf.h
> psi/icontext.c
> psi/icontext.h
> psi/icremap.h
> psi/icsmap.h
> psi/icstate.h
> psi/iddict.h
> psi/iddstack.h
> psi/idebug.c
> psi/idebug.h
> psi/idict.c
> psi/idict.h
> psi/idictdef.h
> psi/idicttpl.h
> psi/idisp.c
> psi/idisp.h
> psi/idosave.h
> psi/idparam.c
> psi/idparam.h
> psi/idsdata.h
> psi/idstack.c
> psi/idstack.h
> psi/ierrors.h
> psi/iesdata.h
> psi/iestack.h
> psi/ifapi.h
> psi/ifcid.h
> psi/ifilter.h
> psi/ifilter2.h
> psi/ifont.h
> psi/ifont1.h
> psi/ifont2.h
> psi/ifont42.h
> psi/ifrpred.h
> psi/ifunc.h
> psi/ifwpred.h
> psi/igc.c
> psi/igc.h
> psi/igcref.c
> psi/igcstr.c
> psi/igcstr.h
> psi/igstate.h
> psi/iht.h
> psi/iimage.h
> psi/iinit.c
> psi/iinit.h
> psi/ilevel.h
> psi/ilocate.c
> psi/imain.c
> psi/imain.h
> psi/imainarg.c
> psi/imainarg.h
> psi/imemory.h
> psi/iminst.h
> psi/iname.c
> psi/iname.h
> psi/inamedef.h
> psi/inameidx.h
> psi/inames.h
> psi/inamestr.h
> psi/inobtokn.c
> psi/inouparm.c
> psi/int.mak
> psi/interp.c
> psi/interp.h
> psi/iosdata.h
> psi/iostack.h
> psi/ipacked.h
> psi/iparam.c
> psi/iparam.h
> psi/iparray.h
> psi/ipcolor.h
> psi/iplugin.c
> psi/iplugin.h
> psi/ireclaim.c
> psi/iref.h
> psi/isave.c
> psi/isave.h
> psi/iscan.c
> psi/iscan.h
> psi/iscanbin.c
> psi/iscanbin.h
> psi/iscannum.c
> psi/iscannum.h
> psi/isdata.h
> psi/isstate.h
> psi/istack.c
> psi/istack.h
> psi/istkparm.h
> psi/istream.h
> psi/istruct.h
> psi/itoken.h
> psi/iutil.c
> psi/iutil.h
> psi/iutil2.c
> psi/iutil2.h
> psi/ivmem2.h
> psi/ivmspace.h
> psi/main.h
> psi/mkfilelt.cpp
> psi/msvc.mak
> psi/msvc32.mak
> psi/msvc64.mak
> psi/nsisinst.nsi
> psi/oparc.h
> psi/opcheck.h
> psi/opdef.h
> psi/oper.h
> psi/opextern.h
> psi/os2.mak
> psi/ostack.h
> psi/psapi.c
> psi/psapi.h
> psi/psromfs.mak
> psi/store.h
> psi/winint.mak
> psi/zalg.c
> psi/zarith.c
> psi/zarray.c
> psi/zbfont.c
> psi/zbseq.c
> psi/zcfont.c
> psi/zchar.c
> psi/zchar1.c
> psi/zchar2.c
> psi/zchar32.c
> psi/zchar42.c
> psi/zchar42.h
> psi/zcharout.c
> psi/zcharx.c
> psi/zcid.c
> psi/zcie.c
> psi/zcie.h
> psi/zcolor.c
> psi/zcolor.h
> psi/zcolor1.c
> psi/zcolor2.c
> psi/zcolor3.c
> psi/zcontrol.c
> psi/zcrd.c
> psi/zcsindex.c
> psi/zcspixel.c
> psi/zcssepr.c
> psi/zdevcal.c
> psi/zdevice.c
> psi/zdevice2.c
> psi/zdfilter.c
> psi/zdict.c
> psi/zdouble.c
> psi/zdps1.c
> psi/zdscpars.c
> psi/zfaes.c
> psi/zfapi.c
> psi/zfarc4.c
> psi/zfbcp.c
> psi/zfcid.c
> psi/zfcid0.c
> psi/zfcid1.c
> psi/zfcmap.c
> psi/zfdctd.c
> psi/zfdcte.c
> psi/zfdecode.c
> psi/zfile.c
> psi/zfile.h
> psi/zfile1.c
> psi/zfileio.c
> psi/zfilter.c
> psi/zfilter2.c
> psi/zfimscale.c
> psi/zfjbig2.c
> psi/zfjpx.c
> psi/zfmd5.c
> psi/zfont.c
> psi/zfont0.c
> psi/zfont1.c
> psi/zfont2.c
> psi/zfont32.c
> psi/zfont42.c
> psi/zfontenum.c
> psi/zform.c
> psi/zfproc.c
> psi/zfrsd.c
> psi/zfrsd.h
> psi/zfsample.c
> psi/zfsha2.c
> psi/zfunc.c
> psi/zfunc.h
> psi/zfunc0.c
> psi/zfunc3.c
> psi/zfunc4.c
> psi/zfzlib.c
> psi/zgeneric.c
> psi/zgstate.c
> psi/zht.c
> psi/zht1.c
> psi/zht2.c
> psi/zht2.h
> psi/zicc.c
> psi/zicc.h
> psi/zimage.c
> psi/zimage3.c
> psi/ziodev.c
> psi/ziodev2.c
> psi/ziodevsc.c
> psi/zmath.c
> psi/zmatrix.c
> psi/zmedia2.c
> psi/zmisc.c
> psi/zmisc1.c
> psi/zmisc2.c
> psi/zmisc3.c
> psi/zncdummy.c
> psi/zpacked.c
> psi/zpaint.c
> psi/zpath.c
> psi/zpath1.c
> psi/zpcolor.c
> psi/zpdf_r6.c
> psi/zpdfops.c
> psi/zrelbit.c
> psi/zshade.c
> psi/zstack.c
> psi/zstring.c
> psi/zsysvm.c
> psi/ztoken.c
> psi/ztrans.c
> psi/ztrap.c
> psi/ztype.c
> psi/zupath.c
> psi/zusparam.c
> psi/zutf8.c
> psi/zvmem.c
> psi/zvmem2.c
> psi/zwinutf8.c
> toolbin/GenSubstCID.ps
> toolbin/afmutil.py
> toolbin/color/icc_creator/ICC_Creator/CIELAB.h
> toolbin/color/icc_creator/ICC_Creator/ICC_Creator.cpp
> toolbin/color/icc_creator/ICC_Creator/ICC_Creator.h
> toolbin/color/icc_creator/ICC_Creator/ICC_CreatorDlg.cpp
> toolbin/color/icc_creator/ICC_Creator/ICC_CreatorDlg.h
> toolbin/color/icc_creator/ICC_Creator/icc_create.cpp
> toolbin/color/icc_creator/ICC_Creator/icc_create.h
> toolbin/color/icc_creator/README.txt
> toolbin/encs2c.ps
> toolbin/errlist.tcl
> toolbin/extractFonts.ps
> toolbin/extractICCprofiles.ps
> toolbin/gen_ldf_jb2.py
> toolbin/genfontmap.ps
> toolbin/gitlog2changelog.py
> toolbin/gsmake.tcl
> toolbin/halftone/gen_ordered/gen_ordered_main.c
> toolbin/halftone/gen_stochastic/gen_stochastic.c
> toolbin/headers.tcl
> toolbin/jpxtopdf.c
> toolbin/leaks.tcl
> toolbin/makehist.tcl
> toolbin/memory.py
> toolbin/ocheck.py
> toolbin/pdf_info.ps
> toolbin/pre.tcl
> toolbin/precheck.tcl
> toolbin/split_changelog.py
> toolbin/suite.tcl
> toolbin/tests/build_revision.py
> toolbin/tests/check_all.py
> toolbin/tests/check_comments.py
> toolbin/tests/check_dirs.py
> toolbin/tests/check_docrefs.py
> toolbin/tests/cmpi.py
> toolbin/tests/compare_checksumdb.py
> toolbin/tests/compare_checksums.py
> toolbin/tests/dump_checksum.py
> toolbin/tests/dump_checksum_plus.py
> toolbin/tests/dump_checksum_raw.py
> toolbin/tests/get_baseline_log.py
> toolbin/tests/get_baselines.py
> toolbin/tests/gscheck_all.py
> toolbin/tests/gscheck_fuzzypdf.py
> toolbin/tests/gscheck_pdfwrite.py
> toolbin/tests/gscheck_raster.py
> toolbin/tests/gscheck_testfiles.py
> toolbin/tests/gsconf.py
> toolbin/tests/gsparamsets.py
> toolbin/tests/gssum.py
> toolbin/tests/gstestgs.py
> toolbin/tests/gstestutils.py
> toolbin/tests/gsutil.py
> toolbin/tests/make_baselinedb.py
> toolbin/tests/make_testdb.py
> toolbin/tests/make_two_pdfversions
> toolbin/tests/make_two_versions
> toolbin/tests/myoptparse.py
> toolbin/tests/rasterdb.py
> toolbin/tests/revert_baseline
> toolbin/tests/revert_pdfbaseline
> toolbin/tests/run_nightly.py
> toolbin/tests/run_parallel
> toolbin/tests/run_regression.py
> toolbin/tests/testdiff.py
> toolbin/tests/update_baseline.py
> toolbin/tests/update_specific
> toolbin/tmake.tcl
> xps/ghostxps.h
> xps/xps.mak
> xps/xpsanalyze.c
> xps/xpscff.c
> xps/xpscolor.c
> xps/xpscommon.c
> xps/xpscrc.c
> xps/xpsdoc.c
> xps/xpsfapi.c
> xps/xpsfapi.h
> xps/xpsfont.c
> xps/xpsglyphs.c
> xps/xpsgradient.c
> xps/xpshash.c
> xps/xpsimage.c
> xps/xpsjpeg.c
> xps/xpsjxr.c
> xps/xpsmem.c
> xps/xpsopacity.c
> xps/xpspage.c
> xps/xpspath.c
> xps/xpspng.c
> xps/xpsresource.c
> xps/xpsromfs.mak
> xps/xpstiff.c
> xps/xpstile.c
> xps/xpstop.c
> xps/xpsttf.c
> xps/xpsutf.c
> xps/xpsvisual.c
> xps/xpsxml.c
> xps/xpszip.c

2019-01-16 08:08:28 -0800
Nancy Durgin <nancy.durgin@artifex.com>
373d83836619fe8b675b3db7235e4fee19b699fd

> Fixed typo and cleaned up usage of //systemdict vs systemdict
> Typo was misspelling of /.PDF_UNDEF_OPLIST
> Cleaned this up to just use //systemdict and .forceundef because the
> mix of uses was confusing.
> Took out 'executeonly' because it's not needed (though harmless). This
> procedure will have already been undef'd by the time the user gets access
> to the interpreter.
> Resource/Init/gs_init.ps

2019-01-15 15:30:46 -0800
Nancy Durgin <nancy.durgin@artifex.com>
9cae141e4654124379dc4738bbea4b5b6e13d37b

> Added array .PDF_UNDEF_OPLIST to pdf_main.ps instead of maintaining twice
> Used to maintain two different lists of operators in gs_init.ps and pdf_main.ps
> for undef'ing operators that are used by pdf, in two cases of DELAYBIND or
> not DELAYBIND.
> This change defines the array in pdf_main.ps and just references it in
> gs_init.ps.
> Also added a couple operators to the pdf_main.ps list that had gotten
> out of sync with the gs_init.ps one (which is why we really need just one
> list...)
> Resource/Init/gs_init.ps
> Resource/Init/pdf_main.ps

2019-01-16 14:10:01 +0000
Chris Liddell <chris.liddell@artifex.com>
5fac4ab4815b3bd86d471389357cdc7cc184f65c

> Update the copyright year (2019) in the documentation
> doc/API.htm
> doc/C-style.htm
> doc/Commprod.htm
> doc/DLL.htm
> doc/Deprecated.htm
> doc/Develop.htm
> doc/Devices.htm
> doc/Drivers.htm
> doc/Fonts.htm
> doc/History9.htm
> doc/Install.htm
> doc/Language.htm
> doc/Lib.htm
> doc/Make.htm
> doc/News.htm
> doc/Ps-style.htm
> doc/Ps2epsi.htm
> doc/Psfiles.htm
> doc/Readme.htm
> doc/Release.htm
> doc/SavedPages.htm
> doc/Source.htm
> doc/Unix-lpr.htm
> doc/Use.htm
> doc/VectorDevices.htm
> doc/WhatIsGS.htm
> doc/gdevds32.c
> doc/sample_downscale_device.htm
> doc/subclass.htm
> doc/thirdparty.htm

2019-01-16 05:12:54 -0800
Robin Watts <Robin.Watts@artifex.com>
03a1e5eaf83896053fa32f68d328ff48f86d906f

> Valgrind fixes.
> Firstly, move entirely to HAVE_VALGRIND rather than ENABLE_VALGRIND.
> My fault for having introduced 2 schemes to do the same thing in
> the past.
> Accordingly, move direct inclusions of memcheck/valgrind.h over to
> calling our local valgrind.h header.
> And finally, fix the problem that prompted all of this; in
> image_simple_expand, we take 1 bit data in. The last bytes in this
> data can frequently be only semi-filled, resulting in some
> undefined bits. While our code to quickly skip complete bytes is
> safe by construction, valgrind cannot recognise it as such, and so
> signals false positive UMRs.
> Work around that here by tweaking valgrinds ideas of what bits
> are defined.
> base/gsinit.c
> base/gxclfile.c
> base/gxclist.c
> base/gxclmem.c
> base/gxclutil.c
> base/gxifast.c
> base/valgrind.h
> psi/imain.c

2019-01-14 12:41:25 +0000
Robin Watts <robin.watts@artifex.com>
b5ecd380a5af595f5e843352df88a6957b1accda

> New valgrind makefile targets and clist tweak.
> We introduce 2 new families of targets to the makefile.
> 1) vg, gsvg, gpcl6vg, gxpsvg, gpdlvg
> 2) debugvg, gsdebugvg, gpcl6debugvg, gxpsdebugvg, gpdldebugvg
> Those build release and debug versions of the executables, tweaked
> to work better with valgrind. These mirror the existing *mementovg
> targets that were introduced a while ago.
> 2 extra tweaks are introduced here too.
> Firstly, *for these targets*, we default to using memory for
> bandlist storage. This should cut down on the number of false
> positives we get when using the clist as uninitialised padding
> bytes will not be flagged up as they are written to the clist
> file. (Instead, they will only be flagged up if they are actually
> used during clist playback).
> Secondly, whenever we write out a clist block and reset the buffer,
> we reset the buffer to "undefined" state so that valgrind can give
> us useful information again.
> base/gxclutil.c
> base/unix-end.mak

2017-11-17 00:22:03 +0000
Robin Watts <Robin.Watts@artifex.com>
53faf466e769bd380a14370aa38562b942e783c2

> Add clist valgrind helper call.
> base/gxcldev.h
> base/gxclimag.c
> base/gxclpath.c
> base/gxclutil.c

2019-01-14 11:34:09 +0000
Robin Watts <robin.watts@artifex.com>
1f5d4a1ce74ea841102a7c77e29c68e9b7a032c2

> Improve -Z: output messages at startup.
> The "Init done" messages given by -Z: were misleading.
> Here, we simplify the process a bit. We move the init messages
> (other than the dumping of the args used) out of -Z: and into
> --debug=init-details.
> The 3 different init messages are now explicitly done around
> each of the 3 phases, rather than in the code that calls
> those 3 phases. This makes it far clearer, as the phases can
> be called from many different places depending on the exact
> command line in use.
> The only downside to this is that only the final phase shows up
> in normal use, as the parsing of --debug=init_details doesn't
> happen until after after the first 2 phases of init have taken
> place. This is no worse than the current code, so we'll take this
> for now, and update it later (maybe by prescanning the arg list)
> if it's ever an issue later on.
> base/gdbflags.h
> psi/imain.c
> psi/imainarg.c

2019-01-11 19:24:47 -0800
Ray Johnston <ray.johnston@artifex.com>
41810035925a2dd419354e8ca918f425603e5cb4

> Bug 700482: Binary Object scanner could write past allocated ref array
> The object length (osize) was used to compute the max_array_index, but
> this exceeded the number of refs allocated based on the overall length
> given in the BOS header. We only allocated overall_length/8 but the bad
> object length value (in this case for a dict, but could be an array)
> was larger so we ended up with a max_array_index that was too large.
> psi/iscanbin.c

2019-01-10 13:48:37 +0000
Robin Watts <robin.watts@artifex.com>
deaae0d435112e2fdd9f3f7d1e8eee6e207758f1

> Squash a warning in XPS interpreter.
> xps/ghostxps.h
> xps/xpszip.c

2019-01-10 13:44:13 +0000
Robin Watts <robin.watts@artifex.com>
6236f942b0601772221a910e006c9fa865b4568e

> gpdl: Tweak stdin operation to respect gsapi set stdio functions.
> Now that gpdl lives entirely under the gsapi API, it should
> respect all that API. That means that as people can define
> callbacks to be used for stdin/stdout/stderr, we should use
> those callbacks if they are set and the program is told to
> read from stdin.
> Sadly, the only stdin stream implementation we have that supports
> this mechanism is the one in the postscript interpreter rather
> than the one in the general library, so we can't rely on it being
> there (and even if we could, it assumes the presence of an
> active PS interpreter instance).
> We therefore lift this code out and simplify it to give us a
> "callback capable" stdin stream that will be present in all our
> builds. This is NOT available using the standard iodev mechanism
> so no changes in behaviour can happen for existing programs.
> base/lib.mak
> base/strmio.c
> base/strmio.h
> pcl/pl/plmain.c

2019-01-10 21:18:08 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
4e71598a97bce38f3ba384c055d6ffb852f045fd

> Bug 697545 : Prevent SEGV when no graphic state is saved.
> Prevent SEGV if memory allocation fails leading to pgs->saved being NULL.
> Error created using :-
> MEMENTO_FAILAT=351 ./membin/gpcl6 -sDEVICE=pbmraw -dMaxBitmap=2000 -o /dev/null ./tests_private/pcl/pcl5cfts/fts.0270
> base/gsdevice.c

2019-01-10 12:19:10 -0500
Steve Phillips <steve.phillips@artifex.com>
2ae1181b33be65478db844e3a330cf31f8dee273

> Fix for bug 700042 -- Sanitize out-of-bounds read with fuzzed PDF file.
> The test file for this bug was fuzzed in such a way as to generate
> Lattice-Form Gouraud shadings with extremely large X coordinates.
> This exposed a bug in the code which performs recursive triangle
> subdivision. A color cache entry is not the same size as a
> patch_color_t so can't be copied directly.
> base/gxshade6.c

2019-01-11 14:25:29 +0100
Tor Andersson <tor.andersson@artifex.com>
24281b198d446da47441b132aba2aa09a5c27ba5

> Bug 697630: Check ZIP entry sizes for integer overflow.
> xps/xpszip.c

2019-01-09 17:55:17 +0000
Robin Watts <robin.watts@artifex.com>
1698937968690ca1ff99e50ae8c1c044718505b8

> Fix stdin operation for gpdl/gpcl etc.
> pcl/pl/plmain.c

2019-01-09 17:14:13 +0000
Robin Watts <robin.watts@artifex.com>
5b41d5347c1cde4847d8d631aa20e00a6cdb5728

> Rename xps language implementation points.
> use _impl_ instead of _imp_ to be consistent with the others.
> xps/xpstop.c

2019-01-08 18:49:38 +0000
Robin Watts <robin.watts@artifex.com>
0b89bbaf583441e84804201d2e74169b9c7be5de

> gpdl: Add -c operation to gpdl.
> We gather up all the commands specified by -c and pass them into
> the language as a 'prefix' command, to be run just after we have
> inited the job. This means they run inside the encapsulation.
> The only language that supports prefix commands is postscript,
> hence only postscript commands can be used. This is what we want.
> gpdl/psi/psitop.c
> pcl/pcl/pctop.c
> pcl/pl/pjparsei.c
> pcl/pl/plmain.c
> pcl/pl/pltop.c
> pcl/pl/pltop.h
> pcl/pxl/pxtop.c
> xps/xpstop.c

2019-01-09 17:19:22 +0000
Robin Watts <robin.watts@artifex.com>
51196c3b88bf5a865e03907c90ac891ab857f021

> Squash a type warning.
> psi/imainarg.c

2019-01-08 16:35:51 +0000
Chris Liddell <chris.liddell@artifex.com>
cb07f9786acc2faa85b1f3cce89339b65f99c310

> Bug 700460: Fix Freetype Type1 path segment closepath
> * src/psaux/psintrp.c: correctly close a contour
> All of the Type 1 path building is done with code common to the revised
> CFF engine, with the exception of closepath, which was still calling
> ps_builder_close_contour(), thus previously cached segments were not
> always written to the path, and glyph corruption, or even invalid outlines
> were possible.
> Switch to calling cf2_glyphpath_closeOpenPath()
> Committed upstream:
> http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=b75abeb5e6561024d182ccdc0eb36a7d2630310e
> freetype/src/psaux/psintrp.c

2019-01-08 14:03:28 -0800
Nancy Durgin <nancy.durgin@artifex.com>
fc8c8630f929cbbe1df01fdc3186f25193b31f75

> Undefine internal .presentspecial dictionary
> This dictionary contains a bunch of procedures that will no longer be exposed.
> Resource/Init/gs_setpd.ps

2019-01-08 11:53:33 -0800
Nancy Durgin <nancy.durgin@artifex.com>
71af04a00d1970be001d043480c07bd336453a73

> Rearrange code in gs_setpd.ps so things are defined before used.
> This is in preparation for undef'ing .presentspecial dictionary.
> I tried to keep the related code together, and I hope I moved the
> right comments with the code...
> Resource/Init/gs_setpd.ps

2019-01-08 20:05:11 +0000
Robin Watts <robin.watts@artifex.com>
06e9bde4dce776a3afa365bc65b1a1278462c865

> Fix Memento squeezing - gs_lib_ctx was using a monitor.
> Monitors don't play nice with memento squeezing, so nobble the
> code.
> base/gslibctx.c

2019-01-08 08:37:55 -0800
Nancy Durgin <nancy.durgin@artifex.com>
cae9c43ecc8eb804022d947f65d60358a7e6094a

> Rewrite some code to be able to undef internal .setpagesize
> /.setpagesize is used internally by gs_statd.ps, but it was written
> to pull the current implementation out of statusdict, so it could use
> either a level 2-compatible version that called setpagedevice, or a level 1
> version that didn't call setpagedevice.
> Since we don't support level 1 postscript anymore, we should always have
> setpagedevice, so this can be cleaned up.
> Now /.setpagesize is just an internal convenience function that we undef
> within gs_statd.ps.
> Resource/Init/gs_lev2.ps
> Resource/Init/gs_statd.ps

2019-01-07 20:03:02 -0800
Michael Vrhel <michael.vrhel@artifex.com>
6b9a0722a5e4c8083a59fd3ba22b1b572ec7fcd6

> Bug 691732 Add support for e-sRGB and ROMMRGB color spaces
> JPX images can have an enumerated color space that indicates
> e-sRGB or ROMMRGB.
> Resource/Init/gs_lev2.ps
> Resource/Init/gs_res.ps
> Resource/Init/pdf_draw.ps
> base/gsicc_manage.h
> iccprofiles/esrgb.icc
> iccprofiles/rommrgb.icc

2018-12-19 15:03:27 -0800
Ray Johnston <ray.johnston@artifex.com>
c75bd64e30d8ff890cd6495e748b30a4b0dacd32

> Bug 699180: Transparency BBox for stroke needs the expanded path.
> The simplified test case has an unusually wide line, but since the path
> is pure horizontal, pathbbox returns the same coordinate for Ymin and Ymax.
> Instead, when painting strokes, use "strokepath pathbbox" to get the actual
> area painted (taking width and miter extensions into account).
> Resource/Init/pdf_ops.ps

2018-12-23 13:02:22 -0800
Ray Johnston <ray.johnston@artifex.com>
10a630656fadb160ec3e01b934adac3e1ca600f9

> Bug 700359: Uniprint device did not set color_info.polarity needed by pdf14
> The pdf14 device assumes that if the polarity is ADDITIVE, the colorspace
> must be Gray or RGB. The uniprint device did not set the polarity when the
> colorspace was changed to CMYK, so the number of components set in the pdf14
> compositor was 3, even though the ICC profile for the device expects 4 as
> num_components in. This caused a mismatch when reading the clist because
> it expected 4 components and only 3 were written. Note that the RGBW, RGBOV,
> and RGBNOV modes will probably still fail, but unti we see a case for a device
> needing these unusual modes, just leave it as it has been for many years.
> Note that other devices with strange colorspaces, such as RGBA may also
> trip over this.
> devices/gdevupd.c

2018-12-26 13:12:39 -0800
Ray Johnston <ray.johnston@artifex.com>
905d1bf02db12aca93a732dbe5956993e19d2443

> Bug 699688: Saving pointer into arg_list string invalid (next arg overwrites)
> The 'saved_pages_inital_arg' cannot be a pointer into the argument buffer
> (arg_list.cstr) since later long arguments can overwrite past the pointer
> saved (12 characters into the buffer). Instead allocate a buffer for the
> argument and copy the argument into it.
> Thanks to Peter Cherepanov for the analysis and part of the fix.
> psi/imain.c
> psi/imainarg.c

2018-10-09 23:04:42 -0700
Ray Johnston <ray.johnston@artifex.com>
02fd67bce5cd981282594b1458c4459613559d1b

> Remove overprint_mode_alt (overprint mode is the same for stroke and fill)
> Also remove effective_overprint_mode_alt.
> base/gsstate.c
> base/gxgstate.h

2018-07-09 12:05:56 -0700
Ray Johnston <ray.johnston@artifex.com>
0c89f7d14ffdaa3080d996d7502a77f3db949381

> Fix for bug 692652: Prevent derefence of NULL if parsed.iodev == NULL
> Robin's suggestion seems reasonable to me.
> base/gsdevice.c

2018-12-17 11:18:07 +0000
Robin Watts <robin.watts@artifex.com>
e91b67894a28c518b34e0daf75d79715c4aa16e4

> Remove some blah_DEFINED cruft.
> Now we properly "include what we use" let's sanitise the horrid
> blah_DEFINED ifdeffery (i.e. kill it where possible).
> Also, we update the .c dependencies in the base/psi makefiles to
> be correct.
> Unfortunately, this new correct set of dependencies causes nmake
> to soil itself and die with an out of memory error. After much
> experimentation, I've come to the conclusion that this is because
> it copes poorly with given the same file as a dependency multiple
> times.
> Sadly, our style of declaring dependencies in the following style:
> foo_h=$(BLAH)/foo.h $(std_h)
> bar_h=$(BLAH)/bar.h $(foo_h) $(std_h)
> baz_h=$(BLAH)/baz.h $(foo_h) $(std_h)
> means that a .obj file that depends on $(foo_h) $(bar_h) and $(baz_h)
> ends up depending on foo.h twice, and std.h three times.
> I have therefore changed the style of dependencies used to be more
> standard.
> We still define:
> foo_h=$(BLAH)/foo.h
> so each .obj file rule can depend on $(foo_h) etc as required, but the
> dependencies between each .h file are expressed in normal rules at the
> end of the file in a dedicated "# Dependencies" section that we can now
> autogenerate.
> base/gdevdevn.c
> base/gdevdevn.h
> base/gdevmrop.h
> base/gdevp14.h
> base/gdevprn.h
> base/gp.h
> base/gsalloc.h
> base/gsccolor.h
> base/gscdevn.h
> base/gschar.h
> base/gscicach.h
> base/gscie.h
> base/gscms.h
> base/gscolor2.h
> base/gscolor3.h
> base/gscrdp.h
> base/gscsepr.h
> base/gscspace.h
> base/gsdcolor.h
> base/gsdevice.h
> base/gsdsrc.h
> base/gsfcmap.h
> base/gsfname.h
> base/gsfont.h
> base/gsfunc.h
> base/gsgc.h
> base/gsgcache.h
> base/gsgdata.h
> base/gsgstate.h
> base/gsht1.h
> base/gsicc_cache.h
> base/gsicc_cms.h
> base/gsimage.h
> base/gsiparam.h
> base/gslibctx.h
> base/gsmatrix.h
> base/gsmemory.h
> base/gsmemraw.h
> base/gsnamecl.h
> base/gsovrc.h
> base/gsparam.h
> base/gspath.h
> base/gspcolor.h
> base/gsptype1.h
> base/gsptype2.h
> base/gsshade.h
> base/gsstate.h
> base/gsstruct.h
> base/gstext.h
> base/gstparam.h
> base/gstrans.h
> base/gstrap.h
> base/gstype1.h
> base/gsuid.h
> base/gxalloc.h
> base/gxblend.h
> base/gxcdevn.h
> base/gxchar.h
> base/gxcid.h
> base/gxclfile.c
> base/gxclipsr.h
> base/gxclist.h
> base/gxclmem.h
> base/gxclthrd.h
> base/gxcmap.h
> base/gxcolor2.h
> base/gxcomp.h
> base/gxcpath.h
> base/gxcspace.h
> base/gxdcolor.h
> base/gxdevbuf.h
> base/gxdevcli.h
> base/gxdevmem.h
> base/gxdht.h
> base/gxdhtres.h
> base/gxdhtserial.h
> base/gxdither.h
> base/gxfapi.h
> base/gxfcache.h
> base/gxfcid.h
> base/gxfcmap.h
> base/gxfill.h
> base/gxfont.h
> base/gxfont0.h
> base/gxfont1.h
> base/gxfont42.h
> base/gxgetbit.h
> base/gxgstate.h
> base/gxhintn.h
> base/gxhldevc.h
> base/gxht.h
> base/gxhttile.h
> base/gxiclass.h
> base/gximage.h
> base/gximask.h
> base/gxiodev.h
> base/gxiparam.h
> base/gxmatrix.h
> base/gxobj.h
> base/gxpaint.h
> base/gxpath.h
> base/gxpcache.h
> base/gxpcolor.h
> base/gxrplane.h
> base/gxsample.h
> base/gxshade.h
> base/gxshade4.h
> base/gxtext.h
> base/gxttfb.h
> base/gxtype1.h
> base/gzpath.h
> base/gzspotan.h
> base/lib.mak
> base/saes.h
> base/sarc4.h
> base/scommon.h
> base/spprint.h
> base/spsdf.h
> base/srdline.h
> base/std.h
> base/strmio.h
> base/tiff.mak
> base/ttfoutl.h
> base/ttobjs.h
> base/unixinst.mak
> devices/contrib.mak
> devices/devs.mak
> devices/gdev8bcm.h
> devices/gdevbmp.h
> devices/gdevdljm.h
> devices/gdevdsp2.h
> devices/gdevfax.h
> devices/gdevmgr.h
> devices/gdevpcl.h
> devices/gdevplib.h
> devices/gdevpsd.c
> devices/gdevpsd.h
> devices/gdevpxut.h
> devices/gdevrinkj.c
> devices/gdevtfax.h
> devices/gdevxcf.c
> devices/gdevxcmp.h
> devices/gxfcopy.h
> devices/vector/gdevpdfb.h
> devices/vector/gdevpdfc.h
> devices/vector/gdevpdfg.h
> devices/vector/gdevpdfo.h
> devices/vector/gdevpdfx.h
> devices/vector/gdevpdt.h
> devices/vector/gdevpdtb.h
> devices/vector/gdevpdtf.h
> devices/vector/gdevpdti.h
> devices/vector/gdevpdts.h
> devices/vector/gdevpdtt.h
> devices/vector/gdevpdtw.h
> devices/vector/gdevpdtx.h
> devices/vector/gdevpsds.h
> devices/vector/gdevpsf.h
> devices/vector/gdevpsu.h
> devices/vector/gdevtxtw.c
> gpdl/psi/gpdlpsi.mak
> pcl/pcl/pcfontst.h
> pcl/pcl/pcl.mak
> pcl/pcl/pgstate.h
> pcl/pl/pl.mak
> pcl/pl/plchar.c
> pcl/pl/plfont.h
> pcl/pl/pltop.h
> pcl/pxl/pxfont.h
> pcl/pxl/pxstate.h
> psi/files.h
> psi/ichar1.h
> psi/icid.h
> psi/icremap.h
> psi/icstate.h
> psi/iddstack.h
> psi/idebug.h
> psi/idict.h
> psi/idparam.h
> psi/idsdata.h
> psi/ifont.h
> psi/igc.h
> psi/igstate.h
> psi/imain.h
> psi/imainarg.h
> psi/imemory.h
> psi/iminst.h
> psi/inamedef.h
> psi/inames.h
> psi/int.mak
> psi/interp.h
> psi/iplugin.h
> psi/iref.h
> psi/isave.h
> psi/iscan.h
> psi/isdata.h
> psi/istack.h
> psi/itoken.h
> psi/iutil.h
> toolbin/checkdeps.pl
> toolbin/headercompile.pl
> windows/ghostpcl.vcproj
> windows/ghostscript.vcproj

2019-01-04 17:53:58 +0000
Robin Watts <robin.watts@artifex.com>
763a5f4c3bf94cd7cc3d9fcdcde3d7cac4f38796

> Bug 696368: Avoid a garbage collection crash.
> The bulk of this analysis and patch is due to Ken.
> We can occasionally hit crashes when dealing with patterns. Ken
> tracked this down to the 'dirty' pointer in the gx_pattern_trans_t
> not being relocated in a garbage collection operation, and hence
> ending up pointing to a random address.
> His proposed fix was to change the 'dirty' pointer to be a pointer
> to the actual pdf14_buf that contained the dirty rectangle, and to
> ensure that it was properly enumerated in gc operations. This largely
> solved the issues, but left a crash.
> This crash was due to pdf14_get_buffer_information returning
> a pointer to buf, even when it closed the device and hence freed
> buf. This didn't normally affect the caller in as it never accessed
> through the pointer, but *did* trip up any garbage collection that
> happened while the pointer was extant.
> The fix is simply to only have pdf14_get_buffer_information return a
> pointer to buf iff buf will actually be around when we return.
> base/gdevp14.c
> base/gxp1fill.c
> base/gxpcmap.c
> base/gxpcolor.h

2019-01-07 09:58:36 +0000
Chris Liddell <chris.liddell@artifex.com>
2b0bfd775e43232ec488b8131b8dc014eb09d5aa

> Coverity 328396: Correctly handle use cases for register root
> There was a logical flaw in the revised iregister_root() implementation that
> meant we only handled 2 of the 3 ways of calling it correctly, the third way
> would result in a segfault.
> Also, add a comment noting those three ways of calling the API.
> base/gsalloc.c
> base/gsmemory.h

2019-01-03 09:40:01 -0800
Nancy Durgin <nancy.durgin@artifex.com>
4759b642f0f85f61949df18a43179d9cc5c9a91a

> Undef internal setpagedevice operators
> Had to delay and undef in ps_init.ps:
> /.execinstall
> Could undefine locally:
> /.postinstall
> /.copytree
> /.defaultdeviceparams
> /.makecurrentpagedevice
> Resource/Init/gs_init.ps
> Resource/Init/gs_setpd.ps

2019-01-01 18:34:45 +0000
Robin Watts <robin.watts@artifex.com>
7fe04b119618b476586e5f5b85c46d72ff05ebfc

> Add -I handling to gpdl.
> This requires an "add_path" entrypoint be added for each language
> (NULL for everything except PS).
> This causes the block of memory used for the -I path to be leaked. I
> suspect this is the same as in gs. A fix for this is a little involved
> so it'll wait for now.
> gpdl/psi/psitop.c
> pcl/pcl/pctop.c
> pcl/pl/pjparsei.c
> pcl/pl/plmain.c
> pcl/pl/pltop.c
> pcl/pl/pltop.h
> pcl/pxl/pxtop.c
> psi/psapi.c
> psi/psapi.h
> xps/xpstop.c

2019-01-03 17:07:25 +0000
Robin Watts <robin.watts@artifex.com>
2bc43397c39db60b865ca6afd14c048d9e595359

> Avoid leak of lib path blocks.
> GS keeps a lib_path postscript array with a list of directories
> in. Currently this memory is assumed to be "permanent", and is
> never freed by the system. This means that whenever we use -I
> we leak a block.
> Here, we change the system over so that we copy the different
> path components into memory blocks and free them at the end.
> This seemingly simple task is made much harder by the way that
> gs throws out some of the entries in the libpath at random
> points during execution.
> Accordingly, I have rejigged the code slightly, and introduced
> comments to explain what is going on, in the hopes that the
> next person through this code (in another 20 years) will have
> an easier time understanding the assumptions baked into it.
> psi/imain.c
> psi/imainarg.c
> psi/iminst.h

2019-01-03 15:14:25 +0000
Robin Watts <robin.watts@artifex.com>
4aadfa18ccc7fd23e3e4e0a262bcda51ef815b3f

> Bug 700438: Fix SEGV due to overflowing double->int conversion.
> Thanks to Ken for doing most of the investigation on this.
> The problem is that we have a double value of 5e9 that won't fit
> into an int (and becomes INT_MIN). This huge negative value is then
> added to a pointer and we access out of range.
> The fix is simply to check for our double values being representable
> as ints before we proceed - if not we throw a rangecheck. This is
> reasonable as it corresponds to an image being positioned stupidly
> far off the page.
> The complication with this commit comes in that it collides with
> some very suspect old fixes for Bugs 686843 and 687411. The patch
> for 686843 makes the same change in 2 places in the code. It looks
> like 687411 is reported as the same issue, but the fix for it appears
> to be reverting one of the fixes for 686843 - I suspect that the
> patch was reversed.
> Given that we can't reproduce the original problems that these bugs
> were trying to solve any more, I am reverting the code to a saner
> form. If the problems recurr, we can reexamine then.
> base/gximag3x.c
> base/gximage3.c

2019-01-02 14:43:58 -0800
Nancy Durgin <nancy.durgin@artifex.com>
5a1b7b9e67f5b9827338fe65881608c530a89a35

> Remove remaining ImageType 2 support, which is now dead code
> ImageType 2 was only used for display postscript.
> Made make_upath() static, since it is now only used locally by zupath.
> base/gsiparm2.h
> base/gximage2.c
> base/gxiparam.h
> base/lib.mak
> devices/gdevx.c
> psi/zupath.c
> windows/ghostscript.vcproj
> windows/ghostscript_rt.vcxproj

2018-11-18 14:45:00 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
486f3b4a677180bbef2553114bf13916c76e1884

> Bug 697545: Update gx_image_enum_begin to correctly handle error returns.
> base/gxi12bit.c
> base/gxiclass.h
> base/gxicolor.c
> base/gxifast.c
> base/gximono.c
> base/gxipixel.c
> base/gxiscale.c

2019-01-02 11:34:52 -0800
Nancy Durgin <nancy.durgin@artifex.com>
0b3e0befdc87323eb518d6233c5fcdf5e006e6dc

> Removed has_alpha flag from postscript high-level image functions
> The flag was only set to 'true' by the .alphaimage operator, which was
> only used by display postscript and has now been removed.
> All other callers passed hard-coded 'false', so the argument is now
> extraneous.
> psi/iimage.h
> psi/zimage.c
> psi/zimage3.c
> psi/ztrans.c

2019-01-02 11:54:21 +0000
Robin Watts <robin.watts@artifex.com>
42646d6c9e264d8f8c34e5e32cde3e02ff83b87d

> Pull in fixes from lcms2mt repo.
> (This pulls in the latest fixes from mainline lcms2 too).
> lcms2mt/README.1ST
> lcms2mt/src/cmsopt.c
> lcms2mt/src/cmsxform.c
> lcms2mt/src/lcms2_internal.h

2019-01-02 10:02:28 +0000
Ken Sharp <ken.sharp@artifex.com>
ef075a44f37f89dcbff03bf0bdcc7e7b6fe17c15

> Address compiler warnings
> Remove unused variables (x4)
> Add include files to fix 'implicit declaration' warnings (x2)
> Rewrite a (now) misleading comment.
> base/gdevmpla.c
> base/gscspace.c
> devices/gdevpsd.c
> devices/vector/gdevpdft.c
> psi/zfont1.c

2019-01-01 13:27:45 +0000
Robin Watts <robin.watts@artifex.com>
11fb2c3140b33f88056d5009b62a98f4ad921109

> Fix gpdl --disable-compile-inits build.
> Silly typos were preventing chunks 1,2,3 of the romfs being
> built.
> base/lib.mak

2018-12-29 09:54:09 -0800
Michael Vrhel <michael.vrhel@artifex.com>
416a5ebe1f7435f6dc8894576f40a8f247ed386c

> Bug 688210: Add psdcmyk16 and psdrgb16 devices
> So the patch that was provided was far from sufficient in making this
> work. There was significant work that needed to be done in the
> pdf14 device to ensure that the transparency put_image operation
> worked correctly. Not sure if the author was paid a bounty but I
> question if it was properly tested.
> I tested this with some extreme altona files and others and
> everything seems to be working well now. Having the psdcmyk16 device
> is nice as it is our only device to have full spot color support and
> 16 bit output precision.
> base/gdevmpla.c
> base/gdevp14.c
> base/gxblend.h
> base/gxblend1.c
> base/lib.mak
> base/unix-gcc.mak
> base/unixansi.mak
> configure.ac
> devices/devs.mak
> devices/gdevpsd.c
> devices/gdevpsd.h
> doc/Devices.htm
> psi/msvc.mak

2018-12-28 14:55:14 +0000
Ken Sharp <ken.sharp@artifex.com>
bfecb45e881eee39b2159873b1954f911dcb7fa3

> Coverity ID 328395 - check return from ref_stack_push
> psi/zdevice.c

2018-12-17 20:16:27 +0000
Robin Watts <robin.watts@artifex.com>
1a61ba8825e80bbd779192950d61474fb7581a26

> Remove "device filter stack" as it is long unused.
> base/gdevsclass.c
> base/gsdfilt.c
> base/gsdfilt.h
> base/gxgstate.h
> windows/ghostscript.vcproj

2018-12-19 09:47:55 -0800
Nancy Durgin <nancy.durgin@artifex.com>
264e3cd12621d8270af08ab645a8aaf2b1b00f7e

> Undefine internal functions in gs_dps2.ps
> (Note that despite the name, this isn't really display postscript)
> .UserObjects
> .fixcurrenthalftonescreen
> .makehalftoneRGBV
> .fixsethalftonescreen
> .makestackdict
> Resource/Init/gs_dps2.ps

2018-12-20 16:09:26 +0000
Ken Sharp <ken.sharp@artifex.com>
48008d0fbcdb26f1deac44f47eb6b0551e4ea17e

> pdfwrite/PDF interpreter/transparency - identify page level groups
> Bug #700376 "Color change after reprocessing PDF with Ghostscript"
> The problem here lies in identifying the difference between a /Group
> entry in the Page dictionary, and a Group encountered as part of an
> operation during the course of a Page content stream.
> To the rendering code, there is no difference, but pdfwrite needs to
> be able to identify Page level groups so that it can attach them to the
> Page dictionary when it writes them out.
> Previously we've been doing this by detecting the fact that we haven't
> started writing anything to the page stream. However, this is simply
> not good enough, in the case of this bug report, the first thing that
> happens is the file runs a form, which has a Group. Because we haven't
> written anything to the page yet, we think its a page level Group and
> emit it as such.
> The problem is that in the original, we had set a constant alpha of
> 0.55. When we run the form that is self-contained and uses an alpha of
> 1, but because its in a form, the result of rendering the form is
> composited with the page so far (currently nothing) with teh result that
> the form contents are drawn 50% opaque.
> When we come to handle this in pdfwrite, the fact that we think the
> Group for the Form is at the page level causes us to write the Form
> content stream in the page (and the Group for the Form is also put
> in the Page dictionary), and we fail to emit a constant alpha, because
> the form resets it to 1 before executing any marks. That means we
> 'optimise out' the change to 0.55 and the form is drawn 100% opaque.
> This commit introduces a new transparency compositor operation
> 'PDF14_BEGIN_TRANS_PAGE_GROUP', the rendering code has been modified
> to treat this as exactly equivalent to a 'PDF14_BEGIN_TRANS_GROUP' so
> that there are no rendering differences.
> The pdfwrite device, however, can use it to identify with certainty
> that a given Group is at the Page level and treat it specially.
> This results in 5 files in the test suite showing progressions, mostly
> subtle, but one quite marked difference. The files are:
> Altona_Technical_v20_x4.pdf, Bug691783.pdf, Bug691982.pdf, CATX3146.pdf,
> x_-_no_compression_bomb.pdf
> *only* when processed through the pdfwrite device.
> Resource/Init/pdf_draw.ps
> Resource/Init/pdf_main.ps
> base/gdevp14.c
> base/gstrans.c
> base/gstrans.h
> devices/vector/gdevpdft.c
> psi/ztrans.c
> xps/xpsgradient.c
> xps/xpsimage.c
> xps/xpsopacity.c

2018-12-19 10:09:24 -0800
Nancy Durgin <nancy.durgin@artifex.com>
16b7aba969bc1d607d80ddab5c8d2430bd36b6a0

> Remove iimage2.h, zimage2.c (dead code after dps removal)
> Remove all the references to these files.
> doc/Develop.htm
> psi/iimage2.h
> psi/int.mak
> psi/zimage2.c
> windows/ghostscript.vcproj
> windows/ghostscript_rt.vcxproj

2018-12-19 10:32:40 -0800
Nancy Durgin <nancy.durgin@artifex.com>
fa1c24756797e43dd63d5318c961baf5f99e2428

> Cleanup from no-longer-existing .alphaimage operator
> Remove <has_alpha> parameter and handling from .colorimage
> Remove references to .alphaimage from comments and stuff
> Resource/Init/gs_img.ps

2018-12-19 08:53:32 -0800
Michael Vrhel <michael.vrhel@artifex.com>
0466d01e1677c8a4a8e57a191710842c844e5ad4

> Bug 698828: Change of TRC in default_gray.icc
> Reviewing this bug revealed that out default_gray.icc profile had a gamma
> of 1.8. The proper gamma should be the same as that used by default_rgb.icc
> which has the sRGB color space TRC. This commit fixes the issue. Unfortunately
> this is going to cause a huge number of changed files.
> iccprofiles/default_gray.icc

2018-12-18 14:24:34 -0800
Nancy Durgin <nancy.durgin@artifex.com>
3c58541e2dff52bf9d481f7cd385386716e2bdd5

> Remove Display Postscript-related cooperative multitasking code and state
> The code this was supporting was in zcontext.c, which has already been
> deleted.
> psi/icontext.c
> psi/icstate.h
> psi/interp.c
> psi/oper.h

2018-12-13 08:57:50 -0800
Nancy Durgin <nancy.durgin@artifex.com>
cc156631163eb9c156e0863387def7368abe5a8b

> Change zmisc.c implementation of usertime to start at 0
> The Display Postscript implementation in zcontext.c always returns 0
> the first time 'usertime' is called, and counts time from there.
> Since that implementation is going away, change the one in zmisc.c to
> behave the same way. It used to return a value based on the time since the
> process started, which would be variable depending on the implementation.
> Both implementations increment based on time spent processing.
> This change causes vasarely.ps to run the same with and without dps.
> psi/icontext.c
> psi/icstate.h
> psi/zmisc.c

2018-12-12 07:43:13 -0800
Nancy Durgin <nancy.durgin@artifex.com>
0d04beddf3f2b5f5eac46f2ae9d5ab0452e38ada

> Removing display postscript and NeXT dps operators.
> This only removes operators that are DPS only. They are marked with
> a "DPS" in the PLRM. Also removes related internal operators.
> (gs_img.ps) Remove img_utils_dict
> Dependency on gs_dps.ps is gone. Can just define the utility funcs for use
> and then just undef them at end.
> (gs_init.ps)
> Don't need to undef dps operators anymore, because they won't be defined
> (pdf_draw.ps)
> Change PDF implementation to call .setscreenphase directly
> This used to call it via the dps operator 'sethalftonephase', but that
> is going away, so just make .setscreenphase be part of the pdf
> implementation directly.
> Also move implementation of .setscreenphase to zpdfops.c
> (gs_cet.ps)
> No longer need to undef 'deviceinfo' for CET because it won't be defined
> (gs_btokn.ps)
> Replace the DPS operators in .installsystemnames with placeholders
> Keeps the length/values in the array the same, just removing dps operators.
> (icontext.c)
> Needed to modify the no_reschedule() proc to return 0 instead
> of an error. I think we can delete a ton of related code, in future commit,
> because the code handling the time_slice_proc and reschedule_proc should
> no longer be needed.
> (lots of changes)
> Delete dps-related source files, update makefiles and other files that
> reference the deleted files.
> Makefile.in
> Resource/Init/gs_cet.ps
> Resource/Init/gs_dpnxt.ps
> Resource/Init/gs_dps.ps
> Resource/Init/gs_img.ps
> Resource/Init/gs_init.ps
> Resource/Init/pdf_draw.ps
> base/gs.mak
> base/gsdpnext.h
> base/gsdps.c
> base/gsdps.h
> base/lib.mak
> base/openvms.mak
> base/openvms.mmk
> base/unix-gcc.mak
> base/unixansi.mak
> gpdl/pspcl6_gcc.mak
> gpdl/pspcl6_msvc.mak
> psi/icontext.c
> psi/int.mak
> psi/msvc.mak
> psi/os2.mak
> psi/psromfs.mak
> psi/zcontext.c
> psi/zdpnext.c
> psi/zdps.c
> psi/zpdfops.c
> toolbin/pre.chk
> toolbin/pre.tcl
> windows/ghostscript.vcproj
> windows/ghostscript_rt.vcxproj

2018-12-18 11:41:35 -0800
Michael Vrhel <michael.vrhel@artifex.com>
164c0da6464b3c9da4923ca4827616a85f0f95a9

> Bug 699152: gen ordered screen generation
> Fix typo in output formatting and clean up a few warnings.
> base/gen_ordered.c
> toolbin/halftone/gen_ordered/gen_ordered_main.c

2018-12-18 09:34:11 -0800
Michael Vrhel <michael.vrhel@artifex.com>
83224c6384cebe4d7463d7b3d7c240c52ca9030b

> Bug 700383: Add support for scRGB
> XPS files can define RGB colors with things like
> Fill="sc#1, 0.0231533665, 0.08021982, 0.226965874"
> This implies that the color space is not sRGB (the standard default in XPS)
> but rather scRGB which shares the primaries of sRGB but has a gamma of 1.0.
> Lots of progressions in the XPS files expected with this commit.
> base/gscspace.c
> base/gscspace.h
> base/gsicc_manage.c
> base/gsicc_manage.h
> base/lib.mak
> iccprofiles/scrgb.icc
> xps/xpstop.c

2018-12-18 10:25:59 +0000
Ken Sharp <ken.sharp@artifex.com>
0996199c8607807f423ebf67d576482f8f2bbadb

> XPS interpreter - remove special case for artificial bold with pdfwrite
> Bug #700382 "Synthetic bold generation too heav"
> There was special case code for handling artificially emboldended text
> in xps_flush_text_buffer, when the output device could directly handle
> text rendering mode 2 (fill and stroke). This was because the pdfwrite
> device, the only device capable of handling this mode, did some nasty
> trickery with the CTM.
> At some point this trickery has been removed, probably as a result of
> the ongoing work to handle stroke+fill as a graphics primitive. The
> result is that the hackery is no longer required, and in fact causes
> the stroke width to be incorrectly calculated, because we are trying to
> reverse a later calculation with the CTM, which is no longer applied.
> So simply remove the whole section of code. This shows a very few
> differences in the test suite, all at low resolution (72 dpi) where
> text is slightly bolder, these appear to be (very minor)
> progressions.
> xps/xpsglyphs.c

2018-12-15 15:19:14 +0000
Ken Sharp <ken.sharp@artifex.com>
2183d4712847901ddf46989e07bdc4dd94a1197f

> pdfwrite - improve h/vmtx table generation for embedded TrueType fonts
> Bug 700099 " glyph spacing changed after going through pdfwrite"
> This is a difficult one to explain. The primary problem is that the
> original PostScript contains multiple EPS files, which contain multiple
> embedded subsets of the same font, but all with the same name.
> Because these subsets are small, they appear to pdfwrite to be the same
> font, the checks we use to check the font do not test every possible
> characteristic, because that would be slow.
> Now this is not a problem, except that for bug #697376 we did an ugly
> hack.
> The generation of embedded TrueType fonts badly needs rewritten. Currently
> we copy some tables, copy and amend other tables, and generate some tables
> from scratch. This has led to numerous problems, on and off.
> In the case of bug 697376, we were only writing the hmtx table with
> exactly as many metrics as the actual glyphs we put in the output file,
> and patched the hhea tale so that it had the correct number of
> hLongMetrics entries. But the spec says that every glyph (even those
> which are empty in the glyf table!) must have a lsb entry. So Acrobat
> Distiller threw an error on encountering our font.
> This was solved by copying the hmtx table instead of generating it. Fine
> as far as it goes, but in this case we have hit the problem where we are
> using glyphs from two different fonts. The hmtx table from the first font
> has the wrong metrics for the glyphs in the second font, which leads to
> spacing errors.
> The only possible solution, until we can find time to rewrite all of this
> is to 'pad out' the hmtx table with lsb entries for the glyphs which are
> present in the glyf table, but not actually used.
> I have a sneaky suspicion that this is still incorrect, we should be
> writing the metrics at the correct place (GID) in the table, instead
> of as a block, but this works well enough for now.
> devices/vector/gdevpsft.c

2018-12-14 13:04:04 -0800
Michael Vrhel <michael.vrhel@artifex.com>
6bcf3eb2fd2bca68eef17a8cfcbf272e22d647d1

> Bug 698721 Overprint mode getting used during shading pattern
> base/gscspace.c
> base/gsstate.c

2018-12-14 09:31:45 -0800
Michael Vrhel <michael.vrhel@artifex.com>
7a9359b06801cea8a7a3c4469c1e7f31564a962c

> Add missing index update in pdf14 buffer debug
> base/gdevp14.c

2018-12-12 12:48:39 +0000
Robin Watts <robin.watts@artifex.com>
085c795835284d2f0d91ebc87faf5b2da1376bca

> Fix header inclusions.
> Run a release build on a linux machine to make arch.h etc. Then
> run toolbin/headercompile.pl to test compiling each headerfile
> by itself.
> Resolve all the missing #includes, add missing repeated include
> guards and copyright statements.
> Also, update all the header dependencies in the makefiles.
> It is possible that the object dependencies in the makefiles can be
> simplified now, but that's a task for another day.
> base/ets.h
> base/ets_tm.h
> base/gdbflags.h
> base/gdebug.h
> base/gdevbbox.h
> base/gdevdcrd.h
> base/gdevddrw.h
> base/gdevdevn.h
> base/gdevdevnprn.h
> base/gdevmem.h
> base/gdevmpla.h
> base/gdevmplt.h
> base/gdevmrop.h
> base/gdevp14.h
> base/gdevpccm.h
> base/gdevplnx.h
> base/gdevppla.h
> base/gdevprn.c
> base/gen_ordered.h
> base/gp_mswin.h
> base/gp_os2.h
> base/gpcheck.h
> base/gpmisc.h
> base/gs.mak
> base/gsalloc.h
> base/gsalpha.h
> base/gsalphac.c
> base/gsalphac.h
> base/gsargs.h
> base/gsbitops.h
> base/gsbittab.h
> base/gsccode.h
> base/gscedata.h
> base/gschar.h
> base/gscie.h
> base/gsclipsr.h
> base/gscms.h
> base/gscolor.h
> base/gscolor1.h
> base/gscolor3.h
> base/gscompt.h
> base/gscoord.h
> base/gscpixel.h
> base/gscrypt1.h
> base/gscspace.h
> base/gsdevice.h
> base/gsdfilt.h
> base/gsdll.h
> base/gsdllwin.h
> base/gsdps.h
> base/gsequivc.h
> base/gsexit.h
> base/gsflip.h
> base/gsfname.h
> base/gsfont.h
> base/gsform1.h
> base/gsfunc.h
> base/gsgc.h
> base/gsgcache.h
> base/gsgstate.h
> base/gshsb.h
> base/gsht.h
> base/gshtx.h
> base/gsicc_cache.h
> base/gsicc_profilecache.h
> base/gsimage.h
> base/gsiparm2.h
> base/gslib.h
> base/gsline.h
> base/gsmatrix.h
> base/gsmchunk.h
> base/gsmemory.h
> base/gsnamecl.h
> base/gsovrc.h
> base/gspaint.h
> base/gsparamx.h
> base/gspath.h
> base/gspath2.h
> base/gspcolor.h
> base/gsrect.h
> base/gsrefct.h
> base/gsrop.h
> base/gsroprun1.h
> base/gsroprun24.h
> base/gsroprun8.h
> base/gsropt.h
> base/gsserial.h
> base/gsstate.h
> base/gsstrl.h
> base/gstext.h
> base/gstiffio.h
> base/gstype1.h
> base/gstypes.h
> base/gsuid.h
> base/gsutil.h
> base/gsxfont.h
> base/gx.h
> base/gxband.h
> base/gxbitfmt.h
> base/gxcdevn.h
> base/gxchrout.h
> base/gxcindex.h
> base/gxclip.h
> base/gxclpath.h
> base/gxclthrd.h
> base/gxcmap.h
> base/gxcomp.h
> base/gxcoord.h
> base/gxcpath.h
> base/gxctable.h
> base/gxdcconv.h
> base/gxdcolor.h
> base/gxdda.h
> base/gxdevbuf.h
> base/gxdevcli.h
> base/gxdevmem.h
> base/gxdevndi.h
> base/gxdevrop.h
> base/gxdevsop.h
> base/gxdht.h
> base/gxdhtserial.h
> base/gxdither.h
> base/gxdtfill.h
> base/gxfapi.h
> base/gxfarith.h
> base/gxfcache.h
> base/gxfill.h
> base/gxfillsl.h
> base/gxfilltr.h
> base/gxfillts.h
> base/gxfixed.h
> base/gxfont0.h
> base/gxfont1.h
> base/gxfont42.h
> base/gxgetbit.h
> base/gxgstate.h
> base/gxhintn.h
> base/gxhldevc.h
> base/gxht_thresh.h
> base/gxhttile.h
> base/gxiclass.h
> base/gxiscale.c
> base/gxmatrix.h
> base/gxmclip.h
> base/gxobj.h
> base/gxoprect.h
> base/gxp1impl.h
> base/gxpaint.h
> base/gxpath.h
> base/gxpcache.h
> base/gxsample.h
> base/gxsamplp.h
> base/gxshade4.h
> base/gxstate.h
> base/gxttf.h
> base/gxttfb.h
> base/gxtype1.h
> base/gxxfont.h
> base/gzht.h
> base/gzline.h
> base/jmemcust.c
> base/jmemcust.h
> base/lib.mak
> base/pcwin.mak
> base/sa85d.h
> base/sbcp.h
> base/sbtx.h
> base/scanchar.h
> base/sdcparam.h
> base/sdct.h
> base/sfilter.h
> base/simscale.h
> base/sisparam.h
> base/sjpeg.h
> base/sjpegc.c
> base/slzwx.h
> base/smd5.h
> base/smtf.h
> base/spdiffx.h
> base/spngpx.h
> base/spprint.h
> base/spwgx.h
> base/srdline.h
> base/srlx.h
> base/ssha2.h
> base/sstring.h
> base/strmio.h
> base/szlibx.h
> base/tiff.mak
> base/ttfinp.h
> base/ttfsfnt.h
> base/ttload.h
> base/ttobjs.h
> base/tttype.h
> devices/devs.mak
> devices/gdevxalt.c
> pcl/pcl/pcstate.h
> pcl/pcl/pgstate.h
> pcl/pl/plchar.c
> pcl/pl/pldraw.h
> pcl/pl/plht.c
> pcl/pl/plmain.h
> pcl/pxl/pxgstate.h
> psi/bfont.h
> psi/btoken.h
> psi/dscparse.h
> psi/dwdll.h
> psi/dwimg.h
> psi/files.h
> psi/ibnum.h
> psi/ichar.h
> psi/ichar1.h
> psi/icharout.h
> psi/icid.h
> psi/icie.h
> psi/icolor.h
> psi/iconf.h
> psi/icremap.h
> psi/icsmap.h
> psi/icstate.h
> psi/iddstack.h
> psi/idebug.h
> psi/idicttpl.h
> psi/idisp.h
> psi/idosave.h
> psi/idparam.h
> psi/ifcid.h
> psi/ifilter2.h
> psi/ifont.h
> psi/ifont1.h
> psi/ifont2.h
> psi/ifont42.h
> psi/ifrpred.h
> psi/ifunc.h
> psi/ifwpred.h
> psi/igc.h
> psi/igcstr.h
> psi/iht.h
> psi/iimage.h
> psi/iimage2.h
> psi/iinit.h
> psi/ilevel.h
> psi/imain.h
> psi/imainarg.h
> psi/imemory.h
> psi/iminst.h
> psi/inames.h
> psi/inamestr.h
> psi/int.mak
> psi/interp.h
> psi/iparam.h
> psi/iparray.h
> psi/ipcolor.h
> psi/isave.h
> psi/iscan.h
> psi/iscanbin.h
> psi/iscannum.h
> psi/isdata.h
> psi/isstate.h
> psi/istkparm.h
> psi/istream.h
> psi/istruct.h
> psi/itoken.h
> psi/iutil.h
> psi/iutil2.h
> psi/ivmem2.h
> psi/ivmspace.h
> psi/oparc.h
> psi/opcheck.h
> psi/opdef.h
> psi/opextern.h
> psi/winint.mak
> psi/zchar42.h
> psi/zcie.h
> psi/zcolor.h
> psi/zfile.h
> psi/zfrsd.h
> psi/zfunc.h
> psi/zicc.h
> toolbin/headercompile.pl
> windows/ghostscript.vcproj

2018-12-14 10:38:19 +0000
Ken Sharp <ken.sharp@artifex.com>
9d23c4d9a6c02416341992d8b29226273df07af8

> PDF interpreter - preserve stroke colour/space round SMask
> Bug #699179 " Chart lines rendered as black when converting from pdf to png or jpg"
> Michael ran the problem down to the fact that the stroke colour space
> is set before an ExtGState with a Group which has an SMask. The colour
> space before the SMask is an ICCBased space and afterwards it is
> DeviceGray.
> The SMask itself has a Group and that group is defined by a Form XObject
> which has (yet another) Group. This Group is defined as having a
> DeviceGray space. The problem is that when we executed a SMask in the
> interpreter, we saved the fill colour space and values and restored
> them at the end (we can't simply use gsave/grestore), but we did not
> preserve the stroke colour space and colourants.
> This commit saves that as well. This results in a progression with
> pdfwrite with one file and three other files showing subtle progressions
> with all devices (586_-_missing_images_gs_SMask_not_applied.pdf,
> fireworks_with_radial_shading.pdf, x_-_recursive_xobjects_cause_crash.pdf)
> Resource/Init/pdf_draw.ps

2018-12-14 08:44:36 +0000
Chris Liddell <chris.liddell@artifex.com>
c7b69c7799c32ec3e895f2053bb6c4a5e2ceb340

> Fix array index typo for resolution (-r) parameter
> psi/imainarg.c

2018-12-13 16:06:46 +0000
Chris Liddell <chris.liddell@artifex.com>
0a6cf27a94f14234b4edad6d8af851a6ba7144c0

> Bug 700361: Explicitly setup color fields in txtwrite
> Because txtwrite just uses the default implementations for sampled images
> and masks, we want to setup various color related data on initialisation.
> This just means setting separable_and_linear appropriately and calling
> set_linear_color_bits_mask_shift().
> Prevents a divide by zero when trying to use the values from
> dev->color_info.comp_bits
> devices/vector/gdevtxtw.c

2018-12-11 12:26:12 +0000
Chris Liddell <chris.liddell@artifex.com>
3e4d8a0ab793ddd889acbcd2a521cfe5a30e5525

> Add product, copyright and version info to Windows binaries
> This appears in the Windows Explorer: Properties -> Details dialogue.
> base/gscdef.c
> base/gscdefs.h
> psi/dwmain.rc
> psi/gsdll32.rc
> psi/winint.mak

2018-12-03 15:06:12 +0000
Chris Liddell <chris.liddell@artifex.com>
218180b6d38a4641807775c032d8774c165a7657

> Add checks for multiple master validity
> Validate multiple master fonts at definefont time - this saves checking each
> item multiple as we pass them into Freetype (or other font scaler library).
> psi/zfapi.c
> psi/zfont1.c

2018-12-03 14:59:55 +0000
Chris Liddell <chris.liddell@artifex.com>
85bb44261edbf10552a09c839decc669f63a8142

> Add an "r_is_number()" macro
> By moving the t_integer and t_real enum values to consecutive positions,
> starting on a multiple of 2, we can check for a "number" type in a single step.
> Useful for values specced as reals, but which may be integer values, and thus
> parsed into integer objects. This means validation can be a single check,
> rather than checking for real and integer individually.
> Also use the macro in various places.
> psi/iref.h
> psi/zcolor.c
> psi/zfunc.c

2018-11-29 14:03:46 -0800
Nancy Durgin <nancy.durgin@artifex.com>
e280984683a5ca0f2d496a93d0333b4a89ab7f42

> Undef internal funcs in gs_setpd.ps
> Had to rearrange the order of functions, so there are quite a few diffs from that.
> /.selectmedia
> /.computemediasize
> /.prepareparams
> /.trysetparams
> /.installpagedevice
> (couldn't undef .uninstallpagedevice because it is called from C code)
> Resource/Init/gs_setpd.ps

2018-12-12 16:01:29 +0000
Robin Watts <robin.watts@artifex.com>
25205fe4aa9d6dc70dd20da8a2ca5e659823bb0c

> Update clusterpush.pl
> toolbin/localcluster/clusterpush.pl

2018-12-02 15:55:55 +0000
Robin Watts <Robin.Watts@artifex.com>
a44306a2ed48b3cee8e5246e6db0300eb8113c0d

> Improve Claptrap headers.
> base/claptrap-impl.h
> base/claptrap.h

2018-12-11 09:01:26 +0000
Ken Sharp <ken.sharp@artifex.com>
134b38ac7b8587c9b4bb080b34473ea5e67d48d7

> remove unused variable to silence compiler warning
> base/gsicc_lcms2mt.c

2018-12-11 09:00:02 +0000
Ken Sharp <ken.sharp@artifex.com>
c6451b921ec9f7bab14977552321a12f6f2a87b8

> Add parentheses to silence a compiler warning
> base/gdevsclass.c

2018-12-08 07:24:43 -0800
Michael Vrhel <michael.vrhel@artifex.com>
3efb86d5d75240b04bed497426cec3dbef36c304

> Bug 699305 Softmask with knockout non-isolated group
> We were not considering the softmask for the shape when
> doing group composition
> base/gxblend.c

2018-12-08 14:51:51 +0000
Ken Sharp <ken.sharp@artifex.com>
68b052d0d704037369352eb3692eb9792361fc81

> PDF interpreter - Improve T42 CharStrings creation for non-symbolic fonts
> Bug #700158 "ghostscript produces incorrect JPG if SubsetFonts=false"
> The problem is not in fact a problem with the pdfwrite device, it is
> in fact the poorly documented way that Acrobat deals with TrueType
> fonts, the symbolic/non-symbolic flags and Encodings.
> When the font has a 3,1 CMAP subtable we use a number of sources of data
> to try and build a CharStrings dictionary, which we use to map a glyph
> name to a glyph ID:
> Encoding CharStrings
> character code --------> glyph name -----------> glyh ID
> However when the font has no 3,1 CMAP subtable the specification says
> we should try to use a 1,0 CMAP instead. For 1,0 tables we were not
> using the 'prebuilt_encoding' to generate the CharStrins, which meant
> that we making less use of information than we might, and some glyphs
> were replaced by the /.notdef when rendering.
> This commit adds the prebuilt_encoding to the sources of information
> we use to generate Charstrings when using a 1,0 CMAP subtable.
> This fixes the problem, and shows a progression with one file in our
> test suite.
> Resource/Init/gs_ttf.ps

2018-12-07 11:33:18 -0800
Michael Vrhel <michael.vrhel@artifex.com>
78af4f91e7a5958acab262f3e90b5ce2a0768562

> Add a profile for a particular RGB color space
> iccprofiles/a98.icc

2017-11-17 15:17:03 +0000
Chris Liddell <chris.liddell@artifex.com>
abb742af3affbe00da625a1272d682ac5fd4c964

> Commit of gpdl-shared-device branch.
> This commit is a squashed version of the gpdl-shared-device
> branch. Essentially this is a first version of the new
> language switching mechanism.
> This does not build as part as "all", but rather as "experimental"
> or "gpdl".
> Resource/Init/gs_cet.ps
> Resource/Init/gs_init.ps
> base/gp_mspol.c
> base/gs.mak
> base/gsalloc.c
> base/gsdevice.c
> base/gsiodev.c
> base/gsiodevs.c
> base/gslibctx.c
> base/gslibctx.h
> base/gsmalloc.c
> base/gsmalloc.h
> base/gsmchunk.c
> base/gsmemory.c
> base/gsmemory.h
> base/gsmemret.c
> base/gsstate.c
> base/gsutil.c
> base/gxdownscale.c
> base/gxdownscale.h
> configure.ac
> devices/devs.mak
> devices/gdevchameleon.c
> gpdl/psi/psitop.c
> pcl/pcl/pctop.c
> pcl/pl/pjparsei.c
> pcl/pl/pl.mak
> pcl/pl/plapi.c
> pcl/pl/plapi.h
> pcl/pl/plmain.c
> pcl/pl/plmain.h
> pcl/pl/pltop.c
> pcl/pl/pltop.h
> pcl/pl/plwmainc.c
> pcl/pl/realmain.c
> pcl/pxl/pxtop.c
> psi/dwdll.h
> psi/dwnodll.c
> psi/gsdll2.def
> psi/gsdll32.def
> psi/gsdll32metro.def
> psi/gsdll64.def
> psi/gsdll64metro.def
> psi/gsdllARM32metro.def
> psi/ialloc.c
> psi/iapi.c
> psi/iapi.h
> psi/icstate.h
> psi/igc.c
> psi/imain.c
> psi/imain.h
> psi/imainarg.c
> psi/imainarg.h
> psi/imemory.h
> psi/iminst.h
> psi/int.mak
> psi/interp.c
> psi/ireclaim.c
> psi/msvc.mak
> psi/opextern.h
> psi/psapi.c
> psi/psapi.h
> psi/zdevice.c
> psi/zfont.c
> psi/ziodevsc.c
> windows/ghostscript.vcproj
> xps/xpstop.c

2018-12-07 18:53:59 +0000
Ken Sharp <ken.sharp@artifex.com>
eab61428b3fa1e4078e71febefe406dad499814e

> txtwrite - allow some slop in zero-width detection
> Bug #700322 " Endless loop when converting pdf to text "
> While trying to fit text (text format 2 or 3) we do some heuristic
> juggling to decide whether or not to use a calculated minimum size.
> During this we check to see whether the width is zero, and if it is
> we don't try to use it because it would result in an infinite loop.
> We actually need to allow a little 'slop' around zero, in case floating
> point errors result in a very small, but not quite zero, width.
> The loop resuling in the bug isn't endless, but it is very lengthy.
> devices/vector/gdevtxtw.c

2018-12-05 10:40:43 -0800
Ray Johnston <ray.johnston@artifex.com>
74723f099067f6b14f61f0cbf816c0b8536931a2

> Improve gx_get_bits_copy determination of depth.
> For devices that are separable, (GX_CINFO_SEP_LIN), it is better to use
> the comp_bits to determine the depth of a plane. Seen with the display
> device in spot color mode where dest_depth calculation from the depth
> divided by num_components is not correct.
> base/gdevdgbr.c

2018-12-04 21:31:31 +0000
Ken Sharp <ken.sharp@artifex.com>
fae21f1668d2b44b18b84cf0923a1d5f3008a696

> subclassing devices - fix put_image method
> The subclassing devices need to change the 'memory device' parameter to
> be the child device, when its the same as the subclassing device.
> Otherwise we end up trying to access the child device's memory pointers
> in the subclassing device, which may not contain valid copies of
> those pointers.
> base/gdevsclass.c

2018-12-03 14:40:37 +0000
Ken Sharp <ken.sharp@artifex.com>
2e68cc460dbe349f68b81082ff7344db48eb4820

> pdfwrite - don't try and apply transfer functions when converting colours
> Bug #700052 "pdfwrite device grayscale conversion looses significant quality on gradients
> The problem is that the file contains considerable spurious (ie has no
> effect) transparency operatiosns. in this particular case a number of
> objects are drawn with an SMask and the SMask uses a transfer function
> to invert the single component colour space (The gray objects are in
> fact described in a DeviceN [/Black] colour space, presumabkly to
> still further pointlessly increase teh complexity).
> When converting colour space we were altering the transfer function
> from 'Presever' to 'Apply', but we can't actually apply the transfer
> function to the SMask in this case.
> So leave this as 'preserve for now', note that transfer functions are
> deprecated, and not permitted in PDF 2.0.
> devices/vector/gdevpdfp.c

2018-12-01 10:04:09 +0000
Ken Sharp <ken.sharp@artifex.com>
86ed59a3b47bc4b57fbd9c76681558c300d1471b

> pdfwrite - conform to Acrobat limitations for PDF 1.4 to conform to PDF/A-1
> Never noticed before, but PDF/A-1 mandates sticking to the architectural
> limits of Acrobat described in the PDF 1.4 specification (Note, these
> are not *PDF* Limitations, they are limitations of the Adobe
> implementation).
> It was possible for us to emit co-ordinate movements which are in real
> numbers, but exceed 32767, which is outside the Acrobat limitation.
> This commit alters that, and in fact uses the older limitation of
> Acrobat 3 and 4, which limits co-ordinates to +/- 16K.
> devices/vector/gdevpdts.c

2018-12-01 10:01:18 +0000
Ken Sharp <ken.sharp@artifex.com>
fb9d383dd90bb430e18bd9c039300f0cff589323

> pdfwrite - PDF/A-1 must set Compatibility Level of 1.4
> Noticed while working on a different bug. Its correct for PDF/A-2 to be
> PDF 1.7, but not for PDF/A-1 we must conform to PDF 1.4.
> devices/vector/gdevpdfp.c

2018-11-29 12:30:10 -0800
Nancy Durgin <nancy.durgin@artifex.com>
7eaa19df8086579009552162814b34c651f8d0d4

> Fix .vmused undef to work properly
> Had to both use an immediate reference and make it an operator.
> (commit 2ff600a3c4fc169e7c6c1e83874a6bf63a6fb42b made .vmused an operator)
> This test was failing and wasn't detected by cluster test:
> debugbin/gs -DDELAYBIND -IResource/Init -sDEVICE=ppmraw -dSAFER
> If I don't make it an operator, then this fails (cluster test detects):
> debugbin/gs -Z: -o out.bin -IResource/Init -sDEVICE=ppmraw -sDEFAULTPAPERSIZE=letter -dNOPAUSE -dBATCH -K2000000 -dClusterJob -dJOBSERVER -dCETMODE %rom%Resource/Init/gs_cet.ps ~/work/samples/tests_private/ps/ps3cet/36-01.PS
> Resource/Init/gs_res.ps

2018-11-28 10:09:01 -0800
Nancy Durgin <nancy.durgin@artifex.com>
932f4106a00e99e4ee32dcc02e57d3636f383ea1

> Undef internal functions from level2dict
> Resource/Init/gs_lev2.ps

2018-11-29 16:07:17 +0000
Robin Watts <robin.watts@artifex.com>
dce2ab5aead0028de39293da8cf835c76b00a7cf

> Remove nasty type check in gs_fapi_finish_render.
> This is a left over from when show and text enumerators were
> significantly different. The only requirement now is that
> text enumerators should set penum->cc to be NULL. We update
> gs_text_enum_init_dynamic (and hence gs_text_enum_init) to
> do this.
> base/gstext.c
> base/gxfapi.c

2018-11-29 11:48:25 +0000
Robin Watts <robin.watts@artifex.com>
3bd37e9686f93dabb7121406bf36e59941db8e59

> Remove unnecessary checks on object types from gxfapi.c
> These are no longer required as the enumerators are the same.
> base/gxfapi.c

2018-11-29 17:32:30 +0000
Ken Sharp <ken.sharp@artifex.com>
66df699e2d7f19d87542c76e9d96167f2125e654

> pdfwrite - add a check to ensure we don't create an invalid PDF file
> related to bug #700291 The PDF file in that bug report was created by
> Ghostscript and pdfwrite. The xref table is invalid because it has an
> entry with an offset of 11 digits, which is illegal (the file exceeds
> 10GB in size)
> Add a check when writing the xref table to see if any offset is greater
> that 10 digits, and throw an error if it is. We can't check any earlier
> because we don't know the offset of any object in the file until it is
> read from its stored temporary file and written to the main output
> file.
> devices/vector/gdevpdf.c

2018-11-29 16:22:41 +0000
Chris Liddell <chris.liddell@artifex.com>
c0682e5dd674ecfedcb92ba114ce5c43306f270a

> Only use FT weight vector API if FT is new enough
> So strictly later than 2.9.1 or when using our patched sources (SHARE_FT==0)
> Makefile.in
> base/fapi_ft.c

2018-11-28 17:12:08 +0000
Chris Liddell <chris.liddell@artifex.com>
2756f0efae1d3966989b15a6526c5d80848b5015

> Bug 700290: Fix problems with DELAYBIND and font substitution
> Judicious use of immediate evaluation for .setnativefontmapbuilt and
> .putgstringcopy to avoid problems with DELAYBIND
> Resource/Init/gs_fonts.ps

2018-11-29 11:47:42 +0000
Robin Watts <robin.watts@artifex.com>
680b49775bf27fcfe3bcdbe7049abbba544f3329

> Remove unnecessary checks on type of pgs.
> No longer required since pgs and pis were merged.
> base/gxchar.c
> devices/vector/gdevtxtw.c

2018-11-29 11:33:20 +0000
Robin Watts <robin.watts@artifex.com>
6da179927d5aeaf936ebc81eb9d430f7edc0397a

> Remove antiquated check in pdf_shift_text_currentpoint.
> pdf_shift_text_currentpoint tests to see that the graphics state
> it is passed is really a graphics state. We believe this is a
> hangover from having graphics states and imager states.
> Firstly, the check is wrong, as it uses penum->dev->memory when
> it should be using penum->pgs->memory. Fixing this is enough to
> solve the problem where this was seen (gpdl pdfwriting files).
> Secondly, however the check is no longer needed, so the nicer fix
> is to remove it completely.
> devices/vector/gdevpdte.c

2018-11-29 10:55:32 +0000
Ken Sharp <ken.sharp@artifex.com>
cb77559a6825f6fa4b23c1d5efb981eadc7f948f

> Source fixup, remove trailing whitespace
> base/strmio.c

2018-11-14 16:56:43 -0800
Ray Johnston <ray.johnston@artifex.com>
f0ca2c929171a025e846a2eddd51f767e04c8e23

> Bug 695813. Reduce memory usage for ICC profiles. Example AIX361DC_Save.pdf
> The same ICC profiles and colorspace were used many times (in the example
> the cited PDF_1.7_ATS file) which could result in memory usage growth and
> performance impact associated with loading the same profile many times.
> There was a icc_profile_cache in the gstate, but it was not being used for
> ICCBased colorspaces, only for CIEBased* spaces.
> Adding logic to cache ICCBased colorspaces and change ICCBased space to
> be in stable memory so it can exist in the cache. This results in a
> reduction of the RAM needed for the cited file from 1.0Gb down to 44Mb
> and reduced the parse time from 29.4s down to 24.4s (overall time from
> 94.5s to 91.3s) for ppmraw 600 dpi.
> Note that this optimization results in many fewer CS/cs operations being
> emitted by pdfwrite, but this also can result in text being emitted as
> TJ operations (glyphs with positioning) which can result in single pixel
> shifts in glyphs. Sometimes this looks better, sometimes not, but the
> reduction in size/complexity of the resulting PDF is worth it.
> Resource/Init/pdf_draw.ps
> base/gsicc_profilecache.c
> psi/zicc.c

2018-11-28 14:04:23 +0000
Robin Watts <robin.watts@artifex.com>
34bb42a7bcd649675d618a62c9f8a3a673598787

> Ensure that gs_cet.ps is not squashed in romfs.
> This causes us to misinterpret it as being PCL, and defeats the
> 'skip if read more than once' test.
> psi/psromfs.mak

2018-11-28 19:13:16 +0000
Robin Watts <robin.watts@artifex.com>
8d462b070127d3541402b4fda670e0b20c6a61a4

> LCMS2MT: Planar data fix.
> The PrecalculatedXFORMIdentity case was failing to allow for planar
> data. Fix that here.
> Also, optimise the src = dst case.
> lcms2mt/src/cmsxform.c

2018-11-27 13:11:15 -0800
Nancy Durgin <nancy.durgin@artifex.com>
87ec442bc2b0bfa6607c5fb7d085dd85f24e1416

> Undefine internal .findcategory
> Resource/Init/gs_init.ps
> Resource/Init/gs_ll3.ps
> Resource/Init/gs_res.ps

2018-11-27 12:36:14 -0800
Nancy Durgin <nancy.durgin@artifex.com>
2ff600a3c4fc169e7c6c1e83874a6bf63a6fb42b

> Undef a bunch of internal things in gs_res.ps
> Resource/Init/gs_res.ps
> Resource/Init/gs_resmp.ps

2018-11-14 22:30:43 +0000
Chris Liddell <chris.liddell@artifex.com>
a6da4c97bb99159269468d95daacdf11ab336187

> Use the new Freetype FT_Set/Get_MM_WightVector API
> Being able to set the weight vector in an existing FT font object avoids the
> need to recreate the font every time the weightvector changes in Postscript.
> Creating an FT font is a time consuming operation, so this can save considerable
> time in jobs that make heavy use of multiple master fonts
> base/fapi_ft.c
> base/gxfapi.c

2018-11-14 22:29:24 +0000
Chris Liddell <chris.liddell@artifex.com>
bfddf70400bb1fd4b3f7bfd72f333ad09a0b6cba

> Add a setweightvector analogue in Freetype
> Avoids the need to recreate the FT font everytime the weightvector changes.
> These Freetype changes have been accepted upstream:
> http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=78a1e69517ca067224d6e33beffd25e2ec8361d2
> freetype/include/freetype/ftmm.h
> freetype/include/freetype/internal/services/svmm.h
> freetype/src/base/ftmm.c
> freetype/src/cff/cffdrivr.c
> freetype/src/truetype/ttdriver.c
> freetype/src/type1/t1driver.c
> freetype/src/type1/t1load.c
> freetype/src/type1/t1load.h

2018-11-27 19:43:29 +0000
Robin Watts <robin.watts@artifex.com>
3f93e079aa448a202329fd08a350485c3504b9dd

> Fix typo in previous commit.
> I failed dismally at checking the depth.
> base/gdevdflt.c
> devices/gdevbit.c

2018-11-27 17:24:38 +0000
Robin Watts <robin.watts@artifex.com>
c80766f966d2801a8608e72a1dea6dcb4bec4248

> Bug 700278: Fix inverted colors in jpegcmyk output.
> It seems that in the transform pixel region code, I know that
> colours are in the right space, and therefore assume that there
> will be a 1:1 mapping from the raw bytes into the device memory.
> Sadly the jpegcmyk device inverts everything, so my assumption
> was wrong.
> Accordingly I've added a gxdso to tell me if the encoding is
> direct. I've added this to the obvious devices - more may be
> required in future.
> If this is unimplemented, then we'll take the slower route
> and look up colors.
> base/gdevdflt.c
> base/gdevp14.c
> base/gxcmap.c
> base/gxdevsop.h
> devices/gdevbit.c

2018-11-26 18:01:25 +0000
Chris Liddell <chris.liddell@artifex.com>
779664d79f0dca77dbdd66b753679bfd12dcbbad

> Have gs_cet.ps run from gs_init.ps
> Previously gs_cet.ps was run on the command line, to set up the interpreter
> state so our output more closely matches the example output for the QL CET
> tests.
> Allow a -dCETMODE command line switch, which will cause gs_init.ps to run the
> file directly.
> This works better for gpdl as it means the changes are made in the intial
> interpreter state, rather than after initialisation is complete.
> This also means adding a definition of the default procedure for black
> generation and under color removal (rather it being defined in-line in
> .setdefaultbgucr
> Also, add a check so gs_cet.ps only runs once - if we try to run it a second
> time, we'll just skip over the file, flushing through to the end.
> Resource/Init/gs_cet.ps
> Resource/Init/gs_init.ps

2018-11-21 13:43:50 -0800
Nancy Durgin <nancy.durgin@artifex.com>
5d967e5d2c0b63a3c7d67a08a53ff657d36f0d18

> Undef some internal level3 implementation details
> Also moved some undef's from gs_init.ps to gs_ll3.ps because they are
> for things defined and used only in this file (or some are defined in
> the C code, but still only used here).
> Resource/Init/gs_init.ps
> Resource/Init/gs_ll3.ps

2018-11-20 14:32:20 -0800
Nancy Durgin <nancy.durgin@artifex.com>
f1206fa3834b5a8ff798e08d9cfcbb27bb9bdd41

> Remove dead code from gs_cspace.ps
> These are dead code, apparently:
> /..includecolorspace
> /cs_substitute_generic
> /cs_substitute_DeviceRGB_for_PDFX_or_PDFA
> This one is called from C code (zcolor.c) and can't be undef'd
> Added comment about how to trigger it.
> /..nosubstdevicetest
> Resource/Init/gs_cspace.ps

2018-11-20 12:47:40 -0800
Nancy Durgin <nancy.durgin@artifex.com>
d6630dfe7a2d44aec9193950acc34836a32f97e2

> Undef'd things used locally in gs_btokn.ps (binary tokens)
> /.objectprinttest
> /.bosheader
> /.cntobj
> /.writeobject
> /.writeobjects
> Resource/Init/gs_btokn.ps

2018-11-20 12:19:28 -0800
Nancy Durgin <nancy.durgin@artifex.com>
c548ed1dca42cb77572b2a7f8448aad2ce98918c

> Fix some previously attempted undef's
> /.setdevicecolorrendering1 needs to be undef'd from both systemdict
> and level2dict
> /.ProcessICCcomment was misspelled
> /.setpagesize is actually in statusdict and haven't successfully undef'd yet
> Resource/Init/gs_icc.ps
> Resource/Init/gs_init.ps

2018-11-27 14:08:33 +0000
Ken Sharp <ken.sharp@artifex.com>
de8b6458abaeb9d0b14f02377f3e617f2854e647

> PS interpreter - fix EPSFitPage (again)
> Bug #700279 "On square EPS files -dFitPage incorrectly rotates output"
> The commit to fix bug #698555 altered the action of EPSFitPage so that
> it set the media size form the BoundingBox (using EPSCrop) and then
> relied on the usual PostScript page fitting.
> However, as noted at the time, this does cause square pages to rotate.
> This isn't actually incorrect, there is no specification for this its a
> Ghostscript feature, and we're free to implement it any way we like.
> However it is a change form the previous behaviour.
> This commit reinstates the EPSFitPage code (in EPSBoundingBoxFitPage
> in gs_epsf.ps) and fixes the calculations in that code when the content
> is rotated onto the media (because it fits better that way) so that it
> correctly scales and translates the content onto the new media.
> because we are no longer using the PostScript page fitting code, this
> no longer rotates square media.
> Resource/Init/gs_epsf.ps
> Resource/Init/gs_init.ps

2018-11-26 08:20:19 +0000
Ken Sharp <ken.sharp@artifex.com>
96c381cce28c27eac182549441a6c5025b0dcdd6

> ps2write - move the page level save/restore wrapper
> Bug #700232 "A5 duplex to duplex-capable Postscript printer prints single-sided"
> Commit 0f6067d2531298060392d0e25fa759d320e03021 for bug #697245
> removed a duplicate definition of pagesave, because it transpires that
> Adobe interpreters don't free save objects when they are no longer
> referenced. Previously we had defined /pagesave in both the page
> content stream, and the code for altering page size.
> The problem is that we alter media size as part of processing the
> 'stream' keyword, which is after we have defined /pagesave. Previously
> we would then have redefined it if we needed to alter the media size.
> When we got to the end of the page (after the showpage) we would then
> restore the save object. Because we had defined the save object after we
> had altered the media size the media would remain unchanged. With the
> commit above, however, the media size would be restored back to the
> original.
> When we process page 2, the media size would then need to he altered
> again, requiring a setpagedevice to be executed. The action of
> setpagedevice, when Duplex is true, is to eject any unpaired pages and
> start again with the first side.
> Thus Duplex was working entirely correctly, simply not as desired.
> This commit moves the pagesave and restore into the 'stream' and
> 'endstream' processing, so that is taken care of after any media size
> changes.
> devices/vector/gdevpdf.c
> devices/vector/opdfread.ps

2018-11-26 15:19:35 -0800
Michael Vrhel <michael.vrhel@artifex.com>
2ceb01328c4270386299ef55dbdc06d1f26d63c8

> Remove unneeded check for planar during color conversion
> base/gsicc_lcms2mt.c

2018-11-26 12:14:21 -0800
Michael Vrhel <michael.vrhel@artifex.com>
56b4298a22c3253206615bc6fda34f74aaa72800

> Avoid allocations when color transforming planar data
> base/gsicc_lcms2mt.c

2018-11-14 14:27:26 -0800
Ray Johnston <ray.johnston@artifex.com>
461cdaa4287edac9bfd0caebf3e8291e0539a0fd

> Fix some missing type checking and use check_read_type consistently
> Some places checked with code, some places used the check__type
> macro (which doesn't check for read access) and some places used
> check_read_type. Also add check for CIEdict1 in hashcieaspace.
> psi/zcolor.c

2018-11-14 14:19:42 -0800
Ray Johnston <ray.johnston@artifex.com>
e45b35ede042259ff9fbf36fa714e874fc5483db

> Change hash key for the icc_profile_cache to uint64_t
> This was ulong in some places and int64_t in another, but ulong on a
> Windows build is only 32-bits. Make it consistent (and more bytes on
> Windows).
> base/gscms.h
> base/gsicc_profilecache.c
> base/gsicc_profilecache.h
> psi/zcie.c
> psi/zcie.h
> psi/zcolor.c

2018-11-09 14:26:27 -0800
Ray Johnston <ray.johnston@artifex.com>
410a192c093c22ca1dbfc1764659faa6a48198a8

> Fix infinite loop freeze running all PDF ATS files.
> The infinite loop was caused by bumping the ref_count on a cache link
> entry too early so that anytime we reached ICC_CACHE_MAXLINKS links in
> the cache, we would loop forever.
> This simplifies the code, removes a function that was only used once,
> and also protects the clist multi-threading from potential lock up due
> to more threads than slots in the icc_link_cache.
> Add a semaphore when the link_cache is full (no zero ref_count entries)
> to let other threads run and finish up with the links that are in the
> cache.
> No bug opened, but occurred with:
> gs -r600 -sDEVICE=ppmraw -o /dev/null PDF_1.7_ATS/*.pdf
> NB: This requires skipping AC8ZD1CC_Save.pdf since that needs a password.
> base/gpsync.h
> base/gscms.h
> base/gsicc_cache.c
> base/gxclthrd.c

2018-11-26 16:17:51 +0000
Robin Watts <robin.watts@artifex.com>
2501816e229ae98e1c0d9a91f8bf00b380301b55

> Fix comment typo.
> psi/zdevice.c

2018-11-23 16:24:43 +0000
Robin Watts <robin.watts@artifex.com>
f73fb86fb40d092b4b9a39f43a374bd70eac0d41

> Remove more macros from iscan.c
> psi/iscan.c

2018-11-26 15:14:12 +0000
Robin Watts <robin.watts@artifex.com>
9a364553aa4d0738ec763aa2c262af6fc82b088d

> Make sfclose accept NULL.
> All destructors should accept NULL. Anything else is insanity.
> base/strmio.c

2018-10-22 18:47:40 +0100
Robin Watts <robin.watts@artifex.com>
40dc5b409c6262b18b4bf5386b5482ead4c511e3

> Remove gpdl from the "all" Makefile targets.
> Add it to a new "experimental" target that is what "all" used to
> be.
> Makefile.in
> base/gs.mak
> psi/msvc.mak

2018-09-14 14:00:40 +0100
Robin Watts <robin.watts@artifex.com>
b43a9362c8614182e77b89a3ff8d8c56a6628260

> iscan.c: Remove some scan macros.
> psi/iscan.c

2018-09-14 13:56:21 +0100
Robin Watts <robin.watts@artifex.com>
9e99c4ab4135f735091d4b3ffe26851604507db5

> iscan.c: Demacro: ssarray
> psi/iscan.c

2018-11-22 19:17:28 +0000
Robin Watts <robin.watts@artifex.com>
0718e9a4fdc1c107d772d1aff37566c73d5958f8

> Remove ziodevs.c from MSVC project.
> windows/ghostscript.vcproj

2018-11-19 17:38:11 +0000
Robin Watts <robin.watts@artifex.com>
edbad08f9c91c994ac8f8df45e0cbf37ca377104

> Remove macro bletcherisms from stream code.
> base/gsioram.c
> base/gsiorom.c
> base/sfxfd.c
> base/sfxstdio.c
> base/stream.c
> base/stream.h
> psi/zfilter.c
> psi/zfrsd.c

2018-11-22 18:18:03 +0000
Robin Watts <robin.watts@artifex.com>
e1eecc89c943d20145a887c64193fb0bfb44c250

> Squash warnings.
> base/gdevdrop.c
> base/gsicc_cache.c
> base/gxclist.c
> devices/gdevxcmp.c
> pcl/pcl/pcfont.c
> psi/ilocate.c
> psi/zvmem.c

2018-11-22 16:30:49 +0000
Robin Watts <robin.watts@artifex.com>
8fe6187ace91d49c3ca07ab850bc1fe50da3409e

> Remove STDIO_IMPLEMENTATION logic from Makefiles.
> This has fallen out of usage to the degree where the non-C callbacks
> based version hasn't even built for years (since at least 2006, by
> my git archaeology). Just strip it out completely.
> Makefile.in
> base/gs.mak
> base/msvclib.mak
> base/openvms.mak
> base/ugcclib.mak
> base/unix-dll.mak
> base/unix-gcc.mak
> base/unixansi.mak
> psi/int.mak
> psi/msvc.mak
> psi/os2.mak
> psi/ziodevs.c
> psi/ziodevsc.c

2018-11-07 16:03:59 +0000
Chris Liddell <chris.liddell@artifex.com>
07b4a67404479dfa3ae55835f05b6cc8699c9adc

> Bring master up to date with 9.26 release branch
> Docs, dates etc
> Dates, change log, etc for 9.26 rc1
> Dates, changelog, etc for 9.26 release
> base/version.mak
> doc/DLL.htm
> doc/Deprecated.htm
> doc/Develop.htm
> doc/Devices.htm
> doc/Drivers.htm
> doc/Fonts.htm
> doc/History9.htm
> doc/Install.htm
> doc/Language.htm
> doc/Lib.htm
> doc/Make.htm
> doc/News.htm
> doc/Ps-style.htm
> doc/Ps2epsi.htm
> doc/Psfiles.htm
> doc/Readme.htm
> doc/Release.htm
> doc/SavedPages.htm
> doc/Source.htm
> doc/Unix-lpr.htm
> doc/Use.htm
> doc/VectorDevices.htm
> doc/WhatIsGS.htm
> doc/gs-vms.hlp
> doc/sample_downscale_device.htm
> doc/subclass.htm
> doc/thirdparty.htm
> man/dvipdf.1
> man/gs.1
> man/gslp.1
> man/gsnd.1
> man/pdf2dsc.1
> man/pdf2ps.1
> man/pf2afm.1
> man/pfbtopfa.1
> man/printafm.1
> man/ps2ascii.1
> man/ps2epsi.1
> man/ps2pdf.1
> man/ps2pdfwr.1
> man/ps2ps.1

2018-11-14 21:11:43 +0000
Robin Watts <robin.watts@artifex.com>
4b50d93dfe0b539d2cbbf80b3db8c89362abb265

> Add gpdlmemento target.
> Also add "mementovg" targets for building memento with knowledge of
> valgrind. Can't make this the default as then we'd not be able to
> build memento on machines without valgrind installed.
> base/unix-end.mak

2018-11-20 18:43:20 +0000
Chris Liddell <chris.liddell@artifex.com>
690bc91e0fff4314128becb98e27b8bdd182c194

> Tweak gs_cet.ps papersize handling.
> This file has always removed all but the default papersizes from
> InputAttributes. Here, also ensure that we make that the current
> page size to avoid problems with setpagedevice later on.
> Resource/Init/gs_cet.ps

2018-11-20 13:44:22 +0000
Robin Watts <robin.watts@artifex.com>
bca00a68a20b4022ce6138d647daa0b6b7989c9a

> Remove pl_top_cursor_t and move to using streams.
> pcl/pl/pl.mak
> pcl/pl/plcursor.c
> pcl/pl/plcursor.h
> pcl/pl/plmain.c
> windows/ghostpcl.vcproj

2018-11-15 15:38:37 -0800
Nancy Durgin <nancy.durgin@artifex.com>
93e0445e2c9980a3e5eb066d61682e84716972bb

> Delete gs_l2img.ps, and all references in makefiles and docs.
> This is dead code that apparently hasn't been used for years. It was
> defining some things in systemdict (.colorspaceimage, .csinextbits)
> that are now also gone.
> Resource/Init/gs_l2img.ps
> doc/Develop.htm
> doc/Psfiles.htm
> psi/int.mak
> psi/psromfs.mak
> windows/ghostscript.vcproj
> windows/ghostscript_rt.vcxproj

2018-11-15 15:01:48 -0800
Nancy Durgin <nancy.durgin@artifex.com>
9a270eea5080ec418202dcb778c1215839123555

> Undef a bunch of image-related things
> If we get rid of display postscript, this simplifies to just getting rid of
> the img_utils_dict, which contains all the things I have undefined.
> Resource/Init/gs_img.ps

2018-11-15 09:23:55 -0800
Nancy Durgin <nancy.durgin@artifex.com>
e06edfb35e09d7e34d4c0c0a31931e28c4cd944d

> Undefine a bunch of functions
> undef .ProcessICCComment from gs_icc.ps
> Undef .rewriteTempMapsNotDef in gs_cmap.ps
> These are implemented in C code, so not associated with a particular ps file.
> /.currentmatrix /.setmatrix /.setdevicecolorrendering1
> /.setlinecap /.setlinejoin /.sizeimagebox /.systemvmcheck
> Resource/Init/gs_cmap.ps
> Resource/Init/gs_icc.ps
> Resource/Init/gs_init.ps

2018-11-20 12:59:06 +0000
Robin Watts <robin.watts@artifex.com>
b7ee393b7afb0d584528173d98fe0509d1ea09ff

> Remove needless macros in plmain.c
> pcl/pl/plmain.c

2018-11-19 17:23:02 +0000
Ken Sharp <ken.sharp@artifex.com>
c0de6c578f685c03d21c2a5d934734081265d10e

> Function cleanup - NULL pointers after free
> The PostScript code seems to get away with this, but for the PDF
> interpreter we need the object pointed to by the various 'params'
> structure members to be NULL after they are freed, so that we don't
> try to free memory which has already been freed.
> base/gsfunc.c
> base/gsfunc0.c
> base/gsfunc3.c
> base/gsfunc4.c

2018-11-19 09:28:41 +0000
Chris Liddell <chris.liddell@artifex.com>
af39fde7b765ea5550a857290d68f58468086a8c

> Coverity CIDs: 326829, 326828 and 326827
> Check return values for gdev_prn_open_printer()
> contrib/gdevgdi.c
> contrib/japanese/gdevrpdl.c
> devices/gdevdjet.c

2018-11-19 09:00:54 +0000
Ken Sharp <ken.sharp@artifex.com>
4d98293c72cc5b5fe456065a3252d39e9ab28e4d

> Coverity ID 327264 - move pointer NULL check
> Due to recent changes in this code, the pointer was being dereferenced
> before we checked it to see if it was NULL. Moe the check so that we
> check for NULL before dereferencing.
> The 'pvalue' of the operand can be NULL, even if the object is a t_device
> type, because invalidate_stack_devices traverses the operand stack
> looking for devices, and sets their pvalue member to NULL in order to
> invalidate them so that they cannot be used.
> psi/zdevice.c

2018-11-17 11:20:08 +0000
Ken Sharp <ken.sharp@artifex.com>
867deb44ce59102b3c817b8228d9cbfd9d9b1fde

> Check structure types when using the r_ptr macro
> Two more places where we were using the r_ptr macro to cast a PostScript
> ref object into a structure without thoroughly checking that the object
> was in fact a structure of the correct type.
> One case did a partial check, but this is more robust.
> base/gsfcid2.c
> base/gsfcmap.c
> psi/zdscpars.c
> psi/zfcmap.c

2018-11-17 10:00:32 +0000
Ken Sharp <ken.sharp@artifex.com>
aba438b1835c4c0f4c2b0aee5b7d8430d7e58251

> Coverity ID 94865
> This had already been tackled, but it turns out there were a couple
> more places where tempnames wasn't freed, but Coverity only seems to
> flag them one at a time.
> psi/imain.c

2018-11-17 09:37:07 +0000
Ken Sharp <ken.sharp@artifex.com>
5cfe86c6f37f4838746d7cc7e9e6125538af6e84

> Coverity ID 323322
> The new 'transform_pixel_region' method default for forwarding devices
> tests the target device to see if its NULL (some forwarding devices are
> not always forwarding devices, eg bbox), and if it is NULL then instead
> of passing the call to the target device it calls the graphics library
> default.
> Unfortunately it was passing the target device as an argument, and this
> is now certain to be NULL. In gx_default_transform_pixel_region_begin()
> we then dereference the pointer which would cause a crash.
> So instead, pass the device itself when its not actually a forwarding
> device.
> Also, some white space changes.
> base/gdevnfwd.c

2018-11-16 17:56:46 +0000
Robin Watts <robin.watts@artifex.com>
79a6bb7c5e33e0acf281bf7f34e6c6cc20c2549c

> Bug 700205: Bring jbig2dec's copy of memento up to date.
> jbig2dec/memento.c
> jbig2dec/memento.h

2017-07-03 13:07:29 +0100
Robin Watts <Robin.Watts@artifex.com>
bd6af85222da668b56a1815fefc374b2096029b5

> Sync Memento from MuPDF.
> * pointer checking functions.
> Add some helpful functions for doing quick checks on pointer validity.
> Use these in the reference counting functions.
> * make ref counting advance events.
> * misc sizeof fixes.
> base/memento.c
> base/memento.h

2018-09-19 17:27:11 +0100
Robin Watts <robin.watts@artifex.com>
7750a48097a387a006577a02e20e2673a77fc82f

> Update language recognition mechanism.
> Rather than each language implementation offering a single string
> to be matched, they now offer a function to match the given
> string.
> This allows us to have the PJL recognising routine accept a
> single <CR><LF> at the top of a PJL block.
> Technically, this is against the spec, which very clearly says
> that any UEL must be followed instantly by "@PJL" rather than
> there being any whitespace there. Sadly, the file from bug 693269
> sends UEL<CR><LF>@PJL... and so outputs a page of PJL in the
> middle of the job without this fix.
> Tests on Henry's HP printer show that his printer at least matches
> this behaviour.
> It is hard to see that there can be that many real world files out
> there that will be adversely affected by this fix.
> This means we now behave the same on bug 693269 as we did prior to
> making our language switching actually switching languages.
> gpdl/psi/psitop.c
> pcl/pcl/pctop.c
> pcl/pl/pjparse.c
> pcl/pl/pjparsei.c
> pcl/pl/plmain.c
> pcl/pl/pltop.c
> pcl/pl/pltop.h
> pcl/pxl/pxtop.c
> xps/xpstop.c

2018-11-15 15:24:10 +0000
Ken Sharp <ken.sharp@artifex.com>
46d3a9a658f3b92e554cffc3c2ace8c140118155

> PS interpreter - check infinite result on exp, where possible
> Bug #700181 "using exp with 0 as base" (again)
> The reporter for the bug failed to mention this condition in the
> original report. Technically we don't always have isinf() available
> (I suspect all real compilers do these days) but where we do we can
> check the result. Where we don't, we're stuck. This mimics the
> behaviour of other math operations in Ghostscript.
> psi/zmath.c

2018-11-15 14:18:17 +0000
Ken Sharp <ken.sharp@artifex.com>
1218b59561ba950e212ad4e585bd7b0612eb2102

> PDF interpreter - use Appearance streams for highlight annotations
> We were previously never using the Appearance stream for a highlight
> annotation, which is documented as incorrect in the PDF 2.0 spec.
> The reason we were not using it is because a very few PDF files render
> differently if we do. This is because Acrobat 'sometimes', and I cannot
> figure out the conditions for htis, ignores a perfectly valid Appearance
> and generates a new one.
> In this case a customer produced a file where the QuadPoints entry is
> incorrect. If we use the Appearance stream (as Acrobat does) then the
> rendering is correct. If we generate an appearance then, because the
> QuadPoints are incorrect, the rendering is incorrect.
> Since the PDF 2.0 specification now makes it clear that we should be
> using a supplied Appearance stream, I've chosen to change the behaviour
> so that we do.
> I've also made the text for an appearance stream slightly more robust
> and general.
> This does produce a few diffs, because of the afore-mentioned files. In
> my opinion Acrobat is incorrect in how it treats these files. Our new
> rendering is correct.
> Resource/Init/pdf_draw.ps

2018-11-14 21:04:46 +0000
Chris Liddell <chris.liddell@artifex.com>
ea1b3ef437f39e45874f821c06bd953196625ac5

> Bug 700176: Use the actual output device for both devices in setdevice
> Also fixes bug 700189.
> The pdf14 compositor device, despite being a forwarding device, does not forward
> all spec_ops to it's target, only a select few are special cased for that.
> gxdso_current_output_device needs to be included in those special cases.
> The original commit (661e8d8fb8248) changed the code to use the spec_op to
> retrieve the output device, checking that for LockSafetyParams. If
> LockSafetyParams is set, it returns an invalidaccess error if the new device
> differs from the current device.
> When we do the comparison between the two devices, we need to check the
> output device in both cases.
> This is complicated by the fact that the new device may not have ever been set
> (and thus fully initialised), and may not have a spec_op method available at
> that point.
> base/gdevp14.c
> psi/zdevice.c

2018-11-13 14:23:41 -0800
Nancy Durgin <nancy.durgin@artifex.com>
fe4c47d8e25d6366ecbb5ff487348148b908a89e

> Undefine some level2-related operators
> These are only a partial set. Undefine them in both the level2dict and
> systemdict. They are undef'd in gs_init.ps because they are used outside
> the scope of just gs_lev2.ps
> /.execform1
> /.getdevparams
> /.setuserparams2
> /.startjob
> /.checkFilePermitparams
> /.checksetparams
> /.copyparam
> /.setpagesize
> Rename .dict1 to .pair2dict and use immediate reference.
> Undef these at end of gs_lev2.ps (should never make it into systemdict):
> /.pair2dict
> /.checkprocesscomment
> Resource/Init/gs_init.ps
> Resource/Init/gs_lev2.ps

2018-11-14 17:37:02 +0000
Robin Watts <robin.watts@artifex.com>
66a273de3ca0560bd41a2448b264d78f9316ba6a

> Fix PCL handling of slightly malformed PJL.
> We parse the PJL lines in, and if we find a terminator character
> other than '\n', we ignore the line. What is worse, we eat the
> character that we trip over, so that if it (say) happened to be
> an ESC, we then don't process the next command correctly.
> pcl/pl/pjparse.c

2018-11-14 16:01:51 +0000
Ken Sharp <ken.sharp@artifex.com>
965a557a4cdc8f45ff962616b884c281abd6c72c

> PS interpreter - in seticcspace, ensure the ICC dictionary is a dict
> From a review of dict_find_string, that function does not check to see
> if the object it is passed as an argument is a dictionary, so its
> essential to make sure the argument is checked before calling.
> This is the only remaining case I could find.
> psi/zcolor.c

2018-11-13 04:18:21 +0100
Sebastian Rasmussen <sebras@gmail.com>
f1756124f0f3c542bd6c2a9b325dea6bf860fc61

> jbig2dec: Only print repeated error/warning messages once.
> base/sjbig2.c
> base/sjbig2.h
> jbig2dec/jbig2dec.c

2018-11-14 14:28:48 +0000
Ken Sharp <ken.sharp@artifex.com>
bcb605e49dbe306ba881818466f8be591510a9ab

> PS interpreter - Throw error from exp when base is 0 and -ve exponent
> Bug #700181 "using exp with 0 as base"
> If base is 0, and exp is negative, then the result of exp is undefined
> we should throw an error instead of pushing #INF.0 on the stack.
> psi/zmath.c

2018-11-14 13:32:43 +0000
Robin Watts <robin.watts@artifex.com>
9a982079dabc985bbd26d69322f517495158e882

> Update .gitattributes file.
> Stolen largely from MuPDF's file. This should keep the tabs in
> Makefiles from confusing things.
> .gitattributes

2018-11-14 13:15:11 +0000
Robin Watts <robin.watts@artifex.com>
fa3ac5d4cfea23ddc4eed64fd6f552013019ad1a

> MSVC: Remove #define for fstat from unistd.h
> We already define it in stat_.h, which seems like a much more sensible
> place.
> base/unistd_.h

2018-11-14 09:50:08 +0000
Chris Liddell <chris.liddell@artifex.com>
661e8d8fb8248c38d67958beda32f3a5876d0c3f

> Bug 700176: check the *output* device for LockSafetyParams
> When calling .setdevice we were checking if LockSafetyParams was set, and if so
> throwing an invalidaccess error.
> The problem is, if another device, for example the pdf14 compositor is the 'top'
> device, that does not (and cannot) honour LockSafetyParams.
> To solve this, we'll now use the (relatively new) gxdso_current_output_device
> spec_op to retrieve the *actual* output device, and check the LockSafetyParams
> flag in that.
> psi/zdevice.c

2018-11-14 09:31:10 +0000
Ken Sharp <ken.sharp@artifex.com>
9a1b3ac61761094713f44dedfce56013308a3b1d

> PS interpreter - add some type checking
> These were 'probably' safe anyway, since they mostly treat the objects
> as integers without checking, which at least can't result in a crash.
> Nevertheless, we ought to check.
> The return from comparedictkeys could be wrong if one of the keys had
> a value which was not an array, it could incorrectly decide the two
> were in fact the same.
> psi/zbfont.c
> psi/zcolor.c
> psi/zcrd.c
> psi/zfjpx.c
> psi/zfont.c
> psi/zfont0.c
> psi/zimage3.c
> psi/ztrans.c

2018-11-14 09:27:00 +0000
Ken Sharp <ken.sharp@artifex.com>
606a22e77e7f081781e99e44644cd0119f559e03

> Bug #700168 - add a type check
> Bug #700168 "Type confusion in JBIG2Decode"
> The code was assuming that .jbig2globalctx was a structure allocated
> by the graphics library, without checking.
> Add a check to see that it is a structure and that its the correct
> type of structure.
> psi/zfjbig2.c

2018-11-14 09:25:13 +0000
Ken Sharp <ken.sharp@artifex.com>
434753adbe8be5534bfb9b7d91746023e8073d16

> Bug #700169 - unchecked type
> Bug #700169 "Type confusion in setcolorspace"
> In seticc() we extract "Name" from a dictionary, if it succeeds we then
> use it as a string, without checking the type to see if it is in fact
> a string.
> Add a check on the type, and add a couple to check that 'N' is an integer
> in a few places too.
> psi/zicc.c

2018-11-07 15:03:48 -0800
Nancy Durgin <nancy.durgin@artifex.com>
4f168df2845e15e5f87232317472d09ad1b2f1a3

> Move a bunch of existing undef's up to the array with the others.
> Resource/Init/gs_init.ps

2018-11-08 15:34:38 -0800
Nancy Durgin <nancy.durgin@artifex.com>
b7e7a76098c33e04e22464b6278c68a02b3d39b0

> Undefined a bunch of EPS things
> Resource/Init/gs_epsf.ps

2018-11-07 15:00:27 -0800
Nancy Durgin <nancy.durgin@artifex.com>
6f8b9869b38909700dcf906332d8825a6c390765

> Remove .endjob, which is not used anywhere
> Resource/Init/gs_lev2.ps

2018-11-12 17:21:33 +0000
Chris Liddell <chris.liddell@artifex.com>
aeea342904978c9fe17d85f4906a0f6fcce2d315

> Bug 700153: restore: always check available stack
> Previously, we were checking there was enough stack space available when the
> restore operation required a device change, but since we have to use
> Postscript to reset the userparams (ick!), we need the stack check even when
> not changing the device.
> psi/zdevice2.c

2018-11-07 12:22:59 +0000
Chris Liddell <chris.liddell@artifex.com>
2dceb0400c5a571f23070891b8a8028d04926de1

> Contrib devices: Check for error return opening output file
> 09-59.PS cycles through every available device, attempting to open each one.
> For many devices this results in an invalid configuration (mainly a lack of
> output file).
> These devices, on being shutdown, ignored the lack of output file, and attempted
> to write their final bytes out anyway (attempting to write data to a null
> FILE * pointer), causing a segfault.
> We now check the return value of gdev_prn_open_printer() and only write those
> final bytes if gdev_prn_open_printer() completed successfully.
> contrib/japanese/gdevespg.c
> contrib/japanese/gdevnpdl.c
> contrib/lips4/gdevl4r.c

2018-11-08 14:43:32 +0000
Ken Sharp <ken.sharp@artifex.com>
693baf02152119af6e6afd30bb8ec76d14f84bbf

> PS interpreter - check the Implementation of a Pattern before use
> Bug #700141 "Type confusion in setpattern"
> As the bug thread says, we were not checking that the Implementation
> of a pattern dictionary was a structure type, leading to a crash when
> we tried to treat it as one.
> Here we make the st_pattern1_instance and st_pattern2_instance
> structures public definitions and in zsetcolor we check the object
> stored under the Implementation key in the supplied dictionary to see if
> its a t_struct or t_astruct type, and if it is that its a
> st_pattern1_instance or st_pattern2_instance structure.
> If either check fails we throw a typecheck error.
> We need to make the st_pattern1_instance and st_pattern2_instance
> definitions public as they are defined in the graphics library and we
> need to check in the interpreter.
> base/gsptype1.c
> base/gsptype2.c
> base/gsptype2.h
> base/gxcolor2.h
> psi/zcolor.c

2018-11-08 12:58:28 +0000
Robin Watts <robin.watts@artifex.com>
81f3d1e7247b9a8e29a388677b01959e612a28c7

> Fix missing images due to transform_pixel_region and pattern_accumulator.
> The pattern_accumulator was defaulting to the forwarding version
> of transform_pixel_region, which was only dealing with the image
> plane, not the mask. Accordingly nothing was being plotted.
> Instead, use the default, which devolves to copy_color (for the
> image data) and fill_rectangle (for the mask).
> base/gxpcmap.c

2018-11-07 15:59:32 +0000
Chris Liddell <chris.liddell@artifex.com>
5a4fec2a34af925993192e197ab666fe542b79d3

> Bump version number for release
> Resource/Init/gs_init.ps
> base/version.mak

2018-11-20 09:51:17 +0000
Chris Liddell <chris.liddell@artifex.com>
8efbedbab72687cb51e3c353d5665d00120eed4a

> Dates, changelog, etc for 9.26 release
> base/gscdef.c
> base/version.mak
> doc/DLL.htm
> doc/Deprecated.htm
> doc/Develop.htm
> doc/Devices.htm
> doc/Drivers.htm
> doc/Fonts.htm
> doc/History9.htm
> doc/Install.htm
> doc/Language.htm
> doc/Lib.htm
> doc/Make.htm
> doc/News.htm
> doc/Ps-style.htm
> doc/Ps2epsi.htm
> doc/Psfiles.htm
> doc/Readme.htm
> doc/Release.htm
> doc/SavedPages.htm
> doc/Source.htm
> doc/Unix-lpr.htm
> doc/Use.htm
> doc/VectorDevices.htm
> doc/WhatIsGS.htm
> doc/gs-vms.hlp
> doc/sample_downscale_device.htm
> doc/subclass.htm
> doc/thirdparty.htm
> man/dvipdf.1
> man/gs.1
> man/gslp.1
> man/gsnd.1
> man/pdf2dsc.1
> man/pdf2ps.1
> man/pf2afm.1
> man/pfbtopfa.1
> man/printafm.1
> man/ps2ascii.1
> man/ps2epsi.1
> man/ps2pdf.1
> man/ps2pdfwr.1
> man/ps2ps.1

2018-11-19 09:28:41 +0000
Chris Liddell <chris.liddell@artifex.com>
e5978ae6d1e4f3dee0a2838ed580b0373e102613

> Coverity CIDs: 326829, 326828 and 326827
> Check return values for gdev_prn_open_printer()
> contrib/gdevgdi.c
> contrib/japanese/gdevrpdl.c
> devices/gdevdjet.c

2018-11-19 09:00:54 +0000
Ken Sharp <ken.sharp@artifex.com>
a4228a0d8d657fca3bb3becb93a43fae061beae8

> Coverity ID 327264 - move pointer NULL check
> Due to recent changes in this code, the pointer was being dereferenced
> before we checked it to see if it was NULL. Moe the check so that we
> check for NULL before dereferencing.
> The 'pvalue' of the operand can be NULL, even if the object is a t_device
> type, because invalidate_stack_devices traverses the operand stack
> looking for devices, and sets their pvalue member to NULL in order to
> invalidate them so that they cannot be used.
> psi/zdevice.c

2018-11-17 11:20:08 +0000
Ken Sharp <ken.sharp@artifex.com>
c796ccb512ac581f5ac492fda8807d41769c47e8

> Check structure types when using the r_ptr macro
> Two more places where we were using the r_ptr macro to cast a PostScript
> ref object into a structure without thoroughly checking that the object
> was in fact a structure of the correct type.
> One case did a partial check, but this is more robust.
> base/gsfcid2.c
> base/gsfcmap.c
> psi/zdscpars.c
> psi/zfcmap.c

2018-11-17 10:00:32 +0000
Ken Sharp <ken.sharp@artifex.com>
cb9bb72643e95383bcacd88ab718565f3df9a510

> Coverity ID 94865
> This had already been tackled, but it turns out there were a couple
> more places where tempnames wasn't freed, but Coverity only seems to
> flag them one at a time.
> psi/imain.c

2018-11-17 09:37:07 +0000
Ken Sharp <ken.sharp@artifex.com>
c69827c308b608719d786fc14c8518af4dd6b335

> Coverity ID 323322
> The new 'transform_pixel_region' method default for forwarding devices
> tests the target device to see if its NULL (some forwarding devices are
> not always forwarding devices, eg bbox), and if it is NULL then instead
> of passing the call to the target device it calls the graphics library
> default.
> Unfortunately it was passing the target device as an argument, and this
> is now certain to be NULL. In gx_default_transform_pixel_region_begin()
> we then dereference the pointer which would cause a crash.
> So instead, pass the device itself when its not actually a forwarding
> device.
> Also, some white space changes.
> base/gdevnfwd.c

2018-11-15 15:24:10 +0000
Ken Sharp <ken.sharp@artifex.com>
4548ceaf5ada7f7a4c4da5907e27fec62c1ce63d

> PS interpreter - check infinite result on exp, where possible
> Bug #700181 "using exp with 0 as base" (again)
> The reporter for the bug failed to mention this condition in the
> original report. Technically we don't always have isinf() available
> (I suspect all real compilers do these days) but where we do we can
> check the result. Where we don't, we're stuck. This mimics the
> behaviour of other math operations in Ghostscript.
> psi/zmath.c

2018-11-15 14:18:17 +0000
Ken Sharp <ken.sharp@artifex.com>
a4e3cb230bfdbf9cb5a0d30763889e58f8215ed1

> PDF interpreter - use Appearance streams for highlight annotations
> We were previously never using the Appearance stream for a highlight
> annotation, which is documented as incorrect in the PDF 2.0 spec.
> The reason we were not using it is because a very few PDF files render
> differently if we do. This is because Acrobat 'sometimes', and I cannot
> figure out the conditions for htis, ignores a perfectly valid Appearance
> and generates a new one.
> In this case a customer produced a file where the QuadPoints entry is
> incorrect. If we use the Appearance stream (as Acrobat does) then the
> rendering is correct. If we generate an appearance then, because the
> QuadPoints are incorrect, the rendering is incorrect.
> Since the PDF 2.0 specification now makes it clear that we should be
> using a supplied Appearance stream, I've chosen to change the behaviour
> so that we do.
> I've also made the text for an appearance stream slightly more robust
> and general.
> This does produce a few diffs, because of the afore-mentioned files. In
> my opinion Acrobat is incorrect in how it treats these files. Our new
> rendering is correct.
> Resource/Init/pdf_draw.ps

2018-11-14 21:04:46 +0000
Chris Liddell <chris.liddell@artifex.com>
e8be28b49c6a43db1861119288933b5a8fdbef73

> Bug 700176: Use the actual output device for both devices in setdevice
> Also fixes bug 700189.
> The pdf14 compositor device, despite being a forwarding device, does not forward
> all spec_ops to it's target, only a select few are special cased for that.
> gxdso_current_output_device needs to be included in those special cases.
> The original commit (661e8d8fb8248) changed the code to use the spec_op to
> retrieve the output device, checking that for LockSafetyParams. If
> LockSafetyParams is set, it returns an invalidaccess error if the new device
> differs from the current device.
> When we do the comparison between the two devices, we need to check the
> output device in both cases.
> This is complicated by the fact that the new device may not have ever been set
> (and thus fully initialised), and may not have a spec_op method available at
> that point.
> base/gdevp14.c
> psi/zdevice.c

2018-11-14 16:01:51 +0000
Ken Sharp <ken.sharp@artifex.com>
5db929cf393fa330bf916da37f5d2a5954a3b0c3

> PS interpreter - in seticcspace, ensure the ICC dictionary is a dict
> From a review of dict_find_string, that function does not check to see
> if the object it is passed as an argument is a dictionary, so its
> essential to make sure the argument is checked before calling.
> This is the only remaining case I could find.
> psi/zcolor.c

2018-11-13 04:18:21 +0100
Sebastian Rasmussen <sebras@gmail.com>
a92e38603902b22c5b20fecefa5da3d2a233516c

> jbig2dec: Only print repeated error/warning messages once.
> base/sjbig2.c
> base/sjbig2.h
> jbig2dec/jbig2dec.c

2018-11-14 14:28:48 +0000
Ken Sharp <ken.sharp@artifex.com>
3bb28e08002ef4a90bddb05aa6cd06a256153663

> PS interpreter - Throw error from exp when base is 0 and -ve exponent
> Bug #700181 "using exp with 0 as base"
> If base is 0, and exp is negative, then the result of exp is undefined
> we should throw an error instead of pushing #INF.0 on the stack.
> psi/zmath.c

2018-11-14 09:50:08 +0000
Chris Liddell <chris.liddell@artifex.com>
35766ceb3b28aad95bd63655b1d621a82d3a5b06

> Bug 700176: check the *output* device for LockSafetyParams
> When calling .setdevice we were checking if LockSafetyParams was set, and if so
> throwing an invalidaccess error.
> The problem is, if another device, for example the pdf14 compositor is the 'top'
> device, that does not (and cannot) honour LockSafetyParams.
> To solve this, we'll now use the (relatively new) gxdso_current_output_device
> spec_op to retrieve the *actual* output device, and check the LockSafetyParams
> flag in that.
> psi/zdevice.c

2018-11-14 09:31:10 +0000
Ken Sharp <ken.sharp@artifex.com>
548bb434e81dadcc9f71adf891a3ef5bea8e2b4e

> PS interpreter - add some type checking
> These were 'probably' safe anyway, since they mostly treat the objects
> as integers without checking, which at least can't result in a crash.
> Nevertheless, we ought to check.
> The return from comparedictkeys could be wrong if one of the keys had
> a value which was not an array, it could incorrectly decide the two
> were in fact the same.
> psi/zbfont.c
> psi/zcolor.c
> psi/zcrd.c
> psi/zfjpx.c
> psi/zfont.c
> psi/zfont0.c
> psi/zimage3.c
> psi/ztrans.c

2018-11-14 09:27:00 +0000
Ken Sharp <ken.sharp@artifex.com>
ef252e7dc214bcbd9a2539216aab9202848602bb

> Bug #700168 - add a type check
> Bug #700168 "Type confusion in JBIG2Decode"
> The code was assuming that .jbig2globalctx was a structure allocated
> by the graphics library, without checking.
> Add a check to see that it is a structure and that its the correct
> type of structure.
> psi/zfjbig2.c

2018-11-14 09:25:13 +0000
Ken Sharp <ken.sharp@artifex.com>
67d760ab775dae4efe803b5944b0439aa3c0b04a

> Bug #700169 - unchecked type
> Bug #700169 "Type confusion in setcolorspace"
> In seticc() we extract "Name" from a dictionary, if it succeeds we then
> use it as a string, without checking the type to see if it is in fact
> a string.
> Add a check on the type, and add a couple to check that 'N' is an integer
> in a few places too.
> psi/zicc.c

2018-11-12 17:21:33 +0000
Chris Liddell <chris.liddell@artifex.com>
3005fcb9bb160af199e761e03bc70a9f249a987e

> Bug 700153: restore: always check available stack
> Previously, we were checking there was enough stack space available when the
> restore operation required a device change, but since we have to use
> Postscript to reset the userparams (ick!), we need the stack check even when
> not changing the device.
> psi/zdevice2.c

2018-11-07 12:22:59 +0000
Chris Liddell <chris.liddell@artifex.com>
2f99c138cf60d75621eb03ae924453b968274694

> Contrib devices: Check for error return opening output file
> 09-59.PS cycles through every available device, attempting to open each one.
> For many devices this results in an invalid configuration (mainly a lack of
> output file).
> These devices, on being shutdown, ignored the lack of output file, and attempted
> to write their final bytes out anyway (attempting to write data to a null
> FILE * pointer), causing a segfault.
> We now check the return value of gdev_prn_open_printer() and only write those
> final bytes if gdev_prn_open_printer() completed successfully.
> contrib/japanese/gdevespg.c
> contrib/japanese/gdevnpdl.c
> contrib/lips4/gdevl4r.c

2018-11-08 14:43:32 +0000
Ken Sharp <ken.sharp@artifex.com>
7c8f85a23db24031945af3cacb2c0b4740e67072

> PS interpreter - check the Implementation of a Pattern before use
> Bug #700141 "Type confusion in setpattern"
> As the bug thread says, we were not checking that the Implementation
> of a pattern dictionary was a structure type, leading to a crash when
> we tried to treat it as one.
> Here we make the st_pattern1_instance and st_pattern2_instance
> structures public definitions and in zsetcolor we check the object
> stored under the Implementation key in the supplied dictionary to see if
> its a t_struct or t_astruct type, and if it is that its a
> st_pattern1_instance or st_pattern2_instance structure.
> If either check fails we throw a typecheck error.
> We need to make the st_pattern1_instance and st_pattern2_instance
> definitions public as they are defined in the graphics library and we
> need to check in the interpreter.
> base/gsptype1.c
> base/gsptype2.c
> base/gsptype2.h
> base/gxcolor2.h
> psi/zcolor.c

2018-11-08 12:58:28 +0000
Robin Watts <robin.watts@artifex.com>
4d6e2125d402033d9073bae3ccde1d95eb3ebc22

> Fix missing images due to transform_pixel_region and pattern_accumulator.
> The pattern_accumulator was defaulting to the forwarding version
> of transform_pixel_region, which was only dealing with the image
> plane, not the mask. Accordingly nothing was being plotted.
> Instead, use the default, which devolves to copy_color (for the
> image data) and fill_rectangle (for the mask).
> base/gxpcmap.c

2018-11-07 16:03:59 +0000
Chris Liddell <chris.liddell@artifex.com>
e477875e170d738d7ea1497e1489a6d344c3ef29

> Dates, change log, etc for 9.26 rc1
> base/gscdef.c
> doc/DLL.htm
> doc/Deprecated.htm
> doc/Develop.htm
> doc/Devices.htm
> doc/Drivers.htm
> doc/Fonts.htm
> doc/History9.htm
> doc/Install.htm
> doc/Language.htm
> doc/Lib.htm
> doc/Make.htm
> doc/News.htm
> doc/Ps-style.htm
> doc/Ps2epsi.htm
> doc/Psfiles.htm
> doc/Readme.htm
> doc/Release.htm
> doc/SavedPages.htm
> doc/Source.htm
> doc/Unix-lpr.htm
> doc/Use.htm
> doc/VectorDevices.htm
> doc/WhatIsGS.htm
> doc/gs-vms.hlp
> doc/sample_downscale_device.htm
> doc/subclass.htm
> doc/thirdparty.htm
> man/dvipdf.1
> man/gs.1
> man/gslp.1
> man/gsnd.1
> man/pdf2dsc.1
> man/pdf2ps.1
> man/pf2afm.1
> man/pfbtopfa.1
> man/printafm.1
> man/ps2ascii.1
> man/ps2epsi.1
> man/ps2pdf.1
> man/ps2pdfwr.1
> man/ps2ps.1

## Version 9.26 (2018-11-20)

Highlights in this release include:

- Security issues have been the primary focus of this release, including solving several (well publicised) real and potential exploits.

  PLEASE NOTE: We strongly urge users to upgrade to this latest release to avoid these issues.

- IMPORTANT: We are in the process of forking LittleCMS. LCMS2 is not thread safe, and cannot be made thread safe without breaking the ABI. Our fork will be thread safe, and include performance enhancements (these changes have all be been offered and rejected upstream). We will maintain compatibility between Ghostscript and LCMS2 for a time, but not in perpetuity. Our fork will be available as its own package separately from Ghostscript (and MuPDF).

- Thanks to Man Yue Mo of Semmle Security Research Team, Jens Müller of Ruhr-Universität Bochum and Tavis Ormandy of Google's Project Zero for their help to identify specific security issues.

- The usual round of bug fixes, compatibility changes, and incremental improvements.

For a list of open issues, or to report problems, please visit bugs.ghostscript.com.

### Incompatible changes

- None

### Changelog

2018-11-20 09:51:17 +0000
Chris Liddell <chris.liddell@artifex.com>
d66acfae372e39e8cbc4ce6395b4451cac72516e

> Dates etc for 9.26 release
> base/gscdef.c
> base/version.mak
> doc/DLL.htm
> doc/Deprecated.htm
> doc/Develop.htm
> doc/Devices.htm
> doc/Drivers.htm
> doc/Fonts.htm
> doc/History9.htm
> doc/Install.htm
> doc/Language.htm
> doc/Lib.htm
> doc/Make.htm
> doc/News.htm
> doc/Ps-style.htm
> doc/Ps2epsi.htm
> doc/Psfiles.htm
> doc/Readme.htm
> doc/Release.htm
> doc/SavedPages.htm
> doc/Source.htm
> doc/Unix-lpr.htm
> doc/Use.htm
> doc/VectorDevices.htm
> doc/WhatIsGS.htm
> doc/gs-vms.hlp
> doc/sample_downscale_device.htm
> doc/subclass.htm
> doc/thirdparty.htm
> man/dvipdf.1
> man/gs.1
> man/gslp.1
> man/gsnd.1
> man/pdf2dsc.1
> man/pdf2ps.1
> man/pf2afm.1
> man/pfbtopfa.1
> man/printafm.1
> man/ps2ascii.1
> man/ps2epsi.1
> man/ps2pdf.1
> man/ps2pdfwr.1
> man/ps2ps.1

2018-11-19 09:28:41 +0000
Chris Liddell <chris.liddell@artifex.com>
e5978ae6d1e4f3dee0a2838ed580b0373e102613

> Coverity CIDs: 326829, 326828 and 326827
> Check return values for gdev_prn_open_printer()
> contrib/gdevgdi.c
> contrib/japanese/gdevrpdl.c
> devices/gdevdjet.c

2018-11-19 09:00:54 +0000
Ken Sharp <ken.sharp@artifex.com>
a4228a0d8d657fca3bb3becb93a43fae061beae8

> Coverity ID 327264 - move pointer NULL check
> Due to recent changes in this code, the pointer was being dereferenced
> before we checked it to see if it was NULL. Moe the check so that we
> check for NULL before dereferencing.
> The 'pvalue' of the operand can be NULL, even if the object is a t_device
> type, because invalidate_stack_devices traverses the operand stack
> looking for devices, and sets their pvalue member to NULL in order to
> invalidate them so that they cannot be used.
> psi/zdevice.c

2018-11-17 11:20:08 +0000
Ken Sharp <ken.sharp@artifex.com>
c796ccb512ac581f5ac492fda8807d41769c47e8

> Check structure types when using the r_ptr macro
> Two more places where we were using the r_ptr macro to cast a PostScript
> ref object into a structure without thoroughly checking that the object
> was in fact a structure of the correct type.
> One case did a partial check, but this is more robust.
> base/gsfcid2.c
> base/gsfcmap.c
> psi/zdscpars.c
> psi/zfcmap.c

2018-11-17 10:00:32 +0000
Ken Sharp <ken.sharp@artifex.com>
cb9bb72643e95383bcacd88ab718565f3df9a510

> Coverity ID 94865
> This had already been tackled, but it turns out there were a couple
> more places where tempnames wasn't freed, but Coverity only seems to
> flag them one at a time.
> psi/imain.c

2018-11-17 09:37:07 +0000
Ken Sharp <ken.sharp@artifex.com>
c69827c308b608719d786fc14c8518af4dd6b335

> Coverity ID 323322
> The new 'transform_pixel_region' method default for forwarding devices
> tests the target device to see if its NULL (some forwarding devices are
> not always forwarding devices, eg bbox), and if it is NULL then instead
> of passing the call to the target device it calls the graphics library
> default.
> Unfortunately it was passing the target device as an argument, and this
> is now certain to be NULL. In gx_default_transform_pixel_region_begin()
> we then dereference the pointer which would cause a crash.
> So instead, pass the device itself when its not actually a forwarding
> device.
> Also, some white space changes.
> base/gdevnfwd.c

2018-11-15 15:24:10 +0000
Ken Sharp <ken.sharp@artifex.com>
4548ceaf5ada7f7a4c4da5907e27fec62c1ce63d

> PS interpreter - check infinite result on exp, where possible
> Bug #700181 "using exp with 0 as base" (again)
> The reporter for the bug failed to mention this condition in the
> original report. Technically we don't always have isinf() available
> (I suspect all real compilers do these days) but where we do we can
> check the result. Where we don't, we're stuck. This mimics the
> behaviour of other math operations in Ghostscript.
> psi/zmath.c

2018-11-15 14:18:17 +0000
Ken Sharp <ken.sharp@artifex.com>
a4e3cb230bfdbf9cb5a0d30763889e58f8215ed1

> PDF interpreter - use Appearance streams for highlight annotations
> We were previously never using the Appearance stream for a highlight
> annotation, which is documented as incorrect in the PDF 2.0 spec.
> The reason we were not using it is because a very few PDF files render
> differently if we do. This is because Acrobat 'sometimes', and I cannot
> figure out the conditions for htis, ignores a perfectly valid Appearance
> and generates a new one.
> In this case a customer produced a file where the QuadPoints entry is
> incorrect. If we use the Appearance stream (as Acrobat does) then the
> rendering is correct. If we generate an appearance then, because the
> QuadPoints are incorrect, the rendering is incorrect.
> Since the PDF 2.0 specification now makes it clear that we should be
> using a supplied Appearance stream, I've chosen to change the behaviour
> so that we do.
> I've also made the text for an appearance stream slightly more robust
> and general.
> This does produce a few diffs, because of the afore-mentioned files. In
> my opinion Acrobat is incorrect in how it treats these files. Our new
> rendering is correct.
> Resource/Init/pdf_draw.ps

2018-11-14 21:04:46 +0000
Chris Liddell <chris.liddell@artifex.com>
e8be28b49c6a43db1861119288933b5a8fdbef73

> Bug 700176: Use the actual output device for both devices in setdevice
> Also fixes bug 700189.
> The pdf14 compositor device, despite being a forwarding device, does not forward
> all spec_ops to it's target, only a select few are special cased for that.
> gxdso_current_output_device needs to be included in those special cases.
> The original commit (661e8d8fb8248) changed the code to use the spec_op to
> retrieve the output device, checking that for LockSafetyParams. If
> LockSafetyParams is set, it returns an invalidaccess error if the new device
> differs from the current device.
> When we do the comparison between the two devices, we need to check the
> output device in both cases.
> This is complicated by the fact that the new device may not have ever been set
> (and thus fully initialised), and may not have a spec_op method available at
> that point.
> base/gdevp14.c
> psi/zdevice.c

2018-11-14 16:01:51 +0000
Ken Sharp <ken.sharp@artifex.com>
5db929cf393fa330bf916da37f5d2a5954a3b0c3

> PS interpreter - in seticcspace, ensure the ICC dictionary is a dict
> From a review of dict_find_string, that function does not check to see
> if the object it is passed as an argument is a dictionary, so its
> essential to make sure the argument is checked before calling.
> This is the only remaining case I could find.
> psi/zcolor.c

2018-11-13 04:18:21 +0100
Sebastian Rasmussen <sebras@gmail.com>
a92e38603902b22c5b20fecefa5da3d2a233516c

> jbig2dec: Only print repeated error/warning messages once.
> base/sjbig2.c
> base/sjbig2.h
> jbig2dec/jbig2dec.c

2018-11-14 14:28:48 +0000
Ken Sharp <ken.sharp@artifex.com>
3bb28e08002ef4a90bddb05aa6cd06a256153663

> PS interpreter - Throw error from exp when base is 0 and -ve exponent
> Bug #700181 "using exp with 0 as base"
> If base is 0, and exp is negative, then the result of exp is undefined
> we should throw an error instead of pushing #INF.0 on the stack.
> psi/zmath.c

2018-11-14 09:50:08 +0000
Chris Liddell <chris.liddell@artifex.com>
35766ceb3b28aad95bd63655b1d621a82d3a5b06

> Bug 700176: check the *output* device for LockSafetyParams
> When calling .setdevice we were checking if LockSafetyParams was set, and if so
> throwing an invalidaccess error.
> The problem is, if another device, for example the pdf14 compositor is the 'top'
> device, that does not (and cannot) honour LockSafetyParams.
> To solve this, we'll now use the (relatively new) gxdso_current_output_device
> spec_op to retrieve the *actual* output device, and check the LockSafetyParams
> flag in that.
> psi/zdevice.c

2018-11-14 09:31:10 +0000
Ken Sharp <ken.sharp@artifex.com>
548bb434e81dadcc9f71adf891a3ef5bea8e2b4e

> PS interpreter - add some type checking
> These were 'probably' safe anyway, since they mostly treat the objects
> as integers without checking, which at least can't result in a crash.
> Nevertheless, we ought to check.
> The return from comparedictkeys could be wrong if one of the keys had
> a value which was not an array, it could incorrectly decide the two
> were in fact the same.
> psi/zbfont.c
> psi/zcolor.c
> psi/zcrd.c
> psi/zfjpx.c
> psi/zfont.c
> psi/zfont0.c
> psi/zimage3.c
> psi/ztrans.c

2018-11-14 09:27:00 +0000
Ken Sharp <ken.sharp@artifex.com>
ef252e7dc214bcbd9a2539216aab9202848602bb

> Bug #700168 - add a type check
> Bug #700168 "Type confusion in JBIG2Decode"
> The code was assuming that .jbig2globalctx was a structure allocated
> by the graphics library, without checking.
> Add a check to see that it is a structure and that its the correct
> type of structure.
> psi/zfjbig2.c

2018-11-14 09:25:13 +0000
Ken Sharp <ken.sharp@artifex.com>
67d760ab775dae4efe803b5944b0439aa3c0b04a

> Bug #700169 - unchecked type
> Bug #700169 "Type confusion in setcolorspace"
> In seticc() we extract "Name" from a dictionary, if it succeeds we then
> use it as a string, without checking the type to see if it is in fact
> a string.
> Add a check on the type, and add a couple to check that 'N' is an integer
> in a few places too.
> psi/zicc.c

2018-11-12 17:21:33 +0000
Chris Liddell <chris.liddell@artifex.com>
3005fcb9bb160af199e761e03bc70a9f249a987e

> Bug 700153: restore: always check available stack
> Previously, we were checking there was enough stack space available when the
> restore operation required a device change, but since we have to use
> Postscript to reset the userparams (ick!), we need the stack check even when
> not changing the device.
> psi/zdevice2.c

2018-11-07 12:22:59 +0000
Chris Liddell <chris.liddell@artifex.com>
2f99c138cf60d75621eb03ae924453b968274694

> Contrib devices: Check for error return opening output file
> 09-59.PS cycles through every available device, attempting to open each one.
> For many devices this results in an invalid configuration (mainly a lack of
> output file).
> These devices, on being shutdown, ignored the lack of output file, and attempted
> to write their final bytes out anyway (attempting to write data to a null
> FILE * pointer), causing a segfault.
> We now check the return value of gdev_prn_open_printer() and only write those
> final bytes if gdev_prn_open_printer() completed successfully.
> contrib/japanese/gdevespg.c
> contrib/japanese/gdevnpdl.c
> contrib/lips4/gdevl4r.c

2018-11-07 16:03:59 +0000
Chris Liddell <chris.liddell@artifex.com>
ba84a01d19a60a8a9a3e834331621bb37cb44a6c

> Dates, etc for 9.26 rc1
> base/gscdef.c
> doc/DLL.htm
> doc/Deprecated.htm
> doc/Develop.htm
> doc/Devices.htm
> doc/Drivers.htm
> doc/Fonts.htm
> doc/History9.htm
> doc/Install.htm
> doc/Language.htm
> doc/Lib.htm
> doc/Make.htm
> doc/News.htm
> doc/Ps-style.htm
> doc/Ps2epsi.htm
> doc/Psfiles.htm
> doc/Readme.htm
> doc/Release.htm
> doc/SavedPages.htm
> doc/Source.htm
> doc/Unix-lpr.htm
> doc/Use.htm
> doc/VectorDevices.htm
> doc/WhatIsGS.htm
> doc/gs-vms.hlp
> doc/sample_downscale_device.htm
> doc/subclass.htm
> doc/thirdparty.htm
> man/dvipdf.1
> man/gs.1
> man/gslp.1
> man/gsnd.1
> man/pdf2dsc.1
> man/pdf2ps.1
> man/pf2afm.1
> man/pfbtopfa.1
> man/printafm.1
> man/ps2ascii.1
> man/ps2epsi.1
> man/ps2pdf.1
> man/ps2pdfwr.1
> man/ps2ps.1

2018-11-07 00:32:29 +0000
Robin Watts <robin.watts@artifex.com>
8747f40646ad2da5c405bab5a1e85fba9b71b85b

> Add nasty workaround for PXL stroking.
> Filter paths to be filled to remove 1 dimensional sections.
> base/gxpath.h
> base/gxpcopy.c
> pcl/pxl/pxpaint.c

2018-11-06 16:46:02 +0000
Chris Liddell <chris.liddell@artifex.com>
6dd9131bfa9bd2d723e745839e4bc8e5fdc817b7

> Ensure stream and string persist as long as required
> When we create an ICC based color space from a string source, we create a stream
> object, with the stream data coming from that string.
> Because the life of the ICC related objects created by the graphics library
> is not dictated by the save/restore operations in the Postscript world, we
> need to ensure that the stream and the string it references persist as long
> as the graphics library needs.
> To do this, we move the string data, and the stream object allocation into
> "system VM", that is, garbage collected, but *not* save/restore memory.
> psi/zcolor.c

2018-11-06 08:48:58 -0800
Ray Johnston <ray.johnston@artifex.com>
30ef5d0b5b14d3f4eaf7929b81aec2279933e1cc

> Fix Bug 699806: Incorrect file size from "status" on Windows.
> With commit afe8e546, I missed the use of _wstat and _stat in gp_mswin.c
> for the "status" operator. Change to use _wstat64 and _stat64 and all
> works. Tested with VS 2005 32-bit build and with VS 2015 32 and 64 bit
> builds. Note the file size reported is correct for large files even on
> a 32-bit build.
> base/gp_mswin.c

2018-11-06 12:46:38 +0000
Robin Watts <robin.watts@artifex.com>
9bb753e22cad9e4a20570267cf8bd54e5910f7f2

> Fix pattern clist data being freed with wrong memory_t.
> gx_pattern_accum_alloc was allocating the pattern clist memory
> using storage_memory->non_gc_memory. It was then being freed in
> clist_close using cdev->bandlist_memory. The two are not the
> same.
> Change the allocation to use target->memory->non_gc_memory,
> as cdev->bandlist_memory is set to that.
> base/gxpcmap.c

2018-11-06 09:51:56 +0000
Chris Liddell <chris.liddell@artifex.com>
0b0825432e04cbb95731aeb22f3db75886a4e6d8

> Bug 700133: handle out of range CIDs in CMap parsing
> Implementation Limits sections of both PLRM and PDFRM limit the size of a CID
> value to unsigned two byte values (max 65535). Acrobat and various other
> consumers seem to silently ignore values outside this range in CMaps embedded
> in PDF files.
> We now limit the CID value to no more than 65535 when parsing a CMap from a
> PDF file (and emit a warning), and *only* from a PDF file: CMap files read
> from disk, and CMaps embedded in Postscript jobs will still throw an error.
> Resource/Init/pdf_font.ps

2018-11-05 20:07:50 +0000
Robin Watts <robin.watts@artifex.com>
2b42541db28423c49cbf47549551a27e9399fd23

> Fix dev spec op warning/handling.
> My previous fiddling in this area wasn't quite right.
> Originally, the code here didn't allow any device to provide
> their own dev spec op (and the warning was hence never hit).
> In lifting that restriction, the first commit allowed devices to
> provide their own one. They then ran into the warning message.
> The second commit fixed the warning message in this case, but
> sadly left the warning message going off in many 'default' cases
> (and what is more, failed to put the prn one in).
> This one hopefully gets everything right. As the comments say
> this does feel like a hack.
> base/gdevprn.c

2018-11-05 15:32:46 +0000
Robin Watts <robin.watts@artifex.com>
d1d59a332b8c560e8949976006424439933c9c64

> Scan converter: Fix pngalpha with zero height rectangles.
> Because of the banding hack in pngalpha, zero height rectangles
> aren't always the lowest scanline in the edgebuffer.
> base/gxscanc.c

2018-11-05 14:02:51 +0000
Ken Sharp <ken.sharp@artifex.com>
85e6fd4df9bb51d5c36e7811a2bac4c52898b08c

> pdfwrite - add a performance enhancing heuristic for text processing
> Bug #700124 "pdfwrite device over 800% performance loss between 9.25 and 9.23"
> This is a heuristic attempt to resolve the reduction in performance. The
> code originally used the FontBBox to try and determine if a glven
> glyph was completely clipped out, or was at least partially drawn.
> For efficiency reasons we don't include glyphs which are clipper out
> in the pdfwrite output, reducing the PDF size.
> However in bug #699454 and bug #699571 we saw EPS files produced from
> OneVision EPSExport which include fonts with a wildly inaccurate
> FontBBox. Two commits; 6a4202691c4317a698fa23c5309ad8974fe2b003 and
> 3bf4f3ea45f0022b6cd36415f095f1bfc119fb73 resolved this.
> The initial fix considered the advance width in addition to the glyph
> width, but this proved to be insufficient with the second file which
> drew the same glyph multiple times, with an advance width of 0. The
> commit logs note that the only solution is to determine the glyph width
> accurately, which means processing the glyph program for each glyph,
> which has performance implications (ie its slower).
> In order to try and alleviate this where possible, this commit looks at
> the number of integer co-ordinates in font space by scaling the
> FontBBox by the FontMatrix. If the resulting design space is small (an
> arbitrary value of 0.1, 1e 100x100 was chosen as 'small') then we do
> not use the FontBBox, but instead use the slower accurate method.
> This may need some adjustment, and its entirely possible that it may,
> in the long term, prove unreliable and have to be removed.
> devices/vector/gdevpdte.c

2018-11-01 12:31:55 +0000
Robin Watts <robin.watts@artifex.com>
b4f29851a33ff04979bb2eb3a32ab62000c6f19c

> Avoid misleading warning message.
> If a printer device provides its own dev_spec_op parameter, the
> system prints a warning. This warning is intended to ensure that
> devices remember to call down to the default printer one, but
> appears irrespective of whether they do or not. This means it will
> confuse most users.
> Instead, introduce a debug only dso that we can use to check that
> printer devices do indeed forward properly, and use that to print
> the warning only when required.
> base/gdevprn.c
> base/gxdevsop.h

2018-11-01 08:53:01 +0000
Robin Watts <robin.watts@artifex.com>
897dc2afc509fc331e66be43fbae2b20ded142c6

> Avoid trampling on dev_spec_op when opening printer device.
> base/gdevprn.c

2018-11-01 18:24:58 +0000
Robin Watts <robin.watts@artifex.com>
1303a9a45124fdea7c4f29858ff900d2d3393c76

> Scan converter: Zero height rectangles hack.
> Spot zero height rectangles, and arrange for them to be rendered.
> base/gxscanc.c

2018-11-03 16:54:27 +0000
Robin Watts <robin.watts@artifex.com>
045239d2d00d8febf1804703019c15eb99ac1cfd

> Scan converter: Reduce bbox size.
> In some cases (specifically, the "centre of pixel" cases) we could
> have constructed the bbox to be larger than it should have been.
> Fix this here.
> This produces diffs (mainly in banded files), because the skipping
> calculations for scanlines below/above the edgebuffer can round
> very slightly differently. These diffs are all 1 pixel things.
> base/gxscanc.c

2018-11-03 14:58:05 +0000
Ken Sharp <ken.sharp@artifex.com>
d03f6e773d0c58c7799ca8f49de6298be59b4e0e

> PDF interpreter - work around type 3 fonts with no FirstChar/LastChar
> Bug #700130 "Invalid PDF file renders blank pages"
> The file (and the customer original file) has a type 3 font with a
> /Widths array, but neither of the required FirstChar or LastChar
> entries.
> With 9.25 and below this was leading to blank pages, where current code
> continued. I think because the previous code left garbage on the stack.
> This commit sets FirstChar to 0 and LastChar to the length of the
> /Widths array if either is missing.
> Resource/Init/pdf_font.ps

2018-11-03 10:40:38 +0000
Ken Sharp <ken.sharp@artifex.com>
d850ebc85cd49dd6445f7fd90f504c28c594aa32

> Fix commit 71e99
> Change dlmprintf to dmlprintf so it'll work.
> I blame the reviewer myself.
> base/gdebug.h

2018-11-03 09:29:24 +0000
Chris Liddell <chris.liddell@artifex.com>
71e99487758e464a077c6781893ce9c6eb4134df

> Add debug only printing macros
> Despite what one might think, dmprintf and co are not exclusing to debug builds
> but are always present, and functional.
> Generally, only the print macros for the -Z style debugging output are exluded
> from debug builds.
> This adds a dbgprintf and dbgmprintf family of macros which don't rely on a -Z
> option to activate them, but are only present when DEBUG is defined.
> Additionally, (in line with convention) the dbgprintf variants (rather than
> dbgmprintf) are exluded when GS_THREADSAFE is defined, since we don't have
> to a context (via a memory pointer) to ensure correct operation of stdout/stderr
> in multithreaded environments.
> base/gdebug.h

2018-11-02 13:53:55 +0000
Chris Liddell <chris.liddell@artifex.com>
5f1c1cbf68fe1f25b2a325b275992338d4d4e449

> Bug 700126: Ensure JPEG passthrough gets shuts down on error
> When an ioerror occurs, ensure we wind up the JPEG passthrough state, to
> prevent dangling pointer(s) in pdfwrite.
> base/sdct.h
> base/sdctc.c
> base/sdctd.c
> base/sjpegd.c

2018-10-23 17:19:31 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
d0abc92713b2e84eb32c67839ddec2d160b3af8d

> Bug 697545 : Prevent SEGV by propagating error code in af_loader_load_glyph.
> Propagate error by checking for return code.
> Error created using :-
> MEMENTO_FAILAT=31598 ./membin/gpcl6 -sDEVICE=pbmraw -dMaxBitmap=2000 -o /dev/null ./tests_private/pcl/pcl5cfts/fts.0270
> freetype/src/autofit/afloader.c

2018-10-31 15:30:22 +0000
Ken Sharp <ken.sharp@artifex.com>
ece5cbbd9979cd35737b00e68267762d72feb2ea

> PDF interpreter - Don't allow page stream fonts to be used for Annotations
> Bug #700096 "Poorly constructed PDF file can inappropriately reuse a Font"
> The file has a page stream which uses a Helvetica font which is embedded
> and subset, but does not have a subset prefix on the name.
> A later annotation uses Helvetica, but does not embed it. So we load
> the Helvetica from the font cache. Unfortunately, this is the subset
> font, and its Encoding is incompatible (as well as missing many glyphs)
> so we get a lot of .notdefs.
> Here we put a save and restore pair around the page contents, so that
> when we come to the annotation rendering, we have restored the font
> cache to an 'empty' state, so that we won't try to load any fonts that
> were defined in the page stream to satisfy annotation requests.
> For some peculiar reason one broken Sumatra file renders slightly
> differently with this in place, and another was wrong before, differently
> wrong now.
> Resource/Init/pdf_main.ps

2018-10-31 15:38:52 -0700
Ray Johnston <ray.johnston@artifex.com>
1ef5f08f2c2e27efa978f0010669ff22355c385f

> Fix display device DisplayFormat=16#a0800 (Separation mode) broken by f2cf6829
> The ICC profile checking needs to be told that the device supports_devn, so
> add a spec_op proc to return true when in separation mode, and add a proc for
> fill_rectangle_hl_color so that fillpage will work in Separation mode.
> This was fixed for other devices in commit 250b5e83, but the display device
> was not fixed then.
> devices/gdevdsp.c

2018-10-31 15:30:05 -0700
Ray Johnston <ray.johnston@artifex.com>
ffcfd8d291d0bc4729a4959580befe4faef48b8f

> Remove duplicate comment.
> base/gxcmap.c

2018-10-30 17:13:57 +0000
Robin Watts <robin.watts@artifex.com>
8718be6504d227b925d1015d289f13209152c286

> Scan converter fix.
> Fix 'unevenness' seen in the bottom edge of strokes in:
> tests/pdf/Bug6901014_CImg_flyer.pdf.ppmraw.300.1
> This is part of the bug tail from the "barcode" fixes where
> cursor positions at (y&255) == 0 are 'special'.
> base/gxscanc.c

2018-10-30 17:13:59 +0100
Sebastian Rasmussen <sebras@gmail.com>
73d4e5d0ac7d697d74bf31ddaed944643f0543a1

> Bug 700056: openjpeg allocator must return NULL if size too large.
> Previously if an allocation larger than ARCH_MAX_UINT was requested
> the size value was truncated and supplied to the gs allocator. Depending
> on the values involved an allocation of this truncated value may
> actually succeed. This allocation was then passed back to the openjpeg
> library as claiming that the larger, initial allocation request was
> satisfied, even though the allocation itself was actually smaller.
> This resulted in segmentation faults.
> base/sjpx_openjpeg.c

2018-09-20 20:24:47 +0800
Sebastian Rasmussen <sebras@gmail.com>
53163da329e2019e27a8876f6b2363628de2ae0f

> jbig2dec: Fix signed/unsigned mismatches.
> jbig2dec/jbig2_generic.c
> jbig2dec/jbig2_halftone.c

2018-10-29 11:12:44 -0700
Ray Johnston <ray.johnston@artifex.com>
ecb88d9bd6f6cc1ea8b4dee9f2df50da04429135

> Fix debug print in clist code -- index value was incorrect.
> base/gxclrast.c

2018-10-26 16:47:23 +0100
Robin Watts <robin.watts@artifex.com>
2be9c4dfc343adafa49c3bbce5f205f771280851

> Update mkromfs to allow for splitting data into chunks.
> Call this in the pdlromfs builds to keep the chunk size
> small enough to avoid out of memory errors during the
> build (on plancks especially).
> base/lib.mak
> base/mkromfs.c
> base/unixlink.mak
> psi/msvc.mak

2018-10-29 16:17:50 +0000
Robin Watts <robin.watts@artifex.com>
a359d37fa7c1ba7e3910b83e8672ac9a4b110518

> Add gs_font_dir_free.
> This extracts some code from pdfwrite and makes it available to
> other callers.
> base/gsfont.c
> base/gsfont.h
> devices/vector/gdevpdf.c
> pcl/pcl/pcfont.c
> pcl/pxl/pxstate.c

2018-10-25 19:46:30 +0100
Chris Liddell <chris.liddell@artifex.com>
17262b11330552fb393bbd2907a9672d0d7eee48

> Add a security policy link, and remove gsview.com link
> The link for the security policy replaces the original 'team' link.
> doc/API.htm
> doc/C-style.htm
> doc/Commprod.htm
> doc/DLL.htm
> doc/Deprecated.htm
> doc/Develop.htm
> doc/Devices.htm
> doc/Drivers.htm
> doc/Fonts.htm
> doc/History9.htm
> doc/Install.htm
> doc/Language.htm
> doc/Lib.htm
> doc/Make.htm
> doc/News.htm
> doc/Ps-style.htm
> doc/Ps2epsi.htm
> doc/Psfiles.htm
> doc/Readme.htm
> doc/Release.htm
> doc/SavedPages.htm
> doc/Source.htm
> doc/Unix-lpr.htm
> doc/Use.htm
> doc/VectorDevices.htm
> doc/WhatIsGS.htm
> doc/sample_downscale_device.htm
> doc/subclass.htm
> doc/thirdparty.htm

2018-10-25 14:30:08 +0100
Ken Sharp <ken.sharp@artifex.com>
04333a6f1344df6b5069880cafe7b190d0984601

> Fix pngalpha device with device subclassing
> Bug #699815 "Segmentation fault for pdf input to pngalpha driver"
> The pngalpha device, in pngalpha_create_buf_device() first creates an
> in-memory rendering device (image32) and then overrides two of the
> device methods with its own versions.
> This doesn't work at all when we have subclassing devices loaded, because
> the device that gets handed as the 'target' device is the head of the
> chain of devices, and the pngalpha device simply pulls the methods
> directly from that device. Note that this also wouldn't work if a
> forwarding device were present.
> We can work around it by descending the chain of devices, and pulling
> the methods from the last device in the chain instead of using the
> 'target' directly. This still feels wrong but it should at least work.
> devices/gdevpng.c

2018-10-25 09:22:14 +0100
Ken Sharp <ken.sharp@artifex.com>
ffac21a73b74c8ce01cbae406f7dd3bfd0a7ef65

> Include gsstate.h to avoid a compiler warning
> Has the definition of gs_currentcpsimode().
> psi/ztype.c

2018-10-24 13:46:14 +0100
Ken Sharp <ken.sharp@artifex.com>
be2c93dca70926069df25467a724eb787497c6f7

> Allow cvrs to operate on 64-bit integers
> Bug #700011 "cvrs may truncate integers"
> zcvrs() cast the PostScript intval to an unsigned int internally, which
> truncates 64-bit values to 32-bit values. Other similar operators are
> capable of handling 64-bit values.
> This commit casts the result to a ps_uint (PostScript unsigned int)
> which varies in size depending on the platform. If a 64-bit integer
> data type is available it will be 64-bit otherwise it will be 32-bit.
> Additionally, check CPSI mode and if it is set, cast the ps_int to an
> unsigned int in order to explicitly truncate to a 32-bit value. We use
> CPSI compatibility mode in our internal testing, and if we don't do this
> then two of the Quality Logic CET files throw errors.
> Finally add some words to Use.htm regarding the word size of platforms
> and some of the implications regarding 64-bit values in PostScript.
> doc/Use.htm
> psi/ztype.c

2018-10-23 13:40:14 +0100
Chris Liddell <chris.liddell@artifex.com>
73f7c6eb92596087a1e30123ba0cdf701f8d6006

> Bug 700023: Fix cups get/put_params LeadingEdge logic
> Custom device LeadingEdge logic in complicated as it potentially requires
> equivalent changes to changing the page size.
> For a device like cups which merely wants the LeadingEdge value stored in its
> own place it makes much more sense to allow the Ghostscript 'core' to handle
> all the logic (which it has to do anyway to ensure the rendering is correct),
> and then just copy the value into the cups specific place.
> This saves the problem, as in this case, of unexpectedly ending up with two
> LeadingEdge parameters being included in a call to put_params.
> cups/gdevcups.c

2018-10-19 13:14:24 +0100
Chris Liddell <chris.liddell@artifex.com>
8e18fcdaa2e2247363c4cc8f851f3096cc5756fa

> "Hide" a final use of a .force* operator
> There was one use of .forceput remaining that was in a regular procedure
> rather than being "hidden" behind an operator.
> In this case, it's buried in the resource machinery, and hard to access (I
> would not be confident in claiming it was impossible). This ensures it's
> not accessible.
> Resource/Init/gs_res.ps

2018-09-07 14:23:06 +0100
Chris Liddell <chris.liddell@artifex.com>
f6b11ea745395193f4f1fc8a7b09dda9913dbe72

> Bug 699740: Better handle failing to set the nulldevice
> When pushing the nulldevice, if gs_setdevice_no_erase() failed, that *could*
> mean we end up freeing the device referenced in the graphics state.
> If that happens, search back through the saved gstates to find the initial
> graphics state, and pull the initial device from there.
> This allows us to return a Fatal error code, and exit cleanly.
> base/gsdevice.c
> psi/zdevice.c

2018-10-18 14:11:45 -0600
Henry Stiles <henry.stiles@artifex.com>
09e6af81cccb5547a18baace0a792f22bc9ea927

> Fix bug# 699969 - inverted colors and misplaced graphics.
> Our testing of HP printers indicate that monochrome printers clear the
> seed row for delta row compression for each each block of adaptive
> compression data but color devices leave the row intact.
> pcl/pcl/rtraster.c

2018-10-18 13:31:08 -0600
Henry Stiles <henry.stiles@artifex.com>
635dad8721def9da27e13b849ba8e37023703501

> Remove unnecessary gs_opendevice() calls
> For reasons unknown the target device was being opened prior to the
> languages setting and opening the device with gs_setdevice_no_erase().
> This is unnecessary and apparently wrong, gs_opendevice() does not
> properly fill in the the device procedures (gx_device_fill_in_procs()).
> pcl/pl/plmain.c
> pcl/pxl/pxtop.c
> xps/xpstop.c

2018-10-18 17:26:09 +0100
Robin Watts <robin.watts@artifex.com>
eb473839eed3eeaf9acc7db4d88a3a0a8ca5f432

> Tweak htmldiff.pl to ignore empty lines without a confusing error.
> toolbin/htmldiff.pl

2018-05-07 14:51:54 +0100
Robin Watts <robin.watts@artifex.com>
e29b99f71c5bdb766e7ee57363ce37cfdcab3621

> Update transform_pixel_region with "direct 1:1" methods for memory devs.
> base/gdevdrop.c
> base/gxcmap.c
> base/gxcmap.h

2018-05-07 11:32:44 +0100
Robin Watts <robin.watts@artifex.com>
852295de5b37409b51970cb9329227f1cf573a7b

> Attempt transform_pixel_region acceleration for memory devices using templating.
> base/gdevdrop.c

2018-05-04 19:37:24 +0100
Robin Watts <robin.watts@artifex.com>
1e926e47d349d0c962c6c64c64804d18c20bf9ba

> Update clip device to be smarter about transform_pixel_region.
> When the clip device is for a single rectangle (a very common case)
> we can avoid resorting to the default transform_pixel_region routine,
> and still use the device's (possibly) optimised one.
> base/gxclip.c

2018-05-02 17:40:21 +0100
Robin Watts <robin.watts@artifex.com>
eefae1a50eb451584c2e17600933b723dbc68a0e

> Implement transform_pixel_region for memory devices.
> base/gdevdrop.c
> base/gdevmem.h

2018-04-19 12:45:14 +0100
Robin Watts <robin.watts@artifex.com>
3b8f34c00e6ed1f7b4847a55d48b8027c0b0b946

> Add "transform_pixel_region" device function.
> Use this for handling image type 4 rendering.
> The default version of this goes to rectangles. It also knows how to
> send portrait images of 8bps to copy_color.
> Next step is to write versions of this for the memory mapped devices
> to know how to go direct.
> Essentially we are copying the guts of the
> image_render_color_icc_{portrait,landscape,skew} into a default
> device method, and making the code that called those functions
> call the device method instead.
> base/gdevdflt.c
> base/gdevepo.c
> base/gdevflp.c
> base/gdevmplt.c
> base/gdevnfwd.c
> base/gdevoflt.c
> base/gdevsclass.c
> base/gdevsclass.h
> base/gxclip.c
> base/gxclipm.c
> base/gxclist.c
> base/gxcmap.c
> base/gxcmap.h
> base/gxdevcli.h
> base/gxdevice.h
> base/gxi12bit.c
> base/gxicolor.c
> base/gxidata.c
> base/gximage.h
> devices/vector/gdevpdfd.c
> devices/vector/gdevpdfx.h
> doc/Drivers.htm
> windows/ghostscript.vcproj

2018-04-23 16:02:10 +0100
Robin Watts <robin.watts@artifex.com>
29113956bb0599209ca81698ab36736e373f054a

> Use copy_color for some image plotting cases.
> Avoid dropping to fill_rectangle where possible. We should be
> careful, because in some cases copy_color ends up doing
> fill_rectangle!
> base/gxicolor.c

2018-04-26 15:18:20 +0100
Robin Watts <robin.watts@artifex.com>
3d2e9a3b7b633db23b2b0f7bfdff522c48c1d4be

> Add gxdso_copy_color_is_fast.
> Default implementation returns 1 if copy_color is not the default
> (as the default drops to copy_rects).
> Also the lcvd device (as used by pdfwrite and ps2write) returns 0
> to stop us calling it in this case. The lcvd device lies about
> the width/height, and so clipping goes wrong.
> base/gdevdflt.c
> base/gxdevsop.h
> devices/vector/gdevpdfd.c

2018-10-18 12:50:55 +0100
Robin Watts <robin.watts@artifex.com>
a366c6a1f2dc882e9b3a4baf79bf7ba253bd9165

> Update htmldiff.pl
> Now properly takes formats from the input test list (though
> this can be overridden).
> toolbin/htmldiff.pl

2018-10-17 19:32:08 +0100
Robin Watts <robin.watts@artifex.com>
23c3e1dd980ec503f5d1f593557d6ebdb5a2173e

> VS solution for bmpcmp.
> toolbin/bmpcmp.sln
> toolbin/bmpcmp.vcproj

2018-10-16 16:52:25 +0100
Ken Sharp <ken.sharp@artifex.com>
1d2a714c9ac3f5cbca0015dbfbfa2fbcb5620fbe

> Remove debug code accidentally left in growPDFobjects
> Resource/Init/pdf_base.ps

2018-10-16 11:32:28 +0100
Chris Liddell <chris.liddell@artifex.com>
00f48edb588188dc9f10c4a84abdb336725769bd

> Don't push the EPO device in front of the nulldevice
> There are no bad effects from this, just pointless.
> base/gdevepo.c

2018-10-16 15:10:41 +0100
Ken Sharp <ken.sharp@artifex.com>
0bbf2de242801bdf7001db7f85c5fb3b4016e9e1

> PDF interpreter - bug in growPDFobjects when repairing PDF file
> Bug #699970 "bug in PDF repair"
> The function growPDFobjects is used to increase the size of the Objects,
> ObjectStream, Generations and IsGlobal records when the number of
> objects being recorded exceeds the size of the current record.
> The problem was that the code assumes Generations is a string, which it
> normally is. However when we are repairing a PDF file, we turn the
> string into an array, and if we need to increase the size of the
> record we need to make a larger array, not a larger string.
> This commit checks the current type of the Generations record and either
> creates a large string or larger array, working from the type of the
> existing record.
> Resource/Init/pdf_base.ps

2018-10-16 11:21:22 +0100
Chris Liddell <chris.liddell@artifex.com>
3c218c1463b9c2ff39b1ea514824815fde4853a7

> Bug 699962: Ensure device survives Postscript "callout"
> In shutting down the interpreter, we run Postscript code to remove the 'real'
> device from the graphics state (replacing it with the nulldevice). That means
> we can shutdown and free the device in the C code, without impacting the
> remaining interpreter shutdown.
> There is, however, a very small chance that, whilst running the Postcript code,
> the interpreter will trigger a garbage collection - if that happens *after*
> the device reference has been removed from the graphics state, there is no
> 'link' to the device object for the garbager to follow. Thus the device can
> be freed before control returns from executing the Postscript.
> Register the device as a garbage collector 'root': thus it is implicitly marked
> and won't be freed before control returns.
> psi/imain.c

2018-10-15 13:35:15 +0100
Ken Sharp <ken.sharp@artifex.com>
30cd347f37bfb293ffdc407397d1023628400b81

> font parsing - prevent SEGV in .cffparse
> Bug #699961 "currentcolortransfer procs crash .parsecff"
> zparsecff checked the operand for being an array (and not a packed
> array) but the returned procedures from the default currentcolortransfer
> are arrays, not packed arrays. This led to the code trying to
> dereference a NULL pointer.
> Add a specific check for the 'refs' pointer being NULL before we try
> to use it.
> Additionally, make the StartData procedure in the CFF Font Resource
> executeonly to prevent pulling the hidden .parsecff operator out and
> using it. Finally, extend this to other resource types.
> Resource/Init/gs_cff.ps
> Resource/Init/gs_cidcm.ps
> Resource/Init/gs_ciddc.ps
> Resource/Init/gs_cmap.ps
> Resource/Init/gs_res.ps
> psi/zfont2.c

2018-10-15 11:28:28 +0100
Ken Sharp <ken.sharp@artifex.com>
8d19fdf63f91f50466b08f23e2d93d37a4c5ea0b

> Make .forceput unavailable from '.policyprocs' helper dictionary
> Bug #69963 "1Policy is a dangerous operator, any callers should be odef"
> Leaving the .policyprocs dictionary with a procedure which is a simple
> wrapper for .forceput effectively leaves .forceput available.
> It seems that the only reason to have .policyprocs is to minimise the
> code in .applypolicies, so we can remove the dictionary and put the
> code straight into .applypolicies, which we can then bind and make
> executeonly, which hides the .forceput. Also, since we don't need
> .applypolicies after startup, we can undefine that from systemdict too.
> While we're here, review all the uses of .force* to make certain that
> there are no other similar cases. This showed a few places where we
> hadn't made a function executeonly, so do that too. Its probably not
> required, since I'm reasonably sure its impossible to load those
> functions as packed arrays (they are all defined as operators), but lets
> have a belt and braces approach, the additional time cost is negligible.
> Resource/Init/gs_diskn.ps
> Resource/Init/gs_dps.ps
> Resource/Init/gs_epsf.ps
> Resource/Init/gs_fonts.ps
> Resource/Init/gs_init.ps
> Resource/Init/gs_setpd.ps

2018-10-14 00:06:46 +0100
Robin Watts <robin.watts@artifex.com>
90b8faa80a4746f7f1e0966d6c56a687d2f8d333

> Pull in newly merged and updated LCMS2MT from MuPDF thirdparty repo.
> The MuPDF repo should be considered canonical, as that is
> the one that can pull in updates from upstream lcms2 easily.
> base/gsicc_lcms2mt.c
> lcms2mt/AUTHORS
> lcms2mt/ChangeLog
> lcms2mt/Projects/VC2010/jpegicc/jpegicc.vcxproj
> lcms2mt/Projects/VC2010/lcms2mt.rc
> lcms2mt/Projects/VC2010/lcms2mt.sln
> lcms2mt/Projects/VC2010/lcms2mt_DLL/lcms2mt_DLL.vcxproj
> lcms2mt/Projects/VC2010/lcms2mt_DLL/lcms2mt_DLL.vcxproj.filters
> lcms2mt/Projects/VC2010/lcms2mt_static/lcms2mt_static.vcxproj
> lcms2mt/Projects/VC2010/lcms2mt_static/lcms2mt_static.vcxproj.filters
> lcms2mt/Projects/VC2010/linkicc/linkicc.vcxproj
> lcms2mt/Projects/VC2010/psicc/psicc.vcxproj
> lcms2mt/Projects/VC2010/testbed/testbed.vcxproj
> lcms2mt/Projects/VC2010/tiffdiff/tiffdiff.vcxproj
> lcms2mt/Projects/VC2010/tifficc/tifficc.vcxproj
> lcms2mt/Projects/VC2010/transicc/transicc.vcxproj
> lcms2mt/Projects/VC2012/jpegicc/jpegicc.vcxproj
> lcms2mt/Projects/VC2012/lcms2mt_DLL/lcms2mt_DLL.vcxproj
> lcms2mt/Projects/VC2012/lcms2mt_DLL/lcms2mt_DLL.vcxproj.filters
> lcms2mt/Projects/VC2012/lcms2mt_static/lcms2mt_static.vcxproj
> lcms2mt/Projects/VC2012/lcms2mt_static/lcms2mt_static.vcxproj.filters
> lcms2mt/Projects/VC2012/linkicc/linkicc.vcxproj
> lcms2mt/Projects/VC2012/psicc/psicc.vcxproj
> lcms2mt/Projects/VC2012/testbed/testbed.vcxproj
> lcms2mt/Projects/VC2012/tiffdiff/tiffdiff.vcxproj
> lcms2mt/Projects/VC2012/tifficc/tifficc.vcxproj
> lcms2mt/Projects/VC2012/transicc/transicc.vcxproj
> lcms2mt/Projects/VC2013/jpegicc/jpegicc.vcxproj
> lcms2mt/Projects/VC2013/lcms2mt.sln
> lcms2mt/Projects/VC2013/lcms2mt_DLL/lcms2mt_DLL.vcxproj
> lcms2mt/Projects/VC2013/lcms2mt_DLL/lcms2mt_DLL.vcxproj.filters
> lcms2mt/Projects/VC2013/lcms2mt_static/lcms2mt_static.vcxproj
> lcms2mt/Projects/VC2013/lcms2mt_static/lcms2mt_static.vcxproj.filters
> lcms2mt/Projects/VC2013/linkicc/linkicc.vcxproj
> lcms2mt/Projects/VC2013/psicc/psicc.vcxproj
> lcms2mt/Projects/VC2013/testbed/testbed.vcxproj
> lcms2mt/Projects/VC2013/tiffdiff/tiffdiff.vcxproj
> lcms2mt/Projects/VC2013/tifficc/tifficc.vcxproj
> lcms2mt/Projects/VC2013/transicc/transicc.vcxproj
> lcms2mt/Projects/VC2015/jpegicc/jpegicc.vcxproj
> lcms2mt/Projects/VC2015/lcms2mt.sln
> lcms2mt/Projects/VC2015/linkicc/linkicc.vcxproj
> lcms2mt/Projects/VC2015/psicc/psicc.vcxproj
> lcms2mt/Projects/VC2015/testbed/testbed.vcxproj
> lcms2mt/Projects/VC2015/tiffdiff/tiffdiff.vcxproj
> lcms2mt/Projects/VC2015/tifficc/tifficc.vcxproj
> lcms2mt/Projects/VC2015/transicc/transicc.vcxproj
> lcms2mt/Projects/VC2017/jpegicc/jpegicc.vcxproj
> lcms2mt/Projects/VC2017/lcms2mt.sln
> lcms2mt/Projects/VC2017/lcms2mt_DLL/lcms2mt_DLL.vcxproj
> lcms2mt/Projects/VC2017/lcms2mt_static/lcms2mt_static.vcxproj
> lcms2mt/Projects/VC2017/linkicc/linkicc.vcxproj
> lcms2mt/Projects/VC2017/psicc/psicc.vcxproj
> lcms2mt/Projects/VC2017/testbed/testbed.vcxproj
> lcms2mt/Projects/VC2017/tiffdiff/tiffdiff.vcxproj
> lcms2mt/Projects/VC2017/tifficc/tifficc.vcxproj
> lcms2mt/Projects/VC2017/transicc/transicc.vcxproj
> lcms2mt/config.guess
> lcms2mt/doc/WhyThisFork.txt
> lcms2mt/include/lcms2mt.h
> lcms2mt/include/lcms2mt_plugin.h
> lcms2mt/ltmain.sh
> lcms2mt/src/cmsalpha.c
> lcms2mt/src/cmscgats.c
> lcms2mt/src/cmscnvrt.c
> lcms2mt/src/cmserr.c
> lcms2mt/src/cmsgamma.c
> lcms2mt/src/cmsgmt.c
> lcms2mt/src/cmshalf.c
> lcms2mt/src/cmsintrp.c
> lcms2mt/src/cmsio0.c
> lcms2mt/src/cmsio1.c
> lcms2mt/src/cmslut.c
> lcms2mt/src/cmsmd5.c
> lcms2mt/src/cmsnamed.c
> lcms2mt/src/cmsopt.c
> lcms2mt/src/cmspack.c
> lcms2mt/src/cmsplugin.c
> lcms2mt/src/cmsps2.c
> lcms2mt/src/cmssamp.c
> lcms2mt/src/cmssm.c
> lcms2mt/src/cmstypes.c
> lcms2mt/src/cmsvirt.c
> lcms2mt/src/cmsxform.c
> lcms2mt/src/extra_xform.h
> lcms2mt/src/lcms2_internal.h
> lcms2mt/src/lcms2mt.def
> lcms2mt/testbed/Makefile.am
> lcms2mt/testbed/Makefile.in
> lcms2mt/testbed/testcms2.c
> lcms2mt/testbed/testcms2.h
> lcms2mt/testbed/testplugin.c
> lcms2mt/testbed/zoo_icc.c
> lcms2mt/utils/common/utils.h
> lcms2mt/utils/common/vprf.c
> lcms2mt/utils/delphi/lcms2dll.pas
> lcms2mt/utils/jpgicc/jpgicc.c
> lcms2mt/utils/linkicc/linkicc.c
> lcms2mt/utils/psicc/Makefile.am
> lcms2mt/utils/psicc/psicc.c
> lcms2mt/utils/samples/itufax.c
> lcms2mt/utils/samples/roundtrip.c
> lcms2mt/utils/tificc/tifdiff.c
> lcms2mt/utils/tificc/tificc.c
> lcms2mt/utils/transicc/Makefile.am
> lcms2mt/utils/transicc/transicc.c

2018-10-14 18:00:24 +0100
Robin Watts <robin.watts@artifex.com>
fc61ee05129b7cafb22dbce5b93c9a80d30433f7

> Enable Trapping by default.
> base/gxdownscale.c
> doc/Devices.htm

2018-10-12 10:54:09 -0700
Ray Johnston <ray.johnston@artifex.com>
45b1d1079b563fc1722ebfb2037b80567b9932ff

> Bug 699935: Change to allow GSView 5 to work with current Ghostscript.
> In 2016, a change was made to consult the ProcessColorModel in order to
> determine if PDF needed special Overprint Transparency handling, but for
> some reason, the GSView display device doesn't have this paramemter in
> the pagedevice dictionary. Change to rely on the /Colors parameter being
> less than 4 for devices that don't need special Overprint trans handling.
> Resource/Init/pdf_main.ps

2018-10-11 15:21:30 +0100
Robin Watts <robin.watts@artifex.com>
45450eb49522afc5ed177d93c142d0c049a864e0

> Bug 699800: Fix the previous scan converter fix
> There were cases where we still weren't handling the cursor
> being on the edge of a pixel correctly, leading to asserts
> and spurious horizontal lines on images.
> base/gxscanc.c

2018-10-08 18:24:23 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
612d81e94ed0249a8e6fd15e33f409207904ecba

> Bug 697545 : Prevent SEGV by propagating error code in tt_find_table.
> Propagate error code by checking for return code from access function call.
> Prevent SEGV during pcl_text by checking if a font file is loaded before
> trying to use a font.
> Error created using :-
> MEMENTO_FAILAT=19130 ./membin/gpcl6 -sDEVICE=pbmraw -dMaxBitmap=2000 -o /dev/null ./tests_private/pcl/pcl5cfts/fts.0210
> pcl/pcl/pcpage.c
> pcl/pcl/pctext.c
> pcl/pcl/pcursor.c
> pcl/pcl/pcursor.h
> pcl/pl/plchar.c

2018-10-10 23:25:51 +0100
Chris Liddell <chris.liddell@artifex.com>
a5a9bf8c6a63aa4ac6874234fe8cd63e72077291

> Bug 699938: .loadfontloop must be an operator
> In the fix for Bug 699816, I omitted to make .loadfontloop into an operator, to
> better hide .forceundef and .putgstringcopy.
> Resource/Init/gs_fonts.ps

2018-10-11 12:22:54 +0100
Ken Sharp <ken.sharp@artifex.com>
262f94222e6965e639e92b920951ff75c2d8f081

> Fix mswinpr2 device with subclassing
> Bug # 699934 "mswinpr2 creates empty print jobs (with some printer drivers)"
> The mswinpr2 device has a bizarre check in it, to see if the device is a
> copy produced by copydevice. Its not clear to me why it does this, and
> the code is very old. It looks to me like this should fail if the device
> *is* a copy produced by copydevice, for the same reason it does with
> subclassing, the Windows-specific parts are set to NULL.
> I can't seem to provoke the device to go through this path in normal
> operation, so I'm not going to try and remove it. Instead I've added
> to the test a check to see if the device has been subclassed. If it has
> we no longer reset the Windows-specific parts of the device, but carry
> on using what we have.
> While we are here, remove the annoying wdev macro which simply makes
> it hard to debug. Especially when the macro has different definitions
> in different parts of the source file!
> devices/gdevwpr2.c

2018-10-10 16:24:38 +0100
Chris Liddell <chris.liddell@artifex.com>
bf9f3f1536487b4d67643ac3d8bddd149a2b3fa0

> Close a device before any other 'finalize' actions
> Previously, when a device object was being finalized, we were calling the
> device's own finalize method, and (possibly) freeing the reference counted
> icc data before calling gs_closedevice() to ensure the device is genuinely
> closed.
> Reorder the operations so closing the device is the *first* thing we do.
> base/gdevsclass.c
> base/gsdevice.c

2018-10-10 15:48:33 +0100
Chris Liddell <chris.liddell@artifex.com>
b7e8af4ce9f3352631c0e1efaee9b92f9bc43bb3

> Fix a memory leak with subclassed devices (stype)
> A dynamic stype in a subclass device wasn't being free with the device - likely
> an oversight from adding the subclass device specific finalize method (rather
> than using the generic device finalize).
> If a subclassed device has a 'dynamic' stype,
> base/gdevsclass.c

2018-10-10 15:38:10 +0100
Chris Liddell <chris.liddell@artifex.com>
34cc326eb2c5695833361887fe0b32e8d987741c

> Bug 699927: don't include operator arrays in execstack output
> When we transfer the contents of the execution stack into the array, take the
> extra step of replacing any operator arrays on the stack with the operator
> that reference them.
> This prevents the contents of Postscript defined, internal only operators (those
> created with .makeoperator) being exposed via execstack (and thus, via error
> handling).
> This necessitates a change in the resource remapping 'resource', which contains
> a procedure which relies on the contents of the operators arrays being present.
> As we already had internal-only variants of countexecstack and execstack
> (.countexecstack and .execstack) - using those, and leaving thier operation
> including the operator arrays means the procedure continues to work correctly.
> Both .countexecstack and .execstack are undefined after initialization.
> Also, when we store the execstack (or part thereof) for an execstackoverflow
> error, make the same oparray/operator substitution as above for execstack.
> Resource/Init/gs_init.ps
> Resource/Init/gs_resmp.ps
> psi/int.mak
> psi/interp.c
> psi/interp.h
> psi/zcontrol.c

2018-10-10 17:12:01 +0100
Ken Sharp <ken.sharp@artifex.com>
04a517f39cc3e25a7aec9766b45aeb2144718ee6

> PDF interpreter - don't use CIDFonts from the PDF file for missing ones
> Bug #699937 "Poorly constructed PDF file can inappropriately reuse a CIDFont"
> If we find a CIDFont is not defined (the FontDescriptor has no FontFile
> entry) then we need to find a substitute. Normally this means going
> to disk and either loading an explicit (user supplied) substitute, or
> using a fallback CIDFont.
> However, if the PDF file had defined a CIDFont with the same name
> previously, we could use that instead. If the CIDFont was a complete
> font this should be absolutely fine. However in this the CIDFont is a
> *subset* font, but not identified as such. Using that font leads to
> missing text....
> This commit continues to use resourcestatus to locate a substitute
> CIDFont, but it checks the 'status' flag. If its 0 then that means we
> created it via an explicit defineresource, which means (I believe and
> testing seems to confirm) that we created it from the PDF file. If its
> 1 or 2, then it was loaded from disk as a substitute (or is available
> but not in VM, ie its on disk).
> So if status is 0, don't use this CIDFont, it might not be reliable,
> instead force an excursion to disk and load a substitute from there.
> Tested with an explicit substitution defined in cidfmap to make sure
> that this does not break at the same time. NB! If a PDF file does
> define a CIDFont of the same name, then we won't (I believe) be able
> to load the explicit CIDFont resource, we will always fall back to the
> default.
> Resource/Init/pdf_font.ps

2018-10-09 19:42:34 +0100
Robin Watts <robin.watts@artifex.com>
7f26bbdc84818f5ecf32c726ff8c15dbb6a94485

> Add avx2 option to clusterpush.pl
> toolbin/localcluster/clusterpush.pl

2018-10-09 15:34:59 +0100
Chris Liddell <chris.liddell@artifex.com>
f1a078763387dde6972b30ee55a4b985d4d130bb

> Explicitly exclude /unknownerror from the SAFERERRORLIST
> Since we remove /unknownerror from errordict, we want to exclude it from the
> list we copy to gserrordict for SAFERERRORS
> Resource/Init/gs_init.ps

2018-10-08 18:52:39 +0100
Chris Liddell <chris.liddell@artifex.com>
7df67ad89e59e1c93684eb48cef2b907076e19bc

> Ensure 'token' errors are reported correctly.
> Previously, any error that occurred during the actual token scanning part of
> 'token' would actually report an error against the internal operator:
> '%token_continue'.
> This commit ensures that such errors are reported against 'token'.
> psi/ztoken.c

2018-10-02 16:02:58 +0100
Chris Liddell <chris.liddell@artifex.com>
a6807394bd94b708be24758287b606154daaaed9

> For hidden operators, pass a name object to error handler.
> In normal operation, Postscript error handlers are passed the object which
> triggered the error: this is invariably an operator object.
> The issue arises when an error is triggered by an operator which is for internal
> use only, and that operator is then passed to the error handler, meaning it
> becomes visible to the error handler code.
> By converting to a name object, the error message is still valid, but we no
> longer expose internal use only operators.
> The change in gs_dps1.ps is related to the above: previously an error in
> scheck would throw an error against .gcheck, but as .gcheck is now a hidden
> operator, it resulted in a name object being passed to the error handler. As
> scheck is a 'real' operator, it's better to use the real operator, rather than
> the name of an internal, hidden one.
> Resource/Init/gs_dps1.ps
> psi/interp.c

2018-10-04 10:42:13 +0100
Chris Liddell <chris.liddell@artifex.com>
1778db6bc10a8d60dfe986b22d2300326733ddd6

> Bug 699832: add control over hiding error handlers.
> With a previous commit changing error handling in SAFER so the handler gets
> passed a name object (rather than executable object), it is less critical to
> hide the error handlers.
> This introduces a -dSAFERERRORS option to force only use of the default error
> handlers.
> It also adds a .setsafererrors Postscript call, meaning a caller, without
> -dSAFERERRORS, can create their own default error handlers (in errordict, as
> normal), and then call .setsafererrors meaning their own handlers are always
> called.
> With -dSAFERERRORS or after a call to .setsafererrors, .setsafererrors is
> removed.
> Resource/Init/gs_init.ps
> psi/interp.c

2018-09-29 15:34:55 +0100
Chris Liddell <chris.liddell@artifex.com>
a54c9e61e7d02bbc620bcba9b1c208462a876afb

> Bug 699816: Improve hiding of security critical custom operators
> Make procedures that use .forceput/.forcedef/.forceundef into operators.
> The result of this is that errors get reported against the "top" operator,
> rather than the "called" operator within the procedure.
> For example:
> /myproc
> {
> myop
> } bind def
> If 'myop' throws an error, the error handler will be passed the 'myop'
> operator. Promoting 'myproc' to a operator means the error handler will be
> passed 'myproc'.
> Resource/Init/gs_diskn.ps
> Resource/Init/gs_dps.ps
> Resource/Init/gs_fntem.ps
> Resource/Init/gs_fonts.ps
> Resource/Init/gs_lev2.ps
> Resource/Init/gs_pdfwr.ps
> Resource/Init/gs_setpd.ps
> Resource/Init/gs_typ32.ps
> Resource/Init/gs_type1.ps
> Resource/Init/pdf_base.ps
> Resource/Init/pdf_draw.ps
> Resource/Init/pdf_font.ps
> Resource/Init/pdf_main.ps
> Resource/Init/pdf_ops.ps

2018-09-26 20:42:32 +0100
Robin Watts <robin.watts@artifex.com>
702f6982b63fca353d9106d2dbb6bb21f826c2e6

> Bug 699800: Fix scan converter problem seen with barcodes.
> The new scan converter is incorrectly counting a pixel as being
> touched if a line moves horizontally across the bottom edge of
> that pixel.
> This means that paths (for example) carefully constructed to cover
> exactly a single pixel, such as:
> 0 0 moveto 1 0 lineto 1 1 lineto 0 1 lineto closepath fill
> (when rendered at 72dpi) will fill 2 pixels, rather than 1.
> The fix is rather more involved that you'd like, as we need to
> treat the cursor being on this vertical edge as a special case.
> We flush and "null" the cursor when we arrive on such an edge,
> and ignore horizontal motion across such edges.
> The identical fixes are required both for trap and rect filling.
> base/gxscanc.c

2018-10-08 09:24:22 +0100
Chris Liddell <chris.liddell@artifex.com>
a73071b87a61acf1237da5ad9da59bae9316fb8c

> Bug 699907: Reinstate GTK+ 2.x.x code.
> The fix (from March 2018) for deprecated API calls in the GTK+ 3.x.x API
> didn't account for the new, supported methods not being available in
> GTK+ 2.x.x. Handle both cases, as we do elsewhere.
> psi/dxmain.c

2018-10-03 17:47:06 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
0269a72336f210c1736efbf0916a41be4d808d5d

> Bug 697545 : Prevent SEGV after calling gs_image_class_1_simple.
> Prevent SEGV if memory allocation fails leading to penum being freed but then
> used again later.
> Error created using :-
> MEMENTO_FAILAT=20913 ./membin/gpcl6 -sDEVICE=pbmraw -dMaxBitmap=2000 -o /dev/null ./tests_private/pcl/pcl5cfts/fts.0100
> base/gxifast.c

2018-09-25 22:25:26 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
52a37b63bb49e221c3f1b5d1ee11b63ce69da1f0

> Bug 697545 : Prevent SEGV in gs_setdevice_no_erase.
> Prevent SEGV if gsicc_init_iccmanager fails.
> Error created using :-
> MEMENTO_FAILAT=350 ./membin/gpcl6 -sDEVICE=pbmraw -dMaxBitmap=2000 -o /dev/null ./tests_private/pcl/pcl5cfts/fts.0070
> base/gsdevice.c

2018-10-03 17:00:28 +0100
Ken Sharp <ken.sharp@artifex.com>
0a7e5a1c309fa0911b892fa40996a7d55d90bace

> PDF interpreter - limit page tree recusrsion checking
> Bug #699856 "Attempting to open a carefully crafted PDF file results in long-running computation"
> A sufficiently bad page tree can lead to us taking significant amounts
> of time when checking the tree for recursion.
> We can limit this by noting the number of pages in the root node
> (given by /Count) and stopping the recursion check when we have
> encountered that many leaf nodes.
> Our other recursion checks work by reading the resources from the page
> nodes and so are unaffected by this.
> Resource/Init/pdf_main.ps

2018-10-03 14:48:48 +0100
Chris Liddell <chris.liddell@artifex.com>
d06af15c447f821309cabb0dba5ff97ce1ea4c99

> Bug 699857: don't push userdict in preparation for Type 1 fonts
> Apparently, Fontographer fonts require a writable dictionary on the
> dict stack. For some reason lost in mists of time, we pushed userdict for that
> purpose - the problem is, that leaves any random redefinition of operators in
> place when we interpret the font file.
> Instead, we now push an empty, temporary dictionary for those Fontographer
> fonts. As we already explicitly push systemdict (before the writable dictionary)
> that ensures a consistent environment for the interpretation of Type 1 fonts.
> Resource/Init/gs_type1.ps

2018-09-30 22:57:33 +0100
Ken Sharp <ken.sharp@artifex.com>
cbdc54055b7db024951daf3dcb3cafe0af458e47

> Change device put_image method to match the other methods in the API
> The put_image device method was unique in that the device parameter
> passed to the method was not a pointer to a device structure of the
> device implementing the method, but was a pointer to a device
> structure describing a memory device.
> This allowed the memory device to use code from the underlying device,
> which knows how its page buffer is laid out, but data from the memory
> device which rendered the composited transparent operations.
> However, this doesn't work at all if we have a chain of devices because
> the device method which we pull from the device at the head of the
> chain, is not the method used to actually rendeer to the page buffer
> of the terminating deevice in the chain.
> This commit alters the prorotype to take two device pointers, one for
> the 'terget' device, and one for the memory device which executed the
> put_image. This allows the final device in the chain to use its own
> code to format the buffer pointers from the memory device, while
> allowing intermediate devices to simply pass on the call.
> Note that previously a few places checked the put_image method against
> gx_default_put_image (before the device API rationalisation this was a
> check against NULL) and only called put_image if it was not the default.
> Now that we have a default implementation (which returns an error), and
> knowing that the existing device methods return an error if they do not
> implment some aspect of the memory layout, we can avoid the test
> altogether; simply call the put_image, the code is already prepared
> to deal with an error return whether that be because the device does not
> implement the method or becuase the device cannot cope with some aspect
> of the layout.
> base/gdevdflt.c
> base/gdevepo.c
> base/gdevflp.c
> base/gdevmem.c
> base/gdevmpla.c
> base/gdevnfwd.c
> base/gdevoflt.c
> base/gdevp14.c
> base/gdevsclass.c
> base/gxblend1.c
> base/gxdevcli.h
> base/gxdevice.h
> devices/gdevbit.c
> devices/gdevpng.c

2018-09-27 10:31:03 +0100
Ken Sharp <ken.sharp@artifex.com>
9565f4ca4aab712f411420fa4c8cae79a2cf88ed

> Bug 699813 "filenameforall calls bad iodev with insufficent scratch"
> This was a regression introduced with commit
> 65a9046ded8e9edd5d33bc812a9e94ae29607a1e
> I hadn't realised the cleanup procedure was expected to be called in the
> case of both the success *and* error conditions.
> psi/zfile.c

2018-09-25 15:38:14 +0100
Chris Liddell <chris.liddell@artifex.com>
f8ccc7dfb990336b1ca55f65f2e1a8ecdcb76adf

> Bug 699793: Hide the .needinput operator
> This removes the .needinput operator from systemdict, ensuring it can only
> be used in the initialization code, and not called erroneously from random
> Postscript.
> Resource/Init/gs_init.ps

2018-09-25 21:50:49 +0100
Robin Watts <robin.watts@artifex.com>
043e3d9058f414607ed8454783175db57e7e6524

> Always set the tag, even if the device won't encode it.
> Intended to sort an issue encountered while debugging bug 699809,
> namely that tag dependent ICC handling only works for devices that
> actually encode tags.
> base/gxgstate.h

2018-09-25 13:57:54 -0400
Robin Watts <Robin.Watts@artifex.com>
efe6d83852b131852550de948e7d0869c01c31f8

> Bug 699809: Fix uninitialised value for render_cond.
> gsicc_get_srcprofile doesn't return a render_cond value in
> all cases. This leads to an undefined value being read, and
> this can lead to a SEGV.
> base/gsicc_cache.c

2018-09-25 07:23:07 -0400
Robin Watts <Robin.Watts@artifex.com>
0bfd5394bc1ed6ef9e887071dc14391923e69ebf

> Bug 699809: Avoid overrunning non terminated string buffer.
> Don't call strlen on something that doesn't have a terminator.
> Use the stored length instead.
> base/gsicc_manage.c

2018-09-25 11:57:12 +0100
Chris Liddell <chris.liddell@artifex.com>
677da1c0ac20020760b372a0c8aa5546d0a30429

> Bug 699810: Explicitly set stroke color for PDF Type 3 glyphs
> When we render a cache-viable Type 3 glyphs (i.e. one that uses 'd1' rather
> than 'd0'), ensure we set the stroke color to match the fill color.
> This is necessary because if we do cache the glyph, we'll render to a mask, and
> fill the mask. On the other hand, if we have to render the glyph uncached,
> we have to ensure that the entire glyph is drawn with the same (fill) color, as
> it would be when drawn cached.
> Resource/Init/pdf_font.ps

2018-09-21 12:03:20 -0700
Ray Johnston <ray.johnston@artifex.com>
db606d2ffd204e89c812408773a15ef183ebd4b6

> Fix Bug 699794 -- device subclass open_device call must return child code
> Even with changes to detect and clean up from errors in setpagedevice (b5)
> and .bigstring, the segfault was still possible because the error return
> code from the child was being ignored, and the device is_open was set true
> when the child device was NOT open. Attempt to 'fillpage' on a clist device
> that is not open is what caused the SEGV.
> base/gdevsclass.c

2018-09-21 12:00:50 -0700
Ray Johnston <ray.johnston@artifex.com>
c29ec2fff76e45bbf9cd767ff541556c5d064be4

> Add parameter checking in setresolution
> Found in sequence for bug 699794
> Resource/Init/gs_lev2.ps

2018-09-21 11:42:19 -0700
Ray Johnston <ray.johnston@artifex.com>
379be67a6a198766e976f1e5daf43e0c0e97522a

> Add parameter type checking on .bigstring
> If the parameter is not an integer, this would leave 65400 on the stack.
> Also, if there is no argument, signal stackunderflow.
> Seen with the PS sequence of bug 699794.
> Resource/Init/gs_ll3.ps

2018-09-21 11:37:38 -0700
Ray Johnston <ray.johnston@artifex.com>
9d6ac20d9b2efdabb631a0ff9b0b0fd5c32f5e75

> Catch errors and cleanup stack on statusdict page size definitions
> This was also found with the sequence from Bug 699794, if .setpagesize
> fails, we need to clean up the two integers (page width, height) then
> signal the error. Since some definitions "load" another (e.g. b5 loads
> isob5) the command name in the error won't be correct for those, but
> it will be close. If anybody cares, we could fix it.
> Resource/Init/gs_statd.ps

2018-09-21 11:16:18 -0700
Ray Johnston <ray.johnston@artifex.com>
95aa78beae9489d5c9f898fe2032aa23f860867d

> Catch errors in setpagesize, .setpagesize and setpagedevice and cleanup
> Bug 699794 showed that attempt to change page size in SAFER mode when the
> nulldevice was the currentdevice would leave 'false' on the stack. Run
> .setdevice in stopped and clean up, and also clean up .setpagesize
> Resource/Init/gs_lev2.ps
> Resource/Init/gs_setpd.ps
> Resource/Init/gs_statd.ps

2018-09-23 16:08:23 +0100
Ken Sharp <ken.sharp@artifex.com>
863b370ba7d791720b97ae10deb211fde8bdbd0a

> pdfwrite - permit Mod and CreDate pdfmarks in PDF 2.0
> Bug 699807 "-dCompatibilityLevel=2.0` prevents all metadata from being set"
> PDF 2.0 has deprecated The Document Info dictionary, so we prevented
> pdfmarks from modifying the data in it, as a prelude to removing it
> potentially when later versions of the PDF spec are approved.
> However, as the report says, the Creation Date and Modification Date
> are still required for documents with PieceInfo (only), so for now we
> will permit those two values (only) to be set.
> devices/vector/gdevpdfm.c

2018-09-22 14:09:17 +0100
Ken Sharp <ken.sharp@artifex.com>
0fdbf706be847198be202eefd3e20fc95d60cbcb

> device subclassing - fix use of put_image in memory devices
> Bug 699799 "gswin64c.exe has stopped working"
> The cause of this is truly ugly. It seems that the put_image device
> method, uniquely, expects that the device parameter it is passed is not
> the device for which it was intended, but is instead a 'memory'
> device.
> All the implementations of put_image start by casting the gx_device *
> to a gx_device_memory *
> This is problematic, because it completely disrupts any attempt at a
> device chain. There's no way to have a device's method check to see if
> it has a child device, if its not given its owe device to work with.
> This commit hacks around the problem by descending to the terminating
> device, and copying the put_image call from there into the memory device
> which is what the pdf14 compositor will then use.
> This needs fixing properly.
> base/gdevmem.c

2017-11-30 18:39:07 -0500
Robin Watts <Robin.Watts@artifex.com>
08fb5ddb928cfc7c4cd5f348f28862d97e53d07a

> Squash warnings in gen_ordered.c
> Use ints instead of doubles, because the values only hold ints!
> base/gen_ordered.c

2018-09-21 15:28:15 +0100
Ken Sharp <ken.sharp@artifex.com>
f31702b38fba21153e26c3417c838618e7cfd16f

> pdfwrite - fix DSC comment parsing
> This may affect other DSC parsing utilities. For some reason double
> comment (%%) marks are being interpreted 'sometimes' in gs_init.ps
> as DSC comments. This only happens when reading the init files from disk
> becuase the ROM file system strips comments.
> Passing these to pdfwrite causes it to drop later DSC comments, such
> as %%Title: and %%Creator: which meant the information wasn't being
> embedded in the document information dictionary.
> Fix by converting double %% to single % comments, document this in the
> header of gs_init.ps.
> Resource/Init/gs_init.ps

2018-09-21 13:02:56 +0100
Ken Sharp <ken.sharp@artifex.com>
fac7eb144135f3ed8fbb0028ab1f33ce4dcc1985

> Check all uses of dict_find* to ensure 0 return properly handled
> dict_find and friends have the surprising quirk of returning < 0 for
> an error and > 0 for no error. But they can also return 0 which means
> 'not found' without it being an error.
> From bug 699801, if the code assumes the usual case where 0 is a success
> then an attempt might be made to use the empty dictionary slot returned
> by dict_find*, which can lead to seg faults, and certainly won't have
> the expected result.
> psi/icontext.c
> psi/zcid.c
> psi/zfapi.c
> psi/zfcid0.c
> psi/zfcid1.c
> psi/zicc.c
> psi/zpdf_r6.c
> psi/ztoken.c

2018-09-21 09:49:58 +0100
Ken Sharp <ken.sharp@artifex.com>
7ee525fd0010a4f0bb507417860e9faa058c6315

> Bug #699801 "zparse_dsc_comments can crash with invalid dsc_state"
> Although zparse_dsc_comments() does check the types of its operands, it
> wasn't checking the return value from dict_find_string properly. It was
> effectively assuming that the dictionary parameter was the *correct*
> dictionary and would contain the key/value pair it needed.
> Here we check to see if the key has not been found and throw an error
> if so.
> psi/zdscpars.c

2018-09-21 08:45:35 +0100
Chris Liddell <chris.liddell@artifex.com>
2118711d122aeb170031ab7eb80e5a9269055772

> Bug 699802: add object type check for AES key
> Make sure the key string is a string.
> psi/zfaes.c

2018-09-20 17:08:08 +0100
Ken Sharp <ken.sharp@artifex.com>
8ed08cb9904bc718ad57e0b4884a81a9227ce3ea

> Bug 699797 "setundercolorremoval memory corruption"
> What is happening is that we are not properly reference counting a
> structure.
> For setblackgeneration and setundercolorremoval we need to use a
> continuation procedure, which samples the supplied PostScript function
> and then stores the sample map.
> As part of this we create an internal structure to hold the map, and we
> make this the current undercolorremoval/blackgeneration entry in the
> graphics state. We *also* push a reference to it onto the exec stack,
> so that the continuation procedure can use it from there. However we
> don't increment the reference count.
> When we execute the 'grestore' in the function we reset the values in
> the graphics state, and because the reference count is one we count it
> down and then discard the structure.
> When we then throw an error we try to copy data off the exec stack into
> an array, when we hit the reference to the freed strcuture we potentially
> are pointing to invalid memory, leading to a seg fault.
> To fix this, increment the reference count of the object when we put
> it on the exec stack, and decrement it when we remove it from the exec
> stack.
> psi/zcolor.c

2018-09-19 18:21:02 -0700
Nancy Durgin <nancy.durgin@artifex.com>
18e8a06bd34bb51c08760b7ebdbab68ab45712c1

> Bug 699793: Fix handling of .needinput if used from interpreter
> .needinput is meant as an internal function, but it is exposed
> to the user. I couldn't see an easy way to undefine it.
> But if user calls it, it returns gs_error_Fatal in a place that the
> code wasn't expecting, and basically puts things in an undefined
> state. This change returns a Fatal error at this point, instead.
> psi/imain.c

2018-09-19 09:14:02 -0700
Nancy Durgin <nancy.durgin@artifex.com>
caa8b4c279a078419ee9c002106a84703c090d5d

> Cleanups for FAPI functions
> Fix .FAPIAvailable to check for stack underflow
> Undefine FAPI functions at end of gs_fapi.ps
> (.FAPIavailable, .FAPIpassfont, .FAPIrebuildfont)
> The rendering functions, .FAPIBuildGlyph, .FAPIBuildChar, .FAPIBuildGlyph9,
> are still defined. I noticed similar rendering funcs for other fonts are also
> exposed -- not sure if this is fixable or not.
> Resource/Init/gs_fapi.ps
> Resource/Init/gs_init.ps
> psi/zfapi.c

2018-09-20 16:35:28 +0100
Chris Liddell <chris.liddell@artifex.com>
b0222e5e39712999f22084996a6b85a120b9389e

> Bug 699795: add operand checking to .setnativefontmapbuilt
> .setnativefontmapbuilt .forceputs a value into systemdict - it is intended
> to be a boolean, but in this case was being called with a compound object
> (a dictionary). Such an object, in local VM, being forced into systemdict
> would then confuse the garbager, since it could be restored away with the
> reference remaining.
> This adds operand checking, so .setnativefontmapbuilt will simply ignore
> anything other than a boolean value, and also removes the definition of
> .setnativefontmapbuilt after use, since it is only used in two, closely
> related places.
> Resource/Init/gs_fonts.ps

2018-09-20 14:23:29 +0100
Chris Liddell <chris.liddell@artifex.com>
78ed0a8f0339dba1674285b0aa1f460a59b0c3ee

> Ensure all errors are included from initialization
> Previously only Level 1 errors were added during init.
> Resource/Init/gs_init.ps

2018-09-20 10:09:37 +0100
Ken Sharp <ken.sharp@artifex.com>
90e8f8d32b64bae015e19e85e693988daaea54f4

> Bug #699796 "copydevice fails after stack device copies invalidated"
> This isn't anything to do with .fill_identity_cmap. A simpler example
> is:
> .distillerdevice
> nulldevice
> copydevice
> The problem is that when we execute nulldevice we need to invalidate any
> copies, stored on the operand stack, of the device that was current
> before the nulldevice was installed.
> We do that by setting the pdevice member of the device structure to NULL.
> However the fact that a device can be invalidated has clearly passed
> by a number of developers in the intervening years, and a number of
> places in the code do check the type of the operand is a device, but
> they don't check to see if the device has been invalidated.
> Add validation checks where required.
> psi/idisp.c
> psi/zdevice.c

2018-09-18 14:15:55 -0700
Nancy Durgin <nancy.durgin@artifex.com>
c1657e3b874261e254d4e132499355b22f3dd46a

> Change "executeonly" to throw typecheck on gstatetype and devicetype objects
> PS doesn't really have a "devicetype", but it is not listed as an
> acceptable argument type to "executeonly", so we probably should not
> accept it.
> "gstate executeonly" throws typecheck in Acrobat, so we should do the same.
> Tested the other "access related" functions (noaccess, readonly,
> rcheck, wcheck, xcheck) and all of these accept "gstate" as an
> argument, even though the PLRM says they should not. Also our initialization
> code does things with wcheck and readonly on devices and gstates.
> So, this fix is only for "executeonly".
> psi/ztype.c

2018-09-19 13:17:45 +0100
Chris Liddell <chris.liddell@artifex.com>
476f6d039fadc33be09068ec09e55824ce089759

> Fix commit 93d13545f90c37327bf3ca7ac75c9549d7b52f6f
> The original fix was passing the px_state_t into px_process_init(), where what
> it takes is actually a px_parser_state_t.
> Fixes segfault spotted on the 32bit weekly cluster test.
> pcl/pxl/pxsessio.c
> pcl/pxl/pxtop.c

2018-09-18 21:10:33 -0600
Henry Stiles <henry.stiles@artifex.com>
93d13545f90c37327bf3ca7ac75c9549d7b52f6f

> Reset the PXL parser along with state cleanup.
> pcl/pxl/pxsessio.c

2018-09-18 11:54:58 -0700
Nancy Durgin <nancy.durgin@artifex.com>
c76bf1cb7cc419534006631ea139ae20801fd824

> Undefine some additional internal operators.
> .type, .writecvs, .setSMask, .currentSMask
> These don't seem to be referenced anywhere outside of the initialization code,
> which binds their usages. Passes cluster if they are removed.
> Resource/Init/gs_init.ps

2018-09-13 13:06:01 -0700
Nancy Durgin <nancy.durgin@artifex.com>
29d8ed33d90bea26b24995c43ad53119a943f2d6

> Fixed a bunch of incorrect parameter counts
> (Note that these were basically harmless, but they make a nice hint to the
> programmers, so it's nice if the hint is correct...)
> psi/zcolor.c
> psi/zdevice.c
> psi/zfile1.c
> psi/zform.c
> psi/zmisc.c
> psi/zvmem2.c

2018-09-17 14:06:12 +0100
Chris Liddell <chris.liddell@artifex.com>
7c3e7eee829cc3d2582e4aa7ae1fd495ca72cef1

> Implement .currentoutputdevice operator
> The currentdevice operator returns the device currently installed in the
> graphics state. This can be the output/page device, but also could be a
> forwarding device (bbox device), compositor (pdf14) or subclass device
> (erasepage optimisation, First/Last page etc).
> In certain circumstances (for example during a setpagedevice) we want to be
> sure we're retrieving the *actual* output/page device.
> The new .currentoutputdevice operator uses the spec_op device method to traverse
> any chain of devices and retrieve the final device in the chain, which
> should always be the output/page device.
> Resource/Init/gs_init.ps
> Resource/Init/gs_setpd.ps
> base/gdevdflt.c
> base/gxdevsop.h
> psi/zdevice.c

2018-09-17 10:18:16 +0100
Chris Liddell <chris.liddell@artifex.com>
8bc783cb586231da2916f423bf5793e194092679

> Bug 699778: Fix doc/* file list in base/unixinst.mak
> base/unixinst.mak

2018-09-18 08:12:00 +0100
Ken Sharp <ken.sharp@artifex.com>
442b5608a6384358e26014c8dec81c169145461e

> Documentation - fix a couple of typos
> doc/VectorDevices.htm

2018-09-17 12:14:36 +0100
Ken Sharp <ken.sharp@artifex.com>
1535333e85a2901cc873c2694c5ee8508cffd992

> Bug 699777 " -dFILTERIMAGE often loses text"
> The pdfwrite device's implementation of transparency relies upon the
> image for a Softmask being run, and pushing a clip, which increments the
> viewer state. However if we have -dFILTERIMAGE in place, then we won't
> do this (its in the pdfwrite implementation of begin_typed_image).
> When we close the transparency mask, this then leads to the viewer state
> stack being out by one.
> There's no easy way to address this, so when we go to restore the viewer
> state, if it would fall off the bottom then check to see if FILTERIMAGE
> is true. If it is, then just don't return an error.
> This is a rare condition, it relies upon the transparency being nested
> quite deeply in groups (in this case the SoftMask is nested about four
> layers deep in spurious transparency).
> devices/vector/gdevpdfg.c

2018-09-11 18:47:10 +0100
Robin Watts <robin.watts@artifex.com>
fb887f9e8a318628b2b82120e1e825343264e42c

> Remove unnecessary struct entry from pcl_interp_instance_s.
> We no longer extend the instance from the implementation.
> pcl/pcl/pctop.c
> pcl/pxl/pxtop.c

2018-09-13 15:18:03 +0100
Robin Watts <robin.watts@artifex.com>
da0910fe776cf6f28391558d01bea8953235f1f7

> VS Project: Add some missing files.
> windows/ghostpcl.vcproj

2018-09-06 19:33:06 +0100
Robin Watts <robin.watts@artifex.com>
68b679df65f8d9ffbbb4acdc2662105e440778df

> Fix "ambiguous else" warning.
> pcl/pl/plmain.c

2018-09-12 15:34:50 -0600
Henry Stiles <henry.stiles@artifex.com>
96ab2635885c40a81d6146d1f3363a019d8af93a

> Fix bug #699564 - pageside different from HP.
> The pageside should be updated only if the page is marked. Also
> refactor and simplify the Page Side Select routine.
> Thanks to Norbert Janssen for identifying and analyzing this problem.
> pcl/pcl/pcjob.c

2018-09-13 16:09:56 +0100
Chris Liddell <chris.liddell@artifex.com>
687e9a482e40d5e2fc6ac7aa66fb4791afccb949

> Tweak examples/transparency_example.ps
> So it prints a warning and runs to completion, rather than erroring out
> when -dSAFER is set.
> examples/transparency_example.ps

2018-09-10 09:25:22 +0100
Chris Liddell <chris.liddell@artifex.com>
c7b6473b425445c6d6c0637f42fdbf5536244198

> Bring master up to date with 9.25 release branch
> base/version.mak
> doc/DLL.htm
> doc/Deprecated.htm
> doc/Develop.htm
> doc/Devices.htm
> doc/Drivers.htm
> doc/Fonts.htm
> doc/History9.htm
> doc/Install.htm
> doc/Language.htm
> doc/Lib.htm
> doc/Make.htm
> doc/News.htm
> doc/Ps-style.htm
> doc/Ps2epsi.htm
> doc/Psfiles.htm
> doc/Readme.htm
> doc/Release.htm
> doc/SavedPages.htm
> doc/Source.htm
> doc/Unix-lpr.htm
> doc/Use.htm
> doc/VectorDevices.htm
> doc/WhatIsGS.htm
> doc/gs-vms.hlp
> doc/sample_downscale_device.htm
> doc/subclass.htm
> doc/thirdparty.htm
> man/dvipdf.1
> man/gs.1
> man/gslp.1
> man/gsnd.1
> man/pdf2dsc.1
> man/pdf2ps.1
> man/pf2afm.1
> man/pfbtopfa.1
> man/printafm.1
> man/ps2ascii.1
> man/ps2epsi.1
> man/ps2pdf.1
> man/ps2pdfwr.1
> man/ps2ps.1

2018-09-11 10:59:24 +0100
Chris Liddell <chris.liddell@artifex.com>
ba8eda9d8c62e34ce3fed2d22647797e29494eb7

> Bug 699757: disable epo device for x11 devices
> The epo device interferes with the operation of the x11 devices when those
> are integrating with an existing X application (i.e. xv, or other application
> that relies on the 'GHOSTVIEW' functionality).
> Disable epo by adding an x11 specific fillpage method.
> devices/gdevx.c

2018-09-11 11:12:13 +0100
Ken Sharp <ken.sharp@artifex.com>
b7c4003f6855b2e11cdda32cdf259c7005dce38b

> PDF interpreter - work around GSView 5 and PAGELABEL pdfmarks
> We added the ability to process PDF page labels as pdfmarks, instead of
> using the .pagelabels operator (as used by pdfwrite) for the benefit of
> DejaVu.
> Unfortunately, GSView 5 redefines the pdfmark operator, and attempts
> to process the information itself. This is a problem when it doesn't
> recognise the pdfmark in question, which it does not with PAGELABEL.
> There's no way for us to fix GSView 5, and we don't want to revert the
> enhancement for DejaVu because that is still being actively maintained.
> This commit is a rather ugly hack which relies upon the presence of a
> specific named dictionary in userdict when GSView is executing. If that
> dictionary is present then we don't create PAGELABEL pdfmarks, thus
> avoiding confusing GSView 5.
> Resource/Init/pdf_main.ps

2018-09-10 09:21:26 +0100
Chris Liddell <chris.liddell@artifex.com>
7fee37d18e9cbcbc99c3e0e5048a7de78f9be58e

> Move pre-release version to 9.26
> Resource/Init/gs_init.ps
> base/version.mak

2018-09-10 17:05:47 +0100
Chris Liddell <chris.liddell@artifex.com>
57c41b4d49ff949503f7d29a0f3dea0504b9e45e

> Bug 699753: Windows uninstall: remove all installed files etc
> This was partly caused by a subtlety of the nsis installer syntax which means
> the '/r' option for the 'File' operation will match and install all
> files/directories in the file heirarchy that match the search term, unless they
> are explicitly excluded.
> For example:
> File /r doc
> will end up matching:
> doc/
> something/doc
> another/thing/doc
> So, ensure we exclude subtrees so we no longer accidentally include files we
> don't intend.
> Also, add the missing removals, so we do remove eveything we intended to
> install.
> Lastly add in (and include removal of!) the Resource/* tree, and the iccprofiles
> directories - both of which users have asked to be included.
> psi/nsisinst.nsi

2018-09-10 07:42:13 -0700
Ray Johnston <ray.johnston@artifex.com>
eb1d28f6937f3692facc2f09ce540f5aa313380b

> Correct getdeviceprops documentation
> doc/Language.htm

2018-09-13 10:54:33 +0100
Chris Liddell <chris.liddell@artifex.com>
070358777b534c600c522da8541690022102b7a6

> Dates, product string, changelog, etc for 9.25 release
> base/gscdef.c
> base/version.mak
> doc/DLL.htm
> doc/Deprecated.htm
> doc/Develop.htm
> doc/Devices.htm
> doc/Drivers.htm
> doc/Fonts.htm
> doc/History9.htm
> doc/Install.htm
> doc/Language.htm
> doc/Lib.htm
> doc/Make.htm
> doc/News.htm
> doc/Ps-style.htm
> doc/Ps2epsi.htm
> doc/Psfiles.htm
> doc/Readme.htm
> doc/Release.htm
> doc/SavedPages.htm
> doc/Source.htm
> doc/Unix-lpr.htm
> doc/Use.htm
> doc/VectorDevices.htm
> doc/WhatIsGS.htm
> doc/gs-vms.hlp
> doc/sample_downscale_device.htm
> doc/subclass.htm
> doc/thirdparty.htm
> man/dvipdf.1
> man/gs.1
> man/gslp.1
> man/gsnd.1
> man/pdf2dsc.1
> man/pdf2ps.1
> man/pf2afm.1
> man/pfbtopfa.1
> man/printafm.1
> man/ps2ascii.1
> man/ps2epsi.1
> man/ps2pdf.1
> man/ps2pdfwr.1
> man/ps2ps.1

2018-09-11 10:59:24 +0100
Chris Liddell <chris.liddell@artifex.com>
4b3fbf2bca24b2833322985be390fc739d237f7d

> Bug 699757: disable epo device for x11 devices
> The epo device interferes with the operation of the x11 devices when those
> are integrating with an existing X application (i.e. xv, or other application
> that relies on the 'GHOSTVIEW' functionality).
> Disable epo by adding an x11 specific fillpage method.
> devices/gdevx.c

2018-09-11 11:12:13 +0100
Ken Sharp <ken.sharp@artifex.com>
5ac63e47077e0e7d02e99e247e0c47c4737e0cb8

> PDF interpreter - work around GSView 5 and PAGELABEL pdfmarks
> We added the ability to process PDF page labels as pdfmarks, instead of
> using the .pagelabels operator (as used by pdfwrite) for the benefit of
> DejaVu.
> Unfortunately, GSView 5 redefines the pdfmark operator, and attempts
> to process the information itself. This is a problem when it doesn't
> recognise the pdfmark in question, which it does not with PAGELABEL.
> There's no way for us to fix GSView 5, and we don't want to revert the
> enhancement for DejaVu because that is still being actively maintained.
> This commit is a rather ugly hack which relies upon the presence of a
> specific named dictionary in userdict when GSView is executing. If that
> dictionary is present then we don't create PAGELABEL pdfmarks, thus
> avoiding confusing GSView 5.
> Resource/Init/pdf_main.ps

2018-09-10 17:05:47 +0100
Chris Liddell <chris.liddell@artifex.com>
b3974730243cb449299524768fc810ad7bac4f73

> Bug 699753: Windows uninstall: remove all installed files etc
> This was partly caused by a subtlety of the nsis installer syntax which means
> the '/r' option for the 'File' operation will match and install all
> files/directories in the file heirarchy that match the search term, unless they
> are explicitly excluded.
> For example:
> File /r doc
> will end up matching:
> doc/
> something/doc
> another/thing/doc
> So, ensure we exclude subtrees so we no longer accidentally include files we
> don't intend.
> Also, add the missing removals, so we do remove eveything we intended to
> install.
> Lastly add in (and include removal of!) the Resource/* tree, and the iccprofiles
> directories - both of which users have asked to be included.
> psi/nsisinst.nsi

2018-09-10 07:42:13 -0700
Ray Johnston <ray.johnston@artifex.com>
7738ffa5136549dd0cdcdf89974e339187246998

> Correct getdeviceprops documentation
> doc/Language.htm

2018-09-10 09:54:14 +0100
Chris Liddell <chris.liddell@artifex.com>
7146378240f90bf4171ae7a2a00cc9d46eaec86d

> Add a note about unSAFERness of ps2epsi
> doc/History9.htm
> doc/News.htm

2018-09-10 09:25:22 +0100
Chris Liddell <chris.liddell@artifex.com>
4cfee19351e36543927b78b97dbf2e600daa9bfe

> Dates/news/history for 9.25 release candidate 1
> base/gscdef.c
> base/version.mak
> doc/DLL.htm
> doc/Deprecated.htm
> doc/Develop.htm
> doc/Devices.htm
> doc/Drivers.htm
> doc/Fonts.htm
> doc/History9.htm
> doc/Install.htm
> doc/Language.htm
> doc/Lib.htm
> doc/Make.htm
> doc/News.htm
> doc/Ps-style.htm
> doc/Ps2epsi.htm
> doc/Psfiles.htm
> doc/Readme.htm
> doc/Release.htm
> doc/SavedPages.htm
> doc/Source.htm
> doc/Unix-lpr.htm
> doc/Use.htm
> doc/VectorDevices.htm
> doc/WhatIsGS.htm
> doc/gs-vms.hlp
> doc/sample_downscale_device.htm
> doc/subclass.htm
> doc/thirdparty.htm
> man/dvipdf.1
> man/gs.1
> man/gslp.1
> man/gsnd.1
> man/pdf2dsc.1
> man/pdf2ps.1
> man/pf2afm.1
> man/pfbtopfa.1
> man/printafm.1
> man/ps2ascii.1
> man/ps2epsi.1
> man/ps2pdf.1
> man/ps2pdfwr.1
> man/ps2ps.1

## Version 9.25 (2018-09-13)

Highlights in this release include:

- This release fixes problems with argument handling, some unintended results of the security fixes to the SAFER file access restrictions (specifically accessing ICC profile files), and some additional security issues over the recent 9.24 release.

- Security issues have been the primary focus of this release, including solving several (well publicised) real and potential exploits.

  PLEASE NOTE: We strongly urge users to upgrade to this latest release to avoid these issues.

- As well as Ghostscript itself, jbig2dec has had a significant amount of work improving its robustness in the face of out specification files.

- IMPORTANT: We are in the process of forking LittleCMS. LCMS2 is not thread safe, and cannot be made thread safe without breaking the ABI. Our fork will be thread safe, and include performance enhancements (these changes have all be been offered and rejected upstream). We will maintain compatibility between Ghostscript and LCMS2 for a time, but not in perpetuity. Our fork will be available as its own package separately from Ghostscript (and MuPDF).

- The usual round of bug fixes, compatibility changes, and incremental improvements.

For a list of open issues, or to report problems, please visit bugs.ghostscript.com.

### Incompatible changes

- None

### Changelog

2018-09-13 10:54:33 +0100
Chris Liddell <chris.liddell@artifex.com>
2f00215a28bcc43bb5857081378a6d956ef8b9d5

> Dates, product string, etc for 9.25 release
> base/gscdef.c
> base/version.mak
> doc/DLL.htm
> doc/Deprecated.htm
> doc/Develop.htm
> doc/Devices.htm
> doc/Drivers.htm
> doc/Fonts.htm
> doc/History9.htm
> doc/Install.htm
> doc/Language.htm
> doc/Lib.htm
> doc/Make.htm
> doc/News.htm
> doc/Ps-style.htm
> doc/Ps2epsi.htm
> doc/Psfiles.htm
> doc/Readme.htm
> doc/Release.htm
> doc/SavedPages.htm
> doc/Source.htm
> doc/Unix-lpr.htm
> doc/Use.htm
> doc/VectorDevices.htm
> doc/WhatIsGS.htm
> doc/gs-vms.hlp
> doc/sample_downscale_device.htm
> doc/subclass.htm
> doc/thirdparty.htm
> man/dvipdf.1
> man/gs.1
> man/gslp.1
> man/gsnd.1
> man/pdf2dsc.1
> man/pdf2ps.1
> man/pf2afm.1
> man/pfbtopfa.1
> man/printafm.1
> man/ps2ascii.1
> man/ps2epsi.1
> man/ps2pdf.1
> man/ps2pdfwr.1
> man/ps2ps.1

2018-09-11 10:59:24 +0100
Chris Liddell <chris.liddell@artifex.com>
4b3fbf2bca24b2833322985be390fc739d237f7d

> Bug 699757: disable epo device for x11 devices
> The epo device interferes with the operation of the x11 devices when those
> are integrating with an existing X application (i.e. xv, or other application
> that relies on the 'GHOSTVIEW' functionality).
> Disable epo by adding an x11 specific fillpage method.
> devices/gdevx.c

2018-09-11 11:12:13 +0100
Ken Sharp <ken.sharp@artifex.com>
5ac63e47077e0e7d02e99e247e0c47c4737e0cb8

> PDF interpreter - work around GSView 5 and PAGELABEL pdfmarks
> We added the ability to process PDF page labels as pdfmarks, instead of
> using the .pagelabels operator (as used by pdfwrite) for the benefit of
> DejaVu.
> Unfortunately, GSView 5 redefines the pdfmark operator, and attempts
> to process the information itself. This is a problem when it doesn't
> recognise the pdfmark in question, which it does not with PAGELABEL.
> There's no way for us to fix GSView 5, and we don't want to revert the
> enhancement for DejaVu because that is still being actively maintained.
> This commit is a rather ugly hack which relies upon the presence of a
> specific named dictionary in userdict when GSView is executing. If that
> dictionary is present then we don't create PAGELABEL pdfmarks, thus
> avoiding confusing GSView 5.
> Resource/Init/pdf_main.ps

2018-09-10 17:05:47 +0100
Chris Liddell <chris.liddell@artifex.com>
b3974730243cb449299524768fc810ad7bac4f73

> Bug 699753: Windows uninstall: remove all installed files etc
> This was partly caused by a subtlety of the nsis installer syntax which means
> the '/r' option for the 'File' operation will match and install all
> files/directories in the file heirarchy that match the search term, unless they
> are explicitly excluded.
> For example:
> File /r doc
> will end up matching:
> doc/
> something/doc
> another/thing/doc
> So, ensure we exclude subtrees so we no longer accidentally include files we
> don't intend.
> Also, add the missing removals, so we do remove eveything we intended to
> install.
> Lastly add in (and include removal of!) the Resource/* tree, and the iccprofiles
> directories - both of which users have asked to be included.
> psi/nsisinst.nsi

2018-09-10 07:42:13 -0700
Ray Johnston <ray.johnston@artifex.com>
7738ffa5136549dd0cdcdf89974e339187246998

> Correct getdeviceprops documentation
> doc/Language.htm

2018-09-10 09:54:14 +0100
Chris Liddell <chris.liddell@artifex.com>
7146378240f90bf4171ae7a2a00cc9d46eaec86d

> Add a note about unSAFERness of ps2epsi
> doc/History9.htm
> doc/News.htm

2018-09-10 09:25:22 +0100
Chris Liddell <chris.liddell@artifex.com>
7657f3698ce5a440b069ff953e57841950919132

> Dates etc for 9.25 release candidate 1
> base/gscdef.c
> base/version.mak
> doc/DLL.htm
> doc/Deprecated.htm
> doc/Develop.htm
> doc/Devices.htm
> doc/Drivers.htm
> doc/Fonts.htm
> doc/History9.htm
> doc/Install.htm
> doc/Language.htm
> doc/Lib.htm
> doc/Make.htm
> doc/News.htm
> doc/Ps-style.htm
> doc/Ps2epsi.htm
> doc/Psfiles.htm
> doc/Readme.htm
> doc/Release.htm
> doc/SavedPages.htm
> doc/Source.htm
> doc/Unix-lpr.htm
> doc/Use.htm
> doc/VectorDevices.htm
> doc/WhatIsGS.htm
> doc/gs-vms.hlp
> doc/sample_downscale_device.htm
> doc/subclass.htm
> doc/thirdparty.htm
> man/dvipdf.1
> man/gs.1
> man/gslp.1
> man/gsnd.1
> man/pdf2dsc.1
> man/pdf2ps.1
> man/pf2afm.1
> man/pfbtopfa.1
> man/printafm.1
> man/ps2ascii.1
> man/ps2epsi.1
> man/ps2pdf.1
> man/ps2pdfwr.1
> man/ps2ps.1

2018-09-10 08:41:34 +0100
Ken Sharp <ken.sharp@artifex.com>
7b0c4cc3e79d1e689b5fc3251a1130f409ed7a82

> Bug 699748 "gs9.24/windows can't process environment variable GS_OPTIONS anymore"
> This problem only exhibits in a 64-bit build.
> The problem is caused by the union of 's' and 'file' in the arg_source
> structure. When in a 32-bit build, this happens to work out to be 0
> when the source is a string and not a file. But in a 64-bit it does not.
> Now because we have a 'is_file' member in the structure this isn't a
> problem, except that in get_codepoint() we pass both the u.file and
> u.str members to the decoding function. In get_codepoint_utf8 we then
> check to see if 'file' is 0, and if it is not, we attempt to read from
> it. If 'file' is 0, then we treat this as a string instead.
> To avoid altering the decoding function, with potential knock-on effects
> through the code, I've chosen to test the 'is_file' member and pass
> NULL for the file if this is not a file.
> base/gsargs.c

2018-09-08 09:47:19 +0100
Ken Sharp <ken.sharp@artifex.com>
95281026d983bff8f72e431c7f620a0e8d07c2af

> Bug 699744 "ps2epsi fails with Error: /undefined in --setpagedevice--"
> Recent changes required to harden SAFER mode mean that it is no longer
> possible to run this script in SAFER mode, because it relies upon
> unsafe Ghostscript non-standard extension operators.
> Removing SAFER and DELAYSAFER, and the code to reset SAFER, allow the
> program to run as well as it ever did (ie badly). This program should
> now be considered unsafe, you should not use it on untrusted PostScript
> programs.
> I think its likely we will deprecate and remove this program in future.
> lib/ps2epsi
> lib/ps2epsi.bat
> lib/ps2epsi.cmd
> lib/ps2epsi.ps

2018-09-07 10:33:41 -0700
Michael Vrhel <michael.vrhel@artifex.com>
232c2bf9db56ab32fbe5026e1b3eabdbb88380a8

> gprf device: Memory leak
> The deflate_block was not being freed after the writing of the page.
> devices/gdevgprf.c

2018-09-07 10:17:44 -0700
Michael Vrhel <michael.vrhel@artifex.com>
d4c2e30bc057bc99e8d0fac04f6ecaae4721f435

> Get formats set properly in gscms_transform_color
> The color space was not getting set in the input
> and output formats when we had a change in the lcms
> formatters.
> base/gsicc_lcms2mt.c

2018-09-07 08:54:58 +0100
Chris Liddell <chris.liddell@artifex.com>
fa78d81c37afc28950020df4accf58d7bb1d01e7

> Initialize a variable.
> Prevents static analysis tools from complaining about it being used
> uninitialized (it's being to in order to initialize it).
> psi/interp.c

2018-09-07 08:16:06 +0100
Chris Liddell <chris.liddell@artifex.com>
790f13e61ddbe232327b34665606f52b4d943676

> Tidy up adding the temp dirs to the PermitFile* arrays
> Resource/Init/gs_init.ps

2018-09-07 08:07:12 +0100
Chris Liddell <chris.liddell@artifex.com>
643b24dbd002fb9c131313253c307cf3951b3d47

> Bug 699718(2): Improve/augment stack size checking
> Improve the rebustness of the previous solution (previously it could trigger an
> error when there *was* stack capacity available).
> Remove redundant check: we don't need to check if the *current* stack size is
> sufficient, before checking the maximum permitted stack size.
> Also check the exec stack, as execstackoverflow can also cause the
> Postscript call out to fail.
> Lastly, in event of failure, put the LockSafetyParams flag back in the existing
> device (this is only necessary because we don't enfore JOBSERVER mode).
> Note: the Postscript callout (%grestorepagedevice) never pushes any dictionaries
> on the dict stack - if that changes, we should check that stack, too.
> psi/zdevice2.c

2018-09-07 08:05:52 +0100
Chris Liddell <chris.liddell@artifex.com>
7dd56d01397a40da636ad88a5d19af4e2e404e6a

> Put .setdebug back into the proc removal list for SAFER
> accidentally removed in a previous commit
> Resource/Init/gs_init.ps

2018-09-07 15:22:29 +0100
Ken Sharp <ken.sharp@artifex.com>
65a9046ded8e9edd5d33bc812a9e94ae29607a1e

> Bug #699707 "Security review bug - continuation procedures"
> As a result of the recent security review, this bug was raised to go
> through the PostScript interpreter looking for places where we exit the
> 'C' level and return control to PostScript. This is done when we need
> to evaluate something in the PostScript environment, such as a transfer
> function or a tint transform.
> Because these functions are written in PostScript we need to run them
> in the PostScript environment.
> To do this we push the procedure (or at least 'a' procedure) onto the
> exec stack and exit with an o_push_estack error. In many cases that's
> all we need to do, but sometimes we want to return control back to the
> 'C' environment and, in some of those cases, we want to store some state
> for the C code. We can't use the operand stack (because the PostScript
> function will alter that) so we store stuff on the exec stack instead.
> When we complete the C level, we should restore the exec stack, so if
> we stored any state on it, we should remove it. Sometimes we were not
> doing so if there was an error.
> Generally this did not cause a problem, because in general on an error
> we would stop. However if the error handler had been altered it was
> possible we might carry on. 'Sometimes' that would mean we tried to
> execute something which wasn't executable, and sometimes it might mean
> that we tried to return to the C level, but without the expected
> state on the exec stack.
> This could lead to memory corruption and crashes.
> This commit tries to find everywhere where we might end up leaving
> extra items on the exec stack in the case of an error, and either
> removes the required number of items from the exec stack or uses
> whatever cleanup routine was established for the C code.
> Its important to note that, in normal use, none of these could actually
> cause a problem. This makes it hard to test. all the cases here I have
> tested, though in many cases the only way I could produce an error was
> by forcing an error return in the debugger. I suspect some error cases
> simply aren't possible but its good practice to check the return codes
> anyway, even if its only a theoretical problem.
> psi/zalg.c
> psi/zcie.c
> psi/zcolor1.c
> psi/zcontrol.c
> psi/zfile.c
> psi/zht1.c
> psi/zht2.c
> psi/zpath1.c
> psi/zpcolor.c

2018-09-06 14:18:22 -0700
Michael Vrhel <michael.vrhel@artifex.com>
0da9680ca0506fd3cdf70840ad5387d85cab4996

> gscms_transform_color fails in cloning operation
> The cloning operation was getting called with a NULL
> pointer for the current ICC link handle.
> base/gsicc_lcms2mt.c

2018-09-06 11:39:58 -0700
Ray Johnston <ray.johnston@artifex.com>
f6ebd382763546e31a024376ff49ff2f074627de

> Remove obsolete code and comment (from 1999)
> After this long, there is no reason to carry this code around that was
> a hack for joins of a flattened curve.
> base/gxstroke.c

2018-09-06 12:07:35 -0700
Michael Vrhel <michael.vrhel@artifex.com>
f509c2c1350fbb3549dcd539448bf02742c1b49e

> gproof device supports post rendering ICC profile
> This issue was introduced during some error clean up
> of the ICC profile code.
> devices/gdevgprf.c

2018-09-06 18:40:05 +0100
Chris Liddell <chris.liddell@artifex.com>
13418541a5ae19b15f51cbb87faf344902f5af98

> Bug 699722 (2): add wildcards to the permissions paths.
> The temp and ICC profile paths need to finish with wildcards to work correctly.
> Resource/Init/gs_init.ps

2018-09-05 17:14:59 +0100
Chris Liddell <chris.liddell@artifex.com>
3e5d316b72e3965b7968bb1d96baa137cd063ac6

> Bug 699718: Ensure stack space is available before gsrestore call out
> During a grestore, if the device is going to change, we call out to Postscript
> to restore the device configuration, before returning to restore the graphics
> state internally.
> We have to ensure sufficient op stack space is available to complete the
> operation, otherwise the device can end up an undefined state.
> Resource/Init/gs_setpd.ps
> psi/zdevice2.c

2018-09-06 14:08:41 +0100
Chris Liddell <chris.liddell@artifex.com>
c8c01f8c4164bc10281d9e8f87cf96314d93104b

> Bug 699722: Add the ICCProfilesDir to the PermitReading list
> There was also an issue that the string being returned from the graphics
> library was null terminated, and Postscript strings are not (and Ghostscript
> strings are not necessarily). We leave the null termination in place, but
> reduce the length returned by 1.
> Resource/Init/gs_init.ps
> base/gsicc_manage.c

2018-09-06 09:16:22 +0100
Chris Liddell <chris.liddell@artifex.com>
fb713b3818b52d8a6cf62c951eba2e1795ff9624

> Bug 699708 (part 1): 'Hide' non-replaceable error handlers for SAFER
> We already had a 'private' dictionary for non-standard errors: gserrordict.
> This now includes all the default error handlers, the dictionary is made
> noaccess and all the prodedures are bound and executeonly.
> When running with -dSAFER, in the event of a Postscript error, instead of
> pulling the handler from errordict, we'll pull it from gserrordict - thus
> malicious input cannot trigger problems by the use of custom error handlers.
> errordict remains open and writeable, so files such as the Quality Logic tests
> that install their own handlers will still 'work', with the exception that the
> custom error handlers will not be called.
> This is a 'first pass', 'sledgehammer' approach: a nice addition would to allow
> an integrator to specify a list of errors that are not to be replaced (for
> example, embedded applications would probably want to ensure that VMerror is
> always handled as they intend).
> Resource/Init/gs_init.ps
> psi/interp.c

2018-09-05 17:00:41 +0100
Chris Liddell <chris.liddell@artifex.com>
0d8c7d563745bfd89051a203267fcbf2492ecfcc

> Bug 699720: Change available buffer space to int from uint
> sbufavailable() returns the number of bytes still available in the stream
> buffer. This can end up as negative at EOF (after we've read the final byte in
> the buffer, we read ptr is moved to the next byte, past the end of the buffer -
> that should never be read, however).
> We can safely use a signed integer since this is buffer space, *not* the total
> bytes available from the stream
> psi/interp.c

2018-09-05 12:54:46 +0100
Chris Liddell <chris.liddell@artifex.com>
37c1547e61e758cdd17c3dcb0504e2f5988004c3

> Delete legacy code source file, and references to it
> base/gp_sysv.c
> base/unix-aux.mak
> doc/Develop.htm
> doc/Source.htm
> windows/ghostscript.vcproj
> windows/ghostscript_rt.vcxproj

2018-09-04 14:35:18 +0100
Robin Watts <robin.watts@artifex.com>
164b6cb355900d0faea7468b4eafb3154aa90f6a

> Fix some comment typos.
> Resource/Init/gs_init.ps

2018-09-06 07:33:16 -0700
Michael Vrhel <michael.vrhel@artifex.com>
3a5815b014c316e28584f134dc3c06e43c848b38

> Add overprint support to knock out rect-fill
> When doing the rect fill for transparency knockout groups
> we were not handling overprint properly
> base/gdevp14.c

2018-09-04 11:18:48 -0700
Michael Vrhel <michael.vrhel@artifex.com>
5317e232d5a0309fc367d8bedb89988dd4bc38c9

> Fix bit rot in RAW_DUMP and TRACK_COMPOSE_GROUPS
> maskbuf is not defined in this particular path (as it is NULL)
> base/gxblend.c

2018-07-09 16:38:15 +0100
Robin Watts <robin.watts@artifex.com>
1435e31660ba94909688dabf74b411ead3196384

> Fix bug in mkromfs binary compaction.
> When writing long strings, psc->inpos changes value between
> writing it's low and high bytes.
> base/mkromfs.c

2018-07-05 17:16:00 +0100
Robin Watts <robin.watts@artifex.com>
5ec955366733d15a4f720271186abcf922ea2535

> Remove GS_NO_UTF8
> base/gp_mswin.c
> base/gp_ntfs.c
> base/gp_wgetv.c
> base/gp_wutf8.c
> base/gsargs.c
> base/msvclib.mak
> base/windows_.h
> devices/gdevwpr2.c
> pcl/pl/plmain.c
> pcl/pl/plwmainc.c
> psi/dwmain.c
> psi/dwmainc.c
> psi/dwtext.c
> psi/dwtext.h
> psi/iapi.c
> psi/imainarg.c
> psi/iminst.h
> psi/msvc.mak

2018-07-09 11:15:00 +0100
Robin Watts <robin.watts@artifex.com>
bc1d2d9742c960f1d4905f43810be072c5d92390

> Bug 691725: Tweak gssetgs*.bat files.
> The existing scripts assume that the gs binaries are on the path.
> The tweaked scripts check to see if there is a binary in the same
> directory as the .bat file, and if there is, use that in preference
> to any version on the path.
> Otherwise functionality is identical.
> lib/gssetgs.bat
> lib/gssetgs32.bat
> lib/gssetgs64.bat

2018-09-06 12:56:51 +0100
Robin Watts <robin.watts@artifex.com>
68eca5e94e6f63f4392b15581ad41af52e0edfd9

> Fix SEGV seen in all-devices test with plank examples/ridt91.eps
> Silly typo in the contone fill code for the landscape flippedy
> color cache case.
> base/gximono.c

2018-09-05 23:58:39 +0100
Robin Watts <robin.watts@artifex.com>
6473ad1394900c79a7ca5335accaaad9cd67d42a

> Add prototype missed from previous commit.
> psi/interp.h

2018-09-05 18:07:40 +0100
Robin Watts <robin.watts@artifex.com>
2b533271d8bd915593a2f8e1a1f446ee940c7d76

> Fix arg_copy leaks.
> When handling -d or -s args, the code currently arg_copies the string
> it gets back, then uses that copied block to make postscript names
> from.
> Here we change the code so that postscript names are made in a
> slightly different way, so they copy the string content. This means
> we can free the arg_copied block afterwards, solving the leaks.
> While we are here, remove a layer of nasty variable hiding macros
> that do nothing but confuse things.
> psi/iddict.h
> psi/idict.c
> psi/idict.h
> psi/iinit.c
> psi/imain.c
> psi/imainarg.c
> psi/interp.h

2018-09-05 15:59:43 +0100
Robin Watts <robin.watts@artifex.com>
a8c7899267121cb92503fe0f7e7f6ae433c386b1

> Bug 699711: Review arg_next to ensure that NULL arg returns are coped with.
> We can only return NULL from arg_next if the return code == 0. We
> therefore have to ensure that all call sites check for either of
> those conditions.
> base/gsargs.c
> pcl/pl/plmain.c
> psi/imainarg.c

2018-09-05 13:46:50 +0100
Robin Watts <robin.watts@artifex.com>
df4ec49e0f2237fe5b17d5d620f8c3cad95b3b5e

> Second attempt at fix for bug 699699.
> The previous attempt failed because it gave the wrong return value
> when we hit an empty argument.
> Now we ignore empty arguments.
> base/gsargs.c
> psi/imainarg.c

2018-09-05 13:19:51 +0100
Robin Watts <robin.watts@artifex.com>
ecfbc3126834e442edb309112e8995df9f10daa4

> Revert previous fix for Bug 699699.
> Revert "Bug 699699 "Crash upon bogus input argument.""
> (commit b509290189f1f37a76339f7b6921d42f126bfd57).
> This reopens bug 699699, so we can fix it in a way that doesn't
> return 1 for 'empty' arguments.
> This reopens bug 699699.
> base/gsargs.c
> psi/imainarg.c

2018-09-05 16:42:44 +0100
Robin Watts <robin.watts@artifex.com>
01514a0c6add9cbafe3c3ba55f57968154d2b323

> Bug 699719: Fix @ files in arg handling.
> When we met an @file in the arg handling, we were failing to swallow
> it and returning "@file" to the caller.
> base/gsargs.c

2018-09-05 16:43:20 +0100
Chris Liddell <chris.liddell@artifex.com>
6c887103a58563dd4e95acab49f9ee60f2aa13a7

> Update signed ghostpdf.cat to new certificate
> also add a *.cat rule to .gitattributes to ensure .cat files are always treated
> as binary
> .gitattributes
> lib/ghostpdf.cat

2018-09-05 08:44:41 +0100
Chris Liddell <chris.liddell@artifex.com>
e914f1da46e33decc534486598dc3eadf69e6efb

> Fix incomplete comment from previous commit
> Resource/Init/gs_setpd.ps

2018-09-04 23:18:46 +0100
Chris Liddell <chris.liddell@artifex.com>
5812b1b78fc4d36fdc293b7859de69241140d590

> Bug 699714: retain .LockSafetyParams through failed .installpagedevice
> In the event that the .trysetparams fails during .installpagedevice, catch the
> error, and ensure that at least the .LockSafetyParams is set.
> Resource/Init/gs_setpd.ps

2018-09-04 17:01:08 +0100
Chris Liddell <chris.liddell@artifex.com>
bc3df0773fccf4b4906a3e59652ad646ea0fee91

> For ICC profile validation, have cups id iteself as DeviceN
> Give the range of color spaces and models that cups supports, we can't
> reasonably provide (or expect others to provide) output ICC profiles for all
> cases.
> For the purpose of profile validation, have it claim to be DeviceN and benefit
> from the extra tolerance in profiles allowed for that class of device.
> cups/gdevcups.c
> devices/devs.mak

2018-08-28 16:55:49 +0100
Chris Liddell <chris.liddell@artifex.com>
90a692cfbfc2d6ec3c227149cd8d52fc22dc9e4e

> Bring master up to date with 9.24 release branch
> Doc changes, etc
> base/version.mak
> doc/DLL.htm
> doc/Deprecated.htm
> doc/Develop.htm
> doc/Devices.htm
> doc/Drivers.htm
> doc/Fonts.htm
> doc/History9.htm
> doc/Install.htm
> doc/Language.htm
> doc/Lib.htm
> doc/Make.htm
> doc/News.htm
> doc/Ps-style.htm
> doc/Ps2epsi.htm
> doc/Psfiles.htm
> doc/Readme.htm
> doc/Release.htm
> doc/SavedPages.htm
> doc/Source.htm
> doc/Unix-lpr.htm
> doc/Use.htm
> doc/VectorDevices.htm
> doc/WhatIsGS.htm
> doc/gs-vms.hlp
> doc/sample_downscale_device.htm
> doc/subclass.htm
> doc/thirdparty.htm
> man/dvipdf.1
> man/gs.1
> man/gslp.1
> man/gsnd.1
> man/pdf2dsc.1
> man/pdf2ps.1
> man/pf2afm.1
> man/pfbtopfa.1
> man/printafm.1
> man/ps2ascii.1
> man/ps2epsi.1
> man/ps2pdf.1
> man/ps2pdfwr.1
> man/ps2ps.1

2018-09-03 16:57:51 +0100
Chris Liddell <chris.liddell@artifex.com>
cc6fafb69b7957c9a7eac9a0087793d48be0443c

> Silence a coverity warning.
> base/gdevdflt.c

2018-09-03 15:32:40 +0100
Chris Liddell <chris.liddell@artifex.com>
29b6890cc618a88e0d9eb8e996d3e0153b5fbda9

> Update files for jbig2dec release 0.15
> jbig2dec/CHANGES
> jbig2dec/config_win32.h
> jbig2dec/configure.ac
> jbig2dec/jbig2dec.1

2018-09-03 15:34:44 +0100
Ken Sharp <ken.sharp@artifex.com>
fd6cac72bbc050e1a2832fd59f9fb1792b493750

> PostScript interpreter - More places where exec stack is not restored
> For the setcolorspace continuation procedure, and the related procs
> for specific colour spaces, we need to remove the extra operands we
> placed on the exec stack, so that there's no possibility of returning
> and executing them.
> psi/zcolor.c

2018-09-03 14:17:05 +0100
Ken Sharp <ken.sharp@artifex.com>
b509290189f1f37a76339f7b6921d42f126bfd57

> Bug 699699 "Crash upon bogus input argument."
> The code in arg_next starts by setting *argstr to NULL, the following
> do..while loop assumes that *argstr will be filled in, and checks its
> first byte. However, if we run out of characters in the argument string
> then *argstr remains NULL, and causes a crash.
> This can happen if we pass an empty quoted argument ""
> In addition, the processing of -o and possibly other switches assumes
> that arg_next will return an error if it doesn't find an argument
> whereas now it can return a NULL. I believe its possible that it always
> could do so.
> So check the 'arg' returned from arg_next to make sure its not NULL
> before we try to use it.
> We should check other places where arg_next is called as well.
> base/gsargs.c
> psi/imainarg.c

2018-09-01 17:50:05 +0100
Chris Liddell <chris.liddell@artifex.com>
0704d18b10314d701a522ad6c16718e0b8e199b7

> Bug 699658(related): Move recording of temp file names into C
> When we successfully create a temporary file from Postscript, either doing so
> when SAFER is not in force, or when SAFER is in force, and creating it in
> a write permitted directory, we record the file name so we can later delete
> the file, even is SAFER has been engaged, or if the PermitWriting list has
> changed to no longer the directory in question.
> Previously the recording of the name was done in Postscript, even though the
> checking was done in C.
> This moves the recording of the names to C, meaning we can remove the Postscript
> redefinitions of .tempfile and deletfile, and make the dictionary in question
> noaccess.
> Also, tidy up the adding of the temporary file directory to the list of
> permitted directories, and include the list in all of the categories
> (PermitFileWriting, PermitFileReading and PermitFileControl) - it was only
> previously adding to writing.
> Resource/Init/gs_init.ps
> psi/int.mak
> psi/zfile.c

2018-08-31 15:57:55 +0100
Chris Liddell <chris.liddell@artifex.com>
29f4603fc0c6de7d5df1f293f0a7efbffe8112bd

> Bug 699693: Fix FAPI handling of multibyte Unicode code point
> The original code worked for one byte code points, and for the case there the
> original character code and Unicode value both had the same number of bytes,
> but was totally wrong if the the two were different.
> psi/zfapi.c

2018-09-01 11:28:06 +0100
Ken Sharp <ken.sharp@artifex.com>
7ba6d80c69f0c74601ffc1077d27e0d1a299e57f

> Bug #699687 "grestore can bypass SAFER"
> The code in z2grestore (part of the level 2 restore machinery) in
> ghostpdl/psi/zdevice2.c sets the device's LockSafetyParams to false, and
> according to the comments there relies on putdeviceparams setting
> the flag back when the old device is re-instated.
> However, if we have corrupted any part of the device's content, then
> its possible to exit putdeviceparams, in one place only, without
> setting LockSafetyParams. Here we simply add an explicit reset of the
> value even in the case of an error setting the new device.
> base/gsdparam.c

2018-09-01 09:28:08 +0100
Ken Sharp <ken.sharp@artifex.com>
61ad589fb861d28e2d2c9d0b609ec4da4d7dd247

> Bug 699677 ".bindnow still causing side effects"
> In fact, its nothing to do with .bindnow. That simply modifies the exec
> stack in a way which makes the problem exhibit.
> setcustomcolor should really check its operands. because it doens't, it
> creates a tint transform function which tries to mulitply a number by
> (in this case) a name. This throws an error of course.
> The problem is that the code to sample the tint transform function
> didn't deal properly with the case where the PostScript function throws
> an error. In that case it properly exits the code which executes the
> function, but it fails to unwind the exec stack.
> This leads to use trying to complete the function, using the enumerator,
> which has been stored on the exec stack. Because we didn't clean up the
> exec stack, what we retrieve isn't an enumerator. This causes us to try
> to access invalid memory and can result in a crash.
> So, several steps. Firstly have the sampling code properly handle the
> error and restore the exec stack. Secondly, have the setcolorspace code
> be prepared to accept a NULL returned from the sampling code and treat
> that as an error (and also fix a similar exec stack problem in the
> setcolorspace code). Finally; have setcustomcolor validate its operands.
> Resource/Init/gs_lev2.ps
> psi/zcolor.c
> psi/zfsample.c

2018-08-29 09:30:19 -0700
Ray Johnston <ray.johnston@artifex.com>
c98cb5237c983e363fe05757b2639eab550499e8

> Fix for security issues found during internal security audit
> While most of the invocations of .forceput and related operators were
> "protected" by being within "executeonly" procedures, several had crept
> in that did not make sure that the operator was hidden in a procedure
> that could not be read.
> Resource/Init/gs_dps.ps
> Resource/Init/gs_fntem.ps
> Resource/Init/gs_init.ps
> Resource/Init/gs_lev2.ps
> Resource/Init/gs_pdfwr.ps
> Resource/Init/gs_setpd.ps
> Resource/Init/gs_typ32.ps

2018-08-31 08:12:48 +0100
Chris Liddell <chris.liddell@artifex.com>
d60214879cd71cf9f995c7d8862394293ffa9014

> Remove embedded, copyrighted ICC profile from PNG images
> doc/images/Artifex_logo.png
> doc/images/favicon.png
> doc/images/ghostscript_logo.png
> doc/images/hamburger-light.png
> doc/images/x-light.png

2018-08-31 09:58:00 +0100
Ken Sharp <ken.sharp@artifex.com>
478b73874179262d880c1417b5a11fb534a18651

> PDF interpreter - remove a warning message
> Commit f6bcc0dfc173b80fddab4fbf10afb34332ff1112 added extra checking
> and processing to deal with the (illegal) case of a Text block which
> includes a 'q' operator.
> As part of that commit, we added a warning message so that users would
> be able to tell there was a problem. Unfortunately, there are cases
> which are perfectly legal (eg running a Pattern PaintProc to fill the
> text) where a q can apparently occur inside a text object.
> We can't differentiate between executing a 'q' in such cases, so the
> only option is to remove the warning. This does not affect the actual
> operation of the code, it still copes with a 'q' inside text objects,
> whether legally or not.
> Resource/Init/pdf_ops.ps

2018-08-30 13:33:36 +0100
Ken Sharp <ken.sharp@artifex.com>
f8834d04215857e6150876bf189b682dbf254f8a

> ps2write - modify Lab space handling
> Commit 9e58cc8dd7e9b98620c798c901f800aff2e381ce improved the handling of
> /Separation spaces with an Lab alternate space.
> However, it also altered the handling of Lab spaces as the base space
> for patterns, or the initial space. This caused a small difference in
> release testing.
> The result was incorrect previously, and after the above commit, but the
> commit made it appear worse from a user's perspective. Until we can
> get time to properly convert Lab base spaces into a device space, return
> the code to its prior state. This does not affect the improvement to
> Separation spaces.
> devices/vector/gdevpdfc.c

2018-08-30 09:34:07 +0100
Ken Sharp <ken.sharp@artifex.com>
6dfd431fb4a97665044dcea7a061e8fa6ec36098

> Bug #699684 "gs segfaults in refset_null_new when processing malformed file"
> It is possible for a specifically malformed Binary Object Sequence to
> run out of data to process (and return to refill the buffer) when it
> had read *exactly* the maximum number of objects declared in the top
> array.
> This meant that the 'index' pointing to the next expected array entry
> to be filled in actually pointed past the end of the array.
> We then called a routine to set the unused entries in the array to null
> objects (for GC purposes), using the index. Because it pointed past the
> end of the array this led to the count of objects being -1. The code
> then counted down the count, until it reached 0, while at the same time
> writing null objects past the end of the array.
> This commit simply checks the index against the array size and doesn't
> attempt to fill it in if its less than that value. Note that the array
> index is 0-based, hence < not <=.
> psi/iscanbin.c

2018-08-29 07:59:17 +0100
Chris Liddell <chris.liddell@artifex.com>
d469deaf34e25f701a531ffd36cfc7f738efc4a2

> Fix a typo in commit 21ae2f8d9953
> psi/zfapi.c

2018-08-28 16:39:43 +0100
Chris Liddell <chris.liddell@artifex.com>
a25e6980ca87eaf0ef3d7e71acbed1ff2db7ab28

> Bump version on master to 9.25
> Resource/Init/gs_init.ps
> base/version.mak

2018-08-26 15:16:46 +0800
Sebastian Rasmussen <sebras@gmail.com>
032603f3c5448fc32609c51c932d11529eb6b581

> Bug 699673: jbig2dec: Initialize return code for all cases.
> Thanks to oss-fuzz for reporting.
> jbig2dec/jbig2_arith.c

2018-08-26 15:16:02 +0800
Sebastian Rasmussen <sebras@gmail.com>
343366cf2d6c3170d8b582d5df076f803c699262

> jbig2dec: Avoid dereferencing pointer before it is tested.
> Thanks to coverity.
> jbig2dec/jbig2.c

2018-09-03 09:44:54 +0100
Chris Liddell <chris.liddell@artifex.com>
32f1afe5c1e0b862e3bde05dc7b860a5f65cfbea

> Update dates, product string etc for release
> Fix release date
> base/gscdef.c
> base/version.mak
> doc/DLL.htm
> doc/Deprecated.htm
> doc/Develop.htm
> doc/Devices.htm
> doc/Drivers.htm
> doc/Fonts.htm
> doc/History9.htm
> doc/Install.htm
> doc/Language.htm
> doc/Lib.htm
> doc/Make.htm
> doc/News.htm
> doc/Ps-style.htm
> doc/Ps2epsi.htm
> doc/Psfiles.htm
> doc/Readme.htm
> doc/Release.htm
> doc/SavedPages.htm
> doc/Source.htm
> doc/Unix-lpr.htm
> doc/Use.htm
> doc/VectorDevices.htm
> doc/WhatIsGS.htm
> doc/gs-vms.hlp
> doc/sample_downscale_device.htm
> doc/subclass.htm
> doc/thirdparty.htm
> man/dvipdf.1
> man/gs.1
> man/gslp.1
> man/gsnd.1
> man/pdf2dsc.1
> man/pdf2ps.1
> man/pf2afm.1
> man/pfbtopfa.1
> man/printafm.1
> man/ps2ascii.1
> man/ps2epsi.1
> man/ps2pdf.1
> man/ps2pdfwr.1
> man/ps2ps.1

2018-09-03 08:34:25 +0100
Chris Liddell <chris.liddell@artifex.com>
ae222d8aa93783ba542b8ba91d62a1e107650563

> Update changelog... again
> doc/History9.htm

2018-09-01 17:50:05 +0100
Chris Liddell <chris.liddell@artifex.com>
07da47959687c1e6a112ad746929ef66e82b5aa9

> Bug 699658(related): Move recording of temp file names into C
> When we successfully create a temporary file from Postscript, either doing so
> when SAFER is not in force, or when SAFER is in force, and creating it in
> a write permitted directory, we record the file name so we can later delete
> the file, even is SAFER has been engaged, or if the PermitWriting list has
> changed to no longer the directory in question.
> Previously the recording of the name was done in Postscript, even though the
> checking was done in C.
> This moves the recording of the names to C, meaning we can remove the Postscript
> redefinitions of .tempfile and deletfile, and make the dictionary in question
> noaccess.
> Also, tidy up the adding of the temporary file directory to the list of
> permitted directories, and include the list in all of the categories
> (PermitFileWriting, PermitFileReading and PermitFileControl) - it was only
> previously adding to writing.
> Resource/Init/gs_init.ps
> psi/int.mak
> psi/zfile.c

2018-08-31 15:57:55 +0100
Chris Liddell <chris.liddell@artifex.com>
d8cfd2e7e1000f644afcaca2f196cb6d494049b8

> Bug 699693: Fix FAPI handling of multibyte Unicode code point
> The original code worked for one byte code points, and for the case there the
> original character code and Unicode value both had the same number of bytes,
> but was totally wrong if the the two were different.
> psi/zfapi.c

2018-09-01 11:28:06 +0100
Ken Sharp <ken.sharp@artifex.com>
a5993c537ae035b2396da5189fd985006627a478

> Bug #699687 "grestore can bypass SAFER"
> The code in z2grestore (part of the level 2 restore machinery) in
> ghostpdl/psi/zdevice2.c sets the device's LockSafetyParams to false, and
> according to the comments there relies on putdeviceparams setting
> the flag back when the old device is re-instated.
> However, if we have corrupted any part of the device's content, then
> its possible to exit putdeviceparams, in one place only, without
> setting LockSafetyParams. Here we simply add an explicit reset of the
> value even in the case of an error setting the new device.
> base/gsdparam.c

2018-09-01 09:28:08 +0100
Ken Sharp <ken.sharp@artifex.com>
21b27dc55b493564006c91326a5ddc636cf88563

> Bug 699677 ".bindnow still causing side effects"
> In fact, its nothing to do with .bindnow. That simply modifies the exec
> stack in a way which makes the problem exhibit.
> setcustomcolor should really check its operands. because it doens't, it
> creates a tint transform function which tries to mulitply a number by
> (in this case) a name. This throws an error of course.
> The problem is that the code to sample the tint transform function
> didn't deal properly with the case where the PostScript function throws
> an error. In that case it properly exits the code which executes the
> function, but it fails to unwind the exec stack.
> This leads to use trying to complete the function, using the enumerator,
> which has been stored on the exec stack. Because we didn't clean up the
> exec stack, what we retrieve isn't an enumerator. This causes us to try
> to access invalid memory and can result in a crash.
> So, several steps. Firstly have the sampling code properly handle the
> error and restore the exec stack. Secondly, have the setcolorspace code
> be prepared to accept a NULL returned from the sampling code and treat
> that as an error (and also fix a similar exec stack problem in the
> setcolorspace code). Finally; have setcustomcolor validate its operands.
> Resource/Init/gs_lev2.ps
> psi/zcolor.c
> psi/zfsample.c

2018-08-29 09:30:19 -0700
Ray Johnston <ray.johnston@artifex.com>
91d6bc4d3e3865388ede3bcd4e84bbb8787b78e4

> Fix for security issues found during internal security audit
> While most of the invocations of .forceput and related operators were
> "protected" by being within "executeonly" procedures, several had crept
> in that did not make sure that the operator was hidden in a procedure
> that could not be read.
> Resource/Init/gs_dps.ps
> Resource/Init/gs_fntem.ps
> Resource/Init/gs_init.ps
> Resource/Init/gs_lev2.ps
> Resource/Init/gs_pdfwr.ps
> Resource/Init/gs_setpd.ps
> Resource/Init/gs_typ32.ps

2018-08-31 08:12:48 +0100
Chris Liddell <chris.liddell@artifex.com>
cd83407209c3901ddfabd09e144c90ea105005d7

> Remove embedded, copyrighted ICC profile from PNG images
> doc/images/Artifex_logo.png
> doc/images/favicon.png
> doc/images/ghostscript_logo.png
> doc/images/hamburger-light.png
> doc/images/x-light.png

2018-08-30 15:07:33 +0100
Chris Liddell <chris.liddell@artifex.com>
f667df996290e64fc091d81b7513abdac488e156

> Update dates etc for release candidate 2
> base/gscdef.c
> doc/DLL.htm
> doc/Deprecated.htm
> doc/Develop.htm
> doc/Devices.htm
> doc/Drivers.htm
> doc/Fonts.htm
> doc/History9.htm
> doc/Install.htm
> doc/Language.htm
> doc/Lib.htm
> doc/Make.htm
> doc/News.htm
> doc/Ps-style.htm
> doc/Ps2epsi.htm
> doc/Psfiles.htm
> doc/Readme.htm
> doc/Release.htm
> doc/SavedPages.htm
> doc/Source.htm
> doc/Unix-lpr.htm
> doc/Use.htm
> doc/VectorDevices.htm
> doc/WhatIsGS.htm
> doc/gs-vms.hlp
> doc/sample_downscale_device.htm
> doc/subclass.htm
> doc/thirdparty.htm
> man/dvipdf.1
> man/gs.1
> man/gslp.1
> man/gsnd.1
> man/pdf2dsc.1
> man/pdf2ps.1
> man/pf2afm.1
> man/pfbtopfa.1
> man/printafm.1
> man/ps2ascii.1
> man/ps2epsi.1
> man/ps2pdf.1
> man/ps2pdfwr.1
> man/ps2ps.1

2018-08-30 13:33:36 +0100
Ken Sharp <ken.sharp@artifex.com>
214d6725e4a2b539294ebfba528a8d0961379fd0

> ps2write - modify Lab space handling
> Commit 9e58cc8dd7e9b98620c798c901f800aff2e381ce improved the handling of
> /Separation spaces with an Lab alternate space.
> However, it also altered the handling of Lab spaces as the base space
> for patterns, or the initial space. This caused a small difference in
> release testing.
> The result was incorrect previously, and after the above commit, but the
> commit made it appear worse from a user's perspective. Until we can
> get time to properly convert Lab base spaces into a device space, return
> the code to its prior state. This does not affect the improvement to
> Separation spaces.
> devices/vector/gdevpdfc.c

2018-08-30 09:34:07 +0100
Ken Sharp <ken.sharp@artifex.com>
e40f79df969e4168daf65b3b3af3ea73b6a71fc4

> Bug #699684 "gs segfaults in refset_null_new when processing malformed file"
> It is possible for a specifically malformed Binary Object Sequence to
> run out of data to process (and return to refill the buffer) when it
> had read *exactly* the maximum number of objects declared in the top
> array.
> This meant that the 'index' pointing to the next expected array entry
> to be filled in actually pointed past the end of the array.
> We then called a routine to set the unused entries in the array to null
> objects (for GC purposes), using the index. Because it pointed past the
> end of the array this led to the count of objects being -1. The code
> then counted down the count, until it reached 0, while at the same time
> writing null objects past the end of the array.
> This commit simply checks the index against the array size and doesn't
> attempt to fill it in if its less than that value. Note that the array
> index is 0-based, hence < not <=.
> psi/iscanbin.c

2018-08-29 11:43:49 +0100
Chris Liddell <chris.liddell@artifex.com>
06e4829c6756f0aa6918ba19710050295bd29bfe

> Update changelog post 9.24rc1
> doc/History9.htm

2018-08-29 07:59:17 +0100
Chris Liddell <chris.liddell@artifex.com>
110b1843b16d92878fd56d874b95bac5e130c720

> Fix a typo in commit 21ae2f8d9953
> psi/zfapi.c

2018-08-26 15:16:46 +0800
Sebastian Rasmussen <sebras@gmail.com>
74cc0437c7d4aa8bef051300b0ba3b510b9922c4

> Bug 699673: jbig2dec: Initialize return code for all cases.
> Thanks to oss-fuzz for reporting.
> jbig2dec/jbig2_arith.c

2018-08-26 15:16:02 +0800
Sebastian Rasmussen <sebras@gmail.com>
46c4a646d5c7954f076478aa8e85a4fc3b2b1f66

> jbig2dec: Avoid dereferencing pointer before it is tested.
> Thanks to coverity.
> jbig2dec/jbig2.c

## Version 9.24 (2018-09-03)

Highlights in this release include:

- Security issues have been the primary focus of this release, including solving several (well publicised) real and potential exploits.

  PLEASE NOTE: We strongly urge users to upgrade to this latest release to avoid these issues.

- As well as Ghostscript itself, jbig2dec has had a significant amount of work improving its robustness in the face of out specification files.

- IMPORTANT: We are in the process of forking LittleCMS. LCMS2 is not thread safe, and cannot be made thread safe without breaking the ABI. Our fork will be thread safe, and include performance enhancements (these changes have all be been offered and rejected upstream). We will maintain compatibility between Ghostscript and LCMS2 for a time, but not in perpetuity. Our fork will be available as its own package separately from Ghostscript (and MuPDF).

- The usual round of bug fixes, compatibility changes, and incremental improvements.

For a list of open issues, or to report problems, please visit bugs.ghostscript.com.

### Incompatible changes

- None

### Changelog

2018-09-01 17:50:05 +0100
Chris Liddell <chris.liddell@artifex.com>
07da47959687c1e6a112ad746929ef66e82b5aa9

> Bug 699658(related): Move recording of temp file names into C
> When we successfully create a temporary file from Postscript, either doing so
> when SAFER is not in force, or when SAFER is in force, and creating it in
> a write permitted directory, we record the file name so we can later delete
> the file, even is SAFER has been engaged, or if the PermitWriting list has
> changed to no longer the directory in question.
> Previously the recording of the name was done in Postscript, even though the
> checking was done in C.
> This moves the recording of the names to C, meaning we can remove the Postscript
> redefinitions of .tempfile and deletfile, and make the dictionary in question
> noaccess.
> Also, tidy up the adding of the temporary file directory to the list of
> permitted directories, and include the list in all of the categories
> (PermitFileWriting, PermitFileReading and PermitFileControl) - it was only
> previously adding to writing.
> Resource/Init/gs_init.ps
> psi/int.mak
> psi/zfile.c

2018-08-31 15:57:55 +0100
Chris Liddell <chris.liddell@artifex.com>
d8cfd2e7e1000f644afcaca2f196cb6d494049b8

> Bug 699693: Fix FAPI handling of multibyte Unicode code point
> The original code worked for one byte code points, and for the case there the
> original character code and Unicode value both had the same number of bytes,
> but was totally wrong if the the two were different.
> psi/zfapi.c

2018-09-01 11:28:06 +0100
Ken Sharp <ken.sharp@artifex.com>
a5993c537ae035b2396da5189fd985006627a478

> Bug #699687 "grestore can bypass SAFER"
> The code in z2grestore (part of the level 2 restore machinery) in
> ghostpdl/psi/zdevice2.c sets the device's LockSafetyParams to false, and
> according to the comments there relies on putdeviceparams setting
> the flag back when the old device is re-instated.
> However, if we have corrupted any part of the device's content, then
> its possible to exit putdeviceparams, in one place only, without
> setting LockSafetyParams. Here we simply add an explicit reset of the
> value even in the case of an error setting the new device.
> base/gsdparam.c

2018-09-01 09:28:08 +0100
Ken Sharp <ken.sharp@artifex.com>
21b27dc55b493564006c91326a5ddc636cf88563

> Bug 699677 ".bindnow still causing side effects"
> In fact, its nothing to do with .bindnow. That simply modifies the exec
> stack in a way which makes the problem exhibit.
> setcustomcolor should really check its operands. because it doens't, it
> creates a tint transform function which tries to mulitply a number by
> (in this case) a name. This throws an error of course.
> The problem is that the code to sample the tint transform function
> didn't deal properly with the case where the PostScript function throws
> an error. In that case it properly exits the code which executes the
> function, but it fails to unwind the exec stack.
> This leads to use trying to complete the function, using the enumerator,
> which has been stored on the exec stack. Because we didn't clean up the
> exec stack, what we retrieve isn't an enumerator. This causes us to try
> to access invalid memory and can result in a crash.
> So, several steps. Firstly have the sampling code properly handle the
> error and restore the exec stack. Secondly, have the setcolorspace code
> be prepared to accept a NULL returned from the sampling code and treat
> that as an error (and also fix a similar exec stack problem in the
> setcolorspace code). Finally; have setcustomcolor validate its operands.
> Resource/Init/gs_lev2.ps
> psi/zcolor.c
> psi/zfsample.c

2018-08-29 09:30:19 -0700
Ray Johnston <ray.johnston@artifex.com>
91d6bc4d3e3865388ede3bcd4e84bbb8787b78e4

> Fix for security issues found during internal security audit
> While most of the invocations of .forceput and related operators were
> "protected" by being within "executeonly" procedures, several had crept
> in that did not make sure that the operator was hidden in a procedure
> that could not be read.
> Resource/Init/gs_dps.ps
> Resource/Init/gs_fntem.ps
> Resource/Init/gs_init.ps
> Resource/Init/gs_lev2.ps
> Resource/Init/gs_pdfwr.ps
> Resource/Init/gs_setpd.ps
> Resource/Init/gs_typ32.ps

2018-08-30 15:07:33 +0100
Chris Liddell <chris.liddell@artifex.com>
00dd8bc74c2abb38195b9f88f7de36f169296a97

> Update dates etc for release candidate 2
> base/gscdef.c
> doc/DLL.htm
> doc/Deprecated.htm
> doc/Develop.htm
> doc/Devices.htm
> doc/Drivers.htm
> doc/Fonts.htm
> doc/History9.htm
> doc/Install.htm
> doc/Language.htm
> doc/Lib.htm
> doc/Make.htm
> doc/News.htm
> doc/Ps-style.htm
> doc/Ps2epsi.htm
> doc/Psfiles.htm
> doc/Readme.htm
> doc/Release.htm
> doc/SavedPages.htm
> doc/Source.htm
> doc/Unix-lpr.htm
> doc/Use.htm
> doc/VectorDevices.htm
> doc/WhatIsGS.htm
> doc/gs-vms.hlp
> doc/sample_downscale_device.htm
> doc/subclass.htm
> doc/thirdparty.htm
> man/dvipdf.1
> man/gs.1
> man/gslp.1
> man/gsnd.1
> man/pdf2dsc.1
> man/pdf2ps.1
> man/pf2afm.1
> man/pfbtopfa.1
> man/printafm.1
> man/ps2ascii.1
> man/ps2epsi.1
> man/ps2pdf.1
> man/ps2pdfwr.1
> man/ps2ps.1

2018-08-30 13:33:36 +0100
Ken Sharp <ken.sharp@artifex.com>
214d6725e4a2b539294ebfba528a8d0961379fd0

> ps2write - modify Lab space handling
> Commit 9e58cc8dd7e9b98620c798c901f800aff2e381ce improved the handling of
> /Separation spaces with an Lab alternate space.
> However, it also altered the handling of Lab spaces as the base space
> for patterns, or the initial space. This caused a small difference in
> release testing.
> The result was incorrect previously, and after the above commit, but the
> commit made it appear worse from a user's perspective. Until we can
> get time to properly convert Lab base spaces into a device space, return
> the code to its prior state. This does not affect the improvement to
> Separation spaces.
> devices/vector/gdevpdfc.c

2018-08-30 09:34:07 +0100
Ken Sharp <ken.sharp@artifex.com>
e40f79df969e4168daf65b3b3af3ea73b6a71fc4

> Bug #699684 "gs segfaults in refset_null_new when processing malformed file"
> It is possible for a specifically malformed Binary Object Sequence to
> run out of data to process (and return to refill the buffer) when it
> had read *exactly* the maximum number of objects declared in the top
> array.
> This meant that the 'index' pointing to the next expected array entry
> to be filled in actually pointed past the end of the array.
> We then called a routine to set the unused entries in the array to null
> objects (for GC purposes), using the index. Because it pointed past the
> end of the array this led to the count of objects being -1. The code
> then counted down the count, until it reached 0, while at the same time
> writing null objects past the end of the array.
> This commit simply checks the index against the array size and doesn't
> attempt to fill it in if its less than that value. Note that the array
> index is 0-based, hence < not <=.
> psi/iscanbin.c

2018-08-29 11:43:49 +0100
Chris Liddell <chris.liddell@artifex.com>
7874cfe914edc8a244976d914fc5a150c263651e

> Update changelog post 9.24rc1
> doc/History9.htm

2018-08-29 07:59:17 +0100
Chris Liddell <chris.liddell@artifex.com>
110b1843b16d92878fd56d874b95bac5e130c720

> Fix a typo in commit 21ae2f8d9953
> psi/zfapi.c

2018-08-26 15:16:46 +0800
Sebastian Rasmussen <sebras@gmail.com>
74cc0437c7d4aa8bef051300b0ba3b510b9922c4

> Bug 699673: jbig2dec: Initialize return code for all cases.
> Thanks to oss-fuzz for reporting.
> jbig2dec/jbig2_arith.c

2018-08-26 15:16:02 +0800
Sebastian Rasmussen <sebras@gmail.com>
46c4a646d5c7954f076478aa8e85a4fc3b2b1f66

> jbig2dec: Avoid dereferencing pointer before it is tested.
> Thanks to coverity.
> jbig2dec/jbig2.c

2018-08-28 16:55:49 +0100
Chris Liddell <chris.liddell@artifex.com>
fa11dee6f8a779edbb03ce20853b719f49815fcc

> Dates, strings and stuff for 9.24 rc1
> base/gscdef.c
> doc/DLL.htm
> doc/Deprecated.htm
> doc/Develop.htm
> doc/Devices.htm
> doc/Drivers.htm
> doc/Fonts.htm
> doc/History9.htm
> doc/Install.htm
> doc/Language.htm
> doc/Lib.htm
> doc/Make.htm
> doc/News.htm
> doc/Ps-style.htm
> doc/Ps2epsi.htm
> doc/Psfiles.htm
> doc/Readme.htm
> doc/Release.htm
> doc/SavedPages.htm
> doc/Source.htm
> doc/Unix-lpr.htm
> doc/Use.htm
> doc/VectorDevices.htm
> doc/WhatIsGS.htm
> doc/gs-vms.hlp
> doc/sample_downscale_device.htm
> doc/subclass.htm
> doc/thirdparty.htm
> man/dvipdf.1
> man/gs.1
> man/gslp.1
> man/gsnd.1
> man/pdf2dsc.1
> man/pdf2ps.1
> man/pf2afm.1
> man/pfbtopfa.1
> man/printafm.1
> man/ps2ascii.1
> man/ps2epsi.1
> man/ps2pdf.1
> man/ps2pdfwr.1
> man/ps2ps.1

2018-08-28 16:27:53 +0100
Ken Sharp <ken.sharp@artifex.com>
520bb0ea7519aa3e79db78aaf0589dae02103764

> Bug #699654 (again) and Bug #699677 Improve operator removal for SAFER
> Take inspiration from the code to remove unused/dangerous operators
> and, when SAFER is true, remove a bunch more non-standard operators
> or routines.
> In particular remove the .bindnow operator, which should have been
> removed previously for Bug #699677 and remove the
> .pushpdf14devicefilter for Bug #699654. Only the PDF interpreter
> needs to use that, and the device in question only expects to be used
> carefully and in the correct sequence. Make sure nobody can meddle with
> it.
> In addition I removed a number of other operators which are not needed
> in normal operation. Some of them, however, are useful so these
> (with the exception of .bindnow which is always removed) are only
> undefined if SAFER is true.
> This allows our QA procedure to continue to use them, which is
> particularly important in the case of .makeoperator and .setCPSImode.
> At a later date we may choose to move some of these into the regular
> undefinition code, ie not dependent on SAFER.
> Resource/Init/gs_init.ps

2018-08-28 14:53:49 +0100
Chris Liddell <chris.liddell@artifex.com>
21ae2f8d9953ffe8d6c8f1b2bf72a14b54d50e74

> Bug 699682: Handle text from single "gs_glyph" or "gs_char"
> In the FAPI code, when dealing a substituted cidfont, we extract the original
> character code, and decode that using the ToUnicode CMap, in order to get a
> Unicode code point we can then put through the TTF Unicode cmap table - thus
> improving the chances of getting a legible result.
> It failed to account for the possiblity that we were dealing with a single
> character code stored directly, rather than a string of 1 or more codes in a
> buffer - derefencing an invalid pointer.
> Add code to handle those cases.
> psi/zfapi.c

2018-08-28 14:17:09 +0100
Chris Liddell <chris.liddell@artifex.com>
7a702103b4490e370b36587c34b8b549a75ef3a5

> Bug 699678: don't allow bytes to be "unread" from stdin
> base/stream.c

2018-08-28 12:13:55 +0100
Ken Sharp <ken.sharp@artifex.com>
4b00990640258f464b02ce3f721a22fcb59b289b

> Bug 699676 "PDF interpreter can leave dangerous operators available"
> The problem here is that certain PDF functions require the ability to
> use some of the non-standard, and dangerous, operators/procedures
> from the PostScript interpreter.
> If we leave those functions readable then a malicious PostScript program
> could instantiate the PDF interpreter, inspect the packedarrray and
> copy the otherwise unobtainable operator/function, then use it for
> mischief.
> By making the PDF functions executeonly its impossible to read the
> function contents, which prevents this kind of abuse.
> Resource/Init/pdf_base.ps
> Resource/Init/pdf_draw.ps
> Resource/Init/pdf_font.ps
> Resource/Init/pdf_main.ps
> Resource/Init/pdf_ops.ps
> Resource/Init/pdf_rbld.ps
> Resource/Init/pdf_sec.ps

2018-08-28 09:55:48 +0100
Chris Liddell <chris.liddell@artifex.com>
5b5536fa88a9e885032bc0df3852c3439399a5c0

> Remove gssetresolution/gsgetresolution
> These are non-standard, and never used, so remove them.
> Also rejig gsgetdeviceprop, rename to .gsgetdeviceprop and undefine it after
> it's used.
> For the only other use of gsgetdeviceprop, replace with a special_op call.
> Resource/Init/gs_init.ps
> Resource/Init/gs_setpd.ps

2018-08-28 07:52:18 +0100
Chris Liddell <chris.liddell@artifex.com>
c9b362ba908ca4b1d7c72663a33229588012d7d9

> Bug 699670: disallow copying of the epo device
> The erasepage optimisation (epo) subclass device shouldn't be allowed to be
> copied because the subclass private data, child and parent pointers end up
> being shared between the original device and the copy.
> Add an epo_finish_copydevice which NULLs the three offending pointers, and
> then communicates to the caller that copying is not allowed.
> This also exposed a separate issue with the stype for subclasses devices.
> Devices are, I think, unique in having two stype objects associated with them:
> the usual one in the memory manager header, and the other stored in the device
> structere directly. In order for the stype to be correct, we have to use the
> stype for the incoming device, with the ssize of the original device (ssize
> should reflect the size of the memory allocation). We correctly did so with the
> stype in the device structure, but then used the prototype device's stype to
> patch the memory manager stype - meaning the ssize potentially no longer
> matched the allocated memory. This caused problems in the garbager where there
> is an implicit assumption that the size of a single object clump (c_alone == 1)
> is also the size (+ memory manager overheads) of the single object it contains.
> The solution is to use the same stype instance to patch the memory manager
> data as we do in the device structure (with the correct ssize).
> base/gdevdflt.c
> base/gdevepo.c

2018-08-27 11:15:16 +0100
Ken Sharp <ken.sharp@artifex.com>
ea735ba37dc0fd5f5622d031830b9a559dec1cc9

> Fix error condition for SC and CS
> The SC and CS PDF operators correctly checked the return code from the
> underlying setcolor and setcolorspace code, but we had already
> set up the exec stack for handling a non-error return.
> We have to do this before calling the underlying code, as that also
> uses a state machine, and alters the exec stack. We must push our
> own execution context first.
> Ordinarily this isn't a problem, but if we have a custom error handler
> which doesn't stop the interpreter, then we would continue on to try
> and use what we'd pushed onto the exec stack, with predictably dire
> results.
> Here we avoid this by saving the exec stack pointer on entry, and if
> an error occurs, restoring back to that point before returning control
> to the PostScript interpreter.
> A minor point, but we now also reset the space/color on an error as
> well, previously it would have been left with the wrong space set.
> psi/zcolor.c

2018-08-25 07:45:45 +0100
Chris Liddell <chris.liddell@artifex.com>
79cccf641486a6595c43f1de1cd7ade696020a31

> Bug 699654(2): preserve LockSafetyParams in the nulldevice
> The nulldevice does not necessarily use the normal setpagedevice machinery,
> but can be set using the nulldevice operator. In which case, we don't preserve
> the settings from the original device (in the way setpagedevice does).
> Since nulldevice does nothing, this is not generally a problem, but in the case
> of LockSafetyParams it *is* important when we restore back to the original
> device, when LockSafetyParams not being set is "preserved" into the post-
> restore configuration.
> We have to initialise the value to false because the nulldevice is used during
> initialisation (before any other device exists), and *must* be writable for
> that.
> base/gsdevice.c

2018-08-24 18:17:50 +0100
Chris Liddell <chris.liddell@artifex.com>
e5b46839994ec093251bb641fb7cbffe81712e40

> Fix a typo in a dependency
> psi/int.mak

2018-08-24 09:26:04 +0100
Chris Liddell <chris.liddell@artifex.com>
5516c614dc33662a2afdc377159f70218e67bde5

> Improve restore robustness
> Prompted by looking at Bug 699654:
> There are two variants of the restore operator in Ghostscript: one is Level 1
> (restoring VM), the other is Level 2+ (adding page device restoring to the
> Level operator).
> This was implemented by the Level 2+ version restoring the device in the
> graphics state, then calling the Level 1 implementation to handle actually
> restoring the VM state.
> The problem was that the operand checking, and sanity of the save object was
> only done by the Level 1 variant, thus meaning an invalid save object could
> leave a (Level 2+) restore partially complete - with the page device part
> restored, but not VM, and the page device not configured.
> To solve that, this commit splits the operand and sanity checking, and the
> core of the restore operation into separate functions, so the relevant
> operators can validate the operand *before* taking any further action. That
> reduces the chances of an invalid restore leaving the interpreter in an
> unknown state.
> If an error occurs during the actual VM restore it is essentially fatal, and the
> interpreter cannot continue, but as an extra surety for security, in the event
> of such an error, we'll explicitly preserve the LockSafetyParams of the device,
> rather than rely on the post-restore device configuration (which won't happen
> in the event of an error).
> psi/int.mak
> psi/isave.h
> psi/zdevice2.c
> psi/zvmem.c

2018-08-24 12:59:45 +0100
Ken Sharp <ken.sharp@artifex.com>
b0a3854751363657998d4c9bd33c290bf9d07c67

> Improve PDF operator hiding
> Firstly, hide the .setdistillerparams operator, if we try to use this
> with a device which doesn't accept distiller params it could cause
> problems. The setdistillerparams operator checks the device before
> calling .setdistillerparams. This change is needed in *both*
> pdf_main.ps and gs_init.ps (see next)
> Secondly, fix the code for hiding PDF operators, when DELAYBIND is
> true. We can't undefine the operators in pdf_main.ps if DELAYBIND
> is true, because the procedures using them won't have been bound yet.
> So we duplicate the code for removing the operators in gs_init.ps
> and call that during .bindnow, after all the deferred binding has been
> completed.
> Previously the code for hiding the PDF and PostScript operators had been
> left commented out, meaning that if a user chose DELAYBIND (which is
> itself a massive security hole) then this minor layer of security
> would not have been activated.
> Resource/Init/gs_init.ps
> Resource/Init/pdf_main.ps

2018-08-24 12:44:26 +0100
Ken Sharp <ken.sharp@artifex.com>
e01e77a36cbb2e0277bc3a63852244bec41be0f6

> Hide the .shfill operator
> Commit 0b6cd1918e1ec4ffd087400a754a845180a4522b was supposed to make
> the .shfill operator unobtainable, but I accidentally left a comment
> in the line doing so.
> Fix it here, without this the operator can still be exploited.
> Resource/Init/gs_init.ps

2018-08-23 15:42:02 +0100
Ken Sharp <ken.sharp@artifex.com>
8e9ce5016db968b40e4ec255a3005f2786cce45f

> Bug 699665 "memory corruption in aesdecode"
> The specimen file calls aesdecode without specifying the key to be
> used, though it does manage to do enough work with the PDF interpreter
> routines to get access to aesdecode (which isn't normally available).
> This causes us to read uninitialised memory, which can (and often does)
> lead to a segmentation fault.
> In this commit we set the key to NULL explicitly during intialisation
> and then check it before we read it. If its NULL we just return.
> It seems bizarre that we don't return error codes, we should probably
> look into that at some point, but this prevents the code trying to
> read uninitialised memory.
> base/aes.c
> base/saes.c

2018-08-23 15:41:18 +0100
Chris Liddell <chris.liddell@artifex.com>
241d91112771a6104de10b3948c3f350d6690c1d

> Bug 699664: Ensure the correct is in place before cleanup
> If the PS job replaces the device and leaves that graphics state in place, we
> wouldn't cleanup the default device in the normal way, but rely on the garbage
> collector.
> This works (but isn't ideal), *except* when the job replaces the device with
> the null device (using the nulldevice operator) - this means that
> .uninstallpagedevice doesn't replace the existing device with the nulldevice
> (since it is already installed), the device from the graphics ends up being
> freed - and as it is the nulldevice, which we rely on, memory corruption
> and a segfault can happen.
> We avoid this by checking if the current device is the nulldevice, and if so,
> restoring it away, before continuing with the device cleanup.
> psi/imain.c

2018-08-23 14:13:25 +0100
Chris Liddell <chris.liddell@artifex.com>
c432131c3fdb2143e148e8ba88555f7f7a63b25e

> Bug 699661: Avoid sharing pointers between pdf14 compositors
> If a copdevice is triggered when the pdf14 compositor is the device, we make
> a copy of the device, then throw an error because, by default we're only allowed
> to copy the device prototype - then freeing it calls the finalize, which frees
> several pointers shared with the parent.
> Make a pdf14 specific finish_copydevice() which NULLs the relevant pointers,
> before, possibly, throwing the same error as the default method.
> This also highlighted a problem with reopening the X11 devices, where a custom
> error handler could be replaced with itself, meaning it also called itself,
> and infifite recursion resulted.
> Keep a note of if the handler replacement has been done, and don't do it a
> second time.
> base/gdevp14.c
> devices/gdevxini.c

2018-08-23 14:12:48 +0100
Ken Sharp <ken.sharp@artifex.com>
0b6cd1918e1ec4ffd087400a754a845180a4522b

> Fix Bug 699660 "shading_param incomplete type checking"
> Its possible to pass a t_struct parameter to .shfill which is not a
> shading function built by .buildshading. This could then lead to memory
> corruption or a segmentation fault by treating the object passed in
> as if it were a shading.
> Its non-trivial to check the t_struct, because this function can take
> 7 different kinds of structures as a parameter. Checking these is
> possible, of course, but would add a performance penalty.
> However, we can note that we never call .shfill without first calling
> .buildshading, and we never call .buildshading without immediately
> calling .shfill. So we can treat these as an atomic operation. The
> .buildshading function takes all its parameters as PostScript objects
> and validates them, so that should be safe.
> This allows us to 'hide' the .shfill operator preventing the possibility
> of passing an invalid parameter.
> Resource/Init/gs_init.ps
> Resource/Init/gs_ll3.ps
> Resource/Init/pdf_draw.ps

2018-08-23 12:20:56 +0100
Chris Liddell <chris.liddell@artifex.com>
b575e1ec42cc86f6a58c603f2a88fcc2af699cc8

> Bug 699668: handle stack overflow during error handling
> When handling a Postscript error, we push the object throwing the error onto
> the operand stack for the error handling procedure to access - we were not
> checking the available stack before doing so, thus causing a crash.
> Basically, if we get a stack overflow when already handling an error, we're out
> of options, return to the caller with a fatal error.
> psi/interp.c

2018-08-23 09:30:56 +0100
Chris Liddell <chris.liddell@artifex.com>
d224b4abec1d0bd991028b7e38e95d47b7a834f4

> Bug 699623: ICC profile creation file permissions check
> The original fix missed the initial branch with an explicitly specified
> directory.
> This also uncovered problems with device profile reference counting, where
> if profile creation failed we'd leave a pointer to the original profile
> in place - either a dangling pointer, or leaving the ref count wrong.
> To solve this, we NULL the relevant profile pointer in the device after
> adjusting the reference count.
> base/gsicc_manage.c

2018-08-23 09:54:59 +0100
Chris Liddell <chris.liddell@artifex.com>
78911a01b67d590b4a91afac2e8417360b934156

> Bug 699654: Check the restore operand type
> The primary function that implements restore correctly checked its parameter,
> but a function that does some preliminary work for the restore (gstate and
> device handling) did not check.
> So, even though the restore correctly errored out, it left things partially done
> and, in particular, the device in partially restored state. Meaning the
> LockSafetyParams was not correctly set.
> psi/zdevice2.c

2018-08-21 20:36:52 +0100
Chris Liddell <chris.liddell@artifex.com>
0edd3d6c634a577db261615a9dc2719bca7f6e01

> Bug 699659: Don't just assume an object is a t_(a)struct
> psi/ztype.c

2018-08-21 20:17:51 +0100
Chris Liddell <chris.liddell@artifex.com>
a054156d425b4dbdaaa9fda4b5f1182b27598c2b

> Bug 699658: Fix handling of pre-SAFER opened files.
> Temp files opened for writing before SAFER is engaged are not subject to the
> SAFER restrictions - that is handled by recording in a dictionary, and
> checking that as part of the permissions checks.
> By adding a custom error handler for invalidaccess, that allowed the filename
> to be added to the dictionary (despite the attempted open throwing the error)
> thus meaning subsequent accesses were erroneously permitted.
> Resource/Init/gs_init.ps

2018-08-21 20:17:05 +0100
Chris Liddell <chris.liddell@artifex.com>
0d3901189f245232f0161addf215d7268c4d05a3

> Bug 699657: properly apply file permissions to .tempfile
> psi/zfile.c

2018-08-21 16:42:45 +0100
Chris Liddell <chris.liddell@artifex.com>
c3476dde7743761a4e1d39a631716199b696b880

> Bug 699656: Handle LockDistillerParams not being a boolean
> This caused a function call commented as "Can't fail" to fail, and resulted
> in memory correuption and a segfault.
> devices/vector/gdevpdfp.c
> psi/iparam.c

2018-08-21 16:24:05 +0100
Chris Liddell <chris.liddell@artifex.com>
b326a71659b7837d3acde954b18bda1a6f5e9498

> Bug 699655: Properly check the return value....
> ...when getting a value from a dictionary
> psi/zcolor.c

2018-08-15 16:24:11 +0100
Chris Liddell <chris.liddell@artifex.com>
f25045e88de674a1202c1239565ee99e9ddabe91

> Fix missing dependency declaration for gdevoflt.h
> base/lib.mak

2018-08-20 15:18:27 +0100
Chris Liddell <chris.liddell@artifex.com>
50ef2aa8c28f0eb097b8dab3effbe6b1c3948879

> Fix "ignored return code" Coverity errors.
> Several places in pl_main_process_options(), we were ignoring return codes -
> particularly, cases where a genuine error is possible.
> Rather than handle each error case automatically, drop out of the switch,
> and catch the error before jumping to the top of the while loop.
> For consistency, ignore the error triggered by -dBATCH
> pcl/pl/plmain.c

2018-08-20 19:03:26 +0100
Ken Sharp <ken.sharp@artifex.com>
678261f0d973badfc4609e9e7b27a1d039609ebb

> PostScrip ICC spaces - fix minor memory leak
> psi/zicc.c

2018-08-18 17:12:46 +0100
Ken Sharp <ken.sharp@artifex.com>
4ade82d9471971937ff3bcb39823cb080a18c2d5

> Fix a minor compiler warning
> devices/gdevdsp.c

2018-08-18 10:44:52 +0100
Ken Sharp <ken.sharp@artifex.com>
6b1106c232bb18366c527f9da54715ac79165317

> Fix display device (some more) with subclassing
> Because the display device isn't based off one of the standard devices
> we need to do extra work with it to ensure it behaves well with the
> subclassing device code.
> Commit 1203adc8bbcb60f0e4145300aac44f1988b7c2de contained some of this
> work, but unfortunately it had an oversight, it didn't update the
> parent (subclassing) devices when the device parameters changed.
> This led to it using the wrong width for the raster, if the media
> size changed after initialisation.
> devices/gdevdsp.c

2018-08-15 13:44:53 -0600
Henry Stiles <henry.stiles@artifex.com>
c265ee6563a1a65d225c4255d95d7306a21c3146

> Token buffer not freed.
> Unrecognized PJL settings resulted in a memory leak of the token
> buffer.
> pcl/pl/pjparse.c

2018-08-15 10:45:50 -0700
Nancy Durgin <nancy.durgin@artifex.com>
fa9b0f51a5fbac1bdabef012cc5b0ca006c2c281

> Fix compiler warning
> base/gdevepo.c

2018-08-15 14:10:55 +0100
Chris Liddell <chris.liddell@artifex.com>
7ab21af0b0c70707aefb1083505136ff7862d337

> Bug 699638(3): Fix param list key handling in pl_main_process_options()
> param lists can be configured to handle keys in two ways: persistent keys, or
> transient keys. For persistent keys, the param list contains a reference to the
> key string, and does no management of the string memory.
> Configured for transient key strings, the param list makes a copy of the string
> and the string memory is managed along with the parameter list itself.
> The two approaches cannot be mixed in the same param list.
> The pl_main_process_options() code configures the param list to use transient
> key strings (which is the default). But it was then copying the key strings,
> before passing them to the param list API, and taking no action to manage
> the string memory - causing memory leaks.
> Since the param list (as configured) takes a copy of the key string, there's no
> call for the calling code to do so, and not doing the local string copy
> prevents leaking memory.
> pcl/pl/plmain.c

2018-08-15 09:30:09 +0100
Chris Liddell <chris.liddell@artifex.com>
1ff8b85ae28c7813aa484dd8f1779f4a4d0742af

> Bug 699638(2): correct reference counts in gs_initgraphics
> In gs_initgraphics(), when we create new color spaces for the graphics state
> the color space is created with a reference count of 1, we then call
> gs_setcolorspace() which attaches the color space to the gstate and increments
> the reference count - we then drop the "local" reference, leaving a
> reference count of 2, but only a single reference to the color space (the one
> in the graphics state). Meaning the memory leaks.
> So, decrement the reference count for the local reference, before dropping the
> local reference.
> base/gsstate.c

2018-08-15 08:37:38 +0100
Chris Liddell <chris.liddell@artifex.com>
854f14096c0c6467068701ad19c4c775374e1ce4

> Bug 699638(1): Clean up before early exit in gx_image_cached_char()
> If we end up using the imagemask method to render a cached glyph, we can drop
> out early if the glyph is outside the current clip. Previously, the function
> simply returned at that point, leaking memory.
> Now it falls through to the cleanup and normal return, no longer leaking.
> base/gxccache.c

2018-08-14 10:01:08 -0700
Nancy Durgin <nancy.durgin@artifex.com>
1fe06b350370a51d1bcccde37f8daf13af803d3c

> Change the debugging in epo to use the gs_debug stuff
> I am using 3 flags -- epo-details, epo-install-only, epo-disable.
> Can also call "epo_disable(1)" during a gdb session to turn on/off
> during the session.
> base/gdbflags.h
> base/gdevepo.c

2018-08-09 07:56:51 -0700
Nancy Durgin <nancy.durgin@artifex.com>
df188f54f3e3eed5f12b921440ac7d29970aba35

> Bug 690131: Add epo subclass device to do erasepage optimization.
> This optimization only works for devices that have a fillpage
> implementation that is "gx_default_fillpage". For other devices the
> subclass device will not be installed. If the device transitions to
> clist (or any other non-gx_default_fillpage device), we will stop
> doing the optimization.
> The optimization basically swallows(defers) all fillpages, remembering
> the color (which is probably always white, but it will work with any
> "pure" color). Then when the first actual marking operation happens,
> we do a fill_rectangle operation with the remembered color.
> base/gdevepo.c
> base/gdevepo.h
> base/gspaint.c
> base/lib.mak

2018-08-09 11:25:57 +0100
Ken Sharp <ken.sharp@artifex.com>
428c05bf7168df79721f9bf3c574ccd9e1294e7e

> Fix a couple of compiler warnings
> Part of the subclassing updates.
> devices/vector/gdevpdfo.c

2018-08-09 11:25:57 +0100
Ken Sharp <ken.sharp@artifex.com>
55cb739c1134882c6abaca6264a8d8bccf24dedf

> Fix a couple of compiler warnings
> Part of the subclassing updates.
> devices/gdevdsp.c
> devices/vector/gdevpdfo.c

2018-07-31 16:36:28 +0100
Ken Sharp <ken.sharp@artifex.com>
5f8ac1413077051fd0f559b7b2d5f36b10d58bfe

> Device Subclassing - fix memory leak of the 'stype' device member
> This is all horribly crufty and really not possible to explain.
> With the addition of the custom finalize() for subclassing devices we
> sorted this out for the case where all the devices were garbage
> collected (the GC, the custom finalize and the device finalize take
> care of all the wrinkles here).
> But for unsubclassing we cannot use the finalize() routine for the
> original device when freeing the child. For most devices this does
> actually work, but if the device itself has a custom finalize method
> (rare, but see psdcmyk) then if we allow the finalize routine to run
> it might (and in the case of psdcmyk does) free memory which is still
> being pointed at by the parent (original) device structure.
> So we need to NULL the finalize routine in the stype structure, tell
> the memory manager to use the newly modified structure, then free the
> child device memory and finally free the stype structure.
> We also need to properly handle the reference counts of the icc_struct
> and PagesList objects, but we had done that already in previous commits.
> For safety, set the parent and child pointers to NULL and set the child
> device structure reference count to 0 to ensure it is not retained.
> Finally; there was a minor error when patching back the memory manager
> 'stype' copy in the parent device, fix that now too.
> base/gdevdflt.c

2018-07-27 12:17:32 +0100
Ken Sharp <ken.sharp@artifex.com>
1203adc8bbcb60f0e4145300aac44f1988b7c2de

> Device subclassing - synchronise devices on put_params
> Commit 434fb65601b91e14fe4f846dcbb92a68d939faf9 on the erasepage
> branch fixed the initial problem, but was not a sufficient solution.
> While it seems correct to update the 'target' of the clist so that it
> points to the head of the subclassing chain, we can run into problems
> using that device, if its parameters (eg width and height) do not
> match the ultimate device.
> This can happen if we get a put_params() which alters the device
> parameters. Although we update the chain after the put_params has
> completed, gdevprn-derived devices will reallocate memory or
> re-initialise the clist *during* the course of the put_params. If we
> don't resynchronise the chain but do update the clist target, then the
> clist re-initialisation will be using the wrong parameters.
> base/gdevprn.c

2018-07-26 17:39:40 +0100
Ken Sharp <ken.sharp@artifex.com>
9cb7fbd8ca2f2dee6652d832c76da16b85a5f730

> Device Subclassing - fix memory leaks with child device
> We should not patch out the finalize routine (now that we have a custom
> one), that prevents the child device finalize being run, leading to
> memory leaks with ICC profiles.
> Also, now we have a finalize routine, we need to free the child device
> if there is one present. The child device's own finalize routine will
> clean everything up.
> base/gdevdflt.c
> base/gdevsclass.c

2018-07-26 16:03:30 +0100
Ken Sharp <ken.sharp@artifex.com>
12a188d18097e2161f3d653b677e55f558d57faf

> Device Subclassing - add a finalize routine for subclassing devices
> After some research its clear that subclassing devices do actually need
> their own specific finalize routine, borrowing the device finalize
> leads to problems.
> So here we define a default version. All subclassing devices should
> either use this routine, or implement their own of the allocate additional
> memory. In that case the specific finalize routine should clean up its
> own memory and then call the default one.
> Add default subclassing finalize to system devices
> base/gdevflp.c
> base/gdevmplt.c
> base/gdevoflt.c
> base/gdevsclass.c
> base/gdevsclass.h

2018-07-17 12:45:20 +0100
Ken Sharp <ken.sharp@artifex.com>
ae5fddd0bd7b06215235090470d3f9297faa24bb

> Subclassing - correct reference counts on ICC profiles
> We weren't previously reference counting the profile structure, this
> wasn't a problem until pdfwrite started honouring /ProcessColorModel
> requests in setpagedevice, which could lead to the ICC profile
> structure altering between the device being subclassed, and the
> device being unsubclassed.
> base/gdevdflt.c

2018-07-17 10:08:33 +0100
Ken Sharp <ken.sharp@artifex.com>
2642d19883e4c008f999f2872cc0a37b2268634e

> Fix the display device with subclassing devices
> When the display device is chosen, the executable calls display_set_callbacks
> on the current device. That code then sets a member in the current
> device, *without* checking the device is actually the display device.
> It does this *before* opening the device....
> This is a quick hack to resolve the problem by descending to the bottom
> child device if there is a chain of devices in place. We should really
> check the device name at each step.
> In addition the Windows display device keeps a pointer to the device along
> with each 'image'. Not sure why, but it breaks if we are using device
> subclassing, because the device can change.
> Finally; the code doesn't cope with being unable to find a matching
> image with the same device. It sets the 'img' to NULL and then goes ahead
> and tries to use it anyway. Fix that at the same time so we don't crash!
> devices/gdevdsp.c
> psi/dwmain.c
> psi/idisp.c

2018-07-16 16:02:26 +0100
Ken Sharp <ken.sharp@artifex.com>
8c0d309e74526e0eb5152af05067a9b0a53892c7

> pdfwrite - fix stored device pointers in streams, when subclassing
> Yet more evidence of nasty hackery in pdfwrite. It stores a copy of the
> device pointer in the pdf stream_state. Of course, if we had a
> subclassed device when we created the stream, and unsubclassed it before
> we closed the (eg if we create a high level pattern before the first
> marking operation) then the stored pointer was pointing at the wrong
> (child, freed) device.
> Just do some pointer traversal to make sure we store the top level one
> and use the bottom level one when we need it.
> devices/vector/gdevpdfo.c
> devices/vector/gdevpsds.c

2018-07-16 15:58:35 +0100
Ken Sharp <ken.sharp@artifex.com>
40b7e425f7ba239e4639baf3feb9d54ebbb85957

> device subclassing - solve several problems with short-lived subclassing
> Nancy's new erasepage optimisation code revealed some interesting
> wrinkles in the subclassing code, Firstly;
> If we did a save, then inserted a subclassing device, then a restore
> we would get a segmentation fault.
> This is because when we subclass a device, we make a new copy of the
> original device. This device is, of course, created inside the current
> save context. When we restore, that restores away the copied device
> with the result that the 'child' pointer of the original device is now
> pointing at garbage memory.
> Fix this by using 'stable' memory instead of immovable memory. Stable
> memory is unaffected by save and restore.
> This means we also need to 'null' the members of the copied child when
> we 'unsubclass' the device. Otherwise garbage collection may end up
> trying to enumerate the pointers in the freed device.
> Following on from that, when we get a create_compositor call in the
> subclassing code we do a dance whereby we patch the method in the
> compositor handler that gets pushed, so that it points to the subclass
> device, not the device's ultimate child. Of course, when we unsubclass
> the device, we need to unpatch the compositor as well.
> That one may need more work.
> Finally (for now) we weren't properly handling the parent and child
> pointers for the list when we removed a device from the middle of a
> chain. The doubly-linked pointers weren't being properly updated.
> base/gdevdflt.c

2018-07-14 10:22:45 +0100
Ken Sharp <ken.sharp@artifex.com>
39e8e61d79488909b7645ecc31563ce15aa05702

> Fix subclassing and page buffer reallocation in prn devices
> It is possible for us to need to reallocate the page buffer for a
> device if (or example) a setpagedevice call results in changed width
> or height of the media.
> When we do that, if we need to change to (or re-initialise) a clist
> then we set the clist 'target' member to be the 'current' device. That
> doesn't mean the current device in the graphics state though, if
> we have subclassed the device then we will have passed the params
> request down the chain, so the rendering device is not the current
> device in the gstate.
> We need the target of the clist to be the subclassing device, ie the
> one in the graphics state, not the 'current' one. Otherwise if we
> were to unsubclass the device, then the clist would be pointing at a
> device which was freed.
> There's no good way to do this from the subclassing code itself, so
> I have (reluctantly) modified gdevprn.c to handle this. Any devices
> which don't derive from gdevprn, and use the clist, will need to handle
> this case themselves.
> base/gdevprn.c

2018-07-14 10:15:34 +0100
Ken Sharp <ken.sharp@artifex.com>
8eb6643606556921bbbbf495825470cd75123874

> subclassing devices - fix clist patching on unsubclass
> When removing a subclassing device from the chain, if we have patched
> the clist create_compositor method, then we need to restore it,
> otherwise it will continue to point to the (now vanished) subnclassing
> device's method.
> base/gdevdflt.c
> base/gdevsclass.c
> base/gxdevice.h

2018-08-09 11:55:54 +0100
Chris Liddell <chris.liddell@artifex.com>
88c54234ef0565e54de8b2378907ca201f348b4b

> Update "Font lookup" description
> The FONTPATH section did not explicitly state the search includes descendants
> of the directories listed in FONTPATH.
> Possibly this is because filenameforall (with which the search is implemented)
> did not recurse into subdirectories when the FONTPATH feature was originally
> added, but filenameforall now does (as it is supposed to), so the docs should
> reflect that.
> doc/Use.htm

2018-08-06 11:31:11 +0100
Ken Sharp <ken.sharp@artifex.com>
398fd3742abf40cd1c4b94273e81755bdcb5e88f

> PDF interpreter remove debug code
> Accidentally left a 'pstack' in the last commit
> Resource/Init/pdf_draw.ps

2018-08-06 11:23:00 +0100
Ken Sharp <ken.sharp@artifex.com>
17d6b5fd47e161b8a0bfd23e7a4214b16acd07dd

> PDF interpreter - resurrect Link handling improvements
> commit 61f53ab8f9e586c8722ccd0ea7de3722b0d40cd2 removed the duplication
> of /Link and /Text annotation handling, and used the newer code for
> handling these instead.
> It transpires that the /Link handling in the old (removed) code was
> considerably more functional than that in the newer code...
> Here we replace the new code with the old code in order to get the same
> functionality, but with the proper controls in place, and only handling
> annotations in one place instead of 2.
> Resource/Init/pdf_draw.ps

2018-08-06 09:37:32 +0100
Ken Sharp <ken.sharp@artifex.com>
61f53ab8f9e586c8722ccd0ea7de3722b0d40cd2

> PDF interpreter - Remove old annotation handling for pdfwrite
> Bug #699619 "Annotations included twice with pdfwrite"
> At some point in the past we handled a very few annotations with
> pdfwrite and did so in the pdfshowpage_finish routine. Since then we
> have moved the handling of annotations for pdfwrite into the
> showpagecontents routine, along with regular annotation rendering.
> But leaving the old code in place meant that some annotations (/Link
> and /Text) were being processed twice (for pdfwrite). Additionally
> the old code didn't honour the ShowAnnots or PreserveAnnots controls.
> Just remove the old code.
> Resource/Init/pdf_main.ps

2018-08-03 21:36:26 +0800
Sebastian Rasmussen <sebras@gmail.com>
1c12d01a2fb48e5fc69f46318348a4ad641be131

> Revert accidentally pushed "WIP: gitignore"
> This reverts commit 3f6507e834e92d9f5fc07ec8e91509a54ce9ec6d.
> .gitignore
> jbig2dec/.gitignore

2018-08-03 10:48:55 +0100
Ken Sharp <ken.sharp@artifex.com>
3bf4f3ea45f0022b6cd36415f095f1bfc119fb73

> pdfwrite - improve further the glyph bounding box calculation
> Bug #699571 "Missing characters when convert eps to pdf. Ok when convert to png."
> When deciding whether to include a text string in the output PDF file
> we compare the bounding box of the string with the bounding box of the
> current clip path. If the string bbox is not at least partially within
> the clip, then we don't emit it.
> To do this we previously used the font's FontBBox in order to estimate
> the size of each glyph in the string.
> Commit 6a4202691c4317a698fa23c5309ad8974fe2b003 fixed a bug where the
> font has a wildly incorrect FontBBox leading to us deciding that the
> glyph was outside the clip area.
> In that commit Chris Liddell noted that using the 'real' glyph bounding
> box would require executing the complete CharString which has
> performance implications.
> Unfortunately this latest bug has forced us into this course. The EPS
> file draws the same glyph multiple times, clipping portions of it each
> time. Sometimes it uses charpath/fill to render the clipped portion, and
> sometimes it uses an xyshow where the advance in both directions is 0.
> At the same time, the font has a completely inaccurate FontBBox.
> Because the advance width is 0 the previous fix does not address this
> situation. The FontBBox is so inaccurate that most of the times the
> glyph is rendered it is deemed to be outside the clip.
> The only remaining solution is to determine the *actual* Bounding Box
> of the glyph, which means we have to execute the glyph description.
> This does result in some degradation in performance.
> devices/vector/gdevpdte.c

2018-08-03 10:40:44 +0100
Ken Sharp <ken.sharp@artifex.com>
3cbfb32d83f8910a9aeae805542c805eba584e34

> TrueType interpreter - set the TrueType rendering routine
> Ensure the GS TTF interpreter is associated with a TTF font before attempting
> to retrieve the glyph bounding box. We have to eplicitly NULL the FAPI entry
> before doing so because, for normal rendering, we'll use the FAPI/Freetype API
> (in this case, we want to avoid rendering the glyph)
> Fix supplied by Chris Liddell
> base/gstype42.c

2018-05-26 19:11:58 +0800
Sebastian Rasmussen <sebras@gmail.com>
3f6507e834e92d9f5fc07ec8e91509a54ce9ec6d

> WIP: gitignore
> .gitignore
> jbig2dec/.gitignore

2018-08-03 19:14:15 +0800
Sebastian Rasmussen <sebras@gmail.com>
8c7d55b8f5b1248bf120ed312538bd824ba5ad9f

> jbig2dec: Avoid accessing symbol bitmap width if it is missing.
> jbig2dec/jbig2_text.c

2018-08-03 19:11:02 +0800
Sebastian Rasmussen <sebras@gmail.com>
06d82c1d8b0c625f5bb8db8acd7113ff0b8179d8

> jbig2dec: Prevent underflow when checking if enough data for bitmap.
> When decoding the symbol dictionary the bitmap size field
> determines the size of the bitmap. The bitmap size is however
> restricted to the size of the segment's data region. This was
> checked previously, but the check itself may underflow, so
> another check was introduced to prevent this from happening.
> jbig2dec/jbig2_symbol_dict.c

2018-08-03 19:10:09 +0800
Sebastian Rasmussen <sebras@gmail.com>
d20a98cb7d3e10a68c7d288318f216db70db610c

> jbig2dec: When reading past the end of a word stream, return 0.
> Previously the returned value would be uninitialized, leading
> to issues detected by valgrind later on in the parsing.
> jbig2dec/jbig2.c

2018-08-03 12:28:23 +0800
Sebastian Rasmussen <sebras@gmail.com>
105f72c232121b12ec2b53bc76c66dd8cf821a78

> jbig2dec: Initialize entire page structure upon allocation.
> Without this uninitialized values in the page structure will be
> used when parsing segments. An example of this is in
> jbig2_immediate_generic_region() when a the height of the page is
> used to determine if the region is outside of the page.
> jbig2dec/jbig2.c

2018-04-26 01:48:05 +0800
Sebastian Rasmussen <sebras@gmail.com>
163d0687c8c6bcfbff9e2ebae634530de0c3ebce

> jbig2dec: Explanation of (un)optimized generic region decoder.
> Previously it was difficult to understand the magic values used in the
> optimized generic region decoder, and also whether the order of pixels
> in the context in the unoptimized decoder were important. This new
> explanation attempts to rectify these issues.
> jbig2dec/jbig2_generic.c

2018-07-24 01:00:18 +0800
Sebastian Rasmussen <sebras@gmail.com>
e115b9b367645f85b42c5c7922b84af6fad7a907

> jbig2dec: Print warning messages even for non-debug builds.
> This is useful because jbig2dec emits warnings when it encounters
> broken files it is able to cope with, e.g. referrals to symbols
> outside the symbol dictionary are ignored but a warning is
> emitted. Ghostscript ought to output warnings in these cases so
> that users know that the final render might not be the intended
> one because the input file is broken.
> base/sjbig2.c

2018-07-01 17:26:21 +0800
Sebastian Rasmussen <sebras@gmail.com>
2db336dc75bf710bcf327545c61f2d215332ce99

> jbig2dec: Read region segment height/width/x/y as unsigned.
> The specification in 5.4.4 states that numbers are unsigned unless
> otherwise stated. 7.4.1.1 through 7.4.1.4 specifying the region segment
> height, width, x and y do not mention that these fields are signed,
> hence they ought to read and handled as unsigned.
> jbig2dec/jbig2_generic.c
> jbig2dec/jbig2_halftone.c
> jbig2dec/jbig2_page.c
> jbig2dec/jbig2_page.h
> jbig2dec/jbig2_refinement.c
> jbig2dec/jbig2_segment.c
> jbig2dec/jbig2_segment.h

2018-07-08 14:10:09 +0800
Sebastian Rasmussen <sebras@gmail.com>
fd551bc0e40d2220b4343aeeefa7d9d3a64140eb

> jbig2dec: Use accurate references to the specification.
> jbig2dec/jbig2_halftone.c
> jbig2dec/jbig2_halftone.h

2018-07-31 19:32:00 +0800
Sebastian Rasmussen <sebras@gmail.com>
ab862e07f1a804d5cf55548e73c0128673070e17

> jbig2dec: Support up to 16 bit gray-scale image for halftoning.
> Without this commit if jbig2dec is fed a fuzzed bitstream where
> HBPP ends up larger than 8, jbig2dec will access bits outside of
> each 8 bit sample in GSVALS.
> HBPP is in Table 22 in 6.6.4 defined to be 32 bits unsigned. The
> specification in C.2 limits GSBPP to 6 bits unsigned, a maximum
> value of 63, i.e. a gray-scale image with 63 bits per sample.
> According to table 23 in 6.6.5 HBPP is assigned to GSBPP, so any
> value larger than 63 would be out of spec.
> A non-fuzzed bitstream that has HBPP larger than 9 is yet to be
> encountered. So for the time being use uint16_t the GSVALS and
> limit HBPP to 16. If a file with HBPP larger than 16 is ever
> encountered, the type and limit needs to be revisited.
> jbig2dec/jbig2_halftone.c

2018-07-09 00:42:51 +0800
Sebastian Rasmussen <sebras@gmail.com>
907b9dff401154cdf5a4716e4f067bdf3a45de27

> jbig2dec: Use corresponding stride for gray-scale bitplane.
> All bitplanes have the same stride, but this change makes it obvious
> that we will not overwrite any boundaries (i.e. use the stride of the
> bitplane in question, not the stride for another bitplane).
> jbig2dec/jbig2_halftone.c

2018-07-08 22:05:57 +0800
Sebastian Rasmussen <sebras@gmail.com>
7f4cd0ad4c0d8636141de50bb6eb76b17e574eb5

> jbig2dec: Fix accidental typo in context size function.
> jbig2dec/jbig2_generic.c

2018-07-04 03:03:17 +0800
Sebastian Rasmussen <sebras@gmail.com>
2bc62e131fb14d22e7f4e0701a190b1cf50e9792

> jbig2dec: Ignore negative pixel runs in MMR decoder.
> Previously these were fatal errors, now warn and continue.
> jbig2dec/jbig2_mmr.c

2018-07-03 00:36:40 +0800
Sebastian Rasmussen <sebras@gmail.com>
9bff24e265f40fca19926f2a44390d1ac543e309

> jbig2dec: Ignore missing glyphs when rendering text region.
> jbig2dec/jbig2_text.c

2018-05-28 22:46:16 +0800
Sebastian Rasmussen <sebras@gmail.com>
052910bb5f16adaa0bc28fb2e8c7aeb562e0e7cb

> jbig2dec: Rephrase jbig2_error() messages.
> * Do not prefix messages with "jbig2 error:", this ought to be
> done by the error callback itself.
> * Avoid using function names in messages as they mean nothing to
> the end user.
> * Avoid contractions in messages.
> * Try to adhere to "failed to" pattern as far as possible.
> * Messages start with lower case character, unless it refers to
> something in the specification.
> * Messages do not end with punctuation.
> jbig2dec/jbig2.c
> jbig2dec/jbig2_arith.c
> jbig2dec/jbig2_arith_iaid.c
> jbig2dec/jbig2_arith_int.c
> jbig2dec/jbig2_generic.c
> jbig2dec/jbig2_halftone.c
> jbig2dec/jbig2_huffman.c
> jbig2dec/jbig2_image.c
> jbig2dec/jbig2_image_pbm.c
> jbig2dec/jbig2_page.c
> jbig2dec/jbig2_refinement.c
> jbig2dec/jbig2_segment.c
> jbig2dec/jbig2_symbol_dict.c
> jbig2dec/jbig2_text.c
> jbig2dec/jbig2dec.c

2018-07-03 20:02:04 +0800
Sebastian Rasmussen <sebras@gmail.com>
fdf6a2d9b8a33b04429608c104680d982fb085f5

> jbig2dec: Implement support for generic region pixel skipping.
> jbig2dec/jbig2_generic.c
> jbig2dec/jbig2_generic.h
> jbig2dec/jbig2_halftone.c

2018-07-04 12:36:41 +0800
Sebastian Rasmussen <sebras@gmail.com>
c10cd780ace02cdc2a07e9c9e59e4617c0434fc6

> jbig2dec: Fix where end row of stripe was only updated locally.
> jbig2dec/jbig2_page.c

2018-07-03 03:10:55 +0800
Sebastian Rasmussen <sebras@gmail.com>
90964e633488e2d8e9fa450ebe04ace16ec0d396

> jbig2dec: Warn on too many symbols in text region, do not report fatal error.
> This condition is already taken care of by not continuing to read symbols,
> so attempt to proceed with parsing the image.
> jbig2dec/jbig2_text.c

2018-07-02 12:44:31 +0800
Sebastian Rasmussen <sebras@gmail.com>
0073f2a6524c731528e950deb7eac598c819a3da

> jbig2dec: Treat unstriped pages with unknown height as striped with max stripe height.
> jbig2dec/jbig2_page.c

2018-07-01 17:25:48 +0800
Sebastian Rasmussen <sebras@gmail.com>
3d8b1c3fc85271e075b22627182998ae4cf894d5

> jbig2dec: Limit region height to page/stripe height.
> Make sure to ignore regions outside of stripe/page.
> jbig2dec/jbig2_generic.c
> jbig2dec/jbig2_page.c

2018-07-09 01:30:11 +0800
Sebastian Rasmussen <sebras@gmail.com>
f3e4a8978b9577bad31d0f818b206eb65da222d6

> jbig2dec: Stripe offsets are absolute, not relative.
> jbig2dec/jbig2_page.c

2018-07-30 16:24:28 +0100
Ken Sharp <ken.sharp@artifex.com>
cf964a720496ff8e1c55f0d629bdec91b789faf0

> Coverity ID 305953 - uninitialised variable
> Also a scan-build warning.
> devices/vector/gdevpdtt.c

2018-07-01 00:36:28 +0800
Sebastian Rasmussen <sebras@gmail.com>
e3212ede0590b02ef57f8946ae413ce44ef3658e

> jbig2dec: Cap runlength for exported symbols, don't error out.
> Capping is necessary because the preceding symbol dictionary segment header
> stated that a specific number of symbols will be exported to succeeding symbol
> dictionaries. By capping overly long runlengths of exported symbol instead of
> reporting fatal errors somewhat corrupt JBIG2 bitstreams may still partially
> render, albeit with a warning about the capping taking place.
> jbig2dec/jbig2_symbol_dict.c

2018-07-01 13:28:26 +0800
Sebastian Rasmussen <sebras@gmail.com>
bbbb7eff0b63f383e073ec760b2b8a94896d81a1

> jbig2dec: Occasional runlengths may be zero, avoid infinite sequence.
> Previously any runlength when exporting symbol dictionary symbols
> being zero caused a fatal error. These are not disallowed by the
> specification, but if there is an infinite sequence of them the
> decoder cannot make any progress in establishing the dictionary
> of exported symbols from a symbol dictionary. This may happen
> when the huffman or arithmetic integer decoder due to e.g. fuzzed
> input data returns an infinite sequence of zeroes when the
> decoder attempts to read the runlengths. This case of infinite
> zero runlengths is best handled as a fatal error. An arbitrary
> limit of 1000 of zero runlengths in sequence (an approximation of
> an infinite sequence of zero runlengths) will now cause a fatal
> error, but the occasional zero runlength will be accepted without
> any kind of message.
> jbig2dec/jbig2_symbol_dict.c

2018-07-13 14:10:40 +0800
Sebastian Rasmussen <sebras@gmail.com>
55ed0cbe04df585a987ca8ce7b6255e9705646d1

> jbig2dec: Advance and limit b1 in MMR decoder in a single location.
> Previously this unnecessarily happened multiple times.
> jbig2dec/jbig2_mmr.c

2018-07-13 13:39:42 +0800
Sebastian Rasmussen <sebras@gmail.com>
1d22aa82619bfd6e02dd1e4afa019a68ba2f3cca

> jbig2dec: Remove check for a0 set before scanline in MMR decoder.
> A few lines of code prior if a0 is set before the scanline it is
> reset to index 0, so no need to recheck for this condition.
> jbig2dec/jbig2_mmr.c

2018-07-13 13:00:06 +0800
Sebastian Rasmussen <sebras@gmail.com>
230dd860b0db9924794570654db3bb162194977e

> jbig2dec: Error message in MMR coded data mixed black/white pixel runs.
> jbig2dec/jbig2_mmr.c

2018-07-13 12:31:19 +0800
Sebastian Rasmussen <sebras@gmail.com>
7f94da2ccf574524d71a7d6aa2e381893dbacb37

> jbig2dec: The MMR runlength tables list error codes, handle those.
> Previously these errors led to spurious negative values for runlengths,
> which were treated as if these were legal even though they are not.
> jbig2dec/jbig2_mmr.c

2018-07-26 11:43:10 +0100
Chris Liddell <chris.liddell@artifex.com>
4b16b3762c1177497633178303665317eae8297e

> Bug 699560: Shut down libjpeg encoder in gdevjpeg
> Have the jpeg devices correctly shutdown libjpeg and release the encoder
> context correctly - solves memory leaks reported by memento.
> devices/gdevjpeg.c

2018-07-26 08:28:23 +0100
Ken Sharp <ken.sharp@artifex.com>
2f017502459778cac3c2b8cb2c6df2f52629aae3

> pdfwrite - don't retry CharProc capture on error.
> Bug #699561 "Infinite loop or Segfault"
> The input PostScript file for this case is invalid and throws a
> rangecheck error with normal devices.
> However when the output device is pdfwrite in the case of *any* error
> handling text we fall back to the 'default implementation' which means
> we run the glyph description normally, and capture the bitmap into a
> type 3 bitmap font.
> In the case of this file, however, when we try to use the captured
> bitmap we again throw an error. This causes us to run the glyph
> description again and capture the bitmap. Of course, that again fails
> when we try to use it leading to an infinite loop. But not any simple
> loop, it involves exiting the code and re-entering it after capture.
> This commit adds a new variable, captured_pte_index. When we complete
> a capture, we record the index (the pointer to the input character codes)
> from the text enumerator. We then try to process the text as normal. If
> we get an error, before falling back to the default implementation, we
> test the current text enumerator index. If its the same as the captured
> index then we know that it was the captured CharProc threw an error.
> In the case of this kind of error we simply return the error, there is
> nothing further we can do.
> devices/vector/gdevpdtt.c

2018-07-20 11:43:54 +0800
Sebastian Rasmussen <sebras@gmail.com>
d735b5ae0b8fc6573f09aee9b8663612bdde3c9b

> jbig2dec: Change overflow check for allocations.
> The maximum size of an allocation was previously limited to
> (maximum value of size_t)-256 bytes. Use SIZE_MAX instead.
> jbig2dec/jbig2.c

2018-06-29 17:47:25 +0800
Sebastian Rasmussen <sebras@gmail.com>
2272769bf1126e20f8458729c334f2134b95e951

> jbig2dec: Always complete a page, attempting decode of problematic streams.
> When JBIG2 bitstreams contain end of page segments the parser in
> jbig2dec calls jbig2_complete_page() to signal that the page is
> now finished.
> JBIG2 bitstreams created by some producers do not contain end of
> page segments but are otherwise well-formed JBIG2 bitstreams.
> Embedded JBIG2 bitstreams do not have to contain end of page
> segments. jbig2dec previously tried to detect these cases and
> simulated an end of page segment by manually calling
> jbig2_complete_page() so as to be able to output a displayable
> image.
> Problematic non-embedded JBIG2 bitstreams that have parse errors
> before any end of page segment is reached, or bitstreams where
> the end of page segment itself is broken, do not fall into either
> of the categories above but may be missing end of page segments.
> Previously jbig2dec treated this type of bistreams as not having
> any displayable image because the pages were never finished.
> To handle all types of bitstreams and attempt to output a
> displayable image (possibly partial due to parse errors),
> jbig2dec now always calls jbig2_complete_page() function.
> jbig2dec/jbig2dec.c

2018-07-13 12:49:36 +0800
Sebastian Rasmussen <sebras@gmail.com>
2483cf3a3467068510a012dc814aa607d6c6a32f

> jbig2dec: Limit scanline index in MMR coded data.
> According to the T.6 specification the pixel references, e.g. a0,
> may point to any of the pixels (indices 0 through N-1) on a
> scanline, one pixel to the left of a scanline (index MINUS1) or
> one pixel beyond the scanline (index N). These indicies are all
> positive (despite its name MINUS1 is defined to UINT32_MAX).
> This commit changes the index type from signed to unsigned to
> reflect this. Moreover, when looking for changing elements,
> make sure to limit the returned index to N.
> jbig2dec/jbig2_mmr.c

2018-07-13 12:41:14 +0800
Sebastian Rasmussen <sebras@gmail.com>
e05019b96b7e038d9335e640b83db098022d1e2c

> jbig2dec: Handle EOFB whether it is required or not.
> Chapter 6.2.6 in the JBIG2 specification states that MMR-encoded
> data _may_ skip the EOFB code when the data length is known in
> advance. If the data length is _not_ known in advance EOFB is
> required. Since an encoder may choose to use or skip EOFB when
> the data length is known, decoders must always be prepared to
> handle EOFB regardless of whether the data length is known or
> unknown.
> After encountering EOFB jbig2dec now stops consuming MMR-coded
> data regardless of whether the data lenght is known in advance
> or not. The remainder of the decoded image region is filled with
> white.
> jbig2dec/jbig2_mmr.c

2018-05-29 03:09:58 +0800
Sebastian Rasmussen <sebras@gmail.com>
7fade522e9e406b1faedc76e71f86951901633d2

> jbig2dec: Limit image size to 2GByte and check for overflow.
> The width/height fields of a JBIG2 image are limited by the
> specification to UINT32_MAX. This means that the total size of
> the image is limited to UINT32_MAX * UINT32_MAX pixels.
> jbig2_alloc() take a size argument of type size_t, limiting
> allocations to at most SIZE_MAX bytes. For 32 bit systems
> SIZE_MAX == UINT32_MAX and for 64 bit systems SIZE_MAX ==
> UINT64_MAX.
> This means that for 32 bit systems the maximum image size is
> limited to UINT32_MAX * 8 pixels. For 64 bit systems it could
> conceivably be limited to UINT64_MAX * 8 pixels if all indexing
> into the image buffer allocation is 64 bit safe.
> However jbig2dec's indexing into the image buffer allocations is
> not always 64 bit safe, so limit image allocations to the safe
> choice of 2Gbyte. This equates to limiting image sizes to
> INT32_MAX * 8 pixels, or a square of 131072 by 131072 pixels.
> jbig2dec/jbig2_image.c

2018-06-20 01:38:41 +0800
Sebastian Rasmussen <sebras@gmail.com>
6f06c79a4f0ee664840ce7bedc35dafc921e5086

> jbig2dec: Cast BMSIZE in symbol dicts to size_t.
> BMSIZE is used to skip over uncompressed symbols in a symbol dictionary.
> Therefore this value is inherently unsigned. Also because the value is
> a multiplication of the height and stride of an image, both of which are
> unsigned 32 bit numbers, rely on the size_t type which is large enough
> to handle images this big.
> jbig2dec/jbig2_huffman.c
> jbig2dec/jbig2_huffman.h
> jbig2dec/jbig2_symbol_dict.c
> jbig2dec/jbig2_text.c

2018-05-29 02:58:14 +0800
Sebastian Rasmussen <sebras@gmail.com>
c01e08cf984192defb63017e1a11a9f1bf05f9ef

> jbig2dec: Remove denial of service check which is no longer needed.
> In commit ee0bc20cc98c8e8381003a25dfa0b21e681c6545 an attempt to detect the end
> of the arithmetic integer decoder bit stream is detected. Now once more error
> handling has been implemented, the files from bug 694949 that caused this end of
> bitstream detection code to be added no longer end in an infinite loop, but fail
> with fatal errors due to other reasons.
> jbig2dec/jbig2_arith.c
> jbig2dec/jbig2_symbol_dict.c

2018-07-24 13:35:03 +0100
Ken Sharp <ken.sharp@artifex.com>
160431b50a3154341fa9ef1270ecb6f8ae045b4d

> Fix tiffpack and tifflzw devices
> Commit 0ef309305417776a9f8b8cd143fbf3c5e89456b2 moved the FillOrder
> parameter into the 'generic' tiff fax device structure, and added a new
> BlackIs1 parameter.
> The macro FAX_DEVICE_BODY was updated to reflect this but unfortunately
> two of the devices, tiffpack and tifflzw do not use the FAX_DEVICE_BODY
> macro, as they need to use device-specific code for the output_page
> device method.
> This meant that the initialisation of these devices was incorrect and
> led to failures in our automated testing.
> devices/gdevtfax.c

2018-07-23 11:54:50 +0100
Chris Liddell <chris.liddell@artifex.com>
da7288fe212f24db7789f9807b9e55a0e4367b8a

> gx_cpath_unshare(): zero unset entries.
> gx_cpath_unshare() does not copy the clip path list, and leaves the list
> structure uninitialized.
> Until/Unless we implement copying the list, set the values in the list to
> zero/NULL so later freeing of the unshared clip path doesn't trip up.
> base/gxcpath.c
> base/lib.mak

2018-07-18 16:41:17 +0100
Chris Liddell <chris.liddell@artifex.com>
954d535ee5a63ff751c1af24bbd45adefc2a078c

> Bug 699542: Fix compiler/linker options for shared lib on AIX
> configure.ac

2018-07-18 16:32:38 +0100
Chris Liddell <chris.liddell@artifex.com>
3afe2983e8e3c5fd9f290d7af0f7469d944a57ec

> Bug 699543: handle missing isinf() and fpclassify()
> Makefile.in
> base/lcms2mt.mak
> configure.ac
> lcms2mt/src/cmsplugin.c
> lcms2mt/src/lcms2_internal.h

2018-07-24 13:03:39 +0100
Ken Sharp <ken.sharp@artifex.com>
f6bcc0dfc173b80fddab4fbf10afb34332ff1112

> PDF interpreter - improve handling of 'q' inside a text object
> Bug #699551 "Text with rendering mode stroke is not displayed"
> We already did deal with a q/Q pair inside a text object (BT/ET pair)
> but a couple of points were missed. We didn't check for the existence
> of a qTextSavematrix in settextstate, which meant that we didn't
> set the text matrix. So vector and image marking worked, but text did
> not.
> We also didn't check for the existence of a qSaveTextMatrix when handling
> the stroke width for a text rendering mode which involves stroking the
> text.
> This commit exhibits one 'progression' (ie it now matches Acrobat) in
> the Quality Logice PDF 2.0 FTS files. I intend to raise this with QL as
> the file is demonstrably invalid.
> It also adversely impacts the performance of text in PDF files, since we
> must now do additional checking on every text operation. This has pushed
> a small number of our test files beyond the point where they start to
> time out on our automated testing.
> Resource/Init/pdf_ops.ps

2018-07-23 13:50:59 -0600
Henry Stiles <henry.stiles@artifex.com>
0ef309305417776a9f8b8cd143fbf3c5e89456b2

> Bug 699425, new fax device parameters added.
> Two new device parameters specify bit order and black white polarity,
> these parameters are the same as found in the tiff fax devices
> (gdevtfax.c)
> devices/gdevfax.c
> devices/gdevfax.h
> devices/gdevtfax.c

2018-07-23 11:51:03 -0600
Henry Stiles <henry.stiles@artifex.com>
dca564fc2a95b6610084ad06a939367217aa78e3

> Bug #699550 - Fix infinite loop processing PCL file with JPEG image.
> The color depth was set to 1 instead of 8 resulting in an ouput buffer
> smaller than the filter needed. Also, make sure we process the return
> code from the dct stream filter correctly so an error will be handled
> properly.
> pcl/pxl/pximage.c

2018-07-20 10:46:59 +0100
Ken Sharp <ken.sharp@artifex.com>
285cd8f8ced5b561116190d56e14baabef740ee9

> ps2write - add a check for PreserveSeparation
> When we check for a /Separation with a Lab alternate, check whether we
> should be preserving Separation spaces before going ahead and converting
> the alternate space to the ProcessColorModel of the device.
> devices/vector/gdevpdfg.c

2018-07-20 10:45:33 +0100
Ken Sharp <ken.sharp@artifex.com>
d0c058c8ef9112f6245e96e3cef81a24e7c9c103

> Documentation - Documentation on PreserveSeparation for pdfwrite was missing
> doc/VectorDevices.htm

2018-07-20 09:49:44 +0100
Ken Sharp <ken.sharp@artifex.com>
9e58cc8dd7e9b98620c798c901f800aff2e381ce

> ps2write - improve handling of Separation colour space with Lab alternate
> Bug #699535 "Separation Colors with alternate Color Lab are not converted correctly when device (e)ps2write is used"
> We can't embed a Lab space in the output from ps2write with the current
> colour handling. So instead spot the condition and convert the
> /Separation alternate space into the underlying ProcessColorModel.
> This preserves the /Separation ink, though the resulting tint transform
> is less than ideal.
> At the same time, make sure we don't try to handle the ICC Lab space
> as if it were a device space. Instead return a rangecheck error so that
> we convert the whole space into the ProcessColorModel.
> devices/vector/gdevpdfc.c
> devices/vector/gdevpdfg.c

2018-07-19 12:09:02 +0100
Ken Sharp <ken.sharp@artifex.com>
b44096b33d28d25c8f88c9fc2565713d85ca0614

> JBIG2DEC - add declarations which are not defined in VS 2005
> Like INT32_MAX and INT32_MIN, UINT32_MAX which is defined in stdint.h
> is not defined for old versions of Visual Studio. Add simple definitions
> in the two source files that use it, if it is not already defined.
> jbig2dec/jbig2_generic.c
> jbig2dec/jbig2_segment.c

2018-07-01 17:26:37 +0800
Sebastian Rasmussen <sebras@gmail.com>
e7ededef7c8b09845aedae08674519fbf50654b8

> jbig2dec: Ignore extension segments that are not marked necessary.
> Previously this was a fatal error, but it is better as a warning as
> the extension segment has not been marked necessary as outlined in
> the specification.
> jbig2dec/jbig2_segment.c

2018-07-04 22:23:26 +0800
Sebastian Rasmussen <sebras@gmail.com>
a6fef0ad778e67783204f71a28119a47fe6eb7c7

> jbig2dec: Improve halftoning debug message.
> jbig2dec/jbig2_halftone.c

2018-07-11 02:40:57 +0800
Sebastian Rasmussen <sebras@gmail.com>
c21d7dfb8cd82f698eb93b0b122a4e01c152faad

> jbig2dec: Fix composing subset of image onto destination.
> jbig2dec/jbig2_image.c

2018-07-01 13:19:43 +0800
Sebastian Rasmussen <sebras@gmail.com>
f8300fe31d487088e2de195ab0bf3a5725e6806f

> jbig2dec: Warn on out of range symbol IDs, but continue.
> jbig2dec/jbig2_text.c

2018-07-01 13:18:48 +0800
Sebastian Rasmussen <sebras@gmail.com>
12e9787cd20407b1440edf212d8e7f1c544dc29e

> jbig2dec: Use already parsed size of page association field.
> jbig2dec/jbig2_segment.c

2018-07-01 13:03:01 +0800
Sebastian Rasmussen <sebras@gmail.com>
72165c941ad4c4134ca593cd744be6b1b5ac1dda

> jbig2dec: Handle text regions without symbol dictionaries.
> Normal text regions reference symbol dictionaries. The symbols
> in those dictionaries are then referenced to by the text region
> and placed somewhere on the page. In the degenerate case a text
> region might not have any instances of symbols that it wants to
> place on the page. If that is the case then there is no need for
> the text region to refer to any symbol dictionaries (since it
> doesn't need any symbols). Previously this was treated as a fatal
> error, but now this just creates a warning and decoding proceeds.
> jbig2dec/jbig2_text.c

2018-07-01 13:07:19 +0800
Sebastian Rasmussen <sebras@gmail.com>
de25a4676d82587b8c6d6c6aeca3785514fde1c2

> jbig2dec: Attempting to compose NULL on a page is silently accepted.
> jbig2dec/jbig2_image.c

2018-07-04 22:19:34 +0800
Sebastian Rasmussen <sebras@gmail.com>
b417ef1deee793f93cc0643e3eccc4a8fea6cf3d

> jbig2dec: Make local functions static.
> jbig2dec/jbig2_halftone.c
> jbig2dec/jbig2_halftone.h

2018-06-29 01:54:15 +0800
Sebastian Rasmussen <sebras@gmail.com>
5158b558038c939c287d3a1194412134a5dc1134

> jbig2dec: Handling missing OOB at end of height class.
> jbig2dec/jbig2_symbol_dict.c

2018-06-24 16:00:30 +0800
Sebastian Rasmussen <sebras@gmail.com>
fb8347da8e388793a4add8442931dbd5033fce41

> jbig2dec: Handle immediate generic regions with unknown height.
> jbig2dec/jbig2.c
> jbig2dec/jbig2_generic.c
> jbig2dec/jbig2_segment.c
> jbig2dec/jbig2_segment.h

2018-06-27 02:13:04 +0800
Sebastian Rasmussen <sebras@gmail.com>
29371c6872f9b72e3810d76bd920f41619924fa7

> jbig2dec: Print segment number in messages when available.
> jbig2dec/jbig2.c
> jbig2dec/jbig2_generic.c
> jbig2dec/jbig2_mmr.c
> jbig2dec/jbig2_refinement.c
> jbig2dec/jbig2_segment.c
> jbig2dec/jbig2_symbol_dict.c

2018-06-22 21:16:24 +0800
Tor Andersson <tor.andersson@artifex.com>
d469fa3d995c8593680c2425f9c2c5a7a231bac7

> jbig2dec: Avoid accessing bytes outside of MMR decoder line.
> Previously the file Bug688080.pdf in bug 693798 e.g. has an object 668
> containing a JBIG2 bitstream containing an MMR-coded region where the
> width of the region is 32 pixels. At one point while decoding this
> image, a0 is in the middle of the line and because of the decoded black
> and white runs both a1 and a2 end up at the pixel just beyond the end
> of the line. At this point jbig2dec would access the byte supposedly
> containing this pixel beyond the end of the line, but that is not
> allowed. Because this byte was written back unchanged no real harm was
> done, but the access was still being performed, triggering software
> like valgrind/ASAN that detects buffer overflows.
> This commit also reverts the incorrect fix for bug 693798
> introduced in commit 46d6b40803cb7a68ceb06b2f71db8cf3f384c2ee
> where the allocated image buffer was simply extended by one byte,
> thereby accommodating the illegal access.
> jbig2dec/jbig2_image.c
> jbig2dec/jbig2_mmr.c

2018-07-14 18:19:47 +0800
Sebastian Rasmussen <sebras@gmail.com>
dfa5b1b784b9c575cb9d797248e282871d24625c

> jbig2dec: Untie fix for Visual Studio from Microsoft's compiler.
> The i32 suffix is specific for MSVC, but can be avoided.
> gssprintf.c for APR_INT32_MAX and APR_INT32_MIN also leaves out
> the suffix out. This is legal because the default integer literal
> size is large enough to fit 32 bit signed integers.
> jbig2dec/jbig2_arith_int.c

2018-07-14 10:31:08 +0100
Ken Sharp <ken.sharp@artifex.com>
29363ac25e7f8796e4cd09a7a88b3b1104191519

> Jbig2dec - Fix compile error on old version of Visual Studio
> A recent change uses INT32_MAX and INT32_MIN, but these are not defined
> in old versions of Visual Studio (not C99 probably).
> This commit works around the problem by including two simple #defines
> if the values are undefined.
> Sebastian may want to alter this.
> jbig2dec/jbig2_arith_int.c

2018-06-10 16:36:21 +0800
Sebastian Rasmussen <sebras@gmail.com>
c7bd3bb9fc9d008ab9d70f4d762be95d3f33cb0c

> jbig2dec: Plug context leak upon errors.
> E.g. failing to complete a page previously caused a context leak.
> jbig2dec/jbig2dec.c

2018-06-10 21:29:31 +0800
Sebastian Rasmussen <sebras@gmail.com>
d06d19b3cfda9a563ffa09e4aa58322774d751fb

> jbig2dec: Free huffman tables upon symbol dictionary parse errors.
> jbig2dec/jbig2_symbol_dict.c

2018-06-10 21:14:48 +0800
Sebastian Rasmussen <sebras@gmail.com>
afed61efb38bed3a5580ee0e458b8c6946ee49f5

> jbig2dec: Free symbol images upon text region parse error.
> The symbol images were previously not freed upon errors.
> jbig2dec/jbig2_text.c

2018-06-19 23:16:17 +0800
Sebastian Rasmussen <sebras@gmail.com>
314fb613ca8fa3028e33627bbb3fa484d4da1e13

> jbig2dec: Remove untested, incomplete metadata handling.
> base/jbig2.mak
> jbig2dec/Makefile.am
> jbig2dec/Makefile.unix
> jbig2dec/jbig2_metadata.c
> jbig2dec/jbig2_metadata.h
> jbig2dec/jbig2_segment.c
> jbig2dec/msvc.mak
> windows/ghostscript.vcproj
> windows/ghostscript_rt.vcxproj

2018-06-19 01:31:14 +0800
Sebastian Rasmussen <sebras@gmail.com>
3835fcfe6d3894e03a68c66bd211c7a739007b5d

> jbig2dec: Limit EXRUNLENGTH according to symbol dictionary header.
> jbig2dec/jbig2_symbol_dict.c

2018-06-19 01:30:34 +0800
Sebastian Rasmussen <sebras@gmail.com>
22e702351066d38c30d2bf695140f8fe6719c3f3

> jbig2dec: Remove unnecessary limitation of EXRUNLENGTH.
> Due to missing boundary checks in other code bug 693285 was resolved
> by limiting the number of times EXRUNLENGTH may be zero. This limit
> is actually not according to the specification. Now that the missing
> boundary checks have been introduced the limitation may be removed.
> jbig2dec/jbig2_symbol_dict.c

2018-06-18 19:04:38 +0800
Sebastian Rasmussen <sebras@gmail.com>
be27bd6685b714e1deca80d580d3ff9dc82f78dc

> jbig2dec: Make private function static.
> jbig2dec/jbig2_metadata.c
> jbig2dec/jbig2_metadata.h

2018-05-30 15:31:10 +0800
Sebastian Rasmussen <sebras@gmail.com>
79eee7b35a6070cacfe94343d01e9e1b7ebb1191

> jbig2dec: Return NULL upon error, avoid returning variable.
> This makes it clearer what is being returned upon error.
> jbig2dec/jbig2.c
> jbig2dec/jbig2_arith.c
> jbig2dec/jbig2_arith_iaid.c
> jbig2dec/jbig2_arith_int.c
> jbig2dec/jbig2_huffman.c
> jbig2dec/jbig2_segment.c

2018-06-01 14:33:11 -0700
Sebastian Rasmussen <sebras@gmail.com>
a97b724a6639e710cb4626ba53be2f86b1ebd5ba

> jbig2dec: Make sure to print fatal error upon detected error.
> jbig2dec/jbig2_huffman.c

2018-06-01 16:56:39 -0700
Sebastian Rasmussen <sebras@gmail.com>
8ea06bef59929bbaa0450a94ab9586dd154657e8

> jbig2dec: Make sure to return fatal/warnings when propagating error.
> jbig2dec/jbig2_huffman.c
> jbig2dec/jbig2_symbol_dict.c
> jbig2dec/jbig2_text.c

2018-05-30 17:30:37 +0800
Sebastian Rasmussen <sebras@gmail.com>
443588c95d5776f141940d57aee2b3a0a21b668f

> jbig2dec: Change types to match those of the parsed data.
> jbig2dec/jbig2_generic.c
> jbig2dec/jbig2_halftone.c

2018-06-21 00:30:02 +0800
Sebastian Rasmussen <sebras@gmail.com>
0188d0818b6f5b25aefdbafefa46d2845a21da9b

> jbig2dec: Keep track of previous lines in generic region decoding.
> This avoids issues with negative array indices.
> jbig2dec/jbig2_generic.c

2018-05-30 14:26:16 +0800
Sebastian Rasmussen <sebras@gmail.com>
7352f5a01fd2e0a1f221d25cbf35fe088226232e

> jbig2dec: No need to check for NULL in huff_get_next_word, use macro instead.
> jbig2dec/jbig2_huffman.c

2018-05-27 02:49:49 +0800
Sebastian Rasmussen <sebras@gmail.com>
6da6f365a8c93128fcd67938ed3f5ef362c77630

> jbig2dec: Label everything not yet implemented NYI.
> jbig2dec/jbig2_halftone.c
> jbig2dec/jbig2_segment.c

2018-05-27 02:48:56 +0800
Sebastian Rasmussen <sebras@gmail.com>
67c937009233f4496b8ece8270c10c4021785752

> jbig2dec: Validate ASCII characters in metadata comments.
> jbig2dec/jbig2_metadata.c

2018-05-27 00:33:45 +0800
Sebastian Rasmussen <sebras@gmail.com>
5c8a10f2e936b990fa3340650849186e92f1ecfd

> jbig2dec: Implement support for profile segment.
> The information in the profile segment is simply printed
> as informational messages via jbig2_error().
> jbig2dec/jbig2_segment.c

2018-04-24 21:43:48 +0800
Sebastian Rasmussen <sebras@gmail.com>
46f4acd48c81fa0db76f26c40b2e76c0fe7d7842

> jbig2dec: Implement support for outputting multipage PBM files.
> jbig2dec/jbig2dec.c

2018-04-25 02:47:39 +0800
Sebastian Rasmussen <sebras@gmail.com>
540f6a2f1c7f98b29b60a6e666623caec8dc8983

> jbig2dec: Share arithmetic/huffman decoding contexts/tables.
> Previously text regions had their own arithmetic/huffman
> decoding contexts/tables, separate from those used to decode
> fields in the symbol dictionary itself. This is incorrect.
> Annex E.3.7 describes how to reset the arithmetic coding
> contexts. Only the top-level symbol dictionary decoding
> procedure described in chapter 7.4.2.2 references this
> annex.
> Neither the symbol dictionary decoding procedure outlined
> in chapter 6.5 in the specification, nor chapter 6.5.8
> describing how to decode the symbol bitmap itself (and
> thereby implicitly chapter 6.2 describing the generic
> region decoding procedure, 6.4 explaining the text
> region decoding procedure and 6.5.8.2.2 describing how to
> decode bitmaps with only one symbol in the
> refinement/aggregate coding) refer to annex E.3.7.
> It is therefore incorrect to separate the arithmetic
> integer decoding contexts from the ones used to parse
> the symbol dictionary fields as the specification calls
> for these to be reused.
> This created a problem when decoding page 3 in the sample
> bitstream in Annex H.1. More specifically in Annex H.1,
> step 37 (f) xi E where the refinement flag was decoded as
> 3 instead of the expected 0. This was because the IAID
> arithmetic coding context used in step 37 (f) xi D had
> not been shared with that in step 37 (f) v as is expected
> in the specification. The result was that page 3 of the
> sample bitstream was never decoded. Potentially this may
> also have affected other JBIG2 bitstreams.
> Sharing the arithmetic coding contexts between the symbol
> dictionary decoding procedure and the text region decoder
> resolves the issue
> jbig2dec/jbig2_symbol_dict.c

2018-06-18 18:48:49 +0800
Sebastian Rasmussen <sebras@gmail.com>
d7b659b9853059ddd1d5ecaab79de16a7f675b32

> jbig2dec: Handle very large symbol code lengths without overflowing.
> jbig2dec/jbig2_symbol_dict.c

2018-04-25 02:33:52 +0800
Sebastian Rasmussen <sebras@gmail.com>
62df49ab137726635c9f3d2f76c0b599d733e8b5

> jbig2dec: Reorder test for huffman decoding vs arithmetic integer decoding.
> jbig2dec/jbig2_symbol_dict.c

2018-04-25 02:27:59 +0800
Sebastian Rasmussen <sebras@gmail.com>
fdf1504cb5dfbe77b0458ccad025fc992df77ad8

> jbig2dec: Move text region decoder parameters initialization.
> Previously the text region decoder parameters were only initialized
> once a text region was about to be decoded. Now they are initialized
> at the beginning of the decoding of the symbol dictionary. This
> prepares for sharing of the IAID, IARDX and IARDY arithmetic
> integer decoder contexts as well as the SBHUFFRDX, SBHUFFRDY and
> SBHUFFRSIZE huffman tables between the text region decoder and the
> symbol dictionary parser itself.
> jbig2dec/jbig2_symbol_dict.c

2018-04-25 02:16:29 +0800
Sebastian Rasmussen <sebras@gmail.com>
e32e214b5de77ca1b658e46ae8d7cc6cabfb9d62

> jbig2dec: Simplify cleanup when parsing symbol dictionary.
> In the process move all cleanup, including any intermediate
> images to the cleanup section towards the end of the symbol
> decoding function.
> jbig2dec/jbig2_symbol_dict.c

2018-04-25 02:11:00 +0800
Sebastian Rasmussen <sebras@gmail.com>
94a5d891cb5cf495b4d2bb8460b293b39e1603ce

> jbig2dec: Initialize huffman table for size of symbols refinement data.
> Previously this was uninitialized, possibly leading to dereferencing
> an uninitialized table pointer.
> jbig2dec/jbig2_symbol_dict.c

2018-04-25 01:57:52 +0800
Sebastian Rasmussen <sebras@gmail.com>
a27e623cac13c67926c42222589ff87f76f369dc

> jbig2dec: Let symbol refinement Y offset use its own huffman table.
> Previously both the symbol instances refinement X and Y offset reused
> the same table SBHUFFRDX, but according to 6.4.11.3 and 6.4.11.4 in
> the specification they ought to be using the independent SBHUFFRDX
> and SBHUFFRDY tables. Let's make it so.
> jbig2dec/jbig2_symbol_dict.c

2018-04-25 01:50:07 +0800
Sebastian Rasmussen <sebras@gmail.com>
721338e0846bc0e50cf4528ba6b0d54b1a577db4

> jbig2dec: Remember to put all new symbols into ref/agg dictionary.
> Previously the symbol dictionary propagated to the text region
> decoder for a refinement/aggregate coded symbol did not contain
> all necessary symbols. Only the symbols in the symbol dictionaries
> referred to (SDINSYMS) by the currently parsed symbol dictionary
> would be propagated into the text region decoder (SBSYMS).
> Table 17 in the specification states that SBSYMS should be set
> according to 6.5.8.2.4 which clearly states that SDINSYMS as well
> as any symbols decoded up to that point (NSYMSDECODED symbols in
> SDNEWSYMS) ought to be introduced into the dictionary that is
> propagated to the text region decoder (SBSYMS). This is now done
> by providing the text region decoder not just with a single symbol
> dictionary, but both with SDINSYMS and SDNEWSYMS allowing the
> decoder to refer to symbols from both.
> jbig2dec/jbig2_symbol_dict.c

2018-04-24 22:32:16 +0800
Sebastian Rasmussen <sebras@gmail.com>
9eab580c634eb61d9340ebc40f4c40174ed226c5

> jbig2dec: Paper over the fact that VS 2010 and earlier may not have SIZE_MAX.
> jbig2dec/config_win32.h

2018-04-20 02:33:31 +0800
Sebastian Rasmussen <sebras@gmail.com>
0ee7f3b1c19f6d777eaf6bdf2b8ea8d241bf49d4

> jbig2dec: Check for T.88 amendments 2/3 bitstreams.
> T.88 Amendment 2 adds up to 12 adaptive template pixels in generic regions.
> T.88 Amendment 3 adds support for generic/text regions to encode colors.
> Neither amendment is implemented and no sample files have been found.
> Return fatal errors for such bitstreams/files for the time being.
> jbig2dec/jbig2.c
> jbig2dec/jbig2_generic.c
> jbig2dec/jbig2_page.c
> jbig2dec/jbig2_segment.c
> jbig2dec/jbig2_text.c

2018-04-24 13:39:07 +0800
Sebastian Rasmussen <sebras@gmail.com>
b200c6e476d00e760100b0b3e23f6e57f0794969

> jbig2dec: Handle under-/overflow in arithmetic integer decoder.
> jbig2dec/jbig2_arith_int.c

2018-04-24 13:54:47 +0800
Sebastian Rasmussen <sebras@gmail.com>
d73eadc850bd8b4f3bd26a70d7916de9f5c824c8

> jbig2dec: Rename variables to closely follow the specification.
> jbig2dec/jbig2_refinement.c
> jbig2dec/jbig2_refinement.h
> jbig2dec/jbig2_symbol_dict.c
> jbig2dec/jbig2_text.c

2018-04-24 04:01:13 +0800
Sebastian Rasmussen <sebras@gmail.com>
f135d8f51b7a3da455c6cd4ccd88c5f6ab7f930b

> jbig2dec: Implement support for resizing image width.
> jbig2dec/jbig2_image.c

2018-04-24 03:48:35 +0800
Sebastian Rasmussen <sebras@gmail.com>
fe83cea1333445c0273e45003d6eeb172bc82e0e

> jbig2dec: When extending image use default page color.
> jbig2dec/jbig2_image.c
> jbig2dec/jbig2_image.h
> jbig2dec/jbig2_page.c

2018-04-24 03:40:06 +0800
Sebastian Rasmussen <sebras@gmail.com>
95df4340d0d65c1f5f180d31a93e8806ddb345dd

> jbig2dec: Clarify lack of support for dependency bit.
> The extension segment dependency bit only matters for
> encoders. This is because it informs the encoder what
> other segments a specific segment depends on. Since
> jbig2dec doesn't do any alteration of segments this
> need not be supported (or indeed even parsed).
> jbig2dec/jbig2_segment.c

2018-04-24 23:57:18 +0800
Sebastian Rasmussen <sebras@gmail.com>
edb5c4000cc7e38c1f9f5e93243ab1737e13aeee

> jbig2dec: Move arithmetic decoder test logging inside test.
> Also take the opportunity to make the test stream static.
> jbig2dec/jbig2_arith.c

2018-04-24 04:51:31 +0800
Sebastian Rasmussen <sebras@gmail.com>
3a2b2f13a26355a0ca7dc58d7c28276df3d7b786

> jbig2dec: Enable both huffman tests when running check.
> jbig2dec/jbig2_huffman.c

2018-04-23 14:02:46 +0800
Sebastian Rasmussen <sebras@gmail.com>
db1efdfb5f194079070bfd1ab50ae11e881de50d

> jbig2dec: Handle get_next_word() returning error/less than a word.
> This includes propagating the error handling to all callers.
> jbig2dec/jbig2_arith.c
> jbig2dec/jbig2_huffman.c
> jbig2dec/jbig2_huffman.h
> jbig2dec/jbig2_symbol_dict.c
> jbig2dec/jbig2_text.c

2018-04-24 20:05:39 +0800
Sebastian Rasmussen <sebras@gmail.com>
968c424a70471c086466568bee21097e89149663

> jbig2dec: free/release functions must handle NULL argument.
> jbig2dec/jbig2.c
> jbig2dec/jbig2_halftone.c
> jbig2dec/jbig2_huffman.c
> jbig2dec/jbig2_image.c
> jbig2dec/jbig2_metadata.c
> jbig2dec/jbig2_page.c
> jbig2dec/jbig2_segment.c
> jbig2dec/jbig2_symbol_dict.c

2018-04-11 00:02:39 +0800
Sebastian Rasmussen <sebras@gmail.com>
a21e4d7cf5b7928c490a2f804dfc01fc66069e35

> jbig2dec: Implement pixel out of field test for refinement regions too.
> jbig2dec/jbig2_refinement.c

2018-04-21 23:36:54 +0800
Sebastian Rasmussen <sebras@gmail.com>
01ae24d85f67b3c1b11993f1644a71da643ecc9b

> jbig2dec: Differentiate error messages in generic region decoder.
> This makes it easier to know from where the error message originated.
> jbig2dec/jbig2_generic.c

2018-04-22 01:45:15 +0800
Sebastian Rasmussen <sebras@gmail.com>
f920a1839a66b844651b2ff5524944b0dd9484cf

> jbig2dec: Fix and use decoder for template 3 generic regions.
> Previously an optimized implementation for template generic
> regions was commented out, presumably because it was faulty,
> but now once the implementation is fixed it may be used.
> The PDF in bug 693617 has an object 25 that contains a JBIG2
> bitstream that can use this fix optimized decoder. Without
> the fix in the optimized decoder the rendered output image
> is incorrect.
> jbig2dec/jbig2_generic.c

2018-04-23 01:25:34 +0800
Sebastian Rasmussen <sebras@gmail.com>
8e1b5e97f0950a47be4094028cf242a2b2861a07

> jbig2dec: Handle non-nominal adaptive pixel locations in template 2.
> Optimized generic region decoders can only handle nominal
> adaptive pixel locations, while the unoptimized generic region
> decoders can handle them being located at any location.
> Previously the optimized decode was always used regardless of the
> locations of the adaptive pixels, possibly causing decoding
> issues. Now an unoptimized decoder is added for template 2 and is
> being used whenever the adaptive pixel locations are at non-nominal
> locations.
> jbig2dec/jbig2_generic.c

2018-04-23 01:28:14 +0800
Sebastian Rasmussen <sebras@gmail.com>
c389757b311d9e01cf98cfb5d56c500929e28c43

> jbig2dec: Handle non-nominal adaptive pixel locations in template 1.
> Optimized generic region decoders can only handle nominal
> adaptive pixel locations, while the unoptimized generic region
> decoders can handle them being located at any location.
> Previously the optimized decode was always used regardless of the
> locations of the adaptive pixels, possibly causing decoding
> issues. Now an unoptimized decoder is added for template 1 and is
> being used whenever the adaptive pixel locations are at non-nominal
> locations.
> jbig2dec/jbig2_generic.c

2018-04-09 22:25:34 +0800
Sebastian Rasmussen <sebras@gmail.com>
d522f9a9815dce16977f7a9e9715e861cab76a55

> jbig2dec: Fix incorrect adaptive pixel location check.
> Previously for the adaptive pixel template 2 the check for the
> location of the adaptive pixel was wrong. Because generic regions
> with nominal locations are more common this lead to the
> unoptimized decoder being used. Only a few images where the
> adaptive pixel location happened to be at this wrong location
> used the optimized decoder, and presumably were decoded
> incorrectly. This incorrect location check therefore hid the bug
> in the optimized generic region decoder concerning what pixels
> are included at what location in the arithmetic integer context.
> Now the adaptive pixel location check is corrected as well as the
> bug in the optimized generic region decoder itself.
> jbig2dec/jbig2_generic.c

2018-05-24 03:27:21 +0800
Sebastian Rasmussen <sebras@gmail.com>
18a051f2f422f9d336e1d6a28f990068faaf2abc

> jbig2dec: Differentiate between errors/OOB when decoding BMSIZE.
> Previously the two very lumped together, causing a single error message.
> jbig2dec/jbig2_symbol_dict.c

2018-04-24 13:39:46 +0800
Sebastian Rasmussen <sebras@gmail.com>
851e3885386f992af8e73ba90c8b8fcf5a6cb69a

> jbig2dec: Print errors when out of boundary values occur.
> According to the specification in 6.4.5 when decoding text
> regions, where OOB values in IDS indicate that the last symbol
> in a strip has been decoded, or in 6.5.5 when decoding symbol
> dictionaries, where OOB values in DW indicate that all the
> symbols in a height class have been decoded. When decoding any
> other symbols than IDS or DW, OOB values are not expected, so
> report these as fatal errors.
> jbig2dec/jbig2_symbol_dict.c
> jbig2dec/jbig2_text.c

2018-04-25 02:08:40 +0800
Sebastian Rasmussen <sebras@gmail.com>
6f4075cae5c70e5f766a79d011624326c4bf5185

> jbig2dec: Check if all arithmetic decoder contexts are initialized.
> Previously the IADT and IARI contexts were never checked for having
> been successfully initialized, possibly causing uninitialized data
> issues later.
> jbig2dec/jbig2_symbol_dict.c

2018-05-24 03:28:04 +0800
Sebastian Rasmussen <sebras@gmail.com>
7241bffe648d3f75cd03bbaa404fc927163e6215

> jbig2dec: Skip over undecoded pages when getting pages.
> jbig2dec/jbig2_page.c

2018-05-24 03:23:25 +0800
Sebastian Rasmussen <sebras@gmail.com>
7b68d2964935c40fe8f58a9540c5765fb2f53f0f

> jbig2dec: Detect NULL image pointer before trying to take reference.
> Attempting to take a reference to NULL is a no-op anyway.
> jbig2dec/jbig2_refinement.c
> jbig2dec/jbig2_text.c

2018-06-01 10:36:53 -0700
Sebastian Rasmussen <sebras@gmail.com>
f8f900369183f908fb8e8796154e2c7b57fbd202

> jbig2dec: Rename jbig2_image_clone() to jbig2_image_reference().
> This more accurately explains what the function does, and
> mirrors jbig2_image_release() quite well.
> jbig2dec/jbig2_image.c
> jbig2dec/jbig2_image.h
> jbig2dec/jbig2_page.c
> jbig2dec/jbig2_refinement.c
> jbig2dec/jbig2_symbol_dict.c
> jbig2dec/jbig2_text.c

2018-05-24 03:24:33 +0800
Sebastian Rasmussen <sebras@gmail.com>
c3707893650d631dfcc4ca5a99b2eb28f7108fd9

> jbig2dec: Refinement bitmaps without images should be treated as fatal errors.
> jbig2dec/jbig2_refinement.c

2018-05-23 23:12:16 +0800
Sebastian Rasmussen <sebras@gmail.com>
dc80246ab0a08f3c946d43d930c772dedb8b7bf4

> jbig2dec: Report warnings if called functions indicate errors.
> The first error detected ought to be a fatal error, but when this
> error condition is propagated to callers, they should indicate warnings.
> jbig2dec/jbig2.c
> jbig2dec/jbig2_generic.c
> jbig2dec/jbig2_halftone.c
> jbig2dec/jbig2_page.c
> jbig2dec/jbig2_refinement.c
> jbig2dec/jbig2_symbol_dict.c
> jbig2dec/jbig2_text.c

2018-05-27 02:51:10 +0800
Sebastian Rasmussen <sebras@gmail.com>
689fa69bfd6c423194e58f22835836870cb519b5

> jbig2dec: Unsupported intermediate generic region is now a fatal error.
> jbig2dec/jbig2_segment.c

2018-05-27 02:50:32 +0800
Sebastian Rasmussen <sebras@gmail.com>
f394d8e7b5588bed1c2265136da0bcb2502507fb

> jbig2dec: Halftone regions with skip enabled is now a fatal error.
> jbig2dec/jbig2_halftone.c

2018-05-24 03:20:52 +0800
Sebastian Rasmussen <sebras@gmail.com>
de4b96e07690cde1999554b1413d79f20d1e8523

> jbig2dec: Detected errors should be fatal, not warnings.
> jbig2dec/jbig2_generic.c
> jbig2dec/jbig2_metadata.c

2018-05-23 21:48:31 +0800
Sebastian Rasmussen <sebras@gmail.com>
d175962540cd0ff2b6dcec2a13bf61a17df93741

> jbig2dec: Remember to free IAID context upon error.
> Previously this might result in a memory leak.
> jbig2dec/jbig2_arith_iaid.c

2018-05-24 00:52:15 +0800
Sebastian Rasmussen <sebras@gmail.com>
e32e5535ca5055e31417d022753eed67a30d482e

> jbig2dec: Free referred to symbol dictionary upon error.
> jbig2dec/jbig2_symbol_dict.c

2018-05-24 03:26:43 +0800
Sebastian Rasmussen <sebras@gmail.com>
fc4940d6aabebd6516befefc0b51676ccc332a7f

> jbig2dec: Pages without decoded images cannot be completed.
> jbig2dec/jbig2_page.c

2018-05-24 00:51:20 +0800
Sebastian Rasmussen <sebras@gmail.com>
e4e1e6ac335eaccd92eff57308e173ac67a392f0

> jbig2dec: When a page fails to complete, handle as an error.
> Previously this only caused a warning message but didn't fail,
> but failing to complete a page means the parsing is somehow broken,
> and so it ought to be best to treat it as a fatal error.
> jbig2dec/jbig2dec.c

2018-05-24 00:33:18 +0800
Sebastian Rasmussen <sebras@gmail.com>
3da06c6284e3370f31382299eddf7c76f11960cd

> jbig2dec: Releasing a page cannot not fail.
> It can only fail if you supply a random page pointer.
> Don't do that it would be a programming error.
> jbig2dec/jbig2.h
> jbig2dec/jbig2_page.c

2018-05-23 23:21:27 +0800
Sebastian Rasmussen <sebras@gmail.com>
451ee5588ec2616afc21ae9ccc61c2afb8144bf7

> jbig2dec: Directly return jbig2_error(FATAL); they indicate errors.
> Because jbig2_error(ctx, JBIG2_SEVERITY_FATAL, ...) returns -1,
> it can be immediately returned or assigned as a return code.
> jbig2dec/jbig2_huffman.c
> jbig2dec/jbig2_metadata.c
> jbig2dec/jbig2_text.c

2018-05-23 23:12:43 +0800
Sebastian Rasmussen <sebras@gmail.com>
1e751b882e18fee36a16488e7b46c0e1b571d605

> jbig2dec: Return jbig2_error(WARNING); they indicate errors.
> Because jbig2_error(ctx, JBIG2_SEVERITY_WARNING, ...) now returns -1,
> it can be immediately returned or assigned as a return code.
> jbig2dec/jbig2_generic.c
> jbig2dec/jbig2_halftone.c
> jbig2dec/jbig2_metadata.c
> jbig2dec/jbig2_mmr.c
> jbig2dec/jbig2_page.c
> jbig2dec/jbig2_symbol_dict.c
> jbig2dec/jbig2_text.c

2018-05-24 01:24:32 +0800
Sebastian Rasmussen <sebras@gmail.com>
c159c4534b9b9af4998d6dcdee896fe2197fa542

> jbig2dec: Convert debug messages in debug code to warnings.
> This is because the debug code calls functions that write
> PBM images or similar, these may fail and when this happens
> the calling function ought to print a warning and fail itself.
> jbig2dec/jbig2_page.c
> jbig2dec/jbig2_refinement.c
> jbig2dec/jbig2_symbol_dict.c

2018-05-23 00:22:41 +0800
Sebastian Rasmussen <sebras@gmail.com>
a8b6f19d5f5e7af568c448421c24bbe200ea9c89

> jbig2dec: Error callback should not modify jbig2_error() return code.
> If a function detects an error it should call
> jbig2_error(ctx, JBIG2_SEVERITY_FATAL, ...) and return -1. The caller
> of this function may then detect the return code indicating error
> and call jbig2_error(ctx, JBIG2_SEVERITY_WARNING, ...). Previously
> this latter call to jbig2_error() would not return -1, but it is good
> form for the calling function to fail and return -1 to the next caller.
> Therefore the error callback no longer has the option to override the
> return code from jbig2_error(), instead jbig2_error() always returns -1.
> base/sjbig2.c
> jbig2dec/jbig2.c
> jbig2dec/jbig2.h
> jbig2dec/jbig2dec.c

2018-05-23 02:00:49 +0800
Sebastian Rasmussen <sebras@gmail.com>
2c743c193e1812795c9c23a8c6cc9d69d2a47eb5

> jbig2dec: Only return jbig2_error() for fatal errors/warnings.
> Only calls to jbig2_error() using fatal errors or warnings may
> return, no calls to jbig2_error() using informational or debug
> messages may return. This is preparation for jbig2_error() to
> always return -1 for errors/warnings.
> jbig2dec/jbig2_refinement.c
> jbig2dec/jbig2_segment.c

2018-04-06 23:43:51 +0800
Sebastian Rasmussen <sebras@gmail.com>
be59a40717ec60a5a054ccf88f7064c90788aa78

> jbig2dec: Add support to process embedded JBIG2 bitstreams.
> This type of stream is present in PDF files which is a good source
> of test streams for jbig2dec.
> jbig2dec/jbig2dec.c

2018-04-24 04:19:31 +0800
Sebastian Rasmussen <sebras@gmail.com>
d7f529ac50d61a1fe07eb1a667322234402e9894

> jbig2dec: Remove check for bitmap coding context use.
> The removed check used bitmask 0x80 to check for the flag
> "bitmap coding context used" among the symbol dictionary flags.
> The correct bitmask is 0x100, which was already checked for
> later in the code, rendering this incorrect check unnecessary.
> jbig2dec/jbig2_symbol_dict.c

2018-04-22 16:11:32 +0800
Sebastian Rasmussen <sebras@gmail.com>
22fbf1bb62b49316452c7556399618399c463039

> jbig2dec: Return error code from get_next_word().
> Previously Jbig2WordStream's get_next_word() callback
> sometimes returned error codes. This contradicted the
> declaration of the callback. However indicating errors
> and the number of bytes returned upon successful calls
> is a good idea. The declaration and all implementations
> of the callback have been adjusted accordingly.
> This means that jbig2dec now compiles without warnings.
> jbig2dec/jbig2.c
> jbig2dec/jbig2_arith.c
> jbig2dec/jbig2_huffman.c
> jbig2dec/jbig2_priv.h

2018-04-25 05:01:41 +0800
Sebastian Rasmussen <sebras@gmail.com>
ef05820d514fd6a27d1b7690df16b63f8b20cf26

> jbig2dec: Indicate success when using arithmetic decoder.
> Commit 2b2dcf4ccf401ed210f03c858b304994749fd2b3 accidentally
> forgot to set the out parameter to indicate success when the
> call was indeed successful.
> jbig2dec/jbig2_arith.c

2018-05-23 20:05:20 +0800
Sebastian Rasmussen <sebras@gmail.com>
359a15e1c8b460268ff80fb8e8a5da121fcbafc3

> jbig2dec: Avoid NULL-check before jbig2_free()/jbig2_image_release().
> jbig2dec/jbig2_halftone.c
> jbig2dec/jbig2_huffman.c
> jbig2dec/jbig2_segment.c
> jbig2dec/jbig2_symbol_dict.c

2018-05-23 00:04:55 +0800
Sebastian Rasmussen <sebras@gmail.com>
b9f15473bdd8f48b9336b67d15dc08a6f78f750b

> jbig2dec: Move declarations from jbig2_priv.h to their respective headers.
> Due to this some .c-files now need new includes.
> jbig2dec/jbig2.c
> jbig2dec/jbig2.h
> jbig2dec/jbig2_generic.c
> jbig2dec/jbig2_generic.h
> jbig2dec/jbig2_halftone.c
> jbig2dec/jbig2_halftone.h
> jbig2dec/jbig2_huffman.c
> jbig2dec/jbig2_image.h
> jbig2dec/jbig2_metadata.c
> jbig2dec/jbig2_page.c
> jbig2dec/jbig2_priv.h
> jbig2dec/jbig2_segment.c
> jbig2dec/jbig2_symbol_dict.c
> jbig2dec/jbig2_text.c
> jbig2dec/jbig2_text.h

2018-05-26 19:12:28 +0800
Sebastian Rasmussen <sebras@gmail.com>
c6d6efdc340e0cac31cda1bbb654bcbfcda92b47

> jbig2dec: Create jbig2_segment.h with segment declarations.
> jbig2dec/jbig2.c
> jbig2dec/jbig2.h
> jbig2dec/jbig2_generic.c
> jbig2dec/jbig2_halftone.c
> jbig2dec/jbig2_huffman.c
> jbig2dec/jbig2_metadata.c
> jbig2dec/jbig2_page.c
> jbig2dec/jbig2_priv.h
> jbig2dec/jbig2_refinement.c
> jbig2dec/jbig2_segment.c
> jbig2dec/jbig2_segment.h
> jbig2dec/jbig2_symbol_dict.c
> jbig2dec/jbig2_text.c

2018-05-26 15:00:00 +0800
Sebastian Rasmussen <sebras@gmail.com>
624bc3cc86c95bc6215d02d6bf39ff694e2c2a9d

> jbig2dec: Create jbig2_refinement.h with refinement declarations.
> jbig2dec/jbig2_generic.h
> jbig2dec/jbig2_priv.h
> jbig2dec/jbig2_refinement.c
> jbig2dec/jbig2_refinement.h
> jbig2dec/jbig2_segment.c
> jbig2dec/jbig2_symbol_dict.c
> jbig2dec/jbig2_text.c

2018-05-26 14:51:42 +0800
Sebastian Rasmussen <sebras@gmail.com>
8f4288807d659f72734d41dd8b7d434b1e15dfc2

> jbig2dec: Create jbig2_page.h with page declarations.
> jbig2dec/jbig2.c
> jbig2dec/jbig2_generic.c
> jbig2dec/jbig2_halftone.c
> jbig2dec/jbig2_page.c
> jbig2dec/jbig2_page.h
> jbig2dec/jbig2_priv.h
> jbig2dec/jbig2_refinement.c
> jbig2dec/jbig2_segment.c
> jbig2dec/jbig2_text.c

2018-05-26 15:12:54 +0800
Sebastian Rasmussen <sebras@gmail.com>
55925ee6220fe371b1fe34fdc27cfd4dad8847b2

> jbig2dec: Create jbig2_image_rw.h with image reading/writing declarations.
> jbig2dec/jbig2_image.h
> jbig2dec/jbig2_image_pbm.c
> jbig2dec/jbig2_image_rw.h
> jbig2dec/jbig2dec.c
> jbig2dec/pbm2png.c

2018-05-26 15:01:37 +0800
Sebastian Rasmussen <sebras@gmail.com>
f7d2387f73488a24db04b22884d1e2c7bb83a857

> jbig2dec: Remove non-existing function from header.
> jbig2dec/jbig2_priv.h

2018-05-24 23:54:54 +0800
Sebastian Rasmussen <sebras@gmail.com>
cbb2072c14305de22f2334acf44a080933f26e21

> jbig2dec: Add include guards to all headers.
> jbig2dec/jbig2_arith.h
> jbig2dec/jbig2_arith_iaid.h
> jbig2dec/jbig2_arith_int.h
> jbig2dec/jbig2_generic.h
> jbig2dec/jbig2_huffman.h
> jbig2dec/jbig2_hufftab.h
> jbig2dec/jbig2_mmr.h
> jbig2dec/jbig2_priv.h
> jbig2dec/jbig2_symbol_dict.h
> jbig2dec/jbig2_text.h

2018-05-24 03:18:04 +0800
Sebastian Rasmussen <sebras@gmail.com>
6cc76f397ff5af382e4e49914d1b42df3e0a78e4

> jbig2dec: Rephrase error messages.
> jbig2dec/jbig2.c
> jbig2dec/jbig2_arith_int.c
> jbig2dec/jbig2_generic.c
> jbig2dec/jbig2_halftone.c
> jbig2dec/jbig2_huffman.c
> jbig2dec/jbig2_image.c
> jbig2dec/jbig2_image_png.c
> jbig2dec/jbig2_mmr.c
> jbig2dec/jbig2_page.c
> jbig2dec/jbig2_refinement.c
> jbig2dec/jbig2_segment.c
> jbig2dec/jbig2_symbol_dict.c
> jbig2dec/jbig2_text.c

2018-05-24 02:05:36 +0800
Sebastian Rasmussen <sebras@gmail.com>
344a90c91dc03e9ae80500303e67594f175374e3

> jbig2dec: Remove unnecessary scoping.
> jbig2dec/jbig2_refinement.c

2018-04-25 00:50:12 +0800
Sebastian Rasmussen <sebras@gmail.com>
120732b27011a1651ebfcf50536cac953c7b4c9b

> jbig2dec: Remove many unnecessary parentheses.
> jbig2dec/jbig2_page.c
> jbig2dec/jbig2_symbol_dict.c
> jbig2dec/jbig2_text.c

2018-04-22 23:08:49 +0800
Sebastian Rasmussen <sebras@gmail.com>
b3d2e786ace758422cdeb22c1cc688bb52087ddf

> jbig2dec: Remove unnecessary comments, whitespace and unused code.
> jbig2dec/jbig2.c
> jbig2dec/jbig2_generic.c
> jbig2dec/jbig2_halftone.c
> jbig2dec/jbig2_huffman.c
> jbig2dec/jbig2_image.c
> jbig2dec/jbig2_page.c
> jbig2dec/jbig2_refinement.c
> jbig2dec/jbig2_segment.c
> jbig2dec/jbig2_symbol_dict.c
> jbig2dec/jbig2_text.c
> jbig2dec/jbig2dec.c

2018-05-08 22:35:11 +0800
Sebastian Rasmussen <sebras@gmail.com>
def343c44322ebdf609d0113884385d944dc361a

> jbig2dec: Fix typos in error messages and comments.
> jbig2dec/jbig2_halftone.c
> jbig2dec/jbig2_huffman.c
> jbig2dec/jbig2_metadata.c
> jbig2dec/jbig2_page.c
> jbig2dec/jbig2_symbol_dict.c
> jbig2dec/jbig2dec.1

2018-05-26 15:46:16 +0800
Sebastian Rasmussen <sebras@gmail.com>
a4ebc6d3cd3e2fcab8b3e9b7bcb7364c14f09d8d

> jbig2dec: Reindent sources in the same way as before.
> Accept some whitespace changes as done by the commands
> from commit d3d767d9b91ae7d82c261fbdfd735f3042161032.
> jbig2dec/jbig2.c
> jbig2dec/jbig2_arith.h
> jbig2dec/jbig2_halftone.c
> jbig2dec/jbig2_image.c
> jbig2dec/jbig2_metadata.c
> jbig2dec/jbig2_mmr.c
> jbig2dec/jbig2_page.c
> jbig2dec/jbig2_priv.h
> jbig2dec/jbig2_symbol_dict.c
> jbig2dec/jbig2dec.c

2018-07-12 16:35:12 +0100
Ken Sharp <ken.sharp@artifex.com>
bc6af8da1adc9b4939e3acbfc4194a143412af3c

> Fix an error in the type 3 stitching function monotonic detection
> Bug #699528 "A rare edge condition can cause a function to incorrectly signal a rangecheck error"
> This is rather difficult to describe. The problem occurs when we try to
> check for monotonicity of a stitching function between two data points
> of the parametric variable.
> We actually calculate a series of points between the two values and
> check to see that they all increase (or decrease). However, a stitching
> function can contain multiple functions, and so we break the range of
> values into groups at the limits of each function and check each
> group of values.
> If the lower value of the parameteric variable is 'close' to the upper
> bound of the current function, we decide to 'punt' it up to the next
> function, presumably to avoid the overhead of a miniscule break. That is
> we simply don't bother calculating tiny amounts at the end of a function
> we just do the next function.
> However, if the upper range of the parametric variable happened also
> to lie close to (but less than) the upper bound of the function, then
> when we used it to evaluate the next function in the array, it would lie
> below the bottom bound of that function, resulting in a rangecheck error.
> This commit applies two fixes; firstly, if the upper and lower values
> of the parametric variable are the same then this is a point, and there
> is no point in checking it, so just jump straight out.
> Secondly, the upper value is now promoted to the lower bound of the
> current function if it is less than that. This prevents us trying to
> use an out of bound value, in case we should somehow get both an upper
> *and* a lower bound which lie within the 'noise' threshold.
> Because the range of 'noise' is so small (the bounds values of the
> function divided by 1 million) there is no practical likelihood of
> us missing a function which is not monotonic between those data
> points.
> base/gsfunc3.c

2015-03-19 11:33:51 +0000
Tim Waugh <twaugh@redhat.com>
00c14a25c0f0d5e5e65d2d489045e566ccf436df

> bug #695876: check that page margins don't overlap in cups driver.
> cups/gdevcups.c

2018-07-10 09:51:37 +0100
Ken Sharp <ken.sharp@artifex.com>
87cfc860ea49a4a39c1198b419a019ed598416f0

> PDF interpreter improve handling of PageLabels as pdfmark
> Patch supplied by Leon Bottou, see Bug #696568. This improves the way
> the code handles the number tree when converting it to pdfmark
> operations.
> I don't have any reasonable way to test this, as it relies on using a
> device which implements pdfmark, but doesn't implement WantsPageLabels
> (to avoid getting the number tree passed).
> Resource/Init/pdf_base.ps
> Resource/Init/pdf_main.ps

2018-07-10 08:50:11 +0100
Ken Sharp <ken.sharp@artifex.com>
ac9f8412e8c35edd7c0bbbbcd1c7195a56bc15d8

> PDF interpreter - fix new PageLabels processing for non-pdfwrite case
> The commit to treat PageLabels as pdfmark operations instead of using
> our internal code had a logical error when *not* using pdfwrite.
> Committed verbatim as there's no simple way to test this case.
> Resource/Init/pdf_main.ps

2018-07-09 09:24:27 -0700
Nancy Durgin <nancy.durgin@artifex.com>
d45ebe705de7b7618ad0d0d20fc31a960c8d9ba2

> Bug 690339 - use free/alloc instead of resize when change frame buffer size
> In gdev_prn_allocate(), when size of frame buffer changed, we used to call
> call gs_resize_object(). Now we call gs_free_object() followed by
> gs_alloc_bytes().
> Two advantages -- avoids copying the old frame buffer to the new one
> (which was pointless) and now the old buffer and new buffer don't need
> to coexist, which could help on a low memory system.
> base/gdevprn.c

2018-07-09 16:49:38 +0100
Ken Sharp <ken.sharp@artifex.com>
9d168db605fba44e6238d53d8c29f5997760d2ca

> device subclassing of patterns, use the correct memory structure
> Spotted by Chris while looking at a customer problem, the customer's
> code allocs a new pattern accumulator using the device's memory, but it
> should really be using the current VM state of the interpreter.
> The reason it didn't was because that information wasn't available at
> the point where the allocation is made. This commit adds the current
> interpreter VM mode to the 'param' structure, which enables us to pass
> it to th device, and have the device use it properly.
> base/gxdevsop.h
> psi/zpcolor.c

2018-07-09 14:16:31 +0100
Ken Sharp <ken.sharp@artifex.com>
4f02acd487721451256d3348760cd3c9333e7635

> pdfwrite - allow PageLabels to be (optionally) transmitted as pdfmarks
> Bug #696568 "Treatment of page labels"
> Patch supplied by Leon Bottou, the creator and maintainer of the djvu
> device for Ghostscript, very slightly modified.
> The djvu device wants the PageLabels from existing PDF files sent to
> the device as pdfmarks, exactly as they would be from PostScript. The
> problem with this from the pdfwrite point of view is that this would
> result in us unpicking the number tree to create pdfmark operations, and
> then at the pdfwrite end rebuilding a number tree to emit. Not rebuilding
> the tree would result in larger output.
> This patch checks that the device implements pdfmark, and if it does
> checks whether WantsPageLabels is set in the device. If it is then we
> assume its pdfwrite (or a similar device prepared to accept the number
> tree). If it is not set then we walk the tree and create a new pdfmark
> for each page in the tree range.
> I'm unable to test this properly, because it relies on a device which
> does implement pdfmark, but doesn't want PageLabels. Rudimentary
> testing seemed to work as expected, its possible that more complex
> examples might require some more work.
> Resource/Init/pdf_main.ps

2018-07-06 09:58:06 +0100
Ken Sharp <ken.sharp@artifex.com>
42cee04f173ccacb6aafc8243dd6c2ef12cdde54

> Forgot to include the changed doc file in last commit
> doc/Use.htm

2018-07-06 09:53:45 +0100
Ken Sharp <ken.sharp@artifex.com>
cc826ca86485321cbc5fc111f7dad7ee39e69a17

> Update PageList processing in the FirstPage/LastPage device
> The intention of the PageList was that pages would be specified in
> ascending order, but the documentation didn't actually say that
> explicitly, so update the documentation to make it absolutely clear.
> In addition, by specifying a lower page number at the end, it was
> possible to cause a buffer overrun, so prevent that here and flag an
> error to the user so they know.
> base/gdevflp.c

2018-07-05 18:04:28 +0100
Robin Watts <robin.watts@artifex.com>
18e4b59efeca56ec2ca716559a7b9e0639561428

> Bug 699379: Fix infinite loop with filenames starting with #.
> The argument handling routines treat lines starting with #
> as being comments. Unfortunately, the logic for this was failing
> to recognise EOF as stopping the search for the end of a line.
> Doubly unfortunatately, it was extending this courtesy, intended
> for lines within @files to command line arguments too. We take
> steps to avoid that too.
> base/gsargs.c

2018-07-05 11:22:41 +0100
Robin Watts <robin.watts@artifex.com>
f390123f8e34ec149fe1a3366ebb872368a57d7f

> Bug 698928: Rework arg_next.
> When I worked on arg_next before, I think I had the wrong idea of
> what it was doing.
> The idea of arg_next (I thought) was that we'd call it, and get back
> a pointer to a decoded version of the next argument. Sadly, this
> wasn't true - it would leave us with an *encoded* version of the
> argument. Now, for most things this didn't matter, for for encodings
> like UTF16LE, it certainly did.
> So, largely revert the previous misguided commit to this code, and
> update arg_next so that it really does return a "decoded" (i.e. always
> utf-8 encoded) buffer.
> This fixes Bug 698928 where I had an underflow read in a buffer.
> base/gsargs.c
> base/gsargs.h

2018-07-05 16:38:01 +0100
Ken Sharp <ken.sharp@artifex.com>
62e67ecc475d3648f32d7d8c4459bbabd740ea2b

> Fix a device subclassing problem with colour mapping procedures
> Bug #699520 "Seg fault with customer device utilising device subclassing"
> When we retrieve colour mapping methods, we need to use the first
> subclassing device in the chain which does not have a 'default' for
> the colour mapping methods. This is so that the monochrome palette
> device in PCL works properly.
> In contrast, if none of the subclassing devices overrides the colour
> mapping then we want to use the first non-subclassing device's
> methods and, importantly, that device as well.
> base/gxdevcli.h

2018-07-03 13:44:28 +0100
Ken Sharp <ken.sharp@artifex.com>
2f8082aa9777a7274c463c6375c2f7d01c299251

> Increase limit on UniqueIDs for fonts
> Bug #699513 "CFF font UniqueID greater then 2^24 - 1 causes error"
> The PDF file contains a font with a UniqueID of 0x7fffff which exceeds
> the PostScript definition of a font UniqueID (0 -> 2^24 - 1).
> Experimentation shows that no PostScript interpreter that I have access
> to (other than GS) implements this limit. However, to keep the change
> conservative, I'm chosen to raise the limit to 2^32-1 to match the CFF
> specification, rather than eliminate it altogether.
> psi/idparam.c

2018-07-03 08:55:43 +0100
Chris Liddell <chris.liddell@artifex.com>
3e44dd7a9f112ea5334a4e189ec64f7a16139597

> Remove some obsolete sections from the docs.
> DOS and OS/2 install sections in install.htm
> doc/Install.htm

2018-06-30 16:10:48 +0100
Ken Sharp <ken.sharp@artifex.com>
dc20112ef13ebdfc6e1ad20ac9ef5462e9145682

> Fix a compiler warning
> devices/vector/gdevpdfp.c

2018-06-30 14:29:43 +0100
Ken Sharp <ken.sharp@artifex.com>
aba212c73d6f10fe891786a938bb461636563dba

> pdfwrite - when changing ProcessColorModel, don't just change the name
> Bug 699490 "Broken PDF/X-3 generated"
> The reason that an empty file was generated was due to a mismatch
> between the underlying device process color model and the ICC profile
> attached to the device. The profile was a CMYK profile, while the
> device was set to have 3 components.
> This is due to the fact that setting the ProcessColorModel separately
> from the ColorConversionStrategy was not actually changing the model,
> it just changed the name.
> This should, of course, have generated an error and an earlier commit
> had already addressed that. In this commit, we call the routine which
> actually switches the colour model, and we also count down the ICC
> structure attached to the device, and set it to 0. This forces a reload
> of the ICC profile. That isn't needed for this particular bug but it
> is needed when OutputICCProfile is not set, because we will otherwise
> try to use the profile for the prior colour model, which will be
> incorrect and leaed to errors.
> devices/vector/gdevpdfp.c

2018-06-29 14:13:39 -0700
Michael Vrhel <michael.vrhel@artifex.com>
8d415abe6f1e0e3a7e895511e20d99eebad48ada

> Fix rendering issue on tiffscaled devices
> The tiffscaled contone devices have to be able to change their color model
> to allow a more flexible use of the post render ICC profile with the output
> intent. Prior to this commit, certain profile combinations would result in
> mis-rendered results.
> With this fix, if we are wanting to render to a CMYK intermediate
> output intent but we want the output to be in sRGB then we need to use
> -sDEVICE=tiffscaled24 -dUsePDFX3Profile -sOutputICCProfile=default_cmyk.icc
> -sPostRenderProfile=srgb.icc . This should then render to a temporary
> buffer the is in the OutputIntent color space and then be converted to
> sRGB. This should look like the result we get when we go out to the
> tiffscaled32 device. This is in contrast to the command line
> sDEVICE=tiffscaled24 -dUsePDFX3Profile -sPostRenderProfile=srgb.icc which would
> end up using the output intent as a proofing profile. The results may be similar
> but not exact as overprint and spot colors would not appear correctly due to the
> additive color model during rendering.
> base/gsicc.c
> base/gsicc.h
> base/lib.mak
> devices/devs.mak
> devices/gdevtsep.c

2018-06-28 16:44:41 +0100
Ken Sharp <ken.sharp@artifex.com>
da3810ce626a1c5dca856a7bac757bf254761f69

> pdfwrite - create GC desscriptors for JPEG Passthrough stream
> Bug #699427 " Shrinking PDF is causing SIGSEGV"
> Its not absolutely clear that this is the same problem, but I'm
> reasonably confident. When passing JPEG data through untouched, we
> copied the stream pointer for the uncompressed data into the device
> structure (because the image enumerator isn't available at that time)
> but if the stream should be relocated after the copy is taken, then the
> old stream might not be valid any more.
> This commit adds a GC descriptor for the copied stream pointer to the
> PDF device structure. For me this solves the problem, but the nature
> of these kinds of problems means that *any* change which affects memory
> layout will affect the execution, so I'm not 100% certain this is the
> problem.
> devices/vector/gdevpdf.c
> devices/vector/gdevpdfx.h

2018-06-26 14:52:22 -0700
Michael Vrhel <michael.vrhel@artifex.com>
250b5e83e923bed9b6d48bf3965f3b38af52286d

> Fix errors introduced in previous commit
> The commit f2cf68297e3d63cb927db3c98d317f7ee68e7898
> resulted in errors with the separation type devices.
> With these devices, we can simply check if the color
> model matches the ICC profile since these devices
> change their number of components. Will likely need
> to do some testing with these device and different
> profiles to see what breaks when and make sure we
> exit gracefully.
> base/gsicc_manage.c
> devices/devs.mak
> devices/gdevcmykog.c
> devices/gdevgprf.c
> devices/gdevpsd.c

2018-06-27 13:22:41 +0100
Chris Liddell <chris.liddell@artifex.com>
e4a7fc24c051241e4dbd14760a218290769d78a6

> Fix a typo in a link
> doc/API.htm
> doc/C-style.htm
> doc/Commprod.htm
> doc/DLL.htm
> doc/Deprecated.htm
> doc/Develop.htm
> doc/Devices.htm
> doc/Drivers.htm
> doc/Fonts.htm
> doc/History9.htm
> doc/Install.htm
> doc/Language.htm
> doc/Lib.htm
> doc/Make.htm
> doc/News.htm
> doc/Ps-style.htm
> doc/Ps2epsi.htm
> doc/Psfiles.htm
> doc/Readme.htm
> doc/Release.htm
> doc/SavedPages.htm
> doc/Source.htm
> doc/Unix-lpr.htm
> doc/Use.htm
> doc/VectorDevices.htm
> doc/WhatIsGS.htm
> doc/sample_downscale_device.htm
> doc/subclass.htm
> doc/thirdparty.htm

2018-06-25 09:44:34 +0100
Chris Liddell <chris.liddell@artifex.com>
6a4202691c4317a698fa23c5309ad8974fe2b003

> Bug 699454: 'improve' pdfwrite guesstimate of glyph bbox
> When estimating the bounding box of a glyph, we were basically only using the
> FontBBox - which is often bogus (as it is in this case).
> We'll now, additionally, use the advance width of the glyph in that estimate.
> This could possibly result in glyphs being included whose marking operations
> are outside the current clip, but whose advance width intersects with the
> current clip. But that would be preferable to (as was happening) a glyph inside
> the clip being dropped.
> (Using the "real" glyph bbox would require executing the complete charstring,
> which, obviously, has performance implications)
> devices/vector/gdevpdte.c

2018-06-22 11:48:58 -0700
Michael Vrhel <michael.vrhel@artifex.com>
9ae241f271ae2eafc69ca44a0b8b70af17705c0e

> Fix crash introduced by commit to make lcms thread-safe
> Using a proof profile or even using -dUsePDFX3Profile with
> a device color model that was different than the output
> intent caused a crash after commit
> 9ff6b34e461fcbd4ef27fbb6c5c8a15071fe1370
> Problem was that the intermediate device link was not
> getting created.
> base/gsicc_lcms2mt.c

2018-06-22 10:35:48 -0700
Michael Vrhel <michael.vrhel@artifex.com>
f2cf68297e3d63cb927db3c98d317f7ee68e7898

> Bug 699381 Add error checking for device icc profiles
> Make sure that the various types of profiles that can be set work with
> the device color model and with each other. Only allow the use of
> the post render ICC profile when the device supports it.
> base/gdevdflt.c
> base/gsdparam.c
> base/gsicc_manage.c
> base/gxdevsop.h
> base/lib.mak
> devices/devs.mak
> devices/gdevtsep.c

2018-06-21 11:56:17 -0700
Michael Vrhel <michael.vrhel@artifex.com>
6b981f05c5dafe5d03e8827cb3b5c1cd879c0644

> Fix crash when using PostRenderProfile
> Crash was introduced by commit to make lcms thread-safe
> 9ff6b34e461fcbd4ef27fbb6c5c8a15071fe1370
> base/gsicc_cache.c

2018-06-19 11:28:31 +0100
Chris Liddell <chris.liddell@artifex.com>
da399f89d08f66d8608e83ecf2cd5c33ec45b866

> Don't overwrite filename in the event of an error.
> When we 'wrap' a file to allow thread safe file access for multithreaded clist
> operation, we replace the original file name with a special 'encoded' file
> name - we shouldn't do the replacement if the underlying file fails to open
> since it means the error message shows the encoded file name, rather than the
> name of the 'real' file.
> base/gxclfile.c

2018-06-14 12:47:21 -0700
Ray Johnston <ray.johnston@artifex.com>
f92376925f99cd418ce94ab738935eb88013175f

> Add aarch64:Linux case to tiff config.guess
> Needed for configure on 64-bit Linux on ARM (seen with SUSE 64-bit linux
> on the Raspberry Pi).
> tiff/config/config.guess

2018-06-14 12:42:49 -0700
Ray Johnston <ray.johnston@artifex.com>
255fe6272797351f83613e6ca079a903bdabb136

> Fix typo in lib.mak. Missing sfilter2 in psfilters.dev
> Both entries were $(GLOBJ)sfilter1.$(OBJ) which resulted in s_A85E_template
> undefined in the link.
> base/lib.mak

2018-06-14 13:57:30 +0100
Ken Sharp <ken.sharp@artifex.com>
fbf2eefa62b8dd4eb1b96aa77b7d4cf6719af5fe

> fix lib.mak for Windows builds
> Commit ca18b9663b10798a2bd800173df3bfbca4a87650 had an extra $(GLOBJ)
> macro in the build line for psfilters.dev. On Linux this doesn't seem
> to be a problem, but nmake (Windows build in Visual Studio) throws
> an error.
> Just remove the extraneous macro.
> base/lib.mak

2018-06-13 16:27:32 +0100
Chris Liddell <chris.liddell@artifex.com>
ca18b9663b10798a2bd800173df3bfbca4a87650

> Move the PS Level 1 filters into 'base/'
> Oddly, Level 2 filters were already in 'base/', but the Level 1 filters were
> still (partially) in 'psi/' (but at least one was partially in base/).
> This not only moves the code, but puts both Level 1 and 2 filters into a
> 'feature' .dev (called psfilters.dev) - on the basis we don't really support
> building as a Level 1 only interpreter any more.
> It is still up to the interpreter makefile(s) to include the dependency on
> psfilter.dev to get these built in.
> This is tidier than before, but primarily done so the SubFileDecode filter
> is available for use by the in-development C based PDF interpreter.
> base/lib.mak
> base/sfilter1.c
> psi/int.mak

2018-06-12 10:08:09 +0100
Ken Sharp <ken.sharp@artifex.com>
e0b4f52ee1904ff3f1cf72d86163321b2f9d6357

> Fix PageList when the last page in the file is not included in the list
> It was possible to run off the end of the array of pages if the last
> page was not included in the list of pages to be printed.
> Also, the trailing '-' syntax (from page 'n' to the end of file) was
> off by one printing the initial page.
> base/gdevflp.c
> base/gdevflp.h

2018-06-11 11:31:05 +0100
Ken Sharp <ken.sharp@artifex.com>
bc0b0ff9bd8dbdd91a142b46a0e5f5168c13306d

> Better fix for bug #699404
> Bug #699404 "Failure with psdcmyk -dGraphicsAlphaBits=4 -dFirstPage=1 -dLastPage=1"
> The commit 3347a19f6fd89fc1b7d9644ff6c4703897501f7e did fix this problem
> but it left a more serious underlying problem. The devices in the chain
> weren't being updated to note that the standard subclassing devcies had
> been installed.
> This could lead to them being installed multiple times, and also to
> taking the wrong code path and failing to update the device methods
> when required.
> This commit unwinds the previous one in gdevprn.c and applies a better
> fix in gdevkrnlsclass.c
> base/gdevkrnlsclass.c
> base/gdevprn.c

2018-06-08 14:05:24 +0100
Ken Sharp <ken.sharp@artifex.com>
a219c745f5fd3bcf38da40f64c5b7cd053721a16

> Documentation update - PageList
> Update use.htm to make it clear that using PageList will override any
> values for FirstPage and LastPage.
> doc/Use.htm

2018-06-07 16:16:08 -0600
Henry Stiles <henry.stiles@artifex.com>
493066fceed538d3c499221aea8e085fba86c827

> Add PCL symbol sets: PC-865 Norway and PC-860 Portugal.
> pcl/pl/plsymbol.c

2018-06-06 17:25:00 +0100
Ken Sharp <ken.sharp@artifex.com>
3347a19f6fd89fc1b7d9644ff6c4703897501f7e

> Move installation of standard subclassing devices
> Bug #699404 "Failure with psdcmyk -dGraphicsAlphaBits=4 -dFirstPage=1 -dLastPage=1"
> The installation of the devices in gdev_prn_open() was slightly too
> early, the procs can still (quite reasonably because this is part of
> the device installation) be altered by gdev_prn_allocate_memory().
> If we had already subclassed the device, then the procs of the
> subclassing device (ie firstPage/LastPage) would be altered rather than
> the real target device's procs. This led to the wrong graphics library
> call, which produced an error.
> Moving the subclassing later in the installation solves the problem.
> base/gdevprn.c

2018-06-05 10:16:26 -0600
Henry Stiles <henry.stiles@artifex.com>
bfbd2a02cd39c799d5d5f2d9850fb0fd06e57b7a

> Fix #699390 - text position wrong.
> The PCL current position (CAP) can be in two states: floating or
> fixed. Floating tracks the origin with margin and orientation changes
> fixed does not. The CAP is floating until we have printable data or a
> command that affects the cursor position is received. We were
> mistakenly resetting the the CAP from fixed to float for orientation
> changes resulting in incorrect text position.
> Norbert Janssen provided the analysis and code change for this fix.
> pcl/pcl/pcpage.c

2018-06-01 17:40:09 +0100
Ken Sharp <ken.sharp@artifex.com>
e997c6836d243ab37fe3a5f0d57974af95eb5eac

> pdfwrite - drop UTF16-BE DOCINFO strings when creating PDF/A-1
> Bug #699392 " XMP metadata missing when trying to create PDF/A "
> Its not obvious, but it appears to be impossible to embed UTF-16BE
> strings in XMP metadata and have them be validated against the same
> string in the Info dictionary, because of the specified method for
> comparing such strings.
> PDF/A-2 states that the document information dictionary should be
> ignored, in contrast to the PDF/A-1 specification which says the
> XMP and Info dictionary information must be consistent. So this
> problem can't arise there.
> This commit detects the use of any UTF-16BE string in a DOCINFO
> pdfmark and use the usual PDFACompatibilityPolicy to decide whether to
> abort PDF/A-1 production, drop the string or raise an error.
> devices/vector/gdevpdfm.c

2018-05-30 15:59:32 +0100
Ken Sharp <ken.sharp@artifex.com>
71de6d0f9c2a48d6e4a69287b2123bf9efd6df88

> txtwrite - Increment character index in text enumerator
> Bug #699391 "segfault in txtwrite_process_plain_text()"
> We need to increment the text enumerator character index no matter what
> kind of operation this is, we had omitted it in the
> TEXT_FROM_SINGLE_GLYPH case.
> devices/vector/gdevtxtw.c

2018-05-28 17:39:55 +0100
Robin Watts <robin.watts@artifex.com>
7a91a08d9c78b5e37b0d434ffaafa30aa1d680ad

> Bug 699382: Fix UTF-8 encoding screwup.
> Also fix utf8_to_wchar making wchar buffers longer than required.
> base/gp_wutf8.c
> base/gsargs.c

2018-05-24 16:37:15 +0100
Chris Liddell <chris.liddell@artifex.com>
fa7a350708d393bad28dffff22da4f96ba037001

> Ghostscript documentation pages revised to new look and feel
> doc/API.htm
> doc/AUTHORS
> doc/C-style.htm
> doc/Changes.htm
> doc/Commprod.htm
> doc/DLL.htm
> doc/Deprecated.htm
> doc/Details.htm
> doc/Details8.htm
> doc/Details9.htm
> doc/Develop.htm
> doc/Devices.htm
> doc/Drivers.htm
> doc/Fonts.htm
> doc/Helpers.htm
> doc/Hershey.htm
> doc/History1.htm
> doc/History2.htm
> doc/History3.htm
> doc/History4.htm
> doc/History5.htm
> doc/History6.htm
> doc/History7.htm
> doc/History8.htm
> doc/History9.htm
> doc/Install.htm
> doc/Issues.htm
> doc/Language.htm
> doc/Lib.htm
> doc/Make.htm
> doc/News.htm
> doc/Projects.htm
> doc/Ps-style.htm
> doc/Ps2epsi.htm
> doc/Psfiles.htm
> doc/Readme.htm
> doc/Release.htm
> doc/SavedPages.htm
> doc/Source.htm
> doc/Unix-lpr.htm
> doc/Use.htm
> doc/VectorDevices.htm
> doc/WhatIsGS.htm
> doc/gs-style.css
> doc/gs.css
> doc/images/.DS_Store
> doc/images/Artifex_logo.png
> doc/images/favicon.png
> doc/images/ghostscript_logo.png
> doc/images/hamburger-light.png
> doc/images/x-light.png
> doc/index.js
> doc/sample_downscale_device.htm
> doc/style.css
> doc/subclass.htm
> doc/thirdparty.htm

2018-05-24 09:21:17 +0100
Ken Sharp <ken.sharp@artifex.com>
1eab394d3715ac37eca4ee3d4b139520166f37f4

> Improve FirstPage/LastPage image data handling
> commit e92f7cbadec35ced4e38d2be9bf13fe4f362aa59 had the right idea but
> erroneous implementation. We can't simply cast the image enumerator,
> because we didn't allocate the enumerator that way.
> Instead, add the expected height and tracking variable to the individual
> enumerator.
> Implement for object filtering device as well.
> base/gdevflp.c
> base/gdevoflt.c

2018-05-23 15:57:16 +0100
Ken Sharp <ken.sharp@artifex.com>
59dce27871a39a9f161aaaf0e852dbd05ba009fe

> PDF interpreter - fix illegal CIDSystemInfo dictionaries
> Bug #699294 " Ghostscript giving errors for attached pdfs and generating blank tiffs"
> The supplied example file has several CIDFonts embedded which have
> illegal CIDSystemInfo dictionaries; they are missing the required
> Registry and Ordering entries.
> A long time ago we discarded the CIDSystemInfo from the CIDFont and
> created a dummy one, which is why the reporter thinks this 'used to
> work'. It didn't. Discarding the information caused problems with the
> pdfwrite output.
> In this case we simply manufacture the missing data. Its wrong, but it
> allows the file to proceed to completion. Naturally we emit a warning
> so that users know their file is garbage.
> Resource/Init/pdf_font.ps

2018-05-23 09:14:07 +0100
Ken Sharp <ken.sharp@artifex.com>
e92f7cbadec35ced4e38d2be9bf13fe4f362aa59

> First/Last page - Fix image data handling with proc data source
> Bug #699215 "Subclassing device leads to infinite(?) loop"
> When processing images, its acceptable for the subclassed device to
> return 0 (need more data) in response to image_plane_data, if the
> source is a file, because the file will reach EOF and the code will
> properly terminate.
> For procedural (or string) data sources this isn't true. The code needs
> to keep track of the number of rows of image data received, and return
> 1 (completed) when we have received enough data.
> Fixed the object filtering device at the same time.
> base/gdevflp.c
> base/gdevoflt.c

2018-05-22 14:47:54 +0100
Ken Sharp <ken.sharp@artifex.com>
b61071c9411c3f6aa0dd594da2c5a20ff4ecd914

> Replace EOI marker in JPEG passthrough
> Bug #699216 " JPEG passthrough appears to truncate JPEGs in some cases"
> The IJG JPEG implementation consumes the EOI marker before the JPEG
> passthrough code gets to see it (in general). Most PDF consumers don't
> care, but some seem to, so when we terminate the DCT decompression
> send the EOI marker to the passthrough code.
> base/sdctd.c

2018-05-22 14:04:31 +0100
Ken Sharp <ken.sharp@artifex.com>
4a288cb8678517c578b336b3d26e5c4115906624

> Fix conversion from PDF time to XMP time for pdfwrite
> Bug #699182 " Invalid XMP metadata and possibly invalid memory access for dates without timezone in pdfmark"
> Two different problems; in the first case a '>' should be '>=' so that
> we properly identify an empty string.
> Then when converting the string, there was a different off-by-one error
> in the buffer index. Also corrected a comment while passing.
> devices/vector/gdevpdfe.c

2018-05-22 10:51:46 +0100
Ken Sharp <ken.sharp@artifex.com>
16ad4cc70918da40f62a919e11187dfb72f4ff63

> Prevent use of CID 0 in a PDF/A output file.
> Bug #699375 "PDF/A 1b / 2b Validation fails after conversion with Ghostscript on some files"
> The input file(s) use CID 0 (which is defined as the /.notdef glyph)
> which is illegal in PDF/A files.
> 'Fixing' this would require us to alter the CID, change the CMap and
> the ToUnicode CMap, and runs the obvious risk of the CID we use as a
> replacement being used later in the document. We could avoid this by
> scanning for 'holes' in the CMap, but even that potentially leaves us
> with a problem if there are no empty entries in the CMap.
> Since we can't guarantee fixing the problem, a partial fix would be a
> great deal of coding, would almost certainly introduce a bug tail and
> still wouldn't guarantee a compliant result, don't try. Instead if we
> encounter this condition abort PDF/A output, or throw an error if the
> PDFACompatibilityPolicy is set that way.
> devices/vector/gdevpdtc.c

2018-05-17 14:30:40 +0100
Chris Liddell <chris.liddell@artifex.com>
48e4565e967eae091b97a9037e77016d8d99f3ce

> Bug 699329: add display device to default Unix build.
> Previously it was only included in the .so build (it doesn't really make sense
> in a monolithic exe build). But since we now have a "supported" static library
> build, it makes sense to include it.
> configure.ac

2018-05-17 07:35:02 +0100
Chris Liddell <chris.liddell@artifex.com>
891ea7d2813edaa3c7c874a4053afdda128e8a10

> Fix for small glyph distortion
> Glyphs with very few pixels (i.e. lower case "i" in 9pt text rendered at 72dpi)
> we being distorted due to the specific rules applied by Freetype's dropout
> compensation. This isn't a full solution but resolves the change in behaviour
> between 2.7.x and 2.9.x (the change was due to different rounding being
> applied).
> This fix is from upstream:
> http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=f1458d2e44d8
> So should be in future Freetype releases, and not need re-applied here.
> freetype/src/base/ftobjs.c

2018-04-03 15:49:48 +0100
Chris Liddell <chris.liddell@artifex.com>
9cb169b6b260f650aac2c3c7ed7af0f345ee0707

> Work around a behaviour change in freetype > 2.8
> Freetype will throw an error when we try to retrieve the glyph if the x/y
> advance values are too big to fit in a 16.16 fixed point value.
> Since we have no need of those values, set them to zero, and avoid the error.
> Bring freetype up to 2.9.1
> Plus the gs makefile changes to support the new version.
> Reapply "Work around a change in the zlib API for 1.2.11"
> for Freetype
> commit: 08482c582115a1396d0fd9186011008f889a61c5
> base/fapi_ft.c
> base/freetype.mak
> freetype/CMakeLists.txt
> freetype/ChangeLog
> freetype/ChangeLog.20
> freetype/ChangeLog.21
> freetype/ChangeLog.22
> freetype/ChangeLog.23
> freetype/ChangeLog.24
> freetype/ChangeLog.25
> freetype/ChangeLog.26
> freetype/ChangeLog.27
> freetype/ChangeLog.28
> freetype/Jamfile
> freetype/Jamrules
> freetype/Makefile
> freetype/README
> freetype/README.git
> freetype/autogen.sh
> freetype/builds/amiga/README
> freetype/builds/amiga/include/config/ftconfig.h
> freetype/builds/amiga/include/config/ftmodule.h
> freetype/builds/amiga/makefile
> freetype/builds/amiga/makefile.os4
> freetype/builds/amiga/smakefile
> freetype/builds/amiga/src/base/ftdebug.c
> freetype/builds/amiga/src/base/ftsystem.c
> freetype/builds/ansi/ansi-def.mk
> freetype/builds/ansi/ansi.mk
> freetype/builds/beos/beos-def.mk
> freetype/builds/beos/beos.mk
> freetype/builds/beos/detect.mk
> freetype/builds/cmake/FindHarfBuzz.cmake
> freetype/builds/cmake/iOS.cmake
> freetype/builds/cmake/testbuild.sh
> freetype/builds/compiler/ansi-cc.mk
> freetype/builds/compiler/bcc-dev.mk
> freetype/builds/compiler/bcc.mk
> freetype/builds/compiler/emx.mk
> freetype/builds/compiler/gcc-dev.mk
> freetype/builds/compiler/gcc.mk
> freetype/builds/compiler/intelc.mk
> freetype/builds/compiler/unix-lcc.mk
> freetype/builds/compiler/visualage.mk
> freetype/builds/compiler/visualc.mk
> freetype/builds/compiler/watcom.mk
> freetype/builds/compiler/win-lcc.mk
> freetype/builds/detect.mk
> freetype/builds/dos/detect.mk
> freetype/builds/dos/dos-def.mk
> freetype/builds/dos/dos-emx.mk
> freetype/builds/dos/dos-gcc.mk
> freetype/builds/dos/dos-wat.mk
> freetype/builds/exports.mk
> freetype/builds/freetype.mk
> freetype/builds/link_dos.mk
> freetype/builds/link_std.mk
> freetype/builds/mac/FreeType.m68k_cfm.make.txt
> freetype/builds/mac/FreeType.m68k_far.make.txt
> freetype/builds/mac/FreeType.ppc_carbon.make.txt
> freetype/builds/mac/FreeType.ppc_classic.make.txt
> freetype/builds/mac/ftmac.c
> freetype/builds/modules.mk
> freetype/builds/newline
> freetype/builds/os2/detect.mk
> freetype/builds/os2/os2-def.mk
> freetype/builds/os2/os2-dev.mk
> freetype/builds/os2/os2-gcc.mk
> freetype/builds/symbian/bld.inf
> freetype/builds/symbian/freetype.mmp
> freetype/builds/toplevel.mk
> freetype/builds/unix/aclocal.m4
> freetype/builds/unix/config.guess
> freetype/builds/unix/config.sub
> freetype/builds/unix/configure
> freetype/builds/unix/configure.ac
> freetype/builds/unix/configure.raw
> freetype/builds/unix/detect.mk
> freetype/builds/unix/freetype-config.in
> freetype/builds/unix/freetype2.in
> freetype/builds/unix/freetype2.m4
> freetype/builds/unix/ft-munmap.m4
> freetype/builds/unix/ftconfig.in
> freetype/builds/unix/ftsystem.c
> freetype/builds/unix/install.mk
> freetype/builds/unix/pkg.m4
> freetype/builds/unix/unix-cc.in
> freetype/builds/unix/unix-def.in
> freetype/builds/unix/unix-dev.mk
> freetype/builds/unix/unix-lcc.mk
> freetype/builds/unix/unix.mk
> freetype/builds/unix/unixddef.mk
> freetype/builds/vms/ftconfig.h
> freetype/builds/vms/ftsystem.c
> freetype/builds/wince/ftdebug.c
> freetype/builds/wince/vc2005-ce/freetype.vcproj
> freetype/builds/wince/vc2005-ce/index.html
> freetype/builds/wince/vc2008-ce/freetype.vcproj
> freetype/builds/wince/vc2008-ce/index.html
> freetype/builds/windows/detect.mk
> freetype/builds/windows/ftdebug.c
> freetype/builds/windows/vc2005/freetype.vcproj
> freetype/builds/windows/vc2005/index.html
> freetype/builds/windows/vc2008/freetype.vcproj
> freetype/builds/windows/vc2008/index.html
> freetype/builds/windows/vc2010/freetype.sln
> freetype/builds/windows/vc2010/freetype.vcxproj
> freetype/builds/windows/vc2010/freetype.vcxproj.filters
> freetype/builds/windows/vc2010/index.html
> freetype/builds/windows/visualc/freetype.dsp
> freetype/builds/windows/visualc/freetype.vcproj
> freetype/builds/windows/visualc/index.html
> freetype/builds/windows/visualce/freetype.dsp
> freetype/builds/windows/visualce/freetype.vcproj
> freetype/builds/windows/visualce/index.html
> freetype/builds/windows/w32-bcc.mk
> freetype/builds/windows/w32-bccd.mk
> freetype/builds/windows/w32-dev.mk
> freetype/builds/windows/w32-gcc.mk
> freetype/builds/windows/w32-icc.mk
> freetype/builds/windows/w32-intl.mk
> freetype/builds/windows/w32-lcc.mk
> freetype/builds/windows/w32-mingw32.mk
> freetype/builds/windows/w32-vcc.mk
> freetype/builds/windows/w32-wat.mk
> freetype/builds/windows/win32-def.mk
> freetype/configure
> freetype/devel/ft2build.h
> freetype/devel/ftoption.h
> freetype/docs/CHANGES
> freetype/docs/CUSTOMIZE
> freetype/docs/DEBUG
> freetype/docs/FTL.TXT
> freetype/docs/INSTALL
> freetype/docs/INSTALL.ANY
> freetype/docs/INSTALL.CROSS
> freetype/docs/INSTALL.GNU
> freetype/docs/INSTALL.MAC
> freetype/docs/INSTALL.UNIX
> freetype/docs/INSTALL.VMS
> freetype/docs/MAKEPP
> freetype/docs/TODO
> freetype/docs/VERSIONS.TXT
> freetype/docs/formats.txt
> freetype/docs/freetype-config.1
> freetype/docs/raster.txt
> freetype/docs/reference/ft2-auto_hinter.html
> freetype/docs/reference/ft2-base_interface.html
> freetype/docs/reference/ft2-basic_types.html
> freetype/docs/reference/ft2-bdf_fonts.html
> freetype/docs/reference/ft2-bitmap_handling.html
> freetype/docs/reference/ft2-bzip2.html
> freetype/docs/reference/ft2-cache_subsystem.html
> freetype/docs/reference/ft2-cff_driver.html
> freetype/docs/reference/ft2-cid_fonts.html
> freetype/docs/reference/ft2-computations.html
> freetype/docs/reference/ft2-error_code_values.html
> freetype/docs/reference/ft2-error_enumerations.html
> freetype/docs/reference/ft2-font_formats.html
> freetype/docs/reference/ft2-gasp_table.html
> freetype/docs/reference/ft2-glyph_management.html
> freetype/docs/reference/ft2-glyph_stroker.html
> freetype/docs/reference/ft2-glyph_variants.html
> freetype/docs/reference/ft2-gx_validation.html
> freetype/docs/reference/ft2-gzip.html
> freetype/docs/reference/ft2-header_file_macros.html
> freetype/docs/reference/ft2-header_inclusion.html
> freetype/docs/reference/ft2-incremental.html
> freetype/docs/reference/ft2-index.html
> freetype/docs/reference/ft2-lcd_filtering.html
> freetype/docs/reference/ft2-list_processing.html
> freetype/docs/reference/ft2-lzw.html
> freetype/docs/reference/ft2-mac_specific.html
> freetype/docs/reference/ft2-module_management.html
> freetype/docs/reference/ft2-multiple_masters.html
> freetype/docs/reference/ft2-ot_validation.html
> freetype/docs/reference/ft2-outline_processing.html
> freetype/docs/reference/ft2-parameter_tags.html
> freetype/docs/reference/ft2-pcf_driver.html
> freetype/docs/reference/ft2-pfr_fonts.html
> freetype/docs/reference/ft2-properties.html
> freetype/docs/reference/ft2-quick_advance.html
> freetype/docs/reference/ft2-raster.html
> freetype/docs/reference/ft2-sfnt_names.html
> freetype/docs/reference/ft2-sizes_management.html
> freetype/docs/reference/ft2-system_interface.html
> freetype/docs/reference/ft2-t1_cid_driver.html
> freetype/docs/reference/ft2-toc.html
> freetype/docs/reference/ft2-truetype_engine.html
> freetype/docs/reference/ft2-truetype_tables.html
> freetype/docs/reference/ft2-tt_driver.html
> freetype/docs/reference/ft2-type1_tables.html
> freetype/docs/reference/ft2-user_allocation.html
> freetype/docs/reference/ft2-version.html
> freetype/docs/reference/ft2-winfnt_fonts.html
> freetype/docs/release
> freetype/include/freetype/config/ftconfig.h
> freetype/include/freetype/config/ftheader.h
> freetype/include/freetype/config/ftoption.h
> freetype/include/freetype/config/ftstdlib.h
> freetype/include/freetype/freetype.h
> freetype/include/freetype/ftadvanc.h
> freetype/include/freetype/ftautoh.h
> freetype/include/freetype/ftbbox.h
> freetype/include/freetype/ftbdf.h
> freetype/include/freetype/ftbitmap.h
> freetype/include/freetype/ftbzip2.h
> freetype/include/freetype/ftcache.h
> freetype/include/freetype/ftcffdrv.h
> freetype/include/freetype/ftchapters.h
> freetype/include/freetype/ftcid.h
> freetype/include/freetype/ftdriver.h
> freetype/include/freetype/fterrdef.h
> freetype/include/freetype/fterrors.h
> freetype/include/freetype/ftfntfmt.h
> freetype/include/freetype/ftgasp.h
> freetype/include/freetype/ftglyph.h
> freetype/include/freetype/ftgxval.h
> freetype/include/freetype/ftgzip.h
> freetype/include/freetype/ftimage.h
> freetype/include/freetype/ftincrem.h
> freetype/include/freetype/ftlcdfil.h
> freetype/include/freetype/ftlist.h
> freetype/include/freetype/ftlzw.h
> freetype/include/freetype/ftmac.h
> freetype/include/freetype/ftmm.h
> freetype/include/freetype/ftmodapi.h
> freetype/include/freetype/ftmoderr.h
> freetype/include/freetype/ftotval.h
> freetype/include/freetype/ftoutln.h
> freetype/include/freetype/ftparams.h
> freetype/include/freetype/ftpfr.h
> freetype/include/freetype/ftrender.h
> freetype/include/freetype/ftsizes.h
> freetype/include/freetype/ftsnames.h
> freetype/include/freetype/ftstroke.h
> freetype/include/freetype/ftsynth.h
> freetype/include/freetype/ftsystem.h
> freetype/include/freetype/fttrigon.h
> freetype/include/freetype/ftttdrv.h
> freetype/include/freetype/fttypes.h
> freetype/include/freetype/ftwinfnt.h
> freetype/include/freetype/internal/autohint.h
> freetype/include/freetype/internal/cffotypes.h
> freetype/include/freetype/internal/cfftypes.h
> freetype/include/freetype/internal/ftcalc.h
> freetype/include/freetype/internal/ftdebug.h
> freetype/include/freetype/internal/ftdrv.h
> freetype/include/freetype/internal/ftgloadr.h
> freetype/include/freetype/internal/ftmemory.h
> freetype/include/freetype/internal/ftobjs.h
> freetype/include/freetype/internal/ftpic.h
> freetype/include/freetype/internal/ftpsprop.h
> freetype/include/freetype/internal/ftrfork.h
> freetype/include/freetype/internal/ftserv.h
> freetype/include/freetype/internal/ftstream.h
> freetype/include/freetype/internal/fttrace.h
> freetype/include/freetype/internal/ftvalid.h
> freetype/include/freetype/internal/internal.h
> freetype/include/freetype/internal/psaux.h
> freetype/include/freetype/internal/pshints.h
> freetype/include/freetype/internal/services/svbdf.h
> freetype/include/freetype/internal/services/svcfftl.h
> freetype/include/freetype/internal/services/svcid.h
> freetype/include/freetype/internal/services/svfntfmt.h
> freetype/include/freetype/internal/services/svgldict.h
> freetype/include/freetype/internal/services/svgxval.h
> freetype/include/freetype/internal/services/svkern.h
> freetype/include/freetype/internal/services/svmetric.h
> freetype/include/freetype/internal/services/svmm.h
> freetype/include/freetype/internal/services/svotval.h
> freetype/include/freetype/internal/services/svpfr.h
> freetype/include/freetype/internal/services/svpostnm.h
> freetype/include/freetype/internal/services/svprop.h
> freetype/include/freetype/internal/services/svpscmap.h
> freetype/include/freetype/internal/services/svpsinfo.h
> freetype/include/freetype/internal/services/svsfnt.h
> freetype/include/freetype/internal/services/svttcmap.h
> freetype/include/freetype/internal/services/svtteng.h
> freetype/include/freetype/internal/services/svttglyf.h
> freetype/include/freetype/internal/services/svwinfnt.h
> freetype/include/freetype/internal/sfnt.h
> freetype/include/freetype/internal/t1types.h
> freetype/include/freetype/internal/tttypes.h
> freetype/include/freetype/t1tables.h
> freetype/include/freetype/ttnameid.h
> freetype/include/freetype/tttables.h
> freetype/include/freetype/tttags.h
> freetype/include/freetype/ttunpat.h
> freetype/include/ft2build.h
> freetype/modules.cfg
> freetype/src/Jamfile
> freetype/src/autofit/Jamfile
> freetype/src/autofit/afangles.c
> freetype/src/autofit/afblue.c
> freetype/src/autofit/afblue.cin
> freetype/src/autofit/afblue.dat
> freetype/src/autofit/afblue.h
> freetype/src/autofit/afblue.hin
> freetype/src/autofit/afcjk.c
> freetype/src/autofit/afcjk.h
> freetype/src/autofit/afcover.h
> freetype/src/autofit/afdummy.c
> freetype/src/autofit/afdummy.h
> freetype/src/autofit/aferrors.h
> freetype/src/autofit/afglobal.c
> freetype/src/autofit/afglobal.h
> freetype/src/autofit/afhints.c
> freetype/src/autofit/afhints.h
> freetype/src/autofit/afindic.c
> freetype/src/autofit/afindic.h
> freetype/src/autofit/aflatin.c
> freetype/src/autofit/aflatin.h
> freetype/src/autofit/aflatin2.c
> freetype/src/autofit/aflatin2.h
> freetype/src/autofit/afloader.c
> freetype/src/autofit/afloader.h
> freetype/src/autofit/afmodule.c
> freetype/src/autofit/afmodule.h
> freetype/src/autofit/afpic.c
> freetype/src/autofit/afpic.h
> freetype/src/autofit/afranges.c
> freetype/src/autofit/afranges.h
> freetype/src/autofit/afscript.h
> freetype/src/autofit/afshaper.c
> freetype/src/autofit/afshaper.h
> freetype/src/autofit/afstyles.h
> freetype/src/autofit/aftypes.h
> freetype/src/autofit/afwarp.c
> freetype/src/autofit/afwarp.h
> freetype/src/autofit/afwrtsys.h
> freetype/src/autofit/autofit.c
> freetype/src/autofit/module.mk
> freetype/src/autofit/rules.mk
> freetype/src/base/Jamfile
> freetype/src/base/basepic.c
> freetype/src/base/basepic.h
> freetype/src/base/ftadvanc.c
> freetype/src/base/ftapi.c
> freetype/src/base/ftbase.c
> freetype/src/base/ftbase.h
> freetype/src/base/ftbbox.c
> freetype/src/base/ftbdf.c
> freetype/src/base/ftbitmap.c
> freetype/src/base/ftcalc.c
> freetype/src/base/ftcid.c
> freetype/src/base/ftdbgmem.c
> freetype/src/base/ftdebug.c
> freetype/src/base/ftfntfmt.c
> freetype/src/base/ftfstype.c
> freetype/src/base/ftgasp.c
> freetype/src/base/ftgloadr.c
> freetype/src/base/ftglyph.c
> freetype/src/base/ftgxval.c
> freetype/src/base/ftinit.c
> freetype/src/base/ftlcdfil.c
> freetype/src/base/ftmac.c
> freetype/src/base/ftmm.c
> freetype/src/base/ftobjs.c
> freetype/src/base/ftotval.c
> freetype/src/base/ftoutln.c
> freetype/src/base/ftpatent.c
> freetype/src/base/ftpfr.c
> freetype/src/base/ftpic.c
> freetype/src/base/ftpsprop.c
> freetype/src/base/ftrfork.c
> freetype/src/base/ftsnames.c
> freetype/src/base/ftstream.c
> freetype/src/base/ftstroke.c
> freetype/src/base/ftsynth.c
> freetype/src/base/ftsystem.c
> freetype/src/base/fttrigon.c
> freetype/src/base/fttype1.c
> freetype/src/base/ftutil.c
> freetype/src/base/ftver.rc
> freetype/src/base/ftwinfnt.c
> freetype/src/base/rules.mk
> freetype/src/bdf/Jamfile
> freetype/src/bdf/README
> freetype/src/bdf/bdf.c
> freetype/src/bdf/bdfdrivr.c
> freetype/src/bdf/bdflib.c
> freetype/src/bzip2/Jamfile
> freetype/src/bzip2/ftbzip2.c
> freetype/src/bzip2/rules.mk
> freetype/src/cache/Jamfile
> freetype/src/cache/ftcache.c
> freetype/src/cache/ftcbasic.c
> freetype/src/cache/ftccache.c
> freetype/src/cache/ftccache.h
> freetype/src/cache/ftccback.h
> freetype/src/cache/ftccmap.c
> freetype/src/cache/ftcerror.h
> freetype/src/cache/ftcglyph.c
> freetype/src/cache/ftcglyph.h
> freetype/src/cache/ftcimage.c
> freetype/src/cache/ftcimage.h
> freetype/src/cache/ftcmanag.c
> freetype/src/cache/ftcmanag.h
> freetype/src/cache/ftcmru.c
> freetype/src/cache/ftcmru.h
> freetype/src/cache/ftcsbits.c
> freetype/src/cache/ftcsbits.h
> freetype/src/cache/rules.mk
> freetype/src/cff/Jamfile
> freetype/src/cff/cf2intrp.c
> freetype/src/cff/cff.c
> freetype/src/cff/cffcmap.c
> freetype/src/cff/cffcmap.h
> freetype/src/cff/cffdrivr.c
> freetype/src/cff/cffdrivr.h
> freetype/src/cff/cfferrs.h
> freetype/src/cff/cffgload.c
> freetype/src/cff/cffgload.h
> freetype/src/cff/cffload.c
> freetype/src/cff/cffload.h
> freetype/src/cff/cffobjs.c
> freetype/src/cff/cffobjs.h
> freetype/src/cff/cffparse.c
> freetype/src/cff/cffparse.h
> freetype/src/cff/cffpic.c
> freetype/src/cff/cffpic.h
> freetype/src/cff/cfftoken.h
> freetype/src/cff/module.mk
> freetype/src/cff/rules.mk
> freetype/src/cid/Jamfile
> freetype/src/cid/ciderrs.h
> freetype/src/cid/cidgload.c
> freetype/src/cid/cidgload.h
> freetype/src/cid/cidload.c
> freetype/src/cid/cidload.h
> freetype/src/cid/cidobjs.c
> freetype/src/cid/cidobjs.h
> freetype/src/cid/cidparse.c
> freetype/src/cid/cidparse.h
> freetype/src/cid/cidriver.c
> freetype/src/cid/cidriver.h
> freetype/src/cid/cidtoken.h
> freetype/src/cid/module.mk
> freetype/src/cid/rules.mk
> freetype/src/cid/type1cid.c
> freetype/src/gxvalid/Jamfile
> freetype/src/gxvalid/README
> freetype/src/gxvalid/gxvalid.c
> freetype/src/gxvalid/gxvalid.h
> freetype/src/gxvalid/gxvbsln.c
> freetype/src/gxvalid/gxvcommn.c
> freetype/src/gxvalid/gxvcommn.h
> freetype/src/gxvalid/gxverror.h
> freetype/src/gxvalid/gxvfeat.c
> freetype/src/gxvalid/gxvfeat.h
> freetype/src/gxvalid/gxvfgen.c
> freetype/src/gxvalid/gxvjust.c
> freetype/src/gxvalid/gxvkern.c
> freetype/src/gxvalid/gxvlcar.c
> freetype/src/gxvalid/gxvmod.c
> freetype/src/gxvalid/gxvmod.h
> freetype/src/gxvalid/gxvmort.c
> freetype/src/gxvalid/gxvmort.h
> freetype/src/gxvalid/gxvmort0.c
> freetype/src/gxvalid/gxvmort1.c
> freetype/src/gxvalid/gxvmort2.c
> freetype/src/gxvalid/gxvmort4.c
> freetype/src/gxvalid/gxvmort5.c
> freetype/src/gxvalid/gxvmorx.c
> freetype/src/gxvalid/gxvmorx.h
> freetype/src/gxvalid/gxvmorx0.c
> freetype/src/gxvalid/gxvmorx1.c
> freetype/src/gxvalid/gxvmorx2.c
> freetype/src/gxvalid/gxvmorx4.c
> freetype/src/gxvalid/gxvmorx5.c
> freetype/src/gxvalid/gxvopbd.c
> freetype/src/gxvalid/gxvprop.c
> freetype/src/gxvalid/gxvtrak.c
> freetype/src/gxvalid/module.mk
> freetype/src/gxvalid/rules.mk
> freetype/src/gzip/Jamfile
> freetype/src/gzip/ftgzip.c
> freetype/src/gzip/ftzconf.h
> freetype/src/gzip/rules.mk
> freetype/src/gzip/zlib.h
> freetype/src/lzw/Jamfile
> freetype/src/lzw/ftlzw.c
> freetype/src/lzw/ftzopen.c
> freetype/src/lzw/ftzopen.h
> freetype/src/lzw/rules.mk
> freetype/src/otvalid/Jamfile
> freetype/src/otvalid/module.mk
> freetype/src/otvalid/otvalid.c
> freetype/src/otvalid/otvalid.h
> freetype/src/otvalid/otvbase.c
> freetype/src/otvalid/otvcommn.c
> freetype/src/otvalid/otvcommn.h
> freetype/src/otvalid/otverror.h
> freetype/src/otvalid/otvgdef.c
> freetype/src/otvalid/otvgpos.c
> freetype/src/otvalid/otvgpos.h
> freetype/src/otvalid/otvgsub.c
> freetype/src/otvalid/otvjstf.c
> freetype/src/otvalid/otvmath.c
> freetype/src/otvalid/otvmod.c
> freetype/src/otvalid/otvmod.h
> freetype/src/otvalid/rules.mk
> freetype/src/pcf/Jamfile
> freetype/src/pcf/README
> freetype/src/pcf/pcf.c
> freetype/src/pcf/pcf.h
> freetype/src/pcf/pcfdrivr.c
> freetype/src/pcf/pcfread.c
> freetype/src/pfr/Jamfile
> freetype/src/pfr/module.mk
> freetype/src/pfr/pfr.c
> freetype/src/pfr/pfrcmap.c
> freetype/src/pfr/pfrcmap.h
> freetype/src/pfr/pfrdrivr.c
> freetype/src/pfr/pfrdrivr.h
> freetype/src/pfr/pfrerror.h
> freetype/src/pfr/pfrgload.c
> freetype/src/pfr/pfrgload.h
> freetype/src/pfr/pfrload.c
> freetype/src/pfr/pfrload.h
> freetype/src/pfr/pfrobjs.c
> freetype/src/pfr/pfrobjs.h
> freetype/src/pfr/pfrsbit.c
> freetype/src/pfr/pfrsbit.h
> freetype/src/pfr/pfrtypes.h
> freetype/src/pfr/rules.mk
> freetype/src/psaux/Jamfile
> freetype/src/psaux/afmparse.c
> freetype/src/psaux/afmparse.h
> freetype/src/psaux/cffdecode.c
> freetype/src/psaux/cffdecode.h
> freetype/src/psaux/module.mk
> freetype/src/psaux/psarrst.c
> freetype/src/psaux/psarrst.h
> freetype/src/psaux/psaux.c
> freetype/src/psaux/psauxerr.h
> freetype/src/psaux/psauxmod.c
> freetype/src/psaux/psauxmod.h
> freetype/src/psaux/psblues.c
> freetype/src/psaux/psblues.h
> freetype/src/psaux/psconv.c
> freetype/src/psaux/psconv.h
> freetype/src/psaux/pserror.c
> freetype/src/psaux/pserror.h
> freetype/src/psaux/psfixed.h
> freetype/src/psaux/psfont.c
> freetype/src/psaux/psfont.h
> freetype/src/psaux/psft.c
> freetype/src/psaux/psft.h
> freetype/src/psaux/psglue.h
> freetype/src/psaux/pshints.c
> freetype/src/psaux/pshints.h
> freetype/src/psaux/psintrp.c
> freetype/src/psaux/psintrp.h
> freetype/src/psaux/psobjs.c
> freetype/src/psaux/psobjs.h
> freetype/src/psaux/psread.c
> freetype/src/psaux/psread.h
> freetype/src/psaux/psstack.c
> freetype/src/psaux/psstack.h
> freetype/src/psaux/pstypes.h
> freetype/src/psaux/rules.mk
> freetype/src/psaux/t1cmap.c
> freetype/src/psaux/t1cmap.h
> freetype/src/psaux/t1decode.c
> freetype/src/psaux/t1decode.h
> freetype/src/pshinter/Jamfile
> freetype/src/pshinter/module.mk
> freetype/src/pshinter/pshalgo.c
> freetype/src/pshinter/pshalgo.h
> freetype/src/pshinter/pshglob.c
> freetype/src/pshinter/pshglob.h
> freetype/src/pshinter/pshinter.c
> freetype/src/pshinter/pshmod.c
> freetype/src/pshinter/pshmod.h
> freetype/src/pshinter/pshnterr.h
> freetype/src/pshinter/pshpic.c
> freetype/src/pshinter/pshpic.h
> freetype/src/pshinter/pshrec.c
> freetype/src/pshinter/pshrec.h
> freetype/src/pshinter/rules.mk
> freetype/src/psnames/Jamfile
> freetype/src/psnames/module.mk
> freetype/src/psnames/psmodule.c
> freetype/src/psnames/psmodule.h
> freetype/src/psnames/psnamerr.h
> freetype/src/psnames/psnames.c
> freetype/src/psnames/pspic.c
> freetype/src/psnames/pspic.h
> freetype/src/psnames/pstables.h
> freetype/src/psnames/rules.mk
> freetype/src/raster/Jamfile
> freetype/src/raster/ftmisc.h
> freetype/src/raster/ftraster.c
> freetype/src/raster/ftraster.h
> freetype/src/raster/ftrend1.c
> freetype/src/raster/ftrend1.h
> freetype/src/raster/module.mk
> freetype/src/raster/raster.c
> freetype/src/raster/rasterrs.h
> freetype/src/raster/rastpic.c
> freetype/src/raster/rastpic.h
> freetype/src/raster/rules.mk
> freetype/src/sfnt/Jamfile
> freetype/src/sfnt/module.mk
> freetype/src/sfnt/pngshim.c
> freetype/src/sfnt/pngshim.h
> freetype/src/sfnt/rules.mk
> freetype/src/sfnt/sfdriver.c
> freetype/src/sfnt/sfdriver.h
> freetype/src/sfnt/sferrors.h
> freetype/src/sfnt/sfnt.c
> freetype/src/sfnt/sfntpic.c
> freetype/src/sfnt/sfntpic.h
> freetype/src/sfnt/sfobjs.c
> freetype/src/sfnt/sfobjs.h
> freetype/src/sfnt/ttbdf.c
> freetype/src/sfnt/ttbdf.h
> freetype/src/sfnt/ttcmap.c
> freetype/src/sfnt/ttcmap.h
> freetype/src/sfnt/ttcmapc.h
> freetype/src/sfnt/ttkern.c
> freetype/src/sfnt/ttkern.h
> freetype/src/sfnt/ttload.c
> freetype/src/sfnt/ttload.h
> freetype/src/sfnt/ttmtx.c
> freetype/src/sfnt/ttmtx.h
> freetype/src/sfnt/ttpost.c
> freetype/src/sfnt/ttpost.h
> freetype/src/sfnt/ttsbit.c
> freetype/src/sfnt/ttsbit.h
> freetype/src/smooth/Jamfile
> freetype/src/smooth/ftgrays.c
> freetype/src/smooth/ftgrays.h
> freetype/src/smooth/ftsmerrs.h
> freetype/src/smooth/ftsmooth.c
> freetype/src/smooth/ftsmooth.h
> freetype/src/smooth/ftspic.c
> freetype/src/smooth/ftspic.h
> freetype/src/smooth/module.mk
> freetype/src/smooth/rules.mk
> freetype/src/smooth/smooth.c
> freetype/src/tools/afblue.pl
> freetype/src/tools/apinames.c
> freetype/src/tools/docmaker/content.py
> freetype/src/tools/docmaker/docbeauty.py
> freetype/src/tools/docmaker/docmaker.py
> freetype/src/tools/docmaker/formatter.py
> freetype/src/tools/docmaker/sources.py
> freetype/src/tools/docmaker/tohtml.py
> freetype/src/tools/docmaker/utils.py
> freetype/src/tools/ftfuzzer/README
> freetype/src/tools/ftfuzzer/ftfuzzer.cc
> freetype/src/tools/ftfuzzer/ftmutator.cc
> freetype/src/tools/ftfuzzer/rasterfuzzer.cc
> freetype/src/tools/ftfuzzer/runinput.cc
> freetype/src/tools/ftrandom/ftrandom.c
> freetype/src/tools/glnames.py
> freetype/src/tools/update-copyright-year
> freetype/src/truetype/Jamfile
> freetype/src/truetype/module.mk
> freetype/src/truetype/rules.mk
> freetype/src/truetype/truetype.c
> freetype/src/truetype/ttdriver.c
> freetype/src/truetype/ttdriver.h
> freetype/src/truetype/tterrors.h
> freetype/src/truetype/ttgload.c
> freetype/src/truetype/ttgload.h
> freetype/src/truetype/ttgxvar.c
> freetype/src/truetype/ttgxvar.h
> freetype/src/truetype/ttinterp.c
> freetype/src/truetype/ttinterp.h
> freetype/src/truetype/ttobjs.c
> freetype/src/truetype/ttobjs.h
> freetype/src/truetype/ttpic.c
> freetype/src/truetype/ttpic.h
> freetype/src/truetype/ttpload.c
> freetype/src/truetype/ttpload.h
> freetype/src/truetype/ttsubpix.c
> freetype/src/truetype/ttsubpix.h
> freetype/src/type1/Jamfile
> freetype/src/type1/module.mk
> freetype/src/type1/rules.mk
> freetype/src/type1/t1afm.c
> freetype/src/type1/t1afm.h
> freetype/src/type1/t1driver.c
> freetype/src/type1/t1driver.h
> freetype/src/type1/t1errors.h
> freetype/src/type1/t1gload.c
> freetype/src/type1/t1gload.h
> freetype/src/type1/t1load.c
> freetype/src/type1/t1load.h
> freetype/src/type1/t1objs.c
> freetype/src/type1/t1objs.h
> freetype/src/type1/t1parse.c
> freetype/src/type1/t1parse.h
> freetype/src/type1/t1tokens.h
> freetype/src/type1/type1.c
> freetype/src/type42/Jamfile
> freetype/src/type42/module.mk
> freetype/src/type42/rules.mk
> freetype/src/type42/t42drivr.c
> freetype/src/type42/t42drivr.h
> freetype/src/type42/t42error.h
> freetype/src/type42/t42objs.c
> freetype/src/type42/t42objs.h
> freetype/src/type42/t42parse.c
> freetype/src/type42/t42parse.h
> freetype/src/type42/t42types.h
> freetype/src/type42/type42.c
> freetype/src/winfonts/Jamfile
> freetype/src/winfonts/fnterrs.h
> freetype/src/winfonts/module.mk
> freetype/src/winfonts/rules.mk
> freetype/src/winfonts/winfnt.c
> freetype/src/winfonts/winfnt.h
> freetype/vms_make.com

2018-05-16 22:25:06 -0700
Ray Johnston <ray.johnston@artifex.com>
ddace435eb99ea1c8a517f4ec94307cfe0743bce

> Fixup msvclib.mak that had seriously bit-rotted.
> Mainly pulling macro definition in from msvc.mak and add missing FEATURE_DEVS
> and change the default device to ppmraw (more useful than ljet2).
> base/msvclib.mak

2018-05-16 22:22:46 -0700
Ray Johnston <ray.johnston@artifex.com>
eab096dcf3d528c4a533ab1fb0616179dd0ee4e6

> Add missing dependency for sicclib (md5 is needed for icc cache hash)
> base/lib.mak

2018-05-16 13:35:26 -0700
Ray Johnston <ray.johnston@artifex.com>
cee69d4f50ff9a860040b8afdeb2cdb65a7252d8

> Rename "rand" function to "gs_rand" to avoid name clash on Windows
> Apparently (at least with VS 2015) stdlib.h contains a declaration for
> "rand" that clashes with the local version.
> base/gslib.c

2018-05-14 22:33:26 -0700
Ray Johnston <ray.johnston@artifex.com>
fc42e417956d4bf3b3b2d7138c550e04f62c3159

> Fix some InterpolateControl issues.
> Some devices (such as clist) rely on image->Interpolate to determine how
> to handle the image. Rather than checking dev->interpolate control there,
> and look for other devices that may also need it, do the force in the
> gs_image_begin_typed. Also, fix gs_pdf14_device_copy_params to copy the
> interpolate_control.
> base/gdevp14.c
> base/gsimage.c

2018-05-15 21:36:30 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
f90f090c0a5c3e5744d3ec6f0430fbe1a86ac44c

> Bug 697545 : Prevent SEGV in freetype if running out of memory.
> Prevent SEGV when trying to use buffer after memory failure. This patch has
> been accepted by the freetype team as commit e0015f7612cf07ff80561475321ce1f98c7c2b88
> Error created using :-
> MEMENTO_FAILAT=17104 ./membin/gpcl6 -sDEVICE=pbmraw -dMaxBitmap=2000 -o /dev/null ./tests_private/pcl/pcl5cfts/fts.0051
> freetype/src/autofit/afcjk.c
> freetype/src/autofit/aflatin.c
> freetype/src/autofit/afshaper.c

2018-05-09 11:31:38 -0700
Ray Johnston <ray.johnston@artifex.com>
43f429a2508e72d36a3b27671c8d7e43f1bbc591

> Increase the data_size for pattern-clist to 128k (from 32K).
> The tile cache is kept in the clist buffer, and there are a few files that
> trip over the limit of the number of hash slots with the small data_size,
> particularly comparefiles/Bug689851.pdf at 72 dpi. With this file, the clist
> size is reduced by about 65%. Other than the pattern-clist, the tile cache
> seems to work adequately without needing to delete tiles.
> Also this means that more data can be accumulated for image_data before
> needing to flush the buffer to the memory_clist storage, which should
> improve performance a bit (but pattern-clist is never going to be fast).
> base/gxpcmap.c

2018-04-26 20:11:31 +0100
Robin Watts <robin.watts@artifex.com>
9df005ac54c94dc986c3ed94b24d5ecdfe03582b

> Fix problem with transparency and ROPs.
> A comment from 1998 in gdevrop.c indicates that
> if we are given a LOP that says "S is transparent", and
> S isn't used, then we should ignore that flag. (Similarly
> for T). Tests seem to indicate that this is indeed true
> (See page 12 of C425.bin for an example).
> Unfortunately, when we start 'folding' LOPs down onto simpler
> ones, we can start with a LOP where S (or T) matters, and
> end up with one where it looks like it doesn't. As such we
> introduce another flag so we can avoid trying to remove
> the S/T transparency flags after we have started to fold the
> rop down.
> We use this in mem_gray8_rgb24_strip_copy_rop, and rop_get_run_op
> to ensure we don't throw away transparency by mistake.
> For example, in mem_gray8_rgb24_strip_copy_rop when called with
> lop=0x2fc, with S as a bitmap where both colors are the same, the
> current code spots that S is always 1, and rewrites the rop to be
> 0xff. This in turn leads to T not being required, so it is ignored,
> despite the fact that T should still be consulted for transparency.
> (Check that page 12 of C425.bin is still OK!)
> base/gdevmr8n.c
> base/gsroprun.c
> base/gsropt.h

2018-05-10 13:58:34 -0600
Henry Stiles <henry.stiles@artifex.com>
30aa9aee30bc0324359df1f931efb75c5a2c5dd7

> Only add the source to the ROP if it isn't already specified.
> The previous code unconditionally added the source to the ROP, so any
> ROP which contained ~S was changed to S. With the extra logic, the
> expression to determine the lop actual paramater was getting
> unreadable so it has been split up.
> base/gxdcolor.c

2018-05-09 17:34:43 +0100
Robin Watts <robin.watts@artifex.com>
8e31bcbf7214568b09a00683a19f7c4e847618f6

> Tweak previous fix to rounding in image code.
> Back in September 2016, commit bffe2011e1 went in, entitled "Fix bug
> 69707. SMask subpixel offset must match image offset."
> In this, an adjustment was applied to the dda to attempt to make it
> match the rounding used in the mono case.
> This adjustment was made *after* the position of the first edge was
> made, rather than after it, resulting in a slight difference to the
> size of the first pixel of a run.
> This error was spotted when comparing the output of an experimental
> optimisation to use memcpy for 1:1 runs of data.
> base/gxicolor.c

2018-05-08 12:37:07 +0100
Chris Liddell <chris.liddell@artifex.com>
f302fbc59b974a167a7a0023ac6f9e89ed27d243

> Honor the single object clump flag when allocating strings
> When checking whether a given clump was a candidate to allocate a string,
> the code was not checking the flag that marks the clump as being for a
> single object. That could lead to the clump being freed (with it's original,
> single object content, along with the string) when the string(s) were still
> in use.
> This is better than resetting the flag since single object clumps are such
> for a reason (they implement immovable memory), and we *never* want
> immovable memory to become movable
> base/gsalloc.c

2018-05-05 20:23:13 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
e1652d0b73989b77a914f6a0de58ec6f53fc8e01

> Bug 697545 : Prevent SEGV after gs_stroke.
> Prevent SEGV if memory allocation fails.
> Error created using :-
> MEMENTO_FAILAT=9971 ./membin/gpcl6 -sDEVICE=pbmraw -dMaxBitmap=2000 -o /dev/null ./tests_private/pcl/pcl5cfts/fts.0010
> base/gspaint.c

2018-05-05 22:49:20 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
93d78c6299905fe0a192840015f71820772be95c

> Bug 697545 : Fix memory leak in gx_image_enum_begin.
> Fix memory leak due to buffer not being freed on error.
> Error created using :-
> MEMENTO_FAILAT=10035 ./membin/gpcl6 -sDEVICE=pbmraw -dMaxBitmap=2000 -o /dev/null ./tests_private/pcl/pcl5cfts/fts.0010
> base/gxipixel.c

2018-05-05 21:28:41 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
2b2fef0e97c148795af8c4c08b261f2807f1ba52

> Bug 697545 : Prevent SEGV after fill_with_rule.
> Prevent SEGV if memory allocation fails.
> Error created using :-
> MEMENTO_FAILAT=9999 ./membin/gpcl6 -sDEVICE=pbmraw -dMaxBitmap=2000 -o /dev/null ./tests_private/pcl/pcl5cfts/fts.0010
> base/gspaint.c

2018-05-04 19:31:59 +0100
Robin Watts <robin.watts@artifex.com>
9e8ef6c2f2086adbf784ddbe71fe2799afc4002b

> Fix image skip logic (again).
> The device to be used is not penum->dev, that'd be far too sensible!
> Pass in the actual device to be used.
> base/gxidata.c
> base/gximage.h

2018-05-03 22:31:31 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
7fa6e4a640857f6cfb1d520e65376c0304594980

> Bug 697545 : Fix memory leak in gx_gstate_dev_ht_install.
> Fix memory leak due to cache not being freed on error.
> Error created using :-
> MEMENTO_FAILAT=10111 ./membin/gpcl6 -sDEVICE=pbmraw -dMaxBitmap=2000 -o /dev/null ./pcl/examples/owl.pcl
> base/gsht.c

2018-05-03 12:00:11 -0700
Ray Johnston <ray.johnston@artifex.com>
9df84425aab2009f6335d57b5c19da2ac49294c4

> Clean up some left over RECT_RECOVER code, delete band_code from state
> base/gxcldev.h
> base/gxclimag.c
> base/gxclrect.c

2018-05-02 08:34:52 -0700
Ray Johnston <ray.johnston@artifex.com>
fe6b6679bced0f6f9b617e72278c538da8386b5c

> Remove unused clist command definitions, document unused code values.
> In preparation for upcoming clist changes for tiles, do some clean up of
> the definitions and document unused command codes. Note that there are
> still commands with flag bits where there are unused bits when certain
> flags are set, e.g. copy_mono_planes, low 3 bits unused if copy_use_tile
> is set, but using these code combinations would need changes in the
> clist_playback_band reader.
> base/gxcldev.h
> base/gxclimag.c
> base/gxclpath.h
> base/gxclrast.c

2018-05-03 18:49:03 +0100
Robin Watts <robin.watts@artifex.com>
a080da17f4d060b4e23d85b35989df92bb4bf76c

> Remove outdated comment.
> base/gxicolor.c

2018-05-03 11:51:22 +0100
Robin Watts <robin.watts@artifex.com>
23de52cfaf6e263dde824bd7be0b8d9d1d2cd053

> Fix quirk in image enumerator creation routines.
> When we start an image, the image code runs through the handlers
> for different types of image until it finds one that can handle
> the required type.
> These handlers are queried with the current device in as penum->dev.
> The image code then sets up any clip or rop device on top of this
> device.
> If the handlers were to call device functions, they would be in
> the somewhat odd position of calling a different device in the setup
> phase than they would be calling in the processing phase. This
> upsets a forthcoming commit.
> The fix is to ensure that any clip and rop devices are setup BEFORE
> the image handlers are called.
> base/gxipixel.c

2018-04-29 10:28:48 +0100
Chris Liddell <chris.liddell@artifex.com>
7b4ad6025f0576e2adb971230a9a2dfb62335a13

> Update doc/thirdparty.htm
> doc/thirdparty.htm

2018-04-25 14:22:03 +0100
Robin Watts <robin.watts@artifex.com>
f7bfa8db8f1407f70253667d832f3b219b434559

> Fix source + texture both data in mem_gray8_rgb24_strip_copy_rop.
> Using rop rather than lop means transparency was broken in the
> (unusual) source + texture both being data based case.
> Also, we were failing to update the source pointer, causing odd
> repeats in output.
> base/gdevmr8n.c

2018-04-27 07:52:52 -0600
Henry Stiles <henry.stiles@artifex.com>
2fd21f767d9b4065fd4f3ef1319ad6dbee8a2ffd

> Change ownership of jbig2 to Sebastian.
> doc/who_owns_what.txt

2018-04-27 11:27:44 +0100
Ken Sharp <ken.sharp@artifex.com>
5ff675bcb1ce0a1349a81c4c2dbfde20769616fa

> pdf_info.ps - report if a PDF file uses XFA forms
> toolbin/pdf_info.ps

2018-04-26 19:01:44 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
133d0c54ba05f887f67c441ceda59f49cf563902

> Bug 697545 : Fix memory leak in clist_open.
> Fix memory leak due to cache not being freed on error.
> Error created using :-
> MEMENTO_FAILAT=1835 ./membin/gpcl6 -sDEVICE=pbmraw -sDEVICE=pbmraw -o /dev/null ./pcl/examples/owl.pcl
> base/gxclist.c

2018-04-25 09:55:51 -0700
Ray Johnston <ray.johnston@artifex.com>
4609498d02a91f954636124d5f5699794ffac48a

> Fix bug 697671: Banding/Page mode mismatch
> The simplified case had a character (copy_mono) followed by a rect
> fill.
> The copy_mono for the character sets the rect.height clamped to the
> "cropping_max" (dev->height) for the band in the writer, but it doesn't
> actually write the height to the clist for that band. Then the reader
> was using the entire bitmap height, but that went past the end of the
> device, so the next time the state.rect.height was used in the reader,
> it was wrong.
> base/gxclrast.c

2018-04-25 20:26:43 +0100
Robin Watts <robin.watts@artifex.com>
bf9c9faf78caacc7e90faf04b50611153a64d014

> Update clusterpush.pl to allow for larger files.
> toolbin/localcluster/clusterpush.pl

2018-04-24 16:00:31 +0100
Chris Liddell <chris.liddell@artifex.com>
8197eaf98c552991a0b7f8068ff3fcce56c07803

> Bug 699201: Fix alignment of rendering bands memory
> The bottom section of the "raster buffer", when rendering through the page
> clist, is reserved as a cache (tile cache, to be specific). Hence to bottom
> address of the memory we actually render into starts immediately after the
> cache.
> No account was taken when setting up that cache size of the alignment expected
> by the rendering code.
> We'll now ensure that the the cache ends, and the raster band memory starts
> on an appropriately aligned address.
> base/gxclist.c

2018-04-24 15:22:15 +0100
Robin Watts <robin.watts@artifex.com>
610862e06b739430a2994dc4a0c399fa21900521

> Tweak MSVC Profile build settings.
> While attempting to debug an unrelated issue, I found a note on
> an MSVC forum from an MS developer suggesting that we should use
> /Profile rather than /PROFILE or /profile as the flags. They
> *should* do the same thing, but the suggestion is that there
> might be a bug in the MS linker.
> Committing this here as it certainly doesn't hurt, and might save
> someone hours in future.
> psi/msvc.mak

2018-04-24 11:57:28 +0100
Robin Watts <robin.watts@artifex.com>
0be413a3f3a24c3d55062273cd37e8fcac7c0c4f

> Fix mem_gray8_rgb24_strip_copy_rop.
> A couple of cases in this routine were failing to increment
> the destination pointer after writing. I guess this shows
> that a couple of cases are rarely used for partial scanlines.
> base/gdevmr8n.c

2018-04-20 23:50:59 +0100
Robin Watts <robin.watts@artifex.com>
c56b2c2d72ef86f3e45882dd5b35a772ce79e8f9

> Avoid 'const' warning.
> base/gxi12bit.c

2018-04-20 14:45:52 +0100
Robin Watts <robin.watts@artifex.com>
7657398e7574f4a54eb35ea757a7c3037fe7c0e5

> Further simplification to image_render_icc_... functions.
> Avoid needless alternations in the middle of the loop in
> exchange for a single function call.
> base/gxcmap.c
> base/gxcmap.h
> base/gxi12bit.c
> base/gxicolor.c

2018-04-20 18:10:12 +0100
Robin Watts <robin.watts@artifex.com>
4a2f6848f38c60eb39a5467c951cfdc06c334a19

> Apply same simplification/optimisations to image_render_icc16
> Apply the same changes to image_render_icc16 as we did just a few
> commits ago.
> base/gxi12bit.c

2018-04-19 19:13:50 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
7b539b765dcc960d257bffbcfef8a496120887a8

> Bug 697545 : Prevent SEGV in c_param_add.
> Prevent SEGV if pkey memory allocation fails.
> Error created using :-
> MEMENTO_FAILAT=1823 ./membin/gpcl6 -sDEVICE=pbmraw -r300 -dMaxBitmap=2000 -o /dev/null ./pcl/examples/owl.pcl
> base/gscparam.c

2018-04-16 20:34:46 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
28c25a7aa12ab36996e12850dfc8e0935c0e4437

> Bug 697545 : Prevent SEGV in pcfont_do_reset.
> Prevent SEGV if memory allocation fails.
> Error created using :-
> MEMENTO_FAILAT=1908 ./membin/gpcl6 -sDEVICE=pbmraw -r300 -o /dev/null ./pcl/examples/owl.pcl
> pcl/pcl/pcfont.c

2018-04-19 17:42:06 +0100
Robin Watts <robin.watts@artifex.com>
b35f89d9bef02a02c55a377c6797afcbbe78664d

> Simplify some image_render code routines.
> Primarily these cut down on needlessly duplicated code.
> The skew case should actually benefit in speed, because we don't
> pointlessly redo the color mapping for every pixel.
> base/gxicolor.c

2018-04-17 21:38:31 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
2c25f3c8582749cc9641d12ca4eb51adefa6d04d

> Bug 697545 : Fix memory leak in rc_unshare_struct.
> Rearrange order of macro so that the memory is freed even if the call to
> rc_alloc_struct_1 fails.
> Error created using :-
> MEMENTO_FAILAT=10044 ./membin/gpcl6 -sDEVICE=pbmraw -r300 -o /dev/null ./pcl/examples/owl.pcl
> base/gsrefct.h

2018-04-19 13:41:33 +0100
Chris Liddell <chris.liddell@artifex.com>
8f37f0e4f6325ea8f58194d81a8a6e3321e6660e

> Remove some experimental code that was ifdef'ed out
> base/gxfapi.c

2018-04-19 13:38:30 +0100
Chris Liddell <chris.liddell@artifex.com>
e8e91f7046645ac7334516735d06ae5109127892

> Ensure uncached glyphs have the "text" tag set.
> Glyphs bitmaps being drawn from FAPI, bypassing the glyph cache, were not
> causing the device's tag to be set to text.
> base/gxfapi.c

2018-04-18 13:54:13 +0100
Chris Liddell <chris.liddell@artifex.com>
8f912519ee1d7407126479fefc2210bc69f9e11a

> Fix compiler warning with debug build
> In a debug build, to facilitate logging/debugging, the rc_ajust() macro
> calls a function to trace the reference count changes. The client name (cname)
> parameter should be declared const to avoid a compiler warning.
> base/gsmemory.c
> base/gsrefct.h

2018-04-18 10:11:50 +0100
Chris Liddell <chris.liddell@artifex.com>
b8c65eab50076cfd56f0301ec764b30df9d86ae3

> Bug 699214: Add and use a "no cache" flag for glyphs
> Previously, to avoid using a cached glyph, the PXL code went around the
> graphics library API to set a flag in the show enumerator that really should
> only be touched internally.
> This adds the capability to the enumerator for the client to request that no
> cached glyphs be used for the current block of text, and changes the PXL code
> to used it.
> base/gstext.h
> base/gxchar.c
> pcl/pxl/pxfont.c

2018-04-18 09:07:27 +0100
Chris Liddell <chris.liddell@artifex.com>
fd22032d14134f32a42897c9db6a796340a912de

> Bug 699214 (related): make text and show enums the same
> This is the first part of removing the text enumerator altogether.
> base/gxchar.h
> base/gxtext.h
> base/lib.mak
> devices/vector/gdevpdtt.h
> devices/vector/gdevtxtw.c

2018-04-18 15:47:20 +0100
Ken Sharp <ken.sharp@artifex.com>
49dcf2a599434f2cb9e0847a75ad61270d30e68a

> Documentation - document two missing parameters
> These got missed from the documentation when they were implemented.
> doc/VectorDevices.htm

2018-04-18 15:46:32 +0100
Ken Sharp <ken.sharp@artifex.com>
39b1e54b2968620723bf32e96764c88797714879

> pdfwrite - Guard against trying to output an infinite number
> Bug #699255 " Buffer overflow on pprintg1 due to mishandle postscript file data to pdf"
> The file uses an enormous parameter to xyxhow, causing an overflow in
> the calculation of text positioning (value > 1e39).
> Since this is basically a nonsense value, and PostScript only supports
> real values up to 1e38, this patch follows the same approach as for
> a degenerate CTM, and treats it as 0.
> Adobe Acrobat Distiller throws a limitcheck error, so we could do that
> instead if this approach proves to be a problem.
> devices/vector/gdevpdts.c

2018-04-17 16:09:40 +0100
Chris Liddell <chris.liddell@artifex.com>
fb4c58a0e097e39547dde3d46893ce1b05d19539

> Remove redundant references to Xfonts.htm
> base/unixinst.mak
> doc/Drivers.htm
> doc/Readme.htm
> doc/Use.htm

2018-03-30 14:38:28 +0100
Chris Liddell <chris.liddell@artifex.com>
59c722d075cb70fc076c2d41b30f16e0e54a4704

> Bug 699160: rejig the .so "loaders" builds.
> The two simple .so "loaders" (gsx and gsc) were built as a single step, source
> to exe, process. Because of that LDFLAGS wasn't used.
> We'll now separate the compile and link stages, meaning we can properly use
> CFLAGS and LDFLAGS. It also means we can have more control of the order in
> which the -L lib search paths are applied.
> Properly pass on debug options, and extend these changes to the PCL/XPS/PDL
> .so/exe targets.
> Makefile.in
> base/unix-dll.mak
> base/unixlink.mak
> configure.ac

2018-04-15 12:49:40 -0700
Ray Johnston <ray.johnston@artifex.com>
769ffb76e7cfd5eeff32251d122399f4b729477b

> Fix warning on exit with ref_count > 0 due to pclxl image handling.
> The pclxl_begin_image gets a link profile, but did not release the
> link in pclxl_image_end_image causing the ref_count to be wrong.
> devices/vector/gdevpx.c

2018-04-15 12:48:20 -0700
Ray Johnston <ray.johnston@artifex.com>
e88d8e90de569adedb614a2a7e3dda38063f4d02

> Add ref_count debug to icc link cache.
> base/gsicc_cache.c

2018-04-11 19:37:07 +0100
Robin Watts <robin.watts@artifex.com>
dfbf92a35d2be0aaa35bdb301c0647deec55b054

> Attempt to fix vertical shifts seen in halftoning.
> Differences are evident between old (slow, non SSE based) and new
> (fast, C/SSE based) halftoning. This is not because of the SSE,
> but rather because of different calculations in the C that prepares
> the screen for the fast SSE based thresholding, specifically, I
> believe, to the calculation of the y offset into the texture tile.
> This commit changes the texture tile y offset calculation in the
> 'fast' code to involve screen_phase.y, in the hopes that this
> will better match the 'old' version.
> With this fix in, we see just a few PS/PDF diffs, but lots of PCL
> diffs (as I guess you'd expect, as PCL makes much more use of this
> kind of stuff). I've checked a random selection of them, and in all
> cases the new page mode renderings with the "fast" code match the
> page mode renderings given by the "old" code.
> There are instances where the clist rendering no longer matches the
> page mode rendering, but in the tests I've done the clist old code
> does match the clist fast code. So we are consistent at least. I
> suspect that there is something up with the way the y_phase is
> transmitted across the clist, and have opened bug 699209 to
> track that.
> base/gxht_thresh.c

2018-04-11 20:28:23 +0100
Robin Watts <robin.watts@artifex.com>
b9e0722267e8770c01914da28f924cffcae1c0b8

> Fix stray debugging code that was breaking windows builds.
> base/write_t1.c

2018-04-10 16:01:44 +0100
Chris Liddell <chris.liddell@artifex.com>
1da9cf6dd87287b952826e8606a26f97b474c556

> Multiple master font cached glyphs
> In the event that the WeightVector is changed (via setweightvector) on an
> already defined font object, we had no way to invalidate the glyph cache
> entries already created for that font, with the previous WeightVector.
> Given that MM fonts generally substitute for an entire use of a "real" font,
> and changing "mid stream" is rare (and almost entirely restricted to test
> files), this uses the sledgehammer approach of purging the existing glyphs
> from the cache.
> In real world use, this is going to have less effect on performance than adding
> a conditional check on a variable length array of floating point numbers is
> likely to have.
> psi/int.mak
> psi/zchar1.c

2018-01-30 09:31:04 +0000
Chris Liddell <chris.liddell@artifex.com>
36e7d38af2a11b5e4d7117ddd0ebf7326fad7c72

> Bug 698767: Improve handling of multiple master fonts
> The FAPI API didn't really handle the possibility that multiple master fonts
> could change (via setweightvector) without a call to definefont/setfont etc.
> We now allow two ways for FAPI to handle this: if the scaler in force allows it,
> we'll set the new weight vector, and carry on as before.
> If the scaler does *not* allow us to change the weight vector "on the fly",
> we'll destroy the scaler's font object and related data, and recreate it with
> the new weight vector in the font dictionary.
> base/fapi_ft.c
> base/fapibstm.c
> base/fapiufst.c
> base/gsalloc.c
> base/gxfapi.c
> base/gxfapi.h
> base/write_t1.c
> psi/zfapi.c

2018-04-08 20:34:43 +0800
Sebastian Rasmussen <sebras@gmail.com>
890e637bf7a1d8a5e3438c2aab4e0eef33d795f1

> jbig2dec: Detect data shortage.
> jbig2dec/jbig2_page.c
> jbig2dec/jbig2_segment.c
> jbig2dec/jbig2_text.c

2018-04-08 20:33:33 +0800
Sebastian Rasmussen <sebras@gmail.com>
44ff6900ac97d53101c8585880acb9a73631cefe

> jbig2dec: Remember to free halftone GB_stats in case of error.
> jbig2dec/jbig2_halftone.c

2018-04-08 20:32:59 +0800
Sebastian Rasmussen <sebras@gmail.com>
9efdbd90790f87ab9f56a4cd39b703a23c9d3172

> jbig2dec: Make error messages distinguishable.
> jbig2dec/jbig2_symbol_dict.c

2018-04-08 14:58:23 +0800
Sebastian Rasmussen <sebras@gmail.com>
1fca43f52caa90926169fe1fe845837749bab233

> jbig2dec: Plug leak of image upon error decoding text region.
> jbig2dec/jbig2_symbol_dict.c

2018-04-06 00:41:01 +0800
Sebastian Rasmussen <sebras@gmail.com>
2b2dcf4ccf401ed210f03c858b304994749fd2b3

> jbig2dec: Improve error handling.
> Some functions detected errors but would not return these
> to the caller. These functions may now indicate errors:
> jbig2_arith_decode(), jbig2_image_resize()
> Errors detected by following functions were not always
> handled, but they are now handled properly:
> jbig2_arith_decode(), jbig2_arith_iaid_decode()
> jbig2_arith_int_ctx_new(), jbig2_build_huffman_table()
> jbig2_complete_page(), jbig2_image_compose()
> jbig2_decode_refinement_region(), jbig2_ctx_new()
> jbig2_image_resize(), jbig2_image_write_pbm()
> jbig2_image_write_pbm_file(), jbig2_image_write_png()
> jbig2_image_write_png_file(), jbig2_metadata_add()
> jbig2_page_add_result(), jbig2_renew()
> jbig2_strndup()
> Some functions detected errors but did not fail early enough:
> jbig2_decode_pattern_dict(), jbig2_decode_halftone_region()
> jbig2_decode_mmr_line() detected errors but did not produce
> suitable error messages. This has been rectified.
> Finally, if a subfunction indicates an error by returning an
> error code, the calling function will report a warning and
> return, indicating failure.
> jbig2dec/jbig2.c
> jbig2dec/jbig2_arith.c
> jbig2dec/jbig2_arith.h
> jbig2dec/jbig2_arith_iaid.c
> jbig2dec/jbig2_arith_iaid.h
> jbig2dec/jbig2_arith_int.c
> jbig2dec/jbig2_arith_int.h
> jbig2dec/jbig2_generic.c
> jbig2dec/jbig2_halftone.c
> jbig2dec/jbig2_image.c
> jbig2dec/jbig2_image_pbm.c
> jbig2dec/jbig2_image_png.c
> jbig2dec/jbig2_metadata.c
> jbig2dec/jbig2_mmr.c
> jbig2dec/jbig2_page.c
> jbig2dec/jbig2_refinement.c
> jbig2dec/jbig2_segment.c
> jbig2dec/jbig2_symbol_dict.c
> jbig2dec/jbig2_text.c
> jbig2dec/jbig2dec.c
> jbig2dec/pbm2png.c

2018-04-06 00:44:10 +0800
Sebastian Rasmussen <sebras@gmail.com>
7ede8fc2b5e8498619d1e32b6b7fbbf9f926a055

> jbig2dec: Remove unused return value for setting pixel.
> jbig2dec/jbig2_image.c
> jbig2dec/jbig2_image.h

2018-04-09 21:30:07 +0800
Sebastian Rasmussen <sebras@gmail.com>
2afeb8384e4db612df56d5f02162767647893a7d

> jbig2dec: Remove end of line characters to jbig2_error() messages.
> jbig2dec/jbig2_image.c
> jbig2dec/jbig2_symbol_dict.c

2018-04-07 00:12:15 +0800
Sebastian Rasmussen <sebras@gmail.com>
d38507b3d62d9d0710b1c5122af5db9730167082

> jbig2dec: Fix some cosmetic typos in code/headers/tests.
> jbig2dec/jbig2.h
> jbig2dec/jbig2_halftone.c
> jbig2dec/jbig2_huffman.c
> jbig2dec/jbig2_image_png.c
> jbig2dec/jbig2_metadata.c
> jbig2dec/jbig2_page.c
> jbig2dec/jbig2_priv.h
> jbig2dec/jbig2_segment.c
> jbig2dec/jbig2_text.c
> jbig2dec/jbig2dec.c
> jbig2dec/memento.c
> jbig2dec/test_jbig2dec.py

2018-03-26 21:57:33 +0800
Sebastian Rasmussen <sebras@gmail.com>
c0f89bd215d700339429da4375a4eaf89445f872

> jbig2dec: Remove unnecessary whitespace.
> jbig2dec/jbig2.c
> jbig2dec/jbig2_arith.c
> jbig2dec/jbig2_generic.c
> jbig2dec/jbig2_huffman.c
> jbig2dec/jbig2_symbol_dict.c
> jbig2dec/jbig2_text.c
> jbig2dec/test_jbig2dec.py

2018-04-09 11:49:52 +0200
Tor Andersson <tor.andersson@artifex.com>
47f3be9b6676ed09e844362b267daae2a1b04a4d

> jbig2dec: Make sure to include stdint.h in the generated config_types.h
> The previous commit accidentally broke the autoconf build.
> jbig2dec/autogen.sh

2018-04-06 12:44:38 +0100
Robin Watts <robin.watts@artifex.com>
bda3b5087d136c7839ded79594ac70e9712228e5

> Fix Memento locking problem.
> When calling Memento_event, it would lock, and then call
> Memento_checkAllMemory which would lock again. This is fine
> on windows, as locks are recursive, but not on Linux.
> base/memento.c

2018-04-04 22:36:24 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
cbbe08d116ae91e0cc0ffa91eb71ec364b4d44a3

> Bug 697545 : Fix memory leak in gx_pattern_load.
> Fix memory leak due to pattern cache data being allocated but not used.
> Error created using :-
> MEMENTO_FAILAT=10103 ./membin/gpcl6 -sDEVICE=ppmraw -o /dev/null ./pcl/examples/owl.pcl
> base/gxpcmap.c

2018-04-04 18:40:01 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
cbc44b82c2c63ef48c994fb2eced4350e41159aa

> Bug 697545 : Fix memory leak in show_proceed.
> Fix memory leak due to gsave/grestore mismatch.
> Error created using :-
> MEMENTO_FAILAT=10946 ./membin/gpcl6 -sDEVICE=ppmraw -o /dev/null ./pcl/examples/owl.pcl
> base/gxchar.c

2018-04-05 16:28:01 +0100
Robin Watts <robin.watts@artifex.com>
4372854939842240c7edb58dd0fa285a0c2f15b1

> Another attempt at fixing the 'skip' logic for halftoned images.
> When rendering images, if the dda is not shared between the
> halftoner and gs, gs cannot just skip lines that it knows should
> be clipped, lest the halftoner get confused about it.
> The previous attempt to solve this used a separate 'skip_render'
> routine, but the decision as to whether to call this or not was
> itself dependent on the values of the dda. When scaling down
> scanlines can be completely skipped. In the cases where the dda
> in gs doesn't match the one in the halftoner exactly we could
> get dropouts.
> So, a new attempt. Here we introduce a new function call that
> checks with the halftoner whether the next scanline will be
> required or not. If it is, gs unpacks the data and passes it in.
> If not, the data can just be skipped.
> base/gxidata.c
> base/gximage.h
> base/gxipixel.c

2018-04-04 18:38:02 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
5886c28f2a7376ad3818dadeb9cc3c6989f7702a

> Bug 697545 : Fix memory leak in pcl_start_raster.
> Fix memory leak after memory allocation failure.
> Error created using :-
> MEMENTO_FAILAT=11602 ./membin/gpcl6 -sDEVICE=ppmraw -o /dev/null ./pcl/examples/owl.pcl
> pcl/pcl/rtraster.c

2018-04-05 14:12:25 +0100
Chris Liddell <chris.liddell@artifex.com>
9ef02a883952ecc225792896a1eabac93e19f143

> Bug 699158: Tidy up a validation check
> Use a cleaner check to ensure UFST only gets passed Microtype fonts (from .fco
> font collections).
> Not sure what I was thinking when I wrote the original check, but it was clearly
> a bad code day!
> base/fapiufst.c

2018-04-05 14:10:54 +0100
Chris Liddell <chris.liddell@artifex.com>
410d5f9372db241713f0e9730ec18edfa117f687

> Fix some link typos in Develop.html
> doc/Develop.htm

2018-04-04 17:30:17 +0100
Robin Watts <robin.watts@artifex.com>
bc9e133f81e02e90e9fc9a82853d0aea18cdb905

> Fix new logic for skipping clipped image lines.
> In refactoring the previous commit so that it didn't cause
> diffs, I broke it so that it gave no advantage.
> This version should give no diffs, AND give a speed increase
> by avoiding unpacking elided lines.
> base/gxidata.c

2018-04-03 17:47:03 +0100
Robin Watts <robin.watts@artifex.com>
41e94a745cdbed112efc0e72d76645e8500a0791

> Tweak logic for skipping clipped image lines.
> As gs runs through image data, it unpacks each line into
> a buffer, then checks whether that buffer is trivially
> outside the clipping region. If it is, then it doesn't
> bother to call the line renderer.
> This has 2 implications. Firstly, we unpack the line data
> even if it is to be skipped. Secondly, for line renderers
> that rely on counting the number of lines they have been
> passed (rather than on consulting the position of the dda)
> to know where they are, this can cause problems.
> Accordingly, this commit rejigs the code a bit. As well
> as a function pointer within penum that points to the
> rendering routine, we have a new function pointer that
> points to an optional "skip_render" routine.
> We also rejig the code so that we only unpack the data if
> we know it is going to be used.
> base/gxidata.c
> base/gximage.h
> base/gxipixel.c

2018-04-02 12:43:21 +0100
Robin Watts <robin.watts@artifex.com>
2870842d23f13413f3492f206cd12bb4144fc80d

> Whitespace fix.
> base/gxicolor.c

2018-04-02 12:44:36 +0100
Robin Watts <robin.watts@artifex.com>
8afca3fad1acbfd34b2a2910d04a5447c2e4555b

> Downgrade gen_ordered solutions to VS2005.
> From VS2008. VS2008 can still read the new (old!) ones.
> toolbin/halftone/gen_ordered/gen_ordered.sln
> toolbin/halftone/gen_ordered/gen_ordered.vcproj

2018-04-03 00:13:16 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
7891eda84b33aef5ee7540b3b3d04477e3602a3d

> Prevent SEGV in memento squeeze builds.
> Remove leftover variables from commit 9ff6b34e461fcbd4e.
> Added conditional compilation to prevent SEGV from thread code.
> base/gsicc_cache.c
> base/gsicc_manage.c

2018-03-29 20:15:29 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
f0e234d660dbeb774f39392f0e45e333fd9308a3

> Bug 697545 : Update set_cache_device to prevent memory leaks.
> Added a matching grestore for the gsave on all error paths.
> base/gxchar.c

2018-03-30 09:21:28 +0100
Chris Liddell <chris.liddell@artifex.com>
bd2ce49067793d8b57c6a1b4831e16f952183f6b

> Address warnings and deprecated API calls.
> A number of gtk/gdk/cairo API calls have been deprecated since GTK+ 3.0 was
> introduced, and using them triggers warnings - this replaces them with the
> currently recommended APIs.
> Also fix a couple of regular compiler warnings, and a gsapi related warning.
> psi/dxmain.c

2018-03-29 14:04:10 -0700
Michael Vrhel <michael.vrhel@artifex.com>
25785cd67484e6ebf3625f7d2adedac076e80de2

> Do not create a new cache for the ICC links with each page in clist mode
> Right now the code currently creates a new ICC cache with every page.
> This commit maintains the cache and only destroys it when we gdev_prn_tear_down
> base/gxclist.c
> base/gxclread.c

2018-03-27 20:13:18 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
344db7fb39f457201f243b2775e3d63cf8406010

> Bug 697545 : Update functions to return error codes.
> Prevent numerous SEGV points by ensuring error codes are returned and
> handled appropriately.
> base/gsdps1.c
> base/gxchar.c
> base/gxifast.c
> base/gximage4.c
> pcl/pcl/pctext.c

2018-03-29 10:14:22 -0700
Robin Watts <Robin.Watts@artifex.com>
0f6ec1c44bb38175344be16d747b8feee35ae35f

> Memento: Fix typo in Mutex init.
> Thanks to Shelly for pointing this out.
> base/memento.c

2018-03-28 14:57:56 +0100
Chris Liddell <chris.liddell@artifex.com>
a31ccd111b6ff21a1e49806c1e6e0861a9e45446

> Update OpenJPEG to 2.3.0
> Incorporates changes from:
> 1) Add predefined openjpeg headers.
> 71242c9a04bb76b8b17fc489d62a91d04c1ad60c
> 2) Import patches from Sumatra's tree.
> 8b89e4b5750069172522ecf85e69d094b5e567e7
> 3) Avoid getenv call in openjpeg
> 202a0318a7b3a397fcd5d015dcad4293474f464c
> base/openjpeg.mak
> openjpeg/CHANGELOG.md
> openjpeg/NEWS.md
> openjpeg/README.md
> openjpeg/appveyor.yml
> openjpeg/doc/CMakeLists.txt
> openjpeg/doc/Doxyfile.dox.cmake.in
> openjpeg/doc/jpip_architect.png
> openjpeg/doc/jpip_protocol.png
> openjpeg/doc/mainpage.dox.in
> openjpeg/doc/man/man1/opj_compress.1
> openjpeg/doc/man/man1/opj_decompress.1
> openjpeg/doc/man/man1/opj_dump.1
> openjpeg/doc/man/man3/libopenjp2.3
> openjpeg/doc/openjpip.dox.in
> openjpeg/src/bin/CMakeLists.txt
> openjpeg/src/bin/common/CMakeLists.txt
> openjpeg/src/bin/common/color.c
> openjpeg/src/bin/common/color.h
> openjpeg/src/bin/common/format_defs.h
> openjpeg/src/bin/common/opj_apps_config.h.cmake.in
> openjpeg/src/bin/common/opj_getopt.c
> openjpeg/src/bin/common/opj_getopt.h
> openjpeg/src/bin/common/opj_string.h
> openjpeg/src/bin/jp2/CMakeLists.txt
> openjpeg/src/bin/jp2/convert.c
> openjpeg/src/bin/jp2/convert.h
> openjpeg/src/bin/jp2/convertbmp.c
> openjpeg/src/bin/jp2/convertpng.c
> openjpeg/src/bin/jp2/converttif.c
> openjpeg/src/bin/jp2/index.c
> openjpeg/src/bin/jp2/index.h
> openjpeg/src/bin/jp2/opj_compress.c
> openjpeg/src/bin/jp2/opj_decompress.c
> openjpeg/src/bin/jp2/opj_dump.c
> openjpeg/src/bin/jp2/windirent.h
> openjpeg/src/bin/jp3d/CMakeLists.txt
> openjpeg/src/bin/jp3d/convert.c
> openjpeg/src/bin/jp3d/convert.h
> openjpeg/src/bin/jp3d/getopt.c
> openjpeg/src/bin/jp3d/getopt.h
> openjpeg/src/bin/jp3d/opj_jp3d_compress.c
> openjpeg/src/bin/jp3d/opj_jp3d_decompress.c
> openjpeg/src/bin/jp3d/tcltk/LPI_JP3D_VM.tcl
> openjpeg/src/bin/jp3d/tcltk/README
> openjpeg/src/bin/jp3d/tcltk/Thumbs.db
> openjpeg/src/bin/jp3d/tcltk/decoder.tcl
> openjpeg/src/bin/jp3d/tcltk/encoder.tcl
> openjpeg/src/bin/jp3d/tcltk/logoLPI.gif
> openjpeg/src/bin/jp3d/windirent.h
> openjpeg/src/bin/jpip/CMakeLists.txt
> openjpeg/src/bin/jpip/README
> openjpeg/src/bin/jpip/opj_dec_server.c
> openjpeg/src/bin/jpip/opj_jpip_addxml.c
> openjpeg/src/bin/jpip/opj_jpip_test.c
> openjpeg/src/bin/jpip/opj_jpip_transcode.c
> openjpeg/src/bin/jpip/opj_server.c
> openjpeg/src/bin/jpip/opj_viewer/dist/manifest.txt
> openjpeg/src/bin/jpip/opj_viewer/src/ImageManager.java
> openjpeg/src/bin/jpip/opj_viewer/src/ImageViewer.java
> openjpeg/src/bin/jpip/opj_viewer/src/ImageWindow.java
> openjpeg/src/bin/jpip/opj_viewer/src/ImgdecClient.java
> openjpeg/src/bin/jpip/opj_viewer/src/JPIPHttpClient.java
> openjpeg/src/bin/jpip/opj_viewer/src/MML.java
> openjpeg/src/bin/jpip/opj_viewer/src/PnmImage.java
> openjpeg/src/bin/jpip/opj_viewer/src/RegimViewer.java
> openjpeg/src/bin/jpip/opj_viewer/src/ResizeListener.java
> openjpeg/src/bin/jpip/opj_viewer_xerces/dist/manifest.txt.in
> openjpeg/src/bin/jpip/opj_viewer_xerces/src/ImageViewer.java
> openjpeg/src/bin/jpip/opj_viewer_xerces/src/ImageWindow.java
> openjpeg/src/bin/jpip/opj_viewer_xerces/src/JP2XMLparser.java
> openjpeg/src/bin/jpip/opj_viewer_xerces/src/OptionPanel.java
> openjpeg/src/bin/jpwl/CMakeLists.txt
> openjpeg/src/bin/jpwl/convert.c
> openjpeg/src/bin/jpwl/convert.h
> openjpeg/src/bin/jpwl/index.c
> openjpeg/src/bin/jpwl/index.h
> openjpeg/src/bin/jpwl/opj_jpwl_compress.c
> openjpeg/src/bin/jpwl/opj_jpwl_decompress.c
> openjpeg/src/bin/jpwl/windirent.h
> openjpeg/src/bin/mj2/CMakeLists.txt
> openjpeg/src/bin/mj2/meta_out.c
> openjpeg/src/bin/mj2/meta_out.h
> openjpeg/src/bin/mj2/mj2_to_metadata.c
> openjpeg/src/bin/mj2/mj2_to_metadata.dtd
> openjpeg/src/bin/mj2/mj2_to_metadata.h
> openjpeg/src/bin/mj2/mj2_to_metadata.sln
> openjpeg/src/bin/mj2/mj2_to_metadata.vcproj
> openjpeg/src/bin/mj2/mj2_to_metadata_Notes.doc
> openjpeg/src/bin/mj2/opj_mj2_compress.c
> openjpeg/src/bin/mj2/opj_mj2_decompress.c
> openjpeg/src/bin/mj2/opj_mj2_extract.c
> openjpeg/src/bin/mj2/opj_mj2_wrap.c
> openjpeg/src/bin/mj2/readme.txt
> openjpeg/src/bin/wx/CMakeLists.txt
> openjpeg/src/bin/wx/OPJViewer/CMakeLists.txt
> openjpeg/src/bin/wx/OPJViewer/OPJViewer.iss
> openjpeg/src/bin/wx/OPJViewer/Readme.txt
> openjpeg/src/bin/wx/OPJViewer/about/about.htm
> openjpeg/src/bin/wx/OPJViewer/about/opj_logo.png
> openjpeg/src/bin/wx/OPJViewer/source/OPJAbout.cpp
> openjpeg/src/bin/wx/OPJViewer/source/OPJChild.ico
> openjpeg/src/bin/wx/OPJViewer/source/OPJChild16.xpm
> openjpeg/src/bin/wx/OPJViewer/source/OPJDialogs.cpp
> openjpeg/src/bin/wx/OPJViewer/source/OPJThreads.cpp
> openjpeg/src/bin/wx/OPJViewer/source/OPJViewer.cpp
> openjpeg/src/bin/wx/OPJViewer/source/OPJViewer.h
> openjpeg/src/bin/wx/OPJViewer/source/OPJViewer.ico
> openjpeg/src/bin/wx/OPJViewer/source/OPJViewer.rc
> openjpeg/src/bin/wx/OPJViewer/source/OPJViewer16.xpm
> openjpeg/src/bin/wx/OPJViewer/source/about_htm.h
> openjpeg/src/bin/wx/OPJViewer/source/build.h
> openjpeg/src/bin/wx/OPJViewer/source/icon1.xpm
> openjpeg/src/bin/wx/OPJViewer/source/icon2.xpm
> openjpeg/src/bin/wx/OPJViewer/source/icon3.xpm
> openjpeg/src/bin/wx/OPJViewer/source/icon4.xpm
> openjpeg/src/bin/wx/OPJViewer/source/icon5.xpm
> openjpeg/src/bin/wx/OPJViewer/source/imagjpeg2000.cpp
> openjpeg/src/bin/wx/OPJViewer/source/imagjpeg2000.h
> openjpeg/src/bin/wx/OPJViewer/source/imagmxf.cpp
> openjpeg/src/bin/wx/OPJViewer/source/imagmxf.h
> openjpeg/src/bin/wx/OPJViewer/source/license.txt
> openjpeg/src/bin/wx/OPJViewer/source/opj_logo.xpm
> openjpeg/src/bin/wx/OPJViewer/source/readmeafter.txt
> openjpeg/src/bin/wx/OPJViewer/source/readmebefore.txt
> openjpeg/src/bin/wx/OPJViewer/source/wxj2kparser.cpp
> openjpeg/src/bin/wx/OPJViewer/source/wxjp2parser.cpp
> openjpeg/src/lib/openjp2/CMakeLists.txt
> openjpeg/src/lib/openjp2/bench_dwt.c
> openjpeg/src/lib/openjp2/dwt.c
> openjpeg/src/lib/openjp2/dwt.h
> openjpeg/src/lib/openjp2/image.c
> openjpeg/src/lib/openjp2/j2k.c
> openjpeg/src/lib/openjp2/j2k.h
> openjpeg/src/lib/openjp2/jp2.c
> openjpeg/src/lib/openjp2/jp2.h
> openjpeg/src/lib/openjp2/mct.c
> openjpeg/src/lib/openjp2/mct.h
> openjpeg/src/lib/openjp2/mqc.c
> openjpeg/src/lib/openjp2/mqc.h
> openjpeg/src/lib/openjp2/mqc_inl.h
> openjpeg/src/lib/openjp2/openjpeg.c
> openjpeg/src/lib/openjp2/openjpeg.h
> openjpeg/src/lib/openjp2/opj_codec.h
> openjpeg/src/lib/openjp2/opj_config.h
> openjpeg/src/lib/openjp2/opj_config_private.h
> openjpeg/src/lib/openjp2/opj_includes.h
> openjpeg/src/lib/openjp2/opj_intmath.h
> openjpeg/src/lib/openjp2/sparse_array.c
> openjpeg/src/lib/openjp2/sparse_array.h
> openjpeg/src/lib/openjp2/t1.c
> openjpeg/src/lib/openjp2/t1.h
> openjpeg/src/lib/openjp2/t2.c
> openjpeg/src/lib/openjp2/t2.h
> openjpeg/src/lib/openjp2/tcd.c
> openjpeg/src/lib/openjp2/tcd.h
> openjpeg/src/lib/openjp2/test_sparse_array.c
> openjpeg/src/lib/openjp2/thread.c

2018-03-27 16:26:13 +0100
Chris Liddell <chris.liddell@artifex.com>
25971c91d6433b0249d3b721b75ef704afe0a09c

> Update libjpeg to 9c
> Plus re-applying:
> Bug 697186: Workaround JPEG lib bug.
> 8dcec8cc076a0cf8350ca7a6ec1d3136812e2a24
> Bug 697186: Tweak to previous JPEG fix.
> dc62c90930512f4b571f68c9110022b234cbd411
> jpeg/Makefile.am
> jpeg/Makefile.in
> jpeg/README
> jpeg/aclocal.m4
> jpeg/ar-lib
> jpeg/cderror.h
> jpeg/change.log
> jpeg/cjpeg.1
> jpeg/compile
> jpeg/config.guess
> jpeg/config.sub
> jpeg/configure
> jpeg/configure.ac
> jpeg/depcomp
> jpeg/djpeg.1
> jpeg/djpeg.c
> jpeg/filelist.txt
> jpeg/install-sh
> jpeg/install.txt
> jpeg/jcinit.c
> jpeg/jcmaster.c
> jpeg/jconfig.vc
> jpeg/jcsample.c
> jpeg/jctrans.c
> jpeg/jdarith.c
> jpeg/jdatadst.c
> jpeg/jdatasrc.c
> jpeg/jdcolor.c
> jpeg/jdct.h
> jpeg/jdhuff.c
> jpeg/jdmainct.c
> jpeg/jdmaster.c
> jpeg/jdmerge.c
> jpeg/jdsample.c
> jpeg/jerror.c
> jpeg/jfdctflt.c
> jpeg/jfdctfst.c
> jpeg/jfdctint.c
> jpeg/jidctflt.c
> jpeg/jidctfst.c
> jpeg/jidctint.c
> jpeg/jinclude.h
> jpeg/jpegint.h
> jpeg/jpeglib.h
> jpeg/jpegtran.1
> jpeg/jversion.h
> jpeg/libjpeg.pc.in
> jpeg/ltmain.sh
> jpeg/makeasln.v15
> jpeg/makecfil.v15
> jpeg/makecvcx.v15
> jpeg/makedfil.v15
> jpeg/makedvcx.v15
> jpeg/makefile.ansi
> jpeg/makefile.b32
> jpeg/makefile.bcc
> jpeg/makefile.dj
> jpeg/makefile.manx
> jpeg/makefile.mc6
> jpeg/makefile.mms
> jpeg/makefile.sas
> jpeg/makefile.unix
> jpeg/makefile.vc
> jpeg/makefile.vs
> jpeg/makefile.wat
> jpeg/makejfil.v15
> jpeg/makejsln.v15
> jpeg/makejvcx.v15
> jpeg/makerfil.v15
> jpeg/makervcx.v15
> jpeg/maketfil.v15
> jpeg/maketvcx.v15
> jpeg/makewfil.v15
> jpeg/makewvcx.v15
> jpeg/missing
> jpeg/rdbmp.c
> jpeg/rdppm.c
> jpeg/rdswitch.c
> jpeg/rdtarga.c
> jpeg/transupp.c
> jpeg/usage.txt
> jpeg/wrbmp.c
> jpeg/wrgif.c
> jpeg/wrjpgcom.c
> jpeg/wrppm.c
> jpeg/wrrle.c
> jpeg/wrtarga.c

2018-03-27 16:16:49 +0100
Chris Liddell <chris.liddell@artifex.com>
d8a919d4b45097a527f6f39d509b920d285d709b

> Update expat to 2.2.5
> With a couple of tweaks to base/expat.mak to make it work.
> base/expat.mak
> expat/AUTHORS
> expat/CMake.README
> expat/CMakeLists.txt
> expat/COPYING
> expat/Changes
> expat/ConfigureChecks.cmake
> expat/MANIFEST
> expat/Makefile.am
> expat/Makefile.in
> expat/README
> expat/README.md
> expat/aclocal.m4
> expat/amiga/Makefile
> expat/amiga/README.txt
> expat/amiga/expat.xml
> expat/amiga/expat_68k.c
> expat/amiga/expat_68k.h
> expat/amiga/expat_68k_handler_stubs.c
> expat/amiga/expat_base.h
> expat/amiga/expat_lib.c
> expat/amiga/expat_vectors.c
> expat/amiga/include/inline4/expat.h
> expat/amiga/include/interfaces/expat.h
> expat/amiga/include/libraries/expat.h
> expat/amiga/include/proto/expat.h
> expat/amiga/launch.c
> expat/bcb5/README.txt
> expat/bcb5/all_projects.bpg
> expat/bcb5/elements.bpf
> expat/bcb5/elements.bpr
> expat/bcb5/elements.mak
> expat/bcb5/expat.bpf
> expat/bcb5/expat.bpr
> expat/bcb5/expat.mak
> expat/bcb5/expat_static.bpf
> expat/bcb5/expat_static.bpr
> expat/bcb5/expat_static.mak
> expat/bcb5/expatw.bpf
> expat/bcb5/expatw.bpr
> expat/bcb5/expatw.mak
> expat/bcb5/expatw_static.bpf
> expat/bcb5/expatw_static.bpr
> expat/bcb5/expatw_static.mak
> expat/bcb5/libexpat_mtd.def
> expat/bcb5/libexpatw_mtd.def
> expat/bcb5/makefile.mak
> expat/bcb5/outline.bpf
> expat/bcb5/outline.bpr
> expat/bcb5/outline.mak
> expat/bcb5/setup.bat
> expat/bcb5/xmlwf.bpf
> expat/bcb5/xmlwf.bpr
> expat/bcb5/xmlwf.mak
> expat/configure
> expat/configure.ac
> expat/conftools/compile
> expat/conftools/config.guess
> expat/conftools/config.sub
> expat/conftools/depcomp
> expat/conftools/get-version.sh
> expat/conftools/install-sh
> expat/conftools/missing
> expat/conftools/mkinstalldirs
> expat/conftools/test-driver
> expat/doc/Makefile.am
> expat/doc/Makefile.in
> expat/doc/reference.html
> expat/doc/xmlwf.1
> expat/doc/xmlwf.xml
> expat/examples/Makefile.am
> expat/examples/Makefile.in
> expat/examples/elements.c
> expat/examples/elements.dsp
> expat/examples/elements.vcxproj
> expat/examples/elements.vcxproj.filters
> expat/examples/outline.c
> expat/examples/outline.dsp
> expat/examples/outline.vcxproj
> expat/examples/outline.vcxproj.filters
> expat/expat.dsw
> expat/expat.sln
> expat/expat_config.h
> expat/expat_config.h.cmake
> expat/expat_config.h.in
> expat/lib/Makefile.MPW
> expat/lib/Makefile.am
> expat/lib/Makefile.in
> expat/lib/amigaconfig.h
> expat/lib/ascii.h
> expat/lib/asciitab.h
> expat/lib/expat.dsp
> expat/lib/expat.h
> expat/lib/expat.vcxproj
> expat/lib/expat.vcxproj.filters
> expat/lib/expat_external.h
> expat/lib/expat_static.dsp
> expat/lib/expat_static.vcxproj
> expat/lib/expat_static.vcxproj.filters
> expat/lib/expatw.dsp
> expat/lib/expatw.vcxproj
> expat/lib/expatw.vcxproj.filters
> expat/lib/expatw_static.dsp
> expat/lib/expatw_static.vcxproj
> expat/lib/expatw_static.vcxproj.filters
> expat/lib/iasciitab.h
> expat/lib/internal.h
> expat/lib/latin1tab.h
> expat/lib/libexpat.def
> expat/lib/libexpatw.def
> expat/lib/loadlibrary.c
> expat/lib/macconfig.h
> expat/lib/nametab.h
> expat/lib/siphash.h
> expat/lib/utf8tab.h
> expat/lib/winconfig.h
> expat/lib/xmlparse.c
> expat/lib/xmlrole.c
> expat/lib/xmlrole.h
> expat/lib/xmltok.c
> expat/lib/xmltok.h
> expat/lib/xmltok_impl.c
> expat/lib/xmltok_impl.h
> expat/lib/xmltok_ns.c
> expat/m4/libtool.m4
> expat/run.sh.in
> expat/test-driver-wrapper.sh
> expat/tests/Makefile.am
> expat/tests/Makefile.in
> expat/tests/benchmark/Makefile.am
> expat/tests/benchmark/Makefile.in
> expat/tests/benchmark/benchmark.c
> expat/tests/benchmark/benchmark.dsp
> expat/tests/benchmark/benchmark.dsw
> expat/tests/benchmark/benchmark.sln
> expat/tests/benchmark/benchmark.vcxproj
> expat/tests/chardata.c
> expat/tests/chardata.h
> expat/tests/memcheck.c
> expat/tests/memcheck.h
> expat/tests/minicheck.c
> expat/tests/minicheck.h
> expat/tests/runtests.c
> expat/tests/runtests.sln
> expat/tests/runtests.vcxproj
> expat/tests/runtests.vcxproj.filters
> expat/tests/runtestspp.cpp
> expat/tests/structdata.c
> expat/tests/structdata.h
> expat/tests/udiffer.py
> expat/tests/xmltest.log.expected
> expat/tests/xmltest.sh
> expat/vms/README.vms
> expat/vms/descrip.mms
> expat/vms/expat_config.h
> expat/win32/MANIFEST.txt
> expat/win32/README.txt
> expat/win32/expat.iss
> expat/xmlwf/Makefile.am
> expat/xmlwf/Makefile.in
> expat/xmlwf/codepage.c
> expat/xmlwf/codepage.h
> expat/xmlwf/ct.c
> expat/xmlwf/filemap.h
> expat/xmlwf/readfilemap.c
> expat/xmlwf/unixfilemap.c
> expat/xmlwf/win32filemap.c
> expat/xmlwf/xmlfile.c
> expat/xmlwf/xmlfile.h
> expat/xmlwf/xmlmime.c
> expat/xmlwf/xmlmime.h
> expat/xmlwf/xmltchar.h
> expat/xmlwf/xmlurl.h
> expat/xmlwf/xmlwf.c
> expat/xmlwf/xmlwf.dsp
> expat/xmlwf/xmlwf.vcxproj
> expat/xmlwf/xmlwf.vcxproj.filters
> expat/xmlwf/xmlwin32url.cxx

2018-03-27 14:08:47 +0100
Chris Liddell <chris.liddell@artifex.com>
003c4211a019eb5c4719860f353777e177553490

> Update libtiff to 4.0.9
> Add in portability changes to tiffiop.h
> Portability tiffiop.h
> Remove globals from tif_pixarlog.c
> Tweaks to support libtiff 4.0.9
> base/gstiffio.c
> configure.ac
> tiff/CMakeLists.txt
> tiff/ChangeLog
> tiff/HOWTO-RELEASE
> tiff/RELEASE-DATE
> tiff/VERSION
> tiff/config/ltmain.sh
> tiff/configure
> tiff/configure.ac
> tiff/html/Makefile.am
> tiff/html/Makefile.in
> tiff/html/index.html
> tiff/html/man/CMakeLists.txt
> tiff/html/man/Makefile.am
> tiff/html/man/Makefile.in
> tiff/html/man/rgb2ycbcr.1.html
> tiff/html/man/thumbnail.1.html
> tiff/html/v4.0.7.html
> tiff/html/v4.0.8.html
> tiff/html/v4.0.9.html
> tiff/libtiff/libtiff.def
> tiff/libtiff/tif_aux.c
> tiff/libtiff/tif_color.c
> tiff/libtiff/tif_dir.c
> tiff/libtiff/tif_dir.h
> tiff/libtiff/tif_dirinfo.c
> tiff/libtiff/tif_dirread.c
> tiff/libtiff/tif_dirwrite.c
> tiff/libtiff/tif_error.c
> tiff/libtiff/tif_fax3.c
> tiff/libtiff/tif_fax3.h
> tiff/libtiff/tif_getimage.c
> tiff/libtiff/tif_jbig.c
> tiff/libtiff/tif_jpeg.c
> tiff/libtiff/tif_jpeg_12.c
> tiff/libtiff/tif_luv.c
> tiff/libtiff/tif_lzw.c
> tiff/libtiff/tif_ojpeg.c
> tiff/libtiff/tif_open.c
> tiff/libtiff/tif_packbits.c
> tiff/libtiff/tif_pixarlog.c
> tiff/libtiff/tif_predict.c
> tiff/libtiff/tif_print.c
> tiff/libtiff/tif_read.c
> tiff/libtiff/tif_strip.c
> tiff/libtiff/tif_swab.c
> tiff/libtiff/tif_unix.c
> tiff/libtiff/tif_warning.c
> tiff/libtiff/tif_win32.c
> tiff/libtiff/tif_write.c
> tiff/libtiff/tif_zip.c
> tiff/libtiff/tiffio.h
> tiff/libtiff/tiffiop.h
> tiff/libtiff/tiffvers.h
> tiff/m4/libtool.m4
> tiff/man/CMakeLists.txt
> tiff/man/Makefile.am
> tiff/man/Makefile.in
> tiff/man/TIFFGetField.3tiff
> tiff/man/TIFFSetDirectory.3tiff
> tiff/man/TIFFSetField.3tiff
> tiff/man/rgb2ycbcr.1
> tiff/man/thumbnail.1
> tiff/nmake.opt
> tiff/test/CMakeLists.txt
> tiff/test/Makefile.am
> tiff/test/Makefile.in
> tiff/test/TiffTestCommon.cmake
> tiff/test/common.sh
> tiff/test/images/quad-lzw-compat.tiff
> tiff/test/tiff2bw-palette-1c-8b.sh
> tiff/test/tiff2bw-quad-lzw-compat.sh
> tiff/test/tiff2bw-rgb-3c-8b.sh
> tiff/test/tiffcp-lzw-compat.sh
> tiff/tools/fax2tiff.c
> tiff/tools/raw2tiff.c
> tiff/tools/tiff2bw.c
> tiff/tools/tiff2pdf.c
> tiff/tools/tiff2ps.c
> tiff/tools/tiffcp.c
> tiff/tools/tiffcrop.c
> tiff/tools/tiffinfo.c
> tiff/tools/tiffset.c

2018-03-26 16:12:39 +0100
Chris Liddell <chris.liddell@artifex.com>
bc817a3afdb932eadac17155834f89efd1c96da4

> Bring libpng up to 1.6.34
> base/png.mak
> libpng/ANNOUNCE
> libpng/CHANGES
> libpng/CMakeLists.txt
> libpng/INSTALL
> libpng/LICENSE
> libpng/Makefile.am
> libpng/Makefile.in
> libpng/README
> libpng/TODO
> libpng/arm/filter_neon.S
> libpng/config.h.in
> libpng/configure
> libpng/configure.ac
> libpng/contrib/arm-neon/android-ndk.c
> libpng/contrib/arm-neon/linux.c
> libpng/contrib/examples/pngtopng.c
> libpng/contrib/gregbook/README
> libpng/contrib/gregbook/readpng.c
> libpng/contrib/gregbook/readpng2.c
> libpng/contrib/gregbook/readppm.c
> libpng/contrib/gregbook/rpng-win.c
> libpng/contrib/gregbook/rpng-x.c
> libpng/contrib/gregbook/rpng2-win.c
> libpng/contrib/gregbook/rpng2-x.c
> libpng/contrib/gregbook/wpng.c
> libpng/contrib/gregbook/writepng.c
> libpng/contrib/intel/INSTALL
> libpng/contrib/intel/intel_sse.patch
> libpng/contrib/libtests/pngstest.c
> libpng/contrib/libtests/pngunknown.c
> libpng/contrib/libtests/pngvalid.c
> libpng/contrib/oss-fuzz/Dockerfile
> libpng/contrib/oss-fuzz/README.txt
> libpng/contrib/oss-fuzz/build.sh
> libpng/contrib/oss-fuzz/libpng_read_fuzzer.cc
> libpng/contrib/oss-fuzz/libpng_read_fuzzer.options
> libpng/contrib/oss-fuzz/newcc
> libpng/contrib/oss-fuzz/png.dict
> libpng/contrib/pngminus/png2pnm.c
> libpng/contrib/pngminus/pnm2png.c
> libpng/contrib/powerpc-vsx/README
> libpng/contrib/powerpc-vsx/linux.c
> libpng/contrib/powerpc-vsx/linux_aux.c
> libpng/contrib/testpngs/crashers/bad_iCCP.png
> libpng/contrib/testpngs/crashers/badadler.png
> libpng/contrib/testpngs/crashers/badcrc.png
> libpng/contrib/testpngs/crashers/empty_ancillary_chunks.png
> libpng/contrib/testpngs/crashers/huge_IDAT.png
> libpng/contrib/testpngs/crashers/huge_bKGD_chunk.png
> libpng/contrib/testpngs/crashers/huge_cHRM_chunk.png
> libpng/contrib/testpngs/crashers/huge_eXIf_chunk.png
> libpng/contrib/testpngs/crashers/huge_gAMA_chunk.png
> libpng/contrib/testpngs/crashers/huge_hIST_chunk.png
> libpng/contrib/testpngs/crashers/huge_iCCP_chunk.png
> libpng/contrib/testpngs/crashers/huge_iTXt_chunk.png
> libpng/contrib/testpngs/crashers/huge_juNK_unsafe_to_copy.png
> libpng/contrib/testpngs/crashers/huge_juNk_safe_to_copy.png
> libpng/contrib/testpngs/crashers/huge_pCAL_chunk.png
> libpng/contrib/testpngs/crashers/huge_pHYs_chunk.png
> libpng/contrib/testpngs/crashers/huge_sCAL_chunk.png
> libpng/contrib/testpngs/crashers/huge_sPLT_chunk.png
> libpng/contrib/testpngs/crashers/huge_sRGB_chunk.png
> libpng/contrib/testpngs/crashers/huge_sTER_chunk.png
> libpng/contrib/testpngs/crashers/huge_tEXt_chunk.png
> libpng/contrib/testpngs/crashers/huge_tIME_chunk.png
> libpng/contrib/testpngs/crashers/huge_zTXt_chunk.png
> libpng/contrib/testpngs/gray-1-1.8-tRNS.png
> libpng/contrib/testpngs/gray-1-1.8.png
> libpng/contrib/testpngs/gray-1-linear-tRNS.png
> libpng/contrib/testpngs/gray-1-linear.png
> libpng/contrib/testpngs/gray-1-sRGB-tRNS.png
> libpng/contrib/testpngs/gray-1-sRGB.png
> libpng/contrib/testpngs/gray-1-tRNS.png
> libpng/contrib/testpngs/gray-1.png
> libpng/contrib/testpngs/gray-16-1.8-tRNS.png
> libpng/contrib/testpngs/gray-16-1.8.png
> libpng/contrib/testpngs/gray-16-linear-tRNS.png
> libpng/contrib/testpngs/gray-16-linear.png
> libpng/contrib/testpngs/gray-16-sRGB-tRNS.png
> libpng/contrib/testpngs/gray-16-sRGB.png
> libpng/contrib/testpngs/gray-16-tRNS.png
> libpng/contrib/testpngs/gray-16.png
> libpng/contrib/testpngs/gray-2-1.8-tRNS.png
> libpng/contrib/testpngs/gray-2-1.8.png
> libpng/contrib/testpngs/gray-2-linear-tRNS.png
> libpng/contrib/testpngs/gray-2-linear.png
> libpng/contrib/testpngs/gray-2-sRGB-tRNS.png
> libpng/contrib/testpngs/gray-2-sRGB.png
> libpng/contrib/testpngs/gray-2-tRNS.png
> libpng/contrib/testpngs/gray-2.png
> libpng/contrib/testpngs/gray-4-1.8-tRNS.png
> libpng/contrib/testpngs/gray-4-1.8.png
> libpng/contrib/testpngs/gray-4-linear-tRNS.png
> libpng/contrib/testpngs/gray-4-linear.png
> libpng/contrib/testpngs/gray-4-sRGB-tRNS.png
> libpng/contrib/testpngs/gray-4-sRGB.png
> libpng/contrib/testpngs/gray-4-tRNS.png
> libpng/contrib/testpngs/gray-4.png
> libpng/contrib/testpngs/gray-8-1.8-tRNS.png
> libpng/contrib/testpngs/gray-8-1.8.png
> libpng/contrib/testpngs/gray-8-linear-tRNS.png
> libpng/contrib/testpngs/gray-8-linear.png
> libpng/contrib/testpngs/gray-8-sRGB-tRNS.png
> libpng/contrib/testpngs/gray-8-sRGB.png
> libpng/contrib/testpngs/gray-8-tRNS.png
> libpng/contrib/testpngs/gray-8.png
> libpng/contrib/testpngs/gray-alpha-16-1.8.png
> libpng/contrib/testpngs/gray-alpha-16-linear.png
> libpng/contrib/testpngs/gray-alpha-16-sRGB.png
> libpng/contrib/testpngs/gray-alpha-16.png
> libpng/contrib/testpngs/gray-alpha-8-1.8.png
> libpng/contrib/testpngs/gray-alpha-8-linear.png
> libpng/contrib/testpngs/gray-alpha-8-sRGB.png
> libpng/contrib/testpngs/gray-alpha-8.png
> libpng/contrib/testpngs/makepngs.sh
> libpng/contrib/testpngs/palette-1-1.8-tRNS.png
> libpng/contrib/testpngs/palette-1-1.8.png
> libpng/contrib/testpngs/palette-1-linear-tRNS.png
> libpng/contrib/testpngs/palette-1-linear.png
> libpng/contrib/testpngs/palette-1-sRGB-tRNS.png
> libpng/contrib/testpngs/palette-1-sRGB.png
> libpng/contrib/testpngs/palette-1-tRNS.png
> libpng/contrib/testpngs/palette-1.png
> libpng/contrib/testpngs/palette-2-1.8-tRNS.png
> libpng/contrib/testpngs/palette-2-1.8.png
> libpng/contrib/testpngs/palette-2-linear-tRNS.png
> libpng/contrib/testpngs/palette-2-linear.png
> libpng/contrib/testpngs/palette-2-sRGB-tRNS.png
> libpng/contrib/testpngs/palette-2-sRGB.png
> libpng/contrib/testpngs/palette-2-tRNS.png
> libpng/contrib/testpngs/palette-2.png
> libpng/contrib/testpngs/palette-4-1.8-tRNS.png
> libpng/contrib/testpngs/palette-4-1.8.png
> libpng/contrib/testpngs/palette-4-linear-tRNS.png
> libpng/contrib/testpngs/palette-4-linear.png
> libpng/contrib/testpngs/palette-4-sRGB-tRNS.png
> libpng/contrib/testpngs/palette-4-sRGB.png
> libpng/contrib/testpngs/palette-4-tRNS.png
> libpng/contrib/testpngs/palette-4.png
> libpng/contrib/testpngs/palette-8-1.8-tRNS.png
> libpng/contrib/testpngs/palette-8-1.8.png
> libpng/contrib/testpngs/palette-8-linear-tRNS.png
> libpng/contrib/testpngs/palette-8-linear.png
> libpng/contrib/testpngs/palette-8-sRGB-tRNS.png
> libpng/contrib/testpngs/palette-8-sRGB.png
> libpng/contrib/testpngs/palette-8-tRNS.png
> libpng/contrib/testpngs/palette-8.png
> libpng/contrib/testpngs/rgb-16-1.8-tRNS.png
> libpng/contrib/testpngs/rgb-16-1.8.png
> libpng/contrib/testpngs/rgb-16-linear-tRNS.png
> libpng/contrib/testpngs/rgb-16-linear.png
> libpng/contrib/testpngs/rgb-16-sRGB-tRNS.png
> libpng/contrib/testpngs/rgb-16-sRGB.png
> libpng/contrib/testpngs/rgb-16-tRNS.png
> libpng/contrib/testpngs/rgb-16.png
> libpng/contrib/testpngs/rgb-8-1.8-tRNS.png
> libpng/contrib/testpngs/rgb-8-1.8.png
> libpng/contrib/testpngs/rgb-8-linear-tRNS.png
> libpng/contrib/testpngs/rgb-8-linear.png
> libpng/contrib/testpngs/rgb-8-sRGB-tRNS.png
> libpng/contrib/testpngs/rgb-8-sRGB.png
> libpng/contrib/testpngs/rgb-8-tRNS.png
> libpng/contrib/testpngs/rgb-8.png
> libpng/contrib/testpngs/rgb-alpha-16-1.8.png
> libpng/contrib/testpngs/rgb-alpha-16-linear.png
> libpng/contrib/testpngs/rgb-alpha-16-sRGB.png
> libpng/contrib/testpngs/rgb-alpha-16.png
> libpng/contrib/testpngs/rgb-alpha-8-1.8.png
> libpng/contrib/testpngs/rgb-alpha-8-linear.png
> libpng/contrib/testpngs/rgb-alpha-8-sRGB.png
> libpng/contrib/testpngs/rgb-alpha-8.png
> libpng/contrib/tools/genpng.c
> libpng/contrib/tools/pngfix.c
> libpng/contrib/tools/sRGB.h
> libpng/contrib/visupng/PngFile.c
> libpng/contrib/visupng/VisualPng.c
> libpng/example.c
> libpng/intel/filter_sse2_intrinsics.c
> libpng/intel/intel_init.c
> libpng/libpng-manual.txt
> libpng/libpng.3
> libpng/libpng.pc.in
> libpng/libpngpf.3
> libpng/ltmain.sh
> libpng/mips/filter_msa_intrinsics.c
> libpng/mips/mips_init.c
> libpng/png.5
> libpng/png.c
> libpng/png.h
> libpng/pngconf.h
> libpng/pngerror.c
> libpng/pngget.c
> libpng/pnginfo.h
> libpng/pngpread.c
> libpng/pngpriv.h
> libpng/pngread.c
> libpng/pngrtran.c
> libpng/pngrutil.c
> libpng/pngset.c
> libpng/pngstruct.h
> libpng/pngtest.c
> libpng/pngtest.png
> libpng/pngtrans.c
> libpng/pngwrite.c
> libpng/pngwutil.c
> libpng/powerpc/filter_vsx_intrinsics.c
> libpng/powerpc/powerpc_init.c
> libpng/projects/owatcom/pngconfig.mak
> libpng/projects/vstudio/README.txt
> libpng/projects/vstudio/zlib.props
> libpng/scripts/README.txt
> libpng/scripts/def.c
> libpng/scripts/libpng-config-head.in
> libpng/scripts/libpng.pc.in
> libpng/scripts/makefile.cegcc
> libpng/scripts/makefile.linux
> libpng/scripts/makefile.linux-opt
> libpng/scripts/makefile.msys
> libpng/scripts/makefile.ne12bsd
> libpng/scripts/makefile.netbsd
> libpng/scripts/makefile.openbsd
> libpng/scripts/makefile.solaris-x86
> libpng/scripts/pnglibconf.dfa
> libpng/scripts/pnglibconf.h.prebuilt
> libpng/scripts/symbols.def
> libpng/tests/pngimage-full
> libpng/tests/pngimage-quick
> libpng/tests/pngstest
> libpng/tests/pngstest-1.8
> libpng/tests/pngstest-1.8-alpha
> libpng/tests/pngstest-linear
> libpng/tests/pngstest-linear-alpha
> libpng/tests/pngstest-none
> libpng/tests/pngstest-none-alpha
> libpng/tests/pngstest-sRGB
> libpng/tests/pngstest-sRGB-alpha
> libpng/tests/pngtest
> libpng/tests/pngtest-badpngs
> libpng/tests/pngunknown-IDAT
> libpng/tests/pngunknown-discard
> libpng/tests/pngunknown-if-safe
> libpng/tests/pngunknown-sAPI
> libpng/tests/pngunknown-sTER
> libpng/tests/pngunknown-save
> libpng/tests/pngunknown-vpAg
> libpng/tests/pngvalid-gamma-16-to-8
> libpng/tests/pngvalid-gamma-alpha-mode
> libpng/tests/pngvalid-gamma-background
> libpng/tests/pngvalid-gamma-expand16-alpha-mode
> libpng/tests/pngvalid-gamma-expand16-background
> libpng/tests/pngvalid-gamma-expand16-transform
> libpng/tests/pngvalid-gamma-sbit
> libpng/tests/pngvalid-gamma-threshold
> libpng/tests/pngvalid-gamma-transform
> libpng/tests/pngvalid-progressive-interlace-standard
> libpng/tests/pngvalid-progressive-size
> libpng/tests/pngvalid-progressive-standard
> libpng/tests/pngvalid-standard
> libpng/tests/pngvalid-transform

2018-03-27 13:47:02 +0100
Chris Liddell <chris.liddell@artifex.com>
0a4ef8b01c2ea146b9dce7b80f21f6cd65420099

> Remove symlink from docs install.
> For 9.23 we moved the default installation path for the documentation to better
> fit with "modern" Linux/Unix directory layouts. To minimize upheaval, we
> included a symlink to the "old"style path.
> Remove that now, as it was only a temporary thing.
> base/unixinst.mak

2018-03-27 10:43:29 +0100
Chris Liddell <chris.liddell@artifex.com>
3de8ff9bc31edb60370e7275a7c35b557737cd84

> Improve the configure check for "restrict" keyword
> configure.ac

2018-03-29 12:41:37 +0200
Tor Andersson <tor.andersson@artifex.com>
5249489366cfac73e83e529bae06a08ad6703980

> Clean up the stdint configuration mess.
> Don't require HAVE_STDINT_H to be defined to assume the sane default of
> including the C standard stdint.h header file.
> Use the configuration defines to include non-standard header files.
> VS 2012 and newer have stdint.h, so use it.
> jbig2dec/config_win32.h
> jbig2dec/os_types.h

2018-03-29 12:59:58 +0200
Tor Andersson <tor.andersson@artifex.com>
0cb8374113ae2770464b6ac7462f11f0cc9677ea

> Fix undeclared function warning.
> jbig2dec/jbig2_image_png.c

2018-03-29 12:56:07 +0200
Tor Andersson <tor.andersson@artifex.com>
a8430e881971485fa4a824a3488f79b7ab0abfeb

> Fix signed/unsigned comparison warnings.
> jbig2dec/Makefile.unix
> jbig2dec/jbig2_huffman.c
> jbig2dec/jbig2_image_png.c
> jbig2dec/jbig2_mmr.c

2017-05-19 12:49:15 +0200
Tor Andersson <tor.andersson@artifex.com>
15f72a0b272e751ce7147bb0d8179eac68da52b0

> xps: Remove needless NULL terminator when parsing abbreviated geometry.
> xps/xpspath.c

2018-03-27 21:21:38 -0700
Ray Johnston <ray.johnston@artifex.com>
59d82e831e62bdf2e44331d10c88dd7837429dad

> Rename lcms2art to lcms2mt, Remove cmsChangeBuffersFormat
> Since cmsChangeBuffersFormat is NOT threadsafe, we want it to remove it
> so that it would not be part of this package which is inteded for multi-
> threaded used. The internal use in CreateNamedColorDevicelink was replaced
> with the appropriate code from the removed function, but that does not
> cause a thread safety issue since the link returned is new and not shared
> when the buffer formatters are changed.
> Note: All internal references to lcms2art are replaced with lcms2mt
> Makefile.in
> base/gsicc_lcms2mt.c
> base/lcms2mt.mak
> base/lib.mak
> base/msvclib.mak
> base/openvms.mak
> base/ugcclib.mak
> base/unix-gcc.mak
> base/unixansi.mak
> base/winlib.mak
> configure.ac
> lcms2art/include/Makefile.am
> lcms2mt/.travis.yml
> lcms2mt/AUTHORS
> lcms2mt/COPYING
> lcms2mt/ChangeLog
> lcms2mt/INSTALL
> lcms2mt/Lib/BC/BC.txt
> lcms2mt/Lib/MS/MS.TXT
> lcms2mt/Makefile.am
> lcms2mt/Makefile.in
> lcms2mt/Projects/.gitignore
> lcms2mt/Projects/BorlandC_5.5/lcms2.rc
> lcms2mt/Projects/BorlandC_5.5/lcmsdll.lk
> lcms2mt/Projects/BorlandC_5.5/lcmsdll.lst
> lcms2mt/Projects/BorlandC_5.5/mklcmsdll.bat
> lcms2mt/Projects/VC2010/jpegicc/jpegicc.vcxproj
> lcms2mt/Projects/VC2010/jpegicc/jpegicc.vcxproj.filters
> lcms2mt/Projects/VC2010/linkicc/linkicc.vcxproj
> lcms2mt/Projects/VC2010/linkicc/linkicc.vcxproj.filters
> lcms2mt/Projects/VC2010/psicc/psicc.vcxproj
> lcms2mt/Projects/VC2010/psicc/psicc.vcxproj.filters
> lcms2mt/Projects/VC2010/resource.h
> lcms2mt/Projects/VC2010/testbed/testbed.vcxproj
> lcms2mt/Projects/VC2010/testbed/testbed.vcxproj.filters
> lcms2mt/Projects/VC2010/tiffdiff/tiffdiff.vcxproj
> lcms2mt/Projects/VC2010/tiffdiff/tiffdiff.vcxproj.filters
> lcms2mt/Projects/VC2010/tifficc/tifficc.vcxproj
> lcms2mt/Projects/VC2010/tifficc/tifficc.vcxproj.filters
> lcms2mt/Projects/VC2010/transicc/transicc.vcxproj
> lcms2mt/Projects/VC2010/transicc/transicc.vcxproj.filters
> lcms2mt/Projects/VC2012/jpegicc/jpegicc.vcxproj
> lcms2mt/Projects/VC2012/jpegicc/jpegicc.vcxproj.filters
> lcms2mt/Projects/VC2012/lcms2mt.rc
> lcms2mt/Projects/VC2012/lcms2mt.sln
> lcms2mt/Projects/VC2012/lcms2mt_DLL/lcms2mt_DLL.vcxproj
> lcms2mt/Projects/VC2012/lcms2mt_DLL/lcms2mt_DLL.vcxproj.filters
> lcms2mt/Projects/VC2012/lcms2mt_static/lcms2mt_static.vcxproj
> lcms2mt/Projects/VC2012/lcms2mt_static/lcms2mt_static.vcxproj.filters
> lcms2mt/Projects/VC2012/linkicc/linkicc.vcxproj
> lcms2mt/Projects/VC2012/linkicc/linkicc.vcxproj.filters
> lcms2mt/Projects/VC2012/psicc/psicc.vcxproj
> lcms2mt/Projects/VC2012/psicc/psicc.vcxproj.filters
> lcms2mt/Projects/VC2012/resource.h
> lcms2mt/Projects/VC2012/testbed/testbed.vcxproj
> lcms2mt/Projects/VC2012/testbed/testbed.vcxproj.filters
> lcms2mt/Projects/VC2012/tiffdiff/tiffdiff.vcxproj
> lcms2mt/Projects/VC2012/tiffdiff/tiffdiff.vcxproj.filters
> lcms2mt/Projects/VC2012/tifficc/tifficc.vcxproj
> lcms2mt/Projects/VC2012/tifficc/tifficc.vcxproj.filters
> lcms2mt/Projects/VC2012/transicc/transicc.vcxproj
> lcms2mt/Projects/VC2012/transicc/transicc.vcxproj.filters
> lcms2mt/Projects/VC2013/jpegicc/jpegicc.vcxproj
> lcms2mt/Projects/VC2013/jpegicc/jpegicc.vcxproj.filters
> lcms2mt/Projects/VC2013/lcms2mt.rc
> lcms2mt/Projects/VC2013/lcms2mt.sln
> lcms2mt/Projects/VC2013/lcms2mt_DLL/lcms2mt_DLL.vcxproj
> lcms2mt/Projects/VC2013/lcms2mt_DLL/lcms2mt_DLL.vcxproj.filters
> lcms2mt/Projects/VC2013/lcms2mt_static/lcms2mt_static.vcxproj
> lcms2mt/Projects/VC2013/lcms2mt_static/lcms2mt_static.vcxproj.filters
> lcms2mt/Projects/VC2013/linkicc/linkicc.vcxproj
> lcms2mt/Projects/VC2013/linkicc/linkicc.vcxproj.filters
> lcms2mt/Projects/VC2013/psicc/psicc.vcxproj
> lcms2mt/Projects/VC2013/psicc/psicc.vcxproj.filters
> lcms2mt/Projects/VC2013/resource.h
> lcms2mt/Projects/VC2013/testbed/testbed.vcxproj
> lcms2mt/Projects/VC2013/testbed/testbed.vcxproj.filters
> lcms2mt/Projects/VC2013/tiffdiff/tiffdiff.vcxproj
> lcms2mt/Projects/VC2013/tiffdiff/tiffdiff.vcxproj.filters
> lcms2mt/Projects/VC2013/tifficc/tifficc.vcxproj
> lcms2mt/Projects/VC2013/tifficc/tifficc.vcxproj.filters
> lcms2mt/Projects/VC2013/transicc/transicc.vcxproj
> lcms2mt/Projects/VC2013/transicc/transicc.vcxproj.filters
> lcms2mt/Projects/VC2015/jpegicc/jpegicc.vcxproj
> lcms2mt/Projects/VC2015/jpegicc/jpegicc.vcxproj.filters
> lcms2mt/Projects/VC2015/lcms2mt.rc
> lcms2mt/Projects/VC2015/lcms2mt.sln
> lcms2mt/Projects/VC2015/lcms2mt_DLL/lcms2mt_DLL.vcxproj
> lcms2mt/Projects/VC2015/lcms2mt_DLL/lcms2mt_DLL.vcxproj.filters
> lcms2mt/Projects/VC2015/lcms2mt_static/lcms2mt_static.vcxproj
> lcms2mt/Projects/VC2015/lcms2mt_static/lcms2mt_static.vcxproj.filters
> lcms2mt/Projects/VC2015/linkicc/linkicc.vcxproj
> lcms2mt/Projects/VC2015/linkicc/linkicc.vcxproj.filters
> lcms2mt/Projects/VC2015/psicc/psicc.vcxproj
> lcms2mt/Projects/VC2015/psicc/psicc.vcxproj.filters
> lcms2mt/Projects/VC2015/resource.h
> lcms2mt/Projects/VC2015/testbed/testbed.vcxproj
> lcms2mt/Projects/VC2015/testbed/testbed.vcxproj.filters
> lcms2mt/Projects/VC2015/tiffdiff/tiffdiff.vcxproj
> lcms2mt/Projects/VC2015/tiffdiff/tiffdiff.vcxproj.filters
> lcms2mt/Projects/VC2015/tifficc/tifficc.vcxproj
> lcms2mt/Projects/VC2015/tifficc/tifficc.vcxproj.filters
> lcms2mt/Projects/VC2015/transicc/transicc.vcxproj
> lcms2mt/Projects/VC2015/transicc/transicc.vcxproj.filters
> lcms2mt/Projects/VC2017/jpegicc/jpegicc.vcxproj
> lcms2mt/Projects/VC2017/jpegicc/jpegicc.vcxproj.filters
> lcms2mt/Projects/VC2017/lcms2mt.rc
> lcms2mt/Projects/VC2017/lcms2mt.sln
> lcms2mt/Projects/VC2017/lcms2mt_DLL/lcms2mt_DLL.vcxproj
> lcms2mt/Projects/VC2017/lcms2mt_DLL/lcms2mt_DLL.vcxproj.filters
> lcms2mt/Projects/VC2017/lcms2mt_static/lcms2mt_static.vcxproj
> lcms2mt/Projects/VC2017/lcms2mt_static/lcms2mt_static.vcxproj.filters
> lcms2mt/Projects/VC2017/linkicc/linkicc.vcxproj
> lcms2mt/Projects/VC2017/linkicc/linkicc.vcxproj.filters
> lcms2mt/Projects/VC2017/psicc/psicc.vcxproj
> lcms2mt/Projects/VC2017/psicc/psicc.vcxproj.filters
> lcms2mt/Projects/VC2017/resource.h
> lcms2mt/Projects/VC2017/testbed/testbed.vcxproj
> lcms2mt/Projects/VC2017/testbed/testbed.vcxproj.filters
> lcms2mt/Projects/VC2017/tiffdiff/tiffdiff.vcxproj
> lcms2mt/Projects/VC2017/tiffdiff/tiffdiff.vcxproj.filters
> lcms2mt/Projects/VC2017/tifficc/tifficc.vcxproj
> lcms2mt/Projects/VC2017/tifficc/tifficc.vcxproj.filters
> lcms2mt/Projects/VC2017/transicc/transicc.vcxproj
> lcms2mt/Projects/VC2017/transicc/transicc.vcxproj.filters
> lcms2mt/Projects/cppcheck/lcms2.cppcheck
> lcms2mt/Projects/mac/LittleCMS/._Info.plist
> lcms2mt/Projects/mac/LittleCMS/._LittleCMS.xcodeproj
> lcms2mt/Projects/mac/LittleCMS/English.lproj/InfoPlist.strings
> lcms2mt/Projects/mac/LittleCMS/Info.plist
> lcms2mt/Projects/mac/LittleCMS/LittleCMS.xcodeproj/mariama.mode1v3
> lcms2mt/Projects/mac/LittleCMS/LittleCMS.xcodeproj/mariama.pbxuser
> lcms2mt/Projects/mac/LittleCMS/LittleCMS.xcodeproj/project.pbxproj
> lcms2mt/Projects/mac/LittleCMS/LittleCMS.xcodeproj/project.xcworkspace/contents.xcworkspacedata
> lcms2mt/Projects/mac/LittleCMS/LittleCMS.xcodeproj/project.xcworkspace/xcuserdata/User.xcuserdatad/UserInterfaceState.xcuserstate
> lcms2mt/Projects/mac/LittleCMS/LittleCMS.xcodeproj/project.xcworkspace/xcuserdata/User.xcuserdatad/WorkspaceSettings.xcsettings
> lcms2mt/Projects/mac/LittleCMS/LittleCMS.xcodeproj/xcuserdata/User.xcuserdatad/xcdebugger/Breakpoints.xcbkptlist
> lcms2mt/Projects/mac/LittleCMS/LittleCMS.xcodeproj/xcuserdata/User.xcuserdatad/xcschemes/LittleCMS.xcscheme
> lcms2mt/Projects/mac/LittleCMS/LittleCMS.xcodeproj/xcuserdata/User.xcuserdatad/xcschemes/testbed.xcscheme
> lcms2mt/Projects/mac/LittleCMS/LittleCMS.xcodeproj/xcuserdata/User.xcuserdatad/xcschemes/xcschememanagement.plist
> lcms2mt/Projects/mac/LittleCMS/LittleCMS_Prefix.pch
> lcms2mt/Projects/mac/LittleCMS/TestBed-Info.plist
> lcms2mt/README.1ST
> lcms2mt/aclocal.m4
> lcms2mt/autogen.sh
> lcms2mt/compile
> lcms2mt/config.guess
> lcms2mt/config.sub
> lcms2mt/configure
> lcms2mt/configure.ac
> lcms2mt/depcomp
> lcms2mt/doc/LittleCMS2.9 API.pdf
> lcms2mt/doc/LittleCMS2.9 Plugin API.pdf
> lcms2mt/doc/LittleCMS2.9 tutorial.pdf
> lcms2mt/doc/WhyThisFork.txt
> lcms2mt/doc/src.zip
> lcms2mt/include/Makefile.am
> lcms2mt/include/Makefile.in
> lcms2mt/include/lcms2mt.h
> lcms2mt/include/lcms2mt_plugin.h
> lcms2mt/install-sh
> lcms2mt/lcms2mt.pc.in
> lcms2mt/ltmain.sh
> lcms2mt/m4/acx_pthread.m4
> lcms2mt/m4/ax_append_compile_flags.m4
> lcms2mt/m4/ax_append_flag.m4
> lcms2mt/m4/ax_check_compile_flag.m4
> lcms2mt/m4/ax_gcc_func_attribute.m4
> lcms2mt/m4/ax_require_defined.m4
> lcms2mt/m4/libtool.m4
> lcms2mt/m4/ltoptions.m4
> lcms2mt/m4/ltsugar.m4
> lcms2mt/m4/ltversion.m4
> lcms2mt/m4/lt~obsolete.m4
> lcms2mt/missing
> lcms2mt/src/Makefile.am
> lcms2mt/src/Makefile.in
> lcms2mt/src/cmsalpha.c
> lcms2mt/src/cmscam02.c
> lcms2mt/src/cmscgats.c
> lcms2mt/src/cmscnvrt.c
> lcms2mt/src/cmserr.c
> lcms2mt/src/cmsgamma.c
> lcms2mt/src/cmsgmt.c
> lcms2mt/src/cmshalf.c
> lcms2mt/src/cmsintrp.c
> lcms2mt/src/cmsio0.c
> lcms2mt/src/cmsio1.c
> lcms2mt/src/cmslut.c
> lcms2mt/src/cmsmd5.c
> lcms2mt/src/cmsmtrx.c
> lcms2mt/src/cmsnamed.c
> lcms2mt/src/cmsopt.c
> lcms2mt/src/cmspack.c
> lcms2mt/src/cmspcs.c
> lcms2mt/src/cmsplugin.c
> lcms2mt/src/cmsps2.c
> lcms2mt/src/cmssamp.c
> lcms2mt/src/cmssm.c
> lcms2mt/src/cmstypes.c
> lcms2mt/src/cmsvirt.c
> lcms2mt/src/cmswtpnt.c
> lcms2mt/src/cmsxform.c
> lcms2mt/src/extra_xform.h
> lcms2mt/src/lcms2_internal.h
> lcms2mt/src/lcms2mt.def
> lcms2mt/testbed/Makefile.am
> lcms2mt/testbed/Makefile.in
> lcms2mt/testbed/bad.icc
> lcms2mt/testbed/bad_mpe.icc
> lcms2mt/testbed/crayons.icc
> lcms2mt/testbed/ibm-t61.icc
> lcms2mt/testbed/new.icc
> lcms2mt/testbed/test1.icc
> lcms2mt/testbed/test2.icc
> lcms2mt/testbed/test3.icc
> lcms2mt/testbed/test4.icc
> lcms2mt/testbed/test5.icc
> lcms2mt/testbed/testcms2.c
> lcms2mt/testbed/testcms2.h
> lcms2mt/testbed/testplugin.c
> lcms2mt/testbed/testthread.cpp
> lcms2mt/testbed/toosmall.icc
> lcms2mt/testbed/zoo_icc.c
> lcms2mt/utils/common/utils.h
> lcms2mt/utils/common/vprf.c
> lcms2mt/utils/common/xgetopt.c
> lcms2mt/utils/delphi/delphidemo.dpr
> lcms2mt/utils/delphi/delphidemo.dproj
> lcms2mt/utils/delphi/delphidemo.res
> lcms2mt/utils/delphi/demo1.dfm
> lcms2mt/utils/delphi/demo1.pas
> lcms2mt/utils/delphi/lcms2dll.pas
> lcms2mt/utils/jpgicc/LICENSE_iccjpeg
> lcms2mt/utils/jpgicc/Makefile.am
> lcms2mt/utils/jpgicc/Makefile.in
> lcms2mt/utils/jpgicc/iccjpeg.c
> lcms2mt/utils/jpgicc/iccjpeg.h
> lcms2mt/utils/jpgicc/jpgicc.1
> lcms2mt/utils/jpgicc/jpgicc.c
> lcms2mt/utils/linkicc/Makefile.am
> lcms2mt/utils/linkicc/Makefile.in
> lcms2mt/utils/linkicc/linkicc.1
> lcms2mt/utils/linkicc/linkicc.c
> lcms2mt/utils/matlab/icctrans.c
> lcms2mt/utils/matlab/lcms_rsp
> lcms2mt/utils/psicc/Makefile.am
> lcms2mt/utils/psicc/Makefile.in
> lcms2mt/utils/psicc/psicc.1
> lcms2mt/utils/psicc/psicc.c
> lcms2mt/utils/samples/Makefile.am
> lcms2mt/utils/samples/Makefile.in
> lcms2mt/utils/samples/itufax.c
> lcms2mt/utils/samples/mkcmy.c
> lcms2mt/utils/samples/mkgrayer.c
> lcms2mt/utils/samples/mktiff8.c
> lcms2mt/utils/samples/roundtrip.c
> lcms2mt/utils/samples/vericc.c
> lcms2mt/utils/samples/wtpt.1
> lcms2mt/utils/samples/wtpt.c
> lcms2mt/utils/tificc/Makefile.am
> lcms2mt/utils/tificc/Makefile.in
> lcms2mt/utils/tificc/tifdiff.c
> lcms2mt/utils/tificc/tificc.1
> lcms2mt/utils/tificc/tificc.c
> lcms2mt/utils/transicc/Makefile.am
> lcms2mt/utils/transicc/Makefile.in
> lcms2mt/utils/transicc/transicc.1
> lcms2mt/utils/transicc/transicc.c
> psi/msvc.mak
> psi/os2.mak
> windows/ghostscript.vcproj
> windows/ghostscript_rt.vcxproj

2018-02-16 13:51:04 -0800
Ray Johnston <ray.johnston@artifex.com>
9ff6b34e461fcbd4ef27fbb6c5c8a15071fe1370

> Make ICC profile management thread safe.
> The change to ref_count of profiles needs to be protected by a lock if
> the profile ref_count could be changed by another thread. Also when
> decrementing the ref_count to 0, we cannot free the lock until after
> the profile has been unlocked.
> New routine gsicc_adjust_profile_rc replaces old (not threadsafe) function
> gsicc_profile_reference.
> Also add tracing "cname" to the RC_ADJUST_ macro to aid in debugging
> with -Z^ debug flag.
> Testing had revealed race conditions which are now fixed (eliminate use
> of semaphores).
> This also changes the gsicc_lcms2art.c interface functions to keep a
> list of transforms configured to have differing buffer formats that
> include alpha, planar IN/OUT, big_endian IN/OUT, bytes_per_component
> IN/OUT which are cloned as needed by threads.
> Change gscms_is_threadsafe to return "true" in gsicc_lcms2art.c
> TBD: If a link fails to build a thread may hang waiting for the link
> profile to become valid if it was not the thread that was building it.
> Not a new condition, but exposed when gscms_is_threadsafe returns true.
> TBD: Fix error handling / clean-up when links fail to build. Also not
> new, but is needed to prevent leaks, and possibly hang conditions.
> base/gdevp14.c
> base/gscdevn.c
> base/gscie.c
> base/gscms.h
> base/gscscie.c
> base/gscspace.c
> base/gsicc.c
> base/gsicc_cache.c
> base/gsicc_lcms2art.c
> base/gsicc_manage.c
> base/gsicc_manage.h
> base/gsicc_monitorcm.c
> base/gsicc_nocm.c
> base/gsicc_replacecm.c
> base/gsmemory.c
> base/gsrefct.h
> base/gstrans.c
> base/gxclist.c
> base/gxclrast.c
> base/gxcmap.c
> base/gxipixel.c
> base/lib.mak
> lcms2art/include/lcms2art.h
> lcms2art/src/cmsxform.c
> lcms2art/src/lcms2art.def
> xps/xpscolor.c
> xps/xpsimage.c
> xps/xpstile.c

2018-03-28 15:24:32 +0100
Ken Sharp <ken.sharp@artifex.com>
33701ac07115cb2f634a40ab73a5c127ca870ad8

> Correctly set the 'encoding' to none when we apply UTF-8
> Bug 699156 " Cyrillic file names"
> On Windows GhostXPS, GhostPCL and the windowed executable (gswinxx.exe)
> were not setting the 'encoding' or were setting it to an incorrect
> 'local' encoding.
> This led to us incorrectly decoding UTF-8 encoded arguments, in
> particular the input filename, which caused ioerrors to result.
> pcl/pl/plmain.c
> psi/dwmain.c

2018-03-26 20:55:39 +0100
Chris Liddell <chris.liddell@artifex.com>
b24a4bd9bab156443c4667d4266e3deb43f933f7

> Bug 699141(redux): use "restrict" on compatible compilers
> The definition of gs_restrict was missing for C99 compilers.
> Even with compilers that claim C99 compatibility, we honor the configure check
> for restrict.
> base/stdpre.h

2018-03-26 14:56:37 +0100
Chris Liddell <chris.liddell@artifex.com>
12d2e6e44c4ed919bd38f2a13314f4942decd610

> Bug 699154: Fix conditional parenthesis in gstype42.c
> base/gstype42.c

2018-03-26 14:35:09 +0100
Chris Liddell <chris.liddell@artifex.com>
8ec5c5ded5fc19cabd95dad385b22a506e59acaf

> zfapi.c: another case of is_glyph_index set wrongly
> This is related to freetype now a) automatically selecting a Unicode cmap for
> every font, if one is available, and b) automatically generating a Unicode cmap
> for every font when one is not available.
> Logic that we had pushed down to the FAPI/FT interface layer, we now need to
> apply earlier.
> psi/zfapi.c

2018-03-26 09:21:53 +0100
Chris Liddell <chris.liddell@artifex.com>
6e4ac5e7f1e8ea1835a99f12a7a4e34ebd85261e

> Bug 699141: add configure test for __restrict in compiler
> It seems that some older compilers that claim to support __restrict really don't
> and compilation fails, so check for that in configure.
> base/stdpre.h
> configure.ac

2018-03-16 14:49:28 +0000
Chris Liddell <chris.liddell@artifex.com>
145c288cc0b1038b14334b92d40b37d27fd732b5

> Disable or fix some (benign) compiler warnings for libtiff
> base/gsjconf.h
> configure.ac
> psi/msvc.mak

2018-03-20 14:58:01 +0000
Chris Liddell <chris.liddell@artifex.com>
e3ef00ae7bd46ac4c45bf67cbb03a2342e850dca

> Fix PACIFY_VALGRIND build
> VALGRIND_HG_DISABLE_CHECKING() doesn't exist in all valgrind versions.
> pcl/pl/plmain.c

2018-03-16 14:50:22 +0000
Chris Liddell <chris.liddell@artifex.com>
fde9abbaf12c0a861dd47792e02752d6b9e6b011

> Fix a couple of unitialized variable warnings
> base/gdevdrop.c
> psi/zfont2.c

2018-03-16 14:16:38 +0000
Chris Liddell <chris.liddell@artifex.com>
99deae37f3cf32feac6eefabf17bf34a436c82ab

> Fix a "defined but not used" warning
> pcl/pcl/rtraster.c

2018-03-16 14:12:16 +0000
Chris Liddell <chris.liddell@artifex.com>
781c6a90b501a7cfcf1cdd337344444e6b388ef6

> Address some compiler warnings adding casts
> devices/gdevxalt.c

2018-03-16 14:11:42 +0000
Chris Liddell <chris.liddell@artifex.com>
9a3176cae5c0cd4fea05d2369289ec41d44cf842

> Fix a couple of unused variable warnings
> devices/gdevdsp.c

2018-03-16 14:11:04 +0000
Chris Liddell <chris.liddell@artifex.com>
465b77b4b9187e99aabad1e436d5c588fa565f97

> Squash some unitialized variable warnings
> contrib/lips4/gdevl4v.c

2018-03-16 10:19:43 +0000
Chris Liddell <chris.liddell@artifex.com>
eb770edd1c4dd9bf6c561f15564e4b8e10cc54b9

> Squash compiler warning in ijs code.
> ijs/ijs_exec_unix.c

2018-03-16 10:16:49 +0000
Chris Liddell <chris.liddell@artifex.com>
54e6bb1a12448aca3c48cd062946f564d3a9a4d1

> Address some compiler warnings in openjpeg
> configure.ac
> openjpeg/src/lib/openjp2/j2k.c
> psi/msvc.mak

2018-03-16 09:57:02 +0000
Chris Liddell <chris.liddell@artifex.com>
d411d72de4d41e0ad436c50d89088dc13e3b3f42

> Shared library compiler warnings: lcms2, openjpeg
> When linking against the system lcms2 and openjpeg there were compiler
> warnings (we don't see building "normally").
> base/gsicc_lcms2.c
> base/sjpx_openjpeg.c

2018-03-16 09:06:33 +0000
Chris Liddell <chris.liddell@artifex.com>
ee08b05dd809984df8c686231b8c8f215f5815f9

> Squash compiler warning in debug code
> base/siscale.c

2018-03-16 09:03:55 +0000
Chris Liddell <chris.liddell@artifex.com>
601e3663d23ddb49af248d539d9c90d9fcec8163

> For now, conditionally compile out unused structures
> Solves compiler warnings.
> base/gdevp14.c

2018-03-26 15:16:19 +0100
Ken Sharp <ken.sharp@artifex.com>
f13d74f60441f7f35691fd4de90476057b8535a4

> Bug #699153 - fix cppcheck warning
> Also fix two tab whitespaces, convert to spaces.
> base/gsdevice.c

2018-03-26 02:10:10 +0800
Sebastian Rasmussen <sebras@gmail.com>
41d6119463a5f013ecbe5d55d2eb707a47fdd294

> Fix 699142: Adaptive pixels can not be pixel to be predicted.
> The fix for 699127 didn't account for the adaptive pixel location
> being that of the pixel to be predicted. This is of course invalid,
> and this is now recitified.
> jbig2dec/jbig2_generic.c

2018-03-26 09:59:27 +0100
Ken Sharp <ken.sharp@artifex.com>
af2cf274d086e9140b388b7b1d92ab7753108491

> Coverity ID 26634 - add some return code checks
> base/gsstate.c

2018-03-23 08:45:39 +0000
Chris Liddell <chris.liddell@artifex.com>
1a3fdb0a05b50a5ddff2d5d566979708ff350ffa

> Add another missing file to the documentation install list
> I'd missed off the example device source file.
> base/unixinst.mak

2018-03-07 09:59:55 +0000
Chris Liddell <chris.liddell@artifex.com>
59b5259ffa6155c3c9341a268310e3879e96d441

> Bring master up to date with 9.23 release branch
> (gs923)
> base/version.mak
> doc/API.htm
> doc/C-style.htm
> doc/Commprod.htm
> doc/DLL.htm
> doc/Deprecated.htm
> doc/Details8.htm
> doc/Details9.htm
> doc/Develop.htm
> doc/Devices.htm
> doc/Drivers.htm
> doc/Fonts.htm
> doc/Helpers.htm
> doc/History1.htm
> doc/History2.htm
> doc/History3.htm
> doc/History4.htm
> doc/History5.htm
> doc/History6.htm
> doc/History7.htm
> doc/History8.htm
> doc/History9.htm
> doc/Install.htm
> doc/Issues.htm
> doc/Language.htm
> doc/Lib.htm
> doc/Make.htm
> doc/News.htm
> doc/Projects.htm
> doc/Ps-style.htm
> doc/Ps2epsi.htm
> doc/Psfiles.htm
> doc/Readme.htm
> doc/Release.htm
> doc/SavedPages.htm
> doc/Source.htm
> doc/Unix-lpr.htm
> doc/Use.htm
> doc/VectorDevices.htm
> doc/WhatIsGS.htm
> doc/gs-vms.hlp
> doc/sample_downscale_device.htm
> doc/thirdparty.htm
> man/dvipdf.1
> man/gs.1
> man/gslp.1
> man/gsnd.1
> man/pdf2dsc.1
> man/pdf2ps.1
> man/pf2afm.1
> man/pfbtopfa.1
> man/printafm.1
> man/ps2ascii.1
> man/ps2epsi.1
> man/ps2pdf.1
> man/ps2pdfwr.1
> man/ps2ps.1

2018-03-22 11:30:03 +0000
Chris Liddell <chris.liddell@artifex.com>
57d33404ce0fab68a909fff501c0b8e2912b9956

> Check __STDC_VERSION__ is defined before using it
> Not all compilers (and versions) have __STDC_VERSION__
> base/stdpre.h

2018-03-22 11:16:09 +0000
Chris Liddell <chris.liddell@artifex.com>
829c4c55f8b0d77ead0c3daf3ab4164c6b7d8365

> Fix FAPI's CharString dictionary accessing
> Because dictionaries are (generally) made up of sparse arrays (one each for
> keys and values), it's not generally safe to simply access indices into those
> arrays - which the FAPI code was doing.
> Normally, for that type of access, we'd use the dictionary content enumerator
> function but, in this case, the FAPI API does not enforce iterating through
> the dictionary contents, but allows for "random" accessing the contents.
> However, the requirement to handle broken or invalid CharStrings also means we
> neatly handle empty slots in the sparse arrays.
> So, the only change required here is to use the maximum size of the dictionary
> object, rather than the "size" to know how many indices to check.
> As an additional safety check, however, also add checks for the key/value
> types, and treat an invalid type as an empty slot.
> psi/zfapi.c

2018-03-22 11:21:13 +0000
Ken Sharp <ken.sharp@artifex.com>
8ac0975771838c7d8c17f5f2f7223607eb976788

> PS interpreter - fix parsing of NChannel Colorants dictionary
> The code was previously using dict_index_entry to retrieve entries
> from the Colorants dictionary, but it did not account for the function
> returning gs_error_undefined when a slot in the dictionary was present
> but unused. Since dictionaries are sparse arrays, this is possible.
> This commit reworks the code to use dict_first() and dict_next() to
> retrieve elements from the dictionary, and starts at the maximum entry
> and works down, instead of the previous code which started at 0 and
> worked up.
> psi/zcolor.c

2018-03-20 21:42:39 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
e54754db42c2640c10a73b18779213d16dbd10d0

> Bug 697545 : Update functions to return error codes.
> Prevent numerous SEGV points by ensuring error codes are returned and
> handled appropriately
> base/gsptype1.c
> base/gximage1.c
> base/gxipixel.c
> base/gxpcmap.c

2018-03-21 02:43:52 +0800
Sebastian Rasmussen <sebras@gmail.com>
94d46eea5dada844ac4d9767dfb7a384a408e111

> Fix 698839: Remove testcase that cannot be found from testrunner.
> jbig2dec/test_jbig2dec.py

2018-03-21 02:38:15 +0800
Sebastian Rasmussen <sebras@gmail.com>
222403964eb437c0b60404fcc11bb879744d263e

> Fix 698839: Add hash for testcases that fail to decode anything.
> The testrunner stated that the expected hash for 042_13.jb2 and
> 042_14.jb2 was that of a successfully decoded image. Historically
> these two images have caused jbig2dec to segfault, but nowadays
> they correctly cause FATAL ERRORs. When FATAL ERRORs are
> encountered as hash covering 0 bytes of image data is computed,
> so the testrunner now expects this hash instead. Therefore the
> check now run successfully.
> jbig2dec/test_jbig2dec.py

2018-03-21 02:30:12 +0800
Sebastian Rasmussen <sebras@gmail.com>
430fcce8516a3c38f03e8f81d4d8b3e87a5aff28

> Fix 698839: Have the testsuite runner return the result.
> Previously the return value was None regardless of test succeeded
> or failed. This meant that the test_jbig2dec.py script had an
> exit code of 1 not matter the outcome. Now it is 0 upon success
> and 1 upon error, as expected by the make check infrastructure.
> jbig2dec/test_jbig2dec.py

2018-03-21 00:44:00 +0800
Sebastian Rasmussen <sebras@gmail.com>
3431972e91c51403cf4223f1d5c28b666ea84c6e

> Fix 698839: Set correct checksum for amb_{1,2}.jb2 in test suite.
> jbig2dec/test_jbig2dec.py

2018-03-20 13:16:40 +0000
Chris Liddell <chris.liddell@artifex.com>
d8d4a64468252f5b632891fa9c8fdf98930fae15

> Add missing files to doc install target
> These files:
> VectorDevices.htm
> sample_downscale_device.htm
> SavedPages.htm
> subclass.htm
> were missing from the documentation installation target
> base/unixinst.mak

2018-03-20 14:13:00 +0000
Ken Sharp <ken.sharp@artifex.com>
18ec3899047e26109548cb601f0bf830a86d9abe

> Coverty ID 94548 - check return value
> psi/zupath.c

2018-03-20 13:36:31 +0000
Ken Sharp <ken.sharp@artifex.com>
a9f78155bc0f5050359ea6dfbfb5166e4f72a9cf

> Coverity ID 26487 - remove duplicate branch
> devices/gdevpdfimg.c

2018-03-20 12:10:15 +0000
Ken Sharp <ken.sharp@artifex.com>
46b6212e1688ba5d49923908d3be3f9329dd705b

> PDF interpreter - remove /.gs.pdfobj# entries from pdfmarks
> Since we increased the places where we use /.gs.pfgobj# to track the
> PDF object number, we have been emitting PDF files from pdfwrite
> which contain dictionaries with illegal PDF names.
> The '#' in PDF naming is used to escape unprintable characters (eg
> space), it must be followed by 2 hex digits, ours isn't.
> Trying to fix this in the pdfmark processing proved problematic, so
> instead, remove it at the PostScritp level.
> Resource/Init/pdf_draw.ps
> Resource/Init/pdf_main.ps

2018-03-20 02:28:20 +0800
Sebastian Rasmussen <sebras@gmail.com>
8cf6ddf78db5fc4a453df1a1a9d3ea120ba47609

> Fix 698840: Fix typo in exit code in command-line tool.
> This was introduced in 301726dd5c9c60c1e54eb0965c1d45b36350ce2e.
> Thanks to Max Rees for reporting.
> jbig2dec/jbig2dec.c

2018-03-18 14:09:16 +0800
Sebastian Rasmussen <sebras@gmail.com>
71bf7cb0c4aa3d2bb06deac2df675af44b3e4c3b

> Fix 699127: JBIG2 adaptive pixels restricted to field.
> When decoding generic regions the adaptive pixels must be
> restricted to a field, previously this was not validated,
> leading to out of buffer accesses.
> This is now validated and may generate a fatal error.
> jbig2dec/jbig2_generic.c

2018-03-19 13:47:36 +0000
Ken Sharp <ken.sharp@artifex.com>
bb2ea8ca0482cb0bb5632c30e9184e3d19fdc8d2

> pdfwrite - ensure correct ICC profile version being written out
> Bug #699104 "Identify ICC profiles unsuitable for embedding in output PDF and fall back to device space"
> Previously we did not check the minor version number of ICC profiles
> when writing an ICCBased colour space. Since PDF versions below 1.7
> support either 4.0.0 0r 4.1.0, this could mean that we wrote a version
> of profile that was too great for teh PDF version.
> Following on from Michael's commit f732ea3a999f73afa46c2cc4ca28b067f671d29c
> we can now determine the minor version number of profiles, and we now
> use that to decide whether to use the profile as it is, or drop back to
> a version 2 profile.
> Since falling back to a version 2 profile can cause subtle changes in
> colour, we now make the default CompatibilityLevel for PDF output 1.7.
> Some PDFSETTINGS convert all colours to device spaces and these have
> not been altered (not required). We could have defaulted to PDF 2.0
> output, but the code is rather new, and also prevents certain constructs
> (eg TransferFunction in the graphics state).
> Resource/Init/gs_pdfwr.ps
> devices/vector/gdevpdf.c
> devices/vector/gdevpdfk.c
> doc/VectorDevices.htm

2018-03-19 11:13:13 +0000
Ken Sharp <ken.sharp@artifex.com>
5fe0dbb5de65ca92a0ba8ff4a96447e30e4366e8

> pdfwrite - remove special case for GS_UNDEFINED ICC profile colour space
> Since commit f732ea3a999f73afa46c2cc4ca28b067f671d29c the cs_data
> member of ICC profiles generated internally is correctly set. So we no
> longer need to special-case ICC profiles where the cs_data member is
> GS_UNDEFINED.
> devices/vector/gdevpdfk.c

2018-03-19 10:29:38 +0000
Ken Sharp <ken.sharp@artifex.com>
8078194fd8abe7c9c3088573b9e69a4a967b6ee0

> Bug 699122 - valgrind regression
> Somewhat to my surprise, calling gs_setcolorspace does not set the
> device colour, and leaves 'ccolor_valid' in an undefined state.
> Call gs_set_dev_color() to explicitly set the device colour after we
> reset the device space to gray in gs_initgraphics()
> base/gsstate.c

2018-03-16 13:27:45 +0000
Chris Liddell <chris.liddell@artifex.com>
9b9acd5a8e074bbb47107f6add7b8afb1fe43270

> Fix ommission from revised documentation install path
> base/unixinst.mak

2018-03-18 12:33:22 -0700
Michael Vrhel <michael.vrhel@artifex.com>
f732ea3a999f73afa46c2cc4ca28b067f671d29c

> Bug 699104 make sure data_cs is populated when creating profiles
> Also, added a method to return the major and minor version numbers
> for use in pdf write.
> base/gsciemap.c
> base/gsicc_manage.c
> base/gsicc_manage.h

2018-03-15 19:14:15 +0000
Ken Sharp <ken.sharp@artifex.com>
269663402c5210dd1a15131a045526e3cd6de479

> pdfimage devices - fix up some minor problems
> Bug #699119 " pdfimage24 creates bad PDF"
> When I removed some extraneous stuff from the output (to simplify it) I
> forgot to update the pdfimage devices properly, leading to them trying
> to write xref entries for missing data.
> In addition, there was a problem writing the Length object of the image
> streams.
> Ghostscript complained about both of these but rendered the content
> correctly, other consumers didn't complain.
> devices/gdevpdfimg.c

2018-03-15 11:04:40 +0000
Chris Liddell <chris.liddell@artifex.com>
124b37fc65fe665d8b4a6133142784c4edb3b3bf

> lcms2art: byteReverse needs a ContextID
> on big endian platforms - fix that.
> Reported against 9.23 RC1
> lcms2art/src/cmsmd5.c

2018-01-29 15:32:52 +0000
Robin Watts <robin.watts@artifex.com>
e0f461a8a634036bbff938492190c72fcef684ac

> Tweak indent of comment.
> base/gsicc_lcms2art.c

2018-03-14 19:49:29 +0000
Robin Watts <robin.watts@artifex.com>
40263f15745f9cf9477acc35708bf61a2de46a6b

> Simplify image enumerator rectangle logic for scalers.
> We store the image size as a rectangle in the image enumerator.
> For the purposes of scaling, we also store the rectangle that
> needs to be rendered. We expand this slightly to allow for
> the support requirements of the scaler, thus giving a rectangle
> that is really what we need to decode.
> In order to correctly setup the scaler we then need to try to
> guess how much expansion was done. My previous attempts at
> this guesswork failed.
> A simpler solution would appear to be to just save both the
> render and decode rectangles stored separately. This simplifies
> the logic.
> base/gximage.h
> base/gxipixel.c
> base/gxiscale.c
> base/sisparam.h

2018-03-12 18:53:45 +0000
Robin Watts <robin.watts@artifex.com>
088cae9953f3a692201915c91bc87260add91fc6

> lcms2art: Split transforms in two.
> Each cmsTransform now has a 'core' part and a part that can
> be 'cloned' to change the buffer formats.
> The plan is to drop cmsChangeBuffersFormat and use this instead
> to make sure we truly are thread safe.
> lcms2art/include/lcms2art.h
> lcms2art/src/cmsalpha.c
> lcms2art/src/cmsnamed.c
> lcms2art/src/cmsplugin.c
> lcms2art/src/cmsps2.c
> lcms2art/src/cmsvirt.c
> lcms2art/src/cmsxform.c
> lcms2art/src/extra_xform.h
> lcms2art/src/lcms2_internal.h

2018-03-12 18:53:17 +0000
Robin Watts <robin.watts@artifex.com>
85569e3bd463ff2b67c195dd84ed770d2f86eb8f

> Update VS project for lcms2 -> lcms2art change.
> windows/ghostscript.vcproj

2018-03-14 19:38:01 +0000
Robin Watts <robin.watts@artifex.com>
ad292af74cbb8e823cf2829d29a35661caf1c49c

> Fix typo in Memento_breakpointLocked.
> base/memento.c

2018-03-14 16:41:03 +0000
Robin Watts <robin.watts@artifex.com>
34e279b84a6271c37a5a51ccefaccd2362845e73

> Revert "Tweak bitmap interpolater patch size."
> This reverts commit 38e0c643e62087c089c59c9ad44fc468dd09cd37.
> This was shown to cause problems with:
> tests_private/pdf/PDFIA1.7_SUBSET/IA3Z3225.pdf.pdf.psdcmyk.300.1
> (or tests_private/pdf/PDFIA1.7_SUBSET/IA3Z3225.pdf, page 2, tweaked
> to rotate by 270).
> Reverting for now so I can try to find a less hacky (and hence
> less error prone) way of working.
> base/gxiscale.c
> base/sisparam.h

2018-03-01 15:04:48 +0800
Sebastian Rasmussen <sebras@gmail.com>
36ab38b53695ae4b212507c45ec07f117ff26e2d

> Fix 699083: Avoid leak in symbol dictionary parsing upon error.
> jbig2dec/jbig2_symbol_dict.c

2018-03-13 12:20:33 +0000
Ken Sharp <ken.sharp@artifex.com>
151aa07a734101182b1861c3113c2539d2d8a485

> pdfwrite - correct a function name
> stupid typo in function name, its been annoying me for years.
> devices/vector/gdevpdtt.c

2018-03-13 10:37:08 +0000
Ken Sharp <ken.sharp@artifex.com>
cb018b64dea61f2d6146652dce349d3fadab1709

> Squash a benign compiler warning
> devices/vector/gdevpdtt.c

2018-03-13 10:36:45 +0000
Ken Sharp <ken.sharp@artifex.com>
9ad220db0c06b9a22bd757f92edaaf624b701b1b

> pdfwrite - don't write device spaces for masks representing glyphs
> This came up while looking into ICC profile embedding. If we are
> processing a mask bitmap which represents a glyph (eg when creating a
> type 3 font for a font which cannot be embedded directly in a PDF) we
> do not want to write a device colour.
> We probably *never* want to write a device colour in here, but I'm not
> certain of that, I am certain that the high level colour will already
> have been set if we are processing text though. So in this commit, limit
> the change so that we don't write device colours for glyphs.
> devices/vector/gdevpdfb.c

2018-03-13 10:33:52 +0000
Ken Sharp <ken.sharp@artifex.com>
f06d2b00d005012379d4a2f6f47aab99b7b13b5c

> pdfwrite - reject inappropriate ICC profiles
> PDF files cannot include the full possible range of ICC profiles, if
> we encounter one of these (eg from an XPS file) then refuse to embed it
> and instead return gs_error_rangecheck, so that the calling code will
> fall back to a device space representation.
> NOTE we currently permit GS_UNDEFINED as a valid data_cs which we really
> shouldn't but the current code, when converting a CIEBasedDEF or
> CIEBasedDEFG (possibly other CIE spaces) to ICC creates a profile
> where data_cs is GS_UNDEFINED (which is 0, so probably not actually
> filled in).
> devices/vector/gdevpdfk.c

2018-03-06 12:22:23 +0000
Robin Watts <robin.watts@artifex.com>
d6bdb65a51e154402a173182e8d1beccba610ea0

> Memento: Add Mutex to protect Memento operations.
> Solves problems that Ray was seeing while debugging the multithreaded
> integration of our modified LCMS2.
> base/memento.c

2018-03-12 14:22:44 +0000
Ken Sharp <ken.sharp@artifex.com>
c6596a021cbe1cd716eaf50e3dd06de646e05572

> pdfwrite - avoid use of /.notdef when converting PCL fonts to type 3
> Bug #699102 "using -sDEVICE=pdfwrite option generate an incorrect code 128 barcode"
> This is actually an Acrobat bug, every other viewer I've tested works as
> expected, Acrobat does not.
> The problem appears to be related to defining a /.notdef glyph and
> encoding it at a position other than 0 in the Encoding. If we do that,
> and use the encoded /.notdef glyph, Acrobat quietly replaces it with the
> glyph encoded at position 0 in the Encoding of the font.
> Because of the way that PCL fonts work, when we are converting PCL
> fonts to type 3 PDF fonts, the character (PCL) 0x1D gets assigned the
> glyph name /.notdef. The actual Encoding of the glyph is at position
> 0x1D however, which causes Acrobat to substitute the glyph at Encoding
> position 0.
> This is obviously wrong. However, since its Acrobat, here we add yet
> another heuristic to avoid defining glyphs with the name /.notdef when
> creating type 3 PDF fonts from PCL fonts.
> No differences expected
> devices/vector/gdevpdtt.c

2018-03-07 18:31:23 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
3b3d8f74dc026c4f1af5022a1527d41d21511401

> Bug 697545 : Prevent SEGV from gs_make_pattern_common.
> Prevent SEGV if memory allocation fails and returns an empty path.
> Error created using :-
> MEMENTO_FAILAT=9104 ./membin/gpcl6 -sDEVICE=ppmraw -o /dev/null ./pcl/examples/owl.pcl
> base/gspcolor.c

2018-03-08 13:21:54 +0000
Robin Watts <robin.watts@artifex.com>
d68b62d7567f20f0f269d096b899bd2409967980

> Avoid total image dropout in interplated rescales.
> Tests show that the following command causes images to disappear:
> gxps -o out.ppm -sDEVICE=ppmraw -72 tests_private/xps/xpsfts-a4/fts_27xx.xps
> This is because we scale a 1600 wide image down to 27 pixels across.
> As such the weights for each individual pixel round to zero, and we
> get nothing displayed.
> Adjust for this by still calculating weights as doubles, and carrying
> the error across the line. This keeps the total sum of the differences
> correct.
> base/siscale.c

2018-03-06 21:57:06 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
676dfb338d296aa86630662714fce5f058e31b8f

> Bug 697545 : Update functions to return error codes.
> Prevent numerous SEGV points by ensuring error codes are returned and
> handled appropriately
> pcl/pxl/pxsessio.c

2018-03-06 20:33:02 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
2926860ca8ce519dadf23e44a9b4828da70090c4

> Bug 697545 : Update functions to return error codes.
> Each parameter handling function has been updated to ensure error codes
> are returned and handled appropriately and gs_c_param_list_release is
> always called on exit.
> pcl/pcl/pcommand.c

2018-03-07 12:16:51 +0000
Chris Liddell <chris.liddell@artifex.com>
cfada4acb65861b4361ad80dbb53f61c5dc94c96

> Bump version - prep for release
> Resource/Init/gs_init.ps
> base/version.mak

2018-03-21 08:44:23 +0000
Chris Liddell <chris.liddell@artifex.com>
a03872ea339d60055fa09dc451ebf37442f467fb

> Final changelog for 9.23 release
> doc/History9.htm

2018-03-21 08:41:35 +0000
Chris Liddell <chris.liddell@artifex.com>
eb210aecab59f338ef9b8af4523edb3c8bc35092

> Dates, changelog and product string for release
> base/gscdef.c
> base/version.mak
> doc/API.htm
> doc/C-style.htm
> doc/Commprod.htm
> doc/DLL.htm
> doc/Deprecated.htm
> doc/Details8.htm
> doc/Details9.htm
> doc/Develop.htm
> doc/Devices.htm
> doc/Drivers.htm
> doc/Fonts.htm
> doc/Helpers.htm
> doc/History1.htm
> doc/History2.htm
> doc/History3.htm
> doc/History4.htm
> doc/History5.htm
> doc/History6.htm
> doc/History7.htm
> doc/History8.htm
> doc/History9.htm
> doc/Install.htm
> doc/Issues.htm
> doc/Language.htm
> doc/Lib.htm
> doc/Make.htm
> doc/News.htm
> doc/Projects.htm
> doc/Ps-style.htm
> doc/Ps2epsi.htm
> doc/Psfiles.htm
> doc/Readme.htm
> doc/Release.htm
> doc/SavedPages.htm
> doc/Source.htm
> doc/Unix-lpr.htm
> doc/Use.htm
> doc/VectorDevices.htm
> doc/WhatIsGS.htm
> doc/gs-vms.hlp
> doc/sample_downscale_device.htm
> doc/thirdparty.htm
> man/dvipdf.1
> man/gs.1
> man/gslp.1
> man/gsnd.1
> man/pdf2dsc.1
> man/pdf2ps.1
> man/pf2afm.1
> man/pfbtopfa.1
> man/printafm.1
> man/ps2ascii.1
> man/ps2epsi.1
> man/ps2pdf.1
> man/ps2pdfwr.1
> man/ps2ps.1

2018-03-20 13:16:40 +0000
Chris Liddell <chris.liddell@artifex.com>
41c92643ce1325893d0f491a49fb2edad1684d17

> Add missing files to doc install target
> These files:
> VectorDevices.htm
> sample_downscale_device.htm
> SavedPages.htm
> subclass.htm
> were missing from the documentation installation target
> base/unixinst.mak

2018-03-16 13:27:45 +0000
Chris Liddell <chris.liddell@artifex.com>
6ca20f5735e9cde19eee6577059cd9d844e94525

> Fix ommission from revised documentation install path
> base/unixinst.mak

2018-03-15 19:14:15 +0000
Ken Sharp <ken.sharp@artifex.com>
713d80d0dde40a5d1d1f402e8347997896b9a8f7

> pdfimage devices - fix up some minor problems
> Bug #699119 " pdfimage24 creates bad PDF"
> When I removed some extraneous stuff from the output (to simplify it) I
> forgot to update the pdfimage devices properly, leading to them trying
> to write xref entries for missing data.
> In addition, there was a problem writing the Length object of the image
> streams.
> Ghostscript complained about both of these but rendered the content
> correctly, other consumers didn't complain.
> devices/gdevpdfimg.c

2018-03-15 11:04:40 +0000
Chris Liddell <chris.liddell@artifex.com>
7f822afbb52a6b37fc4766f840e714d9f491da81

> lcms2art: byteReverse needs a ContextID
> on big endian platforms - fix that.
> Reported against 9.23 RC1
> lcms2art/src/cmsmd5.c

2018-03-15 07:50:41 +0000
Chris Liddell <chris.liddell@artifex.com>
36bc37e414b695b1fa39c7e99be9d83f8628e889

> Changelog and product string for 9.23 rc3
> base/gscdef.c
> doc/History9.htm

2018-03-14 16:41:03 +0000
Robin Watts <robin.watts@artifex.com>
e31e3879532fd23ca2658aea26bf4cadd665687f

> Revert "Tweak bitmap interpolater patch size."
> This reverts commit 38e0c643e62087c089c59c9ad44fc468dd09cd37.
> This was shown to cause problems with:
> tests_private/pdf/PDFIA1.7_SUBSET/IA3Z3225.pdf.pdf.psdcmyk.300.1
> (or tests_private/pdf/PDFIA1.7_SUBSET/IA3Z3225.pdf, page 2, tweaked
> to rotate by 270).
> Reverting for now so I can try to find a less hacky (and hence
> less error prone) way of working.
> base/gxiscale.c
> base/sisparam.h

2018-03-14 07:47:37 +0000
Chris Liddell <chris.liddell@artifex.com>
56888d7a2e8b9cade1fc9535b67bd9841e2aca6e

> Update changelog for 9.23 rc2
> doc/History9.htm

2018-03-14 07:45:29 +0000
Chris Liddell <chris.liddell@artifex.com>
f7acb2502eadeff35dc791b52400d1a301059927

> Dates etc for 9.23 rc2
> base/version.mak
> doc/API.htm
> doc/C-style.htm
> doc/Commprod.htm
> doc/DLL.htm
> doc/Deprecated.htm
> doc/Details8.htm
> doc/Details9.htm
> doc/Develop.htm
> doc/Devices.htm
> doc/Drivers.htm
> doc/Fonts.htm
> doc/Helpers.htm
> doc/History1.htm
> doc/History2.htm
> doc/History3.htm
> doc/History4.htm
> doc/History5.htm
> doc/History6.htm
> doc/History7.htm
> doc/History8.htm
> doc/History9.htm
> doc/Install.htm
> doc/Issues.htm
> doc/Language.htm
> doc/Lib.htm
> doc/Make.htm
> doc/News.htm
> doc/Projects.htm
> doc/Ps-style.htm
> doc/Ps2epsi.htm
> doc/Psfiles.htm
> doc/Readme.htm
> doc/Release.htm
> doc/SavedPages.htm
> doc/Source.htm
> doc/Unix-lpr.htm
> doc/Use.htm
> doc/VectorDevices.htm
> doc/WhatIsGS.htm
> doc/gs-vms.hlp
> doc/sample_downscale_device.htm
> doc/thirdparty.htm
> man/dvipdf.1
> man/gs.1
> man/gslp.1
> man/gsnd.1
> man/pdf2dsc.1
> man/pdf2ps.1
> man/pf2afm.1
> man/pfbtopfa.1
> man/printafm.1
> man/ps2ascii.1
> man/ps2epsi.1
> man/ps2pdf.1
> man/ps2pdfwr.1
> man/ps2ps.1

2018-03-13 10:37:08 +0000
Ken Sharp <ken.sharp@artifex.com>
7c9a54209a2758769102361a456353e7e5993821

> Squash a benign compiler warning
> devices/vector/gdevpdtt.c

2018-03-13 10:33:52 +0000
Ken Sharp <ken.sharp@artifex.com>
353c6caa4b8dea6baae337b30217139e996e9b94

> pdfwrite - reject inappropriate ICC profiles
> PDF files cannot include the full possible range of ICC profiles, if
> we encounter one of these (eg from an XPS file) then refuse to embed it
> and instead return gs_error_rangecheck, so that the calling code will
> fall back to a device space representation.
> NOTE we currently permit GS_UNDEFINED as a valid data_cs which we really
> shouldn't but the current code, when converting a CIEBasedDEF or
> CIEBasedDEFG (possibly other CIE spaces) to ICC creates a profile
> where data_cs is GS_UNDEFINED (which is 0, so probably not actually
> filled in).
> devices/vector/gdevpdfk.c

2018-03-12 14:22:44 +0000
Ken Sharp <ken.sharp@artifex.com>
23f66c8eec91e8efcbc600d987cf8bde7e3dce4b

> pdfwrite - avoid use of /.notdef when converting PCL fonts to type 3
> Bug #699102 "using -sDEVICE=pdfwrite option generate an incorrect code 128 barcode"
> This is actually an Acrobat bug, every other viewer I've tested works as
> expected, Acrobat does not.
> The problem appears to be related to defining a /.notdef glyph and
> encoding it at a position other than 0 in the Encoding. If we do that,
> and use the encoded /.notdef glyph, Acrobat quietly replaces it with the
> glyph encoded at position 0 in the Encoding of the font.
> Because of the way that PCL fonts work, when we are converting PCL
> fonts to type 3 PDF fonts, the character (PCL) 0x1D gets assigned the
> glyph name /.notdef. The actual Encoding of the glyph is at position
> 0x1D however, which causes Acrobat to substitute the glyph at Encoding
> position 0.
> This is obviously wrong. However, since its Acrobat, here we add yet
> another heuristic to avoid defining glyphs with the name /.notdef when
> creating type 3 PDF fonts from PCL fonts.
> No differences expected
> devices/vector/gdevpdtt.c

2018-03-08 13:21:54 +0000
Robin Watts <robin.watts@artifex.com>
1567dba0b505a0bb816e7b2e34f3915165a7d5b3

> Avoid total image dropout in interplated rescales.
> Tests show that the following command causes images to disappear:
> gxps -o out.ppm -sDEVICE=ppmraw -72 tests_private/xps/xpsfts-a4/fts_27xx.xps
> This is because we scale a 1600 wide image down to 27 pixels across.
> As such the weights for each individual pixel round to zero, and we
> get nothing displayed.
> Adjust for this by still calculating weights as doubles, and carrying
> the error across the line. This keeps the total sum of the differences
> correct.
> base/siscale.c

2018-03-07 14:40:21 +0000
Chris Liddell <chris.liddell@artifex.com>
7a6acdfce9344574638c2553f605d86f801f7393

> News and Changelog for 9.23 rc1
> doc/History9.htm
> doc/News.htm

2018-03-07 12:19:48 +0000
Chris Liddell <chris.liddell@artifex.com>
c6285cdd7ae7b1c97ffcf0c824234659b03d6d6a

> Dates and versions for 9.23 rc1
> doc/API.htm
> doc/C-style.htm
> doc/Commprod.htm
> doc/DLL.htm
> doc/Deprecated.htm
> doc/Details8.htm
> doc/Details9.htm
> doc/Develop.htm
> doc/Devices.htm
> doc/Drivers.htm
> doc/Fonts.htm
> doc/Helpers.htm
> doc/History1.htm
> doc/History2.htm
> doc/History3.htm
> doc/History4.htm
> doc/History5.htm
> doc/History6.htm
> doc/History7.htm
> doc/History8.htm
> doc/History9.htm
> doc/Install.htm
> doc/Issues.htm
> doc/Language.htm
> doc/Lib.htm
> doc/Make.htm
> doc/News.htm
> doc/Projects.htm
> doc/Ps-style.htm
> doc/Ps2epsi.htm
> doc/Psfiles.htm
> doc/Readme.htm
> doc/Release.htm
> doc/SavedPages.htm
> doc/Source.htm
> doc/Unix-lpr.htm
> doc/Use.htm
> doc/VectorDevices.htm
> doc/WhatIsGS.htm
> doc/gs-vms.hlp
> doc/sample_downscale_device.htm
> doc/thirdparty.htm
> man/dvipdf.1
> man/gs.1
> man/gslp.1
> man/gsnd.1
> man/pdf2dsc.1
> man/pdf2ps.1
> man/pf2afm.1
> man/pfbtopfa.1
> man/printafm.1
> man/ps2ascii.1
> man/ps2epsi.1
> man/ps2pdf.1
> man/ps2pdfwr.1
> man/ps2ps.1

2018-03-07 09:59:55 +0000
Chris Liddell <chris.liddell@artifex.com>
0df45c3d11246d773110d5b1a563d7462f3acac1

> Revision date and product for release candidate
> base/gscdef.c
> base/version.mak

### Changelog

2018-03-21 08:41:35 +0000
Chris Liddell <chris.liddell@artifex.com>
eb210aecab59f338ef9b8af4523edb3c8bc35092

> Dates, changelog and product string for release
> base/gscdef.c
> base/version.mak
> doc/API.htm
> doc/C-style.htm
> doc/Commprod.htm
> doc/DLL.htm
> doc/Deprecated.htm
> doc/Details8.htm
> doc/Details9.htm
> doc/Develop.htm
> doc/Devices.htm
> doc/Drivers.htm
> doc/Fonts.htm
> doc/Helpers.htm
> doc/History1.htm
> doc/History2.htm
> doc/History3.htm
> doc/History4.htm
> doc/History5.htm
> doc/History6.htm
> doc/History7.htm
> doc/History8.htm
> doc/History9.htm
> doc/Install.htm
> doc/Issues.htm
> doc/Language.htm
> doc/Lib.htm
> doc/Make.htm
> doc/News.htm
> doc/Projects.htm
> doc/Ps-style.htm
> doc/Ps2epsi.htm
> doc/Psfiles.htm
> doc/Readme.htm
> doc/Release.htm
> doc/SavedPages.htm
> doc/Source.htm
> doc/Unix-lpr.htm
> doc/Use.htm
> doc/VectorDevices.htm
> doc/WhatIsGS.htm
> doc/gs-vms.hlp
> doc/sample_downscale_device.htm
> doc/thirdparty.htm
> man/dvipdf.1
> man/gs.1
> man/gslp.1
> man/gsnd.1
> man/pdf2dsc.1
> man/pdf2ps.1
> man/pf2afm.1
> man/pfbtopfa.1
> man/printafm.1
> man/ps2ascii.1
> man/ps2epsi.1
> man/ps2pdf.1
> man/ps2pdfwr.1
> man/ps2ps.1

2018-03-20 13:16:40 +0000
Chris Liddell <chris.liddell@artifex.com>
41c92643ce1325893d0f491a49fb2edad1684d17

> Add missing files to doc install target
> These files:
> VectorDevices.htm
> sample_downscale_device.htm
> SavedPages.htm
> subclass.htm
> were missing from the documentation installation target
> base/unixinst.mak

2018-03-16 13:27:45 +0000
Chris Liddell <chris.liddell@artifex.com>
6ca20f5735e9cde19eee6577059cd9d844e94525

> Fix ommission from revised documentation install path
> base/unixinst.mak

2018-03-15 19:14:15 +0000
Ken Sharp <ken.sharp@artifex.com>
713d80d0dde40a5d1d1f402e8347997896b9a8f7

> pdfimage devices - fix up some minor problems
> Bug #699119 " pdfimage24 creates bad PDF"
> When I removed some extraneous stuff from the output (to simplify it) I
> forgot to update the pdfimage devices properly, leading to them trying
> to write xref entries for missing data.
> In addition, there was a problem writing the Length object of the image
> streams.
> Ghostscript complained about both of these but rendered the content
> correctly, other consumers didn't complain.
> devices/gdevpdfimg.c

2018-03-15 11:04:40 +0000
Chris Liddell <chris.liddell@artifex.com>
7f822afbb52a6b37fc4766f840e714d9f491da81

> lcms2art: byteReverse needs a ContextID
> on big endian platforms - fix that.
> Reported against 9.23 RC1
> lcms2art/src/cmsmd5.c

2018-03-15 07:50:41 +0000
Chris Liddell <chris.liddell@artifex.com>
36bc37e414b695b1fa39c7e99be9d83f8628e889

> Changelog and product string for 9.23 rc3
> base/gscdef.c
> doc/History9.htm

2018-03-14 16:41:03 +0000
Robin Watts <robin.watts@artifex.com>
e31e3879532fd23ca2658aea26bf4cadd665687f

> Revert "Tweak bitmap interpolater patch size."
> This reverts commit 38e0c643e62087c089c59c9ad44fc468dd09cd37.
> This was shown to cause problems with:
> tests_private/pdf/PDFIA1.7_SUBSET/IA3Z3225.pdf.pdf.psdcmyk.300.1
> (or tests_private/pdf/PDFIA1.7_SUBSET/IA3Z3225.pdf, page 2, tweaked
> to rotate by 270).
> Reverting for now so I can try to find a less hacky (and hence
> less error prone) way of working.
> base/gxiscale.c
> base/sisparam.h

2018-03-14 07:45:29 +0000
Chris Liddell <chris.liddell@artifex.com>
f7acb2502eadeff35dc791b52400d1a301059927

> Dates etc for 9.23 rc2
> base/version.mak
> doc/API.htm
> doc/C-style.htm
> doc/Commprod.htm
> doc/DLL.htm
> doc/Deprecated.htm
> doc/Details8.htm
> doc/Details9.htm
> doc/Develop.htm
> doc/Devices.htm
> doc/Drivers.htm
> doc/Fonts.htm
> doc/Helpers.htm
> doc/History1.htm
> doc/History2.htm
> doc/History3.htm
> doc/History4.htm
> doc/History5.htm
> doc/History6.htm
> doc/History7.htm
> doc/History8.htm
> doc/History9.htm
> doc/Install.htm
> doc/Issues.htm
> doc/Language.htm
> doc/Lib.htm
> doc/Make.htm
> doc/News.htm
> doc/Projects.htm
> doc/Ps-style.htm
> doc/Ps2epsi.htm
> doc/Psfiles.htm
> doc/Readme.htm
> doc/Release.htm
> doc/SavedPages.htm
> doc/Source.htm
> doc/Unix-lpr.htm
> doc/Use.htm
> doc/VectorDevices.htm
> doc/WhatIsGS.htm
> doc/gs-vms.hlp
> doc/sample_downscale_device.htm
> doc/thirdparty.htm
> man/dvipdf.1
> man/gs.1
> man/gslp.1
> man/gsnd.1
> man/pdf2dsc.1
> man/pdf2ps.1
> man/pf2afm.1
> man/pfbtopfa.1
> man/printafm.1
> man/ps2ascii.1
> man/ps2epsi.1
> man/ps2pdf.1
> man/ps2pdfwr.1
> man/ps2ps.1

2018-03-13 10:37:08 +0000
Ken Sharp <ken.sharp@artifex.com>
7c9a54209a2758769102361a456353e7e5993821

> Squash a benign compiler warning
> devices/vector/gdevpdtt.c

2018-03-13 10:33:52 +0000
Ken Sharp <ken.sharp@artifex.com>
353c6caa4b8dea6baae337b30217139e996e9b94

> pdfwrite - reject inappropriate ICC profiles
> PDF files cannot include the full possible range of ICC profiles, if
> we encounter one of these (eg from an XPS file) then refuse to embed it
> and instead return gs_error_rangecheck, so that the calling code will
> fall back to a device space representation.
> NOTE we currently permit GS_UNDEFINED as a valid data_cs which we really
> shouldn't but the current code, when converting a CIEBasedDEF or
> CIEBasedDEFG (possibly other CIE spaces) to ICC creates a profile
> where data_cs is GS_UNDEFINED (which is 0, so probably not actually
> filled in).
> devices/vector/gdevpdfk.c

2018-03-12 14:22:44 +0000
Ken Sharp <ken.sharp@artifex.com>
23f66c8eec91e8efcbc600d987cf8bde7e3dce4b

> pdfwrite - avoid use of /.notdef when converting PCL fonts to type 3
> Bug #699102 "using -sDEVICE=pdfwrite option generate an incorrect code 128 barcode"
> This is actually an Acrobat bug, every other viewer I've tested works as
> expected, Acrobat does not.
> The problem appears to be related to defining a /.notdef glyph and
> encoding it at a position other than 0 in the Encoding. If we do that,
> and use the encoded /.notdef glyph, Acrobat quietly replaces it with the
> glyph encoded at position 0 in the Encoding of the font.
> Because of the way that PCL fonts work, when we are converting PCL
> fonts to type 3 PDF fonts, the character (PCL) 0x1D gets assigned the
> glyph name /.notdef. The actual Encoding of the glyph is at position
> 0x1D however, which causes Acrobat to substitute the glyph at Encoding
> position 0.
> This is obviously wrong. However, since its Acrobat, here we add yet
> another heuristic to avoid defining glyphs with the name /.notdef when
> creating type 3 PDF fonts from PCL fonts.
> No differences expected
> devices/vector/gdevpdtt.c

2018-03-08 13:21:54 +0000
Robin Watts <robin.watts@artifex.com>
1567dba0b505a0bb816e7b2e34f3915165a7d5b3

> Avoid total image dropout in interplated rescales.
> Tests show that the following command causes images to disappear:
> gxps -o out.ppm -sDEVICE=ppmraw -72 tests_private/xps/xpsfts-a4/fts_27xx.xps
> This is because we scale a 1600 wide image down to 27 pixels across.
> As such the weights for each individual pixel round to zero, and we
> get nothing displayed.
> Adjust for this by still calculating weights as doubles, and carrying
> the error across the line. This keeps the total sum of the differences
> correct.
> base/siscale.c

2018-03-07 12:19:48 +0000
Chris Liddell <chris.liddell@artifex.com>
c6285cdd7ae7b1c97ffcf0c824234659b03d6d6a

> Dates and versions for 9.23 rc1
> doc/API.htm
> doc/C-style.htm
> doc/Commprod.htm
> doc/DLL.htm
> doc/Deprecated.htm
> doc/Details8.htm
> doc/Details9.htm
> doc/Develop.htm
> doc/Devices.htm
> doc/Drivers.htm
> doc/Fonts.htm
> doc/Helpers.htm
> doc/History1.htm
> doc/History2.htm
> doc/History3.htm
> doc/History4.htm
> doc/History5.htm
> doc/History6.htm
> doc/History7.htm
> doc/History8.htm
> doc/History9.htm
> doc/Install.htm
> doc/Issues.htm
> doc/Language.htm
> doc/Lib.htm
> doc/Make.htm
> doc/News.htm
> doc/Projects.htm
> doc/Ps-style.htm
> doc/Ps2epsi.htm
> doc/Psfiles.htm
> doc/Readme.htm
> doc/Release.htm
> doc/SavedPages.htm
> doc/Source.htm
> doc/Unix-lpr.htm
> doc/Use.htm
> doc/VectorDevices.htm
> doc/WhatIsGS.htm
> doc/gs-vms.hlp
> doc/sample_downscale_device.htm
> doc/thirdparty.htm
> man/dvipdf.1
> man/gs.1
> man/gslp.1
> man/gsnd.1
> man/pdf2dsc.1
> man/pdf2ps.1
> man/pf2afm.1
> man/pfbtopfa.1
> man/printafm.1
> man/ps2ascii.1
> man/ps2epsi.1
> man/ps2pdf.1
> man/ps2pdfwr.1
> man/ps2ps.1

2018-03-07 09:59:55 +0000
Chris Liddell <chris.liddell@artifex.com>
0df45c3d11246d773110d5b1a563d7462f3acac1

> Revision date and product for release candidate
> base/gscdef.c
> base/version.mak

2018-02-26 15:48:45 +0100
David Kaspar [Dee'Kej] <dkaspar@redhat.com>
8c206ceeeac12b048aeafc9ea51080b624750ff4

> Bug 699068: configure.ac: forcibly disable strict aliasing via CFLAGS
> In case user specifies their own CFLAGS that contains -O2, -O3, -Os or
> -fstrict-aliasing, the default behaviour to disable the strict
> aliasing will be overriden and enabled, which is not correct...
> This commit will append the -fno-strict-aliasing option to CFLAGS set
> by user, which will effectively force the disabling of strict aliasing.
> NOTE: originally the patch issued a warning when appending -fno-strict-aliasing
> and I've changed it to a normal checking/result message pattern - it seems less
> likely to cause end user confusion/panic
> configure.ac

2018-03-05 21:48:02 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
39686173fd26eb6e5eee91202433f5e5f307f61c

> Bug 697545 : Update functions to return error codes.
> Prevent numerous SEGV points by ensuring error codes are returned and
> handled appropriately.
> base/gscolor.c
> base/gsdparam.c
> base/gsptype1.c
> pcl/pcl/pcbiptrn.c
> pcl/pcl/pcpatrn.c
> pcl/pcl/pginit.c
> pcl/pcl/pglabel.c
> pcl/pcl/rtraster.c
> pcl/pl/plparams.c
> pcl/pxl/pxgstate.c
> pcl/pxl/pxink.c
> pcl/pxl/pxpthr.c
> psi/ztrans.c

2018-02-21 19:59:25 +0100
David Kaspar [Dee'Kej] <dkaspar@redhat.com>
469bd6ecf5b223b3e6e3f32ec5a4900866c35e57

> Bug 699057: Makefile.in: @LDFLAGS@ added into GCFLAGS
> Previously, the 'gsc' and 'gsx' binaries were not using LDFLAGS when
> they were built with shared library. Adding LDFLAGS into GCFLAGS fixes
> this issue, and specifying LDFLAGS now works for these binaries as well.
> Makefile.in

2018-03-06 10:16:43 +0000
Chris Liddell <chris.liddell@artifex.com>
71e152462e2b47e8e31aec7cf1238934640aa480

> Update zlib to 1.2.11
> zlib/CMakeLists.txt
> zlib/ChangeLog
> zlib/Makefile.in
> zlib/README
> zlib/adler32.c
> zlib/as400/bndsrc
> zlib/as400/compile.clp
> zlib/as400/readme.txt
> zlib/compress.c
> zlib/configure
> zlib/contrib/README.contrib
> zlib/contrib/ada/zlib-streams.ads
> zlib/contrib/ada/zlib-thin.ads
> zlib/contrib/blast/blast.c
> zlib/contrib/blast/blast.h
> zlib/contrib/delphi/ZLib.pas
> zlib/contrib/dotzlib/DotZLib/UnitTests.cs
> zlib/contrib/infback9/inftree9.c
> zlib/contrib/minizip/configure.ac
> zlib/contrib/minizip/iowin32.c
> zlib/contrib/minizip/unzip.c
> zlib/contrib/minizip/zip.c
> zlib/contrib/pascal/zlibpas.pas
> zlib/contrib/puff/puff.c
> zlib/contrib/vstudio/readme.txt
> zlib/contrib/vstudio/vc10/zlib.rc
> zlib/contrib/vstudio/vc10/zlibvc.def
> zlib/contrib/vstudio/vc11/zlib.rc
> zlib/contrib/vstudio/vc11/zlibvc.def
> zlib/contrib/vstudio/vc12/miniunz.vcxproj
> zlib/contrib/vstudio/vc12/minizip.vcxproj
> zlib/contrib/vstudio/vc12/testzlib.vcxproj
> zlib/contrib/vstudio/vc12/testzlibdll.vcxproj
> zlib/contrib/vstudio/vc12/zlib.rc
> zlib/contrib/vstudio/vc12/zlibstat.vcxproj
> zlib/contrib/vstudio/vc12/zlibvc.def
> zlib/contrib/vstudio/vc12/zlibvc.sln
> zlib/contrib/vstudio/vc12/zlibvc.vcxproj
> zlib/contrib/vstudio/vc14/miniunz.vcxproj
> zlib/contrib/vstudio/vc14/minizip.vcxproj
> zlib/contrib/vstudio/vc14/testzlib.vcxproj
> zlib/contrib/vstudio/vc14/testzlibdll.vcxproj
> zlib/contrib/vstudio/vc14/zlib.rc
> zlib/contrib/vstudio/vc14/zlibstat.vcxproj
> zlib/contrib/vstudio/vc14/zlibvc.def
> zlib/contrib/vstudio/vc14/zlibvc.sln
> zlib/contrib/vstudio/vc14/zlibvc.vcxproj
> zlib/contrib/vstudio/vc9/zlib.rc
> zlib/contrib/vstudio/vc9/zlibvc.def
> zlib/crc32.c
> zlib/deflate.c
> zlib/deflate.h
> zlib/examples/gun.c
> zlib/examples/gzlog.c
> zlib/examples/zran.c
> zlib/gzguts.h
> zlib/gzlib.c
> zlib/gzread.c
> zlib/gzwrite.c
> zlib/infback.c
> zlib/inffast.c
> zlib/inflate.c
> zlib/inflate.h
> zlib/inftrees.c
> zlib/msdos/Makefile.dj2
> zlib/msdos/Makefile.emx
> zlib/old/Makefile.emx
> zlib/old/os2/Makefile.os2
> zlib/os400/README400
> zlib/os400/bndsrc
> zlib/os400/make.sh
> zlib/os400/zlib.inc
> zlib/qnx/package.qpg
> zlib/test/example.c
> zlib/test/infcover.c
> zlib/test/minigzip.c
> zlib/treebuild.xml
> zlib/trees.c
> zlib/uncompr.c
> zlib/win32/Makefile.gcc
> zlib/win32/Makefile.msc
> zlib/win32/README-WIN32.txt
> zlib/win32/VisualC.txt
> zlib/win32/zlib.def
> zlib/win32/zlib1.rc
> zlib/zconf.h
> zlib/zconf.h.cmakein
> zlib/zconf.h.in
> zlib/zlib.3
> zlib/zlib.3.pdf
> zlib/zlib.h
> zlib/zlib.map
> zlib/zutil.c
> zlib/zutil.h

2018-03-06 12:36:11 +0000
Chris Liddell <chris.liddell@artifex.com>
08482c582115a1396d0fd9186011008f889a61c5

> Work around a change in the zlib API for 1.2.11
> where it's used in the Freetype/zlib interface debugging code.
> freetype/src/gzip/zutil.h

2018-03-02 10:54:06 +0000
Ken Sharp <ken.sharp@artifex.com>
3da667d889e54fb1a323769fbb4f93b971d0fff4

> CCITT Fax - ensure calculation rounds up
> Still Bug #696413, follows on from commit 0221c9
> When calculating the number of bytes required to store the encoded lines
> we multiply the number of columns byt the number of bits required
> for 2 pixels, then divide by 16 to get the required number of bytes.
> This commit simply ensures that the division by 16 is rounded *up* and
> not down. Previously we could end up dropping up to 7 bits of required
> space. Generally this is not likely to be a problem but it is technically
> a problem, and can be demonstrated on pathological cases.
> base/scfe.c

2018-03-01 18:13:13 +0000
Ken Sharp <ken.sharp@artifex.com>
0221c9e4c43b25375dab6c9d15a777eecf20d261

> Fix CCITT Fax Encoder
> Bug #696413 "Seg faults found by fuzzing in pdf_store_page_resources (gdevpdfu.c:1663)"
> As noted it eh bug report, the problem is that the encoding buffer is
> allocated with a size based on the maximum number of bits for horizontal
> encoding (6 bits per pixel), but for 2D encoding some of the bits might
> use vertical encoding. Vertically encoded bits with an offset of 3 use
> 7 bits per pixel, not 6.
> If we get a line with sufficient 7-bit encodings, where the horizontal
> bits are encoded with 6 bits (eg runs of 1 pixel), then we can end up
> running off the end of the buffer. Make the allocation assume a maximum
> of 7 encoded bits per pixel instead.
> base/scfe.c

2018-02-27 20:56:07 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
e27f0530e3410547563daf757dc5c121c21d2f1c

> Bug 697545 : Fix memory leak in show_proceed.
> Fix memory leak and SEGV when gs_newpath returns an error code.
> Error created using :-
> MEMENTO_FAILAT=9017 ./membin/gpcl6 -sDEVICE=ppmraw -o /dev/null ./pcl/examples/owl.pcl
> base/gxchar.c

2018-02-27 21:12:12 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
49974a63cad8c792067fbf63905a271022b0e806

> Bug 697545 : Fix memory leaks in hpgl_print_char.
> Fix memory leak when pcl_mark_page_for_current_pos returns an error code.
> Also prevent path becoming orphaned in cpath_set_rectangle.
> Error created using :-
> MEMENTO_FAILAT=9010 ./membin/gpcl6 -sDEVICE=ppmraw -o /dev/null ./pcl/examples/owl.pcl
> base/gxcpath.c
> pcl/pcl/pglabel.c

2018-02-28 17:17:23 +0000
Ken Sharp <ken.sharp@artifex.com>
03194b72312b6777021f0554bdd30fecc89db486

> txtwrite - guard against infinite loop
> vertical text could result in an advance width of 0, which would cause
> us to try and write an infinite number of spaces.
> devices/vector/gdevtxtw.c

2018-02-28 14:04:32 +0000
Ken Sharp <ken.sharp@artifex.com>
d57bd7ce641d8134d559f5e8190e2578137e1d39

> txtwrite - better dynamic resizing
> A better fix for bug #699078, this implemnets the thought I had while
> writing up the description of the problem. In this case we check whether
> the current 'effective size' of the monospaced font would lead to
> the end of the current run of text lying to the right of the 'next' run
> of text on this line. If it would, then use the newly calculated
> effective size, no matter how small it is, to avoid collisions.
> devices/vector/gdevtxtw.c

2018-02-28 09:34:06 +0000
Ken Sharp <ken.sharp@artifex.com>
d0d4e282f98487ca2979edbaf6834d9341bcee53

> txtwrite - slacken a restriction on minimum width selection
> Bug #699078 " Extracted text is not properly seperated"
> Allow the minimum size assigned to the monospaced output to be smaller
> than previously (previously we limited it to .75 of the smallest point
> size of any used font).
> This will reduce the number of horizontal text collisions at the cost
> of potentially making the text output wider.
> Essentially this is caused by using a monospaced font to represent the
> original proportionally spaced input. A sufficiently long run of
> characters which are significantly less than the M width could result in
> the position being further to the right (when converted to monspaced
> text) than the neext horizontal fragment. So we wouldn't try to
> space it any further.
> Previously we limited the calculation of the minimum character size in
> a run to 3/4 of the M space. Here we reduce that to 1/2 which will
> permit more flexibility, but as stated, at the potential cost of the
> output text being 'wider' (containing more spaces).
> devices/vector/gdevtxtw.c

2018-02-26 21:25:19 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
a16736bc4ea251c46f1aa1d3b6176aadf5f0b914

> Bug 697545 : Update PCL to return error codes (Patch VI).
> Prevent numerous SEGV points by ensuring error codes are returned and
> handled appropriately.
> pcl/pl/plparams.c
> pcl/pl/pluchar.c

2018-02-25 20:36:29 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
50f7fc4f7a99d874af86e4a874067ba3a7760c42

> Bug 697545 : Update PCL to return error codes (Patch V).
> Prevent numerous SEGV points by ensuring error codes are returned and
> handled appropriately.
> pcl/pcl/rtraster.c
> pcl/pl/plchar.c
> pcl/pl/plht.c
> pcl/pl/pllfont.c

2018-02-23 18:02:47 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
0edcf910b80a1656c9441f32bd1770d2600ab915

> Bug 697545 : Update PCL to return error codes (Patch IV).
> Prevent numerous SEGV points by ensuring error codes are returned and
> handled appropriately.
> pcl/pcl/pginit.c
> pcl/pcl/pginit.h
> pcl/pcl/pglabel.c
> pcl/pcl/pglfill.c
> pcl/pcl/pgmand.h
> pcl/pcl/pgmisc.c
> pcl/pcl/pgpoly.c
> pcl/pcl/pgvector.c

2018-02-22 20:34:53 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
9f90d1361564289e6dbe56863a5fe1be1ca28f83

> Bug 697545 : Update PCL to return error codes (Patch III).
> Prevent numerous SEGV points by ensuring error codes are returned and
> handled appropriately.
> pcl/pcl/pgchar.c
> pcl/pcl/pgconfig.c
> pcl/pcl/pgdraw.c
> pcl/pcl/pgfdata.c
> pcl/pcl/pgfont.c
> pcl/pcl/pgframe.c

2018-02-23 14:35:57 +0000
Ken Sharp <ken.sharp@artifex.com>
6375e295893a71b5695fba2ca117747e326c8ec2

> pdfwrite - gracefully handle inappropriate PDFA command line
> If a user sets -dPDFA, but does not set ColorConversionStrategy, and
> then processes an input file which has a DeviceN space with an alternate
> space which does not match the ProcessColorModel, then we would write
> an invalid PDF file (invalid function for the colour space).
> Now technically this shouldn't happen, but we can guard against this
> specific user error by spotting the problem and returning a rangecheck
> error instead, which will cause the earlier code to fall back to
> writing a device colour instead.
> No diffrences expected.
> devices/vector/gdevpdfc.c

2018-02-20 22:13:51 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
03607549d598b14ebbb6d4aea9591e10fc35c6cc

> Bug 697545 : Update PCL to return error codes (Patch II).
> Prevent numerous SEGV points by ensuring error codes are returned and
> handled appropriately.
> pcl/pcl/pcsfont.c
> pcl/pcl/pcsymbol.c
> pcl/pcl/pctext.c
> pcl/pcl/pctop.c
> pcl/pcl/pcuptrn.c

2018-02-20 18:40:37 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
de2c3c2c536d5aff97091b146ed259270228dcb9

> Bug 697545 : Update PCL to return error codes (Patch I).
> Prevent numerous SEGV points by ensuring error codes are returned and
> handled appropriately.
> pcl/pcl/pccolor.c
> pcl/pcl/pcdraw.c
> pcl/pcl/pcfontpg.c
> pcl/pcl/pcindxed.c
> pcl/pcl/pcjob.c
> pcl/pcl/pcmacros.c
> pcl/pcl/pcpalet.c
> pcl/pcl/pcparse.c
> pcl/pcl/pcpatrn.c

2018-02-14 17:26:23 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
8f2f27a730fc7ba76847d39fc46d6d7183cd27a3

> Bug 697545 : Fix memory leaks during font loading.
> Fix memory leaks for numerous allocation events.
> Error created using :-
> MEMENTO_FAILAT=1564 ./membin/gpcl6 -sDEVICE=ppmraw -o /dev/null ./pcl/examples/owl.pcl
> base/gstype42.c
> base/gxfapi.c
> pcl/pl/plfapi.c
> pcl/pl/plfont.c
> pcl/pl/pllfont.c

2018-02-18 16:05:18 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
cceb3db394d9547d309f596001b02c63dec4d7f5

> Bug 697545 : Fix memory leak in gx_path_new.
> During a memory allocation event failure the orginal path would not be
> decremented and hence become orphaned.
> Error created using :-
> MEMENTO_FAILAT=8959 ./membin/gpcl6 -sDEVICE=ppmraw -o /dev/null ./pcl/examples/owl.pcl
> base/gxpath.c

2018-02-19 15:43:20 +0000
Ken Sharp <ken.sharp@artifex.com>
3f5736cb8a255cdfe00d59896dc39d050d1db00e

> Add more bounds checking to type 2 font interpreter
> Bug #699042 "stack out of bounds read in gs_type2_interpret, gstype2.c line 701"
> The warning is caused by 'csp' being below the cstack bottom bound.
> Adding a check for that prevents this warning. While we're here, add
> checks to the bounds of 'transient_array' which wasn't being checked
> previously.
> base/gstype2.c
> base/gxtype1.h

2018-02-19 14:26:29 +0000
Ken Sharp <ken.sharp@artifex.com>
cc2bfef83b1dca09e016e43238f71ca6c7a622b3

> PDF interpreter - fix ToUnicode processing of bfrange with high byte set
> Bug #699041 "Cyrilic text not respected"
> The title is a misnomer, the problem is not Cyrillic fonts as such.
> The example file has an unusually complex ToUnicode CMap, which includes
> bfrange entries where the CID has a value > 0xFF. The code in pdf_font.ps
> to create our internal GlyphNames2Unicode table was adding the 'offset'
> (The high byte of the index) to the CID, which basically means we were
> adding the high byte twice (the key already included the high byte).
> Fix this by simply not adding the offset to the keys.
> Its surprisingly hard to find examples of this, I can't immediately see
> any in our test suite. I have gone through some of the files which
> have been reported as problems with ToUnicode processing in the past
> but none of them fall into this condition.
> A couple of files show difference, but these are irrelevant, they are of
> the 'wrong before, differently wrong now' category.
> Resource/Init/pdf_font.ps

2018-02-18 14:18:10 +0000
Ken Sharp <ken.sharp@artifex.com>
eb2aa457387429b84c043430354b8476ac918961

> Squash a couple of build warnings
> Sort out negation of the PDFA flag
> Ensure a variable is initialised under all conceivable circumstances
> devices/vector/gdevpdtd.c
> devices/vector/gdevpdtt.c

2018-02-16 19:32:11 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
f006720c87026a67cdcaeab983fe888d4401cb0e

> Bug 697545 : Prevent SEGV by returning error codes.
> Prevent numerous SEGV points by ensuring error codes are returned and
> handled appropriately.
> Error created using :-
> MEMENTO_FAILAT=8961 ./membin/gpcl6 -sDEVICE=ppmraw -o /dev/null ./pcl/examples/owl.pcl
> pcl/pcl/pgconfig.c
> pcl/pcl/pgframe.c

2018-02-16 18:56:23 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
833333a6df506ad9525bb797245042442a0f31cb

> Bug 697545 : Prevent SEGV in palette_do_reset.
> Prevent SEGV when trying to access contents of empty palette.
> Error created using :-
> MEMENTO_FAILAT=8956 ./membin/gpcl6 -sDEVICE=ppmraw -o /dev/null ./pcl/examples/owl.pcl
> pcl/pcl/pcpalet.c

2018-02-16 18:39:30 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
0ebfdae6fceedbbe7036c487916193b4349d4dd3

> Bug 697545 : Fix memory leak in alloc_indexed_cspace.
> Fix memory leak for allocation event 8953.
> Error created using :-
> MEMENTO_FAILAT=8954 ./membin/gpcl6 -sDEVICE=ppmraw -o /dev/null ./pcl/examples/owl.pcl
> pcl/pcl/pcindxed.c

2018-02-13 15:53:09 -0800
Ray Johnston <ray.johnston@artifex.com>
9f9daedfdf98bab590eba53e34fba76b96307ec0

> Fix Bug 698969 SEGV caused by overflow in mark_line_*** functions
> Clipping needs to be performed in 64-bit to allow for the original
> line segment being larger than can fit in signed 32-bit.
> base/gxscanc.c

2018-02-16 10:29:00 +0000
Ken Sharp <ken.sharp@artifex.com>
ad07c06b7f898eeb663ee7eed336c2c602a91551

> pdf_info.ps - check for null DescendantFonts after oforce
> pdf_info.ps was modified to check for circular references when resolving
> indirect objects. Now if we find recursion we return a null.
> However, we weren't checking that when resolving DescendantFonts which
> could lead to a typecheck error if we had two different CIDFonts on
> the same page, and the CIDFonts used the same DescendantFonts array
> (which is silly, of course).
> toolbin/pdf_info.ps

2018-02-15 10:15:28 -0700
Henry Stiles <henry.stiles@artifex.com>
6a8c1d6be02fc7020ab4cf5cfbecf91790f7dc10

> Bug 696654 - PCL/PXL fails to build with system-shared libjpeg.
> Remove the HP CLJ 3500/3500/3600 emulation until it can be properly
> integrated with libjpeg.
> base/gdevpxat.h
> base/gdevpxen.h
> pcl/pxl/pxl.mak
> pcl/pxl/pxptable.c
> pcl/pxl/pxsessio.c
> pcl/pxl/pxstate.h
> pcl/pxl/pxvendor.c
> pcl/pxl/pxvendor.h

2018-02-15 14:36:10 +0000
Ken Sharp <ken.sharp@artifex.com>
094aebef5c058ad312e5d2bfd46d897c21fac398

> pdfwrite - remove dead code
> Commit efb9bf3949617b4c733a6dcce04acd142c50115d changed the flow of
> control to avoid going through code which could not work, since it left
> a variable unassigned (and didn't do any part of the work that would
> be required to give the variable a sensible value).
> That left some code unreachable leading to a coverity warning (Coverity
> ID 262411). I was unable to find any way to trigger the original
> condition, and the code as it stands should at least work, even if it
> might be sub-optimal in some cases. So remove the dead code to prevent
> the warning, if this needs fixing in future there will need to be more
> code written anyway.
> devices/vector/gdevpdfb.c

2018-02-15 09:02:01 +0000
Ken Sharp <ken.sharp@artifex.com>
4384f85cbb9383cbeefea80e45e8893a5d64c7af

> PDF interpreter - remove a debug pstack
> accidentally left some debugging code in place, remove it now.
> Resource/Init/pdf_main.ps

2018-02-14 17:01:21 +0000
Ken Sharp <ken.sharp@artifex.com>
7d1b64fe9474d4c1e6d5f4185c77cb42a8ac5bc0

> Remove a long obselete C source file
> Also remove a documentation reference and Windows project references
> doc/Develop.htm
> psi/zhsb.c
> windows/ghostscript.vcproj
> windows/ghostscript_rt.vcxproj

2018-02-14 17:26:23 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
ecf45b80c55bc79c17bed5143426cd9f8060ec2f

> Bug 697545 : Fix memory leaks during tt font loading.
> Fix memory leak for allocation event numbers 1551, 1552 and 1553.
> Error created using :-
> MEMENTO_FAILAT=1554 ./membin/gpcl6 -sDEVICE=ppmraw -o /dev/null ./pcl/examples/owl.pcl
> pcl/pl/plfont.c
> pcl/pl/pllfont.c

2018-02-14 15:38:42 +0000
Ken Sharp <ken.sharp@artifex.com>
bb8f0822a31e0e976cb659000532fde2fdbccd8c

> PDF interpreter - detect and ignore circular references in Outlines
> Bug #699029 "infinite loop on pdfium test file"
> If the /Next in an Outline points to any previously encountered
> Outline entry, terminate processing of Outlines and warn the user.
> Resource/Init/pdf_main.ps

2018-02-14 10:28:37 +0000
Ken Sharp <ken.sharp@artifex.com>
06ceaa2715fcbe2056214b0f958edc7deb4fa085

> pdfwrite - improve stack bounds checking on font interpreters
> Bug #699020 "stack buffer underflow (read) in gs_type2_interpret / gstype2.c line 567"
> The internal type 1 and type 2 font interpreters are only used by
> the vector devices (in particular pdfwrite), for rendering we use
> FreeType.
> This commit improves the bounds checking of the operand stacks used
> by these interpreters, to catch more cases of badly formed or
> corrupted fonts and throw an error in these cases.
> This addresses the stated bug, but should actually prevent a lot
> more problems which we haven't yet seen test cases for.
> base/gstype1.c
> base/gstype2.c
> base/gxtype1.h

2018-02-13 12:00:10 +0000
Ken Sharp <ken.sharp@artifex.com>
c1a8dc52c0e320c41d04b6f32086622150962d61

> fix commit bcef41ad72a16472a3003d357bf8d8680174ab85
> Accidentally left currentdict on the operand stack afetr startup.
> Resource/Init/gs_init.ps

2018-02-13 10:48:16 +0000
Chris Liddell <chris.liddell@artifex.com>
16586a6a0d8fac17d5201f102e0775e527d3a529

> Bug 699019: bounds check stack access in Type 2 vmoveto
> base/gstype2.c

2018-02-13 10:22:56 +0000
Ken Sharp <ken.sharp@artifex.com>
bcef41ad72a16472a3003d357bf8d8680174ab85

> PS interpreter - fix setpagedevice with -dDELAYBIND
> When a user sets a fixed resolution using -r, then the setpagedevice
> code looks for the existence of a /HWResolution key in the page device
> dictionary and attempts to remove it using .undef to prevent the
> resolution being altered.
> However, if DELAYBIND is set, then the .undef operator is removed
> before .bindnow is run, which means that, when setpagedevice executes,
> the .undef operator is not defined.
> So add the same code for .undef as we use for other similar operators
> (eg .forceundef), don't remove the definition if DELAYBIND is set, but
> do remove it when .bindnow executes.
> This is, of course, a security hole, but then the whole DELAYBIND
> situation is.
> While we are here, add a key /NOBIND with the value false to systemdict.
> This is because some ancient, badly-behaved and no longer maintained
> software checks this key unconditionally, if its not present it fails
> with an undefined error. Setting it to false pacifies that software.
> Resource/Init/gs_init.ps

2018-02-13 08:52:32 +0000
Chris Liddell <chris.liddell@artifex.com>
310a0bcaba3527903fc66fed2984f30d0bd4e4ab

> Bug 699016: add stack bounds check for Type 1 seac
> The macro for checking the stack bounds is now called from both the Type 1 and
> Type 2 charstring code, so move it to a common header, and tweak the name to
> fit.
> base/gstype2.c
> base/gxtype1.c
> base/gxtype1.h

2018-02-13 08:35:22 +0000
Chris Liddell <chris.liddell@artifex.com>
9bbf14bc7210bc54613b0f64a5ad95368891982a

> Bug 699015: bounds check stack for Type 2 callsubr
> base/gstype2.c

2018-02-12 21:47:29 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
0e9ba7084176c7834db00927a8326310c6b83a67

> Fix memory leak in xps_imp_set_device.
> The param list can become orphaned if an error occurs early on in the code.
> xps/xpstop.c

2018-02-11 20:44:04 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
5e9639e974afaa89027a5ccd573e50ff98e3ca3f

> Bug 697545 : Fix memory leak in pcl_load_built_in_symbol_sets.
> Fix memory leak for allocation event number 1266.
> Error created using :-
> MEMENTO_FAILAT=1267 ./membin/gpcl6 -sDEVICE=ppmraw -o /dev/null ./pcl/examples/owl.pcl
> pcl/pcl/pcsymbol.c

2018-02-11 20:20:36 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
3e4c6beff724a4e0078a48e6f5200c23ae73f52b

> Bug 697545 : Fix memory leak in pl_top_create_device.
> The param list can become orphaned if an error occurs early on in the code.
> Error created using :-
> MEMENTO_FAILAT=676 ./membin/gpcl6 -sDEVICE=ppmraw -o /dev/null ./pcl/examples/owl.pcl
> pcl/pl/plmain.c

2018-02-12 15:23:19 +0000
Chris Liddell <chris.liddell@artifex.com>
a4445fe0a312af901a79d6f41ace975a50d88a31

> Bug 699012: bounds check point index in Move_Zp2_Point()
> base/ttinterp.c

2018-02-12 12:05:44 +0000
Chris Liddell <chris.liddell@artifex.com>
e7abbb92e92ba326b4fc06491bd3c3cde61932b3

> Bug 699013: Check glyph has a contour before accessing it.
> in Ins_IUP()
> base/ttinterp.c

2018-02-12 15:20:23 +0000
Ken Sharp <ken.sharp@artifex.com>
edf3684305414731fbdb9b90de7dbcbab0dace5f

> Fix comments
> The comments in zinitgrpahics and the PostScript definition of
> initgraphics in gs_cspace.ps were incorrect, now that gs_initgraphics
> does reset the colour space properly.
> However, we do still need the /initgraphics override in gs_cspace.ps
> in order to correctly set the colour space which we store in the
> 'interpreter' graphics state. We only use that to hand back in response
> to a currentcolorspace, but we do need it.
> Resource/Init/gs_cspace.ps
> psi/zgstate.c

2018-02-12 13:47:18 +0000
Ken Sharp <ken.sharp@artifex.com>
b7a0556297296d8355748b9b130de02923a1c4cd

> Check for error case in gs_cspace_new_ICC()
> If we fail to allocate memory for a new colour space, simply return
> NULL, don't try to use the failed allocation!
> base/gscspace.c

2018-02-12 12:21:50 +0000
Ken Sharp <ken.sharp@artifex.com>
7a708d9fdcba9efbe21f236830e47eb4f4085672

> More work with initgraphics
> Firstly, remove the kludgy gs_initgraphics_no_cspace() and have the
> PostScript operator zinitgraphics() call gs_initgraphics().
> This meant fixing the gs_initgraphics routine; the previous commit
> d527031607a881237819835c2b1045c81e24c387 simply overwrote the existing
> colour spaces in the graphics state with the new DeviceGray space. This
> could lead to memory leaks if the previous colour space had been
> reference counted up. So now we call gs_setcolorspace instead, which also
> correctly sets the current colour.
> This led to the interesting discovery that the null brush in PXL has
> never been handled properly by the high level devices. This is
> handled by the PXL interpreter setting a DeviceGray colour space, and
> then directly editing the device colour 'type' field and setting it to
> 'typ_null'. This doesn't seem like the best way to proceed to me, I
> would have expected us to push the nulldevice, but its what is done.
> No in gx_hld_is_hl_color_available() the code simply tested whether
> the device color 'ccolor_valid' flag was set. Since the PXL interpreter
> simply stomped on the type field, and did not update any of the other
> fields, the result of this was unknown. Sometimes we would decide it
> was valid, and sometimes not. If we did decide it was valid then we
> used the DeviceGray space and colour (0, black) which was also set up
> by the null brush code to draw the object, which means that we could
> end up drawing objects which should not be drawn.
> 'Fixed' this by having the code explicitly test for the device color
> type being 'null' as well as being valid. In passing, it did appear
> to me that we do not always update the ccolor_valid flag in the device
> color structure, which may well lead to more problems of this kind.
> This does result in a number of differences in the output. Mostly
> these are due to the error page now always being rendered in DeviceGray
> which results in a slightly (invisible) difference in printed gray text.
> A very large number of the Quality Logic files exhibit progressions
> due to the fact that we are now correctly processing the null brush.
> base/gsstate.c
> base/gxhldevc.c
> psi/zgstate.c

2018-02-04 18:45:26 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
1af4fced38d9d842195e5635c9e0aa4b5e13f21b

> Bug 697545 : Fix memory leak in pcl interpreter.
> If an error occurs during pl_set_device then the new interpreter is partially
> set up but the old interpreter is still listed as current so the cleanup
> code does not reclaim the partially set up memory. The patch ensures the
> correct interpreter is cleaned up and also zeros out unset fields to prevent
> a SEGV during memory freeing.
> Fix memory leak for allocation event number 1265.
> Error created using :-
> MEMENTO_FAILAT=1266 ./membin/gpcl6 -sDEVICE=ppmraw -o /dev/null ./pcl/examples/owl.pcl
> pcl/pcl/pctop.c
> pcl/pl/plmain.c

2018-02-10 22:28:04 -0800
Ray Johnston <ray.johnston@artifex.com>
98d8f8d12a40bf36f0acdaefc0c63a7562326cab

> Fix compile warning about possible uninitialized procedure pointers
> Setting to NULL is OK since it will trigger a SEGV, but it looks
> like the code will always set the procedures if it needs the source
> colors.
> base/gdevmpla.c

2018-02-10 11:43:15 -0800
Ray Johnston <ray.johnston@artifex.com>
2fe4c53757ef143071517216cacdbb228dfc4243

> Fix compiler warning: mlut_size
> This is OK because mlut_size is only used when 'clut' is non-NULL
> but if so, it is initialized in line 1179.
> base/gsicc_create.c

2018-02-10 11:28:48 -0800
Ray Johnston <ray.johnston@artifex.com>
d3fb0f876971f604597c10519259520a8035cb58

> Fix gcc warning: gscms_is_threadsafe prototype
> base/gsicc_cms.h
> base/gsicc_lcms2.c
> base/gsicc_lcms2art.c

2018-02-06 11:53:24 -0800
Ray Johnston <ray.johnston@artifex.com>
01a71ecbfe576d0a840946a0089f23ce131e995d

> Change from CMM_THREAD_SAFE #define to a gscms_is_threadsafe function
> In preparation for enabling sharing the profiles and link cache among
> rendering threads, switch from a compile time flag to a function that
> is returned by the CMS interface module linked in (e.g gsicc_lcms2.c)
> This avoids more build machinery to propagate the flag, and ensures
> that the flag won't be mis-matched to the CMS in use.
> Also flag a few FIXME places identified that relate to multi-threaded
> sharing of profiles and the profile link cache. Initially, even though
> lcms2art is thread safe, return "false" until the multi-threaded
> rendering works.
> base/gdevp14.c
> base/gsicc_cms.h
> base/gsicc_lcms2.c
> base/gsicc_lcms2art.c
> base/gxcldev.h
> base/gxclthrd.c

2018-02-10 10:59:29 +0000
Ken Sharp <ken.sharp@artifex.com>
da66356a665432f998642b2e9c45756f876f0996

> PCL interpreter - correctly identify high level devices
> Pointed out by Chris, the code in here explicitly tested the name of the
> device to decide if it was a high level device. We deprecated that
> approach some time ago, replacing it with a spec_op call instead.
> The comment said 'this needs a better solution' and this is it.
> Should work correctly now with any device which identifies itself as a
> high level device.
> pcl/pl/plmain.c

2018-02-08 13:57:54 -0700
Henry Stiles <henry.stiles@artifex.com>
4b4a301c90a8905d6b7ba703342ddc9cb1c8ff69

> Fix 694689 - Seg faults found by fuzzing.
> Allow clients of the decompression routines to pass in a parameter to
> indicate no further input or output is expected. The decompression
> routines should produce an error if the parameter is set and more
> processing is needed. The pattern code uses this to indicate indicate
> the final scanline has been processed, it is not needed by the image
> code.
> pcl/pxl/pximage.c

2018-02-07 17:03:04 -0700
Henry Stiles <henry.stiles@artifex.com>
8e4764d61562a44c77920ee67884ca846184b25c

> Add line pointer to the pattern enumerator.
> This tracks the scan line position within the pattern while reading,
> simplifying bounds checking.
> pcl/pxl/pximage.c

2018-02-05 13:28:52 -0700
Henry Stiles <henry.stiles@artifex.com>
faef871274167e12e93fc24026096474d00b794d

> Remove pushed argument.
> No need to push the filename simply run the file and use a do while
> loop.
> pcl/pl/plmain.c

2018-02-02 10:35:28 -0700
Henry Stiles <henry.stiles@artifex.com>
f29e2296e81378ed42b93215137361ab586b2393

> Warning cleanup.
> pcl/pcl/pcpalet.c
> pcl/pcl/pcparse.c
> pcl/pcl/pglabel.c
> pcl/pl/pllfont.c
> pcl/pxl/pxtop.c

2018-02-07 21:08:46 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
b808ea741efe357cf71254d9064e782dfd753584

> Bug 697545 : Fix memory leak in gs_state_alloc.
> The colour allocation code in gs_gstate_alloc was being repeated in the call
> to gs_initgraphics leading to the first set of allocated colours becoming
> orphaned. Given that gs_initigraphics is always called from gs_gstate_alloc
> the duplicate code can be safely removed.
> Error created using :-
> MEMENTO_FAILAT=419 ./membin/gpcl6 -sDEVICE=ppmraw -o /dev/null ./pcl/examples/owl.pcl
> base/gsstate.c

2018-02-06 18:04:07 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
98e5b234b27d82e52d660a9e0bfc6c14e3d7a5cd

> Bug 697545 : Prevent SEGV in pcpage_do_reset.
> Prevent SEGV if memory allocation fails and returns a NULL paper size.
> Error created using :-
> MEMENTO_FAILAT=1215 ./membin/gpcl6 -sDEVICE=ppmraw -o /dev/null ./pcl/examples/owl.pcl
> pcl/pcl/pcpage.c

2018-02-07 15:46:28 +0000
Ken Sharp <ken.sharp@artifex.com>
10dcb4943e552a3d53fbaf0b4e8741258238f7a7

> Handle a potential error condition in PXL
> Bug #698995 "Fixing error returns in gxicolor.c can cause PXL to enter an infinite loop or seg fault"
> This started off as a fix to a scanbuild warning and spiralled somewhat.
> Fixing gs_image_class_4_color() so that it didn't ignore an error return
> led to the possibility of the PXL interpreter seg faulting or ending up
> in an infinte loop.
> Initially this turned out to be because gs_initgraphics() was no longer
> setting the colour space to the proper default, leading to us trying
> to use the very pattern space which failed. That was fixed in the
> previous commit.
> After that it turned out that in an error condition we were freeing
> an image enumerator twice. This didn't seem to cause the PostScript
> interpreter a problem, though it seems likely it did really, it simply
> didn't exhibit before the interpreter exited. The PXL interpreter
> however threw an error in the memory manager rather rapidly.
> Fixed that by not calling gx_default_end_image in gx_enum_begin()
> when we hit this particular error condition (no handler for an image).
> This removes one of the free instances, and seems more reasonable anyway
> it seems wrong to end an image we haven't yet begun.
> This allows us to now propagate the error up from px_remap_pattern
> without causing a seg fault or infinite loop. (finally)
> base/gxipixel.c
> pcl/pxl/pxink.c

2018-02-07 09:55:41 +0000
Ken Sharp <ken.sharp@artifex.com>
d527031607a881237819835c2b1045c81e24c387

> Alter gs_initgraphcis to once again set the colour space and colour
> At some time in the past gs_initgraphics was altered for 'colour substitution'
> so that it did not reset the colour space and current colour. This is
> surprising because the PostScript initgraphics operator is supposed to
> do exactly that.
> Restoring the code resulted in many seg faults with the PDF interpreter
> so this is obviously a requirement, even though I can't see why.
> However, leaving gs_initgraphics as it is would mean that (as per the
> comment above the procedure) that all the interpreters (clients) would
> have to reset the colour space and colour after calling it, which is
> entirely unreasonable. Not only that, it hasn't been done leading to
> the PXL interpreter printing error pages in the wrong colour.
> This commit restores the setting of the colour space and colour to
> gs_initgraphics, but introduces a new gs_initgraphics_no_cpsace()
> procedure to be called from zinitgraphics, which behaves exactly as
> the modified gs_initgraphics did, and does not set the colour space
> or colour values.
> The PDF interpreter now continues to work and the PXL interpreter now
> prints a number of error pages in black where it previously was using a
> pattern, grey or in one case green colour.
> base/gsstate.c
> base/gsstate.h
> psi/zgstate.c

2018-02-07 09:49:34 +0000
Ken Sharp <ken.sharp@artifex.com>
28c58b4114ec145b8597372b6e29cec9e1f5df15

> Yet more scanbuild warnings
> gxhintn.c remove some unnecessary assignemnts
> gxicolor.c remove an assignement, add an error check
> gximono.c add an error check
> gxiscale.c refactor code to remove some unnecessary assignments
> gdevpsft.c remove unnecessary assignment
> base/gxhintn.c
> base/gxicolor.c
> base/gximono.c
> base/gxiscale.c
> devices/vector/gdevpsft.c

2018-01-29 15:32:34 +0000
Robin Watts <robin.watts@artifex.com>
1b1015dc0e07b5269c4ee2009d5b896702550a3a

> Tweak scale parameters in structure.
> Be consistent with naming. Add PatchHeightOut and TopMarginOut so
> we have the complete set. These are required for forthcoming work.
> base/gxiscale.c
> base/sidscale.c
> base/siscale.c
> base/sisparam.h
> devices/vector/gdevpsdi.c

2018-02-02 12:48:07 +0000
Robin Watts <robin.watts@artifex.com>
38e0c643e62087c089c59c9ad44fc468dd09cd37

> Tweak bitmap interpolater patch size.
> When we interpolate an image, we restrict the interpolation to
> the "patch" of the destination image that is actually visible.
> Previously, the calculation of this patch has been inaccurate,
> resulting in a larger area being decoded than was actually
> needed.
> While this extra work was largely mitigated by the "Active" area
> detection code, it has meant that the contribution calculations
> within the scaler were 'wrapping' the outside pixels in the
> region to avoid accessing out of bounds.
> This upsets the new library we are working on to do the scaling,
> and it's basically inelegant. Instead we fix the destination
> patch calculations so that the patch is correctly sized based
> upon the available source data. This is safe to do because we
> know the source data was already expanded.
> base/gxiscale.c
> base/sisparam.h

2018-02-06 11:46:56 +0000
Ken Sharp <ken.sharp@artifex.com>
f6005484617ada241d2f5f4deee4808616474831

> Address more scanbuild/gcc/clang warnings
> gdevkrnlsclass.c Change a while...do into a do...while to see if it
> pacifies a 'dereference of NULL pointer' in scanbuild
> gsparamx.c Incorrect return code could lead to an earlier error not
> being preserved. Fortunately this is currently only called by claptrap.
> gsptype1.c remove unnecessary assignments
> gssprintf.c " " "
> gstype2.c " " "
> gstype42.c " " "
> gxfill.c " " "
> gsptype2.c rejig the code to avoid setting a return code that isn't used.
> Add a check on a return code that was missing.
> gxchar.c add return code checking
> gxcmap.c " " " "
> base/gdevkrnlsclass.c
> base/gsparamx.c
> base/gsptype1.c
> base/gsptype2.c
> base/gssprintf.c
> base/gstype2.c
> base/gstype42.c
> base/gxchar.c
> base/gxcmap.c
> base/gxfill.c

2018-02-06 10:30:32 +0000
Ken Sharp <ken.sharp@artifex.com>
16688a8b833cf4e8950265e933604c32b1f2392e

> Address more scanbuild/gcc/clang warnings
> gp_os2.c free buffer and close file on memory full (as per other
> error conditions).
> gscicach.c remove unnecessary assignment
> gsdparam.c " " " "
> gxfapi.c " " " "
> gscscie.c check a return code
> zicc.c " " " "
> zpcolor.c " " " "
> mkromfs.c If realloc should fail in process_path, free working memory
> print an error and exit as per other error conditions.
> zcolor.c ensure depth cannot be 0. This should not be possible, no
> existing code causes this, but its best to be safe and it prevents a
> possible unassigned pointer dereference (possibly NULL) which is what
> scanbuild complains of. Best to catch this in the interpreter.
> base/gp_os2.c
> base/gscicach.c
> base/gscscie.c
> base/gsdparam.c
> base/gxfapi.c
> base/mkromfs.c
> psi/zcolor.c
> psi/zicc.c
> psi/zpcolor.c

2018-02-05 16:09:28 +0000
Ken Sharp <ken.sharp@artifex.com>
650aae633131396b802b2cae6e09afbd5aae6ad6

> Coverity ID #261212
> This probably showed up because of Ray's work adding return value
> checking. Previously there were probably enough places not checking
> the return code for Coverity to decide it was deliberate, now it is
> raising a warning.
> Add a check and take action on an error return.
> psi/zcrd.c

2018-02-05 16:08:25 +0000
Ken Sharp <ken.sharp@artifex.com>
d7a5f0a14e873c7f5f557c4b635f4b4f166b41d2

> Coverity ID #261211 - unchecked return value
> This probably showed up because of Ray's work adding return value
> checking. Previously there were probably enough places not checking
> the return code for Coverity to decide t was deliberate, now it is
> raising a warning.
> Add a check of the return code.
> devices/vector/gdevpsdi.c

2018-02-05 15:34:58 +0000
Ken Sharp <ken.sharp@artifex.com>
b8e36896913713f46a43dbbc0c0ed83f34ab4f10

> Try to squash 3 identical scanbuild warnings
> I think scanbuild is deciding that 'depth' could be less than 0, leading
> us to not enter the loop which assigns 'obj'. This is not true, the
> depth cannot be less than 0.
> Try making 'depth' an unsigned int as a hint to scanbuild, and see if
> the warning goes away.
> psi/zcolor.c

2018-02-05 15:32:44 +0000
Ken Sharp <ken.sharp@artifex.com>
88e7812d362483d07ce63b47ae75c4852fe01a8f

> txtwrite - honour error conditions
> 2 warnings from scanbuild, we were ignoring a potential error return in
> two places.
> devices/vector/gdevtxtw.c

2018-02-05 11:55:11 +0000
Ken Sharp <ken.sharp@artifex.com>
9c38c79741193010b23dabceb76996488415bd09

> Clean up another scanbuild warning
> We increment a local variable just before it goes out of scope, which is
> clearly pointless.
> devices/vector/gdevpsft.c

2018-02-05 11:54:14 +0000
Ken Sharp <ken.sharp@artifex.com>
0b4c59be1793c81e9d8cfeba04e74b6020571f5d

> Fix another scanbuild warning
> We don't seem to have any test cases which hit this, but it does look
> possible from the code that we can end up trying to dereference
> p_tile, and we don't check to see if its not NULL, which we do in a
> lot of other places in this fucntion.
> To be safe, test it first and return an error if its NULL.
> devices/vector/gdevpdfv.c

2018-02-05 10:39:21 +0000
Ken Sharp <ken.sharp@artifex.com>
5d9d4bc1bbd272478bb9fd24fc1c0e44b0edc22a

> Remove an unused function, clear a scanbuild warning
> The function cos_write_stream_from_pipeline was never used, so remove
> its definition.
> At the same time try to squash a harmless scanbuild warning. We us a
> 'while(s....' loop to try and find a stream, scanbuild regards this as
> implying that 's' might be NULL *initially*, which is not true. This
> leads to a 'NULL pointer dereference' warning in the line after the
> loop, because scanbuild thinks we can get to s->state with s being an
> inital NULL.
> Since we already check for s becoming NULL inside the loop, we don't
> need to check it in while condition.
> devices/vector/gdevpdfo.c

2018-02-05 10:35:16 +0000
Ken Sharp <ken.sharp@artifex.com>
43b2b593743433f45590b02b788c54d6bcf563a7

> Prevent potential garbage pointer dereference
> Picked up by scanbuild, if pdf_enter_substream failed then pres would be
> left uninitialised, but we would then try to dereference it and assign a
> value to a member before acting on the error return code.
> Change the order of execution to test the return code first.
> devices/vector/gdevpdti.c

2018-02-05 09:43:01 +0000
Ken Sharp <ken.sharp@artifex.com>
efb9bf3949617b4c733a6dcce04acd142c50115d

> Remove faulty code picked up by scanbuild
> scanbuild correctly warned that a variable was uninitialised. In fact
> it looks to me like the code that was flagged simply can't work.
> Fortunately it isn't exercised by any files in our test suite, and has
> never been reported as a bug, so its clearly an uncommon (perhaps even
> impossible) case.
> All the same, lets fall back to the default handling if we hit it,
> because at least that works, which the old code definitely didn't.
> devices/vector/gdevpdfb.c

2018-02-05 09:40:50 +0000
Ken Sharp <ken.sharp@artifex.com>
ba6d8c5ec0fa27822041cb3bbc620e531fabcf0a

> remove a scanbuild warning
> We don't care about errors in this case, we are already aborting due
> to an error. So just discard the status return.
> devices/vector/gdevpdfj.c

2018-02-03 10:46:23 +0000
Ken Sharp <ken.sharp@artifex.com>
b119c51e5ce8d671bc33e38b7ebf7a5bdf5f9af5

> Remove unused variable
> another scanbuild warning
> base/gsdevice.c

2018-02-03 10:26:18 +0000
Ken Sharp <ken.sharp@artifex.com>
dde422bb086ce0b2f56609fa3fc9af87867fc757

> partially revert 07f9da3cb5647b18458cd52d1be35ab5365790eb
> This was a scanbuild false positive, the original code was in fact
> correct.
> base/gdevkrnlsclass.c

2018-02-02 15:29:09 +0000
Ken Sharp <ken.sharp@artifex.com>
fa4941c607680159ed62bfe79b754a099adf5a4e

> squash more scanbuild warnings
> check some return values.
> Remove some initialisations that aren't required.
> Remove soem unused variables.
> base/gsdparam.c
> base/gsfunc0.c
> base/gsht.c
> base/gsht1.c

2018-02-02 14:43:23 +0000
Chris Liddell <chris.liddell@artifex.com>
3f38e3eeb6e6e7d88abbe1dca7675e237d5274e7

> Remove spurious semi-colons introduced in 63f0fcc87e7c
> I mistakenly left the trailing semi-colon in the macros defining the contents
> of two pairs of structures.
> Oddly, this caused a warning on VS2017, but not gcc/clang.
> Thanks to Shailesh Mistry for pointing it out.
> pcl/pl/pjparse.c

2018-02-02 13:11:05 +0000
Chris Liddell <chris.liddell@artifex.com>
452efeca35ee7e3fe381cae9a71d6efbcce68cd0

> Address warning in gdevbit.c
> Fix the "missing braces in initializer" warning - the explicit declaration of
> the gs_bitrgbtags_device initializer had gotten out of step with the
> gx_device_printer_s definition.
> devices/gdevbit.c

2018-02-02 14:10:44 +0000
Ken Sharp <ken.sharp@artifex.com>
9036e05dfbcfa7968e00a53ef7ae9f6146740e94

> Remove the 'device filter chain'
> This was an early attempt to allow the possibility of 'chaining'
> devices together. I believe it was never actually completed, although
> the stack existed and was carefully preserved in the graphcis state,
> the only code which accessed it was '.popdevicefilter'.
> No C code or PostScript code ever actually pushed a device onto the
> device filter stack, and nothing ever examined the stack to pass
> operations through the 'chain'.
> Since its been superseded by device subclassing, and didn't actually
> seem to do anything anyway, remove it altogether. In addition to
> removing clutter this also reduces the amount of 'magic' surrounding
> reference counted objects in gstates.
> base/gdevp14.c
> base/gsgstate.c
> base/gsstate.c
> base/gxgstate.h
> base/lib.mak
> doc/Develop.htm
> doc/who_owns_what.txt
> psi/int.mak
> psi/zdfilter.c
> psi/ztrans.c
> windows/ghostscript.vcproj
> windows/ghostscript_rt.vcxproj

2018-02-02 11:55:05 +0000
Ken Sharp <ken.sharp@artifex.com>
154f27478bdf5b27858a9f446433d5b62febb89d

> remove some unused code - scanbuild warnings....
> base/gsdevice.c

2018-02-02 11:17:19 +0000
Ken Sharp <ken.sharp@artifex.com>
84370aa9d391c37eccd467760c471e99e355a8ec

> Fix some debug prints - scanbuild warning fix
> The number of parameters and number of format specifiers didn't match,
> this would only be apparent when built with DISPLAY_DEBUG defined.
> psi/dpmain.c
> psi/dwmainc.c

2018-02-02 11:16:11 +0000
Ken Sharp <ken.sharp@artifex.com>
1552615d4ae39a50a5f7bb40e5f481919ef0cb58

> Fix memory leak - scanbuild warning
> Not really a leak as such, but it prevents the warning.
> psi/apitest.c

2018-02-02 11:15:13 +0000
Ken Sharp <ken.sharp@artifex.com>
ab8d4f968c01900e94438575ce33ae7a4fd63167

> LCMS2art - fix some warnings from scanbuild
> Make three functions static, to avoid 'no prototype' warnings.
> lcms2art/src/cmsalpha.c
> lcms2art/src/cmssamp.c

2018-02-02 09:45:39 +0000
Ken Sharp <ken.sharp@artifex.com>
0c9d19b947f9ca5bfe6ed1ba221e303d60bfc0cb

> Remove the Mitsubishi CP50 colour dot matrix printer device
> Recent changes caused this device to enter clist mode more frequently
> and our automated testing revealed that in clist mode this device
> does not work. It calls a device method which should never be called.
> Its possible to remove the call, but we have no way to determine whether
> the resulting output actually works.
> Given the age of this device (and Mitsubishi have reused the model
> number for a different device, so it must be old) we are removing
> support for this device and deleting it fro the build.
> If someone is still using this device, we'll reinstate support if they
> are prepared to test the outptu for us.
> base/unix-gcc.mak
> configure.ac
> devices/contrib.mak
> devices/gdevcp50.c
> doc/Develop.htm
> psi/msvc.mak
> windows/ghostscript.vcproj
> windows/ghostscript_rt.vcxproj

2018-02-02 08:54:35 +0000
Chris Liddell <chris.liddell@artifex.com>
252527b4257133a722f4f03dce1e8abcbcc3f3c8

> Fix jmp_buf related compiler warning (setjmp_.h)
> The compiler (gcc/clang) considers the alignment of entries in a structure to
> be a run-time "variable", thus gives a warning when that value is used to
> size an array used in a globally available data type.
> The solution (suggested by Robin) is to use a buffer twice the size of a jmpbuf,
> thus guaranteeing we have enough space to offset into the buffer, and get the
> required alignment.
> base/setjmp_.h

2018-02-01 14:56:31 +0000
Chris Liddell <chris.liddell@artifex.com>
f52a7ccf96f1b9bb90194ba1dd6a50040dd63896

> Fix debug flag for TTF loading
> Two places were erroneously using PDFDEBUG instead of TTFDEBUG
> Resource/Init/gs_ttf.ps

2018-02-01 09:46:21 +0000
Chris Liddell <chris.liddell@artifex.com>
5b546c80e79e6d1f1c6c3a9a71bfb58ee23a328c

> Address the popen prototype warning
> Only include the hacky popen() prototype if it doesn't already exist in the
> standard header files.
> Makefile.in
> base/pipe_.h
> configure.ac

2018-02-01 11:40:20 +0000
Ken Sharp <ken.sharp@artifex.com>
88aea05567f36d4d37c00a51b818c80f88291f6b

> Remove another unused procedure from the OpenJPEG interface
> base/sjpx_openjpeg.c

2018-01-31 09:56:46 +0000
Chris Liddell <chris.liddell@artifex.com>
63f0fcc87e7c6a0ca38e92b7b3d72f1e936f2d0e

> Fix discarded qualifier warnings in pcl/pl/pjparse.c
> Create separate structure definitions for the normal and default PJL
> environment and PJL font sources data.
> The only difference between the two is the default one qualifies string
> values as const.
> pcl/pl/pjparse.c

2018-01-31 11:59:02 +0000
Chris Liddell <chris.liddell@artifex.com>
4d2f9f48fc272b7bb396f36704de03a7c15d2b3f

> Fix _MSC_VER undefined warnings on non-MSC compilers
> lcms2art/src/lcms2_internal.h

2018-01-31 10:22:34 +0000
Chris Liddell <chris.liddell@artifex.com>
b272292d9294e88e32d177d8b5e916f8bfaeb78b

> Add a zlib specific CFLAGS and avoid discarded const warning
> zlib has a table initialization with string literals that gcc
> automatically makes const, but the structure definition for the table does not
> qualify those entries as const. Hence we get warnings.
> This adds ZLIB_CFLAGS and, with a gcc compatible compiler, sets it to:
> -Wno-write-strings
> which kills that warning.
> Done this way because we want to retain that warning in the Ghostscript code.
> Makefile.in
> base/zlib.mak
> configure.ac

2018-01-31 09:34:39 +0000
Chris Liddell <chris.liddell@artifex.com>
aea7d587749819b7e59d24720efe86b1f8555186

> Add a TIFF specific CFLAGS and avoid discarded const warning
> libtiff has a large table initialization with string literals that gcc
> automatically makes const, but the structure definition for the table does not
> qualify those entries as const. Hence we get warnings.
> This adds TIFF_CFLAGS and, with a gcc compatible compiler, sets it to:
> -Wno-write-strings
> which kills that warning.
> Done this way because we want to retain that warning in the Ghostscript code.
> Makefile.in
> base/tiff.mak
> configure.ac

2018-01-27 23:11:13 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
865c3a83a449dc2c28f58095183b7493ccd970c4

> Update error code checking to use hpgl_call within pgdraw.c file. Also
> revert error code check in hpgl_draw_current_path to prevent failures
> during cluster run.
> pcl/pcl/pgdraw.c

2018-01-27 17:50:41 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
4ae64a398e6d5693c1dd4dd9348054cd21ef2443

> Check all return code from param_write_float_array.
> pcl/pcl/pcommand.c
> pcl/pxl/pxsessio.c

2018-01-27 16:50:23 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
d372efa33d9e2550b887154e2d6a3b9d03bc6438

> Check all return codes from pxPassthrough_init.
> pcl/pxl/pxpthr.c

2018-01-27 16:27:08 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
cc620400517cd76a5276602aea59f1231f934c46

> Check all return codes from pcl_enter_graphics_mode.
> pcl/pcl/rtgmode.c

2018-01-27 15:18:02 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
db10b7b56e5de12f92c1df83237ec4ff4b0dcf2a

> Check all return codes from pcl_end_graphics_mode.
> pcl/pcl/pctop.c
> pcl/pcl/rtgmode.c

2018-01-26 22:45:54 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
1df8810b79c5ef5979b1cad5ffe22a1fed824871

> Update propagation of error codes from pcl_end_page.
> pcl/pcl/pcjob.c
> pcl/pcl/pcpage.c

2018-01-26 22:17:36 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
e63064cfa3142e7a893a1666570f390d83662360

> Update pcl_mark_page_for_character to propagate error codes.
> pcl/pcl/pcpage.c
> pcl/pcl/pcpage.h
> pcl/pcl/pctext.c

2018-01-26 21:57:56 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
6f514a99fdb079d76df981a39dcb45f090766849

> Update functionality to propagate error codes.
> pcl/pcl/pcpage.c
> pcl/pcl/pcpage.h
> pcl/pcl/pgdraw.c
> pcl/pcl/pglabel.c

2018-01-26 21:20:02 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
193d143d1843edb2515138e6b4b9e7c4f5c06aa5

> Update functionality to propagate error codes returned from new_page_size.
> pcl/pcl/pcpage.c
> pcl/pcl/pcpage.h

2018-01-26 17:59:15 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
0d3c2753172bb9e22aa879d7503ec44f4b33e8f4

> Update pcl_transform_rect to remove unused memory variable.
> pcl/pcl/pcpage.c
> pcl/pcl/pcpatxfm.c
> pcl/pcl/pcpatxfm.h
> pcl/pcl/rtgmode.c

2018-01-31 15:37:17 +0000
Ken Sharp <ken.sharp@artifex.com>
961b01a6e50e640afac0e696f9ce74a677e648ec

> Squash more scan build warnings
> Remove initialisations which aren't required (sometimes due to multiple
> initialisations.
> In interp.c, store the error value in the actual return code.
> Action error return codes.
> Fix a few white space oddities.
> psi/dscparse.c
> psi/gs.c
> psi/imain.c
> psi/interp.c
> psi/zcie.c
> psi/zcolor.c

2018-01-31 14:47:41 +0000
Ken Sharp <ken.sharp@artifex.com>
7220e8e037ccee1c234872d143ec0ca14682604b

> Squash some more warnings
> scan build this time, none of them serious.
> Check some return codes and remove some unused variables.
> devices/gdevpdfimg.c
> devices/vector/gdevpdf.c
> devices/vector/gdevpdfc.c
> devices/vector/gdevpdfg.c
> devices/vector/gdevpdft.c
> devices/vector/gdevpdfu.c
> devices/vector/gdevpsdp.c

2018-01-31 09:59:01 +0000
Ken Sharp <ken.sharp@artifex.com>
68fcaea85611267eec9f4bac3443977fe15627dc

> squash GCC warnings
> remove an unused variable from a (large) macro in gxfilltr.h
> remove some unused variables, and an entire unused function in
> sjpx_openjpeg.c
> remove an unused variable in gdevbit.c
> remove an unused variable in gdevjpeg.c
> bracket a variable declaration and usage with #ifdef DEBUG to prevent
> the compiler warning that the variable is set but not read on non-debug
> builds. gdevxps.c
> preserve 'const' when passing a memory pointer to a procedure to
> avoid a warning about discarding const. zcie.c
> base/gxfilltr.h
> base/sjpx_openjpeg.c
> devices/gdevbit.c
> devices/gdevjpeg.c
> devices/vector/gdevxps.c
> psi/zcie.c

2018-01-31 09:55:34 +0000
Ken Sharp <ken.sharp@artifex.com>
07f9da3cb5647b18458cd52d1be35ab5365790eb

> Device subclassing - fix potential problems
> Flagged by scan build, the code to work a chain of devices had a
> potential problem in walking up and down the chain.
> Also flagged by scan build, the create_compositor method checked the
> target child device before trying to use it to set the saved target
> color info, but didn't check it before trying to set the procs.
> base/gdevdflt.c
> base/gdevkrnlsclass.c

2018-01-30 11:49:19 -0800
Ray Johnston <ray.johnston@artifex.com>
67daf3d995d83da98988085e68548a4920fe1747

> Get rid of some gcc warnings.
> Add initializers for variables that confuse gcc. Also get rid of the
> clist_reinit_output_file which was only needed for the RETRYING code
> and the partial page rendering (this function had unused variable
> warnings). THis should have been part of commit 7eda41b.
> base/gxclist.c
> base/gxclpath.c
> base/gxclrast.c

2018-01-30 16:37:58 +0000
Ken Sharp <ken.sharp@artifex.com>
22cf826fe4d0c0206be582d35c99954199dee999

> Update copyright notice with new head office address.
> Also update copyright dates.
> Remove gs_cmdl.ps as we no longer use it, and remove its entry from
> psfiles.htm.
> Remove xfonts.htm as this feature (xfont support) is long, long gone.
> Makefile.in
> Resource/CIDFont/ArtifexBullet
> Resource/CMap/Identity-UTF16-H
> Resource/ColorSpace/DefaultCMYK
> Resource/ColorSpace/DefaultGray
> Resource/ColorSpace/DefaultRGB
> Resource/ColorSpace/TrivialCMYK
> Resource/ColorSpace/sGray
> Resource/ColorSpace/sRGB
> Resource/Decoding/FCO_Dingbats
> Resource/Decoding/FCO_Symbol
> Resource/Decoding/FCO_Unicode
> Resource/Decoding/FCO_Wingdings
> Resource/Decoding/Latin1
> Resource/Decoding/StandardEncoding
> Resource/Decoding/Unicode
> Resource/Encoding/CEEncoding
> Resource/Encoding/ExpertEncoding
> Resource/Encoding/ExpertSubsetEncoding
> Resource/Encoding/NotDefEncoding
> Resource/Encoding/Wingdings
> Resource/Init/FCOfontmap-PCLPS2
> Resource/Init/Fontmap.GS
> Resource/Init/gs_agl.ps
> Resource/Init/gs_btokn.ps
> Resource/Init/gs_cff.ps
> Resource/Init/gs_cidcm.ps
> Resource/Init/gs_ciddc.ps
> Resource/Init/gs_cidfm.ps
> Resource/Init/gs_cidfn.ps
> Resource/Init/gs_cidtt.ps
> Resource/Init/gs_cmap.ps
> Resource/Init/gs_cspace.ps
> Resource/Init/gs_dbt_e.ps
> Resource/Init/gs_diskn.ps
> Resource/Init/gs_dpnxt.ps
> Resource/Init/gs_dps.ps
> Resource/Init/gs_dps1.ps
> Resource/Init/gs_dps2.ps
> Resource/Init/gs_dscp.ps
> Resource/Init/gs_epsf.ps
> Resource/Init/gs_fapi.ps
> Resource/Init/gs_fntem.ps
> Resource/Init/gs_fonts.ps
> Resource/Init/gs_frsd.ps
> Resource/Init/gs_icc.ps
> Resource/Init/gs_il1_e.ps
> Resource/Init/gs_img.ps
> Resource/Init/gs_init.ps
> Resource/Init/gs_l2img.ps
> Resource/Init/gs_lev2.ps
> Resource/Init/gs_ll3.ps
> Resource/Init/gs_mex_e.ps
> Resource/Init/gs_mgl_e.ps
> Resource/Init/gs_mro_e.ps
> Resource/Init/gs_pdf_e.ps
> Resource/Init/gs_pdfwr.ps
> Resource/Init/gs_res.ps
> Resource/Init/gs_resmp.ps
> Resource/Init/gs_setpd.ps
> Resource/Init/gs_statd.ps
> Resource/Init/gs_std_e.ps
> Resource/Init/gs_sym_e.ps
> Resource/Init/gs_trap.ps
> Resource/Init/gs_ttf.ps
> Resource/Init/gs_typ32.ps
> Resource/Init/gs_typ42.ps
> Resource/Init/gs_type1.ps
> Resource/Init/gs_wan_e.ps
> Resource/Init/pdf_base.ps
> Resource/Init/pdf_draw.ps
> Resource/Init/pdf_font.ps
> Resource/Init/pdf_main.ps
> Resource/Init/pdf_ops.ps
> Resource/Init/pdf_rbld.ps
> Resource/Init/pdf_sec.ps
> Resource/SubstCID/CNS1-WMode
> Resource/SubstCID/GB1-WMode
> Resource/SubstCID/Japan1-WMode
> Resource/SubstCID/Korea1-WMode
> arch/arch_autoconf.h.in
> arch/windows-arm-msvc.h
> arch/windows-x64-msvc.h
> arch/windows-x86-msvc.h
> base/all-arch.mak
> base/assert_.h
> base/bench.c
> base/bobbin.c
> base/bobbin.h
> base/claptrap-init.c
> base/claptrap-planar.c
> base/claptrap.c
> base/claptrap.h
> base/ctype_.h
> base/dirent_.h
> base/dos_.h
> base/echogs.c
> base/errno_.h
> base/expat.mak
> base/fapi_bs.mak
> base/fapi_ft.c
> base/fapibstm.c
> base/fapiufst.c
> base/fcntl_.h
> base/freetype.mak
> base/gconf.c
> base/gconf.h
> base/gdbflags.h
> base/gdebug.h
> base/gdevabuf.c
> base/gdevbbox.c
> base/gdevbbox.h
> base/gdevdbit.c
> base/gdevdcrd.c
> base/gdevdcrd.h
> base/gdevddrw.c
> base/gdevddrw.h
> base/gdevdevn.c
> base/gdevdevn.h
> base/gdevdevnprn.h
> base/gdevdflt.c
> base/gdevdgbr.c
> base/gdevdrop.c
> base/gdevdsha.c
> base/gdevemap.c
> base/gdevflp.c
> base/gdevflp.h
> base/gdevhit.c
> base/gdevkrnlsclass.c
> base/gdevkrnlsclass.h
> base/gdevm1.c
> base/gdevm16.c
> base/gdevm2.c
> base/gdevm24.c
> base/gdevm32.c
> base/gdevm4.c
> base/gdevm40.c
> base/gdevm48.c
> base/gdevm56.c
> base/gdevm64.c
> base/gdevm8.c
> base/gdevmem.c
> base/gdevmem.h
> base/gdevmpla.c
> base/gdevmpla.h
> base/gdevmplt.c
> base/gdevmplt.h
> base/gdevmr1.c
> base/gdevmr2n.c
> base/gdevmr8n.c
> base/gdevmrop.h
> base/gdevmrun.c
> base/gdevmrun.h
> base/gdevmx.c
> base/gdevnfwd.c
> base/gdevoflt.c
> base/gdevoflt.h
> base/gdevp14.c
> base/gdevp14.h
> base/gdevpccm.c
> base/gdevpccm.h
> base/gdevpipe.c
> base/gdevplnx.c
> base/gdevplnx.h
> base/gdevppla.c
> base/gdevppla.h
> base/gdevprn.c
> base/gdevprn.h
> base/gdevpxat.h
> base/gdevpxen.h
> base/gdevpxop.h
> base/gdevrops.c
> base/gdevsclass.c
> base/gdevsclass.h
> base/gdevvec.c
> base/gdevvec.h
> base/gen_ordered.c
> base/gen_ordered.h
> base/genarch.c
> base/genconf.c
> base/gendev.c
> base/genht.c
> base/gp.h
> base/gp_dosfe.c
> base/gp_dosfs.c
> base/gp_dvx.c
> base/gp_getnv.c
> base/gp_mktmp.c
> base/gp_msdll.c
> base/gp_msdos.c
> base/gp_mshdl.c
> base/gp_mslib.c
> base/gp_mspol.c
> base/gp_msprn.c
> base/gp_mswin.c
> base/gp_mswin.h
> base/gp_nsync.c
> base/gp_ntfs.c
> base/gp_nxpsprn.c
> base/gp_os2.c
> base/gp_os2.h
> base/gp_os2fs.c
> base/gp_os2pr.c
> base/gp_os9.c
> base/gp_paper.c
> base/gp_psync.c
> base/gp_stdia.c
> base/gp_stdin.c
> base/gp_strdl.c
> base/gp_sysv.c
> base/gp_unifn.c
> base/gp_unifs.c
> base/gp_unix.c
> base/gp_upapr.c
> base/gp_vms.c
> base/gp_wgetv.c
> base/gp_win32.c
> base/gp_wpapr.c
> base/gp_wsync.c
> base/gp_wutf8.c
> base/gp_wxpsprn.cpp
> base/gpcheck.h
> base/gpgetenv.h
> base/gpmisc.c
> base/gpmisc.h
> base/gpsync.h
> base/gs.mak
> base/gs_dll_call.h
> base/gs_mgl_e.h
> base/gs_mro_e.h
> base/gsalloc.c
> base/gsalloc.h
> base/gsalpha.c
> base/gsalpha.h
> base/gsalphac.c
> base/gsalphac.h
> base/gsargs.c
> base/gsargs.h
> base/gsbitcom.c
> base/gsbitmap.h
> base/gsbitops.c
> base/gsbitops.h
> base/gsbittab.c
> base/gsbittab.h
> base/gsccode.h
> base/gsccolor.h
> base/gscdef.c
> base/gscdefs.h
> base/gscdevn.c
> base/gscdevn.h
> base/gscedata.c
> base/gscedata.h
> base/gscencs.c
> base/gscencs.h
> base/gschar.c
> base/gschar.h
> base/gschar0.c
> base/gscicach.c
> base/gscicach.h
> base/gscie.c
> base/gscie.h
> base/gsciemap.c
> base/gscindex.h
> base/gsclipsr.c
> base/gsclipsr.h
> base/gscms.h
> base/gscolor.c
> base/gscolor.h
> base/gscolor1.c
> base/gscolor1.h
> base/gscolor2.c
> base/gscolor2.h
> base/gscolor3.c
> base/gscolor3.h
> base/gscompt.h
> base/gscoord.c
> base/gscoord.h
> base/gscparam.c
> base/gscpixel.c
> base/gscpixel.h
> base/gscpm.h
> base/gscrd.c
> base/gscrd.h
> base/gscrdp.c
> base/gscrdp.h
> base/gscrypt1.c
> base/gscrypt1.h
> base/gscscie.c
> base/gscsel.h
> base/gscsepr.c
> base/gscsepr.h
> base/gscspace.c
> base/gscspace.h
> base/gscssub.c
> base/gscssub.h
> base/gsdcolor.h
> base/gsdevice.c
> base/gsdevice.h
> base/gsdevmem.c
> base/gsdfilt.c
> base/gsdfilt.h
> base/gsdll.h
> base/gsdllwin.h
> base/gsdparam.c
> base/gsdpnext.h
> base/gsdps.c
> base/gsdps.h
> base/gsdps1.c
> base/gsdsrc.c
> base/gsdsrc.h
> base/gsequivc.c
> base/gsequivc.h
> base/gserrors.h
> base/gsexit.h
> base/gsfcid.c
> base/gsfcid2.c
> base/gsfcmap.c
> base/gsfcmap.h
> base/gsfcmap1.c
> base/gsflip.c
> base/gsflip.h
> base/gsfname.c
> base/gsfname.h
> base/gsfont.c
> base/gsfont.h
> base/gsfont0.c
> base/gsfont0c.c
> base/gsform1.h
> base/gsfunc.c
> base/gsfunc.h
> base/gsfunc0.c
> base/gsfunc0.h
> base/gsfunc3.c
> base/gsfunc3.h
> base/gsfunc4.c
> base/gsfunc4.h
> base/gsgc.h
> base/gsgcache.c
> base/gsgcache.h
> base/gsgdata.c
> base/gsgdata.h
> base/gsgstate.c
> base/gshsb.c
> base/gshsb.h
> base/gsht.c
> base/gsht.h
> base/gsht1.c
> base/gsht1.h
> base/gshtscr.c
> base/gshtx.c
> base/gshtx.h
> base/gsicc.c
> base/gsicc.h
> base/gsicc_cache.c
> base/gsicc_cache.h
> base/gsicc_cms.h
> base/gsicc_create.c
> base/gsicc_create.h
> base/gsicc_lcms2.c
> base/gsicc_lcms2art.c
> base/gsicc_manage.c
> base/gsicc_manage.h
> base/gsicc_monitorcm.c
> base/gsicc_nocm.c
> base/gsicc_profilecache.c
> base/gsicc_profilecache.h
> base/gsicc_replacecm.c
> base/gsimage.c
> base/gsimage.h
> base/gsimpath.c
> base/gsinit.c
> base/gsio.h
> base/gsiodev.c
> base/gsiodevs.c
> base/gsiodisk.c
> base/gsioram.c
> base/gsiorom.c
> base/gsiorom.h
> base/gsipar3x.h
> base/gsiparam.h
> base/gsiparm2.h
> base/gsiparm3.h
> base/gsiparm4.h
> base/gsjconf.h
> base/gsjmorec.h
> base/gslib.c
> base/gslib.h
> base/gslibctx.c
> base/gslibctx.h
> base/gsline.c
> base/gsline.h
> base/gslparam.h
> base/gsmalloc.c
> base/gsmalloc.h
> base/gsmatrix.c
> base/gsmatrix.h
> base/gsmchunk.c
> base/gsmchunk.h
> base/gsmd5.c
> base/gsmd5.h
> base/gsmdebug.h
> base/gsmemory.c
> base/gsmemory.h
> base/gsmemraw.h
> base/gsmemret.c
> base/gsmemret.h
> base/gsmisc.c
> base/gsnamecl.c
> base/gsnamecl.h
> base/gsncdummy.c
> base/gsncdummy.h
> base/gsnogc.c
> base/gsnogc.h
> base/gsnotify.c
> base/gsnotify.h
> base/gsovrc.c
> base/gsovrc.h
> base/gspaint.c
> base/gspaint.h
> base/gsparam.c
> base/gsparam.h
> base/gsparam2.c
> base/gsparams.c
> base/gsparams.h
> base/gsparamx.c
> base/gsparamx.h
> base/gspath.c
> base/gspath.h
> base/gspath1.c
> base/gspath2.h
> base/gspcolor.c
> base/gspcolor.h
> base/gspenum.h
> base/gspmdrv.c
> base/gspmdrv.h
> base/gspmdrv.rc
> base/gsptype1.c
> base/gsptype1.h
> base/gsptype2.c
> base/gsptype2.h
> base/gsrect.h
> base/gsrefct.h
> base/gsromfs0.c
> base/gsrop.c
> base/gsrop.h
> base/gsroprun.c
> base/gsroprun1.h
> base/gsroprun24.h
> base/gsroprun8.h
> base/gsropt.h
> base/gsroptab.c
> base/gsserial.c
> base/gsserial.h
> base/gsshade.c
> base/gsshade.h
> base/gssprintf.h
> base/gsstate.c
> base/gsstate.h
> base/gsstrl.h
> base/gsstrtok.h
> base/gsstruct.h
> base/gsstype.h
> base/gstext.c
> base/gstext.h
> base/gstiffio.c
> base/gstiffio.h
> base/gstparam.h
> base/gstrans.c
> base/gstrans.h
> base/gstrap.c
> base/gstrap.h
> base/gstype1.c
> base/gstype1.h
> base/gstype2.c
> base/gstype42.c
> base/gstypes.h
> base/gsuid.h
> base/gsutil.c
> base/gsutil.h
> base/gswin.rc
> base/gsxfont.h
> base/gx.h
> base/gxacpath.c
> base/gxalloc.h
> base/gxalpha.h
> base/gxarith.h
> base/gxband.h
> base/gxbcache.c
> base/gxbcache.h
> base/gxbitfmt.h
> base/gxbitmap.h
> base/gxbitops.h
> base/gxblend.c
> base/gxblend.h
> base/gxblend1.c
> base/gxccache.c
> base/gxccman.c
> base/gxcdevn.h
> base/gxchar.c
> base/gxchar.h
> base/gxchrout.c
> base/gxchrout.h
> base/gxcht.c
> base/gxcid.h
> base/gxcie.h
> base/gxcindex.h
> base/gxclbits.c
> base/gxcldev.h
> base/gxclfile.c
> base/gxclimag.c
> base/gxclio.h
> base/gxclip.c
> base/gxclip.h
> base/gxclip2.c
> base/gxclip2.h
> base/gxclipm.c
> base/gxclipm.h
> base/gxclipsr.h
> base/gxclist.c
> base/gxclist.h
> base/gxcllzw.c
> base/gxclmem.c
> base/gxclmem.h
> base/gxclpage.c
> base/gxclpage.h
> base/gxclpath.c
> base/gxclpath.h
> base/gxclrast.c
> base/gxclread.c
> base/gxclrect.c
> base/gxclthrd.c
> base/gxclthrd.h
> base/gxclutil.c
> base/gxclzlib.c
> base/gxcmap.c
> base/gxcmap.h
> base/gxcolor2.h
> base/gxcomp.h
> base/gxcoord.h
> base/gxcpath.c
> base/gxcpath.h
> base/gxcspace.h
> base/gxctable.c
> base/gxctable.h
> base/gxcvalue.h
> base/gxdcconv.c
> base/gxdcconv.h
> base/gxdcolor.c
> base/gxdcolor.h
> base/gxdda.h
> base/gxdevbuf.h
> base/gxdevcli.h
> base/gxdevice.h
> base/gxdevmem.h
> base/gxdevndi.c
> base/gxdevndi.h
> base/gxdevrop.h
> base/gxdevsop.h
> base/gxdht.h
> base/gxdhtres.h
> base/gxdhtserial.c
> base/gxdhtserial.h
> base/gxdither.h
> base/gxdownscale.c
> base/gxdownscale.h
> base/gxdtfill.h
> base/gxfapi.c
> base/gxfapi.h
> base/gxfapiu.c
> base/gxfapiu.h
> base/gxfarith.h
> base/gxfcache.h
> base/gxfcid.h
> base/gxfcmap.h
> base/gxfcmap1.h
> base/gxfill.c
> base/gxfill.h
> base/gxfillsl.h
> base/gxfilltr.h
> base/gxfillts.h
> base/gxfixed.h
> base/gxfmap.h
> base/gxfont.h
> base/gxfont0.h
> base/gxfont0c.h
> base/gxfont1.h
> base/gxfont42.h
> base/gxfrac.h
> base/gxftype.h
> base/gxfunc.h
> base/gxgetbit.h
> base/gxgstate.h
> base/gxhintn.c
> base/gxhintn.h
> base/gxhintn1.c
> base/gxhldevc.c
> base/gxhldevc.h
> base/gxht.c
> base/gxht.h
> base/gxht_thresh.c
> base/gxht_thresh.h
> base/gxhtbit.c
> base/gxhttile.h
> base/gxhttype.h
> base/gxi12bit.c
> base/gxi16bit.c
> base/gxiclass.h
> base/gxicolor.c
> base/gxidata.c
> base/gxifast.c
> base/gximag3x.c
> base/gximag3x.h
> base/gximage.c
> base/gximage.h
> base/gximage1.c
> base/gximage2.c
> base/gximage3.c
> base/gximage3.h
> base/gximage4.c
> base/gximask.c
> base/gximask.h
> base/gximdecode.c
> base/gximdecode.h
> base/gximono.c
> base/gxiodev.h
> base/gxiparam.h
> base/gxipixel.c
> base/gxiscale.c
> base/gxline.h
> base/gxlum.h
> base/gxmatrix.h
> base/gxmclip.c
> base/gxmclip.h
> base/gxobj.h
> base/gxoprect.c
> base/gxoprect.h
> base/gxp1fill.c
> base/gxp1impl.h
> base/gxpaint.c
> base/gxpaint.h
> base/gxpath.c
> base/gxpath.h
> base/gxpath2.c
> base/gxpcache.h
> base/gxpcmap.c
> base/gxpcolor.h
> base/gxpcopy.c
> base/gxpdash.c
> base/gxpflat.c
> base/gxrplane.h
> base/gxsample.c
> base/gxsample.h
> base/gxsamplp.h
> base/gxscanc.c
> base/gxscanc.h
> base/gxshade.c
> base/gxshade.h
> base/gxshade1.c
> base/gxshade4.c
> base/gxshade4.h
> base/gxshade6.c
> base/gxstate.h
> base/gxstdio.h
> base/gxstroke.c
> base/gxsync.c
> base/gxsync.h
> base/gxtext.h
> base/gxtmap.h
> base/gxttf.h
> base/gxttfb.c
> base/gxttfb.h
> base/gxtype1.c
> base/gxtype1.h
> base/gxxfont.h
> base/gzacpath.h
> base/gzcpath.h
> base/gzht.h
> base/gzline.h
> base/gzpath.h
> base/gzspotan.c
> base/gzspotan.h
> base/gzstate.h
> base/ijs.mak
> base/instcopy
> base/jbig2.mak
> base/jerror_.h
> base/jmemcust.c
> base/jmemcust.h
> base/jpeg.mak
> base/jpegxr.mak
> base/lcms2.mak
> base/lcms2art.mak
> base/lcups.mak
> base/lcupsi.mak
> base/ldf_jb2.mak
> base/lib.mak
> base/locale_.h
> base/lwf_jp2.mak
> base/malloc_.h
> base/math_.h
> base/md5main.c
> base/memento.c
> base/memento.h
> base/memory_.h
> base/mkromfs.c
> base/msvccmd.mak
> base/msvclib.mak
> base/msvctail.mak
> base/openjpeg.mak
> base/openvms.mak
> base/openvms.mmk
> base/pack_ps.c
> base/pcwin.mak
> base/pipe_.h
> base/png.mak
> base/png_.h
> base/ramfs.c
> base/ramfs.h
> base/sa85d.c
> base/sa85d.h
> base/sa85x.h
> base/saes.c
> base/saes.h
> base/sarc4.c
> base/sarc4.h
> base/sbcp.c
> base/sbcp.h
> base/sbtx.h
> base/scanchar.h
> base/scantab.c
> base/scf.h
> base/scfd.c
> base/scfdgen.c
> base/scfdtab.c
> base/scfe.c
> base/scfetab.c
> base/scfparam.c
> base/scfx.h
> base/scommon.h
> base/sdcparam.c
> base/sdcparam.h
> base/sdct.h
> base/sdctc.c
> base/sdctd.c
> base/sdcte.c
> base/sddparam.c
> base/sdeparam.c
> base/seexec.c
> base/setjmp_.h
> base/sfilter.h
> base/sfilter2.c
> base/sfxboth.c
> base/sfxcommon.c
> base/sfxfd.c
> base/sfxstdio.c
> base/shc.c
> base/shc.h
> base/sidscale.c
> base/sidscale.h
> base/siinterp.c
> base/siinterp.h
> base/simscale.c
> base/simscale.h
> base/siscale.c
> base/siscale.h
> base/sisparam.h
> base/sjbig2.c
> base/sjbig2.h
> base/sjbig2_luratech.c
> base/sjbig2_luratech.h
> base/sjpeg.h
> base/sjpegc.c
> base/sjpegd.c
> base/sjpege.c
> base/sjpx_luratech.c
> base/sjpx_luratech.h
> base/sjpx_none.c
> base/sjpx_openjpeg.c
> base/sjpx_openjpeg.h
> base/slzwc.c
> base/slzwd.c
> base/slzwe.c
> base/slzwx.h
> base/smd5.c
> base/smd5.h
> base/smtf.h
> base/spdiff.c
> base/spdiffx.h
> base/spngp.c
> base/spngpx.h
> base/spprint.c
> base/spprint.h
> base/spsdf.c
> base/spsdf.h
> base/spwgd.c
> base/spwgx.h
> base/srdline.h
> base/srld.c
> base/srle.c
> base/srlx.h
> base/ssha2.c
> base/ssha2.h
> base/sstring.c
> base/sstring.h
> base/stat_.h
> base/std.h
> base/stdint_.h
> base/stdio_.h
> base/stdpre.h
> base/stream.c
> base/stream.h
> base/strimpl.h
> base/string_.h
> base/strmio.c
> base/strmio.h
> base/stub.mak
> base/szlibc.c
> base/szlibd.c
> base/szlibe.c
> base/szlibx.h
> base/szlibxx.h
> base/tiff.mak
> base/time_.h
> base/ttcalc.c
> base/ttcalc.h
> base/ttcommon.h
> base/ttconf.h
> base/ttconfig.h
> base/ttfinp.c
> base/ttfinp.h
> base/ttfmain.c
> base/ttfmemd.c
> base/ttfmemd.h
> base/ttfoutl.h
> base/ttfsfnt.h
> base/ttinterp.c
> base/ttinterp.h
> base/ttload.c
> base/ttload.h
> base/ttmisc.h
> base/ttobjs.c
> base/ttobjs.h
> base/tttables.h
> base/tttype.h
> base/tttypes.h
> base/ugcclib.mak
> base/unistd_.h
> base/unix-aux.mak
> base/unix-dll.mak
> base/unix-end.mak
> base/unix-gcc.mak
> base/unixansi.mak
> base/unixhead.mak
> base/unixinst.mak
> base/unixlink.mak
> base/valgrind.h
> base/version.mak
> base/vms_x_fix.h
> base/vmsmath.h
> base/windows_.h
> base/winlib.mak
> base/winplat.mak
> base/winrtsup.cpp
> base/winrtsup.h
> base/wrfont.c
> base/wrfont.h
> base/write_t1.c
> base/write_t1.h
> base/write_t2.c
> base/write_t2.h
> base/x_.h
> base/zlib.mak
> configure.ac
> devices/contrib.mak
> devices/devs.mak
> devices/gdev3852.c
> devices/gdev4081.c
> devices/gdev8510.c
> devices/gdev8bcm.c
> devices/gdev8bcm.h
> devices/gdevatx.c
> devices/gdevbit.c
> devices/gdevbj10.c
> devices/gdevbjc.h
> devices/gdevbjcl.c
> devices/gdevbjcl.h
> devices/gdevbmp.c
> devices/gdevbmp.h
> devices/gdevbmpc.c
> devices/gdevccr.c
> devices/gdevcdj.c
> devices/gdevcfax.c
> devices/gdevcif.c
> devices/gdevclj.c
> devices/gdevcljc.c
> devices/gdevcmykog.c
> devices/gdevcp50.c
> devices/gdevcslw.c
> devices/gdevdfax.c
> devices/gdevdjet.c
> devices/gdevdjtc.c
> devices/gdevdljm.c
> devices/gdevdljm.h
> devices/gdevdm24.c
> devices/gdevdsp.c
> devices/gdevdsp.h
> devices/gdevdsp2.h
> devices/gdevepsc.c
> devices/gdevepsn.c
> devices/gdevescp.c
> devices/gdevfax.c
> devices/gdevfax.h
> devices/gdevfpng.c
> devices/gdevgprf.c
> devices/gdevhl7x.c
> devices/gdevicov.c
> devices/gdevijs.c
> devices/gdevimgn.c
> devices/gdevjbig2.c
> devices/gdevjpeg.c
> devices/gdevjpx.c
> devices/gdevl31s.c
> devices/gdevlbp8.c
> devices/gdevlj56.c
> devices/gdevlp8k.c
> devices/gdevlxm.c
> devices/gdevmeds.c
> devices/gdevmeds.h
> devices/gdevmgr.c
> devices/gdevmgr.h
> devices/gdevmiff.c
> devices/gdevn533.c
> devices/gdevo182.c
> devices/gdevokii.c
> devices/gdevpbm.c
> devices/gdevpcl.c
> devices/gdevpcl.h
> devices/gdevpcx.c
> devices/gdevpe.c
> devices/gdevperm.c
> devices/gdevphex.c
> devices/gdevpjet.c
> devices/gdevplan.c
> devices/gdevplib.c
> devices/gdevplib.h
> devices/gdevpm.h
> devices/gdevpng.c
> devices/gdevpsd.c
> devices/gdevpsd.h
> devices/gdevpsim.c
> devices/gdevpxut.c
> devices/gdevpxut.h
> devices/gdevrinkj.c
> devices/gdevsj48.c
> devices/gdevsnfb.c
> devices/gdevsppr.c
> devices/gdevstc.c
> devices/gdevstc.h
> devices/gdevstc1.c
> devices/gdevstc2.c
> devices/gdevstc3.c
> devices/gdevstc4.c
> devices/gdevtfax.c
> devices/gdevtfax.h
> devices/gdevtfnx.c
> devices/gdevtifs.c
> devices/gdevtifs.h
> devices/gdevtknk.c
> devices/gdevtrac.c
> devices/gdevtsep.c
> devices/gdevupd.c
> devices/gdevwpr2.c
> devices/gdevx.c
> devices/gdevx.h
> devices/gdevxalt.c
> devices/gdevxcf.c
> devices/gdevxcmp.c
> devices/gdevxcmp.h
> devices/gdevxini.c
> devices/gdevxres.c
> devices/gxfcopy.c
> devices/gxfcopy.h
> devices/minftrsz.c
> devices/minftrsz.h
> devices/rinkj/evenbetter-rll.c
> devices/rinkj/evenbetter-rll.h
> devices/rinkj/rinkj-byte-stream.c
> devices/rinkj/rinkj-byte-stream.h
> devices/rinkj/rinkj-config.c
> devices/rinkj/rinkj-config.h
> devices/rinkj/rinkj-device.c
> devices/rinkj/rinkj-device.h
> devices/rinkj/rinkj-dither.c
> devices/rinkj/rinkj-dither.h
> devices/rinkj/rinkj-epson870.c
> devices/rinkj/rinkj-epson870.h
> devices/rinkj/rinkj-screen-eb.c
> devices/rinkj/rinkj-screen-eb.h
> devices/vector/gdevagl.c
> devices/vector/gdevagl.h
> devices/vector/gdevpdf.c
> devices/vector/gdevpdfb.c
> devices/vector/gdevpdfb.h
> devices/vector/gdevpdfc.c
> devices/vector/gdevpdfc.h
> devices/vector/gdevpdfd.c
> devices/vector/gdevpdfe.c
> devices/vector/gdevpdfg.c
> devices/vector/gdevpdfg.h
> devices/vector/gdevpdfi.c
> devices/vector/gdevpdfj.c
> devices/vector/gdevpdfk.c
> devices/vector/gdevpdfm.c
> devices/vector/gdevpdfo.c
> devices/vector/gdevpdfo.h
> devices/vector/gdevpdfp.c
> devices/vector/gdevpdfr.c
> devices/vector/gdevpdft.c
> devices/vector/gdevpdfu.c
> devices/vector/gdevpdfv.c
> devices/vector/gdevpdfx.h
> devices/vector/gdevpdt.c
> devices/vector/gdevpdt.h
> devices/vector/gdevpdtb.c
> devices/vector/gdevpdtb.h
> devices/vector/gdevpdtc.c
> devices/vector/gdevpdtd.c
> devices/vector/gdevpdtd.h
> devices/vector/gdevpdte.c
> devices/vector/gdevpdtf.c
> devices/vector/gdevpdtf.h
> devices/vector/gdevpdti.c
> devices/vector/gdevpdti.h
> devices/vector/gdevpdts.c
> devices/vector/gdevpdts.h
> devices/vector/gdevpdtt.c
> devices/vector/gdevpdtt.h
> devices/vector/gdevpdtv.c
> devices/vector/gdevpdtv.h
> devices/vector/gdevpdtw.c
> devices/vector/gdevpdtw.h
> devices/vector/gdevpdtx.h
> devices/vector/gdevpsdf.h
> devices/vector/gdevpsdi.c
> devices/vector/gdevpsdp.c
> devices/vector/gdevpsds.c
> devices/vector/gdevpsds.h
> devices/vector/gdevpsdu.c
> devices/vector/gdevpsf.h
> devices/vector/gdevpsf1.c
> devices/vector/gdevpsf2.c
> devices/vector/gdevpsfm.c
> devices/vector/gdevpsft.c
> devices/vector/gdevpsfu.c
> devices/vector/gdevpsfx.c
> devices/vector/gdevpsu.c
> devices/vector/gdevpsu.h
> devices/vector/gdevpx.c
> devices/vector/gdevtxtw.c
> devices/vector/gdevxps.c
> devices/vector/opdfread.ps
> devices/vector/whitelst.c
> devices/vector/whitelst.h
> doc/API.htm
> doc/C-style.htm
> doc/Commprod.htm
> doc/DLL.htm
> doc/Deprecated.htm
> doc/Details8.htm
> doc/Details9.htm
> doc/Develop.htm
> doc/Devices.htm
> doc/Drivers.htm
> doc/Fonts.htm
> doc/GS9_Color_Management.tex
> doc/Helpers.htm
> doc/History1.htm
> doc/History2.htm
> doc/History3.htm
> doc/History4.htm
> doc/History5.htm
> doc/History6.htm
> doc/History7.htm
> doc/History8.htm
> doc/History9.htm
> doc/Install.htm
> doc/Issues.htm
> doc/Language.htm
> doc/Lib.htm
> doc/Make.htm
> doc/News.htm
> doc/Projects.htm
> doc/Ps-style.htm
> doc/Ps2epsi.htm
> doc/Psfiles.htm
> doc/Readme.htm
> doc/Release.htm
> doc/SavedPages.htm
> doc/Source.htm
> doc/Unix-lpr.htm
> doc/Use.htm
> doc/VectorDevices.htm
> doc/WhatIsGS.htm
> doc/Xfonts.htm
> doc/gdevds32.c
> doc/sample_downscale_device.htm
> doc/thirdparty.htm
> examples/waterfal.ps
> gpdl/gpdl.mak
> gpdl/psi/gpdlpsi.mak
> gpdl/psi/psitop.c
> gpdl/pspcl6_gcc.mak
> gpdl/pspcl6_msvc.mak
> ijs/Makefile.am
> ijs/configure.ac
> ijs/ijs.c
> ijs/ijs.h
> ijs/ijs_client.c
> ijs/ijs_client.h
> ijs/ijs_client_example.c
> ijs/ijs_exec_unix.c
> ijs/ijs_exec_win.c
> ijs/ijs_server.c
> ijs/ijs_server_example.c
> ijs/unistd_.h
> ios/ios_arch-arm.h
> ios/ios_arch-x86.h
> jbig2dec/config_win32.h
> jbig2dec/jbig2.c
> jbig2dec/jbig2.h
> jbig2dec/jbig2_arith.c
> jbig2dec/jbig2_arith.h
> jbig2dec/jbig2_arith_iaid.c
> jbig2dec/jbig2_arith_iaid.h
> jbig2dec/jbig2_arith_int.c
> jbig2dec/jbig2_arith_int.h
> jbig2dec/jbig2_generic.c
> jbig2dec/jbig2_generic.h
> jbig2dec/jbig2_halftone.c
> jbig2dec/jbig2_halftone.h
> jbig2dec/jbig2_huffman.c
> jbig2dec/jbig2_huffman.h
> jbig2dec/jbig2_hufftab.h
> jbig2dec/jbig2_image.c
> jbig2dec/jbig2_image.h
> jbig2dec/jbig2_image_pbm.c
> jbig2dec/jbig2_image_png.c
> jbig2dec/jbig2_metadata.c
> jbig2dec/jbig2_metadata.h
> jbig2dec/jbig2_mmr.c
> jbig2dec/jbig2_mmr.h
> jbig2dec/jbig2_page.c
> jbig2dec/jbig2_priv.h
> jbig2dec/jbig2_refinement.c
> jbig2dec/jbig2_segment.c
> jbig2dec/jbig2_symbol_dict.c
> jbig2dec/jbig2_symbol_dict.h
> jbig2dec/jbig2_text.c
> jbig2dec/jbig2_text.h
> jbig2dec/jbig2dec.c
> jbig2dec/memcmp.c
> jbig2dec/memento.c
> jbig2dec/memento.h
> jbig2dec/os_types.h
> jbig2dec/pbm2png.c
> lib/FCOfontmap-PCLPS3
> lib/FCOfontmap-PS3
> lib/Fontmap.ATB
> lib/Fontmap.ATM
> lib/Fontmap.OS2
> lib/Fontmap.SGI
> lib/Fontmap.Sol
> lib/Fontmap.URW-136.T1
> lib/Fontmap.URW-136.TT
> lib/Fontmap.Ult
> lib/Fontmap.VMS
> lib/align.ps
> lib/caption.ps
> lib/cat.ps
> lib/cid2code.ps
> lib/docie.ps
> lib/font2pcl.ps
> lib/gs_ce_e.ps
> lib/gs_cmdl.ps
> lib/gs_il2_e.ps
> lib/gs_kanji.ps
> lib/gs_ksb_e.ps
> lib/gs_lgo_e.ps
> lib/gs_lgx_e.ps
> lib/gs_wl1_e.ps
> lib/gs_wl2_e.ps
> lib/gs_wl5_e.ps
> lib/gslp.ps
> lib/gsnup.ps
> lib/image-qa.ps
> lib/jispaper.ps
> lib/lines.ps
> lib/mkcidfm.ps
> lib/pdf2dsc.ps
> lib/pfbtopfa.ps
> lib/ppath.ps
> lib/pphs.ps
> lib/prfont.ps
> lib/ps2ai.ps
> lib/ps2epsi.ps
> lib/rollconv.ps
> lib/stcinfo.ps
> lib/stcolor.ps
> lib/stocht.ps
> lib/traceimg.ps
> lib/traceop.ps
> lib/uninfo.ps
> lib/viewcmyk.ps
> lib/viewgif.ps
> lib/viewjpeg.ps
> lib/viewmiff.ps
> lib/viewpbm.ps
> lib/viewpcx.ps
> lib/viewps2a.ps
> lib/viewpwg.ps
> lib/viewraw.ps
> lib/viewrgb.ps
> lib/winmaps.ps
> lib/zeroline.ps
> pcl/LICENSE
> pcl/pcl/pcbiptrn.c
> pcl/pcl/pcbiptrn.h
> pcl/pcl/pccid.c
> pcl/pcl/pccid.h
> pcl/pcl/pccolor.c
> pcl/pcl/pccoord.h
> pcl/pcl/pccprint.c
> pcl/pcl/pccsbase.c
> pcl/pcl/pccsbase.h
> pcl/pcl/pcdict.h
> pcl/pcl/pcdither.c
> pcl/pcl/pcdither.h
> pcl/pcl/pcdraw.c
> pcl/pcl/pcdraw.h
> pcl/pcl/pcfont.c
> pcl/pcl/pcfont.h
> pcl/pcl/pcfontpg.c
> pcl/pcl/pcfontst.h
> pcl/pcl/pcfrgrnd.c
> pcl/pcl/pcfrgrnd.h
> pcl/pcl/pcfsel.c
> pcl/pcl/pcfsel.h
> pcl/pcl/pcht.c
> pcl/pcl/pcht.h
> pcl/pcl/pcident.c
> pcl/pcl/pcident.h
> pcl/pcl/pcimpl.c
> pcl/pcl/pcindxed.c
> pcl/pcl/pcindxed.h
> pcl/pcl/pcjob.c
> pcl/pcl/pcl.mak
> pcl/pcl/pcl_top.mak
> pcl/pcl/pclookup.c
> pcl/pcl/pclookup.h
> pcl/pcl/pcmacros.c
> pcl/pcl/pcmisc.c
> pcl/pcl/pcmtx3.c
> pcl/pcl/pcmtx3.h
> pcl/pcl/pcommand.c
> pcl/pcl/pcommand.h
> pcl/pcl/pcpage.c
> pcl/pcl/pcpage.h
> pcl/pcl/pcpalet.c
> pcl/pcl/pcpalet.h
> pcl/pcl/pcparam.h
> pcl/pcl/pcparse.c
> pcl/pcl/pcparse.h
> pcl/pcl/pcpatrn.c
> pcl/pcl/pcpatrn.h
> pcl/pcl/pcpattyp.h
> pcl/pcl/pcpatxfm.c
> pcl/pcl/pcpatxfm.h
> pcl/pcl/pcrect.c
> pcl/pcl/pcsfont.c
> pcl/pcl/pcstate.h
> pcl/pcl/pcstatus.c
> pcl/pcl/pcsymbol.c
> pcl/pcl/pcsymbol.h
> pcl/pcl/pctext.c
> pcl/pcl/pctop.c
> pcl/pcl/pctop.h
> pcl/pcl/pctpm.h
> pcl/pcl/pcuptrn.c
> pcl/pcl/pcuptrn.h
> pcl/pcl/pcursor.c
> pcl/pcl/pcursor.h
> pcl/pcl/pcwhtidx.c
> pcl/pcl/pcwhtidx.h
> pcl/pcl/pcxfmst.h
> pcl/pcl/pgchar.c
> pcl/pcl/pgcolor.c
> pcl/pcl/pgconfig.c
> pcl/pcl/pgdraw.c
> pcl/pcl/pgdraw.h
> pcl/pcl/pgfdata.c
> pcl/pcl/pgfdata.h
> pcl/pcl/pgfont.c
> pcl/pcl/pgfont.h
> pcl/pcl/pgframe.c
> pcl/pcl/pggeom.c
> pcl/pcl/pggeom.h
> pcl/pcl/pginit.c
> pcl/pcl/pginit.h
> pcl/pcl/pglabel.c
> pcl/pcl/pglfill.c
> pcl/pcl/pgmand.h
> pcl/pcl/pgmisc.c
> pcl/pcl/pgmisc.h
> pcl/pcl/pgparse.c
> pcl/pcl/pgpoly.c
> pcl/pcl/pgstate.h
> pcl/pcl/pgvector.c
> pcl/pcl/rtgmode.c
> pcl/pcl/rtgmode.h
> pcl/pcl/rtmisc.c
> pcl/pcl/rtmisc.h
> pcl/pcl/rtraster.c
> pcl/pcl/rtraster.h
> pcl/pcl/rtrstcmp.c
> pcl/pcl/rtrstcmp.h
> pcl/pcl/rtrstst.h
> pcl/pl/pjparse.c
> pcl/pl/pjparse.h
> pcl/pl/pjparsei.c
> pcl/pl/pjtop.c
> pcl/pl/pjtop.h
> pcl/pl/pl.mak
> pcl/pl/plalloc.c
> pcl/pl/plapi.c
> pcl/pl/plapi.h
> pcl/pl/plchar.c
> pcl/pl/plchar.h
> pcl/pl/plcursor.c
> pcl/pl/plcursor.h
> pcl/pl/pldebug.h
> pcl/pl/pldict.c
> pcl/pl/pldict.h
> pcl/pl/pldraw.c
> pcl/pl/pldraw.h
> pcl/pl/plfapi.c
> pcl/pl/plfapi.h
> pcl/pl/plfont.c
> pcl/pl/plfont.h
> pcl/pl/plftable.c
> pcl/pl/plftable.h
> pcl/pl/plht.c
> pcl/pl/plht.h
> pcl/pl/plimpl.c
> pcl/pl/pllfont.c
> pcl/pl/pllfont.h
> pcl/pl/plmain.c
> pcl/pl/plmain.h
> pcl/pl/plparams.c
> pcl/pl/plparams.h
> pcl/pl/plparse.h
> pcl/pl/plromfs.mak
> pcl/pl/plsymbol.c
> pcl/pl/plsymbol.h
> pcl/pl/pltop.c
> pcl/pl/pltop.h
> pcl/pl/pluchar.c
> pcl/pl/plufont.c
> pcl/pl/plufstlp.c
> pcl/pl/plufstlp.h
> pcl/pl/plufstlp1.c
> pcl/pl/plulfont.c
> pcl/pl/plvalue.c
> pcl/pl/plvalue.h
> pcl/pl/plvocab.c
> pcl/pl/plvocab.h
> pcl/pl/plwimg.c
> pcl/pl/plwimg.h
> pcl/pl/plwmainc.c
> pcl/pl/plwreg.c
> pcl/pl/plwreg.h
> pcl/pl/plwres.h
> pcl/pl/realmain.c
> pcl/pxl/pxasm.ps
> pcl/pxl/pxattr.h
> pcl/pxl/pxbfont.c
> pcl/pxl/pxbfont.h
> pcl/pxl/pxbfont.ps
> pcl/pxl/pxcet.txt
> pcl/pxl/pxdict.h
> pcl/pxl/pxdiff.txt
> pcl/pxl/pxenum.h
> pcl/pxl/pxerrors.c
> pcl/pxl/pxerrors.h
> pcl/pxl/pxffont.c
> pcl/pxl/pxfont.c
> pcl/pxl/pxfont.h
> pcl/pxl/pxfts.txt
> pcl/pxl/pxgstate.c
> pcl/pxl/pxgstate.h
> pcl/pxl/pximage.c
> pcl/pxl/pximpl.c
> pcl/pxl/pxink.c
> pcl/pxl/pxl.mak
> pcl/pxl/pxlib.txt
> pcl/pxl/pxoper.h
> pcl/pxl/pxpaint.c
> pcl/pxl/pxparse.c
> pcl/pxl/pxparse.h
> pcl/pxl/pxptable.c
> pcl/pxl/pxptable.h
> pcl/pxl/pxpthr.c
> pcl/pxl/pxpthr.h
> pcl/pxl/pxsessio.c
> pcl/pxl/pxspec.txt
> pcl/pxl/pxstate.c
> pcl/pxl/pxstate.h
> pcl/pxl/pxstream.c
> pcl/pxl/pxsymbol.ps
> pcl/pxl/pxsymbol.psc
> pcl/pxl/pxsymbol.psh
> pcl/pxl/pxtag.h
> pcl/pxl/pxtop.c
> pcl/pxl/pxvalue.c
> pcl/pxl/pxvalue.h
> pcl/pxl/pxvendor.c
> pcl/pxl/pxvendor.h
> pcl/tools/cmpi/cmpi.cpp
> pcl/tools/pxlasm.py
> pcl/tools/pxldis.py
> pcl/tools/suite.tcl
> psi/bfont.h
> psi/btoken.h
> psi/dmmain.c
> psi/dmmain.r
> psi/dpmain.c
> psi/dscparse.c
> psi/dscparse.h
> psi/dstack.h
> psi/dwdll.c
> psi/dwdll.h
> psi/dwimg.c
> psi/dwimg.h
> psi/dwmain.c
> psi/dwmain.rc
> psi/dwmainc.c
> psi/dwnodll.c
> psi/dwreg.c
> psi/dwreg.h
> psi/dwres.h
> psi/dwtext.c
> psi/dwtext.h
> psi/dwtrace.c
> psi/dwtrace.h
> psi/dxmain.c
> psi/dxmainc.c
> psi/estack.h
> psi/files.h
> psi/ghost.h
> psi/gs.c
> psi/gsdll.c
> psi/gsdll2.rc
> psi/gsdll32.rc
> psi/gserver.c
> psi/gsos2.rc
> psi/ialloc.c
> psi/ialloc.h
> psi/iapi.c
> psi/iapi.h
> psi/iastate.h
> psi/iastruct.h
> psi/ibnum.c
> psi/ibnum.h
> psi/ichar.h
> psi/ichar1.h
> psi/icharout.h
> psi/icid.h
> psi/icie.h
> psi/icolor.h
> psi/iconf.c
> psi/iconf.h
> psi/icontext.c
> psi/icontext.h
> psi/icremap.h
> psi/icsmap.h
> psi/icstate.h
> psi/iddict.h
> psi/iddstack.h
> psi/idebug.c
> psi/idebug.h
> psi/idict.c
> psi/idict.h
> psi/idictdef.h
> psi/idicttpl.h
> psi/idisp.c
> psi/idisp.h
> psi/idosave.h
> psi/idparam.c
> psi/idparam.h
> psi/idsdata.h
> psi/idstack.c
> psi/idstack.h
> psi/ierrors.h
> psi/iesdata.h
> psi/iestack.h
> psi/ifapi.h
> psi/ifcid.h
> psi/ifilter.h
> psi/ifilter2.h
> psi/ifont.h
> psi/ifont1.h
> psi/ifont2.h
> psi/ifont42.h
> psi/ifrpred.h
> psi/ifunc.h
> psi/ifwpred.h
> psi/igc.c
> psi/igc.h
> psi/igcref.c
> psi/igcstr.c
> psi/igcstr.h
> psi/igstate.h
> psi/iht.h
> psi/iimage.h
> psi/iimage2.h
> psi/iinit.c
> psi/iinit.h
> psi/ilevel.h
> psi/ilocate.c
> psi/imain.c
> psi/imain.h
> psi/imainarg.c
> psi/imainarg.h
> psi/imemory.h
> psi/iminst.h
> psi/iname.c
> psi/iname.h
> psi/inamedef.h
> psi/inameidx.h
> psi/inames.h
> psi/inamestr.h
> psi/inobtokn.c
> psi/inouparm.c
> psi/int.mak
> psi/interp.c
> psi/interp.h
> psi/iosdata.h
> psi/iostack.h
> psi/ipacked.h
> psi/iparam.c
> psi/iparam.h
> psi/iparray.h
> psi/ipcolor.h
> psi/iplugin.c
> psi/iplugin.h
> psi/ireclaim.c
> psi/iref.h
> psi/isave.c
> psi/isave.h
> psi/iscan.c
> psi/iscan.h
> psi/iscanbin.c
> psi/iscanbin.h
> psi/iscannum.c
> psi/iscannum.h
> psi/isdata.h
> psi/isstate.h
> psi/istack.c
> psi/istack.h
> psi/istkparm.h
> psi/istream.h
> psi/istruct.h
> psi/itoken.h
> psi/iutil.c
> psi/iutil.h
> psi/iutil2.c
> psi/iutil2.h
> psi/ivmem2.h
> psi/ivmspace.h
> psi/main.h
> psi/mkfilelt.cpp
> psi/msvc.mak
> psi/msvc32.mak
> psi/msvc64.mak
> psi/nsisinst.nsi
> psi/oparc.h
> psi/opcheck.h
> psi/opdef.h
> psi/oper.h
> psi/opextern.h
> psi/os2.mak
> psi/ostack.h
> psi/psromfs.mak
> psi/sfilter1.c
> psi/store.h
> psi/winint.mak
> psi/zalg.c
> psi/zarith.c
> psi/zarray.c
> psi/zbfont.c
> psi/zbseq.c
> psi/zcfont.c
> psi/zchar.c
> psi/zchar1.c
> psi/zchar2.c
> psi/zchar32.c
> psi/zchar42.c
> psi/zchar42.h
> psi/zcharout.c
> psi/zcharx.c
> psi/zcid.c
> psi/zcie.c
> psi/zcie.h
> psi/zcolor.c
> psi/zcolor.h
> psi/zcolor1.c
> psi/zcolor2.c
> psi/zcolor3.c
> psi/zcontext.c
> psi/zcontrol.c
> psi/zcrd.c
> psi/zcsindex.c
> psi/zcspixel.c
> psi/zcssepr.c
> psi/zdevcal.c
> psi/zdevice.c
> psi/zdevice2.c
> psi/zdfilter.c
> psi/zdict.c
> psi/zdouble.c
> psi/zdpnext.c
> psi/zdps.c
> psi/zdps1.c
> psi/zdscpars.c
> psi/zfaes.c
> psi/zfapi.c
> psi/zfarc4.c
> psi/zfbcp.c
> psi/zfcid.c
> psi/zfcid0.c
> psi/zfcid1.c
> psi/zfcmap.c
> psi/zfdctd.c
> psi/zfdcte.c
> psi/zfdecode.c
> psi/zfile.c
> psi/zfile.h
> psi/zfile1.c
> psi/zfileio.c
> psi/zfilter.c
> psi/zfilter2.c
> psi/zfimscale.c
> psi/zfjbig2.c
> psi/zfjpx.c
> psi/zfmd5.c
> psi/zfont.c
> psi/zfont0.c
> psi/zfont1.c
> psi/zfont2.c
> psi/zfont32.c
> psi/zfont42.c
> psi/zfontenum.c
> psi/zform.c
> psi/zfproc.c
> psi/zfrsd.c
> psi/zfrsd.h
> psi/zfsample.c
> psi/zfsha2.c
> psi/zfunc.c
> psi/zfunc.h
> psi/zfunc0.c
> psi/zfunc3.c
> psi/zfunc4.c
> psi/zfzlib.c
> psi/zgeneric.c
> psi/zgstate.c
> psi/zhsb.c
> psi/zht.c
> psi/zht1.c
> psi/zht2.c
> psi/zht2.h
> psi/zicc.c
> psi/zicc.h
> psi/zimage.c
> psi/zimage2.c
> psi/zimage3.c
> psi/ziodev.c
> psi/ziodev2.c
> psi/ziodevs.c
> psi/ziodevsc.c
> psi/zmath.c
> psi/zmatrix.c
> psi/zmedia2.c
> psi/zmisc.c
> psi/zmisc1.c
> psi/zmisc2.c
> psi/zmisc3.c
> psi/zncdummy.c
> psi/zpacked.c
> psi/zpaint.c
> psi/zpath.c
> psi/zpath1.c
> psi/zpcolor.c
> psi/zpdf_r6.c
> psi/zpdfops.c
> psi/zrelbit.c
> psi/zshade.c
> psi/zstack.c
> psi/zstring.c
> psi/zsysvm.c
> psi/ztoken.c
> psi/ztrans.c
> psi/ztrap.c
> psi/ztype.c
> psi/zupath.c
> psi/zusparam.c
> psi/zutf8.c
> psi/zvmem.c
> psi/zvmem2.c
> psi/zwinutf8.c
> toolbin/GenSubstCID.ps
> toolbin/afmutil.py
> toolbin/color/icc_creator/ICC_Creator/CIELAB.h
> toolbin/color/icc_creator/ICC_Creator/ICC_Creator.cpp
> toolbin/color/icc_creator/ICC_Creator/ICC_Creator.h
> toolbin/color/icc_creator/ICC_Creator/ICC_CreatorDlg.cpp
> toolbin/color/icc_creator/ICC_Creator/ICC_CreatorDlg.h
> toolbin/color/icc_creator/ICC_Creator/icc_create.cpp
> toolbin/color/icc_creator/ICC_Creator/icc_create.h
> toolbin/color/icc_creator/README.txt
> toolbin/encs2c.ps
> toolbin/errlist.tcl
> toolbin/extractFonts.ps
> toolbin/extractICCprofiles.ps
> toolbin/gen_ldf_jb2.py
> toolbin/genfontmap.ps
> toolbin/gitlog2changelog.py
> toolbin/gsmake.tcl
> toolbin/halftone/gen_ordered/README
> toolbin/halftone/gen_ordered/gen_ordered_main.c
> toolbin/halftone/gen_stochastic/gen_stochastic.c
> toolbin/halftone/thresh_remap/thresh_remap.c
> toolbin/headers.tcl
> toolbin/jpxtopdf.c
> toolbin/leaks.tcl
> toolbin/makehist.tcl
> toolbin/memory.py
> toolbin/ocheck.py
> toolbin/pdf_info.ps
> toolbin/pre.tcl
> toolbin/precheck.tcl
> toolbin/split_changelog.py
> toolbin/suite.tcl
> toolbin/tests/build_revision.py
> toolbin/tests/check_all.py
> toolbin/tests/check_comments.py
> toolbin/tests/check_dirs.py
> toolbin/tests/check_docrefs.py
> toolbin/tests/cmpi.py
> toolbin/tests/compare_checksumdb.py
> toolbin/tests/compare_checksums.py
> toolbin/tests/dump_checksum.py
> toolbin/tests/dump_checksum_plus.py
> toolbin/tests/dump_checksum_raw.py
> toolbin/tests/fuzzy.c
> toolbin/tests/get_baseline_log.py
> toolbin/tests/get_baselines.py
> toolbin/tests/gscheck_all.py
> toolbin/tests/gscheck_fuzzypdf.py
> toolbin/tests/gscheck_pdfwrite.py
> toolbin/tests/gscheck_raster.py
> toolbin/tests/gscheck_testfiles.py
> toolbin/tests/gsconf.py
> toolbin/tests/gsparamsets.py
> toolbin/tests/gssum.py
> toolbin/tests/gstestgs.py
> toolbin/tests/gstestutils.py
> toolbin/tests/gsutil.py
> toolbin/tests/make_baselinedb.py
> toolbin/tests/make_testdb.py
> toolbin/tests/make_two_pdfversions
> toolbin/tests/make_two_versions
> toolbin/tests/myoptparse.py
> toolbin/tests/rasterdb.py
> toolbin/tests/revert_baseline
> toolbin/tests/revert_pdfbaseline
> toolbin/tests/run_nightly.py
> toolbin/tests/run_parallel
> toolbin/tests/run_regression.py
> toolbin/tests/testdiff.py
> toolbin/tests/update_baseline.py
> toolbin/tests/update_specific
> toolbin/tmake.tcl
> xps/ghostxps.h
> xps/xps.mak
> xps/xpsanalyze.c
> xps/xpscff.c
> xps/xpscolor.c
> xps/xpscommon.c
> xps/xpscrc.c
> xps/xpsdoc.c
> xps/xpsfapi.c
> xps/xpsfapi.h
> xps/xpsfont.c
> xps/xpsglyphs.c
> xps/xpsgradient.c
> xps/xpshash.c
> xps/xpsimage.c
> xps/xpsjpeg.c
> xps/xpsjxr.c
> xps/xpsmem.c
> xps/xpsopacity.c
> xps/xpspage.c
> xps/xpspath.c
> xps/xpspng.c
> xps/xpsresource.c
> xps/xpsromfs.mak
> xps/xpstiff.c
> xps/xpstile.c
> xps/xpstop.c
> xps/xpsttf.c
> xps/xpsutf.c
> xps/xpsvisual.c
> xps/xpsxml.c
> xps/xpszip.c

2018-01-30 08:35:40 +0000
Ken Sharp <ken.sharp@artifex.com>
013b8208180cccf65d3c5ee374b678ceffe39cf7

> Documentation - restore docs on image-qa.ps
> Commit b223c93caa34ad34dfd33d534529b3f11d067aab was slightly over
> enthusiastic and accidentally removed the documentation for the file
> image-qa.ps.
> Restore it here.
> doc/Psfiles.htm

2018-01-29 12:27:04 +0000
Chris Liddell <chris.liddell@artifex.com>
ad8f4138ad44647125424aa4b635aade1a2557ad

> Compiler warning in base/gsicc_manage.c
> Comparing a pointer to '\0' should be comparing to NULL to check for a valid
> string argument,
> base/gsicc_manage.c

2018-01-29 16:12:36 +0000
Ken Sharp <ken.sharp@artifex.com>
b223c93caa34ad34dfd33d534529b3f11d067aab

> Documentation - correct erroneous information in psfiles.htm
> Psfiles.htm incorrectly listed a number of files as being in 'lib'
> when in fact they have been moved to 'Resource/Init. In addition
> Several files were listed which no longer exist, and some files in
> 'examples' were not listed or described.
> I suspect this listing is still not comprehensive, but at I believe
> the information that is there is now at least correct.
> doc/Psfiles.htm

2018-01-29 14:05:50 +0000
Ken Sharp <ken.sharp@artifex.com>
d8ec036836a0abcfe3cc677bb88a61bdfd1a65bb

> pdfwrite - remove a global from gdevpdtt.c
> See bug #693376
> In gdevpdtt.c we hold a static gs_glyph standard_glyph_code_for_notdef
> which is initially assinged to GS_NO_GLYPH, and is later assigned a
> value from the encoding table:
> standard_glyph_code_for_notdef =
> gs_c_name_glyph((const byte *)".notdef", 7) - gs_c_min_std_encoding_glyph;
> However, this is only done if the current value is GS_NO_GLYPH. In effect
> standard_glyph_code_for_notdef is a constant. But we can't define it as
> a constant because the actual value depends on the contents of a table
> which is built at compile time.
> This appears to be an attempt to limit the number of times we call
> gs_c_name_glyph because that is a relatively expensive operation, and
> the actual value returned never changes between builds.
> But we don't want to have globals, really, so this commit simply gets
> and stores the value when the PDF font resource is created in
> font_resource_alloc(). We then can look up the value when we need it.
> This is, obviously, slightly slower than a one-time lookup, because
> we execute it once for every font. It also uses up a fraction more
> memory. However, compared to the performance and memory usage of pdfrwite
> the differences are miniscule.
> devices/vector/gdevpdtf.c
> devices/vector/gdevpdtf.h
> devices/vector/gdevpdtt.c

2018-01-28 10:31:26 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
e29a7e00401549ebb7c03c8324209489b7c87681

> Coverity ID: 259882 Fix typo in pcl_impl_allocate_interp_instance.
> Fix typo to allow conditional freeing of pcli->pcs.pids.
> pcl/pcl/pctop.c

2018-01-19 14:28:46 +0000
Chris Liddell <chris.liddell@artifex.com>
2b155ebd780b5737aac4e8096c8fbaa5cb78212c

> Bug 694260: FAPI: tidy up error return for broken TT glyph
> In the event of an error retrieving a TTF glyph, we were storing the negative
> error code in the same variable we use to store the glyph length for a valid
> glyph, which is an unsigned variable, causing a valgrind error, and potential
> security issue reading uninitialized memory.
> In fact, other consumers silently cope with this type of problem and
> (presumably) use a notdef glyph instead. So this tweaks the error codes to
> do the same.
> Because we now have to differentiate between different types of error, we
> can no longer just use a negative value, so there is an enumerated type for
> the error values.
> base/fapi_ft.c
> base/gxfapi.h
> psi/zfapi.c

2016-08-25 09:28:59 +0100
Chris Liddell <chris.liddell@artifex.com>
b82848bc26f47b5b5727d24f03d08eb3679c7243

> Add script and arch*.h headers for ios build
> This results in a "fat" libgs.a library which can be linked used either for the
> simulator or a "real" ios build.
> Really, this script just automates/simplifies the process of using our existing
> cross-compile support.
> The only slightly out of the ordinary part is combining the Intel and arm
> libraries into the single fat library.
> configure.ac
> ios/build_ios_gslib.sh
> ios/ios-README.txt
> ios/ios_arch-arm.h
> ios/ios_arch-x86.h

2018-01-24 19:23:42 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
83f78ff2c85413866f0d4e549fc6a39aa72417e6

> Bug 697545 : Fix memory leak in cmsCreateLab2ProfileTHR.
> Fix memory leak for allocation event numbers 821 - 854.
> Error created using :-
> MEMENTO_FAILAT=860 ./membin/gpcl6 -sDEVICE=ppmraw -o /dev/null ./pcl/examples/owl.pcl
> lcms2art/src/cmsvirt.c

2018-01-24 18:42:46 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
e8501487c929db1bc1a624bf101a3464b447db07

> Bug 697545 : Fix memory leak in BuildRGBOutputMatrixShaper.
> Fix memory leak for allocation event numbers 787 - 792.
> Error created using :-
> MEMENTO_FAILAT=795 ./membin/gpcl6 -sDEVICE=ppmraw -o /dev/null ./pcl/examples/owl.pcl
> lcms2art/src/cmsio1.c

2018-01-23 18:10:04 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
571200a055310b157f3640742f32564fc2de5697

> Bug 697545 : Fix memory leak c_param_write.
> Fix memory leak for allocation event number 676.
> Error created using :-
> MEMENTO_FAILAT=677 ./membin/gpcl6 -sDEVICE=ppmraw -o /dev/null ./pcl/examples/owl.pcl
> base/gscparam.c

2018-01-23 18:18:49 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
92ccfa3dcb2ca9fd2273611f7ed2111d3ae319a8

> Bug 697545 : Fix memory leak in cmsStageAllocMatrix.
> Fix memory leak for allocation event numbers 753 - 754.
> Error created using :-
> MEMENTO_FAILAT=755 ./membin/gpcl6 -sDEVICE=ppmraw -o /dev/null ./pcl/examples/owl.pcl
> lcms2art/src/cmslut.c

2016-12-20 12:30:50 +0100
Tor Andersson <tor.andersson@artifex.com>
0c498888ca6c0bdf4b90d1b3a79a4a185d810a22

> Fix clusterpush detection for mupdf repositories.
> toolbin/localcluster/clusterpush.pl

2018-01-24 17:02:26 +0100
Tor Andersson <tor.andersson@artifex.com>
bb6abd533cdfed34d076c3320c931d778189c202

> Make gitpush.sh script executable.
> toolbin/localcluster/gitpush.sh

2018-01-24 15:18:07 +0000
Ken Sharp <ken.sharp@artifex.com>
9010c622cd4d17053ee405bb378ed08bcaa16251

> pdfwrite - ensure we have a substream Resource dictionary before using it
> Bug #692182 "xps -> pdfwrite SEGVs with softmasked pattern"
> After much messing about with this bug over the years, it appears
> that most of the bugs have been fixed. However one still remained;
> we could attempt to add a ProcSet Resource to a substream, even
> though we had not yet allocated a Resource for that substream.
> Although it shows up with this file, technically it could
> probably happen with any kind of input.
> Fixed here by allocating a substream Resource dictionary if we
> don't already have one when we want to add the Procsets to it.
> No differences expected
> devices/vector/gdevpdfi.c

2018-01-24 09:33:20 +0000
Chris Liddell <chris.liddell@artifex.com>
eb5f2a85c5c3f6436df6158d7fba1977be68116f

> Bug 698903: bounds check t2 charstring stack in op
> Add a stack bounds checking macro for the Type 2 charstring stack, and use it
> for the rmoveto op.
> base/gstype2.c

2018-01-23 18:15:18 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
f5e42eb1dc1cc96bab67990e886756a089a3fa5a

> Bug 697545 : Fix memory leak in AllocateToneCurveStruct.
> Fix memory leak for allocation event number 741.
> Error created using :-
> MEMENTO_FAILAT=742 ./membin/gpcl6 -sDEVICE=ppmraw -o /dev/null ./pcl/examples/owl.pcl
> lcms2art/src/cmsgamma.c

2018-01-23 18:05:54 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
ebae375c979146fd8c2457e217dcb4e67618a718

> Bug 697545 : Fix memory leak in gs_copydevice2.
> Fix memory leak for allocation event number 673.
> Error created using :-
> MEMENTO_FAILAT=674 ./membin/gpcl6 -sDEVICE=ppmraw -o /dev/null ./pcl/examples/owl.pcl
> base/gsdevice.c

2018-01-23 08:49:04 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
34f29fe8f77a626ef71c1f04fd781dd8b8bacd85

> Bug 697545 : Fix pxstate memory leak.
> Fix memory leak for allocation event numbers 517 - 520.
> Error created using :-
> MEMENTO_FAILAT=578 ./membin/gpcl6 -sDEVICE=ppmraw -o /dev/null ./pcl/examples/owl.pcl
> base/gsfont.c
> pcl/pxl/pxstate.c

2018-01-23 16:42:34 +0000
Ken Sharp <ken.sharp@artifex.com>
2ce962cfc20267b3e678d8d1357dfc2643b7a477

> pdfwrite - take advantage of GSUB table glyph substitution enhancement
> Bug #691574 "vert punctuation is rotated when convert ps to 1.3 pdf"
> Commit 7dd033589ce40649ab602fba4c0473aa40c48439 was an enhancement to
> apply vertical glyph substitution from a TrueType GSUB table. This is
> primarily used when a user specifies a TrueType font to be used as a
> replacement for a missing CIDFont (especially in PDF files). Using a
> horizontal font as a replacement for a vertical font can result in
> punctuation marks at the wrong orientation.
> This commit uses the machinery added in that previous commit to apply
> the same fix for pdfwrite. Note that this still does not produce
> 'correct' output, because its still a substitute font being used. It
> does produce punctuation marks at the correct orientation now though,
> for the limited selection of test files we have. The other relevant
> report is 698471, though that was reported against rendering, the same
> effect occurs with pdfwrite.
> The cluster shows one diff, a progression, which surprises me since I
> cannot duplicate the reference output, but I'm not going to complain
> since its a progression.
> devices/gxfcopy.c
> devices/gxfcopy.h
> devices/vector/gdevpdtb.c
> devices/vector/gdevpdtc.c

2018-01-22 17:14:31 -0700
Henry Stiles <henry.stiles@artifex.com>
de0bad3a42012d57fea6c2d55325c033db7a3ded

> Fix Bug 698874 - incorrect text positioning.
> The bug title is misleading, this a font selection problem where 1 of
> 2 fonts with the same attributes must be selected. Experiments
> suggest the HP chooses the font which was defined earliest. We
> emulate the same effect in our interpreter by creating sequential PJL
> font numbers for downloaded fonts and the selection algorithm
> prefering lower numbers.
> Progression with the test file bug690520.pcl.
> pcl/pcl/pcfont.c
> pcl/pcl/pcfsel.c
> pcl/pcl/pcsfont.c
> pcl/pcl/pcstate.h

2018-01-22 11:32:20 -0800
Ray Johnston <ray.johnston@artifex.com>
b5b6ffad4c3e6d12fbb1caf9d0f17d7de77ca3c3

> Fix rc_increment for CMM_THREAD_SAFE case (only 1 param, not 2)
> Thanks to Michael Vrhel for tripping over this first.
> base/gxclthrd.c

2018-01-20 18:12:08 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
8089072692df101c5464e67b3c3a2cebf9b6682d

> Bug 697545 : Fix memory leak in gstate_free_contents.
> Fix memory leak for allocation event numbers 346 - 348.
> Error created using :-
> MEMENTO_FAILAT=349 ./membin/gpcl6 -sDEVICE=ppmraw -o /dev/null ./pcl/examples/owl.pcl
> base/gsstate.c

2018-01-20 13:01:22 -0800
Ray Johnston <ray.johnston@artifex.com>
6adaf9b4d691bfec64d6d6888bb4fed776a2da12

> Bug 698867: Don't push texttransparency knockout group for invisible text
> The customer's example file had text that was not opaque, but was being
> rendered in TextRenderingMode 3 (invisible). Don't push the extra
> transparency group for this. Reduces time from 483 seconds to 44 seconds
> with default clist params, and with BufferSpace of > 32m down to 14 seconds.
> Also reduces page mode (-dBufferSpace=2000m) from 40 minutes to 9 seconds.
> base/gdevp14.c

2018-01-20 10:55:29 -0800
Ray Johnston <ray.johnston@artifex.com>
1bc1bfaf123e866695813895d02da0956f79cb31

> Minor fix and addition of debugging info for clist cropping.
> base/gxclimag.c
> base/gxclist.c

2018-01-22 15:20:29 +0000
Ken Sharp <ken.sharp@artifex.com>
eb5d417375e1c7052aeb9f2532d34573bfd07f53

> Feature - JPEG Pass through
> This commit adds the capability for the PostScript and PDF interpreters
> to pass JPEG compressed image data directly to a device (currently the
> pdfwrite family of devices) as the original JPEG data.
> This allows us to avoid the compression artefacts caused by decompressing
> JPEG image data, and then applying JPEG compression again.
> This works by having the JPEG decoder inquire (via spec_op) if the
> current device would like the original uncompressed data. If so then it
> instructs the JPEG stream decoder to call a routine which will use
> more spec_ops to pass the uncompressed data to the device.
> The interpreter still calls the image methods with the decompressed
> data, its up to the device to ignore these calls while handling JPEG
> pass-through.
> We have to work this way in PostScript, as we must decompress the data
> as it arrives in order to find the end of the DCT compressed data. In
> addition, this allows the device to change its mind about accepting
> compressed data directly if it discovers from the image data that it
> is not suitable for preserving unchanged.
> This approach does not work with the PXL and XPS interpreters. These
> interpreters appear to completely decompress the JPEG data before
> starting an image, unlike the PostScript and PDF interpreters where the
> image methods are called as the stream is decopressed.
> As a result this feature is disabled for these interpreters.
> Resource/Init/gs_pdfwr.ps
> base/gxdevsop.h
> base/sdct.h
> base/sdctd.c
> devices/vector/gdevpdfb.h
> devices/vector/gdevpdfi.c
> devices/vector/gdevpdfj.c
> devices/vector/gdevpdfx.h
> devices/vector/gdevpsdf.h
> devices/vector/gdevpsdi.c
> devices/vector/gdevpsdp.c
> doc/VectorDevices.htm
> pcl/pxl/pximage.c
> pcl/pxl/pxvendor.c
> psi/int.mak
> psi/zfdctd.c
> xps/xpsjpeg.c
> xps/xpstiff.c
> xps/xpstile.c

2018-01-21 14:53:08 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
f858f560061560cbd3670509206dfdd98fea4d07

> Bug 697545 : Fix memory leak in px_state_alloc.
> Fix memory leak for allocation event numbers 515 and 516.
> Error created using :-
> MEMENTO_FAILAT=517 ./membin/gpcl6 -sDEVICE=ppmraw -o /dev/null ./pcl/examples/owl.pcl
> pcl/pxl/pxstate.c

2018-01-20 22:17:57 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
9e0509877950e3ffef5c576472ff12a3e3fb37b3

> Bug 697545 : Fix memory leak of hpgl_parser_state.
> Fix memory leak for allocation event number 420.
> Error created using :-
> MEMENTO_FAILAT=421 ./membin/gpcl6 -sDEVICE=ppmraw -o /dev/null ./pcl/examples/owl.pcl
> pcl/pcl/pcommand.c
> pcl/pcl/pgparse.c

2018-01-20 21:29:08 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
0177158989db4de55199e1b482cbffb033c4a213

> Bug 697545 : Fix memory leak in pcl_impl_allocate_interp_instance.
> Fix memory leak for allocation event numbers 328 - 417.
> Error created using :-
> MEMENTO_FAILAT=419 ./membin/gpcl6 -sDEVICE=ppmraw -o /dev/null ./pcl/examples/owl.pcl
> pcl/pcl/pctop.c

2018-01-20 20:02:53 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
3278973da5d771e3fc56d1a4295c3bdb3a1a51b5

> Bug 697545 : Fix memory leak in file_prepare_stream.
> Fix memory leak for allocation event number 357.
> Error created using :-
> MEMENTO_FAILAT=358 ./membin/gpcl6 -sDEVICE=ppmraw -o /dev/null ./pcl/examples/owl.pcl
> base/sfxcommon.c

2018-01-20 19:07:34 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
43711760b611b1a8e17f3490e3b58914508098f9

> Bug 697545 : Fix memory leak in gs_nulldevice.
> Fix memory leak for allocation event number 355.
> Error created using :-
> MEMENTO_FAILAT=356 ./membin/gpcl6 -sDEVICE=ppmraw -o /dev/null ./pcl/examples/owl.pcl
> base/gsdevice.c

2018-01-19 10:01:22 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
76aea30116ea14ebb2238d34251e44a7e547ebf0

> Bug 697545 : Fix memory leak in gs_gstate_alloc.
> Fix memory leak for allocation event numbers 330 - 334. The path, clip_path and
> effective_clip_path are initialised at the start of gs_gstate_alloc during the
> call to gstate_alloc so this redundant code can be removed.
> Error created using :-
> MEMENTO_FAILAT=348 ./membin/gpcl6 -sDEVICE=ppmraw -o /dev/null ./pcl/examples/owl.pcl
> base/gsstate.c

2018-01-20 14:34:13 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
b09da43f803fda306d3eb8eca99d825f70156db7

> Bug 697545 : Fix memory leak in gp_enumerate_files_init.
> Fix memory leak for allocation event numbers 199 and 200.
> Error created using :-
> MEMENTO_FAILAT=201 ./membin/gpcl6 -sDEVICE=ppmraw -o /dev/null ./pcl/examples/owl.pcl
> base/gp_unifs.c

2018-01-17 20:02:32 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
76c335c7672e3841055d6c6effc2ae61715c8b6a

> Bug 697545 : Fix memory leak in gs_enumerate_files_init.
> Fix memory leak for allocation event numbers 183 and 184.
> Error created using :-
> MEMENTO_FAILAT=185 ./membin/gpcl6 -sDEVICE=ppmraw -o /dev/null ./pcl/examples/owl.pcl
> base/gsiodev.c

2018-01-18 12:06:11 +0000
Chris Liddell <chris.liddell@artifex.com>
4b8eb0c07b84667b0e3f5ab47f328767012781bf

> Bug 691224 : Remove the long non-functional DISKFONTS feature.
> This feature (allowing Type 1 fonts to be loaded into VM without CharStrings
> and individual CharStrings read from the font file on demand) only ever worked
> with very specifically formatted Type 1 fonts (those coming from the also long
> dead and gone bdftops.ps tool). Any significant variation from that format
> would not work.
> As we no longer use fonts derived from BDF (and BDF are very much a thing of the
> past!), DISKFONTS has not worked for a *long* time, hence removing it.
> In addition, even on printers, memory is no longer quite the issue it was, nor
> are the core Postscript fonts as widely used or relied upon as they were.
> Resource/Init/gs_diskf.ps
> Resource/Init/gs_fonts.ps
> Resource/Init/gs_init.ps
> Resource/Init/gs_type1.ps
> doc/Psfiles.htm
> doc/Use.htm
> doc/gs-vms.hlp
> man/gs.1
> psi/int.mak
> psi/psromfs.mak

2018-01-18 12:39:00 -0800
Ray Johnston <ray.johnston@artifex.com>
f3e26b054b866678512cd6c0c2e2daba9f4c17db

> Bug 697856: Reduce clist buffer memory usage for worst case files.
> The band_height is chosen based on number of bytes per scan line, and
> a fudge factor if the page uses transparency. For pages with a large
> number of raster lines, the number of bands could cause the space
> needed for the band "states" to exceed the space remaining in the
> buffer. This was handled by doubling the BufferSpace until there
> was enough space for the band states. Improve by increasing the space
> available more gradually. For one of the worst case files, Bug689581.pdf,
> this reduces the memory needed from 40Mb to 24Mb.
> base/gdevprn.c

2018-01-17 17:33:48 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
c470009cbf8be2aaed7b4b438307479959949625

> Bug 697545 : Fix memory leak in pl_main_delete_instance.
> Fix memory leak for allocation event number 28.
> Error created using :-
> MEMENTO_FAILAT=183 ./membin/gpcl6 -sDEVICE=ppmraw -o /dev/null ./pcl/examples/owl.pcl
> pcl/pl/plmain.c

2018-01-17 12:54:59 -0800
Ray Johnston <ray.johnston@artifex.com>
3c90c6e03844713000f0e300e371487fa49980f5

> Fix bug 697843: Use after free in pdf14_device_finalize
> The trans_group_parent_cmap_procs (misnamed because it has a LOT of
> parent color info along with the cmap procs) needs to be allocated
> in stable_memory to prevent a dangling pointer being seen during the
> pdf14_device_finalize during alloc_restore_all because the parent
> color info may be freed before the pdf14 device itself.
> base/gdevp14.c

2018-01-17 11:43:55 -0800
Ray Johnston <ray.johnston@artifex.com>
bfda8d1f442e3c8e81018833c3698ffcb63535fb

> Fix (some) missing dependencies
> Noticed during other work, but not committed as part of those fixes
> since this is unrelatd.
> devices/devs.mak

2018-01-17 11:18:42 -0800
Ray Johnston <ray.johnston@artifex.com>
c998242a1168320aba8efb909189654f153b8dd3

> Fix bug 698306: consecutive pushpdf14devicefilter leads to SEGV
> If we get to pushpdf14devicefilter with the pdf14 device, the closedevice
> will forward the close to the target, but if the pdf14 device hasn't
> been disabled, the opendevice won't forward to the target. Call the
> pdf14_disable_device to make sure the pdf14_open_device will forward.
> base/gdevp14.c
> psi/int.mak
> psi/ztrans.c

2018-01-17 12:29:00 +0000
Chris Liddell <chris.liddell@artifex.com>
f0fe2481a2e9b0b632a1d4e804a5a1d27fe9c017

> Prevent undefined error with -DDEBUG
> The procedure for dumping VM stats with -DDEBUG and -DINITDEBUG was not being
> bound, so the .<operator> internal operators we now undefine after
> initialization were missing by the time the procedure was called.
> Now, simply bind the procedure
> Resource/Init/gs_init.ps

2018-01-16 20:04:30 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
6e7149bae6bd5c2a7b5acff50ba6600b3beb3818

> Bug 697545 : Memory squeezing fix for double freeing of ToneCurve.
> Avoid SEGV by removing unnecessary freeing of ToneCurve.
> Error created using :-
> MEMENTO_FAILAT=751 ./membin/gpcl6 -sDEVICE=ppmraw -o /dev/null ./pcl/examples/owl.pcl
> lcms2art/src/cmsio1.c

2018-01-16 19:41:55 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
1bbf91df4b8df650f3efe0effd37cf1cf91c9657

> Bug 697545 : Memory squeezing fix for mutex in lcms2art code
> Prevent SEGV by checking for NULL mutex pointer before attempting
> to use or destroy it.
> lcms2art/src/cmserr.c

2018-01-15 17:26:37 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
3aeff79d28e832aefcd005c99ae67304c927b3d3

> Bug 697545 : Fix memory leaks and SEGVs.
> Prevent table being orphaned due to early memory allocation failures. Remove
> cleanup code to prevent double freeing iodev entries. Prevent SEGV when ramfs
> state fails to allocate.
> Error created using :-
> MEMENTO_FAILAT=25 ./membin/gpcl6 -sDEVICE=ppmraw -o /dev/null ./pcl/examples/owl.pcl
> base/gsiodev.c
> base/gsioram.c

2018-01-16 11:18:27 +0000
Chris Liddell <chris.liddell@artifex.com>
d250ce572e7f2e067693a19de8d38b6612b73501

> Fix segfault with "all devices" test.
> Turns out there's a group of devices that actually open a file as they are being
> closed, which causes problems if we've already freed up the I/O device table,
> which commit 2e86e7f64e added.
> So, rejig the Postscript interpreter's I/O device table init/finit functions to
> allow later freeing of the table (whilst keeping the two consistent in their
> parameters).
> psi/iinit.c
> psi/iinit.h
> psi/imain.c

2018-01-16 10:47:14 +0000
Ken Sharp <ken.sharp@artifex.com>
e62df8bbd78e8db1cb254a6ab4c2ebf1232c6c7e

> Reduce severity of memory debug problem detection
> Bug #698849 "gs_abort with Bad object"
> The error occurs because of the combination of -Z? and -dLastPage. In
> order to do First/Last Page processing, we insert a subclassing device
> ahead of the regular device (ppmraw in this case).
> The subclassing works by making a new device structure, copying the
> existing device to it, and replacing the content of the existing
> device structure. This is done to maintain coherency of gsave/grestore
> and save/restore; the structures maintain pointers to the device in
> the graphics state structure, so we can't simply move it.
> When subclassing, we change the declared size of the structure (ssize)
> but we don't (can't!) change the size that the memory manager allocated
> in the first place. This leads to a mismatch between the declared size
> of the structure and the allocated size. I mentioned this in the
> original commit for subclassing, but noted that in normal use there is
> nowhere that actually checks.
> However, if you set -Z? then additional checks are done on memory
> validity, and this discrepancy is flagged. It also raises an abort,
> presumably because this is seen as serious enough to stop and
> investigate.
> I don't want to remove this check altogether, as it may still be useful,
> but we don't want to abort now because this might be a benign change
> caused by subclassing.
> So here, pull the size != ssize check out separately from the other
> consistency checks, and if it is not true raise a warning, but do
> *not* abort the process.
> psi/ilocate.c

2018-01-15 11:41:01 -0800
Ray Johnston <ray.johnston@artifex.com>
4d730d2087680cff4e3b153536922406bfcf4493

> Fix bug 698823. Segfault with psdrgb and transparency_example.ps
> The psdrgb device has max_components == 3, but the pdf14 device was
> using spot_colors to set it more than that (transparency_example.ps
> doed not set PageSpotColors so it was -1, leading to underflow).
> If page_spot_colors is the default -1, then don't use it, and also
> limit the num_components to max_components for the device.
> base/gdevp14.c

2018-01-15 08:14:02 -0800
Ray Johnston <ray.johnston@artifex.com>
afe8e5468db1f875432aa711676eaf4007d13daa

> Fix opening of files > 2GB on Windows built with VS after VS2013
> For whatever reason, even on 64 bit builds, Visual Studio changed
> behaviour and the compiler/run-time now invoke __fstat64i32 for
> fstat. This returns an error if the file size can't fit in int32
> (the older fstat just returned a negative number, ignoring overflow)
> Change to use __fstat64 which works on VS 2005 so it should be
> fine. I also tested this build on an ancient Dell with 760Mb RAM
> running Windows XP SP3 and it runs fine, so __fstat64 is not a
> problem going back that far.
> base/stat_.h

2018-01-15 17:22:38 +0000
Ken Sharp <ken.sharp@artifex.com>
b199f558834d0fbd365cccc426eed0fdc3e035c7

> pdfwrite - Fix the detection of type 3 descendants in composite fonts
> Bug #698844 "ps2pdf creates unusually large PDF files starting with version 9.21"
> Bug #698647 "PCL5 - Downloadfont not as T3 Font interpreted"
> Bug #607462 "Ghostscript falls into infinite loop with pdfwrite"
> The actual problem was that a Type 0 composite font with a single
> descendant was used with stringwidth and the space glyph. This was not
> detected by pdf_text_begin() and so the glyph was cached, but it was not
> added to any type 3 font, it was simply processed as a stringwidth.
> Later the same glyph from the same font was used in earnest, pdfwrite
> noticed it didn't have a copy of the glyph and set up to capture the
> CharProc. But the glyph was present in the glyph cache which meant the
> CharProc wasn't executed, leading to an infinite loop.
> The fix applied prevented caching type 3 fonts, but that caused problems
> with cases where we wanted to convert a font to type 3, so the fix
> was extended to only prevent caching of input type 3 fonts, not
> synthesised ones.
> However, this still caused problems with programs which used type 3 fonts
> with glyphshow. Because we did not cache the glyphs we would detect each
> glyph use through glyphshow as a new glyph, and so there would be no
> glyph reuse, leading to large slow PDF files.
> Here we extend the check on descendants of type 3 fonts so that if no
> font change takes place, we still check the 'current' descendant to
> see if its type 3. If a type 3 descendant is detected then we skip
> caching the glyph which prevents the whole problem.
> No differences expected.
> devices/vector/gdevpdtt.c

2018-01-15 14:06:34 +0000
Chris Liddell <chris.liddell@artifex.com>
99a839311c7d7e1dab919bd88f7632c5e230708f

> Remove hamrless/pointless no-op assignment from previous commit
> psi/zfapi.c

2018-01-15 13:48:27 +0000
Chris Liddell <chris.liddell@artifex.com>
ead0b5bee31a6e2756749a5c8fb6508e49b64703

> Bug 698856: Ensure is_glyph_index flag is consistently set
> The is_glyph_index is (now) set as a local variable, then copied to
> the structure before the ps_get_glyphname_or_cid() function returns.
> A couple of branches in the code were still setting the structure value directly
> meaning the local variable was wrong.
> psi/zfapi.c

2018-01-15 08:17:46 +0000
Chris Liddell <chris.liddell@artifex.com>
2e86e7f64ed169345c9fb49b9c9eaf0a1bf78720

> Bug 698842: cleanup the io_dev table and contents
> This is slightly complicated as (in the Ghostscript case) the table can be
> freed explicitly, or by the garbager.
> base/gdevpipe.c
> base/gp_mshdl.c
> base/gp_msprn.c
> base/gp_os2pr.c
> base/gsiodev.c
> base/gsiodevs.c
> base/gsiodisk.c
> base/gsioram.c
> base/gsiorom.c
> base/gslib.c
> base/gxiodev.h
> base/lib.mak
> pcl/pl/pl.mak
> pcl/pl/plmain.c
> psi/iinit.c
> psi/iinit.h
> psi/imain.c
> psi/int.mak
> psi/zdevcal.c
> psi/ziodev.c
> psi/ziodev2.c
> psi/ziodevs.c
> psi/ziodevsc.c

2018-01-12 08:48:21 +0000
Chris Liddell <chris.liddell@artifex.com>
d0829c3cc4d64594499035d664c918acc9047d70

> Update to latest CMap release from Adobe
> From:
> https://github.com/adobe-type-tools/cmap-resources
> Resource/CMap/78-EUC-H
> Resource/CMap/78-EUC-V
> Resource/CMap/78-H
> Resource/CMap/78-RKSJ-H
> Resource/CMap/78-RKSJ-V
> Resource/CMap/78-V
> Resource/CMap/78ms-RKSJ-H
> Resource/CMap/78ms-RKSJ-V
> Resource/CMap/83pv-RKSJ-H
> Resource/CMap/90ms-RKSJ-H
> Resource/CMap/90ms-RKSJ-V
> Resource/CMap/90msp-RKSJ-H
> Resource/CMap/90msp-RKSJ-V
> Resource/CMap/90pv-RKSJ-H
> Resource/CMap/90pv-RKSJ-V
> Resource/CMap/Add-H
> Resource/CMap/Add-RKSJ-H
> Resource/CMap/Add-RKSJ-V
> Resource/CMap/Add-V
> Resource/CMap/Adobe-CNS1-0
> Resource/CMap/Adobe-CNS1-1
> Resource/CMap/Adobe-CNS1-2
> Resource/CMap/Adobe-CNS1-3
> Resource/CMap/Adobe-CNS1-4
> Resource/CMap/Adobe-CNS1-5
> Resource/CMap/Adobe-CNS1-6
> Resource/CMap/Adobe-CNS1-7
> Resource/CMap/Adobe-GB1-0
> Resource/CMap/Adobe-GB1-1
> Resource/CMap/Adobe-GB1-2
> Resource/CMap/Adobe-GB1-3
> Resource/CMap/Adobe-GB1-4
> Resource/CMap/Adobe-GB1-5
> Resource/CMap/Adobe-Japan1-0
> Resource/CMap/Adobe-Japan1-1
> Resource/CMap/Adobe-Japan1-2
> Resource/CMap/Adobe-Japan1-3
> Resource/CMap/Adobe-Japan1-4
> Resource/CMap/Adobe-Japan1-5
> Resource/CMap/Adobe-Japan1-6
> Resource/CMap/Adobe-Japan2-0
> Resource/CMap/Adobe-Korea1-0
> Resource/CMap/Adobe-Korea1-1
> Resource/CMap/Adobe-Korea1-2
> Resource/CMap/B5-H
> Resource/CMap/B5-V
> Resource/CMap/B5pc-H
> Resource/CMap/B5pc-V
> Resource/CMap/CNS-EUC-H
> Resource/CMap/CNS-EUC-V
> Resource/CMap/CNS1-H
> Resource/CMap/CNS1-V
> Resource/CMap/CNS2-H
> Resource/CMap/CNS2-V
> Resource/CMap/ETHK-B5-H
> Resource/CMap/ETHK-B5-V
> Resource/CMap/ETen-B5-H
> Resource/CMap/ETen-B5-V
> Resource/CMap/ETenms-B5-H
> Resource/CMap/ETenms-B5-V
> Resource/CMap/EUC-H
> Resource/CMap/EUC-V
> Resource/CMap/Ext-H
> Resource/CMap/Ext-RKSJ-H
> Resource/CMap/Ext-RKSJ-V
> Resource/CMap/Ext-V
> Resource/CMap/GB-EUC-H
> Resource/CMap/GB-EUC-V
> Resource/CMap/GB-H
> Resource/CMap/GB-V
> Resource/CMap/GBK-EUC-H
> Resource/CMap/GBK-EUC-V
> Resource/CMap/GBK2K-H
> Resource/CMap/GBK2K-V
> Resource/CMap/GBKp-EUC-H
> Resource/CMap/GBKp-EUC-V
> Resource/CMap/GBT-EUC-H
> Resource/CMap/GBT-EUC-V
> Resource/CMap/GBT-H
> Resource/CMap/GBT-V
> Resource/CMap/GBTpc-EUC-H
> Resource/CMap/GBTpc-EUC-V
> Resource/CMap/GBpc-EUC-H
> Resource/CMap/GBpc-EUC-V
> Resource/CMap/H
> Resource/CMap/HKdla-B5-H
> Resource/CMap/HKdla-B5-V
> Resource/CMap/HKdlb-B5-H
> Resource/CMap/HKdlb-B5-V
> Resource/CMap/HKgccs-B5-H
> Resource/CMap/HKgccs-B5-V
> Resource/CMap/HKm314-B5-H
> Resource/CMap/HKm314-B5-V
> Resource/CMap/HKm471-B5-H
> Resource/CMap/HKm471-B5-V
> Resource/CMap/HKscs-B5-H
> Resource/CMap/HKscs-B5-V
> Resource/CMap/Hankaku
> Resource/CMap/Hiragana
> Resource/CMap/Hojo-EUC-H
> Resource/CMap/Hojo-EUC-V
> Resource/CMap/Hojo-H
> Resource/CMap/Hojo-V
> Resource/CMap/Identity-H
> Resource/CMap/Identity-V
> Resource/CMap/KSC-EUC-H
> Resource/CMap/KSC-EUC-V
> Resource/CMap/KSC-H
> Resource/CMap/KSC-Johab-H
> Resource/CMap/KSC-Johab-V
> Resource/CMap/KSC-V
> Resource/CMap/KSCms-UHC-H
> Resource/CMap/KSCms-UHC-HW-H
> Resource/CMap/KSCms-UHC-HW-V
> Resource/CMap/KSCms-UHC-V
> Resource/CMap/KSCpc-EUC-H
> Resource/CMap/KSCpc-EUC-V
> Resource/CMap/Katakana
> Resource/CMap/NWP-H
> Resource/CMap/NWP-V
> Resource/CMap/RKSJ-H
> Resource/CMap/RKSJ-V
> Resource/CMap/Roman
> Resource/CMap/UniCNS-UCS2-H
> Resource/CMap/UniCNS-UCS2-V
> Resource/CMap/UniCNS-UTF16-H
> Resource/CMap/UniCNS-UTF16-V
> Resource/CMap/UniCNS-UTF32-H
> Resource/CMap/UniCNS-UTF32-V
> Resource/CMap/UniCNS-UTF8-H
> Resource/CMap/UniCNS-UTF8-V
> Resource/CMap/UniGB-UCS2-H
> Resource/CMap/UniGB-UCS2-V
> Resource/CMap/UniGB-UTF16-H
> Resource/CMap/UniGB-UTF16-V
> Resource/CMap/UniGB-UTF32-H
> Resource/CMap/UniGB-UTF32-V
> Resource/CMap/UniGB-UTF8-H
> Resource/CMap/UniGB-UTF8-V
> Resource/CMap/UniHojo-UCS2-H
> Resource/CMap/UniHojo-UCS2-V
> Resource/CMap/UniHojo-UTF16-H
> Resource/CMap/UniHojo-UTF16-V
> Resource/CMap/UniHojo-UTF32-H
> Resource/CMap/UniHojo-UTF32-V
> Resource/CMap/UniHojo-UTF8-H
> Resource/CMap/UniHojo-UTF8-V
> Resource/CMap/UniJIS-UCS2-H
> Resource/CMap/UniJIS-UCS2-HW-H
> Resource/CMap/UniJIS-UCS2-HW-V
> Resource/CMap/UniJIS-UCS2-V
> Resource/CMap/UniJIS-UTF16-H
> Resource/CMap/UniJIS-UTF16-V
> Resource/CMap/UniJIS-UTF32-H
> Resource/CMap/UniJIS-UTF32-V
> Resource/CMap/UniJIS-UTF8-H
> Resource/CMap/UniJIS-UTF8-V
> Resource/CMap/UniJIS2004-UTF16-H
> Resource/CMap/UniJIS2004-UTF16-V
> Resource/CMap/UniJIS2004-UTF32-H
> Resource/CMap/UniJIS2004-UTF32-V
> Resource/CMap/UniJIS2004-UTF8-H
> Resource/CMap/UniJIS2004-UTF8-V
> Resource/CMap/UniJISPro-UCS2-HW-V
> Resource/CMap/UniJISPro-UCS2-V
> Resource/CMap/UniJISPro-UTF8-V
> Resource/CMap/UniJISX0213-UTF32-H
> Resource/CMap/UniJISX0213-UTF32-V
> Resource/CMap/UniJISX02132004-UTF32-H
> Resource/CMap/UniJISX02132004-UTF32-V
> Resource/CMap/UniKS-UCS2-H
> Resource/CMap/UniKS-UCS2-V
> Resource/CMap/UniKS-UTF16-H
> Resource/CMap/UniKS-UTF16-V
> Resource/CMap/UniKS-UTF32-H
> Resource/CMap/UniKS-UTF32-V
> Resource/CMap/UniKS-UTF8-H
> Resource/CMap/UniKS-UTF8-V
> Resource/CMap/V
> Resource/CMap/WP-Symbol

2018-01-13 13:10:08 +0000
Robin Watts <robin.watts@artifex.com>
3b0c7a01433c16f007dd3d92c04edc19bfb79970

> Revert GhostPDL.sln due to stray commit
> I use VS2017 for profiling, so had converted the solution file.
> It should not have been committed, but slipped through. Reverting
> it here.
> windows/GhostPDL.sln

2018-01-13 10:45:32 +0000
Ken Sharp <ken.sharp@artifex.com>
112021a361e9300d9cd0cde0bfc9e691a6e5d0d7

> pdf_info.ps - gracefully handle circular Resource references
> Although not strictly part of Ghostscript, pdf_info.ps is used by
> customers and this is reasonably easy to improve.
> When checking for transparency, pdf_info.ps uses the Ghostscript
> PDF interpreter to do the work. However, other aspects of its operation
> (Media Sizes, Font use) aren't available from the PDF interpreter.
> When detecting Font usage, pdf_info.ps walks the Page Resource chain,
> and any the Resource chains of any Pattern or XObject Resources used
> on that page, as well as the Resources for any Annots (and also any
> XObject or Pattern Resources used by the Annots). If any of these
> Resource chains contains a circular reference (which they absolutely
> should not) then pdf_info will enter a loop and process unwil it
> exceeds the execution stack limit, throwing an error.
> In this commit we borrow the technique used by the PDF interpreter, we
> create a dictionary and every object which we inspect has its object
> number stored in that dictionary. Whenever we encounter a new object
> we first check to see if its number is in that dictionary. If it is, we
> know we've seen it before and this is (possibly) a circular reference.
> Even if it is not a circular reference, we've already checked that chain
> so we don't need to check it again.
> This isn't cluster checked.
> toolbin/pdf_info.ps

2017-12-23 21:19:22 -0800
Ray Johnston <ray.johnston@artifex.com>
3012651caace0d2d4dd26631e0e10d81fdeab181

> Fix Bug 698729: White lines with LeadingEdge=3 and InterpolateControl>1
> Images are always painted in X from left to right, but for landscape the
> lines come in the original order, so if dy is negative we need to back up
> the starting Y coordinate (scaled_y) by the (scaled_h - 1).
> base/gxiscale.c

2018-01-12 09:52:20 -0800
Ray Johnston <ray.johnston@artifex.com>
3110ffa4ee4de170248317813e2e5e5f2d84e75c

> Fix errors: Interpolated images + overprint + devn device
> When using the overprint compositor, the underlying device may be able
> to handle copy_alpha_hl_color (planar devices) so forward to it even
> when the overprint compositor isn't active and use the correct
> overprint_copy_alpha_hl_color for the generic_procs.
> Fix regression errors with psdcmyk device from files in
> tests_private/comparefiles: Bug688308.ps T2CharString.eps and
> from tests_private/ps/ps3cet: 09-47N.PS 10-08.PS 10-14.PS 10-16.PS
> 11-01.PS 11-02.PS 11-03.PS 11-04.PS 11-05.PS 11-06.PS 11-07.PS
> 11-09.PS 11-10.PS 11-11.PS 11-12.PS 11-14.PS 11-15.PS 11-16.PS
> 11-17.PS 11-18.PS 11-19.PS 11-21.PS 11-22.PS 11-26D.PS 11-28.PS
> 12-02.PS 12-04.PS 12-06.PS 12-07D.PS 12-08D.PS 12-11.PS 12-12.PS
> 12-13.PS 13-01.PS 13-02.PS 13-05.PS 13-16.PS 13-17.PS 13-19.PS
> 13-20.PS 13-22.PS 13-26.PS 13-27.PS 13-28.PS 13-29.PS 21-11.PS
> base/gsovrc.c

2018-01-12 08:23:09 -0800
Ray Johnston <ray.johnston@artifex.com>
1508f69d9ed68baac7e659e6089edbf12c9717a9

> Fix devn color affecting psdcmyk tests/pdf/Bug6901014_launch_leaflet.pdf p2
> The image interpolation uses copy_alpha_hl_color so when InterpolateControl=-1
> is used with this file in clist mode, playback ends up calling the
> default_no_copy_alpha_hl_color function which throws an "undefined" error. If
> this proc is seen, instead pass to copy_alpha which can work as long as the
> devn color can be packed into a chunky color which is the case as long as the
> num_components is <= 8, which is useful enough to make it worth trying. If
> the num_components is too large, the copy_alpha will throw a "rangecheck".
> base/gxclrast.c

2018-01-02 11:32:10 -0800
Michael Vrhel <michael.vrhel@artifex.com>
d6a0412e281b786847ec96acc0ba85ffa22bf04d

> Switch to lcms2 Artifex version for CMM
> MuPDF is using Artifex's thread-safe version of lcms2. This commit switches gs to using that
> same version. Having gs take advantage of the thread-safe capabilities will be in a different
> commit.
> Makefile.in
> base/gscms.h
> base/gsicc_cache.c
> base/gsicc_cms.h
> base/gsicc_lcms.c
> base/gsicc_lcms2.c
> base/gsicc_lcms2art.c
> base/gsicc_manage.c
> base/lcms2art.mak
> base/lib.mak
> base/msvclib.mak
> base/openvms.mak
> base/ugcclib.mak
> base/unix-gcc.mak
> base/unixansi.mak
> base/winlib.mak
> configure.ac
> devices/gdevpsd.c
> devices/gdevrinkj.c
> devices/vector/gdevpx.c
> lcms2/README.1ST
> lcms2/doc/LittleCMS2.8 API.pdf
> lcms2/doc/LittleCMS2.8 Plugin API.pdf
> lcms2/doc/LittleCMS2.8 tutorial.pdf
> lcms2/include/Makefile.am
> lcms2art/.travis.yml
> lcms2art/AUTHORS
> lcms2art/COPYING
> lcms2art/ChangeLog
> lcms2art/INSTALL
> lcms2art/Lib/BC/BC.txt
> lcms2art/Lib/MS/MS.TXT
> lcms2art/Makefile.am
> lcms2art/Makefile.in
> lcms2art/Projects/.gitignore
> lcms2art/Projects/BorlandC_5.5/lcms2.rc
> lcms2art/Projects/BorlandC_5.5/lcmsdll.lk
> lcms2art/Projects/BorlandC_5.5/lcmsdll.lst
> lcms2art/Projects/BorlandC_5.5/mklcmsdll.bat
> lcms2art/Projects/VC2010/jpegicc/jpegicc.vcxproj
> lcms2art/Projects/VC2010/jpegicc/jpegicc.vcxproj.filters
> lcms2art/Projects/VC2010/linkicc/linkicc.vcxproj
> lcms2art/Projects/VC2010/linkicc/linkicc.vcxproj.filters
> lcms2art/Projects/VC2010/psicc/psicc.vcxproj
> lcms2art/Projects/VC2010/psicc/psicc.vcxproj.filters
> lcms2art/Projects/VC2010/resource.h
> lcms2art/Projects/VC2010/testbed/testbed.vcxproj
> lcms2art/Projects/VC2010/testbed/testbed.vcxproj.filters
> lcms2art/Projects/VC2010/tiffdiff/tiffdiff.vcxproj
> lcms2art/Projects/VC2010/tiffdiff/tiffdiff.vcxproj.filters
> lcms2art/Projects/VC2010/tifficc/tifficc.vcxproj
> lcms2art/Projects/VC2010/tifficc/tifficc.vcxproj.filters
> lcms2art/Projects/VC2010/transicc/transicc.vcxproj
> lcms2art/Projects/VC2010/transicc/transicc.vcxproj.filters
> lcms2art/Projects/VC2012/jpegicc/jpegicc.vcxproj
> lcms2art/Projects/VC2012/jpegicc/jpegicc.vcxproj.filters
> lcms2art/Projects/VC2012/lcms2art.rc
> lcms2art/Projects/VC2012/lcms2art.sln
> lcms2art/Projects/VC2012/lcms2art_DLL/lcms2art_DLL.vcxproj
> lcms2art/Projects/VC2012/lcms2art_DLL/lcms2art_DLL.vcxproj.filters
> lcms2art/Projects/VC2012/lcms2art_static/lcms2art_static.vcxproj
> lcms2art/Projects/VC2012/lcms2art_static/lcms2art_static.vcxproj.filters
> lcms2art/Projects/VC2012/linkicc/linkicc.vcxproj
> lcms2art/Projects/VC2012/linkicc/linkicc.vcxproj.filters
> lcms2art/Projects/VC2012/psicc/psicc.vcxproj
> lcms2art/Projects/VC2012/psicc/psicc.vcxproj.filters
> lcms2art/Projects/VC2012/resource.h
> lcms2art/Projects/VC2012/testbed/testbed.vcxproj
> lcms2art/Projects/VC2012/testbed/testbed.vcxproj.filters
> lcms2art/Projects/VC2012/tiffdiff/tiffdiff.vcxproj
> lcms2art/Projects/VC2012/tiffdiff/tiffdiff.vcxproj.filters
> lcms2art/Projects/VC2012/tifficc/tifficc.vcxproj
> lcms2art/Projects/VC2012/tifficc/tifficc.vcxproj.filters
> lcms2art/Projects/VC2012/transicc/transicc.vcxproj
> lcms2art/Projects/VC2012/transicc/transicc.vcxproj.filters
> lcms2art/Projects/VC2013/jpegicc/jpegicc.vcxproj
> lcms2art/Projects/VC2013/jpegicc/jpegicc.vcxproj.filters
> lcms2art/Projects/VC2013/lcms2art.rc
> lcms2art/Projects/VC2013/lcms2art.sln
> lcms2art/Projects/VC2013/lcms2art_DLL/lcms2art_DLL.vcxproj
> lcms2art/Projects/VC2013/lcms2art_DLL/lcms2art_DLL.vcxproj.filters
> lcms2art/Projects/VC2013/lcms2art_static/lcms2art_static.vcxproj
> lcms2art/Projects/VC2013/lcms2art_static/lcms2art_static.vcxproj.filters
> lcms2art/Projects/VC2013/linkicc/linkicc.vcxproj
> lcms2art/Projects/VC2013/linkicc/linkicc.vcxproj.filters
> lcms2art/Projects/VC2013/psicc/psicc.vcxproj
> lcms2art/Projects/VC2013/psicc/psicc.vcxproj.filters
> lcms2art/Projects/VC2013/resource.h
> lcms2art/Projects/VC2013/testbed/testbed.vcxproj
> lcms2art/Projects/VC2013/testbed/testbed.vcxproj.filters
> lcms2art/Projects/VC2013/tiffdiff/tiffdiff.vcxproj
> lcms2art/Projects/VC2013/tiffdiff/tiffdiff.vcxproj.filters
> lcms2art/Projects/VC2013/tifficc/tifficc.vcxproj
> lcms2art/Projects/VC2013/tifficc/tifficc.vcxproj.filters
> lcms2art/Projects/VC2013/transicc/transicc.vcxproj
> lcms2art/Projects/VC2013/transicc/transicc.vcxproj.filters
> lcms2art/Projects/VC2015/jpegicc/jpegicc.vcxproj
> lcms2art/Projects/VC2015/jpegicc/jpegicc.vcxproj.filters
> lcms2art/Projects/VC2015/lcms2art.rc
> lcms2art/Projects/VC2015/lcms2art.sln
> lcms2art/Projects/VC2015/lcms2art_DLL/lcms2art_DLL.vcxproj
> lcms2art/Projects/VC2015/lcms2art_DLL/lcms2art_DLL.vcxproj.filters
> lcms2art/Projects/VC2015/lcms2art_static/lcms2art_static.vcxproj
> lcms2art/Projects/VC2015/lcms2art_static/lcms2art_static.vcxproj.filters
> lcms2art/Projects/VC2015/linkicc/linkicc.vcxproj
> lcms2art/Projects/VC2015/linkicc/linkicc.vcxproj.filters
> lcms2art/Projects/VC2015/psicc/psicc.vcxproj
> lcms2art/Projects/VC2015/psicc/psicc.vcxproj.filters
> lcms2art/Projects/VC2015/resource.h
> lcms2art/Projects/VC2015/testbed/testbed.vcxproj
> lcms2art/Projects/VC2015/testbed/testbed.vcxproj.filters
> lcms2art/Projects/VC2015/tiffdiff/tiffdiff.vcxproj
> lcms2art/Projects/VC2015/tiffdiff/tiffdiff.vcxproj.filters
> lcms2art/Projects/VC2015/tifficc/tifficc.vcxproj
> lcms2art/Projects/VC2015/tifficc/tifficc.vcxproj.filters
> lcms2art/Projects/VC2015/transicc/transicc.vcxproj
> lcms2art/Projects/VC2015/transicc/transicc.vcxproj.filters
> lcms2art/Projects/VC2017/jpegicc/jpegicc.vcxproj
> lcms2art/Projects/VC2017/jpegicc/jpegicc.vcxproj.filters
> lcms2art/Projects/VC2017/lcms2art.rc
> lcms2art/Projects/VC2017/lcms2art.sln
> lcms2art/Projects/VC2017/lcms2art_DLL/lcms2art_DLL.vcxproj
> lcms2art/Projects/VC2017/lcms2art_DLL/lcms2art_DLL.vcxproj.filters
> lcms2art/Projects/VC2017/lcms2art_static/lcms2art_static.vcxproj
> lcms2art/Projects/VC2017/lcms2art_static/lcms2art_static.vcxproj.filters
> lcms2art/Projects/VC2017/linkicc/linkicc.vcxproj
> lcms2art/Projects/VC2017/linkicc/linkicc.vcxproj.filters
> lcms2art/Projects/VC2017/psicc/psicc.vcxproj
> lcms2art/Projects/VC2017/psicc/psicc.vcxproj.filters
> lcms2art/Projects/VC2017/resource.h
> lcms2art/Projects/VC2017/testbed/testbed.vcxproj
> lcms2art/Projects/VC2017/testbed/testbed.vcxproj.filters
> lcms2art/Projects/VC2017/tiffdiff/tiffdiff.vcxproj
> lcms2art/Projects/VC2017/tiffdiff/tiffdiff.vcxproj.filters
> lcms2art/Projects/VC2017/tifficc/tifficc.vcxproj
> lcms2art/Projects/VC2017/tifficc/tifficc.vcxproj.filters
> lcms2art/Projects/VC2017/transicc/transicc.vcxproj
> lcms2art/Projects/VC2017/transicc/transicc.vcxproj.filters
> lcms2art/Projects/cppcheck/lcms2.cppcheck
> lcms2art/Projects/mac/LittleCMS/._Info.plist
> lcms2art/Projects/mac/LittleCMS/._LittleCMS.xcodeproj
> lcms2art/Projects/mac/LittleCMS/English.lproj/InfoPlist.strings
> lcms2art/Projects/mac/LittleCMS/Info.plist
> lcms2art/Projects/mac/LittleCMS/LittleCMS.xcodeproj/mariama.mode1v3
> lcms2art/Projects/mac/LittleCMS/LittleCMS.xcodeproj/mariama.pbxuser
> lcms2art/Projects/mac/LittleCMS/LittleCMS.xcodeproj/project.pbxproj
> lcms2art/Projects/mac/LittleCMS/LittleCMS.xcodeproj/project.xcworkspace/contents.xcworkspacedata
> lcms2art/Projects/mac/LittleCMS/LittleCMS.xcodeproj/project.xcworkspace/xcuserdata/User.xcuserdatad/UserInterfaceState.xcuserstate
> lcms2art/Projects/mac/LittleCMS/LittleCMS.xcodeproj/project.xcworkspace/xcuserdata/User.xcuserdatad/WorkspaceSettings.xcsettings
> lcms2art/Projects/mac/LittleCMS/LittleCMS.xcodeproj/xcuserdata/User.xcuserdatad/xcdebugger/Breakpoints.xcbkptlist
> lcms2art/Projects/mac/LittleCMS/LittleCMS.xcodeproj/xcuserdata/User.xcuserdatad/xcschemes/LittleCMS.xcscheme
> lcms2art/Projects/mac/LittleCMS/LittleCMS.xcodeproj/xcuserdata/User.xcuserdatad/xcschemes/testbed.xcscheme
> lcms2art/Projects/mac/LittleCMS/LittleCMS.xcodeproj/xcuserdata/User.xcuserdatad/xcschemes/xcschememanagement.plist
> lcms2art/Projects/mac/LittleCMS/LittleCMS_Prefix.pch
> lcms2art/Projects/mac/LittleCMS/TestBed-Info.plist
> lcms2art/README.1ST
> lcms2art/aclocal.m4
> lcms2art/autogen.sh
> lcms2art/compile
> lcms2art/config.guess
> lcms2art/config.sub
> lcms2art/configure
> lcms2art/configure.ac
> lcms2art/depcomp
> lcms2art/doc/LittleCMS2.9 API.pdf
> lcms2art/doc/LittleCMS2.9 Plugin API.pdf
> lcms2art/doc/LittleCMS2.9 tutorial.pdf
> lcms2art/doc/WhyThisFork.txt
> lcms2art/doc/src.zip
> lcms2art/include/Makefile.am
> lcms2art/include/Makefile.in
> lcms2art/include/lcms2art.h
> lcms2art/include/lcms2art_plugin.h
> lcms2art/install-sh
> lcms2art/lcms2art.pc.in
> lcms2art/ltmain.sh
> lcms2art/m4/acx_pthread.m4
> lcms2art/m4/ax_append_compile_flags.m4
> lcms2art/m4/ax_append_flag.m4
> lcms2art/m4/ax_check_compile_flag.m4
> lcms2art/m4/ax_gcc_func_attribute.m4
> lcms2art/m4/ax_require_defined.m4
> lcms2art/m4/libtool.m4
> lcms2art/m4/ltoptions.m4
> lcms2art/m4/ltsugar.m4
> lcms2art/m4/ltversion.m4
> lcms2art/m4/lt~obsolete.m4
> lcms2art/missing
> lcms2art/src/Makefile.am
> lcms2art/src/Makefile.in
> lcms2art/src/cmsalpha.c
> lcms2art/src/cmscam02.c
> lcms2art/src/cmscgats.c
> lcms2art/src/cmscnvrt.c
> lcms2art/src/cmserr.c
> lcms2art/src/cmsgamma.c
> lcms2art/src/cmsgmt.c
> lcms2art/src/cmshalf.c
> lcms2art/src/cmsintrp.c
> lcms2art/src/cmsio0.c
> lcms2art/src/cmsio1.c
> lcms2art/src/cmslut.c
> lcms2art/src/cmsmd5.c
> lcms2art/src/cmsmtrx.c
> lcms2art/src/cmsnamed.c
> lcms2art/src/cmsopt.c
> lcms2art/src/cmspack.c
> lcms2art/src/cmspcs.c
> lcms2art/src/cmsplugin.c
> lcms2art/src/cmsps2.c
> lcms2art/src/cmssamp.c
> lcms2art/src/cmssm.c
> lcms2art/src/cmstypes.c
> lcms2art/src/cmsvirt.c
> lcms2art/src/cmswtpnt.c
> lcms2art/src/cmsxform.c
> lcms2art/src/extra_xform.h
> lcms2art/src/lcms2_internal.h
> lcms2art/src/lcms2art.def
> lcms2art/testbed/Makefile.am
> lcms2art/testbed/Makefile.in
> lcms2art/testbed/bad.icc
> lcms2art/testbed/bad_mpe.icc
> lcms2art/testbed/crayons.icc
> lcms2art/testbed/ibm-t61.icc
> lcms2art/testbed/new.icc
> lcms2art/testbed/test1.icc
> lcms2art/testbed/test2.icc
> lcms2art/testbed/test3.icc
> lcms2art/testbed/test4.icc
> lcms2art/testbed/test5.icc
> lcms2art/testbed/testcms2.c
> lcms2art/testbed/testcms2.h
> lcms2art/testbed/testplugin.c
> lcms2art/testbed/testthread.cpp
> lcms2art/testbed/toosmall.icc
> lcms2art/testbed/zoo_icc.c
> lcms2art/utils/common/utils.h
> lcms2art/utils/common/vprf.c
> lcms2art/utils/common/xgetopt.c
> lcms2art/utils/delphi/delphidemo.dpr
> lcms2art/utils/delphi/delphidemo.dproj
> lcms2art/utils/delphi/delphidemo.res
> lcms2art/utils/delphi/demo1.dfm
> lcms2art/utils/delphi/demo1.pas
> lcms2art/utils/delphi/lcms2dll.pas
> lcms2art/utils/jpgicc/LICENSE_iccjpeg
> lcms2art/utils/jpgicc/Makefile.am
> lcms2art/utils/jpgicc/Makefile.in
> lcms2art/utils/jpgicc/iccjpeg.c
> lcms2art/utils/jpgicc/iccjpeg.h
> lcms2art/utils/jpgicc/jpgicc.1
> lcms2art/utils/jpgicc/jpgicc.c
> lcms2art/utils/linkicc/Makefile.am
> lcms2art/utils/linkicc/Makefile.in
> lcms2art/utils/linkicc/linkicc.1
> lcms2art/utils/linkicc/linkicc.c
> lcms2art/utils/matlab/icctrans.c
> lcms2art/utils/matlab/lcms_rsp
> lcms2art/utils/psicc/Makefile.am
> lcms2art/utils/psicc/Makefile.in
> lcms2art/utils/psicc/psicc.1
> lcms2art/utils/psicc/psicc.c
> lcms2art/utils/samples/Makefile.am
> lcms2art/utils/samples/Makefile.in
> lcms2art/utils/samples/itufax.c
> lcms2art/utils/samples/mkcmy.c
> lcms2art/utils/samples/mkgrayer.c
> lcms2art/utils/samples/mktiff8.c
> lcms2art/utils/samples/roundtrip.c
> lcms2art/utils/samples/vericc.c
> lcms2art/utils/samples/wtpt.1
> lcms2art/utils/samples/wtpt.c
> lcms2art/utils/tificc/Makefile.am
> lcms2art/utils/tificc/Makefile.in
> lcms2art/utils/tificc/tifdiff.c
> lcms2art/utils/tificc/tificc.1
> lcms2art/utils/tificc/tificc.c
> lcms2art/utils/transicc/Makefile.am
> lcms2art/utils/transicc/Makefile.in
> lcms2art/utils/transicc/transicc.1
> lcms2art/utils/transicc/transicc.c
> psi/msvc.mak
> psi/os2.mak
> psi/zicc.c
> psi/ztrans.c
> windows/ghostscript.vcproj
> windows/ghostscript_rt.vcxproj

2018-01-12 10:56:29 +0000
Ken Sharp <ken.sharp@artifex.com>
b5ac1a6e73af59d5106bf68ed3ab1a456a1c26dc

> PS interpreter - don't use findresource for Idiom Recognition in bind
> The current implementation of idiom recognition uses findresource in
> the definition of the bind operator to check all existing IdiomSets
> for a candidate to substitute.
> This is, in fact, wrong. The PLRM (p135 3rd Edition) states that :
> "This matching by value occurs only for IdiomSet instances that are
> defined in VM; bind does not consider instances that are in not in VM
> but only in external storage."
> and:
> To ensure that the instances in VM are consistent with the external
> ones, the interpreter automatically invokes findresource to load
> external IdiomSet instances into VM at the beginning of each job and at
> certain other times."
> We were not loading the IdiomSet resources into VM, and we were searching
> external resources during bind.
> Not only is this incorrect, but because findresource ends up calling
> filenameforall on every directory in the search path, its also very
> slow.
> While normally we don't expect to see many occurences of bind during the
> course of a job, the customer supplied file did multiple binds on every
> page, and had > 50,000 pages. This led to a fourfold decrease in
> performance compared to Acrobat Distiller.
> Here we load the external resources into gobal VM at startup, and we
> now *only* search instances in VM. This is more correct going by the
> spec, and improves the performance by the desired factor of 4 for the
> customer. It provides a small benefit on cluster testing, which is
> expected as this only affects PostScript input.
> No differences expected.
> Resource/Init/gs_ll3.ps

2018-01-11 19:58:11 +0000
Robin Watts <robin.watts@artifex.com>
338c13198e658b084bbe45930e4837c31102b61f

> ROP Fix: Fix misindexing of scolors/tcolors.
> More evidence that this isn't used much.
> base/gsroprun8.h

2018-01-11 18:34:51 +0000
Robin Watts <robin.watts@artifex.com>
c6fda7403e881ec53f2da6bb6f97f2e647ef523c

> ROPs: Squash scan build warnings.
> base/gsroprun24.h
> base/gsroprun8.h

2018-01-10 21:27:32 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
fc5f089b580040fb70a662e44721fe2fb457ecfa

> Bug 697545 : Fix new_font_defaults memory leak.
> Fix memory leak for allocation event numbers 165 - 180.
> Error created using :-
> MEMENTO_FAILAT=181 ./membin/gpcl6 -sDEVICE=ppmraw -o /dev/null ./pcl/examples/owl.pcl
> pcl/pl/pjparse.c

2018-01-10 21:10:43 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
30ca563d890a503fe4411a404d09c36839120114

> Bug 697545 : Fix new_font_envir memory leak.
> Fix memory leak for allocation event numbers 146 - 161.
> Error created using :-
> MEMENTO_FAILAT=162 ./membin/gpcl6 -sDEVICE=ppmraw -o /dev/null ./pcl/examples/owl.pcl
> pcl/pl/pjparse.c

2018-01-11 17:43:44 +0000
Robin Watts <robin.watts@artifex.com>
6a706f687ae99626ef5b16b71e5df6a05c202e33

> ROP fix: Correctly set scolors/tcolors S and T data case.
> We weren't setting S and T colors in this particular case of
> the code, which would have shown errors if we'd ever called
> it with S and T being 1 bit data arrays to choose between
> scolors[0] and [1] etc.
> It appears that no code in our entire regression suite actually
> calls the S and D both being data case anyway, as proved by
> cluster testing this code with an "abort();" line inserted!
> base/gdevmr8n.c

2018-01-11 17:40:41 +0000
Robin Watts <robin.watts@artifex.com>
aa8accce0a3f3d323dc45f6bf510a3ddfa76d10d

> ROP code: Correction
> Don't look for transparency when depth is 1 (it shouldn't be
> used anyway).
> Correct transparency handling in 8 bit (it was using 0xffffff
> as the color to check for in this mode). Oddly this wasn't
> producing diffs, which suggests that nothing is exercising
> this code in 8 bit.
> base/gsroprun.c

2018-01-10 20:52:35 -0800
Ray Johnston <ray.johnston@artifex.com>
eb59c64085552ef0f98c1afdaae3c39ad4e5d421

> Fix stale pointer de-reference during GC due to restore.
> If a CIEBasedDEF or DEFG colorspace was set in a save level, a restore
> would free the Table memory, but the pgs->icc_profile_cache still had
> a (stale) pointer to that area. Fix by copying the Table to memory that
> is not subject to save/restore (stable_memory). Rely on the GC to free
> up the previous table data since we have no idea what allocator was
> used for it (from PostScript it would be local or global VM). Seen with:
> -Z:?@$ -r300 -sDEVICE=psdcmyk -o x.psd tests_private/comparefiles/Bug688308.ps
> psi/zcie.c

2018-01-11 12:03:30 +0000
Robin Watts <robin.watts@artifex.com>
9b3b93ca92f8b9370d4cb5a4e6176df1a06afeda

> ROP optimisation: Map more rops onto one another.
> Establish an ordering on rops ("unused" < "constant" <
> "bitmap" < "1 bit bitmap") and swap orders such that S
> is always >= T.
> This cuts the number of cases down a bit more.
> base/gsroprun.c

2018-01-02 08:48:33 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
c56dff6dea636c89b7c24bbec7b28f15171d7810

> Bug 697545 : Fix pjl_envir memory leak.
> Fix memory leak for allocation event numbers 89 - 143.
> Error created using :-
> MEMENTO_FAILAT=144 ./membin/gpcl6 -sDEVICE=ppmraw -o /dev/null ./pcl/examples/owl.pcl
> pcl/pl/pjparse.c

2017-12-31 14:57:30 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
411530608129ad6dd2078557a7f3d0a3425a9db8

> Bug 697545 : Fix new_pjl_defaults memory leak.
> Fix memory leak for allocation event numbers 32 - 89.
> Error created using :-
> MEMENTO_FAILAT=90 ./membin/gpcl6 -sDEVICE=ppmraw -o /dev/null ./pcl/examples/owl.pcl
> pcl/pl/pjparse.c

2018-01-10 17:15:38 +0000
Robin Watts <robin.watts@artifex.com>
623d2ceee814622b5a75e13120165d8a2f4a2d35

> ROP transparency optimisation.
> If a transparent ROP uses a constant input that is
> transparent, then it's a NOP.
> base/gsroprun.c

2018-01-08 19:10:01 +0000
Robin Watts <robin.watts@artifex.com>
151cb32d94b5790fae44f48763e19c519ac742cb

> Miscellaneous fixes to roprun code.
> Fold some more rops down to simpler ones.
> Remove some functions that are no longer required. Allow
> for NOP ROPs to short circuit all the work.
> Also, fix what looks like a problem in the setup for 1bit ROPs.
> (Doesn't actually seem to have caused a problem but the new
> code is more readable).
> Avoid intermixing rop_operand * and gx_color_index *'s.
> base/gdevm1.c
> base/gdevmr8n.c
> base/gsroprun.c
> base/gsroprun24.h
> base/gsroprun8.h
> base/gsropt.h

2018-01-09 16:38:04 +0000
Robin Watts <robin.watts@artifex.com>
3927036c14c12857be7dbf98dc777631a365977e

> Fix problem with bitrgbtags and ROPs.
> With bitrgbtags, we can get called to do 24 bit rop operations
> with transparency, with colors like 0x01ffffff.
> The transparency rop code is supposed to spot 0xffffff as meaning
> "be transparent", but the tag in the top byte confuses it.
> Accordingly, mask off stray bits in the colors before using them.
> The same potentially happens for an 8 bit + tags device so we cope
> with that too.
> base/gdevmr8n.c

2018-01-09 07:19:35 -0800
Ray Johnston <ray.johnston@artifex.com>
a8612bfd86f7753fceb738364b2808a4ad9d3bdf

> Fix SEGV DEBUG build with -ZA (tests_private/comparefiles/Bug688308.ps)
> base/gsalloc.c

2018-01-08 12:04:57 +0000
Robin Watts <robin.watts@artifex.com>
9b38e9780bf5cbb9dbf41131efa80887826c59b4

> Enable the use of the RUN_ROP code.
> I thought this had been done years ago :(
> Fix a typo that was causing cluster differences, squash some
> warnings, and fix the scolors/tcolors cases to index as
> gx_color_index *'s rather than byte *'s.
> Presumably these are the reasons this didn't get enabled before.
> Cluster shows no differences now.
> Tests with running 600dpi grashopp.pcl to ppm show this saves
> ~5.5%.
> base/gdevmr8n.c
> base/gsroprun.c
> base/gsroprun24.h
> base/gsropt.h
> base/lib.mak

2017-12-11 19:11:04 +0100
David Kaspar [Dee'Kej] <dkaspar@redhat.com>
731559c56907f223c9f0763d512fae7e4d13e1a0

> Bug 698814: use --docdir= configure parameter
> Previously, the Ghostscript was using custom path to the documentation
> (as docdir=$(gsdatadir)/doc). This was causing that value of --docdir=
> parameter of ./configure was accepted, but not used at all.
> This commit fixes this issue, by using docdir=@docdir@@VERSIONED_PATH@
> instead. However, as a side effect this results in default path for
> documentation to changed to this (with --prefix=/usr):
> /usr/share/doc/ghostscript/<version>/
> To stay backward compatible, a symlink is automatically created to
> point from the old location (/usr/share/ghostscript/<version>/doc) to
> the new location.
> NOTE: Trying to fix this issue with the location of documentation
> staying as it was would require some hacking inside the Autoconf
> itself, which is not desirable.
> Makefile.in
> base/unixinst.mak

2017-12-11 17:27:39 +0100
David Kaspar [Dee'Kej] <dkaspar@redhat.com>
0da8eed54f24cf3dcb5f950c742a8072b7c7e01a

> Bug 698813: do not install examples/ by default anymore
> Those files in the examples/ folder are for testing purposes,
> and not really good examples for people trying to learn PostScript.
> However, we are keeping the 'make install-examples' target for people
> who still wishes to use those files for some reason.
> base/unixinst.mak

2017-11-29 16:42:45 +0100
David Kaspar [Dee'Kej] <dkaspar@redhat.com>
eb3f2ab6f3c5c1d113a8314c0251ca1e50b1196b

> Bug 698795: --without-versioned-path option introduced
> Using this option will result in Ghostscript being installed into a
> paths which do not contain its version in them, which can be useful
> on some distributions.
> As a result of using this option, the Ghostscript's search path will
> be updated as well, to include correct files locations.
> This option is disabled by default, and configure's help page states
> that using this option is dangerous, risky and unsupported.
> Makefile.in
> configure.ac

2018-01-06 18:27:24 +0000
Robin Watts <robin.watts@artifex.com>
3c120a33a91c9251c9a9e409680e92d9625a92da

> Back out stray change in last commit.
> windows/GhostPDL.sln

2018-01-05 17:04:59 +0000
Robin Watts <robin.watts@artifex.com>
47d4d0779563983ab79362acbf3522758ce7a09c

> Optimise some image_render_mono cases.
> Split a case within image_render_mono into separate portrait
> and landscape cases. Use fill rectangle rather than fill_trap
> to save time, and avoid halftoning where possible.
> This saves us about 15% runtime in 1000pages.pcl.
> base/gximono.c
> windows/GhostPDL.sln

2018-01-04 17:53:56 +0000
Robin Watts <robin.watts@artifex.com>
d356025602f3f9f9a1e656bd14430cd95c059548

> Tiny additional tweaks to compose groups.
> Measurable differences, but only just.
> base/gxblend.c

2018-01-04 15:56:55 +0000
Robin Watts <robin.watts@artifex.com>
75f389e6b8a2f2bf15ab3044ae4e1ef185061e8d

> pdf14 compose group (masked group) optimisation.
> The common case is for the mask (if there is one) to entirely
> cover the group we are masking. We can avoid needless
> checking in this case.
> This is the case the apple airprint performance test file
> hits and saves > 4% pam, 5% ppm, and 9% pgm.
> base/gxblend.c

2017-12-29 17:43:01 +0000
Robin Watts <robin.watts@artifex.com>
193e3b87bc711d30be0c2c41f6b3e61f49c92b22

> Fix problem with parsing non 8 bit arguments.
> A problem was reported on IRC, pointing out that we fail to
> correctly parse single char switches when we are using
> GS_ARG_ENCODING_UTF16LE.
> This is because arg_next was failing to convert non-indirected
> arguments correctly.
> Fixed here.
> base/gsargs.c

2017-12-29 13:17:49 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
5907bf4f455cca68cbb405116e3c98d14a5a59d6

> Bug 697545 : Fix pjl_state line buffer memory leak.
> Fix memory leak for allocation event number 30.
> Error created using :-
> MEMENTO_FAILAT=31 ./membin/gpcl6 -sDEVICE=ppmraw -o /dev/null ./pcl/examples/owl.pcl
> pcl/pl/pjparse.c

2017-12-29 14:37:20 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
9ba8351735da67a3064710136499340810c120c1

> Bug 697545 : Fix pl_main_languages_init interp memory leak.
> Fix memory leak for allocation event number 28, the interp_client_data is
> not set so this memory will not be recovered via the normal route of
> pl_deallocate_interp_instance.
> Error created using :-
> MEMENTO_FAILAT=29 ./membin/gpcl6 -sDEVICE=ppmraw -o /dev/null ./pcl/examples/owl.pcl
> pcl/pl/plmain.c

2017-12-29 15:34:32 +0000
Robin Watts <robin.watts@artifex.com>
2b940da204752545813c475488a0a7afd7b55fc7

> Fix LCMS2 optimisation bug
> Found this while importing the optimisations here into the MuPDF
> version of LCMS. When copying for identity transformations,
> allow for extra bytes too.
> GS clearly doesn't exercise this routine in this way.
> lcms2/src/cmsxform.c

2017-12-23 10:50:11 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
906314509273578d4fb5382a8d922ccb2b7adb10

> Bug 697545 : Fix gs_fapi_init memory leak.
> Fix memory leak for allocation event number 13.
> Error created using :-
> MEMENTO_FAILAT=14 ./membin/gpcl6 -sDEVICE=ppmraw -o /dev/null ./pcl/examples/owl.pcl
> pcl/pl/plmain.c

2017-12-13 17:28:11 -0800
Michael Vrhel <michael.vrhel@artifex.com>
9a089895193d71ad6ad70a91cbf9fe02a121261c

> Introduce ColorAccuracy setting
> Set the level of accuracy that should be used. A setting of 0 will result in less accurate
> color rendering compared to a setting of 2. However, the creation of a transformation
> will be faster at a setting of 0 compared to a setting of 2. Default setting is 2.
> base/gsdparam.c
> base/gsicc_cms.h
> base/gsicc_lcms2.c
> base/gsicc_manage.c
> base/gsicc_manage.h
> base/gslibctx.c
> base/gslibctx.h
> doc/Use.htm

2017-12-28 13:56:37 +0000
Ken Sharp <ken.sharp@artifex.com>
4fb32aef42d267948d97243e7f5512a2b37431b0

> XPS interpreter - when discarding an ICC profile for an image, NULL hte pointer
> Possibly Bug #698834 " xps dump"
> Its not at all clear what the bug reporter sees as a problem, but when
> I run the file to the display the XPS interpreter warns that it is
> discarding an ICC profile because it has the wrong number of
> components (profile has 4 in, 3 out components, image claims to be
> RGB).
> This counts the profile reference down by 1 but doesn't set the pointer
> to the profile, saved in the image structure, to NULL leading to us
> trying to free a garbage pointer later.
> Setting the pointer to NULL solves the problem, and may fix the bug
> report, if that's what the reporter is complaining about.
> xps/xpsimage.c

2017-12-21 19:41:20 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
32cc4f267175dcc7a0dac0219e8e042ec9918cd9

> Bug 697545 : Fix main instance memory leak.
> Fix memory leak for allocation event number 12.
> Error created using :-
> MEMENTO_FAILAT=13 ./membin/gpcl6 -sDEVICE=ppmraw -o /dev/null ./pcl/examples/owl.pcl
> pcl/pl/plmain.c

2017-12-20 14:20:13 +0000
Ken Sharp <ken.sharp@artifex.com>
3b24fd02b2bbeaef3d2e0374023fa330a9cddeac

> Add 'gs_restrict' to function prototypes to match functions
> Also add gs_restrict to some functions, because they are assigned to
> function pointers that expect gs_restrict pointers.
> base/gxblend.c
> base/gxblend.h

2017-12-19 16:15:17 +0000
Robin Watts <robin.watts@artifex.com>
ac7e8dfb78a2b3ae2875f64e6feb6f4dce5300b4

> More tweaking to pdf14_fill_rect cases.
> Ensure that the gray/rgb/cmyk cases for AirPrint all go through
> routines that have been hand tweaked.
> base/gxblend.c

2017-12-19 18:22:28 +0000
Robin Watts <robin.watts@artifex.com>
f00a08ec0a7f2fedbc2a7d14c603ec22758ed81c

> Avoid shadowing a variable in mark_fill_rect_add3_common.
> base/gxblend.c

2017-12-19 15:21:55 +0000
Chris Liddell <chris.liddell@artifex.com>
28c4beb74e779da37c4e7aa7f149750a98c09a73

> Remove obsolete font files:
> NimbusSans-BoldOblique (replaced with NimbusSans-BoldItalic)
> NimbusSans-Oblique (replaced with NimbusSans-Italic)
> Resource/Font/NimbusSans-BoldOblique
> Resource/Font/NimbusSans-Oblique

2017-12-19 13:23:42 +0000
Robin Watts <robin.watts@artifex.com>
9d1e45d36064249220ca2f51280770aaaab3a971

> Common up optimised cases of group blending.
> Additive and Subtractive make no difference (modulo rounding) when
> dealing with normal mode blends. As such we can halve the number
> of optimised routines required.
> base/gxblend.c

2017-12-19 10:16:16 +0000
Ken Sharp <ken.sharp@artifex.com>
1143a7aba79e6316ccfb5fc2b0943dcd7a64a48f

> pdfwrite - drop unusable Matte from SMask when doing colour conversion
> Bug #698817 "ColorConversionStrategy=Gray breaks image with smask"
> SMask images can have a Matte entry which is a preblended colour. It
> must have the same number of components as the parent image. If we are
> doing colour conversion then we can't unconditionally use the existing
> Matte value, as it may have the wrong number of components for the
> converted image.
> In fact Matte values are optional and rare. Even rarer are Matte entires
> which have any actual effect. We can't use the value (unless the parent
> image was already in the target colour space, and we can't realistically
> convert the Matte to another space.
> So here we test the color conversion strategy, if the image colour space
> is not the same as the target, then we simply discard the Matte entry.
> This isn't 'correct', but then nothing will be, and this stops Acrobat
> from whinging and refusing to render the image at all.
> devices/vector/gdevpdfi.c

2017-12-19 09:05:22 +0000
Ken Sharp <ken.sharp@artifex.com>
6e77c8f647fecaa1a31116fbcd59ad26fb650905

> pdfimage - eliminate a compiler warning
> Check a return code to eliminate a compiler warning.
> devices/gdevpdfimg.c

2017-12-18 20:59:39 +0000
Robin Watts <robin.watts@artifex.com>
fbf0e1c9f7014b602f9dd94e8fac37b21dffc798

> Add CMYK optimised core to image rendering.
> Add irii_inner_32bpp_4spp_1abs to go along with others. This one
> is hit in the AirPrint test file when going to CMYK.
> base/gxiscale.c

2017-12-13 15:37:53 +0000
Robin Watts <robin.watts@artifex.com>
f34cae2ebb2c85c13787fd828eb6194e32cb19d2

> Optimise image_render_interpolate_icc.
> Split out the core of the routine into a function call. The
> guts of the original routine go into irii_inner_template,
> which can be static instantiated as required.
> I had hoped that merely instantiating this 3 times would be
> enough to optimise the routines, but in the end I had to
> manually cut the core down for the 2 cases that the AirPrint
> test file hits.
> base/gxiscale.c
> windows/GhostPDL.sln

2017-12-18 16:38:31 +0000
Ken Sharp <ken.sharp@artifex.com>
9fb23615725e8a2d6a722814a348094a48a41c36

> pdfimage - support the '%d' output format specifier
> It hadn't occurred to me that anyone would want to do this, so I hadn't
> implemented it. On reflection its probably useful, and it should
> (finally) solve the all devices regression report problem.
> At the same time, add the file to the Windows solution so that we get
> debug information in it.
> devices/gdevpdfimg.c
> windows/ghostscript.vcproj

2017-12-18 15:09:02 +0000
Robin Watts <robin.watts@artifex.com>
561327c559cd8fa6cb5840a80806cff38ef9aa0b

> Manual optimisation of AirPrint hotspot.
> compose_group_nonknockout_nonblend_add_isolated_mask_common_solid
> takes a significant amount of time in the AirPrint test file.
> Unroll it manually and optimise to avoid needless planar -> chunky
> -> planar copying.
> base/gxblend.c

2017-12-18 11:27:32 +0000
Ken Sharp <ken.sharp@artifex.com>
51f279ece4f34c17119a543725c5aee3ca4f8d1d

> Fix pattern code for devices handling patterns by subclassing new device
> The pattern code permits for us to use an 'internal' accumulator or for
> a device to declare it can handle patterns itself. When a device handles
> patterns we pass spec_ops to the device to delineate the pattern
> operations.
> It can happen that when the pattern terminates we (g)restore back to a
> point before the internal pattern accumulator device was pushed into
> the graphics state. To handle that possibility we push a pointer to the
> device onto the exec stack and use that stored pointer to tell the
> pattern accumulator device when the pattern terminates, even if it is
> no longer the current device at that time.
> Unfortunately this conflicts with the ability for other devices to
> handle patterns. The code uses that same stored device pointer to
> indicate whether we are using the internal accumulator or not. If the
> stored pointer is NULL then we are not using the internal accumulator.
> But this assumed that, if we aren't using the internal accumulator, that
> the current device is the one which declared it could handle the pattern.
> This is dangerous anyway, because there's not restriction on how fat
> back we might have restored, and its possible (if unlikely) that the
> device now in the graphics state isn't the one that can handle
> patterns. In addition, if the underlying device handles patterns by
> subclassing itself with a new pattern handling device, then when we
> restore back, even though the device is the one which stated it could
> handle patterns, its not the one we want to inform of the pattern
> termination.
> We handle this simply by getting the current device after the 'start'
> notification. I think its reasonable to assume that the device now in
> place is the one which expects to receive the 'close' message. We
> then store that device on the exec stack. When we get to the cleanup
> routine, if we decide we are not using the internal accumulator, then
> we call the new stored device to handle it.
> I think ideally we should store a flag for whether we are using the
> internal accumulator, but it wouldn't be any more efficient.
> psi/zpcolor.c

2017-12-18 09:11:05 +0000
Ken Sharp <ken.sharp@artifex.com>
15d80a143b71b9b61d007e2abb67a74a5f753cea

> pdfimage - change the way files are closed
> The 'all devices' regression test persists in throwing errors and
> seg faulting with these devices when closing. I can't reproduce the
> problem on Linux.
> So instead of preventing the gdevprn code from closing the file, prevent
> the stream code from closing the file instead, and allow the gdevprn
> code to perform normally.
> Hopefully this will solve the problem.....
> devices/gdevpdfimg.c

2017-12-18 09:08:58 +0000
Ken Sharp <ken.sharp@artifex.com>
9de2f57c80bc9e6a25e3fd570a5c1df3321404eb

> Check for the existence of _MSV_VER before testing its value
> On Linux _MSC_VER is not defined, and so leads to a warning everywhere
> that stdpre.h is included.
> This just eliminates the warning.
> base/stdpre.h

2017-12-16 11:01:40 +0000
Ken Sharp <ken.sharp@artifex.com>
8af42f2da3425a634ec78d8a0add1658778e2226

> Define gs_restrict as a synonym for the compiler 'restrict' definition
> Using the 'restrict' tag tells the compiler that it can safely assume
> no aliasing of pointers is involved, allowing for even higher levels
> of optimisation. However since this is a non-standard extension
> (though widely supported) the exact definition varies.
> We know of 'restrict', '__restrict', '__restrict__' and 'cdecl(restrict)'
> The Visual Studio cdecl causes problems with us simply using 'restrict'
> and #defining it in stdpre.h because stdlib.h includes the cdecl. If
> we include stdpre.h before stdlib.h then the compiler tries to expand
> 'cdecl(resgister)' to 'cdecl(__register)' and that fails.
> The only way to accommodate all the various options is to use something
> other than the 'restrict' keyword, and to #define that as required for
> the different compilers.
> This commit introduces the 'gs_restrict' keyword and that is #defined
> in stdpre.h to be appropriate for whatever compiler is in use (the
> default is to define it to nothing). This means that wherever we want
> to use the restrict capability, we must include stdpre.h.
> base/claptrap-planar.c
> base/claptrap.c
> base/claptrap.h
> base/ets.c
> base/ets.h
> base/gxblend.c
> base/gxblend1.c
> base/gxscanc.c
> base/gxscanc.h
> base/siscale.c
> base/stdpre.h

2017-12-15 21:01:31 +0000
Robin Watts <Robin.Watts@artifex.com>
b35aa4c4e4a8e77395b45051ca2621e6823c5623

> Add optimised LCMS transform operations.
> Add a full set of optimised functions for {1,3,4} -> {1,3,4}
> channels in either 1 or 2 byte form. This should cover all
> the cases we'll hit in gs until we start using spots.
> lcms2/src/cmsxform.c

2017-12-16 16:10:48 -0800
Ray Johnston <ray.johnston@artifex.com>
e8e7034a9714191315313daa4a45ce626a9f6cf7

> Fix bug 698816: Performance with transparency due to commit 3a9d6eb
> Tracked this down to the push_transparency_group logic not skipping the
> allocation of the buffer when "idle" was set. This reduced 32-bit Windows
> 9.22 from 45.9 seconds to 19.9 seconds.
> Even more good news, HEAD (SHA 3f9c130f 32-bit Windows) from 37.5 seconds to
> 11.9 seconds.
> base/gdevp14.c

2017-12-15 19:07:07 +0000
Robin Watts <Robin.Watts@artifex.com>
3f9c130f778167b2f0486bef1c3a2d027433ec57

> Optimise pdf14_fill_rectangle for CMYK
> Add optimised CMYK case.
> base/gxblend.c

2017-12-15 11:50:32 +0000
Robin Watts <Robin.Watts@artifex.com>
0333c58af9a48a14a0e9323732332104e577dc85

> Optimise pdf14_fill_rectangle.
> Optimisations for the common case as seen in Airprint
> test file.
> base/gxblend.c

2017-12-15 09:54:15 +0000
Robin Watts <Robin.Watts@artifex.com>
9b35281f914bb77f5e68070fb6ce4e32e955dcc8

> Add new optimised case for pdf14_fill_rect
> mark_fill_rect_additive_nospots_common_no_alpha_g.
> For the Airprint test case.
> base/gxblend.c

2017-12-14 20:06:37 +0000
Robin Watts <robin.watts@artifex.com>
3dfca86e11ea2143525758325ea0feff06e42a52

> Further optimisations to image_render_color_icc.
> Split it into 3 routines; portrait, landscape and skew.
> base/gxicolor.c

2017-12-14 18:42:14 +0000
Robin Watts <robin.watts@artifex.com>
e0ebcde1ce879cf74fb9d8b53670478d5d03717b

> Optimise image_render_color_icc.
> Avoid using the color_samples hack, as this merely results in us
> first copying bytes into a new buffer, only to effectively
> memcmp it. Just use the bytes directly.
> We lose potential problems with strict aliasing here, and gain
> the benefit of only having to check n bytes rather than
> GS_IMAGE_MAX_COLOR_COMPONENTS bytes each time.
> This gives us a noticable speedup on the Airprint test file.
> base/gxicolor.c

2017-12-15 15:08:40 +0000
Ken Sharp <ken.sharp@artifex.com>
2655f09c04ee2678df98c58764390e9e79bfc254

> PCLm fixes
> rename the device to 'pclm' because none of our devices use capital
> letters.
> Mirror the fix for sclose in the PCLm device (didn't realise this was
> a separate function to the pdfimage devices)
> remove the unused writehex function
> devices/gdevpdfimg.c

2017-12-15 13:06:47 +0000
Ken Sharp <ken.sharp@artifex.com>
3cdca3a2c6cfe74a62797d486ce6c69afd9eacd0

> pdfimage devices - remove UUID code
> The uuid was a holdover from an early incarnation of the code, it
> was dropped later but the code lingered....
> devices/gdevpdfimg.c

2017-12-15 11:21:49 +0000
Ken Sharp <ken.sharp@artifex.com>
44d4d979c25eaea76c2d08aceec058f92ee3ed83

> Make pdfimage devices work on Linux
> Because the devices usurp the FILE * created by the gdevprn code and
> turn it into a stream, we must set the stored pointer to NULL after
> closing or freeing the stream in order to avoid gdev_prn_close()
> attempting to close the underlying file again, which causes an error
> on Linux.
> Also remove some routines we no longer use.
> devices/gdevpdfimg.c

2017-12-13 14:19:43 +0000
Robin Watts <robin.watts@artifex.com>
86322b1ccb1e67cf99672945f1d77925b2902872

> Tweak gx_build_blended_image_row.
> Move from an array index based scheme to a pointer arithmetic
> based scheme. Saves us lots of multiplications per pixel.
> This may not make much difference on x86, but on ARM, where
> pointer arithmetic is largely free, this should help more.
> base/gdevp14.c
> base/gxblend.h
> base/gxblend1.c

2017-12-14 15:27:11 +0000
Robin Watts <robin.watts@artifex.com>
899255deef5a92bf36269d0ef3fa355401fe170f

> Further optimisations to bitmap scaler.
> Use hand unrolled loops rather than static inline optimised ones.
> Fix some debugging. Add CMYK case. Add some restricts. Make the
> zoom_y case explicit in it's reuse of values.
> base/siscale.c

2017-12-14 12:45:08 +0000
Robin Watts <robin.watts@artifex.com>
16eb526bc113a9c783f824ea6940857e302acc3d

> Add restrict qualifier to stdpre.h header.
> Sprinkle it through the blending code. This should never hurt
> and may well help. We should be using it as a matter of course,
> especially in performance critical routines.
> base/gxblend.c
> base/gxblend.h
> base/stdpre.h

2017-12-14 12:00:51 +0000
Ken Sharp <ken.sharp@artifex.com>
34286be72308b7cba275bbf423e589997e9e683e

> Fix compiler warnings after pdfimage device commit
> devices/devs.mak
> devices/gdevpdfimg.c

2017-11-02 08:24:59 +0000
Ken Sharp <ken.sharp@artifex.com>
7a13371ec8dc077c4a3b28f6935206fe06fc534e

> New devices - pdfimage and PCLm
> These devices render input to a bitmap (or in the case of PCLm
> multiple bitmaps) then wraps the bitmap(s) up as the content of
> a PDF file. For PCLm there are some additional rules regarding
> headers, extra content and the order in which the content is
> written in the PDF file.
> The aim is to support the PCLm mobile printing standard, and
> to permit production of PDF files from input where the graphics
> model differs significantly from PDF (eg PCL and RasterOPs).
> Devices are named pdfimage8, pdfimage24, pdfimage32 and PCLm.
> Currently produce valid PDF files with a colour depth of 8 (Gray),
> 24 (RGB) or 32 (CMYK), the PCLm device only supports 24-bit RGB.
> Devices supports the DownScaleFactor switch to implement
> page level anti-aliasing
> -sCompression can be set to None, LZW, Flate, JPEG or RLE (LZW
> is not supported on PCLm, None is only available on PCLm for
> debugging purposes).
> The PCLm device supports -dStripHeight to set the vertical height
> of the strips of image content, as required by the specification.
> For JPEG compression the devices support both the JPEGQ and
> QFactor controls, exactly as per the jpeg and jpeggray devices.
> base/unixansi.mak
> configure.ac
> devices/devs.mak
> devices/gdevpdfimg.c
> devices/vector/gdevpdfe.c
> doc/Devices.htm
> psi/msvc.mak
> psi/os2.mak

2017-12-13 17:55:16 +0000
Robin Watts <robin.watts@artifex.com>
099ba1f50e2af5d43a9f007575e78e3605d008be

> LCMS2 tweak: Spot identity transformations
> Spot identity transformations and handle them as efficiently as
> possible. (i.e. avoid unpack/null transform/repack).
> lcms2/src/cmsopt.c
> lcms2/src/cmsxform.c
> lcms2/src/lcms2_internal.h

2017-12-13 09:25:09 +0000
Robin Watts <robin.watts@artifex.com>
92f0c389ebddf4125dc770f71f4d74187275fd7f

> Add 2 more optimised blend cases for Airprint test case.
> The Airprint Presentation test file hits the
> compose_group_nonknockout_nonblend_add_isolated_mask_common case
> hardest. Add 2 more specialisations of this that cope with
> shape = 255 and alpha == shape == 255.
> This saves us just over half a second (of 13.2) on my desktop PC.
> base/gxblend.c

2017-12-11 19:52:43 +0000
Robin Watts <robin.watts@artifex.com>
b5189a84ddf0ca1454b10bb4a9926cd4f8c4f0eb

> Add PWGDecode filter.
> And lib/viewpwg.ps to use it.
> Makefile.in
> base/lib.mak
> base/spwgd.c
> base/spwgx.h
> base/unix-gcc.mak
> lib/viewpwg.ps
> psi/int.mak
> psi/msvc.mak
> psi/zfilter.c
> windows/ghostscript.vcproj

2017-12-12 17:57:05 +0000
Robin Watts <robin.watts@artifex.com>
0bdb35346b5a9636bc6c1ca629401ba21232d9bb

> Bug 698808: Fix stack overflow in new scan converter.
> Remove some code to split lines. This is no longer needed
> due to the fix for bug 698805, and avoids us getting into the
> stack overflow situation.
> base/gxscanc.c

2017-12-12 01:37:14 -0800
Michael Vrhel <michael.vrhel@artifex.com>
2eb66278cb71b4f97b09300d7c405b8228ebeaf6

> Segv fix for XPS files with trans out to sep device
> When going out to a separation device, PCL and XPS should set
> PageSpotColors to 0. For PCL this lets the sep device know
> that there are not any spot colors on the page.
> For XPS the situation is a bit more complex. XPS files with named colors
> are very rare. I have never seen one in the wild. Supporting
> the separation of them will require work in the XPS interpreter
> to keep track of the colorants (the names of which are in the colorant
> tags of the ICC profile) and make sure that the values are properly
> mapped to the colorant positions on the output device. We will also
> want to do a pre-parser to count the number of independent colorants
> on the page to ensure proper set up of the device. This is needed
> especially if the page has transparency as the pdf14 device expects to
> have this information. Again running into them in the wild is not going to
> occur. If for some reason it does become an issue in the future,
> we can invest the time in doing the above. In the meantime if they
> are encountered they will be remapped to equivalent CMYK colors instead
> of causing a segv.
> pcl/pl/plmain.c

2017-12-12 18:31:00 +0000
Robin Watts <robin.watts@artifex.com>
ac1fb2a0580fac884cbf8e07aba4834498a5927a

> Fix typo in bug fix for 698805.
> base/gxscanc.c

2017-12-12 09:19:41 +0000
Chris Liddell <chris.liddell@artifex.com>
0aa901ed39ae5c2a8fbf1107dbbd7d3813cab2ee

> Check for gdevcups.c before including the cups device
> Previously, we were checking for the cups directory, which won't work reliably
> if the build machine also has the cups libraries installed.
> configure.ac

2017-12-12 16:58:00 +0000
Robin Watts <robin.watts@artifex.com>
ed2c6957a2ed53aac51e0b7d4209e62f096b8d73

> Bug 698805: Fix NULL pointer dereference in new scan converter.
> Again caused by an integer overflow.
> signed sy, ey can differ by more than 0x80000000, which means
> when we subtract them, we can end up with a result with a different
> sign.
> Fix by using a safer test.
> base/gxscanc.c

2017-12-01 14:43:43 -0800
Ray Johnston <ray.johnston@artifex.com>
ac241e31c931858e562dc0a4cd88db31e012c2cf

> Fix bug 698662. Elements shifted horizontally when clist is used.
> The scurveto clist path reading logic assumed that if the first value
> A, was 0, the previous curve entry was vertical, but the writing logic
> checked for B == 0 and decided to use h*curveto, so if A was also 0,
> the reading logic would assume vertical.
> base/gxclpath.c

2017-12-08 13:43:36 -0800
Michael Vrhel <michael.vrhel@artifex.com>
43a84c5d99d14881773b78b58892e9b049b938d9

> Bug 698794 detect alpha data in PNG image
> We were making the decision as to the presence/absence of
> the alpha data in the PNG image a little early. There
> was one more step related to png_set_tRNS_to_alpha
> xps/xpspng.c

2017-11-30 18:41:42 -0500
Robin Watts <Robin.Watts@artifex.com>
4ee9656472805dc39a6ed3a8bd097dd04e497c19

> Fix PCL init routines to return error code.
> And fix calling loop to honour error code. Interestingly
> this calling routine was already set up to do most of the
> hard work here. I wonder if this was once done already?
> pcl/pcl/pccolor.c
> pcl/pcl/pccprint.c
> pcl/pcl/pcfont.c
> pcl/pcl/pcfrgrnd.c
> pcl/pcl/pcjob.c
> pcl/pcl/pcmacros.c
> pcl/pcl/pcmisc.c
> pcl/pcl/pcommand.c
> pcl/pcl/pcommand.h
> pcl/pcl/pcpage.c
> pcl/pcl/pcpalet.c
> pcl/pcl/pcparse.c
> pcl/pcl/pcparse.h
> pcl/pcl/pcpatrn.c
> pcl/pcl/pcrect.c
> pcl/pcl/pcsfont.c
> pcl/pcl/pcstatus.c
> pcl/pcl/pcsymbol.c
> pcl/pcl/pctext.c
> pcl/pcl/pcuptrn.c
> pcl/pcl/pcursor.c
> pcl/pcl/pgchar.c
> pcl/pcl/pginit.c
> pcl/pcl/pginit.h
> pcl/pcl/rtgmode.c
> pcl/pcl/rtmisc.c
> pcl/pcl/rtraster.c

2017-12-05 13:31:25 +0000
Ken Sharp <ken.sharp@artifex.com>
5c851a410c3469860a171420240eb92331dcda9e

> pdfwrite - colour conversion changes
> Bug #698723 "convert rgb pdf to cmyk with icc profile yields wrong black"
> When converting to a base space colour, and applying the transfer
> function, don't use the old-fashioned colour conversion routines but
> instead use the ICC profile colour management.
> With this change in place, the CMYK components in the output file are
> the same as those when rendering to TIFF CMYK output.
> I am convinced there is more work to do in this area.
> devices/vector/gdevpdfg.c

2017-12-05 13:27:27 +0000
Ken Sharp <ken.sharp@artifex.com>
775e9d28f78b4b0b5b41a24f4c9fc7f19a9326e3

> pdfwrite - correct a device method
> Correct the CMYK colour mapping method to use CMYK and not RGB....
> devices/vector/gdevpdf.c

2017-12-01 17:05:07 -0500
Robin Watts <Robin.Watts@artifex.com>
6edda68e00965c0794fdd408cbc02c1729c374ff

> Rejig gs_fapi_ft_ensure_open to avoid error cleanup SEGV.
> Also, aesthetics.
> base/fapi_ft.c

2017-12-01 14:06:12 -0500
Robin Watts <Robin.Watts@artifex.com>
3d6009573b3562d97f03c0fb6b1463ed0e4d133f

> Memory squeezing fix in pl_load_tt_font.
> Fix SEGVs due to memory failures while loading a tt font.
> Error created using :-
> MEMENTO_FAILAT=1402 ./membin/gpcl6 -sDEVICE=ppmraw -o /dev/null
> ./pcl/examples/owl.pcl
> Tweaked version of a commit from Shelley.
> pcl/pl/plfont.c

2017-11-30 18:40:42 -0500
Robin Watts <Robin.Watts@artifex.com>
cc5b750951ee94b2d7e0615dde0122af973f49bb

> Memento: Fix type of signal handler function.
> base/memento.c

2017-12-02 13:11:42 +0000
Ken Sharp <ken.sharp@artifex.com>
7d9b9cc6ff0fafed282257fd1bf1ba815726a50e

> PDF interpreter - another case of incorrect ICCBased profiles
> More cases like those tackled in commit
> df5b3426d31f79c13a735dff9118e9798ce97af9 for bugs #696690 and 696120
> Again we have an ICCBased colour space where the /N alue does not match
> the actual number of components in the ICC profile. Previously we had
> only seen this with images, the customer file uses a 'cs' operator
> which we weren't catching.
> No differences expected.
> Resource/Init/pdf_ops.ps

2017-11-16 16:41:22 +0100
David Kaspar [Dee'Kej] <dkaspar@redhat.com>
615b31526d06fcdac7abb9e37deac3ce5fb214b6

> man/de - all man pages converted to UTF-8 (from ISO-8859-1)
> man/de/dvipdf.1
> man/de/gsnd.1
> man/de/pdf2ps.1
> man/de/printafm.1
> man/de/ps2ascii.1
> man/de/ps2ps.1

2017-12-01 15:16:19 +0000
Chris Liddell <chris.liddell@artifex.com>
69f4ea2d9d86b9eccf5e3477e4dc9d7d51e1d2d8

> Remove obsolete check_source.py tool....
> and its configuration file (testing.cfg.example).
> Bug 698780 (related)
> toolbin/tests/check_source.py
> toolbin/tests/testing.cfg.example

2017-11-27 10:30:52 +0100
David Kaspar [Dee'Kej] <dkaspar@redhat.com>
efc24229b0ba4b2f6a39fe89a4c9c576dbe7e124

> Bug 698784: Fix the alias for Helvetica-Narrow-Bold-Oblique
> Init/Fontmap.GS:
> There was a misalignment between the filename of the
> NimbusSansNarrow-BdOblique and its /Fontname in the T1 font itself.
> Filename: NimbusSansNarrow-BdOblique
> /Fontname: /NimbusSansNarrow-BoldOblique
> This worked correctly if the fonts were located directly in
> /usr/share/ghostcript/Resources/Font folder on the filesystem.
> However, on Fedora we are using /usr/share/fonts/urw-base35/ folder,
> which is part of Ghostscript's Search Path. In this case it was
> causing the Ghostscript being unable to locate the correct font, thus
> crashing while opening any document containing Helvetica Narrow Bold
> Oblique font...
> *In addition*, rename the font file so it matches.
> Resource/Font/NimbusSansNarrow-BoldOblique
> Resource/Init/Fontmap.GS
> psi/psromfs.mak

2017-12-01 13:54:02 +0000
Chris Liddell <chris.liddell@artifex.com>
8d0ca41749ec3070c6a5c660ab0225b42bcb9eb3

> Bug 698741: where the comment says "decrement", actually decrement
> The comment stated we'd move to the end of the row, and work backwards, but
> the code was still working forwards, leading to a buffer overrun.
> base/gxicolor.c

2017-11-24 22:26:59 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
caa10a82fcf313dab7426250f59517936fa34964

> Bug 697545 : Memory squeezing fix for double freeing of ToneCurve.
> Avoid SEGV by removing unnecessary freeing of ToneCurve.
> Error created using :-
> MEMENTO_FAILAT=751 ./membin/gpcl6 -sDEVICE=ppmraw -o /dev/null ./pcl/examples/owl.pcl
> lcms2/src/cmsio1.c

2017-11-25 19:08:28 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
346f1d67dc363195885dd041ede2abb0422c4455

> Bug 697545 : Memory squeezing fix for gs_enumerate_files_next.
> Prevent SEGV by checking for NULL pointer before attempting to
> use it.
> base/gsiodev.c

2017-11-24 19:27:50 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
d2977a7891f5c84526eefdd25b2167e052fa9c90

> Bug 697545 : Memory squeezing fix for pjl resources.
> Prevent SEGV by checking for NULL pointer before attempting to
> free it.
> pcl/pl/pjparse.c

2017-11-24 15:45:16 +0000
Robin Watts <robin.watts@artifex.com>
96030033df28fb89732f58ae4df463f7fc06be5b

> Add '-DCLUSTER' mechanism to builds.
> For autobuild use --enable-cluster option to configure/autogen.sh.
> For windows builds, use CLUSTER=1.
> This nobbles pdfwrite to use a '0' time in the produced files.
> This enables us to md5sum intermediate files.
> Thanks to Chris for his help with the configure minefield.
> Makefile.in
> configure.ac
> devices/vector/gdevpdf.c
> psi/msvc.mak

2017-11-24 19:06:41 +0000
Robin Watts <robin.watts@artifex.com>
949ce4cf61f2ccf1ff39dd2c854aec9f9dad5068

> Tiny stylistic tweak.
> pcl/pl/plmain.c

2017-11-24 19:06:26 +0000
Robin Watts <robin.watts@artifex.com>
33babeb40a9e73e0cfb1d3b30574e305fa6ee7c7

> Squash warning.
> pcl/pl/plmain.h

2017-11-23 22:21:15 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
8b82d6f99ffda116b328e3ae65c58ee5e056e490

> Bug 697545 : Memory squeezing fix for mutex in cms code
> Prevent SEGV by checking for NULL mutex pointer before attempting
> to use or destroy it.
> lcms2/src/cmserr.c

2017-11-23 22:17:55 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
a46d319b6edc2bc07b14fbf155b5101bf884fe27

> Bug 697545 : Memory squeezing fix in pl_main_delete_instance
> Prevent SEGV by checking for NULL value before dereferencing.
> pcl/pl/plmain.c

2017-11-23 17:00:06 +0000
Ken Sharp <ken.sharp@artifex.com>
adfedfa4de0457ecacf5814d4a315fcaee00561d

> OpenType fonts - regard fonts with multiple GSUB tables as invalid
> Bug #697627 "IO in gs_notify_all function"
> The bug title is a misnomer; the actual problem is that we have a badly
> corrupted font which appears to have 2 GSUB tables. This causes us to
> allocate two chunks of memory to hold the tables, losing the original
> reference when we allocate the second, and also to register the font
> to have the GSUB table released twice.
> Trying to release the same memory twice leads to us trying to access
> invalid memory, and therefore to a seg fault.
> So if we find we have a GSUB, and we've already allocated memory for a
> GSUB table, just throw an error.
> Chris thinks it may be possible to legally have multiple GSUB tables, if
> we ever find such a thing we'll have to rethink this.
> base/gstype42.c

2017-11-23 09:40:36 +0000
Chris Liddell <chris.liddell@artifex.com>
3ad236df1e509d0326a1fa31c98e068b5712fd75

> Bug 698773: Cope with "charstring" of invalid type
> This file has a font whose CharStrings dictionary contains:
> /space 3 def
> Ideally, when we hit such a case, we should fallback to the .notdef glyph,
> unfortunately, it also has:
> /.notdef 0 def
> We *should* throw an error since this is clearly totally invalid, but other
> interpreters *appear* to simply ignore the problem. So, we opt to return an
> empty charstring.
> psi/zfapi.c

2017-11-23 13:32:26 +0000
Ken Sharp <ken.sharp@artifex.com>
f32c03a2daad2d2e0e859bd6fc7547b68bd8bed9

> Do not ignore errors from the device's fill_rectangle_hl_color method
> Spotted by Robin while fixing indeterminisms, we currently ignore any
> error return from this method in pattern_accum_fill_rectangle_hl_color()
> when it calls its target device. Adding a check and error propagation is
> simple enough, but that then reveals problems with the high level
> devices.
> There are, in fact, several problems here. Firstly, the mem* devices
> which are used to render pattern tiles (amongst other things) are
> based on forwarding devices. When we send a spec_op we forward this to
> the 'underlying' device. This is a problem if the spec_op is querying
> whether the device can handle hl_color, because if it can then the
> caller may proceed to use hl_color methods. But the mem* devices cannot
> handle these methods and obviously can't forward them to the underlying
> device, resulting in an error. Fixed this one by using the default
> spec_op method instead of the forwarding one. In future this may require
> further attention.
> The NULL device doesn't implement fill_rectangle_hl_color. In fact, with
> the changes elsewhere it doesn't need to, but really we should simply
> handle this in the same way as fill_rectangle and return, all the null
> device does is bit bucket all operations. For completeness, implement
> such a method.
> gx_erase_colored_pattern() didn't do a restore (to match its save) if
> an error occurred. Again, with the other changes this is no longer
> triggered, but it does seem wrong so lets fix it.
> In gx_pattern_load() and pattern_paint_prepare(), avoid erasing the
> background of the tile if the pattern instance is for a device which
> handles patterns itself (eg pdfwrite). Once again, not really required
> now that the mem* devices don't pass on the spec_op to the underlying
> device, but it saves us bothering with erasing a rectangle which we are
> going to throw away anyway.
> Finally, the point of the whole exercise, in
> pattern_accum_fill_rectangle_hl_color(), check the return code from the
> target device's fill_rectangle_hl_color and if its an error, return it.
> base/gdevmem.c
> base/gdevnfwd.c
> base/gxpcmap.c
> psi/zpcolor.c

2017-11-22 21:29:04 +0000
Robin Watts <robin.watts@artifex.com>
1cfc56251773304fb102237ff8a63c5576f08fe7

> Rewritten version of squeeze2html.pl
> This works with the latest memento, and gives nicer results in
> the browser.
> Invoke using something like:
> MEMENTO_SQUEEZEAT=1 membin/gs -sDEVICE=ppmraw -o /dev/null
> in.pdf |& perl toolbin/squeeze2html.pl -q | gzip -9c > out.html.gz
> toolbin/squeeze2html.pl

2017-11-22 17:57:23 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
276a386da36926cf36942528146b4294a5ff9d6d

> Coverity IDs 127198, 127199
> Check return values and handle errors accordingly.
> pcl/pcl/pctext.c

2017-11-22 18:02:26 +0000
Robin Watts <robin.watts@artifex.com>
dd35e58feccf543129bc108857b16fd43d627d02

> Fix indeterminism caused by buffer overrun in thresholding.
> Running:
> gs -sOutputFile=out%d.pbm -dMaxBitmap=400000000 -sDEVICE=pbmraw -r300
> -sDEFAULTPAPERSIZE=letter -dNOPAUSE -dBATCH -K2000000 -dClusterJob
> -dJOBSERVER /home/marcos/cluster/tests_private/pdf/uploads/Bug698519.pdf
> then catting out{1,2,3,4,5}.pbm together and md5summing it gives a
> different result to running the above job direct to out.pbm.
> After much nightmarish debugging, it transpires that this is because
> the special case in the SSE thresholding code that spots the 200%
> scale case is being triggered incorrectly.
> The image is 1753 pixels wide, which would be 3506 pixels at 200%.
> We actually display it at 3507 pixels. The code was triggering the
> 200% case by calculating a scale_factor value of fixed_half (128).
> The rounding here was causing a false positive.
> Instead, we skip the calculation and check by directly comparing
> source and dest sizes.
> base/gxicolor.c
> base/gximono.c

2017-11-21 12:48:54 -0800
Ray Johnston <ray.johnston@artifex.com>
362ec9daadb9992b0def3520cd1dc6fa52edd1c4

> Fix bug 697459 Buffer overflow in fill_threshold_buffer
> There was an overflow check for ht_buffer size, but none for the larger
> threshold_buffer. Note that this file didn't fail on Windows because the
> combination of the ht_buffer and the size of the (miscalculated due to
> overflow) threshold_buffer would have exceeded the 2Gb limit.
> base/gxht_thresh.c
> base/gxipixel.c

2017-11-21 19:27:19 +0000
Robin Watts <robin.watts@artifex.com>
68fa913b5bc06a4250115f52835cadc5493aab12

> Avoid warning.
> base/gdevp14.c

2017-11-21 19:24:04 +0000
Robin Watts <robin.watts@artifex.com>
853737363b7b7cd1eab4da68ba8f83b7dfb5f453

> clist tweak: Pass &var to macros if the value of var is updated.
> Otherwise it's hard for someone unfamiliar with the macros to see
> what is going on.
> base/gxclbits.c
> base/gxcldev.h
> base/gxclimag.c
> base/gxclpath.c
> base/gxclrect.c
> base/gxclutil.c

2017-11-21 17:40:53 +0000
Robin Watts <robin.watts@artifex.com>
ce5c3f42d8bd062da65d592abdaaeea90b901970

> Ensure that single component planar devices can cope with hl_color.
> As part of tracking down indeterminisms in the cluster, I found that:
> gs -sBandListStorage=file -sOutputFile=out%d.psd -dMaxBitmap=10000
> -sDEVICE=psdcmyk -r300 -Z: -sDEFAULTPAPERSIZE=letter -dNOPAUSE
> -dBATCH -K2000000 -dClusterJob -dJOBSERVER -ZL
> tests_private/pdf/sumatra/586_-_missing_images_gs_SMask_not_applied.pdf
> was hitting a case where we were writing a pattern tile into the
> clist that hadn't been initialised at all. This was because all
> the writes to the pattern accumulator went through
> pattern_accum_fill_rectangle_hl_color. This passes the hl_color
> data to the memory devices fill_rectangle_hl_color function, and
> fills the mask with 1s.
> The mask was being entirely filled with 1s and so was being discarded
> as unnecessary. Unfortunately the devices fill_rectangle_hl_color
> entrypoint was left as the default which does nothing by raise an
> error.
> The fix here is to ensure that when we open a planar device, we
> always add in a suitable fill_rectangle_hl_color function, even
> when the device is superficially the same as a chunky one.
> Thanks are due to Michael and Ray for their help with tracking this
> down.
> base/gdevmpla.c

2017-11-21 16:46:18 +0000
Ken Sharp <ken.sharp@artifex.com>
19ebb5f1f497b6f2d50fe13d17d3e627dfb6c868

> PS interpreter - restore the flushpage operator
> Michael Katzmann, working at the Library of Congress, is using
> Ghostscript in a custom application, which also involves a barcode
> reader and an SQL database.
> Currently this resides in an RPM at:
> http://engineering.nlsbph.org/repo/fedora/fedora/updates/27/SRPMS/AddressCard-3.17-LoC.fc27.src.rpm
> but its not usable without the barcode reader and SQL database....
> For reasons which are not completely clear to me, he wants to use
> flushpage to update the display part way through the operation.
> We suspect that it would be possible to avoid this, but it would
> probably require some programming effort on the users part, and since
> flushpage doesn't look like a likely candidate for abuse, we've decided
> just to restore it.
> Resource/Init/gs_init.ps

2017-11-21 14:13:21 +0000
Ken Sharp <ken.sharp@artifex.com>
37a9d25214efcabe0f36ed4cf6e91c58fcdbfa2d

> PDF interpreter - move a default value to be compatible with all xref types
> The commit df5b3426d31f79c13a735dff9118e9798ce97af9 which works around
> PDF files where the /N value and the actual ICC profile colour space
> number of components do not match.
> Unfortunately, I made a minor error when creating this, which wasn't
> exposed by the test files on hand at the time. I set the default value
> of ICCProfileNError to false when processing an xref of type 'orig'
> (ie not an xref stream) which means that for PDF files which use xref
> streams the value was not defined, leading to an error.
> Move the initial declaration to pdfopenfile instead so that it works
> no matter what type of xref we have,.
> Resource/Init/pdf_main.ps

2017-11-05 16:16:46 -0800
Ray Johnston <ray.johnston@artifex.com>
1d7893955cf4231c092045affc32e26ad2b6de32

> Fix bug 696845 SEGV with --saved-pages-test and transparency
> When a file pushes a pdf14devicefilter (or other compositor) it will
> still be the currentdevice after the filter is popped when the saved
> pages printing occurs. We need to check if the device is a forwarding
> device (as compositors will be when deactivated) and use the target
> device to print the saved pages.
> Also, if a device uses the gx_default_dev_spec_op, it will return 0
> from the supports_saved_pages call even when it is a printer device.
> In gdev_prn_forwarding_dev_spec_op, check for a zero return and return
> true (1). A device that is a printer device that doesn't support saved
> page printing needs to return < 0 to prevent this.
> Add a finalize method for gx_device_printer so we can free up the saved-
> pages-list when the device is freed, but not when the device is closed
> which can happen if it needs to close due to put_params. Also the
> return code from the output_page in gx_saved_page_params_process was
> ignored. Both seen with the file Bug687111.ps and the psdcmyk device.
> Also for devn devices, such as psdcmyk, we need to save the separation
> (spot color) names collected during the execution of setcolorspace in
> the gx_saved_page and set them in the devn_params when rendering. These
> are not handled by the paramlist.
> Disable --saved-pages= and --saved-pages-test with PCL and XPS since it
> was never completely implemented and the partial implementation causes
> many errors when tested with --saved-pages-test. Note that while the
> --saved-pages-test option is still accepted as a parameter, it is ignored
> so that regression testing with --saved-pages-test can run.
> Regression shows 3343 "diffs", but bmpcmp doesn't show any diffs.
> base/gdevp14.c
> base/gdevprn.c
> base/gdevprn.h
> base/gxclist.h
> base/gxclpage.c
> base/lib.mak
> examples/transparency_example.ps
> pcl/pl/plmain.c
> psi/imain.c
> psi/imainarg.c

2017-11-20 14:33:03 +0000
Robin Watts <robin.watts@artifex.com>
1b64014143a8a571e5dbff3346c6ad902603dda1

> Fix release/debug difference.
> In searching for the indeterminism in 11-14.PS, I found that I could
> run the same command line in release and debug builds on peeved, and
> get different results:
> touch out1.pgm ref1.pgm && rm out*.pgm ref*.pgm &&
> bin/gs -sOutputFile=ref%d.pgm -dMaxBitmap=10000 -sDEVICE=pgmraw -r300
> -Z: -sDEFAULTPAPERSIZE=letter -dNOPAUSE -dBATCH -K2000000 -dClusterJob
> -dJOBSERVER %rom%Resource/Init/gs_cet.ps cutdown >& ~/log &&
> debugbin/gs -sOutputFile=out%d.pgm -dMaxBitmap=10000 -sDEVICE=pgmraw
> -r300 -Z: -sDEFAULTPAPERSIZE=letter -dNOPAUSE -dBATCH -K2000000
> -dClusterJob -dJOBSERVER %rom%Resource/Init/gs_cet.ps cutdown
> >& ~/log2 && md5sum ref*.pgm out*.pgm && less ~/log ~/log2
> After cutting down the file as much as I could, Chris reduced it
> simply to:
> 3E9 3E9 moveto 1 1 lineto stroke showpage
> Thanks for this!
> Tracing through the code, I discovered that the difference came down
> to check_diff_overflow, where the release build was assuming that if
> v1 > v0, v0 - v1 < 0, which is acceptable because v0 - v1 has
> overflown, at which point C says the value is unpredictable.
> The fix is to detect the overflow before it happens.
> base/gxpflat.c

2017-11-20 13:51:16 +0000
Ken Sharp <ken.sharp@artifex.com>
cea5d8a72dab953fe84ab8f7280003d377559fff

> pdfwrite - Fix typo in on=-page checks for annotations with PDF/X
> Bug #698765 "PDF/X Compliance Check Fails with Ghostscript generated PDF"
> The upper-right y bound check was incorrect, leading to an incorrect
> decision that an annotation was off the page.
> devices/vector/gdevpdfm.c

2017-11-20 09:51:27 +0000
Ken Sharp <ken.sharp@artifex.com>
f9d41654ff0f52b6f42e5eff3215cf183261cffa

> Coverity ID 203245 - remove redundant NULL check
> The changes which fixed the device method API mean that its no longer
> required to check that dev is not NULL in this routine.
> base/gdevsclass.c

2017-11-17 15:42:17 +0000
Robin Watts <Robin.Watts@artifex.com>
7b04e4d7b85769169db94f1b0ed72474211ba27a

> Add another PACIFY_VALGRIND section
> Avoid warnings in 586_-_missing_images_gs_SMask_not_applied.pdf
> base/gxclist.c

2017-11-17 15:26:10 +0000
Ken Sharp <ken.sharp@artifex.com>
c5f770b5c64cf7a2f3a0f3c447c089a089a695d1

> Documentation - Restore the documentation on DELAYBIND and friends
> Since we've reinstated DELAYBIND, reinstate the documentation to go
> with it. Also include the helpers .bind and .bindnow.
> doc/Language.htm
> doc/Use.htm

2017-11-16 20:37:41 +0000
Robin Watts <Robin.Watts@artifex.com>
d9c9bea4ecf31e06bcf52d433b632ce0b6b1b239

> Fix buffer overrun in gp_enumerate_files_next.
> If pattern="*" and patlength = 1, then pathead = 1.
> When we look for any following subdirectory, the code attempts
> to look for the next subdirectory name. To do this it starts
> searching from the byte after the position of the current '/'.
> Unfortunately, if the string ends at the current wildcard, we
> don't have a '/', we have a NUL terminator. This means the
> current code starts looking just after that.
> In code terms this means the current code accesses at
> pattern + pathead + 1, without checking pattern[patthead] first.
> This is a simple fix.
> We also take this opportunity to simplify a couple of while loop
> conditions. The extra negation is too much for my tiny brain to
> cope with.
> base/gp_unifs.c

2017-11-16 20:01:57 +0000
Robin Watts <Robin.Watts@artifex.com>
f27b751a1662c3ca8ef64c164cf3f9a400dd416b

> Add SINGLE_OBJECT_MEMORY_BLOCKS_ONLY logic.
> If SINGLE_OBJECT_MEMORY_BLOCKS_ONLY is defined at
> build time, then we restrict every clump/chunk to
> have just a single object in it. This makes
> valgrind debugging easier as the allocation given
> for when 'undefined' values were created is far
> more likely to be correct.
> base/gsalloc.c
> base/gsmchunk.c

2017-11-16 20:00:01 +0000
Robin Watts <Robin.Watts@artifex.com>
1e1b4dc73087212abd1c6c9bee3192a1fc6bf630

> Add some PACIFY_VALGRIND to quash some warnings.
> 11-14.PS trips some valgrind warnings where we
> write structures into the clist without having
> cleared the padding in the structures.
> base/gsptype1.c
> base/gxclimag.c
> base/gxclist.c
> base/gxpcmap.c

2017-11-16 21:51:13 +0000
Ken Sharp <ken.sharp@artifex.com>
e93a58466a78aab89e065bdae2d6b77db5620692

> pdfwrite - fix instance UUID
> Bug #698757 "Instance UUID truncated"
> Should have spotted and fixed this at the same time as Bug #697977
> but missed it. As noted in the bug report its practically the same code
> and had the exact same problem.
> devices/vector/gdevpdfe.c

2017-11-16 13:38:59 +0000
Ken Sharp <ken.sharp@artifex.com>
b76dc2d704fcc00edc8c1fd8ae19d01a36e22c49

> ps2write - fix string splitting for output formatting
> Bug #698708 "Ghostscript loops"
> When writing output for ps2write, we limit the output width to 255
> characters. If a string is longer than that we try to split it on
> PostScript tokens. If we can't do that then we just break at 255
> characters and stick in a newline.
> The logic in here however was flawed however, it failed to update the
> pointer 'p' which points to the character currently being processed
> and did not reset the width count to 0 when the string was output.
> This could lead to us in an infinite loop.
> devices/vector/gdevpdfu.c

2017-11-16 11:29:47 +0000
Ken Sharp <ken.sharp@artifex.com>
01ce294445f7988f51f63108d53a89df003f2b1e

> Fix tiffsep1 device after device API repair
> commit dd820be was over-enthusiastic with the tiffsep1 device, and tried
> to use the device procs accessor on a device struct member other than
> 'procs' with predictably unfortunate effects.
> devices/gdevtsep.c

2017-11-16 10:28:28 +0000
Ken Sharp <ken.sharp@artifex.com>
fa499a5809aab45b2891b5c8b2363d1bca890757

> PS interpreter - add warnings for DELAYBIND and WRITESYSTEMDICT
> We've seen people using these options in an inappropriate fashion
> and with SAFER set as well. Clearly there is confusion about how to use
> these.
> If the user selects SAFER, and selects an option which is liable to
> make it possible for PostScript to evade the SAFER file system access
> restrictions, then emit a warning reminding the user to 'lock' the
> unsafe option down.
> Also restore the old behaviour of DELAYBIND and remove the
> REALLYDELAYBIND switch. We have heard from the 'pstoedit' maintainer
> and that tool requires the use of both DELAYBIND and WRIESYSTEMDICT.
> Resource/Init/gs_init.ps

2017-11-15 16:49:41 +0000
Ken Sharp <ken.sharp@artifex.com>
dd820bbe7f53e051add94dbcdc779dae1820e0d6

> Device method repair - use accessors throughout
> A lot of places accessed device methods directly, instead of using the
> accessor macros. Update all the code to use the accessors.
> base/gdevdflt.c
> base/gdevmpla.c
> base/gdevnfwd.c
> base/gdevp14.c
> base/gdevprn.c
> base/gdevsclass.c
> base/gdevvec.c
> base/gsdevice.c
> base/gsdparam.c
> base/gsicc_manage.c
> base/gxclist.c
> base/gxclrect.c
> base/gxcmap.c
> base/gxdevice.h
> base/gxfapi.c
> base/gxfill.c
> base/gxp1fill.c
> base/gxpcmap.c
> devices/gdevdsp.c
> devices/gdevplib.c
> devices/gdevtifs.c
> devices/gdevtsep.c
> devices/gdevwpr2.c

2017-11-12 11:10:49 +0000
Ken Sharp <ken.sharp@artifex.com>
c9951359bde5c4e72a20624788a47a97872db090

> Repair the device API - device methods should never be NULL
> The original intention of the device API was that device methods (with
> the odd exception of fill_rectangle) must not be NULL. That appears
> to have been broken with the introduction of the transparency
> compositor, with the result that the code now:
> 1) has to check for methods being NULL sometimes, because that causes
> crashes.
> 2) Uses a device method being NULL to determine code paths.
> We want to return the device method design, because having to check for
> NULL methods before calling is wasteful.
> In this commit:
> define default methods for all the methods that previously did not have
> one.
> Modify gx_device_fill_in_procs to include those defaults in the device
> methods which it checks for NULL and replaces.
> Finding all the places where the code path differs if a device method
> is NULL, alter to check against the default method instead.
> Remove NULL checks where they are no longer required. Device whose
> 'procs' get copied directly (clist) must have defaults for all methods.
> Fix gx_copy_device_procs so that we only special case (don't replace
> the method) for those few methods where it matters that the subclassing
> device must have the default method if the subclassed device does. Long
> term we should change the code not to rely on this!
> Remove a couple of macros that were not required or plain dumb.
> base/gdevdflt.c
> base/gdevmem.c
> base/gdevnfwd.c
> base/gdevp14.c
> base/gdevprn.c
> base/gdevsclass.c
> base/gdevvec.c
> base/gscspace.c
> base/gsdevice.c
> base/gsdparam.c
> base/gsicc_manage.c
> base/gsovrc.c
> base/gspaint.c
> base/gstrans.c
> base/gxblend1.c
> base/gxclist.c
> base/gxclrect.c
> base/gxdevice.h
> base/gxfapi.c
> base/gxiscale.c
> base/gxp1fill.c

2017-11-14 20:27:07 +0000
Robin Watts <robin.watts@artifex.com>
e2565e030eb37a25459671cfa9119715f3a0aae4

> New "planr" device. 1 bit per component, RGB, planar device.
> base/gdevmem.c
> base/unix-gcc.mak
> devices/devs.mak
> devices/gdevplan.c
> psi/msvc.mak

2017-11-15 19:17:05 +0000
Robin Watts <robin.watts@artifex.com>
a8b1611e7613781cd5c2c7defa2c5315254d9d1d

> Fix operation of 1bpc, 3 component halftones.
> In the chunky world, it makes no sense to deal with 3 bit rgb as
> this doesn't pack neatly into a byte. You'd do it by handling
> 4 bit chunks.
> Accordingly, parts of Ghostscript are written to assume that you'd
> not do anything this crazy.
> Unfortunately, in the planar world, a 1 bpc, 3 component device
> does make (some) sense. Sadly, stuff like the halftone generation
> gets deeply confused by this.
> Here we fix 2 specific instances of this problem. In the halftone
> generation, we generate 3bit chunky halftones as 4 bit ones, and in
> the planar_copy_color routines, we assume that 3 bit data is
> actually 4 bit (as a) it probably comes from these routines, and
> b) if it doesn't it'd be packed as 4 bit in any sane world).
> base/gdevmpla.c
> base/gxcht.c

2017-11-15 17:08:58 +0000
Robin Watts <robin.watts@artifex.com>
fac14b8c25422529acded1e9e920eb20190db340

> clusterpush.pl: Add smoke option
> toolbin/localcluster/clusterpush.pl

2017-11-15 17:26:35 +0000
Robin Watts <robin.watts@artifex.com>
ae6f20152ab1e0860952dbeee979ef2c0f195269

> Fix st_device_vector_max_ptrs.
> This should be +4, not +3, but this value appears to be pretty
> much unused, so nothing matters at the moment. It is used by
> st_device_psdf_max_ptrs, but nothing uses that either.
> We may remove both of these definitions in future.
> base/gdevvec.h

2017-11-15 17:12:09 +0000
Robin Watts <robin.watts@artifex.com>
bb5726a74bbfbbd2e17b344eb4bc0385d514d4c1

> Memento: Add Memento_sequence
> base/memento.c
> base/memento.h

2017-11-15 09:03:27 +0000
Ken Sharp <ken.sharp@artifex.com>
d046e24bd2894cf80785bede733006dd53746a07

> PostScript interpreter - silence compiler warning
> Prototype a function to silence a compiler warning. Also, make the
> function static since it isn't used elsewhere.
> psi/zarith.c

2017-11-13 11:05:04 +0000
Robin Watts <robin.watts@artifex.com>
143a892226b79676f5f8853f63532f9e6f4e8f5e

> Avoid buffer overflow in GraphicsAlphaBits cdoe with planar device.
> In GraphicsAlphaBits, we get the pixels from the underlying device
> (in chunky format). The buffer we get that data into was sized
> according to get_device_raster(dev, false), which (for a planar
> device) returns the size for line of planar data. We want the
> size for one line of chunky data, so use get_device_raster_chunky
> instead.
> base/gdevdbit.c

2017-11-13 09:07:03 +0000
Ken Sharp <ken.sharp@artifex.com>
5fe97ce30de048027da19a85bc574a8adfcf2116

> pdfwrite - fix an error handling problem
> Bug 698735 "Ghostscript: SEGV in pdfwrite with -Z@"
> This was, unfortunately, caused by the shift to cleaning up memory
> instead of relying on the garbage collector.
> When an error occurred writing the metadata, the code simply exited
> back to the caller, it did not close the temporary stream it was
> writing the metadata to.
> Due to the way that 'asides' are handled this led to the wrong stream
> being closed, and a pointer retained to a closed stream. The result
> was the seg fault.
> There may well be other conditions like this still present.
> devices/vector/gdevpdfe.c

2017-11-11 19:28:10 +0000
Chris Liddell <chris.liddell@artifex.com>
db2415d2b117946e5ec1d46936a134940f99c21d

> Bug 698733: make vector device memory stable
> The pcl/xl device (gdevpx.c) was using "normal" Postscript global memory for
> its own use, and the vector base device on which it is based. That means the
> memory it allocated could disappear with the end-of-job restore in the
> Postscript interpreter.
> Change it so it uses stable memory which is still garbage collected, and still
> subject to relocation, but is *not* subject to Postscript save/restore
> operation.
> devices/vector/gdevpx.c

2017-11-03 08:52:50 -0700
Ray Johnston <ray.johnston@artifex.com>
c535ebb24602ff14a375a1590a9df6bd8bb7e9c4

> Fix bug 695877: SEGV when display callback not set.
> Change most of the device procs to return gs_error_Fatal when the callback
> hasn't been set. The open is allowed to be called before it is set, but any
> operations other than fill_rect (allowed for due to fillpage) and close will
> now return Fatal errors. This allows the device to be "fake opened" by gs_init
> before the parameters are processed and the display callback is set and the
> device is opened for actual use.
> devices/gdevdsp.c

2017-11-08 14:04:42 +0000
Ken Sharp <ken.sharp@artifex.com>
ea81364fdda57ce2c82007a150add5949a1c5788

> PS interpreter - fix detection of overflow on 64-bit integer multiply
> Bug 698722 "Erroneous Range-Check causes wrong arithmetic results"
> The work here was actually done by Robin Watts, ably assisted by
> Paul Gardiner.
> The previous code failed to properly detect an overflow condition,
> because the cast of MAX_PS_INT to a double reduces the precision to
> only 52 bits for the integer portion, meaning it was possible for
> very large numbers not to be detected as > MAX_PS_INT.
> psi/zarith.c

2017-11-08 10:04:03 +0000
Ken Sharp <ken.sharp@artifex.com>
e1aead165e05e98ae765d6569f39ced839d4298e

> Guard against divide-by-zero exceptions in the halftone code
> Bug #697663 "FPE in gx_compute_cell_values()"
> Bug #698332 "FPE (Division by zero) in pick_cell_size()"
> These have the same root cause, in pick_cell_size() we can end up with
> halftone cell parameters which are (I think) improperly initialised.
> Certainly its possible to get to the point where we divide using one
> of the parameters, and if its 0 we get an error. I suspect that the
> halftone may be badly broken even when its not 0, but both these files
> are the result of fuzzing, so I doubt its possible to have a real
> working file get to this point.
> Guard against the divide-by-zero errors by checking that both the
> parameters are non-zero (its permissible for one to be 0 I believe)
> base/gshtscr.c

2017-11-06 13:27:19 +0000
Robin Watts <robin.watts@artifex.com>
1fb022758a35502b8e299248dd37207c1abc3ffe

> Optimise pdf14_copy_planes
> Call code derived from pdf14_compose_group rather than
> breaking everything down to rectangles.
> base/gdevp14.c
> base/gxblend.c
> base/gxblend.h

2017-11-06 18:37:39 +0000
Robin Watts <robin.watts@artifex.com>
25d1c5f42b748af8d4d331a7b40ce9863e302332

> Fix misalignment in pdf14_copy_planes.
> In the case where x/y get clipped, we can fail to account for
> this.
> base/gdevp14.c

2017-11-03 18:53:27 -0700
Ray Johnston <ray.johnston@artifex.com>
8f36ee7a64c9ec95eb6657d06c602d0e4bb6f232

> Fix -Z? vs. -Zv output for pattern transparency debug.
> base/gdevp14.c
> base/gsptype1.c
> base/gxpcmap.c

2017-11-03 17:42:52 +0000
Robin Watts <robin.watts@artifex.com>
ee863835be136e21d3a4c4bcbe28e6e050e1bc1a

> Check for a failed allocation before using the buffer.
> base/gdevp14.c

2017-11-03 17:42:21 +0000
Robin Watts <robin.watts@artifex.com>
cc95eea7e6e5b5efb53446c8bcb482b748e9072e

> Squash a warning in pdf14.
> base/gdevp14.c

2017-11-03 17:41:33 +0000
Robin Watts <robin.watts@artifex.com>
a953768a82d685e575c17feeebf3ea4468a319f3

> Fix bad free pdf14 (wrong gs_memory_t)
> Michael spotted that:
> gs -sDEVICE=tiff24nc -Z$?@ -r300 -o out%d.tif -f .
> ./MyTests/Advertising-PowerPoint-A4.pdf
> gave a warning saying that a trans pattern being freed from
> the cache wasn't owned by the supplied memory pointer.
> Indeed the free should have been using memory->stable_memory.
> Here we commit the nice fix whereby the buffer keeps a pointer
> to the memory with which it was allocated.
> This simplifies the pdf14_buf_free calls too.
> Credit to Ray for finding the cause/identifying the fix.
> base/gdevp14.c
> base/gdevp14.h

2017-11-03 15:27:50 +0000
Robin Watts <robin.watts@artifex.com>
3c9f8491ecb5cfa382608c47f5a35ad2bce00edc

> Bug 694918: Fix buffer overrun in image_simple_expand.
> If truly crazy values of x_extent are used, the fixed point
> representation can wrap around and we can start accessing out
> of the buffer.
> Check for such stupid values and nobble us to do no harm.
> base/gxifast.c

2017-11-02 12:07:16 -0700
Ray Johnston <ray.johnston@artifex.com>
1ea664170c68539a035279425447f7ce10e130ff

> Add support to viewpbm.ps for GRAYSCALE and RGB_ALPHA and fix logic for FITPAGE
> The RAW_DUMP with RAW_DUMP_AS_PAM emits RGB_ALPHA and GRAYSCALE but these
> were not supported. Display RGB_ALPHA as CMYK for now.
> Also if SCALE was specified, the ifelse for FITPAGE was inverted.
> lib/viewpbm.ps

2017-11-02 11:51:48 -0700
Ray Johnston <ray.johnston@artifex.com>
4c1f9b28eab25b519d0a14401ec6bbcf01813e12

> Fix RAW_DUMP (minor omissions/typos when blending was refactored.
> Resource/Init/pdf_main.ps
> base/gxblend.c
> base/gxblend.h
> base/gxblend1.c

2017-10-27 08:03:36 -0700
Ray Johnston <ray.johnston@artifex.com>
8200f59f1b5aab852e23322587dda7c182fc195b

> Fix Bug696372: Transparency with DeviceN not coping with bad PDF's
> When a PDF with transparency stops interpretation due to an error, the
> grestore may have popped the pgs so that the pdf14 compositor is no
> longer the currentdevice. The logic in pad14_spot_get_color_comp_index
> assumed that the device was a pdf14_device and got a bogus pointer to
> devn_params. Instead, use the device's ret_devn_params function to get
> the actual pointer.
> Also, the poppdf14devicefilter would execute without the pdf14 device
> as the currentdevice. Save the annots_gstate explicitly in pdf_main
> showpagecontents so it can be set back before doing annots and the
> poppdf14devicefilter.
> This also required gs_setgstate to always do gs_do_set_overprint since
> the setgstate may have skipped over states with the overprint compositor.
> This caused "drawn_comps" to not be set correctly for the pdf14
> compose_group.
> Fixups for 696372 fix commit (also ne->be last line of commit msg)
> Resource/Init/pdf_main.ps
> base/gdevp14.c
> base/gsstate.c

2017-11-02 17:54:57 +0000
Robin Watts <robin.watts@artifex.com>
1626f36c9b6ae68abad7818be7cfb2a95f4ecffe

> Bug 698713: Further graphicsAlphaBits + new scan converter fix.
> Previous I ensured that when using graphicsAlphaBits, the new scan
> converter would restrict its output rectangles/traps to fit
> within y % max_fill_band pixels at a time as required.
> I forgot that the base 'y' value taken for this was not necessarily
> aligned to a max_fill_band multiple. Fixed here.
> base/gxscanc.c

2017-11-01 20:08:13 +0000
Robin Watts <robin.watts@artifex.com>
30ba3e3a163f729f2d05561e688dc54df6afa2e1

> LCMS2: Add optimised 3x16bit -> 1x16bit cached transform.
> lcms2/src/cmsxform.c

2017-11-01 21:15:42 +0000
Robin Watts <robin.watts@artifex.com>
d68b31cc315e7e687d0b55a5068b7514d7f73f5f

> LCMS2: Refind transform routine on buffer change.
> lcms2/src/cmsxform.c
> lcms2/src/lcms2_internal.h

2017-11-01 17:23:17 +0000
Robin Watts <robin.watts@artifex.com>
4ef5c30e68bbb33b952db1b70508e7412bf79f0f

> Reintroduce and update LCMS optimisations.
> lcms2/src/cmsxform.c
> lcms2/src/extra_xform.h
> windows/ghostscript.vcproj

2017-10-31 19:37:10 +0000
Robin Watts <robin.watts@artifex.com>
1ab17bc53362ea34b61050429c51c575539bf2b9

> Avoid clearing cm_comps arrays in cmap functions.
> This goes against commit 99c48263b9 by Ray (dating from Nov 1 2009)
> to fix Bug 690713 and solve some indeterminisms.
> My belief is that this SHOULD be fixed in the devices, not in the
> callers. Accordingly I have backed that out, and changed the
> cmyk_cs_to_psdcmyk_cm function (the only one I can find that does
> not set everything to be 0).
> The cluster now shows this running with no diffs.
> base/gxcmap.c
> devices/gdevpsd.c

2017-11-01 12:07:53 +0000
Robin Watts <robin.watts@artifex.com>
b3c0fafa490932cc43009c53c7f8a17598fe78d7

> Tweak map_XXXX_subclass functions.
> To cope with subclassed devices, we no longer simply call:
> pprocs = dev_proc(dev, get_color_mapping_procs);
> pprocs->map_cmyk(dev, ...)
> etc. The 'done thing' is to run up the the dev->parent pointers
> as far as we can, and to get the color mapping procedures from
> that. These color mapping procedures then need to be called
> using the dev pointer from which they were fetched.
> To do this, we provide get_color_mapping_procs_subclass
> and map_XXX_subclass functions that pickle the dev search.
> The only downside to this is that we end up doing the search
> up the tree twice (or more than twice in the case where we
> make several mapping calls).
> Here we therefore tweak these functions so that
> get_color_mapping_procs_subclass returns both the procs AND
> the dev to use when calling them in a structure, and the
> map_XXX_subclass functions now take that structure.
> Broadly, this change shouldn't actually alter any operation,
> other than being slightly more efficient.
> There are a few wrinkles:
> 1) in gsicc_replacecm.c, we were fetching the procs using the
> dev chasing function, but calling them using the unchased dev
> value. Fixed here to use the matching dev value in both cases.
> 2) In a couple of places, we have special handling for forwarding
> devices. I am not convinced that we handle subclassed forwarding
> devices correctly (or devices that forward to subclassed devices).
> I have marked these areas with FIXMEs, but they are no worse
> now than they were before.
> base/gdevdflt.c
> base/gdevdgbr.c
> base/gdevnfwd.c
> base/gscspace.c
> base/gsicc_replacecm.c
> base/gsovrc.c
> base/gspaint.c
> base/gxcmap.c
> base/gxdcolor.c
> base/gxdevcli.h

2017-10-31 17:52:12 +0000
Robin Watts <robin.watts@artifex.com>
961b14dd7e686a1543541070a1ba943590ef2bf9

> Optimise handle_colors in gxiscale.c
> Avoid per-pixel work by doing as much as possible up front.
> base/gxiscale.c

2017-10-31 15:52:49 +0000
Robin Watts <robin.watts@artifex.com>
de645ba2116ecfc71d0fdcea84944735736d0278

> Avoid looking up the profile for every pixel of an image.
> base/gxiscale.c

2017-10-31 13:07:23 +0000
Robin Watts <robin.watts@artifex.com>
f7b61e0cc56206b6811eee85c4cfd6a0963194e0

> Pass device_profile into color concretizing functions.
> base/gdevp14.c
> base/gscdevn.c
> base/gscms.h
> base/gscolor2.c
> base/gscpixel.c
> base/gscsepr.c
> base/gscspace.h
> base/gsicc.c
> base/gsicc_cache.c
> base/gsicc_cache.h
> base/gxcmap.c
> base/gxcspace.h
> base/gxiscale.c
> devices/vector/gdevpdfg.c

2017-10-27 20:24:32 +0100
Robin Watts <robin.watts@artifex.com>
31cb4cf7aa88784219f6fc2be362a66df2f67289

> Tweak cmap functions for speed.
> In looking at the Advertising-PowerPoint-A4.pdf file, I noted that
> cmap_gray_direct and cmap_gray_halftoned were taking a noticable
> amount of time. This commit attempts to alleviate that.
> Various observations:
> 1) Avoid unnecessary loop in cmap_gray_halftoned (and similar functions).
> In some of the code, we do:
> for (i = 0; i < n; i++)
> if (i == k)
> do_something_with(i)
> why not just use:
> if (k < n)
> do_something_with(k)
> 2) Typically functions like cmap_gray_direct do a load of work,
> culminating in trying to encode a color value. If that encoding fails,
> it would fallback to trying to use a cmap_gray_halftoned, which would
> do all the work a second time.
> Tweak the code to avoid the call, and hence the repetition.
> The downside to this is that the work is typically of the form:
> for (i = 0; i < n; i++)
> cv[i] = frac2cv(some_calculation_involving(cm_comps[i]));
> and in order to be able to avoid the call to cmap_gray_halftoned, we
> need to make it:
> for (i = 0; i < n; i++) {
> cm_comps[i] = some_calculation_involving(cm_comps[i]);
> cv[i] = frac2cv(cm_comps[i]);
> }
> i.e. we have to do more stores than before. This can hurt us in some
> cases, but it seems like a worthwhile win, especially in light of 3).
> 3) A lot of the work in these functions involves mapping colors through
> the effective_transfer functions. This happens in code of the form:
> for (i = 0; i < n; i++) {
> cm_comps[i] = gx_map_color_frac(pgs, cm_comps[i], effective_transfer[i]);
> }
> If effective_transfer[i] is identity (as it almost always is), then
> this whole loop is a nop.
> We make some steps to optimise for this case by having the
> gx_map_color_frac macro check for effective_transfer[i] being
> gs_identity_transfer before calling it, but this doesn't help us
> avoid the loop/load/store.
> We therefore extend pgs with a count of the number of
> 'effective_transfer's that are non identity (essentially a flag
> that enables us to know if we can skip this loop or not),
> and use that to optimise our work.
> base/gsht.c
> base/gxcmap.c
> base/gxgstate.h

2017-10-30 19:31:47 +0000
Robin Watts <robin.watts@artifex.com>
de651aaa531a7eb6fa99c1ef97682ebe22a3cda7

> Further optimisations in pdf14_mark_fill_rectangle.
> Normal blend mode case is always worth optimising.
> base/gxblend.c
> base/gxblend.h

2017-10-31 14:11:24 +0000
Robin Watts <robin.watts@artifex.com>
fda23c007c3acb96198648c3f4a65438ce449b63

> Squash warnings.
> psi/zcolor.c
> psi/ztrans.c

2017-10-30 11:08:09 +0000
Ken Sharp <ken.sharp@artifex.com>
76b922b5d3071288edbf8f0cccdbbd2b0ae34742

> PDF interpreter - try and catch yet more cases of circular references
> No bug report for this one, the customer requested destruction of the
> PDF file after analysis, and there was no way to reduce the file to the
> point where nothing sensitive remained.
> The problem is that a Form XObject referenced a number of Image XObjects
> one of which contained a DecodeParms array, where the second element
> referenced the original Form XObject. This circular reference leads to
> an error.
> Here we maintain a dictionary (initially empty) on the stack which we
> populate with object numbers as we recursively dereference objects.
> When we start a new composite object we copy the array into a new array
> which we discard on completion. This is to prevent false detection of
> circular references if we dereference multiple composite objects at the
> same level (eg if we deal with multiple images, each of which perhaps
> contained a reference to the same colour space).
> We now issue an error quoting the object number being circularly
> referenced, replace the object with a null object and continue.
> No differences expected.
> Resource/Init/pdf_base.ps

2017-10-27 18:08:34 +0100
Robin Watts <robin.watts@artifex.com>
ecb0181ae2c6c64f876f741ef1da2980324442ca

> Use integer maths for bitmap interpolation internals.
> We calculate the weights using doubles still, but store them as
> integers. This means all the inner loops avoid FP.
> base/siscale.c

2017-10-27 16:53:51 +0100
Robin Watts <robin.watts@artifex.com>
b62bfe2c7d166bfe8f3743e122abc755d96bec9c

> Unpack/Unroll the inner loops of Mitchell scaler.
> base/lib.mak
> base/siscale.c

2017-10-26 12:53:29 +0100
Robin Watts <robin.watts@artifex.com>
81561e6e04f49a4b3b9599cc09ba2cde4407e936

> Optimise clip_fill_rectangle and family.
> Avoid testing for transpose each time, and cope with the common
> single rectangle case more efficiently.
> This gives a 20% speedup in testing with my cutdown
> Advertising-Powerpoint-A4.pdf file going to 1200dpi, 1bpc cmyk.
> The only one called here is clip_fill_rectangle, but push the
> same optimisations through clip_fill_rectangle_hl_color,
> clip_copy_mono, clip_copy_planes etc to help other devices.
> base/gxclip.c

2017-10-26 16:00:18 +0100
Ken Sharp <ken.sharp@artifex.com>
0d2177ac781235aa67cde3b6fc9d85030c50a8a9

> pdfwrite - take action on an error.
> Don't ignore the potential error return from gx_path_current_point()
> devices/vector/gdevpdte.c

2017-10-25 15:04:28 +0100
Ken Sharp <ken.sharp@artifex.com>
f13a659f9700fac0a0f47007c1eaacddd5c7f208

> improve commit d9d74def0095641f20b46716c929bc6f88154490
> There were a couple of places that returned 0 which, after the goto
> change, return code. Its just barely possible that code might not be
> 0, so set it to 0 first.
> devices/vector/gdevpdte.c

2017-10-25 14:57:12 +0100
Ken Sharp <ken.sharp@artifex.com>
d9d74def0095641f20b46716c929bc6f88154490

> pdfwrite - revisit clipped text and commit 46ef6bc80bd7388883a00aa866af38fe8f05d45b
> Bug #698693 "clipped text is selectable in pdf"
> Commit 46ef6bc80bd7388883a00aa866af38fe8f05d45b fixed bug 697442, in
> that case we needed to completely process text which had been
> deliberately placed off the page (and tehrefore outside the clip).
> In that bug the text used glyphshow, which meant that it could not use
> stringwidth to measure the width of the string, and perform accurate
> positioning. So instead it placed the current point off the page,
> used glyphshow to draw the text, and then currentpoint to find the
> displacement.
> By not fully processing the text we did not correctly update currentpoint
> and so the text was misplaced. This was fixed by fully processing
> the text, but altering a copy of the text enumerator's 'operation'
> field so that the text was not added to the page (clearing TEXT_DO_DRAW)
> However, there are still places (process_text_modify_width) which can
> add the text in, and those look directly at the text enumerator
> operation flags.
> So here we still copy the operation flags, but we then modify the copy
> held in the text enumerator, so that any subsequent processor will
> be able to see that the text should not be drawn. At the end of the
> function we restore the flags in the enumerator. This has meant a few
> places executing a 'goto' in order to reset the flags, instead of simply
> returning as previously.
> A few test files show extremely minor (1 pixel) positioning differences.
> devices/vector/gdevpdte.c

2017-10-24 07:19:39 -0600
Henry Stiles <henry.stiles@artifex.com>
140e1cb28a6ad42e2ded8381af8b53421923e0e1

> Fix bug #694630 - Fuzzing Segmentation Fault.
> Along with soft fonts, the built in fonts should not be restored when
> a macro call completes. The segmentation fault in the report was
> caused by a dangling reference to a deleted font after restoring the
> built in font dictionary. Also, removes a stale comment.
> pcl/pcl/pcsfont.c

2017-10-24 12:13:23 +0100
Chris Liddell <chris.liddell@artifex.com>
434234ef22fd28217045c6485672c93a9685a607

> Have configure set memory manager alignment.
> For certain Unix derivatives (HP-UX, Solaris, and AIX) we have to use 64 bit
> memory alignment - configure will now spot if we are building on and for those
> platforms, and set the alignment appropriately.
> Cross compiling still defaults to 32 bit, and if 64 bit alignment is required,
> it must set explicitly.
> configure.ac

2017-10-21 11:01:12 +0100
Ken Sharp <ken.sharp@artifex.com>
5889736af797dcba1d46af11a84b765340f6c3c4

> PDF interpreter - improve commit 9e8d2e
> We should use .endtransparencytextgroup to close the group started by
> .begintransparencytextgroup, not .endtransparencygroup
> Oddly this doesn't actually seem to cause any problems, but its not
> right.
> Resource/Init/pdf_draw.ps

2017-10-20 14:40:21 -0700
Ray Johnston <ray.johnston@artifex.com>
6495e38f2dbaeedcaedf84f15c96e78aab6773c4

> Remove useless test in PDF interpreter transparency code
> This test was always true since we always have .begintransparencygroup
> It was changed in 2008 from a check for .inittransparencymask which was
> created back in 2006. It was probably a test in case the PDF interpreter
> was running on a system that may not include the pdf14 compositor, but
> that is only a guess.
> Resource/Init/pdf_ops.ps

2017-10-20 16:14:41 +0100
Ken Sharp <ken.sharp@artifex.com>
9e8d2e156aa3ea039f531e6ea378add4ea6e268c

> PDF interpreter - fix annotations with transparency and text
> Since the introduction of '.begintransparencytextgroup' the synthesis
> of missing Appearances for annotations involving text has been broken.
> Approximately since January 2017.
> Introducing '.begintransparencytextgroup' fixes the problem.
> Resource/Init/pdf_draw.ps

2017-10-20 14:16:44 +0100
Chris Liddell <chris.liddell@artifex.com>
2fc463d0efbd044a8232611f0898eeb12b72a970

> Bug 698676: have filenameforall permission check use "reduced" path
> Prevents working around SAFER file access permissions.
> CVE-2017-15652
> psi/zfile.c

2017-10-19 13:01:46 +0100
Robin Watts <robin.watts@artifex.com>
684f73e8deefacb2aa5d2277f3154b68809b2ab7

> Bug 698672: Fix new scanconverter/alphabits interaction.
> The alphabits mechanism relies on the scan converter not
> writing trapezoids so tall as to cause its line buffers
> to flush too early.
> This is achieved by honoring the max_band_height field in
> the device header. Previously the new scan converter was
> ignoring this. Here we alter the code to pay attention to
> it.
> base/gxscanc.c

2017-10-17 12:19:19 -0700
Ray Johnston <ray.johnston@artifex.com>
cc9a66978c56fdfff61bc3b1166955e5506470a9

> Fix bug 693304. Restore with pdf14 can cause SEGV
> The pdf14 compositor device is retained but the mask_stack (and other
> elements of the pdf14_ctx need to be in stable memory to prevent
> dangling references after a restore.
> base/gdevp14.c

2017-10-18 17:01:01 +0100
Chris Liddell <chris.liddell@artifex.com>
6d048c85f5c75e7539e8b5fc42f5fd856986cc6e

> Bug 698669: remove reference to removed example file
> Some time ago, we removed the example file chess.ps due to questions over the
> license for the font it used.
> But the makefile gubbins to "install" the example files wasn't changed to suit,
> and on HP-UX (but so far, nothing else!) caused "make install" to error out.
> base/unixinst.mak

2017-10-18 14:14:11 +0100
Chris Liddell <chris.liddell@artifex.com>
7da09aaf701bd4ff2acea55aacce84a22455aead

> Bug 698647: pdfwrite: avoid cached glyphs for Type 3 font input only
> The original fix in 8360852efab5643d93cc3b040832075e199cd205 wrongly assumed
> that the changed code only came into effect for Type 3 font *input* where,
> in reality, it's for any font for which we have to create a Type 3 in the
> output.
> The change to disable the use of the cache should only apply to Type 3 input
> where we want to force the execution of the BuildGlyph/BuildChar proc so
> pdfwrite can capture it.
> In all other cases, we need to leave the cache in play.
> devices/vector/gdevpdtt.c

2017-10-17 10:16:51 +0100
Ken Sharp <ken.sharp@artifex.com>
9219b1e5febd646f6d87bc424b41237a50529d0d

> Page selection device - fix overprint compositor usage
> Bug #698568 "Ghostscript segmentation fault when doing page selection"
> The PostScript interpreter uses the current device in the graphics
> state, and calls the create_compositor() method when overprint is
> set to true.
> This may or may not insert a new compositor device into the graphics
> state, and whether it does or not is controlled by the return from
> the method. If the device is the same as the one in the graphics state
> then we don't set a new device, if its different then we set the
> returned device.
> The page selection device wasn't initialising this parameter, and if
> we were skipping the page we didn't call the child device method,
> which meant we returned an uninitialised pointer to the caller. Since
> this was unlikely to be the same as the current device, we ended up
> trying to set the device in the graphics state to an uninitialised
> pointer, with predictably disastrous results.
> The simple fix is to initialise the pointer to the current device in
> the graphics state. If we call the child method, and it wants a new
> compositor then it will overwrite it, if it doesn't, or we are skipping
> the page, then we return the current device and nothing changes.
> No differences expected.
> base/gdevflp.c

2017-10-13 11:16:40 +0100
Ken Sharp <ken.sharp@artifex.com>
05432a551f887d7526b2bf3c65f3f1740cb3cc48

> PDF interpreter - Improve annotation appearance generation
> Bug #698627 "PDF 2.0 tests Polygon annotation"
> Bug #698629 "PDF 2.0 tests Polyline annotation"
> Bug #698630 "PDF 2.0 tests Ink annotation"
> This commit refactors the code previously committed for Circle and
> Square annotations to make it more general. Adds support for the Polygon,
> PolyLine and Ink with /Path array (new to PDF 2.0). Adds support for
> transparency in Annotations (some limited support was available before).
> Adds the /Line annotation type and implements the Line Ending (/LE)
> array, but not other aspects of the Line annotation (these may be added
> at a later date).
> Bug #698628 "PDF 2.0 tests Redact annotation"
> We specifically don't generate an Appearance for Redact annotations, but
> will render one if supplied. This annotation is really an interactive
> feature, not relevant to print.
> Predictably this commit causes differences as we now generate substitute
> appearances for more annotation types when the appearance is missing.
> Resource/Init/pdf_draw.ps
> Resource/Init/pdf_main.ps

2017-10-12 14:16:40 +0000
Chris Liddell <chris.liddell@artifex.com>
9196c7ff8c41f1b256d58696158cd6b99e238459

> Always force unsigned chars for Luratech
> configure.ac

2017-10-09 13:14:23 +0100
Robin Watts <robin.watts@artifex.com>
6b076c380d4479aa64375baaad59dba6729e2c8f

> Fix problems caused by pdf14_compose_group tuning.
> It seems that has_mask == 0 does not equate to maskbuf != NULL.
> Assuming that mask_mask == 0 => maskbuf == NULL causes problems in
> tests_private/pdf/sumatra/fireworks_with_radial_shading.pdf (300dpi
> clist renderings in particular) and in
> tests_private/pdf/uploads/Bug697212.pdf (all renderings).
> base/gxblend.c

2017-10-10 10:14:04 +0100
Ken Sharp <ken.sharp@artifex.com>
f64fa48dc792230244f20f115b8dbe3545f484da

> Documentation - remove references to .runandhide
> We removed a number of PostScript operators from accessibility after
> the interpreter is running as part of the security overhaul. One of
> these was .runandhide but we accidentally left a couple of references
> in the documentation (the main part of the documentation was correctly
> updated).
> So remove the references here, and update the documentation to note the
> potential risks in using -dNOSAFER with a save object on the exec
> stack.
> doc/Language.htm
> doc/Use.htm

2017-09-12 10:32:51 +0100
Chris Liddell <chris.liddell@artifex.com>
dab8018a344409710b989c31575e6e0e4eb243ce

> Bring master up to date with gs922 branch
> Update docs dates etc for release
> Changelog and news
> Update dates/product for 9.22rc2
> Changelog for 9.22rc2
> Dates, product, changelog for 9.22 release
> base/version.mak
> doc/API.htm
> doc/C-style.htm
> doc/Commprod.htm
> doc/DLL.htm
> doc/Deprecated.htm
> doc/Details8.htm
> doc/Details9.htm
> doc/Develop.htm
> doc/Devices.htm
> doc/Drivers.htm
> doc/Fonts.htm
> doc/Helpers.htm
> doc/History1.htm
> doc/History2.htm
> doc/History3.htm
> doc/History4.htm
> doc/History5.htm
> doc/History6.htm
> doc/History7.htm
> doc/History8.htm
> doc/History9.htm
> doc/Install.htm
> doc/Issues.htm
> doc/Language.htm
> doc/Lib.htm
> doc/Make.htm
> doc/News.htm
> doc/Projects.htm
> doc/Ps-style.htm
> doc/Ps2epsi.htm
> doc/Psfiles.htm
> doc/Readme.htm
> doc/Release.htm
> doc/SavedPages.htm
> doc/Source.htm
> doc/Unix-lpr.htm
> doc/Use.htm
> doc/VectorDevices.htm
> doc/WhatIsGS.htm
> doc/Xfonts.htm
> doc/gs-vms.hlp
> doc/sample_downscale_device.htm
> doc/thirdparty.htm
> man/dvipdf.1
> man/gs.1
> man/gslp.1
> man/gsnd.1
> man/pdf2dsc.1
> man/pdf2ps.1
> man/pf2afm.1
> man/pfbtopfa.1
> man/printafm.1
> man/ps2ascii.1
> man/ps2epsi.1
> man/ps2pdf.1
> man/ps2pdfwr.1
> man/ps2ps.1
> psi/int.mak
> psi/msvc.mak

2017-10-09 11:08:07 +0100
Ken Sharp <ken.sharp@artifex.com>
11f058b7fea07b2a5d2677be3f057cc5ee3e9023

> PDF Interpreter - support the /Circle annotation type without an appearance
> Bug #698626 "PDF 2.0 tests Circle annotation"
> We didn't synthesise an appearance for annotations of type /Circle
> when they had no appearance stream. This commit adds that support.
> Rather surprisingly, there do not appear to be any files in our test
> suite which exercise this. Doubly surprising since I thought all the
> release 2 PDF 2.0 FTS files were included and its one of these that
> is quoted in the bug report.
> Resource/Init/pdf_draw.ps

2017-10-07 13:33:03 +0100
Ken Sharp <ken.sharp@artifex.com>
6db482c183959dbccdc865d8a27cb53b054d3dc1

> PDF Interpreter - support the /Square annotation type with no /Appearance
> Bug #698625 "PDF 2.0 tests Square annotation type"
> We didn't synthesise an appearance for annotations of type /Square
> when they had no appearance stream. This commit adds that support.
> Rather surprisingly, there do not appear to be any files in our test
> suite which exercise this. Doubly surprising since I thought all the
> release 2 PDF 2.0 FTS files were included and its one of these that
> is quoted in the bug report.
> Resource/Init/pdf_draw.ps

2017-10-06 17:23:59 +0100
Ken Sharp <ken.sharp@artifex.com>
83ef35dce760f68019afd1b07bac8118cd9837a2

> PDF and PS Interprters and ps2write - fix type 6 halftones & transfers
> Bug698621 "PDF 2.0 tests not applying transfer function from halftone"
> The halftones in question are defined (by the PDF interpreter) as type
> 6 halftones, ie file-based threshold arrays.
> Rather to my surprise, the reason this didn't work turns out to be
> because the PostScript interpreter has never supported transfer functions
> with type 6 halftones.
> So; add support for transfer functions in type 6 halftones. This exposed
> a problem with ps2write (and potentially pdfwrite) when emitting these
> transfer functions, instead of simply specifying the object number of
> the function, we were writing it out decorated with "/TransferFunction"
> which caused ps2write output to fail. So fix that here too.
> Remove the 'OBSELETE' comment from the halftone structure, I don't know
> who thought this was obselete, but it really does not seem to be.
> base/gsht1.c
> base/gxht.h
> devices/vector/gdevpdfg.c
> psi/zht2.c

2017-10-06 14:52:03 +0100
Robin Watts <robin.watts@artifex.com>
45a826638bfc6309a829b38ecf14ff9c21f438ca

> Tune pdf14_compose_group inlining.
> Pick specific inlinings based upon examination of the data
> from the TRACK_COMPOSE_GROUPS defines.
> base/gxblend.c

2017-10-05 19:25:41 +0100
Robin Watts <robin.watts@artifex.com>
7b6bce45b1a85266a40844436ea386c4129515f4

> Add TRACK_COMPOSE_GROUPS development code.
> This enables us to track which combinations of options
> are used, and how frequently.
> base/gxblend.c

2017-10-05 19:28:23 +0100
Robin Watts <robin.watts@artifex.com>
5e1675e95b0574f9a5f469458e849e1837c33983

> Further tweaks to pdf14_mark_fill_rectangle
> Avoid having to check for src_alpha == 0 every time around
> the loop.
> base/gxblend.c

2017-10-05 19:29:07 +0100
Robin Watts <robin.watts@artifex.com>
8c72c12c30553b76b4e2b23261529ec4c6d49b43

> Further tweaks to pdf14_preserve_backdrop
> Attempt to avoid blanking tag plane when we're about to copy
> into it.
> base/gxblend1.c

2017-10-05 19:26:15 +0100
Robin Watts <robin.watts@artifex.com>
affab3b5889ce7b8bcb38d0c7c938b907d1e8253

> Fix typo.
> base/gxblend.c

2017-10-05 14:37:37 +0100
Robin Watts <robin.watts@artifex.com>
882e0bfed09e839d53287164ebf4aa99ca5f116a

> Optimise pdf14_mark_fill_rectangle using inlining.
> Same tricks as used for pdf14_compose_group.
> base/gdevp14.c
> base/gxblend.c
> base/gxblend.h
> base/lib.mak

2017-10-04 17:01:24 +0100
Robin Watts <robin.watts@artifex.com>
77cdf72595643da5d17e84fb72d8f58ccfe3d038

> Avoid duplicating code in art_pdf_composite_pixel_alpha8_inline.
> We can spot that blend_mode == BLEND_MODE_Normal in the caller,
> and set first_spot to 0 in that case. Then we always drop
> straight through to the code at the end, and omit the complex
> blend call. Reduces code, doesn't change the speed.
> base/gxblend.c

2017-10-04 16:54:59 +0100
Robin Watts <robin.watts@artifex.com>
aaccd9b5942aae6738ac02874e627b9e8677f965

> Instantiate some more 'optimised' routines for pdf14_group_compose.
> The last one of these is the one that gets hammered in the
> normal_blend_test.pdf file.
> base/gxblend.c

2017-10-04 16:54:23 +0100
Robin Watts <robin.watts@artifex.com>
3dba9682de0b69a8822507a1c11d9f782c33b4c9

> Tweak art_pdf_composite_pixel_alpha_8_inline.
> Normal blending allows us to not only skip the art_blend_pixel_8_inline
> call, but also to simplify the calculations.
> base/gxblend.c

2017-10-04 16:52:03 +0100
Robin Watts <robin.watts@artifex.com>
67bae85a6f46190262cf8a6ad6c37c7aff2e6cc5

> Introduce forceinline define.
> It seems MSVC thinks it knows best about what to inline and what not to.
> Use new 'forceinline' define to persuade it to actually do what it is
> told. On all non-MSVC compilers this just maps to inline.
> base/gxblend.c
> base/stdpre.h

2017-10-04 00:39:53 +0100
Robin Watts <robin.watts@artifex.com>
a9f06af39ced9a69f5841ceef3f5e921c34ea5a7

> Further optimisation in pdf14_compose_group.
> Avoid memcpy's when unnecessary in some of the subfunctions,
> by having a 'dst' pointer that points to the results. If
> the results are supposed to be the same as the src, don't
> copy the source, just reset the dst pointer.
> If the dst pointer is set to NULL, then don't copy the results
> at all, as it'll be the current values unchanged.
> base/gxblend.c

2017-10-03 19:50:33 +0100
Robin Watts <robin.watts@artifex.com>
29e07d407e997a596f682cffa2069e5cea9e3fb4

> Use inlining on pdf14_compose_group functions.
> We move pdf14_compose_group into gxblend.c to enable us to
> make the constituent functions static inlines.
> base/gxblend.c
> base/gxblend.h
> base/gxblend1.c
> base/lib.mak

2017-10-03 19:09:00 +0100
Robin Watts <robin.watts@artifex.com>
65c442f7b2c1a91816f9026553004d66dde147ec

> Tweak art_pdf_composite_knockout_group_8.
> Another case where we can avoid a memcpy by corrupting the source
> data we are passed.
> base/gxblend.c
> base/gxblend.h

2017-10-03 18:45:30 +0100
Robin Watts <robin.watts@artifex.com>
7ef1126569bbdd405f7ef38eb5cd7e4928321f4f

> Further optimisations to compose_group.
> compose_group calls both art_pdf_recomposite_group_8 and
> art_pdf_composite_group_8 next to one another. Both end
> (in most cases) by doing an identical call to
> art_pdf_composite_pixel_alpha_8.
> Tweak the code so that this call happens from the calling
> routine (and thus we only have a single call to the routine).
> This makes no difference now, but potentially saves when
> we start inlining.
> The tweaks here to art_pdf_recomposite_group_8 to avoid
> using a temporary array, *do* avoid a copy in the common case.
> base/gxblend.c
> base/gxblend.h
> base/gxblend1.c

2017-10-03 18:09:05 +0100
Robin Watts <robin.watts@artifex.com>
8d2a3a5b0f8280449d75ea99ddcadb69259370b6

> Tweak art_pdf_recomposite_group_8.
> Avoid having to memcpy the input components in the common case,
> at the expense of corrupting src[n_chan] in the difficult
> case. This is fine, because our only caller never accesses
> src[n_chan] again.
> base/gxblend.c
> base/gxblend.h
> base/gxblend1.c

2017-10-03 15:05:38 +0100
Robin Watts <robin.watts@artifex.com>
ab6acb21bfc42194650ff90243e0737b43d81919

> Start inlining optimisation of compose_group.
> base/gxblend1.c

2017-10-03 13:41:20 +0100
Robin Watts <robin.watts@artifex.com>
8f2d625c260f174d2daa54508f0ff0147c4ad334

> Tweak art_pdf_composite_knockout_group_8.
> This function has 2 branches, both of which end up with the same
> call to art_pdf_knockout_composite_pixel_alpha_8. Tweak the
> code so that we only need do one.
> No speedup expected, but this paces the way for inlining later.
> base/gxblend.c

2017-10-02 20:32:46 +0100
Robin Watts <robin.watts@artifex.com>
83cd299b98510dc87cd3aa27f57a060b268e05ee

> Do not overcopy bytes for pdf14 blending.
> base/gxblend.c

2017-10-03 16:56:43 +0100
Robin Watts <robin.watts@artifex.com>
88152e5c620bda7d25cd351c765751c619019a58

> Tweak art_pdf_composite_pixel_alpha_8.
> art_pdf_composite_pixel_alpha_8 is used to blend src and
> destination pixels together with a given blend mode.
> In the general case, we have n colour compoents, of which the
> first n-s are process ones, and the next s are spots (followed
> by alpha).
> In some cases, we need to blend the first n-s with the given blend
> mode, and the remaining s in Normal mode.
> This is currently achieved in the code by making 2 different calls
> down to art_pdf_composite_pixel_8 for each section of the pixel
> (with different 'n' values).
> Unfortunately, due to alpha being assumed to be held as the nth
> component, this means we need to do a dance where we stash away
> a components value, copy the alpha in, call the routine, then
> restore the alpha afterwards.
> To avoid this, we modify art_pdf_composite_pixel_alpha_8 to take
> another int parameter, specifying the position of the first
> component that needs to be blended with the Normal mode.
> This enables us to simplify the outer routines that call this so
> that we have a single call, rather than 3. It also means we don't
> recaulate 'scale' etc twice.
> I am not expecting any significant speedups from this alone, but
> it simplifies the code so that hopefully we might get some in
> later commits.
> base/gdevp14.c
> base/gxblend.c
> base/gxblend.h
> base/gxblend1.c
> base/gxp1fill.c

2017-10-03 16:55:59 +0100
Robin Watts <robin.watts@artifex.com>
5cc958e9c318ffd51223d6794df389b3c19d1aa1

> Tweak pdf14 compose group function towards optimisation.
> The plan here is to move towards optimised inner loops. The
> initial version of these inner loops will be done using
> static inline templating. This initial commit won't give
> much (if any) improvement, but starts us on the road.
> base/gxblend1.c

2017-10-02 17:42:34 +0100
Robin Watts <robin.watts@artifex.com>
b26279df55a77fe2252de803a0e23ff4f703d609

> Tweak art_pdf_composite_group_8.
> Avoid 2 different calls down to art_pdf_composite_pixel_alpha_8
> when 1 will suffice. No expected speed benefit yet.
> base/gxblend.c

2017-10-02 14:48:54 +0100
Robin Watts <robin.watts@artifex.com>
463928c19de23164ec61e0fdea119195fa1450f4

> Inline versions of art_pdf_union_mul_8 and art_blend_pixel_8.
> base/gxblend.c
> base/gxblend.h

2017-08-01 12:40:53 +0100
Robin Watts <robin.watts@artifex.com>
4505a7fa04bc89a3f9463b0bcf069210771a8a42

> Fix psd spot color handling in bmpcmp.
> toolbin/bmpcmp.c

2017-10-05 11:21:40 +0100
Ken Sharp <ken.sharp@artifex.com>
4f830ad24611ea8c88f78e77dd3b250ee3c55251

> PDF interpreter - remove accidental debugging
> Left some debugging in the SpotFunction array commit, remove it.
> Resource/Init/pdf_draw.ps

2017-10-05 11:11:06 +0100
Ken Sharp <ken.sharp@artifex.com>
75463b045f4ea314f1d22b1b63be5e3709ec59aa

> PDF Interpreter - support PDF 2.0 SpotFunction arrays
> Bug #698620 "PDF 2.0 tests invalid halftones"
> This was an oversight on my part, I missed new functionality when
> reading the PDF 2.0 specification.
> The SpotFunction in a type 1 Halftone can now be a name, function or (new)
> an array of names. If its an array we are supposed to check the entries
> in turn selecting the first one we recognise. If we don't recognise any
> then we should use the default.
> Resource/Init/pdf_draw.ps

2017-10-04 15:48:07 +0100
Robin Watts <robin.watts@artifex.com>
3d6168d9bdfe60f77bc60a270945c67e36ac02a3

> Tweak pdf14_preserve_backdrop (for speed).
> First the current code clears the backdrop, then we copy into it.
> In many cases we overwrite exactly the area we just cleared. Spot
> this, and avoid it.
> We *could* optimise this further in cases where we aren't overwriting
> exactly the same region. Wait to see if this is justified.
> base/gxblend1.c

2017-10-04 20:07:06 +0100
Robin Watts <robin.watts@artifex.com>
a2532236a8f85101c3d0377dde163071745c53bf

> Tweak pdf14_preserve_backdrop (for clarity).
> Reduce duplicated code.
> Also, ensure that the debugging code that dumps planes actually
> dumps the plane that the file modifies.
> base/gxblend1.c

2017-10-04 17:15:10 +0100
Ken Sharp <ken.sharp@artifex.com>
df32585f91bb6b1023fef42545cae2419b0e10db

> PDF interpreter - permit 0 size font scaling, render nothing
> Bug #698619 "PDF 2.0 tests 'zero sized text'"
> The PDF 2.0 specification permits font scale of 0 (!), but nothing
> should be rendered....
> We can't have a font scale of 0, because it breaks our arithmetic, so
> we set it to a tiny value, unfortunately this still means that stroking
> text rendering modes printed some small garbage.
> After a lot of effort with the PDF interpreter, I concluded that there
> was no reasonable way to address this in PostScript, as we didn't
> retain the font size anywhere and had no reasonable, non-volatile,
> place to store it (it needs to respect gsave and grestore).
> So in the end I added it to the graphics state and created two new
> operators to read and write it (and undefined them after startup).
> Its an unfortunately brute-force approach, but it has the benefit of
> actually working.
> Resource/Init/gs_init.ps
> Resource/Init/pdf_ops.ps
> base/gsstate.c
> base/gsstate.h
> base/gxgstate.h
> psi/int.mak
> psi/zgstate.c

2017-10-04 14:07:11 +0100
Chris Liddell <chris.liddell@artifex.com>
3ea417610c5f0526251ed391bfd117a81c9801e1

> Version and dates for jbig2dec release
> jbig2dec/CHANGES
> jbig2dec/config_win32.h
> jbig2dec/configure.ac
> jbig2dec/jbig2dec.1

2017-10-03 16:50:56 +0100
Robin Watts <robin.watts@artifex.com>
4a7815f3b929a05ec8b5aaac965d62d5d370dcbe

> Fix incorrect group alpha calculation.
> In pdf14_compose_group, in the tos_isolated case, for simple
> blends, we call art_pdf_composite_group_8 to apply blend_mode
> to both process and spots. A side effect of this call is to
> update the contents of nos_alpha_g_ptr.
> In more complex blends, we split the process and spots into
> 2 different calls to the same function. The current code
> however passes nos_alpha_g_ptr to both however, resulting in
> it being updated twice.
> Fixed here by making one of them take NULL.
> base/gxblend1.c

2017-10-03 10:01:14 +0100
Chris Liddell <chris.liddell@artifex.com>
71e8599455a7befc7a14f6cd1353c9231fb93d48

> Bug 698615: pdf_add_ToUnicode() correct size of buffer
> We allocate a buffer to store the Unicode value, but failing to account for
> the fact that the Unicode value is two bytes, rather than a byte
> devices/vector/gdevpdte.c

2017-10-02 16:32:25 +0100
Ken Sharp <ken.sharp@artifex.com>
a015666f7b532c1d9266c4cdef3427e0b50fea90

> PDF interpreter - fix default /Decode for Lab images
> When we get an image with no /Decode array we create a default one for
> it by looking at the image colour space.
> For Lab we use the /Range array, but unfortunately this only covers the
> a and b channels, not the L. However, L always ranges from 0 - 100 so
> here we just pull the Range array apart, add in that range, and create
> a new array for the /Decode.
> Resource/Init/pdf_draw.ps

2017-09-28 18:04:20 -0600
Henry Stiles <henry.stiles@artifex.com>
9e01cbd5e2d5ce41ae98ea20722ec9a7d452b9e9

> Fix buffer overflow regression.
> The commit to address 694653 (3749bc274) was incorrect, the
> font_data_size variable is not necessarily the size of the buffer.
> pcl/pcl/pcsfont.c

2017-09-28 10:08:16 +0100
Ken Sharp <ken.sharp@artifex.com>
eb24ad936776bf69f987e90aad8c7fca78fc2b14

> Documentation - spruce up WhatIsGS.htm
> Remove references to the obselete GhostSVG
> Remove references to MuPDF and MuXPS, MuPDF can easily stand alone now
> and its not really part of the Ghostscript family.
> doc/WhatIsGS.htm

2017-09-27 08:34:10 -0700
Ray Johnston <ray.johnston@artifex.com>
7e342b5978eb9df875a91980554835362412200d

> Revert commit a5a2862d
> Even though the commit fixed bug 695280, we noticed that it caused PS
> and PDF clist image logic to sometimes take the slow "default" handling
> instead of the high-level image path.
> To restore the fix for PCL, we could remove the rop3_uses_T altogether,
> but we don't know if this will impact PCL performance.
> Re-opening bug 695280.
> base/gxclimag.c

2017-09-27 16:35:18 +0100
Ken Sharp <ken.sharp@artifex.com>
40deeb89508e1072a4e93441ea58d6332d10fe4c

> Documentation - remove reference to obselete switch
> Missed this when removing the implementation, PDFDontUseObjectNum is no
> longer supported, so remove it from the documentation.
> doc/VectorDevices.htm

2017-09-26 13:30:16 -0700
Ray Johnston <ray.johnston@artifex.com>
9bc74fe17f4699ae160564ba3fb281344d53dba6

> Fix bug 698560. Transparent pattern-clist playback affected target device
> If a transparent pattern was stored as a pattern-clist, changes to the
> pdf14_device during playback were applied to the upper level device, but
> not restored after the playback. This fixes a long standing problem with
> Bug692217.pdf (ELEMENTARY card was to light gray).
> base/gdevp14.c

2017-09-22 16:06:18 +0100
Ken Sharp <ken.sharp@artifex.com>
8dd5ae8b9ea8dcae7775edb879f2949e2ee55be5

> PDF interpreter - clamp Box to MediaBox, even when MediaBox is negative
> When applying the various 'Box' values from a PDF file, we need to clamp
> them to the MediaBox values, so that we don't try and extend the final
> output to be larger than the Media (this appears to be Acotbat's
> behaviour).
> But we also need to account for the fact that the media (and therefore
> the content) may not lie up and right. Its possible for the media to
> be defined with negative height or width.
> We deal with that by scaling/translating the CTM, but we weren't
> taking it into account when calculating the actual media size, which led
> to us calculating the wrong size.
> This is more complicated, but we only do it once per page, so the
> performance penalty is insignificant.
> Resource/Init/pdf_main.ps

2017-09-22 12:36:22 +0100
Chris Liddell <chris.liddell@artifex.com>
819b79e75d8198d16b13c631d6842953f2c6ab81

> Bug 698581: Pscript5Idiom: add missing conditional (and bind)
> One of the procedures which Pscript5Idiom "patches" was missing an ifelse
> meaning, when that idiom was hit, an unexecuted procedure was left on
> the stack.
> For efficiency and consistency, also bind the entire procedure.
> Resource/IdiomSet/Pscript5Idiom

2017-09-22 10:55:10 +0100
Chris Liddell <chris.liddell@artifex.com>
4a0b2e60e3ed23ec1f7f7e0390ce449bef03b8e4

> Simpify confusing stack manipulations
> The existing code was not wrong, but did several unnecessary stack manipulations
> that made it less efficient but, more importantly, confusing.
> Also, remove trailing whitespace.
> Resource/Init/pdf_ops.ps

2017-09-21 11:27:37 +0100
Chris Liddell <chris.liddell@artifex.com>
000915310197a25ff4acc97f0fa476085698d8fd

> Remove pointless free
> In an error condition, we were freeing the object that had failed to allocate.
> Not a problem with our memory manager, but might cause confusion reading the
> code (it did for me!).
> base/gdevp14.c

2017-09-21 18:34:32 +0100
Chris Liddell <chris.liddell@artifex.com>
6f9ba1282eeb2537248fea11b686eefffc5b86fc

> Fix errors with 6b06b8c854
> The stack manipulations with the previous commit were not quite right.
> Resource/Init/pdf_ops.ps

2017-09-19 10:41:21 -0700
Michael Vrhel <michael.vrhel@artifex.com>
6b06b8c85451bdf022f1684f633a85980e7c62ee

> Bug 698559 avoid double alpha application
> When we have a softmask present in the graphic state, we
> wrap up the fill or stroke with an isolated transparency
> group in the interpreter. After the group is pushed we
> should set the opacityalpha and the shapealpha to 1 to
> avoid a double application of alpha at the rect-fill level and
> the group composition level.
> Resource/Init/pdf_ops.ps
> base/gxblend1.c

2017-09-21 10:13:16 +0100
Ken Sharp <ken.sharp@artifex.com>
8d57c8c54bd4fe8b5582a31dca69d034743eeacb

> pdfwrite - fix compiler warnign
> Cast a pointer correctly to avoid a compiler warning.
> devices/vector/gdevpdfe.c

2017-09-20 16:48:27 +0100
Robin Watts <robin.watts@artifex.com>
c1ba880345f3c17f828e28d4c42f38798eab73c2

> Fix stroke/fill mismatches in 09-37.PS
> When 'accurate curves' are requested, ensure we use the same
> curve -> line decomposition for both strokes and fills.
> base/gxfill.c

2017-09-20 18:33:52 +0100
Robin Watts <robin.watts@artifex.com>
d9f068ae6d612f09dd37915edd56381c6a9167b7

> Fix new scan converter glitch with CATX4547.pdf
> Page 11 of this file contains details on the revolvers cylinder
> rendered by filling zero width vertical lines. For example:
> 0.165 0.068 0 0.187 scn
> 506.47 162.99 m
> 506.47 167.99 l
> 506.47 162.99 l
> f
> The new scan converter was incorrectly eliding this. Fixed by
> tweaking the edgebuffer filtering logic for any-part-of-a-pixel
> mode.
> base/gxscanc.c

2017-09-19 18:01:27 +0100
Robin Watts <robin.watts@artifex.com>
fb95f670d3e54befca541dd35c2d7c2fe690ffbd

> Fix in*fill etc test files.
> The new scan converter has been assuming that anything with an
> x coord < 0 is off screen. While this is true for almost every
> device I can think of, it need not be true for the hit detection
> device used for infill/instroke operations.
> Fixed to use INT_MIN here.
> base/gxscanc.c

2017-09-20 15:37:19 +0100
Ken Sharp <ken.sharp@artifex.com>
29d1b0b1152324699f63ecf411bf7d590085c403

> pdfwrite - fix UTF16 to UTF8 conversion
> There was a signed/unsigned error in the arguments to this routine,
> which meant that bytes with the top bit set caused the whole UTF16
> short to become negative as well.
> Fixed here.
> devices/vector/gdevpdfe.c

2017-09-19 17:43:25 +0100
Chris Liddell <chris.liddell@artifex.com>
c49536553df8eef02c6b0fbf1a46eeb2d086859d

> Write initial device error to stderr
> As the "Unable to open the initial device, quitting." occurs outside the
> Postscript error handling auspices, and causes Ghostscript to quit in a
> possibly unexpected way, write it to stderr rather than stdout.
> Resource/Init/gs_init.ps

2017-09-19 13:59:56 +0100
Ken Sharp <ken.sharp@artifex.com>
085fc4933e5169176124922925f6cc6b454ac03e

> PS interpreter - set EPSCrop when EPSFitPage is set
> Bug #698555 "using DEVICE[WIDTH|HEIGHT]POINTS results in blank image"
> The reporter had not set -dEPSCrop which resulted in no PageSize
> request being sent to the interpreter (because EPS files are note
> permitted to set PageSize). Which defeats the use of PageSize Policy
> 13 to scale the page.
> Since anyone using EPSFitPage clearly wants to scale the page to the EPS
> BoundingBox, we may as well set EPSCrop in case they don't.
> NB the original reporter had not set -dFIXEDMEDIA either...
> Resource/Init/gs_init.ps

2017-09-17 18:34:59 +0100
Ken Sharp <ken.sharp@artifex.com>
fc08a2810b1594ce865190763a7831704c00846d

> pdfwrite - properly process Octal 134 '\' in pdfmark UTF16 string
> Bug #698552 "Some PDF outline UTF-16 text is broken"
> The escape processing wasn't catering for an escaped escape '\\' which
> led to us writing the escaped escape direclty and corrupted the remainder
> of the string. We normaly don't use short escapes but write ocral,
> because some versions of Acrobat can't handle the short escapes.
> This commit just processes the '\\' properly, as per the other
> escapes.
> devices/vector/gdevpdfm.c

2017-09-17 11:46:03 +0100
Ken Sharp <ken.sharp@artifex.com>
275d9547b89aa17dc3a3d9441f712dfdfd344201

> Coverity ID 172798
> We hadn't assigned the return value to the variable 'code' but were
> using it (asigned earlier in the code) to action a return.
> Fixed by actually assigning the value to the variable.
> base/gxshade1.c

2017-09-16 23:34:04 +0100
Ken Sharp <ken.sharp@artifex.com>
ce4bbbde09d087fe3af7036c1fc3f0a38f30c19e

> PDF interpreter - more work on images with invalid /Mask
> Commit 119ec77d4e44e3861a376323ed14466b28b2f4bf fixed one case of a
> /Mask array with invalid values by treating DeviceGray the same as
> /Indexed. However, while that worked for the particular file in question
> (Bug #697919) it caused a regression with Bug689717 which I somehow
> missed at the time.
> This commit treats DeviceGray differently to Indexed spaces and
> clamps the value to either 0 or 1 for 1 BPC images. This seems to work
> as per Acrobat for both files.
> Resource/Init/pdf_draw.ps

2017-09-15 18:24:44 -0500
Robin Watts <Robin.Watts@artifex.com>
7914df697a40314e35847f4e1faca5c964c19e84

> Bug 696399: Fix buffer overflow in image scaling.
> Patch calculation that overflows when x_extent is very
> negative.
> base/gxifast.c

2017-09-15 14:28:28 -0700
Robin Watts <Robin.Watts@artifex.com>
176f0c2f9632b2167cbdd3a3ab44435af3b0bb64

> Remove stray memsets left in from previous commit.
> The "Bug 698427: Fix ignoring errors that lead to division by
> zero." commit contained stray memsets.
> base/gxshade1.c

2017-09-15 13:04:06 -0700
Robin Watts <Robin.Watts@artifex.com>
11a0bc253157ff84be1ef8d065d3ccbf8d377280

> Bug 698427: Fix ignoring errors that lead to division by zero.
> By ignoring error return values, we continue running with
> uninitialised data, leading to division by zero.
> base/gxshade1.c

2017-09-15 10:58:11 -0500
Robin Watts <Robin.Watts@artifex.com>
887026173a2200dba9cb5eed39200f8f1e44cc7a

> Coverity #135034: Simplify code.
> The while loop is not strictly required (but it does match
> the other cases). Simplified here.
> base/gxscanc.c

2017-09-15 10:47:54 -0500
Robin Watts <Robin.Watts@artifex.com>
d7804bfc4d6bdd863137073bdc4f935c960a8f1d

> Coverity #135037: Fix unused variable.
> Don't read a value we don't use.
> base/gxscanc.c

2017-09-05 14:52:07 +0100
Chris Liddell <chris.liddell@artifex.com>
e289916162ce817275e05c536525954028e7d2bc

> Coverity ID# 135035
> Remove pointless "upgraded_copypage" code properly.
> The previous commit for this removed code that it should not have done
> base/gdevprn.c

2017-09-15 13:42:00 +0100
Chris Liddell <chris.liddell@artifex.com>
b3de06e71037a6abcf4546fa7d53a00a3ce47cc3

> Revert "Coverity ID# 135035"
> This reverts commit 05c3de8915fafb65b96ba0860523a7a79e2577e2.
> base/gdevprn.c

2017-09-14 22:40:30 +0100
Chris Liddell <chris.liddell@artifex.com>
b76a38bc57de9085474474fc3de5ec295c9aec21

> Remove man pages for removed (obsolete) tools
> (Reported against 9.22 rc1)
> doc/gs-vms.hlp
> man/de/font2c.1
> man/de/wftopfa.1
> man/font2c.1
> man/gs.1
> man/wftopfa.1

2017-09-14 07:01:32 +0100
Chris Liddell <chris.liddell@artifex.com>
6bf33a5d01518dcba8e957299a91a68d871f2b0b

> White space issues reported against 9.22 rc1
> It seems newer gcc versions (6.4.x and later) report indentation "problems".
> Also, add a cast to ensure bitshift op is done on an unsigned value.
> base/gsbitops.c
> base/gsicc_create.c
> base/gxclread.c
> contrib/gdevbjca.c
> contrib/gdevdj9.c
> devices/gdevepsc.c
> pcl/pxl/pxpaint.c
> psi/dscparse.c
> psi/zcrd.c

2017-09-14 06:41:33 +0100
Chris Liddell <chris.liddell@artifex.com>
d26d2bb23f2d8867d99d5f1fa08a37d3f131e1ad

> Bug 698532: replace ijs/ltmain.sh symlink with file
> ijs/ltmain.sh

2017-09-13 08:43:38 +0100
Chris Liddell <chris.liddell@artifex.com>
cadd9e5faede555fade5e7e8f447de8f40e5c5e9

> Remove reference to old wisc site in Readme.htm
> S
> doc/Readme.htm

2017-09-12 10:27:23 +0100
Chris Liddell <chris.liddell@artifex.com>
67b24cbd748db9d96061f476f42c87bd452a496e

> Bump version number for release
> Resource/Init/gs_init.ps
> base/version.mak

2017-09-12 11:17:15 +0100
Ken Sharp <ken.sharp@artifex.com>
95cb9ab7b4ef15bf60bd074220906f9eda145916

> Remove unused variable 'pdev' to silence compiler warning
> base/gdevp14.c

2017-10-04 09:50:33 +0100
Chris Liddell <chris.liddell@artifex.com>
ba50b3c6061d35275b7067204da6f032fb46cf62

> Dates, product, changelog for 9.22 release
> base/gscdef.c
> base/version.mak
> doc/API.htm
> doc/C-style.htm
> doc/Commprod.htm
> doc/DLL.htm
> doc/Deprecated.htm
> doc/Details8.htm
> doc/Details9.htm
> doc/Develop.htm
> doc/Devices.htm
> doc/Drivers.htm
> doc/Fonts.htm
> doc/Helpers.htm
> doc/History1.htm
> doc/History2.htm
> doc/History3.htm
> doc/History4.htm
> doc/History5.htm
> doc/History6.htm
> doc/History7.htm
> doc/History8.htm
> doc/History9.htm
> doc/Install.htm
> doc/Issues.htm
> doc/Language.htm
> doc/Lib.htm
> doc/Make.htm
> doc/News.htm
> doc/Projects.htm
> doc/Ps-style.htm
> doc/Ps2epsi.htm
> doc/Psfiles.htm
> doc/Readme.htm
> doc/Release.htm
> doc/SavedPages.htm
> doc/Source.htm
> doc/Unix-lpr.htm
> doc/Use.htm
> doc/VectorDevices.htm
> doc/WhatIsGS.htm
> doc/Xfonts.htm
> doc/gs-vms.hlp
> doc/sample_downscale_device.htm
> doc/thirdparty.htm
> man/dvipdf.1
> man/gs.1
> man/gslp.1
> man/gsnd.1
> man/pdf2dsc.1
> man/pdf2ps.1
> man/pf2afm.1
> man/pfbtopfa.1
> man/printafm.1
> man/ps2ascii.1
> man/ps2epsi.1
> man/ps2pdf.1
> man/ps2pdfwr.1
> man/ps2ps.1

2017-10-03 10:01:14 +0100
Chris Liddell <chris.liddell@artifex.com>
dcba89978e3cd6e8e55b44e0830594a385a8e07e

> Bug 698615: pdf_add_ToUnicode() correct size of buffer
> We allocate a buffer to store the Unicode value, but failing to account for
> the fact that the Unicode value is two bytes, rather than a byte
> devices/vector/gdevpdte.c

2017-10-02 16:32:25 +0100
Ken Sharp <ken.sharp@artifex.com>
5751e508f72238c1fcaad1a4c284aa875542dd70

> PDF interpreter - fix default /Decode for Lab images
> When we get an image with no /Decode array we create a default one for
> it by looking at the image colour space.
> For Lab we use the /Range array, but unfortunately this only covers the
> a and b channels, not the L. However, L always ranges from 0 - 100 so
> here we just pull the Range array apart, add in that range, and create
> a new array for the /Decode.
> Resource/Init/pdf_draw.ps

2017-09-28 18:04:20 -0600
Henry Stiles <henry.stiles@artifex.com>
3c2974bcd2e638be13c0ec814342a1a35ca0872b

> Fix buffer overflow regression.
> The commit to address 694653 (3749bc274) was incorrect, the
> font_data_size variable is not necessarily the size of the buffer.
> pcl/pcl/pcsfont.c

2017-09-28 11:37:57 +0100
Chris Liddell <chris.liddell@artifex.com>
f1d39c92bff2de2d7b270a419a907c935ea626a6

> Changelog for 9.22rc2
> doc/History9.htm

2017-09-28 11:35:58 +0100
Chris Liddell <chris.liddell@artifex.com>
b1eda05a9fa7327e76b9a4af980d05da9e926e7f

> Update dates/product for 9.22rc2
> base/gscdef.c
> base/version.mak
> doc/API.htm
> doc/C-style.htm
> doc/Commprod.htm
> doc/DLL.htm
> doc/Deprecated.htm
> doc/Details8.htm
> doc/Details9.htm
> doc/Develop.htm
> doc/Devices.htm
> doc/Drivers.htm
> doc/Fonts.htm
> doc/Helpers.htm
> doc/History1.htm
> doc/History2.htm
> doc/History3.htm
> doc/History4.htm
> doc/History5.htm
> doc/History6.htm
> doc/History7.htm
> doc/History8.htm
> doc/History9.htm
> doc/Install.htm
> doc/Issues.htm
> doc/Language.htm
> doc/Lib.htm
> doc/Make.htm
> doc/News.htm
> doc/Projects.htm
> doc/Ps-style.htm
> doc/Ps2epsi.htm
> doc/Psfiles.htm
> doc/Readme.htm
> doc/Release.htm
> doc/SavedPages.htm
> doc/Source.htm
> doc/Unix-lpr.htm
> doc/Use.htm
> doc/VectorDevices.htm
> doc/WhatIsGS.htm
> doc/Xfonts.htm
> doc/gs-vms.hlp
> doc/sample_downscale_device.htm
> doc/thirdparty.htm
> man/dvipdf.1
> man/gs.1
> man/gslp.1
> man/gsnd.1
> man/pdf2dsc.1
> man/pdf2ps.1
> man/pf2afm.1
> man/pfbtopfa.1
> man/printafm.1
> man/ps2ascii.1
> man/ps2epsi.1
> man/ps2pdf.1
> man/ps2pdfwr.1
> man/ps2ps.1

2017-09-28 10:08:16 +0100
Ken Sharp <ken.sharp@artifex.com>
d59e4b57e1807e934ed1dde51e628f84dfb8caa7

> Documentation - spruce up WhatIsGS.htm
> Remove references to the obselete GhostSVG
> Remove references to MuPDF and MuXPS, MuPDF can easily stand alone now
> and its not really part of the Ghostscript family.
> doc/WhatIsGS.htm

2017-09-27 08:34:10 -0700
Ray Johnston <ray.johnston@artifex.com>
a6830a293f9a69caf50777bb6ee7b553589c0a08

> Revert commit a5a2862d
> Even though the commit fixed bug 695280, we noticed that it caused PS
> and PDF clist image logic to sometimes take the slow "default" handling
> instead of the high-level image path.
> To restore the fix for PCL, we could remove the rop3_uses_T altogether,
> but we don't know if this will impact PCL performance.
> Re-opening bug 695280.
> base/gxclimag.c

2017-09-27 16:35:18 +0100
Ken Sharp <ken.sharp@artifex.com>
c10d5ada53245dac13436d663d3dbe265bc9e11a

> Documentation - remove reference to obselete switch
> Missed this when removing the implementation, PDFDontUseObjectNum is no
> longer supported, so remove it from the documentation.
> doc/VectorDevices.htm

2017-09-26 13:30:16 -0700
Ray Johnston <ray.johnston@artifex.com>
ccaaa1fd02f1cedf221bd6a34e5eb0ef64ef8f3f

> Fix bug 698560. Transparent pattern-clist playback affected target device
> If a transparent pattern was stored as a pattern-clist, changes to the
> pdf14_device during playback were applied to the upper level device, but
> not restored after the playback. This fixes a long standing problem with
> Bug692217.pdf (ELEMENTARY card was to light gray).
> base/gdevp14.c

2017-09-22 16:06:18 +0100
Ken Sharp <ken.sharp@artifex.com>
c470609a95c3ba5d531da463df7a98da01998452

> PDF interpreter - clamp Box to MediaBox, even when MediaBox is negative
> When applying the various 'Box' values from a PDF file, we need to clamp
> them to the MediaBox values, so that we don't try and extend the final
> output to be larger than the Media (this appears to be Acotbat's
> behaviour).
> But we also need to account for the fact that the media (and therefore
> the content) may not lie up and right. Its possible for the media to
> be defined with negative height or width.
> We deal with that by scaling/translating the CTM, but we weren't
> taking it into account when calculating the actual media size, which led
> to us calculating the wrong size.
> This is more complicated, but we only do it once per page, so the
> performance penalty is insignificant.
> Resource/Init/pdf_main.ps

2017-09-22 12:36:22 +0100
Chris Liddell <chris.liddell@artifex.com>
ad87c56e9e88907854d4c37f1a80d8f5d06fb8a7

> Bug 698581: Pscript5Idiom: add missing conditional (and bind)
> One of the procedures which Pscript5Idiom "patches" was missing an ifelse
> meaning, when that idiom was hit, an unexecuted procedure was left on
> the stack.
> For efficiency and consistency, also bind the entire procedure.
> Resource/IdiomSet/Pscript5Idiom

2017-09-22 10:55:10 +0100
Chris Liddell <chris.liddell@artifex.com>
9ae11d7a06c216eae554bcc7696028e69c4bc7ee

> Simpify confusing stack manipulations
> The existing code was not wrong, but did several unnecessary stack manipulations
> that made it less efficient but, more importantly, confusing.
> Also, remove trailing whitespace.
> Resource/Init/pdf_ops.ps

2017-09-21 11:27:37 +0100
Chris Liddell <chris.liddell@artifex.com>
d644437adb7833a2c511d143c13e757383106378

> Remove pointless free
> In an error condition, we were freeing the object that had failed to allocate.
> Not a problem with our memory manager, but might cause confusion reading the
> code (it did for me!).
> base/gdevp14.c

2017-09-21 18:34:32 +0100
Chris Liddell <chris.liddell@artifex.com>
8760a38e4ca49ce403cb362ecb4d6b4d247587f1

> Fix errors with 6b06b8c854
> The stack manipulations with the previous commit were not quite right.
> Resource/Init/pdf_ops.ps

2017-09-19 10:41:21 -0700
Michael Vrhel <michael.vrhel@artifex.com>
cc966e7f9029c27abc896431a3c4910b40d915ef

> Bug 698559 avoid double alpha application
> When we have a softmask present in the graphic state, we
> wrap up the fill or stroke with an isolated transparency
> group in the interpreter. After the group is pushed we
> should set the opacityalpha and the shapealpha to 1 to
> avoid a double application of alpha at the rect-fill level and
> the group composition level.
> Resource/Init/pdf_ops.ps
> base/gxblend1.c

2017-09-21 10:13:16 +0100
Ken Sharp <ken.sharp@artifex.com>
c03add9e9caaa4958928f74a6ca4f2b71915063c

> pdfwrite - fix compiler warnign
> Cast a pointer correctly to avoid a compiler warning.
> devices/vector/gdevpdfe.c

2017-09-20 16:48:27 +0100
Robin Watts <robin.watts@artifex.com>
2285580852e74940a4596b754739ba45a03b40d0

> Fix stroke/fill mismatches in 09-37.PS
> When 'accurate curves' are requested, ensure we use the same
> curve -> line decomposition for both strokes and fills.
> base/gxfill.c

2017-09-20 18:33:52 +0100
Robin Watts <robin.watts@artifex.com>
0803369908a0b4b24b215881e4c4a4ecc5de61c2

> Fix new scan converter glitch with CATX4547.pdf
> Page 11 of this file contains details on the revolvers cylinder
> rendered by filling zero width vertical lines. For example:
> 0.165 0.068 0 0.187 scn
> 506.47 162.99 m
> 506.47 167.99 l
> 506.47 162.99 l
> f
> The new scan converter was incorrectly eliding this. Fixed by
> tweaking the edgebuffer filtering logic for any-part-of-a-pixel
> mode.
> base/gxscanc.c

2017-09-19 18:01:27 +0100
Robin Watts <robin.watts@artifex.com>
03ac50df18eb12d40de1615d18730fdd077f605b

> Fix in*fill etc test files.
> The new scan converter has been assuming that anything with an
> x coord < 0 is off screen. While this is true for almost every
> device I can think of, it need not be true for the hit detection
> device used for infill/instroke operations.
> Fixed to use INT_MIN here.
> base/gxscanc.c

2017-09-20 15:37:19 +0100
Ken Sharp <ken.sharp@artifex.com>
4bb7249ce9320c566da5dac3901c41c7965d37d8

> pdfwrite - fix UTF16 to UTF8 conversion
> There was a signed/unsigned error in the arguments to this routine,
> which meant that bytes with the top bit set caused the whole UTF16
> short to become negative as well.
> Fixed here.
> devices/vector/gdevpdfe.c

2017-09-19 17:43:25 +0100
Chris Liddell <chris.liddell@artifex.com>
f2f9ed2897a4cf166c1df50422b2e82ad2422947

> Write initial device error to stderr
> As the "Unable to open the initial device, quitting." occurs outside the
> Postscript error handling auspices, and causes Ghostscript to quit in a
> possibly unexpected way, write it to stderr rather than stdout.
> Resource/Init/gs_init.ps

2017-09-19 13:59:56 +0100
Ken Sharp <ken.sharp@artifex.com>
5fc5b64a6cd3917326479d3d3a0546dca0feef3c

> PS interpreter - set EPSCrop when EPSFitPage is set
> Bug #698555 "using DEVICE[WIDTH|HEIGHT]POINTS results in blank image"
> The reporter had not set -dEPSCrop which resulted in no PageSize
> request being sent to the interpreter (because EPS files are note
> permitted to set PageSize). Which defeats the use of PageSize Policy
> 13 to scale the page.
> Since anyone using EPSFitPage clearly wants to scale the page to the EPS
> BoundingBox, we may as well set EPSCrop in case they don't.
> NB the original reporter had not set -dFIXEDMEDIA either...
> Resource/Init/gs_init.ps

2017-09-17 18:34:59 +0100
Ken Sharp <ken.sharp@artifex.com>
6e317f178c7fe7c81b573598f848acf8487e4e45

> pdfwrite - properly process Octal 134 '\' in pdfmark UTF16 string
> Bug #698552 "Some PDF outline UTF-16 text is broken"
> The escape processing wasn't catering for an escaped escape '\\' which
> led to us writing the escaped escape direclty and corrupted the remainder
> of the string. We normaly don't use short escapes but write ocral,
> because some versions of Acrobat can't handle the short escapes.
> This commit just processes the '\\' properly, as per the other
> escapes.
> devices/vector/gdevpdfm.c

2017-09-17 11:46:03 +0100
Ken Sharp <ken.sharp@artifex.com>
122808aa46118d483c2fe431d5382c88cdd6e735

> Coverity ID 172798
> We hadn't assigned the return value to the variable 'code' but were
> using it (asigned earlier in the code) to action a return.
> Fixed by actually assigning the value to the variable.
> base/gxshade1.c

2017-09-16 23:34:04 +0100
Ken Sharp <ken.sharp@artifex.com>
087abbc55390499ca27823afbe7d1b62b4ff4f8e

> PDF interpreter - more work on images with invalid /Mask
> Commit 119ec77d4e44e3861a376323ed14466b28b2f4bf fixed one case of a
> /Mask array with invalid values by treating DeviceGray the same as
> /Indexed. However, while that worked for the particular file in question
> (Bug #697919) it caused a regression with Bug689717 which I somehow
> missed at the time.
> This commit treats DeviceGray differently to Indexed spaces and
> clamps the value to either 0 or 1 for 1 BPC images. This seems to work
> as per Acrobat for both files.
> Resource/Init/pdf_draw.ps

2017-09-15 18:24:44 -0500
Robin Watts <Robin.Watts@artifex.com>
f1ccd5e2c82eb137abb7af000e93447653093a4d

> Bug 696399: Fix buffer overflow in image scaling.
> Patch calculation that overflows when x_extent is very
> negative.
> base/gxifast.c

2017-09-15 14:28:28 -0700
Robin Watts <Robin.Watts@artifex.com>
a768ec17b12e44b20d555f3c2fc2c5dcde3d9f0b

> Remove stray memsets left in from previous commit.
> The "Bug 698427: Fix ignoring errors that lead to division by
> zero." commit contained stray memsets.
> base/gxshade1.c

2017-09-15 13:04:06 -0700
Robin Watts <Robin.Watts@artifex.com>
45e4bcf4992c6c22e942730f5df393fc6b4cab63

> Bug 698427: Fix ignoring errors that lead to division by zero.
> By ignoring error return values, we continue running with
> uninitialised data, leading to division by zero.
> base/gxshade1.c

2017-09-15 10:58:11 -0500
Robin Watts <Robin.Watts@artifex.com>
1b18e15f10532d584c6fc2191e1b2a3f8e5ba7e5

> Coverity #135034: Simplify code.
> The while loop is not strictly required (but it does match
> the other cases). Simplified here.
> base/gxscanc.c

2017-09-15 10:47:54 -0500
Robin Watts <Robin.Watts@artifex.com>
6fb9174c1517143158781ed37e0c6d6eb9321808

> Coverity #135037: Fix unused variable.
> Don't read a value we don't use.
> base/gxscanc.c

2017-09-05 14:52:07 +0100
Chris Liddell <chris.liddell@artifex.com>
228ac64b768ac3df1bcd5f63e3f353f8fd01e372

> Coverity ID# 135035
> Remove pointless "upgraded_copypage" code properly.
> The previous commit for this removed code that it should not have done
> base/gdevprn.c

2017-09-15 13:42:00 +0100
Chris Liddell <chris.liddell@artifex.com>
3f9d3e1392236fef4658c8dcad15385670d6831e

> Revert "Coverity ID# 135035"
> This reverts commit 05c3de8915fafb65b96ba0860523a7a79e2577e2.
> base/gdevprn.c

2017-09-14 22:40:30 +0100
Chris Liddell <chris.liddell@artifex.com>
12ff84c1ff077c737b0a194761a370de079943fd

> Remove man pages for removed (obsolete) tools
> (Reported against 9.22 rc1)
> doc/gs-vms.hlp
> man/de/font2c.1
> man/de/wftopfa.1
> man/font2c.1
> man/gs.1
> man/wftopfa.1

2017-09-14 07:01:32 +0100
Chris Liddell <chris.liddell@artifex.com>
7df9b3d9b0dabd9854731fab796d5d458cf743f7

> White space issues reported against 9.22 rc1
> It seems newer gcc versions (6.4.x and later) report indentation "problems".
> Also, add a cast to ensure bitshift op is done on an unsigned value.
> base/gsbitops.c
> base/gsicc_create.c
> base/gxclread.c
> contrib/gdevbjca.c
> contrib/gdevdj9.c
> devices/gdevepsc.c
> pcl/pxl/pxpaint.c
> psi/dscparse.c
> psi/zcrd.c

2017-09-14 06:41:33 +0100
Chris Liddell <chris.liddell@artifex.com>
9e56aafaf2fc8fe3ffeefc0d13fa8c1b033ddec8

> Bug 698532: replace ijs/ltmain.sh symlink with file
> ijs/ltmain.sh

2017-09-13 08:43:38 +0100
Chris Liddell <chris.liddell@artifex.com>
98e115748ec4b16c610396b9444c1d82d263a30c

> Remove reference to old wisc site in Readme.htm
> S
> doc/Readme.htm

2017-09-12 11:17:15 +0100
Ken Sharp <ken.sharp@artifex.com>
4241a4b3a7099cddac36d13f6c67054483eb7511

> Remove unused variable 'pdev' to silence compiler warning
> base/gdevp14.c

2017-09-12 11:16:30 +0100
Chris Liddell <chris.liddell@artifex.com>
29be703c9762714a47f67947d6dfb9efd6c6bc29

> Changelog and news
> doc/History9.htm
> doc/News.htm

2017-09-12 10:32:51 +0100
Chris Liddell <chris.liddell@artifex.com>
85e04afbc2c80c8c6b129aff2741cbdf4d41ff67

> Update docs dates etc for release
> doc/API.htm
> doc/C-style.htm
> doc/Commprod.htm
> doc/DLL.htm
> doc/Deprecated.htm
> doc/Details8.htm
> doc/Details9.htm
> doc/Develop.htm
> doc/Devices.htm
> doc/Drivers.htm
> doc/Fonts.htm
> doc/Helpers.htm
> doc/History1.htm
> doc/History2.htm
> doc/History3.htm
> doc/History4.htm
> doc/History5.htm
> doc/History6.htm
> doc/History7.htm
> doc/History8.htm
> doc/History9.htm
> doc/Install.htm
> doc/Issues.htm
> doc/Language.htm
> doc/Lib.htm
> doc/Make.htm
> doc/News.htm
> doc/Projects.htm
> doc/Ps-style.htm
> doc/Ps2epsi.htm
> doc/Psfiles.htm
> doc/Readme.htm
> doc/Release.htm
> doc/SavedPages.htm
> doc/Source.htm
> doc/Unix-lpr.htm
> doc/Use.htm
> doc/VectorDevices.htm
> doc/WhatIsGS.htm
> doc/Xfonts.htm
> doc/gs-vms.hlp
> doc/sample_downscale_device.htm
> doc/thirdparty.htm
> man/dvipdf.1
> man/font2c.1
> man/gs.1
> man/gslp.1
> man/gsnd.1
> man/pdf2dsc.1
> man/pdf2ps.1
> man/pf2afm.1
> man/pfbtopfa.1
> man/printafm.1
> man/ps2ascii.1
> man/ps2epsi.1
> man/ps2pdf.1
> man/ps2pdfwr.1
> man/ps2ps.1
> man/wftopfa.1
> psi/int.mak
> psi/msvc.mak

2017-09-12 10:30:01 +0100
Chris Liddell <chris.liddell@artifex.com>
43561187cdb501ac1c6184082065647253d9336c

> Product string and date for release
> base/gscdef.c
> base/version.mak

## Version 9.22 (2017-10-04)

This is the sixteeth full release in the stable 9.x series.

Highlights in this release include:

- Ghostscript can now consume and produce (via the pdfwrite device) PDF 2.0 compliant files.

- The main focus of this release has been security and code cleanliness. Hence many AddressSanitizer, Valgrind and Coverity issues have been addressed.

- The usual round of bug fixes, compatibility changes, and incremental improvements.

For a list of open issues, or to report problems, please visit bugs.ghostscript.com.

### Incompatible changes

- The planned device API tidy (still!) did not happen for this release, due to time pressures, but we still intend to undertake the following: We plan to somewhat tidy up the device API. We intend to remove deprecated device procs (methods/function pointers) and change the device API so every device proc takes a graphics state parameter (rather than the current scheme where only a very few procs take an imager state parameter). This should serve as notice to anyone maintaining a Ghostscript device outside the canonical source tree that you may (probably will) need to update your device(s) when these changes happen. Devices using only the non-deprecated procs should be trivial to update.

### Changelog

2017-10-03 10:01:14 +0100
Chris Liddell <chris.liddell@artifex.com>
dcba89978e3cd6e8e55b44e0830594a385a8e07e

> Bug 698615: pdf_add_ToUnicode() correct size of buffer
> We allocate a buffer to store the Unicode value, but failing to account for
> the fact that the Unicode value is two bytes, rather than a byte
> devices/vector/gdevpdte.c

2017-10-02 16:32:25 +0100
Ken Sharp <ken.sharp@artifex.com>
5751e508f72238c1fcaad1a4c284aa875542dd70

> PDF interpreter - fix default /Decode for Lab images
> When we get an image with no /Decode array we create a default one for
> it by looking at the image colour space.
> For Lab we use the /Range array, but unfortunately this only covers the
> a and b channels, not the L. However, L always ranges from 0 - 100 so
> here we just pull the Range array apart, add in that range, and create
> a new array for the /Decode.
> Resource/Init/pdf_draw.ps

2017-09-28 18:04:20 -0600
Henry Stiles <henry.stiles@artifex.com>
3c2974bcd2e638be13c0ec814342a1a35ca0872b

> Fix buffer overflow regression.
> The commit to address 694653 (3749bc274) was incorrect, the
> font_data_size variable is not necessarily the size of the buffer.
> pcl/pcl/pcsfont.c

2017-09-28 11:35:58 +0100
Chris Liddell <chris.liddell@artifex.com>
b1eda05a9fa7327e76b9a4af980d05da9e926e7f

> Update dates/product for 9.22rc2
> base/gscdef.c
> base/version.mak
> doc/API.htm
> doc/C-style.htm
> doc/Commprod.htm
> doc/DLL.htm
> doc/Deprecated.htm
> doc/Details8.htm
> doc/Details9.htm
> doc/Develop.htm
> doc/Devices.htm
> doc/Drivers.htm
> doc/Fonts.htm
> doc/Helpers.htm
> doc/History1.htm
> doc/History2.htm
> doc/History3.htm
> doc/History4.htm
> doc/History5.htm
> doc/History6.htm
> doc/History7.htm
> doc/History8.htm
> doc/History9.htm
> doc/Install.htm
> doc/Issues.htm
> doc/Language.htm
> doc/Lib.htm
> doc/Make.htm
> doc/News.htm
> doc/Projects.htm
> doc/Ps-style.htm
> doc/Ps2epsi.htm
> doc/Psfiles.htm
> doc/Readme.htm
> doc/Release.htm
> doc/SavedPages.htm
> doc/Source.htm
> doc/Unix-lpr.htm
> doc/Use.htm
> doc/VectorDevices.htm
> doc/WhatIsGS.htm
> doc/Xfonts.htm
> doc/gs-vms.hlp
> doc/sample_downscale_device.htm
> doc/thirdparty.htm
> man/dvipdf.1
> man/gs.1
> man/gslp.1
> man/gsnd.1
> man/pdf2dsc.1
> man/pdf2ps.1
> man/pf2afm.1
> man/pfbtopfa.1
> man/printafm.1
> man/ps2ascii.1
> man/ps2epsi.1
> man/ps2pdf.1
> man/ps2pdfwr.1
> man/ps2ps.1

2017-09-28 10:08:16 +0100
Ken Sharp <ken.sharp@artifex.com>
d59e4b57e1807e934ed1dde51e628f84dfb8caa7

> Documentation - spruce up WhatIsGS.htm
> Remove references to the obselete GhostSVG
> Remove references to MuPDF and MuXPS, MuPDF can easily stand alone now
> and its not really part of the Ghostscript family.
> doc/WhatIsGS.htm

2017-09-27 08:34:10 -0700
Ray Johnston <ray.johnston@artifex.com>
a6830a293f9a69caf50777bb6ee7b553589c0a08

> Revert commit a5a2862d
> Even though the commit fixed bug 695280, we noticed that it caused PS
> and PDF clist image logic to sometimes take the slow "default" handling
> instead of the high-level image path.
> To restore the fix for PCL, we could remove the rop3_uses_T altogether,
> but we don't know if this will impact PCL performance.
> Re-opening bug 695280.
> base/gxclimag.c

2017-09-27 16:35:18 +0100
Ken Sharp <ken.sharp@artifex.com>
c10d5ada53245dac13436d663d3dbe265bc9e11a

> Documentation - remove reference to obselete switch
> Missed this when removing the implementation, PDFDontUseObjectNum is no
> longer supported, so remove it from the documentation.
> doc/VectorDevices.htm

2017-09-26 13:30:16 -0700
Ray Johnston <ray.johnston@artifex.com>
ccaaa1fd02f1cedf221bd6a34e5eb0ef64ef8f3f

> Fix bug 698560. Transparent pattern-clist playback affected target device
> If a transparent pattern was stored as a pattern-clist, changes to the
> pdf14_device during playback were applied to the upper level device, but
> not restored after the playback. This fixes a long standing problem with
> Bug692217.pdf (ELEMENTARY card was to light gray).
> base/gdevp14.c

2017-09-22 16:06:18 +0100
Ken Sharp <ken.sharp@artifex.com>
c470609a95c3ba5d531da463df7a98da01998452

> PDF interpreter - clamp Box to MediaBox, even when MediaBox is negative
> When applying the various 'Box' values from a PDF file, we need to clamp
> them to the MediaBox values, so that we don't try and extend the final
> output to be larger than the Media (this appears to be Acotbat's
> behaviour).
> But we also need to account for the fact that the media (and therefore
> the content) may not lie up and right. Its possible for the media to
> be defined with negative height or width.
> We deal with that by scaling/translating the CTM, but we weren't
> taking it into account when calculating the actual media size, which led
> to us calculating the wrong size.
> This is more complicated, but we only do it once per page, so the
> performance penalty is insignificant.
> Resource/Init/pdf_main.ps

2017-09-22 12:36:22 +0100
Chris Liddell <chris.liddell@artifex.com>
ad87c56e9e88907854d4c37f1a80d8f5d06fb8a7

> Bug 698581: Pscript5Idiom: add missing conditional (and bind)
> One of the procedures which Pscript5Idiom "patches" was missing an ifelse
> meaning, when that idiom was hit, an unexecuted procedure was left on
> the stack.
> For efficiency and consistency, also bind the entire procedure.
> Resource/IdiomSet/Pscript5Idiom

2017-09-22 10:55:10 +0100
Chris Liddell <chris.liddell@artifex.com>
9ae11d7a06c216eae554bcc7696028e69c4bc7ee

> Simpify confusing stack manipulations
> The existing code was not wrong, but did several unnecessary stack manipulations
> that made it less efficient but, more importantly, confusing.
> Also, remove trailing whitespace.
> Resource/Init/pdf_ops.ps

2017-09-21 11:27:37 +0100
Chris Liddell <chris.liddell@artifex.com>
d644437adb7833a2c511d143c13e757383106378

> Remove pointless free
> In an error condition, we were freeing the object that had failed to allocate.
> Not a problem with our memory manager, but might cause confusion reading the
> code (it did for me!).
> base/gdevp14.c

2017-09-21 18:34:32 +0100
Chris Liddell <chris.liddell@artifex.com>
8760a38e4ca49ce403cb362ecb4d6b4d247587f1

> Fix errors with 6b06b8c854
> The stack manipulations with the previous commit were not quite right.
> Resource/Init/pdf_ops.ps

2017-09-19 10:41:21 -0700
Michael Vrhel <michael.vrhel@artifex.com>
cc966e7f9029c27abc896431a3c4910b40d915ef

> Bug 698559 avoid double alpha application
> When we have a softmask present in the graphic state, we
> wrap up the fill or stroke with an isolated transparency
> group in the interpreter. After the group is pushed we
> should set the opacityalpha and the shapealpha to 1 to
> avoid a double application of alpha at the rect-fill level and
> the group composition level.
> Resource/Init/pdf_ops.ps
> base/gxblend1.c

2017-09-21 10:13:16 +0100
Ken Sharp <ken.sharp@artifex.com>
c03add9e9caaa4958928f74a6ca4f2b71915063c

> pdfwrite - fix compiler warnign
> Cast a pointer correctly to avoid a compiler warning.
> devices/vector/gdevpdfe.c

2017-09-20 16:48:27 +0100
Robin Watts <robin.watts@artifex.com>
2285580852e74940a4596b754739ba45a03b40d0

> Fix stroke/fill mismatches in 09-37.PS
> When 'accurate curves' are requested, ensure we use the same
> curve -> line decomposition for both strokes and fills.
> base/gxfill.c

2017-09-20 18:33:52 +0100
Robin Watts <robin.watts@artifex.com>
0803369908a0b4b24b215881e4c4a4ecc5de61c2

> Fix new scan converter glitch with CATX4547.pdf
> Page 11 of this file contains details on the revolvers cylinder
> rendered by filling zero width vertical lines. For example:
> 0.165 0.068 0 0.187 scn
> 506.47 162.99 m
> 506.47 167.99 l
> 506.47 162.99 l
> f
> The new scan converter was incorrectly eliding this. Fixed by
> tweaking the edgebuffer filtering logic for any-part-of-a-pixel
> mode.
> base/gxscanc.c

2017-09-19 18:01:27 +0100
Robin Watts <robin.watts@artifex.com>
03ac50df18eb12d40de1615d18730fdd077f605b

> Fix in*fill etc test files.
> The new scan converter has been assuming that anything with an
> x coord < 0 is off screen. While this is true for almost every
> device I can think of, it need not be true for the hit detection
> device used for infill/instroke operations.
> Fixed to use INT_MIN here.
> base/gxscanc.c

2017-09-20 15:37:19 +0100
Ken Sharp <ken.sharp@artifex.com>
4bb7249ce9320c566da5dac3901c41c7965d37d8

> pdfwrite - fix UTF16 to UTF8 conversion
> There was a signed/unsigned error in the arguments to this routine,
> which meant that bytes with the top bit set caused the whole UTF16
> short to become negative as well.
> Fixed here.
> devices/vector/gdevpdfe.c

2017-09-19 17:43:25 +0100
Chris Liddell <chris.liddell@artifex.com>
f2f9ed2897a4cf166c1df50422b2e82ad2422947

> Write initial device error to stderr
> As the "Unable to open the initial device, quitting." occurs outside the
> Postscript error handling auspices, and causes Ghostscript to quit in a
> possibly unexpected way, write it to stderr rather than stdout.
> Resource/Init/gs_init.ps

2017-09-19 13:59:56 +0100
Ken Sharp <ken.sharp@artifex.com>
5fc5b64a6cd3917326479d3d3a0546dca0feef3c

> PS interpreter - set EPSCrop when EPSFitPage is set
> Bug #698555 "using DEVICE[WIDTH|HEIGHT]POINTS results in blank image"
> The reporter had not set -dEPSCrop which resulted in no PageSize
> request being sent to the interpreter (because EPS files are note
> permitted to set PageSize). Which defeats the use of PageSize Policy
> 13 to scale the page.
> Since anyone using EPSFitPage clearly wants to scale the page to the EPS
> BoundingBox, we may as well set EPSCrop in case they don't.
> NB the original reporter had not set -dFIXEDMEDIA either...
> Resource/Init/gs_init.ps

2017-09-17 18:34:59 +0100
Ken Sharp <ken.sharp@artifex.com>
6e317f178c7fe7c81b573598f848acf8487e4e45

> pdfwrite - properly process Octal 134 '\' in pdfmark UTF16 string
> Bug #698552 "Some PDF outline UTF-16 text is broken"
> The escape processing wasn't catering for an escaped escape '\\' which
> led to us writing the escaped escape direclty and corrupted the remainder
> of the string. We normaly don't use short escapes but write ocral,
> because some versions of Acrobat can't handle the short escapes.
> This commit just processes the '\\' properly, as per the other
> escapes.
> devices/vector/gdevpdfm.c

2017-09-17 11:46:03 +0100
Ken Sharp <ken.sharp@artifex.com>
122808aa46118d483c2fe431d5382c88cdd6e735

> Coverity ID 172798
> We hadn't assigned the return value to the variable 'code' but were
> using it (asigned earlier in the code) to action a return.
> Fixed by actually assigning the value to the variable.
> base/gxshade1.c

2017-09-16 23:34:04 +0100
Ken Sharp <ken.sharp@artifex.com>
087abbc55390499ca27823afbe7d1b62b4ff4f8e

> PDF interpreter - more work on images with invalid /Mask
> Commit 119ec77d4e44e3861a376323ed14466b28b2f4bf fixed one case of a
> /Mask array with invalid values by treating DeviceGray the same as
> /Indexed. However, while that worked for the particular file in question
> (Bug #697919) it caused a regression with Bug689717 which I somehow
> missed at the time.
> This commit treats DeviceGray differently to Indexed spaces and
> clamps the value to either 0 or 1 for 1 BPC images. This seems to work
> as per Acrobat for both files.
> Resource/Init/pdf_draw.ps

2017-09-15 18:24:44 -0500
Robin Watts <Robin.Watts@artifex.com>
f1ccd5e2c82eb137abb7af000e93447653093a4d

> Bug 696399: Fix buffer overflow in image scaling.
> Patch calculation that overflows when x_extent is very
> negative.
> base/gxifast.c

2017-09-15 14:28:28 -0700
Robin Watts <Robin.Watts@artifex.com>
a768ec17b12e44b20d555f3c2fc2c5dcde3d9f0b

> Remove stray memsets left in from previous commit.
> The "Bug 698427: Fix ignoring errors that lead to division by
> zero." commit contained stray memsets.
> base/gxshade1.c

2017-09-15 13:04:06 -0700
Robin Watts <Robin.Watts@artifex.com>
45e4bcf4992c6c22e942730f5df393fc6b4cab63

> Bug 698427: Fix ignoring errors that lead to division by zero.
> By ignoring error return values, we continue running with
> uninitialised data, leading to division by zero.
> base/gxshade1.c

2017-09-15 10:58:11 -0500
Robin Watts <Robin.Watts@artifex.com>
1b18e15f10532d584c6fc2191e1b2a3f8e5ba7e5

> Coverity #135034: Simplify code.
> The while loop is not strictly required (but it does match
> the other cases). Simplified here.
> base/gxscanc.c

2017-09-15 10:47:54 -0500
Robin Watts <Robin.Watts@artifex.com>
6fb9174c1517143158781ed37e0c6d6eb9321808

> Coverity #135037: Fix unused variable.
> Don't read a value we don't use.
> base/gxscanc.c

2017-09-05 14:52:07 +0100
Chris Liddell <chris.liddell@artifex.com>
228ac64b768ac3df1bcd5f63e3f353f8fd01e372

> Coverity ID# 135035
> Remove pointless "upgraded_copypage" code properly.
> The previous commit for this removed code that it should not have done
> base/gdevprn.c

2017-09-15 13:42:00 +0100
Chris Liddell <chris.liddell@artifex.com>
3f9d3e1392236fef4658c8dcad15385670d6831e

> Revert "Coverity ID# 135035"
> This reverts commit 05c3de8915fafb65b96ba0860523a7a79e2577e2.
> base/gdevprn.c

2017-09-14 22:40:30 +0100
Chris Liddell <chris.liddell@artifex.com>
12ff84c1ff077c737b0a194761a370de079943fd

> Remove man pages for removed (obsolete) tools
> (Reported against 9.22 rc1)
> doc/gs-vms.hlp
> man/de/font2c.1
> man/de/wftopfa.1
> man/font2c.1
> man/gs.1
> man/wftopfa.1

2017-09-14 07:01:32 +0100
Chris Liddell <chris.liddell@artifex.com>
7df9b3d9b0dabd9854731fab796d5d458cf743f7

> White space issues reported against 9.22 rc1
> It seems newer gcc versions (6.4.x and later) report indentation "problems".
> Also, add a cast to ensure bitshift op is done on an unsigned value.
> base/gsbitops.c
> base/gsicc_create.c
> base/gxclread.c
> contrib/gdevbjca.c
> contrib/gdevdj9.c
> devices/gdevepsc.c
> pcl/pxl/pxpaint.c
> psi/dscparse.c
> psi/zcrd.c

2017-09-14 06:41:33 +0100
Chris Liddell <chris.liddell@artifex.com>
9e56aafaf2fc8fe3ffeefc0d13fa8c1b033ddec8

> Bug 698532: replace ijs/ltmain.sh symlink with file
> ijs/ltmain.sh

2017-09-13 08:43:38 +0100
Chris Liddell <chris.liddell@artifex.com>
98e115748ec4b16c610396b9444c1d82d263a30c

> Remove reference to old wisc site in Readme.htm
> S
> doc/Readme.htm

2017-09-12 11:17:15 +0100
Ken Sharp <ken.sharp@artifex.com>
4241a4b3a7099cddac36d13f6c67054483eb7511

> Remove unused variable 'pdev' to silence compiler warning
> base/gdevp14.c

2017-09-12 10:32:51 +0100
Chris Liddell <chris.liddell@artifex.com>
85e04afbc2c80c8c6b129aff2741cbdf4d41ff67

> Update docs dates etc for release
> doc/API.htm
> doc/C-style.htm
> doc/Commprod.htm
> doc/DLL.htm
> doc/Deprecated.htm
> doc/Details8.htm
> doc/Details9.htm
> doc/Develop.htm
> doc/Devices.htm
> doc/Drivers.htm
> doc/Fonts.htm
> doc/Helpers.htm
> doc/History1.htm
> doc/History2.htm
> doc/History3.htm
> doc/History4.htm
> doc/History5.htm
> doc/History6.htm
> doc/History7.htm
> doc/History8.htm
> doc/History9.htm
> doc/Install.htm
> doc/Issues.htm
> doc/Language.htm
> doc/Lib.htm
> doc/Make.htm
> doc/News.htm
> doc/Projects.htm
> doc/Ps-style.htm
> doc/Ps2epsi.htm
> doc/Psfiles.htm
> doc/Readme.htm
> doc/Release.htm
> doc/SavedPages.htm
> doc/Source.htm
> doc/Unix-lpr.htm
> doc/Use.htm
> doc/VectorDevices.htm
> doc/WhatIsGS.htm
> doc/Xfonts.htm
> doc/gs-vms.hlp
> doc/sample_downscale_device.htm
> doc/thirdparty.htm
> man/dvipdf.1
> man/font2c.1
> man/gs.1
> man/gslp.1
> man/gsnd.1
> man/pdf2dsc.1
> man/pdf2ps.1
> man/pf2afm.1
> man/pfbtopfa.1
> man/printafm.1
> man/ps2ascii.1
> man/ps2epsi.1
> man/ps2pdf.1
> man/ps2pdfwr.1
> man/ps2ps.1
> man/wftopfa.1
> psi/int.mak
> psi/msvc.mak

2017-09-12 10:30:01 +0100
Chris Liddell <chris.liddell@artifex.com>
43561187cdb501ac1c6184082065647253d9336c

> Product string and date for release
> base/gscdef.c
> base/version.mak

2017-09-12 10:14:45 +0100
Ken Sharp <ken.sharp@artifex.com>
56ca27c9a95d7917baebd42b04cb08be872d1e39

> PDF interpreter - handle invalid XRefStm in hybrid PDF file
> Bug #698519 "Invalid XRefStm exits with error"
> Just wrap the 'readpdf15xref pop' in a stopped if the user has not set
> PDFSTOPONERROR, also add mark/cleartomark to clean up the stack.
> Resource/Init/pdf_main.ps

2017-09-11 09:30:59 -0700
Ray Johnston <ray.johnston@artifex.com>
a1cd439519aa07b5f70b1b044342d90377c1188e

> Coverity ID 94477 and 158386
> 94477 suggests a potential access (as an array pcc[i]) past the singelton
> address which could occur if pgs->color_component_map.num_components > 1
> Copy the "all" value to an array to prevent the issue.
> 158386 was a mistake, fixed. Two differences show up with bitrgbtags, but
> they look the same to me.
> tests_private/comparefiles/Altona_Technical_v20_x4.pdf
> tests_private/comparefiles/eci_altona-test-suite-v2_technical2_x4.pdf
> base/gdevp14.c

2017-09-11 16:22:29 +0100
Ken Sharp <ken.sharp@artifex.com>
9e92e379d04979de614bbdb89a0af5f4aff187cb

> Coverity ID 107344 and 107345, again....
> When testing the return value from ftell() don't assign it to an
> unsigned int....
> Warning from clang this time
> devices/gdevgprf.c

2017-09-11 09:31:52 +0100
Ken Sharp <ken.sharp@artifex.com>
49d8d66c80d04bd7bfcae0c50e31b18355408e71

> Coverity ID 94485 revisited
> another place to check that fw is not negative. Missed the fact there
> were two instances with the first commit.
> devices/minftrsz.c

2017-09-11 09:31:01 +0100
Ken Sharp <ken.sharp@artifex.com>
954ed1df4b60bd9b3fc57b56cb7503cb950e05b9

> Coverity IDs 107344, 107345 revisited
> Check return values from ftell() as well as fseek()
> devices/gdevgprf.c

2017-09-11 08:22:41 +0100
Ken Sharp <ken.sharp@artifex.com>
988e56308515118b723d868e50e8b5836d43f803

> Coverity ID 171512
> Check return values from seek and propagate errors if encountered.
> pcl/pl/plparams.c

2017-09-11 08:20:27 +0100
Ken Sharp <ken.sharp@artifex.com>
c35b385f02e007fe1edf086d8b5175af4a9836f9

> Coverity IDs 171513 and 171514
> prevent potential divide by zero errors. Instead, propagate error
> return codes.
> base/gen_ordered.c

2017-09-10 12:40:14 -0700
Ray Johnston <ray.johnston@artifex.com>
d94fd9bd9cb69a998c812eb2f04fdc0083895ae5

> Adjust .genordered 50% gray level to be on an desirable boundary
> Customer needs 50% gray level with 45 degree Angle and DotShape 8
> to be a checkerboard pattern with no stray dots. Add a check to force
> the step at 50% to be an even number of dots. Tested for Frequency
> from 30 to 150 (at 600 dpi).
> psi/zht2.c

2017-09-07 15:38:19 +0100
Ken Sharp <ken.sharp@artifex.com>
dc8eb2a822bda44aab546e0bf7a0e35e3115696b

> Coverity ID 94999
> I don't believe its actually possible to end up at the if (swap)
> without setting run, because the few cases in the switch where we
> don't set run, we go back to the top, swap the source and texture,
> and then do the switch again, so somehow we will end up setting run
> But its cheap to initialise it, and it will silence Coverity, and it
> guards against any possible future problem.
> base/gsroprun.c

2017-09-05 16:53:52 +0100
Chris Liddell <chris.liddell@artifex.com>
ff5828a537fbf8b58095f5147b2acd59a6330941

> Compiler warning: discaring const
> The fix for coverity ID# 127201 introduced a compiler warning due to an
> accessor macro (ctm_only) implicitly adding const. Make the local variable
> const, too.
> base/gxipixel.c

2017-09-05 15:46:03 +0100
Chris Liddell <chris.liddell@artifex.com>
6846f1d5d8c7f5512fc385b3b9e2fa95cc720c53

> Coverity ID# 94891
> Add a cast to make integer division explicit.
> base/gsdparam.c

2017-09-07 13:35:35 +0100
Ken Sharp <ken.sharp@artifex.com>
534257c41de66f040fa548b47f2bf5950cb5a3cb

> Coverity ID 94819
> No structural changes, just change a couple of pointer type declarations
> I think this should satisfy Coverity and there doesn't seem to be any
> actual problem here.
> base/gxclthrd.c

2017-09-07 12:11:47 +0100
Ken Sharp <ken.sharp@artifex.com>
f12500705c692b0ad51156081901fcd3457a5601

> Coverity ID 158370
> Again we shouldn't be able to get to the flagged code with 'raster'
> being uninitialised, because 'data', which is initialised to 0 would
> have to be updated, and that would mean raster was updated as well.
> But since we already initialise data its cheap to initialise raster too.
> base/gximag3x.c

2017-09-07 11:36:59 +0100
Ken Sharp <ken.sharp@artifex.com>
627b0c8a1228830917bb2420edb4613550dd4ef1

> Coverity ID 94819
> The comments on clist_end_page() state that it returns negative for an
> error, 0 for success and positive for success with a low memory warning.
> In fact it always returns 0.
> This means we don't conform to the comments, and discard any errors that
> occur.
> This commit reformats the code to reduce the number of tests and to
> store the error codes, as well as adding the potential to return
> something other than 0.
> base/gxclist.c

2017-09-07 10:09:04 +0100
Ken Sharp <ken.sharp@artifex.com>
be04e2ac2389e6fcc2ccf7b50434678c7aefa19d

> Coverity ID 94571
> Its not obvious whether raster can ever be 0 here, it clearly never is
> during our tests, and I think it should not be possible, but just in
> case we'll guard the division with a check.
> base/gsimage.c

2017-09-07 08:51:31 +0100
Ken Sharp <ken.sharp@artifex.com>
24bbc1ed3d0553964dd5086b08062442071e4ef5

> Fix memory leak
> An error exit would leave 'filter' and 'screen_blur' allocated, and
> therefore a memory leak.
> base/gen_ordered.c

2017-09-06 15:51:33 -0700
Ray Johnston <ray.johnston@artifex.com>
30e336aee9812ca3610931f86ea641d82022c8ca

> Second fix for missing FULL_FILE_NAME_LENGTH
> Previous commit fixed the RAW_SCREEN_DUMP=1 case, but broke the normal
> case. Also added #ifndef RAW_SCREEN_DUMP around the setting in gen_odrered.h
> so that the preprocesor flag could be set via the command line.
> Lastly, add base/gen_ordered.h to the Headers section of the .vcproj
> base/gen_ordered.h
> toolbin/halftone/gen_ordered/gen_ordered.vcproj

2017-09-06 14:23:05 -0700
Ray Johnston <ray.johnston@artifex.com>
a92188b76f30c5840ce8b0716e5c70e9791fb6eb

> Fix RAW_SCREEN_DUMP for gen_ordered standalone
> In refactoring, I missed that FUL_FILE_NAME_LENGTH was needed if
> RAW_SCREEN_DUMP was > 0 (RAW_SCREEN_DUMP is #define'd in genordered.h,
> so put the definition there.).
> base/gen_ordered.h
> toolbin/halftone/gen_ordered/gen_ordered_main.c

2017-09-06 19:08:24 +0100
Ken Sharp <ken.sharp@artifex.com>
6b085aa479bcf0c8cb426c0b51fe7f98faba72ff

> Coverity ID 94886
> Remove a NULL pointer check, there's no possible way the pointer
> can be NULL at this point. Or if there is, its because a NULL
> pointer was passed in as an argument, and we will seg fault earlier
> in this function anyway, so no point in checking it here.
> base/gxfill.c

2017-09-06 19:06:22 +0100
Ken Sharp <ken.sharp@artifex.com>
754e99239371ec4aa06a9728ae65028ac22c440c

> Coverity ID 94627
> Guard the dereference of pdht with a NULL pointer test, to avoid a
> potential seg fault.
> base/gxdevndi.c

2017-09-06 16:31:48 +0100
Ken Sharp <ken.sharp@artifex.com>
6857ef647312daa24eb47417b09d823e8b59831d

> Coverity ID 141334
> Add some error checking
> base/gxclip.c

2017-09-06 15:58:28 +0100
Ken Sharp <ken.sharp@artifex.com>
198924f4c94c561543f5838900e21ed761a886a5

> Coverity ID 95001
> We can only get back here by jumping to the label 'top'. ymax is not
> used between this point and the last 'goto top', and it is then
> recalculated before being used.
> So the assignment is indeed pointless.
> base/gxacpath.c

2017-09-06 15:11:56 +0100
Ken Sharp <ken.sharp@artifex.com>
0808c9eec2a92db3176b3eac0520f48a2119ddf9

> Coverity IDs 164020, 164022, 164025
> We don't need to check if dot_grid.data is NULL.
> Testing a == 0 && b == 0 after testing a nd b individually can't be
> correct. Test for both being zero first.
> In the case of an error, we could attempt to free memory that had not
> been allocated. Prevent this by checking dot_level_pos is non-NULL.
> base/gen_ordered.c

2017-09-06 14:37:21 +0100
Ken Sharp <ken.sharp@artifex.com>
05768db75e90f56c6fda33c9c14515a3e0b6aeaa

> Addition to commit 18f009a08f1eac4708188b516d375356a502a3b1
> Forgot to initialise the pointer to NULL before starting.
> base/gdevp14.c

2017-09-06 10:03:40 +0100
Ken Sharp <ken.sharp@artifex.com>
18f009a08f1eac4708188b516d375356a502a3b1

> Coverity IDs 138751, 141130, 141131, 158373
> 138751 - The code assumes that a separating device has an ICC profile
> but doesn't check. Add a check and return an error if it doesn't.
> 141130 - initialise a structure member
> 141131 - check and action return codes
> 158373 put #if DEBUG round some code that's only present to provide a
> breakpoint location in debuggers. (and told Coverity to ignore this)
> base/gdevp14.c

2017-09-05 15:28:19 +0100
Chris Liddell <chris.liddell@artifex.com>
61856e04852124491a47fa6379f1c3ad296f3366

> Coverity ID# 122660
> NULL pointer check - the code branch above already does so, looks like a simple
> ommission
> base/gxiscale.c

2017-09-05 15:21:23 +0100
Chris Liddell <chris.liddell@artifex.com>
1b9ea22b3456a24e356d3f5a68036cecbb28af56

> Coverity ID# 126580
> Explicitly promote an unsigned char value to a long.
> base/gxclrect.c

2017-09-05 15:12:09 +0100
Chris Liddell <chris.liddell@artifex.com>
28e95004b508a3f4cd73552d92f7f4cd699c645b

> Coverity ID# 127201
> Fix potential NULL pgs (graphics state) pointer dereference. I suspect this can
> never occur, but it's cheap and should silence coverity
> base/gxipixel.c

2017-09-05 14:52:07 +0100
Chris Liddell <chris.liddell@artifex.com>
05c3de8915fafb65b96ba0860523a7a79e2577e2

> Coverity ID# 135035
> Remove pointless "upgraded_copypage" code.
> base/gdevprn.c

2017-09-05 14:18:10 +0100
Ken Sharp <ken.sharp@artifex.com>
9a6045cc4c7843ee8608c1d4a2fb76e8a10a6581

> Coverity ID 95054
> Explicitly initialise a member of the new 'order' structure.
> base/gxdhtserial.c

2017-09-05 13:36:45 +0100
Chris Liddell <chris.liddell@artifex.com>
7dd033589ce40649ab602fba4c0473aa40c48439

> Bug 698471: apply vertical substitute glyphs in TTF fonts
> We weren't applying vertical glyph substition (from the gsub table).
> base/gstype42.c
> psi/zfapi.c

2017-09-05 13:23:24 +0100
Chris Liddell <chris.liddell@artifex.com>
f753769041467a1c88084d6d26c2755d7174691d

> Bug 698486: memory leaks from fontconfig calls
> Address most of the memory leaks stemming from the use of fontconfig.
> In this case, just destroying the fontconfig context.
> base/gp_unix.c

2017-09-04 09:39:18 +0100
Chris Liddell <chris.liddell@artifex.com>
8b249d3ebd8058f2961770e21c72e1ac703cc12f

> Coverity ID 139142: etc.c modulo by zero
> Only calculate tmline when it will actually be used. The calculation uses
> y % tmheight, but only the ETS_RSTYLE_THRESHOLD case is called with
> tmheight != 0
> base/ets.c

2017-09-05 12:16:38 +0100
Ken Sharp <ken.sharp@artifex.com>
463854833474dc3ae642e17707e50c451ada1fec

> Coverity ID 94994
> Check a return value and action it.
> base/gxp1fill.c

2017-09-05 11:41:38 +0100
Ken Sharp <ken.sharp@artifex.com>
aa75f905024bdf13882c30e543d64e285e22aad1

> Coverity ID 158395
> I think its not currently possible to trigger this, as it would require
> setting up the device pointer incorrectly before entering this routine.
> However Coverity is correct that it appears possible to end up doing
> a NULL pointer dereference, so add a guard to maek sure that can't
> happen.
> base/gzspotan.c

2017-09-05 10:45:14 +0100
Ken Sharp <ken.sharp@artifex.com>
06b5a54361525363bdc163b88f965f0d1a295087

> Coverity ID 94914
> Remove an unnecessary copy of a variable, its unconditionally
> overwritten immediately after. Comment that.
> base/sfilter2.c

2017-09-05 09:58:24 +0100
Ken Sharp <ken.sharp@artifex.com>
3f40707f85296c0abf798c9c32c79db33affbddc

> Coverity IDs 94554 and 94551
> We weren't checking the return values from gp_fseek_64 or fstat() and
> in a couple of places weren't even able to return an error anyway
> (void function).
> So check the error returns from the C run-time and add error handling
> as required in order too report these.
> base/sfxcommon.c
> base/sfxstdio.c
> base/stream.h

2017-09-04 19:02:39 +0100
Ken Sharp <ken.sharp@artifex.com>
ac6c349f54b09df7b2f8cf606b8fe7e62291c2e0

> Coverity ID 94959
> We were failing to free a couple of allocated buffers in the event of an
> error. The other error test all free both buffers properly.
> devices/rinkj/rinkj-epson870.c

2017-09-04 17:26:45 +0100
Ken Sharp <ken.sharp@artifex.com>
a11bd1f982f8a8491a4c1ab45aa5535426d01dca

> Coverity IDs 94868, 94936, 158371
> Initialise some arrays, these are sparsely populated by the code and
> potentially possible to access uninitialised data.
> devices/rinkj/evenbetter-rll.c

2017-09-04 17:01:14 +0100
Ken Sharp <ken.sharp@artifex.com>
538f12d7bdd292c4798161a5d49ba2f3bcfebbe3

> Alter the fix for Coverity ID 94726
> Ray objected to my original change, because the debug output would not
> be a valid file. So instead we choose to lose the information that
> logbits2 is non-zero and drop the if clause.
> devices/gdevplib.c

2017-09-04 16:57:32 +0100
Ken Sharp <ken.sharp@artifex.com>
e0d49f799157f2d0ba1ea4969cc225a15d108cf7

> Coverity IDs 94478 and 94485
> The first is a clear typo, the code below this point is the same as the
> code modified in this commit.
> The second one is less clear, but I think its reasonable, if there is
> no '0' (-1 return from next_zero()) then we can't make the feature
> larger by darkening to the right, so darken to the left.
> devices/minftrsz.c

2017-09-04 16:27:32 +0100
Ken Sharp <ken.sharp@artifex.com>
f7d9662c5737d42942dbe1f5d4e74a9d00838b56

> Coverity ID 94479
> The macro used here says it shouldn't be used for run-time calculations.
> However this code does use it, I'm not certain for what purpose. Since
> it clearly is possible to get a negative shift, add a guard to the
> values to make sure that can't happen.
> Since this code is conditionally compiled out, anyone who compiled it
> in and finds a problem can easily fix it.
> devices/gdevxcmp.c

2017-09-04 15:56:29 +0100
Ken Sharp <ken.sharp@artifex.com>
0462b654d8a57688c1b811a4e04ad8a7aaf0dab9

> Coverity ID 127202
> Check the stored graphics state and if its 0, use the default method.
> Remove the now redundant later check on pgs being 0 before use.
> devices/gdevx.c

2017-09-04 15:16:42 +0100
Ken Sharp <ken.sharp@artifex.com>
2c5d0e0970e60d9d4c61865d61fb39629dfd6623

> Coverity IDs 94503, 94506, 94523, 94536
> A number of pointless comparisons, checking that a signed 32-bit variable
> had a value less than the maximum for a signed 32-bit integer.
> Remove them all.
> devices/gdevupd.c

2017-09-04 14:32:22 +0100
Ken Sharp <ken.sharp@artifex.com>
ae7f71a161803d10f263585e8b2e5087835f51b8

> Coverity IDs 94719, 94889, 94912, 94967, 95088, 101187
> Return an error instead of storing it (where it gets lost)
> As per gdevpsd.c and gdevprf.c refactor the #if conditional compiled
> code to remove a variable and get rid of Coverity warning.
> In the 'build_cmyk_raster_line_fromplanar* routines, pass the params as
> a pointer instead of copying the whole 500+ byte structure around.
> Finally, not a Coverity warning but a compiler warning; remove an unused
> variable.
> devices/gdevtsep.c

2017-09-04 13:47:16 +0100
Ken Sharp <ken.sharp@artifex.com>
413cefabb9888c0810e1c4c23e603fa4e69c7c1d

> Coverity IDs 94856 and 94719
> If we get an error from param_read_name, then just return it.
> The AddLut lookup is less obvious. Clearly the size of the LUT read from
> the config file should not be less than 0, but there's no clear upper
> limit (other than an unsigned integer). However a 4Gb config file seems
> unlikely. The only example we have has ~23 values for each plane, so a
> limit of 256 entries seems reasonable. If anyone complains its easy to
> increase and we can ask the user what a reasonable limit should be.
> devices/gdevrinkj.c

2017-09-04 13:12:27 +0100
Ken Sharp <ken.sharp@artifex.com>
1cf6a2a71851e507716bd5c82c8c991239ac04e0

> Coverity ID 94728
> As with gdevgprf.c, refactor the #if conditional compilation so that we
> don't need a variable, and remove the Coverity warning.
> devices/gdevpsd.c

2017-09-04 12:12:06 +0100
Ken Sharp <ken.sharp@artifex.com>
cdceb9e93516264fcdae965e5eeb0e733bad76ee

> Coverity IDs 94596, 94726
> A debug print was identical in both the if and else clauses. Not really
> important since its debug, but change the else to match others of the
> same type.
> line_ptrs was calculated and altered in the loop invocation, but its
> then immediately overwritten in the loop body, making it pointless.
> devices/gdevplib.c

2017-09-04 11:29:50 +0100
Ken Sharp <ken.sharp@artifex.com>
11e90b8945a54e4e16c702a4ba4ed19cef47f4a2

> Coverity ID 158390
> Since line is recalculated inside the loop on every iteration, there's
> no point in calculating it in the loop definition.
> devices/gdevphex.c

2017-09-04 10:47:04 +0100
Ken Sharp <ken.sharp@artifex.com>
615d7caf21e957fe3716ef9264def280df20beb7

> Coverity IDs 121444, 121445, 121449
> More problems with intermediate promotion to int, probably caused when
> gx_color_index went from 32 to 64 bits.
> devices/gdevpbm.c

2017-09-04 10:29:55 +0100
Ken Sharp <ken.sharp@artifex.com>
65ef52484c9a973f5fcb72b258cf1bf5a4653a75

> Coverity ID 158391
> Initialise 'backtable'. The code does later fill in some entries in
> backtable, but it doesn't fill all of them and I can see no coherence
> between the filling in code and the code that reads data from it. It
> really does look like its possible to read uninitialised data here.
> devices/gdevmgr.c

2017-09-03 17:14:41 +0100
Ken Sharp <ken.sharp@artifex.com>
5f73a2c82f0cbd0d0965709066ebdf13cc0b9c9d

> Coverity ID 94489
> The spec says that it must be 3 bytes, and uses a 16 bit shift example
> (suggesting it is stored in the Brother driver as 24 bits).
> For us its a short, so rather than copy the brother code, set it to 0 to
> avoid any confusion over whether shifting a short right by 16 results in
> all 0 or all 1.
> devices/gdevhl7x.c

2017-09-03 11:48:54 +0100
Ken Sharp <ken.sharp@artifex.com>
4e122728ecf07941e15f75fc7feaec57eeb54e90

> Coverity IDs 107340, 107341, 107343, 107344, 107345, 121455
> Considerable rework of error checking in this device.
> Firstly add error return checks on fseek and fwrite. Alter functions to
> return those errors. Alter the parent functions to check the errors,
> repeat until we bubble up to the top level.
> Coverity claims that ftell() can return a negative value, which as far
> as I can see is not true. However, by casting the return value to an
> unsigned type, and altering the variable types appropriately, I think
> we should eliminate this warning.
> Refactor conditionally compiled code to eliminate a variable and get
> rid of a dead code warning.
> devices/gdevgprf.c

2017-09-02 18:31:11 +0100
Ken Sharp <ken.sharp@artifex.com>
18d430f97d95d5919fb9ea06b63423c8367548b9

> Coverity ID 94722
> Change the way memory allocation and free'ing is done so that we no
> longer check row_first, which is always 0. THis should mean that we
> don't need to check min_feature_data before passing it to
> min_feature_size_process(), it is allocated in min_feature_size_init()
> and we do actually now check the return value from there to ensure
> there are no errors which could leave min_feature_data uninitialised.
> devices/gdevfax.c

2017-09-02 17:19:00 +0100
Ken Sharp <ken.sharp@artifex.com>
4b07f41941f75fc54cd6937ff18426402ab9af36

> Coverity IDs 94575 and 94722
> Remove some dead code, refactor and add error checking to avoid a NULL
> pointer dereference
> devices/gdevdjtc.c

2017-09-02 16:33:06 +0100
Ken Sharp <ken.sharp@artifex.com>
6a4506040593416d23930049e41e806336335e67

> Coverity ID 94526
> Add some error checking on file handling, and report ioerrors if they
> fail.
> devices/gdevdfax.c

2017-09-02 15:09:25 +0100
Ken Sharp <ken.sharp@artifex.com>
998dd6a53f17104decc8533d5978023fdd008c21

> Coverity ID 94814 and 94980
> I wasn't able to find a way to reproduce this, because it relies on
> a particular sequence of lines/points. We must fill the data buffer to
> the point where another line or curve will not fit, and then the next
> curve or line must be a 'POINTS_NONE'.
> In this case we will not flush the accumulated points, which means we
> will not reset the counter, but we will then still go on to save the
> current co-ordinates in the data buffer, which will cause an overflow.
> Fixed by reducing the 'full' check slightly, so that we still have one
> line/curve slot open in the data buffer. If we get a POINTS_NONE then
> we check to see if we have already gone past the slop. If we have, simply
> reduce the counter by one which will cause us to overwrite the previous
> points. Since this must have also been a POINTS_NONE, this just means
> in effect that we have combined consecutive ones.
> I'm not certain its even possible to get consecutive POINTS_NONE, but
> its best to be safe.
> This should silence Coverity, and fixes the genuine (if hard to
> reproduce) potential problem.
> devices/vector/gdevpx.c

2017-09-02 11:02:23 +0100
Ken Sharp <ken.sharp@artifex.com>
3a98b6855660c84b2fa5529cc25bdbdc4b2b9d7a

> Coverity ID 94943
> I think this code is incorrect, because this routine *always* maps
> CMYK to CMYK, so there's no need to test the colour depth.
> Also, it always gets provided with a CMYK buffer, not an RGB one so it
> actually can't write off the end of the buffer. But the declaration
> was wrong, so fix that here to avoid the warning.
> devices/gdevcdj.c

2017-09-02 10:55:51 +0100
Ken Sharp <ken.sharp@artifex.com>
065b5cc15cea365c3fa5a1f3133416a0db228082

> Coverity ID 95019
> This code was unreachable, its even commented as such. So lets just
> remove it.
> devices/gdevcdj.c

2017-09-02 10:54:06 +0100
Ken Sharp <ken.sharp@artifex.com>
a48211dc97ef345261e7e9a08818dd274b07040e

> Coverity ID 94736
> Guard against a NULL pointer dereference. If we didn't recognise the
> pritner type, then it was possible to attempt to use a NULL pointer.
> devices/gdevcdj.c

2017-09-02 10:50:34 +0100
Ken Sharp <ken.sharp@artifex.com>
77fae933e126cb3b3aad9faa30a659294ed8a44a

> Coverity ID 94708
> The original code in here was correctly noted by Coverity as being
> dead, because the division by BJC_RESOLUTION_BASE meant that we were
> always comparing 0 with 0.
> In addition, the use of bit shifting meant that the resolution wasn't
> tested against a simple multiple of 90 dpi, but against powers of 2
> times 90 dpi, which rapidly led to ridiculous values.
> I'm not certain what the original limits should have been here, and
> I don't have a bjc device to test against, but the code as it stood was
> clearly incorrect, and this at least stands some chance or working.
> devices/gdevcdj.c

2017-09-02 10:28:44 +0100
Ken Sharp <ken.sharp@artifex.com>
1e6e40715f9038b177cf4649945af38b4b21e83c

> Coverity ID 121443
> This was supposed to be in the earlier commit but somehow fell off...
> devices/vector/gdevpx.c

2017-09-02 09:59:30 +0100
Ken Sharp <ken.sharp@artifex.com>
f2a4735118b9558a76adf46e7bb6f814a74ffb38

> Coverity ID 94703
> param_string_from_string cannot return an error so don't try to
> check it.
> devices/vector/gdevpx.c

2017-09-02 09:51:33 +0100
Ken Sharp <ken.sharp@artifex.com>
ca09b00d27d7a855c0e7cbf55c26b5e287262cca

> Coverity IDs 121437, 121438 and 121443
> Not certain if these are really a potential problem, but a type cast
> safely resolves any potential for error.
> I suspect this is a hang over from when gs_color_index was a 32-bit
> value instead of 64.
> devices/vector/gdevpx.c

2017-09-02 09:40:14 +0100
Ken Sharp <ken.sharp@artifex.com>
34ac92ae1741e4d8573162efbd25520bc8796424

> pdfwrite - remove unused code
> This code was left over from transfer function the /Apply work, but is
> no longer used. It was also raising warnings with scan-build and
> didn't work properly anyway (which is why its unused).
> So remove it.
> devices/vector/gdevpsdf.h
> devices/vector/gdevpsdi.c
> devices/vector/gdevpsds.c
> devices/vector/gdevpsds.h

2017-08-31 16:11:15 +0100
Ken Sharp <ken.sharp@artifex.com>
4129543f9f51ccaf97d8429a9e66e348394e95b0

> PDF interpreter - add support for Choice fields in Widget annotations
> Bug 698461 "PDF files with filled forms are not rendered correctly if they have drop-down lists"
> We didn't support Choice fields in either AcroForms or Widget annotations
> which leads to these not being rendered if they have no Appearance (in
> the case of widget annotations) or not rendered at all in the case of
> AcroForms.
> This commit adds simple support for single selection Choice fields, we
> may want to improve this later.
> Resource/Init/pdf_draw.ps
> devices/vector/gdevpsds.c

2017-08-30 16:36:20 +0100
Chris Liddell <chris.liddell@artifex.com>
e547f2490aa40a4f8e35bb15e6815e7d6f1be22a

> clang warning in color mapping code
> We were bit shifting -1 (i.e. -1 << x) which is, strictly speaking undefined.
> Where what was meant was meant was -(1 << x).
> base/gxcmap.c

2017-08-30 16:28:08 +0100
Chris Liddell <chris.liddell@artifex.com>
dafd08a54332f66760b8d667a4b59f42bd4edf1f

> clang warnings in the TTF code.
> There was a type mismatch: we were using a boolean to track if an error had
> occurred, but in most places we were treating it as a gs error code (int type).
> Change the type to int, and tweak the couple of places where it was treated as
> a bool.
> base/gxttfb.c
> base/gxttfb.h

2017-08-25 10:54:42 +0100
Chris Liddell <chris.liddell@artifex.com>
ff70cedd80fd037414abb8a17cd1988d92da2ad6

> This is a combination of 7 commits.
> from the openjpeg-2.2.0-update branch
> 1) OpenJPEG 2.2.0 initial commit
> 0b5fc7368721af148d85ef8dac2e018de10cfe91
> 2) Zap the openjpeg stuff we don't need
> e90bbccd19cb266b55de28ebfd16d024b6e67373
> 3) Add predefined openjpeg headers.
> 71242c9a04bb76b8b17fc489d62a91d04c1ad60c
> 4) Import patches from Sumatra's tree.
> 8b89e4b5750069172522ecf85e69d094b5e567e7
> 5) update makefiles, interface and vcproj files for new openjpeg version
> 456cbe1c76659b0ab022f6ca3f67cc63b253b05f
> 6) Avoid getenv call in openjpeg
> 202a0318a7b3a397fcd5d015dcad4293474f464c
> 7) Bug 698135: Import security fix for OpenJPEG
> 8057698a5f7833499fdf8d2529162841920e354a
> base/openjpeg.mak
> base/sjpx_openjpeg.c
> openjpeg/.gitignore
> openjpeg/.travis.yml
> openjpeg/CHANGELOG.md
> openjpeg/NEWS.md
> openjpeg/THANKS.md
> openjpeg/src/CMakeLists.txt
> openjpeg/src/lib/openjp2/CMakeLists.txt
> openjpeg/src/lib/openjp2/bench_dwt.c
> openjpeg/src/lib/openjp2/bio.c
> openjpeg/src/lib/openjp2/bio.h
> openjpeg/src/lib/openjp2/cidx_manager.c
> openjpeg/src/lib/openjp2/cidx_manager.h
> openjpeg/src/lib/openjp2/cio.c
> openjpeg/src/lib/openjp2/cio.h
> openjpeg/src/lib/openjp2/dwt.c
> openjpeg/src/lib/openjp2/dwt.h
> openjpeg/src/lib/openjp2/event.c
> openjpeg/src/lib/openjp2/event.h
> openjpeg/src/lib/openjp2/function_list.c
> openjpeg/src/lib/openjp2/function_list.h
> openjpeg/src/lib/openjp2/image.c
> openjpeg/src/lib/openjp2/image.h
> openjpeg/src/lib/openjp2/indexbox_manager.h
> openjpeg/src/lib/openjp2/invert.c
> openjpeg/src/lib/openjp2/invert.h
> openjpeg/src/lib/openjp2/j2k.c
> openjpeg/src/lib/openjp2/j2k.h
> openjpeg/src/lib/openjp2/jp2.c
> openjpeg/src/lib/openjp2/jp2.h
> openjpeg/src/lib/openjp2/libopenjp2.pc.cmake.in
> openjpeg/src/lib/openjp2/mct.c
> openjpeg/src/lib/openjp2/mct.h
> openjpeg/src/lib/openjp2/mqc.c
> openjpeg/src/lib/openjp2/mqc.h
> openjpeg/src/lib/openjp2/mqc_inl.h
> openjpeg/src/lib/openjp2/openjpeg.c
> openjpeg/src/lib/openjp2/openjpeg.h
> openjpeg/src/lib/openjp2/opj_clock.c
> openjpeg/src/lib/openjp2/opj_clock.h
> openjpeg/src/lib/openjp2/opj_codec.h
> openjpeg/src/lib/openjp2/opj_common.h
> openjpeg/src/lib/openjp2/opj_config.h
> openjpeg/src/lib/openjp2/opj_config.h.cmake.in
> openjpeg/src/lib/openjp2/opj_config_private.h
> openjpeg/src/lib/openjp2/opj_config_private.h.cmake.in
> openjpeg/src/lib/openjp2/opj_includes.h
> openjpeg/src/lib/openjp2/opj_intmath.h
> openjpeg/src/lib/openjp2/opj_inttypes.h
> openjpeg/src/lib/openjp2/opj_malloc.c
> openjpeg/src/lib/openjp2/opj_malloc.h
> openjpeg/src/lib/openjp2/opj_stdint.h
> openjpeg/src/lib/openjp2/phix_manager.c
> openjpeg/src/lib/openjp2/pi.c
> openjpeg/src/lib/openjp2/pi.h
> openjpeg/src/lib/openjp2/ppix_manager.c
> openjpeg/src/lib/openjp2/raw.h
> openjpeg/src/lib/openjp2/t1.c
> openjpeg/src/lib/openjp2/t1.h
> openjpeg/src/lib/openjp2/t1_generate_luts.c
> openjpeg/src/lib/openjp2/t1_luts.h
> openjpeg/src/lib/openjp2/t2.c
> openjpeg/src/lib/openjp2/t2.h
> openjpeg/src/lib/openjp2/tcd.c
> openjpeg/src/lib/openjp2/tcd.h
> openjpeg/src/lib/openjp2/tgt.c
> openjpeg/src/lib/openjp2/tgt.h
> openjpeg/src/lib/openjp2/thix_manager.c
> openjpeg/src/lib/openjp2/thread.c
> openjpeg/src/lib/openjp2/thread.h
> openjpeg/src/lib/openjp2/tls_keys.h
> openjpeg/src/lib/openjp2/tpix_manager.c
> windows/ghostscript.vcproj

2017-08-31 09:40:51 +0100
Ken Sharp <ken.sharp@artifex.com>
d1dbe825e2fefed1156d0f5e02e6b4d5f20a7781

> pdfwrite - address compiler warnings
> A couple of benign compiler warnings, assigning to an unused variable
> Also add some white space because the construction seems to confuse
> scan-build.
> devices/vector/gdevpdfg.c
> devices/vector/gdevpsds.c

2017-08-30 15:36:10 +0100
Ken Sharp <ken.sharp@artifex.com>
794c559e34192d96b772950f854600add9c86651

> PDF interpreter - make sure Stamp appearance synthesis cannot have 0 scale
> One of the new PDF 2.0 Quality Logic files exhibited a problem with
> synthesising a missing Appearance for some Stamp annotations; the
> scale factor could be calculated as 0.
> This commit makes the minimum scale value 1
> Resource/Init/pdf_draw.ps

2017-08-30 10:18:19 +0100
Ken Sharp <ken.sharp@artifex.com>
782ca576c8582457b063481a4315f7b767ec4546

> PDF interpreter - fix implementation of HTO
> I implemented HTO by using the existing sethalftonephase without an
> example to look at. It turns out that sethalftonephase uses
> .setscreenphase which expects three integers while HTO consists of
> an array of 2 reals.
> We already manufacture the third integer (the texture) and use aload to
> extract the two reals. This commit uses transform to apply the CTM and
> then cvi to convert the HTO numbers to something that makes a difference
> and is legal.
> Fixes the error and the resulting file (rendered at 1bpp) does show a
> difference in the halftone at 300 dpi or better.
> Resource/Init/pdf_draw.ps

2017-08-29 14:04:28 +0100
Ken Sharp <ken.sharp@artifex.com>
050f12a7c1c9b6e17fd6253924ce5929861cd99f

> PDF interpreter - Properly clamp real arguments for /Indexed spaces
> Bug #698434 "real operands to /Indexed spaces not properly limited (PDF 2.0)"
> The quality Logic PDF 2.0 test file fts_14_1422.pdf tests /Indexed
> colour spaces with real value to see if the notes in Section 8.6.6.3
> regarding real values are adhered to. Previously we simply set such
> values to the lowest integer (truncated the fractional part) which is
> wrong according to both the PDF and PostScript specifications.
> The PDF specification specifically states that 0.5 rounds *up* while
> the PostScript Language Reference Manual (unusually) doesn't state
> exactly what 'nearest' means.
> Since it was wrong for both before I've chosen to apply the same rules
> for both PDF and PostScript, 0.5 and above rounds up, other reals round
> down. Values outside the range 0->hival are clamped to either 0 or
> hival whichever is nearer (this was already done in fact).
> psi/zcolor.c

2017-08-29 10:37:23 +0100
Ken Sharp <ken.sharp@artifex.com>
ed962af64e86887b0c2ca614c877bb743315d414

> PDF Interpreter - Paint one pixel for Patterns with BBox width/height of 0
> Bug #698431 "PDF 2.0 - Patterns with BBox where width or height = 0 should paint 1 pixel"
> The ISO32000-2:2017 specification explicitly states (See section 8.7.3.1
> Table 74 and section 8.7.4.3 Table 77) that a Pattern with a BBox where
> the width or height is 0 should still paint one pixel.
> We achieve this here by detecting the condition where width or height in
> a Pattern BBox is exactly 0, and add a tiny amount to the urx or ury
> to ensure that one pixels is touched, and therefore painted.
> Resource/Init/pdf_draw.ps

2017-08-28 15:28:01 +0100
Ken Sharp <ken.sharp@artifex.com>
93b7c164f969787767da98ea3cb4b3efdb6ffc32

> fix previous commit
> Commit e239afa0924503e131b0445bf2624da90f7c93d1 accidentally broke
> ps2write for files with a halftone, but no transfer function. We do need
> to check to see if the transfer function is present before trying to
> emit it!
> For safety, set the character array to NULLs before we start.
> devices/vector/gdevpdfg.c

2017-08-28 14:38:02 +0100
Ken Sharp <ken.sharp@artifex.com>
e239afa0924503e131b0445bf2624da90f7c93d1

> pdfwrite - fix 2 scan-build warnings
> devices/vector/gdevpdfg.c

2017-08-28 14:31:37 +0100
Ken Sharp <ken.sharp@artifex.com>
f06cb1ba2d51c44cd27cbf12e2011d15e49cd3ad

> PDF Interpreter - Handle recursive /Prev entries in trailer dictionaries
> Bug #698409 "PDF xref loop causes denial of service"
> This commit creates an array and stores the offset of each /Prev as it
> is encountered while processing xrefs. Each Prev is also compared
> against every preceding offset already stored in the array. If we get
> a match then we have recursion and we break out. The file may not render
> correctly, and we issue the usual warning.
> For complex reasons it was necessary to create the array and store it in
> the current dictionary rather than simply leave it on the stack, so we
> undef it again after use.
> Resource/Init/pdf_main.ps

2017-08-26 10:39:51 +0100
Ken Sharp <ken.sharp@artifex.com>
347f334e934356746f7cc63e478fee41a2c4a8dd

> pdfwrite - fix a couple of compiler warnings
> Nothing serious, but the code wasn't checking some error returns. We
> should do that so fixed here.
> devices/vector/gdevpdfg.c

2017-08-26 10:03:00 +0100
Ken Sharp <ken.sharp@artifex.com>
56aa7b23cbb3cea465ba962ce57157e3a6101e3a

> pdfwrite - add code to apply transfer functions instead of preserving
> With the release of the PDF 2.0 specification transfer functions have
> been deprecated in graphics states. This means we can no longer simply
> preserve transfer functions as we have done in the past, and removing
> them can lead to unexpected results (Quark XPress is notorious for
> using transfer functions inadvisably). So this commit alters the colour
> handling code fairly extensively in order to allow transfer functions
> to be applied.
> In order to achieve this there are conditions under which we are forced
> to convert colour spaces, as its not possible to apply the transfer
> function reasonably to the base space (CIEBased colour spaces are an
> example of this). In this case we will use the ProcessColorModel in
> effect at the time as the space to convert to.
> Its also (unfortunately) the case that when the input is a PDF file,
> the PDF file uses transparency and the PDF file has transfer functions
> set in the graphics state, that some kinds of operation (soft mask
> groups for example) cannot have the transfer function simply applied.
> This can result in surprising output. In these (admittedly rare) cases
> removing the transfer function causes differently incorrect output.
> There is no realistic way for us to take a PDF file like this and
> produce an equivalent PDF file which does not contain transfer function.
> Worse, we can't even detect this condition in advance.
> This concludes the work required to support PDF 2.0 creation, and
> Ghostscript should now be able to create and consume PDF 2.0 files
> though additional work may be required, and we may choose to add
> more functionality (eg Document Parts processing) in the future.
> devices/vector/gdevpdfg.c
> devices/vector/gdevpdfi.c
> devices/vector/gdevpdfp.c
> devices/vector/gdevpdft.c
> devices/vector/gdevpsdf.h
> devices/vector/gdevpsdi.c
> devices/vector/gdevpsds.c
> devices/vector/gdevpsds.h
> doc/VectorDevices.htm

2017-08-23 16:41:14 -0700
Ray Johnston <ray.johnston@artifex.com>
bd8b456c088516e622659fb58c1079ef0d4aa21f

> Fixes for .genordered
> The zgenordered function created the "THRESH_STRING" length string
> which would be rejected by sethalftone since the Width * Height was
> not equal to the length of the Thresholds string.
> Rather than a compile time switch, the .genordered param dict now
> has /OutputType, one of /Type3, /ThreshString, or /TOSArray.
> The supercell code still had a "realloc". This was replaced by the
> simple ALLOC, memcpy, FREE equivalent.
> There were still several places that used naked printf. Changed to
> respect the "verbose" value or to use EPRINTF* macros. This required
> a couple of new macros.
> Lastly, add DITHERSC (SuperCellSize) and DITHERLEVELS (Levels) as
> options in the gen_ordered_example.ps
> base/gen_ordered.c
> doc/Language.htm
> psi/int.mak
> psi/zht2.c
> toolbin/halftone/gen_ordered/gen_ordered_example.ps

2017-08-22 11:27:38 -0700
Ray Johnston <ray.johnston@artifex.com>
1a9c68e70e338c31a1fbfce6c3750123c6dda319

> Move gen_ordered.c from toolbin to base.
> Modify to strip non LIB_BUILD functions from gen_ordered.c and
> move gen_ordered.[ch] to base. Main now in gen_ordered_main.c with
> project file referencing ../../../base/ for gen_ordered.[ch].
> Modify the project file appropriately and add a simple Makefile for
> unix.
> base/gen_ordered.c
> base/gen_ordered.h
> base/lib.mak
> base/msvclib.mak
> base/openvms.mak
> base/ugcclib.mak
> base/unix-gcc.mak
> base/unixansi.mak
> psi/int.mak
> psi/msvc.mak
> psi/os2.mak
> toolbin/halftone/gen_ordered/Makefile
> toolbin/halftone/gen_ordered/README
> toolbin/halftone/gen_ordered/gen_ordered.vcproj
> toolbin/halftone/gen_ordered/gen_ordered_main.c

2017-08-19 14:36:59 -0600
Henry Stiles <henry.stiles@artifex.com>
37c454cb7f70fd27f14dd2c1b9c63528b3a237ab

> Fix debug -dNOCACHE command line option.
> In the last PL API change the code to disbable the cache was
> accidentally removed.
> xps/xpstop.c

2017-08-22 13:43:00 +0100
Chris Liddell <chris.liddell@artifex.com>
3d3fbafe4a8d1a74a3edb3acbe844da66e1176a2

> Bug 698392: add a type check to transparency enum_param()
> We were using a ref parameter as a name object without checking its type first
> psi/ztrans.c

2017-08-22 13:32:02 +0100
Chris Liddell <chris.liddell@artifex.com>
e61805f2b5559647c0a9122cde508e278f331071

> Bug 698391: check base_space pointer before de-referencing
> in gs_pattern1_remap_color()
> base/gxpcmap.c

2017-08-22 13:38:26 +0100
Ken Sharp <ken.sharp@artifex.com>
a8621022595d5af20f14e87f6ced620dbca43bad

> pdfwrite - don't attempt to use the image-to-mask device unless its present
> Bug #698390 "gswin32/64 crashes during PDF conversion"
> This looks like a simple oversight, other places where we attempt to
> use methods from the mask device we first check to see if we have a
> mask device present, which we do not in this case. This commit simply
> checks the presence of the mask device and doesn't attempt to use it
> if we have not installed one.
> No differences expected
> devices/vector/gdevpdfd.c

2017-08-18 16:10:45 +0100
Chris Liddell <chris.liddell@artifex.com>
e0a921ea3457ae4fea740c4af532e9c103ee9366

> Fix FAPI memory leaks.
> Noticed while chasing down other memory issues.
> Two issues, as it turns out:
> Firstly, descendants of a composite font were not having the notify method set, so
> we can free the FAPI related memory for the font.
> Secondly, the Freetype incremental interface object created for each font was not
> freed along with the font object.
> base/fapi_ft.c
> base/gxfapi.c

2017-08-21 17:05:09 +0100
Ken Sharp <ken.sharp@artifex.com>
7a9d86b5ed28862b671bfb65d3a4d0622ec745c1

> XPS Interpreter - fix a formatting mistake
> No impact, but it silences a compiler warning. Accidentally introduced
> in commit 6162bbb7b804a0c70a35f218e59fa6c3118cd6a2
> xps/xpszip.c

2017-08-21 09:46:42 +0100
Ken Sharp <ken.sharp@artifex.com>
6162bbb7b804a0c70a35f218e59fa6c3118cd6a2

> Coverity IDs 158378, 158393
> Add some limit checks to see if they silence Coverity. Also revisit the
> check added in commit c5bf24912f589c881be44408e110ebdbb2fcd5b9 to
> correct the limit check.
> Coverity complains about reading values from a file format and then
> using them without validating them. Its hard to see how to validate
> values which can legitimately range over the whole space available. If
> we add checks for that, then Coverity complains that the checks are
> pointless (which is true of course).
> In these cases, however, we are reading unsigned shorts into signed
> integers, so we can add a (pointless, really) test to ensure that the
> integer value lies in the range of a short. This should satisfy the
> 'tainted scalar' complaints and also should silence the overflow
> warnings when using the values to allocate memory.
> Normally I wouldn't do this as is costs performance, but we only execute
> this code once when we open the file, so its negligible.
> xps/xpszip.c

2017-08-19 14:53:28 +0100
Ken Sharp <ken.sharp@artifex.com>
c5bf24912f589c881be44408e110ebdbb2fcd5b9

> Coverity IDs 158372 - 4, 158384
> This is an attempt to work-around Coverity complaining about a 'tainted
> scalar' or 'tainted argument'. This is caused by reading a 16-bit value
> from the Zip central directory and then using it without checking the
> bounds. Since the legal bounds are 0 - 2^16 its rather hard to see how
> we can bounds check this....
> If this doesn't silence the warnings tomorrow, or creates new ones
> complaining that the bounds check is pointless (this has happened with
> Coverity before) then I'll undo this commit and just tell Coverity
> to ignore the warning.
> xps/xpszip.c

2017-08-19 10:54:59 +0100
Ken Sharp <ken.sharp@artifex.com>
c57ea7b20d39f0e56432c9cc7bbb7f59fcc544e9

> Coverity ID 158375
> The function xps_set_nocache() is pointless, it doesn't do anything at
> all, it merely retrieves a value from the PCL state stored in the
> current instance. I suspect the value retrieved is garbage, since this
> is XPS, not PCL, but since we never even use it, its irrelevant.
> Whatever the original thinking behind this function was, its not doing
> anything useful, so simply remove it.
> xps/xpstop.c

2017-08-19 10:28:25 +0100
Ken Sharp <ken.sharp@artifex.com>
c552209d54f69152332795bd833fb3d655e79c48

> Coverity ID 158394
> I don't actually think the Coverity warning is possible, but I cannot be
> absolutely certain, so its simpler just to explicitly set the contents
> of these two arrays to a fixed 0 before we start. Its a low overhead if
> we do it at the start of the routine.
> devices/vector/gdevpsf2.c

2017-08-18 16:08:53 +0100
Ken Sharp <ken.sharp@artifex.com>
57bb7d00e180439440ab1be775fad94e13d340ff

> PDF interpreter - Cover some cases of illegal /Parent entries
> Bug #698372
> The PDF file has a Page with an invlalid /Parent (it references the Page
> object). Attempting to use that Page object fails when tracking Resources.
> This commit alters the object storage introduced with the PDF unique
> font identification so that *any* dictionary with a /Type gets its
> object number stored inside it. We can then compare the object and the
> Parent when tracking resources and refuse to follow a self-referencing
> object.
> No differences expected
> Resource/Init/pdf_base.ps
> Resource/Init/pdf_main.ps

2017-08-17 15:46:17 +0100
Chris Liddell <chris.liddell@artifex.com>
39648c6aafbe7ff790dd4dddf577def1fa7b1f07

> Bug 698363: bounds check against length of loca table
> In the FAPI code retrieving the glyph data, we weren't checking that the glyph
> index was inside the loca table (i.e. that it was less than or equal to the
> number of glyphs available in the font).
> psi/zfapi.c

2017-08-16 15:12:14 +0100
Chris Liddell <chris.liddell@artifex.com>
2b138093cf78d9f72596a764d4225b5022ed9d9c

> Bug 698356: Add reference counting for SMask ICC profiles
> Previously, we didn't properly reference count the ICC profiles for
> soft masks because we simply swapped in the ones for the mask, and swapped out
> the ones "in force" at the time into temporary storage, then swapped them back
> when the SMask was complete.
> That works fine *if* the PDF is well formed, and thus the SMask completes. But
> it causes havoc if the PDF is invalid and causes an error during the processing
> of the SMask.
> We'll now properly reference count the profiles.
> base/gdevp14.c

2017-08-12 16:24:54 -0700
Ray Johnston <ray.johnston@artifex.com>
f6cabb1a7264e81a4b80a515717f7cc8938f1145

> Add .gen_ordered operator to PS and htsc_gen_ordered to gs lib
> If GS_LIB_BUILD is #defined, gen_ordered.c API can be called from GS to
> allow for addittion of a PS operator to make a HalftoneType 3 (threshold
> array based halftone) controlled by parameters from a dictionary.
> The result is can be used by sethalftone or as a HalftoneType 5 halftone.
> Also some warnings cleaned up and add checks for ALLOC fail.
> Add a gen_ordered parameter to control verbosity of printing The default
> is 0, which is error messages only. Error messages are generated to
> stderr (using the EPRINTF* macro).
> Add documentation of these two new operators in doc/Lagnuage.htm
> Add an example toolbin/halftone/gen_ordered/gen_ordered_example.ps
> of usage of ,genordered and some related rendering options.
> Other parsers (PCL or XPS) may call htsc_set_default_params and
> htsc_gen_ordered as well to make ordered dither halftone generation
> more flexible, but the integration into non-PS parsers is left for
> later.
> Makefile.in
> base/lib.mak
> base/msvclib.mak
> base/openvms.mak
> base/ugcclib.mak
> base/unix-gcc.mak
> base/unixansi.mak
> doc/Language.htm
> psi/int.mak
> psi/msvc.mak
> psi/os2.mak
> psi/zht2.c
> toolbin/halftone/gen_ordered/gen_ordered.c
> toolbin/halftone/gen_ordered/gen_ordered.h
> toolbin/halftone/gen_ordered/gen_ordered_example.ps

2017-08-11 10:43:52 -0700
Ray Johnston <ray.johnston@artifex.com>
e64f5a2eaeb5c667bfc6bf584f4d7655c8b6b959

> Refactor gen_ordered to allow for use by an application (ghostscript).
> Also Refactor htsc_save_tos to extract htsc_mask_to_tos to convert
> final_mask.data to turn_on_sequence.
> If GS_LIB_BUILD is #defined, the "main" and functions that write files
> will not be included, and all but a few of the functions will be made
> static. Exported functions are:
> htsc_set_default_params
> htsc_gen_ordered
> Also ALLOC and FREE are used to allow the use of a memory allocator
> (such as ghostscript's) and PRINTF and EPRINTF macros are used to
> allow for redirection of messages.
> toolbin/halftone/gen_ordered/gen_ordered.c
> toolbin/halftone/gen_ordered/gen_ordered.h
> toolbin/halftone/gen_ordered/gen_ordered.vcproj

2017-08-15 16:56:58 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
376e4a546024d9d5f22d1f0a76294d5605ad82be

> Bug 694680: Prevent SEGV due to uninitialised structure.
> Changing compression within an image is unimplemented but for
> now we return an error.
> However, changing to eNoCompression is allowed since no
> uninitialised structures are encountered.
> pcl/pxl/pximage.c

2017-08-15 09:20:34 +0100
Ken Sharp <ken.sharp@artifex.com>
5628bd182819bafe965cbf86649e678a6701f818

> pdfwrite - remove obselete code
> Originally included as part of the colour management rework, this was
> never actually needed, so remove it.
> devices/vector/gdevpsds.c
> devices/vector/gdevpsds.h

2017-08-15 09:19:27 +0100
Ken Sharp <ken.sharp@artifex.com>
55e3ee85c171a0d7e563535c77d69a8773f17265

> Fix some spurious code in the CUPS device, flagged by the compiler
> Somehow a few lines of code were duplicated, fortunately this was
> benign, but lets remove the nonsense lines anwyay.
> cups/gdevcups.c

2017-08-11 08:30:24 -0700
Michael Vrhel <michael.vrhel@artifex.com>
ffa47bc975171d8839af1cf8fb9677c173cff0e6

> Bug 696386 Fuzzing
> Take slow path if we have a 16bit indexed image
> base/gxi12bit.c

2017-08-10 17:39:05 -0700
Michael Vrhel <michael.vrhel@artifex.com>
fb37a099ccc86c2af63794167ccc1799c6fc06a0

> Clean up warning in gen_ordered.c
> The comment about what the levels of quantization
> were when no size was given for the macro cell was
> not correct
> toolbin/halftone/gen_ordered/gen_ordered.c

2017-08-10 17:17:39 -0700
Michael Vrhel <michael.vrhel@artifex.com>
723d2a565e726cc6f29f4d32f202c29a995b4e37

> Bug 698344 gen_ordered.c
> Fix case for -r600 -l144 -a45 -q64 -s8
> A problem where we only need to take
> one dot location for our first quantization level (there were
> not multiple dots set to get that level)
> toolbin/halftone/gen_ordered/gen_ordered.c

2017-08-10 13:15:15 -0700
Michael Vrhel <michael.vrhel@artifex.com>
f08687ffb24f641f7ed788ccf152752cd502df88

> Fix ambiguity in creation of turn on sequence
> When dot profile values are the same due to tiling,
> force decision as to which one to turn on next based
> upon distance to center of dot mask.
> toolbin/halftone/gen_ordered/gen_ordered.c

2017-08-09 14:58:02 -0700
Michael Vrhel <michael.vrhel@artifex.com>
a664e0d6601c80388cd8af765400ce071ee8f967

> Fix minor offset issue in gen_ordered.c
> toolbin/halftone/gen_ordered/gen_ordered.c

2017-08-07 17:12:54 +0100
Ken Sharp <ken.sharp@artifex.com>
913acc7c63921770e755a39fca3f768dda49be5d

> PDF interpreter - PDF 2.0 - basic support for UTF-8 strings
> I'm sure this will require more work in future, but for now this is at
> least as good as our support for UTF-16 strings.
> Resource/Init/pdf_draw.ps
> Resource/Init/pdf_ops.ps

2017-08-07 13:44:06 +0100
Ken Sharp <ken.sharp@artifex.com>
2efe17a30ff9a72f0698add0bd8708f3ef1d3b99

> PDF interpreter - fix typos
> two typos in error messages, 'endjobj' should be 'endobj'
> Resource/Init/pdf_base.ps

2017-08-07 13:37:59 +0100
Ken Sharp <ken.sharp@artifex.com>
9a5e5e3c396fb18bcd21158c4f44596eed69e5d0

> PDF interpreter - PDF 2.0 support - per page OutputIntents
> The only way previously to handle *any* OutputIntents array was to
> specify UsePDFX3Profile and give the array index of the required
> profile.
> This is too inflexible as each page can have a different array, so the
> indices may be different on each page. Add a new switch -dUseOutputIntent
> which takes a string argument.
> If we have set -dUseOutputIntent, then check teh document level and each
> page for an array of OutputIntents. If found, check each OutputIntent
> dictionary for a OutputConditionIdentifier and compare it with the
> specified string. If the OutputConditionidentifier is 'Custom' then use
> the value of the Info key instead.
> Resource/Init/pdf_main.ps
> doc/Use.htm

2017-08-07 10:07:06 +0100
Ken Sharp <ken.sharp@artifex.com>
04fd73cadbf91e7a9cf0dee0129384ce23aa3000

> PDF interpreter - PDF 2.0 support add UseBlackPtComp
> Michael already implemented the use of black point compensation, and
> we have a PostScript operator to turn it on and off already (GS
> defaults to on).
> This just hooks up the PDF 2.0 graphics state entry to the existing
> framework. Note that the PDF entry is a boolean whereas our existing
> PostScript operator takes 0 or 1, so there's a little fiddling to get
> that right.
> Resource/Init/gs_init.ps
> Resource/Init/pdf_draw.ps
> Resource/Init/pdf_ops.ps
> psi/zcolor3.c

2017-08-07 10:04:27 +0100
Ken Sharp <ken.sharp@artifex.com>
dcc9ea12638e99917b28b49c120a52c8e309d9fa

> PDF interpreter - support for PDF 2.0 add HTO
> I doubt we will ever see a Halftone Origin for real. According to the
> specification its like a halftone phase but with a different co-ordinate
> system.
> For now simply treat its as a halftone phase, if anyone ever complains
> we can address it, because they will be able to supply an example to
> work from.
> Resource/Init/pdf_draw.ps

2017-08-06 12:24:21 -0700
Ray Johnston <ray.johnston@artifex.com>
478a0a862d2593199bcae599e46bdc97b525bb12

> Bug 698334: LeadingEdge parameter problems.
> Because -dLeadingEdge=# sets the value in systemdict, we need to return
> this parameter from gx_default_get_param and gx_default_get_params so that
> the systemdict value will get sent to the device (putdeviceprops).
> Also found that the JPEG device was using LeadingEdge, but not stripping
> off the "LEADINGEDGE_SET" bit. Fix by anding with LEADINGEDGE_MASK.
> Lastly, the cups device put_params needs to be able to accept a null
> parameter type as the default put_params can.
> base/gsdparam.c
> cups/gdevcups.c
> devices/gdevjpeg.c

2017-08-06 02:23:55 +0800
Sebastian Rasmussen <sebras@gmail.com>
d91d4273f38fb8a527ff342d360cee8aaf468896

> Allow for symbol dictionary with 0 symbols.
> jbig2dec/jbig2_symbol_dict.c

2017-05-14 17:50:32 +0800
Sebastian Rasmussen <sebras@gmail.com>
b5a27404ff64c427d8bcdbd16742ab15a4f6cda5

> Plug leak of parameter info in command-line tool.
> jbig2dec/jbig2dec.c

2017-05-14 17:44:45 +0800
Sebastian Rasmussen <sebras@gmail.com>
1d939952cc3262c8e7b31247046f4e7d9c2d7394

> Do not grow page if page height is known.
> Previously an encountered region segment could cause the page
> height to be increased if the segment height/position occurred
> outside of the page boundaries. This happened regardless of
> whether the page height was previously known or unknown.
> jbig2dec/jbig2_page.c

2017-08-05 11:23:25 +0100
Ken Sharp <ken.sharp@artifex.com>
22dca483140d23a73ab7db835e7d923a91745b6f

> pdfwrite - begin support for PDF 2.0
> Permit CompatibilityLevel to be 2.0 for production of PDF 2.0. We may
> eventually make this the default.
> Don't write ProcSet resources when creating PDF 2.0
> Don't write a Producer etc in the Info dict when creating PDF 2.0
> Don't write DOCINFO pdfmarks in the Info dict when creating PDF 2.0
> Don't write CharSet key in font dictionaries when creating PDF 2.0
> Write FontDescriptor, Widths, FirstChar and LastChar for base 14 fonts
> when creating PDF 2.0
> Don't write Transfer functions in graphics states when creating PDF 2.0.
> We need to add the ability to 'apply' transfer functions for proper
> support here.
> Need to add support for BlackPointCompensation and (possibly) per-page
> OutputIntents when the PDF itnerpreter has been upgraded to support
> these.
> devices/vector/gdevpdf.c
> devices/vector/gdevpdfb.c
> devices/vector/gdevpdfg.c
> devices/vector/gdevpdfi.c
> devices/vector/gdevpdfm.c
> devices/vector/gdevpdfp.c
> devices/vector/gdevpdft.c
> devices/vector/gdevpdfv.c
> devices/vector/gdevpdtd.c
> devices/vector/gdevpdtt.c

2017-08-01 15:57:17 +0100
Chris Liddell <chris.liddell@artifex.com>
dcda07a31c90ff1ece5a92961eb83b58ffc44be4

> Bug 697232: URW++ font update from 2017/07/27
> Adds blue zones for the top features of numbers in:
> NimbusSans-Italic
> NimbusSans-Regular
> Resource/Font/NimbusSans-Italic
> Resource/Font/NimbusSans-Regular

2017-08-04 09:22:36 +0100
Ken Sharp <ken.sharp@artifex.com>
cd1c10382c868b8bd8dba9b52ea7fca970f95eaa

> pdfwrite - initialise some new downscale parameters
> Bug #698329 "Floating point exception in s_IScale_init()"
> Commit a936cf76a33389610b558ffaf5de7389265fd657 to fix Bug #693684
> "Add InterpolateControl parameter to limit image interpolation." added
> a new parameter 'abs_interp_limit' but omittted to initialise the
> variable in pdfwrite's use of the filter.
> This led to an unuinitialised variable, which could eventually cause a
> divide by zero fault.
> It seems this parameter is only used when scaling up, so this commit
> simply sets it to the minimum value of 1. At the same time initialise
> a couple of other parameters too, these are probably unused and in any
> event should be initialised by the filter code, but its best to be safe.
> devices/vector/gdevpsdi.c

2017-08-02 13:41:59 +0100
Ken Sharp <ken.sharp@artifex.com>
ca1ec9b486ddba3f921355fd1d775f27f4871356

> PDF interpreter - remove the PDFDontUseObjectNum switch
> This was implemented to allow us to restore the default behaviour if
> it caused problems. No real problems reported, so lets get rid of
> (yet another) of our many, many command line switches.
> Resource/Init/pdf_font.ps

2017-07-29 18:18:58 +0100
Robin Watts <robin.watts@artifex.com>
cdd2b1bcafdc9108f843183a22360ffbc65525a1

> Bug 698034: Fix various problems with MFS downscaling to cmyk.
> Firstly, the mfs buffer was not large enough.
> Secondly, the downscaling logic in down_core4_mfs was broken - fixed
> by copying it from down_core4.
> Thirdly, the sense of the mfs was inverted (we had forced the white
> spots to be zero).
> All in all, my finest work. :(
> Fixed here.
> base/gxdownscale.c

2017-07-27 13:22:50 -0700
Ray Johnston <ray.johnston@artifex.com>
8321323b7c31828d79c0aa1b5c0312f156a53192

> Fix Bug 695333: PDF 1.4 transparency did not support Spot Color clist devices
> Not just the tiffsep device named in the bug, but the psdcmyk device would
> also fail if the clist was used. This file needs to be in the regression suite.
> Fix by adding a pdf14_clist_copy_planes proc that forwards to the underlying
> clist device. NB: The pdf14 rendering device already had a copy_planes device
> which is used in page mode or during clist playback.
> base/gdevp14.c

2017-07-28 15:58:38 +0100
Ken Sharp <ken.sharp@artifex.com>
8b721623f5fee0150822f7ead66ca5820d74e568

> Fix a couple of documentation typos
> doc/Use.htm

2017-07-28 13:37:17 +0100
Ken Sharp <ken.sharp@artifex.com>
7454690eb64cb71c13e957fc47e9881463d01ba4

> Coverity ID 158374 - cater for anerror return
> This probably isn't possible, we're getting a repeat form so the original
> form must be already stored, but its worth the error check.
> devices/vector/gdevpdfi.c

2017-07-28 12:06:01 +0100
Ken Sharp <ken.sharp@artifex.com>
afa8fb82aea663e3da2d7e0e297ca9bc401a1912

> Coverity ID 158379 identical branches
> Coverity is obviously correct that the two branches are identical. I'm
> no longer certain of how this works, but I did test it quite extensively
> at the time so I'm going to assume that the code is correct and simply
> remove the branch logic which seems to be pointless.
> base/gxshade1.c

2017-07-28 11:37:14 +0100
Ken Sharp <ken.sharp@artifex.com>
f26ebc119717475bef5b6fd6068af5f0ab779dc9

> Coverity ID 158388 - don't dereference a pointer before checking it is non-NULL
> base/gdevdflt.c

2017-07-28 11:08:18 +0100
Ken Sharp <ken.sharp@artifex.com>
0947a042bab551b60f9004366bc06b098b8bdbf3

> Coverity ID 158394 - uninitial;ised scalar variable subrs_count[j]
> Unlike other instances of this, I can't be certain that its impossible
> to read the data when its not been initialised, and in other places
> we zero the memory when we change the current hint size, which suggets
> that its at least potentially possible, so here we zero the array of
> bits (flags).
> No differences expected
> devices/vector/gdevpsfx.c

2017-07-27 16:33:08 +0100
Ken Sharp <ken.sharp@artifex.com>
e5d24b703e5413732f2ef58d8fcd5b4803865d7c

> pdfwrite - don't handle some kinds of x/yshow with TJ
> Bug 698218 "Font matrix woes, also with PDF Reader/Writer"
> In fact this is not a problem with the FontMatrix. The problem is
> actually to do with the way the PDF interpreter executes certain kinds
> of operation, basically Fonts where the /Widths array entries don't
> match the actual glyph widths.
> In this case we use an x/yshow operation with the modified width, and
> this works perfectly well for rendering. However, for pdfwrite, we can
> try to use the TJ operator, which works in a slightly different way...
> xshow takes a displacement which is measured from the origin of the first
> glyph to the origin of the following glyph, TJ by contrast adds a
> displacement after the first glyph is rendered. Normally we essentially
> subtract the width from the displacement to find the TJ value. However,
> if the Widths array overrides the glyph width, and the actual glyph
> width is significantly different (eg 0), then what happens is that
> we apply the modified width after rendering the first glyph, and then
> apply the TJ displacement. In effect applying it twice.
> Detecting this condition turned out to be essentially impossible, there
> are too many cases in PostScript files where similar trickery is pulled
> to reliably determine that this occurs. It is, however, rare, especially
> in PDF files, because very few fonts are neither horizontal nor vertical
> in their FontMatrix (shearing is not uncommon but that's different)
> So this commit adds a new boolean which we set false only when we have
> a x/yshow operation, and the width and real width do not match (which
> happens when we have a /Widths mismatch). This prevents the TJ being
> applied and uses direct text positioning commands instead, which works.
> devices/vector/gdevpdte.c
> devices/vector/gdevpdts.c
> devices/vector/gdevpdts.h

2017-07-25 13:55:19 -0600
Henry Stiles <henry.stiles@artifex.com>
44ccac6fb19ec0e3f42b2b51ec4b2b6a4438af71

> Add an upper bound for pattern and bitmap source heights.
> pcl/pxl/pxptable.c

2017-07-21 13:03:54 -0600
Henry Stiles <henry.stiles@artifex.com>
92e2f00d88d664e5249792458c276b6be89b37fa

> Remove unnecessary padding.
> pcl/pxl/pximage.c

2017-07-21 10:59:35 -0600
Henry Stiles <henry.stiles@artifex.com>
bcae781b1f4ef69a67c287f187cf871cd5db60f0

> Fix 694654 - fuzzing seg fault.
> The clip path accumulator device (gxacpath.c) does not support raster
> operations so don't install the device if the raster operation is not
> default.
> To support raster ops the device would need to add procs for get_bits,
> get_bits_rectangle, strip_copy_rop, and copy_color (used by get_bits
> potentially), then it would need to render the accumulated path using
> the current raster operation (it uses "lop_default" now). The
> optimization is not useful in real world PCL files so we choose to
> bypass it.
> base/gsimage.c
> base/gximask.c
> base/gximask.h

2017-07-18 13:50:33 -0600
Henry Stiles <henry.stiles@artifex.com>
dbb4ea0147655b70ee51c18f9963566057b05dc6

> Fix 694643 fuzzing segfault.
> It was possible to write past the end of the gs_debug array.
> pcl/pcl/pgconfig.c

2017-07-21 09:38:13 -0700
Ray Johnston <ray.johnston@artifex.com>
be281458bc48aa20acd7d276fb1e1713f1966750

> Fix bug 694654: Stale cdev->clip_path with image
> base/gxclimag.c

2017-07-20 13:23:14 -0700
Ray Johnston <ray.johnston@artifex.com>
0d751be73cfa40e45bee50560873bf01884b9d92

> Add ROUNDSPOT function and fix limit on lpi search.
> ROUNDSPOT added as growing white circle transitioning to shrinking black
> circle.
> Also there was an arbitrary limit of lpi <= res/10.0 (y<11) that I changed
> to allow things like -l30 -r600 to give more than 100 levels.
> toolbin/halftone/gen_ordered/gen_ordered.c

2017-07-25 12:58:02 +0100
Ken Sharp <ken.sharp@artifex.com>
f816b092c1f69c0fed977aa8804dadd04f0296a5

> PDF interpreter - cope with corrupted Pattern
> Bug #696410 "Seg faults found by fuzzing in pattern_paint_finish (zpcolor.c:321)"
> The file no longer seg faults, but it did enter an endless loop, caused
> by the pattern code consuming the saved dictionary for the 'q' (gsave)
> operation, but leaving another different dictionary on the dictionary
> stack.
> The code here 'ends' teh current dictionary if it has neither a /n or
> /self key, otherwise it calls 'Q' which will end it anyway. This
> prevents the loop being endless because countdictstack is greater
> than the saved dict count, but the current dictionary isn't the
> result of a gsave.
> No differences expected
> Resource/Init/pdf_draw.ps

2017-07-25 11:30:20 +0100
Chris Liddell <chris.liddell@artifex.com>
f0b4fc4f870ada5264c74c17094c982a66bcb42c

> Bug 698287: fix out of bounds access in c_pdf14trans_write
> In pdf14_clist_create_compositor() we create a temporary compositor command to
> change the compositor procs and avoid creating subsequent compositors (rather
> than enable/disable/reconfigure the already existing compositor).
> The problem arises because we create and only copy the data defined by
> the generic gs_composite_t type, rather than the pdf14 compositor specific
> type (gs_pdf14trans_t).
> Change so we use, and copy, the full pdf14 compositor command type.
> base/gdevp14.c

2017-07-25 11:02:07 +0100
Chris Liddell <chris.liddell@artifex.com>
f98e88cabfa7161ec098e0aaf9d94df52923a212

> Move the PCL/PXL/XPS example files into pcl/examples
> instead of pcl/tools
> pcl/examples/bitfont.pcl
> pcl/examples/bitfonts.pxl
> pcl/examples/fills.pcl
> pcl/examples/fontpage.pcl
> pcl/examples/fonts.pcl
> pcl/examples/fonts.pxl
> pcl/examples/frs96.pxl
> pcl/examples/gl-chars.pcl
> pcl/examples/grashopp.pcl
> pcl/examples/grid.pcl
> pcl/examples/label.tst
> pcl/examples/lineprinter.pcl
> pcl/examples/null.pxl
> pcl/examples/opaque.pcl
> pcl/examples/origins.pcl
> pcl/examples/owl.pcl
> pcl/examples/owl2.pcl
> pcl/examples/pattern.pcl
> pcl/examples/pattern.pxl
> pcl/examples/tiger.px3
> pcl/examples/tiger.xps
> pcl/examples/vasarely.px3

2017-07-21 15:03:16 +0100
Chris Liddell <chris.liddell@artifex.com>
910927d86239c80cc5bc365445c1df7a6e5fa8da

> Bug 696387: iccprofile ref counting in gdevp14 compositor
> The transparency compositor does extensive swapping and creating of ICC
> profiles but was less than well disciplined with the reference counting. This
> moves *most* of the profile swapping to a consistent use of the reference
> counting.
> The one remaining exception is the handling of colors for soft masks, which are
> still handled "specially".
> base/gdevp14.c

2017-07-13 13:57:30 +0100
Chris Liddell <chris.liddell@artifex.com>
f060b1bffacca60b45b9be1b94a8944ca2608930

> Bug 698188: (clist) prevent reading off the end of a bitmap buffer
> In clist_copy_mono, when the bitmap is clipped (in the x-direction) we apply
> gross clipping to the bitmap data - the "clip" the left edge of the bitmap
> to the nearest byte.
> The problem is that we then calculate the aligned bitmap raster from that
> byte offset. Thus, in the uncompressed case, if we copy the aligned raster
> bytes for each scanline, we *can* end up reading off the end of the buffer.
> Instead, use width/8 bytes as the amount to copy for each scanline. Then, if
> necessary, zero the padding bytes.
> base/gxclbits.c

2017-07-06 14:54:02 +0100
Chris Liddell <chris.liddell@artifex.com>
671fd59eb657743aa86fbc1895cb15872a317caa

> Bug 698158: prevent trying to reloc a freed object
> In the token reader, we pass the scanner state structure around as a
> t_struct ref on the Postscript operand stack.
> But we explicitly free the scanner state when we're done, which leaves a
> dangling reference on the operand stack and, unless that reference gets
> overwritten before the next garbager run, we can end up with the garbager
> trying to deal with an already freed object - that can cause a crash, or
> memory corruption.
> psi/ztoken.c

2017-07-13 13:36:19 +0100
Chris Liddell <chris.liddell@artifex.com>
18a2365b69cc43ed4dbe2bfd44f739622623821c

> Update fonts to latest URW++ release (2017/05/01)
> Plus 2017/07/20 update
> Fixes bugs 696582, 697232 and 697058
> Resource/Font/C059-BdIta
> Resource/Font/C059-Bold
> Resource/Font/C059-Italic
> Resource/Font/C059-Roman
> Resource/Font/NimbusMonoPS-Bold
> Resource/Font/NimbusMonoPS-BoldItalic
> Resource/Font/NimbusMonoPS-Italic
> Resource/Font/NimbusMonoPS-Regular
> Resource/Font/NimbusRoman-Bold
> Resource/Font/NimbusRoman-BoldItalic
> Resource/Font/NimbusRoman-Italic
> Resource/Font/NimbusRoman-Regular
> Resource/Font/NimbusSans-Bold
> Resource/Font/NimbusSans-BoldItalic
> Resource/Font/NimbusSans-BoldOblique
> Resource/Font/NimbusSans-Italic
> Resource/Font/NimbusSans-Oblique
> Resource/Font/NimbusSans-Regular
> Resource/Font/NimbusSansNarrow-BdOblique
> Resource/Font/NimbusSansNarrow-Bold
> Resource/Font/NimbusSansNarrow-Oblique
> Resource/Font/NimbusSansNarrow-Regular
> Resource/Font/P052-Bold
> Resource/Font/P052-BoldItalic
> Resource/Font/P052-Italic
> Resource/Font/P052-Roman
> Resource/Font/URWBookman-Demi
> Resource/Font/URWBookman-DemiItalic
> Resource/Font/URWBookman-Light
> Resource/Font/URWBookman-LightItalic
> Resource/Font/URWGothic-Book
> Resource/Font/URWGothic-BookOblique
> Resource/Font/URWGothic-Demi
> Resource/Font/URWGothic-DemiOblique
> Resource/Font/Z003-MediumItalic
> Resource/Init/Fontmap.GS
> psi/psromfs.mak

2017-07-24 15:54:41 +0100
Ken Sharp <ken.sharp@artifex.com>
bfed2aa2b1d854d4b63bc75957438e38fca361fc

> PDF interpreter - permit Widths arrays to contain indirect objects (!)
> Bug 698275 "GPL Ghostscript 9.21: Failed to interpret TT Instructions"
> The actual problem is that the PDF file contains a Widths array where
> one or more of the entries is an indirect object. Since this has no
> useful purpose beyond making the PDF file larger I can't think why this
> has been done.
> Nevertheless, as usual 'Acrobat accepts it' so now we do too.
> The complain about the TT instructions is because in addition the file
> contains two TrueType fonts which are broken.
> Resource/Init/pdf_font.ps

2017-07-19 22:05:33 -0700
Ray Johnston <ray.johnston@artifex.com>
983e56cb679768fe5a048fbb33a43259efb9afbf

> Fix Bug 696398: Segfault with fuzzing file.
> Oveflow of integer caused later failure even if allocation of the
> ht_buffer succeeded. Detect overflow, return error.
> base/gxht_thresh.c

2017-07-19 12:13:30 -0700
Ray Johnston <ray.johnston@artifex.com>
877cbdf0b279bb4bf5f3b74182ab6d0101095f99

> Fix bug 696402: Segfault with fuzzed data caused by dda overflow.
> The ty of the matrix in the fuzzed data was a very large value that
> resulted in the Y for an image being near the limit for the dda,
> so the first step (dda_next) overflowed from positive to negative
> resulting is a large destination height calculation (vdi). Prevent
> this by not stepping if it would cause an overflow. This will be
> outside the clip limits, so will not affect the output.
> base/gxidata.c

2017-07-20 13:36:46 +0100
Ken Sharp <ken.sharp@artifex.com>
91fd78617440c18288b6d4cd226fa3f77db91705

> Update the nulldevice for DeviceN
> Bug #696383 "Seg faults found by fuzzing in get_num_pdf14_spot_colors (gstrans.c:720)"
> The problem here is really an example of our poorly maintained device
> API. As stated previously the comments in the code seem to indicate
> that all devices should either implement their own versions of all
> the device methods, or use the graphics library default method. No
> device method should be NULL, so it should never be necessary to check
> this.
> Sadly, many of our devices have NULL entries for some methods, and in
> this case the nulldevice did not implement a method for
> 'ret_devn_params'. Presumably this was missed when the mthod was added.
> In this commit, just up date the device to use the default method.
> base/gdevnfwd.c

2017-07-18 16:36:15 +0100
Ken Sharp <ken.sharp@artifex.com>
64cb7a492292eb40a01de760be832b7d5425d8e9

> PDF interpreter - detect and ignore recursive Form XObjects
> Bug #698226 "Error: /rangecheck in --run--"
> The PDF file supplied in the bug is broken, it has a Form XObject:
> 285 0 obj
> <<
> /BBox [ 294.572 797.586 306.188 793.466 ]
> /Group 287 0 R
> /Matrix [ 1 0 0 1 0 0 ]
> /Resources <<
> /ExtGState <<
> /GS0 32 0 R
> >>
> /XObject <<
> /Fm0 285 0 R
> >>
> >>
> /Subtype /Form
> /Length 58
> >>
> stream
> q
> 0 Tc 0 Tw 0 Ts 100 Tz 0 Tr []0 d
> /GS0 gs
> 0 TL/Fm0 Do
> Q
> endstream
> endobj
> The file throws an error in Acrobat, Ghostscript recurses the Form until
> it hits an execstackoverflow, and is then unable to proceed. Testing
> Acrobat we see that it can detect recursion even when its not a simple
> self-reference, a child referencing a parent is also detected and
> ignored.
> In the PDF interpreter we normally push a dictionary on the operand
> stack and record objects as we encounter them, checking each new one
> against all the ones executed so far, and exit if we find reuse. This
> approach doesn't quite work for Form XObjects, because we cannot be
> certain of the operand stack shape when a Form is executed, and so we
> cannot locate our dictionary.
> Instead we now store the dictionary in the top level 'pdfdict' which is
> always available. The technique is otherwise the same.
> I'm not totally happy with this, but its the best compromise between
> performance hit, memory use and code frailty I could come up with.
> No differences expected.
> Resource/Init/pdf_draw.ps
> Resource/Init/pdf_main.ps

2017-07-13 16:02:16 -0600
Henry Stiles <henry.stiles@artifex.com>
cea2da4aae1edbf6aef128f44962cfe8baa5c728

> Fixes Bug 697900 - No support for disk resident fonts.
> Support added for using PCL font resources from the PJL file system.
> Macros have always been supported and using a font wrapped in a macro
> as a workaround works, but this isn't quite correct or convenient.
> Also refactoring and better error handling for alphanumeric key support.
> pcl/pcl/pcsfont.c

2017-07-12 08:53:21 -0600
Henry Stiles <henry.stiles@artifex.com>
8d195215c057f4df0c609828b5da65c7f3462588

> Fix bug #697650 - RemoveFont opearator error handling.
> The RemoveFont operator produced an error and stopped processing when
> the font was not found, now we produce a warning and continue like HP.
> Other areas of the code needed tidying up as well. The
> px_widen_font() function did not NULL the font output parameter
> according to its spec and RemoveFont did not check there wasn't an
> error before attempting to remove the font from the font dictionary
> pcl/pxl/pxffont.c
> pcl/pxl/pxfont.c

2017-07-17 09:19:14 +0100
Ken Sharp <ken.sharp@artifex.com>
798bc40317ba4b552560f4ceede1607c561ef54c

> pdfwrite - remove the 'deferred free' code
> Now that the memory cleanup is completed, we can remove the 'hack'
> that defers really freeing freed memory in the memory manager.
> devices/vector/gdevpdf.c

2017-07-13 13:43:45 +0100
Ken Sharp <ken.sharp@artifex.com>
091b860bcde7fc610cff89b7711c59597dc06674

> pdfwrite - memory management cleanup
> Bug #696608 "Use after free error in PDF write"
> As per the instructions in the original bug report, filling free memory
> with 0x00 causes seg faults because of 'use after free' conditions in
> the pdfwrite resource management.
> There were a number of problems solved in order:
> 1) Move freeing of colour spaces until after shadings are freed, because
> shadings can refer to colour spaces.
> 2) Colour space and function resources can reference other resources of
> the same type. clear such references before freeing the resources.
> 3) 'Other' resources can potentially reference other resource types
> (seen with Colorant dictionaries referencing colour spaces). We need to
> clear these references before freeing the resource types. Also, move the
> freeing of 'other' resources until nearer the end.
> 4) The 'Metadata' resource was previously added to the Catalog
> dictionary after the 'Other' resources were freed, so the fact that it
> was double referenced (once from resourceOther, once from 'global named
> object' wasn't a problem. Now that we free 'other' resources later,
> this could lead to double freeing. Explicitly remove the Metadata
> reference from the 'other' resource chains to prevent this.
> Running this on the cluster fixes all the pdfwrite problems, it does
> however leave one file which still causes problems, just not with pdfwrite.
> Bug688308.ps seg faults on the cluster with differing configurations,
> it isn't stable, so I suspect garbage collection may be involved. Its a
> rather complicated page from a yellow pages directory, and involves
> numerous EPS files from varied sources. Unfortunately I can't reproduce
> a problem locally.
> However, its not a pdfwrite problem.
> devices/vector/gdevpdf.c
> devices/vector/gdevpdfe.c
> devices/vector/gdevpdfo.h
> devices/vector/gdevpdfu.c
> devices/vector/gdevpdfx.h

2017-07-10 15:06:36 -0600
Henry Stiles <henry.stiles@artifex.com>
7276327a2f78290a7d526df493d92325947a834d

> Bug 698147 - PXL "passthrough" initialization problem.
> Don't let PCL clear the current page if XL has marked the page.
> Thanks to Norbert Janssen for the patch.
> pcl/pxl/pxpthr.c

2017-07-10 11:09:57 -0600
Henry Stiles <henry.stiles@artifex.com>
ec906d206f6ed044b6b7e1b1cc7551150b8db6d4

> Bug 698125 - JPEG RGB not grayscaled.
> Using the XL JPEG compression scheme it is possible to have a mismatch
> between color space in the graphics state and image. This cannot
> happen in any other PXL raster format except JPEG and we expect it
> will rarely happen in the normal workflows. We detect the the
> mismatch and convert the rgb triples to gray triples in advance of
> rendering the scanline.
> pcl/pxl/pximage.c

2017-06-28 17:14:14 -0600
Henry Stiles <henry.stiles@artifex.com>
df8ac78c06cc6093409142aaee839cd4bf953588

> Renaming and refactoring, no functional differences.
> In particular, we get rid of the "universe" structure and move its
> members into the main instance.
> pcl/pl/plapi.c
> pcl/pl/plmain.c
> pcl/pl/plmain.h

2017-07-06 13:57:41 -0700
Ray Johnston <ray.johnston@artifex.com>
21e28148792158aba5cf2b93fad755455d0cc8ba

> Fix viewpbm.ps FITPAGE SCALE option
> lib/viewpbm.ps

2017-07-05 08:45:10 -0700
Ray Johnston <ray.johnston@artifex.com>
12cb9d16d69cd3430b86d0bdfea7f73fcbeeceb3

> Fix regression from InterpolateControl change that affects pattern-clist
> Seen with comparefiles/Bug689851.pdf as missing interpolation.
> The clist_make_accum_device did not copy the interpolate_control value
> from the target. Also copy the params for non-clist pattern accum
> devices and forwarding devices along with graphics_type_tag.
> base/gdevnfwd.c
> base/gxclist.c
> base/gxpcmap.c

2017-07-05 10:59:18 +0100
Robin Watts <robin.watts@artifex.com>
6b24e08b26bbd99082e36785fe742108ab705c23

> Bug 698135: Import security fix for OpenJPEG
> https://pdfium.googlesource.com/pdfium/+/463b77b4f1e4257cd89f3460b5a6fdb102f44265%5E%21/#F0
> Patch doesn't apply cleanly, but requires some manual conflict
> resolution.
> openjpeg/src/lib/openjp2/dwt.c

2017-07-05 14:31:31 +0100
Ken Sharp <ken.sharp@artifex.com>
095a0c9e9c16b5c131709d2d831f97a77084f1bd

> pdfwrite - prevent substitution of an SMask for an identical parent image
> Bug #698128 "PDF created by gs generates "recursive /SMask" messages when run with gs"
> When we have the (highly unusual) case where an image dictionary has an
> SMask entry, and the SMask is an image which is identical to the parent
> in every respect (dictionary contents, stream data) except for the
> SMask key, it was possible for pdfwrite to decide to use the SMask
> instead of the image.
> This leads to a PDF which has an image which references an SMask in the
> image dictionary, and the SMask is the same image XObject.
> In this commit, when checking for an identical image, if the image we
> find is the same as the 'current' softmask image, then do not treat it
> as identical. This prevents us inadvertently detecting an image and its
> SMask as being the same image.
> devices/vector/gdevpdfj.c

2013-06-05 10:07:47 -0700
Ray Johnston <ray.johnston@artifex.com>
a936cf76a33389610b558ffaf5de7389265fd657

> Bug 693684: Add InterpolateControl parameter to limit image interpolation.
> Previously, we always interpolated to the full device resolution. This
> parameter allows control of the resolution of the interploated image
> which makes sense for devices that cannot render continuous tone at
> the device resolution due to halftone cell size. This avoids the
> overhead of interpolation beyond what the device can reproduce and
> allows the user a quality/performance tradeoff.
> The -dDOINTERPOLATE is equivalent to -dInterpolateControl=-1 and the
> -dNOINTERPOLATE is equivalent to -dInterpolateControl=0. These options
> still work for PS/PDF files, but are deprecated and may be removed in
> the future.
> Performance results vary, but using the -dInterpolateControl=4 is
> 4.5 times faster with files that have images that are scaled up and cover
> a large portion of the page such as comparefiles/Bug695221.ps at 600dpi.
> Resource/Init/gs_img.ps
> Resource/Init/gs_init.ps
> base/gsdparam.c
> base/gxdevcli.h
> base/gxdevice.h
> base/gxht.c
> base/gxiscale.c
> base/lib.mak
> base/siscale.c
> base/sisparam.h
> devices/devs.mak
> devices/gdevbit.c
> devices/vector/gdevpsdi.c
> doc/Use.htm

2017-06-27 15:56:01 -0700
Ray Johnston <ray.johnston@artifex.com>
e56286167cad5a5fba3e0b8911d9a54b6a5a5400

> Speed up image interpolation with UseFastColor
> The check for dev_profile->usefastcolor was buried way down in the ICC
> remap logic after getting a link, etc. then eventually returning the
> is_identity that would skip transforming the color. Also check in the
> image_class0_interpolate function to disable use_icc so that it uses
> the faster image_render_interpolate rather than the interpolate_icc
> versions.
> base/gxiscale.c

2017-06-29 15:13:03 -0600
Henry Stiles <henry.stiles@artifex.com>
9ed740e848891de10af6f85bd234298ac2bbab7b

> Fix fuzzing Bug 694668 - CCITT fuzzing.
> Bounds check CCITT Columns.
> pcl/pcl/pcl.mak
> pcl/pcl/rtraster.c

2017-07-04 12:11:33 +0100
Ken Sharp <ken.sharp@artifex.com>
676ad40aed33815aea7bf65cb9f374b79b1d8518

> pdfwrite - fix /Colorants when converting DeviceN colour spaces
> Bug 698129 "Produced PDF that gives "Wrong operand type" in Acrobat for some pages"
> The supplied example uses a Duotone witha CMYK alternate and a Colorants
> array (for the Pantone colour only). When converting to a different
> space we preserve the Spot colours (and therefore DeviceN) but we
> convert the alternate space to the specified base space by sampling the
> original space.
> However, if the DeviceN space contained a Colorants array we were writing
> the new colour space array with the Colorants inserted in the wrong
> position, immediately after the ink array instead of at the end.
> This commit moves the Colorants entry to the correct place, and also
> adds the (previously missing) Subtype key to the Colorants dictionary.
> devices/vector/gdevpdfg.c

2017-07-01 16:36:29 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
f1cfdcd88da67bcab1efbed26191d27a0ce00a53

> Bug 694626: Prevent SEGV due to division by zero.
> Add bounds checking in ttfFont__Open to default nUnitsPerEm to 1024 as
> precedented in ttfOutliner__Outline.
> base/ttfmain.c

2017-06-29 11:20:09 +0100
Chris Liddell <chris.liddell@artifex.com>
0b7fa9293f43dce8aea028e4d2b32da1d8fc18c8

> Add error checking for gs_colorspace_set_icc_equivalent()
> base/gscdevn.c
> base/gsciemap.c
> base/gscolor2.c
> base/gscsepr.c
> base/gstrans.c
> base/gxcmap.c
> base/gxipixel.c
> base/gxiscale.c
> base/gxshade.c

2017-06-29 11:00:38 +0100
Chris Liddell <chris.liddell@artifex.com>
d592ee18a9168b1190bc7f7a1426b41fa6d508af

> Bug 698151: XPS: bounds check selecting cmap table.
> xps/xpsfont.c

2017-06-29 10:54:49 +0100
Chris Liddell <chris.liddell@artifex.com>
0c39ac5a0b8ca650101ac6322be34bd7504e7f63

> Bug 698150: XPS: bounds check in format 6 and 10 cmap tables
> xps/xpsfont.c

2017-06-29 12:07:29 +0100
Robin Watts <robin.watts@artifex.com>
ad0ac7883807331c1c9afb0b87585838bd3e63be

> Bug 697981: Avoid integer overflow problems in scan converter.
> Positions can be anywhere in the signed range 0x80000000..0x7fffffff,
> therefore the difference between those positions can overflow a
> signed 32bit representation.
> base/gxscanc.c

2017-06-28 17:03:24 -0600
Henry Stiles <henry.stiles@artifex.com>
d4681a07410f96ee68479e0c39f1ca6f27168b8f

> Fix Bug 694656, Seg faults found by fuzzing in hpgl_get_char_width
> Along with checking that there is a valid font make sure there is a
> current font selection, if not recompute the current font.
> pcl/pcl/pglabel.c

2017-06-28 20:29:47 +0100
Robin Watts <robin.watts@artifex.com>
1d9dc902167802515d8ee86bf4e2205461486b50

> Squash some warnings in gsmchunk.c
> base/gsmchunk.c

2017-06-07 19:16:46 +0100
Robin Watts <robin.watts@artifex.com>
af4317bc527142dd0b8a6032799c4accf40bf835

> MSVC: Squash double->float implicit cast warning.
> devices/vector/gdevpdfv.c

2017-06-07 19:14:16 +0100
Robin Watts <robin.watts@artifex.com>
f204ddc13530f1bdb180eb38ebcf5a96caab8b74

> MSVC: Fix some implicit casting warnings in ft_api.c
> Simply make the castings explicit.
> base/fapi_ft.c

2017-06-27 19:18:32 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
3a684e3dcc55c27506dc179723e8bcd85d121aa7

> Bug 694670: Prevent buffer overrun.
> Add bounds checking in pxSetHalftoneMethod to prevent a buffer
> overrun.
> pcl/pxl/pxink.c

2017-06-22 22:14:59 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
25d4e951e5290a34354f633f46d57cb6870fbd5d

> Bug 694681: Prevent buffer overrun.
> Move bounds checking earlier in pxReadRastPattern to prevent a buffer
> overrun when StartLine attribute is set to non-zero.
> pcl/pxl/pximage.c

2017-06-27 09:58:44 -0700
Michael Vrhel <michael.vrhel@artifex.com>
dc09d291658c1758fe2a0a02776e66355f56b09a

> Bug 698134 Text knock with alphabits
> The pdf14_copy_alpha operation was not updated
> when fixes were made to properly handle non-isolated
> knockout groups.
> base/gdevp14.c

2017-06-27 15:33:22 +0100
Chris Liddell <chris.liddell@artifex.com>
6ce668c11ccbadde6d76430ba00205eca853879e

> Bug 698130: check the icc profile data exists before accessing it
> base/gscsepr.c

2017-06-26 10:04:02 +0100
Chris Liddell <chris.liddell@artifex.com>
74ce33d1fdb26af4e15a58e5df91dbb1403f66f9

> Drop the now redundant check for zero length, staight contours
> when degenerating the outline into moveto/lineto/curveto operations.
> base/gxfapi.c

2017-06-26 09:58:11 +0100
Chris Liddell <chris.liddell@artifex.com>
6d17251a6c22673854bcd288d8562650361847e5

> Bug 697983: (re-redux) Drop zero length contours from glyph outlines
> Zero length contours cause issues (line-caps) when the outline is stroked.
> Turns out the same problem can arise with arcs as with straight lines.
> That complicates things where TTFs are concerned since we have to convert cubic
> to conic splines, and the floating point errors make it dubious checking for
> point equality after the conversion. As a result, the checking has to be done
> in the scaler specific interface code, rather than in the scaler independant
> FAPI code.
> That just means if we ever integrate another scaler that can handle
> downloadable fonts, we need to take care to include the same checks as are
> now in the Freetype interface code.
> base/fapi_ft.c

2017-06-20 06:50:49 -0600
Henry Stiles <henry.stiles@artifex.com>
793f93b08813e898aa0f1b316619e33568275fb0

> Fix Bug 697926, processing jpeg embedded color parameters.
> HP ignores the height, width and color components provided with the
> raster commands and uses the values in the embedded JPEG.
> Consequently, we have to defer beginning the image until the image
> data arrives.
> pcl/pxl/pximage.c

2017-06-21 01:07:17 +0800
Sebastian Rasmussen <sebras@gmail.com>
4942c650d9ab84671724e1f98541829ba8b6ff80

> Adapt tools to use renamed gpcl6 binary.
> pcl/tools/docov.pl
> pcl/tools/pcl2pdfwr
> pcl/tools/pcl2pdfwr.bat
> pcl/tools/plot2pdf.sh
> pcl/tools/smoke_check.sh
> pcl/tools/smoke_update.sh

2017-06-21 16:01:39 +0100
Ken Sharp <ken.sharp@artifex.com>
3b6625b9f04daedf678a137475858ad35b991052

> pdfwrite - don't arbitrarily alter the 'current' shape alpha
> Bug 697472 "Transparent box appears lighter"
> Whenever we opened a substream, if it was an XObject resource we would
> set the blend mode and shape alpha to the default values.
> This looks wrong to me, and it means that when using a complex ExtGState
> which includes a SMask, if there was an alpha other than 1 in the
> ExtGState then we would write the constant alpha out twice, once
> in the page content, and once again in the resulting Group Form
> XObject which we create. If the alpha was not 1, then this causes it
> to be applied twice, resulting in rendered content which is too pale.
> Both of these look incorrect, but removing the blend mode causes other
> files to fail. Removing the shape alpha causes progressions in a number
> of test suite files.
> devices/vector/gdevpdti.c

2017-06-21 07:38:01 -0700
Ray Johnston <ray.johnston@artifex.com>
e178c1c3a45076fcffbe703c722b4f9bca0ac532

> Fix typo in previous commit s/b PageUsesTransparency
> examples/transparency_example.ps

2017-06-20 17:57:26 -0700
Ray Johnston <ray.johnston@artifex.com>
670840afcd100f4751b911cf4ac3bf0415ba55c2

> Bug 698087: Heap buffer overflow with confused clist colorspace
> The PDF14 transparency compositor changes the colorspace to Gray
> (8-bit), but if a 1-bit deep device is the target device, and the
> normal startup for transparent pages doesn't happen, the playback
> would write 8-bit data to a 1-bit deep buffer
> Also fix the transparency_example.ps so that it sets the device param
> PageUsesTransparency which is expected.
> examples/transparency_example.ps
> psi/ztrans.c

2017-06-20 15:39:22 +0100
Chris Liddell <chris.liddell@artifex.com>
7258589eb5005d05c1499e717da8de804e1c35e1

> Bug 698069: tighten up the out-of-data condition in spgetcc
> base/stream.c

2017-06-20 10:06:51 +0100
Chris Liddell <chris.liddell@artifex.com>
8aaacf3f8d3837b471fc302de0a84c85ecb24307

> Bug 698081: more bounds checking in xps_load_sfnt_name
> xps/xpsfont.c

2017-06-19 13:26:02 +0100
Ken Sharp <ken.sharp@artifex.com>
605af24e8adcbc71bec1c5e1283dc20eabfbc515

> Yet another check on raster memory for get_bits_rectangle
> Bug #698073 "Potential null pointer dereference in mem_word_get_bits_rectangle"
> Not the same reason, but still a potential use of dev->line_ptrs, which
> can be NULL If you mangle makeimagedevice and copyscanlines.
> base/gdevmem.c

2017-06-19 10:02:34 +0100
Ken Sharp <ken.sharp@artifex.com>
a5c6f7da872845b1d9bf2025c0cd5fc98b937d90

> PS interpreter - remove 'STRICT' and remove from documentation
> The 'STRICT' switch is documented as removing as many Ghostsctipt
> extensions as possible. In reality it only removes some media size
> definitions from statusdict.
> This seems less than useful, so remove it to reduce clutter.
> Resource/Init/gs_init.ps
> Resource/Init/gs_statd.ps
> doc/Use.htm

2017-06-19 09:46:21 +0100
Ken Sharp <ken.sharp@artifex.com>
2fa6beaa40144c592661a611bf35ff6f06d3354f

> Tools - remove ps2ascii.ps, recode scripts to use txtwrite
> ps2ascii.ps uses DELAYBIND, which we would like to get rid of, in
> addition it doesn't do a terribly good job of actually extracting text.
> The txtwrite device is more sophisticated, although it does not have the
> added 'COMPLEX' feature of ps2ascii.ps which emits strokes and fills
> as rectangles.
> If the COMPLEX feature set should prove useful enough it would be easy
> to add this functionality to a new device, but in reality I doubt
> anyone is using this. The scripts specifically set -dSIMPLE.
> This allows us to deprecate DELAYBIND and in future remove it.
> lib/ps2ascii
> lib/ps2ascii.bat
> lib/ps2ascii.cmd
> lib/ps2ascii.ps

2017-06-17 17:06:32 +0100
Ken Sharp <ken.sharp@artifex.com>
8f796773b5aae90362ec500d942dc38e6a1f0f6b

> PS interpreter - deprecate DELAYBIND, remove from documentation
> DELAYBIND seems like a bad idea, we suspect there is nothing it does
> which cannot be achieved another way.
> For now we will continue to allow it, but user will have to set
> -dREALLYDELAYBIND instead, setting -dDELAYBIND will trigger a warning
> message and an error.
> Resource/Init/gs_init.ps
> doc/Language.htm
> doc/Use.htm

2017-06-17 16:13:57 +0100
Ken Sharp <ken.sharp@artifex.com>
0a41e707c2ca9a9243df640b32c5abe372be1f53

> PS interpreter - remove NOBIND option and all references
> This was only ever supposed to be a 'debugging aid' and its something
> of a struggle to see why it would be useful.
> Resource/Init/gs_dps1.ps
> Resource/Init/gs_init.ps
> Resource/Init/gs_ll3.ps
> doc/Language.htm
> doc/Use.htm

2017-06-17 14:27:06 +0100
Ken Sharp <ken.sharp@artifex.com>
c294b131ea270cea5d66c9b0a6ea61d3a69a20a0

> PS interpreter - fix use of superexec with DELAYBIND
> Commit 8556b698892e4706aa0b9d996bec82fed645eaa5 removed superexec from
> systemdict, leaving it in internaldict, where it should be. However,
> if we run with DELAYBIND then by the time we come to bind the procedures
> which use superexec the definition in systemdict is gone.
> Technically this shouldn't be a problem, as we should be using the version
> in internaldict. But if we do that, without DELAYBIND the internaldict
> definition isn't present, because we haven't copied it yet....
> So now we look for the presence of superexec in systemdict and use that
> one if its present, otherwise we assume its in internaldict and use
> that instead.
> Unfortunately the use of DELAYBIND interferes with the cluster testing
> causing thousands of files to fail. I've run a random selection of them
> locally in a normal setup and they work, I guess we'll just have to
> hope for the best and fix any problems as they are reported.
> Resource/Init/gs_dps1.ps
> Resource/Init/gs_fonts.ps
> Resource/Init/gs_ttf.ps
> Resource/Init/gs_type1.ps

2017-06-17 11:17:52 +0100
Ken Sharp <ken.sharp@artifex.com>
971472c83a345a16dac9f90f91258bb22dd77f22

> Make operator hiding work with DELAYBIND
> Commit 1497d65039885a52b598b137dd8622bd4672f9be undefines as many operators
> as possible once startup is completed, in order to prevent potantially
> malicious PostScript or PDF files using them.
> However, if DELAYBIND (itself a gaping security hole if used) is
> specified, this leads to an endless loop. Instead we must undefine the
> operators during .bindnow (after the deferred binding has occured).
> Resource/Init/gs_init.ps
> Resource/Init/pdf_main.ps

2017-06-13 00:45:54 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
4bf1f491517c4d1f30f594a77ea4adbef263bfc9

> Bug 694639: Prevent buffer overrun.
> Add bounds checking in pxReadRastPattern to prevent a buffer overrun when
> StartLine attribute is set to non-zero.
> pcl/pxl/pximage.c

2017-06-16 15:40:33 +0100
Chris Liddell <chris.liddell@artifex.com>
824aa630e2d4ce5b53e78cf8b2686ee6acb7a5fe

> Bug 698066: Ensure device has raster memory before using it
> Same solution as Bug #697676
> This is only possible by abusing/mis-using Ghostscript-specific
> language extensions, so cannot happen in a general PostScript program.
> Nevertheless, Ghostscript should not crash. So this commit checks the
> memory device to see if raster memory has been allocated, before trying
> to read from it.
> base/gdevmpla.c

2017-06-16 09:03:14 +0100
Chris Liddell <chris.liddell@artifex.com>
260fefe6504653742a623d416fcf73f6b2559579

> Bug 698065: xps: fix reading of idRangeOffset in cmap table
> In format 4 cmap tables the idRangeOffset was being read as a signed value,
> but it is unsigned.
> xps/xpsfont.c

2017-06-16 08:50:43 +0100
Chris Liddell <chris.liddell@artifex.com>
961b10cdd71403072fb99401a45f3bef6ce53626

> Bug 698064: bounds check xps_encode/decode_font_char_imp
> xps/xpsfont.c

2017-06-16 08:29:25 +0100
Chris Liddell <chris.liddell@artifex.com>
c501a58f8d5650c8ba21d447c0d6f07eafcb0f15

> Bug 698063: Bounds check Ins_JMPR
> base/ttinterp.c

2017-06-15 09:05:20 +0100
Chris Liddell <chris.liddell@artifex.com>
937ccd17ac65935633b2ebc06cb7089b91e17e6b

> Bug 698056: make bounds check in gx_ttfReader__Read more robust
> base/gxttfb.c

2017-06-15 08:58:31 +0100
Chris Liddell <chris.liddell@artifex.com>
7755e67116e8973ee0e3b22d653df026a84fa01b

> Bug 698055: bounds check zone pointer in Ins_MDRP
> base/ttinterp.c

2017-06-14 22:00:52 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
f887813ad00d680e2ea5d81606fd21d1b68067af

> Bug 694662: Bounds check formlines in pcl_vmi_default()
> Added bounds checking to clamp value between a minimum of 5 and a
> maximum of 128.
> pcl/pcl/pcursor.c

2017-06-13 22:35:37 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
3749bc274be1ae5a2f9897447708e84418ccf7a4

> Bug 694653: Prevent buffer overrun.
> Add bounds checking to pcl_character_data to prevent a buffer overrun if
> the continuation data total is greater than font_data_size.
> pcl/pcl/pcsfont.c

2017-06-14 16:07:02 +0100
Chris Liddell <chris.liddell@artifex.com>
db85b2782543f6dc6397a2e87c6beefc00b25b54

> Fix mistake introduced with the pcl glyph data bounds checking code
> When I added the bounds checking for PCL glyph data, I changed slightly the
> way offsets were calculated for the PXL 'error handler' bitmap font so
> we could know the data length.
> I messed up, and forgot to fully take account of the first byte being the
> char code, and not part of the bitmap data.
> pcl/pxl/pxerrors.c

2017-06-14 15:14:30 +0100
Chris Liddell <chris.liddell@artifex.com>
4992ef5bc283a6347737f1369ef3d7bd4efbdce1

> Bug 697983: (redux) Drop zero length contours from glyph outlines
> When a outline glyph has contours with only one point in it, we end up with
> a moveto and a lineto the same point, thus resulting in a zero length line
> segment. This causes problems when the outline is stroked (line caps).
> We'll now drop these pointless lineto operations.
> Resource/Init/pdf_ops.ps
> base/gxfapi.c
> base/lib.mak

2017-06-14 10:46:27 +0100
Chris Liddell <chris.liddell@artifex.com>
80f4cc558efdd73be26ede4057ac1750b0b34210

> chunk allocator: on free, use original size for single object chunk
> On allocation, we decide, based on the requested size (+ house keeping data)
> if an object should be in a chunk on its own. But the size recorded can be
> larger than that if the chunk was recovered from the free list (because the
> free list can contain merged free chunks). In such a case, we also record the
> padding bytes.
> On freeing, we have to use the object size minus the object padding to
> identify single object chunks - to mirror the decision making in the allocation
> code.
> Fixes the cluster segfault with C410.bin and bitrgbtags
> base/gsmchunk.c

2017-06-14 10:14:51 +0100
Chris Liddell <chris.liddell@artifex.com>
3ee55637480d5e319a5de0481b01c3346855cbc9

> Bug 698050: xps: bounds check offset for requested cmap table
> xps/ghostxps.h
> xps/xpsfont.c
> xps/xpsglyphs.c

2017-06-14 09:30:45 +0100
Chris Liddell <chris.liddell@artifex.com>
3c2aebbedd37fab054e80f2e315de07d7e9b5bdb

> Bug 698044: restrict font name length to the buffer size.
> xps/ghostxps.h
> xps/xpsfont.c
> xps/xpsttf.c

2017-06-14 09:16:02 +0100
Chris Liddell <chris.liddell@artifex.com>
c53183d4e7103e87368b7cfa15367a47d559e323

> Bug 698042: xps: fix glyph index and index bounds check.
> If a gs_glyph has the GS_MIN_GLYPH_INDEX offset, we need to remove the offset
> before we try to use it.
> Secondly, using a unsigned variable for a value from which we subtract 1, and
> which can be zero doesn't work well. Switch to a signed value.
> xps/xpsttf.c

2017-06-14 09:28:34 +0100
Ken Sharp <ken.sharp@artifex.com>
6cf7a8c45517d5857aa81cf59a82a2cc5c7d021c

> PDF interpreter - fix a problem with AcroForm interpretation
> No bug for this, noticed in passing while working on a customer bug.
> If we turn on AcroForm processing, and we have an AcroFOrm where a /Tx
> field has a /V entry, then we would not write the value to the string we
> are accumulating. We would only write the value if we had no /V but a
> /DV.
> Instead the string was left on the stack, leading to an error. This
> appears to be due to a logical error when writing the V/DV handling
> where the write== was placed inside the if clause, when it should be
> outside the clause.
> Resource/Init/pdf_draw.ps

2017-06-13 06:58:32 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
fe61712d5157066212d0fcee79b129d6ddcbd251

> Bug 694657: Prevent SEGV due to missing font.
> Updated pcl_reselect_font to check for missing font.
> Updated hpgl_select_stick_font to initialise font->storage before it is
> used in pcl_downloaded_and_bound.
> pcl/pcl/pcfsel.c
> pcl/pcl/pglabel.c

2017-06-12 18:05:14 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
8e1acddeb57e9cbb105ec9ff9e65d35005cac44f

> Bug 694648: Prevent buffer overrun.
> Add bounds checking to pl_tt_string_proc to prevent a buffer overrun if
> the incoming offset value is greater than the header size.
> pcl/pl/plchar.c

2017-06-12 17:50:58 +0100
Chris Liddell <chris.liddell@artifex.com>
284f5fe121d8eb0a0f50a6f2465ee2f99a061018

> mkromfs needs linked to zlib when using shared zlib
> Ensure the compiler/linker command line parameter gets propagated from configure
> to the mkromfs build.
> Makefile.in

2017-06-12 13:15:17 +0100
Chris Liddell <chris.liddell@artifex.com>
98f6da60b9d463c617e631fc254cf6d66f2e8e3c

> Bug 698026: bounds check zone pointers in Ins_IP()
> base/ttinterp.c

2017-06-12 13:08:40 +0100
Chris Liddell <chris.liddell@artifex.com>
c7c55972758a93350882c32147801a3485b010fe

> Bug 698024: bounds check zone pointer in Ins_MIRP()
> base/ttinterp.c

2017-06-12 12:59:38 +0100
Chris Liddell <chris.liddell@artifex.com>
d2ab84732936b6e7e5a461dc94344902965e9a06

> Bug 698025: validate offsets reading TTF name table in xps
> xps/xpsfont.c

2017-06-10 14:06:49 +0100
Ken Sharp <ken.sharp@artifex.com>
f6507e828ddfe1f60645bc925bff9bedfdb306ce

> graphics library - fix memory leak regression
> Bug # 698005 "regression: commit 70cfc6afc42b9c299e9c05359f12455055105fac with Bug692720.pdf"
> Commit 70cfc6 created a path from a list of rectangles early in a clip,
> in order to minimise the number of times the path was created (creating
> it later caused it to be discarded and re-created multiple times)
> Unfortunately, as I feared at the time, this introduced a memory leak
> under certain conditions. When the clip_path is discarded we weren't
> counting down the reference to the path_list.
> With this commit Bug697270.pdf uses approximately the same amount of
> memory as it did before commit 70cfc6, but runs approximately 20%
> faster.
> The regular cluster run also seems to exhibit a further ~20% improvement
> in performance, presumably in addition to the existing 10% from the initial
> commit. Note, this *only* affects configurations where the clist is
> used.
> base/gxcpath.c

2017-06-08 16:57:25 +0100
Ken Sharp <ken.sharp@artifex.com>
a4f2cd23893cabe466d977668975987f925278d2

> pdfwrite - keep using /Subsample for /Indexed images when downsampling
> Bug #698000 "Inappropriate choice of downsampling filter for Indexed images"
> For Bug #693917 we checked the downsampling factor for the Subsample and
> Average downsampling filters and, if it was not an integer or nearly so,
> we forced the Bicubic filter instead.
> Unfortunately, this doesn't work well for image data in a /Indexed colour
> space.
> Instead this commit checks the colour space and, if its a /Indexed space,
> forces the downsampling factor to the nearest integer, and preserves the
> Subsample or Average filter.
> devices/vector/gdevpsdi.c

2017-06-08 15:43:42 +0100
Chris Liddell <chris.liddell@artifex.com>
2a9d6adb5239e797eec3358518950e49565730b0

> Bug 697983: avoid marking zero length glyph contours
> The file contains many glyphs with stray zero length contours dotted around the
> 'main body' of the glyph outline. When a text rendering mode involving stroke
> was used, these were resulting in the linecaps being drawn, and showing as
> extra dots around the gylphs.
> Force linecap to 'butt' when using a stroking text rendering mode to avoid this.
> Resource/Init/pdf_ops.ps

2017-06-07 14:55:12 +0100
Chris Liddell <chris.liddell@artifex.com>
cfde94be1d4286bc47633c6e6eaf4e659bd78066

> Bug 697985: bounds check the array allocations methods
> The clump allocator has four allocation functions that use 'number of elements'
> and 'size of elements' parameters (rather than a simple 'number of bytes').
> Those need specific bounds checking.
> base/gsalloc.c

2017-06-07 14:27:51 +0100
Robin Watts <robin.watts@artifex.com>
70cfc6afc42b9c299e9c05359f12455055105fac

> Bug 697679: Ensure clist playback correctly creates clip paths.
> Ghostscript clip paths consist of 3 parts:
> 1) A list of scan converted rectangles that union together to give
> the clipping region.
> 2) (Optionally) a path that represents the clipping region.
> 3) A path_list structure (a list of paths that when intersected
> together give the required clipping region).
> 3 is required for high level devices like pdfwrite (and the opvp
> device).
> Most of the code is at pains to preserve path_list as gx_cpaths are
> manipulated. The exception to this appears to be the clist code.
> The rectangle list is sent through the clist, but the path is not.
> Accordingly, the code to intersect a gx_cpath with another path
> checks to see if the path_list is valid on entry. If not, it
> synthesizes one from the rectangle list.
> This bug is caused by the fact that we end up intersecting a
> clip path 120000 times in a pattern clist playback. Each of those
> synthesizes a path from the rectangle list.
> The fix here is to make the pattern clist playback create the
> path_list each time it is replayed, meaning we have < 100 such
> operations.
> Thanks to Ken for his work on this, and for coming up with the
> initial version of this patch.
> base/gxclrast.c
> base/gxcpath.c
> base/gxpath.h

2017-06-03 18:50:05 +0100
Ken Sharp <ken.sharp@artifex.com>
0af88bdacdd8962244ac0a538c78b56bd5cc9376

> pdfwrite - fix customised doumentUUID
> Bug #697977 "document UUID gets truncated"
> The code writing out a user-specified documentUUID had an error, failing
> to account for the 'uuid:' prefix.
> Credit to Axel Holewa for finding the preoblem and suggesting the fix.
> devices/vector/gdevpdfe.c

2017-05-19 18:12:00 +0100
Robin Watts <robin.watts@artifex.com>
9c94340cd251ead99b4ae9121d1138c83be9a5df

> PXL: Optimise 1 pixel wide image handling.
> If we are given a 1xH image, we'd rather reflect it to be
> an Hx1 image so that it gets passed through the image code
> as a single scanline. This allows things like collation of
> runs of matching pixels to work far better.
> In particular this improves page mode performance for j11.prn.
> pcl/pxl/pximage.c

2017-05-29 16:19:39 +0100
Chris Liddell <chris.liddell@artifex.com>
5f53dbc3e917d44e92619f831ba06be7944b5471

> Bounds check buffers for downloaded glyphs in PCL.
> For downloaded fonts, there were several buffer overreads reported by valgrind
> when interpreting Intellifont glyph descriptions.
> This adds using the (already existing) length field to bounds check when we
> interpret the glyph.
> pcl/pcl/pcsfont.c
> pcl/pl/plchar.c
> pcl/pl/plfont.c
> pcl/pl/plfont.h
> pcl/pl/pllfont.c
> pcl/pl/plulfont.c
> pcl/pxl/pxerrors.c
> pcl/pxl/pxfont.c

2017-05-29 16:22:19 +0100
Chris Liddell <chris.liddell@artifex.com>
fe6ed9f54a02357e01c1f8c517b6af831e5f59ae

> Ensure a FAPI instance is attached to a cloned font
> It was possible for a cloned font to be missing the FAPI server attached to the
> 'parent' font. Add in a pl_fapi_passfont() call so it's guaranteed to be
> available.
> pcl/pcl/pcsfont.c

2017-05-31 20:51:00 +0100
Robin Watts <robin.watts@artifex.com>
bc12dc36623f3eb3c553ea1455cf1fd84d10b114

> Avoid needless clip path recalculations.
> While investigating Bug 697679, I spotted that clip_call_fill_path
> was being called with a non NULL pcpath, thus triggering a 'slow'
> rebuild of the clipping path.
> In at least some of these cases, pcpath pointed to an invalid
> clipping path. I believe this means we might as well have used
> the fast route!
> base/gxclip.c

2017-05-31 20:14:55 +0100
Robin Watts <robin.watts@artifex.com>
9ee2adefdfc9a12bf71acd1e08e88b8cc8af0502

> Avoid calling the same function twice.
> Not really expecting any huge speed benefit from this, but
> it's silly to call it twice with the same args.
> base/gxcpath.c

2017-05-31 21:44:41 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
2cebfeb7c91d5bcf916bc2c51d32a213f0ca776d

> Bug 694646: Fix SEGV due to missing FontName attribute.
> pxSetFont allowed for an optional FontName attribute which meant it tried
> to set a font using NULL. This function has been updated to check that
> FontName, CharSize and SymbolSet are not NULL before trying to use them.
> pcl/pxl/pxfont.c

2017-05-31 12:28:43 +0100
Robin Watts <robin.watts@artifex.com>
e57b2aafe5bf09bb7e7df5f4608a4910145553b2

> Bug 697970: Solve underflow/overflow problems in new scan converter.
> The test file asks us to fill a line with one end at 0x7fffffff,
> using 'any part of a pixel'. In order to calculate the index table
> the existing code 'expands' this vertical area by 0x7f to allow
> for rounding within a pixel. This leads to 0x8000007e, which
> is of a different sign.
> Correspondingly the vertical ranges touched by the lines appear
> different in the indexing and marking phases.
> To fix this we rejig the line calculations to avoid this
> difference by more carefully doing the expansion.
> Thanks to Kamil Frankowicz for doing the fuzz testing that lead
> to this bug/fix.
> base/gxscanc.c

2017-05-31 13:50:32 +0100
Ken Sharp <ken.sharp@artifex.com>
9e621d6ffb0e29c5de8331bf2c95003c8cf85941

> PDF interpreter - apply Optional Content /Usage dictionaries
> Bug #696076 "Ghost script 9.16/9.15 print PDF layer even if print state is "Never Print""
> We currently only apply the /OFF (or /ON) entries from the Optional
> Content Properties (/OCProperties) which is quite a high level and hence
> low granularity control.
> This commit adds processing of the /Usage dictionary; any ordinary
> Optional Content (not OCMD) which is not set to /OFF in the OCProperties
> is checked for the existence of a /Usage dictionary. We then check for
> either a /Print or /View key in the dictionary depending on the setting
> of the -dPrinted command line switch. If the relevant key is present
> then we check for a ViewState key and use that to determine whether the
> Optional Content should be rendered or not.
> Note that if -dPrinted is not set on the command line then the interpreter
> will attempt to guess. If the current device has OutputFile set then
> the interpreter will assume that it should consider 'Print' keys. If it
> is not present in the device, then the interpreter will assume that it
> should consider 'View' keys.
> This causes the PDF file Bug690364.pdf to render radically differently.
> This is because much of the content is set to not print, and a small
> amount of extra data is set to render only when printed. Because the
> cluster uses an OutputFile, we assume that we should behave as if
> printing.
> Resource/Init/pdf_draw.ps

2017-05-31 11:24:40 +0100
Robin Watts <robin.watts@artifex.com>
33cf871a82e0fd9a0ebfed14317a2fa0f40e1e9d

> Bug 697748: Fix misspelled alignment attribute in SSE code.
> The SSE thresholding code relies on a buffer being 16 byte aligned.
> To achieve this we use a compiler attribute to force alignment
> to 16 bytes.
> MSVC uses "align(16)", but gcc etc uses "aligned(16)".
> We were using "align(16)" for both. Fix this in the macro here.
> Thanks to Timo Teras for spotting the problem and suggesting the
> fix.
> base/gxht_thresh.c

2017-05-30 10:30:05 +0100
Ken Sharp <ken.sharp@artifex.com>
b883b8fc62ec6bc630d5f88abef0d7799efa6687

> pdfwrite - Don't assume param list strings are NULL-terminated
> Bug #697948 "(Add an ID to memory allocations.) breaks PDF/A output"
> The bug description is misleading; in fact the problem is that the code
> for reading a flag numeric value from a string parameter was assuming
> the parameter was NULL_terminated, when in fact it is not.
> Depending on exactly how the memory layout happened to be, the bytes
> following the parameter may or may not be NULLs, or ASCII digits. If it
> so happened that the trailing bytes were ASCII digits, it was possible
> for an incorrect Flag value to be parsed, which could lead to an error
> being flagged.
> This commit just copies the actual number of bytes in the parameter
> string to a temporary stack-based character buffer, NULL terminates the
> buffer and reads the Flag value from there.
> devices/vector/gdevpdfm.c

2017-05-28 21:46:26 -0600
Henry Stiles <henry.stiles@artifex.com>
4226202adec2a3f3a416e1986e8630bf7ca3bdc7

> Fix Bug 694633 fuzzing segmentation fault.
> Return an error if the GL/2 parser runs out of data while processing
> a macro. If within a macro, unlike the normal data stream, the GL/2
> commands already have access to all of the data.
> pcl/pcl/pgparse.c

2016-07-04 09:28:06 +0100
Ken Sharp <ken.sharp@artifex.com>
7918a01dd37bc383e61ae0b237341e69286dc83c

> PDF interpreter - Move ExtGState parameters into the regular graphics state
> Bug #696511 - "Move ExtGState parameters into the regular graphics state"
> A long time ago a decision was made not to replicate the PDF ExtGstate
> parameters in the graphics state. This has had long term painful consequences
> because we were unable to do a gsave/grestore to simply preserve
> parameters but had to jump throuhg a lot of hoops. Amongst other problems
> has been confusion over when exactly a change in colour has taken place.
> With this commit the ExtGState parameters are moved into the graphics state
> and obey gsave and grestore.
> This extensive commit was worked on in the PDF_gstate branch and the history
> is preserved in that branch.
> This does introduce a few differences in the test suite;
> There are a few cases where broken files (recursive SMasks) now render
> slightly differently.
> Some files now exhibit progressions, especially with CMYK or DeviceN output
> devices, this is because the 'default' colour space was incorrect, the code
> was using DeviceGray instead of the device's colour space, and this makes
> a difference for some types of transparency blending when the Group does
> not specify a Blending space.
> A few other files demonstrate progressions because a change in colour now
> takes place before an error occurs.
> Resource/Init/pdf_draw.ps
> Resource/Init/pdf_font.ps
> Resource/Init/pdf_main.ps
> Resource/Init/pdf_ops.ps
> base/gsstate.c
> base/gsstate.h
> base/gstrans.c
> base/gstrans.h
> base/gxgstate.h
> psi/igstate.h
> psi/int.mak
> psi/zcolor.c
> psi/zcssepr.c
> psi/zgstate.c
> psi/zmatrix.c
> psi/ztrans.c
> psi/ztype.c

2017-05-29 11:22:34 +0100
Ken Sharp <ken.sharp@artifex.com>
2e2a9d851c73192739c9227ef0030f3ba3e7b6fd

> PDF interpreter - Don't render closed Popup annotations, synthesise missing Popup Appearances
> Bug #697951 "MuPDF - Arguably incorrect annotation"
> Although this is a MuPDF bug, it showed a couple of problems in Ghostscript
> Firstly; Popup annotations which have /Open false should not be rendered
> Secondly; Popup annotations with no /Open should be treated as ?open False
> Finally, Popup annotations with no /Appearance were not rendered, unlike
> other annotation types we were not synthesising an Appearance.
> This commit addresses all 3 of these, and shows progressions with:
> tests_private/pdf/PDF_1.7_FTS/fts_32_3232.pdf
> tests_private/pdf/sumatra/1312_-_comments_not_displayed.pdf
> tests_private/pdf/sumatra/1571_-_popup_annotations.pdf
> tests_private/pdf/sumatra/embedded_go-to_actions.pdf
> Resource/Init/pdf_draw.ps

2017-05-28 21:27:41 -0600
Henry Stiles <henry.stiles@artifex.com>
3ded6c3b28a1b183a492ada2f2a3970953f3d060

> Increment the PJL stream pointer for illegal characters.
> When an illegal character is encountered within a PJL command we exit
> with end of job. With recent changes it is necessary to increment the
> stream pointer as well because the PJL interpreter is reinvoked upon
> UEL resulting in an infinite loop.
> pcl/pl/pjparse.c

2017-05-24 19:29:57 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
3ebffb1d96ba0cacec23016eccb4047dab365853

> Bug 697934: Fix SEGV due to error code being ignored.
> The return code from jbig2_decode_text_region was being ignored so the
> code continued to try and parse the invalid file using incomplete/empty
> structures.
> jbig2dec/jbig2_symbol_dict.c

2017-05-26 17:05:29 +0100
Ken Sharp <ken.sharp@artifex.com>
5cf06167c248f345a1042c421cc2f5f741bf281d

> pdfwrite - correctly set the BPC for the image downsampling filter
> Bug #697944 "Segmentation fault with -sDEVICE=pdfwrite"
> The code to call the downsampling filter resizes the input to the filter
> to 8BPC, and then resizes the output from the filter back to whatever
> the required depth was.
> But the stream state for the downsampling filter was left with the
> original BPC. This led to the Mitchell filter calculating two parameters
> sizeofPixelIn and sizeofPixelOut incorrectly as 0 (4/8 is 0 in integer
> arithmetic). Later the code used sizeofPixelOut being 1 to write 1 byte
> output data, but if the value was not 1 it wrote 2 bytes of output.
> This causes a buffer overflow in the callers buffer, leading to memory
> corruption and an eventual seg fault.
> This commit simply sets the BPC in the stream state correctly to reflect
> the fact that the intermediate data is always 8 bits.
> devices/vector/gdevpsdi.c

2017-05-26 13:13:16 +0100
Ken Sharp <ken.sharp@artifex.com>
6cae884b66944318c34e17992c628a246dda18aa

> Vector devices - work around TrueType subsetting bug corrupting metrics tables
> Bug #697376 "Adobe Distiller can't handle EPS files created with eps2write - limitcheck error"
> The TrueType writing code for the vector devices continues to produce
> problems. We should rewrite this code but realistically that is still
> some way off.
> In this case the code was attempting to minimise the size of the VMTX
> and HMTX tables by only writing out the metrics for the glyphs we were
> actually including in the font (unused glyphs remain as references in the
> font, but have no outlines).
> This is not valid in TrueType, the metrics tables must contain an entry
> for each glyph. Looking at the code it should have been clear that this
> was nonsense, but apparently it was missed.
> We can save a minimal amount of space by writing out the metrics for all
> the glyphs up to the last used one, and then writing just a 0 side
> bearing for each remaining glyph, but the space saving is small. So I've
> chosen simply to disable the subsetting of metrics and copy the entire
> table.
> devices/vector/gdevpsft.c

2017-05-26 11:27:44 +0100
Chris Liddell <chris.liddell@artifex.com>
bf949eaff89ac71b30d4a93638716e2c63090b0a

> Bug 697949: check parameters for .setuseciecolor
> psi/zcolor3.c

2017-05-24 08:54:25 -0700
Ray Johnston <ray.johnston@artifex.com>
d57e9332127baa82fa8083c0927498f412aa48d8

> Fix tags with transparency.
> Only change the tag if the alpha_s (source alpha) is > 0. If it is 100%
> and the BlendMode is Normal, then we use the object's tag, if not, we
> combine with the existing tag (in the backdrop/destination) by OR'ing
> the bits together. Note that for some Blend modes, the pixel may only
> have contributions from the source or from the destination, but we don't
> use that because it could change the tag within an object (e.g, gradient
> or image) depending on the color value causing unexpected shifts in the
> tag value.
> base/gdevp14.c

2017-05-24 16:26:55 +0100
Ken Sharp <ken.sharp@artifex.com>
2e3ca2386ae8045a084dc862e7e22f3df1341d0e

> device subclassing fix reference counting and stype patching
> We patch the memory manager's 'stype' on the original device's memory
> when we subclass the device, but had missed resetting that when we
> unsubclass the device, restoring the child device. This left the memory
> manager stype set incorrectly.
> Secondly it transpires that we can alter the reference count of the
> parent, so that it differs from the child, and we hadn't accounted for
> that. If the reference count of the child (subclassed) device differs
> from the parent (subclassing) device at the point where we unsubclass
> the device, we need to make sure we retain the correct reference
> count. Otherwise we can end up with saved gstates pointing to a device
> which has been freed.
> base/gdevdflt.c

2017-05-23 13:05:42 +0100
Ken Sharp <ken.sharp@artifex.com>
b13ef3074dd164d2317cd5d03331b8de96ea98d0

> pdfwrite - unescape specially escaped names in pdfmark operations
> Bug #697885 "Commented pdf-file converting with 9.21 comments are omitted but not with <= 9.20 versions"
> We now preserve (where possible) annotations from input PDF files
> into the output file, where previously these were effectively 'folded into'
> the page content stream.
> In order to do this for Appearances, we need to create a separate Form
> XObjet which we reference from the annotation. Doing this requires
> some underhandedness in the PDF interpreter, where me make use of
> a non-standard 'escape' consisting of tow NULL (0x00) bytes before the
> name of the Form XObject, and one NULL after.
> This works well, but ended up copying the NULL bytes into the output
> PDF file. This is actually legal, but it seriously confused the
> Linearisation code when it tried to alter the object numbers in order
> to write them in the correct xref table.
> Since these NULLs are not required and confuse the code, we now take
> extra action to remove them from the string we create working from the
> pdfmark data.
> devices/vector/gdevpdfr.c

2017-05-22 10:18:56 +0100
Chris Liddell <chris.liddell@artifex.com>
b914c5de71fcc7675f40d8557975ec87cd46fced

> Bug 697910: handle Type 1 fonts with 'embedded' Type 1 fonts
> The test file for this bug has a Type 1 font stream (for an oblique version of
> a font) which 'contains' a second (non-oblique) Type 1 font, from which the
> 'outer' font pulls the CharStrings (the oblique version contains its own
> subrs to make the regular font into the oblique font).
> A previous fix for a broken Type 1 font broke support for the above (valid)
> form of Type 1 font. The broken Type 1 ends up putting various required keys
> in the current dictionary, rather than in the font dictionary.
> The previous fix pushes a sacrificial "top dictionary" before executing the font
> stream. It identifies the broken font by spotting that required keys exist in
> a dictionary on the dictionary stack (rather than in the font dictionary on the
> operand stack on the call to definefont). When it encounters the broken font
> layout, it copies the required keys into that sacrificial top dictionary, and
> uses that as the font dictionary.
> The Type 1 inside another Type confuses that code, and ends up creating one font
> from the "inner" Type 1.
> This commit reverses the logic: it checks for required keys missing from the
> font dictionary, and if any are missing, it tries to find them on the
> dictionary stack.
> This is slightly less robust than the original solution, since it assumes that
> the font has created a font dictionary, but has defined required keys before
> pushing it onto the dictionary stack. A font that fails entirely to create
> a font dictionary will fail.
> Obviously, a solution for broken fonts that causes (admittedly strange) but
> valid fonts to fail is unacceptable. If we find a case of a font that is broken
> as described above, we can revisit this fix.
> Resource/Init/pdf_font.ps

2017-05-17 15:27:23 -0600
Henry Stiles <henry.stiles@artifex.com>
d7cade08ad36382a0ed5dfa72fcb9a0e9a822417

> Remove shared device psi implementation and improve documentation.
> The experimental gpdl build now only supports running PostScript and
> PDF in a seperate context with it's own device using the normal API.
> At this time it only runs files detected as PostScript or PDF in the
> default device with no arguments. The previous setup did not work
> properly and if we are to have a shared device it should be
> implemented anew anyway.
> Also improve the documentation for how languages plug into the
> language switching system.
> gpdl/psi/psitop.c
> pcl/pcl/pctop.c
> pcl/pl/plimpl.c
> pcl/pl/plmain.c
> pcl/pl/pltop.h
> psi/imain.c
> psi/zdevice.c

2017-05-11 13:56:04 -0600
Henry Stiles <henry.stiles@artifex.com>
00d5670774e9c56cb8bf6e9f877756c82d10536e

> Clean up documentation and simplify language implementation procs.
> pcl/pcl/pctop.c
> pcl/pl/pltop.h
> pcl/pxl/pxtop.c
> xps/xpstop.c

2017-05-08 17:16:56 -0600
Henry Stiles <henry.stiles@artifex.com>
d585f6b8b2150c70a4fdc8d2b4d582012411f586

> PL API: Remove separate interpreter instances.
> The previous design was complicated by supporting multiple instances
> of each language which will never be used, so we can remove the
> interpreter instance type and access each language through the
> implementation pointer.
> gpdl/psi/psitop.c
> pcl/pcl/pcimpl.c
> pcl/pcl/pcstate.h
> pcl/pcl/pctop.c
> pcl/pcl/pctop.h
> pcl/pl/pjparse.c
> pcl/pl/pjparse.h
> pcl/pl/pjparsei.c
> pcl/pl/pjtop.c
> pcl/pl/pjtop.h
> pcl/pl/plapi.c
> pcl/pl/plimpl.c
> pcl/pl/plmain.c
> pcl/pl/plmain.h
> pcl/pl/pltop.c
> pcl/pl/pltop.h
> pcl/pl/realmain.c
> pcl/pxl/pxstate.h
> pcl/pxl/pxtop.c
> xps/xpstop.c

2017-02-21 20:42:15 -0700
Henry Stiles <henry.stiles@artifex.com>
b6689161cc0dcbbb0f029a91708ac2724570a63d

> PL API: make PJL an implementation and several miscellaneous improvements.
> It is simpler to have PJL selected as an implementation upon seeing
> the @PJL identifier or detecting a UEL in the input stream.
> Previously we always entered the PJL interpreter after exiting another
> language. Also, added stubs for the "run_string" api.
> pcl/pl/pjparsei.c
> pcl/pl/pl.mak
> pcl/pl/plapi.c
> pcl/pl/plapi.h
> pcl/pl/plcursor.c
> pcl/pl/plmain.c
> pcl/pl/plmain.h
> pcl/pl/realmain.c

2017-02-03 13:04:53 -0700
Henry Stiles <henry.stiles@artifex.com>
611289048a343ec07eb3ec1dd19aa922211f200d

> Remove cursor renewal.
> This hack was used so the languages could return without consuming
> data which is wrong. The underlying problem was the XL interpreter
> returning 0 when it should have been returning an exit code.
> pcl/pl/plcursor.c
> pcl/pl/plcursor.h
> pcl/pl/plmain.c
> pcl/pxl/pxtop.c

2017-01-30 17:10:50 -0700
Henry Stiles <henry.stiles@artifex.com>
3eb111d09610e72106af19b28a90982b14dc55dc

> PL API: cleanup unused functions replace by API calls.
> pcl/pl/gpcl6dll32.def
> pcl/pl/gpcl6dll64.def
> pcl/pl/gpdldll32.def
> pcl/pl/gpdldll64.def
> pcl/pl/gxpsdll32.def
> pcl/pl/gxpsdll64.def
> pcl/pl/plapi.h
> pcl/pl/plmain.c
> pcl/pl/plwmainc.c

2017-01-29 08:08:56 -0700
Henry Stiles <henry.stiles@artifex.com>
87af13a97cc6868dd31379e446f089b1dd9e101a

> PLAPI: Use api for windows display program.
> pcl/pl/pl.mak
> pcl/pl/plapi.c
> pcl/pl/plapi.h
> pcl/pl/plmain.c
> pcl/pl/plwmainc.c

2017-01-02 10:20:58 -0700
Henry Stiles <henry.stiles@artifex.com>
761bf52f3591219b8262549d9a337d0a3d71fd61

> PL API: add plapi implementation.
> Fills out the plapi implementation and changes the default command line
> program to use the new api.
> pcl/pl/pl.mak
> pcl/pl/plapi.c
> pcl/pl/plapi.h
> pcl/pl/plmain.c
> pcl/pl/plmain.h
> pcl/pl/realmain.c

2016-12-29 08:55:44 -0700
Henry Stiles <henry.stiles@artifex.com>
47d3e1e7ec973fcead1f88cf24e4bdc430123592

> Memory leak check.
> pcl/pl/plmain.c

2016-12-29 08:38:42 -0700
Henry Stiles <henry.stiles@artifex.com>
0877d850a63fe57ad60fac065ae7675817ba7a4f

> Rename pltoputl to plcursor.
> Only the cursor code remained in pltoputl.
> pcl/pl/pl.mak
> pcl/pl/plcursor.c
> pcl/pl/plcursor.h
> pcl/pl/plmain.c

2016-12-23 11:10:31 -0700
Henry Stiles <henry.stiles@artifex.com>
ebd2e51a648e0657eb9bd2464be01ad09f9b01e0

> Move all cursor code to single module.
> Not sure why this was spread out in plmain.c and pltoputl.c.
> pcl/pl/pl.mak
> pcl/pl/plmain.c
> pcl/pl/pltoputl.c
> pcl/pl/pltoputl.h

2016-12-22 15:09:31 -0700
Henry Stiles <henry.stiles@artifex.com>
2ec6f74df2fa14776182a75d306f3028170f5715

> Make the main instance opaque.
> Needed to reduce spreading dependencies resulting from including
> plmain.h.
> pcl/pcl/pctop.c
> pcl/pl/plmain.c
> pcl/pl/plmain.h
> pcl/pxl/pxtop.c
> xps/xpstop.c

2016-12-21 12:03:57 -0700
Henry Stiles <henry.stiles@artifex.com>
6850869002f40634a2af0e6a1c939d3ed385f217

> Factor out common icc code into 1 pl procedure.
> pcl/pcl/pctop.c
> pcl/pl/plmain.c
> pcl/pl/plmain.h
> pcl/pxl/pxtop.c
> xps/xpstop.c

2016-12-21 10:17:40 -0700
Henry Stiles <henry.stiles@artifex.com>
5c663ee7cf06f0887404709aae45141fb3049817

> Remove unused vmspaces and nogc references.
> pcl/pcl/pcl.mak
> pcl/pcl/pcpage.c
> pcl/pl/plmain.c
> pcl/pl/plmain.h
> pcl/pl/pltop.c
> pcl/pxl/pxl.mak
> pcl/pxl/pxtop.c

2016-12-19 21:43:08 -0700
Henry Stiles <henry.stiles@artifex.com>
6a20606c8f5ce3f8c0ce80c84a831ed4a98f2156

> PL API: functions to exit and delete the main instance, like gs.
> pcl/pl/plmain.c
> pcl/pl/plmain.h

2016-12-18 14:50:20 -0700
Henry Stiles <henry.stiles@artifex.com>
2a3bc2153fd93542914b83df5d94dbafdbe257ec

> Fix the gpdl build, PCL and XPS language switching for testing.
> This uncovered a problem with the PJL state and the command line. PJL
> should not be initialized for each file (pl_main_run_file()) if PJL
> was issued on the command line (-J switch) otherwise it should be
> initialized.
> pcl/pl/plimpl.c
> pcl/pl/plmain.c
> pcl/pl/plmain.h

2016-12-17 20:47:14 -0700
Henry Stiles <henry.stiles@artifex.com>
37d1286a66bd80a471aa9ac0a166bc291a8318db

> PL API - Reorganizing main procedure.
> Splits out routines for running a file and inializing with arguments,
> consistent with gs API. The allocator module was removed, the
> procedures were to simple to be separated out. Lots of trivial clean
> up as well.
> pcl/pl/pl.mak
> pcl/pl/plalloc.h
> pcl/pl/plmain.c
> pcl/pl/plmain.h

2016-12-15 11:11:13 -0700
Henry Stiles <henry.stiles@artifex.com>
f1dd6db9f969d0a6d23baeb781f5082f8d0f78e4

> PL API: deprecate error string buffers which were never used.
> pcl/pl/plmain.c

2016-12-15 10:32:49 -0700
Henry Stiles <henry.stiles@artifex.com>
bd95aa0cf7a5eef3e37c4bfa29ec32debd6b954d

> PL API: continues previous commit removing pre and post page operations.
> pcl/pl/plmain.c

2016-12-14 13:01:07 -0700
Henry Stiles <henry.stiles@artifex.com>
e9ff0dcf1892086276872e868a254d012ab48702

> PL API: continue previous commit, purge pre and post page closures.
> pcl/pcl/pctop.c
> pcl/pl/pjparsei.c
> pcl/pl/plmain.c
> pcl/pl/pltop.c
> pcl/pl/pltop.h
> pcl/pxl/pxtop.c
> xps/xpstop.c

2016-12-14 12:34:40 -0700
Henry Stiles <henry.stiles@artifex.com>
97f9904dc5d8f45cbca93b02098eac077bca7f5c

> PL API: remove instance page count and refactor output page.
> The page count is no longer needed in the main instance, it is now
> available in the device. The output page closures were convoluted and
> never used, factor out a common procedure to output the page,
> pl_finish_page(), to be used by PCL, PXL and XPS.
> pcl/pcl/pctop.c
> pcl/pl/plmain.c
> pcl/pl/plmain.h
> pcl/pxl/pxtop.c
> xps/xpstop.c

2016-12-13 16:38:10 -0700
Henry Stiles <henry.stiles@artifex.com>
23d85c19be2700d098d133f87a40e24031a9c64e

> Remove set client instance procedure.
> Unnecessary complexity between the main program and the individual languages.
> pcl/pcl/pctop.c
> pcl/pl/pjparsei.c
> pcl/pl/plmain.c
> pcl/pl/plmain.h
> pcl/pl/pltop.c
> pcl/pl/pltop.h
> pcl/pxl/pxtop.c
> xps/xpstop.c

2016-12-09 10:34:42 -0700
Henry Stiles <henry.stiles@artifex.com>
e14474ba4eff1cf7c42ff8888a3daa6dc6c83aaa

> PL API Remove device_memory main instance member.
> This was only needed for the language switch build with PS and PDF
> which is no longer supported.
> gpdl/psi/psitop.c
> pcl/pcl/pctop.c
> pcl/pl/pjparsei.c
> pcl/pl/plmain.c
> pcl/pl/plmain.h
> pcl/pl/pltop.c
> pcl/pl/pltop.h
> pcl/pxl/pxtop.c
> xps/xpstop.c

2016-12-08 17:33:41 -0700
Henry Stiles <henry.stiles@artifex.com>
3e026d15093a2a7279c3c4e46b3e24cb5ee11370

> PL API: Add PJL instance to PDL array.
> Previously the PJL interpreter was separated out from the other
> interpreters now it is simply known to be the 0'th entry in the array
> of languages. Having it separate would yet another member in the main
> instance with the new API.
> pcl/pl/pjparsei.c
> pcl/pl/plimpl.c
> pcl/pl/plmain.c

2016-12-08 08:40:56 -0700
Henry Stiles <henry.stiles@artifex.com>
ce20a5af6c0d72ae1d0198f3c44e2b0a0d0a09d6

> PL API: remove pdl implementation array references.
> A copy of a reference to the array was used in varous places, yet it
> is a global constant, so reference the global directly.
> pcl/pl/plmain.c
> pcl/pl/plmain.h

2016-12-08 07:34:26 -0700
Henry Stiles <henry.stiles@artifex.com>
a3ad76f1872b46390328c31102c9b6e6bf25d776

> PL API: remove plplatf module.
> This makes the startup more consistent with gs.
> pcl/pl/pl.mak
> pcl/pl/plmain.c
> pcl/pl/plplatf.c
> pcl/pl/plplatf.h
> pcl/pl/plplatfps.c

2016-12-07 18:30:04 -0700
Henry Stiles <henry.stiles@artifex.com>
587bfc08b8e833c2aa45284fe558a8d9b7116f4e

> PL API: move argument state to the main instance.
> pcl/pl/plmain.c
> pcl/pl/plmain.h

2016-12-07 16:53:00 -0700
Henry Stiles <henry.stiles@artifex.com>
7f856d0f9de2145e7533ad239de618506ae145e6

> PL API: move device parameter list to the main instance.
> pcl/pl/plmain.c
> pcl/pl/plmain.h

2016-12-07 13:40:09 -0700
Henry Stiles <henry.stiles@artifex.com>
5ce6334ed0996ccd2d52ac81d273a78293487bfd

> PL API: access main instance parameters directly.
> pcl/pcl/pctop.c
> pcl/pl/plmain.c
> pcl/pl/plmain.h
> pcl/pl/pltop.h
> pcl/pxl/pxtop.c
> xps/xpstop.c

2016-12-07 09:38:45 -0700
Henry Stiles <henry.stiles@artifex.com>
6ab1d85eef2b821dcb08f8b82622fa92be1be1af

> PL API: make main instance the "top of the system"
> pcl/pl/plmain.c

2016-11-30 19:52:57 -0700
Henry Stiles <henry.stiles@artifex.com>
9a7d93d3f71ec4a92a726998f1acac85489c277e

> PL API Make language read buffer a member of the language instance.
> pcl/pl/plmain.c
> pcl/pl/plmain.h

2016-11-29 17:26:55 -0700
Henry Stiles <henry.stiles@artifex.com>
1130f6ac765de4c6d202281496e1ad62b8370460

> PL API: refactor initialization to be more like gs.
> pcl/pl/plmain.c

2016-11-28 11:56:01 -0700
Henry Stiles <henry.stiles@artifex.com>
6cf194e23355ed75ddd248bde3e4849c8ad1bfcf

> SVG is no longer supported, remove test file.
> Also adds an xps tiger created by xpswrite.
> pcl/tools/tiger.svg
> pcl/tools/tiger.xps

2016-11-27 15:35:38 -0700
Henry Stiles <henry.stiles@artifex.com>
46a472c247dd33d53124b79204594c707c99e134

> PL API - remove PJL memory allocator.
> pcl/pl/plmain.c

2016-11-18 13:47:46 -0700
Henry Stiles <henry.stiles@artifex.com>
c672305a6e45a39c446918b5c4899c9763fc8f5b

> PL API - make "universe" part of instance.
> The "universe" is soon to be deprecated but for now include it in the
> instance so it is available to all api functions.
> pcl/pl/plmain.c
> pcl/pl/plmain.h

2016-11-17 16:43:19 -0700
Henry Stiles <henry.stiles@artifex.com>
c5b13ee9953a4d482ab3bce112c61f19cf758a62

> PL API - Dynamically allocate main instance.
> pcl/pl/plmain.c

2017-05-19 11:08:38 +0100
Ken Sharp <ken.sharp@artifex.com>
119ec77d4e44e3861a376323ed14466b28b2f4bf

> PDF interpreter - better match the behaviour of Acrobat with invalid /Mask
> Bug #697919 "Invalid Mask values cause content to not render"
> The sample file has a 1 bit per component image with a Mask, the values
> in the mask array are [204 255]. Since this is a 1 bit image, clearly the
> only valid values are 0 or 1.
> Previously (bug #692852) we have specifically treated /Indexed spaces
> with an invalid Mask specially, so that if the initial value is out
> of range we ignore the Mask array, otherwise we use the initial value
> and set the second to 1.
> Also previously we have bug #689717 which is, in fact, an identical
> case to this one. In that case we have code which clamps the two values
> to 'max - 1' which works for that case. In fact, it works too well for
> that case, and produces content which is almost certainly desired by
> the author, but which Acrobat does not render.
> In this commit we make the DeviceGray case match the /Indexed case, I
> rather suspect that for 1 bit images Acrobat *never* uses the /Mask
> array values, but I don't have an example in any other colour space. So
> for now we'll leave them alone.
> This causes the file for Bug 689717 to render with content 'missing',
> however it does now match Acrobat. I do not think we can reasonably match
> Acrobat's result for this bug without also matching it for the prior bug.
> Resource/Init/pdf_draw.ps

2017-05-15 14:34:17 +0100
Robin Watts <robin.watts@artifex.com>
5501c28dbb1814aa869cb5132e52d5bcf090ec6e

> New chunk memory manager.
> Based off the original chunk heap managers code, this uses splay
> trees for free blocks to speed searching. (Dual, top-down,
> semi-splaying trees, one ordered on size, and another on location).
> Adding this memory manager runs into a problem with pdfwrite.
> Because pdfwrite is not entirely behaved with memory freeing, it
> can free the same blocks more than once. This primarily happens
> in pdf_close.
> The existing chunk memory manager seems to get away with this by
> luck, whereas this revised version sees SEGVs in some {pcl,xps} ->
> pdfwrite tests.
> Accordingly, we add a special fudge; if we call gs_defer_frees(1)
> then the memory manager defers freeing blocks by putting them
> onto a linked list (but only once). When we then call
> gs_defer_frees(0), the manager finalizes all the blocks on the
> list (which may in turn add new blocks to the list!). Once
> all the blocks have been finalized, they are then freed.
> "All" the pdfwrite double frees come from inside pdf_close (or
> all the ones I have seen at least). Accordingly we bracket
> pdf_close with gs_defer_frees(1) and gs_defer_frees(0).
> base/gsalloc.c
> base/gsmalloc.c
> base/gsmchunk.c
> base/gsmchunk.h
> base/gsmemory.h
> base/gsmemret.c
> devices/vector/gdevpdf.c

2017-05-18 16:18:25 +0100
Robin Watts <robin.watts@artifex.com>
b69d68995d065d61b2defe919c038cf9cf60b598

> Fix buffer overrun in xpspath.c
> Seen with tests_private/xps/sumatra/buffer_overflow_in_path_handling.xps
> Specifically:
> bin/gxps -sOutputFile=out.pdf -sDEVICE=pdfwrite -r72 -Z: -dNOPAUSE
> -dBATCH -dClusterJob
> tests_private/xps/sumatra/buffer_overflow_in_path_handling.xps
> xps/xpspath.c

2017-05-18 15:59:22 +0100
Ken Sharp <ken.sharp@artifex.com>
1e0088aa8d8e65ad7455d35e9280fe978163534b

> Bug 696412 - Fix seg fault in pdf_end_transparency_mask
> Bug #696412 "Seg faults found by fuzzing in pdf_end_transparency_mask"
> The file is (of course) badly corrupted, leading to us receiving a
> 'end' for a transparency mask when we did not previously receive a
> 'begin'.
> The code in pdf_end_transparency_mask assumed that the prior begin would
> have created a soft mask dictionary, but of course if we didn't see the
> begin then we don't have one.
> Check for this and simply return an error instead of trying to
> dereference the NULL pointer.
> devices/vector/gdevpdft.c

2017-05-18 14:10:56 +0100
Ken Sharp <ken.sharp@artifex.com>
58aeac2fbd1489c797351a9b53134e40729b661c

> Bug 696377 - Fix a seg fault in subclassing
> Bug #696377 "Seg faults found by fuzzing in default_subclass_create_compositor"
> With a sufficiently corrupted file it was possible to reach this point
> with a mismatch of transparency group begin/end. This could lead to
> us having the compositor device being NULL which we would then try to
> dereference.
> Simply check the compositor device and don't try to dereference it if
> its NULL.
> This was only reproducible on the commit mentioned in the bug report,
> after fixing it the file continued on to seg fault in a completely
> different place. However I believe this is due to the fact that the
> corrupted file leads to a mismatch of push/pop groups for transparency
> and Michael has addressed that with later commits. The file runs to
> completion (with *many* errors) on current code.
> base/gdevsclass.c

2017-05-14 03:34:57 +0800
Sebastian Rasmussen <sebras@gmail.com>
56c26790af78f94c08a595e0c9da527418c47614

> Bug 697866: Do bounds checking of read data.
> Credit to Ken for suggesting what bounds to check.
> jbig2dec/jbig2_text.c

2017-05-14 03:37:11 +0800
Sebastian Rasmussen <sebras@gmail.com>
d39d31168cec8a08ac1e5c44c95925fecb087173

> Make clipping in image compositing handle underflow.
> jbig2dec/jbig2_image.c

2017-05-14 12:36:28 +0800
Sebastian Rasmussen <sebras@gmail.com>
a328d6377bac5268d3a8c071fbbf54c66e07de3a

> Fix memory leak in case of error.
> jbig2dec/jbig2_text.c

2017-05-14 03:31:50 +0800
Sebastian Rasmussen <sebras@gmail.com>
dbdcc8158d59960abfa5241b55ed76cbd40e12f3

> Fix double free in error case.
> jbig2dec/jbig2_symbol_dict.c

2017-05-16 20:53:27 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
8e466b1468df6afd91eac6266a417160540d8789

> Bug 694632: Fix SEGV due to invalid proportional_spacing value.
> Updated pcl_font_header to correctly handle fonts where the
> proportional_spacing is greater than 1.
> pcl/pcl/pcsfont.c

2017-05-17 14:38:45 +0100
Robin Watts <robin.watts@artifex.com>
bc8190c4e8050364c10bb3545ca6c705bfb3d38c

> Squash warning.
> Don't implicitly lose 'const'.
> pcl/pcl/pcstate.h
> pcl/pcl/pctext.c

2017-05-17 13:03:07 +0100
Robin Watts <robin.watts@artifex.com>
24781094295489cafe562239a251300c6cfbd6ca

> Remove superfluous gsmemlok files.
> Use it or lose it.
> base/gsmalloc.c
> base/gsmemlok.c
> base/gsmemlok.h
> base/gxclread.c
> base/gxclthrd.c
> base/lib.mak
> windows/ghostscript.vcproj

2017-05-17 09:58:44 +0100
Chris Liddell <chris.liddell@artifex.com>
79fd8d7466f51c74bd0c14dc1fd33cfaba0e7b83

> Bug 697909: Handle PDF T3 glyph streams with unmatched 'q'
> We have to handle the case where a glyph description stream from a PDF Type 3
> font has an unmatched 'q'. We can track this in the PDF interpreter by checking
> the depth of the dictionary stack, and unwinding with 'Q' operations until the
> dictionary stack is back to where we started.
> Resource/Init/pdf_font.ps

2017-05-17 12:45:20 +0100
Robin Watts <robin.watts@artifex.com>
b38ed8a40e013ea79c89c6561eedf1841caa9801

> Add gs_set_object_type function to gs_memory_t interface.
> The subclassing code uses a horribly unsafe hack to reset
> the type of a device object. This fails when the device
> object is not of the expected type (in this case, when it's
> not from the i_alloc manager).
> Add a new access function to the API to allow this to happen
> safely regardless of manager type.
> base/gdevdflt.c
> base/gsalloc.c
> base/gsmalloc.c
> base/gsmchunk.c
> base/gsmemlok.c
> base/gsmemory.h
> base/gsmemret.c

2017-05-15 14:32:47 +0100
Robin Watts <robin.watts@artifex.com>
b5fd7b3473fc7cd02a2575f47b38d07f0e1e4222

> Squash warning in ETS code
> Missing 'restrict' in a prototype.
> base/ets.h

2017-05-14 11:53:42 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
b9c9f25d2cf43835d3d563e6012968b253e7faf1

> Bug 694628: Fix SEGV due to invalid bits_per_index value.
> Updated check_cid_hdr to correctly handle indexed colour
> spaces where the bits_per_index is greater than 8.
> pcl/pcl/pccid.c

2017-05-15 13:42:23 +0100
Chris Liddell <chris.liddell@artifex.com>
9468f852a09232d1f4200d252ffb665bc4d86f51

> Bug 696416: clean up pdfwrite form stack after error.
> In pdfwrite, when we start accumulating a form (whether a 'real' form, or a
> transparency group), we save a load of 'state' in stack form, so we can then
> unroll it when the form execution completes.
> If we begin a form, and the form content throws an error, we can reach the end
> of the page whilst still having not unrolled the state from the form level back
> to the page level, leaving the form stream object as the 'current' stream
> rather than the page stream.
> This results in the form not being marked as used, and potentially freed,
> resulting in a seg fault when we try to flush the current stream (expecting it
> to be the page stream, not the form stream).
> Before we proceed to complete the page, ensure that we've unrolled any errant
> form states.
> devices/vector/gdevpdf.c

2017-05-15 13:26:22 +0100
Chris Liddell <chris.liddell@artifex.com>
050d101bda8a73a6da44c379b20156f1ce49c948

> Remove spurious extra definition of RAMFS_APPEND
> Spotted by Robin
> base/ramfs.h

2017-05-12 11:21:51 +0100
Chris Liddell <chris.liddell@artifex.com>
969bef004730b3feb8cc01cf99d12f152807b24e

> Bug 696397: further validate TTF glyph "end point" values
> In a TTF glyph, we have to read the index of last point for each contour. We
> already validated the value to ensure that the value for index "i + 1" was
> always larger than that for "i". But we didn't check the values are positive.
> base/ttfmain.c

2017-05-12 11:19:00 +0100
Chris Liddell <chris.liddell@artifex.com>
7de3003abd8a66ec312ebed4146bd56ec4649d8f

> Bug 696390: bounds check Type 2 charstring "registry"
> We emulate a "Registry" construct for Type 2 charstrings, but only with a single
> entry. Bounds check accesses to it to avoid overrun.
> base/gstype2.c

2017-05-13 10:48:56 +0100
Ken Sharp <ken.sharp@artifex.com>
98fca6146085dc2cf60effb0596e79fe12b3e69f

> pdfwrite - make sure an EP pdfmark is not an orphan
> Bug #696375 "Seg faults found by fuzzing in cos_object_memory (gdevpdfo.c:189)"
> The fault is caused because the initial /BP pdfmark is corrupted. This
> means that a substream and resource for the 'Picture' has not been
> created, leading to us trying to dereference a NULL pointer.
> If the resource is NULL< throw an 'undefined' error instead.
> devices/vector/gdevpdfm.c

2017-05-12 13:15:06 +0100
Ken Sharp <ken.sharp@artifex.com>
7df7d8b6c37ca2d42ffcf1eb5bc795e741241259

> Remove descriptions of operators which have been hidden
> doc/Language.htm

2017-05-12 11:54:24 +0100
Ken Sharp <ken.sharp@artifex.com>
35a0ead22c8f1f459a4466b435b2486d53e75836

> Update documentation to reflect recent utility file removal
> doc/Psfiles.htm

2017-05-12 11:20:13 +0100
Ken Sharp <ken.sharp@artifex.com>
a0753746c3b6dd0ee01f37ebf9f3903450e9e832

> remove deleted file references from unixinst.mak
> base/unixinst.mak

2017-05-12 08:42:31 +0100
Ken Sharp <ken.sharp@artifex.com>
e8750a73313d6083aa949bc5223a26ae55ef02dd

> Renove or modify many files from lib and toolbin that are no longer useful
> Remove unused packfile.ps and gs_pfile.ps file from lib
> --------------------------------------------------------
> The PostScript claims to 'Pack groups of files together, with
> compression, for use in storage-scarce environments.'
> It also states that it 'must be kept consistent with gs_pfile.ps' which
> says it is 'Runtime support for minimum-space fonts and packed files'
> I've never heard of either of these being used, they aren't used in the
> ROM file system and it seems unlikely these days that there is a great
> deal of call for minimising file sizes.
> If these should need to be reinstated, note that they use .setglobal
> .currentglobal and .computecodes. At the time of this commit these
> operators were being deprecated and hidden though the C support is
> retained. If the C code is later removed then these library files
> will not work.
> Remove font2c.ps
> -----------------
> If we want to build a font into C and link it, we have the ROM file
> system in place to do so. This no longer seems useful.
> remove font2c
> Remove impath.ps
> -----------------
> The apparent purpose of this code is to take a bitmap (scan ?) of a
> glyph and turn it into a PostScript type 1 font form, presumably in
> order to make a font.
> This doesn't seem hugely useful, and seems to me at least borderline
> illegal depending on jurisdiction.
> We also want to remove, or at least disable, the .imagepath operator
> which this program (and only this program) relies upon. If we ever
> need to re-instate this program, we will also need to reinstate
> .imagepath
> Remove pdfinflt.ps and pdfwrite.ps
> -----------------------------------
> pdfwrite is only (as far as I can see) used by pdfinflt.ps which says:
> % It is not yet ready for prime time, but it is available for anyone wants
> % to fix it.
> %
> % The main problem is:
> %
> % 1. Sometimes the PDF files that are written are broken. When they are
> % broken, GS gets an xref problem.
> %
> % This problem is actually due to lib/pdfwrite.ps since even
> % when no conversion is done, the file is may be bad.
> Since it doesn't work, and we can use MuPDF (which does work) for the
> same task, I've chosen to delete both these files.
> Remove unprot.ps wrfont.ps
> ---------------------------
> unprot.ps 'disables access checks' according to the comments in order
> to print out eexec-encrypted type 1 fonts. Since this could, presumably
> be used to read a noaccess dictionary and dump type 1 font outlines it
> is of dubious legality. (see the comments in wrfont.ps)
> wrfont.ps is used to decode a type 1 font, we have better tools for
> decoding fonts so this file seems mostly useless.
> By the same reasoning we don't need type1ops.ps or type1enc.ps
> Remove addxchar.ps
> -------------------
> This was used to add extended Latin characters to a font. Our fonts
> now contain all the standard glyphs that Adobe fonts do, we don't want
> to go back down the route of adding (and maintaining) poor quality
> additional glyphs to the fonts.
> Remove decrypt.ps
> ------------------
> Yet another way to decrypt a type 1 font. In addition to dubious
> legality we have better ways to do this.
> Remove pcharstr.ps
> -------------------
> Again, we have better tools for doing this job and the legality of
> this tool is debatable.
> Remove markhint.ps
> -------------------
> We believe we now have better tools for dealing with fonts than this.
> Delete level1.ps
> -----------------
> A fairly pointless file.
> Remove smoke.ps from toolbin
> -----------------------------
> Our current testing method is much more thorough.
> Remove bughunt.sh
> ------------------
> A 'user contributed file that has not been kept current', since 1995
> apparently. I can't believe this is still useful.
> Remove pstogsf.bat
> -------------------
> I'm fairly certain this is long defunct.
> Remove showchar.ps
> -------------------
> another font-related utility, we've deleted the programs it reliee on,
> so....
> Remove wftopfa
> ---------------
> Wadalab fonts, given these were uploaded by Werner Lemberg I'm as sure
> as possible that we don't need these utilities to work with these
> fonts.
> Remove markpath.sh
> -------------------
> seems like a moderately pointless file; since it uses flushpage,
> which I want to hide, remove it.
> Remove quit.ps
> ---------------
> Seriously ? A file which just contains 'quit' ?
> Modify various of our utilities to not use Ghostscript extension ops
> ---------------------------------------------------------------------
> We want to hide various of our extension operators, these files used
> .devicename, .rectappend, .currentglobal, .setglobal and .namestring
> Replaced .currentglobal/.setglobal with currenglobal/setglobal
> Replaced .rectappend with a simple PostScript path
> Replaced .devicename with currentdevice /Name get
> Replaced .namestring with 1024 string cvs
> Remove EndOfTask.ps
> --------------------
> Just a Ctrl-D
> Remove gs_rdlin.ps
> -------------------
> Linux 'readline' support, just sets prompt to nothing
> Remove showpage.ps
> -------------------
> just contains 'showpage'!
> lib/EndOfTask.ps
> lib/addxchar.ps
> lib/decrypt.ps
> lib/font2c
> lib/font2c.bat
> lib/font2c.cmd
> lib/font2c.ps
> lib/font2pcl.ps
> lib/gs_pfile.ps
> lib/gs_rdlin.ps
> lib/impath.ps
> lib/level1.ps
> lib/markhint.ps
> lib/markpath.ps
> lib/packfile.ps
> lib/pcharstr.ps
> lib/pdfwrite.ps
> lib/pftogsf.bat
> lib/ps2ascii.ps
> lib/quit.ps
> lib/showchar.ps
> lib/showpage.ps
> lib/traceop.ps
> lib/type1enc.ps
> lib/type1ops.ps
> lib/unprot.ps
> lib/viewmiff.ps
> lib/wftopfa
> lib/wftopfa.ps
> lib/wrfont.ps
> toolbin/bughunt.sh
> toolbin/pdf_info.ps
> toolbin/pdfinflt.ps
> toolbin/smoke.ps

2017-05-11 13:09:29 +0100
Ken Sharp <ken.sharp@artifex.com>
1497d65039885a52b598b137dd8622bd4672f9be

> Remove as many non-standard operators as possible
> Remove all the Display PostScript operators and all the NeXT extensions
> Remove all the operators which do not appear to be used in our code
> Remove all the operators which are only used in bound procedures defined
> at startup and which can therefore subsequently be removed.
> The operators to be undefined are stored in arrays in PostScript and
> the C support code is untouched. This means that it is relatively
> simple for an end user to restore an operator if required.
> Operators which are used in our test suite files are listed in the
> arrays but commented out.
> Operators which are used (by our own code) in a way which requires them
> to be present are also listed in the arrays, but commented out.
> Resource/Init/gs_init.ps
> Resource/Init/pdf_main.ps

2017-05-12 13:47:34 +0100
Ken Sharp <ken.sharp@artifex.com>
0072619f46f89e0c7406160d4829bccda314b37d

> ps2epsi - reapply fix
> Bug #697890 "Bug 689832 still unresolved in master"
> The fix for this was applied (contrary to the report in 697890) but it
> was later removed as part of the fix for bug #688500.
> I presume this was accidental, since 688500 predates 689832, but the
> fix was applied later. I don' know how this happened and after 8 years
> I don't propose to worry about it.
> Just reapply the fix for 689832
> lib/ps2epsi.ps

2017-05-12 11:22:55 +0100
Joseph Heenan <joseph@emobix.co.uk>
0feca09fccfa3b45b095f85a9627a89954b03d58

> Update URLs in jbig2dec README
> jbig2dec/README

2017-05-11 18:23:55 +0100
Robin Watts <robin.watts@artifex.com>
fdd5bef4c19dcc653b07c5cfd3cea4de13aab0f7

> Tweak MSVC build flags for profile builds.
> Always build with frame pointers enabled, otherwise we get no
> stacktraces, which makes the profiles much less useful.
> base/msvccmd.mak

2017-05-11 13:30:45 -0600
Henry Stiles <henry.stiles@artifex.com>
ce0dd3907f01e93cc42c1b5e5d18c996cf7822e9

> XPS and PXL did not set the scan converter option.
> pcl/pxl/pxtop.c
> xps/xps.mak
> xps/xpstop.c

2017-04-17 16:23:41 -0600
Henry Stiles <henry.stiles@artifex.com>
9cbd475a13e5b0992bb7f8e33d75eb246c1a622d

> There is no reason to flush the cache when writing mode changes.
> pcl/pxl/pxgstate.c

2017-05-11 16:42:34 +0100
Ken Sharp <ken.sharp@artifex.com>
181ebf1c8c07c5411e98d50cbac86511e0098e4d

> PDF interpreter don't warn about Decode for ImaegMasks
> An imagemask could result in a warning about Decode arrays being the
> wrong length if the current colour space was not DeviceGray.
> This commit properly checks to see if the image is an ImageMask and
> checks the Decode length is 2.
> Resource/Init/pdf_draw.ps

2017-05-11 14:07:48 +0100
Chris Liddell <chris.liddell@artifex.com>
ccfd2c75ac9be4cbd369e4cbdd40ba11a0c7bdad

> Bug 697892: fix check for op stack underflow.
> In the original fix, I used the wrong method to check for stack underflow, this
> is using the correct method.
> psi/zfrsd.c
> psi/zmisc3.c

2017-05-11 09:57:48 +0100
Chris Liddell <chris.liddell@artifex.com>
31f9fddb4a330c21ea8268fc9e8ae0ead23296bf

> Bug 696417: fully initialise TTF bytecode context.
> Although the font and CVT programs aren't supposed to use certain opcodes,
> specifically, in this case, the opcodes that reference the contents of the
> zone pointers. But this font contains programs that do. Since other interpreters
> handle this, just ensure we initialize the context fully (so the zone pointers
> are valid) before executing the context.
> base/ttobjs.c

2017-05-10 18:43:25 +0100
Chris Liddell <chris.liddell@artifex.com>
6839638079bab4dc6f1e9e87e340e98b2e39ba7c

> Bug 696421: check for infinite recursion in TTF composite glyph
> This font contains a composite glyph that references itself, resulting in
> infinite recursion when we try to retrieve the metrics for the glyph.
> Add a check for this (trivial) case.
> base/gstype42.c

2017-05-10 18:20:38 +0100
Chris Liddell <chris.liddell@artifex.com>
496ebe4757eb630d09589a577738891c1e803707

> Bug 696422: bounds check number of points in TTF glyph
> There was already a bounds check for the number of points in a TTF glyph
> outline contour, to avoid buffer overflow, but it failed to check that the value
> was positive. In this case, the value is negative, which caused loops to fail
> to exit. This is sufficiently broken, we can only give up and return an error
> base/ttfmain.c

2017-05-10 16:33:34 +0100
Chris Liddell <chris.liddell@artifex.com>
85cd173e3ceeb638a2b035e057a0497f10547978

> Bug 694150(2): Ensure lzw state is fully intialized.
> valgrind identified an issue where the OldTiff flag in the lzw state wasn't
> initialized. Although not evident in this case, it was possible for other fields
> to also not be set. So, initialize the state fully before using it.
> psi/zfdecode.c

2017-05-10 17:50:39 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
ed6c5133a1004ce8d38f1b44de85a7186feda95e

> Bug 697683: Bounds check before reading from image source data.
> Add extra check to prevent reading off the end of the image source
> data buffer.
> Thank you to Dai Ge for finding this issue and suggesting a patch.
> jbig2dec/jbig2_image.c

2017-05-10 15:34:35 +0100
Robin Watts <robin.watts@artifex.com>
1a624d1bfa1e63ceab87f5e4e22c3daffa2d0f01

> Bug 697811 (continued): Fix the other 3 equivalent cases.
> Followup from the previous commit, applying the same fix to the
> other 3 cases.
> base/gxscanc.c

2017-05-10 15:18:34 +0100
Robin Watts <robin.watts@artifex.com>
210893fb2b271717957fcca4e6c049494024cc9d

> Bug 697847: Fix SEGV seen in scan converter.
> Previously the scan converter had had problems with extremely
> large/small values over/underflowing during bezier subdivision.
> We'd fixed this by calling into a "_big" variant of the
> subdivision routine that sacrificed accuracy in the bottom bit.
> Unfortunately, this can cause 'jitter' in the low bits of the
> subdivided curves, which can cause scanlines to be crossed
> repeatedly. Once a single curve can cross a given scanline
> more times than expected, our buffer allocation is too small
> and we get crashes such as the one seen here.
> The fix is to move to using 64bit accuracy in the _big variant
> and thus not introduce the jitter.
> base/gxscanc.c

2017-05-10 11:13:04 +0100
Robin Watts <Robin.Watts@artifex.com>
b38f2cb37b7bf469b36ac52b62c4aab6ccf55b6b

> Bug 697813: Fix integer overflow leading to buffer overflow.
> When calculating the amount of space required for a buffer, we
> were using an int. This would overflow, meaning we'd allocate
> less than we needed, and then segmentation fault when we overran
> the end.
> Fix is to count the space required in an int64_t, and check that
> that actually fits into a uint (the type passed to the allocation
> function) before allocating.
> Side note: Surely gs should be using size_t's rather than uints
> for its allocation calls?
> Also, our error cleanup was freeing the wrong thing. Fix that too.
> base/gxscanc.c

2017-05-05 13:25:08 -0700
Michael Vrhel <michael.vrhel@artifex.com>
0bccbb7bc00ffaeee7785544aa796c315f4b579f

> Bug 697861 Avoid push of text transparency group when no text is drawn
> The text can be handed to the pdf14 device text_begin operation with a graphic
> state that has a null device. This occurs when the text state was
> set to do no stroke or fill, only movements. In such a case we
> don't want to do the text group push until we actually have some
> text to draw.
> base/gdevp14.c

2017-05-08 16:08:46 +0100
Ken Sharp <ken.sharp@artifex.com>
ab78fab575a8d699aeec7ca37fecff66413cb93b

> Ensure FAPI server is present in base font in .FAPIBuildChar
> The code used 'I', the FAPI server retrieved from the font dictionary,
> without checking to see if it was NULL.
> Prevents a seg fault
> psi/zfapi.c

2017-05-08 12:16:16 +0100
Ken Sharp <ken.sharp@artifex.com>
24133e312b7824ad1b5bc7701039b34b800b7062

> remove #if TEST sections
> This code seems to be no longer used, it wasn't compiled and
> I can't see a justification to retain it.
> base/gscencs.c
> psi/zfdcte.c
> psi/zfunc.c

2017-05-08 11:48:42 +0100
Ken Sharp <ken.sharp@artifex.com>
2ef1ae95e0b0c7f24a246868dd26339bb5db7160

> remove smtf.c, zrop.c, zdosio.c and zfilterx.c from all builds
> Some of these were included in some builds, none of the content is
> believed to be still useful.
> Update the Windows projects to reflect the file deletions
> Update develop.htm to also reflect the file removal
> Makefile.in
> base/smtf.c
> base/unix-gcc.mak
> doc/Develop.htm
> psi/int.mak
> psi/os2.mak
> psi/zcidtest.c
> psi/zdosio.c
> psi/zfilterx.c
> psi/zrop.c
> windows/ghostscript.vcproj
> windows/ghostscript_rt.vcxproj

2017-05-06 09:26:16 +0100
Ken Sharp <ken.sharp@artifex.com>
f11cb093563ace8c4b831bcb97caff951474e380

> Remove some old colour test code and associated operators
> psi/zcolor.c

2017-05-06 09:09:54 +0100
Ken Sharp <ken.sharp@artifex.com>
4ee490955006dda75797468ba1a69a71867c8cdb

> Delete the unused source file zcsdevn.c from the PostScript interpreter
> Remove the reference from the Windows VS projects
> Remove the reference in develop.htm
> doc/Develop.htm
> psi/zcsdevn.c
> windows/ghostscript.vcproj
> windows/ghostscript_rt.vcxproj

2017-05-05 15:38:19 +0100
Ken Sharp <ken.sharp@artifex.com>
ff2243aae6d34e395f0d5cbac93689df7069c09c

> Bug 697859 - unchecked operand in .repeatform can cause seg fault
> Check that the second operand is a dictionary before we try to use it.
> psi/zform.c

2017-05-03 22:06:01 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
b184e783702246e154294326d03d9abda669fcfa

> Bug 697703: Prevent integer overflow vulnerability.
> Add extra check for the offset being greater than the size
> of the image and hence reading off the end of the buffer.
> Thank you to Dai Ge for finding this issue and suggesting a patch.
> jbig2dec/jbig2_symbol_dict.c

2017-05-04 15:50:46 +0100
Ken Sharp <ken.sharp@artifex.com>
e24e6194ca59d7b556116451490f71d2d85f4642

> Bug 697854 - unchecked operand in .seticcspace can cause seg fault
> This operator hasn't been used since (I think) the release of 9.0. To
> prevent this problem, remove it totally.
> psi/zicc.c

2017-05-04 15:13:10 +0100
Ken Sharp <ken.sharp@artifex.com>
956becf97c69ccb2542a37c9a6421159dfe58e4e

> Bug 697853 - unchecked operands in .begintransparencymaskgroup
> The operator .begintransparencymaskgroup didn't check the type (or
> indeed existence) of its 5th parameter. Because this a boolean it
> wouldn't have caused an actual problem, but nor would it have correctly
> signalled a stackunderflow or typecheck error. Also, we should always
> validate the operands.
> psi/ztrans.c

2017-05-04 14:16:09 +0100
Chris Liddell <chris.liddell@artifex.com>
59ef159e4c42c84c72130c14825f9517ef53cc16

> Extend annotation type control for pdfwrite
> The original solution to control the drawing of annotations based on the
> annotation type only worked for output devices that do not preserve things
> like annotations (i.e. only non-pdfwrite devices).
> This applies the filtering to also work with pdfwrite.
> Resource/Init/pdf_draw.ps

2017-05-04 14:26:25 +0100
Ken Sharp <ken.sharp@artifex.com>
88667cf67d3a435bc3ba727ab173c77666c8a1bb

> Bug 697850 - .getdeviceparms doesn't check operands
> This is actually benign because the unchecked parameter is used as an
> argument to stack_param_list_write() which simply ignores it if the
> type is incorrect. However, its possible we might change this at some
> point, I think its best to check the type.
> psi/zdevice.c

2017-05-04 13:42:37 +0100
Ken Sharp <ken.sharp@artifex.com>
37f9ba12dad303edca41ef166dd5b8815fb31763

> Bug 697848 - .type42execchar doesn't validate parameters
> The code made quite a has of parameter validation, it did validate some
> parameters, but not very coherently.
> psi/zchar42.c

2017-05-04 12:08:02 +0100
Ken Sharp <ken.sharp@artifex.com>
478800857dfc06b0d2d363dd1ef916dbdda061ed

> Correct function /Domain array checks
> Bug #697858 "Function Domain validation incorrect"
> The PDF and PostScript specifications state that the entries in a Domain
> array for a function must be such that Domain2i <= Domain2i+1
> However the code in fn_build_sub_function() inverted the sense by
> checking if Domain2i >= Domain2i+1 and throwing an error if so. This is
> of course incorrect for the case where Domain2i == Domain2i+1, this
> should not be an error, but the code treated it as an error.
> psi/zfunc.c

2017-05-03 12:05:45 +0100
Chris Liddell <chris.liddell@artifex.com>
57f20719e1cfaea77b67cb26e26de7fe4d7f9b2e

> Bug 697846: revision to commit 4f83478c88 (.eqproc)
> When using the "DELAYBIND" feature, it turns out that .eqproc can be called with
> parameters that are not both procedures. In this case, it turns out, the
> expectation is for the operator to return 'false', rather than throw an error.
> psi/zmisc3.c

2017-05-03 11:47:35 +0100
Chris Liddell <chris.liddell@artifex.com>
2a619d16d86348805b1732fb1e21c88dd00374fd

> Add finer control of PDF annotation drawing.
> Add the ability to define an array of annotation types that gs should draw,
> and ignore the others. On the command line, you'd add:
> -c "/ShowAnnotTypes [.....]" -f <input file>
> Where the array can contain one or more of:
> /Stamp
> /Squiggly
> /Underline
> /Link
> /Text
> /Highlight
> /Ink
> /FreeText
> /StrikeOut
> /stamp_dict
> Resource/Init/pdf_draw.ps
> doc/Use.htm

2017-04-26 22:12:14 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
5e57e483298dae8b8d4ec9aab37a526736ac2e97

> Bug 697693: Prevent SEGV due to integer overflow.
> While building a Huffman table, the start and end points were susceptible
> to integer overflow.
> Thank you to Jiaqi for finding this issue and suggesting a patch.
> jbig2dec/jbig2_huffman.c

2017-04-27 13:21:31 +0100
Chris Liddell <chris.liddell@artifex.com>
04b37bbce174eed24edec7ad5b920eb93db4d47d

> Bug 697799: have .rsdparams check its parameters
> The Ghostscript internal operator .rsdparams wasn't checking the number or
> type of the operands it was being passed. Do so.
> psi/zfrsd.c

2017-04-27 13:03:33 +0100
Chris Liddell <chris.liddell@artifex.com>
4f83478c88c2e05d6e8d79ca4557eb039354d2f3

> Bug 697799: have .eqproc check its parameters
> The Ghostscript custom operator .eqproc was not check the number or type of
> the parameters it was given.
> psi/zmisc3.c

2017-04-27 12:34:19 +0100
Chris Liddell <chris.liddell@artifex.com>
5603e8fc3e59c435318877efe627967ee6baebb8

> Bug 697769: cmap tab for symbolic fonts, and format 4 cmap parsing
> This involved two problems:
> Firstly, the logic of whether to treat a font flagged as symbolic *really*
> as symbolic was missing a condition. It appears that as well as checking for
> a symbolic (3.0) cmap table, we also need to check for a UCS-2 (3.1) cmap
> table.
> As noted before, this area is poorly documented in the spec, so it is possible
> further issues may arise.
> Secondly, the fonts in the test file are, in fact, invalid. Each using a format
> 4 segmented cmap table with only one, non-terminal, segment. According to the
> TTF spec, a format 4 table should have a terminating segment whose start and
> end codes are 0xffff. These fonts do not have such a segment. As it happens,
> we ignore the terminal segment anyway, so by simply tweaking the loop
> condition, we can parse the one segment, and retrieve a usable cmap.
> Resource/Init/gs_ttf.ps

2017-04-27 12:28:42 +0100
Chris Liddell <chris.liddell@artifex.com>
05d0bbc50ad453990520ed2d2ded3ace538bcb1d

> Change TTF cmap procedure name and tidy up
> The procedure for parsing the TTF cmap table was called "cmaparray", but it
> has returned a dictionary rather than an array for a *long* time. So change
> the procedure name to "cmapdict".
> In the format 4 cmap parsing, left over from when we did return an array, we
> looped over the codes, counting as we go, so we could allocate an array large
> enough to hold all the mappings, then looped over them again to fill in the
> array.
> As we now use a dictionary, there is no need to pre-count, so the first
> loop was redundant - remove it.
> Resource/Init/gs_ttf.ps

2017-04-20 09:54:44 +0100
Chris Liddell <chris.liddell@artifex.com>
e589d67461e7e522c8af6cb9cc61064018b6a4fc

> Bug 696379: Handle error correctly in font with CDevProc
> In event of a Type 1 charstring font throwing an error setting up for a
> CDevProc, ensure we use the correct path to exit the function, doing the
> required cleanup along the way.
> psi/zchar.c

2017-04-19 16:20:49 +0100
Chris Liddell <chris.liddell@artifex.com>
7e78f3a285bb41a6d3a33d608c6ba9d00b9cd107

> Ensure gs is sufficiently inited before using PS memory
> Spotted by accident: having "-o" first in the command line can cause a
> segfault
> psi/imainarg.c

2017-04-06 22:10:30 +0100
Chris Liddell <chris.liddell@artifex.com>
88fc69e9bf5bfc73ce906c038b09bc8055dabe96

> Bug 697722: Skip glyph cache with vertical substitution
> The way PXL implements vertical glyph substitution means it defeats our glyph
> cache logic - the cache doesn't have the information to differentiate between
> a vertical substitute and a regular glyph.
> As this is a very rarely used feature, the simplest solution is to disable use
> of the cache when vertical substitutes are in force - it will neither lookup
> existing, nor add new glyph instances to the cache.
> If we start seeing more jobs using vertical glyph substitution, and this proves
> to be a performance bottleneck, we can revisit this and add the required data
> for the cache to handle these (and possibly other) cases.
> pcl/pxl/pxfont.c

2017-04-25 21:05:27 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
7f5fb63f7f2ef5ff3f234e0653412d8f4a439c0d

> Bug 694150 : Fix SEGV in s_LZWD_process.
> Prevent using prev_code < 0 which would make an entry before the table.
> This in turn means that when a length of 4 is decoded, the decoder fails
> to find the eod and continues to write off the end of the memory segment.
> base/slzwd.c

2017-04-26 16:12:10 +0100
Ken Sharp <ken.sharp@artifex.com>
1d2ba380aaa4df253bb6a1237f136ab4984657bd

> PDF interpreter - Apply /Widths to illegal (empty) type 3 CharProcs
> Bug #697805 "Incorrect spacing between text"
> The file (created by the Skia graphics library) embeds all the fonts as
> type 3, the CharProc for the space glyph is embedded as an empty stream:
> 17 0 obj
> <<
> /Length 0
> >>
> stream
> endstream
> endobj
> The specification does not say what should happen if the /Width entry
> is not the same as the actual width in the glyph description, but we
> choose to use the /Width, because from prior experience we know that's
> what Acrobat does.
> However, this glyph is illegal, because it contains neither a d0 nor a d1
> operator. We apply the Widths override when executing d0 or d1, so if
> the (required) operator is not present in the glyph description we
> cannot override it.
> In this commit we detect a 0 length stream and treat it the same as a
> missing stream; we execute a dummy d1 which enables us to do the
> Widths override.
> Resource/Init/pdf_font.ps

2017-04-26 10:20:12 +0100
Ken Sharp <ken.sharp@artifex.com>
d648ec8c6935387d485b1d9be56e2d147109616f

> (e)ps2write - add definition of MacRoman Encoding
> Bug #697733, follow on from commit c90836f3782ce8e8f3076cb8b50503cfe91dabcf
> The previous commit altered to using MacRoman Encoding for embedded,
> subset TrueType fonts, because we prefer the 1,0 CMAP subtable from
> such fonts. However, MacRoman is not a standard Encoding for PostScript
> interpreters. Add it here.
> devices/vector/opdfread.ps

2017-04-25 17:08:26 +0100
Ken Sharp <ken.sharp@artifex.com>
8556b698892e4706aa0b9d996bec82fed645eaa5

> PS interpreter - remove superexec from systemdict
> This looks like bit rot, superexec was meant to have been undefined from
> systemdict, and moved to internaldict, but the code only executed if
> superexec was defined in the current dictionary. It seems that at some
> time in the past the order of execution was changed in such a way that
> the current dictionary at that point was no longer systemdict.
> So instead of checking currentdict, explicitly check systemdict.
> This means changing our gs_cet.ps file which we use for the Quality
> Logic CET (Command Emulation Test) suite so that it can find superexec
> and use it to set up our environment in a specific fashion, to prevent
> spurious differences when running the tests.
> If sueperexec isn't available when we run the CET tests we'll get an
> error, which sounds like a good idea, hopefully we'll notice that.
> Resource/Init/gs_cet.ps
> Resource/Init/gs_init.ps

2017-04-25 13:38:33 +0100
Ken Sharp <ken.sharp@artifex.com>
31cb597dbbff0a6aebe48469568837e2844cdfdc

> A better DSC Parser fix for bug #697800
> Commit 06d283c4a20fe7ec727bebb56404242734ea2d70 checked the number of
> operands, but this is a better fix, since it also correctly checks the
> type of the dictionary operand, which the previous fix didn't do.
> psi/zdscpars.c

2017-04-25 13:03:22 +0100
Ken Sharp <ken.sharp@artifex.com>
06d283c4a20fe7ec727bebb56404242734ea2d70

> DSC parser - check number of operands supplied
> Bug 697800 "Null pointer dereference in zparse_dsc_comments()"
> The custom operator .parse_dsc_comments wasn't checking the number of
> operands supplied, before attempting to validate them. If not enough
> were supplied it ended up falling off the bottom of the operand stack.
> Generate a stackunderflow error when this happens.
> psi/zdscpars.c

2017-04-24 12:01:53 +0100
Ken Sharp <ken.sharp@artifex.com>
db4cb499fbc3c87b2b0182e550c82eb3c93fc1b4

> PS interpreter - restore correct error behaviour for invalid /Decode arrays
> PDF interpreter - trim excessively long Decode arrays to the correct length
> Bug #697787 " regression, several EPS figures which work fine with gs <= 9.07 throw Error with gs > 9.08"
> commit 89c224b029357002c48660dae98de2d1e560d4e0 was applied to fix
> bug #694276, and the fix was, I'm afraid, incorrect.
> The bug in question was a PDF file where the /Decode array was too long
> (by 1 entry) for the actual colour space. This caused the PostScript
> interpreter to (correctly) throw an error. Ray fixed this by altering
> the PostScript interpreter so that it did not throw an error when the
> Decode array was too long, but instead used the requisite number of
> elements.
> This is not correct, the PostScirpt interpreter should throw an error.
> The file attached to this report is an EPS file which relies (horribly)
> on getting an error when the Deocde array is too long for an image, and
> uses that to call colorimage instead.
> By not throwing an error we treat the image as being in DeviceGray and,
> since the data is actually RGB, only read 1/3 of the image data. We then
> attempt to carry on from that point and throw real errors due to reading
> from the middle of a data string.
> This commit reverts (significant) the changes in commit
> 89c224b029357002c48660dae98de2d1e560d4e0. It also addresses the 'bug'
> in report #694726 by shifting the checking to the PDF interpreter and
> having that correctly set the decode array.
> Resource/Init/pdf_draw.ps
> psi/idparam.c
> psi/zimage.c

2017-03-28 09:22:23 -0700
Ray Johnston <ray.johnston@artifex.com>
5fa7596d8d467e98fbc069d11b7a3769f7d024f0

> More fixes for tag plane problems.
> tests_private/comparefiles/Altona_Technical_v20_x4.pdf Page 7 had a
> problem in blending when nos_knockout was true that ignored the tag.
> This also showed up cases where the alt_dev_color was not updated with
> the tag (e.g. tests_private/comparefiles/0000728-simpleNG.pdf).
> Another difference that tests_private/comparefiles/Bug689761.pdf shows
> is that "gsave fill grestore stroke" reverts the dev_color with grestore,
> but doesn't change the dev->graphics_type_tag. Keep the tag in the
> dev_color structure so that we know if the dev_color needs unset.
> Fix the ensure_tag_is_set inline function to make sure BOTH the device's
> graphics_type_tag AND the dev_color.tag are set correctly.
> We need to write and read the pattern tag plane for raster patterns with
> transparency. Seen with tests_private/comparefiles/Bug689422.pdf
> Lastly, the ensure_tag_is_set in gs_shfill needs to happen before the
> remap_color (since it may unset the dev_color if the tag was different).
> base/gdevdsha.c
> base/gdevp14.c
> base/gscolor3.c
> base/gsdcolor.h
> base/gsdevice.c
> base/gsht.c
> base/gsptype1.c
> base/gxblend1.c
> base/gxdcolor.h
> base/gxgstate.h
> base/gxp1fill.c
> base/gxpcmap.c
> base/gxpcolor.h
> base/lib.mak

2017-04-18 09:38:17 -0700
Ray Johnston <ray.johnston@artifex.com>
35a5977484afecae01afc92f5018709feba6bc91

> gs_fillpage should set the tag to UNTOUCHED, not PATH.
> This produces tag plane differences in areas that have transparency
> that are painted (touched) in a transparency group since the page level
> buffer will now have tag UNTOUCHED == 0 instead of PATH, so areas that
> were PATH+TEXT or PATH+IMAGE can become just TEXT or IMAGE (which is
> correct).
> base/gspaint.c

2017-04-10 12:23:00 -0700
Ray Johnston <ray.johnston@artifex.com>
82ec3b5eef0a530666044dc94b6ba94ed9aa15b6

> Set color_info separable_and_linear for bitrgbtags device.
> Since this device is separable and linear, we can skip the testing in
> check_device_separable and check_device_compatible_encoding. We can
> safely set GX_CINFO_SEP_LIN_STANDARD since the low (color) bits are
> compatible with the pdf14_encode_color_tag.
> This shows up many shading differences since the device was being
> (incorrectly) classified as SEP_LIN_UNKNOWN which would then flatten
> color patches and use fill_trapezoid rather than the preferred
> fill_linear_color_trapezoid (the latter writes less data to the
> clist).
> devices/gdevbit.c

2017-04-20 14:34:43 -0400
Steve Phillips <steve.phillips@artifex.com>
59c7840aea41253d274d9037b637e60c38359f9f

> Auto-generate opdfread.h from opdfread.ps during the build using packps tool
> This commit implements a new packps tool which converts PostScript files
> to packed arrays of C strings, providing a method to compile PostScript
> code directly into the executable. Using this tool, the opdfread.h
> file is now derived from devices/vector/opdfread.ps.
> - The packps utility is built from the new file base/pack_ps.c.
> - opdfread.ps has been moved from lib to /devices/vector. This is
> now the reference file for the opdfread header procset code.
> - opdfread.h has been removed from /devices/vector and is now built
> within the DEVGEN directory as part of the make process.
> - For Windows builds, a stale file reference to Resource\Init\opdfread.ps
> has been removed from the project file. Additionally, a file reference
> to opdfread.ps has been added to the /devices/vector source list, and
> the reference to opdfread.h has been removed from the header file list.
> base/gs.mak
> base/msvctail.mak
> base/pack_ps.c
> base/unix-aux.mak
> base/unix-end.mak
> devices/devs.mak
> devices/vector/opdfread.h
> devices/vector/opdfread.ps
> windows/ghostscript.vcproj

2017-04-20 13:42:31 -0400
Steve Phillips <steve.phillips@artifex.com>
7daa44b70e213e704e0da53032a89bf56ff07e0a

> Reconcile differences between opdfread.h and opdfread.ps
> This change reconciles all differences between devices/vector/opdfread.h
> and lib/opdfread.ps so that they contain exactly the same PostScript code,
> other than whitespace differences and comments. The opdfread.h file was
> originally created through a one-time conversion of opdfread.ps to an array
> of C strings, and opdfread.h is currently used as the reference code for
> source builds. These two files have diverged slightly over time, so the
> unused code in opdfread.ps was no longer up-to-date.
> In this commit, all differences between these two files have been reconciled
> so that either the header file or the PostScript version can be used as the
> reference copy. A subsequent commit will add a tool to derive opdfread.h
> from opdfread.ps during the build process, which will use opdfread.ps as
> the master copy instead. This commit ensures that this tool change will
> not introduce any functional differences in the generated header file.
> For ease of comparison, all whitespace-only changes (removing spaces and
> moving code to different lines) have been made in opdfread.h, so there are
> no functional changes to this module.
> The changes to opdfread.ps resolve all remaining functional differences,
> with opdfread.h used as the reference source for any changes.
> With these changes, the new packps tool converts opdfread.ps to a C
> file which matches opdfread.h exactly, other than the header comments
> at the top of the file.
> devices/vector/opdfread.h
> lib/opdfread.ps

2017-04-20 13:57:21 +0100
Robin Watts <robin.watts@artifex.com>
18174668ea815c7830841a511f1dc850557772a9

> Scan converter: Remove 2 outdated asserts.
> base/gxscanc.c

2017-04-20 12:31:22 +0100
Robin Watts <robin.watts@artifex.com>
53c1849dabf14941bc191506b6feaf2d6f7817cb

> Add missing braces in scan converter code.
> The lack of these could cause memory overwrites when
> DEBUG_SCAN_CONVERTER was enabled.
> base/gxscanc.c

2017-04-20 11:57:14 +0100
Ken Sharp <ken.sharp@artifex.com>
13b97d2c1b4c8a819e0682047d044f9308a56174

> Initialise path bounding boxes.
> Bug #697770 "Inconsistent behaviour"
> The problem is that gx_path_init_bbox_accumulator() sets bbox_accurate
> which is later used to signal that the attached bbox is valid and
> accurate.
> But we don't actually initialise the bbox member at all, in the bug in
> question the glyph has no contours, so creates no path, leaving the
> bbox uninitialised. But because we have set bbox_accurate we just
> copy the values when determining the font bounding box, leading to
> insane values.
> Initialising the bbox gives more reasonable results.
> base/gxpath.c

2017-04-19 12:06:39 +0100
Robin Watts <robin.watts@artifex.com>
8210a2864372723b49c526e2b102fdc00c9c4699

> Bug 697762: Fix scan converter SEGVs.
> The SEGVs are caused by the scan converter allowing less room
> in the table than is actually required. This happens due to
> the mark_curve subdivision overflowing.
> For example, if we have a curve such as:
> 0 0x80000000 moveto
> 0 0x80000000 0 0x80000000 0 0x80000000 curveto
> Then the current subdivision logic does:
> fixed ay = (sy + c1y)>>1
> For sy = c1y = 0x80000000 this gives ay = 0, when clearly
> the average should be 0x80000000.
> An alternative formulation of the splitting code:
> fixed ay = (sy>>1) + (c1y>>1)
> gives the required result, at the expense of dropping accuracy at
> the low end.
> This commit therefore has 2 formulations of the splitting code, one
> for 'big' values (values that might overflow), and ones for normal
> values (values that won't).
> We select between the two pieces of code by comparing the top 2
> bits of each value; if they differ, then we use the big variant.
> Also, when calculating the size of the table required, we were
> incorrectly closing the curve more often than we needed to. This
> had no ill effect other than inflating the amount of memory we
> needed.
> base/gxscanc.c

2017-04-18 12:37:21 +0100
Ken Sharp <ken.sharp@artifex.com>
0f598a2c56f2ccec4ecf67f8f585a340b04057ef

> PDF interpreter - detect missing 'endobj' on final object in file
> Bug #697761 " Broken PDF (missing endobj on final object) causes error"
> The sample file has the final two objects (Info and Catalog dictionaries)
> written with missing 'endobj' Our normal processing catches that in the
> body of the file, but if its the final object, then we carried on and
> tried to process the entire trailer and xref.
> Add 'xref' to the entries in resolveopdict and treat it as a missing
> endobj. While we're here, add an error message for the case of detecting
> an 'obj' when resolving an object. We already handle that, but we
> weren't producing an error for it.
> Resource/Init/pdf_base.ps

2017-04-17 15:41:11 +0100
Robin Watts <robin.watts@artifex.com>
3e7e5272faf866419473a7c8e0149028bdfb4add

> MSVC: Fix x64 'All' configuration.
> windows/GhostPDL.sln

2017-04-15 14:33:08 +0100
Ken Sharp <ken.sharp@artifex.com>
43ed8ae1ce7e254866d443176e48c9ca6787db35

> subclassing devices - process the graphics_type_tag into all chained devices
> The tag devices encode the type of operation into the device color, if
> the devices graphics_type_tag has the GS_DEVICE_ENCODES_TAGS bit set.
> The specific tag is maintained by altering the graphics_type_tag in the
> device structure using a device method (set_graphics_type_tag). However,
> when checking to see if the tag needs to change (for a different marking
> operation type), the code does not, as might be expected, use a
> symmetric device method such as get_graphics_type_tag. It was felt that
> the performance impact would be unacceptable. Instead the
> graphics_type_tag of the *current* device in the graphics state is
> inspected directly from the structure.
> This means that every device chaining method (and there are several,
> see ghostpdl/doc/subclass.htm) needs to ensure that every device in
> the chain sets its graphics_type_tag in the device structure, *and*
> passes that on to any underlying devices.
> Apparently the 'forwarding' devices already do this, I presume the clist
> and transparency compositors do as well, I haven't checked. The obselete
> 'device filter chain' does not, the subclassing devices did not either.
> Its also important (for pattern colour spaces) that we track the tag
> even when we are not actually rendering.
> So here we remove the code from the First/Last page device which skipped
> tags on elided pages. This means the device can instead use the standard
> subclassing default method.
> In the standard subclassing default method we now update the tag on the
> current device in the chain before passing it on to the next device.
> This means that all devices in the chain now track the tag. An important
> note for any subclassing devices which implement a set_graphics_type_tag
> method is that it must set the tag in its device structure. So we document
> that as well.
> base/gdevflp.c
> base/gdevsclass.c
> doc/subclass.htm

2017-04-14 14:19:53 -0700
Michael Vrhel <michael.vrhel@artifex.com>
22d8a2653ae532c7c23aa9a441e6c120edd9bdef

> Add back icc support for PNG output
> When the png library was updated, the embedded ICC profile
> was no longer getting written. This fixes the issue as
> well as fixes a minor issue in our setting of D50 in the
> resource ICC profiles which prompted a warning from the
> PNG library.
> devices/gdevpng.c
> iccprofiles/default_cmyk.icc
> iccprofiles/default_rgb.icc
> iccprofiles/gray_to_k.icc
> iccprofiles/lab.icc
> iccprofiles/ps_cmyk.icc
> iccprofiles/ps_gray.icc
> iccprofiles/ps_rgb.icc
> iccprofiles/srgb.icc

2017-04-13 16:01:02 +0100
Ken Sharp <ken.sharp@artifex.com>
6d65aaa8af3a9f56c1828e7943c6e1c8b93cf614

> PCL - remove the 'bias' from glyph indices before use, if present
> Bug #697744 "Accents not handled correctly"
> In plfont.c, pl_glyph_name, we use the 'glyph' (which is of type
> gs_glyph) as an index to retrieve a glyph name from a TrueType font.
> However, as per the documentation in gsccode.h, if the glyph is truly
> an index (as opposed to a name) then it is biased by GS_MIN_GLYPH_INDEX
> which means that attempting to use it directly as an index into the font
> fails, and returns no name.
> This causes pdfwrite multiple problems; firstly it causes the original
> glyph to be rendered as a bitmap. Then, because the glyph is a composite
> glyph (its made up of two or more other glyphs) subsequent uses of the
> same glyph cause it to become confused, and use the initail component
> glyph.
> This can be easily resolved simply by testing to see if the glyph is
> biased by GS_MIN_GLYPH_INDEX and, if it is, removing the bias.
> In addition to fixing the reported problem a number of test suite files
> show progressions (accents now present) and small but useful quality
> improvements (glyphs no longer rendered as bitmaps) as well as being
> able to properly extract text from either the PCL or the output PDF file.
> pcl/pl/plfont.c

2017-04-12 16:02:33 +0100
Ken Sharp <ken.sharp@artifex.com>
c90836f3782ce8e8f3076cb8b50503cfe91dabcf

> (e)ps2write - use correct encoding for subset TrueType fonts
> Bug #697733 "Character section is not handled with eps2write"
> We carry around a 'base encoding' with fonts, which is generally the
> encoding of the original font, potentially 'refined' to a more useful
> encoding if its originally one we can't use.
> For TrueType fonts, we would either Standard or ISOLatin1, and in fact
> almost always StandardEncoding.
> The problem is that if we are subsetting the font, then we *don't* embed
> the original font's CMAP subtable, we generate a new pair, one of Windows
> Unicode (3,1) and one of Mac Roman (1,0). Neither is suitable for use
> with StandrdEncoding and in fact the opdfread code will always use the
> MacRoman Encoding.
> This can lead to a problem if the same glyph name is encoded in one or
> other Encodings, and is either missing or in a in a different position
> in the other.
> When we encode the string we will use StandardEncoding, and the opdfread
> code will read the character codes using MacRoman Encoding, so the
> Charstrings dictionary will be incorrectly constructed and glyphs will
> either become notdef or potentially use the wrong glyph.
> To fix it; if we have a TrueType font, and are subsetting it, select
> a Base Encoding of MacRoman. Update the refine_encoding procedure to
> permit a TrueType fotn to have MacRoman encoding.
> This shows a minor progression in one file in the test suite;
> Bug691848.ps, surprisingly with Kanji text.....
> devices/vector/gdevpdtt.c

2017-04-11 14:55:26 -0700
Ray Johnston <ray.johnston@artifex.com>
e90c8f5a93e274b02b7e25762ef83995455f8464

> Yet another fix for tag handling that affects shading fills and pdf14
> The comp_shift that is relied upon for color generation in fill_linear
> color_scanline did not work because the comp_shift[num_components] was
> not set for the pdf14 device when the device "has_tags".
> Also fix a bunch of whitespace variances.
> base/gdevp14.c

2017-04-07 18:39:58 +0100
Robin Watts <robin.watts@artifex.com>
ba92812e5a25c3c1f8d13c79e584398d2250b72a

> Scan Converter: Speed tweak to sorting.
> When sorting the intersects on a scanline, if the list is short
> use inline sort code, rather than calling qsort. This is a big
> saving in runtime, presumably due to function call overhead.
> This reduces the bug 697678 time from 40 seconds to 35.
> base/gxscanc.c

2017-04-10 18:10:32 +0100
Robin Watts <robin.watts@artifex.com>
31aefb5777a72c54363685498c07f2cd00867525

> Scan converter: Simplify edgecmp comparison.
> It *shouldn't* matter the order we treat up/down edges in,
> therefore, it shouldn't matter if we alter our sort routine
> to actually care about the bottom bits. This results in
> simpler (and hence, hopefully, faster) code.
> base/gxscanc.c

2017-04-07 18:15:21 +0100
Robin Watts <robin.watts@artifex.com>
9eb97696875fb97b08321aba009c14419a4feeba

> Tweak make_table for speed.
> base/gxscanc.c

2017-04-10 18:47:43 +0100
Robin Watts <robin.watts@artifex.com>
81385210e0d484050ee6ed7898b03ebcc5105ba1

> Scan converter: Fix double written pixels
> The any part of a pixel (non trap) code could occasionally double
> write some pixels. Fixed here.
> base/gxscanc.c

2017-04-10 18:09:07 +0100
Robin Watts <robin.watts@artifex.com>
bc739b046c0490e5ab941ef2942eadac37a2ce13

> Squash a float <-> double warning.
> base/gxiscale.c

2017-04-10 18:05:44 +0100
Robin Watts <robin.watts@artifex.com>
e16d0c760651b973d5a750524cf9e69df8601256

> MSVC: Profile builds. Ensure linker optimisations are enabled
> /DEBUG disables optimisations, so add /OPT:REF and /OPT:ICF to
> reenable them.
> base/msvccmd.mak

2017-04-07 18:06:15 +0100
Chris Liddell <chris.liddell@artifex.com>
74f9d86d60c8ded49d0df2c23bec2d68fea1f6b5

> Revert "gs_malloc_memory_t: change type of limit/used/max_used"
> This reverts commit 47417a5cbfbfa3d7bb9ee387909246cdd265d4ff.
> Until I can debug the errors is causes on Windows.
> base/gsalloc.c
> base/gsmalloc.c
> base/gsmalloc.h

2017-04-07 15:09:29 +0100
Robin Watts <robin.watts@artifex.com>
1cd00def041e82e66e2ea12a153801552b64246e

> Squash warning.
> ./base/gsfont.c:1006:12: warning: overflow in implicit constant conversion [-Woverflow]
> base/gsfont.c

2017-04-07 13:15:46 +0100
Robin Watts <robin.watts@artifex.com>
9eae07a45a76f8944d7fbfe1fb4546f473fcf400

> Further scan converter work inspired by Bug 697678
> This applies the same changes done for the any-part-of-a-pixel,
> trapezoid case to the any-part-of-a-pixel non-trapezoid case.
> base/gxscanc.c

2017-04-05 17:56:14 +0100
Robin Watts <robin.watts@artifex.com>
f158bfa0346833ac2181bc66709cfabff1a12afc

> Further work inspired by Bug 697678
> Apply the same speedups for vertically clipped paths as have already
> been done for the any-part-of-a-pixel, trapezoid case to the
> centre-of-a-pixel cases.
> The any-part-of-a-pixel, non-trapezoid case remains to be done.
> base/gxscanc.c

2017-04-06 08:46:20 -0700
Michael Vrhel <michael.vrhel@artifex.com>
ee57023920599a2209e5e0b7eded2ae9c2002e19

> Fix error in color updating
> Ray found an issue that would appear to cause problems when we have
> transparency and spot colors for the separations devices.
> The mask and shift values in color info were not getting set properly
> for the spot colors in this case. It is not a real issue
> due to the way that the separation device colors are
> stored in the devn hl color (planar) but is good to fix
> to avoid confusion.
> base/gdevp14.c

2017-04-04 14:43:05 +0100
Chris Liddell <chris.liddell@artifex.com>
47417a5cbfbfa3d7bb9ee387909246cdd265d4ff

> gs_malloc_memory_t: change type of limit/used/max_used
> The limit, used and max_used values in gs_malloc_memory_t were type ulong,
> giving rise to differences between LP64 systems (Unix-like) and LLP64 systems
> (MS Windows).
> So, make them uint64_t for consistency across platforms.
> base/gsalloc.c
> base/gsmalloc.c
> base/gsmalloc.h

2017-04-06 16:44:54 +0100
Chris Liddell <chris.liddell@artifex.com>
bfa6b2ecbe48edc69a7d9d22a12419aed25960b8

> Bug 697548: use the correct param list enumerator
> When we encountered dictionary in a ref_param_list, we were using the enumerator
> for the "parent" param_list, rather than the enumerator for the param_list
> we just created for the dictionary. That parent was usually the stack
> list enumerator, and caused a segfault.
> Using the correct enumerator works better.
> psi/iparam.c

2017-03-31 13:36:03 -0700
Ray Johnston <ray.johnston@artifex.com>
063416192c169889ef0b227aab5d912f71640590

> Fix gx_default_fill_linear_color_scanline to handle tags.
> The fill_linear_color_scanline would calculate linear and separable colors
> based on the num_components, which does not include the tags, leaving the
> tag value set to 0 (GS_UNTOUCHED_TAG). If the device does need tags
> (GS_DEVICE_ENCODES_TAGS set) then set the tag value using the last comp_shift
> to GS_PATH_TAG. Seen with Ghent_V5.0/GWG010_CMYK_OP_x3.pdf and the
> bitrgbtags device in clist mode.
> base/gdevdsha.c
> base/gxdevcli.h
> devices/gdevbit.c

2017-04-05 11:42:30 +0100
Robin Watts <robin.watts@artifex.com>
9c711b79f1230cbbd346d1cbf7e9bcaa701d2e4c

> Scan converter optimisations
> Optimise unneeded writes when updating the cursor.
> base/gxscanc.c

2017-04-05 12:28:20 +0100
Robin Watts <robin.watts@artifex.com>
d90f7b0782b74201cbca8e40e02800453a48a873

> Attempt to fix warning.
> ./base/gsccode.h:29:20: warning: overflow in implicit constant conversion
> base/gsccode.h

2017-04-05 10:38:16 +0100
Robin Watts <robin.watts@artifex.com>
25c8f788cf15829adb5f1e3292f46f9ca9a1c329

> Fix scan converter issues.
> Commit edba51f ("Bug 697678: Scan converter performance (out of
> range lines)." caused 3 SEGVs in the normal tests, but caused
> many many more in the overnights.
> This commit fixes those. The problems were due to edge effects
> on the top/bottom of the edgebuffers, due to differences in
> the logic for rising/falling lines.
> base/gxscanc.c

2017-03-29 11:08:03 -0700
Ray Johnston <ray.johnston@artifex.com>
ac125ce3320aeb3888c18805cd12136d3e1ebfc7

> Fix a problem with tags not being set in dev_color
> When the tag is changed, we need to unset the dev_color so that the
> device's encode_color gets called to apply the correct tag. Seen with
> the bitrgbtags device and the file: tests/pdf/Bug691997.pdf
> Also, fix a problem with the hit_detect device (infill PS operator).
> If the dev_color is unset in the fill or stroke operation, it would
> attempt to remap the dev_color which would fail because the hit detect
> device doesn't have a device profile. This sets the grapchis_type_tag
> to GS_PATH_TAG so that fill and stroke don't unset (and subsequently
> remap in gx_set_dev_color) the dev_color.
> base/gdevddrw.c
> base/gdevnfwd.c
> base/gdevp14.c
> base/gscolor3.c
> base/gsdps1.c
> base/gsimage.c
> base/gspaint.c
> base/gstext.c
> base/gxclrast.c
> base/gxdevcli.h
> base/gxgstate.h
> base/gxpcmap.c
> psi/zupath.c

2017-04-04 11:37:35 +0100
Ken Sharp <ken.sharp@artifex.com>
ddb63fcf10ce51416f0921dbb0f7b0dee3cf3849

> PDF interpreter - don't remove Filters from streams declared as 0 Length
> No bug number for this, the problem arose from a Stack Overflow
> question here http://stackoverflow.com/questions/43149372/repairing-pdfs-with-damaged-xref-table/43154410?noredirect=1#comment73447166_43154410
> The PDF file is multiply broken, it has invalid xref entries and each
> page is an image XObject whose dictionary has an indirect object for
> the /Length entry. In every case the Length is defined as 0.
> For some obscure reason, sometime in the past someone added code to
> remove the /Filter entry from the dictionary when a stream has a
> declared Length of 0. I have no idea why, if the stream is compressed
> or encoded then removing the Filter can have no useful effect. But
> if the Filter is left in place we can still recover from an invalid
> Length declaration, provided we properly decode the stream, which
> obviously requires us to install the correct Filter(s).
> So here we simply remove the code which undefines the Filter in the
> stream dictionary.
> cluster runs show no differences.
> Resource/Init/pdf_base.ps

2017-03-30 14:18:11 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
ea5389d2ff12797df9a1fd932f499223460a3808

> Bug 697545: Memory Squeezing fix font cache leak.
> Fix font cache leak when memory squeezing:
> gs -sDEVICE=bit -o /dev/null: examples/tiger.eps
> base/gsfont.c
> devices/vector/gdevpdf.c
> pcl/pcl/pcfont.c

2017-03-28 22:56:18 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
9fbb9d8695deecfe937ffdd91b9bd69613c1c8df

> Bug 697545: Memory Squeezing fix leaks in swproc.
> Fix memory leaks in swproc when memory squeezing:
> gs -sDEVICE=bit -o /dev/null: examples/tiger.eps
> psi/imainarg.c

2017-03-29 20:31:49 -0700
Ray Johnston <ray.johnston@artifex.com>
5499169177746ec62d8440f193be418999f156d4

> Change GS_UNTOUCHED_TAG to 0 and GS_UNKNOWN_TAG to 0x40
> This is mostly arbitrary, but it sort of makes more sense that UNTOUCHED
> be 0 so any marking operation can just OR tag bits into the tag plane or
> color (e.g. gdevp14.c).
> This will change ALL bitrgbtags regression results.
> base/gdevp14.c
> base/gscms.h
> base/gxblend1.c
> base/gxdevice.h
> devices/gdevbit.c
> lib/viewpbm.ps

2017-03-29 19:26:50 +0100
Robin Watts <robin.watts@artifex.com>
edba51f4647f56b3559451f5fdbfbde04bc87828

> Bug 697678: Scan converter performance (out of range lines).
> This significantly improves the timings.
> Essentially, if we were rendering just a band of a page (say from
> Y1 to Y2) and the line extended beyond that (say from Y0 to Y3,
> where Y0 < Y1 or Y2 < Y3), we'd have run the bresenham for the
> entire range rather than for just the section we needed to.
> This was particularly problematic in the example file due to the
> use of a clipping device, meaning that we were repeatedly
> scan converting lines in 1 pixel high regions.
> base/gxscanc.c

2017-03-29 20:36:04 +0100
Robin Watts <robin.watts@artifex.com>
0fe78bcd5eb6cc919e6b0a97aadb6f9259176bc8

> Tweak bmpcmp to better handle tags.
> toolbin/bmpcmp.c

2017-03-29 21:04:55 +0100
Robin Watts <robin.watts@artifex.com>
7dbcd5da85934c9e437c557c359556f3c67b48d5

> Scan converter: Fix restrict in prototypes.
> Forgot to change the prototypes while adding restrict.
> base/gxscanc.c
> base/gxscanc.h

2017-03-29 11:55:40 +0100
Robin Watts <robin.watts@artifex.com>
d6903654402789d60bff227fd916a368991ef3eb

> Scan converter: Special case vertical lines.
> base/gxscanc.c

2017-03-29 11:55:22 +0100
Robin Watts <robin.watts@artifex.com>
df5be672c357ffc884d0b2f0b7a890e1783ed402

> Remove unnecessary assignments from scan converter
> base/gxscanc.c

2017-03-28 19:32:26 +0100
Robin Watts <robin.watts@artifex.com>
2342e8533bf55a39226e0c99e75c9d2aae3b3d6b

> Tweak Scan Converter.
> Mark pointers as restricted to try to alleviate aliasing.
> Use static inlines for speed.
> base/gxscanc.c

2017-03-28 09:12:05 -0700
Ray Johnston <ray.johnston@artifex.com>
93e2557fb36f69310b7f325c70203ae063ef1fae

> Fix clist file to invalidate the read cache upon writing (see bug 697689).
> This fixes the unknownerror reported by the bug, but does not totally fix
> the use of # false .outputpage with the clist since the data after the
> first cmd_opv_end_page is not rendered to the page (stops the clist reader).
> The bug is left open for that reason and has been marked bountiable.
> base/gxclfile.c

2017-03-24 17:32:14 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
fa6f17de62fd27cef4005f336afcd1ac656dc9af

> Bug 697545: Memory Squeezing fix i_register_root leaks.
> Fix memory leak for i_register_root allocation when memory squeezing:
> gs -sDEVICE=bit -o /dev/null: examples/tiger.eps
> base/gsiodev.c
> base/gslibctx.c
> base/gslibctx.h
> psi/imain.c
> psi/zfont.c

2017-03-23 09:20:41 +0000
Chris Liddell <chris.liddell@artifex.com>
2eab4ad4d3e861e8e39a10ba58cfdb217b32db78

> Remove a pointless typedef
> base/gsmemory.h

2017-03-27 09:38:03 +0100
Ken Sharp <ken.sharp@artifex.com>
c06135acc959dbc0458352579bafe238794f2733

> pdfwrite - don't try to allocate a 0 length buffer for metadata
> Bug #697684 "Regression - Ghostscript 9.21 fails when pdfmark contains certain Unicode characters"
> Under some conditions, specifying a 0 length buffer size when calling
> gs_alloc_bytes() can return a NULL pointer. Since we use a NULL return
> to indicate a failure to allocate a buffer, this results in a VM error.
> In this commit we check the data length and don't try to allocate or
> use a 0 length buffer.
> We'll tackle the allocation problem separately, it would be better if
> gs_alloc_bytes didn't return a NULL pointer.
> devices/vector/gdevpdfe.c

2017-03-24 11:47:33 +0000
Ken Sharp <ken.sharp@artifex.com>
0d21a58ab12b9584faa54baa48ce0dab350af53e

> jbig2dec - refine test for "Denial of Service" images
> Bug 697682 "Incorrectly displayed a PDF file on GSView, MuPDF and GhostScript"
> In commit 7366747076f3b75def52079bd4d5021539a16394 Simon introduced a
> test to try and detect a JBIG2 compressed image which would take an
> unreasonable amount of time to process. Unfortunately, the test also trips
> up this real world (if rather extreme) example.
> The test looks for an image to be > 16MB and for the segment being
> processed to contain less than 1/256 of the image data. However, since
> we use this same section for symbol decoding, the segment size can be
> considerably smaller than that, and still be legal.
> This commit alters the image size to 64MB (as this is, frankly, ridiculously
> large for a JBIG2 image) and for the segment size to be less than
> 1/65536 of the total image data. This means that images less than 64MB,
> with segments larger than ~1KB might still cause a DOS, but this seems
> to be simply a problem we have to accept.
> Since the DOS time is dependent on the size of the data, and the size
> of the segment, this is a compromise.
> jbig2dec/jbig2_generic.c

2017-03-23 19:36:43 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
eb6ebd779b24cf36ac8dd13e3553c9b262235b37

> Bug 697545: Memory Squeezing fix events 244 to 267
> Fix memory leaks for allocation event number 244 to 267
> when memory squeezing:
> gs -sDEVICE=bit -o /dev/null: examples/tiger.eps
> Setting the init_done level earlier in gs_main_init1 means that the
> existing code in gs_main_finit will clean up after any failures in
> i_plugin_init and i_iodev_init.
> psi/imain.c

2017-03-21 22:38:44 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
6dd92923afc2779975c0c7a128bb12ed92c263ba

> Bug 697545: Memory Squeezing updated fix for events 10 to 33
> Fix memory leaks for allocation event number 10 to 33
> when memory squeezing:
> gs -sDEVICE=bit -o /dev/null: examples/tiger.eps
> psi/ialloc.c
> psi/imain.c

2017-03-21 17:50:14 +0000
Chris Liddell <chris.liddell@artifex.com>
fa182eb185494fae17731f426fb3307d7feda4f0

> Bug 697681: fix shared lib build with openjpeg >= 2.1.1
> In 2.1.1 openjpeg extended the use of the OPJ_STATIC to use gcc attributes to
> hide certain functions, as well as the previous use of preventing the
> inclusion of the Windows DllMain function.
> As we (in Ghostscript) need the functions the OPJ_STATIC on Linux/Unix hides,
> only set the flag for Windows builds.
> base/lib.mak
> psi/msvc.mak

2017-03-21 17:59:12 +0000
Chris Liddell <chris.liddell@artifex.com>
c17c7bbaad9002b38f4881497fc3ce3cc4eb64e6

> Add capability to sign the nsis installer exe
> On the nmake command line or in the evironment, it requires the following
> variables to be set:
> KEYFILE - pfx file containing the key
> KEYPWORD - password for using the above key file
> TIMESTAMP - URL for the timestamp server
> psi/winint.mak

2017-03-21 15:45:34 +0000
Chris Liddell <chris.liddell@artifex.com>
a0e27403bbb991f5a541d39122a92505afb0d1dc

> Fix the shared openjpeg build
> base/sjpx_openjpeg.c

2017-03-21 12:01:02 +0000
Chris Liddell <chris.liddell@artifex.com>
b8b1d543fe833478c167940110e04ddc353d0f3b

> Bug 697677: fix support for --disable-openjpeg
> base/lib.mak
> base/sjpx_none.c

2017-03-20 09:04:31 +0000
Chris Liddell <chris.liddell@artifex.com>
59d8b2e95d2acd2b7e3f86809fa9ebe8ea7eeb8d

> Move invalid_file_stream into gc memory.
> At initialisation we create an special stream (in the gs context) to use as an
> invalid stream whenever we need one.
> It was originally being allocated in non-gc memory. Since the context is in
> gc memory, the invalid_file_stream can leak. Rather than add explicit freeing
> of the invalid_file_stream, and risk a life span conflict between a gc object
> and a non-gc object, it makes it neater, and more sense, to keep the
> invalid_file_stream in gc memory. It *is* stable memory (not subject to
> save/restore) and allocated as an immovable object (not subject to relocating
> by the garbager).
> Fixes a problem spotted by Shailesh Mistry while working on memory squeezing
> event 170.
> psi/icontext.c

2017-03-20 09:34:11 +0000
Ken Sharp <ken.sharp@artifex.com>
309eca4e0a31ea70dcc844812691439312dad091

> Ensure a device has raster memory, before trying to read it.
> Bug #697676 "Null pointer dereference in mem_get_bits_rectangle()"
> This is only possible by abusing/mis-using Ghostscript-specific
> language extensions, so cannot happen in a general PostScript program.
> Nevertheless, Ghostscript should not crash. So this commit checks the
> memory device to see if raster memory has been allocated, before trying
> to read from it.
> base/gdevmem.c

2016-12-29 17:08:58 +0000
Robin Watts <robin.watts@artifex.com>
dd5da2cb3e08398ac6d86598b36b00994d058308

> Make the edgebuffer scan converter the default.
> Selecting the new (edgebuffer) scan converter (as is now the
> default) has the effect of forcing the fill adjust values to
> be 0 or 0.5.
> base/gslibctx.h
> base/gsstate.c
> base/gsstate.h
> base/gxfill.c
> pcl/pcl/pctop.c
> psi/zmisc.c

2017-03-16 18:27:54 +0000
Robin Watts <robin.watts@artifex.com>
c4bff06c6c527af4cdddc2bd4cbd6fef8ffa4e22

> Set tags correctly for glyphs when sent as masked images.
> In gx_image_cached_char we can end up sending the glyph as
> an imagemask. When we do so, the tag is incorrectly reset
> to image, rather than text.
> Here we correct that by adding an 'image_is_text' flag to
> gs_image_init and gs_image_begin_typed.
> This can be seen by the fact that:
> gs -sDEVICE=bitrgbtags -o out.bit -r600 -dMaxBitmap=1000
> tests_private/customer_tests/jw202dwo.pcl
> and
> gs -sDEVICE=bitrgbtags -o out.bit -r600 -dMaxBitmap=400000000
> tests_private/customer_tests/jw202dwo.pcl
> give different tag values for the text.
> base/gsimage.c
> base/gsimage.h
> base/gsptype1.c
> base/gxccache.c
> base/gxfapi.c
> pcl/pcl/pctext.c
> pcl/pcl/rtraster.c
> pcl/pl/pldraw.c
> psi/zimage.c
> psi/zimage2.c
> xps/xpsimage.c

2017-03-06 10:31:53 +0000
Chris Liddell <chris.liddell@artifex.com>
66361d261c6cdcf4d01463ac9d1d769951a32bed

> Bring master up to date with 9.21 release branch
> Update copyrights in "top" makefiles
> Update dates and versions
> Update News.html and History9.htm
> with highlights and changelogs
> Date and product string for 9.21 release
> Changelog and News + date for 9.21 release
> Dates for 9.21 release
> Makefile.in
> base/gscdef.c
> base/version.mak
> doc/API.htm
> doc/C-style.htm
> doc/Commprod.htm
> doc/DLL.htm
> doc/Deprecated.htm
> doc/Details8.htm
> doc/Details9.htm
> doc/Develop.htm
> doc/Devices.htm
> doc/Drivers.htm
> doc/Fonts.htm
> doc/Helpers.htm
> doc/History1.htm
> doc/History2.htm
> doc/History3.htm
> doc/History4.htm
> doc/History5.htm
> doc/History6.htm
> doc/History7.htm
> doc/History8.htm
> doc/History9.htm
> doc/Install.htm
> doc/Issues.htm
> doc/Language.htm
> doc/Lib.htm
> doc/Make.htm
> doc/News.htm
> doc/Projects.htm
> doc/Ps-style.htm
> doc/Ps2epsi.htm
> doc/Psfiles.htm
> doc/Readme.htm
> doc/Release.htm
> doc/SavedPages.htm
> doc/Source.htm
> doc/Unix-lpr.htm
> doc/Use.htm
> doc/VectorDevices.htm
> doc/WhatIsGS.htm
> doc/Xfonts.htm
> doc/gs-vms.hlp
> doc/sample_downscale_device.htm
> doc/thirdparty.htm
> man/dvipdf.1
> man/font2c.1
> man/gs.1
> man/gslp.1
> man/gsnd.1
> man/pdf2dsc.1
> man/pdf2ps.1
> man/pf2afm.1
> man/pfbtopfa.1
> man/printafm.1
> man/ps2ascii.1
> man/ps2epsi.1
> man/ps2pdf.1
> man/ps2pdfwr.1
> man/ps2ps.1
> man/wftopfa.1
> psi/winint.mak

2017-03-16 15:57:47 +0000
Chris Liddell <chris.liddell@artifex.com>
4237b0bc1155a781de80c0079d72c0bcdacbb95e

> Remove two erroneous uses of return_error
> psi/idisp.c

2017-03-16 07:54:26 -0700
Ray Johnston <ray.johnston@artifex.com>
ec32c674469fab173c6df5e97bc3f3aff37e6c92

> Fix SEGV with tiffsep1 device found by customer 531.
> When "warning_given" was set, the device was cast to tiffsep_device,
> but the parameter was in a different offset with the tiffsep1_device.
> Move the warning_given to the tiffsep_devices_common part of the structure
> so the casting works properly.
> devices/gdevtsep.c

2017-03-15 14:15:00 +0000
Robin Watts <robin.watts@artifex.com>
6cd467ecdb2678847670fd22a0d5dd39b89e8ca3

> Tweak code in gxfapi.c to avoid repetition.
> base/gxfapi.c

2017-03-15 19:04:13 +0000
Robin Watts <robin.watts@artifex.com>
8ad42f17df0c9e7afe25f95ecfae8fd005ac589c

> Fix typo.
> base/gxclimag.c

2017-03-15 19:38:32 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
e146bb38c20e5b967d89e16db244b2beb74ba345

> Bug 697545: Memory squeezing SEGV event in gstate_clone
> An allocation failure in gstate_clone caused pgs->color to be
> freed too early when memory squeezing:
> gs -sDEVICE=bit -o /dev/null: examples/tiger.eps
> base/gsstate.c

2017-03-15 15:32:03 +0000
Ken Sharp <ken.sharp@artifex.com>
917b4e28c37d5e9ac3a605658f51b29a2357ab28

> PDF interpreter - add B operators to spcial 'W' handling
> Previously we had altered the handling of stroke, fill and eofill when
> in a 'W' context, to detect changes in the graphics state between the
> 'W' or 'W*' operation and the terminating path operator.
> Unfortunately when this was done the B, b, B* and b* operators were
> missed, which meant these always behaved as if an invalid graphics
> state change was executed, ignored the graphics state change, and
> ended up rednering incorrectly.
> This commit adds those operators to the special handling of the W and
> W* operators.
> Resource/Init/pdf_ops.ps

2017-03-15 14:46:49 +0000
Chris Liddell <chris.liddell@artifex.com>
46ef6bc80bd7388883a00aa866af38fe8f05d45b

> pdfwrite: properly handle text outside the clip
> Bug 697442:
> To work around an Acrobat limitation (related to glyphs with very large
> coordinates), we don't emit glyph whose bounding box is outside the current
> clipping region.
> However, the file in question here uses a combination of show and glyphshow to
> display text, and it also measures (in the manner of stringwidth) to position
> the text. *But* because it relies on glyphshow, it cannot use stringwidth. It
> moves the current point outside the page, draws the text (strings and glyph
> names), and records how far the current point has moved.
> The previous code would skip out early to avoid emitting the clipped out glyphs,
> whilst still apparently updating the current point. *But* the values from which
> the current point were updated were not correctly set due to skipping out
> early.
> We now do everything *except* emit the glyphs, thus the various values are
> correct, and the currentpoint is updated properly.
> devices/vector/gdevpdte.c

2017-03-12 17:07:18 -0700
Ray Johnston <ray.johnston@artifex.com>
16b7f46fa03a82445784608b8db21f11cd76c884

> Fix Bug 697661 -- SEGV with tiffsep1 device and threshold array halftones
> Threshold arrays create a different type of gx_ht_order than screen type
> halftones so the bit_data is short X,Y coordinates instead of offset,mask
> (gx_ht_bit) elements that the tiffsep1 "threshold_from_order" code was
> expecting. Using the bit_index proc of the order works for all gx_ht_order
> types.
> TODO: determine if it is possible to use the gx_ht_construct_threshold
> function. This function is used in the FAST_HT_CODE used for some
> images to halftone devices that need halftoning.
> devices/gdevtsep.c

2017-03-11 15:10:00 -0800
Ray Johnston <ray.johnston@artifex.com>
a5a2862d9503fedfb32f46f1cbc669c40497474f

> Fix bug 695280 page mode and clist mode differ
> The clist mode "uses_color" was ignoring CombineWithColor if the rop
> did not use the texture (rop3_uses_T false). This affects the ps3cet
> 09-40.PS and pcl5ccet/23-11.BIN files.
> Note that this reults in these cases not using high-level images
> in the clist since currently the clist cannot accomodate the two
> different colorspaces (painting an Indexed colorspace image through
> a pattern). Since the number of changed file is minimal, I assume
> that the performance impact does not affect many files.
> base/gxclimag.c

2017-03-10 19:44:43 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
cc35e521d8fb162f97252a3509b9041f4253b818

> Bug 697545: Memory Squeezing updated fix for events 10 to 33
> Fix memory leaks for allocation event number 10 to 33
> when memory squeezing:
> gs -sDEVICE=bit -o /dev/null: examples/tiger.eps
> psi/ialloc.c
> psi/imain.c

2017-03-10 13:14:10 +0000
Ken Sharp <ken.sharp@artifex.com>
acf5451a357a8595e692fe86e0be722a69e036dc

> PDF interpreter - avoid looping/recursion searching for Default* spaces
> Bug #697655 " gswin32c.exe hangs while interpreting some pdf files"
> The (insane) PDF file ended up looping through Resources and XObjects
> looking for any instances of the Default* colour spaces. We need the
> information to set UseCIEColor to true if any are present, in order
> to do proper colour management on the input colours.
> Follows the same technique we already use for transparency and cpot
> colour searches.
> Resource/Init/pdf_main.ps

2017-02-23 18:06:53 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
62a865bbdf2abafabe5971d42c71be2bd1233e5c

> Bug 697545: Memory Squeezing fix events 10 to 33
> Fix memory leaks for allocation event number 10 to 33
> when memory squeezing:
> gs -sDEVICE=bit -o /dev/null: examples/tiger.eps
> psi/ialloc.c
> psi/ialloc.h
> psi/imain.c

2017-03-05 20:16:39 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
1df92f6952038fa70aa9cad8c398f360b0323539

> Bug 697545: Memory Squeezing fix.
> Fix memory leak for allocation event number 170
> when memory squeezing:
> gs -sDEVICE=bit -o /dev/null: examples/tiger.eps
> psi/interp.c

2017-03-07 14:20:23 +0000
Robin Watts <robin.watts@artifex.com>
67dba2b7fdb5adf4b3f8cdf112c7ac67a89a9ea8

> MSVC: Add 2 missing files to solution.
> windows/ghostscript.vcproj

2017-03-08 10:15:25 +0000
Ken Sharp <ken.sharp@artifex.com>
f37a69d40a6222d903b48b97b58a26151ea2e493

> txtwrite - fix Unicode conversion of glyph names 'unixxxx'
> More fallout from the ToUnicode revamp required for pdfwrite, commit
> 9dba57f0f9a53c130ec2771c0ed1d7bd6bbef6ab
> The code to handle converting glyphs whose name conforms to the
> uniXXXX form, when there is no better ToUnicode information, was still
> returning the number of bytes, not shorts. In addition, the original
> change was packing the 2 bytes as two shorts instead of a singe short.
> This resulted in incorrect output. Fixed here by packing the 4 nibbles
> into a single short and returning a count of 1 short.
> devices/vector/gdevtxtw.c

2017-03-03 19:42:29 +0000
Robin Watts <robin.watts@artifex.com>
64f5d62c80176085335d84c24e02cd49d9e032b9

> Bug 697545: Extend "separable_and_linear" processing.
> First, avoid needless check_separable_and_linear tests.
> When we make a memory store for a target device, we use
> the encoding/decoding color functions from that target
> device. It seems reasonable to copy the "separable_and_linear"
> information from that device too, to avoid having to needlessly
> retest using the same encoding/decoding functions to get
> the same answer.
> Next, extend gx_color_enc_sep_lin_t to represent not just
> whether we know details about the device colors separability
> and linearity (and what those details are if known), but also
> to encode whether those are standard encodings or not. The
> standard encoding is defined to be "that which is compatible
> with the pdf14 compositor".
> Finally, we add a function, check_device_separable_encoding,
> that 'promotes' the record for a given space from being a
> known separable_and_linear one, to one that knows it's
> separable_and_linear, but also knows whether it uses the
> standard encoding.
> Call this in clist_close_writer_and_init_reader to ensure that
> the buffer device is created knowing whether it's a standard
> encoding or not. If called here, it only ever needs to run once.
> Call it again in pdf14_ok_to_optimize (just in case we ever slip
> through - this takes no time if it has been run already). This
> enables us to make a correct choice, and to avoid skipping
> transparency bands if we are not using the standard (pdf14
> compositor compatible) encoding.
> base/gdevdflt.c
> base/gdevmem.c
> base/gdevp14.c
> base/gscspace.c
> base/gsicc.c
> base/gsovrc.c
> base/gxclread.c
> base/gxcmap.c
> base/gxdevcli.h
> base/gxdevice.h
> base/gxshade6.c
> psi/zcolor.c

2017-03-07 10:24:37 +0000
Robin Watts <robin.watts@artifex.com>
ddd39cb2ea1773bf001cd4f975856446c2bd7f43

> Bug 696915: Second attempt at fix.
> In attempting to fix a buffer overrun in mapped8_copy01, I broke it.
> This is a proper fix. Previously I'd missed the increment of count
> after the loop.
> base/gdevm8.c

2017-03-07 10:08:11 +0000
Robin Watts <robin.watts@artifex.com>
1a7bfc5dd6d84a15bba163c0f7328fb766d8be20

> Revert "Bug 696915: Fix buffer overread in mapped8_copy01."
> This reverts commit 4e646ef8103f3ab2ab9d7de64bd30cc2156f0441.
> Cluster testing shows problems with this.
> base/gdevm8.c

2017-03-06 10:00:11 +0000
Chris Liddell <chris.liddell@artifex.com>
b46bb757037a18bfcc95e61fbe751df5e4cfdd58

> Bump version number.
> Resource/Init/gs_init.ps
> base/version.mak

2017-03-16 09:20:11 +0000
Chris Liddell <chris.liddell@artifex.com>
f80288c8a4b9c9abfc0fa3ccce3b6d169baa59ff

> Dates for 9.21 release
> doc/API.htm
> doc/C-style.htm
> doc/Commprod.htm
> doc/DLL.htm
> doc/Deprecated.htm
> doc/Details8.htm
> doc/Details9.htm
> doc/Develop.htm
> doc/Devices.htm
> doc/Drivers.htm
> doc/Fonts.htm
> doc/Helpers.htm
> doc/History1.htm
> doc/History2.htm
> doc/History3.htm
> doc/History4.htm
> doc/History5.htm
> doc/History6.htm
> doc/History7.htm
> doc/History8.htm
> doc/History9.htm
> doc/Install.htm
> doc/Issues.htm
> doc/Language.htm
> doc/Lib.htm
> doc/Make.htm
> doc/Projects.htm
> doc/Ps-style.htm
> doc/Ps2epsi.htm
> doc/Psfiles.htm
> doc/Readme.htm
> doc/Release.htm
> doc/SavedPages.htm
> doc/Source.htm
> doc/Unix-lpr.htm
> doc/Use.htm
> doc/VectorDevices.htm
> doc/WhatIsGS.htm
> doc/Xfonts.htm
> doc/gs-vms.hlp
> doc/sample_downscale_device.htm
> doc/thirdparty.htm
> man/dvipdf.1
> man/font2c.1
> man/gs.1
> man/gslp.1
> man/gsnd.1
> man/pdf2dsc.1
> man/pdf2ps.1
> man/pf2afm.1
> man/pfbtopfa.1
> man/printafm.1
> man/ps2ascii.1
> man/ps2epsi.1
> man/ps2pdf.1
> man/ps2pdfwr.1
> man/ps2ps.1
> man/wftopfa.1

2017-03-16 09:19:16 +0000
Chris Liddell <chris.liddell@artifex.com>
a96ade6b7238764b1a940dafbe2b7d52932f66ec

> Changelog and News + date for 9.21 release
> doc/History9.htm
> doc/News.htm

2017-03-16 09:13:57 +0000
Chris Liddell <chris.liddell@artifex.com>
db6fa66eba7427854f491738500ecf9f179446fc

> Date and product string for 9.21 release
> base/gscdef.c
> base/version.mak

2017-03-12 17:07:18 -0700
Ray Johnston <ray.johnston@artifex.com>
6ffbbb5a389df10d7b7a0a630a910363f75b73d6

> Fix Bug 697661 -- SEGV with tiffsep1 device and threshold array halftones
> Threshold arrays create a different type of gx_ht_order than screen type
> halftones so the bit_data is short X,Y coordinates instead of offset,mask
> (gx_ht_bit) elements that the tiffsep1 "threshold_from_order" code was
> expecting. Using the bit_index proc of the order works for all gx_ht_order
> types.
> TODO: determine if it is possible to use the gx_ht_construct_threshold
> function. This function is used in the FAST_HT_CODE used for some
> images to halftone devices that need halftoning.
> devices/gdevtsep.c

2017-03-08 10:15:25 +0000
Ken Sharp <ken.sharp@artifex.com>
a629fb9e9f03d8d5aefd32d3c46f6045dba41ccb

> txtwrite - fix Unicode conversion of glyph names 'unixxxx'
> More fallout from the ToUnicode revamp required for pdfwrite, commit
> 9dba57f0f9a53c130ec2771c0ed1d7bd6bbef6ab
> The code to handle converting glyphs whose name conforms to the
> uniXXXX form, when there is no better ToUnicode information, was still
> returning the number of bytes, not shorts. In addition, the original
> change was packing the 2 bytes as two shorts instead of a singe short.
> This resulted in incorrect output. Fixed here by packing the 4 nibbles
> into a single short and returning a count of 1 short.
> devices/vector/gdevtxtw.c

2017-03-07 10:24:37 +0000
Robin Watts <robin.watts@artifex.com>
bea6c3e636b0fcf49ab5042fb0506fdb1f5fe4b8

> Bug 696915: Second attempt at fix.
> In attempting to fix a buffer overrun in mapped8_copy01, I broke it.
> This is a proper fix. Previously I'd missed the increment of count
> after the loop.
> base/gdevm8.c

2017-03-07 10:08:11 +0000
Robin Watts <robin.watts@artifex.com>
d1d0bf5f9776bf2ad26e223bf3d36e85176e7c78

> Revert "Bug 696915: Fix buffer overread in mapped8_copy01."
> This reverts commit 4e646ef8103f3ab2ab9d7de64bd30cc2156f0441.
> Cluster testing shows problems with this.
> base/gdevm8.c

2017-03-07 10:42:00 +0000
Robin Watts <robin.watts@artifex.com>
8115fa337c70e08516a9fad6da68edf5b461cb2d

> Product string for 9.20RC2
> base/gscdef.c

2017-03-06 10:57:03 +0000
Chris Liddell <chris.liddell@artifex.com>
53dc6a1e4bb61ce1aaf689550d42ec6cf706d889

> Update News.html and History9.htm
> with highlights and changelogs
> doc/History9.htm
> doc/News.htm

2017-03-06 10:32:53 +0000
Chris Liddell <chris.liddell@artifex.com>
2f4b5eb2cf7d173d69c7a6bdb8008447f8e1b174

> Update dates and versions
> doc/API.htm
> doc/C-style.htm
> doc/Commprod.htm
> doc/DLL.htm
> doc/Deprecated.htm
> doc/Details8.htm
> doc/Details9.htm
> doc/Develop.htm
> doc/Devices.htm
> doc/Drivers.htm
> doc/Fonts.htm
> doc/Helpers.htm
> doc/History1.htm
> doc/History2.htm
> doc/History3.htm
> doc/History4.htm
> doc/History5.htm
> doc/History6.htm
> doc/History7.htm
> doc/History8.htm
> doc/History9.htm
> doc/Install.htm
> doc/Issues.htm
> doc/Language.htm
> doc/Lib.htm
> doc/Make.htm
> doc/News.htm
> doc/Projects.htm
> doc/Ps-style.htm
> doc/Ps2epsi.htm
> doc/Psfiles.htm
> doc/Readme.htm
> doc/Release.htm
> doc/SavedPages.htm
> doc/Source.htm
> doc/Unix-lpr.htm
> doc/Use.htm
> doc/VectorDevices.htm
> doc/WhatIsGS.htm
> doc/Xfonts.htm
> doc/gs-vms.hlp
> doc/sample_downscale_device.htm
> doc/thirdparty.htm
> man/dvipdf.1
> man/font2c.1
> man/gs.1
> man/gslp.1
> man/gsnd.1
> man/pdf2dsc.1
> man/pdf2ps.1
> man/pf2afm.1
> man/pfbtopfa.1
> man/printafm.1
> man/ps2ascii.1
> man/ps2epsi.1
> man/ps2pdf.1
> man/ps2pdfwr.1
> man/ps2ps.1
> man/wftopfa.1

2017-03-06 10:31:53 +0000
Chris Liddell <chris.liddell@artifex.com>
7d3e8640525cab77feabf33db732e5d1bb4eb652

> Update copyrights in "top" makefiles
> Makefile.in
> psi/winint.mak

2017-03-06 10:28:47 +0000
Chris Liddell <chris.liddell@artifex.com>
8f917db5eb0b94c864cef770022d86b22e45df98

> Product string for 9.20RC1
> base/gscdef.c

## Version 9.21 (2017-03-16)

This is the fifteenth full release in the stable 9.x series.

Highlights in this release include:

- pdfwrite now preserves annotations from input PDFs (where possible).

- The GhostXPS interpreter now provides the pdfwrite device with the data it requires to emit a ToUnicode CMap: thus allowing fully searchable PDFs to be created from XPS input (in the vast majority of cases).

- Ghostscript now allows the default color space for PDF transparency blends.

- The Ghostscript/GhostPDL configure script now has much better/fuller support for cross compiling.

- The tiffscaled and tiffscaled4 devices can now use ETS (Even Tone Screening)

- The toolbin/pdf_info.ps utility can now emit the PDF XML metadata.

- Ghostscript has a new scan converter available (currently optional, but will become the default in a near future release). It can be enabled by using the command line option: '-dSCANCONVERTERTYPE=2'. This new implementation provides vastly improved performance with large and complex paths.

- The usual round of bug fixes, compatibility changes, and incremental improvements.

For a list of open issues, or to report problems, please visit bugs.ghostscript.com.

### Incompatible changes

- The planned device API tidy (still!) did not happen for this release, due to time pressures, but we still intend to undertake the following: We plan to somewhat tidy up the device API. We intend to remove deprecated device procs (methods/function pointers) and change the device API so every device proc takes a graphics state parameter (rather than the current scheme where only a very few procs take an imager state parameter). This should serve as notice to anyone maintaining a Ghostscript device outside the canonical source tree that you may (probably will) need to update your device(s) when these changes happen. Devices using only the non-deprecated procs should be trivial to update.

### Changelog

2017-03-16 09:13:57 +0000
Chris Liddell <chris.liddell@artifex.com>
db6fa66eba7427854f491738500ecf9f179446fc

> Date and product string for 9.21 release
> base/gscdef.c
> base/version.mak

2017-03-12 17:07:18 -0700
Ray Johnston <ray.johnston@artifex.com>
6ffbbb5a389df10d7b7a0a630a910363f75b73d6

> Fix Bug 697661 -- SEGV with tiffsep1 device and threshold array halftones
> Threshold arrays create a different type of gx_ht_order than screen type
> halftones so the bit_data is short X,Y coordinates instead of offset,mask
> (gx_ht_bit) elements that the tiffsep1 "threshold_from_order" code was
> expecting. Using the bit_index proc of the order works for all gx_ht_order
> types.
> TODO: determine if it is possible to use the gx_ht_construct_threshold
> function. This function is used in the FAST_HT_CODE used for some
> images to halftone devices that need halftoning.
> devices/gdevtsep.c

2017-03-08 10:15:25 +0000
Ken Sharp <ken.sharp@artifex.com>
a629fb9e9f03d8d5aefd32d3c46f6045dba41ccb

> txtwrite - fix Unicode conversion of glyph names 'unixxxx'
> More fallout from the ToUnicode revamp required for pdfwrite, commit
> 9dba57f0f9a53c130ec2771c0ed1d7bd6bbef6ab
> The code to handle converting glyphs whose name conforms to the
> uniXXXX form, when there is no better ToUnicode information, was still
> returning the number of bytes, not shorts. In addition, the original
> change was packing the 2 bytes as two shorts instead of a singe short.
> This resulted in incorrect output. Fixed here by packing the 4 nibbles
> into a single short and returning a count of 1 short.
> devices/vector/gdevtxtw.c

2017-03-07 10:24:37 +0000
Robin Watts <robin.watts@artifex.com>
bea6c3e636b0fcf49ab5042fb0506fdb1f5fe4b8

> Bug 696915: Second attempt at fix.
> In attempting to fix a buffer overrun in mapped8_copy01, I broke it.
> This is a proper fix. Previously I'd missed the increment of count
> after the loop.
> base/gdevm8.c

2017-03-07 10:08:11 +0000
Robin Watts <robin.watts@artifex.com>
d1d0bf5f9776bf2ad26e223bf3d36e85176e7c78

> Revert "Bug 696915: Fix buffer overread in mapped8_copy01."
> This reverts commit 4e646ef8103f3ab2ab9d7de64bd30cc2156f0441.
> Cluster testing shows problems with this.
> base/gdevm8.c

2017-03-07 10:42:00 +0000
Robin Watts <robin.watts@artifex.com>
8115fa337c70e08516a9fad6da68edf5b461cb2d

> Product string for 9.20RC2
> base/gscdef.c

2017-03-06 10:32:53 +0000
Chris Liddell <chris.liddell@artifex.com>
2f4b5eb2cf7d173d69c7a6bdb8008447f8e1b174

> Update dates and versions
> doc/API.htm
> doc/C-style.htm
> doc/Commprod.htm
> doc/DLL.htm
> doc/Deprecated.htm
> doc/Details8.htm
> doc/Details9.htm
> doc/Develop.htm
> doc/Devices.htm
> doc/Drivers.htm
> doc/Fonts.htm
> doc/Helpers.htm
> doc/History1.htm
> doc/History2.htm
> doc/History3.htm
> doc/History4.htm
> doc/History5.htm
> doc/History6.htm
> doc/History7.htm
> doc/History8.htm
> doc/History9.htm
> doc/Install.htm
> doc/Issues.htm
> doc/Language.htm
> doc/Lib.htm
> doc/Make.htm
> doc/News.htm
> doc/Projects.htm
> doc/Ps-style.htm
> doc/Ps2epsi.htm
> doc/Psfiles.htm
> doc/Readme.htm
> doc/Release.htm
> doc/SavedPages.htm
> doc/Source.htm
> doc/Unix-lpr.htm
> doc/Use.htm
> doc/VectorDevices.htm
> doc/WhatIsGS.htm
> doc/Xfonts.htm
> doc/gs-vms.hlp
> doc/sample_downscale_device.htm
> doc/thirdparty.htm
> man/dvipdf.1
> man/font2c.1
> man/gs.1
> man/gslp.1
> man/gsnd.1
> man/pdf2dsc.1
> man/pdf2ps.1
> man/pf2afm.1
> man/pfbtopfa.1
> man/printafm.1
> man/ps2ascii.1
> man/ps2epsi.1
> man/ps2pdf.1
> man/ps2pdfwr.1
> man/ps2ps.1
> man/wftopfa.1

2017-03-06 10:31:53 +0000
Chris Liddell <chris.liddell@artifex.com>
7d3e8640525cab77feabf33db732e5d1bb4eb652

> Update copyrights in "top" makefiles
> Makefile.in
> psi/winint.mak

2017-03-06 10:28:47 +0000
Chris Liddell <chris.liddell@artifex.com>
8f917db5eb0b94c864cef770022d86b22e45df98

> Product string for 9.20RC1
> base/gscdef.c

2017-03-03 10:20:14 +0000
Chris Liddell <chris.liddell@artifex.com>
278c66866eb41c0d8220d31bd7f12887706eb51c

> Change git behaviour broke gitlog2changelog.py
> remove the --cc options
> toolbin/gitlog2changelog.py

2017-03-03 10:00:05 -0700
Henry <henry.stiles@artifex.com>
1d2da0ae232605c4f62a97f8cf1cedce15c4ba9f

> Add error message when resident fonts are not found.
> The fix also uncovered a regression. The XL interpreter was checking
> if the function to load built in fonts returned a code less than 0
> which does not happen anymore. Upon error the function returns 0 (false),
> indicating no fonts found.
> pcl/pcl/pcfont.c
> pcl/pxl/pxsessio.c

2017-03-03 06:58:19 -0700
Henry Stiles <henry.stiles@artifex.com>
c9cb91b2fb59481247aaee88779577ef6c103327

> Update the default PCL font search path.
> The font search path was never updated when the directory structure
> changed, also add a directory entry to allow PCL to find fonts while
> cluster testing without an environment variable or command line
> setting.
> pcl/pl/pjparse.c

2017-03-03 09:30:59 +0000
Chris Liddell <chris.liddell@artifex.com>
62354d822b29006d7e431a2b07c70106647b62c8

> Remove the left over Mac specific files.
> OS X is basically just a Unix-like system, so building gs for it is now just
> like for any other Unix-like system. We haven't supported Mac Classic for some
> time.
> Several Mac related files were left over, atrophied and no longer any value.
> This removes them.
> base/gsiomacres.c
> base/lib.mak
> base/macgenmcpxml.sh
> base/macos_carbon_d_pre.h
> base/macos_carbon_pre.h
> base/macos_classic_d_pre.h
> base/macosx.mak
> base/macsystypes.h
> windows/ghostscript.vcproj
> windows/ghostscript_rt.vcxproj

2017-03-02 16:35:51 -0800
Ray Johnston <ray.johnston@artifex.com>
ba8d4abaa9c33edd8c79da7022f231e4b21f22e9

> fix bug 697621: color_usage.or bits were wrong with transparency
> The psdcmykog uses the color_usage.or bits to decide which components need to
> be processed, skipping those that are not needed. When the pdf14 device changes
> the color_info the color that will actually go on the page cannot be known
> without transforming the color to the device color which is too expensive.
> Also fix the polarity tests in gx_color_index2usage (it was being ignored)
> base/gxclist.c
> base/gxclpath.c

2017-03-02 12:26:16 +0000
Chris Liddell <chris.liddell@artifex.com>
ea14e8c7c8f8ece7a7ea2a324bca2c115c61b1a3

> Bug 697626: bounds check allocations in the chunk allocator
> Ensure the requested memory allocation doesn't overflow the 32 bit variables
> in the chunk allocator.
> base/gsmchunk.c

2017-03-01 10:26:17 -0800
Ray Johnston <ray.johnston@artifex.com>
670e5d250c6049694f0f1f1c3d15270d6dc2246a

> Bug 697615: Only apply CompatibleOverprint handling to some colorspaces
> Testing with Adobe shows that only Gray, CMYK, DeviceN and Sep color
> spaces should use the special CompatibleOverprint handling specified
> in the section "Compatibility with Opaque Overprinting".
> Resource/Init/pdf_ops.ps

2017-03-01 12:59:12 +0000
Robin Watts <robin.watts@artifex.com>
0a8f8a53a968a638e828086f0725780aa64793c0

> Fix clump handling.
> Ray spotted that running:
> debugbin/gs -r300 -Z@\$\?: -dJOBSERVER
> is enough to send us into an infinite loop.
> Tracking this down, it appears that the reason is to do with
> the gs_ref_memory_t's use of 'pcc' and 'cc'.
> It copies the 'current' chunk out of the splay tree, and then
> puts it back later, without realising that the splay tree
> may have been altered.
> The simplest fix appears to be just to not do this copying.
> base/gsalloc.c
> base/gxalloc.h
> psi/ialloc.c
> psi/igc.c
> psi/ilocate.c
> psi/isave.c

2017-02-28 17:36:00 +0000
Robin Watts <robin.watts@artifex.com>
f8c0d4e78f75de95b0d74210b3e929abef6f3a60

> Add sanity check on image sizes.
> Inspired by bug 697395, but doesn't actually solve any problem
> seen in that bug (or at least, not that I can see, as I can't
> reproduce the problem with file2).
> jbig2dec/jbig2_image.c

2017-03-01 09:47:58 -0700
Henry Stiles <henry.stiles@artifex.com>
bbb2b961388b028d7d9d8f6454ced8192ad513c1

> Fix Bug 697624 - PCL segfaults with --disable-compile inits.
> Instead of trying to continue we exit upon initialization if no fonts
> are found and the current emulation is PCL.
> pcl/pcl/pcfont.c

2017-02-28 18:43:04 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
ce437b88df500a184ae2ca15d67a019f57a11d20

> Bug 697545: Memory Squeezing fix.
> Fix memory leaks for allocation event numbers 25 to 32
> when memory squeezing:
> gs -sDEVICE=bit -o /dev/null: examples/tiger.eps
> psi/imain.c
> psi/iname.c
> psi/inames.h

2017-02-28 19:54:51 +0000
Chris Liddell <chris.liddell@artifex.com>
0ebb37a19ece80fa03af8de5047705722625870b

> Bug 697372: Fix crash due to pattern clist being freed
> When rendering a pattern from a clist into the pdf14 compositor, the compositor
> takes a reference to the pattern clist device. This is fine pre-page-clist, or
> with no page clist involved (when the memory is managed by the garbage
> collector), but post-page-clist the life span of the pattern clist device is
> dicated by the clist replay, *not* by references to it (as in the gc'ed case).
> This can result in a dangling pointer, which later causes a crash in the
> garbage collector when it cleans up after the page-clist has completed.
> So, when pattern fill has been completed, remove the reference to the pattern
> clist device.
> base/gdevp14.c

2017-02-28 15:36:34 +0000
Robin Watts <robin.watts@artifex.com>
459a0e650ffab1069a6f59c17775f5fd462c45d2

> Bug 696364: Restrict size of alphabits buffer
> Thanks to Michael for doing the investigation, and leaving a
> really good write up of the problem on the bug.
> The basic problem is that we have a transparency group that
> contains a softmask. The softmask is larger than the transparency
> group, so it is restricted to the size of the group and written
> into the clist as occupying just a small set of bands.
> The content for the softmask is larger, however, so when used with
> GraphicsAlphaBits, we create various alphabits devices, draw
> the contents, and then send the results with copy_alpha.
> These copy_alpha calls are NOT restricted to being within the
> reduced region for the softmask. This therefore upsets the clist
> reading.
> The fix, as suggested by Michael in his bug report is to limit
> the size of the softmask contents (by limiting the size of the
> alphabits buffers).
> Ideally the alphabits device would know what region to limit
> itself to just by looking at the graphics state it's passed in.
> Unfortunately, that doesn't work as the current softmask/groups
> aren't reflected in the graphic state. This feels wrong to me,
> but that's the way it is.
> Instead, we have to resort to asking the device to limit our
> bbox according to the current state. We achieve this by adding
> a new dev_spec_op, and adding the required plumbing to the pdf14
> device (to pass it on to the target) and the clist device (to
> actually do the restriction).
> base/gdevp14.c
> base/gspaint.c
> base/gxclrect.c
> base/gxdevsop.h

2017-02-28 07:05:58 -0800
Ray Johnston <ray.johnston@artifex.com>
4a9394e6abc6b0107da4f42675bf35eb031fe068

> Fix DEPTH is RAW_DUMP_AS_PAM GRAYSCALE_ALPHA header
> base/gxblend.c

2017-02-27 13:37:41 -0800
Ray Johnston <ray.johnston@artifex.com>
ff07b67892c201a0a16d983b05d121ac409b78a0

> Bug 697615: color_usage was incorrectly updated for devn with pdf14
> When the pdf14 compositor messes with the color space and color_info,
> it doesn't change the target (clist) color_info, but sets the new
> information in cldev->clist_color_info. In order to properly update the
> color_usage cmd_drawing_color_usage needs to set the bits according to the
> clist_color_info num_components and polarity in gx_dc_devn_get_nonzero_comps,
> so save the cldev->color_info values, set them to the cldev->clist_color_info
> values for the calculation and restore them afterwards
> base/gxclpath.c
> base/gxdcolor.c

2017-02-27 14:15:30 -0700
Henry Stiles <henry.stiles@artifex.com>
97ddb45834c73f697e53839c6b433f65248d9c2a

> Improve pcl page marking detection.
> Instead of looking at only the character's position to determine if a
> character marks the page we now look at the extant of the character's
> width. Thanks to Norbert Janssen for the fix.
> pcl/pcl/pcpage.c
> pcl/pcl/pcpage.h
> pcl/pcl/pctext.c

2017-02-27 18:20:39 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
8bb1aab8a60810aefb67a6d2764a54abc547878b

> Bug 697545: Memory Squeezing fix.
> Fix memory leak for allocation event number 22
> when memory squeezing:
> gs -sDEVICE=bit -o /dev/null: examples/tiger.eps
> base/fapi_ft.c

2017-02-26 05:23:39 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
a76a82abca879fcf351fce5aba50a48e7de41963

> Bug 697545: Memory Squeezing fix.
> Fix memory leak for allocation event number 10
> when memory squeezing:
> gs -sDEVICE=bit -o /dev/null: examples/tiger.eps
> psi/imainarg.c

2017-02-24 18:21:12 +0000
Robin Watts <robin.watts@artifex.com>
009e40a0534e1d11ed5ee353477859b5cdd4faed

> Bug 696921: Don't "early decode" when interpolating Lab images
> Applying the decode array to Lab source values during the
> conversion to fracs that takes place before non-icc based
> interpolation causes an overflow.
> We therefore leave the application of the decode array until
> after the interpolation.
> After the interpolation, we don't actually want to apply the
> decode array though - in that we want the result in the usual
> 0...1 float form rather than the 0..100/-128..127/-128...127
> ranges that the color would seem to require.
> One option would be simply to not apply the decode array. This
> will however go wrong when we meet an Lab file with a
> non-standard Decode array. We therefore apply the given decode
> array (which may well be the default), and 'undo' the default
> one to get the values we actually want.
> base/gxiscale.c

2017-02-24 19:05:52 +0000
Robin Watts <robin.watts@artifex.com>
af3c1d10726b2d932d951bf021193cbd5bcc734d

> Bug 697048: Fix compatible overprint blend mode.
> Fix from Michael Vrhel.
> Compatible overprint is operating in subtractive color spaces, so
> a 'zero' component actually means 0xFF.
> base/gxblend.c

2017-02-24 18:40:03 +0000
Robin Watts <robin.watts@artifex.com>
9e38426abd977fbc67c0d91103eb7bd3573409bb

> Update clusterpush.pl
> Allow "extended", "cull" and "win32".
> toolbin/localcluster/clusterpush.pl

2017-02-23 15:20:35 +0000
Robin Watts <robin.watts@artifex.com>
1aebfe56c80bb46bba74c23654d9febcf5f761b5

> Correct assert in new scan converter
> base/gxscanc.c

2017-02-24 09:33:05 -0800
Ray Johnston <ray.johnston@artifex.com>
13686f5374600d41105587c20a15f3c1e55f3534

> Return Fatal errors from PS putdeviceparams to avoid potential SEGV
> The change to return Fatal from the display device (commit 269354e)
> would segfault with the PS interpreter because zputdeviceparams never
> returned an error code, assuming that the interpreter could handle it,
> but this resulted in a segfault when setpagedevice tried to erase the
> page and the display device did not have a valid bitmap. Return the
> Fatal error so the interpreter can exit cleanly.without performing
> the usual setpagedevice "configurationerror" recovery.
> psi/zdevice.c

2017-02-24 16:10:11 +0000
Ken Sharp <ken.sharp@artifex.com>
dabad3f6e9c2bdbd152f67a66b698262f94b816d

> PDF interpreter - remove some (ancient) debug code
> This line seems to have been left in accidentally a long, long, time
> ago. Surprisingly its never been noticed before....
> Resource/Init/pdf_base.ps

2017-02-24 15:50:21 +0000
Ken Sharp <ken.sharp@artifex.com>
269354ea918e4498df67e52a1efd16295e031421

> Fix display device for non-PostScript interpreters
> commit cf279b8c4773e14045dd6b411c3a524c6ac39124 fixed a potential
> crash when memory was exhausted, but used the gs_abort() routine to
> tell the interpreter to abort immediately and not carry on.
> Unfortunately, and despite the comment in gsexit.h, gs_abort() is only
> available in the PostScript interpreter.
> So here we opt to return a fatal error, which *should* cause the
> interpreter to give up (it does on PCL and PostScript) and will allow
> us to build GhostPCL on Windows.
> devices/gdevdsp.c

2017-02-24 10:12:43 +0000
Chris Liddell <chris.liddell@artifex.com>
0e9a345e7badf0d53ab19761a938665079883612

> Bug 694995: Fix 'wrapped' x11 devices' buffered 'mode'
> The x11 devices can either unbuffered (where rendered objects go straight to the
> screen) or buffered (where objects are rendered to a memory buffer device, and
> then blitted to the screen).
> Additionally, the 'real' x11 device always uses the resolution and color specs
> of the X11 server on which it is running. Then devices such as x11mono and
> x11cmyk using a "wrapper" device in order to keep the x11 device using the
> specs of the X11 server, whilst presenting an appropriate character to the rest
> of Ghostscript (so, even though x11 is *probably* running 24bit RBG, x11mono
> needs to look like a pure monochrome device).
> Because we need the 'real' x11 device to handle get_params/put_params, and we
> need to temporarily 'patch' the color info of the 'real' x11 device so it
> retrieves/applies the params correctly.
> The problem arises when we run one of these 'wrapper' devices in buffered mode.
> The memory buffer device (particularly after a resizing of the page buffer),
> would end up being configured based on the color settings of the 'wrapper'
> device, rather than the 'wrapped' device. So we could end up treating a 1bpp
> mono bitmap (from the memory buffer device) as a 24bpp RGB pixmap and blitting
> to the screen. Causing a buffer overflow, and segfault.
> To solve that, store the color info we need away from its place in a
> standard device, and use the x11 device's own dedicated copy for setting up
> the memory buffer device.
> devices/gdevx.c
> devices/gdevx.h
> devices/gdevxalt.c
> devices/gdevxini.c

2017-02-22 07:17:54 -0800
Ray Johnston <ray.johnston@artifex.com>
670c6b29ebbd29fb3238575cb08a6c2c9586ace7

> Add support for RGB_TAG PAM files to lib/viewpbm.ps (type from bitrgbtags)
> The bitrgbtags device was changed recently to create a PAM (P7) file rather
> than a bogus P6 file with 4 components. This means that the pcl/tools/GOT
> detag.c and tagimage.c no longer worked. Instead of changing these the
> lib/viewpbm.ps was enhanced to process the RGB_TAG P7 files.
> By default, it shows the image, and with -dTAG it shows pseudo-color for
> the tag values, UNKNOWN/UNMARKED is white, TEXT is black, PATH is yellow
> and IMAGE is red.
> example usage:
> gs -dSCALE=1 -- lib/viewpbm.ps bitrgbags.pam
> or
> gs -dSCALE=1 -dTAG -- lib/viewpbm.ps bitrgbags.pam
> This can also be used to convert the P7 image to another format using
> -sDEVICE=___ -o ___ arguments prior to the -- option.
> Also, fix numerous problems with FITPAGE and SCALE options. They were
> just WRONG!
> lib/viewpbm.ps
> pcl/tools/GOT/README
> pcl/tools/GOT/detag.c
> pcl/tools/GOT/dotags.sh
> pcl/tools/GOT/tagimage.c

2017-02-22 17:51:17 -0800
Ray Johnston <ray.johnston@artifex.com>
862b31689c3f1c6425f5522adc820b73e352e012

> Improve bitrgbtags device so that unmarked areas are preserved.
> Similar to pngalpha, the bitrgbtags device needs to have a fillpage
> procedure to fill the page to "GS_UNTOUCHED_TAG" | white (0xffffff)
> Without this, the page was entirely set to "PATH" by the default
> fillpage.
> Note this will change EVERY bitrgbtags output in the regression results.
> devices/gdevbit.c

2017-02-23 13:04:11 +0000
Chris Liddell <chris.liddell@artifex.com>
b0d12644776ab1517e549903ba3262c082759680

> Bug 697607: correctly bounds check glyph index in TTFs
> The update to Freetype removed a bounds check in the Freetype code when the
> incremental API is in use (leaving it up to the caller to validate the glyph
> index). This adds that bounds check to our glyph data callback.
> As part of that, return the trueNumGlyphs and numGlyphs varaibles in the
> Ghostscript type 42 font structure to their (apparent) original intent:
> trueNumGlyphs is the value read from the maxp table, whilst numGlyphs is a value
> derived from the size of the loca table (see the bug for a fuller explanation).
> base/gstype42.c
> psi/zfapi.c

2017-02-23 11:30:22 +0000
Robin Watts <Robin.Watts@artifex.com>
4e646ef8103f3ab2ab9d7de64bd30cc2156f0441

> Bug 696915: Fix buffer overread in mapped8_copy01.
> If the stars align, we can overread by 1 source byte
> in mapped8_copy01. Simple fix.
> base/gdevm8.c

2017-02-22 17:24:24 -0800
Ray Johnston <ray.johnston@artifex.com>
cf279b8c4773e14045dd6b411c3a524c6ac39124

> Fix SEGV is display device when PageSize needs bitmap > 2Gb
> The display_put_params is supposed to revert to the original settings
> if an error is encountered, but since it frees the display bitmap before
> attempting to allocate the new one, if that allocation fails, the device
> is left with a memory device that has an invald bitmap pointer.
> Instead revert the settings and attempt to allocate a bitmap with those
> settings. If that fails (unlikely) then gs_abort with an error message.
> NB: It is preferable to free one bitmap before allocating the new one
> in case we are near a system memory constraint.
> devices/gdevdsp.c

2017-02-22 23:54:38 +0000
Robin Watts <robin.watts@artifex.com>
340b7c7f79d45ed36cd247ff0c13586e6b6a4763

> Bug 696520: Avoid dereferencing NULL in epson devices.
> Adopt Peter Cherepanov's patch to avoid dereferencing NULL.
> Only calculate the pure color if we know we're going to need
> it - by which time we know it's safe to deference.
> contrib/eplaser/gdevescv.c

2017-02-20 16:32:51 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
4c99ddc1dbd610d9d677750d6b1dabcb1cda8fb0

> Bug 697545: Memory Squeezing fix.
> Fix memory leaks for allocation event number 8 and 9
> when memory squeezing:
> gs -sDEVICE=bit -o /dev/null: examples/tiger.eps
> psi/gs.c
> psi/iapi.c
> psi/imain.c

2017-02-22 16:41:33 +0000
Robin Watts <robin.watts@artifex.com>
21901b860ca033ed14168d3c191b39ff714946b5

> Bug 697602: Remove 2 instances of variable shadowing.
> Hard to believe these are right because setting code
> and then falling out of scope doesn't achieve much.
> base/gp_wxpsprn.cpp

2017-02-22 08:11:48 -0800
Michael Vrhel <michael.vrhel@artifex.com>
f8d299c399312fdd41958843a101db36353ad8e2

> Avoid getenv call in openjpeg
> getenv is not allowed in certain cases causing linking
> issues. This fix should be pushed to the openjpeg
> group. Thanks to Chris for the fix.
> openjpeg/src/lib/openjp2/j2k.c

2017-02-21 16:46:07 +0000
Chris Liddell <chris.liddell@artifex.com>
8e8831a02f172490d7b175e54c7d15814acacea4

> Update bytes_decoded for the non-cache code path.
> If a glyph is being rendered without going through the glyph cache, we still
> must update the 'bytes_decoded' entry in the text enumerator.
> base/gxchar.c

2017-02-20 10:16:32 +0000
Chris Liddell <chris.liddell@artifex.com>
948d880467b2436813f7ffe5d1bd694c9475093c

> Bug 694269: valgrind issues in Type 1 charstring interpreter
> 1) Bounds check the charstring data so we don't run off the end of the buffer
> 2) Initialise various entries in the Type 1 hinter state: in a well formed
> font these will never be used without being set from the charstring, but in
> a broken font, they can be used without being set.
> 3) Initialise the (sacrificial) path we use when retrieving glyph metrics etc.
> 4) Initialise the contents of the stack
> base/gstype1.c
> base/gxhintn.c
> base/gxpath.c
> base/gxtype1.c
> base/gxtype1.h

2017-02-17 11:07:41 +0000
Chris Liddell <chris.liddell@artifex.com>
64c433d69b7732ae919a029dbf4b635133c97f03

> Bug 694250: bounds check in TTF hinting code
> Broken font tries to access *way* off the end of the opcode buffer. Check the
> index before using it
> base/ttinterp.c

2017-02-17 11:33:36 +0000
Chris Liddell <chris.liddell@artifex.com>
83b54c55a485a17124321d437e8207515396024a

> Bug 694268: init stack based data.
> devices/vector/gdevpdfd.c

2017-02-16 10:27:22 +0000
Chris Liddell <chris.liddell@artifex.com>
cf60a549d2413ae96b17010f0a69f82b797d33e3

> Fix low memory crash in native font enumeration.
> psi/zfontenum.c

2017-02-20 10:24:14 -0800
Ray Johnston <ray.johnston@artifex.com>
12091a85336f5c422545f03b4afcd1ea7362a10e

> Fix misspelled TUPLTYPE in PAM header for bitrgbtags output.
> Also add in DEPTH 4
> devices/gdevbit.c

2017-02-20 15:58:03 +0000
Robin Watts <robin.watts@artifex.com>
8e918ac9ca06971534c7e39087ecca05c3809ce7

> Update bmpcmp to cope with PAMs with RGB_TAG input.
> We treat these as CMYK PAMs for now. This should be enough for
> us to spot differences in the false color images produced.
> toolbin/bmpcmp.c

2017-02-20 15:48:47 +0000
Robin Watts <robin.watts@artifex.com>
f21824bbf5bd1c0ba8cb19855a8fbc5e0681ff74

> Update bitrgbtags device to use better header.
> The bit devices output raw data.
> The bittagsrgb device outputs rgb + a tag plane, with a PPM header.
> The PPM header tells code to expect 3 bytes of image data, not 4,
> so is wrong. Here we change it over to use a PAM header (of type
> RGB_TAG).
> This allows bmpcmp to be amended to cope better.
> devices/gdevbit.c

2017-02-20 09:45:18 +0000
Ken Sharp <ken.sharp@artifex.com>
ecceafe3abba2714ef9b432035fe0739d9b1a283

> Resolve image enumerator ownership on error
> Bug #697596 "Use-After-Free in i_free_object()"
> There is confusion over ownership of 'penum' between gx_begin_image1(),
> gx_begin_image4() and gx_image_enum_begin() which is called from these
> two functions (and only from these two functions).
> The enumerator is allocated in gx_begin_image?() and freed there if
> gx_image_enum_begin() returns an error. However, gx_image_enum_begin()
> also frees the enumerator on an error; except that it doesn't always do
> so. Its a large function and there are at least 9 ways to exit it, only
> 4 of which free the enumerator.
> This commit removes the 'free' instances from gx_image_enum_begin()
> leaving the cleanup as the responsibility of the calling code, which
> performed the allocation.
> base/gxipixel.c

2017-02-19 10:13:53 -0800
Ray Johnston <ray.johnston@artifex.com>
8452f9238959a4d518af365812bf031fe4d8d4b7

> Fix Coverity CID 141336 -- Indentation gripe.
> base/gdevprn.c

2017-02-06 19:21:43 -0800
Ray Johnston <ray.johnston@artifex.com>
eccf38345588ced6595d3414fca10098e9855da3

> Add -dDumpXML to toolbin/pdf_info.ps options and fix -dDumpFontsNeeded
> As an example of getting even more info from the PDF, add -dDumpXML to
> dump the PDF Metadata (if any).
> Also a problem found with -dDumpFontsNeeded=false was fixed.
> usage to dump the basic info and Metadata:
> gs -q -dDumpXML -dDumpMediaSizes=false -dDumpFontsNeeded=false -- \
> toolbin/pdf_info.ps examples/annots.pdf
> toolbin/pdf_info.ps

2017-02-18 17:57:18 -0700
Henry Stiles <henry.stiles@artifex.com>
e548d290d7d052a32e65493a703e1276230554c3

> Fix 697576: false colors with pxlcolor.
> PXL high level image processing does not support DeviceN, fall back to
> rendering rectangles.
> devices/vector/gdevpx.c

2017-02-18 08:50:48 -0700
Henry Stiles <henry.stiles@artifex.com>
cb5ec3dc7d0214ca3a784f9630b0775142c2ec08

> Fix bug #687561, bad parsing of intellifont data.
> The previous code read the metric offset field at the wrong positon (8
> vs. 6) resulting in a value that caused a range check error. Further,
> the range checking which checked the offsets were ordered is not
> useful or correct, and has been removed. There is nothing in the
> documentation to indicate the offsets must be ordered and showing
> order does not help in preventing out of bounds access.
> pcl/pcl/pcsfont.c

2017-02-16 21:47:47 -0800
Ray Johnston <ray.johnston@artifex.com>
c139c069968a59bc53e45d8373dd70d30278d152

> Change -Za output to omit the (mostly useless) opening/closing clump messages
> The -ZA is noisier so, keep these messages for that debug level (for now).
> I've worked with Ghostscript allocators for MANY years and have yet to
> find these messages useful. This is a precursor to totally deleting these
> messages.
> base/gsalloc.c

2017-02-16 16:37:28 -0800
Ray Johnston <ray.johnston@artifex.com>
88201849f123642dac3920a0bad5e68290280798

> Fix incorrect calculation of pdf14 number of components.
> This was seen with DeviceN devices (psdcmyk, tiffsep, ...) with the file:
> tests_private/comparefiles/Altona_Technical_v20_x4.pdf resulting in
> Error messages and warnings that "Output may be incorrect". With the
> -dPDFSTOPONERROR option, an reangecheck error is reported.
> base/gdevp14.c

2017-02-16 07:56:26 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
7bb2ad6cce75aae3ebedaa5883e1ecd6ba19b52d

> Bug 697545: Memory Squeezing fix.
> Fix for 'red 85546'. This is a SEGV seen at allocation event
> 85546 when memory squeezing:
> gs -sDEVICE=bit -o /dev/null: examples/tiger.eps
> Also account for all the other places that allocate a new
> colorspace without checking the returned value.
> base/gsgstate.c
> base/gsicc_manage.c
> base/gsimage.c
> base/gsptype1.c
> base/gstrans.c
> base/gxclrast.c
> devices/vector/gdevpdfb.c
> devices/vector/gdevpdfc.c
> devices/vector/gdevpdfi.c
> devices/vector/gdevpsdi.c

2017-01-29 11:14:39 -0800
Ray Johnston <ray.johnston@artifex.com>
40a82d9e72340b8547f0d45709693e456465ccfd

> Fix Bug 697502, problems with NumRenderingThreads exceeding available RAM
> The logic that determined the amount of printer buffer space, and allocated it
> was including the ESTIMATED pdf14 transparency buffer space, but we only need
> to make sure that amount of space is available, not actually allocate it (since
> then it wouldn't be availble when needed).
> if there wasn't enough memory for the band buffer when a thread's clist reader
> was opened, gdev_prn_setup_as_command_list would try reducing the BufferSpace
> (by successive dividing by 2) until it could fit. This would result in a
> reader band size that did not match what was used to write the clist. This
> so we force the BandBufferSpace to be exactly the same as was used in the writer
> using the cdev page_info.band_params. The tile_cache_size was added to the
> space_params used to set up the thread clist device to make it match that used
> by the writer.
> In order to make sure we don't "over commit" in creating threads we reserve
> an extra amount per thread, currently 2 Mb plus the ht_cache size times the
> number of components, plus when the page uses transparency, we increase it by
> the ESTIMATED_PDF14_ROW_SPACE times the band_height. We further increase it by
> the size of the link profiles and the size of the icclink profiles (CURRENTLY
> ESTIMATED). We free the reserve area as we start threads.
> Also when an allocation for a thread failed, the 'band' used for next_band was
> being decremented but it did not need to be since it was already the correct value.
> This had caused a problem with threads getting started for the wrong band.
> Fix gx_ht_read_and_install to prevent double free if gx_gstate_dev_ht_install
> gets an error (VMerror).
> Fix gdevbit so that we don't keep going after get_bits returns an error.
> TODO: collect the size of the icclinks rather than a rather worst case value
> currently estimated.
> base/gdevprn.c
> base/gsht.c
> base/gsicc_manage.c
> base/gxclist.c
> base/gxclthrd.c
> base/gxdevcli.h
> base/gxdhtserial.c
> devices/gdevbit.c

2017-02-16 08:52:48 +0000
Ken Sharp <ken.sharp@artifex.com>
89371a73c6d97606ca61884b555b7c13ec1534ac

> Fix segfaults in low memory conditions
> Bug 697572 "Segfaults when ps2write runs out of memory"
> Add some return code checks in pdfwrite/ps2write, check a stream when
> trying to close an 'aside', add a check for error return codes when
> rendering a cached glyph bitmap.
> base/gxccache.c
> devices/vector/gdevpdfb.c
> devices/vector/gdevpdfi.c
> devices/vector/gdevpdfj.c
> devices/vector/gdevpdfo.c
> devices/vector/gdevpdti.c
> devices/vector/gdevpdtt.c

2017-02-11 04:30:56 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
4d2b25f06c25e6e3e2b1bf319481a7442d42af8a

> Bug 697531 : Tidy up unused code.
> The first patch for this bug made the error return from
> jbig2_word_stream_buf_get_next_word pointless so this
> patch removes all the remaining redundant code.
> jbig2_word_stream_buf_get_next_word does not need to return
> any value so this is now defined as a void type and the rest
> of the code has been updated accordingly.
> jbig2dec/jbig2.c
> jbig2dec/jbig2_arith.c
> jbig2dec/jbig2_arith_iaid.c
> jbig2dec/jbig2_arith_int.c
> jbig2dec/jbig2_generic.c
> jbig2dec/jbig2_huffman.c
> jbig2dec/jbig2_priv.h
> jbig2dec/jbig2_refinement.c

2017-02-15 06:13:55 -0800
Ray Johnston <ray.johnston@artifex.com>
1f8ada0d7e2c19138038bccd585e412b1f7a0267

> Fix ignored return code in pdf14 transparency.
> This fixes segfaults that pop up later. Found when testing multi-threaded
> rendering with (somewhat) constrained memory (-K256000) on the file:
> tests_private/pdf/sumatra/x_-_renders_slowly.pdf.ppmraw.300.0
> base/gdevp14.c

2017-02-15 14:59:27 +0000
Ken Sharp <ken.sharp@artifex.com>
460ef0691145c8c81e238f61baa5009c29838304

> pdfwrite - improve commit ad3e0de3e3ca33f00c81c071560bf6c9f4d5a0f0
> Use gs_note_error instead of simply returning an error, and don't
> bother checking pdfont, since we check for NULL immediately above.
> devices/vector/gdevpdtt.c

2017-02-14 16:47:59 +0000
Chris Liddell <chris.liddell@artifex.com>
120f8533b705142ef83b899736e41e5739df5fc2

> Tweak the string that controls the greeting message
> For GPL releases we print a greeting message on execution that states the
> software is supplied without warranty.
> So, we should check for it being the GPL release before printing it.
> Resource/Init/gs_init.ps

2017-02-15 10:01:39 +0000
Ken Sharp <ken.sharp@artifex.com>
ad3e0de3e3ca33f00c81c071560bf6c9f4d5a0f0

> pdfwrite - don't seg fault for Line Printer font and UFST
> Using the PCL Line Printer Font, when built to use UFST, can't be
> handled with pdfwrite currently. In fact, using UFST with pdfwrite
> results in garbage output anyway.
> However, we should not seg fault. So here we check to see if we have a
> PDF Font resource associated with a native font, and if we don't have
> one when we need it, we give up and signal an invalidfont error.
> devices/vector/gdevpdtt.c

2017-02-14 11:50:34 +0000
Robin Watts <robin.watts@artifex.com>
836e9a34c17b8bc2fdb4376f572982dfe1412ae0

> Make frac31s hold values in the defined range in all cases.
> frac31s are supposed to hold values where 0x7ff..... represents 1.
> The code, however, currently converts to and from devn values using
> 0x00007ff8 as 1.
> Either we need to update the docs, or we need to fix the code to be
> consistent. This is an attempt at the latter.
> base/gdevdsha.c
> base/gscicach.c
> base/gxcvalue.h
> base/gxfrac.h
> base/gxshade6.c

2017-02-14 15:37:43 +0000
Ken Sharp <ken.sharp@artifex.com>
b969fb501f59d807d54fcfc186b7b97b55cebe0f

> XPS interpreter - fix some Coverity warnings
> Check a few values read from TT tables to satisfy Coverity 'tainted
> scalar' errors.
> May need some additional changes, but I can't see any way to validate
> the unsigned 32 bit values.
> xps/xpsfont.c

2017-02-14 12:48:10 +0000
Chris Liddell <chris.liddell@artifex.com>
7273aa3cd04e0acb212e335ab6b3f360cbd727c9

> Fix SAFER issue with filenameforall
> With the change to ensure we only apply SAFER permissions to real file system
> operations (so only on '%os%' and not on other PS '%<device>%' devices), the
> way filenameforall called the permission checking function meant it did not
> work correctly.
> Basically, check_file_permissions() and co must have a valid iodev parameter
> passed to them to function correctly.
> So, fix that call.
> psi/zfile.c

2017-02-14 10:22:46 +0000
Chris Liddell <chris.liddell@artifex.com>
b3acfdeaf1eb63a07e8169ea4c30ace7522054bc

> Yet more SAFER problems with .libfile
> With the change to ensure we only apply SAFER permissions to real file system
> operations (so only on '%os%' and not on other PS '%<device>%' devices), the
> .libfile call was dropping through without being restricted.
> This changes the .libfile code to call the permissions checking function
> properly.
> psi/zfile.c

2017-02-14 09:37:55 +0000
Chris Liddell <chris.liddell@artifex.com>
3d14e0b20dfdc05cda60f7a9a4c78e9d3ee206e2

> Split out $(MAKE) from recursive make calls
> Commit 8acec58309 consolidate the common parts of the various recursive make
> calls. Turns out, this breaks parallel make, as it defeats the make
> algorithm which spots a make command line. As a result, none of those recursive
> make calls would do parallel builds.
> So, this time, we keep the options consolidated into a make variable, but put
> back the $(MAKE) call explicitly for each recursive call
> base/unix-end.mak

2017-02-13 16:02:54 +0000
Chris Liddell <chris.liddell@artifex.com>
e36d3979ebcaa1ce28f7c58e7e1c7a5959816eb8

> Fix Windows UFST build.
> psi/msvc.mak
> windows/ghostscript-ufst.vcproj

2017-02-09 20:32:56 +0000
Chris Liddell <chris.liddell@artifex.com>
c7d5567fbc5f98488761ab93eaed60f1ac26023e

> Bug 697484: fix mkromfs memory leak
> In commit aa28186288 we missed the need to free some of the memory used during
> the file name sorting phase.
> base/mkromfs.c

2017-02-09 15:54:42 +0000
Chris Liddell <chris.liddell@artifex.com>
e476d710841d8be4d4e56c2b9e468e914f977161

> ramfs: fix modes other than (r) and (w)
> The (a), (r+) and (w+) modes were not working correctly. The "core" code of the
> ramfs was correct, but the "glue" code between the Ghostscript stream API
> and the ramfs core was not setting flags to support those.
> Conversely, the ramfs "glue" code was not setting the permissions flags
> correctly in the stream objects it created, when using the "+" modes.
> Also, (w) and (w+) were not truncating the file on opening.
> Finally, tweak the definition of the various read/write/etc flags for the
> ramfs code so the values match those used in the stream API (this makes fixing
> the flags in the stream objects much simpler).
> base/gsioram.c
> base/lib.mak
> base/ramfs.h

2017-02-07 15:44:52 +0000
Chris Liddell <chris.liddell@artifex.com>
42fd2f459098bfda17ca8d29195ada57154cfe06

> Change how we check for artibrary file accesses
> When we apply the SAFER restrictions, we have to *not* apply the rules
> for Postscript devices (such as %rom%, %calendar% etc), we only want to apply
> the restrictions to the "real" file system (%os%).
> Previously the code was checking if the iodev's "open_file" method was set to
> the one for the %os% device, but that is actually not set (it is intentionally
> NULL), so here we check the i/o device instance to ensure it is not the
> i/o device instance for %os%
> psi/zfile.c

2017-02-01 12:46:57 +0000
Chris Liddell <chris.liddell@artifex.com>
dd3c9ba2839ada5162aaccfeb442a958bfea637c

> Build exes from static lib builds.
> Add targets to build executables linked to the static library builds, meaning we
> can actually test the static libs we create.
> base/unix-end.mak
> base/unixlink.mak

2017-01-12 20:55:11 +0100
Stefan Brüns <stefan.bruens@rwth-aachen.de>
aa2818628843205283c563865cd56b4091f2e37f

> Bug 697484: mkromfs: sort gp_enumerate_files output....
> for deterministic ROM contents
> gp_enumerate_files_next returns dir entries in the same order as returned
> by readdir. Sort by name to generate deterministic output.
> base/mkromfs.c

2017-01-12 18:04:57 +0100
Stefan BrÃ¼ns <stefan.bruens@rwth-aachen.de>
98696f718b5c0f9a5fd9c33d61f81da469b9a4e1

> Bug 697484: mkromfs: make build reproducible.....
> use buildtime from SOURCE_DATE_EPOCH
> The environment variable SOURCE_DATE_EPOCH is the common approach for
> getting reproducible timestamps and thus builds. In case the variable
> is not set, keep using the current time of the mkromfs run.
> Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
> base/mkromfs.c

2017-02-07 22:15:58 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
4c7b41dff7d57be0e13de15c45b0296602e63472

> Bug 697531 : Fix decoder error on JBIG2 compressed image.
> The problem is in jbig2_word_stream_buf_get_next_word
> returning -1 and sending a fail error causing the whole
> file to fail.
> Now when the buffer is exhausted, the returned value is set
> to zero so that the decoder does not try to use an
> unintialised value.
> This now means the error return is pointless and another
> commit will follow this one to tidy up the unused code.
> jbig2dec/jbig2.c

2017-02-08 10:46:58 -0800
Ray Johnston <ray.johnston@artifex.com>
7ca4d2cc269effd69273112ec7ad9d40076abbc1

> Increase PDF 1.4 transparency ESTIMATED_ROW_SPACE
> Testing showed that the ESTIMATED_PDF14_ROW_SPACE was too optimistic, so
> increase NUM_PDF14_BUFFERS to 4 and use the target num_components (primarily
> for spot color devices such as tiffsep) to try and make this more robust.
> Still a guess, but works better as tested with multi-threaded rendering.
> Note, the band height chosen based on the BufferSpace will be different
> when the page has transparency, so there are differences. I have reviewed
> them and they are all 1 pixel differences or invisible color differences.
> base/gstrans.h

2017-02-08 14:49:35 +0000
Robin Watts <robin.watts@artifex.com>
9284128b1a16c21a95570f4c79258590839a10c7

> Further fixes to ramfs.
> All allocations are made using fs->memory, so all frees should be
> done with it too. This wasn't caught by memory squeezing (or other
> tests), because we don't actually use the ramdisc.
> base/ramfs.c

2017-02-07 20:28:28 -0800
Ray Johnston <ray.johnston@artifex.com>
cffb5712bc10c2c2f46adf311fc74aaae74cb784

> Commit a9a58bb95 was incorrect, clearing some values that it shouldn't
> The penum->rect values were cleared, and this didn't cover all uses of
> gx_image_enum_alloc. Also, return *ppenum NULL if alloc fails in case the
> caller doesn't check the return code. Also, if we fail the enum_begin,
> free the enum and set *pinfo to NULL.
> base/gximage1.c
> base/gximage4.c
> base/gxipixel.c

2017-02-07 19:32:08 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
a1b951c274a1d48340cfbaddb1308c92836dbc61

> Bug 697545: Memory Squeezing fix.
> Fix for 'red 242'. This is a SEGV seen at allocation event
> 242 when memory squeezing:
> gs -sDEVICE=bit -o /dev/null: examples/tiger.eps
> base/ramfs.c

2017-02-07 19:52:51 +0000
Ken Sharp <ken.sharp@artifex.com>
6084cc0a0cb1cd6e0d5b9be044622c74a16a0573

> XPS interpreter - add a reverse GID lookup for the benefit of pdfwrite
> Bug #697304 "Encoding gets lost when generating PDF"
> Prior to this commit the XPS interpreter, like the PCL interpreter, did
> not really return a character code when asked for an equivalent for a
> GID. Instead it returned the 'last' character code.
> For strings with multiple characters processed at once, this meant that
> all the characters in the string were assigned the same 'code' as the
> last character in the string. Also there was no reason to assume that
> code was even a Unicode value.
> This commit adds code to reverse the TrueType CMAP subtable lookup;
> given a GID it will return a character code. We then use the resulting
> character code in pdfwrite (which is the only device to use this method)
> to build a ToUnicode CMap in the output PDF file.
> There are a number of caveats with this commit;
> I've only been able to create XPS files with fonts containing format 4
> CMAP subtables. While I've coded the others (but not 2 or 8 because the
> normal character code -> GID mapping doesn't support them either) I
> have no way to actually test whether they work
> I'm not certain whether its possible to get an XPS file containing a
> font which does not have a 3,1 CMAP. Again I've not been able to create
> such a file, if we ever encounter one this code will likely not work
> properly.
> I have tested Latin and Far Eastern scripts, and files which use more
> than 256 glyphs from a single font. All of these appear to work as
> expected. When more than 256 glyphs are used from the same font, we
> create a PDF file with multiple simple subsets of the font, each with
> less than 256 glyphs. Each subset has its own ToUnicode CMap and so
> cut&paste works as expected.
> No differences expected, we cannot cluster test this code.
> xps/ghostxps.h
> xps/xpsfont.c
> xps/xpsttf.c

2017-02-07 09:42:43 -0800
Ray Johnston <ray.johnston@artifex.com>
a9a58bb95e4a41014f42cae9393767b26da3aa80

> Fix dangling pointer in gx_image_enum after malloc fail.
> Yet another, probably a squeezing failure since it failed with:
> -K30000 -dMaxBitmap=0 -r300 -sDEVICE=pkmraw -o nul: tests/pdf/cmyk_blend.pdf
> base/gximage1.c

2017-02-06 19:20:40 +0000
Robin Watts <robin.watts@artifex.com>
a65893f973c65d2ba22f8b2a2c6cf0822fc8c1da

> Bug 697555: Fix UTF-8 handling of args.
> The logic for checking for continuation bytes in UTF-8 was
> broken. Continuation bytes have the top bit set, but not the top 2
> bits set.
> This leaves the issue of @files on windows always being taken
> as UTF-8.
> base/gsargs.c

2017-02-01 16:31:03 +0000
Chris Liddell <chris.liddell@artifex.com>
c1834eb0cf024cf51231a19b975d97f33c559e0c

> Fix Luratech Linux build use if "inline"
> Compilers don't seem to like "inline" being used without "static", so tweak the
> build flags for Luratech so that doesn't happen.
> configure.ac

2017-02-06 12:31:12 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
aaf0b87aa5e0c41a32a290c836a5b3811433c561

> Fix memory leak in psi/imain.c
> Remove unused "paths" allocation.
> psi/imain.c

2017-02-06 09:49:45 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
e4439a505ed3ac582d7f65260678bc9dca03ce54

> Bug 697545: Memory Squeezing fix.
> Fix for 'red 62'. This is a SEGV seen at allocation event
> 62 when memory squeezing:
> gs -sDEVICE=bit -o /dev/null: examples/tiger.eps
> Also, improve the macro for FREE in base/gxclmem.c
> base/gsmemory.h
> base/gxclmem.c

2016-11-27 16:38:26 +0000
Ken Sharp <ken.sharp@artifex.com>
2bf2b4cebe44b74229e086380c3c25110f37aed0

> pdfwrite - where possible, preserve annotations
> This allows us to preserve many (but not all) annotation from an
> input PDF file as annotations in the output PDF file. This only
> works with the pdfwrite device, the ps2write device does not
> write pdfmarks to the output.
> Certain kinds of annotations (eg Link annotations) cannot be
> preserved, because they require a page (or other object) destination
> which we can't easily know at the time we create the pdfmark.
> Widget annotations are not preserved as these only have relvance
> in AcroForms, and since we don't preserve AcroForms, its much
> better to render the Widgets, otherwise their appearance will
> be lost along with the AcroForm data.
> It is possible that this behaviour may not be desirable, and
> that there could be bugs in this code, so a new switch
> '-dPreserveAnnots' is defined for use with the pdfwrite device
> only. If set to false the old behaviour returns, and annotations
> will be rendered instead of preserved.
> There are a few differences with this code; a few progressions,
> a few 'differences' and one file where the Stamp annotation no
> longer renders. THis is because the Form for the Apperance is
> invliad (leaves junk on the stack) and attempts to work around
> this ran into al kinds of trouble. In the end I ran out of time
> and chose to accept the error, the form is incorrect after all.
> Resource/Init/pdf_draw.ps
> Resource/Init/pdf_main.ps
> base/gdevp14.c
> base/gsform1.h
> base/gxdevsop.h
> devices/vector/gdevpdfb.h
> devices/vector/gdevpdfi.c
> devices/vector/gdevpdfu.c
> devices/vector/gdevpdfx.h
> doc/VectorDevices.htm
> psi/zform.c
> psi/zpdfops.c

2017-02-04 08:36:05 +0000
Robin Watts <robin.watts@artifex.com>
678e660cd4efcbf155675539c13a584cdffb5258

> Fix memento builds.
> base/gsrefct.h
> base/lib.mak

2017-02-03 12:29:20 +0000
Robin Watts <robin.watts@artifex.com>
59d509244ddb6fe9719a6205bf5657268efcb6d6

> Add missing \n to error message.
> psi/interp.c

2017-02-03 02:53:02 -0800
Robin Watts <Robin.Watts@artifex.com>
1392f5d2e7fe73bce8ff56cef62e4205f8a53bfd

> Memory squeezing fixes (PCL)
> Harden PCL (and gslibctx etc) against memory failures
> during initialisation.
> base/gsicc_manage.c
> base/gslibctx.c
> base/gslibctx.h
> base/gsmalloc.c
> pcl/pl/plalloc.c
> pcl/pl/plmain.c

2017-02-03 02:48:52 -0800
Robin Watts <Robin.Watts@artifex.com>
92ecd60a5218eb5bd1ba5e497e5fd2550112b5ed

> Destructors should cope with being called with NULL.
> Tweak pl level so that neat error closedown is easier.
> pcl/pl/pltop.c

2017-02-02 20:12:33 +0000
Robin Watts <robin.watts@artifex.com>
dd6fdc6dd668776d7b9570dd07e1e1790fcba8fb

> Fix Memento builds.
> Some headers were sometimes being used with memento.h having
> been included, and sometimes not. This lead to differing
> redefinitions of 'free'.
> base/gsfunc.h
> base/lib.mak
> base/ttfoutl.h

2017-01-27 16:32:07 +0000
Robin Watts <robin.watts@artifex.com>
9060c91ef75d7d36cfc1fd975e3368415df69b3a

> New scan converter fix.
> Don't convert ex and ey from endpoints to distance until *after*
> we have finished using it as an endpoint.
> base/gxscanc.c

2017-02-02 04:07:47 -0800
Robin Watts <Robin.Watts@artifex.com>
d8af3708a4907e98b5db54860d379702355dc077

> Tweak gs to enable fast Memento memory squeezing.
> Memento can memory squeeze in 2 modes; firstly it can repeatedly
> run the same job again and again failing at subsequent points.
> This has the advantage of being simple, but it has the problem
> of being slow, in that processing is repeated again and again.
> A faster mode is available where we run to the point of failure,
> then fork. The child proceeds to fail, and once failed, the
> parent then continues for 1 more allocation then repeats the
> process. Thus the only repeated work is in the failure cases.
> The downside to this is that fork copes very badly with
> multi-threaded programs. Firstly, it only duplicates the current
> thread - this means that we can only use it with single
> threaded programs. Secondly, even with single threaded programs
> the forked child goes wrong if you try to use mutexes etc.
> This means that in order to use GS with the fast memento memory
> squeezer, we need to ensure we don't create mutexes etc. We
> do this by adding a MEMENTO_SQUEEZE_BUILD define to gs.
> base/gp_psync.c
> base/gsicc_cache.c
> base/gsicc_lcms2.c
> base/gsicc_manage.c
> base/gsmalloc.c
> base/sjpx_openjpeg.c

2017-02-02 03:34:22 -0800
Robin Watts <Robin.Watts@artifex.com>
8cca94c736bb4babc676bd2ce49176d93058b8b3

> Memento memory squeezing tweaks.
> Add Memento_bt() - a function to output the backtrace
> to stderr.
> Call this when we fork for a memory squeeze.
> Forking only clones the active thread, so we can only use
> the forking memory squeezer on single threaded tasks. Even
> with single threaded tasks, you can't unlock mutexes in
> the child that were taken in the parent. This means that
> we need to disable mutexes in the main application if we
> want to memory squeeze safely.
> Also tweak the time we spend sleeping while waiting for a child
> to die. This makes a huge difference to the runtime.
> If we die during squeezing due to a SEGV, then don't bother
> listing the blocks that we leaked.
> base/memento.c
> base/memento.h

2017-02-01 19:46:29 -0800
Ray Johnston <ray.johnston@artifex.com>
de2314431f400a439cb2bcebb1152fc206b8804d

> Fix ignored return code for ICC profile device parameters.
> All of the uses of gx_default_put_icc_colorants and gx_default_put_icc
> ignored the return code which might be VMerror. Found when testing with
> multi-threaded rendering and low memory conditions.
> base/gsdparam.c

2017-02-01 08:40:01 -0800
Robin Watts <Robin.Watts@artifex.com>
cead170cb9e8dc25e59e3c8d7d8616d8b2f7119a

> Memento: Improve memory squeezing.
> It seems that Memory squeezing can sometimes run into
> problems with the child hanging after a fork. This seems
> to be related to the child process SEGVing and the
> signal handler not picking it up.
> I've introduced a workaround so that the parent now only
> waits a maximum of 30 seconds before killing the child and
> continuing.
> base/memento.c

2017-01-25 21:42:53 -0800
Michael Vrhel <michael.vrhel@artifex.com>
3a9d6ebe560689930eaf3aca00652b22cef26423

> Bug 626295 Text Knockout Transparency
> When we have transparency, text knockout set,
> with either a non-normal blend mode or an
> opacity less than 1.0, we need to push a
> non-isolated knockout group. Graphic state
> changes can occur between the BT and ET commands.
> As such, we will need to handling the push
> operation in pdf14_text_begin (and the clist version)
> when the conditions are right. This is a special
> group that indicates its uniqueness with a text_group
> flag. This flag is included through the clist, the
> group as well as the device. Once set, subsequent
> calls to pdf14_text_begin will not push another group.
> The group is popped with ET is encountered through the
> zendtransparencytextgroup command from the interpreter.
> If the pdf14 device is not currently in a text group,
> this group pop is ignored (and not even placed in
> the clist). The pdfwrite compositor logic, ignores
> and group pushes that occur with the text_group set
> as well as all PDF14_END_TRANS_TEXT_GROUP types.
> Due to confusion of with the annotation text writing
> methods, I had to add a PDF14_BEGIN_TRANS_TEXT_GROUP
> to denote when we encounter a BT in the source file
> to ensure that we are only going to push groups if
> our conditions are right and we are in a BT/ET pair and
> not drawing a text annotation.
> One optimization we may want to look at doing later, is
> determining the bbox for the area between BT and ET.
> Currently the group push is the same size as the parent
> group which is likely much to large.
> Resource/Init/pdf_ops.ps
> base/gdevp14.c
> base/gdevp14.h
> base/gstparam.h
> base/gstrans.c
> base/gstrans.h
> devices/vector/gdevpdft.c
> psi/ztrans.c

2017-01-31 19:05:05 +0000
Chris Liddell <chris.liddell@artifex.com>
04c75cebae5912610526c997604f8d15fb933682

> Fix a typo/thinko in the static lib build changes.
> I'd mistakenly used $(TOP_OBJ) instead of $(XPS_TOP_OBJS) for the XPS
> static library.
> base/unixlink.mak

2017-01-31 15:04:55 +0000
Chris Liddell <chris.liddell@artifex.com>
ba07b2df0ea519b1a6e9fcdfe6f7a25be92264fa

> Fix Windows build
> In adding/tidying the Unix-like static library targets, I forgot to tweak the
> VS nmake Makefiles to cope with the revisions. Done here.
> psi/msvc.mak

2017-01-31 10:05:11 +0000
Chris Liddell <chris.liddell@artifex.com>
8acec5830978b1199b3cda4eae3064deb4d91818

> Consolidate recurive make calls
> We have various classes of target (e.g. debug, profile etc) that rely on
> recursively calling make with specific sets of options per class.
> Put the make call and the options into a macro for each class
> base/unix-end.mak

2017-01-31 09:12:34 +0000
Chris Liddell <chris.liddell@artifex.com>
d9e40fcbf0a213e6717e1ab3bd234f5b20ca1270

> Add debug static lib targets.
> For neatness, I've moved the "visible" targets to unix-end.mak with the other
> Unix-like targets.
> And then added the recursive make calls to build debug versions.
> base/unix-end.mak
> base/unixlink.mak

2017-01-31 08:57:30 +0000
Chris Liddell <chris.liddell@artifex.com>
7718fe48373ff62f140d33080af9f49fc21b9f39

> Tidy/Add static lib target(s).
> Tidy up the libgs target for the gs static library on Unix-like systems (since
> we're now using it).
> Rejig the PCL, XPS and PDL executable builds to a) more closely match the gs
> one, and b) facilitate static library targets for those, too.
> Add the static library targets for the PCL/XPS/PDL builds (libgpcl6, libgxps
> and libgpdl respectively).
> base/gs.mak
> base/unixlink.mak
> gpdl/gpdl.mak

2017-01-30 15:05:36 -0800
Michael Vrhel <michael.vrhel@artifex.com>
94278ad478278567dbdfcb87137676ff73e86c22

> XPS Transparency check remote resource dictionary
> The XPS interpreter checks for the presence of transparency
> on the page. It was not checking remote resource dictionaries
> but rather was assuming that they always had transparency
> which resulted in an unneeded push of the pdf14 device when
> going to a raster output device.
> xps/xpsanalyze.c

2017-01-30 14:08:52 -0800
Michael Vrhel <michael.vrhel@artifex.com>
587d0a7edfd3519bd28981eb2703cfaaf11c747c

> Fix coverity issues 140991 and 140990
> Introduced from http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=91741e126688807cd086dad55158cd0cad63725a
> xps/xpszip.c

2017-01-27 12:17:00 -0800
Michael Vrhel <michael.vrhel@artifex.com>
8cde4bc582904132bd8bb78e6c5da5ab2ebdb6ce

> XPS Transparency check
> The XPS interpreter code was not setting the device param to
> indicate if a page had transparency. As such, the fact that
> a page had transparency was not getting used in the decision
> to invoke or not invoke the command list.
> xps/ghostxps.h
> xps/xpspage.c

2017-01-30 07:25:59 -0800
Ray Johnston <ray.johnston@artifex.com>
827ab0227853b9ee5491ceb76b178757aa2ab733

> Fix a potential de-reference of a NULL pointer with -Zv
> base/gdevp14.c

2017-01-27 13:24:32 -0800
Michael Vrhel <michael.vrhel@artifex.com>
91741e126688807cd086dad55158cd0cad63725a

> xps: low memory null dereference
> If the allocation in xps_new_part fails, it returns
> a null object which is then getting dereferenced.
> xps/xpszip.c

2017-01-26 11:35:38 -0800
Ray Johnston <ray.johnston@artifex.com>
c27947491f9b4bc87b09bff0648e1816ebd2af19

> Segfault in low memory configurations
> Testing with -K values for bug 697504, I was able to reproduce some
> segfaults, but don't know if they relate to the one mentioned here and
> on bug 691170 (which was closed as fixed), but these need to get fixed
> in any case.
> These occured because the init2 had not completed, but the interp was
> being called to do more stuff than it could reasonably hope to do in
> this case. Testing with -K values from 15000 down to 100 by 100 now
> no longer segfaults.
> psi/imain.c

2017-01-26 18:09:06 +0000
Robin Watts <robin.watts@artifex.com>
0734126eafa7c9212341886626d15d90ccce400f

> Add XPS_INDIRECTED_FILE_ACCESS define
> If defined, then the xps interpreter looks to use user
> supplied xps_{fopen,ftell,fseek,getc,fread,fclose} functions
> rather than gp_fopen,ftell,fseek,getc,fread,fclose.
> xps/ghostxps.h
> xps/xpsjxr.c
> xps/xpszip.c

2017-01-25 14:41:17 +0000
Chris Liddell <chris.liddell@artifex.com>
68af8c3b1584d0b001c7bd96456caf7547a0229e

> Bug 697503: Check resource path, and GenericResourceDir...
> ...paths when searching for resources.
> This relates back to bug 694509.
> If GenericResourceDir is set as a relative path, relative to a non-standard
> GS_LIB search path, we have to prefix the resource path (Category/Key) with
> the GenericResourceDir for the search path machinery to find the resource
> file.
> *However*, if the GenericResourceDir is set in the normal way (automagically
> by the initialization), then just using the plan resource path is required.
> So, try both the plain 'Category/Key' path, and the
> 'GenericResourceDir/Category/Key' path.
> Resource/Init/gs_res.ps

2017-01-25 16:00:40 +0000
Robin Watts <Robin.Watts@artifex.com>
4d07b45685976bd38e5cec8062b3a61d2ada5575

> Hide more JPEG entries.
> base/gsjconf.h

2017-01-24 18:07:11 +0000
Robin Watts <Robin.Watts@artifex.com>
aeb0bfb6c99e1e1683a21f684c18c1363ccc16cb

> Add more jpeg symbols to be hidden.
> It seems these clash with the devboards software too.
> base/gsjconf.h

2017-01-20 17:02:39 +0000
Robin Watts <Robin.Watts@artifex.com>
c7d005ac1c92a6fee43554fffd9a6f38c0a6b962

> Add GS_NO_FILESYSTEM define for systems with no FS.
> Some systems (such as ThreadX), have std headers that
> define FILE, but do not actually have a real filing
> system implementation. As such, they don't support
> filing system enumeration.
> We therefore introduce a GS_NO_FILESYSTEM define that
> stubs out the code in these entrypoints.
> At some point we may split the contents out to a different
> platform, but this will probably require some careful
> thinking about other functions in these files to avoid
> duplication of code.
> base/gdevpipe.c
> base/gp_unifs.c
> base/gp_unix.c
> pcl/pl/pjparse.c

2017-01-19 18:49:01 +0000
Robin Watts <Robin.Watts@artifex.com>
9568153b12b80d477f3031b88631910082a55bc8

> Add option to hide jpeg entrypoints.
> If we define GS_HIDE_INTERNAL_JPEG on build, then a series of macros
> is used to rename internal JPEG entrypoints. This can prevent
> symbol clashes when linking with other libraries.
> There may well be more symbols to add here in future, but this
> seems to be enough to solve it for me now.
> base/gsjconf.h

2017-01-24 12:41:12 +0000
Robin Watts <Robin.Watts@artifex.com>
aafd60bddbb3d5cfc0d9fb726d0cf81c51805c4c

> Remove opj_clock.c from build.
> Only defines one function, that isn't used, and doesn't compile
> on all platforms.
> base/openjpeg.mak

2017-01-24 12:41:05 +0000
Robin Watts <Robin.Watts@artifex.com>
ea534adfd0a3deed4f2a70d47fc9d78c1911d928

> Fix icc34.h header to compile on ThreadX.
> Honour HAVE_STDINT_H predefine.
> Also, tweak the #ifdeffery to be more readable (IMHO).
> Less nesting and rightward creep, and a more straightforward
> base/icc34.h

2017-01-21 15:01:14 -0800
Ray Johnston <ray.johnston@artifex.com>
eead75f44a03517ad50702f3c65d8c5784b4bfbb

> Fizes for the ramfs (%ram% device) (Bug 226943)
> There were problems with the GC not tracing the s->file pointer from the
> stream (assumed to be an OS item) so change to using non_gc_memory. Also
> problems with writing buffers more that a single block (not advancing
> in the source buffer).
> The bytesavailable operator didn't work because there was a bogus file_limit
> in the stream, and s_ram_available was wrong.
> Change the "this" to "thisdirent" so that C++ debuggers (like VS) can
> show the structure contents correctly.
> The bug shows an example that can be used to run a PDF file from stdin
> without needing to write a file to disk.
> base/gsioram.c
> base/ramfs.c

2017-01-23 12:33:22 +0000
Robin Watts <robin.watts@artifex.com>
024e9bd9a07ff906e91f78594c9d547f5228b3c6

> Force some typedef enums to be 32 bits.
> Modern C's are allowed to shrink typedef enums so that they are
> only as large as required to cover all the values in the
> enumeration. This can mean that typedef enums can now be byte
> sized.
> This works very badly when we have an array of them, take the
> address and cast it to an int *. That int * is no longer
> appropriately aligned for some compilers. This happens in the
> get_param code.
> We therefore add a trailing 'large' enum value to force the
> enums to be large. This will break down if we ever have a platform
> where ints are larger than 32bits.
> base/gscms.h

2017-01-23 11:48:11 +0000
Robin Watts <robin.watts@artifex.com>
24cb576dd60e903466b2d78cc718b3dd4da19529

> MSVC: Add %ram% FS to VS project.
> windows/ghostscript.vcproj

2017-01-16 18:33:25 +0000
Robin Watts <Robin.Watts@artifex.com>
e6753115b8a4c72c5e526f2a0a3849391a255962

> Use consistent types in API and C implementation.
> base/gssprintf.c

2017-01-19 11:44:18 -0800
Michael Vrhel <michael.vrhel@artifex.com>
79d6e96a8db2956c8317fd8bdeb8d8db5fd0e212

> Bug 697489 xps transparency issue
> The xps interpreter was pushing transparency groups without
> pushing the pdf14 device. The problem was that the interpreter
> was not checking the glyphs in the resource dictionaries.
> I also optimized the code to stop checking for transparency
> once it finds transparency.
> xps/xpsanalyze.c
> xps/xpspage.c

2017-01-18 14:49:40 -0800
Michael Vrhel <michael.vrhel@artifex.com>
a9bd0b6d95b16d594983682ae387922507e70b98

> Bug 697489 bitrgbtags segv
> The clist compositor call was not returning the existing
> compositing device in certain cases causing an issue
> later in the code.
> base/gdevp14.c

2017-01-18 13:24:20 -0800
Michael Vrhel <michael.vrhel@artifex.com>
56879003723e608173cdc063a8f2da4172f29a95

> Bug 697488 segv in pattern code
> The transparency code was not updating the bit depth
> properly when we had a color space change in the presence
> of spot colors
> base/gdevp14.c

2017-01-18 09:43:24 -0800
Michael Vrhel <michael.vrhel@artifex.com>
b12adcc4c201e94e1f726c8fa6ad7eea8a5f4ca7

> Bug 697435 bitrgbtags device
> The bit depth in the device was not getting set correctly
> during a color space change in the transparency code when
> the target device includes tags.
> base/gdevp14.c

2017-01-18 14:18:29 +0000
Chris Liddell <chris.liddell@artifex.com>
b5abd7391d4d065e6b4d05c119d2dd243bda2f4d

> Bug 697482: handle cff with broken /Private data
> The problem in this case is that the offset into the cff data for the /Private
> dictionary definition is well beyond the end of the cff stream.
> Bounds check the offset, and if it's nonsense, treat it as a zero length
> /Private dictionary (in the hope that the font doesn't actually need it.
> NOTE: /Private *is* a required entry, so *using* the font may throw an error.
> psi/zfont2.c

2017-01-18 14:29:18 +0000
Chris Liddell <chris.liddell@artifex.com>
90d3fb2e75aea47501dceb298ccd4f4229d4a6f3

> Fix error check/return logic in the CFF parser
> psi/zfont2.c

2017-01-17 10:48:07 -0800
Michael Vrhel <michael.vrhel@artifex.com>
51c5aa09762602b5dd3982ff3b92e182f1637dd4

> Bug 697435 bittags device blending color space
> In the clist case, there was a mixup with the ICC profile
> during playback. This fixes that issue. While the small
> file in Bug 697433 works with this fix, the large file
> (regression3.pdf) still shows 2 issues. When the blending
> color space is -sBlendColorProfile=default_cmyk.icc at 300dpi
> we see a dropped band (likely some confusion about the
> pdf14/clist optimization). When we use no blending color
> space we end up with a segv in clist_playback_band
> base/gdevp14.c

2017-01-13 19:16:56 -0800
Michael Vrhel <michael.vrhel@artifex.com>
0dbfbb773e40d23de5052fc5641387dad5d79bae

> Code cleanup. Remove unused code in transparency code.
> base/gdevp14.c
> base/gscolorbuffer.c
> base/gscolorbuffer.h
> base/lib.mak
> windows/ghostscript.vcproj

2017-01-13 12:33:05 -0800
Michael Vrhel <michael.vrhel@artifex.com>
8aa6b2ae6b27912339548380b602b8e3e6d17db3

> Bug 697435 Tags device with Blending color space
> Allow the use of put_image when we specified a blending color space.
> base/gdevp14.c

2017-01-12 13:25:04 -0800
Ray Johnston <ray.johnston@artifex.com>
7d97633daa0679a688a85a8a8805c261bd828a7e

> Add bitrgbtags device to Windows default build.
> psi/msvc.mak

2017-01-12 13:16:58 -0800
Ray Johnston <ray.johnston@artifex.com>
3434578b240b1e4bc34a0ce108595653e0994a11

> Add basic support for CMYK PAM (P7) format files.
> This works for the files generated by Ghostscript and mupdf, so it
> is useful enough to add.
> lib/viewpbm.ps

2017-01-11 09:58:34 -0800
Ray Johnston <ray.johnston@artifex.com>
0130e9cc9f196b4bd2e107cd71826210a8274c9d

> Fix SEGV bug 697473 bitrgbtags device with transparency
> The SEGV was caused by setting tos->n_planes to the wrong value if we
> converted colors to a different number of color components. Also fix
> clearing of the tags if the backdrop was NULL (leave it set as it was
> by pdf14_buf_new to GS_UNKNOWN_TAG).
> Lastly, the pdf14_put_image wasn't setting up the buffer pointers for
> all of the planes (alpha and tag), so bit_put_image choked. This
> probably would have caused a problem with pngalpha.
> base/gdevp14.c

2017-01-11 10:08:42 +0000
Chris Liddell <chris.liddell@artifex.com>
e424a42d269a626db054fb76e481df011ec6f1d6

> pdfwrite: set the 'bytes_decoded' value in the text enum
> For CIDFont subsitutions (and spotting single byte space characters), we need
> to know how many bytes were read from the input string for the current glyph,
> hence we have the 'bytes_decoded' value. For one code path, pdfwrite was
> failing to set the value.
> devices/vector/gdevpdtc.c

2017-01-11 09:16:59 +0000
Chris Liddell <chris.liddell@artifex.com>
aedc5a96d855086711b8accd48bd014dd57b18fa

> Fix the profile (pg) build.
> base/unix-end.mak

2017-01-11 09:19:07 +0000
Ken Sharp <ken.sharp@artifex.com>
40869fa69cdb74126977e35c2028d4176d350cdb

> Improve CIDFont rearranged font handling slightly
> Noticed while investigating a customer problem. We do not handle
> rearranged fonts (because they are a hideous hack) but we do have code
> to at least process them. Unfortunately there's a typo in the code which
> causes it to throw an error if its ever executed.
> Fix the typo here.
> The fact that this has never come up indicates how often this mess is
> used; ie never.
> Resource/Init/gs_cmap.ps

2017-01-04 13:13:14 +0000
Chris Liddell <chris.liddell@artifex.com>
8360852efab5643d93cc3b040832075e199cd205

> Bug 697462: pdfwrite: avoid cached glyph use
> When pdfwrite is accumulating a Type 3 font, and we want to try to capture the
> CharProc (rather than falling back to a bitmap), we need to stop the core
> font code from using a previously cached glyph bitmap (for example, from an
> earlier stringwidth operation), so we're sure the CharProc gets executed.
> If we don't ensure the cache doesn't get used, we end up in an infinite loop,
> where pdfwrite repeatedly returns to the core to run the CharProc.
> devices/vector/gdevpdtt.c

2017-01-06 15:37:08 -0800
Michael Vrhel <michael.vrhel@artifex.com>
3f4e699c31368a08b0146ef62f5b196315bd700d

> Update color document with new GS logo
> doc/GS9_Color_Management.pdf

2017-01-06 09:59:29 -0800
Michael Vrhel <michael.vrhel@artifex.com>
434ae2a49e9b6026a3ae1eeceb0f32b78a894ee1

> Color code clean up.
> base/gdevp14.c
> base/gsicc_cache.c
> base/gsicc_manage.c
> base/gsicc_manage.h
> psi/zicc.c

2017-01-06 09:56:15 -0800
Michael Vrhel <michael.vrhel@artifex.com>
32765969861bee5773b5f1207dae2500fa1fd506

> Update color management documentation
> doc/GS9_Color_Management.pdf
> doc/GS9_Color_Management.tex

2017-01-05 15:21:22 +0000
Robin Watts <robin.watts@artifex.com>
2259f4c693d02a43c007cab6cb268fa4e6d6c542

> Tidy variable naming in iapi.{c,h}
> Use 'instance' consistently.
> psi/iapi.c
> psi/iapi.h

2017-01-03 14:37:26 +0000
Robin Watts <robin.watts@artifex.com>
2f45ea017e9691c2b817884746306d27e06e0199

> Windows gs: Avoid unininitialised read.
> pcl/pl/plwmainc.c
> psi/dpmain.c
> psi/dwmain.c
> psi/dwmainc.c
> psi/dxmain.c

2017-01-03 10:17:13 +0000
Robin Watts <robin.watts@artifex.com>
8071bb2950068a3c6a1b5a405d16548177503a14

> New scan converter: Fix some warnings.
> "ey is set and then never used" in some release builds.
> Rejig the code to avoid this.
> base/gxscanc.c

2017-01-02 18:27:50 +0000
Robin Watts <robin.watts@artifex.com>
06e756898579cd21dbff40ad30efff9571a549fe

> New scan converter: Fix problems in trap fills.
> I was calculating trapezium fills slightly wrong.
> Also, I was filling the 'centre of a pixel' cases edgebuffers
> with slightly incorrect values. Now the debugging shows that
> we are getting exactly what we want in the example files I
> have tried.
> This results in much smoother edges on some shapes.
> base/gxscanc.c

2017-01-02 18:25:08 +0000
Robin Watts <robin.watts@artifex.com>
fb1f10f6eaed79016dd924b2e5730160e9267fd3

> New scan converter: Improved debugging.
> Update the debugging output from the new scan converter to be
> more useful.
> base/gxscanc.c

2016-12-29 14:00:21 -0800
Michael Vrhel <michael.vrhel@artifex.com>
90fd0c7ca3efc1ddff64a86f4104b13b3ac969eb

> Bug 697456. Dont create new ctx when pdf14 device reenabled
> This bug had yet another weird case where the user created a
> file that pushed the pdf14 device twice. We were in that case,
> creating a new ctx and blowing away the original one with out
> proper clean up. To avoid, only create a new one when we need it.
> base/gdevp14.c

2016-12-29 12:00:40 -0800
Michael Vrhel <michael.vrhel@artifex.com>
d621292fb2c8157d9899dcd83fd04dd250e30fe4

> Bug 697444 Unmatched transparency group pop
> This issue can only occur if there is an unmatched group pop.
> If the interpreter is doing that, then the interpreter is
> broken. With this bug the user is intentionally doing it.
> We now throw and error when it occurs.
> base/gdevp14.c

2016-12-29 15:57:43 +0000
Robin Watts <Robin.Watts@artifex.com>
4bef1a1d32e29b68855616020dbff574b9cda08f

> Bug 697453: Avoid divide by 0 in scan conversion code.
> Arithmetic overflow due to extreme values in the scan conversion
> code can cause a division by 0.
> Avoid this with a simple extra check.
> dx_old=cf814d81
> endp->x_next=b0e859b9
> alp->x_next=8069a73a
> leads to dx_den = 0
> base/gxfill.c

2016-12-29 13:39:50 +0000
Robin Watts <robin.watts@artifex.com>
0aeb0bbd41cc16e70ab6e4b1d56e0c510bf2a758

> Bug 697423: Fix overflow in pngalpha.
> The composite creation maths in the copy_alpha method overflowed
> due to the alpha range being changed from 0..15 to 0..255 in
> commit d9f041d6fe7eda89364df1424f85ace974ed0fec. Changing to
> unsigned solves this.
> devices/gdevpng.c

2016-12-28 18:34:03 +0000
Robin Watts <robin.watts@artifex.com>
a7f3177cb0ae8f56cfec52ea38a4f6f613c91055

> New scan converter: Fix problems seen at local minima/maxima.
> Sometimes the fill isn't quite right at the extremes of shapes.
> This is due to a problem when we exactly align with scanlines.
> See the output of tests_private/comparefiles/Bug696174.ps at 300dpi
> for some examples. Look at the tie lines for the first notes in the
> last line of page 2 - a scanlines worth of pixels are missing from
> the top.
> base/gxscanc.c

2016-12-28 14:16:00 +0000
Robin Watts <robin.watts@artifex.com>
79572779090e4f777bfd21996f04ff9bddcd3cbc

> New scan converter: Fix zero height rectangle behaviour.
> base/gxscanc.c

2016-12-27 16:18:40 +0000
Robin Watts <robin.watts@artifex.com>
290c044b5156b8111326da25738cbc3c1ad2b182

> Add some debug code to new scan converter.
> Output the rectangles/traps filled by the scan converter as
> postscript.
> base/gxscanc.c

2016-12-23 19:39:23 +0000
Robin Watts <robin.watts@artifex.com>
deb69ac011df1cc58a0da4c08123e2aebf819c7e

> New scanconverter; fix various problems
> 1) Fix problems seen when stroke and fills don't line up.
> This turns out to be because fills done with traps and "any
> part of a pixel" (APP) were being rounded wrongly. Fixed here.
> 2) Fix some debug statements.
> 3) Fix some centre of pixel trap filling code - the code to
> look for the 'end' of traps was failing due to only comparing
> the first half of the intercepts on a given line.
> base/gxscanc.c

2016-12-22 17:27:11 +0000
Robin Watts <robin.watts@artifex.com>
8d722263343e7c17769cc4026a76cc28046a8e1a

> Fix new scan converter.
> When filling by traps with any part of a pixel in the new scan
> converter, we were hitting cases where we we missing parts
> of lines.
> As seen in the borders of the "CPU" and "CACHE" boxes on:
> gs -dSCANCONVERTERTYPE=2 -o out.png -sDEVICE=png16m -r72
> -dFirstPage3 -dLastPage3 tests/pdf/Bug6901014_SMP_Warwick_14.pdf
> base/gxscanc.c

2016-12-22 17:26:24 +0000
Robin Watts <robin.watts@artifex.com>
0c625d998fb85d87b6184bd52bfeee954746a2cd

> Improve debugging in new scan converter.
> base/gxscanc.c

2016-12-22 10:34:31 +0000
Ken Sharp <ken.sharp@artifex.com>
64fcc1460ef1af131c17d3ced0f01ec755243986

> Fix a scan-build warning
> The return value stored in code wasn't being actioned, move it to
> code1 instead.
> devices/vector/gdevpdfv.c

2016-12-21 18:16:28 +0000
Robin Watts <robin.watts@artifex.com>
5924a809c21ce8564c72b9917e4a5fbd278049ad

> Fix double pixels writes in new scanconverter.
> When scan converting to scanlines with any part of a pixel
> we have to be careful not to double write pixels. The logic
> for this was broken. Fix it here.
> Seen with:
> gs -dSCANCONVERTERTYPE=2 -o out.png -sDEVICE=png16m -r72
> tests_private/comparefiles/Bug687295c.pdf
> base/gxscanc.c

2016-12-21 16:54:14 +0000
Ken Sharp <ken.sharp@artifex.com>
daf85701dab05f17e924a48a81edc9195b4a04e8

> fix crash with bad data supplied to makeimagedevice
> Bug #697450 "Null pointer dereference in gx_device_finalize()"
> The problem here is that the code to finalise a device unconditionally
> frees the icc_struct member of the device structure. However this
> particular (weird) device is not setup as a normal device, probably
> because its very, very ancient. Its possible for the initialisation
> of the device to abort with an error before calling gs_make_mem_device()
> which is where the icc_struct member gets allocated (or set to NULL).
> If that happens, then the cleanup code tries to free the device, which
> calls finalize() which tries to free a garbage pointer.
> Setting the device memory to 0x00 after we allocate it means that the
> icc_struct member will be NULL< and our memory manager allows for that
> happily enough, which avoids the problem.
> base/gsdevmem.c

2016-12-21 15:42:36 +0000
Ken Sharp <ken.sharp@artifex.com>
2299c9a25fc9ae7b59752f1795f8b53920901c80

> pdfwrite - don't emit degenerate Matrix for type 2 Patterns
> Bug 697451 "shfill with degenerate matrix leads to PDF unreadable with Acrobat"
> The original file deliberately makes the CTM degenerate before drawing
> a shfill. Although all PostScript consumers handle this without complaint.
> When converted to PDF most PDF consumers also are happy with the
> situation, however Adobe Acrobat recoils in horror and aborts the
> processing of the page stream with an error.
> Adobe Acrobat Distiller simply refuses (silently!) to embed the shfill
> in the PDF file.
> We don't have a way to drop the fill, so instead, if the Matrix is
> degenerate, replace it with the smallest scale matrix we can. Acrobat
> is happy with this.
> No differences expected.
> devices/vector/gdevpdfv.c

2016-12-20 10:40:56 +0000
Ken Sharp <ken.sharp@artifex.com>
7d820556974dbafaed04cfe5356fc66556907128

> Fix accuracy of bbox device with curves in filled paths
> Bug #697446 "bbox device is inaccurate with certain curves, when filled"
> The problem here is that, when a path is not clipped, is composed of
> certain types of flattish curves at the boundary, we used an inaccurate
> method to determine the bounds of the path.
> The old code used gx_path_bbox, which only considers the points in a path
> which is a problem for curves, because it considers the control points
> to be part of the curve, which they are not, and with some curves
> they can lie a long way from the actual path, as in this case.
> This commit simply forces the code through the scan-converter in order
> to get an accurate result, the same as the stroked code.
> No differences expected.
> base/gdevbbox.c

2016-12-19 16:24:37 +0000
Robin Watts <Robin.Watts@artifex.com>
79a594c9bd95239ee975e930563e7fb567018372

> Fix SEGV seen with new scan converter.
> The following command:
> gs -sOutputFile=out.ppm -dMaxBitmap=400000000 -sDEVICE=ppmraw -r300
> -Z: -sDEFAULTPAPERSIZE=letter -dNOPAUSE -dBATCH -K2000000 -dClusterJob
> -dJOBSERVER -dSCANCONVERTERTYPE=2 %rom%Resource/Init/gs_cet.ps ~/11-11.PS
> was failing, due to a problem in the scan conversion code with
> extreme paths.
> base/gxscanc.c

2016-12-17 10:33:18 +0000
Ken Sharp <ken.sharp@artifex.com>
2d46dd9e83edc813f2047a89cd260ab4de48fdf4

> More heuristic fixes from ToUnicode CMap changes
> Bug #697436 "Chinese character can not be copied out correctly"
> The changes in commit 9dba57f0f9a53c130ec2771c0ed1d7bd6bbef6ab to
> properly handle ToUnicde CMaps had rippling effects throughout the
> code wherever ToUnicode CMaps are read or generated. In this case the
> code which turned glyph names of the form uniXXXX into Unicode code
> point XXXX (in the absence of a GlyphNames2Unicode table) was not
> updated correctly.
> This commit changes the allocation from two shorts to a single unsigned
> short, and fill sin the data from the glyph name in big-endian format
> (as required throughout the ToUnicode code now), which results in
> the correct ToUnicode CMap being generated.
> devices/vector/gdevpdte.c

2016-12-13 09:20:45 -0800
Michael Vrhel <michael.vrhel@artifex.com>
00dfdefe5d38871c0c67b08ede10a208b6897d10

> Bug 693307 Overprint issues
> Remove the portions of code used to simulate
> the overprinting of CMYK and spot colorants while
> in an RGB device. This really can't work and
> we are doing a real separation compositor device for
> this process. The code parts removed only confuse
> understanding of the overprint compositor. Also fix
> problems related to Bug 693307 which were caused by
> some confusion in the code with regard to the overprint
> mode. Fix other issues related to the Ghent overprint
> tests where we were not handling properly the case
> of overprinting with a gray color when the output
> device was CMYK based. Finally there were multiple
> issues with the testing and setting of the overprint
> settings and the use of the effective overprint mode
> base/gdevp14.c
> base/gdevp14.h
> base/gscdevn.c
> base/gscolor.c
> base/gscsepr.c
> base/gscspace.c
> base/gsicc.c
> base/gsovrc.c
> base/gsovrc.h
> base/gstrans.h
> base/gxblend.h
> base/gxblend1.c
> base/gxcmap.c
> base/gxcspace.h
> base/gxdevcli.h
> base/gxoprect.c
> base/gxoprect.h

2016-12-15 13:56:43 -0800
Michael Vrhel <michael.vrhel@artifex.com>
46de0c56a0132356084b320a9f7e4d2ac1396c1c

> Bug 697435 add blending color space
> This adds the ability to specify the default (based) blending
> color space for a target device when we have transparency blending.
> -sBlendColorProfile="my_profile.icc" is used for the specification.
> Only Gray, RGB, or CMYK ICC profiles are allowed. Also, separation
> devices (e.g. tiffsep and psdcmyk) will not support the use of this
> at this time. Note also that if a target device has a put_image
> procedure where it did its own blending or tag processing, this command
> proc is not called if the blending color space is specified as the final color
> conversion is applied through begin_typed_image.
> base/gdevp14.c
> base/gdevp14.h
> base/gscms.h
> base/gsdparam.c
> base/gsequivc.c
> base/gsicc_manage.c

2016-12-14 15:56:31 +0100
Tor Andersson <tor.andersson@artifex.com>
73060a27e554f8e64ae2aba4a1b03822207346c7

> Fix warnings: remove unsigned < 0 tests that are always false.
> jbig2dec/jbig2_image.c
> jbig2dec/jbig2_mmr.c
> jbig2dec/jbig2_symbol_dict.c

2016-12-12 17:47:17 +0000
Robin Watts <robin.watts@artifex.com>
cecf6b592945d247bf932f6a4f50065db4acfba8

> Squash signed/unsigned warnings in MSVC jbig2 build.
> Also rename "new" to "new_dict", because "new" is a bad
> variable name.
> jbig2dec/jbig2.c
> jbig2dec/jbig2.h
> jbig2dec/jbig2_generic.c
> jbig2dec/jbig2_halftone.c
> jbig2dec/jbig2_huffman.c
> jbig2dec/jbig2_huffman.h
> jbig2dec/jbig2_image.c
> jbig2dec/jbig2_mmr.c
> jbig2dec/jbig2_page.c
> jbig2dec/jbig2_priv.h
> jbig2dec/jbig2_segment.c
> jbig2dec/jbig2_symbol_dict.c
> jbig2dec/jbig2_symbol_dict.h
> jbig2dec/jbig2_text.c
> jbig2dec/jbig2_text.h

2016-12-12 08:31:34 -0800
Michael Vrhel <michael.vrhel@artifex.com>
0efaa8dff5b82169313a086861597e0f455892d3

> Bug 697350. Fix isolated knockout group rendering
> The blending code in the knockout isolate case had issues
> and the only difference compared to the non-isolated case
> is that we don't need to do the blend with the backdrop.
> base/gdevp14.c
> base/gxblend.c
> base/gxblend.h
> base/gxblend1.c

2016-12-12 17:53:23 +0000
Robin Watts <robin.watts@artifex.com>
15d9aaac64334776284310f5cbfe8ae79edae540

> Squash annoying MSVC warning.
> base/gxpcmap.c

2016-12-09 19:29:37 +0000
Robin Watts <robin.watts@artifex.com>
f5ac81f27674c54540c6313ed31b027f1385ceb5

> Add ETS to Downscaler.
> Currently only hooked up for tiffscaled and tiffscaled4.
> Enable using -dDownScaleETS=1 along with the usual other downscaler
> hooks.
> No control over all the myriad ETS flags as yet.
> base/ets.c
> base/ets.h
> base/ets_tm.h
> base/gxdownscale.c
> base/gxdownscale.h
> base/lib.mak
> devices/gdevtifs.c
> devices/gdevtifs.h
> devices/gdevtsep.c
> doc/Devices.htm
> windows/ghostscript.vcproj

2016-12-09 12:33:41 -0800
Michael Vrhel <michael.vrhel@artifex.com>
dd50b33582901eda25fce78a40552de91db3c8e5

> Use normal blend mode for spots when mode is non-white preserving
> When we are doing the group compositing, make sure to catch the
> cases where we have spot colorants and the blend modes is either
> non-separable or non-white preserving. In those cases, the spot
> colorants have to use the normal blend mode.
> base/gxblend.c
> base/gxblend.h
> base/gxblend1.c

2016-12-09 10:43:57 +0000
Chris Liddell <chris.liddell@artifex.com>
8894abf2985a58900e778957f93151b6cec1c17a

> Address a segfault and error introduced in 4b3be09
> In the zbegintransparencymaskgroup with a '/None' SMask parameter with the clist
> in use, we get to clist_create_compositor().
> In there, the return value of the get_cropping method can be either an error
> (negative) or a specific cropping operation (positive). We assign it to 'code',
> and if it's an error, return it, if not, assign it to another variable. But
> don't set 'code' to anything else. It is then possible to get to the end of the
> function without going through the path where 'code' is used again.
> Setting 'code' to 0 after storing the cropping op solves the problem.
> base/gxclimag.c

2016-12-08 18:09:58 +0000
Chris Liddell <chris.liddell@artifex.com>
4b3be091fa0384e679baaf04b14ea195da5adf21

> Bug 697415: 'clean up' after images with SMask entries
> Our handling of images with SMasks depends on telling the transparency
> compositor to expect an SMask image, draw the SMask as a regular image,
> tell the compositor the SMask is done, and then draw the 'main' image (to
> which the compositor will apply the SMask).
> The problem was that the compositor treats SMasks from images and SMasks from
> ExtGState as the same (which they really are), but the image drawing code
> took no action to inform the compositor we were done with the SMask, thus
> leaving it place.
> By adding a call to "unset" the SMask from the current graphics state (in this
> case, it's really the current group in the compositor), we ensure the SMask
> is only applied to the current image).
> Resource/Init/pdf_draw.ps

2016-12-05 18:30:06 +0000
Ken Sharp <ken.sharp@artifex.com>
c875bf7490447579e850fa4722874848c3be4657

> PDF Interpreter - more indirect object foolishness
> Bug #697402 "PDF rendered as blank in PDF with unusual font width array"
> Not ony the /Widths array of one of the fonts, but also an entry in a
> /W array for a CIDFont specify a value using an indirect object
> reference.
> While this is silly (it makes the PDF file larger and slower) it is legal
> so this commit copes with it by dereferencing any indirect references.
> We alos now handle W2 arrays with references, even though this file
> doesn't use one.
> Resource/Init/pdf_font.ps

2016-12-03 06:40:17 -0800
Michael Vrhel <michael.vrhel@artifex.com>
0e16bd592aaccde9b384415a87d8a9bef9c57f83

> Fix debug output for pattern bitmaps
> base/gxpcmap.c

2016-12-03 12:25:58 +0000
Ken Sharp <ken.sharp@artifex.com>
cc746214644deacd5233a1453ce660573af09443

> txtwrite - sort out endian-ness of Unicode based on architecture
> Bug #697339 "Device txtwrite seems to be broken"
> decode_glyph sppears always to return big-endian shorts for Unicode
> code points. On litlee-endian platforms, reverse the byte order so
> that we can treat the data as shorts instead of bytes.
> As I don't have a big endian device to test this on, further work may
> be required.
> devices/vector/gdevtxtw.c

2016-12-02 09:00:20 -0800
Ray Johnston <ray.johnston@artifex.com>
d05c99ba9f3c1539a5b02a96ed050422677d9704

> Remove MarginsHWResolution non-standard device parameter
> base/gdevp14.c
> base/gscoord.c
> base/gsdevice.c
> base/gsdevmem.c
> base/gsdparam.c
> base/gspath.c
> base/gxclist.c
> base/gxdevcli.h
> base/gxdevice.h
> devices/gdevbit.c
> devices/gdevupd.c
> devices/gdevxalt.c
> devices/gdevxini.c
> lib/align.ps

2016-12-02 19:03:42 +0000
Ken Sharp <ken.sharp@artifex.com>
b880332b899e0e59d17c7e48033e5cc816e5a831

> pdfwrite - adjust Mono Subsample resolution to integer
> Bug #697351 "/Subsample filter needs to make non-integer scales integer for monochrome images"
> The only downsampling filter available for monochrome images and
> imagemasks (1 bpp images and masks) is the /Subsample filter. However
> the Subsample filter only works when the downsampling factor is an
> exact integer.
> Its unreasonable to insist that all the monochrome images in a given
> document can be downsampled to a specific resolution and that the downsample
> factor for all those images will be an integer.
> So here, if the image is monochrome (so we canot switch to the Bicubic
> filter) and the factor is not an integer, we force the factor to the
> nearest integer.
> Also, update the documentation which incorrectly stated that when
> /PDFSETTINGS was set to 'prepress', monochrome images used the Bicubic
> filter, it actually uses the Subsample filter.
> devices/vector/gdevpsdi.c
> doc/VectorDevices.htm

2016-12-02 17:13:35 +0000
Ken Sharp <ken.sharp@artifex.com>
26acbbb980a44d9610080876afeef5bb834d21e3

> Documentation - Document the fact that setpagedevice resets distiller params
> doc/VectorDevices.htm

2016-12-02 16:33:25 +0000
Ken Sharp <ken.sharp@artifex.com>
336c69b8be32c7193909a7f25b1a073b0ac2d92f

> PDF Interpreter - have warning messages respect QUIET
> Bug #697394 "stderr is included with stdout when result is set to stdout"
> We do want the warnings to go to stdout, for debugging purposes,
> because it is easier to use -dPDFDEBUG if the warnings are interleaved.
> For the benefit of user piping the output to stdout, have the warning
> messages respect -dQUIET so they don't end up in the output file.
> Error messages (which are directed to stderr anyway) are not suppressed
> as these are important.
> No differences expected
> Resource/Init/pdf_main.ps

2016-11-24 12:26:17 -0800
Ray Johnston <ray.johnston@artifex.com>
a8d6c4074ee8cfc251ebdd44ce4d2f97cdf20517

> Revert commit 3cde6d6d, require %d OutputFile spec for multi-page tiffsep
> The previous commit allowed multi-page separation files, but this would only
> work if all pages had the same spot colors. If a later page added a spot color
> it would be appended to the set of spot colors, but then the separation layer
> would be emitted with the previous spot color name (according to the order)
> and the CMYK equivalent for that previous spot color would be used to make the
> CMYK composite.
> Now multi-page tiffsep requires the use of %d (or some other format that uses
> the page number in the filename). The first page can be output without %d, and
> the second page will issue an error message and quit with ioerror.
> In theory we could wait to issue the error until we encounter a spot color order
> that was not the same as the first page, but this is of little utility, and
> this change makes tiffsep operate similarly to the psdcmyk device.
> devices/gdevtsep.c
> doc/Devices.htm

2016-11-24 09:56:12 +0000
Ken Sharp <ken.sharp@artifex.com>
f42898997f249062f5da8fcf9c3a46cd6443fb39

> PDF interpreter - skip 'R' operator in invalid context
> Bug #697365 "corrupted content stream causes error"
> The file has 2 Form XObject whose content streams have a single garbage
> byte at the end of the stream, and which forms part of the 'endstream'.
> In one case this simply leads to garbage on the stack, which we deal with
> already, but in the other case the garbage happens to be a 'R character
> which we attempt to process as a token.
> Now attempting to process an R operator fails in this case, because the
> stack contents are not a pair of integers. However, in the process, it
> removes two stack objects which we require for further processing.
> There's no way to restore those to the operand stack, and there is no
> way to not process the 'R' as a token. We also cannot temporarily
> define 'R' as a no-op for the course of a stream, because if the
> stream uses named objects which have not already been dereferenced
> we need to execute the R operator to resolve them.
> This commit modifies the definition of R so that it checks the type
> of the expected operands before consuming them. If they are not both
> integers then it flags an error, leaves the stack alone and exits.
> THis will, of course, be slightly slower than the current approach
> which doesn't check types, but it should only be executed once
> for each object in the file. Even for a large file that should only
> be a few tens of thousands, and this is likely to be lost among
> the processing time for real operations. However, shuold this
> causew significant performance problems we may remove this in the
> future.
> No differences expected.
> Resource/Init/pdf_base.ps
> Resource/Init/pdf_main.ps

2016-11-23 09:26:16 -0800
Michael Vrhel <michael.vrhel@artifex.com>
b7ea690782c306241ed94fa3bdaf296f6bcc455f

> Bug 697366
> Partial fix. Pattern now renders correctly. Issues
> with a few other spots though.
> base/gdevdsha.c

2016-11-23 06:58:19 -0800
Michael Vrhel <michael.vrhel@artifex.com>
2237813596c8703de6008dd6c05460f9dac3ed75

> Fix segv due to improper depth computation
> Commit
> 47294ff5b168d25bfc7db64f51572d64b8ebde91
> had an issue that was found when running
> eci_altona-test-suite-v2_technical2_x4.pdf
> (the Altona file with ALL the pages on one page)
> with tiffsep and psdcmyk. This fixes the segv.
> A rending issue remains on this issue.
> Bug http://bugs.ghostscript.com/show_bug.cgi?id=697366
> was opened to address.
> base/gdevp14.c

2016-11-21 10:03:24 +0000
Chris Liddell <chris.liddell@artifex.com>
5b87f18df814aaa9f0036c843a4b24b1638aa4cf

> libtiff: update to 4.0.7
> Add in portability changes to tiffiop.h
> Portability tiffiop.h
> Remove globals from tif_pixarlog.c
> tiff/CMakeLists.txt
> tiff/ChangeLog
> tiff/HOWTO-RELEASE
> tiff/Makefile.am
> tiff/Makefile.in
> tiff/RELEASE-DATE
> tiff/VERSION
> tiff/aclocal.m4
> tiff/build/CMakeLists.txt
> tiff/build/Makefile.am
> tiff/build/Makefile.in
> tiff/config/compile
> tiff/config/depcomp
> tiff/config/ltmain.sh
> tiff/config/missing
> tiff/config/test-driver
> tiff/configure
> tiff/configure.ac
> tiff/configure.com
> tiff/contrib/CMakeLists.txt
> tiff/contrib/Makefile.am
> tiff/contrib/Makefile.in
> tiff/contrib/addtiffo/CMakeLists.txt
> tiff/contrib/addtiffo/Makefile.am
> tiff/contrib/addtiffo/Makefile.in
> tiff/contrib/addtiffo/addtiffo.c
> tiff/contrib/addtiffo/tif_overview.c
> tiff/contrib/addtiffo/tif_ovrcache.c
> tiff/contrib/dbs/CMakeLists.txt
> tiff/contrib/dbs/Makefile.am
> tiff/contrib/dbs/Makefile.in
> tiff/contrib/dbs/xtiff/CMakeLists.txt
> tiff/contrib/dbs/xtiff/Makefile.am
> tiff/contrib/dbs/xtiff/Makefile.in
> tiff/contrib/dbs/xtiff/xtiff.c
> tiff/contrib/iptcutil/CMakeLists.txt
> tiff/contrib/iptcutil/Makefile.am
> tiff/contrib/iptcutil/Makefile.in
> tiff/contrib/iptcutil/iptcutil.c
> tiff/contrib/mfs/CMakeLists.txt
> tiff/contrib/mfs/Makefile.am
> tiff/contrib/mfs/Makefile.in
> tiff/contrib/pds/CMakeLists.txt
> tiff/contrib/pds/Makefile.am
> tiff/contrib/pds/Makefile.in
> tiff/contrib/ras/CMakeLists.txt
> tiff/contrib/ras/Makefile.am
> tiff/contrib/ras/Makefile.in
> tiff/contrib/stream/CMakeLists.txt
> tiff/contrib/stream/Makefile.am
> tiff/contrib/stream/Makefile.in
> tiff/contrib/tags/CMakeLists.txt
> tiff/contrib/tags/Makefile.am
> tiff/contrib/tags/Makefile.in
> tiff/contrib/win_dib/CMakeLists.txt
> tiff/contrib/win_dib/Makefile.am
> tiff/contrib/win_dib/Makefile.in
> tiff/html/CMakeLists.txt
> tiff/html/Makefile.am
> tiff/html/Makefile.in
> tiff/html/addingtags.html
> tiff/html/bugs.html
> tiff/html/build.html
> tiff/html/contrib.html
> tiff/html/document.html
> tiff/html/images.html
> tiff/html/images/CMakeLists.txt
> tiff/html/images/Makefile.am
> tiff/html/images/Makefile.in
> tiff/html/index.html
> tiff/html/internals.html
> tiff/html/intro.html
> tiff/html/libtiff.html
> tiff/html/man/CMakeLists.txt
> tiff/html/man/HtmlDoc.cmake
> tiff/html/man/Makefile.am
> tiff/html/man/Makefile.in
> tiff/html/man/TIFFClose.3tiff.html
> tiff/html/man/TIFFDataWidth.3tiff.html
> tiff/html/man/TIFFError.3tiff.html
> tiff/html/man/TIFFFieldDataType.3tiff.html
> tiff/html/man/TIFFFieldName.3tiff.html
> tiff/html/man/TIFFFieldPassCount.3tiff.html
> tiff/html/man/TIFFFieldReadCount.3tiff.html
> tiff/html/man/TIFFFieldTag.3tiff.html
> tiff/html/man/TIFFFieldWriteCount.3tiff.html
> tiff/html/man/TIFFFlush.3tiff.html
> tiff/html/man/TIFFGetField.3tiff.html
> tiff/html/man/TIFFRGBAImage.3tiff.html
> tiff/html/man/TIFFReadDirectory.3tiff.html
> tiff/html/man/TIFFReadEncodedStrip.3tiff.html
> tiff/html/man/TIFFReadEncodedTile.3tiff.html
> tiff/html/man/TIFFReadRGBAImage.3tiff.html
> tiff/html/man/TIFFReadRGBAStrip.3tiff.html
> tiff/html/man/TIFFReadRGBATile.3tiff.html
> tiff/html/man/TIFFReadRawStrip.3tiff.html
> tiff/html/man/TIFFReadRawTile.3tiff.html
> tiff/html/man/TIFFReadScanline.3tiff.html
> tiff/html/man/TIFFReadTile.3tiff.html
> tiff/html/man/TIFFSetDirectory.3tiff.html
> tiff/html/man/TIFFSetField.3tiff.html
> tiff/html/man/TIFFWarning.3tiff.html
> tiff/html/man/TIFFWriteDirectory.3tiff.html
> tiff/html/man/TIFFWriteEncodedStrip.3tiff.html
> tiff/html/man/TIFFWriteEncodedTile.3tiff.html
> tiff/html/man/TIFFWriteRawStrip.3tiff.html
> tiff/html/man/TIFFWriteRawTile.3tiff.html
> tiff/html/man/TIFFWriteScanline.3tiff.html
> tiff/html/man/TIFFWriteTile.3tiff.html
> tiff/html/man/TIFFbuffer.3tiff.html
> tiff/html/man/TIFFcodec.3tiff.html
> tiff/html/man/TIFFcolor.3tiff.html
> tiff/html/man/TIFFmemory.3tiff.html
> tiff/html/man/TIFFsize.3tiff.html
> tiff/html/man/TIFFstrip.3tiff.html
> tiff/html/man/TIFFswab.3tiff.html
> tiff/html/man/TIFFtile.3tiff.html
> tiff/html/man/fax2ps.1.html
> tiff/html/man/fax2tiff.1.html
> tiff/html/man/gif2tiff.1.html
> tiff/html/man/index.html
> tiff/html/man/pal2rgb.1.html
> tiff/html/man/ppm2tiff.1.html
> tiff/html/man/ras2tiff.1.html
> tiff/html/man/raw2tiff.1.html
> tiff/html/man/rgb2ycbcr.1.html
> tiff/html/man/sgi2tiff.1.html
> tiff/html/man/thumbnail.1.html
> tiff/html/man/tiff2bw.1.html
> tiff/html/man/tiff2pdf.1.html
> tiff/html/man/tiff2ps.1.html
> tiff/html/man/tiff2rgba.1.html
> tiff/html/man/tiffcmp.1.html
> tiff/html/man/tiffcp.1.html
> tiff/html/man/tiffcrop.1.html
> tiff/html/man/tiffdither.1.html
> tiff/html/man/tiffdump.1.html
> tiff/html/man/tiffgt.1.html
> tiff/html/man/tiffinfo.1.html
> tiff/html/man/tiffmedian.1.html
> tiff/html/man/tiffset.1.html
> tiff/html/man/tiffsplit.1.html
> tiff/html/man/tiffsv.1.html
> tiff/html/misc.html
> tiff/html/support.html
> tiff/html/tools.html
> tiff/html/v3.4beta007.html
> tiff/html/v3.4beta016.html
> tiff/html/v3.4beta018.html
> tiff/html/v3.4beta024.html
> tiff/html/v3.4beta028.html
> tiff/html/v3.4beta029.html
> tiff/html/v3.4beta031.html
> tiff/html/v3.4beta032.html
> tiff/html/v3.4beta033.html
> tiff/html/v3.4beta034.html
> tiff/html/v3.4beta035.html
> tiff/html/v3.4beta036.html
> tiff/html/v3.5.1.html
> tiff/html/v3.5.2.html
> tiff/html/v3.5.3.html
> tiff/html/v3.5.4.html
> tiff/html/v3.5.5.html
> tiff/html/v3.5.6-beta.html
> tiff/html/v3.5.7.html
> tiff/html/v3.6.0.html
> tiff/html/v3.6.1.html
> tiff/html/v3.7.0.html
> tiff/html/v3.7.0alpha.html
> tiff/html/v3.7.0beta.html
> tiff/html/v3.7.0beta2.html
> tiff/html/v3.7.1.html
> tiff/html/v3.7.2.html
> tiff/html/v3.7.3.html
> tiff/html/v3.7.4.html
> tiff/html/v3.8.0.html
> tiff/html/v3.8.1.html
> tiff/html/v3.8.2.html
> tiff/html/v3.9.0beta.html
> tiff/html/v3.9.1.html
> tiff/html/v3.9.2.html
> tiff/html/v4.0.0.html
> tiff/html/v4.0.1.html
> tiff/html/v4.0.2.html
> tiff/html/v4.0.3.html
> tiff/html/v4.0.4.html
> tiff/html/v4.0.4beta.html
> tiff/html/v4.0.5.html
> tiff/html/v4.0.6.html
> tiff/html/v4.0.7.html
> tiff/libtiff/CMakeLists.txt
> tiff/libtiff/Makefile.am
> tiff/libtiff/Makefile.in
> tiff/libtiff/Makefile.vc
> tiff/libtiff/libtiff.def
> tiff/libtiff/mkg3states.c
> tiff/libtiff/tif_aux.c
> tiff/libtiff/tif_close.c
> tiff/libtiff/tif_codec.c
> tiff/libtiff/tif_color.c
> tiff/libtiff/tif_compress.c
> tiff/libtiff/tif_config.h.cmake.in
> tiff/libtiff/tif_config.h.in
> tiff/libtiff/tif_config.vc.h
> tiff/libtiff/tif_dir.c
> tiff/libtiff/tif_dirinfo.c
> tiff/libtiff/tif_dirread.c
> tiff/libtiff/tif_dirwrite.c
> tiff/libtiff/tif_dumpmode.c
> tiff/libtiff/tif_extension.c
> tiff/libtiff/tif_fax3.c
> tiff/libtiff/tif_fax3.h
> tiff/libtiff/tif_getimage.c
> tiff/libtiff/tif_jpeg.c
> tiff/libtiff/tif_jpeg_12.c
> tiff/libtiff/tif_luv.c
> tiff/libtiff/tif_lzma.c
> tiff/libtiff/tif_lzw.c
> tiff/libtiff/tif_next.c
> tiff/libtiff/tif_ojpeg.c
> tiff/libtiff/tif_open.c
> tiff/libtiff/tif_packbits.c
> tiff/libtiff/tif_pixarlog.c
> tiff/libtiff/tif_predict.c
> tiff/libtiff/tif_predict.h
> tiff/libtiff/tif_print.c
> tiff/libtiff/tif_read.c
> tiff/libtiff/tif_stream.cxx
> tiff/libtiff/tif_strip.c
> tiff/libtiff/tif_swab.c
> tiff/libtiff/tif_thunder.c
> tiff/libtiff/tif_tile.c
> tiff/libtiff/tif_unix.c
> tiff/libtiff/tif_win32.c
> tiff/libtiff/tif_write.c
> tiff/libtiff/tif_zip.c
> tiff/libtiff/tiff.h
> tiff/libtiff/tiffconf.h.cmake.in
> tiff/libtiff/tiffconf.vc.h
> tiff/libtiff/tiffio.h
> tiff/libtiff/tiffiop.h
> tiff/libtiff/tiffvers.h
> tiff/libtiff/uvcode.h
> tiff/man/CMakeLists.txt
> tiff/man/Makefile.am
> tiff/man/Makefile.in
> tiff/man/TIFFClose.3tiff
> tiff/man/TIFFDataWidth.3tiff
> tiff/man/TIFFError.3tiff
> tiff/man/TIFFFieldDataType.3tiff
> tiff/man/TIFFFieldName.3tiff
> tiff/man/TIFFFieldPassCount.3tiff
> tiff/man/TIFFFieldReadCount.3tiff
> tiff/man/TIFFFieldTag.3tiff
> tiff/man/TIFFFieldWriteCount.3tiff
> tiff/man/TIFFFlush.3tiff
> tiff/man/TIFFGetField.3tiff
> tiff/man/TIFFRGBAImage.3tiff
> tiff/man/TIFFReadDirectory.3tiff
> tiff/man/TIFFReadEncodedStrip.3tiff
> tiff/man/TIFFReadEncodedTile.3tiff
> tiff/man/TIFFReadRGBAImage.3tiff
> tiff/man/TIFFReadRGBAStrip.3tiff
> tiff/man/TIFFReadRGBATile.3tiff
> tiff/man/TIFFReadRawStrip.3tiff
> tiff/man/TIFFReadRawTile.3tiff
> tiff/man/TIFFReadScanline.3tiff
> tiff/man/TIFFReadTile.3tiff
> tiff/man/TIFFSetDirectory.3tiff
> tiff/man/TIFFSetField.3tiff
> tiff/man/TIFFWarning.3tiff
> tiff/man/TIFFWriteDirectory.3tiff
> tiff/man/TIFFWriteEncodedStrip.3tiff
> tiff/man/TIFFWriteEncodedTile.3tiff
> tiff/man/TIFFWriteRawStrip.3tiff
> tiff/man/TIFFWriteRawTile.3tiff
> tiff/man/TIFFWriteScanline.3tiff
> tiff/man/TIFFWriteTile.3tiff
> tiff/man/TIFFbuffer.3tiff
> tiff/man/TIFFcodec.3tiff
> tiff/man/TIFFcolor.3tiff
> tiff/man/TIFFmemory.3tiff
> tiff/man/TIFFsize.3tiff
> tiff/man/TIFFstrip.3tiff
> tiff/man/TIFFswab.3tiff
> tiff/man/TIFFtile.3tiff
> tiff/man/bmp2tiff.1
> tiff/man/fax2ps.1
> tiff/man/fax2tiff.1
> tiff/man/gif2tiff.1
> tiff/man/libtiff.3tiff
> tiff/man/pal2rgb.1
> tiff/man/ppm2tiff.1
> tiff/man/ras2tiff.1
> tiff/man/raw2tiff.1
> tiff/man/rgb2ycbcr.1
> tiff/man/sgi2tiff.1
> tiff/man/thumbnail.1
> tiff/man/tiff2bw.1
> tiff/man/tiff2pdf.1
> tiff/man/tiff2ps.1
> tiff/man/tiff2rgba.1
> tiff/man/tiffcmp.1
> tiff/man/tiffcp.1
> tiff/man/tiffcrop.1
> tiff/man/tiffdither.1
> tiff/man/tiffdump.1
> tiff/man/tiffgt.1
> tiff/man/tiffinfo.1
> tiff/man/tiffmedian.1
> tiff/man/tiffset.1
> tiff/man/tiffsplit.1
> tiff/man/tiffsv.1
> tiff/nmake.opt
> tiff/port/CMakeLists.txt
> tiff/port/Makefile.am
> tiff/port/Makefile.in
> tiff/port/Makefile.vc
> tiff/port/libport.h
> tiff/port/snprintf.c
> tiff/port/strcasecmp.c
> tiff/test/CMakeLists.txt
> tiff/test/Makefile.am
> tiff/test/Makefile.in
> tiff/test/TiffSplitTest.cmake
> tiff/test/TiffTest.cmake
> tiff/test/TiffTestCommon.cmake
> tiff/test/ascii_tag.c
> tiff/test/bmp2tiff_palette.sh
> tiff/test/bmp2tiff_rgb.sh
> tiff/test/common.sh
> tiff/test/custom_dir.c
> tiff/test/gif2tiff.sh
> tiff/test/images/palette-1c-8b.bmp
> tiff/test/images/palette-1c-8b.gif
> tiff/test/images/quad-tile.jpg.tiff
> tiff/test/images/rgb-3c-8b.bmp
> tiff/test/long_tag.c
> tiff/test/raw_decode.c
> tiff/test/rewrite_tag.c
> tiff/test/short_tag.c
> tiff/test/strip.c
> tiff/test/tiff2rgba-quad-tile.jpg.sh
> tiff/tools/CMakeLists.txt
> tiff/tools/Makefile.am
> tiff/tools/Makefile.in
> tiff/tools/Makefile.vc
> tiff/tools/bmp2tiff.c
> tiff/tools/fax2ps.c
> tiff/tools/fax2tiff.c
> tiff/tools/gif2tiff.c
> tiff/tools/pal2rgb.c
> tiff/tools/ppm2tiff.c
> tiff/tools/ras2tiff.c
> tiff/tools/rasterfile.h
> tiff/tools/raw2tiff.c
> tiff/tools/rgb2ycbcr.c
> tiff/tools/sgi2tiff.c
> tiff/tools/sgisv.c
> tiff/tools/thumbnail.c
> tiff/tools/tiff2bw.c
> tiff/tools/tiff2pdf.c
> tiff/tools/tiff2ps.c
> tiff/tools/tiff2rgba.c
> tiff/tools/tiffcmp.c
> tiff/tools/tiffcp.c
> tiff/tools/tiffcrop.c
> tiff/tools/tiffdither.c
> tiff/tools/tiffdump.c
> tiff/tools/tiffgt.c
> tiff/tools/tiffinfo.c
> tiff/tools/tiffmedian.c
> tiff/tools/tiffset.c
> tiff/tools/tiffsplit.c
> tiff/tools/ycbcr.c

2016-11-08 09:50:00 +0000
Chris Liddell <chris.liddell@artifex.com>
6655712ee1d0bf2a7818044613bbed226b7abddd

> Update freetype to 2.7.0
> Tweak makefile for new freetype version
> Force use of the v35 Freetype bytecode interpreter
> base/fapi_ft.c
> base/freetype.mak
> freetype/CMakeLists.txt
> freetype/ChangeLog
> freetype/ChangeLog.20
> freetype/ChangeLog.21
> freetype/ChangeLog.22
> freetype/ChangeLog.23
> freetype/ChangeLog.24
> freetype/ChangeLog.25
> freetype/ChangeLog.26
> freetype/Jamfile
> freetype/Jamrules
> freetype/Makefile
> freetype/README
> freetype/README.git
> freetype/autogen.sh
> freetype/builds/amiga/README
> freetype/builds/amiga/include/config/ftconfig.h
> freetype/builds/amiga/include/config/ftmodule.h
> freetype/builds/amiga/makefile
> freetype/builds/amiga/makefile.os4
> freetype/builds/amiga/smakefile
> freetype/builds/amiga/src/base/ftdebug.c
> freetype/builds/amiga/src/base/ftsystem.c
> freetype/builds/ansi/ansi-def.mk
> freetype/builds/ansi/ansi.mk
> freetype/builds/atari/ATARI.H
> freetype/builds/atari/README.TXT
> freetype/builds/beos/beos-def.mk
> freetype/builds/beos/beos.mk
> freetype/builds/beos/detect.mk
> freetype/builds/cmake/FindHarfBuzz.cmake
> freetype/builds/cmake/iOS.cmake
> freetype/builds/cmake/testbuild.sh
> freetype/builds/compiler/ansi-cc.mk
> freetype/builds/compiler/bcc-dev.mk
> freetype/builds/compiler/bcc.mk
> freetype/builds/compiler/emx.mk
> freetype/builds/compiler/gcc-dev.mk
> freetype/builds/compiler/gcc.mk
> freetype/builds/compiler/intelc.mk
> freetype/builds/compiler/unix-lcc.mk
> freetype/builds/compiler/visualage.mk
> freetype/builds/compiler/visualc.mk
> freetype/builds/compiler/watcom.mk
> freetype/builds/compiler/win-lcc.mk
> freetype/builds/detect.mk
> freetype/builds/dos/detect.mk
> freetype/builds/dos/dos-def.mk
> freetype/builds/dos/dos-emx.mk
> freetype/builds/dos/dos-gcc.mk
> freetype/builds/dos/dos-wat.mk
> freetype/builds/exports.mk
> freetype/builds/freetype.mk
> freetype/builds/link_dos.mk
> freetype/builds/link_std.mk
> freetype/builds/mac/FreeType.m68k_cfm.make.txt
> freetype/builds/mac/FreeType.m68k_far.make.txt
> freetype/builds/mac/FreeType.ppc_carbon.make.txt
> freetype/builds/mac/FreeType.ppc_classic.make.txt
> freetype/builds/mac/ftmac.c
> freetype/builds/modules.mk
> freetype/builds/os2/detect.mk
> freetype/builds/os2/os2-def.mk
> freetype/builds/os2/os2-dev.mk
> freetype/builds/os2/os2-gcc.mk
> freetype/builds/symbian/bld.inf
> freetype/builds/symbian/freetype.mmp
> freetype/builds/toplevel.mk
> freetype/builds/unix/aclocal.m4
> freetype/builds/unix/config.guess
> freetype/builds/unix/config.sub
> freetype/builds/unix/configure.ac
> freetype/builds/unix/configure.raw
> freetype/builds/unix/detect.mk
> freetype/builds/unix/freetype-config.in
> freetype/builds/unix/freetype2.in
> freetype/builds/unix/freetype2.m4
> freetype/builds/unix/ft-munmap.m4
> freetype/builds/unix/ftconfig.in
> freetype/builds/unix/ftsystem.c
> freetype/builds/unix/install-sh
> freetype/builds/unix/install.mk
> freetype/builds/unix/ltmain.sh
> freetype/builds/unix/mkinstalldirs
> freetype/builds/unix/unix-cc.in
> freetype/builds/unix/unix-def.in
> freetype/builds/unix/unix-dev.mk
> freetype/builds/unix/unix-lcc.mk
> freetype/builds/unix/unix.mk
> freetype/builds/unix/unixddef.mk
> freetype/builds/vms/ftconfig.h
> freetype/builds/vms/ftsystem.c
> freetype/builds/wince/ftdebug.c
> freetype/builds/wince/vc2005-ce/freetype.sln
> freetype/builds/wince/vc2005-ce/freetype.vcproj
> freetype/builds/wince/vc2005-ce/index.html
> freetype/builds/wince/vc2008-ce/freetype.sln
> freetype/builds/wince/vc2008-ce/freetype.vcproj
> freetype/builds/wince/vc2008-ce/index.html
> freetype/builds/windows/detect.mk
> freetype/builds/windows/ftdebug.c
> freetype/builds/windows/vc2005/freetype.vcproj
> freetype/builds/windows/vc2005/index.html
> freetype/builds/windows/vc2008/freetype.vcproj
> freetype/builds/windows/vc2008/index.html
> freetype/builds/windows/vc2010/freetype.sln
> freetype/builds/windows/vc2010/freetype.vcxproj
> freetype/builds/windows/vc2010/freetype.vcxproj.filters
> freetype/builds/windows/vc2010/index.html
> freetype/builds/windows/visualc/freetype.dsp
> freetype/builds/windows/visualc/freetype.vcproj
> freetype/builds/windows/visualc/index.html
> freetype/builds/windows/visualce/freetype.dsp
> freetype/builds/windows/visualce/freetype.vcproj
> freetype/builds/windows/visualce/index.html
> freetype/builds/windows/w32-bcc.mk
> freetype/builds/windows/w32-bccd.mk
> freetype/builds/windows/w32-dev.mk
> freetype/builds/windows/w32-gcc.mk
> freetype/builds/windows/w32-icc.mk
> freetype/builds/windows/w32-intl.mk
> freetype/builds/windows/w32-lcc.mk
> freetype/builds/windows/w32-mingw32.mk
> freetype/builds/windows/w32-vcc.mk
> freetype/builds/windows/w32-wat.mk
> freetype/builds/windows/win32-def.mk
> freetype/configure
> freetype/devel/ft2build.h
> freetype/devel/ftoption.h
> freetype/docs/CHANGES
> freetype/docs/CUSTOMIZE
> freetype/docs/DEBUG
> freetype/docs/FTL.TXT
> freetype/docs/INSTALL
> freetype/docs/INSTALL.ANY
> freetype/docs/INSTALL.CROSS
> freetype/docs/INSTALL.GNU
> freetype/docs/INSTALL.UNIX
> freetype/docs/INSTALL.VMS
> freetype/docs/LICENSE.TXT
> freetype/docs/TODO
> freetype/docs/VERSION.DLL
> freetype/docs/VERSIONS.TXT
> freetype/docs/formats.txt
> freetype/docs/freetype-config.1
> freetype/docs/raster.txt
> freetype/docs/reference/ft2-auto_hinter.html
> freetype/docs/reference/ft2-base_interface.html
> freetype/docs/reference/ft2-basic_types.html
> freetype/docs/reference/ft2-bdf_fonts.html
> freetype/docs/reference/ft2-bitmap_handling.html
> freetype/docs/reference/ft2-bzip2.html
> freetype/docs/reference/ft2-cache_subsystem.html
> freetype/docs/reference/ft2-cff_driver.html
> freetype/docs/reference/ft2-cid_fonts.html
> freetype/docs/reference/ft2-computations.html
> freetype/docs/reference/ft2-error_code_values.html
> freetype/docs/reference/ft2-error_enumerations.html
> freetype/docs/reference/ft2-font_formats.html
> freetype/docs/reference/ft2-gasp_table.html
> freetype/docs/reference/ft2-glyph_management.html
> freetype/docs/reference/ft2-glyph_stroker.html
> freetype/docs/reference/ft2-glyph_variants.html
> freetype/docs/reference/ft2-gx_validation.html
> freetype/docs/reference/ft2-gzip.html
> freetype/docs/reference/ft2-header_file_macros.html
> freetype/docs/reference/ft2-header_inclusion.html
> freetype/docs/reference/ft2-incremental.html
> freetype/docs/reference/ft2-index.html
> freetype/docs/reference/ft2-lcd_filtering.html
> freetype/docs/reference/ft2-list_processing.html
> freetype/docs/reference/ft2-lzw.html
> freetype/docs/reference/ft2-mac_specific.html
> freetype/docs/reference/ft2-module_management.html
> freetype/docs/reference/ft2-multiple_masters.html
> freetype/docs/reference/ft2-ot_validation.html
> freetype/docs/reference/ft2-outline_processing.html
> freetype/docs/reference/ft2-pfr_fonts.html
> freetype/docs/reference/ft2-quick_advance.html
> freetype/docs/reference/ft2-raster.html
> freetype/docs/reference/ft2-sfnt_names.html
> freetype/docs/reference/ft2-sizes_management.html
> freetype/docs/reference/ft2-system_interface.html
> freetype/docs/reference/ft2-toc.html
> freetype/docs/reference/ft2-truetype_engine.html
> freetype/docs/reference/ft2-truetype_tables.html
> freetype/docs/reference/ft2-tt_driver.html
> freetype/docs/reference/ft2-type1_tables.html
> freetype/docs/reference/ft2-user_allocation.html
> freetype/docs/reference/ft2-version.html
> freetype/docs/reference/ft2-winfnt_fonts.html
> freetype/docs/release
> freetype/include/config/ftconfig.h
> freetype/include/config/ftheader.h
> freetype/include/config/ftmodule.h
> freetype/include/config/ftoption.h
> freetype/include/config/ftstdlib.h
> freetype/include/freetype.h
> freetype/include/freetype/config/ftconfig.h
> freetype/include/freetype/config/ftheader.h
> freetype/include/freetype/config/ftmodule.h
> freetype/include/freetype/config/ftoption.h
> freetype/include/freetype/config/ftstdlib.h
> freetype/include/freetype/freetype.h
> freetype/include/freetype/ftadvanc.h
> freetype/include/freetype/ftautoh.h
> freetype/include/freetype/ftbbox.h
> freetype/include/freetype/ftbdf.h
> freetype/include/freetype/ftbitmap.h
> freetype/include/freetype/ftbzip2.h
> freetype/include/freetype/ftcache.h
> freetype/include/freetype/ftcffdrv.h
> freetype/include/freetype/ftchapters.h
> freetype/include/freetype/ftcid.h
> freetype/include/freetype/fterrdef.h
> freetype/include/freetype/fterrors.h
> freetype/include/freetype/ftfntfmt.h
> freetype/include/freetype/ftgasp.h
> freetype/include/freetype/ftglyph.h
> freetype/include/freetype/ftgxval.h
> freetype/include/freetype/ftgzip.h
> freetype/include/freetype/ftimage.h
> freetype/include/freetype/ftincrem.h
> freetype/include/freetype/ftlcdfil.h
> freetype/include/freetype/ftlist.h
> freetype/include/freetype/ftlzw.h
> freetype/include/freetype/ftmac.h
> freetype/include/freetype/ftmm.h
> freetype/include/freetype/ftmodapi.h
> freetype/include/freetype/ftmoderr.h
> freetype/include/freetype/ftotval.h
> freetype/include/freetype/ftoutln.h
> freetype/include/freetype/ftpfr.h
> freetype/include/freetype/ftrender.h
> freetype/include/freetype/ftsizes.h
> freetype/include/freetype/ftsnames.h
> freetype/include/freetype/ftstroke.h
> freetype/include/freetype/ftsynth.h
> freetype/include/freetype/ftsystem.h
> freetype/include/freetype/fttrigon.h
> freetype/include/freetype/ftttdrv.h
> freetype/include/freetype/fttypes.h
> freetype/include/freetype/ftwinfnt.h
> freetype/include/freetype/internal/autohint.h
> freetype/include/freetype/internal/ftcalc.h
> freetype/include/freetype/internal/ftdebug.h
> freetype/include/freetype/internal/ftdriver.h
> freetype/include/freetype/internal/ftgloadr.h
> freetype/include/freetype/internal/fthash.h
> freetype/include/freetype/internal/ftmemory.h
> freetype/include/freetype/internal/ftobjs.h
> freetype/include/freetype/internal/ftpic.h
> freetype/include/freetype/internal/ftrfork.h
> freetype/include/freetype/internal/ftserv.h
> freetype/include/freetype/internal/ftstream.h
> freetype/include/freetype/internal/fttrace.h
> freetype/include/freetype/internal/ftvalid.h
> freetype/include/freetype/internal/internal.h
> freetype/include/freetype/internal/psaux.h
> freetype/include/freetype/internal/pshints.h
> freetype/include/freetype/internal/services/svbdf.h
> freetype/include/freetype/internal/services/svcid.h
> freetype/include/freetype/internal/services/svfntfmt.h
> freetype/include/freetype/internal/services/svgldict.h
> freetype/include/freetype/internal/services/svgxval.h
> freetype/include/freetype/internal/services/svkern.h
> freetype/include/freetype/internal/services/svmm.h
> freetype/include/freetype/internal/services/svotval.h
> freetype/include/freetype/internal/services/svpfr.h
> freetype/include/freetype/internal/services/svpostnm.h
> freetype/include/freetype/internal/services/svprop.h
> freetype/include/freetype/internal/services/svpscmap.h
> freetype/include/freetype/internal/services/svpsinfo.h
> freetype/include/freetype/internal/services/svsfnt.h
> freetype/include/freetype/internal/services/svttcmap.h
> freetype/include/freetype/internal/services/svtteng.h
> freetype/include/freetype/internal/services/svttglyf.h
> freetype/include/freetype/internal/services/svwinfnt.h
> freetype/include/freetype/internal/sfnt.h
> freetype/include/freetype/internal/t1types.h
> freetype/include/freetype/internal/tttypes.h
> freetype/include/freetype/t1tables.h
> freetype/include/freetype/ttnameid.h
> freetype/include/freetype/tttables.h
> freetype/include/freetype/tttags.h
> freetype/include/freetype/ttunpat.h
> freetype/include/ft2build.h
> freetype/include/ftadvanc.h
> freetype/include/ftautoh.h
> freetype/include/ftbbox.h
> freetype/include/ftbdf.h
> freetype/include/ftbitmap.h
> freetype/include/ftbzip2.h
> freetype/include/ftcache.h
> freetype/include/ftcffdrv.h
> freetype/include/ftchapters.h
> freetype/include/ftcid.h
> freetype/include/fterrdef.h
> freetype/include/fterrors.h
> freetype/include/ftgasp.h
> freetype/include/ftglyph.h
> freetype/include/ftgxval.h
> freetype/include/ftgzip.h
> freetype/include/ftimage.h
> freetype/include/ftincrem.h
> freetype/include/ftlcdfil.h
> freetype/include/ftlist.h
> freetype/include/ftlzw.h
> freetype/include/ftmac.h
> freetype/include/ftmm.h
> freetype/include/ftmodapi.h
> freetype/include/ftmoderr.h
> freetype/include/ftotval.h
> freetype/include/ftoutln.h
> freetype/include/ftpfr.h
> freetype/include/ftrender.h
> freetype/include/ftsizes.h
> freetype/include/ftsnames.h
> freetype/include/ftstroke.h
> freetype/include/ftsynth.h
> freetype/include/ftsystem.h
> freetype/include/fttrigon.h
> freetype/include/ftttdrv.h
> freetype/include/fttypes.h
> freetype/include/ftwinfnt.h
> freetype/include/ftxf86.h
> freetype/include/internal/autohint.h
> freetype/include/internal/ftcalc.h
> freetype/include/internal/ftdebug.h
> freetype/include/internal/ftdriver.h
> freetype/include/internal/ftgloadr.h
> freetype/include/internal/ftmemory.h
> freetype/include/internal/ftobjs.h
> freetype/include/internal/ftpic.h
> freetype/include/internal/ftrfork.h
> freetype/include/internal/ftserv.h
> freetype/include/internal/ftstream.h
> freetype/include/internal/fttrace.h
> freetype/include/internal/ftvalid.h
> freetype/include/internal/internal.h
> freetype/include/internal/psaux.h
> freetype/include/internal/pshints.h
> freetype/include/internal/services/svbdf.h
> freetype/include/internal/services/svcid.h
> freetype/include/internal/services/svgldict.h
> freetype/include/internal/services/svgxval.h
> freetype/include/internal/services/svkern.h
> freetype/include/internal/services/svmm.h
> freetype/include/internal/services/svotval.h
> freetype/include/internal/services/svpfr.h
> freetype/include/internal/services/svpostnm.h
> freetype/include/internal/services/svprop.h
> freetype/include/internal/services/svpscmap.h
> freetype/include/internal/services/svpsinfo.h
> freetype/include/internal/services/svsfnt.h
> freetype/include/internal/services/svttcmap.h
> freetype/include/internal/services/svtteng.h
> freetype/include/internal/services/svttglyf.h
> freetype/include/internal/services/svwinfnt.h
> freetype/include/internal/services/svxf86nm.h
> freetype/include/internal/sfnt.h
> freetype/include/internal/t1types.h
> freetype/include/internal/tttypes.h
> freetype/include/t1tables.h
> freetype/include/ttnameid.h
> freetype/include/tttables.h
> freetype/include/tttags.h
> freetype/include/ttunpat.h
> freetype/modules.cfg
> freetype/src/Jamfile
> freetype/src/autofit/Jamfile
> freetype/src/autofit/afangles.c
> freetype/src/autofit/afblue.c
> freetype/src/autofit/afblue.cin
> freetype/src/autofit/afblue.dat
> freetype/src/autofit/afblue.h
> freetype/src/autofit/afblue.hin
> freetype/src/autofit/afcjk.c
> freetype/src/autofit/afcjk.h
> freetype/src/autofit/afcover.h
> freetype/src/autofit/afdummy.c
> freetype/src/autofit/afdummy.h
> freetype/src/autofit/aferrors.h
> freetype/src/autofit/afglobal.c
> freetype/src/autofit/afglobal.h
> freetype/src/autofit/afhints.c
> freetype/src/autofit/afhints.h
> freetype/src/autofit/afindic.c
> freetype/src/autofit/afindic.h
> freetype/src/autofit/aflatin.c
> freetype/src/autofit/aflatin.h
> freetype/src/autofit/aflatin2.c
> freetype/src/autofit/aflatin2.h
> freetype/src/autofit/afloader.c
> freetype/src/autofit/afloader.h
> freetype/src/autofit/afmodule.c
> freetype/src/autofit/afmodule.h
> freetype/src/autofit/afpic.c
> freetype/src/autofit/afpic.h
> freetype/src/autofit/afranges.c
> freetype/src/autofit/afranges.h
> freetype/src/autofit/afscript.h
> freetype/src/autofit/afshaper.c
> freetype/src/autofit/afshaper.h
> freetype/src/autofit/afstyles.h
> freetype/src/autofit/aftypes.h
> freetype/src/autofit/afwarp.c
> freetype/src/autofit/afwarp.h
> freetype/src/autofit/afwrtsys.h
> freetype/src/autofit/autofit.c
> freetype/src/autofit/hbshim.c
> freetype/src/autofit/hbshim.h
> freetype/src/autofit/module.mk
> freetype/src/autofit/rules.mk
> freetype/src/base/Jamfile
> freetype/src/base/basepic.c
> freetype/src/base/basepic.h
> freetype/src/base/ftadvanc.c
> freetype/src/base/ftapi.c
> freetype/src/base/ftbase.c
> freetype/src/base/ftbase.h
> freetype/src/base/ftbbox.c
> freetype/src/base/ftbdf.c
> freetype/src/base/ftbitmap.c
> freetype/src/base/ftcalc.c
> freetype/src/base/ftcid.c
> freetype/src/base/ftdbgmem.c
> freetype/src/base/ftdebug.c
> freetype/src/base/ftfntfmt.c
> freetype/src/base/ftfstype.c
> freetype/src/base/ftgasp.c
> freetype/src/base/ftgloadr.c
> freetype/src/base/ftglyph.c
> freetype/src/base/ftgxval.c
> freetype/src/base/fthash.c
> freetype/src/base/ftinit.c
> freetype/src/base/ftlcdfil.c
> freetype/src/base/ftmac.c
> freetype/src/base/ftmm.c
> freetype/src/base/ftobjs.c
> freetype/src/base/ftotval.c
> freetype/src/base/ftoutln.c
> freetype/src/base/ftpatent.c
> freetype/src/base/ftpfr.c
> freetype/src/base/ftpic.c
> freetype/src/base/ftrfork.c
> freetype/src/base/ftsnames.c
> freetype/src/base/ftstream.c
> freetype/src/base/ftstroke.c
> freetype/src/base/ftsynth.c
> freetype/src/base/ftsystem.c
> freetype/src/base/fttrigon.c
> freetype/src/base/fttype1.c
> freetype/src/base/ftutil.c
> freetype/src/base/ftwinfnt.c
> freetype/src/base/ftxf86.c
> freetype/src/base/md5.c
> freetype/src/base/rules.mk
> freetype/src/bdf/Jamfile
> freetype/src/bdf/bdf.h
> freetype/src/bdf/bdfdrivr.c
> freetype/src/bdf/bdfdrivr.h
> freetype/src/bdf/bdferror.h
> freetype/src/bdf/bdflib.c
> freetype/src/bdf/rules.mk
> freetype/src/bzip2/Jamfile
> freetype/src/bzip2/ftbzip2.c
> freetype/src/bzip2/rules.mk
> freetype/src/cache/Jamfile
> freetype/src/cache/ftcache.c
> freetype/src/cache/ftcbasic.c
> freetype/src/cache/ftccache.c
> freetype/src/cache/ftccache.h
> freetype/src/cache/ftccback.h
> freetype/src/cache/ftccmap.c
> freetype/src/cache/ftcerror.h
> freetype/src/cache/ftcglyph.c
> freetype/src/cache/ftcglyph.h
> freetype/src/cache/ftcimage.c
> freetype/src/cache/ftcimage.h
> freetype/src/cache/ftcmanag.c
> freetype/src/cache/ftcmanag.h
> freetype/src/cache/ftcmru.c
> freetype/src/cache/ftcmru.h
> freetype/src/cache/ftcsbits.c
> freetype/src/cache/ftcsbits.h
> freetype/src/cache/rules.mk
> freetype/src/cff/Jamfile
> freetype/src/cff/cf2arrst.c
> freetype/src/cff/cf2arrst.h
> freetype/src/cff/cf2blues.h
> freetype/src/cff/cf2error.h
> freetype/src/cff/cf2fixed.h
> freetype/src/cff/cf2font.h
> freetype/src/cff/cf2ft.c
> freetype/src/cff/cf2ft.h
> freetype/src/cff/cf2glue.h
> freetype/src/cff/cf2hints.c
> freetype/src/cff/cf2hints.h
> freetype/src/cff/cf2intrp.c
> freetype/src/cff/cf2intrp.h
> freetype/src/cff/cf2read.h
> freetype/src/cff/cf2stack.c
> freetype/src/cff/cf2stack.h
> freetype/src/cff/cf2types.h
> freetype/src/cff/cff.c
> freetype/src/cff/cffcmap.c
> freetype/src/cff/cffcmap.h
> freetype/src/cff/cffdrivr.c
> freetype/src/cff/cffdrivr.h
> freetype/src/cff/cfferrs.h
> freetype/src/cff/cffgload.c
> freetype/src/cff/cffgload.h
> freetype/src/cff/cffload.c
> freetype/src/cff/cffload.h
> freetype/src/cff/cffobjs.c
> freetype/src/cff/cffobjs.h
> freetype/src/cff/cffparse.c
> freetype/src/cff/cffparse.h
> freetype/src/cff/cffpic.c
> freetype/src/cff/cffpic.h
> freetype/src/cff/cfftoken.h
> freetype/src/cff/cfftypes.h
> freetype/src/cff/module.mk
> freetype/src/cff/rules.mk
> freetype/src/cid/Jamfile
> freetype/src/cid/ciderrs.h
> freetype/src/cid/cidgload.c
> freetype/src/cid/cidgload.h
> freetype/src/cid/cidload.c
> freetype/src/cid/cidload.h
> freetype/src/cid/cidobjs.c
> freetype/src/cid/cidobjs.h
> freetype/src/cid/cidparse.c
> freetype/src/cid/cidparse.h
> freetype/src/cid/cidriver.c
> freetype/src/cid/cidriver.h
> freetype/src/cid/cidtoken.h
> freetype/src/cid/module.mk
> freetype/src/cid/rules.mk
> freetype/src/cid/type1cid.c
> freetype/src/gxvalid/Jamfile
> freetype/src/gxvalid/README
> freetype/src/gxvalid/gxvalid.c
> freetype/src/gxvalid/gxvalid.h
> freetype/src/gxvalid/gxvbsln.c
> freetype/src/gxvalid/gxvcommn.c
> freetype/src/gxvalid/gxvcommn.h
> freetype/src/gxvalid/gxverror.h
> freetype/src/gxvalid/gxvfeat.c
> freetype/src/gxvalid/gxvfeat.h
> freetype/src/gxvalid/gxvfgen.c
> freetype/src/gxvalid/gxvjust.c
> freetype/src/gxvalid/gxvkern.c
> freetype/src/gxvalid/gxvlcar.c
> freetype/src/gxvalid/gxvmod.c
> freetype/src/gxvalid/gxvmod.h
> freetype/src/gxvalid/gxvmort.c
> freetype/src/gxvalid/gxvmort.h
> freetype/src/gxvalid/gxvmort0.c
> freetype/src/gxvalid/gxvmort1.c
> freetype/src/gxvalid/gxvmort2.c
> freetype/src/gxvalid/gxvmort4.c
> freetype/src/gxvalid/gxvmort5.c
> freetype/src/gxvalid/gxvmorx.c
> freetype/src/gxvalid/gxvmorx.h
> freetype/src/gxvalid/gxvmorx0.c
> freetype/src/gxvalid/gxvmorx1.c
> freetype/src/gxvalid/gxvmorx2.c
> freetype/src/gxvalid/gxvmorx4.c
> freetype/src/gxvalid/gxvmorx5.c
> freetype/src/gxvalid/gxvopbd.c
> freetype/src/gxvalid/gxvprop.c
> freetype/src/gxvalid/gxvtrak.c
> freetype/src/gxvalid/module.mk
> freetype/src/gxvalid/rules.mk
> freetype/src/gzip/Jamfile
> freetype/src/gzip/ftgzip.c
> freetype/src/gzip/rules.mk
> freetype/src/gzip/zlib.h
> freetype/src/lzw/Jamfile
> freetype/src/lzw/ftlzw.c
> freetype/src/lzw/ftzopen.c
> freetype/src/lzw/ftzopen.h
> freetype/src/lzw/rules.mk
> freetype/src/otvalid/Jamfile
> freetype/src/otvalid/module.mk
> freetype/src/otvalid/otvalid.c
> freetype/src/otvalid/otvalid.h
> freetype/src/otvalid/otvbase.c
> freetype/src/otvalid/otvcommn.c
> freetype/src/otvalid/otvcommn.h
> freetype/src/otvalid/otverror.h
> freetype/src/otvalid/otvgdef.c
> freetype/src/otvalid/otvgpos.c
> freetype/src/otvalid/otvgpos.h
> freetype/src/otvalid/otvgsub.c
> freetype/src/otvalid/otvjstf.c
> freetype/src/otvalid/otvmath.c
> freetype/src/otvalid/otvmod.c
> freetype/src/otvalid/otvmod.h
> freetype/src/otvalid/rules.mk
> freetype/src/pcf/Jamfile
> freetype/src/pcf/pcf.h
> freetype/src/pcf/pcfdrivr.c
> freetype/src/pcf/pcfdrivr.h
> freetype/src/pcf/pcferror.h
> freetype/src/pcf/pcfread.c
> freetype/src/pcf/pcfread.h
> freetype/src/pcf/pcfutil.h
> freetype/src/pcf/rules.mk
> freetype/src/pfr/Jamfile
> freetype/src/pfr/module.mk
> freetype/src/pfr/pfr.c
> freetype/src/pfr/pfrcmap.c
> freetype/src/pfr/pfrcmap.h
> freetype/src/pfr/pfrdrivr.c
> freetype/src/pfr/pfrdrivr.h
> freetype/src/pfr/pfrerror.h
> freetype/src/pfr/pfrgload.c
> freetype/src/pfr/pfrgload.h
> freetype/src/pfr/pfrload.c
> freetype/src/pfr/pfrload.h
> freetype/src/pfr/pfrobjs.c
> freetype/src/pfr/pfrobjs.h
> freetype/src/pfr/pfrsbit.c
> freetype/src/pfr/pfrsbit.h
> freetype/src/pfr/pfrtypes.h
> freetype/src/pfr/rules.mk
> freetype/src/psaux/Jamfile
> freetype/src/psaux/afmparse.c
> freetype/src/psaux/afmparse.h
> freetype/src/psaux/module.mk
> freetype/src/psaux/psaux.c
> freetype/src/psaux/psauxerr.h
> freetype/src/psaux/psauxmod.c
> freetype/src/psaux/psauxmod.h
> freetype/src/psaux/psconv.c
> freetype/src/psaux/psconv.h
> freetype/src/psaux/psobjs.c
> freetype/src/psaux/psobjs.h
> freetype/src/psaux/rules.mk
> freetype/src/psaux/t1cmap.c
> freetype/src/psaux/t1cmap.h
> freetype/src/psaux/t1decode.c
> freetype/src/psaux/t1decode.h
> freetype/src/pshinter/Jamfile
> freetype/src/pshinter/module.mk
> freetype/src/pshinter/pshalgo.c
> freetype/src/pshinter/pshalgo.h
> freetype/src/pshinter/pshglob.c
> freetype/src/pshinter/pshglob.h
> freetype/src/pshinter/pshinter.c
> freetype/src/pshinter/pshmod.c
> freetype/src/pshinter/pshmod.h
> freetype/src/pshinter/pshnterr.h
> freetype/src/pshinter/pshpic.c
> freetype/src/pshinter/pshpic.h
> freetype/src/pshinter/pshrec.c
> freetype/src/pshinter/pshrec.h
> freetype/src/pshinter/rules.mk
> freetype/src/psnames/Jamfile
> freetype/src/psnames/module.mk
> freetype/src/psnames/psmodule.c
> freetype/src/psnames/psmodule.h
> freetype/src/psnames/psnamerr.h
> freetype/src/psnames/psnames.c
> freetype/src/psnames/pspic.c
> freetype/src/psnames/pspic.h
> freetype/src/psnames/pstables.h
> freetype/src/psnames/rules.mk
> freetype/src/raster/Jamfile
> freetype/src/raster/ftmisc.h
> freetype/src/raster/ftraster.c
> freetype/src/raster/ftraster.h
> freetype/src/raster/ftrend1.c
> freetype/src/raster/ftrend1.h
> freetype/src/raster/module.mk
> freetype/src/raster/raster.c
> freetype/src/raster/rasterrs.h
> freetype/src/raster/rastpic.c
> freetype/src/raster/rastpic.h
> freetype/src/raster/rules.mk
> freetype/src/sfnt/Jamfile
> freetype/src/sfnt/module.mk
> freetype/src/sfnt/pngshim.c
> freetype/src/sfnt/pngshim.h
> freetype/src/sfnt/rules.mk
> freetype/src/sfnt/sfdriver.c
> freetype/src/sfnt/sfdriver.h
> freetype/src/sfnt/sferrors.h
> freetype/src/sfnt/sfnt.c
> freetype/src/sfnt/sfntpic.c
> freetype/src/sfnt/sfntpic.h
> freetype/src/sfnt/sfobjs.c
> freetype/src/sfnt/sfobjs.h
> freetype/src/sfnt/ttbdf.c
> freetype/src/sfnt/ttbdf.h
> freetype/src/sfnt/ttcmap.c
> freetype/src/sfnt/ttcmap.h
> freetype/src/sfnt/ttcmapc.h
> freetype/src/sfnt/ttkern.c
> freetype/src/sfnt/ttkern.h
> freetype/src/sfnt/ttload.c
> freetype/src/sfnt/ttload.h
> freetype/src/sfnt/ttmtx.c
> freetype/src/sfnt/ttmtx.h
> freetype/src/sfnt/ttpost.c
> freetype/src/sfnt/ttpost.h
> freetype/src/sfnt/ttsbit.c
> freetype/src/sfnt/ttsbit.h
> freetype/src/smooth/Jamfile
> freetype/src/smooth/ftgrays.c
> freetype/src/smooth/ftgrays.h
> freetype/src/smooth/ftsmerrs.h
> freetype/src/smooth/ftsmooth.c
> freetype/src/smooth/ftsmooth.h
> freetype/src/smooth/ftspic.c
> freetype/src/smooth/ftspic.h
> freetype/src/smooth/module.mk
> freetype/src/smooth/rules.mk
> freetype/src/smooth/smooth.c
> freetype/src/tools/afblue.pl
> freetype/src/tools/apinames.c
> freetype/src/tools/chktrcmp.py
> freetype/src/tools/docmaker/content.py
> freetype/src/tools/docmaker/docmaker.py
> freetype/src/tools/docmaker/formatter.py
> freetype/src/tools/docmaker/sources.py
> freetype/src/tools/docmaker/tohtml.py
> freetype/src/tools/docmaker/utils.py
> freetype/src/tools/ftfuzzer/README
> freetype/src/tools/ftfuzzer/ftfuzzer.cc
> freetype/src/tools/ftfuzzer/ftmutator.cc
> freetype/src/tools/ftfuzzer/rasterfuzzer.cc
> freetype/src/tools/ftfuzzer/runinput.cc
> freetype/src/tools/ftrandom/Makefile
> freetype/src/tools/ftrandom/README
> freetype/src/tools/ftrandom/ftrandom.c
> freetype/src/tools/glnames.py
> freetype/src/tools/no-copyright
> freetype/src/tools/test_afm.c
> freetype/src/tools/update-copyright
> freetype/src/tools/update-copyright-year
> freetype/src/truetype/Jamfile
> freetype/src/truetype/module.mk
> freetype/src/truetype/rules.mk
> freetype/src/truetype/truetype.c
> freetype/src/truetype/ttdriver.c
> freetype/src/truetype/ttdriver.h
> freetype/src/truetype/tterrors.h
> freetype/src/truetype/ttgload.c
> freetype/src/truetype/ttgload.h
> freetype/src/truetype/ttgxvar.c
> freetype/src/truetype/ttgxvar.h
> freetype/src/truetype/ttinterp.c
> freetype/src/truetype/ttinterp.h
> freetype/src/truetype/ttobjs.c
> freetype/src/truetype/ttobjs.h
> freetype/src/truetype/ttpic.c
> freetype/src/truetype/ttpic.h
> freetype/src/truetype/ttpload.c
> freetype/src/truetype/ttpload.h
> freetype/src/truetype/ttsubpix.c
> freetype/src/truetype/ttsubpix.h
> freetype/src/type1/Jamfile
> freetype/src/type1/module.mk
> freetype/src/type1/rules.mk
> freetype/src/type1/t1afm.c
> freetype/src/type1/t1afm.h
> freetype/src/type1/t1driver.c
> freetype/src/type1/t1driver.h
> freetype/src/type1/t1errors.h
> freetype/src/type1/t1gload.c
> freetype/src/type1/t1gload.h
> freetype/src/type1/t1load.c
> freetype/src/type1/t1load.h
> freetype/src/type1/t1objs.c
> freetype/src/type1/t1objs.h
> freetype/src/type1/t1parse.c
> freetype/src/type1/t1parse.h
> freetype/src/type1/t1tokens.h
> freetype/src/type1/type1.c
> freetype/src/type42/Jamfile
> freetype/src/type42/module.mk
> freetype/src/type42/rules.mk
> freetype/src/type42/t42drivr.c
> freetype/src/type42/t42drivr.h
> freetype/src/type42/t42error.h
> freetype/src/type42/t42objs.c
> freetype/src/type42/t42objs.h
> freetype/src/type42/t42parse.c
> freetype/src/type42/t42parse.h
> freetype/src/type42/t42types.h
> freetype/src/type42/type42.c
> freetype/src/winfonts/Jamfile
> freetype/src/winfonts/fnterrs.h
> freetype/src/winfonts/module.mk
> freetype/src/winfonts/rules.mk
> freetype/src/winfonts/winfnt.c
> freetype/src/winfonts/winfnt.h
> freetype/vms_make.com

2016-11-15 09:58:58 +0000
Chris Liddell <chris.liddell@artifex.com>
99c6a18eb430a9091c79369b2bdd2952d481c7d5

> Document use of string for subsituted CIDFont name
> Add a comment and example at the top of cidfmap with details of dealing with
> CIDFont names with spaces in them.
> Resource/Init/cidfmap

2016-11-07 14:52:28 +0000
Chris Liddell <chris.liddell@artifex.com>
23dc144b3c3d3dbafd83dca7b9c09e6977b774d6

> Update lcms2 to 2.8
> Tweak makefile for lcms2 2.8
> Delete mac file system specific files from lcms2 tree
> Bug 697056: Fix LCMS static init of critical section.
> LCMS2 relies on being able to statically init a mutex
> (actually a Critical Section on windows). Windows has
> no official API for statically initing a critical
> section, so lcms2 uses a hack (albeit it a safe one)
> to do this.
> Unfortunately ApplicationVerifier (and presumably other
> similar tools) don't understand this idiom, and get
> confused by not seeing an explicit initialisation call.
> This is causing problems for a customer.
> This commit therefore introduces code to properly
> initialise it on Windows. In order to avoid any possible
> multithreaded startup issues, we use the Windows
> InterlockedCompareExchangePointer API (introduced in
> Windows XP).
> If anyone wants to avoid this code (so they can work
> on pre-Windows XP), they can build with:
> CMS_RELY_ON_WINDOWS_STATIC_MUTEX_INIT
> defined, and get the old behaviour. We automatically
> set this when building with any version of MSVC older
> than VS2005 (i.e. those that don't have that API
> available).
> base/lcms2.mak
> lcms2/AUTHORS
> lcms2/ChangeLog
> lcms2/Makefile.am
> lcms2/Makefile.in
> lcms2/Projects/BorlandC_5.5/lcms2.rc
> lcms2/Projects/BorlandC_5.5/lcmsdll.lst
> lcms2/Projects/VC2008/jpegicc/jpegicc.vcproj
> lcms2/Projects/VC2008/lcms2.rc
> lcms2/Projects/VC2008/lcms2.sln
> lcms2/Projects/VC2008/lcms2_DLL/lcms2_DLL.vcproj
> lcms2/Projects/VC2008/lcms2_static/lcms2_static.vcproj
> lcms2/Projects/VC2008/linkicc/linkicc.vcproj
> lcms2/Projects/VC2008/psicc/psicc.vcproj
> lcms2/Projects/VC2008/resource.h
> lcms2/Projects/VC2008/testbed/testbed.vcproj
> lcms2/Projects/VC2008/tiffdiff/tiffdiff.vcproj
> lcms2/Projects/VC2008/tifficc/tifficc.vcproj
> lcms2/Projects/VC2008/transicc/transicc.vcproj
> lcms2/Projects/VC2010/jpegicc/jpegicc.vcproj
> lcms2/Projects/VC2010/jpegicc/jpegicc.vcxproj
> lcms2/Projects/VC2010/lcms2.rc
> lcms2/Projects/VC2010/lcms2.sln
> lcms2/Projects/VC2010/lcms2_DLL/lcms2_DLL.vcproj
> lcms2/Projects/VC2010/lcms2_static/lcms2_static.vcproj
> lcms2/Projects/VC2010/linkicc/linkicc.vcproj
> lcms2/Projects/VC2010/psicc/psicc.vcproj
> lcms2/Projects/VC2010/testbed/testbed.vcproj
> lcms2/Projects/VC2010/tiffdiff/tiffdiff.vcproj
> lcms2/Projects/VC2010/tifficc/tifficc.vcproj
> lcms2/Projects/VC2010/transicc/transicc.vcproj
> lcms2/Projects/VC2012/jpegicc/jpegicc.vcproj
> lcms2/Projects/VC2012/jpegicc/jpegicc.vcxproj
> lcms2/Projects/VC2012/jpegicc/jpegicc.vcxproj.filters
> lcms2/Projects/VC2012/lcms2.rc
> lcms2/Projects/VC2012/lcms2.sln
> lcms2/Projects/VC2012/lcms2_DLL/lcms2_DLL.vcproj
> lcms2/Projects/VC2012/lcms2_DLL/lcms2_DLL.vcxproj
> lcms2/Projects/VC2012/lcms2_DLL/lcms2_DLL.vcxproj.filters
> lcms2/Projects/VC2012/lcms2_static/lcms2_static.vcproj
> lcms2/Projects/VC2012/lcms2_static/lcms2_static.vcxproj
> lcms2/Projects/VC2012/lcms2_static/lcms2_static.vcxproj.filters
> lcms2/Projects/VC2012/linkicc/linkicc.vcproj
> lcms2/Projects/VC2012/linkicc/linkicc.vcxproj
> lcms2/Projects/VC2012/linkicc/linkicc.vcxproj.filters
> lcms2/Projects/VC2012/psicc/psicc.vcproj
> lcms2/Projects/VC2012/psicc/psicc.vcxproj
> lcms2/Projects/VC2012/psicc/psicc.vcxproj.filters
> lcms2/Projects/VC2012/resource.h
> lcms2/Projects/VC2012/testbed/testbed.vcproj
> lcms2/Projects/VC2012/testbed/testbed.vcxproj
> lcms2/Projects/VC2012/testbed/testbed.vcxproj.filters
> lcms2/Projects/VC2012/tiffdiff/tiffdiff.vcproj
> lcms2/Projects/VC2012/tiffdiff/tiffdiff.vcxproj
> lcms2/Projects/VC2012/tiffdiff/tiffdiff.vcxproj.filters
> lcms2/Projects/VC2012/tifficc/tifficc.vcproj
> lcms2/Projects/VC2012/tifficc/tifficc.vcxproj
> lcms2/Projects/VC2012/tifficc/tifficc.vcxproj.filters
> lcms2/Projects/VC2012/transicc/transicc.vcproj
> lcms2/Projects/VC2012/transicc/transicc.vcxproj
> lcms2/Projects/VC2012/transicc/transicc.vcxproj.filters
> lcms2/Projects/VC2013/jpegicc/jpegicc.vcxproj
> lcms2/Projects/VC2013/jpegicc/jpegicc.vcxproj.filters
> lcms2/Projects/VC2013/lcms2.rc
> lcms2/Projects/VC2013/lcms2.sln
> lcms2/Projects/VC2013/lcms2_DLL/lcms2_DLL.vcxproj
> lcms2/Projects/VC2013/lcms2_DLL/lcms2_DLL.vcxproj.filters
> lcms2/Projects/VC2013/lcms2_static/lcms2_static.vcxproj
> lcms2/Projects/VC2013/lcms2_static/lcms2_static.vcxproj.filters
> lcms2/Projects/VC2013/linkicc/linkicc.vcxproj
> lcms2/Projects/VC2013/linkicc/linkicc.vcxproj.filters
> lcms2/Projects/VC2013/psicc/psicc.vcxproj
> lcms2/Projects/VC2013/psicc/psicc.vcxproj.filters
> lcms2/Projects/VC2013/resource.h
> lcms2/Projects/VC2013/testbed/testbed.vcxproj
> lcms2/Projects/VC2013/testbed/testbed.vcxproj.filters
> lcms2/Projects/VC2013/tiffdiff/tiffdiff.vcxproj
> lcms2/Projects/VC2013/tiffdiff/tiffdiff.vcxproj.filters
> lcms2/Projects/VC2013/tifficc/tifficc.vcxproj
> lcms2/Projects/VC2013/tifficc/tifficc.vcxproj.filters
> lcms2/Projects/VC2013/transicc/transicc.vcxproj
> lcms2/Projects/VC2013/transicc/transicc.vcxproj.filters
> lcms2/Projects/VC2015/jpegicc/jpegicc.vcxproj
> lcms2/Projects/VC2015/jpegicc/jpegicc.vcxproj.filters
> lcms2/Projects/VC2015/lcms2.rc
> lcms2/Projects/VC2015/lcms2.sln
> lcms2/Projects/VC2015/lcms2_DLL/lcms2_DLL.vcxproj
> lcms2/Projects/VC2015/lcms2_DLL/lcms2_DLL.vcxproj.filters
> lcms2/Projects/VC2015/lcms2_static/lcms2_static.vcxproj
> lcms2/Projects/VC2015/lcms2_static/lcms2_static.vcxproj.filters
> lcms2/Projects/VC2015/linkicc/linkicc.vcxproj
> lcms2/Projects/VC2015/linkicc/linkicc.vcxproj.filters
> lcms2/Projects/VC2015/psicc/psicc.vcxproj
> lcms2/Projects/VC2015/psicc/psicc.vcxproj.filters
> lcms2/Projects/VC2015/resource.h
> lcms2/Projects/VC2015/testbed/testbed.vcxproj
> lcms2/Projects/VC2015/testbed/testbed.vcxproj.filters
> lcms2/Projects/VC2015/tiffdiff/tiffdiff.vcxproj
> lcms2/Projects/VC2015/tiffdiff/tiffdiff.vcxproj.filters
> lcms2/Projects/VC2015/tifficc/tifficc.vcxproj
> lcms2/Projects/VC2015/tifficc/tifficc.vcxproj.filters
> lcms2/Projects/VC2015/transicc/transicc.vcxproj
> lcms2/Projects/VC2015/transicc/transicc.vcxproj.filters
> lcms2/Projects/cppcheck/lcms2.cppcheck
> lcms2/Projects/mac/LittleCMS/._Info.plist
> lcms2/Projects/mac/LittleCMS/._LittleCMS.xcodeproj
> lcms2/Projects/mac/LittleCMS/English.lproj/InfoPlist.strings
> lcms2/Projects/mac/LittleCMS/Info.plist
> lcms2/Projects/mac/LittleCMS/LittleCMS.xcodeproj/mariama.mode1v3
> lcms2/Projects/mac/LittleCMS/LittleCMS.xcodeproj/mariama.pbxuser
> lcms2/Projects/mac/LittleCMS/LittleCMS.xcodeproj/project.pbxproj
> lcms2/Projects/mac/LittleCMS/LittleCMS.xcodeproj/project.xcworkspace/contents.xcworkspacedata
> lcms2/Projects/mac/LittleCMS/LittleCMS.xcodeproj/project.xcworkspace/xcuserdata/User.xcuserdatad/UserInterfaceState.xcuserstate
> lcms2/Projects/mac/LittleCMS/LittleCMS.xcodeproj/project.xcworkspace/xcuserdata/User.xcuserdatad/WorkspaceSettings.xcsettings
> lcms2/Projects/mac/LittleCMS/LittleCMS.xcodeproj/xcuserdata/User.xcuserdatad/xcdebugger/Breakpoints.xcbkptlist
> lcms2/Projects/mac/LittleCMS/LittleCMS.xcodeproj/xcuserdata/User.xcuserdatad/xcschemes/LittleCMS.xcscheme
> lcms2/Projects/mac/LittleCMS/LittleCMS.xcodeproj/xcuserdata/User.xcuserdatad/xcschemes/testbed.xcscheme
> lcms2/Projects/mac/LittleCMS/LittleCMS.xcodeproj/xcuserdata/User.xcuserdatad/xcschemes/xcschememanagement.plist
> lcms2/Projects/mac/LittleCMS/LittleCMS_Prefix.pch
> lcms2/Projects/mac/LittleCMS/TestBed-Info.plist
> lcms2/aclocal.m4
> lcms2/autogen.sh
> lcms2/compile
> lcms2/config.guess
> lcms2/config.sub
> lcms2/configure
> lcms2/configure.ac
> lcms2/depcomp
> lcms2/doc/LittleCMS2.6 API.pdf
> lcms2/doc/LittleCMS2.6 Plugin API.pdf
> lcms2/doc/LittleCMS2.6 tutorial.pdf
> lcms2/doc/LittleCMS2.8 API.pdf
> lcms2/doc/LittleCMS2.8 Plugin API.pdf
> lcms2/doc/LittleCMS2.8 tutorial.pdf
> lcms2/doc/src.zip
> lcms2/include/Makefile.in
> lcms2/include/lcms2.h
> lcms2/include/lcms2_plugin.h
> lcms2/install-sh
> lcms2/ltmain.sh
> lcms2/m4/acx_pthread.m4
> lcms2/m4/libtool.m4
> lcms2/m4/ltoptions.m4
> lcms2/m4/ltsugar.m4
> lcms2/m4/ltversion.m4
> lcms2/m4/lt~obsolete.m4
> lcms2/missing
> lcms2/src/Makefile.am
> lcms2/src/Makefile.in
> lcms2/src/cmsalpha.c
> lcms2/src/cmscam02.c
> lcms2/src/cmscgats.c
> lcms2/src/cmscnvrt.c
> lcms2/src/cmserr.c
> lcms2/src/cmsgamma.c
> lcms2/src/cmsgmt.c
> lcms2/src/cmshalf.c
> lcms2/src/cmsintrp.c
> lcms2/src/cmsio0.c
> lcms2/src/cmsio1.c
> lcms2/src/cmslut.c
> lcms2/src/cmsmd5.c
> lcms2/src/cmsmtrx.c
> lcms2/src/cmsnamed.c
> lcms2/src/cmsopt.c
> lcms2/src/cmspack.c
> lcms2/src/cmspcs.c
> lcms2/src/cmsplugin.c
> lcms2/src/cmsps2.c
> lcms2/src/cmssamp.c
> lcms2/src/cmssm.c
> lcms2/src/cmstypes.c
> lcms2/src/cmsvirt.c
> lcms2/src/cmswtpnt.c
> lcms2/src/cmsxform.c
> lcms2/src/extra_xform.h
> lcms2/src/lcms2.def
> lcms2/src/lcms2_internal.h
> lcms2/testbed/Makefile.am
> lcms2/testbed/Makefile.in
> lcms2/testbed/crayons.icc
> lcms2/testbed/ibm-t61.icc
> lcms2/testbed/new.icc
> lcms2/testbed/test1.icc
> lcms2/testbed/test2.icc
> lcms2/testbed/test3.icc
> lcms2/testbed/test4.icc
> lcms2/testbed/test5.icc
> lcms2/testbed/testcms2.c
> lcms2/testbed/testcms2.h
> lcms2/testbed/testplugin.c
> lcms2/testbed/toosmall.icc
> lcms2/testbed/zoo_icc.c
> lcms2/utils/common/utils.h
> lcms2/utils/common/vprf.c
> lcms2/utils/delphi/delphidemo.res
> lcms2/utils/delphi/demo1.dfm
> lcms2/utils/delphi/lcms2.dll
> lcms2/utils/delphi/lcms2dll.pas
> lcms2/utils/jpgicc/LICENSE_iccjpeg
> lcms2/utils/jpgicc/Makefile.am
> lcms2/utils/jpgicc/Makefile.in
> lcms2/utils/jpgicc/iccjpeg.c
> lcms2/utils/jpgicc/jpgicc.1
> lcms2/utils/jpgicc/jpgicc.c
> lcms2/utils/linkicc/Makefile.am
> lcms2/utils/linkicc/Makefile.in
> lcms2/utils/linkicc/linkicc.1
> lcms2/utils/linkicc/linkicc.c
> lcms2/utils/psicc/Makefile.am
> lcms2/utils/psicc/Makefile.in
> lcms2/utils/psicc/psicc.1
> lcms2/utils/psicc/psicc.c
> lcms2/utils/samples/Makefile.am
> lcms2/utils/samples/roundtrip.c
> lcms2/utils/samples/wtpt.c
> lcms2/utils/tificc/Makefile.am
> lcms2/utils/tificc/Makefile.in
> lcms2/utils/tificc/tifdiff.c
> lcms2/utils/tificc/tificc.1
> lcms2/utils/tificc/tificc.c
> lcms2/utils/transicc/Makefile.am
> lcms2/utils/transicc/Makefile.in
> lcms2/utils/transicc/transicc.1
> lcms2/utils/transicc/transicc.c

2016-11-07 10:42:05 +0000
Chris Liddell <chris.liddell@artifex.com>
64ad2a92195fd05e9ba34995ae994eb250fc9c7c

> Update libpng to 1.6.26
> libpng/ANNOUNCE
> libpng/CHANGES
> libpng/CMakeLists.txt
> libpng/INSTALL
> libpng/LICENSE
> libpng/Makefile.am
> libpng/Makefile.in
> libpng/README
> libpng/TODO
> libpng/arm/arm_init.c
> libpng/arm/filter_neon_intrinsics.c
> libpng/autogen.sh
> libpng/config.h.in
> libpng/configure
> libpng/configure.ac
> libpng/contrib/README.txt
> libpng/contrib/arm-neon/README
> libpng/contrib/arm-neon/linux-auxv.c
> libpng/contrib/arm-neon/linux.c
> libpng/contrib/conftest/pngcp.dfa
> libpng/contrib/examples/README.txt
> libpng/contrib/examples/iccfrompng.c
> libpng/contrib/examples/pngpixel.c
> libpng/contrib/examples/pngtopng.c
> libpng/contrib/examples/simpleover.c
> libpng/contrib/gregbook/README
> libpng/contrib/gregbook/readpng2.c
> libpng/contrib/gregbook/rpng-win.c
> libpng/contrib/gregbook/rpng2-win.c
> libpng/contrib/gregbook/rpng2-x.c
> libpng/contrib/intel/INSTALL
> libpng/contrib/intel/filter_sse2_intrinsics.c
> libpng/contrib/intel/intel_init.c
> libpng/contrib/intel/intel_sse.patch
> libpng/contrib/libtests/fakepng.c
> libpng/contrib/libtests/makepng.c
> libpng/contrib/libtests/pngimage.c
> libpng/contrib/libtests/pngstest-errors.h
> libpng/contrib/libtests/pngstest.c
> libpng/contrib/libtests/pngunknown.c
> libpng/contrib/libtests/pngvalid.c
> libpng/contrib/libtests/readpng.c
> libpng/contrib/libtests/tarith.c
> libpng/contrib/libtests/timepng.c
> libpng/contrib/mips-msa/README
> libpng/contrib/mips-msa/linux.c
> libpng/contrib/pngminus/README
> libpng/contrib/pngminus/png2pnm.c
> libpng/contrib/pngminus/pnm2png.c
> libpng/contrib/pngsuite/README
> libpng/contrib/tools/README.txt
> libpng/contrib/tools/chkfmt
> libpng/contrib/tools/genpng.c
> libpng/contrib/tools/png-fix-itxt.c
> libpng/contrib/tools/pngcp.c
> libpng/contrib/tools/pngfix.c
> libpng/contrib/tools/reindent
> libpng/contrib/visupng/PngFile.c
> libpng/example.c
> libpng/libpng-manual.txt
> libpng/libpng.3
> libpng/libpngpf.3
> libpng/mips/filter_msa_intrinsics.c
> libpng/mips/mips_init.c
> libpng/png.5
> libpng/png.c
> libpng/png.h
> libpng/pngconf.h
> libpng/pngdebug.h
> libpng/pngerror.c
> libpng/pngget.c
> libpng/pnginfo.h
> libpng/pngmem.c
> libpng/pngpread.c
> libpng/pngpriv.h
> libpng/pngread.c
> libpng/pngrio.c
> libpng/pngrtran.c
> libpng/pngrutil.c
> libpng/pngset.c
> libpng/pngstruct.h
> libpng/pngtest.c
> libpng/pngtrans.c
> libpng/pngwio.c
> libpng/pngwrite.c
> libpng/pngwtran.c
> libpng/pngwutil.c
> libpng/projects/vstudio/README.txt
> libpng/projects/vstudio/WARNING
> libpng/projects/vstudio/libpng/libpng.vcxproj
> libpng/projects/vstudio/pnglibconf/pnglibconf.vcxproj
> libpng/projects/vstudio/pngstest/pngstest.vcxproj
> libpng/projects/vstudio/pngtest/pngtest.vcxproj
> libpng/projects/vstudio/pngunknown/pngunknown.vcxproj
> libpng/projects/vstudio/pngvalid/pngvalid.vcxproj
> libpng/projects/vstudio/readme.txt
> libpng/projects/vstudio/zlib.props
> libpng/projects/vstudio/zlib/zlib.vcxproj
> libpng/scripts/README.txt
> libpng/scripts/def.c
> libpng/scripts/genchk.cmake.in
> libpng/scripts/genout.cmake.in
> libpng/scripts/gensrc.cmake.in
> libpng/scripts/libpng-config-head.in
> libpng/scripts/libpng.pc.in
> libpng/scripts/makefile.cegcc
> libpng/scripts/makefile.linux
> libpng/scripts/makefile.msys
> libpng/scripts/makefile.ne12bsd
> libpng/scripts/makefile.netbsd
> libpng/scripts/makefile.openbsd
> libpng/scripts/makefile.sco
> libpng/scripts/pnglibconf.dfa
> libpng/scripts/pnglibconf.h.prebuilt
> libpng/scripts/symbols.def
> libpng/scripts/test.cmake.in
> libpng/tests/pngimage-full
> libpng/tests/pngimage-quick
> libpng/tests/pngstest
> libpng/tests/pngstest-0g01
> libpng/tests/pngstest-0g02
> libpng/tests/pngstest-0g04
> libpng/tests/pngstest-0g08
> libpng/tests/pngstest-0g16
> libpng/tests/pngstest-2c08
> libpng/tests/pngstest-2c16
> libpng/tests/pngstest-3p01
> libpng/tests/pngstest-3p02
> libpng/tests/pngstest-3p04
> libpng/tests/pngstest-3p08
> libpng/tests/pngstest-4a08
> libpng/tests/pngstest-4a16
> libpng/tests/pngstest-6a08
> libpng/tests/pngstest-6a16
> libpng/tests/pngstest-error
> libpng/tests/pngtest
> libpng/tests/pngunknown-IDAT
> libpng/tests/pngunknown-discard
> libpng/tests/pngunknown-if-safe
> libpng/tests/pngunknown-sAPI
> libpng/tests/pngunknown-sTER
> libpng/tests/pngunknown-save
> libpng/tests/pngunknown-vpAg
> libpng/tests/pngvalid-gamma-16-to-8
> libpng/tests/pngvalid-gamma-alpha-mode
> libpng/tests/pngvalid-gamma-background
> libpng/tests/pngvalid-gamma-expand16-alpha-mode
> libpng/tests/pngvalid-gamma-expand16-background
> libpng/tests/pngvalid-gamma-expand16-transform
> libpng/tests/pngvalid-gamma-sbit
> libpng/tests/pngvalid-gamma-threshold
> libpng/tests/pngvalid-gamma-transform
> libpng/tests/pngvalid-progressive-interlace-size
> libpng/tests/pngvalid-progressive-interlace-standard
> libpng/tests/pngvalid-progressive-interlace-transform
> libpng/tests/pngvalid-progressive-standard
> libpng/tests/pngvalid-standard

2016-11-22 09:14:28 +0000
Ken Sharp <ken.sharp@artifex.com>
1b1e7f3f4abf7a97101ff7f4e2389ca2edd9af0a

> PDF Interpreter - ensure /Separation ink names are not indirect objects
> Bug #697358 "PDF interpreter throws an error on a colour space"
> Another bizarre file that thinks its a good idea to reference items
> as indirect objects instead of a simple inclusion. This time its the
> ink name in a /Separation space.
> Simply make sure it is not an indirect object.
> Resource/Init/pdf_draw.ps

2016-10-20 13:53:06 -0700
Michael Vrhel <michael.vrhel@artifex.com>
47294ff5b168d25bfc7db64f51572d64b8ebde91

> Bug 697345 Blend Color Space Support for Separation devices
> This is a rather large commit that brings support for transparency
> blend color spaces to the separation devices. Previously the
> transparency compositor always used CMYK for the blend color space
> if the output device was a separation device.
> With this commit:
> If the blend space is RGB or Gray based, then we now ensure that the
> alternate tint transform is not used when we encounter a separation or DeviceN color space.
> (assuming we have not run out of spot color space at the target device). Note that
> if the any of the spot colors in a DeviceN color space are CMYK process colorants and the
> blend space is Gray or RGB, the alternate tint transform IS used.
> 2) The pdf14 compositor now handles a mixture of additive and subtractive components.
> I.e. RGB + spots or Gray + spots.
> 3) If the blend mode is non white preserving or not separable, then the spot colors
> use the normal blend mode while the process colorants use the specified blend mode.
> 4) In the process there was a bit of code clean up. But much remains to be cleaned.
> base/gdevdevn.c
> base/gdevdevn.h
> base/gdevdsha.c
> base/gdevp14.c
> base/gdevp14.h
> base/gscdevn.c
> base/gscsepr.c
> base/gxblend.c
> base/gxblend.h
> base/gxblend1.c
> base/gxclrast.c
> base/gxcmap.h
> base/gxdcolor.c
> base/gxdevsop.h
> base/gxshade6.c
> base/lib.mak

2016-11-17 16:45:04 +0000
Robin Watts <robin.watts@artifex.com>
c9d8618934ebf682f72dd9b3ebef48b2be535a8d

> Change API for put_image
> base/gdevflp.c
> base/gdevmpla.c
> base/gdevoflt.c
> base/gdevp14.c
> base/gdevsclass.c
> base/gxblend1.c
> base/gxdevcli.h
> devices/gdevbit.c
> devices/gdevpng.c

2016-11-21 15:43:14 +0000
Ken Sharp <ken.sharp@artifex.com>
b33ffc0e958b613cd6ba114d42720694b11219ff

> PDF interpreter - ensure Rect array entries are not indirect objects
> Bug #697357 "Can't handle annots where /Rect entries are indirect"
> The example file has an insanely constructed Rect entry, where not only
> is the /Rect value itself an indirect object, but each of the entries
> in the array is also an indirect object.
> Here we ensure that the entries in a /Rect for an annotation are
> fully resolved.
> Resource/Init/pdf_draw.ps

2016-11-21 11:30:50 +0000
Ken Sharp <ken.sharp@artifex.com>
737da8a64a873ea128c5830519d3327baecc6444

> PDF interpreter - when detecting transparent pages, include Form 'Groups'
> Bug #697354 "PDF Interpreter fails to push pdf14 compositor"
> We have an optimisation in the PDF interpreter which ignores page
> level Group definitions, as these have no effect on the output.
> However, the way this is performed meant that we also did not detect
> Group entries in Form XObjects. So if the only transparency on a page
> was a Form XObject with a Group entry, then we would incorrectly
> decide that the page had no transparency.
> We do still want to do the performance check at the page level, but its
> important that we include Form XObject Groups in the resources check. So
> here we specifically check Form XObjects to see if they have a Group.
> This produces differences in a few files, surprisingly miniscule
> differences. It appears that we have a number of files which include
> Forms with Group entries which, as is so often the case with PDF
> files produced by naive graphics libraries, don't actually *do* any
> real transparency.
> Unfortunately this does mean we now process those files slower than
> we did before (and ps2write now produces images for them), but I don't
> see any real prospect of detecting pointless transparency at this depth
> in a PDF file.
> So the only differences are small colour changes depending on the
> ProcessColorModel of the destination device. None of these appear to
> be significant to me.
> Resource/Init/pdf_main.ps

2016-11-16 14:13:18 -0200
Till Kamppeter <till.kamppeter@gmail.com>
36269a8e76b7b495eba9cc061ebf52163188876a

> "rpdl" output device: Allow 5pt tolerance for page size selection
> The "rpdl" printer driver required an exact match of the page size in
> points so that the correct command for selecting the page size was
> sent to the printer. Otherwise the printer received the command for a
> custom size. Tis is fixed now, allowing a 5-point tolerance (Bug
> 697348).
> contrib/japanese/gdevrpdl.c

2016-11-15 15:06:58 +0000
Robin Watts <robin.watts@artifex.com>
99e9ca317adbd28b5faf3e9eda4c63d636478f43

> Bug 697045: Skip over broken tile data rather than aborting.
> openjpeg/src/lib/openjp2/j2k.c

2016-11-01 18:50:30 +0000
Robin Watts <robin.watts@artifex.com>
2f6ddae95676585717159445001fda2ebb00db8d

> Squash compiler warning.
> base/gxccman.c

2016-11-14 16:59:45 +0000
Ken Sharp <ken.sharp@artifex.com>
90b7603c1afb3ad79a6a0dfee97560b1c3565379

> PCL - fix pdfmark parsing for PUTFILE
> Bug #697285 "Not able to produce a valid PDF/A - Invalid ColorSpace error opening a PDF"
> We have a special pdfmark type '/PUTFILE' for dealing with files,
> because unlike PostScript we can't deal with these as file objects in
> PJL. The code reading the file had a bug, I think caused by altering
> for error detection.
> Fixed here, and returned the error back up the tree. However, note that
> the PCL interpreter still ignores error returns from PJL parsing.
> No differences expected.
> pcl/pl/plparams.c

2016-11-14 15:06:49 +0000
Ken Sharp <ken.sharp@artifex.com>
0f6067d2531298060392d0e25fa759d320e03021

> ps2write - don't try to alter /pagesave when modifying media size
> Bug #697245 " Generated postscript by ps2write causes limitcheck for save error"
> When altering the media size for a page the code defined the save object
> 'pagesave' with the new media size. I believe the intention was probably
> to have the new media size persist, in order to avoid calling setpagdevice
> for every subsequent page with the modified media.
> Unfortunately, this does not remove the prior 'save' object attached to
> /pagesave. The only way to get rid of that is to actually 'restore' it.
> So, fundamentally, we need to remove the definition of pagesave from
> the code which sets the media size. We can achieve the same effect in a
> rather more roundabout fashion by also moving the definition of pagesave
> within the page stream to a point after the definition of the page
> dictionary.
> Less neat, but it works.
> For some obscure reason this results in some pages being rendered
> very slightly different sizes on the cluster. I've checked and the
> current sizes are correct. I have no idea why this was wrong before
> and I'm not interested enough to go looking, since they are now
> correct.
> devices/vector/gdevpdf.c
> devices/vector/opdfread.h
> lib/opdfread.ps

2016-11-14 10:14:01 +0000
Ken Sharp <ken.sharp@artifex.com>
8cefc79359e14fdb8b967697bba33b754e83bcad

> pdfwrite - fix calculation of a bounding box
> Bug #697237 "ps2pdf not producing correct PDF with a rotated character in the PS"
> The code for detecting a glyph which is completely clipped out of the
> output had a fault; after calculating the Font BoundingBox in current
> user space, it only considered three of the points of the resulting
> rectangle to calculate the largest rectangle.
> This erroneous rectangle was then used to decide if a glyph was entirely
> outside the clipping area. Since the top left corner was not considered
> a sufficiently large glyph rotated to an acute enough anti-clockwise
> angle could appear to be totally clipped when in fact it is only
> partially clipped.
> Fix this here by considering all four points.
> This show two very minor progressions in Quality Logic tests and some
> PXL->PDF conversions are now larger. The reason is that we use the
> font bounding box and a couple of glyphs are now considered to be
> unclipped when in fact they are totally clipped out, but we can't tell.
> This results in not only the glyphs but also a font being embedded
> in the output and increasing the size slightly.
> devices/vector/gdevpdte.c

2016-11-12 11:24:18 +0000
Ken Sharp <ken.sharp@artifex.com>
a46245139253b2ec607fcd06c549a6293d05a3a8

> Fix a bug in device subclassing
> If we free the memory used by a child device, we must not then try
> to write to that memory.
> Chanced upon while working on bug #697279
> base/gdevdflt.c

2016-11-10 17:45:38 +0000
Ken Sharp <ken.sharp@artifex.com>
513d6fd7ddfc5a59fbf8bf6ce72eda6c97fea9f8

> remove a bunch of now unused variables from the earlier shading code
> commit.
> base/gxshade1.c

2016-11-10 14:42:49 +0000
Ken Sharp <ken.sharp@artifex.com>
8a26fa67398970f357e1292310ef20556a8e5d96

> Fix 'corner' radial gradient case.
> Bug #697144 " Some incorrectly rendered radial shadings"
> This is to address 'radialshade4.ps, but fixed (the customer had managed
> to create incorrect PostScript for this specific test, see radialshade4b.ps).
> In the case where the two circles defining a radial gradient are
> tangential, and the larger circle has 'extend' set to true, the extended
> area should be limited to the tangent which touches the two circles, and
> the smaller circle should not be filled.
> Getting this corre4ct with our existing method for drawing gradients
> has been difficult. It 'looks like' all gradients are defined in terms
> of tensor patches, rather than having a dedicated plotter for each
> gradient type.
> In order to generate a proper 'truncated' annulus for this case, it is
> necessary to construct a number of different 'quadrilaterals' and fit
> them carefully around the larger circle. To ensure no 'cracks' appear
> between the quads, we must also take care to ensure that they join at
> horizontal or vertical boundaries (in user space).
> There's some trigonometry involved to get this correct, and to avoid
> having to check for infinity returns from tan(alpha), and generally
> avoid the complex work required in the general case, we handle the
> cases where the tangent point of the circles is on a horizontal or
> vertical axis.
> This passes cluster tests, the customer test suite, and my own hand
> created PostScript files which exercise the code rather more thoroughly
> No differences expected.
> base/gxshade1.c

2016-11-09 22:02:47 -0800
Ray Johnston <ray.johnston@artifex.com>
d4d8b7d51f79b47d21d3c82fe652a79e1f890df5

> Fix bug 697323, Segfault after pattern with transparency.
> While the pdfwrite device usage may have contributed to the path being
> taken, the segfault was in the GC and was due to a pattern-clist device
> still existing in the allocator, but no longer referenced (at least as
> seen with a debug build. The fix was to set gx_device_retain false for
> the adev (pattern accum device, which may be a pattern-clist device) for
> the case where the pattern uses transparency so the freeing the saved
> gstate would free the pdf14 device and it would rc_decrement its target,
> thus freeing the accumulator device.
> base/gxpcmap.c

2016-11-07 14:03:30 +0000
Chris Liddell <chris.liddell@artifex.com>
0e2523b9dae517f91bd7da78323e5207d099a10e

> Fix expat build on Windows
> The new version of expat uses time/date API calls to seed a hash function. That
> means we need a extra CFLAG (/DWIN32) and to drop the /Za CFLAG as we do for
> LCMS2.
> base/expat.mak
> psi/msvc.mak

2016-09-14 10:40:36 +0100
Chris Liddell <chris.liddell@artifex.com>
c9f7be4f4de8e98df9d34ff8e4a7f781c0a33899

> Bring master up to date with 9.20 release branch
> Docs, dates, copyrights etc.
> Copyrights, dates etc
> Update News and changelog
> Fix a type in the release comments
> Changelog update for 9.20 RC2
> Update date and product string for 9.20 release
> Copyrights, dates etc
> base/gscdef.c
> base/version.mak
> doc/API.htm
> doc/C-style.htm
> doc/Commprod.htm
> doc/DLL.htm
> doc/Deprecated.htm
> doc/Details8.htm
> doc/Details9.htm
> doc/Develop.htm
> doc/Devices.htm
> doc/Drivers.htm
> doc/Fonts.htm
> doc/Helpers.htm
> doc/History1.htm
> doc/History2.htm
> doc/History3.htm
> doc/History4.htm
> doc/History5.htm
> doc/History6.htm
> doc/History7.htm
> doc/History8.htm
> doc/History9.htm
> doc/Install.htm
> doc/Issues.htm
> doc/Language.htm
> doc/Lib.htm
> doc/Make.htm
> doc/News.htm
> doc/Projects.htm
> doc/Ps-style.htm
> doc/Ps2epsi.htm
> doc/Psfiles.htm
> doc/Readme.htm
> doc/Release.htm
> doc/SavedPages.htm
> doc/Source.htm
> doc/Unix-lpr.htm
> doc/Use.htm
> doc/VectorDevices.htm
> doc/WhatIsGS.htm
> doc/Xfonts.htm
> doc/gs-vms.hlp
> doc/sample_downscale_device.htm
> doc/thirdparty.htm
> man/dvipdf.1
> man/font2c.1
> man/gs.1
> man/gslp.1
> man/gsnd.1
> man/pdf2dsc.1
> man/pdf2ps.1
> man/pf2afm.1
> man/pfbtopfa.1
> man/printafm.1
> man/ps2ascii.1
> man/ps2epsi.1
> man/ps2pdf.1
> man/ps2pdfwr.1
> man/ps2ps.1
> man/wftopfa.1
> psi/msvc.mak

2016-11-04 13:18:21 +0000
Chris Liddell <chris.liddell@artifex.com>
21b582ca561214aa9c5b9c8987a1c0cdce43ace6

> Add expat endian settings.
> And fix the logic for the LCMS2 endian setting (noticed in passing).
> configure.ac

2016-11-04 12:41:02 +0000
Chris Liddell <chris.liddell@artifex.com>
c99d0ad7d5f5187e5e0279b6f9c8092798badc2f

> Bug 697181: allow xps build with shared expat.
> Makefile.in
> configure.ac

2016-11-04 12:13:08 +0000
Chris Liddell <chris.liddell@artifex.com>
00b5d81646bb936577cbea2476e13f0a5dd4b9f1

> Update to expat 2.2.0
> expat/CMake.README
> expat/CMakeLists.txt
> expat/COPYING
> expat/Changes
> expat/ConfigureChecks.cmake
> expat/MANIFEST
> expat/Makefile.in
> expat/README
> expat/aclocal.m4
> expat/amiga/Makefile
> expat/amiga/README.txt
> expat/amiga/expat_68k.c
> expat/amiga/expat_68k.h
> expat/amiga/expat_68k_handler_stubs.c
> expat/amiga/expat_base.h
> expat/amiga/expat_lib.c
> expat/amiga/expat_vectors.c
> expat/amiga/launch.c
> expat/amiga/stdlib.c
> expat/bcb5/elements.bpr
> expat/bcb5/expat.bpr
> expat/bcb5/expat.mak
> expat/bcb5/expat_static.bpr
> expat/bcb5/expat_static.mak
> expat/bcb5/expatw.bpr
> expat/bcb5/expatw.mak
> expat/bcb5/expatw_static.bpr
> expat/bcb5/expatw_static.mak
> expat/bcb5/outline.bpr
> expat/bcb5/xmlwf.bpr
> expat/bcb5/xmlwf.mak
> expat/configure
> expat/configure.ac
> expat/configure.in
> expat/conftools/PrintPath
> expat/conftools/ac_c_bigendian_cross.m4
> expat/conftools/config.guess
> expat/conftools/config.sub
> expat/conftools/expat.m4
> expat/conftools/get-version.sh
> expat/conftools/install-sh
> expat/conftools/libtool.m4
> expat/conftools/ltmain.sh
> expat/conftools/mkinstalldirs
> expat/doc/expat.png
> expat/doc/reference.html
> expat/doc/valid-xhtml10.png
> expat/doc/xmlwf.1
> expat/doc/xmlwf.sgml
> expat/doc/xmlwf.xml
> expat/examples/elements.c
> expat/examples/elements.dsp
> expat/examples/outline.c
> expat/examples/outline.dsp
> expat/expat.dsw
> expat/expat.pc.in
> expat/expat_config.h.cmake
> expat/expat_config.h.in
> expat/lib/amigaconfig.h
> expat/lib/expat.dsp
> expat/lib/expat.h
> expat/lib/expat_external.h
> expat/lib/expat_static.dsp
> expat/lib/expatw.dsp
> expat/lib/expatw_static.dsp
> expat/lib/internal.h
> expat/lib/libexpat.def
> expat/lib/libexpatw.def
> expat/lib/xmlparse.c
> expat/lib/xmlrole.c
> expat/lib/xmltok.c
> expat/lib/xmltok.h
> expat/lib/xmltok_impl.c
> expat/m4/libtool.m4
> expat/m4/ltoptions.m4
> expat/m4/ltsugar.m4
> expat/m4/ltversion.m4
> expat/m4/lt~obsolete.m4
> expat/tests/README.txt
> expat/tests/benchmark/README.txt
> expat/tests/benchmark/benchmark.dsp
> expat/tests/chardata.c
> expat/tests/minicheck.c
> expat/tests/minicheck.h
> expat/tests/runtests.c
> expat/tests/xmltest.sh
> expat/win32/README.txt
> expat/win32/expat.iss
> expat/xmlwf/codepage.c
> expat/xmlwf/readfilemap.c
> expat/xmlwf/unixfilemap.c
> expat/xmlwf/xmlfile.c
> expat/xmlwf/xmlwf.c
> expat/xmlwf/xmlwf.dsp

2016-11-03 13:09:27 +0000
Chris Liddell <chris.liddell@artifex.com>
a73e3cf1ca91bbdb51d5a999a491e58fb9a7ce35

> Bug 697286: handle GlyphDirectory as an array
> For high level devices that need to copy CIDFonts, we need to establish the
> highest CID in a given CIDFont. If the font has a GlyphDirectory dictionary
> the only way to do so is to iterate through the keys to find the highest.
> The code handling this ignored that the GlyphDirectory could be an array,
> which confused the dictionary content iterator, and caused a segfault.
> In the case of an array, set the high CID to the highest index available in the
> array.
> psi/zfcid.c

2016-11-02 16:19:02 +0000
Robin Watts <robin.watts@artifex.com>
dc62c90930512f4b571f68c9110022b234cbd411

> Bug 697186: Tweak to previous JPEG fix.
> Only clamp the DC coefficient. This shouldn't make a difference
> in any real world cases, but is more correct.
> jpeg/jidctint.c

2016-11-01 18:40:04 +0000
Robin Watts <robin.watts@artifex.com>
8dcec8cc076a0cf8350ca7a6ec1d3136812e2a24

> Bug 697186: Workaround JPEG lib bug.
> Commit fix for overflow. Awaiting response from IJG.
> jpeg/jidctint.c

2016-10-26 16:35:38 +0100
Robin Watts <robin.watts@artifex.com>
1eebbfa373d295bdd2bad88aaef1edc368450568

> Bug 697231: Introduce caching to use of clipping paths.
> When we create a clipping device from a path, we copy over the
> pointers to the rectangle list, and start searching them from
> the start.
> This means that if we perform an operation that causes lots of
> calls to something with the same clipping path (like for instance
> a stroke operation with a clipping path that calls down to a fill
> path with a clipping path), then we will repeatedly search from
> the top of the rectangle list.
> This massively slows stuff down.
> This commit introduces a 'cached' entry in the clipping path
> that can be updated after a clipping device has been used to show
> the last place in the list that was found. Subsequent creations
> start searching from this point.
> This gives us the desired locality of reference, and massively
> speeds up the test file.
> base/gxacpath.c
> base/gxclip.c
> base/gxcpath.c
> base/gxcpath.h
> base/gxfill.c
> base/gzcpath.h

2016-10-26 12:14:48 +0100
Robin Watts <robin.watts@artifex.com>
71629c04758788b238d6ff3537d9708f430a4db7

> Tweak to clip device nesting.
> Any call through clip_call_fill_path will be safely nested
> in terms of the clippers used. Reflect this in the
> initialisation of the local device. This avoids an error given
> with the next commit.
> base/gxclip.c

2016-10-26 17:39:29 -0200
Till Kamppeter <till.kamppeter@gmail.com>
0726780b28920045ee6f344a34bc5e8565bc4ed5

> "cups" output device: When creating PWG Raster output, always output the bitmap of the full page, ignoring any unprintable margins suggested by the PPD file.
> cups/gdevcups.c

2016-10-26 08:37:46 +0100
Ken Sharp <ken.sharp@artifex.com>
f0b49c3cf4e0602627c4dc5b6ff910074d298398

> set GX_DOWNSCALER_PARAMS_DEFAULTS to remaining JPEG devices
> Michael's fix in commit 45268652fcddf2031f5edb592bc61e53d9ac4f5b
> resolves the problem for jpeg, but didn't fix the jpeggray or jpegcmyk
> devices, as shown by the all devices test.
> I believe copying the same fix to the other devices should resolve those
> too.
> No differences expected.
> devices/gdevjpeg.c

2016-10-25 15:34:10 -0700
Michael Vrhel <michael.vrhel@artifex.com>
45268652fcddf2031f5edb592bc61e53d9ac4f5b

> Set GX_DOWNSCALER_PARAMS_DEFAULTS in jpeg
> Fix for crash caused by division by zero
> devices/gdevjpeg.c

2016-10-25 18:25:36 +0100
Robin Watts <robin.watts@artifex.com>
cb8022f3e15b761adf4bbc78621cf0699f69e21c

> Fix SEGV caused by previous commit.
> Running:
> gs --debug
> would cause a SEGV in gs_finit_push_systemdict due to
> i_ctx_p being NULL.
> psi/imain.c

2016-10-25 11:16:13 +0100
Chris Liddell <chris.liddell@artifex.com>
2f3679b53632c5b7b9e9a416311ae82f36645fc9

> Bug 697220(2): Fix returning execstackoverflow
> In one case of returning execstackoverflow from the main interpreter loop,
> we'd set the interpreter's private count value of objects to execute, *before*
> we try to push the ref array onto the stack. As a consequence the object
> count was for the new array, but the top of the exec stack was still the
> previous array. This meant when we sync'ed the interpreter loop's internal
> state with the state in the interpreter context, the size of the top object
> on the exec stack could be wrong, causing problems in the garbager - especially
> if the length was too long.
> To resolve, move the exec stack bounds check before the count gets set.
> psi/interp.c

2016-10-25 11:10:54 +0100
Chris Liddell <chris.liddell@artifex.com>
3f09e7022e39412af98602cdfe22adfb34a7fa63

> Bug 697220(1): Push systemdict onto dict stack before we cleanup.
> As part of shutting down the Postscript interpreter, we run some Postscript
> from the C code. We really don't want to stumble across random redefinitions
> of operators (especially if the definitions trigger errors) at this point.
> So, push systemdict onto the top of the dict stack before we start our cleanup.
> Do it in C, to further ensure we don't trip over redefinitions in the Postscipt
> world.
> This *should* resolve the segfaults, but leaves a garbage collector error
> psi/imain.c

2016-10-25 11:10:07 +0100
Chris Liddell <chris.liddell@artifex.com>
5d1ae930711d492d01110ef054c0add3c7615910

> Fix BOBBIN undefined warnings.
> base/bobbin.h

2016-10-23 00:58:23 +0100
Robin Watts <robin.watts@artifex.com>
3216c2b692fe5a4c87936819b2fe14d0963a347a

> Bug 697144: Fix fix for previous radial shading fix.
> This fixes the final case in page_create_color.ps
> In some cases R_tensor_annulus can be called twice; avoid
> flipping function_arg_shift back and forth.
> base/gxshade1.c

2016-10-22 15:47:35 +0100
Robin Watts <robin.watts@artifex.com>
5915f971fa47c8ad1561e403bc7aacd86325c428

> Bug 697144: Fix radial shadings broken by previous fix.
> The previous fix addressed the fact that monotonicity of a
> filled quad was being tested based on splitting on u rather
> than v (or vice versa). It turns out that in some
> circumstances (when circles are entirely nested), we reverse
> u and v, and hence need to reverse the test.
> The previous fix did not allow for this.
> base/gxshade1.c

2016-10-21 17:00:15 +0100
Robin Watts <robin.watts@artifex.com>
898cdaedf52a37c84923d75aa2942e48b0fec91c

> Bug 697144: Fix radialshade2.ps
> Many many moons ago, a fix was committed for bug 690831. The
> commit message for that was lost in the great svn -> git
> migration, but the bug itself makes the history clear.
> Looking back at this again now, it appears that the fix was
> incorrect. Ghostscript was in fact doing the right thing by
> the letter of the standard, but Acrobat was applying a fudge
> factor.
> When filling a radial shade, the code tests to see if the
> two circles are nested. If so, then when the shade is 'extended',
> the entire area outside the final circle is filled. If not,
> a different fill operation has to happen.
> The file given in the bug has a shade where the two circles are
> very close to being nested, but are not strictly so. Acrobat is
> choosing to treat them as if they were.
> We therefore revert the code to 'unbreak' it, and adjust the
> fudge factor in our code to give the same results as Acrobat does.
> This causes no changes in the cluster tests.
> base/gxshade1.c

2016-01-25 10:59:23 +0000
Chris Liddell <chris.liddell@artifex.com>
c3c4bf022a631be939ebb4bf6f59e41514cb1e48

> Bug 696508: improve configure cross compile support
> This is a squashing of the commits on the branch:
> CCAUX-configure
> This allows CCAUX and related settings to be set on the configure command
> line, or in the environment.
> Also, using configure to guess at creating an arch.h file which gets used
> rather than genarch generating one. A couple of things in that file will
> not be as accurate as using genarch, but those are rare, and almost
> certainly for outdated systems (such as whether floats use IEEE
> representation).
> Better documentation to follow, but as an example, building for Android would
> work with:
> ./configure --host=arm-linux-gnu --build=x86_64-linux-gnu \
> CC=/opt/android-ndk-r10e/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-gcc \
> CFLAGS="--sysroot=/home/cliddell/bin/android-ndk-r10e/platforms/android-18/arch-arm -MMD -MP -MF -fpic \
> -ffunction-sections -funwind-tables -fstack-protector -no-canonical-prefixes -march=armv7-a -mfloat-abi=softfp \
> -mfpu=vfpv3-d16 -mthumb -fomit-frame-pointer -fno-strict-aliasing -finline-limit=64 -Wa,--noexecstack" LDFLAGS=" \
> --sysroot=/home/cliddell/bin/android-ndk-r10e/platforms/android-18/arch-arm -MMD -MP -MF -fpic -ffunction-sections \
> -funwind-tables -fstack-protector -no-canonical-prefixes -march=armv7-a -mfloat-abi=softfp -mfpu=vfpv3-d16 -mthumb \
> -fomit-frame-pointer -fno-strict-aliasing -finline-limit=64 -Wa,--noexecstack" CCAUX=gcc CFLAGSAUX=" "
> .gitignore
> Makefile.in
> arch/arch_autoconf.h.in
> base/gsroprun.c
> base/unix-aux.mak
> base/unix-end.mak
> configure.ac
> xps/xps.mak

2016-10-20 16:45:09 +0100
Robin Watts <robin.watts@artifex.com>
0845a1c90f7a22a5b50fddbf7809d985b98290cd

> Bug 697144: Fix radialshade1.ps
> When filling a radial shading, we form 4 tensor patches, one for
> each quadrant. The points for these are represented as poles of
> the tensor patches as p->poles[v][u].
> One quadrant might look like (excuse the ascii art)
> J I H G p->poles[0][0] = A p->poles[3][0] = J
> F p->poles[0][1] = B p->poles[2][0] = K
> K ED p->poles[0][2] = C p->poles[1][0] = L
> p->poles[0][3] = D
> C p->poles[1][3] = E (plus 4 more points
> p->poles[2][3] = F internal to the
> B p->poles[3][3] = G patch, not shown
> p->poles[3][2] = H here)
> L A p->poles[3][1] = I
> Thus 'u' controls how far along the radius of the radial shading
> we are, and 'v' controls how far 'around' the shading we are.
> The shading code first subdivides the patch on v (using the
> split_patch routine). This gives us a succession of slices running
> from the centre of the radial fill to the outside (like slices of
> pizza).
> It then subdivides these slices (using split_slice) to give small
> quadrangles to fill.
> The code then checks to see whether these quadrangles need to be
> further divided by checking to see whether the color change across
> such quadrangles is monotonic or not. If it is, and the quadrangles
> are 'not big' (for some definition of big) then it is considered
> reasonable to fill them using a linear fill.
> For simple radial fills, the color changes across 'u' not 'v'.
> We thefore check for the color change in the given range to see
> if it is monotonic, and if it not, we divide the patch.
> As part of the work for bug 689189 (see commit 36375961a02091)
> Igor had identified some uses of the radial fill code where the
> tensor patches are constructed such that the color varies across
> 'v' rather than 'u', and had therefore amended the code so allow
> for this.
> Unfortunately the setup for this appears to have got it wrong
> for the normal radial case. Fixing that here solves the problem.
> base/gxshade1.c
> base/gxshade6.c

2016-10-20 11:45:54 -0700
Michael Vrhel <michael.vrhel@artifex.com>
cca05810721874cabcc377615cac050bd775ed37

> Add -dNoSeparationFiles to tiffsep device
> If -dNoSeparationFiles is specified when using the tiffsep
> device, only the composite file will be created, no
> separations are created in this case.
> devices/gdevtsep.c
> doc/Devices.htm

2016-10-17 16:34:14 +0100
Chris Liddell <chris.liddell@artifex.com>
6d1822faa68c17b945aea2713985b7095ca424aa

> ASAN segfault: add missing pointer to pclxl_image_enum_t gc info
> The pclxl_image_enum_t stores a pointer to an icclink which is allocated in gc
> memory, so the garbager needs to know about that.
> devices/vector/gdevpx.c

2016-10-17 15:14:54 +0100
Chris Liddell <chris.liddell@artifex.com>
e6460567fcec3b4c96dd4912e556e3b846adaef2

> Refine SAFER file access permissions
> SAFER (amongst other things) is to stop arbitrary file accesses on the host
> system (in Postscript terms '%os%....') but it should not limit access to
> other Postscript devices (most importantly '%rom%').
> psi/zfile.c

2016-10-17 16:21:30 -0700
Michael Vrhel <michael.vrhel@artifex.com>
ed425fcd620837bf63a18a3ee2a2202fa91b1207

> Add -sPostRenderICCProfile support to tiffsep
> Customer would like to have this capability.
> devices/devs.mak
> devices/gdevtsep.c

2016-10-17 20:10:46 +0100
Robin Watts <robin.watts@artifex.com>
937efa62c23c2c79c7487895421041896e8c14b7

> Fix previous JPEG commit.
> The previous commit did not even compile. I have no idea how
> I managed to get that to pass the tests I ran!
> Apologies.
> devices/gdevjpeg.c

2016-10-17 18:11:08 +0100
Robin Watts <robin.watts@artifex.com>
6f14fb471faedbe9657d32743dba609ddd3a0465

> Add Downscaler functionality to jpeg devices.
> devices/gdevjpeg.c
> doc/Devices.htm

2016-10-12 14:15:50 +0100
Robin Watts <robin.watts@artifex.com>
910f459d535cec757b8e5f541dd39be6fa2fb0c9

> Bug 697012: Fix buffer overflow in gxps.
> Port back same fix already applied to muxps.
> xps/xpsglyphs.c

2016-10-17 10:03:53 +0100
Robin Watts <robin.watts@artifex.com>
9388ecefe9d8659d8434aa78d07a1fa247c8ea4e

> Rework openjpeg subsampled decode.
> The current code performs the yuv -> rgb step on the data
> within openjpegs buffers. Unfortunately, this means that
> subsampled data is "expanded" into rgb, converted, and then
> redecimated. The R plane stays intact, and the G and the B
> are degraded. The code is then desubsampled again when copying
> out into the stream, but the damage has been done.
> This gives awful results.
> Instead here, we simplify the code to decode a row at a time
> into a row buffer. We then convert that row buffer to rgb, and
> copy that out. We never redecimate the output.
> This looks much better.
> base/sjpx_openjpeg.c
> base/sjpx_openjpeg.h

2016-10-16 11:36:34 +0100
Chris Liddell <chris.liddell@artifex.com>
08b3f4a91fc65f36da13dfb02a1273c70638c6af

> Bug 697217(4): deal with negative index in context ops
> In this case the join operator was being passed a negative index.
> psi/zcontext.c

2016-10-16 11:30:36 +0100
Chris Liddell <chris.liddell@artifex.com>
a7a8b148c368d313f913c23a754e14394d6fb5a1

> Bug 697217(3): guard against stack underflow in debug info dump
> In the event of an error exit, we dump out the contents of the stacks.
> *But* in the event of an error, we can already be into the "guard" entries
> below the bottom of the normal operand stack - so protect against that
> when dumping out the stack.
> psi/idebug.c

2016-10-16 13:11:46 +0100
Chris Liddell <chris.liddell@artifex.com>
86ea41068f8ee8930aa169ad3a106db4f7d6c7db

> Bug 697217(2): cleanup exec stack on currentcolor* error
> If an error occurs when retrieving currentcolor values, we have to clean up
> the exec stack before returning the error.
> psi/zcolor.c

2016-10-16 11:18:43 +0100
Chris Liddell <chris.liddell@artifex.com>
060cfdc002d29158d9d7f6c5fb15f187c165d408

> Bug 697217(1): Match signs when checking lengths in binary sequences
> psi/iscanbin.c

2016-10-14 15:50:30 +0100
Chris Liddell <chris.liddell@artifex.com>
1f6581f9b77868b56a2f6269f3d1440c9eaad8b0

> Bug 692721: remove SMask specific stuff from form dict
> When we get an SMask group, we have to store the graphics state and the contents
> of the ExtGState, and reset all that before we execute the content stream
> for the group XObject. So it all gets setup in the correct place, that
> information needs to be added to the group's form dictionary.
> It turns out we also need to *remove* these entries from the group's form
> dictionary, in case it gets reused as a normal for XObject.
> The gstate and extended gstate values remain in the SMask parameter dictionary,
> so any reuse of the SMask will still work correctly.
> Resource/Init/pdf_draw.ps

2016-10-14 08:38:29 +0100
Ken Sharp <ken.sharp@artifex.com>
3bf51ac09d8759761057bbf1817434415616258e

> pdfwrite - fix SMask handling, when painting with a Pattern
> Bug #697212 "Error in SMask during ExtGState"
> The title is misleading, the error occurs with a Pattern, but there must
> be an SMask preceding it. This appears to have been a very long-standing
> problem in the code, but it was hidden by ignoring an error return code.
> Fixing Coverity reports meant that the return code was actioned, and that
> is what revealed the problem.
> When we start a new substream to capture a Pattern PaintProc we need to
> reset the 'soft_mask_id' (the ID assigned to the SMask pdfwrite has
> created) in the graphics state. If we don't do that then the code (in
> effect) tries to handle the SMask twice, once for the correct stream
> and once for the pattern PaintProc stream, and this results in the
> stack of pdfwrite internal gstate copies becoming unsynchronised, as well
> as creating a PDF file with unbalanced q/Q operators.
> Ignoring the return code had masked this problem.
> No differences expected.
> devices/vector/gdevpdfi.c

2016-10-13 16:47:47 -0700
Michael Vrhel <michael.vrhel@artifex.com>
84fec37351ebd502c70ac16347fae4b1b5f5cbe6

> Fix for Bug 695154
> The pngalpha device should really have its separable_and_linear setting
> set to GX_CINFO_UNKNOWN_SEP_LIN. In this case, the device will get its shifting
> and mask color info settings set up and in this case the gradient
> code will actually work in the manner to which it is designed.
> devices/gdevpng.c

2016-10-12 11:02:09 -0700
Michael Vrhel <michael.vrhel@artifex.com>
06add83a38437ccd2e7f0f1deb5e2d7bc7a8546d

> Bug 695340. Avoid NULL dereferences
> base/gsptype1.c

2016-10-09 08:22:03 -0700
Michael Vrhel <michael.vrhel@artifex.com>
6d5b4ffeb00f50faf45b72191d38dea422f28405

> Bug 694189 catch NULL of pinst
> If an error occurs and we dig through the saved
> gstates to find the pattern but come up empty
> then return an error
> psi/zpcolor.c

2016-10-11 11:16:59 -0700
Ray Johnston <ray.johnston@artifex.com>
62e787ce74c5c22aaba9377a709bc06217bd46f8

> Fix Bug 696866: patterns need to set color_usage.or over the entire area
> Thanks to Michael Vrhel for the simplified file and suggesting the cause of
> the problem.
> base/gxclpath.c

2016-10-11 16:07:40 +0100
Chris Liddell <chris.liddell@artifex.com>
a48d5240229d2a5cf9413ff2a425c40e2db03b8e

> xpswrite: Add color space to enumerated pointers
> In the xps_image_enum_s the pointer to the color space (pcs) was not
> declared to the garbage collector, so could end up moving with the
> object being updated.
> Caused a segfault spotted in the weekly regression test (for EPSCrop, but
> that's not relevant)
> devices/vector/gdevxps.c

2016-10-10 14:03:51 -0700
Ray Johnston <ray.johnston@artifex.com>
a34f71c530409a559c4cb35cb1a23296541d53c3

> Fix Bug 696864: Use Default colorspaces when processing SMask
> This is done by saving the OverrideICC user parameter before setting the
> colorspace, etc. so as to ignore the ICC profile, which may have a gamma
> that we don't expect, and restore it after the SMask has been rendered.
> Note this file rendered correctly with -dOverrideICC on the command line,
> but this patch automatically applies that during execmaskgroup.
> Thanks to Michael Vrhel for identifying the problem and coming up with a
> simplified test case.
> Resource/Init/pdf_draw.ps

2016-10-08 17:27:34 +0100
Chris Liddell <chris.liddell@artifex.com>
a87e380acd5e326f7d4e4380348bac393fac3058

> Remove the appledmp, iwlo, iwhi, iwlq devices
> base/unix-gcc.mak
> configure.ac
> devices/contrib.mak
> devices/gdevadmp.c
> doc/Develop.htm
> windows/ghostscript.vcproj
> windows/ghostscript_rt.vcxproj

2016-10-07 15:52:42 +0100
Chris Liddell <chris.liddell@artifex.com>
ad13de0b7a11675f34a29a03d1597a780da54851

> Update docs to reflect removal mswindll device
> doc/DLL.htm

2016-10-07 15:38:14 +0100
Chris Liddell <chris.liddell@artifex.com>
e0f5118c432d4f17d8038871691517d84ce01918

> Remove the os2prn device
> base/pcwin.mak
> devices/devs.mak
> devices/gdevos2p.c
> doc/Develop.htm
> psi/os2.mak
> windows/ghostscript.vcproj
> windows/ghostscript_rt.vcxproj

2016-10-07 15:31:06 +0100
Chris Liddell <chris.liddell@artifex.com>
5be37082980552a9d8a21b70a7ee93fbf4320e8f

> Remove the mswindll and mswin devices
> As well as the (long non-functional/non-useful) Windows "xfont" code.
> base/pcwin.mak
> devices/devs.mak
> devices/gdevmswn.c
> devices/gdevmswn.h
> devices/gdevmsxf.c
> devices/gdevwddb.c
> devices/gdevwdib.c
> devices/gdevwprn.c
> doc/DLL.htm
> doc/Develop.htm
> psi/gsdll32.def
> psi/gsdll32metro.def
> psi/gsdll32w.lnk
> psi/gsdll64.def
> psi/gsdll64metro.def
> psi/gsdllARM32metro.def
> psi/msvc.mak
> toolbin/pre.chk
> toolbin/tests/check_comments.py
> windows/ghostscript.vcproj
> windows/ghostscript_rt.vcxproj

2016-10-07 15:07:17 +0100
Chris Liddell <chris.liddell@artifex.com>
ff59e2a9f86a4476aa67b5e768811fe43b0b4f0c

> Remove the macos device
> devices/gdevmac.c
> devices/gdevmac.h
> devices/gdevmacpictop.h
> devices/gdevmacttf.h
> doc/Develop.htm
> toolbin/tests/check_comments.py
> windows/ghostscript.vcproj
> windows/ghostscript_rt.vcxproj

2016-10-07 15:01:26 +0100
Chris Liddell <chris.liddell@artifex.com>
6c0d6e66d219006acfa3201963a0a7123dce3cc9

> Remove sgirgb device
> base/unix-gcc.mak
> configure.ac
> devices/contrib.mak
> devices/gdevsgi.c
> devices/gdevsgi.h
> doc/Develop.htm
> windows/ghostscript.vcproj
> windows/ghostscript_rt.vcxproj

2016-10-06 15:05:23 +0100
Chris Liddell <chris.liddell@artifex.com>
fa981020ef9f96cb2d4d92bd48da81b025bc267a

> Remove the various "vga" devices
> devices/devs.mak
> devices/gdevevga.c
> devices/gdevpcfb.c
> devices/gdevpcfb.h
> devices/gdevs3ga.c
> devices/gdevsco.c
> devices/gdevsvga.h
> doc/Develop.htm
> toolbin/pre.chk
> windows/ghostscript.vcproj
> windows/ghostscript_rt.vcxproj

2016-10-06 14:52:09 +0100
Chris Liddell <chris.liddell@artifex.com>
3488db574bf6d7291f51180395da9aa7fd6816cc

> Remove svga device(s)
> devices/devs.mak
> devices/gdevsvga.c
> doc/Develop.htm
> windows/ghostscript.vcproj
> windows/ghostscript_rt.vcxproj

2016-10-06 14:40:14 +0100
Chris Liddell <chris.liddell@artifex.com>
323a1cb0e1fbd96bed87f818874f51543b286949

> Remove the sunview device
> devices/contrib.mak
> devices/gdevsun.c
> doc/Develop.htm
> windows/ghostscript.vcproj
> windows/ghostscript_rt.vcxproj

2016-10-06 14:37:29 +0100
Chris Liddell <chris.liddell@artifex.com>
74aa1c0b1f71f59f866c800bd698712cdb5c9405

> Remove the sunhmono device
> base/unix-gcc.mak
> configure.ac
> devices/contrib.mak
> devices/gdevsunr.c
> doc/Develop.htm
> windows/ghostscript.vcproj
> windows/ghostscript_rt.vcxproj

2016-10-06 14:32:43 +0100
Chris Liddell <chris.liddell@artifex.com>
4010f1e52592197537e1af639fe3228b8b5fc727

> Remove sparc (printer) device
> devices/contrib.mak
> doc/Develop.htm
> windows/ghostscript.vcproj
> windows/ghostscript_rt.vcxproj

2016-10-06 14:28:52 +0100
Chris Liddell <chris.liddell@artifex.com>
5c6b4d035b6c8c3466e77bc4a581732659d3687e

> Remove the att3b1 device
> configure.ac
> devices/contrib.mak
> devices/gdev3b1.c
> doc/Develop.htm
> windows/ghostscript.vcproj
> windows/ghostscript_rt.vcxproj

2016-10-06 14:25:38 +0100
Chris Liddell <chris.liddell@artifex.com>
6e98f2159d615b4bedd6e5d83c95a511d4f9ea6f

> Remove the herc device
> devices/contrib.mak
> devices/gdevherc.c
> doc/Develop.htm
> windows/ghostscript.vcproj
> windows/ghostscript_rt.vcxproj

2016-10-06 14:16:48 +0100
Chris Liddell <chris.liddell@artifex.com>
8901d9044df836f9ee8988f1ce9f6bbebbc6c314

> Remove lvga256 device
> devices/devs.mak
> devices/gdevl256.c
> doc/Develop.htm
> windows/ghostscript.vcproj
> windows/ghostscript_rt.vcxproj

2016-10-06 14:09:30 +0100
Chris Liddell <chris.liddell@artifex.com>
a6b63be35e0278b4018863cf9b197e90686cc374

> Remove the s3ga device
> devices/devs.mak
> doc/Develop.htm
> windows/ghostscript.vcproj
> windows/ghostscript_rt.vcxproj

2016-10-06 14:04:23 +0100
Chris Liddell <chris.liddell@artifex.com>
461b6c19ab09b19ac436b6ccba234f36ad70c197

> Remove vgalib device
> devices/devs.mak
> devices/gdevvglb.c
> windows/ghostscript.vcproj
> windows/ghostscript_rt.vcxproj

2016-10-06 13:47:19 +0100
Chris Liddell <chris.liddell@artifex.com>
f659ff57a2e3fa011255569dcdf54cc825aaa9af

> Remove omni device
> Makefile.in
> configure.ac
> contrib/contrib.mak
> contrib/defs.h
> contrib/gomni.c
> windows/ghostscript.vcproj
> windows/ghostscript_rt.vcxproj

2016-10-06 13:43:59 +0100
Chris Liddell <chris.liddell@artifex.com>
ec346cc09daada7c16e7213be154e86f644c6d04

> Remove mag16 and mag256 devices
> configure.ac
> contrib/contrib.mak
> contrib/japanese/gdevmag.c
> psi/msvc.mak

2016-10-06 13:05:56 +0100
Chris Liddell <chris.liddell@artifex.com>
c0448269dd1928b2aff0307ed1206118f329af14

> Remove the moribund Mac Classic specific files.
> base/gp_mac.c
> base/gp_mac.h
> base/gp_macio.c
> base/gp_macpoll.c
> base/macos-mcp.mak

2016-10-10 09:45:44 +0100
Chris Liddell <chris.liddell@artifex.com>
ed539f1b8d29b2f03cd22ac2d54ee9036000d565

> Remove doc sections about making SAFER the default
> man/gs.1

2016-10-10 09:40:31 +0100
Ken Sharp <ken.sharp@artifex.com>
7119a01ae110a4c81b002f86464e684259626b30

> Remove from the documentation the stated intention to make -dSAFER the
> default.
> doc/Use.htm

2016-10-10 08:45:46 +0100
Ken Sharp <ken.sharp@artifex.com>
9572484beac8fda920cbca3f6c6d09a5dc424825

> Fix pdfmark argument validation
> This doesn't fit neatly into any category, its a PostScript 'operator'
> but it is only implemented for the pdfwrite device...
> The pdfmark operator takes a mark, a series of arguments and a name
> object. Zero argument sis valid, but the absence of a name object is
> not. We weren't checking for the absence of a name object, or
> validating its type.
> No differences expected.
> Resource/Init/gs_pdfwr.ps

2016-10-10 08:09:15 +0100
Ken Sharp <ken.sharp@artifex.com>
ec6ba697311d2424189583f8fc26d373a584a4ce

> Coverity ID 137703 - remove some dead code
> devices/vector/gdevpdfe.c

2016-10-08 16:35:39 +0100
Chris Liddell <chris.liddell@artifex.com>
b60d50b7567369ad856cebe1efb6cd7dd2284219

> Bug 697193: status operator honour SAFER option
> psi/zfile.c

2016-10-08 16:18:25 +0100
Chris Liddell <chris.liddell@artifex.com>
4ea759bbd40746410fb2beb82e3ba9ebb6788107

> Bug 697204: fully init lock object
> The scheduler field (which is relocatable) was not being initialisedm causing a
> segfault in teh garbage collector
> psi/zcontext.c

2016-10-08 16:10:27 +0100
Chris Liddell <chris.liddell@artifex.com>
f5c7555c30393e64ec1f5ab0dfae5b55b3b3fc78

> Bug 697203: check for sufficient params in .sethalftone5
> and param types
> psi/zht2.c

2016-10-08 16:01:12 +0100
Chris Liddell <chris.liddell@artifex.com>
a5360401495654e89301b2516703c1d2877fc5ba

> Check for NULL return from memory allocation
> base/gxipixel.c

2016-10-05 09:36:33 -0700
Michael Vrhel <michael.vrhel@artifex.com>
f3de2191afc0d8fcf0285736d2d25fa6071a7981

> Bug 696860 remove memcmp of structs in gscrdp.c
> base/gscie.c
> base/gscie.h
> base/gscrdp.c

2016-10-05 09:59:25 +0100
Chris Liddell <chris.liddell@artifex.com>
6f749c0c44e7b9e09737b9f29edf29925a34f0cf

> Bug 697179: Reference count device icc profile
> when copying a device
> base/gsdevice.c

2016-10-05 09:55:55 +0100
Chris Liddell <chris.liddell@artifex.com>
6d444c273da5499a4cd72f21cb6d4c9a5256807d

> Bug 697178: Add a file permissions callback
> For the rare occasions when the graphics library directly opens a file
> (currently for reading), this allows us to apply any restrictions on
> file access normally applied in the interpteter.
> base/gsicc_manage.c
> base/gslibctx.c
> base/gslibctx.h
> psi/imain.c
> psi/int.mak
> psi/zfile.c
> psi/zfile.h

2016-10-03 01:46:28 +0100
Chris Liddell <chris.liddell@artifex.com>
8abd22010eb4db0fb1b10e430d5f5d83e015ef70

> Bug 697169: Be rigorous with SAFER permissions
> Once we've opened our input file from the command line, enforce the SAFER
> rules.
> psi/zfile.c

2016-07-19 08:43:35 +0100
Chris Liddell <chris.liddell@artifex.com>
d609a3d4c1b8583d1c22db6b4d3bce4b239cf88c

> Use ToUnicode for substituted CIDFonts
> When we substitute a CIDFont in a PDF file with a TTF from disk, use the
> ToUnicode CMap (if available) to extract Unicode values. In a lot of case, this
> gets a more accurate character code to glyph mapping than the previous reliance
> on the low level glyph ordering from the TTF.
> This also meant being more robust for broken ToUnicode CMap. Also, an additional
> option (-dIgnoreToUnicode) to skip parsing of the ToUnicode CMap - for cases
> where a correctly formed ToUnicode is semantically wrong.
> Resource/Init/pdf_font.ps
> base/gstext.c
> base/gxfapi.c
> base/gxfapi.h
> pcl/pl/plfapi.c
> psi/zfapi.c

2016-10-05 08:32:39 -0700
Michael Vrhel <michael.vrhel@artifex.com>
3089131dc90ec008ff540d41df0f1a9fbc2dd47b

> Bug 696859 memcmp of struct removal in gscrd.c
> base/gscrd.c

2016-10-05 13:15:23 +0100
Ken Sharp <ken.sharp@artifex.com>
799531ffc1240933786cd2121add9d7e3cba778e

> Coverity ID 137283 - pdfwrite - remove some redundant code
> I had left some code that catered for a UTF16 surrogate pair promoted to
> UTF32, converting the result to UTF8. But I didn't implement the UTF32
> promotion, leaving it as a potential future enhancement.
> However, Coverity whinges about the test always being true, so here
> just remove the code. Its trivial enough to add in if we ever need it.
> devices/vector/gdevpdfe.c

2016-10-05 10:10:58 +0100
Ken Sharp <ken.sharp@artifex.com>
875a0095f37626a721c7ff57d606a0f95af03913

> DSC parser - validate parameters
> Bug #697190 ".initialize_dsc_parser doesn't validate the parameter is a dict type before using it."
> Regardless of any security implications, its simply wrong for a PostScript
> operator not to validate its parameter(s).
> No differences expected.
> psi/zdscpars.c

2016-10-05 09:41:18 +0100
Ken Sharp <ken.sharp@artifex.com>
aef8f6cfbff9080e4b9c54053bc909875c09a2be

> Prevent dereference of NULL device method
> Bug #697189 ".gethardwareparams crashes with any special device"
> Another NULL device method problem. As noted previously, the original
> design intended that device methods should never be NULL, but this
> has been ignored over the years leading to the current mess of some
> methods being NULL accidentally, some being NULL deliberately and
> having different effects when NULL, and some methods never being NULL.
> While I do still intend to try and rectify this one day, in the meantime
> add a check to make sure the method is not NULL before trying to
> execute it in this case.
> No differences expected
> base/gsdparam.c

2016-10-04 16:24:13 -0700
Michael Vrhel <michael.vrhel@artifex.com>
36a2c94c4ebea8aa1c9cb2ca98e124a5b363000e

> Fix misplace parenthesis and missing const
> base/gdevdevn.c
> base/gscie.c

2016-10-04 15:54:56 -0700
Michael Vrhel <michael.vrhel@artifex.com>
e4ab4499f9f33c51cdb95020c99cf0f4f1e6ee77

> Bug 696858 remove memcmp struct in gscie.c
> base/gscie.c

2016-10-04 14:39:54 -0700
Michael Vrhel <michael.vrhel@artifex.com>
2e9a339b766fb7a4d791c5ba1d85bdd24e6dbbaa

> Bug 696854 remove memcmp of structs in gdevdevn.c
> base/gdevdevn.c

2016-10-04 12:04:03 -0700
Michael Vrhel <michael.vrhel@artifex.com>
4fd414107c5b36419896a9c46956cb254adf201f

> Bug 696862 remove memcmp() color info structure
> base/gsdevice.c
> base/gxclpage.c
> base/gxdevcli.h
> base/gximage2.c

2016-10-03 16:21:49 +0100
Ken Sharp <ken.sharp@artifex.com>
a8642064fe21752b00e28d05483baca029fe0891

> pdfwrite - fix ToUnicode CMap sequence consolidation
> Bug #697176 "ToUnicode CMap generation broken in 9.20"
> The reworking to handle the current version of ToUnicode CMap missed
> a case where the size of a code pair had changed. This led to a loop
> comparing incorrect values, instead of comparing two consecutive
> values, it compared a value with one much earlier.
> In general this led to a loss of efficient, causing us to emit two or
> more entries when it was possible to emit a single range. However in the
> rare case when the comparison happened to compare two values that were
> consecutive, but shouldn't have been, this led to us writing an incorrect
> ToUnicode CMap.
> No differences expected.
> base/gsfcmap.c

2016-09-29 21:57:20 +0100
Ken Sharp <ken.sharp@artifex.com>
309edf631cf1160087ede69384f502aa1d64006c

> pdfwrite - Fix handling of Separation /All alternate space conversion
> Bug #697118 "Separation colorspace is not converted correctly by pdfwrite"
> The /All Separation space wasn't getting the components of the tint
> transform colour space correctly set. For rendering we never need to
> do that, and simply set the relevant component of the Separation
> (or DeviceN) space to be the tint value.
> This commit forces the CMS to run the tint transform when we need to
> create a new, different, alternate for the Separation space.
> No differences expected.
> devices/vector/gdevpdfg.c

2016-09-29 19:22:10 +0100
Ken Sharp <ken.sharp@artifex.com>
727aeab76c39026722e3e492a30ae2f7c218c1ec

> Fix UTF16 surrogate pair detection
> Flagged by clang, the use of a short would fail to detect surrogate
> pairs, this shuold be an unsigned short.
> Bizarrely this worked as expected on Windows, I have no idea how.
> devices/vector/gdevpdfe.c

2016-09-29 17:35:05 +0100
Ken Sharp <ken.sharp@artifex.com>
273a133110838ee5702e7eb6409a853c598211b2

> Remove (and re-implement) ConvertUTF.c
> Bug #697122 " embedded ConvertUTF.c is buggy and licensed incompatibly with GPL/APGL"
> Its not clear that this code is incompatible with GPL, nor do we think
> any 'bugginess' in the code affects us, since we are using a comparatively
> small part of the included code.
> Nevertheless its possible to remove the code, and re-implement the small
> part we actually need, and that is done here.
> Also removed the DSCEncodingToUnicode option which was insanely difficult
> to use, and incorrectly documented.
> Yhis shows one difference, 692486_-_heap_overflow_in_pdf_to_ucs2.pdf
> now correctly throws an error, because the PDF file contains document
> information (Application) which has an invalid UTF16-BE sequence.
> base/ConvertUTF.c
> base/ConvertUTF.h
> base/lib.mak
> devices/devs.mak
> devices/vector/gdevpdf.c
> devices/vector/gdevpdfb.h
> devices/vector/gdevpdfe.c
> devices/vector/gdevpdfp.c
> devices/vector/gdevpdfx.h
> windows/ghostscript.vcproj
> windows/ghostscript_rt.vcxproj

2016-09-27 17:07:02 +0100
Robin Watts <robin.watts@artifex.com>
27e01aa77d0cf1668f60d87cf7417c90bf309d1b

> Squash 2 warnings in the openjpeg code.
> openjpeg/src/lib/openjp2/j2k.c
> openjpeg/src/lib/openjp2/thread.c

2016-09-27 16:08:57 +0100
Robin Watts <robin.watts@artifex.com>
9a78bfb8698061e22e3d460b8c15825992e44def

> Import new OpenJPEG version.
> Squashed version of openjpeg-update-20160927
> This squashes the following commits:
> * Import new OpenJPEG version.
> From https://github.com/uclouvain/openjpeg
> Final commit is:
> commit 34dae137a9a8c04feaa9763ae7e09a86ecb10400
> Author: Mathieu Malaterre <mathieu.malaterre@gmail.com>
> Date: Mon Sep 26 12:01:31 2016 +0200
> OPENJPEG_NAMESPACE is configurable by user
> * Zap the OpenJPEG stuff we don't need
> * Add predefined openjpeg headers.
> * Import patches from Sumatra's tree.
> * Update Makefiles for new openjpeg
> * Update MSVC for new files
> * OpenJPEG allocation fixes.
> The old version of openjpeg allocates using malloc/free.
> The new version of openjpeg allocates via opj_malloc (and co).
> We can capture these and pass them down to our own allocators,
> but we cannot get openjpeg to pass us a gs_memory_t * to use.
> We therefore resort to using a static to hold 'the current
> gs_memory_t *' before we call openjpeg. To keep this threadsafe
> we add some private data to the gslibctx, which the openjpeg
> implementation can use to hold a lock.
> We add calls to both jpx decode implementations to init this
> private data (where the luratech implementation is null).
> base/gslibctx.c
> base/gslibctx.h
> base/openjpeg.mak
> base/sjpx_luratech.c
> base/sjpx_openjpeg.c
> openjpeg/AUTHORS
> openjpeg/AUTHORS.md
> openjpeg/CHANGELOG.md
> openjpeg/CHANGES
> openjpeg/NEWS
> openjpeg/NEWS.md
> openjpeg/THANKS
> openjpeg/THANKS.md
> openjpeg/src/lib/openjp2/CMakeLists.txt
> openjpeg/src/lib/openjp2/bio.c
> openjpeg/src/lib/openjp2/cidx_manager.c
> openjpeg/src/lib/openjp2/cio.c
> openjpeg/src/lib/openjp2/cio.h
> openjpeg/src/lib/openjp2/dwt.c
> openjpeg/src/lib/openjp2/dwt.h
> openjpeg/src/lib/openjp2/event.h
> openjpeg/src/lib/openjp2/function_list.c
> openjpeg/src/lib/openjp2/function_list.h
> openjpeg/src/lib/openjp2/image.c
> openjpeg/src/lib/openjp2/indexbox_manager.h
> openjpeg/src/lib/openjp2/invert.c
> openjpeg/src/lib/openjp2/j2k.c
> openjpeg/src/lib/openjp2/j2k.h
> openjpeg/src/lib/openjp2/jp2.c
> openjpeg/src/lib/openjp2/jp2.h
> openjpeg/src/lib/openjp2/libopenjp2.pc.cmake.in
> openjpeg/src/lib/openjp2/mct.c
> openjpeg/src/lib/openjp2/mct.h
> openjpeg/src/lib/openjp2/mqc.c
> openjpeg/src/lib/openjp2/mqc.h
> openjpeg/src/lib/openjp2/mqc_inl.h
> openjpeg/src/lib/openjp2/openjpeg.c
> openjpeg/src/lib/openjp2/openjpeg.h
> openjpeg/src/lib/openjp2/opj_clock.c
> openjpeg/src/lib/openjp2/opj_codec.h
> openjpeg/src/lib/openjp2/opj_config.h.cmake.in
> openjpeg/src/lib/openjp2/opj_config_private.h.cmake.in
> openjpeg/src/lib/openjp2/opj_includes.h
> openjpeg/src/lib/openjp2/opj_intmath.h
> openjpeg/src/lib/openjp2/opj_malloc.c
> openjpeg/src/lib/openjp2/opj_malloc.h
> openjpeg/src/lib/openjp2/phix_manager.c
> openjpeg/src/lib/openjp2/pi.c
> openjpeg/src/lib/openjp2/pi.h
> openjpeg/src/lib/openjp2/ppix_manager.c
> openjpeg/src/lib/openjp2/raw.c
> openjpeg/src/lib/openjp2/t1.c
> openjpeg/src/lib/openjp2/t1.h
> openjpeg/src/lib/openjp2/t1_generate_luts.c
> openjpeg/src/lib/openjp2/t1_luts.h
> openjpeg/src/lib/openjp2/t2.c
> openjpeg/src/lib/openjp2/t2.h
> openjpeg/src/lib/openjp2/tcd.c
> openjpeg/src/lib/openjp2/tcd.h
> openjpeg/src/lib/openjp2/tgt.c
> openjpeg/src/lib/openjp2/tgt.h
> openjpeg/src/lib/openjp2/thix_manager.c
> openjpeg/src/lib/openjp2/thread.c
> openjpeg/src/lib/openjp2/thread.h
> openjpeg/src/lib/openjp2/tls_keys.h
> windows/ghostscript.vcproj

2016-09-27 11:22:18 +0100
Chris Liddell <chris.liddell@artifex.com>
b4cc6d28e9a456a34a7348d98ff78ada9da727bb

> Add pre-processor define for shared OpenJPEG
> Makefile.in

2016-09-23 17:17:19 -0300
Till Kamppeter <till.kamppeter@gmail.com>
9e00367c3f598dc5e7b80d492e2b2d7321015fb3

> pxlcolor/pxlmono output devices: Make MediaPosition, ManualFeed, and MediaType work
> In the pxlcolor and pxlmono output devices (for PCL-XL printers) the
> support for the attributes MediaPosition, ManualFeed, and MediaType
> got broken when ESP Ghostscript got merged into GPL Ghostscript (Bug
> devices/vector/gdevpx.c

2016-09-22 09:21:18 +0100
Chris Liddell <chris.liddell@artifex.com>
c1a79c6ab5ffadde8e296cd3e0b9e52a87c4ef66

> Bug 697087: Apply PDF TTF rules when loading from disk
> When we substitute a TTF from disk for a (non-embedded) TTF in a PDF, apply the
> same rules (if possible) as when reading a TTF embedded in a PDF. So, selection
> of cmap table, font encoding, whether or not to draw the notdef etc.
> This applies *only* to fonts, *not* to CIDFonts.
> Resource/Init/gs_ttf.ps
> Resource/Init/pdf_font.ps

2016-09-22 15:24:45 +0100
Robin Watts <robin.watts@artifex.com>
abffa3e76c3e33b683333be329b39efaf762eca7

> Remove Android logging code.
> Bow to protestations from my colleagues and move code into
> the caller. Probably nicer. If anyone ever needs the code they
> can grab it from git.
> Revert "Tweak android logging code logic."
> This reverts commit 4d08bfd98b5fcd7cd4c2bd5faf72ac9615354ee3.
> Revert "Add android logging code."
> This reverts commit 2c52876b77d348866941fb85f6d0349a51df0455.
> psi/iapi.c

2016-09-21 16:22:48 +0100
Robin Watts <Robin.Watts@artifex.com>
4d08bfd98b5fcd7cd4c2bd5faf72ac9615354ee3

> Tweak android logging code logic.
> It seems we don't set NDEBUG in release builds for android.
> Revert to #ifdef DEBUG rather than #ifndef NDEBUG as a guard.
> psi/iapi.c

2016-09-21 12:01:47 +0100
Robin Watts <robin.watts@artifex.com>
2c52876b77d348866941fb85f6d0349a51df0455

> Add android logging code.
> Update stdio redirection so that stdout and stderr go to
> Android.log in DEBUG builds.
> psi/iapi.c

2016-09-20 18:07:51 +0100
Chris Liddell <chris.liddell@artifex.com>
1bd7f32d70549971b4a384c5865e1fd030f49f20

> Bug 697138: Fix --disable-sse2 to work with openjpeg
> OpenJPEG enables it's SSE code based on the compiler defining __SSE__ so we
> want to undefine that if we're not using SSE operations.
> Makefile.in
> configure.ac

2016-09-20 19:57:14 +0100
Robin Watts <robin.watts@artifex.com>
20b0255206254ebcce1cde0a4a63d74b0aedcecf

> Fix splay tree traversal (again)
> When setting up a traversal from a midpoint of the tree, we'd
> immediately trip into the "has hit the endpoint" code.
> Fix that.
> base/gsalloc.c

2016-09-20 09:03:31 -0700
Ray Johnston <ray.johnston@artifex.com>
0e1153bf2d344044cd9fdfb7706f829b63348118

> FitPage should not add in rotation if destination page is square.
> If the PageSize was square, it would be treated as "not landscape",
> but landscape pages in would be arbitrarily rotated.
> Note this does not change the bahavior of PS or EPS page fitting.
> TBD: Add an option to fit to a page and never rotate (FitPageNR)
> Resource/Init/pdf_main.ps

2016-09-20 16:48:45 +0100
Robin Watts <robin.watts@artifex.com>
570041cc341557da8521fdace380f837cc572a69

> Fix Memento crash
> When reallocing set the rawsize before attempting to write
> the post guard block.
> base/memento.c

2016-09-20 13:41:31 +0100
Robin Watts <robin.watts@artifex.com>
3dd5f4c6b02179422bd8686fceed1f4955221d90

> Sync Memento with MuPDF.
> base/memento.c
> base/memento.h

2016-09-20 13:04:51 +0100
Robin Watts <robin.watts@artifex.com>
4e01c57e0f0773e29bc6f921cfc677576e72739d

> Bug 697134: Tweak MEMENTO_GS_HACKS inclusion.
> Rather than rolling our own memset prototype in this case, use
> the one that gs provides.
> base/memento.c

2016-09-16 15:23:32 +0100
Chris Liddell <chris.liddell@artifex.com>
1a0104084a4dfdff77165d931bdc87849c8ad824

> Clump has_refs - follow up to commit 63f74ce6
> The function save_set_new() (where the original fix for 'has_refs' is located)
> is called in two circumstances: when creating a save level, and when destroying
> a save level.
> We have to retain the 'has_refs' value for the latter case for the garbager to
> function correctly, but doing so in the former results in the garbager
> sometimes scanning more memory than is really necessary (it can end up scanning
> ref memory from the previous save state, which is pointless since that cannot
> change).
> This change means that 'has_refs == true' will only be retained in the
> 'destroying a save level' case (which works correctly because, by the time the
> function is called, we've already returned the relevant allocated to its
> previous state).
> psi/isave.c

2016-09-15 14:14:35 -0700
Ray Johnston <ray.johnston@artifex.com>
bfffe2011e1c8ffe53a432424b049f3989d6174a

> Fix bug 697097. SMask subpixel offset must match image offset.
> The dda used to select the source pixel for mapping into the image
> must use the same stepping for gray (monochrome) and color images
> since an SMask is monochrome and the image may be in color. This is
> primarily evident with the bug file since Matte is used to indicate
> that the source data is premuliplied. Colors can shift a LOT since
> the removal of the premultiplication can expand mistaked.
> base/gxicolor.c

2016-09-14 16:31:56 +0100
Ken Sharp <ken.sharp@artifex.com>
5521e702af192e06f186d0d741f24097eb5b8e26

> PDF interpreter - fix for GSView 5
> Commit 093bd18bd923644fcd25c507088c0ebc63b4c320 included an
> 'optimisation' to prevent rescanning for transparency if we had already
> scanned. However, this assumed that the function pdfshowpage_setup
> had already been executed in order to set a variable.
> This is always true when running files via Ghostscript, but any
> application (such as GSView 5) which executes the PDF operations
> individually need not execute this function. If the function was not
> executed then an error occurred. From other comments in pdf_main.ps
> its possible that customers may be using these functions as well (see
> the comments above the definition of /pdfshowpage)
> This commit checks to see if the variable has been set, if it has then
> it is used, otherwise we rescan for transparency. This prevents the
> error, but uses the optimisation if its possible to do so.
> No differences expected
> Resource/Init/pdf_main.ps

2016-09-14 10:28:43 +0100
Chris Liddell <chris.liddell@artifex.com>
04117ec705cfc89ce4bb4b451ba95af61b937fe0

> Bump version number to 9.21
> Resource/Init/gs_init.ps
> base/version.mak

2016-09-26 11:36:27 +0100
Chris Liddell <chris.liddell@artifex.com>
5deee306126e09f95e40e69fe04a7d26c842fb56

> Update date and product string for 9.20 release
> base/gscdef.c
> base/version.mak
> doc/API.htm
> doc/C-style.htm
> doc/Commprod.htm
> doc/DLL.htm
> doc/Deprecated.htm
> doc/Details8.htm
> doc/Details9.htm
> doc/Develop.htm
> doc/Devices.htm
> doc/Drivers.htm
> doc/Fonts.htm
> doc/Helpers.htm
> doc/History1.htm
> doc/History2.htm
> doc/History3.htm
> doc/History4.htm
> doc/History5.htm
> doc/History6.htm
> doc/History7.htm
> doc/History8.htm
> doc/History9.htm
> doc/Install.htm
> doc/Issues.htm
> doc/Language.htm
> doc/Lib.htm
> doc/Make.htm
> doc/News.htm
> doc/Projects.htm
> doc/Ps-style.htm
> doc/Ps2epsi.htm
> doc/Psfiles.htm
> doc/Readme.htm
> doc/Release.htm
> doc/SavedPages.htm
> doc/Source.htm
> doc/Unix-lpr.htm
> doc/Use.htm
> doc/VectorDevices.htm
> doc/WhatIsGS.htm
> doc/Xfonts.htm
> doc/gs-vms.hlp
> doc/sample_downscale_device.htm
> doc/thirdparty.htm
> man/dvipdf.1
> man/font2c.1
> man/gs.1
> man/gslp.1
> man/gsnd.1
> man/pdf2dsc.1
> man/pdf2ps.1
> man/pf2afm.1
> man/pfbtopfa.1
> man/printafm.1
> man/ps2ascii.1
> man/ps2epsi.1
> man/ps2pdf.1
> man/ps2pdfwr.1
> man/ps2ps.1
> man/wftopfa.1

2016-09-20 20:33:21 +0100
Chris Liddell <chris.liddell@artifex.com>
3263f33ba60aafe7b671d2c9b7a3b25fb39a7bee

> Changelog update for 9.20 RC2
> doc/History9.htm

2016-09-14 17:35:30 +0100
Chris Liddell <chris.liddell@artifex.com>
457cc95668fbf26cf9cf5e4ee10709ad8c8e2c58

> Fix a type in the release comments
> doc/History9.htm
> doc/News.htm

2016-09-14 12:14:11 +0100
Chris Liddell <chris.liddell@artifex.com>
eedf4c16032d2a8ec356705f28cee3fdbec248d2

> Update News and changelog
> doc/History9.htm
> doc/News.htm

2016-09-14 10:40:36 +0100
Chris Liddell <chris.liddell@artifex.com>
7658715de338f9cd3a62d44f7c503f81d03a3fae

> Copyrights, dates etc
> doc/API.htm
> doc/C-style.htm
> doc/Commprod.htm
> doc/DLL.htm
> doc/Deprecated.htm
> doc/Details8.htm
> doc/Details9.htm
> doc/Develop.htm
> doc/Devices.htm
> doc/Drivers.htm
> doc/Fonts.htm
> doc/Helpers.htm
> doc/History1.htm
> doc/History2.htm
> doc/History3.htm
> doc/History4.htm
> doc/History5.htm
> doc/History6.htm
> doc/History7.htm
> doc/History8.htm
> doc/History9.htm
> doc/Install.htm
> doc/Issues.htm
> doc/Language.htm
> doc/Lib.htm
> doc/Make.htm
> doc/News.htm
> doc/Projects.htm
> doc/Ps-style.htm
> doc/Ps2epsi.htm
> doc/Psfiles.htm
> doc/Readme.htm
> doc/Release.htm
> doc/SavedPages.htm
> doc/Source.htm
> doc/Unix-lpr.htm
> doc/Use.htm
> doc/VectorDevices.htm
> doc/WhatIsGS.htm
> doc/Xfonts.htm
> doc/gs-vms.hlp
> doc/sample_downscale_device.htm
> doc/thirdparty.htm
> man/dvipdf.1
> man/font2c.1
> man/gs.1
> man/gslp.1
> man/gsnd.1
> man/pdf2dsc.1
> man/pdf2ps.1
> man/pf2afm.1
> man/pfbtopfa.1
> man/printafm.1
> man/ps2ascii.1
> man/ps2epsi.1
> man/ps2pdf.1
> man/ps2pdfwr.1
> man/ps2ps.1
> man/wftopfa.1
> psi/msvc.mak

2016-09-14 10:34:52 +0100
Chris Liddell <chris.liddell@artifex.com>
8749511b204f255740a1555520a9b1d7adcceacf

> Change product family for RC
> Plus dates
> base/gscdef.c

2016-09-20 18:07:51 +0100
Chris Liddell <chris.liddell@artifex.com>
65898de27797a835d2029676d4380b3c7806dc9e

> Bug 697138: Fix --disable-sse2 to work with openjpeg
> OpenJPEG enables it's SSE code based on the compiler defining __SSE__ so we
> want to undefine that if we're not using SSE operations.
> Makefile.in
> configure.ac

2016-09-20 19:57:14 +0100
Robin Watts <robin.watts@artifex.com>
ed866d7ab135edebd9c53f52026426d403f53a49

> Fix splay tree traversal (again)
> When setting up a traversal from a midpoint of the tree, we'd
> immediately trip into the "has hit the endpoint" code.
> Fix that.
> base/gsalloc.c

2016-09-20 09:03:31 -0700
Ray Johnston <ray.johnston@artifex.com>
ba8a97dc6f67e044d567e38c68cfd5b785835615

> FitPage should not add in rotation if destination page is square.
> If the PageSize was square, it would be treated as "not landscape",
> but landscape pages in would be arbitrarily rotated.
> Note this does not change the bahavior of PS or EPS page fitting.
> TBD: Add an option to fit to a page and never rotate (FitPageNR)
> Resource/Init/pdf_main.ps

2016-09-20 16:48:45 +0100
Robin Watts <robin.watts@artifex.com>
029f4ec2d6b8165b0cfff02173cde68edaebc108

> Fix Memento crash
> When reallocing set the rawsize before attempting to write
> the post guard block.
> base/memento.c

2016-09-20 13:41:31 +0100
Robin Watts <robin.watts@artifex.com>
5547040a0de52d588401ea9f1dfd20bc8168f455

> Sync Memento with MuPDF.
> base/memento.c
> base/memento.h

2016-09-20 13:04:51 +0100
Robin Watts <robin.watts@artifex.com>
f763382b616c35e9a021bde4e5347c1d67df5a0a

> Bug 697134: Tweak MEMENTO_GS_HACKS inclusion.
> Rather than rolling our own memset prototype in this case, use
> the one that gs provides.
> base/memento.c

2016-09-16 15:23:32 +0100
Chris Liddell <chris.liddell@artifex.com>
c3c48bbdda6915abfe39b4a0de9978555fc071ba

> Clump has_refs - follow up to commit 63f74ce6
> The function save_set_new() (where the original fix for 'has_refs' is located)
> is called in two circumstances: when creating a save level, and when destroying
> a save level.
> We have to retain the 'has_refs' value for the latter case for the garbager to
> function correctly, but doing so in the former results in the garbager
> sometimes scanning more memory than is really necessary (it can end up scanning
> ref memory from the previous save state, which is pointless since that cannot
> change).
> This change means that 'has_refs == true' will only be retained in the
> 'destroying a save level' case (which works correctly because, by the time the
> function is called, we've already returned the relevant allocated to its
> previous state).
> psi/isave.c

2016-09-15 14:14:35 -0700
Ray Johnston <ray.johnston@artifex.com>
974843fc7c06bc7354bd5f74f87a22014b0a1e16

> Fix bug 697097. SMask subpixel offset must match image offset.
> The dda used to select the source pixel for mapping into the image
> must use the same stepping for gray (monochrome) and color images
> since an SMask is monochrome and the image may be in color. This is
> primarily evident with the bug file since Matte is used to indicate
> that the source data is premuliplied. Colors can shift a LOT since
> the removal of the premultiplication can expand mistaked.
> base/gxicolor.c

2016-09-14 16:31:56 +0100
Ken Sharp <ken.sharp@artifex.com>
8079f5a688d54ba7ab5358d59a7773caa2176d23

> PDF interpreter - fix for GSView 5
> Commit 093bd18bd923644fcd25c507088c0ebc63b4c320 included an
> 'optimisation' to prevent rescanning for transparency if we had already
> scanned. However, this assumed that the function pdfshowpage_setup
> had already been executed in order to set a variable.
> This is always true when running files via Ghostscript, but any
> application (such as GSView 5) which executes the PDF operations
> individually need not execute this function. If the function was not
> executed then an error occurred. From other comments in pdf_main.ps
> its possible that customers may be using these functions as well (see
> the comments above the definition of /pdfshowpage)
> This commit checks to see if the variable has been set, if it has then
> it is used, otherwise we rescan for transparency. This prevents the
> error, but uses the optimisation if its possible to do so.
> No differences expected
> Resource/Init/pdf_main.ps

## Version 9.20 (2016-09-26)

This is the fourteenth full release in the stable 9.x series, and is purely a maintenance release.

Highlights in this release include:

- The usual round of bug fixes, compatibility changes, and incremental improvements.

For a list of open issues, or to report problems, please visit bugs.ghostscript.com.

### Incompatible changes

- The planned device API tidy did not happen for this release, due to time pressures, but we still intend to undertake the following: We plan to somewhat tidy up the device API. We intend to remove deprecated device procs (methods/function pointers) and change the device API so every device proc takes a graphics state parameter (rather than the current scheme where only a very few procs take an imager state parameter). This should serve as notice to anyone maintaining a Ghostscript device outside the canonical source tree that you may (probably will) need to update your device(s) when these changes happen. Devices using only the non-deprecated procs should be trivial to update.

### Changelog

2016-09-20 18:07:51 +0100
Chris Liddell <chris.liddell@artifex.com>
1bd7f32d70549971b4a384c5865e1fd030f49f20

> Bug 697138: Fix --disable-sse2 to work with openjpeg
> OpenJPEG enables it's SSE code based on the compiler defining __SSE__ so we
> want to undefine that if we're not using SSE operations.
> Makefile.in
> configure.ac

2016-09-20 19:57:14 +0100
Robin Watts <robin.watts@artifex.com>
20b0255206254ebcce1cde0a4a63d74b0aedcecf

> Fix splay tree traversal (again)
> When setting up a traversal from a midpoint of the tree, we'd
> immediately trip into the "has hit the endpoint" code.
> Fix that.
> base/gsalloc.c

2016-09-20 09:03:31 -0700
Ray Johnston <ray.johnston@artifex.com>
0e1153bf2d344044cd9fdfb7706f829b63348118

> FitPage should not add in rotation if destination page is square.
> If the PageSize was square, it would be treated as "not landscape",
> but landscape pages in would be arbitrarily rotated.
> Note this does not change the bahavior of PS or EPS page fitting.
> TBD: Add an option to fit to a page and never rotate (FitPageNR)
> Resource/Init/pdf_main.ps

2016-09-20 16:48:45 +0100
Robin Watts <robin.watts@artifex.com>
570041cc341557da8521fdace380f837cc572a69

> Fix Memento crash
> When reallocing set the rawsize before attempting to write
> the post guard block.
> base/memento.c

2016-09-20 13:41:31 +0100
Robin Watts <robin.watts@artifex.com>
3dd5f4c6b02179422bd8686fceed1f4955221d90

> Sync Memento with MuPDF.
> base/memento.c
> base/memento.h

2016-09-20 13:04:51 +0100
Robin Watts <robin.watts@artifex.com>
4e01c57e0f0773e29bc6f921cfc677576e72739d

> Bug 697134: Tweak MEMENTO_GS_HACKS inclusion.
> Rather than rolling our own memset prototype in this case, use
> the one that gs provides.
> base/memento.c

2016-09-16 15:23:32 +0100
Chris Liddell <chris.liddell@artifex.com>
1a0104084a4dfdff77165d931bdc87849c8ad824

> Clump has_refs - follow up to commit 63f74ce6
> The function save_set_new() (where the original fix for 'has_refs' is located)
> is called in two circumstances: when creating a save level, and when destroying
> a save level.
> We have to retain the 'has_refs' value for the latter case for the garbager to
> function correctly, but doing so in the former results in the garbager
> sometimes scanning more memory than is really necessary (it can end up scanning
> ref memory from the previous save state, which is pointless since that cannot
> change).
> This change means that 'has_refs == true' will only be retained in the
> 'destroying a save level' case (which works correctly because, by the time the
> function is called, we've already returned the relevant allocated to its
> previous state).
> psi/isave.c

2016-09-15 14:14:35 -0700
Ray Johnston <ray.johnston@artifex.com>
bfffe2011e1c8ffe53a432424b049f3989d6174a

> Fix bug 697097. SMask subpixel offset must match image offset.
> The dda used to select the source pixel for mapping into the image
> must use the same stepping for gray (monochrome) and color images
> since an SMask is monochrome and the image may be in color. This is
> primarily evident with the bug file since Matte is used to indicate
> that the source data is premuliplied. Colors can shift a LOT since
> the removal of the premultiplication can expand mistaked.
> base/gxicolor.c

2016-09-14 16:31:56 +0100
Ken Sharp <ken.sharp@artifex.com>
5521e702af192e06f186d0d741f24097eb5b8e26

> PDF interpreter - fix for GSView 5
> Commit 093bd18bd923644fcd25c507088c0ebc63b4c320 included an
> 'optimisation' to prevent rescanning for transparency if we had already
> scanned. However, this assumed that the function pdfshowpage_setup
> had already been executed in order to set a variable.
> This is always true when running files via Ghostscript, but any
> application (such as GSView 5) which executes the PDF operations
> individually need not execute this function. If the function was not
> executed then an error occurred. From other comments in pdf_main.ps
> its possible that customers may be using these functions as well (see
> the comments above the definition of /pdfshowpage)
> This commit checks to see if the variable has been set, if it has then
> it is used, otherwise we rescan for transparency. This prevents the
> error, but uses the optimisation if its possible to do so.
> No differences expected
> Resource/Init/pdf_main.ps

2016-09-14 10:40:36 +0100
Chris Liddell <chris.liddell@artifex.com>
79c79254908fe69462407c60966dd10521b4a9ac

> Copyrights, dates etc
> doc/API.htm
> doc/C-style.htm
> doc/Commprod.htm
> doc/DLL.htm
> doc/Deprecated.htm
> doc/Details8.htm
> doc/Details9.htm
> doc/Develop.htm
> doc/Devices.htm
> doc/Drivers.htm
> doc/Fonts.htm
> doc/Helpers.htm
> doc/History1.htm
> doc/History2.htm
> doc/History3.htm
> doc/History4.htm
> doc/History5.htm
> doc/History6.htm
> doc/History7.htm
> doc/History8.htm
> doc/History9.htm
> doc/Install.htm
> doc/Issues.htm
> doc/Language.htm
> doc/Lib.htm
> doc/Make.htm
> doc/News.htm
> doc/Projects.htm
> doc/Ps-style.htm
> doc/Ps2epsi.htm
> doc/Psfiles.htm
> doc/Readme.htm
> doc/Release.htm
> doc/SavedPages.htm
> doc/Source.htm
> doc/Unix-lpr.htm
> doc/Use.htm
> doc/VectorDevices.htm
> doc/WhatIsGS.htm
> doc/Xfonts.htm
> doc/gs-vms.hlp
> doc/sample_downscale_device.htm
> doc/thirdparty.htm
> man/dvipdf.1
> man/font2c.1
> man/gs.1
> man/gslp.1
> man/gsnd.1
> man/pdf2dsc.1
> man/pdf2ps.1
> man/pf2afm.1
> man/pfbtopfa.1
> man/printafm.1
> man/ps2ascii.1
> man/ps2epsi.1
> man/ps2pdf.1
> man/ps2pdfwr.1
> man/ps2ps.1
> man/wftopfa.1
> psi/msvc.mak

2016-09-14 10:34:52 +0100
Chris Liddell <chris.liddell@artifex.com>
703223237fe84cff31628e78a511cf60ef632969

> Change product family for RC
> Plus dates
> base/gscdef.c
> base/version.mak

2016-09-07 11:05:08 +0100
Chris Liddell <chris.liddell@artifex.com>
cd181f9d5cb9b2cd589cb43b0d06b1e6ebc579b4

> Bug 697102 - AddressSanitizer: buffer overflow solid_pattern_data
> Although (likely) benign, solving this is trivial: give the rendering code
> a ushort rather than a single byte.
> pcl/pcl/pcbiptrn.c

2016-09-07 11:33:28 +0100
Chris Liddell <chris.liddell@artifex.com>
cd95789bc8eaf0e86f902c8ba3f796340ffdad25

> Ensure PCL/XPS free all their memory.
> Noticed in passing (thrown up by ASAN): the plmain code was not fully shutting
> down the memory manager when using the chunk allocator.
> This commit adds a convenient function (gs_memory_chunk_wrap) and a
> pl_alloc_finit() function to ensure that all happens.
> base/gsmalloc.c
> base/gsmchunk.c
> base/gsmchunk.h
> pcl/pl/plalloc.c
> pcl/pl/plalloc.h
> pcl/pl/plmain.c

2016-09-07 09:58:50 +0100
Chris Liddell <chris.liddell@artifex.com>
dbfde5f3400e97b6d9b71a6549ff419dcefc9a95

> Bug 696599: cast disguised wrong type dereference.
> The code was casting to a gx_device_printer to get to the BLS_force_memory
> value, but since the target device for a clist device is no longer
> necessarily a printer device, it wasn't guaranteed that the struct contained
> that entry.
> So move BLS_force_memory to the base device type (gx_device), so it's always
> available.
> base/gdevprn.h
> base/gxclbits.c
> base/gxdevcli.h
> base/gxdevice.h
> devices/gdevbit.c

2016-09-12 19:31:49 +0100
Ken Sharp <ken.sharp@artifex.com>
8e541e3e356624506720fddd26441a2c43d82024

> pdfwrite - don't reset the graphics state object for new XObject streams
> Bug #697109 "Inkscape graphics in Latex PDF distorted on compression"
> When starting a new substream the pdfwrite code always resets the current
> graphics state to the 'initial' state. This seem, to me, utterly wrong,
> if we have changed the graphics state, then it persists into any
> 'substreams'.
> Indeed, in this case we set the dash array, then the fact that we have
> transparency causes us to push a new group, this starts a new substream,
> we reset the graphics parameters (including the dash). Then we set the
> dash pattern to the default and stroke a path. If we didn't start a
> group we would notice the dash had changed and emit the change. However
> because the group causes a reset, we see the dash change to the same as
> it currently is, so we don't emit it.
> I'm not totally happy with this change, there are a *lot* of subtleties
> in the code, not least the (bonkers) fact that starting a group *does*
> reset 3 extended graphics state parameters (SMask and constant alpha).
> It looks like we have some assumptions built in elsewhere as well. If
> I don't reset all the parameters then some other files start to fail.
> This fix doesn't reset the graphics state for XObjects, but does for
> everything else. For XObjects it only resets the 3 group parameters.
> I'd spend more time on this but I want to get some sort of fix into the
> 9.20 release. This definitely needs more investigation.
> There are a number of diffs, most are definite progressions, a few that
> I can't be sure of but they don't seem any worse (and in some cases the
> original file is technically broken anyway). Oddly there are more
> progressions when rendering to halftoned devices, I can only assume
> that we were previously emitting a broken halftone.
> devices/vector/gdevpdti.c

2016-09-12 17:50:45 +0100
Chris Liddell <chris.liddell@artifex.com>
d1ef839f4c41645cdba9524d0062c5aa2c533818

> Bug 697110: Ensure stream 'file_limit' is correct
> Follow-on from commit 4b101952d81a5899972f81f7b18ef3becd5bd45e
> There are several places that set, and check the value of file_limit for
> streams. Ensure they all use the requisite value whether the gs_offset_t is
> 64 bit (normal) or 32 bit (abnormal).
> To make it easier, and more consistent, pull the logic out into a macro.
> base/gsioram.c
> base/gsiorom.c
> base/sfxfd.c
> base/sfxstdio.c
> base/stream.h
> psi/zfrsd.c
> psi/ziodevsc.c

2016-09-09 07:54:26 +0200
Janssen <njj@ocevenlo.oce.net>
efdd255f800b4f1bc22e81d686691aa1b48f785f

> Bug 697088, HPGL not printing PCL downloaded font.
> The hpgl_map_symbol() function is modified to handle downloaded
> (bound) pcl fonts correctly. HPGL and PCL now use the same
> char_is_printable() function to detect printable characters.
> modified: pcl/pcl/pcstate.h
> modified: pcl/pcl/pctext.c
> modified: pcl/pcl/pglabel.c
> pcl/pcl/pcstate.h
> pcl/pcl/pctext.c
> pcl/pcl/pglabel.c

2016-09-11 10:52:58 +0100
Ken Sharp <ken.sharp@artifex.com>
e25d823decd905a4917d26fe3d08a15af12eb1a6

> pdfwrite - another guard against a NULL clip path
> commit ab3a1249ce28e3cac629ce1466d17e635ff50fab introduced a check
> to ensure a clip path wasn't null before using it. This caused Coverity
> to then check the use of that clip path throughout the function, and
> identify another area needing a check.
> devices/vector/gdevpdte.c

2016-09-10 11:52:38 -0700
Ray Johnston <ray.johnston@artifex.com>
aa23930545649007079b17057083c1725427c558

> Apply fix suggested in Bug 697108 to prevent infinite loop
> Hopefully the last missed increment of a loop variable in the image
> interpolation code.
> Thanks to Jonathan Dagresta for the patch.
> base/gxiscale.c

2016-09-09 12:15:44 +0100
Chris Liddell <chris.liddell@artifex.com>
cca3ba8087dbec47a6e7a8e5368da9e28fb81663

> Add building a 'stripped' shared lib.
> configure.ac now finds the 'strip' exe.
> There's a new target 'so-only-stripped' which builds the .so libs and then
> strips them using the supplied strip exe
> Makefile.in
> base/unix-dll.mak
> configure.ac

2016-09-09 09:05:31 +0100
Chris Liddell <chris.liddell@artifex.com>
0783d723673f60099d6cdaa47431d6fd2bfad68b

> Tweak .so target to not have a "main" function.
> base/unix-dll.mak
> base/unixlink.mak

2016-09-08 15:10:47 -0600
Henry Stiles <henry.stiles@artifex.com>
e088b1dfdaab9dc66b96b2f2d022384f6258a822

> Bug #696658 - 2 ligatures had incorrect mappings.
> The unicode values were wrong for ff and fi. With this fix and the
> new URW fonts the problem reported is fixed.
> pcl/pl/plsymbol.c

2016-09-08 09:12:52 +0100
Ken Sharp <ken.sharp@artifex.com>
e221dcd1b756f2a6e04531876e43b587fa8577b1

> pdfwrite - don't attempt to keep co-ordinates <32K when creating PDF 1.5+
> Bug #697098 "pdfwrite charpath conversion problem"
> When the PDFCompatibilityLevel is 1.5 or above we can use reals with
> sensible ranges, instead of the +/- 32767 that old versions of the
> specification limited us to.
> This results in a large number of small differences, some minor progressions
> devices/vector/gdevpdfd.c

2016-09-07 16:11:58 +0100
Ken Sharp <ken.sharp@artifex.com>
e644fc3454bf84555b2d8369138d2f25bfbf6133

> pdfwrite - Don't limit the resolution when Compatibility > 1.4
> Bug #697098 "pdfwrite charpath conversion problem"
> This is not a fix, but a work-around, especially for future files.
> We currently limit the resolution by checking the media size to see if
> it lies in the range +/- 16,000. This is because The PDF Reference states
> that co-ordinates are real numbers, and versions of the spec prior to
> 1.5 have a limit of +/- 32,767 for real numbers. In practice it was
> noted that Acrobat Reader couldn't even cope with numbers that large so
> we arbitrarily settled on 16,384 and then allowed a bit of slop.
> With the PDF 1.5 specification (now 13 years old) this limit was raised
> to +/- 3.403x10^38
> In the interim we have also raised our default PDF creation to 1.5 and
> we have adopted other means (altering the CTM) to keep co-ordinates
> in the 32,767 range. So there is really no reason to maintain this old
> hack.
> devices/vector/gdevpdfp.c

2016-09-07 16:03:02 +0100
Ken Sharp <ken.sharp@artifex.com>
ab3a1249ce28e3cac629ce1466d17e635ff50fab

> pdfwrite - guard against an empty clip path
> Noticed while doing other work, if we don't have a clip path, we must
> not attempt to use it to clip text.....
> No differences expected
> devices/vector/gdevpdte.c

2016-09-07 10:37:27 -0700
Ray Johnston <ray.johnston@artifex.com>
c835d00d51a70d410e0092f9442d30bcf38e95f1

> Soft Mask Matte Entry Bug 697097
> Included getting the Matte color entries to the
> transparency compositor action (Thanks to Ray)
> and undoing the preblend with the Matte bias.
> Resource/Init/pdf_draw.ps
> base/gdevp14.c
> base/gdevp14.h
> base/gstparam.h
> base/gstrans.c
> base/gstrans.h
> base/gxblend1.c
> psi/ztrans.c

2016-09-07 07:17:26 -0700
Ray Johnston <ray.johnston@artifex.com>
4b101952d81a5899972f81f7b18ef3becd5bd45e

> Fix sread_subfile check for file_limit when gs_offset_t is bigger than long.
> The file_limit was initialized in sread_file and swrite_file to the largest
> gs_offset_t value, but the check only compared to max_long.
> base/sfxstdio.c

2016-09-04 10:51:06 -0700
Ray Johnston <ray.johnston@artifex.com>
527450e2ef1eca2ad26cdfba3a4f667e90bfd992

> Fix typo introduced in commit c9f24068
> Resource/Init/pdf_main.ps

2016-09-02 10:37:59 -0700
Ray Johnston <ray.johnston@artifex.com>
57387434f2bfefea94445b095465dfb621855ba1

> Fix is_big_mask calculation to be sqrt(a*a + b*b)
> Resource/Init/pdf_draw.ps

2016-09-01 07:44:23 -0700
Ray Johnston <ray.johnston@artifex.com>
a127d73fc54024ad7aa6a73703c642527137d4ac

> Add findrgbcustomcolor as requested by customer 400.
> This appears to be used in the AI5 ProcSet of Adobe Illustrator (R)
> Version 7.0 Full Prolog and allows us to construct a Separation
> space that has a DeviceRGB alternate colorspace and tint transform.
> There is no Adobe documentation that mentions this, but I found one
> other implementation that had this procedure defined.
> Also fix missing pop when setcustomcolor is invoked with tint == null
> Resource/Init/gs_lev2.ps

2016-08-30 12:59:37 -0600
Henry Stiles <henry.stiles@artifex.com>
776b12c8b6051cad5c6e1839a00f20221b33731d

> Bug 697032 - remove files with unsuitable licenses
> contrib/japanese/doc/djgpp.txt
> contrib/japanese/doc/gdevmag.txt
> contrib/japanese/doc/gs261j.euc
> contrib/japanese/doc/gs261j.txt

2016-08-30 12:43:58 -0600
Henry Stiles <henry.stiles@artifex.com>
605f61b950d79204762198e67c9700b9410b465e

> Bug 697032, remove chess.ps
> examples/chess.ps

2016-08-30 08:33:32 -0700
Ray Johnston <ray.johnston@artifex.com>
dd8d83665f5e32ce7057e3ca2e8662eabb195c2a

> Add mention of PostRenderProfile option in documentation.
> doc/Devices.htm
> doc/sample_downscale_device.htm

2016-08-30 16:03:00 +0100
Chris Liddell <chris.liddell@artifex.com>
d26a2bb28aeeb5e94c501ff085bb52f72151f65b

> Bug 696867: strip trailing whitespace from configure.ac
> configure.ac

2016-08-26 15:44:24 +0100
Chris Liddell <chris.liddell@artifex.com>
66d905ba077ec5025299a7cd2074e66fac2e09d2

> Reinstate pointer alignment special case for sparc and hpux
> The configure check for required pointer alignment works on Linux/SPARC, but
> not on Solaris/SPARC - so reinstate the special case code in genarch.c
> I'm including the HP/UX case as well since it's safer, and does not add
> to the complexity of code.
> base/genarch.c

2016-08-26 15:12:19 +0100
Chris Liddell <chris.liddell@artifex.com>
c6290b83763b6a7022112886517d23ce3d2140ca

> Bug 697064: FAPI: work around compiler bug
> The Sun cc compiler optimizer has bug that *seems* to result in the order
> addition operations being changed (which isn't legal). In this case, we're
> unpacking bytes from a stream, and reordering the operations means the
> bytes come out of the stream in the wrong order.
> psi/zfapi.c

2016-08-26 13:44:49 -0700
Ray Johnston <ray.johnston@artifex.com>
b830052545cbcd5f31fc90edc8ddedf54eb9eded

> Fix a couple of minor typos in the Trap param section.
> doc/Devices.htm

2016-08-26 13:37:47 -0700
Ray Johnston <ray.johnston@artifex.com>
7bb57f5d37e246ceb551ed5821873239ab26034e

> Add documentaion and sample code for a CMYK 32-bit downscaling device
> doc/gdevds32.c
> doc/sample_downscale_device.htm

2016-08-29 13:46:13 -0600
Henry Stiles <henry.stiles@artifex.com>
a76c1e1c6bce85d01682e8e595b50ddabed5be3d

> Bug #696856 - fix memcmp being used on a structure.
> The bad memcmp was part of an obsolete implementation to include icc
> profiles in the photoshop device which is removed with this change.
> devices/gdevpsd.c

2016-08-29 12:46:47 -0600
Henry Stiles <henry.stiles@artifex.com>
6892b89fab66086346d754714806ce0870407970

> Fix 696929 - SetLineDash error.
> Many HP printer and our PXL interpreter limit the dash element array
> size to 20 so we shouldn't produce PCLXL that exceeds that limit.
> devices/vector/gdevpx.c

2016-08-26 12:12:37 -0600
Henry Stiles <henry.stiles@artifex.com>
2f18c60fd2aa43f59fbf197463aca30ea3a0bc2d

> Fix 697030 - Interpreter exit.
> If the vector device's begin image procedure fails fallback to using
> the default image code instead of producing an error.
> devices/vector/gdevpx.c

2016-08-25 13:26:13 -0700
Ray Johnston <ray.johnston@artifex.com>
124e9f44c03cc0d3773d18708ee285b75cb12c04

> Fix minor typo in devs.mak for the tiffscaled8 devcice
> devices/devs.mak

2016-08-25 08:56:58 +0100
Chris Liddell <chris.liddell@artifex.com>
af8dfa700dca2671ea9d81e01adb2db219c0bb2f

> Tweak the .a target
> Add an explicit "gslib" target, and have the .a end up in the "bin" direstory
> rather than the root of the tree.
> So, to build the .a now, you'd do "make gslib"
> base/unixlink.mak

2016-08-25 08:55:47 +0100
Chris Liddell <chris.liddell@artifex.com>
94913c07fe8c4863d925cf117664a07262c6fc9d

> Add a couple of headers for function prototypes
> abs() and memset() prototypes.
> Also, dependencies as required
> base/gp_psync.c
> base/gxht_thresh.c
> base/lib.mak

2016-08-24 10:12:59 -0700
Michael Vrhel <michael.vrhel@artifex.com>
7f08915e1b84fc15759ab8a3aacab47196bbaf32

> Bug 697060. -dUsePDFX3Profile and -dNumRenderingThreads
> When the output intent profile is used it was cloned from
> the target device, but it was not getting its initial settings
> in place. The threads do not need the post render profile nor
> the output intent profile (it is the device profile in this case)
> This was tested on -dUsePDFX3Profile, -dNumRenderingThreads=4
> -sPostRenderProfile="myprinter.icc" with the file Altona_Technical_v20_x4.pdf
> base/gsicc_manage.c
> base/gxclthrd.c

2016-08-24 07:49:53 -0700
Michael Vrhel <michael.vrhel@artifex.com>
8a8eefe5dcb1509aa5ebd7517438c755045bb139

> Bug 697059 Pattern and Spot Color
> If the only occurrence of a spot color was in a pattern,
> the equivalent CMYK values were not getting set for use
> by a separation device during the installation of the
> separation color space. This was due to the fact that
> the pattern accumulator bits device (whose target is the
> real device) has its update_spot_equivalent_color proc set
> to default which ends up doing nothing. Instead we now
> set the bits device proc to forward to the real target
> device.
> base/gxpcmap.c

2016-08-23 08:09:09 -0700
Ray Johnston <ray.johnston@artifex.com>
cc3192c4fddaccfe4d3199e944ae9a7b8edb5682

> Improve bug 696985. Performance issue (and large memory usage).
> The GC would run due to the 'system' VM which never had it's limit set (default
> 600,000), but after the GC ran the limits for all of the VM's were reset to
> the current allocated plus the limit, so the local VM and global VM were not
> in a state to be collected (pages ran in a save ... restore).
> Setting the system VM limit to the same value allows the file to complete
> in 84 seconds and only uses 74Mb (a cut down file that was 5k pages took 170
> seconds and used 634Mb before the change). The entire large file only needed
> 725 GC's to complete and most were for the local VM (space==12), rather than
> for the system VM (space==4).
> Also change the formatting of one of the gs_debug['0'] messages to keep all
> the relevant values on one line which makes searching/grepping easier.
> base/gsalloc.c
> psi/zvmem2.c

2016-08-22 15:10:17 -0700
Michael Vrhel <michael.vrhel@artifex.com>
e20ae050feea47ded0d96c49627ed5c7b3502db6

> Set default rendering condition to unspecified
> Also fix up a few memory issues with respect to the post render
> ICC profile.
> base/gsdevice.c
> base/gsicc_manage.c
> base/gxclthrd.c

2016-08-23 16:41:16 +0100
Chris Liddell <chris.liddell@artifex.com>
755eddab9cb238324dc84ac1fd5c9736314d8a48

> Partially revert "Change "GPL Ghostscript" to "Ghostscript""
> Change references from GPL to AGPL, but leave the product/project name
> as "GPL Ghostscript".
> base/gp_wgetv.c
> base/gscdef.c
> doc/Commprod.htm
> doc/Install.htm
> doc/Language.htm
> doc/Readme.htm
> doc/Release.htm
> psi/dwreg.c
> psi/mkfilelt.cpp
> psi/nsisinst.nsi

2016-08-22 08:52:26 +0100
Ken Sharp <ken.sharp@artifex.com>
5cbf2d0185ce6b268abffc275d72ffd1a6b5b18b

> PDF interpreter - honour /Intent for images
> Bug #697055 " Intent entry in Image Dictionary not honored"
> This causes a number of differences, most are not discernible, (careful
> scrutiny shows slightly brighter colour in a few of these) however
> icc_v4_profile.pdf shows a marked progression in one image
> (V4 CMYK profile).
> Resource/Init/pdf_draw.ps

2016-08-21 16:58:29 -0700
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
923d7bd2715f24a41a79894086b8106885a71ccd

> Dependency fix for gxscanc.c.
> The dependency gx.h was missing from the dependency list; this caused
> parallel builds to fail.
> base/lib.mak

2016-08-21 22:44:34 +0000
Hin-Tak Leung <hintak@ghostscript.com>
c9af5e8a5578b01714ddca0afa13b5707e3a14a9

> Revert a few line-breaks from the recent auto-indentation
> This is a cosmetic change - no modification to code logic.
> No cluster differences
> devices/vector/gdevpx.c

2016-08-20 20:38:16 +0000
Hin-Tak Leung <hintak@ghostscript.com>
1142ba29b19a819aba4cb89f029a6d15330ea11a

> Factoring out a long common expression, for readability.
> This is a cosmetic change, and does not affect the code logic.
> This part of the code had grown steadily in the past from
> stuff_1
> to
> (flipped ? stuff_2 : stuff_1)
> to
> if (!icc)
> (flipped ? stuff_2 : stuff_1)
> else
> (flipped ? stuff_2a : stuff_1a)
> No cluster differences
> devices/vector/gdevpx.c

2016-08-19 00:40:16 +0100
Hin-Tak Leung <hintak@ghostscript.com>
ada0c784640fcd355a0d6a1b2132dafad14f21bc

> Auto-indent according to doc/C-style.htm
> Running
> indent -bad -nbap -nsob -br -ce -cli4 -npcs -ncs -i4 -di0 -psl -lp -lps -nut
> , according to doc/C-style.htm
> This fixes some inconsistent tabs and indentations accumulated over the years.
> No cluster differences
> devices/vector/gdevpx.c

2016-08-19 00:56:29 +0000
Hin-Tak Leung <hintak@ghostscript.com>
764812e438e1a94afa09a8b46fa017d8cb287fac

> Add a few semi-colons and manually breaking a few lines
> This is a non-code-logic change to assist the next step, auto-indentation.
> No cluster differences
> devices/vector/gdevpx.c

2016-08-19 00:00:13 +0100
Hin-Tak Leung <hintak@ghostscript.com>
62898632f38230fc778f929ab4ea4469b36ac3b4

> Use default unoptimized code path for non-CMYK and inverted images.
> 5 of the test files have 32-bit images which the new CMYK code does
> not process correctly. So we revert back to the unoptimized code
> path for them.
> 1 with 32-bit DeviceN:
> tests_private/comparefiles/Bug692494.pdf
> 4 have inverted Decode arrays ([1 0 1 0 1 0 1 0]) - i.e. they
> are RGBW rather than CMYK. It is probably not hard to cope with them
> also, but push them back onto the unoptimized code path for now:
> tests_private/comparefiles/Bug696487.pdf
> tests_private/comparefiles/z400454b01d4-1.pdf
> tests_private/pdf/PDFIA1.7_SUBSET/CATX6554.pdf
> tests_private/pdf/sumatra/1610_-_Decode_ignored_for_JPX_images_regression_from_r2055_.pdf
> No cluster differences
> devices/vector/gdevpx.c

2016-08-18 23:16:16 +0100
Hin-Tak Leung <hintak@ghostscript.com>
cf72ede2c68e1f76530b1da86dfda70e8ee5295c

> Calculate correctly the offset for the last (incomplete) strip of a flipped image for icc
> The ICC-transform code path was never thoroughly tested. PXL can do rotated
> but not reflected images; we worked around this limitation by processing the
> scanlines from the end of the buffer backward. For an incomplete strip, we
> therefore need to offset into the final buffer. The offset is different for
> pre-icc code path vs icc-transformed code path.
> Affected files:
> tests_private/comparefiles/besttest.pdf
> tests_private/pdf/PDFIA1.7_SUBSET/CATX4547.pdf
> tests_private/pdf/sumatra/x_-_text_clipped_away_above_141_pc.pdf
> No cluster differences
> devices/vector/gdevpx.c

2016-08-17 03:17:41 +0000
Hin-Tak Leung <hintak@ghostscript.com>
50aa6f1bcb7035c3eb7f6e0d3e502ae021ba681e

> Allow 32-bit CMYK image (converted to 24-bit RGB) to be jpeg compressed.
> Previously, anything except 24-bit RGB is forbidden from going through
> jpeg compression, because anything other than image does not make sense.
> RLE and DeltaRow can apply to general byte-stream data, not jpeg.
> This is another part of the enhancement for bug 696905, and depends
> on the previous two of this group. The previous two changes convert
> 32-bit CMYK data to 24-bit RGB internally, either through
> DeviceCMYK->RGB or icc. So this change is just a one-liner.
> No cluster differences
> devices/vector/gdevpx.c

2016-08-13 21:36:54 +0000
Hin-Tak Leung <hintak@ghostscript.com>
cea5c6072c1e224fea7c0a7334d943cc1250ad5b

> Make 32-bit CMYK image icc-proccessed, unless UseFastColor is specified.
> This is a further part of the enhancement for bug 696905.
> There is a big block of comments about a previous change of
> pclxl_can_handle_color_space() (introduced in bug 692329)
> being wrong and causes slightly wrong colors. That needs to be
> looked at eventually, and this change updated.
> No cluster differences
> devices/vector/gdevpx.c

2016-08-10 14:31:47 +0000
Hin-Tak Leung <hintak@ghostscript.com>
967460041394c2ece02aedf9dba59ef4a3137f28

> Optimize for CMYK image inputs in pxlcolor/pxlmono
> This is part of the enhancement for bug 696905.
> pxlcolor/pxlmono is not supposed to be colour-accurate. This change must be
> used together with -dUseFastColor=true, or there will be unsighty colour
> tiling between image portions under different colour management, or lack of.
> No cluster differences
> devices/vector/gdevpx.c

2016-08-16 16:24:06 -0700
Ray Johnston <ray.johnston@artifex.com>
0a5e560e38f47b19257debff272adbe3acacbfab

> Fix -dDisplayFormat=16#20808 that caused 50% Cyan background with transparency.
> This was broken in commit 4e44c99 that added a clist device when transparency
> caused MaxBitmap to be exceeded. The values for max_gray and dither_grays in
> the color_info for the pdf14_accum_CMYK were incorrectly initialized confusing
> the gx_default_encode_color and COLROUND macros.
> base/gdevp14.c

2012-04-23 18:14:29 +0100
Robin Watts <robin.watts@artifex.com>
18ef67078eb63103ed5e0de627296cb86f493d42

> Bug 696636: New scan converter.
> This commit adds a new scan converter implementation designed
> to address some of the problems seen with 'busy' paths in the
> current implementation.
> No 'active line list' is kept, instead we run through the path
> generating a buffer of scanline edge intersections. This trades
> repeated sorting of the active list against potentially higher
> memory usage.
> This code has 2 pairs of different variants. Each pair copes
> with 'centre of pixel' and 'any part of a pixel' rendering
> modes. One pair scan converts to rectangles, another pair to
> trapezoids.
> These routine does not give identical results to the old code,
> partly due to (minimal) rounding issues, but more due to the
> fact that the new code is only equivalent to adjust values of
> 0 or 0.5.
> GS uses intermediate adjust values by default (such as 0.3)
> when rasterising at low resolution (< 150dpi). In such cases
> this new code will cover more than the old code did. It is
> hoped that the impact of this is reduced due to the fact we
> use freetype for character rendering now.
> This new scan converter is disabled by default. To enable it,
> set the scanconverter value to be non-zero. This is most easily
> achieved by using -dSCANCONVERTERTYPE=1 on the command line.
> Runs vastly faster on the cases highlighted in bugs 692351
> and 691984.
> base/gslibctx.h
> base/gspaint.c
> base/gxfill.c
> base/gxscanc.c
> base/gxscanc.h
> base/lib.mak
> windows/ghostscript.vcproj

2016-08-11 14:12:52 +0100
Robin Watts <robin.watts@artifex.com>
bb689d1d01b339088d89b98b5eabef0c195cfdc4

> Scan converter configuration code.
> Here, we introduce the notion of "which scan converter are
> we using" to the core library. This is an integer value
> in gs_lib_ctx_t which (currently) defaults to 1.
> We add graphics library calls to get/set this value, and
> new operators reflecting these into postscript.
> In addition, we update both the PCL frontend and the PS init
> code so that -dSCANCONVERTERTYPE can be used on the command
> line to set the desired scan converter value.
> -dSCANCONVERTERTYPE or -dSCANCONVERTERTYPE=1 will set it to
> 1. -dSCANCONVERTERTYPE=false or -dSCANCONVERTERTYPE=0 will
> set it to 0. Otherwise -dSCANCONVERTERTYPE=<int> will set
> it to the required value.
> Currently we only have the one scan converter in gs, hence
> setting this value makes no difference. A subsequent commit
> (probably the very next one) will introduce an alternative
> scan converter that will be disabled by default, but can be
> enabled by setting this value. This commit merely prepares
> the framework for that to fit into.
> The intent is that:
> 0 (or lower) will mean "The old scan converter"
> 1 will mean "The default scan converter"
> 2 (or higher) will mean new scan converters yet to be defined.
> Thanks to Ken for the postscript code.
> Resource/Init/gs_init.ps
> base/gslibctx.c
> base/gslibctx.h
> base/gsstate.c
> base/gsstate.h
> pcl/pcl/pcstate.h
> pcl/pcl/pctop.c
> pcl/pl/plmain.c
> pcl/pl/plmain.h
> pcl/pl/pltop.h
> pcl/pxl/pxpthr.c
> psi/int.mak
> psi/zmisc.c

2016-08-19 16:17:39 +0100
Robin Watts <robin.watts@artifex.com>
1fbbfeb5dc9d1a12c8ed2e4640e59c416450e478

> Bug 697056: Fix LCMS static init of critical section.
> LCMS2 relies on being able to statically init a mutex
> (actually a Critical Section on windows). Windows has
> no official API for statically initing a critical
> section, so lcms2 uses a hack (albeit it a safe one)
> to do this.
> Unfortunately ApplicationVerifier (and presumably other
> similar tools) don't understand this idiom, and get
> confused by not seeing an explicit initialisation call.
> This is causing problems for a customer.
> This commit therefore introduces code to properly
> initialise it on Windows. In order to avoid any possible
> multithreaded startup issues, we use the Windows
> InterlockedCompareExchangePointer API (introduced in
> Windows XP).
> If anyone wants to avoid this code (so they can work
> on pre-Windows XP), they can build with:
> CMS_RELY_ON_WINDOWS_STATIC_MUTEX_INIT
> defined, and get the old behaviour. We automatically
> set this when building with any version of MSVC older
> than VS2005 (i.e. those that don't have that API
> available).
> lcms2/src/cmsplugin.c
> lcms2/src/lcms2_internal.h

2016-08-17 18:40:01 +0100
Robin Watts <robin.watts@artifex.com>
31bdc6bb9587da08d0aecddfee2533e8368706d4

> MSVC solution: Reorder files in XML.
> MSVC has sorted the list of files alphabetically, and this moved
> one. This should be an invisible change.
> windows/ghostscript.vcproj

2016-08-17 15:05:02 +0100
Robin Watts <robin.watts@artifex.com>
16fa0fbe02250839ff9c953245b5962a65c816cb

> Bug 697044: Fix indeterminism in tiffscaled
> When downscaling by a factor of 3, we render at the usual device
> width, then take groups of 9 (3*3) pixels to combine them
> together.
> Externally from the downscaler we were rounding the scaled size
> down, whereas internally we were rounding it up.
> This means we'd potentially be calculating 1 more pixel than we
> actually needed, using some uninitialised data.
> Now we round down both internally and externally.
> base/gxdownscale.c

2016-08-17 07:46:59 +0100
Chris Liddell <chris.liddell@artifex.com>
7dee0903b551b43e40bfa12aabce1061c0dae171

> Change "GPL Ghostscript" to "Ghostscript"
> and various other instances of GPL to APGL.
> Note that this means changing the product string (Postscript visible),
> and all the Windows registry keys we use.
> base/gp_wgetv.c
> base/gscdef.c
> doc/Commprod.htm
> doc/Install.htm
> doc/Language.htm
> doc/Make.htm
> doc/Readme.htm
> doc/Release.htm
> doc/thirdparty.htm
> psi/dwreg.c
> psi/mkfilelt.cpp
> psi/nsisinst.nsi

2016-08-10 11:27:57 -0700
Ray Johnston <ray.johnston@artifex.com>
7eda41b6392a09256447cccbe8b770717f5122f2

> Remove the RECT_RECOVER and VMerror retrying logic from the clist
> The entire concept relies on recovery by being able to store an entire
> page raster image somewhere when the clist writing gets a VMerror, but
> if we have room for a page, we could have used page mode in the first
> place and totally avoid clist complexity VMerrors. Rip this code out
> to make the clist more readable and maintainable.
> base/gdevprn.c
> base/gdevprn.h
> base/gxcldev.h
> base/gxclimag.c
> base/gxclist.c
> base/gxclist.h
> base/gxclpath.c
> base/gxclrect.c
> base/gxclutil.c
> devices/gdevbit.c

2016-08-10 07:32:29 -0700
Ray Johnston <ray.johnston@artifex.com>
a1c3ce81d35c869a2385c3f3e08250c484cfb2ab

> Remove all traces of the (probably bit-rotted) async renderer
> This has mostly been replaced by BGPrint and saved-pages (except for
> a queue), but that will be added differently in the future.
> base/gdevprn.c
> base/gdevprn.h
> base/gdevprna.c
> base/gdevprna.h
> base/gxpageq.c
> base/gxpageq.h
> base/lib.mak
> devices/devs.mak
> devices/gdevbit.c
> devices/gdevbmpa.c

2016-08-11 14:56:47 +0100
Robin Watts <robin.watts@artifex.com>
ce7245f9b4eb21af76310790ac0f1ec92e237e90

> Update PCL command line parser arg handling.
> Certain "special" params are interpreted directly by the pcl
> build, and handled directly. (Namely, BATCH, NOPAUSE,
> NOINTERPOLATE and NOCACHE).
> The current code can only cope with these being being used
> with no argument. i.e. -dNOINTERPOLATE will be accepted, but
> -dNOINTERPOLATE=1 will not trigger the no interpolation code.
> Here we change the code so that we now decide whether the arg is
> a 'special' one or a normal param at the last moment, and
> correctly raise errors if the values are set out of line.
> pcl/pl/plmain.c

2016-08-11 14:55:48 +0100
Robin Watts <robin.watts@artifex.com>
f3703d439ebea68be96654e1f74f7e77c62eb823

> Fix error/warning in PCL build.
> return of a function returning void is not allowed in C,
> even though it semantically makes sense.
> pcl/pcl/pcwhtidx.c

2016-08-11 17:50:03 +0100
Chris Liddell <chris.liddell@artifex.com>
df3d872f9e561a119eb29e7dcc25d0a466ea4a00

> Decrement rather than free reference counted object
> Commit b9a265a02b7d1 fixed the unintialised reference count data for the
> cie_joint_caches in a temporary gstate created during CIE to ICC conversion.
> I hadn't realised it was explicitly freed later on, rather than either
> had the ref count decremented, or left to the default gstate freeing to deal
> with. This was causing a C lib error on Windows, and a valgrind error on
> Linux.
> Switching to using the reference counting machinery resolves the problem.
> base/gscie.c

2016-08-10 15:55:50 +0100
Ken Sharp <ken.sharp@artifex.com>
684457fff0bb980c719cd40de63b6f322068d9ce

> Add a specific licence comment to ramfs.h
> base/ramfs.h

2016-08-09 17:12:31 +0100
Chris Liddell <chris.liddell@artifex.com>
7c247cba2ee612b61cad624cb4915d4dbfbb6ce0

> Further compensation for Freetype number representation
> base/fapi_ft.c

2016-08-08 15:34:27 +0100
Chris Liddell <chris.liddell@artifex.com>
b259a1f93ad59636b9c95a57d86484e53aff47a6

> Have configure add flag for AIX large file support
> AIX uses a different pre-preprocessor directive to enable access to the >2Gb
> file operations (fopen64 etc). Further, adding the AIX one in the same place
> as the existing one (base/stdpre.h) does not work.
> So, have configure add -D_LARGE_FILES to the CFLAGS on AIX.
> configure.ac

2016-08-04 19:12:19 +0100
Chris Liddell <chris.liddell@artifex.com>
63f74ce638cce033f724f42ec9393056c880e37f

> Preserve the clump has_refs flag.
> refs are handled specially by the garbager and during a restore operation, so
> it's worth, during a save, restting the flag if no refs are left in a clump.
> *But*, for the garbager to work correctly, we *must* ensure the flag is set
> when refs are still in a given clump.
> psi/isave.c

2016-08-08 12:34:28 -0700
Ray Johnston <ray.johnston@artifex.com>
12d4dd43bab634a24a4b602e799ea1e550ab769f

> Fix global/local VM issue with gstate that b9a265a trips over.
> The commit to perform finalization cleanup of gstates had problems at
> the alloc_restore_all when global memory was finalized because local
> memory was already freed, but there was still "savedinitalgstate" in
> systemdict that was in global VM but that had elements that were in
> local VM.
> Also .forceundef savedinitialgstate in systemdict to avoid leaving
> a pointer to localVM from systemdict. This isn't strictly needed
> since systemdict isn't ever traced by restore_finalize.
> Resource/Init/gs_dps.ps
> psi/imain.c

2016-08-08 17:00:54 +0100
Ken Sharp <ken.sharp@artifex.com>
90c660a5e1d45bee0e15ee46bf9c54d19f3f635f

> pdfwrite - check return values
> picked up by scan-build, I carelessly forgot to check the return value
> from pdf_add_resource.
> devices/vector/gdevpdfi.c

2016-08-08 13:19:50 +0100
Ken Sharp <ken.sharp@artifex.com>
f7ffeb0319e112a1657987a9e5bad5b0f834a074

> pdfwrite - permit nested Forms in PDF output
> Bug #696986 "Add support for nested PostScript forms as nested Form XObjects in pdfwrite"
> Previously we checked for nested forms and 'unrolled' the child form(s)
> into the parent PaintProc. However a simple extension (declaring the
> child Form XObject(s) as Resources for the parent) permits us to have
> nested forms.
> Note that the way our PostScript output (from ps2write) works, it is
> not possible to support nested forms, so in this case we continue to
> unroll the child PaintProc into the parent. The code works, despite
> the inefficiency.
> devices/vector/gdevpdfi.c

2016-08-08 13:16:28 +0100
Ken Sharp <ken.sharp@artifex.com>
5f4319612f1837f89b9586a5695018d3554325d8

> PosScript interpreter - don't error on nested forms
> In commit fa20f5915978823a8c72a80e49fa90ce9c5c5879 I added code to check
> if a Form PaintProc illegally left junk on the stack after execution
> and cleaned it up if it did (issuing a warning).
> However, the code didn't cease checking when it found the first Form
> dictionary, which meant that if there were two Form dictionaries on the
> stack (nested forms) then we would throw an error.
> This commit simply terminates the loop when we find and check a Form
> dictionary. If forms are nested then terminating the enclosing form will
> lead it to check its own dictionary on the stack and so on.
> Resource/Init/gs_lev2.ps

2016-07-27 19:48:39 -0700
Ray Johnston <ray.johnston@artifex.com>
b9a265a02b7d1522fa56a353eb2bd0074ef3c715

> Fix memory leak due to PDF interpreter DefaultQstate losing scope
> The graphics state is mostly tracked during gsave/grestore operations,
> but the 'gstate' operator can result in a graphics state not being
> freed until a garbage collection. Add a 'finalization' function for
> gstates to deal with this.
> The alloc_restore_all function needs to do gs_grestoreall_for_restore
> so that the gstates don't end up with dangling pointers, so pass the
> interpreter context instead of the dual memory pointer so it can call
> that function.
> Thanks to Chris for coming up with this approach to the 'finit' freeing,
> and finding the fix for a SEGV due missing rc_init in gx_cie_to_xyz_alloc
> that affected a couple of PS FTS files.
> base/gscie.c
> base/gsicc_cache.c
> base/gsstate.c
> base/gxgstate.h
> psi/imain.c
> psi/int.mak
> psi/isave.c
> psi/isave.h
> psi/zvmem.c

2016-08-03 11:52:43 -0600
Henry Stiles <henry.stiles@artifex.com>
feaaad91269f7515692f911f29c93b3c4b6d0477

> Bug 696983 - Fix bidirectional XPS spacing.
> Bidirectional setting was not accounted for when advance width was set
> in the XPS Indices Attribute.
> xps/xpsglyphs.c

2016-06-15 08:04:41 -0600
Henry Stiles <henry.stiles@artifex.com>
af706ab3fafd2671d30fe82e4ebd431610c15d6c

> Fix Coverity ID 102148, buffer not terminated.
> Also, require the client to pass in a file name without spaces as a
> routine precondition instead of trying to replace spaces with
> underscores each time a font is built.
> Note gs_font_name is a ghostscript string with a size but also requires
> null termination, see the typedef's header file.
> pcl/pcl/pglabel.c
> pcl/pl/plfont.c
> pcl/pl/pllfont.c
> pcl/pl/plufont.c
> pcl/pl/plulfont.c

2016-08-03 16:33:14 +0100
Ken Sharp <ken.sharp@artifex.com>
deac5c942561bc044499987e86aa46eaa7abd495

> pdfwrite - don't complain about linearising encrypted files, when not linearinsing
> devices/vector/gdevpdfp.c

2016-07-11 10:36:27 -0700
Ray Johnston <ray.johnston@artifex.com>
093bd18bd923644fcd25c507088c0ebc63b4c320

> Support CompatibleOverprint in the interpreter (bug 696876)
> If the device is not a HighLevelDevice and the device supports
> overprint (ProcessColorModel == /DeviceCMYK) then transparency needs
> to treat painting operations differently by pushing a non-isolated,
> non-knockout group and set the BlendMode to CompatibleOverprint.
> Also the opacityalpha needs to be 1 during painting in this group.
> Note that although the interpreter now has code for fill, stroke,
> 'sh' (shaded fills), text and images, our regression suite does
> not seem to have OP with transparency for the 'sh' op (yet).
> Out of all of our PDF test files, only 21 trigger this code
> (including all of the PDF ATS files that are not run as part of
> the commit regression tests.
> Resource/Init/pdf_draw.ps
> Resource/Init/pdf_main.ps
> Resource/Init/pdf_ops.ps

2016-07-25 11:29:17 -0700
Ray Johnston <ray.johnston@artifex.com>
82e37a2d3309381ca55cde3a5515ab8aa61e3ebe

> Bug696876: Fix overprint blending when CompatibleOverprint mode not used.
> base/gxblend1.c

2016-07-29 18:19:33 +0100
Robin Watts <robin.watts@artifex.com>
cc393ffc7b748c8f053eaf4028e8cf130fabbbf7

> Revised gx_subpath_is_rectangular.
> This copes with more cases. For a given rectangle A, B, C, D, the
> original code coped with:
> Move A, Line B, Line C, Line D, close
> Move A, Line B, Line C, Line D, Move E, ...
> Move A, Line B, Line C, Line D, Line A
> Move A, Line B, Line C, Line D, Line A, Close
> Move A, Line B, Line C, Line D, Line A, Move E
> (and the flipped variants)
> We now cope with other cases including repeated corners:
> Move A, Line B, Line B, Line C, Line D, close
> etc
> and the case where the lines are curves that are really lines.
> base/gxpath.h
> base/gxpath2.c

2016-08-01 10:34:45 +0100
Ken Sharp <ken.sharp@artifex.com>
1e214a7382f35f52ae1efe2b53169704913e4df5

> pdfwrite - don't coerce Dests from strings to names unless required
> Bug #696974 "GS pdfwrite seems to break /GoToR's destination names /D"
> We were always altering GoTo and GoToR Destinations from strings into
> names, because string Dests are a PDF 1.2 feature. However its not
> always possible to represent a string (eg Unicode) as a name.
> In this commit we don't try to force the Dest into a name unless the
> PDF level is < 1.2 and if we do try to coerce it, we check to see if it
> can be represented. If not we throw an error and drop the Dest.
> devices/vector/gdevpdfm.c

2016-07-29 17:06:47 +0100
Robin Watts <robin.watts@artifex.com>
f885f6395594fc52c81075ebf7698ecd5bd09e6c

> Add some parentheses to clarify interpolation condition.
> base/gxiscale.c

2016-07-29 17:06:17 +0100
Robin Watts <robin.watts@artifex.com>
ca7d98064b32f4ad216732dc1523016a67878b26

> Include gximage.h for prototype of gx_image_compute_mat
> base/gsimage.c
> base/lib.mak

2016-07-29 15:48:43 +0100
Robin Watts <robin.watts@artifex.com>
7f8c86ebfc9efbb63df4898f15f93a705ff3ceaf

> Remove Visual Debugger
> base/gdevddrw.c
> base/gdevdsha.c
> base/gdevm24.c
> base/gdevmr8n.c
> base/gdevp14.c
> base/gsimage.c
> base/gxblend.h
> base/gxblend1.c
> base/gxclread.c
> base/gxdtfill.h
> base/gxfill.c
> base/gxfillsl.h
> base/gxfilltr.h
> base/gxfillts.h
> base/gxhintn.c
> base/gxhintn1.c
> base/gxi12bit.c
> base/gximono.c
> base/gxiscale.c
> base/gxpath.c
> base/gxpcopy.c
> base/gxpflat.c
> base/gxshade1.c
> base/gxshade4.c
> base/gxshade6.c
> base/gxstroke.c
> base/gzspotan.c
> base/lib.mak
> base/vdtrace.c
> base/vdtrace.h
> pcl/pl/plmain.c
> pcl/pl/plwmainc.c
> psi/dmmain.c
> psi/dwdll.c
> psi/dwdll.h
> psi/dwmain.c
> psi/dwmainc.c
> psi/dwnodll.c
> psi/dwtrace.c
> psi/dwtrace.h
> psi/gsdll32.def
> psi/gsdll32metro.def
> psi/gsdll64.def
> psi/gsdll64metro.def
> psi/gsdllARM32metro.def
> psi/iapi.c
> psi/iapi.h
> psi/imainarg.c

2016-07-29 14:52:46 +0100
Robin Watts <robin.watts@artifex.com>
d98f2adc027cd995b3c66e9dddd1d2fdad18e946

> Remove pseudo_rasterization.
> I'ts not used any more, and is just extra complexity that we don't
> need.
> base/gdevddrw.h
> base/gxfdrop.c
> base/gxfdrop.h
> base/gxfill.c
> base/gxfill.h
> base/gxfilltr.h
> base/gzspotan.c
> base/lib.mak

2016-07-29 13:26:39 +0100
Robin Watts <robin.watts@artifex.com>
4639fe50f8037a35b981ed239aa5cdf1a30a19ed

> Skip 0 length edges when filling.
> In theory, a zero length edge shouldn't make any difference
> to the appearance of a path. In practice, they appear as
> horizontal edges, and so can trip the code in gxfilltr.h that's
> labelled as:
> /*
> * This is a hack to make sure that isolated horizontal
> * lines get stroked.
> */
> That code is only called for !PSEUDO_RASTERIZATION.
> There is code in gxfill.c that ignores zero length edges, but
> this is currently conditional on pseudo_rasterization being
> turned on.
> As I understand it, PSEUDO_RASTERISATION is 1 when we are
> plotting chars, and should never be so anymore. The idea is that
> PSEUDO_RASTERISATION prevents dropouts in characters, hence it
> feels wrong that any code that has this on should plot LESS than
> code with it off.
> I suspect that Igor got the test the wrong way around here.
> I am just removing the test, and always ignoring 0 length edges.
> base/gxfill.c

2016-07-29 13:40:45 +0100
Ken Sharp <ken.sharp@artifex.com>
bd0df3ce9e72315f54d857f4de028da79412802f

> Fix FirstPage/LastPage for non-PDF input
> Robin spotted this one. When I added the page ranges code to augment
> the existing First/Last page functionality I moved the code which
> decided whether an operation was destined for a page which was being
> output into a single routine. Previously this was simple code which
> was replicated in each method, but the added complexity meant it was
> better handled centrally.
> However, when doing so I accidentally dropped the '-1' from the First
> and Last Page tests (PageCount starts from 0) which meant these were
> off by one throughout.
> Added these back in here.
> base/gdevflp.c

2016-07-26 20:31:06 -0700
Michael Vrhel <michael.vrhel@artifex.com>
8e901f44bdfcee1855378bdd6e26989fa294c8d5

> Fix DeviceGrayToK. Bug 696875
> By default we have -dDeviceGrayToK=true map all gray source
> colors directly to the K channel when the Device is CMYK based.
> This fix changes it so that Ghostscript matches Acrobat and
> Distiller and does this mapping only if the source color
> was truly defined as DeviceGray.
> The file in Bug 696875 has the property that it has a gray image
> whose color space is DefaultGray, which references an ICC color
> space. This color space was being treated as DeviceGray by
> Ghostscript but it really should be color managed and not
> treated as DeviceGray since it is ICC based.
> There are several progressions in the test suite assuming the
> reference is Acrobat. The differences are caused by the fact
> that gray sources that are not DeviceGray are now color
> managed.
> base/gsicc_cache.c

2016-07-27 12:11:13 +0100
Chris Liddell <chris.liddell@artifex.com>
200b1450b99ec4f1d3b7356b8497ff57da5460f3

> Remove leftover debugging code (pstack)
> Resource/Init/pdf_rbld.ps

2016-07-27 08:54:40 +0100
Ken Sharp <ken.sharp@artifex.com>
a2e50179a29ffa30f332bd19ab7b0ca50e4bc933

> PDF interpreter - fix some typos
> Ray noticed that the (future proofing) code to handle a 're' inside
> a text block had a typo. We haven't ever encountered such a thing, the
> code is there so that when we do encoutner one it will just work.
> No differences expected.
> Resource/Init/pdf_ops.ps

2016-07-26 18:28:52 +0100
Robin Watts <robin.watts@artifex.com>
337167e66a8edf08fc65826afdcf62cede445dc1

> Fix windows_debug_out.
> Simplified code that properly copes with strings longer than
> 4096.
> Thanks to Ray for spotting the problem(s) with the last one.
> psi/dwmainc.c

2016-07-25 17:57:56 +0100
Robin Watts <robin.watts@artifex.com>
016eeca9b2136d322d15f8add7bb207e61bfdb8c

> Fix Memento bug.
> When hunting for the block that contains a pointer, if we can't find
> one, return NULL, not the unchanged pointer!
> base/memento.c

2016-07-25 16:51:03 +0100
Robin Watts <robin.watts@artifex.com>
eb30a6927cf172c45bda4717a8bb8e21e7a5fe95

> Import latest Memento from MuPDF.
> Reintroduce the Memento_tick, and Mememto_event changes which haven't
> made it to MuPDF yet.
> base/memento.c
> base/memento.h

2016-07-25 17:57:15 +0100
Robin Watts <robin.watts@artifex.com>
2858aea017d933b2187d6eb5ac5718f0a45f3ca1

> Fix silly mistake in Windows OutputDebugString code.
> psi/dwmainc.c

2016-07-26 11:18:46 +0100
Ken Sharp <ken.sharp@artifex.com>
05bdaafd166a22797dc7f58e74d415081e00d469

> PDF interpreter - handle PageLabels where the number tree starts with Kids
> Bug #696947 "Regression: Error: /undefined in --run-- writing pdf file starting with 5784bfbfba7191cacce5309e88afac0851287460"
> This is not really a regression, exactly. Prior to the commit noted
> above we discarded PageLabels, the commit added the ability to preserve
> these.
> However, we had a limited number of available files to test from, and
> this particular file is the first one I have encountered where the
> number tree defining the page ranges begins with a number tree node
> which has /Kids but no /Nums (Table 3.34, p166 of the 1.7 specification
> says that the Root node may have /Kids only if there are no /Nums)
> I did code to cope with this but there was a minor flaw in the code,
> fixed here, which we lacked a test case for.
> Note that, although the specification says on p595 that the value of
> the PageLabels entry in the Catalog is a number tree, this file neatly
> exposes a probable bug in Acrobat. If the root of the number tree has
> no /Nums, but does have /Kids (which is valid for a number tree, see
> above) then Acrobat X does not display the PageLabels.
> This probably explains why we have never seen such a file before.
> For now I have chosen to permit the number tree to have /Kids, if in
> the future we need to revise this to behave like Acrobat we can do so.
> This does have the interesting side effect that if the file is sent to
> the pdfwrite device (and there is no other device which can use
> PageLabels) the resulting PDF file will have working labels, where the
> original does not.
> No differences expected
> Resource/Init/gs_pdfwr.ps

2016-07-22 15:44:43 -0600
Henry Stiles <henry.stiles@artifex.com>
6f1da3c990ab7de4c3218bf8beff21f19449b284

> Update PCL fonts and font table.
> Replace old URW fonts and update the font table with the new font
> names.
> pcl/pl/plftable.h
> pcl/urwfonts/A028-Ext.ttf
> pcl/urwfonts/A028-Med.ttf
> pcl/urwfonts/A030-Bol.ttf
> pcl/urwfonts/A030-BolIta.ttf
> pcl/urwfonts/A030-Ita.ttf
> pcl/urwfonts/A030-Reg.ttf
> pcl/urwfonts/Algiers-ExtraBold.ttf
> pcl/urwfonts/Algiers-Medium.ttf
> pcl/urwfonts/AntiqueOlive-Bol.ttf
> pcl/urwfonts/AntiqueOlive-Bold.ttf
> pcl/urwfonts/AntiqueOlive-Ita.ttf
> pcl/urwfonts/AntiqueOlive-Italic.ttf
> pcl/urwfonts/AntiqueOlive-Reg.ttf
> pcl/urwfonts/AntiqueOlive-Regular.ttf
> pcl/urwfonts/C011Condensed-Bold.ttf
> pcl/urwfonts/C059-BdIta.ttf
> pcl/urwfonts/C059-Bold.ttf
> pcl/urwfonts/C059-Italic.ttf
> pcl/urwfonts/C059-Roman.ttf
> pcl/urwfonts/C093-Regular.ttf
> pcl/urwfonts/CenturySchL-Bold.ttf
> pcl/urwfonts/CenturySchL-BoldItal.ttf
> pcl/urwfonts/CenturySchL-Ital.ttf
> pcl/urwfonts/CenturySchL-Roma.ttf
> pcl/urwfonts/ClarendonURW-BolCon.ttf
> pcl/urwfonts/Coronet.ttf
> pcl/urwfonts/D050000L.ttf
> pcl/urwfonts/Dingbats.ttf
> pcl/urwfonts/Garamond-Antiqua.ttf
> pcl/urwfonts/Garamond-Halbfett.ttf
> pcl/urwfonts/Garamond-Kursiv.ttf
> pcl/urwfonts/Garamond-KursivHalbfett.ttf
> pcl/urwfonts/GaramondNo8-Ita.ttf
> pcl/urwfonts/GaramondNo8-Med.ttf
> pcl/urwfonts/GaramondNo8-MedIta.ttf
> pcl/urwfonts/GaramondNo8-Reg.ttf
> pcl/urwfonts/LetterGothic-Bol.ttf
> pcl/urwfonts/LetterGothic-Bold.ttf
> pcl/urwfonts/LetterGothic-Ita.ttf
> pcl/urwfonts/LetterGothic-Italic.ttf
> pcl/urwfonts/LetterGothic-Reg.ttf
> pcl/urwfonts/LetterGothic-Regular.ttf
> pcl/urwfonts/Mauritius-Reg.ttf
> pcl/urwfonts/Mauritius-Regular.ttf
> pcl/urwfonts/NewDingbats.ttf
> pcl/urwfonts/NimbusMonL-Bold.ttf
> pcl/urwfonts/NimbusMonL-BoldObli.ttf
> pcl/urwfonts/NimbusMonL-Regu.ttf
> pcl/urwfonts/NimbusMonL-ReguObli.ttf
> pcl/urwfonts/NimbusMono-Bol.ttf
> pcl/urwfonts/NimbusMono-BolIta.ttf
> pcl/urwfonts/NimbusMono-Bold.ttf
> pcl/urwfonts/NimbusMono-BoldItalic.ttf
> pcl/urwfonts/NimbusMono-Ita.ttf
> pcl/urwfonts/NimbusMono-Italic.ttf
> pcl/urwfonts/NimbusMono-Reg.ttf
> pcl/urwfonts/NimbusMono-Regular.ttf
> pcl/urwfonts/NimbusMonoPS-Bold.ttf
> pcl/urwfonts/NimbusMonoPS-BoldItalic.ttf
> pcl/urwfonts/NimbusMonoPS-Italic.ttf
> pcl/urwfonts/NimbusMonoPS-Regular.ttf
> pcl/urwfonts/NimbusRomNo9L-Medi.ttf
> pcl/urwfonts/NimbusRomNo9L-MediItal.ttf
> pcl/urwfonts/NimbusRomNo9L-Regu.ttf
> pcl/urwfonts/NimbusRomNo9L-ReguItal.ttf
> pcl/urwfonts/NimbusRoman-Bold.ttf
> pcl/urwfonts/NimbusRoman-BoldItalic.ttf
> pcl/urwfonts/NimbusRoman-Italic.ttf
> pcl/urwfonts/NimbusRoman-Regular.ttf
> pcl/urwfonts/NimbusRomanNo4-Bol.ttf
> pcl/urwfonts/NimbusRomanNo4-BolIta.ttf
> pcl/urwfonts/NimbusRomanNo4-Bold.ttf
> pcl/urwfonts/NimbusRomanNo4-BoldItalic.ttf
> pcl/urwfonts/NimbusRomanNo4-Italic.ttf
> pcl/urwfonts/NimbusRomanNo4-Lig.ttf
> pcl/urwfonts/NimbusRomanNo4-LigIta.ttf
> pcl/urwfonts/NimbusRomanNo4-Regular.ttf
> pcl/urwfonts/NimbusRomanNo9-Bold.ttf
> pcl/urwfonts/NimbusRomanNo9-BoldItalic.ttf
> pcl/urwfonts/NimbusRomanNo9-Ita.ttf
> pcl/urwfonts/NimbusRomanNo9-Italic.ttf
> pcl/urwfonts/NimbusRomanNo9-Med.ttf
> pcl/urwfonts/NimbusRomanNo9-MedIta.ttf
> pcl/urwfonts/NimbusRomanNo9-Reg.ttf
> pcl/urwfonts/NimbusRomanNo9-Regular.ttf
> pcl/urwfonts/NimbusSanL-Bold.ttf
> pcl/urwfonts/NimbusSanL-BoldCond.ttf
> pcl/urwfonts/NimbusSanL-BoldCondItal.ttf
> pcl/urwfonts/NimbusSanL-BoldItal.ttf
> pcl/urwfonts/NimbusSanL-Regu.ttf
> pcl/urwfonts/NimbusSanL-ReguCond.ttf
> pcl/urwfonts/NimbusSanL-ReguCondItal.ttf
> pcl/urwfonts/NimbusSanL-ReguItal.ttf
> pcl/urwfonts/NimbusSans-Bold.ttf
> pcl/urwfonts/NimbusSans-BoldOblique.ttf
> pcl/urwfonts/NimbusSans-Oblique.ttf
> pcl/urwfonts/NimbusSans-Regular.ttf
> pcl/urwfonts/NimbusSansNarrow-BdOblique.ttf
> pcl/urwfonts/NimbusSansNarrow-Bold.ttf
> pcl/urwfonts/NimbusSansNarrow-Oblique.ttf
> pcl/urwfonts/NimbusSansNarrow-Regular.ttf
> pcl/urwfonts/NimbusSansNo2-Bold.ttf
> pcl/urwfonts/NimbusSansNo2-BoldItalic.ttf
> pcl/urwfonts/NimbusSansNo2-Italic.ttf
> pcl/urwfonts/NimbusSansNo2-Regular.ttf
> pcl/urwfonts/P052-Bold.ttf
> pcl/urwfonts/P052-BoldItalic.ttf
> pcl/urwfonts/P052-Italic.ttf
> pcl/urwfonts/P052-Roman.ttf
> pcl/urwfonts/StandardSymL.ttf
> pcl/urwfonts/StandardSymbolsPS.ttf
> pcl/urwfonts/Symbols.ttf
> pcl/urwfonts/U001-Bol.ttf
> pcl/urwfonts/U001-BolIta.ttf
> pcl/urwfonts/U001-Ita.ttf
> pcl/urwfonts/U001-Reg.ttf
> pcl/urwfonts/U001Con-Bol.ttf
> pcl/urwfonts/U001Con-BolIta.ttf
> pcl/urwfonts/U001Con-Ita.ttf
> pcl/urwfonts/U001Con-Reg.ttf
> pcl/urwfonts/URWBookman-Demi.ttf
> pcl/urwfonts/URWBookman-DemiItalic.ttf
> pcl/urwfonts/URWBookman-Light.ttf
> pcl/urwfonts/URWBookman-LightItalic.ttf
> pcl/urwfonts/URWBookmanL-DemiBold.ttf
> pcl/urwfonts/URWBookmanL-DemiBoldItal.ttf
> pcl/urwfonts/URWBookmanL-Ligh.ttf
> pcl/urwfonts/URWBookmanL-LighItal.ttf
> pcl/urwfonts/URWChanceryL-MediItal.ttf
> pcl/urwfonts/URWClassicSans-Bold.ttf
> pcl/urwfonts/URWClassicSans-BoldItalic.ttf
> pcl/urwfonts/URWClassicSans-Regular.ttf
> pcl/urwfonts/URWClassicSans-RegularIt.ttf
> pcl/urwfonts/URWClassicSansCond-BdItalic.ttf
> pcl/urwfonts/URWClassicSansCond-Bold.ttf
> pcl/urwfonts/URWClassicSansCond-Italic.ttf
> pcl/urwfonts/URWClassicSansCond-Regular.ttf
> pcl/urwfonts/URWClassico-Bol.ttf
> pcl/urwfonts/URWClassico-BolIta.ttf
> pcl/urwfonts/URWClassico-Bold.ttf
> pcl/urwfonts/URWClassico-BoldItalic.ttf
> pcl/urwfonts/URWClassico-Ita.ttf
> pcl/urwfonts/URWClassico-Italic.ttf
> pcl/urwfonts/URWClassico-Reg.ttf
> pcl/urwfonts/URWClassico-Regular.ttf
> pcl/urwfonts/URWDings.ttf
> pcl/urwfonts/URWGothic-Book.ttf
> pcl/urwfonts/URWGothic-BookOblique.ttf
> pcl/urwfonts/URWGothic-Demi.ttf
> pcl/urwfonts/URWGothic-DemiOblique.ttf
> pcl/urwfonts/URWGothicL-Book.ttf
> pcl/urwfonts/URWGothicL-BookObli.ttf
> pcl/urwfonts/URWGothicL-Demi.ttf
> pcl/urwfonts/URWGothicL-DemiObli.ttf
> pcl/urwfonts/URWPalladioL-Bold.ttf
> pcl/urwfonts/URWPalladioL-BoldItal.ttf
> pcl/urwfonts/URWPalladioL-Ital.ttf
> pcl/urwfonts/URWPalladioL-Roma.ttf
> pcl/urwfonts/Z003-MediumItalic.ttf

2016-07-25 11:16:37 +0100
Ken Sharp <ken.sharp@artifex.com>
8fedc1d7a098481e6607ffb6ef4612f18b68ed95

> High level devices - handle 12 BPC image data
> Bug #696944 "Lockup with pdfwrite device"
> This appears to be a bug of very long standing and points up our previous
> lack of image test files in the cluster runs, since it hasn't emerged
> before.
> The high level image stream code did not properly handle 12 bit data,
> In s_compr_chooser__unpack_and_recognize() we ended up with 8 bits of
> data remaining, which is not less than 8, but because the input size is
> 12 bits it is also not > the bits per sample. This led to an infinite
> loop trying to read data at the end of a line.
> Here we change the '<' to '<=' to properly detect the end of input, so
> we don't fall into this trap of assuming samples are 8 BPC.
> devices/vector/gdevpsds.c

2016-07-14 15:29:23 -0700
Michael Vrhel <michael.vrhel@artifex.com>
49ba79c5c27129cc0f47b150c49363b3ab3b1b63

> Add support for -sPostRenderProfile="icc profile" to tiffscaled devices
> With this commit, it is possible to have the tiffscaled32, tiffscaled24
> and tiffscaled8 devices apply an ICC profile after rendering, which
> will transform the rendered page to the color space defined by
> PostRenderProfile. When used in conjunction with -dUsePDFX3Profile,
> if the source file contains an Output Intent profile, the page will
> be rendered first to the color space defined by the output intent profile and then
> transformed to the color space defined by the PostRenderProfile setting. In this
> way, we can avoid issues caused by mismatching ICC profiles in overprint
> situations. This along with the commit http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=0df325b4bdbd037c92e2528fc16900de84f8d9c1
> are needed to create a patch.
> base/gxdownscale.c
> base/gxdownscale.h
> devices/devs.mak
> devices/gdevpng.c
> devices/gdevtfnx.c
> devices/gdevtifs.c
> devices/gdevtifs.h
> devices/gdevtsep.c

2016-07-22 12:01:29 +0100
Robin Watts <robin.watts@artifex.com>
d89f998d1008d693592f4c69ccf92085aa277060

> Send stdout/stderr to windows debug console too.
> When debugging in MSVC it's much easier to watch the output pane
> rather than the terminal window.
> psi/dwmainc.c

2016-07-21 16:26:29 +0100
Ken Sharp <ken.sharp@artifex.com>
6a3790308268f70e1be29eb8cca0c0e55711ef67

> PDF interpreter - treat invalid BaseEncoding as a missing BaseEncoding
> Bug #696942 "Missing content reading PDF file"
> The file contains Encoding dictionaries which contain BaseEncoding
> entries which are invalid, one is '/utf-8' the other is '/'. We already
> checked for '/' and ignored it, and we already checked named Encodings
> against the permissible list of Encodings, so here we just extend the
> checks for BaseEncoding to see if a named BaseEncoding is in the list
> pf permitted names.
> No differences expected.
> Resource/Init/pdf_font.ps

2016-07-21 13:01:12 +0100
Ken Sharp <ken.sharp@artifex.com>
e5326d42115f162d906415bdf3b5cbcba1cb477d

> Fix an inline function for storing 12-bit image data
> Bug #696940 " crash with 12-bit type 3 images"
> When I removed the 'load' and 'store' macros from the graphics library
> code, replacing with static inline functions commit
> d5008bf9092e99b5eb7f295c9d684850bf2aa66f I made an error. There was
> a 'break' missed in the 12 bit store function.
> We should probably add image-qa.ps to our test files for the cluster.
> base/gsbitops.h

2016-07-20 17:16:22 +0100
Chris Liddell <chris.liddell@artifex.com>
19931aea2fb8e6e72f58806836f0e769cd3139dd

> Fix position of 'const' modifier
> base/genconf.c

2016-07-19 23:58:16 +0300
Boris Nagaev <bnagaev@gmail.com>
3e5f8d3267e8abf3330da15fa6c159dd067bedc3

> Fix the --disable-contrib option for out-of-tree builds
> The grep to exclude contrib/contrib.mak was not lenient enough to handle
> srcdir!=dstdir.
> configure.ac

2016-07-20 12:50:55 +0100
Chris Liddell <chris.liddell@artifex.com>
7795d6d4a30d923bd3c11f4dd27b86617c15f1bd

> Bug 696937: readhexstring handle signed/unsigned char
> When readhexstring runs out of data, we overload an integer ref with the
> number of bytes from the input buffer used, and the value of a trailing
> odd numbered byte shifted to the top 8 bits of the integer value. If no
> trailing byte was read, the value is set to -1.
> When restarting readhexstring with a full buffer, we relied on casting to
> char to retrieve the signed value from the top 8 bits on the integer ref.
> Unfortunately, unqualified chars are not signed on all platforms, and on
> platforms where chars are unsigned, we ended up with an invalid value.
> So, have the casting use qualified (signed/unsigned) chars for writing and
> reading back the value.
> To make this neater, and consistent, add an "schar" type to match the existing
> "uchar" type.
> base/stdpre.h
> psi/zfileio.c

2016-07-20 12:50:22 +0100
Chris Liddell <chris.liddell@artifex.com>
49c7c0ec017baa0fe1708e185586859d9188dd2a

> Remove some debugging code.
> Resource/Init/gs_ttf.ps

2016-07-20 11:38:09 +0100
Robin Watts <robin.watts@artifex.com>
97a2fc7002bbaecdaa9673fc59e0929d8f61e36b

> Silence warning.
> base/gsfunc0.c

2016-07-19 15:20:53 +0100
Robin Watts <robin.watts@artifex.com>
d512fd15d80625557c5a3c494d7a86b89ffa5bd3

> Fix debug builds.
> Code I modified yesterday broke the debug printfs.
> psi/isave.c

2016-07-18 18:56:50 +0100
Robin Watts <robin.watts@artifex.com>
e21bbf5f9ca6d0a75a18342cb951608ad072cddf

> Bug 696837: Improve performance of memory searches.
> The swap to use splay trees reduces the performance of this
> file from 11 seconds to 25 seconds for me.
> This is due to the additional complexity of traversing a
> more complex memory structure. The hope is that in the average
> case we'll do better (or at least no worse), and that we'll
> make gains in more pathological cases.
> It turns out that in alloc_is_since_save I was failing to
> actually make use of the fact that the new structure is
> sorted and can hence be searched much more efficiently.
> Do that here. This gets performance back to 17 seconds - so
> still a net loss, but less so.
> base/gsalloc.c
> base/gxalloc.h
> psi/isave.c

2016-07-18 18:53:22 +0100
Robin Watts <robin.watts@artifex.com>
702bc7f6b3f0634daae556a4a2c27fae44d80300

> Fix stray result of global replace.
> base/gsalloc.c

2016-07-15 18:39:56 +0100
Robin Watts <robin.watts@artifex.com>
0df325b4bdbd037c92e2528fc16900de84f8d9c1

> Add color management hooks for downscaler.
> base/gxdownscale.c
> base/gxdownscale.h

2016-07-18 10:03:24 -0600
Henry Stiles <henry.stiles@artifex.com>
2e7642ca7abdddc7fba5ab2a6450f1fc7dad62eb

> Fix 696933 interpreter exit.
> The PXL output device did not take into account transparency when
> checking if the destination was needed.
> devices/devs.mak
> devices/vector/gdevpx.c

2016-07-18 13:03:35 +0100
Ken Sharp <ken.sharp@artifex.com>
00c81b3dd0dfd918168a56741c56920331890319

> txtwrite - fix a conversion from bytes to shorts
> Bug 696935 "SEGV in txtwrite"
> When I modified the ToUnicode processing to return more than a single
> code point for a given glyph, I altered the code to return a required
> buffer size (or count of bytes copied). Txtwrite wanted a count of code
> pints (always 2 bytes for ToUnicode) and so I should have divided the
> return value by the size of a short. For some reason I multiplied it
> instead, I have no idea what I was thinking of.....
> I couldn't reproduce a SEGV but since this was a buffer overrun problem
> it would depend on the memory layout. With this fix the text is once
> again sensible, and Robin reports the SEGV has gone away.
> devices/vector/gdevtxtw.c

2016-07-15 09:00:05 -0700
Ray Johnston <ray.johnston@artifex.com>
03ef4a5345cf996270679bc3c3e9103991bd8d24

> Fix previous commit that was missing most of the changes.
> base/gxacpath.c
> base/gxclip.c

2016-07-12 14:55:28 -0700
Ray Johnston <ray.johnston@artifex.com>
9c2d7369994b7b3c4b7204c7e6fe11b34e243037

> Fix problems with commit fd34a32 (bug 696841) which transposed clip
> Even though the transposition of clip paths commit fd34a32 didn't
> turn up any differences, it had problems, some spotted by desk check
> and some as a result of testing the customer file and debug.
> First, the accum_fill_rectangle needs to transpose coordinates. Then
> the clip device must transpose coordinates when comparing to rectangles
> in the list. The clip_enumerate function and the procedures that open
> code checks against rdev->current transpose the coordinates. If they
> need to call clip_enumerate_rest it is with transposed values. The
> coordinates in the ccdata structure are non-transposed.
> It was surprising when the previous commit didn't show any problems
> (my trust in the regression test took a hit).
> base/gxclip.c

2016-07-14 18:54:36 +0100
Robin Watts <robin.watts@artifex.com>
762afc5e23d658345ac0484e9eeb0186d340803c

> MSVC: Tweak makefile so .pdb files go in the obj directory
> This avoids them going at the top, and hence makes cleaning etc
> easier.
> base/msvccmd.mak

2016-07-14 11:31:31 +0100
Ken Sharp <ken.sharp@artifex.com>
fd1b84560536076f655421e98a27e58d2881ca70

> XPS interpreter - fix 'synthetic bold' text style
> Bug 696914 "Large black objects in output with pdfwrite device"
> The problem here is that the XPS interpreter, when creating a synthetic
> bold font, merely set the text rendering mode to 2 (fill and stroke),
> assuming that the graphics library would deal with this.
> However, the graphics library does not care about text rendering modes
> at all. The graphics state parameter is used only by the high level
> devices and (apart from this instance) only be the PDF interpreter. When
> the PDF interpreter encounters a text rendering mode other than 0 it
> checks the device to see whether it wants text rendering modes preserved.
> If it does, then the interpreter simply sets the mode and does nothing
> else. If, however, the device does not want the mode preserved, then the
> PDF interpreter breaks the text rendering mode into its component
> operations.
> This commit adds the same functionality to the XPS interpreter. It seems
> that the XPS interpreter only uses this for synthetic bold, and so only
> uses Tr 2. So the code now checks with the device to see if it wants
> the mode preserved, if it does, we simply leave it (but see below).
> Otherwise, we stroke the text, and then draw it normally (fill). This
> means that the artificial bold text is now actually drawn bold.
> There is one slight complication. When stroking a path the pdfwrite device
> takes care to undo the scaling done by the CTM from the stroke width.
> But when using a text render mode, it does not do so, it uses the
> line width 'as is'. The XPS interpreter sets the line width including
> the CTM (which is correct for stroking), so we need to 'undo' the CTM
> applied to the line width before we draw the text, when we are preserving
> the text rendering mode.
> xps/ghostxps.h
> xps/xpsglyphs.c

2016-07-13 08:13:09 -0600
Henry Stiles <henry.stiles@artifex.com>
1d3ee57f5a57bb68d0693ca11fafdedd1f2249f5

> Images of 0 area caused division by 0.
> We now let the default begin image procedure handle this case.
> devices/vector/gdevpx.c

2016-04-08 14:46:06 +0100
Chris Liddell <chris.liddell@artifex.com>
c8342b4a7b6cdcc4cb1261bf2b008f6df257b5c6

> URW++ update to base 35 from June 2016.
> This extends the Greek and Cyrillic glyphs originally supplied in only three
> font families to cover all the relevant fonts in the base 35.
> These remain covered by the GPL with the embedding exemption.
> Resource/Font/C059-BdIta
> Resource/Font/C059-Bold
> Resource/Font/C059-Italic
> Resource/Font/C059-Roman
> Resource/Font/CenturySchL-Bold
> Resource/Font/CenturySchL-BoldItal
> Resource/Font/CenturySchL-Ital
> Resource/Font/CenturySchL-Roma
> Resource/Font/D050000L
> Resource/Font/Dingbats
> Resource/Font/NimbusMono-Bold
> Resource/Font/NimbusMono-BoldOblique
> Resource/Font/NimbusMono-Oblique
> Resource/Font/NimbusMono-Regular
> Resource/Font/NimbusMonoPS-Bold
> Resource/Font/NimbusMonoPS-BoldItalic
> Resource/Font/NimbusMonoPS-Italic
> Resource/Font/NimbusMonoPS-Regular
> Resource/Font/NimbusRomNo9L-Med
> Resource/Font/NimbusRomNo9L-MedIta
> Resource/Font/NimbusRomNo9L-Reg
> Resource/Font/NimbusRomNo9L-RegIta
> Resource/Font/NimbusRoman-Bold
> Resource/Font/NimbusRoman-BoldItalic
> Resource/Font/NimbusRoman-Italic
> Resource/Font/NimbusRoman-Regular
> Resource/Font/NimbusSanL-Bol
> Resource/Font/NimbusSanL-BolIta
> Resource/Font/NimbusSanL-BoldCond
> Resource/Font/NimbusSanL-BoldCondItal
> Resource/Font/NimbusSanL-Reg
> Resource/Font/NimbusSanL-RegIta
> Resource/Font/NimbusSanL-ReguCond
> Resource/Font/NimbusSanL-ReguCondItal
> Resource/Font/NimbusSans-Bold
> Resource/Font/NimbusSans-BoldOblique
> Resource/Font/NimbusSans-Oblique
> Resource/Font/NimbusSans-Regular
> Resource/Font/NimbusSansNarrow-BdOblique
> Resource/Font/NimbusSansNarrow-Bold
> Resource/Font/NimbusSansNarrow-Oblique
> Resource/Font/NimbusSansNarrow-Regular
> Resource/Font/P052-Bold
> Resource/Font/P052-BoldItalic
> Resource/Font/P052-Italic
> Resource/Font/P052-Roman
> Resource/Font/StandardSymL
> Resource/Font/StandardSymbolsPS
> Resource/Font/URWBookman-Demi
> Resource/Font/URWBookman-DemiItalic
> Resource/Font/URWBookman-Light
> Resource/Font/URWBookman-LightItalic
> Resource/Font/URWBookmanL-DemiBold
> Resource/Font/URWBookmanL-DemiBoldItal
> Resource/Font/URWBookmanL-Ligh
> Resource/Font/URWBookmanL-LighItal
> Resource/Font/URWChanceryL-MediItal
> Resource/Font/URWGothic-Book
> Resource/Font/URWGothic-BookOblique
> Resource/Font/URWGothic-Demi
> Resource/Font/URWGothic-DemiOblique
> Resource/Font/URWGothicL-Book
> Resource/Font/URWGothicL-BookObli
> Resource/Font/URWGothicL-Demi
> Resource/Font/URWGothicL-DemiObli
> Resource/Font/URWPalladioL-Bold
> Resource/Font/URWPalladioL-BoldItal
> Resource/Font/URWPalladioL-Ital
> Resource/Font/URWPalladioL-Roma
> Resource/Font/Z003-MediumItalic
> Resource/Init/Fontmap.GS
> psi/psromfs.mak

2016-07-12 10:30:58 +0100
Ken Sharp <ken.sharp@artifex.com>
a086f21714dbcb710d698bb2b47ac7a9e3ce89db

> pdfwrite - fix PDF/X-3 Box emission when boes supplied via pdfmark
> Bug #696919 " Wrong TrimBox and Metadata not allowed in PDF/X-3 conversion"
> The code to calculate, check and emit the various Boxes when creating
> PDF/X output relied upon the mediabox array contents being set. However
> this array was initialised to 0, and not set correctly. I suspect this
> has been altered at some time in the past, since we now use a temporary
> array of floats (instead of doubles) to store and emit the MediaBox.
> The upshot of this is that we were writing just the differences from
> the MediaBox instead of the full Box values.
> No differences expected, the cluster doesn't test PDF/X-3 creation
> devices/vector/gdevpdf.c

2016-07-12 10:25:06 +0100
Ken Sharp <ken.sharp@artifex.com>
9f2e9ea89e35b4857ca06056ef978005bfae48bc

> Allow SubFileDecode filter to exceed 2GB
> Bug #696916 "32-bit byte counter in /SubFileDecode"
> Adopt the patch supplied by Alex Cherepanov, this allows a SubFileDeocde
> filter to skip more than 2GB of data. I haven't tested Alex's file,
> I'll assume it works for him.
> No differences in cluster testing.
> base/sfilter.h

2016-07-12 00:25:21 +0100
Robin Watts <robin.watts@artifex.com>
08fb4a4997cf85a0f903f55f099e266d9ab70290

> Fix landscape imagemask plotting.
> In commit 0fb16eb7 I implemented interpolation of imagemasks
> for the non hl-color case. Unfortunately it appears I implemented
> it badly.
> Thanks to Ray for spotting this and supplying the fix.
> base/gxiscale.c

2016-07-11 16:54:55 +0100
Ken Sharp <ken.sharp@artifex.com>
344a80aab2e4ca48f4332c49f74560d56e739ad8

> PDF interpreter - cope with Default* ColorSpace definitions in Forms
> Bug #696875 " Differences in output - altona swatch p"
> Our existing code for dealing with DefaultGray, DefaultRGB and DefaultCMYK
> ColorSpace definitions is not great. It relies upon defining these as
> ColorSpace resources, and setting UseCIEColor to true. When we then
> set DevicGray, DeviceRGB or DeviceCMYK the PostScript code detects the
> use of CIEColor and loads the corresponding 'Default' colour space
> instead of loading the device space (NB the initial definitions are
> identity, ie initally DefaultGray = DeviceGray)
> This was only done for Pages, not for Forms, and we now have examples
> (test suite files) which use different Default* spaces in Forms.
> This code extends the detection of Default* spaces to Form XObjects
> and turns on UseCIEColor if it finds any. DoForm now detects any such
> spaces and defines appropriate ColorSpace resources. I would like to
> put save/restore around the form to preserve any existing definitions,
> but that causes the transparency code to seg fault. Instead we carefully
> copy any existing definitions, and replace them after running the form.
> This show progressions in 2 files:
> Altona_Technical_v20_x4.pdf
> CATX9509.pdf
> The file Bug695948.pdf now times out. This is because of the crazy way
> the file is constructed, it has forms nested 50 levels deep, only the
> last one making any actual marks. Each form declares every preceding
> form as a resource (which it need not do, only the form it actually
> uses need be declared). This causes the code attempting to detect the
> use of Default* colour spaces to take an extraordinarily long time. I've
> decided to accept this as the price for getting the Altona file to work.
> In the long term we should rework the use of Default* colour spaces so
> that the ICC manager is involved. This should ideally mean storing the
> Default* spaces in the graphics state I think.
> Resource/Init/pdf_draw.ps
> Resource/Init/pdf_main.ps

2016-07-08 10:23:11 -0700
Michael Vrhel <michael.vrhel@artifex.com>
0d619ee9816662b4264f6d9ca3be0045a42a7d61

> CompatibleOverprint blend mode addition (c-code)
> This adds support in the transparency code for providing proper
> application of blending when we have overprint and transparency.
> The description is in Section 7.6.3 of the spec. This is for
> fixing Bug 696876. This does not complete the problem yet. We
> have to add code in the interpreter side to invoke this blending mode
> when overprint is enabled and we are painting elementary graphics objects
> (fills, strokes, text, images, and shadings) (That is from the spec).
> If the blend mode is anything BUT Normal, the interpreter should
> push a non-isolated non-knockout group prior to painting the object. The
> blend mode should be set to BLEND_MODE_CompatibleOverprint. When
> we pop the group, the blend mode should be restored to the non-Normal
> blend mode for the group composition.
> base/gdevp14.c
> base/gstparam.h
> base/gxblend.c
> base/gxblend.h
> base/gxblend1.c
> base/gxp1fill.c
> base/gxpcolor.h
> base/lib.mak

2016-07-07 11:07:45 -0700
Ray Johnston <ray.johnston@artifex.com>
60195a79aff2a53662a471a59c2900c8435730f6

> Improve performance for interpolated landscape images (bug 696841)
> There was a comment that indicated that doing landscape runs was not
> worthwhile, but on the customer's test file it improved peformance by
> 40%.
> base/gxiscale.c

2016-07-05 08:57:24 -0700
Ray Johnston <ray.johnston@artifex.com>
fd34a32b0fd8f6d38f26c464b3a4efa6fdc37a56

> Improve performance of landscape masks for bug 696841.
> Since the clip list accumulator is optimized for x-major entry of rects,
> if we know the information is y-major, as for landscape imagemasks, then
> transpose X and Y in the list, and similarly transpose back when doing
> the clip_enumeration bounds checking and calling the target operation
> (process function).
> This improves the processing of the customer's file from 1900 seconds to
> 96 seconds!
> So far only landscape imagemask clip path accumulation uses this. TBD
> is to evaluate if any other uses of the clip path accum device can take
> advantage of this transposition.
> base/gsimage.c
> base/gxacpath.c
> base/gxclip.c
> base/gxclrast.c
> base/gxcpath.c
> base/gxcpath.h
> base/gximage.h
> base/gximask.c
> base/gximask.h
> base/gxipixel.c
> base/gzacpath.h

2016-07-06 13:59:10 -0700
Michael Vrhel <michael.vrhel@artifex.com>
ab8f19f34d7c2b1ea7d1a853bc9fa74f58bf49e2

> Extend the -sSourceObjectICC to include gray ICC profiles
> This makes it possible to specify overriding gray ICC profiles
> for gray color spaces as specified in the file referenced by
> -sSourceObjectICC. The notation is similar to that described
> for the RGB and CMYK color spaces in the color document.
> Fixes Bug 696834.
> base/gscms.h
> base/gsicc_cache.c
> base/gsicc_manage.c
> base/gsicc_manage.h

2016-07-06 10:52:49 -0700
Michael Vrhel <michael.vrhel@artifex.com>
8387d9f2cb6f77dca2b12d87f865a28dd52a9840

> Add support to create threshold profiles for input color spaces
> This adds the ability to the ICC Creator tool in toolbin/color
> to create ICC profiles that will threshold to neutral CIELAB
> values of black or white. You can specify the L* point at
> which to apply the transition. The input curve treats the device values as
> having the traditional sRGB like gamma. This is work toward dealing
> with the enhancement in Bug 696834
> toolbin/color/icc_creator/ICC_Creator/ICC_Creator.rc
> toolbin/color/icc_creator/ICC_Creator/ICC_CreatorDlg.cpp
> toolbin/color/icc_creator/ICC_Creator/ICC_CreatorDlg.h
> toolbin/color/icc_creator/ICC_Creator/icc_create.cpp
> toolbin/color/icc_creator/ICC_Creator/icc_create.h
> toolbin/color/icc_creator/ICC_Creator/resource.h

2016-07-05 10:17:48 -0700
Ray Johnston <ray.johnston@artifex.com>
e9b54d14d939bd038bfddc745ea765cb970c9edb

> Fix force_interpolation to work properly with interpolation threshold
> If the scaling was less than the threshold, interpolation would be skipped
> even if it had been forced by logic in gxipixel.c. Also skip interpolation
> if it doesn't do anything (Width and Height In == Out).
> base/gxidata.c
> base/gximage.h
> base/gxipixel.c
> base/gxiscale.c

2016-07-05 09:31:00 -0700
Ray Johnston <ray.johnston@artifex.com>
cdbf67714cddad97b2cad46adc56c648764be733

> Use fixed_epsilon to detect downscale for force_interpolation of patterns
> PCL uses patterns (a lot) but due to rounding patterns intended to be 1:1
> scale end up as slightly less (grasshop.pcl) so interpolation would be
> forced.
> base/gxipixel.c

2016-07-04 14:25:49 +0100
Ken Sharp <ken.sharp@artifex.com>
f342b3bdf81308ff3ce90381ec741a1b0f25ed0c

> pdfwrite - fix an off-by-1 error copying extension metadata
> We were copying one byte too few from the supplied string. Take the
> opportunity to optimise the size of the allocated data at the same
> time. Its only 1 byte, but still.....
> devices/vector/gdevpdfm.c

2016-07-04 10:26:07 +0100
Ken Sharp <ken.sharp@artifex.com>
810ce1e302af7d12e08650ccf0d88407b04a0d46

> PDF interpreter - cope with missing parameters in Destinations
> The PDF specification says that certain elements in Destinations can
> be 'null' but doesn't say that this actually means 'missing'.
> Commit b4fc7327fa0c792a7b218610b86d9fa4533d3e0b added support for this
> in XYZ Dests, this commit adds support for FitH, FitV, FitBH and FitBV
> Dests completing the variations. Note that the spec says that 'null'
> values for FitR have 'undefined results' so we just throw those away
> still.
> No differences expected.
> Resource/Init/pdf_main.ps

2016-07-04 08:13:00 +0100
Ken Sharp <ken.sharp@artifex.com>
389657cf69b2a9c612442c8222236e3ce6f869ca

> PDF interpreter - handle ToUnicode CMaps with large ranges
> The CMap reading code did not cope with range entries which spanned
> more than 255 indices in a single range, it assumed there would never
> be more than this and only used a single byte for the key values.
> Fixing that revealed that the ToUnicode generation (from the decoded
> CMap) also assumed that a range would never span more than 255 indices.
> This was a little more complex to fix.
> This commit should allow arbitrary length ranges, even though the
> ToUnicode specification currently limits the keys to 0-65536. This is
> not tested by cluster runs, but appears to work with all the problematic
> ToUnicode files I can find on a quick sweep through Git.
> Resource/Init/gs_cmap.ps
> Resource/Init/pdf_font.ps

2016-06-30 16:31:09 +0100
Ken Sharp <ken.sharp@artifex.com>
bbb684bc346851cb08d615048c9f50c106ec1fe4

> add per-page annotation detection to pdf_info.ps
> toolbin/pdf_info.ps

2016-06-24 09:14:43 -0700
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
7dca388d4b952357c931f52b4bb16dee76cea01e

> Minor changes to clusterpush.pl and improvements in its documentation.
> toolbin/localcluster/clusterpush.pl
> toolbin/localcluster/clusterpush.txt

2016-06-24 10:28:39 +0100
Ken Sharp <ken.sharp@artifex.com>
fd75e1678500f1ba60296ddf8fbb17e60aedcd6d

> Match Acrobat's use of AutoRotatePages and DSC
> When AutoRotatePages is set to anything except /None Acrobat will
> honour DSC Orientation comments and use them in preference to the
> heuristically determined value, which we weren't doing.
> This commit matches Acrobat, including the ability to have the heuristic
> override the DSC comments by setting -dParseDSCComments=false.
> The documentation is updated and now correct, including mentioning that
> the heuristic can be preferred by turning off DSC parsing.
> A few files (7) show a difference because of different orientation
> with the pdfwrite device.
> devices/vector/gdevpdf.c
> doc/VectorDevices.htm

2016-06-23 09:09:08 +0100
Ken Sharp <ken.sharp@artifex.com>
75e76c19392457f442d10770f6096a558fe6befc

> remove memcmp() of structures from zfont1.c
> Bug 696863 "memcmp() in zfont1.c"
> psi/zfont1.c

2016-06-22 16:36:20 -0700
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
5ce6369cb89453e75f1915e6f520a19c49a4096b

> Flip cups files right side up in bmpcmp.c.
> toolbin/bmpcmp.c

2016-06-22 18:15:55 +0100
Brian Norris <computersforpeace@gmail.com>
d54d8d529fdc9515068384c6262f321bec06bf5f

> Bug 696843: poor dependencies for install target
> The dependencies for the install target were poorly specified causing them
> to sometimes fail when called in a parallel make.
> contrib/contrib.mak

2016-06-22 18:12:34 +0100
Brian Norris <computersforpeace@gmail.com>
832c32645075dcd93e8e448ec012241f79edac17

> Fix use of shell built-in 'trap'
> In instcopy we use the shell built-in 'trap' so that if anything goes wrong
> in the copying process, we ensure cleanup afterwards. But we only setup the
> trap *after* we'd started copying stuff.
> It was *probably* okay, but is safer and cleaner this way.
> Noticed in passing looking at Bug 696843.
> base/instcopy

2016-06-22 10:00:22 +0100
Chris Liddell <chris.liddell@artifex.com>
d278f6a3b8b7baecbe23d7fa40de1164fd67e63e

> More TTF post table wranglings
> The original TTF spec listed name table indices between 32768 and 65536 as
> "reserved for future use". The latest OTF spec (1.60) has indices up to and
> including 63335 as valid.
> So, tweak our post table handling to cope.
> Since numGlyphs is a unsigned short (16 bit) number, there is no point checking
> for the upper limit of value, now, so that check is dropped.
> Also, since we pre-process the requested indices to ascertain the largest index
> we have to deal with, and if the number of names is less than that, fill the
> remainder of the array with /.notdef names, we can also drop the explicit check
> for indices beyond the available names.
> Resource/Init/gs_ttf.ps

2016-06-21 14:39:27 +0100
Ken Sharp <ken.sharp@artifex.com>
b4fc7327fa0c792a7b218610b86d9fa4533d3e0b

> pdfwrite - cope with missing optional arguments in /XYZ Dests
> Bug 696838 "Preserve /Dests when not named"
> Well it seems that 3 of the arguments for an XYZ Destination are
> optional and may be omitted, using the current setting instead. The
> link destination code wasn't catering for that.
> This commit checks the number of arguments in the array, throws errors
> when there are too many or not enough, and replaces missing optional
> values with 'null' which is equivalent and doesn't break the code.
> Resource/Init/pdf_main.ps

2016-06-20 16:29:21 +0100
Chris Liddell <chris.liddell@artifex.com>
f3ed5db0fff13a4f2262e1d203ac6444df196c5d

> Bug 696824 (redux): post table handling
> It turns out that it is valid for the number of entries in the post table's name
> list to be larger than the number of glyph indices used in the font (for what
> purpose, I cannot fathom).
> Worse, the number of entries in the name list is not declared anywhere, so the
> only option is to pre-process to recover it. In fact, we pro-process the list
> of indices (rather than the list of names) and note the highest reference -
> this is more efficient as the indices are short, and fixed length values, where
> names tend to longer, and of variable length.
> Resource/Init/gs_ttf.ps

2016-06-19 10:59:25 -0700
Ray Johnston <ray.johnston@artifex.com>
6aff224d35988db9a388eee4ddd849eee18bd9d6

> Fix clist_dev_spec_op forwarding when the device is pattern-clist
> Detected while investigating bug 696841, but it doesn't help with the
> performance issue. It would cause gridfitting and forced interpolation
> to be different for patterns accumulated to a bitmap compared to those
> that used the pattern-clist.
> base/gxclrect.c
> base/gxpcmap.c
> base/gxpcolor.h

2016-06-18 10:21:48 +0100
Ken Sharp <ken.sharp@artifex.com>
9744319ca8e8f55fa2b8e146557e2b146deb6f1b

> Coverity ID 94756 - add a 'fall through' comment
> base/gxshade4.c

2016-06-18 09:30:49 +0100
Ken Sharp <ken.sharp@artifex.com>
9484cc1d16b50f506bcea80030cffc442e46d717

> pdfwrite - test a return code to silence a scan-build warning.
> devices/vector/gdevpdfm.c

2016-06-17 18:12:09 +0100
Ken Sharp <ken.sharp@artifex.com>
e64d0620193b05d57f37d2deceac965ec5114e67

> pdfwrite - don't compress data from Metadata pdfmark when output is PDF/A
> Bug 696864 "Metadata stream should not be compressed, when using a pdfmark"
> This turned out to be rather more complex than expected. The stream is
> constructed via a pdfmark before we add the 'Metadata' key to its
> dictionary. This means that at the time we create the stream, we don't
> know that it should not be compressed, so we open it with compression
> filters added.
> We can't throw away the stream we have at the time data is written to
> it, because we've written keys to its associated dictionary. Also that
> would generate a new object number leaving an unused object in the xref
> which is legal but undesirable.
> This means that we either have to defer the compression filters
> until we write to the file, or close the compression filters when we see
> the Metadata. Ideally I'd like to do the former, but I wasn't able to
> prove categorically that there was no other code path leading to a
> pdfmark-created stream which would evade the checks.
> So I've chosen to discard the existing compressed stream when we find
> a /Metadata pdfmark, and create a new uncompressed stream for the
> stream object. This means also deleting the Filter and DecodeParams
> entries from the dictionary, if present.
> Finally, there has for some time been an icky hack in the code where we
> overload the meaning of 'CompressFonts' to determine whether to compress
> all streams outside of page streams (which are controlled with
> CompressPages). This commit also adds the new debugging switch
> CompressStreams which, if set to false (default is true) will not
> compress streams other than Fonts or Pages, which still retain their
> existing controls.
> devices/vector/gdevpdfb.h
> devices/vector/gdevpdfi.c
> devices/vector/gdevpdfm.c
> devices/vector/gdevpdfp.c
> devices/vector/gdevpdfx.h
> doc/VectorDevices.htm

2016-06-14 18:26:18 +0100
Robin Watts <robin.watts@artifex.com>
3c889ceed3b9a78da16ea2387f3b8029e25aa15b

> Memento: Add Memento_tick()
> Sometimes it can be useful to be able to run a program
> repeatedly and stop it at a given place, just before a
> problem occurs.
> Suppose you know that the problem occurs in the 'foo'
> function, but only after a number of runs.
> Insert a call to Memento_tick() at the top of foo, rebuild
> and run in the debugger. When the problem occurs, consult
> memento.sequence to see what event number we are on;
> suppose it's 1000.
> Then you can rerun the debugger with breakpoints on Memento_inited
> and Memento_breakpoint. When the program stops at Memento_inited,
> call Memento_breakAt(1000) and continue execution. The program
> will then stop in Memento_breakpoint within the Memento_tick
> call just before the problem occurs, enabling you to step forward
> and see what goes wrong.
> base/memento.c
> base/memento.h

2016-05-02 19:31:27 +0100
Robin Watts <robin.watts@artifex.com>
3bc51652cc962f0256acdf37f52d0a7d98b20ed1

> Bobbin: Add first version of Bobbin.
> A simple tool to help debug performance problems with
> threads.
> Build with BOBBIN defined, and all pthreads calls (or at
> least all the ones gs uses) go through Bobbin. This keeps
> track of the time each threads spends waiting on mutexes
> or condition variables.
> Hopefully this allows contention to be spotted.
> A report is printed at the end.
> base/bobbin.c
> base/bobbin.h
> base/gdevprn.c
> base/gp_psync.c
> base/gpsync.h
> base/gsicc_cache.c
> base/gsicc_lcms2.c
> base/gsicc_manage.c
> base/gsmalloc.c
> base/gxclthrd.c
> base/gxsync.c
> base/gxsync.h
> base/lib.mak
> base/malloc_.h
> base/memento.h
> windows/ghostscript.vcproj

2016-06-14 15:33:46 +0100
Chris Liddell <chris.liddell@artifex.com>
b3cea386ef8ebc24198963a26c90ad33dc1f8f07

> Bug 696833: Use sane way to identify fill/stroke in a glyph
> There was a highly unreliable hack used in the do_fill() and do_stroke()
> functions in order to the set the object type tag between line art and
> text.
> This uses a more robust solution
> base/gspaint.c

2016-06-14 08:33:57 +0100
Chris Liddell <chris.liddell@artifex.com>
f3b34d04f6c7b58375582a6b46abb024a0bb0ab0

> Clarify description comment in gdevmiff.c
> devices/gdevmiff.c

2016-06-14 16:29:12 +0100
Ken Sharp <ken.sharp@artifex.com>
53d35a364f99dc2353104cfec0c684a062034456

> pdfwrite - move linearisation records to non-GC memory
> Bug 696832 "crashes on Windows server 2012 R2"
> This seems to be because the pointer enumeration was messed up and
> we didn't enumerate the 'PageList' at all, causing some spectacular
> faults in Garbage collection, because linearization only occurs when
> closing the device, which means we always do GC beforehand and move
> all the pointers.
> The simples solution is just to move the records to non-GC memory, there
> is no reason for these to be tracked by the garbage collector.
> devices/vector/gdevpdf.c
> devices/vector/gdevpdfx.h

2016-06-14 10:01:08 +0100
Ken Sharp <ken.sharp@artifex.com>
d6c70b021c6dd2ee20dfdbd82b4bbfc213b1c64a

> pdfwrite - fix octal escapes in Ext_Matadata pdfmark processing
> Bug #696830 "Ext_Metadata pdfmark — does it work with general UTF-8 text string?"
> The code for undoing octal escapes in the Ext_Metadata pdfmark
> processing code did not subtract 0x30 (ASCII '0') from bytes before
> converting them to binary, resulting in incorrect data.
> Thanks to Ross Moore for finding the problem and tracking down the fix.
> devices/vector/gdevpdfm.c

2016-06-13 12:38:59 +0100
Ken Sharp <ken.sharp@artifex.com>
aeabbe1b9bfbcc3a2214c030aa5c77910112e021

> ps2write - permit image downsampling
> For inline images we set up 'lossless' filters, which use lossless
> compression, but also disable downsampling.
> This seems wrong for pdfwrite, and because ps2write always uses inline
> images, means that downsampling wasn't working at all for ps2write.
> This commit alters the lossless filters to allow for image downsampling
> even when inline. At the same time we change the ps2write defaults to
> not downsample color images, so that we don't see a change in behaviour.
> Resource/Init/gs_pdfwr.ps
> devices/vector/gdevpdfi.c
> devices/vector/gdevpsdf.h
> devices/vector/gdevpsdi.c

2016-06-11 16:47:52 +0100
Robin Watts <robin.watts@artifex.com>
2fc20e2ff73b0d015f7aab9f5bc2df0e11361536

> Update LZW decode to cope with TIFF 5.0 streams.
> The LZW decoder used in TIFF 5.0 streams is not as strict as
> normal LZW. When we hit the maximum number of codes we do not
> expect a CLEAR code immediately.
> base/slzwd.c
> base/slzwx.h
> xps/xpstiff.c

2016-06-13 08:46:41 +0100
Ken Sharp <ken.sharp@artifex.com>
aa55104b991e14e142267f85bb2695a59481cff0

> Coverity ID 127203 don't test variable
> The variable pgs must be valid, if it isn't we would already have
> seg faulted, so there's no point testing it.
> Not sure why coverity suddenly started detecting this, I don't
> believe the code has changed.
> devices/vector/gdevpdfg.c

2016-06-13 08:45:21 +0100
Ken Sharp <ken.sharp@artifex.com>
5eaeba97a259aca8057c48e0dc130ae7182a6bcf

> Coverity ID 94741 add a 'fall through' comment to a switch
> devices/gdevupd.c

2016-06-09 19:11:40 +0100
Robin Watts <robin.watts@artifex.com>
c1ea03762b602589acc27b8cea330ae99596edc4

> Improve splay tree handling in clumps.
> The code walks the splay tree of clumps in 3 main ways.
> Firstly it can do an inorder traversal of the tree, from
> min to max. We call this a "forward" traversal.
> Secondly it can do a reverse-inorder traversal of the tree,
> from max to min. We call this a "backward" traversal.
> Finally, and most commonly, it can do an inorder traversal
> of the tree, from an arbitrary starting position, so that when
> it hits the max, the calling code can restart it from the min.
> This latter behaviour was nastily implemented, requiring the
> callers to jump through hoops. I think that some of the callers
> had been getting it wrong, resulting in incomplete traversals
> of the tree.
> We implement a nicer version here, where the logic for looping
> from max to min, and stopping when we reach the start position
> is neatly encapsulated in the tree handling.
> We also update the clump sanity checking and call it in more
> places.
> This seems to fix the stale pointer problem that Ray has
> encountered, presumably because clumps are correctly freed
> now.
> base/gsalloc.c
> base/gxalloc.h
> psi/igc.c

2016-06-10 09:49:02 +0100
Ken Sharp <ken.sharp@artifex.com>
99e331527d541a8f01ad5455c4eb2aabd67281a6

> Fix .locksafe
> Apparently we need to .forceput the definition of getenve into
> systemdict, at least when running GSView 5.0.
> Discovered when trying to investigate a customer bug report using
> GSView 5.
> Resource/Init/gs_init.ps

2016-06-09 08:50:03 -0600
Henry Stiles <henry.stiles@artifex.com>
0d4644c003067fc14ca1db9c600dce420c06e6b1

> Add strlcpy and strlcat to ghostscript.
> Adds the FreeBsd implementation of the safer string functions. These
> replace the xps implementations which did not have proper source
> acknowledgment.
> base/gsstrl.c
> base/gsstrl.h
> base/lib.mak
> base/string_.h
> xps/ghostxps.h
> xps/xpscolor.c
> xps/xpsdoc.c
> xps/xpsimage.c
> xps/xpsmem.c
> xps/xpspage.c
> xps/xpsresource.c
> xps/xpszip.c

2016-06-07 16:16:40 -0600
Henry Stiles <henry.stiles@artifex.com>
8f0cca98368f5dd21dcbc79cae3247b57a88236c

> Remove unused remap code.
> Remove code to remap raster with bits per component that don't divide 8.
> 3,5,6 and 7 bit per pixel pcl raster is always consolidated to 8 bits
> per pixel before remapping.
> pcl/pcl/pcwhtidx.c

2016-06-07 07:49:46 -0600
Henry Stiles <henry.stiles@artifex.com>
d3d41654f43ff7a027cb9ffb271c90020a6c2de7

> Remove unnecessary remap macros.
> The free macro was never used the array has always been freed directly.
> pcl/pcl/pcwhtidx.c
> pcl/pcl/pcwhtidx.h
> pcl/pcl/rtraster.c

2016-06-08 18:02:33 +0100
Chris Liddell <chris.liddell@artifex.com>
9d7c50bce20bd870305c3206c731498bc5ef6bbd

> Bug 696824: 'post' table with out of range indices
> Loading a Truetype font with a 'post' table which has glyph indices outside
> the range of glyph names available, we'd previously exit the loop filling in
> the array of names early - leaving subsequent entries in the array unset.
> Which would, later, cause a typecheck error.
> To be more tolerant, when we encounter an index outside the available range,
> just use notdef for that position in the name array.
> Resource/Init/gs_ttf.ps

2016-06-07 10:28:54 +0100
Ken Sharp <ken.sharp@artifex.com>
054861374d6822738865892d5a0c2bb78cd58a9d

> PDF interpreter - refuse to set degenerate text matrix
> Bug 696817 "Regression: text missing starting with 83e211723f975beff6ce488a2a6ee5105c089121"
> The file sets a font size of 0 and then a ridiculous text matrix:
> -2147483648 -2147483648 -2147483648 -2147483648 197 380 Tm
> Combined with the CTM this leads to a degenerate CTM (the 2-dimensional
> co-ordinates all map to a one dimensional line). This is clearly silly.
> This is not in fact a regression, I modified the code so that it would
> behave the same when TextAlphaBits is set as when it is not. Although
> this file did 'work' previously, when TextAlphaBiots is not set, it
> did not work if TextAlphaBits was set, so the code works as expected.
> This commit adds a test for a degenerate matrix resulting from Tm and
> ignores it if it would. We already 'fix' a font size of 0.
> Resource/Init/pdf_ops.ps

2016-06-06 17:39:44 +0100
Ken Sharp <ken.sharp@artifex.com>
3cdf4f936d07333e78f545d67ce14ccbe4290b4c

> Add 'fall through' comments to many switch cases to satisfy Coverity
> base/gdevdrop.c
> base/gdevprn.c
> base/gdevvec.c
> base/gsbitops.h
> base/gsdevmem.c
> base/gsdparam.c
> base/gsfunc4.c
> base/gsht.c
> base/gsparamx.c
> base/gxclimag.c
> base/gxclrast.c
> base/gxpath2.c
> base/sstring.c
> cups/gdevcups.c
> devices/gdevupd.c
> devices/gdevxalt.c
> devices/vector/gdevpdfd.c
> devices/vector/gdevpdtd.c
> devices/vector/gdevtxtw.c
> psi/imainarg.c
> psi/interp.c
> psi/iscan.c
> psi/iscannum.c
> psi/zcolor.c
> psi/zmedia2.c

2016-06-06 16:45:34 +0100
Chris Liddell <chris.liddell@artifex.com>
c4dd42e0bcfd9e5bdd42a248111b5786ad7096cb

> Fix two makefile typos from the imager_state->gs_gsgstate commit
> First was a missing closing parenthasis in a macro reference in psi/int.mak
> Second was using a period ('.') in a macro name in base/lib.mak
> Oddly, neither of these manifested with GNU make, only with nmake on Windows.
> base/lib.mak
> psi/int.mak

2016-02-24 12:50:47 +0000
Chris Liddell <chris.liddell@artifex.com>
45dcf097558e880a76f569dd8d6c678f6ed186ce

> Make gs_imager_state == gs_state.
> Change how gstate initialisation is done:
> Previously we relied on the imager state being a subset of the gstate (thus
> assigning an imager state to a graphics state over wrote to the entries
> common to both, and didn't overwrite any already set graphics state specific
> entries).
> Making the imager and graphics states the same means that approach doesn't work,
> so this changes it to initialise the entries individually.
> Renames gsistate.c->gsgstate.c and gxistate.h->gxgstate.h
> Cleanup and fix the gs_state gc stuff.
> Uses different check for pre/post clist pdf14 device
> Previously, the code used "is_gstate" in the imager/graphics state object
> to determine if the code was being called pre or post clist (post clist would
> only ever have had an imager_state so is_gstate = false).
> With no imager state any more, that test would no longer work (and I am dubious
> about whether it was really safe, anyway). Other places check for the presence
> of a clist reader device in the pdf14 device structure - so use that here
> too.
> Adds initial (NULL) value for show_gstate pointer in gs_state.
> Removes the now pointless macro for the contents of the graphics state
> Changes function names that had "imager" to use "gstate"
> Removes the redundant 'is_state' flag
> Cleans up gs_(g)state_putdeviceparams():
> Previously we had to similar routines: one took a graphics state, and used the
> device from the graphics state, the other took an imager state and the device
> as an explicit parameter.
> With the removal of the imager state, "merge" those two functions
> Replaces gs_state with gs_gstate
> It makes for less confusion as it really is a g(raphics)state
> base/gdevabuf.c
> base/gdevbbox.c
> base/gdevddrw.c
> base/gdevdevn.c
> base/gdevdevn.h
> base/gdevdflt.c
> base/gdevflp.c
> base/gdevmpla.c
> base/gdevmplt.c
> base/gdevnfwd.c
> base/gdevoflt.c
> base/gdevp14.c
> base/gdevp14.h
> base/gdevplnx.c
> base/gdevsclass.c
> base/gdevvec.c
> base/gdevvec.h
> base/gsalpha.c
> base/gsalpha.h
> base/gsalphac.c
> base/gscdevn.c
> base/gscdevn.h
> base/gschar.c
> base/gschar.h
> base/gscicach.c
> base/gscicach.h
> base/gscie.c
> base/gscie.h
> base/gsciemap.c
> base/gsclipsr.c
> base/gsclipsr.h
> base/gscolor.c
> base/gscolor.h
> base/gscolor1.c
> base/gscolor1.h
> base/gscolor2.c
> base/gscolor2.h
> base/gscolor3.c
> base/gscolor3.h
> base/gscoord.c
> base/gscoord.h
> base/gscpixel.c
> base/gscscie.c
> base/gscsepr.c
> base/gscsepr.h
> base/gscspace.c
> base/gscspace.h
> base/gscssub.c
> base/gscssub.h
> base/gsdevice.c
> base/gsdevice.h
> base/gsdfilt.c
> base/gsdfilt.h
> base/gsdps.c
> base/gsdps.h
> base/gsdps1.c
> base/gsequivc.c
> base/gsequivc.h
> base/gsfont.c
> base/gsfont.h
> base/gsgstate.c
> base/gshsb.c
> base/gshsb.h
> base/gsht.c
> base/gsht.h
> base/gsht1.c
> base/gsht1.h
> base/gshtscr.c
> base/gshtx.c
> base/gshtx.h
> base/gsicc.c
> base/gsicc_cache.c
> base/gsicc_cache.h
> base/gsicc_cms.h
> base/gsicc_create.c
> base/gsicc_create.h
> base/gsicc_manage.c
> base/gsicc_manage.h
> base/gsicc_nocm.c
> base/gsicc_profilecache.c
> base/gsicc_profilecache.h
> base/gsicc_replacecm.c
> base/gsimage.c
> base/gsimage.h
> base/gsimpath.c
> base/gsiparm2.h
> base/gsistate.c
> base/gslib.c
> base/gsline.c
> base/gsline.h
> base/gsnamecl.c
> base/gsnamecl.h
> base/gsncdummy.c
> base/gsovrc.c
> base/gspaint.c
> base/gspaint.h
> base/gspath.c
> base/gspath.h
> base/gspath1.c
> base/gspath2.h
> base/gspcolor.c
> base/gspcolor.h
> base/gsptype1.c
> base/gsptype1.h
> base/gsptype2.c
> base/gsptype2.h
> base/gsrefct.h
> base/gsrop.c
> base/gsrop.h
> base/gsshade.c
> base/gsshade.h
> base/gsstate.c
> base/gsstate.h
> base/gsstype.h
> base/gstext.c
> base/gstext.h
> base/gstrans.c
> base/gstrans.h
> base/gstype1.c
> base/gstype1.h
> base/gstype2.c
> base/gstype42.c
> base/gx.h
> base/gxacpath.c
> base/gxblend.h
> base/gxblend1.c
> base/gxccache.c
> base/gxcdevn.h
> base/gxchar.c
> base/gxchar.h
> base/gxchrout.c
> base/gxchrout.h
> base/gxcht.c
> base/gxcie.h
> base/gxcldev.h
> base/gxclimag.c
> base/gxclip.c
> base/gxclip.h
> base/gxclip2.c
> base/gxclipm.c
> base/gxclist.c
> base/gxclist.h
> base/gxclpath.c
> base/gxclpath.h
> base/gxclrast.c
> base/gxclrect.c
> base/gxcmap.c
> base/gxcmap.h
> base/gxcomp.h
> base/gxcoord.h
> base/gxcpath.c
> base/gxcspace.h
> base/gxdcconv.c
> base/gxdcconv.h
> base/gxdcolor.c
> base/gxdcolor.h
> base/gxdevcli.h
> base/gxdevice.h
> base/gxdevmem.h
> base/gxdht.h
> base/gxdhtserial.c
> base/gxdhtserial.h
> base/gxfapi.c
> base/gxfapi.h
> base/gxfcache.h
> base/gxfill.c
> base/gxfont.h
> base/gxfont42.h
> base/gxgstate.h
> base/gxhintn.c
> base/gxhldevc.c
> base/gxhldevc.h
> base/gxht.c
> base/gxht.h
> base/gxht_thresh.c
> base/gxi12bit.c
> base/gxi16bit.c
> base/gxicolor.c
> base/gxifast.c
> base/gximag3x.c
> base/gximag3x.h
> base/gximage.c
> base/gximage.h
> base/gximage1.c
> base/gximage2.c
> base/gximage3.c
> base/gximage3.h
> base/gximage4.c
> base/gximono.c
> base/gxiparam.h
> base/gxipixel.c
> base/gxiscale.c
> base/gxistate.h
> base/gxp1impl.h
> base/gxpaint.c
> base/gxpaint.h
> base/gxpath.h
> base/gxpcmap.c
> base/gxpcolor.h
> base/gxpcopy.c
> base/gxpdash.c
> base/gxshade.c
> base/gxshade.h
> base/gxshade1.c
> base/gxshade4.c
> base/gxshade4.h
> base/gxshade6.c
> base/gxstate.h
> base/gxstroke.c
> base/gxtext.h
> base/gxttfb.c
> base/gxtype1.c
> base/gxtype1.h
> base/gzacpath.h
> base/gzht.h
> base/gzline.h
> base/gzstate.h
> base/lib.mak
> contrib/eplaser/gdevescv.c
> contrib/japanese/gdevlbp3.c
> contrib/japanese/gdevp201.c
> contrib/lips4/gdevl4v.c
> contrib/opvp/gdevopvp.c
> contrib/pcl3/eprn/eprnparm.c
> contrib/pcl3/eprn/gdeveprn.c
> contrib/pcl3/eprn/gdeveprn.h
> cups/gdevcups.c
> devices/devs.mak
> devices/gdevbit.c
> devices/gdevdsp.c
> devices/gdevepsn.c
> devices/gdevgprf.c
> devices/gdevijs.c
> devices/gdevo182.c
> devices/gdevokii.c
> devices/gdevpbm.c
> devices/gdevperm.c
> devices/gdevpng.c
> devices/gdevpsd.c
> devices/gdevrinkj.c
> devices/gdevsgi.c
> devices/gdevsj48.c
> devices/gdevtrac.c
> devices/gdevtsep.c
> devices/gdevx.c
> devices/gdevxcf.c
> devices/gdevxini.c
> devices/gxfcopy.c
> devices/vector/gdevpdfb.c
> devices/vector/gdevpdfc.c
> devices/vector/gdevpdfc.h
> devices/vector/gdevpdfd.c
> devices/vector/gdevpdfg.c
> devices/vector/gdevpdfg.h
> devices/vector/gdevpdfi.c
> devices/vector/gdevpdfk.c
> devices/vector/gdevpdft.c
> devices/vector/gdevpdfv.c
> devices/vector/gdevpdfx.h
> devices/vector/gdevpdtc.c
> devices/vector/gdevpdte.c
> devices/vector/gdevpdti.c
> devices/vector/gdevpdts.c
> devices/vector/gdevpdts.h
> devices/vector/gdevpdtt.c
> devices/vector/gdevpdtt.h
> devices/vector/gdevpsdf.h
> devices/vector/gdevpsdi.c
> devices/vector/gdevpsds.c
> devices/vector/gdevpsds.h
> devices/vector/gdevpsdu.c
> devices/vector/gdevpsfx.c
> devices/vector/gdevpx.c
> devices/vector/gdevtxtw.c
> devices/vector/gdevxps.c
> doc/Drivers.htm
> gpdl/psi/psitop.c
> pcl/pcl/pcommand.c
> pcl/pcl/pcpage.c
> pcl/pcl/pcpatrn.c
> pcl/pcl/pcrect.c
> pcl/pcl/pcstate.h
> pcl/pcl/pctext.c
> pcl/pcl/pctop.c
> pcl/pcl/pgdraw.c
> pcl/pcl/pgfont.c
> pcl/pcl/pglabel.c
> pcl/pcl/pgstate.h
> pcl/pcl/rtraster.c
> pcl/pl/plchar.c
> pcl/pl/plchar.h
> pcl/pl/pldraw.c
> pcl/pl/pldraw.h
> pcl/pl/plfapi.c
> pcl/pl/plht.c
> pcl/pl/plht.h
> pcl/pl/plmain.h
> pcl/pl/pluchar.c
> pcl/pxl/pxerrors.c
> pcl/pxl/pxfont.c
> pcl/pxl/pxgstate.c
> pcl/pxl/pxgstate.h
> pcl/pxl/pximage.c
> pcl/pxl/pxink.c
> pcl/pxl/pxl.mak
> pcl/pxl/pxpaint.c
> pcl/pxl/pxsessio.c
> pcl/pxl/pxstate.c
> pcl/pxl/pxstate.h
> pcl/pxl/pxtop.c
> psi/gserver.c
> psi/icie.h
> psi/icolor.h
> psi/icontext.c
> psi/icstate.h
> psi/igstate.h
> psi/int.mak
> psi/zchar.c
> psi/zchar1.c
> psi/zchar42.c
> psi/zcie.c
> psi/zcolor.c
> psi/zcontext.c
> psi/zcrd.c
> psi/zcsindex.c
> psi/zdevice2.c
> psi/zdpnext.c
> psi/zdps.c
> psi/zdps1.c
> psi/zgstate.c
> psi/zht2.c
> psi/zicc.c
> psi/zmatrix.c
> psi/zpath.c
> psi/zpath1.c
> psi/zpcolor.c
> psi/ztrans.c
> psi/zupath.c
> psi/zusparam.c
> psi/zvmem.c
> windows/ghostscript.vcproj
> windows/ghostscript_rt.vcxproj
> xps/ghostxps.h
> xps/xpscff.c
> xps/xpsfapi.c
> xps/xpsgradient.c
> xps/xpspage.c
> xps/xpstile.c
> xps/xpstop.c
> xps/xpsttf.c

2016-06-06 10:49:07 +0100
Chris Liddell <chris.liddell@artifex.com>
41d8d83a77ee6ea12109dde7b72dedc61cca01a3

> Coverity ID: 94795 handle stack based T1 hinter state
> If the Type 1 hinter state is a stack allocation, then the 'memory' pointer
> will be NULL, so pass a suitable allocator into the functions that need them,
> rather than assuming the hinter state one will be valid.
> base/gstype1.c
> base/gstype2.c
> base/gxhintn.c
> base/gxhintn.h

2016-06-06 13:19:20 +0100
Ken Sharp <ken.sharp@artifex.com>
8f644a331f5d5c79a523c35495b0751d8ba44916

> Coverity ID 94995 - take 2....
> Turns out there are two chunks of code that need to be removed. The code
> is currently dead, but we might want it someday so #if 0 it out rather
> than simply deleting it.
> devices/vector/gdevpsfu.c

2016-06-06 13:12:06 +0100
Ken Sharp <ken.sharp@artifex.com>
1d1bcc3997e44f36b5559163cca738091c035813

> Coverity ID 95084
> Turns out there were two places where we needed a NULL dererference
> check
> devices/gdevxcmp.c

2016-06-06 12:32:50 +0100
Ken Sharp <ken.sharp@artifex.com>
d020de175b5c26f9fb06d28fa3e2010ba4dbfcb9

> Coverity ID 126581 - cast to avoid implicit sign extension
> devices/gdevtifs.c

2016-06-06 11:57:28 +0100
Ken Sharp <ken.sharp@artifex.com>
154c010b817eb171e10e91d5ff5aaa946127f8ad

> Coverity ID 94540
> missed a check on fseek return code
> devices/gdevsgi.c

2016-06-06 11:30:33 +0100
Ken Sharp <ken.sharp@artifex.com>
dd0c18056a5f28ad43f23860a5e54b990d9d64a2

> Coverity ID 127115
> check pis before dereferencing pointer, return error if NULL
> devices/vector/gdevxps.c

2016-06-06 10:31:49 +0100
Ken Sharp <ken.sharp@artifex.com>
716a2e45caac97bb1e91484b0f706e47801d71d5

> Coverity IDs 94897, 127116
> Missed a chack against a buffer size in earlier commit
> the file descriptor 'fd' is initially set negative, need to check
> the value before trying to close it.
> devices/gdevijs.c

2016-06-06 10:21:01 +0100
Ken Sharp <ken.sharp@artifex.com>
25936513d5dfc0270f23be57d8c79de32a0e45eb

> Coverity ID 127117
> us is an unsigned short, so remove the pointless test 'us < 0'
> devices/gdevifno.c

2016-06-03 16:32:27 +0100
Chris Liddell <chris.liddell@artifex.com>
bc06a8ac477bd5b08e34c5e74d70bc6107255da0

> Coverity ID: 94951 limit the size of strings.....
> .... read from the command line
> base/mkromfs.c

2016-06-03 16:11:02 +0100
Chris Liddell <chris.liddell@artifex.com>
e48b8ea64488d065d647212eb205ae2041f6fe30

> Coverity 94527: check a return code.
> psi/zfapi.c

2016-06-03 15:26:17 +0100
Chris Liddell <chris.liddell@artifex.com>
3cbaf3dc7d1e8790bd9b6cb748a6ea88052522c7

> Coverity ID: 94590 Initialise ref to null object.
> Previously we initialised a ref pointer to NULL, which coverity reckoned could
> result in a null pointer dereference.
> Instead, initialise it to a reference to a null object.
> psi/interp.c

2016-06-03 16:10:32 +0100
Ken Sharp <ken.sharp@artifex.com>
bc90e4de0e59a1c8ccefc4b367220d36f9213beb

> Test use of 'fall through' comment to silence Coverity
> When encountering switch cases where we deliberately don't have a
> break.
> base/gdevbbox.c
> base/gdevprn.c

2016-06-03 10:43:09 +0100
Ken Sharp <ken.sharp@artifex.com>
cff9c80230086676a22c1c9f81457855bd8c69c5

> Coverity ID - 95084ce inside
> Move a pointer derefeferene into a if clause checking for NULL
> devices/gdevxcmp.c

2016-06-01 16:01:33 +0100
Ken Sharp <ken.sharp@artifex.com>
ba73a9d5cf2dcdd84d74046288c9e056ce39f5df

> Coverity ID 94895
> Don't ignore a return code
> devices/gdevxcf.c

2016-06-01 15:58:02 +0100
Ken Sharp <ken.sharp@artifex.com>
e63a4886b3b345db5b9656c7b82d3fcf91436d85

> Coverity IDs 94767, 126581
> Avoid a potential (probably impossible) divide-by-zero
> Remove pointless test of unsigned variable < 0
> devices/gdevstc2.c

2016-06-01 15:45:40 +0100
Ken Sharp <ken.sharp@artifex.com>
f8d1ca815990feca25a1ef5dad70aa177d9c4670

> initialise some variables to silence a CPP warning
> devices/gdevijs.c

2016-06-01 15:41:38 +0100
Ken Sharp <ken.sharp@artifex.com>
afbab2f5452541d45ca4186a743f95fe4c28370a

> Check return code - compiler warning
> The code was not checking the return value of sgi_begin_page() which
> could fail. If we then continued, various members of 'cur' could
> be used uninitialised and in any event the device could not possibly
> continue safely.
> NB this could happen if we wrote multiple pages and did not specify
> '%d' in the OutputFile or if we exhausted memory.
> devices/gdevsgi.c

2016-06-01 15:25:11 +0100
Ken Sharp <ken.sharp@artifex.com>
b5e474eca6e8b83f5b4a5bce2b2736c70ca3e3d6

> Various Coverity IDs
> 94605 - logically dead code, remove the dead code
> 94779 - dereference NULL - test pointer before use
> 94940 - cast to avoid sign extension
> 121446 - cast to avoid overflow
> 126582 - cast to avoid sign extension
> devices/gdevstc.c

2016-06-01 14:49:48 +0100
Ken Sharp <ken.sharp@artifex.com>
aa8ac2b01659b998f5561bbabb3b0f863d88fd3e

> Coverity ID 94540 check and action a return code
> devices/gdevsgi.c

2016-06-01 14:38:35 +0100
Ken Sharp <ken.sharp@artifex.com>
1ef49f0612b367bfca7ebec1642b5a20fc440852

> Coverity IDs 94791, 95082
> I *think* this will solve the Coverity complaint about the sprintf
> mismatch. Only way to find out is to try it.
> devices/gdevlp8k.c

2016-06-01 10:13:41 +0100
Ken Sharp <ken.sharp@artifex.com>
a42440365ee0fa333d28005a511090e9f7530ed1

> IJS device - Coverity IDs 94848, 94897, 94970, 94997
> Close an fd (result of 'dup') on error
> Check the return value from a routine against array bounds before using
> it as an array index.
> devices/gdevijs.c

2016-06-01 09:37:12 +0100
Ken Sharp <ken.sharp@artifex.com>
3cb304a014ca7bfdfe7196bb10ca0fd6498de13a

> inferno device - Coverity ID 94985 - prevent overrun
> Explicitly check a calculated buffer index to ensure it is not past the
> end of the buffer.
> devices/gdevifno.c

2016-06-01 09:30:15 +0100
Ken Sharp <ken.sharp@artifex.com>
97c955fc3a92f8286382f5242a82f8aec45416ae

> inkcov - Coverity IDs 94600, 94671, 94820, 95003
> Explicit check of total_pix to guarantee no divide-by-zero error. This
> could only occur if page width or height was 0, which *should* be
> impossible anyway.
> Promote a 32-bit signed int to a 64-bit unsigned to prevent potential
> signed overflow (2 times).
> devices/gdevicov.c

2016-05-31 15:28:48 +0100
Ken Sharp <ken.sharp@artifex.com>
04b455ea5a59866f4955f07c295c6fd955ea9a7f

> Coverity ID 94636 Remove dead code, pointless test and now unused variable
> devices/gdevescp.c

2016-05-31 14:42:05 +0100
Ken Sharp <ken.sharp@artifex.com>
5a7a7f4ed4effb576368c7b923c4aa95aef0f5b4

> ToUnicode CMaps - avoid buffer overrun
> Bug 696811 "Regression: address sanitizer error starting with 9dba57f0f9a53c130ec2771c0ed1d7bd6bbef6ab"
> An oversight when I rewrote the ToUnicode CMap processing recently.
> Originally the ToUnicode CMap array always carried 2 bytes; now it can
> hold an arbitrary length of data.
> However, I'd missed the fact that there is one location which expects
> to read 2 bytes, if we are only storing 1, and we reach the end of the
> array (maximum character code) then we would read one byte past the end
> of the array.
> Fixed here by checking the size of the value and only reading the second
> byte if there are at least 2 (set the second byte value to 0 if not).
> base/gsfcmap.c

2016-05-31 10:16:37 +0100
Ken Sharp <ken.sharp@artifex.com>
85cec887fbd31099b2c6977f4427b20d25f98714

> pdfwrite - prevent invalid combination of encryption and linearisation
> The pdfwrite device does linearization as a post-creation process,
> this makes it difficult to deal with encryption as we alter the object
> numbers, and the object number is used as part of the encryption.
> In order to support this we would have to decrypt each string or stream
> and then re-encrypt with a different encryption key using the new
> object number.
> This is way too much effort for a feature of such marginal utility.
> Instead, prevent the combination taking place, and document this as a
> limitation.
> devices/vector/gdevpdfp.c
> doc/VectorDevices.htm

2016-05-30 09:47:16 +0100
Ken Sharp <ken.sharp@artifex.com>
bce0e0b651b2ec2c14b6d28b3da290f48b2b49dd

> Coverity IDs 94672, 94998 dead code, unused value
> cups/gdevcups.c

2016-05-29 11:40:54 +0100
Ken Sharp <ken.sharp@artifex.com>
a99ac607787704b0171db55846976aa8438b85e7

> pdfwrite - #if out some unused code
> This code causes Coverity to complain about 'countof', quite rightly.
> However the code cannot currently be executed as subset_glyphs is
> always NULL. The code looks like it might (if fixed) possibly be
> useful so for now I've used #if 0 to remove it.
> devices/vector/gdevpsfu.c

2016-05-29 11:09:05 +0100
Ken Sharp <ken.sharp@artifex.com>
6d772c95b87f9d5e81b49f15badb1d58d1448fee

> xpswrite - various Coverity IDs
> IDs:
> 94615 - remove dead code (can only get to this point with pie == NULL)
> 94646 - check pointer non-NULL before dereference
> 94666 - return error if allocation fails
> 94878 - Move assignment after NULL pointer check
> 94894 - check and action a return value
> devices/vector/gdevxps.c

2016-05-28 10:13:09 +0100
Ken Sharp <ken.sharp@artifex.com>
b4e0f2080b25fc3518d9e4fb68f4d7d478bac8eb

> Coverity ID 94614 - remove dead code
> lnum can only be 0 on the first time round the loop, initially
> num_blank_lines is 0, and is only modified in the 'if' clause, whereas
> the test against lnum is in the else clause. So num_blank_lines
> cannot be non-zero on the first pass, and lnum cannot be zero on
> subsequent passes. Therefore the code is dead.
> devices/gdev3852.c

2016-05-26 14:34:25 +0100
Ken Sharp <ken.sharp@artifex.com>
1f8219335025566277364bde52315aa339d6fda4

> pdfwrite - remove an unused (and rather pointless) function
> devices/vector/gdevpdfx.h
> devices/vector/gdevpdts.c

2016-05-26 14:02:04 +0100
Ken Sharp <ken.sharp@artifex.com>
d5f17bbf37e4090952080423e3aa35c29c2751f5

> txtwrite - fix the ToUnicode processing
> commit 9dba57f0f9a53c130ec2771c0ed1d7bd6bbef6ab inadvertently broke
> txtweite, I changed the meaning of the return value from the font
> decode_glyph method. Initially I had intended it to be a count of
> unsigned shorts, but altered it to bytes. Unfortunately I had
> changed txtwrite for shorts, but forgot to change it for bytes.
> This led to a buffer overrun and heap corruption.
> devices/vector/gdevtxtw.c

2016-05-26 13:00:24 +0100
Ken Sharp <ken.sharp@artifex.com>
094d5a1880f1cb9ed320ca9353eb69436e09b594

> pdfwrite - honour PDFA-2 restriction on OPM
> Bug 696799 " Conformation to PDF/A fails specification ISO 19005-2:2011, clause: 6.2.4.2, test number 2 in veraPDF"
> It seems the standards committee decided to disallow OPM 1, essentially.
> The spec does say that its only disallowed when a CMYK space is used
> and overprinting is true for either stroke or fill, but since that's
> the only time its ever used that essentially means it can't be set.
> This seems like a bad idea, because PDF/A-1 did *not* enforce this,
> which means that the same file cna make a valid PDF/A-1 but not a valid
> PDF/A-2.
> Still nobody asked my opinion, and its in the spec, so this commit
> enforces it. We can't wait until its actually *used*, we have to
> prevent it being set in the first place.
> devices/vector/gdevpdfg.c

2016-05-25 16:56:46 +0100
Ken Sharp <ken.sharp@artifex.com>
f25436308ce95a714319c572b7fa2f571ef5e84b

> PDF interpreter - fix GlyphNames2Unicode with 2 byte keys
> Bug 695834 "After processing a pdf file with PDF writer copy & paste doesn't work anymore"
> The .convert_ToUnicode-into-g2u function translates .CodeMapData
> (which is generated from a CMap) into a GlyphNames2Unicode dictionary,
> but due to an oversight, when the high byte of an integer key was set
> (via the 'offset' stored in .CodeMapData) it was not being added to the
> key when generating ranges, with the result that the keys were incorrect
> and could overwrite earlier values.
> Resource/Init/pdf_font.ps

2016-05-25 16:53:57 +0100
Ken Sharp <ken.sharp@artifex.com>
0124e1a5e635abc4cb65e53ca13930e3b95499fe

> Fonts - add some new glyph names to the Unicode Decoding resource
> Bug 695806 "Words with ligatures cannot be searched for in PDF created with ps2pdf"
> TeX seems to use some non-standard glyph names for ligatures, just
> add those names to the existing ones for the benefit of ToUnicode
> CMap generation
> Resource/Decoding/Unicode

2016-05-25 16:51:20 +0100
Ken Sharp <ken.sharp@artifex.com>
9dba57f0f9a53c130ec2771c0ed1d7bd6bbef6ab

> pdfwrite - ToUnicode revamp
> Bug 695461 " Why does the search results changes after pdf optimzation in ghostscript?"
> The existing ToUnicode functions were written against the original
> ToUnicode specification, and assume that there will be no more than
> 2 unsigned shorts returned as the Unicode code point for any given
> glyph. Sadly Adobe have revised the ToUnicode CMap making it the same
> as a regular CMap, and then extending it still further.
> It is now possible for a single glyph to map to a string of up to
> 512 bytes.
> This commit revises the existing C 'decode_glyph's so that instead of
> returning a gs_char for the Unicode code point, we return a string of
> bytes. If the caller initially says that the string it is passing is
> zero bytes, then we do not copy the bytes, we just return the required
> size of the string (in bytes).
> A return value of 0 from a decode_glyph function means that the glyph
> was not in the map and so could not be 'decoded'.
> As a consequence of this change, and to further permit more than
> 2 unsigned shorts for ToUnicode CMaps, the CMap lookup enumerator
> now needs to be able to allocate memory, so the 'next_lookup'
> methods all now take a gs_memory_t pointer to make ths possible.
> The ToUnicode cmap table also has to change. Formerly it was a simple
> 4 bytes per code, either 255 or 65535 codes array. For simplicity
> I've chosen to keep it as a large continuous array, but each entry
> is now the number of bytes required to store the longest defined
> Unicode value for that font, plus 2 bytes. The 2 bytes give the length
> of the reserved space actually used by each Unicode code point. The
> bytes are stored immediately following the length (so a 2 byte length
> Pascal string if you like). This may possibly cause ToUnicode maps
> to use a lot of memory, in the short term we'll live with it because
> these only exist with pdfwrite, and that only really is expected
> to run on decent sized platforms. May need to do something better in
> future.
> base/gsfcid2.c
> base/gsfcmap.c
> base/gsfcmap.h
> base/gsfcmap1.c
> base/gsfont.c
> base/gxfcmap.h
> base/gxfont.h
> devices/vector/gdevpdtc.c
> devices/vector/gdevpdte.c
> devices/vector/gdevpsf.h
> devices/vector/gdevpsfm.c
> devices/vector/gdevtxtw.c
> pcl/pl/plfont.c
> psi/bfont.h
> psi/zbfont.c
> xps/xpscff.c
> xps/xpsttf.c

2016-05-25 13:44:28 -0700
Ray Johnston <ray.johnston@artifex.com>
a60087bafbaabf7052e65eb7f08548ae596d91d4

> Change PCL/XPS -Z: to use wall clock time on unix rather than cpu time.
> See 4a2a3c755dc51722483e3dda5eab821a9b7035d4 that does the same thing
> for PS interpreter.
> pcl/pl/plmain.c
> pcl/pl/plmain.h

2016-05-25 12:49:04 -0700
Ray Johnston <ray.johnston@artifex.com>
4a2a3c755dc51722483e3dda5eab821a9b7035d4

> Change -Z: timing output to use wall clock time rather than CPU time.
> On Windows, the gp_get_usertime would give elapsed time (wall clock),
> but on linux (depending on "use_times_for_usertime", which was defined
> on most unix systems), the result was CPU time for the process. This
> caused multi-threaded runs to show no improvement (CPU time would only
> increase a bit, but elapsed time could be much better).
> By using "realtime" for the minst->base_time and in print_resource_usage,
> all platforms work consistently.
> psi/imain.c

2016-05-25 12:33:45 -0600
Henry Stiles <henry.stiles@artifex.com>
15d4d4b5ccac7d54362d9ae2f6f400f7e26a7627

> Bug 696800 - subpolygon mode flag not reset.
> A flag is used in polygon mode when a subpolygon is created which is
> used later when building subpolygon paths (they're special). The code
> that builds the path always resets the flag so the special handling is
> not applied to regular paths. The degenerate case of creating an
> empty subpolygon resulted in the flag being left set. Now we reset
> the flag when we exit subpolygon mode.
> pcl/pcl/pgpoly.c

2016-05-25 14:12:33 +0100
Ken Sharp <ken.sharp@artifex.com>
e450c0fa22a073f468d214e763c542f7ca3a473b

> pdfwrite - fix AutoFilterStrategy for Luratech
> Commit 74d5e9fb7d70d3d3d9cf964c76c550134c822020 used an enum for the
> autofilter strategy (as well as fixing numerous other problems in the
> code) instead of a string. But this part of the Luratech code didn't
> get altered, which would have led to it not working properly
> devices/vector/gdevpsdp.c

2016-05-25 10:41:51 +0100
Chris Liddell <chris.liddell@artifex.com>
9308777ef5ce79552041ca138083a7f001799019

> Add some directories to the list in LICENSE
> Add explicit mention of iccprofiles, pcl, xps and gpdl directories to the
> list in the LICENSE file.
> LICENSE

2016-05-23 09:34:48 -0700
Michael Vrhel <michael.vrhel@artifex.com>
b62625272225b3d7beb2a7f4310089efebfc1903

> Bug 696602: Buffer overflow
> Turned out the offending code was actually unused.
> base/gsicc_manage.c
> base/gsicc_manage.h

2016-05-20 10:54:56 +0100
Chris Liddell <chris.liddell@artifex.com>
b2c68b707812f6a258c991241b4dde4fd4a8cc1d

> Coverity ID: 122659 further impossible alpha code tweak
> A while back, we identified code in gx_alloc_char_bits() that, due to long
> standing changes in the setup code, simply cannot be used. We opted to
> conditionally compile out that code, just in case.
> Coverity spotted that some later code was dependant on that now redundant code.
> So, add the later code to the conditionally compiled out code.
> base/gxccman.c

2016-05-20 10:47:05 +0100
Chris Liddell <chris.liddell@artifex.com>
29b831273bf8c7ed17835ab5ece59ea7e87ff07e

> Coverity ID: 94750 change where we get the memory pointer.
> Use a guaranteed non-NULL pointer from which to get the memory pointer for
> a fatal error message print out.
> base/gxccman.c

2016-05-19 14:46:59 +0100
Chris Liddell <chris.liddell@artifex.com>
bb5ed57c5c00d139285f16f6d69505e6d0d95f9e

> Coverity ID: 125640: check return from clump_locate_ptr()
> In this, clump_locate_ptr() should never fail in this location, if it does, it
> it is a catastrophic failure, and we should just abort.
> psi/ialloc.c
> psi/int.mak

2016-05-19 16:31:03 +0100
Chris Liddell <chris.liddell@artifex.com>
fb4a2e734e71c86261d386ce53ab92605dff503a

> Coverity ID: 94516 remove spurious range check code.
> The code alleged to be checking a length value was valid, but in fact could not
> fail, and thus had no effect.
> psi/iscanbin.c

2016-05-19 15:52:58 +0100
Chris Liddell <chris.liddell@artifex.com>
f196b120c236993ae5f01ccd5415be5da7c751c3

> Coverity ID 94563: move the fallback assignment.
> When a gc run is triggered, if a specific space (local, global etc) isn't
> specified, we try to find the space which caused it. In case it wasn't found,
> we were setting the pointer to the allocator, but doing so in the wrong place.
> Move it to a more suitable place.
> psi/ireclaim.c

2016-05-19 15:13:13 +0100
Chris Liddell <chris.liddell@artifex.com>
cb988d950c8f154e62f28b2755f2205af9b98060

> Coverity ID: 94590 initialize ierror ref contents.
> psi/interp.c

2016-05-19 15:02:50 +0100
Chris Liddell <chris.liddell@artifex.com>
7b0be9cc0ea4f8e2fc764b57d5c70a35d4f7b0ce

> Coverity ID: 94749 check a pointer != NULL
> When we search for the ID of a save level, it should never be possible to reach
> the point where save == NULL when we exit the loop - if it does, it implies
> a serious failure (most likely memory corruption), so return a totally
> impossible value.
> psi/isave.c

2016-05-19 14:55:55 +0100
Chris Liddell <chris.liddell@artifex.com>
114451da4f27bbfda36bdde201ba7bdc960a3760

> Coverity ID: 95036: ignore return from interp_reclaim
> In this case, we can safely ignore it, as it will be be triggered and handled
> at the top, next time through the loop.
> psi/interp.c

2016-05-19 09:23:08 +0100
Chris Liddell <chris.liddell@artifex.com>
d807b791559f64276d6fb1676fbab2cb66140bd0

> Remove deprecated Pn macros for pre-ANSI compilers
> These were, apparently, left in place for the benefit of libjpeg, but that has
> long since ceased to be necessary, so they were just clutter.
> base/jpeg.mak
> base/lib.mak
> base/stdpn.h
> base/stdpre.h

2016-05-19 09:25:36 +0100
Chris Liddell <chris.liddell@artifex.com>
d2772b4017397ebd3ad69022ed440b084812096a

> Add to a comment about a deprecated function
> base/gsdevice.h

2016-05-18 18:35:33 +0100
Chris Liddell <chris.liddell@artifex.com>
7d3dc0cccbf7b1a1d0a273eb78287bf8bb659fb8

> Remove gs_no_glyph, gs_min_cid_glyph and gs_max_glyph
> These were legacy remnants. Replace their remaining uses with the upper case,
> non-deprecated equivalents.
> base/gsccode.h
> base/gscencs.c
> base/gscencs.h
> base/gschar0.c
> base/gsfcid.c
> base/gsfcid2.c
> base/gsfcmap.c
> base/gsfcmap.h
> base/gsfcmap1.c
> base/gsfont.c
> base/gstext.c
> base/gxchar.c
> base/gxfapi.c
> base/gxfont.h
> devices/gdevtrac.c
> devices/vector/gdevpdtd.c
> devices/vector/gdevpdte.c
> devices/vector/gdevpdtf.c
> devices/vector/gdevpsf.h
> devices/vector/gdevpsf1.c
> devices/vector/gdevpsf2.c
> devices/vector/gdevpsft.c
> devices/vector/gdevpsfu.c
> pcl/pcl/pctext.c
> pcl/pl/plchar.c
> pcl/pl/plfapi.c
> psi/zbfont.c
> psi/zchar.c
> psi/zchar32.c
> psi/zcharout.c
> psi/zcharx.c
> psi/zfcid0.c
> psi/zfcid1.c
> psi/zfont.c
> psi/zfont32.c
> psi/zfont42.c
> xps/xpscff.c
> xps/xpsttf.c

2016-05-18 18:40:34 +0100
Chris Liddell <chris.liddell@artifex.com>
b1b8ec293a199d58742c3ed45c47f249359e3392

> Coverity ID: 94531
> Remove the check against GS_MAX_GLYPH since that is the maximum value of
> the gs_glyph data type, anyway.
> psi/zfont42.c

2016-05-18 18:32:43 +0100
Chris Liddell <chris.liddell@artifex.com>
3e210f8e786464ec1f4ec8524abdf8f6a9a6f39b

> Fix the PCL and XPS .so builds.
> The soname value wasn't being set correctly, so they both ended up being called
> libgs.so... internally.
> Makefile.in
> base/macosx.mak
> base/unix-dll.mak
> base/unix-gcc.mak
> base/unixansi.mak
> base/unixlink.mak
> configure.ac

2016-05-17 20:03:18 +0100
Chris Liddell <chris.liddell@artifex.com>
b43055a17fe8369daa100ce5b522c86f215567fd

> PCL/XPS so targets typo
> Remove the autotools markers ("@") and replace with make variable markers
> ("$()").
> base/unix-dll.mak

2016-05-19 17:48:14 -0700
Michael Vrhel <michael.vrhel@artifex.com>
07b3d1c457b146d7fc6b2e63a680366cd3002e52

> Update of ICC creator code
> The code had suffered some bit rot due to the movement of MS to
> unicode with the newer versions of Visual studio. I updated the
> project to VS 2013, fixed several bugs dealing with unicode, cleaned
> the code, and fixed issues in the creation of PS-like CMYK ICC profiles
> when using the UCR/BG data. Updated the UCR/BG data and included an
> example with Max K. Included ICC profiles for Max K and No K. The
> Max K profile would be useful in for text output with -sTextICCProfile=max_k.icc
> toolbin/color/icc_creator/ICC_Creator.sln
> toolbin/color/icc_creator/ICC_Creator/ICC_Creator.rc
> toolbin/color/icc_creator/ICC_Creator/ICC_Creator.vcproj
> toolbin/color/icc_creator/ICC_Creator/ICC_Creator.vcxproj
> toolbin/color/icc_creator/ICC_Creator/ICC_Creator.vcxproj.filters
> toolbin/color/icc_creator/ICC_Creator/ICC_CreatorDlg.cpp
> toolbin/color/icc_creator/ICC_Creator/ICC_CreatorDlg.h
> toolbin/color/icc_creator/ICC_Creator/icc_create.cpp
> toolbin/color/icc_creator/ICC_Creator/icc_create.h
> toolbin/color/icc_creator/README.txt
> toolbin/color/icc_creator/max_k.icc
> toolbin/color/icc_creator/no_k.icc
> toolbin/color/icc_creator/ucr_bg.txt
> toolbin/color/icc_creator/ucr_bg_max_k.txt
> toolbin/color/icc_creator/ucr_bg_no_k.txt

2016-05-16 10:53:53 -0700
Michael Vrhel <michael.vrhel@artifex.com>
d1e5eef9a6e62424a07194a5e04300d84a749491

> Fix Coverity 94799 Explicit null dereference
> Make sure we do not deference the backdrop if it is NULL when we are doing
> are group composing.
> base/gxblend1.c

2016-05-18 21:36:43 +0100
Mistry <smistry@trl.co.uk>
e426b1593a4b682f3cc83fc9559e4acc16ea1744

> Bug 696786 : Prevent checking too early for buffer overrun
> The code has reached near the end of the buffer so you can not just take the
> last 4 bytes, in this case you have to read any remaining bytes and make a
> return value based on that, in this edge case you have no bytes to read so the
> return value is zero.
> jbig2dec/jbig2.c

2016-05-18 18:54:35 +0100
Ken Sharp <ken.sharp@artifex.com>
1cfc3d978813a6ce0564a50718bb742024e62cdd

> Coverity IDs 94953, 94964
> Move a pointer dereference into the block that conditionally executes
> when the pointer is non-NULL. I think the pointer can never be NULL
> but we were doing the test anyway.
> Alter the declaration of a function, it was incorrect before.
> devices/gxfcopy.c

2016-05-09 12:55:56 -0700
Ray Johnston <ray.johnston@artifex.com>
33a1bb7fc1cc618e7f562a6231fc48755f4dad74

> Fix Coverity ID's: 94500, 94697, 94819, 94829, 94996, 126373.
> base/gxclimag.c
> base/gxclpath.c
> base/gxclrast.c
> base/gxclthrd.c

2016-05-18 14:44:55 +0100
Ken Sharp <ken.sharp@artifex.com>
49f43fb5c95e0bf3f3f44a9cb33393470d2388b6

> Coverity IDs 126566, 126567, 126568
> More dead code exposed by the macro removal in gsbitops.h.
> base/gximage3.c
> devices/gdevxalt.c

2016-05-18 14:10:08 +0100
Ken Sharp <ken.sharp@artifex.com>
13b3c67366aef69beed5f9c7e058c59a03714997

> Coverity ID 126579
> Explicit cast to avoid implicit cast and potential sign extension.
> Can't actually happen, but the explicit cast costs no more than the
> implicit, and avoids the warning.
> devices/vector/gdevpdfg.c

2016-05-18 13:51:38 +0100
Ken Sharp <ken.sharp@artifex.com>
991a906e492b23dc1199dc47cb6d48f25d2b9fc9

> Coverity IDs 126564, 126565
> Remove some dead code. This was also present in the macro version of
> this code, revealed by move to inline functions.
> base/gsflip.c

2016-05-18 13:28:13 +0100
Ken Sharp <ken.sharp@artifex.com>
93f26fbb884a6a26016c86e25c64f2bcd061949f

> Coverity IDs 126571, 126572, 126577
> Fallout from the change from macros to inline functions, change a function
> parameter from uint32 * to ushort * and remove the redundant type casts
> Change a variable from unint32 to ushort
> Finally, remove a redundant check for < 0 on an unsigned variable.
> base/gdevdgbr.c
> base/gdevmpla.c
> base/gsbitops.h

2016-05-18 08:49:00 +0100
Ken Sharp <ken.sharp@artifex.com>
a045d4290e2b371ed4ed8de210f8a9efa4989d01

> Various Coverity issues - 126569 126583
> While moving from macros to inline functions:
> Missed a pointer dereference, fixed.
> Missed an 'inline' declaration, fixed.
> Fixed some casts of shifts which were implicitly promoted resulting in
> potential sign problems. These were also present with the former
> macros, but are fixed now.
> base/gsbitops.h

2016-05-13 15:11:07 +0100
Ken Sharp <ken.sharp@artifex.com>
26aa9f163805f69ec54d05a1237aebbda719706a

> Font copying - fix the dropping of 'extension' (duplicate) glyphs
> Bug #696777 "AddressSanitizer heap-buffer-overflow in copied_drop_extension_glyphs"
> When we find that we have a glyph which is processed with different
> /Widths, we need to encode it specially in the font. We do this by
> extending the glyph name with a ~GS~x where x is an integer.
> For output though (pdfwrite and friends) we really don't want to emit
> these non-standard glyphs which are duplicates of existing glyphs, the
> Widths emission should take care of the metrics problem for us. (in
> fact we deal with it by leaving ghe Widths alone and alter the
> spacing with a TJ operator).
> This is supposed to be performed by 'copied_drop_extension_glyphs()'
> but the code for detecting additional duplicates was incorrect and
> caused us to read off a block of memory. Fixing that revealed another
> problem, the code which was supposed to truncate the 'extended' name
> to the normal name was using the wrong loop index and was updating
> the 'non-extended' rather than 'extended' glyph name, which of course
> had no effect.
> I've fixed both cases, and altered the names of the loop counters to
> be a little more descriptive in the hope of avoiding future such
> problems.
> This then exposed faults in the type 1 to Type 2 (CFF) conversion
> code which simply wasn't expecting slots to be unused (and as Chris
> points out rather begs the question of what this is for). Fixing this
> required ratehr more extensive changes to the converter, but it seems
> to work correctly now.
> No differences expected
> devices/gxfcopy.c
> devices/vector/gdevpsf2.c

2016-05-17 12:05:17 +0100
Chris Liddell <chris.liddell@artifex.com>
fd35140f473cd64f7c27daae268858e2277127a9

> Bug 696782: Fix the asciitilde glyph.
> The asciitilde glyph was at the wrong y offset, meaning it appeared at the top
> of the font bounding box, rather than near the middle of it.
> Resource/Font/NimbusSanL-ReguCond

2016-05-17 08:06:57 -0600
Henry Stiles <henry.stiles@artifex.com>
0b2375b2e94e08a13bf972c22eafc9c9917421da

> Missing va_end.
> pcl/pcl/pcstatus.c

2016-05-17 07:58:27 -0600
Henry Stiles <henry.stiles@artifex.com>
b0a19d008448ca5952506f6bfc67f5982de78a07

> Faulty parser control flow fixed.
> The PCL parser did not properly transition from scanning data to
> scanning parameters in short hand mode. Coverity uncovered the
> problem (102252).
> pcl/pcl/pcparse.c

2016-05-13 11:40:36 -0600
Henry Stiles <henry.stiles@artifex.com>
39b2eb4200b81e081fb97be0df4575c5ceb3afd3

> Coverity fixes.
> pcht.c 102234: parameter list released twice.
> pcsymbol.c 102225: insecure data handling.
> The latter is not a bug as far as we can tell but the readability of the
> code and directness of the checks have been improved anyway.
> pcl/pcl/pcht.c
> pcl/pcl/pcsymbol.c

2016-05-13 11:31:30 -0600
Henry Stiles <henry.stiles@artifex.com>
6c9e348bde9a8f007352c88477fb3655291b12f8

> Fix symbol set lookup.
> The PJL symbol set lookup could potentially dereference NULL for a
> couple of the sets, also we rebuild the table to simply return the
> associated symbol set number, there is no need to calculate the number
> at runtime.
> pcl/pl/pjparse.c

2016-05-13 10:01:44 +0100
Ken Sharp <ken.sharp@artifex.com>
fcedd5c71e5edac73f4240c635c6280dce918152

> pdfwrite - prevent buffer overrun
> While investigating Bug #696777, the new rectangular subpath code threw
> errors with address sanitizer. This was due to trying to pick up the
> last segment co-ordinate using the loop counter, when it should have
> been using the segment index.
> devices/vector/gdevpdfd.c

2016-05-12 17:38:44 +0100
Chris Liddell <chris.liddell@artifex.com>
6bba1f6fa4d48e9651873d34815ede36bca73a74

> Bug 696776: Allow gs run without pdfwrite installed.
> With the build consolidation change, one of the requirements was that there
> should be no dependencies in the graphics library build objects on any of
> the interpreter objects.
> That meant that gs_pdfwr.ps always gets built in, and then run by the
> initialization code, which then throws an error when pdfwrite is not
> present.
> To handle this, check if pdfwrite is available, and if not, skip executing
> the contents of gs_pdfwr.ps.
> Resource/Init/gs_pdfwr.ps
> devices/devs.mak

2016-05-13 08:29:25 +0100
Ken Sharp <ken.sharp@artifex.com>
f7b9321be1a0d029e1465af699dff52319b1c906

> Revert the use of gp_get_realtime in pdfwrite
> base/gp_win32.c
> base/time_.h
> devices/vector/gdevpdf.c
> devices/vector/gdevpdfe.c

2016-05-09 11:40:59 +0100
Chris Liddell <chris.liddell@artifex.com>
14e151e48e07af8eee5efbbc336e1a1b59eb93a2

> Build PCL and XPS as shared library and DLL
> Also, most of building gpdl as a shared lib and DLL is here, too.
> There isn't really an "API" here: the library has one entry point:
> "pl_main_aux()", this is really just the build skeleton on which we can
> assemble a real API.
> On Windows, PCL, XPS and (if forced to build) GPDL will all default to building
> a DLL and a "loader" executable (rather than the monolithic exe it build
> previously). The monolithic builds can still be done by passing nmake the
> MAKEDLL=0 option.
> On other (Unix-like) systems, they will default to the monolithic builds.
> This all mirrors the gs builds.
> Makefile.in
> base/gscdef.c
> base/std.h
> base/unix-dll.mak
> pcl/pl/gpcl6dll32.def
> pcl/pl/gpcl6dll64.def
> pcl/pl/gpdldll32.def
> pcl/pl/gpdldll64.def
> pcl/pl/gxpsdll32.def
> pcl/pl/gxpsdll64.def
> pcl/pl/pl.mak
> pcl/pl/plapi.h
> pcl/pl/plmain.c
> pcl/pl/plwimg.c
> pcl/pl/plwmainc.c
> pcl/pl/plwreg.c
> psi/msvc.mak
> xps/xps.mak

2016-05-12 12:20:33 +0100
Ken Sharp <ken.sharp@artifex.com>
a39fa755db3f83a1d1fd8611d66dde487ed95f9d

> Typo in language.htm
> Bug #696775 "Typo in documentation"
> Noticed and reported by "rrt@sc3d.org", fixed ehre.
> doc/Language.htm

2016-05-12 11:27:22 +0100
Ken Sharp <ken.sharp@artifex.com>
3e825c0ee714a26633395e95bdf143d30b14fc28

> Fix gp_get_realtime commit
> The gp_get_realtime commit attempted top use both the upper and lower
> values in the long[2] array, this turns out to be a bad idea on Unix
> systems, because that uses timeofday() instead of time(), and results
> in a time_t which causes a GPF in gmtimte() (NB I think its pretty poor that a
> function which takes a 64-bit value can cause a GPF if the value is
> sufficiently large!)
> Instead use only the bottom long. This will, eventually, cause us to
> write incorrect time stamps (when we overflow a long), we will have
> to look into that when the time comes.
> At the same time fix the definitions of gp_get_realtime() and
> gp_get_usertime() in gp.h as these were incorrect.
> base/gp.h
> devices/vector/gdevpdf.c
> devices/vector/gdevpdfe.c

2016-05-11 16:15:19 +0100
Ken Sharp <ken.sharp@artifex.com>
646248bf7730c8d2ecf4ff2d06c494a5c280d211

> Make pdfwrite use the OS-agnostic gp_get_realtime () function
> Also fix the Windows go_get_realtime() function so that it returns
> the same values as the other OS's
> The change in time_.h is to prevent the definition of timeval if we
> have already included windows.h (_WINDOWS_ is defined) as this also
> defines timeval (actually in winsock.h, claims to be copied from a BSD
> header).
> base/gp_win32.c
> base/time_.h
> devices/vector/gdevpdf.c
> devices/vector/gdevpdfe.c

2016-05-11 09:59:09 -0600
Henry Stiles <henry.stiles@artifex.com>
545defc11cdb1b7a1009ccf8103417273fb3d7ee

> Coverity fixes.
> 122662 plparams.c: resource leak.
> 122664 plparams.c, 122663 pjparse.c: unnecessary null check.
> 122661 plparams.c: negative returns.
> 102248 pcpage.c: uninitialized pointer write.
> 102237 pjparse.c: uninitialized variable.
> pcl/pcl/pcpage.c
> pcl/pl/pjparse.c
> pcl/pl/plparams.c

2016-05-11 14:34:02 +0100
Ken Sharp <ken.sharp@artifex.com>
4e9c4db88f1aff478230b7cb0c32eb60846231a3

> remove an unused variable
> commit c4a33f573adbf8627f08407e4357475285b46cf0 replaced the variable
> 'int i' with 'unsigned int j', but left the definition of i, which
> meant it was then unused leading to a cppcheck warning.
> Simply remove the now unused variable.
> devices/vector/gdevpdfg.c

2016-05-11 14:01:47 +0100
Ken Sharp <ken.sharp@artifex.com>
d5008bf9092e99b5eb7f295c9d684850bf2aa66f

> Remove a load of macros in the graphics library
> The 'load' and 'store' macros were deemed offensive for a number of
> reasons; they declared variables, hiding them from casual view, they
> hid flow control (switch statements started in one macro, ended in
> another), returns from inside macros, some macros were not (and could
> not be) bounded by "do{...} while" which means care needed to be taken
> with ';' and were very deeply nested, the names chose for the macros
> made them look like functions, finally macros are hard to debug, even
> with a macro-expanding debugger.
> Additionally there were the 'LINE_ACCUM' macros, some of which simply
> called the 'load/store' macros directly, which just added another
> layer of obfuscation, particularly since these macros were defined in
> a different header file. Macros could be nested 4 or 5 levels deep.
> This commit finishes removing all but one of the macros, the last
> remaining macro has been renamed to upper case to make it clearer that
> it is a macro. It can't easily be removed since it depends on the size
> of gx_color_index, which is a compile time #define.
> The functionality of the macros has either been expanded in line or
> replaced with inline functions declared in gsbitops.h. The majority
> of the macros have been replaced with functions, even for small functions
> where it seemed useful to keep the name as a description of the actual
> functionality.
> I don't anticipate any differences, but I think this makes the code
> easier to understand, easier to debug, and therefore easier to maintain.
> base/gdevdbit.c
> base/gdevdgbr.c
> base/gdevmpla.c
> base/gsalphac.c
> base/gsbitops.c
> base/gsbitops.h
> base/gsflip.c
> base/gxcindex.h
> base/gximag3x.c
> base/gximage3.c
> base/gxiscale.c
> devices/gdevpng.c
> devices/gdevxalt.c

2016-05-10 07:21:45 -0600
Henry Stiles <henry.stiles@artifex.com>
473afa3fbc71bd8cd1814f5e9d7f551ebbda436d

> Fix Coverity identified dereferences before null check.
> Coverity id's: 102199, 10220[012]
> pcl/pcl/pcdraw.c
> pcl/pcl/pcfrgrnd.c
> pcl/pxl/pxgstate.c

2016-05-09 10:42:50 -0600
Henry Stiles <henry.stiles@artifex.com>
a09336ddb6257103ea9d020ed8ace474e1e12df6

> Fix Coverity identified potential buffer overflows.
> Coverity numbers: 122665 (#1 - #8). Also fixes a reversed argument
> problem with an unimplemented function (100212) and a typo with a
> previous coverity problem was fixed.
> pcl/pl/pjparse.c

2016-05-10 10:15:12 +0100
Chris Liddell <chris.liddell@artifex.com>
2bf16c4c6942ffe38ded65df1d17e485843de4f0

> Remove remaining persistent cache code.
> base/gp.h
> base/gp_dvx.c
> base/gp_mac.c
> base/gp_mswin.c
> base/gp_os2.c
> base/gp_os9.c
> base/gp_vms.c

2016-05-06 15:54:32 +0100
Chris Liddell <chris.liddell@artifex.com>
db1ecd47087fa139e310d42772cb912184f5bc6a

> Remove the (unused) "persistent cache" code
> base/gp_unix_cache.c
> base/unix-aux.mak
> psi/zmisc.c

2016-05-09 09:28:00 -0700
Michael Vrhel <michael.vrhel@artifex.com>
c4a33f573adbf8627f08407e4357475285b46cf0

> Change max_components and num_components in dev.color_info to uchar
> There are locations in the code where Coverity has complained about
> code logic that resulted in passing of unintialized values that
> could only occur if num_components < 0 . Since this should never
> be the case, we will make it clear by setting num_components and
> max_components to uchar. This will limit our support to 256 colors
> by a device.
> base/gdevdbit.c
> base/gdevddrw.c
> base/gdevdevn.c
> base/gdevdevn.h
> base/gdevdgbr.c
> base/gdevdrop.c
> base/gdevmem.c
> base/gdevmpla.c
> base/gdevp14.c
> base/gdevplnx.c
> base/gscspace.c
> base/gsdparam.c
> base/gsicc_cache.c
> base/gsovrc.c
> base/gsptype2.c
> base/gxblend1.c
> base/gxclist.c
> base/gxclrast.c
> base/gxclread.c
> base/gxclrect.c
> base/gxcmap.c
> base/gxdcolor.c
> base/gxdevcli.h
> base/gxdtfill.h
> base/gxpcmap.c
> base/gxshade6.c
> cups/gdevcups.c
> devices/gdevcmykog.c
> devices/gdevpbm.c
> devices/gdevrinkj.c
> devices/gdevxcf.c
> devices/vector/gdevpdfg.c
> devices/vector/gdevpsdi.c
> psi/zcolor.c
> psi/zdpnext.c

2016-05-09 11:04:25 +0100
Ken Sharp <ken.sharp@artifex.com>
ccd831b1b17b7e5f62e43583da51505d202b4de7

> Coverity ID 126372 - incorrect test '||' instead of '&&'
> base/ttfmain.c

2016-05-09 08:38:27 +0100
Ken Sharp <ken.sharp@artifex.com>
16328264c44400e242fd2a7c0a2b38ef16abfe3c

> Coverity IDs 102152, 126374 - 1x check return value and 3x cleanup
> Missed a check of the return value from fseek in a prior commit and
> 3 cases where I added a check of a file operation, exited the function
> on error, but did not close the locally opened file.
> xps/xpszip.c

2016-05-09 08:30:54 +0100
Ken Sharp <ken.sharp@artifex.com>
ef840222e42df8d69d3e3f8a0f153c8cbe0b96db

> Coverity ID 102187 (again) - remove 2 more tests of unsigned variables > 0
> Missed the fact there were multiple occurrences in the first commit
> xps/xpsttf.c

2016-05-07 09:41:19 +0100
Ken Sharp <ken.sharp@artifex.com>
5aef585cd506caad237972953fe62f013f0fd4e2

> Replace the 'sample_load*' macros with inline functions
> base/gdevdgbr.c
> base/gdevmpla.c
> base/gsalphac.c
> base/gsbitops.c
> base/gsbitops.h
> base/gximag3x.c
> base/gximage3.c

2016-05-08 10:15:11 +0100
Robin Watts <robin.watts@artifex.com>
49a22e649644cc71e42e8f87954a01322133e96e

> Fix memset of incorrect size.
> base/gp_psync.c

2016-05-07 12:28:18 -0700
Ray Johnston <ray.johnston@artifex.com>
6329a63a5b358ff2522c9a2fee04afc7dea6e125

> Fix Coverity ID's in gdevp14.c (too many for one line)
> ID list: 95577, 94594. 94612. 94628, 94637, 94689, 94958, 94978, 95032
> 95033, 96060
> base/gdevp14.c

2016-05-06 17:09:04 +0100
Robin Watts <robin.watts@artifex.com>
43d009b93762d1c69d6f7d08b2fb7962e1ccba78

> Coverity 95029: Out of bounds write in gdevijs.c
> While parsing params, if we hit the end of the buffer, stop
> rather than trying to write into it.
> devices/gdevijs.c

2016-05-06 16:16:59 +0100
Robin Watts <robin.watts@artifex.com>
429bddce6bb0089d247e7bd6c32dbb6b7d7efdeb

> Coverity 95056: Uninitalised variable use.
> The analysis of this case going wrong relies on the variable being
> negative. Change it to be unsigned to avoid this.
> base/sfilter2.c

2016-05-06 16:07:51 +0100
Robin Watts <robin.watts@artifex.com>
20b13a63253d1271ee1b3eeaea090e269a0f27fb

> MSVC: Add missing jpegxr directory to solution
> windows/ghostscript.vcproj

2016-05-06 16:05:18 +0100
Robin Watts <robin.watts@artifex.com>
b5e075d70152429f2216ba5d002bdc9e5dadfc14

> Coverity 102233: Uninitialised variable use.
> Looks like an initialisation was dropped. Copying from similar
> functions as inspection suggets this is correct.
> jpegxr/r_strip.c

2016-05-06 08:47:41 -0600
Henry Stiles <henry.stiles@artifex.com>
224a4a9a3315873c59e6d688635615ed1a5be3d5

> Various Coverity fixes
> pjparse.c: 102194 Resource leak and 102181 argument can't be negative,
> and 102171 logically dead code.
> pjparsei.c: 102174 Dereference after null.
> plfont.c: 102189 unsigned compare against 0.
> pxfont.c: 102176 Deref after null check.
> pcl/pl/pjparse.c
> pcl/pl/pjparsei.c
> pcl/pl/plfont.c
> pcl/pxl/pxfont.c

2016-05-04 15:44:56 -0600
Henry Stiles <henry.stiles@artifex.com>
5f12ea458d83bf9f301fae6066526c4f890bae06

> Fix many unchecked returns in PCL.
> Coverity ids: 10215[013568], 10216[0579].
> pcl/pcl/pcsfont.c
> pcl/pcl/pgchar.c
> pcl/pcl/pginit.c
> pcl/pcl/pglfill.c
> pcl/pcl/rtmisc.c
> pcl/pl/pjparse.c
> pcl/pl/plmain.c
> pcl/pxl/pxgstate.c

2016-05-05 10:22:51 +0100
Robin Watts <robin.watts@artifex.com>
8e1d95eea940bca0892f016cd79d6ee72a2219ba

> Bug 696703: Shading disappears at high dpi.
> The Shading doesn't disappear, it simply plots solid white.
> This is due to an overflow in the tensor patch calculations.
> (fixed + fixed + fixed)/3 can overflow.
> Change this to be (int64_t + int64_t + int64_t)/3.
> For efficiency (and improved accuracy) we postpone the /3 until
> the end of the series of operations that use it (where it becomes
> a /9).
> base/gxshade6.c

2016-05-05 13:15:25 +0100
Robin Watts <robin.watts@artifex.com>
7032b71519c04432f2c56748103bd9dfe32ac6ff

> Revert "Makefile for Android MuPDF libgs.so"
> This reverts commit e350758ceb8d9f7ec6bb209908a6ce1fe35e2397.
> Committed in error.
> Makefile.android
> arch/android.h

2016-05-05 10:19:43 +0100
Robin Watts <robin.watts@artifex.com>
219ac028f804f8470faf502830c545b7858845b4

> Remove free variables from macros.
> In macro-hell, the lowest level is reserved for macros that
> rely on free variables. While removing the macros would be
> nicer, this at least moves it up a level.
> base/gsshade.c

2016-05-05 09:14:29 +0100
Ken Sharp <ken.sharp@artifex.com>
7cef5b5e9746ade53779ae13989e3d070337ac68

> Coverity IDs 94574, 94743, 94524, 94691
> ttfmain.c:
> Use 'code' instead of 'error', error is the wrong variable to test
> Remove pointless code with no effect
> ttinterp.c:
> Correct a copy/paste error (cur_x should be cur_y)
> remove pointless self-assignment
> base/ttfmain.c
> base/ttinterp.c

2016-05-05 06:59:31 +0100
Ken Sharp <ken.sharp@artifex.com>
e03821104b5752c7b343f7b839ec9a9c01c5f4b1

> Fix to commit 5b173d99c6ed3ebbd84eff6e63e987441a5da10d
> Slightly over-enthusiastic commit, potentially tried to free an object
> 'part' before it had been created. Three occurrences in three different
> error conditions.
> xps/xpszip.c

2016-05-04 18:55:36 -0700
Ray Johnston <ray.johnston@artifex.com>
7b916edd3554e42a4cd3de4c9bd17450e9cbb202

> Fix Coverity ID 95026: Code not reachable -- seems to be editing error.
> psi/imainarg.c

2016-05-04 13:19:59 -0700
Ray Johnston <ray.johnston@artifex.com>
c2ba126a3ca1b740526b998e5e49a1c6c6f98ce8

> Fix Coverity ID: 94491 Buffer not nul terminated.
> Leave room for the 'nul' in the count for strncpy.
> base/gxclread.c

2016-05-04 13:24:45 -0700
Michael Vrhel <michael.vrhel@artifex.com>
88f49c9ae729336e8b1e68e2e8b231eac56b6d96

> Coverity ID 119184
> Use floating point math for scaling the colors when doing the smoothness test.
> base/gscspace.c

2016-05-04 13:14:02 -0700
Ray Johnston <ray.johnston@artifex.com>
cbe50881d78c9c9bb13745569f806cb92bc14dd9

> Fix Coverity ID's: 94501, 94697 and 94712 (only last was non-trivial)
> The change to gximask.c checks to make sure that pcpath == NULL is never
> dereferenced. Others were minor/trivial and easily fixed).
> base/gxclrast.c
> base/gximask.c

2016-05-04 11:02:10 -0700
Ray Johnston <ray.johnston@artifex.com>
91158cabe4fd1d4faef98408ed3a36c3cbcc3ec7

> Fix Coverity issue 94826, Buffer overrun, 94595 De-ref after NULL check
> The 'buf' declaration had 1 instead of 2 for the cap_join case.
> The dereference after NULL check is a warning, and two case call the
> gx_default_fill_path (for shading fill) where ppath==NULL is OK, but
> we add a check before emitting the ppath via cmd_put_path since that
> _would_ dereference ppath elements. The first two are "Ignore".
> base/gxclpath.c

2016-05-04 08:51:41 -0700
Ray Johnston <ray.johnston@artifex.com>
c98fd2a26df5498593e562b2551b637acebb2896

> Fix Coverity issues 94873, 121257, 121258 and 121859.
> in gxclpage, strncpy should have the copy length 1 less than buffer size
> so that there will be room for the terminating nul. Also check return
> from clist_close_writer_and_init_reader.
> The scan of saved_pages_keys needed the countof, not sizeof the array
> of pointers (sizeof(a)/sizeof(a[0]))
> base/gxclpage.c

2016-05-03 18:00:39 +0100
Robin Watts <robin.watts@artifex.com>
a6a7e077b4936f82a32b5de1c944ae14c1881950

> Fix potential cleanup error in pthreads handling.
> When creating a semaphore, if the mutex inits, but the condition
> variable doesn't, we'd fail to destroy the mutex.
> base/gp_psync.c

2016-05-04 09:52:45 +0100
Ken Sharp <ken.sharp@artifex.com>
5b173d99c6ed3ebbd84eff6e63e987441a5da10d

> Coverity IDs 102152, 102157, 102159, 102161, 102162, 102164, 102182, 102183
> A load of unchecked return values from fseek/fread
> xps/xpszip.c

2016-05-04 09:31:21 +0100
Ken Sharp <ken.sharp@artifex.com>
ab551afbaa92aacf0a451364e1273ff6e138fab5

> Coverity ID 102152 - check if fseek failed and throw error if so
> xps/xpszip.c

2016-05-04 09:25:59 +0100
Ken Sharp <ken.sharp@artifex.com>
4327987dc81df5f9e48af83de340af8973c529cb

> Coverity ID 102188 - remove redundant check if unsigned variable < 0
> xps/xpsttf.c

2016-05-04 09:24:53 +0100
Ken Sharp <ken.sharp@artifex.com>
eeeeacfb3c62ec7954b3982edab3d39c4a4faccc

> Coverity ID 102187 - remove a redundant check of unsigned variable < 0
> xps/xpsttf.c

2016-05-04 09:23:20 +0100
Ken Sharp <ken.sharp@artifex.com>
4b252650fa3d07348b680b3b19e3d3b8672eafc2

> Coverity ID 102187 - check and action a return code
> xps/xpstop.c

2016-05-04 09:19:45 +0100
Ken Sharp <ken.sharp@artifex.com>
e99becee24fd1608084c734e34be5297ec3b4141

> Coverity ID 102257 - check and action a return value
> At the same time, cleaned up a whole load of potential memory leaks
> on error conditions.
> xps/xpspage.c

2016-05-04 09:13:41 +0100
Ken Sharp <ken.sharp@artifex.com>
fca4b8dab7f588c9e7439ce7c06d347b6eeabf59

> Coverity ID 102184 - fix white space indenting
> xps/xpsmem.c

2016-05-04 09:11:51 +0100
Ken Sharp <ken.sharp@artifex.com>
358c42de2691b9b0adb020244d6c70a20d94257c

> Coverity ID 102195 - clean up memory on error exit.
> xps/xpsjxr.c

2016-05-04 09:08:36 +0100
Ken Sharp <ken.sharp@artifex.com>
7c95a58878fd3fca7b964eb6e067cac55587286e

> Coverity ID 102246 - initialise a pointer variable
> xps/xpsgradient.c

2016-05-04 09:04:06 +0100
Ken Sharp <ken.sharp@artifex.com>
b933637c55943ce50eefdd665666ec7fc90fa25b

> Coverity ID 102235 - initialise a memory array to 0
> xps/xpscff.c

2016-05-04 08:43:45 +0100
Ken Sharp <ken.sharp@artifex.com>
e1ac3e1ce877bbbc89edbd719fab6ee304e0da38

> Luratech decoder - set the initial colour space to 'unset'
> If the image dictionary has a ColorSpace we set the colorspace member,
> and if we get to disconvering the 'N' value, and its still unset then
> we set it from the N value. But the Luratech decoder 'set_defaults'
> method didn't initially set the colorspace member to 'gs_jpx_cs_unset'
> so we might never set it from the /N value.
> base/sjpx_luratech.c

2016-05-04 08:34:51 +0100
Ken Sharp <ken.sharp@artifex.com>
b8678aa57feaf7fa60273f7c0e4fe28e44fa78c3

> Coverity ID 94683 - check pointer is not NULL before dereference
> I'm pretty sure this can't happen, but this makes certain.
> psi/zcontext.c

2016-05-02 07:55:50 -0700
Ray Johnston <ray.johnston@artifex.com>
d56fc8010e3c8456e565bab38eb54d7f218bed27

> Prevent buffer overrun during image interpolation (NOCIE, UseFastColor)
> When using NOCIE and UseFastColor to revert to non-ICC color conversion,
> we encounter a few instances where we decode samples, but the buffer was
> not being allocated for it. Bug691466.pdf and fts_17_1700.pdf through 1707
> and fts_31_3116.pdf were examples going to ppmraw.
> base/gxiscale.c

2016-05-03 09:03:54 +0100
Ken Sharp <ken.sharp@artifex.com>
e4c06b9c1cd3130cbbd4fc5599e55056f2136cf1

> Bug #692945 " Need warn equivalent of -dPDFSTOPONERROR, like -dPDFSTOPONWARN"
> This commit adds (and documents the new command line switch
> PDFSTOPONWARNING. When set this will cause the PDF interpreter to raise
> an 'undefined' error if a warning is encountered, and stop processing
> the input.
> Note that PDFSTOPONWARNING implies that PDFSTOPONERROR is true, and sets
> it if it is not.
> Resource/Init/gs_init.ps
> Resource/Init/pdf_main.ps
> doc/Use.htm

2016-05-02 15:24:33 +0100
Ken Sharp <ken.sharp@artifex.com>
e8fe0ee8255c0ee8a71e811ddeeb49a211dd6586

> Bug #696687 - cannot open encrypt pdf file
> We need to treat a /StmF value of /Identity the same as we would if the
> key was missing....
> No differences expected
> Resource/Init/pdf_sec.ps

2016-05-02 13:31:35 +0100
Ken Sharp <ken.sharp@artifex.com>
6b7d44b001788183e1222856ad84737612c84466

> Coverity ID 94530 (again) - Check and action a return code
> Missed a second occurence of the same thing.
> devices/vector/gdevpdfm.c

2016-05-02 12:28:59 +0100
Ken Sharp <ken.sharp@artifex.com>
3c99fe662db97d01a76e59a9548dd49ce6b65256

> Coverity ID 94730 - fix an incorrect index
> This one's a puzzle. Coverity is absolutely correct that the '-1'
> is invalid, as we use it later as an array index, in fact we possibly
> use it in several different sub-functions, as an array index, and its
> not valid for it to be negative in any of them. There are no tests
> on the value to take special action.
> I'm forced to conclude that it should simply be a positive '1' not a
> negative '1'.
> I am also unable to get the code to take this path, so I can't test the
> change, but the -1 was definitely wrong, and a step of 1 looks correct.
> base/gsfunc0.c

2016-05-02 11:57:22 +0100
Ken Sharp <ken.sharp@artifex.com>
08d98e00bc18b47bdf357f2c3f3ba5f47995ce68

> Coverity ID 94487 - use pre-calculated value to avoid shift
> base/gsfunc0.c

2016-05-02 09:43:34 +0100
Chris Liddell <chris.liddell@artifex.com>
7253f0cfd8f67ffab1683fb1ad9c54b4250a930f

> Coverity ID: 125783
> Move memory freeing into the common cleanup code before function returns:
> fixes leak in event of an error.
> Also, add some pointer initialisation for safety.
> base/mkromfs.c

2016-05-02 09:41:28 +0100
Chris Liddell <chris.liddell@artifex.com>
a8f8634c36cdfcf516cd0576127a84f1b09921c2

> Coverity ID: 125785
> Move string buffer freeing *after* the error message that uses the buffer
> base/genconf.c

2016-05-02 09:35:07 +0100
Chris Liddell <chris.liddell@artifex.com>
417aacf016f3e4298e9c825aa9b4586434b36a76

> scan-build warnings in zfapi.c and gxfapi.c
> zfapi.c: initialize pointer and check it's valid before using it
> gxfapi.c: remove unnecessary assignment.
> base/gxfapi.c
> psi/zfapi.c

2016-05-02 09:44:18 +0100
Ken Sharp <ken.sharp@artifex.com>
ebdb8acb36a8084089fa7093882a40a4484640fb

> Coverity ID 94546 - correct impossible condition
> the a_all bit mask does not include the 'a_executable' bit, making the
> r_has_masked_attrs() test always return false. We do not have a test
> case for this invalid parameter, but I think this is at least an
> improvement.
> psi/zshade.c

2016-04-30 11:18:12 +0100
Chris Liddell <chris.liddell@artifex.com>
c8827f917d2ff40ffeda384fa8df0ceaed2670de

> Coverity IDs: 94798, 94930, 94932, 94951, 95022
> 94798: check for null before using pointer
> 94930: Initialize structure before using
> 94932: use %d for "int" in printf (rather than %ld)
> 94951: Use an intermediate string buffer (limiting string size) to protect from
> buffer overflow.
> 95022: use %d for "int" in printf (rather than %ld)
> base/mkromfs.c

2016-04-30 11:07:01 +0100
Chris Liddell <chris.liddell@artifex.com>
ad59c4428676c61ce2c44b21d76b84154bbec26d

> Coverity IDs: 94527, 94804, 94888
> 94527: fix ignored return value
> 94804: the code could not fall into the condition Coverity warned about (the
> condition is checked by the calling code. But adding a "default" to the innner
> switch should clear the warning, make the code clearer, and not cost us
> anything.
> 94888: explicit cast to avoid unintended sign confusion.
> psi/zfapi.c

2016-05-02 08:26:14 +0100
Ken Sharp <ken.sharp@artifex.com>
7ba62042a98039203b45b019ffc523778de38513

> Coverity ID 94706 - fix a copy/paste error
> Commit 1ba0d89544ba6d057867648027c5a6919888c619 was meant to test for
> 'pgd' being non-NULL but a silly copy/paste error tested 'pgd->bits.data'
> by mistake.
> base/gstype1.c

2016-05-02 08:19:43 +0100
Ken Sharp <ken.sharp@artifex.com>
94c7469f9d4dff9c32314b95b89f00e584ec1ed4

> Coverity ID 125639 (again) - clamp page number to 0
> Commit 83353631064ac5307a9b62877d5a0664e7ac800e fixed 2 occurrences
> but missed a 3rd one.
> base/gdevflp.c

2016-05-02 08:16:21 +0100
Ken Sharp <ken.sharp@artifex.com>
8b8725f7fbf9bd51a20459caeeda487bee019cf4

> Coverity ID 121436 (again) - guard a 2nd place where a pointer is dereferenced
> Commit 5655e62da7ad0a4c6368994a11cdb9954d1fa296 missed a second place
> where 'textures' is dereferenced.
> base/gdevdrop.c

2016-05-02 08:11:54 +0100
Ken Sharp <ken.sharp@artifex.com>
38de4f3a79583a2b7147a369a86cb1e599331300

> Coverity ID 94765 (again) - really make sure array index is not negative
> commit fa1757fe4317171cd45755d0b66111ebf12be920 only fixed half the
> problem (possibility of num_planes being 0 or less), technically we can
> still go round the loop and have no planes requested (params-data[]
> all being 0). This should never happen of course, but this ensures that
> if it does we throw an error, instead of crashing.
> base/gdevdgbr.c

2016-05-02 08:05:02 +0100
Ken Sharp <ken.sharp@artifex.com>
ee023598f2f16ab07cd4dced768729a39c2a9369

> Coverity ID 94880 (again) - explicit cast to avoid signed implicit cast
> Missed a couple of cases the first time....
> base/aes.c

2016-05-02 08:00:14 +0100
Ken Sharp <ken.sharp@artifex.com>
2d8ddfb13033f53795120eb700e9618e0b15f486

> Coverity ID 125784 - initialise a variable
> base/gdevdbit.c

2016-04-30 10:14:30 +0100
Ken Sharp <ken.sharp@artifex.com>
957f6cdd4376a12e7b037808f8c9326887d32ef3

> Bug #696334 - Don't clean up exec stack after a stackoverflow error
> The problem is that the CET file leaves junk on the operand stack after
> running the colour transform, it also runs three nested loops, 10 steps
> in each loop, for each of the of R, G and B components. This (eventually)
> leads to a stack overflow error.
> This wouldn't normally be a problem, but we then go round and increase
> the stack size, and retry the operation. But, because we had removed the
> execution stack operands, the operator failed, leading to a typecheck
> error.
> We can (and I have) fix this by not popping the elements off the exec
> stack when the error is a stackoverflow. This permits us to properly
> clean up the exec stack for other types of error, and we can hope that
> the stackoverflow is self-correcting. Its not ideal but its the best I
> can think of.
> No differences expected
> psi/zcolor.c

2016-04-29 10:07:10 -0700
Michael Vrhel <michael.vrhel@artifex.com>
b24e0938edf4477a8d318e79a60497fd39e25a57

> Bug 696700: Reduce error messages in release
> base/gsicc.c

2016-04-29 15:49:57 +0100
Ken Sharp <ken.sharp@artifex.com>
71fdcc8a7e15271928587637def7187c1e2ac807

> Coverity ID 94498 - Make size clearer
> There was nothing actually wrong with the previous code, but it took
> the sizeof() a value rather than using the #define for the actual
> number of bits in a color_value, using the #define is clearer
> psi/zdpnext.c

2016-04-29 15:23:41 +0100
Ken Sharp <ken.sharp@artifex.com>
9980daa62eb9909ef5a33935886df24008180c4b

> Coverity ID 94732 - prevent a NULL dereference
> psi/zcontext.c

2016-04-29 14:42:54 +0100
Ken Sharp <ken.sharp@artifex.com>
7b96281dec9a53a56a444ef18f00a8c6611a4395

> Fix bug in Commit 117eac07f12948d4c581335a5587c22815ad18dd
> As was more or less inevitable, I made a mistake in one of these
> Coverity fixes. I believe this resolves the problem
> psi/iutil.c

2016-04-29 11:57:40 +0100
Ken Sharp <ken.sharp@artifex.com>
85ebe6e6ec96e0f24ca057fe6b628bf9d33e61e6

> Coverity ID 94603 - guard against a NULL pointer dereference
> Other cases return error, but ths is a void function....
> psi/zcontext.c

2016-04-29 11:50:11 +0100
Ken Sharp <ken.sharp@artifex.com>
117eac07f12948d4c581335a5587c22815ad18dd

> Coverity ID 95013 - prevent a potential 1 byte buffer overrun
> psi/iutil.c

2016-04-29 11:25:54 +0100
Ken Sharp <ken.sharp@artifex.com>
ab82e27e0941582a879f01e53a6fd7e41dcf8bb2

> Coverity ID 94852 - explicit cast to prevent 32-bit overflow
> base/siscale.c

2016-04-29 11:20:40 +0100
Ken Sharp <ken.sharp@artifex.com>
8ccd0c1a010e78de76e7f84c5659964444de53fe

> Coverity ID 94564 - remove dead code
> I'm practically certain we don't use this code anyway since the adoption
> of FreeType.
> base/gzspotan.c

2016-04-29 11:15:09 +0100
Ken Sharp <ken.sharp@artifex.com>
e2d61987cc597e121ff68b9cdf3a80f82fce03e2

> Coverity ID 95044 - remove dead code
> A 'goto' was unreachable, being preceded by a goto (after macro expansion)
> Replaced with a break just to match the other cases.
> base/gxtype1.c

2016-04-29 11:10:59 +0100
Ken Sharp <ken.sharp@artifex.com>
6df3e33a8445ef53ab5cb5debdf28b2384001284

> Coverity ID 94883 - array overrun
> This appears to be genuinely a potential problem. A triangular line cap
> requires 3 points which, together with the start and end points
> results in a total of 5 points, the array is only 4.
> Extend the array to 5 to ensure that we cannot run off the end.
> base/gxstroke.c

2016-04-29 10:46:07 +0100
Ken Sharp <ken.sharp@artifex.com>
2eeb1cf7951dc0184082adbaf30167eac4dffcf9

> Coverity ID 94664 - make an else clause clearer
> The >0 (actually == 1), < 0 cases were already covered, and terminated
> with a goto, so the only way to get here was if code == 0, so it
> doesn't actually matter if we enclose the 'else' clause in
> parentheses or not, in any event we will execute the 'goto out'.
> But this is clearer.
> base/gxshade6.c

2016-04-29 10:25:46 +0100
Ken Sharp <ken.sharp@artifex.com>
f083229e242b8a0ce4f55935a17ad006502bc5bb

> Coverity ID 94537 - inconsistent use of a variable
> It doesn't actually seem to matter whether we use 'big' or 'big1' here
> but we should be consistent throughout, since they need not be the
> same. Three places use big1 (which is variable, big remains unchanged)
> and one uses big, so I believe that is the incorrect case and have
> changed it accordingly,
> base/gxshade6.c

2016-04-29 09:12:42 +0100
Ken Sharp <ken.sharp@artifex.com>
55bb1e8f7c3ff1bfcf6bea0149f7ce05c2323401

> Coverity IDs 94982, 95068 - extend 2 arrays by 1 to prevent overrun
> I can't quite convince myself that its impossible to overrun these arrays
> and it only costs 8 bytes of heap storage, so lets just extend them.
> base/gxpcopy.c

2016-04-29 09:11:09 +0100
Ken Sharp <ken.sharp@artifex.com>
9bb3550bb02656203e29e6984160cc097757bcb6

> Coverity ID 94547 - don't ignore a return value
> I think its very unlikely this could ever cause a problem, but it is
> theoretically possible.
> base/gxpcopy.c

2016-04-29 08:47:41 +0100
Ken Sharp <ken.sharp@artifex.com>
4b87ec33e0bd4b0383e186e9b4d5d21fe20fa98f

> Coverity IDs 94875, 95076 - explicit cast to avoid integer overflow
> I don't believe this is a real problem.
> base/gxpcmap.c

2016-04-29 08:28:08 +0100
Ken Sharp <ken.sharp@artifex.com>
4080ef1c210020e6c3ba22f5b21b5eb6181cc28e

> Coverity ID 94693 - Fix a return check
> The code looks like it was originally of the form:
> if ((code = .....) < 0)
> and has been changed to return the error code instead, but the
> '< 0' was accidentally left behind.
> base/gxpcmap.c

2016-04-28 17:04:36 +0100
Ken Sharp <ken.sharp@artifex.com>
07c424bda4443ab51442d18fe8502a9610efd070

> Coverity ID 121447 - explicit cast to avoid potential overflow
> base/gxcmap.c

2016-04-28 16:55:05 +0100
Ken Sharp <ken.sharp@artifex.com>
22d1de0456139c2e93e67372f574536794800268

> Coverity ID 94874 - remove pointless code
> There was no point in checking for penum being NULL as we had already
> dereferenced it. I'm certain we should not get here with penum NULL.
> base/gxccache.c

2016-04-28 16:35:11 +0100
Ken Sharp <ken.sharp@artifex.com>
1f324ef9520f49ee03136c8c8a438662d3d1fba0

> Coverity ID 94584 - prevent a potential divide by zero
> This would only be possible with an invalid font, but we've seen plenty
> of those over the years!
> base/gstype2.c

2016-04-28 16:08:52 +0100
Ken Sharp <ken.sharp@artifex.com>
1ba0d89544ba6d057867648027c5a6919888c619

> Coverity ID 94873 - prevent a potential NULL dereference
> I'm almost certain this condition cannot arise, but lets be safe.
> base/gstype1.c

2016-04-28 15:36:07 +0100
Ken Sharp <ken.sharp@artifex.com>
8b5def7074f49c4a231b5b49046af2a510c0fa37

> Coverity ID 121453 - reorder code to check pointer before dereferencing
> base/gsshade.c

2016-04-28 14:33:45 +0100
Ken Sharp <ken.sharp@artifex.com>
60455507951739cc7826c9e0429d1273adf6b87c

> Coverity ID 94900 check and action a return code
> base/gspaint.c

2016-04-28 14:31:33 +0100
Ken Sharp <ken.sharp@artifex.com>
4722eeefcd1f084e335422b53d6b87b5e73efa18

> Coverity ID 94849 - initialise a member of a structure
> I'm certain this doesn't matter, but this should get rid of the warning.
> base/gsovrc.c

2016-04-28 14:26:19 +0100
Ken Sharp <ken.sharp@artifex.com>
4a550a4bdca8dec8cd7907bfc11d9ce454f85dbf

> Coverity ID 94555 - check a return code
> And if we overflowed the buffer, emit the customary 'truncated'
> warning after writing the output.
> base/gsmisc.c

2016-04-28 13:57:26 +0100
Ken Sharp <ken.sharp@artifex.com>
6ab7be0da61c115d95ecead8ba5be99dfb82e777

> Coverity ID 94583 - guarantee prevention of NULL dereference
> I don't think this was actually possible to generate, as p_ctx->profiledir_len
> ought to be 0 if p_ctx->profiledir is NULL.
> But this is safer.
> base/gslibctx.c

2016-04-28 13:47:02 +0100
Ken Sharp <ken.sharp@artifex.com>
6957a9b2daad5256ae91f7416cc62368e0817847

> Coverity ID 94864 - don't dereference a pointer until after NULL check
> base/gsioram.c

2016-04-28 13:43:55 +0100
Ken Sharp <ken.sharp@artifex.com>
e92d375e70f9db4f332135a8dba1d4b5ef5379a0

> Coverity ID 95053 - ensure we do not dereference a potential NULL pointer
> base/gsht.c

2016-04-28 13:23:34 +0100
Ken Sharp <ken.sharp@artifex.com>
29570038d7a5ef3e0e606a8e92680a7a2a159a8d

> Coverity ID 94649 - prevent potential NULL dereference
> base/gsht.c

2016-04-28 12:15:10 +0100
Ken Sharp <ken.sharp@artifex.com>
6911125a371ba43f2014e43d4a3a12516aeebad9

> Coverity IDs 94657, 94867, 94995
> Set some array contents to NULL to ensure we cannot access uninitialised
> data. Ensure an array index cannot be negative (return error if it
> ever is).
> base/gsfunc4.c

2016-04-28 11:53:49 +0100
Ken Sharp <ken.sharp@artifex.com>
2bf6fe4fe5b0e32cc8961843e7f4752f13536208

> Coverity ID 94844 - pay attention to parameter checking
> We checked the parameters for validity, but ignored the result !
> base/gsfunc3.c

2016-04-28 11:42:05 +0100
Ken Sharp <ken.sharp@artifex.com>
a51b3d81caf2936ad017236b6099bc97acf5584a

> Coverity ID 121451 - explicit cast to avoid potential overflow
> base/gdevmr2n.c

2016-04-28 11:33:04 +0100
Ken Sharp <ken.sharp@artifex.com>
ba0d94c3f1628f1f36358e7ff513d699bf5aa87c

> Coverity ID 94662 - ensure argument is not NULL
> gx_make_rop_texture_device checked 'target' to see if it is NULL, but
> then later dereferenced target without checking. It 'looks like' this
> is a condition which can't happen, because we would get a seg fault.
> In fact it is only called from one place, and that location
> (gx_image_enum_begin) can return an error, so I've chosen to ensure
> that the argument cannot be NULL before calling gx_make_rop_texture_device
> base/gdevrops.c
> base/gxipixel.c

2016-04-28 10:23:31 +0100
Ken Sharp <ken.sharp@artifex.com>
a1625fe7efe8da391f77932f866504ee75b936ac

> Coverity ID 94796 - guard against (throw an error) possible NULL dereference
> base/gdevprn.c

2016-04-27 16:42:18 +0100
Ken Sharp <ken.sharp@artifex.com>
d9cc10861f21fe7c5dde8836a09028d9ad8b8d97

> Coverity ID 94705 - prevent a NULL pointer dereference
> gs_cie_jc_complete dereferences pis->cie_render.
> base/gsciemap.c

2016-04-27 15:27:35 +0100
Ken Sharp <ken.sharp@artifex.com>
405236003e7a0cc472f46fda556f011d58cc2ca9

> Coverity ID 121450 - explicit cast to 64-bit type, avoids faulty implicit 32-bit cast
> base/gsbitops.c

2016-04-27 15:04:26 +0100
Ken Sharp <ken.sharp@artifex.com>
1446fbba1351efc867f9dedcc96c27e8be0c4f06

> Coverity ID 94825 - initialise struct members so copying doesn't give a warning
> base/gsalphac.c

2016-04-27 14:35:15 +0100
Ken Sharp <ken.sharp@artifex.com>
b04a8f07705611a731629ca328f117b12e617776

> Coverity ID 125641 - remove a harmless line of dead code
> base/gsalloc.c

2016-04-27 14:26:44 +0100
Ken Sharp <ken.sharp@artifex.com>
dab434b2058d77088c6f495904602b30539effd1

> Coverity ID 121452 - resource leak
> free 'filekey' if we successfully allocated it, and then later aborted.
> base/gp_unix_cache.c

2016-04-27 10:09:20 +0100
Caolán McNamara <caolanm@redhat.com>
abeee8de532a512aeb5e4b0c3f7b11abcea30b72

> Resolves: gs#696735 valgrind bits_bounding_box uninitialized values
> base/gxfapi.c

2016-04-26 11:07:14 +0100
Chris Liddell <chris.liddell@artifex.com>
934af9c2ac583542d7a167cda75b83e79adc6c7e

> Coverity IDs: 36550, 94906, 94907, 95028, 95064
> 36550: handle errors from file operations.
> 94906, 94907, 95028, 95064: ensure we don't overflow string buffers.
> base/genconf.c

2016-04-26 11:05:43 +0100
Chris Liddell <chris.liddell@artifex.com>
0efb1a2a5b49dab22afb2cb9985f6fb155f1db29

> cppcheck: uninitialized variable in gsmd5.c
> In practice, porbably can't happen - simple initialization should resolve the
> warning
> base/gsmd5.c

2016-04-26 11:04:44 +0100
Chris Liddell <chris.liddell@artifex.com>
1de3af7338592b108fa01dfed496df3092ed1fa9

> Address some error handling issues in mkromfs.c
> cppcheck reported some potential resource leaks in error conditions.
> base/mkromfs.c

2016-04-26 09:05:49 +0100
Chris Liddell <chris.liddell@artifex.com>
94c93f7841ad4b90522756acc7ed0083475cd74a

> Change allocator initialization.
> cppcheck reckoned the pointer to the memory allocator (cmem) could possibly be
> a NULL pointer dereference (in fact, that's not true).
> But a simple tweak to how cmem is initialized can prevent the error arising.
> base/fapi_ft.c
> base/fapiufst.c

2016-04-27 10:23:10 +0100
Ken Sharp <ken.sharp@artifex.com>
33b190011e6aa70b7ab2049842a10b090544c2d1

> Coverity ID 94842 - initialise some variables
> Worst case (I think) would have resulted in indeterminate, incorrect,
> rendering, so not a huge issue but fixed just in case.
> base/gdevmpla.c

2016-04-27 10:02:22 +0100
Ken Sharp <ken.sharp@artifex.com>
1497b768ef1463a952f981a97b66900138268005

> Coverity ID 94578 - avoid dereferencing a pointer if its NULL
> The variable 'textures' was checked for being NULL before assigning
> traster from it, but we then later used textures without checking it.
> I did consider adding a similar check to the original one here, at the
> point flagged by Coverity, but the loop would then have proceeded to
> use a NULL pointer as an array, leading to further problems.
> I suspect that textures cannot (or at least should not) be NULL, and
> none of our test files exercise ths case. So I've chosen to simply
> return if it ever is.
> base/gdevmpla.c

2016-04-27 09:36:30 +0100
Ken Sharp <ken.sharp@artifex.com>
fbeade5f65fe17607df5da0b20ab562c2e68dc01

> Coverity ID 94508 - check and action a return code
> base/gdevmem.c

2016-04-27 09:10:12 +0100
Ken Sharp <ken.sharp@artifex.com>
5655e62da7ad0a4c6368994a11cdb9954d1fa296

> Coverity ID 121436 - guard against a NULL dereference
> textures is checked for NULL in the procedure initialisation, so it
> seems it may be possible for it to be NULL. Make sure we don't try to
> dereference it if so.
> base/gdevdrop.c

2016-04-27 08:34:14 +0100
Ken Sharp <ken.sharp@artifex.com>
fa1757fe4317171cd45755d0b66111ebf12be920

> Coverity ID 94765 guard against invalid array index
> We checked to ensure that no more than 1 plane was requested, but we
> didn't check to ensure that at least 1 plane *was* selected.
> base/gdevdgbr.c

2016-04-26 10:22:56 -0700
Michael Vrhel <michael.vrhel@artifex.com>
da2d4893743831b9739eaa3f7f4373e011a39e36

> Coverity ID 94879 and 94963 Performance inefficiency
> Pass pointer to landscape information instead of structure when
> applying threshold.
> base/gxht_thresh.c
> base/gxht_thresh.h

2016-04-25 15:45:41 -0700
Ray Johnston <ray.johnston@artifex.com>
341a0b9a1268cb246c1e0cc12d684a59b39cf876

> Fix nocm (-dUseFastColor) allocation when using NumRenderingThreads>0
> Rendering threads use a chunk_memory allocator that is, by nature, not
> GC'ed so its non_gc_memory points to itself, but the icc_cache_cl of the
> (and the icc_cache_list[]) link caches use thread_safe_memory (the heap
> allocator) so when the thread exits, we have "leaked" nocm elements from
> the chunk allocator (seen with a DEBUG build) and end up with stale pointers
> in the link_cache that cause SEGV when the link cache's contents are removed.
> Problem seen with:
> -dNOCIE -dUseFastColor -dNumRenderingThreads=1 -dMaxBitmap=0 j9_acrobat.pdf
> base/gsicc_cache.c
> base/gsicc_nocm.c

2016-04-26 15:39:02 +0100
Chris Liddell <chris.liddell@artifex.com>
979d208cb52fb7fda65d742aa09311067c60aba6

> Bug 696733: Make sure we have an open file before writing to it
> The lj3100sw writes the last data to the output file on closing, but if there
> have been no pages written, there is no open output file.
> On close, check we have an open (non-NULL) output file before attempting to
> write the final data.
> devices/gdevl31s.c

2016-04-26 15:40:41 +0100
Ken Sharp <ken.sharp@artifex.com>
10da8a2209c066b9060e2de0c2641a977266d115

> Typo in commit 7f42fb28229370fa9829c56c42e203ba3da5c1d2
> I put the parenthesis in the wrong place and missed the failure to
> compile due to the cluster being very busy
> base/gdevdbit.c

2016-04-26 15:15:15 +0100
Ken Sharp <ken.sharp@artifex.com>
e1c3a86d9d9845c717bd09b65b219b2add238ac8

> coverity ID 104077 - pass a large data structure as a pointer
> base/gdevdevn.c
> base/gdevdevn.h
> devices/gdevgprf.c
> devices/gdevtsep.c

2016-04-26 15:14:12 +0100
Ken Sharp <ken.sharp@artifex.com>
7f42fb28229370fa9829c56c42e203ba3da5c1d2

> silence compiler warning, make sure variable is initialised
> base/gdevdbit.c

2016-04-26 14:38:08 +0100
Ken Sharp <ken.sharp@artifex.com>
24065aee02fd942cd81ff373514489e9e6177491

> Coverity IDs 94687 & 94762 - prevent NULL dereference
> Don't attempt to set pequiv_colors data, if the pointer is NULL
> base/gdevdevn.c

2016-04-26 14:15:37 +0100
Ken Sharp <ken.sharp@artifex.com>
5649f1d05a3dbdd7dfc969b0b7b05328bde07629

> Coverity ID 94589 and 94687 - prevent a NULL dereference
> The code contained a poorly named macro (copy_tile) which executed
> a device method without testing to see if it was NULL. We know from
> prior work that the original intention was that device methods should
> *never* be NULL, but we also know that some devices do have NULL methods
> and indeed this very routine sets some NULL methods.
> So to be safe we now check the method before executing it. At the same
> time I've renamed the macro, using upper case so we have some chance of
> seeing its a macro, and prevents the macro name collisions with the
> code in gdevwddb.c and gdevwprn.c.
> I also rewrote it to use if....else instead of ? : because it was
> practically unreadable before.
> Removed the (pointless) 'return_if_interrupt' macro.
> Finally, added the do..while(0) construction around the macro body.
> base/gdevdbit.c

2016-04-26 13:15:24 +0100
Ken Sharp <ken.sharp@artifex.com>
fc2e6a0517d4ecc7a486647da8bfaa9e1ab9e03e

> Coverity ID 121448 - change the order of casting
> Change the cast position to avoid implicit type promotion, and consequent
> potential integer overflow.
> I don't believe this is really a problem, but the explicit early casting
> prevents any problems and makes no differences otherwise.
> base/gdevabuf.c

2016-04-26 11:56:42 +0100
Ken Sharp <ken.sharp@artifex.com>
e79881cba48fcbfa84d09a4c0f78cfaaf53347d9

> Coverity IDs 94851, 94872, 94880, 94884, 94885, 94918, 94939, 95050, 95061
> I *think* that casting the intermediate result to an unsigned int should
> prevent the implicit cast to a signed int, which will prevent the
> sign extension which Coverity is warning about.
> I'll check after the next Coverity submission and rework this if it
> should turn out to be insufficient.
> base/aes.c

2016-04-25 16:32:00 -0600
Henry Stiles <henry.stiles@artifex.com>
bc5657a8613d078d5774a5453d47fa9c5f410f54

> Bug 696675 - UI message in output file.
> Update this file to be a bit more in sync with its analog in gs
> dwmain.c. Hopefully by redirecting output to stderr we will avoid the
> issue reported in the bug where error messages were being directed to
> output files. I was unable to reproduce it locally with Windows 10 once
> the changes were applied.
> pcl/pl/plwmainc.c

2016-04-24 15:01:32 -0700
Michael Vrhel <michael.vrhel@artifex.com>
86f15f469c2015a6f2c85593eab08c3625a24df2

> Coverity ID 95017 Null dereference possible
> Check for device NULL and if it is return NULL for link
> in the replacement color code.
> base/gsicc_replacecm.c

2016-04-24 14:58:27 -0700
Michael Vrhel <michael.vrhel@artifex.com>
2761b30ed29f3e6b87ebe739fbb289d5c345db44

> Coverity ID 94960: Dereference before NULL check.
> It has already been checked if pis was NULL on
> all the paths leading to this, so remove the check here.
> base/gsicc_nocm.c

2016-04-24 14:55:06 -0700
Michael Vrhel <michael.vrhel@artifex.com>
c09d5f52594f04966d93c7001fec49707970e6bf

> Coverity ID 94714: Possible Null Dereference
> If device is NULL in the no_cm color management return NULL for the link.
> The device is required for this transform.
> base/gsicc_nocm.c

2016-04-24 14:49:09 -0700
Michael Vrhel <michael.vrhel@artifex.com>
142ebba4e98047b0ebd1acce28911b042c19f899

> Coverity ID 125642 Possible dereference NULL issue
> Make sure we do the testing correct to avoid any
> possible dereference of NULL.
> base/gsicc_cache.c

2016-04-24 14:36:48 -0700
Michael Vrhel <michael.vrhel@artifex.com>
d683717565b3e09ff6bcacbc1fec50352cd08507

> Coverity ID 94673 Dead code removal
> base/gsicc_cache.c

2016-04-23 12:37:23 -0700
Ray Johnston <ray.johnston@artifex.com>
4d417ff8cbfe7b6a04a15bc9f898e77ab2ffd737

> Change PS interpreter allocator chunks to clumps.
> We are in the confusing position of having the PS interpreter
> allocator that allocates in chunks, along with a chunked allocator.
> To avoid this confusing clash of terminology, we do some
> global renames to change the standard allocator to allocate
> in 'clumps' instead.
> base/gdbflags.h
> base/gdevprna.c
> base/gxobj.h
> psi/ialloc.c
> psi/igcref.c
> psi/imain.c
> psi/imainarg.c
> psi/iminst.h
> psi/inameidx.h
> psi/interp.c

2016-04-25 17:09:50 +0100
Ken Sharp <ken.sharp@artifex.com>
d1cc9c37f2b437244235222832989b4f0fb42ae4

> pdfwrite - continue writing fonts even after one fails
> File Bug693711.pdf has a number of broken fonts which we cannot write
> out (Acrobat throws an error on these pages in the original PDF file).
> Previously when we encountered an error writing a font we would stop
> writing fonts, even the ones which were valid.
> Here we store the error (we don't want to forget there was one, so we
> can report it at the end) but carry on emitting the PDF file. This
> does a better job of emitting a file from broken input.
> devices/vector/gdevpdtw.c

2016-04-25 09:21:24 -0600
Henry Stiles <henry.stiles@artifex.com>
dca281c3d8011a2afe3caadc23009fe38d8df839

> Bug 696314, Add PJL to staple documents.
> Staple setting for the PXL devices courtesy of Hin-Tak Leung.
> devices/gdevlj56.c
> devices/gdevpxut.c
> devices/gdevpxut.h
> devices/vector/gdevpx.c

2016-04-25 15:12:45 +0100
Ken Sharp <ken.sharp@artifex.com>
22e08ac60e5363282631b596e996c0d0ad806484

> pdfwrite - clear/delete extra temp files when run with %d in OutputFile
> Bug #696727 "Regression: pdfwrite leaves temp files"
> For some reason this does not exhibit on Windows, I have no idea why.
> This commit adds a call to the function that closes and removes
> pdfwrite's temporary files if we exit due to a '%d' in OutputFile in
> order to prevent a spurious extra file being output.
> For me this fixes the problem on Linux.
> devices/vector/gdevpdf.c

2016-04-25 13:20:35 +0100
Chris Liddell <chris.liddell@artifex.com>
efe7fd03e0ca45aac5ee4610ed9a23b7ea712e0d

> Bug 696730: print meaningful error when device shutdown fails
> When we explicitly close the default device, previously we just printed the
> error code, and a reference to gserrors.h - this finds the error code in the
> Postscript world, and prints the Postcript error string instead.
> psi/imain.c

2016-04-25 10:17:48 +0100
Chris Liddell <chris.liddell@artifex.com>
17b6456984a0676a8cf271ff7abc29fdd5ff10a5

> Coverity IDs 95065, 121457: tidy up error conditions
> base/fapi_ft.c

2016-04-25 09:54:26 +0100
Chris Liddell <chris.liddell@artifex.com>
43e5273d8ce5e8c7ec02da874129fd2bea26301e

> Coverity IDs 94494, 94617, 94818, 95043
> 94494: increase size of string buffer to allow for NULL termination.
> 94617: Initialize string pointer to avoid NULL dereference.
> 94818: Initialize string variable (fmode).
> 95043: Swtich to strncpy() to ensure we don't overflow string buffer
> base/echogs.c

2016-04-25 10:34:07 +0100
Robin Watts <robin.watts@artifex.com>
3787c3f9753c542a5bd3f040b2aaa73db2f2f527

> Fix clump splay tree backward in-order traversal.
> When walking backwards, we stop for 'in-order' operation when
> stepping from the right, not the left.
> Also, backward walking requires different initialisation from
> forward walking.
> Add some debug code to dump a clump tree, and fix a prototype.
> base/gsalloc.c
> base/gsalloc.h
> base/gxalloc.h
> psi/isave.c

2016-04-25 09:22:00 +0100
Ken Sharp <ken.sharp@artifex.com>
99c712e4b10b459d2eab687d0f4db481999aad96

> Coverity ID 101841, change order of code so that NULL check comes before dereference
> base/gdevp14.c

2016-04-25 09:17:18 +0100
Ken Sharp <ken.sharp@artifex.com>
3cd70f69f9054fdb9da2c18d4d1bdbbd5cd752ad

> add parentheses to make the control flow obvious, as requested by owner.
> psi/ialloc.c

2016-04-25 09:01:58 +0100
Ken Sharp <ken.sharp@artifex.com>
74fd7f6bbe5e2aa493ef9bd087ab64adbabe71bc

> Coverity ID 94725 - correct misleading indenting
> psi/ialloc.c

2016-04-25 08:45:13 +0100
Ken Sharp <ken.sharp@artifex.com>
a3d988b75d952367ed898d0e1ac2af79add49296

> Coverity ID 94530 check and action a return code
> devices/vector/gdevpdfm.c

2016-04-25 08:25:03 +0100
Ken Sharp <ken.sharp@artifex.com>
83353631064ac5307a9b62877d5a0664e7ac800e

> Coverity ID 125639 - clamp page numbers to 0
> The PageList is supposed to be page numbers 1 onwards. Putting a zero
> in the list would potentially have caused the numbers to 'wrap' resulting
> in no output.
> base/gdevflp.c

2016-04-23 10:59:46 +0100
Ken Sharp <ken.sharp@artifex.com>
88a145bebee34481862ea79d09098eb71dd15e38

> Coverity ID 94810 - properly bracket macro
> gx_setcurrentpoint is a macro, with 2 lines of code. This meant the else
> clause was only applied to the first line, and the second was always
> processed.
> Fortuitously the if clause would have invalidated the current point so
> I believe this is always safe, but its best to be certain and not
> corrupt the current point.
> base/gspaint.c

2016-04-22 14:51:02 -0700
Michael Vrhel <michael.vrhel@artifex.com>
2f622fe34c6290e737216dbc85d93efcdd3895fd

> Coverity ID 94776 Dereference after null check
> This should not have been an issue since the only
> case where we called with a NULL device we have a profile,
> but we will add the check for safety.
> base/gsicc_cache.c

2016-04-22 11:55:57 -0700
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
644914cb5cef5b6138cb5f2a2ac541ea2333edc1

> Bug 696726: gdevcmykog.c - insure that temp files are deleted
> Call gp_open_scratch_file_rm() instead of gp_open_scratch_file() to insure
> that no temp files are left around if Ghostscript is killed or crashes.
> devices/gdevcmykog.c

2016-04-22 11:36:24 -0700
Michael Vrhel <michael.vrhel@artifex.com>
263b9e169ec5cf09c4b671ef9ea58f3e0edbe994

> Coverity ID 94766: Self assignment (no effect)
> Remove spurious code.
> base/gxcmap.c

2016-04-22 11:25:56 -0700
Michael Vrhel <michael.vrhel@artifex.com>
ae840462e761fbb798e0a3f9ca822a69b252220d

> Coverity ID 94882 and 95018: Uninitialized variables
> If someone sets the number of inputs to an out of range
> value in the transform, we will return 0 for our output
> in the no_cm and replace_cm color management work flow.
> base/gsicc_nocm.c
> base/gsicc_replacecm.c

2016-04-22 10:55:18 -0700
Michael Vrhel <michael.vrhel@artifex.com>
6026f85a1a30738a8f453d9d3bbd8a785aff1d1b

> Coverity ID: 94515, 94513, 94528 copy-paste errors
> Output buffer was using input plane stride.
> base/gsicc_monitorcm.c
> base/gsicc_nocm.c
> base/gsicc_replacecm.c

2016-04-22 10:44:59 -0700
Michael Vrhel <michael.vrhel@artifex.com>
199d49a64706673643671bbb74c19a91809f7e38

> Coverity ID 94935 Out-of-bounds read
> Mistake when we are resetting the proof or the device link
> profile. We would have ended up overrunning the profile
> array that is used for the default/text/graphic/image array.
> base/gsicc_manage.c

2016-04-22 10:30:18 -0700
Michael Vrhel <michael.vrhel@artifex.com>
55d58a84767b82fe9f81b7b2357e1feafa06f017

> Coverity ID 94570, 94785, 94915 Missing break in switch
> The CIEXYZ case can't occur so it has been removed. It
> was a vestige from the early days of the ICC development.
> The CIEXYZ case was missing a break statement, which led to three
> coverity complaints.
> base/gscms.h
> base/gsicc_manage.c

2016-04-22 18:22:30 +0100
Robin Watts <robin.watts@artifex.com>
15ee3fb57b660a796f8ac40c8784cfb165405336

> Change standard allocator chunks to clumps.
> We are in the confusing position of having a standard
> allocator that allocates in chunks, along with a chunked
> allocator.
> To avoid this confusing clash of terminology, we do some
> global renames to change the standard allocator to allocate
> in 'clumps' instead.
> base/gdbflags.h
> base/gsalloc.c
> base/gxalloc.h
> base/gxobj.h
> doc/Develop.htm
> doc/Use.htm
> psi/ialloc.c
> psi/igc.c
> psi/igc.h
> psi/igcstr.c
> psi/igcstr.h
> psi/ilocate.c
> psi/ireclaim.c
> psi/isave.c
> psi/zcontext.c

2016-04-22 09:56:04 -0700
Michael Vrhel <michael.vrhel@artifex.com>
e749f3d65d203edbc7c140ec8fd76b66805d27ff

> Coverity ID 94910 Uninitialized pointer read
> Set indices to avoid use of uninitialized index. It is actually not
> possible to access them using real data but someone could perhaps
> be malicious and cause a problem
> base/gsicc_cache.c

2016-04-22 13:11:31 +0100
Robin Watts <robin.watts@artifex.com>
7b0baf9dc683b3ed6ac27b7a8f89718220589f7c

> Rework gsalloc chunk list to use splay trees.
> Instead of using a simple linked list (that can result in
> slow searching in pathological cases), change to a splay tree
> structure.
> base/gsalloc.c
> base/gxalloc.h
> psi/ialloc.c
> psi/igc.c
> psi/ilocate.c
> psi/isave.c

2016-04-22 09:24:52 -0700
Michael Vrhel <michael.vrhel@artifex.com>
dd683d444dba28a6bb4701be065353e4f5344de0

> Coverity ID 94568 Dereference after null check
> The device profile is not even used in this function.
> Likely left over by mistake. Dereference of NULL no
> longer possible here.
> base/gsicc.c

2016-04-22 09:07:12 -0700
Michael Vrhel <michael.vrhel@artifex.com>
dd34f9f634b2d179bb898138255bb20c3de8c76f

> Coverity ID 95055 Uninitialized scalar variable
> If we have an invalid color space (non-CIE) we should
> not be in this part of the code. Throw an error in
> this case (the default in the switch) which will make
> us avoid the uninitialized access.
> base/gsicc_create.c

2016-04-22 13:59:03 +0100
Ken Sharp <ken.sharp@artifex.com>
e821df35998b594b844edf3e554d5a8002a6311d

> Coverity ID 94783 - prevent a NULL dereference
> If the device doesn't have a 'color_usage_array' then trying to use it
> will be fatal. There is a check for the array being NULL, but it was
> empty!
> As a work-around, if it is NULL then return -1 which looks like its a
> 'do nothing' value.
> base/gdevprn.c

2016-04-22 13:28:42 +0100
Ken Sharp <ken.sharp@artifex.com>
b49a4b5142dba407e63e2b8907efce3d38202ac4

> Coverity ID 94751 - error in return check
> Looks like this was a "if ((code= ...) < 0)" converted into "code=.. if
> (code < 0)" but mistakenly.
> psi/zpcolor.c

2016-04-22 13:17:35 +0100
Ken Sharp <ken.sharp@artifex.com>
3204fa03a809db3d8ff26d629012096ff1aecef6

> Coverity ID 94977 - check and action 2 return codes
> psi/zicc.c

2016-04-22 12:59:42 +0100
Ken Sharp <ken.sharp@artifex.com>
bffaddf2c2c1d3f0a52e205cf33c9023a779ace7

> Coverity ID 94543 check a return code
> This does actually lead to a memory leak, but there is equivalent code
> below (allocating prci) which potentially leaks in exactly the same
> way, so I'm going to ignore the leak. A real VM error will quickly
> cause the interpreter to exit anyway.
> psi/zgstate.c

2016-04-22 11:54:44 +0100
Ken Sharp <ken.sharp@artifex.com>
caf54da6fe8635a17f069e947ff87d0b6c37a592

> Coverity ID 94789 - missing parentheses could cause error
> This appears to be a genuine bug, even if the parameters were valid
> we would jump to the failure condition. Seems we do not have a test
> case for this code path.
> psi/zfsample.c

2016-04-22 11:36:13 +0100
Ken Sharp <ken.sharp@artifex.com>
58db0de140dc12170d4fb4b33d32a90f5d57f0e2

> Coverity ID 94947 - initialise an unused paramter
> delta is only used for Dissolve blend modes, so I'm pretty certain this
> is really a false positive, but it does no harm to initialise it to 0.
> psi/zdpnext.c

2016-04-22 11:27:52 +0100
Ken Sharp <ken.sharp@artifex.com>
56315a80d2bd49d3d9baa71ea3be8b1dba64adcd

> Coverity ID 95062 - check and action a return code
> Almost certainly impossible to trigger, the only way to get an error
> here would be for the ref pointed to by arr to not be an array, which
> should have been checked earlier, All the same, lets check the return
> code.
> psi/zcolor.c

2016-04-22 10:57:14 +0100
Ken Sharp <ken.sharp@artifex.com>
5bfdb858ea41d0018acc3c022e885fc6b4a1ccfc

> fix Coverity ID 94865 - free some memory on exit
> This is minor, as the memory leak only occurs on a fatal error and
> application exit.
> psi/imain.c

2016-04-22 10:23:45 +0100
Ken Sharp <ken.sharp@artifex.com>
5ee4779b097da19ef0b50cd4c04d0f7f6da46da4

> Coverity ID 94725 - purely cosmetic indenting
> psi/ialloc.c

2016-04-22 10:16:55 +0100
Ken Sharp <ken.sharp@artifex.com>
8d6c1c1396d3678afd37f8492be7e31aed405c59

> Coverity ID 94927 - initialise a string buffer
> Set the buffer contents to all 0, prevents possibility of using
> uninitialised data and makes a 'buf[] = 0' redundant.
> psi/dscparse.c

2016-04-22 09:48:23 +0100
Ken Sharp <ken.sharp@artifex.com>
2a5d6cd40a49c89efdb83c6f4399ec7ad8692218

> txtwrite - Coverity fix, Adobe glyph list lookup not working
> Coverity ID 94593
> The code to search the Adobe Glyph List in an attempt to find a Unicode
> value for a named glyph was incorrect, and simply didn't work. Because
> 'index' started at -1, and all the searches started by testing if
> 'index >= 0', all the table searches were skipped.
> This should actually run the searches and may improve the text extraction
> a little.
> devices/vector/gdevtxtw.c

2016-04-21 18:04:55 -0700
Michael Vrhel <michael.vrhel@artifex.com>
42bca0e60954adc27d78998905e0daab97136be2

> Fix for Bug 696724
> This issue was caused by the interaction of the AA alpha and the fact
> that we have a knock out group. In such a case, we don't want the
> AA alpha to be knocking out what was already drawn. Instead we want
> to do a blend with the AA alpha and then force the alpha to what ever
> the alpha is in the graphic state. This is achieved by looking at
> what is already drawn in our destination and if there is nothing there,
> then we just copy. If there is something there, then we blend and
> then set the alpha value appropriately.
> base/gdevp14.c
> base/gxblend.c
> base/gxblend.h

2016-04-21 16:26:27 +0100
Ken Sharp <ken.sharp@artifex.com>
fa3dbd3a9fa9ddb2894ef80738d95c3c1b6a92a6

> Coverity fix - CID 94748 and 94805 potentail NULL dereference
> In both these cases we check dev for NULL and then either dereference dev
> or dereference a pointer set to NULL if dev is NULL.
> Simply guard against that. I don't believe this should be possible
> in any event, I don't think the graphics state should *ever* have no
> device.
> base/gscspace.c

2016-04-21 15:43:06 +0100
Ken Sharp <ken.sharp@artifex.com>
e9d0f658f01ca857f18c9e038adbdad899979f25

> Coverity fix - CID 95051, initialise a variable
> base/gdevvec.c

2016-04-20 09:22:16 +0100
Chris Liddell <chris.liddell@artifex.com>
3f8b170b6a7ab90cb64814502c0cde317f9fd4ae

> Remove some defunct references to old wisc site.
> doc/API.htm
> doc/Release.htm

2016-04-19 12:05:58 -0700
Ray Johnston <ray.johnston@artifex.com>
43a88f4e6377fa6d4ea0a609450ddb19ee0474cb

> Add max_used to gs_memory_status and use it for -Z: resource usage
> By adding this to the gs_memory_status_t and returning it (if available)
> from the gs_memory_status function of allocators, we can print the max
> used even when it is not a DEBUG build and avoid the ugly gs_debug
> hack previously used to print the max_used for a DEBUG build. The
> time for tracking this is microscopic. Also the chunk_mem allocator
> now tracks this always, not just for DEBUG builds.
> base/gsalloc.c
> base/gsmalloc.c
> base/gsmalloc.h
> base/gsmchunk.c
> base/gsmemory.h
> base/gsmemraw.h
> psi/imain.c

2016-04-19 15:56:09 +0100
Chris Liddell <chris.liddell@artifex.com>
4976a1a4a0b44cd44467e6fe2ba5d453e7573434

> Bug 696716: cff parser: cope with incomplete encoded numbers
> The fonts in the test case had an incomplete 32 bit number at the end of the
> stream - meaning it threw an error trying to read 4 bytes when only 1 byte
> was available.
> Update the code to read *up to* 4 bytes in these cases.
> The fonts are still invalid because they leave a dirty operand stack, but the
> cff parser ignores such problems.
> Also quieten an uninitialised variable warning.
> psi/zfont2.c

2016-04-19 16:02:36 +0100
Ken Sharp <ken.sharp@artifex.com>
a1e2d8b247955e65a7e1ed26e3b8163a58fa6ca7

> page processing - remove a spurious line of code
> Spotted by scan-build, this line of code did no harm, but served no
> useful purpose either, since its return value wasn't tested.
> base/gdevflp.c

2016-04-19 15:03:26 +0100
Ken Sharp <ken.sharp@artifex.com>
3376c638a5d5cad500c48862ace55b8e1eafc458

> txtwrite action a return code
> From Coverity ID 94593
> devices/vector/gdevtxtw.c

2016-04-19 14:27:54 +0100
Ken Sharp <ken.sharp@artifex.com>
e9e077eff06e8fb4141885d9225f212920af431c

> pdfwrite - remove some dead code in the ICC handling: Coverity analysis
> devices/vector/gdevpdfk.c

2016-04-19 11:18:40 +0100
Ken Sharp <ken.sharp@artifex.com>
69c20a21a5bd53284437029b5b9d316a408a7392

> Add a system to allow processing of individual pages and ranges of pages
> Bug #692752 "Implement mechanism to specify a range (or ranges) of pages for txtwrite"
> Documented in Use.htm, this introduces a new command line parameter
> 'PageList' which allows for ranges and individual pages to be specified
> for processing.
> Resource/Init/pdf_main.ps
> base/gdevdflt.c
> base/gdevflp.c
> base/gdevflp.h
> base/gdevkrnlsclass.c
> base/gsdevice.c
> base/gsdparam.c
> base/gxdevcli.h
> base/gxdevice.h
> devices/gdevbit.c
> doc/Use.htm

2016-04-18 17:06:58 +0100
Robin Watts <robin.watts@artifex.com>
e6ecf9ccab71740fddc70f2e6cb30bef3b831d61

> On windows, in profile builds, disable DLL build.
> This enables Very Sleepy to reliably find symbols for me.
> psi/msvc.mak

2016-04-18 15:31:53 +0100
Robin Watts <robin.watts@artifex.com>
7c0e498f47b97a3086fdb4297de600b0ef66d584

> BBox device: speed up.
> When taking the bbox of a stroked path, don't stroke the entire
> path to a new path, and then take the bbox of that. Instead
> allow the stroke code to call the underlying bbox code for each
> path segment directly.
> On files with HUGE paths this can save a lot of mallocs/frees.
> base/gdevbbox.c

2016-04-18 15:17:06 +0100
Robin Watts <robin.watts@artifex.com>
952ac2015ef8e1e1d3fe84224e99e6b98bc84f05

> Remove unneeded padding byte.
> This made sense until 2002 when another byte was added. Since then
> it's been bloat.
> base/gzpath.h

2015-07-18 09:35:37 +0100
Robin Watts <Robin.Watts@artifex.com>
e350758ceb8d9f7ec6bb209908a6ce1fe35e2397

> Makefile for Android MuPDF libgs.so
> make -f Makefile.android so
> Makefile.android
> arch/android.h

2016-04-16 10:34:58 +0100
Ken Sharp <ken.sharp@artifex.com>
e1e13aa4492918ff0dec6062faab351ba9ae6ac0

> pdfwrite - when fill->bitmap conversion degenerates to empty, just drop it
> Bug #696705 "crash in pdfwrite"
> This is caused by a combination of a low resolution and converting
> colours into RGB, when a shading uses Separation colour spaces.
> The code renders the shading as a bitmap, but the path to fill is empty
> triggering the use of the mask instead of the path. However, because
> we are a shading not a masked image, there is no mask.
> Instead we now simply drop the shading.
> No differences expected
> devices/vector/gdevpdfd.c

2016-04-14 10:00:57 +0100
Ken Sharp <ken.sharp@artifex.com>
df5b3426d31f79c13a735dff9118e9798ce97af9

> PDF Interpreter - try to work around invalid ICCBased spaces
> Bug #696690 and Bug #696120
> These files have ICCBased spaces where the value of /N and the number of
> components in the profile differ. In addition the profile in Bug #696690
> is invalid. In the case of Bug #696690 the /N value is correct, and the
> profile is wrong, in the case of Bug #696120 the /N value is incorrect
> and the profile is correct.
> We 'suspect' that Acrobat uses the fact that Bug #696120 is a pure image
> to detect that the /N is incorrect, we can't be sure whether it uses the
> profile or just uses the /N to decide on a device space.
> What we now do is; If the /N and device profile number of components
> don't match, we assume the device profile is correct and patch /N to be
> the same as the profile (see /ICCBased-resolve), but we save the
> original value of /N in /OrigN. In the PostScript setcolor operator, if
> the space is a genuine ICCBased space (not a replacement for a device
> space) we call set_dev_color which will actually exercise the profile.
> If that fails we return an error. For ICCbased spaces we run setcolor in
> a stopped context, and if it fails we check to see if there is a /OrigN
> (this occurs only if the /N was different to the number of components in
> the profile). If there is a /OrigN then prefer that to the profile,
> otherwise they agreed, so just use /N and select a device space. If we
> can't select a device space with the correct number of components, give
> up and throw an error.
> This produces some differences in a small number of files, mostly the
> PAM device at 72 dpi. These are not visually perceptible, and since they
> only occur on one device at low resolution I think they are spurious.
> Resource/Init/pdf_draw.ps
> Resource/Init/pdf_main.ps
> Resource/Init/pdf_ops.ps
> psi/zcolor.c

2016-04-11 14:28:47 +0100
Ken Sharp <ken.sharp@artifex.com>
87665c0a73e3d53f791017813424d6f3ba5f85c7

> txtwrite - reinstate an earlier commit by Robin Watts
> This was removed as I couldn't, at the time, be certain that it was not
> required. Having spent some time working through the various macros, and
> the code, I'm now convinced that this is not required, and is probably
> a remnant of an early attempt at this device, which used garbage collected
> objects.
> This was originally added by Robin as a small part of commit
> fd9a66f997bb57e9628a703774eddcf933475a34 and removed by me in commit
> 15b3f5cbf12461e2ed318e793669b7c34e32089b
> No differences expected
> devices/vector/gdevtxtw.c

2016-04-11 13:32:06 +0100
Ken Sharp <ken.sharp@artifex.com>
faa3f93a3f7f2da9c53501fc5780999ba14cb1e3

> pdfwrite - remove some deleted code accidentally left with #if
> devices/vector/gdevpdfp.c

2016-04-11 10:06:29 +0100
Ken Sharp <ken.sharp@artifex.com>
416aa779312c296dfbecd87e6ba88ea57284a337

> pdfwrite - Remove the 'old' (non-ICC) colour management code
> Removal of this code has been warned for some time, since there have
> been practically no reports of problems, and those few have been
> fixed, I'm now removing the old and deprecated colour conversion
> code.
> We also now process, but ignore, changes to ProcessColorModel. If you
> want output in a specific colour space, then use ColorConversionStrategy
> to select the output colour space. Note that although we ignore the
> value, we do change it, so that code which attempts to set the
> ProcessColorModel won't produce an error (ie some of the Quality Logic
> test files).
> This does produce one small difference; Bug692106.ps run through
> ps2write, the result is somewhat improved when rendered to RGB.
> devices/vector/gdevpdfb.h
> devices/vector/gdevpdfc.c
> devices/vector/gdevpdfg.c
> devices/vector/gdevpdfi.c
> devices/vector/gdevpdfk.c
> devices/vector/gdevpdfp.c
> devices/vector/gdevpdfv.c
> devices/vector/gdevpdfx.h
> devices/vector/gdevpsdf.h
> devices/vector/gdevpsdu.c
> doc/VectorDevices.htm

2016-04-09 14:38:17 +0100
Ken Sharp <ken.sharp@artifex.com>
6cab1a4b2a08a7d0bcb4772d28a22c72eff62052

> pdfwrite - write fonts as ProcSet resources instead of fonts
> Seems that font names aren't allowed to have spaces and aren't supposed
> to use string syntax (bloody stupid idea). So just write a DSC comment
> that its a ProcSet instead of a Font, problem solved.
> devices/vector/gdevpdfu.c

2016-04-09 09:18:25 +0100
Ken Sharp <ken.sharp@artifex.com>
b28091a97d3c153feeecf47dc8fefa90ab5984a2

> PDF interpreter - fix a typo in an error message
> Resource/Init/pdf_ops.ps

2016-04-05 10:51:24 +0100
Ken Sharp <ken.sharp@artifex.com>
0ec0f1627b7f7f5ffa1347123a926cd1e32c9f19

> PDF interpreter + pdfwrite - use font object numbers to detect identical fonts
> Previously we have had problems when dealing with multiple input PDF files
> where the files contain subset fonts with poorly chosen subset prefixes.
> Because we only have the font name to work with it was difficult to
> determine whether two fonts with the same name were, in fact, the same font.
> Incorrectly deciding that fonts were the same led to glyphs being wrong
> in the pdfwrite output, whereas treating all fonts as unique resulted in
> outputting far, far too many font instances.
> In ths commit we add a means to determine from PostScript the filename
> associated with a PostScript file object and we use that to get the
> filename of the current PDF file being processed in the PDF interpreter.
> When we encounter a font in a PDF file, we check to see whether it has
> an object number and a FontDescriptor, if the FontDescriptor is present
> we get its object number. We then check to see if the FontDescriptor
> has a FontFile, if it does not then the font is not embedded.
> If the font is embedded then we use the object number of the FontDescriptor
> (two fonts can have the same FOntDescriptor, and we can treat these as
> being the same font) and combine it with the PDF filename using a
> CRC to produce a hash which we store in the font as an XUID.
> pdfwrite then uses the XUID (if present) to determine if two fonts
> are in fact the same font.
> Adding the XUID causes a very small number of pixel differences in
> the text of some PDF files (especially, for some reason, with the
> psdcmy device). Also, a few PDF files have multiple copies of the
> same font, with different FontDescriptors, which were previously merged
> but now are not, whch leads to a small increase in file size.
> This new behaviour can be disabled by adding the -dPDFDontUseFontObjectNum
> switch on the command line.
> Resource/Init/pdf_base.ps
> Resource/Init/pdf_font.ps
> Resource/Init/pdf_main.ps
> Resource/Init/pdf_ops.ps
> devices/vector/gdevpdtf.h
> devices/vector/gdevpdtt.c
> doc/VectorDevices.htm
> psi/zfile.c

2016-04-08 11:59:16 +0200
Tor Andersson <tor.andersson@artifex.com>
d3d767d9b91ae7d82c261fbdfd735f3042161032

> Reindent jbig2dec source to follow gs coding style.
> First a pass through gnu indent:
> indent \
> -bad -nbap -nsob -br -ce -cli0 \
> -npcs -ncs -i4 -di0 -psl -lp -lps -nut -l160 \
> *.c *.h
> Followed by astyle to patch over some of the indentation bugs in gnu indent:
> astyle --style=kr -H -U -k3 *.c *.h
> jbig2dec/config_win32.h
> jbig2dec/getopt.c
> jbig2dec/getopt.h
> jbig2dec/getopt1.c
> jbig2dec/jbig2.c
> jbig2dec/jbig2.h
> jbig2dec/jbig2_arith.c
> jbig2dec/jbig2_arith.h
> jbig2dec/jbig2_arith_iaid.c
> jbig2dec/jbig2_arith_iaid.h
> jbig2dec/jbig2_arith_int.c
> jbig2dec/jbig2_arith_int.h
> jbig2dec/jbig2_generic.c
> jbig2dec/jbig2_generic.h
> jbig2dec/jbig2_halftone.c
> jbig2dec/jbig2_halftone.h
> jbig2dec/jbig2_huffman.c
> jbig2dec/jbig2_huffman.h
> jbig2dec/jbig2_hufftab.h
> jbig2dec/jbig2_image.c
> jbig2dec/jbig2_image.h
> jbig2dec/jbig2_image_pbm.c
> jbig2dec/jbig2_image_png.c
> jbig2dec/jbig2_metadata.c
> jbig2dec/jbig2_metadata.h
> jbig2dec/jbig2_mmr.c
> jbig2dec/jbig2_mmr.h
> jbig2dec/jbig2_page.c
> jbig2dec/jbig2_priv.h
> jbig2dec/jbig2_refinement.c
> jbig2dec/jbig2_segment.c
> jbig2dec/jbig2_symbol_dict.c
> jbig2dec/jbig2_symbol_dict.h
> jbig2dec/jbig2_text.c
> jbig2dec/jbig2_text.h
> jbig2dec/jbig2dec.c
> jbig2dec/memcmp.c
> jbig2dec/memento.c
> jbig2dec/memento.h
> jbig2dec/os_types.h
> jbig2dec/pbm2png.c
> jbig2dec/sha1.c
> jbig2dec/sha1.h
> jbig2dec/snprintf.c

2016-01-05 15:21:43 +0100
Tor Andersson <tor.andersson@artifex.com>
22506f32c40851e9ec6d0321f7ef82f1c9e12605

> Update C-style to mention that we don't mix tabs and spaces.
> doc/C-style.htm

2016-01-05 14:53:03 +0100
Tor Andersson <tor.andersson@artifex.com>
08b7f1ef45a844138df28e678c062400036a7b8b

> Fix warning: for loop has empty body (semicolon at end of line).
> jbig2dec/jbig2_text.c

2016-04-08 09:42:13 +0100
Chris Liddell <chris.liddell@artifex.com>
9c29e53a5955c3c12ed1b1dff66a564cbec8d24d

> Close file on error before exit
> jbig2dec/jbig2dec.c

2016-04-08 09:37:32 +0100
Chris Liddell <chris.liddell@artifex.com>
d65f57bc4dc4732dc828a342498c34308101e507

> Fix jbig2dec libpng API versions support
> jbig2dec/jbig2_image_png.c

2016-04-07 15:33:53 +0100
Chris Liddell <chris.liddell@artifex.com>
b0878d062cf7acefbc2b47e038af4e3392132981

> Update version number and dates for jbig2dec release
> will be v0.13
> jbig2dec/CHANGES
> jbig2dec/config_win32.h
> jbig2dec/configure.ac
> jbig2dec/jbig2dec.1

2016-03-31 08:00:34 +0100
Chris Liddell <chris.liddell@artifex.com>
1e6f5f00082ee7aa8dbcf65bfcc3ba85acd89443

> Correct a couple of typos
> doc/History9.htm
> doc/News.htm

2016-04-05 12:28:19 +0100
Ken Sharp <ken.sharp@artifex.com>
f29334eac74485b8274d13b56915b5e28290e6c7

> txtwrite - remove some commented out code
> devices/vector/gdevtxtw.c

2016-04-05 12:27:53 +0100
Ken Sharp <ken.sharp@artifex.com>
734ebbf2ca118da7fbc56ae53e7c08db477ce96d

> pdfwrite - remove various chunks of dead/deprecated code
> devices/vector/gdevpdfc.c
> devices/vector/gdevpdfd.c
> devices/vector/gdevpdte.c
> devices/vector/gdevpdtw.c

2016-03-05 14:56:03 -0800
Chris Liddell <chris.liddell@artifex.com>
ab109aaeb3ddba59518b036fb288402a65cf7ce8

> Bug 694724: Have filenameforall and getenv honor SAFER
> Resource/Init/gs_init.ps
> psi/zfile.c

2016-03-29 15:25:05 +0100
Chris Liddell <chris.liddell@artifex.com>
bcdbe51791cf38240c73862af9ca1cacb8f3e177

> Tidy up the 'sanitize' target
> Have configure check that the compiler and linker can handle the address
> sanitizer options, and if not, put something dummy in so the 'sanitize'
> will fail pretty much immediately.
> Remove the '-i' option from the recursive make call since we no longer need
> that.
> Makefile.in
> base/unix-end.mak
> configure.ac

2016-02-03 11:38:44 +0000
Chris Liddell <chris.liddell@artifex.com>
8b1d6f2f8d9e9f1706e2893042872a723a6d3ce3

> Bug 696563: tidy memory use in genconf and mkromfs
> Both tools failed to free all their working memory before exit.
> genconf was especially bad.
> base/genconf.c
> base/mkromfs.c

2016-01-05 15:52:35 +0000
Chris Liddell <chris.liddell@artifex.com>
fc1d455fe97e3c306a04c5f3674bb61969d9302d

> Bug 693179: move gc related variables off C stack
> The variables ticks_left and gc_signal were local stack variables in interp()
> and gs_call_inter() respectively, a pointer to which was set in the
> gs_memory_gc_status_t of each memory "space".
> This moves and "merges" the variables into a single entry in gs_lib_ctx, and
> has the memory spaces access that variable directly in gs_lib_ctx, rather than
> through a pointer belonging to each space.
> base/gsalloc.c
> base/gsalloc.h
> base/gslibctx.h
> psi/interp.c
> psi/isave.c

2016-03-29 08:42:50 +0100
Ken Sharp <ken.sharp@artifex.com>
96a779957d6d0dc83e0f97e302b1e5ecdc924f61

> pdfwrite - silence some compiler warnings
> devices/vector/gdevpdfd.c

2016-03-28 17:41:16 +0100
Chris Liddell <chris.liddell@artifex.com>
22dac7b2fa8f5015687396433ceb6c5038002ec9

> Remove a couple of mac specific hidden files
> These shouldn't be in the repo
> lcms2/Projects/mac/._.DS_Store
> lcms2/Projects/mac/LittleCMS/._.DS_Store

2016-03-28 17:15:16 +0100
Ken Sharp <ken.sharp@artifex.com>
fa20f5915978823a8c72a80e49fa90ce9c5c5879

> High level forms - cope with junk on stack after PaintProc
> Bug #696678 " "Error: /typecheck in --.execform1--" writing pdf file"
> Form PaintProc procedures are supposed to have no side effects, in
> particular they should not disturb the stacks. There are some
> PostScript programs which (usually by negligence) don't obey this
> restriction.
> If the PaintProc deliberately disturbs the stacks, or has other side-
> effects, then there is nothing we can do about it, but if its just an
> oversight we can 'fix' the problem by removing extraneous objects from
> the operand stack after we execute the PaintProc and before we call
> .endform.
> This allows some badly behaved PostScript programs to work.
> No differences expected.
> Resource/Init/gs_lev2.ps

2016-03-22 15:12:10 +0000
Ken Sharp <ken.sharp@artifex.com>
f124ca485a4a0648cc502f5e5adb3e2b8b9de955

> pdfwrite - optimise rectangular subpaths as 're' where possible
> The current 'vector device' path code doesn't work properly with clips and
> doesn't optimise rectangular subpaths as rectangles. (For the purposes
> of 're' optimisation a rectangular subpath is a moveto, followed by 4
> lineto's at right angles, followed by a closepath).
> This commit creates new code to handle pahts in pdfwrite, if the enumerator
> is a clip enumerator it correctly enumerates the subpaths from the clip
> instead of enumerating the path.
> We buffer up operations looking for rectangles; when we find one, if the
> current matrix is not sheared or skewed, then we check to see if the
> rectangle is 'x first'. If it isn't we move the starting point round by one
> as 're' always emits width first. We also check to see if we are doing
> a dashed stroke, as if we are we cannot move the initial vertex as this
> will cause the dash to be incorrect (abort the optimisation).
> We copy the code from gdevvec whcih checks to see if the whole path is
> a rectangle, and also the 'optimise' code whch will concatenate colinear
> moveto and lineto operations into a single operation.
> Finally we also preserve the heuristic that prevents a fill with a trailing
> moveto as ths apparently exposed a bug in old versions of Acrobat.
> Ths does result in a number of single pixel or single pixel wide
> differences in the test suite, but they all look like simple differences
> to me, not regressions. The new code doesn not appear to be
> singificantly slower and ths does produce a useful reduction in file
> size for some files.
> base/gdevvec.h
> devices/vector/gdevpdfd.c

2016-03-23 17:28:08 +0000
Robin Watts <robin.watts@artifex.com>
efc6c6f3587b0c08522f3d9f45e611dc1dceba23

> Bring Memento up to date with MuPDF version.
> base/memento.c
> base/memento.h

2016-03-23 17:24:04 +0000
Robin Watts <robin.watts@artifex.com>
7152391110d4b58287740e4de90912024169ac9d

> Add comment to misleading device code.
> devices/gdevdjtc.c

2015-09-24 11:04:22 +0100
Chris Liddell <chris.liddell@artifex.com>
5a7b20755617cde8c915ab24725f94fd74be3aee

> Bring master up to date with gs919 branch
> Add words to 9.18 release notes
> about the revised directory structure, build and executable names
> Tweak changelog for 9.18 release
> Update dates versions in docs etc
> Changelog + release "highlights".
> Dates, strings and changelog for release.
> Makefile.in
> base/version.mak
> doc/API.htm
> doc/C-style.htm
> doc/Commprod.htm
> doc/DLL.htm
> doc/Deprecated.htm
> doc/Details8.htm
> doc/Details9.htm
> doc/Develop.htm
> doc/Devices.htm
> doc/Drivers.htm
> doc/Fonts.htm
> doc/Helpers.htm
> doc/History1.htm
> doc/History2.htm
> doc/History3.htm
> doc/History4.htm
> doc/History5.htm
> doc/History6.htm
> doc/History7.htm
> doc/History8.htm
> doc/History9.htm
> doc/Install.htm
> doc/Issues.htm
> doc/Language.htm
> doc/Lib.htm
> doc/Make.htm
> doc/News.htm
> doc/Projects.htm
> doc/Ps-style.htm
> doc/Ps2epsi.htm
> doc/Psfiles.htm
> doc/Readme.htm
> doc/Release.htm
> doc/SavedPages.htm
> doc/Source.htm
> doc/Unix-lpr.htm
> doc/Use.htm
> doc/VectorDevices.htm
> doc/WhatIsGS.htm
> doc/Xfonts.htm
> doc/gs-vms.hlp
> doc/thirdparty.htm
> man/dvipdf.1
> man/font2c.1
> man/gs.1
> man/gslp.1
> man/gsnd.1
> man/pdf2dsc.1
> man/pdf2ps.1
> man/pf2afm.1
> man/pfbtopfa.1
> man/printafm.1
> man/ps2ascii.1
> man/ps2epsi.1
> man/ps2pdf.1
> man/ps2pdfwr.1
> man/ps2ps.1
> man/wftopfa.1
> psi/int.mak
> psi/winint.mak

2016-03-21 10:38:58 +0000
Ken Sharp <ken.sharp@artifex.com>
7ee0a82260050b2b7391b4968cd02682557e2cbc

> PDF interpreter - cope with Indexed space with 'hival' being indirect
> The code to handle an Indexed colour space expected that the 'hival',
> that is the highest index, would be an integer. It can legally be an
> indirect reference. Dumb, but legal.
> Here we 'resolve' the hival in case it is an indirect reference.
> No differences expected
> Resource/Init/pdf_draw.ps

2016-03-17 17:12:41 +0000
Chris Liddell <chris.liddell@artifex.com>
2dda1c123c76a126059808c04df63805f1694686

> Bug 696665: add extra brackets for better compatibility
> Some versions of autoconf enforce macro arguments to macros being bounded by
> "[" and "[", others do not (the version I have does not), but we should use
> them for best compatibility.
> configure.ac

2016-03-17 10:21:16 +0000
Chris Liddell <chris.liddell@artifex.com>
2e262fac0f15b51dd3588e3e92157b5fd2a90bb2

> Remove some left debug code.
> configure.ac

2016-03-17 10:06:14 +0000
Chris Liddell <chris.liddell@artifex.com>
c281807816be4dcc10c3fc66b32651098f321600

> Bug 696665: fix gs only install
> I added dummy gpcl6 and gxps exe names to avoid a warning when building from a
> gs only release archive. I neglected to add appropriate dummy install targets
> for those, and that caused an error with "make install".
> base/unixinst.mak

2016-03-15 08:29:03 -0700
Ray Johnston <ray.johnston@artifex.com>
aeb5c1e3d2b47ffb9f4ccd01d32429ebd2c5effc

> Increase limits for tile_clip_buffer and Max VM on 64-bit machines
> These changes allow the file from bug 696257 to complete on 64-bit gcc
> builds where a "long" is 64 bits. Also the MaxLocalVM and MaxGlobalVM
> values returned in CPSI mode are truncated to return only the low 32
> bits (CET 99-01.ps)
> base/gsalloc.c
> base/gxmclip.h
> psi/zusparam.c

2016-03-15 08:17:34 -0700
Ray Johnston <ray.johnston@artifex.com>
28049debc650116b9762d7b0ec82f52d45039927

> Revert change to mswinpr2 device from commit 5cf300b
> This caused us to ignore the printer specified by -s%printer%___
> and always use the default printer if QueryUser was not specified
> devices/gdevwpr2.c

2016-03-15 10:38:15 +0000
Ken Sharp <ken.sharp@artifex.com>
38990b3619ed74308454d0d3910bd394a982e7cd

> pdfwrite - more changes for composite object emission
> This 'fixes' Bug 696657, but it is not correct in general.
> We break the emission of composite objects up into blocks of less than
> 255 characters for compliance with DSC output, but if any one of the
> objects contains certain characters ('/' '[' '{' '(' or ' ') then we
> might break the object inappropriately (this is likely for strings and
> is the case for ths file).
> There is no way to address this 'properly' in general, its perfectly
> possible to create a PostScript object more than 255 bytes which
> cannot be broken up, so I'm going to ignore the problem for now, since
> it only occurs when writing pdfmarks to the ps2write device and having
> DSC turned on (which is the default).
> If anyone really needs to do this, they should set ProduceDSC to false.
> devices/vector/gdevpdfu.c

2016-03-15 09:37:53 +0000
Chris Liddell <chris.liddell@artifex.com>
15240a6631e2c721402dcbaf58d9b784707bde42

> Bug 696655: have configure support --without-pcl
> and --without-xps.
> configure.ac

2016-03-15 09:19:33 +0000
Ken Sharp <ken.sharp@artifex.com>
5d1ffe2669e7523e579a4cc47bb6debe805c0a2c

> pdfwrite - fix writing of composite objects
> When emitting composite objects we attempt (for reasons which are
> unclear) to do so in chunks of 256 bytes or less. The code to split a
> large buffer into smaller buffers was simply broken, did not work
> properly at all.
> This commit fixes the logical flaw, allowing us to write composite
> objects larger then 254 bytes without error.
> NB this is a rare condition, such objects are usually only created
> from input such as pdfmarks, normal composite objects are created and
> emitted by pdfwrite itself and do not go through this code.
> devices/vector/gdevpdfu.c

2016-03-14 10:09:42 +0000
Chris Liddell <chris.liddell@artifex.com>
ebd8585aabd050b64e33221478d0bcb6b7f41abf

> Always have configure set gpcl6 and gxps exe names
> But still skip adding them to the targets list if the source is not available.
> This avoids a warning when building a Ghostscript only release archive.
> configure.ac

2016-03-11 10:13:03 +0000
Chris Liddell <chris.liddell@artifex.com>
36ea2f21ee862f6e3d3276389cf71a8d0008865b

> Bump version number/date
> Resource/Init/gs_init.ps
> base/version.mak

2016-03-23 08:19:58 +0000
Chris Liddell <chris.liddell@artifex.com>
50a8b6fcd897e71344965d6bc300f0d01b850fad

> Dates, strings and changelog for release.
> base/gscdef.c
> base/version.mak
> doc/API.htm
> doc/C-style.htm
> doc/Commprod.htm
> doc/DLL.htm
> doc/Deprecated.htm
> doc/Details8.htm
> doc/Details9.htm
> doc/Develop.htm
> doc/Devices.htm
> doc/Drivers.htm
> doc/Fonts.htm
> doc/Helpers.htm
> doc/History1.htm
> doc/History2.htm
> doc/History3.htm
> doc/History4.htm
> doc/History5.htm
> doc/History6.htm
> doc/History7.htm
> doc/History8.htm
> doc/History9.htm
> doc/Install.htm
> doc/Issues.htm
> doc/Language.htm
> doc/Lib.htm
> doc/Make.htm
> doc/News.htm
> doc/Projects.htm
> doc/Ps-style.htm
> doc/Ps2epsi.htm
> doc/Psfiles.htm
> doc/Readme.htm
> doc/Release.htm
> doc/SavedPages.htm
> doc/Source.htm
> doc/Unix-lpr.htm
> doc/Use.htm
> doc/VectorDevices.htm
> doc/WhatIsGS.htm
> doc/Xfonts.htm
> doc/gs-vms.hlp
> doc/thirdparty.htm
> man/dvipdf.1
> man/font2c.1
> man/gs.1
> man/gslp.1
> man/gsnd.1
> man/pdf2dsc.1
> man/pdf2ps.1
> man/pf2afm.1
> man/pfbtopfa.1
> man/printafm.1
> man/ps2ascii.1
> man/ps2epsi.1
> man/ps2pdf.1
> man/ps2pdfwr.1
> man/ps2ps.1
> man/wftopfa.1

2016-03-17 17:12:41 +0000
Chris Liddell <chris.liddell@artifex.com>
9cf6bfee8d3c285e84d28437bff0747f601a7827

> Bug 696665: add extra brackets for better compatibility
> Some versions of autoconf enforce macro arguments to macros being bounded by
> "[" and "[", others do not (the version I have does not), but we should use
> them for best compatibility.
> configure.ac

2016-03-17 10:21:16 +0000
Chris Liddell <chris.liddell@artifex.com>
d7e175bc49d8dcdc38af093cd744c62cb6451686

> Remove some left debug code.
> configure.ac

2016-03-17 10:06:14 +0000
Chris Liddell <chris.liddell@artifex.com>
a529498d1a52bbb91cca5e32512d6c49e665a004

> Bug 696665: fix gs only install
> I added dummy gpcl6 and gxps exe names to avoid a warning when building from a
> gs only release archive. I neglected to add appropriate dummy install targets
> for those, and that caused an error with "make install".
> base/unixinst.mak

2016-03-15 08:17:34 -0700
Ray Johnston <ray.johnston@artifex.com>
3a089782b11699fe83c22a92544623a9c21e0c4a

> Revert change to mswinpr2 device from commit 5cf300b
> This caused us to ignore the printer specified by -s%printer%___
> and always use the default printer if QueryUser was not specified
> devices/gdevwpr2.c

2016-03-11 12:17:57 +0000
Chris Liddell <chris.liddell@artifex.com>
1a8b008b6d34efcc00b8c10507a28b517ab5b7db

> Changelog + release "highlights".
> doc/Devices.htm
> doc/History9.htm
> doc/News.htm

2016-03-14 10:09:42 +0000
Chris Liddell <chris.liddell@artifex.com>
2e7c06dc36d9fe255a6171a28967eb53395abe4f

> Always have configure set gpcl6 and gxps exe names
> But still skip adding them to the targets list if the source is not available.
> This avoids a warning when building a Ghostscript only release archive.
> configure.ac

2016-03-11 10:34:00 +0000
Chris Liddell <chris.liddell@artifex.com>
7f9c8fbce554eebdbda21f25d208c541355e177d

> Update dates versions in docs etc
> Makefile.in
> doc/API.htm
> doc/C-style.htm
> doc/Commprod.htm
> doc/DLL.htm
> doc/Deprecated.htm
> doc/Details8.htm
> doc/Details9.htm
> doc/Develop.htm
> doc/Devices.htm
> doc/Drivers.htm
> doc/Fonts.htm
> doc/Helpers.htm
> doc/History1.htm
> doc/History2.htm
> doc/History3.htm
> doc/History4.htm
> doc/History5.htm
> doc/History6.htm
> doc/History7.htm
> doc/History8.htm
> doc/History9.htm
> doc/Install.htm
> doc/Issues.htm
> doc/Language.htm
> doc/Lib.htm
> doc/Make.htm
> doc/News.htm
> doc/Projects.htm
> doc/Ps-style.htm
> doc/Ps2epsi.htm
> doc/Psfiles.htm
> doc/Readme.htm
> doc/Release.htm
> doc/SavedPages.htm
> doc/Source.htm
> doc/Unix-lpr.htm
> doc/Use.htm
> doc/VectorDevices.htm
> doc/WhatIsGS.htm
> doc/Xfonts.htm
> doc/gs-vms.hlp
> doc/thirdparty.htm
> man/dvipdf.1
> man/font2c.1
> man/gs.1
> man/gslp.1
> man/gsnd.1
> man/pdf2dsc.1
> man/pdf2ps.1
> man/pf2afm.1
> man/pfbtopfa.1
> man/printafm.1
> man/ps2ascii.1
> man/ps2epsi.1
> man/ps2pdf.1
> man/ps2pdfwr.1
> man/ps2ps.1
> man/wftopfa.1
> psi/int.mak
> psi/winint.mak

2016-03-11 10:30:26 +0000
Chris Liddell <chris.liddell@artifex.com>
837d4dcaff85a7c96726caaeeb10b690aa6e18f1

> Change product string for 9.19 RC1
> base/gscdef.c

2015-09-30 14:57:38 +0100
Chris Liddell <chris.liddell@artifex.com>
50efb7307dab9df334ad45acdfbe83bf2f3ffba3

> Tweak changelog for 9.18 release
> doc/History9.htm

2015-09-24 11:04:22 +0100
Chris Liddell <chris.liddell@artifex.com>
32e59ede8dddc2838478dfaeac2a238318c22835

> Add words to 9.18 release notes
> about the revised directory structure, build and executable names
> doc/History9.htm
> doc/News.htm

## Version 9.19 (2016-03-23)

This is the thirteenth full release in the stable 9.x series, and is mainly a maintenance release.

Highlights in this release include:

- New custom PJL (near) equivalents for pdfmark and setdistillerparams. These were primarily added to allow pdfwrite to be configured correctly for PDF/A output from GhostPCL. See: pdfwrite with PCL input for more details.

  Ghostscript users should continue to use the existing pdfmark and setdistillerparams capabilities.

- Metadata pdfmark is now implemented. This allows the user to specify an XMP stream which will be written to the Catalog of the PDF file. A new pdfmark 'Ext_Metadata' has been defined. This takes a string parameter which contains XML to be added to the XMP normally created by pdfwrite.

  See pdfwrite pdfmark extensions for more information.

- An experimental, rudimentary raster trapping implementation has been added to the Ghostscript graphics library. See Trapping for details.

- The halftone threshold array generation tools (part of `toolbin/halftone`) have been improved with `thresh_remap` which allows folding the transfer function (AKA toner response curve (TRC)) into the threshold array so that highlights are improved. Further, `gen_stochastic` has improved support for minimum dot size and shape.

- Plus the usual round of bug fixes, compatibility changes, and incremental improvements.

For a list of open issues, or to report problems, please visit bugs.ghostscript.com.

### Incompatible changes

- (Minor) API change: copy_alpha now supports 8 bit depth (as well as the previous 2 and 4).

- The gs man pages are woefully out of date and basically unmaintained. With the release following 9.19, we intend to replace their contents with a very limited summary of (unlikely to ever change aspects of) calling Ghostscript, and a pointer to the (maintained) HTML documentation. That is, unless a volunteer is willing to update, and commit to maintaining the man pages.

- We plan (ideally for the release following 9.19) to somewhat tidy up the device API. We plan to remove deprecated device procs (methods/function pointers). We also intend to merge the imager state and graphics state (thus eliminating the imager state), and change the device API so every device proc takes a graphics state parameter (rather than the current scheme where only a very few procs take an imager state parameter). This should serve as notice to anyone maintaining a Ghostscript device outside the canonical source tree that you may (probably will) need to update your device(s) when these changes happen. Devices using only the non-deprecated procs should be trivial to update.

### Changelog

2016-03-17 17:12:41 +0000
Chris Liddell <chris.liddell@artifex.com>
9cf6bfee8d3c285e84d28437bff0747f601a7827

> Bug 696665: add extra brackets for better compatibility
> Some versions of autoconf enforce macro arguments to macros being bounded by
> "[" and "[", others do not (the version I have does not), but we should use
> them for best compatibility.
> configure.ac

2016-03-17 10:21:16 +0000
Chris Liddell <chris.liddell@artifex.com>
d7e175bc49d8dcdc38af093cd744c62cb6451686

> Remove some left debug code.
> configure.ac

2016-03-17 10:06:14 +0000
Chris Liddell <chris.liddell@artifex.com>
a529498d1a52bbb91cca5e32512d6c49e665a004

> Bug 696665: fix gs only install
> I added dummy gpcl6 and gxps exe names to avoid a warning when building from a
> gs only release archive. I neglected to add appropriate dummy install targets
> for those, and that caused an error with "make install".
> base/unixinst.mak

2016-03-15 08:17:34 -0700
Ray Johnston <ray.johnston@artifex.com>
3a089782b11699fe83c22a92544623a9c21e0c4a

> Revert change to mswinpr2 device from commit 5cf300b
> This caused us to ignore the printer specified by -s%printer%___
> and always use the default printer if QueryUser was not specified
> devices/gdevwpr2.c

2016-03-14 10:09:42 +0000
Chris Liddell <chris.liddell@artifex.com>
f75b4a8160d60039d850c581c7fbe18f1574bc39

> Always have configure set gpcl6 and gxps exe names
> But still skip adding them to the targets list if the source is not available.
> This avoids a warning when building a Ghostscript only release archive.
> configure.ac

2016-03-11 10:34:00 +0000
Chris Liddell <chris.liddell@artifex.com>
7f9c8fbce554eebdbda21f25d208c541355e177d

> Update dates versions in docs etc
> Makefile.in
> doc/API.htm
> doc/C-style.htm
> doc/Commprod.htm
> doc/DLL.htm
> doc/Deprecated.htm
> doc/Details8.htm
> doc/Details9.htm
> doc/Develop.htm
> doc/Devices.htm
> doc/Drivers.htm
> doc/Fonts.htm
> doc/Helpers.htm
> doc/History1.htm
> doc/History2.htm
> doc/History3.htm
> doc/History4.htm
> doc/History5.htm
> doc/History6.htm
> doc/History7.htm
> doc/History8.htm
> doc/History9.htm
> doc/Install.htm
> doc/Issues.htm
> doc/Language.htm
> doc/Lib.htm
> doc/Make.htm
> doc/News.htm
> doc/Projects.htm
> doc/Ps-style.htm
> doc/Ps2epsi.htm
> doc/Psfiles.htm
> doc/Readme.htm
> doc/Release.htm
> doc/SavedPages.htm
> doc/Source.htm
> doc/Unix-lpr.htm
> doc/Use.htm
> doc/VectorDevices.htm
> doc/WhatIsGS.htm
> doc/Xfonts.htm
> doc/gs-vms.hlp
> doc/thirdparty.htm
> man/dvipdf.1
> man/font2c.1
> man/gs.1
> man/gslp.1
> man/gsnd.1
> man/pdf2dsc.1
> man/pdf2ps.1
> man/pf2afm.1
> man/pfbtopfa.1
> man/printafm.1
> man/ps2ascii.1
> man/ps2epsi.1
> man/ps2pdf.1
> man/ps2pdfwr.1
> man/ps2ps.1
> man/wftopfa.1
> psi/int.mak
> psi/winint.mak

2016-03-11 10:30:26 +0000
Chris Liddell <chris.liddell@artifex.com>
837d4dcaff85a7c96726caaeeb10b690aa6e18f1

> Change product string for 9.19 RC1
> base/gscdef.c

2015-09-30 14:57:38 +0100
Chris Liddell <chris.liddell@artifex.com>
50efb7307dab9df334ad45acdfbe83bf2f3ffba3

> Tweak changelog for 9.18 release
> doc/History9.htm

2015-09-24 11:04:22 +0100
Chris Liddell <chris.liddell@artifex.com>
32e59ede8dddc2838478dfaeac2a238318c22835

> Add words to 9.18 release notes
> about the revised directory structure, build and executable names
> doc/History9.htm
> doc/News.htm

2016-03-10 11:16:51 +0000
Robin Watts <robin.watts@artifex.com>
e980dc6f1356e659254974838a94e16d6506af44

> Bug 696640: Fix stack overflow in memento.
> Windows backtraces are limited to 63 levels. Linux ones can be
> any size. I'd mistakenly overflown the buffers in the linux
> case.
> While we're fixing that, improve the code to require less copying.
> base/memento.c

2016-03-10 04:32:36 -0800
Robin Watts <robin@peeves.(none)>
596e5b0bb0bc470cc177e5dca35bc69de7c664d1

> Memento: Fix linux memento builds.
> The fix for windows builds broke linux due to -DMEMENTO
> being in CFLAGS on windows, and GENOPT on configured builds.
> Also tidy the code to avoid things detected by the more picky
> compiler on Linux.
> base/lib.mak
> base/memento.c
> base/memento.h

2016-03-09 23:44:10 +0100
Vincent Torri <vincent dot torri at gmail dot com>
80c9d7671534c51e7239e0f7c5ca8a67a43c842d

> Bug 696641 - support build with MSYS2
> uname in MSYS2 terminal reports MSYS_NT-6.1, so add MSYS* to all the "case"
> in configure.ac.
> Note: cygwin terminal's uname reports CYGWIN_NT-6.1
> configure.ac

2016-03-10 11:11:35 +0000
Robin Watts <robin.watts@artifex.com>
f79377b1a156c40ff304a3d161b54865e35f23a3

> Fix windows memento builds.
> So, windows.h cannot be used unless Microsoft extensions are enabled.
> How dumb is that?
> base/lib.mak
> base/memento.c

2016-03-09 10:49:26 +0000
Chris Liddell <chris.liddell@artifex.com>
0e787367c085457a106890ce4c2068dccee86933

> Removing hacky HAVE_LIBDL stuff for memento....
> Replace with proper configure setting.
> base/lib.mak
> configure.ac

2016-03-09 15:36:50 +0000
Chris Liddell <chris.liddell@artifex.com>
4f0dd9dd527451c1a2b625c667c4bf0a131e9ce3

> Properly fix building with shared OpenJPEG.
> configure.ac

2016-03-07 06:26:25 -0800
Robin Watts <robin@peeves.(none)>
0d4339898f181acb77bc4cc2a419f38cf4727b4e

> Memento: Store/display backtraces with blocks.
> If built with MEMENTO_DETAILS (on by default), we store the
> backtrace on every event that affects a block.
> Memento_details(address) will display the events that affected
> a block (typically malloc, {realloc}*, free), including the
> backtrace at each point.
> Windows and linux use different mechanisms for this. Windows
> loads a DLL and calls windows specific functions - no extra
> libraries are required.
> Linux also loads a shared object (libbacktrace.so). This is not
> present on all platforms, so on platforms where it is not available
> we just get addresses. These can be converted using addr2line
> (unless ASLR is enabled).
> base/lib.mak
> base/memento.c

2016-03-05 15:25:01 -0800
Chris Liddell <chris.liddell@artifex.com>
8692d5e0996ab3995e1d02efc3d0ca145ccced71

> Fix psdcmyk handling of output to /dev/null or equivalent.
> The PSD file format does not support multiple images (pages) in a single file,
> so we spot such an attempt (by checking whether or not the output file string
> has a "%d" in it) and throw an error.
> This also throws an error if an attempt is made to write multiple pages to
> /dev/null (as is done for performance testing).
> Since it really doesn't matter if the output "file" is invalid when we're just
> discarding the data, spot this case, and allow multi-page files to run
> without error.
> devices/gdevpsd.c

2016-03-05 14:34:20 -0800
Chris Liddell <chris.liddell@artifex.com>
49852e6060f63b3feaa15157ee27644eb1d1b8c9

> Remove pointless (Mac classic only) setenv()
> base/gp_macio.c

2016-03-05 13:12:46 -0800
Chris Liddell <chris.liddell@artifex.com>
381bc0729b96f47ebe1ee5d49cb603d688361291

> Bug 696610: add pngmonod into the configure build
> configure.ac

2016-03-05 20:01:04 +0000
Ken Sharp <ken.sharp@artifex.com>
cd3c6a408bd64e515a46cfb4bdbbb7e42d0b943e

> Now that we have contatced the original author and received written
> copyright assignment, update the copyright headers for the RAM file
> system code.
> base/gsioram.c
> base/ramfs.c

2016-03-04 16:18:23 -0800
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
284cd94895a68c0d558c2b9d5325b77cce90f807

> Document psdcmykog device.
> doc/Devices.htm

2016-03-04 15:15:07 -0800
Ray Johnston <ray.johnston@artifex.com>
5cf300b7347c509f7530f5f9e7d6b0b997581f33

> Fix bug 696559, default to QueryUser=3 so that printer properties are correct.
> Thanks to Nikolaus Kreuzer for suggesting this method. It now seems to work
> as requested and as I would expect.
> devices/gdevwpr2.c

2016-03-04 13:56:09 -0800
Chris Liddell <chris.liddell@artifex.com>
53ee0f551785f8ae3689f8cef77b48d76ba6340f

> Bug 696518: remove long deceased pcx2up device.
> base/unix-gcc.mak
> configure.ac
> devices/devs.mak
> devices/gdevp2up.c

2016-03-04 14:04:19 -0800
Ray Johnston <ray.johnston@artifex.com>
ab70c0f9de22ff012d5d73f9b2aab9ae724a743b

> Fix bug 696515 -- the snowflak.ps did not handle page size < 250 points.
> examples/snowflak.ps

2015-10-14 10:26:16 -0700
Ray Johnston <ray.johnston@artifex.com>
449604f1a31067fa8e32227c3ce234b55b8cf143

> Get rid of code allowing for no 12 bit or 16 bit image support.
> The gxino12b.c and gxino16b.c modules were no longer used and the
> graphics library always supported 12 and 16 bit images, so remove
> the leftover code allowing for these to be build time options.
> This was causing false positives with helgrind since the procs
> were being set into the two-dimensional array at run time. The
> unpackicc_16 had this same code even though there was no method
> or check for non-support.
> base/gxi12bit.c
> base/gxi16bit.c
> base/gximage.h
> base/gximdecode.c
> base/gxino12b.c
> base/gxino16b.c
> base/gxipixel.c
> base/gxiscale.c
> base/gxsample.h

2016-03-04 19:17:10 +0000
Ken Sharp <ken.sharp@artifex.com>
f71dca797cbcdf0430fd8009c6c517baed62b4cb

> pdfwrite - FunctionType 2 C0 and C1 are optional
> Bug #696626 " A PDF file causes ps2pdf crash"
> The code fro serialising a Type 2 function was assuming that C0 and C1
> were valid (validated by the interpreter) and always present. In fact
> both of these are optional. We were attempting to dereference a NULL
> pointer.
> Altered the type 2 serialise code to write the default values if either
> or both of C0 and C1 are not present.
> No differences expected.
> base/gsfunc3.c

2016-03-04 18:50:01 +0000
Ken Sharp <ken.sharp@artifex.com>
a90ca3d4c30339f93b1e595ee81d08f1ca7174e4

> ps2write - suppress an address sanitizer warning for MM fonts
> ps2write does not currently handle Multiple Master fonts well, we know
> this there is an open enhancement for it. We do have a hacky work-around
> which turns the MM OtherSubrs into regular OtherSubrs using the blended
> values.
> This doesn't work when the font program uses constrcuts such as ' x y div'
> in order to create floating point values. This could mean that we did
> not have as many paramters as expected on the stack as are required for
> a given MM OtherSubr, leading to us indexing off the bottom of the
> stack.
> This meant we were using random values, but this didn't really matter
> as the data is always going to be wrong. However the address sanitizer
> complains about this.....
> In this commit if we would underrun the stack we just write a 0 instead
> devices/vector/gdevpsf1.c

2016-03-04 15:40:30 +0000
Ken Sharp <ken.sharp@artifex.com>
8175c6993efa8637ac39a050cc0696a19214abe1

> pdfwrite fix address sanitizer complaint.
> When checking a font name to see if its a URW replacement for a base 14
> font we were doing a memcmp with the length of the candidate name.
> If that length exceeded the length of the URW name then we were in
> effect comparng against part of the next name (or random bytes off the
> end of the table.
> Of course this is harmless except in the highly unlikely case of the end
> of the table not being followed by more data bytes. But the address
> sanitizer complains. So we now compare the length of the two strings
> first.
> devices/vector/gdevpdtb.c

2016-03-03 15:50:48 -0800
Robin Watts <Robin.Watts@artifex.com>
b40526038481dd3158331df6c42c47654e02c3ab

> Memento: Speed improvements.
> Avoid searching the linked list of blocks in order to remove a
> block by moving to a doubly linked list. This can be done
> without increasing the amount of memory in use by making better
> use of the 'parent' pointer that is only used when displaying
> nested blocks.
> Also store magic values in the 'child' and 'sibling' pointers
> (again only used when displaying nested blocks) so that we
> can quickly verify that a block is real before doing too much
> with it.
> Those changes drastically reduce the time required for
> MEMENTO_LEAKONLY runs (now the same order of magnitude as non
> memento runs).
> Normal memento runs are still very slow when the numbers of
> blocks increase due to the paranoid checking taking time.
> To ameliorate this a bit, we try 2 other things.
> Firstly, we optimise the searching of blocks by making use of
> int aligned tests. This still doesn't make much difference.
> Secondly, we introduce a new mechanism for the 'paranoia'
> levels. If a negative number is given for the paranoia level
> (say -n) then we first perform our overwrite checks after n events.
> We next test after 2n events, then 4n, then 8n etc.
> The new default paranoia level is set to be -1024.
> This makes a huge difference, and brings normal memento runs
> down to be comparable with debug runs.
> base/memento.c
> base/memento.h

2016-03-01 16:58:43 +0000
Robin Watts <robin.watts@artifex.com>
83055a87a2ce1910ede8cdfe722766a8a4c13d55

> Bug 696616: Move antidropout downscaler functionality.
> The current code globally enables use of the antidropout
> downscaler on all halftoned devices (unless they override
> the gxdso call), when interpolation is enabled.
> We now introduce a -dAntidropoutDownscaler option that
> defaults off. That sets a bit in dev.color_info that is
> used to control the option. This decouples it from
> interpolation.
> base/gdevdflt.c
> base/gsdparam.c
> base/gxdevcli.h

2016-03-01 17:20:04 +0000
Chris Liddell <chris.liddell@artifex.com>
7a3d6527825a79471e93b723bbd2e6dad0c61b64

> Fix up some broken/out of date links
> Marcos did some cleanup identifying broken links, based on his work, I've fixed
> the broken links, and removed those to files that no longer exist.
> doc/Develop.htm
> doc/Drivers.htm

2016-03-01 15:04:38 +0000
Robin Watts <robin.watts@artifex.com>
579f5891d69bcb057f27e44d49bf686d64a9f2ee

> Bug 696620: Avoid rangecheck errors in tiff devices.
> Only write downscaler options if we will read them.
> devices/gdevtifs.c

2016-02-29 15:33:23 +0000
Ken Sharp <ken.sharp@artifex.com>
3c4c85ae660c22d8442c3a9ea17bbc295f2a2fac

> high level forms - account for flipped/mirrored CTM
> For high level forms support, if the device requests a specific CTM be
> applied we calculate a clip path which includes negative co-ordinates
> to ensure that a translated form won't be erroneously clipped to the
> page.
> When doing this, we need to account for the CTM when the form is executed
> potentially being flipped or mirrored (or both!)
> No differences expected.
> psi/zform.c

2016-02-28 09:02:43 +0000
Ken Sharp <ken.sharp@artifex.com>
5d15322e32f85f9b4d9fbebd19148d7a95428adf

> pdfwrite - silence Coverity warning
> Change an indent to silence Coverity.....
> devices/vector/gdevpdfi.c

2016-02-26 09:38:46 -0800
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
f682ba02caa1cb974e475cc387efce1e04d901f5

> Fixed links in Develop.htm and Drivers.html.
> Some referenced files appear to no longer exist, I've left those in
> the documentation but commented out with a 'missing' notation.
> doc/Develop.htm
> doc/Drivers.htm

2016-02-25 14:23:02 +0000
Robin Watts <robin.watts@artifex.com>
b94ac333a172558441726e47f257cb26a3b6f924

> Bug 696615: Solve incorrect copy_alpha of hl_color
> The code that expanded alphas to 8 bits was incorrect for the
> 4 bit case.
> base/gdevdbit.c

2016-02-25 10:56:35 +0000
Robin Watts <robin.watts@artifex.com>
65b72cece8e2462fd787e8d54d9f990327a061ac

> Fix dropped error code in clist code.
> base/gxclrect.c

2016-02-25 11:47:27 -0800
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
8f69cda3004976da8da5c23ca86fdb62086ec508

> Another set of broken doc links.
> doc/WhatIsGS.htm

2016-02-25 11:30:19 -0800
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
09ca513fbcd7e3a843cc2690dd9dadecfd50bad9

> Fixed another broken link in doc.
> doc/WhatIsGS.htm

2016-02-25 11:18:26 -0800
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
4d954bfd6b0bb8e3d7400ca1f5e4b6494ec91384

> Fixed broken links in doc/*.htm.
> There are still broken links in doc/Psfiles.htm, doc/Develop.htm, and
> doc/Drivers.htm caused by the files they refer to having been moved to
> a different directory. Those will be fixed in a separate commit.
> doc/Devices.htm
> doc/Language.htm
> doc/Readme.htm
> doc/Use.htm

2016-02-24 20:09:58 +0000
Robin Watts <robin.watts@artifex.com>
bcf738d762ef65e16f060d57ea15824f1f6bd57c

> Bug 696611: Avoid imagemask interpolation errors with pbmraw.
> pbmraw (deliberately) doesn't know how to copy_alpha. We never
> call copy_alpha when going to pbmraw direct because of this, but
> the clist wrapping defeats our detection. This results in an
> error.
> Tests enabling copy_alpha for pbmraw show a degredation in render
> quality, so instead, we just disable all imagemask interpolation
> when going to halftone devices.
> base/gxiscale.c

2016-02-24 15:56:23 +0000
Robin Watts <Robin.Watts@artifex.com>
036710b85c9e1b08ea0c0c7d5e2ad0734a1460eb

> Add some 'sanitize' targets to the Makefile
> These build with address sanitizer enabled.
> These hackily set the '-i' flag in the recursive calls to make
> to sidestep the problems with genconf/mkromfs leaking at the
> moment. These issues will be fixed and the -i removed.
> Makefile.in
> base/unix-end.mak

2016-02-24 17:51:29 +0000
Robin Watts <Robin.Watts@artifex.com>
dd65a40fa66835646972b665f352498c696557a1

> Bug 696609: Fix operation in non 24bpp modes.
> I had the depth checks in blank_unmasked_pixels wrong.
> base/gxpcmap.c

2016-02-24 16:34:35 +0000
Robin Watts <Robin.Watts@artifex.com>
1386dbd1ad0bef6b6264e198162d0b7c9abfce54

> Bug 696603: Quieten address sanitiser.
> mem_mono_copy_mono includes some clever code that reads
> 16 bits at a time and shifts to do fast mono copies of
> unaligned data. This can result in overreading the end
> of data by a byte, but never so far as to cause address
> overflows due to the granularity at which data can be
> allocated.
> The 'overread' data is never actually used.
> The simple fix here just extends the source block by
> a byte to avoid error sanitizer complaining. Valgrind
> correctly does not flag this.
> pcl/pcl/pcbiptrn.c

2016-02-24 13:45:20 +0000
Robin Watts <robin.watts@artifex.com>
628f3de2f47e46d2b56fa9f6bfd7b7a479d8b10e

> Bug 699613: gs leaves temp files in GS_NO_UTF8 windows builds.
> Adopt Cecil Hornbakers patch to solve this. Many thanks!
> base/gp_mswin.c

2016-02-24 12:30:28 +0000
Robin Watts <robin.watts@artifex.com>
8fa7be62354e783551661cbda24b56deb3e67f1f

> Remove unused variables/conditions from gdevpdf.c
> Spotted while debugging bug 696612.
> Various places in the code do:
> { int j, code = 0;
> for (j = 0; j < n && code >= 0; j++)
> {
> STUFF
> }
> }
> which is a perfectly reasonable thing to do - except for the
> facts that: 1) STUFF never alters the value of code, and 2) even
> if STUFF did alter the value of code, we never check the value
> and return it.
> Accordingly, I've just removed the references to code.
> devices/vector/gdevpdf.c

2016-02-24 12:31:17 +0000
Robin Watts <robin.watts@artifex.com>
e2a848f1157fdecab41165ac790394202e13d9d0

> Bug 696612: Swallow rangecheck errors in psf_check_outline_glyphs
> At the closedown of the file, we run through and write out fonts.
> As part of this process, we check the glyphs in the font. If any
> of the glyphs come back as bad, we abort the whole process.
> Previously we ignored any errors here, and my change to make us
> not ignore errors in the pdf_close routine caused this regression.
> After discussion with Ken and Chris, the correct fix, I believe,
> is to continue to catch and honour all errors in pdf_close, but
> to explicitly swallow certain errors lower down.
> Chris suggested, and I agree with him, that simply swallowing
> the rangecheck error in psf_check_outline_glyphs would be an
> acceptable fix (for now at least).
> I am leaving the bug open and passing it to Ken so that he can
> double check this area in more detail at his convenience.
> devices/vector/gdevpsfu.c

2016-02-23 19:53:31 +0000
Robin Watts <robin.watts@artifex.com>
636bb0bce0ece581f3004915e2c10c79c00439eb

> Bug 695180: Maintain antialias levels into pdf14 devices.
> When creating a pdf14 device, ensure that the antialias level
> of the pdf14 device matches that of the underlying device.
> This prevents antialiasing getting lost when the clist kicks
> in for transparency.
> base/gdevp14.c

2016-02-23 18:57:28 +0000
Robin Watts <Robin.Watts@artifex.com>
b85daf6bdb43c09fe92ac9c319c9fea5b012989a

> Bug696540: Fix pattern accumulator initialisation
> When we create a pattern accumulator the bitmap contents are
> initially undefined. We then draw a rectangle over them to set
> them to known values.
> Unfortunately the code that writes this bitmap does not check
> for the ctm being sane, so in some cases the initialisation
> can fail.
> This shows up as indeterminisms in the alpha blending.
> The simple fix is to set the ctm to the identity matrix before
> rendering.
> base/gxpcmap.c

2015-12-28 17:35:10 +0000
Robin Watts <Robin.Watts@artifex.com>
7aed42f6e9f1f0bf09dde46d7004d517faed0d2e

> Fix potential valgrind warning.
> We don't have an example file for this, but this was spotted
> during investigations into Bug 693784.
> We can overrun by 1 pixel for odd length rows. When we overrun
> we read the lower 4 bits of a byte, and those may be undefined.
> Simply make PACIFY_VALGRIND blank these bits before we start.
> devices/gdevpbm.c

2016-02-23 14:59:25 +0000
Robin Watts <robin.watts@artifex.com>
89f02bdede0a2a46ee8937e6138b0f8905b524f5

> Bug 696609: Fix x11alpha regressions.
> The changes to pattern_accum_get_bits_rectangle were causing
> a lack of output.
> This was due to the call to the underlying get_bits_rectangle
> returning with a pointer to the data (rather than supplying
> a copy of it). The blank_unmasked_bits call would then fail
> as it could not alter the underlying data safely.
> The fix is simply to remove the bit that allows a copy of the
> data to be submitted from the options before calling, thus
> ensuring that we can operate on a copy.
> base/gxpcmap.c

2016-02-22 09:09:50 +0000
Ken Sharp <ken.sharp@artifex.com>
ece091d02c69174fb96dc6b02df9e30f9c964461

> pdfwrite - fix a colour conversion crash
> Discovered while working on an unrelated problem. If we had set the
> CompatibilityLevel to < 1.3 and encountered a CIEBased colour space in
> the input file, then we unconditionally return a 'convert' result
> because we cannot embed an ICC profile in such an old PDF version.
> However we did not update the 'pcs_orig' argument, and later tried to
> use it, resulting in a NULL dereference.
> No differences expected.
> devices/vector/gdevpdfi.c

2016-02-19 09:29:58 +0000
Robin Watts <robin.watts@artifex.com>
e636c3958126201c858d394d05c135bcd90cf3df

> Avoid another undefined data return case.
> Attempting to getbits from any pattern accumulator without a
> color plane cannot work. Give an error.
> base/gxpcmap.c

2016-02-19 09:29:51 +0000
Robin Watts <robin.watts@artifex.com>
c480ef1b2d0a9ede3df1d6fc64e6f305e378d3d7

> Fix possible undefined variable access.
> I messed this up while refactoring.
> base/gxpcmap.c

2016-02-18 19:37:05 +0000
Robin Watts <robin.watts@artifex.com>
cc6adc3f223ac00778e6236b687ab624cadb4445

> Ensure pattern_accumulator_get_bits returns defined values.
> When reading bits from the pattern_accumulator, if it has a mask
> then blank the masked bits as otherwise the values are undefined.
> base/gxpcmap.c

2016-02-18 17:33:18 +0000
Robin Watts <robin.watts@artifex.com>
f63ceefb7fc70cc7ccce9e4ae4221c5b5ca00100

> Update Acrobat2Tiff to hopefully work with 10/11/DC too.
> toolbin/Acrobat2Tiff/Acrobat2Tiff/Acrobat2Tiff.vb

2016-02-18 16:31:31 +0000
Robin Watts <robin.watts@artifex.com>
9bb42182c7637e11bc2939fb359ab79365594202

> Update devices to return errors using return_error.
> contrib/gdevcd8.c
> contrib/gdevdj9.c
> contrib/gomni.c
> contrib/japanese/gdevdmpr.c
> devices/gdevcdj.c
> devices/gdevcmykog.c
> devices/gdevfpng.c
> devices/gdevmac.c
> devices/gdevmac.h
> devices/gdevmswn.c
> devices/gdevmsxf.c
> devices/gdevos2p.c
> devices/gdevpng.c
> devices/gdevsvga.c
> devices/gdevtifs.c
> devices/gdevtsep.c
> devices/gdevupd.c
> devices/gdevwddb.c
> devices/gdevwdib.c
> devices/gdevwpr2.c
> devices/gdevwprn.c
> devices/gxfcopy.c
> devices/vector/gdevpdf.c
> devices/vector/gdevpdfg.c
> devices/vector/gdevpdfi.c
> devices/vector/gdevpdfm.c
> devices/vector/gdevpdfo.c
> devices/vector/gdevpdfr.c
> devices/vector/gdevpdfu.c
> devices/vector/gdevpdfx.h
> devices/vector/gdevpdtc.c
> devices/vector/gdevpdte.c
> devices/vector/gdevpdtt.c
> devices/vector/gdevpsdi.c
> devices/vector/gdevpsdp.c
> devices/vector/gdevpsf1.c
> devices/vector/gdevpsf2.c
> devices/vector/gdevtxtw.c

2016-02-17 17:50:19 +0000
Robin Watts <robin.watts@artifex.com>
c00965e4c05f08ec000303d53942e846187eed1a

> Improve logability of errors.
> Ensure that we always return_error(gs_error_blah) rather than just
> return gs_error_blah.
> base/fapi_ft.c
> base/fapibstm.c
> base/fapiufst.c
> base/gdevabuf.c
> base/gdevdbit.c
> base/gdevdflt.c
> base/gdevdrop.c
> base/gdevm24.c
> base/gdevnfwd.c
> base/gdevp14.c
> base/gdevprn.c
> base/gdevsclass.c
> base/gdevvec.c
> base/gp_mswin.c
> base/gp_wsync.c
> base/gsargs.c
> base/gsdparam.c
> base/gsfunc0.c
> base/gsicc_cache.c
> base/gsicc_lcms2.c
> base/gsicc_manage.c
> base/gsiodisk.c
> base/gsioram.c
> base/gsiorom.c
> base/gslibctx.c
> base/gsovrc.c
> base/gxccman.c
> base/gxcht.c
> base/gxclthrd.c
> base/gxcmap.c
> base/gxdhtserial.c
> base/gxdownscale.c
> base/gxht.c
> base/gxpageq.c
> base/gxshade.c
> base/sjbig2_luratech.c
> base/sjpegc.c
> base/sjpx_luratech.c

2016-02-18 16:15:33 +0000
Robin Watts <robin.watts@artifex.com>
18af3c05dc3774512529436fd41d953fa24b34f8

> Avoid interpolating imagemasks in pattern accumulators.
> To interpolate imagemasks, we need to do a copy_alpha operation.
> These are impossible to do well on a pattern accumulator due to
> the 1bpp alpha plane.
> As such the best thing we can do is to sidestep the problem.
> base/gxipixel.c
> base/gxpcmap.c

2016-02-17 16:23:40 +0000
Robin Watts <robin.watts@artifex.com>
a08a24751a672a21972d3888d651dacae054888e

> MSVC Solution: Add gdevsclass.{c,h} to the solution.
> windows/ghostscript.vcproj

2016-02-18 10:49:11 +0000
Ken Sharp <ken.sharp@artifex.com>
ccca669b1a1bf97fc1b778dd6f768b3a71d9dfbc

> Silence a compiler warning
> accidentally left a debugging variable in place
> devices/vector/gdevpdfg.c

2016-02-18 10:29:58 +0000
Ken Sharp <ken.sharp@artifex.com>
32e721e9e4c21f0a843ada824d17ac465f21ac4b

> pdfwrite - don't render shadings if we don't need to convert base space
> Bug #690125 "Gradient / Fill Pattern Conversion Issues"
> Since the change to ICC colour management, the check to see whether we
> could support the base space of a shading was incorrect, it checked the
> strategy against 'ICC' instead of the real base space of the pattern.
> This change checks the actual base space of the pattern before deciding
> whether we can handle it.
> Although this 'fixes' this bug its not the whole story, I want to alter
> the functions so that they can be sampled and generate a different colour
> space if we are doing colour conversion, rather than rendering the
> shading.
> No differences expected.
> devices/vector/gdevpdfg.c

2016-02-17 11:30:34 -0700
Henry Stiles <henry.stiles@artifex.com>
19755c9a944bc257c936345742e3dc18703ca17f

> Bug #696592 Macro and duplex state interaction.
> The duplex page state was not being properly maintained during overlay
> macro execution. Thanks to Norbert Janssen for discovering and
> analyzing this problem.
> pcl/pcl/pcjob.c

2016-02-16 18:03:30 +0000
Robin Watts <robin.watts@artifex.com>
80f7b13626dbf60275a8ea2d4ae16336832cfec5

> Further indeterminism fixes for halftoning.
> Yesterday I changed the halftone code to calculate the dest_width
> etc from the bresenham. Now it turns out that the bresenham is
> tweaked slightly in some cases, so that the 2 places where it
> was being used to calculate dest_width were still getting
> different results.
> This commit rearranges the code so that the same bresenham values
> are used consistently, and so should give us proper matches.
> base/gxht_thresh.c
> base/gxicolor.c
> base/gximono.c

2016-02-16 17:09:14 +0000
Robin Watts <robin.watts@artifex.com>
d282b4d03e8dacfea9efb2867cc8cedb2f154a0f

> Bug 696594: Fix timeouts in cluster.
> Thanks to Ken for spotting this one.
> I'd neglected to update x in the landscape code, resulting in
> infinite loops.
> base/gxiscale.c

2016-02-16 12:07:03 +0000
Ken Sharp <ken.sharp@artifex.com>
1a7c20c004643d38b3eb8fb9898927c351a7a63d

> pdfwrite - force non-Identity CMap emission when creating PDF/A
> Bug #696547 "Converting to PDF/A using -dPDFACompatibilityPolicy=2 returns without error but produces invalid PDF/A files"
> The third and (so far) final bug in this collection.
> PDF/A mandates that all CMaps except Identity-H and Identity-V must be
> embedded in the PDF file. Previously we were not doing that for the
> 'standard' CMaps.
> This commit forces the emission of all CMaps except Identity ones when
> producing PDF/A output.
> No differences expected
> devices/vector/gdevpdtc.c

2016-02-15 19:31:33 +0000
Robin Watts <robin.watts@artifex.com>
656b19ddd19772c5c3fd40817d6532c853494d68

> Fix unused variable.
> Leftover from previous code rework.
> base/gxht_thresh.c

2016-02-15 18:15:12 +0000
Robin Watts <robin.watts@artifex.com>
92b88a1aefcd3410d8378bac8e92122622b7c80a

> MSVC: Add targets for debugging.
> Add output paths to the projects so that the debugger knows where
> to find the executable for each different build configuration.
> windows/ghostpcl.vcproj
> windows/ghostpdl.vcproj
> windows/ghostxps.vcproj

2016-02-15 16:57:46 +0000
Robin Watts <robin.watts@artifex.com>
4a8525ca93d7be6091f38ee68f4dbefa540158fa

> Bug 696323: Fix indeterminism in thresholding code.
> The thresholding code calculates the destination width of the
> image lines in one way, then fills the data based on the
> bresenham. It is possible for the destination width calculated
> to not match that given by the bresenham, in which case
> undefined data can be plotted.
> The fix here is simply to calculate the destination width from
> the bresenham, so it will exactly match the actual data we get.
> base/gxht_thresh.c
> base/gxht_thresh.h
> base/gxicolor.c
> base/gximono.c

2016-02-15 15:08:38 +0000
Robin Watts <robin.watts@artifex.com>
0d66d291c29a7c34a4ba32060af7e9f4f1870a6c

> Add "NoInterpolateImagemasks" device param.
> Rather than relying on the 'HighLevelDevice' device param, instead
> look at a new 'NoInterpolateImagemasks' param.
> base/gdevvec.c
> base/gxiscale.c

2016-02-12 14:12:41 +0000
Robin Watts <robin.watts@artifex.com>
5a9269c17c036606f13f257f7ee5580a3a191530

> Bug 696132: Reapply previous work.
> Previous commits in this area went in piecemeal and caused lots of
> diffs which were then fixed etc. By committing here in one go, we
> hope to get saner results from the tests which we can have more
> confidence in.
> A summary of the changes:
> 1) Introduce a mechanism so that we can know whether we are in
> a pattern accumulator or not.
> 2) When plotting an othogonal image use that mechanism to detect
> whether we are in a pattern accumulator. If we are, then grid
> fit the image.
> 3) If we are in a pattern accumulator and we are downscaling an
> image, then interpolate it. This avoids nasty dropouts with
> halftoned images that can (due to nearest neighbour plotting)
> suddenly change massively in appearance.
> base/gxdevsop.h
> base/gxipixel.c
> base/gxpcmap.c

2016-02-15 15:22:46 +0000
Ken Sharp <ken.sharp@artifex.com>
2959218b70dcb95765e458073195b4a9baa65be9

> graphics library - make vector devices implement the correct spec_op handler
> Devices based on gdevvec were not properly having the spec_op method
> assigned to the gdevvec spec_op handler if the device didn't handle
> spec_op itself.
> Ideally this would be done by having the device prototype being fully
> populated, but the number of device methods makes that impractical.
> Instead, if the method is NULL or the gx_default method, replace it
> with the gdevvec one.
> This already works for devices based on gdevprn as a simlar hack is
> performed in gx_default_create_buf_device
> No differences expected
> base/gdevvec.c

2016-02-15 10:21:57 +0000
Ken Sharp <ken.sharp@artifex.com>
343e3ed65423135a1f25ba1b5d52f45707c17c70

> documentation - make it clearer the NumRenderingThreads has no effect on pdfwrite
> Unfortunately nothing can be done about the 'cargo cult' approach to
> command line parameters which most people seem to use, but we should try
> and make it clear in the documentation, on the off-chance that someone
> actually reads it.
> doc/Language.htm
> doc/Use.htm

2016-02-12 10:14:50 -0800
Ray Johnston <ray.johnston@artifex.com>
38e501dcddb6a15e9d2e41ae534d398942f9e839

> Move Acrobat2TIFF from pcl/tools to toolbin (it is not PCL related)
> pcl/tools/Acrobat2Tiff/Acrobat2Tiff.sln
> pcl/tools/Acrobat2Tiff/Acrobat2Tiff/Acrobat2Tiff.vb
> pcl/tools/Acrobat2Tiff/Acrobat2Tiff/Acrobat2Tiff.vbproj
> pcl/tools/Acrobat2Tiff/Acrobat2Tiff/Acrobat2Tiff/Application.Designer.vb
> pcl/tools/Acrobat2Tiff/Acrobat2Tiff/Acrobat2Tiff/Application.myapp
> pcl/tools/Acrobat2Tiff/Acrobat2Tiff/Acrobat2Tiff/AssemblyInfo.vb
> pcl/tools/Acrobat2Tiff/Acrobat2Tiff/Acrobat2Tiff/Resources.Designer.vb
> pcl/tools/Acrobat2Tiff/Acrobat2Tiff/Acrobat2Tiff/Resources.resx
> pcl/tools/Acrobat2Tiff/Acrobat2Tiff/Acrobat2Tiff/Settings.Designer.vb
> pcl/tools/Acrobat2Tiff/Acrobat2Tiff/Acrobat2Tiff/Settings.settings
> pcl/tools/Acrobat2Tiff/Acrobat2Tiff/bin/Release/Acrobat2Tiff.exe
> pcl/tools/Acrobat2Tiff/Acrobat2Tiff/bin/Release/Acrobat2Tiff.vshost.exe
> pcl/tools/Acrobat2Tiff/Acrobat2Tiff/bin/Release/Acrobat2Tiff.xml
> pcl/tools/Acrobat2Tiff/Acrobat2Tiff/bin/Release/Interop.Acrobat.dll
> toolbin/Acrobat2Tiff/Acrobat2Tiff.sln
> toolbin/Acrobat2Tiff/Acrobat2Tiff/Acrobat2Tiff.vb
> toolbin/Acrobat2Tiff/Acrobat2Tiff/Acrobat2Tiff.vbproj
> toolbin/Acrobat2Tiff/Acrobat2Tiff/Acrobat2Tiff/Application.Designer.vb
> toolbin/Acrobat2Tiff/Acrobat2Tiff/Acrobat2Tiff/Application.myapp
> toolbin/Acrobat2Tiff/Acrobat2Tiff/Acrobat2Tiff/AssemblyInfo.vb
> toolbin/Acrobat2Tiff/Acrobat2Tiff/Acrobat2Tiff/Resources.Designer.vb
> toolbin/Acrobat2Tiff/Acrobat2Tiff/Acrobat2Tiff/Resources.resx
> toolbin/Acrobat2Tiff/Acrobat2Tiff/Acrobat2Tiff/Settings.Designer.vb
> toolbin/Acrobat2Tiff/Acrobat2Tiff/Acrobat2Tiff/Settings.settings
> toolbin/Acrobat2Tiff/Acrobat2Tiff/bin/Release/Acrobat2Tiff.exe
> toolbin/Acrobat2Tiff/Acrobat2Tiff/bin/Release/Acrobat2Tiff.vshost.exe
> toolbin/Acrobat2Tiff/Acrobat2Tiff/bin/Release/Acrobat2Tiff.xml
> toolbin/Acrobat2Tiff/Acrobat2Tiff/bin/Release/Interop.Acrobat.dll

2016-02-07 09:07:53 -0800
Ray Johnston <ray.johnston@artifex.com>
5c83e97e4c1216d7e3f67c7001a2513b0c1b9b45

> Remove OMIT_SAVED_PAGES_TEST that was left in plmain when removed from gs
> pcl/pl/plmain.c

2016-02-12 14:04:11 +0000
Robin Watts <robin.watts@artifex.com>
6c080667d88ba604a7033da1e507e2c39fa0fca2

> Revert Bug 696132 work, in order to start from scratch.
> Revert:
> 1) "Bug 696132/696572: Continued "pattern gap" work - interpolate"
> commit 80693d83612e03b26a5006b74296c6e9f11779da.
> 2) "Bug 696132/696572: Continued "pattern gap" work - tidying."
> commit 1b843b1a6adca2f0245af8049b7c5d6d8f00ae5d.
> 3) "Fix gridfitting images being too greedy."
> commit c902d4d4ba62306aa59cd30c3f450af5ad7bf797.
> 4) "Bug 696132: Grid fit images within pattern fills."
> commit 6b04051b251d7dbde9a2e6f170cac9dc7950e20e.
> After this I can reintroduce the commits and get (hopefully)
> cleaner testing data.
> base/gxdevsop.h
> base/gxipixel.c
> base/gxpcmap.c

2016-02-12 13:49:17 +0000
Ken Sharp <ken.sharp@artifex.com>
a44fff01232a1ae6c7200a403a132d860c2de718

> pdfwrite - disallow Launch Actions in annotations when creating PDF/A
> Bug #696547 "Converting to PDF/A using -dPDFACompatibilityPolicy=2 returns without error but produces invalid PDF/A files"
> Another part of this bug. PDF/A does not permit Launch actions for
> annotations, if we get one, and we are emitting PDF/A, consult the
> CompatibilityPolicy and take appropriate action.
> devices/vector/gdevpdfm.c

2016-02-12 13:48:06 +0000
Ken Sharp <ken.sharp@artifex.com>
1d83aa202383cfccdcf83a80f728106bf19267dd

> pdfwrite - disallow missing glyphs in CIDFonts when creating PDF/A
> Bug #696547 "Converting to PDF/A using -dPDFACompatibilityPolicy=2 returns without error but produces invalid PDF/A files"
> One part of this bug. PDF/A insists that all fonts be embedded, and
> all glyphs used from that font are present. If we detect a condition
> where that is not the case, and we are emitting PDF/A consult the
> CompatibilityPolicy and take appropriate action.
> devices/vector/gdevpdtc.c

2016-02-12 13:45:43 +0000
Ken Sharp <ken.sharp@artifex.com>
9df72d93fbe869b44a566911bdf81d2aefc3ac79

> Documentation - fix an incorrect example and make usage a little clearer
> doc/VectorDevices.htm

2016-02-12 11:44:41 +0000
Chris Liddell <chris.liddell@artifex.com>
b7d67a3b885f86c23d731f2bff77e16d73e1dc39

> Fix CompatibilityLevel typo in man pages
> The man pages listed -dCompatibility instead of -dCompatibilityLevel
> man/de/ps2pdf.1
> man/ps2pdf.1

2016-02-12 11:41:10 +0000
Chris Liddell <chris.liddell@artifex.com>
7f32dc0df826defdd20f8cd493ce795e0c73b83a

> Add documentation for the inkcov device.
> Credit to Jonas Smedegaard <dr@jones.dk>
> doc/Devices.htm

2016-02-12 10:57:35 +0000
Chris Liddell <chris.liddell@artifex.com>
3340d723e22500fd10c05ac113d7f5532a1ea762

> Bug 696586 (2): Clean up some leftovers in my previous commit
> base/openjpeg.mak

2016-02-12 09:01:20 +0000
Chris Liddell <chris.liddell@artifex.com>
4ca1d9d7a6a5cea50e1bb3a562b2b5c79d640c0c

> Bug 696585: Fix jpeg, tiff and cups shared lib builds
> Some more overzealous dependencies removed.
> Mostly, credit to Jonas Smedegaard <dr@jones.dk>, plus some tweaks of my own
> base/jpegxr.mak
> base/lcups.mak
> base/lcupsi.mak
> base/tiff.mak

2016-02-12 08:51:09 +0000
Chris Liddell <chris.liddell@artifex.com>
cf6f31c177fb36b3a706c80da4c003d009fbe2af

> Bug 696586: support shared OpenJPEG lib
> There was a halfhearted attempt there already, do it properly.
> Makefile.in
> base/openjpeg.mak
> configure.ac

2016-02-11 12:08:13 +0000
Robin Watts <robin.watts@artifex.com>
80693d83612e03b26a5006b74296c6e9f11779da

> Bug 696132/696572: Continued "pattern gap" work - interpolate
> Marcos reports (in bug 696572) that many files have problems
> after the commit done for bug 696132. That commit was intended to
> cause all orthogonal images within a pattern to be gridfitted.
> Due to a mistake, this actually caused all orthogonal images
> ANYWHERE to be gridfitted. That bug was fixed a few commits
> ago (c902d4d).
> Having fixed that, so we now operate as originally intended
> we still have some problems showing. These (in the cases tested
> at least) appear to be due to the radically different renderings
> given of images when they are very slightly permuted. This is
> because when images are being rendered at a smaller size
> than their source, dropouts occur.
> A classic example of this might be an image of the form:
> * * * * * *
> * * * * *
> * * * * * *
> * * * * *
> which is used as a pattern to give a halftone efferct.
> When downscaled, this is very sensitive to dropouts; we can easily
> get solid black or white out of such images. Using interpolation
> gives a truer rendition of the intended output.
> This commit spots such downscales of gridfitted images within
> pattern accumulators and forces interpolation on for them.
> base/gxipixel.c

2016-02-11 12:08:23 +0000
Robin Watts <robin.watts@artifex.com>
1b843b1a6adca2f0245af8049b7c5d6d8f00ae5d

> Bug 696132/696572: Continued "pattern gap" work - tidying.
> Rejig the existing code slightly to make it more readable.
> No functional changes, just clearer code.
> base/gxdevsop.h
> base/gxipixel.c
> base/gxpcmap.c

2016-02-11 16:56:23 +0000
Ken Sharp <ken.sharp@artifex.com>
710d030617a586c5b9bbc105dd3054e467112f47

> PDF interpreter - allow the operand stack to gro without limit
> Bug #696567 "Error reading PDF file: /stackunderflow in --run--"
> The file has a page with an outrageous number of ExtGStates on it,
> 447000, many (possibly all) of which do not contain any actual gstate.
> This was causing a stackoverflow because the maximummoperand stack
> size was set at 300,000. This commit builds on the code for
> Bug #696487 (from the same customer) and enables the operand stack to
> grow without limit when interpreting PDF files.
> Of course, the page is still stupidly slow.
> No differences expected.
> Resource/Init/pdf_main.ps

2016-02-11 12:06:28 +0000
Ken Sharp <ken.sharp@artifex.com>
d781291c9acb4eb30bf4920882c23b03fa445a2b

> pdfwrite - don't emit an empty clip
> Bug #696566 "Regression: acrobat cannot open ghostscript generated pdf file starting with b56ff42047f6df6e7c74a79b91cd7d193bfa7357"
> This appears to be a weird bug in Acrobat. If we had a PostScript file
> which did the equivalent of 'clip newpath clip' then we could end up
> writing the same equivalent to the PDF file as 'W n W n'. Under some
> (and only some) conditions, depending apparently on what operation
> followed the clip, Acrobat would throw a fit on this and stop.
> No other PDF consumer seems to be bothered by this, and indeed if we
> alter the PDF contents slightly Acrobat isn't bothered either.
> Since I cannot determine exactly what Acrobat is complaining about, and
> since the empty clip makes no real sense anyway, I've added code which
> detects an empty path and doesn't bother to write the clip (W) operator.
> This seems to pacify Acrobat, but I can't guarantee that other degenerate
> paths won't cause similar problems.
> No differences expected.
> devices/vector/gdevpdfd.c

2016-02-10 21:07:57 +0000
Robin Watts <robin.watts@artifex.com>
c902d4d4ba62306aa59cd30c3f450af5ad7bf797

> Fix gridfitting images being too greedy.
> Devices that don't understand a gxdso will return -1, which we
> were incorrectly reading as meaning "gridfit this image".
> base/gxipixel.c

2016-02-10 15:57:02 +0000
Ken Sharp <ken.sharp@artifex.com>
393e7a835a375b32bf06e8eec4ef89cd2c333d99

> PDF interpreter - handle Xref stream with incorrect length
> Bug 696560 "Error reading PDF file"
> The file uses compressed Xref streams (several of them in fact) and one
> of them has an incorrect length (36 instead of 34). This leads to the
> interpreter reading past the end of the stream and consuming the first
> two bytes of the following token, so instead of seeing 'endstream' as
> we should, we encounter 'dstream'.
> We already have code which attempts to detect and handle this condition
> but it assumes that the stream is being executed as an object, not as
> an xref, and expects the object number and generation to be on the
> stack, which they are not when we are dealing with an Xref stream.
> In this commit, when we detect such a problem we attempt to verify if
> we are dealing with an object by checking to see if the stack contains
> at least 3 objects (the stream dict, the object and generation) and that
> the second and third objects down are integers. If these conditions are
> met we end the object and execute the 'exit' operator to terminate
> the calling .pdfrun function. Otherwise we simply return with the
> dictionary on the stack, as this is what the xref code expects.
> The regression file Bug696240.pdf should now render correctly.
> Resource/Init/pdf_base.ps

2016-02-10 12:50:03 +0000
Robin Watts <robin.watts@artifex.com>
7f5ed0cde537a43fdc8bae669ffc413f39d69df8

> Detect 'impossible' code path being called.
> As part of the work towards bug 696562, we spotted a code path
> that can never be run.
> gx_alloc_char_bits is only called from one place (base/gxchar.c
> line 607). dev2 can only be non-NULL if:
> iwidth > MAX_CCACHE_TEMP_BITMAP_BITS / iheight &&
> log2_scale.x + log2_scale.y > alpha_bits
> The second half of that condition can never be true due to the
> construction of the log2_scale.{x,y} values in
> gx_compute_text_oversampling().
> Rather than rip this code out just before a release (and inevitably
> be proved wrong), we add an error in this code path. If no one
> reports it to us, we'll rip the code out later.
> base/gxccman.c

2016-02-08 17:13:35 +0000
Robin Watts <robin.watts@artifex.com>
0fb16eb72ee9136856e0a52dcb194993fced16c9

> Bug 696562: Interpolate imagemasks.
> When rendering imagemasks, we can get nasty dropout effects if we
> should be using interpolation. To fix this, we implement
> interpolation for the non-high level device case.
> We use copy_alpha (and copy_alpha_hl_color) to write the data. We
> only do this in the case of devices that don't declare themselves
> to be high-level.
> base/gxiscale.c
> devices/gdevpng.c

2016-02-09 17:12:17 +0000
Robin Watts <robin.watts@artifex.com>
71f32f8bbc9e905732293ef2c2bd0821744c1a86

> Only insert default_copy_alpha_hl_color if it can work.
> default_copy_alpha_hl_color requires underlying copy_planes and
> get_bits_rectangle methods. If the device does not provide them
> then do not add default_copy_alpha_hl_color.
> base/gdevdflt.c

2016-02-08 12:23:01 +0000
Robin Watts <robin.watts@artifex.com>
d9f041d6fe7eda89364df1424f85ace974ed0fec

> Extend copy_alpha to support 8 bit depth.
> Currently copy_alpha (and copy_alpha_hl_color) can only accept
> 2 or 4 bits of alpha data. In order for the work on bug 696562
> to proceed we need it to support 8 bits of alpha data. Extend
> the 2 default implementations here.
> Also update the docs to mention the new bit depths, and to mention
> the existence of copy_alpha_hl_color at all.
> Remove the line in the docs that claims copy_alpha will not be
> called unless get_alpha_bits returns non-1, as this will shortly
> not be true.
> base/gdevabuf.c
> base/gdevdbit.c
> base/gdevm24.c
> base/gdevp14.c
> devices/gdevpng.c
> devices/gdevsvga.c
> doc/Drivers.htm

2016-02-08 18:51:14 +0000
Robin Watts <robin.watts@artifex.com>
3c75e35b6bbadd553a074509c3d80046457dda98

> Bug 696571: Fix rangecheck in tiffscaled.
> I was putting some params that I wasn't getting (or vice versa).
> devices/gdevtifs.c

2016-02-08 17:10:42 +0000
Robin Watts <robin.watts@artifex.com>
453e8fca47db33555f86774b99cde0b429223c92

> Tidy downscaler params.
> Use ints rather than longs consistently. This should shut
> coverity up.
> base/gxdownscale.c
> base/gxdownscale.h
> devices/gdevfpng.c

2016-02-09 13:45:19 +0000
Ken Sharp <ken.sharp@artifex.com>
75a299ff71ef01d645acc744fb2248f99830e84a

> silence a couple of compiler warnings
> Check and action the return value from fread throw an ioerror if it
> failed.
> Prototype a couple of functions (this is an old warning)
> I did not remove two functions 'pjl_impl_set_envvar' and
> 'pjl_impl_set_defvar'. Although these are not used at present they
> match 'pjl_impl_get_envvar', which *is* used. It would be surprising
> to a programmer if only one accessor was defiend.
> pcl/pl/pjparse.h
> pcl/pl/plparams.c

2016-02-08 16:55:47 +0000
Robin Watts <robin.watts@artifex.com>
4b65f6276c674a9947f3c65f7d08b46c02ba0ff3

> Silence warning about unchecked return code.
> Check the return code.
> devices/gdevpsd.c

2015-09-10 10:04:23 +0100
Ken Sharp <ken.sharp@artifex.com>
d097c4624a7c23610b007aab98860d175535cb48

> PJL interpreter - add new methods to configure pdfwrite
> Bug #693117 "PCL -> PDF/A"
> Bug #693058 "There is no way to control many pdfwrite features in GhostPCL (eg AutoRotatePages)"
> Originally developed on the branch PJL_pdfwrite_config, full history
> is available on that branch.
> Added new PDFMARK and SETDISTILLERPARAMS PJL tokens which will allow
> for 'PostScript like' syntax whch can be used to configure the
> pdfwrite family of devices.
> This will allow for the production of PDF/A-1b files and also the
> control of some features which cannot be set from the command line.
> Updated the documentation, gathering all the high level devices in
> one place, split the documentation into controls based on the
> input language and the output format.
> No differences expected.
> doc/Devices.htm
> doc/Drivers.htm
> doc/Ps2pdf.htm
> doc/Ps2ps2.htm
> doc/Readme.htm
> doc/Use.htm
> doc/VectorDevices.htm
> pcl/pcl/pcjob.c
> pcl/pcl/pcl.mak
> pcl/pl/pjparse.c
> pcl/pl/pjparsei.c
> pcl/pl/pl.mak
> pcl/pl/plparams.c
> pcl/pl/plparams.h
> pcl/pxl/pxsessio.c

2016-02-08 13:55:40 +0000
Ken Sharp <ken.sharp@artifex.com>
119e73617fb0f1b20e6d3257d26df0159c4ca81a

> PDF interpreter - yet more robust error handlign with broken files
> Bug #696540 "ps2pdf fails on a file that can be opened by some other viewers"
> Two problems here.
> First, the file has been truncated and garbage written, after the startxref
> token. Previously we used the 'token' operator to try and read both the
> 'startxref' and the actual offset value. However, while executing the
> token operator we reached EOF, and this *closes* the underlying file.
> Unsurprisingly this then caused ioerrors on every subsequent operation.
> So, define a new routine 'token_no_close' which installs a SubFileDecode
> filter on top of the existing file/filter chain and reads from that. We
> explicitly set CloseSource to false so that even if we encounter EOF
> while executing the file we will only close the filter and not the
> underlying file/filter chain.
> However this then exposed a different problem when rebuilding the xref;
> we scan backwards looking for a trailer with a /Root key. But if the
> trailer was early in the file (< 64Kb), and the block reading worked
> out so that the initial block was less than 64Kb then we would calculate
> The offset to the trailer incorrectly because we assumed the block size
> was always 64Kb, which it isn't if we don't have 64Kb to read.
> No differences expected
> Resource/Init/pdf_main.ps
> Resource/Init/pdf_rbld.ps

2016-02-03 12:48:07 +0000
Robin Watts <robin.watts@artifex.com>
15f8b6ce6d7ae574d7803bb19d2f5cec474f087b

> Disable trapping by default.
> Build with ENABLE_TRAPPING to reenable it. Add explanation and
> warnings to doc/Devices.htm.
> base/gxdownscale.c
> doc/Devices.htm

2016-02-01 17:22:53 +0000
Robin Watts <robin.watts@artifex.com>
afc7e2cfb9544a8cebd8abb0d89e02429ad98f7d

> Reduce boilerplate downscaler params handling.
> The same sets of parameters (or subsets thereof) are read/
> written in many devices get/put_params routines to control
> the downscaler.
> Arrange to read/write these all in one place to keep the
> code simpler.
> base/gxdownscale.c
> base/gxdownscale.h
> devices/gdevfpng.c
> devices/gdevgprf.c
> devices/gdevpng.c
> devices/gdevpsd.c
> devices/gdevtfnx.c
> devices/gdevtifs.c
> devices/gdevtifs.h
> devices/gdevtsep.c

2016-01-29 19:06:22 +0000
Robin Watts <robin.watts@artifex.com>
afbffabc7bf3593d3de5a210899e364371807c66

> Simple optimisations to ClapTrap.
> base/claptrap-init.c
> base/claptrap-planar.c
> base/claptrap.c

2016-01-28 11:33:52 +0000
Robin Watts <robin.watts@artifex.com>
049ba9c4de3514452e4bd3b6601c20e1d22188fd

> Initial import of ClapTrap.
> Hooked in under the downscaler, so accessible to any device that
> calls the downscaler without too many changes.
> Only enabled for CMYK devices, so tiffscaled32, tiffsep and
> psdcmyk.
> -dTrapX and -dTrapY set the horizontal and vertical search areas.
> Use 0 for off, otherwise n searches +/- n either side.
> TrapOrder sets the cmyk spot ordering from darkest to lightest.
> For CMYK, default is [ 3 1 0 2 ] (K, M, C, Y).
> For CMYK and spots, default is [ 3 1 0 2 4 5 6 7 ... ]. This
> will be wrong if spots aren't arranged in darkest to lightest order.
> A typical command line might look like:
> gs -sDEVICE=tiffsep -dTrapX=2 -dTrapY=2 -o out.tif
> -c "<< /TrapOrder [ 3 1 0 2 ] setpagedevice >>"
> -f examples/tiger.eps
> base/claptrap-impl.h
> base/claptrap-init.c
> base/claptrap-planar.c
> base/claptrap.c
> base/claptrap.h
> base/gxdownscale.c
> base/gxdownscale.h
> base/lib.mak
> devices/gdevpsd.c
> devices/gdevtifs.c
> devices/gdevtifs.h
> devices/gdevtsep.c
> doc/Devices.htm
> windows/ghostscript.vcproj

2016-02-03 19:08:46 +0000
Robin Watts <robin.watts@artifex.com>
6b04051b251d7dbde9a2e6f170cac9dc7950e20e

> Bug 696132: Grid fit images within pattern fills.
> To avoid white lines appearing between pattern fills, grid fit
> images whenever they appear within such fills.
> Gridfitting involves stretching any axis aligned image to
> completely cover the pixels it touches.
> The vast majority of this patch is to do with detecting that
> we are in a pattern accumulation device in a nice way (allowing
> for the possibilities of pdf14 accumulators etc).
> base/gxdevsop.h
> base/gxipixel.c
> base/gxpcmap.c

2016-02-05 10:31:10 +0000
Ken Sharp <ken.sharp@artifex.com>
de6cead970c7aebdca0c49d841bb94897f02102d

> PDF interpreter - move a device name check into a parameter check
> Bug #696568 "Treatment of page labels"
> Previously we were checking against the device being pdfwrite before
> processing page labels, because these require special handling. This
> stops it working with the DejaVu device (which I wasn't previously
> aware of) so instead we use the current method of checking a device
> parameter to see if the device wants to be given the Page Labels.
> Because the pdfmark syntax apparently cannot handle the range of
> possible schemes for PageLabels (see bug #692901) we don't handle
> PageLabels as pdfmarks, but instead as a specific device parameter.
> We won't change this unless someone can show conclusively that the
> pdfmark syntax can handle all possible formats for PageLabels.
> No differences expected
> Resource/Init/pdf_main.ps
> devices/vector/gdevpdfb.h
> devices/vector/gdevpdfp.c
> devices/vector/gdevpdfx.h

2016-02-04 08:02:33 +0000
Chris Liddell <chris.liddell@artifex.com>
25717bc03607476d3fa3a4f26a852c8064fe31c4

> Bug 696565: remove spurious deps for shared lcms, cups and jpeg
> When I added a load of missing dependencies, I was over zealous and added some
> depedencies to some of the shared library builds that are only relevant to the
> non-shared library cases.
> base/jpegxr.mak
> base/lcms2.mak
> base/lcups.mak
> base/lcupsi.mak

2016-02-03 09:07:57 +0000
Chris Liddell <chris.liddell@artifex.com>
8a3b3487d4946e0b66388c2602d70a5ed45193ff

> Don't use stack allocation for text enum
> Text (and show) enumeators can no longer be safely allocated on the stack since
> we need the memory manager's metadata to check the type (show or text) we're
> dealing with (to correctly handle an error condition without crashing).
> base/gstext.c
> base/gxtext.h
> pcl/pl/plfapi.c

2016-02-01 11:57:38 +0000
Chris Liddell <chris.liddell@artifex.com>
f8e77523b98f0e95e0d93fa282d6955f8f537eea

> Bug 696516: tiffsep(1) validation of compression method
> Use a meaningful value of bits-per-component to validate the compression setting
> for tiffsep and tiffsep1.
> Since both those devices ignore the device BitsPerComponent setting, we cannot
> rely on that, so check explicitly for tiffsep or tiffsep1 and use an
> appropriate bpc value depending which is in force.
> Also, change the comment on the default tiffsep(1) device(s) BitsPerComponent
> value from "Not used" to "Ignored" which is more accurate, since bpc can and
> does change, but has no effect on those two devices.
> devices/gdevtsep.c

2016-02-03 11:56:00 +0000
Robin Watts <robin.watts@artifex.com>
5c1ae7a77f19ff3e7521a80c276335e473ba2b60

> VS2015: Workaround apparent C runtime bug.
> The behaviour of _read appears to have changed in VS2015 in
> a way that is contrary to the documentation. If a _read call
> is given a single "return" keypress, it puts \n in the buffer
> but returns 0 as the number of things read.
> This, according to the documentation means 'EOF'. We therefore
> have some sneaky code to guess when it's lying to us.
> psi/dwmainc.c

2016-02-02 15:10:21 +0000
Robin Watts <robin.watts@artifex.com>
57df4f3b0234e4231f024b53e0428ead17e95c3c

> VS2015 builds: Tweak to fix bool problems.
> Always include windows_.h first, wherever we include it.
> This gets the windows definition of 'bool' in, and we can then
> override it with our own.
> base/gp_mswin.c
> base/gp_ntfs.c
> base/gp_win32.c
> base/gp_wsync.c
> base/gsicc_monitorcm.c
> base/gstype42.c
> base/stdpre.h
> devices/gdevmswn.h
> devices/gdevmsxf.c
> devices/gdevwpr2.c
> psi/msvc.mak
> psi/zwinutf8.c

2016-02-02 10:27:05 +0000
Ken Sharp <ken.sharp@artifex.com>
bb799fa99685fc9cd0177242a5f923180eda135c

> Revert and fix commit a7655b5d2fc42217eac71efd01f22fe3cca33d4a
> In the previous commit I misunderstood the return value meanings from
> s_DCT_byte_params leading to an incorrect default (and causing many
> diffs)
> This commit properly sets the return value so that, if the key is not
> found we use the correct default.
> Again, lots of diffs expected here.
> base/sdcparam.c

2016-02-01 15:51:05 +0000
Ken Sharp <ken.sharp@artifex.com>
a7655b5d2fc42217eac71efd01f22fe3cca33d4a

> PS interpreter - further fix for DCTEncode params arrays
> commit 96f79a46a559af75995bf021cc85438c99509bbb missed the fact that,
> when a parameter is returned from parameter processing we need to
> return a positive code > 0, otherwise the caller assumes that there was
> no error, but no key found either.
> This actually makes the HSamples, VSamples and QuantTables work for
> the DCTEncode filter.
> This causes a *very* large number of diffs, because the pdfwrite (and
> ps2write) devices now actually use the parameters defined for these values
> resulting in small differences in DCT (JPEG) output.
> Also the Quality Logic test 23-12E.ps tests this feature and now shows
> a difference.
> base/sdcparam.c

2016-01-29 13:51:02 +0000
Chris Liddell <chris.liddell@artifex.com>
b826c1774a0b89e237590232be227642734c3a5e

> Bug 696553: reduce redundant loading of (some) substitute fonts
> Loading fonts from a Fontmap mapping, the actual font name from the font
> file usually does not match the Postscript font name.
> When that happens, a subsequent attempt to load the same font name will not
> find the font in the font directory, and this triggers the whole font file
> loading process via Fontmap.
> Add code to create a new font with the original Postscript font name.
> Also, undefine the orginal font from the font file, to avoid cluttering up
> the FontDirectory with pointless entries.
> Resource/Init/gs_fonts.ps

2016-02-01 10:32:52 +0000
Ken Sharp <ken.sharp@artifex.com>
96f79a46a559af75995bf021cc85438c99509bbb

> PS interpreter - fix array processing for the DCTEncode params dict
> The PLRM says that HSamples, VSamples can be strings, arrays or packed
> arrays and QuantTables can be an array or a packed array (of strings,
> arrays or packed arrays). If they are array types, then the values must
> be integers.
> In sdcparam.c where we process the paramters we were checking and
> processing strings, and if the data was not a string we tried to handle
> it as an array of floats (which is technically incorrect), but we never
> tried to process the data as an int array.
> This led to the routine throwing a typecheck error, so the values were
> never used.
> This commit adds processing for int arrays (I've left the float array
> processing intact, even though its wrong).
> No differences expected, this is really only used by pdfwrite.
> base/sdcparam.c

2016-01-30 10:45:29 +0000
Ken Sharp <ken.sharp@artifex.com>
9399eefc54d7c14b9ebf56ca585f4946abaf555e

> pdfwrite - fix alpha duplication
> Bug #696524 "gs: Some elements discarded in PDF with 3d transform"
> The bug title is incorrect. In fact the problem is complex; we have two
> forms, each of which is preceded by a graphics state, each graphics state
> modifies the constant alpha, but one has alpha is shape false, while the
> other has it as true.
> This causes confusion when updating the alpha as we cannot have AIS
> both true and false at the same time, so we don't know which alpha to
> use.
> This commit checks the graphics state to see which alpha usage is the
> default state and sets AIS from that, as appropriate for whether the
> opacity or shape is set.
> This is a little hacky but I think its safe enough and fixes what is a
> rather rare problem.
> devices/vector/gdevpdfg.c

2016-01-29 10:30:13 +0000
Chris Liddell <chris.liddell@artifex.com>
471af1e1961054327484bf86a474669f37634c7f

> Bug 696554: cleanup after failing to read font value
> In /.findfontvalue, if we hit an error tokenizing the contents of the font file
> the stack cleanup was incorrect.
> Resource/Init/gs_fonts.ps

2016-01-28 15:37:14 +0000
Ken Sharp <ken.sharp@artifex.com>
29757551f9935292418df94d588693e13e3afeec

> PDF interpreter - repair xref processing with PDFSTOPONERROR
> commit c9f24068810f762f2a54d33d7cb8040eff080368 accidentally broke the
> processing of xref tables with -dPDFSTOPONERROR, any xref would lead to
> an error and premature exit.
> This commit repairs the processing as intended, so that *valid* xref
> tables won't cause us to stop with an error.
> No differences expected
> Resource/Init/pdf_main.ps

2016-01-28 12:24:05 +0000
Ken Sharp <ken.sharp@artifex.com>
1204680ae25d0cfa1ab815952b3009a024c6b9ec

> pdfwrite - prevent emitting a negative value for linewidth
> Bug #696548 "Regression: acrobat cannot open ghostscript generated pdf file starting with d43d5653c0e052c172ce1db9d9b04d4ba7360de3"
> The PDF reference states that linewidth is a non-negative number, and
> we were emitting a negative value in some conditions.
> Bizarrely (given the horrendously broken PDF files Acrobat *will* read)
> this causes an error in Acrobat, though not in practically every other
> PDF consumer.
> This commit simply forces the value to be positive.
> No differences expected.
> devices/vector/gdevpdfd.c

2016-01-28 11:38:53 +0000
Ken Sharp <ken.sharp@artifex.com>
d6d499ba4bb4fa27d0f6970a5e98b3372f52d05c

> PDF interpreter - Handle inline images in a text block
> Bug #696545 "Missing inline images"
> Similar to bug #695897, where image XObjects were being drawn inside
> a text block (between BT and ET), in this case we have inline images
> (ID) inside a text block.
> This is, according to the specification, illegal but Acrobat simply
> ignores that and draws the image using the CTM in force when the BT
> operator is encountered.
> This commit just reuses the code for Bug 695897 and applies it to the
> ID operator as well.
> No differences expected
> Resource/Init/pdf_draw.ps

2016-01-27 18:42:06 +0000
Chris Liddell <chris.liddell@artifex.com>
a8b8922b4608d6bf021714100dcd3b85ac1a8c86

> Make waterfal.ps standalone
> Originally waterfal.ps called .runlibfile to run landscap.ps (in the lib
> directory) to draw the page landscape.
> Since .runlibfile is non-standard Postscript, and lib is no longer in our
> default search path, *and* it is only five lines of Postscript, it's a
> needless complication - better for the file to be self contained.
> examples/waterfal.ps

2016-01-26 08:47:30 -0800
Michael Vrhel <michael.vrhel@artifex.com>
3bbced3ab549bef42f47fb28c10287b32826d1b4

> Fix for Bug 696514. rinkj device
> The rinkj device was dereferencing a NULL pointer related
> to the ICC device link profile that it can be set up to use.
> Fixing this issued and playing around with a various command
> line options revealed a problem in error trapping in the
> icc code where you could cause a crash by having a bogus
> device link profile specified on the command line. This
> fixes that crash also.
> base/gsciemap.c
> base/gsicc_create.c
> base/gsicc_manage.c
> base/gsicc_manage.h
> devices/gdevrinkj.c
> xps/xpscolor.c
> xps/xpsimage.c

2016-01-26 16:48:22 +0000
Ken Sharp <ken.sharp@artifex.com>
5e270fffe76164b07b29dec2358ef01003866674

> PS Interpeter - correct the error from setfileposition on invalid file
> Noticed while working on a different problem, the check_file macro in
> stream.h returns invalidaccess if a file is invalid, the PLRM (see
> setfileposition operator on p669 of the 3rd edition) says that the
> error return should be ioerror.
> base/stream.h

2016-01-26 15:45:55 +0000
Ken Sharp <ken.sharp@artifex.com>
704617563f8640f6b229ffd65185f79efb0ae195

> PDF interpreter - more robustness in the face of broken Info dicts
> Bug #696541 "ps2pdf fails (typecheck) on a file that can be opened by some other viewers"
> This only fails if the device states it can accept document info,
> currently that's limited to pdfwrite and friends.
> The problem is that the Info dictionary contains invalid strings, and
> those cause the parsing to break with an error.
> This commit simply ignores the error (thereby bit-bucketing the Info)
> just like other devices.
> Resource/Init/pdf_main.ps

2016-01-25 15:50:14 -0800
Michael Vrhel <michael.vrhel@artifex.com>
d9dbc622e4828089e4f2ad63203eb2a32b0e1737

> Fix for bug 696517
> bitrgbtags device needed to have its get_color_comp_index
> set to the gx_default_DevRGB_get_color_comp_index.
> devices/gdevbit.c

2016-01-25 12:27:58 -0800
Michael Vrhel <michael.vrhel@artifex.com>
9a5c3505255381bcfd4ec3b5265142927d56e264

> Bug 696521. Fix for bit rotted contributed devices.
> These devices now run to completion. I can't verify if the output
> is correct however.
> contrib/japanese/gdevmjc.c
> devices/gdevphex.c

2016-01-25 09:59:23 -0700
Henry Stiles <henry.stiles@artifex.com>
6e07b8891aa1bebf258f3936fd537e169aa45c05

> Fix #69643 Margins don't work in XL.
> The PXL interpreter was setting the hardware margins to 0 overriding
> the setting from the command line. We simply remove the setting and
> let the device set to the default parameters if it isn't set on the
> command line or explicitly elsewhere.
> pcl/pxl/pxsessio.c

2016-01-23 08:13:45 -0700
Henry Stiles <henry.stiles@artifex.com>
ccb0968c696ab80eb19071e0f3b93c850759856a

> Fix typo in last commit.
> pcl/pcl/rtgmode.c

2016-01-22 12:17:29 -0700
Henry Stiles <henry.stiles@artifex.com>
f56510cefb91ee24becd43e5f0d9baa7be53367d

> Fix badly scaled image (696530) and refactor.
> Many RTL plotters do not restrict resolutions so we allow any resolution
> in RTL mode. Further the the function which sets the resolution was
> awkward: wrongly commented with a complex nested ternary operator. We
> now use a simpler lookup table and hopefully have a better explanation
> of what we are doing in the comments.
> pcl/pcl/rtgmode.c

2016-01-22 14:30:39 +0000
Ken Sharp <ken.sharp@artifex.com>
c30df20c44d608b9c0832e5ef117f08cd358895b

> pdfwrite - correct a buffer size when converting colours
> Bug #696531 "Ghostscript segfaults on some PDF files"
> When converting DeviceN (and some other) spaces to a different colour
> space we do not convert the actual space, we convert the *base* space
> in order to better preserve the original colour intent.
> For example a Separation ink of 'PANTONE 4' might have a base space (to
> which the PANTONE colour will be converted if that ink is not available)
> of DeviceCMYK. If we set the ColourConversionStrategy to RGB then we can
> either convert every pantone colour to CMYK then convert the CMYK to RGB
> or we can alter the base space from CMYK to RGB, we choose to alter the
> base space.
> To do this we need to create a function which maps the input colours to
> the base space. This function needs a data source, and the buffer being
> allocated to hold the data had its size incorrectly calculated.
> This led to running off the end of the buffer and corrupting memory.
> This commit corrects the buffer size calculation.
> No differences expected.
> devices/vector/gdevpdfc.c

2016-01-22 13:55:24 +0000
Robin Watts <robin.watts@artifex.com>
19abd5d192aeab76f521791148f8b586414504a1

> Bug 696522: Set up copy_planes for all planar devices.
> Previously we never set up the copy_planes dev proc for planar
> devices that had a single plane, but it seems we need to.
> base/gdevmpla.c

2016-01-21 09:51:43 -0800
Brian Norris <computersforpeace@gmail.com>
0c176a91d53c85cdacd7917c76d6f659125ac3f6

> Bug 696528: kill off ijs-config
> The custom ijs-config tool gives different include paths than pkg-config
> (-I${INCLUDE_PATH}/ijs vs. -I${INCLUDE_PATH}/), which can be confusing
> for developers using this library. pkg-config is more standard anyway,
> so just kill the custom tool.
> ijs/Makefile.am
> ijs/Makefile.in
> ijs/configure
> ijs/configure.ac
> ijs/ijs-config.1
> ijs/ijs-config.in
> ijs/libtool

2016-01-21 10:48:54 +0000
Robin Watts <robin.watts@artifex.com>
fd63655e199fbfcda8e52c873b3a28bf27914c93

> Enable "accurate curves" by default.
> This helps to address bug 696466 (and it's earlier related
> bug 688434).
> base/gxistate.h

2016-01-21 18:09:09 +0000
Robin Watts <robin.watts@artifex.com>
e25594f98886a164f4465505595691aca8136deb

> Bug 696466: Preliminary work on setaccuratecurves.
> If accurate curves are enabled, and the same path is filled
> and then stroked, we can get very different results when the
> flatness is high.
> This can look very odd. Ensure that we flatten paths in the
> same way for both fills and strokes when accurate curves is
> enabled.
> base/gxfill.c
> base/gxpath.h

2016-01-20 20:15:42 +0000
Robin Watts <robin.watts@artifex.com>
064559beaa05329b1d9e6283e6d17a8c87765e7f

> Bug 696466: Fix incorrect line joins in strokes.
> When we flatten a path for stroking, we keep 'notes' on each
> line to tell us whether each line was present in the original
> path, or whether it was generated by the flattening process.
> We further note which lines were generated by the flattening
> process, and are NOT the first one in a given curve. We do this
> so that we can apply the 'curve join' to the start of such line
> segments.
> The "curve_join" is an optimisation to speed path drawing. When
> we've flattened a curve, it makes no sense to draw (say) a round
> join between each flattened line, because they will be almost
> parallel, and the join will be visually indistinguishable from
> a simple bevel (in most cases).
> It's still important that we draw the correct curve between any
> preceeding line and the first line in the curve though.
> Sometimes, (especially when setaccuratecurves is turned on), the
> first line in a flattened curve may be degenerate (i.e. 0 length).
> The stroker spots degenerate sections and skips them. Unfortunately
> that means it also skips the note about it being the first line
> from a curve, and the wrong join is used.
> The fix implemented here is to alter the stroker so that when
> it skips a degenerate section, it checks for the 'first line
> from an arc' flag and carries it forwards.
> base/gxstroke.c

2016-01-18 10:16:09 -0800
Ray Johnston <ray.johnston@artifex.com>
68dc00f46d402685f2060ce7ae1b64056996556f

> Improve interpolated image processing collecting runs of non-pure colors.
> It the colorspace output is not "pure", runs were not being detected.
> Use code similar to the pure color case detecting runs when the interpolated
> color (psrc) is the same.
> This allows the file on Bug 696140 to complete (eventually).
> base/gxiscale.c

2016-01-19 12:32:37 -0800
Michael Vrhel <michael.vrhel@artifex.com>
1e153e19cfd9660ea81c738ea8be3dd9183b3bbc

> Fix dereference of NULL pointer
> When gscms_get_link is called with a device link profile as the source
> and no destination profile, we had a dereferencing issue. Thanks
> to Henry for seeing this.
> base/gsicc_lcms2.c

2016-01-18 16:50:46 +0000
Ken Sharp <ken.sharp@artifex.com>
10916df6310cb94c4074302cf485f535d76b4533

> PS/PDF interpreters - fix Text rendering mode 3 with large glyphs
> Bug #696513 "Regression: Ghostscript renders unexpected boxes starting with bb246f03fab855325a73fdc982ed9802c1f16772"
> The commit noted as causing the regression is, frankly, incorrect.
> When handling text we have two possible paths; one with caching and,
> for large glyphs at high resolution, one without caching.
> When doing a stringwidth or Tr3 with a cached glyph, we simply avoid
> rendering the cached bitmap. However with non-cached glyphs its not so
> simple. We run the CharProc/BuildGlyph procedure as PostScript, which
> means all the operations are indistinguishable from regular PostScript.
> So, when performing a stringwidth using a non-cached glyph, and prior to
> the noted commit, when using Tr 3, we push the null device in order to
> prevent the glyphs actually marking the page, and then grestore back to
> original device when we finish.
> The commit noted broke that by failing to push the null device, meaning
> that uncached glyph in rendering mode 3 did actually mark the raster.
> The first part of the commit reverses the earlier commit, and implements
> skipping the currentpoint by explicitly checking the 'operation' before
> performing it. In fact this is no longer necessary as the PDF interpreter
> now checks this at an earlier stage and the original bug can no longer
> be reproduced this way anyway.
> However, this exposed two new problems which had previously been masked,
> but were nevertheless potential bugs:
> The 'procs' structure in a device was originally intended to be fully
> populated, each proc should either have a device-specific method or a
> graphics library default. This means there is no need to check the value
> of a device proc, we can always execute it.
> Unfortunately, as noted before, this has been broken for some time in
> the code base. There are several methods which do not have graphics
> library defaults, and are not set up by the default device macros. This
> can lead to the 'procs' members being NULL.
> There are several places in the code where we explicitly check for a
> device method being NULL before execution in order to catch this
> condition. Ideally we should go back and fix these properly so that we
> can go back to simply executing the device method without checking. But
> this is a big job.....
> So here we add two more cases where we check a device method
> 'update_spot_equivalent_colors' to be sure its not NULL before we
> execute it.
> No differences expected.
> base/gscdevn.c
> base/gscsepr.c
> base/gxchar.c

2016-01-18 08:57:10 +0000
Chris Liddell <chris.liddell@artifex.com>
da79b51a8bc3aeb4c4e55ae4ce6ebe07b34b93cf

> Fix xpswrite/gprf builds with shared zlib.
> Both those devices depend on zlib, but lacked the Makefile magic to cope with
> both "local" and shared zlib libraries.
> devices/devs.mak

2016-01-15 15:46:07 +0000
Ken Sharp <ken.sharp@artifex.com>
1e6b986c30ca319ad87d5e1fea9a327d74f3de83

> PDF interpreter - improved Acrobat matching with illegal '--x' numbers
> It seems that Acrobat handles malformed numbers of the form '--<number>'
> by ignoring the duplicated negations. GS was treating these as 0.
> This commit adds to the special 'invalid number' scanning by treating
> numbers with any number of negative signs as a single negative.
> Progressions in sumatra/2238_-_text_wrongly_aligned.pdf and
> sumatra/2238_-_doubly_negated_numbers.pdf
> psi/iscan.c

2016-01-14 14:21:22 +0000
Ken Sharp <ken.sharp@artifex.com>
193ecef5be3f755e8285a55776e0aacdbaf249c1

> PDF interpreter - allow unlimited growth of stacks
> Bug #696487 "Error: /undefined in --run-- reading PDF file"
> The problem is caused by the fact that we use a dictionary to store
> ExtGstate changes, so every time we do a gsave we need a new dictionary
> to hold those changes. The file is sub-optimal and contains thousands
> of nested gsaves, which means we need thousands of dictionaries, and
> quickly fill up the dictionary stack.
> We could specify a larger maximum dictionary stack, but there is no
> obvious limit to files of this type, one page was seen to have in excess
> of 6,000 nested gsaves. Instead we permit unchecked stack growth by
> setting MaxDictStack (or MaxOpStack / MaxExecStack) to -1 so that the
> stack will grow as required until we run out of memory.
> Bug #696511 has been opened as an enhancement to move the ExtGstate
> parameters into the regular graphics state which has to be better than
> the current kludge.
> No differences expected.
> Resource/Init/pdf_main.ps
> psi/istack.c
> psi/zusparam.c

2016-01-13 11:27:59 +0000
Chris Liddell <chris.liddell@artifex.com>
665d68106d0a0853273d0d0d4a555f22cd984c0b

> Fix libjpeg jconfig.h dependency
> Our customised jconfig.h depends on our own arch.h header - add that to
> jpeg.mak
> base/jpeg.mak

2016-01-12 15:59:03 +0000
Chris Liddell <chris.liddell@artifex.com>
bb6963e41cedb4ff68db0e0ff61d4de2668fdc5e

> Tidy up the error code and string return in arg_next()
> Previously the arg_next() return value was the string containing the argument
> and the error code (if any) was returned via a pointer parameter to an int
> variable.
> Change it so the return value is the error code, and the argument string is
> returned via a parameter.
> base/gsargs.c
> base/gsargs.h
> pcl/pl/plmain.c
> psi/imainarg.c

2016-01-12 10:22:59 -0800
Michael Vrhel <michael.vrhel@artifex.com>
05aa8a4d63935183a0902d33892041ea3f7769da

> Fix crash in x64 Windows display device
> The code used for the 64 bit display device was broken due
> to an improper initialization of the pointer size during
> the class registration as well as the use of the wrong
> API where we were using SetWindowLong/GetWindowLong instead of
> SetWindowLongPtr/GetWindowLongPtr. Thanks to Robin for
> helping with this.
> pcl/pl/plwimg.c
> psi/dwimg.c

2016-01-12 14:43:17 +0000
Ken Sharp <ken.sharp@artifex.com>
fde64dbcf02a2548145d662196e83cd0319cece5

> PS interpreter - properly handle errors when preparing to run CDevProc
> Bug #696503 " Regression: segfault with pdfwrite starting with 2deb460ef02e2802546e09979243764ede2d4173"
> The bug title is something of a misnomer, the stated commit does not
> cause the problem, it simply shifts memory around and exposes the
> already existing bug.
> The problem is caused by a faulty CIDFont, and the default behaviour of
> the PDF interpreter, which does not halt when an error is encountered.
> When running CIDFonts we need to execute a CDevProc in order to add the
> PDF /W or /W2 values to the width of the glyph. However, the font we use
> when setting up to run the CDevProc is broken so badly that we throw an
> error from z1_set_cache. We return the error, but we don't terminate
> the text enumerator, which leads to us continuing with the text. Not
> surprisingly this eventually crashes.
> This commit terminates the 'show' operation if it detects an error when
> setting up to run the CDevProc.
> No differences expected
> psi/zchar.c

2016-01-11 16:10:52 +0000
Ken Sharp <ken.sharp@artifex.com>
15b3f5cbf12461e2ed318e793669b7c34e32089b

> text extraction - restore the GC macro
> Robin asserts that this macro can have no effect and removed it as it
> causes a compiler warning.
> Checking this properly will require more time than I have conveniently
> at the moment, and I seem to recall that this was required, in the past
> at least.
> Because this might result in a difficult to track down GC problem, and
> was only removed to prevent a compiler warning, I'm restoring the old
> code until I can get the time to walk through it properly and determine
> if it is genuinely unused, and if it is, whether it should be.....
> devices/vector/gdevtxtw.c

2016-01-11 14:13:42 +0000
Chris Liddell <chris.liddell@artifex.com>
d43e2ebb241d5a6ed63a2d0cc2c7ff0909498510

> Remove legacy lower case arch_* macros
> Most of the ARCH_* macros had lower case equivalents for "backwards
> compatibility" - it's been long enough.....
> base/gdevdevn.c
> base/gdevm1.c
> base/gdevm16.c
> base/gdevm2.c
> base/gdevm24.c
> base/gdevm32.c
> base/gdevm4.c
> base/gdevm40.c
> base/gdevm48.c
> base/gdevm56.c
> base/gdevm64.c
> base/gdevm8.c
> base/gdevmem.c
> base/gdevmem.h
> base/gsalloc.c
> base/gsbitops.c
> base/gsbitops.h
> base/gsccode.h
> base/gscie.h
> base/gsfont.c
> base/gsovrc.c
> base/gspaint.c
> base/gsparam.c
> base/gxalloc.h
> base/gxbitops.h
> base/gxchar.c
> base/gxcht.c
> base/gxcindex.h
> base/gxcvalue.h
> base/gxdcolor.c
> base/gxdevcli.h
> base/gxdevice.h
> base/gxfapi.c
> base/gxfill.c
> base/gxfill.h
> base/gxfrac.h
> base/gxi12bit.c
> base/gxidata.c
> base/gxiscale.c
> base/gxmclip.h
> base/gxobj.h
> base/gxoprect.c
> base/gxpcmap.c
> base/gxsample.c
> base/gxtype1.h
> base/gzht.h
> base/scf.h
> base/shc.h
> base/smtf.c
> base/spngp.c
> base/std.h
> contrib/gdevhl12.c
> devices/gdev4693.c
> devices/gdevbmpc.c
> devices/gdevdsp.c
> devices/gdevgprf.c
> devices/gdevimgn.c
> devices/gdevmgr.c
> devices/gdevmswn.c
> devices/gdevpcx.c
> devices/gdevpsd.c
> devices/gdevstc.c
> devices/gdevstc.h
> devices/gdevsun.c
> devices/gdevtfax.c
> devices/gdevtfnx.c
> devices/gdevtsep.c
> devices/gdevupd.c
> devices/gdevxcf.c
> devices/vector/gdevpdfb.c
> devices/vector/gdevpdfv.c
> pcl/pcl/pccoord.h
> pcl/pcl/pcommand.h
> pcl/pl/plchar.c
> psi/ialloc.c
> psi/idict.c
> psi/idict.h
> psi/igcref.c
> psi/igcstr.c
> psi/iref.h
> psi/zdouble.c
> psi/zusparam.c
> toolbin/color/icc_creator/ICC_Creator/icc_create.cpp

2016-01-09 08:09:06 +0000
Chris Liddell <chris.liddell@artifex.com>
9bf5ab79cf5a0e9d6eee490fe1859c6d6aa28ca5

> Fix typo in Make.htm.
> Spotted by Brian Norris.
> doc/Make.htm

2016-01-08 15:42:30 +0000
Chris Liddell <chris.liddell@artifex.com>
4b7b278daa5a8290681de6ad157060fb2e9068ea

> Bug 696497 (part 2): fix support for building with a JPX decoder
> base/lib.mak
> psi/int.mak

2016-01-08 13:54:22 +0000
Chris Liddell <chris.liddell@artifex.com>
57fbbff9f296ddf75d3deafb0094543a04c5450b

> Tweak LCMS2 endian setting in configure
> The previous configure setting did not work with the latest endian stuff in
> lcms2.h when building a universal binary on Mac. This change resolves that.
> Also change the order of the types we check when looking for a 64 bit data
> type for color indices - put the more commonly successful one first. Again,
> this is in support of universal binaries on Mac.
> Noticed in passing.....
> configure.ac

2016-01-08 11:00:08 +0000
Chris Liddell <chris.liddell@artifex.com>
2e8632ae0ac799d4ad7cf253530576c53369baa7

> Bug 696498: clean up endian configure checks
> The custom endian checks in the configure scripts were implemented because the
> built-in test in the most common autoconf version at the time was buggy on
> several platforms.
> Those autoconf problems were addressed some time and several versions ago, and
> the newer versions are widely adopted, so we can safely use the built-in
> AC_C_BIGENDIAN() test.
> configure.ac

2016-01-07 20:32:19 +0000
Chris Liddell <chris.liddell@artifex.com>
08eaf8b0f70c5ad000001e01d767e4093ba38eff

> Tidy up cmap table selection in fapi_ft.c
> Rearrange so we don't try to select the cmap table for non-TT fonts, and only
> once.
> Also, make it explicit and comment the fact we ignore the return value from
> the Freetype call.
> base/fapi_ft.c

2016-01-07 17:44:56 +0000
Chris Liddell <chris.liddell@artifex.com>
d5fe73441042077ee8e76494a94b9fef5102c3d0

> Bug 696502: cope with PaintProc with more gsaves than grestores
> If a pattern PaintProc executes one or more gsave operations, and fails to
> execute a matching number of grestore operations, we can end up trying to
> complete any transparency operations and cache the pattern tile with the
> wrong gstate in force.
> pattern_paint_cleanup() already dealt with that, so add similar code to
> pattern_paint_finish() - as the information is already available on the
> stack.
> psi/zpcolor.c

2016-01-07 17:09:34 +0000
Chris Liddell <chris.liddell@artifex.com>
03456d0a01bfb2823261d200d40bf2975c947eb8

> Bug 696499: avoid infinite recursion of Show calls
> In the PDF interpreter we keep a procedure called "/Show" in the PDF
> graphics state dictionary, which gets changed to suit the current text
> rendering settings when we enter a text context.
> To cope with a previous broken PDF we prevent changes to the graphics state
> under certain circumstances (specifically, after a 'W' operator).
> In this case, we have a *very* broken PDF that attempts to draw some text
> in these circumstances - as the graphics state is is now "locked", we
> cannot update /Show and we end up infinitely recursing.
> We now special case /Show to prevent this.
> Resource/Init/pdf_ops.ps

2016-01-07 12:33:45 +0000
Chris Liddell <chris.liddell@artifex.com>
b0f5a97512332ecf2ec7cf1cc413fe7305a4060e

> Bug 696497: Fix support for building with no jbig2 decoder
> base/lib.mak
> psi/int.mak

2016-01-07 09:03:10 +0000
Chris Liddell <chris.liddell@artifex.com>
8f5d28536e4518716fdfe974e580194c8f57871d

> Bug 696281: fix check for using shared freetype lib
> When I changed the initial value of the Freetype source path variable (to reduce
> the risk of header search path problems), I neglected to fix the logic for
> falling back to the system's libfreetype2.
> Credit to Rodrigo Rivas Costa for spotting the problem.
> configure.ac

2016-01-07 09:15:54 -0800
Michael Vrhel <michael.vrhel@artifex.com>
2e29faf57ebe822b6f4c526b87a21c7cfeea768b

> Remove unused code from last commit
> Last commit had a static function that I was thinking of using. I decided not to
> use it and forgot to remove it with the commit.
> base/gxiscale.c

2016-01-05 10:41:58 -0800
Michael Vrhel <michael.vrhel@artifex.com>
b1e15776353f8128dfec34a50a14feea12b2a072

> Refactor code in gxiscale.c
> Quite a bit of code duplication present in gxiscale.c. This gets many of the color
> tests/initializations into common static functions and simplifies some of the tests.
> base/gxiscale.c

2016-01-06 20:08:20 +0000
Robin Watts <robin.watts@artifex.com>
e9a94db35178e398c759fdf31fa586e2913aab55

> VS builds: Ensure /FC is added to CFLAGS
> /FC forces the compiler to report full paths in warnings and
> error messages. This enables throwback to work correctly in the
> IDE. This only affects builds with the DEVSTUDIO variable
> defined (i.e. those done from the VS solution).
> psi/msvc.mak

2016-01-06 19:16:58 +0000
Robin Watts <robin.watts@artifex.com>
bd067d202a7944554dafb82ee71e5ce4ab0adf90

> Remove some wacky code from gxttfb
> Originally by Igor, neither Chris nor I can understand the
> purpose of this purposeless code.
> Chris has run against the test files and can't find any that trigger
> the case, so removing it seems harmless.
> base/gxttfb.c

2015-12-31 13:55:01 +0000
Robin Watts <robin.watts@artifex.com>
645e21d1faa7024c6d6f4c690125453344f56c2d

> Bug 649971: GS Stroking fix
> 'Fat' strokes for curves of high curvature can go wrong due to the
> winding for the 'underjoin' below curves being in the wrong sense.
> This commit introduces a tweaked version of the code that solves this
> at the cost of more complex paths. Sadly the cost for this seems to
> be a huge slowdown, so the new code is disabled for now unless we
> build with SLOWER_BUT_MORE_ACCURATE_STROKING defined.
> base/gxstroke.c

2016-01-06 16:54:22 +0000
Robin Watts <robin.watts@artifex.com>
ab929e3d6568334e336a952794918fb92123e869

> VS Solution: Add some missing files
> windows/ghostscript.vcproj

2016-01-06 17:01:28 +0000
Robin Watts <robin.watts@artifex.com>
6c2ec1e45216df7311cf14dd0b1d261a0173d70c

> Silence some more warnings.
> base/gdevdbit.c
> base/gdevflp.c
> base/gdevoflt.c
> base/genht.c
> base/gp_unix_cache.c
> base/gshtscr.c
> base/gsicc_manage.c
> base/gxclrast.c
> base/gxclread.c
> base/gxclthrd.c
> base/gxcpath.c
> base/gzcpath.h
> base/ttinterp.c
> contrib/pcl3/eprn/eprnrend.c
> contrib/pcl3/eprn/gdeveprn.c
> psi/iscan.c
> psi/iscanbin.c
> psi/zimage.c

2016-01-06 16:57:16 +0000
Robin Watts <robin.watts@artifex.com>
433d47aa3efdcf5cb26026dae27793ab901f12db

> Fix some dropped errors in pdfwrite.
> devices/vector/gdevpdf.c
> devices/vector/gdevpdfo.c
> devices/vector/gdevpdfu.c
> devices/vector/gdevpdfx.h

2016-01-05 17:05:19 +0000
Robin Watts <robin.watts@artifex.com>
b30e140190d1b18eaf769a29855f5cfe20e4922e

> Squash warnings: postscript interpreter
> Avoid some 'defined but not used' warnings in release builds.
> Avoid a particularly bonkers warning about "string" + int not doing
> concatenation (and simplify the code a bit).
> Remove some unused code.
> psi/ilocate.c
> psi/iutil.c
> psi/zcontext.c

2016-01-05 16:26:12 +0000
Robin Watts <robin.watts@artifex.com>
e0bcc257b1d94b8d5b1e800c25a1dd7149aa773c

> Fix macro error in gxfapi.h
> We have a macro that defines an expression. Add params to ensure
> that if MACRO = A || B || C that !MACRO = !(A || B || C) not
> !A || B || C.
> base/gxfapi.h

2016-01-05 17:00:38 +0000
Robin Watts <robin.watts@artifex.com>
5f7bc19bbbc551142dd94733a94657ef571ea4f8

> Fix some error returns in pdfwrite.
> Various places in the pdfwrite device we call:
> gs_note_error(x)
> and then carry on. The compiler warnings report whinges about
> this.
> We could fix it by doing:
> (void)gs_note_error(x);
> to simply shut the compiler warnings up, but it might be nicer to
> do it properly by changing the functions to correctly return
> errors.
> I'm going to try the latter. Ken can kick me later.
> devices/vector/gdevpdf.c
> devices/vector/gdevpdfo.c
> devices/vector/gdevpdfu.c
> devices/vector/gdevpdfx.h

2016-01-05 17:07:02 +0000
Robin Watts <robin.watts@artifex.com>
9c8d7abbff0cb9f8856e18934528f7b81702627d

> VS solution: gdevpxut.c was in the wrong place.
> windows/ghostscript.vcproj

2016-01-05 17:04:45 +0000
Robin Watts <robin.watts@artifex.com>
fd9a66f997bb57e9628a703774eddcf933475a34

> Squash warnings: various warnings in devices.
> Nothing contentious here.
> devices/devs.mak
> devices/gdevlp8k.c
> devices/gdevpxut.c
> devices/gdevupd.c
> devices/rinkj/rinkj-screen-eb.c
> devices/vector/gdevpdti.c
> devices/vector/gdevpsds.c
> devices/vector/gdevpx.c
> devices/vector/gdevtxtw.c
> devices/vector/gdevxps.c
> devices/vector/whitelst.c

2016-01-05 12:43:23 +0000
Robin Watts <robin.watts@artifex.com>
e7e548af55b7034409e96483fee1d92313573973

> Squash miscellaneous warnings.
> Remove some redundant variables, and tweak code to avoid compiler
> warnings.
> contrib/gdevmd2k.c
> contrib/pcl3/eprn/eprnfs.c
> contrib/pcl3/eprn/eprnparm.c
> contrib/pcl3/eprn/eprnrend.c
> contrib/pcl3/eprn/gdeveprn.c
> contrib/pcl3/eprn/gdeveprn.h
> contrib/pcl3/eprn/mediasize.c
> contrib/pcl3/eprn/mediasize.h
> contrib/pcl3/eprn/pagecount.c
> contrib/pcl3/eprn/pagecount.h
> contrib/pcl3/src/gdevpcl3.c
> contrib/pcl3/src/pcl3opts.c
> contrib/pcl3/src/pclcap.c
> contrib/pcl3/src/pclcap.h
> contrib/pcl3/src/pclcomp.c
> contrib/pcl3/src/pclgen.c
> contrib/pcl3/src/pclgen.h
> contrib/pcl3/src/pclscan.c
> contrib/pcl3/src/pclscan.h
> contrib/pcl3/src/pclsize.c
> contrib/pcl3/src/pclsize.h
> devices/gdevhl7x.c
> devices/gdevifno.c

2016-01-05 07:39:18 -0800
Ray Johnston <ray.johnston@artifex.com>
8fa72d8d85859cc4e8e52bd72231f1af8f7862a2

> Fix minor typo in "unbalanced q/Q" message for "too many q's" case.
> Resource/Init/pdf_main.ps

2016-01-05 09:49:24 +0000
Chris Liddell <chris.liddell@artifex.com>
53975ad9284df0a3aaaaca1f9bf7843620741086

> Type 1 glyph name synthesis minor efficiency improvement
> Some very small efficiency improvements - mainly, avoiding the need to
> re-init a scratch string with a loop.
> Resource/Init/gs_type1.ps

2016-01-04 19:50:53 -0800
Michael Vrhel <michael.vrhel@artifex.com>
7c2b9d06f582996ed6c230aacfbf9a0dc88c1349

> Clean up logic statements in gxiscale.c
> The test to determine if we need to do an upfront decode during the color
> management of colors in the image scaling routine were confusing to
> say the least. This should clarify everything.
> base/gxiscale.c

2016-01-04 19:44:35 +0000
Robin Watts <robin.watts@artifex.com>
92e3e79af6a068f99a723aba56df6b2cd17bbb39

> Squash clang warnings: Miscellaneous more warnings
> All fairly self explainatory.
> base/gxfdrop.c
> base/gxfill.c
> base/gxhintn.c
> base/gximono.c
> base/gxshade6.c
> base/gxstroke.c
> base/gxttfb.c
> base/sjpx_openjpeg.c
> base/ttfmain.c
> base/vdtrace.c
> contrib/gdevgdi.c
> contrib/gdevlx7.c
> contrib/opvp/gdevopvp.c
> windows/ghostscript.vcproj

2016-01-04 18:56:28 +0000
Robin Watts <robin.watts@artifex.com>
e3bc0494fc7084bd729a393e7bd6aebeeba6b6a9

> Squash clang warning: Avoid testing enums out of range.
> clang complains that the code we use to test whether an enum value
> we get it out of range is testing for values outside the enum range.
> Fix it with an explicit cast.
> base/gstrans.c

2016-01-04 18:54:17 +0000
Robin Watts <robin.watts@artifex.com>
d957420f8b2949fb7cd7563ee52af2807eb9aa7a

> Squash warning: clist code
> clang complains that the clist code is checking an enum return against
> out of range values. Rejig the code to use a switch rather than the
> chain of ifs (clearer IMAO), and handle the out of range values in the
> default case.
> base/gxclrast.c

2016-01-04 18:44:36 +0000
Robin Watts <robin.watts@artifex.com>
06f4897ea836544c48f15b7b3ffb7c4d1dc3a7d1

> Remove unused structure definition from gsshade.c
> Meshes are a superclass - never instantiated on their own.
> base/gsshade.c
> base/gsshade.h

2016-01-04 18:44:01 +0000
Robin Watts <robin.watts@artifex.com>
94ce8c79aca2a839f369a3d61347facb1b5bef7e

> Fix harmless tiny type typo in icc stuff.
> This shuts clang up.
> base/gsicc_create.c

2016-01-04 18:42:49 +0000
Robin Watts <robin.watts@artifex.com>
438f429625773d675a0649fb189e1378be2c6b29

> Squash warnings: gsht.c
> Remove unused table, and pacify clang by casting an enum type to
> int before comparing it to out of range enum values.
> base/gsht.c

2016-01-04 18:28:21 +0000
Robin Watts <robin.watts@artifex.com>
9aec49be8f43a1a3a4bdad7a552ef9fcf039b2e7

> Avoid unused function warning in release builds.
> base/gsfcmap1.c

2016-01-04 18:27:12 +0000
Robin Watts <robin.watts@artifex.com>
3d07583e43d472979250f57b80a50028226c667b

> Fix use of uninitialised var.
> base/gscspace.c

2016-01-04 18:24:31 +0000
Robin Watts <robin.watts@artifex.com>
3a563b047e686038283474b9cef942ffa889f7a3

> Fix typo: == should be =
> base/gdevprn.c

2016-01-04 18:22:43 +0000
Robin Watts <robin.watts@artifex.com>
34857cb1514033237cf658f33157a991606cfe7d

> Remove unused definition.
> base/gdevp14.c

2016-01-04 18:11:52 +0000
Robin Watts <robin.watts@artifex.com>
3343e6fe21259e548cb93748f70e81c7255d7ec7

> Squash warnings: Use better unused var paradigm.
> Using "n = n;" causes some versions of gcc to whinge. Trying
> (void)n; instead.
> base/gspmdrv.c
> base/gsptype1.c
> contrib/japanese/gdevmjc.c
> devices/gdevcmykog.c
> devices/gdevgprf.c
> devices/gdevpsd.c
> jpeg/jcsample.c
> xps/xpszip.c

2016-01-04 18:11:18 +0000
Robin Watts <robin.watts@artifex.com>
80ceaaec2fe06505cb0a5059ad5f95ea28004f9f

> Remove unused function from gdevddrw.c
> base/gdevddrw.c

2016-01-04 17:34:53 +0000
Robin Watts <robin.watts@artifex.com>
24c51631502da158557e0f35368756dd95cdfb38

> Fix potential problem in transparency code
> If we ever use more the 8 bits for color values, we'd try to
> pack numbers > 255 into a byte in pdf14_cmykspot_put_image and
> pdf14_custom_put_image. Simple fix is to use 0xff rather than
> gx_max_color_value.
> base/gdevp14.c

2016-01-04 17:33:25 +0000
Robin Watts <robin.watts@artifex.com>
46b2671d6526cb6aee37f786bb616c1513248a02

> Fix typo in gdevdbgr.c
> Should be | not || as a & (constant || constant) doesn't really
> make sense.
> base/gdevdgbr.c

2016-01-04 17:18:19 +0000
Robin Watts <robin.watts@artifex.com>
7069210f88b764929a32713ab5032f02097b62b5

> Squash warnings: XPS MSVC
> Add some casts etc to squash (most of) the warnings seen in
> an MSVC debug build of ghostxps.
> We have an unavoidable "cast away of const" in a devspecop call,
> and various stupidities in the jpegxr lib left over.
> xps/ghostxps.h
> xps/xpscff.c
> xps/xpscolor.c
> xps/xpsglyphs.c
> xps/xpsgradient.c
> xps/xpsjpeg.c
> xps/xpsjxr.c
> xps/xpspath.c
> xps/xpspng.c
> xps/xpstiff.c

2016-01-04 16:39:31 +0000
Robin Watts <robin.watts@artifex.com>
d697081ba9f0943977ed5ae8a62c7389046a5776

> Squash warnings: MSVC PCL
> Squash the warnings seen when building a debug PCL build on MSVC 2005.
> Mostly addition of simple casts.
> pcl/pcl/pcjob.c
> pcl/pcl/pcpage.c
> pcl/pcl/pglabel.c
> pcl/pcl/pglfill.c
> pcl/pcl/rtgmode.c
> pcl/pl/plchar.c
> pcl/pl/pllfont.c
> pcl/pxl/pximage.c
> pcl/pxl/pxink.c
> pcl/pxl/pxvendor.c

2016-01-04 16:16:18 +0000
Robin Watts <robin.watts@artifex.com>
15d2abc903ed91f5f319687c2bc6959a38d36069

> Windows PCL: Correct return type from int to void.
> Nothing was ever returned.
> pcl/pl/plwmainc.c

2016-01-04 16:11:06 +0000
Robin Watts <robin.watts@artifex.com>
5fe48dd2498953fc3df7f8f22655e91c77f97076

> Squash warnings: MSVC ones.
> Tweak the code to avoid the warnings seen in the MSVC debug build of
> gs.
> Mostly adding a few casts to make type changes explicit (and hence
> avoid the "casting from int to double might lose data" etc warnings).
> Reorder the headers in a couple of places to avoid offsetof being
> redefined in a system header warnings.
> base/gpmisc.c
> base/gsicc_create.c
> base/gxclimag.c
> base/gxfapi.c
> devices/gdevdsp.c
> devices/gdevfpng.c
> devices/gdevgprf.c
> devices/gdevpng.c
> devices/gdevtifs.c
> devices/vector/gdevpdfu.c
> devices/vector/gdevpsds.c
> devices/vector/gdevxps.c
> psi/gsdll.c
> psi/iscannum.c
> psi/iutil.c
> psi/zdpnext.c
> psi/zdps1.c
> psi/zmatrix.c
> windows/ghostscript.vcproj

2016-01-04 17:07:35 +0000
Chris Liddell <chris.liddell@artifex.com>
063c0a1eface77cdc2c4e657599521c7146ec8ca

> Bug 696480: add a missing 'pop' for stack cleanup.
> When attempting to create all viable glyph name mappings in a Type 1 font,
> as a last ditch, we try to parse a unicode code point out of a string containing
> a'uniXXXX' type glyph name (where 'XXXX' is the code point). If that parsing
> fails, we were leaving the string on the stack, causing an error.
> Resource/Init/gs_type1.ps

2016-01-04 14:14:35 +0000
Robin Watts <robin.watts@artifex.com>
7795f0f1f8700651d2a79f979a5d40885569dd11

> Squash warnings: ICC code.
> Various bits of the ICC code collects return values only to not
> check them. Fix that here.
> In some cases this is because functions have a 'void' return type
> so there isn't a way to return an error. Change those return types
> and ensure that all callers check and propogate the errors.
> base/gdevdevn.c
> base/gscms.h
> base/gsdevice.c
> base/gsequivc.c
> base/gsequivc.h
> base/gsicc_cache.c
> base/gsicc_cache.h
> base/gsicc_cms.h
> base/gsicc_lcms.c
> base/gsicc_lcms2.c
> base/gsicc_manage.c
> base/gsicc_monitorcm.c
> base/gsicc_nocm.c
> base/gsicc_replacecm.c
> base/gspaint.c
> base/gxclimag.c

2016-01-04 14:10:04 +0000
Robin Watts <robin.watts@artifex.com>
998c8bf7a2e409b6c4c29b8e535028a24404e7c5

> Squash warnings: Contrib devices
> Workaround as many warnings as possible in the contrib devices.
> Removing dead code, checking return values etc, fixing type casts
> (char to unsigned char etc).
> contrib/eplaser/gdevescv.c
> contrib/gdevmd2k.c
> contrib/japanese/gdev10v.c
> contrib/japanese/gdevalps.c
> contrib/japanese/gdevespg.c
> contrib/japanese/gdevfmpr.c
> contrib/japanese/gdevlbp3.c
> contrib/japanese/gdevmag.c
> contrib/japanese/gdevml6.c
> contrib/lips4/gdevl4r.c
> contrib/lips4/gdevl4v.c
> contrib/opvp/gdevopvp.c
> contrib/pcl3/eprn/eprnparm.c
> contrib/pcl3/src/gdevpcl3.c

2016-01-04 14:07:31 +0000
Robin Watts <robin.watts@artifex.com>
39cdb5df0e2f8e3e4410e008b2a7fb72dcdff805

> Avoid ignoring a return code during garbage collection.
> psi/ireclaim.c

2016-01-04 14:05:59 +0000
Robin Watts <robin.watts@artifex.com>
3388e52d3ea54fa2d46e857d3004a229d143ad40

> gdevxcf: don't confuse rgb and cmyk profile functions.
> We are writing prgbs to both ProfileRGB and ProfileCMYK.
> That seems wrong.
> devices/gdevxcf.c

2016-01-04 14:04:00 +0000
Robin Watts <robin.watts@artifex.com>
dd32af452b8bd08e7eb5daf3344d2caae8a13dc7

> Squash Warnings: JBig2
> ifdef out some used code.
> Make some functions static that should be.
> jbig2dec/jbig2_generic.c
> jbig2dec/jbig2_image.c
> jbig2dec/jbig2_refinement.c
> jbig2dec/jbig2_segment.c

2016-01-04 13:59:43 +0000
Robin Watts <robin.watts@artifex.com>
046f22db259214cb77b95e631d65ebdacec79a87

> Squash warnings: XPS.
> Avoid some warnings in the XPS code.
> Mostly 'set but unused' variables. Either remove these or
> (in cases where they may be required later) comment them out.
> Ensure that all return codes are checked once read. This has
> meant making a few functions return error codes that didn't before.
> Include an extra gs header in ghostxps.h. This trips the code into
> objecting to using printf etc. Change the calls to printf to use
> dlprintf instead (as they should do).
> Change the prototypes for some functions to pass const params
> in some cases, and make a few return error codes rather than ignoring
> them.
> Add a couple of missing prototypes.
> xps/ghostxps.h
> xps/xpsdoc.c
> xps/xpshash.c
> xps/xpsmem.c
> xps/xpsopacity.c
> xps/xpsxml.c
> xps/xpszip.c

2016-01-04 13:52:43 +0000
Robin Watts <robin.watts@artifex.com>
7a7588ce7c7cd1b0a8d55818af5d2f34dd17d3ff

> Minimise warnings in unix ijs code calling execvp.
> execvp should really take const char *args, but linux is 'inconsistent'
> about this. We assume that the args are of this form in our code,
> so we'd rather have 1 warning on the call on such systems, rather than
> n about the setup on all systems.
> ijs/ijs_exec_unix.c

2016-01-04 13:51:23 +0000
Robin Watts <robin.watts@artifex.com>
882ce8be8592ed51243c9a7190c89fb1d2d61fd8

> ijs_server: Don't ignore the 'sign' var when parsing ints.
> ijs/ijs_server.c

2016-01-04 13:16:03 +0000
Robin Watts <robin.watts@artifex.com>
91470dae4954f9c9e36c019616c3ff7bcdd173de

> Squash warnings: Cull unused or dead code.
> In cases where the code is there for potential future use,
> comment small sections out or use #ifdef UNUSED.
> base/mkromfs.c
> contrib/gdevcd8.c
> contrib/gdevdj9.c
> contrib/gdevgdi.c
> contrib/gdevlx32.c
> contrib/gdevop4w.c
> contrib/japanese/gdevmjc.c
> contrib/japanese/gdevrpdl.c
> devices/gdevhl7x.c

2016-01-04 13:10:15 +0000
Robin Watts <robin.watts@artifex.com>
2d914c99900578d76753a134ea6d7bf35eb932f3

> Squash warnings: Add explicit bracketing.
> && binds more tightly than || in C (similarly & and |).
> Expressions such as "A && B || C" are therefore well defined, but
> often error prone and confusing to read, so the compiler warns about
> them. We add explicit parentheses to shut this up (and to clarify
> the code).
> base/gxiscale.c
> contrib/pcl3/eprn/eprnfs.c
> contrib/pcl3/eprn/eprnparm.c
> contrib/pcl3/eprn/eprnrend.c
> contrib/pcl3/eprn/gdeveprn.c
> contrib/pcl3/eprn/mediasize.c
> contrib/pcl3/src/gdevpcl3.c
> contrib/pcl3/src/pclcomp.c
> contrib/pcl3/src/pclgen.c
> contrib/pcl3/src/pclsize.c
> devices/gdevpsd.c

2016-01-04 13:03:13 +0000
Robin Watts <robin.watts@artifex.com>
c8e1e6dff1d48adf79659455e7082735909558a1

> Squash warning: switch(rop)
> Ensure that rop3_T and rop3_S are defined as enum values as well
> as preprocessor definitions.
> They must be preprocessor definitions as otherwise the rop templating
> code does not work. If they are not enum values, we get warned about
> switch(rop) testing for values not defined in the enums.
> base/gsropt.h

2016-01-04 12:57:15 +0000
Robin Watts <robin.watts@artifex.com>
ff1c44b4dbe241df64dd3d9892df56a421921c2b

> Squash warning: Improve static init
> base/gsptype1.c

2016-01-04 12:54:18 +0000
Robin Watts <robin.watts@artifex.com>
cc15153ffe7fe8ca9fa38091bfb50a67897b768b

> Squash Warnings: Add casts to avoid warnings.
> base/gdevmem.c
> base/gsht.c
> base/gsicc_manage.c
> base/gzht.h
> base/sdctd.c
> contrib/gdevbjc_.c
> contrib/gdevbjc_.h
> contrib/gdevbjca.c
> devices/rinkj/rinkj-device.h
> devices/rinkj/rinkj-screen-eb.c
> psi/imain.c

2016-01-04 12:44:43 +0000
Robin Watts <robin.watts@artifex.com>
240b8f048945a129aacb1e84c7e7b66cf0d5bff1

> Squash Warnings: Unused Var/Var set but not used.
> base/gscrdp.c
> base/gsfcmap1.c
> base/gsicc.c
> base/gsiorom.c
> base/gstype1.c
> base/gstype42.c
> base/gxclimag.c
> base/gxdtfill.h
> base/gxhintn.c
> base/gxi12bit.c
> base/sdcparam.c
> base/strmio.c
> devices/gdevcdj.c
> devices/gdevlp8k.c
> devices/gdevphex.c
> devices/gdevxalt.c
> devices/gdevxcf.c
> devices/rinkj/evenbetter-rll.c
> devices/rinkj/rinkj-epson870.c
> devices/vector/gdevpdfk.c
> devices/vector/gdevpsds.c
> psi/imain.c
> psi/zfont.c
> xps/xpscff.c
> xps/xpsfont.c
> xps/xpsglyphs.c
> xps/xpsgradient.c
> xps/xpstile.c
> xps/xpszip.c

2016-01-04 11:53:44 +0000
Robin Watts <robin.watts@artifex.com>
8db551f3a3e949035889fcb63188764ca61ab8c1

> Squash warnings: Warnings caused by printf specifiers.
> base/gdevnfwd.c
> base/gscspace.c
> base/gsicc_cache.c
> base/gsicc_manage.c
> base/gsmchunk.c
> base/gstrans.c
> base/gxclrect.c
> base/gxpflat.c
> base/scfd.c
> devices/vector/gdevpsft.c
> psi/igc.c

2016-01-04 11:43:51 +0000
Robin Watts <robin.watts@artifex.com>
6e628ac44909dd2a0fc738eaa491d92a6e4c1db0

> Squash Warnings: Simple unused variable warnings.
> base/gdevflp.c
> base/gdevoflt.c
> base/gscoord.c
> base/gsptype1.c
> base/gxclist.c
> contrib/japanese/gdev10v.c
> devices/gdevcmykog.c
> devices/gdevgprf.c
> devices/gdevijs.c
> devices/gdevplan.c
> devices/gdevpsd.c
> jpeg/jcsample.c
> psi/zicc.c
> xps/xpsjxr.c

2015-12-31 08:34:09 -0800
Robin Watts <Robin.Watts@artifex.com>
95a16466806c9f8c4f783fd6ebfb0095b9227f56

> Squash warning: remove unused variable.
> base/gxshade6.c

2015-12-31 16:13:19 +0000
Robin Watts <robin.watts@artifex.com>
df47d1bfc3f5d3bf5c58660b98840f3c9a6b6018

> Avoid some warnings in the stroking code.
> base/gxstroke.c

2015-12-31 02:40:39 -0800
Robin Watts <Robin.Watts@artifex.com>
27ab71451562b815d04e71903c1feb223069c0a2

> Bug 697822: clist fix
> When saving/restoring the clist state around the saved pages
> processing, ensure that the file handling is correct. Leaving
> the old filenames in play in particular is a bad thing, as the
> shared fdesc stuff gets confused by this.
> This commit reworks that so that clist files aren't closed/reopened
> as much.
> base/gxclpage.c

2015-12-31 02:39:10 -0800
Robin Watts <Robin.Watts@artifex.com>
f920cb3d90603df9c5f48df007ef10750f2427ff

> Bug 695822: clist fix
> When reading from the cfile, if we fail to read a cmd_block,
> give up as nothing else will make sense.
> base/gxclread.c

2015-12-31 02:37:31 -0800
Robin Watts <Robin.Watts@artifex.com>
87d413205bd948d302345004092ed43f9b6bc213

> Bug 695822: clist fix
> If we rewind a page, ensure that the 'end_pos' for the bfile is
> reset to 0.
> base/gxclist.c

2015-12-31 02:36:52 -0800
Robin Watts <Robin.Watts@artifex.com>
7c67185c0f428f2cec5a8bb339e8917ee3f6584e

> Trivial whitespace fix in clist comment.
> base/gxclfile.c

2015-12-28 13:22:35 +0000
Robin Watts <Robin.Watts@artifex.com>
834afc272d0df4dc09b1f24ac4366afa26de48b2

> Bug 693777: Valgrind indeterminism.
> Valgrind reports an indeterminism in gs_image_class_1_simple,
> caused by penum->map[0].inverted not being set.
> Analysis reveals that image_init_colors is not setting .inverted
> in some cases. The fix is simply to ensure that it's always set.
> base/gxipixel.c

2015-12-27 09:51:24 +0000
Ken Sharp <ken.sharp@artifex.com>
34ccb87a69ed6e632468e495a54ecb69bf9f5719

> pdfwrite - remove some debugging code causing a compiler warning
> devices/vector/gdevpdfm.c

2015-12-24 17:18:09 +0000
Ken Sharp <ken.sharp@artifex.com>
d4056b5dab63199d86c8fb140807b9b307a427c0

> pdfwrite - implement Metadata pdfmark and a non-standard extension metadata pdfmark
> Bug #696472 "pdfwrite lacks support for /Metadata pdfmark"
> There are several issues tackled in this single commit:
> 1) A previous commit left it impossible to use the EMBED pdfmark unless
> producing PDF/A, fixed.
> 2) The Metadata pdfmark is now implemented. This allows the user to
> specify an XMP stream which will be written to the Catalog of the PDF
> file. The pdfwrite device will not overwrite this, or add any further
> Metadata, it is the user's responsibility to get the XMP data correct.
> 3) A new pdfmark 'Ext_Metadata' has bee defined. This takes a string
> parameter which contains XML to be add to the XMP normally created by
> pdfwrite. Again ths is up to the user to specify correctly.
> In no case does pdfwrite attempt to validate the data, though it will
> issue warnings that PDF/A and PDF/X files may not be valid.
> The additional pdfmark is to support creation of the ZugFERD electronic
> invoice (http://www.ferd-net.de/front_content.php?idcat=231&changelang=4)
> and potentially other similar formats in the future.
> These new features are essentially untested.
> devices/vector/gdevpdf.c
> devices/vector/gdevpdfb.h
> devices/vector/gdevpdfe.c
> devices/vector/gdevpdfm.c
> devices/vector/gdevpdfx.h
> doc/Ps2pdf.htm

2015-12-23 14:11:47 +0000
Ken Sharp <ken.sharp@artifex.com>
21bd4941bafcd55064ba70acf1af66117e1267bd

> Documentation - sterner words on use of PDFSETTINGS
> Many people use the 'PDFSETTINGS' switch without, aopparently, comprehending
> that this will involve some alteration to the input. In addition there
> seems to be a belief that '/prepress' will produce the best (ie closest
> to the original) output, which is absolutely not the case. The best
> quality is obtained by leaving pdfwrite alone.
> I doubt it will make any difference, since so many people use a cargo cult
> approach to Ghostscript command line parameters, but at least it is now
> in the documentation.
> doc/Ps2pdf.htm

2015-12-23 12:30:12 +0000
Ken Sharp <ken.sharp@artifex.com>
e55a2b097f17846a23d0454302f7950d83baca9c

> pdfwrite - If downsampling filter initialisation fails, don't downsample
> If the image downsampling filter failed during initialisation we still
> carried on and set up to downsample (we ignored the error return). This
> would later result in a further error, and we would try to fall back
> using the default image code. However, that would again try to set up
> the downsampling filter, and would again fail, resulting in the image
> being dropped from the output.
> Here we check the return code from image initialisation, and if it fails
> we emit a warnign and stop trying to do downsampling.
> devices/vector/gdevpsdi.c

2015-12-23 12:27:31 +0000
Ken Sharp <ken.sharp@artifex.com>
8f7f0dc6616762ee14437265ec8f10bef4094a95

> pdfwrite - fix mono image downsampling for /prepress setup
> The /prepress PDFSETTING had the monochrome image downsampling set to
> /Bicubic. This is not appropriate for monochrome images, as it would
> require converting the image to to grayscale.
> The same is true for all downsampling methods except /Subsample, so
> here we alter the setting to /Subsample, which matches the other settings.
> Resource/Init/gs_pdfwr.ps

2015-12-22 17:21:37 +0000
Robin Watts <robin.watts@artifex.com>
dd43cb649f5772096b71c23f1bf36982531b74fa

> Bug 694970: Improve downscaler docs.
> Mention the explicit limit for DownScaleFactor.
> There is no point in downscaling by more than 8, as any given
> pixel ceases to contribute enough to make a difference.
> At any rate, any downscale scale >= 12 runs the risk of overflowing
> the 32bit integers used to do the sum.
> doc/Devices.htm

2015-12-22 13:42:04 +0000
Ken Sharp <ken.sharp@artifex.com>
0fd77514b93367aafaddfa3138f2b8424c7f7085

> Documentation - Note that the pdfwrite option PDFA now allows values up to 3
> doc/Ps2pdf.htm

2015-12-22 13:35:48 +0000
Ken Sharp <ken.sharp@artifex.com>
8555f7fd1500322ab6e5b2ab979eb233623c232d

> pdfwrite - permit creation of PDF/A-3 files, disable file embedding if PDFA < 2
> Bug #696473 "feature request: PDF/A-3 support"
> There is actually very little practical difference between a PDF/A-2
> and a PDF/A-3 file, PDF/A-3 permits embedding of arbitrary files
> while PDF/A-2 does not.
> Prior to commit a91d2576df0e60f6e691a3bd967b51109ae41f22 which
> added support for the EMBED pdfmark there was therefore no point in
> PDF/A-3 output.
> This commit allows the -dPDFA switch to be turned up to 3 and creates
> appropriate metadata. It also disables the EMBED pdfmark when creating
> PDF/A-1 and emits a warning for PDF/A-2 that we don't validate the
> content (PDF/A-2 only permits inclusion of PDF/A-1 and PDF/A-2). The
> precise behaviour depends on the setting of PDFACompatibilityPolicy.
> I can't claim this is well tested.
> devices/vector/gdevpdfe.c
> devices/vector/gdevpdfm.c
> devices/vector/gdevpdfp.c

2015-12-18 16:14:31 +0000
Robin Watts <robin.watts@artifex.com>
50cb214c0223d12c891cbab8e5d337975b6f3cba

> Move Memento include back into jbig2_priv.h
> It's clearly nicer not to have Memento as part of the external
> interface of jbig2, and this solves bug 696183.
> The include has ping ponged back and forth from jbig2.h in the
> past due to problems with the jbig2 allocator field naming.
> We fix that here with a spot of #ifdef/#undef-ery.
> We also simplify some of the hackery here. Rather than having
> specific defines such as GSBUILD (meaning 'get memento.h from
> some place that you magically know about') and JBIG_NO_MEMENTO
> (meaning 'just ignore memento.h at all'), we now just have
> JBIG_EXTERNAL_MEMENTO_H.
> Projects which have their own version of Memento in, and use
> jbig2dec should define JBIG_EXTERNAL_MEMENTO_H to the location
> of the memento.h file at build time.
> base/jbig2.mak
> jbig2dec/jbig2.c
> jbig2dec/jbig2.h
> jbig2dec/jbig2_priv.h

2015-12-18 14:03:06 +0000
Ken Sharp <ken.sharp@artifex.com>
6f57908e88674a1582e87043f79dc8a1c04ce55f

> PDF interpreter - reword warnings
> Marcos has complained on customer's behalf on a number of occasions
> that we don't use the word 'error' very much when fixing broken PDF
> files leading to unrealistic expectations from the customer.
> This commit breaks the errors and warnings up into two distinct groups;
> Warnings are now uncommon and are reserved for situations where it seems
> unlikely to me that the problem will result in a rendering error. For
> example, any problems processing ToUnicode CMaps are now treated as
> warnings since these are not used in rendering.
> Anything which I feel has a reasonable chance of indicating a problem
> with the PDF file sufficiently serious to result in a difference between
> our output and Acrobat is now flagged as an error.
> Each message should explicitly use the word error or warning as
> appropriate, to avoid any confusion.
> The end of job notifications differ slightly between errors and
> warnings (errors state again that the output may be incorrect). This
> potentially allows us to take additional different action in the future
> as errors and warnings are tracked separately (NB errors trump
> warnings, if you get an error, you get he error EOJ message)
> These notifications now also obey QUIET, so they won't be show if this is
> set.
> Resource/Init/pdf_base.ps
> Resource/Init/pdf_draw.ps
> Resource/Init/pdf_font.ps
> Resource/Init/pdf_main.ps
> Resource/Init/pdf_ops.ps
> Resource/Init/pdf_rbld.ps
> Resource/Init/pdf_sec.ps

2015-12-17 14:33:22 +0000
Robin Watts <robin.watts@artifex.com>
f8803ba7066e3be8a627e62eb1406c21c604c639

> Bug 696142: Sanitise tiffsep separation names.
> The existing code 'copies' separation names for printing/using in
> filenames in a very naive way. It essentially blanks out any
> characters unsupported in the filesystem with (or '%') with '_'.
> Top bit set chars are let through unchanged, which causes
> confusion as we now assume that filenames are held internally
> in utf-8 format.
> The code is updated here to output such filenames with simple
> %02x style escaping. All characters unsupported in the filesystem
> (or '%', or backspace, or top bit set chars) are escaped.
> This leaves us utf-8 safe strings.
> The only 'interesting' aspect here is that we have to check for
> whether we need to put '%%' instead of '%' because we might be
> printf-style processing the string later on.
> devices/gdevtsep.c

2015-12-16 12:24:12 -0800
Michael Vrhel <michael.vrhel@artifex.com>
47d23e2dfbae8db3b142b70aaef086c1bd6e097d

> Fix for Bug 695074 x11 device encode color
> The X11 device can be set up for different bit depths including
> indexed like colors. It could fill its palette when we have
> a small number of possible colors and fail to encode. Really the
> device should not fail the encoding but always return the best
> color that it can. It should not rely upon gs to do any halftoning
> to provide possibly see if another color could be encoded.
> With this fix, we try to use a color that is in the existing palette,
> adding a color if it is not available and we have space. If we
> no longer have space we now force the use of the closest color in
> the table.
> devices/gdevxcmp.c

2015-12-16 14:55:01 +0000
Ken Sharp <ken.sharp@artifex.com>
c9f24068810f762f2a54d33d7cb8040eff080368

> PDF Interpreter - improve performance on files with many xref sections
> Bug #696454 "Regression: Performance decrease starting with 002cd5262ccb71010473abfb9069e1fb39f36f12"
> The file is very large, and has an extremely large (~700,000 entries)
> xref table with a very large number of sections in it. Normally we
> allocate our internal xref storage as we parse the xref table, each time
> we find a new section we increase the size of an array by the number
> of entries in the section.
> If we have a lot of sections, we end up spending a lot of time in the
> memory management, allocating, copying and freeing arrays. This was less
> of a problem when we used a 2D array because each array had a maximum of
> 65535 entries. However now that we use a single array this can be time
> consuming.
> The first part of this commit searches the trailer dictionaries (stored
> after the xref) looking for the /Size entry. If we find one we use that
> to set the initial size of the xref array. This saves us having to resize
> the array as the Size is large enough to contain all entries.
> However, this file *also* has an error in its /Size entry. It declares
> the /Size as 88693, whereas in fact the xref contains nearly 700,000
> entries. Our code still worked, but it was again spending a great deal
> of time in memory management.
> So the second part of this commit detects the fact that the declared
> /Size is incorrect. When this happens, instead of allocating just
> enough new entries in the array for the section we have discovered we
> allocate 65534 entries, which makes it more likely that subsequent
> sections will not need to increase the size again.
> This is slightly wasteful of memory as we allocate storage we will never
> use, but since the file is invalid it seems better to do this than
> spend a lot of time minimising memory usage.
> In my cluster tests this seems to give a small performance improvement
> No other differences expected.
> Resource/Init/pdf_main.ps

2015-12-15 11:34:12 +0000
Ken Sharp <ken.sharp@artifex.com>
8a5802e5c99959032ccd1763861effbd30dad440

> PDF interpreter - improved recovery encountering broken fonts
> Bug #696306 "Incomplete rendering of PDF file"
> The original commit to fix this 487ed6d3b5fabbe21c23da288fbf020f49a28fae
> did resolve the problem, however it was replaced with a better (better
> in terms of correct PostScript error handling)
> 243614398b7bf3e8c4d080de7f8bbcb7436472cf
> Unfortunately I only tested that with a decompressed file from MuPDF,
> rather than the original file, and this failed with an additional
> problem in the original file.
> The file has a font stream which is ASCIIHex encoded, but contains,
> at the end, some non-ASCIIHex characters (specifically a Q) which
> causes an error in the ASCIIHexDecode before we even try to execute
> the font (which is also damaged).
> The commit to fix this fixed the handling of the broken font, but did
> not work correctly with the invalid ASCIIHex stream. The problem was
> that the font code returns a null object (instead of a font dictionary)
> but does not signal an error. This means that the code for recovering
> the operand and dictionary stacks did not execute, leaving the dict
> stack in an incorrect state.
> This code copies and executes the recovery code so that, even if there
> is no error, we still clean up.
> In addition, PDFSTOPONERROR is now honoured in a couple more places when
> we encounter font problems.
> Finally I haver altered pdfformaterror to put its output on stdout
> instead of stderr, because this makes debugging much easier (the
> warnings are now interleaved into the PDFDEBUG output for instance).
> No differences expected
> Resource/Init/pdf_font.ps
> Resource/Init/pdf_main.ps

2015-12-14 13:05:14 +0000
Chris Liddell <chris.liddell@artifex.com>
877655e3ec275accf5cba7cd724ec845fb4cb396

> Coverity 120747: correct a typo in the WOFF C code
> base/gstype42.c

2015-12-14 12:43:05 +0000
Chris Liddell <chris.liddell@artifex.com>
a7addfad24879fadb2d44fba25be70ed43ccb163

> Bug 692427: include the ICC code in the Level 2 features
> The ICC handling code was pulled in by the PDF interpreter feature, but since
> 9.00 we *always* have an ICC color workflow (even for Postscript). So make
> the Postscript Level 2 core depend on the ICC feature (this should be sufficient
> because we no longer support a pure Level 1 interpreter, and it saves rewriting
> the ICC Postscript code to use only Level 1 + Ghostscript extensions code).
> Resource/Init/gs_icc.ps
> psi/int.mak

2015-12-14 11:46:15 +0000
Chris Liddell <chris.liddell@artifex.com>
760fcc4243072daa545419f57c0513b3d24a23de

> Use sdct.dev in non-autotools builds, too.
> And fix a typo from previous commit
> base/lib.mak
> base/unix-gcc.mak
> psi/msvc.mak

2015-12-14 14:26:55 +0000
Ken Sharp <ken.sharp@artifex.com>
a3cc9ea512025960b68deca87170053e43393dbc

> PDF interpreter - handle (invalid) PS CMap streams
> Bug #696449 "Incomplete rendering of PDF file"
> The file includes a CIDFont which uses a custom CMap, which is incorrectly
> defined. CMaps in PDF files are specified to be a CMap stream, that is a
> dictionary declaration followed by a stream of data. The dictionary
> should contain the CMApName, the CIDSystemInfo and WMode.
> The supplied file has a stream which is simply a PostScript CMap, it
> does not include any of the required definitions, and is, as far as I can
> see, therefore invalid.
> Nevertheless 'Acrobat can open it', so I've modified the type 0 font
> and more specifically the CMap interpretation, to read a PostScript
> CMap. This is not as easy as it may seem, and there may still be
> problems with this code, because PostScript CMap files are normally
> (unsurprisingly) run in a PostScript interpreter. Trying to handle them
> without executing them in a PostScript interpreter is tricky. We can't
> simply execute the PostScript (which would be ideal) because we need to
> alter the CMAP Type.
> This commit also contains a minor change to make Annotation processing
> check the PDFSTOPONERROR flag when running annotations, and if it is set
> cease processing, instead of ignoring the error.
> Resource/Init/pdf_font.ps
> Resource/Init/pdf_main.ps

2015-12-14 10:31:56 +0000
Chris Liddell <chris.liddell@artifex.com>
18e58518812980b09215ae17b8c385cdb46fda19

> JPEG/DCT dependency fix
> Because we have common code to handle certain aspects of JPEG/DCT encoding and
> decoding, we cannot include one without the other.
> Add a "top level" sdct.dev which includes both sdcte.dev and sdctd.dev and make
> that part of the core graphics lib features.
> As our code and the libjpeg code both have considerable common code between
> encoding and decoding, the inpact on the executable size is negligible.
> Makefile.in
> base/lib.mak

2015-12-11 14:02:24 +0000
Chris Liddell <chris.liddell@artifex.com>
1dccf1916e1227e66ffdfbbd0d99c385268f60db

> Bug 695576: tidy up xpsprint dependency confusion
> Promote the pushing of jobs into the XPS print queue to be a "platform"
> feature - i.e. make it a required "gp_" call, with a real one for Windows
> (when supporting libs are available) and a dummy for when an XPS print queue
> is not available.
> This eases the confusion of dependencies and removes the need for platform
> specific conditionally compiled code in the xpswrite device code.
> base/gp.h
> base/gp_nxpsprn.c
> base/gp_wxpsprn.cpp
> base/lib.mak
> base/macos-mcp.mak
> base/openvms.mak
> base/unix-aux.mak
> base/winlib.mak
> base/winplat.mak
> base/xpsprint.cpp
> devices/vector/gdevxps.c
> psi/os2.mak

2015-12-11 12:02:41 +0000
Ken Sharp <ken.sharp@artifex.com>
fabc4fb245306177204bf9439424cca33132b6fa

> PDF interpreter - fix OutputIntent for device when no Trailer located in PDF (broken)
> Bug #696447 "Error message lost with x11 device"
> Despite the comment, I believe the X11 device behaviour is correct. We
> generally try not to throw PostScript errors when dealing with PDF files,
> even badly broken PDF files.
> In this case the PDF is so broken we are unable to repair it (Acrobat
> can't either), which means we have no Trailer either found or created.
> However, we must continue with our processing loop and that includes
> processing OutputIntents, if the device supports them.
> The X11 device (and the Windows display device amongst others) do *NOT*
> support an OutputIntent (its not file based so there's nowhere to put it)
> but the ppmraw device, erroneously I believe, does claim to be able to
> write an OutputIntent.
> This led us into code in writeoutputintents whcih attempted to use the
> Trailer without checking if it was present, and so throwing an error.
> This commit simply checks if we have a Trailer, and doesn't attempt to
> write the OutputIntent if we don't (because the PDF is unusable anyway)
> This makes the devices behave the same, even though its not exactly
> the fix Marcos wanted.
> Resource/Init/pdf_main.ps

2015-12-11 11:02:14 +0000
Chris Liddell <chris.liddell@artifex.com>
e8a5151dcc3a3451a42a294ed7bddbf137ddf518

> Bug 696446: only use const strings for param list keys
> The original fix replaced uses of strdup() (which caused a memory leak) with
> a dynamically allocated temporary string which was freed at the end of
> cups_get/put_params().
> Unfortunately, as param lists simply take a reference to the key string, this
> meant that the contents of the string were overwritten, and indeterminate
> after being freed.
> Switch to using lists of static const strings.
> And add a stern warning to gsparams.h on the subject.
> And squash a couple of compiler warnings in the cups code.
> base/gsparam.h
> cups/gdevcups.c

2015-12-10 16:11:30 +0000
Ken Sharp <ken.sharp@artifex.com>
546d49f920ed3b1d7f8eec26ae1c8d94b7d6fd32

> PDF interpreter - don't store ICCBased colour spaces in resolved dicts
> Bug #696439 "unable to extract page one special page"
> The page in question has nearly 2000 images, most in ICCbased colour
> spaces, and large profiles (around 2MB or more). Because of the way we
> dereference objects, this led to the ICCbased DataSource (the 2MB+)
> being stored in the colour space, which was stored in the image
> dictionaries, which were stored in the Page's Resources dicttionary.
> The Page's Resources dictionary is not freed until the page is complete
> which meant we were storing an awful lot of data. When we exceeded 2GB
> (on the 32 bit build) we ran out of memory and mostly stopped rendering
> anything further.
> This commit alters the image (and shading, which has the same problem)
> handling so that if the colour space is an array object, we make a copy
> of the dictionary and use that. This leaves the original definition
> unresolved in the Page's Resources dictionary, if we should need to use
> the object again then we will have the (slight) overhead of needing to
> rerun it, but at least we won't be storing gobs of mostly useless data
> in the general case.
> No differences expected.
> Resource/Init/pdf_draw.ps

2015-10-12 18:37:32 +0100
Chris Liddell <chris.liddell@artifex.com>
bcf0e5887c74e3337fcac62addf0de70be9a2cb8

> Commit of WOFF font support for GS
> Support in Ghostscript is implemented by augmenting the TrueType handling in
> the Postscript world. Loading WOFF fonts "stripped" is not supported, except
> for the purpose of finding the font name from the name table.
> There is also a C implementation in the graphics library which takes a memory
> buffer or a stream, and unpacks the WOFF into a TTF in a memory buffer. It
> is currently not called.
> Resource/Init/gs_cff.ps
> Resource/Init/gs_cidtt.ps
> Resource/Init/gs_ttf.ps
> base/gstype42.c
> base/gsutil.c
> base/gsutil.h
> base/gxfont42.h
> base/lib.mak

2015-12-09 18:09:12 +0000
Chris Liddell <chris.liddell@artifex.com>
618d0c07922e47b869cdec48235ff003c791d2e3

> Bug 696441: handle numcopies > 1 in bgprint mode.
> When numcopies is greater than 1, the device closes and closes and opens
> the output file(s) for each copy. In the case of background printing, the
> main device opens the output file, and generally expects to close the same
> file, but with num_copies > 1 that is not the case.
> When shutting down a bgprint "worker" device, copy the file pointer from
> the worker device to the main device, so the main device retains a valid
> output file pointer.
> base/gdevprn.c

2015-11-04 15:47:02 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
47dd8a92aeb7b574748871127a6621ce9f7abbb9

> Fix memory leaks in cups device
> Noticed while debugging Bug 694179.
> The main leak here is due to the strdup in cups_get_params and cups_put_params.
> The code was then refactored to have one exit point to catch the remaining
> 6K leak.
> However, the final 6k is due to the global structure created in
> cups_globals_alloc and later freed in cups_globals_free. The free function
> call is only done on windows due to a #define WIN32 and not called on a
> Linux machine where the server continues to run.
> No cluster differences
> cups/gdevcups.c

2015-11-04 15:42:53 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
160665445b3b10da794959e508b5dd800b0592e5

> Bug 694179: Fix memory leak in jbig2dec
> Ensure the image contents are initialised, so that, if an error occurs, the
> image can be safely cleaned up.
> No cluster differences.
> jbig2dec/jbig2_text.c

2015-09-23 20:35:09 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
24c38f914a24391f880e2fd73423dff9cc9a678f

> Bug 694180: Fix memory leak if there is an error while parsing jbig2 global stream.
> base/sjbig2.c

2015-12-04 17:46:33 -0500
Chris Liddell <chris.liddell@artifex.com>
fb89b8a3a9f58898402750dbcef43156e54d0118

> Bug 695771: multithread/bgprint render may not be complete device shutdown
> In some cleanup code, I assumed that by the time that code was called, rendering
> would be complete - specifcally, background rendering would be complete.
> This may be true when background rendering is one thread, but is definitely not
> guaranteed when we have bgprint *and* multithreaded rendering.
> Rather nicely, accounting for this actually makes the code tidier.
> Also, add a check that we successfully created a clist IFILE object before
> storing a value in it.
> base/gdevprn.c
> base/gxclfile.c

2015-12-04 21:29:05 +0000
Ken Sharp <ken.sharp@artifex.com>
80539e002a8a2feed7a1d34608980c3a0d13dbbc

> pdfwrite - fix array dta source mesh shadings
> Bug #696433 "Indeterminism with Bug695847b.ps and the pdfwrite device"
> The code for emitting a mesh shading in a PDF given floating point
> input (array based vertex data, at least) calcul;ates the number of
> colour samples by multiplying the number of componentsd in the colour
> space by the number of vertices.
> However, when applying the max/min clamping from the ranges array in the
> colour space, it used the current colour sample index, which obviously
> could be much larger than the number of components in the colour space.
> This caused us to run off the end of the pranges array and use
> uninitialised data to set the colour sample, leading to non-deterministic
> (and indeed incorrect) output.
> We now pass in the number of components in the colour space and use the
> modulus of that with the colour value index to index the pranges array.
> devices/vector/gdevpdfv.c

2015-12-01 16:47:47 -0500
Chris Liddell <chris.liddell@artifex.com>
17e2a278e9a4adfd534941813075e428f3ea7966

> Make writing TIFF DateTime tag optional.
> Add a -dTIFFDateTime option, defaults to "true" (existing behaviour) and
> -dTIFFDateTime=false prevents the tag being written to the output file.
> Also, document this and the UseBigTIFF option.
> devices/gdevtfax.c
> devices/gdevtfnx.c
> devices/gdevtifs.c
> devices/gdevtifs.h
> devices/gdevtsep.c
> doc/Devices.htm

2015-12-04 17:04:22 +0000
Ken Sharp <ken.sharp@artifex.com>
44c63aecd4d13f47e0f75e74f63f38715ab7ab73

> EPSFitPage - fix some kinds of rotation
> Bug #696128 "Rendering an EPS to a PNG with -dEPSFitPage and -gWxH sometimes results in blank render"
> There was a typo in commit d59e1feb9545b399027907cb2d1a6855c524e0b4 which
> prevented proper rotation in some cases. Note that in this particular
> case we do *NOT* want to rotate.
> Resource/Init/gs_epsf.ps

2015-12-04 07:01:38 -0800
Ray Johnston <ray.johnston@artifex.com>
4703d04a6146904cab9b1b04aee1478e31df52da

> Fix bug 696258: Crash with mswinpr2 device due to typo.
> There was a typo in win_pr2_getdc was calling gs_strtok with the "last"
> parameter being a value instead of a pointer to the buffer.
> devices/gdevwpr2.c

2015-11-29 18:12:02 -0800
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
237f98e6abb42407466240585b897b5190b68053

> Document that the -c option should be specified after other otions (Bug 695293).
> doc/Use.htm

2015-11-27 10:08:40 +0000
Chris Liddell <chris.liddell@artifex.com>
e1af9ed039398be924e31179e6b742682f49e772

> Bug 689856: CIE cache: account for different sizes of ulong
> Handle both 32 bit and 64 bit ulong sizes.
> psi/zcolor.c

2015-11-24 11:52:42 +0000
Chris Liddell <chris.liddell@artifex.com>
96d5dc98103b6adab46efa4baeb19535675929b8

> Docs: Add words about soon removing DisableFAPI
> doc/Use.htm

2015-11-26 20:03:23 -0800
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
5596cc435aec8387ddd2e64437f1f9486f3ee5c6

> Fixed call to Luratech JP2_Compress_SetLicense() (Bug 695768).
> The Luratech JP2_Decompress_SetLicense() routine was being called instead
> of JP2_Compress_SetLicense() in the compression section. Thanks for
> Rodrigo Terra for the finding this.
> Untested since Ghostscript doesn't use this code.
> base/sjpx_luratech.c

2015-11-24 16:54:55 +0100
Tor Andersson <tor.andersson@artifex.com>
d8ee66a742b9dbc006dd69e6049d9acfef4ad89f

> xps: Fix warnings.
> xps/xpspath.c

2015-11-24 13:10:48 +0100
Tor Andersson <tor.andersson@artifex.com>
86a2f29eddb0addaa1c72bd7967748083fb6be3c

> xps: Multiply alpha from opacity attribute with alpha from color attribute.
> xps/xpsglyphs.c
> xps/xpspath.c

2015-11-24 13:02:09 +0100
Tor Andersson <tor.andersson@artifex.com>
b4393aa83107a484cafc59241eac964fc5a6e560

> xps: Support AlternateContent compatibility markup.
> xps/ghostxps.h
> xps/xpscommon.c
> xps/xpspage.c
> xps/xpsxml.c

2015-11-20 12:51:09 +0100
Tor Andersson <tor.andersson@artifex.com>
286433913eeaa01d53e5225b524afb56039cdde8

> xps: Fix potential memory leak.
> xps/xpspage.c

2015-11-20 12:50:52 +0100
Tor Andersson <tor.andersson@artifex.com>
7ab039de8626a3052483aeb806186aaa4079e925

> xps: Add more warning messages.
> xps/xpsdoc.c
> xps/xpstile.c

2015-11-19 15:10:36 +0100
Tor Andersson <tor.andersson@artifex.com>
7ea84e45f743381e2b47d94a3718a400904ba45f

> xps: Avoid generating unnecessary linetos for arcs.
> xps/xpspath.c

2015-11-19 11:38:55 +0100
Tor Andersson <tor.andersson@artifex.com>
cba41adae8a388156f8e4eae29cbf1cd5a61cd1e

> xps: Avoid ctype.h
> xps/xpsglyphs.c

2015-11-19 11:34:14 +0100
Tor Andersson <tor.andersson@artifex.com>
40e2a79e7e4c223c4219b12020fde906df5fd91e

> xps: Use xps_strlcpy instead of strcpy when parsing colors.
> xps/xpscolor.c

2015-11-17 16:54:23 +0100
Tor Andersson <tor.andersson@artifex.com>
100dff645dbb231de77e7b2f347a459490213bef

> xps: Check that we have the last piece of multi-part zip entries.
> xps/xpszip.c

2015-11-12 16:57:45 +0100
Tor Andersson <tor.andersson@artifex.com>
ef0b983d909787c0a2ace46f61993af84ec32f66

> xps: Add special case handling of zero-length dash patterns.
> xps/TODO
> xps/xpspath.c

2015-11-18 15:43:40 +0100
Tor Andersson <tor.andersson@artifex.com>
0833727c2a2e23daefd2721f64d7fb9e02ee3049

> xps: Bail on zip errors instead of returning a part full of garbage.
> xps/xpsimage.c
> xps/xpszip.c

2015-11-18 15:36:57 +0100
Tor Andersson <tor.andersson@artifex.com>
15a26a58d1cedf0ab2ad7a968ea2ac5a58e48842

> xps: Fix uninitialized value.
> xps/xpspath.c

2015-11-13 16:33:42 +0100
Tor Andersson <tor.andersson@artifex.com>
7b91a3627f29ab0c831a56bc5585a5895398279e

> xps: Various arithmetic and uninitialized value fixes.
> xps/xpsgradient.c
> xps/xpsimage.c
> xps/xpspath.c

2015-11-23 08:05:58 -0700
Henry Stiles <henry.stiles@artifex.com>
ac252acf1dec30c24bbba9adfc3140fb23a41d7b

> Tidy up a few comments.
> base/gslibctx.c

2015-11-23 07:24:49 -0700
Henry Stiles <henry.stiles@artifex.com>
65ad11d96a83783a71e9e0a2ff8534bf0cdd9864

> Fix the gs library context's allocator use.
> The gs library context now uses the allocator with which it was
> initialized for all memory operations. Previously it used different
> allocators, resulting in mismatched alloc/free pairs. For example, the
> languages passed in a memory pointer to the heap allocator upon
> initialization of the context and then passed in a memory pointer to chunk
> allocator when the library context is shut down.
> base/gslibctx.c

2015-11-20 13:56:33 -0800
Ray Johnston <ray.johnston@artifex.com>
c8bc794d9e9fe9c03d1519cf2a70f70a2d0784d8

> Improve documentation and fixup toolbin/halftone tools
> The thresh_remap (previously referred to as linearize_threshold) was
> never in the package, so add it in a separate directory, and fix the
> reference to it in gen_ordered.c
> Add README files for the upper level, for thresh_remap and for the
> gen_stochastic directories, so people don't have to read the code to
> find the parameters.
> Fix gen_stochastic minimum dot logic to actually work, although only
> the 2x2 (-m5) parameter was tested. Also change the defaults for the
> tolerance, -t, to 10 (1%) and exponential factor affecting choice, -p,
> to 2.5 both of which tighten the selection to improve the quality (at
> least in my opinion).
> toolbin/halftone/README
> toolbin/halftone/gen_ordered/gen_ordered.c
> toolbin/halftone/gen_stochastic/README
> toolbin/halftone/gen_stochastic/gen_stochastic.c
> toolbin/halftone/gen_stochastic/gen_stochastic.sln
> toolbin/halftone/gen_stochastic/gen_stochastic.vcproj
> toolbin/halftone/thresh_remap/README
> toolbin/halftone/thresh_remap/thresh_remap.c
> toolbin/halftone/thresh_remap/thresh_remap.sln
> toolbin/halftone/thresh_remap/thresh_remap.vcproj

2015-11-19 14:16:46 +0000
Chris Liddell <chris.liddell@artifex.com>
ecd8816ca46c15da304d6bc93f79f39d47c51952

> Bug 696363 & 696362: wrong error code return.
> The FAPI/UFST code was returning a "limitcheck" error when no glyph raster was
> available, when it should have been "unregistered".
> This caused problems when I added the return code checks to address some
> Coverity warnings.
> base/fapiufst.c
> base/gxfapi.c
> psi/zfapi.c

2015-11-19 14:14:27 +0000
Chris Liddell <chris.liddell@artifex.com>
92f236c7f2293db8aeae437ac0800617552d6e63

> Bug 696357: correctly check the length of a string
> Indeterminism in 34_all.PS: the check on the size of the string containing the
> font's CIDMap was incorrect leading to reading off the end.
> psi/zfapi.c

2015-11-16 17:26:56 +0000
Chris Liddell <chris.liddell@artifex.com>
0ec425689333b77b9badd8585989e15655d740c1

> Bug 696316: Enforce memory alignment for libpng
> libpng's inclusion of it's jmp buffer at the beginning of it's private context
> requires the allocation to be 16 byte aligned on Win64 (because the jmp
> buffer must be 16 byte aligned).
> In the libpng callback functions for memory allocationg and freeing enforce
> that alignment.
> Also, add those callbacks (including the alignment enforcement) to the gdevpng.c
> output device.
> (Code mostly supplied by Robin!).
> No cluster differences.
> devices/gdevpng.c
> xps/xpspng.c

2015-11-18 10:59:13 +0000
Ken Sharp <ken.sharp@artifex.com>
d368650e9f3e7e6e4af2d840ffa0dd1e161a9694

> PDF Interpreter - Handle incorrect /Size in Xref streams
> Bug #696365 "Error reading PDF file"
> The PDF file is, as usual, invalid. It uses Xref streams and is a
> Linearized file, meaning that there are two Xrefs, the first one being
> for page 1 (caused by Linearization).
> This xref looks like ths:
> <<
> /Size 12
> /Root 30 0 R
> /Prev 15073
> /Info 28 0 R
> /ID[<B6AEC95A19F1E4391AFF6AF538489730><B6AEC95A19F1E4391AFF6AF538489730>]
> /Type/XRef/Index[29 39]/W[1 4 1]/Filter /FlateDecode /Length 112
> >>
> Notice that the Size (the number of entries in the xref) is given as 12
> but the Index (starting index + number of entries) gives the size of the
> table as 39, starting at index 29.
> We were believing the Size, which meant that we created a Xref table
> which was too small to hold the actual number of entries.
> This commit checks both 'starting index + number of entries in the Index'
> and 'starting index + Size' and uses the larger.
> NB the xref also contains an entry with an invalid offset, but this does
> not seem to cause a problem, presumably the entry is never actually used
> Resource/Init/pdf_main.ps

2015-11-17 13:34:45 +0000
Ken Sharp <ken.sharp@artifex.com>
5e8eae05c4629217f87eaab7302ac7b880dd9c7c

> Hash CIE spaces to detect matching, cached, ICC profiles
> Bug #696355 "Create unique ID for CIE color spaces"
> Creating an ICC profile for a PostScript colour space is a performance
> hit. Especially (I believe) for CIE spaces. We maintain a cache of ICC
> profiles that have been created, but we need a way to identify if a
> given, cached, profile matches a newly selected colour space.
> There is code already in place for this, but missing the generation of
> a unique ID for a space, so that we can find a matching profile, if we
> have one cached.
> This commit uses the existing MD5 machinery to create a hash from the
> PostScript array defining a CIEBased colour space. We then use that hash
> as the ID for the space, and check to see if we already have a cached
> ICC profile with a matching ID.
> This should improve performance on files using CIEBased colour spaces,
> especially if they do 'gsave [/CIEBased <<...>>] setcolorspace grestore'
> operations, as we will only need to create the ICC profile once.
> I've created and manually checked example CIEBasedA, CIEBasedABC,
> CIEBasedDEF and CIEBasedDEFG files to see that two identical spaces are
> correctly identified as the same and that spaces with even very tiny
> differences are correctly identified as different.
> No differences expected in cluster test.
> psi/zcie.c
> psi/zcolor.c

2015-11-16 12:46:18 +0000
Chris Liddell <chris.liddell@artifex.com>
70880b866b06e34e4c078e115001371ae8e9c454

> Docs: Remove references to OS X framework
> No cluster differences
> doc/API.htm

2015-11-16 12:30:59 +0000
Chris Liddell <chris.liddell@artifex.com>
ff6175631e7b8c79849d6de637aaaf5338476d62

> Bug 696352: initalise io dev table count variable.
> Previously the io device count was only initalised when the library context
> was created, but it seems the library context can survive multiple
> instances of the interpreter.
> Initialise the count variable every time a new io device table is created.
> No cluster differences.
> base/gsiodev.c

2015-11-16 09:17:19 +0000
Ken Sharp <ken.sharp@artifex.com>
5757d87431c31cf99ea294697382239ab74d424e

> graphics library - if pattern x or y size is 0, don't estimate tile size
> Inspired by Bug #696351
> The bug report in Bug #696351 is ridiculously incomplete and the reporter
> seems determined not to provide any real assistance.
> However, by some logic and experimentation it did prove possible to
> (eventually) reproduce the problem and trace through the code from
> pattern creation. (run with a very low resolution, -r10 did it for me)
> The crash is caused by attempting to estimate the size of a pattern
> bitmap tile, when the pattern has a size of 0 in the y direction. This
> is a legitimate value, we simply drop the pattern in this case. Since
> we aren't going to render anything, the tile will have a size of 0 so
> we can easily short-circuit all this calculation by testing for the tile
> being 0 in either the x or y direction and simply returning 0.
> No differences expected.
> base/gxpcmap.c

2015-11-13 11:55:20 +0000
Chris Liddell <chris.liddell@artifex.com>
e21aae2ee801a6468e44697970d11d4d56d0c6ab

> Bug 694237: Handle missing/incomplete TTF glyph lengths
> In the case of a broken TTF based CIDFont passing through ps2write (or one of
> the pdfwrite paths that requires glyphs to be rendered), we can end up with
> a partially complete font structure - in particular, the glyph lengths table
> may be incomplete or missing.
> We have a couple of fallback options available to get the length of a glyph:
> the first is to retrieve the offset of the data for *next* glyph index and
> the difference between the two offsets is the length of the glyph of interest.
> If that fails (particularly if we are already processing the last available
> glyph), we can use the offset to the end of the sfnt data - since the glyph
> table is invariably the last table in the sfnt stream.
> No cluster differences.
> psi/zfapi.c

2015-11-13 08:48:35 +0000
Chris Liddell <chris.liddell@artifex.com>
5aa97eed0f8b17ea0f7138d36d64af505420caa1

> Bug 696345: .nativeFontmap when TTF name table is invalid
> When building the .nativeFontmap (using fonts retrieved from a platform
> specific API - i.e. fontconfig), if we can't read the font name from the
> font file, we fall back to using the font name as reported by the API.
> But, the code failed to take into account that the operand stack has different
> depth depending on whether we were able to read the name from the file or not.
> This commit handles that by using a counttomark rather than hard coded stack
> depth.
> No cluster differences.
> Resource/Init/gs_fonts.ps

2015-11-12 17:22:42 +0000
Chris Liddell <chris.liddell@artifex.com>
dfe06d0d8b3f296b908709c22157f7135ed660c7

> Bug 694238: init several gs_glyph_info_t structs
> In various places we were calling a font's glyph_info which may, or may not
> fully fill in the gs_glyph_info_t passed to it, then using the results,
> regardless of whether the specific value had been set. Initialize to zeros
> for at least consistent results.
> No cluster differences.
> base/gsfont.c
> devices/gxfcopy.c
> devices/vector/gdevpdte.c

2015-11-12 17:17:03 +0000
Chris Liddell <chris.liddell@artifex.com>
01cb2de3fbbcfa7c7f809176bb72249831d93b98

> Bug 694238: Fix segfault in error during PatternType 1
> If the PaintProc of a Type 1 pattern triggers an error after having done one
> or more gsaves, we'll try to retrieve the pattern instance from the wrong
> graphics state when we attempt the final cleanup.
> To address this, store a reference to the pattern instance on the exec stack
> which a) guarantees we get the correct pattern instance during cleanup,
> and b) allows us to roll back the graphics state stack to the correct point.
> No cluster differences.
> psi/zpcolor.c

2015-11-13 08:20:39 +0000
Chris Liddell <chris.liddell@artifex.com>
daf28428a76f3a89a9cff9285cb7b0a663a86b63

> Coverity: fix some ignored return codes in FAPI
> No cluster differences.
> base/gxfapi.c

2015-11-12 16:25:54 +0100
Tor Andersson <tor.andersson@artifex.com>
e85900d1814a65918b9c7e90504e25155ae0b9c1

> xps: Return with error on encrypted zip files.
> xps/ghostxps.h
> xps/xpszip.c

2015-11-12 16:27:06 +0100
Tor Andersson <tor.andersson@artifex.com>
9d1c199af467cd1138bf07c6f66a276e26875c99

> xps: Fix buffer overflow in xps_parse_color.
> xps/ghostxps.h
> xps/xpsanalyze.c
> xps/xpscolor.c
> xps/xpsglyphs.c
> xps/xpspath.c

2015-11-12 16:24:30 +0100
Tor Andersson <tor.andersson@artifex.com>
0fa7177163f46c77f7928c520ddc3f90de4c59dc

> xps: Fix indeterminism with broken zip files.
> xps/xpszip.c

2015-11-12 16:13:05 +0100
Tor Andersson <tor.andersson@artifex.com>
9b4be4d130b37578be55eb6aae4feb8a57c0636d

> xps: Fix gradient ordering edge case.
> Gradients in XPS code are ordered by offset. If however two offsets are
> equal, the order of the colors depends on the sort algorithm instead of
> the original order in the document. This is shown e.g. in 2245*.xps:
> <GradientStop Offset="0" Color="#ff00ff00" />
> <GradientStop Offset="0.5" Color="#ff0000ff" />
> <GradientStop Offset="0.5" Color="#ff00ff00" />
> <GradientStop Offset="1" Color="#ff00ffff" />
> Tracking the original order of gradient stops and always sorting earlier
> stops first makes gradient ordering consistent.
> xps/xpsgradient.c

2015-11-11 16:59:22 +0000
Ken Sharp <ken.sharp@artifex.com>
bb56dc645039d5a2f376920af1023b7ece801c88

> PDF Interpreter - Ignore empty /Kids arrays in AcroForm fields
> Bug #696342 "PDF Annotation Error: /rangecheck in --run--"
> The PDF file has an AcroForm with a field where the /Kids array is [ ]
> This previously caused an error.
> Adopting the patch from Martin McNabb with a very slight tweak to issue
> a warning if -dQUIET isn't set.
> Bizarrely this does exhibit a progression with Bug694429.pdf on the
> cluster, even though this code isn't executed......
> Its a progression so I'm not going to complain.
> Resource/Init/pdf_draw.ps

2015-11-09 10:33:16 +0000
Ken Sharp <ken.sharp@artifex.com>
e174b0553e6e2d3bb641cbede1187dfe7979ae86

> PDF interpreter - Allow Shading whose Extend array contains indirect refs
> Bug #696338 "Garbled output - File has unbalanced q/Q operators (too many Q's)"
> A Shading dictionary contains (bizarrely) an Extend array which has
> members which are indirect references instead of simple booleans.
> Mad, but legal.....
> This commit adds the Extend array to shrdict, which does additional
> processing of the Shading dictionary before passing to the graphics
> library. In this case we simply dereference the objects.
> No differences expected.
> Resource/Init/pdf_draw.ps

2015-11-04 16:08:13 -0800
Ray Johnston <ray.johnston@artifex.com>
f330b5d4bdae73f9ca88c04e2a1391800c5da758

> Fix Bug 696324 SMask None handled incorrectly by clist writing.
> The SMask None special case that is sent using gssmask in the PDF
> interpreter when it needs to make sure there is no SMask in place
> needs special handling w.r.t. the clist cropping logic since we do
> want to write it, but there won't be a endtransparencymask to
> perform the pop of the cropping stack.
> base/gdevp14.c

2015-11-02 15:17:45 +0000
Chris Liddell <chris.liddell@artifex.com>
142820542bb883e304788bd4dcc2833b6486cf6d

> Bug 693011: stop PSD devs writing multiple images to one file
> PSD does not support multiple pages/images per file. Previously the PSD devices
> would allow writing multiple image to the PSD output file, and end up with an
> invalid PSD file.
> The devices will now check what the output name file has the "%d" formatter to
> so each page written to a separate file, and if it isn't there, they will
> generate an error message and error code if an attempt is made to produce
> more than one page.
> To be clear: and single page input file will complete without error without the
> "%d" formatter.
> No cluster differences
> base/gdevdevnprn.h
> devices/devs.mak
> devices/gdevcmykog.c
> devices/gdevpsd.c
> devices/gdevpsd.h
> doc/Devices.htm

2015-11-02 15:16:26 +0000
Chris Liddell <chris.liddell@artifex.com>
4c6f80586f047561c5ed4e2f9d3a307c2ca6099f

> Add Art/Bleed/Trim boxes to pdf_info.ps
> No cluster diffs.
> toolbin/pdf_info.ps

2015-11-03 19:25:38 +0000
Robin Watts <robin.watts@artifex.com>
3d2d28598857d94b4c4683fe3ae5a0a71fdfe17d

> Bug 696305: Ensure subdivided lines are not dropped
> While walking the contour in scan_contour, we use
> gx_flattened_iterator to cope with flattening curves.
> Each time we call gx_flattened_iterator__next we get the
> next section of the line out.
> To avoid overflows in huge lines/curves the iterator splits
> segments into 4. This was showing up a problem in this code
> whereby a vertical line from 0x80xxxxxx to 0x7fxxxxxx was
> being split into 4. 2 of these sub-divided lines crossed the
> region of interest, but only the first of them was being
> considered for addition into the active line list.
> The fix here is simply to ensure that we continue to loop
> through the iterator for the curve if we fail to add anything
> from it.
> It is possible that there are further optimisations possible
> here (see the FIXMEs in the code), but the changes I've made
> should be safe and minimally invasive.
> Many thanks to Chris for doing the legwork in tracking the
> cause down!
> base/gxfill.c

2015-11-03 13:41:20 +0000
Robin Watts <robin.watts@artifex.com>
35148ae2ffd20e949e01da427a82a6eee20b7127

> Bug 696305: Revamp scan_contour
> As part of the investigation into bug 696305, rejig the functions
> around 'scan_contour' for clarity.
> Firstly, we pull the usage of contour_cursor into scan_contour.
> Rather than having the caller set part of the structure up, and
> then pass it in, have the caller pass in the required parts and
> let all of the structure handling be done within scan_contour.
> This improves the modularity of this code at least.
> Secondly, rather than having the contour_cursor structure contain
> a pointer to a gx_flattened_iterator allocated separately on the
> stack, have it be part of the structure. This saves lots of
> dereferencing (which might help with repeated reads due to C's
> pointer aliasing) and is clearer to read.
> Thirdly, we break the if's into more deeply nested things. This
> results in more indented code, but it avoids us having to retest
> the same variables several times, and may give us some improvement
> in runtimes.
> Firstly, add some comments. This is a break with tradition in
> this code. These comments describe my understanding (however
> limited) it may be of what the code is doing.
> base/gxfill.c
> base/gxfill.h
> base/lib.mak

2015-11-03 09:07:27 +0000
Ken Sharp <ken.sharp@artifex.com>
7fbc6ddf76a5590252dc25642ae13da15f2a92db

> pdfwrite - prevent selection of inappropriate Downsample filter
> Bug #696322 " GS produces empty PDF with /MonoImageDownsampleType /Bicubic"
> We can't use anything except Subsample for Monochrome images, because
> anything else will turn them into grayscale images.
> This commit prevents the selection of any downsampling filter if the
> image is monochrome, using the default Subsample.
> No differences expected
> devices/vector/gdevpsdi.c

2015-11-03 08:21:37 +0000
Chris Liddell <chris.liddell@artifex.com>
de66bba6a320e7b263260205637976c734805909

> Fix PCL/XPS Windows builds from previous commit
> A typo and a missing header caused the Windows PCL/XPS builds to fail.
> No cluster differences.
> pcl/pl/plwmainc.c

2015-11-02 12:37:37 +0000
Chris Liddell <chris.liddell@artifex.com>
6b1b1d72ed6432bc29b719e186ea8ebd0b26de8a

> Expunge references to e_* style errors
> No cluster differences
> base/fapibstm.c
> base/gp_unifs.c
> base/gpcheck.h
> base/gsiomacres.c
> base/sjpeg.h
> base/strmio.c
> contrib/japanese/gdevdmpr.c
> contrib/pscolor/test.c
> devices/vector/gdevpdfr.c
> devices/vector/gdevpdfx.h
> devices/vector/gdevpdtt.c
> doc/API.htm
> doc/C-style.htm
> doc/Develop.htm
> pcl/pcl/pcommand.h
> pcl/pl/plparse.h
> pcl/pl/plwmainc.c
> toolbin/halftone/gen_stochastic/gen_stochastic.c

2015-10-28 10:33:43 +0000
Chris Liddell <chris.liddell@artifex.com>
ac5d49f03f44aa45ba9a0788bbe351b0510a5bcc

> Coverity #94560: Protect from possible null ptr deref..
> Also ensure we always write a character to the character set.
> No cluster differences
> base/wrfont.c
> base/write_t2.c

2015-11-01 09:43:04 -0800
Michael Vrhel <michael.vrhel@artifex.com>
6c28ba38b907ec1c6a5755669ea0ecb55b95f8cc

> Bug 694982: DeviceN ICC Source Profiles
> The use of -sDeviceNProfile was broken when we introduced
> delayed initialization of the ICC profiles. This fixes
> the issue and adds a ReadMe to the example to explain why
> the orange and green colorants will be swapped from what
> happens when -sDeviceNProfile is not used.
> base/gsicc_manage.c
> toolbin/color/icc_creator/example/README.txt

2015-10-31 12:24:01 +0000
Ken Sharp <ken.sharp@artifex.com>
243614398b7bf3e8c4d080de7f8bbcb7436472cf

> Replacement fix for commit 487ed6
> Bug #696306 was originally fixed in commit 487ed6. After talking about
> it with Chris, it became clearer why I was unable to intercept the
> broken font where I wanted. gs_type1.ps contains a redefinition of
> .buildfont1, and this redefinition does not properly preserve the
> stack in the event of an error.
> If this was a simple procedure that would be understandable, but the
> redefinition is of a C operator, so not preserving the stack is actually
> wrong.
> The commit here corrects that problem, which enables me to intercept the
> error much later in the page rendering and do a considerably better job
> of correcting the problem. This now renders as per Marcos' Acrobat
> screenshot (but unlike mine).
> This fix should be used in preference.
> Resource/Init/gs_type1.ps
> Resource/Init/pdf_font.ps

2015-10-29 14:29:48 -0700
Michael Vrhel <michael.vrhel@artifex.com>
c938315af2a0d4d90a03a762d19d31bf35b47b07

> Bug 695042; -dUsePDFX3Profile with -dNumRenderingThreads issues
> When a PDF file has on Output Intent (OI) profile and we want
> to use it as the device profile or the proof profile, it is
> set for the device through a call from the interpreter in
> zset_outputintent. Unlike other profiles for the device,
> this profile is not a device param that is set with get/put
> params of a file name. Instead the profile is inside the source
> file that is being rendered.
> When the threads are set up in setup_device_and_mem_for_thread
> the icc profiles are set through put and get param calls. Since
> the OI profile is not available in this manner, this fails.
> This fix detects the presence of the OI profile during
> setup_device_and_mem_for_thread and clones the profiles.
> Doing a straight reference to the profile instead of cloning
> is problematic if the CMM is not thread safe in its use
> of the profile handles (which is true for LCMS), hence the
> cloning process.
> In addition, in this commit a non-ascii character was added to
> the special name for the OI profile to help avoid issues with
> an actual profile being named with our special key word.
> base/gsicc_manage.c
> base/gsicc_manage.h
> base/gxclthrd.c
> base/lib.mak

2015-10-30 11:58:21 +0000
Ken Sharp <ken.sharp@artifex.com>
487ed6d3b5fabbe21c23da288fbf020f49a28fae

> PDF interpreter - handle broken type 1 fonts with no Private dict earlier
> Bug #696306 "Incomplete rendering of PDF file"
> The embedded type 1 font 'Consolas' is broken. The eexec encrypted
> portion of the font suddenly ends during a glyph description. This means
> that the Private dictionary is never added to the font dictionary but is
> instead left on the operand stack. Where the PDF interpreter removes it
> in order to avoid other errors.
> The error actually occurs inside .buildfont1, but despite efforts it
> proved impossible to deal with the error at that point. This was due to
> all the code already in place to deal with other errors while handling
> broken PDF files. It wasn't possible to address this particular problem
> without breaking other (admittedly invalid) PDF files.
> This commit checks the font dictionary for the presence of a Private
> dictionary before returning from readtype1 and if the Private dict is
> not present it instead returns a null object, which signals the calling
> code to attempt to load the font from another source.
> No differences expected
> Resource/Init/pdf_font.ps

2015-10-29 09:59:13 -0700
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
e0498dcff844d119ee51873394aef93be5bfffc6

> Fix for transparency_example.ps to set the number of spot colors, Bug 695277.
> From Michael Vrhel:
> The ps file transparency_example.ps failed to set the number of spot
> colors on the page. This information is expected to be provided
> for the pdf14 device by the PDF interpreter when we are dealing with the
> separable devices (e.g. psdcmyk, tiffsep)
> examples/transparency_example.ps

2015-10-24 17:12:46 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
65b10e0fc85dc791848dbd43dbcf673669c1fc4c

> Bug 696222: Fix segfault due to image buffer being allocated too small leading to a memory over run.
> Also updated pclr functionality to detect BitsPerComponent early and so
> allowing the signature image to be decoded correctly.
> Signed-off-by: Henry Stiles <henry.stiles@artifex.com>
> Resource/Init/pdf_draw.ps
> base/sjpx_luratech.c

2015-10-23 10:11:14 -0700
Michael Vrhel <michael.vrhel@artifex.com>
d2c0a7d63b5a2b9b5e99883b89fc03b12f60b77d

> Handle NULL returns from gsicc_profile_new.
> Fix for bug 696268. Also clean up some of the other error handling
> in gsicc_create.c, gsicc_manage.c and gsciemap.c
> base/gsciemap.c
> base/gsicc_create.c
> base/gsicc_manage.c
> psi/zicc.c

2015-10-28 11:08:20 -0700
Michael Vrhel <michael.vrhel@artifex.com>
1a7740b8a021e2962964fcaf69dd0d95e1af5888

> Fix for crash in Bug 696290
> The planar devices were not getting the bit depth arrays set up.
> This was causing an issue during the gradient fill for high level
> colors where we were trying to make a smoothness decision during
> the line fills. Problem occurred for all the existing planar devices.
> devices/gdevcmykog.c
> devices/gdevpsd.c
> devices/gdevtsep.c

2015-10-27 10:08:57 -0700
Michael Vrhel <michael.vrhel@artifex.com>
0e95a71f661323214a4206f534068301b441dbe3

> Fix for bug 696227.
> The color usage information for the clist bands was not getting
> updated for certain cases where we are doing trapezoid fills.
> base/gxclrect.c

2015-10-26 11:01:16 -0700
Michael Vrhel <michael.vrhel@artifex.com>
aaefd493e35b75e761e542713d18cecabfe96593

> Add proper check for gx_dc_type_data_devn color type in shading color linearity
> When we added the gx_dc_type_data_devn to support the Device N planar devices,
> we failed to update the linearity check for shadings when we draw to these
> devices. This resulted in the linearity check always failing which resulted
> in extreme decomposition of the shading beyond what was needed.
> Fixes bug 696290. Note that a couple files like 442-01.ps will have some minor
> shading artifacts visible that were not there before for the psdcmyk device.
> I checked, and these same artifacts are visible in other CMYK devices (e.g. tiff32nc)
> for this file.
> These issues are different than what was addressed by this fix and should not
> be considered a regression by this commit. That said, we may want to open a bug
> related to those issues.
> base/gscspace.c

2015-10-26 08:32:32 +0000
Ken Sharp <ken.sharp@artifex.com>
dc5cae259b8f5b7dc4b6105f60b56af72fed235a

> check gp_fseek_64 return value and action it, silences Coverity CID 118348
> devices/vector/gdevpdfp.c

2015-10-22 12:27:50 -0700
Ray Johnston <ray.johnston@artifex.com>
59c818b145474f6e8a8dc315adaaa308f8e53aac

> Fix multi-threaded rendering crash on Windows. Bug 696254.
> The use of fseek(...SEEK_END)...ftell to determine the file size is not
> thread safe because reading changes the current position. On Windows, the
> ReadFile changes the position of the 'fd' attached to the stream and handle,
> and the ftell uses 'lseek(fd, 0, SEEK_CUR)' to get the current position
> which may have moved due to reads on other threads.
> On unix, similar conditions can occur sharing the FILE * stream. Also on
> unix, we must assume that without PREAD support, we cannot share the file
> descriptor since reading requires "ftell..seek..read..seek" sequences that
> are not thread safe without locking (that is not yet implemented, and may
> impact performance).
> Maintain the filesize while writing the file in the IFILE wrapper stucture
> and use that for the file size instead of fseek..ftell to avoid the position
> change that could happen on the clist file due to a read by a different
> thread on that same file fd.
> This was a rare problem because only cl_cache_read_init used the seek..tell
> mechanism to get the filesize, and this only happens in a thread on the
> first read (to either the bfile or the cfile) which is a narrow window.
> base/gp_unifs.c
> base/gxclfile.c

2015-10-23 11:16:20 +0100
Chris Liddell <chris.liddell@artifex.com>
fb1154ad98a2826679be009bf92576aaec99a4dd

> Bug 694149: Move copied font init earlier.
> When copying a font (for high level device use) we have to initialize at least
> some of the gs_font structure contents so that, in the event of a later fail,
> the font can be cleaned up, finalized and freed correctly.
> No cluster differences.
> devices/gxfcopy.c

2015-10-23 10:16:11 +0100
Chris Liddell <chris.liddell@artifex.com>
feafe5e540a0545ec5d28f3f66bb542056bba495

> Bug 696301: add gserrors.h to the installed files
> for the so-install target.
> Also remove a spurious (copy'n'paste error) comment.
> No cluster differences
> base/gserrors.h
> base/unix-dll.mak

2015-10-22 18:03:56 +0100
Chris Liddell <chris.liddell@artifex.com>
3ff82bf9367e36cf582811634cc37831907c439c

> Bug 694147: add stack checks in Type 1 charstrings
> Add checks for the both the operand stack and the 'control' stack during
> interpreting of Type 1 charstrings.
> No cluster differences
> base/gstype1.c
> base/gxtype1.h

2015-10-22 16:13:20 +0100
Chris Liddell <chris.liddell@artifex.com>
3be1a95a2b6e5a8a9c7472d077cdd454315a40fd

> Bug 696102: use gs_abort() instead of forced segfault
> In the garbage collector, in a condition that should not occur, gs_abort()
> is the correct way to bail out.
> No cluster differences.
> psi/isave.c

2015-10-22 16:11:57 +0100
Chris Liddell <chris.liddell@artifex.com>
c92c06899aab159ad2f60f69d3ce76ecdb03caff

> Add more details about COMPILE_INITS trade-offs
> No cluster differences
> doc/Make.htm

2015-10-22 15:35:57 +0100
Chris Liddell <chris.liddell@artifex.com>
f435300f1647be90380554b23099ae6dd047c6c0

> Tweak for CIDSystemInfo indirect object fix
> So these will be handled for all CIDFont types, and not just those with TTF
> outlines.
> No cluster differences.
> Resource/Init/pdf_font.ps

2015-10-22 10:35:50 +0100
Ken Sharp <ken.sharp@artifex.com>
34dba299b2f76c6ee6254950b5d32fd4026bd030

> Typo in .gitattributes, corrected eof to eol. Try and get line endings
> consistent in ghostpdf.inf
> .gitattributes
> lib/ghostpdf.inf

2015-10-22 10:33:15 +0100
Ken Sharp <ken.sharp@artifex.com>
0dd90a3cef222b7195459ee16dfcba0093c24b55

> remove the accidentally added ghostpdl.inf
> lib/ghostpdl.inf

2015-10-22 10:13:33 +0100
Ken Sharp <ken.sharp@artifex.com>
3e1089d53b8b44b9c0c0dcdcc493b7290f11773e

> Try again to get Git to change the ghostpdf.inf file
> lib/ghostpdf.inf

2015-10-22 10:02:36 +0100
Ken Sharp <ken.sharp@artifex.com>
0baeb24527e4d700cd2e0b0de30cfb58a9b3ba9c

> Touch the ghostpdf.inf file simply in order to get it to be updated in Git
> We need the ghostpdf.inf file to have consistent line endings across
> platforms (see commit c46f8651e6bea69b76f84dd58568c18fc73ade7d) simply
> updating the .gitattributes file doesn't seem to actually alter the file.
> lib/ghostpdl.inf

2015-10-22 09:48:02 +0100
Ken Sharp <ken.sharp@artifex.com>
c46f8651e6bea69b76f84dd58568c18fc73ade7d

> Make all '.inf' files have DOS/Windows line terminators
> This means that when checked out onto a Linux platform for building releases
> the line endings will still be 'correct' for DOS/Windows platforms and,
> more importantly, will be the same as was used when creating any '.cat'
> files which are used for digital signing.
> .gitattributes

2015-10-21 11:11:43 -0700
Michael Vrhel <michael.vrhel@artifex.com>
268bc03cbf664cad907f7a1f8ee9be7db93f9405

> Fix some of the paths in the visual studio project
> This fixes the paths for the openjpeg files. I don't see the jpegxr content in the project.
> Also the jpeg files need to be cleaned up. Some of the refs in the project are not really
> there.
> windows/ghostscript.vcproj

2015-10-21 10:55:12 -0700
Michael Vrhel <michael.vrhel@artifex.com>
3d4ade241415faeed82e8cc355f58c58d6b0b886

> Add name space definitions for Open XPS
> With this commit we should be rendering Open XPS content. Fix for bug 696272
> xps/ghostxps.h
> xps/xpsdoc.c
> xps/xpsxml.c

2015-10-21 10:19:26 +0100
Ken Sharp <ken.sharp@artifex.com>
1f0ad334a81e871dbbbc9929928ec025c616926a

> PDF interpreter - check for (illegal) non-dict XObjects when scanning spot colours
> Bug #696288 "Error: /typecheck in --run-- writing psdcmyk file"
> The PDF file contains a /Pages dictionary which includes a /Resources
> dictionary, this is consulted if a page calls for a resource which isn't
> defined in the page's own Resources dictionary.
> Unfortunately the XObject dictionary defined in this resource contains a
> reference to an object which is not an XObject.
> When scanning for transparency we deal with this (and ignore it) but when
> scanning for page spot colours, we do not, resulting in a typecheck error.
> This commit adds checking the XObject type when scanning for page spot
> colours, and ignores anything which isn't a dictionary.
> No differences expected.
> Resource/Init/pdf_main.ps

2015-10-21 09:20:42 +0100
Ken Sharp <ken.sharp@artifex.com>
56aa405c6d7913701091ce58370679b571690d82

> PDF interpreter - ignore indirect references to invalid object number 0
> Bug #696289 "**** Unrecoverable error in ref! writing PDF file"
> The Outlines tree is referenced indirectly as "0 0 R" which is invalid
> (object number 0 is reserved). The resolveR routine which resolves indirect
> references checks the validity of the object number but was checking for a
> value *less* than 0, when it should have been less than or equal.
> This commit alters the lt to le, which allows the file to be processed, of
> course there are no Outlines present since those were originally broken.
> Note this only exhibits with high level devices because rendering devices
> cannot usefully use the Outlines tree, and ignore it.
> No differences expected.
> Resource/Init/pdf_base.ps

2015-10-19 16:35:51 -0600
Henry Stiles <henry.stiles@artifex.com>
3777fa7d9a00158ed2b84de1b547b5fe4a8241dd

> Undo mistakenly added debug code from the last commit.
> base/gsalloc.c

2015-10-19 15:59:57 -0600
Henry Stiles <henry.stiles@artifex.com>
e0ce584138cbc37c91e757a18d9946b02d3abd03

> Fix crash in language switch build introduced by an API change in
> ghostscript argument processing.
> The language switch system is being reworked but it is nonetheless
> useful to have the old design working at least for the time being. It
> looks as though earlier revisions of arg_init() supported a null
> terminated list, now the function reads all the arguments specified by
> "argc". The language switch build used a null terminated list smaller
> than argc resulting in dereferencing null in arg_init().
> Also remove the business about reading options from a file, certainly
> not worth the distraction of reading it.
> base/gsalloc.c
> gpdl/psi/psitop.c

2015-10-16 14:34:08 +0100
Ken Sharp <ken.sharp@artifex.com>
fe1c025dcbaef436b4a45e0a0bcb4af4d98eefde

> Correct some out of date information regarding ColorConversionStrategy
> The PDF/A and PDF/X sections of the documentation contained some out of
> date settings. The main body of the text remained correct.
> doc/Ps2pdf.htm

2015-10-14 13:54:01 +0100
Chris Liddell <chris.liddell@artifex.com>
e126995d6327788ddac7fd99f55db3c1603beea7

> Bug 696271: Fix a load of makefile dependencies.
> A large number of targets weren't depending on the makefile in which they were
> defined.
> Almost no targets were dependent on the top level makefile.
> A significant number of targets were missing the "MAKEDIRS" dependency (which
> is specific to GNU make as an order-only prerequisite).
> No cluster differences
> base/expat.mak
> base/fapi_bs.mak
> base/freetype.mak
> base/gs.mak
> base/ijs.mak
> base/jbig2.mak
> base/jpeg.mak
> base/jpegxr.mak
> base/lcms2.mak
> base/lcups.mak
> base/lcupsi.mak
> base/ldf_jb2.mak
> base/lib.mak
> base/lwf_jp2.mak
> base/msvclib.mak
> base/msvctail.mak
> base/openjpeg.mak
> base/pcwin.mak
> base/png.mak
> base/tiff.mak
> base/unix-aux.mak
> base/unix-dll.mak
> base/unix-end.mak
> base/unixinst.mak
> base/unixlink.mak
> base/winlib.mak
> base/winplat.mak
> base/zlib.mak
> contrib/contrib.mak
> cups/cups.mak
> devices/contrib.mak
> devices/devs.mak
> pcl/pcl/pcl.mak
> pcl/pcl/pcl_top.mak
> pcl/pl/pl.mak
> pcl/pxl/pxl.mak
> psi/int.mak
> psi/msvc.mak
> psi/os2.mak
> psi/winint.mak
> xps/xps.mak
> xps/xps_gcc.mak
> xps/xps_msvc.mak

2015-10-14 15:23:06 +0100
Ken Sharp <ken.sharp@artifex.com>
74ba28a80804f82aaa68682733c7d7a3cd5f9cbd

> pdfwrite - guard against NULL pointer dereference and correct a loop
> Bug #696275 "-dFastWebView parameter crashes Ghostscript"
> This is a twofold fix. A Coverity static analysis fix added some return
> checking, but this happened inside a faulty loop, the code should not have
> been executed. Because the return value wasn't checked, this didn't cause a
> problem......
> Checking the return value meant that we returned an error to the caller, and
> an oversight there could lead to us dereferencing a pointer which had not
> been allocated.
> This commit fixes both of these problems.
> No differences expected.
> devices/vector/gdevpdf.c

2015-10-14 09:50:40 +0100
Chris Liddell <chris.liddell@artifex.com>
c6fa28f20c464c4badb2579b6bf8dfd0c7cc0230

> Bug 696267: augment DroidSansFallback.ttf
> Specifcally to add the Yen symbol, but adds any glyphs in DroidSans.ttf not
> present in DroidSansFallback.ttf
> One minor cluster change - 959_-_cannot_search_for_japanese.pdf
> Resource/CIDFSubst/DroidSansFallback.ttf

2015-10-13 08:32:26 +0100
Ken Sharp <ken.sharp@artifex.com>
1ebc998c9e6e18468a64210ed5da091e765cef1c

> Squash a compiler warning
> I hadn't realised but the 'setup_fn' is a fixed 256 byte character array
> rather than a char pointer, so there's no point for testing it being
> non-NULL.
> Of course, having the filename be a fixed length array has other implications
> for buffer overruns.....
> devices/gdevrinkj.c

2015-10-12 16:40:10 +0100
Ken Sharp <ken.sharp@artifex.com>
5571ddfa377c5d7d98f55af40e693814ac287ae4

> prevent rinkj device crash when misconfigured (no SetupFile)
> Bug #696246 "Ghostscript 9.18 with -dFirstPage/-dLastPage fails for ijs and some x11 devices"
> The rinkj device requires a SetupFile to be given as a device parameter,
> however it doesn't actually check to see if one is given, and just tries
> to open the filename, with a predictable crash when none is given.
> Here we check the filename and attempt to ensure it is both present and
> minimally valid.
> No differences expected.
> devices/gdevrinkj.c

2015-10-12 16:38:09 +0100
Ken Sharp <ken.sharp@artifex.com>
1bdbe4f87dc57648821e613ebcc591b84e8b35b3

> Ensure plib devices always use the clist
> Bug #696246 "Ghostscript 9.18 with -dFirstPage/-dLastPage fails for ijs and some x11 devices"
> the plib* class of devices only work if clist is present, but previously
> they left the banding_type set to 'auto', which meant that under some
> conditions we did not use the clist, leading to a seg fault.
> This commit simply forces banding_type to be 'BandingAlways'.
> No differences expected.
> devices/gdevplib.c

2015-10-12 16:36:11 +0100
Ken Sharp <ken.sharp@artifex.com>
007bd77d08d800e6b07274d62e3c91be7c4a3f47

> Guard against NULL 'base' for non-clist devices
> Bug #696246 "Ghostscript 9.18 with -dFirstPage/-dLastPage fails for ijs and some x11 devices"
> This is actually for the plib device. This device is currently (this will
> change in the next commit) set to BandingAuto, despite the fact that the
> device only works in banding mode.
> This can lead to use arriving in gdev_mem_open_scan_lines with all of
> mdev->bitmap_memory, mdev->line_pointers_memory and mdev->base being set to
> NULL. The code didn't check and assumed that mdev->base was valid, which
> led to a later seg fault.
> Here we just check to make sure it isn't NULL and return an error if it is.
> This doesn't prevent the possibility of garbage uninitialised values, but
> there's not much we can do to check that at this stage, devices are supposed
> to be initialised to 0 so this 'shouldn't' happen.
> No differences expected.
> base/gdevmem.c

2015-10-09 10:04:17 +0100
Chris Liddell <chris.liddell@artifex.com>
92f91de4a43e164602f2c219f895006347db958c

> Bug 696232: apply metrics for PCL TTF fonts.
> Specifically, metrics for Format 1 Class 2 glyph data.
> Several PCL/PXL files show differences, most are not really visible without
> pixel level comparisons, a very few are (mostly subtle) progressions.
> base/fapi_ft.c
> base/gxfapi.c
> pcl/pl/plchar.c
> pcl/pl/plchar.h
> pcl/pl/plfapi.c

2015-10-09 12:54:44 +0100
Chris Liddell <chris.liddell@artifex.com>
95553954b8d150e847090ec03db3b10a998e82be

> Bug 696246: patch the memory manager fields for sublassed devices.
> When we subclass a device, we were patching the "visible" type field - that is,
> the one referenced directly in the device structure. We were not patching
> the type information in the memory object header so, in particular, the
> garbage collector could end up calling the wrong methods for the subclassed
> device.
> No cluster differences.
> base/gdevdflt.c
> base/lib.mak

2015-10-09 10:54:10 +0100
Chris Liddell <chris.liddell@artifex.com>
b68e05c3b78c19ae06003281adaa2736cb53e605

> Bug 696246: devijs account for device sublassing.
> The IJS device wasn't coping with the possibility it had been subclassed.
> No cluster differences
> devices/gdevijs.c

2015-10-08 15:02:17 +0100
Chris Liddell <chris.liddell@artifex.com>
d39382efae340a29cd5a502b52d135f63f9202ce

> Add configure and makefile stuff for isinf() and isnan()
> Bug #696248 related.
> Makefile.in
> configure.ac

2015-10-08 13:54:50 +0100
Ken Sharp <ken.sharp@artifex.com>
5411d274b19067bec99189dd0a956432d619c80e

> PS interpreter - check for floating point exceptions in mul, div and add
> Bug #696248 "gs9.18 crash on display of nan; also poor handling of inf"
> The mul, div and add operators did not detect invalid results (infinity or
> non-a-number). This is likely because there is no guaranteed portable
> method for detection of these prior to C99.
> Here we add checks for this results using the C99 extensions isnan() and
> isinf(). These are guarded by #ifdef so that they do not cause compilation
> problems on compilers that don't support them. Additionally add support for
> early versions of Microsoft Visual Studio which used somewhat different
> names for these functions.
> This code requires some changes to the configure scripts on Linus in
> order to enable it.
> On systems which do not support isnan() and isinf() there will be no change,
> we will continue to not report errors in ths case.
> No differences expected.
> base/gssprintf.c
> base/math_.h
> psi/zarith.c

2015-10-07 09:26:05 -0600
Henry Stiles <henry.stiles@artifex.com>
33f782ee9e09fd840d0d50598db491e5b8a951f5

> Fix Bug #696242: PCL should be the default implementation when
> building with XPS.
> pcl/pl/plimpl.c

2015-10-07 09:33:00 +0100
Ken Sharp <ken.sharp@artifex.com>
ddda7e89bb0bf35cec575c54b19fa8ba3608d8f7

> PS interpreter - fix a buffer overrun in '=='
> Since changing the implementation of sprintf we now have a situation
> where %g can return > 50 bytes of data for a INF. In obj_cvp we define a
> fixed size buffer on the heap to receive this, but only 50 bytes wide, so
> the buffer overflows and we get a crash.
> Increased the size of the buffer well past the maximum possible return
> size from sprintf.
> No differences expected.
> psi/iutil.c

2015-10-06 17:36:27 +0100
Chris Liddell <chris.liddell@artifex.com>
b3c0f7279a34836276df5126a0d4a7a1abd00977

> Add a missing dependency for the gs romfs file
> psi/psromfs.mak

2015-10-05 13:15:28 +0100
Ken Sharp <ken.sharp@artifex.com>
0db2e3063957b94ee331da09369a9e4116c3d9c1

> pdfwrite - cater for forms with negative bounding boxes
> When setting a clip for forms, we were not accounting for the possibility
> of a form which was wholly negative in either or both dimensions.
> Here we permit that and create a better clip.
> No differences expected.
> psi/zform.c

2015-10-01 13:37:43 +0100
Ken Sharp <ken.sharp@artifex.com>
a7a09c72cd84b539914d97ceafd02673f0dd32f9

> pdfwrite - prevent NULL pointer dereference
> Bug #696234 " Regression: segfault with pdfwrite starting with 17131c7a7fdf9d8537c4715e538c49b29c8945a8"
> When trying to find an object in the resource chains using an ID, we can
> encounter resources which have been cancelled. These have no object (it has
> been freed) so trying to dereference the object can cause a SEG fault.
> I did try to free the resource as well, when cancelling it but that spun
> off into a maze of complications involving the garbage collector. It seems
> that 'something' was maintaining a pointer to those structures, so freeing
> them caused all kinds of relocation/free problems.
> Its a lot easier just to prevent dereferencing the pointer.
> No differences expected.
> devices/vector/gdevpdfu.c

2015-09-30 09:43:44 +0100
Ken Sharp <ken.sharp@artifex.com>
38dd52355037ce88c21bad94bff0df04d71ffc8b

> pdfwrite - improve tiny text matrix clamping in 53ac1eca93ac13fead4c4ab8ced0faeee1ee517c
> Use fabs instead of abs on the matrix elements, and allow individual
> scaling for each element so that clamping to a minimum value can vary for
> each element.
> No diffrences expected.
> devices/vector/gdevpdts.c

2015-09-29 15:32:52 +0100
Chris Liddell <chris.liddell@artifex.com>
e88f94fed2a339288b3ee65cf3dce348c0b3419d

> Contents of CIDSystemInfo can be indirect references
> Cope with that....
> No cluster differences.
> Resource/Init/pdf_font.ps

2015-09-28 22:44:30 +0100
Chris Liddell <chris.liddell@artifex.com>
c874900bf0c184bd61586acfb6f4ebb5a007f730

> Improve initalization of the gdevplib device.
> Tweak so it uses appropriate macro, eliminating warnings, and hopefully making
> long term maintenance easier.
> No cluster differences.
> devices/gdevplib.c

2015-09-28 09:53:55 +0100
Chris Liddell <chris.liddell@artifex.com>
da2038b2040827f9f29faa43266477f73d83c043

> Bug 696229: initialize clist color space validity.
> The clist uses a stack variable to hold the device color. Valgrind reports
> that the ccolor_valid entry in the device color can remain unset, so set
> it to invalid when the initialize the device color to "unset".
> Also, add a PACIFY_VALGRIND memset so pattern bitmap buffers are fully zeroed
> on allocation - stops valgrind getting upset about writing and reading back
> uninitialised (padding) bytes to/from the clist.
> No cluster differences.
> base/gdevmem.c
> base/gxclrast.c

2015-09-29 14:25:07 +0100
Ken Sharp <ken.sharp@artifex.com>
53ac1eca93ac13fead4c4ab8ced0faeee1ee517c

> pdfwrite - ensure we don't write non-zero matrix elements with too tiny a value
> Bug #696228 "Regression: error starting with 70b442162ff8f3d40595d0eb9fb365d341139ee2"
> The change noted causes the PDF interpreter to replace degenerate text matrices
> with a very tiny scaling matrix. However, when writing this back through
> ps2write, we also take the size of the font into account, and bake this
> into the matrix.
> If the font size was less than 1 this could lead to us writing a value too
> small for printf's '%g' format, and it ended up being written as zero, which
> caused the error with the ps2write output.
> This commit checks each of the array elements to see if they are non-zero, but
> have a value so small that they will *become* zero when written out. If this
> happens we recalculate the scale so that the minimum value is emitted. The
> value is so small anyway that this should not cause a perceptible difference.
> We *don't* do this for the Tx and Ty values as we want these to be correct
> and it doesn't cause a problem if these are 0.
> No differences expected.
> devices/vector/gdevpdts.c

## Version 9.18 (2015-09-23)

This is the thirteenth full release in the stable 9.x series, and is a maintenance release.

Highlights in this release include:

- A substantial revision of the build system and GhostPDL directory structure, meaning the GhostPCL and GhostXPS "products" are now built by the Ghostscript build system "proper" rather than having their own builds which called the Ghostscript build system for certain parts of the builds.

  Ghostscript-only users should not be affected by this change.

  For users of the PCL and XPS interpreters (collectively downloaded as "GhostPDL") there is a new, "flatter" directory structure and only one `configure` and one `make` invocation to build all the products. There are also some executable default name changes to bring the PCL and XPS binaries in line with the Ghostscript ones. All executables now end up in the "bin" directory (or build specific variant thereof, e.g. "debugbin"). The PCL executable, by default, is now "gpcl6" on Unix like systems and "gpcl6win??.exe" (where "??" is either "32" or "64"). The XPS executable remains "gxps" on Unix-like systems, but similarly becomes "gxpswin??.exe" on Windows.

  Those using scripts or other automated processes will need to take steps to cope with these changes.

- A new method of internally inserting devices into the device chain has been developed, named "device subclassing". This allows suitably written devices to be more easily and consistently as "filter" devices.

  The first fruit of this is a new implementation of the "-dFirstPage"/"-dLastPage" feature which functions a device filter in the Ghostscript graphics library, meaning it works consistently with all input languages.

- The "ghostpdl.inf" file, provided to simplify installing a Postscript printer configure to produce output to suit Ghostscript's "pdfwrite" device is now available as a digitally signed version: "ghostpdl.cat".

- Plus the usual round of bug fixes, compatibility changes, and incremental improvements.

For a list of open issues, or to report problems, please visit bugs.ghostscript.com.

### Incompatible changes

No recorded incompatible changes.

### Changelog

2015-09-29 15:32:52 +0100
Chris Liddell <chris.liddell@artifex.com>
60ecc24519fa3c5be80617bd88fd0489344fd617

> Contents of CIDSystemInfo can be indirect references
> Cope with that....
> No cluster differences.
> Resource/Init/pdf_font.ps

2015-09-25 14:36:11 +0100
Chris Liddell <chris.liddell@artifex.com>
6c1b1ccce595e6477c972c9bf927462986b343a2

> More ICC reference counting problems
> Fix a few ICC profile reference counting issues with LAB and Calibrated color
> spaces.
> No cluster differences.
> psi/zicc.c

2015-09-24 21:09:53 -0700
Michael Vrhel <michael.vrhel@artifex.com>
f616e3be41a6c3a13ddda3dddf9d57d73edc32be

> Avoid doing color linearity tests when they are not needed.
> In the shading code there are several tests to determine if we
> are sufficiently linear in our fill region. If not, it is further
> divided. For certain color mappings we are always going to be linear
> and do not need to check. We test for these now and avoid the check.
> Cluster push reported 119 diffs. Checked them and they looked
> reasonable. Differences in various gradient fills. The run time
> numbers from the regression test improved significantly.
> Going from a cpu time of 37:29:22 to 29:28:04 with gs going from
> 19:42:34 to 15:25:29
> base/gxshade.c
> base/gxshade.h
> base/gxshade6.c
> base/lib.mak

2015-09-24 11:44:23 +0100
Chris Liddell <chris.liddell@artifex.com>
b675dca5482eadece52ba917e1e492d9f30df618

> gximono.c: fix use of color sample cache
> When pulling multiple samples from the color cache (for example, for RGB and
> CMYK) we should get the pointer to the first sample (from which we can work
> through the samples) rather than the sample value itself.
> Identified by Johannes Meixner.
> No cluster differences.
> base/gximono.c

2015-09-24 14:30:20 +0100
Chris Liddell <chris.liddell@artifex.com>
3a5faa7c23b323b7cdac8377a666c2fc64dc1990

> Bug 696223: cope with empty %rom% returning an error
> The romfs is always included now, but if there are no files (i.e. if we're using
> the "dummy" romfs for COMPILE_INITS=0) it returns an "unregistered" error from
> the "status" method.
> This trips up the code for identifying the ICC profiles path, which stats the
> default ICC profile path, which happens to be %rom%iccprofiles.
> So, put the status call in a stopped context, and act accordingly.
> No cluster differences.
> Resource/Init/gs_lev2.ps

2015-09-24 09:32:22 +0100
Chris Liddell <chris.liddell@artifex.com>
67d03961a838a391f79fcb0fbbded02ca53ad2e9

> Bug 696151: fix logic in gx_downscaler_get_bits_rectangle()
> The logic about whether to use an interim buffer or not did not match between
> gx_downscaler_init_planar() and gx_downscaler_get_bits_rectangle() causing the
> latter to attempt to write into a buffer that had not been allocated, thus
> crashing.
> No cluster differences.
> base/gxdownscale.c

2015-09-24 11:04:22 +0100
Chris Liddell <chris.liddell@artifex.com>
e35c4ca446faf442b558aa3dd2d2957e18d45ea4

> Add words to release notes
> about the revised directory structure, build and executable names
> doc/History9.htm
> doc/News.htm

2015-09-24 08:26:17 +0100
Chris Liddell <chris.liddell@artifex.com>
30021e7ba7cac7310cf0018746aad0ea1f2ee772

> Add missing dependencies....
> gsromfs0.c -> time_.h
> iconfig.c -> gs.tr
> No cluster differences.
> base/lib.mak
> psi/int.mak

2015-09-23 12:04:49 +0100
Chris Liddell <chris.liddell@artifex.com>
474e96f093527b1714df2f06dc66502a6d83db32

> Remove gpdl from the default target list
> No cluster differences
> configure.ac
> psi/msvc.mak

2015-09-22 09:12:33 +0100
Chris Liddell <chris.liddell@artifex.com>
dafc7774e523411a228d236612df03cab1b11c17

> Delete the left-overs from the build reorg.
> No cluster differences.
> old-stuff/COPYING
> old-stuff/Makefile
> old-stuff/autogen.sh
> old-stuff/common/cp.bat
> old-stuff/common/gccdefs.mak
> old-stuff/common/generic.mak
> old-stuff/common/msvc_top.mak
> old-stuff/common/msvcdefs.mak
> old-stuff/common/mv.bat
> old-stuff/common/pcdefs.mak
> old-stuff/common/rm.bat
> old-stuff/common/sgidefs.mak
> old-stuff/common/ugcc_top.mak
> old-stuff/common/unixdefs.mak
> old-stuff/config.mak.in
> old-stuff/configure.ac
> old-stuff/main/pcl6_gcc.mak
> old-stuff/main/pcl6_msvc.mak
> old-stuff/win32/GhostPDL.sln
> old-stuff/win32/ReadMe.txt
> old-stuff/win32/language_switch.vcproj
> old-stuff/win32/pcl.vcproj
> old-stuff/win32/xps.vcproj
> old-stuff/xcode/GhostPDL/GhostPDL.xcodeproj/project.pbxproj
> old-stuff/xcode/GhostPDL/GhostPDL.xcodeproj/project.xcworkspace/contents.xcworkspacedata
> old-stuff/xcode/GhostPDL/GhostPDL.xcodeproj/xcshareddata/xcschemes/GhostPDL.xcscheme
> old-stuff/xcode/GhostPDL/GhostPDL.xcodeproj/xcshareddata/xcschemes/ghostscript.xcscheme
> old-stuff/xcode/GhostPDL/GhostPDL.xcodeproj/xcshareddata/xcschemes/language_switch.xcscheme
> old-stuff/xcode/GhostPDL/GhostPDL.xcodeproj/xcshareddata/xcschemes/pcl.xcscheme
> old-stuff/xcode/GhostPDL/GhostPDL.xcodeproj/xcshareddata/xcschemes/svg.xcscheme
> old-stuff/xcode/GhostPDL/GhostPDL.xcodeproj/xcshareddata/xcschemes/xps.xcscheme
> old-stuff/xcode/Makefile
> old-stuff/xcode/clang_wrapper.c
> old-stuff/xcode/clang_wrapper.sh
> old-stuff/xcode/resolve.sh

2015-09-22 09:10:02 +0100
Chris Liddell <chris.liddell@artifex.com>
0b78c7a692745084e7b9f328f4165af84eca57fe

> Revise Make.htm.
> Fix out of date links, remove long untested systems, and general cleanup.
> No cluster differences.
> doc/Make.htm

2015-09-22 08:20:07 +0100
Chris Liddell <chris.liddell@artifex.com>
e9e62834caf6b75248ea6e9ba558821834339075

> Tweak the WinRT build for new build scheme.
> No cluster differences.
> old-stuff/winrt/GhostPDL.sln
> windows/Ghostscript-winrt.sln
> windows/ghostscript_rt.vcxproj

2015-09-17 21:21:46 -0500
Chris Liddell <chris.liddell@artifex.com>
01639146163f7e196658ba7feb98d5c1a2cb8c34

> Bug 694180 (related): jbig2dec base streams error handling
> Two problems:
> First: when creating the jbig2dec context, you optionally pass it a function
> pointer and data pointer to use to record error conditions. The data pointer
> being used was the pointer to the Ghostscript stream state - which was allocated
> in normal Postscript memory - i.e. subject to relocation by the garbage
> collector. As this was stored as part of jbig2dec's internals, there was no
> way for the garbage collector to move the pointer, and thus the location
> was potentially nonsense.
> Secondly, in testing the fix for above, it turns out that, in the event of an
> error during JBIG2 decoding, there was no cleanup done - only the memory for
> the stream state would be discarded (by the garbage collector), the jbig2dec
> context was left to leak.
> To fix the first problem, add a non-gc memory structure with the pointers
> required for the jbig2dec error callback.
> For the second problem, add a finalize method to the jbig2dec stream state
> so the non-gc stuff can be cleaned up in the event of an error.
> No cluster differences.
> base/sjbig2.c
> base/sjbig2.h

2015-09-18 09:49:55 -0500
Chris Liddell <chris.liddell@artifex.com>
94c98185fdc65a9e048303b3bbc40949f61b0fc3

> jbig2dec: release huffman table memory properly
> Freeing huffman table memory didn't use the jbig2dec allocator call, just called
> "free" directly. Caused a crash if the caller uses a custom allocator.
> No cluster differences.
> jbig2dec/jbig2_huffman.c

2015-09-23 08:14:49 +0100
Ken Sharp <ken.sharp@artifex.com>
375fc31051400eda284cd450ea108317489ea8a0

> remove an unused variable to silence a compiler warning
> devices/vector/gdevpdtt.c

2015-09-22 14:15:06 -0700
Ray Johnston <ray.johnston@artifex.com>
adcbb5795f02903c71504faa9dd26fdfee69c9f3

> Fix bug 696201. Regression caused by fast HT fixes commit 695065f2
> The entire threshold array was not being initialized to the max value
> when num_repeats > 1. Apparently this is rare.
> base/gsht.c

2015-09-22 14:05:46 -0700
Ray Johnston <ray.johnston@artifex.com>
a711e36640bde6b4d76e51de5e2d57124bb49ff7

> Get rid of "magic number" returns from compositor is_closing proc
> Instead use enums that are somewhat mnemonic. We hate magic numbers.
> base/gdevdflt.c
> base/gdevp14.c
> base/gscompt.h
> base/gsovrc.c
> base/gxclrast.c

2015-09-18 13:39:58 -0700
Ray Johnston <ray.johnston@artifex.com>
0d04e52b3b4bb2a0dd03d70d31630b3e79c0fb31

> Convert constants used by 'is_closing' compositor proc to menmonic enums
> These had used constants that were a source of wasted time when working on
> compositors since one had to hunt around for the 'meaning' of constant
> numeric values. Change to using a gs_compositor_closing_state enum with
> somewhat meaningful names.
> base/gdevdflt.c
> base/gdevp14.c
> base/gscompt.h
> base/gsovrc.c
> base/gxclrast.c
> base/gxcomp.h

2015-09-22 20:36:02 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
c48fb6fb210b852d4156ea303c3ba0e9060c7a75

> Bug 696052: Check that cloned image exists before proceeding further.
> jbig2dec/jbig2_refinement.c

2015-09-18 23:15:40 +0100
Ken Sharp <ken.sharp@artifex.com>
54510dd67d4f1344fda4e913be9c70341e453fe8

> pdfwrite - yet more symbolic font meddling
> Bug #696207 "Creation of PDF/A-1b from PDF results in missing characters"
> The previous fix for symbolic fonts could lead to a situation where we emitted
> an embedded, subset, symbolic TrueType font, bu put a /Encoding in the font.
> This is invalid for PDF/A-1 and also causes Acrobat to do strange things with
> the CMAP subtable(s) in the font. This commit should ensure (by synchronising
> the tests) that we don't emit symbolic TT fonts with an Encoding.
> Checking with the test file for bug 695969 indicates that the code still
> works for that case too.
> This has unfortunatley required some re-organisation of data structure
> declarations.
> I think we won't be able to reliably have this work until the TrueType font
> embedding code is rewritten.
> In any event the heuristics seem improved again.
> devices/vector/gdevpdtd.c
> devices/vector/gdevpdtd.h
> devices/vector/gdevpdtt.c

2015-09-18 20:22:25 +0100
Ken Sharp <ken.sharp@artifex.com>
128b24a5c42f0cb73f4b3c39fabb2fb46707af8a

> txtwrite - cater for empty strings
> Bug #696212 "txtwrite: pdfs generated by JasperReports cause segfault in gs"
> The PDF file contains an operation of the form () Tj The empty string
> means that we don't process the text (because there is none) resulting in
> uninitialised data later.
> Fixed by ignoring emtpy strings.
> devices/vector/gdevtxtw.c

2015-09-15 10:24:53 +0100
Chris Liddell <chris.liddell@artifex.com>
478dda05a6a4b3b1f8ce2a934fb0f60870d2fc98

> Fix pdf14 compositor/ICC reference counting problems.
> One reference counting issue whereby the code originally assumed it would be
> moving an existing ICC profile reference, rather than creating a new reference
> (thus no reference counting was done) and it transpired that in certain cases
> a new profile could end up being created - thus reference counting was required
> to ensure that, in the case where a newly created profile was used, it would
> also be freed as required. In this case, one of the places where the reference
> was removed did not decrement the reference count.
> Secondly, in the event of the compositor being interrupted (by an error or user
> intervention) between push group and pop group operations, when we come to
> finalize the compositor device, we have to emulate the ICC profile restorations
> that happen during a pop group, so all the references and reference counts end
> up back where they were when the push group happened.
> No cluster differences.
> base/gdevp14.c

2015-09-15 10:15:28 +0100
Chris Liddell <chris.liddell@artifex.com>
f894956b58e3e5c9a2238c0cd66a98d803c7c117

> Fix memory leak with pattern clists.
> The clist reader's ICC cache gets recreated every time we execute a clist,
> but previously the code did not take action to clean it up, this the
> reference count was wrong, and we leaked memory.
> Whilst it may be preferable to have it persist, in the short term, it seems
> safer to cleanup after clist playback, as that is functionally the same as the
> existing behaviour.
> No cluster differences
> base/gxp1fill.c

2015-09-15 10:11:24 +0100
Chris Liddell <chris.liddell@artifex.com>
2432584e6bb6a257c47261430d1cd8ef3e71c9c4

> Cleanup after error in clist
> If an error (or interrupt) occurs during clist replay, ensure we tidy up
> the memory buffer device that the clist renders into before propagating
> the error.
> No cluster differences
> base/gxclread.c

2015-09-15 10:07:05 +0100
Chris Liddell <chris.liddell@artifex.com>
b7fffb5a7429cfd1f0716c98f1b71f57eda653dc

> Change memcpy to memmove
> valgrind reported overlapping memory regions in a memcpy, so change it to
> memmove which copes with such cases.
> No cluster differences.
> base/gxclfile.c

2015-09-15 11:02:46 +0100
Chris Liddell <chris.liddell@artifex.com>
989f7afffdbf49d6b385f3e817a0dc7a736f13bc

> Prevent crash with reference count debugging (-Z^)
> The garbage collector makes no promises about the order in which objects are
> swept. As a result, it is possible for a forwarding device to remain unswept
> after its target has already.
> To handle such relationships, the garbage collector leaves memory contents alone
> until the entire sweep is complete, so the forwarding device's decrement of the
> target reference count is safe. However, with rc debugging active, the debugging
> code attempts to ascertain the object type by interrogating the memory header,
> which the garbage has, by now, userped for it's own uses - causing a crash.
> By setting the rc.memory pointer to NULL when the target device is finalized,
> the rc debugging code is kept happy.
> In the non-gc case, the finalize is the very last thing to happen before the
> memory is actually freed, thus the memory pointer is moot by that stage.
> No cluster differences.
> base/gsdevice.c

2015-09-16 20:30:57 +0100
Ken Sharp <ken.sharp@artifex.com>
717a3d6e5e139d6cbb2474dbb44bf0ca2069d5b4

> eps2write - convert path bounding box to user space from device space
> Bug #696181 "BoundingBox wrong when using eps2write in AIX environment"
> I can't test this on an AIX setup, but for me the test file was incorrect
> on Windows anyway.
> In order to find the marking extent of a (filled) path we intersect the
> path with the current clipping path and check the extents of the resulting
> rectangle against the extents of the current BBox.
> However, the result of the intersection is in device space, and we did not
> 'undo' the resolution. Other places in the code *do* remove the scaling
> due to resolution, so we simply adopt that here.
> No differences expected.
> devices/vector/gdevpdfd.c

2015-09-15 12:55:15 +0100
Ken Sharp <ken.sharp@artifex.com>
22dcf8215791732199f6b76a7d7e330b0b792931

> Coverity ID #95039 - initialise a stack
> I don't think its possible for this to be a problem, but its pretty cheap to
> do.
> devices/vector/gdevpsf1.c

2015-09-15 09:43:43 +0100
Ken Sharp <ken.sharp@artifex.com>
5772922322e908279196a77bddc6bd1d973f5f82

> Coverity ID #94682 check and action a return value.
> devices/vector/gdevpdfm.c

2015-09-14 13:38:03 +0100
Ken Sharp <ken.sharp@artifex.com>
c4d4f68db961ea0bebde67764fa3c7383277b6c2

> pdfwrite force XMP metadata emission when creating PDF/A
> Discovered while working on PCL -> PDF/A, we need to have XMP metadata
> emitted for PDF/A compatibility.
> devices/vector/gdevpdfe.c

2015-09-10 13:56:43 +0100
Ken Sharp <ken.sharp@artifex.com>
f077c60d6441d5dae58bcaeeab2977491f5dff66

> Coverity ID #107437 check and action a return value
> devices/vector/gdevpdfi.c

2015-09-09 14:35:52 +0100
Chris Liddell <chris.liddell@artifex.com>
0dd8e231284a6c898cd21bb9d6f3e096282b3907

> Add a special finalize method for the pdf14 compositor
> In the event of an error, the pdf14 compositor device can be part way through
> accumulating its data. Add a finalize method to discard stuff that might remain
> before the device itself is freed.
> No cluster differences.
> base/gdevp14.c

2015-09-08 09:30:16 +0100
Chris Liddell <chris.liddell@artifex.com>
28989d155efe5db7f2ea5f4477a7e654f5402470

> Bug 696178: avoid var overflow with large CFF font
> If a CFF/Type 2 font has a large number of (g)subrs, the remaining buffer size
> when we come to recreate the font for Freetype could be larger than 64435
> bytes, and this could overflow the usigned short parameter we pass to the
> helper function which extracts and stores each (g)subr.
> As I doubt we'll see a font with a single (g)subr of more than 65535 bytes, I'm
> just clamping the value to the usigned short range.
> No cluster differences.
> base/write_t2.c

2015-09-07 20:32:35 -0700
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
08c278231e4fa357cb4a8b001b751b132819c739

> Change cluster host from casper.ghostscript.com to cluster.ghostscript.com.
> toolbin/localcluster/clusterpush.pl

2015-09-04 10:28:54 -0700
Ray Johnston <ray.johnston@artifex.com>
bd02324382fc0f97674ad29235600e498566fb16

> Prevent leak if device subclassing fails.
> Move a check earlier, before any allocations.
> Also fix a divide by zero problem seen while testing with the spotcmyk
> device and -dFirstPage=2 on tests_private/comparefiles/86554321.pdf
> base/gdevdflt.c
> base/gxdevndi.c

2015-09-03 08:53:31 +0100
Chris Liddell <chris.liddell@artifex.com>
0ed9597158122a9200b6e973fbb0810bbf97e1eb

> Remove the moribund pdf_cslayer.ps etc.
> THe BMC/BDC/EMC marked content operators are now handled fully in the PDF
> interpreter "proper" and this original handling has not been touched or used
> (or even built-in) since it's original authoring 7 years ago.
> No cluster differences.
> Resource/Init/pdf_cslayer.ps
> psi/int.mak
> psi/psromfs.mak

2015-09-01 09:54:00 +0100
Ken Sharp <ken.sharp@artifex.com>
66fc00c563bfbbb3736159f646b58666fe444c55

> Don't require Type 42 fonts to have copyrigth information
> Bug #696174 "Error: /invalidfont in --show--"
> The problem occurs because the embedded type 42 fonts don't include a
> Copyright entry in the names table. When copying fonts, we try to copy the
> copyright information, and it fails which results in an invalid font error.
> Clearly we want to copy the information if its present, but its absence
> shouldn't be regarded as an error, so this commit simply ignores the return
> value when we try to copy the copyright information.
> base/gstype42.c

2015-08-31 22:24:25 -0700
Michael Vrhel <michael.vrhel@artifex.com>
57ed8b1f0accfa6364bf0fc0699d0bab22b79ac2

> Fix mistake in spot color value collection in gprf device
> devices/gdevgprf.c

2015-08-31 12:44:52 +0100
Ken Sharp <ken.sharp@artifex.com>
3bd0059f57389a935c8ec35a92fdb8d5263d4e1c

> pdfwrite - a missed SMask case
> Commit 937bfdbc0c6204ae0be40b1ed1c4bb880568d6be which was to fix a Coverity
> detected problem uncovered a missing case in the new SMask handling. We need
> to check for the soft mask ID having changed when we start accumulating a
> pattern.
> Good catch there from Coverity.
> devices/vector/gdevpdfi.c

2015-08-31 08:39:45 +0100
Ken Sharp <ken.sharp@artifex.com>
1ca58566f41417aac93a5cba0b757ddfdb8bd2a7

> Coverity ID #107342 another return value check
> devices/vector/gdevpdfg.c

2015-08-31 08:36:41 +0100
Ken Sharp <ken.sharp@artifex.com>
937bfdbc0c6204ae0be40b1ed1c4bb880568d6be

> Coverity ID #107346 check and action a return value
> devices/vector/gdevpdfg.c

2015-08-27 11:10:31 -0700
Ray Johnston <ray.johnston@artifex.com>
55203d93e86974ee974c441d567c27b06507e98e

> Remove the compressed_color_encoding that has not been used for a while.
> base/gdevdbit.c
> base/gdevdevn.c
> base/gdevdevn.h
> base/gdevp14.c
> base/gxblend.h
> base/gxblend1.c
> devices/gdevtsep.c

2015-08-28 12:22:38 +0100
Robin Watts <robin.watts@artifex.com>
0877e6183221beb559e02e8aed87efa9cb65064a

> Rename gproof device to gprf.
> The device produces .gprf files, not .gproof ones, and gs
> never actually touches a .gproof file, so the name is
> definitely wrong as is.
> devices/gdevgprf.c

2015-08-28 12:00:03 +0100
Chris Liddell <chris.liddell@artifex.com>
3d3982f844fed6d6cb092055980900289fb6a402

> Add "safe" defaults for the FT and LCMS2 source dirs
> So we don't risk (too much) finding spurious headers for wrong versions
> when linking to shared libraries for Freetype and LittleCMS2, use the same
> safe default ("src") as the other shared libs.
> No cluster differences
> configure.ac

2015-08-28 11:13:36 +0100
Chris Liddell <chris.liddell@artifex.com>
cdc41ce6ddbb7b0233645c750ccfbf6eb927a5c6

> Add gprf device to Unix builds.
> No cluster diffs.
> configure.ac

2015-08-28 11:06:15 +0100
Chris Liddell <chris.liddell@artifex.com>
5ba6e5c4488b6dca2530e772086dd7d45d99709d

> Check for _cmsCreateMutex in lcms2
> When checking for a usable system lcms2 library, check that it contains the
> _cmsCreateMutex() - that ensures we get a sufficiently up to date version
> No cluster diffs
> configure.ac

2015-08-26 12:11:34 +0100
Chris Liddell <chris.liddell@artifex.com>
c6c744cf1634bf7e8a90f4a404ee019ba73451d1

> Update the example "fixed" makefiles
> This provides an example/start point for unix-like systems that don't,
> for whatever reason, want to use the autoconf build.
> No cluster differences
> base/unix-gcc.mak

2015-08-26 12:07:36 +0100
Chris Liddell <chris.liddell@artifex.com>
95acc209c0522c16c985b5916c1043471635e8e3

> If no libtiff, leave out xpswrite
> xpswrite depends on libtiff, so it libtiff isn't available we need to leave out
> the xpswrite devices
> No cluster differences
> configure.ac

2015-08-27 09:45:49 -0600
Henry Stiles <henry.stiles@artifex.com>
3b20ec9955f6b7e48c90d9a021d1511e03b67977

> Fixes PCL crash when a new ICC directory is specified on the command
> line.
> The library context must use the same allocator to create and free the
> icc directory string. The memory parameter passed in is not necessarily
> the same as the original. For example the PCL client wraps the
> allocator to use the chunk allocator after the icc directory string is
> created (part of gs_malloc_init). This can result in memory being
> managed by 2 different memory handlers. Fortunately the original memory
> pointer was tucked in the library context structure and that can be used
> instead of the parameter passed in.
> There are other areas in the library context code that need to be
> checked for this same problem, and a discussion about how this might be
> handled better is in the works.
> base/gslibctx.c

2015-08-27 08:18:06 -0600
Henry Stiles <henry.stiles@artifex.com>
57b90f1c71fc4ae03051917fe912c3917702ba91

> Fix PCL crash if no device argument is specified.
> The previous change (0eac574ee24) to have PCL use the graphics library
> default device list did not account for a missing device on the command
> line. The change intended to remove the check for an index < 0 at the
> beginning of the pl_top_create_device() procedure.
> pcl/pl/plmain.c

2015-08-27 13:28:35 +0100
Ken Sharp <ken.sharp@artifex.com>
7f17c1ddae39841ef1b2bbef84cc3c95cf2e1685

> pdfwrite - improved SMask handling
> This follows on from commit 1a319a9, in that commit we included the soft mask
> ID in the graphics state we were tracking (in fact it was present in the
> structure, but untracked). This did resolve the problem adequately, but left
> us emitting graphics states with /SMask /None entries in order to remove
> some kinds of SMask.
> A neater solution, implemented here, is to use gsave and grestore instead.
> Thia is committed separately as it marks a significant change in the way
> pdfwrite works. Previously only clips were handled by using gsave and grestore
> and I'm slightly concerned that this may not work completely seamlessly
> with this change.
> This exhibits some slight halftoning differences with Altona_Technical_v20_x4.pdf
> and Bug692368.pdf, and some invisible to the naked eye differences in
> Bug690534.pdf, Bug694290.pdf 1439_color_softmask_filas_to_draw_jpx_image.pdf
> Progressions are seen in 586_-_missing_images_gs_SMask_not_applied.pdf
> multiply_luminosity_masks_ignored.pdf and x_-_renders_slowly.pdf
> devices/vector/gdevpdfd.c
> devices/vector/gdevpdfg.c
> devices/vector/gdevpdfi.c
> devices/vector/gdevpdft.c
> devices/vector/gdevpdfx.h
> devices/vector/gdevpdtt.c

2015-08-27 11:44:48 +0100
Ken Sharp <ken.sharp@artifex.com>
1a319a93c147eb14a0791d837bb7f1c5dfd81a3c

> pdfwrite - track soft mask IDs in our saved graphcs states
> Bug #695250 "Missing text from pdfwrite"
> The problem was that we were not tracking soft mask IDs in our saved copies
> of the graphics state, which meant that we were not properly adding (or
> removing) when creating ExtGStates in pdf_update_alpha().
> This addresses the specific issue in the bug, as well as showing progressions
> in the test file x_-_renders_slowly.pdf (missing Qt logo now appears)
> However, a more ambitious treatment, which better tracks gsave/grestore by
> actually emitting q/Q operations seems to show still further improvement.
> I'm going to add this as a separate commit as, despite the progressions,
> I'm a little unsure about it.
> devices/vector/gdevpdfg.c

2015-08-25 22:45:23 -0700
Michael Vrhel <michael.vrhel@artifex.com>
11c1290bab401e84785c731bd8a931bb3bc66c44

> Fix mixup in what is the plane raster vs the row raster in gproof device_procs
> The icc code had several issues as we converted the chunks of 256 planer lines
> of data. The various paths tested out correctly with gsview on windows after
> these fixes.
> devices/gdevgprf.c

2015-08-26 07:54:05 +0100
Chris Liddell <chris.liddell@artifex.com>
69b0e7d39eae1b2a20738258dec0efcd1b38a271

> Include romfs in the static lib build
> No cluster differences.
> base/unixlink.mak

2015-08-25 09:28:49 +0100
Chris Liddell <chris.liddell@artifex.com>
7459309630cf63fd791bfd1a79e2f3ac47d92b70

> Fix the gs static library target
> The recent build reorganisation broke the gs.a target, meaning an incomplete
> set of object files were included in the library file.
> No cluster differences
> base/gs.mak

2015-08-24 17:38:15 +0100
Chris Liddell <chris.liddell@artifex.com>
8fcea1fef23c45a81ad5d13a5e3afd5662e0efef

> Bug 696126 (2): PCL/XPS should (sort of) ignore COMPILE_INITS (for now)
> As the PCL and XPS exes *must* have the icc profiles available in a romfs, they
> will paretially ignore the COMPILE_INITS setting, and always use a rom file
> system for the ICC profiles. COMPILE_INITS=0 will cause PCL to not include
> it's fonts in the romfs.
> This means always including the romfs I/O code in the graphics library, then
> building an empty romfs into Ghostscript for COMPILE_INITS=0, and the romfs i/o
> will now return gs_error_unregistered from its file_status method if
> the empty romfs is found (identified by gs_romfs_buildtime being zero).
> No cluster differences.
> base/gs.mak
> base/gsiorom.c
> base/gsromfs0.c
> base/lib.mak
> psi/imain.c
> psi/imainarg.c

2015-08-24 15:33:39 +0100
Chris Liddell <chris.liddell@artifex.com>
a32ece5ee924a6a4a581f7e6dd298f9d9af6d475

> Bug 696126: tweak error checking for graphics state creation
> We need to check and handle a failure to create a graphics state before trying
> to initialise the ICC profile handling to prevent a crash
> No cluster differences
> pcl/pcl/pctop.c

2015-08-05 09:19:28 +0100
Chris Liddell <chris.liddell@artifex.com>
67aad48044024b9c198c72304971055a288322d9

> Latest fonts with updated cyrillic and greek glyphs
> Resource/Font/BookmanURW-DemBol
> Resource/Font/BookmanURW-DemBolIta
> Resource/Font/BookmanURW-Lig
> Resource/Font/BookmanURW-LigIta
> Resource/Font/CenturySchL-Bold
> Resource/Font/CenturySchL-BoldItal
> Resource/Font/CenturySchL-Ital
> Resource/Font/CenturySchL-Roma
> Resource/Font/CenturySchURW-Bol
> Resource/Font/CenturySchURW-BolIta
> Resource/Font/CenturySchURW-Ita
> Resource/Font/CenturySchURW-Rom
> Resource/Font/ChanceryURW-MedIta
> Resource/Font/NimbusMono-Bold
> Resource/Font/NimbusMono-BoldOblique
> Resource/Font/NimbusMono-Oblique
> Resource/Font/NimbusMono-Regular
> Resource/Font/NimbusRomNo9L-Med
> Resource/Font/NimbusRomNo9L-MedIta
> Resource/Font/NimbusRomNo9L-Reg
> Resource/Font/NimbusRomNo9L-RegIta
> Resource/Font/NimbusSanL-Bol
> Resource/Font/NimbusSanL-BolIta
> Resource/Font/NimbusSanL-BoldCond
> Resource/Font/NimbusSanL-BoldCondItal
> Resource/Font/NimbusSanL-Reg
> Resource/Font/NimbusSanL-RegIta
> Resource/Font/NimbusSanL-ReguCond
> Resource/Font/NimbusSanL-ReguCondItal
> Resource/Font/NimbusSanNar-Bol
> Resource/Font/NimbusSanNar-BolIta
> Resource/Font/NimbusSanNar-Ita
> Resource/Font/NimbusSanNar-Reg
> Resource/Font/PalladioURW-Bol
> Resource/Font/PalladioURW-BolIta
> Resource/Font/PalladioURW-Ita
> Resource/Font/PalladioURW-Rom
> Resource/Font/URWBookmanL-DemiBold
> Resource/Font/URWBookmanL-DemiBoldItal
> Resource/Font/URWBookmanL-Ligh
> Resource/Font/URWBookmanL-LighItal
> Resource/Font/URWChanceryL-MediItal
> Resource/Font/URWGothic-Boo
> Resource/Font/URWGothic-BooObl
> Resource/Font/URWGothic-Dem
> Resource/Font/URWGothic-DemObl
> Resource/Font/URWGothicL-Book
> Resource/Font/URWGothicL-BookObli
> Resource/Font/URWGothicL-Demi
> Resource/Font/URWGothicL-DemiObli
> Resource/Font/URWPalladioL-Bold
> Resource/Font/URWPalladioL-BoldItal
> Resource/Font/URWPalladioL-Ital
> Resource/Font/URWPalladioL-Roma
> Resource/Init/Fontmap.GS
> psi/psromfs.mak

2015-08-21 09:12:16 +0100
Chris Liddell <chris.liddell@artifex.com>
4084d87a0ff7c66ecf0b9ece65f9cd9da496c15b

> Bug 696161: ensure we have a show enumerator object
> before using it as such - it is possible (via an invalid configuration) to get
> a text enumerator, and treating that as a show enumerator can cause a crash.
> Similarly, ensure we have a graphics state (and not just an imager state).
> Found and fix suggested by Ken.
> No cluster differences.
> base/gxchar.c

2015-08-21 18:01:46 +0100
Robin Watts <robin.watts@artifex.com>
849891b1577e3caab4c73f0bfa5c27a7308e1ffc

> GProof: Component names from devn_params are not null terminated.
> Use the given length, not strlen.
> devices/gdevgprf.c

2015-08-20 11:00:39 +0100
Ken Sharp <ken.sharp@artifex.com>
a45d3714ad03c67cee37d6ec29a8eda0fc2e937f

> vector devices - prevent the use of Graphics and TextAlphaBits
> The GraphicsAlphaBits and TextAlphaBits parameters don't make sense and don't
> work with the vector devices, with the exception of rendering transparency.
> In addition they can potentially cause seg faults and other errors.
> Although we've always had code to detect the use of this at rendering
> time, this hasn't stopped people from pointlessly using them.
> To prevent such foolishness (at the expense of transparency flattening, which
> is a very minor usage) this commit prints a warning and throws an error on
> attempts to use these switches with vector devices.
> Additionally update the documentation to make it clear that this is not
> permitted.
> base/gdevvec.c
> devices/vector/gdevpsdu.c
> doc/Devices.htm
> doc/Language.htm
> doc/Use.htm

2015-07-21 18:12:46 +0100
Robin Watts <robin.watts@artifex.com>
55af534b9d621d7ae8a2d6818369dc468514841b

> Add gprf device to Windows builds.
> psi/msvc.mak

2015-08-19 15:34:54 +0100
Ken Sharp <ken.sharp@artifex.com>
af72527ff3b08ff91230a0884ce601b949735cf6

> pdfwrite - consider both X and Y axes when deciding on downsampling
> Bug #696152 "gs no more rendering figure inside the frame"
> The decision on downsampling is taken by comparing the image resolution
> against the downsampling threshold. Previously we only considered the
> resolution in the X direction, assuming (not entirely unreasonably) that
> the image would be of similar resolution in each direction.
> However in this case the image is massively scaled (and therefore has a
> practical very high resolution) in the X direction, but is barely scaled
> at all in the Y direction.
> Downsampling this image caused the height of the image to be reduced to 1
> whcih effectively caused it to disappear.
> No differences expected.
> devices/vector/gdevpsdi.c

2015-08-19 14:20:27 +0100
Ken Sharp <ken.sharp@artifex.com>
ac4b3ca63dbb4f51aaae6d6e927672ebde207326

> pdfwrite - fix an 'unescape' for \b
> Bug #696147 "\b is converted into 007 in devices/vector/gdevpdfm.c"
> Picked up, and fix provided, by popjussi (at gmail.com)
> The code is pretty clearly an 'off by 1' error when converting the
> escaped character code into an octal number.
> No differences expected
> devices/vector/gdevpdfm.c

2015-08-18 14:27:49 +0100
Chris Liddell <chris.liddell@artifex.com>
0eac574ee24b9567743906721039fa0279ab3175

> Use default device list for PCL/XPS
> Previously, the PCL and XPS executables would simply default to the first
> device in the graphics library's device list, and ignore the actual compile
> time set default device list.
> It now uses the graphics library's default device list, bringing it inline
> with Ghostscript.
> No cluster differences.
> pcl/pl/plmain.c

2015-08-18 16:07:53 +0100
Chris Liddell <chris.liddell@artifex.com>
021277d531aa5ba13cfcbfde5bc1a6012db54fd7

> Bug 696150: make allocator available to init jpeg state in gdevpx.c
> When I changed the JPEG state API, it seems I missed one of the instances
> of its use - now fixed.
> Identified by Dmitry Pankratov.
> No cluster differences.
> devices/vector/gdevpx.c

2015-08-18 15:44:16 +0100
Chris Liddell <chris.liddell@artifex.com>
d552e3ba3ed5a3e43062ee5bb1778787bff829ff

> Add a target to build only the unix shared lib
> The "so-only" target will build the .so shared library, and the associated
> sym links, but not the "loader" executables.
> This is useful for building/cross compiling the .so when you haven't got
> the dependencies available for the executables (x11, gtk etc).
> No cluster differences
> base/unix-dll.mak

2015-08-18 13:47:04 +0100
Chris Liddell <chris.liddell@artifex.com>
9238bb855cae9ac53b6cf2b95e3b070f3de69a38

> Recursive make calls use -f "makefile name" option
> The recursive make calls previously relied
> on the makefile being the default name "Makefile" - by passing the name of
> the makefile to the sub-call, we can use custom makefile names.
> Currently only works for GNU make (detected in configure).
> For this to work, if you rename the makefile, you must also edit the name in
> the "MAKEFILE" variable to match your custom makefile name.
> No cluster differences.
> Makefile.in
> base/unix-dll.mak
> base/unix-end.mak
> configure.ac

2015-08-18 14:33:59 +0100
Chris Liddell <chris.liddell@artifex.com>
0e30e7c64f4001adfa5fe376e4cd9ab184903b55

> Bug 696149: tweak under/overflow prevention in FAPI/UFST
> Due to limits of the fixed point arithmetic in the UFST, we have to balance
> various scale factors at extreme scales (scale matrix, font size, "resolution")
> to ensure varaibles don't over/under flow.
> It looks like there was a typo, or just a mistake in how two of the factors
> were being scaled relative each other which could cause *extremely* small
> scale factors to end up as *extremely* large scale factors.
> No cluster differences.
> base/fapiufst.c

2015-08-17 11:38:42 +0100
Chris Liddell <chris.liddell@artifex.com>
e607d6afe7afde57f5f2218f5a7ec267a95a45e4

> Split fonts files out from romfs args
> Have each interpreter specify it's font files separately from any other
> resources for inclusion in the romfs. That means when integrating the UFST
> into the build, we can automatically leave out the font files, whilst including
> the FCO files.
> No cluster differences.
> base/lib.mak
> pcl/pl/plromfs.mak
> psi/psromfs.mak
> xps/xpsromfs.mak

2015-08-18 19:51:16 +0100
Robin Watts <robin.watts@artifex.com>
fc9afb317f3f3e1af5c74fcf381af50a28328acd

> GProof: Trade performance for compression.
> Use Z_BEST_SPEED rather than Z_BEST_COMPRESSION when saving the
> raster data.
> devices/gdevgprf.c

2015-08-18 12:42:43 +0100
Robin Watts <robin.watts@artifex.com>
98b136b5343998849d983e9c508e6f6047cdec64

> GProof device: Fix no-icc rgb generation.
> Derefence pointers to get colour values, rather than using the
> pointers themselves as colour values.
> devices/gdevgprf.c

2015-08-17 08:20:39 +0100
Ken Sharp <ken.sharp@artifex.com>
828b99f459b17f8537eae96694d745409a577469

> PDF interpreter - Attempt to validate the ICCBased /N value for color spaces
> Bug #696120 "Invalid PDF to TIFF conversion"
> The supplied specimen file is incorrect, it has an ICCBased colour space
> which contains the /N key (number of channels) set to a value of 3, but
> the actual profile is a gray profile, and therefore /N should be 1.
> Here we add a new function .numicc_components which attempts to find the
> number of components from an ICC profile (returns 0 if it can't determine
> the value). We then use that returned value to compare to the actual
> /N value given. If the two don't match, and the calculated value is non-zero
> then we use the calculated value instead, and alter the value of /N.
> One file in the cluster test suite is shown as different, but it is visually
> the same.
> In passing, remove some unused variables and commented out code from zicc.c
> to silence some compiler warnings.
> Resource/Init/pdf_draw.ps
> psi/zicc.c

2015-08-14 12:18:14 -0600
Henry Stiles <henry.stiles@artifex.com>
6ebd1b211bda59c5d2a70c423f3539a8e11d1bce

> Bug 696092 - fix memory leak in the X driver.
> Thanks to Hin-Tak Leung for providing a patch to cleanup when the X
> device closes.
> devices/gdevxini.c

2015-08-14 17:48:11 +0100
Robin Watts <robin.watts@artifex.com>
c50adbe72f3e8a07c96127a4df9d78b422acf22a

> MSVC Solution: Adjust output location.
> Output location had not been adjusted to allow for the projects
> being moved to a subdirectory.
> windows/All.vcproj
> windows/ghostscript-ufst.vcproj
> windows/ghostscript.vcproj

2015-05-25 12:35:14 -0700
Ray Johnston <ray.johnston@artifex.com>
695065f2183049bafb8c468f1bc54996da7698dd

> Fix bug 695929. gx_ht_construct_threshold t_level calculation was wrong.
> Rewrite the threshold construction method. For num_levels < 256 the
> previous "t_level_adjust", etc. were never invoked, but the logic for
> the adjustment was incorrect (only worked for num_levels == 256).
> This algorithm uses the same method for determining 'shade' as the
> logic in gx_render_device_DeviceN which is used prior to setting up
> the HT tile in the non-fast threshold code.
> The 'off' is eliminated since that caused threshold values that do not
> match the HT tiling code, and the init_value and threshold values now
> match those generated by the HT tiling code for num_levels < 256.
> Tested with 300 dpi and DITHERPPI values of 18, 24, 30, 33, 39, 52,
> and 60 (the default).
> Also the size of images with the fast code was wrong (dest_width)
> and the phase of the pixels did not match the image code (dda_init).
> This also re-enables the fast code disabled with an earlier commit.
> This was tested with tests/pdf/GridDownscaleTest0.pdf, modified to
> test all rotations, and at 72, 300 and 1200 dpi.
> The transfer function is now pickled into the threshold array levels.
> Although this causes some minor shade differences since the normal
> cmap function calculates the shade from a frac (0-32760) and the
> threshold has to select the shade from a byte value (0-255). The
> 09-47N.PS test shows this.
> Also the texture screen_phase is used to adjust the thresholds when
> filling the threshold buffer.
> This collection of changes fixes the customer bug, also seen with
> 12-07B.PS and reduces the number of differences to the non-fast HT
> code from 3931 to 1026. The 12-07B.PS still shows a screen angle
> issue (page 3) that occurs when num_repeat > 0, but changing the logic
> results in a marked increase in the number of differences. Also, xl
> tests show some phase shift in Y that remains unexplained.
> All other diffs appear to be transfer function related
> fixup
> base/gsht.c
> base/gxdht.h
> base/gxht_thresh.c
> base/gxht_thresh.h
> base/gxicolor.c
> base/gximono.c
> base/gzht.h

2015-08-14 15:13:27 +0100
Chris Liddell <chris.liddell@artifex.com>
6a90174e403131c372acf19e1d63e5d202333503

> Validate SMask object before evaluating it.
> and if it's not valid, replace the object with /None
> Relates to test file:
> tests_private/pdf/sumatra/broken_xobject_messing_up_clip_stack.pdf
> No cluster differences
> Resource/Init/pdf_draw.ps

2015-08-10 12:57:03 +0100
Chris Liddell <chris.liddell@artifex.com>
819e651a61d16c636821b3281a3cc70ec434dbb7

> Ensure imager state is not marked as graphics state
> In various places in the pdf14 compositor device, we use local copies of the
> imager state (so stuff specific to the pdf14 compositor functions doesn't
> accidentally affect the "upstream" state).
> This ensures that those copies are not marked as being a graphics state, in case
> the imager state started life as a full graphics state.
> No cluster differences.
> base/gdevp14.c

2015-08-10 09:34:48 +0100
Chris Liddell <chris.liddell@artifex.com>
91e952779b18b3db612c96d898cd3c6f6c433ca7

> Bug 696127: add missing tiffscaled* devs to configure build
> The tiffscaled4, tiffscaled8, tiffscaled24 and tiffscaled32 were missed from
> the default list of TIFF devices in the configure based builds.
> No cluster differences.
> configure.ac

2015-08-14 07:24:48 -0600
Henry Stiles <henry.stiles@artifex.com>
7b6538e2fac9dd4e7e423c4f974fcdd235626484

> Fix bug #694673, segmentation fault caused by "fuzzing" test.
> Deleting the current font resulted in later dereferencing an invalid
> pointer to the font. We now set the current font to "NULL". This
> problem should not have required a fuzzing test to find it should have
> been realized by the original CET 3.0 test.
> pcl/pxl/pxfont.c

2015-08-11 14:57:06 -0600
Henry Stiles <henry.stiles@artifex.com>
20d5f3dcf93022f843a8bba1e17594b768c85306

> Fix for bug 696124, character scaling with a singular matrix.
> By experiment HP does not ignore requests for font height which are out
> of range, instead it clamps the values to the limits of the range. The
> minimum is .25 points. The cet files in these bugs are requesting a
> font size of 0 and the HP laserjet does render a very small character
> which is visible but only readable with magnification assuming normal
> vision.
> This change just allows the matrix to be scaled to the minimum value
> allowing the test files in the bug to continue processing, these tiny
> characters do not render properly even with this change. The rounding of
> escapement would have to be worked in PCL and likely the font rasterizer
> would need to be looked at, the characters do not appear correct even
> with proper spacing.
> There is no practical demand to do this correctly, so we don't plan to
> work on it anytime soon.
> pcl/pcl/pcfont.c

2015-08-07 14:58:57 +0100
Ken Sharp <ken.sharp@artifex.com>
6ebbe34a5a5ae65a513f50970854032625d5a8db

> Coverity ID #102065 prevent a potential NULL pointer derefernce
> base/gdevsclass.c

2015-08-06 11:23:00 +0100
Ken Sharp <ken.sharp@artifex.com>
b22c02829e476a07a8c7fb93f919b2ea797a8791

> Commit 6fb23cff7abcef91d03b43454d2d40d79c5e83da was actually incorrect.
> The Coverity report is a false positive, and the change causes a seg fault, fixed here.
> At the same time fix another fualt that prevented the cluster building
> Ghostscript.
> devices/vector/gdevpdti.c
> devices/vector/gdevpdtt.c

2015-08-06 10:42:35 +0100
Ken Sharp <ken.sharp@artifex.com>
108ed487b6c24554b00e36f3b716fd37e427bd09

> Coverity ID #94769 restore saved FontMatrix on error
> devices/vector/gdevpdtt.c

2015-08-06 10:39:53 +0100
Ken Sharp <ken.sharp@artifex.com>
ae73639179ec10c29d902f7e802e769bca70fd06

> Coverity ID #94641 remove dead code
> devices/vector/gdevpdtt.c

2015-07-30 17:27:23 +0100
Chris Liddell <chris.liddell@artifex.com>
1fae53a708fca6c2ac0417bc23f5d095cc379250

> Bug 696101: fix uses of the sfopen API.
> The stream API in GS is defined as *always* opening files in binary mode,
> where applicable, so there is no need for the API clients to specify binary
> mode.
> This is previously been benign, and thus ignored, but reportedly ending up with
> a duplicate 'b' character in the mode causes a crash on Windows 10.
> No cluster differences.
> base/fapiufst.c
> base/gsicc_manage.c
> base/lib.mak
> base/sfxcommon.c
> base/strmio.h
> devices/vector/gdevpdfu.c
> pcl/pl/pllfont.c
> psi/zfile.c

2015-08-06 09:20:59 +0100
Ken Sharp <ken.sharp@artifex.com>
6fb23cff7abcef91d03b43454d2d40d79c5e83da

> Coverity ID #95037. Fix what looks like a simple oversight
> devices/vector/gdevpdti.c

2015-08-06 09:16:56 +0100
Ken Sharp <ken.sharp@artifex.com>
c2adcc65d5e56e008b082675bc3883edb92f57a4

> Coverity ID #94925 alter '>' to '>=' to avoid potential overrun
> devices/vector/gdevpdti.c

2015-08-06 09:05:53 +0100
Ken Sharp <ken.sharp@artifex.com>
eb2204d269bb5577170ad28fc837704c8f865dba

> Coverity ID #94859 avoid potential NULL pointer dereference
> devices/vector/gdevpdtd.c

2015-08-06 08:51:21 +0100
Ken Sharp <ken.sharp@artifex.com>
56d3dfcbb53294e980e3a0169c2e676143eb66e7

> Coverity ID #101184 prevent a potential NULL pointer dereference
> devices/vector/gdevpdfv.c

2015-08-06 08:25:54 +0100
Ken Sharp <ken.sharp@artifex.com>
38635d15c08f5359632bf3ed6162ed125ce204c0

> Coverity ID #94860 remove dead code
> devices/vector/gdevpdfp.c

2015-08-05 15:15:17 +0100
Ken Sharp <ken.sharp@artifex.com>
b71c1d775b1ca343a7cd80fc842f6681d2fd4037

> Coverity ID #101186 Remove some unused code to silence warnigns
> devices/vector/gdevpdfo.c

2015-08-05 14:50:15 +0100
Ken Sharp <ken.sharp@artifex.com>
2964fc6908aa86a9a7b2964b6c1e8d70459641b0

> Coverity ID #95040 check a return code
> devices/vector/gdevpdte.c

2015-08-04 16:02:37 +0100
Ken Sharp <ken.sharp@artifex.com>
6fc5e5a406e6dae25233719a8c6cc1442c774695

> pdfwrite - fix some sorting problems in Names trees
> Bug #696030 "main level of bookmarks not being set as destination"
> The new code to write the Names tree as a tree had some logical flaws when
> ordering the keys which led to some entries not being written.
> devices/vector/gdevpdfo.c

2015-08-04 08:55:11 +0100
Ken Sharp <ken.sharp@artifex.com>
b56ff42047f6df6e7c74a79b91cd7d193bfa7357

> pdfwrite - improved clips under rare conditions
> Bug #696093 "Distortion converting PS to PDF"
> The test file exposes a rare condition in the graphics library and the
> pdfwrite device.
> The example is carelessly constructed by the designer; a blue rectangle
> has an image laid over the top of it, the image is required to be at a
> particular position in order to align the text in the image with other
> parts of the text, in other images. This causes part of the image to
> obscure the underlying blue rectangle.
> A simple way to resolve this would be to change the z-order so that the
> rectangle lies on top of the image, or to apply a clip to the image to
> stop it overlapping. Instead the designer has created a new image, the
> same colour as the blue rectangle, and placed that on top of the image
> containing the text. This image has been clipped to a very small area. In
> addition the applied clip is not quite rectangular.
> The effect of this is that two clipping paths intersect, when this happens
> the graphics library calculates the intersection as a series of rectangles.
> Because the final clip is very small and very nearly rectangular, at the
> resolution used by pdfwrite the intersection (at pixel level) *is* a
> rectangle.
> So the code wrote the final clip as a rectangle. This works fine at specific
> resolutions, but at other resolutions (ie other zoom levels in Acrobat)
> the lack of precision caused the clip to go slightly awry, allowing the
> clipped image to get bigger and overlap portions of the image containing the
> text.
> The first part of the fix is in pdfwrite. We check the 'path_valid' member
> of the clip path structure. This is set if the clip is set due to a single
> path, if its the intersection of two paths, then path_valid is reset.
> We only write a simple rectangle if the clip path is a rectangle *and* the
> rectangle is the result of a single path.
> Otherwise, we use the path_list. This is a list of all the paths that were
> used to create this clip. By writing the paths out we recover the accuracy.
> There is, however, a second part to this. Initclip, and a few other operations
> can set the clip to a rectangular area, *without* setting a path. This
> results in path_valid being false *and* not having a path_list. In this case
> the pdfwrite code just writes the rectangle.
> There is one further wrinkle; If we had an existing clip which was overridden
> with a rectangle by one of these operators, the graphics library did not
> clear the path_list member of the clip path. This meant that the path_list
> referred to the paths which created a totally different clip to the one
> actually being applied. For rendering this isn't a problem, but for the
> pdfwrite device it caused us to write a completely incorrect set of paths.
> There are a number of cluster differences, mostly at low resolution
> (because the resolution matters):
> minor (single pixel changes)
> -----------------------------
> Bug689189.pdf
> Bug689748.pdf
> Bug690395.pdf
> Bug691115.pdf
> Bug694871.eps
> Bug695863.pdf
> pcl5ccet/32_02.bin
> catx4547.pdf
> catx6508.pdf
> x_-_text_clipped_away_above_141_pc.pdf
> 09-34.ps
> 10-01.ps
> minor changes
> --------------------
> pcl6cet3.0/c303.bin
> pcl6cet3.0/c304.bin
> pcl6cet3.0/c308.bin
> pcl6cet3.0/c309.bin
> pcl6cet3.0/c310.bin
> pcl6cet3.0/c311.bin
> pcl6cet3.0/c312.bin
> pcl6cet3.0/c314.bin
> pcl6cet3.0/c315.bin
> pcl6cet3.0/c316.bin
> pcl6cet3.0/c317.bin
> pcl6cet3.0/c318.bin
> pcl6cet3.0/c319.bin
> pcl6cet3.0/c321.bin
> pcl6cet3.0/c331.bin
> pcl6cet3.0/c332.bin
> pcl6cet3.0/c333.bin
> pcl6cet3.0/c335.bin
> pcl6cet3.0/c401.bin
> pcl6cet3.0/c403.bin
> pcl6cet3.0/c404.bin
> pcl6cet3.0/c405.bin
> pcl6cet3.0/c406.bin
> pcl6cet3.0/c407.bin
> pcl6cet3.0/c408.bin
> pcl6cet3.0/c409.bin
> pcl6cet3.0/c410.bin
> pcl6cet3.0/c411.bin
> pcl6cet3.0/c412.bin
> pcl6cet3.0/c413.bin
> pcl6cet3.0/c414.bin
> pcl6cet3.0/c415.bin
> pcl6cet3.0/c416.bin
> pcl6cet3.0/c417.bin
> pcl6cet3.0/c418.bin
> pcl6cet3.0/c420.bin
> pcl6cet3.0/c422.bin
> pcl6cet3.0/c424.bin
> pcl6cet3.0/c425.bin
> pcl6cet3.0/c426.bin
> minor (single pixel changes), probably progressions
> ----------------------------------------------------
> 09_47N.pdf
> 26_09.pdf
> 09-34.ps
> 10-01.ps
> 10-08.ps
> 10-13.ps
> 10-14.ps
> 10-16.ps
> 13-16.ps
> 13-17.ps
> 13-19.ps
> small but useful progressions
> Bug692720.pdf
> Bug694909.pdf
> x_-_text_clipped_away_above_141_pc.pdf
> significant progressions
> -------------------------
> pcl6cet3.0/c325.bin
> xpsfts-a4/fts_34xx.xps
> xpsfts-a4/fts_42xx.xps
> xpsfts-a4/fts_45xx.xps
> just different (wrong both ways)
> --------------------------------
> pcl6cet3.0/c421.bin
> pcl6cet3.0/c422.bin
> base/gspath.c
> devices/vector/gdevpdfd.c

2015-07-31 14:59:27 +0100
Ken Sharp <ken.sharp@artifex.com>
83e211723f975beff6ce488a2a6ee5105c089121

> Force the normal text handling to throw errors under the same (degenerate
> CTM) conditions as when -dTextAlphaBits is set.
> Currently if the CTM is something like [0 0 0 0 Tx Ty] then Ghostscript
> throws an error if -dTextAlphaBits is set, but not if it isn't. This leads
> to a number of bug reports citing problems with TextAlphaBits which really
> isn't the case.
> Testing Adobe seems to indicate that, for PostScript, and error is the
> expected behaviour.
> This commit adds a 'currentpoint' call in two places so that we get the same
> error no matter which code path we follow.
> The PDF interpreter has already been fixed so that all known cases will not
> throw errors with this commit, but two PCL files from Quality Logic do now
> throw an error, 18-08.bin and 18-09.bin. A bug report will be raised for
> these.
> base/gxfapi.c

2015-07-31 11:05:12 +0100
Ken Sharp <ken.sharp@artifex.com>
70b442162ff8f3d40595d0eb9fb365d341139ee2

> PDF interpreter - detect and 'fix' degenerate text matrices
> Cluster test files Bug689006.pdf, Bug690179.pdf and Bug694981.pdf all end
> up setting a degenerate text matrix (horizontal or vertical scale of 0)
> albeit in different ways.
> This commit detects these cases, and fixes the matrix by changing to a
> tiny scale factor, instead of 0.
> These files now work with -dTextAlphaBits=4, which they did not before. In
> addition there are several progressions exhibited.
> Bug694981.pdf now works with the psdcmyk device.
> singular_ctm_3_tr_mode.pdf and Bug689614.pdf with the ps2write device no
> longer produce PostScript files which error out on execution.
> Resource/Init/pdf_ops.ps

2015-07-29 08:57:01 +0100
Ken Sharp <ken.sharp@artifex.com>
b2f3441d5481e9629130b989d5ad14841f22ce98

> PDF interpreter - clamp horizontal text spacing to prevent degenerate CTM
> Bug #696107 "Text missing with -dTextAlphaBits=4"
> The file contains three occurrences of "0 Tz" which sets the horizontal
> scale factor to 0. This causes the CTM to have a zero horizontal scale
> which (correctly) throws an error when TextAlphaBits is set.
> This commit detects setting Tz to 0 and replaces it with a miniscule, but
> non-zero, value thus preventing the degenerate matrix and the error.
> A later commit will change the behaviour of the graphics library so that it
> is at least consistent with differing values for TextAlphaBits.
> Resource/Init/pdf_ops.ps

2015-07-30 12:09:53 -0700
Michael Vrhel <michael.vrhel@artifex.com>
47622dec684584b38571516b844e007cda7853c8

> Initial commit for color management in gproof device.
> There are four possible cases that had to be handled.
> They depend upon if we have or do not have non standard colorants
> and if we have or do not have the proper ICC profiles
> Essentially we may have to compute the equivalent CMYK colors
> for the image that includes spot colors and we may have to do
> a very slow conversion to RGB when we don't have the proper
> ICC profiles. The fastest case, occurs when we have an ICC
> for all our source colorants (including any spots).
> devices/gdevgprf.c

2015-07-29 07:17:58 -0700
Ray Johnston <ray.johnston@artifex.com>
ab674af32798e8b7ce46bb093acfe756d226cdf6

> Fixes for Windows build with VS 2015.
> Apparently snprintf is now available (since VS2014), and we need to
> make sure and undef bool to avoid conflicts.
> base/gp_mswin.c
> base/stdio_.h
> base/windows_.h
> jbig2dec/config_win32.h
> tiff/libtiff/tif_config.vc.h

2015-07-30 07:22:34 -0700
Ray Johnston <ray.johnston@artifex.com>
56045937000ea510c40347bc921a287624ea502d

> Add /PROFILE linker switch for gpcl, gxps profile builds on Windows
> base/msvccmd.mak

2015-07-29 11:51:56 -0700
Michael Vrhel <michael.vrhel@artifex.com>
be5f5ebf5c30219671d762c0423f83c86de93e62

> Make the lcms temp memory allocations use memory from the device
> With recent changes a link may not have a valid link cache entry and
> previously were using memory from the link cache entry for temporary
> memory allocations.
> base/gsicc_lcms2.c
> base/lib.mak

2015-07-27 12:17:13 -0700
Michael Vrhel <michael.vrhel@artifex.com>
7a6eafb5cbe23d7618bec87b3a904c9bb116150a

> Move a tiffsep method and struct to the common devn device so it can be used by others
> The gproof device needs to do some of the same things as the tiffsep device when
> the ICC profile is not sufficient to map the colorants.
> base/gdevdevn.c
> base/gdevdevn.h
> devices/gdevtsep.c

2015-07-25 17:53:34 +0100
Chris Liddell <chris.liddell@artifex.com>
e32fe0b1e0cebc58fa9d413d2c6541d26a238d04

> Bug 696114: fix disable compile inits build
> Fix mistakes for the non-compile inits build.
> For that case, we make a single empty romfs source file, which then gets built
> into different object files, one for each product. When I made those changes
> I got the source and object file names the wrong way round.
> base/lib.mak

2015-07-24 11:43:27 -0700
Michael Vrhel <michael.vrhel@artifex.com>
0eee21b097b505e24915b9c535ce166f92a397b6

> Create equivalent RGB colors from CMYK equivalent colors
> The ICC profiles are used if they are valid. If not, the old
> canned routines for doing the conversions are used. Note that
> the icc link was added to the context.
> devices/gdevgprf.c

2015-07-23 13:23:38 -0700
Michael Vrhel <michael.vrhel@artifex.com>
6e470ae65e274d9671df1bfc72007203c3158855

> Set up for color management in gproof device
> Here we remove code that is not needed as well as create the
> link between the source and the destination profiles and
> release it when the device is closed. Next step will be to apply
> the profile to the data.
> devices/gdevgprf.c

2015-07-23 12:59:17 -0700
Michael Vrhel <michael.vrhel@artifex.com>
547f44324971c716ae3ee4d7a2cb0b48e011f0b4

> Clean up a few items in the device based link allocation.
> Had to add a way to free the link, make sure the allocation is done in non-gc memory
> and initialize a few more items.
> base/gsicc_cache.c
> base/gsicc_cache.h

2015-07-23 11:19:46 -0700
Michael Vrhel <michael.vrhel@artifex.com>
a6ee000ceb76fe7da46aaa89ff5c5f7c304775a3

> Add support in ICC code for the creation of links that are not in the cache
> This is needed for use by device that are doing post rendering color management.
> In this case, they do not have access to the imager state and the icc cache. They
> typically only need one link which will be applied to the rendered data.
> base/gsicc_cache.c
> base/gsicc_cache.h

2015-07-22 15:28:48 -0700
Michael Vrhel <michael.vrhel@artifex.com>
3f492a9920f9d4cd30e6229c5b0b56bf1b7ade28

> Remove jasper and lcms (vers 1) references from ghostscript.vcproj
> windows/ghostscript.vcproj

2015-07-22 12:18:00 -0700
Michael Vrhel <michael.vrhel@artifex.com>
317b83e6f31f91a2a8c957df46f7d9b922290110

> Fix paths for files in visual studio project.
> windows/ghostscript.vcproj

2015-07-22 14:49:57 +0100
Chris Liddell <chris.liddell@artifex.com>
2c02e58e490f3488e506873018ad04f2565a82c9

> Remove the Postscript based CFF interpreter.
> The C CFF implementation has been the default for quite some time, and it is
> several years since we had the one problem reported on it, so it seems fitting
> to remove it as redundant, and it's supporting data.
> No cluster differences.
> Resource/Init/gs_cff.ps
> Resource/Init/gs_css_e.ps
> psi/int.mak
> psi/psromfs.mak

2015-07-22 18:05:56 +0100
Chris Liddell <chris.liddell@artifex.com>
b0fd01a31fc4f74a1afab5f915bfccc6864d0235

> Remove a FIXME comment.....
> Makefile.in

2015-07-21 08:30:10 -0700
Michael Vrhel <michael.vrhel@artifex.com>
f9c3dbc6ed02b9bba2f1d54dea10acce5145da24

> Add post rendering ICC profile to device params and Device ICC structure
> We will initially use this for the gsproof device but it would be accessible
> for any of the devices if they wish to do additional color managed processing
> for the creation of some special proofing output for example
> base/gscms.h
> base/gsdparam.c
> base/gsequivc.c
> base/gsicc_manage.c

2015-07-20 21:52:22 -0700
Michael Vrhel <michael.vrhel@artifex.com>
ba2eea6610e997ecd3735ee95d0325e59ae45006

> Fix typo in gx_default_get_param for TextICCProfile.
> base/gsdparam.c

2015-07-10 17:26:45 +0100
Robin Watts <robin.watts@artifex.com>
d94669ba0009288630bcec80a3dd725cfa7ba002

> First cut at gproof device.
> devices/devs.mak
> devices/gdevgprf.c
> windows/ghostscript.vcproj

2015-07-21 10:42:10 +0100
Robin Watts <robin.watts@artifex.com>
578025a9cc9cd682f8570004f6d873e76f1af3ef

> MS solution; move to windows directory
> Remove repeated files from within ghostpdl.
> All.vcproj
> GhostPDL.sln
> ghostall.vcproj
> ghostpcl.vcproj
> ghostpdl.vcproj
> ghostscript-ufst.vcproj
> ghostscript.vcproj
> ghostscript_rt.vcxproj
> ghostxps.vcproj
> windows/All.vcproj
> windows/GhostPDL.sln
> windows/ghostpcl.vcproj
> windows/ghostpdl.vcproj
> windows/ghostscript-ufst.vcproj
> windows/ghostscript.vcproj
> windows/ghostscript_rt.vcxproj
> windows/ghostxps.vcproj

2015-07-21 14:12:07 +0100
Chris Liddell <chris.liddell@artifex.com>
d9eff8f0120d772189bf54fb5de6f7d0b061e7b3

> Fix a few mistakes in the Windows makefiles
> base/lcupsi.mak
> psi/msvc.mak

2015-07-21 11:45:02 +0100
Chris Liddell <chris.liddell@artifex.com>
15436d6ad86d5f394b5699474be82f624a289685

> Add targets for memento and profile builds
> for each individual executable. And update the VS projects to use them
> base/unix-end.mak
> ghostpcl.vcproj
> ghostpdl.vcproj
> ghostscript.vcproj
> ghostxps.vcproj
> psi/msvc.mak

2015-07-21 00:08:24 +0100
Robin Watts <robin.watts@artifex.com>
2aa05a2667836e9bb9f46a4d64ceb68f14556214

> MS solution; add 'All' project.
> The All project invokes some new makefile targets. These makefile
> targets just depend on all the appropriate existing makefile targets.
> Thus we get a sequential build of the different projects.
> Nmake does not (yet) support parallelism, so we don't have the problem
> of building multiple projects in parallel as we get when we build
> multiple projects in the solution.
> We use the configuration manager in the solution to ensure that when
> we build the entire solution, only 'All' is built.
> All.vcproj
> GhostPDL.sln
> ghostall.vcproj

2015-07-20 20:29:26 +0100
Robin Watts <robin.watts@artifex.com>
428c32050b287e90db4d77ff920dd37162d43c94

> Tweak VS solution a bit more; avoid repeating files.
> To avoid files showing up more than once when we search for them,
> ensure that each file is only included once. This means that common
> files are listed only under ghostscript.
> This makes no difference to builds etc, as that's all handled by the
> Makefiles.
> ghostpcl.vcproj
> ghostscript.vcproj
> ghostxps.vcproj

2015-07-20 20:06:28 +0100
Robin Watts <robin.watts@artifex.com>
c676ef3689f80f9103727a40e91fcbcf52882f3f

> Fix VS solution configuration issues.
> It seems the solution has gotten confused, and wants to build
> Release-contrib for all exes in all cases.
> GhostPDL.sln

2015-07-20 21:25:10 +0100
Chris Liddell <chris.liddell@artifex.com>
4a545c49f3a22a891c60cbd0f228b1c08fe11ec4

> Fix the gpcl6 and gxps targets for Windows.
> psi/msvc.mak

2013-07-23 16:24:19 +0100
Chris Liddell <chris.liddell@artifex.com>
6948650efd3fb9e2a70b8cf16aca57e9d0b7eb0a

> Commit of build_consolidation branch
> Squashed into one commit (see branch for details of the evolution of the
> branch).
> This brings gpcl6 and gxps into the Ghostscript build system, and a shared
> set of graphics library object files for all the interpreters.
> Also, brings the same configuration options to the pcl and xps products as we
> have for Ghostscript.
> COPYING
> COPYING.AFPL
> DroidSansFallback.NOTICE
> GhostPDL.sln
> LICENSE
> Makefile
> Makefile.in
> NEWS
> README.txt
> Resource/CIDFSubst/DroidSansFallback.ttf
> Resource/CIDFont/ArtifexBullet
> Resource/CMap/78-EUC-H
> Resource/CMap/78-EUC-V
> Resource/CMap/78-H
> Resource/CMap/78-RKSJ-H
> Resource/CMap/78-RKSJ-V
> Resource/CMap/78-V
> Resource/CMap/78ms-RKSJ-H
> Resource/CMap/78ms-RKSJ-V
> Resource/CMap/83pv-RKSJ-H
> Resource/CMap/90ms-RKSJ-H
> Resource/CMap/90ms-RKSJ-V
> Resource/CMap/90msp-RKSJ-H
> Resource/CMap/90msp-RKSJ-V
> Resource/CMap/90pv-RKSJ-H
> Resource/CMap/90pv-RKSJ-V
> Resource/CMap/Add-H
> Resource/CMap/Add-RKSJ-H
> Resource/CMap/Add-RKSJ-V
> Resource/CMap/Add-V
> Resource/CMap/Adobe-CNS1-0
> Resource/CMap/Adobe-CNS1-1
> Resource/CMap/Adobe-CNS1-2
> Resource/CMap/Adobe-CNS1-3
> Resource/CMap/Adobe-CNS1-4
> Resource/CMap/Adobe-CNS1-5
> Resource/CMap/Adobe-CNS1-6
> Resource/CMap/Adobe-GB1-0
> Resource/CMap/Adobe-GB1-1
> Resource/CMap/Adobe-GB1-2
> Resource/CMap/Adobe-GB1-3
> Resource/CMap/Adobe-GB1-4
> Resource/CMap/Adobe-GB1-5
> Resource/CMap/Adobe-Japan1-0
> Resource/CMap/Adobe-Japan1-1
> Resource/CMap/Adobe-Japan1-2
> Resource/CMap/Adobe-Japan1-3
> Resource/CMap/Adobe-Japan1-4
> Resource/CMap/Adobe-Japan1-5
> Resource/CMap/Adobe-Japan1-6
> Resource/CMap/Adobe-Korea1-0
> Resource/CMap/Adobe-Korea1-1
> Resource/CMap/Adobe-Korea1-2
> Resource/CMap/B5-H
> Resource/CMap/B5-V
> Resource/CMap/B5pc-H
> Resource/CMap/B5pc-V
> Resource/CMap/CNS-EUC-H
> Resource/CMap/CNS-EUC-V
> Resource/CMap/CNS1-H
> Resource/CMap/CNS1-V
> Resource/CMap/CNS2-H
> Resource/CMap/CNS2-V
> Resource/CMap/ETHK-B5-H
> Resource/CMap/ETHK-B5-V
> Resource/CMap/ETen-B5-H
> Resource/CMap/ETen-B5-V
> Resource/CMap/ETenms-B5-H
> Resource/CMap/ETenms-B5-V
> Resource/CMap/EUC-H
> Resource/CMap/EUC-V
> Resource/CMap/Ext-H
> Resource/CMap/Ext-RKSJ-H
> Resource/CMap/Ext-RKSJ-V
> Resource/CMap/Ext-V
> Resource/CMap/GB-EUC-H
> Resource/CMap/GB-EUC-V
> Resource/CMap/GB-H
> Resource/CMap/GB-V
> Resource/CMap/GBK-EUC-H
> Resource/CMap/GBK-EUC-V
> Resource/CMap/GBK2K-H
> Resource/CMap/GBK2K-V
> Resource/CMap/GBKp-EUC-H
> Resource/CMap/GBKp-EUC-V
> Resource/CMap/GBT-EUC-H
> Resource/CMap/GBT-EUC-V
> Resource/CMap/GBT-H
> Resource/CMap/GBT-V
> Resource/CMap/GBTpc-EUC-H
> Resource/CMap/GBTpc-EUC-V
> Resource/CMap/GBpc-EUC-H
> Resource/CMap/GBpc-EUC-V
> Resource/CMap/H
> Resource/CMap/HKdla-B5-H
> Resource/CMap/HKdla-B5-V
> Resource/CMap/HKdlb-B5-H
> Resource/CMap/HKdlb-B5-V
> Resource/CMap/HKgccs-B5-H
> Resource/CMap/HKgccs-B5-V
> Resource/CMap/HKm314-B5-H
> Resource/CMap/HKm314-B5-V
> Resource/CMap/HKm471-B5-H
> Resource/CMap/HKm471-B5-V
> Resource/CMap/HKscs-B5-H
> Resource/CMap/HKscs-B5-V
> Resource/CMap/Hankaku
> Resource/CMap/Hiragana
> Resource/CMap/Identity-H
> Resource/CMap/Identity-UTF16-H
> Resource/CMap/Identity-V
> Resource/CMap/KSC-EUC-H
> Resource/CMap/KSC-EUC-V
> Resource/CMap/KSC-H
> Resource/CMap/KSC-Johab-H
> Resource/CMap/KSC-Johab-V
> Resource/CMap/KSC-V
> Resource/CMap/KSCms-UHC-H
> Resource/CMap/KSCms-UHC-HW-H
> Resource/CMap/KSCms-UHC-HW-V
> Resource/CMap/KSCms-UHC-V
> Resource/CMap/KSCpc-EUC-H
> Resource/CMap/KSCpc-EUC-V
> Resource/CMap/Katakana
> Resource/CMap/NWP-H
> Resource/CMap/NWP-V
> Resource/CMap/RKSJ-H
> Resource/CMap/RKSJ-V
> Resource/CMap/Roman
> Resource/CMap/UniCNS-UCS2-H
> Resource/CMap/UniCNS-UCS2-V
> Resource/CMap/UniCNS-UTF16-H
> Resource/CMap/UniCNS-UTF16-V
> Resource/CMap/UniCNS-UTF32-H
> Resource/CMap/UniCNS-UTF32-V
> Resource/CMap/UniCNS-UTF8-H
> Resource/CMap/UniCNS-UTF8-V
> Resource/CMap/UniGB-UCS2-H
> Resource/CMap/UniGB-UCS2-V
> Resource/CMap/UniGB-UTF16-H
> Resource/CMap/UniGB-UTF16-V
> Resource/CMap/UniGB-UTF32-H
> Resource/CMap/UniGB-UTF32-V
> Resource/CMap/UniGB-UTF8-H
> Resource/CMap/UniGB-UTF8-V
> Resource/CMap/UniHojo-UCS2-H
> Resource/CMap/UniJIS-UCS2-H
> Resource/CMap/UniJIS-UCS2-HW-H
> Resource/CMap/UniJIS-UCS2-HW-V
> Resource/CMap/UniJIS-UCS2-V
> Resource/CMap/UniJIS-UTF16-H
> Resource/CMap/UniJIS-UTF16-V
> Resource/CMap/UniJIS-UTF32-H
> Resource/CMap/UniJIS-UTF32-V
> Resource/CMap/UniJIS-UTF8-H
> Resource/CMap/UniJIS-UTF8-V
> Resource/CMap/UniJIS2004-UTF16-H
> Resource/CMap/UniJIS2004-UTF16-V
> Resource/CMap/UniJIS2004-UTF32-H
> Resource/CMap/UniJIS2004-UTF32-V
> Resource/CMap/UniJIS2004-UTF8-H
> Resource/CMap/UniJIS2004-UTF8-V
> Resource/CMap/UniJISPro-UCS2-HW-V
> Resource/CMap/UniJISPro-UCS2-V
> Resource/CMap/UniJISPro-UTF8-V
> Resource/CMap/UniJISX0213-UTF32-H
> Resource/CMap/UniJISX0213-UTF32-V
> Resource/CMap/UniJISX02132004-UTF32-H
> Resource/CMap/UniJISX02132004-UTF32-V
> Resource/CMap/UniKS-UCS2-H
> Resource/CMap/UniKS-UCS2-V
> Resource/CMap/UniKS-UTF16-H
> Resource/CMap/UniKS-UTF16-V
> Resource/CMap/UniKS-UTF32-H
> Resource/CMap/UniKS-UTF32-V
> Resource/CMap/UniKS-UTF8-H
> Resource/CMap/UniKS-UTF8-V
> Resource/CMap/V
> Resource/CMap/WP-Symbol
> Resource/ColorSpace/DefaultCMYK
> Resource/ColorSpace/DefaultGray
> Resource/ColorSpace/DefaultRGB
> Resource/ColorSpace/TrivialCMYK
> Resource/ColorSpace/sGray
> Resource/ColorSpace/sRGB
> Resource/Decoding/FCO_Dingbats
> Resource/Decoding/FCO_Symbol
> Resource/Decoding/FCO_Unicode
> Resource/Decoding/FCO_Wingdings
> Resource/Decoding/Latin1
> Resource/Decoding/StandardEncoding
> Resource/Decoding/Unicode
> Resource/Encoding/CEEncoding
> Resource/Encoding/ExpertEncoding
> Resource/Encoding/ExpertSubsetEncoding
> Resource/Encoding/NotDefEncoding
> Resource/Encoding/Wingdings
> Resource/Font/BookmanURW-DemBol
> Resource/Font/BookmanURW-DemBolIta
> Resource/Font/BookmanURW-Lig
> Resource/Font/BookmanURW-LigIta
> Resource/Font/CenturySchURW-Bol
> Resource/Font/CenturySchURW-BolIta
> Resource/Font/CenturySchURW-Ita
> Resource/Font/CenturySchURW-Rom
> Resource/Font/ChanceryURW-MedIta
> Resource/Font/Dingbats
> Resource/Font/NimbusMono-Bold
> Resource/Font/NimbusMono-BoldOblique
> Resource/Font/NimbusMono-Oblique
> Resource/Font/NimbusMono-Regular
> Resource/Font/NimbusRomNo9L-Med
> Resource/Font/NimbusRomNo9L-MedIta
> Resource/Font/NimbusRomNo9L-Reg
> Resource/Font/NimbusRomNo9L-RegIta
> Resource/Font/NimbusSanL-Bol
> Resource/Font/NimbusSanL-BolIta
> Resource/Font/NimbusSanL-Reg
> Resource/Font/NimbusSanL-RegIta
> Resource/Font/NimbusSanNar-Bol
> Resource/Font/NimbusSanNar-BolIta
> Resource/Font/NimbusSanNar-Ita
> Resource/Font/NimbusSanNar-Reg
> Resource/Font/PalladioURW-Bol
> Resource/Font/PalladioURW-BolIta
> Resource/Font/PalladioURW-Ita
> Resource/Font/PalladioURW-Rom
> Resource/Font/StandardSymL
> Resource/Font/URWGothic-Boo
> Resource/Font/URWGothic-BooObl
> Resource/Font/URWGothic-Dem
> Resource/Font/URWGothic-DemObl
> Resource/IdiomSet/Pscript5Idiom
> Resource/Init/FAPIcidfmap
> Resource/Init/FAPIconfig
> Resource/Init/FAPIfontmap
> Resource/Init/FCOfontmap-PCLPS2
> Resource/Init/Fontmap
> Resource/Init/Fontmap.GS
> Resource/Init/cidfmap
> Resource/Init/gs_agl.ps
> Resource/Init/gs_btokn.ps
> Resource/Init/gs_cet.ps
> Resource/Init/gs_cff.ps
> Resource/Init/gs_cidcm.ps
> Resource/Init/gs_ciddc.ps
> Resource/Init/gs_cidfm.ps
> Resource/Init/gs_cidfn.ps
> Resource/Init/gs_cidtt.ps
> Resource/Init/gs_cmap.ps
> Resource/Init/gs_cspace.ps
> Resource/Init/gs_css_e.ps
> Resource/Init/gs_dbt_e.ps
> Resource/Init/gs_diskf.ps
> Resource/Init/gs_diskn.ps
> Resource/Init/gs_dpnxt.ps
> Resource/Init/gs_dps.ps
> Resource/Init/gs_dps1.ps
> Resource/Init/gs_dps2.ps
> Resource/Init/gs_dscp.ps
> Resource/Init/gs_epsf.ps
> Resource/Init/gs_fapi.ps
> Resource/Init/gs_fntem.ps
> Resource/Init/gs_fonts.ps
> Resource/Init/gs_frsd.ps
> Resource/Init/gs_icc.ps
> Resource/Init/gs_il1_e.ps
> Resource/Init/gs_img.ps
> Resource/Init/gs_init.ps
> Resource/Init/gs_l2img.ps
> Resource/Init/gs_lev2.ps
> Resource/Init/gs_ll3.ps
> Resource/Init/gs_mex_e.ps
> Resource/Init/gs_mgl_e.ps
> Resource/Init/gs_mro_e.ps
> Resource/Init/gs_pdf_e.ps
> Resource/Init/gs_pdfwr.ps
> Resource/Init/gs_res.ps
> Resource/Init/gs_resmp.ps
> Resource/Init/gs_setpd.ps
> Resource/Init/gs_statd.ps
> Resource/Init/gs_std_e.ps
> Resource/Init/gs_sym_e.ps
> Resource/Init/gs_trap.ps
> Resource/Init/gs_ttf.ps
> Resource/Init/gs_typ32.ps
> Resource/Init/gs_typ42.ps
> Resource/Init/gs_type1.ps
> Resource/Init/gs_wan_e.ps
> Resource/Init/pdf_base.ps
> Resource/Init/pdf_cslayer.ps
> Resource/Init/pdf_draw.ps
> Resource/Init/pdf_font.ps
> Resource/Init/pdf_main.ps
> Resource/Init/pdf_ops.ps
> Resource/Init/pdf_rbld.ps
> Resource/Init/pdf_sec.ps
> Resource/Init/xlatmap
> Resource/SubstCID/CNS1-WMode
> Resource/SubstCID/GB1-WMode
> Resource/SubstCID/Japan1-WMode
> Resource/SubstCID/Korea1-WMode
> arch/osx-x86-x86_64-ppc-gcc.h
> arch/windows-arm-msvc.h
> arch/windows-x64-msvc.h
> arch/windows-x86-msvc.h
> autogen.sh
> base/ConvertUTF.c
> base/ConvertUTF.h
> base/aes.c
> base/aes.h
> base/all-arch.mak
> base/append_l.com
> base/assert_.h
> base/bcc32.cfg
> base/bench.c
> base/catmake
> base/copy_one.com
> base/cp.bat
> base/cp.cmd
> base/ctype_.h
> base/dirent_.h
> base/dos_.h
> base/echogs.c
> base/errno_.h
> base/expat.mak
> base/fapi_bs.mak
> base/fapi_ft.c
> base/fapibstm.c
> base/fapiufst.c
> base/fcntl_.h
> base/freetype.mak
> base/gconf.c
> base/gconf.h
> base/gdbflags.h
> base/gdebug.h
> base/gdevabuf.c
> base/gdevbbox.c
> base/gdevbbox.h
> base/gdevdbit.c
> base/gdevdcrd.c
> base/gdevdcrd.h
> base/gdevddrw.c
> base/gdevddrw.h
> base/gdevdevn.c
> base/gdevdevn.h
> base/gdevdevnprn.h
> base/gdevdflt.c
> base/gdevdgbr.c
> base/gdevdrop.c
> base/gdevdsha.c
> base/gdevemap.c
> base/gdevflp.c
> base/gdevflp.h
> base/gdevhit.c
> base/gdevkrnlsclass.c
> base/gdevkrnlsclass.h
> base/gdevm1.c
> base/gdevm16.c
> base/gdevm2.c
> base/gdevm24.c
> base/gdevm32.c
> base/gdevm4.c
> base/gdevm40.c
> base/gdevm48.c
> base/gdevm56.c
> base/gdevm64.c
> base/gdevm8.c
> base/gdevmem.c
> base/gdevmem.h
> base/gdevmpla.c
> base/gdevmpla.h
> base/gdevmplt.c
> base/gdevmplt.h
> base/gdevmr1.c
> base/gdevmr2n.c
> base/gdevmr8n.c
> base/gdevmrop.h
> base/gdevmrun.c
> base/gdevmrun.h
> base/gdevmx.c
> base/gdevnfwd.c
> base/gdevoflt.c
> base/gdevoflt.h
> base/gdevp14.c
> base/gdevp14.h
> base/gdevpccm.c
> base/gdevpccm.h
> base/gdevpipe.c
> base/gdevplnx.c
> base/gdevplnx.h
> base/gdevppla.c
> base/gdevppla.h
> base/gdevprn.c
> base/gdevprn.h
> base/gdevprna.c
> base/gdevprna.h
> base/gdevpxat.h
> base/gdevpxen.h
> base/gdevpxop.h
> base/gdevrops.c
> base/gdevsclass.c
> base/gdevsclass.h
> base/gdevvec.c
> base/gdevvec.h
> base/genarch.c
> base/genconf.c
> base/gendev.c
> base/genht.c
> base/gp.h
> base/gp_dosfe.c
> base/gp_dosfs.c
> base/gp_dvx.c
> base/gp_getnv.c
> base/gp_mac.c
> base/gp_mac.h
> base/gp_macio.c
> base/gp_macpoll.c
> base/gp_mktmp.c
> base/gp_msdll.c
> base/gp_msdos.c
> base/gp_mshdl.c
> base/gp_mslib.c
> base/gp_mspol.c
> base/gp_msprn.c
> base/gp_mswin.c
> base/gp_mswin.h
> base/gp_nsync.c
> base/gp_ntfs.c
> base/gp_os2.c
> base/gp_os2.h
> base/gp_os2fs.c
> base/gp_os2pr.c
> base/gp_os9.c
> base/gp_paper.c
> base/gp_psync.c
> base/gp_stdia.c
> base/gp_stdin.c
> base/gp_strdl.c
> base/gp_sysv.c
> base/gp_unifn.c
> base/gp_unifs.c
> base/gp_unix.c
> base/gp_unix_cache.c
> base/gp_upapr.c
> base/gp_vms.c
> base/gp_wgetv.c
> base/gp_win32.c
> base/gp_wpapr.c
> base/gp_wsync.c
> base/gp_wutf8.c
> base/gpcheck.h
> base/gpgetenv.h
> base/gpmisc.c
> base/gpmisc.h
> base/gpsync.h
> base/gs.mak
> base/gs_dll_call.h
> base/gs_mgl_e.h
> base/gs_mro_e.h
> base/gsalloc.c
> base/gsalloc.h
> base/gsalpha.c
> base/gsalpha.h
> base/gsalphac.c
> base/gsalphac.h
> base/gsargs.c
> base/gsargs.h
> base/gsbitcom.c
> base/gsbitmap.h
> base/gsbitops.c
> base/gsbitops.h
> base/gsbittab.c
> base/gsbittab.h
> base/gsccode.h
> base/gsccolor.h
> base/gscdef.c
> base/gscdefs.h
> base/gscdevn.c
> base/gscdevn.h
> base/gscedata.c
> base/gscedata.h
> base/gscencs.c
> base/gscencs.h
> base/gschar.c
> base/gschar.h
> base/gschar0.c
> base/gscicach.c
> base/gscicach.h
> base/gscie.c
> base/gscie.h
> base/gsciemap.c
> base/gscindex.h
> base/gsclipsr.c
> base/gsclipsr.h
> base/gscms.h
> base/gscolor.c
> base/gscolor.h
> base/gscolor1.c
> base/gscolor1.h
> base/gscolor2.c
> base/gscolor2.h
> base/gscolor3.c
> base/gscolor3.h
> base/gscolorbuffer.c
> base/gscolorbuffer.h
> base/gscompt.h
> base/gscoord.c
> base/gscoord.h
> base/gscparam.c
> base/gscpixel.c
> base/gscpixel.h
> base/gscpm.h
> base/gscrd.c
> base/gscrd.h
> base/gscrdp.c
> base/gscrdp.h
> base/gscrypt1.c
> base/gscrypt1.h
> base/gscscie.c
> base/gscsel.h
> base/gscsepr.c
> base/gscsepr.h
> base/gscspace.c
> base/gscspace.h
> base/gscssub.c
> base/gscssub.h
> base/gsdcolor.h
> base/gsdevice.c
> base/gsdevice.h
> base/gsdevmem.c
> base/gsdfilt.c
> base/gsdfilt.h
> base/gsdll.h
> base/gsdllwin.h
> base/gsdparam.c
> base/gsdpnext.h
> base/gsdps.c
> base/gsdps.h
> base/gsdps1.c
> base/gsdsrc.c
> base/gsdsrc.h
> base/gsequivc.c
> base/gsequivc.h
> base/gserrors.h
> base/gsexit.h
> base/gsfcid.c
> base/gsfcid2.c
> base/gsfcmap.c
> base/gsfcmap.h
> base/gsfcmap1.c
> base/gsflip.c
> base/gsflip.h
> base/gsfname.c
> base/gsfname.h
> base/gsfont.c
> base/gsfont.h
> base/gsfont0.c
> base/gsfont0c.c
> base/gsform1.h
> base/gsfunc.c
> base/gsfunc.h
> base/gsfunc0.c
> base/gsfunc0.h
> base/gsfunc3.c
> base/gsfunc3.h
> base/gsfunc4.c
> base/gsfunc4.h
> base/gsgc.h
> base/gsgcache.c
> base/gsgcache.h
> base/gsgdata.c
> base/gsgdata.h
> base/gshsb.c
> base/gshsb.h
> base/gsht.c
> base/gsht.h
> base/gsht1.c
> base/gsht1.h
> base/gshtscr.c
> base/gshtx.c
> base/gshtx.h
> base/gsicc.c
> base/gsicc.h
> base/gsicc_cache.c
> base/gsicc_cache.h
> base/gsicc_cms.h
> base/gsicc_create.c
> base/gsicc_create.h
> base/gsicc_lcms.c
> base/gsicc_lcms2.c
> base/gsicc_manage.c
> base/gsicc_manage.h
> base/gsicc_monitorcm.c
> base/gsicc_nocm.c
> base/gsicc_profilecache.c
> base/gsicc_profilecache.h
> base/gsicc_replacecm.c
> base/gsimage.c
> base/gsimage.h
> base/gsimpath.c
> base/gsinit.c
> base/gsio.h
> base/gsiodev.c
> base/gsiodevs.c
> base/gsiodisk.c
> base/gsiomacres.c
> base/gsioram.c
> base/gsiorom.c
> base/gsiorom.h
> base/gsipar3x.h
> base/gsiparam.h
> base/gsiparm2.h
> base/gsiparm3.h
> base/gsiparm4.h
> base/gsistate.c
> base/gsjconf.h
> base/gsjmorec.h
> base/gslib.c
> base/gslib.h
> base/gslibctx.c
> base/gslibctx.h
> base/gsline.c
> base/gsline.h
> base/gslparam.h
> base/gsmalloc.c
> base/gsmalloc.h
> base/gsmatrix.c
> base/gsmatrix.h
> base/gsmchunk.c
> base/gsmchunk.h
> base/gsmd5.c
> base/gsmd5.h
> base/gsmdebug.h
> base/gsmemlok.c
> base/gsmemlok.h
> base/gsmemory.c
> base/gsmemory.h
> base/gsmemraw.h
> base/gsmemret.c
> base/gsmemret.h
> base/gsmisc.c
> base/gsnamecl.c
> base/gsnamecl.h
> base/gsncdummy.c
> base/gsncdummy.h
> base/gsnogc.c
> base/gsnogc.h
> base/gsnotify.c
> base/gsnotify.h
> base/gsovrc.c
> base/gsovrc.h
> base/gspaint.c
> base/gspaint.h
> base/gsparam.c
> base/gsparam.h
> base/gsparam2.c
> base/gsparams.c
> base/gsparams.h
> base/gsparamx.c
> base/gsparamx.h
> base/gspath.c
> base/gspath.h
> base/gspath1.c
> base/gspath2.h
> base/gspcolor.c
> base/gspcolor.h
> base/gspenum.h
> base/gspmdrv.c
> base/gspmdrv.def
> base/gspmdrv.h
> base/gspmdrv.icx
> base/gspmdrv.rc
> base/gsptype1.c
> base/gsptype1.h
> base/gsptype2.c
> base/gsptype2.h
> base/gsrect.h
> base/gsrefct.h
> base/gsromfs0.c
> base/gsrop.c
> base/gsrop.h
> base/gsroprun.c
> base/gsroprun1.h
> base/gsroprun24.h
> base/gsroprun8.h
> base/gsropt.h
> base/gsroptab.c
> base/gsserial.c
> base/gsserial.h
> base/gsshade.c
> base/gsshade.h
> base/gssprintf.c
> base/gssprintf.h
> base/gsstate.c
> base/gsstate.h
> base/gsstrtok.c
> base/gsstrtok.h
> base/gsstruct.h
> base/gsstype.h
> base/gstext.c
> base/gstext.h
> base/gstiffio.c
> base/gstiffio.h
> base/gstparam.h
> base/gstrans.c
> base/gstrans.h
> base/gstrap.c
> base/gstrap.h
> base/gstype1.c
> base/gstype1.h
> base/gstype2.c
> base/gstype42.c
> base/gstypes.h
> base/gsuid.h
> base/gsutil.c
> base/gsutil.h
> base/gswin.icx
> base/gswin.rc
> base/gswin16.icx
> base/gswin32.rc
> base/gsxfont.h
> base/gx.h
> base/gxacpath.c
> base/gxalloc.h
> base/gxalpha.h
> base/gxarith.h
> base/gxband.h
> base/gxbcache.c
> base/gxbcache.h
> base/gxbitfmt.h
> base/gxbitmap.h
> base/gxbitops.h
> base/gxblend.c
> base/gxblend.h
> base/gxblend1.c
> base/gxccache.c
> base/gxccman.c
> base/gxcdevn.h
> base/gxchar.c
> base/gxchar.h
> base/gxchrout.c
> base/gxchrout.h
> base/gxcht.c
> base/gxcid.h
> base/gxcie.h
> base/gxcindex.h
> base/gxclbits.c
> base/gxcldev.h
> base/gxclfile.c
> base/gxclimag.c
> base/gxclio.h
> base/gxclip.c
> base/gxclip.h
> base/gxclip2.c
> base/gxclip2.h
> base/gxclipm.c
> base/gxclipm.h
> base/gxclipsr.h
> base/gxclist.c
> base/gxclist.h
> base/gxcllzw.c
> base/gxclmem.c
> base/gxclmem.h
> base/gxclpage.c
> base/gxclpage.h
> base/gxclpath.c
> base/gxclpath.h
> base/gxclrast.c
> base/gxclread.c
> base/gxclrect.c
> base/gxclthrd.c
> base/gxclthrd.h
> base/gxclutil.c
> base/gxclzlib.c
> base/gxcmap.c
> base/gxcmap.h
> base/gxcolor2.h
> base/gxcomp.h
> base/gxcoord.h
> base/gxcpath.c
> base/gxcpath.h
> base/gxcspace.h
> base/gxctable.c
> base/gxctable.h
> base/gxcvalue.h
> base/gxdcconv.c
> base/gxdcconv.h
> base/gxdcolor.c
> base/gxdcolor.h
> base/gxdda.h
> base/gxdevbuf.h
> base/gxdevcli.h
> base/gxdevice.h
> base/gxdevmem.h
> base/gxdevndi.c
> base/gxdevndi.h
> base/gxdevrop.h
> base/gxdevsop.h
> base/gxdht.h
> base/gxdhtres.h
> base/gxdhtserial.c
> base/gxdhtserial.h
> base/gxdither.h
> base/gxdownscale.c
> base/gxdownscale.h
> base/gxdtfill.h
> base/gxfapi.c
> base/gxfapi.h
> base/gxfapiu.c
> base/gxfapiu.h
> base/gxfarith.h
> base/gxfcache.h
> base/gxfcid.h
> base/gxfcmap.h
> base/gxfcmap1.h
> base/gxfdrop.c
> base/gxfdrop.h
> base/gxfill.c
> base/gxfill.h
> base/gxfillsl.h
> base/gxfilltr.h
> base/gxfillts.h
> base/gxfixed.h
> base/gxfmap.h
> base/gxfont.h
> base/gxfont0.h
> base/gxfont0c.h
> base/gxfont1.h
> base/gxfont42.h
> base/gxfrac.h
> base/gxftype.h
> base/gxfunc.h
> base/gxgetbit.h
> base/gxhintn.c
> base/gxhintn.h
> base/gxhintn1.c
> base/gxhldevc.c
> base/gxhldevc.h
> base/gxht.c
> base/gxht.h
> base/gxht_thresh.c
> base/gxht_thresh.h
> base/gxhtbit.c
> base/gxhttile.h
> base/gxhttype.h
> base/gxi12bit.c
> base/gxi16bit.c
> base/gxiclass.h
> base/gxicolor.c
> base/gxidata.c
> base/gxifast.c
> base/gximag3x.c
> base/gximag3x.h
> base/gximage.c
> base/gximage.h
> base/gximage1.c
> base/gximage2.c
> base/gximage3.c
> base/gximage3.h
> base/gximage4.c
> base/gximask.c
> base/gximask.h
> base/gximdecode.c
> base/gximdecode.h
> base/gximono.c
> base/gxino12b.c
> base/gxino16b.c
> base/gxiodev.h
> base/gxiparam.h
> base/gxipixel.c
> base/gxiscale.c
> base/gxistate.h
> base/gxline.h
> base/gxlum.h
> base/gxmatrix.h
> base/gxmclip.c
> base/gxmclip.h
> base/gxobj.h
> base/gxoprect.c
> base/gxoprect.h
> base/gxp1fill.c
> base/gxp1impl.h
> base/gxpageq.c
> base/gxpageq.h
> base/gxpaint.c
> base/gxpaint.h
> base/gxpath.c
> base/gxpath.h
> base/gxpath2.c
> base/gxpcache.h
> base/gxpcmap.c
> base/gxpcolor.h
> base/gxpcopy.c
> base/gxpdash.c
> base/gxpflat.c
> base/gxrplane.h
> base/gxsample.c
> base/gxsample.h
> base/gxsamplp.h
> base/gxshade.c
> base/gxshade.h
> base/gxshade1.c
> base/gxshade4.c
> base/gxshade4.h
> base/gxshade6.c
> base/gxstate.h
> base/gxstdio.h
> base/gxstroke.c
> base/gxsync.c
> base/gxsync.h
> base/gxtext.h
> base/gxtmap.h
> base/gxttf.h
> base/gxttfb.c
> base/gxttfb.h
> base/gxtype1.c
> base/gxtype1.h
> base/gxxfont.h
> base/gzacpath.h
> base/gzcpath.h
> base/gzht.h
> base/gzline.h
> base/gzpath.h
> base/gzspotan.c
> base/gzspotan.h
> base/gzstate.h
> base/icc34.h
> base/ijs.mak
> base/instcopy
> base/jbig2.mak
> base/jerror_.h
> base/jmemcust.c
> base/jmemcust.h
> base/jpeg.mak
> base/jpegxr.mak
> base/lcms2.mak
> base/lcups.mak
> base/lcupsi.mak
> base/ldf_jb2.mak
> base/lib.mak
> base/locale_.h
> base/lwf_jp2.mak
> base/macgenmcpxml.sh
> base/macos-mcp.mak
> base/macos_carbon_d_pre.h
> base/macos_carbon_pre.h
> base/macos_classic_d_pre.h
> base/macosx.mak
> base/macsystypes.h
> base/malloc_.h
> base/math_.h
> base/md5main.c
> base/memento.c
> base/memento.h
> base/memory_.h
> base/mkromfs.c
> base/msvccmd.mak
> base/msvclib.mak
> base/msvctail.mak
> base/mv.bat
> base/mv.cmd
> base/openjpeg.mak
> base/openvms.mak
> base/openvms.mmk
> base/pcwin.mak
> base/pipe_.h
> base/png.mak
> base/png_.h
> base/ramfs.c
> base/ramfs.h
> base/rm.bat
> base/rm.cmd
> base/rm_all.com
> base/rm_one.com
> base/sa85d.c
> base/sa85d.h
> base/sa85x.h
> base/saes.c
> base/saes.h
> base/sarc4.c
> base/sarc4.h
> base/sbcp.c
> base/sbcp.h
> base/sbtx.h
> base/scanchar.h
> base/scantab.c
> base/scf.h
> base/scfd.c
> base/scfdgen.c
> base/scfdtab.c
> base/scfe.c
> base/scfetab.c
> base/scfparam.c
> base/scfx.h
> base/scommon.h
> base/sdcparam.c
> base/sdcparam.h
> base/sdct.h
> base/sdctc.c
> base/sdctd.c
> base/sdcte.c
> base/sddparam.c
> base/sdeparam.c
> base/seexec.c
> base/setjmp_.h
> base/sfilter.h
> base/sfilter2.c
> base/sfxboth.c
> base/sfxcommon.c
> base/sfxfd.c
> base/sfxstdio.c
> base/sha2.c
> base/sha2.h
> base/shc.c
> base/shc.h
> base/sidscale.c
> base/sidscale.h
> base/siinterp.c
> base/siinterp.h
> base/simscale.c
> base/simscale.h
> base/siscale.c
> base/siscale.h
> base/sisparam.h
> base/sjbig2.c
> base/sjbig2.h
> base/sjbig2_luratech.c
> base/sjbig2_luratech.h
> base/sjpeg.h
> base/sjpegc.c
> base/sjpegd.c
> base/sjpege.c
> base/sjpx_luratech.c
> base/sjpx_luratech.h
> base/sjpx_openjpeg.c
> base/sjpx_openjpeg.h
> base/slzwc.c
> base/slzwd.c
> base/slzwe.c
> base/slzwx.h
> base/smd5.c
> base/smd5.h
> base/smtf.c
> base/smtf.h
> base/spdiff.c
> base/spdiffx.h
> base/spngp.c
> base/spngpx.h
> base/spprint.c
> base/spprint.h
> base/spsdf.c
> base/spsdf.h
> base/srdline.h
> base/srld.c
> base/srle.c
> base/srlx.h
> base/ssha2.c
> base/ssha2.h
> base/sstring.c
> base/sstring.h
> base/stat_.h
> base/std.h
> base/stdint_.h
> base/stdio_.h
> base/stdpn.h
> base/stdpre.h
> base/stream.c
> base/stream.h
> base/strimpl.h
> base/string_.h
> base/strmio.c
> base/strmio.h
> base/stub.mak
> base/szlibc.c
> base/szlibd.c
> base/szlibe.c
> base/szlibx.h
> base/szlibxx.h
> base/tiff.mak
> base/time_.h
> base/ttcalc.c
> base/ttcalc.h
> base/ttcommon.h
> base/ttconf.h
> base/ttconfig.h
> base/ttfinp.c
> base/ttfinp.h
> base/ttfmain.c
> base/ttfmemd.c
> base/ttfmemd.h
> base/ttfoutl.h
> base/ttfsfnt.h
> base/ttinterp.c
> base/ttinterp.h
> base/ttload.c
> base/ttload.h
> base/ttmisc.h
> base/ttobjs.c
> base/ttobjs.h
> base/tttables.h
> base/tttype.h
> base/tttypes.h
> base/ugcclib.mak
> base/unistd_.h
> base/unix-aux.mak
> base/unix-dll.mak
> base/unix-end.mak
> base/unix-gcc.mak
> base/unixansi.mak
> base/unixhead.mak
> base/unixinst.mak
> base/unixlink.mak
> base/valgrind.h
> base/vdtrace.c
> base/vdtrace.h
> base/version.mak
> base/vms_x_fix.h
> base/vmsmath.h
> base/windows_.h
> base/winlib.mak
> base/winplat.mak
> base/winrtsup.cpp
> base/winrtsup.h
> base/wrfont.c
> base/wrfont.h
> base/write_t1.c
> base/write_t1.h
> base/write_t2.c
> base/write_t2.h
> base/x_.h
> base/xpsprint.cpp
> base/zlib.mak
> common/cp.bat
> common/gccdefs.mak
> common/generic.mak
> common/msvc_top.mak
> common/msvcdefs.mak
> common/mv.bat
> common/pcdefs.mak
> common/rm.bat
> common/sgidefs.mak
> common/ugcc_top.mak
> common/unixdefs.mak
> config.mak.in
> configure.ac
> contrib/chp2200/AUTHORS
> contrib/chp2200/COPYING
> contrib/chp2200/INSTALL
> contrib/contrib.mak
> contrib/defs.h
> contrib/eplaser/gdevescv.c
> contrib/eplaser/gdevescv.h
> contrib/epson740/README
> contrib/epson740/printerdb_rh5.2
> contrib/epson740/printerdb_rh6.0
> contrib/epson740/ps-to-printer.fpi_rh5.2
> contrib/epson740/upp-HowTo-to-be
> contrib/gdevbjc_.c
> contrib/gdevbjc_.h
> contrib/gdevbjca.c
> contrib/gdevcd8.c
> contrib/gdevcd8.h
> contrib/gdevdj9.c
> contrib/gdevgdi.c
> contrib/gdevhl12.c
> contrib/gdevln03.c
> contrib/gdevlx32.c
> contrib/gdevlx7.c
> contrib/gdevmd2k.c
> contrib/gdevop4w.c
> contrib/gdevxes.c
> contrib/gomni.c
> contrib/japanese/dmp_init.ps
> contrib/japanese/dmp_site.ps
> contrib/japanese/doc/Gdevlips.htm
> contrib/japanese/doc/README.gs550j
> contrib/japanese/doc/cdj880.txt
> contrib/japanese/doc/dj505j.txt
> contrib/japanese/doc/djgpp.txt
> contrib/japanese/doc/gdev10v.txt
> contrib/japanese/doc/gdevalps.txt
> contrib/japanese/doc/gdevcd8.txt
> contrib/japanese/doc/gdevdmpr.txt
> contrib/japanese/doc/gdevfmlbp.txt
> contrib/japanese/doc/gdevj100.txt
> contrib/japanese/doc/gdevlbp3.txt
> contrib/japanese/doc/gdevmag.txt
> contrib/japanese/doc/gdevmd2k.txt
> contrib/japanese/doc/gdevmjc.txt
> contrib/japanese/doc/gdevml6.txt
> contrib/japanese/doc/gdevp201.txt
> contrib/japanese/doc/gs261j.euc
> contrib/japanese/doc/gs261j.txt
> contrib/japanese/dviprlib.c
> contrib/japanese/dviprlib.h
> contrib/japanese/escp_24.src
> contrib/japanese/gdev10v.c
> contrib/japanese/gdevalps.c
> contrib/japanese/gdevdmpr.c
> contrib/japanese/gdevespg.c
> contrib/japanese/gdevfmlbp.c
> contrib/japanese/gdevfmpr.c
> contrib/japanese/gdevj100.c
> contrib/japanese/gdevlbp3.c
> contrib/japanese/gdevmag.c
> contrib/japanese/gdevmjc.c
> contrib/japanese/gdevmjc.h
> contrib/japanese/gdevml6.c
> contrib/japanese/gdevnpdl.c
> contrib/japanese/gdevp201.c
> contrib/japanese/gdevrpdl.c
> contrib/lips4/gdevl4r.c
> contrib/lips4/gdevl4v.c
> contrib/lips4/gdevlips.c
> contrib/lips4/gdevlips.h
> contrib/lips4/gdevlprn.c
> contrib/lips4/gdevlprn.h
> contrib/lxm3200-tweaked/LICENSE
> contrib/lxm3200-tweaked/README
> contrib/lxm3200-tweaked/RELEASE_NOTES
> contrib/lxm3200-tweaked/Z12-Z31-QuickSetup
> contrib/md2k_md5k/README.jis
> contrib/opvp/gdevopvp.c
> contrib/opvp/opvp.h
> contrib/opvp/opvp_0_2_0.h
> contrib/opvp/opvp_common.h
> contrib/opvp/opvp_media.def
> contrib/pcl3/BUGS
> contrib/pcl3/LGPL
> contrib/pcl3/NEWS
> contrib/pcl3/README
> contrib/pcl3/doc/gs-mods.txt
> contrib/pcl3/doc/gs-pcl3.1
> contrib/pcl3/doc/gs-pcl3.html
> contrib/pcl3/doc/gs-pcl3.ref
> contrib/pcl3/doc/how-to-report.txt
> contrib/pcl3/doc/notes.bbl
> contrib/pcl3/doc/notes.tex
> contrib/pcl3/doc/pcl3opts.1
> contrib/pcl3/doc/pcl3opts.html
> contrib/pcl3/doc/pcl3opts.ref
> contrib/pcl3/doc/reports.txt
> contrib/pcl3/eprn/eprnfs.c
> contrib/pcl3/eprn/eprnparm.c
> contrib/pcl3/eprn/eprnrend.c
> contrib/pcl3/eprn/gdeveprn.c
> contrib/pcl3/eprn/gdeveprn.h
> contrib/pcl3/eprn/mediasize.c
> contrib/pcl3/eprn/mediasize.h
> contrib/pcl3/eprn/pagecount.c
> contrib/pcl3/eprn/pagecount.h
> contrib/pcl3/lib/cups-pcl3
> contrib/pcl3/lib/example.mcf
> contrib/pcl3/lib/if-pcl3
> contrib/pcl3/pcl3.tar.sig
> contrib/pcl3/ppd/README
> contrib/pcl3/ppd/catppd
> contrib/pcl3/ppd/fonts.ppd
> contrib/pcl3/ppd/gs-5.50.ppd
> contrib/pcl3/ppd/gs-6.01.ppd
> contrib/pcl3/ppd/gs-6.50.ppd
> contrib/pcl3/ppd/gs-6.51.ppd
> contrib/pcl3/ppd/gs-7.00.ppd
> contrib/pcl3/ppd/gs-common.ppd
> contrib/pcl3/ppd/gs-pcl3-common.ppd
> contrib/pcl3/ppd/gs-pcl3-hpdj1120c.ppd
> contrib/pcl3/ppd/gs-pcl3-hpdj3xx.ppd
> contrib/pcl3/ppd/gs-pcl3-hpdj400.ppd
> contrib/pcl3/ppd/gs-pcl3-hpdj500.ppd
> contrib/pcl3/ppd/gs-pcl3-hpdj500c.ppd
> contrib/pcl3/ppd/gs-pcl3-hpdj510.ppd
> contrib/pcl3/ppd/gs-pcl3-hpdj540.ppd
> contrib/pcl3/ppd/gs-pcl3-hpdj550c.ppd
> contrib/pcl3/ppd/gs-pcl3-hpdj600.ppd
> contrib/pcl3/ppd/gs-pcl3-hpdj660c.ppd
> contrib/pcl3/ppd/gs-pcl3-hpdj680c.ppd
> contrib/pcl3/ppd/gs-pcl3-hpdj8xxc.ppd
> contrib/pcl3/ppd/gs-pcl3-hpdjportable.ppd
> contrib/pcl3/ppd/gs-pcl3-unspec.ppd
> contrib/pcl3/ppd/gs-pcl3-unspecold.ppd
> contrib/pcl3/ps/calign.ps
> contrib/pcl3/ps/dumppdd.ps
> contrib/pcl3/ps/levels-test.ps
> contrib/pcl3/ps/margins-A4.ps
> contrib/pcl3/ps/margins-A4Rotated.ps
> contrib/pcl3/ps/margins-Env10Rotated.ps
> contrib/pcl3/ps/margins-EnvDLRotated.ps
> contrib/pcl3/ps/margins-Letter.ps
> contrib/pcl3/ps/margins-LetterRotated.ps
> contrib/pcl3/src/contrib.mak-5.50.add
> contrib/pcl3/src/contrib.mak-6.01.add
> contrib/pcl3/src/contrib.mak-6.50.add
> contrib/pcl3/src/contrib.mak-6.51.add
> contrib/pcl3/src/contrib.mak-7.00.add
> contrib/pcl3/src/gdevpcl3.c
> contrib/pcl3/src/pcl3opts-de.msg
> contrib/pcl3/src/pcl3opts-en.msg
> contrib/pcl3/src/pcl3opts.c
> contrib/pcl3/src/pclcap.c
> contrib/pcl3/src/pclcap.h
> contrib/pcl3/src/pclcomp.c
> contrib/pcl3/src/pclgen.c
> contrib/pcl3/src/pclgen.h
> contrib/pcl3/src/pclscan.c
> contrib/pcl3/src/pclscan.h
> contrib/pcl3/src/pclsize.c
> contrib/pcl3/src/pclsize.h
> contrib/pcl3/src/zmedia2.c-5.50.diff
> contrib/pcl3/src/zmedia2.c-6.01.diff
> contrib/pcl3/src/zmedia2.c-6.50.diff
> contrib/pcl3/src/zmedia2.c-6.51.diff
> contrib/pcl3/src/zmedia2.c-7.00.diff
> contrib/pscolor/Makefile
> contrib/pscolor/black.pdf
> contrib/pscolor/black.ps
> contrib/pscolor/color.pdf
> contrib/pscolor/color.ps
> contrib/pscolor/colorsplit.vcproj
> contrib/pscolor/common.mak
> contrib/pscolor/input.ps
> contrib/pscolor/instream.yy
> contrib/pscolor/test.c
> contrib/pscolor/windows.mak
> contrib/uniprint/PM760p.upp
> contrib/uniprint/PM760pl.upp
> contrib/uniprint/PM820p.upp
> contrib/uniprint/PM820pl.upp
> contrib/uniprint/Stc670p.upp
> contrib/uniprint/Stc670pl.upp
> contrib/uniprint/Stc680p.upp
> contrib/uniprint/Stc680pl.upp
> contrib/uniprint/Stc740p.upp
> contrib/uniprint/Stc740pl.upp
> contrib/uniprint/Stc760p.upp
> contrib/uniprint/Stc760pl.upp
> contrib/uniprint/Stc777p.upp
> contrib/uniprint/Stc777pl.upp
> contrib/uniprint/Stp720p.upp
> contrib/uniprint/Stp720pl.upp
> contrib/uniprint/Stp870p.upp
> contrib/uniprint/Stp870pl.upp
> contrib/uniprint/bjc6000a1.upp
> contrib/uniprint/bjc6000b1.upp
> contrib/uniprint/s400a1.upp
> contrib/uniprint/s400b1.upp
> contrib/uniprint/sharp.upp
> contrib/uniprint/sipixa6.upp
> contrib/uniprint/stc740ih.upp
> cups/cups.mak
> cups/gdevcups.c
> cups/libs/Makedefs
> cups/libs/configlinux.h
> cups/libs/configwin.h
> cups/libs/cups/Dependencies
> cups/libs/cups/Makefile
> cups/libs/cups/adminutil.c
> cups/libs/cups/adminutil.h
> cups/libs/cups/api-array.header
> cups/libs/cups/api-array.shtml
> cups/libs/cups/api-cups.header
> cups/libs/cups/api-cups.shtml
> cups/libs/cups/api-filedir.header
> cups/libs/cups/api-filedir.shtml
> cups/libs/cups/api-filter.header
> cups/libs/cups/api-filter.shtml
> cups/libs/cups/api-httpipp.header
> cups/libs/cups/api-httpipp.shtml
> cups/libs/cups/api-overview.header
> cups/libs/cups/api-overview.shtml
> cups/libs/cups/api-ppd.header
> cups/libs/cups/api-ppd.shtml
> cups/libs/cups/array-private.h
> cups/libs/cups/array.c
> cups/libs/cups/array.h
> cups/libs/cups/attr.c
> cups/libs/cups/auth.c
> cups/libs/cups/backchannel.c
> cups/libs/cups/backend.c
> cups/libs/cups/backend.h
> cups/libs/cups/conflicts.c
> cups/libs/cups/cups-private.h
> cups/libs/cups/cups.h
> cups/libs/cups/custom.c
> cups/libs/cups/debug-private.h
> cups/libs/cups/debug.c
> cups/libs/cups/dest-job.c
> cups/libs/cups/dest-localization.c
> cups/libs/cups/dest-options.c
> cups/libs/cups/dest.c
> cups/libs/cups/dir.c
> cups/libs/cups/dir.h
> cups/libs/cups/emit.c
> cups/libs/cups/encode.c
> cups/libs/cups/file-private.h
> cups/libs/cups/file.c
> cups/libs/cups/file.h
> cups/libs/cups/getdevices.c
> cups/libs/cups/getifaddrs.c
> cups/libs/cups/getputfile.c
> cups/libs/cups/globals.c
> cups/libs/cups/http-addr.c
> cups/libs/cups/http-addrlist.c
> cups/libs/cups/http-private.h
> cups/libs/cups/http-support.c
> cups/libs/cups/http.c
> cups/libs/cups/http.h
> cups/libs/cups/ipp-private.h
> cups/libs/cups/ipp-support.c
> cups/libs/cups/ipp.c
> cups/libs/cups/ipp.h
> cups/libs/cups/langprintf.c
> cups/libs/cups/language-private.h
> cups/libs/cups/language.c
> cups/libs/cups/language.h
> cups/libs/cups/libcups2.def
> cups/libs/cups/libcups2.rc
> cups/libs/cups/libcups_s.exp
> cups/libs/cups/localize.c
> cups/libs/cups/mark.c
> cups/libs/cups/md5-private.h
> cups/libs/cups/md5.c
> cups/libs/cups/md5passwd.c
> cups/libs/cups/notify.c
> cups/libs/cups/options.c
> cups/libs/cups/page.c
> cups/libs/cups/ppd-cache.c
> cups/libs/cups/ppd-private.h
> cups/libs/cups/ppd.c
> cups/libs/cups/ppd.h
> cups/libs/cups/pwg-media.c
> cups/libs/cups/pwg-private.h
> cups/libs/cups/pwg.h
> cups/libs/cups/raster-private.h
> cups/libs/cups/raster.h
> cups/libs/cups/request.c
> cups/libs/cups/sidechannel.c
> cups/libs/cups/sidechannel.h
> cups/libs/cups/snmp-private.h
> cups/libs/cups/snmp.c
> cups/libs/cups/snprintf.c
> cups/libs/cups/sspi-private.h
> cups/libs/cups/sspi.c
> cups/libs/cups/string-private.h
> cups/libs/cups/string.c
> cups/libs/cups/tempfile.c
> cups/libs/cups/test.ppd
> cups/libs/cups/test2.ppd
> cups/libs/cups/testadmin.c
> cups/libs/cups/testarray.c
> cups/libs/cups/testconflicts.c
> cups/libs/cups/testcups.c
> cups/libs/cups/testfile.c
> cups/libs/cups/testhttp.c
> cups/libs/cups/testi18n.c
> cups/libs/cups/testipp.c
> cups/libs/cups/testlang.c
> cups/libs/cups/testoptions.c
> cups/libs/cups/testppd.c
> cups/libs/cups/testpwg.c
> cups/libs/cups/testsnmp.c
> cups/libs/cups/thread-private.h
> cups/libs/cups/thread.c
> cups/libs/cups/transcode.c
> cups/libs/cups/transcode.h
> cups/libs/cups/usersys.c
> cups/libs/cups/utf8demo.txt
> cups/libs/cups/util.c
> cups/libs/cups/versioning.h
> cups/libs/filter/Dependencies
> cups/libs/filter/Makefile
> cups/libs/filter/api-raster.header
> cups/libs/filter/api-raster.shtml
> cups/libs/filter/commandtops.c
> cups/libs/filter/common.c
> cups/libs/filter/common.h
> cups/libs/filter/error.c
> cups/libs/filter/gziptoany.c
> cups/libs/filter/interpret.c
> cups/libs/filter/libcupsimage2.def
> cups/libs/filter/libcupsimage_s.exp
> cups/libs/filter/postscript-driver.header
> cups/libs/filter/postscript-driver.shtml
> cups/libs/filter/ppd-compiler.header
> cups/libs/filter/ppd-compiler.shtml
> cups/libs/filter/pstops.c
> cups/libs/filter/raster-driver.header
> cups/libs/filter/raster-driver.shtml
> cups/libs/filter/raster.c
> cups/libs/filter/rasterbench.c
> cups/libs/filter/rastertoepson.c
> cups/libs/filter/rastertohp.c
> cups/libs/filter/rastertolabel.c
> cups/libs/filter/rastertopwg.c
> cups/libs/filter/spec-ppd.header
> cups/libs/filter/spec-ppd.shtml
> cups/libs/filter/testraster.c
> devices/contrib.mak
> devices/devs.mak
> devices/gdev3852.c
> devices/gdev3b1.c
> devices/gdev4081.c
> devices/gdev4693.c
> devices/gdev8510.c
> devices/gdev8bcm.c
> devices/gdev8bcm.h
> devices/gdevadmp.c
> devices/gdevatx.c
> devices/gdevbit.c
> devices/gdevbj10.c
> devices/gdevbjc.h
> devices/gdevbjcl.c
> devices/gdevbjcl.h
> devices/gdevbmp.c
> devices/gdevbmp.h
> devices/gdevbmpa.c
> devices/gdevbmpc.c
> devices/gdevccr.c
> devices/gdevcdj.c
> devices/gdevcfax.c
> devices/gdevcif.c
> devices/gdevclj.c
> devices/gdevcljc.c
> devices/gdevcmykog.c
> devices/gdevcp50.c
> devices/gdevcslw.c
> devices/gdevdfax.c
> devices/gdevdjet.c
> devices/gdevdjtc.c
> devices/gdevdljm.c
> devices/gdevdljm.h
> devices/gdevdm24.c
> devices/gdevdsp.c
> devices/gdevdsp.h
> devices/gdevdsp2.h
> devices/gdevepsc.c
> devices/gdevepsn.c
> devices/gdevescp.c
> devices/gdevevga.c
> devices/gdevfax.c
> devices/gdevfax.h
> devices/gdevfpng.c
> devices/gdevherc.c
> devices/gdevhl7x.c
> devices/gdevicov.c
> devices/gdevifno.c
> devices/gdevijs.c
> devices/gdevimgn.c
> devices/gdevjbig2.c
> devices/gdevjpeg.c
> devices/gdevjpx.c
> devices/gdevl256.c
> devices/gdevl31s.c
> devices/gdevlbp8.c
> devices/gdevlj56.c
> devices/gdevlp8k.c
> devices/gdevlxm.c
> devices/gdevmac.c
> devices/gdevmac.h
> devices/gdevmacpictop.h
> devices/gdevmacttf.h
> devices/gdevmeds.c
> devices/gdevmeds.h
> devices/gdevmgr.c
> devices/gdevmgr.h
> devices/gdevmiff.c
> devices/gdevmswn.c
> devices/gdevmswn.h
> devices/gdevmsxf.c
> devices/gdevn533.c
> devices/gdevo182.c
> devices/gdevokii.c
> devices/gdevos2p.c
> devices/gdevp2up.c
> devices/gdevpbm.c
> devices/gdevpcfb.c
> devices/gdevpcfb.h
> devices/gdevpcl.c
> devices/gdevpcl.h
> devices/gdevpcx.c
> devices/gdevpe.c
> devices/gdevperm.c
> devices/gdevphex.c
> devices/gdevpjet.c
> devices/gdevplan.c
> devices/gdevplib.c
> devices/gdevplib.h
> devices/gdevpm.h
> devices/gdevpng.c
> devices/gdevpsd.c
> devices/gdevpsim.c
> devices/gdevpxut.c
> devices/gdevpxut.h
> devices/gdevrinkj.c
> devices/gdevs3ga.c
> devices/gdevsco.c
> devices/gdevsgi.c
> devices/gdevsgi.h
> devices/gdevsj48.c
> devices/gdevsnfb.c
> devices/gdevsppr.c
> devices/gdevstc.c
> devices/gdevstc.h
> devices/gdevstc1.c
> devices/gdevstc2.c
> devices/gdevstc3.c
> devices/gdevstc4.c
> devices/gdevsun.c
> devices/gdevsunr.c
> devices/gdevsvga.c
> devices/gdevsvga.h
> devices/gdevtfax.c
> devices/gdevtfax.h
> devices/gdevtfnx.c
> devices/gdevtifs.c
> devices/gdevtifs.h
> devices/gdevtknk.c
> devices/gdevtrac.c
> devices/gdevtsep.c
> devices/gdevupd.c
> devices/gdevvglb.c
> devices/gdevwddb.c
> devices/gdevwdib.c
> devices/gdevwpr2.c
> devices/gdevwprn.c
> devices/gdevx.c
> devices/gdevx.h
> devices/gdevxalt.c
> devices/gdevxcf.c
> devices/gdevxcmp.c
> devices/gdevxcmp.h
> devices/gdevxini.c
> devices/gdevxres.c
> devices/gxfcopy.c
> devices/gxfcopy.h
> devices/minftrsz.c
> devices/minftrsz.h
> devices/rinkj/evenbetter-rll.c
> devices/rinkj/evenbetter-rll.h
> devices/rinkj/rinkj-byte-stream.c
> devices/rinkj/rinkj-byte-stream.h
> devices/rinkj/rinkj-config.c
> devices/rinkj/rinkj-config.h
> devices/rinkj/rinkj-device.c
> devices/rinkj/rinkj-device.h
> devices/rinkj/rinkj-dither.c
> devices/rinkj/rinkj-dither.h
> devices/rinkj/rinkj-epson870.c
> devices/rinkj/rinkj-epson870.h
> devices/rinkj/rinkj-screen-eb.c
> devices/rinkj/rinkj-screen-eb.h
> devices/vector/gdevagl.c
> devices/vector/gdevagl.h
> devices/vector/gdevpdf.c
> devices/vector/gdevpdfb.c
> devices/vector/gdevpdfb.h
> devices/vector/gdevpdfc.c
> devices/vector/gdevpdfc.h
> devices/vector/gdevpdfd.c
> devices/vector/gdevpdfe.c
> devices/vector/gdevpdfg.c
> devices/vector/gdevpdfg.h
> devices/vector/gdevpdfi.c
> devices/vector/gdevpdfj.c
> devices/vector/gdevpdfk.c
> devices/vector/gdevpdfm.c
> devices/vector/gdevpdfo.c
> devices/vector/gdevpdfo.h
> devices/vector/gdevpdfp.c
> devices/vector/gdevpdfr.c
> devices/vector/gdevpdft.c
> devices/vector/gdevpdfu.c
> devices/vector/gdevpdfv.c
> devices/vector/gdevpdfx.h
> devices/vector/gdevpdt.c
> devices/vector/gdevpdt.h
> devices/vector/gdevpdtb.c
> devices/vector/gdevpdtb.h
> devices/vector/gdevpdtc.c
> devices/vector/gdevpdtd.c
> devices/vector/gdevpdtd.h
> devices/vector/gdevpdte.c
> devices/vector/gdevpdtf.c
> devices/vector/gdevpdtf.h
> devices/vector/gdevpdti.c
> devices/vector/gdevpdti.h
> devices/vector/gdevpdts.c
> devices/vector/gdevpdts.h
> devices/vector/gdevpdtt.c
> devices/vector/gdevpdtt.h
> devices/vector/gdevpdtv.c
> devices/vector/gdevpdtv.h
> devices/vector/gdevpdtw.c
> devices/vector/gdevpdtw.h
> devices/vector/gdevpdtx.h
> devices/vector/gdevpsdf.h
> devices/vector/gdevpsdi.c
> devices/vector/gdevpsdp.c
> devices/vector/gdevpsds.c
> devices/vector/gdevpsds.h
> devices/vector/gdevpsdu.c
> devices/vector/gdevpsf.h
> devices/vector/gdevpsf1.c
> devices/vector/gdevpsf2.c
> devices/vector/gdevpsfm.c
> devices/vector/gdevpsft.c
> devices/vector/gdevpsfu.c
> devices/vector/gdevpsfx.c
> devices/vector/gdevpsu.c
> devices/vector/gdevpsu.h
> devices/vector/gdevpx.c
> devices/vector/gdevtxtw.c
> devices/vector/gdevxps.c
> devices/vector/opdfread.h
> devices/vector/whitelst.c
> devices/vector/whitelst.h
> doc/API.htm
> doc/AUTHORS
> doc/C-style.htm
> doc/COPYING
> doc/Changes.htm
> doc/Commprod.htm
> doc/DLL.htm
> doc/Deprecated.htm
> doc/Details.htm
> doc/Details8.htm
> doc/Details9.htm
> doc/Develop.htm
> doc/Devices.htm
> doc/Drivers.htm
> doc/Fonts.htm
> doc/GS9_Color_Management.pdf
> doc/GS9_Color_Management.tex
> doc/Helpers.htm
> doc/Hershey.htm
> doc/History1.htm
> doc/History2.htm
> doc/History3.htm
> doc/History4.htm
> doc/History5.htm
> doc/History6.htm
> doc/History7.htm
> doc/History8.htm
> doc/History9.htm
> doc/Install.htm
> doc/Issues.htm
> doc/Language.htm
> doc/Lib.htm
> doc/Make.htm
> doc/Makefile
> doc/News.htm
> doc/Projects.htm
> doc/Ps-style.htm
> doc/Ps2epsi.htm
> doc/Ps2pdf.htm
> doc/Ps2ps2.htm
> doc/Psfiles.htm
> doc/README
> doc/Readme.htm
> doc/Release.htm
> doc/SavedPages.htm
> doc/Source.htm
> doc/Unix-lpr.htm
> doc/Use.htm
> doc/WhatIsGS.htm
> doc/Xfonts.htm
> doc/ghostpdl.pdf
> doc/ghostpdl.tex
> doc/ghostpdl.txt
> doc/gs-vms.hlp
> doc/gs.css
> doc/gsdoc.el
> doc/index.html
> doc/pclxps/Makefile
> doc/pclxps/README
> doc/pclxps/ghostpdl.pdf
> doc/pclxps/ghostpdl.tex
> doc/pclxps/ghostpdl.txt
> doc/pscet_status.txt
> doc/subclass.htm
> doc/thirdparty.htm
> examples/alphabet.ps
> examples/annots.pdf
> examples/chess.ps
> examples/cjk/all_ac1.ps
> examples/cjk/all_ag1.ps
> examples/cjk/all_aj1.ps
> examples/cjk/all_aj2.ps
> examples/cjk/all_ak1.ps
> examples/cjk/article9.ps
> examples/cjk/gscjk_ac.ps
> examples/cjk/gscjk_ag.ps
> examples/cjk/gscjk_aj.ps
> examples/cjk/gscjk_ak.ps
> examples/cjk/iso2022.ps
> examples/cjk/iso2022v.ps
> examples/colorcir.ps
> examples/doretree.ps
> examples/escher.ps
> examples/golfer.eps
> examples/grayalph.ps
> examples/ridt91.eps
> examples/snowflak.ps
> examples/text_graph_image_cmyk_rgb.pdf
> examples/text_graphic_image.pdf
> examples/tiger.eps
> examples/transparency_example.ps
> examples/vasarely.ps
> examples/waterfal.ps
> expat/COPYING
> expat/Changes
> expat/MANIFEST
> expat/Makefile.in
> expat/README
> expat/amiga/Makefile
> expat/amiga/README.txt
> expat/amiga/expat.xml
> expat/amiga/expat_lib.c
> expat/amiga/expat_vectors.c
> expat/amiga/include/inline4/expat.h
> expat/amiga/include/interfaces/expat.h
> expat/amiga/include/libraries/expat.h
> expat/amiga/include/proto/expat.h
> expat/amiga/launch.c
> expat/amiga/stdlib.c
> expat/bcb5/README.txt
> expat/bcb5/all_projects.bpg
> expat/bcb5/elements.bpf
> expat/bcb5/elements.bpr
> expat/bcb5/elements.mak
> expat/bcb5/expat.bpf
> expat/bcb5/expat.bpr
> expat/bcb5/expat.mak
> expat/bcb5/expat_static.bpf
> expat/bcb5/expat_static.bpr
> expat/bcb5/expat_static.mak
> expat/bcb5/expatw.bpf
> expat/bcb5/expatw.bpr
> expat/bcb5/expatw.mak
> expat/bcb5/expatw_static.bpf
> expat/bcb5/expatw_static.bpr
> expat/bcb5/expatw_static.mak
> expat/bcb5/libexpat_mtd.def
> expat/bcb5/libexpatw_mtd.def
> expat/bcb5/makefile.mak
> expat/bcb5/outline.bpf
> expat/bcb5/outline.bpr
> expat/bcb5/outline.mak
> expat/bcb5/setup.bat
> expat/bcb5/xmlwf.bpf
> expat/bcb5/xmlwf.bpr
> expat/bcb5/xmlwf.mak
> expat/configure
> expat/configure.in
> expat/conftools/PrintPath
> expat/conftools/ac_c_bigendian_cross.m4
> expat/conftools/config.guess
> expat/conftools/config.sub
> expat/conftools/expat.m4
> expat/conftools/get-version.sh
> expat/conftools/install-sh
> expat/conftools/libtool.m4
> expat/conftools/ltmain.sh
> expat/conftools/mkinstalldirs
> expat/doc/expat.png
> expat/doc/reference.html
> expat/doc/style.css
> expat/doc/valid-xhtml10.png
> expat/doc/xmlwf.1
> expat/doc/xmlwf.sgml
> expat/examples/elements.c
> expat/examples/elements.dsp
> expat/examples/outline.c
> expat/examples/outline.dsp
> expat/expat.dsw
> expat/expat_config.h.in
> expat/lib/Makefile.MPW
> expat/lib/amigaconfig.h
> expat/lib/ascii.h
> expat/lib/asciitab.h
> expat/lib/expat.dsp
> expat/lib/expat.h
> expat/lib/expat_external.h
> expat/lib/expat_static.dsp
> expat/lib/expatw.dsp
> expat/lib/expatw_static.dsp
> expat/lib/iasciitab.h
> expat/lib/internal.h
> expat/lib/latin1tab.h
> expat/lib/libexpat.def
> expat/lib/libexpatw.def
> expat/lib/macconfig.h
> expat/lib/nametab.h
> expat/lib/utf8tab.h
> expat/lib/winconfig.h
> expat/lib/xmlparse.c
> expat/lib/xmlrole.c
> expat/lib/xmlrole.h
> expat/lib/xmltok.c
> expat/lib/xmltok.h
> expat/lib/xmltok_impl.c
> expat/lib/xmltok_impl.h
> expat/lib/xmltok_ns.c
> expat/tests/README.txt
> expat/tests/benchmark/README.txt
> expat/tests/benchmark/benchmark.c
> expat/tests/benchmark/benchmark.dsp
> expat/tests/benchmark/benchmark.dsw
> expat/tests/chardata.c
> expat/tests/chardata.h
> expat/tests/minicheck.c
> expat/tests/minicheck.h
> expat/tests/runtests.c
> expat/tests/runtestspp.cpp
> expat/tests/xmltest.sh
> expat/vms/README.vms
> expat/vms/descrip.mms
> expat/vms/expat_config.h
> expat/win32/MANIFEST.txt
> expat/win32/README.txt
> expat/win32/expat.iss
> expat/xmlwf/codepage.c
> expat/xmlwf/codepage.h
> expat/xmlwf/ct.c
> expat/xmlwf/filemap.h
> expat/xmlwf/readfilemap.c
> expat/xmlwf/unixfilemap.c
> expat/xmlwf/win32filemap.c
> expat/xmlwf/xmlfile.c
> expat/xmlwf/xmlfile.h
> expat/xmlwf/xmlmime.c
> expat/xmlwf/xmlmime.h
> expat/xmlwf/xmltchar.h
> expat/xmlwf/xmlurl.h
> expat/xmlwf/xmlwf.c
> expat/xmlwf/xmlwf.dsp
> expat/xmlwf/xmlwin32url.cxx
> freetype/CMakeLists.txt
> freetype/ChangeLog
> freetype/ChangeLog.20
> freetype/ChangeLog.21
> freetype/ChangeLog.22
> freetype/ChangeLog.23
> freetype/ChangeLog.24
> freetype/Jamfile
> freetype/Jamrules
> freetype/Makefile
> freetype/README
> freetype/README.git
> freetype/autogen.sh
> freetype/builds/amiga/README
> freetype/builds/amiga/include/config/ftconfig.h
> freetype/builds/amiga/include/config/ftmodule.h
> freetype/builds/amiga/makefile
> freetype/builds/amiga/makefile.os4
> freetype/builds/amiga/smakefile
> freetype/builds/amiga/src/base/ftdebug.c
> freetype/builds/amiga/src/base/ftsystem.c
> freetype/builds/ansi/ansi-def.mk
> freetype/builds/ansi/ansi.mk
> freetype/builds/atari/ATARI.H
> freetype/builds/atari/FNames.SIC
> freetype/builds/atari/FREETYPE.PRJ
> freetype/builds/atari/README.TXT
> freetype/builds/atari/deflinejoiner.awk
> freetype/builds/atari/gen-purec-patch.sh
> freetype/builds/beos/beos-def.mk
> freetype/builds/beos/beos.mk
> freetype/builds/beos/detect.mk
> freetype/builds/cmake/iOS.cmake
> freetype/builds/compiler/ansi-cc.mk
> freetype/builds/compiler/bcc-dev.mk
> freetype/builds/compiler/bcc.mk
> freetype/builds/compiler/emx.mk
> freetype/builds/compiler/gcc-dev.mk
> freetype/builds/compiler/gcc.mk
> freetype/builds/compiler/intelc.mk
> freetype/builds/compiler/unix-lcc.mk
> freetype/builds/compiler/visualage.mk
> freetype/builds/compiler/visualc.mk
> freetype/builds/compiler/watcom.mk
> freetype/builds/compiler/win-lcc.mk
> freetype/builds/detect.mk
> freetype/builds/dos/detect.mk
> freetype/builds/dos/dos-def.mk
> freetype/builds/dos/dos-emx.mk
> freetype/builds/dos/dos-gcc.mk
> freetype/builds/dos/dos-wat.mk
> freetype/builds/exports.mk
> freetype/builds/freetype.mk
> freetype/builds/link_dos.mk
> freetype/builds/link_std.mk
> freetype/builds/mac/FreeType.m68k_cfm.make.txt
> freetype/builds/mac/FreeType.m68k_far.make.txt
> freetype/builds/mac/FreeType.ppc_carbon.make.txt
> freetype/builds/mac/FreeType.ppc_classic.make.txt
> freetype/builds/mac/README
> freetype/builds/mac/ascii2mpw.py
> freetype/builds/mac/freetype-Info.plist
> freetype/builds/mac/ftlib.prj.xml
> freetype/builds/mac/ftmac.c
> freetype/builds/modules.mk
> freetype/builds/newline
> freetype/builds/os2/detect.mk
> freetype/builds/os2/os2-def.mk
> freetype/builds/os2/os2-dev.mk
> freetype/builds/os2/os2-gcc.mk
> freetype/builds/symbian/bld.inf
> freetype/builds/symbian/freetype.mmp
> freetype/builds/toplevel.mk
> freetype/builds/unix/aclocal.m4
> freetype/builds/unix/config.guess
> freetype/builds/unix/config.sub
> freetype/builds/unix/configure.ac
> freetype/builds/unix/configure.raw
> freetype/builds/unix/detect.mk
> freetype/builds/unix/freetype-config.in
> freetype/builds/unix/freetype2.in
> freetype/builds/unix/freetype2.m4
> freetype/builds/unix/ft-munmap.m4
> freetype/builds/unix/ftconfig.in
> freetype/builds/unix/ftsystem.c
> freetype/builds/unix/install-sh
> freetype/builds/unix/install.mk
> freetype/builds/unix/ltmain.sh
> freetype/builds/unix/mkinstalldirs
> freetype/builds/unix/pkg.m4
> freetype/builds/unix/unix-cc.in
> freetype/builds/unix/unix-def.in
> freetype/builds/unix/unix-dev.mk
> freetype/builds/unix/unix-lcc.mk
> freetype/builds/unix/unix.mk
> freetype/builds/unix/unixddef.mk
> freetype/builds/vms/ftconfig.h
> freetype/builds/vms/ftsystem.c
> freetype/builds/wince/ftdebug.c
> freetype/builds/wince/vc2005-ce/freetype.sln
> freetype/builds/wince/vc2005-ce/freetype.vcproj
> freetype/builds/wince/vc2005-ce/index.html
> freetype/builds/wince/vc2008-ce/freetype.sln
> freetype/builds/wince/vc2008-ce/freetype.vcproj
> freetype/builds/wince/vc2008-ce/index.html
> freetype/builds/windows/detect.mk
> freetype/builds/windows/ftdebug.c
> freetype/builds/windows/vc2005/freetype.sln
> freetype/builds/windows/vc2005/freetype.vcproj
> freetype/builds/windows/vc2005/index.html
> freetype/builds/windows/vc2008/freetype.sln
> freetype/builds/windows/vc2008/freetype.vcproj
> freetype/builds/windows/vc2008/index.html
> freetype/builds/windows/vc2010/freetype.sln
> freetype/builds/windows/vc2010/freetype.user.props
> freetype/builds/windows/vc2010/freetype.vcxproj
> freetype/builds/windows/vc2010/freetype.vcxproj.filters
> freetype/builds/windows/vc2010/index.html
> freetype/builds/windows/visualc/freetype.dsp
> freetype/builds/windows/visualc/freetype.dsw
> freetype/builds/windows/visualc/freetype.sln
> freetype/builds/windows/visualc/freetype.vcproj
> freetype/builds/windows/visualc/index.html
> freetype/builds/windows/visualce/freetype.dsp
> freetype/builds/windows/visualce/freetype.dsw
> freetype/builds/windows/visualce/freetype.vcproj
> freetype/builds/windows/visualce/index.html
> freetype/builds/windows/w32-bcc.mk
> freetype/builds/windows/w32-bccd.mk
> freetype/builds/windows/w32-dev.mk
> freetype/builds/windows/w32-gcc.mk
> freetype/builds/windows/w32-icc.mk
> freetype/builds/windows/w32-intl.mk
> freetype/builds/windows/w32-lcc.mk
> freetype/builds/windows/w32-mingw32.mk
> freetype/builds/windows/w32-vcc.mk
> freetype/builds/windows/w32-wat.mk
> freetype/builds/windows/win32-def.mk
> freetype/configure
> freetype/devel/ft2build.h
> freetype/devel/ftoption.h
> freetype/docs/CHANGES
> freetype/docs/CMAKE
> freetype/docs/CUSTOMIZE
> freetype/docs/DEBUG
> freetype/docs/FTL.TXT
> freetype/docs/GPLv2.TXT
> freetype/docs/INSTALL
> freetype/docs/INSTALL.ANY
> freetype/docs/INSTALL.CROSS
> freetype/docs/INSTALL.GNU
> freetype/docs/INSTALL.MAC
> freetype/docs/INSTALL.UNIX
> freetype/docs/INSTALL.VMS
> freetype/docs/LICENSE.TXT
> freetype/docs/MAKEPP
> freetype/docs/PROBLEMS
> freetype/docs/TODO
> freetype/docs/VERSION.DLL
> freetype/docs/formats.txt
> freetype/docs/freetype-config.1
> freetype/docs/raster.txt
> freetype/docs/reference/README
> freetype/docs/reference/ft2-auto_hinter.html
> freetype/docs/reference/ft2-base_interface.html
> freetype/docs/reference/ft2-basic_types.html
> freetype/docs/reference/ft2-bdf_fonts.html
> freetype/docs/reference/ft2-bitmap_handling.html
> freetype/docs/reference/ft2-bzip2.html
> freetype/docs/reference/ft2-cache_subsystem.html
> freetype/docs/reference/ft2-cff_driver.html
> freetype/docs/reference/ft2-cid_fonts.html
> freetype/docs/reference/ft2-computations.html
> freetype/docs/reference/ft2-font_formats.html
> freetype/docs/reference/ft2-gasp_table.html
> freetype/docs/reference/ft2-glyph_management.html
> freetype/docs/reference/ft2-glyph_stroker.html
> freetype/docs/reference/ft2-glyph_variants.html
> freetype/docs/reference/ft2-gx_validation.html
> freetype/docs/reference/ft2-gzip.html
> freetype/docs/reference/ft2-header_file_macros.html
> freetype/docs/reference/ft2-header_inclusion.html
> freetype/docs/reference/ft2-incremental.html
> freetype/docs/reference/ft2-index.html
> freetype/docs/reference/ft2-lcd_filtering.html
> freetype/docs/reference/ft2-list_processing.html
> freetype/docs/reference/ft2-lzw.html
> freetype/docs/reference/ft2-mac_specific.html
> freetype/docs/reference/ft2-module_management.html
> freetype/docs/reference/ft2-multiple_masters.html
> freetype/docs/reference/ft2-ot_validation.html
> freetype/docs/reference/ft2-outline_processing.html
> freetype/docs/reference/ft2-pfr_fonts.html
> freetype/docs/reference/ft2-quick_advance.html
> freetype/docs/reference/ft2-raster.html
> freetype/docs/reference/ft2-sfnt_names.html
> freetype/docs/reference/ft2-sizes_management.html
> freetype/docs/reference/ft2-system_interface.html
> freetype/docs/reference/ft2-toc.html
> freetype/docs/reference/ft2-truetype_engine.html
> freetype/docs/reference/ft2-truetype_tables.html
> freetype/docs/reference/ft2-tt_driver.html
> freetype/docs/reference/ft2-type1_tables.html
> freetype/docs/reference/ft2-user_allocation.html
> freetype/docs/reference/ft2-version.html
> freetype/docs/reference/ft2-winfnt_fonts.html
> freetype/docs/release
> freetype/include/config/ftconfig.h
> freetype/include/config/ftheader.h
> freetype/include/config/ftmodule.h
> freetype/include/config/ftoption.h
> freetype/include/config/ftstdlib.h
> freetype/include/freetype.h
> freetype/include/ft2build.h
> freetype/include/ftadvanc.h
> freetype/include/ftautoh.h
> freetype/include/ftbbox.h
> freetype/include/ftbdf.h
> freetype/include/ftbitmap.h
> freetype/include/ftbzip2.h
> freetype/include/ftcache.h
> freetype/include/ftcffdrv.h
> freetype/include/ftchapters.h
> freetype/include/ftcid.h
> freetype/include/fterrdef.h
> freetype/include/fterrors.h
> freetype/include/ftgasp.h
> freetype/include/ftglyph.h
> freetype/include/ftgxval.h
> freetype/include/ftgzip.h
> freetype/include/ftimage.h
> freetype/include/ftincrem.h
> freetype/include/ftlcdfil.h
> freetype/include/ftlist.h
> freetype/include/ftlzw.h
> freetype/include/ftmac.h
> freetype/include/ftmm.h
> freetype/include/ftmodapi.h
> freetype/include/ftmoderr.h
> freetype/include/ftotval.h
> freetype/include/ftoutln.h
> freetype/include/ftpfr.h
> freetype/include/ftrender.h
> freetype/include/ftsizes.h
> freetype/include/ftsnames.h
> freetype/include/ftstroke.h
> freetype/include/ftsynth.h
> freetype/include/ftsystem.h
> freetype/include/fttrigon.h
> freetype/include/ftttdrv.h
> freetype/include/fttypes.h
> freetype/include/ftwinfnt.h
> freetype/include/ftxf86.h
> freetype/include/internal/autohint.h
> freetype/include/internal/ftcalc.h
> freetype/include/internal/ftdebug.h
> freetype/include/internal/ftdriver.h
> freetype/include/internal/ftgloadr.h
> freetype/include/internal/ftmemory.h
> freetype/include/internal/ftobjs.h
> freetype/include/internal/ftpic.h
> freetype/include/internal/ftrfork.h
> freetype/include/internal/ftserv.h
> freetype/include/internal/ftstream.h
> freetype/include/internal/fttrace.h
> freetype/include/internal/ftvalid.h
> freetype/include/internal/internal.h
> freetype/include/internal/psaux.h
> freetype/include/internal/pshints.h
> freetype/include/internal/services/svbdf.h
> freetype/include/internal/services/svcid.h
> freetype/include/internal/services/svgldict.h
> freetype/include/internal/services/svgxval.h
> freetype/include/internal/services/svkern.h
> freetype/include/internal/services/svmm.h
> freetype/include/internal/services/svotval.h
> freetype/include/internal/services/svpfr.h
> freetype/include/internal/services/svpostnm.h
> freetype/include/internal/services/svprop.h
> freetype/include/internal/services/svpscmap.h
> freetype/include/internal/services/svpsinfo.h
> freetype/include/internal/services/svsfnt.h
> freetype/include/internal/services/svttcmap.h
> freetype/include/internal/services/svtteng.h
> freetype/include/internal/services/svttglyf.h
> freetype/include/internal/services/svwinfnt.h
> freetype/include/internal/services/svxf86nm.h
> freetype/include/internal/sfnt.h
> freetype/include/internal/t1types.h
> freetype/include/internal/tttypes.h
> freetype/include/t1tables.h
> freetype/include/ttnameid.h
> freetype/include/tttables.h
> freetype/include/tttags.h
> freetype/include/ttunpat.h
> freetype/modules.cfg
> freetype/objs/README
> freetype/src/Jamfile
> freetype/src/autofit/Jamfile
> freetype/src/autofit/afangles.c
> freetype/src/autofit/afangles.h
> freetype/src/autofit/afblue.c
> freetype/src/autofit/afblue.cin
> freetype/src/autofit/afblue.dat
> freetype/src/autofit/afblue.h
> freetype/src/autofit/afblue.hin
> freetype/src/autofit/afcjk.c
> freetype/src/autofit/afcjk.h
> freetype/src/autofit/afcover.h
> freetype/src/autofit/afdummy.c
> freetype/src/autofit/afdummy.h
> freetype/src/autofit/aferrors.h
> freetype/src/autofit/afglobal.c
> freetype/src/autofit/afglobal.h
> freetype/src/autofit/afhints.c
> freetype/src/autofit/afhints.h
> freetype/src/autofit/afindic.c
> freetype/src/autofit/afindic.h
> freetype/src/autofit/aflatin.c
> freetype/src/autofit/aflatin.h
> freetype/src/autofit/aflatin2.c
> freetype/src/autofit/aflatin2.h
> freetype/src/autofit/afloader.c
> freetype/src/autofit/afloader.h
> freetype/src/autofit/afmodule.c
> freetype/src/autofit/afmodule.h
> freetype/src/autofit/afpic.c
> freetype/src/autofit/afpic.h
> freetype/src/autofit/afranges.c
> freetype/src/autofit/afranges.h
> freetype/src/autofit/afscript.h
> freetype/src/autofit/afstyles.h
> freetype/src/autofit/aftypes.h
> freetype/src/autofit/afwarp.c
> freetype/src/autofit/afwarp.h
> freetype/src/autofit/afwrtsys.h
> freetype/src/autofit/autofit.c
> freetype/src/autofit/hbshim.c
> freetype/src/autofit/hbshim.h
> freetype/src/autofit/module.mk
> freetype/src/autofit/rules.mk
> freetype/src/base/Jamfile
> freetype/src/base/basepic.c
> freetype/src/base/basepic.h
> freetype/src/base/ftadvanc.c
> freetype/src/base/ftapi.c
> freetype/src/base/ftbase.c
> freetype/src/base/ftbase.h
> freetype/src/base/ftbbox.c
> freetype/src/base/ftbdf.c
> freetype/src/base/ftbitmap.c
> freetype/src/base/ftcalc.c
> freetype/src/base/ftcid.c
> freetype/src/base/ftdbgmem.c
> freetype/src/base/ftdebug.c
> freetype/src/base/ftfstype.c
> freetype/src/base/ftgasp.c
> freetype/src/base/ftgloadr.c
> freetype/src/base/ftglyph.c
> freetype/src/base/ftgxval.c
> freetype/src/base/ftinit.c
> freetype/src/base/ftlcdfil.c
> freetype/src/base/ftmac.c
> freetype/src/base/ftmm.c
> freetype/src/base/ftobjs.c
> freetype/src/base/ftotval.c
> freetype/src/base/ftoutln.c
> freetype/src/base/ftpatent.c
> freetype/src/base/ftpfr.c
> freetype/src/base/ftpic.c
> freetype/src/base/ftrfork.c
> freetype/src/base/ftsnames.c
> freetype/src/base/ftstream.c
> freetype/src/base/ftstroke.c
> freetype/src/base/ftsynth.c
> freetype/src/base/ftsystem.c
> freetype/src/base/fttrigon.c
> freetype/src/base/fttype1.c
> freetype/src/base/ftutil.c
> freetype/src/base/ftwinfnt.c
> freetype/src/base/ftxf86.c
> freetype/src/base/md5.c
> freetype/src/base/md5.h
> freetype/src/base/rules.mk
> freetype/src/bdf/Jamfile
> freetype/src/bdf/README
> freetype/src/bdf/bdf.c
> freetype/src/bdf/bdf.h
> freetype/src/bdf/bdfdrivr.c
> freetype/src/bdf/bdfdrivr.h
> freetype/src/bdf/bdferror.h
> freetype/src/bdf/bdflib.c
> freetype/src/bdf/module.mk
> freetype/src/bdf/rules.mk
> freetype/src/bzip2/Jamfile
> freetype/src/bzip2/ftbzip2.c
> freetype/src/bzip2/rules.mk
> freetype/src/cache/Jamfile
> freetype/src/cache/ftcache.c
> freetype/src/cache/ftcbasic.c
> freetype/src/cache/ftccache.c
> freetype/src/cache/ftccache.h
> freetype/src/cache/ftccback.h
> freetype/src/cache/ftccmap.c
> freetype/src/cache/ftcerror.h
> freetype/src/cache/ftcglyph.c
> freetype/src/cache/ftcglyph.h
> freetype/src/cache/ftcimage.c
> freetype/src/cache/ftcimage.h
> freetype/src/cache/ftcmanag.c
> freetype/src/cache/ftcmanag.h
> freetype/src/cache/ftcmru.c
> freetype/src/cache/ftcmru.h
> freetype/src/cache/ftcsbits.c
> freetype/src/cache/ftcsbits.h
> freetype/src/cache/rules.mk
> freetype/src/cff/Jamfile
> freetype/src/cff/cf2arrst.c
> freetype/src/cff/cf2arrst.h
> freetype/src/cff/cf2blues.c
> freetype/src/cff/cf2blues.h
> freetype/src/cff/cf2error.c
> freetype/src/cff/cf2error.h
> freetype/src/cff/cf2fixed.h
> freetype/src/cff/cf2font.c
> freetype/src/cff/cf2font.h
> freetype/src/cff/cf2ft.c
> freetype/src/cff/cf2ft.h
> freetype/src/cff/cf2glue.h
> freetype/src/cff/cf2hints.c
> freetype/src/cff/cf2hints.h
> freetype/src/cff/cf2intrp.c
> freetype/src/cff/cf2intrp.h
> freetype/src/cff/cf2read.c
> freetype/src/cff/cf2read.h
> freetype/src/cff/cf2stack.c
> freetype/src/cff/cf2stack.h
> freetype/src/cff/cf2types.h
> freetype/src/cff/cff.c
> freetype/src/cff/cffcmap.c
> freetype/src/cff/cffcmap.h
> freetype/src/cff/cffdrivr.c
> freetype/src/cff/cffdrivr.h
> freetype/src/cff/cfferrs.h
> freetype/src/cff/cffgload.c
> freetype/src/cff/cffgload.h
> freetype/src/cff/cffload.c
> freetype/src/cff/cffload.h
> freetype/src/cff/cffobjs.c
> freetype/src/cff/cffobjs.h
> freetype/src/cff/cffparse.c
> freetype/src/cff/cffparse.h
> freetype/src/cff/cffpic.c
> freetype/src/cff/cffpic.h
> freetype/src/cff/cfftoken.h
> freetype/src/cff/cfftypes.h
> freetype/src/cff/module.mk
> freetype/src/cff/rules.mk
> freetype/src/cid/Jamfile
> freetype/src/cid/ciderrs.h
> freetype/src/cid/cidgload.c
> freetype/src/cid/cidgload.h
> freetype/src/cid/cidload.c
> freetype/src/cid/cidload.h
> freetype/src/cid/cidobjs.c
> freetype/src/cid/cidobjs.h
> freetype/src/cid/cidparse.c
> freetype/src/cid/cidparse.h
> freetype/src/cid/cidriver.c
> freetype/src/cid/cidriver.h
> freetype/src/cid/cidtoken.h
> freetype/src/cid/module.mk
> freetype/src/cid/rules.mk
> freetype/src/cid/type1cid.c
> freetype/src/gxvalid/Jamfile
> freetype/src/gxvalid/README
> freetype/src/gxvalid/gxvalid.c
> freetype/src/gxvalid/gxvalid.h
> freetype/src/gxvalid/gxvbsln.c
> freetype/src/gxvalid/gxvcommn.c
> freetype/src/gxvalid/gxvcommn.h
> freetype/src/gxvalid/gxverror.h
> freetype/src/gxvalid/gxvfeat.c
> freetype/src/gxvalid/gxvfeat.h
> freetype/src/gxvalid/gxvfgen.c
> freetype/src/gxvalid/gxvjust.c
> freetype/src/gxvalid/gxvkern.c
> freetype/src/gxvalid/gxvlcar.c
> freetype/src/gxvalid/gxvmod.c
> freetype/src/gxvalid/gxvmod.h
> freetype/src/gxvalid/gxvmort.c
> freetype/src/gxvalid/gxvmort.h
> freetype/src/gxvalid/gxvmort0.c
> freetype/src/gxvalid/gxvmort1.c
> freetype/src/gxvalid/gxvmort2.c
> freetype/src/gxvalid/gxvmort4.c
> freetype/src/gxvalid/gxvmort5.c
> freetype/src/gxvalid/gxvmorx.c
> freetype/src/gxvalid/gxvmorx.h
> freetype/src/gxvalid/gxvmorx0.c
> freetype/src/gxvalid/gxvmorx1.c
> freetype/src/gxvalid/gxvmorx2.c
> freetype/src/gxvalid/gxvmorx4.c
> freetype/src/gxvalid/gxvmorx5.c
> freetype/src/gxvalid/gxvopbd.c
> freetype/src/gxvalid/gxvprop.c
> freetype/src/gxvalid/gxvtrak.c
> freetype/src/gxvalid/module.mk
> freetype/src/gxvalid/rules.mk
> freetype/src/gzip/Jamfile
> freetype/src/gzip/adler32.c
> freetype/src/gzip/ftgzip.c
> freetype/src/gzip/infblock.c
> freetype/src/gzip/infblock.h
> freetype/src/gzip/infcodes.c
> freetype/src/gzip/infcodes.h
> freetype/src/gzip/inffixed.h
> freetype/src/gzip/inflate.c
> freetype/src/gzip/inftrees.c
> freetype/src/gzip/inftrees.h
> freetype/src/gzip/infutil.c
> freetype/src/gzip/infutil.h
> freetype/src/gzip/rules.mk
> freetype/src/gzip/zconf.h
> freetype/src/gzip/zlib.h
> freetype/src/gzip/zutil.c
> freetype/src/gzip/zutil.h
> freetype/src/lzw/Jamfile
> freetype/src/lzw/ftlzw.c
> freetype/src/lzw/ftzopen.c
> freetype/src/lzw/ftzopen.h
> freetype/src/lzw/rules.mk
> freetype/src/otvalid/Jamfile
> freetype/src/otvalid/module.mk
> freetype/src/otvalid/otvalid.c
> freetype/src/otvalid/otvalid.h
> freetype/src/otvalid/otvbase.c
> freetype/src/otvalid/otvcommn.c
> freetype/src/otvalid/otvcommn.h
> freetype/src/otvalid/otverror.h
> freetype/src/otvalid/otvgdef.c
> freetype/src/otvalid/otvgpos.c
> freetype/src/otvalid/otvgpos.h
> freetype/src/otvalid/otvgsub.c
> freetype/src/otvalid/otvjstf.c
> freetype/src/otvalid/otvmath.c
> freetype/src/otvalid/otvmod.c
> freetype/src/otvalid/otvmod.h
> freetype/src/otvalid/rules.mk
> freetype/src/pcf/Jamfile
> freetype/src/pcf/README
> freetype/src/pcf/module.mk
> freetype/src/pcf/pcf.c
> freetype/src/pcf/pcf.h
> freetype/src/pcf/pcfdrivr.c
> freetype/src/pcf/pcfdrivr.h
> freetype/src/pcf/pcferror.h
> freetype/src/pcf/pcfread.c
> freetype/src/pcf/pcfread.h
> freetype/src/pcf/pcfutil.c
> freetype/src/pcf/pcfutil.h
> freetype/src/pcf/rules.mk
> freetype/src/pfr/Jamfile
> freetype/src/pfr/module.mk
> freetype/src/pfr/pfr.c
> freetype/src/pfr/pfrcmap.c
> freetype/src/pfr/pfrcmap.h
> freetype/src/pfr/pfrdrivr.c
> freetype/src/pfr/pfrdrivr.h
> freetype/src/pfr/pfrerror.h
> freetype/src/pfr/pfrgload.c
> freetype/src/pfr/pfrgload.h
> freetype/src/pfr/pfrload.c
> freetype/src/pfr/pfrload.h
> freetype/src/pfr/pfrobjs.c
> freetype/src/pfr/pfrobjs.h
> freetype/src/pfr/pfrsbit.c
> freetype/src/pfr/pfrsbit.h
> freetype/src/pfr/pfrtypes.h
> freetype/src/pfr/rules.mk
> freetype/src/psaux/Jamfile
> freetype/src/psaux/afmparse.c
> freetype/src/psaux/afmparse.h
> freetype/src/psaux/module.mk
> freetype/src/psaux/psaux.c
> freetype/src/psaux/psauxerr.h
> freetype/src/psaux/psauxmod.c
> freetype/src/psaux/psauxmod.h
> freetype/src/psaux/psconv.c
> freetype/src/psaux/psconv.h
> freetype/src/psaux/psobjs.c
> freetype/src/psaux/psobjs.h
> freetype/src/psaux/rules.mk
> freetype/src/psaux/t1cmap.c
> freetype/src/psaux/t1cmap.h
> freetype/src/psaux/t1decode.c
> freetype/src/psaux/t1decode.h
> freetype/src/pshinter/Jamfile
> freetype/src/pshinter/module.mk
> freetype/src/pshinter/pshalgo.c
> freetype/src/pshinter/pshalgo.h
> freetype/src/pshinter/pshglob.c
> freetype/src/pshinter/pshglob.h
> freetype/src/pshinter/pshinter.c
> freetype/src/pshinter/pshmod.c
> freetype/src/pshinter/pshmod.h
> freetype/src/pshinter/pshnterr.h
> freetype/src/pshinter/pshpic.c
> freetype/src/pshinter/pshpic.h
> freetype/src/pshinter/pshrec.c
> freetype/src/pshinter/pshrec.h
> freetype/src/pshinter/rules.mk
> freetype/src/psnames/Jamfile
> freetype/src/psnames/module.mk
> freetype/src/psnames/psmodule.c
> freetype/src/psnames/psmodule.h
> freetype/src/psnames/psnamerr.h
> freetype/src/psnames/psnames.c
> freetype/src/psnames/pspic.c
> freetype/src/psnames/pspic.h
> freetype/src/psnames/pstables.h
> freetype/src/psnames/rules.mk
> freetype/src/raster/Jamfile
> freetype/src/raster/ftmisc.h
> freetype/src/raster/ftraster.c
> freetype/src/raster/ftraster.h
> freetype/src/raster/ftrend1.c
> freetype/src/raster/ftrend1.h
> freetype/src/raster/module.mk
> freetype/src/raster/raster.c
> freetype/src/raster/rasterrs.h
> freetype/src/raster/rastpic.c
> freetype/src/raster/rastpic.h
> freetype/src/raster/rules.mk
> freetype/src/sfnt/Jamfile
> freetype/src/sfnt/module.mk
> freetype/src/sfnt/pngshim.c
> freetype/src/sfnt/pngshim.h
> freetype/src/sfnt/rules.mk
> freetype/src/sfnt/sfdriver.c
> freetype/src/sfnt/sfdriver.h
> freetype/src/sfnt/sferrors.h
> freetype/src/sfnt/sfnt.c
> freetype/src/sfnt/sfntpic.c
> freetype/src/sfnt/sfntpic.h
> freetype/src/sfnt/sfobjs.c
> freetype/src/sfnt/sfobjs.h
> freetype/src/sfnt/ttbdf.c
> freetype/src/sfnt/ttbdf.h
> freetype/src/sfnt/ttcmap.c
> freetype/src/sfnt/ttcmap.h
> freetype/src/sfnt/ttcmapc.h
> freetype/src/sfnt/ttkern.c
> freetype/src/sfnt/ttkern.h
> freetype/src/sfnt/ttload.c
> freetype/src/sfnt/ttload.h
> freetype/src/sfnt/ttmtx.c
> freetype/src/sfnt/ttmtx.h
> freetype/src/sfnt/ttpost.c
> freetype/src/sfnt/ttpost.h
> freetype/src/sfnt/ttsbit.c
> freetype/src/sfnt/ttsbit.h
> freetype/src/smooth/Jamfile
> freetype/src/smooth/ftgrays.c
> freetype/src/smooth/ftgrays.h
> freetype/src/smooth/ftsmerrs.h
> freetype/src/smooth/ftsmooth.c
> freetype/src/smooth/ftsmooth.h
> freetype/src/smooth/ftspic.c
> freetype/src/smooth/ftspic.h
> freetype/src/smooth/module.mk
> freetype/src/smooth/rules.mk
> freetype/src/smooth/smooth.c
> freetype/src/tools/Jamfile
> freetype/src/tools/afblue.pl
> freetype/src/tools/apinames.c
> freetype/src/tools/chktrcmp.py
> freetype/src/tools/cordic.py
> freetype/src/tools/docmaker/content.py
> freetype/src/tools/docmaker/docbeauty.py
> freetype/src/tools/docmaker/docmaker.py
> freetype/src/tools/docmaker/formatter.py
> freetype/src/tools/docmaker/sources.py
> freetype/src/tools/docmaker/tohtml.py
> freetype/src/tools/docmaker/utils.py
> freetype/src/tools/ftrandom/Makefile
> freetype/src/tools/ftrandom/README
> freetype/src/tools/ftrandom/ftrandom.c
> freetype/src/tools/glnames.py
> freetype/src/tools/test_afm.c
> freetype/src/tools/test_bbox.c
> freetype/src/tools/test_trig.c
> freetype/src/truetype/Jamfile
> freetype/src/truetype/module.mk
> freetype/src/truetype/rules.mk
> freetype/src/truetype/truetype.c
> freetype/src/truetype/ttdriver.c
> freetype/src/truetype/ttdriver.h
> freetype/src/truetype/tterrors.h
> freetype/src/truetype/ttgload.c
> freetype/src/truetype/ttgload.h
> freetype/src/truetype/ttgxvar.c
> freetype/src/truetype/ttgxvar.h
> freetype/src/truetype/ttinterp.c
> freetype/src/truetype/ttinterp.h
> freetype/src/truetype/ttobjs.c
> freetype/src/truetype/ttobjs.h
> freetype/src/truetype/ttpic.c
> freetype/src/truetype/ttpic.h
> freetype/src/truetype/ttpload.c
> freetype/src/truetype/ttpload.h
> freetype/src/truetype/ttsubpix.c
> freetype/src/truetype/ttsubpix.h
> freetype/src/type1/Jamfile
> freetype/src/type1/module.mk
> freetype/src/type1/rules.mk
> freetype/src/type1/t1afm.c
> freetype/src/type1/t1afm.h
> freetype/src/type1/t1driver.c
> freetype/src/type1/t1driver.h
> freetype/src/type1/t1errors.h
> freetype/src/type1/t1gload.c
> freetype/src/type1/t1gload.h
> freetype/src/type1/t1load.c
> freetype/src/type1/t1load.h
> freetype/src/type1/t1objs.c
> freetype/src/type1/t1objs.h
> freetype/src/type1/t1parse.c
> freetype/src/type1/t1parse.h
> freetype/src/type1/t1tokens.h
> freetype/src/type1/type1.c
> freetype/src/type42/Jamfile
> freetype/src/type42/module.mk
> freetype/src/type42/rules.mk
> freetype/src/type42/t42drivr.c
> freetype/src/type42/t42drivr.h
> freetype/src/type42/t42error.h
> freetype/src/type42/t42objs.c
> freetype/src/type42/t42objs.h
> freetype/src/type42/t42parse.c
> freetype/src/type42/t42parse.h
> freetype/src/type42/t42types.h
> freetype/src/type42/type42.c
> freetype/src/winfonts/Jamfile
> freetype/src/winfonts/fnterrs.h
> freetype/src/winfonts/module.mk
> freetype/src/winfonts/rules.mk
> freetype/src/winfonts/winfnt.c
> freetype/src/winfonts/winfnt.h
> freetype/version.sed
> freetype/vms_make.com
> ghostall.vcproj
> ghostpcl.vcproj
> ghostpdl.vcproj
> ghostscript-ufst.vcproj
> ghostscript.vcproj
> ghostscript_rt.vcxproj
> ghostxps.vcproj
> gpdl/gpdl.mak
> gpdl/psi/gpdlpsi.mak
> gpdl/psi/psitop.c
> gpdl/pspcl6_gcc.mak
> gpdl/pspcl6_msvc.mak
> gs/DroidSansFallback.NOTICE
> gs/LICENSE
> gs/Makefile.in
> gs/Resource/CIDFSubst/DroidSansFallback.ttf
> gs/Resource/CIDFont/ArtifexBullet
> gs/Resource/CMap/78-EUC-H
> gs/Resource/CMap/78-EUC-V
> gs/Resource/CMap/78-H
> gs/Resource/CMap/78-RKSJ-H
> gs/Resource/CMap/78-RKSJ-V
> gs/Resource/CMap/78-V
> gs/Resource/CMap/78ms-RKSJ-H
> gs/Resource/CMap/78ms-RKSJ-V
> gs/Resource/CMap/83pv-RKSJ-H
> gs/Resource/CMap/90ms-RKSJ-H
> gs/Resource/CMap/90ms-RKSJ-V
> gs/Resource/CMap/90msp-RKSJ-H
> gs/Resource/CMap/90msp-RKSJ-V
> gs/Resource/CMap/90pv-RKSJ-H
> gs/Resource/CMap/90pv-RKSJ-V
> gs/Resource/CMap/Add-H
> gs/Resource/CMap/Add-RKSJ-H
> gs/Resource/CMap/Add-RKSJ-V
> gs/Resource/CMap/Add-V
> gs/Resource/CMap/Adobe-CNS1-0
> gs/Resource/CMap/Adobe-CNS1-1
> gs/Resource/CMap/Adobe-CNS1-2
> gs/Resource/CMap/Adobe-CNS1-3
> gs/Resource/CMap/Adobe-CNS1-4
> gs/Resource/CMap/Adobe-CNS1-5
> gs/Resource/CMap/Adobe-CNS1-6
> gs/Resource/CMap/Adobe-GB1-0
> gs/Resource/CMap/Adobe-GB1-1
> gs/Resource/CMap/Adobe-GB1-2
> gs/Resource/CMap/Adobe-GB1-3
> gs/Resource/CMap/Adobe-GB1-4
> gs/Resource/CMap/Adobe-GB1-5
> gs/Resource/CMap/Adobe-Japan1-0
> gs/Resource/CMap/Adobe-Japan1-1
> gs/Resource/CMap/Adobe-Japan1-2
> gs/Resource/CMap/Adobe-Japan1-3
> gs/Resource/CMap/Adobe-Japan1-4
> gs/Resource/CMap/Adobe-Japan1-5
> gs/Resource/CMap/Adobe-Japan1-6
> gs/Resource/CMap/Adobe-Korea1-0
> gs/Resource/CMap/Adobe-Korea1-1
> gs/Resource/CMap/Adobe-Korea1-2
> gs/Resource/CMap/B5-H
> gs/Resource/CMap/B5-V
> gs/Resource/CMap/B5pc-H
> gs/Resource/CMap/B5pc-V
> gs/Resource/CMap/CNS-EUC-H
> gs/Resource/CMap/CNS-EUC-V
> gs/Resource/CMap/CNS1-H
> gs/Resource/CMap/CNS1-V
> gs/Resource/CMap/CNS2-H
> gs/Resource/CMap/CNS2-V
> gs/Resource/CMap/ETHK-B5-H
> gs/Resource/CMap/ETHK-B5-V
> gs/Resource/CMap/ETen-B5-H
> gs/Resource/CMap/ETen-B5-V
> gs/Resource/CMap/ETenms-B5-H
> gs/Resource/CMap/ETenms-B5-V
> gs/Resource/CMap/EUC-H
> gs/Resource/CMap/EUC-V
> gs/Resource/CMap/Ext-H
> gs/Resource/CMap/Ext-RKSJ-H
> gs/Resource/CMap/Ext-RKSJ-V
> gs/Resource/CMap/Ext-V
> gs/Resource/CMap/GB-EUC-H
> gs/Resource/CMap/GB-EUC-V
> gs/Resource/CMap/GB-H
> gs/Resource/CMap/GB-V
> gs/Resource/CMap/GBK-EUC-H
> gs/Resource/CMap/GBK-EUC-V
> gs/Resource/CMap/GBK2K-H
> gs/Resource/CMap/GBK2K-V
> gs/Resource/CMap/GBKp-EUC-H
> gs/Resource/CMap/GBKp-EUC-V
> gs/Resource/CMap/GBT-EUC-H
> gs/Resource/CMap/GBT-EUC-V
> gs/Resource/CMap/GBT-H
> gs/Resource/CMap/GBT-V
> gs/Resource/CMap/GBTpc-EUC-H
> gs/Resource/CMap/GBTpc-EUC-V
> gs/Resource/CMap/GBpc-EUC-H
> gs/Resource/CMap/GBpc-EUC-V
> gs/Resource/CMap/H
> gs/Resource/CMap/HKdla-B5-H
> gs/Resource/CMap/HKdla-B5-V
> gs/Resource/CMap/HKdlb-B5-H
> gs/Resource/CMap/HKdlb-B5-V
> gs/Resource/CMap/HKgccs-B5-H
> gs/Resource/CMap/HKgccs-B5-V
> gs/Resource/CMap/HKm314-B5-H
> gs/Resource/CMap/HKm314-B5-V
> gs/Resource/CMap/HKm471-B5-H
> gs/Resource/CMap/HKm471-B5-V
> gs/Resource/CMap/HKscs-B5-H
> gs/Resource/CMap/HKscs-B5-V
> gs/Resource/CMap/Hankaku
> gs/Resource/CMap/Hiragana
> gs/Resource/CMap/Identity-H
> gs/Resource/CMap/Identity-UTF16-H
> gs/Resource/CMap/Identity-V
> gs/Resource/CMap/KSC-EUC-H
> gs/Resource/CMap/KSC-EUC-V
> gs/Resource/CMap/KSC-H
> gs/Resource/CMap/KSC-Johab-H
> gs/Resource/CMap/KSC-Johab-V
> gs/Resource/CMap/KSC-V
> gs/Resource/CMap/KSCms-UHC-H
> gs/Resource/CMap/KSCms-UHC-HW-H
> gs/Resource/CMap/KSCms-UHC-HW-V
> gs/Resource/CMap/KSCms-UHC-V
> gs/Resource/CMap/KSCpc-EUC-H
> gs/Resource/CMap/KSCpc-EUC-V
> gs/Resource/CMap/Katakana
> gs/Resource/CMap/NWP-H
> gs/Resource/CMap/NWP-V
> gs/Resource/CMap/RKSJ-H
> gs/Resource/CMap/RKSJ-V
> gs/Resource/CMap/Roman
> gs/Resource/CMap/UniCNS-UCS2-H
> gs/Resource/CMap/UniCNS-UCS2-V
> gs/Resource/CMap/UniCNS-UTF16-H
> gs/Resource/CMap/UniCNS-UTF16-V
> gs/Resource/CMap/UniCNS-UTF32-H
> gs/Resource/CMap/UniCNS-UTF32-V
> gs/Resource/CMap/UniCNS-UTF8-H
> gs/Resource/CMap/UniCNS-UTF8-V
> gs/Resource/CMap/UniGB-UCS2-H
> gs/Resource/CMap/UniGB-UCS2-V
> gs/Resource/CMap/UniGB-UTF16-H
> gs/Resource/CMap/UniGB-UTF16-V
> gs/Resource/CMap/UniGB-UTF32-H
> gs/Resource/CMap/UniGB-UTF32-V
> gs/Resource/CMap/UniGB-UTF8-H
> gs/Resource/CMap/UniGB-UTF8-V
> gs/Resource/CMap/UniHojo-UCS2-H
> gs/Resource/CMap/UniJIS-UCS2-H
> gs/Resource/CMap/UniJIS-UCS2-HW-H
> gs/Resource/CMap/UniJIS-UCS2-HW-V
> gs/Resource/CMap/UniJIS-UCS2-V
> gs/Resource/CMap/UniJIS-UTF16-H
> gs/Resource/CMap/UniJIS-UTF16-V
> gs/Resource/CMap/UniJIS-UTF32-H
> gs/Resource/CMap/UniJIS-UTF32-V
> gs/Resource/CMap/UniJIS-UTF8-H
> gs/Resource/CMap/UniJIS-UTF8-V
> gs/Resource/CMap/UniJIS2004-UTF16-H
> gs/Resource/CMap/UniJIS2004-UTF16-V
> gs/Resource/CMap/UniJIS2004-UTF32-H
> gs/Resource/CMap/UniJIS2004-UTF32-V
> gs/Resource/CMap/UniJIS2004-UTF8-H
> gs/Resource/CMap/UniJIS2004-UTF8-V
> gs/Resource/CMap/UniJISPro-UCS2-HW-V
> gs/Resource/CMap/UniJISPro-UCS2-V
> gs/Resource/CMap/UniJISPro-UTF8-V
> gs/Resource/CMap/UniJISX0213-UTF32-H
> gs/Resource/CMap/UniJISX0213-UTF32-V
> gs/Resource/CMap/UniJISX02132004-UTF32-H
> gs/Resource/CMap/UniJISX02132004-UTF32-V
> gs/Resource/CMap/UniKS-UCS2-H
> gs/Resource/CMap/UniKS-UCS2-V
> gs/Resource/CMap/UniKS-UTF16-H
> gs/Resource/CMap/UniKS-UTF16-V
> gs/Resource/CMap/UniKS-UTF32-H
> gs/Resource/CMap/UniKS-UTF32-V
> gs/Resource/CMap/UniKS-UTF8-H
> gs/Resource/CMap/UniKS-UTF8-V
> gs/Resource/CMap/V
> gs/Resource/CMap/WP-Symbol
> gs/Resource/ColorSpace/DefaultCMYK
> gs/Resource/ColorSpace/DefaultGray
> gs/Resource/ColorSpace/DefaultRGB
> gs/Resource/ColorSpace/TrivialCMYK
> gs/Resource/ColorSpace/sGray
> gs/Resource/ColorSpace/sRGB
> gs/Resource/Decoding/FCO_Dingbats
> gs/Resource/Decoding/FCO_Symbol
> gs/Resource/Decoding/FCO_Unicode
> gs/Resource/Decoding/FCO_Wingdings
> gs/Resource/Decoding/Latin1
> gs/Resource/Decoding/StandardEncoding
> gs/Resource/Decoding/Unicode
> gs/Resource/Encoding/CEEncoding
> gs/Resource/Encoding/ExpertEncoding
> gs/Resource/Encoding/ExpertSubsetEncoding
> gs/Resource/Encoding/NotDefEncoding
> gs/Resource/Encoding/Wingdings
> gs/Resource/Font/BookmanURW-DemBol
> gs/Resource/Font/BookmanURW-DemBolIta
> gs/Resource/Font/BookmanURW-Lig
> gs/Resource/Font/BookmanURW-LigIta
> gs/Resource/Font/CenturySchURW-Bol
> gs/Resource/Font/CenturySchURW-BolIta
> gs/Resource/Font/CenturySchURW-Ita
> gs/Resource/Font/CenturySchURW-Rom
> gs/Resource/Font/ChanceryURW-MedIta
> gs/Resource/Font/Dingbats
> gs/Resource/Font/NimbusMono-Bold
> gs/Resource/Font/NimbusMono-BoldOblique
> gs/Resource/Font/NimbusMono-Oblique
> gs/Resource/Font/NimbusMono-Regular
> gs/Resource/Font/NimbusRomNo9L-Med
> gs/Resource/Font/NimbusRomNo9L-MedIta
> gs/Resource/Font/NimbusRomNo9L-Reg
> gs/Resource/Font/NimbusRomNo9L-RegIta
> gs/Resource/Font/NimbusSanL-Bol
> gs/Resource/Font/NimbusSanL-BolIta
> gs/Resource/Font/NimbusSanL-Reg
> gs/Resource/Font/NimbusSanL-RegIta
> gs/Resource/Font/NimbusSanNar-Bol
> gs/Resource/Font/NimbusSanNar-BolIta
> gs/Resource/Font/NimbusSanNar-Ita
> gs/Resource/Font/NimbusSanNar-Reg
> gs/Resource/Font/PalladioURW-Bol
> gs/Resource/Font/PalladioURW-BolIta
> gs/Resource/Font/PalladioURW-Ita
> gs/Resource/Font/PalladioURW-Rom
> gs/Resource/Font/StandardSymL
> gs/Resource/Font/URWGothic-Boo
> gs/Resource/Font/URWGothic-BooObl
> gs/Resource/Font/URWGothic-Dem
> gs/Resource/Font/URWGothic-DemObl
> gs/Resource/IdiomSet/Pscript5Idiom
> gs/Resource/Init/FAPIcidfmap
> gs/Resource/Init/FAPIconfig
> gs/Resource/Init/FAPIfontmap
> gs/Resource/Init/FCOfontmap-PCLPS2
> gs/Resource/Init/Fontmap
> gs/Resource/Init/Fontmap.GS
> gs/Resource/Init/cidfmap
> gs/Resource/Init/gs_agl.ps
> gs/Resource/Init/gs_btokn.ps
> gs/Resource/Init/gs_cet.ps
> gs/Resource/Init/gs_cff.ps
> gs/Resource/Init/gs_cidcm.ps
> gs/Resource/Init/gs_ciddc.ps
> gs/Resource/Init/gs_cidfm.ps
> gs/Resource/Init/gs_cidfn.ps
> gs/Resource/Init/gs_cidtt.ps
> gs/Resource/Init/gs_cmap.ps
> gs/Resource/Init/gs_cspace.ps
> gs/Resource/Init/gs_css_e.ps
> gs/Resource/Init/gs_dbt_e.ps
> gs/Resource/Init/gs_diskf.ps
> gs/Resource/Init/gs_diskn.ps
> gs/Resource/Init/gs_dpnxt.ps
> gs/Resource/Init/gs_dps.ps
> gs/Resource/Init/gs_dps1.ps
> gs/Resource/Init/gs_dps2.ps
> gs/Resource/Init/gs_dscp.ps
> gs/Resource/Init/gs_epsf.ps
> gs/Resource/Init/gs_fapi.ps
> gs/Resource/Init/gs_fntem.ps
> gs/Resource/Init/gs_fonts.ps
> gs/Resource/Init/gs_frsd.ps
> gs/Resource/Init/gs_icc.ps
> gs/Resource/Init/gs_il1_e.ps
> gs/Resource/Init/gs_img.ps
> gs/Resource/Init/gs_init.ps
> gs/Resource/Init/gs_l2img.ps
> gs/Resource/Init/gs_lev2.ps
> gs/Resource/Init/gs_ll3.ps
> gs/Resource/Init/gs_mex_e.ps
> gs/Resource/Init/gs_mgl_e.ps
> gs/Resource/Init/gs_mro_e.ps
> gs/Resource/Init/gs_pdf_e.ps
> gs/Resource/Init/gs_pdfwr.ps
> gs/Resource/Init/gs_res.ps
> gs/Resource/Init/gs_resmp.ps
> gs/Resource/Init/gs_setpd.ps
> gs/Resource/Init/gs_statd.ps
> gs/Resource/Init/gs_std_e.ps
> gs/Resource/Init/gs_sym_e.ps
> gs/Resource/Init/gs_trap.ps
> gs/Resource/Init/gs_ttf.ps
> gs/Resource/Init/gs_typ32.ps
> gs/Resource/Init/gs_typ42.ps
> gs/Resource/Init/gs_type1.ps
> gs/Resource/Init/gs_wan_e.ps
> gs/Resource/Init/pdf_base.ps
> gs/Resource/Init/pdf_cslayer.ps
> gs/Resource/Init/pdf_draw.ps
> gs/Resource/Init/pdf_font.ps
> gs/Resource/Init/pdf_main.ps
> gs/Resource/Init/pdf_ops.ps
> gs/Resource/Init/pdf_rbld.ps
> gs/Resource/Init/pdf_sec.ps
> gs/Resource/Init/xlatmap
> gs/Resource/SubstCID/CNS1-WMode
> gs/Resource/SubstCID/GB1-WMode
> gs/Resource/SubstCID/Japan1-WMode
> gs/Resource/SubstCID/Korea1-WMode
> gs/arch/osx-x86-x86_64-ppc-gcc.h
> gs/arch/windows-arm-msvc.h
> gs/arch/windows-x64-msvc.h
> gs/arch/windows-x86-msvc.h
> gs/autogen.sh
> gs/base/ConvertUTF.c
> gs/base/ConvertUTF.h
> gs/base/aes.c
> gs/base/aes.h
> gs/base/all-arch.mak
> gs/base/append_l.com
> gs/base/assert_.h
> gs/base/bcc32.cfg
> gs/base/bench.c
> gs/base/catmake
> gs/base/copy_one.com
> gs/base/cp.bat
> gs/base/cp.cmd
> gs/base/ctype_.h
> gs/base/dirent_.h
> gs/base/dos_.h
> gs/base/echogs.c
> gs/base/errno_.h
> gs/base/expat.mak
> gs/base/fapi_bs.mak
> gs/base/fapi_ft.c
> gs/base/fapibstm.c
> gs/base/fapiufst.c
> gs/base/fcntl_.h
> gs/base/freetype.mak
> gs/base/gconf.c
> gs/base/gconf.h
> gs/base/gdbflags.h
> gs/base/gdebug.h
> gs/base/gdevabuf.c
> gs/base/gdevbbox.c
> gs/base/gdevbbox.h
> gs/base/gdevdbit.c
> gs/base/gdevdcrd.c
> gs/base/gdevdcrd.h
> gs/base/gdevddrw.c
> gs/base/gdevddrw.h
> gs/base/gdevdevn.c
> gs/base/gdevdevn.h
> gs/base/gdevdevnprn.h
> gs/base/gdevdflt.c
> gs/base/gdevdgbr.c
> gs/base/gdevdrop.c
> gs/base/gdevdsha.c
> gs/base/gdevemap.c
> gs/base/gdevflp.c
> gs/base/gdevflp.h
> gs/base/gdevhit.c
> gs/base/gdevkrnlsclass.c
> gs/base/gdevkrnlsclass.h
> gs/base/gdevm1.c
> gs/base/gdevm16.c
> gs/base/gdevm2.c
> gs/base/gdevm24.c
> gs/base/gdevm32.c
> gs/base/gdevm4.c
> gs/base/gdevm40.c
> gs/base/gdevm48.c
> gs/base/gdevm56.c
> gs/base/gdevm64.c
> gs/base/gdevm8.c
> gs/base/gdevmem.c
> gs/base/gdevmem.h
> gs/base/gdevmpla.c
> gs/base/gdevmpla.h
> gs/base/gdevmplt.c
> gs/base/gdevmplt.h
> gs/base/gdevmr1.c
> gs/base/gdevmr2n.c
> gs/base/gdevmr8n.c
> gs/base/gdevmrop.h
> gs/base/gdevmrun.c
> gs/base/gdevmrun.h
> gs/base/gdevmx.c
> gs/base/gdevnfwd.c
> gs/base/gdevoflt.c
> gs/base/gdevoflt.h
> gs/base/gdevp14.c
> gs/base/gdevp14.h
> gs/base/gdevpccm.c
> gs/base/gdevpccm.h
> gs/base/gdevpipe.c
> gs/base/gdevplnx.c
> gs/base/gdevplnx.h
> gs/base/gdevppla.c
> gs/base/gdevppla.h
> gs/base/gdevprn.c
> gs/base/gdevprn.h
> gs/base/gdevprna.c
> gs/base/gdevprna.h
> gs/base/gdevpxat.h
> gs/base/gdevpxen.h
> gs/base/gdevpxop.h
> gs/base/gdevrops.c
> gs/base/gdevsclass.c
> gs/base/gdevsclass.h
> gs/base/gdevvec.c
> gs/base/gdevvec.h
> gs/base/genarch.c
> gs/base/genconf.c
> gs/base/gendev.c
> gs/base/genht.c
> gs/base/gp.h
> gs/base/gp_dosfe.c
> gs/base/gp_dosfs.c
> gs/base/gp_dvx.c
> gs/base/gp_getnv.c
> gs/base/gp_mac.c
> gs/base/gp_mac.h
> gs/base/gp_macio.c
> gs/base/gp_macpoll.c
> gs/base/gp_mktmp.c
> gs/base/gp_msdll.c
> gs/base/gp_msdos.c
> gs/base/gp_mshdl.c
> gs/base/gp_mslib.c
> gs/base/gp_mspol.c
> gs/base/gp_msprn.c
> gs/base/gp_mswin.c
> gs/base/gp_mswin.h
> gs/base/gp_nsync.c
> gs/base/gp_ntfs.c
> gs/base/gp_os2.c
> gs/base/gp_os2.h
> gs/base/gp_os2fs.c
> gs/base/gp_os2pr.c
> gs/base/gp_os9.c
> gs/base/gp_paper.c
> gs/base/gp_psync.c
> gs/base/gp_stdia.c
> gs/base/gp_stdin.c
> gs/base/gp_strdl.c
> gs/base/gp_sysv.c
> gs/base/gp_unifn.c
> gs/base/gp_unifs.c
> gs/base/gp_unix.c
> gs/base/gp_unix_cache.c
> gs/base/gp_upapr.c
> gs/base/gp_vms.c
> gs/base/gp_wgetv.c
> gs/base/gp_win32.c
> gs/base/gp_wpapr.c
> gs/base/gp_wsync.c
> gs/base/gp_wutf8.c
> gs/base/gpcheck.h
> gs/base/gpgetenv.h
> gs/base/gpmisc.c
> gs/base/gpmisc.h
> gs/base/gpsync.h
> gs/base/gs.mak
> gs/base/gs_dll_call.h
> gs/base/gs_mgl_e.h
> gs/base/gs_mro_e.h
> gs/base/gsalloc.c
> gs/base/gsalloc.h
> gs/base/gsalpha.c
> gs/base/gsalpha.h
> gs/base/gsalphac.c
> gs/base/gsalphac.h
> gs/base/gsargs.c
> gs/base/gsargs.h
> gs/base/gsbitcom.c
> gs/base/gsbitmap.h
> gs/base/gsbitops.c
> gs/base/gsbitops.h
> gs/base/gsbittab.c
> gs/base/gsbittab.h
> gs/base/gsccode.h
> gs/base/gsccolor.h
> gs/base/gscdef.c
> gs/base/gscdefs.h
> gs/base/gscdevn.c
> gs/base/gscdevn.h
> gs/base/gscedata.c
> gs/base/gscedata.h
> gs/base/gscencs.c
> gs/base/gscencs.h
> gs/base/gschar.c
> gs/base/gschar.h
> gs/base/gschar0.c
> gs/base/gscicach.c
> gs/base/gscicach.h
> gs/base/gscie.c
> gs/base/gscie.h
> gs/base/gsciemap.c
> gs/base/gscindex.h
> gs/base/gsclipsr.c
> gs/base/gsclipsr.h
> gs/base/gscms.h
> gs/base/gscolor.c
> gs/base/gscolor.h
> gs/base/gscolor1.c
> gs/base/gscolor1.h
> gs/base/gscolor2.c
> gs/base/gscolor2.h
> gs/base/gscolor3.c
> gs/base/gscolor3.h
> gs/base/gscolorbuffer.c
> gs/base/gscolorbuffer.h
> gs/base/gscompt.h
> gs/base/gscoord.c
> gs/base/gscoord.h
> gs/base/gscparam.c
> gs/base/gscpixel.c
> gs/base/gscpixel.h
> gs/base/gscpm.h
> gs/base/gscrd.c
> gs/base/gscrd.h
> gs/base/gscrdp.c
> gs/base/gscrdp.h
> gs/base/gscrypt1.c
> gs/base/gscrypt1.h
> gs/base/gscscie.c
> gs/base/gscsel.h
> gs/base/gscsepr.c
> gs/base/gscsepr.h
> gs/base/gscspace.c
> gs/base/gscspace.h
> gs/base/gscssub.c
> gs/base/gscssub.h
> gs/base/gsdcolor.h
> gs/base/gsdevice.c
> gs/base/gsdevice.h
> gs/base/gsdevmem.c
> gs/base/gsdfilt.c
> gs/base/gsdfilt.h
> gs/base/gsdll.h
> gs/base/gsdllwin.h
> gs/base/gsdparam.c
> gs/base/gsdpnext.h
> gs/base/gsdps.c
> gs/base/gsdps.h
> gs/base/gsdps1.c
> gs/base/gsdsrc.c
> gs/base/gsdsrc.h
> gs/base/gsequivc.c
> gs/base/gsequivc.h
> gs/base/gserrors.h
> gs/base/gsexit.h
> gs/base/gsfcid.c
> gs/base/gsfcid2.c
> gs/base/gsfcmap.c
> gs/base/gsfcmap.h
> gs/base/gsfcmap1.c
> gs/base/gsflip.c
> gs/base/gsflip.h
> gs/base/gsfname.c
> gs/base/gsfname.h
> gs/base/gsfont.c
> gs/base/gsfont.h
> gs/base/gsfont0.c
> gs/base/gsfont0c.c
> gs/base/gsform1.h
> gs/base/gsfunc.c
> gs/base/gsfunc.h
> gs/base/gsfunc0.c
> gs/base/gsfunc0.h
> gs/base/gsfunc3.c
> gs/base/gsfunc3.h
> gs/base/gsfunc4.c
> gs/base/gsfunc4.h
> gs/base/gsgc.h
> gs/base/gsgcache.c
> gs/base/gsgcache.h
> gs/base/gsgdata.c
> gs/base/gsgdata.h
> gs/base/gshsb.c
> gs/base/gshsb.h
> gs/base/gsht.c
> gs/base/gsht.h
> gs/base/gsht1.c
> gs/base/gsht1.h
> gs/base/gshtscr.c
> gs/base/gshtx.c
> gs/base/gshtx.h
> gs/base/gsicc.c
> gs/base/gsicc.h
> gs/base/gsicc_cache.c
> gs/base/gsicc_cache.h
> gs/base/gsicc_cms.h
> gs/base/gsicc_create.c
> gs/base/gsicc_create.h
> gs/base/gsicc_lcms.c
> gs/base/gsicc_lcms2.c
> gs/base/gsicc_manage.c
> gs/base/gsicc_manage.h
> gs/base/gsicc_monitorcm.c
> gs/base/gsicc_nocm.c
> gs/base/gsicc_profilecache.c
> gs/base/gsicc_profilecache.h
> gs/base/gsicc_replacecm.c
> gs/base/gsimage.c
> gs/base/gsimage.h
> gs/base/gsimpath.c
> gs/base/gsinit.c
> gs/base/gsio.h
> gs/base/gsiodev.c
> gs/base/gsiodevs.c
> gs/base/gsiodisk.c
> gs/base/gsiomacres.c
> gs/base/gsioram.c
> gs/base/gsiorom.c
> gs/base/gsiorom.h
> gs/base/gsipar3x.h
> gs/base/gsiparam.h
> gs/base/gsiparm2.h
> gs/base/gsiparm3.h
> gs/base/gsiparm4.h
> gs/base/gsistate.c
> gs/base/gsjconf.h
> gs/base/gsjmorec.h
> gs/base/gslib.c
> gs/base/gslib.h
> gs/base/gslibctx.c
> gs/base/gslibctx.h
> gs/base/gsline.c
> gs/base/gsline.h
> gs/base/gslparam.h
> gs/base/gsmalloc.c
> gs/base/gsmalloc.h
> gs/base/gsmatrix.c
> gs/base/gsmatrix.h
> gs/base/gsmchunk.c
> gs/base/gsmchunk.h
> gs/base/gsmd5.c
> gs/base/gsmd5.h
> gs/base/gsmdebug.h
> gs/base/gsmemlok.c
> gs/base/gsmemlok.h
> gs/base/gsmemory.c
> gs/base/gsmemory.h
> gs/base/gsmemraw.h
> gs/base/gsmemret.c
> gs/base/gsmemret.h
> gs/base/gsmisc.c
> gs/base/gsnamecl.c
> gs/base/gsnamecl.h
> gs/base/gsncdummy.c
> gs/base/gsncdummy.h
> gs/base/gsnogc.c
> gs/base/gsnogc.h
> gs/base/gsnotify.c
> gs/base/gsnotify.h
> gs/base/gsovrc.c
> gs/base/gsovrc.h
> gs/base/gspaint.c
> gs/base/gspaint.h
> gs/base/gsparam.c
> gs/base/gsparam.h
> gs/base/gsparam2.c
> gs/base/gsparams.c
> gs/base/gsparams.h
> gs/base/gsparamx.c
> gs/base/gsparamx.h
> gs/base/gspath.c
> gs/base/gspath.h
> gs/base/gspath1.c
> gs/base/gspath2.h
> gs/base/gspcolor.c
> gs/base/gspcolor.h
> gs/base/gspenum.h
> gs/base/gspmdrv.c
> gs/base/gspmdrv.def
> gs/base/gspmdrv.h
> gs/base/gspmdrv.icx
> gs/base/gspmdrv.rc
> gs/base/gsptype1.c
> gs/base/gsptype1.h
> gs/base/gsptype2.c
> gs/base/gsptype2.h
> gs/base/gsrect.h
> gs/base/gsrefct.h
> gs/base/gsromfs0.c
> gs/base/gsrop.c
> gs/base/gsrop.h
> gs/base/gsroprun.c
> gs/base/gsroprun1.h
> gs/base/gsroprun24.h
> gs/base/gsroprun8.h
> gs/base/gsropt.h
> gs/base/gsroptab.c
> gs/base/gsserial.c
> gs/base/gsserial.h
> gs/base/gsshade.c
> gs/base/gsshade.h
> gs/base/gssprintf.c
> gs/base/gssprintf.h
> gs/base/gsstate.c
> gs/base/gsstate.h
> gs/base/gsstrtok.c
> gs/base/gsstrtok.h
> gs/base/gsstruct.h
> gs/base/gsstype.h
> gs/base/gstext.c
> gs/base/gstext.h
> gs/base/gstiffio.c
> gs/base/gstiffio.h
> gs/base/gstparam.h
> gs/base/gstrans.c
> gs/base/gstrans.h
> gs/base/gstrap.c
> gs/base/gstrap.h
> gs/base/gstype1.c
> gs/base/gstype1.h
> gs/base/gstype2.c
> gs/base/gstype42.c
> gs/base/gstypes.h
> gs/base/gsuid.h
> gs/base/gsutil.c
> gs/base/gsutil.h
> gs/base/gswin.icx
> gs/base/gswin.rc
> gs/base/gswin16.icx
> gs/base/gswin32.rc
> gs/base/gsxfont.h
> gs/base/gx.h
> gs/base/gxacpath.c
> gs/base/gxalloc.h
> gs/base/gxalpha.h
> gs/base/gxarith.h
> gs/base/gxband.h
> gs/base/gxbcache.c
> gs/base/gxbcache.h
> gs/base/gxbitfmt.h
> gs/base/gxbitmap.h
> gs/base/gxbitops.h
> gs/base/gxblend.c
> gs/base/gxblend.h
> gs/base/gxblend1.c
> gs/base/gxccache.c
> gs/base/gxccman.c
> gs/base/gxcdevn.h
> gs/base/gxchar.c
> gs/base/gxchar.h
> gs/base/gxchrout.c
> gs/base/gxchrout.h
> gs/base/gxcht.c
> gs/base/gxcid.h
> gs/base/gxcie.h
> gs/base/gxcindex.h
> gs/base/gxclbits.c
> gs/base/gxcldev.h
> gs/base/gxclfile.c
> gs/base/gxclimag.c
> gs/base/gxclio.h
> gs/base/gxclip.c
> gs/base/gxclip.h
> gs/base/gxclip2.c
> gs/base/gxclip2.h
> gs/base/gxclipm.c
> gs/base/gxclipm.h
> gs/base/gxclipsr.h
> gs/base/gxclist.c
> gs/base/gxclist.h
> gs/base/gxcllzw.c
> gs/base/gxclmem.c
> gs/base/gxclmem.h
> gs/base/gxclpage.c
> gs/base/gxclpage.h
> gs/base/gxclpath.c
> gs/base/gxclpath.h
> gs/base/gxclrast.c
> gs/base/gxclread.c
> gs/base/gxclrect.c
> gs/base/gxclthrd.c
> gs/base/gxclthrd.h
> gs/base/gxclutil.c
> gs/base/gxclzlib.c
> gs/base/gxcmap.c
> gs/base/gxcmap.h
> gs/base/gxcolor2.h
> gs/base/gxcomp.h
> gs/base/gxcoord.h
> gs/base/gxcpath.c
> gs/base/gxcpath.h
> gs/base/gxcspace.h
> gs/base/gxctable.c
> gs/base/gxctable.h
> gs/base/gxcvalue.h
> gs/base/gxdcconv.c
> gs/base/gxdcconv.h
> gs/base/gxdcolor.c
> gs/base/gxdcolor.h
> gs/base/gxdda.h
> gs/base/gxdevbuf.h
> gs/base/gxdevcli.h
> gs/base/gxdevice.h
> gs/base/gxdevmem.h
> gs/base/gxdevndi.c
> gs/base/gxdevndi.h
> gs/base/gxdevrop.h
> gs/base/gxdevsop.h
> gs/base/gxdht.h
> gs/base/gxdhtres.h
> gs/base/gxdhtserial.c
> gs/base/gxdhtserial.h
> gs/base/gxdither.h
> gs/base/gxdownscale.c
> gs/base/gxdownscale.h
> gs/base/gxdtfill.h
> gs/base/gxfapi.c
> gs/base/gxfapi.h
> gs/base/gxfapiu.c
> gs/base/gxfapiu.h
> gs/base/gxfarith.h
> gs/base/gxfcache.h
> gs/base/gxfcid.h
> gs/base/gxfcmap.h
> gs/base/gxfcmap1.h
> gs/base/gxfdrop.c
> gs/base/gxfdrop.h
> gs/base/gxfill.c
> gs/base/gxfill.h
> gs/base/gxfillsl.h
> gs/base/gxfilltr.h
> gs/base/gxfillts.h
> gs/base/gxfixed.h
> gs/base/gxfmap.h
> gs/base/gxfont.h
> gs/base/gxfont0.h
> gs/base/gxfont0c.h
> gs/base/gxfont1.h
> gs/base/gxfont42.h
> gs/base/gxfrac.h
> gs/base/gxftype.h
> gs/base/gxfunc.h
> gs/base/gxgetbit.h
> gs/base/gxhintn.c
> gs/base/gxhintn.h
> gs/base/gxhintn1.c
> gs/base/gxhldevc.c
> gs/base/gxhldevc.h
> gs/base/gxht.c
> gs/base/gxht.h
> gs/base/gxht_thresh.c
> gs/base/gxht_thresh.h
> gs/base/gxhtbit.c
> gs/base/gxhttile.h
> gs/base/gxhttype.h
> gs/base/gxi12bit.c
> gs/base/gxi16bit.c
> gs/base/gxiclass.h
> gs/base/gxicolor.c
> gs/base/gxidata.c
> gs/base/gxifast.c
> gs/base/gximag3x.c
> gs/base/gximag3x.h
> gs/base/gximage.c
> gs/base/gximage.h
> gs/base/gximage1.c
> gs/base/gximage2.c
> gs/base/gximage3.c
> gs/base/gximage3.h
> gs/base/gximage4.c
> gs/base/gximask.c
> gs/base/gximask.h
> gs/base/gximdecode.c
> gs/base/gximdecode.h
> gs/base/gximono.c
> gs/base/gxino12b.c
> gs/base/gxino16b.c
> gs/base/gxiodev.h
> gs/base/gxiparam.h
> gs/base/gxipixel.c
> gs/base/gxiscale.c
> gs/base/gxistate.h
> gs/base/gxline.h
> gs/base/gxlum.h
> gs/base/gxmatrix.h
> gs/base/gxmclip.c
> gs/base/gxmclip.h
> gs/base/gxobj.h
> gs/base/gxoprect.c
> gs/base/gxoprect.h
> gs/base/gxp1fill.c
> gs/base/gxp1impl.h
> gs/base/gxpageq.c
> gs/base/gxpageq.h
> gs/base/gxpaint.c
> gs/base/gxpaint.h
> gs/base/gxpath.c
> gs/base/gxpath.h
> gs/base/gxpath2.c
> gs/base/gxpcache.h
> gs/base/gxpcmap.c
> gs/base/gxpcolor.h
> gs/base/gxpcopy.c
> gs/base/gxpdash.c
> gs/base/gxpflat.c
> gs/base/gxrplane.h
> gs/base/gxsample.c
> gs/base/gxsample.h
> gs/base/gxsamplp.h
> gs/base/gxshade.c
> gs/base/gxshade.h
> gs/base/gxshade1.c
> gs/base/gxshade4.c
> gs/base/gxshade4.h
> gs/base/gxshade6.c
> gs/base/gxstate.h
> gs/base/gxstdio.h
> gs/base/gxstroke.c
> gs/base/gxsync.c
> gs/base/gxsync.h
> gs/base/gxtext.h
> gs/base/gxtmap.h
> gs/base/gxttf.h
> gs/base/gxttfb.c
> gs/base/gxttfb.h
> gs/base/gxtype1.c
> gs/base/gxtype1.h
> gs/base/gxxfont.h
> gs/base/gzacpath.h
> gs/base/gzcpath.h
> gs/base/gzht.h
> gs/base/gzline.h
> gs/base/gzpath.h
> gs/base/gzspotan.c
> gs/base/gzspotan.h
> gs/base/gzstate.h
> gs/base/icc34.h
> gs/base/ijs.mak
> gs/base/instcopy
> gs/base/jbig2.mak
> gs/base/jerror_.h
> gs/base/jmemcust.c
> gs/base/jmemcust.h
> gs/base/jpeg.mak
> gs/base/jpegxr.mak
> gs/base/lcms2.mak
> gs/base/lcups.mak
> gs/base/lcupsi.mak
> gs/base/ldf_jb2.mak
> gs/base/lib.mak
> gs/base/locale_.h
> gs/base/lwf_jp2.mak
> gs/base/macgenmcpxml.sh
> gs/base/macos-mcp.mak
> gs/base/macos_carbon_d_pre.h
> gs/base/macos_carbon_pre.h
> gs/base/macos_classic_d_pre.h
> gs/base/macosx.mak
> gs/base/macsystypes.h
> gs/base/malloc_.h
> gs/base/math_.h
> gs/base/md5main.c
> gs/base/memento.c
> gs/base/memento.h
> gs/base/memory_.h
> gs/base/mkromfs.c
> gs/base/msvccmd.mak
> gs/base/msvclib.mak
> gs/base/msvctail.mak
> gs/base/mv.bat
> gs/base/mv.cmd
> gs/base/openjpeg.mak
> gs/base/openvms.mak
> gs/base/openvms.mmk
> gs/base/pcwin.mak
> gs/base/pipe_.h
> gs/base/png.mak
> gs/base/png_.h
> gs/base/ramfs.c
> gs/base/ramfs.h
> gs/base/rm.bat
> gs/base/rm.cmd
> gs/base/rm_all.com
> gs/base/rm_one.com
> gs/base/sa85d.c
> gs/base/sa85d.h
> gs/base/sa85x.h
> gs/base/saes.c
> gs/base/saes.h
> gs/base/sarc4.c
> gs/base/sarc4.h
> gs/base/sbcp.c
> gs/base/sbcp.h
> gs/base/sbtx.h
> gs/base/scanchar.h
> gs/base/scantab.c
> gs/base/scf.h
> gs/base/scfd.c
> gs/base/scfdgen.c
> gs/base/scfdtab.c
> gs/base/scfe.c
> gs/base/scfetab.c
> gs/base/scfparam.c
> gs/base/scfx.h
> gs/base/scommon.h
> gs/base/sdcparam.c
> gs/base/sdcparam.h
> gs/base/sdct.h
> gs/base/sdctc.c
> gs/base/sdctd.c
> gs/base/sdcte.c
> gs/base/sddparam.c
> gs/base/sdeparam.c
> gs/base/seexec.c
> gs/base/setjmp_.h
> gs/base/sfilter.h
> gs/base/sfilter2.c
> gs/base/sfxboth.c
> gs/base/sfxcommon.c
> gs/base/sfxfd.c
> gs/base/sfxstdio.c
> gs/base/sha2.c
> gs/base/sha2.h
> gs/base/shc.c
> gs/base/shc.h
> gs/base/sidscale.c
> gs/base/sidscale.h
> gs/base/siinterp.c
> gs/base/siinterp.h
> gs/base/simscale.c
> gs/base/simscale.h
> gs/base/siscale.c
> gs/base/siscale.h
> gs/base/sisparam.h
> gs/base/sjbig2.c
> gs/base/sjbig2.h
> gs/base/sjbig2_luratech.c
> gs/base/sjbig2_luratech.h
> gs/base/sjpeg.h
> gs/base/sjpegc.c
> gs/base/sjpegd.c
> gs/base/sjpege.c
> gs/base/sjpx_luratech.c
> gs/base/sjpx_luratech.h
> gs/base/sjpx_openjpeg.c
> gs/base/sjpx_openjpeg.h
> gs/base/slzwc.c
> gs/base/slzwd.c
> gs/base/slzwe.c
> gs/base/slzwx.h
> gs/base/smd5.c
> gs/base/smd5.h
> gs/base/smtf.c
> gs/base/smtf.h
> gs/base/spdiff.c
> gs/base/spdiffx.h
> gs/base/spngp.c
> gs/base/spngpx.h
> gs/base/spprint.c
> gs/base/spprint.h
> gs/base/spsdf.c
> gs/base/spsdf.h
> gs/base/srdline.h
> gs/base/srld.c
> gs/base/srle.c
> gs/base/srlx.h
> gs/base/ssha2.c
> gs/base/ssha2.h
> gs/base/sstring.c
> gs/base/sstring.h
> gs/base/stat_.h
> gs/base/std.h
> gs/base/stdint_.h
> gs/base/stdio_.h
> gs/base/stdpn.h
> gs/base/stdpre.h
> gs/base/stream.c
> gs/base/stream.h
> gs/base/strimpl.h
> gs/base/string_.h
> gs/base/strmio.c
> gs/base/strmio.h
> gs/base/stub.mak
> gs/base/szlibc.c
> gs/base/szlibd.c
> gs/base/szlibe.c
> gs/base/szlibx.h
> gs/base/szlibxx.h
> gs/base/tiff.mak
> gs/base/time_.h
> gs/base/ttcalc.c
> gs/base/ttcalc.h
> gs/base/ttcommon.h
> gs/base/ttconf.h
> gs/base/ttconfig.h
> gs/base/ttfinp.c
> gs/base/ttfinp.h
> gs/base/ttfmain.c
> gs/base/ttfmemd.c
> gs/base/ttfmemd.h
> gs/base/ttfoutl.h
> gs/base/ttfsfnt.h
> gs/base/ttinterp.c
> gs/base/ttinterp.h
> gs/base/ttload.c
> gs/base/ttload.h
> gs/base/ttmisc.h
> gs/base/ttobjs.c
> gs/base/ttobjs.h
> gs/base/tttables.h
> gs/base/tttype.h
> gs/base/tttypes.h
> gs/base/ugcclib.mak
> gs/base/unistd_.h
> gs/base/unix-aux.mak
> gs/base/unix-dll.mak
> gs/base/unix-end.mak
> gs/base/unix-gcc.mak
> gs/base/unixansi.mak
> gs/base/unixhead.mak
> gs/base/unixinst.mak
> gs/base/unixlink.mak
> gs/base/valgrind.h
> gs/base/vdtrace.c
> gs/base/vdtrace.h
> gs/base/version.mak
> gs/base/vms_x_fix.h
> gs/base/vmsmath.h
> gs/base/windows_.h
> gs/base/winlib.mak
> gs/base/winplat.mak
> gs/base/winrtsup.cpp
> gs/base/winrtsup.h
> gs/base/wrfont.c
> gs/base/wrfont.h
> gs/base/write_t1.c
> gs/base/write_t1.h
> gs/base/write_t2.c
> gs/base/write_t2.h
> gs/base/x_.h
> gs/base/xpsprint.cpp
> gs/base/zlib.mak
> gs/configure.ac
> gs/contrib/chp2200/AUTHORS
> gs/contrib/chp2200/COPYING
> gs/contrib/chp2200/INSTALL
> gs/contrib/contrib.mak
> gs/contrib/defs.h
> gs/contrib/eplaser/gdevescv.c
> gs/contrib/eplaser/gdevescv.h
> gs/contrib/epson740/README
> gs/contrib/epson740/printerdb_rh5.2
> gs/contrib/epson740/printerdb_rh6.0
> gs/contrib/epson740/ps-to-printer.fpi_rh5.2
> gs/contrib/epson740/upp-HowTo-to-be
> gs/contrib/gdevbjc_.c
> gs/contrib/gdevbjc_.h
> gs/contrib/gdevbjca.c
> gs/contrib/gdevcd8.c
> gs/contrib/gdevcd8.h
> gs/contrib/gdevdj9.c
> gs/contrib/gdevgdi.c
> gs/contrib/gdevhl12.c
> gs/contrib/gdevln03.c
> gs/contrib/gdevlx32.c
> gs/contrib/gdevlx7.c
> gs/contrib/gdevmd2k.c
> gs/contrib/gdevop4w.c
> gs/contrib/gdevxes.c
> gs/contrib/gomni.c
> gs/contrib/japanese/dmp_init.ps
> gs/contrib/japanese/dmp_site.ps
> gs/contrib/japanese/doc/Gdevlips.htm
> gs/contrib/japanese/doc/README.gs550j
> gs/contrib/japanese/doc/cdj880.txt
> gs/contrib/japanese/doc/dj505j.txt
> gs/contrib/japanese/doc/djgpp.txt
> gs/contrib/japanese/doc/gdev10v.txt
> gs/contrib/japanese/doc/gdevalps.txt
> gs/contrib/japanese/doc/gdevcd8.txt
> gs/contrib/japanese/doc/gdevdmpr.txt
> gs/contrib/japanese/doc/gdevfmlbp.txt
> gs/contrib/japanese/doc/gdevj100.txt
> gs/contrib/japanese/doc/gdevlbp3.txt
> gs/contrib/japanese/doc/gdevmag.txt
> gs/contrib/japanese/doc/gdevmd2k.txt
> gs/contrib/japanese/doc/gdevmjc.txt
> gs/contrib/japanese/doc/gdevml6.txt
> gs/contrib/japanese/doc/gdevp201.txt
> gs/contrib/japanese/doc/gs261j.euc
> gs/contrib/japanese/doc/gs261j.txt
> gs/contrib/japanese/dviprlib.c
> gs/contrib/japanese/dviprlib.h
> gs/contrib/japanese/escp_24.src
> gs/contrib/japanese/gdev10v.c
> gs/contrib/japanese/gdevalps.c
> gs/contrib/japanese/gdevdmpr.c
> gs/contrib/japanese/gdevespg.c
> gs/contrib/japanese/gdevfmlbp.c
> gs/contrib/japanese/gdevfmpr.c
> gs/contrib/japanese/gdevj100.c
> gs/contrib/japanese/gdevlbp3.c
> gs/contrib/japanese/gdevmag.c
> gs/contrib/japanese/gdevmjc.c
> gs/contrib/japanese/gdevmjc.h
> gs/contrib/japanese/gdevml6.c
> gs/contrib/japanese/gdevnpdl.c
> gs/contrib/japanese/gdevp201.c
> gs/contrib/japanese/gdevrpdl.c
> gs/contrib/lips4/gdevl4r.c
> gs/contrib/lips4/gdevl4v.c
> gs/contrib/lips4/gdevlips.c
> gs/contrib/lips4/gdevlips.h
> gs/contrib/lips4/gdevlprn.c
> gs/contrib/lips4/gdevlprn.h
> gs/contrib/lxm3200-tweaked/LICENSE
> gs/contrib/lxm3200-tweaked/README
> gs/contrib/lxm3200-tweaked/RELEASE_NOTES
> gs/contrib/lxm3200-tweaked/Z12-Z31-QuickSetup
> gs/contrib/md2k_md5k/README.jis
> gs/contrib/opvp/gdevopvp.c
> gs/contrib/opvp/opvp.h
> gs/contrib/opvp/opvp_0_2_0.h
> gs/contrib/opvp/opvp_common.h
> gs/contrib/opvp/opvp_media.def
> gs/contrib/pcl3/BUGS
> gs/contrib/pcl3/LGPL
> gs/contrib/pcl3/NEWS
> gs/contrib/pcl3/README
> gs/contrib/pcl3/doc/gs-mods.txt
> gs/contrib/pcl3/doc/gs-pcl3.1
> gs/contrib/pcl3/doc/gs-pcl3.html
> gs/contrib/pcl3/doc/gs-pcl3.ref
> gs/contrib/pcl3/doc/how-to-report.txt
> gs/contrib/pcl3/doc/notes.bbl
> gs/contrib/pcl3/doc/notes.tex
> gs/contrib/pcl3/doc/pcl3opts.1
> gs/contrib/pcl3/doc/pcl3opts.html
> gs/contrib/pcl3/doc/pcl3opts.ref
> gs/contrib/pcl3/doc/reports.txt
> gs/contrib/pcl3/eprn/eprnfs.c
> gs/contrib/pcl3/eprn/eprnparm.c
> gs/contrib/pcl3/eprn/eprnrend.c
> gs/contrib/pcl3/eprn/gdeveprn.c
> gs/contrib/pcl3/eprn/gdeveprn.h
> gs/contrib/pcl3/eprn/mediasize.c
> gs/contrib/pcl3/eprn/mediasize.h
> gs/contrib/pcl3/eprn/pagecount.c
> gs/contrib/pcl3/eprn/pagecount.h
> gs/contrib/pcl3/lib/cups-pcl3
> gs/contrib/pcl3/lib/example.mcf
> gs/contrib/pcl3/lib/if-pcl3
> gs/contrib/pcl3/pcl3.tar.sig
> gs/contrib/pcl3/ppd/README
> gs/contrib/pcl3/ppd/catppd
> gs/contrib/pcl3/ppd/fonts.ppd
> gs/contrib/pcl3/ppd/gs-5.50.ppd
> gs/contrib/pcl3/ppd/gs-6.01.ppd
> gs/contrib/pcl3/ppd/gs-6.50.ppd
> gs/contrib/pcl3/ppd/gs-6.51.ppd
> gs/contrib/pcl3/ppd/gs-7.00.ppd
> gs/contrib/pcl3/ppd/gs-common.ppd
> gs/contrib/pcl3/ppd/gs-pcl3-common.ppd
> gs/contrib/pcl3/ppd/gs-pcl3-hpdj1120c.ppd
> gs/contrib/pcl3/ppd/gs-pcl3-hpdj3xx.ppd
> gs/contrib/pcl3/ppd/gs-pcl3-hpdj400.ppd
> gs/contrib/pcl3/ppd/gs-pcl3-hpdj500.ppd
> gs/contrib/pcl3/ppd/gs-pcl3-hpdj500c.ppd
> gs/contrib/pcl3/ppd/gs-pcl3-hpdj510.ppd
> gs/contrib/pcl3/ppd/gs-pcl3-hpdj540.ppd
> gs/contrib/pcl3/ppd/gs-pcl3-hpdj550c.ppd
> gs/contrib/pcl3/ppd/gs-pcl3-hpdj600.ppd
> gs/contrib/pcl3/ppd/gs-pcl3-hpdj660c.ppd
> gs/contrib/pcl3/ppd/gs-pcl3-hpdj680c.ppd
> gs/contrib/pcl3/ppd/gs-pcl3-hpdj8xxc.ppd
> gs/contrib/pcl3/ppd/gs-pcl3-hpdjportable.ppd
> gs/contrib/pcl3/ppd/gs-pcl3-unspec.ppd
> gs/contrib/pcl3/ppd/gs-pcl3-unspecold.ppd
> gs/contrib/pcl3/ps/calign.ps
> gs/contrib/pcl3/ps/dumppdd.ps
> gs/contrib/pcl3/ps/levels-test.ps
> gs/contrib/pcl3/ps/margins-A4.ps
> gs/contrib/pcl3/ps/margins-A4Rotated.ps
> gs/contrib/pcl3/ps/margins-Env10Rotated.ps
> gs/contrib/pcl3/ps/margins-EnvDLRotated.ps
> gs/contrib/pcl3/ps/margins-Letter.ps
> gs/contrib/pcl3/ps/margins-LetterRotated.ps
> gs/contrib/pcl3/src/contrib.mak-5.50.add
> gs/contrib/pcl3/src/contrib.mak-6.01.add
> gs/contrib/pcl3/src/contrib.mak-6.50.add
> gs/contrib/pcl3/src/contrib.mak-6.51.add
> gs/contrib/pcl3/src/contrib.mak-7.00.add
> gs/contrib/pcl3/src/gdevpcl3.c
> gs/contrib/pcl3/src/pcl3opts-de.msg
> gs/contrib/pcl3/src/pcl3opts-en.msg
> gs/contrib/pcl3/src/pcl3opts.c
> gs/contrib/pcl3/src/pclcap.c
> gs/contrib/pcl3/src/pclcap.h
> gs/contrib/pcl3/src/pclcomp.c
> gs/contrib/pcl3/src/pclgen.c
> gs/contrib/pcl3/src/pclgen.h
> gs/contrib/pcl3/src/pclscan.c
> gs/contrib/pcl3/src/pclscan.h
> gs/contrib/pcl3/src/pclsize.c
> gs/contrib/pcl3/src/pclsize.h
> gs/contrib/pcl3/src/zmedia2.c-5.50.diff
> gs/contrib/pcl3/src/zmedia2.c-6.01.diff
> gs/contrib/pcl3/src/zmedia2.c-6.50.diff
> gs/contrib/pcl3/src/zmedia2.c-6.51.diff
> gs/contrib/pcl3/src/zmedia2.c-7.00.diff
> gs/contrib/pscolor/Makefile
> gs/contrib/pscolor/black.pdf
> gs/contrib/pscolor/black.ps
> gs/contrib/pscolor/color.pdf
> gs/contrib/pscolor/color.ps
> gs/contrib/pscolor/colorsplit.vcproj
> gs/contrib/pscolor/common.mak
> gs/contrib/pscolor/input.ps
> gs/contrib/pscolor/instream.yy
> gs/contrib/pscolor/test.c
> gs/contrib/pscolor/windows.mak
> gs/contrib/uniprint/PM760p.upp
> gs/contrib/uniprint/PM760pl.upp
> gs/contrib/uniprint/PM820p.upp
> gs/contrib/uniprint/PM820pl.upp
> gs/contrib/uniprint/Stc670p.upp
> gs/contrib/uniprint/Stc670pl.upp
> gs/contrib/uniprint/Stc680p.upp
> gs/contrib/uniprint/Stc680pl.upp
> gs/contrib/uniprint/Stc740p.upp
> gs/contrib/uniprint/Stc740pl.upp
> gs/contrib/uniprint/Stc760p.upp
> gs/contrib/uniprint/Stc760pl.upp
> gs/contrib/uniprint/Stc777p.upp
> gs/contrib/uniprint/Stc777pl.upp
> gs/contrib/uniprint/Stp720p.upp
> gs/contrib/uniprint/Stp720pl.upp
> gs/contrib/uniprint/Stp870p.upp
> gs/contrib/uniprint/Stp870pl.upp
> gs/contrib/uniprint/bjc6000a1.upp
> gs/contrib/uniprint/bjc6000b1.upp
> gs/contrib/uniprint/s400a1.upp
> gs/contrib/uniprint/s400b1.upp
> gs/contrib/uniprint/sharp.upp
> gs/contrib/uniprint/sipixa6.upp
> gs/contrib/uniprint/stc740ih.upp
> gs/cups/cups.mak
> gs/cups/gdevcups.c
> gs/cups/libs/Makedefs
> gs/cups/libs/configlinux.h
> gs/cups/libs/configwin.h
> gs/cups/libs/cups/Dependencies
> gs/cups/libs/cups/Makefile
> gs/cups/libs/cups/adminutil.c
> gs/cups/libs/cups/adminutil.h
> gs/cups/libs/cups/api-array.header
> gs/cups/libs/cups/api-array.shtml
> gs/cups/libs/cups/api-cups.header
> gs/cups/libs/cups/api-cups.shtml
> gs/cups/libs/cups/api-filedir.header
> gs/cups/libs/cups/api-filedir.shtml
> gs/cups/libs/cups/api-filter.header
> gs/cups/libs/cups/api-filter.shtml
> gs/cups/libs/cups/api-httpipp.header
> gs/cups/libs/cups/api-httpipp.shtml
> gs/cups/libs/cups/api-overview.header
> gs/cups/libs/cups/api-overview.shtml
> gs/cups/libs/cups/api-ppd.header
> gs/cups/libs/cups/api-ppd.shtml
> gs/cups/libs/cups/array-private.h
> gs/cups/libs/cups/array.c
> gs/cups/libs/cups/array.h
> gs/cups/libs/cups/attr.c
> gs/cups/libs/cups/auth.c
> gs/cups/libs/cups/backchannel.c
> gs/cups/libs/cups/backend.c
> gs/cups/libs/cups/backend.h
> gs/cups/libs/cups/conflicts.c
> gs/cups/libs/cups/cups-private.h
> gs/cups/libs/cups/cups.h
> gs/cups/libs/cups/custom.c
> gs/cups/libs/cups/debug-private.h
> gs/cups/libs/cups/debug.c
> gs/cups/libs/cups/dest-job.c
> gs/cups/libs/cups/dest-localization.c
> gs/cups/libs/cups/dest-options.c
> gs/cups/libs/cups/dest.c
> gs/cups/libs/cups/dir.c
> gs/cups/libs/cups/dir.h
> gs/cups/libs/cups/emit.c
> gs/cups/libs/cups/encode.c
> gs/cups/libs/cups/file-private.h
> gs/cups/libs/cups/file.c
> gs/cups/libs/cups/file.h
> gs/cups/libs/cups/getdevices.c
> gs/cups/libs/cups/getifaddrs.c
> gs/cups/libs/cups/getputfile.c
> gs/cups/libs/cups/globals.c
> gs/cups/libs/cups/http-addr.c
> gs/cups/libs/cups/http-addrlist.c
> gs/cups/libs/cups/http-private.h
> gs/cups/libs/cups/http-support.c
> gs/cups/libs/cups/http.c
> gs/cups/libs/cups/http.h
> gs/cups/libs/cups/ipp-private.h
> gs/cups/libs/cups/ipp-support.c
> gs/cups/libs/cups/ipp.c
> gs/cups/libs/cups/ipp.h
> gs/cups/libs/cups/langprintf.c
> gs/cups/libs/cups/language-private.h
> gs/cups/libs/cups/language.c
> gs/cups/libs/cups/language.h
> gs/cups/libs/cups/libcups2.def
> gs/cups/libs/cups/libcups2.rc
> gs/cups/libs/cups/libcups_s.exp
> gs/cups/libs/cups/localize.c
> gs/cups/libs/cups/mark.c
> gs/cups/libs/cups/md5-private.h
> gs/cups/libs/cups/md5.c
> gs/cups/libs/cups/md5passwd.c
> gs/cups/libs/cups/notify.c
> gs/cups/libs/cups/options.c
> gs/cups/libs/cups/page.c
> gs/cups/libs/cups/ppd-cache.c
> gs/cups/libs/cups/ppd-private.h
> gs/cups/libs/cups/ppd.c
> gs/cups/libs/cups/ppd.h
> gs/cups/libs/cups/pwg-media.c
> gs/cups/libs/cups/pwg-private.h
> gs/cups/libs/cups/pwg.h
> gs/cups/libs/cups/raster-private.h
> gs/cups/libs/cups/raster.h
> gs/cups/libs/cups/request.c
> gs/cups/libs/cups/sidechannel.c
> gs/cups/libs/cups/sidechannel.h
> gs/cups/libs/cups/snmp-private.h
> gs/cups/libs/cups/snmp.c
> gs/cups/libs/cups/snprintf.c
> gs/cups/libs/cups/sspi-private.h
> gs/cups/libs/cups/sspi.c
> gs/cups/libs/cups/string-private.h
> gs/cups/libs/cups/string.c
> gs/cups/libs/cups/tempfile.c
> gs/cups/libs/cups/test.ppd
> gs/cups/libs/cups/test2.ppd
> gs/cups/libs/cups/testadmin.c
> gs/cups/libs/cups/testarray.c
> gs/cups/libs/cups/testconflicts.c
> gs/cups/libs/cups/testcups.c
> gs/cups/libs/cups/testfile.c
> gs/cups/libs/cups/testhttp.c
> gs/cups/libs/cups/testi18n.c
> gs/cups/libs/cups/testipp.c
> gs/cups/libs/cups/testlang.c
> gs/cups/libs/cups/testoptions.c
> gs/cups/libs/cups/testppd.c
> gs/cups/libs/cups/testpwg.c
> gs/cups/libs/cups/testsnmp.c
> gs/cups/libs/cups/thread-private.h
> gs/cups/libs/cups/thread.c
> gs/cups/libs/cups/transcode.c
> gs/cups/libs/cups/transcode.h
> gs/cups/libs/cups/usersys.c
> gs/cups/libs/cups/utf8demo.txt
> gs/cups/libs/cups/util.c
> gs/cups/libs/cups/versioning.h
> gs/cups/libs/filter/Dependencies
> gs/cups/libs/filter/Makefile
> gs/cups/libs/filter/api-raster.header
> gs/cups/libs/filter/api-raster.shtml
> gs/cups/libs/filter/commandtops.c
> gs/cups/libs/filter/common.c
> gs/cups/libs/filter/common.h
> gs/cups/libs/filter/error.c
> gs/cups/libs/filter/gziptoany.c
> gs/cups/libs/filter/interpret.c
> gs/cups/libs/filter/libcupsimage2.def
> gs/cups/libs/filter/libcupsimage_s.exp
> gs/cups/libs/filter/postscript-driver.header
> gs/cups/libs/filter/postscript-driver.shtml
> gs/cups/libs/filter/ppd-compiler.header
> gs/cups/libs/filter/ppd-compiler.shtml
> gs/cups/libs/filter/pstops.c
> gs/cups/libs/filter/raster-driver.header
> gs/cups/libs/filter/raster-driver.shtml
> gs/cups/libs/filter/raster.c
> gs/cups/libs/filter/rasterbench.c
> gs/cups/libs/filter/rastertoepson.c
> gs/cups/libs/filter/rastertohp.c
> gs/cups/libs/filter/rastertolabel.c
> gs/cups/libs/filter/rastertopwg.c
> gs/cups/libs/filter/spec-ppd.header
> gs/cups/libs/filter/spec-ppd.shtml
> gs/cups/libs/filter/testraster.c
> gs/devices/contrib.mak
> gs/devices/devs.mak
> gs/devices/gdev3852.c
> gs/devices/gdev3b1.c
> gs/devices/gdev4081.c
> gs/devices/gdev4693.c
> gs/devices/gdev8510.c
> gs/devices/gdev8bcm.c
> gs/devices/gdev8bcm.h
> gs/devices/gdevadmp.c
> gs/devices/gdevatx.c
> gs/devices/gdevbit.c
> gs/devices/gdevbj10.c
> gs/devices/gdevbjc.h
> gs/devices/gdevbjcl.c
> gs/devices/gdevbjcl.h
> gs/devices/gdevbmp.c
> gs/devices/gdevbmp.h
> gs/devices/gdevbmpa.c
> gs/devices/gdevbmpc.c
> gs/devices/gdevccr.c
> gs/devices/gdevcdj.c
> gs/devices/gdevcfax.c
> gs/devices/gdevcif.c
> gs/devices/gdevclj.c
> gs/devices/gdevcljc.c
> gs/devices/gdevcmykog.c
> gs/devices/gdevcp50.c
> gs/devices/gdevcslw.c
> gs/devices/gdevdfax.c
> gs/devices/gdevdjet.c
> gs/devices/gdevdjtc.c
> gs/devices/gdevdljm.c
> gs/devices/gdevdljm.h
> gs/devices/gdevdm24.c
> gs/devices/gdevdsp.c
> gs/devices/gdevdsp.h
> gs/devices/gdevdsp2.h
> gs/devices/gdevepsc.c
> gs/devices/gdevepsn.c
> gs/devices/gdevescp.c
> gs/devices/gdevevga.c
> gs/devices/gdevfax.c
> gs/devices/gdevfax.h
> gs/devices/gdevfpng.c
> gs/devices/gdevherc.c
> gs/devices/gdevhl7x.c
> gs/devices/gdevicov.c
> gs/devices/gdevifno.c
> gs/devices/gdevijs.c
> gs/devices/gdevimgn.c
> gs/devices/gdevjbig2.c
> gs/devices/gdevjpeg.c
> gs/devices/gdevjpx.c
> gs/devices/gdevl256.c
> gs/devices/gdevl31s.c
> gs/devices/gdevlbp8.c
> gs/devices/gdevlj56.c
> gs/devices/gdevlp8k.c
> gs/devices/gdevlxm.c
> gs/devices/gdevmac.c
> gs/devices/gdevmac.h
> gs/devices/gdevmacpictop.h
> gs/devices/gdevmacttf.h
> gs/devices/gdevmeds.c
> gs/devices/gdevmeds.h
> gs/devices/gdevmgr.c
> gs/devices/gdevmgr.h
> gs/devices/gdevmiff.c
> gs/devices/gdevmswn.c
> gs/devices/gdevmswn.h
> gs/devices/gdevmsxf.c
> gs/devices/gdevn533.c
> gs/devices/gdevo182.c
> gs/devices/gdevokii.c
> gs/devices/gdevos2p.c
> gs/devices/gdevp2up.c
> gs/devices/gdevpbm.c
> gs/devices/gdevpcfb.c
> gs/devices/gdevpcfb.h
> gs/devices/gdevpcl.c
> gs/devices/gdevpcl.h
> gs/devices/gdevpcx.c
> gs/devices/gdevpe.c
> gs/devices/gdevperm.c
> gs/devices/gdevphex.c
> gs/devices/gdevpjet.c
> gs/devices/gdevplan.c
> gs/devices/gdevplib.c
> gs/devices/gdevplib.h
> gs/devices/gdevpm.h
> gs/devices/gdevpng.c
> gs/devices/gdevpsd.c
> gs/devices/gdevpsim.c
> gs/devices/gdevpxut.c
> gs/devices/gdevpxut.h
> gs/devices/gdevrinkj.c
> gs/devices/gdevs3ga.c
> gs/devices/gdevsco.c
> gs/devices/gdevsgi.c
> gs/devices/gdevsgi.h
> gs/devices/gdevsj48.c
> gs/devices/gdevsnfb.c
> gs/devices/gdevsppr.c
> gs/devices/gdevstc.c
> gs/devices/gdevstc.h
> gs/devices/gdevstc1.c
> gs/devices/gdevstc2.c
> gs/devices/gdevstc3.c
> gs/devices/gdevstc4.c
> gs/devices/gdevsun.c
> gs/devices/gdevsunr.c
> gs/devices/gdevsvga.c
> gs/devices/gdevsvga.h
> gs/devices/gdevtfax.c
> gs/devices/gdevtfax.h
> gs/devices/gdevtfnx.c
> gs/devices/gdevtifs.c
> gs/devices/gdevtifs.h
> gs/devices/gdevtknk.c
> gs/devices/gdevtrac.c
> gs/devices/gdevtsep.c
> gs/devices/gdevupd.c
> gs/devices/gdevvglb.c
> gs/devices/gdevwddb.c
> gs/devices/gdevwdib.c
> gs/devices/gdevwpr2.c
> gs/devices/gdevwprn.c
> gs/devices/gdevx.c
> gs/devices/gdevx.h
> gs/devices/gdevxalt.c
> gs/devices/gdevxcf.c
> gs/devices/gdevxcmp.c
> gs/devices/gdevxcmp.h
> gs/devices/gdevxini.c
> gs/devices/gdevxres.c
> gs/devices/gxfcopy.c
> gs/devices/gxfcopy.h
> gs/devices/minftrsz.c
> gs/devices/minftrsz.h
> gs/devices/rinkj/evenbetter-rll.c
> gs/devices/rinkj/evenbetter-rll.h
> gs/devices/rinkj/rinkj-byte-stream.c
> gs/devices/rinkj/rinkj-byte-stream.h
> gs/devices/rinkj/rinkj-config.c
> gs/devices/rinkj/rinkj-config.h
> gs/devices/rinkj/rinkj-device.c
> gs/devices/rinkj/rinkj-device.h
> gs/devices/rinkj/rinkj-dither.c
> gs/devices/rinkj/rinkj-dither.h
> gs/devices/rinkj/rinkj-epson870.c
> gs/devices/rinkj/rinkj-epson870.h
> gs/devices/rinkj/rinkj-screen-eb.c
> gs/devices/rinkj/rinkj-screen-eb.h
> gs/devices/vector/gdevagl.c
> gs/devices/vector/gdevagl.h
> gs/devices/vector/gdevpdf.c
> gs/devices/vector/gdevpdfb.c
> gs/devices/vector/gdevpdfb.h
> gs/devices/vector/gdevpdfc.c
> gs/devices/vector/gdevpdfc.h
> gs/devices/vector/gdevpdfd.c
> gs/devices/vector/gdevpdfe.c
> gs/devices/vector/gdevpdfg.c
> gs/devices/vector/gdevpdfg.h
> gs/devices/vector/gdevpdfi.c
> gs/devices/vector/gdevpdfj.c
> gs/devices/vector/gdevpdfk.c
> gs/devices/vector/gdevpdfm.c
> gs/devices/vector/gdevpdfo.c
> gs/devices/vector/gdevpdfo.h
> gs/devices/vector/gdevpdfp.c
> gs/devices/vector/gdevpdfr.c
> gs/devices/vector/gdevpdft.c
> gs/devices/vector/gdevpdfu.c
> gs/devices/vector/gdevpdfv.c
> gs/devices/vector/gdevpdfx.h
> gs/devices/vector/gdevpdt.c
> gs/devices/vector/gdevpdt.h
> gs/devices/vector/gdevpdtb.c
> gs/devices/vector/gdevpdtb.h
> gs/devices/vector/gdevpdtc.c
> gs/devices/vector/gdevpdtd.c
> gs/devices/vector/gdevpdtd.h
> gs/devices/vector/gdevpdte.c
> gs/devices/vector/gdevpdtf.c
> gs/devices/vector/gdevpdtf.h
> gs/devices/vector/gdevpdti.c
> gs/devices/vector/gdevpdti.h
> gs/devices/vector/gdevpdts.c
> gs/devices/vector/gdevpdts.h
> gs/devices/vector/gdevpdtt.c
> gs/devices/vector/gdevpdtt.h
> gs/devices/vector/gdevpdtv.c
> gs/devices/vector/gdevpdtv.h
> gs/devices/vector/gdevpdtw.c
> gs/devices/vector/gdevpdtw.h
> gs/devices/vector/gdevpdtx.h
> gs/devices/vector/gdevpsdf.h
> gs/devices/vector/gdevpsdi.c
> gs/devices/vector/gdevpsdp.c
> gs/devices/vector/gdevpsds.c
> gs/devices/vector/gdevpsds.h
> gs/devices/vector/gdevpsdu.c
> gs/devices/vector/gdevpsf.h
> gs/devices/vector/gdevpsf1.c
> gs/devices/vector/gdevpsf2.c
> gs/devices/vector/gdevpsfm.c
> gs/devices/vector/gdevpsft.c
> gs/devices/vector/gdevpsfu.c
> gs/devices/vector/gdevpsfx.c
> gs/devices/vector/gdevpsu.c
> gs/devices/vector/gdevpsu.h
> gs/devices/vector/gdevpx.c
> gs/devices/vector/gdevtxtw.c
> gs/devices/vector/gdevxps.c
> gs/devices/vector/opdfread.h
> gs/devices/vector/whitelst.c
> gs/devices/vector/whitelst.h
> gs/doc/API.htm
> gs/doc/AUTHORS
> gs/doc/C-style.htm
> gs/doc/COPYING
> gs/doc/Changes.htm
> gs/doc/Commprod.htm
> gs/doc/DLL.htm
> gs/doc/Deprecated.htm
> gs/doc/Details.htm
> gs/doc/Details8.htm
> gs/doc/Details9.htm
> gs/doc/Develop.htm
> gs/doc/Devices.htm
> gs/doc/Drivers.htm
> gs/doc/Fonts.htm
> gs/doc/GS9_Color_Management.pdf
> gs/doc/GS9_Color_Management.tex
> gs/doc/Helpers.htm
> gs/doc/Hershey.htm
> gs/doc/History1.htm
> gs/doc/History2.htm
> gs/doc/History3.htm
> gs/doc/History4.htm
> gs/doc/History5.htm
> gs/doc/History6.htm
> gs/doc/History7.htm
> gs/doc/History8.htm
> gs/doc/History9.htm
> gs/doc/Install.htm
> gs/doc/Issues.htm
> gs/doc/Language.htm
> gs/doc/Lib.htm
> gs/doc/Make.htm
> gs/doc/News.htm
> gs/doc/Projects.htm
> gs/doc/Ps-style.htm
> gs/doc/Ps2epsi.htm
> gs/doc/Ps2pdf.htm
> gs/doc/Ps2ps2.htm
> gs/doc/Psfiles.htm
> gs/doc/Readme.htm
> gs/doc/Release.htm
> gs/doc/SavedPages.htm
> gs/doc/Source.htm
> gs/doc/Unix-lpr.htm
> gs/doc/Use.htm
> gs/doc/WhatIsGS.htm
> gs/doc/Xfonts.htm
> gs/doc/gs-vms.hlp
> gs/doc/gs.css
> gs/doc/gsdoc.el
> gs/doc/index.html
> gs/doc/pscet_status.txt
> gs/doc/subclass.htm
> gs/doc/thirdparty.htm
> gs/examples/alphabet.ps
> gs/examples/annots.pdf
> gs/examples/chess.ps
> gs/examples/cjk/all_ac1.ps
> gs/examples/cjk/all_ag1.ps
> gs/examples/cjk/all_aj1.ps
> gs/examples/cjk/all_aj2.ps
> gs/examples/cjk/all_ak1.ps
> gs/examples/cjk/article9.ps
> gs/examples/cjk/gscjk_ac.ps
> gs/examples/cjk/gscjk_ag.ps
> gs/examples/cjk/gscjk_aj.ps
> gs/examples/cjk/gscjk_ak.ps
> gs/examples/cjk/iso2022.ps
> gs/examples/cjk/iso2022v.ps
> gs/examples/colorcir.ps
> gs/examples/doretree.ps
> gs/examples/escher.ps
> gs/examples/golfer.eps
> gs/examples/grayalph.ps
> gs/examples/ridt91.eps
> gs/examples/snowflak.ps
> gs/examples/text_graph_image_cmyk_rgb.pdf
> gs/examples/text_graphic_image.pdf
> gs/examples/tiger.eps
> gs/examples/transparency_example.ps
> gs/examples/vasarely.ps
> gs/examples/waterfal.ps
> gs/expat/COPYING
> gs/expat/Changes
> gs/expat/MANIFEST
> gs/expat/Makefile.in
> gs/expat/README
> gs/expat/amiga/Makefile
> gs/expat/amiga/README.txt
> gs/expat/amiga/expat.xml
> gs/expat/amiga/expat_lib.c
> gs/expat/amiga/expat_vectors.c
> gs/expat/amiga/include/inline4/expat.h
> gs/expat/amiga/include/interfaces/expat.h
> gs/expat/amiga/include/libraries/expat.h
> gs/expat/amiga/include/proto/expat.h
> gs/expat/amiga/launch.c
> gs/expat/amiga/stdlib.c
> gs/expat/bcb5/README.txt
> gs/expat/bcb5/all_projects.bpg
> gs/expat/bcb5/elements.bpf
> gs/expat/bcb5/elements.bpr
> gs/expat/bcb5/elements.mak
> gs/expat/bcb5/expat.bpf
> gs/expat/bcb5/expat.bpr
> gs/expat/bcb5/expat.mak
> gs/expat/bcb5/expat_static.bpf
> gs/expat/bcb5/expat_static.bpr
> gs/expat/bcb5/expat_static.mak
> gs/expat/bcb5/expatw.bpf
> gs/expat/bcb5/expatw.bpr
> gs/expat/bcb5/expatw.mak
> gs/expat/bcb5/expatw_static.bpf
> gs/expat/bcb5/expatw_static.bpr
> gs/expat/bcb5/expatw_static.mak
> gs/expat/bcb5/libexpat_mtd.def
> gs/expat/bcb5/libexpatw_mtd.def
> gs/expat/bcb5/makefile.mak
> gs/expat/bcb5/outline.bpf
> gs/expat/bcb5/outline.bpr
> gs/expat/bcb5/outline.mak
> gs/expat/bcb5/setup.bat
> gs/expat/bcb5/xmlwf.bpf
> gs/expat/bcb5/xmlwf.bpr
> gs/expat/bcb5/xmlwf.mak
> gs/expat/configure
> gs/expat/configure.in
> gs/expat/conftools/PrintPath
> gs/expat/conftools/ac_c_bigendian_cross.m4
> gs/expat/conftools/config.guess
> gs/expat/conftools/config.sub
> gs/expat/conftools/expat.m4
> gs/expat/conftools/get-version.sh
> gs/expat/conftools/install-sh
> gs/expat/conftools/libtool.m4
> gs/expat/conftools/ltmain.sh
> gs/expat/conftools/mkinstalldirs
> gs/expat/doc/expat.png
> gs/expat/doc/reference.html
> gs/expat/doc/style.css
> gs/expat/doc/valid-xhtml10.png
> gs/expat/doc/xmlwf.1
> gs/expat/doc/xmlwf.sgml
> gs/expat/examples/elements.c
> gs/expat/examples/elements.dsp
> gs/expat/examples/outline.c
> gs/expat/examples/outline.dsp
> gs/expat/expat.dsw
> gs/expat/expat_config.h.in
> gs/expat/lib/Makefile.MPW
> gs/expat/lib/amigaconfig.h
> gs/expat/lib/ascii.h
> gs/expat/lib/asciitab.h
> gs/expat/lib/expat.dsp
> gs/expat/lib/expat.h
> gs/expat/lib/expat_external.h
> gs/expat/lib/expat_static.dsp
> gs/expat/lib/expatw.dsp
> gs/expat/lib/expatw_static.dsp
> gs/expat/lib/iasciitab.h
> gs/expat/lib/internal.h
> gs/expat/lib/latin1tab.h
> gs/expat/lib/libexpat.def
> gs/expat/lib/libexpatw.def
> gs/expat/lib/macconfig.h
> gs/expat/lib/nametab.h
> gs/expat/lib/utf8tab.h
> gs/expat/lib/winconfig.h
> gs/expat/lib/xmlparse.c
> gs/expat/lib/xmlrole.c
> gs/expat/lib/xmlrole.h
> gs/expat/lib/xmltok.c
> gs/expat/lib/xmltok.h
> gs/expat/lib/xmltok_impl.c
> gs/expat/lib/xmltok_impl.h
> gs/expat/lib/xmltok_ns.c
> gs/expat/tests/README.txt
> gs/expat/tests/benchmark/README.txt
> gs/expat/tests/benchmark/benchmark.c
> gs/expat/tests/benchmark/benchmark.dsp
> gs/expat/tests/benchmark/benchmark.dsw
> gs/expat/tests/chardata.c
> gs/expat/tests/chardata.h
> gs/expat/tests/minicheck.c
> gs/expat/tests/minicheck.h
> gs/expat/tests/runtests.c
> gs/expat/tests/runtestspp.cpp
> gs/expat/tests/xmltest.sh
> gs/expat/vms/README.vms
> gs/expat/vms/descrip.mms
> gs/expat/vms/expat_config.h
> gs/expat/win32/MANIFEST.txt
> gs/expat/win32/README.txt
> gs/expat/win32/expat.iss
> gs/expat/xmlwf/codepage.c
> gs/expat/xmlwf/codepage.h
> gs/expat/xmlwf/ct.c
> gs/expat/xmlwf/filemap.h
> gs/expat/xmlwf/readfilemap.c
> gs/expat/xmlwf/unixfilemap.c
> gs/expat/xmlwf/win32filemap.c
> gs/expat/xmlwf/xmlfile.c
> gs/expat/xmlwf/xmlfile.h
> gs/expat/xmlwf/xmlmime.c
> gs/expat/xmlwf/xmlmime.h
> gs/expat/xmlwf/xmltchar.h
> gs/expat/xmlwf/xmlurl.h
> gs/expat/xmlwf/xmlwf.c
> gs/expat/xmlwf/xmlwf.dsp
> gs/expat/xmlwf/xmlwin32url.cxx
> gs/freetype/CMakeLists.txt
> gs/freetype/ChangeLog
> gs/freetype/ChangeLog.20
> gs/freetype/ChangeLog.21
> gs/freetype/ChangeLog.22
> gs/freetype/ChangeLog.23
> gs/freetype/ChangeLog.24
> gs/freetype/Jamfile
> gs/freetype/Jamrules
> gs/freetype/Makefile
> gs/freetype/README
> gs/freetype/README.git
> gs/freetype/autogen.sh
> gs/freetype/builds/amiga/README
> gs/freetype/builds/amiga/include/config/ftconfig.h
> gs/freetype/builds/amiga/include/config/ftmodule.h
> gs/freetype/builds/amiga/makefile
> gs/freetype/builds/amiga/makefile.os4
> gs/freetype/builds/amiga/smakefile
> gs/freetype/builds/amiga/src/base/ftdebug.c
> gs/freetype/builds/amiga/src/base/ftsystem.c
> gs/freetype/builds/ansi/ansi-def.mk
> gs/freetype/builds/ansi/ansi.mk
> gs/freetype/builds/atari/ATARI.H
> gs/freetype/builds/atari/FNames.SIC
> gs/freetype/builds/atari/FREETYPE.PRJ
> gs/freetype/builds/atari/README.TXT
> gs/freetype/builds/atari/deflinejoiner.awk
> gs/freetype/builds/atari/gen-purec-patch.sh
> gs/freetype/builds/beos/beos-def.mk
> gs/freetype/builds/beos/beos.mk
> gs/freetype/builds/beos/detect.mk
> gs/freetype/builds/cmake/iOS.cmake
> gs/freetype/builds/compiler/ansi-cc.mk
> gs/freetype/builds/compiler/bcc-dev.mk
> gs/freetype/builds/compiler/bcc.mk
> gs/freetype/builds/compiler/emx.mk
> gs/freetype/builds/compiler/gcc-dev.mk
> gs/freetype/builds/compiler/gcc.mk
> gs/freetype/builds/compiler/intelc.mk
> gs/freetype/builds/compiler/unix-lcc.mk
> gs/freetype/builds/compiler/visualage.mk
> gs/freetype/builds/compiler/visualc.mk
> gs/freetype/builds/compiler/watcom.mk
> gs/freetype/builds/compiler/win-lcc.mk
> gs/freetype/builds/detect.mk
> gs/freetype/builds/dos/detect.mk
> gs/freetype/builds/dos/dos-def.mk
> gs/freetype/builds/dos/dos-emx.mk
> gs/freetype/builds/dos/dos-gcc.mk
> gs/freetype/builds/dos/dos-wat.mk
> gs/freetype/builds/exports.mk
> gs/freetype/builds/freetype.mk
> gs/freetype/builds/link_dos.mk
> gs/freetype/builds/link_std.mk
> gs/freetype/builds/mac/FreeType.m68k_cfm.make.txt
> gs/freetype/builds/mac/FreeType.m68k_far.make.txt
> gs/freetype/builds/mac/FreeType.ppc_carbon.make.txt
> gs/freetype/builds/mac/FreeType.ppc_classic.make.txt
> gs/freetype/builds/mac/README
> gs/freetype/builds/mac/ascii2mpw.py
> gs/freetype/builds/mac/freetype-Info.plist
> gs/freetype/builds/mac/ftlib.prj.xml
> gs/freetype/builds/mac/ftmac.c
> gs/freetype/builds/modules.mk
> gs/freetype/builds/newline
> gs/freetype/builds/os2/detect.mk
> gs/freetype/builds/os2/os2-def.mk
> gs/freetype/builds/os2/os2-dev.mk
> gs/freetype/builds/os2/os2-gcc.mk
> gs/freetype/builds/symbian/bld.inf
> gs/freetype/builds/symbian/freetype.mmp
> gs/freetype/builds/toplevel.mk
> gs/freetype/builds/unix/aclocal.m4
> gs/freetype/builds/unix/config.guess
> gs/freetype/builds/unix/config.sub
> gs/freetype/builds/unix/configure.ac
> gs/freetype/builds/unix/configure.raw
> gs/freetype/builds/unix/detect.mk
> gs/freetype/builds/unix/freetype-config.in
> gs/freetype/builds/unix/freetype2.in
> gs/freetype/builds/unix/freetype2.m4
> gs/freetype/builds/unix/ft-munmap.m4
> gs/freetype/builds/unix/ftconfig.in
> gs/freetype/builds/unix/ftsystem.c
> gs/freetype/builds/unix/install-sh
> gs/freetype/builds/unix/install.mk
> gs/freetype/builds/unix/ltmain.sh
> gs/freetype/builds/unix/mkinstalldirs
> gs/freetype/builds/unix/pkg.m4
> gs/freetype/builds/unix/unix-cc.in
> gs/freetype/builds/unix/unix-def.in
> gs/freetype/builds/unix/unix-dev.mk
> gs/freetype/builds/unix/unix-lcc.mk
> gs/freetype/builds/unix/unix.mk
> gs/freetype/builds/unix/unixddef.mk
> gs/freetype/builds/vms/ftconfig.h
> gs/freetype/builds/vms/ftsystem.c
> gs/freetype/builds/wince/ftdebug.c
> gs/freetype/builds/wince/vc2005-ce/freetype.sln
> gs/freetype/builds/wince/vc2005-ce/freetype.vcproj
> gs/freetype/builds/wince/vc2005-ce/index.html
> gs/freetype/builds/wince/vc2008-ce/freetype.sln
> gs/freetype/builds/wince/vc2008-ce/freetype.vcproj
> gs/freetype/builds/wince/vc2008-ce/index.html
> gs/freetype/builds/windows/detect.mk
> gs/freetype/builds/windows/ftdebug.c
> gs/freetype/builds/windows/vc2005/freetype.sln
> gs/freetype/builds/windows/vc2005/freetype.vcproj
> gs/freetype/builds/windows/vc2005/index.html
> gs/freetype/builds/windows/vc2008/freetype.sln
> gs/freetype/builds/windows/vc2008/freetype.vcproj
> gs/freetype/builds/windows/vc2008/index.html
> gs/freetype/builds/windows/vc2010/freetype.sln
> gs/freetype/builds/windows/vc2010/freetype.user.props
> gs/freetype/builds/windows/vc2010/freetype.vcxproj
> gs/freetype/builds/windows/vc2010/freetype.vcxproj.filters
> gs/freetype/builds/windows/vc2010/index.html
> gs/freetype/builds/windows/visualc/freetype.dsp
> gs/freetype/builds/windows/visualc/freetype.dsw
> gs/freetype/builds/windows/visualc/freetype.sln
> gs/freetype/builds/windows/visualc/freetype.vcproj
> gs/freetype/builds/windows/visualc/index.html
> gs/freetype/builds/windows/visualce/freetype.dsp
> gs/freetype/builds/windows/visualce/freetype.dsw
> gs/freetype/builds/windows/visualce/freetype.vcproj
> gs/freetype/builds/windows/visualce/index.html
> gs/freetype/builds/windows/w32-bcc.mk
> gs/freetype/builds/windows/w32-bccd.mk
> gs/freetype/builds/windows/w32-dev.mk
> gs/freetype/builds/windows/w32-gcc.mk
> gs/freetype/builds/windows/w32-icc.mk
> gs/freetype/builds/windows/w32-intl.mk
> gs/freetype/builds/windows/w32-lcc.mk
> gs/freetype/builds/windows/w32-mingw32.mk
> gs/freetype/builds/windows/w32-vcc.mk
> gs/freetype/builds/windows/w32-wat.mk
> gs/freetype/builds/windows/win32-def.mk
> gs/freetype/configure
> gs/freetype/devel/ft2build.h
> gs/freetype/devel/ftoption.h
> gs/freetype/docs/CHANGES
> gs/freetype/docs/CMAKE
> gs/freetype/docs/CUSTOMIZE
> gs/freetype/docs/DEBUG
> gs/freetype/docs/FTL.TXT
> gs/freetype/docs/GPLv2.TXT
> gs/freetype/docs/INSTALL
> gs/freetype/docs/INSTALL.ANY
> gs/freetype/docs/INSTALL.CROSS
> gs/freetype/docs/INSTALL.GNU
> gs/freetype/docs/INSTALL.MAC
> gs/freetype/docs/INSTALL.UNIX
> gs/freetype/docs/INSTALL.VMS
> gs/freetype/docs/LICENSE.TXT
> gs/freetype/docs/MAKEPP
> gs/freetype/docs/PROBLEMS
> gs/freetype/docs/TODO
> gs/freetype/docs/VERSION.DLL
> gs/freetype/docs/formats.txt
> gs/freetype/docs/freetype-config.1
> gs/freetype/docs/raster.txt
> gs/freetype/docs/reference/README
> gs/freetype/docs/reference/ft2-auto_hinter.html
> gs/freetype/docs/reference/ft2-base_interface.html
> gs/freetype/docs/reference/ft2-basic_types.html
> gs/freetype/docs/reference/ft2-bdf_fonts.html
> gs/freetype/docs/reference/ft2-bitmap_handling.html
> gs/freetype/docs/reference/ft2-bzip2.html
> gs/freetype/docs/reference/ft2-cache_subsystem.html
> gs/freetype/docs/reference/ft2-cff_driver.html
> gs/freetype/docs/reference/ft2-cid_fonts.html
> gs/freetype/docs/reference/ft2-computations.html
> gs/freetype/docs/reference/ft2-font_formats.html
> gs/freetype/docs/reference/ft2-gasp_table.html
> gs/freetype/docs/reference/ft2-glyph_management.html
> gs/freetype/docs/reference/ft2-glyph_stroker.html
> gs/freetype/docs/reference/ft2-glyph_variants.html
> gs/freetype/docs/reference/ft2-gx_validation.html
> gs/freetype/docs/reference/ft2-gzip.html
> gs/freetype/docs/reference/ft2-header_file_macros.html
> gs/freetype/docs/reference/ft2-header_inclusion.html
> gs/freetype/docs/reference/ft2-incremental.html
> gs/freetype/docs/reference/ft2-index.html
> gs/freetype/docs/reference/ft2-lcd_filtering.html
> gs/freetype/docs/reference/ft2-list_processing.html
> gs/freetype/docs/reference/ft2-lzw.html
> gs/freetype/docs/reference/ft2-mac_specific.html
> gs/freetype/docs/reference/ft2-module_management.html
> gs/freetype/docs/reference/ft2-multiple_masters.html
> gs/freetype/docs/reference/ft2-ot_validation.html
> gs/freetype/docs/reference/ft2-outline_processing.html
> gs/freetype/docs/reference/ft2-pfr_fonts.html
> gs/freetype/docs/reference/ft2-quick_advance.html
> gs/freetype/docs/reference/ft2-raster.html
> gs/freetype/docs/reference/ft2-sfnt_names.html
> gs/freetype/docs/reference/ft2-sizes_management.html
> gs/freetype/docs/reference/ft2-system_interface.html
> gs/freetype/docs/reference/ft2-toc.html
> gs/freetype/docs/reference/ft2-truetype_engine.html
> gs/freetype/docs/reference/ft2-truetype_tables.html
> gs/freetype/docs/reference/ft2-tt_driver.html
> gs/freetype/docs/reference/ft2-type1_tables.html
> gs/freetype/docs/reference/ft2-user_allocation.html
> gs/freetype/docs/reference/ft2-version.html
> gs/freetype/docs/reference/ft2-winfnt_fonts.html
> gs/freetype/docs/release
> gs/freetype/include/config/ftconfig.h
> gs/freetype/include/config/ftheader.h
> gs/freetype/include/config/ftmodule.h
> gs/freetype/include/config/ftoption.h
> gs/freetype/include/config/ftstdlib.h
> gs/freetype/include/freetype.h
> gs/freetype/include/ft2build.h
> gs/freetype/include/ftadvanc.h
> gs/freetype/include/ftautoh.h
> gs/freetype/include/ftbbox.h
> gs/freetype/include/ftbdf.h
> gs/freetype/include/ftbitmap.h
> gs/freetype/include/ftbzip2.h
> gs/freetype/include/ftcache.h
> gs/freetype/include/ftcffdrv.h
> gs/freetype/include/ftchapters.h
> gs/freetype/include/ftcid.h
> gs/freetype/include/fterrdef.h
> gs/freetype/include/fterrors.h
> gs/freetype/include/ftgasp.h
> gs/freetype/include/ftglyph.h
> gs/freetype/include/ftgxval.h
> gs/freetype/include/ftgzip.h
> gs/freetype/include/ftimage.h
> gs/freetype/include/ftincrem.h
> gs/freetype/include/ftlcdfil.h
> gs/freetype/include/ftlist.h
> gs/freetype/include/ftlzw.h
> gs/freetype/include/ftmac.h
> gs/freetype/include/ftmm.h
> gs/freetype/include/ftmodapi.h
> gs/freetype/include/ftmoderr.h
> gs/freetype/include/ftotval.h
> gs/freetype/include/ftoutln.h
> gs/freetype/include/ftpfr.h
> gs/freetype/include/ftrender.h
> gs/freetype/include/ftsizes.h
> gs/freetype/include/ftsnames.h
> gs/freetype/include/ftstroke.h
> gs/freetype/include/ftsynth.h
> gs/freetype/include/ftsystem.h
> gs/freetype/include/fttrigon.h
> gs/freetype/include/ftttdrv.h
> gs/freetype/include/fttypes.h
> gs/freetype/include/ftwinfnt.h
> gs/freetype/include/ftxf86.h
> gs/freetype/include/internal/autohint.h
> gs/freetype/include/internal/ftcalc.h
> gs/freetype/include/internal/ftdebug.h
> gs/freetype/include/internal/ftdriver.h
> gs/freetype/include/internal/ftgloadr.h
> gs/freetype/include/internal/ftmemory.h
> gs/freetype/include/internal/ftobjs.h
> gs/freetype/include/internal/ftpic.h
> gs/freetype/include/internal/ftrfork.h
> gs/freetype/include/internal/ftserv.h
> gs/freetype/include/internal/ftstream.h
> gs/freetype/include/internal/fttrace.h
> gs/freetype/include/internal/ftvalid.h
> gs/freetype/include/internal/internal.h
> gs/freetype/include/internal/psaux.h
> gs/freetype/include/internal/pshints.h
> gs/freetype/include/internal/services/svbdf.h
> gs/freetype/include/internal/services/svcid.h
> gs/freetype/include/internal/services/svgldict.h
> gs/freetype/include/internal/services/svgxval.h
> gs/freetype/include/internal/services/svkern.h
> gs/freetype/include/internal/services/svmm.h
> gs/freetype/include/internal/services/svotval.h
> gs/freetype/include/internal/services/svpfr.h
> gs/freetype/include/internal/services/svpostnm.h
> gs/freetype/include/internal/services/svprop.h
> gs/freetype/include/internal/services/svpscmap.h
> gs/freetype/include/internal/services/svpsinfo.h
> gs/freetype/include/internal/services/svsfnt.h
> gs/freetype/include/internal/services/svttcmap.h
> gs/freetype/include/internal/services/svtteng.h
> gs/freetype/include/internal/services/svttglyf.h
> gs/freetype/include/internal/services/svwinfnt.h
> gs/freetype/include/internal/services/svxf86nm.h
> gs/freetype/include/internal/sfnt.h
> gs/freetype/include/internal/t1types.h
> gs/freetype/include/internal/tttypes.h
> gs/freetype/include/t1tables.h
> gs/freetype/include/ttnameid.h
> gs/freetype/include/tttables.h
> gs/freetype/include/tttags.h
> gs/freetype/include/ttunpat.h
> gs/freetype/modules.cfg
> gs/freetype/objs/README
> gs/freetype/src/Jamfile
> gs/freetype/src/autofit/Jamfile
> gs/freetype/src/autofit/afangles.c
> gs/freetype/src/autofit/afangles.h
> gs/freetype/src/autofit/afblue.c
> gs/freetype/src/autofit/afblue.cin
> gs/freetype/src/autofit/afblue.dat
> gs/freetype/src/autofit/afblue.h
> gs/freetype/src/autofit/afblue.hin
> gs/freetype/src/autofit/afcjk.c
> gs/freetype/src/autofit/afcjk.h
> gs/freetype/src/autofit/afcover.h
> gs/freetype/src/autofit/afdummy.c
> gs/freetype/src/autofit/afdummy.h
> gs/freetype/src/autofit/aferrors.h
> gs/freetype/src/autofit/afglobal.c
> gs/freetype/src/autofit/afglobal.h
> gs/freetype/src/autofit/afhints.c
> gs/freetype/src/autofit/afhints.h
> gs/freetype/src/autofit/afindic.c
> gs/freetype/src/autofit/afindic.h
> gs/freetype/src/autofit/aflatin.c
> gs/freetype/src/autofit/aflatin.h
> gs/freetype/src/autofit/aflatin2.c
> gs/freetype/src/autofit/aflatin2.h
> gs/freetype/src/autofit/afloader.c
> gs/freetype/src/autofit/afloader.h
> gs/freetype/src/autofit/afmodule.c
> gs/freetype/src/autofit/afmodule.h
> gs/freetype/src/autofit/afpic.c
> gs/freetype/src/autofit/afpic.h
> gs/freetype/src/autofit/afranges.c
> gs/freetype/src/autofit/afranges.h
> gs/freetype/src/autofit/afscript.h
> gs/freetype/src/autofit/afstyles.h
> gs/freetype/src/autofit/aftypes.h
> gs/freetype/src/autofit/afwarp.c
> gs/freetype/src/autofit/afwarp.h
> gs/freetype/src/autofit/afwrtsys.h
> gs/freetype/src/autofit/autofit.c
> gs/freetype/src/autofit/hbshim.c
> gs/freetype/src/autofit/hbshim.h
> gs/freetype/src/autofit/module.mk
> gs/freetype/src/autofit/rules.mk
> gs/freetype/src/base/Jamfile
> gs/freetype/src/base/basepic.c
> gs/freetype/src/base/basepic.h
> gs/freetype/src/base/ftadvanc.c
> gs/freetype/src/base/ftapi.c
> gs/freetype/src/base/ftbase.c
> gs/freetype/src/base/ftbase.h
> gs/freetype/src/base/ftbbox.c
> gs/freetype/src/base/ftbdf.c
> gs/freetype/src/base/ftbitmap.c
> gs/freetype/src/base/ftcalc.c
> gs/freetype/src/base/ftcid.c
> gs/freetype/src/base/ftdbgmem.c
> gs/freetype/src/base/ftdebug.c
> gs/freetype/src/base/ftfstype.c
> gs/freetype/src/base/ftgasp.c
> gs/freetype/src/base/ftgloadr.c
> gs/freetype/src/base/ftglyph.c
> gs/freetype/src/base/ftgxval.c
> gs/freetype/src/base/ftinit.c
> gs/freetype/src/base/ftlcdfil.c
> gs/freetype/src/base/ftmac.c
> gs/freetype/src/base/ftmm.c
> gs/freetype/src/base/ftobjs.c
> gs/freetype/src/base/ftotval.c
> gs/freetype/src/base/ftoutln.c
> gs/freetype/src/base/ftpatent.c
> gs/freetype/src/base/ftpfr.c
> gs/freetype/src/base/ftpic.c
> gs/freetype/src/base/ftrfork.c
> gs/freetype/src/base/ftsnames.c
> gs/freetype/src/base/ftstream.c
> gs/freetype/src/base/ftstroke.c
> gs/freetype/src/base/ftsynth.c
> gs/freetype/src/base/ftsystem.c
> gs/freetype/src/base/fttrigon.c
> gs/freetype/src/base/fttype1.c
> gs/freetype/src/base/ftutil.c
> gs/freetype/src/base/ftwinfnt.c
> gs/freetype/src/base/ftxf86.c
> gs/freetype/src/base/md5.c
> gs/freetype/src/base/md5.h
> gs/freetype/src/base/rules.mk
> gs/freetype/src/bdf/Jamfile
> gs/freetype/src/bdf/README
> gs/freetype/src/bdf/bdf.c
> gs/freetype/src/bdf/bdf.h
> gs/freetype/src/bdf/bdfdrivr.c
> gs/freetype/src/bdf/bdfdrivr.h
> gs/freetype/src/bdf/bdferror.h
> gs/freetype/src/bdf/bdflib.c
> gs/freetype/src/bdf/module.mk
> gs/freetype/src/bdf/rules.mk
> gs/freetype/src/bzip2/Jamfile
> gs/freetype/src/bzip2/ftbzip2.c
> gs/freetype/src/bzip2/rules.mk
> gs/freetype/src/cache/Jamfile
> gs/freetype/src/cache/ftcache.c
> gs/freetype/src/cache/ftcbasic.c
> gs/freetype/src/cache/ftccache.c
> gs/freetype/src/cache/ftccache.h
> gs/freetype/src/cache/ftccback.h
> gs/freetype/src/cache/ftccmap.c
> gs/freetype/src/cache/ftcerror.h
> gs/freetype/src/cache/ftcglyph.c
> gs/freetype/src/cache/ftcglyph.h
> gs/freetype/src/cache/ftcimage.c
> gs/freetype/src/cache/ftcimage.h
> gs/freetype/src/cache/ftcmanag.c
> gs/freetype/src/cache/ftcmanag.h
> gs/freetype/src/cache/ftcmru.c
> gs/freetype/src/cache/ftcmru.h
> gs/freetype/src/cache/ftcsbits.c
> gs/freetype/src/cache/ftcsbits.h
> gs/freetype/src/cache/rules.mk
> gs/freetype/src/cff/Jamfile
> gs/freetype/src/cff/cf2arrst.c
> gs/freetype/src/cff/cf2arrst.h
> gs/freetype/src/cff/cf2blues.c
> gs/freetype/src/cff/cf2blues.h
> gs/freetype/src/cff/cf2error.c
> gs/freetype/src/cff/cf2error.h
> gs/freetype/src/cff/cf2fixed.h
> gs/freetype/src/cff/cf2font.c
> gs/freetype/src/cff/cf2font.h
> gs/freetype/src/cff/cf2ft.c
> gs/freetype/src/cff/cf2ft.h
> gs/freetype/src/cff/cf2glue.h
> gs/freetype/src/cff/cf2hints.c
> gs/freetype/src/cff/cf2hints.h
> gs/freetype/src/cff/cf2intrp.c
> gs/freetype/src/cff/cf2intrp.h
> gs/freetype/src/cff/cf2read.c
> gs/freetype/src/cff/cf2read.h
> gs/freetype/src/cff/cf2stack.c
> gs/freetype/src/cff/cf2stack.h
> gs/freetype/src/cff/cf2types.h
> gs/freetype/src/cff/cff.c
> gs/freetype/src/cff/cffcmap.c
> gs/freetype/src/cff/cffcmap.h
> gs/freetype/src/cff/cffdrivr.c
> gs/freetype/src/cff/cffdrivr.h
> gs/freetype/src/cff/cfferrs.h
> gs/freetype/src/cff/cffgload.c
> gs/freetype/src/cff/cffgload.h
> gs/freetype/src/cff/cffload.c
> gs/freetype/src/cff/cffload.h
> gs/freetype/src/cff/cffobjs.c
> gs/freetype/src/cff/cffobjs.h
> gs/freetype/src/cff/cffparse.c
> gs/freetype/src/cff/cffparse.h
> gs/freetype/src/cff/cffpic.c
> gs/freetype/src/cff/cffpic.h
> gs/freetype/src/cff/cfftoken.h
> gs/freetype/src/cff/cfftypes.h
> gs/freetype/src/cff/module.mk
> gs/freetype/src/cff/rules.mk
> gs/freetype/src/cid/Jamfile
> gs/freetype/src/cid/ciderrs.h
> gs/freetype/src/cid/cidgload.c
> gs/freetype/src/cid/cidgload.h
> gs/freetype/src/cid/cidload.c
> gs/freetype/src/cid/cidload.h
> gs/freetype/src/cid/cidobjs.c
> gs/freetype/src/cid/cidobjs.h
> gs/freetype/src/cid/cidparse.c
> gs/freetype/src/cid/cidparse.h
> gs/freetype/src/cid/cidriver.c
> gs/freetype/src/cid/cidriver.h
> gs/freetype/src/cid/cidtoken.h
> gs/freetype/src/cid/module.mk
> gs/freetype/src/cid/rules.mk
> gs/freetype/src/cid/type1cid.c
> gs/freetype/src/gxvalid/Jamfile
> gs/freetype/src/gxvalid/README
> gs/freetype/src/gxvalid/gxvalid.c
> gs/freetype/src/gxvalid/gxvalid.h
> gs/freetype/src/gxvalid/gxvbsln.c
> gs/freetype/src/gxvalid/gxvcommn.c
> gs/freetype/src/gxvalid/gxvcommn.h
> gs/freetype/src/gxvalid/gxverror.h
> gs/freetype/src/gxvalid/gxvfeat.c
> gs/freetype/src/gxvalid/gxvfeat.h
> gs/freetype/src/gxvalid/gxvfgen.c
> gs/freetype/src/gxvalid/gxvjust.c
> gs/freetype/src/gxvalid/gxvkern.c
> gs/freetype/src/gxvalid/gxvlcar.c
> gs/freetype/src/gxvalid/gxvmod.c
> gs/freetype/src/gxvalid/gxvmod.h
> gs/freetype/src/gxvalid/gxvmort.c
> gs/freetype/src/gxvalid/gxvmort.h
> gs/freetype/src/gxvalid/gxvmort0.c
> gs/freetype/src/gxvalid/gxvmort1.c
> gs/freetype/src/gxvalid/gxvmort2.c
> gs/freetype/src/gxvalid/gxvmort4.c
> gs/freetype/src/gxvalid/gxvmort5.c
> gs/freetype/src/gxvalid/gxvmorx.c
> gs/freetype/src/gxvalid/gxvmorx.h
> gs/freetype/src/gxvalid/gxvmorx0.c
> gs/freetype/src/gxvalid/gxvmorx1.c
> gs/freetype/src/gxvalid/gxvmorx2.c
> gs/freetype/src/gxvalid/gxvmorx4.c
> gs/freetype/src/gxvalid/gxvmorx5.c
> gs/freetype/src/gxvalid/gxvopbd.c
> gs/freetype/src/gxvalid/gxvprop.c
> gs/freetype/src/gxvalid/gxvtrak.c
> gs/freetype/src/gxvalid/module.mk
> gs/freetype/src/gxvalid/rules.mk
> gs/freetype/src/gzip/Jamfile
> gs/freetype/src/gzip/adler32.c
> gs/freetype/src/gzip/ftgzip.c
> gs/freetype/src/gzip/infblock.c
> gs/freetype/src/gzip/infblock.h
> gs/freetype/src/gzip/infcodes.c
> gs/freetype/src/gzip/infcodes.h
> gs/freetype/src/gzip/inffixed.h
> gs/freetype/src/gzip/inflate.c
> gs/freetype/src/gzip/inftrees.c
> gs/freetype/src/gzip/inftrees.h
> gs/freetype/src/gzip/infutil.c
> gs/freetype/src/gzip/infutil.h
> gs/freetype/src/gzip/rules.mk
> gs/freetype/src/gzip/zconf.h
> gs/freetype/src/gzip/zlib.h
> gs/freetype/src/gzip/zutil.c
> gs/freetype/src/gzip/zutil.h
> gs/freetype/src/lzw/Jamfile
> gs/freetype/src/lzw/ftlzw.c
> gs/freetype/src/lzw/ftzopen.c
> gs/freetype/src/lzw/ftzopen.h
> gs/freetype/src/lzw/rules.mk
> gs/freetype/src/otvalid/Jamfile
> gs/freetype/src/otvalid/module.mk
> gs/freetype/src/otvalid/otvalid.c
> gs/freetype/src/otvalid/otvalid.h
> gs/freetype/src/otvalid/otvbase.c
> gs/freetype/src/otvalid/otvcommn.c
> gs/freetype/src/otvalid/otvcommn.h
> gs/freetype/src/otvalid/otverror.h
> gs/freetype/src/otvalid/otvgdef.c
> gs/freetype/src/otvalid/otvgpos.c
> gs/freetype/src/otvalid/otvgpos.h
> gs/freetype/src/otvalid/otvgsub.c
> gs/freetype/src/otvalid/otvjstf.c
> gs/freetype/src/otvalid/otvmath.c
> gs/freetype/src/otvalid/otvmod.c
> gs/freetype/src/otvalid/otvmod.h
> gs/freetype/src/otvalid/rules.mk
> gs/freetype/src/pcf/Jamfile
> gs/freetype/src/pcf/README
> gs/freetype/src/pcf/module.mk
> gs/freetype/src/pcf/pcf.c
> gs/freetype/src/pcf/pcf.h
> gs/freetype/src/pcf/pcfdrivr.c
> gs/freetype/src/pcf/pcfdrivr.h
> gs/freetype/src/pcf/pcferror.h
> gs/freetype/src/pcf/pcfread.c
> gs/freetype/src/pcf/pcfread.h
> gs/freetype/src/pcf/pcfutil.c
> gs/freetype/src/pcf/pcfutil.h
> gs/freetype/src/pcf/rules.mk
> gs/freetype/src/pfr/Jamfile
> gs/freetype/src/pfr/module.mk
> gs/freetype/src/pfr/pfr.c
> gs/freetype/src/pfr/pfrcmap.c
> gs/freetype/src/pfr/pfrcmap.h
> gs/freetype/src/pfr/pfrdrivr.c
> gs/freetype/src/pfr/pfrdrivr.h
> gs/freetype/src/pfr/pfrerror.h
> gs/freetype/src/pfr/pfrgload.c
> gs/freetype/src/pfr/pfrgload.h
> gs/freetype/src/pfr/pfrload.c
> gs/freetype/src/pfr/pfrload.h
> gs/freetype/src/pfr/pfrobjs.c
> gs/freetype/src/pfr/pfrobjs.h
> gs/freetype/src/pfr/pfrsbit.c
> gs/freetype/src/pfr/pfrsbit.h
> gs/freetype/src/pfr/pfrtypes.h
> gs/freetype/src/pfr/rules.mk
> gs/freetype/src/psaux/Jamfile
> gs/freetype/src/psaux/afmparse.c
> gs/freetype/src/psaux/afmparse.h
> gs/freetype/src/psaux/module.mk
> gs/freetype/src/psaux/psaux.c
> gs/freetype/src/psaux/psauxerr.h
> gs/freetype/src/psaux/psauxmod.c
> gs/freetype/src/psaux/psauxmod.h
> gs/freetype/src/psaux/psconv.c
> gs/freetype/src/psaux/psconv.h
> gs/freetype/src/psaux/psobjs.c
> gs/freetype/src/psaux/psobjs.h
> gs/freetype/src/psaux/rules.mk
> gs/freetype/src/psaux/t1cmap.c
> gs/freetype/src/psaux/t1cmap.h
> gs/freetype/src/psaux/t1decode.c
> gs/freetype/src/psaux/t1decode.h
> gs/freetype/src/pshinter/Jamfile
> gs/freetype/src/pshinter/module.mk
> gs/freetype/src/pshinter/pshalgo.c
> gs/freetype/src/pshinter/pshalgo.h
> gs/freetype/src/pshinter/pshglob.c
> gs/freetype/src/pshinter/pshglob.h
> gs/freetype/src/pshinter/pshinter.c
> gs/freetype/src/pshinter/pshmod.c
> gs/freetype/src/pshinter/pshmod.h
> gs/freetype/src/pshinter/pshnterr.h
> gs/freetype/src/pshinter/pshpic.c
> gs/freetype/src/pshinter/pshpic.h
> gs/freetype/src/pshinter/pshrec.c
> gs/freetype/src/pshinter/pshrec.h
> gs/freetype/src/pshinter/rules.mk
> gs/freetype/src/psnames/Jamfile
> gs/freetype/src/psnames/module.mk
> gs/freetype/src/psnames/psmodule.c
> gs/freetype/src/psnames/psmodule.h
> gs/freetype/src/psnames/psnamerr.h
> gs/freetype/src/psnames/psnames.c
> gs/freetype/src/psnames/pspic.c
> gs/freetype/src/psnames/pspic.h
> gs/freetype/src/psnames/pstables.h
> gs/freetype/src/psnames/rules.mk
> gs/freetype/src/raster/Jamfile
> gs/freetype/src/raster/ftmisc.h
> gs/freetype/src/raster/ftraster.c
> gs/freetype/src/raster/ftraster.h
> gs/freetype/src/raster/ftrend1.c
> gs/freetype/src/raster/ftrend1.h
> gs/freetype/src/raster/module.mk
> gs/freetype/src/raster/raster.c
> gs/freetype/src/raster/rasterrs.h
> gs/freetype/src/raster/rastpic.c
> gs/freetype/src/raster/rastpic.h
> gs/freetype/src/raster/rules.mk
> gs/freetype/src/sfnt/Jamfile
> gs/freetype/src/sfnt/module.mk
> gs/freetype/src/sfnt/pngshim.c
> gs/freetype/src/sfnt/pngshim.h
> gs/freetype/src/sfnt/rules.mk
> gs/freetype/src/sfnt/sfdriver.c
> gs/freetype/src/sfnt/sfdriver.h
> gs/freetype/src/sfnt/sferrors.h
> gs/freetype/src/sfnt/sfnt.c
> gs/freetype/src/sfnt/sfntpic.c
> gs/freetype/src/sfnt/sfntpic.h
> gs/freetype/src/sfnt/sfobjs.c
> gs/freetype/src/sfnt/sfobjs.h
> gs/freetype/src/sfnt/ttbdf.c
> gs/freetype/src/sfnt/ttbdf.h
> gs/freetype/src/sfnt/ttcmap.c
> gs/freetype/src/sfnt/ttcmap.h
> gs/freetype/src/sfnt/ttcmapc.h
> gs/freetype/src/sfnt/ttkern.c
> gs/freetype/src/sfnt/ttkern.h
> gs/freetype/src/sfnt/ttload.c
> gs/freetype/src/sfnt/ttload.h
> gs/freetype/src/sfnt/ttmtx.c
> gs/freetype/src/sfnt/ttmtx.h
> gs/freetype/src/sfnt/ttpost.c
> gs/freetype/src/sfnt/ttpost.h
> gs/freetype/src/sfnt/ttsbit.c
> gs/freetype/src/sfnt/ttsbit.h
> gs/freetype/src/smooth/Jamfile
> gs/freetype/src/smooth/ftgrays.c
> gs/freetype/src/smooth/ftgrays.h
> gs/freetype/src/smooth/ftsmerrs.h
> gs/freetype/src/smooth/ftsmooth.c
> gs/freetype/src/smooth/ftsmooth.h
> gs/freetype/src/smooth/ftspic.c
> gs/freetype/src/smooth/ftspic.h
> gs/freetype/src/smooth/module.mk
> gs/freetype/src/smooth/rules.mk
> gs/freetype/src/smooth/smooth.c
> gs/freetype/src/tools/Jamfile
> gs/freetype/src/tools/afblue.pl
> gs/freetype/src/tools/apinames.c
> gs/freetype/src/tools/chktrcmp.py
> gs/freetype/src/tools/cordic.py
> gs/freetype/src/tools/docmaker/content.py
> gs/freetype/src/tools/docmaker/docbeauty.py
> gs/freetype/src/tools/docmaker/docmaker.py
> gs/freetype/src/tools/docmaker/formatter.py
> gs/freetype/src/tools/docmaker/sources.py
> gs/freetype/src/tools/docmaker/tohtml.py
> gs/freetype/src/tools/docmaker/utils.py
> gs/freetype/src/tools/ftrandom/Makefile
> gs/freetype/src/tools/ftrandom/README
> gs/freetype/src/tools/ftrandom/ftrandom.c
> gs/freetype/src/tools/glnames.py
> gs/freetype/src/tools/test_afm.c
> gs/freetype/src/tools/test_bbox.c
> gs/freetype/src/tools/test_trig.c
> gs/freetype/src/truetype/Jamfile
> gs/freetype/src/truetype/module.mk
> gs/freetype/src/truetype/rules.mk
> gs/freetype/src/truetype/truetype.c
> gs/freetype/src/truetype/ttdriver.c
> gs/freetype/src/truetype/ttdriver.h
> gs/freetype/src/truetype/tterrors.h
> gs/freetype/src/truetype/ttgload.c
> gs/freetype/src/truetype/ttgload.h
> gs/freetype/src/truetype/ttgxvar.c
> gs/freetype/src/truetype/ttgxvar.h
> gs/freetype/src/truetype/ttinterp.c
> gs/freetype/src/truetype/ttinterp.h
> gs/freetype/src/truetype/ttobjs.c
> gs/freetype/src/truetype/ttobjs.h
> gs/freetype/src/truetype/ttpic.c
> gs/freetype/src/truetype/ttpic.h
> gs/freetype/src/truetype/ttpload.c
> gs/freetype/src/truetype/ttpload.h
> gs/freetype/src/truetype/ttsubpix.c
> gs/freetype/src/truetype/ttsubpix.h
> gs/freetype/src/type1/Jamfile
> gs/freetype/src/type1/module.mk
> gs/freetype/src/type1/rules.mk
> gs/freetype/src/type1/t1afm.c
> gs/freetype/src/type1/t1afm.h
> gs/freetype/src/type1/t1driver.c
> gs/freetype/src/type1/t1driver.h
> gs/freetype/src/type1/t1errors.h
> gs/freetype/src/type1/t1gload.c
> gs/freetype/src/type1/t1gload.h
> gs/freetype/src/type1/t1load.c
> gs/freetype/src/type1/t1load.h
> gs/freetype/src/type1/t1objs.c
> gs/freetype/src/type1/t1objs.h
> gs/freetype/src/type1/t1parse.c
> gs/freetype/src/type1/t1parse.h
> gs/freetype/src/type1/t1tokens.h
> gs/freetype/src/type1/type1.c
> gs/freetype/src/type42/Jamfile
> gs/freetype/src/type42/module.mk
> gs/freetype/src/type42/rules.mk
> gs/freetype/src/type42/t42drivr.c
> gs/freetype/src/type42/t42drivr.h
> gs/freetype/src/type42/t42error.h
> gs/freetype/src/type42/t42objs.c
> gs/freetype/src/type42/t42objs.h
> gs/freetype/src/type42/t42parse.c
> gs/freetype/src/type42/t42parse.h
> gs/freetype/src/type42/t42types.h
> gs/freetype/src/type42/type42.c
> gs/freetype/src/winfonts/Jamfile
> gs/freetype/src/winfonts/fnterrs.h
> gs/freetype/src/winfonts/module.mk
> gs/freetype/src/winfonts/rules.mk
> gs/freetype/src/winfonts/winfnt.c
> gs/freetype/src/winfonts/winfnt.h
> gs/freetype/version.sed
> gs/freetype/vms_make.com
> gs/ghostscript-ufst.vcproj
> gs/ghostscript.vcproj
> gs/ghostscript_rt.vcxproj
> gs/iccprofiles/default_cmyk.icc
> gs/iccprofiles/default_gray.icc
> gs/iccprofiles/default_rgb.icc
> gs/iccprofiles/gray_to_k.icc
> gs/iccprofiles/lab.icc
> gs/iccprofiles/ps_cmyk.icc
> gs/iccprofiles/ps_gray.icc
> gs/iccprofiles/ps_rgb.icc
> gs/iccprofiles/sgray.icc
> gs/iccprofiles/srgb.icc
> gs/ijs/Makefile.am
> gs/ijs/Makefile.in
> gs/ijs/README
> gs/ijs/autogen.sh
> gs/ijs/common.mak
> gs/ijs/compile
> gs/ijs/config.guess
> gs/ijs/config.sub
> gs/ijs/configure
> gs/ijs/configure.ac
> gs/ijs/ijs-config.1
> gs/ijs/ijs-config.in
> gs/ijs/ijs.c
> gs/ijs/ijs.h
> gs/ijs/ijs.pc.in
> gs/ijs/ijs_client.c
> gs/ijs/ijs_client.h
> gs/ijs/ijs_client_example.c
> gs/ijs/ijs_exec_unix.c
> gs/ijs/ijs_exec_win.c
> gs/ijs/ijs_server.c
> gs/ijs/ijs_server.h
> gs/ijs/ijs_server_example.c
> gs/ijs/ijs_spec.pdf
> gs/ijs/ijs_spec.ps
> gs/ijs/ijs_spec.sgml
> gs/ijs/install-sh
> gs/ijs/libtool
> gs/ijs/ltmain.sh
> gs/ijs/missing
> gs/ijs/state.eps
> gs/ijs/state.fig
> gs/ijs/unistd_.h
> gs/ijs/unix.mak
> gs/ijs/windows.mak
> gs/jbig2dec/.gitignore
> gs/jbig2dec/CHANGES
> gs/jbig2dec/COPYING
> gs/jbig2dec/LICENSE
> gs/jbig2dec/Makefile.am
> gs/jbig2dec/Makefile.unix
> gs/jbig2dec/README
> gs/jbig2dec/annex-h.jbig2
> gs/jbig2dec/autogen.sh
> gs/jbig2dec/config_win32.h
> gs/jbig2dec/configure.ac
> gs/jbig2dec/getopt.c
> gs/jbig2dec/getopt.h
> gs/jbig2dec/getopt1.c
> gs/jbig2dec/jbig2.c
> gs/jbig2dec/jbig2.h
> gs/jbig2dec/jbig2_arith.c
> gs/jbig2dec/jbig2_arith.h
> gs/jbig2dec/jbig2_arith_iaid.c
> gs/jbig2dec/jbig2_arith_iaid.h
> gs/jbig2dec/jbig2_arith_int.c
> gs/jbig2dec/jbig2_arith_int.h
> gs/jbig2dec/jbig2_generic.c
> gs/jbig2dec/jbig2_generic.h
> gs/jbig2dec/jbig2_halftone.c
> gs/jbig2dec/jbig2_halftone.h
> gs/jbig2dec/jbig2_huffman.c
> gs/jbig2dec/jbig2_huffman.h
> gs/jbig2dec/jbig2_hufftab.h
> gs/jbig2dec/jbig2_image.c
> gs/jbig2dec/jbig2_image.h
> gs/jbig2dec/jbig2_image_pbm.c
> gs/jbig2dec/jbig2_image_png.c
> gs/jbig2dec/jbig2_metadata.c
> gs/jbig2dec/jbig2_metadata.h
> gs/jbig2dec/jbig2_mmr.c
> gs/jbig2dec/jbig2_mmr.h
> gs/jbig2dec/jbig2_page.c
> gs/jbig2dec/jbig2_priv.h
> gs/jbig2dec/jbig2_refinement.c
> gs/jbig2dec/jbig2_segment.c
> gs/jbig2dec/jbig2_symbol_dict.c
> gs/jbig2dec/jbig2_symbol_dict.h
> gs/jbig2dec/jbig2_text.c
> gs/jbig2dec/jbig2_text.h
> gs/jbig2dec/jbig2dec.1
> gs/jbig2dec/jbig2dec.c
> gs/jbig2dec/memcmp.c
> gs/jbig2dec/memento.c
> gs/jbig2dec/memento.h
> gs/jbig2dec/msvc.mak
> gs/jbig2dec/os_types.h
> gs/jbig2dec/pbm2png.c
> gs/jbig2dec/sha1.c
> gs/jbig2dec/sha1.h
> gs/jbig2dec/snprintf.c
> gs/jbig2dec/test_jbig2dec.py
> gs/jpeg/Makefile.am
> gs/jpeg/Makefile.in
> gs/jpeg/README
> gs/jpeg/aclocal.m4
> gs/jpeg/ar-lib
> gs/jpeg/cderror.h
> gs/jpeg/cdjpeg.c
> gs/jpeg/cdjpeg.h
> gs/jpeg/change.log
> gs/jpeg/cjpeg.1
> gs/jpeg/cjpeg.c
> gs/jpeg/ckconfig.c
> gs/jpeg/coderules.txt
> gs/jpeg/compile
> gs/jpeg/config.guess
> gs/jpeg/config.sub
> gs/jpeg/configure
> gs/jpeg/configure.ac
> gs/jpeg/depcomp
> gs/jpeg/djpeg.1
> gs/jpeg/djpeg.c
> gs/jpeg/example.c
> gs/jpeg/filelist.txt
> gs/jpeg/install-sh
> gs/jpeg/install.txt
> gs/jpeg/jaricom.c
> gs/jpeg/jcapimin.c
> gs/jpeg/jcapistd.c
> gs/jpeg/jcarith.c
> gs/jpeg/jccoefct.c
> gs/jpeg/jccolor.c
> gs/jpeg/jcdctmgr.c
> gs/jpeg/jchuff.c
> gs/jpeg/jcinit.c
> gs/jpeg/jcmainct.c
> gs/jpeg/jcmarker.c
> gs/jpeg/jcmaster.c
> gs/jpeg/jcomapi.c
> gs/jpeg/jconfig.bcc
> gs/jpeg/jconfig.cfg
> gs/jpeg/jconfig.dj
> gs/jpeg/jconfig.mac
> gs/jpeg/jconfig.manx
> gs/jpeg/jconfig.mc6
> gs/jpeg/jconfig.sas
> gs/jpeg/jconfig.st
> gs/jpeg/jconfig.txt
> gs/jpeg/jconfig.vc
> gs/jpeg/jconfig.vms
> gs/jpeg/jconfig.wat
> gs/jpeg/jcparam.c
> gs/jpeg/jcprepct.c
> gs/jpeg/jcsample.c
> gs/jpeg/jctrans.c
> gs/jpeg/jdapimin.c
> gs/jpeg/jdapistd.c
> gs/jpeg/jdarith.c
> gs/jpeg/jdatadst.c
> gs/jpeg/jdatasrc.c
> gs/jpeg/jdcoefct.c
> gs/jpeg/jdcolor.c
> gs/jpeg/jdct.h
> gs/jpeg/jddctmgr.c
> gs/jpeg/jdhuff.c
> gs/jpeg/jdinput.c
> gs/jpeg/jdmainct.c
> gs/jpeg/jdmarker.c
> gs/jpeg/jdmaster.c
> gs/jpeg/jdmerge.c
> gs/jpeg/jdpostct.c
> gs/jpeg/jdsample.c
> gs/jpeg/jdtrans.c
> gs/jpeg/jerror.c
> gs/jpeg/jerror.h
> gs/jpeg/jfdctflt.c
> gs/jpeg/jfdctfst.c
> gs/jpeg/jfdctint.c
> gs/jpeg/jidctflt.c
> gs/jpeg/jidctfst.c
> gs/jpeg/jidctint.c
> gs/jpeg/jinclude.h
> gs/jpeg/jmemansi.c
> gs/jpeg/jmemdos.c
> gs/jpeg/jmemdosa.asm
> gs/jpeg/jmemmac.c
> gs/jpeg/jmemmgr.c
> gs/jpeg/jmemname.c
> gs/jpeg/jmemnobs.c
> gs/jpeg/jmemsys.h
> gs/jpeg/jmorecfg.h
> gs/jpeg/jpegint.h
> gs/jpeg/jpeglib.h
> gs/jpeg/jpegtran.1
> gs/jpeg/jpegtran.c
> gs/jpeg/jquant1.c
> gs/jpeg/jquant2.c
> gs/jpeg/jutils.c
> gs/jpeg/jversion.h
> gs/jpeg/libjpeg.map
> gs/jpeg/libjpeg.txt
> gs/jpeg/ltmain.sh
> gs/jpeg/makcjpeg.st
> gs/jpeg/makdjpeg.st
> gs/jpeg/makeadsw.vc6
> gs/jpeg/makeasln.v10
> gs/jpeg/makecdep.vc6
> gs/jpeg/makecdsp.vc6
> gs/jpeg/makecfil.v10
> gs/jpeg/makecmak.vc6
> gs/jpeg/makecvcx.v10
> gs/jpeg/makeddep.vc6
> gs/jpeg/makeddsp.vc6
> gs/jpeg/makedfil.v10
> gs/jpeg/makedmak.vc6
> gs/jpeg/makedvcx.v10
> gs/jpeg/makefile.ansi
> gs/jpeg/makefile.bcc
> gs/jpeg/makefile.dj
> gs/jpeg/makefile.manx
> gs/jpeg/makefile.mc6
> gs/jpeg/makefile.mms
> gs/jpeg/makefile.sas
> gs/jpeg/makefile.unix
> gs/jpeg/makefile.vc
> gs/jpeg/makefile.vms
> gs/jpeg/makefile.wat
> gs/jpeg/makejdep.vc6
> gs/jpeg/makejdsp.vc6
> gs/jpeg/makejdsw.vc6
> gs/jpeg/makejfil.v10
> gs/jpeg/makejmak.vc6
> gs/jpeg/makejsln.v10
> gs/jpeg/makejvcx.v10
> gs/jpeg/makeproj.mac
> gs/jpeg/makerdep.vc6
> gs/jpeg/makerdsp.vc6
> gs/jpeg/makerfil.v10
> gs/jpeg/makermak.vc6
> gs/jpeg/makervcx.v10
> gs/jpeg/maketdep.vc6
> gs/jpeg/maketdsp.vc6
> gs/jpeg/maketfil.v10
> gs/jpeg/maketmak.vc6
> gs/jpeg/maketvcx.v10
> gs/jpeg/makewdep.vc6
> gs/jpeg/makewdsp.vc6
> gs/jpeg/makewfil.v10
> gs/jpeg/makewmak.vc6
> gs/jpeg/makewvcx.v10
> gs/jpeg/makljpeg.st
> gs/jpeg/maktjpeg.st
> gs/jpeg/makvms.opt
> gs/jpeg/missing
> gs/jpeg/rdbmp.c
> gs/jpeg/rdcolmap.c
> gs/jpeg/rdgif.c
> gs/jpeg/rdjpgcom.1
> gs/jpeg/rdjpgcom.c
> gs/jpeg/rdppm.c
> gs/jpeg/rdrle.c
> gs/jpeg/rdswitch.c
> gs/jpeg/rdtarga.c
> gs/jpeg/structure.txt
> gs/jpeg/testimg.bmp
> gs/jpeg/testimg.jpg
> gs/jpeg/testimg.ppm
> gs/jpeg/testimgp.jpg
> gs/jpeg/testorig.jpg
> gs/jpeg/testprog.jpg
> gs/jpeg/transupp.c
> gs/jpeg/transupp.h
> gs/jpeg/usage.txt
> gs/jpeg/wizard.txt
> gs/jpeg/wrbmp.c
> gs/jpeg/wrgif.c
> gs/jpeg/wrjpgcom.1
> gs/jpeg/wrjpgcom.c
> gs/jpeg/wrppm.c
> gs/jpeg/wrrle.c
> gs/jpeg/wrtarga.c
> gs/jpegxr/APP.rc
> gs/jpegxr/APP.vcproj
> gs/jpegxr/COPYRIGHT.txt
> gs/jpegxr/DLL.rc
> gs/jpegxr/DLL.vcproj
> gs/jpegxr/JPEG-XR.sln
> gs/jpegxr/Makefile
> gs/jpegxr/README.txt
> gs/jpegxr/algo.c
> gs/jpegxr/api.c
> gs/jpegxr/app_resource.h
> gs/jpegxr/cr_parse.c
> gs/jpegxr/cw_emit.c
> gs/jpegxr/dll_resource.h
> gs/jpegxr/dllmain.c
> gs/jpegxr/file.c
> gs/jpegxr/file.h
> gs/jpegxr/flags.c
> gs/jpegxr/init.c
> gs/jpegxr/io.c
> gs/jpegxr/jpegxr.c
> gs/jpegxr/jpegxr.h
> gs/jpegxr/jpegxr_pixelformat.c
> gs/jpegxr/jxr_priv.h
> gs/jpegxr/my_getopt-1.5/LICENSE
> gs/jpegxr/my_getopt-1.5/getopt.h
> gs/jpegxr/my_getopt-1.5/my_getopt.c
> gs/jpegxr/my_getopt-1.5/my_getopt.h
> gs/jpegxr/qp.tab.c
> gs/jpegxr/qp.tab.h
> gs/jpegxr/qp_lexor.c
> gs/jpegxr/qp_lexor.lex
> gs/jpegxr/qp_parse.y
> gs/jpegxr/r_parse.c
> gs/jpegxr/r_strip.c
> gs/jpegxr/r_tile_frequency.c
> gs/jpegxr/r_tile_spatial.c
> gs/jpegxr/sample.qp
> gs/jpegxr/stdint_minimal.h
> gs/jpegxr/versions-windows.txt
> gs/jpegxr/w_emit.c
> gs/jpegxr/w_strip.c
> gs/jpegxr/w_tile_frequency.c
> gs/jpegxr/w_tile_spatial.c
> gs/jpegxr/x_strip.c
> gs/lcms2/AUTHORS
> gs/lcms2/COPYING
> gs/lcms2/ChangeLog
> gs/lcms2/INSTALL
> gs/lcms2/Lib/BC/BC.txt
> gs/lcms2/Lib/MS/MS.TXT
> gs/lcms2/Makefile.am
> gs/lcms2/Makefile.in
> gs/lcms2/Projects/.gitignore
> gs/lcms2/Projects/BorlandC_5.5/lcms2.rc
> gs/lcms2/Projects/BorlandC_5.5/lcmsdll.lk
> gs/lcms2/Projects/BorlandC_5.5/lcmsdll.lst
> gs/lcms2/Projects/BorlandC_5.5/mklcmsdll.bat
> gs/lcms2/Projects/VC2008/jpegicc/jpegicc.vcproj
> gs/lcms2/Projects/VC2008/lcms2.rc
> gs/lcms2/Projects/VC2008/lcms2.sln
> gs/lcms2/Projects/VC2008/lcms2_DLL/lcms2_DLL.vcproj
> gs/lcms2/Projects/VC2008/lcms2_static/lcms2_static.vcproj
> gs/lcms2/Projects/VC2008/linkicc/linkicc.vcproj
> gs/lcms2/Projects/VC2008/psicc/psicc.vcproj
> gs/lcms2/Projects/VC2008/resource.h
> gs/lcms2/Projects/VC2008/testbed/testbed.vcproj
> gs/lcms2/Projects/VC2008/tiffdiff/tiffdiff.vcproj
> gs/lcms2/Projects/VC2008/tifficc/tifficc.vcproj
> gs/lcms2/Projects/VC2008/transicc/transicc.vcproj
> gs/lcms2/Projects/VC2010/jpegicc/jpegicc.vcproj
> gs/lcms2/Projects/VC2010/jpegicc/jpegicc.vcxproj
> gs/lcms2/Projects/VC2010/jpegicc/jpegicc.vcxproj.filters
> gs/lcms2/Projects/VC2010/lcms2.rc
> gs/lcms2/Projects/VC2010/lcms2.sln
> gs/lcms2/Projects/VC2010/lcms2_DLL/lcms2_DLL.vcproj
> gs/lcms2/Projects/VC2010/lcms2_DLL/lcms2_DLL.vcxproj
> gs/lcms2/Projects/VC2010/lcms2_DLL/lcms2_DLL.vcxproj.filters
> gs/lcms2/Projects/VC2010/lcms2_static/lcms2_static.vcproj
> gs/lcms2/Projects/VC2010/lcms2_static/lcms2_static.vcxproj
> gs/lcms2/Projects/VC2010/lcms2_static/lcms2_static.vcxproj.filters
> gs/lcms2/Projects/VC2010/linkicc/linkicc.vcproj
> gs/lcms2/Projects/VC2010/linkicc/linkicc.vcxproj
> gs/lcms2/Projects/VC2010/linkicc/linkicc.vcxproj.filters
> gs/lcms2/Projects/VC2010/psicc/psicc.vcproj
> gs/lcms2/Projects/VC2010/psicc/psicc.vcxproj
> gs/lcms2/Projects/VC2010/psicc/psicc.vcxproj.filters
> gs/lcms2/Projects/VC2010/resource.h
> gs/lcms2/Projects/VC2010/testbed/testbed.vcproj
> gs/lcms2/Projects/VC2010/testbed/testbed.vcxproj
> gs/lcms2/Projects/VC2010/testbed/testbed.vcxproj.filters
> gs/lcms2/Projects/VC2010/tiffdiff/tiffdiff.vcproj
> gs/lcms2/Projects/VC2010/tiffdiff/tiffdiff.vcxproj
> gs/lcms2/Projects/VC2010/tiffdiff/tiffdiff.vcxproj.filters
> gs/lcms2/Projects/VC2010/tifficc/tifficc.vcproj
> gs/lcms2/Projects/VC2010/tifficc/tifficc.vcxproj
> gs/lcms2/Projects/VC2010/tifficc/tifficc.vcxproj.filters
> gs/lcms2/Projects/VC2010/transicc/transicc.vcproj
> gs/lcms2/Projects/VC2010/transicc/transicc.vcxproj
> gs/lcms2/Projects/VC2010/transicc/transicc.vcxproj.filters
> gs/lcms2/Projects/VC2012/jpegicc/jpegicc.vcproj
> gs/lcms2/Projects/VC2012/jpegicc/jpegicc.vcxproj
> gs/lcms2/Projects/VC2012/jpegicc/jpegicc.vcxproj.filters
> gs/lcms2/Projects/VC2012/lcms2.rc
> gs/lcms2/Projects/VC2012/lcms2.sln
> gs/lcms2/Projects/VC2012/lcms2_DLL/lcms2_DLL.vcproj
> gs/lcms2/Projects/VC2012/lcms2_DLL/lcms2_DLL.vcxproj
> gs/lcms2/Projects/VC2012/lcms2_DLL/lcms2_DLL.vcxproj.filters
> gs/lcms2/Projects/VC2012/lcms2_static/lcms2_static.vcproj
> gs/lcms2/Projects/VC2012/lcms2_static/lcms2_static.vcxproj
> gs/lcms2/Projects/VC2012/lcms2_static/lcms2_static.vcxproj.filters
> gs/lcms2/Projects/VC2012/linkicc/linkicc.vcproj
> gs/lcms2/Projects/VC2012/linkicc/linkicc.vcxproj
> gs/lcms2/Projects/VC2012/linkicc/linkicc.vcxproj.filters
> gs/lcms2/Projects/VC2012/psicc/psicc.vcproj
> gs/lcms2/Projects/VC2012/psicc/psicc.vcxproj
> gs/lcms2/Projects/VC2012/psicc/psicc.vcxproj.filters
> gs/lcms2/Projects/VC2012/resource.h
> gs/lcms2/Projects/VC2012/testbed/testbed.vcproj
> gs/lcms2/Projects/VC2012/testbed/testbed.vcxproj
> gs/lcms2/Projects/VC2012/testbed/testbed.vcxproj.filters
> gs/lcms2/Projects/VC2012/tiffdiff/tiffdiff.vcproj
> gs/lcms2/Projects/VC2012/tiffdiff/tiffdiff.vcxproj
> gs/lcms2/Projects/VC2012/tiffdiff/tiffdiff.vcxproj.filters
> gs/lcms2/Projects/VC2012/tifficc/tifficc.vcproj
> gs/lcms2/Projects/VC2012/tifficc/tifficc.vcxproj
> gs/lcms2/Projects/VC2012/tifficc/tifficc.vcxproj.filters
> gs/lcms2/Projects/VC2012/transicc/transicc.vcproj
> gs/lcms2/Projects/VC2012/transicc/transicc.vcxproj
> gs/lcms2/Projects/VC2012/transicc/transicc.vcxproj.filters
> gs/lcms2/Projects/cppcheck/lcms2.cppcheck
> gs/lcms2/Projects/mac/._.DS_Store
> gs/lcms2/Projects/mac/LittleCMS/._.DS_Store
> gs/lcms2/Projects/mac/LittleCMS/English.lproj/InfoPlist.strings
> gs/lcms2/Projects/mac/LittleCMS/Info.plist
> gs/lcms2/Projects/mac/LittleCMS/LittleCMS.xcodeproj/mariama.mode1v3
> gs/lcms2/Projects/mac/LittleCMS/LittleCMS.xcodeproj/mariama.pbxuser
> gs/lcms2/Projects/mac/LittleCMS/LittleCMS.xcodeproj/project.pbxproj
> gs/lcms2/Projects/mac/LittleCMS/LittleCMS_Prefix.pch
> gs/lcms2/Projects/mac/LittleCMS/TestBed-Info.plist
> gs/lcms2/README.1ST
> gs/lcms2/aclocal.m4
> gs/lcms2/autogen.sh
> gs/lcms2/config.guess
> gs/lcms2/config.sub
> gs/lcms2/configure
> gs/lcms2/configure.ac
> gs/lcms2/depcomp
> gs/lcms2/doc/LittleCMS2.6 API.pdf
> gs/lcms2/doc/LittleCMS2.6 Plugin API.pdf
> gs/lcms2/doc/LittleCMS2.6 tutorial.pdf
> gs/lcms2/doc/src.zip
> gs/lcms2/include/Makefile.am
> gs/lcms2/include/Makefile.in
> gs/lcms2/include/lcms2.h
> gs/lcms2/include/lcms2_plugin.h
> gs/lcms2/install-sh
> gs/lcms2/lcms2.pc.in
> gs/lcms2/ltmain.sh
> gs/lcms2/m4/acx_pthread.m4
> gs/lcms2/missing
> gs/lcms2/src/Makefile.am
> gs/lcms2/src/Makefile.in
> gs/lcms2/src/cmscam02.c
> gs/lcms2/src/cmscgats.c
> gs/lcms2/src/cmscnvrt.c
> gs/lcms2/src/cmserr.c
> gs/lcms2/src/cmsgamma.c
> gs/lcms2/src/cmsgmt.c
> gs/lcms2/src/cmshalf.c
> gs/lcms2/src/cmsintrp.c
> gs/lcms2/src/cmsio0.c
> gs/lcms2/src/cmsio1.c
> gs/lcms2/src/cmslut.c
> gs/lcms2/src/cmsmd5.c
> gs/lcms2/src/cmsmtrx.c
> gs/lcms2/src/cmsnamed.c
> gs/lcms2/src/cmsopt.c
> gs/lcms2/src/cmspack.c
> gs/lcms2/src/cmspcs.c
> gs/lcms2/src/cmsplugin.c
> gs/lcms2/src/cmsps2.c
> gs/lcms2/src/cmssamp.c
> gs/lcms2/src/cmssm.c
> gs/lcms2/src/cmstypes.c
> gs/lcms2/src/cmsvirt.c
> gs/lcms2/src/cmswtpnt.c
> gs/lcms2/src/cmsxform.c
> gs/lcms2/src/extra_xform.h
> gs/lcms2/src/lcms2.def
> gs/lcms2/src/lcms2_internal.h
> gs/lcms2/testbed/Makefile.am
> gs/lcms2/testbed/Makefile.in
> gs/lcms2/testbed/bad.icc
> gs/lcms2/testbed/ibm-t61.icc
> gs/lcms2/testbed/new.icc
> gs/lcms2/testbed/test1.icc
> gs/lcms2/testbed/test2.icc
> gs/lcms2/testbed/test3.icc
> gs/lcms2/testbed/test4.icc
> gs/lcms2/testbed/test5.icc
> gs/lcms2/testbed/testcms2.c
> gs/lcms2/testbed/testcms2.h
> gs/lcms2/testbed/testplugin.c
> gs/lcms2/testbed/testthread.cpp
> gs/lcms2/testbed/toosmall.icc
> gs/lcms2/testbed/zoo_icc.c
> gs/lcms2/utils/common/utils.h
> gs/lcms2/utils/common/vprf.c
> gs/lcms2/utils/common/xgetopt.c
> gs/lcms2/utils/delphi/delphidemo.dpr
> gs/lcms2/utils/delphi/delphidemo.dproj
> gs/lcms2/utils/delphi/delphidemo.res
> gs/lcms2/utils/delphi/demo1.dfm
> gs/lcms2/utils/delphi/demo1.pas
> gs/lcms2/utils/delphi/lcms2.dll
> gs/lcms2/utils/delphi/lcms2dll.pas
> gs/lcms2/utils/jpgicc/Makefile.am
> gs/lcms2/utils/jpgicc/Makefile.in
> gs/lcms2/utils/jpgicc/iccjpeg.c
> gs/lcms2/utils/jpgicc/iccjpeg.h
> gs/lcms2/utils/jpgicc/jpgicc.1
> gs/lcms2/utils/jpgicc/jpgicc.c
> gs/lcms2/utils/linkicc/Makefile.am
> gs/lcms2/utils/linkicc/Makefile.in
> gs/lcms2/utils/linkicc/linkicc.1
> gs/lcms2/utils/linkicc/linkicc.c
> gs/lcms2/utils/matlab/icctrans.c
> gs/lcms2/utils/matlab/lcms_rsp
> gs/lcms2/utils/psicc/Makefile.am
> gs/lcms2/utils/psicc/Makefile.in
> gs/lcms2/utils/psicc/psicc.1
> gs/lcms2/utils/psicc/psicc.c
> gs/lcms2/utils/samples/Makefile.am
> gs/lcms2/utils/samples/Makefile.in
> gs/lcms2/utils/samples/itufax.c
> gs/lcms2/utils/samples/mkcmy.c
> gs/lcms2/utils/samples/mkgrayer.c
> gs/lcms2/utils/samples/mktiff8.c
> gs/lcms2/utils/samples/roundtrip.c
> gs/lcms2/utils/samples/vericc.c
> gs/lcms2/utils/samples/wtpt.1
> gs/lcms2/utils/samples/wtpt.c
> gs/lcms2/utils/tificc/Makefile.am
> gs/lcms2/utils/tificc/Makefile.in
> gs/lcms2/utils/tificc/tifdiff.c
> gs/lcms2/utils/tificc/tificc.1
> gs/lcms2/utils/tificc/tificc.c
> gs/lcms2/utils/transicc/Makefile.am
> gs/lcms2/utils/transicc/Makefile.in
> gs/lcms2/utils/transicc/transicc.1
> gs/lcms2/utils/transicc/transicc.c
> gs/lib/EndOfTask.ps
> gs/lib/FAPIconfig-FCO
> gs/lib/FCOfontmap-PCLPS3
> gs/lib/FCOfontmap-PS3
> gs/lib/Fontmap.ATB
> gs/lib/Fontmap.ATM
> gs/lib/Fontmap.OS2
> gs/lib/Fontmap.OSF
> gs/lib/Fontmap.SGI
> gs/lib/Fontmap.Sol
> gs/lib/Fontmap.URW-136.T1
> gs/lib/Fontmap.URW-136.TT
> gs/lib/Fontmap.Ult
> gs/lib/Fontmap.VMS
> gs/lib/Info-macos.plist
> gs/lib/PDFA_def.ps
> gs/lib/PDFX_def.ps
> gs/lib/acctest.ps
> gs/lib/addxchar.ps
> gs/lib/afmdiff.awk
> gs/lib/align.ps
> gs/lib/bj8.rpd
> gs/lib/bj8gc12f.upp
> gs/lib/bj8hg12f.upp
> gs/lib/bj8oh06n.upp
> gs/lib/bj8pa06n.upp
> gs/lib/bj8pp12f.upp
> gs/lib/bj8ts06n.upp
> gs/lib/bjc610a0.upp
> gs/lib/bjc610a1.upp
> gs/lib/bjc610a2.upp
> gs/lib/bjc610a3.upp
> gs/lib/bjc610a4.upp
> gs/lib/bjc610a5.upp
> gs/lib/bjc610a6.upp
> gs/lib/bjc610a7.upp
> gs/lib/bjc610a8.upp
> gs/lib/bjc610b1.upp
> gs/lib/bjc610b2.upp
> gs/lib/bjc610b3.upp
> gs/lib/bjc610b4.upp
> gs/lib/bjc610b6.upp
> gs/lib/bjc610b7.upp
> gs/lib/bjc610b8.upp
> gs/lib/caption.ps
> gs/lib/cat.ps
> gs/lib/cbjc600.ppd
> gs/lib/cbjc800.ppd
> gs/lib/cdj550.upp
> gs/lib/cdj690.upp
> gs/lib/cdj690ec.upp
> gs/lib/cid2code.ps
> gs/lib/decrypt.ps
> gs/lib/dnj750c.upp
> gs/lib/dnj750m.upp
> gs/lib/docie.ps
> gs/lib/dvipdf
> gs/lib/eps2eps
> gs/lib/eps2eps.bat
> gs/lib/eps2eps.cmd
> gs/lib/font2c
> gs/lib/font2c.bat
> gs/lib/font2c.cmd
> gs/lib/font2c.ps
> gs/lib/font2pcl.ps
> gs/lib/ghostpdf.README
> gs/lib/ghostpdf.cat
> gs/lib/ghostpdf.inf
> gs/lib/ghostpdf.ppd
> gs/lib/gs_ce_e.ps
> gs/lib/gs_cmdl.ps
> gs/lib/gs_il2_e.ps
> gs/lib/gs_kanji.ps
> gs/lib/gs_ksb_e.ps
> gs/lib/gs_l.xbm
> gs/lib/gs_l.xpm
> gs/lib/gs_l_m.xbm
> gs/lib/gs_lgo_e.ps
> gs/lib/gs_lgx_e.ps
> gs/lib/gs_m.xbm
> gs/lib/gs_m.xpm
> gs/lib/gs_m_m.xbm
> gs/lib/gs_pfile.ps
> gs/lib/gs_rdlin.ps
> gs/lib/gs_s.xbm
> gs/lib/gs_s.xpm
> gs/lib/gs_s_m.xbm
> gs/lib/gs_t.xbm
> gs/lib/gs_t.xpm
> gs/lib/gs_t_m.xbm
> gs/lib/gs_wl1_e.ps
> gs/lib/gs_wl2_e.ps
> gs/lib/gs_wl5_e.ps
> gs/lib/gsbj
> gs/lib/gsbj.bat
> gs/lib/gsdj
> gs/lib/gsdj.bat
> gs/lib/gsdj500
> gs/lib/gsdj500.bat
> gs/lib/gslj
> gs/lib/gslj.bat
> gs/lib/gslp
> gs/lib/gslp.bat
> gs/lib/gslp.ps
> gs/lib/gsnd
> gs/lib/gsnd.bat
> gs/lib/gsndt.bat
> gs/lib/gsnup.ps
> gs/lib/gssetgs.bat
> gs/lib/gssetgs32.bat
> gs/lib/gssetgs64.bat
> gs/lib/gst.bat
> gs/lib/gstt.bat
> gs/lib/ht_ccsto.ps
> gs/lib/image-qa.ps
> gs/lib/impath.ps
> gs/lib/jispaper.ps
> gs/lib/jobseparator.ps
> gs/lib/landscap.ps
> gs/lib/level1.ps
> gs/lib/lines.ps
> gs/lib/lp386.bat
> gs/lib/lp386r2.bat
> gs/lib/lpgs.bat
> gs/lib/lpr2.bat
> gs/lib/lprsetup.sh
> gs/lib/markhint.ps
> gs/lib/markpath.ps
> gs/lib/mkcidfm.ps
> gs/lib/necp2x.upp
> gs/lib/necp2x6.upp
> gs/lib/opdfread.ps
> gs/lib/packfile.ps
> gs/lib/pcharstr.ps
> gs/lib/pdf2dsc
> gs/lib/pdf2dsc.bat
> gs/lib/pdf2dsc.ps
> gs/lib/pdf2ps
> gs/lib/pdf2ps.bat
> gs/lib/pdf2ps.cmd
> gs/lib/pdfwrite.ps
> gs/lib/pf2afm
> gs/lib/pf2afm.bat
> gs/lib/pf2afm.cmd
> gs/lib/pf2afm.ps
> gs/lib/pfbtopfa
> gs/lib/pfbtopfa.bat
> gs/lib/pfbtopfa.ps
> gs/lib/pftogsf.bat
> gs/lib/ppath.ps
> gs/lib/pphs
> gs/lib/pphs.ps
> gs/lib/prfont.ps
> gs/lib/printafm
> gs/lib/printafm.ps
> gs/lib/ps2ai.ps
> gs/lib/ps2ascii
> gs/lib/ps2ascii.bat
> gs/lib/ps2ascii.cmd
> gs/lib/ps2ascii.ps
> gs/lib/ps2epsi
> gs/lib/ps2epsi.bat
> gs/lib/ps2epsi.cmd
> gs/lib/ps2epsi.ps
> gs/lib/ps2pdf
> gs/lib/ps2pdf.bat
> gs/lib/ps2pdf.cmd
> gs/lib/ps2pdf12
> gs/lib/ps2pdf12.bat
> gs/lib/ps2pdf12.cmd
> gs/lib/ps2pdf13
> gs/lib/ps2pdf13.bat
> gs/lib/ps2pdf13.cmd
> gs/lib/ps2pdf14
> gs/lib/ps2pdf14.bat
> gs/lib/ps2pdf14.cmd
> gs/lib/ps2pdfwr
> gs/lib/ps2pdfxx.bat
> gs/lib/ps2ps
> gs/lib/ps2ps.bat
> gs/lib/ps2ps.cmd
> gs/lib/ps2ps2
> gs/lib/ps2ps2.bat
> gs/lib/ps2ps2.cmd
> gs/lib/quit.ps
> gs/lib/ras1.upp
> gs/lib/ras24.upp
> gs/lib/ras3.upp
> gs/lib/ras32.upp
> gs/lib/ras4.upp
> gs/lib/ras8m.upp
> gs/lib/rinkj-2200-setup
> gs/lib/rollconv.ps
> gs/lib/showchar.ps
> gs/lib/showpage.ps
> gs/lib/st640ih.upp
> gs/lib/st640ihg.upp
> gs/lib/st640p.upp
> gs/lib/st640pg.upp
> gs/lib/st640pl.upp
> gs/lib/st640plg.upp
> gs/lib/stc.upp
> gs/lib/stc1520h.upp
> gs/lib/stc2.upp
> gs/lib/stc200_h.upp
> gs/lib/stc2_h.upp
> gs/lib/stc2s_h.upp
> gs/lib/stc300.upp
> gs/lib/stc300bl.upp
> gs/lib/stc300bm.upp
> gs/lib/stc500p.upp
> gs/lib/stc500ph.upp
> gs/lib/stc600ih.upp
> gs/lib/stc600p.upp
> gs/lib/stc600pl.upp
> gs/lib/stc640p.upp
> gs/lib/stc800ih.upp
> gs/lib/stc800p.upp
> gs/lib/stc800pl.upp
> gs/lib/stc_h.upp
> gs/lib/stc_l.upp
> gs/lib/stcany.upp
> gs/lib/stcany_h.upp
> gs/lib/stcinfo.ps
> gs/lib/stcolor.ps
> gs/lib/stocht.ps
> gs/lib/traceimg.ps
> gs/lib/traceop.ps
> gs/lib/type1enc.ps
> gs/lib/type1ops.ps
> gs/lib/uninfo.ps
> gs/lib/unix-lpr.sh
> gs/lib/unprot.ps
> gs/lib/viewcmyk.ps
> gs/lib/viewgif.ps
> gs/lib/viewjpeg.ps
> gs/lib/viewmiff.ps
> gs/lib/viewpbm.ps
> gs/lib/viewpcx.ps
> gs/lib/viewps2a.ps
> gs/lib/viewraw.ps
> gs/lib/viewrgb.ps
> gs/lib/wftopfa
> gs/lib/wftopfa.ps
> gs/lib/winmaps.ps
> gs/lib/wmakebat.bat
> gs/lib/wrfont.ps
> gs/lib/zeroline.ps
> gs/libpng/ANNOUNCE
> gs/libpng/CHANGES
> gs/libpng/CMakeLists.txt
> gs/libpng/INSTALL
> gs/libpng/LICENSE
> gs/libpng/Makefile.am
> gs/libpng/Makefile.in
> gs/libpng/README
> gs/libpng/TODO
> gs/libpng/aclocal.m4
> gs/libpng/arm/arm_init.c
> gs/libpng/arm/filter_neon.S
> gs/libpng/arm/filter_neon_intrinsics.c
> gs/libpng/autogen.sh
> gs/libpng/compile
> gs/libpng/config.guess
> gs/libpng/config.h.in
> gs/libpng/config.sub
> gs/libpng/configure
> gs/libpng/configure.ac
> gs/libpng/contrib/README.txt
> gs/libpng/contrib/arm-neon/README
> gs/libpng/contrib/arm-neon/android-ndk.c
> gs/libpng/contrib/arm-neon/linux-auxv.c
> gs/libpng/contrib/arm-neon/linux.c
> gs/libpng/contrib/conftest/README
> gs/libpng/contrib/conftest/read.dfa
> gs/libpng/contrib/conftest/s_read.dfa
> gs/libpng/contrib/conftest/s_write.dfa
> gs/libpng/contrib/conftest/simple.dfa
> gs/libpng/contrib/conftest/write.dfa
> gs/libpng/contrib/examples/README.txt
> gs/libpng/contrib/examples/iccfrompng.c
> gs/libpng/contrib/examples/pngpixel.c
> gs/libpng/contrib/examples/pngtopng.c
> gs/libpng/contrib/gregbook/COPYING
> gs/libpng/contrib/gregbook/LICENSE
> gs/libpng/contrib/gregbook/Makefile.mingw32
> gs/libpng/contrib/gregbook/Makefile.sgi
> gs/libpng/contrib/gregbook/Makefile.unx
> gs/libpng/contrib/gregbook/Makefile.w32
> gs/libpng/contrib/gregbook/README
> gs/libpng/contrib/gregbook/makevms.com
> gs/libpng/contrib/gregbook/readpng.c
> gs/libpng/contrib/gregbook/readpng.h
> gs/libpng/contrib/gregbook/readpng2.c
> gs/libpng/contrib/gregbook/readpng2.h
> gs/libpng/contrib/gregbook/readppm.c
> gs/libpng/contrib/gregbook/rpng-win.c
> gs/libpng/contrib/gregbook/rpng-x.c
> gs/libpng/contrib/gregbook/rpng2-win.c
> gs/libpng/contrib/gregbook/rpng2-x.c
> gs/libpng/contrib/gregbook/toucan.png
> gs/libpng/contrib/gregbook/wpng.c
> gs/libpng/contrib/gregbook/writepng.c
> gs/libpng/contrib/gregbook/writepng.h
> gs/libpng/contrib/libtests/fakepng.c
> gs/libpng/contrib/libtests/gentests.sh
> gs/libpng/contrib/libtests/makepng.c
> gs/libpng/contrib/libtests/pngimage.c
> gs/libpng/contrib/libtests/pngstest.c
> gs/libpng/contrib/libtests/pngunknown.c
> gs/libpng/contrib/libtests/pngvalid.c
> gs/libpng/contrib/libtests/readpng.c
> gs/libpng/contrib/libtests/tarith.c
> gs/libpng/contrib/libtests/timepng.c
> gs/libpng/contrib/pngminim/README
> gs/libpng/contrib/pngminim/decoder/README
> gs/libpng/contrib/pngminim/decoder/makefile
> gs/libpng/contrib/pngminim/decoder/pngusr.dfa
> gs/libpng/contrib/pngminim/decoder/pngusr.h
> gs/libpng/contrib/pngminim/encoder/README
> gs/libpng/contrib/pngminim/encoder/makefile
> gs/libpng/contrib/pngminim/encoder/pngusr.dfa
> gs/libpng/contrib/pngminim/encoder/pngusr.h
> gs/libpng/contrib/pngminim/preader/README
> gs/libpng/contrib/pngminim/preader/makefile
> gs/libpng/contrib/pngminim/preader/pngusr.dfa
> gs/libpng/contrib/pngminim/preader/pngusr.h
> gs/libpng/contrib/pngminus/README
> gs/libpng/contrib/pngminus/makefile.std
> gs/libpng/contrib/pngminus/makefile.tc3
> gs/libpng/contrib/pngminus/makevms.com
> gs/libpng/contrib/pngminus/png2pnm.bat
> gs/libpng/contrib/pngminus/png2pnm.c
> gs/libpng/contrib/pngminus/png2pnm.sh
> gs/libpng/contrib/pngminus/pngminus.bat
> gs/libpng/contrib/pngminus/pngminus.sh
> gs/libpng/contrib/pngminus/pnm2png.bat
> gs/libpng/contrib/pngminus/pnm2png.c
> gs/libpng/contrib/pngminus/pnm2png.sh
> gs/libpng/contrib/pngsuite/README
> gs/libpng/contrib/pngsuite/basn0g01.png
> gs/libpng/contrib/pngsuite/basn0g02.png
> gs/libpng/contrib/pngsuite/basn0g04.png
> gs/libpng/contrib/pngsuite/basn0g08.png
> gs/libpng/contrib/pngsuite/basn0g16.png
> gs/libpng/contrib/pngsuite/basn2c08.png
> gs/libpng/contrib/pngsuite/basn2c16.png
> gs/libpng/contrib/pngsuite/basn3p01.png
> gs/libpng/contrib/pngsuite/basn3p02.png
> gs/libpng/contrib/pngsuite/basn3p04.png
> gs/libpng/contrib/pngsuite/basn3p08.png
> gs/libpng/contrib/pngsuite/basn4a08.png
> gs/libpng/contrib/pngsuite/basn4a16.png
> gs/libpng/contrib/pngsuite/basn6a08.png
> gs/libpng/contrib/pngsuite/basn6a16.png
> gs/libpng/contrib/pngsuite/ftbbn0g01.png
> gs/libpng/contrib/pngsuite/ftbbn0g02.png
> gs/libpng/contrib/pngsuite/ftbbn0g04.png
> gs/libpng/contrib/pngsuite/ftbbn2c16.png
> gs/libpng/contrib/pngsuite/ftbbn3p08.png
> gs/libpng/contrib/pngsuite/ftbgn2c16.png
> gs/libpng/contrib/pngsuite/ftbgn3p08.png
> gs/libpng/contrib/pngsuite/ftbrn2c08.png
> gs/libpng/contrib/pngsuite/ftbwn0g16.png
> gs/libpng/contrib/pngsuite/ftbwn3p08.png
> gs/libpng/contrib/pngsuite/ftbyn3p08.png
> gs/libpng/contrib/pngsuite/ftp0n0g08.png
> gs/libpng/contrib/pngsuite/ftp0n2c08.png
> gs/libpng/contrib/pngsuite/ftp0n3p08.png
> gs/libpng/contrib/pngsuite/ftp1n3p08.png
> gs/libpng/contrib/tools/README.txt
> gs/libpng/contrib/tools/checksum-icc.c
> gs/libpng/contrib/tools/chkfmt
> gs/libpng/contrib/tools/cvtcolor.c
> gs/libpng/contrib/tools/intgamma.sh
> gs/libpng/contrib/tools/makesRGB.c
> gs/libpng/contrib/tools/png-fix-itxt.c
> gs/libpng/contrib/tools/pngfix.c
> gs/libpng/contrib/tools/sRGB.h
> gs/libpng/contrib/visupng/PngFile.c
> gs/libpng/contrib/visupng/PngFile.h
> gs/libpng/contrib/visupng/README.txt
> gs/libpng/contrib/visupng/VisualPng.c
> gs/libpng/contrib/visupng/VisualPng.dsp
> gs/libpng/contrib/visupng/VisualPng.dsw
> gs/libpng/contrib/visupng/VisualPng.ico
> gs/libpng/contrib/visupng/VisualPng.png
> gs/libpng/contrib/visupng/VisualPng.rc
> gs/libpng/contrib/visupng/cexcept.h
> gs/libpng/contrib/visupng/resource.h
> gs/libpng/depcomp
> gs/libpng/example.c
> gs/libpng/install-sh
> gs/libpng/libpng-config.in
> gs/libpng/libpng-manual.txt
> gs/libpng/libpng.3
> gs/libpng/libpng.pc.in
> gs/libpng/libpngpf.3
> gs/libpng/ltmain.sh
> gs/libpng/missing
> gs/libpng/png.5
> gs/libpng/png.c
> gs/libpng/png.h
> gs/libpng/pngbar.jpg
> gs/libpng/pngbar.png
> gs/libpng/pngconf.h
> gs/libpng/pngdebug.h
> gs/libpng/pngerror.c
> gs/libpng/pngget.c
> gs/libpng/pnginfo.h
> gs/libpng/pngmem.c
> gs/libpng/pngnow.png
> gs/libpng/pngpread.c
> gs/libpng/pngpriv.h
> gs/libpng/pngread.c
> gs/libpng/pngrio.c
> gs/libpng/pngrtran.c
> gs/libpng/pngrutil.c
> gs/libpng/pngset.c
> gs/libpng/pngstruct.h
> gs/libpng/pngtest.c
> gs/libpng/pngtest.png
> gs/libpng/pngtrans.c
> gs/libpng/pngusr.dfa
> gs/libpng/pngwio.c
> gs/libpng/pngwrite.c
> gs/libpng/pngwtran.c
> gs/libpng/pngwutil.c
> gs/libpng/projects/owatcom/libpng.tgt
> gs/libpng/projects/owatcom/libpng.wpj
> gs/libpng/projects/owatcom/pngconfig.mak
> gs/libpng/projects/owatcom/pngstest.tgt
> gs/libpng/projects/owatcom/pngtest.tgt
> gs/libpng/projects/owatcom/pngvalid.tgt
> gs/libpng/projects/visualc71/PRJ0041.mak
> gs/libpng/projects/visualc71/README.txt
> gs/libpng/projects/visualc71/README_zlib.txt
> gs/libpng/projects/visualc71/libpng.sln
> gs/libpng/projects/visualc71/libpng.vcproj
> gs/libpng/projects/visualc71/pngtest.vcproj
> gs/libpng/projects/visualc71/zlib.vcproj
> gs/libpng/projects/vstudio/WARNING
> gs/libpng/projects/vstudio/libpng/libpng.vcxproj
> gs/libpng/projects/vstudio/pnglibconf/pnglibconf.vcxproj
> gs/libpng/projects/vstudio/pngstest/pngstest.vcxproj
> gs/libpng/projects/vstudio/pngtest/pngtest.vcxproj
> gs/libpng/projects/vstudio/pngunknown/pngunknown.vcxproj
> gs/libpng/projects/vstudio/pngvalid/pngvalid.vcxproj
> gs/libpng/projects/vstudio/readme.txt
> gs/libpng/projects/vstudio/vstudio.sln
> gs/libpng/projects/vstudio/zlib.props
> gs/libpng/projects/vstudio/zlib/zlib.vcxproj
> gs/libpng/scripts/README.txt
> gs/libpng/scripts/SCOPTIONS.ppc
> gs/libpng/scripts/checksym.awk
> gs/libpng/scripts/def.c
> gs/libpng/scripts/descrip.mms
> gs/libpng/scripts/dfn.awk
> gs/libpng/scripts/intprefix.c
> gs/libpng/scripts/libpng-config-body.in
> gs/libpng/scripts/libpng-config-head.in
> gs/libpng/scripts/libpng.pc.in
> gs/libpng/scripts/libtool.m4
> gs/libpng/scripts/ltoptions.m4
> gs/libpng/scripts/ltsugar.m4
> gs/libpng/scripts/ltversion.m4
> gs/libpng/scripts/lt~obsolete.m4
> gs/libpng/scripts/macro.lst
> gs/libpng/scripts/makefile.32sunu
> gs/libpng/scripts/makefile.64sunu
> gs/libpng/scripts/makefile.acorn
> gs/libpng/scripts/makefile.aix
> gs/libpng/scripts/makefile.amiga
> gs/libpng/scripts/makefile.atari
> gs/libpng/scripts/makefile.bc32
> gs/libpng/scripts/makefile.beos
> gs/libpng/scripts/makefile.bor
> gs/libpng/scripts/makefile.cegcc
> gs/libpng/scripts/makefile.darwin
> gs/libpng/scripts/makefile.dec
> gs/libpng/scripts/makefile.dj2
> gs/libpng/scripts/makefile.freebsd
> gs/libpng/scripts/makefile.gcc
> gs/libpng/scripts/makefile.hp64
> gs/libpng/scripts/makefile.hpgcc
> gs/libpng/scripts/makefile.hpux
> gs/libpng/scripts/makefile.ibmc
> gs/libpng/scripts/makefile.intel
> gs/libpng/scripts/makefile.knr
> gs/libpng/scripts/makefile.linux
> gs/libpng/scripts/makefile.mips
> gs/libpng/scripts/makefile.msc
> gs/libpng/scripts/makefile.msys
> gs/libpng/scripts/makefile.ne12bsd
> gs/libpng/scripts/makefile.netbsd
> gs/libpng/scripts/makefile.openbsd
> gs/libpng/scripts/makefile.sco
> gs/libpng/scripts/makefile.sggcc
> gs/libpng/scripts/makefile.sgi
> gs/libpng/scripts/makefile.so9
> gs/libpng/scripts/makefile.solaris
> gs/libpng/scripts/makefile.solaris-x86
> gs/libpng/scripts/makefile.std
> gs/libpng/scripts/makefile.sunos
> gs/libpng/scripts/makefile.tc3
> gs/libpng/scripts/makefile.vcwin32
> gs/libpng/scripts/makevms.com
> gs/libpng/scripts/options.awk
> gs/libpng/scripts/pnglibconf.dfa
> gs/libpng/scripts/pnglibconf.h.prebuilt
> gs/libpng/scripts/pnglibconf.mak
> gs/libpng/scripts/pngwin.rc
> gs/libpng/scripts/prefix.c
> gs/libpng/scripts/smakefile.ppc
> gs/libpng/scripts/sym.c
> gs/libpng/scripts/symbols.c
> gs/libpng/scripts/symbols.def
> gs/libpng/scripts/vers.c
> gs/libpng/test-driver
> gs/libpng/tests/pngimage-full
> gs/libpng/tests/pngimage-quick
> gs/libpng/tests/pngstest
> gs/libpng/tests/pngstest-0g01
> gs/libpng/tests/pngstest-0g02
> gs/libpng/tests/pngstest-0g04
> gs/libpng/tests/pngstest-0g08
> gs/libpng/tests/pngstest-0g16
> gs/libpng/tests/pngstest-2c08
> gs/libpng/tests/pngstest-2c16
> gs/libpng/tests/pngstest-3p01
> gs/libpng/tests/pngstest-3p02
> gs/libpng/tests/pngstest-3p04
> gs/libpng/tests/pngstest-3p08
> gs/libpng/tests/pngstest-4a08
> gs/libpng/tests/pngstest-4a16
> gs/libpng/tests/pngstest-6a08
> gs/libpng/tests/pngstest-6a16
> gs/libpng/tests/pngstest-error
> gs/libpng/tests/pngtest
> gs/libpng/tests/pngunknown-IDAT
> gs/libpng/tests/pngunknown-discard
> gs/libpng/tests/pngunknown-if-safe
> gs/libpng/tests/pngunknown-sAPI
> gs/libpng/tests/pngunknown-sTER
> gs/libpng/tests/pngunknown-save
> gs/libpng/tests/pngunknown-vpAg
> gs/libpng/tests/pngvalid-gamma-16-to-8
> gs/libpng/tests/pngvalid-gamma-alpha-mode
> gs/libpng/tests/pngvalid-gamma-background
> gs/libpng/tests/pngvalid-gamma-expand16-alpha-mode
> gs/libpng/tests/pngvalid-gamma-expand16-background
> gs/libpng/tests/pngvalid-gamma-expand16-transform
> gs/libpng/tests/pngvalid-gamma-sbit
> gs/libpng/tests/pngvalid-gamma-threshold
> gs/libpng/tests/pngvalid-gamma-transform
> gs/libpng/tests/pngvalid-progressive-interlace-size
> gs/libpng/tests/pngvalid-progressive-interlace-standard
> gs/libpng/tests/pngvalid-progressive-interlace-transform
> gs/libpng/tests/pngvalid-progressive-standard
> gs/libpng/tests/pngvalid-standard
> gs/man/de/dvipdf.1
> gs/man/de/font2c.1
> gs/man/de/gsnd.1
> gs/man/de/pdf2dsc.1
> gs/man/de/pdf2ps.1
> gs/man/de/printafm.1
> gs/man/de/ps2ascii.1
> gs/man/de/ps2pdf.1
> gs/man/de/ps2ps.1
> gs/man/de/wftopfa.1
> gs/man/dvipdf.1
> gs/man/eps2eps.1
> gs/man/font2c.1
> gs/man/gs.1
> gs/man/gslp.1
> gs/man/gsnd.1
> gs/man/pdf2dsc.1
> gs/man/pdf2ps.1
> gs/man/pf2afm.1
> gs/man/pfbtopfa.1
> gs/man/printafm.1
> gs/man/ps2ascii.1
> gs/man/ps2epsi.1
> gs/man/ps2pdf.1
> gs/man/ps2pdfwr.1
> gs/man/ps2ps.1
> gs/man/wftopfa.1
> gs/openjpeg/AUTHORS
> gs/openjpeg/CHANGES
> gs/openjpeg/LICENSE
> gs/openjpeg/NEWS
> gs/openjpeg/THANKS
> gs/openjpeg/src/lib/openjp2/CMakeLists.txt
> gs/openjpeg/src/lib/openjp2/bio.c
> gs/openjpeg/src/lib/openjp2/bio.h
> gs/openjpeg/src/lib/openjp2/cidx_manager.c
> gs/openjpeg/src/lib/openjp2/cidx_manager.h
> gs/openjpeg/src/lib/openjp2/cio.c
> gs/openjpeg/src/lib/openjp2/cio.h
> gs/openjpeg/src/lib/openjp2/dwt.c
> gs/openjpeg/src/lib/openjp2/dwt.h
> gs/openjpeg/src/lib/openjp2/event.c
> gs/openjpeg/src/lib/openjp2/event.h
> gs/openjpeg/src/lib/openjp2/function_list.c
> gs/openjpeg/src/lib/openjp2/function_list.h
> gs/openjpeg/src/lib/openjp2/image.c
> gs/openjpeg/src/lib/openjp2/image.h
> gs/openjpeg/src/lib/openjp2/indexbox_manager.h
> gs/openjpeg/src/lib/openjp2/invert.c
> gs/openjpeg/src/lib/openjp2/invert.h
> gs/openjpeg/src/lib/openjp2/j2k.c
> gs/openjpeg/src/lib/openjp2/j2k.h
> gs/openjpeg/src/lib/openjp2/jp2.c
> gs/openjpeg/src/lib/openjp2/jp2.h
> gs/openjpeg/src/lib/openjp2/libopenjp2.pc.cmake.in
> gs/openjpeg/src/lib/openjp2/mct.c
> gs/openjpeg/src/lib/openjp2/mct.h
> gs/openjpeg/src/lib/openjp2/mqc.c
> gs/openjpeg/src/lib/openjp2/mqc.h
> gs/openjpeg/src/lib/openjp2/openjpeg.c
> gs/openjpeg/src/lib/openjp2/openjpeg.h
> gs/openjpeg/src/lib/openjp2/opj_clock.c
> gs/openjpeg/src/lib/openjp2/opj_clock.h
> gs/openjpeg/src/lib/openjp2/opj_codec.h
> gs/openjpeg/src/lib/openjp2/opj_config.h
> gs/openjpeg/src/lib/openjp2/opj_config.h.cmake.in
> gs/openjpeg/src/lib/openjp2/opj_config_private.h
> gs/openjpeg/src/lib/openjp2/opj_config_private.h.cmake.in
> gs/openjpeg/src/lib/openjp2/opj_includes.h
> gs/openjpeg/src/lib/openjp2/opj_intmath.h
> gs/openjpeg/src/lib/openjp2/opj_inttypes.h
> gs/openjpeg/src/lib/openjp2/opj_malloc.h
> gs/openjpeg/src/lib/openjp2/opj_stdint.h
> gs/openjpeg/src/lib/openjp2/phix_manager.c
> gs/openjpeg/src/lib/openjp2/pi.c
> gs/openjpeg/src/lib/openjp2/pi.h
> gs/openjpeg/src/lib/openjp2/ppix_manager.c
> gs/openjpeg/src/lib/openjp2/raw.c
> gs/openjpeg/src/lib/openjp2/raw.h
> gs/openjpeg/src/lib/openjp2/t1.c
> gs/openjpeg/src/lib/openjp2/t1.h
> gs/openjpeg/src/lib/openjp2/t1_generate_luts.c
> gs/openjpeg/src/lib/openjp2/t1_luts.h
> gs/openjpeg/src/lib/openjp2/t2.c
> gs/openjpeg/src/lib/openjp2/t2.h
> gs/openjpeg/src/lib/openjp2/tcd.c
> gs/openjpeg/src/lib/openjp2/tcd.h
> gs/openjpeg/src/lib/openjp2/tgt.c
> gs/openjpeg/src/lib/openjp2/tgt.h
> gs/openjpeg/src/lib/openjp2/thix_manager.c
> gs/openjpeg/src/lib/openjp2/tpix_manager.c
> gs/psi/apitest.c
> gs/psi/bfont.h
> gs/psi/btoken.h
> gs/psi/dmmain.c
> gs/psi/dmmain.r
> gs/psi/dpmain.c
> gs/psi/dscparse.c
> gs/psi/dscparse.h
> gs/psi/dstack.h
> gs/psi/dw32c.def
> gs/psi/dw64c.def
> gs/psi/dwdll.c
> gs/psi/dwdll.h
> gs/psi/dwimg.c
> gs/psi/dwimg.h
> gs/psi/dwmain.c
> gs/psi/dwmain.rc
> gs/psi/dwmain32.def
> gs/psi/dwmain64.def
> gs/psi/dwmainc.c
> gs/psi/dwnodll.c
> gs/psi/dwreg.c
> gs/psi/dwreg.h
> gs/psi/dwres.h
> gs/psi/dwsetup.def
> gs/psi/dwsetup_x64.manifest
> gs/psi/dwsetup_x86.manifest
> gs/psi/dwtext.c
> gs/psi/dwtext.h
> gs/psi/dwtrace.c
> gs/psi/dwtrace.h
> gs/psi/dwuninst.def
> gs/psi/dwuninst_x64.manifest
> gs/psi/dwuninst_x86.manifest
> gs/psi/dxmain.c
> gs/psi/dxmainc.c
> gs/psi/estack.h
> gs/psi/files.h
> gs/psi/ghost.h
> gs/psi/gs.c
> gs/psi/gsdll.c
> gs/psi/gsdll2.def
> gs/psi/gsdll2.rc
> gs/psi/gsdll32.def
> gs/psi/gsdll32.rc
> gs/psi/gsdll32metro.def
> gs/psi/gsdll32w.lnk
> gs/psi/gsdll64.def
> gs/psi/gsdll64metro.def
> gs/psi/gsdllARM32metro.def
> gs/psi/gserver.c
> gs/psi/gsos2.def
> gs/psi/gsos2.icx
> gs/psi/gsos2.rc
> gs/psi/ialloc.c
> gs/psi/ialloc.h
> gs/psi/iapi.c
> gs/psi/iapi.h
> gs/psi/iastate.h
> gs/psi/iastruct.h
> gs/psi/ibnum.c
> gs/psi/ibnum.h
> gs/psi/ichar.h
> gs/psi/ichar1.h
> gs/psi/icharout.h
> gs/psi/icid.h
> gs/psi/icie.h
> gs/psi/icolor.h
> gs/psi/iconf.c
> gs/psi/iconf.h
> gs/psi/icontext.c
> gs/psi/icontext.h
> gs/psi/icremap.h
> gs/psi/icsmap.h
> gs/psi/icstate.h
> gs/psi/iddict.h
> gs/psi/iddstack.h
> gs/psi/idebug.c
> gs/psi/idebug.h
> gs/psi/idict.c
> gs/psi/idict.h
> gs/psi/idictdef.h
> gs/psi/idicttpl.h
> gs/psi/idisp.c
> gs/psi/idisp.h
> gs/psi/idosave.h
> gs/psi/idparam.c
> gs/psi/idparam.h
> gs/psi/idsdata.h
> gs/psi/idstack.c
> gs/psi/idstack.h
> gs/psi/ierrors.h
> gs/psi/iesdata.h
> gs/psi/iestack.h
> gs/psi/ifapi.h
> gs/psi/ifcid.h
> gs/psi/ifilter.h
> gs/psi/ifilter2.h
> gs/psi/ifont.h
> gs/psi/ifont1.h
> gs/psi/ifont2.h
> gs/psi/ifont42.h
> gs/psi/ifrpred.h
> gs/psi/ifunc.h
> gs/psi/ifwpred.h
> gs/psi/igc.c
> gs/psi/igc.h
> gs/psi/igcref.c
> gs/psi/igcstr.c
> gs/psi/igcstr.h
> gs/psi/igstate.h
> gs/psi/iht.h
> gs/psi/iimage.h
> gs/psi/iimage2.h
> gs/psi/iinit.c
> gs/psi/iinit.h
> gs/psi/ilevel.h
> gs/psi/ilocate.c
> gs/psi/imain.c
> gs/psi/imain.h
> gs/psi/imainarg.c
> gs/psi/imainarg.h
> gs/psi/imemory.h
> gs/psi/iminst.h
> gs/psi/iname.c
> gs/psi/iname.h
> gs/psi/inamedef.h
> gs/psi/inameidx.h
> gs/psi/inames.h
> gs/psi/inamestr.h
> gs/psi/inobtokn.c
> gs/psi/inouparm.c
> gs/psi/int.mak
> gs/psi/interp.c
> gs/psi/interp.h
> gs/psi/iosdata.h
> gs/psi/iostack.h
> gs/psi/ipacked.h
> gs/psi/iparam.c
> gs/psi/iparam.h
> gs/psi/iparray.h
> gs/psi/ipcolor.h
> gs/psi/iplugin.c
> gs/psi/iplugin.h
> gs/psi/ireclaim.c
> gs/psi/iref.h
> gs/psi/isave.c
> gs/psi/isave.h
> gs/psi/iscan.c
> gs/psi/iscan.h
> gs/psi/iscanbin.c
> gs/psi/iscanbin.h
> gs/psi/iscannum.c
> gs/psi/iscannum.h
> gs/psi/isdata.h
> gs/psi/isstate.h
> gs/psi/istack.c
> gs/psi/istack.h
> gs/psi/istkparm.h
> gs/psi/istream.h
> gs/psi/istruct.h
> gs/psi/itoken.h
> gs/psi/iutil.c
> gs/psi/iutil.h
> gs/psi/iutil2.c
> gs/psi/iutil2.h
> gs/psi/ivmem2.h
> gs/psi/ivmspace.h
> gs/psi/main.h
> gs/psi/mkfilelt.cpp
> gs/psi/msvc.mak
> gs/psi/msvc32.mak
> gs/psi/msvc64.mak
> gs/psi/nsisinst.nsi
> gs/psi/oparc.h
> gs/psi/opcheck.h
> gs/psi/opdef.h
> gs/psi/oper.h
> gs/psi/opextern.h
> gs/psi/os2.mak
> gs/psi/ostack.h
> gs/psi/psromfs.mak
> gs/psi/sfilter1.c
> gs/psi/store.h
> gs/psi/winint.mak
> gs/psi/zalg.c
> gs/psi/zarith.c
> gs/psi/zarray.c
> gs/psi/zbfont.c
> gs/psi/zbseq.c
> gs/psi/zcfont.c
> gs/psi/zchar.c
> gs/psi/zchar1.c
> gs/psi/zchar2.c
> gs/psi/zchar32.c
> gs/psi/zchar42.c
> gs/psi/zchar42.h
> gs/psi/zcharout.c
> gs/psi/zcharx.c
> gs/psi/zcid.c
> gs/psi/zcidtest.c
> gs/psi/zcie.c
> gs/psi/zcie.h
> gs/psi/zcolor.c
> gs/psi/zcolor.h
> gs/psi/zcolor1.c
> gs/psi/zcolor2.c
> gs/psi/zcolor3.c
> gs/psi/zcontext.c
> gs/psi/zcontrol.c
> gs/psi/zcrd.c
> gs/psi/zcsdevn.c
> gs/psi/zcsindex.c
> gs/psi/zcspixel.c
> gs/psi/zcssepr.c
> gs/psi/zdevcal.c
> gs/psi/zdevice.c
> gs/psi/zdevice2.c
> gs/psi/zdfilter.c
> gs/psi/zdict.c
> gs/psi/zdosio.c
> gs/psi/zdouble.c
> gs/psi/zdpnext.c
> gs/psi/zdps.c
> gs/psi/zdps1.c
> gs/psi/zdscpars.c
> gs/psi/zfaes.c
> gs/psi/zfapi.c
> gs/psi/zfarc4.c
> gs/psi/zfbcp.c
> gs/psi/zfcid.c
> gs/psi/zfcid0.c
> gs/psi/zfcid1.c
> gs/psi/zfcmap.c
> gs/psi/zfdctd.c
> gs/psi/zfdcte.c
> gs/psi/zfdecode.c
> gs/psi/zfile.c
> gs/psi/zfile.h
> gs/psi/zfile1.c
> gs/psi/zfileio.c
> gs/psi/zfilter.c
> gs/psi/zfilter2.c
> gs/psi/zfilterx.c
> gs/psi/zfimscale.c
> gs/psi/zfjbig2.c
> gs/psi/zfjpx.c
> gs/psi/zfmd5.c
> gs/psi/zfont.c
> gs/psi/zfont0.c
> gs/psi/zfont1.c
> gs/psi/zfont2.c
> gs/psi/zfont32.c
> gs/psi/zfont42.c
> gs/psi/zfontenum.c
> gs/psi/zform.c
> gs/psi/zfproc.c
> gs/psi/zfrsd.c
> gs/psi/zfrsd.h
> gs/psi/zfsample.c
> gs/psi/zfsha2.c
> gs/psi/zfunc.c
> gs/psi/zfunc.h
> gs/psi/zfunc0.c
> gs/psi/zfunc3.c
> gs/psi/zfunc4.c
> gs/psi/zfzlib.c
> gs/psi/zgeneric.c
> gs/psi/zgstate.c
> gs/psi/zhsb.c
> gs/psi/zht.c
> gs/psi/zht1.c
> gs/psi/zht2.c
> gs/psi/zht2.h
> gs/psi/zicc.c
> gs/psi/zicc.h
> gs/psi/zimage.c
> gs/psi/zimage2.c
> gs/psi/zimage3.c
> gs/psi/ziodev.c
> gs/psi/ziodev2.c
> gs/psi/ziodevs.c
> gs/psi/ziodevsc.c
> gs/psi/zmath.c
> gs/psi/zmatrix.c
> gs/psi/zmedia2.c
> gs/psi/zmisc.c
> gs/psi/zmisc1.c
> gs/psi/zmisc2.c
> gs/psi/zmisc3.c
> gs/psi/zncdummy.c
> gs/psi/zpacked.c
> gs/psi/zpaint.c
> gs/psi/zpath.c
> gs/psi/zpath1.c
> gs/psi/zpcolor.c
> gs/psi/zpdf_r6.c
> gs/psi/zpdfops.c
> gs/psi/zrelbit.c
> gs/psi/zrop.c
> gs/psi/zshade.c
> gs/psi/zstack.c
> gs/psi/zstring.c
> gs/psi/zsysvm.c
> gs/psi/ztoken.c
> gs/psi/ztrans.c
> gs/psi/ztrap.c
> gs/psi/ztype.c
> gs/psi/zupath.c
> gs/psi/zusparam.c
> gs/psi/zutf8.c
> gs/psi/zvmem.c
> gs/psi/zvmem2.c
> gs/psi/zwinutf8.c
> gs/tiff/COPYRIGHT
> gs/tiff/ChangeLog
> gs/tiff/HOWTO-RELEASE
> gs/tiff/Makefile.am
> gs/tiff/Makefile.in
> gs/tiff/Makefile.vc
> gs/tiff/README
> gs/tiff/README.vms
> gs/tiff/RELEASE-DATE
> gs/tiff/SConstruct
> gs/tiff/TODO
> gs/tiff/VERSION
> gs/tiff/aclocal.m4
> gs/tiff/autogen.sh
> gs/tiff/build/Makefile.am
> gs/tiff/build/Makefile.in
> gs/tiff/build/README
> gs/tiff/config/compile
> gs/tiff/config/config.guess
> gs/tiff/config/config.sub
> gs/tiff/config/depcomp
> gs/tiff/config/install-sh
> gs/tiff/config/ltmain.sh
> gs/tiff/config/missing
> gs/tiff/config/mkinstalldirs
> gs/tiff/configure
> gs/tiff/configure.ac
> gs/tiff/configure.com
> gs/tiff/contrib/Makefile.am
> gs/tiff/contrib/Makefile.in
> gs/tiff/contrib/README
> gs/tiff/contrib/addtiffo/Makefile.am
> gs/tiff/contrib/addtiffo/Makefile.in
> gs/tiff/contrib/addtiffo/Makefile.vc
> gs/tiff/contrib/addtiffo/README
> gs/tiff/contrib/addtiffo/addtiffo.c
> gs/tiff/contrib/addtiffo/tif_overview.c
> gs/tiff/contrib/addtiffo/tif_ovrcache.c
> gs/tiff/contrib/addtiffo/tif_ovrcache.h
> gs/tiff/contrib/dbs/Makefile.am
> gs/tiff/contrib/dbs/Makefile.in
> gs/tiff/contrib/dbs/README
> gs/tiff/contrib/dbs/tiff-bi.c
> gs/tiff/contrib/dbs/tiff-grayscale.c
> gs/tiff/contrib/dbs/tiff-palette.c
> gs/tiff/contrib/dbs/tiff-rgb.c
> gs/tiff/contrib/dbs/xtiff/Makefile.am
> gs/tiff/contrib/dbs/xtiff/Makefile.in
> gs/tiff/contrib/dbs/xtiff/README
> gs/tiff/contrib/dbs/xtiff/patchlevel.h
> gs/tiff/contrib/dbs/xtiff/xtiff.c
> gs/tiff/contrib/dbs/xtiff/xtifficon.h
> gs/tiff/contrib/iptcutil/Makefile.am
> gs/tiff/contrib/iptcutil/Makefile.in
> gs/tiff/contrib/iptcutil/README
> gs/tiff/contrib/iptcutil/iptcutil.c
> gs/tiff/contrib/iptcutil/test.iptc
> gs/tiff/contrib/iptcutil/test.txt
> gs/tiff/contrib/mfs/Makefile.am
> gs/tiff/contrib/mfs/Makefile.in
> gs/tiff/contrib/mfs/README
> gs/tiff/contrib/mfs/mfs_file.c
> gs/tiff/contrib/pds/Makefile.am
> gs/tiff/contrib/pds/Makefile.in
> gs/tiff/contrib/pds/README
> gs/tiff/contrib/pds/tif_imageiter.c
> gs/tiff/contrib/pds/tif_imageiter.h
> gs/tiff/contrib/pds/tif_pdsdirread.c
> gs/tiff/contrib/pds/tif_pdsdirwrite.c
> gs/tiff/contrib/ras/Makefile.am
> gs/tiff/contrib/ras/Makefile.in
> gs/tiff/contrib/ras/README
> gs/tiff/contrib/ras/ras2tif.c
> gs/tiff/contrib/ras/tif2ras.c
> gs/tiff/contrib/stream/Makefile.am
> gs/tiff/contrib/stream/Makefile.in
> gs/tiff/contrib/stream/README
> gs/tiff/contrib/stream/tiffstream.cpp
> gs/tiff/contrib/stream/tiffstream.h
> gs/tiff/contrib/tags/Makefile.am
> gs/tiff/contrib/tags/Makefile.in
> gs/tiff/contrib/tags/README
> gs/tiff/contrib/tags/listtif.c
> gs/tiff/contrib/tags/maketif.c
> gs/tiff/contrib/tags/xtif_dir.c
> gs/tiff/contrib/tags/xtiffio.h
> gs/tiff/contrib/tags/xtiffiop.h
> gs/tiff/contrib/win_dib/Makefile.am
> gs/tiff/contrib/win_dib/Makefile.in
> gs/tiff/contrib/win_dib/Makefile.w95
> gs/tiff/contrib/win_dib/README.Tiffile
> gs/tiff/contrib/win_dib/README.tiff2dib
> gs/tiff/contrib/win_dib/Tiffile.cpp
> gs/tiff/contrib/win_dib/tiff2dib.c
> gs/tiff/html/Makefile.am
> gs/tiff/html/Makefile.in
> gs/tiff/html/TIFFTechNote2.html
> gs/tiff/html/addingtags.html
> gs/tiff/html/bugs.html
> gs/tiff/html/build.html
> gs/tiff/html/contrib.html
> gs/tiff/html/document.html
> gs/tiff/html/images.html
> gs/tiff/html/images/Makefile.am
> gs/tiff/html/images/Makefile.in
> gs/tiff/html/images/back.gif
> gs/tiff/html/images/bali.jpg
> gs/tiff/html/images/cat.gif
> gs/tiff/html/images/cover.jpg
> gs/tiff/html/images/cramps.gif
> gs/tiff/html/images/dave.gif
> gs/tiff/html/images/info.gif
> gs/tiff/html/images/jello.jpg
> gs/tiff/html/images/jim.gif
> gs/tiff/html/images/note.gif
> gs/tiff/html/images/oxford.gif
> gs/tiff/html/images/quad.jpg
> gs/tiff/html/images/ring.gif
> gs/tiff/html/images/smallliz.jpg
> gs/tiff/html/images/strike.gif
> gs/tiff/html/images/warning.gif
> gs/tiff/html/index.html
> gs/tiff/html/internals.html
> gs/tiff/html/intro.html
> gs/tiff/html/libtiff.html
> gs/tiff/html/man/Makefile.am
> gs/tiff/html/man/Makefile.in
> gs/tiff/html/man/TIFFClose.3tiff.html
> gs/tiff/html/man/TIFFDataWidth.3tiff.html
> gs/tiff/html/man/TIFFError.3tiff.html
> gs/tiff/html/man/TIFFFlush.3tiff.html
> gs/tiff/html/man/TIFFGetField.3tiff.html
> gs/tiff/html/man/TIFFOpen.3tiff.html
> gs/tiff/html/man/TIFFPrintDirectory.3tiff.html
> gs/tiff/html/man/TIFFRGBAImage.3tiff.html
> gs/tiff/html/man/TIFFReadDirectory.3tiff.html
> gs/tiff/html/man/TIFFReadEncodedStrip.3tiff.html
> gs/tiff/html/man/TIFFReadEncodedTile.3tiff.html
> gs/tiff/html/man/TIFFReadRGBAImage.3tiff.html
> gs/tiff/html/man/TIFFReadRGBAStrip.3tiff.html
> gs/tiff/html/man/TIFFReadRGBATile.3tiff.html
> gs/tiff/html/man/TIFFReadRawStrip.3tiff.html
> gs/tiff/html/man/TIFFReadRawTile.3tiff.html
> gs/tiff/html/man/TIFFReadScanline.3tiff.html
> gs/tiff/html/man/TIFFReadTile.3tiff.html
> gs/tiff/html/man/TIFFSetDirectory.3tiff.html
> gs/tiff/html/man/TIFFSetField.3tiff.html
> gs/tiff/html/man/TIFFWarning.3tiff.html
> gs/tiff/html/man/TIFFWriteDirectory.3tiff.html
> gs/tiff/html/man/TIFFWriteEncodedStrip.3tiff.html
> gs/tiff/html/man/TIFFWriteEncodedTile.3tiff.html
> gs/tiff/html/man/TIFFWriteRawStrip.3tiff.html
> gs/tiff/html/man/TIFFWriteRawTile.3tiff.html
> gs/tiff/html/man/TIFFWriteScanline.3tiff.html
> gs/tiff/html/man/TIFFWriteTile.3tiff.html
> gs/tiff/html/man/TIFFbuffer.3tiff.html
> gs/tiff/html/man/TIFFcodec.3tiff.html
> gs/tiff/html/man/TIFFcolor.3tiff.html
> gs/tiff/html/man/TIFFmemory.3tiff.html
> gs/tiff/html/man/TIFFquery.3tiff.html
> gs/tiff/html/man/TIFFsize.3tiff.html
> gs/tiff/html/man/TIFFstrip.3tiff.html
> gs/tiff/html/man/TIFFswab.3tiff.html
> gs/tiff/html/man/TIFFtile.3tiff.html
> gs/tiff/html/man/fax2ps.1.html
> gs/tiff/html/man/fax2tiff.1.html
> gs/tiff/html/man/gif2tiff.1.html
> gs/tiff/html/man/index.html
> gs/tiff/html/man/libtiff.3tiff.html
> gs/tiff/html/man/pal2rgb.1.html
> gs/tiff/html/man/ppm2tiff.1.html
> gs/tiff/html/man/ras2tiff.1.html
> gs/tiff/html/man/raw2tiff.1.html
> gs/tiff/html/man/rgb2ycbcr.1.html
> gs/tiff/html/man/sgi2tiff.1.html
> gs/tiff/html/man/thumbnail.1.html
> gs/tiff/html/man/tiff2bw.1.html
> gs/tiff/html/man/tiff2pdf.1.html
> gs/tiff/html/man/tiff2ps.1.html
> gs/tiff/html/man/tiff2rgba.1.html
> gs/tiff/html/man/tiffcmp.1.html
> gs/tiff/html/man/tiffcp.1.html
> gs/tiff/html/man/tiffcrop.1.html
> gs/tiff/html/man/tiffdither.1.html
> gs/tiff/html/man/tiffdump.1.html
> gs/tiff/html/man/tiffgt.1.html
> gs/tiff/html/man/tiffinfo.1.html
> gs/tiff/html/man/tiffmedian.1.html
> gs/tiff/html/man/tiffset.1.html
> gs/tiff/html/man/tiffsplit.1.html
> gs/tiff/html/man/tiffsv.1.html
> gs/tiff/html/misc.html
> gs/tiff/html/support.html
> gs/tiff/html/tools.html
> gs/tiff/html/v3.4beta007.html
> gs/tiff/html/v3.4beta016.html
> gs/tiff/html/v3.4beta018.html
> gs/tiff/html/v3.4beta024.html
> gs/tiff/html/v3.4beta028.html
> gs/tiff/html/v3.4beta029.html
> gs/tiff/html/v3.4beta031.html
> gs/tiff/html/v3.4beta032.html
> gs/tiff/html/v3.4beta033.html
> gs/tiff/html/v3.4beta034.html
> gs/tiff/html/v3.4beta035.html
> gs/tiff/html/v3.4beta036.html
> gs/tiff/html/v3.5.1.html
> gs/tiff/html/v3.5.2.html
> gs/tiff/html/v3.5.3.html
> gs/tiff/html/v3.5.4.html
> gs/tiff/html/v3.5.5.html
> gs/tiff/html/v3.5.6-beta.html
> gs/tiff/html/v3.5.7.html
> gs/tiff/html/v3.6.0.html
> gs/tiff/html/v3.6.1.html
> gs/tiff/html/v3.7.0.html
> gs/tiff/html/v3.7.0alpha.html
> gs/tiff/html/v3.7.0beta.html
> gs/tiff/html/v3.7.0beta2.html
> gs/tiff/html/v3.7.1.html
> gs/tiff/html/v3.7.2.html
> gs/tiff/html/v3.7.3.html
> gs/tiff/html/v3.7.4.html
> gs/tiff/html/v3.8.0.html
> gs/tiff/html/v3.8.1.html
> gs/tiff/html/v3.8.2.html
> gs/tiff/html/v3.9.0beta.html
> gs/tiff/html/v3.9.1.html
> gs/tiff/html/v3.9.2.html
> gs/tiff/html/v4.0.0.html
> gs/tiff/libtiff-4.pc.in
> gs/tiff/libtiff/Makefile.am
> gs/tiff/libtiff/Makefile.in
> gs/tiff/libtiff/Makefile.vc
> gs/tiff/libtiff/SConstruct
> gs/tiff/libtiff/libtiff.def
> gs/tiff/libtiff/libtiff.map
> gs/tiff/libtiff/libtiffxx.map
> gs/tiff/libtiff/mkg3states.c
> gs/tiff/libtiff/t4.h
> gs/tiff/libtiff/tif_aux.c
> gs/tiff/libtiff/tif_close.c
> gs/tiff/libtiff/tif_codec.c
> gs/tiff/libtiff/tif_color.c
> gs/tiff/libtiff/tif_compress.c
> gs/tiff/libtiff/tif_config.h-vms
> gs/tiff/libtiff/tif_config.h.in
> gs/tiff/libtiff/tif_config.vc.h
> gs/tiff/libtiff/tif_config.wince.h
> gs/tiff/libtiff/tif_dir.c
> gs/tiff/libtiff/tif_dir.h
> gs/tiff/libtiff/tif_dirinfo.c
> gs/tiff/libtiff/tif_dirread.c
> gs/tiff/libtiff/tif_dirwrite.c
> gs/tiff/libtiff/tif_dumpmode.c
> gs/tiff/libtiff/tif_error.c
> gs/tiff/libtiff/tif_extension.c
> gs/tiff/libtiff/tif_fax3.c
> gs/tiff/libtiff/tif_fax3.h
> gs/tiff/libtiff/tif_fax3sm.c
> gs/tiff/libtiff/tif_flush.c
> gs/tiff/libtiff/tif_getimage.c
> gs/tiff/libtiff/tif_jbig.c
> gs/tiff/libtiff/tif_jpeg.c
> gs/tiff/libtiff/tif_jpeg_12.c
> gs/tiff/libtiff/tif_luv.c
> gs/tiff/libtiff/tif_lzma.c
> gs/tiff/libtiff/tif_lzw.c
> gs/tiff/libtiff/tif_next.c
> gs/tiff/libtiff/tif_ojpeg.c
> gs/tiff/libtiff/tif_open.c
> gs/tiff/libtiff/tif_packbits.c
> gs/tiff/libtiff/tif_pixarlog.c
> gs/tiff/libtiff/tif_predict.c
> gs/tiff/libtiff/tif_predict.h
> gs/tiff/libtiff/tif_print.c
> gs/tiff/libtiff/tif_read.c
> gs/tiff/libtiff/tif_stream.cxx
> gs/tiff/libtiff/tif_strip.c
> gs/tiff/libtiff/tif_swab.c
> gs/tiff/libtiff/tif_thunder.c
> gs/tiff/libtiff/tif_tile.c
> gs/tiff/libtiff/tif_unix.c
> gs/tiff/libtiff/tif_version.c
> gs/tiff/libtiff/tif_warning.c
> gs/tiff/libtiff/tif_win32.c
> gs/tiff/libtiff/tif_write.c
> gs/tiff/libtiff/tif_zip.c
> gs/tiff/libtiff/tiff.h
> gs/tiff/libtiff/tiffconf.h.in
> gs/tiff/libtiff/tiffconf.vc.h
> gs/tiff/libtiff/tiffconf.wince.h
> gs/tiff/libtiff/tiffio.h
> gs/tiff/libtiff/tiffio.hxx
> gs/tiff/libtiff/tiffiop.h
> gs/tiff/libtiff/tiffvers.h
> gs/tiff/libtiff/uvcode.h
> gs/tiff/m4/acinclude.m4
> gs/tiff/m4/libtool.m4
> gs/tiff/m4/ltoptions.m4
> gs/tiff/m4/ltsugar.m4
> gs/tiff/m4/ltversion.m4
> gs/tiff/m4/lt~obsolete.m4
> gs/tiff/man/Makefile.am
> gs/tiff/man/Makefile.in
> gs/tiff/man/TIFFClose.3tiff
> gs/tiff/man/TIFFDataWidth.3tiff
> gs/tiff/man/TIFFError.3tiff
> gs/tiff/man/TIFFFlush.3tiff
> gs/tiff/man/TIFFGetField.3tiff
> gs/tiff/man/TIFFOpen.3tiff
> gs/tiff/man/TIFFPrintDirectory.3tiff
> gs/tiff/man/TIFFRGBAImage.3tiff
> gs/tiff/man/TIFFReadDirectory.3tiff
> gs/tiff/man/TIFFReadEncodedStrip.3tiff
> gs/tiff/man/TIFFReadEncodedTile.3tiff
> gs/tiff/man/TIFFReadRGBAImage.3tiff
> gs/tiff/man/TIFFReadRGBAStrip.3tiff
> gs/tiff/man/TIFFReadRGBATile.3tiff
> gs/tiff/man/TIFFReadRawStrip.3tiff
> gs/tiff/man/TIFFReadRawTile.3tiff
> gs/tiff/man/TIFFReadScanline.3tiff
> gs/tiff/man/TIFFReadTile.3tiff
> gs/tiff/man/TIFFSetDirectory.3tiff
> gs/tiff/man/TIFFSetField.3tiff
> gs/tiff/man/TIFFWarning.3tiff
> gs/tiff/man/TIFFWriteDirectory.3tiff
> gs/tiff/man/TIFFWriteEncodedStrip.3tiff
> gs/tiff/man/TIFFWriteEncodedTile.3tiff
> gs/tiff/man/TIFFWriteRawStrip.3tiff
> gs/tiff/man/TIFFWriteRawTile.3tiff
> gs/tiff/man/TIFFWriteScanline.3tiff
> gs/tiff/man/TIFFWriteTile.3tiff
> gs/tiff/man/TIFFbuffer.3tiff
> gs/tiff/man/TIFFcodec.3tiff
> gs/tiff/man/TIFFcolor.3tiff
> gs/tiff/man/TIFFmemory.3tiff
> gs/tiff/man/TIFFquery.3tiff
> gs/tiff/man/TIFFsize.3tiff
> gs/tiff/man/TIFFstrip.3tiff
> gs/tiff/man/TIFFswab.3tiff
> gs/tiff/man/TIFFtile.3tiff
> gs/tiff/man/bmp2tiff.1
> gs/tiff/man/fax2ps.1
> gs/tiff/man/fax2tiff.1
> gs/tiff/man/gif2tiff.1
> gs/tiff/man/libtiff.3tiff
> gs/tiff/man/pal2rgb.1
> gs/tiff/man/ppm2tiff.1
> gs/tiff/man/ras2tiff.1
> gs/tiff/man/raw2tiff.1
> gs/tiff/man/rgb2ycbcr.1
> gs/tiff/man/sgi2tiff.1
> gs/tiff/man/thumbnail.1
> gs/tiff/man/tiff2bw.1
> gs/tiff/man/tiff2pdf.1
> gs/tiff/man/tiff2ps.1
> gs/tiff/man/tiff2rgba.1
> gs/tiff/man/tiffcmp.1
> gs/tiff/man/tiffcp.1
> gs/tiff/man/tiffcrop.1
> gs/tiff/man/tiffdither.1
> gs/tiff/man/tiffdump.1
> gs/tiff/man/tiffgt.1
> gs/tiff/man/tiffinfo.1
> gs/tiff/man/tiffmedian.1
> gs/tiff/man/tiffset.1
> gs/tiff/man/tiffsplit.1
> gs/tiff/man/tiffsv.1
> gs/tiff/nmake.opt
> gs/tiff/port/Makefile.am
> gs/tiff/port/Makefile.in
> gs/tiff/port/Makefile.vc
> gs/tiff/port/dummy.c
> gs/tiff/port/getopt.c
> gs/tiff/port/lfind.c
> gs/tiff/port/libport.h
> gs/tiff/port/strcasecmp.c
> gs/tiff/port/strtoul.c
> gs/tiff/port/strtoull.c
> gs/tiff/test/Makefile.am
> gs/tiff/test/Makefile.in
> gs/tiff/test/ascii_tag.c
> gs/tiff/test/bmp2tiff_palette.sh
> gs/tiff/test/bmp2tiff_rgb.sh
> gs/tiff/test/check_tag.c
> gs/tiff/test/common.sh
> gs/tiff/test/gif2tiff.sh
> gs/tiff/test/images/README.txt
> gs/tiff/test/images/logluv-3c-16b.tiff
> gs/tiff/test/images/minisblack-1c-16b.tiff
> gs/tiff/test/images/minisblack-1c-8b.pgm
> gs/tiff/test/images/minisblack-1c-8b.tiff
> gs/tiff/test/images/minisblack-2c-8b-alpha.tiff
> gs/tiff/test/images/miniswhite-1c-1b.pbm
> gs/tiff/test/images/miniswhite-1c-1b.tiff
> gs/tiff/test/images/palette-1c-1b.tiff
> gs/tiff/test/images/palette-1c-4b.tiff
> gs/tiff/test/images/palette-1c-8b.bmp
> gs/tiff/test/images/palette-1c-8b.gif
> gs/tiff/test/images/palette-1c-8b.tiff
> gs/tiff/test/images/rgb-3c-16b.tiff
> gs/tiff/test/images/rgb-3c-8b.bmp
> gs/tiff/test/images/rgb-3c-8b.ppm
> gs/tiff/test/images/rgb-3c-8b.tiff
> gs/tiff/test/long_tag.c
> gs/tiff/test/ppm2tiff_pbm.sh
> gs/tiff/test/ppm2tiff_pgm.sh
> gs/tiff/test/ppm2tiff_ppm.sh
> gs/tiff/test/rewrite_tag.c
> gs/tiff/test/short_tag.c
> gs/tiff/test/strip.c
> gs/tiff/test/strip_rw.c
> gs/tiff/test/test_arrays.c
> gs/tiff/test/test_arrays.h
> gs/tiff/test/tiff2pdf.sh
> gs/tiff/test/tiff2ps-EPS1.sh
> gs/tiff/test/tiff2ps-PS1.sh
> gs/tiff/test/tiff2ps-PS2.sh
> gs/tiff/test/tiff2ps-PS3.sh
> gs/tiff/test/tiff2rgba-logluv-3c-16b.sh
> gs/tiff/test/tiff2rgba-minisblack-1c-16b.sh
> gs/tiff/test/tiff2rgba-minisblack-1c-8b.sh
> gs/tiff/test/tiff2rgba-minisblack-2c-8b-alpha.sh
> gs/tiff/test/tiff2rgba-miniswhite-1c-1b.sh
> gs/tiff/test/tiff2rgba-palette-1c-1b.sh
> gs/tiff/test/tiff2rgba-palette-1c-4b.sh
> gs/tiff/test/tiff2rgba-palette-1c-8b.sh
> gs/tiff/test/tiff2rgba-rgb-3c-16b.sh
> gs/tiff/test/tiff2rgba-rgb-3c-8b.sh
> gs/tiff/test/tiffcp-g3-1d-fill.sh
> gs/tiff/test/tiffcp-g3-1d.sh
> gs/tiff/test/tiffcp-g3-2d-fill.sh
> gs/tiff/test/tiffcp-g3-2d.sh
> gs/tiff/test/tiffcp-g3.sh
> gs/tiff/test/tiffcp-g4.sh
> gs/tiff/test/tiffcp-logluv.sh
> gs/tiff/test/tiffcp-split-join.sh
> gs/tiff/test/tiffcp-split.sh
> gs/tiff/test/tiffcp-thumbnail.sh
> gs/tiff/test/tiffcrop-R90-logluv-3c-16b.sh
> gs/tiff/test/tiffcrop-R90-minisblack-1c-16b.sh
> gs/tiff/test/tiffcrop-R90-minisblack-1c-8b.sh
> gs/tiff/test/tiffcrop-R90-minisblack-2c-8b-alpha.sh
> gs/tiff/test/tiffcrop-R90-miniswhite-1c-1b.sh
> gs/tiff/test/tiffcrop-R90-palette-1c-1b.sh
> gs/tiff/test/tiffcrop-R90-palette-1c-4b.sh
> gs/tiff/test/tiffcrop-R90-palette-1c-8b.sh
> gs/tiff/test/tiffcrop-R90-rgb-3c-16b.sh
> gs/tiff/test/tiffcrop-R90-rgb-3c-8b.sh
> gs/tiff/test/tiffcrop-doubleflip-logluv-3c-16b.sh
> gs/tiff/test/tiffcrop-doubleflip-minisblack-1c-16b.sh
> gs/tiff/test/tiffcrop-doubleflip-minisblack-1c-8b.sh
> gs/tiff/test/tiffcrop-doubleflip-minisblack-2c-8b-alpha.sh
> gs/tiff/test/tiffcrop-doubleflip-miniswhite-1c-1b.sh
> gs/tiff/test/tiffcrop-doubleflip-palette-1c-1b.sh
> gs/tiff/test/tiffcrop-doubleflip-palette-1c-4b.sh
> gs/tiff/test/tiffcrop-doubleflip-palette-1c-8b.sh
> gs/tiff/test/tiffcrop-doubleflip-rgb-3c-16b.sh
> gs/tiff/test/tiffcrop-doubleflip-rgb-3c-8b.sh
> gs/tiff/test/tiffcrop-extract-logluv-3c-16b.sh
> gs/tiff/test/tiffcrop-extract-minisblack-1c-16b.sh
> gs/tiff/test/tiffcrop-extract-minisblack-1c-8b.sh
> gs/tiff/test/tiffcrop-extract-minisblack-2c-8b-alpha.sh
> gs/tiff/test/tiffcrop-extract-miniswhite-1c-1b.sh
> gs/tiff/test/tiffcrop-extract-palette-1c-1b.sh
> gs/tiff/test/tiffcrop-extract-palette-1c-4b.sh
> gs/tiff/test/tiffcrop-extract-palette-1c-8b.sh
> gs/tiff/test/tiffcrop-extract-rgb-3c-16b.sh
> gs/tiff/test/tiffcrop-extract-rgb-3c-8b.sh
> gs/tiff/test/tiffcrop-extractz14-logluv-3c-16b.sh
> gs/tiff/test/tiffcrop-extractz14-minisblack-1c-16b.sh
> gs/tiff/test/tiffcrop-extractz14-minisblack-1c-8b.sh
> gs/tiff/test/tiffcrop-extractz14-minisblack-2c-8b-alpha.sh
> gs/tiff/test/tiffcrop-extractz14-miniswhite-1c-1b.sh
> gs/tiff/test/tiffcrop-extractz14-palette-1c-1b.sh
> gs/tiff/test/tiffcrop-extractz14-palette-1c-4b.sh
> gs/tiff/test/tiffcrop-extractz14-palette-1c-8b.sh
> gs/tiff/test/tiffcrop-extractz14-rgb-3c-16b.sh
> gs/tiff/test/tiffcrop-extractz14-rgb-3c-8b.sh
> gs/tiff/test/tiffdump.sh
> gs/tiff/test/tiffinfo.sh
> gs/tiff/test/tifftest.h
> gs/tiff/tools/Makefile.am
> gs/tiff/tools/Makefile.in
> gs/tiff/tools/Makefile.vc
> gs/tiff/tools/bmp2tiff.c
> gs/tiff/tools/fax2ps.c
> gs/tiff/tools/fax2tiff.c
> gs/tiff/tools/gif2tiff.c
> gs/tiff/tools/pal2rgb.c
> gs/tiff/tools/ppm2tiff.c
> gs/tiff/tools/ras2tiff.c
> gs/tiff/tools/rasterfile.h
> gs/tiff/tools/raw2tiff.c
> gs/tiff/tools/rgb2ycbcr.c
> gs/tiff/tools/sgi2tiff.c
> gs/tiff/tools/sgisv.c
> gs/tiff/tools/thumbnail.c
> gs/tiff/tools/tiff2bw.c
> gs/tiff/tools/tiff2pdf.c
> gs/tiff/tools/tiff2ps.c
> gs/tiff/tools/tiff2rgba.c
> gs/tiff/tools/tiffcmp.c
> gs/tiff/tools/tiffcp.c
> gs/tiff/tools/tiffcrop.c
> gs/tiff/tools/tiffdither.c
> gs/tiff/tools/tiffdump.c
> gs/tiff/tools/tiffgt.c
> gs/tiff/tools/tiffinfo.c
> gs/tiff/tools/tiffmedian.c
> gs/tiff/tools/tiffset.c
> gs/tiff/tools/tiffsplit.c
> gs/tiff/tools/ycbcr.c
> gs/toolbin/GenSubstCID.ps
> gs/toolbin/afmutil.py
> gs/toolbin/apitest.pl
> gs/toolbin/bmpcmp.c
> gs/toolbin/bughunt.sh
> gs/toolbin/bugsByEngineer.pl
> gs/toolbin/checkdeps.pl
> gs/toolbin/color/icc_creator/ICC Profiles/cmyk_k_ouput_only.icc
> gs/toolbin/color/icc_creator/ICC Profiles/ps_emulate_cmyk.icc
> gs/toolbin/color/icc_creator/ICC Profiles/ps_emulate_gray.icc
> gs/toolbin/color/icc_creator/ICC Profiles/ps_emulate_rgb.icc
> gs/toolbin/color/icc_creator/ICC_Creator.sln
> gs/toolbin/color/icc_creator/ICC_Creator/CIELAB.h
> gs/toolbin/color/icc_creator/ICC_Creator/ICC_Creator.cpp
> gs/toolbin/color/icc_creator/ICC_Creator/ICC_Creator.h
> gs/toolbin/color/icc_creator/ICC_Creator/ICC_Creator.rc
> gs/toolbin/color/icc_creator/ICC_Creator/ICC_Creator.vcproj
> gs/toolbin/color/icc_creator/ICC_Creator/ICC_CreatorDlg.cpp
> gs/toolbin/color/icc_creator/ICC_Creator/ICC_CreatorDlg.h
> gs/toolbin/color/icc_creator/ICC_Creator/icc34.h
> gs/toolbin/color/icc_creator/ICC_Creator/icc_create.cpp
> gs/toolbin/color/icc_creator/ICC_Creator/icc_create.h
> gs/toolbin/color/icc_creator/ICC_Creator/res/ICC_Creator.rc2
> gs/toolbin/color/icc_creator/ICC_Creator/res/gsimage_.ico
> gs/toolbin/color/icc_creator/ICC_Creator/res/gswin.ico
> gs/toolbin/color/icc_creator/ICC_Creator/resource.h
> gs/toolbin/color/icc_creator/ICC_Creator/stdafx.cpp
> gs/toolbin/color/icc_creator/ICC_Creator/stdafx.h
> gs/toolbin/color/icc_creator/ICC_Creator/targetver.h
> gs/toolbin/color/icc_creator/README.txt
> gs/toolbin/color/icc_creator/effects/black_output.icc
> gs/toolbin/color/icc_creator/effects/c_only.txt
> gs/toolbin/color/icc_creator/effects/cyan_output.icc
> gs/toolbin/color/icc_creator/effects/k_only.txt
> gs/toolbin/color/icc_creator/effects/m_only.txt
> gs/toolbin/color/icc_creator/effects/magenta_output.icc
> gs/toolbin/color/icc_creator/effects/y_only.txt
> gs/toolbin/color/icc_creator/effects/yellow_output.icc
> gs/toolbin/color/icc_creator/example/artifex_blue_purple.icc
> gs/toolbin/color/icc_creator/example/artifex_tritone.icc
> gs/toolbin/color/icc_creator/example/cielab_values.txt
> gs/toolbin/color/icc_creator/example/color_names.txt
> gs/toolbin/color/icc_creator/example/duotone.pdf
> gs/toolbin/color/icc_creator/example/tritone.pdf
> gs/toolbin/color/icc_creator/example/tritone_cielab.txt
> gs/toolbin/color/icc_creator/example/tritone_names.txt
> gs/toolbin/color/icc_creator/ucr_bg.txt
> gs/toolbin/color/named_color/named_color_table.txt
> gs/toolbin/color/named_color/named_colors.pdf
> gs/toolbin/color/src_color/cmyk_des_renderintent.icc
> gs/toolbin/color/src_color/cmyk_src_cyan.icc
> gs/toolbin/color/src_color/cmyk_src_magenta.icc
> gs/toolbin/color/src_color/cmyk_src_renderintent.icc
> gs/toolbin/color/src_color/cmyk_src_yellow.icc
> gs/toolbin/color/src_color/objsrc_profiles_example.txt
> gs/toolbin/color/src_color/rgb_source_blue.icc
> gs/toolbin/color/src_color/rgb_source_green.icc
> gs/toolbin/color/src_color/rgb_source_red.icc
> gs/toolbin/drawafm.ps
> gs/toolbin/encs2c.ps
> gs/toolbin/errlist.tcl
> gs/toolbin/extractFonts.ps
> gs/toolbin/extractICCprofiles.ps
> gs/toolbin/gen_ldf_jb2.py
> gs/toolbin/genfontmap.ps
> gs/toolbin/gitlog2changelog.py
> gs/toolbin/gitsetup.sh
> gs/toolbin/gsmake
> gs/toolbin/gsmake.tcl
> gs/toolbin/halftone/ETS/README.txt
> gs/toolbin/halftone/ETS/ei03.pdf
> gs/toolbin/halftone/ETS/ets.c
> gs/toolbin/halftone/ETS/ets.h
> gs/toolbin/halftone/ETS/ipview.html
> gs/toolbin/halftone/ETS/test_ets.c
> gs/toolbin/halftone/ETS/tm.h
> gs/toolbin/halftone/ETS/win32/ETS.sln
> gs/toolbin/halftone/ETS/win32/ETS.vcproj
> gs/toolbin/halftone/gen_ordered/README
> gs/toolbin/halftone/gen_ordered/gen_ordered.c
> gs/toolbin/halftone/gen_ordered/gen_ordered.sln
> gs/toolbin/halftone/gen_ordered/gen_ordered.vcproj
> gs/toolbin/halftone/gen_stochastic/gen_stochastic.c
> gs/toolbin/halftone/gen_stochastic/gen_stochastic.sln
> gs/toolbin/halftone/gen_stochastic/gen_stochastic.vcproj
> gs/toolbin/headers.tcl
> gs/toolbin/htmldiff.pl
> gs/toolbin/jpxtopdf.c
> gs/toolbin/leaks.tcl
> gs/toolbin/localcluster/clusterpush.pl
> gs/toolbin/localcluster/clusterpush.txt
> gs/toolbin/localcluster/gitpush.sh
> gs/toolbin/localcluster/readme
> gs/toolbin/makehist.tcl
> gs/toolbin/memory.py
> gs/toolbin/ocheck.py
> gs/toolbin/pdf_info.ps
> gs/toolbin/pdfinflt.ps
> gs/toolbin/performance.pl
> gs/toolbin/pre.chk
> gs/toolbin/pre.tcl
> gs/toolbin/precheck.tcl
> gs/toolbin/pscet_status.pl
> gs/toolbin/search-svn-revs
> gs/toolbin/search/README
> gs/toolbin/smoke.ps
> gs/toolbin/split_changelog.py
> gs/toolbin/squeeze2html.pl
> gs/toolbin/suite.tcl
> gs/toolbin/tests/README
> gs/toolbin/tests/build_revision.py
> gs/toolbin/tests/check_all.py
> gs/toolbin/tests/check_comments.py
> gs/toolbin/tests/check_dirs.py
> gs/toolbin/tests/check_docrefs.py
> gs/toolbin/tests/check_source.py
> gs/toolbin/tests/cmpi.py
> gs/toolbin/tests/collate.py
> gs/toolbin/tests/compare_checksumdb.py
> gs/toolbin/tests/compare_checksums.py
> gs/toolbin/tests/dump_checksum.py
> gs/toolbin/tests/dump_checksum_plus.py
> gs/toolbin/tests/dump_checksum_raw.py
> gs/toolbin/tests/find_unique_file.py
> gs/toolbin/tests/fuzzy.c
> gs/toolbin/tests/get_baseline_log.py
> gs/toolbin/tests/get_baselines.py
> gs/toolbin/tests/gscheck_all.py
> gs/toolbin/tests/gscheck_fuzzypdf.py
> gs/toolbin/tests/gscheck_pdfwrite.py
> gs/toolbin/tests/gscheck_raster.py
> gs/toolbin/tests/gscheck_testfiles.py
> gs/toolbin/tests/gsconf.py
> gs/toolbin/tests/gsparamsets.py
> gs/toolbin/tests/gssum.py
> gs/toolbin/tests/gstestgs.py
> gs/toolbin/tests/gstestutils.py
> gs/toolbin/tests/gsutil.py
> gs/toolbin/tests/gsvalidate.py
> gs/toolbin/tests/main.py
> gs/toolbin/tests/make_baselinedb.py
> gs/toolbin/tests/make_testdb.py
> gs/toolbin/tests/make_two_pdfversions
> gs/toolbin/tests/make_two_versions
> gs/toolbin/tests/myoptparse.py
> gs/toolbin/tests/rasterdb.py
> gs/toolbin/tests/regen_baseline.py
> gs/toolbin/tests/regen_filelist.py
> gs/toolbin/tests/revert_baseline
> gs/toolbin/tests/revert_pdfbaseline
> gs/toolbin/tests/run_nightly
> gs/toolbin/tests/run_nightly.py
> gs/toolbin/tests/run_parallel
> gs/toolbin/tests/run_regression.py
> gs/toolbin/tests/run_series.py
> gs/toolbin/tests/testdiff.py
> gs/toolbin/tests/testing.cfg.example
> gs/toolbin/tests/update_baseline.py
> gs/toolbin/tests/update_specific
> gs/toolbin/tests/updatelist.py
> gs/toolbin/tests/updatelistpdf.py
> gs/toolbin/tests/validate.py
> gs/toolbin/tmake.tcl
> gs/toolbin/vg_bugs.supp
> gs/toolbin/vg_okay.supp
> gs/zlib/CMakeLists.txt
> gs/zlib/ChangeLog
> gs/zlib/FAQ
> gs/zlib/INDEX
> gs/zlib/Makefile
> gs/zlib/Makefile.in
> gs/zlib/README
> gs/zlib/adler32.c
> gs/zlib/amiga/Makefile.pup
> gs/zlib/amiga/Makefile.sas
> gs/zlib/as400/bndsrc
> gs/zlib/as400/compile.clp
> gs/zlib/as400/readme.txt
> gs/zlib/as400/zlib.inc
> gs/zlib/compress.c
> gs/zlib/configure
> gs/zlib/contrib/README.contrib
> gs/zlib/contrib/ada/buffer_demo.adb
> gs/zlib/contrib/ada/mtest.adb
> gs/zlib/contrib/ada/read.adb
> gs/zlib/contrib/ada/readme.txt
> gs/zlib/contrib/ada/test.adb
> gs/zlib/contrib/ada/zlib-streams.adb
> gs/zlib/contrib/ada/zlib-streams.ads
> gs/zlib/contrib/ada/zlib-thin.adb
> gs/zlib/contrib/ada/zlib-thin.ads
> gs/zlib/contrib/ada/zlib.adb
> gs/zlib/contrib/ada/zlib.ads
> gs/zlib/contrib/ada/zlib.gpr
> gs/zlib/contrib/amd64/amd64-match.S
> gs/zlib/contrib/asm686/README.686
> gs/zlib/contrib/asm686/match.S
> gs/zlib/contrib/blast/Makefile
> gs/zlib/contrib/blast/README
> gs/zlib/contrib/blast/blast.c
> gs/zlib/contrib/blast/blast.h
> gs/zlib/contrib/blast/test.pk
> gs/zlib/contrib/blast/test.txt
> gs/zlib/contrib/delphi/ZLib.pas
> gs/zlib/contrib/delphi/ZLibConst.pas
> gs/zlib/contrib/delphi/readme.txt
> gs/zlib/contrib/delphi/zlibd32.mak
> gs/zlib/contrib/dotzlib/DotZLib.build
> gs/zlib/contrib/dotzlib/DotZLib.chm
> gs/zlib/contrib/dotzlib/DotZLib.sln
> gs/zlib/contrib/dotzlib/DotZLib/AssemblyInfo.cs
> gs/zlib/contrib/dotzlib/DotZLib/ChecksumImpl.cs
> gs/zlib/contrib/dotzlib/DotZLib/CircularBuffer.cs
> gs/zlib/contrib/dotzlib/DotZLib/CodecBase.cs
> gs/zlib/contrib/dotzlib/DotZLib/Deflater.cs
> gs/zlib/contrib/dotzlib/DotZLib/DotZLib.cs
> gs/zlib/contrib/dotzlib/DotZLib/DotZLib.csproj
> gs/zlib/contrib/dotzlib/DotZLib/GZipStream.cs
> gs/zlib/contrib/dotzlib/DotZLib/Inflater.cs
> gs/zlib/contrib/dotzlib/DotZLib/UnitTests.cs
> gs/zlib/contrib/dotzlib/LICENSE_1_0.txt
> gs/zlib/contrib/dotzlib/readme.txt
> gs/zlib/contrib/gcc_gvmat64/gvmat64.S
> gs/zlib/contrib/infback9/README
> gs/zlib/contrib/infback9/infback9.c
> gs/zlib/contrib/infback9/infback9.h
> gs/zlib/contrib/infback9/inffix9.h
> gs/zlib/contrib/infback9/inflate9.h
> gs/zlib/contrib/infback9/inftree9.c
> gs/zlib/contrib/infback9/inftree9.h
> gs/zlib/contrib/inflate86/inffas86.c
> gs/zlib/contrib/inflate86/inffast.S
> gs/zlib/contrib/iostream/test.cpp
> gs/zlib/contrib/iostream/zfstream.cpp
> gs/zlib/contrib/iostream/zfstream.h
> gs/zlib/contrib/iostream2/zstream.h
> gs/zlib/contrib/iostream2/zstream_test.cpp
> gs/zlib/contrib/iostream3/README
> gs/zlib/contrib/iostream3/TODO
> gs/zlib/contrib/iostream3/test.cc
> gs/zlib/contrib/iostream3/zfstream.cc
> gs/zlib/contrib/iostream3/zfstream.h
> gs/zlib/contrib/masmx64/bld_ml64.bat
> gs/zlib/contrib/masmx64/gvmat64.asm
> gs/zlib/contrib/masmx64/inffas8664.c
> gs/zlib/contrib/masmx64/inffasx64.asm
> gs/zlib/contrib/masmx64/readme.txt
> gs/zlib/contrib/masmx86/bld_ml32.bat
> gs/zlib/contrib/masmx86/inffas32.asm
> gs/zlib/contrib/masmx86/match686.asm
> gs/zlib/contrib/masmx86/readme.txt
> gs/zlib/contrib/minizip/Makefile
> gs/zlib/contrib/minizip/Makefile.am
> gs/zlib/contrib/minizip/MiniZip64_Changes.txt
> gs/zlib/contrib/minizip/MiniZip64_info.txt
> gs/zlib/contrib/minizip/configure.ac
> gs/zlib/contrib/minizip/crypt.h
> gs/zlib/contrib/minizip/ioapi.c
> gs/zlib/contrib/minizip/ioapi.h
> gs/zlib/contrib/minizip/iowin32.c
> gs/zlib/contrib/minizip/iowin32.h
> gs/zlib/contrib/minizip/make_vms.com
> gs/zlib/contrib/minizip/miniunz.c
> gs/zlib/contrib/minizip/miniunzip.1
> gs/zlib/contrib/minizip/minizip.1
> gs/zlib/contrib/minizip/minizip.c
> gs/zlib/contrib/minizip/minizip.pc.in
> gs/zlib/contrib/minizip/mztools.c
> gs/zlib/contrib/minizip/mztools.h
> gs/zlib/contrib/minizip/unzip.c
> gs/zlib/contrib/minizip/unzip.h
> gs/zlib/contrib/minizip/zip.c
> gs/zlib/contrib/minizip/zip.h
> gs/zlib/contrib/pascal/example.pas
> gs/zlib/contrib/pascal/readme.txt
> gs/zlib/contrib/pascal/zlibd32.mak
> gs/zlib/contrib/pascal/zlibpas.pas
> gs/zlib/contrib/puff/Makefile
> gs/zlib/contrib/puff/README
> gs/zlib/contrib/puff/puff.c
> gs/zlib/contrib/puff/puff.h
> gs/zlib/contrib/puff/pufftest.c
> gs/zlib/contrib/puff/zeros.raw
> gs/zlib/contrib/testzlib/testzlib.c
> gs/zlib/contrib/testzlib/testzlib.txt
> gs/zlib/contrib/untgz/Makefile
> gs/zlib/contrib/untgz/Makefile.msc
> gs/zlib/contrib/untgz/untgz.c
> gs/zlib/contrib/vstudio/readme.txt
> gs/zlib/contrib/vstudio/vc10/miniunz.vcxproj
> gs/zlib/contrib/vstudio/vc10/miniunz.vcxproj.filters
> gs/zlib/contrib/vstudio/vc10/minizip.vcxproj
> gs/zlib/contrib/vstudio/vc10/minizip.vcxproj.filters
> gs/zlib/contrib/vstudio/vc10/testzlib.vcxproj
> gs/zlib/contrib/vstudio/vc10/testzlib.vcxproj.filters
> gs/zlib/contrib/vstudio/vc10/testzlibdll.vcxproj
> gs/zlib/contrib/vstudio/vc10/testzlibdll.vcxproj.filters
> gs/zlib/contrib/vstudio/vc10/zlib.rc
> gs/zlib/contrib/vstudio/vc10/zlibstat.vcxproj
> gs/zlib/contrib/vstudio/vc10/zlibstat.vcxproj.filters
> gs/zlib/contrib/vstudio/vc10/zlibvc.def
> gs/zlib/contrib/vstudio/vc10/zlibvc.sln
> gs/zlib/contrib/vstudio/vc10/zlibvc.vcxproj
> gs/zlib/contrib/vstudio/vc10/zlibvc.vcxproj.filters
> gs/zlib/contrib/vstudio/vc11/miniunz.vcxproj
> gs/zlib/contrib/vstudio/vc11/minizip.vcxproj
> gs/zlib/contrib/vstudio/vc11/testzlib.vcxproj
> gs/zlib/contrib/vstudio/vc11/testzlibdll.vcxproj
> gs/zlib/contrib/vstudio/vc11/zlib.rc
> gs/zlib/contrib/vstudio/vc11/zlibstat.vcxproj
> gs/zlib/contrib/vstudio/vc11/zlibvc.def
> gs/zlib/contrib/vstudio/vc11/zlibvc.sln
> gs/zlib/contrib/vstudio/vc11/zlibvc.vcxproj
> gs/zlib/contrib/vstudio/vc9/miniunz.vcproj
> gs/zlib/contrib/vstudio/vc9/minizip.vcproj
> gs/zlib/contrib/vstudio/vc9/testzlib.vcproj
> gs/zlib/contrib/vstudio/vc9/testzlibdll.vcproj
> gs/zlib/contrib/vstudio/vc9/zlib.rc
> gs/zlib/contrib/vstudio/vc9/zlibstat.vcproj
> gs/zlib/contrib/vstudio/vc9/zlibvc.def
> gs/zlib/contrib/vstudio/vc9/zlibvc.sln
> gs/zlib/contrib/vstudio/vc9/zlibvc.vcproj
> gs/zlib/crc32.c
> gs/zlib/crc32.h
> gs/zlib/deflate.c
> gs/zlib/deflate.h
> gs/zlib/doc/algorithm.txt
> gs/zlib/doc/rfc1950.txt
> gs/zlib/doc/rfc1951.txt
> gs/zlib/doc/rfc1952.txt
> gs/zlib/doc/txtvsbin.txt
> gs/zlib/examples/README.examples
> gs/zlib/examples/enough.c
> gs/zlib/examples/fitblk.c
> gs/zlib/examples/gun.c
> gs/zlib/examples/gzappend.c
> gs/zlib/examples/gzjoin.c
> gs/zlib/examples/gzlog.c
> gs/zlib/examples/gzlog.h
> gs/zlib/examples/zlib_how.html
> gs/zlib/examples/zpipe.c
> gs/zlib/examples/zran.c
> gs/zlib/gzclose.c
> gs/zlib/gzguts.h
> gs/zlib/gzlib.c
> gs/zlib/gzread.c
> gs/zlib/gzwrite.c
> gs/zlib/infback.c
> gs/zlib/inffast.c
> gs/zlib/inffast.h
> gs/zlib/inffixed.h
> gs/zlib/inflate.c
> gs/zlib/inflate.h
> gs/zlib/inftrees.c
> gs/zlib/inftrees.h
> gs/zlib/make_vms.com
> gs/zlib/msdos/Makefile.bor
> gs/zlib/msdos/Makefile.dj2
> gs/zlib/msdos/Makefile.emx
> gs/zlib/msdos/Makefile.msc
> gs/zlib/msdos/Makefile.tc
> gs/zlib/nintendods/Makefile
> gs/zlib/nintendods/README
> gs/zlib/old/Makefile.emx
> gs/zlib/old/Makefile.riscos
> gs/zlib/old/README
> gs/zlib/old/descrip.mms
> gs/zlib/old/os2/Makefile.os2
> gs/zlib/old/os2/zlib.def
> gs/zlib/old/visual-basic.txt
> gs/zlib/qnx/package.qpg
> gs/zlib/test/example.c
> gs/zlib/test/infcover.c
> gs/zlib/test/minigzip.c
> gs/zlib/treebuild.xml
> gs/zlib/trees.c
> gs/zlib/trees.h
> gs/zlib/uncompr.c
> gs/zlib/watcom/watcom_f.mak
> gs/zlib/watcom/watcom_l.mak
> gs/zlib/win32/DLL_FAQ.txt
> gs/zlib/win32/Makefile.bor
> gs/zlib/win32/Makefile.gcc
> gs/zlib/win32/Makefile.msc
> gs/zlib/win32/README-WIN32.txt
> gs/zlib/win32/VisualC.txt
> gs/zlib/win32/zlib.def
> gs/zlib/win32/zlib1.rc
> gs/zlib/zconf.h
> gs/zlib/zconf.h.cmakein
> gs/zlib/zconf.h.in
> gs/zlib/zlib.3
> gs/zlib/zlib.3.pdf
> gs/zlib/zlib.h
> gs/zlib/zlib.map
> gs/zlib/zlib.pc.cmakein
> gs/zlib/zlib.pc.in
> gs/zlib/zlib2ansi
> gs/zlib/zutil.c
> gs/zlib/zutil.h
> iccprofiles/default_cmyk.icc
> iccprofiles/default_gray.icc
> iccprofiles/default_rgb.icc
> iccprofiles/gray_to_k.icc
> iccprofiles/lab.icc
> iccprofiles/ps_cmyk.icc
> iccprofiles/ps_gray.icc
> iccprofiles/ps_rgb.icc
> iccprofiles/sgray.icc
> iccprofiles/srgb.icc
> ijs/Makefile.am
> ijs/Makefile.in
> ijs/README
> ijs/autogen.sh
> ijs/common.mak
> ijs/compile
> ijs/config.guess
> ijs/config.sub
> ijs/configure
> ijs/configure.ac
> ijs/ijs-config.1
> ijs/ijs-config.in
> ijs/ijs.c
> ijs/ijs.h
> ijs/ijs.pc.in
> ijs/ijs_client.c
> ijs/ijs_client.h
> ijs/ijs_client_example.c
> ijs/ijs_exec_unix.c
> ijs/ijs_exec_win.c
> ijs/ijs_server.c
> ijs/ijs_server.h
> ijs/ijs_server_example.c
> ijs/ijs_spec.pdf
> ijs/ijs_spec.ps
> ijs/ijs_spec.sgml
> ijs/install-sh
> ijs/libtool
> ijs/ltmain.sh
> ijs/missing
> ijs/state.eps
> ijs/state.fig
> ijs/unistd_.h
> ijs/unix.mak
> ijs/windows.mak
> jbig2dec/.gitignore
> jbig2dec/CHANGES
> jbig2dec/COPYING
> jbig2dec/LICENSE
> jbig2dec/Makefile.am
> jbig2dec/Makefile.unix
> jbig2dec/README
> jbig2dec/annex-h.jbig2
> jbig2dec/autogen.sh
> jbig2dec/config_win32.h
> jbig2dec/configure.ac
> jbig2dec/getopt.c
> jbig2dec/getopt.h
> jbig2dec/getopt1.c
> jbig2dec/jbig2.c
> jbig2dec/jbig2.h
> jbig2dec/jbig2_arith.c
> jbig2dec/jbig2_arith.h
> jbig2dec/jbig2_arith_iaid.c
> jbig2dec/jbig2_arith_iaid.h
> jbig2dec/jbig2_arith_int.c
> jbig2dec/jbig2_arith_int.h
> jbig2dec/jbig2_generic.c
> jbig2dec/jbig2_generic.h
> jbig2dec/jbig2_halftone.c
> jbig2dec/jbig2_halftone.h
> jbig2dec/jbig2_huffman.c
> jbig2dec/jbig2_huffman.h
> jbig2dec/jbig2_hufftab.h
> jbig2dec/jbig2_image.c
> jbig2dec/jbig2_image.h
> jbig2dec/jbig2_image_pbm.c
> jbig2dec/jbig2_image_png.c
> jbig2dec/jbig2_metadata.c
> jbig2dec/jbig2_metadata.h
> jbig2dec/jbig2_mmr.c
> jbig2dec/jbig2_mmr.h
> jbig2dec/jbig2_page.c
> jbig2dec/jbig2_priv.h
> jbig2dec/jbig2_refinement.c
> jbig2dec/jbig2_segment.c
> jbig2dec/jbig2_symbol_dict.c
> jbig2dec/jbig2_symbol_dict.h
> jbig2dec/jbig2_text.c
> jbig2dec/jbig2_text.h
> jbig2dec/jbig2dec.1
> jbig2dec/jbig2dec.c
> jbig2dec/memcmp.c
> jbig2dec/memento.c
> jbig2dec/memento.h
> jbig2dec/msvc.mak
> jbig2dec/os_types.h
> jbig2dec/pbm2png.c
> jbig2dec/sha1.c
> jbig2dec/sha1.h
> jbig2dec/snprintf.c
> jbig2dec/test_jbig2dec.py
> jpeg/Makefile.am
> jpeg/Makefile.in
> jpeg/README
> jpeg/aclocal.m4
> jpeg/ar-lib
> jpeg/cderror.h
> jpeg/cdjpeg.c
> jpeg/cdjpeg.h
> jpeg/change.log
> jpeg/cjpeg.1
> jpeg/cjpeg.c
> jpeg/ckconfig.c
> jpeg/coderules.txt
> jpeg/compile
> jpeg/config.guess
> jpeg/config.sub
> jpeg/configure
> jpeg/configure.ac
> jpeg/depcomp
> jpeg/djpeg.1
> jpeg/djpeg.c
> jpeg/example.c
> jpeg/filelist.txt
> jpeg/install-sh
> jpeg/install.txt
> jpeg/jaricom.c
> jpeg/jcapimin.c
> jpeg/jcapistd.c
> jpeg/jcarith.c
> jpeg/jccoefct.c
> jpeg/jccolor.c
> jpeg/jcdctmgr.c
> jpeg/jchuff.c
> jpeg/jcinit.c
> jpeg/jcmainct.c
> jpeg/jcmarker.c
> jpeg/jcmaster.c
> jpeg/jcomapi.c
> jpeg/jconfig.bcc
> jpeg/jconfig.cfg
> jpeg/jconfig.dj
> jpeg/jconfig.mac
> jpeg/jconfig.manx
> jpeg/jconfig.mc6
> jpeg/jconfig.sas
> jpeg/jconfig.st
> jpeg/jconfig.txt
> jpeg/jconfig.vc
> jpeg/jconfig.vms
> jpeg/jconfig.wat
> jpeg/jcparam.c
> jpeg/jcprepct.c
> jpeg/jcsample.c
> jpeg/jctrans.c
> jpeg/jdapimin.c
> jpeg/jdapistd.c
> jpeg/jdarith.c
> jpeg/jdatadst.c
> jpeg/jdatasrc.c
> jpeg/jdcoefct.c
> jpeg/jdcolor.c
> jpeg/jdct.h
> jpeg/jddctmgr.c
> jpeg/jdhuff.c
> jpeg/jdinput.c
> jpeg/jdmainct.c
> jpeg/jdmarker.c
> jpeg/jdmaster.c
> jpeg/jdmerge.c
> jpeg/jdpostct.c
> jpeg/jdsample.c
> jpeg/jdtrans.c
> jpeg/jerror.c
> jpeg/jerror.h
> jpeg/jfdctflt.c
> jpeg/jfdctfst.c
> jpeg/jfdctint.c
> jpeg/jidctflt.c
> jpeg/jidctfst.c
> jpeg/jidctint.c
> jpeg/jinclude.h
> jpeg/jmemansi.c
> jpeg/jmemdos.c
> jpeg/jmemdosa.asm
> jpeg/jmemmac.c
> jpeg/jmemmgr.c
> jpeg/jmemname.c
> jpeg/jmemnobs.c
> jpeg/jmemsys.h
> jpeg/jmorecfg.h
> jpeg/jpegint.h
> jpeg/jpeglib.h
> jpeg/jpegtran.1
> jpeg/jpegtran.c
> jpeg/jquant1.c
> jpeg/jquant2.c
> jpeg/jutils.c
> jpeg/jversion.h
> jpeg/libjpeg.map
> jpeg/libjpeg.txt
> jpeg/ltmain.sh
> jpeg/makcjpeg.st
> jpeg/makdjpeg.st
> jpeg/makeadsw.vc6
> jpeg/makeasln.v10
> jpeg/makecdep.vc6
> jpeg/makecdsp.vc6
> jpeg/makecfil.v10
> jpeg/makecmak.vc6
> jpeg/makecvcx.v10
> jpeg/makeddep.vc6
> jpeg/makeddsp.vc6
> jpeg/makedfil.v10
> jpeg/makedmak.vc6
> jpeg/makedvcx.v10
> jpeg/makefile.ansi
> jpeg/makefile.bcc
> jpeg/makefile.dj
> jpeg/makefile.manx
> jpeg/makefile.mc6
> jpeg/makefile.mms
> jpeg/makefile.sas
> jpeg/makefile.unix
> jpeg/makefile.vc
> jpeg/makefile.vms
> jpeg/makefile.wat
> jpeg/makejdep.vc6
> jpeg/makejdsp.vc6
> jpeg/makejdsw.vc6
> jpeg/makejfil.v10
> jpeg/makejmak.vc6
> jpeg/makejsln.v10
> jpeg/makejvcx.v10
> jpeg/makeproj.mac
> jpeg/makerdep.vc6
> jpeg/makerdsp.vc6
> jpeg/makerfil.v10
> jpeg/makermak.vc6
> jpeg/makervcx.v10
> jpeg/maketdep.vc6
> jpeg/maketdsp.vc6
> jpeg/maketfil.v10
> jpeg/maketmak.vc6
> jpeg/maketvcx.v10
> jpeg/makewdep.vc6
> jpeg/makewdsp.vc6
> jpeg/makewfil.v10
> jpeg/makewmak.vc6
> jpeg/makewvcx.v10
> jpeg/makljpeg.st
> jpeg/maktjpeg.st
> jpeg/makvms.opt
> jpeg/missing
> jpeg/rdbmp.c
> jpeg/rdcolmap.c
> jpeg/rdgif.c
> jpeg/rdjpgcom.1
> jpeg/rdjpgcom.c
> jpeg/rdppm.c
> jpeg/rdrle.c
> jpeg/rdswitch.c
> jpeg/rdtarga.c
> jpeg/structure.txt
> jpeg/testimg.bmp
> jpeg/testimg.jpg
> jpeg/testimg.ppm
> jpeg/testimgp.jpg
> jpeg/testorig.jpg
> jpeg/testprog.jpg
> jpeg/transupp.c
> jpeg/transupp.h
> jpeg/usage.txt
> jpeg/wizard.txt
> jpeg/wrbmp.c
> jpeg/wrgif.c
> jpeg/wrjpgcom.1
> jpeg/wrjpgcom.c
> jpeg/wrppm.c
> jpeg/wrrle.c
> jpeg/wrtarga.c
> jpegxr/APP.rc
> jpegxr/APP.vcproj
> jpegxr/COPYRIGHT.txt
> jpegxr/DLL.rc
> jpegxr/DLL.vcproj
> jpegxr/JPEG-XR.sln
> jpegxr/Makefile
> jpegxr/README.txt
> jpegxr/algo.c
> jpegxr/api.c
> jpegxr/app_resource.h
> jpegxr/cr_parse.c
> jpegxr/cw_emit.c
> jpegxr/dll_resource.h
> jpegxr/dllmain.c
> jpegxr/file.c
> jpegxr/file.h
> jpegxr/flags.c
> jpegxr/init.c
> jpegxr/io.c
> jpegxr/jpegxr.c
> jpegxr/jpegxr.h
> jpegxr/jpegxr_pixelformat.c
> jpegxr/jxr_priv.h
> jpegxr/my_getopt-1.5/LICENSE
> jpegxr/my_getopt-1.5/getopt.h
> jpegxr/my_getopt-1.5/my_getopt.c
> jpegxr/my_getopt-1.5/my_getopt.h
> jpegxr/qp.tab.c
> jpegxr/qp.tab.h
> jpegxr/qp_lexor.c
> jpegxr/qp_lexor.lex
> jpegxr/qp_parse.y
> jpegxr/r_parse.c
> jpegxr/r_strip.c
> jpegxr/r_tile_frequency.c
> jpegxr/r_tile_spatial.c
> jpegxr/sample.qp
> jpegxr/stdint_minimal.h
> jpegxr/versions-windows.txt
> jpegxr/w_emit.c
> jpegxr/w_strip.c
> jpegxr/w_tile_frequency.c
> jpegxr/w_tile_spatial.c
> jpegxr/x_strip.c
> language_switch/pspcl6_gcc.mak
> language_switch/pspcl6_msvc.mak
> lcms2/AUTHORS
> lcms2/COPYING
> lcms2/ChangeLog
> lcms2/INSTALL
> lcms2/Lib/BC/BC.txt
> lcms2/Lib/MS/MS.TXT
> lcms2/Makefile.am
> lcms2/Makefile.in
> lcms2/Projects/.gitignore
> lcms2/Projects/BorlandC_5.5/lcms2.rc
> lcms2/Projects/BorlandC_5.5/lcmsdll.lk
> lcms2/Projects/BorlandC_5.5/lcmsdll.lst
> lcms2/Projects/BorlandC_5.5/mklcmsdll.bat
> lcms2/Projects/VC2008/jpegicc/jpegicc.vcproj
> lcms2/Projects/VC2008/lcms2.rc
> lcms2/Projects/VC2008/lcms2.sln
> lcms2/Projects/VC2008/lcms2_DLL/lcms2_DLL.vcproj
> lcms2/Projects/VC2008/lcms2_static/lcms2_static.vcproj
> lcms2/Projects/VC2008/linkicc/linkicc.vcproj
> lcms2/Projects/VC2008/psicc/psicc.vcproj
> lcms2/Projects/VC2008/resource.h
> lcms2/Projects/VC2008/testbed/testbed.vcproj
> lcms2/Projects/VC2008/tiffdiff/tiffdiff.vcproj
> lcms2/Projects/VC2008/tifficc/tifficc.vcproj
> lcms2/Projects/VC2008/transicc/transicc.vcproj
> lcms2/Projects/VC2010/jpegicc/jpegicc.vcproj
> lcms2/Projects/VC2010/jpegicc/jpegicc.vcxproj
> lcms2/Projects/VC2010/jpegicc/jpegicc.vcxproj.filters
> lcms2/Projects/VC2010/lcms2.rc
> lcms2/Projects/VC2010/lcms2.sln
> lcms2/Projects/VC2010/lcms2_DLL/lcms2_DLL.vcproj
> lcms2/Projects/VC2010/lcms2_DLL/lcms2_DLL.vcxproj
> lcms2/Projects/VC2010/lcms2_DLL/lcms2_DLL.vcxproj.filters
> lcms2/Projects/VC2010/lcms2_static/lcms2_static.vcproj
> lcms2/Projects/VC2010/lcms2_static/lcms2_static.vcxproj
> lcms2/Projects/VC2010/lcms2_static/lcms2_static.vcxproj.filters
> lcms2/Projects/VC2010/linkicc/linkicc.vcproj
> lcms2/Projects/VC2010/linkicc/linkicc.vcxproj
> lcms2/Projects/VC2010/linkicc/linkicc.vcxproj.filters
> lcms2/Projects/VC2010/psicc/psicc.vcproj
> lcms2/Projects/VC2010/psicc/psicc.vcxproj
> lcms2/Projects/VC2010/psicc/psicc.vcxproj.filters
> lcms2/Projects/VC2010/resource.h
> lcms2/Projects/VC2010/testbed/testbed.vcproj
> lcms2/Projects/VC2010/testbed/testbed.vcxproj
> lcms2/Projects/VC2010/testbed/testbed.vcxproj.filters
> lcms2/Projects/VC2010/tiffdiff/tiffdiff.vcproj
> lcms2/Projects/VC2010/tiffdiff/tiffdiff.vcxproj
> lcms2/Projects/VC2010/tiffdiff/tiffdiff.vcxproj.filters
> lcms2/Projects/VC2010/tifficc/tifficc.vcproj
> lcms2/Projects/VC2010/tifficc/tifficc.vcxproj
> lcms2/Projects/VC2010/tifficc/tifficc.vcxproj.filters
> lcms2/Projects/VC2010/transicc/transicc.vcproj
> lcms2/Projects/VC2010/transicc/transicc.vcxproj
> lcms2/Projects/VC2010/transicc/transicc.vcxproj.filters
> lcms2/Projects/VC2012/jpegicc/jpegicc.vcproj
> lcms2/Projects/VC2012/jpegicc/jpegicc.vcxproj
> lcms2/Projects/VC2012/jpegicc/jpegicc.vcxproj.filters
> lcms2/Projects/VC2012/lcms2.rc
> lcms2/Projects/VC2012/lcms2.sln
> lcms2/Projects/VC2012/lcms2_DLL/lcms2_DLL.vcproj
> lcms2/Projects/VC2012/lcms2_DLL/lcms2_DLL.vcxproj
> lcms2/Projects/VC2012/lcms2_DLL/lcms2_DLL.vcxproj.filters
> lcms2/Projects/VC2012/lcms2_static/lcms2_static.vcproj
> lcms2/Projects/VC2012/lcms2_static/lcms2_static.vcxproj
> lcms2/Projects/VC2012/lcms2_static/lcms2_static.vcxproj.filters
> lcms2/Projects/VC2012/linkicc/linkicc.vcproj
> lcms2/Projects/VC2012/linkicc/linkicc.vcxproj
> lcms2/Projects/VC2012/linkicc/linkicc.vcxproj.filters
> lcms2/Projects/VC2012/psicc/psicc.vcproj
> lcms2/Projects/VC2012/psicc/psicc.vcxproj
> lcms2/Projects/VC2012/psicc/psicc.vcxproj.filters
> lcms2/Projects/VC2012/resource.h
> lcms2/Projects/VC2012/testbed/testbed.vcproj
> lcms2/Projects/VC2012/testbed/testbed.vcxproj
> lcms2/Projects/VC2012/testbed/testbed.vcxproj.filters
> lcms2/Projects/VC2012/tiffdiff/tiffdiff.vcproj
> lcms2/Projects/VC2012/tiffdiff/tiffdiff.vcxproj
> lcms2/Projects/VC2012/tiffdiff/tiffdiff.vcxproj.filters
> lcms2/Projects/VC2012/tifficc/tifficc.vcproj
> lcms2/Projects/VC2012/tifficc/tifficc.vcxproj
> lcms2/Projects/VC2012/tifficc/tifficc.vcxproj.filters
> lcms2/Projects/VC2012/transicc/transicc.vcproj
> lcms2/Projects/VC2012/transicc/transicc.vcxproj
> lcms2/Projects/VC2012/transicc/transicc.vcxproj.filters
> lcms2/Projects/cppcheck/lcms2.cppcheck
> lcms2/Projects/mac/._.DS_Store
> lcms2/Projects/mac/LittleCMS/._.DS_Store
> lcms2/Projects/mac/LittleCMS/English.lproj/InfoPlist.strings
> lcms2/Projects/mac/LittleCMS/Info.plist
> lcms2/Projects/mac/LittleCMS/LittleCMS.xcodeproj/mariama.mode1v3
> lcms2/Projects/mac/LittleCMS/LittleCMS.xcodeproj/mariama.pbxuser
> lcms2/Projects/mac/LittleCMS/LittleCMS.xcodeproj/project.pbxproj
> lcms2/Projects/mac/LittleCMS/LittleCMS_Prefix.pch
> lcms2/Projects/mac/LittleCMS/TestBed-Info.plist
> lcms2/README.1ST
> lcms2/aclocal.m4
> lcms2/autogen.sh
> lcms2/config.guess
> lcms2/config.sub
> lcms2/configure
> lcms2/configure.ac
> lcms2/depcomp
> lcms2/doc/LittleCMS2.6 API.pdf
> lcms2/doc/LittleCMS2.6 Plugin API.pdf
> lcms2/doc/LittleCMS2.6 tutorial.pdf
> lcms2/doc/src.zip
> lcms2/include/Makefile.am
> lcms2/include/Makefile.in
> lcms2/include/lcms2.h
> lcms2/include/lcms2_plugin.h
> lcms2/install-sh
> lcms2/lcms2.pc.in
> lcms2/ltmain.sh
> lcms2/m4/acx_pthread.m4
> lcms2/missing
> lcms2/src/Makefile.am
> lcms2/src/Makefile.in
> lcms2/src/cmscam02.c
> lcms2/src/cmscgats.c
> lcms2/src/cmscnvrt.c
> lcms2/src/cmserr.c
> lcms2/src/cmsgamma.c
> lcms2/src/cmsgmt.c
> lcms2/src/cmshalf.c
> lcms2/src/cmsintrp.c
> lcms2/src/cmsio0.c
> lcms2/src/cmsio1.c
> lcms2/src/cmslut.c
> lcms2/src/cmsmd5.c
> lcms2/src/cmsmtrx.c
> lcms2/src/cmsnamed.c
> lcms2/src/cmsopt.c
> lcms2/src/cmspack.c
> lcms2/src/cmspcs.c
> lcms2/src/cmsplugin.c
> lcms2/src/cmsps2.c
> lcms2/src/cmssamp.c
> lcms2/src/cmssm.c
> lcms2/src/cmstypes.c
> lcms2/src/cmsvirt.c
> lcms2/src/cmswtpnt.c
> lcms2/src/cmsxform.c
> lcms2/src/extra_xform.h
> lcms2/src/lcms2.def
> lcms2/src/lcms2_internal.h
> lcms2/testbed/Makefile.am
> lcms2/testbed/Makefile.in
> lcms2/testbed/bad.icc
> lcms2/testbed/ibm-t61.icc
> lcms2/testbed/new.icc
> lcms2/testbed/test1.icc
> lcms2/testbed/test2.icc
> lcms2/testbed/test3.icc
> lcms2/testbed/test4.icc
> lcms2/testbed/test5.icc
> lcms2/testbed/testcms2.c
> lcms2/testbed/testcms2.h
> lcms2/testbed/testplugin.c
> lcms2/testbed/testthread.cpp
> lcms2/testbed/toosmall.icc
> lcms2/testbed/zoo_icc.c
> lcms2/utils/common/utils.h
> lcms2/utils/common/vprf.c
> lcms2/utils/common/xgetopt.c
> lcms2/utils/delphi/delphidemo.dpr
> lcms2/utils/delphi/delphidemo.dproj
> lcms2/utils/delphi/delphidemo.res
> lcms2/utils/delphi/demo1.dfm
> lcms2/utils/delphi/demo1.pas
> lcms2/utils/delphi/lcms2.dll
> lcms2/utils/delphi/lcms2dll.pas
> lcms2/utils/jpgicc/Makefile.am
> lcms2/utils/jpgicc/Makefile.in
> lcms2/utils/jpgicc/iccjpeg.c
> lcms2/utils/jpgicc/iccjpeg.h
> lcms2/utils/jpgicc/jpgicc.1
> lcms2/utils/jpgicc/jpgicc.c
> lcms2/utils/linkicc/Makefile.am
> lcms2/utils/linkicc/Makefile.in
> lcms2/utils/linkicc/linkicc.1
> lcms2/utils/linkicc/linkicc.c
> lcms2/utils/matlab/icctrans.c
> lcms2/utils/matlab/lcms_rsp
> lcms2/utils/psicc/Makefile.am
> lcms2/utils/psicc/Makefile.in
> lcms2/utils/psicc/psicc.1
> lcms2/utils/psicc/psicc.c
> lcms2/utils/samples/Makefile.am
> lcms2/utils/samples/Makefile.in
> lcms2/utils/samples/itufax.c
> lcms2/utils/samples/mkcmy.c
> lcms2/utils/samples/mkgrayer.c
> lcms2/utils/samples/mktiff8.c
> lcms2/utils/samples/roundtrip.c
> lcms2/utils/samples/vericc.c
> lcms2/utils/samples/wtpt.1
> lcms2/utils/samples/wtpt.c
> lcms2/utils/tificc/Makefile.am
> lcms2/utils/tificc/Makefile.in
> lcms2/utils/tificc/tifdiff.c
> lcms2/utils/tificc/tificc.1
> lcms2/utils/tificc/tificc.c
> lcms2/utils/transicc/Makefile.am
> lcms2/utils/transicc/Makefile.in
> lcms2/utils/transicc/transicc.1
> lcms2/utils/transicc/transicc.c
> lib/EndOfTask.ps
> lib/FAPIconfig-FCO
> lib/FCOfontmap-PCLPS3
> lib/FCOfontmap-PS3
> lib/Fontmap.ATB
> lib/Fontmap.ATM
> lib/Fontmap.OS2
> lib/Fontmap.OSF
> lib/Fontmap.SGI
> lib/Fontmap.Sol
> lib/Fontmap.URW-136.T1
> lib/Fontmap.URW-136.TT
> lib/Fontmap.Ult
> lib/Fontmap.VMS
> lib/Info-macos.plist
> lib/PDFA_def.ps
> lib/PDFX_def.ps
> lib/acctest.ps
> lib/addxchar.ps
> lib/afmdiff.awk
> lib/align.ps
> lib/bj8.rpd
> lib/bj8gc12f.upp
> lib/bj8hg12f.upp
> lib/bj8oh06n.upp
> lib/bj8pa06n.upp
> lib/bj8pp12f.upp
> lib/bj8ts06n.upp
> lib/bjc610a0.upp
> lib/bjc610a1.upp
> lib/bjc610a2.upp
> lib/bjc610a3.upp
> lib/bjc610a4.upp
> lib/bjc610a5.upp
> lib/bjc610a6.upp
> lib/bjc610a7.upp
> lib/bjc610a8.upp
> lib/bjc610b1.upp
> lib/bjc610b2.upp
> lib/bjc610b3.upp
> lib/bjc610b4.upp
> lib/bjc610b6.upp
> lib/bjc610b7.upp
> lib/bjc610b8.upp
> lib/caption.ps
> lib/cat.ps
> lib/cbjc600.ppd
> lib/cbjc800.ppd
> lib/cdj550.upp
> lib/cdj690.upp
> lib/cdj690ec.upp
> lib/cid2code.ps
> lib/decrypt.ps
> lib/dnj750c.upp
> lib/dnj750m.upp
> lib/docie.ps
> lib/dvipdf
> lib/eps2eps
> lib/eps2eps.bat
> lib/eps2eps.cmd
> lib/font2c
> lib/font2c.bat
> lib/font2c.cmd
> lib/font2c.ps
> lib/font2pcl.ps
> lib/ghostpdf.README
> lib/ghostpdf.cat
> lib/ghostpdf.inf
> lib/ghostpdf.ppd
> lib/gs_ce_e.ps
> lib/gs_cmdl.ps
> lib/gs_il2_e.ps
> lib/gs_kanji.ps
> lib/gs_ksb_e.ps
> lib/gs_l.xbm
> lib/gs_l.xpm
> lib/gs_l_m.xbm
> lib/gs_lgo_e.ps
> lib/gs_lgx_e.ps
> lib/gs_m.xbm
> lib/gs_m.xpm
> lib/gs_m_m.xbm
> lib/gs_pfile.ps
> lib/gs_rdlin.ps
> lib/gs_s.xbm
> lib/gs_s.xpm
> lib/gs_s_m.xbm
> lib/gs_t.xbm
> lib/gs_t.xpm
> lib/gs_t_m.xbm
> lib/gs_wl1_e.ps
> lib/gs_wl2_e.ps
> lib/gs_wl5_e.ps
> lib/gsbj
> lib/gsbj.bat
> lib/gsdj
> lib/gsdj.bat
> lib/gsdj500
> lib/gsdj500.bat
> lib/gslj
> lib/gslj.bat
> lib/gslp
> lib/gslp.bat
> lib/gslp.ps
> lib/gsnd
> lib/gsnd.bat
> lib/gsndt.bat
> lib/gsnup.ps
> lib/gssetgs.bat
> lib/gssetgs32.bat
> lib/gssetgs64.bat
> lib/gst.bat
> lib/gstt.bat
> lib/ht_ccsto.ps
> lib/image-qa.ps
> lib/impath.ps
> lib/jispaper.ps
> lib/jobseparator.ps
> lib/landscap.ps
> lib/level1.ps
> lib/lines.ps
> lib/lp386.bat
> lib/lp386r2.bat
> lib/lpgs.bat
> lib/lpr2.bat
> lib/lprsetup.sh
> lib/markhint.ps
> lib/markpath.ps
> lib/mkcidfm.ps
> lib/necp2x.upp
> lib/necp2x6.upp
> lib/opdfread.ps
> lib/packfile.ps
> lib/pcharstr.ps
> lib/pdf2dsc
> lib/pdf2dsc.bat
> lib/pdf2dsc.ps
> lib/pdf2ps
> lib/pdf2ps.bat
> lib/pdf2ps.cmd
> lib/pdfwrite.ps
> lib/pf2afm
> lib/pf2afm.bat
> lib/pf2afm.cmd
> lib/pf2afm.ps
> lib/pfbtopfa
> lib/pfbtopfa.bat
> lib/pfbtopfa.ps
> lib/pftogsf.bat
> lib/ppath.ps
> lib/pphs
> lib/pphs.ps
> lib/prfont.ps
> lib/printafm
> lib/printafm.ps
> lib/ps2ai.ps
> lib/ps2ascii
> lib/ps2ascii.bat
> lib/ps2ascii.cmd
> lib/ps2ascii.ps
> lib/ps2epsi
> lib/ps2epsi.bat
> lib/ps2epsi.cmd
> lib/ps2epsi.ps
> lib/ps2pdf
> lib/ps2pdf.bat
> lib/ps2pdf.cmd
> lib/ps2pdf12
> lib/ps2pdf12.bat
> lib/ps2pdf12.cmd
> lib/ps2pdf13
> lib/ps2pdf13.bat
> lib/ps2pdf13.cmd
> lib/ps2pdf14
> lib/ps2pdf14.bat
> lib/ps2pdf14.cmd
> lib/ps2pdfwr
> lib/ps2pdfxx.bat
> lib/ps2ps
> lib/ps2ps.bat
> lib/ps2ps.cmd
> lib/ps2ps2
> lib/ps2ps2.bat
> lib/ps2ps2.cmd
> lib/quit.ps
> lib/ras1.upp
> lib/ras24.upp
> lib/ras3.upp
> lib/ras32.upp
> lib/ras4.upp
> lib/ras8m.upp
> lib/rinkj-2200-setup
> lib/rollconv.ps
> lib/showchar.ps
> lib/showpage.ps
> lib/st640ih.upp
> lib/st640ihg.upp
> lib/st640p.upp
> lib/st640pg.upp
> lib/st640pl.upp
> lib/st640plg.upp
> lib/stc.upp
> lib/stc1520h.upp
> lib/stc2.upp
> lib/stc200_h.upp
> lib/stc2_h.upp
> lib/stc2s_h.upp
> lib/stc300.upp
> lib/stc300bl.upp
> lib/stc300bm.upp
> lib/stc500p.upp
> lib/stc500ph.upp
> lib/stc600ih.upp
> lib/stc600p.upp
> lib/stc600pl.upp
> lib/stc640p.upp
> lib/stc800ih.upp
> lib/stc800p.upp
> lib/stc800pl.upp
> lib/stc_h.upp
> lib/stc_l.upp
> lib/stcany.upp
> lib/stcany_h.upp
> lib/stcinfo.ps
> lib/stcolor.ps
> lib/stocht.ps
> lib/traceimg.ps
> lib/traceop.ps
> lib/type1enc.ps
> lib/type1ops.ps
> lib/uninfo.ps
> lib/unix-lpr.sh
> lib/unprot.ps
> lib/viewcmyk.ps
> lib/viewgif.ps
> lib/viewjpeg.ps
> lib/viewmiff.ps
> lib/viewpbm.ps
> lib/viewpcx.ps
> lib/viewps2a.ps
> lib/viewraw.ps
> lib/viewrgb.ps
> lib/wftopfa
> lib/wftopfa.ps
> lib/winmaps.ps
> lib/wmakebat.bat
> lib/wrfont.ps
> lib/zeroline.ps
> libpng/ANNOUNCE
> libpng/CHANGES
> libpng/CMakeLists.txt
> libpng/INSTALL
> libpng/LICENSE
> libpng/Makefile.am
> libpng/Makefile.in
> libpng/README
> libpng/TODO
> libpng/aclocal.m4
> libpng/arm/arm_init.c
> libpng/arm/filter_neon.S
> libpng/arm/filter_neon_intrinsics.c
> libpng/autogen.sh
> libpng/compile
> libpng/config.guess
> libpng/config.h.in
> libpng/config.sub
> libpng/configure
> libpng/configure.ac
> libpng/contrib/README.txt
> libpng/contrib/arm-neon/README
> libpng/contrib/arm-neon/android-ndk.c
> libpng/contrib/arm-neon/linux-auxv.c
> libpng/contrib/arm-neon/linux.c
> libpng/contrib/conftest/README
> libpng/contrib/conftest/read.dfa
> libpng/contrib/conftest/s_read.dfa
> libpng/contrib/conftest/s_write.dfa
> libpng/contrib/conftest/simple.dfa
> libpng/contrib/conftest/write.dfa
> libpng/contrib/examples/README.txt
> libpng/contrib/examples/iccfrompng.c
> libpng/contrib/examples/pngpixel.c
> libpng/contrib/examples/pngtopng.c
> libpng/contrib/gregbook/COPYING
> libpng/contrib/gregbook/LICENSE
> libpng/contrib/gregbook/Makefile.mingw32
> libpng/contrib/gregbook/Makefile.sgi
> libpng/contrib/gregbook/Makefile.unx
> libpng/contrib/gregbook/Makefile.w32
> libpng/contrib/gregbook/README
> libpng/contrib/gregbook/makevms.com
> libpng/contrib/gregbook/readpng.c
> libpng/contrib/gregbook/readpng.h
> libpng/contrib/gregbook/readpng2.c
> libpng/contrib/gregbook/readpng2.h
> libpng/contrib/gregbook/readppm.c
> libpng/contrib/gregbook/rpng-win.c
> libpng/contrib/gregbook/rpng-x.c
> libpng/contrib/gregbook/rpng2-win.c
> libpng/contrib/gregbook/rpng2-x.c
> libpng/contrib/gregbook/toucan.png
> libpng/contrib/gregbook/wpng.c
> libpng/contrib/gregbook/writepng.c
> libpng/contrib/gregbook/writepng.h
> libpng/contrib/libtests/fakepng.c
> libpng/contrib/libtests/gentests.sh
> libpng/contrib/libtests/makepng.c
> libpng/contrib/libtests/pngimage.c
> libpng/contrib/libtests/pngstest.c
> libpng/contrib/libtests/pngunknown.c
> libpng/contrib/libtests/pngvalid.c
> libpng/contrib/libtests/readpng.c
> libpng/contrib/libtests/tarith.c
> libpng/contrib/libtests/timepng.c
> libpng/contrib/pngminim/README
> libpng/contrib/pngminim/decoder/README
> libpng/contrib/pngminim/decoder/makefile
> libpng/contrib/pngminim/decoder/pngusr.dfa
> libpng/contrib/pngminim/decoder/pngusr.h
> libpng/contrib/pngminim/encoder/README
> libpng/contrib/pngminim/encoder/makefile
> libpng/contrib/pngminim/encoder/pngusr.dfa
> libpng/contrib/pngminim/encoder/pngusr.h
> libpng/contrib/pngminim/preader/README
> libpng/contrib/pngminim/preader/makefile
> libpng/contrib/pngminim/preader/pngusr.dfa
> libpng/contrib/pngminim/preader/pngusr.h
> libpng/contrib/pngminus/README
> libpng/contrib/pngminus/makefile.std
> libpng/contrib/pngminus/makefile.tc3
> libpng/contrib/pngminus/makevms.com
> libpng/contrib/pngminus/png2pnm.bat
> libpng/contrib/pngminus/png2pnm.c
> libpng/contrib/pngminus/png2pnm.sh
> libpng/contrib/pngminus/pngminus.bat
> libpng/contrib/pngminus/pngminus.sh
> libpng/contrib/pngminus/pnm2png.bat
> libpng/contrib/pngminus/pnm2png.c
> libpng/contrib/pngminus/pnm2png.sh
> libpng/contrib/pngsuite/README
> libpng/contrib/pngsuite/basn0g01.png
> libpng/contrib/pngsuite/basn0g02.png
> libpng/contrib/pngsuite/basn0g04.png
> libpng/contrib/pngsuite/basn0g08.png
> libpng/contrib/pngsuite/basn0g16.png
> libpng/contrib/pngsuite/basn2c08.png
> libpng/contrib/pngsuite/basn2c16.png
> libpng/contrib/pngsuite/basn3p01.png
> libpng/contrib/pngsuite/basn3p02.png
> libpng/contrib/pngsuite/basn3p04.png
> libpng/contrib/pngsuite/basn3p08.png
> libpng/contrib/pngsuite/basn4a08.png
> libpng/contrib/pngsuite/basn4a16.png
> libpng/contrib/pngsuite/basn6a08.png
> libpng/contrib/pngsuite/basn6a16.png
> libpng/contrib/pngsuite/ftbbn0g01.png
> libpng/contrib/pngsuite/ftbbn0g02.png
> libpng/contrib/pngsuite/ftbbn0g04.png
> libpng/contrib/pngsuite/ftbbn2c16.png
> libpng/contrib/pngsuite/ftbbn3p08.png
> libpng/contrib/pngsuite/ftbgn2c16.png
> libpng/contrib/pngsuite/ftbgn3p08.png
> libpng/contrib/pngsuite/ftbrn2c08.png
> libpng/contrib/pngsuite/ftbwn0g16.png
> libpng/contrib/pngsuite/ftbwn3p08.png
> libpng/contrib/pngsuite/ftbyn3p08.png
> libpng/contrib/pngsuite/ftp0n0g08.png
> libpng/contrib/pngsuite/ftp0n2c08.png
> libpng/contrib/pngsuite/ftp0n3p08.png
> libpng/contrib/pngsuite/ftp1n3p08.png
> libpng/contrib/tools/README.txt
> libpng/contrib/tools/checksum-icc.c
> libpng/contrib/tools/chkfmt
> libpng/contrib/tools/cvtcolor.c
> libpng/contrib/tools/intgamma.sh
> libpng/contrib/tools/makesRGB.c
> libpng/contrib/tools/png-fix-itxt.c
> libpng/contrib/tools/pngfix.c
> libpng/contrib/tools/sRGB.h
> libpng/contrib/visupng/PngFile.c
> libpng/contrib/visupng/PngFile.h
> libpng/contrib/visupng/README.txt
> libpng/contrib/visupng/VisualPng.c
> libpng/contrib/visupng/VisualPng.dsp
> libpng/contrib/visupng/VisualPng.dsw
> libpng/contrib/visupng/VisualPng.ico
> libpng/contrib/visupng/VisualPng.png
> libpng/contrib/visupng/VisualPng.rc
> libpng/contrib/visupng/cexcept.h
> libpng/contrib/visupng/resource.h
> libpng/depcomp
> libpng/example.c
> libpng/install-sh
> libpng/libpng-config.in
> libpng/libpng-manual.txt
> libpng/libpng.3
> libpng/libpng.pc.in
> libpng/libpngpf.3
> libpng/ltmain.sh
> libpng/missing
> libpng/png.5
> libpng/png.c
> libpng/png.h
> libpng/pngbar.jpg
> libpng/pngbar.png
> libpng/pngconf.h
> libpng/pngdebug.h
> libpng/pngerror.c
> libpng/pngget.c
> libpng/pnginfo.h
> libpng/pngmem.c
> libpng/pngnow.png
> libpng/pngpread.c
> libpng/pngpriv.h
> libpng/pngread.c
> libpng/pngrio.c
> libpng/pngrtran.c
> libpng/pngrutil.c
> libpng/pngset.c
> libpng/pngstruct.h
> libpng/pngtest.c
> libpng/pngtest.png
> libpng/pngtrans.c
> libpng/pngusr.dfa
> libpng/pngwio.c
> libpng/pngwrite.c
> libpng/pngwtran.c
> libpng/pngwutil.c
> libpng/projects/owatcom/libpng.tgt
> libpng/projects/owatcom/libpng.wpj
> libpng/projects/owatcom/pngconfig.mak
> libpng/projects/owatcom/pngstest.tgt
> libpng/projects/owatcom/pngtest.tgt
> libpng/projects/owatcom/pngvalid.tgt
> libpng/projects/visualc71/PRJ0041.mak
> libpng/projects/visualc71/README.txt
> libpng/projects/visualc71/README_zlib.txt
> libpng/projects/visualc71/libpng.sln
> libpng/projects/visualc71/libpng.vcproj
> libpng/projects/visualc71/pngtest.vcproj
> libpng/projects/visualc71/zlib.vcproj
> libpng/projects/vstudio/WARNING
> libpng/projects/vstudio/libpng/libpng.vcxproj
> libpng/projects/vstudio/pnglibconf/pnglibconf.vcxproj
> libpng/projects/vstudio/pngstest/pngstest.vcxproj
> libpng/projects/vstudio/pngtest/pngtest.vcxproj
> libpng/projects/vstudio/pngunknown/pngunknown.vcxproj
> libpng/projects/vstudio/pngvalid/pngvalid.vcxproj
> libpng/projects/vstudio/readme.txt
> libpng/projects/vstudio/vstudio.sln
> libpng/projects/vstudio/zlib.props
> libpng/projects/vstudio/zlib/zlib.vcxproj
> libpng/scripts/README.txt
> libpng/scripts/SCOPTIONS.ppc
> libpng/scripts/checksym.awk
> libpng/scripts/def.c
> libpng/scripts/descrip.mms
> libpng/scripts/dfn.awk
> libpng/scripts/intprefix.c
> libpng/scripts/libpng-config-body.in
> libpng/scripts/libpng-config-head.in
> libpng/scripts/libpng.pc.in
> libpng/scripts/libtool.m4
> libpng/scripts/ltoptions.m4
> libpng/scripts/ltsugar.m4
> libpng/scripts/ltversion.m4
> libpng/scripts/lt~obsolete.m4
> libpng/scripts/macro.lst
> libpng/scripts/makefile.32sunu
> libpng/scripts/makefile.64sunu
> libpng/scripts/makefile.acorn
> libpng/scripts/makefile.aix
> libpng/scripts/makefile.amiga
> libpng/scripts/makefile.atari
> libpng/scripts/makefile.bc32
> libpng/scripts/makefile.beos
> libpng/scripts/makefile.bor
> libpng/scripts/makefile.cegcc
> libpng/scripts/makefile.darwin
> libpng/scripts/makefile.dec
> libpng/scripts/makefile.dj2
> libpng/scripts/makefile.freebsd
> libpng/scripts/makefile.gcc
> libpng/scripts/makefile.hp64
> libpng/scripts/makefile.hpgcc
> libpng/scripts/makefile.hpux
> libpng/scripts/makefile.ibmc
> libpng/scripts/makefile.intel
> libpng/scripts/makefile.knr
> libpng/scripts/makefile.linux
> libpng/scripts/makefile.mips
> libpng/scripts/makefile.msc
> libpng/scripts/makefile.msys
> libpng/scripts/makefile.ne12bsd
> libpng/scripts/makefile.netbsd
> libpng/scripts/makefile.openbsd
> libpng/scripts/makefile.sco
> libpng/scripts/makefile.sggcc
> libpng/scripts/makefile.sgi
> libpng/scripts/makefile.so9
> libpng/scripts/makefile.solaris
> libpng/scripts/makefile.solaris-x86
> libpng/scripts/makefile.std
> libpng/scripts/makefile.sunos
> libpng/scripts/makefile.tc3
> libpng/scripts/makefile.vcwin32
> libpng/scripts/makevms.com
> libpng/scripts/options.awk
> libpng/scripts/pnglibconf.dfa
> libpng/scripts/pnglibconf.h.prebuilt
> libpng/scripts/pnglibconf.mak
> libpng/scripts/pngwin.rc
> libpng/scripts/prefix.c
> libpng/scripts/smakefile.ppc
> libpng/scripts/sym.c
> libpng/scripts/symbols.c
> libpng/scripts/symbols.def
> libpng/scripts/vers.c
> libpng/test-driver
> libpng/tests/pngimage-full
> libpng/tests/pngimage-quick
> libpng/tests/pngstest
> libpng/tests/pngstest-0g01
> libpng/tests/pngstest-0g02
> libpng/tests/pngstest-0g04
> libpng/tests/pngstest-0g08
> libpng/tests/pngstest-0g16
> libpng/tests/pngstest-2c08
> libpng/tests/pngstest-2c16
> libpng/tests/pngstest-3p01
> libpng/tests/pngstest-3p02
> libpng/tests/pngstest-3p04
> libpng/tests/pngstest-3p08
> libpng/tests/pngstest-4a08
> libpng/tests/pngstest-4a16
> libpng/tests/pngstest-6a08
> libpng/tests/pngstest-6a16
> libpng/tests/pngstest-error
> libpng/tests/pngtest
> libpng/tests/pngunknown-IDAT
> libpng/tests/pngunknown-discard
> libpng/tests/pngunknown-if-safe
> libpng/tests/pngunknown-sAPI
> libpng/tests/pngunknown-sTER
> libpng/tests/pngunknown-save
> libpng/tests/pngunknown-vpAg
> libpng/tests/pngvalid-gamma-16-to-8
> libpng/tests/pngvalid-gamma-alpha-mode
> libpng/tests/pngvalid-gamma-background
> libpng/tests/pngvalid-gamma-expand16-alpha-mode
> libpng/tests/pngvalid-gamma-expand16-background
> libpng/tests/pngvalid-gamma-expand16-transform
> libpng/tests/pngvalid-gamma-sbit
> libpng/tests/pngvalid-gamma-threshold
> libpng/tests/pngvalid-gamma-transform
> libpng/tests/pngvalid-progressive-interlace-size
> libpng/tests/pngvalid-progressive-interlace-standard
> libpng/tests/pngvalid-progressive-interlace-transform
> libpng/tests/pngvalid-progressive-standard
> libpng/tests/pngvalid-standard
> main/pcl6_gcc.mak
> main/pcl6_msvc.mak
> man/de/dvipdf.1
> man/de/font2c.1
> man/de/gsnd.1
> man/de/pdf2dsc.1
> man/de/pdf2ps.1
> man/de/printafm.1
> man/de/ps2ascii.1
> man/de/ps2pdf.1
> man/de/ps2ps.1
> man/de/wftopfa.1
> man/dvipdf.1
> man/eps2eps.1
> man/font2c.1
> man/gs.1
> man/gslp.1
> man/gsnd.1
> man/pdf2dsc.1
> man/pdf2ps.1
> man/pf2afm.1
> man/pfbtopfa.1
> man/printafm.1
> man/ps2ascii.1
> man/ps2epsi.1
> man/ps2pdf.1
> man/ps2pdfwr.1
> man/ps2ps.1
> man/wftopfa.1
> old-stuff/COPYING
> old-stuff/Makefile
> old-stuff/autogen.sh
> old-stuff/common/cp.bat
> old-stuff/common/gccdefs.mak
> old-stuff/common/generic.mak
> old-stuff/common/msvc_top.mak
> old-stuff/common/msvcdefs.mak
> old-stuff/common/mv.bat
> old-stuff/common/pcdefs.mak
> old-stuff/common/rm.bat
> old-stuff/common/sgidefs.mak
> old-stuff/common/ugcc_top.mak
> old-stuff/common/unixdefs.mak
> old-stuff/config.mak.in
> old-stuff/configure.ac
> old-stuff/main/pcl6_gcc.mak
> old-stuff/main/pcl6_msvc.mak
> old-stuff/win32/GhostPDL.sln
> old-stuff/win32/ReadMe.txt
> old-stuff/win32/language_switch.vcproj
> old-stuff/win32/pcl.vcproj
> old-stuff/win32/xps.vcproj
> old-stuff/winrt/GhostPDL.sln
> old-stuff/xcode/GhostPDL/GhostPDL.xcodeproj/project.pbxproj
> old-stuff/xcode/GhostPDL/GhostPDL.xcodeproj/project.xcworkspace/contents.xcworkspacedata
> old-stuff/xcode/GhostPDL/GhostPDL.xcodeproj/xcshareddata/xcschemes/GhostPDL.xcscheme
> old-stuff/xcode/GhostPDL/GhostPDL.xcodeproj/xcshareddata/xcschemes/ghostscript.xcscheme
> old-stuff/xcode/GhostPDL/GhostPDL.xcodeproj/xcshareddata/xcschemes/language_switch.xcscheme
> old-stuff/xcode/GhostPDL/GhostPDL.xcodeproj/xcshareddata/xcschemes/pcl.xcscheme
> old-stuff/xcode/GhostPDL/GhostPDL.xcodeproj/xcshareddata/xcschemes/svg.xcscheme
> old-stuff/xcode/GhostPDL/GhostPDL.xcodeproj/xcshareddata/xcschemes/xps.xcscheme
> old-stuff/xcode/Makefile
> old-stuff/xcode/clang_wrapper.c
> old-stuff/xcode/clang_wrapper.sh
> old-stuff/xcode/resolve.sh
> openjpeg/AUTHORS
> openjpeg/CHANGES
> openjpeg/LICENSE
> openjpeg/NEWS
> openjpeg/THANKS
> openjpeg/src/lib/openjp2/CMakeLists.txt
> openjpeg/src/lib/openjp2/bio.c
> openjpeg/src/lib/openjp2/bio.h
> openjpeg/src/lib/openjp2/cidx_manager.c
> openjpeg/src/lib/openjp2/cidx_manager.h
> openjpeg/src/lib/openjp2/cio.c
> openjpeg/src/lib/openjp2/cio.h
> openjpeg/src/lib/openjp2/dwt.c
> openjpeg/src/lib/openjp2/dwt.h
> openjpeg/src/lib/openjp2/event.c
> openjpeg/src/lib/openjp2/event.h
> openjpeg/src/lib/openjp2/function_list.c
> openjpeg/src/lib/openjp2/function_list.h
> openjpeg/src/lib/openjp2/image.c
> openjpeg/src/lib/openjp2/image.h
> openjpeg/src/lib/openjp2/indexbox_manager.h
> openjpeg/src/lib/openjp2/invert.c
> openjpeg/src/lib/openjp2/invert.h
> openjpeg/src/lib/openjp2/j2k.c
> openjpeg/src/lib/openjp2/j2k.h
> openjpeg/src/lib/openjp2/jp2.c
> openjpeg/src/lib/openjp2/jp2.h
> openjpeg/src/lib/openjp2/libopenjp2.pc.cmake.in
> openjpeg/src/lib/openjp2/mct.c
> openjpeg/src/lib/openjp2/mct.h
> openjpeg/src/lib/openjp2/mqc.c
> openjpeg/src/lib/openjp2/mqc.h
> openjpeg/src/lib/openjp2/openjpeg.c
> openjpeg/src/lib/openjp2/openjpeg.h
> openjpeg/src/lib/openjp2/opj_clock.c
> openjpeg/src/lib/openjp2/opj_clock.h
> openjpeg/src/lib/openjp2/opj_codec.h
> openjpeg/src/lib/openjp2/opj_config.h
> openjpeg/src/lib/openjp2/opj_config.h.cmake.in
> openjpeg/src/lib/openjp2/opj_config_private.h
> openjpeg/src/lib/openjp2/opj_config_private.h.cmake.in
> openjpeg/src/lib/openjp2/opj_includes.h
> openjpeg/src/lib/openjp2/opj_intmath.h
> openjpeg/src/lib/openjp2/opj_inttypes.h
> openjpeg/src/lib/openjp2/opj_malloc.h
> openjpeg/src/lib/openjp2/opj_stdint.h
> openjpeg/src/lib/openjp2/phix_manager.c
> openjpeg/src/lib/openjp2/pi.c
> openjpeg/src/lib/openjp2/pi.h
> openjpeg/src/lib/openjp2/ppix_manager.c
> openjpeg/src/lib/openjp2/raw.c
> openjpeg/src/lib/openjp2/raw.h
> openjpeg/src/lib/openjp2/t1.c
> openjpeg/src/lib/openjp2/t1.h
> openjpeg/src/lib/openjp2/t1_generate_luts.c
> openjpeg/src/lib/openjp2/t1_luts.h
> openjpeg/src/lib/openjp2/t2.c
> openjpeg/src/lib/openjp2/t2.h
> openjpeg/src/lib/openjp2/tcd.c
> openjpeg/src/lib/openjp2/tcd.h
> openjpeg/src/lib/openjp2/tgt.c
> openjpeg/src/lib/openjp2/tgt.h
> openjpeg/src/lib/openjp2/thix_manager.c
> openjpeg/src/lib/openjp2/tpix_manager.c
> pcl/Anomalies.txt
> pcl/COPYING.AFPL
> pcl/LICENSE
> pcl/NEWS
> pcl/PCL5C_Color_Laserjet_4700_Differences.xls
> pcl/README.txt
> pcl/pcbiptrn.c
> pcl/pcbiptrn.h
> pcl/pccid.c
> pcl/pccid.h
> pcl/pccolor.c
> pcl/pccoord.h
> pcl/pccprint.c
> pcl/pccsbase.c
> pcl/pccsbase.h
> pcl/pcdict.h
> pcl/pcdither.c
> pcl/pcdither.h
> pcl/pcdraw.c
> pcl/pcdraw.h
> pcl/pcfont.c
> pcl/pcfont.h
> pcl/pcfontpg.c
> pcl/pcfontst.h
> pcl/pcfrgrnd.c
> pcl/pcfrgrnd.h
> pcl/pcfsel.c
> pcl/pcfsel.h
> pcl/pcht.c
> pcl/pcht.h
> pcl/pcident.c
> pcl/pcident.h
> pcl/pcimpl.c
> pcl/pcindxed.c
> pcl/pcindxed.h
> pcl/pcjob.c
> pcl/pcl.mak
> pcl/pcl/Anomalies.txt
> pcl/pcl/PCL5C_Color_Laserjet_4700_Differences.xls
> pcl/pcl/pcbiptrn.c
> pcl/pcl/pcbiptrn.h
> pcl/pcl/pccid.c
> pcl/pcl/pccid.h
> pcl/pcl/pccolor.c
> pcl/pcl/pccoord.h
> pcl/pcl/pccprint.c
> pcl/pcl/pccsbase.c
> pcl/pcl/pccsbase.h
> pcl/pcl/pcdict.h
> pcl/pcl/pcdither.c
> pcl/pcl/pcdither.h
> pcl/pcl/pcdraw.c
> pcl/pcl/pcdraw.h
> pcl/pcl/pcfont.c
> pcl/pcl/pcfont.h
> pcl/pcl/pcfontpg.c
> pcl/pcl/pcfontst.h
> pcl/pcl/pcfrgrnd.c
> pcl/pcl/pcfrgrnd.h
> pcl/pcl/pcfsel.c
> pcl/pcl/pcfsel.h
> pcl/pcl/pcht.c
> pcl/pcl/pcht.h
> pcl/pcl/pcident.c
> pcl/pcl/pcident.h
> pcl/pcl/pcimpl.c
> pcl/pcl/pcindxed.c
> pcl/pcl/pcindxed.h
> pcl/pcl/pcjob.c
> pcl/pcl/pcl.mak
> pcl/pcl/pcl_top.mak
> pcl/pcl/pclookup.c
> pcl/pcl/pclookup.h
> pcl/pcl/pcmacros.c
> pcl/pcl/pcmisc.c
> pcl/pcl/pcmtx3.c
> pcl/pcl/pcmtx3.h
> pcl/pcl/pcommand.c
> pcl/pcl/pcommand.h
> pcl/pcl/pcpage.c
> pcl/pcl/pcpage.h
> pcl/pcl/pcpalet.c
> pcl/pcl/pcpalet.h
> pcl/pcl/pcparam.h
> pcl/pcl/pcparse.c
> pcl/pcl/pcparse.h
> pcl/pcl/pcpatrn.c
> pcl/pcl/pcpatrn.h
> pcl/pcl/pcpattyp.h
> pcl/pcl/pcpatxfm.c
> pcl/pcl/pcpatxfm.h
> pcl/pcl/pcrect.c
> pcl/pcl/pcsfont.c
> pcl/pcl/pcstate.h
> pcl/pcl/pcstatus.c
> pcl/pcl/pcsymbol.c
> pcl/pcl/pcsymbol.h
> pcl/pcl/pctext.c
> pcl/pcl/pctop.c
> pcl/pcl/pctop.h
> pcl/pcl/pctpm.h
> pcl/pcl/pcuptrn.c
> pcl/pcl/pcuptrn.h
> pcl/pcl/pcursor.c
> pcl/pcl/pcursor.h
> pcl/pcl/pcwhtidx.c
> pcl/pcl/pcwhtidx.h
> pcl/pcl/pcxfmst.h
> pcl/pcl/pgchar.c
> pcl/pcl/pgcolor.c
> pcl/pcl/pgconfig.c
> pcl/pcl/pgdraw.c
> pcl/pcl/pgdraw.h
> pcl/pcl/pgfdata.c
> pcl/pcl/pgfdata.h
> pcl/pcl/pgfont.c
> pcl/pcl/pgfont.h
> pcl/pcl/pgframe.c
> pcl/pcl/pggeom.c
> pcl/pcl/pggeom.h
> pcl/pcl/pginit.c
> pcl/pcl/pginit.h
> pcl/pcl/pglabel.c
> pcl/pcl/pglfill.c
> pcl/pcl/pgmand.h
> pcl/pcl/pgmisc.c
> pcl/pcl/pgmisc.h
> pcl/pcl/pgparse.c
> pcl/pcl/pgpoly.c
> pcl/pcl/pgstate.h
> pcl/pcl/pgvector.c
> pcl/pcl/rtgmode.c
> pcl/pcl/rtgmode.h
> pcl/pcl/rtmisc.c
> pcl/pcl/rtmisc.h
> pcl/pcl/rtraster.c
> pcl/pcl/rtraster.h
> pcl/pcl/rtrstcmp.c
> pcl/pcl/rtrstcmp.h
> pcl/pcl/rtrstst.h
> pcl/pcl_top.mak
> pcl/pclookup.c
> pcl/pclookup.h
> pcl/pcmacros.c
> pcl/pcmisc.c
> pcl/pcmtx3.c
> pcl/pcmtx3.h
> pcl/pcommand.c
> pcl/pcommand.h
> pcl/pcpage.c
> pcl/pcpage.h
> pcl/pcpalet.c
> pcl/pcpalet.h
> pcl/pcparam.h
> pcl/pcparse.c
> pcl/pcparse.h
> pcl/pcpatrn.c
> pcl/pcpatrn.h
> pcl/pcpattyp.h
> pcl/pcpatxfm.c
> pcl/pcpatxfm.h
> pcl/pcrect.c
> pcl/pcsfont.c
> pcl/pcstate.h
> pcl/pcstatus.c
> pcl/pcsymbol.c
> pcl/pcsymbol.h
> pcl/pctext.c
> pcl/pctop.c
> pcl/pctop.h
> pcl/pctpm.h
> pcl/pcuptrn.c
> pcl/pcuptrn.h
> pcl/pcursor.c
> pcl/pcursor.h
> pcl/pcwhtidx.c
> pcl/pcwhtidx.h
> pcl/pcxfmst.h
> pcl/pgchar.c
> pcl/pgcolor.c
> pcl/pgconfig.c
> pcl/pgdraw.c
> pcl/pgdraw.h
> pcl/pgfdata.c
> pcl/pgfdata.h
> pcl/pgfont.c
> pcl/pgfont.h
> pcl/pgframe.c
> pcl/pggeom.c
> pcl/pggeom.h
> pcl/pginit.c
> pcl/pginit.h
> pcl/pglabel.c
> pcl/pglfill.c
> pcl/pgmand.h
> pcl/pgmisc.c
> pcl/pgmisc.h
> pcl/pgparse.c
> pcl/pgpoly.c
> pcl/pgstate.h
> pcl/pgvector.c
> pcl/pl/pjparse.c
> pcl/pl/pjparse.h
> pcl/pl/pjparsei.c
> pcl/pl/pjtop.c
> pcl/pl/pjtop.h
> pcl/pl/pl.mak
> pcl/pl/plalloc.c
> pcl/pl/plalloc.h
> pcl/pl/plapi.h
> pcl/pl/plchar.c
> pcl/pl/plchar.h
> pcl/pl/pldebug.h
> pcl/pl/pldict.c
> pcl/pl/pldict.h
> pcl/pl/pldraw.c
> pcl/pl/pldraw.h
> pcl/pl/plfapi.c
> pcl/pl/plfapi.h
> pcl/pl/plfont.c
> pcl/pl/plfont.h
> pcl/pl/plftable.c
> pcl/pl/plftable.h
> pcl/pl/plht.c
> pcl/pl/plht.h
> pcl/pl/plimpl.c
> pcl/pl/pllfont.c
> pcl/pl/pllfont.h
> pcl/pl/plmain.c
> pcl/pl/plmain.h
> pcl/pl/plparse.h
> pcl/pl/plplatf.c
> pcl/pl/plplatf.h
> pcl/pl/plplatfps.c
> pcl/pl/plromfs.mak
> pcl/pl/plsymbol.c
> pcl/pl/plsymbol.h
> pcl/pl/pltop.c
> pcl/pl/pltop.h
> pcl/pl/pltoputl.c
> pcl/pl/pltoputl.h
> pcl/pl/pluchar.c
> pcl/pl/plufont.c
> pcl/pl/plufstlp.c
> pcl/pl/plufstlp.h
> pcl/pl/plufstlp1.c
> pcl/pl/plulfont.c
> pcl/pl/plvalue.c
> pcl/pl/plvalue.h
> pcl/pl/plvocab.c
> pcl/pl/plvocab.h
> pcl/pl/plwimg.c
> pcl/pl/plwimg.h
> pcl/pl/plwmainc.c
> pcl/pl/plwreg.c
> pcl/pl/plwreg.h
> pcl/pl/plwres.h
> pcl/pl/realmain.c
> pcl/pxl/PXL_Color_Laserjet_4700_Differences.xls
> pcl/pxl/pxasm.bat
> pcl/pxl/pxasm.ps
> pcl/pxl/pxattr.h
> pcl/pxl/pxbfont.c
> pcl/pxl/pxbfont.h
> pcl/pxl/pxbfont.ps
> pcl/pxl/pxcet.txt
> pcl/pxl/pxdict.h
> pcl/pxl/pxdiff.txt
> pcl/pxl/pxenum.h
> pcl/pxl/pxerrors.c
> pcl/pxl/pxerrors.h
> pcl/pxl/pxffont.c
> pcl/pxl/pxfont.c
> pcl/pxl/pxfont.h
> pcl/pxl/pxfts.txt
> pcl/pxl/pxgstate.c
> pcl/pxl/pxgstate.h
> pcl/pxl/pximage.c
> pcl/pxl/pximpl.c
> pcl/pxl/pxink.c
> pcl/pxl/pxl.mak
> pcl/pxl/pxlib.txt
> pcl/pxl/pxoper.h
> pcl/pxl/pxpaint.c
> pcl/pxl/pxparse.c
> pcl/pxl/pxparse.h
> pcl/pxl/pxptable.c
> pcl/pxl/pxptable.h
> pcl/pxl/pxpthr.c
> pcl/pxl/pxpthr.h
> pcl/pxl/pxsessio.c
> pcl/pxl/pxspec.txt
> pcl/pxl/pxstate.c
> pcl/pxl/pxstate.h
> pcl/pxl/pxstream.c
> pcl/pxl/pxsymbol.ps
> pcl/pxl/pxsymbol.psc
> pcl/pxl/pxsymbol.psh
> pcl/pxl/pxtag.h
> pcl/pxl/pxtop.c
> pcl/pxl/pxvalue.c
> pcl/pxl/pxvalue.h
> pcl/pxl/pxvendor.c
> pcl/pxl/pxvendor.h
> pcl/rtgmode.c
> pcl/rtgmode.h
> pcl/rtmisc.c
> pcl/rtmisc.h
> pcl/rtraster.c
> pcl/rtraster.h
> pcl/rtrstcmp.c
> pcl/rtrstcmp.h
> pcl/rtrstst.h
> pcl/tools/Acrobat2Tiff/Acrobat2Tiff.sln
> pcl/tools/Acrobat2Tiff/Acrobat2Tiff/Acrobat2Tiff.vb
> pcl/tools/Acrobat2Tiff/Acrobat2Tiff/Acrobat2Tiff.vbproj
> pcl/tools/Acrobat2Tiff/Acrobat2Tiff/Acrobat2Tiff/Application.Designer.vb
> pcl/tools/Acrobat2Tiff/Acrobat2Tiff/Acrobat2Tiff/Application.myapp
> pcl/tools/Acrobat2Tiff/Acrobat2Tiff/Acrobat2Tiff/AssemblyInfo.vb
> pcl/tools/Acrobat2Tiff/Acrobat2Tiff/Acrobat2Tiff/Resources.Designer.vb
> pcl/tools/Acrobat2Tiff/Acrobat2Tiff/Acrobat2Tiff/Resources.resx
> pcl/tools/Acrobat2Tiff/Acrobat2Tiff/Acrobat2Tiff/Settings.Designer.vb
> pcl/tools/Acrobat2Tiff/Acrobat2Tiff/Acrobat2Tiff/Settings.settings
> pcl/tools/Acrobat2Tiff/Acrobat2Tiff/bin/Release/Acrobat2Tiff.exe
> pcl/tools/Acrobat2Tiff/Acrobat2Tiff/bin/Release/Acrobat2Tiff.vshost.exe
> pcl/tools/Acrobat2Tiff/Acrobat2Tiff/bin/Release/Acrobat2Tiff.xml
> pcl/tools/Acrobat2Tiff/Acrobat2Tiff/bin/Release/Interop.Acrobat.dll
> pcl/tools/GOT/README
> pcl/tools/GOT/detag.c
> pcl/tools/GOT/dotags.sh
> pcl/tools/GOT/tagimage.c
> pcl/tools/bitfont.pcl
> pcl/tools/bitfonts.pxl
> pcl/tools/cat_url.py
> pcl/tools/check_deps.py
> pcl/tools/cmpi/Makefile
> pcl/tools/cmpi/Makefile.in
> pcl/tools/cmpi/README
> pcl/tools/cmpi/cmpi.bkl
> pcl/tools/cmpi/cmpi.cpp
> pcl/tools/cmpi/cmpi.dsp
> pcl/tools/cmpi/cmpi.dsw
> pcl/tools/cmpi/cmpi.pro
> pcl/tools/cmpi/cmpi.rc
> pcl/tools/cmpi/cmpi.sln
> pcl/tools/cmpi/cmpi.suo
> pcl/tools/cmpi/cmpi.vcp
> pcl/tools/cmpi/cmpi.vcproj
> pcl/tools/cmpi/cmpi.vcw
> pcl/tools/cmpi/descrip.mms
> pcl/tools/cmpi/makefile.bcc
> pcl/tools/cmpi/makefile.dmc
> pcl/tools/cmpi/makefile.dms
> pcl/tools/cmpi/makefile.dos
> pcl/tools/cmpi/makefile.gcc
> pcl/tools/cmpi/makefile.sc
> pcl/tools/cmpi/makefile.unx
> pcl/tools/cmpi/makefile.va
> pcl/tools/cmpi/makefile.vc
> pcl/tools/cmpi/makefile.wat
> pcl/tools/docov.pl
> pcl/tools/fills.pcl
> pcl/tools/fontpage.pcl
> pcl/tools/fonts.pcl
> pcl/tools/fonts.pxl
> pcl/tools/frs96.pxl
> pcl/tools/gl-chars.pcl
> pcl/tools/gl2_chars.pl
> pcl/tools/grashopp.pcl
> pcl/tools/grid.pcl
> pcl/tools/label.tst
> pcl/tools/lineprinter.pcl
> pcl/tools/make_snapshot.sh
> pcl/tools/makeromttf.py
> pcl/tools/null.pxl
> pcl/tools/opaque.pcl
> pcl/tools/origins.pcl
> pcl/tools/owl.pcl
> pcl/tools/owl2.pcl
> pcl/tools/pattern.pcl
> pcl/tools/pattern.pxl
> pcl/tools/pcl2pdf
> pcl/tools/pcl2pdf.bat
> pcl/tools/pcl2pdfwr
> pcl/tools/pcl2pdfwr.bat
> pcl/tools/plot2pdf.sh
> pcl/tools/pxlasm.py
> pcl/tools/pxldis.py
> pcl/tools/regress.sh
> pcl/tools/revlist.py
> pcl/tools/smoke_baseline.txt
> pcl/tools/smoke_check.sh
> pcl/tools/smoke_update.sh
> pcl/tools/suite.tcl
> pcl/tools/tiger.px3
> pcl/tools/tiger.svg
> pcl/tools/tt2pcl.c
> pcl/tools/vasarely.px3
> pcl/urwfonts/A028-Ext.ttf
> pcl/urwfonts/A028-Med.ttf
> pcl/urwfonts/A030-Bol.ttf
> pcl/urwfonts/A030-BolIta.ttf
> pcl/urwfonts/A030-Ita.ttf
> pcl/urwfonts/A030-Reg.ttf
> pcl/urwfonts/AntiqueOlive-Bol.ttf
> pcl/urwfonts/AntiqueOlive-Ita.ttf
> pcl/urwfonts/AntiqueOlive-Reg.ttf
> pcl/urwfonts/ArtLinePrinter.ttf
> pcl/urwfonts/CenturySchL-Bold.ttf
> pcl/urwfonts/CenturySchL-BoldItal.ttf
> pcl/urwfonts/CenturySchL-Ital.ttf
> pcl/urwfonts/CenturySchL-Roma.ttf
> pcl/urwfonts/ClarendonURW-BolCon.ttf
> pcl/urwfonts/Coronet.ttf
> pcl/urwfonts/Dingbats.ttf
> pcl/urwfonts/GaramondNo8-Ita.ttf
> pcl/urwfonts/GaramondNo8-Med.ttf
> pcl/urwfonts/GaramondNo8-MedIta.ttf
> pcl/urwfonts/GaramondNo8-Reg.ttf
> pcl/urwfonts/LetterGothic-Bol.ttf
> pcl/urwfonts/LetterGothic-Ita.ttf
> pcl/urwfonts/LetterGothic-Reg.ttf
> pcl/urwfonts/Mauritius-Reg.ttf
> pcl/urwfonts/NewDingbats.ttf
> pcl/urwfonts/NimbusMonL-Bold.ttf
> pcl/urwfonts/NimbusMonL-BoldObli.ttf
> pcl/urwfonts/NimbusMonL-Regu.ttf
> pcl/urwfonts/NimbusMonL-ReguObli.ttf
> pcl/urwfonts/NimbusMono-Bol.ttf
> pcl/urwfonts/NimbusMono-BolIta.ttf
> pcl/urwfonts/NimbusMono-Ita.ttf
> pcl/urwfonts/NimbusMono-Reg.ttf
> pcl/urwfonts/NimbusRomNo9L-Medi.ttf
> pcl/urwfonts/NimbusRomNo9L-MediItal.ttf
> pcl/urwfonts/NimbusRomNo9L-Regu.ttf
> pcl/urwfonts/NimbusRomNo9L-ReguItal.ttf
> pcl/urwfonts/NimbusRomanNo4-Bol.ttf
> pcl/urwfonts/NimbusRomanNo4-BolIta.ttf
> pcl/urwfonts/NimbusRomanNo4-Lig.ttf
> pcl/urwfonts/NimbusRomanNo4-LigIta.ttf
> pcl/urwfonts/NimbusRomanNo9-Ita.ttf
> pcl/urwfonts/NimbusRomanNo9-Med.ttf
> pcl/urwfonts/NimbusRomanNo9-MedIta.ttf
> pcl/urwfonts/NimbusRomanNo9-Reg.ttf
> pcl/urwfonts/NimbusSanL-Bold.ttf
> pcl/urwfonts/NimbusSanL-BoldCond.ttf
> pcl/urwfonts/NimbusSanL-BoldCondItal.ttf
> pcl/urwfonts/NimbusSanL-BoldItal.ttf
> pcl/urwfonts/NimbusSanL-Regu.ttf
> pcl/urwfonts/NimbusSanL-ReguCond.ttf
> pcl/urwfonts/NimbusSanL-ReguCondItal.ttf
> pcl/urwfonts/NimbusSanL-ReguItal.ttf
> pcl/urwfonts/StandardSymL.ttf
> pcl/urwfonts/U001-Bol.ttf
> pcl/urwfonts/U001-BolIta.ttf
> pcl/urwfonts/U001-Ita.ttf
> pcl/urwfonts/U001-Reg.ttf
> pcl/urwfonts/U001Con-Bol.ttf
> pcl/urwfonts/U001Con-BolIta.ttf
> pcl/urwfonts/U001Con-Ita.ttf
> pcl/urwfonts/U001Con-Reg.ttf
> pcl/urwfonts/URWBookmanL-DemiBold.ttf
> pcl/urwfonts/URWBookmanL-DemiBoldItal.ttf
> pcl/urwfonts/URWBookmanL-Ligh.ttf
> pcl/urwfonts/URWBookmanL-LighItal.ttf
> pcl/urwfonts/URWChanceryL-MediItal.ttf
> pcl/urwfonts/URWClassico-Bol.ttf
> pcl/urwfonts/URWClassico-BolIta.ttf
> pcl/urwfonts/URWClassico-Ita.ttf
> pcl/urwfonts/URWClassico-Reg.ttf
> pcl/urwfonts/URWGothicL-Book.ttf
> pcl/urwfonts/URWGothicL-BookObli.ttf
> pcl/urwfonts/URWGothicL-Demi.ttf
> pcl/urwfonts/URWGothicL-DemiObli.ttf
> pcl/urwfonts/URWPalladioL-Bold.ttf
> pcl/urwfonts/URWPalladioL-BoldItal.ttf
> pcl/urwfonts/URWPalladioL-Ital.ttf
> pcl/urwfonts/URWPalladioL-Roma.ttf
> pcl6/pcl6.xcodeproj/project.pbxproj
> pl/dwimg.c
> pl/dwimg.h
> pl/dwmainc.c
> pl/dwreg.c
> pl/dwreg.h
> pl/dwres.h
> pl/pjparse.c
> pl/pjparse.h
> pl/pjparsei.c
> pl/pjtop.c
> pl/pjtop.h
> pl/pl.mak
> pl/plalloc.c
> pl/plalloc.h
> pl/plapi.h
> pl/plchar.c
> pl/plchar.h
> pl/pldebug.h
> pl/pldict.c
> pl/pldict.h
> pl/pldraw.c
> pl/pldraw.h
> pl/plfapi.c
> pl/plfapi.h
> pl/plfont.c
> pl/plfont.h
> pl/plftable.c
> pl/plftable.h
> pl/plht.c
> pl/plht.h
> pl/plimpl.c
> pl/pllfont.c
> pl/pllfont.h
> pl/plmain.c
> pl/plmain.h
> pl/plparse.h
> pl/plplatf.c
> pl/plplatf.h
> pl/plplatfps.c
> pl/plsymbol.c
> pl/plsymbol.h
> pl/pltop.c
> pl/pltop.h
> pl/pltoputl.c
> pl/pltoputl.h
> pl/pluchar.c
> pl/plufont.c
> pl/plufstlp.c
> pl/plufstlp.h
> pl/plufstlp1.c
> pl/plulfont.c
> pl/plvalue.c
> pl/plvalue.h
> pl/plvocab.c
> pl/plvocab.h
> pl/realmain.c
> psi/apitest.c
> psi/bfont.h
> psi/btoken.h
> psi/dmmain.c
> psi/dmmain.r
> psi/dpmain.c
> psi/dscparse.c
> psi/dscparse.h
> psi/dstack.h
> psi/dw32c.def
> psi/dw64c.def
> psi/dwdll.c
> psi/dwdll.h
> psi/dwimg.c
> psi/dwimg.h
> psi/dwmain.c
> psi/dwmain.rc
> psi/dwmain32.def
> psi/dwmain64.def
> psi/dwmainc.c
> psi/dwnodll.c
> psi/dwreg.c
> psi/dwreg.h
> psi/dwres.h
> psi/dwsetup.def
> psi/dwsetup_x64.manifest
> psi/dwsetup_x86.manifest
> psi/dwtext.c
> psi/dwtext.h
> psi/dwtrace.c
> psi/dwtrace.h
> psi/dwuninst.def
> psi/dwuninst_x64.manifest
> psi/dwuninst_x86.manifest
> psi/dxmain.c
> psi/dxmainc.c
> psi/estack.h
> psi/files.h
> psi/ghost.h
> psi/gs.c
> psi/gsdll.c
> psi/gsdll2.def
> psi/gsdll2.rc
> psi/gsdll32.def
> psi/gsdll32.rc
> psi/gsdll32metro.def
> psi/gsdll32w.lnk
> psi/gsdll64.def
> psi/gsdll64metro.def
> psi/gsdllARM32metro.def
> psi/gserver.c
> psi/gsos2.def
> psi/gsos2.icx
> psi/gsos2.rc
> psi/ialloc.c
> psi/ialloc.h
> psi/iapi.c
> psi/iapi.h
> psi/iastate.h
> psi/iastruct.h
> psi/ibnum.c
> psi/ibnum.h
> psi/ichar.h
> psi/ichar1.h
> psi/icharout.h
> psi/icid.h
> psi/icie.h
> psi/icolor.h
> psi/iconf.c
> psi/iconf.h
> psi/icontext.c
> psi/icontext.h
> psi/icremap.h
> psi/icsmap.h
> psi/icstate.h
> psi/iddict.h
> psi/iddstack.h
> psi/idebug.c
> psi/idebug.h
> psi/idict.c
> psi/idict.h
> psi/idictdef.h
> psi/idicttpl.h
> psi/idisp.c
> psi/idisp.h
> psi/idosave.h
> psi/idparam.c
> psi/idparam.h
> psi/idsdata.h
> psi/idstack.c
> psi/idstack.h
> psi/ierrors.h
> psi/iesdata.h
> psi/iestack.h
> psi/ifapi.h
> psi/ifcid.h
> psi/ifilter.h
> psi/ifilter2.h
> psi/ifont.h
> psi/ifont1.h
> psi/ifont2.h
> psi/ifont42.h
> psi/ifrpred.h
> psi/ifunc.h
> psi/ifwpred.h
> psi/igc.c
> psi/igc.h
> psi/igcref.c
> psi/igcstr.c
> psi/igcstr.h
> psi/igstate.h
> psi/iht.h
> psi/iimage.h
> psi/iimage2.h
> psi/iinit.c
> psi/iinit.h
> psi/ilevel.h
> psi/ilocate.c
> psi/imain.c
> psi/imain.h
> psi/imainarg.c
> psi/imainarg.h
> psi/imemory.h
> psi/iminst.h
> psi/iname.c
> psi/iname.h
> psi/inamedef.h
> psi/inameidx.h
> psi/inames.h
> psi/inamestr.h
> psi/inobtokn.c
> psi/inouparm.c
> psi/int.mak
> psi/interp.c
> psi/interp.h
> psi/iosdata.h
> psi/iostack.h
> psi/ipacked.h
> psi/iparam.c
> psi/iparam.h
> psi/iparray.h
> psi/ipcolor.h
> psi/iplugin.c
> psi/iplugin.h
> psi/ireclaim.c
> psi/iref.h
> psi/isave.c
> psi/isave.h
> psi/iscan.c
> psi/iscan.h
> psi/iscanbin.c
> psi/iscanbin.h
> psi/iscannum.c
> psi/iscannum.h
> psi/isdata.h
> psi/isstate.h
> psi/istack.c
> psi/istack.h
> psi/istkparm.h
> psi/istream.h
> psi/istruct.h
> psi/itoken.h
> psi/iutil.c
> psi/iutil.h
> psi/iutil2.c
> psi/iutil2.h
> psi/ivmem2.h
> psi/ivmspace.h
> psi/main.h
> psi/mkfilelt.cpp
> psi/msvc.mak
> psi/msvc32.mak
> psi/msvc64.mak
> psi/nsisinst.nsi
> psi/oparc.h
> psi/opcheck.h
> psi/opdef.h
> psi/oper.h
> psi/opextern.h
> psi/os2.mak
> psi/ostack.h
> psi/psi.mak
> psi/psitop.c
> psi/psromfs.mak
> psi/sfilter1.c
> psi/store.h
> psi/winint.mak
> psi/zalg.c
> psi/zarith.c
> psi/zarray.c
> psi/zbfont.c
> psi/zbseq.c
> psi/zcfont.c
> psi/zchar.c
> psi/zchar1.c
> psi/zchar2.c
> psi/zchar32.c
> psi/zchar42.c
> psi/zchar42.h
> psi/zcharout.c
> psi/zcharx.c
> psi/zcid.c
> psi/zcidtest.c
> psi/zcie.c
> psi/zcie.h
> psi/zcolor.c
> psi/zcolor.h
> psi/zcolor1.c
> psi/zcolor2.c
> psi/zcolor3.c
> psi/zcontext.c
> psi/zcontrol.c
> psi/zcrd.c
> psi/zcsdevn.c
> psi/zcsindex.c
> psi/zcspixel.c
> psi/zcssepr.c
> psi/zdevcal.c
> psi/zdevice.c
> psi/zdevice2.c
> psi/zdfilter.c
> psi/zdict.c
> psi/zdosio.c
> psi/zdouble.c
> psi/zdpnext.c
> psi/zdps.c
> psi/zdps1.c
> psi/zdscpars.c
> psi/zfaes.c
> psi/zfapi.c
> psi/zfarc4.c
> psi/zfbcp.c
> psi/zfcid.c
> psi/zfcid0.c
> psi/zfcid1.c
> psi/zfcmap.c
> psi/zfdctd.c
> psi/zfdcte.c
> psi/zfdecode.c
> psi/zfile.c
> psi/zfile.h
> psi/zfile1.c
> psi/zfileio.c
> psi/zfilter.c
> psi/zfilter2.c
> psi/zfilterx.c
> psi/zfimscale.c
> psi/zfjbig2.c
> psi/zfjpx.c
> psi/zfmd5.c
> psi/zfont.c
> psi/zfont0.c
> psi/zfont1.c
> psi/zfont2.c
> psi/zfont32.c
> psi/zfont42.c
> psi/zfontenum.c
> psi/zform.c
> psi/zfproc.c
> psi/zfrsd.c
> psi/zfrsd.h
> psi/zfsample.c
> psi/zfsha2.c
> psi/zfunc.c
> psi/zfunc.h
> psi/zfunc0.c
> psi/zfunc3.c
> psi/zfunc4.c
> psi/zfzlib.c
> psi/zgeneric.c
> psi/zgstate.c
> psi/zhsb.c
> psi/zht.c
> psi/zht1.c
> psi/zht2.c
> psi/zht2.h
> psi/zicc.c
> psi/zicc.h
> psi/zimage.c
> psi/zimage2.c
> psi/zimage3.c
> psi/ziodev.c
> psi/ziodev2.c
> psi/ziodevs.c
> psi/ziodevsc.c
> psi/zmath.c
> psi/zmatrix.c
> psi/zmedia2.c
> psi/zmisc.c
> psi/zmisc1.c
> psi/zmisc2.c
> psi/zmisc3.c
> psi/zncdummy.c
> psi/zpacked.c
> psi/zpaint.c
> psi/zpath.c
> psi/zpath1.c
> psi/zpcolor.c
> psi/zpdf_r6.c
> psi/zpdfops.c
> psi/zrelbit.c
> psi/zrop.c
> psi/zshade.c
> psi/zstack.c
> psi/zstring.c
> psi/zsysvm.c
> psi/ztoken.c
> psi/ztrans.c
> psi/ztrap.c
> psi/ztype.c
> psi/zupath.c
> psi/zusparam.c
> psi/zutf8.c
> psi/zvmem.c
> psi/zvmem2.c
> psi/zwinutf8.c
> pxl/PXL_Color_Laserjet_4700_Differences.xls
> pxl/pxasm.bat
> pxl/pxasm.ps
> pxl/pxattr.h
> pxl/pxbfont.c
> pxl/pxbfont.h
> pxl/pxbfont.ps
> pxl/pxcet.txt
> pxl/pxdict.h
> pxl/pxdiff.txt
> pxl/pxenum.h
> pxl/pxerrors.c
> pxl/pxerrors.h
> pxl/pxffont.c
> pxl/pxfont.c
> pxl/pxfont.h
> pxl/pxfts.txt
> pxl/pxgstate.c
> pxl/pxgstate.h
> pxl/pximage.c
> pxl/pximpl.c
> pxl/pxink.c
> pxl/pxl.mak
> pxl/pxlib.txt
> pxl/pxoper.h
> pxl/pxpaint.c
> pxl/pxparse.c
> pxl/pxparse.h
> pxl/pxptable.c
> pxl/pxptable.h
> pxl/pxpthr.c
> pxl/pxpthr.h
> pxl/pxsessio.c
> pxl/pxspec.txt
> pxl/pxstate.c
> pxl/pxstate.h
> pxl/pxstream.c
> pxl/pxsymbol.ps
> pxl/pxsymbol.psc
> pxl/pxsymbol.psh
> pxl/pxtag.h
> pxl/pxtop.c
> pxl/pxvalue.c
> pxl/pxvalue.h
> pxl/pxvendor.c
> pxl/pxvendor.h
> tiff/COPYRIGHT
> tiff/ChangeLog
> tiff/HOWTO-RELEASE
> tiff/Makefile.am
> tiff/Makefile.in
> tiff/Makefile.vc
> tiff/README
> tiff/README.vms
> tiff/RELEASE-DATE
> tiff/SConstruct
> tiff/TODO
> tiff/VERSION
> tiff/aclocal.m4
> tiff/autogen.sh
> tiff/build/Makefile.am
> tiff/build/Makefile.in
> tiff/build/README
> tiff/config/compile
> tiff/config/config.guess
> tiff/config/config.sub
> tiff/config/depcomp
> tiff/config/install-sh
> tiff/config/ltmain.sh
> tiff/config/missing
> tiff/config/mkinstalldirs
> tiff/configure
> tiff/configure.ac
> tiff/configure.com
> tiff/contrib/Makefile.am
> tiff/contrib/Makefile.in
> tiff/contrib/README
> tiff/contrib/addtiffo/Makefile.am
> tiff/contrib/addtiffo/Makefile.in
> tiff/contrib/addtiffo/Makefile.vc
> tiff/contrib/addtiffo/README
> tiff/contrib/addtiffo/addtiffo.c
> tiff/contrib/addtiffo/tif_overview.c
> tiff/contrib/addtiffo/tif_ovrcache.c
> tiff/contrib/addtiffo/tif_ovrcache.h
> tiff/contrib/dbs/Makefile.am
> tiff/contrib/dbs/Makefile.in
> tiff/contrib/dbs/README
> tiff/contrib/dbs/tiff-bi.c
> tiff/contrib/dbs/tiff-grayscale.c
> tiff/contrib/dbs/tiff-palette.c
> tiff/contrib/dbs/tiff-rgb.c
> tiff/contrib/dbs/xtiff/Makefile.am
> tiff/contrib/dbs/xtiff/Makefile.in
> tiff/contrib/dbs/xtiff/README
> tiff/contrib/dbs/xtiff/patchlevel.h
> tiff/contrib/dbs/xtiff/xtiff.c
> tiff/contrib/dbs/xtiff/xtifficon.h
> tiff/contrib/iptcutil/Makefile.am
> tiff/contrib/iptcutil/Makefile.in
> tiff/contrib/iptcutil/README
> tiff/contrib/iptcutil/iptcutil.c
> tiff/contrib/iptcutil/test.iptc
> tiff/contrib/iptcutil/test.txt
> tiff/contrib/mfs/Makefile.am
> tiff/contrib/mfs/Makefile.in
> tiff/contrib/mfs/README
> tiff/contrib/mfs/mfs_file.c
> tiff/contrib/pds/Makefile.am
> tiff/contrib/pds/Makefile.in
> tiff/contrib/pds/README
> tiff/contrib/pds/tif_imageiter.c
> tiff/contrib/pds/tif_imageiter.h
> tiff/contrib/pds/tif_pdsdirread.c
> tiff/contrib/pds/tif_pdsdirwrite.c
> tiff/contrib/ras/Makefile.am
> tiff/contrib/ras/Makefile.in
> tiff/contrib/ras/README
> tiff/contrib/ras/ras2tif.c
> tiff/contrib/ras/tif2ras.c
> tiff/contrib/stream/Makefile.am
> tiff/contrib/stream/Makefile.in
> tiff/contrib/stream/README
> tiff/contrib/stream/tiffstream.cpp
> tiff/contrib/stream/tiffstream.h
> tiff/contrib/tags/Makefile.am
> tiff/contrib/tags/Makefile.in
> tiff/contrib/tags/README
> tiff/contrib/tags/listtif.c
> tiff/contrib/tags/maketif.c
> tiff/contrib/tags/xtif_dir.c
> tiff/contrib/tags/xtiffio.h
> tiff/contrib/tags/xtiffiop.h
> tiff/contrib/win_dib/Makefile.am
> tiff/contrib/win_dib/Makefile.in
> tiff/contrib/win_dib/Makefile.w95
> tiff/contrib/win_dib/README.Tiffile
> tiff/contrib/win_dib/README.tiff2dib
> tiff/contrib/win_dib/Tiffile.cpp
> tiff/contrib/win_dib/tiff2dib.c
> tiff/html/Makefile.am
> tiff/html/Makefile.in
> tiff/html/TIFFTechNote2.html
> tiff/html/addingtags.html
> tiff/html/bugs.html
> tiff/html/build.html
> tiff/html/contrib.html
> tiff/html/document.html
> tiff/html/images.html
> tiff/html/images/Makefile.am
> tiff/html/images/Makefile.in
> tiff/html/images/back.gif
> tiff/html/images/bali.jpg
> tiff/html/images/cat.gif
> tiff/html/images/cover.jpg
> tiff/html/images/cramps.gif
> tiff/html/images/dave.gif
> tiff/html/images/info.gif
> tiff/html/images/jello.jpg
> tiff/html/images/jim.gif
> tiff/html/images/note.gif
> tiff/html/images/oxford.gif
> tiff/html/images/quad.jpg
> tiff/html/images/ring.gif
> tiff/html/images/smallliz.jpg
> tiff/html/images/strike.gif
> tiff/html/images/warning.gif
> tiff/html/index.html
> tiff/html/internals.html
> tiff/html/intro.html
> tiff/html/libtiff.html
> tiff/html/man/Makefile.am
> tiff/html/man/Makefile.in
> tiff/html/man/TIFFClose.3tiff.html
> tiff/html/man/TIFFDataWidth.3tiff.html
> tiff/html/man/TIFFError.3tiff.html
> tiff/html/man/TIFFFlush.3tiff.html
> tiff/html/man/TIFFGetField.3tiff.html
> tiff/html/man/TIFFOpen.3tiff.html
> tiff/html/man/TIFFPrintDirectory.3tiff.html
> tiff/html/man/TIFFRGBAImage.3tiff.html
> tiff/html/man/TIFFReadDirectory.3tiff.html
> tiff/html/man/TIFFReadEncodedStrip.3tiff.html
> tiff/html/man/TIFFReadEncodedTile.3tiff.html
> tiff/html/man/TIFFReadRGBAImage.3tiff.html
> tiff/html/man/TIFFReadRGBAStrip.3tiff.html
> tiff/html/man/TIFFReadRGBATile.3tiff.html
> tiff/html/man/TIFFReadRawStrip.3tiff.html
> tiff/html/man/TIFFReadRawTile.3tiff.html
> tiff/html/man/TIFFReadScanline.3tiff.html
> tiff/html/man/TIFFReadTile.3tiff.html
> tiff/html/man/TIFFSetDirectory.3tiff.html
> tiff/html/man/TIFFSetField.3tiff.html
> tiff/html/man/TIFFWarning.3tiff.html
> tiff/html/man/TIFFWriteDirectory.3tiff.html
> tiff/html/man/TIFFWriteEncodedStrip.3tiff.html
> tiff/html/man/TIFFWriteEncodedTile.3tiff.html
> tiff/html/man/TIFFWriteRawStrip.3tiff.html
> tiff/html/man/TIFFWriteRawTile.3tiff.html
> tiff/html/man/TIFFWriteScanline.3tiff.html
> tiff/html/man/TIFFWriteTile.3tiff.html
> tiff/html/man/TIFFbuffer.3tiff.html
> tiff/html/man/TIFFcodec.3tiff.html
> tiff/html/man/TIFFcolor.3tiff.html
> tiff/html/man/TIFFmemory.3tiff.html
> tiff/html/man/TIFFquery.3tiff.html
> tiff/html/man/TIFFsize.3tiff.html
> tiff/html/man/TIFFstrip.3tiff.html
> tiff/html/man/TIFFswab.3tiff.html
> tiff/html/man/TIFFtile.3tiff.html
> tiff/html/man/fax2ps.1.html
> tiff/html/man/fax2tiff.1.html
> tiff/html/man/gif2tiff.1.html
> tiff/html/man/index.html
> tiff/html/man/libtiff.3tiff.html
> tiff/html/man/pal2rgb.1.html
> tiff/html/man/ppm2tiff.1.html
> tiff/html/man/ras2tiff.1.html
> tiff/html/man/raw2tiff.1.html
> tiff/html/man/rgb2ycbcr.1.html
> tiff/html/man/sgi2tiff.1.html
> tiff/html/man/thumbnail.1.html
> tiff/html/man/tiff2bw.1.html
> tiff/html/man/tiff2pdf.1.html
> tiff/html/man/tiff2ps.1.html
> tiff/html/man/tiff2rgba.1.html
> tiff/html/man/tiffcmp.1.html
> tiff/html/man/tiffcp.1.html
> tiff/html/man/tiffcrop.1.html
> tiff/html/man/tiffdither.1.html
> tiff/html/man/tiffdump.1.html
> tiff/html/man/tiffgt.1.html
> tiff/html/man/tiffinfo.1.html
> tiff/html/man/tiffmedian.1.html
> tiff/html/man/tiffset.1.html
> tiff/html/man/tiffsplit.1.html
> tiff/html/man/tiffsv.1.html
> tiff/html/misc.html
> tiff/html/support.html
> tiff/html/tools.html
> tiff/html/v3.4beta007.html
> tiff/html/v3.4beta016.html
> tiff/html/v3.4beta018.html
> tiff/html/v3.4beta024.html
> tiff/html/v3.4beta028.html
> tiff/html/v3.4beta029.html
> tiff/html/v3.4beta031.html
> tiff/html/v3.4beta032.html
> tiff/html/v3.4beta033.html
> tiff/html/v3.4beta034.html
> tiff/html/v3.4beta035.html
> tiff/html/v3.4beta036.html
> tiff/html/v3.5.1.html
> tiff/html/v3.5.2.html
> tiff/html/v3.5.3.html
> tiff/html/v3.5.4.html
> tiff/html/v3.5.5.html
> tiff/html/v3.5.6-beta.html
> tiff/html/v3.5.7.html
> tiff/html/v3.6.0.html
> tiff/html/v3.6.1.html
> tiff/html/v3.7.0.html
> tiff/html/v3.7.0alpha.html
> tiff/html/v3.7.0beta.html
> tiff/html/v3.7.0beta2.html
> tiff/html/v3.7.1.html
> tiff/html/v3.7.2.html
> tiff/html/v3.7.3.html
> tiff/html/v3.7.4.html
> tiff/html/v3.8.0.html
> tiff/html/v3.8.1.html
> tiff/html/v3.8.2.html
> tiff/html/v3.9.0beta.html
> tiff/html/v3.9.1.html
> tiff/html/v3.9.2.html
> tiff/html/v4.0.0.html
> tiff/libtiff-4.pc.in
> tiff/libtiff/Makefile.am
> tiff/libtiff/Makefile.in
> tiff/libtiff/Makefile.vc
> tiff/libtiff/SConstruct
> tiff/libtiff/libtiff.def
> tiff/libtiff/libtiff.map
> tiff/libtiff/libtiffxx.map
> tiff/libtiff/mkg3states.c
> tiff/libtiff/t4.h
> tiff/libtiff/tif_aux.c
> tiff/libtiff/tif_close.c
> tiff/libtiff/tif_codec.c
> tiff/libtiff/tif_color.c
> tiff/libtiff/tif_compress.c
> tiff/libtiff/tif_config.h-vms
> tiff/libtiff/tif_config.h.in
> tiff/libtiff/tif_config.vc.h
> tiff/libtiff/tif_config.wince.h
> tiff/libtiff/tif_dir.c
> tiff/libtiff/tif_dir.h
> tiff/libtiff/tif_dirinfo.c
> tiff/libtiff/tif_dirread.c
> tiff/libtiff/tif_dirwrite.c
> tiff/libtiff/tif_dumpmode.c
> tiff/libtiff/tif_error.c
> tiff/libtiff/tif_extension.c
> tiff/libtiff/tif_fax3.c
> tiff/libtiff/tif_fax3.h
> tiff/libtiff/tif_fax3sm.c
> tiff/libtiff/tif_flush.c
> tiff/libtiff/tif_getimage.c
> tiff/libtiff/tif_jbig.c
> tiff/libtiff/tif_jpeg.c
> tiff/libtiff/tif_jpeg_12.c
> tiff/libtiff/tif_luv.c
> tiff/libtiff/tif_lzma.c
> tiff/libtiff/tif_lzw.c
> tiff/libtiff/tif_next.c
> tiff/libtiff/tif_ojpeg.c
> tiff/libtiff/tif_open.c
> tiff/libtiff/tif_packbits.c
> tiff/libtiff/tif_pixarlog.c
> tiff/libtiff/tif_predict.c
> tiff/libtiff/tif_predict.h
> tiff/libtiff/tif_print.c
> tiff/libtiff/tif_read.c
> tiff/libtiff/tif_stream.cxx
> tiff/libtiff/tif_strip.c
> tiff/libtiff/tif_swab.c
> tiff/libtiff/tif_thunder.c
> tiff/libtiff/tif_tile.c
> tiff/libtiff/tif_unix.c
> tiff/libtiff/tif_version.c
> tiff/libtiff/tif_warning.c
> tiff/libtiff/tif_win32.c
> tiff/libtiff/tif_write.c
> tiff/libtiff/tif_zip.c
> tiff/libtiff/tiff.h
> tiff/libtiff/tiffconf.h.in
> tiff/libtiff/tiffconf.vc.h
> tiff/libtiff/tiffconf.wince.h
> tiff/libtiff/tiffio.h
> tiff/libtiff/tiffio.hxx
> tiff/libtiff/tiffiop.h
> tiff/libtiff/tiffvers.h
> tiff/libtiff/uvcode.h
> tiff/m4/acinclude.m4
> tiff/m4/libtool.m4
> tiff/m4/ltoptions.m4
> tiff/m4/ltsugar.m4
> tiff/m4/ltversion.m4
> tiff/m4/lt~obsolete.m4
> tiff/man/Makefile.am
> tiff/man/Makefile.in
> tiff/man/TIFFClose.3tiff
> tiff/man/TIFFDataWidth.3tiff
> tiff/man/TIFFError.3tiff
> tiff/man/TIFFFlush.3tiff
> tiff/man/TIFFGetField.3tiff
> tiff/man/TIFFOpen.3tiff
> tiff/man/TIFFPrintDirectory.3tiff
> tiff/man/TIFFRGBAImage.3tiff
> tiff/man/TIFFReadDirectory.3tiff
> tiff/man/TIFFReadEncodedStrip.3tiff
> tiff/man/TIFFReadEncodedTile.3tiff
> tiff/man/TIFFReadRGBAImage.3tiff
> tiff/man/TIFFReadRGBAStrip.3tiff
> tiff/man/TIFFReadRGBATile.3tiff
> tiff/man/TIFFReadRawStrip.3tiff
> tiff/man/TIFFReadRawTile.3tiff
> tiff/man/TIFFReadScanline.3tiff
> tiff/man/TIFFReadTile.3tiff
> tiff/man/TIFFSetDirectory.3tiff
> tiff/man/TIFFSetField.3tiff
> tiff/man/TIFFWarning.3tiff
> tiff/man/TIFFWriteDirectory.3tiff
> tiff/man/TIFFWriteEncodedStrip.3tiff
> tiff/man/TIFFWriteEncodedTile.3tiff
> tiff/man/TIFFWriteRawStrip.3tiff
> tiff/man/TIFFWriteRawTile.3tiff
> tiff/man/TIFFWriteScanline.3tiff
> tiff/man/TIFFWriteTile.3tiff
> tiff/man/TIFFbuffer.3tiff
> tiff/man/TIFFcodec.3tiff
> tiff/man/TIFFcolor.3tiff
> tiff/man/TIFFmemory.3tiff
> tiff/man/TIFFquery.3tiff
> tiff/man/TIFFsize.3tiff
> tiff/man/TIFFstrip.3tiff
> tiff/man/TIFFswab.3tiff
> tiff/man/TIFFtile.3tiff
> tiff/man/bmp2tiff.1
> tiff/man/fax2ps.1
> tiff/man/fax2tiff.1
> tiff/man/gif2tiff.1
> tiff/man/libtiff.3tiff
> tiff/man/pal2rgb.1
> tiff/man/ppm2tiff.1
> tiff/man/ras2tiff.1
> tiff/man/raw2tiff.1
> tiff/man/rgb2ycbcr.1
> tiff/man/sgi2tiff.1
> tiff/man/thumbnail.1
> tiff/man/tiff2bw.1
> tiff/man/tiff2pdf.1
> tiff/man/tiff2ps.1
> tiff/man/tiff2rgba.1
> tiff/man/tiffcmp.1
> tiff/man/tiffcp.1
> tiff/man/tiffcrop.1
> tiff/man/tiffdither.1
> tiff/man/tiffdump.1
> tiff/man/tiffgt.1
> tiff/man/tiffinfo.1
> tiff/man/tiffmedian.1
> tiff/man/tiffset.1
> tiff/man/tiffsplit.1
> tiff/man/tiffsv.1
> tiff/nmake.opt
> tiff/port/Makefile.am
> tiff/port/Makefile.in
> tiff/port/Makefile.vc
> tiff/port/dummy.c
> tiff/port/getopt.c
> tiff/port/lfind.c
> tiff/port/libport.h
> tiff/port/strcasecmp.c
> tiff/port/strtoul.c
> tiff/port/strtoull.c
> tiff/test/Makefile.am
> tiff/test/Makefile.in
> tiff/test/ascii_tag.c
> tiff/test/bmp2tiff_palette.sh
> tiff/test/bmp2tiff_rgb.sh
> tiff/test/check_tag.c
> tiff/test/common.sh
> tiff/test/gif2tiff.sh
> tiff/test/images/README.txt
> tiff/test/images/logluv-3c-16b.tiff
> tiff/test/images/minisblack-1c-16b.tiff
> tiff/test/images/minisblack-1c-8b.pgm
> tiff/test/images/minisblack-1c-8b.tiff
> tiff/test/images/minisblack-2c-8b-alpha.tiff
> tiff/test/images/miniswhite-1c-1b.pbm
> tiff/test/images/miniswhite-1c-1b.tiff
> tiff/test/images/palette-1c-1b.tiff
> tiff/test/images/palette-1c-4b.tiff
> tiff/test/images/palette-1c-8b.bmp
> tiff/test/images/palette-1c-8b.gif
> tiff/test/images/palette-1c-8b.tiff
> tiff/test/images/rgb-3c-16b.tiff
> tiff/test/images/rgb-3c-8b.bmp
> tiff/test/images/rgb-3c-8b.ppm
> tiff/test/images/rgb-3c-8b.tiff
> tiff/test/long_tag.c
> tiff/test/ppm2tiff_pbm.sh
> tiff/test/ppm2tiff_pgm.sh
> tiff/test/ppm2tiff_ppm.sh
> tiff/test/rewrite_tag.c
> tiff/test/short_tag.c
> tiff/test/strip.c
> tiff/test/strip_rw.c
> tiff/test/test_arrays.c
> tiff/test/test_arrays.h
> tiff/test/tiff2pdf.sh
> tiff/test/tiff2ps-EPS1.sh
> tiff/test/tiff2ps-PS1.sh
> tiff/test/tiff2ps-PS2.sh
> tiff/test/tiff2ps-PS3.sh
> tiff/test/tiff2rgba-logluv-3c-16b.sh
> tiff/test/tiff2rgba-minisblack-1c-16b.sh
> tiff/test/tiff2rgba-minisblack-1c-8b.sh
> tiff/test/tiff2rgba-minisblack-2c-8b-alpha.sh
> tiff/test/tiff2rgba-miniswhite-1c-1b.sh
> tiff/test/tiff2rgba-palette-1c-1b.sh
> tiff/test/tiff2rgba-palette-1c-4b.sh
> tiff/test/tiff2rgba-palette-1c-8b.sh
> tiff/test/tiff2rgba-rgb-3c-16b.sh
> tiff/test/tiff2rgba-rgb-3c-8b.sh
> tiff/test/tiffcp-g3-1d-fill.sh
> tiff/test/tiffcp-g3-1d.sh
> tiff/test/tiffcp-g3-2d-fill.sh
> tiff/test/tiffcp-g3-2d.sh
> tiff/test/tiffcp-g3.sh
> tiff/test/tiffcp-g4.sh
> tiff/test/tiffcp-logluv.sh
> tiff/test/tiffcp-split-join.sh
> tiff/test/tiffcp-split.sh
> tiff/test/tiffcp-thumbnail.sh
> tiff/test/tiffcrop-R90-logluv-3c-16b.sh
> tiff/test/tiffcrop-R90-minisblack-1c-16b.sh
> tiff/test/tiffcrop-R90-minisblack-1c-8b.sh
> tiff/test/tiffcrop-R90-minisblack-2c-8b-alpha.sh
> tiff/test/tiffcrop-R90-miniswhite-1c-1b.sh
> tiff/test/tiffcrop-R90-palette-1c-1b.sh
> tiff/test/tiffcrop-R90-palette-1c-4b.sh
> tiff/test/tiffcrop-R90-palette-1c-8b.sh
> tiff/test/tiffcrop-R90-rgb-3c-16b.sh
> tiff/test/tiffcrop-R90-rgb-3c-8b.sh
> tiff/test/tiffcrop-doubleflip-logluv-3c-16b.sh
> tiff/test/tiffcrop-doubleflip-minisblack-1c-16b.sh
> tiff/test/tiffcrop-doubleflip-minisblack-1c-8b.sh
> tiff/test/tiffcrop-doubleflip-minisblack-2c-8b-alpha.sh
> tiff/test/tiffcrop-doubleflip-miniswhite-1c-1b.sh
> tiff/test/tiffcrop-doubleflip-palette-1c-1b.sh
> tiff/test/tiffcrop-doubleflip-palette-1c-4b.sh
> tiff/test/tiffcrop-doubleflip-palette-1c-8b.sh
> tiff/test/tiffcrop-doubleflip-rgb-3c-16b.sh
> tiff/test/tiffcrop-doubleflip-rgb-3c-8b.sh
> tiff/test/tiffcrop-extract-logluv-3c-16b.sh
> tiff/test/tiffcrop-extract-minisblack-1c-16b.sh
> tiff/test/tiffcrop-extract-minisblack-1c-8b.sh
> tiff/test/tiffcrop-extract-minisblack-2c-8b-alpha.sh
> tiff/test/tiffcrop-extract-miniswhite-1c-1b.sh
> tiff/test/tiffcrop-extract-palette-1c-1b.sh
> tiff/test/tiffcrop-extract-palette-1c-4b.sh
> tiff/test/tiffcrop-extract-palette-1c-8b.sh
> tiff/test/tiffcrop-extract-rgb-3c-16b.sh
> tiff/test/tiffcrop-extract-rgb-3c-8b.sh
> tiff/test/tiffcrop-extractz14-logluv-3c-16b.sh
> tiff/test/tiffcrop-extractz14-minisblack-1c-16b.sh
> tiff/test/tiffcrop-extractz14-minisblack-1c-8b.sh
> tiff/test/tiffcrop-extractz14-minisblack-2c-8b-alpha.sh
> tiff/test/tiffcrop-extractz14-miniswhite-1c-1b.sh
> tiff/test/tiffcrop-extractz14-palette-1c-1b.sh
> tiff/test/tiffcrop-extractz14-palette-1c-4b.sh
> tiff/test/tiffcrop-extractz14-palette-1c-8b.sh
> tiff/test/tiffcrop-extractz14-rgb-3c-16b.sh
> tiff/test/tiffcrop-extractz14-rgb-3c-8b.sh
> tiff/test/tiffdump.sh
> tiff/test/tiffinfo.sh
> tiff/test/tifftest.h
> tiff/tools/Makefile.am
> tiff/tools/Makefile.in
> tiff/tools/Makefile.vc
> tiff/tools/bmp2tiff.c
> tiff/tools/fax2ps.c
> tiff/tools/fax2tiff.c
> tiff/tools/gif2tiff.c
> tiff/tools/pal2rgb.c
> tiff/tools/ppm2tiff.c
> tiff/tools/ras2tiff.c
> tiff/tools/rasterfile.h
> tiff/tools/raw2tiff.c
> tiff/tools/rgb2ycbcr.c
> tiff/tools/sgi2tiff.c
> tiff/tools/sgisv.c
> tiff/tools/thumbnail.c
> tiff/tools/tiff2bw.c
> tiff/tools/tiff2pdf.c
> tiff/tools/tiff2ps.c
> tiff/tools/tiff2rgba.c
> tiff/tools/tiffcmp.c
> tiff/tools/tiffcp.c
> tiff/tools/tiffcrop.c
> tiff/tools/tiffdither.c
> tiff/tools/tiffdump.c
> tiff/tools/tiffgt.c
> tiff/tools/tiffinfo.c
> tiff/tools/tiffmedian.c
> tiff/tools/tiffset.c
> tiff/tools/tiffsplit.c
> tiff/tools/ycbcr.c
> toolbin/GenSubstCID.ps
> toolbin/afmutil.py
> toolbin/apitest.pl
> toolbin/bmpcmp.c
> toolbin/bughunt.sh
> toolbin/bugsByEngineer.pl
> toolbin/checkdeps.pl
> toolbin/color/icc_creator/ICC Profiles/cmyk_k_ouput_only.icc
> toolbin/color/icc_creator/ICC Profiles/ps_emulate_cmyk.icc
> toolbin/color/icc_creator/ICC Profiles/ps_emulate_gray.icc
> toolbin/color/icc_creator/ICC Profiles/ps_emulate_rgb.icc
> toolbin/color/icc_creator/ICC_Creator.sln
> toolbin/color/icc_creator/ICC_Creator/CIELAB.h
> toolbin/color/icc_creator/ICC_Creator/ICC_Creator.cpp
> toolbin/color/icc_creator/ICC_Creator/ICC_Creator.h
> toolbin/color/icc_creator/ICC_Creator/ICC_Creator.rc
> toolbin/color/icc_creator/ICC_Creator/ICC_Creator.vcproj
> toolbin/color/icc_creator/ICC_Creator/ICC_CreatorDlg.cpp
> toolbin/color/icc_creator/ICC_Creator/ICC_CreatorDlg.h
> toolbin/color/icc_creator/ICC_Creator/icc34.h
> toolbin/color/icc_creator/ICC_Creator/icc_create.cpp
> toolbin/color/icc_creator/ICC_Creator/icc_create.h
> toolbin/color/icc_creator/ICC_Creator/res/ICC_Creator.rc2
> toolbin/color/icc_creator/ICC_Creator/res/gsimage_.ico
> toolbin/color/icc_creator/ICC_Creator/res/gswin.ico
> toolbin/color/icc_creator/ICC_Creator/resource.h
> toolbin/color/icc_creator/ICC_Creator/stdafx.cpp
> toolbin/color/icc_creator/ICC_Creator/stdafx.h
> toolbin/color/icc_creator/ICC_Creator/targetver.h
> toolbin/color/icc_creator/README.txt
> toolbin/color/icc_creator/effects/black_output.icc
> toolbin/color/icc_creator/effects/c_only.txt
> toolbin/color/icc_creator/effects/cyan_output.icc
> toolbin/color/icc_creator/effects/k_only.txt
> toolbin/color/icc_creator/effects/m_only.txt
> toolbin/color/icc_creator/effects/magenta_output.icc
> toolbin/color/icc_creator/effects/y_only.txt
> toolbin/color/icc_creator/effects/yellow_output.icc
> toolbin/color/icc_creator/example/artifex_blue_purple.icc
> toolbin/color/icc_creator/example/artifex_tritone.icc
> toolbin/color/icc_creator/example/cielab_values.txt
> toolbin/color/icc_creator/example/color_names.txt
> toolbin/color/icc_creator/example/duotone.pdf
> toolbin/color/icc_creator/example/tritone.pdf
> toolbin/color/icc_creator/example/tritone_cielab.txt
> toolbin/color/icc_creator/example/tritone_names.txt
> toolbin/color/icc_creator/ucr_bg.txt
> toolbin/color/named_color/named_color_table.txt
> toolbin/color/named_color/named_colors.pdf
> toolbin/color/src_color/cmyk_des_renderintent.icc
> toolbin/color/src_color/cmyk_src_cyan.icc
> toolbin/color/src_color/cmyk_src_magenta.icc
> toolbin/color/src_color/cmyk_src_renderintent.icc
> toolbin/color/src_color/cmyk_src_yellow.icc
> toolbin/color/src_color/objsrc_profiles_example.txt
> toolbin/color/src_color/rgb_source_blue.icc
> toolbin/color/src_color/rgb_source_green.icc
> toolbin/color/src_color/rgb_source_red.icc
> toolbin/drawafm.ps
> toolbin/encs2c.ps
> toolbin/errlist.tcl
> toolbin/extractFonts.ps
> toolbin/extractICCprofiles.ps
> toolbin/gen_ldf_jb2.py
> toolbin/genfontmap.ps
> toolbin/gitlog2changelog.py
> toolbin/gitsetup.sh
> toolbin/gsmake
> toolbin/gsmake.tcl
> toolbin/halftone/ETS/README.txt
> toolbin/halftone/ETS/ei03.pdf
> toolbin/halftone/ETS/ets.c
> toolbin/halftone/ETS/ets.h
> toolbin/halftone/ETS/ipview.html
> toolbin/halftone/ETS/test_ets.c
> toolbin/halftone/ETS/tm.h
> toolbin/halftone/ETS/win32/ETS.sln
> toolbin/halftone/ETS/win32/ETS.vcproj
> toolbin/halftone/gen_ordered/README
> toolbin/halftone/gen_ordered/gen_ordered.c
> toolbin/halftone/gen_ordered/gen_ordered.sln
> toolbin/halftone/gen_ordered/gen_ordered.vcproj
> toolbin/halftone/gen_stochastic/gen_stochastic.c
> toolbin/halftone/gen_stochastic/gen_stochastic.sln
> toolbin/halftone/gen_stochastic/gen_stochastic.vcproj
> toolbin/headers.tcl
> toolbin/htmldiff.pl
> toolbin/jpxtopdf.c
> toolbin/leaks.tcl
> toolbin/localcluster/clusterpush.pl
> toolbin/localcluster/clusterpush.txt
> toolbin/localcluster/gitpush.sh
> toolbin/localcluster/readme
> toolbin/makehist.tcl
> toolbin/memory.py
> toolbin/ocheck.py
> toolbin/pdf_info.ps
> toolbin/pdfinflt.ps
> toolbin/performance.pl
> toolbin/pre.chk
> toolbin/pre.tcl
> toolbin/precheck.tcl
> toolbin/pscet_status.pl
> toolbin/search-svn-revs
> toolbin/search/README
> toolbin/smoke.ps
> toolbin/split_changelog.py
> toolbin/squeeze2html.pl
> toolbin/suite.tcl
> toolbin/tests/README
> toolbin/tests/build_revision.py
> toolbin/tests/check_all.py
> toolbin/tests/check_comments.py
> toolbin/tests/check_dirs.py
> toolbin/tests/check_docrefs.py
> toolbin/tests/check_source.py
> toolbin/tests/cmpi.py
> toolbin/tests/collate.py
> toolbin/tests/compare_checksumdb.py
> toolbin/tests/compare_checksums.py
> toolbin/tests/dump_checksum.py
> toolbin/tests/dump_checksum_plus.py
> toolbin/tests/dump_checksum_raw.py
> toolbin/tests/find_unique_file.py
> toolbin/tests/fuzzy.c
> toolbin/tests/get_baseline_log.py
> toolbin/tests/get_baselines.py
> toolbin/tests/gscheck_all.py
> toolbin/tests/gscheck_fuzzypdf.py
> toolbin/tests/gscheck_pdfwrite.py
> toolbin/tests/gscheck_raster.py
> toolbin/tests/gscheck_testfiles.py
> toolbin/tests/gsconf.py
> toolbin/tests/gsparamsets.py
> toolbin/tests/gssum.py
> toolbin/tests/gstestgs.py
> toolbin/tests/gstestutils.py
> toolbin/tests/gsutil.py
> toolbin/tests/gsvalidate.py
> toolbin/tests/main.py
> toolbin/tests/make_baselinedb.py
> toolbin/tests/make_testdb.py
> toolbin/tests/make_two_pdfversions
> toolbin/tests/make_two_versions
> toolbin/tests/myoptparse.py
> toolbin/tests/rasterdb.py
> toolbin/tests/regen_baseline.py
> toolbin/tests/regen_filelist.py
> toolbin/tests/revert_baseline
> toolbin/tests/revert_pdfbaseline
> toolbin/tests/run_nightly
> toolbin/tests/run_nightly.py
> toolbin/tests/run_parallel
> toolbin/tests/run_regression.py
> toolbin/tests/run_series.py
> toolbin/tests/testdiff.py
> toolbin/tests/testing.cfg.example
> toolbin/tests/update_baseline.py
> toolbin/tests/update_specific
> toolbin/tests/updatelist.py
> toolbin/tests/updatelistpdf.py
> toolbin/tests/validate.py
> toolbin/tmake.tcl
> toolbin/vg_bugs.supp
> toolbin/vg_okay.supp
> tools/Acrobat2Tiff/Acrobat2Tiff.sln
> tools/Acrobat2Tiff/Acrobat2Tiff/Acrobat2Tiff.vb
> tools/Acrobat2Tiff/Acrobat2Tiff/Acrobat2Tiff.vbproj
> tools/Acrobat2Tiff/Acrobat2Tiff/Acrobat2Tiff/Application.Designer.vb
> tools/Acrobat2Tiff/Acrobat2Tiff/Acrobat2Tiff/Application.myapp
> tools/Acrobat2Tiff/Acrobat2Tiff/Acrobat2Tiff/AssemblyInfo.vb
> tools/Acrobat2Tiff/Acrobat2Tiff/Acrobat2Tiff/Resources.Designer.vb
> tools/Acrobat2Tiff/Acrobat2Tiff/Acrobat2Tiff/Resources.resx
> tools/Acrobat2Tiff/Acrobat2Tiff/Acrobat2Tiff/Settings.Designer.vb
> tools/Acrobat2Tiff/Acrobat2Tiff/Acrobat2Tiff/Settings.settings
> tools/Acrobat2Tiff/Acrobat2Tiff/bin/Release/Acrobat2Tiff.exe
> tools/Acrobat2Tiff/Acrobat2Tiff/bin/Release/Acrobat2Tiff.vshost.exe
> tools/Acrobat2Tiff/Acrobat2Tiff/bin/Release/Acrobat2Tiff.xml
> tools/Acrobat2Tiff/Acrobat2Tiff/bin/Release/Interop.Acrobat.dll
> tools/GOT/README
> tools/GOT/detag.c
> tools/GOT/dotags.sh
> tools/GOT/tagimage.c
> tools/bitfont.pcl
> tools/bitfonts.pxl
> tools/cat_url.py
> tools/check_deps.py
> tools/cmpi/Makefile
> tools/cmpi/Makefile.in
> tools/cmpi/README
> tools/cmpi/cmpi.bkl
> tools/cmpi/cmpi.cpp
> tools/cmpi/cmpi.dsp
> tools/cmpi/cmpi.dsw
> tools/cmpi/cmpi.pro
> tools/cmpi/cmpi.rc
> tools/cmpi/cmpi.sln
> tools/cmpi/cmpi.suo
> tools/cmpi/cmpi.vcp
> tools/cmpi/cmpi.vcproj
> tools/cmpi/cmpi.vcw
> tools/cmpi/descrip.mms
> tools/cmpi/makefile.bcc
> tools/cmpi/makefile.dmc
> tools/cmpi/makefile.dms
> tools/cmpi/makefile.dos
> tools/cmpi/makefile.gcc
> tools/cmpi/makefile.sc
> tools/cmpi/makefile.unx
> tools/cmpi/makefile.va
> tools/cmpi/makefile.vc
> tools/cmpi/makefile.wat
> tools/colorcirc.xps
> tools/docov.pl
> tools/fills.pcl
> tools/fontpage.pcl
> tools/fonts.pcl
> tools/fonts.pxl
> tools/frs96.pxl
> tools/gl-chars.pcl
> tools/gl2_chars.pl
> tools/grashopp.pcl
> tools/grid.pcl
> tools/label.tst
> tools/lineprinter.pcl
> tools/make_snapshot.sh
> tools/makeromttf.py
> tools/null.pxl
> tools/opaque.pcl
> tools/origins.pcl
> tools/owl.pcl
> tools/owl2.pcl
> tools/pattern.pcl
> tools/pattern.pxl
> tools/pcl2pdf
> tools/pcl2pdf.bat
> tools/pcl2pdfwr
> tools/pcl2pdfwr.bat
> tools/plot2pdf.sh
> tools/pxlasm.py
> tools/pxldis.py
> tools/regress.sh
> tools/revlist.py
> tools/smoke_baseline.txt
> tools/smoke_check.sh
> tools/smoke_update.sh
> tools/suite.tcl
> tools/tiger.px3
> tools/tiger.svg
> tools/tiger.xps
> tools/tt2pcl.c
> tools/vasarely.px3
> tools/xps2tiff/README
> tools/xps2tiff/xps2tiff.sln
> tools/xps2tiff/xps2tiff/AssemblyInfo.cpp
> tools/xps2tiff/xps2tiff/stdafx.cpp
> tools/xps2tiff/xps2tiff/stdafx.h
> tools/xps2tiff/xps2tiff/xps2tiff.cpp
> tools/xps2tiff/xps2tiff/xps2tiff.vcproj
> urwfonts/A028-Ext.ttf
> urwfonts/A028-Med.ttf
> urwfonts/A030-Bol.ttf
> urwfonts/A030-BolIta.ttf
> urwfonts/A030-Ita.ttf
> urwfonts/A030-Reg.ttf
> urwfonts/AntiqueOlive-Bol.ttf
> urwfonts/AntiqueOlive-Ita.ttf
> urwfonts/AntiqueOlive-Reg.ttf
> urwfonts/ArtLinePrinter.ttf
> urwfonts/CenturySchL-Bold.ttf
> urwfonts/CenturySchL-BoldItal.ttf
> urwfonts/CenturySchL-Ital.ttf
> urwfonts/CenturySchL-Roma.ttf
> urwfonts/ClarendonURW-BolCon.ttf
> urwfonts/Coronet.ttf
> urwfonts/Dingbats.ttf
> urwfonts/GaramondNo8-Ita.ttf
> urwfonts/GaramondNo8-Med.ttf
> urwfonts/GaramondNo8-MedIta.ttf
> urwfonts/GaramondNo8-Reg.ttf
> urwfonts/LetterGothic-Bol.ttf
> urwfonts/LetterGothic-Ita.ttf
> urwfonts/LetterGothic-Reg.ttf
> urwfonts/Mauritius-Reg.ttf
> urwfonts/NewDingbats.ttf
> urwfonts/NimbusMonL-Bold.ttf
> urwfonts/NimbusMonL-BoldObli.ttf
> urwfonts/NimbusMonL-Regu.ttf
> urwfonts/NimbusMonL-ReguObli.ttf
> urwfonts/NimbusMono-Bol.ttf
> urwfonts/NimbusMono-BolIta.ttf
> urwfonts/NimbusMono-Ita.ttf
> urwfonts/NimbusMono-Reg.ttf
> urwfonts/NimbusRomNo9L-Medi.ttf
> urwfonts/NimbusRomNo9L-MediItal.ttf
> urwfonts/NimbusRomNo9L-Regu.ttf
> urwfonts/NimbusRomNo9L-ReguItal.ttf
> urwfonts/NimbusRomanNo4-Bol.ttf
> urwfonts/NimbusRomanNo4-BolIta.ttf
> urwfonts/NimbusRomanNo4-Lig.ttf
> urwfonts/NimbusRomanNo4-LigIta.ttf
> urwfonts/NimbusRomanNo9-Ita.ttf
> urwfonts/NimbusRomanNo9-Med.ttf
> urwfonts/NimbusRomanNo9-MedIta.ttf
> urwfonts/NimbusRomanNo9-Reg.ttf
> urwfonts/NimbusSanL-Bold.ttf
> urwfonts/NimbusSanL-BoldCond.ttf
> urwfonts/NimbusSanL-BoldCondItal.ttf
> urwfonts/NimbusSanL-BoldItal.ttf
> urwfonts/NimbusSanL-Regu.ttf
> urwfonts/NimbusSanL-ReguCond.ttf
> urwfonts/NimbusSanL-ReguCondItal.ttf
> urwfonts/NimbusSanL-ReguItal.ttf
> urwfonts/StandardSymL.ttf
> urwfonts/U001-Bol.ttf
> urwfonts/U001-BolIta.ttf
> urwfonts/U001-Ita.ttf
> urwfonts/U001-Reg.ttf
> urwfonts/U001Con-Bol.ttf
> urwfonts/U001Con-BolIta.ttf
> urwfonts/U001Con-Ita.ttf
> urwfonts/U001Con-Reg.ttf
> urwfonts/URWBookmanL-DemiBold.ttf
> urwfonts/URWBookmanL-DemiBoldItal.ttf
> urwfonts/URWBookmanL-Ligh.ttf
> urwfonts/URWBookmanL-LighItal.ttf
> urwfonts/URWChanceryL-MediItal.ttf
> urwfonts/URWClassico-Bol.ttf
> urwfonts/URWClassico-BolIta.ttf
> urwfonts/URWClassico-Ita.ttf
> urwfonts/URWClassico-Reg.ttf
> urwfonts/URWGothicL-Book.ttf
> urwfonts/URWGothicL-BookObli.ttf
> urwfonts/URWGothicL-Demi.ttf
> urwfonts/URWGothicL-DemiObli.ttf
> urwfonts/URWPalladioL-Bold.ttf
> urwfonts/URWPalladioL-BoldItal.ttf
> urwfonts/URWPalladioL-Ital.ttf
> urwfonts/URWPalladioL-Roma.ttf
> win32/GhostPDL.sln
> win32/ReadMe.txt
> win32/language_switch.vcproj
> win32/pcl.vcproj
> win32/xps.vcproj
> winrt/GhostPDL.sln
> xcode/GhostPDL/GhostPDL.xcodeproj/project.pbxproj
> xcode/GhostPDL/GhostPDL.xcodeproj/project.xcworkspace/contents.xcworkspacedata
> xcode/GhostPDL/GhostPDL.xcodeproj/xcshareddata/xcschemes/GhostPDL.xcscheme
> xcode/GhostPDL/GhostPDL.xcodeproj/xcshareddata/xcschemes/ghostscript.xcscheme
> xcode/GhostPDL/GhostPDL.xcodeproj/xcshareddata/xcschemes/language_switch.xcscheme
> xcode/GhostPDL/GhostPDL.xcodeproj/xcshareddata/xcschemes/pcl.xcscheme
> xcode/GhostPDL/GhostPDL.xcodeproj/xcshareddata/xcschemes/svg.xcscheme
> xcode/GhostPDL/GhostPDL.xcodeproj/xcshareddata/xcschemes/xps.xcscheme
> xcode/Makefile
> xcode/clang_wrapper.c
> xcode/clang_wrapper.sh
> xcode/resolve.sh
> xps/tools/colorcirc.xps
> xps/tools/tiger.xps
> xps/tools/xps2tiff/README
> xps/tools/xps2tiff/xps2tiff.sln
> xps/tools/xps2tiff/xps2tiff/AssemblyInfo.cpp
> xps/tools/xps2tiff/xps2tiff/stdafx.cpp
> xps/tools/xps2tiff/xps2tiff/stdafx.h
> xps/tools/xps2tiff/xps2tiff/xps2tiff.cpp
> xps/tools/xps2tiff/xps2tiff/xps2tiff.vcproj
> xps/xps.mak
> xps/xpsromfs.mak
> zlib/CMakeLists.txt
> zlib/ChangeLog
> zlib/FAQ
> zlib/INDEX
> zlib/Makefile
> zlib/Makefile.in
> zlib/README
> zlib/adler32.c
> zlib/amiga/Makefile.pup
> zlib/amiga/Makefile.sas
> zlib/as400/bndsrc
> zlib/as400/compile.clp
> zlib/as400/readme.txt
> zlib/as400/zlib.inc
> zlib/compress.c
> zlib/configure
> zlib/contrib/README.contrib
> zlib/contrib/ada/buffer_demo.adb
> zlib/contrib/ada/mtest.adb
> zlib/contrib/ada/read.adb
> zlib/contrib/ada/readme.txt
> zlib/contrib/ada/test.adb
> zlib/contrib/ada/zlib-streams.adb
> zlib/contrib/ada/zlib-streams.ads
> zlib/contrib/ada/zlib-thin.adb
> zlib/contrib/ada/zlib-thin.ads
> zlib/contrib/ada/zlib.adb
> zlib/contrib/ada/zlib.ads
> zlib/contrib/ada/zlib.gpr
> zlib/contrib/amd64/amd64-match.S
> zlib/contrib/asm686/README.686
> zlib/contrib/asm686/match.S
> zlib/contrib/blast/Makefile
> zlib/contrib/blast/README
> zlib/contrib/blast/blast.c
> zlib/contrib/blast/blast.h
> zlib/contrib/blast/test.pk
> zlib/contrib/blast/test.txt
> zlib/contrib/delphi/ZLib.pas
> zlib/contrib/delphi/ZLibConst.pas
> zlib/contrib/delphi/readme.txt
> zlib/contrib/delphi/zlibd32.mak
> zlib/contrib/dotzlib/DotZLib.build
> zlib/contrib/dotzlib/DotZLib.chm
> zlib/contrib/dotzlib/DotZLib.sln
> zlib/contrib/dotzlib/DotZLib/AssemblyInfo.cs
> zlib/contrib/dotzlib/DotZLib/ChecksumImpl.cs
> zlib/contrib/dotzlib/DotZLib/CircularBuffer.cs
> zlib/contrib/dotzlib/DotZLib/CodecBase.cs
> zlib/contrib/dotzlib/DotZLib/Deflater.cs
> zlib/contrib/dotzlib/DotZLib/DotZLib.cs
> zlib/contrib/dotzlib/DotZLib/DotZLib.csproj
> zlib/contrib/dotzlib/DotZLib/GZipStream.cs
> zlib/contrib/dotzlib/DotZLib/Inflater.cs
> zlib/contrib/dotzlib/DotZLib/UnitTests.cs
> zlib/contrib/dotzlib/LICENSE_1_0.txt
> zlib/contrib/dotzlib/readme.txt
> zlib/contrib/gcc_gvmat64/gvmat64.S
> zlib/contrib/infback9/README
> zlib/contrib/infback9/infback9.c
> zlib/contrib/infback9/infback9.h
> zlib/contrib/infback9/inffix9.h
> zlib/contrib/infback9/inflate9.h
> zlib/contrib/infback9/inftree9.c
> zlib/contrib/infback9/inftree9.h
> zlib/contrib/inflate86/inffas86.c
> zlib/contrib/inflate86/inffast.S
> zlib/contrib/iostream/test.cpp
> zlib/contrib/iostream/zfstream.cpp
> zlib/contrib/iostream/zfstream.h
> zlib/contrib/iostream2/zstream.h
> zlib/contrib/iostream2/zstream_test.cpp
> zlib/contrib/iostream3/README
> zlib/contrib/iostream3/TODO
> zlib/contrib/iostream3/test.cc
> zlib/contrib/iostream3/zfstream.cc
> zlib/contrib/iostream3/zfstream.h
> zlib/contrib/masmx64/bld_ml64.bat
> zlib/contrib/masmx64/gvmat64.asm
> zlib/contrib/masmx64/inffas8664.c
> zlib/contrib/masmx64/inffasx64.asm
> zlib/contrib/masmx64/readme.txt
> zlib/contrib/masmx86/bld_ml32.bat
> zlib/contrib/masmx86/inffas32.asm
> zlib/contrib/masmx86/match686.asm
> zlib/contrib/masmx86/readme.txt
> zlib/contrib/minizip/Makefile
> zlib/contrib/minizip/Makefile.am
> zlib/contrib/minizip/MiniZip64_Changes.txt
> zlib/contrib/minizip/MiniZip64_info.txt
> zlib/contrib/minizip/configure.ac
> zlib/contrib/minizip/crypt.h
> zlib/contrib/minizip/ioapi.c
> zlib/contrib/minizip/ioapi.h
> zlib/contrib/minizip/iowin32.c
> zlib/contrib/minizip/iowin32.h
> zlib/contrib/minizip/make_vms.com
> zlib/contrib/minizip/miniunz.c
> zlib/contrib/minizip/miniunzip.1
> zlib/contrib/minizip/minizip.1
> zlib/contrib/minizip/minizip.c
> zlib/contrib/minizip/minizip.pc.in
> zlib/contrib/minizip/mztools.c
> zlib/contrib/minizip/mztools.h
> zlib/contrib/minizip/unzip.c
> zlib/contrib/minizip/unzip.h
> zlib/contrib/minizip/zip.c
> zlib/contrib/minizip/zip.h
> zlib/contrib/pascal/example.pas
> zlib/contrib/pascal/readme.txt
> zlib/contrib/pascal/zlibd32.mak
> zlib/contrib/pascal/zlibpas.pas
> zlib/contrib/puff/Makefile
> zlib/contrib/puff/README
> zlib/contrib/puff/puff.c
> zlib/contrib/puff/puff.h
> zlib/contrib/puff/pufftest.c
> zlib/contrib/puff/zeros.raw
> zlib/contrib/testzlib/testzlib.c
> zlib/contrib/testzlib/testzlib.txt
> zlib/contrib/untgz/Makefile
> zlib/contrib/untgz/Makefile.msc
> zlib/contrib/untgz/untgz.c
> zlib/contrib/vstudio/readme.txt
> zlib/contrib/vstudio/vc10/miniunz.vcxproj
> zlib/contrib/vstudio/vc10/miniunz.vcxproj.filters
> zlib/contrib/vstudio/vc10/minizip.vcxproj
> zlib/contrib/vstudio/vc10/minizip.vcxproj.filters
> zlib/contrib/vstudio/vc10/testzlib.vcxproj
> zlib/contrib/vstudio/vc10/testzlib.vcxproj.filters
> zlib/contrib/vstudio/vc10/testzlibdll.vcxproj
> zlib/contrib/vstudio/vc10/testzlibdll.vcxproj.filters
> zlib/contrib/vstudio/vc10/zlib.rc
> zlib/contrib/vstudio/vc10/zlibstat.vcxproj
> zlib/contrib/vstudio/vc10/zlibstat.vcxproj.filters
> zlib/contrib/vstudio/vc10/zlibvc.def
> zlib/contrib/vstudio/vc10/zlibvc.sln
> zlib/contrib/vstudio/vc10/zlibvc.vcxproj
> zlib/contrib/vstudio/vc10/zlibvc.vcxproj.filters
> zlib/contrib/vstudio/vc11/miniunz.vcxproj
> zlib/contrib/vstudio/vc11/minizip.vcxproj
> zlib/contrib/vstudio/vc11/testzlib.vcxproj
> zlib/contrib/vstudio/vc11/testzlibdll.vcxproj
> zlib/contrib/vstudio/vc11/zlib.rc
> zlib/contrib/vstudio/vc11/zlibstat.vcxproj
> zlib/contrib/vstudio/vc11/zlibvc.def
> zlib/contrib/vstudio/vc11/zlibvc.sln
> zlib/contrib/vstudio/vc11/zlibvc.vcxproj
> zlib/contrib/vstudio/vc9/miniunz.vcproj
> zlib/contrib/vstudio/vc9/minizip.vcproj
> zlib/contrib/vstudio/vc9/testzlib.vcproj
> zlib/contrib/vstudio/vc9/testzlibdll.vcproj
> zlib/contrib/vstudio/vc9/zlib.rc
> zlib/contrib/vstudio/vc9/zlibstat.vcproj
> zlib/contrib/vstudio/vc9/zlibvc.def
> zlib/contrib/vstudio/vc9/zlibvc.sln
> zlib/contrib/vstudio/vc9/zlibvc.vcproj
> zlib/crc32.c
> zlib/crc32.h
> zlib/deflate.c
> zlib/deflate.h
> zlib/doc/algorithm.txt
> zlib/doc/rfc1950.txt
> zlib/doc/rfc1951.txt
> zlib/doc/rfc1952.txt
> zlib/doc/txtvsbin.txt
> zlib/examples/README.examples
> zlib/examples/enough.c
> zlib/examples/fitblk.c
> zlib/examples/gun.c
> zlib/examples/gzappend.c
> zlib/examples/gzjoin.c
> zlib/examples/gzlog.c
> zlib/examples/gzlog.h
> zlib/examples/zlib_how.html
> zlib/examples/zpipe.c
> zlib/examples/zran.c
> zlib/gzclose.c
> zlib/gzguts.h
> zlib/gzlib.c
> zlib/gzread.c
> zlib/gzwrite.c
> zlib/infback.c
> zlib/inffast.c
> zlib/inffast.h
> zlib/inffixed.h
> zlib/inflate.c
> zlib/inflate.h
> zlib/inftrees.c
> zlib/inftrees.h
> zlib/make_vms.com
> zlib/msdos/Makefile.bor
> zlib/msdos/Makefile.dj2
> zlib/msdos/Makefile.emx
> zlib/msdos/Makefile.msc
> zlib/msdos/Makefile.tc
> zlib/nintendods/Makefile
> zlib/nintendods/README
> zlib/old/Makefile.emx
> zlib/old/Makefile.riscos
> zlib/old/README
> zlib/old/descrip.mms
> zlib/old/os2/Makefile.os2
> zlib/old/os2/zlib.def
> zlib/old/visual-basic.txt
> zlib/qnx/package.qpg
> zlib/test/example.c
> zlib/test/infcover.c
> zlib/test/minigzip.c
> zlib/treebuild.xml
> zlib/trees.c
> zlib/trees.h
> zlib/uncompr.c
> zlib/watcom/watcom_f.mak
> zlib/watcom/watcom_l.mak
> zlib/win32/DLL_FAQ.txt
> zlib/win32/Makefile.bor
> zlib/win32/Makefile.gcc
> zlib/win32/Makefile.msc
> zlib/win32/README-WIN32.txt
> zlib/win32/VisualC.txt
> zlib/win32/zlib.def
> zlib/win32/zlib1.rc
> zlib/zconf.h
> zlib/zconf.h.cmakein
> zlib/zconf.h.in
> zlib/zlib.3
> zlib/zlib.3.pdf
> zlib/zlib.h
> zlib/zlib.map
> zlib/zlib.pc.cmakein
> zlib/zlib.pc.in
> zlib/zlib2ansi
> zlib/zutil.c
> zlib/zutil.h

2015-07-19 22:51:01 -0700
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
7fd9e0be26e67c36f87733bc89ea07dc26d9f839

> Modify clusterpush.pl to handle build_consolidation directory structure.
> gs/toolbin/localcluster/clusterpush.pl

2015-07-15 16:10:30 +0100
Ken Sharp <ken.sharp@artifex.com>
f374cec0a68ad63707f398967f1a9fb38163fdae

> pdfwrite - More fiddling with symbolic TrueType fonts
> Bug #695969 "Regression: Missing umlauts starting with 28b7d3c75adb8e942f2158bdec445a147f945530"
> The problem here is the way that Acrobat behaves with symbolic fonts. If we define
> a font as 'symbolic', then we don't write an Encoding (its not permitted
> with PDF/A, and is technically invalid), and Acrobat uses the font's 1,0
> CMAP subtable.
> If we do not write the font as symbolic then we need to write an Encoding. In
> this case it seems that Acrobat uses the embedded font's 3,1 CMAP subtable.
> The problem is that the two tables need not be consistent, and in the case
> of this file, are not. The character code 77 maps to GID 48 in both cases
> but the character code 252 maps to GID 129 (a composite glyph) with the 3,1
> CMAP and to a /.notdef with the 1,0 CMAP.
> This is only a problem if we *don't* subset the font, because if we subset the
> font we *generate* a set of CMAP subtables, and we generate tables which
> are consistent with each other.
> I did consider forcing the CMAP tables to be generated, even when not subsetting
> the font, but this font contains more than 255 glyphs, so we can't fit them
> all into a 1,0 CMAP anyway, so which ones should we use ?
> So instead, if we have a TrueType font, are embedding it, are *not* subsetting it
> *and* the original font was 'not symbolic', (which we test by looking for the
> presence of a 'nearest_encoding_index' in the original font as this is set
> from the is_symbolic flag in the PDF interpreter, which is set from the
> original font descriptor Flags value), then we do *NOT* mark the font as
> symbolic.
> This also means altering the check against creating an Encoding, if we are
> (eventually) going to make the font non-symbolic, then we need to add an
> Encoding to it as well.
> This causes a difference in one cluster test, this is due to the fact that
> the font can't be embedded due to licencing restrictions. Because of this
> the output was already incorrect, its now incorrect in a slightly different
> way.
> gs/devices/vector/gdevpdtd.c
> gs/devices/vector/gdevpdtt.c

2015-07-13 16:03:38 +0100
Ken Sharp <ken.sharp@artifex.com>
962c6299e5fe72120eba0f966cbd0430105d8b49

> Update TrueType font copying code to handle OpenType 1.7 OS/2 tables
> Bug #696049 "Postscript can not konverted to PDF"
> The embedded TrueType font conforms to version 1.7 of the OpenType specifiction
> which introduces 2 new variables to the OS/2 table. This makes the OS/2 table
> length too great for the sanity checks in the code and it abrots with an error.
> This commit extends the checking to cater for version 1.7 OpenType OS/2
> tables, and removes an unused variable at the same time.
> No differences expected.
> gs/base/gxttf.h
> gs/devices/vector/gdevpsft.c

2015-07-13 10:08:41 +0100
Ken Sharp <ken.sharp@artifex.com>
7a18e49ebfbc225a3f1e8562571a2fc70fb61c48

> PDF interpreter - check type of XObject resoruces when scanning for transparency
> Bug #696083 "Error reading PDF file"
> The PDF file has a single page, but the /Pages dictionary has a Resources
> dictionary (which is consulted if any page is missing a resource definition)
> The Page is complete, but when scanning for the presence of transparency
> (to improve performance) we test any 'Parent' resources as well, and in this
> case the Pages dictionary contains an XObject resource which is incorrect.
> Instead of a dictoinary, its an integer, and since that's the wrong type we
> throw an error.
> This commit checks the type of XObject resources during scanning for transparency
> and ignores (with a warning) any which have an incorrect type.
> No differences expected.
> gs/Resource/Init/pdf_main.ps

2015-06-02 11:07:45 +0100
Ken Sharp <ken.sharp@artifex.com>
aa48df9c6d4af5e611e8b641d8c544885f59b2ac

> graphics library and interpreter changes to allow us to subclass the
> pattern accumulator device.
> The main change is to pass a structure to the
> device_spec_op which handle patterns. This structure carries the graphcs
> state, which we require. This has required altering pdfwrite (the only
> device currently implementing these spec_ops) and all the interpreters in
> order to pass the required information.
> An additional change places the GC structure descriptor for the pattern
> accumulator device in the device structure's 'stype' instead of leaving it
> NULL. We can't subclass devices with a NULL stype.
> gs/base/gsptype1.c
> gs/base/gxdevsop.h
> gs/base/gxpcmap.c
> gs/devices/vector/gdevpdfd.c
> gs/devices/vector/gdevpdfi.c
> gs/psi/zpcolor.c
> pxl/pxink.c
> xps/xpstile.c

2015-07-10 14:38:15 +0100
Chris Liddell <chris.liddell@artifex.com>
a3598cd629a959c189a9b2195640c3d5bdf8490d

> Makefile: Add ZI_ macro for zlib include
> For files that only need zlib (and not, for example libpng nor libtiff), add a
> makefile macro just for the zlib include path, and tweak to use it where
> appropriate (gdevfpng.c doesn't use libpng but does use zlib).
> No cluster differences
> gs/base/gs.mak
> gs/devices/devs.mak

2015-07-10 14:48:51 +0100
Ken Sharp <ken.sharp@artifex.com>
5a3bcaf5439ce0f911297d8e2a5699cd4cd983f3

> Initialise a variable to silence scan-build (it can't actually be used uninitialised)
> gs/base/gdevdflt.c

2015-07-10 14:39:14 +0100
Ken Sharp <ken.sharp@artifex.com>
326a116687ee35db6d1bdcc54f2a8b2fb4458878

> PDF interpreter - alter rebuilding of xref when problems are detected
> Bug #696084 "Page rendered blank"
> The file is pretty classically broken. It starts with an entry in the xref
> for object 290 which is not flagged as 'free'. However, when we check the
> file at the given offset it actually points to object 228.
> This triggers us to rescan the file, because the xref is broken. So we sweep
> the file from beginning to end looking for the sequence 'x y obj'. NB we
> don't (can't) do this for object streams, because those are compressed.
> When we find an object definition we enter it into the rebuilt xref table.
> However, this file contains duplicate definitions for all the page objects
> which leads us to emit a warning that there are multiple definitions and the
> output may be incorrect. The rebuilding code uses the *last* definition of
> a given object and the highest generation number, because in general when
> there are multiple definitions of the same object, the last one is the one
> that's correct (PDF tools usually modify the file by appending rather than
> writing into the middle of the file).
> However, in this case, the *first* definition is the correct one. Not only
> that but the second definitions aren't even valid.....
> So the problem is caused by; a broken xref table, multiple definitions of
> the same object, and the later definitions being invalid.
> I've worked around this by checking the *original* xref table and if one of
> the definitions is at the same offset as defined in the original xref we now
> always prefer that definition, otherwise we prefer the last definition, as
> before.
> No differences expected.
> gs/Resource/Init/pdf_rbld.ps

2015-07-10 09:00:16 +0100
Ken Sharp <ken.sharp@artifex.com>
4dbd8ee3ffa0c0f18fe43acff3e859b61323844b

> Coverity IDs 101838 and 101840
> gs/base/gdevsclass.c

2015-07-10 08:44:52 +0100
Ken Sharp <ken.sharp@artifex.com>
202bd93e65d5f30070de06f4dc449450e316ebad

> Coverity ID 101842, checking 'dev' and 'child' before dereferencing
> gs/base/gdevdflt.c

2015-07-10 08:30:00 +0100
Ken Sharp <ken.sharp@artifex.com>
e28d75a2f2b7828d1d6deb7667f545c7c73ace33

> Coverity IDs 101844, 101843, 101839
> I don't think that dev can be NULL here, but just for safety.
> gs/base/gdevmplt.c

2015-07-09 15:14:11 +0100
Ken Sharp <ken.sharp@artifex.com>
80653628e28a8520a48b0ca3bb9cd0e1a1874001

> Move variable to procedure header, from body
> This caused PCL not to build on VS and (at least sometimes) on Linuc but
> oddly was not a problem on the cluster.
> pl/plmain.c

2015-07-09 15:13:13 +0100
Ken Sharp <ken.sharp@artifex.com>
f6214c2d6f8ed3aea4f4e7140899489ada5ccc46

> Fix a potential uninitialised variable spotted by scan-build
> pcl/pcpalet.c

2014-10-17 14:51:52 +0100
Ken Sharp <ken.sharp@artifex.com>
f98b0b84a7f7c1833550ee3938f60aef356840c3

> Addition of device 'subclassing'
> This is a new feature in the graphcs library which allows for a chain of
> devices to be created and for new devices to be created and added to that
> chain, even if the graphcs state is not available.
> The work for ths was originally performed on the 'device_subclassing'
> branch, and all the history is maikntained in that branch. This single
> commit embodies all the work, but none of the history.
> The background to the code is documented in ghostpdl/doc/subclass.htm.
> In addition to the graphics library support for this feature there are two
> new devices; the First Page/Last Page device and the Object Filtering
> device.
> gs/Resource/Init/gs_pdfwr.ps
> gs/Resource/Init/pdf_main.ps
> gs/base/gdevbbox.c
> gs/base/gdevdevn.c
> gs/base/gdevdflt.c
> gs/base/gdevdgbr.c
> gs/base/gdevflp.c
> gs/base/gdevflp.h
> gs/base/gdevkrnlsclass.c
> gs/base/gdevkrnlsclass.h
> gs/base/gdevmplt.c
> gs/base/gdevmplt.h
> gs/base/gdevnfwd.c
> gs/base/gdevoflt.c
> gs/base/gdevoflt.h
> gs/base/gdevp14.c
> gs/base/gdevprn.c
> gs/base/gdevsclass.c
> gs/base/gdevsclass.h
> gs/base/gdevvec.c
> gs/base/gscspace.c
> gs/base/gsdevice.c
> gs/base/gsdparam.c
> gs/base/gserrors.h
> gs/base/gsicc_manage.c
> gs/base/gsicc_replacecm.c
> gs/base/gsovrc.c
> gs/base/gspaint.c
> gs/base/gsstate.c
> gs/base/gxclbits.c
> gs/base/gxclist.c
> gs/base/gxclist.h
> gs/base/gxclpage.c
> gs/base/gxclrast.c
> gs/base/gxcmap.c
> gs/base/gxdcolor.c
> gs/base/gxdevcli.h
> gs/base/gxdevice.h
> gs/base/gxpcmap.c
> gs/base/lib.mak
> gs/contrib/opvp/gdevopvp.c
> gs/contrib/pcl3/eprn/gdeveprn.c
> gs/contrib/pcl3/src/gdevpcl3.c
> gs/devices/gdevbit.c
> gs/devices/gdevcdj.c
> gs/devices/gdevdsp.c
> gs/devices/gdevfpng.c
> gs/devices/gdevpbm.c
> gs/devices/gdevtfax.c
> gs/devices/gdevtifs.c
> gs/devices/gdevtsep.c
> gs/devices/gdevupd.c
> gs/devices/gdevwdib.c
> gs/devices/gdevwpr2.c
> gs/devices/gdevx.c
> gs/devices/vector/gdevpdf.c
> gs/devices/vector/gdevpdfb.h
> gs/devices/vector/gdevpdfc.c
> gs/devices/vector/gdevpdfc.h
> gs/devices/vector/gdevpdfi.c
> gs/devices/vector/gdevpdfk.c
> gs/devices/vector/gdevpdfo.c
> gs/devices/vector/gdevpdfo.h
> gs/devices/vector/gdevpdfp.c
> gs/devices/vector/gdevpdfu.c
> gs/devices/vector/gdevpdfv.c
> gs/devices/vector/gdevpdfx.h
> gs/devices/vector/gdevpdtd.c
> gs/devices/vector/gdevpdtt.c
> gs/devices/vector/gdevpsdu.c
> gs/devices/vector/gdevpx.c
> gs/devices/vector/gdevtxtw.c
> gs/devices/vector/gdevxps.c
> gs/doc/Use.htm
> gs/doc/subclass.htm
> gs/psi/zdevice2.c
> pcl/pcl.mak
> pcl/pcpalet.c
> pl/plmain.c
> psi/psitop.c

2015-07-07 16:57:41 +0100
Chris Liddell <chris.liddell@artifex.com>
0c0b0859ae1aba64861599f0e7f74f143f305932

> Bug 696041: sanity check for memory allocation.
> In gs_heap_alloc_bytes(), add a sanity check to ensure we don't overflow the
> variable holding the actual number of bytes we allocate.
> No cluster differences
> gs/base/gsmalloc.c

2015-07-05 17:56:30 -0700
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
9d53a5175c77ca789f099f3d77d4109f6a412cdd

> Document added lib and examples file to silence regression warnings.
> gs/doc/Develop.htm
> gs/doc/Psfiles.htm

2015-07-03 13:25:30 +0100
Chris Liddell <chris.liddell@artifex.com>
95c861c397536f4427297caf88935ef474466f8f

> Bug 695475: use gs_snprintf in font serializing
> Change to using gs_snprintf() (from gs_sprintf) in the Type 1 and 2 font
> serializing code, and if the number is truncated, print a warning (but carry
> on).
> No cluster differences
> gs/base/lib.mak
> gs/base/wrfont.c
> gs/base/wrfont.h
> gs/base/write_t1.c
> gs/base/write_t2.c

2015-07-02 15:57:30 +0100
Chris Liddell <chris.liddell@artifex.com>
d8c1bfb119b9a5d44d684227104c01bcdbcea0f5

> Remove last vestige of TurboC build
> gs/base/turboc.cfg

2015-06-30 08:58:40 +0100
Chris Liddell <chris.liddell@artifex.com>
65a4fa4d6fbd3ab04f565e051d6a7af8f65c0960

> Replace strtok()
> Add a portable, thread-safe equivalent of strtok() lifted from the Apache
> project a tweaked slightly for use in Ghostcript.
> Commit apache strtok source "as is"
> Rename apache strtok source file to suit GS
> Add header for gs_strtok()
> First pass at makefile changes for gs_strtok()
> Tweak apache strtok() code to work for Ghostscript
> Further makefile tweak for gs_strtok
> Missing semicolon
> Modify code to use gs_strtok() instead of strtok
> No cluster differences.
> gs/base/gsicc_cache.c
> gs/base/gsicc_manage.c
> gs/base/gsstrtok.c
> gs/base/gsstrtok.h
> gs/base/lib.mak
> gs/base/string_.h
> gs/devices/gdevwpr2.c
> gs/psi/dscparse.c
> pl/pjparse.c
> pl/pllfont.c
> pl/plmain.c

2015-06-29 12:05:28 +0100
Chris Liddell <chris.liddell@artifex.com>
b04c259dc71b3c7890e0c3771ee1b8f79519be1e

> Replace trio for sprintf
> Use code from the Apache project (under Apache License) tweaked to remove
> Apache specific dependencies and to better fit our formatting needs.
> Cluster differences only due to slight difference in at what point the exponent
> notation kicks in.
> Add Apache's sprintf implementation "as is"
> Rename Apache sprintf source.
> Tweak to work outside of Apache
> common/msvc_top.mak
> common/ugcc_top.mak
> config.mak.in
> configure.ac
> gs/Makefile.in
> gs/base/gs.mak
> gs/base/gssprintf.c
> gs/base/gssprintf.h
> gs/base/gxclmem.c
> gs/base/lib.mak
> gs/base/trio.mak
> gs/base/unix-gcc.mak
> gs/base/unixansi.mak
> gs/base/winlib.mak
> gs/configure.ac
> gs/psi/msvc.mak
> gs/trio/CHANGES
> gs/trio/FILES
> gs/trio/Makefile.in
> gs/trio/README
> gs/trio/autogen.sh
> gs/trio/compare.c
> gs/trio/configure.in
> gs/trio/doc/doc.h
> gs/trio/doc/doc_dynamic.h
> gs/trio/doc/doc_printf.h
> gs/trio/doc/doc_register.h
> gs/trio/doc/doc_scanf.h
> gs/trio/doc/doc_static.h
> gs/trio/doc/footer.html
> gs/trio/doc/header.html
> gs/trio/doc/trio.cfg
> gs/trio/doc/trio.css
> gs/trio/example.c
> gs/trio/html/group___dynamic_strings.html
> gs/trio/html/group___printf.html
> gs/trio/html/group___scanf.html
> gs/trio/html/group___special_quantities.html
> gs/trio/html/group___static_strings.html
> gs/trio/html/group___user_defined.html
> gs/trio/html/index.html
> gs/trio/html/modules.html
> gs/trio/html/trio.css
> gs/trio/install-sh
> gs/trio/maketgz
> gs/trio/regression.c
> gs/trio/strio.h
> gs/trio/trio.c
> gs/trio/trio.h
> gs/trio/triodef.h
> gs/trio/trionan.c
> gs/trio/trionan.h
> gs/trio/triop.h
> gs/trio/triostr.c
> gs/trio/triostr.h
> main/pcl6_gcc.mak
> main/pcl6_msvc.mak
> xps/xps_msvc.mak

2015-07-02 09:22:08 -0600
Henry Stiles <henry.stiles@artifex.com>
86beea017099fa94f210b8eaa028656c197ce676

> Support for Margins on the PCL command line.
> pl/plmain.c

2015-07-02 07:43:09 -0600
Henry Stiles <henry.stiles@artifex.com>
c802d7bca87d26fabbc090518e942b2424e1f269

> Margins resolution units were not correct for the X11 device.
> X11 initializes resolution and margin's resolution to "FAKE_RES" (1152)
> at compile time. Upon initialization if the resolution is still
> FAKE_RES indicating the resolution wasn't set on the command line or by
> parameter setting the code figures out a good resolution by querying X11
> screen dimensions. It forgot to set the Margin Resolution which
> remained at 1152 dpi.
> gs/devices/gdevxini.c

2015-07-02 07:40:11 -0600
Henry Stiles <henry.stiles@artifex.com>
04859e2ea30608d0ae8a4b844dac2f7ea36cbb82

> A little better documentation for "MarginsHWResolution".
> gs/base/gxdevcli.h

2015-06-30 07:28:35 -0600
Henry Stiles <henry.stiles@artifex.com>
8563e28b346f50cef8ee30dafba8a39b9af55e20

> Fix 696039 - Command line option doesn't allow "0" margins.
> A parsing error in scanf will not allow parsing floats in the format
> %fx%f if the float argument is 0, we now use strtok() to parse the
> floats in the format string.
> pl/plmain.c

2015-06-29 15:56:39 -0600
Henry Stiles <henry.stiles@artifex.com>
3f39e091c56a8abbe61124a728ab9382b246643b

> Fix lacking debug output for the label termination command.
> pcl/pgchar.c

2015-06-29 08:39:20 -0600
Henry Stiles <henry.stiles@artifex.com>
07859ace56b3410ac0af31ce1300505e7582d756

> Improve the readability of the built-in bitmap patterns. The change has
> no effect on program execution.
> pcl/pcbiptrn.c

2015-06-30 08:05:14 -0700
Ray Johnston <ray.johnston@artifex.com>
835ce7c78f3e396554dd2b965e41476e1bd72f8d

> Coverity ID #95048: Use of 'f' file pointer after freed by freopen.
> gs/base/gxclfile.c

2015-06-30 13:53:00 +0100
Ken Sharp <ken.sharp@artifex.com>
2d54c07d327f8d7b3eabc8a15c80127dc847e949

> XPS Interpreter - allow for empty remote resource dictionaries
> Bug #696061 "conversion of Test.xps fails with segment violation"
> If there was no remote resource dictionary, or it was empty, the code
> assigned XML data to the dictionary, which would cause a seg fault as the
> dictionary pointer was NULL.
> Simply check for a NULL dictionary pointer and if found, discard the
> 'xml' data instead of assigning it to the dictionary.
> A similar fix is already present in MuPDF.
> xps/xpsresource.c

2015-06-29 18:51:39 -0700
Ray Johnston <ray.johnston@artifex.com>
cf5a15bbc7b932ef4525962f770b1d6126383732

> Coverity ID #95083: Uninitialized variable 'code' used if color is not pure
> gs/base/gxcmap.c

2015-06-28 19:27:01 +0100
Ken Sharp <ken.sharp@artifex.com>
612f284f7cba5f3abf45b7f572af064cac0d005e

> PDF Interpreter - Don't attempt to draw annotations scaled to 0 size
> Bug #696051 "Warning only appears with -dTextAlphaBits=4"
> This commit does not address the underlying fault. The interpreter/graphics
> library behaves differently with TextAlphaBits set and not. This:
> /Helvetica findfont 20 scalefont setfont 10 10 moveto (test) show
> gives an error with -dTextAlphaBits set, but not when it isn't. The latter
> appears to be incorrect.
> We work around this in the PDF interpreter by checking the scale factor
> (because the actual fault is a /Rect [0 0 0 0]) and if either the x or y
> scale is 0, we simply don't draw the annotation.
> No differences expected.
> gs/Resource/Init/pdf_draw.ps

2015-06-23 15:36:29 +0100
Ken Sharp <ken.sharp@artifex.com>
7e8cd8ff35d36d66a7f5de50c16bcc0a4352777d

> Commit f5444527 inadvertently introduced seg faults, fixed here.
> gs/devices/vector/gdevpdtd.c

2015-06-23 12:37:29 +0100
Ken Sharp <ken.sharp@artifex.com>
d5287fe7585d7a203656244a72a15cb958cd798d

> Coverity ID #94512 copy paste error, x should have been y
> gs/devices/vector/gdevpdte.c

2015-06-23 12:14:06 +0100
Ken Sharp <ken.sharp@artifex.com>
f544452718283d4d7122b3c22c1f3991313099ea

> Coverity ID #94859 rearrange code to avoid potential NULL pointer dereference
> gs/devices/vector/gdevpdtd.c

2015-06-23 12:03:14 +0100
Ken Sharp <ken.sharp@artifex.com>
6b7de65620163f1a92ce42ef787a0ae4b07ecdef

> Coverity ID #94702 a missing ',' caused two standard CMap names to be concatenated, which means they were effectively both corrupted.
> gs/devices/vector/gdevpdtc.c

2015-06-23 11:44:00 +0100
Ken Sharp <ken.sharp@artifex.com>
83d2eb9128d94aa18fc4f9cc7d0b79e5d53976e5

> Coverity ID #94692 the variable 'code1' is pointlessly used to save a
> return code. This is no longer needed, so removed.
> gs/devices/vector/gdevpdtb.c

2015-06-23 11:29:39 +0100
Ken Sharp <ken.sharp@artifex.com>
3fd5c000705d844ae609945ae82260ccdff58896

> Coverity ID #94854, 94855, 94871, 94928 avoid potential array overrun
> by using '>=' instead of '>'. In practice this can't happen, because the
> enum value 'NUM_RESOURCe_TYPES' isn't used to create or address any actual
> resources.
> gs/devices/vector/gdevpdfu.c

2015-06-23 08:55:09 +0100
Ken Sharp <ken.sharp@artifex.com>
352a75aaba6804eab50b49e6c574365a83e37c47

> Coverity ID #94534 another two ignored returns from gp_fseek_64
> gs/devices/vector/gdevpdfu.c

2015-06-23 08:53:13 +0100
Ken Sharp <ken.sharp@artifex.com>
47485417cd9a734d5a7c9951eadcd8d5888ac34b

> Coverity ID #94521 fix two more cases of ignored return values from gp_fseek_64
> gs/devices/vector/gdevpdfu.c

2015-06-23 08:50:50 +0100
Ken Sharp <ken.sharp@artifex.com>
ebc78b1157d2393d5996425c1c2bd06b383db478

> Coverity ID #94509 check and action return value from gp_fessk_64
> gs/devices/vector/gdevpdfu.c

2015-06-23 08:47:45 +0100
Ken Sharp <ken.sharp@artifex.com>
867a7589bd1006ba9d1f0866e1ccf2fb87094c49

> Initialise variable to silence compiler warning
> gs/devices/vector/gdevpdfm.c

2015-06-14 10:22:12 +0100
Chris Liddell <chris.liddell@artifex.com>
d16982fb1078ecfe371f15df86c63f4649d70fdd

> Bug 696034: Add the correct updated font files
> I mistakenly committed the wrong font update (ones without the extra cyrillic
> and greek glyphs), this corrects the mistake.
> Cluster differences expected....
> gs/Resource/Font/NimbusMon-Bol
> gs/Resource/Font/NimbusMon-BolObl
> gs/Resource/Font/NimbusMon-Obl
> gs/Resource/Font/NimbusMon-Reg
> gs/Resource/Font/NimbusMono-Bold
> gs/Resource/Font/NimbusMono-BoldOblique
> gs/Resource/Font/NimbusMono-Oblique
> gs/Resource/Font/NimbusMono-Regular
> gs/Resource/Font/NimbusRom-Ita
> gs/Resource/Font/NimbusRom-Med
> gs/Resource/Font/NimbusRom-MedIta
> gs/Resource/Font/NimbusRom-Reg
> gs/Resource/Font/NimbusRomNo9L-Med
> gs/Resource/Font/NimbusRomNo9L-MedIta
> gs/Resource/Font/NimbusRomNo9L-Reg
> gs/Resource/Font/NimbusRomNo9L-RegIta
> gs/Resource/Font/NimbusSan-Bol
> gs/Resource/Font/NimbusSan-BolIta
> gs/Resource/Font/NimbusSan-Ita
> gs/Resource/Font/NimbusSan-Reg
> gs/Resource/Font/NimbusSanL-Bol
> gs/Resource/Font/NimbusSanL-BolIta
> gs/Resource/Font/NimbusSanL-Reg
> gs/Resource/Font/NimbusSanL-RegIta
> gs/Resource/Init/Fontmap.GS
> gs/psi/psromfs.mak

2015-06-23 08:24:33 +0100
Chris Liddell <chris.liddell@artifex.com>
663d2c237506045862a4c8d13cbea26c534dc893

> Quash some compiler warnings.
> No cluster differences
> gs/base/fapi_ft.c

2015-06-22 08:02:38 +0100
Chris Liddell <chris.liddell@artifex.com>
e30f3e82b017756428974be81c08fb212f28673e

> Coverity #94836: remove dead code.
> No cluster diffs
> gs/base/fapi_ft.c

2015-06-19 16:00:58 +0100
Chris Liddell <chris.liddell@artifex.com>
078079b7a857c5d640854fd1a06578675d9adaab

> Coverity ID #94816: initialise pointer to NULL.
> Benign: initialise the ft_stream pointer to NULL when we're not opening a stream
> based font in freetype.
> No cluster differences.
> gs/base/fapi_ft.c

2015-06-19 15:57:55 +0100
Chris Liddell <chris.liddell@artifex.com>
e0778e3f7815dd4a27b275772560dc450d5e2bc3

> Coverity ID# 94753: clean up error handling.
> Move handling an out of memory condition to avoid a potential null pointer
> dereference.
> No cluster differences.
> gs/base/fapi_ft.c

2015-06-19 15:55:28 +0100
Chris Liddell <chris.liddell@artifex.com>
81137c03db99736261862fb2745e8e989983e859

> Coverity: ID #94572: NULL pointer dereference
> In the event we have no i/o device, throw an error. Avoids a possible NULL
> pointer dereference.
> No cluster differences
> gs/base/fapi_ft.c

2015-06-19 15:45:20 +0100
Chris Liddell <chris.liddell@artifex.com>
9e264c139aa99ad827171e65ebd802d55cb92dbe

> Coverity ID #94675, #94731, #94772, #94800
> Tidy up conditionals where one condition cannot occur at that point (mostly
> benign copy and paste mistakes).
> Restore a locally changed value in an external object before returning.
> No cluster differences.
> gs/base/gxfapi.c

2015-06-23 08:21:19 +0100
Ken Sharp <ken.sharp@artifex.com>
134424c1fe1b163e3bd3e230b6b2acd217843d9c

> The default case lacked a break. I suspect this is a hold over from an
> older set of code where it may have made sense, it doesn't now.
> gs/devices/vector/gdevpdfp.c

2015-06-23 08:20:02 +0100
Ken Sharp <ken.sharp@artifex.com>
500f1e8f1436ac82c642c325d0f0e67aabc9cef9

> Coverity ID #94701 two comparisons against ccs_sRGB. We really wanted to
> test for RGB or sRGB here, so one of them should have been ccs_RGB. Fixed
> gs/devices/vector/gdevpdfp.c

2015-06-22 14:59:16 +0100
Ken Sharp <ken.sharp@artifex.com>
05e65d67fcf33e8223bacfe7c060380ba291c07c

> change missed in previous commit
> gs/devices/vector/gdevpdfo.c

2015-06-22 14:57:06 +0100
Ken Sharp <ken.sharp@artifex.com>
94105d6b7273c83e24f8561f4c086657fa071219

> coverity ID #94518 more checks on return code form gp_fseek_64
> gs/devices/vector/gdevpdfo.c

2015-06-22 14:39:35 +0100
Ken Sharp <ken.sharp@artifex.com>
a89d5988026eeb1477bd9a2ec8b463fc4596fa21

> Coverity ID #94510 add some checks to the return from gp_fseek_64
> gs/devices/vector/gdevpdfo.c

2015-06-22 14:18:49 +0100
Ken Sharp <ken.sharp@artifex.com>
30f0a322ea0643366a93274e03dc80e226a7b822

> Coverity ID #94648, ensure a pointer cannot be dereferenced if NULL. In
> practice it can't happen because we check the size of the data firs, and the
> size is initialised to 0. But it is slightly safer to be certain.
> gs/devices/vector/gdevpdfm.c

2015-06-22 13:51:57 +0100
Ken Sharp <ken.sharp@artifex.com>
0f7ab3e067a5e8b8434312ca5ce364869288eeec

> Coverity ID #94530 check and action a return code.
> gs/devices/vector/gdevpdfm.c

2015-06-21 16:28:42 +0100
Ken Sharp <ken.sharp@artifex.com>
4d4a868350c8ec82b8ce42100cd03aef92e1d40a

> Coverity ID #94974, the variable can never be uninitialised, but that's
> not evident because it depends on the switch statement and there is no
> default case coded because we cater for all possibilities.
> Add a memset to the default case just to set the memory to NULL, it will
> never be called.
> gs/devices/vector/gdevpdfk.c

2015-06-21 16:24:01 +0100
Ken Sharp <ken.sharp@artifex.com>
7427b67964490963ce82076a0cd4ff334d03ad62

> Coverity ID #94931 increase buffer to 256 so that array bounds check is correct.
> gs/devices/vector/gdevpdfj.c

2015-06-21 16:16:59 +0100
Ken Sharp <ken.sharp@artifex.com>
a8eb47a837b31ce723e76c98f122ba834b7380d0

> Coverity ID #94678 guard a potential null pointer dereference with a check.
> gs/devices/vector/gdevpdfi.c

2015-06-21 13:51:56 +0100
Ken Sharp <ken.sharp@artifex.com>
f629df898a59145db4b8b60447ba46671a3bf76e

> dummy
> gs/devices/vector/gdevpdfg.c

2015-06-21 13:36:46 +0100
Ken Sharp <ken.sharp@artifex.com>
010b0dc68542a17e0309f230ee071ca0a6f2bb84

> Coverity ID #95002 another couple of pointless NULL pointer checks
> gs/devices/vector/gdevpdfg.c

2015-06-21 13:30:40 +0100
Ken Sharp <ken.sharp@artifex.com>
b0f10e57dcd17c31a8754eaca38ba49a4496f52d

> Coverity ID #94908 pointless check of NULL Pointer, removed.
> gs/devices/vector/gdevpdfg.c

2015-06-21 13:23:38 +0100
Ken Sharp <ken.sharp@artifex.com>
6482eded57246b1ddebe590d6874a01220477d16

> Coverity ID #94680, the previous code checked the incorrect returned value,
> leading to dead code.
> Coverity ID #94786, this is spurious, we check the colour space is one of
> Gray, RGB or CMYK, then switch on the number of components (1, 3, 4) and set
> a variable. This causes a complaint that the variable 'command' could be
> dereferenced when NULL. In practice this is impossible.
> gs/devices/vector/gdevpdfg.c

2015-06-19 15:51:42 +0100
Ken Sharp <ken.sharp@artifex.com>
34aa319c5d592ffba5d814aef30e67f3aef55adb

> Coverity ID #94561 its technically possible to get into new_pdf_reset_color
> with pis being NULL, if we don't have a high level colour imager state for a stroke.
> In practice I don't believe its possible to have a pattern colour space for
> a stroke without an image state for a high level colour, but its wise to
> check before dereferencing.
> gs/devices/vector/gdevpdfg.c

2015-06-19 15:44:52 +0100
Ken Sharp <ken.sharp@artifex.com>
c82b4be5033763c0a5fb4b46e5f5628b6703e7f3

> Coverity ID #94544, should have been assigning to y, not x
> gs/devices/vector/gdevpdfd.c

2015-06-19 11:25:59 +0100
Chris Liddell <chris.liddell@artifex.com>
75c8ee6f7e8e3d87033a5d1055d66237ed28b387

> Coverity: don't ignore error return.
> No cluster differences.
> gs/base/fapi_ft.c

2015-06-19 11:18:32 +0100
Chris Liddell <chris.liddell@artifex.com>
3adab1a6e20eebc004e032c50f017b176e5b3aeb

> Coverity: move assignment to before the return
> Resetting a pointer to NULL was after the function returned.
> No cluster differences.
> gs/psi/zfile.c

2015-06-19 11:10:03 +0100
Chris Liddell <chris.liddell@artifex.com>
d366dc9568f3bd2da06b57c7b0776b299200861a

> Coverity: add initializer and check some return codes.
> In truth, these were benign - we couldn't get to the ps_get_glyphname_or_cid()
> call if the dictionary lookups would fail, and the possibly "uninitialized
> variable" also couldn't happen, as one of the routes through the code that sets
> it would have to be traversed with a valid font, and if the font were not valid
> we'd never get to that function....
> No cluster differences.
> gs/psi/zfapi.c

2015-06-19 11:02:04 +0100
Chris Liddell <chris.liddell@artifex.com>
24f0b7d55b89b30d64623e03269027020628a432

> Coverity: change parameter from explicit array to ptr.
> gs_type42_default_get_metrics() takes either a 4 element or 8 element float
> array depending on metrics requested, but the parameter was explicitly declared
> as a four element array.
> No cluster diffs.
> gs/base/gstype42.c

2015-06-19 14:30:25 +0100
Ken Sharp <ken.sharp@artifex.com>
1e7db1c8bc26d57740b6ce4e6bcb2a154de2952a

> Add a pointer cast to silence a Cppcheck warning (can't be a new warning
> but it just popped up).
> gs/devices/vector/gdevpdfm.c

2015-06-19 14:29:53 +0100
Ken Sharp <ken.sharp@artifex.com>
c458209c7de440ce65b1ae48f982635d2f1cf2ac

> Coverity ID #94519, #94538 check the return value from gp_fseek_64.
> Coverity ID #94813, check return value from fread and return error if failed.
> Coverity ID #95042, add a missing check on return value of rewrite_object
> gs/devices/vector/gdevpdf.c

2015-06-19 10:18:17 +0100
Chris Liddell <chris.liddell@artifex.com>
d64555d5f1180ee84875c7031d5acc3596397c24

> Bug 696037: resolve issue with named pipes on Windows
> The stat() call does not work for named pipes on Windows.
> Move around the order of tests in lib_file_open_search_with_no_combine() so
> it works with names pipes.
> The way lib_file_open_search_with_no_combine() works is that we have a list of
> paths to search, and list of paths from which we are allowed to open files.
> If a file does not exist in one path from our search list, we continue
> searching.
> If, on the other hand, the file does exist, but is not in a path we are
> permitted to use files from, we have to throw an invalidaccess error.
> Previously, we'd stat() the file, then consult our allowed paths, then open the
> file - taking appropriate alternative action if any of those stages failed.
> Now, we consult the permitted paths first, and if that fails, only then do we
> call stat() to decide whether to throw an error, or continue searching.
> This should work correctly with Windows named pipes, as the names are always of
> the form "\\\\.\\pipe\\..." (local) or "\\ServerName\pipe\..." (remote) so in
> both cases the leading character being "\" will identify it as an absolute path
> and those are always allowed.
> No cluster differences.
> gs/psi/zfile.c

2015-06-19 10:36:29 +0100
Ken Sharp <ken.sharp@artifex.com>
106be79bed699548c6094a0ffa98d73be3e32ce8

> Split previous initialisation so that we don't end up assigning an integer
> to a pointer (causing a new warning...)
> gs/devices/vector/gdevpdfm.c

2015-06-19 08:06:03 +0100
Ken Sharp <ken.sharp@artifex.com>
c46817a77dc2fd72ea2d1c16e140fba607a8787c

> Check before dereferencing a pointer, silences Coverity warning.
> gs/devices/vector/gdevpdfv.c

2015-06-19 08:04:50 +0100
Ken Sharp <ken.sharp@artifex.com>
997591ab50521899870075d3f85f1c7aef1ea81b

> Initialise 'Stack' memory to silence a Coverity warning. bounds check an
> array access to ensure we don't read off the bottom end.
> gs/devices/vector/gdevpsf1.c

2015-06-19 08:03:47 +0100
Ken Sharp <ken.sharp@artifex.com>
e5de820e5fca5cc836c4bf7099f86eb0ab5299ae

> Silence a Coverity warning by initialising some variables
> gs/devices/vector/gdevpdfm.c

2015-06-19 08:03:16 +0100
Ken Sharp <ken.sharp@artifex.com>
74b3ed15d3c03f9486fa829ba9fd14d26c5eb582

> Check a return value to silence a Coverity warning
> Should this actually ever fail we'd write an invalid PDF file anyway.
> gs/devices/vector/gdevpdf.c

2015-06-19 08:02:02 +0100
Ken Sharp <ken.sharp@artifex.com>
223c7994f8caa0500dc345ff86170d55776fc222

> Spotted by Coverity, fix parentheses for checking file is writeable
> gs/base/ramfs.c

2015-06-16 18:32:47 +0100
Robin Watts <robin.watts@artifex.com>
9b4c78e969e75d8a0a9490511af07bb41cc26431

> Bug 695234: Fix valgrind warnings with fuzzed file.
> The file was reported as causing SEGVs, but I cannot reproduce this.
> Possibly the SEGV was fixed by Chris' change for bug 694205.
> gs/base/gxfill.c

2015-06-15 17:30:39 +0100
Robin Watts <robin.watts@artifex.com>
b83b92758672b1ea690d4b979afaf07cf251b11f

> Bug 695348: Proper fix for avoiding SEGV in interpolated scalar.
> Avoid using the interpolated scaler for images where the
> calculations have overflowed.
> gs/base/gxiscale.c

2015-06-16 10:13:47 +0100
Ken Sharp <ken.sharp@artifex.com>
72ca9b670f70cfaad1a299f891d03a313143cc3c

> PDF interpreter - further work to handle illegal operations in text blocks
> Bug #696017 "Portions of page missing"
> The specimen file contains numerous operations illegally inside text blocks,
> previously we fixed this for nested text blocks and more recently for images
> inside text blocks. However this file also has stroke operations inside text
> blocks (also illegal).
> Here we handle this by redefining the path construction operators so that
> they check for the existence of a SavedTextMatrix and use that instead of
> the CTM if it is present. This has some consequences; we can't do this for
> pattern PaintProcs or the pattern will be incorrectly defined, and the flag
> we were previously using (presence of TextSavedMatrix in currentdict) can't
> be used as that isn't present during the execution of a PaintProc. So we
> have to look at the current definition of the marking operations (we choose
> to just use /m for brevity) and take action based upon that. We always set
> the 'normal' marking ops for a PaintProc, and if we are in a text block
> we switch the ops back again after running the PaintProc.
> No differences (except the obvious expected one in Bug696017.pdf)
> gs/Resource/Init/pdf_draw.ps
> gs/Resource/Init/pdf_ops.ps

2015-06-15 16:49:51 +0100
Robin Watts <robin.watts@artifex.com>
4191a9eb66adffbf6ae77c4f89f6dbbffc847ed9

> Revert "Bug 695348: Avoid SEGV in interpolated scaler."
> This reverts commit 78b27bf3e1a70699296f41442e767b1d04492b1c.
> I forgot a ' < 0' in one of the tests. This returns the tests to
> sanity to let me check the impact of the proper fix correctly.
> gs/base/gxipixel.c
> gs/base/gxiscale.c

2015-06-15 13:51:14 +0100
Robin Watts <robin.watts@artifex.com>
78b27bf3e1a70699296f41442e767b1d04492b1c

> Bug 695348: Avoid SEGV in interpolated scaler.
> Don't use interpolated scaler if calculations have overflowed.
> gs/base/gxipixel.c
> gs/base/gxiscale.c

2015-06-12 19:54:41 +0100
Robin Watts <robin.watts@artifex.com>
1572afcd641ed003150eec439c7ca16145cd0888

> Bug 695954: Add gp_stat function.
> gp_stat just calls stat, except on windows, where it converts from
> UTF8 to unicode and calls _wstat.
> gs/base/gp.h
> gs/base/gp_macio.c
> gs/base/gp_mswin.c
> gs/base/gp_os2fs.c
> gs/base/gp_unifs.c
> gs/base/gp_vms.c
> gs/base/gsiodev.c
> gs/base/stat_.h

2015-06-11 12:18:52 +0100
Ken Sharp <ken.sharp@artifex.com>
908a9083697c8d41057110f30adf7a6c6b6eb46b

> pdfwrite - fix ToUnicode emission
> Bug #696021 "commit 24c562(fix for #692119) causes G2U mapping is lost in CIDFont"
> Despite the bug title, it was in fact commit
> 1be6f4e4084443772b928510fb7ebce71572ea10 which broke the handling of the
> code created by PSCRIPT5.DLL. The windows printing system emits a
> GlyphNames2Unicode dictionary which you would expect to contain names and
> Unicode values, but in fact contains character codes and Unicode values.
> Sometimes we have the Character code to CID mapping being an identity, and
> sometimes we don't. So we need to check both of these, which we can conveniently
> do by lying to the decode_glyph procedure and pretending we are not a CIDFont.
> We don't generally want to do this though, so we only do it if the CID and
> character code differ. I haven't found a case where a PDF input file has a
> differing CID and character code *and* fails decode_glyph with a CID, but
> I suspect this may be possible, in which case we'll get a garbage ToUnicode
> CMap, but it won't be worse than it was before
> I think the code originally supplied by the user to fix this bug is dangerous
> (may produce incorrect results with PDF input files) and so have not entirely
> adopted it but created our own resolution.
> No differences expected.
> gs/devices/vector/gdevpdtc.c

2015-06-08 03:15:26 +0100
Chris Liddell <chris.liddell@artifex.com>
2395efe0bb6ee1e054ace4866a3c8dc4afb56c60

> Use an enum for error codes common to all modules
> No cluster differences.
> gs/base/gserrors.h

2015-06-09 12:36:59 +0100
Chris Liddell <chris.liddell@artifex.com>
4da046f4dff81fdb6d8b7fdf5d114187d4782617

> Bug 695810: improve/expand tests for memory alignment
> Add a cross platform test for minimum memory alignment in configure. Make it
> apply for the whole of the build (not just LCMS). And allow it to be
> overridden at the command line.
> No cluster diffs
> configure.ac
> gs/Makefile.in
> gs/base/genarch.c
> gs/configure.ac

2015-06-10 09:29:45 +0100
Ken Sharp <ken.sharp@artifex.com>
dbfd36b313eb9866300d5f7daef1249831332acf

> PDF interpreter - ignore broken SMask in ExtGState
> Bug #696027 "Blank page instead of expected output"
> The PDF file is invalid, it has an ExtGState with a SMask dictionary, the
> SMask does not contain a /Group, which is required and the dictionary is
> unusable without it.
> This commit wraps the execution of SMask in a stopped so that if it fails
> we can raise a warning and continue with the ExtGState, effectively ignoring
> the invalid SMask.
> This produces a small progression in tests_private/pdf/sumatra/broken_xobject_messing_up_clip_stack.pdf
> that particular file is so damaged even Acrobat won't open it, but a
> progression is nice anyway.
> gs/Resource/Init/pdf_draw.ps

2015-06-09 09:56:16 +0100
Ken Sharp <ken.sharp@artifex.com>
7e05f9d78f63b2a84339f1f39505a786fed75599

> Remove 2 unused variables to silence compiler warnings.
> gs/devices/vector/gdevpdfo.c

2015-06-09 09:20:10 +0100
Ken Sharp <ken.sharp@artifex.com>
cb48631e7254e0843a08f075777cbecb43947823

> pdfwrite - write encrypted strings in Dests tree if protected PDF output
> Bug #695992
> We were forced to stop using names when creatng a Dests tree (instead of
> an array), even though it seems legal, because Acrobat didn't like it.
> However, I forgot to take account of password protected PDF files, which
> require us to encrypt strings. Encryption is applied in this commit if
> it is required.
> No differences expected.
> gs/devices/vector/gdevpdfo.c

2015-06-04 16:30:03 +0100
Chris Liddell <chris.liddell@artifex.com>
640801c0fd5527c7f183549df4fd2da365e427d4

> Consolidate almost all error codes into the graphics library
> Do away with the separate/duplicate error code definitions in the Postscript
> interpreter and in the graphics library. Also, where possible, do the same
> for PCL.
> The exception is the PXL code which has errors codes entirely of its own -
> as unpleasant as that is, it would require rather more invasive changes to
> have PXL use the common error codes. Possibly something to consider for a
> future commit.
> No cluster differences.
> gs/base/gserrors.h
> gs/base/stream.h
> gs/psi/apitest.c
> gs/psi/dmmain.c
> gs/psi/dpmain.c
> gs/psi/dwmain.c
> gs/psi/dwmainc.c
> gs/psi/dxmain.c
> gs/psi/dxmainc.c
> gs/psi/estack.h
> gs/psi/gs.c
> gs/psi/gsdll.c
> gs/psi/gserver.c
> gs/psi/ialloc.c
> gs/psi/iapi.c
> gs/psi/iapi.h
> gs/psi/ibnum.c
> gs/psi/icontext.c
> gs/psi/idict.c
> gs/psi/idict.h
> gs/psi/idparam.c
> gs/psi/ierrors.h
> gs/psi/igstate.h
> gs/psi/iinit.c
> gs/psi/imain.c
> gs/psi/imain.h
> gs/psi/imainarg.c
> gs/psi/iname.c
> gs/psi/inobtokn.c
> gs/psi/int.mak
> gs/psi/interp.c
> gs/psi/iparam.c
> gs/psi/iparam.h
> gs/psi/iplugin.c
> gs/psi/ireclaim.c
> gs/psi/isave.c
> gs/psi/iscan.c
> gs/psi/iscanbin.c
> gs/psi/iscanbin.h
> gs/psi/iscannum.c
> gs/psi/istack.c
> gs/psi/istack.h
> gs/psi/iutil.c
> gs/psi/iutil.h
> gs/psi/iutil2.c
> gs/psi/ivmspace.h
> gs/psi/opcheck.h
> gs/psi/oper.h
> gs/psi/ostack.h
> gs/psi/zalg.c
> gs/psi/zarith.c
> gs/psi/zarray.c
> gs/psi/zbfont.c
> gs/psi/zbseq.c
> gs/psi/zcfont.c
> gs/psi/zchar.c
> gs/psi/zchar1.c
> gs/psi/zchar32.c
> gs/psi/zchar42.c
> gs/psi/zcharout.c
> gs/psi/zcharx.c
> gs/psi/zcid.c
> gs/psi/zcidtest.c
> gs/psi/zcie.c
> gs/psi/zcolor.c
> gs/psi/zcontext.c
> gs/psi/zcontrol.c
> gs/psi/zcrd.c
> gs/psi/zdevice.c
> gs/psi/zdevice2.c
> gs/psi/zdict.c
> gs/psi/zdouble.c
> gs/psi/zdpnext.c
> gs/psi/zdps.c
> gs/psi/zdps1.c
> gs/psi/zdscpars.c
> gs/psi/zfaes.c
> gs/psi/zfapi.c
> gs/psi/zfarc4.c
> gs/psi/zfcid.c
> gs/psi/zfcid0.c
> gs/psi/zfcid1.c
> gs/psi/zfcmap.c
> gs/psi/zfdctd.c
> gs/psi/zfdcte.c
> gs/psi/zfdecode.c
> gs/psi/zfile.c
> gs/psi/zfile1.c
> gs/psi/zfileio.c
> gs/psi/zfilter.c
> gs/psi/zfilter2.c
> gs/psi/zfilterx.c
> gs/psi/zfimscale.c
> gs/psi/zfjbig2.c
> gs/psi/zfont.c
> gs/psi/zfont0.c
> gs/psi/zfont1.c
> gs/psi/zfont2.c
> gs/psi/zfont42.c
> gs/psi/zfontenum.c
> gs/psi/zform.c
> gs/psi/zfproc.c
> gs/psi/zfrsd.c
> gs/psi/zfsample.c
> gs/psi/zfunc.c
> gs/psi/zfunc0.c
> gs/psi/zfunc3.c
> gs/psi/zfunc4.c
> gs/psi/zgeneric.c
> gs/psi/zgstate.c
> gs/psi/zht.c
> gs/psi/zht1.c
> gs/psi/zht2.c
> gs/psi/zicc.c
> gs/psi/zimage.c
> gs/psi/zimage3.c
> gs/psi/ziodev.c
> gs/psi/ziodev2.c
> gs/psi/ziodevs.c
> gs/psi/ziodevsc.c
> gs/psi/zmath.c
> gs/psi/zmatrix.c
> gs/psi/zmedia2.c
> gs/psi/zmisc.c
> gs/psi/zmisc1.c
> gs/psi/zmisc2.c
> gs/psi/zpacked.c
> gs/psi/zpaint.c
> gs/psi/zpath1.c
> gs/psi/zpcolor.c
> gs/psi/zpdf_r6.c
> gs/psi/zpdfops.c
> gs/psi/zshade.c
> gs/psi/zstack.c
> gs/psi/zstring.c
> gs/psi/ztoken.c
> gs/psi/ztrans.c
> gs/psi/ztrap.c
> gs/psi/ztype.c
> gs/psi/zupath.c
> gs/psi/zusparam.c
> gs/psi/zutf8.c
> gs/psi/zvmem.c
> gs/psi/zvmem2.c
> gs/psi/zwinutf8.c
> pcl/pgchar.c
> pcl/pgconfig.c
> pcl/pglabel.c
> pcl/pglfill.c
> pcl/pgmand.h
> pcl/pgparse.c
> pcl/pgvector.c

2015-06-06 20:07:10 +0100
Ken Sharp <ken.sharp@artifex.com>
a6d05fcee5521bc410068b16925c36476f207eab

> pdfwrite - fix consecutive CIE colour usage
> Bug #695847 " colors in CIE color model are not converted correctly to PDF"
> CIE colours cannot be represented directly in a PDF file, they *must* be
> converted into an ICCBased colour space. If the colour conversion strategy
> was LeaveColorUnchanged then the first usage of a colour in a CIEBased
> colour space was correctly convrted, and the colour components rescaled,
> but if the job then used another, different, colour in the same colour
> space then the components were written out unscaled.
> This commit forces colours in a CIEBased space to always be rescaled.
> This gives one small progression in the test suite (09-31.ps) and some
> slight colour differences in a further 7 files.
> gs/devices/vector/gdevpdfg.c

2015-06-05 23:59:53 +0100
Ken Sharp <ken.sharp@artifex.com>
3a54125ff9225876f56e812f45bfc38cb2861c4b

> PDF Interpreter - fix a problem with DecodeParms
> Bug #696019 "- Regression: reading PDF file produces error starting with ddaea8157085f4efb227e78326dd739d59493b97"
> There was a problem whe we had an image dictionary with a /Filter, which was
> not an array. We consumed the image and stream dictionaries which led to an
> error.
> This commit correctly updates and preserves the dictionaries.
> No differences expected.
> gs/Resource/Init/pdf_draw.ps

2015-06-05 12:09:55 -0700
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
4752fbce72100255089a5251b741711eab038ea0

> Clarified comment re. default PCL HW margins in pcl/pcpage.c.
> pcl/pcpage.c

2015-06-04 11:17:34 -0700
Robin Watts <Robin.Watts@artifex.com>
70242e40c8b12024f517155176cd81bf62bb932e

> MSVC: Ensure that language switch still build on windows.
> We were a) not linking in the right msprinter device (XPSPrint
> missing), and b) not linking in the lib that XPSPrint needed.
> gs/base/msvctail.mak
> language_switch/pspcl6_msvc.mak

2015-06-04 11:14:56 -0700
Robin Watts <Robin.Watts@artifex.com>
07c977b5d7f586758143afa07bde29d9fe9eaede

> MSVC Makefile sanitisation: Pass PGMFILES etc in debug call
> In the recursive make call done for debug builds, we pass
> BUILD_SYSTEM. If we're going to pass BUILD_SYSTEM, we must
> pass PGMFILES and PGMFILESx86 too, as these will not get
> set if BUILD_SYSTEM is already set.
> gs/psi/msvc.mak

2015-06-04 13:51:38 +0100
Robin Watts <Robin.Watts@artifex.com>
d3dd0d208955d1368270e1139178bc6776e0574e

> Windows display builds: set app as being dpi aware.
> This avoids horrible screen scaling.
> gs/psi/dwmain.c
> gs/psi/dwmainc.c
> pl/dwmainc.c

2015-05-28 09:40:41 +0100
Ken Sharp <ken.sharp@artifex.com>
32fc208587c2c8e6d2eca660ed0c84bdc6d799cd

> Bug #696009 "File doc/current/Install.htm and Windows 95"
> The last version of Ghostscript which actually installed (using our installer)
> on Windows 95 was apparently 8.60, the documentation said 8.71.
> gs/doc/Install.htm

2015-05-28 09:38:11 +0100
Ken Sharp <ken.sharp@artifex.com>
be72694a3cac0aa72c0843334e7f1afdabbddc7a

> Digitally sign the 'ghostscript printer' file ghostpdf.inf
> Recent versions (8+) of Windows make it very difficult to install a device
> whose driver is not signed. While the ghostpdf.inf file isn't really part
> of Ghostscript we have had enquiries about producing s signed version. Now
> that we have our own certificate, this is possible and is done here.
> This should now install without problems on WIndows 8 and with fewer warnings
> from UAC on Vista and Windows 7.
> gs/lib/ghostpdf.README
> gs/lib/ghostpdf.cat
> gs/lib/ghostpdf.inf

2015-05-26 16:44:56 +0100
Chris Liddell <chris.liddell@artifex.com>
46cbd27208a84296d7bda96bf24b83ec0c084b57

> Bug 694549: make optimisation more robust.
> And optimisation to reduce load on the memory manager and garbage collector
> could end up dumping PS refs in a chunk not marked as containing refs,
> potentially resulting in refs being mis-handled during save/restore.
> No cluster differences, but should stop Bug688845.eps seg faulting/erroring out
> gs/psi/ialloc.c

2015-05-25 10:45:47 -0700
Ray Johnston <ray.johnston@artifex.com>
ef0c86cbf991166924c84657eac90ca357457697

> Disable fast threhsold halftoning because it doesn't match HT tiling.
> This was discovered while working on fixing a bug in the threshold
> array generation (bug 695929). The 'off' offset causes gray shade
> differences, and the t_level_adjust, delta and delta_sum logic is
> broken for num_levels > 256.
> gs/base/gxht_thresh.h

2015-05-23 18:08:57 -0300
Till Kamppeter <till.kamppeter@gmail.com>
d73a3420ad559a527fd0ee94ddb3a37620933a16

> "cups"/"pwgraster" output devices: Added support for the color spaces
> 18 (SGray), 19 (SRGB), and 20 (Adobe RGB).
> Note that this is not a full implementation in terms of color
> management. The implementation is done by simply using the most
> similar of the existing color spaces, simple grayscale (0) for SGray
> and RGB (1) for SRGB and Adobe RGB.
> This prevents Ghostscript from crashing and produce an output as close
> as possible to the desired when these new color spaces are requested.
> TODO: Proper color management for the SGray, SRGB, and Adobe RGB
> output.
> gs/cups/gdevcups.c

2015-05-21 21:53:25 +0100
Chris Liddell <chris.liddell@artifex.com>
668406a56eb351bf07fe3b5ec1be7bfc89cf4d77

> Bug 696005: handle indirect objs in image parameters
> When we round and convert to integer the height parameter in an image (to handle
> the parameter being a real rather than integer, it needs to account for the
> value being an indirect object.
> No cluster differences.
> gs/Resource/Init/pdf_draw.ps

2015-05-21 12:48:31 +0100
Chris Liddell <chris.liddell@artifex.com>
30d3d658ddc70e070e915995e072eb2315942619

> Make use of revised endian checks in LCMS2.
> No cluster differences
> configure.ac
> gs/configure.ac

2015-05-21 12:40:07 +0100
Chris Liddell <chris.liddell@artifex.com>
17ee8f214fc2621c594efcdb898756b3b8ff649a

> Bug 695544: Simplify/Improve endian decisions in lcms2.h
> Firstly, protect the endian decisions in lcms2.h so that settings given on the
> compiler command line are not silently overridden. Thus being set explicitly
> gets the highest priority.
> Secondly, use the endianness detected by the configure script, and remove the
> complex and error prone stuff for PPC platforms from lcms2.h. Thus the endianess
> from configure gets second highest priority.
> Thirdly, if neither of the above are set, fall back to some simple (and long
> standing) platform/compiler specific tests. These should rarely, if ever, come
> into play in a "normal" build for a "normal" Unix-like system.
> Submitted and committed upstream:
> https://github.com/mm2/Little-CMS/commit/6e33faab
> No cluster differences.
> gs/lcms2/include/lcms2.h

2015-05-20 17:54:21 +0100
Chris Liddell <chris.liddell@artifex.com>
e2a659fd03505668929eb0264a97e959fc722eb9

> Fix comment regarding FAPI, UFST and Freetype
> No cluster differences
> gs/Makefile.in

2015-05-19 15:42:12 +0100
Chris Liddell <chris.liddell@artifex.com>
f831cdfd7909bb1bd1feabb12311ffed1afd7c03

> Fix compiler warning unsigned/signed comparison
> gs/base/gp_unifs.c

2015-05-19 15:38:27 +0100
Chris Liddell <chris.liddell@artifex.com>
d81f899051cb374faa1da265a41c3eec899a36a6

> Update to libjpeg 9a
> gs/jpeg/Makefile.am
> gs/jpeg/Makefile.in
> gs/jpeg/README
> gs/jpeg/aclocal.m4
> gs/jpeg/ansi2knr.1
> gs/jpeg/ansi2knr.c
> gs/jpeg/ar-lib
> gs/jpeg/change.log
> gs/jpeg/cjpeg.1
> gs/jpeg/cjpeg.c
> gs/jpeg/compile
> gs/jpeg/config.guess
> gs/jpeg/config.sub
> gs/jpeg/configure
> gs/jpeg/configure.ac
> gs/jpeg/depcomp
> gs/jpeg/djpeg.1
> gs/jpeg/djpeg.c
> gs/jpeg/filelist.txt
> gs/jpeg/install-sh
> gs/jpeg/install.txt
> gs/jpeg/jcapistd.c
> gs/jpeg/jcarith.c
> gs/jpeg/jccolor.c
> gs/jpeg/jcdctmgr.c
> gs/jpeg/jchuff.c
> gs/jpeg/jcinit.c
> gs/jpeg/jcmainct.c
> gs/jpeg/jcmarker.c
> gs/jpeg/jcmaster.c
> gs/jpeg/jconfig.cfg
> gs/jpeg/jconfig.txt
> gs/jpeg/jconfig.vc
> gs/jpeg/jcparam.c
> gs/jpeg/jctrans.c
> gs/jpeg/jdapimin.c
> gs/jpeg/jdapistd.c
> gs/jpeg/jdarith.c
> gs/jpeg/jdatadst.c
> gs/jpeg/jdcolor.c
> gs/jpeg/jddctmgr.c
> gs/jpeg/jdhuff.c
> gs/jpeg/jdinput.c
> gs/jpeg/jdmainct.c
> gs/jpeg/jdmarker.c
> gs/jpeg/jdmaster.c
> gs/jpeg/jdmerge.c
> gs/jpeg/jerror.c
> gs/jpeg/jerror.h
> gs/jpeg/jfdctint.c
> gs/jpeg/jidctint.c
> gs/jpeg/jmemmgr.c
> gs/jpeg/jmorecfg.h
> gs/jpeg/jpegint.h
> gs/jpeg/jpeglib.h
> gs/jpeg/jpegtran.1
> gs/jpeg/jpegtran.c
> gs/jpeg/jversion.h
> gs/jpeg/libjpeg.map
> gs/jpeg/libjpeg.txt
> gs/jpeg/makefile.ansi
> gs/jpeg/makefile.bcc
> gs/jpeg/makefile.dj
> gs/jpeg/makefile.manx
> gs/jpeg/makefile.mc6
> gs/jpeg/makefile.mms
> gs/jpeg/makefile.sas
> gs/jpeg/makefile.unix
> gs/jpeg/makefile.vc
> gs/jpeg/makefile.wat
> gs/jpeg/missing
> gs/jpeg/rdjpgcom.1
> gs/jpeg/structure.txt
> gs/jpeg/testimg.bmp
> gs/jpeg/testimg.ppm
> gs/jpeg/transupp.c
> gs/jpeg/transupp.h
> gs/jpeg/usage.txt

2015-05-19 11:03:04 -0700
Ray Johnston <ray.johnston@artifex.com>
22c1f418a37ccbb31aaf2910cf7926ce85bf8df0

> Fix some compiler warnings. Thanks to Robin for spotting these.
> Note change to use _fstat64 to allow for large file sizes and to get
> rid of warnings. Fixed use of QueryPerformance functions (Windows).
> Fix a wrong cast in cmd_drawing_color_usage.
> gs/base/gp_mswin.c
> gs/base/gp_win32.c
> gs/base/gxclpath.c

2015-05-19 12:27:36 -0700
Michael Vrhel <michael.vrhel@artifex.com>
2c10206487eb9aa4623395148fa4b393b95af8ce

> Add in some error checking during ICC profile creation.
> Thanks to Tim Waugh for catching one of these (bug 695474)
> gs/base/gsciemap.c
> gs/base/gsicc_manage.c
> xps/xpscolor.c
> xps/xpsimage.c

2015-05-19 09:59:31 -0700
Michael Vrhel <michael.vrhel@artifex.com>
0309d66cc63c8ebfed8b8aa301d8c819b469dd63

> Do not embed ICC profiles in JPEG, TIFF or PNG when -dUseFastColor is specified
> A reasonable request in bug 695584
> gs/devices/gdevjpeg.c
> gs/devices/gdevpng.c
> gs/devices/gdevtifs.c

2015-05-14 15:33:03 +0100
Ken Sharp <ken.sharp@artifex.com>
47b1c5726a717be052957b399ff0e2cd32fd7bca

> pdfwrite - Fix a conversion of a /Separation bas space
> Bug #695953 "bad pdf generation"
> When converting a /Separation space's alternate, because the suer has
> specified ColorConversionStrategy, if the conversion was to sRGB we would
> write the incorrect space, as this case was missing from the switch.
> No differences expected.
> gs/devices/vector/gdevpdfg.c

2015-05-14 12:17:14 +0100
Ken Sharp <ken.sharp@artifex.com>
ab45751e7b38c7f9b28b090af52649f19355115d

> pdfwrite - Use the Mitchell filter instead of 'bicubic' for better quality
> Bug #695597 "Look at the output from the pdfwrite Bicubic image downsampler"
> The Mitchell filter output is clearly of superior quality to the existing
> bicubic filter. So use it instead.....
> Note; when we switch to bicubic because the downsampling factor is not an
> integer, we still use bicubic.
> Update the documentation and change some of the defaults as well.
> gs/Resource/Init/gs_pdfwr.ps
> gs/devices/vector/gdevpsdi.c
> gs/doc/Ps2pdf.htm

2015-05-13 15:04:07 +0100
Ken Sharp <ken.sharp@artifex.com>
d9172b7dfeac889e4301cd98216fdc297bf9e7bc

> Don't load the image compression chooser when we are going to force lossless compression
> Bug #695978 "Unexpected downsampling"
> As noted in the bug thread, this isn't to do with downsampling. However, in
> the original email conversation I did note that there was a confusion in
> two tests in the code which should have been the same.
> This commit resolves that confusion, if we are forcing lossless compression
> we set the count of alternate streams to 1 initially. This will prevent us
> from loading the image compression chooser and hence avoid the second test
> which only takes place if we have alternate streams.
> Disabling the compression chooser is what gets the performance gain noted
> in the bug thread. It so happens that by specifying the downsampling filter
> the code took a different path, even though no downsampling was taking, and
> this was causing the compression chooser to be dumped.
> No differences expected.
> gs/devices/vector/gdevpdfi.c

2015-05-12 17:30:55 +0100
Chris Liddell <chris.liddell@artifex.com>
04de5b2db8ed54f424b6ec9458d7e1b5a15c89b4

> Update zlib to 1.2.8.
> Don't define _LARGEFILE64_SOURCE on MSVC build
> zlib 1.2.8 tries to include unistd.h if _LARGEFILE64_SOURCE is defined,
> causing build failure on Windows.
> gs/base/stdpre.h
> gs/zlib/CMakeLists.txt
> gs/zlib/ChangeLog
> gs/zlib/Makefile.in
> gs/zlib/README
> gs/zlib/adler32.c
> gs/zlib/as400/bndsrc
> gs/zlib/as400/compile.clp
> gs/zlib/as400/readme.txt
> gs/zlib/as400/zlib.inc
> gs/zlib/compress.c
> gs/zlib/configure
> gs/zlib/contrib/README.contrib
> gs/zlib/contrib/blast/blast.c
> gs/zlib/contrib/blast/blast.h
> gs/zlib/contrib/delphi/ZLib.pas
> gs/zlib/contrib/dotzlib/DotZLib/UnitTests.cs
> gs/zlib/contrib/infback9/infback9.c
> gs/zlib/contrib/infback9/inftree9.c
> gs/zlib/contrib/minizip/configure.ac
> gs/zlib/contrib/minizip/crypt.h
> gs/zlib/contrib/minizip/iowin32.c
> gs/zlib/contrib/minizip/miniunzip.1
> gs/zlib/contrib/minizip/minizip.1
> gs/zlib/contrib/minizip/unzip.c
> gs/zlib/contrib/minizip/unzip.h
> gs/zlib/contrib/minizip/zip.c
> gs/zlib/contrib/pascal/zlibpas.pas
> gs/zlib/contrib/puff/puff.c
> gs/zlib/contrib/puff/puff.h
> gs/zlib/contrib/puff/pufftest.c
> gs/zlib/contrib/testzlib/testzlib.c
> gs/zlib/contrib/vstudio/readme.txt
> gs/zlib/contrib/vstudio/vc10/miniunz.vcxproj.user
> gs/zlib/contrib/vstudio/vc10/minizip.vcxproj.user
> gs/zlib/contrib/vstudio/vc10/testzlib.vcxproj.user
> gs/zlib/contrib/vstudio/vc10/testzlibdll.vcxproj.user
> gs/zlib/contrib/vstudio/vc10/zlib.rc
> gs/zlib/contrib/vstudio/vc10/zlibstat.vcxproj
> gs/zlib/contrib/vstudio/vc10/zlibstat.vcxproj.user
> gs/zlib/contrib/vstudio/vc10/zlibvc.def
> gs/zlib/contrib/vstudio/vc10/zlibvc.vcxproj
> gs/zlib/contrib/vstudio/vc10/zlibvc.vcxproj.user
> gs/zlib/contrib/vstudio/vc11/miniunz.vcxproj
> gs/zlib/contrib/vstudio/vc11/minizip.vcxproj
> gs/zlib/contrib/vstudio/vc11/testzlib.vcxproj
> gs/zlib/contrib/vstudio/vc11/testzlibdll.vcxproj
> gs/zlib/contrib/vstudio/vc11/zlib.rc
> gs/zlib/contrib/vstudio/vc11/zlibstat.vcxproj
> gs/zlib/contrib/vstudio/vc11/zlibvc.def
> gs/zlib/contrib/vstudio/vc11/zlibvc.sln
> gs/zlib/contrib/vstudio/vc11/zlibvc.vcxproj
> gs/zlib/contrib/vstudio/vc9/zlib.rc
> gs/zlib/contrib/vstudio/vc9/zlibvc.def
> gs/zlib/crc32.c
> gs/zlib/deflate.c
> gs/zlib/deflate.h
> gs/zlib/examples/enough.c
> gs/zlib/examples/gun.c
> gs/zlib/examples/gzappend.c
> gs/zlib/examples/gzjoin.c
> gs/zlib/examples/gzlog.c
> gs/zlib/examples/gzlog.h
> gs/zlib/examples/zran.c
> gs/zlib/gzguts.h
> gs/zlib/gzlib.c
> gs/zlib/gzread.c
> gs/zlib/gzwrite.c
> gs/zlib/infback.c
> gs/zlib/inffast.c
> gs/zlib/inflate.c
> gs/zlib/inftrees.c
> gs/zlib/qnx/package.qpg
> gs/zlib/test/example.c
> gs/zlib/test/minigzip.c
> gs/zlib/treebuild.xml
> gs/zlib/trees.c
> gs/zlib/uncompr.c
> gs/zlib/win32/Makefile.msc
> gs/zlib/win32/README-WIN32.txt
> gs/zlib/win32/zlib.def
> gs/zlib/win32/zlib1.rc
> gs/zlib/zconf.h
> gs/zlib/zconf.h.cmakein
> gs/zlib/zconf.h.in
> gs/zlib/zlib.3
> gs/zlib/zlib.3.pdf
> gs/zlib/zlib.h
> gs/zlib/zlib.map
> gs/zlib/zutil.c
> gs/zlib/zutil.h

2015-05-12 18:02:02 +0100
Chris Liddell <chris.liddell@artifex.com>
26657b796bb6756bf5a907f1745efe1d325978e0

> Rename md5.c/h to gsmd5.c/h to avoid clashes.
> gs/base/gp_unix_cache.c
> gs/base/gsmd5.c
> gs/base/gsmd5.h
> gs/base/lib.mak
> gs/base/md5.c
> gs/base/md5.h
> gs/base/md5main.c
> gs/base/smd5.h
> gs/base/stdpre.h
> gs/base/unix-aux.mak
> gs/doc/Develop.htm
> gs/ghostscript.vcproj
> gs/ghostscript_rt.vcxproj

2015-05-12 16:21:25 +0100
Chris Liddell <chris.liddell@artifex.com>
66e29868f02aaaed1f4f751d41c3b4c4e2bf4399

> Update to libpng 1.6.17
> gs/libpng/ANNOUNCE
> gs/libpng/CHANGES
> gs/libpng/CMakeLists.txt
> gs/libpng/INSTALL
> gs/libpng/LICENSE
> gs/libpng/Makefile.am
> gs/libpng/Makefile.in
> gs/libpng/README
> gs/libpng/TODO
> gs/libpng/aclocal.m4
> gs/libpng/arm/arm_init.c
> gs/libpng/arm/filter_neon.S
> gs/libpng/arm/filter_neon_intrinsics.c
> gs/libpng/autogen.sh
> gs/libpng/compile
> gs/libpng/config.guess
> gs/libpng/config.h.in
> gs/libpng/config.sub
> gs/libpng/configure
> gs/libpng/configure.ac
> gs/libpng/contrib/arm-neon/README
> gs/libpng/contrib/arm-neon/android-ndk.c
> gs/libpng/contrib/arm-neon/linux-auxv.c
> gs/libpng/contrib/arm-neon/linux.c
> gs/libpng/contrib/conftest/README
> gs/libpng/contrib/conftest/read.dfa
> gs/libpng/contrib/conftest/s_read.dfa
> gs/libpng/contrib/conftest/s_write.dfa
> gs/libpng/contrib/conftest/simple.dfa
> gs/libpng/contrib/conftest/write.dfa
> gs/libpng/contrib/examples/iccfrompng.c
> gs/libpng/contrib/examples/pngpixel.c
> gs/libpng/contrib/gregbook/Makefile.mingw32
> gs/libpng/contrib/gregbook/Makefile.sgi
> gs/libpng/contrib/gregbook/Makefile.unx
> gs/libpng/contrib/gregbook/Makefile.w32
> gs/libpng/contrib/gregbook/readpng.c
> gs/libpng/contrib/gregbook/readpng2.c
> gs/libpng/contrib/gregbook/readppm.c
> gs/libpng/contrib/gregbook/rpng-x.c
> gs/libpng/contrib/gregbook/rpng2-win.c
> gs/libpng/contrib/gregbook/rpng2-x.c
> gs/libpng/contrib/gregbook/writepng.c
> gs/libpng/contrib/libtests/fakepng.c
> gs/libpng/contrib/libtests/pngimage.c
> gs/libpng/contrib/libtests/pngstest.c
> gs/libpng/contrib/libtests/pngunknown.c
> gs/libpng/contrib/libtests/pngvalid.c
> gs/libpng/contrib/libtests/timepng.c
> gs/libpng/contrib/pngminim/decoder/makefile
> gs/libpng/contrib/pngminim/decoder/pngusr.h
> gs/libpng/contrib/pngminim/encoder/makefile
> gs/libpng/contrib/pngminim/encoder/pngusr.dfa
> gs/libpng/contrib/pngminim/encoder/pngusr.h
> gs/libpng/contrib/pngminim/preader/makefile
> gs/libpng/contrib/pngminim/preader/pngusr.h
> gs/libpng/contrib/pngminus/makefile.std
> gs/libpng/contrib/pngminus/makefile.tc3
> gs/libpng/contrib/pngminus/png2pnm.bat
> gs/libpng/contrib/pngminus/png2pnm.c
> gs/libpng/contrib/pngminus/png2pnm.sh
> gs/libpng/contrib/pngminus/pngminus.bat
> gs/libpng/contrib/pngminus/pngminus.sh
> gs/libpng/contrib/pngminus/pnm2png.bat
> gs/libpng/contrib/pngminus/pnm2png.c
> gs/libpng/contrib/pngminus/pnm2png.sh
> gs/libpng/contrib/tools/fixitxt.c
> gs/libpng/contrib/tools/intgamma.sh
> gs/libpng/contrib/tools/png-fix-itxt.c
> gs/libpng/contrib/tools/pngfix.c
> gs/libpng/contrib/visupng/PngFile.c
> gs/libpng/depcomp
> gs/libpng/example.c
> gs/libpng/install-sh
> gs/libpng/libpng-manual.txt
> gs/libpng/libpng.3
> gs/libpng/libpngpf.3
> gs/libpng/ltmain.sh
> gs/libpng/missing
> gs/libpng/png.5
> gs/libpng/png.c
> gs/libpng/png.h
> gs/libpng/pngconf.h
> gs/libpng/pngdebug.h
> gs/libpng/pngerror.c
> gs/libpng/pngget.c
> gs/libpng/pnginfo.h
> gs/libpng/pngmem.c
> gs/libpng/pngpread.c
> gs/libpng/pngpriv.h
> gs/libpng/pngread.c
> gs/libpng/pngrio.c
> gs/libpng/pngrtran.c
> gs/libpng/pngrutil.c
> gs/libpng/pngset.c
> gs/libpng/pngstruct.h
> gs/libpng/pngtest.c
> gs/libpng/pngtrans.c
> gs/libpng/pngusr.dfa
> gs/libpng/pngwio.c
> gs/libpng/pngwrite.c
> gs/libpng/pngwtran.c
> gs/libpng/pngwutil.c
> gs/libpng/projects/vstudio/readme.txt
> gs/libpng/projects/vstudio/zlib.props
> gs/libpng/scripts/README.txt
> gs/libpng/scripts/def.c
> gs/libpng/scripts/def.dfn
> gs/libpng/scripts/descrip.mms
> gs/libpng/scripts/dfn.awk
> gs/libpng/scripts/intprefix.c
> gs/libpng/scripts/intprefix.dfn
> gs/libpng/scripts/libpng-config-body.in
> gs/libpng/scripts/libpng-config-head.in
> gs/libpng/scripts/libpng.pc.in
> gs/libpng/scripts/libtool.m4
> gs/libpng/scripts/ltoptions.m4
> gs/libpng/scripts/ltsugar.m4
> gs/libpng/scripts/ltversion.m4
> gs/libpng/scripts/lt~obsolete.m4
> gs/libpng/scripts/makefile.32sunu
> gs/libpng/scripts/makefile.64sunu
> gs/libpng/scripts/makefile.aix
> gs/libpng/scripts/makefile.amiga
> gs/libpng/scripts/makefile.atari
> gs/libpng/scripts/makefile.bc32
> gs/libpng/scripts/makefile.beos
> gs/libpng/scripts/makefile.bor
> gs/libpng/scripts/makefile.cegcc
> gs/libpng/scripts/makefile.darwin
> gs/libpng/scripts/makefile.dec
> gs/libpng/scripts/makefile.dj2
> gs/libpng/scripts/makefile.elf
> gs/libpng/scripts/makefile.freebsd
> gs/libpng/scripts/makefile.gcc
> gs/libpng/scripts/makefile.hp64
> gs/libpng/scripts/makefile.hpgcc
> gs/libpng/scripts/makefile.hpux
> gs/libpng/scripts/makefile.ibmc
> gs/libpng/scripts/makefile.intel
> gs/libpng/scripts/makefile.knr
> gs/libpng/scripts/makefile.linux
> gs/libpng/scripts/makefile.mips
> gs/libpng/scripts/makefile.msc
> gs/libpng/scripts/makefile.msys
> gs/libpng/scripts/makefile.ne12bsd
> gs/libpng/scripts/makefile.netbsd
> gs/libpng/scripts/makefile.openbsd
> gs/libpng/scripts/makefile.sco
> gs/libpng/scripts/makefile.sggcc
> gs/libpng/scripts/makefile.sgi
> gs/libpng/scripts/makefile.so9
> gs/libpng/scripts/makefile.solaris
> gs/libpng/scripts/makefile.solaris-x86
> gs/libpng/scripts/makefile.std
> gs/libpng/scripts/makefile.sunos
> gs/libpng/scripts/makefile.tc3
> gs/libpng/scripts/makefile.vcwin32
> gs/libpng/scripts/makevms.com
> gs/libpng/scripts/options.awk
> gs/libpng/scripts/pnglibconf.dfa
> gs/libpng/scripts/pnglibconf.h.prebuilt
> gs/libpng/scripts/pnglibconf.mak
> gs/libpng/scripts/prefix.c
> gs/libpng/scripts/prefix.dfn
> gs/libpng/scripts/sym.c
> gs/libpng/scripts/sym.dfn
> gs/libpng/scripts/symbols.c
> gs/libpng/scripts/symbols.def
> gs/libpng/scripts/symbols.dfn
> gs/libpng/scripts/vers.c
> gs/libpng/scripts/vers.dfn
> gs/libpng/test-driver
> gs/libpng/tests/pngimage-full
> gs/libpng/tests/pngimage-quick
> gs/libpng/tests/pngvalid-progressive-standard

2015-05-12 16:26:45 +0100
Chris Liddell <chris.liddell@artifex.com>
7274a44e2fda741572c815ef17298b7e37c96e7a

> Add freetype's configure script to our repo.
> Missed from previous commit.
> gs/freetype/configure

2015-05-07 15:48:47 +0100
Chris Liddell <chris.liddell@artifex.com>
9b6129c546bd924fb588219bc2d352ff44a79dd5

> Update freetype to 2.5.5 and tweak our makefile for it
> Bug 695774: Fallback for glyph with degenerate bbox
> (Re-applying after update to Freetype 2.5.5)
> If a glyph has only one very narrow feature, the bbox can end up with either
> the width or height of the bbox being 0, in which case no raster memory is
> allocated and no attempt is made to render the glyph. This is less than ideal
> when the drop-out compensation in the rendering code would actually result in
> the glyph being rendered.
> Normally the coordinates for the bbox are rounded (which is technically
> correct). Now, if that results in the width or height being 0, we'll
> then try explicitly rounding up/down, providing a sort of naive whole glyph
> drop-out compensation.
> The same change has been included upstream and will be in the next scheduled
> Freetype release:
> http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=942aa5ff
> This causes a large number of low resolution differences on cluster, all
> progressions where glyphs like dash ('-'), underscore ('_') and vertical
> bar ('|') were dropping out entirely, and are now printing.
> Revert to old Freetype CFF code
> (for now, at least)
> The new CFF code causes issues:
> Altona_Technical_1v1_x3.pdf - missing u-umlaut
> Bug687311.pdf - missing glyph
> Bug689516.pdf - extra ' glyph
> Bug690559.pdf - missing umlaut glyphs
> Bug691045.pdf- missing accent glyphs
> type2accent.pdf - missing accent glyphs
> z400454b01d4-1.pdf - content missing
> Fix and reenable new FT CFF code.
> 1) The incremental interface to Freetype requires the callback method to apply
> character code mapping via std encoding, rather it being applied internally
> in Freetype.
> submitted and applied upstream:
> http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=d65bf72
> 2) The VVCURVETO, HHCURVETO, VHCURVETO and HVCURVETO in the old CFF engine were
> tolerant of extra parameters on the stack, apply a similar thing in the
> new CFF code.
> submitted and applied upstream:
> http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=a87fb8cc
> gs/base/freetype.mak
> gs/freetype/CMakeLists.txt
> gs/freetype/ChangeLog
> gs/freetype/ChangeLog.21
> gs/freetype/ChangeLog.23
> gs/freetype/ChangeLog.24
> gs/freetype/Jamfile
> gs/freetype/README
> gs/freetype/README.git
> gs/freetype/autogen.sh
> gs/freetype/builds/amiga/README
> gs/freetype/builds/amiga/include/config/ftconfig.h
> gs/freetype/builds/amiga/include/config/ftmodule.h
> gs/freetype/builds/amiga/include/freetype/config/ftconfig.h
> gs/freetype/builds/amiga/include/freetype/config/ftmodule.h
> gs/freetype/builds/amiga/makefile
> gs/freetype/builds/amiga/makefile.os4
> gs/freetype/builds/amiga/smakefile
> gs/freetype/builds/amiga/src/base/ftdebug.c
> gs/freetype/builds/amiga/src/base/ftsystem.c
> gs/freetype/builds/atari/deflinejoiner.awk
> gs/freetype/builds/cmake/iOS.cmake
> gs/freetype/builds/compiler/bcc-dev.mk
> gs/freetype/builds/detect.mk
> gs/freetype/builds/dos/detect.mk
> gs/freetype/builds/exports.mk
> gs/freetype/builds/freetype.mk
> gs/freetype/builds/mac/README
> gs/freetype/builds/mac/freetype-Info.plist
> gs/freetype/builds/mac/ftmac.c
> gs/freetype/builds/modules.mk
> gs/freetype/builds/symbian/bld.inf
> gs/freetype/builds/toplevel.mk
> gs/freetype/builds/unix/aclocal.m4
> gs/freetype/builds/unix/config.guess
> gs/freetype/builds/unix/config.sub
> gs/freetype/builds/unix/configure
> gs/freetype/builds/unix/configure.ac
> gs/freetype/builds/unix/configure.raw
> gs/freetype/builds/unix/detect.mk
> gs/freetype/builds/unix/freetype-config.in
> gs/freetype/builds/unix/freetype2.in
> gs/freetype/builds/unix/freetype2.m4
> gs/freetype/builds/unix/ft2unix.h
> gs/freetype/builds/unix/ftconfig.in
> gs/freetype/builds/unix/ftsystem.c
> gs/freetype/builds/unix/install-sh
> gs/freetype/builds/unix/install.mk
> gs/freetype/builds/unix/ltmain.sh
> gs/freetype/builds/unix/pkg.m4
> gs/freetype/builds/unix/unix-def.in
> gs/freetype/builds/vms/ftconfig.h
> gs/freetype/builds/vms/ftsystem.c
> gs/freetype/builds/win32/detect.mk
> gs/freetype/builds/win32/ftdebug.c
> gs/freetype/builds/win32/vc2005/freetype.sln
> gs/freetype/builds/win32/vc2005/freetype.vcproj
> gs/freetype/builds/win32/vc2005/index.html
> gs/freetype/builds/win32/vc2008/freetype.sln
> gs/freetype/builds/win32/vc2008/freetype.vcproj
> gs/freetype/builds/win32/vc2008/index.html
> gs/freetype/builds/win32/vc2010/freetype.sln
> gs/freetype/builds/win32/vc2010/freetype.vcxproj
> gs/freetype/builds/win32/vc2010/freetype.vcxproj.filters
> gs/freetype/builds/win32/vc2010/index.html
> gs/freetype/builds/win32/visualc/freetype.dsp
> gs/freetype/builds/win32/visualc/freetype.dsw
> gs/freetype/builds/win32/visualc/freetype.sln
> gs/freetype/builds/win32/visualc/freetype.vcproj
> gs/freetype/builds/win32/visualc/index.html
> gs/freetype/builds/win32/visualce/freetype.dsp
> gs/freetype/builds/win32/visualce/freetype.dsw
> gs/freetype/builds/win32/visualce/freetype.vcproj
> gs/freetype/builds/win32/visualce/index.html
> gs/freetype/builds/win32/w32-bcc.mk
> gs/freetype/builds/win32/w32-bccd.mk
> gs/freetype/builds/win32/w32-dev.mk
> gs/freetype/builds/win32/w32-gcc.mk
> gs/freetype/builds/win32/w32-icc.mk
> gs/freetype/builds/win32/w32-intl.mk
> gs/freetype/builds/win32/w32-lcc.mk
> gs/freetype/builds/win32/w32-mingw32.mk
> gs/freetype/builds/win32/w32-vcc.mk
> gs/freetype/builds/win32/w32-wat.mk
> gs/freetype/builds/win32/win32-def.mk
> gs/freetype/builds/wince/ftdebug.c
> gs/freetype/builds/wince/vc2005-ce/freetype.vcproj
> gs/freetype/builds/wince/vc2005-ce/index.html
> gs/freetype/builds/wince/vc2008-ce/freetype.vcproj
> gs/freetype/builds/wince/vc2008-ce/index.html
> gs/freetype/builds/windows/detect.mk
> gs/freetype/builds/windows/ftdebug.c
> gs/freetype/builds/windows/vc2005/freetype.sln
> gs/freetype/builds/windows/vc2005/freetype.vcproj
> gs/freetype/builds/windows/vc2005/index.html
> gs/freetype/builds/windows/vc2008/freetype.sln
> gs/freetype/builds/windows/vc2008/freetype.vcproj
> gs/freetype/builds/windows/vc2008/index.html
> gs/freetype/builds/windows/vc2010/freetype.sln
> gs/freetype/builds/windows/vc2010/freetype.user.props
> gs/freetype/builds/windows/vc2010/freetype.vcxproj
> gs/freetype/builds/windows/vc2010/freetype.vcxproj.filters
> gs/freetype/builds/windows/vc2010/index.html
> gs/freetype/builds/windows/visualc/freetype.dsp
> gs/freetype/builds/windows/visualc/freetype.dsw
> gs/freetype/builds/windows/visualc/freetype.sln
> gs/freetype/builds/windows/visualc/freetype.vcproj
> gs/freetype/builds/windows/visualc/index.html
> gs/freetype/builds/windows/visualce/freetype.dsp
> gs/freetype/builds/windows/visualce/freetype.dsw
> gs/freetype/builds/windows/visualce/freetype.vcproj
> gs/freetype/builds/windows/visualce/index.html
> gs/freetype/builds/windows/w32-bcc.mk
> gs/freetype/builds/windows/w32-bccd.mk
> gs/freetype/builds/windows/w32-dev.mk
> gs/freetype/builds/windows/w32-gcc.mk
> gs/freetype/builds/windows/w32-icc.mk
> gs/freetype/builds/windows/w32-intl.mk
> gs/freetype/builds/windows/w32-lcc.mk
> gs/freetype/builds/windows/w32-mingw32.mk
> gs/freetype/builds/windows/w32-vcc.mk
> gs/freetype/builds/windows/w32-wat.mk
> gs/freetype/builds/windows/win32-def.mk
> gs/freetype/configure
> gs/freetype/devel/ft2build.h
> gs/freetype/devel/ftoption.h
> gs/freetype/docs/CHANGES
> gs/freetype/docs/CMAKE
> gs/freetype/docs/CUSTOMIZE
> gs/freetype/docs/DEBUG
> gs/freetype/docs/INSTALL
> gs/freetype/docs/INSTALL.ANY
> gs/freetype/docs/INSTALL.CROSS
> gs/freetype/docs/INSTALL.GNU
> gs/freetype/docs/INSTALL.UNIX
> gs/freetype/docs/LICENSE.TXT
> gs/freetype/docs/VERSION.DLL
> gs/freetype/docs/formats.txt
> gs/freetype/docs/freetype-config.1
> gs/freetype/docs/reference/ft2-auto_hinter.html
> gs/freetype/docs/reference/ft2-base_interface.html
> gs/freetype/docs/reference/ft2-basic_types.html
> gs/freetype/docs/reference/ft2-bdf_fonts.html
> gs/freetype/docs/reference/ft2-bitmap_handling.html
> gs/freetype/docs/reference/ft2-bzip2.html
> gs/freetype/docs/reference/ft2-cache_subsystem.html
> gs/freetype/docs/reference/ft2-cff_driver.html
> gs/freetype/docs/reference/ft2-cid_fonts.html
> gs/freetype/docs/reference/ft2-computations.html
> gs/freetype/docs/reference/ft2-font_formats.html
> gs/freetype/docs/reference/ft2-gasp_table.html
> gs/freetype/docs/reference/ft2-glyph_management.html
> gs/freetype/docs/reference/ft2-glyph_stroker.html
> gs/freetype/docs/reference/ft2-glyph_variants.html
> gs/freetype/docs/reference/ft2-gx_validation.html
> gs/freetype/docs/reference/ft2-gzip.html
> gs/freetype/docs/reference/ft2-header_file_macros.html
> gs/freetype/docs/reference/ft2-header_inclusion.html
> gs/freetype/docs/reference/ft2-incremental.html
> gs/freetype/docs/reference/ft2-index.html
> gs/freetype/docs/reference/ft2-lcd_filtering.html
> gs/freetype/docs/reference/ft2-list_processing.html
> gs/freetype/docs/reference/ft2-lzw.html
> gs/freetype/docs/reference/ft2-mac_specific.html
> gs/freetype/docs/reference/ft2-module_management.html
> gs/freetype/docs/reference/ft2-multiple_masters.html
> gs/freetype/docs/reference/ft2-ot_validation.html
> gs/freetype/docs/reference/ft2-outline_processing.html
> gs/freetype/docs/reference/ft2-pfr_fonts.html
> gs/freetype/docs/reference/ft2-quick_advance.html
> gs/freetype/docs/reference/ft2-raster.html
> gs/freetype/docs/reference/ft2-sfnt_names.html
> gs/freetype/docs/reference/ft2-sizes_management.html
> gs/freetype/docs/reference/ft2-system_interface.html
> gs/freetype/docs/reference/ft2-toc.html
> gs/freetype/docs/reference/ft2-truetype_engine.html
> gs/freetype/docs/reference/ft2-truetype_tables.html
> gs/freetype/docs/reference/ft2-tt_driver.html
> gs/freetype/docs/reference/ft2-type1_tables.html
> gs/freetype/docs/reference/ft2-user_allocation.html
> gs/freetype/docs/reference/ft2-version.html
> gs/freetype/docs/reference/ft2-winfnt_fonts.html
> gs/freetype/docs/release
> gs/freetype/include/config/ftconfig.h
> gs/freetype/include/config/ftheader.h
> gs/freetype/include/config/ftmodule.h
> gs/freetype/include/config/ftoption.h
> gs/freetype/include/config/ftstdlib.h
> gs/freetype/include/freetype.h
> gs/freetype/include/freetype/config/ftconfig.h
> gs/freetype/include/freetype/config/ftheader.h
> gs/freetype/include/freetype/config/ftmodule.h
> gs/freetype/include/freetype/config/ftoption.h
> gs/freetype/include/freetype/config/ftstdlib.h
> gs/freetype/include/freetype/freetype.h
> gs/freetype/include/freetype/ftadvanc.h
> gs/freetype/include/freetype/ftbbox.h
> gs/freetype/include/freetype/ftbdf.h
> gs/freetype/include/freetype/ftbitmap.h
> gs/freetype/include/freetype/ftbzip2.h
> gs/freetype/include/freetype/ftcache.h
> gs/freetype/include/freetype/ftchapters.h
> gs/freetype/include/freetype/ftcid.h
> gs/freetype/include/freetype/fterrdef.h
> gs/freetype/include/freetype/fterrors.h
> gs/freetype/include/freetype/ftgasp.h
> gs/freetype/include/freetype/ftglyph.h
> gs/freetype/include/freetype/ftgxval.h
> gs/freetype/include/freetype/ftgzip.h
> gs/freetype/include/freetype/ftimage.h
> gs/freetype/include/freetype/ftincrem.h
> gs/freetype/include/freetype/ftlcdfil.h
> gs/freetype/include/freetype/ftlist.h
> gs/freetype/include/freetype/ftlzw.h
> gs/freetype/include/freetype/ftmac.h
> gs/freetype/include/freetype/ftmm.h
> gs/freetype/include/freetype/ftmodapi.h
> gs/freetype/include/freetype/ftmoderr.h
> gs/freetype/include/freetype/ftotval.h
> gs/freetype/include/freetype/ftoutln.h
> gs/freetype/include/freetype/ftpfr.h
> gs/freetype/include/freetype/ftrender.h
> gs/freetype/include/freetype/ftsizes.h
> gs/freetype/include/freetype/ftsnames.h
> gs/freetype/include/freetype/ftstroke.h
> gs/freetype/include/freetype/ftsynth.h
> gs/freetype/include/freetype/ftsystem.h
> gs/freetype/include/freetype/fttrigon.h
> gs/freetype/include/freetype/fttypes.h
> gs/freetype/include/freetype/ftwinfnt.h
> gs/freetype/include/freetype/ftxf86.h
> gs/freetype/include/freetype/internal/autohint.h
> gs/freetype/include/freetype/internal/ftcalc.h
> gs/freetype/include/freetype/internal/ftdebug.h
> gs/freetype/include/freetype/internal/ftdriver.h
> gs/freetype/include/freetype/internal/ftgloadr.h
> gs/freetype/include/freetype/internal/ftmemory.h
> gs/freetype/include/freetype/internal/ftobjs.h
> gs/freetype/include/freetype/internal/ftpic.h
> gs/freetype/include/freetype/internal/ftrfork.h
> gs/freetype/include/freetype/internal/ftserv.h
> gs/freetype/include/freetype/internal/ftstream.h
> gs/freetype/include/freetype/internal/fttrace.h
> gs/freetype/include/freetype/internal/ftvalid.h
> gs/freetype/include/freetype/internal/internal.h
> gs/freetype/include/freetype/internal/psaux.h
> gs/freetype/include/freetype/internal/pshints.h
> gs/freetype/include/freetype/internal/services/svbdf.h
> gs/freetype/include/freetype/internal/services/svcid.h
> gs/freetype/include/freetype/internal/services/svgldict.h
> gs/freetype/include/freetype/internal/services/svgxval.h
> gs/freetype/include/freetype/internal/services/svkern.h
> gs/freetype/include/freetype/internal/services/svmm.h
> gs/freetype/include/freetype/internal/services/svotval.h
> gs/freetype/include/freetype/internal/services/svpfr.h
> gs/freetype/include/freetype/internal/services/svpostnm.h
> gs/freetype/include/freetype/internal/services/svpscmap.h
> gs/freetype/include/freetype/internal/services/svpsinfo.h
> gs/freetype/include/freetype/internal/services/svsfnt.h
> gs/freetype/include/freetype/internal/services/svttcmap.h
> gs/freetype/include/freetype/internal/services/svtteng.h
> gs/freetype/include/freetype/internal/services/svttglyf.h
> gs/freetype/include/freetype/internal/services/svwinfnt.h
> gs/freetype/include/freetype/internal/services/svxf86nm.h
> gs/freetype/include/freetype/internal/sfnt.h
> gs/freetype/include/freetype/internal/t1types.h
> gs/freetype/include/freetype/internal/tttypes.h
> gs/freetype/include/freetype/t1tables.h
> gs/freetype/include/freetype/ttnameid.h
> gs/freetype/include/freetype/tttables.h
> gs/freetype/include/freetype/tttags.h
> gs/freetype/include/freetype/ttunpat.h
> gs/freetype/include/ft2build.h
> gs/freetype/include/ftadvanc.h
> gs/freetype/include/ftautoh.h
> gs/freetype/include/ftbbox.h
> gs/freetype/include/ftbdf.h
> gs/freetype/include/ftbitmap.h
> gs/freetype/include/ftbzip2.h
> gs/freetype/include/ftcache.h
> gs/freetype/include/ftcffdrv.h
> gs/freetype/include/ftchapters.h
> gs/freetype/include/ftcid.h
> gs/freetype/include/fterrdef.h
> gs/freetype/include/fterrors.h
> gs/freetype/include/ftgasp.h
> gs/freetype/include/ftglyph.h
> gs/freetype/include/ftgxval.h
> gs/freetype/include/ftgzip.h
> gs/freetype/include/ftimage.h
> gs/freetype/include/ftincrem.h
> gs/freetype/include/ftlcdfil.h
> gs/freetype/include/ftlist.h
> gs/freetype/include/ftlzw.h
> gs/freetype/include/ftmac.h
> gs/freetype/include/ftmm.h
> gs/freetype/include/ftmodapi.h
> gs/freetype/include/ftmoderr.h
> gs/freetype/include/ftotval.h
> gs/freetype/include/ftoutln.h
> gs/freetype/include/ftpfr.h
> gs/freetype/include/ftrender.h
> gs/freetype/include/ftsizes.h
> gs/freetype/include/ftsnames.h
> gs/freetype/include/ftstroke.h
> gs/freetype/include/ftsynth.h
> gs/freetype/include/ftsystem.h
> gs/freetype/include/fttrigon.h
> gs/freetype/include/ftttdrv.h
> gs/freetype/include/fttypes.h
> gs/freetype/include/ftwinfnt.h
> gs/freetype/include/ftxf86.h
> gs/freetype/include/internal/autohint.h
> gs/freetype/include/internal/ftcalc.h
> gs/freetype/include/internal/ftdebug.h
> gs/freetype/include/internal/ftdriver.h
> gs/freetype/include/internal/ftgloadr.h
> gs/freetype/include/internal/ftmemory.h
> gs/freetype/include/internal/ftobjs.h
> gs/freetype/include/internal/ftpic.h
> gs/freetype/include/internal/ftrfork.h
> gs/freetype/include/internal/ftserv.h
> gs/freetype/include/internal/ftstream.h
> gs/freetype/include/internal/fttrace.h
> gs/freetype/include/internal/ftvalid.h
> gs/freetype/include/internal/internal.h
> gs/freetype/include/internal/psaux.h
> gs/freetype/include/internal/pshints.h
> gs/freetype/include/internal/services/svbdf.h
> gs/freetype/include/internal/services/svcid.h
> gs/freetype/include/internal/services/svgldict.h
> gs/freetype/include/internal/services/svgxval.h
> gs/freetype/include/internal/services/svkern.h
> gs/freetype/include/internal/services/svmm.h
> gs/freetype/include/internal/services/svotval.h
> gs/freetype/include/internal/services/svpfr.h
> gs/freetype/include/internal/services/svpostnm.h
> gs/freetype/include/internal/services/svprop.h
> gs/freetype/include/internal/services/svpscmap.h
> gs/freetype/include/internal/services/svpsinfo.h
> gs/freetype/include/internal/services/svsfnt.h
> gs/freetype/include/internal/services/svttcmap.h
> gs/freetype/include/internal/services/svtteng.h
> gs/freetype/include/internal/services/svttglyf.h
> gs/freetype/include/internal/services/svwinfnt.h
> gs/freetype/include/internal/services/svxf86nm.h
> gs/freetype/include/internal/sfnt.h
> gs/freetype/include/internal/t1types.h
> gs/freetype/include/internal/tttypes.h
> gs/freetype/include/t1tables.h
> gs/freetype/include/ttnameid.h
> gs/freetype/include/tttables.h
> gs/freetype/include/tttags.h
> gs/freetype/include/ttunpat.h
> gs/freetype/modules.cfg
> gs/freetype/src/Jamfile
> gs/freetype/src/autofit/afangles.c
> gs/freetype/src/autofit/afblue.c
> gs/freetype/src/autofit/afblue.cin
> gs/freetype/src/autofit/afblue.dat
> gs/freetype/src/autofit/afblue.h
> gs/freetype/src/autofit/afblue.hin
> gs/freetype/src/autofit/afcjk.c
> gs/freetype/src/autofit/afcjk.h
> gs/freetype/src/autofit/afcover.h
> gs/freetype/src/autofit/afdummy.c
> gs/freetype/src/autofit/afdummy.h
> gs/freetype/src/autofit/afglobal.c
> gs/freetype/src/autofit/afglobal.h
> gs/freetype/src/autofit/afhints.c
> gs/freetype/src/autofit/afhints.h
> gs/freetype/src/autofit/afindic.c
> gs/freetype/src/autofit/afindic.h
> gs/freetype/src/autofit/aflatin.c
> gs/freetype/src/autofit/aflatin.h
> gs/freetype/src/autofit/aflatin2.c
> gs/freetype/src/autofit/aflatin2.h
> gs/freetype/src/autofit/afloader.c
> gs/freetype/src/autofit/afloader.h
> gs/freetype/src/autofit/afmodule.c
> gs/freetype/src/autofit/afmodule.h
> gs/freetype/src/autofit/afpic.c
> gs/freetype/src/autofit/afpic.h
> gs/freetype/src/autofit/afranges.c
> gs/freetype/src/autofit/afranges.h
> gs/freetype/src/autofit/afscript.h
> gs/freetype/src/autofit/afstyles.h
> gs/freetype/src/autofit/aftypes.h
> gs/freetype/src/autofit/afwrtsys.h
> gs/freetype/src/autofit/autofit.c
> gs/freetype/src/autofit/hbshim.c
> gs/freetype/src/autofit/hbshim.h
> gs/freetype/src/autofit/rules.mk
> gs/freetype/src/base/basepic.c
> gs/freetype/src/base/basepic.h
> gs/freetype/src/base/ftadvanc.c
> gs/freetype/src/base/ftbbox.c
> gs/freetype/src/base/ftbdf.c
> gs/freetype/src/base/ftbitmap.c
> gs/freetype/src/base/ftcalc.c
> gs/freetype/src/base/ftcid.c
> gs/freetype/src/base/ftdbgmem.c
> gs/freetype/src/base/ftdebug.c
> gs/freetype/src/base/ftfstype.c
> gs/freetype/src/base/ftgloadr.c
> gs/freetype/src/base/ftglyph.c
> gs/freetype/src/base/ftgxval.c
> gs/freetype/src/base/ftinit.c
> gs/freetype/src/base/ftlcdfil.c
> gs/freetype/src/base/ftmac.c
> gs/freetype/src/base/ftmm.c
> gs/freetype/src/base/ftobjs.c
> gs/freetype/src/base/ftotval.c
> gs/freetype/src/base/ftoutln.c
> gs/freetype/src/base/ftpfr.c
> gs/freetype/src/base/ftpic.c
> gs/freetype/src/base/ftrfork.c
> gs/freetype/src/base/ftsnames.c
> gs/freetype/src/base/ftstream.c
> gs/freetype/src/base/ftstroke.c
> gs/freetype/src/base/ftsynth.c
> gs/freetype/src/base/ftsystem.c
> gs/freetype/src/base/fttrigon.c
> gs/freetype/src/base/fttype1.c
> gs/freetype/src/base/ftutil.c
> gs/freetype/src/base/ftwinfnt.c
> gs/freetype/src/base/md5.c
> gs/freetype/src/base/md5.h
> gs/freetype/src/base/rules.mk
> gs/freetype/src/bdf/bdfdrivr.c
> gs/freetype/src/bdf/bdflib.c
> gs/freetype/src/bzip2/ftbzip2.c
> gs/freetype/src/cache/Jamfile
> gs/freetype/src/cache/ftcbasic.c
> gs/freetype/src/cache/ftccache.c
> gs/freetype/src/cache/ftccache.h
> gs/freetype/src/cache/ftccback.h
> gs/freetype/src/cache/ftccmap.c
> gs/freetype/src/cache/ftcmanag.c
> gs/freetype/src/cache/ftcmanag.h
> gs/freetype/src/cache/ftcmru.h
> gs/freetype/src/cache/ftcsbits.c
> gs/freetype/src/cff/cf2arrst.c
> gs/freetype/src/cff/cf2arrst.h
> gs/freetype/src/cff/cf2blues.c
> gs/freetype/src/cff/cf2blues.h
> gs/freetype/src/cff/cf2error.c
> gs/freetype/src/cff/cf2error.h
> gs/freetype/src/cff/cf2fixed.h
> gs/freetype/src/cff/cf2font.c
> gs/freetype/src/cff/cf2font.h
> gs/freetype/src/cff/cf2ft.c
> gs/freetype/src/cff/cf2ft.h
> gs/freetype/src/cff/cf2glue.h
> gs/freetype/src/cff/cf2hints.c
> gs/freetype/src/cff/cf2hints.h
> gs/freetype/src/cff/cf2intrp.c
> gs/freetype/src/cff/cf2intrp.h
> gs/freetype/src/cff/cf2read.c
> gs/freetype/src/cff/cf2read.h
> gs/freetype/src/cff/cf2stack.c
> gs/freetype/src/cff/cf2stack.h
> gs/freetype/src/cff/cf2types.h
> gs/freetype/src/cff/cff.c
> gs/freetype/src/cff/cffcmap.c
> gs/freetype/src/cff/cffdrivr.c
> gs/freetype/src/cff/cffgload.c
> gs/freetype/src/cff/cffgload.h
> gs/freetype/src/cff/cffload.c
> gs/freetype/src/cff/cffobjs.c
> gs/freetype/src/cff/cffobjs.h
> gs/freetype/src/cff/cffparse.c
> gs/freetype/src/cff/cffpic.c
> gs/freetype/src/cff/cffpic.h
> gs/freetype/src/cff/cfftypes.h
> gs/freetype/src/cff/rules.mk
> gs/freetype/src/cid/cidgload.c
> gs/freetype/src/cid/cidload.c
> gs/freetype/src/cid/cidobjs.c
> gs/freetype/src/cid/cidparse.c
> gs/freetype/src/cid/cidparse.h
> gs/freetype/src/cid/cidriver.c
> gs/freetype/src/gxvalid/gxvbsln.c
> gs/freetype/src/gxvalid/gxvcommn.c
> gs/freetype/src/gxvalid/gxvcommn.h
> gs/freetype/src/gxvalid/gxverror.h
> gs/freetype/src/gxvalid/gxvfeat.c
> gs/freetype/src/gxvalid/gxvjust.c
> gs/freetype/src/gxvalid/gxvkern.c
> gs/freetype/src/gxvalid/gxvlcar.c
> gs/freetype/src/gxvalid/gxvmod.c
> gs/freetype/src/gxvalid/gxvmort.c
> gs/freetype/src/gxvalid/gxvmort.h
> gs/freetype/src/gxvalid/gxvmort0.c
> gs/freetype/src/gxvalid/gxvmort1.c
> gs/freetype/src/gxvalid/gxvmort2.c
> gs/freetype/src/gxvalid/gxvmort4.c
> gs/freetype/src/gxvalid/gxvmort5.c
> gs/freetype/src/gxvalid/gxvmorx.c
> gs/freetype/src/gxvalid/gxvmorx.h
> gs/freetype/src/gxvalid/gxvmorx0.c
> gs/freetype/src/gxvalid/gxvmorx1.c
> gs/freetype/src/gxvalid/gxvmorx2.c
> gs/freetype/src/gxvalid/gxvmorx4.c
> gs/freetype/src/gxvalid/gxvmorx5.c
> gs/freetype/src/gxvalid/gxvopbd.c
> gs/freetype/src/gxvalid/gxvprop.c
> gs/freetype/src/gxvalid/gxvtrak.c
> gs/freetype/src/gzip/adler32.c
> gs/freetype/src/gzip/ftgzip.c
> gs/freetype/src/gzip/inftrees.c
> gs/freetype/src/gzip/rules.mk
> gs/freetype/src/gzip/zconf.h
> gs/freetype/src/gzip/zutil.c
> gs/freetype/src/gzip/zutil.h
> gs/freetype/src/lzw/ftlzw.c
> gs/freetype/src/lzw/ftzopen.h
> gs/freetype/src/otvalid/otvbase.c
> gs/freetype/src/otvalid/otvcommn.c
> gs/freetype/src/otvalid/otvcommn.h
> gs/freetype/src/otvalid/otverror.h
> gs/freetype/src/otvalid/otvgdef.c
> gs/freetype/src/otvalid/otvgpos.c
> gs/freetype/src/otvalid/otvgsub.c
> gs/freetype/src/otvalid/otvjstf.c
> gs/freetype/src/otvalid/otvmath.c
> gs/freetype/src/otvalid/otvmod.c
> gs/freetype/src/pcf/README
> gs/freetype/src/pcf/pcfdrivr.c
> gs/freetype/src/pcf/pcfread.c
> gs/freetype/src/pcf/pcfutil.c
> gs/freetype/src/pfr/pfrcmap.c
> gs/freetype/src/pfr/pfrdrivr.c
> gs/freetype/src/pfr/pfrgload.c
> gs/freetype/src/pfr/pfrload.c
> gs/freetype/src/pfr/pfrobjs.c
> gs/freetype/src/pfr/pfrsbit.c
> gs/freetype/src/psaux/afmparse.c
> gs/freetype/src/psaux/psconv.c
> gs/freetype/src/psaux/psconv.h
> gs/freetype/src/psaux/psobjs.c
> gs/freetype/src/psaux/t1cmap.c
> gs/freetype/src/psaux/t1decode.c
> gs/freetype/src/pshinter/pshalgo.c
> gs/freetype/src/pshinter/pshalgo.h
> gs/freetype/src/pshinter/pshglob.c
> gs/freetype/src/pshinter/pshglob.h
> gs/freetype/src/pshinter/pshmod.c
> gs/freetype/src/pshinter/pshpic.c
> gs/freetype/src/pshinter/pshpic.h
> gs/freetype/src/pshinter/pshrec.c
> gs/freetype/src/pshinter/pshrec.h
> gs/freetype/src/psnames/psmodule.c
> gs/freetype/src/psnames/pspic.c
> gs/freetype/src/psnames/pspic.h
> gs/freetype/src/psnames/rules.mk
> gs/freetype/src/raster/ftmisc.h
> gs/freetype/src/raster/ftraster.c
> gs/freetype/src/raster/ftrend1.c
> gs/freetype/src/raster/rastpic.c
> gs/freetype/src/raster/rastpic.h
> gs/freetype/src/sfnt/pngshim.c
> gs/freetype/src/sfnt/pngshim.h
> gs/freetype/src/sfnt/rules.mk
> gs/freetype/src/sfnt/sfdriver.c
> gs/freetype/src/sfnt/sferrors.h
> gs/freetype/src/sfnt/sfnt.c
> gs/freetype/src/sfnt/sfntpic.c
> gs/freetype/src/sfnt/sfntpic.h
> gs/freetype/src/sfnt/sfobjs.c
> gs/freetype/src/sfnt/ttbdf.c
> gs/freetype/src/sfnt/ttcmap.c
> gs/freetype/src/sfnt/ttcmap.h
> gs/freetype/src/sfnt/ttcmapc.h
> gs/freetype/src/sfnt/ttkern.c
> gs/freetype/src/sfnt/ttload.c
> gs/freetype/src/sfnt/ttmtx.c
> gs/freetype/src/sfnt/ttmtx.h
> gs/freetype/src/sfnt/ttpost.c
> gs/freetype/src/sfnt/ttsbit.c
> gs/freetype/src/sfnt/ttsbit.h
> gs/freetype/src/sfnt/ttsbit0.c
> gs/freetype/src/smooth/ftgrays.c
> gs/freetype/src/smooth/ftsmooth.c
> gs/freetype/src/smooth/ftspic.c
> gs/freetype/src/smooth/ftspic.h
> gs/freetype/src/tools/afblue.pl
> gs/freetype/src/tools/apinames.c
> gs/freetype/src/tools/chktrcmp.py
> gs/freetype/src/tools/cordic.py
> gs/freetype/src/tools/docmaker/content.py
> gs/freetype/src/tools/docmaker/docmaker.py
> gs/freetype/src/tools/docmaker/formatter.py
> gs/freetype/src/tools/docmaker/sources.py
> gs/freetype/src/tools/docmaker/tohtml.py
> gs/freetype/src/tools/docmaker/utils.py
> gs/freetype/src/tools/ftrandom/README
> gs/freetype/src/tools/ftrandom/ftrandom.c
> gs/freetype/src/tools/test_afm.c
> gs/freetype/src/tools/test_bbox.c
> gs/freetype/src/tools/test_trig.c
> gs/freetype/src/truetype/rules.mk
> gs/freetype/src/truetype/truetype.c
> gs/freetype/src/truetype/ttdriver.c
> gs/freetype/src/truetype/ttgload.c
> gs/freetype/src/truetype/ttgload.h
> gs/freetype/src/truetype/ttgxvar.c
> gs/freetype/src/truetype/ttinterp.c
> gs/freetype/src/truetype/ttinterp.h
> gs/freetype/src/truetype/ttobjs.c
> gs/freetype/src/truetype/ttobjs.h
> gs/freetype/src/truetype/ttpic.c
> gs/freetype/src/truetype/ttpic.h
> gs/freetype/src/truetype/ttpload.c
> gs/freetype/src/truetype/ttsubpix.c
> gs/freetype/src/truetype/ttsubpix.h
> gs/freetype/src/type1/t1afm.c
> gs/freetype/src/type1/t1driver.c
> gs/freetype/src/type1/t1gload.c
> gs/freetype/src/type1/t1load.c
> gs/freetype/src/type1/t1objs.c
> gs/freetype/src/type1/t1parse.c
> gs/freetype/src/type42/t42drivr.c
> gs/freetype/src/type42/t42objs.c
> gs/freetype/src/type42/t42parse.c
> gs/freetype/src/winfonts/winfnt.c
> gs/freetype/vms_make.com

2015-05-05 12:33:16 +0100
Chris Liddell <chris.liddell@artifex.com>
28876fa00c5a325a6b3ad2e768375f203d060aaf

> Improve efficiency of pdf_info.ps
> Original, pdf_info.ps would loop to retrieve each page of a PDF, emit its
> media information. Then, in a second loop, it would retrieve each page, and
> emit its font information.
> This change means it will loop only once, retrieving each page only once, and
> using the same page dictionary object for both media information and fonts used.
> This *should* improve the speed on very large PDF files.
> No cluster differences.
> gs/toolbin/pdf_info.ps

2015-05-11 09:57:01 -0700
Michael Vrhel <michael.vrhel@artifex.com>
8117f3e31575a08451d0e8a1b9c251ffbef047a8

> Non-Isolated transparency groups should ignore CS entry
> If a transparency group is not isolated the blending color
> space for the group is inherited from the parent group.
> This is a partial fix for the issues seen in Bug 695930.
> In particular the issues seen with the letter D.
> gs/base/gstrans.c

2015-04-30 15:06:06 +0100
Chris Liddell <chris.liddell@artifex.com>
0f3691890027236e3c7b34317426b913f62288dc

> Bug 695972: always use a square scaling for glyphs
> We're seeing Truetype fonts whose hinting programs do not work correctly with
> certain, non-square scalings. So ensure that the scale we pass to Freetype
> is equal in in width and height, then apply the non-square part in the final,
> output matrix (along with non-square resolution scaling, and shearing etc).
> This causes quite a lot of cluster differences, due to rounding changes.
> gs/base/fapi_ft.c

2015-05-02 19:49:34 +0100
Robin Watts <robin.watts@artifex.com>
b34e6835e6e918dfca8c6558fe00eedcca6660c5

> Fix error in gsapi; gsapi_run_string is broken.
> gsapi_run_string calls through to gsapi_run_string_with_length
> with the first argument converted from a gs_lib_ctx_t * to a void *.
> gsapi_run_string_with_length then performs this conversion again.
> This will lead to a SEGV.
> The fix is not to do this dereference.
> Wouldn't it be better if we used types here rather than void *'s?
> gs/psi/iapi.c

2015-04-27 10:11:22 -0600
Henry Stiles <henry.stiles@artifex.com>
505601bd6ee848be2aff84d264ae9583ae96c64a

> Fix Bug #695951 Portion of page cut off.
> Implement the PJL command EDGETOEDGE, not only does this enable full
> bleed but it also shifts the logical page to the left allowing printing
> of graphics that would have been clipped because they extended past the
> physical page edge.
> pcl/pcpage.c
> pl/pjparse.c

2015-04-15 14:33:18 -0700
Ray Johnston <ray.johnston@artifex.com>
b742626e8ec7d976535395316f7986097982b73b

> Use the Windows "QueryPerformanceCounter" high res timer for usertime.
> The gp_get_realtime is OK, but for gp_get_usertime from C it is handy
> to have better resolution. Also use this for the -Z: output from the
> print_resource_usage function. NB the functions were always defined
> as returning seconds and nanoseconds.
> gs/base/gp_win32.c
> gs/psi/imain.c

2015-04-22 16:44:37 -0700
Ray Johnston <ray.johnston@artifex.com>
53cb4209b397c9e8121aeec31607cbfb53622f20

> Fix for file BFAZSLPD.pdf JPX image uses Lab colorspace.
> The jp2_csp_dict definitiion for the basic Lab colorspace for a JPX
> encoded image was (1) not an array with a dict as the second element
> as required by the PDF parser, and (2) the dict must have a WhitePoint
> array (required per the PDF spec).
> gs/Resource/Init/pdf_draw.ps

2015-04-17 14:24:35 +0100
Chris Liddell <chris.liddell@artifex.com>
d56cdfd63c26a29d118f570d1b37d32214834c78

> Remove -Werror=return-type for builds with UFST
> Some UFST versions will fail to build with -Werror=return-type, so when
> building with UFST, strip that option from the compiler flags.
> No cluster differences.
> configure.ac
> gs/configure.ac

2015-04-21 12:18:45 +0100
Chris Liddell <chris.liddell@artifex.com>
3b174bb21edd57fb53914d3fea3c202f9e41d4a3

> Remove a now superfluous assignment to NULL.
> The previous commit changed pdf14_free_mask_stack() so it would set the
> pdf14 context "mask_stack" pointer to NULL after freeing the memory, so
> there's now no requirement for the calling code to do so.
> No cluster differences
> gs/base/gdevp14.c

2015-04-21 12:00:29 +0100
Chris Liddell <chris.liddell@artifex.com>
e895599e66cc174b2d7a2740e747f05589836546

> Bug 695952: avoid double free of mask_stack.
> The pdf14 context "mask_stack" could end up being freed twice, once by
> pdf14_free_mask_stack() and then again explicitly.
> This commit removes the erroneous free, but I also opted to change
> pdf14_free_mask_stack() so it takes the pdf14 context pointer (rather than
> just the "mask_stack" pointer) which means it can set the pointer to NULL as
> well as freeing it, which is safer for the error handling case.
> No cluster differences.
> gs/base/gdevp14.c

2015-04-21 10:33:40 +0100
Ken Sharp <ken.sharp@artifex.com>
30fde04cca068e34cc64f3656d7eefc50a8316d7

> PDF Interpreter - validate and clamp arguments to Td
> Bug #695950 "Incomplete rendering of PDF file"
> As usual an invalid PDF file. In this case the PDF file contains an argument
> to Td which is 1.5090553259294607 x 10^258. Typical implementation limits
> in Appendix C of the PDF Reference limit reals to 3.403x10^38
> GS returns the value as -infinity, it appears Acrobat clamps these out of range
> values to 0 (at least for the Td operator)
> This commit checks the arguments against 2^32 as checking against the full
> range permitted for reals would be slightly more difficult, and its unlikely
> that a real file would use arguments larger than this anyway. If any argument
> is out of range it gets clamped to 0.
> No differences expected.
> gs/Resource/Init/pdf_ops.ps

2015-04-18 17:52:27 +0100
Chris Liddell <chris.liddell@artifex.com>
e2f65f3e0087442caf6d657f238e50ce87403988

> Bug 695934: Fix a typo in Type 1 font bounds checking.
> When I added some stack bounds checking to the Type 1 charstring code, I
> mistakenly used a value for subrs in the gsubrs section, this could lead to
> stack corruption and a subsequent segfault.
> No cluster differences.
> gs/base/gxtype1.c

2015-04-17 12:19:26 +0100
Chris Liddell <chris.liddell@artifex.com>
b3fc1892747bba78cc2dcc8181803bf5dc4b6a5d

> Bug 695890: Update jbig2dec for modern libpng
> libpng 1.5.x and newer hide the internals, and only allow values to be set and
> retrieved via define API calls.
> Also tidy up a couple of (benign) compiler warnings.
> No cluster diffs.
> gs/jbig2dec/jbig2_arith.c
> gs/jbig2dec/jbig2_image_pbm.c
> gs/jbig2dec/jbig2_image_png.c
> gs/jbig2dec/jbig2_refinement.c
> gs/jbig2dec/jbig2_text.c

2015-04-16 15:28:58 +0100
Chris Liddell <chris.liddell@artifex.com>
5d87a9ba906ad303abdd487a719cc966e857c198

> Tweak FAPI code for server search.
> If we have multiple FAPI "servers" (i.e. font renderers) we cycle through them
> testing if they can handle a particular font. To indicate it cannot, a server
> will return an invalidaccess error, which we were erroneously returning to the
> interpreter.
> Now keep searching on an invalidaccess.
> No cluster differences.
> gs/psi/zfapi.c

2015-04-16 15:26:20 +0100
Ken Sharp <ken.sharp@artifex.com>
6d1bde2bad1afeb610735f7ea53cabd7d3120fbe

> PDF interpreter - additional debugging option
> Added a 'stdoutprint' to go along with stderrprint, this allows us to
> have the 'pdfformaterror' and other informative messages sent to stdout
> instead of stderr.
> When capturing stdout and stderr for debugging purposes it can be useful to
> have the logging/debug messages go to the same place as the error messages
> in order that they are captured properly 'interleaved'.
> gs/Resource/Init/pdf_main.ps

2015-04-15 17:19:07 +0100
Ken Sharp <ken.sharp@artifex.com>
4dce3f3cb2ece5795312a85c5ac2693ff8293169

> pdfwrite - Pay attention to /MediaBox pdfmarks
> Previously we always emitted a /MediaBox for each page based only on the
> PostScript media size, even if we had a /MediaBox /Page pdfmark.
> This in itself is incorrect, but worse we would then emit the MediaBox from
> the /Page pdfmark as well, leading to a dictionary with duplicate keys....
> This commit will use any /MediaBox /Page pdfmark in preference to any PostScript
> media settings, though it will default to those if no such pdfmark is sent.
> This exhibits a difference in Bug692502.eps because this file (uniquely in
> our test suite it seems) does emit a /MediaBox /Page pdfmark, which is
> different to the media we use in PostScript. Previously it was incorrect,
> now it is correct, or at least we honour the pdfmark now.....
> gs/devices/vector/gdevpdf.c

2015-04-10 11:47:13 -0700
Michael Vrhel <michael.vrhel@artifex.com>
e8142ce7390e2686456894a602df07d8de16a7c7

> Fix for bug 695916. Simulated overprint blending of spots colors issue
> For non separation devices, we had attempted to simulate the overprint effect of spot colors
> that are not CMYK values. This was set up by default, and could be turned on/off
> with -dSimulateOverprint = true/false. Looking over the method used to
> simulate the colors, it was clear that there were issues and that a completely
> different approach is needed. To do proper spot color overprinting simulation
> will require buffers for each of the spot colorants. The plan is to
> achieve this through the use of the pdf14 device and setting it up in
> a manner similar to how it is set up when the target device is a separation
> device. The colorants will then be collapsed to the device's real color
> space when the pdf14 put image occurs. For now, this commit disables the
> blending approach, which did not work in every case, fixing the customers issue
> with this file.
> gs/base/gdevp14.c
> gs/base/gsdparam.c
> gs/base/gsicc_manage.c
> gs/base/gsovrc.c
> gs/base/gsstate.c
> gs/base/gxblend1.c
> gs/base/gxoprect.c

2015-04-09 10:43:21 -0700
Ray Johnston <ray.johnston@artifex.com>
64188c8e3615de788ad916b7d14e24e98d9c289c

> Fix Bug 695904, Transparency with non-identity transfer functions.
> This does _not_ yet implement the arcane transfer function handling of
> section 7.6.4 of the PDF 1.7 Reference Manual, but it fixes a problem
> detected by customer 532 who uses a transfer function set by PS before
> the PDF file runs. This was causing bands in part of the image.
> The problem was that the pdf14 compositor was not applying the transfer
> function for monochrome or indexed color images, and did apply it for
> color images or when the halftone thresholding was done during image
> processing. The transfer function was then applied during pdf14_put_image
> only when the default method of passing the image to the device was
> used (not when the device implemented a put_image proc, as the customer's
> code does for efficiency). If color images had the transfer function
> applied, then the put_image would apply it a second time.
> For bands that had the pdf14 compositor skipped because transparency
> was not needed, the transfer function was applied correctly, causing
> differences on transitions to bands that used the pdf14 compositor.
> The fix applies the transfer function in the pdf14 cmap procs and does
> _not_ apply it during pdf14_put_image, which also makes it consistent
> with devices that implement a put_image proc and do not have the pis
> or any way to get the transfer function.
> gs/Resource/Init/pdf_main.ps
> gs/base/gdevp14.c

2015-04-09 10:41:05 +0100
Ken Sharp <ken.sharp@artifex.com>
f143277e868a37d7154c64408c0cc9b30c4fdb9d

> txtwrite - Be careful not to handle strinwidth operations as text
> Bug #695914 "txtwrite command is different then Adobe save as other tool"
> If we have a CIDFont with a descendant, and the descendant is not present,
> and we substitute with a type 1 font, then when we do a stringwidth the
> txtwrite code could throw an error (no current point) if the text was the
> first element on the page.
> This would then throw the font handling off, and we would get the text as
> being in a type 1 font, instead of a type 0 font, which meant that the text
> output was incorrect, even when a ToUnicode CMap was present.
> We can deal with this easily by copying the approach from pdfwrite, if its
> a stringwidth let the graphics library deal with it.
> No differences in cluster, we don't test txtwrite
> gs/devices/vector/gdevtxtw.c

2015-04-08 17:04:05 +0100
Ken Sharp <ken.sharp@artifex.com>
35f03f7dfdbd7aa834e5c283a24cad48184f7a27

> eps2write - Use an improved approach to getting the BBox of filled paths
> Bug #695910 "Error reading a content stream" when using device eps2write by GhostScript 9.16 "
> The eps2write device, unlike other devices, needs a 'page' bounding box and
> so often 'renders' content where the other high level devices don't. In
> general this works because we degenerate to low level operations, which are
> then filtered by the eps2write device and used to calculate the BBox.
> Unfortunately for pattern fills this doesn't work, as we check the pattern
> tile boundaries, and because we aren't really rendering these are 0. This
> causes an 'unregistered' error.
> This commit alters the way we calculate filled path BBoxes, instead of
> rendering to low level objects, we take advantage of the code to calculate
> the bounding box of a path, intersect that with the current clip path's
> outer bounding box, and use that as the BBox of the path. Because we only
> case about maxima and minima this is sufficient, we don't have to worry
> about all the nooks and crannies potentially present in the path.
> We do have to watch out for a degenerate path or bbox though, and not take
> that into account.
> This commit also does a couple of casts, just to eliminate a compiler warning.
> No differences expected.
> gs/devices/vector/gdevpdfd.c

2015-04-07 13:26:54 +0100
Chris Liddell <chris.liddell@artifex.com>
f63ac1a69b1bec4c97d032b69c61bcadeb69902f

> Up version number to 9.18
> gs/Resource/Init/gs_init.ps
> gs/base/version.mak

2015-04-07 16:40:04 +0100
Ken Sharp <ken.sharp@artifex.com>
d82053315ada259dfccaabdc41fbbaab50df46a1

> PDF interpreter - attempt to recover from broken, linearised, PDF file
> Bug #695619 "mupdf cannot load page with a special PDF file"
> The 'special' PDF file is in fact a totally broken PDF file, caused by
> concatenating a regular PDF file with a linearised PDF file. We detect the
> fact that the xref is not where the Linearised file says it is, and attempt
> to recover, but fail because the trailer dictionary we find is for the
> linearised file, and so does not contain a Root object. Without that we
> cannot decipher the file.
> We could attempt to find a 'Linearised' key, but instead I've opted to
> search backwards through the file looking for a previous trailer dictionary
> until we find one that has a Root key, or fail altogether to locate one. If
> we find eon we proceed as before, if we fail to find a trailer with a Root
> key we fail altogether, there's not much else we can do.
> Note that depending how ones chooses to 'recover' from this broken PDF file
> could potentially determine *which* of the 2 PDF files present actually
> gets interpreted. We match Acrobat in this case, I won't guarantee we will
> do so in every case.
> No differences expected.
> gs/Resource/Init/pdf_rbld.ps

2015-04-06 21:43:55 +0100
Chris Liddell <chris.liddell@artifex.com>
22573c9d775a7a56449d601e0bbc951c2b325f16

> Bug 695905: reoder tests to prevent seg fault.
> We should check the pointer is not null *before* trying to strcmp it.
> No cluster differences.
> gs/devices/vector/gdevpsdp.c

2015-04-02 16:18:34 +0100
Chris Liddell <chris.liddell@artifex.com>
e136d916239917c9224ebba180cb12329271a597

> Fix a couple of minor typos and out of dates
> relating to cidfmap.
> gs/Resource/Init/cidfmap
> gs/doc/Use.htm

2015-04-02 12:14:24 +0100
Chris Liddell <chris.liddell@artifex.com>
ad0c3d1a9f4f209aefa4414b8073e42cd440edd5

> Tidy jbig2dec build configuration:
> 1) Remove automake version specific tests/use
> The script does unpleasant things which can cause us to attempt to use a
> specific version of automake, which should not really be needed these days.
> So we now just check that the automake version is greater than or equal to the
> version we require.
> The old method can still be accessed by invoking autogen.sh thus:
> USE_OLD=yes ./autogen.sh
> 2) Add automake option to make dist "self contained"
> The automake default is to symlink to a few scripts ('compile', 'missing' etc)
> in the current system's automake install. That results in a configuration
> reliant on automake being installed, and the same version, for a build.
> Add the '--copy' automake option so the script files are copied rather than
> linked, so we get a self contained configure/make/install setup.
> No cluster differences.
> gs/ijs/autogen.sh
> gs/jbig2dec/autogen.sh

2015-04-06 11:59:15 +0100
Ken Sharp <ken.sharp@artifex.com>
54f502f35b12fd889a47e048b15d92bd8ca66d55

> PDF Interpreter - work around non-text operations inside a text block
> Bug #695897 "Text missing reading PDF file"
> In addition to nesting text block inside one another, the test file also
> executes a 'Do' (draw image) operator inside a text block. This is also
> illegal, except in the context of type character descriptions, or pattern
> fills of text, or similar.
> This commit slightly modifies the previous one (7bc2078) by copying the
> TextSaveMatrix, instead of simply referencing it, when we execute a gsave
> inside a text block. We can then safely modify the copied array whenever
> a 'cm' operation takes place (just as we already did for TextSaveMatrix),
> finally we can check for TextSaveMatrix or qTextSaveMatrix being present
> when we execute a non-text operation. If this occurs (so far only Do tests
> this) then we save the graphics state (so we don't disturb any following text)
> return to the 'TextSaveMatrix', perform the operation and then restore the
> graphics state.
> It should be emphasised that this file is badly broken, both nested text blocks
> and non-text operations inside text blocks are specifically forbidden in the
> PDF reference. So the warning messages emitted when this occurs have been
> extended slightly.
> No differences expected
> gs/Resource/Init/pdf_draw.ps
> gs/Resource/Init/pdf_ops.ps

2015-04-04 09:35:23 +0100
Ken Sharp <ken.sharp@artifex.com>
76c20780b2148e56ffcb6944d910d5a04f4f96a9

> PDF Inerpreter - work around illegally nested BT blocks
> Bug #695897 "Text missing reading PDF file"
> There are actually 2 problems with this file, this is the first fix. The
> file contains nested text blocks, quite a few of them, in direct contravention
> of the PDF specification.
> We already have code to detect this, but it relies on a specific key being
> present in the current dictionary to detect the condition. Sadly this file
> executes the nested blocks inside a q/Q pair as well, and the way the PDF
> interpreter deals with a q means that we start a new, empty, dictionary
> which neatly prevents us detecting this.
> The nasty hack here introduces a new key 'qTextSaveMatrix' in the dictionary
> created by a 'q' operator, *if* the current dictionary has a TextSaveMatrix
> key present. We then add detection of the qTextSaveMatrix key to the BT
> operator in exactly the same way as the existing TextSaveMatrx.
> Attempts to have the TextSaveMatrix copied and used, so that the CTM would
> follow the nesting simply didn't work, leading to the key being present
> when it shouldn't be, or not present when it should, or having the wrong
> value. The only 'correct' way to deal with this illegal file is to separate
> the Text Matrix out from the CTM and track changes to it as required. This
> would mean rewriting large parts of the PDF interpreter which I don;t think
> is reasonable to cope with an invalid file.
> The second problem will be the subject of another commit.
> No differences expected.
> gs/Resource/Init/pdf_ops.ps

2015-04-01 16:36:18 -0700
Ray Johnston <ray.johnston@artifex.com>
29cc06bfced3b06b55bed829ce314273461b21e5

> Clean up assumption that gs_no_id is "false"
> gs/base/gxclpath.c

2015-04-02 08:42:11 +0100
Chris Liddell <chris.liddell@artifex.com>
f1d98961fe65d8b0964ab93040d995d5463a43d8

> Remove spurious debug code.
> No cluster diffs
> gs/Resource/Init/pdf_ops.ps

2015-03-30 22:31:57 +0100
Chris Liddell <chris.liddell@artifex.com>
30c7475eee24393f454368b998980afbae89e542

> Fix a (rather unfortunate) typo in some debug code.
> No cluster differences.
> gs/toolbin/headers.tcl

2015-04-01 15:50:02 -0600
Henry Stiles <henry.stiles@artifex.com>
8dc207fec1341fa844bc7ae578eb37a8d0267087

> Fix bug 695867, incorrect cursor position.
> The current user space position was not being maintained by the HPGL IR
> command. This is fairly rare and we haven't seen it in our tests,
> HPGL's SC (scale), IP (Input P1 and P2) and IR (Input Relative P1 and
> P2) are used to set up scaling for the page and most jobs usually will
> provide an initial user space coordinate after modifying the CTM and not
> depend on the location that was current when the scaling was applied.
> There is more work to be done in this area, the IP command needs similar
> updating as provided here for IR, and other attributes like anchor
> corner and carriage return position should be looked at for side effects
> resulting from IP, IR or SC.
> pcl/pgconfig.c

2015-03-28 15:22:22 -0600
Henry Stiles <henry.stiles@artifex.com>
820064dd06bb0bd63c0c89dc5f500fe70c23ac4b

> Refactor and cleanup hpgl/2 IP and IR commands.
> pcl/pgconfig.c

2015-03-30 22:19:37 +0100
Chris Liddell <chris.liddell@artifex.com>
f68473b9034c542575ac8f8334e0c7fc546fa422

> Fix date typo in the docs.
> No cluster diffs.
> gs/doc/History9.htm

2015-03-30 10:56:05 +0100
Chris Liddell <chris.liddell@artifex.com>
2a0d0d006ce1066cbe83ebc818025321953a1cd3

> Add the MAKEDIRS target onto the pnglibconf.h deps
> No cluster differences.
> gs/base/png.mak

2015-03-30 10:19:43 +0100
Chris Liddell <chris.liddell@artifex.com>
6dd7e751d41639fd303b795d1503173d38d8d82d

> Move the augmenting of CFLAGS for -Werror....
> until after we've identified we're building with gcc.
> No cluster differences.
> configure.ac

2015-03-19 11:55:19 +0000
Chris Liddell <chris.liddell@artifex.com>
26e90b59da069a84cc34501f4c8b4dbfc3dacbe0

> Bring master up to date with release branch
> Update versions and dates for release candidate.
> Update News.htm and History9.htm for release candidate.
> Some doc updates in response to rc1 feedback
> Tweak dates and stuff for second release candidate
> Update History file.
> Update changelog
> Update product string and date in the code.
> Update release date in the docs.
> README.txt
> gs/Makefile.in
> gs/base/gscdef.c
> gs/base/version.mak
> gs/contrib/opvp/gdevopvp.c
> gs/doc/API.htm
> gs/doc/C-style.htm
> gs/doc/Commprod.htm
> gs/doc/DLL.htm
> gs/doc/Deprecated.htm
> gs/doc/Details8.htm
> gs/doc/Details9.htm
> gs/doc/Develop.htm
> gs/doc/Devices.htm
> gs/doc/Drivers.htm
> gs/doc/Fonts.htm
> gs/doc/Helpers.htm
> gs/doc/History1.htm
> gs/doc/History2.htm
> gs/doc/History3.htm
> gs/doc/History4.htm
> gs/doc/History5.htm
> gs/doc/History6.htm
> gs/doc/History7.htm
> gs/doc/History8.htm
> gs/doc/History9.htm
> gs/doc/Install.htm
> gs/doc/Issues.htm
> gs/doc/Language.htm
> gs/doc/Lib.htm
> gs/doc/Make.htm
> gs/doc/News.htm
> gs/doc/Projects.htm
> gs/doc/Ps-style.htm
> gs/doc/Ps2epsi.htm
> gs/doc/Ps2pdf.htm
> gs/doc/Ps2ps2.htm
> gs/doc/Psfiles.htm
> gs/doc/Readme.htm
> gs/doc/Release.htm
> gs/doc/SavedPages.htm
> gs/doc/Source.htm
> gs/doc/Unix-lpr.htm
> gs/doc/Use.htm
> gs/doc/WhatIsGS.htm
> gs/doc/Xfonts.htm
> gs/doc/gs-vms.hlp
> gs/doc/thirdparty.htm
> gs/man/dvipdf.1
> gs/man/font2c.1
> gs/man/gs.1
> gs/man/gslp.1
> gs/man/gsnd.1
> gs/man/pdf2dsc.1
> gs/man/pdf2ps.1
> gs/man/pf2afm.1
> gs/man/pfbtopfa.1
> gs/man/printafm.1
> gs/man/ps2ascii.1
> gs/man/ps2epsi.1
> gs/man/ps2pdf.1
> gs/man/ps2pdfwr.1
> gs/man/ps2ps.1
> gs/man/wftopfa.1
> gs/psi/int.mak
> gs/psi/msvc.mak
> gs/psi/winint.mak

2015-03-27 17:30:18 -0600
Henry Stiles <henry.stiles@artifex.com>
1e8937a52502d0244c6a3bc173dccd4d83cf00f2

> Fix 695888 - GhostPCL locks up.
> The flag to indicate a command is not implemented (e_Unimplemented) was
> set to a positive integer which the GL/2 parser uses to tell the pcl
> parser more PCL is expected. This isn't a problem unless the job
> terminates unexpectedly with an unimplemented GL/2 command leaving the
> PCL parser poised to read more data. Without changing the
> parsers we simply change the unimplemented flag to 0 and the command
> will be properly ignored, like range errors (e_Range).
> Unfortunately that leaves us with the same code for e_Range and
> e_Unimplemented which may be an inconvenience when debugging, but both
> codes demand the same behavior of the parsers so we prefer this change
> to trying to find all the places in the parser where e_Unimplemented
> should be "plugged in".
> pcl/pcommand.h

2015-03-27 09:58:06 +0000
Ken Sharp <ken.sharp@artifex.com>
5e87a537c30c15e30615eafedb83ff040a33f6ee

> PDF Interpreter - When resolving type 6 halftones, preserve the underlying PDFfile position
> Bug #695886 "Error reading a content stream, missing objects"
> Type 6 halftones in PDF are stream based, so when we first use a graphics
> state which includes a type 6 halftone, we use resolvestream to read the
> halftone.
> However resolvestream does not preserve the current file position of PDFfile
> and resolveht6 wasn't taking steps to save and restore it. Often this would
> not be harmful but if we are already reading a stream (eg a page content
> stream) and the stream was large enough not to be entirely buffered then when
> we ran out of data we would return to 'PDFfile' to read another buffer from
> the content stream. The fact that PDFfile had been repositioned would cause
> us to read the wrong data (always, in fact, the 'endstream' from the halftone
> stream).
> This commit retrieves the current position of PDFfile and restores it after
> resolving the stream.
> No differences expected
> gs/Resource/Init/pdf_draw.ps

2015-03-23 15:29:37 +0000
Chris Liddell <chris.liddell@artifex.com>
f56588ea3cb9337b3c4143a9eb651f085cfe8298

> LCMS2 pointer alignment on SPARC/gcc
> Building on commit 5a2da7dd71:
> With gcc on (Ultra)SPARC hardware, pointers must be 8 byte aligned, even in
> 32 bit userspace (where sizeof(void *) == 4).
> So it means taking special action to enforce 8 byte alignment in the LCMS2
> memory management code.
> We'll set the alignment for SPARC builds in the configure script.
> No cluster differences.
> config.mak.in
> configure.ac
> gs/Makefile.in
> gs/configure.ac

2015-03-24 13:50:34 +0000
Chris Liddell <chris.liddell@artifex.com>
cab2628321d8806747da90c02c3abf4b2c9fe4c3

> LCMS2 on SPARC ptr alignment.
> Allow the ptr alignment for LCMS2 memory management to set at build time on the
> compiler command line.
> Submitted upstream:
> https://github.com/mm2/Little-CMS/commit/dd0074b2
> No cluster differences
> gs/lcms2/src/lcms2_internal.h

2015-03-23 17:03:41 +0000
Chris Liddell <chris.liddell@artifex.com>
8bb53a7f2cb309cc10209f8e7ed31daf6c2f4811

> Bug 695882: ensure function protypes are available
> There are some special defines on Linux to include prototypes for pread, pwrite
> and pthread_mutexattr_settype: add these to our "unistd_.h" header.
> Also, tweak the the configure script to check for prototypes as well as just
> successful linking before including the code that uses those functions
> No cluster differences
> configure.ac
> gs/base/gp_psync.c
> gs/base/unistd_.h
> gs/configure.ac

2015-03-24 11:07:43 +0000
Ken Sharp <ken.sharp@artifex.com>
0997387b6b691d7495722d020ee7f6bab4988020

> PDF Interpreter - ignore XRefStm entries which poitn beyond end of file
> Bug #695883 "Error: /invalidaccess in --run--"
> The file is pretty well broken, it claims to be a hybrid (PDF 1.5 or better
> readable by PDF 1.4 consumer, it uses xref streams) and as such its trailer
> dictionary contains an XRefStm key whose value is supposed to point to the
> PDF 1.5 xref stream. It doesn't, in fact it points past the end of the file
> and so is clearly bogus.
> This commit tests to ensure the XRefStm value is inside the file before
> attempting to read it.
> No differences expected.
> gs/Resource/Init/pdf_main.ps

2015-03-20 00:11:26 +0000
Chris Liddell <chris.liddell@artifex.com>
8a275b2f12c2d22cb40fcf421c309a018dd48b0e

> Tweak builds for SPARC architecture
> SPARC's interesting alignment requirements don't work with the memory header
> ID code, so disable it.
> No cluster differences.
> configure.ac
> gs/configure.ac

2015-03-19 11:50:40 +0000
Chris Liddell <chris.liddell@artifex.com>
e77a35e7ffef84328a7fb26379783455da3f8a58

> Bump version numbers to 9.17
> Usual cluster differences.
> gs/Resource/Init/gs_init.ps
> gs/base/version.mak

2015-03-30 09:16:22 +0100
Chris Liddell <chris.liddell@artifex.com>
92d4dd195d0cb9155851411db04e1d2af1f59c03

> Update release date in the docs.
> gs/contrib/opvp/gdevopvp.c
> gs/doc/API.htm
> gs/doc/C-style.htm
> gs/doc/Commprod.htm
> gs/doc/DLL.htm
> gs/doc/Deprecated.htm
> gs/doc/Details8.htm
> gs/doc/Details9.htm
> gs/doc/Develop.htm
> gs/doc/Devices.htm
> gs/doc/Drivers.htm
> gs/doc/Fonts.htm
> gs/doc/Helpers.htm
> gs/doc/History1.htm
> gs/doc/History2.htm
> gs/doc/History3.htm
> gs/doc/History4.htm
> gs/doc/History5.htm
> gs/doc/History6.htm
> gs/doc/History7.htm
> gs/doc/History8.htm
> gs/doc/History9.htm
> gs/doc/Install.htm
> gs/doc/Issues.htm
> gs/doc/Language.htm
> gs/doc/Lib.htm
> gs/doc/Make.htm
> gs/doc/News.htm
> gs/doc/Projects.htm
> gs/doc/Ps-style.htm
> gs/doc/Ps2epsi.htm
> gs/doc/Ps2pdf.htm
> gs/doc/Ps2ps2.htm
> gs/doc/Psfiles.htm
> gs/doc/Readme.htm
> gs/doc/Release.htm
> gs/doc/SavedPages.htm
> gs/doc/Source.htm
> gs/doc/Unix-lpr.htm
> gs/doc/Use.htm
> gs/doc/WhatIsGS.htm
> gs/doc/Xfonts.htm
> gs/doc/gs-vms.hlp
> gs/doc/thirdparty.htm
> gs/man/dvipdf.1
> gs/man/font2c.1
> gs/man/gs.1
> gs/man/gslp.1
> gs/man/gsnd.1
> gs/man/pdf2dsc.1
> gs/man/pdf2ps.1
> gs/man/pf2afm.1
> gs/man/pfbtopfa.1
> gs/man/printafm.1
> gs/man/ps2ascii.1
> gs/man/ps2epsi.1
> gs/man/ps2pdf.1
> gs/man/ps2pdfwr.1
> gs/man/ps2ps.1
> gs/man/wftopfa.1

2015-03-30 09:15:05 +0100
Chris Liddell <chris.liddell@artifex.com>
20c71f82b1116ee95e0ae03121b9f137900fbcd8

> Update product string and date in the code.
> gs/base/gscdef.c
> gs/base/version.mak

2015-03-24 14:08:57 +0000
Chris Liddell <chris.liddell@artifex.com>
2a35f042bfa9fa431794546bff4b2e388036798d

> Update changelog
> gs/doc/History9.htm

2015-03-23 15:29:37 +0000
Chris Liddell <chris.liddell@artifex.com>
49ac7a284e46cf8df8eb553c91ee48a6b004652e

> LCMS2 pointer alignment on SPARC/gcc
> Building on commit 5a2da7dd71:
> With gcc on (Ultra)SPARC hardware, pointers must be 8 byte aligned, even in
> 32 bit userspace (where sizeof(void *) == 4).
> So it means taking special action to enforce 8 byte alignment in the LCMS2
> memory management code.
> We'll set the alignment for SPARC builds in the configure script.
> No cluster differences.
> config.mak.in
> configure.ac
> gs/Makefile.in
> gs/configure.ac

2015-03-24 13:50:34 +0000
Chris Liddell <chris.liddell@artifex.com>
f2f22a246dcbe8468880535ea75f47e0fc4619ce

> LCMS2 on SPARC ptr alignment.
> Allow the ptr alignment for LCMS2 memory management to set at build time on the
> compiler command line.
> Submitted upstream:
> https://github.com/mm2/Little-CMS/commit/dd0074b2
> No cluster differences
> gs/lcms2/src/lcms2_internal.h

2015-03-23 17:03:41 +0000
Chris Liddell <chris.liddell@artifex.com>
b96200d7fc5f3b7464744589f6657e9b4c4cb3ec

> Bug 695882: ensure function protypes are available
> There are some special defines on Linux to include prototypes for pread, pwrite
> and pthread_mutexattr_settype: add these to our "unistd_.h" header.
> Also, tweak the the configure script to check for prototypes as well as just
> successful linking before including the code that uses those functions
> No cluster differences
> configure.ac
> gs/base/gp_psync.c
> gs/base/unistd_.h
> gs/configure.ac

2015-03-24 11:07:43 +0000
Ken Sharp <ken.sharp@artifex.com>
9358edca362b60f8ace388768548e6e94f5ebec8

> PDF Interpreter - ignore XRefStm entries which poitn beyond end of file
> Bug #695883 "Error: /invalidaccess in --run--"
> The file is pretty well broken, it claims to be a hybrid (PDF 1.5 or better
> readable by PDF 1.4 consumer, it uses xref streams) and as such its trailer
> dictionary contains an XRefStm key whose value is supposed to point to the
> PDF 1.5 xref stream. It doesn't, in fact it points past the end of the file
> and so is clearly bogus.
> This commit tests to ensure the XRefStm value is inside the file before
> attempting to read it.
> No differences expected.
> gs/Resource/Init/pdf_main.ps

2015-03-20 15:45:56 +0000
Chris Liddell <chris.liddell@artifex.com>
866f98d9b88b6b450aa4d112cabc60a1f964bbd6

> Update History file.
> gs/doc/History9.htm

2015-03-20 15:09:41 +0000
Chris Liddell <chris.liddell@artifex.com>
08c4ed7a418ea4eed1efd12cf8fe81297c00a2f9

> Tweak dates and stuff for second release candidate
> gs/base/gscdef.c
> gs/base/version.mak
> gs/doc/API.htm
> gs/doc/C-style.htm
> gs/doc/Commprod.htm
> gs/doc/DLL.htm
> gs/doc/Deprecated.htm
> gs/doc/Details8.htm
> gs/doc/Details9.htm
> gs/doc/Develop.htm
> gs/doc/Devices.htm
> gs/doc/Drivers.htm
> gs/doc/Fonts.htm
> gs/doc/Helpers.htm
> gs/doc/History1.htm
> gs/doc/History2.htm
> gs/doc/History3.htm
> gs/doc/History4.htm
> gs/doc/History5.htm
> gs/doc/History6.htm
> gs/doc/History7.htm
> gs/doc/History8.htm
> gs/doc/History9.htm
> gs/doc/Install.htm
> gs/doc/Issues.htm
> gs/doc/Language.htm
> gs/doc/Lib.htm
> gs/doc/Make.htm
> gs/doc/News.htm
> gs/doc/Projects.htm
> gs/doc/Ps-style.htm
> gs/doc/Ps2epsi.htm
> gs/doc/Ps2pdf.htm
> gs/doc/Ps2ps2.htm
> gs/doc/Psfiles.htm
> gs/doc/Readme.htm
> gs/doc/Release.htm
> gs/doc/SavedPages.htm
> gs/doc/Source.htm
> gs/doc/Unix-lpr.htm
> gs/doc/Use.htm
> gs/doc/WhatIsGS.htm
> gs/doc/Xfonts.htm
> gs/doc/gs-vms.hlp
> gs/doc/thirdparty.htm
> gs/man/dvipdf.1
> gs/man/font2c.1
> gs/man/gs.1
> gs/man/gslp.1
> gs/man/gsnd.1
> gs/man/pdf2dsc.1
> gs/man/pdf2ps.1
> gs/man/pf2afm.1
> gs/man/pfbtopfa.1
> gs/man/printafm.1
> gs/man/ps2ascii.1
> gs/man/ps2epsi.1
> gs/man/ps2pdf.1
> gs/man/ps2pdfwr.1
> gs/man/ps2ps.1
> gs/man/wftopfa.1

2015-03-20 14:58:45 +0000
Chris Liddell <chris.liddell@artifex.com>
6aac092d495d1651840074cd2ed9ba64d9d4c0a4

> Some doc updates in response to rc1 feedback
> README.txt
> gs/doc/History9.htm
> gs/doc/News.htm

2015-03-20 00:11:26 +0000
Chris Liddell <chris.liddell@artifex.com>
6c56ffb81354dca442b69389b0f7a0b75e4e864e

> Tweak builds for SPARC architecture
> SPARC's interesting alignment requirements don't work with the memory header
> ID code, so disable it.
> No cluster differences.
> configure.ac
> gs/configure.ac

2015-03-19 11:55:19 +0000
Chris Liddell <chris.liddell@artifex.com>
369bb9d36e4309c93bb60a2eb799ee5ff16e9c7c

> Update versions and dates for release candidate.
> Update News.htm and History9.htm for release candidate.
> gs/Makefile.in
> gs/base/gscdef.c
> gs/base/version.mak
> gs/doc/API.htm
> gs/doc/C-style.htm
> gs/doc/Commprod.htm
> gs/doc/DLL.htm
> gs/doc/Deprecated.htm
> gs/doc/Details8.htm
> gs/doc/Details9.htm
> gs/doc/Develop.htm
> gs/doc/Devices.htm
> gs/doc/Drivers.htm
> gs/doc/Fonts.htm
> gs/doc/Helpers.htm
> gs/doc/History1.htm
> gs/doc/History2.htm
> gs/doc/History3.htm
> gs/doc/History4.htm
> gs/doc/History5.htm
> gs/doc/History6.htm
> gs/doc/History7.htm
> gs/doc/History8.htm
> gs/doc/History9.htm
> gs/doc/Install.htm
> gs/doc/Issues.htm
> gs/doc/Language.htm
> gs/doc/Lib.htm
> gs/doc/Make.htm
> gs/doc/News.htm
> gs/doc/Projects.htm
> gs/doc/Ps-style.htm
> gs/doc/Ps2epsi.htm
> gs/doc/Ps2pdf.htm
> gs/doc/Ps2ps2.htm
> gs/doc/Psfiles.htm
> gs/doc/Readme.htm
> gs/doc/Release.htm
> gs/doc/SavedPages.htm
> gs/doc/Source.htm
> gs/doc/Unix-lpr.htm
> gs/doc/Use.htm
> gs/doc/WhatIsGS.htm
> gs/doc/Xfonts.htm
> gs/doc/gs-vms.hlp
> gs/doc/thirdparty.htm
> gs/man/dvipdf.1
> gs/man/font2c.1
> gs/man/gs.1
> gs/man/gslp.1
> gs/man/gsnd.1
> gs/man/pdf2dsc.1
> gs/man/pdf2ps.1
> gs/man/pf2afm.1
> gs/man/pfbtopfa.1
> gs/man/printafm.1
> gs/man/ps2ascii.1
> gs/man/ps2epsi.1
> gs/man/ps2pdf.1
> gs/man/ps2pdfwr.1
> gs/man/ps2ps.1
> gs/man/wftopfa.1
> gs/psi/int.mak
> gs/psi/msvc.mak
> gs/psi/winint.mak

## Version 9.16 (2015-03-30)

This is the twelfth full release in the stable 9.x series, and is primarily a maintenance release.

Highlights in this release include:

- "LockColorants" command line option for tiffsep and psdcmyk devices. Specifying -dLockColorants will restrict those devices to only the colorants list on the command line (thus: -c "<< /SeparationColorNames [ /Cyan /Magenta /Yellow /Black /Violet /Orange] /SeparationOrder [ /Cyan /Magenta /Yellow /Black /Violet /Orange]>> setpagedevice"), rather than allowing the devices to add new colorants as encountered in the input. This is, obviously, preferable for real printers, where only a certain of inks will be available.

- Improved high level devices handling of Forms. Whilst High level devices (eg pdfwrite) already checked Forms to see if they are duplicates, and if so use the initial definition. However, this does not improve performance, since the Form PaintProc still needs to be executed for each instance of the Form, and the matching algorithm could, in very odd circumstances, be defeated. The new implementation benefits both causes, meaning the second and subsequent invocation of the form need not re-run the PaintProc, and removes the heuristic aspect of the reuse detection.

- New URW+ fonts in which the families NimbusMono, NimbusRoman and NimbusSans have been augmented with production quality Greek and Cyrillic glyphs. These correspond to our substitutes for the PDF base 14 fonts.

- Plus the usual round of bug fixes, compatibility changes, and incremental improvements.

For a list of open issues, or to report problems, please visit bugs.ghostscript.com.

### Incompatible changes

No recorded incompatible changes.

### Changelog

2015-03-20 00:11:26 +0000

2015-03-19 11:55:19 +0000
Chris Liddell <chris.liddell@artifex.com>
49ac7a284e46cf8df8eb553c91ee48a6b004652e

> LCMS2 pointer alignment on SPARC/gcc
> Building on commit 5a2da7dd71:
> With gcc on (Ultra)SPARC hardware, pointers must be 8 byte aligned, even in
> 32 bit userspace (where sizeof(void *) == 4).
> So it means taking special action to enforce 8 byte alignment in the LCMS2
> memory management code.
> We'll set the alignment for SPARC builds in the configure script.
> No cluster differences.
> config.mak.in
> configure.ac
> gs/Makefile.in
> gs/configure.ac

2015-03-24 13:50:34 +0000
Chris Liddell <chris.liddell@artifex.com>
f2f22a246dcbe8468880535ea75f47e0fc4619ce

> LCMS2 on SPARC ptr alignment.
> Allow the ptr alignment for LCMS2 memory management to set at build time on the
> compiler command line.
> Submitted upstream:
> https://github.com/mm2/Little-CMS/commit/dd0074b2
> No cluster differences
> gs/lcms2/src/lcms2_internal.h

2015-03-23 17:03:41 +0000
Chris Liddell <chris.liddell@artifex.com>
b96200d7fc5f3b7464744589f6657e9b4c4cb3ec

> Bug 695882: ensure function protypes are available
> There are some special defines on Linux to include prototypes for pread, pwrite
> and pthread_mutexattr_settype: add these to our "unistd_.h" header.
> Also, tweak the the configure script to check for prototypes as well as just
> successful linking before including the code that uses those functions
> No cluster differences
> configure.ac
> gs/base/gp_psync.c
> gs/base/unistd_.h
> gs/configure.ac

2015-03-24 11:07:43 +0000
Ken Sharp <ken.sharp@artifex.com>
9358edca362b60f8ace388768548e6e94f5ebec8

> PDF Interpreter - ignore XRefStm entries which poitn beyond end of file
> Bug #695883 "Error: /invalidaccess in --run--"
> The file is pretty well broken, it claims to be a hybrid (PDF 1.5 or better
> readable by PDF 1.4 consumer, it uses xref streams) and as such its trailer
> dictionary contains an XRefStm key whose value is supposed to point to the
> PDF 1.5 xref stream. It doesn't, in fact it points past the end of the file
> and so is clearly bogus.
> This commit tests to ensure the XRefStm value is inside the file before
> attempting to read it.
> No differences expected.
> gs/Resource/Init/pdf_main.ps

Chris Liddell <chris.liddell@artifex.com>
6c56ffb81354dca442b69389b0f7a0b75e4e864e

> Tweak builds for SPARC architecture
> SPARC's interesting alignment requirements don't work with the memory header
> ID code, so disable it.
> No cluster differences.
> configure.ac
> gs/configure.ac

Chris Liddell <chris.liddell@artifex.com>
03d399b295f9a39f743eb194ebce0995d52d0bfb

> Update versions and dates for release candidate.
> gs/Makefile.in
> gs/base/gscdef.c
> gs/base/version.mak
> gs/doc/API.htm
> gs/doc/C-style.htm
> gs/doc/Commprod.htm
> gs/doc/DLL.htm
> gs/doc/Deprecated.htm
> gs/doc/Details8.htm
> gs/doc/Details9.htm
> gs/doc/Develop.htm
> gs/doc/Devices.htm
> gs/doc/Drivers.htm
> gs/doc/Fonts.htm
> gs/doc/Helpers.htm
> gs/doc/History1.htm
> gs/doc/History2.htm
> gs/doc/History3.htm
> gs/doc/History4.htm
> gs/doc/History5.htm
> gs/doc/History6.htm
> gs/doc/History7.htm
> gs/doc/History8.htm
> gs/doc/History9.htm
> gs/doc/Install.htm
> gs/doc/Issues.htm
> gs/doc/Language.htm
> gs/doc/Lib.htm
> gs/doc/Make.htm
> gs/doc/News.htm
> gs/doc/Projects.htm
> gs/doc/Ps-style.htm
> gs/doc/Ps2epsi.htm
> gs/doc/Ps2pdf.htm
> gs/doc/Ps2ps2.htm
> gs/doc/Psfiles.htm
> gs/doc/Readme.htm
> gs/doc/Release.htm
> gs/doc/SavedPages.htm
> gs/doc/Source.htm
> gs/doc/Unix-lpr.htm
> gs/doc/Use.htm
> gs/doc/WhatIsGS.htm
> gs/doc/Xfonts.htm
> gs/doc/gs-vms.hlp
> gs/doc/thirdparty.htm
> gs/man/dvipdf.1
> gs/man/font2c.1
> gs/man/gs.1
> gs/man/gslp.1
> gs/man/gsnd.1
> gs/man/pdf2dsc.1
> gs/man/pdf2ps.1
> gs/man/pf2afm.1
> gs/man/pfbtopfa.1
> gs/man/printafm.1
> gs/man/ps2ascii.1
> gs/man/ps2epsi.1
> gs/man/ps2pdf.1
> gs/man/ps2pdfwr.1
> gs/man/ps2ps.1
> gs/man/wftopfa.1
> gs/psi/int.mak
> gs/psi/msvc.mak
> gs/psi/winint.mak

2015-03-19 13:50:07 +0000
Chris Liddell <chris.liddell@artifex.com>
a463733e35e1070a06029657dedb67148c33c87a

> Handle an invalid cidfmap entry in the CIDFont subst code
> Certain types of invalid entry in the cidfmap can mean that resourcestatus
> returns "true" but a subsequent "findresource" will fail. There is already
> validation code to strip out invalid entries, but as an extra safety measure,
> call the findresource in a stopped context, so we can recover, and continue
> with the next substitution fallback stage.
> No cluster differences.
> gs/Resource/Init/pdf_font.ps

2015-03-19 10:51:32 +0000
Chris Liddell <chris.liddell@artifex.com>
68f1390c29df09d2cc7cdb5c815c71aaa77f667c

> Add instructions about using ghostpdf.inf on Windows 8
> Add the instructions in the comments in ghostpdf.inf, and in a separate README
> file.
> Lots of "AT YOUR OWN RISK!!" comments in both.
> No cluster differences.
> gs/lib/ghostpdf.README
> gs/lib/ghostpdf.inf

2015-03-19 10:49:34 +0000
Chris Liddell <chris.liddell@artifex.com>
2487b24d668f86350a1c5bdcf0e7a485470665e9

> Correct a copy'n'paste mistake in a conditional
> No cluster differences.
> gs/configure.ac

2015-03-18 08:37:15 +0000
Chris Liddell <chris.liddell@artifex.com>
3c4edb1e23eec531b96194f85685b30656149732

> Bug 695860: only shutdown BGPrint if it's active
> Always forcing a setpagedevice interacts poorly with pdfwrite/ps2write (which
> rely on the device shutting down to trigger emitting the final output).
> Since vector devices cannot benefit from BGPrint, only disable BGPrint (with
> setpagedevice) if BGPrint was active in the first place.
> No cluster differences.
> gs/psi/imain.c

2015-03-17 22:42:22 +0000
Chris Liddell <chris.liddell@artifex.com>
2ceee5a8a0e1a4d65f14de5f6cf53bb939b2f02c

> Bug 695872: handle real/integer mixup in image Decode dict
> In PDF we now pass the Height value from the image dict into the parameters
> for the filter to access (specifically, the DCTDecodeFilter), and this will
> cause an error if the Height value is, erroneously, a real rather than integer
> value (the Postscript image operator appears to already handle that error,
> at least in certain cases, gracefully).
> So the filter code does not throw an error, round and convert the value to an
> integer before storing it in the filter parameters dictionary.
> No cluster differences.
> gs/Resource/Init/pdf_draw.ps

2015-03-17 21:44:50 +0000
Chris Liddell <chris.liddell@artifex.com>
ace1b71cd0097ee830692e3e59738e084f5a4141

> Fix a couple of typos in Install.htm
> No cluster differences.
> gs/doc/Install.htm

2015-03-17 18:05:51 +0000
Chris Liddell <chris.liddell@artifex.com>
41ff61ceceb55dd03da6b309c290c880c38fce04

> Bug 692861: update Install.htm for "new" installer.
> Bring Install.htm in-line with the nsis based Windows installer.
> Also, remove references to Adobe Type Manager, and document that OpenVMS and
> OS/2 are no longer actively supported by us.
> No cluster differences
> gs/doc/Install.htm

2015-03-17 16:38:50 +0000
Chris Liddell <chris.liddell@artifex.com>
b18cefb10c2391188d07ad0ca397e58121434b8b

> Recursive mutex emulation: fix order of operations
> We have to invalidate the self_id value *before* we unlock the mutex, as the
> mutex implicitly protects the self_id (and lcount) value.
> Also add asserts so we'll abort if the self_id and/or lcount get out of whack.
> Finally, add a missing default value for RECURSIVE_MUTEXATTR in the ghostpdl
> configure.
> No cluster differences
> configure.ac
> gs/base/gp_psync.c
> gs/base/lib.mak

2015-03-17 14:45:01 +0000
Chris Liddell <chris.liddell@artifex.com>
3dbcbb2ac75a8565534310cba189544ccdd1c1c4

> Bug 695862: addendum - fix typo
> No cluster differences.
> gs/base/gp_psync.c

2015-03-16 22:18:41 +0000
Chris Liddell <chris.liddell@artifex.com>
edf3461901805376bdb1b9aa995df359531c7539

> Fix a write after free memory issue.
> No cluster differences
> gs/base/stream.c

2015-03-16 12:52:49 +0000
Chris Liddell <chris.liddell@artifex.com>
444e0bf9c43bae0261660e6318ba0e514c18d41e

> Bug 695862: use PTHREAD_MUTEX_RECURSIVE(_NP) if available
> or properly emulate recursive mutexes ourselves.
> No cluster differences
> config.mak.in
> configure.ac
> gs/Makefile.in
> gs/base/gp_psync.c
> gs/configure.ac

2015-03-07 16:25:46 +0000
Chris Liddell <chris.liddell@artifex.com>
f1feefae4e6412d37db6abb46b492a74073964c7

> Bug 691396: add new lines to FAPIdebug messages.
> No cluster differences
> tmp commit
> gs/Resource/Init/gs_fapi.ps

2015-03-07 17:05:53 +0000
Chris Liddell <chris.liddell@artifex.com>
febe7a1acf152ef7379a126bfa65358604272b5a

> Flush around FAPI "internal" debug messages.
> Try to avoid the FAPI -Z1 messages stomping on other output messages by flushing
> around the messages.
> No cluster differences.
> gs/base/fapi_ft.c
> gs/base/fapiufst.c

2015-03-07 15:10:49 +0000
Chris Liddell <chris.liddell@artifex.com>
0f1d26a75ccb1adc806287f7e97af14af85f4fdf

> Bug 692815: Fonts resourcestatus and native fonts
> The core of the resourcestatus implementation for the Fonts category would
> check the content of Fontmap, but would not trigger the native font scanning
> to occur. So two invokations of resourcestatus for Font could result in
> different results depending on whether, in the intervening period, another
> operation had triggered the native font scan.
> This could result in unexpected behaviour from the PDF interpreter where a
> "synthetic" substitute could be created on the first page, and a native font
> selected on the second page, for the same font name.
> We'll now try to "find" the font for resourcestatus, if we fail, we'll try to
> trigger the native font scan, and retry.
> Further, I had missed the fact that this code used the Fontmap dictionary in my
> previous commit, so it now accounts for the new NativeFontmap dict.
> No cluster differences.
> gs/Resource/Init/gs_fonts.ps
> gs/Resource/Init/gs_res.ps

2015-03-05 14:56:51 +0000
Chris Liddell <chris.liddell@artifex.com>
3edd8e8e64c0b35364c2fdf2e13336191c023f4b

> Bug 690653: fix order of font substitution mapping.
> Previously, the enumeration of the "native fonts" (i.e. when using
> fontconfig) wrote the mappings into the same Fontmap dictionary that is built
> from the Fontmap file.
> This could cause several problems. Firstly, it was possible for fonts found by
> the native font search to effective replace the default font set - which should
> *never* happen. Secondly, and even worse, the font found when trying to load
> one of the default font set could change depending on whether a prior attempt
> was made to load from from outside the default font, because the attempt to load
> a font from outside the default set would trigger the Fontmap to change with the
> native fonts being added.
> We'll now keep the Fontmap dict from the Fontmap file separate from a new
> native fontmap dictionary. We'll now check the Fontmap dictionary, then try to
> load directly by name, then check the .nativeFontmap dict.
> The .nativeFontmap also gets the results of scanning the directories in the
> FONTDIR paremeter.
> No cluster differences.
> Bug 690653 (related): update pdf interp to use NativeFontmap
> The pdf interpreter accesses Fontmap, so tweak it to also use NativeFontmap.
> No cluster differences
> gs/Resource/Init/gs_fonts.ps
> gs/Resource/Init/pdf_font.ps

2015-03-16 18:29:09 +0000
Robin Watts <robin.watts@artifex.com>
0391d0e73c1892138b11c1416113e32b80d3317f

> Update clusterpush.pl to cope with new mupdf source layout.
> gs/toolbin/localcluster/clusterpush.pl

2015-03-16 08:39:36 -0700
Ray Johnston <ray.johnston@artifex.com>
949e2de694cb5464a26794b7679d8f74ad2fe02b

> Temporary fix for bug 695711. Disable BGPrint when NumRenderingThreads > 0.
> This will be fixed, but since background printing is an optimization, it is
> better to disable it instead of having a SEGV occur due to a race condition.
> gs/base/gdevprn.c

2015-03-16 10:08:52 +0000
Ken Sharp <ken.sharp@artifex.com>
d4440c2190845bdd165f3d208d508f45e2142bee

> pdfwrite - process octal escapes in DSC comments
> Bug #695850 - "DSC comments not being read correctly from PDFDocEncoding"
> DSC comments are not encoded using PDFDocEncoding, nor are they PostScript
> strings, they are a simple sequence of bytes. So it seems that we should
> simply preserve that sequence in the output PDF file. However Distiller
> behaves 'oddly' with DSC comments containing escape characters:
> octal escapes (\ followed by 3 numbers) are converted into apparently a
> PDFDocEncoding byte
> non-octal numeric escapes (\ followed by less than 3 numbers or numebrs
> which aren't octal) have the \ changed to a ?
> non-octal non-numeric escapes (eg \n) simply get the escape dropped.
> IMO this leads to problems, for example bug687660.ps has a %%Title which is
> a DOS filename '%%Title: (C:\PHYSICS\TeX\SPINTRONICS\SPIN_HALL\gh_ef_001.eps)'
> Distiller mangles this by dropping all the '\' characters to become
> (C:PHYSICSTeXSPINTRONICSSPIN_HALLgh_ef_001.eps)
> This commit alters the way that pdfwrite handles octal escapes *only*. These
> are converted to binary and will then be encoded as if they were in
> PDFDocEncoding which matches Distiller. We will not attempt to match the
> observed behaviour of Distiller, not least because I think its completely
> the wrong thing to do.
> No differences expected
> gs/devices/vector/gdevpdfp.c

2015-03-13 09:20:39 -0700
Michael Vrhel <michael.vrhel@artifex.com>
a16e39318467d8a802296bd34bbf0fab7f7809d5

> Fix for bug 695863 overprint while pattern color is active
> If a pattern color space is present when a graphics state swap occurs, and
> the overprint changes from on to off in the graphics state the overprint
> compositor is not disabled. In Bug 695863 a DeviceN image fill follows such
> a case and the fill is improperly performed with overprint enabled. With this
> commit we disable the overprint compositor if overprint is off. If overprint
> is not off, it is not clear how we should proceed, as the color space is
> a factor in that set up and here the color space is a pattern.
> gs/base/gspcolor.c
> gs/base/lib.mak

2015-03-10 22:05:52 -0700
Michael Vrhel <michael.vrhel@artifex.com>
64e33af885e49b40c0ebc070ede50e86a8ed3bdb

> Change to check for len > 0 on while loop
> Requested by a customer and protects against caller passing invalid len
> gs/psi/dwmainc.c

2015-03-07 08:38:57 -0800
Michael Vrhel <michael.vrhel@artifex.com>
8e8a9c4265c3346055ecfc8025880cab28e268de

> Fix for bug 693070 psdrgb device
> The psdrgb device should not alter its number of components but it should stay
> fixed. This commit plus b5b03bde360a7ba625a4c40a936c4e2fd5a32359
> should fix the psdrgb device.
> gs/devices/gdevpsd.c

2015-03-06 13:28:51 -0800
Michael Vrhel <michael.vrhel@artifex.com>
b5b03bde360a7ba625a4c40a936c4e2fd5a32359

> PageSpotColors was getting handled by devn_get_params but not devn_put_params
> For additive devices devn_put_params was not handling PageSpotColors but
> devn_get_params was. This mismatch would lead to an error for the psdrgb
> device, which is an additive device built upon the DeviceN device. Additive
> devices do not handle apot colors at this time so the fix was to make
> the handling of PageSpotColors in devn_get_params dependent upon the device
> polarity like devn_put_params does.
> gs/base/gdevdevn.c

2015-03-06 11:19:07 -0800
Michael Vrhel <michael.vrhel@artifex.com>
c75e5c690c6f9c1da2e9225d4986967d1d391c8b

> Fix for bug 695791. Wrong ICC profile written when source was CIELAB colorspace.
> gs/devices/vector/gdevxps.c

2015-03-03 18:59:17 +0000
Chris Liddell <chris.liddell@artifex.com>
12ddbaa69c38fa0178ff60a012ff358987b6238d

> Handle non-integer /Rotate values.
> Add a convert to integer (cvi) after retrieving the /Rotate entry from a PDF
> /Page object (we already reject values that are not a multiple of 90).
> In this case, the value was 90.0.
> No cluster differences.
> gs/Resource/Init/pdf_main.ps

2015-02-27 12:25:15 -0800
Michael Vrhel <michael.vrhel@artifex.com>
863c929faa7811ce6d78cb8d1b4610ee00a7a572

> Fix mistake on temp state setup for named color replacement
> I had not properly set up the colorant mapping positions and
> size for the temporary graphic state that is used during the
> storage of the color values that are set by the named color
> replacement code. Thanks to Stefan for finding this.
> gs/base/gxcmap.c

2015-02-26 18:01:04 -0700
Henry Stiles <henry.stiles@artifex.com>
7093747c7336656cfba938cff705b36fea6106c2

> More improvement related to bug #695833 properly selecting LinePrinter
> not Courier.
> pl/plftable.h

2015-02-26 17:54:10 -0700
Henry Stiles <henry.stiles@artifex.com>
f4f0f0a92a543adef944c09ff065defe1c58fefe

> Remove the test for a TrueType file type to make way for supporting
> other font file types.
> pl/pllfont.c

2015-02-25 07:44:51 -0800
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
70bd09212747f8b13e94948c04cadf5b0df65899

> Silence a compiler warning in fuzzy.c
> gs/toolbin/tests/fuzzy.c

2015-02-12 10:13:10 -0800
Ray Johnston <ray.johnston@artifex.com>
a2d08f1eb88355c81672668595f0b80f32386e48

> Fix pattern-clist with transparency color mismatch with raster patterns
> Cust 532 noticed that colors would be (very slightly) different when patterns
> were rendered from raster patterns vs. using the pattern-clist approach. This
> happened when the pattern has transparency such as fts_25_2526.ps.
> The file tests_private/comparefiles/Bug692720.pdf is a progression (lower left
> "21h" and "22h" are missing and the bold outline for some of the text on the
> left panel is wrong without this change.
> Fix it to make sure and push and pop a transparency group around the pattern
> filling when pattern-clist is used, the same as for raster patterns that have
> transparecncy. The 'blending_mode' was moved to the tile (gx_color_tile_s)
> from the ttrans (gx_pattern_trans_s) struct so that it will be available when
> painting from the pattern-clist.
> Also remove some code in gxpcmap.c that was dead (#if 0) since 2007.
> gs/base/gdevp14.c
> gs/base/gsptype1.c
> gs/base/gxclread.c
> gs/base/gximask.c
> gs/base/gxp1fill.c
> gs/base/gxpcmap.c
> gs/base/gxpcolor.h
> gs/psi/zpcolor.c

2015-02-23 14:13:53 -0800
Ray Johnston <ray.johnston@artifex.com>
fb531eecd1942807a792ef66a1aa49ec00792d13

> Fix bugs 695840, 695841. Regression due to pdf14_clist optimization.
> If the color characteristics of the device do not match the pdf14
> compositor, rendering the clist bands without the pdf14 compositor
> will fail, either by reading colors with the wrong depth back from
> the clist or colors having been pre-converted using a device ICC
> profile that is different than the colors that are written using
> the pdf14 compositor.
> gs/base/gdevp14.c
> gs/base/gdevp14.h
> gs/base/gxclrast.c
> gs/base/gxclread.c

2015-02-23 12:18:01 -0800
Michael Vrhel <michael.vrhel@artifex.com>
1dca5f29bf59d3071021a3ba4b7378e60d0e7a10

> Fixes for named color support
> A few minor fixes for named color support including the detection of the
> None colorant in the DeviceN list of colorants. Making sure that the
> equivalent CMYK color is correctly computed. Make sure that all the
> colorants in the device are cleared out prior to setting the ones
> associated with the device profile in the example code given in
> gsicc_transform_named_color.
> gs/base/gsequivc.c
> gs/base/gsequivc.h
> gs/base/gsicc_cache.c
> gs/base/gxcmap.c

2015-02-23 10:15:02 -0800
Michael Vrhel <michael.vrhel@artifex.com>
46b59d18a8f4d204e83327e135c17657caefde3a

> Fix issues with sICCOutputColors option
> If an NCLR ICC profile is specified for output then it is also
> possible to specify the colorant names associated with the profile.
> This information is described by the sICCOutputColors parameter.
> There was an issue where the default colorant names AND the
> colorant names specified by sICCOutputColors were getting
> added to the device. With this fix only the colorants specified
> by sICCOutputColors are added to the device.
> gs/base/gsdparam.c
> gs/base/gsicc_manage.c
> gs/devices/gdevpsd.c

2015-02-23 12:30:30 +0000
Chris Liddell <chris.liddell@artifex.com>
375752983d9373b28bf1fada04fc9325673bc51c

> Bug 695516: fix psl.dev/psbase.dev deps snafu....
> And also tidy dependency for PDF interpreter.
> No cluster differences
> gs/psi/int.mak

2015-02-23 11:49:08 +0000
Ken Sharp <ken.sharp@artifex.com>
1125d53f8db9f7402f37fa8fe7823257e4c6554a

> PDF Interpreter - fix some kinds of FreeText processing
> Bug 695848 "Ghostscript decode error when opening PDF"
> The processing of the Default Appearance was mishandling some colour
> specifications. It was expecting arrays for all operators, when in fact only
> the (undocumented ?) 'r' operator takes an array, all the others simply
> take a sequence of values.
> gs/Resource/Init/pdf_draw.ps

2015-02-20 15:05:51 -0800
Michael Vrhel <michael.vrhel@artifex.com>
6ab5713f556bde0be38fa411e2eb1d25eb73e2c5

> Use different remap proc for indexed color space when dealing with named colors
> Currently the Index color space uses gx_default_remap_color for its remap procedure.
> This is a problem for when we are dealing with an index color whose base space
> is DeviceN and we are doing named color replacement in our color management. To
> fix this, we introduce a different version of the Indexed color space that is installed
> with a different remap proc for the case when we have a index color space whose
> base space is DeviceN or Separation AND we have specified a named color ICC profile.
> gs/base/gscolor2.c
> gs/base/gscolor2.h
> gs/psi/zcolor.c

2015-02-20 14:23:56 -0800
Michael Vrhel <michael.vrhel@artifex.com>
033cf566b74c7e12bfb82d9b63a7bc680c51c5f8

> Add LockColorants option to tiffsep and psdcmyk devices
> If someone specifies a list of colorants using something like this
> -c "<< /SeparationColorNames [ /Cyan /Magenta /Yellow /Black /Violet /Orange]
> /SeparationOrder [ /Cyan /Magenta /Yellow /Black /Violet /Orange]>> setpagedevice"
> on the command line, it would be nice if they also had the option to
> keep the colorants to only this set for the tiffsep and psdcmyk devices.
> Currently, the list of colorants above would be included as well as any that
> are encountered in the document (up to a max of 64). In some cases, this
> may be the desired outcome. In other cases, the user may like to keep the colorants
> to only those set by SeparationColorNames. Toward that end, this commits adds
> a -dLockColorants=true/false option for the tiffsep and psdcmyk devices to
> ensure that the devices do not add on additional colorants as they are
> encountered in the document.
> gs/devices/gdevpsd.c
> gs/devices/gdevtsep.c

2015-02-20 09:51:50 +0000
Chris Liddell <chris.liddell@artifex.com>
5135b9cd1a26332af64ff3a770103d8d8ad001a0

> Bug 695842: cope with no pread/pwrite available
> Older Unix and Linux systems for example.
> Without pread/pwrite we also disable multithreading support.
> No cluster differences
> config.mak.in
> configure.ac
> gs/Makefile.in
> gs/base/gp_unifs.c
> gs/configure.ac

2015-02-20 11:32:34 +0000
Chris Liddell <chris.liddell@artifex.com>
93ceb24e53ac62b5d6ac338dd8983e2e2a15eaad

> Cope with systems with inttypes.h that doesn't define PRI..
> The PRI... macros for printf formatting aren't always available, so cope better with that.
> Solaris, for example.
> No cluster differences
> gs/base/stdint_.h

2015-02-20 11:30:26 +0000
Chris Liddell <chris.liddell@artifex.com>
5c7b12b0bfd990329b6ecd009afbfc4f037e8b48

> Cope with systems without strnlen.
> We'll use strnlen in preference, but replace it with strlen if strnlen isn't available.
> An example would be Sun cc on Solaris.
> No cluster differences
> configure.ac
> gs/configure.ac

2015-02-18 15:57:29 +0000
Chris Liddell <chris.liddell@artifex.com>
1e7626e4a9db58f9e5a531c04233bc8b04c52b1f

> Bug 695836: add flag for MINGW binary file opening
> MINGW, being a unix-like API on Windows, using the file handling gp_unifn.c,
> but unlike "real" Unix systems, requires an extra flag for opening binary
> files.
> Add that conditional on being built for MINGW
> No cluster differences.
> gs/base/gp_unifn.c

2015-02-16 10:13:58 +0000
Ken Sharp <ken.sharp@artifex.com>
f27d8957a6afde54c0105fe6599b175b7ec46540

> Increase the linewidth used in idiom recognition of artificial bold text
> Bug #695835 "Artificially emboldened fonts not showing up as bold in output PDF"
> I believe this to be an Acrobat display bug, different versions of Acrobat
> display the result differently, modifying the viewer preferences alters the
> boldness significantly, and opening another file also alters the displayed
> boldness.
> However, I've opted to increase the linewidth we are using slightly. This
> results in a few single pixel differences in our output. At 600 dpi the
> test file is slightly bolder, about 1 pixel worth.
> Comparison against the PostScript output is slightly complicated, because
> the 'fill and stroke' results in slightly smoother output than the 'draw
> the glyph 4 times' approach. However, there is little significant difference
> as far as I can tell.
> gs/Resource/IdiomSet/Pscript5Idiom

2015-02-12 17:09:40 -0700
Henry Stiles <henry.stiles@artifex.com>
7b3af6d5075a23cd6b5ef199e7680be8ab1045a6

> Fixes bug #695833 to correctly select the Line Printer font instead of
> Courier.
> We need to have a LinePrinter font entry in the font table for each
> symbol set supported by LinePrinter. We were missing an entry for the
> PS text (10J) symbol set.
> pl/plftable.h

2015-02-12 13:24:58 +0000
Ken Sharp <ken.sharp@artifex.com>
4264a0716724dbd7fd8e35a53572e262658d5979

> Fix error recovery after invalid type 1c (CFF) font
> Bug #695819 "Ghostscript cannot process font stream"
> The PDF file (which purports to have been produced by an earlier version
> of Ghostscript) contains a CFF font which has en empty names index.
> Ghostscript, not unreasonably, treats this as being 'the first byte of the
> name is 0x00' which indicates a font which has been deleted from the
> FontSet. This means that the embedded FontSet contains no fonts.
> Since there are on fonts, we obviously can't use the font stream, and so
> we enter an error recovery process. This exposes a problem specific to
> this type of font, failing in this fashion, which left the operand stack
> in a condition where we were unable to recover from the error.
> This commit detects the error condition at an earlier stage and prevents
> the change to the operand stack, which allows the missing font to be
> substituted, and the file runs to completion.
> No differences expected.
> gs/Resource/Init/pdf_font.ps

2015-02-10 10:30:53 -0800
Michael Vrhel <michael.vrhel@artifex.com>
40e783f0274ede8a5a15caf878bd18cad1bfa690

> Fix for crash issue in -dUseFastColor
> The noncm link was storing the target device color mapping procs
> and using those to map the colors. The problem is that some devices
> (for example tiffsep) rely upon special device structures to
> do the mapping. When we had a forwarding device like the overprint
> device in front of the target, we were calling the target mapping
> procs where we should be calling the overprint device mapping procs.
> This commit fixes the issue.
> gs/base/gsicc_nocm.c

2015-02-09 11:04:27 -0800
Michael Vrhel <michael.vrhel@artifex.com>
14ea68e33fa129addf3860e3bf760060aa100ce3

> Fixes for named color replacement.
> The sample code for named color replacement had several issues
> that this commits fixes.
> 1) The memory allocations were not being done in non-gc memory.
> 2) There needed to be a release method to free the allocations
> when we are done with the named color profile structure.
> Since this is a "custom" profile, the release procedure for
> a profile was added as a member variable to the profile structure.
> 3) The decision to use the named color profile was moved earlier
> in the ghostscript color remapping logic. The ensures we
> have better control and avoid unwanted multiple remaps.
> Once the color is assigned values by the call to
> gsicc_transform_named_color in gx_remap_named_color, note
> that in gx_remap_concrete_devicen the transfer functions are applied.
> Also note that in gx_remap_concrete_devicen we will end up doing
> a possible ICC mapping of just the CMYK values from source CMYK to
> destination CMYK via the call to devicen_icc_cmyk. The reason for
> this is explained by the large comment in that part of the code.
> If this remap is not desired, for example if gx_remap_named_color
> assigned the CMYK values in the destination space already, then
> this mapping should be disabled. The decision to enable or disable
> is a design/customization decision of which the developer should be aware.
> gs/base/gscdevn.c
> gs/base/gscms.h
> gs/base/gscsepr.c
> gs/base/gsicc_cache.c
> gs/base/gsicc_manage.c
> gs/base/gxcmap.c
> gs/base/gxcspace.h

2015-02-05 17:21:51 +0000
Ken Sharp <ken.sharp@artifex.com>
17131c7a7fdf9d8537c4715e538c49b29c8945a8

> Improve high level devices handling of Forms
> Bug #695805 "PostScript can defeat the code to spot PostScript forms being run multiple times "
> High level devices (eg pdfwrite) already check Forms to see if they are
> duplicates, and if so use the initial definition. However, this does not
> improve performance, since the Form PaintProc still needs to be executed
> for each instance of the Form.
> This commit adds two new spec_op enums, and uses them to improve performance
> as well, but *only* for high level devices.
> After running a PaintProc, the PostScript .execform1 procedure now sends a
> spec_op to the device requesting an integer ID to store in the Form. If the
> device does not do its own form caching it will return -1, in which case
> the PostScript will not store the value.
> Each time a Form is executed, the PostScript code will look to see if we
> have a non-null value stored for the Implementation key in the Form dictioanry.
> If so, then we assume its a dictionary (ideally we should check, but this is
> all tightly coupled code), pull the /FormID from it, and then send another
> (different) spec_op to the device. On receipt of this the device simply
> reuses its stored Form.
> This absolves us from running the PaintProc again, which on some files can
> have significant performance benefits. It also means that even Forms which
> execute pdfmarks (as the original file does) will be recognised as the same
> form, which the duplicate removal code cannot achieve.
> The customer's test file runs in ~16 seconds now,producing a 4.3 Mb output
> file, previously this produced an 81 Mb file and took around 20 minutes.
> gs/Resource/Init/gs_lev2.ps
> gs/base/gsform1.h
> gs/base/gxdevsop.h
> gs/devices/vector/gdevpdfb.h
> gs/devices/vector/gdevpdfi.c
> gs/devices/vector/gdevpdfx.h
> gs/psi/zform.c

2015-01-23 09:48:50 +0000
Chris Liddell <chris.liddell@artifex.com>
be26bcf588c1dff9f8a867f764bb46b0d6389081

> Update URW fonts to Jan 2015 release.
> The families NimbusMono, NimbusRoman and NimbusSans have been augmented with
> production quality Greek and Cyrillic glyphs. These correspond to our
> substitutes for the PDF base 14 fonts
> Lots of minor pixel level cluster differences, and
> sumatra/664_-_accented_characters_missing.PDF
> is progression with previously missing accented glyphs now printing
> gs/Resource/Font/BookmanURW-DemBol
> gs/Resource/Font/BookmanURW-DemBolIta
> gs/Resource/Font/BookmanURW-Lig
> gs/Resource/Font/BookmanURW-LigIta
> gs/Resource/Font/CenturySchL-Bold
> gs/Resource/Font/CenturySchL-BoldItal
> gs/Resource/Font/CenturySchL-Ital
> gs/Resource/Font/CenturySchL-Roma
> gs/Resource/Font/CenturySchURW-Bol
> gs/Resource/Font/CenturySchURW-BolIta
> gs/Resource/Font/CenturySchURW-Ita
> gs/Resource/Font/CenturySchURW-Rom
> gs/Resource/Font/ChanceryURW-MedIta
> gs/Resource/Font/NimbusMon-Bol
> gs/Resource/Font/NimbusMon-BolObl
> gs/Resource/Font/NimbusMon-Obl
> gs/Resource/Font/NimbusMon-Reg
> gs/Resource/Font/NimbusMonL-Bold
> gs/Resource/Font/NimbusMonL-BoldObli
> gs/Resource/Font/NimbusMonL-Regu
> gs/Resource/Font/NimbusMonL-ReguObli
> gs/Resource/Font/NimbusRom-Ita
> gs/Resource/Font/NimbusRom-Med
> gs/Resource/Font/NimbusRom-MedIta
> gs/Resource/Font/NimbusRom-Reg
> gs/Resource/Font/NimbusRomNo9L-Medi
> gs/Resource/Font/NimbusRomNo9L-MediItal
> gs/Resource/Font/NimbusRomNo9L-Regu
> gs/Resource/Font/NimbusRomNo9L-ReguItal
> gs/Resource/Font/NimbusSan-Bol
> gs/Resource/Font/NimbusSan-BolIta
> gs/Resource/Font/NimbusSan-Ita
> gs/Resource/Font/NimbusSan-Reg
> gs/Resource/Font/NimbusSanL-Bold
> gs/Resource/Font/NimbusSanL-BoldCond
> gs/Resource/Font/NimbusSanL-BoldCondItal
> gs/Resource/Font/NimbusSanL-BoldItal
> gs/Resource/Font/NimbusSanL-Regu
> gs/Resource/Font/NimbusSanL-ReguCond
> gs/Resource/Font/NimbusSanL-ReguCondItal
> gs/Resource/Font/NimbusSanL-ReguItal
> gs/Resource/Font/NimbusSanNar-Bol
> gs/Resource/Font/NimbusSanNar-BolIta
> gs/Resource/Font/NimbusSanNar-Ita
> gs/Resource/Font/NimbusSanNar-Reg
> gs/Resource/Font/PalladioURW-Bol
> gs/Resource/Font/PalladioURW-BolIta
> gs/Resource/Font/PalladioURW-Ita
> gs/Resource/Font/PalladioURW-Rom
> gs/Resource/Font/URWBookmanL-DemiBold
> gs/Resource/Font/URWBookmanL-DemiBoldItal
> gs/Resource/Font/URWBookmanL-Ligh
> gs/Resource/Font/URWBookmanL-LighItal
> gs/Resource/Font/URWChanceryL-MediItal
> gs/Resource/Font/URWGothic-Boo
> gs/Resource/Font/URWGothic-BooObl
> gs/Resource/Font/URWGothic-Dem
> gs/Resource/Font/URWGothic-DemObl
> gs/Resource/Font/URWGothicL-Book
> gs/Resource/Font/URWGothicL-BookObli
> gs/Resource/Font/URWGothicL-Demi
> gs/Resource/Font/URWGothicL-DemiObli
> gs/Resource/Font/URWPalladioL-Bold
> gs/Resource/Font/URWPalladioL-BoldItal
> gs/Resource/Font/URWPalladioL-Ital
> gs/Resource/Font/URWPalladioL-Roma
> gs/Resource/Init/Fontmap.GS
> gs/psi/psromfs.mak

2015-02-03 16:05:55 +0000
Chris Liddell <chris.liddell@artifex.com>
af9d47bf4ed5ebe42c1b2592a607bd891cd1dd92

> Bug 695787: skip WOFF fonts in font scanning
> As Ghostscript doesn't support WOFF fonts, skip them during the building of the
> "native" fonts table - this prevents the pseudo-parsing from consuming large
> amounts of memory and processor time pointlessly.
> No cluster differences.
> gs/Resource/Init/gs_fonts.ps
> gs/Resource/Init/gs_ttf.ps

2015-02-02 13:31:32 +0000
Ken Sharp <ken.sharp@artifex.com>
8803294d1768a74a2ca3a1acc97f7def74752791

> commit 23aab341f57c20974e4dfcb68abb13ce08c5e5a8 actually committed the wrong
> code by accident, ooops!
> This is the corrected test for a type 2 font being used. The comments in
> the previous commit still apply, this isn't a 'fix' just a work-around to
> avoid a crash.
> gs/devices/vector/gdevpdtc.c

2015-02-02 11:52:49 +0000
Ken Sharp <ken.sharp@artifex.com>
23aab341f57c20974e4dfcb68abb13ce08c5e5a8

> Noticed by chrisl while working on moving our installed base fonts to
> CFF, if a type 0 font has an FDepVector which uses both a type 3 font, and
> a base font (which is CFF) then we fail to process the condition where
> we use one glyph from the type 3 and follow it with a glyph from the
> type 2.
> The problem seems to be that we get confused, we detect the error with the
> CFF font, but instead of capturing it as a bitmap (fallback case) we end
> up dealing with it as if we had started capturing a type 3 charproc. Of
> course we didn't start capturing it that way, so that causes chaos.
> In the long run this will need to be fixed properly (ie figure out why we
> are ending the glyph with the current font being type 3, when it should be
> type 2), but for now this prevents the GPF. When/if we do move to CFF fonts
> for our base fonts, this will need to be revisited.
> gs/devices/vector/gdevpdtc.c

2015-01-29 17:33:48 -0800
Ray Johnston <ray.johnston@artifex.com>
3af4b00ad39d7c3672f3967512d81b1f8ecf6bac

> Fix some (probably not all) dependencies when the build has minimal devices.
> The lib.mak was missing some dependencies, and pdf_main.ps depended on the
> .pdfputparams which is only defined if the pdfwrite device is built in.
> Tested with a build from: autogen.sh --with-drivers=ppmraw,pgmraw,pbmraw
> which only has bbox and those devices.
> gs/Resource/Init/pdf_main.ps
> gs/base/lib.mak

2015-01-30 10:43:31 +0000
Ken Sharp <ken.sharp@artifex.com>
47178da0d32b82a40b75f9aa9684210ff4dc1d24

> Remove the reference to -dLanguageLevel=1 in the man page.
> Also remove the incorrect nonsense about language level 3 and so on, which
> has never been correct, and some general tidying up. Also point out that,
> despite the name of the scripts, PDF is an equally acceptable input.
> Update the versions and dates and so on to reflect the edit.
> gs/man/ps2ps.1

2015-01-28 08:34:08 -0800
Ray Johnston <ray.johnston@artifex.com>
704fcded8bb82dcbfad512ee8eec80e1d5655ded

> Fix miscalculation of pattern size when 'has_tags' is true.
> This fix was developed for customer 532 who uses tags. The 'has_tags'
> passed in to gx_pattern_size_estimate is a boolean, so we should adjust
> size for the extra tag byte, not the value (which doesn't have to be 1).
> gs/base/gxpcmap.c

2015-01-23 17:32:36 -0800
Ray Johnston <ray.johnston@artifex.com>
8c015519af0f14ada59399a96d0f4ffc3c9e5ccd

> Fix some debug statements that used NULL mem pointers.
> gs/base/gxipixel.c

2015-01-22 08:35:39 -0800
Ray Johnston <ray.johnston@artifex.com>
c8cf49712712f288d5b956f36ecb285a39a2b134

> Fix emprintf problem with previous commit
> gs/devices/gdevplib.c

2015-01-21 13:41:35 -0800
Ray Johnston <ray.johnston@artifex.com>
cad213c2d188e7461322ee6f810684bea5358235

> Fix BandHeight and segfault problems with plib device.
> The BandHeight will be 0 initially to convey "set it automatically
> if it isn't set on the command line. Only check once it has been
> set.
> Once past this a segfault was occurring because the mdev->line_ptrs
> never was set. This seems to have been broken by commit c4357bef
> caused by passing "mlines" into the device's setup_buf_device
> rather than NULL in the call from clist_rasterize_lines (which
> did fix another segfault).
> Since regression doesn't test this device, I don't expect any
> differences.
> gs/devices/gdevplib.c

2015-01-20 16:01:07 +0000
Chris Liddell <chris.liddell@artifex.com>
f38db629f962a599693e13b572eef9ee64412800

> Add the plib device family to build on Unix.
> No cluster differences.
> gs/configure.ac
> gs/devices/gdevplib.c

2015-01-19 11:19:08 +0000
Chris Liddell <chris.liddell@artifex.com>
4d9083d4f20d53eda3ae129cd35d1947144db743

> Commit the automake/autoconf/libtool derived files
> For ijs the build is not expected to change, and if it does, it will be very
> infrequent. So keeping the derived files in source control simplifies things.
> No cluster differences
> gs/ijs/Makefile.in
> gs/ijs/compile
> gs/ijs/config.guess
> gs/ijs/config.sub
> gs/ijs/configure
> gs/ijs/install-sh
> gs/ijs/libtool
> gs/ijs/ltmain.sh
> gs/ijs/missing

2015-01-19 11:15:02 +0000
Chris Liddell <chris.liddell@artifex.com>
c09cc83e53c9a1269e0c64fea94d9ceeafa9a494

> Remove automake version specific tests/use
> The script does unpleasant things which can cause us to attempt to use a
> specific version of automake, which should not really be needed these days.
> So we now just check that the automake version is greater than or equal to the
> version we require.
> The old method can still be accessed by invoking autogen.sh thus:
> USE_OLD=yes ./autogen.sh
> Also, reset the the minimum automake version to 1.6.
> No cluster differences.
> gs/ijs/autogen.sh
> gs/ijs/configure.ac

2015-01-21 22:34:40 +0000
Chris Liddell <chris.liddell@artifex.com>
b2d6985a0fdc20c9775e3caa2f90af039cc5e2f5

> Remove spurious debug code.
> No cluster differences.
> gs/Resource/Init/gs_type1.ps

2015-01-21 22:08:39 +0000
Chris Liddell <chris.liddell@artifex.com>
da65b995be88cfcbef7c99dbae1d15f5eb14122d

> Bug 695794: fix invalidaccess with some Type 1 fonts
> Use superexec to execute the .growput to enter the flag into the font dictionary
> that indicates we've already applied the glyph mapping augmentation. Handles
> the case that the font dictionary already readonly.
> No cluster differences.
> gs/Resource/Init/gs_type1.ps

2015-01-20 09:22:31 -0800
Ray Johnston <ray.johnston@artifex.com>
38501651d81ae41f6505e7f457f46a975648c63a

> Fix C stack overflow with psdcmykog.
> The commit fe0b8fcf increased the gp_filename_sizeof to 4096, and
> this increased the stack usage for cmykog_process_arg_t by enough
> to cause stack overflow on Windows.
> gs/devices/gdevcmykog.c

2015-01-20 09:00:31 -0800
Ray Johnston <ray.johnston@artifex.com>
a8a479e6104a509de49b0d10d8aae6cc4cd4809a

> Clean up gx_pattern_size_estimate to clamp at max_int
> When the pattern had transparency, we had conditional assignment to
> limit at (max_int * ~0xFFFF), but not otherwise. No known defect.
> gs/base/gxpcmap.c

2015-01-19 09:15:47 +0000
Chris Liddell <chris.liddell@artifex.com>
2cc3a1779d832fc84b36f0ebb20336bbdad17352

> Bug 695774: Fallback for glyph with degenerate bbox
> If a glyph has only one very narrow feature, the bbox can end up with either
> the width or height of the bbox being 0, in which case no raster memory is
> allocated and no attempt is made to render the glyph. This is less than ideal
> when the drop-out compensation in the rendering code would actually result in
> the glyph being rendered.
> Normally the coordinates for the bbox are rounded (which is technically
> correct). Now, if that results in the width or height being 0, we'll
> then try explicitly rounding up/down, providing a sort of naive whole glyph
> drop-out compensation.
> The same change has been included upstream and will be in the next scheduled
> Freetype release:
> http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=942aa5ff
> This causes a large number of low resolution differences on cluster, all
> progressions where glyphs like dash ('-'), underscore ('_') and vertical
> bar ('|') were dropping out entirely, and are now printing.
> gs/freetype/src/raster/ftrend1.c

2015-01-17 10:58:33 +0000
Ken Sharp <ken.sharp@artifex.com>
2c14b47453cc4c4bc6d6a97af073ae0145f107dd

> txtwrite - properly terminate 'char' tags
> Bug #695788 "txtwrite textoutput=0 XML file"
> The 'char' tag was being terminated with a '>' instead of a '/>'.
> Reported, and the offending code isolated, by Petko Lukov, who offered to
> create a patch, but the change is so trivial I simply went ahead with it.
> No differences expected, cluster doesn't test txtwrite.
> gs/devices/vector/gdevtxtw.c

2015-01-17 09:01:00 +0000
Chris Liddell <chris.liddell@artifex.com>
8a72aff8e6f1009cce8cf0ed535baf3d6c362fb4

> Slience a (benign) compiler warning about missing return
> No cluster differences.
> gs/psi/dxmain.c

2015-01-16 10:27:51 -0800
Ray Johnston <ray.johnston@artifex.com>
7882030e49b1309c6d8ccc96b799c8eddb0cc10d

> Improve error message when required OutputFile not specified.
> Bug 695767. Also improve the formatting when there was a filename
> by adding ' around the filename,
> gs/base/gsdevice.c

2015-01-16 15:26:56 +0000
Chris Liddell <chris.liddell@artifex.com>
66eafeeec0288a96dde38ecb406961c869ce06e4

> Move bbox.dev to be immediately after the x11 devs
> So that in pcl and xps on Unix, if we aren't including the x11 devices, we'll
> default to bbox.
> No cluster differences
> main/pcl6_gcc.mak

2015-01-16 15:18:23 +0000
Chris Liddell <chris.liddell@artifex.com>
d1ef180b6cad83dde54843e028accb22222e6f39

> Explicitly check for both libcups and libcupsimage
> No cluster differences.
> gs/configure.ac

2015-01-16 09:40:27 +0000
Ken Sharp <ken.sharp@artifex.com>
6e1e22c7643ee2e0b28a702a3ed9fc5b8f3a96b0

> NTFS - fix some memory problems Bug 695752
> Bug #695752 "gp_enumerate_files_close leaks some memory"
> This appears to be a simple oversight in the original commit, a piece of
> allocated memory was not freed, the 'free' call was commented out.
> Noticed in passing; if the allocation of the file pattern fails, we were not
> freeing the file or directory enumerators, leading to a memory leak as
> well.
> No differences expected (cluster does not test Windows file system)
> gs/base/gp_ntfs.c

2015-01-15 16:16:59 +0000
Ken Sharp <ken.sharp@artifex.com>
d9168fef51ff878e58834b38d620f4afc9fa66c2

> pdfwrite - fix compiler warning
> The compiler complained that pres could be NULL. In fact it should never be,
> it *should* be the same as pres1, but we ought to be dereferencing pres1 here
> anyway, not pres, so we make that change, just in case.
> gs/devices/vector/gdevpdfu.c

2015-01-14 10:51:21 -0800
Michael Vrhel <michael.vrhel@artifex.com>
65b46878adabda061b67670dfd81899acca2cea1

> Fix warnings from f02d0a5
> For some reason no warnings came up during the cluster push. Thanks
> to those who fixed a couple. Hopefully this fixes the rest.
> gs/base/gximdecode.c
> gs/devices/vector/gdevxps.c

2015-01-13 12:31:40 -0800
Ray Johnston <ray.johnston@artifex.com>
48eb76b5b774772e39b0a163a9a3c1d06eafbdd4

> Allow Orientation pagedevice parameter to control the FitPage rotation
> With this change, Orientation is no longer ignored except for devices
> that support pdfmark where it must be 0 (e.g., pdfwrite). Now with
> -dFitPage, -c "<< /Orientation 0 >> setpagedevice" will use either 0
> or 90 degree rotation, while -c "<< /Orientation 2 >> setpagedevice"
> will rotate either 180 degrees or 270 degrees.
> Note that Orientation 2 will invert a page (rotate by 180) if 270
> degree rotation is not needed for the best fit.
> Orientation will also control which way is "up" without -dFitPage,
> but may result in clipping.
> gs/Resource/Init/pdf_main.ps

2015-01-14 15:01:24 +0000
Chris Liddell <chris.liddell@artifex.com>
6213ab0b0c3229f1744e404e0d673d36f62bd6cd

> Treat a couple of compiler warnings as errors.
> Treat declaration-after-statement and return-type warnings as errors when
> building with gcc.
> No cluster differences.
> configure.ac
> gs/configure.ac

2015-01-14 15:01:02 +0000
Chris Liddell <chris.liddell@artifex.com>
d18f698b8e7176653d096b2e554eeff713be4182

> Fix a missing return type for a function.
> gs/devices/vector/gdevxps.c

2015-01-14 13:21:54 +0000
Ken Sharp <ken.sharp@artifex.com>
d7bffde12e3b9856e271af3b50254fd93d98b3d3

> Fix 'warning: ISO C90 forbids mixed declarations and code'
> Commit f02d0a5 added code which declares variables in the body of a
> function. This is not permitted in C90 (or C89), is contrary to the coding
> style for Ghostscript and fails to compile Ghostscript under Visual Studio.
> In addition 'zip_close_all_archive_files()' did not have a return value on
> success which led to random return values and a number of regression files
> failing.
> Moved the variables to the start of the functions (removing const as required)
> and added a specific return code on success.
> Now compiles under Windows, does not throw as many warnings on Linux and
> does not cause spurious regression failures. There are still many warnings
> produced by gcc, EG:
> ./devices/vector/gdevxps.c:1771:9: warning: unused variable 'count' [-Wunused-variable]
> ./devices/vector/gdevxps.c:1770:9: warning: unused variable 'code' [-Wunused-variable]
> The author of the commit should address those separately.
> gs/base/gximdecode.c
> gs/devices/vector/gdevxps.c

2014-12-15 12:15:14 -0800
Michael Vrhel <michael.vrhel@artifex.com>
f02d0a5067a0970aa5e9c6b4f9cd08956485447e

> Add support for encoded source images with xpswrite device. Fix for bug 695698
> Also fixes 695754 and 695680.
> The xps format does not allow for the image data encodings that PDF source files can
> create. Hence we have to decode the data prior to writing out to our TIFF file.
> The clist image code had static methods for doing the decode during color monitoring. These
> methods were re-factored to work on a new structure that are now member variables for
> the xpswrite image enum structure and the clist image enum structure. The methods and
> the structure definition were placed in their own file gximdecode.c/h
> Also this adds support for images in indexed, CIELAB, DeviceN and separation color spaces.
> Finally, images are stored in a temp file during creation and then copied into the zip
> archived, releasing the image temp file. ICC profiles are written directly from memory
> to the zip file. This avoids having lots of temp files around for each image that is
> created. A similar process needs to be done for other parts of the xps document. With the
> current architecture of having a temp file open for every "file" in the package we would
> not be able to create something larger than 512 pages on windows due to the limit on
> the number of open files.
> gs/base/gxclimag.c
> gs/base/gximdecode.c
> gs/base/gximdecode.h
> gs/base/lib.mak
> gs/devices/devs.mak
> gs/devices/vector/gdevxps.c
> gs/ghostscript.vcproj

2015-01-13 11:19:53 +0000
Ken Sharp <ken.sharp@artifex.com>
3e7115492c378ffa324c0a083244a785a6a61f82

> pdfwrite - optimise pdf_foget_resource with CharProc resources
> Bug #695778 "Long delay converting .ps file to .pdf file"
> The specimen file uses glyphshow to draw a huge number of 'characters',
> these turn out to be bitmaps which, taken together create the page. Each
> page defines and at the end specifically undefines a type 3 font and the
> glyphs are stored in this font.
> Since PDF has no equivalent to glypshow we store the glyphs in multiple
> type 3 fonts, resulting in around 10 times as many fonts. The creation and
> storage of the fonts and glyphs is quite slow.
> However, we start off unaware that this is a glyphshow operation, so we
> start by attempting to capture the type 3 CharProc. Its not until we get
> to the actual capture of the bitmap that we discover we cannot handle the
> glyph like this. That means we have to discard the CharProc we had begun,
> and remove it from the list of stored resources.
> Now resources are stored in 'chains' which is a simple way of limiting the
> number of searches. We hash on the resource ID and pick the chain based on
> that.
> The first problem was that pdf_forget_resource was not using the hash, it
> was checking every entry in every chain, in effect checking all the entries
> of a given resource type. Even if it found a match, it continued checking
> the remaining chains! As the number of stored CharProcs (we still store
> the glyphs as CharProcs, but in a different font) increases, the time taken
> to exhaustively check all the glyphs increases.
> Here we fix that by starting from the correct chain based on the hash of
> the id (if its 0 we start at the first chain, so if we haven't allocated an
> ID we check all the entries). When we find a match we return immediately
> instead of merely exiting the *inner* loop.
> The second problem is that we don't allocate an ID for CharProcs initially.
> This is fixed by storing the ID which we used temporarily as an argument
> to pdf_enter_substream.
> Taken together these speed up this file by a factor of ~8.
> No differences expected.
> gs/devices/vector/gdevpdfu.c
> gs/devices/vector/gdevpdti.c

2015-01-13 09:28:37 +0000
Chris Liddell <chris.liddell@artifex.com>
7d97b54d767627d1d88ea026c3d3accd11cb670f

> Bug 695783: correct cups return of string parameters
> The cups device was using param_string_from_string() to return string parameters
> allocated in the device structure in its get_params method. Of the many problems
> this could cause, it came to light due to the same parameter being sent through
> put_params thus causing strncpy() to attempt to copy a string to itself, causing
> a segfault.
> Changing to the correct param_string_from_transient_string() way to return such
> strings resolves the problem.
> No cluster differences.
> gs/cups/gdevcups.c

2015-01-12 11:10:04 +0000
Chris Liddell <chris.liddell@artifex.com>
f29420b18ba7abedb649d0352fb1b16adae1d4a5

> Bug 695743: LCMS: Fix a macro clash on SNONE
> Partial patch pulled from Marti's github repo:
> https://github.com/mm2/Little-CMS/commit/5bc4f52f
> (only the macro clash fix).
> No cluster differences.
> gs/lcms2/src/cmscgats.c

2015-01-12 09:56:01 +0000
Chris Liddell <chris.liddell@artifex.com>
84d749a65e509c31805a8f99d1aad78c013f13e6

> Bug 695764: allow compiler to be overridden
> Allow the C compiler to set by the configure script.
> No cluster differences.
> common/gccdefs.mak
> config.mak.in
> configure.ac

2015-01-12 08:44:46 +0000
Chris Liddell <chris.liddell@artifex.com>
e17fcc029c96949982b8f01c6e649b87dceab1be

> Bug 695772: account for clist icc_table being shared
> When multi-thread rendering is used (but not background printing), the icc_table
> is shared between all the render thread devices and the 'parent' device in the
> interpreter thread - but it is not reference counted. We rely on the fact that
> the device in the interpreter thread will exist before, and persist past the
> death of the rendering threads.
> So, when dismantling a rendering thread device, null the icc_table entry so
> it doesn't get erroneously freed.
> No cluster differences.
> gs/base/gxclthrd.c

2015-01-09 11:25:01 +0000
Chris Liddell <chris.liddell@artifex.com>
30abb3d5d5fbf9cf67d4ff691e898c8b29e39a56

> Add automake option to make dist "self contained"
> The automake default is to symlink to a few scripts ('compile', 'missing' etc)
> in the current system's automake install. That results in a configuration
> reliant on automake being installed, and the same version, for a build.
> Add the '--copy' automake option so the script files are copied rather than
> linked, so we get a self contained configure/make/install setup.
> No cluster differences.
> gs/ijs/autogen.sh

2015-01-09 11:23:34 +0000
Chris Liddell <chris.liddell@artifex.com>
9961f351a3c71949da49eb75b65560028fb8272e

> Bug 695148: remove spec PDF and PS from clean list
> As the IJS spec hasn't changed in ages, we'll just keep the PDF and PS files
> of the spec in git, so no need to remove them with a "make clean".
> No cluster differences.
> gs/ijs/Makefile.am

2015-01-07 07:57:36 -0800
Ray Johnston <ray.johnston@artifex.com>
d78594c1982682a06c9fb8fc7f2ea746938a93cc

> Fix problem in xps_zip_alloc_items caused by previous commit: 188c7b0
> When the allocation succeeded, nothing was returned.
> xps/xpszip.c

2015-01-03 16:00:16 -0800
Ray Johnston <ray.johnston@artifex.com>
188c7b05a5c232ba43e6b3172023498f7aa72c70

> Fix segfault with ppmraw -r300 from fts_06_0626.pdf.xpse when allocation fails
> The gxps had numerous places where allocation failures were ignored,
> writing to RAM at offsets from 0 (NULL). This no longer fails, but the
> fixes are not yet complete. Running a memento build with the parameters:
> MEMENTO_SQUEEZEAT=1 gxps -o /dev/null -sDEVICE=ppmraw in.xps
> xps/xpsdoc.c
> xps/xpsfont.c
> xps/xpsgradient.c
> xps/xpshash.c
> xps/xpsimage.c
> xps/xpsjpeg.c
> xps/xpsjxr.c
> xps/xpspath.c
> xps/xpspng.c
> xps/xpsresource.c
> xps/xpstiff.c
> xps/xpsxml.c
> xps/xpszip.c

2015-01-02 22:48:56 -0800
Ray Johnston <ray.johnston@artifex.com>
f553eec30efa8cbefdc3c3635e090abb915a1a9d

> Fix bug 695373: xpswrite leaves temp files on Windows.
> There is a recent addidtion of a gp function to open a temp file that
> will be deleted upon close: 'gp_open_scratch_file_rm'. The method of
> 'unlink' after open does not work on Windows. This function is platform
> specific and works on all supported platforms even if the process crashes.
> Also get rid of confusing error messages. PageSpotColors is now only
> given to devices that support it (pdf_main.ps) and NumRenderingThreads
> and BGPrint are ignored for vector devices (gdevvec.c).
> gs/Resource/Init/pdf_main.ps
> gs/base/gdevvec.c
> gs/devices/vector/gdevxps.c

2014-11-24 11:13:33 -0800
Ray Johnston <ray.johnston@artifex.com>
64f9cafcfc594ddaa1d1981a16f45fce25e4fb18

> Fix BGPrint=true SEGV and slowdown due to commit 9108db2
> Bug 695669:
> The BGPrint problem was due to using the fname afer freeing it but the
> 'fake_path_to_file' logic needed the fname in order to find the real
> file to close.
> Tail of commit 6ecc8536:
> Also the original cfname and bfname (ocfname and obfname) were copied
> using strnlen so the trailing NULL wasn't copied resulting in UMR being
> used for the close/delete.
> Tail of bug 693121:
> The performance of unbuffered I/O is slow, seen on many files, but
> a good example is: tests/df/Bug6901014_Fourth_crash_signature_testcase.pdf
> with params: -sDEVICE=pbmraw -o /dev/null -r300 -dMaxBitmap=0
> The fix for this is to add a read cache. This caching method in intended
> to also be used by the memory based clist logic (TBI).
> With the cache, the performance on the above goes from 40 seconds down to
> 4.6 seconds, and with -dBGPrint=true reduces to 3.8 seconds (which crashes
> prior to this fix).
> gs/base/gdevprn.c
> gs/base/gxclfile.c
> gs/base/gxclist.c

2014-12-30 09:18:31 -0700
Henry Stiles <henry.stiles@artifex.com>
7631204934e5d8b0bcdb13d8691370365eb84b2b

> Add directory entry configuration support to fix a broken ghostpdl
> build after a Mac upgrade to Yosemite.
> configure.ac

2014-12-23 16:01:05 +0000
Ken Sharp <ken.sharp@artifex.com>
35bb14eaf871b6a7e41e17688bcc41a1fb4da595

> pdfwrite - add 'Launch' Actions
> Bug #695715 "Launch action link annotations removed after GS processing"
> Add Launch actions to the PDF interpreter, for both annotations and
> outlines.
> No differences expected.
> gs/Resource/Init/pdf_main.ps

2014-12-23 13:53:27 +0000
Ken Sharp <ken.sharp@artifex.com>
fde4b9b183a140b8906874d0bf56d258b488d4b9

> pdfwrite - free copied base fonts on exit
> Bug #695753 "Segfault in gs_purge_font_from_char_caches_forced with -Z@"
> The problem here is that we free copied fonts when we free the associated
> FontDescriptor (because until then we need the copied font). However, if
> we have a 'base 14' font, or other font which is not embedded, we do not
> create a FontDescriptor, and so never free the font copy we take when the
> font is used.
> This later causes a problem because when the garbage collector frees this
> font copy it is still pointing to a font cache which no longer exists.
> This commit tests to see if a FontDescriptor is associated with a font when
> we free the (PDF) font. If it is not then we free the copied font there and
> then, as well as the ancillary bytes used for the font name etc.
> No differences expected.
> gs/devices/vector/gdevpdtf.c

2014-12-23 13:08:08 +0000
Ken Sharp <ken.sharp@artifex.com>
bd2e9c2c30b0696ca9f929637193aaef38951e6a

> follow up to commit dc2c3634aeae6634b130e124b1f0997f17ee3141
> Separate GoTo and GoToR processing for links as well as Outlines
> gs/Resource/Init/pdf_main.ps

2014-12-22 11:29:49 +0000
Ken Sharp <ken.sharp@artifex.com>
01b9c47eefd7f88195e71f877e5ea44f183a0067

> pdfwrite - when writing Names array use better method to find /Last
> Bug #695704 "GS 9.15 (still) breaks *something* in hyperref-generated pdf BOOKMARKS"
> The find_last_dict_entry code should have returned the same results as for
> find_next_dict_entry, but it clearly didn't, resulting in effective
> truncation of the Names array.
> Simplified the code here by using find_next_dict_entry in a loop to locate
> the last entry. This should mean we cannot be out of sync, the code is simpler
> and easier to follow.
> No differences expected.
> gs/devices/vector/gdevpdfo.c

2014-12-22 10:47:22 +0000
Ken Sharp <ken.sharp@artifex.com>
dc2c3634aeae6634b130e124b1f0997f17ee3141

> pdfwrite - separate GoTo and GoToR processing
> Because we convert any named destination in a GoTo to a specific internal
> destination, we cannot handle GoTo and GoToR in the same way. Here we
> split the two again, and this time add a comment so we don't end up merging
> them again by mistake.
> No differences expected.
> gs/Resource/Init/pdf_main.ps

2014-12-20 10:57:39 +0000
Ken Sharp <ken.sharp@artifex.com>
2c525aa076d7094fa487621602b8e326c58eeabe

> pdfwrite - improve Goto and GoToR handling
> Bug #695747 "git produces broken pdf from pdfTeX output"
> The original code for generating pdfmarks from the equivalent annotations
> in a PDF file did not properly create an Action dictionary, which caused
> /D and /Dest entries to be removed.
> Here we handle this more cleanly, and properly create the Action dictionary
> NB for ps2write this relies upon commit b5a4f24141ab47b5ba2b7b3dff938ba30a8a908a
> being present, in order to deal with the empty objects produced by ps2write.
> No differences expected.
> gs/Resource/Init/pdf_main.ps

2014-12-20 10:53:28 +0000
Ken Sharp <ken.sharp@artifex.com>
b5a4f24141ab47b5ba2b7b3dff938ba30a8a908a

> ps2write - handle empty object definitions
> object definitions such as:
> 5 0 obj
> endobj
> cause errors. Handle this by checking in /endobj to see if the stack count
> is 1 (only the object number is present) and if so, do not attempt to
> define the object.
> gs/devices/vector/opdfread.h
> gs/lib/opdfread.ps

2014-12-19 13:10:03 -0700
Henry Stiles <henry.stiles@artifex.com>
7df6f9570c00c34a3e1d6c74d66186a371208f0e

> Integrate Ken Sharp's solution to preserve PCL transparent text in
> pdfwrite to fix bug #695731.
> PCL characters are rendered transparently when the current color is
> white and pattern transparency is on. Usually this is done by simply
> not printing or rendering the effected text. For high level devices
> like pdfwrite we try to preserve the original intent of the source
> document and include the text and transparency setting in the output.
> pcl/pcl.mak
> pcl/pctext.c

2014-12-19 15:31:24 +0000
Chris Liddell <chris.liddell@artifex.com>
9b3669dbcd3d29cd212e9961fcfc7b98780aa408

> Add link to description of "Vienna" naming style
> After a discussion on IRC: a summary of the "Vienna naming style" is actually
> later in the document, this just adds a link between the early reference and
> the fuller summary.
> No cluster differences.
> gs/doc/Ps-style.htm

2014-12-18 17:12:49 +0000
Chris Liddell <chris.liddell@artifex.com>
09def28ae012fc0e1b4f65ea55b19639c7737bc9

> Bug 695750: fix icc link cache leak when freeing clist devices
> No cluster differences.
> gs/base/gdevprn.c

2014-11-24 22:47:15 -0700
Henry Stiles <henry.stiles@artifex.com>
5ddbec6f11792e2fa974c95924a984f876a9a705

> Simplify rectangle output to be vertical and horizontal lines instead
> of general lines.
> The vertical and horizontal line commands take 1 argument resulting in
> more compact XPS and we'd expect it to be faster when rendered.
> gs/devices/vector/gdevxps.c

2014-12-18 11:35:44 +0000
Ken Sharp <ken.sharp@artifex.com>
8e196062593b295421b869db9d5cd9ab22f7205e

> pdfwrite - some changes to text handling for Tr 3
> Bug #695731 "PCL interpreter doesn't send text to the graphics library if its not visible."
> Altering the PCL interpreter to set the Text rendering mode to 3 for
> 'invisible' text demonstrated a few problems in pdfwrite.
> 1) If the last character drawn was in Tr 3, and we buffer some new text in
> Tr mode 0, but we are inside a gsave, and the outer state is Tr 0, then when
> we restore back to the Tr 0 the mode is not emitted for the buffered text. Leaving
> it as Tr mode 3. To fix this (and potentially other similar graphics state
> problems) we now call sync_text_state when we reset text, this will
> potentially flush the text buffer as well.
> 2) We were not using the text rendering mode from the graphics state when
> falling back to a type 3 bitmap font, because the character code was out
> of range (falling back for other reasons *did* preserve it).
> This commit fixes these two problems.
> Because of the change to text flushing some text is being drawn 1 pixel different
> in location, presumably due to rounding differences, I've reviewed these
> and they look fine to me.
> gs/devices/vector/gdevpdf.c
> gs/devices/vector/gdevpdti.c

2014-12-17 20:48:42 +0000
Chris Liddell <chris.liddell@artifex.com>
06a462093e4145073a61e6ca62aabbb343e39fa1

> Bug 695745: apply resourcestatus hook only once.
> pdfwrite requires that Type 32 fonts be disabled, and it does it by hooking
> the resourcestatus operator. The problem is, because we always append
> to the operator table, if we string a number PS files together from the
> PScript5.dll, we can end up overflowing the operator table by repeatedly
> doing the resourcestatus hook.
> This just puts a boolean into systemdict to note that we're already applied
> the hook, and there don't do it again.
> No cluster differences.
> gs/Resource/Init/gs_pdfwr.ps

2014-12-15 08:21:18 +0000
Ken Sharp <ken.sharp@artifex.com>
07150250834717499b74c87d00a8dc52599d33ec

> pdfwrite - pass imager state through coloured patterns as well
> commit eef2764 passed the imager state through to the underlying routines
> for uncolored patterns. This commit extends the same change to include
> coloured patterns.
> No differences expected.
> gs/devices/vector/gdevpdfg.c
> gs/devices/vector/gdevpdfg.h
> gs/devices/vector/gdevpdfv.c

2014-12-13 12:24:11 +0000
Ken Sharp <ken.sharp@artifex.com>
3570b4830e7f54f3a057176bc01db04ec311fe23

> pdfwrite - increase predefined minimum CompatiblityLevel
> To avoid having to create V2 profiles, increase the minimum value of
> CompatibilityLevel in the predefined PDFSETTINGS to 1.5
> No differences expected
> gs/Resource/Init/gs_pdfwr.ps

2014-12-13 11:16:08 +0000
Ken Sharp <ken.sharp@artifex.com>
eef2764f3f9ab6dac88ea6720a05693c1d19af43

> pdfwrite porpagate the imager state through the pdfwrite Pattern code.
> Bug #695733 "Error using pattern under odd conditions"
> If we set UseCIEColor, so that all colours are converted into CIEBased spaces,
> *and* we set CompatibilityLevel < 1.5 so that we require to convert ICCBased
> profiles to V2, and then use a Pattern colour space, pdfwrite throws an
> error.
> This is because we were not propagating the image state through the pattern
> code, and the new colour code requires the imager state in order to generate
> a V2 ICC profile for inclusion in the PDF file.
> Here we simply pass the imager state through for use.
> No differences expected
> gs/devices/vector/gdevpdfc.c
> gs/devices/vector/gdevpdfg.c
> gs/devices/vector/gdevpdfg.h
> gs/devices/vector/gdevpdfv.c

2014-12-12 13:09:43 -0800
Michael Vrhel <michael.vrhel@artifex.com>
e153528e1f5044d2018284fbf2eea45b545232fe

> xpswrite device: fix for missing images.
> Force vector device to do new path as the clip path is the image path.
> I had a case where the clip path ids were the same but the CTM was changing
> which resulted in subsequent images coming up missing on the page. i.e. only
> the first one was shown.
> gs/devices/vector/gdevxps.c

2014-12-12 10:20:31 -0800
Michael Vrhel <michael.vrhel@artifex.com>
36c89af1edf269fe68f61c48326ff257862e274d

> Fix for broken make file introduced in 878ef4d48a0aebc9354ccd09443a1a52ad93c9a0.
> When adding the libtiff capability into the xpswrite device, I failed to update the devs.mak
> file. This broke the Windows release 64x build. Not sure why the other platforms were also
> not broken. Likely something is not getting cleaned up during a clean and rebuild.
> gs/devices/devs.mak
> gs/devices/vector/gdevxps.c

2014-12-11 12:07:15 +0000
Chris Liddell <chris.liddell@artifex.com>
27ce88cce7024691f292071cb602c119afc91f61

> Bug 694509: Fix file name "building" for resources
> After we'd created a candidate file name, there was a spurious "exch" in
> place before we actually tried to validate the file name.
> So, instead of "<path-to-resources>/<Resource Category>/<Resource Instance>"
> being passed to .libfile, we actually passed the Postscript "path":
> "<Resource Category>/<Resource Instance>"
> Simply removing the exch seems to resolve this bug for me.
> No cluster differences.
> gs/Resource/Init/gs_res.ps

2014-12-05 13:59:31 +0000
Chris Liddell <chris.liddell@artifex.com>
dbcb29d2508de6ea997cf07d0987c107cd754cfb

> Bug 695711: Resolve issue with relative paths for FONTPATH
> Check whether a "lib" file exists, and whether we are allowed to open it,
> before we try to open it.
> This reverts ""starting_arg_file" should only apply once." (commit
> 407cc61e87b0fd9d44d72ca740af7d3c85dee78d).
> Which caused problems with, for example, the "-sFONTPATH=..." option when the
> path is relative rather than absolute.
> No cluster differences.
> gs/psi/imainarg.c
> gs/psi/zfile.c

2014-12-04 08:24:32 +0000
Chris Liddell <chris.liddell@artifex.com>
ac4bfb62efdef25bf6d60c7f6a985dc6344891ca

> Bug 695712: Revise glyph name map generation for TT fonts
> Reinstate the unicode cmap and formatted "uniXXXX" glyph name methods of
> finding glyph name maps, but in a more efficient method than the original
> implementation.
> No cluster differences.
> gs/Resource/Init/gs_ttf.ps

2014-12-11 14:45:36 +0000
Ken Sharp <ken.sharp@artifex.com>
2207f06c5647e4308622733df854e49e2d48c97f

> Handle a 'q' during the course of a 'W.....n' sequence
> Bug #695723 "Inverted images when converting PDF to Tiff (B&W)"
> The 'W' (and W*) operators are unlike their PostScript equivalents, and all
> other PDF operators, they don't take effect immediately they simply add to
> the clip path and produce a new clip path. Not until the 'n' is executed do
> they actually apply the clip path. The Ghostscript PDF interpreter handles
> this by accumulating the path operations (W/W*) until a 'n' is encountered.
> Normally nothing else would need to be done, but because we've seen broken
> PDF files that change the graphics state while accumulating a clip, and we
> know that Acrobat ignores these, we have to track this. We do this by using
> a dictionary.
> So each graphics state operator checks the current dictionary to see if we
> are inside a 'W' context and if so emits a warning and drops the change.
> Again, so far so good.
> However, the 'q' starts a new dictionary (pushing the existing 'W' one back
> one level), which means that the 'n' operator closes that new dictionary
> instead of the one it should close, and that brings the 'W' dictionary back
> to the front.
> Now when we execute the '1 1 1 rg' it looks at the dictionary and says "aha,
> we are in a 'W' state, so ignore this".
> This commit has the 'q' operator check to see if we are in a 'W' context. If
> we are we copy the context dictionary to the stack, and close it. Then we
> start the q 'nodict' dictionary. Finally we reopen the 'W' dictionary from
> the stack. Now the 'n' will correctly close the 'W' dictionary, leaving the
> 'nodict' in its place.
> No differences expected.
> gs/Resource/Init/pdf_ops.ps

2014-10-31 13:30:04 +0000
Chris Liddell <chris.liddell@artifex.com>
813dc08154a525e5acca20b5da446eb58199680f

> Update jbig2dec version and CHANGES file
> No cluster differences
> gs/jbig2dec/CHANGES
> gs/jbig2dec/config_win32.h
> gs/jbig2dec/configure.ac
> gs/jbig2dec/jbig2dec.1

2014-11-19 15:02:22 +0000
Chris Liddell <chris.liddell@artifex.com>
66710da50af90cca72c2c8ea4942f3c4a23c9e5b

> Bug 695688: improve cidfmap record validation.
> The previous record validation only checked for valid substitutions when the
> substitution referenced a TTF file (and removed the mapping if the TTF file was
> not available). It ignored name to name mappings.
> This revision adds validation to the name to name mappings, again removing
> ones found to be invalid.
> No cluster differences.
> gs/Resource/Init/gs_cidfm.ps

2014-09-24 12:30:27 -0700
Michael Vrhel <michael.vrhel@artifex.com>
878ef4d48a0aebc9354ccd09443a1a52ad93c9a0

> Add high level image handling to xpswrite device.
> This adds the ability to create high level image content with the XPS write device.
> It includes the writing of the ICC profile for the image and will support gray, rgb,
> and cmyk images. Currently it only supports 8 bit per color channel bit depth.
> Conflicts:
> gs/devices/vector/gdevxps.c
> gs/base/gsicc_cache.c
> gs/base/gsicc_cache.h
> gs/base/gsicc_create.c
> gs/devices/vector/gdevxps.c
> gs/ghostscript.vcproj

2014-11-18 09:16:05 +0000
Ken Sharp <ken.sharp@artifex.com>
a476643d942cfbcc6f68e7470e0d8425d31435ce

> Documentation - remove some odd switches from examples in ps2pdf.htm
> gs/doc/Ps2pdf.htm

2014-11-17 11:33:42 -0800
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
7d5a454da233c45775f640f251cec5c035e1ee55

> Minor fixes to clusterpush documentation (done primarily to force an update of md5sums).
> gs/toolbin/localcluster/clusterpush.pl
> gs/toolbin/localcluster/clusterpush.txt

2014-11-17 14:22:44 +0000
Ken Sharp <ken.sharp@artifex.com>
abcaeaace08efa5d1596ef6a50f3d809d0b07a4a

> pdfwrite - remove the force to the old CMS for PDF/A-1
> Before we could guarantee a V2 ICC profile we forced the CMS to be the old
> version for PDF/A-1. Now that we can guarantee a V2 profile this is no longer
> required, and is removed here.
> No differences expected.
> gs/devices/vector/gdevpdfp.c

2014-11-14 12:15:45 -0800
Ray Johnston <ray.johnston@artifex.com>
4a37526a0606a29f0f0a86cd4b815ec7d966a1a0

> Improve performance of PDF TJ operator to avoid repeated setfillstate
> Add TextFillStateNeeded and add settextfillstate that conditionally
> performs setfillstate only once for the operations.
> gs/Resource/Init/pdf_ops.ps

2014-11-13 14:30:37 -0700
Henry Stiles <henry.stiles@artifex.com>
b669cfb4d3805adbcc2d7d7a3fa9fad3e9645aa1

> Warning cleanup and remove an obsolete PCL XL colorspace type.
> gs/base/gdevpxen.h
> pcl/pcfsel.c
> pcl/pglabel.c
> pl/plftable.h
> pxl/pxgstate.c
> pxl/pxink.c
> pxl/pxptable.c

2014-11-12 23:03:50 -0800
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
a814674105d9b57d5751e21d4a803df9fa4a4856

> Added xpswrite option to clusterpush.pl.
> gs/toolbin/localcluster/clusterpush.pl

2014-11-12 16:50:50 -0700
Henry Stiles <henry.stiles@artifex.com>
40bc5a9477192f663d66ffcad75cd14d7dac43ab

> Fix 695673: symbol set not used correctly.
> If we don't support a requested symbol set we map the font directly
> with the character codes, i.e. the symbol mapping is identity. Due to
> an historical artifact we used to map symbol and wingding fonts
> without symbol sets by just adding 0xf000 to the input character code,
> thus evolved the conditional to check if the font is internal and the
> symbol set is 0 just add 0xf000 because it must be a wingdings or
> symbol font. Of course that is wrong even if very rarely encountered,
> and unnecessary because we've added the symbols sets needed to support
> wingdings and symbol.
> pcl/pctext.c
> pcl/pglabel.c
> pl/plsymbol.c
> pl/plsymbol.h
> pxl/pxfont.c

2014-11-10 14:31:44 +0000
Ken Sharp <ken.sharp@artifex.com>
c98c38c8b9912fc3510ef2e1e53c3ff1837b0519

> eps2write - don't clamp text BBox to the text enumerator origin
> Bug #695671 "eps2write gives incorrect bounding box with rotated text"
> The bug here is that, having gone to some effort to retrieve the bounding
> box of the text, the code then clamps the origin of the text box to the
> origin of the text enumerator.
> This is clearly incorrect for rotated text, and I'm doubtful it makes sense
> even for upright text. I'm somewhat puzzled because it looks quite deliberate
> but I don't see why, and my testing shows no differences if I don't do this.
> So I'm removing this for now, this may need some more attention in the future
> but then that is still generally true of the eps2write device.
> No differences expected, the eps2write device is not cluster tested.
> gs/devices/vector/gdevpdte.c

2014-11-06 09:53:05 +0000
Ken Sharp <ken.sharp@artifex.com>
b7fa37ecf0f25b125fafeed15873963853148276

> Documentation change - improve and correct MaxShadinBitmapSize documentation
> gs/doc/Ps2pdf.htm

2014-11-05 15:57:10 +0000
Ken Sharp <ken.sharp@artifex.com>
7bdf34b3dfd52e3897cef02e7c540270c10e2349

> PDF Interpreter - run annotations in a stopped context for error-and-continue
> Bug #695453 "Conversion to png fails with undefinedresult in --run--"
> The PDF test file was supplied privately, it contains 3 annotations, each of
> which is invalid having /Rect, /QuadPoints or /BBox arrays where each
> element is 0.
> Here we simply run the annotation inside a stopped context so that if it
> throws an error we can raise a message and carry on.
> No differences expected.
> gs/Resource/Init/pdf_main.ps

2014-11-05 10:33:15 +0000
Ken Sharp <ken.sharp@artifex.com>
25b7ec08e8fed8a69c9b3ac75fbf3ccc43693e7c

> PDF interpreter - attempt to recover from empty stream with broken endstream
> Bug #695664 "Problem reading PDF file: stream length incorrect"
> The file has an annotation with a broken stream, its empty (Length 0) and
> the endstream keyword is incorrectly written as endsteam.
> When we encounter the endobj we attempt to unwind back to the object number
> and generation on the stack, but we don't have those on the stack, so instead
> we consume the error recovery information, which then leads to the stream
> code being unable to recover from the error condition, resulting in an error.
> This change to endobj looks to see if either of the 2nd and third entries
> on the operand stack are a 'mark', and if so assumes that this is a broken
> empty stream, pops back to the mark and exits leaving cleanup to the
> stream code.
> Clearly this code can be defeated, depending on what garbage is left behind
> by the broken stream, but in general we might reasonably expect to find two
> integers before a mark object. Even if we don't, the result will still be no
> worse than at present.
> No differences expected
> gs/Resource/Init/pdf_base.ps

2014-11-03 15:36:55 +0000
Ken Sharp <ken.sharp@artifex.com>
b2a6decb294ca8c48c71da2211f3284b2334d921

> PDF interpreter - make unrecognised operators obey PDFSTOPONERROR
> Bug #695661 "Ghostscript command hangs indefinitely"
> The PDF file is badly corrupted, Acrobat fails to display most of page 27,
> MuPDF complains of zlib errors.
> Ghostscript also emits many warnings and then proceeds to spend an interminably
> long time subdividing a curve. At resolutions up to ~25 dpi its reasonably
> quick, after that its a long time indeed.
> We can't simply catch the zlib errors like MuPDF, as bug #688716 indicates
> that, under at least some conditions, Acrobat ignores these errors.
> The problem seems to be caused by the fact that the corrupted data includes
> some truly massive co-ordinates, but we can't simply ignore those either
> as a real number can vary up to +/- 3.403 x 10^38. Possibly we could limit
> numbers representing co-ordinates to 14,400, since that's the maximum
> Acrobat can use, but that would mean a *lot* of reworking in the PDF
> interpreter.
> The best I can come up with short of that is to make malformed numbers
> throw an error, and honour PDFSTOPONERROR, which to be frank should have
> been the case already.
> No differences expected.
> gs/Resource/Init/pdf_base.ps

2014-10-16 12:26:24 +0100
Chris Liddell <chris.liddell@artifex.com>
a3bb342587cc7247420a05ff2428c4c94da194c0

> Bug 695593: Add the MAKEDIRS target wherever it was missing.
> MAKEDIRS target was missing from a large number of object files and other
> files created during the build process. This could cause problems when
> running parallel make instances.
> No cluster differences.
> gs/base/expat.mak
> gs/base/fapi_bs.mak
> gs/base/freetype.mak
> gs/base/ijs.mak
> gs/base/jbig2.mak
> gs/base/jpeg.mak
> gs/base/jpegxr.mak
> gs/base/lcms2.mak
> gs/base/lcups.mak
> gs/base/lcupsi.mak
> gs/base/ldf_jb2.mak
> gs/base/lib.mak
> gs/base/lwf_jp2.mak
> gs/base/openjpeg.mak
> gs/base/png.mak
> gs/base/tiff.mak
> gs/base/trio.mak
> gs/base/unix-aux.mak
> gs/base/zlib.mak
> gs/devices/contrib.mak
> gs/devices/devs.mak
> gs/psi/int.mak

2014-10-31 12:39:45 +0000
Chris Liddell <chris.liddell@artifex.com>
0f0b9350206c99e5f4b73fe639ed3e085066fe5e

> Fix and improve bit-rotted jbig2dec/libpng build on Windows
> The Windows jbig2dec build incorporating libpng had bit-rotted, credit to
> Ray for identifying the problems there.
> In addition, I've added provision for specifying the libpng and zlib source
> paths on the nmake command line, and automatic inclusion of libpng if
> the path appears valid.
> No cluster differences.
> gs/jbig2dec/jbig2_image_png.c
> gs/jbig2dec/msvc.mak

2014-10-30 10:59:01 +0000
Chris Liddell <chris.liddell@artifex.com>
69a6dc944e63a4a037eccc0d0cba5dee6bf9f272

> Fix annoying, hard to reproduce ICC related warning
> Occasionally, and in hard to reproduce circumstances, we could get a warning
> from the ICC code:
> ./base/gsicc_manage.c:1084: gsicc_open_search(): \
> Could not find <garbage string>
> This, it turns out, is because the get_params code was returning a pointer to
> a string allocated in non-gc memory, which just isn't compatible with the
> way the Postscript interpreter interacts with the graphics library.
> This commit changes the way the parameter is returned so it copies the string
> into gc memory, compatible with use in a Postscript string object. Note that the
> put_params equivalent code was already correct in copying the string from gc
> memory into non-gc memory managed by the device code.
> No cluster differences
> gs/base/gsdparam.c

2014-10-27 21:19:44 +0100
Simon Bünzli <zeniko@gmail.com>
ee0bc20cc98c8e8381003a25dfa0b21e681c6545

> replace jbig2_arith_get_offset with jbig2_arith_has_reached_marker
> The DOS check introduced with 6e1f2259115efac14cd6c7ad9d119b43013a32a1
> tries to determine whether arithmetic coding has run out of data and
> has entered an infinite loop. It does so by checking how many bytes
> have been read and compares with the number of bytes available. The fix
> however fails to take into account bytes which have been cached in
> _Jbig2ArithState::next_word which causes valid images to be rejected.
> This patch corrects that bug by replacing that check with a generic
> check as to whether the end of the data stream has been reached (which
> is the case if the only two remaining cached bytes are 0xFF and a value
> larger than 0x8F).
> Signed-off-by: Henry Stiles <henry.stiles@artifex.com>
> gs/jbig2dec/jbig2_arith.c
> gs/jbig2dec/jbig2_arith.h
> gs/jbig2dec/jbig2_symbol_dict.c

2014-09-27 13:51:32 +0200
Simon Bünzli <zeniko@gmail.com>
9157d6a5fccf109eb6554557eb8904b281571d28

> Bug 694892: fix typo in 5eaf740b2c02523ae2ae6454e546cb6700d4e3f3
> Signed-off-by: Henry Stiles <henry.stiles@artifex.com>
> gs/jbig2dec/jbig2_metadata.c

2014-10-29 09:29:09 +0000
Chris Liddell <chris.liddell@artifex.com>
f6789d068a5f7af9cfead5120930893955123be1

> Correct a small out-of-dateness related to COMPILE_INITS
> No cluster differences
> gs/doc/Make.htm

2014-10-28 17:09:17 +0000
Ken Sharp <ken.sharp@artifex.com>
cd2c4af1dd92bc4cc32170254c84498792913c0e

> PDF interpreter - ignore /Contents array entries which don't resolve to dicts
> Bug #695645 "PDFWrite fails on file with Error: /typecheck in --run--"
> The specimen file has a /Contents array where one of the elements is an
> indirect reference to another array. This isn't legal, entries in the
> /Contents array must be references to streams. Acrobat simply ignores the
> error and displays the page blank.
> Here we check each entry before we process it, and if its not a dictionary
> we ignore it, exit the loop processing the entries (as Acrobat apparently does)
> and emit a warning.
> No differences expected.
> gs/Resource/Init/pdf_main.ps

2014-10-28 16:28:30 +0000
Ken Sharp <ken.sharp@artifex.com>
e21bb3e597825215da7ad4d757585fa96eb39909

> PDF interpreter - provide a default BBox for Forms
> Bug #695632 "Error: /undefined in --.PDFexecform--"
> Type 1 Form XObjects are required to have a /BBox, but this example file
> incorrectly omits it. Here we add a default (incorrect) BBox just to work
> around the error. We also emit a warning that the file is damaged.
> No diffreences expected.
> gs/Resource/Init/pdf_draw.ps

2014-10-28 15:55:48 +0000
Chris Liddell <chris.liddell@artifex.com>
282c8f902d98543aee12931e69087180829bc8d1

> Remove paragraphs relating to GNU readline
> No cluster differences.
> gs/doc/Make.htm

2014-10-28 10:49:37 +0000
Chris Liddell <chris.liddell@artifex.com>
05c2e0876019551d65f8f79655f34aa5adb5ca27

> Update the docs for fonts and COMPILE_INITS
> No cluster differences.
> gs/doc/Fonts.htm
> gs/doc/Make.htm
> gs/doc/Use.htm

2014-10-27 19:12:15 -0700
Michael Vrhel <michael.vrhel@artifex.com>
d39b321e4927dfafa428af8c25bddb791b14e15b

> Update color management documentation.
> gs/doc/GS9_Color_Management.pdf
> gs/doc/GS9_Color_Management.tex

2014-10-23 09:35:26 +0100
Chris Liddell <chris.liddell@artifex.com>
db7ac4892625633204fad65ffa0da6dbaf43fc6a

> Bug 695598: cidfmap validation problems on Windows
> Originally, the cidfmap validation used "stat" to check whether the font file
> was available (and remove the mapping if the font file is missing). But it
> seems, for some (currently unidentified) reason, stat can fail even if the
> font file is actually avaiable.
> This changes the validation code to use ".libfile" and "file" operators to
> check whether the font file can be found - this, it seems, works, even in cases
> where "state" fails.
> No cluster differences.
> gs/Resource/Init/gs_cidfm.ps

2014-10-22 13:30:08 +0100
Ken Sharp <ken.sharp@artifex.com>
352645ff149aa690074030995ef33e1c2e4c35a0

> Xpswrite - properly initialise PrinterName
> Bug #695617 "Error: Printer name too long"
> The xpswrite device doesn't include a full definition of its devicestructure
> or initialisers for its variables.
> This can lead to problems if any of these variables are exposed via
> put/get params as the initial parameter will be uninitialised (put and get
> params are called before the device open method)
> Here we add a 'finish_copydevice' method and initialise the PrinterName
> in it. Devices are created by calling copydevice on the device prototype
> and the finish_copydevice method is called as the last action from there
> so its safe to initialise the variables, and this will be completed before
> put/get params is called.
> No differences expected
> gs/devices/vector/gdevxps.c

2014-10-22 14:04:14 +0200
Tor Andersson <tor.andersson@artifex.com>
648aba52e1430277035471709e3d6596c7016a35

> Fix 695618: Keep a tail pointer to speed up parsing long XML documents.
> xps/xpsxml.c

2014-10-20 09:55:22 -0600
Henry Stiles <henry.stiles@artifex.com>
c477d95f3e6cf50da2dc125c8d8335a440d9970d

> Restrict xpswrite PrinterName device paramater to windows platform.
> gs/devices/vector/gdevxps.c

2014-10-19 17:54:28 -0600
Henry Stiles <henry.stiles@artifex.com>
54f69da6cdeae9dcffcb1d060ccbeef3e0d4f7b0

> Bug #695578 - Continue parsing a numeric parameter if a bad character
> is found before a legal value.
> This refines an earlier fix, bug #694725 which implemented skipping
> the rest of the numerical parameter when a bad character was parsed.
> Thanks to Norbert Janssen for finding and fixing this problem.
> pcl/pcparse.c

2014-10-19 10:31:42 -0600
Henry Stiles <henry.stiles@artifex.com>
75a6c77aaa4278d462834f08b8da23dabc4566d7

> Change warnings to debug statements.
> gs/devices/vector/gdevxps.c

2014-10-19 10:07:57 -0600
Henry Stiles <henry.stiles@artifex.com>
8eadbf5b901588e86886f7ab42462c2486e9f561

> Fix warnings introduced with "saved page" work.
> pl/plmain.c

2014-10-19 09:52:33 -0600
Henry Stiles <henry.stiles@artifex.com>
d9a5f2f04b57d09f7f8c2082b29edd43fc96dcb0

> Remove repetive accessors for 2 user options (interpolate and nocache)
> and replace with single routine in pl.
> pcl/pctop.c
> pl/plmain.c
> pl/plmain.h
> pxl/pxl.mak
> pxl/pxtop.c

2014-10-11 09:46:19 -0600
Henry Stiles <henry.stiles@artifex.com>
d93848b56be856aaa41a7e16fa42c141219244f5

> Add -dNOCACHE to the usage help statement that runs when the program
> is run incorrectly or incompletely.
> pl/plmain.c

2014-10-11 09:42:52 -0600
Henry Stiles <henry.stiles@artifex.com>
88ed32c13b7bca6c259dc29502a40446bf34f75b

> Implement NOCACHE parameter. We only support the simple case of
> specifying the parameter or not. Right hand side values of /true and
> /false are not supported.
> pcl/pcfont.c
> pcl/pcstate.h
> pcl/pctop.c
> pl/plmain.c
> pl/plmain.h
> pl/pltop.h
> pxl/pxstate.c
> pxl/pxstate.h
> pxl/pxtop.c
> xps/xpstop.c

2014-10-10 11:56:28 -0600
Henry Stiles <henry.stiles@artifex.com>
f072fac051e5f008488e5eea66cc76876516ec47

> Error handling was wrong, objects were dereferenced before checking if
> the allocation failed.
> xps/xpstop.c

2014-10-18 07:55:27 -0700
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
6715211e308d753a79b35663f951a239704b8092

> Fix compile issue with Luratech introduced in 74d5e9fb7d70d3d3d9cf964c76c550134c822020.
> The change from a char * to an enum for psdf_image_params_s->AutoFilterStrategy
> required a change in gdevpsdi.c.
> gs/devices/vector/gdevpsdi.c

2014-10-14 12:39:27 +0100
Ken Sharp <ken.sharp@artifex.com>
5bf2c272781f20dc2ed4ca8a461166543846f422

> ps2write - undo PDF name escaping for Separation colours
> Bug #695590 "Spaces in spot colour names are encoded to "#20""
> The opdfread header wasn't applying the conversion from PDF escaped names
> when the name was an entry in a Separation colour space.
> No differences expected.
> gs/devices/vector/opdfread.h
> gs/lib/opdfread.ps

2014-10-10 11:26:45 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
63b484c3040aa644fff2ed2a0861ac8cb082aafb

> Bug 695146: patch for missing lrintf
> OpenJPEG uses lrintf() which can be missing, or in this case, the prototype is
> missing from the math.h header file - causing faulty output.
> This patch checks for the function prototype, if it's missing it replaces the
> lrintf() call with a naive round/cast implementation.
> Two reasons for choosing this approach: it saves maintaining a patch against
> OpenJPEG, and secondly, this is only relevant to older systems - more up to
> date systems have lrintf() correctly prototyped, and often have implementations
> optimised to the hardware, so we really want to use it if it's available.
> No cluster differences.
> gs/configure.ac

2014-10-07 14:33:08 -0600
Henry Stiles <henry.stiles@artifex.com>
8095a1010b799d5e36ac5bf4a5b67356362df607

> Upon macro creation there is no need to search the dictionary for a
> like named macros and delete it, the dictionary entry is recycled later
> when we add the macro.
> pcl/pcmacros.c

2014-10-07 09:28:38 +0100
Ken Sharp <ken.sharp@artifex.com>
ca7cea181d7905cb460ad6f82f234d3ee8d5efce

> pdfwrite - fix a logical error in the AutoFilterStrategy params
> This code was originally present only when using the Luratech decoder
> but would have been incorrect there too.
> Spotted while looking at a scan-build warning
> gs/devices/vector/gdevpsdp.c

2014-10-05 20:55:39 +0100
Chris Liddell <chris.liddell@artifex.com>
1f3e40cf0fbbbb9a1c8085584f3e411cb112d9b4

> Bug 695555: fix check to simulate overprint.
> Mirror condition from pdf14_mark_fill_rectangle() in
> pdf14_copy_alpha_color() to decide whether we should apply overprinting.
> No cluster differences.
> gs/base/gdevp14.c

2014-10-06 18:00:46 +0100
Ken Sharp <ken.sharp@artifex.com>
4018f1158984093380971ba1f4096b599c2d639e

> PDF interpreter - improve error recovery with PDF form execution
> Bug #695537 "Ghostscript locks up reading attached PDF file"
> The problem is that, after we execute a form, we attempt to 'grestore' back
> to the gsave depth at the time we executed the form, this is to try and
> cater for broken form streams that have unbalanced Q/q operators.
> This is done by counting the dict stack before the form execution, and after
> the form is complete. If the depth is different we execute 'Q' in a loop
> until we get back to the same dict stack depth.
> This assumes that the only reason for having more dictionaries on the stack
> is due to them being pushed by our implementation of 'q'. However in this
> case (and more generally, in any event) we have created some dictionaries
> then encountered an error, and returned control back to the form execution
> routine.
> As stated this calls 'Q' in a loop expecting that each 'Q' will decrement
> the number of dictionaries by 1 each time. But 'Q' only does that if the
> dictionary is the result of a 'q' if it isn't it leaves it in place.
> So the form execution simply carries on round the loop forever.
> This commit addresses this by checking the number of items on the dict
> stack before and after executing 'Q' and if they are the same, it executes
> the 'end' operator instead to remove the topmost dictionary from the stack.
> This allows us to carry on removing gstate or general dictionaries until
> we get back to the correct depth.
> Note that, because there is a genuine error in the file, we do not render
> it 'correctly', but neither does any other PDF consumer. Other consumers
> render more of it than we do, but they all drop the 'Fannie Mae' logo.
> No differences expected
> gs/Resource/Init/pdf_draw.ps

2014-10-06 17:06:27 +0100
Ken Sharp <ken.sharp@artifex.com>
33e70f43badc2581757549bba55747af3f966622

> colour handling - remove continuations from the exec stack on error
> If we get an error (not running another PostScript function), we were not
> removing our continuation procedure and data from the execution stack
> before exiting setcolorspace.
> This led to the interpreter exiting instead of simply flagging an error.
> No bug report for this, discovered while working on bug #695537
> gs/psi/zcolor.c

2014-10-06 16:37:37 +0100
Ken Sharp <ken.sharp@artifex.com>
74d5e9fb7d70d3d3d9cf964c76c550134c822020

> pdfwrite - Correct Gray and ColorImageAutoFilterStrategy
> A number of problems here; firstly the commit that added these to the
> distiller params has the correct names in the commit message, but the names
> used in the code were incorrect (eg ColorAutoFilterStrategy).
> Secondly the parameter is supposed to be a name, but the data stored
> was a C string, and get_params was returning an integer, so it actually
> contained half the memory pointer value.
> The parameters weren't added to .distillerparamkeys so currentdistillerparams
> didn't return the values.
> The default value for the non-Luratech case should have been /JPEG but in
> fact /JPEG2000 was used in both cases.
> 99-01-fixed.ps should dhow up as a diff this time, and then should cease
> being indeterminate with the pdfwrite device, as we now return the correct
> name rather than half a random memory location.
> gs/Resource/Init/gs_pdfwr.ps
> gs/devices/vector/gdevpsdf.h
> gs/devices/vector/gdevpsdp.c

2014-10-05 19:37:24 +0100
Paul Gardiner <paul.gardiner@artifex.com>
e72d03c68bfb6afaa0b90f6b717f91aef67b6c07

> Fix compiler warnings introduced by temp-file commit
> gs/base/gxclfile.c
> gs/base/unistd_.h

2014-10-05 17:14:09 +0100
Ken Sharp <ken.sharp@artifex.com>
5d4d9d9772765501cac81b9b181ecc83f900d08a

> pdfwrite - move outline relocation after the outline action relocation
> Bug #695354 "Segmentation fault splitting PDF"
> Move the pointer relocation for outline levels so that it takes place after
> we relocate the outline actions, otherwise we can end up corrupting
> memory.
> No differences expected
> gs/devices/vector/gdevpdf.c

2014-07-24 12:50:17 +0100
Paul Gardiner <paul.gardiner@artifex.com>
9108db24fef88855199038a257bf935a698af2f4

> Avoid failure to clean up temp files when the execution is killed
> This currently works only for Windows and Linux builds. For Windows, temp
> files are created with the "delete on close" option. For Linux, temp
> files are immediately unlinked on creation. In both cases, the initially
> opened FILE pointer is kept open throughout execution, and reader access
> is provided by duplicating the initial FILE rather than opening a new
> FILE pointer based on the file name.
> gs/base/gp.h
> gs/base/gp_macio.c
> gs/base/gp_mswin.c
> gs/base/gp_os2fs.c
> gs/base/gp_unifs.c
> gs/base/gp_vms.c
> gs/base/gxclfile.c

2014-10-03 13:40:21 +0100
Chris Liddell <chris.liddell@artifex.com>
0a8ac7c25438fbd4c406fc735c9c0fbd9f05c527

> Bug 695244: ensure a consistent allocator for DCT streams.
> The existing code could result in a mis-match between the memory allocators
> used for the DCT specific parts of the stream and the main body of the stream.
> As both are in gc memory, this could result, when the stream goes out of scope,
> in the DCT specific memory being garbage collected before the main stream
> object. As the main stream object contains the "finalize" method, the call to
> finalize would result in accessing already freed memory.
> This commit revises the code to use the same method to work out the allocator
> to use for the main stream object as we do for the DCT specific parts.
> No cluster differences.
> gs/psi/zfdctd.c

2014-10-02 21:54:56 +0100
Chris Liddell <chris.liddell@artifex.com>
8f16e6dc73550d3e8f339a609e2dc51998616330

> Bug 695561: remove .DS_Store files
> No cluster differences.
> gs/lcms2/Projects/mac/.DS_Store
> gs/lcms2/Projects/mac/LittleCMS/.DS_Store

2014-09-30 17:35:02 +0100
Chris Liddell <chris.liddell@artifex.com>
f85afab4a4584c79f309e8f5691f5955605c67b5

> Address two compiler warnings.
> No cluster differences.
> gs/base/gdevprn.c

2014-09-30 08:58:55 +0100
Chris Liddell <chris.liddell@artifex.com>
b460743bdc6c8c4de5fca260224673ca839b11e6

> Remove LCMS.
> No cluster differences.
> gs/Makefile.in
> gs/base/lcms.mak
> gs/configure.ac
> gs/lcms/AUTHORS
> gs/lcms/COPYING
> gs/lcms/ChangeLog
> gs/lcms/Delphi/Samples/MAKETEST.BAT
> gs/lcms/Delphi/Samples/TEST.PAS
> gs/lcms/Delphi/Samples/create.pas
> gs/lcms/Delphi/Samples/gamutchk.pas
> gs/lcms/Delphi/Samples/getxyz.pas
> gs/lcms/Delphi/Samples/sRGB Color Space Profile.icm
> gs/lcms/Delphi/Samples/testfrm.pas
> gs/lcms/Delphi/Samples/testwp.pas
> gs/lcms/Delphi/delphidemo.cfg
> gs/lcms/Delphi/delphidemo.dof
> gs/lcms/Delphi/delphidemo.dpr
> gs/lcms/Delphi/delphidemo.res
> gs/lcms/Delphi/demo1.dcu
> gs/lcms/Delphi/demo1.ddp
> gs/lcms/Delphi/demo1.dfm
> gs/lcms/Delphi/demo1.pas
> gs/lcms/Delphi/lcmsdll.pas
> gs/lcms/INSTALL
> gs/lcms/Lib/BC/BC.txt
> gs/lcms/Lib/MS/MS.TXT
> gs/lcms/Makefile.am
> gs/lcms/Makefile.in
> gs/lcms/NEWS
> gs/lcms/Projects/BorlandC_5.5/lcms.rc
> gs/lcms/Projects/BorlandC_5.5/lcmsdll.lk
> gs/lcms/Projects/BorlandC_5.5/lcmsdll.lst
> gs/lcms/Projects/BorlandC_5.5/mklcmsdll.bat
> gs/lcms/Projects/VC2005/Python.vcproj
> gs/lcms/Projects/VC2005/Testbed.vcproj
> gs/lcms/Projects/VC2005/icc2ps.vcproj
> gs/lcms/Projects/VC2005/icclink.vcproj
> gs/lcms/Projects/VC2005/icctrans.vcproj
> gs/lcms/Projects/VC2005/jpegicc.vcproj
> gs/lcms/Projects/VC2005/lcms.rc
> gs/lcms/Projects/VC2005/lcms.sln
> gs/lcms/Projects/VC2005/lcms.vcproj
> gs/lcms/Projects/VC2005/lcmsdll.vcproj
> gs/lcms/Projects/VC2005/resource.h
> gs/lcms/Projects/VC2005/tiffdiff.vcproj
> gs/lcms/Projects/VC2005/tifficc.vcproj
> gs/lcms/Projects/VC2008/Python.vcproj
> gs/lcms/Projects/VC2008/Testbed.vcproj
> gs/lcms/Projects/VC2008/icc2ps.vcproj
> gs/lcms/Projects/VC2008/icclink.vcproj
> gs/lcms/Projects/VC2008/icctrans.vcproj
> gs/lcms/Projects/VC2008/jpegicc.vcproj
> gs/lcms/Projects/VC2008/lcms.rc
> gs/lcms/Projects/VC2008/lcms.sln
> gs/lcms/Projects/VC2008/lcms.vcproj
> gs/lcms/Projects/VC2008/lcmsdll.vcproj
> gs/lcms/Projects/VC2008/resource.h
> gs/lcms/Projects/VC2008/tiffdiff.vcproj
> gs/lcms/Projects/VC2008/tifficc.vcproj
> gs/lcms/Projects/VC6/Python.dsp
> gs/lcms/Projects/VC6/Python.plg
> gs/lcms/Projects/VC6/Testbed.dsp
> gs/lcms/Projects/VC6/Testbed.plg
> gs/lcms/Projects/VC6/icc2ps.dsp
> gs/lcms/Projects/VC6/icclink.dsp
> gs/lcms/Projects/VC6/icctrans.dsp
> gs/lcms/Projects/VC6/jpegicc.dsp
> gs/lcms/Projects/VC6/lcms.dsp
> gs/lcms/Projects/VC6/lcms.dsw
> gs/lcms/Projects/VC6/lcms.opt
> gs/lcms/Projects/VC6/lcms.rc
> gs/lcms/Projects/VC6/lcmsdll.dsp
> gs/lcms/Projects/VC6/resource.h
> gs/lcms/Projects/VC6/tifficc.dsp
> gs/lcms/Projects/VC7/Python.vcproj
> gs/lcms/Projects/VC7/Testbed.vcproj
> gs/lcms/Projects/VC7/icc2ps.vcproj
> gs/lcms/Projects/VC7/icclink.vcproj
> gs/lcms/Projects/VC7/icctrans.vcproj
> gs/lcms/Projects/VC7/jpegicc.vcproj
> gs/lcms/Projects/VC7/lcms.rc
> gs/lcms/Projects/VC7/lcms.sln
> gs/lcms/Projects/VC7/lcms.vcproj
> gs/lcms/Projects/VC7/lcmsdll.vcproj
> gs/lcms/Projects/VC7/resource.h
> gs/lcms/Projects/VC7/tiffdiff.vcproj
> gs/lcms/Projects/VC7/tifficc.vcproj
> gs/lcms/README.1ST
> gs/lcms/aclocal.m4
> gs/lcms/bin/Bin.txt
> gs/lcms/compile
> gs/lcms/config.guess
> gs/lcms/config.sub
> gs/lcms/configure
> gs/lcms/configure.ac
> gs/lcms/depcomp
> gs/lcms/doc/LCMSAPI.TXT
> gs/lcms/doc/TUTORIAL.TXT
> gs/lcms/filter.c
> gs/lcms/include/Makefile.am
> gs/lcms/include/Makefile.in
> gs/lcms/include/icc34.h.in
> gs/lcms/include/lcms.h
> gs/lcms/install-sh
> gs/lcms/install.gcc
> gs/lcms/jpegicc/Makefile.am
> gs/lcms/jpegicc/Makefile.in
> gs/lcms/jpegicc/iccjpeg.c
> gs/lcms/jpegicc/iccjpeg.h
> gs/lcms/jpegicc/jpegicc.1
> gs/lcms/jpegicc/jpegicc.c
> gs/lcms/jpegicc/makefile.simple
> gs/lcms/lcms.pc.in
> gs/lcms/ltmain.sh
> gs/lcms/makefile.simple
> gs/lcms/matlab/icctrans.c
> gs/lcms/matlab/icctrans.matlab.pdf
> gs/lcms/missing
> gs/lcms/mkinstalldirs
> gs/lcms/python/Makefile.am
> gs/lcms/python/Makefile.in
> gs/lcms/python/lcms.i
> gs/lcms/python/lcms.py
> gs/lcms/python/lcms_wrap.cxx
> gs/lcms/python/swig_lcms
> gs/lcms/python/testbed/AdobeRGB1998.icc
> gs/lcms/python/testbed/cam02.py
> gs/lcms/python/testbed/cam97.py
> gs/lcms/python/testbed/clamp.py
> gs/lcms/python/testbed/constant.py
> gs/lcms/python/testbed/createmsh.py
> gs/lcms/python/testbed/gamma.py
> gs/lcms/python/testbed/info.py
> gs/lcms/python/testbed/lab2adobe.py
> gs/lcms/python/testbed/sRGB Color Space Profile.icm
> gs/lcms/python/testbed/sRGB2adobe.py
> gs/lcms/python/testbed/srgb2lab.py
> gs/lcms/python/testbed/srgb2xyz.py
> gs/lcms/python/testbed/virtprf.py
> gs/lcms/python/testbed/whtpnt.py
> gs/lcms/samples/Makefile.am
> gs/lcms/samples/Makefile.in
> gs/lcms/samples/icc2ps.1
> gs/lcms/samples/icc2ps.c
> gs/lcms/samples/icclink.1
> gs/lcms/samples/icclink.c
> gs/lcms/samples/icctrans.1
> gs/lcms/samples/icctrans.c
> gs/lcms/samples/itufax.c
> gs/lcms/samples/makefile.simple
> gs/lcms/samples/mkcmy.c
> gs/lcms/samples/mkgrayer.c
> gs/lcms/samples/mktiff8.c
> gs/lcms/samples/vprf.c
> gs/lcms/samples/wtpt.1
> gs/lcms/samples/wtpt.c
> gs/lcms/samples/xgetopt.c
> gs/lcms/src/Makefile.am
> gs/lcms/src/Makefile.in
> gs/lcms/src/cmscam02.c
> gs/lcms/src/cmscam97.c
> gs/lcms/src/cmscgats.c
> gs/lcms/src/cmscnvrt.c
> gs/lcms/src/cmserr.c
> gs/lcms/src/cmsgamma.c
> gs/lcms/src/cmsgmt.c
> gs/lcms/src/cmsintrp.c
> gs/lcms/src/cmsio0.c
> gs/lcms/src/cmsio1.c
> gs/lcms/src/cmslut.c
> gs/lcms/src/cmsmatsh.c
> gs/lcms/src/cmsmtrx.c
> gs/lcms/src/cmsnamed.c
> gs/lcms/src/cmspack.c
> gs/lcms/src/cmspcs.c
> gs/lcms/src/cmsps2.c
> gs/lcms/src/cmssamp.c
> gs/lcms/src/cmsvirt.c
> gs/lcms/src/cmswtpnt.c
> gs/lcms/src/cmsxform.c
> gs/lcms/src/cmsxform.c.orig
> gs/lcms/src/cmsxform.h
> gs/lcms/src/lcms.def
> gs/lcms/src/makefile.simple
> gs/lcms/testbed/Makefile.am
> gs/lcms/testbed/Makefile.in
> gs/lcms/testbed/makefile.simple
> gs/lcms/testbed/sRGB Color Space Profile.icm
> gs/lcms/testbed/sRGBSpac.icm
> gs/lcms/testbed/testcms.c
> gs/lcms/tifficc/Makefile.am
> gs/lcms/tifficc/Makefile.in
> gs/lcms/tifficc/getopt.c
> gs/lcms/tifficc/makefile.simple
> gs/lcms/tifficc/tiffdiff.c
> gs/lcms/tifficc/tifficc.1
> gs/lcms/tifficc/tifficc.c
> gs/psi/msvc.mak

2014-09-25 11:21:14 +0100
Chris Liddell <chris.liddell@artifex.com>
6ecc8536f5119f21aa38b94eb00e61214d27bd62

> Bug 695502: segfault with -dBGPrint=true
> When we're doing background printing, and we're using a memory file based
> clist, we create a "clone" of the file object with it's own "context" but
> which shares the underlying "raw" data with the original file. The original
> code tries to free the underlying raw data memory along with the clone
> file object, but as the clone uses the memory allocator created for the
> rendering thread and the raw data memory was allocated in the interpretation
> "thread", we end up trying to free memory to the wrong allocator.
> This commit has the interpreter thread hold a reference to the original clist
> files, so we can free the "clone" files with the thread allocator, and the
> original file with the allocator from the interpreter thread. As both these
> cleanup actions happen in the interpreter thread, we don't have to worry about
> thread clashes.
> No cluster differences.
> gs/base/gdevprn.c
> gs/base/gdevprn.h
> gs/base/gxclthrd.c

2014-09-17 21:17:14 +0100
Chris Liddell <chris.liddell@artifex.com>
7ac0f1668fca8e1ca343e02f55faa7dd9f23d549

> Bug 695483: BGPrint seg fault
> When reading params for the existing device, to pass to the cloned device,
> use the thread_memory rather than the original device memory.
> And move the io_device_table into immovable memory, rather than regular gc
> memory.
> No cluster differences.
> gs/base/gsiodev.c
> gs/base/gxclthrd.c

2014-09-29 08:57:14 +0100
Chris Liddell <chris.liddell@artifex.com>
68aa4cb52359c0c6e25bcf53735bb05030ee4a2b

> Fix typo in LICENSE file
> CLUSTER_UNTESTED
> gs/LICENSE

2014-09-27 15:21:01 +0100
Ken Sharp <ken.sharp@artifex.com>
d5ecb99d3641a95803c88e6df2f734d392a3be63

> Make DCT filter finalize routine robust against double calling.
> Bug #695542 "Crash on EPS on Mac and Linux"
> The problem is that we close a DCT filter inside a gsave context, while
> the file ref is still pointing at it.
> When the PostScript 'close' operator closes the DCT filter, we free the
> memory associated with the stream state in the finalize routine. But the
> PostScript file ref is still pointing at it, and when we grestore, the
> finalize routine gets called again. Because the routine doesn't check for
> NULL pointers before freeing, and indeed doesn't NULL the pointers after it
> does free them, this leads to us freeing memory which has already been
> freed.
> Apparently we've already fixed a number of similar problems in finalize
> routines, probably caused by people not realising a finalize routine could
> (surprisingly) be called more than once.
> In this commit we set the pointers to null after feeing the memory, and
> check for null pointers before attempting to free the memory, and before
> attempting to dereference any pointers.
> No differences expected.
> gs/base/sdctc.c
> gs/base/stream.c

2014-09-27 09:05:54 +0100
Chris Liddell <chris.liddell@artifex.com>
9ef2c8188a86c5e19c93a38bb01b9297200bd896

> Bug 695543 - gs %stdin segfaults
> In zopen_file() when we're opening a Postscript device, ensure that we set the
> "state" entry in the iodev structure before calling the device specific "open"
> method - as we do elsewhere in the same circumstances. That is required to
> properly access devices like "%stdin" and co.
> No cluster differences.
> gs/psi/zfile.c

2014-09-26 09:56:40 +0100
Chris Liddell <chris.liddell@artifex.com>
97ee68c17fd8709b4509b394b721524b7777c3bb

> Bug 695539: glyph mapping - handle "missing" codepoints
> When extending the glyph mapping in a font, the original code for adding the
> codepoint to the font could assume the codepoint was valid as it was always
> read from the Adobe Glyph List. But I added code to "parse" a codepoint from
> the special "uniXXXX" type names, and that breaks that assumption.
> Handle the case where we reach that point with codepoint that doesn't exist in
> the AGL.
> No cluster differences.
> gs/Resource/Init/gs_ttf.ps
> gs/Resource/Init/gs_type1.ps

2014-09-25 23:42:50 -0600
Henry Stiles <henry.stiles@artifex.com>
0c677ef110bb53460062da7586e37a37ea6eae52

> Fix Bug #695535 Page not cleared upon resolution setting.
> Somewhat puzzling this hasn't come up before but PCL was changing the
> resolution of a PCL job upon receiving a PJL command without erasing
> the page. If the resolution is set on the command line or the device
> default is used the normal page erasing happens with the job's
> resolution already set.
> pcl/pcjob.c
> pcl/pcl.mak

2014-09-25 09:47:14 -0700
Ray Johnston <ray.johnston@artifex.com>
53d8252202f860398be69a59d6a6da80aca551ce

> Fix typo when closing bfile and cfile. Thanks to Norbert Janssen.
> gs/base/gxclthrd.c

2014-09-23 07:47:00 -0700
Ray Johnston <ray.johnston@artifex.com>
75a183ff51daebf8c3835f3d6e5107d70061a8ce

> Change the -Z: output to report parse done as well as page render done.
> This corresponds more closely the the information available with -Z: from
> gs which provides Outputpage start and Outputpage end times. This is useful
> for the 'overview' timing analysis, such as with bug 695374.
> pcl/pctop.c
> pl/plmain.c

2014-09-23 09:18:46 +0100
Ken Sharp <ken.sharp@artifex.com>
98b066aad13281ce75471163959db727a5a9da58

> pdfwrite - fix a warning and an assignment to conditional
> Removing the assignment of a return value to code in order to eliminate a
> compiler warning.
> The test of code against gs_error_interrupt was accidentally written as an
> assignment, fixing this causes progressions in:
> Bug690534.pdf
> 586_-_missing_images_gs_SMask_not_applied.pdf
> multiply_luminosity_masks_ignored.pdf
> These are progressions over 9.15 as well.
> gs/devices/vector/gdevpdft.c

2014-09-08 14:47:15 +0100
Chris Liddell <chris.liddell@artifex.com>
2454c0d599f3abdff7d7b002d54dd58549e948de

> Update docs, versions and dates for release candidate.
> Update docs, dates etc for second release candidate.
> Update stuff for release
> gs/base/version.mak
> gs/doc/API.htm
> gs/doc/C-style.htm
> gs/doc/Commprod.htm
> gs/doc/DLL.htm
> gs/doc/Deprecated.htm
> gs/doc/Details8.htm
> gs/doc/Details9.htm
> gs/doc/Develop.htm
> gs/doc/Devices.htm
> gs/doc/Drivers.htm
> gs/doc/Fonts.htm
> gs/doc/Helpers.htm
> gs/doc/History1.htm
> gs/doc/History2.htm
> gs/doc/History3.htm
> gs/doc/History4.htm
> gs/doc/History5.htm
> gs/doc/History6.htm
> gs/doc/History7.htm
> gs/doc/History8.htm
> gs/doc/History9.htm
> gs/doc/Install.htm
> gs/doc/Issues.htm
> gs/doc/Language.htm
> gs/doc/Lib.htm
> gs/doc/Make.htm
> gs/doc/News.htm
> gs/doc/Projects.htm
> gs/doc/Ps-style.htm
> gs/doc/Ps2epsi.htm
> gs/doc/Ps2pdf.htm
> gs/doc/Ps2ps2.htm
> gs/doc/Psfiles.htm
> gs/doc/Readme.htm
> gs/doc/Release.htm
> gs/doc/SavedPages.htm
> gs/doc/Source.htm
> gs/doc/Unix-lpr.htm
> gs/doc/Use.htm
> gs/doc/WhatIsGS.htm
> gs/doc/Xfonts.htm
> gs/doc/gs-vms.hlp
> gs/doc/thirdparty.htm
> gs/man/dvipdf.1
> gs/man/font2c.1
> gs/man/gs.1
> gs/man/gslp.1
> gs/man/gsnd.1
> gs/man/pdf2dsc.1
> gs/man/pdf2ps.1
> gs/man/pf2afm.1
> gs/man/pfbtopfa.1
> gs/man/printafm.1
> gs/man/ps2ascii.1
> gs/man/ps2epsi.1
> gs/man/ps2pdf.1
> gs/man/ps2pdfwr.1
> gs/man/ps2ps.1
> gs/man/wftopfa.1

2014-09-22 16:08:37 +0100
Ken Sharp <ken.sharp@artifex.com>
fd5858999c4117ef16f8127497bcc329e4006833

> accidentally left a line out of ee3d09
> Due to finger trouble, missed this line off the last commit
> gs/devices/vector/gdevpdft.c

2014-09-22 16:06:01 +0100
Ken Sharp <ken.sharp@artifex.com>
ee3d09d4efed339d15d6168f3ef72516d3391576

> pdfwrite - handle transparency mask of type TRANSPARENCY_MASK_None
> Bug #695482 "Regression: empty PDF files written starting with ea6290b302598f13e7fb4c29aff73657989e693d"
> commit ea6290b302598f13e7fb4c29aff73657989e693d introduced this type of
> transparency mask, which is *not* concluded with an end transparency group.
> Because pdfwrite didn't expect this, it led to 0 length output PDF files.
> This commit restores the functionality, it does not (apparently) produce
> correct output from the test file using pdfwrite though.
> The differences here are all progressions.
> gs/devices/vector/gdevpdft.c

2014-09-22 14:34:55 +0100
Ken Sharp <ken.sharp@artifex.com>
a1a6d76aae77b28bfd805f06df4a1a9537fbc139

> remove some C++ comments (and some other commented code)
> gs/devices/vector/gdevpdte.c

2014-09-22 13:28:50 +0100
Ken Sharp <ken.sharp@artifex.com>
37837c01c7ca8461e9f458c061e27990dd94ad41

> remove an unused variable to silence a compiler warning
> gs/devices/gxfcopy.c

2014-09-22 10:42:29 +0100
Ken Sharp <ken.sharp@artifex.com>
202b0d827c4840410d01a6acb83c56277829f507

> pdfwrite - close dangling substreams at end of page
> Inspired by bug #695482 but not intended as a fix, and also by bug #695354
> If we fail to close a substream (possibly because the PDF interpreter throws
> an error) then this leaves a text_state associated with the substream
> dangling, and potentially referencing other freed memory which can lead
> to a crash in the garbage collector. In addition we can end up writing an
> empty PDF file.
> This commit closes any substreams which are still open when a page is written
> which ensures the memory is cleaned up, and that a valid (if broken) PDF
> file gets written.
> Note that ps2write is (of course) different, and *expects* to have a substream
> open at the end of the page, so in this case we have to close the page and then
> clean up any dangling substreams afterwards.
> Although this appears to 'fix' bug #695482 its not a proper fix.
> No differences expected.
> gs/devices/vector/gdevpdf.c

2014-09-22 08:51:23 +0100
Ken Sharp <ken.sharp@artifex.com>
9e5c21512649090ae563b584caec32fb6fdc2bb9

> pdfwrite - free associated text state when closing a substream
> When we open a substream, we create a text state, but we did not prevoously
> free the text state when closing the substream, which could lead to memory
> leaks or if using the '%d' syntax for per-page PDF output, could lead to
> crashes in the garbage collector.
> No differences expected
> gs/devices/vector/gdevpdti.c

2014-09-22 08:49:39 +0100
Ken Sharp <ken.sharp@artifex.com>
1cd582c342d1d754d85f5d89f39cbe672b9d9c67

> pdfwrite - free FDArray from copied CIDFOnts when copy is freed
> further to commit 26a22e which freed copied descendant fonts from a copy of
> a CIDFont when it was freed, here we free the FDArray itself from teh copy.
> No differences expected
> gs/devices/gxfcopy.c

2014-09-19 13:38:25 +0100
Ken Sharp <ken.sharp@artifex.com>
26a22e6fd3dd42fdcaae568276f82b40d746bce9

> Free copied descendant font(s) when freeing a copied CIDFont
> When we copy a CIDFont (other than a TrueType CIDFont) we also copy the
> descendant fonts. But when we free them (gs_free_copied_font) we only free
> the CIDFont, leaving the descendants dangling. This can cause problems
> (seg fault) when we garbage collect the descendants.
> Here we free the descendants as well. This is complicated by the fact that
> the parent CIDFont 'glyphs' space is shared by all the descendants, so
> we *don't* want to free that when we free the descendant.
> No differences expected
> gs/devices/gxfcopy.c

2014-09-17 14:02:17 +0100
Chris Liddell <chris.liddell@artifex.com>
bb35d2d7bc93b1fff5e182be370d64b24129a09e

> Bug 695490: GL stick font seg fault
> Initialise width cache values for stick font and 531 font.
> No cluster differences.
> pcl/pglabel.c

2014-09-17 13:46:17 +0100
Chris Liddell <chris.liddell@artifex.com>
d4c1bd25347e42d0668a73a57bd9aa8ca904be1a

> Bug 695491: parallel make fail due to pconfig.h
> Create a target for pconfig.h and have it as a dependency where required,
> rather than have each individual target that needs it copy pconf.h to
> pconfig.h which could cause a "collision" during a parallel build.
> No cluster differences.
> pcl/pcl.mak
> pl/pl.mak
> psi/psi.mak
> pxl/pxl.mak
> xps/xps.mak

2014-09-17 12:23:05 +0100
Chris Liddell <chris.liddell@artifex.com>
ec56638c8cc6176c2ee935a7ba43cd0af2a02fd1

> Bug 695492: fix seg fault regression with '-h'
> When called with the '-h' parameter, we don't fully initialise the PS
> interpreter. In which case, we shouldn't try to use the PS interpreter
> when we shut down.
> No cluster differences.
> gs/psi/imain.c

2014-09-15 19:33:32 -0700
Ray Johnston <ray.johnston@artifex.com>
b66f287128616340b68243bf5384acac066db561

> Fix colors for -sDEVICE=bitrgb -dGrayValues=16
> This device was using the default, but that code was encoding the
> color as 5x5x5 RGB since the bit device selects a color_info.depth
> of 16. Import the logic and fix it for the 4-bit RGB case (12-bit
> values in 16-bit pixels).
> gs/devices/gdevbit.c

2014-09-15 17:51:56 -0700
Ray Johnston <ray.johnston@artifex.com>
10d517b4954e5adaaf7cc8d823db68e8e1b157f3

> Fix the -dRGB option to work with BITS = 1, 2, 4 or 8
> Note that the -sDEVICE=bitrgb -dGrayValues=16 was broken due to
> improper encoding. This will be fixed in a separate commit.
> gs/lib/viewraw.ps

2014-09-15 08:59:08 -0700
Ray Johnston <ray.johnston@artifex.com>
eb486a42382152c5d7448eabfa7e7a40f8226c81

> Improvements for viewraw.ps with RGB input for 1 and 2 bpc.
> Note BITS=4 is still not supported.
> gs/lib/viewraw.ps

2014-09-16 14:01:36 +0100
Ken Sharp <ken.sharp@artifex.com>
2e619c7a51e45c05c3d02792c3353b3c731f3884

> pdfwrite - mark freshly opened device as 'open'
> When using the '%d' format for output files, the pdf_output_page() routine
> closes and reopens the pdfwrite device (to flush the device, creating
> a PDF file). However, it doesn't mark the 'is_open' member of the device,
> and pdfwrite doesn't do that itself, relying on the caller (normally
> gs_opendevice()) to set the flag.
> Later we get a setpagedevice, this executes .setdevice which calls
> gs_setdevice_no_erase() which checks dev->is_open and if it is not open
> then it opens it. This causes pdf_open to allocate all kinds of new
> memory areas, without freeing the old ones, as well as temporary files and
> possibly other structures/memory allocations.
> Surprisingly this doesn't actually seem to cause a problem, but its not
> right, and surely will cause problems one day, its definitely causing
> memory leaks in non-GC interpreters.
> So this tiny commit just sets the flag is_open when we open the device in
> pdf_output_page.
> No differences expected
> gs/devices/vector/gdevpdf.c

2014-09-15 11:02:09 +0100
Chris Liddell <chris.liddell@artifex.com>
d0816120fdae4e9592269d98e933cbdf99faad5e

> Bug 695483: disable BGPrint before we shutdown interpreter
> Before we start the process of shutting down the PS interpreter, disable BGPrint
> (and set NumRenderingThreads to 0, just for safety). If we don't do this, the
> "parent" rendering thread will continue preparations for the next page whilst
> we shutdown the interpreter, and will thus attempt to access some objects
> subject to garbage collection (such as the I/O device table).
> Additionally, when a device switches from BGPrint enabled to disabled, make sure
> we tear down the rendering thread(s) and get rid off the BGPrint related data.
> No cluster differences.
> gs/base/gdevprn.c
> gs/psi/imain.c

2014-09-15 10:21:18 +0100
Chris Liddell <chris.liddell@artifex.com>
0d22694c3798bf13120be35322b7984fd2296e0f

> Bug 695486: initialise c_alone in current chunk (cc)
> When we (re-)initialise an allocator, we have to initialise the contents of the
> current chunk (cc) entry - initialise to "false" since that's the common case.
> No cluster differences.
> gs/base/gsalloc.c

2014-09-15 15:19:46 +0100
Ken Sharp <ken.sharp@artifex.com>
a7b8c4f39f0f8f1f0872c2ae8faff1ddd35cbdb2

> pdfwrite - free pdfwrite's 'complete' font copy if required
> Bug #695484 "Regression: seg fault with debug build in pdfwrite starting with ceb5e2f006bf554a56701ee2f2c228841b324a4b"
> The problem was caused because pdfwrite can maintain two copies of a font,
> a subset and a complete copy, depending on settings. We were properly freeing
> the subset, but not the complete copy.
> This has been a long-standing undetected memory leak, but only on systems
> without garbage collection, because the copied font is subject to GC, and
> indeed this was causing the actual fault. When we restored at the end of the
> file, the copied font was garbage collected, which caused it to try nd free
> any glyphs from its font cache. But the font cache is now (since the commit
> in the bug title) pointing at the pdfwrite font cache, and that has already
> been freed before we get to the end of job restore, resutling in a seg fault.
> Here we free the complete font copy if one has been allocated.
> No differences expected.
> gs/devices/vector/gdevpdtd.c

2014-09-14 23:00:08 -0600
Henry Stiles <henry.stiles@artifex.com>
0614577faa0b89574b0d9c6c9cabe77398183a40

> Fix Bug 695481 - Barcode font scaled incorrectly.
> The downloaded font in this file (the barcode) used the typeface
> family designation of 0 which is reserved for the lineprinter font.
> Our interpreter scales lineprinter specially and identifies
> lineprinter with its typeface number (0), thus the barcode font was
> scaled as if it were the lineprinter font. Now we check the typeface
> number is 0 and the font is internal which will uniquely identify the
> lineprinter font and not confuse other fonts with it.
> Technically the font is broken and shouldn't be accepted, the typeface
> family numbers documented by HP should not be reused by downloaded
> fonts, but HP printers seem to print the job.
> pcl/pctext.c

2014-09-12 14:49:08 +0100
Chris Liddell <chris.liddell@artifex.com>
94786ac00b285be997aaddbc689180478a47e270

> Get rid of last vestiges of pswrite....
> Remove epswrite (the final "subdevice" of pswrite) and references to it.
> Also remove the gdevps.c source file.
> Cluster differences only in files that enumerate the devices list, for
> example:
> 430-01.ps
> doc/who_owns_what.txt
> gs/Makefile.in
> gs/base/macos-mcp.mak
> gs/base/macosx.mak
> gs/base/openvms.mak
> gs/base/openvms.mmk
> gs/base/unix-gcc.mak
> gs/base/unixansi.mak
> gs/configure.ac
> gs/devices/devs.mak
> gs/devices/vector/gdevps.c
> gs/lib/eps2eps
> gs/lib/eps2eps.bat
> gs/lib/eps2eps.cmd
> gs/man/ps2ps.1
> gs/psi/msvc.mak
> gs/psi/os2.mak
> gs/toolbin/pre.chk

2014-09-10 11:57:10 -0700
Ray Johnston <ray.johnston@artifex.com>
ea6290b302598f13e7fb4c29aff73657989e693d

> Fix Bug 695471, cust 532. /SMask /None did not remove prior SMask
> The 'gssmask' proc in pdf_draw.ps doesn't remove a previous SMask
> when the ExtGState is set to /SMask /None. Change the logic to
> issue a "dummy" .begintransparencymaskgroup (that does NOT have a
> corresponding .endtransparencymask) and add handling for this type
> of SMask in the code. This does not result in a colorspace change,
> but only frees the tos maskbuf. Seen with MSN_Chrome.pdf
> gs/Resource/Init/pdf_draw.ps
> gs/base/gdevp14.c
> gs/base/gstparam.h
> gs/base/gstrans.c

2014-08-27 10:08:45 -0700
Ray Johnston <ray.johnston@artifex.com>
3b2d19e8a459610ba50560ee004eae8736644dc1

> Add lib/viewraw.ps utility to view "raw" files
> An extended version of lib/viewcmyk.ps so that "raw" output from
> bit, bitrgb or bitcmyk can be displayed or converted. For example:
> gswin32c -sDEVICE=bitrgb -dGrayValues=256 -o x.rgb examples/tiger.eps
> can be viewed with:
> gswin32c -dRGB -dBITS=8 -- lib/viewraw.ps x.rgb 612
> gs/lib/viewraw.ps

2014-09-08 13:52:07 +0100
Chris Liddell <chris.liddell@artifex.com>
fcb0c5ee27b9d5a769545f547ee7afdcf8e9829f

> Bump version.
> Usual cluster differences.....
> gs/Resource/Init/gs_init.ps
> gs/base/version.mak

2014-09-22 11:12:44 +0100
Chris Liddell <chris.liddell@artifex.com>
8b2e4263a230d0e7cb262532e0f347976f4b289a

> Update stuff for release
> gs/base/gscdef.c
> gs/base/version.mak
> gs/doc/API.htm
> gs/doc/C-style.htm
> gs/doc/Commprod.htm
> gs/doc/DLL.htm
> gs/doc/Deprecated.htm
> gs/doc/Details8.htm
> gs/doc/Details9.htm
> gs/doc/Develop.htm
> gs/doc/Devices.htm
> gs/doc/Drivers.htm
> gs/doc/Fonts.htm
> gs/doc/Helpers.htm
> gs/doc/History1.htm
> gs/doc/History2.htm
> gs/doc/History3.htm
> gs/doc/History4.htm
> gs/doc/History5.htm
> gs/doc/History6.htm
> gs/doc/History7.htm
> gs/doc/History8.htm
> gs/doc/History9.htm
> gs/doc/Install.htm
> gs/doc/Issues.htm
> gs/doc/Language.htm
> gs/doc/Lib.htm
> gs/doc/Make.htm
> gs/doc/News.htm
> gs/doc/Projects.htm
> gs/doc/Ps-style.htm
> gs/doc/Ps2epsi.htm
> gs/doc/Ps2pdf.htm
> gs/doc/Ps2ps2.htm
> gs/doc/Psfiles.htm
> gs/doc/Readme.htm
> gs/doc/Release.htm
> gs/doc/SavedPages.htm
> gs/doc/Source.htm
> gs/doc/Unix-lpr.htm
> gs/doc/Use.htm
> gs/doc/WhatIsGS.htm
> gs/doc/Xfonts.htm
> gs/doc/gs-vms.hlp
> gs/doc/thirdparty.htm
> gs/man/dvipdf.1
> gs/man/font2c.1
> gs/man/gs.1
> gs/man/gslp.1
> gs/man/gsnd.1
> gs/man/pdf2dsc.1
> gs/man/pdf2ps.1
> gs/man/pf2afm.1
> gs/man/pfbtopfa.1
> gs/man/printafm.1
> gs/man/ps2ascii.1
> gs/man/ps2epsi.1
> gs/man/ps2pdf.1
> gs/man/ps2pdfwr.1
> gs/man/ps2ps.1
> gs/man/wftopfa.1

2014-09-17 12:23:05 +0100
Chris Liddell <chris.liddell@artifex.com>
404e71e01ad665deb7435fe37aad6034380297e3

> Bug 695492: fix seg fault regression with '-h'
> When called with the '-h' parameter, we don't fully initialise the PS
> interpreter. In which case, we shouldn't try to use the PS interpreter
> when we shut down.
> No cluster differences.
> gs/psi/imain.c

2014-09-16 11:48:12 +0100
Chris Liddell <chris.liddell@artifex.com>
96a55a20f5b0d852d2118a1ac318293c6a0f716e

> Update docs, dates etc for second release candidate.
> gs/base/gscdef.c
> gs/doc/API.htm
> gs/doc/C-style.htm
> gs/doc/Commprod.htm
> gs/doc/DLL.htm
> gs/doc/Deprecated.htm
> gs/doc/Details8.htm
> gs/doc/Details9.htm
> gs/doc/Develop.htm
> gs/doc/Devices.htm
> gs/doc/Drivers.htm
> gs/doc/Fonts.htm
> gs/doc/Helpers.htm
> gs/doc/History1.htm
> gs/doc/History2.htm
> gs/doc/History3.htm
> gs/doc/History4.htm
> gs/doc/History5.htm
> gs/doc/History6.htm
> gs/doc/History7.htm
> gs/doc/History8.htm
> gs/doc/History9.htm
> gs/doc/Install.htm
> gs/doc/Issues.htm
> gs/doc/Language.htm
> gs/doc/Lib.htm
> gs/doc/Make.htm
> gs/doc/News.htm
> gs/doc/Projects.htm
> gs/doc/Ps-style.htm
> gs/doc/Ps2epsi.htm
> gs/doc/Ps2pdf.htm
> gs/doc/Ps2ps2.htm
> gs/doc/Psfiles.htm
> gs/doc/Readme.htm
> gs/doc/Release.htm
> gs/doc/SavedPages.htm
> gs/doc/Source.htm
> gs/doc/Unix-lpr.htm
> gs/doc/Use.htm
> gs/doc/WhatIsGS.htm
> gs/doc/Xfonts.htm
> gs/doc/gs-vms.hlp
> gs/doc/thirdparty.htm
> gs/man/dvipdf.1
> gs/man/font2c.1
> gs/man/gs.1
> gs/man/gslp.1
> gs/man/gsnd.1
> gs/man/pdf2dsc.1
> gs/man/pdf2ps.1
> gs/man/pf2afm.1
> gs/man/pfbtopfa.1
> gs/man/printafm.1
> gs/man/ps2ascii.1
> gs/man/ps2epsi.1
> gs/man/ps2pdf.1
> gs/man/ps2pdfwr.1
> gs/man/ps2ps.1
> gs/man/wftopfa.1

2014-09-15 11:02:09 +0100
Chris Liddell <chris.liddell@artifex.com>
551d7dd426fe8ab7f2c0c9d90339784e2b643bad

> Bug 695483: disable BGPrint before we shutdown interpreter
> Before we start the process of shutting down the PS interpreter, disable BGPrint
> (and set NumRenderingThreads to 0, just for safety). If we don't do this, the
> "parent" rendering thread will continue preparations for the next page whilst
> we shutdown the interpreter, and will thus attempt to access some objects
> subject to garbage collection (such as the I/O device table).
> Additionally, when a device switches from BGPrint enabled to disabled, make sure
> we tear down the rendering thread(s) and get rid off the BGPrint related data.
> No cluster differences.
> gs/base/gdevprn.c
> gs/psi/imain.c

2014-09-15 10:21:18 +0100
Chris Liddell <chris.liddell@artifex.com>
51b9c7dc2a471b9c3dfe6400c0a55d90db4fec16

> Bug 695486: initialise c_alone in current chunk (cc)
> When we (re-)initialise an allocator, we have to initialise the contents of the
> current chunk (cc) entry - initialise to "false" since that's the common case.
> No cluster differences.
> gs/base/gsalloc.c

2014-09-15 15:19:46 +0100
Ken Sharp <ken.sharp@artifex.com>
fec643c7e29810c0c5381bd86ba31ff3595bc9ba

> pdfwrite - free pdfwrite's 'complete' font copy if required
> Bug #695484 "Regression: seg fault with debug build in pdfwrite starting with ceb5e2f006bf554a56701ee2f2c228841b324a4b"
> The problem was caused because pdfwrite can maintain two copies of a font,
> a subset and a complete copy, depending on settings. We were properly freeing
> the subset, but not the complete copy.
> This has been a long-standing undetected memory leak, but only on systems
> without garbage collection, because the copied font is subject to GC, and
> indeed this was causing the actual fault. When we restored at the end of the
> file, the copied font was garbage collected, which caused it to try nd free
> any glyphs from its font cache. But the font cache is now (since the commit
> in the bug title) pointing at the pdfwrite font cache, and that has already
> been freed before we get to the end of job restore, resutling in a seg fault.
> Here we free the complete font copy if one has been allocated.
> No differences expected.
> gs/devices/vector/gdevpdtd.c

2014-09-14 23:00:08 -0600
Henry Stiles <henry.stiles@artifex.com>
d10d0b9f9a4c11ef11f08849cf0f0f0405ada6c6

> Fix Bug 695481 - Barcode font scaled incorrectly.
> The downloaded font in this file (the barcode) used the typeface
> family designation of 0 which is reserved for the lineprinter font.
> Our interpreter scales lineprinter specially and identifies
> lineprinter with its typeface number (0), thus the barcode font was
> scaled as if it were the lineprinter font. Now we check the typeface
> number is 0 and the font is internal which will uniquely identify the
> lineprinter font and not confuse other fonts with it.
> Technically the font is broken and shouldn't be accepted, the typeface
> family numbers documented by HP should not be reused by downloaded
> fonts, but HP printers seem to print the job.
> pcl/pctext.c

2014-09-12 14:49:08 +0100
Chris Liddell <chris.liddell@artifex.com>
f4034b2aa85e685c66e98be8c31c511cd9a5169e

> Get rid of last vestiges of pswrite....
> Remove epswrite (the final "subdevice" of pswrite) and references to it.
> Also remove the gdevps.c source file.
> Cluster differences only in files that enumerate the devices list, for
> example:
> 430-01.ps
> doc/who_owns_what.txt
> gs/Makefile.in
> gs/base/macos-mcp.mak
> gs/base/macosx.mak
> gs/base/openvms.mak
> gs/base/openvms.mmk
> gs/base/unix-gcc.mak
> gs/base/unixansi.mak
> gs/configure.ac
> gs/devices/devs.mak
> gs/devices/vector/gdevps.c
> gs/lib/eps2eps
> gs/lib/eps2eps.bat
> gs/lib/eps2eps.cmd
> gs/man/ps2ps.1
> gs/psi/msvc.mak
> gs/psi/os2.mak
> gs/toolbin/pre.chk

2014-08-27 10:08:45 -0700
Ray Johnston <ray.johnston@artifex.com>
bbe97e4cfc3d725f42ae34125c716902faf72977

> Add lib/viewraw.ps utility to view "raw" files
> An extended version of lib/viewcmyk.ps so that "raw" output from
> bit, bitrgb or bitcmyk can be displayed or converted. For example:
> gswin32c -sDEVICE=bitrgb -dGrayValues=256 -o x.rgb examples/tiger.eps
> can be viewed with:
> gswin32c -dRGB -dBITS=8 -- lib/viewraw.ps x.rgb 612
> gs/lib/viewraw.ps

2014-09-08 14:47:15 +0100
Chris Liddell <chris.liddell@artifex.com>
540a228f026bf3abd288d5e88a7ef74345600380

> Update docs, versions and dates for release candidate.
> gs/base/gscdef.c
> gs/doc/API.htm
> gs/doc/C-style.htm
> gs/doc/Commprod.htm
> gs/doc/DLL.htm
> gs/doc/Deprecated.htm
> gs/doc/Details8.htm
> gs/doc/Details9.htm
> gs/doc/Develop.htm
> gs/doc/Devices.htm
> gs/doc/Drivers.htm
> gs/doc/Fonts.htm
> gs/doc/Helpers.htm
> gs/doc/History1.htm
> gs/doc/History2.htm
> gs/doc/History3.htm
> gs/doc/History4.htm
> gs/doc/History5.htm
> gs/doc/History6.htm
> gs/doc/History7.htm
> gs/doc/History8.htm
> gs/doc/History9.htm
> gs/doc/Install.htm
> gs/doc/Issues.htm
> gs/doc/Language.htm
> gs/doc/Lib.htm
> gs/doc/Make.htm
> gs/doc/News.htm
> gs/doc/Projects.htm
> gs/doc/Ps-style.htm
> gs/doc/Ps2epsi.htm
> gs/doc/Ps2pdf.htm
> gs/doc/Ps2ps2.htm
> gs/doc/Psfiles.htm
> gs/doc/Readme.htm
> gs/doc/Release.htm
> gs/doc/SavedPages.htm
> gs/doc/Source.htm
> gs/doc/Unix-lpr.htm
> gs/doc/Use.htm
> gs/doc/WhatIsGS.htm
> gs/doc/Xfonts.htm
> gs/doc/gs-vms.hlp
> gs/doc/thirdparty.htm
> gs/man/dvipdf.1
> gs/man/font2c.1
> gs/man/gs.1
> gs/man/gslp.1
> gs/man/gsnd.1
> gs/man/pdf2dsc.1
> gs/man/pdf2ps.1
> gs/man/pf2afm.1
> gs/man/pfbtopfa.1
> gs/man/printafm.1
> gs/man/ps2ascii.1
> gs/man/ps2epsi.1
> gs/man/ps2pdf.1
> gs/man/ps2pdfwr.1
> gs/man/ps2ps.1
> gs/man/wftopfa.1

## Version 9.15 (2014-09-22)

This is the eleventh full release in the stable 9.x series, and is primarily a maintenance release.

Highlights in this release include:

- Ghostscript now supports the PDF security handler revision 6.

- The pdfwrite and ps2write (and related) devices can now be forced to "flatten" glyphs into "basic" marking operations (rather than writing fonts to the output), by giving the `-dNoOutputFonts` command line option (defaults to "false")

- PostScript programs can now use get_params or get_param to determine if a page contains color markings by reading the pageneutralcolor state from the device (so whether the page is "color" or "mono").

  Note that this is only accurate when in clist mode, so `-dMaxBitmap=0` and `-dGrayDetection=true` should both be used.

- The pdfwrite device now supports Link annotations with GoTo and GoToR actions

- The pdfwrite device now supports BMC/BDC/EMC pdfmarks

- Regarding the new color management for the pdfwrite device introduced in the previous release, the proscription on using the new color management when producing PDF/A-1 compliant files is now lifted.

  To reiterate, also, with the new color management implementation, using the UseCIEColor option is strongly discouraged.

  For further information on the new pdfwrite color management, see: Color Conversion and Management

- Plus the usual round of bug fixes, compatibility changes, and incremental improvements.

For a list of open issues, or to report problems, please visit bugs.ghostscript.com.

### Incompatible changes

No recorded incompatible changes.

### Changelog

2014-09-08 09:36:19 +0100
Chris Liddell <chris.liddell@artifex.com>
551d7dd426fe8ab7f2c0c9d90339784e2b643bad

> Bug 695483: disable BGPrint before we shutdown interpreter
> Before we start the process of shutting down the PS interpreter, disable BGPrint
> (and set NumRenderingThreads to 0, just for safety). If we don't do this, the
> "parent" rendering thread will continue preparations for the next page whilst
> we shutdown the interpreter, and will thus attempt to access some objects
> subject to garbage collection (such as the I/O device table).
> Additionally, when a device switches from BGPrint enabled to disabled, make sure
> we tear down the rendering thread(s) and get rid off the BGPrint related data.
> No cluster differences.
> gs/base/gdevprn.c
> gs/psi/imain.c

2014-09-15 10:21:18 +0100
Chris Liddell <chris.liddell@artifex.com>
51b9c7dc2a471b9c3dfe6400c0a55d90db4fec16

> Bug 695486: initialise c_alone in current chunk (cc)
> When we (re-)initialise an allocator, we have to initialise the contents of the
> current chunk (cc) entry - initialise to "false" since that's the common case.
> No cluster differences.
> gs/base/gsalloc.c

2014-09-15 15:19:46 +0100
Ken Sharp <ken.sharp@artifex.com>
fec643c7e29810c0c5381bd86ba31ff3595bc9ba

> pdfwrite - free pdfwrite's 'complete' font copy if required
> Bug #695484 "Regression: seg fault with debug build in pdfwrite starting with ceb5e2f006bf554a56701ee2f2c228841b324a4b"
> The problem was caused because pdfwrite can maintain two copies of a font,
> a subset and a complete copy, depending on settings. We were properly freeing
> the subset, but not the complete copy.
> This has been a long-standing undetected memory leak, but only on systems
> without garbage collection, because the copied font is subject to GC, and
> indeed this was causing the actual fault. When we restored at the end of the
> file, the copied font was garbage collected, which caused it to try nd free
> any glyphs from its font cache. But the font cache is now (since the commit
> in the bug title) pointing at the pdfwrite font cache, and that has already
> been freed before we get to the end of job restore, resutling in a seg fault.
> Here we free the complete font copy if one has been allocated.
> No differences expected.
> gs/devices/vector/gdevpdtd.c

2014-09-14 23:00:08 -0600
Henry Stiles <henry.stiles@artifex.com>
d10d0b9f9a4c11ef11f08849cf0f0f0405ada6c6

> Fix Bug 695481 - Barcode font scaled incorrectly.
> The downloaded font in this file (the barcode) used the typeface
> family designation of 0 which is reserved for the lineprinter font.
> Our interpreter scales lineprinter specially and identifies
> lineprinter with its typeface number (0), thus the barcode font was
> scaled as if it were the lineprinter font. Now we check the typeface
> number is 0 and the font is internal which will uniquely identify the
> lineprinter font and not confuse other fonts with it.
> Technically the font is broken and shouldn't be accepted, the typeface
> family numbers documented by HP should not be reused by downloaded
> fonts, but HP printers seem to print the job.
> pcl/pctext.c

2014-09-12 14:49:08 +0100
Chris Liddell <chris.liddell@artifex.com>
f4034b2aa85e685c66e98be8c31c511cd9a5169e

> Get rid of last vestiges of pswrite....
> Remove epswrite (the final "subdevice" of pswrite) and references to it.
> Also remove the gdevps.c source file.
> Cluster differences only in files that enumerate the devices list, for
> example:
> 430-01.ps
> doc/who_owns_what.txt
> gs/Makefile.in
> gs/base/macos-mcp.mak
> gs/base/macosx.mak
> gs/base/openvms.mak
> gs/base/openvms.mmk
> gs/base/unix-gcc.mak
> gs/base/unixansi.mak
> gs/configure.ac
> gs/devices/devs.mak
> gs/devices/vector/gdevps.c
> gs/lib/eps2eps
> gs/lib/eps2eps.bat
> gs/lib/eps2eps.cmd
> gs/man/ps2ps.1
> gs/psi/msvc.mak
> gs/psi/os2.mak
> gs/toolbin/pre.chk

2014-08-27 10:08:45 -0700
Ray Johnston <ray.johnston@artifex.com>
bbe97e4cfc3d725f42ae34125c716902faf72977

> Add lib/viewraw.ps utility to view "raw" files
> An extended version of lib/viewcmyk.ps so that "raw" output from
> bit, bitrgb or bitcmyk can be displayed or converted. For example:
> gswin32c -sDEVICE=bitrgb -dGrayValues=256 -o x.rgb examples/tiger.eps
> can be viewed with:
> gswin32c -dRGB -dBITS=8 -- lib/viewraw.ps x.rgb 612
> gs/lib/viewraw.ps

Ken Sharp <ken.sharp@artifex.com>
8605f67582ae2e2e619ab6fbab9888a23f37fdb9

> pdfwrite - tidy up some compiler warnings
> No effect, just silences the compiler or scan-build.
> gs/devices/vector/gdevpdfp.c
> gs/devices/vector/gdevpsdp.c

2014-09-04 14:49:21 +0100
Chris Liddell <chris.liddell@artifex.com>
b4c9acd0ca532d19421fdf83aa9ad71895fad753

> Remove the uproduct and co targets.
> Replaced (for now) with a brief message about being unsupported, and to use
> configure --with-ufst=<>
> No cluster differences.
> Makefile

2014-09-04 14:34:58 +0100
Chris Liddell <chris.liddell@artifex.com>
91e8954e01996853ce6dc1318465c7b55e9d1f90

> Better mkromfs support for cross compile
> When cross compiling between platforms of differening endianness, mkromfs will
> now create output usable on the target architecture.
> No cluster differences.
> gs/base/mkromfs.c

2014-09-04 14:31:25 +0100
Chris Liddell <chris.liddell@artifex.com>
bfeeadc3d534cb01fe6dd3bfb21a0af1e55b0a48

> Tweak "search" for default CID fallback font.
> Fix an issue where the default fallback font could not be found if the
> GenericResourceDir was a relative path.
> No cluster differences.
> gs/Resource/Init/gs_cidtt.ps

2014-09-05 15:03:05 +0100
Ken Sharp <ken.sharp@artifex.com>
201ff60b950912c09d22b3b4ed0b57ed75c3587a

> pdfwrite - consume Distiller params even when LockDistillerparams is true
> Bug #695468 "/rangecheck in .installpagedevice error when combining LockDistillerParams, setpagedevice, and restore"
> Previously when LockDistillerParams was true the distiller param parsing
> code did not get called. This left the Distiller parameter key/value
> pairs 'untouched' in the parameter list.
> Ordinarily this is not a problem, but .installpagedevice, which is called
> during restore to reset the page device parameters, insists that all keys
> must be consumed and throws an error if they are not.
> This patch alters the distiller parameter parsing to read all the parameters
> no matter what the setting of LockDisillerParams. The values are read into
> a dummy parameter structure, when complete they are either copied back to
> the real structure or, if LockDistillerParams is set, discarded. If we
> discard the parameters we clean up the memory rather than relying on garbage
> collection to do it for us.
> I don't think the pdfwrite device currently does this when the device is
> closed, which would be a memory leak, if we ever decide we need to address
> this then we can use the code here.
> No differences expected.
> gs/devices/vector/gdevpdfp.c
> gs/devices/vector/gdevpsdp.c

2014-09-04 13:16:48 +0100
Ken Sharp <ken.sharp@artifex.com>
ce3445892ca6094a5c681667b1ecc1aa07c87254

> Improved form handling of clip areas
> Bug #695307 "Preservation of PostScript form elides form content"
> When a device (such as pdfwrite) hands back a matrix to set as the CTM
> (pdfwrite does this to capture the form unscaled), we need to account for
> that CTM when we reset the clip, otherwise we can end up clipping content.
> Also, rather than using +/- page boundaries, we use +/- the form BBox.
> This shows 2 minor progressions in the test suite.
> gs/psi/zform.c

2014-09-02 15:27:25 +0100
Ken Sharp <ken.sharp@artifex.com>
ceb5e2f006bf554a56701ee2f2c228841b324a4b

> Address leaking font cache in PCL interpreter
> Bug #695017 "pcfont_do_reset() leaks memory"
> The PCL interpreter should free its font cache on exit, but it does not.
> This is because of the fact that when we copy fonts the font cache of the
> original font is copied to the font cache of the copied font. Later, when
> a high level device wants to retrieve glyph information, the font code
> uses the font cache from the copied font.
> This doesn't immediately seem like a problem, it seems like we should be
> able to defer freeing the font cache until after we've closed the device,
> and that would satisfy pdfwrite. However, the way that PCL 'passthrough'
> works, the PCL interpreter can be run 'inside' the PXL interpreter. If we
> free the PCL interpreter font cache when it exits then pdfwrite has font
> copies which are still pointing at the freed font cache.
> We did discuss having the PCL/PXL interpreter set the gs_lib_ctx font_dir
> (it currently dos not do so) and having pdfwrite set the font cache of the
> fonts it copies use that, instead of the font cache from the original font.
> But this seemed to me likely to run into the possibility of the same problem
> recurring in future.
> Instead, we have pdfwrite create and maintain its own font cache. When pdfwrite
> copies a font it replaces the font cache pointer (which is initially the same
> as the original font) with the new pdfwrite-specific font cache.
> This means that any interpreter can free its font cache and pdfwrite will
> still be able to use its own font cache when retrieving glyph information.
> This commit includes both the changes to pdfwrite to enable the new font cache
> and the changes to the PCL/PXL interpreter to free the font cache when the
> interpreter is done with it.
> No differences expected.
> gs/devices/vector/gdevpdf.c
> gs/devices/vector/gdevpdfb.h
> gs/devices/vector/gdevpdfx.h
> gs/devices/vector/gdevpdtb.c
> pcl/pcfont.c

2014-09-02 09:40:20 +0100
Chris Liddell <chris.liddell@artifex.com>
884b9e456336b1fd7ddb3c50726be5469159421a

> Bug 695235: off-by-one error in trio
> Tweak to deal with off-by-one errors due to casting of doubles in trio.
> No cluster differences.
> gs/trio/trio.c

2014-08-29 17:19:58 +0100
Chris Liddell <chris.liddell@artifex.com>
c670fd6b0852aa057103632630bab81c9317b613

> Tweak the libtiff configure invocation to use relative paths.
> No cluster differences.
> configure.ac
> gs/configure.ac

2014-08-29 16:05:38 +0100
Chris Liddell <chris.liddell@artifex.com>
d0c3d8e6b0f5ce246ad5e3d08b1628b529f99582

> Add quoting around paths for libtiff configure.
> No cluster differences.
> configure.ac
> gs/configure.ac

2014-08-28 10:09:41 +0100
Ken Sharp <ken.sharp@artifex.com>
3ff453592e3ae6d98a640047765a5baf1e345964

> More work with setpagedevice
> commit 55bd0a59caf26a59f852e2dec5b76ad399d9408b fixed the problems with
> RedValues and friends, but at the cost of preventing these keys being set
> by setpagedevice.
> This commit allows them to be set by creating a 'write only' dictioanry
> whose keys are removed from the initial device dictionary before we make it
> read-only and send it to setpagedevice.
> See the comments in the commit for further details.
> No differences expected.
> gs/Resource/Init/gs_setpd.ps

2014-08-27 14:45:33 +0100
Ken Sharp <ken.sharp@artifex.com>
55bd0a59caf26a59f852e2dec5b76ad399d9408b

> Fix setpagedevice so that changing ProcessColorModel works
> Bug #695439 "Reference to free memory, or segfault with release build"
> The problem is the horrendous way our implementation of setpagedevice works.
> Where we should query the device for its parameters, our implementation
> maintains a dictionary (initially built by querying the device) which is
> updated by calls to setpagedevice.
> Clearly at some time in the past someone has discovered that this breaks
> badly if the device changes a parameter itself, as this won't be reflected
> in the saved dictionary. So the '.dynamicppkeys' dictionary was defined,
> whose sole purpose is to hold a list of keys whose values must be refreshed
> from the device.
> However, this dictionary is *also* used to prevent those same keys being
> sent to the device.....
> This means that commit 2eda51b48c7e97adf7c46fc3d7eb34fcdf6061e6 prevented
> any changes to OutputICCProfile being sent to the device.
> So I've now made 2 dictionaries with separate purposes, one is for 'read only'
> keys which should not be sent to the device, and one which contains the list
> of keys which must be read back from the device to replace the stored values
> in our dictionary. Keys may appear in both, either, or neither.
> The problem in this bug is that we create our initial dictionary when the
> device is in DeviceRGB, and we store the RedValues, GreenValues, BlueValues
> and GrayValues from the device in our stored dictionary. Then we execute
> code to change the ProcessColorModel to DeviceGray. This alters the values
> of the RedValues etc in the device. But these are *not* copied into our
> stored dictionary. Later we call .installpagedevice which does not change
> the ProcessColorModel, but does attempt to set the RedValues etc, which are
> invalid for a DeviceGray ProcessCOlorModel, leading to a rangecheck.
> I had hoped that adding these keys to the volatile dictionary would be
> sufficient to fix the problem, but it seems that we don't update our stored
> dictionary with these parameters. The only way to fix this turned out to be
> to add the keys to the 'read only keys' dictionary so that we don't try and
> send them to the device.
> I'm not completely sure this is sensible, it isn't obvious to me what these
> values are for, so I can't be certain that they should become 'read only'.
> However, its the simplest way to solve this problem.
> Of course the right way to fix this is to change our horrible setpagedevice
> code so that it works the way the spec says it should.
> The fix described above resolves the memory warning for me as well.
> No differences expected.
> gs/Resource/Init/gs_setpd.ps

2014-08-25 15:16:13 +0100
Ken Sharp <ken.sharp@artifex.com>
5ce2fca754b4ba5bce4194bae382ef1d46abaf00

> pdfwrite - fix handling of Tx fields in AcroForms
> Bug #695438 "AcroForm text fields not being rendered"
> There are multiple parts to this fix.
> 1) Alter the default of the NeedAppearances key in AcroForms and AcroForm
> field dictionaries to true so that if its not present we will generate
> Appearances for fields which have none. (we still won't generate them if
> the field is present and set to false, though Acrobat does)
> 2) Fix the Length key of the Form dictionary we generate for Tx fields,
> previously it was set to 0, so the form wasn't ever executed.
> 3) If there is no 'V' key in the Field dictionary for a Tx field, use the
> /DV key instead. If still no key then use an empty string.
> These changes uncovered some interesting additional problems.
> 1) Bug687498 has an AcroForm with a Tx field, declared as multiline, where
> the actual data is an empty string. Now that we actually execute the Form
> this causes an error. Add a check to treat strings with less than 2 bytes
> as single line, so that splitstring doesn't throw an error.
> 2) Bug692477.pdf, now that we default 'NeedAppearances' to true, we discover
> that this file has a Fields array where every element is the null object,
> which causes errors trying to extract dictionary key/value pairs from it.
> Add a check to see that the Field element is a dictionary, and ignore it if
> it isn't.
> No differences expected, we don't test with -dShowAcroForm
> gs/Resource/Init/pdf_draw.ps
> gs/Resource/Init/pdf_main.ps
> gs/Resource/Init/pdf_ops.ps

2014-08-20 08:54:16 -0700
Ray Johnston <ray.johnston@artifex.com>
2eda51b48c7e97adf7c46fc3d7eb34fcdf6061e6

> Bug 695420: Bad pointer to OutputICCProfile string.
> This was caused by the gs_setpd.ps logic having a dictionary that has the
> OutputICCProfile pointing to dev->icc_struct->device_profile[0]->name, but
> when ColorConversionStrategy distillerparam is set, it does a rc_decrement
> on the pdev->icc_struct which frees the entire structure, among those the
> 'name' (which was allocated in non_gc_memory).
> Add the OutputICCProfile to the list of .dynamicppkeys in gs_setpd.ps so
> that the string will always be updated and the dictionary won't have a
> stale pointer.
> Having a dict with a string in non_gc_memory is OK I guess, even though
> we generally "hide" all non_gc_memory elements from the GC.
> gs/Resource/Init/gs_setpd.ps

2014-07-24 17:41:32 -0700
Ray Johnston <ray.johnston@artifex.com>
b181cc746811d2920cfe183d8fd341de944d65b3

> Add a missing condition for devices that need tags to pdf14_recreate_device.
> Customer 532 has done extensive testing and uses tags. This change
> is in their code.
> gs/base/gdevp14.c

2014-08-18 16:40:53 +0100
Ken Sharp <ken.sharp@artifex.com>
727340d4bd2a42b2793d00c3b5cd36facdf26e92

> pdfwrite - fix a ShadingType 5 with array DataSource and a Function
> Bug #695359 "Wrong gradients after conversion to PDF"
> The example file is a hand-coded shading of type 5 with the DataSource
> being an array, but using a function to convert the parametric value at
> each vertex into a colour value.
> The PDF specification doesn't support this kind of shading, so we need
> to convert it. In doing so we write out a Decode array, which needs to contain
> the minimum and maximum colour values. Ordinarily we get these from the
> shading dictionary, but when using an array for DataSource this is not
> present. In the absence of the Decode array we were defaulting to 0 and 1
> but the function actually has a range from 0 to 10. This meant we were
> truncating the colour space.
> This commit examines the Function (if present) and uses the Domain of the
> function as the values instead of 0 and 1.
> This may not be sufficient in the absolute general case, but all mesh
> shadings are rare in real world files, and mesh shadings using array
> DataSource are still less common, as are examples with a function which
> does not have a Domain 0-1. So this will suffice until we see more
> problems.
> Note that Acorbat Distiller X produces different output if you run the
> two shadings in the example file separately instead of consecutively. Also
> Acrobat X displays the resulting file from both Distiller and Ghostscript
> incorrectly (Acrobat XI displays them correctly)
> No differences expected.
> gs/devices/vector/gdevpdfv.c

2014-08-18 09:15:48 +0100
Ken Sharp <ken.sharp@artifex.com>
db7668753ca114aabc4d34063876732dc043e9b8

> PDF interpreter - read BPC from the JPX stream instead of the resource dict
> Bug #695387 "PDF with jpeg2000 conversion problems"
> The PDF spec states (table 4.39, BPX on page 340 of the PDF Rerference)
> that the Bits Per Component value is to be taken from the JPX stream and
> the image dictionary value should be ignored if present. We were only
> reading the BPC if either that to the ColorSpace was missing from the
> image dictionary.
> In this commit we *always* pare the data out of the JPX stream (which is
> a small performance penalty). However, this always overwrites the data in
> the resource dictionary, which is fine for BPX< but not acceptable for the
> colour space, because Acrobat favours the ColorSpace in the
> image dictionary over the JPX colour space, and because we set the colour
> space to be DeviceGray for softmasks.
> So we save the colour space from the resource dictionary (if present), read
> the BPC and colour space then, if we had a colour space in the resource
> dictionary we restore it back again.
> For some reason this causes problems on the cluster with the test file
> Bug688845.eps. Since this change only affects JPX images, and PDF files, I
> can't see any way that the change can be responsible for this. I am unable
> to reproduce the problem on Windows or Linux locally.
> gs/Resource/Init/pdf_draw.ps

2014-08-15 11:30:01 +0100
Chris Liddell <chris.liddell@artifex.com>
a7e8f7592a9861f83dbb94b8b545961caca864ce

> Bug 694160: Prevent malicious code being injected into the system.
> This is essentially the same patch as committed in:
> 4fc4b8410d35b193d549558ab212cc727db9460b
> but that patch was missing white space at the ends of automatically
> concatenated strings - hence the interpreter saw, for example:
> ".systemexecend" rather than ".systemexec end".
> Additionally, to avoid that confusion in the future, I've removed the reliance
> on the automatic string concatenation.
> Also removed a spurious additional call to ".uninstallpagedevice".
> No cluster differences.
> gs/Resource/Init/gs_init.ps
> gs/psi/imain.c

2014-08-15 10:14:36 +0100
Ken Sharp <ken.sharp@artifex.com>
1db534ed2b1277b265652d4b660b11e957a3e0bf

> Revert commit 4fc4b8410d35b193d549558ab212cc727db9460b
> See bug #694160 and #695420. Somehow this patch ends up leaving 'quit'
> undefined at the end of job, which breaks the '-o' switch. It also somehow
> manages to break at least some pdfwrite incantations, leading to an undefined
> error with a garbage caller. It kind of looks like the name table is
> broken or similar.
> Note that the undefined error on quit occurs when running GS interactively
> and even when this happens, "systemdict /quit get exec" works, so its not
> as simple as /quit being undefined.
> No differences expected.
> gs/Resource/Init/gs_init.ps
> gs/psi/imain.c

2014-08-13 20:33:36 +0100
Chris Liddell <chris.liddell@artifex.com>
062f4b4536b7b3fa1742e31c05dc57fe241d6690

> Bug 695423: follow up.
> Fix the description comments.
> No cluster differences
> gs/devices/devs.mak

2014-08-13 19:28:04 +0100
Gerard Belanger <gbelanger@practicalautomation.com>
25a0cd96ac4b44d96e27c435dad5cc2c31788733

> Bug 695423: Add current generation printers to gdevatx.c
> Practical Automation printers.
> No cluster differences.
> gs/configure.ac
> gs/devices/devs.mak
> gs/devices/gdevatx.c

2014-08-12 10:17:01 +0100
Ken Sharp <ken.sharp@artifex.com>
9a80562145b25a7166bd7c8e005446bd306be34e

> ps2write - fix conversion of TrueType fonts with format 0 LOCA tables
> Bug #695417 "gs(ps2write) produce invalid ps from certain LibreOffice print emission"
> The code in the opdfread prolog for converting TrueType fonts to type 42
> fonts was completely broken for fonts with a format 0 LOCA table (16 bit
> offsets). The offending routine is StringToLoca.
> The code was reading 32 bits instead of 16, which causes it to exhaust
> the string data, leaving array members uninitialised, which is the inital
> cause of the error. However, it also didn't multiply the offsets it did
> read by 2 (format 0 LOCA offsets are multiplied by 2), and had a 'dup'
> which resulted in the stack having the wrong value on top on exit.
> No differences expected
> gs/devices/vector/opdfread.h
> gs/lib/opdfread.ps

2014-08-11 21:22:46 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
4fc4b8410d35b193d549558ab212cc727db9460b

> Bug 694160: Prevent malicious code being injected into the system.
> gs/Resource/Init/gs_init.ps
> gs/psi/imain.c

2014-08-08 11:55:55 +0100
Ken Sharp <ken.sharp@artifex.com>
5be9d0429b79f53b0e074fb1042cf3e88134ba0d

> remove an unused variable to silence a compiler warning
> gs/devices/gdevtsep.c

2014-08-08 10:07:24 +0100
Ken Sharp <ken.sharp@artifex.com>
3a035a2a9e94196920f99a18670ee96202f67bb9

> tiffsep - add code to print CMYK equivalents for spot inks
> Bug #695407 "tiffsep should print out separation equivalent CMYK"
> Patch supplied by Mateusz Lenik to print out the CMYK equivalents for every
> ink in the job.
> Controlled by the new PrintSpotCMYK switch, which is only supported on the
> tiffsep device, documented in devices.htm.
> No differences expected.
> gs/devices/gdevtsep.c
> gs/doc/Devices.htm

2014-08-05 13:25:01 +0100
Chris Liddell <chris.liddell@artifex.com>
5671fc9b4b5fc8abb326e60195dff7ec46d5b389

> Bug 695394: fix TTF glyph encoding generation
> There was a logical error in the glyph encoding generation for TT fonts,
> affecting fonts without post tables.
> When handling the case where the same glyph name references two different
> glyphs, the index in the glyph encoding we wrote the generated name to was the
> GID (i.e. the index returned from the cmap table) rather the original index
> we were handling from the glyph encoding.
> No cluster differences.
> gs/Resource/Init/gs_ttf.ps

2014-08-01 14:50:40 +0100
Ken Sharp <ken.sharp@artifex.com>
275dc99017b96c1be74a50026479dbdf8d63192f

> PDF interpreter - fix Hybrid file parsing
> Bug #695403 "Error ocurred while reading XREF table"
> The fix for bug #694342 treated an xref section with no entries as an error
> and caused the xref to be rebuilt. However, if a PDF file is converted into
> a hybrid file (one with an xref *and* an XrefStrm) by adobe CS 3, then it
> does this by adding a 'dummy' xref which has a /Prev pointing to the real
> xref, and a /XrefStrm pointing to the stream.
> The dummy xref has a section "0 0", is first object 0, no objects defined
> which falls foul of the test for Bug 694342 and causes the xref to be rebuilt.
> This commit adds a boolean which is initially false and is set true in the
> parsing loop for the xref section. When we encounter a /trailer, instead
> of checking if 0 objects are defined, we now look at that boolean. If its
> 'true' then we have seen a section entry, and can treat this as valid, even
> if no objects are yet defined. If we haven't seen a section then we treat
> it as invalid and force an xref rebuild.
> This causes sumatra/694313_-_empty_xref.pdf to stop producing errors as
> well.
> gs/Resource/Init/pdf_main.ps

2014-08-01 09:52:00 +0100
Ken Sharp <ken.sharp@artifex.com>
80395ccbe7558e324ff3cb75c3e241ce0ffd735d

> ps2write - fix a bug in the debug code
> The PrintHex routine assumes that PostScript integers are 32 bits wide.
> This is no longer guaranteed with GS. This fix ensures that after we do
> the bit shifting to isolate 4 bits for conversion to hex, we don't have
> a number > 15, which could occur if the integer was sufficiently large.
> This prevents the code throwing an error when debugging.
> No differences expected
> gs/devices/vector/opdfread.h
> gs/lib/opdfread.ps

2014-07-30 15:33:00 +0100
Chris Liddell <chris.liddell@artifex.com>
9fbecef99a40d8a5b372fadf4ed99fe29c6815a9

> Bug 695397: handle "unknown" glyph names >16 chars long
> When creating glyph aliases for a TTF, we check for "formatted" unicode glyph
> names of the form "uniWXYZ" where "WXYZ" is the glyph code point in base 16.
> In doing that we use a temporary string which is 16 characters long (since the
> formatted names we're interested won't be longer that 16).
> So, check the glyph name is <16 chars long before checking if it's a "uni..."
> style name.
> No cluster differences.
> gs/Resource/Init/gs_ttf.ps

2014-07-30 08:34:29 +0100
Chris Liddell <chris.liddell@artifex.com>
7a2d86136669e79742aacda148e5c70854273ca5

> Bug 695380: add a simple sanity check in i_alloc_string
> Checks for integer overflow.
> No cluster differences.
> gs/base/gsalloc.c

2014-07-29 17:26:27 +0100
Chris Liddell <chris.liddell@artifex.com>
f25cb59f2ed56df8366d03c5cb7d9b37dec77934

> Bug 695319: Set pdf14 (trans) ctx to NULL on free on error
> In the event of an interpreter triggered error during a transparency operation,
> pdf14_discard_trans_layer() is called to clean up. It frees the context, but
> didn't set the ctx pointer to NULL - thus we could try to free the already
> freed context object when the pdf14 compositor device is shut down.
> No cluster differences.
> gs/base/gdevp14.c

2014-07-29 15:37:45 +0100
Chris Liddell <chris.liddell@artifex.com>
e889a18896e668e5e565e5ec1cada8b8a64c60a2

> Bug 695318: mark memory chunks used for single allocations.
> Certain chunks in the memory manager are used to contain only one (o_alone)
> allocation: "large" allocations and "immovable" allocations specifically.
> We need to be able to identify those chunks so we don't end up trying to use
> any empty space in them for later allocations - these chhunks can end up with
> empty space in them if the original object allocated in them is shrunk.
> The problem that occurs is when we free an o_alone object, we immediately free
> the chunk containing it, thus any other allocations in that chunk are also
> freed.
> Adding a c_alone flag to the chunk means we can trivially identify and skip
> those chunks when searching for free memory.
> No cluster differences.
> gs/base/gsalloc.c
> gs/base/gxalloc.h

2014-07-25 15:57:30 +0100
Chris Liddell <chris.liddell@artifex.com>
21d86e8264a6cd11f963b4c36b989ab4c0ed3294

> Bug 695363: handle TTF with no/empty loca table.
> A broken TT font could end up with us allocating a zero length array for
> the for the glyph lengths, then later to attempt to access entries in that
> array.
> Thus, avoid allocating the zero length array, and treat a NULL glyph_len array
> the same as a glyph_len of 0.
> No cluster differences.
> gs/base/gstype42.c

2014-07-24 14:26:30 -0700
Ray Johnston <ray.johnston@artifex.com>
ea4547f4bc24803f167e8a0b1a1384d9dc8af9e8

> Add setting buf->backdrop to NULL when knockout is false.
> Minor issue, but I did find a case where the buf->backdrop was left
> uninitialized when working on customer 532 issue with fts_25_2526.pdf
> gs/base/gdevp14.c

2014-06-02 21:17:54 +0200
Tor Andersson <tor.andersson@artifex.com>
23f71dd93eeac60f0ff3c58b17bcd8ccd2d971d6

> xps: Remove trailing whitespace.
> xps/xpsgradient.c
> xps/xpsimage.c
> xps/xpsjxr.c
> xps/xpsopacity.c
> xps/xpspath.c
> xps/xpspng.c
> xps/xpstiff.c

2014-06-02 21:06:47 +0200
Tor Andersson <tor.andersson@artifex.com>
eed68003a30b64649157b7dcdcfc1d5162c3bb63

> xps: Allow colormapped 1-bit TIFF files.
> Thanks to Norbert Janssen.
> xps/xpstiff.c

2014-06-02 21:01:18 +0200
Tor Andersson <tor.andersson@artifex.com>
3b03ee5480ab38f0d7b4e2ad341385d7dffd8343

> xps: Improve transparency analysis for resource dictionaries.
> Thanks to Norbert Janssen.
> xps/xpsanalyze.c

2014-07-22 09:09:47 +0100
Ken Sharp <ken.sharp@artifex.com>
8d3081c0403a1d911a79dce57008ede4279d050a

> pdfwrite and ps2write - Mimic the -dNOCACHE output of pswrite
> This feature is in response to the thread on gs-devel "pswrite and NOPLATFONTS"
> Normally pdfwrite and ps2write try very hard to maintain fonts from the input
> as fonts in the output, for reasons of output size, performance and qualiity.
> It seems that some people are relying on using pswrite with -dNOCACHE in
> order to produce PostScript output with no fonts at all. (As far as I can
> see this is to address the limitations of other software). This was never
> a goal for pswrite, but it seems that it works 'well enough' to be useful.
> Sadly, despite us flagging the fact that pswrite had been deprecated, nobody
> gave us any feedback until after (several releases after, in fact) we had
> removed the device. We are not going to reinstate support for the pswrite
> device, having spent effort to remove it in order to drop support for it,
> so this commit adds a new feature which causes pdfwrite and friends to
> write the glyph description into the content stream as it is used instead
> of constructing fonts.
> This is controlled with the new switch NoOutputFonts which defaults to false
> There are no cluster differences with this commit. Using the switch causes
> pretty much every test file which contains text to render differently.
> gs/devices/vector/gdevpdfb.h
> gs/devices/vector/gdevpdfp.c
> gs/devices/vector/gdevpdfx.h
> gs/devices/vector/gdevpdtt.c
> gs/doc/Ps2pdf.htm

2014-07-21 11:02:55 +0100
Chris Liddell <chris.liddell@artifex.com>
b6575b8a91e23365b340771fc67b29819ba7937b

> Have pdfwrite/ps2write "flatten" glyphs...
> ...into "normal" marking ops if the glyph cache is disabled.
> gs/devices/vector/gdevpdtt.c

2014-07-11 13:52:31 +0100
Chris Liddell <chris.liddell@artifex.com>
f35a388327055a3a2635c91f5e1080af6d957d37

> Bug 694205: prevent crash rendering unfeasibly large glyph
> Initialise the "prev" entry in the top node in the x line list to null and
> check it isn't null before we use it. If we reach that point, it indicates that
> a) the current path reaches (and probably passes) the limits of our coordinate
> space and b) the line list is already in the correct order - as best it can be,
> anyway.
> No cluster differences.
> gs/base/gxfill.c

2014-07-16 13:14:42 -0600
Henry Stiles <henry.stiles@artifex.com>
56162c7c6c55bd2f98e4a25fa399c0a5865f7249

> Bug #695367 - Writing a 64 bit integer into a 32 bit format specifier
> corrupted sprintf's variadic argument list on some (windows)
> platforms.
> gs/devices/vector/gdevxps.c

2014-07-14 16:05:36 -0600
Henry Stiles <henry.stiles@artifex.com>
ef4150919c5dc6c0fcf441cc499a3250d8a6529e

> Use a conditional form feed when selecting a page side, #695325.
> pcl/pcjob.c

2014-06-27 06:59:09 -0600
Henry Stiles <henry.stiles@artifex.com>
a6fc36d436fa166c87d4d75d3f7d037f80cf6ce6

> Bring comment in line with recent changes to the printable region.
> pcl/pcxfmst.h

2014-07-07 12:31:13 +0100
Ken Sharp <ken.sharp@artifex.com>
4823edf7be9b8dd1e40306e1b5e0f0edbecb84be

> pdfwrite - prevent closing the device if its not open
> Bug #694380 "Seg fault in pdfwrite"
> The file in question throws an error in pdfwrite when we try to write a
> FontDescriptor (the font is broken). The PDF interpreter, however,
> often ignores errors and continues trying to process the input file.
> When producing one output file this is not a problem, as the error occurs
> in pdf_close() and so it all works. However, when producing one file per
> page this fails, because we close the device, notice the error, and
> do not open it anew. However the PDF interpreter just carries on. When we
> come to the end of the next page we try to close a device which is already
> closed, and this means we try to dereference an invalid pointer.
> In this commit we check the 'is_open' flag of the device in pdf_close and
> if the device is not open then we jump straight back out. We also set is_open
> to false in the same routine as it wasn't previously being set (because we
> couldn't previously close and reopen the device).
> This fixes the problem with Bug693711.pdf for me.
> gs/devices/vector/gdevpdf.c

2014-07-07 09:00:20 +0100
Ken Sharp <ken.sharp@artifex.com>
84bdbfec67808ea22ec152a56bcb33655ef084aa

> pdfwrite - add an include file for a prototype, silences a compiler warning
> gs/devices/vector/gdevpdfk.c

2014-07-04 12:02:59 +0100
Ken Sharp <ken.sharp@artifex.com>
ddae2b83fd7e91053d62b2d4533e850fdba341bf

> pdfwrite - fix memory corruption caused by type 3 capture of PCL fonts
> Bug #695350 "GhostPCL line shifting"
> It was impossible to reproduce this bug exactly as the reporter is running
> Ghostscript on an unusual platform. Fortunately what appears to be the same
> problem could be reproduced on a PowerPC Mac running Linux. It is possible
> that this commit doesn't actually fix the bug though.
> When capturing glyph descriptions in order to build a type 3 font from a
> PCL font, we were saving the default text procedures from the enumerator
> (which was created by gx_default_text_begin), and then restoring them when
> we had finished processing the glyph. However, by that time we had already
> releases the enumerator, which meant we were corrupting memory.
> Desk checking the code, I can't see any reason for saving the procedures
> from the text enumerator, and I conclude this is either a holdover from an
> earlier version of this code, or an oversight when writing the code that
> captured PCL fonts. In any event this commit removes the save/restore
> behaviour, since it is definitely causing memory corruption.
> No differences expected.
> gs/devices/vector/gdevpdtt.c

2014-07-02 13:42:07 +0100
Ken Sharp <ken.sharp@artifex.com>
3bfacc81f717f6e658f3cb4575ded0c36919ec4e

> pdfwrite - detect corrupted type 3 fonts and generate an errror
> Bug #694186 "Seg faults found by fuzzing in names_index_ref"
> The file has a corrupted glyph in a type 3 font, which throws an error.
> However, pdfwrite can't tell that the glyph threw an error rather than
> simply completing successfully, and tries to use the returned glyph ID. The
> glyph ID is GS_NO_GLYPH which fails with a seg fault when looking up the
> name.
> In this commit we check the glyph ID to see if its GS_NO_GLYPH and throw an
> error if it is. This prevents us looking up an invalid glyph ID in the
> name table, and the file is demonstrably broken.
> This fixes a1c8db... the other file, cc5c... is also fixed, but in newer
> code never even makes it to this point as the current code detects a different
> problem before it reaches this point.
> gs/devices/vector/gdevpdtt.c

2014-07-01 17:30:17 +0100
Ken Sharp <ken.sharp@artifex.com>
4d2e447a5226bf8b1baf6f079f3e767c72928d88

> pdfwrite - ensure we have V2 ICC profiles for PDF/A-1 and PDF < 1.5
> Bug 695118 "PDF/A-file is generated with ICC version 4.2 profiles"
> PDF/A-1 requires us to use ICC v2 profiles due to the level of PDF mandated
> by the spec. In addition, we should not use V4 profiles when producing
> PDF less than 1.5.
> Michael added considerable code to allow us to get a V2 profile, given a
> V4 profile, and this commit makes the changes required for pdfwrite. Its more
> extensive than appears necessary because we need access to the current
> imager state in order to generate the V2 profile, so a large number
> of routines have been altered to pass along the imager state (or NULL in
> some cases, where we can only be dealing with device spaces anyway).
> We also change the default version of PDF we produce to 1.5 so that we can
> emit V4 profiles and alter the 'prepress' predfined settings similarly.
> This causes changes in a Genoa CET file, but its just different, not wrong.
> gs/Resource/Init/gs_pdfwr.ps
> gs/devices/vector/gdevpdf.c
> gs/devices/vector/gdevpdfb.c
> gs/devices/vector/gdevpdfc.c
> gs/devices/vector/gdevpdfc.h
> gs/devices/vector/gdevpdfg.c
> gs/devices/vector/gdevpdfg.h
> gs/devices/vector/gdevpdfi.c
> gs/devices/vector/gdevpdfk.c
> gs/devices/vector/gdevpdft.c
> gs/devices/vector/gdevpdfv.c

2014-07-01 09:41:38 +0100
Ken Sharp <ken.sharp@artifex.com>
c4dfed923d2513e4b79f8c765b5682e628b2fa60

> pdfwrite - colour conversion
> When converting a Separation alternate space we create a new space which
> uses the ink name pf the Separation. We were putting the name into the
> space without copying it, which can lead to it being freed while the original
> space is still pointing to it.
> Follow on from commit e492e1671b7b1041ba123a22c1df3b920cf753af which
> addressed DeviceN spaces.
> No differences expected.
> gs/devices/vector/gdevpdfg.c

2014-06-30 10:14:08 +0100
Ken Sharp <ken.sharp@artifex.com>
c88ded04ea9977d994b243720b8fa32bc7fa56e7

> Type 42 font - correctly initialise Max Composite points and Contours
> The previous commit which initiaslised these (by me) was incorrect, the
> values are 2 byte shorts, not 4 byte ints.
> No differences expected.
> gs/base/gstype42.c

2014-06-30 09:40:26 +0100
Ken Sharp <ken.sharp@artifex.com>
e492e1671b7b1041ba123a22c1df3b920cf753af

> pdfwrite - colour conversion of DeviceN alternate spaces
> Bug #695306 "Converting a PDF to RGB colorspace causes missing drawing parts"
> There are two problems addressed in this commit.
> Firstly the code wasn't catering properly for the possibility of an /Indexed
> DeviceN space. We did dereference the Indeexed space, but not until after
> we had tried to use the original space as a DeviceN, with unfortunate
> potential results. We move the dereference to the top of the function
> convert_DeviceN_alternate so that we properly use the DeviceN space.
> Secondly when creating the new colour space (ie with a different alternate
> space), we add the names of the inks from the original DeviceN space.
> However, we were using add_no_copy which meant when the new array was
> garbage collected we freed the names, but left them being pointed at by
> the original array, leading to pointers to garbage memory.
> No differences expected as the colour conversion is not tested by the cluster
> gs/devices/vector/gdevpdfg.c

2014-06-27 04:58:24 -0700
Ray Johnston <ray.johnston@artifex.com>
9f7902c6a9a5a2315901b3d5ef32e98feefe7e86

> Fix compiler warnings and dependencies.
> gs/base/gspaint.c
> gs/base/gxclthrd.c
> gs/base/lib.mak

2014-06-26 18:12:52 -0700
Michael Vrhel <michael.vrhel@artifex.com>
abcf61e770b8b4687c571f321c79e6a0bb0a7424

> Fix compiler warnings in ICC generation code.
> gs/base/gsicc_create.c

2014-06-26 16:26:44 -0600
Henry Stiles <henry.stiles@artifex.com>
417ffa428a427abd327ab7be48759d536b0689a6

> PCL no longer needs to maintain the hardware clipping state with the
> change to have the device maintain the printable region (HWMargins).
> See last commit.
> pcl/pcpage.c
> pcl/pcxfmst.h
> pcl/pgdraw.c

2014-06-26 18:22:22 +0100
Chris Liddell <chris.liddell@artifex.com>
5470aa39ebcfff65fb00e163f781c5769f4f9c18

> Bug 695334: fix seg fault with CIDFont substitution.
> When deciding whether to share the subst_CID_on_WMode table between CIDFont
> objects, make sure the two fonts are allocated in the same VM mode. If they
> differ, do not share the table.
> No cluster differences.
> gs/psi/zfcid1.c

2014-06-26 18:21:07 +0100
Chris Liddell <chris.liddell@artifex.com>
c73b4d533dc236427d57b3e8f9725f12d8d0aadd

> Add the SubstCID resources to the romfs.
> No cluster differences
> gs/psi/psromfs.mak

2014-06-24 05:46:32 -0700
Ray Johnston <ray.johnston@artifex.com>
02c486ce654faf99eac1dcd262651af5d32bae05

> Add pageneutralcolor as a printer device parameter to allow query.
> fillpage (erasepage from PS) will re-enable monitoring so we needn't
> ouptut the page in order to restart monitoring.
> This allows PostScript or clients to use get_params or get_param to
> read the pageneutralcolor state. Presumably this would be used prior
> to showpage. Coupled with the EndPage proc, PS can examine this even
> without emitting the pages.
> Note that this is only accurate when in clist mode, so -dMaxBitmap=0
> and -dGrayDetection=true should both be used.
> gs/base/gdevprn.c
> gs/base/gspaint.c
> gs/doc/Language.htm

2014-06-26 07:59:12 -0600
Henry Stiles <henry.stiles@artifex.com>
f3f29cf2f2ad9ab30c0a10f0634ec4d2d06d906c

> Default PCL to full bleed, setting the printable region margins to 0.
> Actually this change was partially implemented previously, but there
> were still lingering parts of the code that used the 1/6" border to
> affect the output. Older HP printers default to a 1/6" inch printable
> region. This can be implemented by changing the default HWMargins in
> the device or by setting them with the command line option -H, see the
> PCL documentation for details.
> pcl/pcpage.c

2014-06-25 20:23:17 -0700
Michael Vrhel <michael.vrhel@artifex.com>
b13d19749b58b2b0263013ad9a516c36e56cdb1c

> Fix wrong pointer type passing to gsicc_create_compute_cam
> No differences expected since the pointer type mix up happened to
> be both float types
> gs/base/gsicc_create.c

2014-06-25 14:59:54 -0700
Michael Vrhel <michael.vrhel@artifex.com>
d6be178195f97d7fa1cd2ae010e5d9e89f911e1a

> Apply cat02 chromatic adaptation to primaries when creating ICC profile from CalRGB
> While I had pickled the CAM into the transform created using the lutAtoB type, I
> failed to apply the transform for the matrix based solution that is used for the
> profile when created from CalRGB. I did have a comment in the code that this needed
> to be done.
> Several progressions occur.
> gs/base/gsicc_create.c

2014-06-25 08:54:43 -0600
Henry Stiles <henry.stiles@artifex.com>
759230353994354ae7417cdab1bbb09924dea70f

> Add an option to set hardware margins.
> There was no way to specify Ghostscript .HWMargins on the command line
> because the PCL option parser cannot parse most composite objects. So
> we add a '-H' option to be followed by 4 numbers: left, bottom, right
> and top margin.
> doc/ghostpdl.pdf
> doc/ghostpdl.tex
> doc/ghostpdl.txt
> pl/plmain.c

2014-06-24 12:33:48 +0100
Chris Liddell <chris.liddell@artifex.com>
f293a2fd1bfed25a69d64472967417d7d40d08ff

> Fix memory leak in libjpeg custom memory management
> Noticed working on another issue: the cleanup function was missing for the
> custom libjpeg memory management code.
> No cluster differences.
> gs/base/sjpeg.h
> gs/base/sjpegc.c

2014-06-19 17:23:26 +0100
Chris Liddell <chris.liddell@artifex.com>
0fc3bea788f6b65062432ff4bc6eace3cc713e63

> Various ICC profile related memory leak fixes
> Raised by cust 532.
> Add several "finalize" methods so ICC profiles (not in garbage collected memory)
> get freed or ref count decremented appropriately when the referencing object
> *is* garbage collected.
> Also, there were some mismatched ref count increments.
> No cluster differences.
> gs/base/gdevp14.c
> gs/base/gscms.h
> gs/base/gsicc_cache.c
> gs/base/gsicc_lcms.c
> gs/base/gsicc_lcms2.c
> gs/base/gsicc_manage.c
> gs/base/gsicc_nocm.c
> gs/base/gsstate.c
> gs/base/gstrans.c
> gs/base/gxclist.c
> gs/base/gxclist.h

2014-06-24 13:26:58 +0100
Ken Sharp <ken.sharp@artifex.com>
d936f19a3342a8da88b32a1559087b3a38c66832

> pdfwrite - more changes to better handle sRGB ColorConversionStrategy
> Following on from commit d704ab3d30b6119c8169d8827226f7325e5ee87f an
> additional 3 cases where I believe we need to handle sRGB as per RGB.
> These changes are committed separately as they were found by code inspection
> and I don't have a test case for them.
> No differences expected
> gs/devices/vector/gdevpdfg.c
> gs/devices/vector/gdevpdfi.c

2014-06-24 12:51:16 +0100
Ken Sharp <ken.sharp@artifex.com>
d704ab3d30b6119c8169d8827226f7325e5ee87f

> pdfwrite colour conversion - handle alternate conversion to sRGB from DeviceN
> Bug #695316 "A DeviceN image in pdf can't be converted to RGB image, it is converted to many paths instead"
> Bug #695306 "Converting a PDF to RGB colorspace causes missing drawing parts"
> The code for converting a DeviceN alternate space and tint transform wasn't
> catering for a ColorConversionStrategy of /sRGB. This commit ads the
> ccs_sRGB case, and converts it to RGB as per the documentation, using the
> selected RGB profile.
> Bug 695316 now converts the image to an image, though it produces an error
> on exit relating to ICC profiles.
> Bug 695306, for me, caused a seg fault, which this commit corrects. I do not
> see any missing content with either sRGB or RGB conversion. I do see the
> same error as for Bug #695316 and I'll continue working on that problem
> under that bug number
> No differences expected, the c;luster doesn't test colour conversion
> gs/devices/vector/gdevpdfg.c

2014-06-21 09:22:10 +0100
Ken Sharp <ken.sharp@artifex.com>
699e5a8478c2acbe34add1a9b2bd809779001e3f

> pdfwrite - preserve enumerator text for composite data
> Bug #695322 "Distilling PS to PDF using GS causes strange characters for spaces when using a particular sequence in the PS"
> The problem occurs because when processing text in a composite font pdfwrite
> overwrites the string data while working on it. In general this is not actually
> a problem, as the string data argument to the show family of operators is
> normally not reused.
> However, in this case the customer's PostScript inserts space glyphs by calling
> a bound procedure, instead of simply calling show. The first execution works
> properly, but corrupts the string, the second execution uses the corrupted
> string as the data, and is unable to find a glyph in the font to match the
> corrupted data, which results in the /.notdef being used instead.
> The particular routine in question (scan_cmap_text) is one of the most
> convoluted and bloated routines in pdfwrite, and after some inspection it
> was obviously going to be very difficult to avoid overwriting the string
> data, it would run considerable risk of breaking the code in subtle ways,
> and would in any event mean copying the string data around, possibly mutliple
> times.
> Accordingly I've chose to make a new copy of the string data in
> process_cmap_text, which is the only parent of scan_cmap_text, and save/restore
> the string data round the call. This prevents the bound string being
> corrupted and fixes the problem.
> This also exhibits a progression in Bug691680.ps and I've noted in that
> thread that the remaining problem is fixed.
> gs/devices/vector/gdevpdtc.c

2014-06-20 17:53:49 -0700
Michael Vrhel <michael.vrhel@artifex.com>
2322d38f28a21cfaad42e66398bcc34077818beb

> Addition of code in gsicc_create.c to create V2 ICC profiles from V4 ICC profiles
> This is needed to support a version of PDF-X that requires V2 ICC profiles.
> gs/base/gscms.h
> gs/base/gsicc_cms.h
> gs/base/gsicc_create.c
> gs/base/gsicc_create.h
> gs/base/gsicc_lcms2.c
> gs/base/gsicc_manage.c
> gs/base/gsicc_manage.h

2014-06-19 13:43:37 +0100
Ken Sharp <ken.sharp@artifex.com>
d6a29d5618f95cbbd299a5d5d02ec820ae8d7ced

> Check for trivially clipped out images before checking trivially non-clipped
> Bug #695320 "Difference in bbox result from 9.06 onwards"
> commit a13600f1c241c3e36dbe4973e9d78a8934b16004 introduced checks to see
> if we actually needed a clip device before going ahead and installing it.
> However, the order of checks was slightly incorrect. The code clamps the
> rectangle to be tested to the outer box of the clip path, then checked to
> see if the rectangle was completely included in the inner box.
> If the object was completely clipped out then the rectangle would be clamped
> to the outer box of the clip. If the outer and inner boxes were the same
> (rectangular clip) then the test could decide that the totally clipped out
> rectangle was in fact completely enclosed in the inner box.
> We fix this here by checking to see if the image is clipped out (by testing
> to see if the top/bottom or left/right edges are co-incident) before we
> check for trivial inclusion.
> For totally clipped out objects we then abort the object which, like the
> original fix prevents us installing a clip device and also prevents us
> going through the trapezoid degeneration., Potentially a small performance
> win, as well as getting the bbox correct.
> No differences expected
> gs/base/gxclip.c

2014-06-16 07:06:09 -0700
Ray Johnston <ray.johnston@artifex.com>
8269dd2b5f6d5aea4a5c1a6374dd7f6e6b7202f5

> Fix parameters to tile_by_steps that improves performance on J10
> Found while investigating performance for cust 532, one of the calls
> to tile_by_steps in gx_trans_pattern_fill_rect passed the rect upper
> right rather than the width and height. This improved the time spent
> in tile_by_steps from 8 sec to 4 sec on the JEITA J10 page.
> gs/base/gxp1fill.c

2014-05-30 07:40:56 -0700
Ray Johnston <ray.johnston@artifex.com>
9b6c504d49663d737dffbd42aace7891c3fb15dd

> Fix Knockout true, Isolated false blending with pdf transparency. fts_25_2524
> This was reported by customer 532. Knockout blending was seriously broken in
> not using the background correctly when not isolated, and knockout blending
> in art_pdf_composite_knockout_simple_8 did not handle blend modes other than
> normal. Also pdf14_compose_group was basing decisions on tos_isolated when
> nos_isolated was needed, and a special check for tos_knockout when the nos
> is the page level was not needed.
> gs/base/gdevp14.c
> gs/base/gxblend.c
> gs/base/gxblend.h
> gs/base/gxblend1.c

2014-06-12 15:44:47 +0100
Ken Sharp <ken.sharp@artifex.com>
77f9aa46adf05063752c9afdcd6cff92b332cb66

> txtwrite - fix a couple of compiler warnings
> gs/devices/vector/gdevpdfm.c

2014-05-27 14:50:25 +0100
Chris Liddell <chris.liddell@artifex.com>
b8a9352dac5e388de3c596371143040722fa2285

> Bug 695258: optimize AGL name mapping.
> Add a "reverse AGL" dictionary which allows us to create the extra name mappings
> with one pass over the CharStrings dictionary, rather than two passes over the
> entire AGL dictionary.
> No cluster differences.
> gs/Resource/Init/gs_agl.ps
> gs/Resource/Init/gs_ttf.ps
> gs/Resource/Init/gs_type1.ps
> gs/psi/int.mak

2014-06-12 08:46:53 +0100
Ken Sharp <ken.sharp@artifex.com>
1413e11d39ea015f1568a7ed7f00f99e16534259

> pdfwrite - more improvements on GoToR and link processing
> Still Bug #695269
> This time we take account of possible FirstPage and LastPage settings and
> *don't* apply them to GoToR actions.
> No differences expected.
> gs/devices/vector/gdevpdfm.c

2014-06-11 13:38:56 -0600
Henry Stiles <henry.stiles@artifex.com>
759c5f4aca61fe8914eaec8d86e0a64850034430

> Deterministic seeding for random number generator so the file can be
> regression tested.
> gs/examples/snowflak.ps

2014-06-10 17:39:23 +0100
Chris Liddell <chris.liddell@artifex.com>
e4a278eccdfd1f7b45daee3b77f9776fcd11e686

> Up the required version of autoconf to 2.60
> Due to our (long term!) use of the AC_PROG_SED macro, we need autoconf
> 2.60 (the macro was actually added to the 2.59b release, but 2.60 is close
> enough).
> No cluster differences
> gs/configure.ac

2014-06-10 15:28:28 +0100
Ken Sharp <ken.sharp@artifex.com>
cb32f7a923fbe661d5b959e8c7a24c147de7f782

> pdfwrite - don't include 'GoToR' references in check of destinations
> Bug #695269 " PDF file containing outline or link annotation with GoToR action processing ended with a message "ERROR: A pdfmark destination page XXX points beyond the last page YYYY.""
> The problem is that the function which gets a numeric page number, either by
> finding the /Next or /Prev keys or by finding an absolute page number, was
> also updating the 'max_referred_page' variable. This is checked when closing
> the PDF file and an error message emitted if it exceeds the number of pages
> in the PDF file.
> Of course, for a GoToR action, its valid for the destination (which is in a
> different file after all) to be greater than the number of pages in the current
> file.
> This commit removes the update for the max_referred_page variable from
> pdfmark_page_number, and places it in the calling function. This makes more
> sense to me, its not reasonable that s utility function should have an
> unexpected side effect like that, and it makes more sense for the function
> which handles the destination to decide whether it should update this variable.
> No differences expected, we don't test this on the cluster.
> gs/devices/vector/gdevpdfm.c

2014-06-10 13:31:07 +0100
Ken Sharp <ken.sharp@artifex.com>
baecaed381a6799e71c451933c3a1707f5653782

> pdfwrite - improved handling of images with > 8 BPC
> Bug #691713 "/rangecheck in fts_18_1805.pdf on pdfwrite device"
> Bug #694731 "pdfwrite doesn't handle 16 bpc images"
> To date images with more than 8 bits per component, using any transparency
> features, resulted in a rangecheck error as the code was incapable of
> handling 12 or 16 bpc.
> The new image code (improved for colour management) now allows us to apply
> a simple 16->8 (discarding the lower 8 bits) subsampler and this results
> in all the files which caused problems working correctly.
> In addition, many files which previously 'fell back' to the default implementation
> (where each image sample is transformed into a filled rectangle) now preserve
> the image as an image. This makes the resulting PDF or PostScript file
> considerably smaller and quicker to process.
> Note that this *only* works if the ColorConversionStrategy is 'LeaveColorUnchanged'
> This is because the existing image colour space conversion code cannot cope
> with anything other than 8-bit input.
> A number of test files show differences.
> The majority are PDF files which previously had content missing but now
> render correctly.
> A number are due to the fact that the image is no longer degenerated into
> thousands of rectangles which means that it is recompressed, if the input
> was JPEG and the compression is also JPEG this results in visible artefacts.
> Some files show differences due to the fact that the naive downsampling
> gives slightly different results from the accurate colour conversion. These
> show slight improvements in about as many cases as they show slight degradation
> gs/devices/vector/gdevpdfi.c

2014-06-09 08:23:09 +0100
Ken Sharp <ken.sharp@artifex.com>
5cc8aa8af871ab95ddebc2fc15baaf261bd8bb89

> PDF interpreter - remove some commented out code
> Commit 33fb85045c2590ac58a723ea2abcfbde505e53d1 included some code which was
> commented out but should have been removed.
> gs/Resource/Init/pdf_draw.ps

2014-06-07 11:46:00 +0100
Ken Sharp <ken.sharp@artifex.com>
33fb85045c2590ac58a723ea2abcfbde505e53d1

> PDF interpreter - improve synthesis of text form fields with no /AP
> Bug #694738 " Text synthesis of missing appearances in the PDF interpreter does not handle UTF16BE"
> Previously we didn't strip the 0xFE 0xFF byte order mark from UTF16-BE strings
> this commit removes them. We also remove the requirement for a /DA (Default
> Appearance) to be present in a Text field before we synthesise a replacement
> for a missing AP, taking int account any UTF16 strings.
> This does not 'fix' bug #694738 but this is because the /DA uses a font which
> is not correctly encoded to draw UTF16 text. The font uses an /Identity-H
> CMap which is unlikely to work with UTF16. Replacing it with our own fallback
> CID font and using a /Identity-UTF16-H CMap draws the text correctly, which
> shows that the problem is the font. NB Acrobat (as usual) ignores appearances
> and creates its own representation, so the Acrobat display is not an indication
> of a bug in GS.
> A few files in the test suite show differences because we no longer attempt
> to print the BOM.
> gs/Resource/Init/pdf_draw.ps
> gs/Resource/Init/pdf_ops.ps

2014-06-06 17:06:32 +0100
Chris Liddell <chris.liddell@artifex.com>
b5e0be23db6988057a0007cec24b592180ec25ff

> Handle the Identity-UTF16-H CMap "properly"
> For "normal" identity CMaps we skip a step in decoding the CID to the GID, but
> this should not be done for the Identity-UTF16-H CMap.
> Relates to (but does not resolve) Bug 694738.
> No cluster differences.
> gs/psi/zfapi.c

2014-06-05 16:37:36 +0100
Chris Liddell <chris.liddell@artifex.com>
235b2db4ab9cfd5b82bb45fb941bec04d41a00c8

> Tweaks for cups 1.7.3 to build on Windows and OS X
> No cluster differences
> gs/cups/libs/cups/cups.h
> gs/cups/libs/cups/debug.c
> gs/cups/libs/cups/globals.c
> gs/cups/libs/cups/ipp.c
> gs/cups/libs/cups/language.c
> gs/cups/libs/cups/usersys.c
> gs/psi/msvc.mak

2014-06-05 15:36:03 +0100
Chris Liddell <chris.liddell@artifex.com>
e9b8fbfed2c406ef7612f8c7b7e846f71a2d93d1

> Update libcups to 1.7.3
> gs/base/lcups.mak
> gs/base/lcupsi.mak
> gs/cups/libs/configlinux.h
> gs/cups/libs/configwin.h
> gs/cups/libs/cups/Dependencies
> gs/cups/libs/cups/Makefile
> gs/cups/libs/cups/adminutil.c
> gs/cups/libs/cups/adminutil.h
> gs/cups/libs/cups/api-array.header
> gs/cups/libs/cups/api-array.shtml
> gs/cups/libs/cups/api-cups.header
> gs/cups/libs/cups/api-cups.shtml
> gs/cups/libs/cups/api-filedir.header
> gs/cups/libs/cups/api-filedir.shtml
> gs/cups/libs/cups/api-filter.header
> gs/cups/libs/cups/api-filter.shtml
> gs/cups/libs/cups/api-httpipp.header
> gs/cups/libs/cups/api-httpipp.shtml
> gs/cups/libs/cups/api-overview.header
> gs/cups/libs/cups/api-overview.shtml
> gs/cups/libs/cups/api-ppd.header
> gs/cups/libs/cups/api-ppd.shtml
> gs/cups/libs/cups/array-private.h
> gs/cups/libs/cups/array.c
> gs/cups/libs/cups/array.h
> gs/cups/libs/cups/attr.c
> gs/cups/libs/cups/auth.c
> gs/cups/libs/cups/backchannel.c
> gs/cups/libs/cups/backend.c
> gs/cups/libs/cups/backend.h
> gs/cups/libs/cups/conflicts.c
> gs/cups/libs/cups/cups-private.h
> gs/cups/libs/cups/cups.h
> gs/cups/libs/cups/custom.c
> gs/cups/libs/cups/debug-private.h
> gs/cups/libs/cups/debug.c
> gs/cups/libs/cups/debug.h
> gs/cups/libs/cups/dest-job.c
> gs/cups/libs/cups/dest-localization.c
> gs/cups/libs/cups/dest-options.c
> gs/cups/libs/cups/dest.c
> gs/cups/libs/cups/dir.c
> gs/cups/libs/cups/dir.h
> gs/cups/libs/cups/emit.c
> gs/cups/libs/cups/encode.c
> gs/cups/libs/cups/file-private.h
> gs/cups/libs/cups/file.c
> gs/cups/libs/cups/file.h
> gs/cups/libs/cups/getdevices.c
> gs/cups/libs/cups/getifaddrs.c
> gs/cups/libs/cups/getputfile.c
> gs/cups/libs/cups/globals.c
> gs/cups/libs/cups/globals.h
> gs/cups/libs/cups/http-addr.c
> gs/cups/libs/cups/http-addrlist.c
> gs/cups/libs/cups/http-private.h
> gs/cups/libs/cups/http-support.c
> gs/cups/libs/cups/http.c
> gs/cups/libs/cups/http.h
> gs/cups/libs/cups/i18n.h
> gs/cups/libs/cups/ipp-private.h
> gs/cups/libs/cups/ipp-support.c
> gs/cups/libs/cups/ipp.c
> gs/cups/libs/cups/ipp.h
> gs/cups/libs/cups/langprintf.c
> gs/cups/libs/cups/language-private.h
> gs/cups/libs/cups/language.c
> gs/cups/libs/cups/language.h
> gs/cups/libs/cups/libcups2.def
> gs/cups/libs/cups/libcups2.rc
> gs/cups/libs/cups/libcups_s.exp
> gs/cups/libs/cups/localize.c
> gs/cups/libs/cups/mark.c
> gs/cups/libs/cups/md5-apple.h
> gs/cups/libs/cups/md5-private.h
> gs/cups/libs/cups/md5.c
> gs/cups/libs/cups/md5.h
> gs/cups/libs/cups/md5passwd.c
> gs/cups/libs/cups/notify.c
> gs/cups/libs/cups/options.c
> gs/cups/libs/cups/page.c
> gs/cups/libs/cups/ppd-cache.c
> gs/cups/libs/cups/ppd-private.h
> gs/cups/libs/cups/ppd.c
> gs/cups/libs/cups/ppd.h
> gs/cups/libs/cups/pwg-file.c
> gs/cups/libs/cups/pwg-media.c
> gs/cups/libs/cups/pwg-ppd.c
> gs/cups/libs/cups/pwg-private.h
> gs/cups/libs/cups/pwg.h
> gs/cups/libs/cups/raster-private.h
> gs/cups/libs/cups/raster.h
> gs/cups/libs/cups/request.c
> gs/cups/libs/cups/sidechannel.c
> gs/cups/libs/cups/sidechannel.h
> gs/cups/libs/cups/snmp-private.h
> gs/cups/libs/cups/snmp.c
> gs/cups/libs/cups/snprintf.c
> gs/cups/libs/cups/sspi-private.h
> gs/cups/libs/cups/sspi.c
> gs/cups/libs/cups/string-private.h
> gs/cups/libs/cups/string.c
> gs/cups/libs/cups/string.h
> gs/cups/libs/cups/tempfile.c
> gs/cups/libs/cups/test.ppd
> gs/cups/libs/cups/test2.ppd
> gs/cups/libs/cups/testadmin.c
> gs/cups/libs/cups/testarray.c
> gs/cups/libs/cups/testconflicts.c
> gs/cups/libs/cups/testcups.c
> gs/cups/libs/cups/testfile.c
> gs/cups/libs/cups/testhttp.c
> gs/cups/libs/cups/testi18n.c
> gs/cups/libs/cups/testipp.c
> gs/cups/libs/cups/testlang.c
> gs/cups/libs/cups/testoptions.c
> gs/cups/libs/cups/testppd.c
> gs/cups/libs/cups/testpwg.c
> gs/cups/libs/cups/testsnmp.c
> gs/cups/libs/cups/thread-private.h
> gs/cups/libs/cups/thread.c
> gs/cups/libs/cups/transcode.c
> gs/cups/libs/cups/transcode.h
> gs/cups/libs/cups/usersys.c
> gs/cups/libs/cups/utf8demo.txt
> gs/cups/libs/cups/util.c
> gs/cups/libs/cups/versioning.h
> gs/cups/libs/filter/Dependencies
> gs/cups/libs/filter/Makefile
> gs/cups/libs/filter/api-raster.header
> gs/cups/libs/filter/api-raster.shtml
> gs/cups/libs/filter/commandtops.c
> gs/cups/libs/filter/common.c
> gs/cups/libs/filter/common.h
> gs/cups/libs/filter/error.c
> gs/cups/libs/filter/gziptoany.c
> gs/cups/libs/filter/image-bmp.c
> gs/cups/libs/filter/image-colorspace.c
> gs/cups/libs/filter/image-gif.c
> gs/cups/libs/filter/image-jpeg.c
> gs/cups/libs/filter/image-photocd.c
> gs/cups/libs/filter/image-pix.c
> gs/cups/libs/filter/image-png.c
> gs/cups/libs/filter/image-pnm.c
> gs/cups/libs/filter/image-private.h
> gs/cups/libs/filter/image-sgi.c
> gs/cups/libs/filter/image-sgi.h
> gs/cups/libs/filter/image-sgilib.c
> gs/cups/libs/filter/image-sun.c
> gs/cups/libs/filter/image-tiff.c
> gs/cups/libs/filter/image-zoom.c
> gs/cups/libs/filter/image.c
> gs/cups/libs/filter/image.h
> gs/cups/libs/filter/interpret.c
> gs/cups/libs/filter/libcupsimage2.def
> gs/cups/libs/filter/libcupsimage_s.exp
> gs/cups/libs/filter/postscript-driver.header
> gs/cups/libs/filter/postscript-driver.shtml
> gs/cups/libs/filter/ppd-compiler.header
> gs/cups/libs/filter/ppd-compiler.shtml
> gs/cups/libs/filter/pstops.c
> gs/cups/libs/filter/raster-driver.header
> gs/cups/libs/filter/raster-driver.shtml
> gs/cups/libs/filter/raster.c
> gs/cups/libs/filter/rasterbench.c
> gs/cups/libs/filter/rastertoepson.c
> gs/cups/libs/filter/rastertohp.c
> gs/cups/libs/filter/rastertolabel.c
> gs/cups/libs/filter/rastertopwg.c
> gs/cups/libs/filter/spec-ppd.header
> gs/cups/libs/filter/spec-ppd.shtml
> gs/cups/libs/filter/testraster.c

2014-06-05 17:06:47 +0100
Chris Liddell <chris.liddell@artifex.com>
e2da8a39efbfbd96cb05964f3d90e33a507256ef

> Include pwgraster.dev with suitable cups revisions
> The pwgraster support arrived in cups 1.5, so only build in pwgraster device
> when linking with cups 1.5 and later.
> No cluster differences
> gs/configure.ac

2014-06-05 13:36:58 +0100
Ken Sharp <ken.sharp@artifex.com>
cd1ec1cfbc66568eeb6c2b4413a477568caeadf4

> PDF interpreter - ignore broken appearance dicts
> Bug #692181 " %%EOF marker"
> The bug title is very misleading, there were two problems;
> 1) Ghostscript didn't synthesise appearances fro FreeText annotations
> 2) The appearance dictionaries were invalid.
> Previous work added support for FreeText annotations, this commit adds some
> slight improvements to that, and in addition it does minimal validation on
> the AP (appearance) dictionary. If its invalid we don't bother to use it
> but synthesise an appearance anyway.
> gs/Resource/Init/pdf_draw.ps

2014-06-03 11:27:09 -0700
Chris Liddell <chris.liddell@artifex.com>
2deb460ef02e2802546e09979243764ede2d4173

> Bug 695274: validate CIDFont substitute records.
> In cidfmap records which substitute TTF fonts check whether we can access
> the TTF file, if we cannot, remove the record from the map.
> No cluster differences.
> gs/Resource/Init/gs_cidfm.ps

2014-06-03 11:18:13 -0700
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
cc5257faa69ed02333ac63bd1f3c5e360931407a

> Changed copyright date to 2014.
> gs/base/gscdef.c

2014-05-31 14:02:28 +0100
Chris Liddell <chris.liddell@artifex.com>
4994e176c4b8ff43ccc91dba807879d02d070d88

> Bug 695272: init PS arrays at alloc time
> Write null objects to PS arrays when they are allocated - prevents invalid
> reads/writes during garbage collection if we hit an error between allocation
> and the contents being written.
> No cluster differences.
> gs/psi/ialloc.c

2014-05-31 13:24:43 +0100
Chris Liddell <chris.liddell@artifex.com>
053fa67fa93fa7be26885422f3881b72ccc682a0

> Bug 695275: Add bounds check when retrieving TTF name
> When deciding whether a TTF font name is multi or single byte string,
> validate the Platform ID before trying to use it. If it is invalid
> attempt to continue as a single byte string.
> No cluster differences.
> gs/Resource/Init/gs_ttf.ps

2014-06-03 05:07:55 +0100
Ken Sharp <ken.sharp@artifex.com>
87b6bca6b9878ea28e460baac62f0abe974c5748

> txtwrite - fix BOM emission
> Bug #695292 "txtwrite device extracts unicode text from file like bigendian"
> The code was emitting the BOM in a way that meant it was always written as
> a big-endian BOM when in fsct it should have been the native endian-ness.
> No differences expected.
> gs/devices/vector/gdevtxtw.c

2014-06-02 17:24:16 -0700
Chris Liddell <chris.liddell@artifex.com>
dae5b12f2e9e4716d6d60874efd7bfee410d69c7

> Destroy gslite
> CLUSTER_UNTESTED
> doc/who_owns_what.txt
> gs/base/gxccman.c
> gs/base/gxfcache.h
> tools/gslite/README
> tools/gslite/gslite-api.rtf
> tools/gslite/gslt.def
> tools/gslite/gslt.h
> tools/gslite/gslt.mak
> tools/gslite/gslt_alloc.c
> tools/gslite/gslt_alloc.h
> tools/gslite/gslt_font.h
> tools/gslite/gslt_font_api.c
> tools/gslite/gslt_font_api.h
> tools/gslite/gslt_font_api_test.c
> tools/gslite/gslt_font_cache.c
> tools/gslite/gslt_font_cff.c
> tools/gslite/gslt_font_encoding.c
> tools/gslite/gslt_font_glyph.c
> tools/gslite/gslt_font_int.h
> tools/gslite/gslt_font_test.c
> tools/gslite/gslt_font_ttf.c
> tools/gslite/gslt_image.c
> tools/gslite/gslt_image.h
> tools/gslite/gslt_image_jpeg.c
> tools/gslite/gslt_image_png.c
> tools/gslite/gslt_image_test.c
> tools/gslite/gslt_image_threads_test.c
> tools/gslite/gslt_image_tiff.c
> tools/gslite/gslt_init.c
> tools/gslite/gslt_lib_gcc.mak
> tools/gslite/gslt_lib_msvc.mak
> tools/gslite/gslt_stubs.c
> tools/gslite/gslt_test.c
> tools/gslite/tiger.jpg

2014-06-02 17:07:28 -0700
Chris Liddell <chris.liddell@artifex.com>
ddcebb6600c102f0d7d8a396f0dafa67845df48b

> Remove "commercial only" comment from ETS docs
> CLUSTER_UNTESTED
> gs/toolbin/halftone/ETS/README.txt

2014-06-02 17:32:33 +0200
Till Kamppeter <till.kamppeter@gmail.com>
e054f1e08f8fdaa557f56cee5ff93f354db1f971

> "cups" output device: Do byte-swapping for correct Endian not only for EncodeLUT but also for DecodeLUT
> Robin Watts on bug bugs.ghostscript.com/show_bug.cgi?id=695264:
> ----------
> Generally, I think it's considered good form that encode_color and
> decode_color should be complementary operations :)
> devcups uses EncodeLUT to implement encode_color, and DecodeLUT to
> implement decode_color.
> In the case of little endian 16bit, it packs a endian reversal into
> EncodeLUT. It leaves DecodeLUT undiddled though.
> Diddling DecodeLUT in the equivalent manner seems (superficially at
> least) to solve the problem.
> ----------
> This makes all 16-bit color spaces give correct colors on rasterview.
> gs/cups/gdevcups.c

2014-05-29 15:33:12 +0100
Ken Sharp <ken.sharp@artifex.com>
95eea50e13987bd06d5634ec7f4dc381a76ee629

> PDF interpreter - add support for GoTo and GoToR in Link annotations of PDF files
> Bug #695268 "PDF file containing link annotation with GoToR action
> broken by GS processing, action is not passed"
> Patch supplied by Jacek Bator after the code for Outlines with GoTo and
> GoToR annotations.
> No differences expected.
> gs/Resource/Init/pdf_main.ps

2014-05-29 08:32:30 +0100
Ken Sharp <ken.sharp@artifex.com>
272d83387ff590244e3fb8719e8eef2e928f514d

> pdfwrite - fix GoTo processing for Outlines in PDF input files
> Bug #695267 "Incorrect PDF output for outlines and link annotations with GoTo action"
> commit 099657a962e716658f20658051c9692b439ecf2d incorrectly modified the
> GoTo action, it turns out that GoTo and GoToR really do have to be handled
> differently.
> No differences expected.
> gs/Resource/Init/pdf_main.ps

2014-05-28 20:43:35 +0100
Robin Watts <robin.watts@artifex.com>
73123c3caa6495e1b30d1ecd35602629d6a8c17e

> Bug 695116: Rewrite JPEG header height when required.
> This follows on from Kens previous commit and should fix the bug.
> When a PDF includes a JPEG it states the height to use for that
> JPEG. We now check the JPEG header to see if the height declared
> there is 0 or is greater than the PDF specified height. If so,
> we rewrite the header to contain the height specified in the PDF.
> Short of performing radical surgery on libjpeg to make it honour
> the DNL tag, this is the best we are going to be able to do.
> gs/base/sdctd.c

2014-05-28 18:52:26 +0100
Ken Sharp <ken.sharp@artifex.com>
ddaea8157085f4efb227e78326dd739d59493b97

> PDF interpreter - pass image height as a /DecodeParm to all filters
> Bug #695116 "**** Warning: File has insufficient data for an image"
> This is not a solution for this bug, merely framework to allow it to be fixed.
> The PDF file contains a DCT encoded stream for an image, where the header
> declares a height of '-1' and then later uses a DNL marker to set the actual
> number of rows of data in the image. This does not work with libjpeg (in
> fact it doesn't work with an number of JPEG consumers).
> However, because this is an image in a PDF file, we do have the image dimensiosn
> from the image dictionary, so we can use that instead, if only we had a way
> to pass the information into the stream decode filter.
> This commit modifies the dictionary we provide to the stream code in the PDF
> interpreter, we now insist that all the Filters in an image shall have a
> DecodeParms dictionary, if they don;t already have one we create them as
> required. In that dictionary we add a /Height key and put the Height retrieved
> from the image dictionary in it.
> All the decode operators handle being passed a dictionary with parameters,
> so all that is then necessary is to have the DCT decode filter check the
> parameter dictionary and store the Height from it in a new entry in the DCT
> stream state.
> The parameter is now available for use by the DCT decode filter, and a future
> commit will use it to fix the actual problem.
> No differences expected.
> gs/Resource/Init/pdf_draw.ps
> gs/base/sdcparam.c
> gs/base/sdct.h

2014-05-28 14:48:27 +0200
Till Kamppeter <till.kamppeter@gmail.com>
625b7570141287bf5ca7b61fc733f81b109b45d7

> "cups" output device: Fixed obvious copy-and-paste error in color conversion.
> gs/cups/gdevcups.c

2014-05-28 11:46:07 +0200
Till Kamppeter <till.kamppeter@gmail.com>
d5065760d06ba71646d08240b87a8de08104c4c5

> Fixed PWG Raster support in gdevcups.c to build with all CUPS library versions
> We determine now whether we have PWG Raster support by the proper
> macro of the CUPS library, not by whether the built-in or an external
> lib is used. So we can also build with older CUPS library versions as
> external library (bug 695243).
> gs/cups/gdevcups.c

2014-05-28 08:33:15 +0100
Ken Sharp <ken.sharp@artifex.com>
230e512962ab5d05f137fc6b3665f5dcae0aa4e9

> pdfwrite - test a return code to silence a compiler warning
> gs/devices/vector/gdevpdte.c

2014-05-27 14:09:50 +0100
Ken Sharp <ken.sharp@artifex.com>
64dd281abf84ba7383aa85c99599b5aebea3998a

> pdfwrite - improved handling of 'glyphshow' and similar operations
> Bug #695168 "Problem converting xps to pdf"
> Bug #695259 "both (incorrect) B/W and (correct) AA rendering of Libertine font in same PDF output"
> Although these are different products, one being Ghostscript and the other
> gxps, the underlying problem is similar. The PostScript makes extensive use
> of the glyphshow operator, which ends up as a TEXT_FROM_SINGLE_GLYPH operation
> in the graphics library, and the XPS interpreter always uses TEXT_FROM_GLYPHS.
> In both cases the font is effectively unencoded when pdfwrite seee it. Since
> we cannot construct and use an unencoded font in PDF we have no alternative
> but to create an encoding for the font, and write the text using that encoding.
> The way this is done we use the name table, which effectively means that the
> character code we use is derived from the first byte of the glyph name. For
> limited usage this works well, but more complex usage can result in problems.
> For example the glyphs /o and /omicron are both encoded at index 103.
> Previously this would cause us to fall back to rendering the font and embedding
> as a type 3 font, or in the worst case an inline image. This is because when
> encoding the text we would discover that an the font already had a glyph
> encoded at the correct index, and would simply pass on, not realising it was
> the incorrect glyph. Later we would check the actual glyph index against the glyph index
> of the glyph encoded at that position, realise they were different and throw an error.
> In this commit we check the glyph index early, at the point where we encode the text.
> If the font already has a glyph encoded at the given character code, we check
> the glyph index to see if it matches the current glyph. If it does all is well
> but if it doesn't we break out and create a new font instance, with the new
> glyph encoded in it.
> Potentially this could result in a *lot* of font subsets being created, which
> would increase the size of the output PDF file, but the quality improvement
> is well worth it.
> No differences expected.
> gs/devices/vector/gdevpdte.c

2014-05-26 12:43:54 +0100
Ken Sharp <ken.sharp@artifex.com>
099657a962e716658f20658051c9692b439ecf2d

> pdfwrite - fix GoTo and GoToR actions when passed through from PDF input
> Bug #695232 "Broken PDF file when input file containes bookmarks with GoToR action"
> When adding the GoToR functionality I copied the code from the GoTo action
> sadly it seems the GoTo was already incorrect.
> This commit should fix both, though I don't have a test for the GoTo action.
> No differences expected.
> gs/Resource/Init/pdf_main.ps

2014-05-24 09:04:53 +0100
Ken Sharp <ken.sharp@artifex.com>
5e868fffeaa21ebb0f7b30a4a9c29272d850b18a

> pdfwrite - prototype a function to silence compiler warnings
> gs/devices/vector/gdevpdfx.h

2014-05-23 13:59:30 +0100
Ken Sharp <ken.sharp@artifex.com>
cb5c738d04a028a88633f3f98d955f4218b05654

> pdfwrite - better handling of input PDF files with broken fonts
> Bug #695216 "Spurious errors and bad PDF written from input file comparefles/Bug693711.pdf"
> The errors are not spurious, and are caused by the missing/damaged fonts in
> the input file.
> This commit chooses to ignore these errors, but I may rethink that if it causes
> future problems, the fact that there are no errors when rendering does not
> mean that there should be no errors when creating a PDF file.
> Because the PDF interpreter ignores errors and continues regardles we were
> then attempting to write an invalid font, which failed, resulting in an
> (unused) entry in the xref with a duplicate offset of an earlier entry. This
> commit further refines the broken font handling by detecting the fact that
> the font was incorrectly written and elides it from the xref table.
> This addresses both of the concerns raised in the bug report, though I would
> point out that ignoring errors when the output device is pdfwrite is always
> very likely to produce broken PDF files.
> This does alter the font substitution for Bug693711.pdf on Linux.
> gs/devices/vector/gdevpdfu.c
> gs/devices/vector/gdevpdtb.c
> gs/devices/vector/gdevpdtt.c

2014-05-22 18:33:34 +0100
Chris Liddell <chris.liddell@artifex.com>
93a23603b23160943b42c2f1e357fb75cc0a396b

> Add an extra compiler flag for OpenJPEG 2.1.0
> 2.1.0 requires an extra compiler flag "USE_JPIP" that I had forgotten to add
> to the Windows build
> CLUSTER_UNTESTED
> gs/psi/msvc.mak

2014-05-21 15:30:35 +0100
Chris Liddell <chris.liddell@artifex.com>
0d2bc37f7e4096fe31d6ebc6679d79935f52ba0c

> Update OpenJPEG to 2.1.0
> No cluster differences.
> Revise configure script with extra flags for OPJ
> Copy in new openjpeg (2.1.0) complete
> Zap the openjpeg stuff we don't need
> Add predefined openjpeg headers.
> These are *nearly* empty of actual definitions, as we generate the settings
> from the gs configure script.
> Revised makefiles and configure script for new openjpeg
> Tweak for updated openjpeg API
> Import patches OpenJPEG from Sumatra's tree:
> Reference:
> https://code.google.com/p/sumatrapdf/source/browse/trunk/ext/_patches/openjpeg.patch?r=8887
> gs/base/gs.mak
> gs/base/openjpeg.mak
> gs/base/sjpx_openjpeg.c
> gs/configure.ac
> gs/openjpeg/AUTHORS
> gs/openjpeg/CHANGES
> gs/openjpeg/LICENSE
> gs/openjpeg/NEWS
> gs/openjpeg/THANKS
> gs/openjpeg/libopenjpeg/CMakeLists.txt
> gs/openjpeg/libopenjpeg/Makefile.am
> gs/openjpeg/libopenjpeg/Makefile.in
> gs/openjpeg/libopenjpeg/bio.c
> gs/openjpeg/libopenjpeg/bio.h
> gs/openjpeg/libopenjpeg/cidx_manager.c
> gs/openjpeg/libopenjpeg/cidx_manager.h
> gs/openjpeg/libopenjpeg/cio.c
> gs/openjpeg/libopenjpeg/cio.h
> gs/openjpeg/libopenjpeg/dwt.c
> gs/openjpeg/libopenjpeg/dwt.h
> gs/openjpeg/libopenjpeg/event.c
> gs/openjpeg/libopenjpeg/event.h
> gs/openjpeg/libopenjpeg/fix.h
> gs/openjpeg/libopenjpeg/function_list.c
> gs/openjpeg/libopenjpeg/function_list.h
> gs/openjpeg/libopenjpeg/image.c
> gs/openjpeg/libopenjpeg/image.h
> gs/openjpeg/libopenjpeg/indexbox_manager.h
> gs/openjpeg/libopenjpeg/int.h
> gs/openjpeg/libopenjpeg/invert.c
> gs/openjpeg/libopenjpeg/invert.h
> gs/openjpeg/libopenjpeg/j2k.c
> gs/openjpeg/libopenjpeg/j2k.h
> gs/openjpeg/libopenjpeg/j2k_lib.c
> gs/openjpeg/libopenjpeg/j2k_lib.h
> gs/openjpeg/libopenjpeg/jp2.c
> gs/openjpeg/libopenjpeg/jp2.h
> gs/openjpeg/libopenjpeg/jpt.c
> gs/openjpeg/libopenjpeg/jpt.h
> gs/openjpeg/libopenjpeg/mct.c
> gs/openjpeg/libopenjpeg/mct.h
> gs/openjpeg/libopenjpeg/mqc.c
> gs/openjpeg/libopenjpeg/mqc.h
> gs/openjpeg/libopenjpeg/openjpeg.c
> gs/openjpeg/libopenjpeg/openjpeg.h
> gs/openjpeg/libopenjpeg/opj_clock.c
> gs/openjpeg/libopenjpeg/opj_clock.h
> gs/openjpeg/libopenjpeg/opj_config.h
> gs/openjpeg/libopenjpeg/opj_config_private.h
> gs/openjpeg/libopenjpeg/opj_includes.h
> gs/openjpeg/libopenjpeg/opj_intmath.h
> gs/openjpeg/libopenjpeg/opj_inttypes.h
> gs/openjpeg/libopenjpeg/opj_malloc.h
> gs/openjpeg/libopenjpeg/opj_stdint.h
> gs/openjpeg/libopenjpeg/phix_manager.c
> gs/openjpeg/libopenjpeg/pi.c
> gs/openjpeg/libopenjpeg/pi.h
> gs/openjpeg/libopenjpeg/ppix_manager.c
> gs/openjpeg/libopenjpeg/raw.c
> gs/openjpeg/libopenjpeg/raw.h
> gs/openjpeg/libopenjpeg/t1.c
> gs/openjpeg/libopenjpeg/t1.h
> gs/openjpeg/libopenjpeg/t1_generate_luts.c
> gs/openjpeg/libopenjpeg/t1_luts.h
> gs/openjpeg/libopenjpeg/t2.c
> gs/openjpeg/libopenjpeg/t2.h
> gs/openjpeg/libopenjpeg/tcd.c
> gs/openjpeg/libopenjpeg/tcd.h
> gs/openjpeg/libopenjpeg/tgt.c
> gs/openjpeg/libopenjpeg/tgt.h
> gs/openjpeg/libopenjpeg/thix_manager.c
> gs/openjpeg/libopenjpeg/tpix_manager.c
> gs/openjpeg/opj_config.h.in.user
> gs/openjpeg/src/lib/openjp2/CMakeLists.txt
> gs/openjpeg/src/lib/openjp2/bio.c
> gs/openjpeg/src/lib/openjp2/bio.h
> gs/openjpeg/src/lib/openjp2/cidx_manager.c
> gs/openjpeg/src/lib/openjp2/cidx_manager.h
> gs/openjpeg/src/lib/openjp2/cio.c
> gs/openjpeg/src/lib/openjp2/cio.h
> gs/openjpeg/src/lib/openjp2/dwt.c
> gs/openjpeg/src/lib/openjp2/dwt.h
> gs/openjpeg/src/lib/openjp2/event.c
> gs/openjpeg/src/lib/openjp2/event.h
> gs/openjpeg/src/lib/openjp2/function_list.c
> gs/openjpeg/src/lib/openjp2/function_list.h
> gs/openjpeg/src/lib/openjp2/image.c
> gs/openjpeg/src/lib/openjp2/image.h
> gs/openjpeg/src/lib/openjp2/indexbox_manager.h
> gs/openjpeg/src/lib/openjp2/invert.c
> gs/openjpeg/src/lib/openjp2/invert.h
> gs/openjpeg/src/lib/openjp2/j2k.c
> gs/openjpeg/src/lib/openjp2/j2k.h
> gs/openjpeg/src/lib/openjp2/jp2.c
> gs/openjpeg/src/lib/openjp2/jp2.h
> gs/openjpeg/src/lib/openjp2/libopenjp2.pc.cmake.in
> gs/openjpeg/src/lib/openjp2/mct.c
> gs/openjpeg/src/lib/openjp2/mct.h
> gs/openjpeg/src/lib/openjp2/mqc.c
> gs/openjpeg/src/lib/openjp2/mqc.h
> gs/openjpeg/src/lib/openjp2/openjpeg.c
> gs/openjpeg/src/lib/openjp2/openjpeg.h
> gs/openjpeg/src/lib/openjp2/opj_clock.c
> gs/openjpeg/src/lib/openjp2/opj_clock.h
> gs/openjpeg/src/lib/openjp2/opj_codec.h
> gs/openjpeg/src/lib/openjp2/opj_config.h
> gs/openjpeg/src/lib/openjp2/opj_config.h.cmake.in
> gs/openjpeg/src/lib/openjp2/opj_config_private.h
> gs/openjpeg/src/lib/openjp2/opj_config_private.h.cmake.in
> gs/openjpeg/src/lib/openjp2/opj_includes.h
> gs/openjpeg/src/lib/openjp2/opj_intmath.h
> gs/openjpeg/src/lib/openjp2/opj_inttypes.h
> gs/openjpeg/src/lib/openjp2/opj_malloc.h
> gs/openjpeg/src/lib/openjp2/opj_stdint.h
> gs/openjpeg/src/lib/openjp2/phix_manager.c
> gs/openjpeg/src/lib/openjp2/pi.c
> gs/openjpeg/src/lib/openjp2/pi.h
> gs/openjpeg/src/lib/openjp2/ppix_manager.c
> gs/openjpeg/src/lib/openjp2/raw.c
> gs/openjpeg/src/lib/openjp2/raw.h
> gs/openjpeg/src/lib/openjp2/t1.c
> gs/openjpeg/src/lib/openjp2/t1.h
> gs/openjpeg/src/lib/openjp2/t1_generate_luts.c
> gs/openjpeg/src/lib/openjp2/t1_luts.h
> gs/openjpeg/src/lib/openjp2/t2.c
> gs/openjpeg/src/lib/openjp2/t2.h
> gs/openjpeg/src/lib/openjp2/tcd.c
> gs/openjpeg/src/lib/openjp2/tcd.h
> gs/openjpeg/src/lib/openjp2/tgt.c
> gs/openjpeg/src/lib/openjp2/tgt.h
> gs/openjpeg/src/lib/openjp2/thix_manager.c
> gs/openjpeg/src/lib/openjp2/tpix_manager.c

2014-05-20 11:47:21 -0700
Ray Johnston <ray.johnston@artifex.com>
21565d4ad3c3eed360d3a56c372663d1ba876c0d

> Fix for fts_09_0920 SMask in ExGState ignored for text.
> When the SMask is set in the ExtGState rather than in a Group Form,
> we need to push a transparency group before painting the text (after
> the setfillstate) and pop it afterwards, similarly to what we do
> for fills and strokes.
> gs/Resource/Init/pdf_ops.ps

2014-05-21 15:30:35 +0100
Chris Liddell <chris.liddell@artifex.com>
f032367796457690caa484b1a50aa1f97b80322a

> Ensure memory allocator is available for jpeg encoding
> No cluster differences.
> gs/devices/gdevjpeg.c

2014-05-21 13:15:09 +0100
Ken Sharp <ken.sharp@artifex.com>
cc26212b8b4a756d6da891c946b53c52641befd3

> pdfwrite - add an idiom for certain patterns produced by the MS driver
> Bug #695230 "Invalid pattern fill rendering"
> The Windows PostScript driver produces some patterns (for background fills)
> which vary the size of the pattern cell according to the device resolution.
> This means that as the resolution goes up, more pattern cells are drawn,
> resulting in a finer and finer pattern.
> This resolution neatly defeats our high level pattern capture in pdfwrite.
> It only works properly if the device is running at 72 dpi, and the example
> runs at 600.
> It seems the easiest way to deal with this is to create an idiom which will
> replace the resolution-varying pattern with a fixed pattern (it isn't possible
> to have a resolution-dependent pattern in PDF anyway) and this commit adds
> such an idiom.
> It also updates the idioms to use the new .spec_op operator to interrogate
> device parameters rather than the slow getdeviceparams previously used.
> No differences expected.
> gs/Resource/IdiomSet/Pscript5Idiom

2014-05-19 15:53:05 +0100
Chris Liddell <chris.liddell@artifex.com>
1b06d7888faf61bef37fc17b10a1745d889f4c75

> Remove jmorecfg.h from includes....
> in jmemcust.c
> No cluster differences.
> gs/base/jmemcust.c

2014-05-09 12:22:08 +0100
Chris Liddell <chris.liddell@artifex.com>
cb50ac70a8e8874a265da59baca7e95790e79af1

> Add an app independent custom memory manager for libjpeg
> gs/base/jmemcust.c
> gs/base/jmemcust.h
> gs/base/jpeg.mak
> gs/base/sjpeg.h
> gs/base/sjpegc.c
> gs/base/sjpegd.c
> gs/base/sjpege.c

2014-05-16 21:01:33 -0700
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
0145175ab9d530a4ed2c79dc6290235b30e980cc

> Temporarily disable code introduced in 6fefd767005a8e5e8da0cbb954d0d47fc45fc37b.
> For more details see Bug 695243.
> gs/cups/gdevcups.c

2014-05-15 19:54:04 +0200
Till Kamppeter <till.kamppeter@gmail.com>
6fefd767005a8e5e8da0cbb954d0d47fc45fc37b

> CUPS Raster output device: Fix cupsRasterOpen() call to get correct PWG Raster output
> The CUPS Raster output device generated incorrect PWG Raster output
> because it called cupsRasterOpen() without the required
> CUPS_RASTER_WRITE_PWG mode setting. Due to the output never being
> tested with an IPP Everywhere printer but only with software which
> also accepts CUPS Raster, the bug did not get discovered until testing
> the output against the mime type recognition of CUPS where it failed.
> Note that this patch only fixes the problem if a shared libcupsimage
> library of the system is used, not with the library included with
> Ghostscript. This is because the included library is too old to
> contain PWG Raster output support. If the included CUPS libraries have
> to be used, the CUPS Raster output device is built as before to assure
> that Ghostscript builds and CUPS Raster can still get generated.
> gs/Makefile.in
> gs/cups/gdevcups.c
> gs/devices/devs.mak

2014-05-15 08:51:43 +0100
Chris Liddell <chris.liddell@artifex.com>
4836ecb5c5a03eb7217937b8503b20068e9bf846

> Bug 695227: fix crash in bbox device
> Don't try to assign the "imaging_dev" entry in the text enumerator if the
> enumerator initialisation doesn't complete.
> Slightly modified version of the patch supplied by
> Antti Husa <a.husa@hushmail.com>
> No cluster differences.
> gs/base/gdevbbox.c

2014-05-12 11:13:07 +0100
Chris Liddell <chris.liddell@artifex.com>
a7434eca8268e31fdfc4b47740a7e7695b189bc0

> Words about static linking the executable.
> Mention the need to explicitly link libraries when building a static gs exe.
> CLUSTER_UNTESTED
> gs/doc/Make.htm

2014-05-12 10:53:12 +0100
Chris Liddell <chris.liddell@artifex.com>
3c4cfba8a74fd3255231fb381b55998753174849

> Pass SHARE_LCMS as a compiler flag.
> As pointed out by Albert Astals Cid <aacid@kde.org> although the code had been
> changed to use the system malloc/free calls when sharing LCMS2, the flag
> (SHARE_LCMS==1) I had forgotten to add it to the compiler parameters.
> I've opted to add SHARE_LCMS to the compiler flags for LCMS, and include them
> when compiler our interface files - this seems less likely to throw up a
> similar oversight in the future.
> No regression differences.
> gs/Makefile.in
> gs/base/lib.mak

2014-05-09 07:32:54 -0700
Ray Johnston <ray.johnston@artifex.com>
7df04bbe3a7126dc702cb09369ba29fd142bfa62

> Only include trace devices (tr_mono, tr_rgb, tr_cmyk) in DEBUG builds on MSVC
> gs/psi/msvc.mak

2014-05-09 07:22:08 -0700
Ray Johnston <ray.johnston@artifex.com>
db885d6e72fce5140a56abc8d4f49b0a3658aad7

> Add tracedev (tr_mono, tr_rgb, tr_cmyk) to default MSVC build.
> gs/psi/msvc.mak

2014-05-09 00:41:44 +0100
Robin Watts <robin.watts@artifex.com>
cc278761f766f7dbbba051af13b1ea0fdc7cdb08

> Further tweak to ETS; mention patents, and add image viewer
> Mention the patents in the comments of the code.
> Add the image viewer back, as for people without Photoshop it can
> be hard to visualise the output.
> gs/toolbin/halftone/ETS/ets.c
> gs/toolbin/halftone/ETS/ipview.html

2014-05-08 13:19:09 -0700
Michael Vrhel <michael.vrhel@artifex.com>
c203e3342db1933e610433de6915fcb66a8e593f

> Removed files that were no longer used (SSE and VEC files and Build files). Updated README.txt
> gs/toolbin/halftone/ETS/COPYING.txt
> gs/toolbin/halftone/ETS/Makefile_avec
> gs/toolbin/halftone/ETS/Makefile_sse2
> gs/toolbin/halftone/ETS/README.txt
> gs/toolbin/halftone/ETS/_eb_sse2.s
> gs/toolbin/halftone/ETS/build.bat
> gs/toolbin/halftone/ETS/eb_avec.c
> gs/toolbin/halftone/ETS/eb_avec.h
> gs/toolbin/halftone/ETS/eb_sse2.s
> gs/toolbin/halftone/ETS/ets.c
> gs/toolbin/halftone/ETS/ipview.html

2014-05-05 11:38:10 -0700
Ray Johnston <ray.johnston@artifex.com>
d2111f620ad95a5deb918c8d64be04012025fed1

> Fix clist closepath to wrong start point. Bug 695205, cust 870.
> When writing paths into the clist, we simplify the path for each band.
> This means that whole line segments that are not present within a band
> can be omitted which speeds up path rendering for bands. This code had
> a bug that could cause the closepath of a subpath to connect to the
> wrong point.
> If the last element written for a subpath ends at point X, and the
> start point of the first element of the next subpath is that same
> point X, then the code would forget to emit a "catchup" moveto.
> This would cause a closepath to connect to the initial point of
> the previous subpath.
> Amazingly, this bug has been there since rev 3.60 (Nov 1995) although
> a partial fix was added in 3.68 (May 1996).
> gs/base/gxclpath.c

2014-05-07 17:51:21 +0100
Chris Liddell <chris.liddell@artifex.com>
a33588aad3bde9321bd5ea7eaf37b5adba22482c

> Bug 695211: (addendum) set SHARE_TRIO for Windows builds
> CLUSTER_UNTESTED
> common/msvc_top.mak
> gs/psi/msvc.mak
> xps/xps_msvc.mak

2014-05-05 11:12:47 +0100
Chris Liddell <chris.liddell@artifex.com>
fc0420d74524a9988c8cdf465a2fbf234e343a38

> Bug 695211: Allow trio to be shared.
> No cluster differences
> gs/Makefile.in
> gs/base/gs.mak
> gs/base/lib.mak
> gs/base/trio.mak
> gs/configure.ac
> main/pcl6_gcc.mak
> main/pcl6_msvc.mak

2014-05-06 10:39:42 +0100
Ken Sharp <ken.sharp@artifex.com>
a314230d18fd13810774318d985cc46fe9ed0102

> PDF interpreter - work around GSView usage of the interpreter
> Bug #695179 "Inert links in PDF and collapsing PDF when opened in gsview with gs ver. newer that 9.07"
> Commit 073f460af5bb37edb1849c5d6235048598100437 introduced a cumulative page
> count, which is added to pdfmarks when encountered in order to cope with
> running multiple input files. The pdfmarks from the second file would
> be incorrect unless the number of pages in the first file were added to the
> destinationpage numbers.
> Unfortunately the (undocumented, unsupported) way that GSView works with the
> PDF interpreter to retrieve links failed, because the variable is unavailable
> under the conditions that GSView exercises the interpreter.
> In this commit we extend the CumultaivePageCount usage so that we first check
> if the variable is defined, and if its not, we set a default of '0'. This
> should mean that the supported use of the PDF interpreter continues to work
> correctly with multiple input files, and restores the GSView behaviour.
> No differences expected.
> gs/Resource/Init/pdf_main.ps

2014-05-05 11:39:00 +0100
Chris Liddell <chris.liddell@artifex.com>
50e62cb7c50393e0cbb34f82981e7d1f6d7a3a6d

> Bug 695206: add directories to deps for zlib/png objs
> Ensure that the build directories exist before we try to build any
> object files from zlib or png.
> No cluster differences.
> gs/base/png.mak
> gs/base/zlib.mak

2014-04-29 15:46:44 -0700
Ray Johnston <ray.johnston@artifex.com>
2cad20efb9a9a1ec483c58bd6a087a9445ba23dc

> Fix wrong tag value for customer 532, file "VINEYARD_p1.pdf"
> If the SOURCE alpha is 100%, then replace the tag, otherwise, OR.
> gs/base/gdevp14.c

2014-05-02 10:10:41 +0100
Ken Sharp <ken.sharp@artifex.com>
87218e9f187d2d8c36c3eb6721f2725d9834553a

> txtwrite - fix a copy/paste error
> After allocating memory we checked to see if it was successful but we checked
> the wrong variable. Corrected here.
> No differences expected.
> gs/devices/vector/gdevtxtw.c

2014-05-02 09:51:40 +0100
Ken Sharp <ken.sharp@artifex.com>
63a5201a2b5db40e11dd45cf991a7e5a84d7ce80

> txtwrite - clear file handle when file is closed
> When we close the output file, set the handle to 0 so that we don't later
> attempt to close it again. Apparently closing a closed file causes a
> problem on Linux.
> No differences expected.
> gs/devices/vector/gdevtxtw.c

2014-05-02 09:18:06 +0100
Ken Sharp <ken.sharp@artifex.com>
c82e83c2c10751f048a3f2260c9adaceaca7880e

> Fix some scan-build warnings from commit 0476b5036d8175a4817a9385cb6a15b64fab310e
> The code dealing with single device parameters was over-aggressive about
> reducing the ICC profile setup. In practice this is unlikely ever to be
> a problem, there is no real chance that the setup won't be performed
> before we reach this point, but its obviously much better to have the code
> correct.
> This commit essentially copies verbatim the setup code from the normal
> get_params device method in the default device.
> gs/base/gsdparam.c

2014-04-30 12:19:40 +0100
Chris Liddell <chris.liddell@artifex.com>
34a04b46e5ed098251901ce0b51caa2137928922

> Bug 695194: ignore invalid color space in shading
> When checking objects for spot colors, ignore an invalid color space in a
> shading object.
> The code during rendering already deals with this problem (by ignoring the
> shading!).
> No cluster differences.
> gs/Resource/Init/pdf_main.ps

2014-04-30 09:58:11 +0100
Chris Liddell <chris.liddell@artifex.com>
b02681f8dd6799236f040576e35884634e9c3508

> Bug 695193: USE_LARGE_COLOR_INDEX=0 on Windows
> As we use a pregenerated arch.h for Windows (in order to support cross compiling
> 64 bit executables on 32 bit systems), we need to handle this in a combination
> of the makefile and predefined arch.h
> This commit includes equivalent changes for the other pre-defined arch.h files
> No cluster differences.
> gs/arch/osx-x86-x86_64-ppc-gcc.h
> gs/arch/windows-arm-msvc.h
> gs/arch/windows-x64-msvc.h
> gs/arch/windows-x86-msvc.h
> gs/psi/msvc.mak

2014-05-01 15:14:02 +0100
Ken Sharp <ken.sharp@artifex.com>
ad27e65ad745e4dd287e0f7a7a0efb2637472bc2

> Implement use of the new 'device param' spec op
> Wherever possible, replace the .getdeviceparams call with a call to the
> PostScript .special_op to retrieve a single parameter.
> This cannot be done unless we can guarantee that the devices we are
> interested in will implement the spec_op device method. So some places
> which appear at first sight to be candidates can't be done this way.
> gs/Resource/Init/gs_cidfn.ps
> gs/Resource/Init/gs_fapi.ps
> gs/Resource/Init/gs_img.ps
> gs/Resource/Init/gs_pdfwr.ps
> gs/Resource/Init/gs_setpd.ps
> gs/Resource/Init/pdf_draw.ps
> gs/Resource/Init/pdf_font.ps
> gs/Resource/Init/pdf_main.ps
> gs/Resource/Init/pdf_ops.ps
> gs/psi/zfunc4.c

2014-05-01 15:11:39 +0100
Ken Sharp <ken.sharp@artifex.com>
0476b5036d8175a4817a9385cb6a15b64fab310e

> Add support for the 'device param' spec op to devices
> Adds support for the spec_op which retrieves a single device parameter to
> every device I cna find which currently implements spec_ops.
> Add spec_op support to the generic vector device, the txtwrite and the psdf
> devices
> gs/base/gdevdflt.c
> gs/base/gdevprn.c
> gs/base/gdevprn.h
> gs/base/gdevvec.c
> gs/base/gdevvec.h
> gs/base/gsdparam.c
> gs/base/gxdevice.h
> gs/base/lib.mak
> gs/devices/gdevcmykog.c
> gs/devices/gdevfpng.c
> gs/devices/vector/gdevpdfi.c
> gs/devices/vector/gdevpdfp.c
> gs/devices/vector/gdevpdfx.h
> gs/devices/vector/gdevps.c
> gs/devices/vector/gdevpsdf.h
> gs/devices/vector/gdevpsdp.c
> gs/devices/vector/gdevtxtw.c

2014-05-01 15:07:37 +0100
Ken Sharp <ken.sharp@artifex.com>
e2d3dca4aff619e0b407a8c04e559f9c509b9787

> Add a new PostScript operator to permit device spec_ops to be executed
> gs/psi/int.mak
> gs/psi/opextern.h
> gs/psi/zdevice.c

2014-05-01 15:05:15 +0100
Ken Sharp <ken.sharp@artifex.com>
3b03988711bc5ab352c61e4937282e61e5e092aa

> Add a new 'spec op' to retrieve a single parameter from a device.
> Includes a new structure to be passed as the 'data' parameter to allow us
> to pass multiple parameters.
> gs/base/gxdevsop.h

2014-04-15 14:18:16 -0700
Ray Johnston <ray.johnston@artifex.com>
e69c464da00208889ed4c55ef0e869ac9246e750

> Avoid remap calls if color already mapped to a pure color.
> Device colors that map to a pure color are common. The optimization
> reduced the number of remap_color calls to 1/390 on a QL pdf test
> file (WWTTN1CT). Performance improvement is small if FP is fast.
> gs/base/gscolor2.c
> gs/base/gxcmap.c

2014-04-29 11:48:48 +0100
Chris Liddell <chris.liddell@artifex.com>
0c5a6d8c142371b84542ab9ea175501f02cfb9bd

> Bug 695190: implement glyph width cache for pcl/pxl
> Using the FAPI integration of UFST instead of the original PCL specific
> one lost an optimisation where glyph widths were cached by the interpreter.
> Reintroduce this, and attach the widths cache to the plfont object (instead of
> it being global).
> No cluster differences.
> pl/plchar.c
> pl/plfont.c
> pl/plfont.h

2014-04-24 16:37:53 +0100
Chris Liddell <chris.liddell@artifex.com>
7580b5f2b52a51d9da6e8eb2188360f1c894ee1e

> Bug 695096: make the "display" device the default in gsx
> No cluster differences
> gs/psi/dxmain.c

2014-04-24 16:22:52 +0100
Chris Liddell <chris.liddell@artifex.com>
496d5b9ee3c8247354152ec8d2b3b8268cdc4430

> Add support for changing the default device list at runtime
> (Bug 695096)
> The graphics library searches a list of preferred devices to find a suitable
> default device. Previously that list was created at graphics library compile
> time and could not be changed after that.
> This change allows the calling application to retrieve the current string that
> represents this list, and set its preferred list and order, if required.
> No cluster differences.
> gs/base/gsdevice.c
> gs/base/gsdevice.h
> gs/base/gslibctx.c
> gs/base/gslibctx.h
> gs/base/lib.mak
> gs/psi/dwdll.c
> gs/psi/dwdll.h
> gs/psi/dwnodll.c
> gs/psi/gsdll2.def
> gs/psi/gsdll32.def
> gs/psi/gsdll32metro.def
> gs/psi/gsdll64.def
> gs/psi/gsdll64metro.def
> gs/psi/gsdllARM32metro.def
> gs/psi/iapi.c
> gs/psi/iapi.h
> gs/psi/zdevice.c

2014-04-24 13:20:01 +0100
Chris Liddell <chris.liddell@artifex.com>
5192635686b3a9da14e4531c7ce7ca85cd629a66

> Don't pass a 32 bit variable 64 is expected.
> On 64 bit platforms the "gsize" type is 64 bits long, thus if we pass a 32 bit
> integer into a call expecting to write to a gsize, we get stack corruption.
> Use a temporary gsize variable to retrieve the value, and then copy it to the
> 32 bit integer. As this is for stdin buffers, we're not likely to require
> 64 bit values!
> CLUSTER_UNTESTED
> gs/psi/dxmain.c

2014-04-22 23:50:51 -0400
James Cloos <cloos@jhcloos.com>
ab862a54568407fdaff554c56baed9809e23860b

> Set the WM_CLASS property when using the x11 DEVICEs.
> Add an explicit call to XSetClassHint(1) to the x11 devices to ensure
> that the WM_CLASS property is set.
> Setting WM_CLASS allows one to configure how gs’s output window behaves.
> For comparison, gtk+ sets the display DEVICE’s output window’s
> WM_CLASS based on the executable’s name.
> Signed-off-by: James Cloos <cloos@jhcloos.com>
> Signed-off-by: Henry Stiles <henry.stiles@artifex.com>
> gs/devices/gdevxini.c

2014-04-23 09:43:56 +0100
Ken Sharp <ken.sharp@artifex.com>
c79b0ee1dbc1cbbcbe406abd4bc47f617ed5cb2c

> pdfwrite - fix Named destinations with Names tree
> Bug #695162 "Internal hyperlinks lost when converting to pdf"
> Bug #695175 "can't save PDF file if compiled with hyperref packages"
> In order to add support for the EMBED pdfmark we had to move the named destinations
> from the PDF 1.1 /Dests dictionary to the PDF 1.2+ Names tree. The Names
> tree requires that the 'keys' be strings, unlike the old Dests dict where
> the keys are of course name objects.
> Now the PDF reference says that,with PDF 1.2 and above, both strings and
> name objects can be used to refer to named destinations. However it appears
> that this is not true for Acrobat, the reference to a named destination must
> be a string object if we are using a Names tree.
> This commit alters the creation of the Names tree so that we store the actual
> destinations as individual objects (this probably wasn't required, but it
> mimics Distiller) instead of inline dictionaries, reinstates a missing /D
> key in said dictionary and crucially alters the reference to the named
> destination so that it is a string and not a name.
> The commit also caters for 'unusual' names in named destinations. The PDF
> interpreter 'escapes' the name of a name object by adding leading NULLs if
> the name contains certain kinds of characters. We weren't catering for that
> when converting names to strings for inclusion in the Names tree, which was
> leading to an empty object, and caused Acrobat to refuse to save the file.
> Finally, while investigating the problems, I noticed a logical error with
> DOCVIEW pdfmarks which could result in Open actions being written incorrectly
> and this is also fixed here.
> No differences expected as the cluster doesn't test this kind of metadata.
> gs/devices/vector/gdevpdfm.c
> gs/devices/vector/gdevpdfo.c

2014-04-22 19:02:28 +0100
Robin Watts <robin.watts@artifex.com>
963c6827fdcd2e07c2a7bc6848a97eb7ecb3c38d

> Update Ghostscript solution for Windows.
> Later versions of VS dislike relative paths for the working directory
> in the debug set up. The solution is to use "$(ProjectDir)\.." as this
> evaluates to the same dir as ".." used to. Update the ReadMe to
> reflect this.
> Also update the Solution files so that "Output" points to the built
> executables. This enables the editing required for the debugging
> setup to be simpler.
> gs/ghostscript-ufst.vcproj
> gs/ghostscript.vcproj
> win32/GhostPDL.sln
> win32/ReadMe.txt
> win32/language_switch.vcproj
> win32/pcl.vcproj
> win32/svg.vcproj
> win32/xps.vcproj

2014-04-22 21:13:51 +0100
Chris Liddell <chris.liddell@artifex.com>
5898732ce7f140bc9bbe9818c8525a02236aa8f0

> Add a cast to address compiler warning
> No cluster differences.
> gs/psi/iapi.c

2014-04-22 17:44:13 +0100
Chris Liddell <chris.liddell@artifex.com>
fb11fa25a622124ab1ceba66b0f6ba165162f056

> Bug 695173: skip conversion to UTF8 for "local" encoding
> If we're using "GS_ARG_ENCODING_LOCAL" that means arguments are already in the
> text encoding we want so no conversion is required (and the get_codepoint()
> method is set to NULL).
> When that happens, skip the conversion step, and avoid a seg fault.
> No cluster differences.
> gs/psi/iapi.c

2014-04-21 13:42:40 -0600
Henry Stiles <henry.stiles@artifex.com>
4c1b9214b3e996778f69f33abbf02e9d4da95332

> Fix 694958 - raster portions of plot were rotated because the
> coordinate system was not properly oriented.
> The HPGL/2-RTL's current coordinate system is different depending on
> relative extant of plot width and length, rotating the system if the
> width is greater than or equal to the height. We did not handle the
> equal case properly, we mistakenly used a strict inequality.
> pcl/pgdraw.c

2014-04-18 11:08:54 +0100
Ken Sharp <ken.sharp@artifex.com>
12e2eafa38a9932bb136879374423de133075a4a

> PDF interpreter - reinstate (and complete) the BMC/BDC/EMC pdfmark support
> Bug #695151 "Add BMC/EMC and BDC pdfmark support"
> This is the patch supplied by Alexander Grahn with a couple of very minor
> additions. Firstly we clean up the Properties resource in pdf_close in case
> by some chance there are still properties dictionaries lying around. Secondly
> we treat the Properties resource specially (like fonts) in
> pdf_store_page_resources().
> Because we write the properties dictionaries in line, we must not emit them
> in pdf_store_page_resources (they no longer exist for one thing) as this
> leads to duplicate objects being created. We may need to revisit this in the
> future as I'm not 100% certain this is the best way to proceed. However it
> works properly for all the (very few) test cases I have, or have been able
> to create.
> This patch also 'fixes' the opdfread ps2write header. In the past if a BMC
> EMC or BDC was encountered in the PDF file it would try to handle it, but
> the handler doesn't exist, leading to PostScript errors. Rather than try
> to reconstruct the requisite pdfmarks I've chosen simply to ignore these
> constructs. If anyone objects strenuously we can figure out a handler
> in future.
> No differences expected.
> gs/devices/vector/gdevpdfm.c
> gs/devices/vector/gdevpdfu.c
> gs/devices/vector/opdfread.h
> gs/lib/opdfread.ps

2014-04-17 09:45:00 +0100
Ken Sharp <ken.sharp@artifex.com>
b374d709ac920682b4848ea9070681ceb6b44790

> PDF interpreter - treat 0 length CIDToGIDMap as if it were not present
> Bug #695167 "Output page blank"
> The PDF contained a type 11 CIDFont with a CIDToGIDMap whose length was 0,
> this caused the type11buildfont code to fail.
> Since the CIDTogidMap is optional, treating a 0 length map as 'not present'
> seems a sensible solution.
> No differences expected
> gs/Resource/Init/pdf_font.ps

2014-04-16 09:41:19 +0100
Ken Sharp <ken.sharp@artifex.com>
d2f4c3e592b0f4063ce92c9245dc903ad75495fc

> PDF interpreter - improve transparency detection and apply it to annotations
> The existence of CA and ca in annotations without appearance streams were
> not detected. The FreeText annotation synthesis can apply transparency if
> present, so we need to detect it and push the compositor.
> Also, add the code to the FreeText annotation appearance synthesis to apply
> transparency.
> A few (3) Sumatra PDF files now render very slightly differently, and the
> same files now produce larger PostScript than they did before (because they
> are rendered to images)
> gs/Resource/Init/pdf_draw.ps
> gs/Resource/Init/pdf_main.ps

2014-04-15 12:51:51 +0100
Ken Sharp <ken.sharp@artifex.com>
0ace93f19464cab701f117ba1e6ee489062748e5

> PDF interpreter - sunthesise appearances for FreeText annotations
> Bug #693731 "Freetext annotations are not printed"
> The FreeText annotation in question has no appearance stream and we did
> no previously synthesise one. This commit adds code to do so, it should
> work with UTF16-BE text but I don't have a test file for this.
> The existing code to draw annotation borders was insufficient, it did not
> correctly drop elements drawn with a colour of /C[] and would not handle
> colours (/C) defined in anything except RGB space.
> The Sumatra test file annotations_galore_II.pdf exhibits a progression
> with this commit (its the only other example of this I could find)
> gs/Resource/Init/pdf_draw.ps

2014-04-15 10:09:19 +0100
Ken Sharp <ken.sharp@artifex.com>
b0a655cb457f5d719a647ef0663c4770c764cef7

> pdfwrite - disable the BMC/BDC/EMC pdfamrks again
> The previous commit b90e081b8ad9b64ae4b66bd27262a9582c129cfc could create
> PDF files which Acrobat couldn't open.
> This disables the pdfmark processing until I find out why.
> gs/devices/vector/gdevpdfm.c

2014-04-15 09:35:45 +0100
Ken Sharp <ken.sharp@artifex.com>
b90e081b8ad9b64ae4b66bd27262a9582c129cfc

> pdfwrite - implement the BDC, BMC and BDC pdfmarks
> Bug #695151 "Add BMC/EMC and BDC pdfmark support"
> Adopt the patch from Alexander Grahn, with the small addition of code to
> free the Properties resource at the end of the job.
> No differences expected.
> gs/devices/vector/gdevpdf.c
> gs/devices/vector/gdevpdfm.c
> gs/devices/vector/gdevpdfx.h

2014-04-14 16:47:35 +0200
Norbert Janssen <norbert.janssen@oce.com>
723ae69281aec8c7e9ad5192fe77761f4e476186

> Bug 695049: plexity handling in pcl
> Handle plexity in pcl (and its interactions with left/top offset
> registrations, pageside selections).
> pcl/pcjob.c
> pcl/pcpage.c
> pxl/pxsessio.c

2014-04-11 22:33:07 -0600
Henry Stiles <henry.stiles@artifex.com>
44a0504d79c28baa6d7a5eda6d5a697424be1c7b

> Fix 695417 cursor tracking broken.
> The bug subject is incorrect, the problem was initially diagnosed as a
> problem with GL/2 and PCL cursor interaction, but in fact it was the
> rounding of the translation components of PCL raster to device space
> matrix produced incorrect results at some resolutions.
> This problem needs a bit more investigation but empirically not
> rounding translation components seems to give better results. I don't
> know if this is because it more closely emulates HP's calculations or
> if there is another interaction in the ghostscript graphics library
> which makes the integral translation components inappropriate.
> The change results in many single pixel translations in the regression
> tests.
> pcl/rtgmode.c

2014-04-11 10:46:11 -0600
Henry Stiles <henry.stiles@artifex.com>
fdffeb917e804522ed7117f19ac230c9d23d158f

> Fix bug #695129 black background painted with the pxlcolor device.
> PXL has no high level understanding of PostScript or PDF transfer
> functions so we fall back to having the graphics library handle color
> conversion when a transfer function is set.
> gs/devices/vector/gdevpx.c

2014-04-09 14:32:40 +0100
Ken Sharp <ken.sharp@artifex.com>
c8673cb8209a9f294721fae7a1842fcd8940ecab

> PDF interpreter - implement the (not yet documented) revision 6 security handler
> Copied from the MUPDF implementation. This does cause a few differences,
> I'm not really sure why as the code can't possibly be causing them. I assume
> its simply memory differences of some kind.
> gs/Resource/Init/pdf_sec.ps
> gs/psi/int.mak
> gs/psi/zpdf_r6.c

2014-04-08 14:10:45 -0600
Henry Stiles <henry.stiles@artifex.com>
cd8b2819ddd9c9aba33a19c8913861767296d576

> Disable the remaining long form color commands, fixing 695110.
> All of the color long form commands appear to be no longer supported
> on modern HP devices and our implementation of them frequently results
> in unexpected output and difficult to find bugs. This change gets rid
> of the remaining commands which affected white and black point
> settings. Aside from fixing the test file in the bug this improves
> several panels in the Quality Logic FTS against the Color Laserjet
> 4700, i.e. panels 810 and 814.
> The command is simply truncated so the long form command is
> transformed into a corresponding short form allowing for setting of
> the color space, bits per component, etc. The long form code remains
> for now and is easily brought back if we get user feedback that there
> is an HP device we care to support with these extended color commands.
> If that is the case it will have to be handled with conditional
> compilation or a device emulation mode. We'd like to avoid that if
> possible.
> pcl/pccid.c

2014-04-07 19:32:45 +0200
Norbert Janssen <janssnjj@xs4all.nl>
2d0a6b70f3578a1e4ba61d05d1682a0e2a8f764b

> Bug 695138: PCL pushcursor in definemacro not stored correctly (combined command)
> When a macro is defined with a combined command and de define is not
> the closing command (i.e. 0x) then the continuation as stored in the
> macro_prefix (pcparse.c) is not correct. It contains only the <ESC>&,
> but should have been <ESC>&f).
> Thus a following 0S is stored as <ESC>&0S, i.s.o. <ESC>&f0S, and is not
> recognized as a valid push-cursor command.
> pcl/pcparse.c

2014-04-07 10:47:41 +0100
Chris Liddell <chris.liddell@artifex.com>
11bb9975a044bf281a498a8f20d3f2436725ad3d

> Bug 692577: tweak lprsetup.sh for non-default locations
> Provide a command line option to lprsetup.sh to specify where the filter files
> should be written. Also, implement a simple heuristic to attempt to identify
> the correct location for the filter files.
> Finally, if we rely on the above heuristic, issue a warning and give the user
> the chance to abort the script.
> CLUSTER_UNTESTED
> gs/lib/lprsetup.sh

2014-04-04 15:19:47 +0100
Ken Sharp <ken.sharp@artifex.com>
7e1117aa46696ea3d05f54e4bdd13d6641d53d8a

> PXL font code - correct the order of a matrix multiplication
> Bug #693947 "The Intellifont as type 3 font commit causes a regression."
> Matrix multiplication is not commutative, and the order of operands was
> incorrect in this case. Since it only matters for high level devices it
> naturally only showed up with pdfwrite.
> This shows a progression (with pdfwrite) in C207.bin and bug691464b.xl
> which actually appears to be the same file.
> pxl/pxfont.c

2014-04-04 14:42:20 +0200
Norbert Janssen <norbert.janssen@oce.com>
2024f434636139c9da20ab3afe0356d5e29c2c55

> Bug 695100: pxl jpeg decoding sometimes misses scans
> jpeg decoding (s_DCTD_process) is used by all pdls (pdf/ps/pcl/pxl/xps)
> but in different ways.
> The PDLs provide an output buffer (pw->ptr) for the decoded scan(s), and
> an input buffer (pr->ptr) with inputdata. XPS's outputbuffer can contain
> the complete image, the other pdls provide a buffer for 1 scan.
> So XPS calls the jpeg-decoder once for the complete image (including the
> EOI marker), the other pdls call repeatedly for 1 scan, until all scans
> have been retrieved.
> The jpeg-decoder (s_DCTD_process) calls gs_jpeg_read_scanlines(inputdata)
> to decode 1 scan (using the inputdata). If inputdata is not enough the pdl
> is asked for more, until (atleast) 1 scan is available. This scan
> (samples) is then copied into the outputbuffer (goto dumpbuffer:).
> If the outputbuffer is not filled completely, the jpeg-decoder is asked
> for another scan (i.e. for XPS) which is then also added to the
> outputbuffer.
> Else (if the outputbuffer cannot contain the next scan) it is passed back
> to the graphics-lib (pl_image_data), the outputbuffer is emptied and the
> jpeg-decoder is called for the next scan.
> However, with PXL, provided outputbuffer is exactly the size of a scan.
> This means that it is only transferred, when s_DCTD_process wants to copy
> a next scan (which fails because the outputbuffer is full; the
> transferring is delayed), or end-of-data is reached.
> If however, the gs_jpeg_read_scanlines() needs multiple inputbuffers to
> provide this next scan, then this next scan will be copied over the not
> yet transferred scan, thus causing the previous scan to be missed.
> The fix in sdctd.c prevents the delaying and copies immediately.
> The mod in pximage.c ensures that the complete imagedata (incl the
> jpeg-EOI) is consumed (otherwise a bufferoverflow is triggered).
> Some (PXL) cluster differences (progressions).
> gs/base/sdctd.c
> pxl/pximage.c

2014-04-02 22:57:33 +0100
Chris Liddell <chris.liddell@artifex.com>
89d0847d1f12a7069ccf2d6eff6328fd1f9aee10

> Bug 695133: fix invalid types in form xobject matrix
> The PDF in question has a name object rather a real or integer object as the
> last entry in the matrix.
> Before rendering the form, check the entries in the matrix, and if there is
> an invalid type, replace it with a real value. I've opted to use 0.00 as the
> replacement value, and this *seems* to reflect Acrobat's behavior. Creating
> a test case where one of the scale values in the matrix is an invalid type
> results in Acrobat not displaying the form, which hints at a degenerate matrix.
> We have also previously established that Acrobat substitutes zero in other
> similar cases.
> No cluster differences.
> gs/Resource/Init/pdf_draw.ps

2014-04-02 13:15:58 +0100
Ken Sharp <ken.sharp@artifex.com>
f3b31c9544c05f87fc0a58b133c5757311c49bbc

> PS interpreter - don't limit sampled tint transforms to 64k data
> Bug #693237 "PDF restrictions on PS function"
> The bug title is misleading, as is the comment in the report. The problem
> has little to do with PDF restrictions. When we get a tint transform for a
> complex space we convert it into a PostScript function rather than maintaining
> the tint transform as PostScript (we do this for performance reasons).
> In general we try to use a type 4 (PostScript calculator) function, as these
> are the most flexible variety, but these are not defined for PostScript, only
> for PDF, and it is not always possible to handle a tint transform as a type
> 4 function. In this case we fall back to using a type 0 (sampled) function.
> In order to create a sampled function we must (obviously!) sample the original
> function, and create a lookup table to store the samples. This is an M-in
> N-out table, so as the number of inputs and outputs increases the size of
> the table increases dramatically. Because we store the data in a string
> the code checks the size of the lookup table against 64k and if it is too
> large (as in this case) rejects it and tries again, taking fewer samples.
> The minimum number of samples is 2 (we must sample each end of the ramp),
> and if we cannot fit that into a 64k string, then we returned a rangecheck
> error.
> However we now permit strings greater than 64k, so while we still want to
> keep the lookup table to a sensible size, we should not abort just because
> the table is > 64k.
> This commit alters the logic so that we try to fit into a 64k string, but
> if we've reached the minimum number of samples we don't bother checking any
> more and simply use a string big enough to hold the data.
> This seems to work, however the example file is reduced to the point where
> nothing is visible on the output, and although the bug report references
> a customer file its not attached to the report, nor is there any other
> information which would allow me to find the original file. So this isn't
> hugely well tested in this unusual condition.
> No differences expected.
> gs/psi/zfsample.c

2014-04-01 14:39:12 +0100
Ken Sharp <ken.sharp@artifex.com>
fb1ac66da597d9d6fe773ddaf3413098028cc6a0

> pdfwrite - while processing pdfmarks, ensure strings are null-terminated before using sscanf
> Bug #695119 "Ghostscript inconsistently fails creating links with pdfmark"
> The problem turns out to be that while handling SrcPage in a pdfmark the
> code executed sscanf on a string which was not guaranteed to be null-terminated
> Here we copy the data and explicitly null terminate the copy before running
> sscanf, so that the returned value is reliable.
> Also remove an uninitialised variable that could potentially have caused a problem.
> No differences expected.
> gs/devices/vector/gdevpdfm.c

2014-03-31 20:25:27 +0100
Chris Liddell <chris.liddell@artifex.com>
5b5962e8610a279aba3841adb80d8e66bca2caa9

> Bug 695087: modify jbig2 device to output jb2 files
> The jbig2 device originally was written to output "bare" streams, as are written
> to PDF files, but is of very limited use.
> This commit changes it so the "bare" stream is written to a jb2 container file,
> which can be easily opened, for example, by the jbig2dec command line tool.
> Note that the output seems to be inverted, I haven't "fixed" that as I'm not
> sure whether our jbi2 output is wrong, or the jbig2dec conversion to PNG is
> wrong.
> This is primarily to ease regression testing of the Luratech jbig2 encoder
> integration.
> No cluster differences.
> gs/base/sjbig2_luratech.c
> gs/base/sjbig2_luratech.h
> gs/devices/gdevjbig2.c

2014-03-31 20:21:03 +0100
Chris Liddell <chris.liddell@artifex.com>
0ccf3294ecd3dbaa654279ca605dadccb8bd122a

> Bug 695113: fix fpng device build handle shared zlib
> No cluster differences.
> gs/devices/devs.mak

2014-03-31 10:58:58 +0100
Ken Sharp <ken.sharp@artifex.com>
6cc95ce9fa08d126fc7c701f6eccc1cf49781e0b

> ps2write - fix CompressPages=false and SubFileDecode filter
> commit c30fb930e7c38dd7bcf47b0305e77cb6ba003bc3 altered the default of the
> CompressPages switch to false, this uncovered an interesting bug. The code
> previously used the string 'endstream' as the EODString argument for a
> SubFileDecode filter. When the stream contents are compressed this is reliable
> but if the stream contents are not compressed they may contain the string
> 'endstream' (eg a document describing PDF syntax) which would cause premature
> end of data detection.
> In this commit we instead set the EODString to the empty string () and set
> the EODCount to the length of the stream. This is more reliable, because we
> trust the stream length we create ourselves, but does mean that the stream
> can no longer be edited simply, the length must now be consistent with the
> actual stream contents.
> This fixes a bug introdcued with commit c30fb930e7c38dd7bcf47b0305e77cb6ba003bc3
> involving the test file DML_003-2010-1_8.pdf
> gs/devices/vector/opdfread.h

2014-03-29 10:43:27 +0000
Ken Sharp <ken.sharp@artifex.com>
083fa3f6912ad3f44fc94d5e1a362878576b0024

> ps2write - document incompatibility of ProduceDSC with the page options
> gs/doc/Ps2ps2.htm

2014-03-29 10:42:57 +0000
Ken Sharp <ken.sharp@artifex.com>
c30fb930e7c38dd7bcf47b0305e77cb6ba003bc3

> ps2write - alter the default of CompressPages to false for ps2write
> gs/Resource/Init/gs_pdfwr.ps

2014-03-29 10:42:29 +0000
Ken Sharp <ken.sharp@artifex.com>
c126936d5bd81af58743d8770d9d21ac22e64211

> ps2write - set EPS2Write to false when ProduceDSC is false
> Due to the way that DSC and non-DSC headers are emitted the variable EPS2Write
> wasn't set, which resulted in a PostScript error.
> gs/devices/vector/gdevpdfu.c

2014-03-28 13:18:34 +0000
Ken Sharp <ken.sharp@artifex.com>
27f586bb4a5f5a3ffe6508874527eae684039380

> pdfwrite - clamp CropBox to MediaBox for PDF/X output
> Bug #695120 "Page boxes not nested properly when creating PDF/X using files with bleed"
> The description of the bug is not accurate, the bleed is irrelevant.
> The problem is caused because the specimen file has ridiculously accurate
> MediaBox etc, specified to 3 decimal places. Due to rounding differences the
> CropBox can be a tiny amount (thousandths of a millimeter) large than the
> MediaBox.
> I cannot find anywhere in the PDF/X-3 spec which says that the CropBox has
> to be smaller than the MediaBox, but the Acrobat pre-flight tool complains
> if it is.
> This commit simply clamps the CropBox to the MediaBox that actually gets written
> to the PDF file (for PDF/X only) and prevents the problem.
> No differences expected
> gs/devices/vector/gdevpdf.c

2014-03-27 13:13:53 +0000
Ken Sharp <ken.sharp@artifex.com>
4840334cee8f79d3dedb8b95899dc43e7a55779a

> pdfwrite - don't emit ICC spaces with no Alternate and no potential default alternate
> Bug #691500 "Bad pdf file generated with pdfwrite"
> The XPS file cotnains a 6 colour ICC profile, the XPS interpreter passes this
> along as an ICCBased space, but does not construct an /Alternate space for
> it. pdfwrite would then emit a PDF file with a 6 colour profile and no
> /Alternate, which is illegal as there is no possible way to convert the
> input into a device space without handling the ICC profile.
> If we encounter this (which I think is only possible from XPS), we now give
> up on the ICC profile and instead convert to the ProcessColorModel colour
> space instead.
> Ghostscript can read the resulting file without error, Acrobat gives a
> 'drawing error' and evince complains about input profiles, but in general
> I'm going to label this as a fix.
> No differences expected
> gs/devices/vector/gdevpdfk.c

2014-03-27 08:23:37 +0000
Ken Sharp <ken.sharp@artifex.com>
094451a13d990ba0f64c285ba157b6f45deb09e6

> txtwrite - fix a buffer overrun
> Bug #695109 "gswin32c produces an access violation when using txtwrite"
> A cut and paste error led to us trying to copy a char string as a sequence
> of shorts, resulting in overrunning the source buffer. Depending on the
> precise memory layout this could cause access to unallocated memory and
> an application crash.
> Thanks to José Antonio for persisting with this bug and doing all the
> debugging work.
> No differences expected.
> gs/devices/vector/gdevtxtw.c

2014-03-26 09:09:12 +0000
Chris Liddell <chris.liddell@artifex.com>
0b40e26308b5a728b1b1cbab7104c7da6b57618f

> Update docs for release.
> gs/doc/API.htm
> gs/doc/C-style.htm
> gs/doc/Commprod.htm
> gs/doc/DLL.htm
> gs/doc/Deprecated.htm
> gs/doc/Details8.htm
> gs/doc/Details9.htm
> gs/doc/Develop.htm
> gs/doc/Devices.htm
> gs/doc/Drivers.htm
> gs/doc/Fonts.htm
> gs/doc/Helpers.htm
> gs/doc/History1.htm
> gs/doc/History2.htm
> gs/doc/History3.htm
> gs/doc/History4.htm
> gs/doc/History5.htm
> gs/doc/History6.htm
> gs/doc/History7.htm
> gs/doc/History8.htm
> gs/doc/History9.htm
> gs/doc/Install.htm
> gs/doc/Issues.htm
> gs/doc/Language.htm
> gs/doc/Lib.htm
> gs/doc/Make.htm
> gs/doc/News.htm
> gs/doc/Projects.htm
> gs/doc/Ps-style.htm
> gs/doc/Ps2epsi.htm
> gs/doc/Ps2pdf.htm
> gs/doc/Ps2ps2.htm
> gs/doc/Psfiles.htm
> gs/doc/Readme.htm
> gs/doc/Release.htm
> gs/doc/SavedPages.htm
> gs/doc/Source.htm
> gs/doc/Unix-lpr.htm
> gs/doc/Use.htm
> gs/doc/WhatIsGS.htm
> gs/doc/Xfonts.htm
> gs/doc/gs-vms.hlp
> gs/doc/thirdparty.htm
> gs/man/dvipdf.1
> gs/man/font2c.1
> gs/man/gs.1
> gs/man/gslp.1
> gs/man/gsnd.1
> gs/man/pdf2dsc.1
> gs/man/pdf2ps.1
> gs/man/pf2afm.1
> gs/man/pfbtopfa.1
> gs/man/printafm.1
> gs/man/ps2ascii.1
> gs/man/ps2epsi.1
> gs/man/ps2pdf.1
> gs/man/ps2pdfwr.1
> gs/man/ps2ps.1
> gs/man/wftopfa.1

2014-03-26 12:52:30 +0000
Chris Liddell <chris.liddell@artifex.com>
221a37e79b9d0e93d73b257bf16fe9c96c7505a0

> Bump version number.
> gs/Resource/Init/gs_init.ps
> gs/base/version.mak

2014-03-26 07:34:18 +0000
Chris Liddell <chris.liddell@artifex.com>
ee4458671553d95302439bacbbb66333d019b83a

> Add eps2write to Linux gs and all ghostpdl bulids
> No cluster differences.
> gs/Makefile.in
> gs/configure.ac
> main/pcl6_gcc.mak
> main/pcl6_msvc.mak

2014-03-26 08:46:33 +0000
Ken Sharp <ken.sharp@artifex.com>
c481ce6ab184e6cd109b856d6ba6d2bd440be85b

> ps2write - better documentation for HaveTrueTypes
> The documentation for HaveTrueTypes stated that TrueType fonts would be
> emitted as bitmap fonts if -dHaveTrueTypes is false. This information was
> only partially correct, if the size of the bitmap (as determined by the
> text size and resolution) exceeds the maximum for the cache then we don't
> put the bitmap in a font at all, we emit it as an inline image.
> gs/doc/Ps2pdf.htm

2014-03-14 10:00:05 +0000
Chris Liddell <chris.liddell@artifex.com>
de72ef09fd37d51755faefdb4d719c78ac85d60c

> doc changes from 9.12 release
> Update version number, release and copyright dates.
> Update release notes, changelog and couple of tweaks
> Update product string and date for release.
> CLUSTER_UNTESTED
> gs/Makefile.in
> gs/base/version.mak
> gs/doc/API.htm
> gs/doc/C-style.htm
> gs/doc/Commprod.htm
> gs/doc/DLL.htm
> gs/doc/Deprecated.htm
> gs/doc/Details8.htm
> gs/doc/Details9.htm
> gs/doc/Develop.htm
> gs/doc/Devices.htm
> gs/doc/Drivers.htm
> gs/doc/Fonts.htm
> gs/doc/Helpers.htm
> gs/doc/History1.htm
> gs/doc/History2.htm
> gs/doc/History3.htm
> gs/doc/History4.htm
> gs/doc/History5.htm
> gs/doc/History6.htm
> gs/doc/History7.htm
> gs/doc/History8.htm
> gs/doc/History9.htm
> gs/doc/Install.htm
> gs/doc/Issues.htm
> gs/doc/Language.htm
> gs/doc/Lib.htm
> gs/doc/Make.htm
> gs/doc/News.htm
> gs/doc/Projects.htm
> gs/doc/Ps-style.htm
> gs/doc/Ps2epsi.htm
> gs/doc/Ps2pdf.htm
> gs/doc/Ps2ps2.htm
> gs/doc/Psfiles.htm
> gs/doc/Readme.htm
> gs/doc/Release.htm
> gs/doc/SavedPages.htm
> gs/doc/Source.htm
> gs/doc/Unix-lpr.htm
> gs/doc/Use.htm
> gs/doc/WhatIsGS.htm
> gs/doc/Xfonts.htm
> gs/doc/gs-vms.hlp
> gs/doc/thirdparty.htm
> gs/man/dvipdf.1
> gs/man/font2c.1
> gs/man/gs.1
> gs/man/gslp.1
> gs/man/gsnd.1
> gs/man/pdf2dsc.1
> gs/man/pdf2ps.1
> gs/man/pf2afm.1
> gs/man/pfbtopfa.1
> gs/man/printafm.1
> gs/man/ps2ascii.1
> gs/man/ps2epsi.1
> gs/man/ps2pdf.1
> gs/man/ps2pdfwr.1
> gs/man/ps2ps.1
> gs/man/wftopfa.1
> gs/psi/msvc.mak
> gs/psi/winint.mak

2013-12-31 15:19:54 +0000
Robin Watts <robin.watts@artifex.com>
cdde0e961884a0dbe7e576af5f2f73df9527af6b

> Import LCMS 2.6 Release version
> Update gs calling code to cope, including simple mutex
> handlers. Also incorporates our optimisations etc.
> gs/base/gsicc_lcms2.c
> gs/base/lib.mak
> gs/lcms2/AUTHORS
> gs/lcms2/ChangeLog
> gs/lcms2/Makefile.am
> gs/lcms2/Makefile.in
> gs/lcms2/Projects/VC2010/testbed/testbed.vcxproj
> gs/lcms2/Projects/VC2010/testbed/testbed.vcxproj.filters
> gs/lcms2/Projects/VC2012/jpegicc/jpegicc.vcproj
> gs/lcms2/Projects/VC2012/jpegicc/jpegicc.vcxproj
> gs/lcms2/Projects/VC2012/jpegicc/jpegicc.vcxproj.filters
> gs/lcms2/Projects/VC2012/lcms2.rc
> gs/lcms2/Projects/VC2012/lcms2.sln
> gs/lcms2/Projects/VC2012/lcms2_DLL/lcms2_DLL.vcproj
> gs/lcms2/Projects/VC2012/lcms2_DLL/lcms2_DLL.vcxproj
> gs/lcms2/Projects/VC2012/lcms2_DLL/lcms2_DLL.vcxproj.filters
> gs/lcms2/Projects/VC2012/lcms2_static/lcms2_static.vcproj
> gs/lcms2/Projects/VC2012/lcms2_static/lcms2_static.vcxproj
> gs/lcms2/Projects/VC2012/lcms2_static/lcms2_static.vcxproj.filters
> gs/lcms2/Projects/VC2012/linkicc/linkicc.vcproj
> gs/lcms2/Projects/VC2012/linkicc/linkicc.vcxproj
> gs/lcms2/Projects/VC2012/linkicc/linkicc.vcxproj.filters
> gs/lcms2/Projects/VC2012/psicc/psicc.vcproj
> gs/lcms2/Projects/VC2012/psicc/psicc.vcxproj
> gs/lcms2/Projects/VC2012/psicc/psicc.vcxproj.filters
> gs/lcms2/Projects/VC2012/resource.h
> gs/lcms2/Projects/VC2012/testbed/testbed.vcproj
> gs/lcms2/Projects/VC2012/testbed/testbed.vcxproj
> gs/lcms2/Projects/VC2012/testbed/testbed.vcxproj.filters
> gs/lcms2/Projects/VC2012/tiffdiff/tiffdiff.vcproj
> gs/lcms2/Projects/VC2012/tiffdiff/tiffdiff.vcxproj
> gs/lcms2/Projects/VC2012/tiffdiff/tiffdiff.vcxproj.filters
> gs/lcms2/Projects/VC2012/tifficc/tifficc.vcproj
> gs/lcms2/Projects/VC2012/tifficc/tifficc.vcxproj
> gs/lcms2/Projects/VC2012/tifficc/tifficc.vcxproj.filters
> gs/lcms2/Projects/VC2012/transicc/transicc.vcproj
> gs/lcms2/Projects/VC2012/transicc/transicc.vcxproj
> gs/lcms2/Projects/VC2012/transicc/transicc.vcxproj.filters
> gs/lcms2/Projects/cppcheck/lcms2.cppcheck
> gs/lcms2/Projects/mac/.DS_Store
> gs/lcms2/Projects/mac/._.DS_Store
> gs/lcms2/Projects/mac/LittleCMS/.DS_Store
> gs/lcms2/Projects/mac/LittleCMS/._.DS_Store
> gs/lcms2/Projects/mac/LittleCMS/Info.plist
> gs/lcms2/Projects/mac/LittleCMS/LittleCMS.xcodeproj/mariama.mode1v3
> gs/lcms2/Projects/mac/LittleCMS/LittleCMS.xcodeproj/mariama.pbxuser
> gs/lcms2/Projects/mac/LittleCMS/LittleCMS.xcodeproj/project.pbxproj
> gs/lcms2/aclocal.m4
> gs/lcms2/autogen.sh
> gs/lcms2/configure
> gs/lcms2/configure.ac
> gs/lcms2/doc/LittleCMS2.5 API.pdf
> gs/lcms2/doc/LittleCMS2.5 Plugin API.pdf
> gs/lcms2/doc/LittleCMS2.5 tutorial.pdf
> gs/lcms2/doc/LittleCMS2.6 API.pdf
> gs/lcms2/doc/LittleCMS2.6 Plugin API.pdf
> gs/lcms2/doc/LittleCMS2.6 tutorial.pdf
> gs/lcms2/include/Makefile.in
> gs/lcms2/include/lcms2.h
> gs/lcms2/include/lcms2_plugin.h
> gs/lcms2/m4/acx_pthread.m4
> gs/lcms2/src/Makefile.in
> gs/lcms2/src/cmscam02.c
> gs/lcms2/src/cmscgats.c
> gs/lcms2/src/cmscnvrt.c
> gs/lcms2/src/cmserr.c
> gs/lcms2/src/cmsgamma.c
> gs/lcms2/src/cmsgmt.c
> gs/lcms2/src/cmsintrp.c
> gs/lcms2/src/cmsio0.c
> gs/lcms2/src/cmsio1.c
> gs/lcms2/src/cmsopt.c
> gs/lcms2/src/cmspack.c
> gs/lcms2/src/cmsplugin.c
> gs/lcms2/src/cmsps2.c
> gs/lcms2/src/cmstypes.c
> gs/lcms2/src/cmsvirt.c
> gs/lcms2/src/cmswtpnt.c
> gs/lcms2/src/cmsxform.c
> gs/lcms2/src/extra_xform.h
> gs/lcms2/src/lcms2.def
> gs/lcms2/src/lcms2_internal.h
> gs/lcms2/testbed/Makefile.am
> gs/lcms2/testbed/Makefile.in
> gs/lcms2/testbed/ibm-t61.icc
> gs/lcms2/testbed/new.icc
> gs/lcms2/testbed/testcms2.c
> gs/lcms2/testbed/testcms2.h
> gs/lcms2/testbed/testplugin.c
> gs/lcms2/testbed/testthread.cpp
> gs/lcms2/testbed/zoo_icc.c
> gs/lcms2/utils/delphi/lcms2dll.pas
> gs/lcms2/utils/jpgicc/Makefile.in
> gs/lcms2/utils/jpgicc/jpgicc.c
> gs/lcms2/utils/linkicc/Makefile.in
> gs/lcms2/utils/psicc/Makefile.in
> gs/lcms2/utils/psicc/psicc.c
> gs/lcms2/utils/tificc/Makefile.in
> gs/lcms2/utils/tificc/tificc.c
> gs/lcms2/utils/transicc/Makefile.in
> gs/lcms2/utils/transicc/transicc.1

2014-03-24 10:00:23 +0000
Ken Sharp <ken.sharp@artifex.com>
c74e146b74fe6db9f3a91ff71b7478dac79b5c1a

> Repair performance degradation with PostScript functions
> Bug #693561 "gs_c_param_list_release() corrupts memory"
> The commit 289aa28f46e2be1c87c34d44ee86dec41e87506b removed the explicit
> test of the device name with a test against a specifically named device
> parameter. However, as noted in the bug, this led to a performance penalty
> as the parameter was re-evaluated inside a loop.
> This commit moves the parameter evaluation outside check_psc_function()
> altogether as this routine can be called recursively. Instead the parameter
> is retrieved in the calling routines and passed as a new argument.
> No differences expected
> gs/psi/zfunc4.c

2014-03-24 09:56:32 +0000
Ken Sharp <ken.sharp@artifex.com>
23666d2037f14a1ef880e60bce9008203e502436

> Make C 'param' collections free memory as per 'ref' params
> Bug #693561
> The 'memory corruption' referred to in the bug report is actually a memory
> leak, and is only exposed by using the -Z? (check pointers) debugging switch.
> As such its not as disastrous as the bug report makes it sound (I'm unable
> to reproduce the SEGV).
> Its caused because when we retrieve a parameter list from the device, we do
> so using the 'C' param list structures rather than the PostScript 'ref'
> params. One of the things that pdfwrite returns is image dictionaries, and
> these require us to create a temporary param list. With the 'ref' param
> structures, when we call param_end_write_dict (redirected through a macro
> to param_end_write_collection, further redirected through a macro to
> plist->procs->end_xmit_collection) the memory used by the list is explicitly
> freed, when we use the 'C' param, it is *NOT* freed.
> All the places in the code that I can find where we call param_end_write_dict
> seem to assume that this will also free the memory. This commit modifies
> the C param list code so that it also frees the memory. At least now the
> two param types behave the same.
> No differences expected
> gs/base/gscparam.c

2014-03-22 04:07:14 +0000
Hin-Tak Leung <hintak@ghostscript.com>
8ae4ee220766aa180150eafeffe4f094f1354f92

> Fixes PXL segfault with trying to set up icc transform for bitmasks, Bug 695103
> Masks also get treated as images (the conditionals about being masks,
> bit-depths, interpolation, etc is getting really long...), and the
> iccTranform change mistakenly try to set up link transform for such.
> There should be an additional conditional (where this change is) for
> the data not being masks. This is equivalent to not
> setting up icc tranform for missing color space info (Part 1), but clearer.
> The other two check images having valid color space info, and should stay.
> Cluster tested. No difference expected.
> Signed-off-by: Hin-Tak Leung <hintak@ghostscript.com>
> gs/devices/vector/gdevpx.c

2014-03-21 21:44:30 +0000
Hin-Tak Leung <hintak@ghostscript.com>
553cea8ecaeba7a48837325da098583eaef5f1ca

> Further protection against PXL segfault with image data without colorspace info, Bug 695103
> Someghow since gs 9.10, it becomes possible for image data to arrive
> without colorspace info, and accessing such causes segfault; we should
> protect against it in any case, but further investigation (possibly
> by somebody else) is needed on how that happened. Part 2 of the fix.
> Cluster tested. No difference expected.
> Signed-off-by: Hin-Tak Leung <hintak@ghostscript.com>
> gs/devices/vector/gdevpx.c

2014-03-21 21:42:30 +0000
Hin-Tak Leung <hintak@ghostscript.com>
b780ff05fd1959202b27f9c0da383968a7e398e9

> Protection against PXL segfault with image data without colorspace info, Bug 695103
> Someghow since gs 9.10, it becomes possible for image data to arrive
> without colorspace info, and accessing such causes segfault; we should
> protect against it in any case, but further investigation (possibly
> by somebody else) is needed on how that happened. Part 1 of the fix.
> Cluster tested. No difference expected.
> Signed-off-by: Hin-Tak Leung <hintak@ghostscript.com>
> gs/devices/vector/gdevpx.c

2014-03-20 11:40:18 +0000
Ken Sharp <ken.sharp@artifex.com>
b504d2f72c6903a4dbf66176ec3358e4cd5d151d

> pdfwrite - fix multi-plane images with < 8bpc
> The code to pack multiple bit planes into bytes didn't properly account
> for the number of bytes to be written to the output. We always wrote a
> full block of bytes as long as the number of bytes remaining was not
> greater than our block size. That is, it did not account for the fact that
> we might not need to write a complete block of bytes, in the case where the
> number of bytes left was exactly equal to the size of our internal block.
> Fixed that by changing the '>=' to '>' so that if the size was equal we would
> properly check to see how many bytes we actually need to write. This then
> uncovered another problem, if the width of the image in bits was a multiple
> of the block size, then we wouldn't write any data. Fixed that too.
> No differences expected.
> gs/devices/vector/gdevpdfi.c

2014-02-14 23:18:53 +0000
Hin-Tak Leung <hintak@ghostscript.com>
bccf1cdd8d8936a8ff89ea09c1887a4816ca5685

> Miscellaneous corrections to typos and comments, accumulated over a while.
> Not cluster tested.
> Signed-off-by: Hin-Tak Leung <hintak@ghostscript.com>
> gs/base/gxblend.h
> pcl/pcindxed.c
> pcl/rtgmode.c
> pcl/rtraster.c

2014-03-10 00:37:09 +0000
Hin-Tak Leung <hintak@ghostscript.com>
d1f1b3eccb689bb9c1fa80f20f222c44ed563e99

> Fixes unicode-processing related slowdown from the python 2 to 3 migration.
> Replaces the last "+" usage by join() in the hex dump part.
> Concatenation via "+" in python has always known to be slow.
> It becomes of acceptable speed towards the end of the python
> 2 cycle, and becomes very slow again when 3-migration
> compatibility for python 2 is switched on. This is a
> Python string processing idiosyncrasy - the optimal
> ways of concatenating strings in python is via join(), instead
> of the more common "+".
> 3MB test file (attachment 9725 to bug 694086) - any
> non-small PXL file should do. "+" is almost 20x slower
> than join():
> $ time python2 before/pxldis.py test.pxl > /dev/null
> real 4m39.810s
> user 4m9.798s
> sys 0m2.548s
> $ time python3 before/pxldis.py test.pxl > /dev/null
> real 0m13.150s
> user 0m12.374s
> sys 0m0.081s
> $ time python2 after/pxldis.py test.pxl > /dev/null
> real 0m18.653s
> user 0m17.871s
> sys 0m0.129s
> $ time python3 after/pxldis.py test.pxl > /dev/null
> real 0m13.295s
> user 0m12.969s
> sys 0m0.053s
> Not cluster tested. cluster testing is not relevant to this script.
> Signed-off-by: Hin-Tak Leung <hintak@ghostscript.com>
> tools/pxldis.py

2014-03-12 15:16:05 +0000
Hin-Tak Leung <hintak@ghostscript.com>
41ab485d48890ecadc3d5f74657b644f9d1a8d7f

> pxlmono/pxlcolor: Transform deep (24-bit) images with an ICC transform to emit high-level images. Bug 690867.
> Deep images with an associated rendering intent
> or custom colour spaces, or icc profiles, could be emitted
> more efficiently as high-level PXL images if the individual
> pixels values are transformed through the icclink transform.
> The new code path is off by default, and switched on via an option
> (-diccTransform). When the new code is thoroughly tested, this
> option will be removed and the new code path will become the default.
> Cluster tesed - new code is optional and off by default,
> no difference is expected.
> Signed-off-by: Hin-Tak Leung <hintak@ghostscript.com>
> gs/devices/vector/gdevpx.c

2014-03-12 15:03:58 +0000
Hin-Tak Leung <hintak@ghostscript.com>
4b44b41c9b6c4a7e5ebf03b6970f9be39548443b

> Implements PCL XL Compression Mode 2 (JPEG), and updated documentation and other support files. Bug 694282.
> This patch implements PCL XL Compression Mode 2 (JPEG) -
> Bug 694282. Compression Mode 2 would be appropriate when the
> original image data is already lossy (Bug 691880 - JPX,
> Bug 690867 - JPEG).
> Unlike compression mode 1 (RLE) and 3 (DeltaRow), JPEG
> is not appropriate for arbitrary indexed-coloured images
> or masks, so this new functionality will silently fall
> back to RLE for masks and other unsuitable data.
> Currently it is limited to apply to only 24-bit input to
> be on the conservative side. Further furture improvement
> may be possible for gray 8-bit images to emit gray jpeg
> if those can be identified accurately.
> Cluster tested. The new functionality is optonal and controlled by
> -dCompressMode=2 (default 1) so no difference is expected.
> Signed-off-by: Hin-Tak Leung <hintak@ghostscript.com>
> gs/devices/devs.mak
> gs/devices/vector/gdevpx.c
> gs/doc/Devices.htm

2014-03-18 11:41:44 -0700
Ray Johnston <ray.johnston@artifex.com>
39da69e074c36e5a56ac52041444e4af1aa9a7c8

> Fix Segfaults caused by 'vertical stripe' fix (f18fac0).
> The done flag is no longer needed and caused us to exit the while
> loop before processing enough of the data.
> Also, move_landscape_buffer could end up with position_curr ==
> position_new so we were moving 'in place' (wasting time). Fix that.
> gs/base/gxht_thresh.c

2014-03-18 11:39:51 +0000
Ken Sharp <ken.sharp@artifex.com>
7c8b652e6e9019c8e9c9731f8e7a59c3505db638

> pdfwrite - null a pointer to avoid an enumeration problem
> pdev->vgstack wasn't being set to NULL when freed, which could lead to
> garbage collection problems.
> At the same time, remove two macros which I really don't like (and made this
> problem difficult to locate) and set a couple more pointers to NULL when
> the contents are freed.
> Bug #694380, but unfortunately this simply causes a seg fault in a different
> location.
> gs/devices/vector/gdevpdf.c
> gs/devices/vector/gdevpdfx.h
> gs/devices/vector/gdevpdtd.c

2014-03-18 10:44:49 +0000
Chris Liddell <chris.liddell@artifex.com>
f20811cce805fcc748e58112ec4fdaa87b934960

> Bug 694612: add some bounds checking to fax decode
> to prevent writing off the end of the buffer with corrupted data.
> No cluster differences.
> gs/base/scfd.c

2014-03-17 13:07:37 -0700
Michael Vrhel <michael.vrhel@artifex.com>
2ab7e7b2d8a7cf92b3cb5c4e6d4455e4badc98de

> Fix to turn of BPC when we are using the Gray_to_K ICC profile.
> This appears to be a bug in lcms. Will follow up with Marti. Also fix for tiff64nc. In the test
> tiff_compression_allowed we were missing the test for the 16 bit case. Surprisingly this commit
> results in progressions in the 8 bit device outputs too when we have a gray source and going
> to a CMYK device.
> gs/base/gsicc_cache.c
> gs/devices/gdevtifs.c

2014-03-17 13:06:05 +0000
Ken Sharp <ken.sharp@artifex.com>
5412d27994c9abec041e798592b2c842d8910a5c

> pdfwrite - handle CIDFonts with mixed type 3/type 1 descendants
> Bug #691096 "the file generated by ps2pdf from this PS file does not display some chars"
> The input has a CIDFont declared which uses both a type 1 and a type 3 font
> as descendants. The pdfwrite device family can't handle this, resulting in
> /.notdef glyphs.
> In this commit; when we detect a switch to a type 3 descendant, and the previous
> font was not a type 3, we set 'type3charpath' to true. This forces the
> text handling to fall back to a bitmap font mode for this text.
> This is less than ideal, but its a very rare occurence and does result in
> all the text being rendered.
> No differences expected
> gs/devices/vector/gdevpdtc.c

2014-03-15 12:47:22 -0700
Ray Johnston <ray.johnston@artifex.com>
4f18e30f56b7fcc339b617e82e948ed96d561cde

> Git rid of some simple 'unused' compiler warnings.
> gs/base/gsfcmap1.c
> gs/base/gsicc.c
> gs/base/gsicc_create.c
> gs/base/gxdcolor.c
> gs/base/gxht_thresh.c
> gs/base/gxp1fill.c
> gs/base/gxshade.c

2014-03-14 14:39:51 -0700
Ray Johnston <ray.johnston@artifex.com>
1e79e7e3f12404a85d52dfa28b254998b39b0782

> Fix broken detection for fast image threshold, planar and GrayValues > 2.
> The detection enabled ALL planar devices, so bits per component 2 and
> above would use the 1 bit methods.
> gs/base/gxicolor.c

2014-03-14 09:44:08 +0000
Chris Liddell <chris.liddell@artifex.com>
bb78de3c11b86088126d3f5d2a7a4c817caf4935

> Bump version numbers.
> gs/Resource/Init/gs_init.ps
> gs/base/version.mak

2014-03-13 20:35:53 -0700
Ray Johnston <ray.johnston@artifex.com>
f18fac03991c6164dfad81f03b3e7a8a4eadf243

> Fix sporadic vertical stripes with planar fast image thresholding (pkmraw)
> In the landscape code, only the data for the last plane was being moved
> to the start of the contone data for the next 32 lines of output. Seen
> with -sDEVICE=pkmraw -dUsePlanarBuffer J8_landscape.ps but any landscape
> image could have the problem. New code moves all planes and only resets
> the ht_landscape parameters after all planes have been processed and
> output (via copy_planes).
> gs/base/gxht_thresh.c

2014-03-26 09:09:12 +0000
Chris Liddell <chris.liddell@artifex.com>
a76558de66281375e2a738a2380ca62c0fd223d4

> Update docs for release.
> gs/doc/API.htm
> gs/doc/C-style.htm
> gs/doc/Commprod.htm
> gs/doc/DLL.htm
> gs/doc/Deprecated.htm
> gs/doc/Details8.htm
> gs/doc/Details9.htm
> gs/doc/Develop.htm
> gs/doc/Devices.htm
> gs/doc/Drivers.htm
> gs/doc/Fonts.htm
> gs/doc/Helpers.htm
> gs/doc/History1.htm
> gs/doc/History2.htm
> gs/doc/History3.htm
> gs/doc/History4.htm
> gs/doc/History5.htm
> gs/doc/History6.htm
> gs/doc/History7.htm
> gs/doc/History8.htm
> gs/doc/History9.htm
> gs/doc/Install.htm
> gs/doc/Issues.htm
> gs/doc/Language.htm
> gs/doc/Lib.htm
> gs/doc/Make.htm
> gs/doc/News.htm
> gs/doc/Projects.htm
> gs/doc/Ps-style.htm
> gs/doc/Ps2epsi.htm
> gs/doc/Ps2pdf.htm
> gs/doc/Ps2ps2.htm
> gs/doc/Psfiles.htm
> gs/doc/Readme.htm
> gs/doc/Release.htm
> gs/doc/SavedPages.htm
> gs/doc/Source.htm
> gs/doc/Unix-lpr.htm
> gs/doc/Use.htm
> gs/doc/WhatIsGS.htm
> gs/doc/Xfonts.htm
> gs/doc/gs-vms.hlp
> gs/doc/thirdparty.htm
> gs/man/dvipdf.1
> gs/man/font2c.1
> gs/man/gs.1
> gs/man/gslp.1
> gs/man/gsnd.1
> gs/man/pdf2dsc.1
> gs/man/pdf2ps.1
> gs/man/pf2afm.1
> gs/man/pfbtopfa.1
> gs/man/printafm.1
> gs/man/ps2ascii.1
> gs/man/ps2epsi.1
> gs/man/ps2pdf.1
> gs/man/ps2pdfwr.1
> gs/man/ps2ps.1
> gs/man/wftopfa.1

2014-03-26 09:06:56 +0000
Chris Liddell <chris.liddell@artifex.com>
3ab7b7c314bf478ad76dae0f90f2dd6370fa11a6

> Up version number
> gs/Resource/Init/gs_init.ps
> gs/base/version.mak

2014-03-26 07:34:18 +0000
Chris Liddell <chris.liddell@artifex.com>
0e3e14fce68beb871c48e427af6904f7441bf803

> Add eps2write to Linux gs and all ghostpdl bulids
> No cluster differences.
> gs/Makefile.in
> gs/configure.ac
> main/pcl6_gcc.mak
> main/pcl6_msvc.mak

2014-03-25 08:39:14 +0000
Chris Liddell <chris.liddell@artifex.com>
3059462485a66539f8a036b1bc60584f74901ac2

> Update product string and date for release.
> gs/base/gscdef.c
> gs/base/version.mak
> gs/doc/API.htm
> gs/doc/C-style.htm
> gs/doc/Commprod.htm
> gs/doc/DLL.htm
> gs/doc/Deprecated.htm
> gs/doc/Details8.htm
> gs/doc/Details9.htm
> gs/doc/Develop.htm
> gs/doc/Devices.htm
> gs/doc/Drivers.htm
> gs/doc/Fonts.htm
> gs/doc/Helpers.htm
> gs/doc/History1.htm
> gs/doc/History2.htm
> gs/doc/History3.htm
> gs/doc/History4.htm
> gs/doc/History5.htm
> gs/doc/History6.htm
> gs/doc/History7.htm
> gs/doc/History8.htm
> gs/doc/History9.htm
> gs/doc/Install.htm
> gs/doc/Issues.htm
> gs/doc/Language.htm
> gs/doc/Lib.htm
> gs/doc/Make.htm
> gs/doc/News.htm
> gs/doc/Projects.htm
> gs/doc/Ps-style.htm
> gs/doc/Ps2epsi.htm
> gs/doc/Ps2pdf.htm
> gs/doc/Ps2ps2.htm
> gs/doc/Psfiles.htm
> gs/doc/Readme.htm
> gs/doc/Release.htm
> gs/doc/SavedPages.htm
> gs/doc/Source.htm
> gs/doc/Unix-lpr.htm
> gs/doc/Use.htm
> gs/doc/WhatIsGS.htm
> gs/doc/Xfonts.htm
> gs/doc/gs-vms.hlp
> gs/doc/thirdparty.htm
> gs/man/dvipdf.1
> gs/man/font2c.1
> gs/man/gs.1
> gs/man/gslp.1
> gs/man/gsnd.1
> gs/man/pdf2dsc.1
> gs/man/pdf2ps.1
> gs/man/pf2afm.1
> gs/man/pfbtopfa.1
> gs/man/printafm.1
> gs/man/ps2ascii.1
> gs/man/ps2epsi.1
> gs/man/ps2pdf.1
> gs/man/ps2pdfwr.1
> gs/man/ps2ps.1
> gs/man/wftopfa.1

2014-03-14 11:56:29 +0000
Chris Liddell <chris.liddell@artifex.com>
aac778af6233ee10e66c1ca3f902adf8b6566b60

> Update release notes, changelog and couple of tweaks
> gs/doc/History9.htm
> gs/doc/News.htm
> gs/doc/Ps2pdf.htm
> gs/doc/Ps2ps2.htm
> gs/doc/Use.htm

2014-03-18 11:41:44 -0700
Ray Johnston <ray.johnston@artifex.com>
20f8aebb83a88ca225b67c3bbf5e6dae936349b0

> Fix Segfaults caused by 'vertical stripe' fix (f18fac0).
> The done flag is no longer needed and caused us to exit the while
> loop before processing enough of the data.
> Also, move_landscape_buffer could end up with position_curr ==
> position_new so we were moving 'in place' (wasting time). Fix that.
> gs/base/gxht_thresh.c

2014-03-17 13:07:37 -0700
Michael Vrhel <michael.vrhel@artifex.com>
7458c4b5eed25b49ba15dcb37b6dd2ec1d6f0089

> Fix to turn of BPC when we are using the Gray_to_K ICC profile.
> This appears to be a bug in lcms. Will follow up with Marti. Also fix for tiff64nc. In the test
> tiff_compression_allowed we were missing the test for the 16 bit case. Surprisingly this commit
> results in progressions in the 8 bit device outputs too when we have a gray source and going
> to a CMYK device.
> gs/base/gsicc_cache.c
> gs/devices/gdevtifs.c

2014-03-13 20:35:53 -0700
Ray Johnston <ray.johnston@artifex.com>
c23cde8b44a751a787636a7747b42b2da7911922

> Fix sporadic vertical stripes with planar fast image thresholding (pkmraw)
> In the landscape code, only the data for the last plane was being moved
> to the start of the contone data for the next 32 lines of output. Seen
> with -sDEVICE=pkmraw -dUsePlanarBuffer J8_landscape.ps but any landscape
> image could have the problem. New code moves all planes and only resets
> the ht_landscape parameters after all planes have been processed and
> output (via copy_planes).
> gs/base/gxht_thresh.c

2014-03-14 10:00:05 +0000
Chris Liddell <chris.liddell@artifex.com>
b65f4e9d7cdd32981680a5486e1c1c320ac4046e

> Update version number, release and copyright dates.
> gs/Makefile.in
> gs/Resource/Init/gs_init.ps
> gs/base/gscdef.c
> gs/base/version.mak
> gs/doc/API.htm
> gs/doc/C-style.htm
> gs/doc/Commprod.htm
> gs/doc/DLL.htm
> gs/doc/Deprecated.htm
> gs/doc/Details8.htm
> gs/doc/Details9.htm
> gs/doc/Develop.htm
> gs/doc/Devices.htm
> gs/doc/Drivers.htm
> gs/doc/Fonts.htm
> gs/doc/Helpers.htm
> gs/doc/History1.htm
> gs/doc/History2.htm
> gs/doc/History3.htm
> gs/doc/History4.htm
> gs/doc/History5.htm
> gs/doc/History6.htm
> gs/doc/History7.htm
> gs/doc/History8.htm
> gs/doc/History9.htm
> gs/doc/Install.htm
> gs/doc/Issues.htm
> gs/doc/Language.htm
> gs/doc/Lib.htm
> gs/doc/Make.htm
> gs/doc/News.htm
> gs/doc/Projects.htm
> gs/doc/Ps-style.htm
> gs/doc/Ps2epsi.htm
> gs/doc/Ps2pdf.htm
> gs/doc/Ps2ps2.htm
> gs/doc/Psfiles.htm
> gs/doc/Readme.htm
> gs/doc/Release.htm
> gs/doc/SavedPages.htm
> gs/doc/Source.htm
> gs/doc/Unix-lpr.htm
> gs/doc/Use.htm
> gs/doc/WhatIsGS.htm
> gs/doc/Xfonts.htm
> gs/doc/gs-vms.hlp
> gs/doc/thirdparty.htm
> gs/man/dvipdf.1
> gs/man/font2c.1
> gs/man/gs.1
> gs/man/gslp.1
> gs/man/gsnd.1
> gs/man/pdf2dsc.1
> gs/man/pdf2ps.1
> gs/man/pf2afm.1
> gs/man/pfbtopfa.1
> gs/man/printafm.1
> gs/man/ps2ascii.1
> gs/man/ps2epsi.1
> gs/man/ps2pdf.1
> gs/man/ps2pdfwr.1
> gs/man/ps2ps.1
> gs/man/wftopfa.1
> gs/psi/msvc.mak
> gs/psi/winint.mak

## Version 9.14 (2014-03-26)

This is the tenth full release in the stable 9.x series, and is primarily a maintenance release.

Highlights in this release include:

- pdfwrite now uses the same color management engine as Ghostscript rendering devices (by default LCMS2). This provides much better control over color conversion and color management generally, but will result in some small color differences when compared to the old system.

  It is no longer necessary to specify UseCIEColor (and we very much encourage you not to do this) or the ProcessColorModel if you want to convert a PDF file to a specific color space, simply set the ColorConversionStrategy appropriately.

  We do not expect any major problems to arise with this new code, but for the duration of this release a new switch -dPDFUseOldCMS is available which will restore the old color management. See: Color Conversion and Management

  Please note that due to constraints of the PDF/A-1 specification, the new color management does not yet apply when producing PDF/A files.

- A new device 'eps2write' has been added which allows for the creation of EPS files using the ps2write device instead of the old (deprecated and removed) pswrite device. This produces considerably better quality EPS files than the old epswrite device which is now also deprecated and will be removed in a future release.

- ps2write now has a feature to allow customisation of the output for specific devices. Please see PSDocOptions and PSPageOptions described in ps2ps2.htm Additional Distiller Params

- Ghostscript now reduces memory usage when processing PDF files that use transparency and output is to display devices such as Windows display or x11 (i.e. devices that are strictly full framebuffer devices), and to high level vector devices that cannot reproduce the PDF transparency model, such as the ps2write device or pdfwrite when 'flattening' to PDF 1.3 or earlier (-dCompatibilityLevel=1.3). This uses banding (clist) files to render the transparent areas in bands to reduce memory use, and unlike the existing page level banding, this is hidden from the target device.

- Ghostscript can now collect information for pages in temp files (in Ghostscript's clist format), then render and output pages for the job in arbitrary order, including normal, reverse, odd, even, or any order or subset of the pages. This is controlled with the --saved-page=___ option. (Note that this only applies to rendering devices, and not high level devices such as pdfwrite and ps2write.) See: Deferred Page Rendering

- The Ghostscript device architecture has been extended so that, when rendering bands into multiple threads, it is now possible to perform post-processing in multiple threads, such as downscale, post-render halftoning, or compression. Previously, post processing was only possible in the single main thread. This can improve performance significantly.

- Ghostscript has a new "pwgraster" output device for PWG Raster output

- The CUPS device now has improved support for PPD-less printing

- Plus the usual round of bug fixes, compatibility changes, and incremental improvements.

For a list of open issues, or to report problems, please visit bugs.ghostscript.com.

### Incompatible changes

No recorded incompatible changes.

### Changelog

2014-03-14 10:00:05 +0000
Chris Liddell <chris.liddell@artifex.com>
b65f4e9d7cdd32981680a5486e1c1c320ac4046e

> Update version number, release and copyright dates.
> gs/Makefile.in
> gs/Resource/Init/gs_init.ps
> gs/base/gscdef.c
> gs/base/version.mak
> gs/doc/API.htm
> gs/doc/C-style.htm
> gs/doc/Commprod.htm
> gs/doc/DLL.htm
> gs/doc/Deprecated.htm
> gs/doc/Details8.htm
> gs/doc/Details9.htm
> gs/doc/Develop.htm
> gs/doc/Devices.htm
> gs/doc/Drivers.htm
> gs/doc/Fonts.htm
> gs/doc/Helpers.htm
> gs/doc/History1.htm
> gs/doc/History2.htm
> gs/doc/History3.htm
> gs/doc/History4.htm
> gs/doc/History5.htm
> gs/doc/History6.htm
> gs/doc/History7.htm
> gs/doc/History8.htm
> gs/doc/History9.htm
> gs/doc/Install.htm
> gs/doc/Issues.htm
> gs/doc/Language.htm
> gs/doc/Lib.htm
> gs/doc/Make.htm
> gs/doc/News.htm
> gs/doc/Projects.htm
> gs/doc/Ps-style.htm
> gs/doc/Ps2epsi.htm
> gs/doc/Ps2pdf.htm
> gs/doc/Ps2ps2.htm
> gs/doc/Psfiles.htm
> gs/doc/Readme.htm
> gs/doc/Release.htm
> gs/doc/SavedPages.htm
> gs/doc/Source.htm
> gs/doc/Unix-lpr.htm
> gs/doc/Use.htm
> gs/doc/WhatIsGS.htm
> gs/doc/Xfonts.htm
> gs/doc/gs-vms.hlp
> gs/doc/thirdparty.htm
> gs/man/dvipdf.1
> gs/man/font2c.1
> gs/man/gs.1
> gs/man/gslp.1
> gs/man/gsnd.1
> gs/man/pdf2dsc.1
> gs/man/pdf2ps.1
> gs/man/pf2afm.1
> gs/man/pfbtopfa.1
> gs/man/printafm.1
> gs/man/ps2ascii.1
> gs/man/ps2epsi.1
> gs/man/ps2pdf.1
> gs/man/ps2pdfwr.1
> gs/man/ps2ps.1
> gs/man/wftopfa.1
> gs/psi/msvc.mak
> gs/psi/winint.mak

2014-03-18 11:41:44 -0700
Ray Johnston <ray.johnston@artifex.com>
20f8aebb83a88ca225b67c3bbf5e6dae936349b0

> Fix Segfaults caused by 'vertical stripe' fix (f18fac0).
> The done flag is no longer needed and caused us to exit the while
> loop before processing enough of the data.
> Also, move_landscape_buffer could end up with position_curr ==
> position_new so we were moving 'in place' (wasting time). Fix that.
> gs/base/gxht_thresh.c

2014-03-17 13:07:37 -0700
Michael Vrhel <michael.vrhel@artifex.com>
7458c4b5eed25b49ba15dcb37b6dd2ec1d6f0089

> Fix to turn of BPC when we are using the Gray_to_K ICC profile.
> This appears to be a bug in lcms. Will follow up with Marti. Also fix for tiff64nc. In the test
> tiff_compression_allowed we were missing the test for the 16 bit case. Surprisingly this commit
> results in progressions in the 8 bit device outputs too when we have a gray source and going
> to a CMYK device.
> gs/base/gsicc_cache.c
> gs/devices/gdevtifs.c

2014-03-13 20:35:53 -0700
Ray Johnston <ray.johnston@artifex.com>
c23cde8b44a751a787636a7747b42b2da7911922

> Fix sporadic vertical stripes with planar fast image thresholding (pkmraw)
> In the landscape code, only the data for the last plane was being moved
> to the start of the contone data for the next 32 lines of output. Seen
> with -sDEVICE=pkmraw -dUsePlanarBuffer J8_landscape.ps but any landscape
> image could have the problem. New code moves all planes and only resets
> the ht_landscape parameters after all planes have been processed and
> output (via copy_planes).
> gs/base/gxht_thresh.c

2014-03-14 09:40:22 +0000
Chris Liddell <chris.liddell@artifex.com>
7784cce96478d8bcec314e2dc8ecb3d3a849c37b

> Add missing newline to memento error logging.
> CLUSTER_UNTESTED
> gs/base/memento.c

2014-03-11 08:31:32 -0700
Ray Johnston <ray.johnston@artifex.com>
c34097f6786f809826a30484e69684adf4915e9a

> Fix output color values of pkm and pkmraw for GrayValues > 2.
> In the header we indicate the max value is 255, so the output values
> need to be scaled to that, not the color_info.max_color. We stay with
> 255 since many viewers cannot display PPM files with other that 255
> as the max (ignoring the max value in the header).
> gs/devices/gdevpbm.c

2014-03-13 11:43:24 +0000
James Cloos <cloos@jhcloos.com>
685e801f7de04d087166e24b3373ab16dcca57bc

> Bug 695080: fix typo in the pngmono device declaration
> which caused pngmono to threshold rather than halftone at or above 150 dpi.
> No cluster differences.
> gs/devices/gdevpng.c

2014-03-13 13:47:56 +0000
Robin Watts <robin.watts@artifex.com>
303b48577602fb78df5fa40eb2de1d8e73245afa

> Bug 695090: Solve memory overwrite with pkmraw in planar mode.
> When using -dUsePlanarBuffer with the pnm devices, we run the
> underlying rendering in planar mode, but then expect 'getbits'
> to return chunky pixels. As such, the memory we allocate to
> 'getbits' into should be allocated for chunky mode, not for
> planar mode.
> gs/base/gdevprn.h
> gs/base/gsdevice.c
> gs/base/gxdevcli.h
> gs/devices/gdevpbm.c

2014-03-13 11:19:11 +0000
Chris Liddell <chris.liddell@artifex.com>
f2fde5b9596318796f4ffd8d356116b1bb203ae3

> Delete gs_fform.ps
> If we want to cache forms, we should implement it properly.
> CLUSTER_UNTESTED
> gs/lib/gs_fform.ps

2014-03-13 10:53:49 +0000
Andreas Schwab <schwab@linux-m68k.org>
becedfbfdbd9dee77825ff245f48c0acc9d03252

> Bug 695058: force correct struct ref_s size
> On compilers that tightly pack structures (i.e. don't pad to alignment
> boundaries), struct ref_s could end up as 14 bytes instead of 16 bytes,
> thus breaking requirement in the garbage collector.
> This is less than ideal, and would be better achieved using the same trick
> we use for the alignment of obj_header_s in base/gxobj.h, linking the structure
> size to the obj_align_mod, but as on the majority of systems struct ref_s is
> already 16 bytes, that results in a zero byte array which notable compilers (at
> least MSVC, and probably others) to error.
> No cluster differences,
> gs/psi/iref.h

2014-03-13 09:27:28 +0000
Chris Liddell <chris.liddell@artifex.com>
fdaa74efeebb753db1855eaf6a3a824ecbf1231e

> Remove deprecated glyph mapping code.
> No cluster differences.
> gs/Resource/Init/gs_ttf.ps
> gs/Resource/Init/gs_type1.ps

2014-03-12 17:18:25 +0000
Chris Liddell <chris.liddell@artifex.com>
fe0b8fcfb69246cbea99b85f453ed6c3c83f4592

> Bug 693380: raise file path/name size limit to 4k
> And move as many cases of paths allocated on the stack to heap memory as is
> reasonable.
> No cluster differences.
> gs/base/gdevdevn.c
> gs/base/gp.h
> gs/base/gsdevice.c
> gs/base/gsiodisk.c
> gs/base/gsiomacres.c
> gs/base/gsparam2.c
> gs/devices/gdevtsep.c
> gs/devices/vector/gdevxps.c
> gs/psi/zfile.c
> xps/xpsjxr.c

2014-03-13 10:35:33 +0000
Ken Sharp <ken.sharp@artifex.com>
83b6646951fee8fe153d14d3e2d7da75894b922a

> PDF interpreter - fix multiple xref stream reading
> Bug #695086 "**** Error: Trailer is not found."
> When reading Xref streams, the PDF interpreter resizes its internal xref
> tracking objects by looking at the /Size of the stream and making sure
> the objects are at least that big. However it did not account for the fact
> that an Xref stream may not start with object 0.
> In this case the first stream encountered had a /Size of 2, and an /Index
> of [6 0]. This meant that we allocated objects of size 2, then tried to store
> into location8, which naturally failed.
> This commit adds the /Index (starting object number) to the /Size before
> ensuring the objects are large enough.
> No differences expected
> gs/Resource/Init/pdf_main.ps

2014-03-12 21:25:39 -0700
Marcos H. Woehrmann <marcos@inches.(none)>
fadf80da45458db57cffdd90f1ed6c57aa31e51f

> Fixed typo in Devices.htm.
> gs/doc/Devices.htm

2014-03-12 15:52:34 +0000
Ken Sharp <ken.sharp@artifex.com>
94d070553225e0a8fb38157e081e9496dee8fde5

> pdfwrite - remove deprecated code
> Before the release of 9.06 I #ifdef'ed a load of code as deprecated. Nobody
> has found any problems, so I'm removing the code.
> gs/devices/vector/gdevpdf.c
> gs/devices/vector/gdevpdfb.h
> gs/devices/vector/gdevpdfp.c
> gs/devices/vector/gdevpdfu.c
> gs/devices/vector/gdevpdfx.h
> gs/devices/vector/gdevpdt.h
> gs/devices/vector/gdevpdte.c
> gs/devices/vector/gdevpdtf.h
> gs/devices/vector/gdevpdtt.c
> gs/devices/vector/gdevpdtw.c
> gs/devices/vector/gdevpsds.c

2014-03-12 13:32:05 +0000
Ken Sharp <ken.sharp@artifex.com>
0598a205e9293fcaf548571624d93f534afa098d

> Documentation - remove %ram% from the projects, as it is completed
> gs/doc/Projects.htm

2014-03-12 09:33:24 +0000
Ken Sharp <ken.sharp@artifex.com>
8fad68f7c27f16cf78967443322bc4f638649f27

> Update documentation for the pdfwrite family
> devices.htm - change epswrite references to eps2write, note that support for
> language level 1 output is now removed.
> drivers.htm - alter pswrite to ps2write
> use.htm - alter epswrite to eps2write
> issues.htm - remove a surprisingly large number of documented issues which
> appear to be no longer issues. Note that epswrite is deprecated.
> ps2pdf.htm - improve the documentation of PDF/A and PDF/X output and correct
> the places where it was incorrect with the new colour management.
> No differences.
> gs/doc/Devices.htm
> gs/doc/Drivers.htm
> gs/doc/Issues.htm
> gs/doc/Ps2pdf.htm
> gs/doc/Use.htm

2014-03-11 09:58:31 -0600
Henry Stiles <henry.stiles@artifex.com>
ee30f349671e3a23d666615f1648eab4a5290b4c

> Abbreviated escape sequence improvement.
> Abbreviated escape sequences were not handled properly with commands
> that hold arbitrary amounts of data, like raster and font related
> commands. PCL shorthand is rarely used in this circumstance
> but it is legal. Thanks to Hin-Tak for the discovery and analysis of
> this problem.
> pcl/pcparse.c
> pcl/pcparse.h

2014-03-09 16:11:24 +0000
Chris Liddell <chris.liddell@artifex.com>
4c2f426905b4bf300f6b412024d71cd2be6276de

> Remove GhostSVG.
> No cluster differences.
> Makefile
> gs/configure.ac
> svg/ghostsvg.h
> svg/svg.mak
> svg/svg_gcc.mak
> svg/svg_msvc.mak
> svg/svgcolor.c
> svg/svgcolorlist.h
> svg/svgdoc.c
> svg/svgshapes.c
> svg/svgtop.c
> svg/svgtransform.c
> svg/svgtypes.c
> svg/svgxml.c

2014-03-09 15:54:06 +0000
Chris Liddell <chris.liddell@artifex.com>
8dacc34a50174bceac7786ce47466d9a71547955

> Remove SVG writer from Ghostscript/GhostPDL
> No cluster differences.
> gs/Makefile.in
> gs/configure.ac
> gs/devices/devs.mak
> gs/devices/vector/gdevsvg.c
> gs/psi/msvc.mak

2014-03-06 11:57:00 -0800
Ray Johnston <ray.johnston@artifex.com>
22ebcc33db33aa15399a6836e48953736256eb41

> Fix UseFastColor during clist playback.
> Discovered with customer 532, the default_match was not set early
> enough in gsicc_get_link for the index to be correct, effectively
> disabling usefastcolor mode. As a result images could be rendered
> with ICC based color transform instead of the 'nocm' fastcolor
> methods.
> gs/base/gxclimag.c
> gs/base/gxclist.h
> gs/base/gxclrast.c

2014-03-08 20:29:30 +0000
Chris Liddell <chris.liddell@artifex.com>
f5457548e8162438a43b1aeb2040e34c001adaa4

> Use malloc/free for lcms(2) shared lib build.
> No cluster differences.
> gs/base/gsicc_lcms.c
> gs/base/gsicc_lcms2.c
> gs/base/lcms.mak
> gs/base/lcms2.mak

2014-03-07 17:00:28 +0000
Ken Sharp <ken.sharp@artifex.com>
58121374ed0d12aa38c872eb4d069b75ed5875d5

> cast to silence a compiler warning
> gs/base/gdevvec.c

2014-03-07 13:41:01 +0000
Ken Sharp <ken.sharp@artifex.com>
94c5ecffe4bf66cc91108d99a802c7c2d3b86e0b

> PS interpreter, vector devices and pdfwrite - remove setdash limit of 11
> Bug #693916 "setdash does not accept more than 11 elements in the array argument"
> The PostScript interpreter was already capable of this, it simply required
> the limit check to be removed. The vector device needed to allocate and
> free an array of floats, rather than maintain a fixed size array.
> pdfwrite was teh most complex as it maintains a stack of gstates, and these
> also needed to be modified to allocate and free the dash array. However the
> gstate stack wasn't already a garbage collecting structure. Rather than going
> to the effort of turning it into one I've opted to allocate the dash pattern
> from non-gc memory.
> A few PCL files show differences with pdfwrite, because previously pdfwrite
> would throw an error (more than 11 elements in the dash array) and the stroked
> lines would degenerate into filled rectangles, whereas now they are drawn as
> stroked lines with a correct dash pattern. This is much more efficient.
> The clist remains unmodified, Ray assures me that it will be handled there
> without problems.
> gs/Resource/Init/gs_init.ps
> gs/base/gdevvec.c
> gs/base/gdevvec.h
> gs/devices/vector/gdevpdf.c
> gs/devices/vector/gdevpdfg.c
> gs/devices/vector/gdevpdfx.h

2014-03-05 09:47:52 -0800
Ray Johnston <ray.johnston@artifex.com>
4b16c45c3b834efb9ff9608360d3c053e91b1f23

> Fix UseFastColor ignored for pages with transparency.
> Found when researching problem from customer 532.
> gs/base/gdevp14.c

2014-03-03 12:21:12 -0800
Ray Johnston <ray.johnston@artifex.com>
e63f9d066c001052f5594f09c3a3a59ff80d2d03

> Fix problem with -d***Values=16 and bitrgb device.
> The max_gray and max_color would confuse the gx_device_must_halftone
> macro because setting -dGrayValues=16 would end up setting the
> max_gray and max_color to 31 (0x1f) which does NOT halftone. with
> the change setting to 16 values doesn't change the bpc if put_params
> is called again. Also remove allowing -dGrayValues=32 from supported
> choices.
> gs/devices/gdevbit.c

2014-03-05 08:54:56 +0000
Ken Sharp <ken.sharp@artifex.com>
b442d9a0c193d2d0114e72e1312e7bcc6e558aab

> pdfwrite revert 3894e9c8a3ab125c82048da3bf81515500bb2da0
> Bug #695083 " Regression: pdfwrite DEVICE generates extra page with -dLastPage= option"
> This wasn't a customer bug report, and it doesn't work well with PCL, when
> specifying -dLastPage, so I've decided just to revert it.
> A very few PCL files are flagged by the cluster as different, but there are
> no bmpcmp diffs.
> gs/devices/vector/gdevpdf.c

2014-03-03 17:34:08 +0000
Robin Watts <robin.watts@artifex.com>
9a68412d171e5c998026a13dffcbc90ef9d477b9

> Bug 695007: Fix problems with unicode chars in TEMP path.
> If there are unicode chars in the temporary path (either that
> given by TMPDIR, TEMP or windows own GetTempPath functions)
> when opening a scratch file, we mishandle them.
> This commit improves the behaviour to treat paths consistently
> as UTF8.
> This incorporates changes from Paul Gardiner to make the winrtsup.cpp
> functions use wide chars. This simplifies the functions and integrates
> better with the calling code. Also fix some uses of sizeof where size
> in chars was required.
> gs/base/gp_mswin.c
> gs/base/winrtsup.cpp
> gs/base/winrtsup.h

2014-03-04 10:24:47 +0000
Paul Gardiner <paulg-artifex@glidos.net>
f29e49d4b157a84b4793eda614447811b471c047

> Fix pointer-usage bug in GetTempFileNameWRT
> gs/base/winrtsup.cpp

2014-03-04 15:30:02 +0000
Ken Sharp <ken.sharp@artifex.com>
5b2adda7468241123d9559a98cd469f527dd7e3c

> pdfwrite - do not apply the 'Default*' colour spaces
> Noticed while testing by Chris.
> The PDF spec says that if any of DefaultGray, DefaultRGB or DefaultCMYK are
> present in a PDF page, then we should use those to do a conversion to
> device-independent colour space for colours specified in the matching Device*
> space.
> This is broadly equivalent to the UseCIEColor PostScript user parameter but
> unlike that parameter the user has no control over it. Previously we applied
> this conversion but it seems unreasonable to do this for pdfwrite as this
> will convert a PDF using device spaces into a PDF using ICCBased spaces.
> Accordingly we now test the device properties and for HigLevel devices we
> do *not* perform this conversion.
> If the conversion really is desired then setting -dUseCIEColor will perform it.
> This results in a very few files showing differences, neither progressions
> nor regressions, merely different. However the pdfwrite warning about use
> of UseCIEColor does go away.
> gs/Resource/Init/pdf_main.ps

2014-03-04 09:25:18 +0000
Chris Liddell <chris.liddell@artifex.com>
2621110f37eb0c94a732578acd24634caec1c25b

> Bug 694832: add an explicit flag for TTF notdef
> The previous solution for this issue "overloaded" an existing workaround for
> pdfwrite. Unfortunately, a clash between pdfwrite's needs and FAPI's meant it
> did not work all the time.
> So, when loading a TTF for use in a PDF, add a new flag to the font dictionary
> to tell the FAPI code whether to render a Truetype notdef.
> Several differences show up on the cluster - the following are progressions
> compared to Acrobat:
> Bug689757.pdf
> Bug691031.pdf
> Bug691221.pdf
> Bug693538.pdf
> Bug693646.ps
> Bug693711.pdf
> keyboard.pdf
> CATX1490.pdf
> IA3Z0815.pdf
> These are different from before, but since Acrobat can't even open these,
> I don't much care:
> 207ee6f24411fc4591d2b5a337c46de8-full.pdf
> 2123_-_MacExpertEncoding_badly_handled.pdf
> 764_-_heading_garbage.pdf
> gs/Resource/Init/gs_ttf.ps
> gs/psi/zfapi.c

2014-03-04 09:49:52 +0000
Ken Sharp <ken.sharp@artifex.com>
0214c1b9c70cd41026e5cda707e582b32489a64c

> remove a misleading comment
> gs/devices/vector/gdevpdfu.c

2014-03-04 09:47:50 +0000
Ken Sharp <ken.sharp@artifex.com>
095ae57e266ee5168f042c26dd2e9d12273efb28

> ps2write - fix missing %%BeginResource comment for FontFile objects
> Bug #695082 " ps2write: Some "%%BeginResource" DSC comments have only one "%" character"
> FontFile streams were being written with a "%%EndResource" comment, but the
> "%%BeginResource" comment was missing.
> No differences expected
> gs/devices/vector/gdevpdfu.c
> gs/devices/vector/gdevpdfx.h
> gs/devices/vector/gdevpdtd.c

2014-03-03 14:14:19 +0000
Ken Sharp <ken.sharp@artifex.com>
649848310dd4f9400f63c685748e4f76344ba9d7

> ps2write - fix a DSC comment
> Bug #695082 "ps2write: Some "%%BeginResource" DSC comments have only one "%" character"
> A DSC comment was emitted using a printf format string without escaping the
> "%"s
> No differences expected.
> gs/devices/vector/gdevpdtd.c

2014-02-27 11:28:57 +0000
Ken Sharp <ken.sharp@artifex.com>
f6abeac1c7ab3ee82523353b5373230e2607c0b9

> pdfwrite - fix commit 1d1d22976ce5b5e96d862c404ca80f189476bfed
> Despite not throwing any regressions, there was a bug in this commit.
> A couple of places used the pprintld* routines, which *don't* accept the
> %"PRId64" sequence and this led ot us writing an invalid xref.
> Fixed here by using gs_sprintf instead.
> gs/devices/vector/gdevpdf.c

2014-02-27 09:33:13 +0000
Ken Sharp <ken.sharp@artifex.com>
1d1d22976ce5b5e96d862c404ca80f189476bfed

> pdfwrite - fix FastWebView for big-endian devices
> Bug #695075 " Creating "optimized" PDF on Big-endian OS gives errors when view the PDF indicating PDF is not right"
> This commit applies all the changes supplied by Jonathan Dagresta of SDL,
> see the bug report for details.
> No differences expected.
> gs/devices/vector/gdevpdf.c

2014-02-26 10:38:02 -0800
Ray Johnston <ray.johnston@artifex.com>
30f2c656469f5930b1adc82454706743df68b0d7

> Disable threshold array based image optimization for depth > 1.
> The monochrome image case in gximono.c already checked for depth == 1
> but the gxicolor.c code was missing this. These can be removed when
> the gxht_thresh.c code is enhanced for greater bit depths.
> gs/base/gxicolor.c

2014-02-26 09:20:37 +0000
Ken Sharp <ken.sharp@artifex.com>
b53c81e38925d05b00ba9068aebc5fcbc519a685

> ps2write - add a feature to customise the output for specific devices
> Bug #695070 "Customer would like a way to specify printer specific features in ps2write device"
> This commit adds two new distiller params, specific to ps2write, PSDocOptions
> and PSPageOptions, which are described in detail in the ps2ps2.htm document.
> These allow an end user to specify PostScript (normally device-specific
> configuration) which can be injected into a DSC compliant file at the documet
> level and at the individual page level.
> No differences expected
> gs/Resource/Init/gs_pdfwr.ps
> gs/devices/vector/gdevpdf.c
> gs/devices/vector/gdevpdfb.h
> gs/devices/vector/gdevpdfu.c
> gs/devices/vector/gdevpsdf.h
> gs/devices/vector/gdevpsdp.c
> gs/doc/Ps2ps2.htm

2014-02-23 09:46:21 -0800
Ray Johnston <ray.johnston@artifex.com>
77fce4a0cfd70b94a90a876cac0310fda1a969ee

> Fix bug 695054, segfault caused by stale pointer in pattern-clist device.
> The pattern-clist device could be left allocated in stable memory
> after the pattern was removed from the pattern cache. The pattern
> instance could be freed by a subsequent restore since it was not
> in stable memory. GC trace of the chunks would then reference the
> stale pinst pointer. Also, the heap pointer needs to be valid in
> ialloc_validate_spaces 'state' since it can be used for error output
> and this could cause a segfault.
> gs/base/gxpcmap.c
> gs/psi/ilocate.c

2014-02-24 10:41:23 -0700
Henry Stiles <henry.stiles@artifex.com>
9990bdac31c018de33de2c09053b7e392a26304f

> Fix Bug 694685 - Seg faults found by fuzzing in sfopen.
> PCL would continue processing with a corrupt font. This could lead to
> bad memory accesses as demonstrated by the fuzzing example. For now,
> we return an error when a corrupt font is encountered and end the job.
> Likely, a lighter approach is called for: continue process without
> defining the font. This would be a bit more involved and we'll
> consider it if users report HP precedent for the behavior.
> pcl/pcsfont.c

2014-02-24 15:14:45 +0000
Ken Sharp <ken.sharp@artifex.com>
b6f8dba649f1be2ba5b9eb1d257f2052f7f2df28

> Move ram file system memory to 'stable' memory
> The RAM file system was using regular GC'ed memory for its storage, which is
> subject to save and restore. The RAM file system should not, of course, be
> subject to save and restore!
> This commit prevents save and restore affecting the memory for the ramfs
> No differences expected.
> gs/base/ramfs.c

2014-02-14 18:16:55 +0100
Simon Bünzli <zeniko@gmail.com>
863a1dfb328298a39871e49d218a16781fd42cba

> Bug 694880 and bug 694904: prevent heap overflow in opj_j2k_add_tlmarker
> Signed-off-by: Henry Stiles <henry.stiles@artifex.com>
> gs/openjpeg/libopenjpeg/j2k.c

2014-02-14 18:20:36 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
b17894bfedaf7b76edac15f681a4bd08717c65c0

> Bug 694906: fix potential heap overflow in opj_t2_read_packet_header
> Signed-off-by: Henry Stiles <henry.stiles@artifex.com>
> gs/openjpeg/libopenjpeg/t2.c

2014-02-18 09:36:09 +0000
Chris Liddell <chris.liddell@artifex.com>
7bd3739a888f70edf0270891782a88a547f5e829

> Make the OpenJPEG callbacks static.....
> and give them names more likely to be unique (just for debugging convenience).
> No cluster differences.
> gs/base/sjpx_openjpeg.c

2014-02-18 11:22:16 -0800
Ray Johnston <ray.johnston@artifex.com>
174cfd14e4d34a37cdcf2e0372bd0b4334310e8b

> Fix pngalpha when PDF has transparency. Bugs 687630, 693024 and 695042.
> We needed a pngalpha_put_image procedure to properly collect the pdf14
> compositor alpha value. Note that this is NOT simple 0 or 1 alpha, but
> the actual effective page level opacity from the PDF. Note that some
> viewers may not correctly display these despite this being part of
> the PNG spec.
> gs/devices/gdevpng.c

2014-02-15 13:54:07 -0800
Ray Johnston <ray.johnston@artifex.com>
b69da60516576d65ce1e27087dc358fef067ec58

> Fix bug 695405. The psdcmykog device should not lock num_components.
> This regression was introduced with an attempt to fix SeparationOrder
> handling, but is not needed because we throw an error when there is
> an attempt to set the SeparationOrder, and the device is confused
> when the num_components is reset in the open_device procedure.
> gs/devices/gdevcmykog.c

2014-02-11 08:07:04 -0800
Ray Johnston <ray.johnston@artifex.com>
3ebdb4596c8fa05656dc3987553217efe72b6b8d

> Improve chunk allocator performance using a doubly linked list (bug 694985)
> Thanks to Norbert Janssen for the linked list logic. Also make a couple
> of other improvements in the free_object logic and use a separate
> structure for the freelist to avoid confusion with object nodes.
> gs/base/gsmchunk.c

2014-02-14 14:07:11 +0100
Tor Andersson <tor.andersson@artifex.com>
c5ad5b7f373313e9bc7b8991cc9e34506e627e0a

> xps: Fix memory leaks in xpszip.c when handling errors.
> Thanks to Norbert Janssen.
> xps/xpszip.c

2014-02-14 10:12:28 +0000
Ken Sharp <ken.sharp@artifex.com>
1e93c580b175ac086db942c32fab055c6062e8e4

> ps2write - more colour conversion work
> Bug #694774
> When outputting to PostScript we don't preserve certain colour spaces which
> either cannot be represented in PDF (CIEBased) or in level 2 PostScript
> (ICCBased/Lab/DeviceN) are not preserved. These should be written as device
> colours instead, but this wasn't always happening correctly.
> This commit should resolve this, and should now make it possible (but still
> inadvisable) to use -dUseCIEColor with both pdfwrite and ps2write.
> A small number of files show (frankly imperceptible) colour shifts with
> ps2write with this change.
> gs/devices/vector/gdevpdfc.c
> gs/devices/vector/gdevpdfg.c

2014-02-13 14:49:42 +0000
Chris Liddell <chris.liddell@artifex.com>
edbed246ed67fcf24f854795f0d703bcb5d902fe

> Bug 695027: use a consistent allocator in the FT server
> There was some mixing of memory allocators in the Freetype integration code,
> most of the code used the chunk allocator instance created during the
> server initialization, but glyph data allocations were using the allocator from
> the font object.
> With two different FAPI servers in place, and with the right combination of
> events, that could mean we'd lose the allocator pointer when destroying
> the font object.
> We're consistent in that all the memory allocations in the FAPI/Freetype code
> are directed through the chunk allocator created for that purpose.
> No cluster differences.
> gs/base/fapi_ft.c

2014-02-13 14:47:18 +0000
Chris Liddell <chris.liddell@artifex.com>
979d824c9da11e9f366b1d90aed06f9449127997

> Bug 695024: fix a typo
> In the UFST integration code, we check if the Freetype server is available
> and if it is, we punt any non-Microtype fonts to that. The typo is that
> the Freetype server is named "FreeType" - the "T" was lower case.
> CLUSTER_UNTESTED
> gs/base/fapiufst.c

2014-02-13 15:14:49 +0000
Ken Sharp <ken.sharp@artifex.com>
4d349b1ae5852db20fcaca21b357748eb5360817

> Bug #695034 Improve handling of word spacing with CIDFonta
> Bug #695034 "Numbers and words are overlapping"
> Word spacing does not apply to ti CIDFOnts, *except* for 1-byte mappings
> where the byte 0x20 has word spacing applied to it.
> The previous code attempted to check this by using a heuristic to determine
> a single byte mapping in order to avoid adding more entries to the text
> enumerator. unfortunately this file defeats that heuristic which meant
> that it was necessary to calculate the number of bytes decoded when we
> extract one character, and store that information so that the 'move'
> routine can apply word spacing if required.
> This shows two differences with a cluster run. Bug694436.pdf is very subtly
> different, I'm assuming this is a progression. The Sumatra file
> 850_-_wrong_default_for_asian_fonts.pdf shows very significant improvements
> with this commit.
> gs/base/gxchar.c
> gs/base/gxtext.h

2014-02-11 15:15:56 +0000
Chris Liddell <chris.liddell@artifex.com>
f4584b0e162a96ec143f0057de63c116e649e02b

> Bug 695031: don't assume we can read a font file
> When we scan system fonts, we were assuming fonts found would be in a format
> Ghostscript understands. This is not necessarily the case.
> So put the minimal parsing call to get the font's name in a stopped context,
> so we can skip the file it's not an understandable format. And clean up the
> stack in the event we try such a file.
> No cluster differences.
> gs/Resource/Init/gs_fonts.ps

2014-02-11 12:14:33 -0800
Michael Vrhel <michael.vrhel@artifex.com>
149b4b33c909c2d67c44c7a820f70209294bee76

> Don't allow PS CIE color spaces to be used for transparency group color spaces.
> The CIE color spaces are 1-way. In that they map from Device to CIE, not from
> CIE to Device. A transparency group color space needs to be able to go both
> directions. This fixes the regression 694774
> gs/base/gsicc_cms.h
> gs/base/gsicc_lcms2.c
> gs/psi/int.mak
> gs/psi/ztrans.c

2014-02-11 11:18:39 -0700
Henry Stiles <henry.stiles@artifex.com>
c22a604f0dc176fe1ae7545097e8a818e5d38309

> Remove final remnants of deprecated CRD code.
> pcl/pccid.c
> pcl/pcl.mak
> pl/pl.mak
> pl/plsrgb.c
> pl/plsrgb.h
> pxl/pxgstate.c
> pxl/pximage.c
> pxl/pxink.c
> pxl/pxl.mak
> pxl/pxsessio.c

2014-02-11 08:07:04 -0800
Ray Johnston <ray.johnston@artifex.com>
c240594f3083158ab829cd121159879183bf49c8

> Improve the debug 'cname' for chunk_mem_node_add similar to MEMENTO builds.
> For normal builds use the caller's cname when allocating the chunk if the
> object is in its own chunk. Previously this only was used for MEMENTO builds.
> NB: MEMENTO builds put every object in a chunk, so the cname will always be
> the caller's, never "chunk_mem_node_add".
> gs/base/gsmchunk.c

2014-02-09 11:48:35 -0800
Ray Johnston <ray.johnston@artifex.com>
0eaf9e76f83eff5d0dd5eb1f8d9a5314b9ca44cd

> Fix bug 694821. Ignore SeparationOrder with the psdcmykog device.
> While this is a DeviceN device with some non-standard components
> that can be painted using Separation or DeviceN colorspaces, this
> device always outputs all 6 channels and can't deal with a subset
> of the channels, so return an error (undefined) for SeparationOrder.
> the separation_map remains constant to avoid color distortion if
> SeparationOrder is used.
> Also make sure that we never add separations (NO_AUTO_SPOT_COLORS)
> from the get_color_comp_index procedure.
> gs/devices/gdevcmykog.c

2014-02-07 18:13:52 -0800
Ray Johnston <ray.johnston@artifex.com>
a11848051b9abdbe2b750976018d4167a96d2fea

> Fix some problems with SeparationOrder handling -- 29-07I.PS
> Most importantly, when setting SeparationOrder parameters fail, we
> need to use param_signal_error. Otherwise, even though the error code
> is returned, the stack for setpagedevice would be missing the param
> information and code that caused the error.
> Also the num_spot and num_spot_changed were improperly updated when
> ENABLE_AUTO_SPOT_COLORS allowed SeparationOrder to add separations.
> gs/base/gdevdevn.c

2014-02-11 09:33:13 +0000
Ken Sharp <ken.sharp@artifex.com>
f176e516add62d3a943a755a9294c510c579655d

> pdfwrite - fix a bug in the font embedding white list detection
> While working on bug #695030 I ran across a bug in the font embedding
> white list code. If the bisection of the list exactly hits the target string
> exactly then the bisection would fail to find the string.
> This commit special cases this and detects the string.
> No differences expected.
> gs/devices/vector/whitelst.c

2014-02-10 11:17:01 +0000
Ken Sharp <ken.sharp@artifex.com>
fac814792b42dfc2baafe84062ff986b7620cfe3

> pdfwrite - alter the example pdfa_def.ps for PDF/A generation
> The pdfa_def.ps file is incorrect with the new colour handling, and has long
> had a problem with only handling Gray or CMYK.
> Its no longer possible to retrieve the ProcessColorModel from systemdict,
> we must now use the current device dictionary.
> pdfa_def.ps now supports DevuiceGray, DeviceRGB and DeviceCMYK models.
> No differences expected
> gs/lib/PDFA_def.ps

2014-02-10 11:14:31 +0000
Ken Sharp <ken.sharp@artifex.com>
e17abc0e4574cdefd25032aa1003ff28503b5867

> pdfwrite - new color code. Fix the emission of DeviceIndependent colours
> Bug #694806 "chars and colors lost during PDF/A transformation"
> If we used the same device independent (ICCBased) colour space, but a
> different colour, we ended up not writing the new colour. This code fixes
> that problem.
> No differences expected
> gs/devices/vector/gdevpdfg.c

2014-02-10 08:34:54 +0000
Ken Sharp <ken.sharp@artifex.com>
d59e1feb9545b399027907cb2d1a6855c524e0b4

> PS interpreter - Fix rotation problem with EPSFitPage
> Bug #695016 "Gradient eps file to pdf"
> When fitting an EPS Bounding Box to a specified page size, the code looks
> at the width and height of both the page and the EPS file, to see if the
> EPS will fit 'better' by rotating it.
> In this particular case the page is square, but there was no special case
> for this, which mean that landscape pages wold be rotated twice, causing
> the content to disappear.
> This commit special cases square media sizes and does not attempt to rotate
> the EPS, no matter what its orientation, as there is clearly no point in
> doing so. This prevents the double rotation and resolves the problem.
> Tested with landscape, portrait and square media and EPS files, in all
> combinations.
> No differences expected
> gs/Resource/Init/gs_epsf.ps

2014-02-06 09:56:43 -0800
Ray Johnston <ray.johnston@artifex.com>
dc3770910997a17386c65eaa44e73cf7cf5e8339

> Fix Windows display device -dDisplayFormat=16#a0800 regression.
> Commit 82fc3bd change to msvc.mak removed setting the GX_COLOR_INDEX_TYPE,
> and code in base/gxcindex.h set this incorrectly to 'ulong'. Add the code
> that was removed and also add conditional compile to set this from
> ARCH_SIZEOF_GX_COLOR_INDEX if it is not defined.
> Also add a 'compile time assert' that causes the build to fail if the
> sizeof(GX_COLOR_INDEX_TYPE) is not equal to ARCH_SIZEOF_GX_COLOR_INDEX.
> Thanks to Robin for finding this trick on the web.
> gs/base/gxcindex.h
> gs/base/lib.mak
> gs/psi/msvc.mak

2014-02-06 09:53:55 +0000
Ken Sharp <ken.sharp@artifex.com>
ab3faf9dd8b61b7adc83f370e8caf40f09a442bb

> pdfwrite - improved error handling in pdf_close
> Bug #695013 " GS not finishing pdf write, creating huge files, when root / partition is full"
> we weren't checking the error return when trying to find the end of an
> xref section while writing the xref. Any ioerror would havce caused this
> problem.
> While this fixes the specific instance of the problem, I can't guarantee
> that more subtle problems (eg filling disk while writing the PDF file)
> don't still exist.
> No differences expected.
> gs/devices/vector/gdevpdf.c

2014-02-05 14:19:59 +0000
Ken Sharp <ken.sharp@artifex.com>
ff033b6ec050f23cb7b1e6ff52bb48fb45afd9e3

> Update jbig2dec standalone build for Windows.
> Add the missing jbig2_halftone.c file, and make building without libpng
> the default.
> CLUSTER_UNTESTED
> gs/jbig2dec/msvc.mak

2014-02-04 13:35:04 -0800
Michael Vrhel <michael.vrhel@artifex.com>
a75ff89833289614e0dc2476c822462670f822bc

> Remove strdup in gdevxps.c .
> In Windows 8 64 bit builds with VS2012/2013 strdup use resulted in a crash. Replaced
> with standard strlen/gs_alloc_bytes/strcpy. Note that we need to free this allocation at some point.
> gs/devices/vector/gdevxps.c

2014-01-23 09:53:23 +0000
Chris Liddell <chris.liddell@artifex.com>
8033bcb40edf7520682cb14ee41226eddf9c8e5e

> Tweak xpsprint build.
> Conflicts:
> gs/base/msvctail.mak
> gs/base/winlib.mak
> gs/devices/vector/gdevxps.c
> Tweak the xpsprint code to use runtime DLL loading
> Conflicts:
> gs/base/msvctail.mak
> gs/base/msvctail.mak
> gs/base/winlib.mak
> gs/base/xpsprint.cpp
> gs/devices/devs.mak
> gs/devices/vector/gdevxps.c
> gs/psi/msvc.mak

2014-01-21 12:01:41 +0000
Ken Sharp <ken.sharp@artifex.com>
d10c375e190876fef3f431e17c47dcacda03d567

> Add new code for a 'gsprint' alike which uses the XPS print system on
> WIndows
> Add new code for a 'gsprint' on new versions of Windows, using XPS
> gs/base/xpsprint.cpp
> gs/devices/vector/gdevxps.c

2014-02-03 07:18:16 -0800
Ray Johnston <ray.johnston@artifex.com>
4eb758e74c73c03b113ba2bf73245f21b1c6de14

> Fix writes to freed memory caused by commit 429640.
> I had moved the clearing of the ctx to before the gs_malloc_release
> call, but this function frees the ctx, so we wrote to freed memory.
> Move it back.
> gs/psi/iapi.c

2014-01-31 12:24:25 -0800
Ray Johnston <ray.johnston@artifex.com>
363f3bc0d3b6206cc1e0aff0ce2fe954c0295409

> Fix bug 694994. Gray and CMYK pdf14 clist accumu devices had wrong color_info.
> In cut and pasting the device structures, I negleccted to change the color
> info for the macros.
> gs/base/gdevp14.c

2014-02-01 12:10:22 +0000
Ken Sharp <ken.sharp@artifex.com>
2f2970c2a35a146f21631612adfca48a0b1bb2b3

> PDF interpreter - disable Comment parsing for PDF files
> Bug #694987 "PDF metadata messed up for PDF->PDF conversion"
> This is caused by parsing DSC comments from an embedded font file. Of course
> the font should not contain DSC comments, but it seems FontForge always
> embeds such.
> There is nothing useful to be gained from *PostScript* comments in a PDF
> file, so the simplest solution is to disable comment parsing for the
> duration of the PDF file.
> This will also avoid problems with PostScript XObjects.
> No differences expected
> gs/Resource/Init/pdf_main.ps

2014-01-31 15:08:17 +0000
Chris Liddell <chris.liddell@artifex.com>
161559d289a9b4306673c7d7e089182670c5090a

> Slightly rejig i/o in inkcov device.
> Tweak so that output directed to stdout or stderr go through the graphics
> library's own stdout and stderr handlers - that way, it can be seen by
> integrators using the Ghostscript API with custom stdio handler methods.
> No cluster differences.
> gs/base/gdevprn.c
> gs/base/gslibctx.h
> gs/devices/gdevicov.c

2014-01-31 14:50:55 +0000
Ken Sharp <ken.sharp@artifex.com>
7ef7b0d503fee02da12430ee19a394b23b1bfa6f

> pdfwrite - colour conversion, consider sRGB to be RGB
> gs/devices/vector/gdevpdfg.c
> gs/devices/vector/gdevpdfi.c
> gs/devices/vector/gdevpdfp.c

2014-01-31 09:42:38 +0000
Ken Sharp <ken.sharp@artifex.com>
a2a785d3f6111410198c396fe21813ddd41664be

> PDF interpreter - add -dUseBleedBox to complete the quartet of Boxes
> Bug #694977 "please provide -dUseBleedBox in analogy to crop- and trimbox"
> gs/Resource/Init/pdf_main.ps
> gs/doc/Use.htm

2014-01-31 08:19:31 +0000
Ken Sharp <ken.sharp@artifex.com>
6c4e66f6a7a1e9fc3ed3beff84549aa3bbbbe795

> pdfwrite - remove 2 unused variables
> silences compiler warnings
> gs/devices/vector/gdevpdfm.c

2014-01-30 11:08:55 -0800
Ray Johnston <ray.johnston@artifex.com>
429640b32e1ffcd324c2b44daa1fb35ef41c01d4

> Move final memory (max) usage to gs_malloc_release.
> Not all systems (e.g. unix) use the gsapi interface, so the debug
> -Z: didn't print the final memory usage as on Windows.
> gs/base/gsmalloc.c
> gs/psi/iapi.c

2014-01-30 15:32:23 +0000
Ken Sharp <ken.sharp@artifex.com>
ea83541f7fcc1af40cf62f0e7457df74e8b427c4

> pdfwrite - more EMBED pdfmrk changes
> commit 3e5ae4ea39655643ae352cf4723702a164c10417 omitted a crucial change
> which swapped the search order of /FS and /Name. Without that the dict
> entries are not correctly named.
> This oversight demonstrated a flaw in the error handling resulting in invalid
> PDF files being written, which we correct here. If we get an error we close
> the 'aside' so that we don't end up writing the PDF trailer to a temporary
> file instead of the real PDF file.
> No differences expected
> gs/devices/vector/gdevpdfm.c
> gs/devices/vector/gdevpdfo.c

2014-01-30 10:00:23 +0000
Ken Sharp <ken.sharp@artifex.com>
3e5ae4ea39655643ae352cf4723702a164c10417

> pdfwrite - more work on /EMBED pdfmark
> As was rather anticipated, commit a91d2576df0e60f6e691a3bd967b51109ae41f22
> wasn't sufficient. We were writing an invalid name tree as we were writing
> /Limits in the root node. For single entries in the Limits array we only
> wrote the single entry, in fact we should write that entry twice (!). The
> value associated with each key in the EmbeddedFiles array had the dictionary
> we needed stored inside another dictionary with a /FS key. EmbeddedFiles
> were introduced in PDF 1.4, not PDF 1.2.
> This commit addresses all those problems, Adobe Acrobat Professional can
> display the list of embedded files and (for embedded PDF files at least)
> can open the embedded file.
> gs/devices/vector/gdevpdf.c
> gs/devices/vector/gdevpdfm.c
> gs/devices/vector/gdevpdfo.c

2013-11-26 11:15:17 -0800
Ray Johnston <ray.johnston@artifex.com>
4e44c995bcc7a2aa6c32e23cb73fd532a93f5b1c

> Fix bug 689805: Use a clist for pages with transparency that need lots of RAM
> Devices that are not gx_device_printer class try to allocate full page bitmaps
> for the stack of transparency buffers. This can kill performance or result in
> VMerror during transparency stack pushes. Devices that are gx_device_printer
> class automatically used clist mode, but other devices did not. Devices that
> do not internally support clist mode are recognized by the return from
> gxdso_supports_saved_pages device spec_op.
> A gx_device_printer device is used to accumulate the page, then when the
> PDF14_POP_DEVICE is performed, the page is sent to the original device
> as an image.
> NB, both the pdf14clist___ device and the pdf14___ device are kept in the
> device chain since we have to be able to accomodate unwinding the gs_state
> structure that may point to either as various "restore" ops occur.
> Unfortunate, but until we come up with a way to fix the chain of compositors,
> this is the best we can do.
> Move space_params to gx_device struct in order to allow non-printer devices
> control over MaxBitmap, BufferSpace, BandBufferSpace, and BandHeight. The x11
> device used MaxBitmap somewhat differently, so it now uses the space_params
> value, and sets the default in its 'open' function, rather than the device
> prototype. The duplicate 'page_uses_transparency' in space_params is removed,
> and all devices have this as a parameter.
> Also, get rid if the nasty hacks for detecting pattern-clist devices based on
> the device name, and export these for the pdf14 device and other clients.
> Finally, (unrelated) remove the #if 0 for testing with small memory on
> large memory machines, and get rid of the the description of the '.' option
> since this hasn't worked for years, and the command line options can readily
> be set anyway.
> gs/base/gdevp14.c
> gs/base/gdevprn.c
> gs/base/gdevprn.h
> gs/base/gsdparam.c
> gs/base/gsptype1.c
> gs/base/gsstate.c
> gs/base/gstrans.c
> gs/base/gxband.h
> gs/base/gxclbits.c
> gs/base/gxclimag.c
> gs/base/gxclist.c
> gs/base/gxclist.h
> gs/base/gxclpage.c
> gs/base/gxclrast.c
> gs/base/gxdevcli.h
> gs/base/gxdevice.h
> gs/base/gxpcmap.c
> gs/base/gxpcolor.h
> gs/base/lib.mak
> gs/devices/gdevbit.c
> gs/devices/gdevplib.c
> gs/devices/gdevx.c
> gs/devices/gdevx.h
> gs/devices/gdevxini.c
> gs/doc/Use.htm

2014-01-29 17:32:04 +0000
Ken Sharp <ken.sharp@artifex.com>
a91d2576df0e60f6e691a3bd967b51109ae41f22

> pdfwrite - enable the EMBED pdfamrk
> Bug #690043 "Can't create a pdf file with attachment"
> This turned out to be more complex than I expected. I had planned to lever
> off the /Dests code, but....
> It seems that our Named destinations support is only PDF 1.1. The specification
> was changed ion PDF 1.2 to use a name tree instead of a simple dictionary
> and we didn't alter our code. The EmbeddedFiles wasn't supported in PDF 1.1
> so it has always needed a name tree.
> So in addition to adding the EMBED pdfmark, we now also will write a name
> tree for Dests if the CompatibilityLevel is > 1.1. Note that the 'tree'
> we write is the simplest possible one and is likely to be sub-optimal, we
> write all the entries in the root of the tree. However its legal and should
> work, we can extend this later if needs be.
> I don't have a good way to test this, but the output looks OK by inspection
> and we don't get any regressions.
> gs/devices/vector/gdevpdf.c
> gs/devices/vector/gdevpdfb.h
> gs/devices/vector/gdevpdfm.c
> gs/devices/vector/gdevpdfo.c
> gs/devices/vector/gdevpdfo.h
> gs/devices/vector/gdevpdfu.c
> gs/devices/vector/gdevpdfx.h

2014-01-29 13:07:34 +0000
Robin Watts <robin.watts@artifex.com>
2dae08db5c51c9a255b8d18ef011f75c4ee48e9f

> Fix non gcc DEBUG builds of pcl.
> Simple transposition of lines required.
> pcl/pcsfont.c

2014-01-28 17:21:48 +0000
Ken Sharp <ken.sharp@artifex.com>
f471820635cbbaf4f7ed5c9185700ebb51378f0d

> PDF interpreter - attempt to recover from degenerate text matrix or CTM
> Some PDF files set a degenerate matrix or text matrix, eg
> 0 0 0 0 0 0 Tm
> This causes us a problem with currentpoint and .getpath, both of which
> need to invert the CTM. If the CTM is all 0 then it (clearly) can't be
> inverted.
> The code here emits a warning, in the case of settextposition it simply
> does not advance the current point (which seems correct, since the text
> will make no changes). In the case where we attempt to grestore (Q) but
> preserving the current path, we drop the path and make a new path. This
> may well not be correct, but its hard to see what would be.
> No differences expected.
> gs/Resource/Init/pdf_ops.ps

2014-01-23 09:17:31 +0000
Ken Sharp <ken.sharp@artifex.com>
e46be795d1a682259ebcca3df2ad581150414adf

> epsi.ps - change two \r to \n
> Apparently gv has a bug and can't handle \r line endings.
> Bug #694968
> No differences expected.
> gs/lib/ps2epsi.ps

2014-01-23 09:09:48 +0000
Ken Sharp <ken.sharp@artifex.com>
03376079a8c05dd2224c057aaa95c508521ce784

> vector devices - add a warning message when OutputFile exceeds a limit
> Bug #694948
> No differences expected.
> gs/base/gdevvec.c

2014-01-11 16:53:48 +0000
Hin-Tak Leung <hintak@ghostscript.com>
49bb8200d6c92ddcd191026c0273f8bc229ad9e0

> Bug 694873: bare JPEG2000 images without JP2 header in pdf.
> To cope with JPEG2000 images without JP2 headers.
> This change is essentially the corresponding change in mupdf
> (https://code.google.com/p/sumatrapdf/issues/detail?id=937 ,
> http://bugs.ghostscript.com/show_bug.cgi?id=691346 ,
> test file 937_-_openjpeg_cannot_decode_JP2_structure.pdf),
> where one takes a peek at the first few bytes of the stream
> before setting the decoding parameters; with the caveat that
> in ghostcript, we need to delay most of the stream
> initialization - and allocation of resources - until
> after seeing the first few bytes, and therefore also
> not necessarily de-allocate at stream close.
> The cluster test file, openjpeg_166_-_buffer_overflow.pdf,
> (https://code.google.com/p/openjpeg/issues/detail?id=166)
> is of the same issue.
> EXPECTED DIFFERENCES:
> 937_-_openjpeg_cannot_decode_JP2_structure.pdf
> openjpeg_166_-_buffer_overflow.pdf
> (Both are progressions.)
> gs/base/sjpx_openjpeg.c

2014-01-22 22:06:51 +0100
Till Kamppeter <till.kamppeter@gmail.com>
5d6b18aa6a2a4ece4854ed9af074bb65f41af293

> Set correct portrait/landscape orientation on PCL 5c/e output
> Fixes bug #693715.
> gs/devices/gdevdjet.c
> gs/devices/gdevdljm.c
> gs/devices/gdevpcl.c
> gs/devices/gdevpcl.h

2014-01-20 13:18:23 +0000
Ken Sharp <ken.sharp@artifex.com>
c699e89a897b85d2f1f0a07ecac8d64b53500804

> pdfwrite - fix xref when eliding duplicate patterns
> commit fe99ca5fd2e3b191a76c7f7d791b72f3603e9fea detected duplicate shading
> patterns, and did not emit them into the PDF file, instead using the first
> definition. Unfortunately, due to a mis-understanding of the existing code
> the xref entry remained assigned, which led to invalid xref tables
> being written.
> This commit fixes the xref, and adds some (hopefully useful) comments to
> the relevant functions to try and avoid a repetition.
> No differences expected
> gs/devices/vector/gdevpdfu.c
> gs/devices/vector/gdevpdfv.c

2014-01-17 12:37:24 -0700
Henry Stiles <henry.stiles@artifex.com>
54927dd449c476b5a8c125e9beb1fbe06bebc45e

> Fix 694951 - No output produced.
> Allow the HPGL/2 command "PG" to initialize the GL/2 parser at the
> beginning of a job.
> pcl/pcparse.c

2014-01-15 02:00:12 +0100
Simon Bünzli <zeniko@gmail.com>
b13ef732907219b48757e2f501486f71b9f21030

> Bug 694893: prevent overflow in opj_int_ceildivpow2
> This can be seen e.g. in:
> 4241ac039aba57e6a9c948d519d94216_asan_heap-oob_14650f2_7469_602.pdf
> Thanks to Mateusz Jurczyk and Gynvael Coldwind of the Google Security
> Team for providing the example files.
> gs/openjpeg/libopenjpeg/opj_intmath.h

2014-01-14 23:11:43 +0100
Simon Bünzli <zeniko@gmail.com>
5b0c9985e3359aca9b3fcfd94424166aa61a141a

> Bug 694880: fix write access violation in opj_j2k_add_tlmarker
> A tile_index' current_tpsno may be far larger than the number of tile
> parts because opj_j2k_read_sot increases that number just by 10 instead
> of growing it to the actually required size.
> This can be seen e.g. in:
> 147af3f1083de4393666b7d99b01b58b_signal_sigsegv_130c531_6155_5136.pdf
> Thanks to Mateusz Jurczyk and Gynvael Coldwind of the Google Security
> Team for providing the example files.
> gs/openjpeg/libopenjpeg/j2k.c

2014-01-14 22:45:49 +0100
Simon Bünzli <zeniko@gmail.com>
7366747076f3b75def52079bd4d5021539a16394

> Bug 694949: prevent denial of service with arithmetic decoding
> Badly constructed Jbig2 images using arithmetic decoding may result in
> a denial of service attack by causing huge images to be created and
> initialized from no data at all (at EOS, the arithmetic decoder always
> returns the same values instead of failing).
> Two cases are prevented with this patch:
> * huge generic regions with barely any data to decode it from
> * a huge list of height classes with no data at all to decode it from
> This can be seen e.g. in:
> b534b5caad95dd405735ec9a079fd43b_asan_heap-oob_14bf3ce_6977_5690.pdf
> Thanks to Mateusz Jurczyk and Gynvael Coldwind of the Google Security
> Team for providing the example files.
> gs/jbig2dec/jbig2_arith.c
> gs/jbig2dec/jbig2_arith.h
> gs/jbig2dec/jbig2_generic.c
> gs/jbig2dec/jbig2_symbol_dict.c

2014-01-17 09:35:36 +0000
Ken Sharp <ken.sharp@artifex.com>
24dce021d5f774dd4264011cbd64bb4afb5aa51c

> PDF interpreter - Don't set UseCIEColor unless actually required.
> The PDF specification says that if a PDF file contains a page which uses
> a ColorSpace Resource of DefautlGray, DefaultRGB or DefaultCMYK then this
> should be regarded as a "request that such colors be systematically
> transformed (remapped) into device-independent CIE-based color spaces.".
> Essentially the PDF equivalent of UseCIEColor.
> This does rather beg the question of why not specify the colours in a
> device-independent space in the first place.....
> In any event, in order to achieve this the PDF interpreter pulls some
> tricks. We start by defining the Default* resources as the equivalent
> Device* spaces and *always* define UseCIEColor to true. Thus whenever
> we set a device color space the colour machinery tries to use instead the
> appropriate Device* space. Because the color space machinery has an
> optimisation to jump straight out when the requested space is the same as
> the current space, this means that the UseCIEColor transformation should
> have no effect.
> However, pdfwrite now emits a warning if UseCIEColor is true, so we want
> to avoid unconditionally setting UseCIEColor (I also find it horrifying that
> we do this terrible hackery).
> This commit borrows code used to set the Default* spaces if they exist on
> a page, and uses it to detect such spaces before we call setpagedevice
> for each page. We now only set UseCIEColor if the page actually uses one
> of the Default* spaces and therefore requires it.
> I did consider trying to substitute the defined colour space with the
> Default* space whenever a colour space definition takes place and a Default*
> space is defined, but gave up as there were simply too many places where
> color spaces could be defined.
> This code does (somewhat unexpectedly) produce some differences.
> These are either progressions or very tiny differences, and I feel that
> *not* setting UseCIEColor should be preferable anyway. (The real puzzle
> is why some PostScript files seem to differ, but they only differ when
> sent to pdfwrite and the PDF is then interpreed. Looks like UseCIEColor
> has some strange behaviour with ICCBased spaces).
> with pdfwrite:
> altona_technical_1v2_x3.pdf - very minor colour shift
> altona_technical_v20_x4 - progression on page 7
> 09-31.ps - difference in gray ramp in CIE space
> 09-34.ps - indetectable differences in some CIE colours
> all devices:
> Bug692783.pdf - indetectable shits in background
> Catx5720.pdf - slight colour shifts in 3 graphics
> 1021_-_transparency-issue.pdf - tiny colour shifts
> 1141_-_background_shading_cropped.pdf - tiny colour shifts
> gs/Resource/Init/pdf_main.ps
> gs/devices/vector/gdevpdf.c

2014-01-14 20:09:53 +0000
Chris Liddell <chris.liddell@artifex.com>
ec1c4adcc5fab850e4038c4d5392adddd265c67e

> Bug 694871: move libjpeg away from gc memory
> Change the libjpeg interface code to use a chunk allocator instead of garbage
> collected, "unstable" memory.
> Previously, the libjpeg integration used "Postscript" memory, that is, memory
> that is subject to garbage collection and save/restore operations.
> This means that Postscript like:
> /In (file) (r) file /DCTDecode filter def
> save
> <<
> ...
> /ImageSource In
> ...
> >> image
> restore
> In closefile
> would almost certainly cause a crash, since the memory allocated by libjpeg
> during the decoding for the "image" operator would be freed by the "restore"
> operator, *before* the "closefile" destroyed the filter stream and the
> libjpeg context.
> If we opt to always wrap the "default" heap allocator in a chunk allocator
> then we should probably remove the chunk allocator instances created
> specifically for libjpeg.
> No cluster differences.
> gs/base/gsstruct.h
> gs/base/lib.mak
> gs/base/sdct.h
> gs/base/sdctc.c
> gs/base/sdctd.c
> gs/base/sdcte.c
> gs/base/sjpegc.c
> gs/devices/vector/gdevpsdi.c

2014-01-15 12:54:43 +0000
Chris Liddell <chris.liddell@artifex.com>
c95dd5ba2cfd9b36aa3a18e7725089a741b7fa70

> Have DSC parser use GS memory handling
> The DSC parser was using it's own default memory alloc/free functions which
> just called the libc malloc/free.
> This tweaks our integration code so the parser will use the Ghostscript memory
> management functions.
> There are no changes to the parser code, the changes are entirely confined to
> integrating the parser with our PS interpreter.
> No cluster differences.
> gs/psi/zdscpars.c

2014-01-09 23:05:43 +0100
Simon Bünzli <zeniko@gmail.com>
8ec8321df613986e8642e2975f7182072eb4be62

> make opj_stream_set_user_data accept a NULL stream
> ... for consistency with opj_stream_set_* which does so.
> gs/openjpeg/libopenjpeg/cio.c

2014-01-09 22:56:54 +0100
Simon Bünzli <zeniko@gmail.com>
d6121c78a0fc6c8cd87c6495e11d327068518c35

> prevent assertion under MSVC on impossibly large allocations
> MSVC's debug CRT asserts that arguments to malloc and realloc aren't
> impossibly large (close to (size_t)-1) which makes testing fuzzed files
> impossible with assertions enabled.
> Problem found in a test file, 2236.pdf.asan.40.1376 supplied
> by Mateusz "j00ru" Jurczyk and Gynvael Coldwind of the Google
> Security Team using Address Sanitizer. Many thanks!
> gs/openjpeg/libopenjpeg/opj_malloc.h

2014-01-09 22:54:36 +0100
Simon Bünzli <zeniko@gmail.com>
87b08a096bb8ad61f9dbe4811e208d9c9d7fe63b

> don't define lrintf for MSVC 2013 (fix compilation breakage)
> gs/openjpeg/libopenjpeg/opj_includes.h

2014-01-09 23:04:38 +0100
Simon Bünzli <zeniko@gmail.com>
0f07c3247cc9211e57bb5429634f79c8c762fbfa

> fix error message in opj_jp2_read_colr
> gs/openjpeg/libopenjpeg/jp2.c

2014-01-09 22:46:48 +0100
Simon Bünzli <zeniko@gmail.com>
2f4b1565c10fe6faa7ed3854a7fa3cd0a6e18511

> tweak commit 66d9c0aa17a5abcecd6590e63f0620f7aa51634c
> The fix for testcase 1336.pdf.asan.47.376 for bug 694311 was slightly
> too strict: The access violation only happens during the MCT decoding
> step which might be skipped for some images. This patch moves the test
> into opj_tcd_mct_decode to only apply when it's actually required
> (which should allow j2kp4-file3-ycc-8bpc.pdf to be read without errors
> inside openjpeg itself and leaves handling of components of different
> sizes to the calling application/library).
> gs/openjpeg/libopenjpeg/tcd.c

2014-01-09 22:40:39 +0100
Simon Bünzli <zeniko@gmail.com>
0eedf7c22a76f089bbe13d76496ae56de38dfbef

> tweak commit 99a6f1af177c15f4db475186b79d169c993494ef
> Error messages should go to stderr instead of stdout so that tools such
> as mudraw -t don't get stdout polluted.
> gs/openjpeg/libopenjpeg/t2.c

2014-01-09 22:35:38 +0100
Simon Bünzli <zeniko@gmail.com>
fc884aee2b69c78500e65c3d05bf216791a9ea4a

> prevent heap overflow in opj_t2_read_packet_header
> Also prevent a double-free of segment data under OOM conditions.
> Problem found in a test file, 1802.pdf.SIGSEGV.36e.894 supplied
> by Mateusz "j00ru" Jurczyk and Gynvael Coldwind of the Google
> Security Team using Address Sanitizer. Many thanks!
> gs/openjpeg/libopenjpeg/t2.c

2014-01-09 22:32:37 +0100
Simon Bünzli <zeniko@gmail.com>
83dad6a76536222a3a51146f942e733a2e90ec52

> fix potential NULL-pointer dereference
> ... caused by testing the wrong variable after opj_realloc
> (happens only in OOM situations)
> gs/openjpeg/libopenjpeg/jp2.c

2013-12-23 00:00:32 +0100
Simon Bünzli <zeniko@gmail.com>
dafa1945a18e79578335693a4e4c6247e2617ee2

> jbig2dec: tweak overflow check in jbig2_(re)alloc
> If num * size overflows under x64, the value may be negative and still
> fit into a 32-bit integer. The proper check unfortunately requires a
> division.
> Note: The maximum allowed allocation is (size_t)-0x100 instead of
> SIZE_MAX so that debug CRTs which check for the allocation of e.g.
> (size_t)-1 never assert.
> gs/jbig2dec/jbig2.c

2014-01-10 22:56:52 +0100
Simon Bünzli <zeniko@gmail.com>
5eaf740b2c02523ae2ae6454e546cb6700d4e3f3

> Bug 694892: buffer overrun in jbig2_comment_ascii
> gs/jbig2dec/jbig2_metadata.c

2014-01-10 22:30:16 +0100
Simon Bünzli <zeniko@gmail.com>
8b82970325b2bd9aa993aa16c214a915ec8210e3

> follow-up to 8e2f00f15c988d75a4182ecdcdc1a82b4686ef92
> This might fix bug 694903.
> gs/jbig2dec/jbig2_symbol_dict.c

2014-01-12 22:12:35 +0100
Simon Bünzli <zeniko@gmail.com>
cddfd67f2df1863f8b06770e80e7c97bf970ccbb

> Bug 694882: sanitize component mappings
> PCLR, CMAP and CDEF data aren't properly sanitized - even after the
> fixes from the last fuzzing round. This patch unifies all the required
> checks in a new function opj_jp2_check_color which is invoked before
> the cdef and cmap values are used.
> This can be seen e.g. in:
> 66ea31acbb0f23a2bbc91f64d69a03f5_signal_sigsegv_13937c0_7030_5725.pdf
> Thanks to Mateusz Jurczyk and Gynvael Coldwind of the Google Security
> Team for providing the example files.
> gs/openjpeg/libopenjpeg/jp2.c

2014-01-09 22:20:37 +0100
Simon Bünzli <zeniko@gmail.com>
f4139d702559649e577a5df9cfd64b0ca6107a7a

> don't ignore buffer sizes
> Several functions accept a buffer size but never actually check whether
> the buffer overflows during reading/writing. This fixes all cases where
> a size variable has explicitly been marked as unused (through a (void)
> cast).
> This was discovered while investigating an assertion caused by
> 7cc691f332f26802c64cdc47e17bff8b_signal_sigabrt_7ffff6d59425_2247_2509.pdf
> among others.
> Thanks to Mateusz Jurczyk and Gynvael Coldwind of the Google Security
> Team for providing the example files.
> gs/openjpeg/libopenjpeg/event.c
> gs/openjpeg/libopenjpeg/jp2.c

2014-01-10 11:45:16 -0700
Henry Stiles <henry.stiles@artifex.com>
2c5cd8c29271d8735349353538c4a353f3aa563b

> Debug option "-ZI" results improved or corrected with the goal of
> creating output that can be reassembled back into PCL.
> We have an assembler and disassembler for PXL: pxlasm.py, pxldis.py,
> but they do not support PCL. For PCL we will use the GhostPCL
> interpreter with -ZI and an upcoming Python program will read that
> output and reassemble back to PCL.
> pcl/pccid.c
> pcl/pcdither.c
> pcl/pclookup.c
> pcl/pcommand.c
> pcl/pcommand.h
> pcl/pcpage.c
> pcl/pcparse.c
> pcl/pcpatrn.c
> pcl/pcsfont.c
> pcl/pcsymbol.c
> pcl/pctext.c
> pcl/pcuptrn.c
> pcl/pglabel.c
> pcl/pgparse.c
> pcl/pgvector.c
> pcl/rtmisc.c
> pcl/rtraster.c
> pl/plmain.c

2014-01-11 11:44:36 +0000
Ken Sharp <ken.sharp@artifex.com>
4a267d719148abf961f479ba6c9024bfa2c18bf5

> pdfwrite - limit scan line comparison to actual width
> Bug #694930 "Valgrind issues found by fuzzing in compute_subimage (gdevpdfd.c:707)"
> The local image converter, and specifically mask to clip conversion,
> compare consecutive scan lines of an image to see if they are identical.
> However, they were using the width of the allocated raster, which can include
> alignment padding, rather then the actual width of the image data. This
> meant we were comparing uninitialised data. In this case its actually safe
> as we would simply create a more complex clip than required, but its
> definitely sub-optimal.
> This commit changes the comparison to use the number of bits in the image,
> rounded up to the nearest byte.
> No differences expected.
> gs/devices/vector/gdevpdfd.c

2014-01-09 16:08:15 +0000
Ken Sharp <ken.sharp@artifex.com>
20f6eb7d946cda9bd6b141881d1abd13daec911e

> More error checking when copying fonts
> Bug #694263 is again a fuzzing bug declared to demonstrate Valgrind errors
> which for me causes a seg fault.
> This again appears to be due to a broken TrueType font. The additional
> checking in this commit resolves the problem for me.
> gs/devices/gxfcopy.c

2014-01-09 12:04:51 +0000
Ken Sharp <ken.sharp@artifex.com>
49a05084feee92818347fbf888fc2ab784b82122

> pdfwrite - initialise some variables to pacify valgrind
> Bug #694236 does not give the valgrind warnings described in the bug
> report for me, but did complain about the character widths. It seems
> that somehow (broken font ?) the values were uninitialised. Here we just
> set them to 0.
> No differences expected
> gs/devices/vector/gdevpdte.c

2014-01-09 11:13:02 +0000
Ken Sharp <ken.sharp@artifex.com>
e9a574ec0e6d13fcf898a7132ce08476af4ea84d

> Don't attempt to copy a missing glyph when copying fonts
> Bug #694236 for me does not (initially at least) cause a Valgrind warning,
> but does cause a seg fault.
> The problem is that we have a (presumably broken) TrueType font where we
> try to enumerate all the glyphs in the font. The enumeration code returns
> a GS_NO_GLYPH, but the font copying code doesn't catch that, and so tries
> to copy that glyph. This causes a crash in the name lookup.
> The commit here simply adds an additional check that the glyph is not
> 'GS_NO_GLYPH', if it is we treat it as an error.
> No differences expected.
> gs/devices/gxfcopy.c

2014-01-09 08:19:51 +0000
Ken Sharp <ken.sharp@artifex.com>
eb42d237028c3fd832664c5e1479483a430f5ed9

> DSC parser - silence a compiler warning with a cast
> gs/psi/dscparse.c

2014-01-08 10:57:46 -0700
Henry Stiles <henry.stiles@artifex.com>
b2ecdbba02eac6fa19866bd18c83ece7cdd4074d

> Possible fix for 694837.
> Allow the luratech jbig2 encoder to process 0 input without error like
> all other streams encoders. Analysis by Ken Sharp.
> gs/base/sjbig2_luratech.c

2014-01-08 16:12:53 +0000
Ken Sharp <ken.sharp@artifex.com>
32df3bf46606f697d7deae86211c897be63a0764

> DSC parser - reset scanning at end of job
> Currently the DSC parser never leaves 'scan_trailer', which is fine for
> one-job-at-a-time usage, but not good for job server or multiple inputs.
> This commit modifies the scan-trailer condition so that if a new DSC header
> is encountered, *after* we've found a trailer, we reset some aspects of the
> DSC parsing.
> Note that this doesn't completely reset the parser as that caused memory
> problems.
> Bug #692208
> No differences expected
> gs/psi/dscparse.c

2014-01-08 08:26:14 +0000
Ken Sharp <ken.sharp@artifex.com>
cbeeef7f54bd183515f81d42176a049a7f7703a2

> pdfwrite - add a warning if -dUseCIEColor is set
> With the current color management its not really sensible to set UseCIEColor
> (which was always a horrible hack anyway) in order to do color conversion
> or management.
> So if we see this being done, show the user a warning. We don't want to
> raise an error as someone will undoubtedly complain that they have a good
> reason for using UseCIEColor with pdfwrite.....
> No differences expected.
> gs/devices/vector/gdevpdf.c

2014-01-01 20:32:49 -0800
Ray Johnston <ray.johnston@artifex.com>
13b8f94c86efc4b98c7d63774b761bad9783f16c

> Enable the pdf14 optimization. Previous commit only collected data.
> Somehow, the previous commit that collected the data didn't actually
> skip pdf14 transparency on any bands. Also testing showed that fiils
> with patterns that needed transparency were not being detected.
> We need to save the page mode pdf14_needed state based on the blend_mode
> and opacity to restore to the correct setting after smask or transpacrency
> group pushes.
> Lastly, we punt if the device is not contone, since the colors written
> for bands will be contone which are not compatible with the target.
> Correct the pdf14_opmode_names to add in the missing PDF14_ABORT_DEVICE.
> gs/base/gdevp14.c
> gs/base/gstrans.h
> gs/base/gxclist.h
> gs/base/gxclpath.c
> gs/base/gxclrast.c
> gs/base/gxclread.c

2014-01-06 14:29:14 +0000
Ken Sharp <ken.sharp@artifex.com>
b86a214d542a91e526599aaadd2e68d896c1edff

> pdfwrite - fix another memory allocator
> After the previous problem caused by using the non-stable memory allocator
> I reviewed all use of this allocator and nonticed that in this case we
> allocate using the stable allocator, but were freeing it using the non-stable
> allocator.
> This probably only leaks memory but its best to fix it.
> gs/devices/vector/gdevpdtd.c

2014-01-06 14:27:37 +0000
Ken Sharp <ken.sharp@artifex.com>
465eb2d291a92c8eda46c090c70594b4ef8f0fba

> pdfwrite - add a comment explaining about pdev->pdf_mewmory
> gs/devices/vector/gdevpdfx.h

2014-01-06 14:27:01 +0000
Ken Sharp <ken.sharp@artifex.com>
18f35e567b9e6760bf60a1f4c04b725cd343d5a9

> pdfwrite - minor memory issue
> Noticed while reviewing other problems, we didn't check to see if a memory
> allocation was successful, and also; if a subsequent fread() failed we would
> not free the allocated memory.
> gs/devices/vector/gdevpdfo.c

2014-01-06 14:25:06 +0000
Ken Sharp <ken.sharp@artifex.com>
ba099db2df6867215178b7cfc1065eb921105d66

> pdfwrite - squelch a compiler warning
> undefine PDF_FOR_EPS2WRITE to prevent compiler complaning its redefined.
> gs/devices/vector/gdevpdf.c

2014-01-06 10:39:41 +0000
Ken Sharp <ken.sharp@artifex.com>
ecf24042611a96c9d5560ccec845f3b2e4d70b38

> pdfwrite - use stable memory for the outline tree
> Bug #694868 "Regression: seg faults starting with 0790b03698b27dcf342e0175d2f833c921b5dab2"
> The move of the outline tree to a dynamic allocation instead of static
> accidentally used memory subject to save and restore instead of stable
> memory. Oddly this only caused problems on the Linux debug build.
> This commit moves the allocation to stable memory which I *believe* will
> solve the problem. NB Chris is going to alter the allocation code so that
> a debug build will flag this sort of problem up.
> No differences expected.
> gs/devices/vector/gdevpdf.c
> gs/devices/vector/gdevpdfm.c

2013-12-30 12:50:40 -0800
Michael Vrhel <michael.vrhel@artifex.com>
d4e6b106c336b8ae7db87f4bec6e0afb6993b687

> Fixes for issues with the use of DeviceN source profiles
> GC definitions were wrong for some of the structures and also name allocation size was wrong.
> Fixes bug 694865
> gs/base/gsicc_lcms.c
> gs/base/gsicc_lcms2.c
> gs/base/gsicc_manage.c

2013-12-20 18:19:23 +0000
Robin Watts <robin.watts@artifex.com>
6700dbf0d426ba8d6a707d639159b5b8db00a95c

> Pass on an error code rather than ignore it.
> gs/base/gdevp14.c

2013-12-22 23:22:42 -0800
Michael Vrhel <michael.vrhel@artifex.com>
17f0dfaf200163d7207f27f3cc34e0a1cf843203

> Add missing case for UNKNOWN color space in transparency group.
> This is used when the the new group did not specify a color space. We
> were incorrectly returning an error. There is no error. The UNKNOWN
> information is stored in the clist and when we later get the UNKNOWN
> information we known to just keep the current color space.
> gs/base/gdevp14.c

2013-12-23 10:30:04 -0800
Ray Johnston <ray.johnston@artifex.com>
72713e784ddaea275498a67e25ab77aedbc0eb9b

> Fix bug 69365: Write pattern colors to all bands consistently for images.
> Thanks to Michael Vrhel for tracking this down. If a transparent pattern
> color is written to all bands after having been written to a band for
> an image, the transparency fill_trans_buffer will be NULL because the
> group for the image was pushed at 'begin_typed_image' time. We now write
> the color to all_bands based on the image extent, consistently.
> gs/base/gxcldev.h
> gs/base/gxclimag.c
> gs/base/gxclpath.c

2013-12-23 15:45:23 +0000
Ken Sharp <ken.sharp@artifex.com>
0790b03698b27dcf342e0175d2f833c921b5dab2

> pdfwrite - convert outline tree to dynamic storage
> Bug #690429 "convert outline tree from static array to dynamic list"
> In the past the outline tree in pdfwrite was a hard coded array with a
> maximum depth of 31. This array is now dynamically allocated, so the depth
> is limited only by available memory.
> No differences expected
> gs/devices/vector/gdevpdf.c
> gs/devices/vector/gdevpdfb.h
> gs/devices/vector/gdevpdfm.c
> gs/devices/vector/gdevpdfx.h

2013-12-20 17:54:42 +0000
Robin Watts <robin.watts@artifex.com>
3574d5254bd93dc2b002f93de120043990c3fcda

> Remove mistakenly added files.
> clustercmd
> clusterdatestamp

2013-12-18 07:56:31 -0800
Michael Vrhel <michael.vrhel@artifex.com>
6f8bb99dae2db541b7941d65816581137990be6d

> Temp debug patch
> gs/base/gdevp14.c
> gs/base/gsptype1.c
> gs/base/gxpcmap.c

2013-12-20 15:31:10 +0000
Robin Watts <robin.watts@artifex.com>
dcb60221c23d33e65ed2193f1f0e6355f06c12ab

> Add more error handling missing from pdf14.
> gs/base/gxblend1.c

2013-12-20 15:27:54 +0000
Robin Watts <robin.watts@artifex.com>
d355b00b5915697904a2c0f8a2334050d2c1bf32

> Bug 694858: Add some missing error handling.
> This solves at least some of the SEGVs.
> clustercmd
> clusterdatestamp
> gs/base/gstrans.c

2013-12-20 10:05:58 +0000
Ken Sharp <ken.sharp@artifex.com>
ba28d0f50d9de48d8961f93044b5dac8139312f2

> pdfwrite - update element linked list before freeing element in cos dicts
> Bug 694854 "Converting pdf to PDFX standard crashes ghostscript right before the end"
> When creating a PDF/X file the code deletes any BleedBox, TrimBox, ArtBox
> entries from the page dictionary after writing them (ho idea why...) using
> the cos_dict_delete() function.
> The function frees the memory, and then updates the linked list of elements
> in the dictionary, however it updates the list after freeing the memory. If
> the free memory pointed to should alter before the linked list is updated,
> then the list will be updated with garbage.
> Updating the linked list *before* freeing the memory is a much better way
> to proceed.
> Because this is only called when creating PDF/X files, no differences are
> expected.
> gs/devices/vector/gdevpdfo.c

2013-12-19 22:30:39 +0100
Till Kamppeter <till.kamppeter@gmail.com>
615059129740d77fac1db1bbec4a79958d88e3bf

> Fixed line conibuation typos in previous commit (d997bc4)
> gs/cups/gdevcups.c

2013-12-19 00:41:19 +0000
Robin Watts <robin.watts@artifex.com>
77eb4f71f15365c713f1fec698a87203afaaf984

> Add some error checking to pdf14.
> When we record an error code, ensure we check it.
> gs/base/gdevp14.c

2013-12-19 12:32:23 +0000
Chris Liddell <chris.liddell@artifex.com>
3c913314883114d671d550e5db9efa2192241040

> Only issue the "unbalanced q/Q" warning once per page.
> Write a flag to the pdfdict to indicate that we've already issued the warning
> and skip it from then on for the current page. Reset flag at the end of the
> page.
> No cluster differences.
> gs/Resource/Init/pdf_main.ps
> gs/Resource/Init/pdf_ops.ps

2013-12-19 17:03:39 +0100
Till Kamppeter <till.kamppeter@gmail.com>
d997bc49531613205e055c8e4e25d93bb4c762e6

> Added "pwgraster" output device
> The "pwgraster" output device rasterizes the input into the PWG Raster
> format, an industry-standarized raster format for printers, especially
> the upcoming IPP Everywhere network printers which are supposed to
> work with any hardware-model-specific software (drivers). As PWG
> Raster is derived from CUPS Raster it is generated by the "cups"
> output device, but calling it with the "pwgraster" name makes it
> generating PWG Raster instead of CUPS Raster.
> gs/configure.ac
> gs/cups/gdevcups.c
> gs/devices/devs.mak

2013-12-19 09:40:01 +0000
Ken Sharp <ken.sharp@artifex.com>
81b246414c4624cf476793c2590201de408ea33a

> pdfwrite - don't allocate multiple object IDs for shadings
> Bug #694853 "PDF/A generation does not fix all errors"
> When the code to detect and elide duplicate shadings was added we used the
> pdf_substitute_resource function to detect duplicates and drop the new one.
> However this function *always* assigned a new object ID if it wasn't a
> duplicate, which leaves the original ID dangling (if the object already had
> one). This commit simply avoids creating a new ID if the object is not a
> duplicate, and already has an ID.
> I'm a little nervous about this one, but a cluster push seems to be OK. No
> differences expected.
> gs/devices/vector/gdevpdfu.c

2013-12-18 18:43:56 +0000
Robin Watts <robin.watts@artifex.com>
1a25414344c0a2c3b9c8947ad120d34845ecb387

> Bug 693365: Add find_pdf14_device function, and use it.
> This seems to solve the problem with simple6.pdf at least.
> gs/base/gdevp14.c
> gs/base/gsicc_monitorcm.c
> gs/base/gspaint.c
> gs/base/gxdevsop.h

2013-12-18 15:26:49 +0000
Robin Watts <robin.watts@artifex.com>
36f97ff44c7e94d1cf033a6495f2876b1976ca66

> Bug 694258: Allow for floating point inaccuracies in pattern code.
> When calculating the regions 'touched' by pattern repeats, allow for
> inaccuracies in the floating point calculations.
> gs/base/gsptype1.c
> gs/base/math_.h

2013-12-18 15:06:17 +0000
Chris Liddell <chris.liddell@artifex.com>
b0cbadbbb03dffbf5f9ec9e72658f59e0e59238a

> Remove floatp references in docs.
> CLUSTER_UNTESTED
> gs/doc/C-style.htm

2013-12-18 14:53:48 +0000
Chris Liddell <chris.liddell@artifex.com>
cf009c80c4a371ad64cc5c0444d72902657dbfce

> Replace the "floatp" with "double"
> For historic reasons, floating point parameters used the type "floatp" which
> was actually typedef'ed to "double".
> To reduce confusion, we now use "double" directly.
> No cluster differences.
> gs/base/fapi_ft.c
> gs/base/gdevdcrd.c
> gs/base/gdevdflt.c
> gs/base/gdevvec.c
> gs/base/gdevvec.h
> gs/base/gsalpha.c
> gs/base/gsalpha.h
> gs/base/gscdevn.c
> gs/base/gschar.c
> gs/base/gschar.h
> gs/base/gscie.c
> gs/base/gscie.h
> gs/base/gsciemap.c
> gs/base/gscolor.c
> gs/base/gscolor.h
> gs/base/gscolor1.c
> gs/base/gscolor1.h
> gs/base/gscolor3.c
> gs/base/gscolor3.h
> gs/base/gscoord.c
> gs/base/gscoord.h
> gs/base/gscpixel.c
> gs/base/gscrd.c
> gs/base/gscrdp.c
> gs/base/gsdevice.c
> gs/base/gsdparam.c
> gs/base/gsdps1.c
> gs/base/gsfont.c
> gs/base/gsfont.h
> gs/base/gsfunc0.c
> gs/base/gsfunc4.c
> gs/base/gshsb.c
> gs/base/gshsb.h
> gs/base/gsht.h
> gs/base/gsht1.c
> gs/base/gshtscr.c
> gs/base/gshtx.c
> gs/base/gshtx.h
> gs/base/gsicc.c
> gs/base/gsicc_create.c
> gs/base/gslib.c
> gs/base/gsline.c
> gs/base/gsline.h
> gs/base/gsmatrix.c
> gs/base/gsmatrix.h
> gs/base/gspaint.c
> gs/base/gspath.c
> gs/base/gspath.h
> gs/base/gspath1.c
> gs/base/gspath2.h
> gs/base/gsstate.c
> gs/base/gsstate.h
> gs/base/gstext.c
> gs/base/gstext.h
> gs/base/gstparam.h
> gs/base/gstrans.c
> gs/base/gstrans.h
> gs/base/gxccache.c
> gs/base/gxchar.c
> gs/base/gxchar.h
> gs/base/gxchrout.c
> gs/base/gxchrout.h
> gs/base/gxclimag.c
> gs/base/gxclpath.c
> gs/base/gxcmap.c
> gs/base/gxcolor2.h
> gs/base/gxdevcli.h
> gs/base/gxdevice.h
> gs/base/gxfapi.c
> gs/base/gxfmap.h
> gs/base/gximag3x.c
> gs/base/gximage3.c
> gs/base/gxline.h
> gs/base/gxmatrix.h
> gs/base/gxpath.c
> gs/base/gxpath.h
> gs/base/gxshade1.c
> gs/base/gxshade4.h
> gs/base/gxshade6.c
> gs/base/gxtmap.h
> gs/base/sdcparam.c
> gs/base/spprint.c
> gs/base/spprint.h
> gs/base/stdpre.h
> gs/contrib/eplaser/gdevescv.c
> gs/contrib/eplaser/gdevescv.h
> gs/contrib/lips4/gdevl4v.c
> gs/contrib/opvp/gdevopvp.c
> gs/devices/gdevcdj.c
> gs/devices/gdevclj.c
> gs/devices/gdevijs.c
> gs/devices/gdevjpeg.c
> gs/devices/gdevpxut.c
> gs/devices/gdevpxut.h
> gs/devices/vector/gdevpdf.c
> gs/devices/vector/gdevpdfc.c
> gs/devices/vector/gdevpdfd.c
> gs/devices/vector/gdevpdfg.c
> gs/devices/vector/gdevpdfg.h
> gs/devices/vector/gdevpdfj.c
> gs/devices/vector/gdevpdfk.c
> gs/devices/vector/gdevpdfm.c
> gs/devices/vector/gdevpdfo.c
> gs/devices/vector/gdevpdfo.h
> gs/devices/vector/gdevpdfv.c
> gs/devices/vector/gdevpdts.c
> gs/devices/vector/gdevpdts.h
> gs/devices/vector/gdevps.c
> gs/devices/vector/gdevpsdf.h
> gs/devices/vector/gdevpsdi.c
> gs/devices/vector/gdevpsdu.c
> gs/devices/vector/gdevpsf2.c
> gs/devices/vector/gdevpx.c
> gs/devices/vector/gdevsvg.c
> gs/devices/vector/gdevxps.c
> gs/psi/idparam.c
> gs/psi/idparam.h
> gs/psi/imain.c
> gs/psi/imain.h
> gs/psi/zcolor.c
> gs/psi/zgstate.c
> gs/psi/zht1.c
> gs/psi/zht2.c
> gs/psi/zmatrix.c
> gs/psi/zpath.c
> gs/psi/zpath1.c
> gs/psi/ztrans.c
> pcl/pccsbase.c
> pcl/pcfont.c
> pcl/pcht.c
> pcl/pcindxed.c
> pcl/pcindxed.h
> pcl/pcmtx3.c
> pcl/pcmtx3.h
> pcl/pcommand.c
> pcl/pcpage.c
> pcl/pcpalet.c
> pcl/pcpalet.h
> pcl/pcparam.h
> pcl/pcpatxfm.c
> pcl/pcpatxfm.h
> pcl/pcrect.c
> pcl/pcsfont.c
> pcl/pctext.c
> pcl/pgcolor.c
> pcl/pgdraw.c
> pcl/pgdraw.h
> pcl/pgfdata.c
> pcl/pggeom.c
> pcl/pggeom.h
> pcl/pglabel.c
> pcl/pgpoly.c
> pcl/pgvector.c
> pcl/rtgmode.c
> pcl/rtraster.c
> pl/pjparse.c
> pl/pjparse.h
> pl/pjparsei.c
> pl/pjtop.c
> pl/pjtop.h
> pl/plchar.c
> pl/plfont.h
> pl/plsrgb.c
> pl/pluchar.c
> pxl/pxink.c
> pxl/pxpaint.c
> pxl/pxpthr.c
> svg/svgtop.c
> tools/gslite/gslt_test.c
> xps/xpstop.c

2013-12-18 11:37:40 +0000
Ken Sharp <ken.sharp@artifex.com>
5ddd13eda3853d53315b7ba656ccd32ad9814c34

> ps2write - Don't emit a page size change if the last request failed (and was the same size)
> Bug #694852 We check the current media size at the start of every page, and
> only emit a new request if the page is a different size to the current size.
> However, if the request fails (media not available) we keep on requesting
> the media via setpagedevice. This causes duplexing to be disabled, as each
> setpagedevice resets the device and ejects the previous page.
> This commit still checks the current page size, however, if it is not the
> size needed for the page, we then check to see if 'MediaRequested;' is
> known. If it is not we set the media, and set MediaRequested to the new
> media size. If MediaRequested is known, we check to see if the new media
> size is the same as the last one we requested. If it is there's no point
> in doing a new request as it will fail again,so we drop the request.
> If the new requested media is not the same as the last requested media,
> then we do emit a new request, which may or may not be satisfied of course.
> This should permit duplexing to work and be slightly faster in the case
> where requested media is not available.
> gs/devices/vector/opdfread.h
> gs/lib/opdfread.ps

2013-12-14 13:13:02 +0000
Chris Liddell <chris.liddell@artifex.com>
2f8b73d56d667334e935071f24f1d6b1860a48e2

> Bug 694832: refine when to elide the TTF notdef glyph
> Only force the Truetype notdef glyph to be non-marking when the font in
> question uses a TTF cmap table other than the symbolic (3.0) cmap table.
> Several cluster files show differences - all except one are progressions
> with reference to Acrobat, and the exception was "wrong" before and is
> slightly differently wrong now (an entirely different underlying issue).
> gs/Resource/Init/gs_ttf.ps
> gs/psi/zfapi.c

2013-12-17 17:33:05 +0000
Robin Watts <robin.watts@artifex.com>
727b6e87edc234670120dcce040547610736fe0d

> Bug 694844: Fix thin stroking of paths with non-idempotent colors.
> For non-idempotent colors when stroking we have to construct an entire
> path and then fill it, rather than stroking each section as we go.
> Unfortunately in the code that implements this, we missed a case - thin
> sections can be stroked section by section even in the non-idempotent
> case.
> We fix that here.
> This appears to solve Bug 694844, which was hitting this case.
> gs/base/gxstroke.c

2013-12-16 18:13:03 +0000
Robin Watts <robin.watts@artifex.com>
300c3ea8f2c82471c5e57655bd13549f1172c38a

> Bug 694842: Fix threshold table generation.
> When we generate threshold tables for dithering, we should expect them
> to be 'evenly distributed'. This is not the case currently. In the
> example given in this bug, we generate an 8x4 dither table. This
> contains 32 pixels, all of which can be on or off, hence we have 33
> levels, ranging from 0 on to 32 on.
> We would further expect our input range to be evenly divided into these
> levels - i.e. roughly 256/33 in each band.
> This is not the case. The threshold table generated is:
> threshold array row 0= 88 120 152 184 176 144 112 80
> threshold array row 1= 192 224 208 168 72 40 56 96
> threshold array row 2= 232 255 240 136 32 8 24 128
> threshold array row 3= 216 248 200 104 48 16 64 160
> The operation of our thresholding code is to set a pixel if
> contone(x,y) < threshold(x,y), hence our inputs divide into:
> 0-7,8-15,...240-254,255
> Not only does this not have the required 256/33 per region, the top
> and bottom regions are far from being even (8 vs 1 entries).
> Ideally we should fix this code so generate the correct distribution -
> an enhancement bug will be opened for this. For now we will satisfy
> ourselves by offsetting the thresholds slightly so that the top and
> bottom ranges are at least even. The new code gives:
> threshold array row 0= 84 116 148 180 172 140 108 76
> threshold array row 1= 188 220 204 164 68 36 52 92
> threshold array row 2= 228 252 236 132 28 4 20 124
> threshold array row 3= 212 244 196 100 44 12 60 156
> gs/base/gsht.c

2013-12-17 10:30:26 +0000
Ken Sharp <ken.sharp@artifex.com>
712d2254dc190baeea795931a470d39f8d43c2bf

> Update opdfread.ps with the changes for eps2write. Although we no longer
> actually use opdfread.ps, instead we use opdfread.h, we want to keep the
> two in sync.
> gs/lib/opdfread.ps

2013-12-17 10:29:31 +0000
Ken Sharp <ken.sharp@artifex.com>
730dbe8b0717b2f882067163737eb89708e7e66d

> correct a tab in the source, replacing with spaces.
> gs/devices/vector/gdevpdfd.c

2013-12-16 17:44:22 +0000
Ken Sharp <ken.sharp@artifex.com>
1f30a9f66b280fad5cb8133e02530c60a038843c

> Add new 'eps2write' device which will eventually replace epswrite
> No differences expected
> gs/devices/devs.mak
> gs/devices/vector/gdevpdf.c
> gs/devices/vector/gdevpdfb.h
> gs/devices/vector/gdevpdfd.c
> gs/devices/vector/gdevpdfi.c
> gs/devices/vector/gdevpdfu.c
> gs/devices/vector/gdevpdfx.h
> gs/devices/vector/gdevpdtc.c
> gs/devices/vector/gdevpdte.c
> gs/devices/vector/gdevpdti.c
> gs/devices/vector/gdevpdts.c
> gs/devices/vector/gdevpdts.h
> gs/devices/vector/gdevpdtt.c
> gs/devices/vector/gdevpdtt.h
> gs/devices/vector/opdfread.h
> gs/psi/msvc.mak

2013-12-16 08:32:12 -0800
Michael Vrhel <michael.vrhel@artifex.com>
abd38464f9b058502c9491873ff7f01f00c406d7

> Fix for goof up in loop index variable.
> Fixes bug 694811 and 694848. Thanks ken for finding this.
> gs/base/gdevp14.c

2013-12-16 12:34:26 +0000
Robin Watts <robin.watts@artifex.com>
8e2f00f15c988d75a4182ecdcdc1a82b4686ef92

> Bug 694845: Shailesh Mistrys patch for regression in jbig2dec
> Having reverted the problematic patch, this is the fixed version.
> gs/jbig2dec/jbig2_symbol_dict.c

2013-12-16 11:45:42 +0000
Robin Watts <robin.watts@artifex.com>
fa8b62e45f07564304d671b57cba7fede5d4729d

> Revert "Bug 694124: Shailesh Mistry's patch for valgrind problems."
> This reverts commit d166833eb541466104c582980be1e42e0062c738.
> gs/jbig2dec/jbig2_symbol_dict.c

2013-12-16 10:08:20 +0000
Chris Liddell <chris.liddell@artifex.com>
bcac8f9cfd8330ec4434b176c150c44af276393e

> Force special action to build language_switch
> A "normal" attempt to build language_switch will elicit a warning, to actually
> make it build, adding "UNSUPPORTED=1" to the (n)make command line is required.
> language_switch/pspcl6_gcc.mak
> language_switch/pspcl6_msvc.mak

2013-12-15 09:51:50 -0800
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
88a39ea069424045161ff000af5574ba340bb51d

> Remove the language switch build from the default make targets.
> Makefile

2013-12-14 13:54:31 +0000
Chris Liddell <chris.liddell@artifex.com>
70c1f72389b31e95e9cffb6578a3a94e3052cb44

> Bug 694843: reset FAPI font data on "refine" font
> For example, a font dict may be copied, so the "FAPI" entry is copied with
> the dict, but the new internal font object does not have the FAPI server in
> it. We catch that in the "refine font" call - previously here we didn't reset
> the font data, just "re-bound" the FAPI server. It turns out with the
> language switch build, we need to set the FAPI font data, too.
> No cluster differences.
> gs/psi/zfapi.c

2013-12-13 15:15:24 +0000
Ken Sharp <ken.sharp@artifex.com>
5b592a88fa8760f5fd4d7a8f082e094bda981a93

> pdfwrite - yet more discriminating tests before TrueType font combining
> Bug #694833 "german letters adieresis, odieresis and udieresis are missing after conversion to PDF"
> This follows on from commit 8b6be8be2cdcefae39339682d45d3c009ab909ac
> Bug #694538.
> Again we have a random pair of Type 42 fonts which would be compatible to
> combine, except that they have differing max composite points and contours.
> Mad, but there you go.
> No differences expected, we don't see these files from any other source.
> gs/base/gstype42.c
> gs/base/gxfont42.h
> gs/devices/gxfcopy.c

2013-12-12 16:20:59 +0000
Chris Liddell <chris.liddell@artifex.com>
3e8a32f8a884039b851c39b5aceabfd8c8e93198

> Inherit CFLAGS from environment in (pdl) configure script
> No cluster differences.
> config.mak.in
> configure.ac
> main/pcl6_gcc.mak

2013-12-12 00:58:04 +0000
Robin Watts <robin.watts@artifex.com>
99a6f1af177c15f4db475186b79d169c993494ef

> Bug 694119: Shailesh Mistry's patch for Valgrind problems.
> Don't read off the end of an empty (or almost empty) buffer.
> gs/openjpeg/libopenjpeg/t2.c

2013-12-11 19:06:03 +0000
Robin Watts <robin.watts@artifex.com>
bb123bf027bf7ea0aa5b82ed2626d21f91c57613

> Bug 694363: Shailesh Mistry's patch for SEGV.
> Avoid buffer overflow due to oversized image dimensions causing
> int overflow.
> gs/openjpeg/libopenjpeg/j2k.c

2013-12-11 19:02:39 +0000
Robin Watts <robin.watts@artifex.com>
d166833eb541466104c582980be1e42e0062c738

> Bug 694124: Shailesh Mistry's patch for valgrind problems.
> Detect zero sized symbol dictionary and exit neatly. Avoids overreads.
> gs/jbig2dec/jbig2_symbol_dict.c

2013-12-11 09:47:45 -0800
Ray Johnston <ray.johnston@artifex.com>
f42c717329ec13db00f2627bd89ad4c081379fd9

> Remove extraneous %d from a debug message (-ZL).
> Thanks to Henry for spotting this.
> gs/base/gxclutil.c

2013-12-11 16:17:31 +0000
Chris Liddell <chris.liddell@artifex.com>
19d709b45b9173e225bd6e62bb20e9eb5f192254

> Bug 694836: remove erroring CIDFont subsitute record
> When subsituting a CIDFont we dynamically update the CIDFont resource's .map
> dictionary (to ensure the substitute CIDFont is loaded with the correct
> "attributes").
> If findresource fails with the updated .map dictionary, remove the entry we
> just added, to avoid subsequent attempted loads of that CIDFont finding the
> erroring .map entry.
> No cluster differences.
> gs/Resource/Init/gs_ciddc.ps
> gs/Resource/Init/pdf_font.ps

2013-12-11 13:03:28 +0000
Ken Sharp <ken.sharp@artifex.com>
b3be65914d6dbe6585dec8576e80c7fb52fffbe4

> pdfwrite - fix compiler comparison oddness
> Bug #694838 "Artifex Ghostscript 9.10: JBIG2Encode requires CompabilityLevel >= 1.4"
> The code compares a float variable with a non-integer constant. Bizzarely
> the comparison fails unless the contant is declared as type float as well
> (using the x.yf syntax), at least on the Microsoft compiler. Presumably
> without this they are evaluated as double.
> This commit simply alters the constants to be declared specifically as
> floats.
> No differences expected.
> gs/devices/vector/gdevpdfp.c

2013-12-07 16:16:22 -0800
Ray Johnston <ray.johnston@artifex.com>
2aaae7404988d7443b002907954693749c468347

> A better fix for the previous -dEPSFitPage.
> Note that -dEPSCrop with -dEPSFitPage is actually done in the C
> code.
> gs/Resource/Init/gs_epsf.ps

2013-12-07 14:42:07 -0800
Ray Johnston <ray.johnston@artifex.com>
7f4d1c480eb53e2f18bd87a0c3cb0f98faa7281c

> Fix EPSFitPage (related to bug 694829.
> The EPSFitPage now rotates as well as translating/scaling.
> gs/Resource/Init/gs_epsf.ps
> gs/Resource/Init/gs_init.ps

2013-12-03 10:09:56 +0000
Ken Sharp <ken.sharp@artifex.com>
ca3d544d51c3e1d63a2fd115dac23255c966ba0e

> pdfwrite - add Resources to current substream when starting an SP pdfmark
> Bug #689653 "Nested form XObject pdfmarks not working properly"
> Bug #689883 "/SP pdfmark inside /BP-/EP pdfmark pair for XObject re-use"
> When we use a 'picture' via the SP pdfmark, add the picture resource to
> the current substream resources, so that if we are accumulating a substream
> (pattern, form, another picture etc) then the Resources for that substream
> will contain an entry for the picture. Previously they did not and relied
> on inheriting from the page dictionary, which is long since deprecated.
> Thanks to Alexander Grahn for diagnosing the problem and supplying the
> patch.
> No differences expected.
> gs/devices/vector/gdevpdfm.c

2013-12-02 16:28:46 -0800
Ray Johnston <ray.johnston@artifex.com>
da944b290302bf9391116b806c4a368b7d185d94

> Add debugging for max heap memory allocation for -Z:
> This is a minor hack for debug builds that prints out the 'max' usage
> which is often of interest. A better method would be to add a memory
> proc to print the stats that would be implemented for all allocators.
> If so, a 'verbosity' control might be nice for 'max' (max used) and
> 'leaked' that would print all elements that the allocator knows about
> (for leak detection), or 'current' to print current allocated size.
> gs/psi/iapi.c

2013-11-30 13:46:49 +0000
Ken Sharp <ken.sharp@artifex.com>
05d2e5cd0b8ce92ddeacca00e8f64d3f7b2e5883

> pdfwrite - add garbage collection handlers to Bicubic streams
> Bug #694826 "Seg fault with pdfwrite device"
> There was an oversight when coding the Bicubic stream downsampling and the
> working buffer was not enabled for relocation on garbage collection.
> No differences expected.
> gs/devices/vector/gdevpsds.c
> gs/devices/vector/gdevpsds.h

2013-11-29 09:31:04 +0000
Ken Sharp <ken.sharp@artifex.com>
33b41157c24f27cd912fa1d517e9246af37bbe2f

> txtwrite - set the returned glpyh in the text enumerator before executing CDevProc
> Bug #698422 "txtwriter driver crashes with this (badly crafted) PDF file"
> The txtwrite device was leaving the 'returned' glyph unset when it needed
> to run the CDevProc for a CIDFont. This could later cause a crash because
> other code would attempt to use the uninitialised variable.
> No differences expected.
> gs/devices/vector/gdevtxtw.c

2013-11-28 18:24:03 +0000
Robin Watts <robin.watts@artifex.com>
748013087dd75882abbcfe4c630eeddb059be773

> Bug 694362: More tweaking in jbig2dec.
> Following more discussions with Simon, and testing within MuPDF, it
> appears that the original code was correct. I am therefore restoring
> the original behaviour, except with a direct jump to cleanup rather
> than relying on dropping into the following case.
> This will result in just 1 error being given, and is cleaner, to my
> mind.
> gs/jbig2dec/jbig2_symbol_dict.c

2013-11-28 17:51:02 +0000
Robin Watts <robin.watts@artifex.com>
fa25793292f8e6799ecad1bcd6565206b7566664

> More work on bug 694362
> Back out some 'unreachable code' that I had accidently added back in.
> Remove a couple of unreachable 'break;' statements too.
> gs/jbig2dec/jbig2.c
> gs/jbig2dec/jbig2_segment.c
> gs/jbig2dec/jbig2_symbol_dict.c

2013-11-28 16:43:26 +0000
Robin Watts <robin.watts@artifex.com>
e697fc428f4cca033d0b844cc4bceebffe50e853

> Pull changes back from mupdf's version of jbig2dec to gs's.
> MuPDF now tracks the version of jbig2dec extracted from gs.
> Shelly spotted a couple of minor things that had been lost as
> part of his investigation into bug 694362. Pull them back
> across.
> gs/jbig2dec/jbig2.c
> gs/jbig2dec/jbig2_segment.c
> gs/jbig2dec/jbig2_symbol_dict.c

2013-11-27 09:38:02 +0000
Ken Sharp <ken.sharp@artifex.com>
01cef1fd7dbaf3ef48dcff9e23875980265f2859

> pdfwrite - ignore annotation /AP where the appearance is not a stream
> Bug #694809 "Conversion of PDF-file fails with typecheck-error"
> The speciment PDF file has an invalid appearance for an annotation:
> 182 0 obj
> <<
> /AP << /N << /Yes /null >> >>
> The normal appearance should be a dictionary where each key value pair has
> a value which is a stream. /null is not a stream.
> This commit drops annotations with this problem and emits a warning.
> No differences expected.
> gs/Resource/Init/pdf_draw.ps

2013-11-27 10:44:28 +0100
Till Kamppeter <till.kamppeter@gmail.com>
87a7fd8afe9af506bf91024d8cc60ef0721450d5

> "cups" output device: Support for PPD-less printing and PWG Raster output
> 1. PWG Raster output: With -sMediaClass=PwgRaster the output is in PWG
> Raster format and not in CUPS Raster format. TODO: Create "pwg" or
> "pwgraster" output device name for that.
> 2. Support for PPD-less printing: If the "PPD" environment variable is
> not set to a valid PPD file, allow setting unprintable margins via
> something like:
> "-c '<</.HWMargins[12 12 12 12] /Margins[0 0]>>setpagedevice'"
> 3. Correct rounding by adding 0.5 to float numbers before converting
> them to integer.
> gs/cups/gdevcups.c

2013-11-27 08:43:53 +0000
Ken Sharp <ken.sharp@artifex.com>
49f620bbdabaa186b56cb783afd30bcfc8ca40ef

> pdfwrite - remove an unused variable to silence a compiler warning
> gs/devices/vector/gdevpdfv.c

2013-11-26 16:20:18 +0000
Ken Sharp <ken.sharp@artifex.com>
fe99ca5fd2e3b191a76c7f7d791b72f3603e9fea

> pdfwrite - spot reuse of shading dictionaries and don't emit multiple times
> Bug #689247 "pdfwrite creates redundant shadings"
> Previously we always made a new shading and pattern dictionary every time
> we encountered a shading. Taking advantage of the hashing mechanism that
> was written to improve performance, we can now spot reuse of shading
> dictionaries, and emit only a single copy.
> The output from the test file now only contains 106 shadings and patterns
> and the compressed file size is reduced by 41% as a result.
> No differences expected.
> gs/devices/vector/gdevpdfv.c

2013-11-26 09:21:13 +0000
Chris Liddell <chris.liddell@artifex.com>
fb3e5c6278fc7ea5e1bfdb3a23944cdcce13eb5a

> Change the order of checks when enumerating PCL fonts.
> We need to check whether the MT fonts have populated the font dictionary
> before we worry about whether there's a path to find the TTF versions of the
> built-in fonts.
> No cluster differences.
> pl/pllfont.c

2013-11-20 14:55:12 +0000
Chris Liddell <chris.liddell@artifex.com>
9ecb86e69f473d8c981baeca6885d67b23964440

> pcl/FAPI MT font fixes.
> Fix a problem with parsing out the FCO paths from the FCO list string (we could
> run off the end of the string).
> Make the "header" byte swapping call conditional on being a little-endian
> platform.
> Fix a makefile hiccup that resulted in the FCO files being built into the romfs
> twice.
> CLUSTER_UNTESTED
> gs/base/fapiufst.c
> main/pcl6_gcc.mak
> pl/pllfont.c

2013-11-26 12:07:13 +0000
Ken Sharp <ken.sharp@artifex.com>
90ec17f20be53db00fcbc2ada6931e7cc7b22b9e

> pdfwrite - fix dictionary stream hashing
> The dictionary stream hashing code didn't initialise the MD5 hash before
> using it, which could lead to problems. Also the cos_stream_equal routine
> was passing in an MD5 state which would then be reused inside the hashing
> code. Although this doesn't seem to cause a problem, and we don't actually
> use that state, its safest if we make use a dummy instead.
> Problems discovered while working on duplicate shadings.
> No differences expected
> gs/devices/vector/gdevpdfo.c

2013-11-25 18:26:20 +0000
Robin Watts <robin.watts@artifex.com>
83fb95771604bd85b1b3345f67d83cc99c69bfd9

> Bug 694245: Fix valgrind problems.
> During stroke calculations, ff we have a non-invertible matrix, then
> use 0 as the calculated distance, rather than running with
> undefined values. We were failing to check for an error code.
> Returning an error code stops rendering, so swallow the error and
> continue with 0.
> gs/base/gxpdash.c
> gs/base/gxstroke.c

2013-11-25 18:39:05 +0000
Robin Watts <robin.watts@artifex.com>
7be77f2a74952c2d7f8f3969ae885a014b51513c

> Add missing Makefile header dependency.
> gs/base/lib.mak

2013-11-25 09:58:08 -0800
Ray Johnston <ray.johnston@artifex.com>
0d8fcaef61f7af1a032f9dff8d38957b335ee8cc

> Remove #define DEBUG_TRACE_PS_OPERATORS inadvertently left enabled.
> gs/psi/iinit.c
> gs/psi/iinit.h

2013-11-25 14:33:12 +0000
Robin Watts <robin.watts@artifex.com>
7b3a65aab20feac334cac8e5935ba5cbe310ac69

> Fix previous commit; align_bitmap_mod is in bytes not bits.
> Correct the calculations in the previous commit.
> gs/base/gsiparam.h

2013-11-25 13:24:03 +0000
Robin Watts <robin.watts@artifex.com>
b81962611a292e1b2c5306f3d5cdfea832715169

> Bug 694601: Fix big endian crash in mem_mono_copy_mono.
> While the crash is reported on a big endian device, the problem actually
> potentially occurs on little endian systems too. As it happens,
> x86, amd64, and many ARM configurations will read happily from unaligned
> addresses. Some ARMs and many other processors will not, however, so we
> apply a fix that will work properly everywhere.
> When calling device level functions, we should ensure that the 'raster'
> given is always a multiple of align_bitmap_mod bits.
> Thanks to John Wehle for the bug report and suggested fix.
> gs/base/gsiparam.h

2013-11-23 21:37:03 -0800
Ray Johnston <ray.johnston@artifex.com>
4a72e695c6ad632a38d27eaaa45bdbad8b5a0fa1

> Fix garbage output with --saved-pages due to not doing needed erasepage.
> Actions which print, or reallocate to clist mode or page mode, may
> need the page to be erased. This includes the 'print' action. Seen
> with 12-07C.PS when gs_cet.ps is used.
> Also, don't allow "copies n" without a prior "begin".
> Silence a few build warnings (missing dependency)
> gs/base/gxclpage.c
> gs/base/gxclpage.h
> gs/psi/iinit.h
> gs/psi/imainarg.c
> gs/psi/int.mak

2013-11-20 17:03:48 -0800
Ray Johnston <ray.johnston@artifex.com>
006051023733a636fc7e61754489e05fa38acdea

> Remove FORCE_SAVED_PAGES_TEST since cluster now supports extras=...
> Also clean up some compiler warnings.
> gs/psi/imain.c
> gs/psi/imainarg.c
> gs/psi/iminst.h

2013-10-23 11:36:09 -0700
Ray Johnston <ray.johnston@artifex.com>
54610538e180cb5cb9b80c51f9a8a3d5b9bba5c2

> Make order of --saved-pages-test and --saved-pages= options position independent.
> The position of these command line options had been required to be the
> last option prior to the first file to run, but this is not how most
> other command line options operate. This allows the --saved-pages-test
> or --saved-pages=begin option to be placed anywhere in the command line.
> The debug option to FORCE_SAVED_PAGES_TEST is now in psi/imain.c
> and the OMIT_SAVED_PAGES_TEST is removed.
> gs/psi/imain.c
> gs/psi/imainarg.c
> gs/psi/iminst.h

2013-10-05 12:27:58 -0700
Ray Johnston <ray.johnston@artifex.com>
97535718d671b728c47f7bbc35512449c47d2bc1

> Fix more Segfaults with --saved-pages and psdcmyk and many differences.
> Devices that have devn paramaters could close the device so make sure
> and open it. Also set banding_type to BandingAlways while in saved-pages
> mode and restore it when we end saved-pages mode.
> A few files still segfaulted, and there were many differences because
> the page was not erased after the saved-pages "begin".
> In gx_saved_page_load, for pages that fit in a single band (as with
> large -dMaxBitmap values), reset the ymin and ymax to force rasterizing
> the next page's clist.
> gs/base/gxclpage.c
> gs/base/gxclpage.h
> gs/psi/imainarg.c
> pl/plmain.c

2013-11-22 17:34:46 +0000
Chris Liddell <chris.liddell@artifex.com>
55d90681fd4eb85fa8d38b965fb31d12cdb133e2

> Enable shared library builds on AIX (gcc only)
> Add the code to detect AIX (and gcc), and setup the command like arguments
> so the "make so" targets works.
> There is still a "duplicate symbols" warning on ".main" when linking to the
> shared lib - none of the documented options seemed to resolve that.
> No cluster differences.
> gs/configure.ac

2013-11-22 15:23:00 +0000
Ken Sharp <ken.sharp@artifex.com>
cdd142387a04a6d7ea519838e15204c4d7c681d8

> pdfwrite - flush streams before attempting to MD5 hash them
> This was discovered in the process of other work. Its possible that when we
> MD5 hash a stream, its still partially or fully buffered, not written to
> the asides file. This commit makes sure that the streams are flushed first.
> No differences expected.
> gs/devices/vector/gdevpdfo.c

2013-11-22 12:16:40 +0000
Robin Watts <robin.watts@artifex.com>
82e02b0dc49b51fbe4851a16a669ef83d35a2fae

> Bug 694803: Fix truncated psd files.
> GS can truncate the number of spots used if we are working with PDF
> files, hence not all 6 planes may be written. Fix this here.
> gs/devices/gdevcmykog.c

2013-11-22 14:09:34 +0000
Robin Watts <robin.watts@artifex.com>
47584728a68520b754ba97f0bcbf001a19d8271b

> Bug 694802: psdcmykog files truncated on MacOS.
> It appears that macos will not allow you to read from files opened
> as "wb", so use "w+b" instead. I probably should have been using this
> anyway.
> gs/devices/gdevcmykog.c

2013-11-21 16:51:29 +0000
Robin Watts <robin.watts@artifex.com>
16c29cb9deb49be55c582213469ff6993d26c731

> Bug 694798: Fix SEGV with psdcmykog device.
> The alignment/padding code was going wrong. In cases where the device
> changes size and reallocates, we were attempting to resize the buffer
> memory using the aligned pointer rather than the unaligned pointer.
> gs/base/gdevmem.c

2013-11-21 15:01:16 +0000
Robin Watts <robin.watts@artifex.com>
1829196ecccb692765c27c9b3eac13367cf50204

> Bug 694797: Remove stray code from psdcmykog device.
> Some stray code in the close method was causing the device to clear the
> file on exit. This only seems to happen in some cases though. Just
> removing the code should solve it.
> gs/devices/gdevcmykog.c

2013-11-21 14:32:23 +0000
Ken Sharp <ken.sharp@artifex.com>
1eeb45d0537ba8e561f27d6461fc5b62bd042340

> pdfwrite - honour device-independent color conversion strategy for images
> Bug #694799 "New: incoherent output intent and color space in PDF/A (bis)"
> The image colour conversion wasn't writing a device independent colour
> space for UseDeviceIndependentColor or sRGB, but was instead writing
> the original colour space.
> No Differences expected.
> gs/devices/vector/gdevpdfi.c

2013-11-20 12:46:01 +0000
Robin Watts <robin.watts@artifex.com>
8a94e4ee285f8b7d2f04edf2d8ac35f687355061

> Remove boilerplate from gdevcmykog
> gs/devices/gdevcmykog.c

2013-11-19 19:57:33 +0000
Robin Watts <robin.watts@artifex.com>
bbaff51c391f0e3e6c0503da9f355c96a739c1b4

> Silence warning.
> gs/devices/gdevpsd.c

2013-11-19 10:14:04 -0800
Ray Johnston <ray.johnston@artifex.com>
5af6431204f15f89519aac55c8d8ff42c823ced7

> Fix misplelling of 'parent' in the gp files.
> gs/base/gp.h
> gs/base/gp_dosfs.c
> gs/base/gp_macio.c
> gs/base/gp_ntfs.c
> gs/base/gp_os2fs.c
> gs/base/gp_unifn.c
> gs/base/gp_vms.c
> gs/base/gpmisc.c

2013-11-19 19:18:50 +0000
Robin Watts <robin.watts@artifex.com>
ab73cd1550f558f5e1a82e60d95339b044713976

> Solve psdcmykog hang on MacOSX.
> Mac gets hung in the collating phase, presumably due to different
> handling of eof conditions for read/write file handles.
> Also, fix a mistake that can cause SEGVs in non debug versions.
> gs/devices/gdevcmykog.c
> gs/devices/gdevpsd.c

2013-11-19 17:03:27 +0000
Robin Watts <robin.watts@artifex.com>
9f03f419cc8cc598c2a9b4e94e41d6cfdad61c02

> Various small fixes for psdcmykog build issues.
> Rename the device. Include it in linux builds by default, along with
> fpng.
> Fix various warnings.
> gs/Makefile.in
> gs/base/gdevdevnprn.h
> gs/base/lib.mak
> gs/base/unix-gcc.mak
> gs/base/unixansi.mak
> gs/configure.ac
> gs/devices/devs.mak
> gs/devices/gdevcmykog.c
> gs/devices/gdevfpng.c
> gs/psi/msvc.mak

2013-11-15 18:30:21 +0000
Robin Watts <robin.watts@artifex.com>
3cee4eb9e3c24e0a2e7c48fddc473590c5a820b6

> Make garbage collector private.
> Private is better than public.
> gs/base/gsgcache.c

2013-11-18 16:20:05 +0000
Robin Watts <robin.watts@artifex.com>
be1e5a0dde242dc41f4e67a629d6bf403ac2938b

> Update psdcmykog to use common psd writing functions.
> gs/devices/gdevcmykog.c

2013-11-15 17:24:04 +0000
Robin Watts <robin.watts@artifex.com>
bf2404a47b8b2843e37efbb0d242e5b46357b588

> Tweak psdcmykog.c to use gdevdevnprn.h functions.
> This reduces the boilerplate.
> gs/devices/gdevcmykog.c

2013-11-06 17:52:25 +0000
Robin Watts <robin.watts@artifex.com>
8cb60cfe03ab7f1ada9b26eb57342fa9eca62e48

> psdcmykog: simple example process_page device
> This device demonstrates a range of facilities newly added to
> the Ghostscript core. This device exists as an exemplar for these
> facilities, and as a mechanism to allow us to cluster test.
> gs/devices/devs.mak
> gs/devices/gdevcmykog.c
> gs/ghostscript.vcproj
> gs/psi/msvc.mak

2013-11-18 16:19:12 +0000
Robin Watts <robin.watts@artifex.com>
7089d5416766a4a526b382e57e4436633d29bb9e

> Externalise psd writing functions.
> This will enable psdcmykog to share the psd writing functions.
> gs/base/gdevdevnprn.h
> gs/devices/gdevpsd.c

2013-11-15 17:14:14 +0000
Robin Watts <robin.watts@artifex.com>
a1bee59ddf2bf82273359564d6cdb8e0549ae14f

> Extract guts of spotcmyk device to be reusable.
> Whenever we build a "devicen" based device, there is a lot of repeated
> code. Tweak the spotcmyk functions (one such device) into a form where
> they can be reused more easily.
> Also add cmyk_equiv_colors into this extracted structure. This shouldn't
> matter to code that doesn't use the equivalent colors, (i.e. spotcmyk
> and devicen will be unaffected), but should allow us to bring the psd
> devices into the fold.
> gs/base/gdevdevn.c
> gs/base/gdevdevnprn.h
> gs/base/lib.mak
> gs/devices/gdevpsd.c
> gs/ghostscript.vcproj

2013-11-18 15:43:32 +0000
Ken Sharp <ken.sharp@artifex.com>
a65b8db506a553334de495a9b27a18811188539a

> pdfwrite - new colour code, emit sRGB as ICCBased
> Bug #694780 "incoherent output intent and color space in PDF/A"
> sRGB was supposed to be written as ICCBased, but the code has a special
> check to see if the ICC profile being used is one of the default ones
> (ie its our ICC equivalent of Gray, RGB or CMYK) and if it is, we write
> the original colour apace out.
> Added a boolean to override this behaviour so that when we emit sRGB we do
> in fact write the ICCBased equivalent profile for RGB.
> No differences expected.
> gs/devices/vector/gdevpdfb.c
> gs/devices/vector/gdevpdfc.c
> gs/devices/vector/gdevpdfg.c
> gs/devices/vector/gdevpdfg.h
> gs/devices/vector/gdevpdfi.c
> gs/devices/vector/gdevpdfk.c
> gs/devices/vector/gdevpdft.c
> gs/devices/vector/gdevpdfv.c

2013-11-15 13:21:42 +0000
Ken Sharp <ken.sharp@artifex.com>
d2804d480928140577560f673eb6a6419afb9abd

> AES decryption - Don't return an error if the input is not a multiple of 16 bytes
> Bug #694781 "Regression: error reading PDF files starting with 4885eb2fa363002fdf0980cd189f2a5bb9340f58"
> The stream is technically invalid, it should be a multiple of 16 bytes in
> length. Acrobat as usual silently ignores the error.
> We now emit a warning but carry on.
> No differences expected
> gs/base/saes.c

2013-11-07 12:36:18 -0800
Ray Johnston <ray.johnston@artifex.com>
b83ce7db814dd026b97bf2e00429459fc9c1f296

> Improve collection of color_usage.or bits and track devn colors.
> Some of this was in place with cmd_drawing_color_usage, but it was
> not used many times, and it just returned 'all'. Also, add the
> check for devn colors that are widely used with planar devices
> such as psdcmyk.
> Also handle the color_usage_array in the setup and teardown of the
> BGPrint thread and/or multiple rendering threads.
> gs/base/gxclimag.c
> gs/base/gxclpath.c
> gs/base/gxclrect.c
> gs/base/gxclthrd.c

2013-11-14 12:11:02 -0800
Ray Johnston <ray.johnston@artifex.com>
db89e2390033fde0c69ffc01aeff346296336907

> Fix SEGV with BGPrint=true -dNumRenderingThreads=2
> With BGPrint=true, the icc_cache_list for the rendering threads was
> allocated using 'mem', but was being freed using mem->thread_safe_memory.
> The BGPrint clist device 'mem' is a chunk allocator but its thread
> safe memory is the heap allocator.
> gs/base/gxclthrd.c

2013-11-14 17:02:27 +0000
Robin Watts <robin.watts@artifex.com>
026a7ed96060a9f9a11a16857a9549f77ed5042b

> Fix alignment of memory buffers in page mode.
> The setup buffer call was setting the 'base' member to it's aligned
> version, and the caller was then overwriting it with the unaligned
> version. Simply remove the override.
> gs/base/gdevprn.c

2013-11-14 14:02:05 +0000
Robin Watts <robin.watts@artifex.com>
10b2168ba0a3973ce1e98b8405e01bc7d235464d

> Correct raster calculation in get_bits_rectangle for planar case.
> gs/base/gdevdgbr.c

2013-11-13 09:29:55 -0800
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
ea5452061ce70ada597888e629e6f6e9ca09ab10

> Fix building WIN64=1 with Visual Studio 2013 and add pam to default devices.
> gs/psi/msvc.mak

2013-11-13 16:57:46 +0000
Robin Watts <robin.watts@artifex.com>
428f750746c09af66e53eed08a9fabf8dba2fef8

> Bug694768: Fix VMerrors during pattern processing.
> In a recent commit I moved the line_ptrs into the clist data block.
> Don't do this for pattern accumulator operation, as the logic is
> different.
> gs/base/gxclist.c
> gs/base/gxclread.c
> gs/base/gxclthrd.c

2013-11-13 15:38:45 +0000
Robin Watts <robin.watts@artifex.com>
d42c77506452de368bebb64e61fd5f0b7347b343

> Fix SEGVs caused by icc_cache_cl memory space change.
> A few commits ago, we moved the icc_cache_cl used for NRT > 0 to the
> thread safe memory handler. This meant it was no longer in gc-able
> space, so we therefore removed the enumeration of icc_cache_cl from
> the clist structure definitions.
> Unfortunately I forgot to move the non-NPR related allocations of
> icc_cache_cl to the same thread safe handler, meaning that they were
> still being allocated in gc-able memory and causing crashes. For
> example:
> gs/debugbin/gswin32c.exe -Z@ -o out.pbm -sDEVICE=ppmraw -r300
> -dMaxBitmap=400000000 ../ghostpcl/tests_private/comparefiles/Bug690189c.pdf
> gs/base/gxclist.c
> gs/base/gxclpage.c
> gs/base/gxclthrd.c
> gs/base/gxp1fill.c
> gs/base/gxpcmap.c

2013-11-13 14:03:30 +0000
Robin Watts <robin.watts@artifex.com>
0c50e7ba960e2ed37deb87501d8b966e5d800cd8

> Fix crash with NPR > 0 and planar devices.
> A command such as:
> gs -sDEVICE=psdcmyk -r300 -dMaxBitmap=10000 -dNumRenderingThreads=3
> gs/examples/tiger.eps
> would crash with a SEGV due to an incorrect calculation for raster in
> get_bits_rectangle.
> clustercmd
> clusterdatestamp
> gs/base/gxclthrd.c

2013-11-13 13:35:56 +0000
Ken Sharp <ken.sharp@artifex.com>
f221142fa36adc5a3d1192e534196dd4a7e953b4

> PDF interpreter - more heuristics to work around broken PDF files
> Bug #594772 " Regression: missing data reading PDF files starting with d5c42d3a14cee808fd889c14805a69adae8eb5b9"
> The PDF file is broken, it has a font with a FontMatrix where one of
> the values is 0.-4.
> Previously we used .pdftokenerror which would detect
> this and convert the value to 0 (observed Acrobat behaviour). However at
> some point this was modified so that if we are not in a content stream we
> convert into a name object instead.
> This doesn't work in the case of a matrix. Unfortunately changing it back
> broke *many* PDF files. Almost all of them from SumatraPDF and they are
> also badly broken but still....
> In essence we want to treat broken numbers as '0' and broken anything else
> as a name. So the code now tries to decide if the input looks like a broken
> number (contains 0-9, ',', '.' or '-' and nothing else). If it looks like a
> number we pass it through .pdftokenerror which will convert it to 0. It is
> possible for .pdftokenerror to throw an error, though, so we run it in a
> stopped context and if it does, we convert to a name instead. If it doesn't
> look like a number, we just convert it to a name.
> This causes differences in Bug694429.pdf, but the differences are that more
> text is now drawn. The output was wrong before, its wrong now, its merely
> wrong in a different way.
> gs/Resource/Init/pdf_base.ps

2013-11-12 16:19:46 -0700
Henry Stiles <henry.stiles@artifex.com>
4d3dc3a3a6948a49a2e8faed57290da40a774703

> Fix 694773 - default raster resolution to the PJL setting when in
> HPGL/RTL mode.
> pcl/rtgmode.c

2013-11-11 19:07:09 +0000
Robin Watts <robin.watts@artifex.com>
a0a9d6746cf2e911c2db54c756e34e9e52c0723a

> Introduce a list of device caches within the clist.
> This is only used when NumRenderingThreads > 0, and avoids us recreating
> caches every page.
> We allocate the cache list with the thread safe allocator. This has the
> effect of moving the icc_cache_cl entries out of the thread specific
> chunked allocators, and also out of garbage collected memory. We
> therefore remove the code to enumerate icc_cache_cl.
> Also, this has the effect of fixing a gc enumeration bug where the first
> element of the imager state wouldn't have been enumerated.
> gs/base/gdevprn.c
> gs/base/gxclist.c
> gs/base/gxclist.h
> gs/base/gxclthrd.c
> gs/base/gxclthrd.h

2013-11-12 17:26:13 +0000
Robin Watts <robin.watts@artifex.com>
482b8b302399afda3b14242c56209a76694e0062

> Fix reference counting for icc_cache_cl in clist.
> Currently we only rc_decrement the icc_cache_cl entry in the bg_print
> case. We should really be decrementing in all cases, but we get away
> with this because the icc_cache_cl entries are allocated in the
> rendering threads own chunked allocator which is destroyed after each
> run.
> In a soon-to-come commit, icc_cache_cl will be moved out of the
> thread specific chunked allocator, and these will become real leaks.
> The simple fix is to rc_decrement in all cases.
> gs/base/gxclthrd.c

2013-11-12 18:31:50 +0000
Robin Watts <robin.watts@artifex.com>
a0386e872771958c67874ab4ef45eb8f43c63f77

> Add 'extras' option to clusterpush.pl
> Use:
> clusterpush.pl gs lowres extras=-dNumRenderingThreads=3
> to specify extra args to supply to all jobs.
> clustercmd
> clusterdatestamp
> gs/toolbin/localcluster/clusterpush.pl

2013-11-11 19:06:41 +0000
Robin Watts <robin.watts@artifex.com>
6d4dc3c736c4cdf9e1728484857c613baf6ba3b4

> Silence build warning.
> Downcast to the basic device.
> gs/devices/gdevfpng.c

2013-11-12 10:33:42 +0000
Chris Liddell <chris.liddell@artifex.com>
f15da3a62aed425e85597b8482daf7ff778beb31

> GS_THREADSAFE: don't ignore "basic" fills....
> In the default "fill" device method, don't drop the call to
> gx_general_fill_path() for the GS_THREADSAFE build.
> No cluster differences.
> gs/base/gxfill.c

2013-11-11 16:56:11 +0000
Ken Sharp <ken.sharp@artifex.com>
bcb467c754a7a292f2ed65e61953782577e0412d

> pdfwrite - set CIDToGIDMap correctly for PDF/A-2 output
> Bug #694769 "Fonts changed from TrueType to CID TrueType and not displaying correctly in output PDF"
> We opted not to emit CIDSet for PDF/A-2 since its now documented as
> optional and I wasn't able to find a CIDSet which would pass Acrobat's
> preflight tool.
> However, the code also skipped the correct setup of the CIDToGIDMap and we
> can't do that or the output will be incorrect.
> This commit makes PDF/A-1 and PDF/A-2 behave the same with respect to the
> CIDToGIDMap.
> No differences expected, we don't test PDF/A production
> gs/devices/vector/gdevpdtd.c

2013-11-11 10:42:06 +0000
Chris Liddell <chris.liddell@artifex.com>
f9774c5ae1b9cb12a811d810787b3e21d001a08f

> Bug 694767: have configure set some Trio flags.
> For systems that lack some math functions.
> No cluster differences.
> config.mak.in
> configure.ac
> gs/Makefile.in
> gs/configure.ac

2013-11-11 16:14:21 +0000
Chris Liddell <chris.liddell@artifex.com>
efc0ab29473b65f1f0a119023601d987921373c0

> Bug 691498: only declare Windows DLL exports once.
> Using both the __declspec(dllexport) form *and* the .def file results in export
> symbols being declared twice, and warning from the linker (but only on x86_64
> for unknown reasons!).
> See: http://support.microsoft.com/kb/835326
> The original uses of __declspec(dllexport) are left in place, but conditionally
> compiled out, just in case.
> CLUSTER_UNTESTED
> gs/base/gs_dll_call.h
> gs/psi/iapi.h

2013-11-11 12:41:02 +0000
Alan Hourihane <alanh@fairlite.co.uk>
48a0dd978939fb6ae7bd445fd7b07bcf3b918948

> Bug 694766: rename "internal" SHA symbols
> Prevent linker errors when linking to something else that uses SHA, by
> prepending "p" (for private) to our "internal" SHA symbols.
> gs/base/sha2.c
> gs/base/sha2.h

2013-11-11 09:07:07 +0000
Ken Sharp <ken.sharp@artifex.com>
c6d592ef12079f3a1ea7b9218620f813769c3654

> pdfwrite - when unable to convert a Shading colour space, fallback to image
> Bug #688731 "Huge PDF file with ProcessColorModel=/DeviceCMYK and ColorConversionStrategy=/CMYK"
> When we can't convert the colour space of a shading dictioanary to satisfy
> the ColorConversionStrategy we currently fall back to the rendering method
> used by gx_fill_default, which is to degenerate into parallelograms.
> This results in hugs and very slow PDF files.
> This commit tests the ColorConversionStrategy when we detect an inability
> to include a Shading unchanged, and if the strategy is not 'LeaveCOlorUnchanged'
> then we use the ps2write approach and render the shading to an image instead.
> This produces smaller faster output and the quality can be controlled by
> setting resolution with the -r switch allowing a tradeoff between size and
> quality.
> If we should be unable to embed a shading for other reasons we will still
> fall back to the parallelograms method. We may want to avoid this in all
> circumstances, but lets wait for an example before we decide.
> No differences expected.
> gs/devices/vector/gdevpdfd.c

2013-11-08 18:33:23 +0000
Robin Watts <robin.watts@artifex.com>
db8fcdf94105c55a8886203254e401b601f29a69

> Remove dev->num_planes in favour of dev->is_planar.
> This removes the need to remember to keep
> dev->num_planes == dev->color_info.num_components for all planar
> devices.
> gs/base/gdevdevn.c
> gs/base/gdevdrop.c
> gs/base/gdevmem.c
> gs/base/gdevmpla.c
> gs/base/gdevp14.c
> gs/base/gdevppla.c
> gs/base/gdevprn.c
> gs/base/gsdevice.c
> gs/base/gsovrc.c
> gs/base/gxclimag.c
> gs/base/gxclip.c
> gs/base/gxclist.c
> gs/base/gxclist.h
> gs/base/gxclthrd.c
> gs/base/gxdevcli.h
> gs/base/gxht_thresh.c
> gs/base/gxicolor.c
> gs/base/gximono.c
> gs/base/gxp1fill.c
> gs/base/gxpcmap.c
> gs/devices/gdevplib.c

2013-11-08 16:40:10 +0000
Robin Watts <robin.watts@artifex.com>
c0e10e8636386abf427f922390445b0b6cb2bb59

> Fix SEGV in psdcmyk.
> tests_private/pdf/sumatra/586_-_missing_images_gs_SMask_not_applied.pdf.psdcmyk.300.1
> It seems num_planes was getting out of sync with color_info.num_components.
> gs/base/gdevp14.c

2013-11-08 17:55:04 +0000
Ken Sharp <ken.sharp@artifex.com>
1cb2458772321dc86117cb45b5b28a1423ccf9b7

> pdfwrite - free any allocated memory when initialising stream filters
> Bug #694758 "Segmentation Fault"
> It seems that the arcane image setup sequence used by pdfwrite can result
> in us calling stream 'init' functions more than once for the same stream.
> Some of the stream filters (Average and Bicubic) allocate some working
> memory in the 'init' procedure, but they don't check to see if the
> working memory has already been allocated.
> This is primarily a cause of memory leaks, though since the memory is
> garbage collected it won't (probably) actually leak. However it *does*
> seem to confuse the garbage collector when relocating the stream state
> structure. We allocate a buffer 9.9Kb but when we come to use it it has
> shrunk to a little over 1Kb.
> This commit checks the working memory and if its not NULL then we free it
> before re-allocating (we might be re-initialising to a different size) which
> resolves the problem for me. However because it changes the memory pattern
> its possible this is simply masking the problem. Note that this change
> assumes that the structure members will be set to NULL when the structure
> is allocated (which it always is at the moment).
> No differences expected
> gs/devices/vector/gdevpsds.c

2013-11-08 16:08:41 +0000
Chris Liddell <chris.liddell@artifex.com>
656f26c232933c6b3c29d2e6b37574096572f35a

> Bug 694622: address a compiler warning.
> Use sprintf() instead of gs_sprintf() for "top level" code.
> CLUSTER_UNTESTED
> gs/psi/dxmain.c

2013-11-08 09:52:25 +0000
Chris Liddell <chris.liddell@artifex.com>
8f2a046ddc81258749e73cfc7a6daf0a43488181

> Bug 694624: remove couple of deprecated filters.
> Remove the Bounded Huffman and Burrows-Wheeler filters: not required by any
> of the interpreters, and not used anywhere else.
> No cluster differences.
> gs/base/sbhc.c
> gs/base/sbhc.h
> gs/base/sbwbs.c
> gs/base/sbwbs.h
> gs/base/shcgen.c
> gs/base/shcgen.h
> gs/doc/Develop.htm
> gs/psi/int.mak
> gs/psi/zfilterx.c

2013-11-08 13:26:29 +0000
Robin Watts <robin.watts@artifex.com>
a9567942aa10ef2321627316d6f647819584179d

> Solve SEGV due to recentl planar changes.
> tests_private/comparefiles/Bug692217.pdf.psdcmyk.72.0 would SEGV.
> This was because num_planes was getting out of sync with num_components.
> gs/base/gdevp14.c

2013-11-07 17:30:06 +0000
Chris Liddell <chris.liddell@artifex.com>
f59dba325a55dd25ad6b5af4f9579b21bd562eb2

> Bug 690878: have ghostpdl use HAVE_FILE64 setting
> The GhostPDL configure checked for, but the config.mak.in never used the setting
> for HAVE_FILE64.
> Add it in.
> No cluster differences.
> config.mak.in

2013-11-07 17:21:27 +0000
Chris Liddell <chris.liddell@artifex.com>
31120fdcbb3f1ab815ade3763b638b77bd9b3d76

> Bug 690776: missing check for HAVE_MKSTEMP64
> Oddly, the ghostpdl configure.ac checked for mkstemp64 but config.mak.in did not
> have the substitution pattern for the -DHAVE_MKSTEMP64.
> So add that in.
> No cluster differences.
> config.mak.in

2013-11-07 15:37:37 +0000
Dr. Werner Fink <werner@suse.de>
4a4a912b43ae85b8c3d07f6d4727ced14b2e102a

> Bug 690571: deal with memory dev/xdev dimensions being different.
> For GV (and ghostview) a memory deivce is used. The problem is now
> that most time the width and height of the memory device is not
> identical with the xdev device its self. Also extrem large bbox
> can lead to problems on systems with less physical memory.
> This patch avoids these two problems.
> No cluster differences.
> gs/devices/gdevx.c

2013-11-07 20:12:14 +0000
Robin Watts <robin.watts@artifex.com>
c4357befbf3d09c50c4208bbb5dd9864269bf9b3

> Fix previous tweak to clist line_ptrs.
> The calculation for the clist line_ptrs used before was broken; I guess
> this proves that we weren't relying on it in most cases. This solves
> a few SEGVs.
> gs/base/gdevppla.c
> gs/base/gxclread.c
> gs/base/gxclthrd.c

2013-11-07 18:29:46 +0000
Robin Watts <robin.watts@artifex.com>
64a57147f683bfbf4c9f2bfcd978e8bcbd87ad97

> Fix SEGV in psdcmyk cluster tests.
> tests_private/comparefiles/09_47N.PDF.300.1 SEGVs due to typo in
> gx_forward_strip_tile_rect_devn.
> gs/base/gdevnfwd.c

2013-11-07 09:49:47 -0800
Ray Johnston <ray.johnston@artifex.com>
1805749a2338844f19a3c7d336fd4707d04b13de

> Fix fpng crash, file has_transparency
> In clist_playback_band, it checks to see if there is a compositor as
> the target, and needs to free it, but it should not close the device
> if its is_open is false, since that would forward the close to the
> orig_target, closing the memory device. The pdf14 pop_device had
> already done the pdf14_close and set the procs to forward.
> gs/base/gxclrast.c

2013-11-07 17:23:40 +0000
Robin Watts <robin.watts@artifex.com>
6efb9ed5890e7b56814699f6e374de97602a0a1b

> Squash some warnings.
> gs/base/gdevmem.c
> gs/base/gdevmpla.c
> gs/base/gdevp14.c
> gs/base/gdevppla.c
> gs/base/gsicc_manage.c
> gs/base/gsicc_nocm.c
> gs/base/gxccman.c
> gs/base/gxclthrd.c
> gs/base/gximage3.c
> gs/base/gxpcmap.c
> gs/devices/gdevpsd.c
> gs/devices/vector/gdevpdfd.c

2013-11-07 15:47:19 +0000
Robin Watts <robin.watts@artifex.com>
432f71e687183df4971c0bee1932fb57ef0295a1

> Tweak clist line_ptrs data.
> The clist has always allocated space for the memory device as if
> the line_ptrs were to be included within the allocated space, but
> has never actually put the line_ptrs into this space.
> Consequently the memory device always allocates space for the
> line_ptrs itself. This space is then freed on a close_device call.
> This can present problems in NumRenderingThreads mode, when
> process_page is used. With the existing code, within clist_render_thread,
> the buffer device is setup (and the new line_ptrs block is allocated).
> The device is then freed at the end of clist_playback_band
> (called from clust_render_rectangle). This nukes the line_ptrs
> leaving the get_bits_rectangle call from within the process_fn call
> to fail when dereferencing NULL.
> The fix here is to amend the clist device structure to include the
> offset within the block that the line_ptrs should be allocated at.
> This offset can then be used to pass in the address of the line_ptrs
> to the setup_buffer_device call. This means the line_ptrs survive
> device closing.
> This still leaves questions (in my mind at least) as to whether the
> handling of the device closures within clist_playback_band is correct
> or not.
> gs/base/gxband.h
> gs/base/gxclist.c
> gs/base/gxclthrd.c

2013-11-07 10:37:34 +0000
Ken Sharp <ken.sharp@artifex.com>
cfeb9f98b896384ac366f4e30f3653a52de7af87

> pdfwrite - add a Resources dictionary to 'Group' dictionaries
> Bug #693322 "Acrobat Preflight tool reports missing XObjects"
> Crazy Cairo-constructed files can result in Group dictionaries which use
> other resources (in this case an ExtGState) and this wasn't possible in
> the existing code. This commit adds a Resources dictionary so that it is
> now possible to recreate this.
> No differences expected
> gs/devices/vector/gdevpdft.c

2013-11-07 09:15:38 +0000
Chris Liddell <chris.liddell@artifex.com>
6c5ecdf1a54e9d5a572c11860492abce06523f24

> Bug 694718: "reset" MT fonts for each glyph.
> Seems some vesions of UFST require the font object to be recreated for each
> glyph to work correctly. So when I fixed the optimisation in gxfapi.c to
> avoid calling "get_scaled_font()" when the font parameters had not changed, it
> exposed the problem with the UFST integration.
> To address this, the fapi/ufst code now zeros out the stored scale matrix for
> MT fonts, so the code in gxfapi.c always registers the scaling as having
> changed. Luckily, recreating the MT font object is not a very expensive
> operation.
> Also, grab the design units scale from the UFST state structure if the values
> haven't been set in the outline structure.
> CLUSTER_UNTESTED
> gs/base/fapiufst.c

2013-11-07 08:27:47 +0000
Ken Sharp <ken.sharp@artifex.com>
58cdefdeadbceda4833e489b6d94f5895a2d8ea4

> pdfwrite - check a return code
> Silences a compiler warning (and is the right thing to do of course)
> gs/devices/vector/gdevpdft.c

2013-11-06 09:18:19 +0000
Ken Sharp <ken.sharp@artifex.com>
616ff4cc44b00bcf7df97b64c8bdaebbe0620713

> pdfwrite - add transparency Group to substream resources
> Bug #691352 "cairo pdf mis-distilled."
> This fixes the last remaining problem with this old bug. When we were
> creating Form XObjects (because of transparency groups) we were assuming
> that the from was a child of the page.
> However, groups nested within groups (uncommon, except with Cairo's awful
> output) can cause a Form XObject to have children which are also Form
> XObjects. In this case we need to have the Form (or other substream) add
> the child form to its own Resources rather than inheriting them from the
> Page.
> This also addresses (most of) Bug #693332 though this still leaves a
> dangling ExtGState which needs separate investigation.
> No Differences expected
> gs/devices/vector/gdevpdft.c

2013-11-04 18:32:21 +0000
Robin Watts <robin.watts@artifex.com>
29a06fed84063976abe9864659384e7e371d799e

> Add alignment and padding code.
> Every time we create a new device in the code, we need to copy
> the pad and align values from the 'base' device to the new device.
> Build with TEST_PAD_AND_ALIGN defined to force on for pxmraw and psdcmyk.
> gs/base/gdevdevn.c
> gs/base/gdevmem.c
> gs/base/gdevmpla.c
> gs/base/gdevppla.c
> gs/base/gdevprn.c
> gs/base/gxbitmap.h
> gs/base/gxclthrd.c
> gs/devices/gdevpbm.c
> gs/devices/gdevpsd.c

2013-11-01 17:30:00 +0000
Robin Watts <robin.watts@artifex.com>
b3aec5521e0e5d84164285353af20a5163139c3f

> Remove is_native_planar.
> gs/base/gdevdevn.c
> gs/base/gdevdflt.c
> gs/base/gdevdrop.c
> gs/base/gdevmem.c
> gs/base/gdevmpla.c
> gs/base/gdevnfwd.c
> gs/base/gdevp14.c
> gs/base/gdevppla.c
> gs/base/gsdevice.c
> gs/base/gsovrc.c
> gs/base/gxccman.c
> gs/base/gxclimag.c
> gs/base/gxclip.c
> gs/base/gxclist.c
> gs/base/gxclrect.c
> gs/base/gxdevsop.h
> gs/base/gxht_thresh.c
> gs/base/gxicolor.c
> gs/base/gximage3.c
> gs/base/gximono.c
> gs/base/gxp1fill.c
> gs/base/gxpcmap.c
> gs/devices/vector/gdevpdfd.c

2013-11-01 16:47:06 +0000
Robin Watts <robin.watts@artifex.com>
f6946de99dd19c7a883d7edb28b4f52290e3e934

> Steps towards supporting aligned and padded buffer devices.
> Introduce log2_align_mod, pad and num_planes to the gx_device
> structure. Values of 0 will cause no changes to default behaviours.
> gs/base/gdevppla.c
> gs/base/gdevprn.c
> gs/base/gsdevice.c
> gs/base/gxclread.c
> gs/base/gxdevcli.h
> gs/base/gxdevice.h
> gs/base/gxdevmem.h
> gs/devices/gdevbit.c
> gs/devices/gdevplib.c

2013-11-04 17:23:28 +0000
Ken Sharp <ken.sharp@artifex.com>
a8f9934aa6c54830230f749280765ea4e65471d2

> pdfwrite - fix some XML emission
> Bug #694736 "PDF/A XMP dc:description - wrong element structure"
> The dc:creator is specified as a text sequence, but we were also emitting
> the dc:description that way, which is clearly wrong.
> gs/devices/vector/gdevpdfe.c

2013-11-04 15:09:03 +0000
Ken Sharp <ken.sharp@artifex.com>
f09f7f7cd37f3a52f733019e1d383034dd1c01cf

> pdfwrite - revert a4de55 and check for parentheses properly instead
> Bug #694735 "PDF/A XMP metadata and DOCINFO synchronization"
> The commit a4de55 was incorrect, the PDF/A spec clearly states that the
> XML creator is based on the Author. However, when an empty string is
> present for the Document Info entry, we should not write the string parentheses
> into the XML, this is clearly incorrect.
> Still no differences expected.
> gs/devices/vector/gdevpdfe.c

2013-11-04 13:41:00 +0000
Ken Sharp <ken.sharp@artifex.com>
a4de55d2fd0fa38e5110e7b5d5cca746528b28f6

> pdfwrite - use /Creator instead of /Author for the XML creator entry
> Bug #694735 "PDF/A XMP metadata and DOCINFO synchronization"
> We were using the Document Info /Author field for the XML 'creator' which
> apparently causes at least one PDF/A validator to take offence. Its not
> entirely clear to me from the documentation which one is inteded to be
> here, so we'll just use /Creator instead.
> No differences expected.
> gs/devices/vector/gdevpdfe.c

2013-11-04 09:26:47 +0000
Ken Sharp <ken.sharp@artifex.com>
ee0bf17f4912f131f7ad98aab744e571a18ece39

> pdfwrite/ps2write colour management, enable the new code
> Change the default setting of teh colour management switch so that we
> default to using the new code.
> If we are creating PDF/A-1, force the old colour management, we can't yet
> guarantee that we are getting a version 2 profile.
> Add some minimal documentation in ps2pdf.htm, hopefully we will do some
> more work in this area before release, and the documentation can be revamped.
> This change results in a lot of differences, especially with ps2write. In
> the main these are slight shifts in color values caused by using a different
> (better) conversion system. However, the new code does a much better job
> of handling some kinds of colour spaces, in particular Separation spaces
> with ps2write which are now preserved. This leads to a number of progressions
> in the test suite.
> I've looked at all the differences and I believe they are all either very
> minor colour shifts, or progressions.
> This is with 'LeaveColorUnchanged', actually converting to different spaces
> does result in differences but this can't be cluster tested. I believe these
> are all progressions however.
> gs/devices/vector/gdevpdfb.h
> gs/devices/vector/gdevpdfp.c
> gs/doc/Ps2pdf.htm

2013-11-02 12:21:21 +0000
Ken Sharp <ken.sharp@artifex.com>
41e1bdc7ef06bd00874890b36a53d84166ef30d0

> pdfwrite - colour code, do not apply range limiting for images
> When handling an image in a Lab space, do not reset the range of the space.
> We don't need to when preserving an image, and if we use the same space
> immediately afterward for linework, the range clamping causes the components
> to come out black.
> No differences, code is not used yet.
> gs/devices/vector/gdevpdfi.c

2013-11-02 12:19:03 +0000
Ken Sharp <ken.sharp@artifex.com>
eada430a0c612f5f50a9fea6416daa048464a5c3

> pdfwrite - coiour code, silence some compiler warnings
> gs/devices/vector/gdevpdfg.c
> gs/devices/vector/gdevpsdu.c

2013-11-01 11:01:02 -0700
Ray Johnston <ray.johnston@artifex.com>
82bfa31f2f423223b002aab74323927e8ee42ea0

> Add in some missing checks for failed allocations in gsicc code.
> There are a couple of functions that are 'void' that just return,
> which seems like should be fixed. Also fix _cmsCalloc in gsicc_lcms.c
> to actually clear the memory.
> gs/base/gsicc_cache.c
> gs/base/gsicc_lcms.c
> gs/base/gsicc_manage.c
> gs/base/gsicc_nocm.c
> gs/base/gsicc_profilecache.c
> gs/base/gsicc_replacecm.c

2013-11-01 08:32:45 +0000
Ken Sharp <ken.sharp@artifex.com>
b937b04503837d2ac6f3877478b5500f4bc8ea8a

> pdfwrite/ps2write - colour code work
> 1) Rescale inputs to 0->1 before concretizing if the space is specifically
> Lab. Required as the inputs to the ICC profile must be 0->1. gx_remap_color
> and its children do this for us, but gx_concretize_color does not.
> 2) Do not corrupt the device color from the interpreter if we are converting
> to a different colour space, use a temporary structure instead.
> 3) Make sure to use frac2float after concretizing to convert the values.
> 4) Don't forget to update the saved colour (in the device) after we've
> converted colours.
> 5) Update pdsdf_set_color so that if we are using the new colour code we
> get the expected number of output components from the ICC profile attached
> to the device, rather than the device 'color_info'. Update all calls to
> psdf_set_color so that they pass in the required boolean.
> This code is still switched off by default, so no cluster differences will
> show up.
> gs/devices/vector/gdevpdfc.c
> gs/devices/vector/gdevpdfg.c
> gs/devices/vector/gdevpdfv.c
> gs/devices/vector/gdevpsdf.h
> gs/devices/vector/gdevpsdu.c

2013-10-31 07:11:47 -0700
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
5929829c83498b2694bd32cf3579e151c1c99f0d

> Added support for VS2013 to msvc.mak.
> gs/psi/msvc.mak

2013-10-30 17:56:00 +0000
Robin Watts <robin.watts@artifex.com>
b87f410b4084c84242c254c70c379b96c8fca2d7

> Ensure that gdev_prn_dev_spec_op forwards to the real device.
> When the clist hijacks all the device entries, it attempts to forward
> the dev_spec_op calls to the generic printer device. This doesn't
> help when we have a device specific one. Only the printer device
> knows what the original procs were, so the best we can do is to have
> gdev_prn_dev_spec_op forwarding.
> This was important as the adjust_bandheight gxdso call was not making
> it through to the underlying device.
> gs/base/gdevprn.c
> gs/base/gdevprn.h
> gs/base/gxclist.h
> gs/base/gxclrect.c
> gs/base/gxpcmap.c

2013-10-24 21:07:31 +0100
Robin Watts <robin.watts@artifex.com>
bdf630af4252ba87bffa6108840bac53f4754cea

> Remove unnecessary code.
> The test is unneccessary due to us being within a if.
> gs/base/gdevprn.c

2013-10-31 10:10:21 +0000
Chris Liddell <chris.liddell@artifex.com>
9c77012daa9b1903d7be5fc4f239a46df863d0db

> Add quotes to conditional for safety.
> CLUSTER_UNTESTED
> gs/base/msvclib.mak

2013-10-30 14:19:06 -0700
Michael Vrhel <michael.vrhel@artifex.com>
75a8be6597d6ce56182c5391d6be02f997a1aa21

> Addition of code to test if current ICC color space is the same as new ICC color space
> gs/psi/zcolor.c

2013-10-30 18:30:42 +0000
Chris Liddell <chris.liddell@artifex.com>
5c511841cbe373743165e2248adc583382ca3b2a

> Avoid warning for missing (not required) encoding for PDFs
> Check earlier for the existence of an encoding entry in a PDF font object,
> for font types in which encoding is optional. Avoids a benign but annoying
> warning from the PDF interpreter.
> No cluster differences.
> gs/Resource/Init/pdf_font.ps

2013-10-28 18:45:31 +0000
Chris Liddell <chris.liddell@artifex.com>
c186880d7e3651c8a76e55bc981fc22e4a57ea94

> Bug 694733 (part 2): ensure jmp_buf alignment is correct
> Move the jmp_buf used by the HP/GL parser to be a local variable, accessed
> via a pointer in the state (rather than directly allocated within the state).
> This ensures that any alignment requirements are met - specifically, 64 bit
> MS Visual Studio 2010 requires that jmp_bufs be aligned to 16 byte boundaries.
> No cluster differences.
> pcl/pgmand.h
> pcl/pgparse.c

2013-10-28 11:08:19 +0000
Chris Liddell <chris.liddell@artifex.com>
16fbdade9a29352ad936455eab65e77a9db6f768

> Bug 694733 (part 1): fix incorrect offsets in chunk allocator
> When I changed the chunk allocator to honor the alignment value for the
> memory manager, I missed a couple of places where the calculation of the offset
> to get from the allocated memory address to the address of the chunk node.
> No cluster differences.
> gs/base/gsmchunk.c

2013-10-26 13:42:34 -0600
Henry Stiles <henry.stiles@artifex.com>
8f491ec1493bcb11583d450a264a1b80d5557217

> Fix 694737 - Typeface mask incorrect.
> The typeface value is in the first 12 bits and the vendor info in the
> next 4 bits of the short value that stores typeface information. We
> were extracting the first 11 bits for the typeface. This problem is
> not associated with a known bug, and in fact, it is quite unlikely to
> result in a problem, but it is incorrect. Thanks to Norbert Janssen
> for pointing out the problem.
> pcl/pcfsel.c

2013-10-24 20:22:18 -0700
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
1b691ea92ead0590c619ec64a00d93f24452bb2c

> Fix Luratech build (by removing spurious JPX_AUTOCONF_CFLAGS= from configure.ac).
> gs/configure.ac

2013-10-24 20:03:15 -0600
Henry Stiles <henry.stiles@artifex.com>
5c08e60fc75c940ce6c6df1e75802ce2d72fbd2f

> Fix bug 694725 - bad characters in numeric input not processed
> correctly.
> Thanks to Norbert Janssen for finding and fixing this problem.
> pcl/pcparse.c
> pcl/pcparse.h

2013-10-24 08:59:12 +0100
Chris Liddell <chris.liddell@artifex.com>
184dcfd570a96328798e36d8e08495eb426d67f9

> Allow user to override configure's color index setting
> This command line parameter is not listed in the "configure --help" output
> as it is really intended for our use, and not generally by end users.
> To build with 32 bit colour indices, issue:
> ./configure --with-large_color_index=0
> to build with 64 bit color indices:
> ./configure --with-large_color_index=1
> This works for both Ghostscript and GhostPDL builds.
> The only "wrinkle" is that Ghostscript default to:
> "--with-large_color_index=1" (so 64 bit indices)
> whilst GhostPDL defaults to:
> "--with-large_color_index=0" (so 32 bit indices)
> This retains the previous default settings.
> No cluster differences.
> config.mak.in
> configure.ac
> gs/configure.ac
> main/pcl6_gcc.mak

2013-10-22 11:09:23 -0700
Michael Vrhel <michael.vrhel@artifex.com>
38ed5ffaf81405a3e8ff094afbc2ada05eaf630c

> Fix for bug in case where alternate color space for DeviceN and separation is CIE
> If the CIE color space has a range different than 0 to 1 we need to rescale before using
> the equivalent ICC profile. Fixes bug 694731. Note diffs for 09-34.PS match what is
> created by Distiller and AR vers. X.
> gs/base/gscdevn.c
> gs/base/gsciemap.c
> gs/base/gscsepr.c
> gs/base/gsicc.c
> gs/base/gxcie.h
> gs/base/lib.mak

2013-10-23 16:09:21 +0100
Robin Watts <robin.watts@artifex.com>
c7cca8f105194908bb1b28b3e6606be51533b6d9

> Fix possible (but very unlikely) SEGV and warning.
> It is extremely unlikely that options will be NULL, but check to be
> sure.
> gs/base/gxclthrd.c

2013-10-23 12:53:49 +0100
Robin Watts <robin.watts@artifex.com>
d76e3a434e699f8974f50d98c0b7e82042fdc7ec

> Clean a few #defines out of psdcmyk device.
> Not needed since the transition away from compressed color encoding
> to planar operation.
> gs/devices/gdevpsd.c

2013-10-23 14:34:11 +0100
Chris Liddell <chris.liddell@artifex.com>
ad3e3ed7913986cec6acbc1afe0eff0c57627ddc

> Bug 694734: handle Type 0 font in annotation
> The code to generate an appearance from an annotation with an AP, the code
> required the FontBBox, but failed to take account that the FontBBox is not
> required in a Type 0 font.
> We now handle it by grabbing the FontBBox from the descendant font - for
> which a FontBBox is mandatory.
> No cluster differences.
> gs/Resource/Init/pdf_ops.ps

2013-10-22 08:23:19 +0100
Chris Liddell <chris.liddell@artifex.com>
ee941e19870761a752277f08c82282f53f4d4fee

> Bug 694722: force ptr alignment to 8 bytes for HP-UX
> Like Solaris/SPARC, HP-UX appears to require pointer alignment to be 8 bytes
> even when user space pointers are 32 bits.
> No cluster differences.
> gs/base/genarch.c

2013-10-21 13:34:36 +0100
Robin Watts <robin.watts@artifex.com>
25db24cbeb52621cd1e2ae3e79d9b06c97143bc3

> Add documentation for process_page.
> gs/doc/Drivers.htm

2013-10-22 13:08:14 +0100
Robin Watts <robin.watts@artifex.com>
d2612770174079f423d704af4f68f6c85f63905a

> Update fpng device to use downscaler.
> gs/devices/gdevfpng.c

2013-10-18 18:36:52 +0100
Robin Watts <robin.watts@artifex.com>
ae8611c998beaad5e6f0cd2b85abb1b1995d94c4

> Add fpng device.
> Example 'fastpng' device for process_page.
> gs/devices/devs.mak
> gs/devices/gdevfpng.c
> gs/ghostscript.vcproj
> gs/psi/msvc.mak

2013-10-18 22:14:55 +0100
Robin Watts <robin.watts@artifex.com>
afe18de12b530d8d95a132755516847e8fc3f88e

> Add gxdso_adjust_bandheight
> Add mechanism for adjusting the bandheight. Intended to allow devices to
> exert fine control over bandheight while ghostscript still handles the
> gross sizing. An example would be the downscaler ensuring that bands are
> multiples of the given downscale.
> gs/base/gxclist.c
> gs/base/gxdevsop.h

2013-10-22 13:06:40 +0100
Robin Watts <robin.watts@artifex.com>
edd06c70150166780f1360a42499569f3a52903e

> Update downscaler to allow for process_page operation.
> (No error diffusion in this mode, as bands need to be independent).
> gs/base/gxdownscale.c
> gs/base/gxdownscale.h

2013-10-21 12:03:42 +0100
Robin Watts <robin.watts@artifex.com>
ca5a608fe9062492f53c80eccb8b78dbdb997499

> Add default process_page implementation.
> This serves to handle the page mode case.
> gs/base/gdevdflt.c
> gs/base/gxdevice.h

2013-10-18 18:36:26 +0100
Robin Watts <robin.watts@artifex.com>
a25313d4518a942d74528ee7b6a52c96aa0128b6

> Add process_page entry point.
> Add clist implementation (both threaded and non-threaded) for process_page.
> gs/base/gxcldev.h
> gs/base/gxclist.c
> gs/base/gxclthrd.c
> gs/base/gxclthrd.h
> gs/base/gxdevcli.h

2013-10-21 11:54:33 +0100
Ken Sharp <ken.sharp@artifex.com>
d7bff9b2f7230b527765661ea721d4b60e0e4154

> pdfwrite - free Named Images stack before clearing local/global named objects
> Bug #694136 "Seg faults found by fuzzing in cos_value_free"
> If we stored named images in the initial name space then when we closed
> the PDF file we would free and delete the local named objects before we
> freed the named images stack. If the named images stack included entries
> stored in the local named objects stack then we would attempt to free an
> object which was already freed.
> So we clear the named images stack first, for added safety we ensure we
> clear the NI stack before global named objects are freed too.
> No differences expected.
> gs/devices/vector/gdevpdf.c

2013-10-19 10:50:17 +0100
Ken Sharp <ken.sharp@artifex.com>
8dbe789dec0a8be00942849f768648da60ee3336

> pdfwrite - do not compose font name with CMAp when creating a CIDFOnt
> Bug #694721 "Issued with font names in pdfwrite device"
> When creating a CIDFont for output to a PDF file, we created the name by
> composing the CIDFont name with the CMap originally used with the font.
> However, this doesn't make sense, the CIDFont we emit is not composed with
> that CMap, its usually composed with an Identity CMap. The CIDFont is
> still arranged according to the original CMap, but this is the Ordering
> of the font, not the CMap being used with it, and we record that Ordering
> (should it be useful for anything) in the CIDSystemInfo.
> We now do not add the CMap name to the CIDfont name, which allows Acrobat
> to do a 'better' job of copy and paste (apparently it passes the font name
> along).
> No differences expected
> gs/devices/vector/gdevpdtf.c

2013-10-18 18:33:21 +0100
Robin Watts <robin.watts@artifex.com>
7936b2643f2577fb70fdf2b8d9e3af5c8058668d

> Fix memory leak on error in gxclimag.c
> If we fail to allocate pie->buffer, there is no need to free it during
> the clean up. On the other hand, it's probably a good idea to free 'pie'.
> Also, for good style, if nothing else, avoid pinfo being returned with
> a dangling pointer.
> gs/base/gxclimag.c

2013-10-17 21:06:02 -0700
Ray Johnston <ray.johnston@artifex.com>
357ec4e2553a80c2bb6df29bb33ad095ac343242

> Fix Bug694714. Clamp the ymin/ymax values to valid device coordinates.
> In write_image_end_all, we could advance to a band past the end of the
> page that didn't have a pcls in the states array, causing a segfault
> when garbage values were used.
> gs/base/gxclimag.c

2013-10-18 11:35:06 +0100
Ken Sharp <ken.sharp@artifex.com>
b21c6dd0fc782709712307f58fe0685634c6db30

> pdfwrite - Improve robustness of type 1 font interpreter
> Bug #694214 "Seg faults found by fuzzing in type1_next"
> The font is corrupted and one of the glyph instrctions performs a 'return'
> without previously executing a subroutine. This caused the font interpreter
> to crash.
> We now check when executing a return to see if we are not in the main glyph
> program, if we are, we return an invalidfont error.
> No differences expected
> gs/devices/vector/gdevpsfx.c

2013-10-17 12:56:38 +0100
Ken Sharp <ken.sharp@artifex.com>
fc7ead6d34638a521a48debeb9437eac4e82ef98

> pdfwrite - some casts to prevent compiler warnings
> gs/devices/vector/gdevpdfc.c

2013-10-17 12:08:54 +0100
Ken Sharp <ken.sharp@artifex.com>
3cd2f7878bdae2d954ab27906336a9b87a267cd9

> pdfwrite colour code - after concretizing a DeviceN space, don't attempt to convert it again
> gs/devices/vector/gdevpdfg.c

2013-10-17 12:07:11 +0100
Ken Sharp <ken.sharp@artifex.com>
bbb32ec3f43405bd794f5d60f58f2d1bb7f5546b

> pdfwrite colour - ensure icc_equivalent is set before trying to use it.
> gs/devices/vector/gdevpdfc.c

2013-10-17 08:19:33 +0100
Ken Sharp <ken.sharp@artifex.com>
88df0b8fe9cce08b30ae7b12d6a1e8aa104981e2

> pdfwrite - check before dereferencing a pointer
> Bug #694716 - "seg fault with pdfwrite"
> No differences expected
> gs/devices/vector/gdevpdfm.c

2013-10-16 09:26:35 -0600
Henry Stiles <henry.stiles@artifex.com>
82fc3bd9f058974403d9f9ff9945391a6b8b20f6

> The color index size was not transmitted properly from the MSVC
> PCL/PXL/XPS makefiles to the Ghostscript makefile system.
> common/msvc_top.mak
> gs/base/msvclib.mak
> gs/psi/msvc.mak
> main/pcl6_msvc.mak

2013-10-16 00:59:19 +0100
Robin Watts <robin.watts@artifex.com>
8e9b3ce974cbd12452ae11ff1ff4cd48e4a261a9

> Add downscaler support to pngalpha.
> gs/devices/gdevpng.c
> gs/doc/Devices.htm

2013-10-15 10:31:33 -0700
Michael Vrhel <michael.vrhel@artifex.com>
a438d95a859b430e58ef448a0995aa13cefac172

> Minor fixes for use of equivalent ICC profiles from PS objects with pdfwrite
> gs/base/gsicc_cache.c
> gs/devices/vector/gdevpdfg.c

2013-10-14 16:56:25 -0700
Michael Vrhel <michael.vrhel@artifex.com>
9a441022bfe6f59dacdca40ce60c37ee02adfa07

> Fix for error when nos had shape and alpha_g during compositing.
> gs/base/gxblend1.c

2013-10-14 10:30:03 -0700
Michael Vrhel <michael.vrhel@artifex.com>
1c1f1619da98236ea06c4fdb1ea403d5ab990e08

> Make sure to set the soft mask opacity to one so that we do not apply the
> global path opacity multiple times when we have an opacity and a soft mask
> from an image. Fix for Bug 694705
> xps/xpsgradient.c
> xps/xpsimage.c
> xps/xpsopacity.c

2013-10-14 17:14:59 +0100
Ken Sharp <ken.sharp@artifex.com>
a0b7b91e2ca181e06fe11a89c5240e78b6e31aaf

> pdfwrite - check return values from 'convert color'
> Bug #694221 "Valgrind issues found by fuzzing in choose_DCT_params (gdevpsdi.c:156)"
> In the past convert_color could not fail, with ICC handling, it can, so
> we need to check the return code and handle errors gracefully.
> This would not in fact have caused problems, but we fix it anyway.
> gs/devices/vector/gdevpsdi.c

2013-10-11 16:18:32 -0700
Michael Vrhel <michael.vrhel@artifex.com>
d28da52a57923eb76503277d8be2eb0c72165599

> Fix free mistake made in knockout commit http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=2d2cc321df4223fd7cf64946ac2fa963fa1cea3d
> gs/base/gdevp14.c

2013-10-11 15:33:55 +0100
Chris Liddell <chris.liddell@artifex.com>
561b37fb083fa0dc32ea81b4aaea38607db05814

> Remove the -dDisableFAPI hack from the "languages" builds
> No cluster differences.
> pl/plmain.c

2013-10-11 15:24:43 +0100
Chris Liddell <chris.liddell@artifex.com>
31ca73d856f974c7e1422948b2fb5794af55bf58

> Have FAPI honor GridFitTT parameter.
> The FAPI code now passes the GridFitTT parameter onto the scaler/renderer
> interface code.
> The default setting is now "1" for using the bytecode hinting. "0" disables
> all TTF hinting, and "2" (with Freetype) enables Freetype's "autohinting"
> algorithm. With other scalers the paramter currently has no effect, and
> the "2" setting will *always* be scaler dependent.
> Causes differences in pretty much every cluster PCL file containing TTF
> glyphs as (and I still think this is a bad idea) PCL disables hinting at 300
> dpi and above. No differences in PS/PDF/XPS/PXL jobs.
> gs/base/fapi_ft.c
> gs/base/fapibstm.c
> gs/base/fapiufst.c
> gs/base/gsfont.c
> gs/base/gxfapi.c
> gs/base/gxfapi.h
> gs/doc/Language.htm
> pl/plfapi.c

2013-10-11 09:45:56 +0100
Ken Sharp <ken.sharp@artifex.com>
9c13e3b9e735ba119f58c751a51fc55efef15a0c

> xps interpreter - correct high level pattern handling
> A silly error was causing fills to be applied twice. For opaque fills this
> is merely a performance penalty but for transparent fills the result is
> incorrect.
> Thanks to Phil McSharry for identifying the problem and supplying a solution.
> This shows progressions in a number of test files.
> xps/xpspath.c

2013-10-11 08:09:01 +0100
Ken Sharp <ken.sharp@artifex.com>
6e10e787517ae0212ada6b7735542cbb4c41040c

> Squash a scan-build compiler warning.
> Prevent any possibility of a null-pointer dereference.
> gs/base/gsdevice.c

2013-10-10 13:34:37 +0100
Ken Sharp <ken.sharp@artifex.com>
72afba4af187b01fded403d6a986d5de0be741d2

> txtwrite - fix UTF-8 output Bug #694690
> Thanks to r_one_guy@yahoo.fr for pointing this out and supplying a fix. The
> UTF-8 output was incorrect for Unicode values between 0x80 and 0x7FF.
> Also, we weren't outputting a BOM for Unicode (UCS2) output.
> Not cluster tested
> gs/devices/vector/gdevtxtw.c

2013-10-10 12:15:54 +0100
Ken Sharp <ken.sharp@artifex.com>
f924bf4d2bb4243ebe771e7e42bf1df3e41f415a

> pdfwrite - don't emit extra blank page with '%d' output file spec
> Bug #694576 "Using %d with pdfwrite results in extra, blank page"
> Added a flag to the PDF device structure so that we can tell if pdf_close
> has been called as the result of outputting a page. If it has not, and
> the page is unmarked, and we are outputting in 'file per page' mode, then
> we don't emit the page.
> However, this leads to a 0 byte output file, so we also need to delete the
> current output file. There seemed to be no obvious way to do this, so I
> have added a gx_device_delete_output_file very similar to the existing
> gx_device_open_output_file and gx_device_close_output_file routines.
> No differences expected.
> gs/base/gsdevice.c
> gs/base/gxdevice.h
> gs/devices/vector/gdevpdf.c
> gs/devices/vector/gdevpdfb.h
> gs/devices/vector/gdevpdfx.h

2013-10-03 15:15:53 +0100
Chris Liddell <chris.liddell@artifex.com>
68fa228ade5d2f7496b96676aaa1f82be4584362

> Bug 694519: improve PCL performance with FAPI
> Correctly maintain "design_grid" parameter in the font/matrix pair
> structure, for FAPI handled TTFs.
> Change a "return" to a "return_error".
> Retrieving glyph metrics was sub-optimal as my original implementation used
> a gs_text_process() call, which uses the entire "show machinery".
> This implementation calls gs_fapi_do_char() directly. This has several benefits:
> we only need a "skeleton" text enumerator, and a "skeleton" graphics state,
> cutting down the local overhead setup. We also cutout a whole lot of setup
> done as part of gs_text_begin() and during gs_text_process() itself. Finally,
> we avoid a lot of "stuff" related to showing entire strings, when we're only
> ever handling a single glyph at a time.
> A final optimisation is in the FAPI/FT code: if we're just retrieving metrics,
> we no longer take the action of retrieving the glyph from FT - which is not
> a very cheap operation.
> This commit causes ~100 cluster tests to have pixel shift differences.
> gs/base/fapi_ft.c
> gs/base/gxccman.c
> gs/base/gxfapi.c
> gs/base/gxfapi.h
> gs/psi/zfapi.c
> pl/plfapi.c
> xps/xpsfapi.c

2013-10-09 12:25:56 -0700
Michael Vrhel <michael.vrhel@artifex.com>
83565d8264e96312df8c26055aaa0e23e57c4c8d

> Add missing reference to $(memory__h) in gsicc_lcms2.c lib.mak
> gs/base/lib.mak

2013-09-30 13:14:52 -0700
Michael Vrhel <michael.vrhel@artifex.com>
2d2cc321df4223fd7cf64946ac2fa963fa1cea3d

> Knockout non-isolated transparency group support.
> Fixes bug 692766
> Proper non-isolated knockout group support added.
> This commit adds non-isolated knockout group support to gs. Also, previously, non-isolated groups that
> had color space mismatches were being forced to be isolated. We now color convert the parent buffer
> to the new groups color space to ensure that the group is handled in the way it should.
> This work revealed an issue in the color handling of planar buffers which was also fixed.
> Also, an issue with clipping to the soft mask boundary during a transparency group pop was was
> discovered and fixed as well as an overprint simulation issue in transparency.
> Several progressions occurred with this fix.
> Fixes bug 692766.
> gs/base/gdevp14.c
> gs/base/gdevp14.h
> gs/base/gscsepr.c
> gs/base/gsicc_cache.c
> gs/base/gsicc_lcms2.c
> gs/base/gstrans.c
> gs/base/gxblend.c
> gs/base/gxblend.h
> gs/base/gxblend1.c
> gs/base/lib.mak

2013-10-08 11:25:11 +0100
Chris Liddell <chris.liddell@artifex.com>
1969b28c60d666b5eab0050169b5b9aae1a28db5

> Bug 694699: Scale FAPI's font BBox for units.
> When FAPI "refined" the FontBBox from the scaler's data, it failed to correctly
> take account of the units in which the scaler returned the values.
> There was some code which *may* have been an attempt to handle it, but was
> wrong in the general case. That's removed in favour of handling it properly.
> Several regression files show differences, mainly with pdfwrite/ps2write: many
> are pixel differences due to rounding, some are progressions. One was wrong
> prior to this commit, and is slightly differently wrong with it.
> gs/base/fapi_ft.c
> gs/base/fapibstm.c
> gs/base/fapiufst.c
> gs/base/gxfapi.c
> gs/base/gxfapi.h

2013-10-08 13:08:17 +0200
Tor Andersson <tor@ccxvii.net>
8b28b7dfd503146f7e2355a5dad9202b35405256

> xps: Look harder for a font name in the 'name' table.
> We used to look only for "Mac Roman, English" strings, now also try
> "MS Unicode, United States" and "MS Unicode UCS-4, United States" if
> the mac roman string can't be found.
> xps/xpsfont.c

2013-10-07 16:05:07 +0100
Ken Sharp <ken.sharp@artifex.com>
7276c1f94cfa55aed0554d45858652ee1cac2097

> correct a scan-build warning by checking a return value
> No differences expected
> gs/devices/vector/gdevpdfi.c

2013-10-07 15:05:22 +0100
Ken Sharp <ken.sharp@artifex.com>
1bdb7a9e1a3064b5e8abf29dcdfa9d279715ae34

> Have pdfwrite ignore WMode=1 when a font has no Metrics2 entry
> This arose while investigating a customer bug. Sadly its not actually
> anything to do with the customer problem, but it was incorrect. The spec
> says that if a font has WMode 1 but has no Metrics2 entry it should be
> treated as horizontal (WMode = 0)
> Quality Logic file 16-09.ps shows a progression with this change.
> gs/devices/vector/gdevpdte.c
> gs/devices/vector/gdevpdtt.c
> gs/devices/vector/gdevpdtt.h

2013-10-04 08:17:40 -0700
Robin Watts <robin@peeves.(none)>
cdde8014aa4fe051743fad132f132fd608463744

> Bug 694249: Fix JBig2Dec using broken image regions.
> When decoding a "generic immediate region" in jbig2dec, if
> we detect an error, we should not use the image as it may not
> have been entirely initialised.
> gs/jbig2dec/jbig2_generic.c

2013-10-02 09:51:31 -0700
Ray Johnston <ray.johnston@artifex.com>
41c13b4cc25b456d3862a73235ddbce09a85a104

> Fix Segfaults with --saved-pages.
> If the page was not large enough to use Banding mode, the clist_reset
> would crash after the print request finished and the page reloaded.
> The gx_saved_page_load needs to be after the saved_pages_list is put
> back in the device.
> Also, the "file_is_new" status was incorrect if pages were saved, but
> no printing was done. This was seen with the TIFF devices and psdcmyk.
> The psi/imainarg.c has a #define FORCE_SAVED_PAGES_TEST (disabled by
> default) to simplify testing on the cluster without modifying command
> line parameters.
> gs/base/gdevprn.c
> gs/base/gxclpage.c
> gs/psi/imainarg.c

2013-10-01 17:52:43 +0100
Robin Watts <robin.watts@artifex.com>
dcc172feb018bfe0613f90ce76ce25dd1eafe3ce

> Bug 689098: Only dash paths when the dashing would be visible.
> If the ctm doesn't expand the dash lengths to be > 1 pixel, then
> they can't be seen, so don't bother.
> gs/base/gsmatrix.c
> gs/base/gxstroke.c

2013-10-01 13:41:28 +0100
Robin Watts <robin.watts@artifex.com>
607370ce1a661d8657d5255056d810551c04d642

> Bug 692650 - remove dead code in gxifast.c
> A piece of code that was obviously left in a special case due to
> cut and pasting can be removed. This will probably not actually
> make any difference as a decent compiler (ha!) would optimise
> it out anyway, but it's neater to remove it.
> gs/base/gxifast.c

2013-10-01 12:44:13 +0100
Robin Watts <robin.watts@artifex.com>
9b43b8b20c6344ccac7fac48151161a51743246b

> Add openjpeg files to ghostscript.vcproj
> gs/ghostscript.vcproj

2013-09-28 08:29:45 +0100
Ken Sharp <ken.sharp@artifex.com>
29ed18f26f78d3e737b5e73452b1aa1a90088144

> Eliminate some scan-build warnings in the ramfs code
> The warning in gsioram.c is bogus, but hopefully this change will eliminate
> it anyway.
> 2 lines deleted in ramfs.c were benign but pointless. The final deletion
> could have caused a seg fault when memory was exhausted.
> No differences expected
> gs/base/gsioram.c
> gs/base/ramfs.c

2013-09-27 16:03:04 +0100
Ken Sharp <ken.sharp@artifex.com>
be574c5550733da6b2ffa43fbc2099ae01608797

> PDF interpreter - update to BPC change for JPEG2000
> Bug #694621
> If we find a box, which we shoudl not as this is only supposed to be used
> when each colour channel has differing depth, we parse teh BPC from that,
> and ignore the BPC in the ihdr box.
> If the components are not all equal, we use the first one and raise a
> warning.
> No differences expected
> gs/Resource/Init/pdf_draw.ps

2013-09-27 11:24:32 +0100
Ken Sharp <ken.sharp@artifex.com>
6fe7ace41f8afaba72f0f1da7747c062382346fc

> PDF interpreter - treat invalid BPC of 128 in JPEG2000 files as 8
> The test file has JPEG2000 images (produced by JasPer) which have a BPC
> of 128. The valid range for JPEG2000 is 1->38 and for PDF is 1, 2, 4, 8,
> 12 or 16. Acrobat (of course) opens the file without complaint.
> It appears that the image actually has 8 BPC so we specifically treat
> this invalid value as 8.
> No differences expected.
> gs/Resource/Init/pdf_draw.ps

2013-09-26 14:07:19 -0600
Henry Stiles <henry.stiles@artifex.com>
49c0d08e7e04c8c4e1472142461f3ed369089639

> Fix 694614 - Properly handle a resolution argument of zero.
> pcl/rtgmode.c

2013-09-26 13:55:53 -0600
Henry Stiles <henry.stiles@artifex.com>
0f815674bfda9f940a20bb703d124f27b92de181

> Fix 694615 - CCITT filter overflow.
> The type of image columns in the graphics library CCITT filter is a
> signed integer and PCL was assuming an unsigned and therefore did not
> check for possible overflow.
> pcl/rtraster.c

2013-09-26 10:31:51 -0600
Henry Stiles <henry.stiles@artifex.com>
3f02bbe5fad16e1f44131cb444e488e96157de5a

> Fix 694616 - Fuzzing uncovered a modulo divisor of 0
> pcl/rtraster.c

2013-09-17 16:49:51 +0100
Ken Sharp <ken.sharp@artifex.com>
c561232cf26e060b89fc4f3bd4bf5c679731d4db

> pdfwrite - add support for form preservation from PostScript
> Bug #687561 et al
> We add the new operators .beginform and .endform which call device spec_op
> methods in order to allow devices to capture form streams. Devices can
> also return a matrix to replace the CTM for the course of the form.
> Modified pdfwrite to capture and store forms, and set the CTM to the
> pdfwrite general matrix (resolution/72).
> Added new PDFexecform for use by the PDF interpreter, trying to capture
> forms from PDF files is fraught with difficulty because we already capture
> transparent forms as forms.
> Because some kinds of forms cannot be successfully preserved (only happens
> with badly behaved PostScript) we need a way to prevent forms from being
> preserved. This option does that.
> Examples of badly behaved PostScript can be found in a few Quality Logic
> CET tests (use of setgstate in a form to set the CTM to a state prior to
> the form execution, and use of setflat with a parameter derived from the
> CTM. So we add UNROLLFORMS to the gs_cet file.
> gs/Resource/Init/gs_cet.ps
> gs/Resource/Init/gs_lev2.ps
> gs/Resource/Init/pdf_draw.ps
> gs/base/gdevdflt.c
> gs/base/gsform1.h
> gs/base/gxdevsop.h
> gs/devices/vector/gdevpdfb.h
> gs/devices/vector/gdevpdfi.c
> gs/devices/vector/gdevpdfx.h
> gs/doc/Ps2pdf.htm
> gs/psi/int.mak
> gs/psi/zform.c

2013-09-26 10:34:34 +0100
Chris Liddell <chris.liddell@artifex.com>
a62129ba436ff3a35c92c704a905d21ceae09a88

> Bug 694575: workaround for filenameforall in regression tests
> (This is slightly hacky!)
> For the regression testing, especially the weekly tests, several of the QL
> CET files give variable results depending on the exact content of the current
> working directory - because they use filenameforall and vary their output based
> whether it returns an error (mainly due to the path ending up too long for the
> scratch string).
> This commit "patches" the filenameforall operator to catch those cases, and
> (hopefully) always return with no files, and no errors, thus giving consistent
> results between runs.
> Cluster differences in the CET files, as expected.
> gs/Resource/Init/gs_cet.ps

2013-09-25 18:12:58 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
f9d0691129945b6d0657effcec6e6c440f57a364

> Bug 694137 : Prevent accessing outside of array.
> gs/openjpeg/libopenjpeg/jp2.c

2013-09-23 14:54:55 +0100
Chris Liddell <chris.liddell@artifex.com>
f945f8b050fb0a64f5de746f253244afa107bff8

> Bug 694586: Have chunk allocator honor alignment
> Have the chunk memory manager honor the same alignment as the rest
> of the memory manager(s).
> Fixes potential bus errors on SPARC.
> No cluster differences.
> gs/base/gsmchunk.c
> gs/base/lib.mak

2013-09-23 10:55:34 -0700
Michael Vrhel <michael.vrhel@artifex.com>
b6d163b01a4ecca30503fbd770770b1bd7de73e2

> Fix potential access violation and add error checking in pdf14 put image.
> Fixes segv in fuzzing Bug 694190
> gs/base/gdevp14.c
> gs/base/gxblend1.c

2013-09-23 09:56:14 -0700
Michael Vrhel <michael.vrhel@artifex.com>
b8bb26de721811ca80712d8540e9279b4dca5bc9

> Add error code checking in image color initialization
> Fix for bug 694175
> gs/base/gxipixel.c

2013-09-23 08:08:50 -0700
Robin Watts <robin@peeves.(none)>
f39d9824015ff6f909a59f697947f262d2c9c21c

> Bug 694289: Avoid SEGVs sue to Xmprintfs with mem = NULL
> If no memory pointer is supplied to a printf, then (in threadsafe
> builds) return doing nothing or (in non-threadsafe builds) use the
> default one.
> Also tweak the lib ctx closedown so that we safely closedown
> without trying to print anything via undefined print pointers.
> gs/base/gslibctx.c

2013-09-23 15:19:04 +0100
Robin Watts <robin.watts@artifex.com>
23ef9ea1fd7193c19c37c9cd00c6aad52a992fd1

> Bug 694162: Harden gx_forward_dev_spec_op against SEGVs.
> If tdev == 0, don't pass on the call. I cannot reproduce the bug,
> but this seems like a sensible precaution.
> gs/base/gdevnfwd.c

2013-09-23 14:29:50 +0100
Robin Watts <robin.watts@artifex.com>
8c5cbff3351774ac55704c9c633112922313c74b

> Bug 694159: Check return code on color remap.
> If return code is ignored, returned device color may be used when
> it is not initialised.
> gs/base/gsshade.c

2013-09-22 20:56:11 -0700
Michael Vrhel <michael.vrhel@artifex.com>
81b54e2a9237dec0186ad331af845800011ae6d2

> Improved error recovery during transparency group popping.
> If the creation of the ICC link fails then we attempt a non-ICC mapping. Fix for fuzz segv bug 694191.
> gs/base/gdevp14.c

2013-09-22 19:13:04 -0700
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
9f29534318f7a70eb42408a2bdca51dad7181c16

> Added ink_cov device (Bug 694501).
> Thanks for Billon Marc <billon.m@free.fr> for the patch.
> gs/base/macos-mcp.mak
> gs/base/macosx.mak
> gs/base/openvms.mak
> gs/base/unix-gcc.mak
> gs/base/unixansi.mak
> gs/configure.ac
> gs/devices/devs.mak
> gs/devices/gdevicov.c
> gs/psi/msvc.mak

2013-09-21 22:36:34 -0700
Michael Vrhel <michael.vrhel@artifex.com>
af81a6bf1a5de5d8cc23aaec7ae663c8985767c7

> Fix improper error checking in icc color space installation
> Fixes fuzzing segv Bug 694192
> gs/psi/zicc.c

2013-09-20 23:08:57 -0700
Michael Vrhel <michael.vrhel@artifex.com>
bbb9f59c59f7e229001e9e8413ff6ebf812910de

> Add in pdf14 abort compositor action
> The fuzzing files have identified that the interpreter was popping the
> pdf14 device during a stop. This caused the pdf14 device to think it
> was time to do its put_image command since it was done, causing a lot
> of potential segv issues. This commit adds an abort compositor action
> which will clean up the pdf14 device and set it back up as a pass through
> device allowing for a more graceful exit.
> gs/Resource/Init/pdf_main.ps
> gs/base/gdevp14.c
> gs/base/gstrans.c
> gs/base/gstrans.h
> gs/base/gxdevcli.h
> gs/devices/vector/gdevpdft.c
> gs/psi/ztrans.c

2013-09-20 12:19:36 -0600
Henry Stiles <henry.stiles@artifex.com>
46b8210665fe111b2fa544eed4a661de831d245e

> Include another GL/2 command (SP) which can be used to initialize the
> GL/2 interpreter, see related fix with bug #694595 for problem
> details.
> pcl/pcparse.c

2013-09-19 10:04:17 +0100
Ken Sharp <ken.sharp@artifex.com>
a5fa1ac21714a2dfdbcd3b9d70bc5cd913764ef3

> pdfwrite - extend TrueType MaxPoint checking to include CID fonts
> Further to commit 8b6be8be2cdcefae39339682d45d3c009ab909ac which added
> checks for MaxPoints and NumContours before merging TrueType fonts, this
> commit adds the same checks to CIDFonts with TrueType base fonts.
> Also, relax the checks somewhat. As long as the new font doesn't have
> *more* points, or contours, its safe to merge with the existing font.
> No differences expected
> gs/devices/gxfcopy.c

2013-09-18 13:56:35 -0700
Michael Vrhel <michael.vrhel@artifex.com>
142b12b12b56aba0d4ec7372c0260c39d2d58d28

> Additional error checking fixes from fuzzing files
> Fixes Bug 694154
> gs/base/gsicc.c
> gs/base/gsstate.c

2013-09-18 12:26:43 -0700
Michael Vrhel <michael.vrhel@artifex.com>
2236e20a9604602a12a9fbefc05e162d12954b03

> Fix error checking for fuzzing case where pdf14 pattern accumulator target was closed
> Fixes 3842.pdf.SIGSEGV.201.3160
> gs/base/gdevp14.c

2013-09-18 10:31:50 -0700
Michael Vrhel <michael.vrhel@artifex.com>
c6fbf53542a13b9a8582aef2c50bba7a145a8e49

> Error code checking fix.
> Fixes Fuzzing Bug http://bugs.ghostscript.com/show_bug.cgi?id=694161
> gs/base/gximag3x.c

2013-09-17 11:37:05 -0700
Michael Vrhel <michael.vrhel@artifex.com>
f4a1368a6585d20a218acd236d97706401a1b8c1

> Fix for pattern, transparency, clipper interaction issues
> Three issues this fixes. One is that if a clipper device is installed during the filling
> with a transparency tile, we need to make sure we get the pdf14 device to pop the group
> and not use the clipper device.
> The second issue was that fit_fill was not getting used properly in the tile filling code.
> The third issue was that the wrong dimensions were supplied to gx_trans_pattern_fill_rect when
> the pattern was clist based.
> This should fix Bug 693365.
> gs/base/gdevp14.c
> gs/base/gxp1fill.c

2013-09-17 20:02:34 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
3f098349c0ff70a50ebb0341f1e98da2c2330c84

> Bug 694132: Resolve uninitialised variable and handle returning error correctly.
> gs/base/gdevprn.c
> gs/base/gxicolor.c

2013-09-17 08:47:18 -0600
Henry Stiles <henry.stiles@artifex.com>
54ab9a05fbc13ad402aaa63c86d9ec0422bd112a

> Fix # 694595 - nothing produced reading PCL files.
> This change allows the command BP (Begin Plot) to initiate the HPGL/2
> parser for improperly constructed GL/2 files that lack the Enter GL/2
> command (<ESC>%1B).
> pcl/pcparse.c

2013-09-17 13:50:56 +0100
Robin Watts <robin.watts@artifex.com>
5347e2c3e43a28f64b0e4775945c6a58ee72debf

> Bug 691182: Disable interpolation for Type3 postscript images
> If we interpolate an image, but not its mask we get nasty edge
> effects. We therefore choose not to interpolate either.
> gs/psi/zimage3.c

2013-09-13 13:28:16 -0700
Michael Vrhel <michael.vrhel@artifex.com>
b7094e220951fc76656056a426ab7fa1363f38b7

> Make sure the mono device that is created for non-FAPI bold font caching has icc procs set.
> Fixes bug 694551
> Note Enhancement Bug 694593 was opened with this commit so that I will remember to review
> the setting of the get_profile procs for these devices.
> gs/base/gdevmem.c
> pl/plchar.c

2013-09-07 06:05:01 -0700
Michael Vrhel <michael.vrhel@artifex.com>
752aeb0e47fc11aff22618a00dd07576647c192d

> Avoid forced white point mapping in CMM when the source profile is derived from CIE PS type.
> LittleCMS and perhaps other CMMs have methods to force the white point in the mashed transform
> between source and destination color space. The methods used can lead to incorrect results
> when the source space is a non-traditional profile like those derived from CIEDEF(G) types.
> This fix gets and sets the appropriate flags for the CMM to avoid the white point alignment
> when the source space is PS based. Fixes bug 693826
> Fixing this bug revealed an issue in the CIEA color space conversion.
> Also, fixed old bug, mapping cie ps color spaces to ciexyz to allow ciexyz values larger than 1.0.
> Fixes bug 692807.
> Started changes to add in V2 profile creation.
> Fixed error handling in this part of code also.
> gs/base/gscie.h
> gs/base/gsciemap.c
> gs/base/gsicc.c
> gs/base/gsicc_cache.c
> gs/base/gsicc_cms.h
> gs/base/gsicc_create.c
> gs/base/gsicc_lcms.c
> gs/base/gsicc_lcms2.c
> gs/base/gsicc_manage.c
> gs/base/gsicc_manage.h
> gs/base/gxcie.h
> gs/devices/gdevrinkj.c
> gs/devices/gdevxcf.c
> gs/devices/vector/gdevpdfk.c

2013-09-12 18:08:53 +0100
Robin Watts <robin.watts@artifex.com>
808e6d525d978b6f083be8eeb2a612b343500693

> Bug 694590: Tweak scan converters handling of horizontal lines.
> The scan converter only puts horizontal edges into the edge list
> if expanding the height of the line by fill adjust causes it to
> cover a pixel centre.
> Unfortunately, for the fill_adjust = 0.5 case we actually use
> adjust_above = 128 and adjust_below = 127, so there is one possible
> subpixel offset for which the line will not appear. We therefore
> tweak the logic to accept all horizontal lines through in this case.
> This produces many diffs, all benign. Sorry Marcos.
> gs/base/gxfill.c

2013-09-12 12:21:48 +0100
Ken Sharp <ken.sharp@artifex.com>
002cd5262ccb71010473abfb9069e1fb39f36f12

> PDF interpreter - remove the 2D array of objects for large (>64k) objects
> Bug #694470
> In the past Ghostscript had a limit of 64k entries for arrays and strings
> but this proved a problem for some PDF files, so a set of new objects were
> defined 'larray' and 'lstring', which were defined as an array of arrays
> and an array of strings. New accessor and utility functions were also
> created.
> With bug 694470 there is an object with an index of 2^32 - 1, which takes
> a very long time, as the code allocates more and more sub-arrays.
> Now that we have a limit of 2^24 on arrays and strings (which can be increased),
> we can remove the 2d array hackery. This causes the bug file to abort almost
> immediately while rebuilding the xref. It *should* also provide a modest
> performance benefit, and makes the code smaller and easier to deal with.
> No differences expected.
> gs/Resource/Init/pdf_base.ps
> gs/Resource/Init/pdf_main.ps
> gs/Resource/Init/pdf_rbld.ps

2013-09-11 16:06:38 -0700
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
d97571b56d7c740e7d6aeee064313b96048a5667

> Fixed typo in lib.mak introduced in b5472ea6bf
> gs/base/lib.mak

2013-09-11 11:11:35 -0700
Michael Vrhel <michael.vrhel@artifex.com>
6dd5b91bbaf237ca3153722887d5965b0eb3633e

> Ensure overprint drawn components are updated with color space changes during transparency.
> Fixes bug 694297
> gs/base/gdevp14.c
> gs/base/gstrans.c

2013-09-11 18:47:45 +0100
Robin Watts <robin.watts@artifex.com>
faea7d6e98d6e7ee0b82d891544a13d703a291f5

> Bug 690790: Workaround libpng 64bit build bug.
> libpng keeps a jmpbuf in it's structure. jmp_bufs have to be 16 byte
> aligned on x64 systems, and the png allocator makes no effort to
> align the buffer.
> The workaround here changes the PNG allocator to allocate it's main
> structure in a larger block than it needs, and to actually use a
> block in the middle of this to ensure alignment. A pointer is
> kept to the real address of the block for freeing.
> gs/libpng/png.c
> gs/libpng/pngmem.c
> gs/libpng/pngstruct.h

2013-09-11 10:15:26 +0100
Ken Sharp <ken.sharp@artifex.com>
b5472ea6bf6925023febdeab12be9dbd83e811f1

> update ramfs code
> gs/base/gsioram.c
> gs/base/lib.mak
> gs/base/ramfs.c

2013-09-07 12:01:22 +0100
unknown <ken@.(none)>
db45b95faa06f8204b9a075323125d7f398c5d06

> PDF interpreter - process GoToR actions into pdfmarks for pdfwrite
> Bug #693427 "GoToR target file information lost after GS processing"
> This commit adds GoToR to the Existing GoTo and Named actions which the
> PDF interpreter will convert into pdfmarks. pdfwrite already handles
> the GoToR action so no changes were needed there.
> No differences expected
> New ram file system code
> Updated from the patch submitted by Michael Slade in bug #226943. This code
> removes a single Unix-ism and rewrites the memory allocations to use the
> GS garbage collected memory (as is appropriate for PostScript) instead of
> using the system malloc.
> No differences expected since we have no files that use the ramfs.
> gs/Makefile.in
> gs/base/gsioram.c
> gs/base/lib.mak
> gs/base/ramfs.c
> gs/base/ramfs.h
> gs/psi/msvc.mak

2013-09-07 12:01:22 +0100
unknown <ken@.(none)>
8425cde6e55dfaa26e64e81f54e044187fb98384

> PDF interpreter - process GoToR actions into pdfmarks for pdfwrite
> Bug #693427 "GoToR target file information lost after GS processing"
> This commit adds GoToR to the Existing GoTo and Named actions which the
> PDF interpreter will convert into pdfmarks. pdfwrite already handles
> the GoToR action so no changes were needed there.
> No differences expected
> gs/Resource/Init/pdf_main.ps

2013-09-06 17:58:57 -0500
Robin Watts <robin.watts@artifex.com>
e05fe9d24205f50ee12b97c22a5d1b34fa118ed0

> Bug 619917: Add support for configurable timeslice
> Add more of the patch from Herbert Swann. Many thanks again!
> gs/psi/zcontext.c

2013-09-06 15:35:50 -0500
Robin Watts <robin.watts@artifex.com>
ddc4b6753a40b2cbac503dbef300d339979274c8

> Bug 691917: Fix SEGVs in display postscript.
> Cutdown version of Herbert Swanns patch.
> gs/psi/zcontext.c

2013-09-06 15:49:10 -0500
Chris Liddell <chris.liddell@artifex.com>
64de3a6bf2b3a75123ae406076796f23a773aff1

> Bug 693629: fix outdated FSF address information.
> No cluster differences.
> gs/contrib/gdevbjc_.h
> gs/contrib/gdevcd8.c
> gs/contrib/gdevdj9.c
> gs/contrib/gdevlx32.c
> gs/contrib/opvp/gdevopvp.c

2013-06-13 18:07:01 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
66d9c0aa17a5abcecd6590e63f0620f7aa51634c

> Bug 694311 : GS openjpeg2 integration
> WIP : Update with latest OpenJPEG2. Warning - does not compile yet.
> WIP : Update code. Warning - does not compile yet.
> WIP : Code compiles but is not cluster tested.
> Update to build on xeon and macpro
> Use default image creation
> Add error/info/warning event handlers.
> Update fuzzing patch to allow j2kp4-file3-ycc-8bpc.pdf to process correctly.
> Update fuzzing patch to allow bug 691816 to process correctly without blurring.
> Patch to cater for eYCC colour space.
> Patch for indexed colour spaces and cater for bad BPCC header box.
> Cater for alpha channel information.
> gs/base/openjpeg.mak
> gs/base/sjpx_openjpeg.c
> gs/base/sjpx_openjpeg.h
> gs/configure.ac
> gs/openjpeg/libopenjpeg/CMakeLists.txt
> gs/openjpeg/libopenjpeg/bio.c
> gs/openjpeg/libopenjpeg/bio.h
> gs/openjpeg/libopenjpeg/cidx_manager.c
> gs/openjpeg/libopenjpeg/cidx_manager.h
> gs/openjpeg/libopenjpeg/cio.c
> gs/openjpeg/libopenjpeg/cio.h
> gs/openjpeg/libopenjpeg/dwt.c
> gs/openjpeg/libopenjpeg/dwt.h
> gs/openjpeg/libopenjpeg/event.c
> gs/openjpeg/libopenjpeg/event.h
> gs/openjpeg/libopenjpeg/function_list.c
> gs/openjpeg/libopenjpeg/function_list.h
> gs/openjpeg/libopenjpeg/image.c
> gs/openjpeg/libopenjpeg/image.h
> gs/openjpeg/libopenjpeg/indexbox_manager.h
> gs/openjpeg/libopenjpeg/invert.c
> gs/openjpeg/libopenjpeg/invert.h
> gs/openjpeg/libopenjpeg/j2k.c
> gs/openjpeg/libopenjpeg/j2k.h
> gs/openjpeg/libopenjpeg/jp2.c
> gs/openjpeg/libopenjpeg/jp2.h
> gs/openjpeg/libopenjpeg/mct.c
> gs/openjpeg/libopenjpeg/mct.h
> gs/openjpeg/libopenjpeg/mqc.c
> gs/openjpeg/libopenjpeg/mqc.h
> gs/openjpeg/libopenjpeg/openjpeg.c
> gs/openjpeg/libopenjpeg/openjpeg.h
> gs/openjpeg/libopenjpeg/opj_clock.c
> gs/openjpeg/libopenjpeg/opj_clock.h
> gs/openjpeg/libopenjpeg/opj_config.h
> gs/openjpeg/libopenjpeg/opj_config_private.h
> gs/openjpeg/libopenjpeg/opj_includes.h
> gs/openjpeg/libopenjpeg/opj_intmath.h
> gs/openjpeg/libopenjpeg/opj_inttypes.h
> gs/openjpeg/libopenjpeg/opj_malloc.h
> gs/openjpeg/libopenjpeg/opj_stdint.h
> gs/openjpeg/libopenjpeg/phix_manager.c
> gs/openjpeg/libopenjpeg/pi.c
> gs/openjpeg/libopenjpeg/pi.h
> gs/openjpeg/libopenjpeg/ppix_manager.c
> gs/openjpeg/libopenjpeg/raw.c
> gs/openjpeg/libopenjpeg/raw.h
> gs/openjpeg/libopenjpeg/t1.c
> gs/openjpeg/libopenjpeg/t1.h
> gs/openjpeg/libopenjpeg/t1_generate_luts.c
> gs/openjpeg/libopenjpeg/t1_luts.h
> gs/openjpeg/libopenjpeg/t2.c
> gs/openjpeg/libopenjpeg/t2.h
> gs/openjpeg/libopenjpeg/tcd.c
> gs/openjpeg/libopenjpeg/tcd.h
> gs/openjpeg/libopenjpeg/tgt.c
> gs/openjpeg/libopenjpeg/tgt.h
> gs/openjpeg/libopenjpeg/thix_manager.c
> gs/openjpeg/libopenjpeg/tpix_manager.c

2013-09-04 11:03:02 -0700
Michael Vrhel <michael.vrhel@artifex.com>
a92c4411e302b1b99fe65b5d89d26b87671feff5

> Removal of default initialization of ICC profile in languages. The default will be set when the page erase occurs.
> Thanks to Henry for catching this.
> pcl/pctop.c
> pxl/pxpthr.c
> pxl/pxtop.c
> svg/svgtop.c
> xps/xpstop.c

2013-08-30 10:00:41 +0100
Chris Liddell <chris.liddell@artifex.com>
45dfe09a18a7c19c626561d506ab44ee68421c41

> Update product string, dates and docs for 9.10 release.
> Bring master up to date with gs910 branch
> gs/base/version.mak
> gs/doc/API.htm
> gs/doc/C-style.htm
> gs/doc/Commprod.htm
> gs/doc/DLL.htm
> gs/doc/Deprecated.htm
> gs/doc/Details8.htm
> gs/doc/Details9.htm
> gs/doc/Develop.htm
> gs/doc/Devices.htm
> gs/doc/Drivers.htm
> gs/doc/Fonts.htm
> gs/doc/Helpers.htm
> gs/doc/History1.htm
> gs/doc/History2.htm
> gs/doc/History3.htm
> gs/doc/History4.htm
> gs/doc/History5.htm
> gs/doc/History6.htm
> gs/doc/History7.htm
> gs/doc/History8.htm
> gs/doc/History9.htm
> gs/doc/Install.htm
> gs/doc/Issues.htm
> gs/doc/Language.htm
> gs/doc/Lib.htm
> gs/doc/Make.htm
> gs/doc/News.htm
> gs/doc/Projects.htm
> gs/doc/Ps-style.htm
> gs/doc/Ps2epsi.htm
> gs/doc/Ps2pdf.htm
> gs/doc/Ps2ps2.htm
> gs/doc/Psfiles.htm
> gs/doc/Readme.htm
> gs/doc/Release.htm
> gs/doc/Source.htm
> gs/doc/Unix-lpr.htm
> gs/doc/Use.htm
> gs/doc/WhatIsGS.htm
> gs/doc/Xfonts.htm
> gs/doc/gs-vms.hlp
> gs/doc/thirdparty.htm
> gs/man/dvipdf.1
> gs/man/font2c.1
> gs/man/gs.1
> gs/man/gslp.1
> gs/man/gsnd.1
> gs/man/pdf2dsc.1
> gs/man/pdf2ps.1
> gs/man/pf2afm.1
> gs/man/pfbtopfa.1
> gs/man/printafm.1
> gs/man/ps2ascii.1
> gs/man/ps2epsi.1
> gs/man/ps2pdf.1
> gs/man/ps2pdfwr.1
> gs/man/ps2ps.1
> gs/man/wftopfa.1

2013-08-15 16:53:31 +0100
Robin Watts <robin.watts@artifex.com>
edb56190f321ea9e094cb161f9b94941d49a40ae

> Update antidropout downscaler.
> The antidropout downscaler is not consistent in the way it detects
> 'darker' colors; some of the code predicates 'darker' on the color
> polarity, other parts of it do not.
> Here we make it consistently follow the color polarity.
> Also, we correctly take the color polarity from the color space, rather
> than from the device. Thanks to Michael Vrhel for making the changes
> to make this possible.
> gs/base/gxiscale.c
> gs/base/sidscale.c

2013-09-03 18:01:55 +0100
Robin Watts <robin.watts@artifex.com>
02ab2adaafb3cc9322e54f0ea4e78952c34818d2

> Bug 694561: Fix interpolated landscape images (again).
> Don't try to accumulate runs of identical pixels in landscape images.
> We weren't aligning the transposed data to bitmap_align, and this was
> causing problems. It's unfeasible to do so, and the underlying driver
> almost certainly will break down to 1 call per pixel, so we might as
> well do that immediately and simplify the code massively.
> Also fix some warnings/unused variables.
> gs/base/gxcindex.h
> gs/base/gxiscale.c

2013-08-24 20:44:10 -0700
Michael Vrhel <michael.vrhel@artifex.com>
bdc103f817778f84efe66f10489c88a9263d279f

> Addition of new procedure to color spaces to return the polarity of the color space.
> gs/base/gsccolor.h
> gs/base/gscdevn.c
> gs/base/gscolor2.c
> gs/base/gscpixel.c
> gs/base/gscscie.c
> gs/base/gscsepr.c
> gs/base/gscspace.c
> gs/base/gsicc.c
> gs/base/gspcolor.c
> gs/base/gxcspace.h
> gs/base/gxdevcli.h

2013-09-03 12:59:05 +0100
Ken Sharp <ken.sharp@artifex.com>
5ae4180ca9d17f367acd068537f0a67a243656b8

> PS Interpreter - don't interpolate imagemask data for high level devices
> Bug #689460 "imagemask interpolation differs from Adobe"
> This is rather a long-running bug. The title isn't really very descriptive
> of the problem, as far as I can tell the problem only affects pdfwrite.
> In the current implementation, interpolation of imagemasks is handled in
> *PostScript*, by inserting the ImScaleDecode filter in front of the image
> DataSource. This works well for rendering, but for high level devicees
> (particularly pdfwrite) this means that we do not embed the original mask
> data, we embed the interpolated data. This makes the PDF file much larger
> and also means that when opened with Acrobat Reader, the output does not
> match, becuase Acrobat does interpolation by applying what looks like a
> Mitchell filter, and promoting the imagemask to 8 bpc.
> I did look into applying our current scheme in C, as suggested in comment #18,
> but that was inordintely difficult. We can't use the existing 1bpp image
> interpolation code, as that promotes to 8bpc and uses a Mitchell filter,
> so we lose the sharp edges, which is important for a mask. It probably would
> be possible to replicate the PostScript code which adds the ImScaleDecode
> filter to the DataSource, but there seems little point in doing this in
> C when it could be done more easily in PostScript.
> So instead I've chosen to test if the current device is a 'high level'
> device and, if it is, not to apply the filter.
> With pdfwrite this leads to us producing smaller PDF files, as expected,
> and the result in Acrobat matching the one from Distiller.
> When testing with the cluster a small number of Genoa test files exhibit
> differences. These all use the well known 'turkey' image at very low resolution,
> with the old code these were interpolated at 720 dpi and that was the image
> data written out. Now we write the original data and interpolate to the
> resolution of the actual device at rendering time. In the case of 300 dpi
> output this results in small but visible differences.
> gs/Resource/Init/gs_img.ps

2013-09-01 12:23:04 +0200
Simon Bünzli <zeniko@gmail.com>
42839db66a6cb026691c2e30af3489ff22d96b35

> bug 694281: fix memory leaks and compilation warnings
> * jbig2_build_huffman_table leaks LENCOUNT and result under OOM conditions
> * jbig2_decode_symbol_dict leaks an image in an error case
> * jbig2_symbol_dictionary skips cleanup in an error case
> * jbig2_text_region leaks GR_stats in various error and non-error cases
> * MSVC reports two "unreachable code" warnings and a "signed/unsigned
> mismatch" one
> gs/jbig2dec/jbig2.c
> gs/jbig2dec/jbig2_huffman.c
> gs/jbig2dec/jbig2_segment.c
> gs/jbig2dec/jbig2_symbol_dict.c
> gs/jbig2dec/jbig2_text.c

2013-09-02 12:26:59 +0100
Chris Liddell <chris.liddell@artifex.com>
1c1395aeeee68d545a3f293d6aa0ec38999879c9

> Update font versions in PPD files.
> A couple of ppd's contain version numbers for the font files, update them
> from 1.05 to 1.10
> CLUSTER_UNTESTED
> gs/contrib/pcl3/ppd/fonts.ppd
> gs/lib/ghostpdf.ppd

2013-09-01 18:48:32 -0700
Ray Johnston <ray.johnston@artifex.com>
f89dd1d4d38db72a9fc7a605072cf2a419e6f190

> Fix compiler warnings.
> gs/base/gxclpage.c
> gs/psi/imainarg.c
> gs/psi/int.mak

2013-07-11 13:03:17 -0700
Ray Johnston <ray.johnston@artifex.com>
9c95a9ae56b5051ba8c7c3b3d161932678d3b01d

> Enhance gx_saved_page and save_page function to support advanced functions.
> By saving the device params in the saved_page struct we can use it more
> generally to print pages out of order. This is still compatible with the
> rendering of multiple saved pages on a 'master' page for imposition, but
> the latter does not use the device params so pages with differing spot colors
> or differing destination ICC profiles may be incorrect. To be fixed later.
> Several utility functions support lists of saved pages: gx_saved_pages_list_new
> to allocate and initialize a saved page list; gx_saved_pages_list_add to alloc
> a new saved page object, fill it with the current page and add it to the end of
> the list; gx_saved_pages_list_print to print various pages in various orders
> from the list; gx_saved_pages_list_free to free the clist files for the saved
> pages as well as the saved pages and the saved pages list and to support the
> parameter and command line arg, gx_saved_pages_param_process. This function
> may be useful for applications as well. See psi/imainarg.c for sample usage
> with --saved-pages-test.
> Also, the gx_device_printer get and put params have an added saved-pages string
> parameter to allow control of this feature.
> A new command line option --saved-pages="..." is added that will call the
> 'process' function. This is implemented for BOTH gs imainarg and plmain used
> by the other languages. Also, --saved-pages-test is added for weekly testing
> that will collect all pages in a list (--saved-pages=begin) then after the
> file is processed, will print all pages (--saved-pages="print normal flush").
> The capability is mentioned in doc/Use.htm, and the parameters for the control
> string is documented in doc/SavedPages.htm
> gs/base/gdevdflt.c
> gs/base/gdevppla.c
> gs/base/gdevprn.c
> gs/base/gdevprn.h
> gs/base/gsdparam.c
> gs/base/gxclist.c
> gs/base/gxclist.h
> gs/base/gxclpage.c
> gs/base/gxclpage.h
> gs/base/gxclread.c
> gs/base/gxclrect.c
> gs/base/gxclthrd.c
> gs/base/gxdevsop.h
> gs/base/gxpcmap.c
> gs/base/lib.mak
> gs/base/string_.h
> gs/devices/gdevijs.c
> gs/devices/gdevp2up.c
> gs/devices/gdevtsep.c
> gs/doc/SavedPages.htm
> gs/doc/Use.htm
> gs/psi/imainarg.c
> gs/psi/iminst.h
> gs/psi/int.mak
> pl/pl.mak
> pl/plmain.c
> pl/plmain.h

2013-06-11 22:04:00 +0200
zeniko <zeniko@gmail.com>
e7b7ecff0277c0aa7e162edd21842dc4409391ff

> Bug 694121: prevent heap overflow
> jbig2_decode_symbol_dict checks whether more glyphs are requested than
> are available (SDNUMINSYMS + SDNUMNEWSYMS) but has so far failed check
> whether there are more than expected (SDNUMEXSYMS); fixes
> 3324.pdf.asan.3.2585
> gs/jbig2dec/jbig2_symbol_dict.c

2013-07-05 13:11:58 +0200
zeniko <zeniko@gmail.com>
f7064096ceac3d6c148096a936e1ea10fd8f0c55

> Bug 694111: prevent heap overflow
> jbig2_image_compose fails to ensure that the destination rectangle lies
> entirely within the destination buffer (in the case of the file
> 3324.pdf.asan.50.2585, this happens due to a huge value for y). Adding a
> new check which makes sure that...
> @ y * dst->stride + leftbyte doesn't overflow
> @ x and leftbyte don't overflow to the next line
> @ h * dst->stride doesn't overflow
> @ all values read are within the destination buffer
> The file 3324.pdf.asan.50.2585 also demonstrates a memory leak where the
> glyph isn't properly released if jbig2_image_compose fails.
> gs/jbig2dec/jbig2_image.c
> gs/jbig2dec/jbig2_text.c

2013-08-30 13:05:46 +0100
Ken Sharp <ken.sharp@artifex.com>
ca5a118174084f53893978d0c6b71d3a58db41bf

> PDF interpreter - synthesize appearance for multiline text widgets
> Bug 689761 "Multiline PDF form field does not honor line breaks"
> There are several parts to this change. Firstly there was a bug in the code
> to detect multiline text widgets, which meant that they were not detected
> and instead of flagging a warning and ignoring the widget, we handled it
> as if it were a single line. This also meant that we were mishandling combined
> fields as tetx fields.
> Secondly there is code in pdf-draw.ps which checks to see if we can synthesise
> an appearance and if we can it ignores the one provided. Testing with Acrobat
> indicates that this is what Acrobat does. However I think this is very wrong
> and in testing our code I see about as many files which are better if we
> use the appearance stream as are better if we manufacture one. So I've
> chosen (for now at least) to use the appearance stream if we're given one.
> Finally we now handle multiline text fields. The string is broken up into
> multiple strings at the line breaks. The height of the rectangle is divided
> by the number of strings, which allows us to space the lines evenly. We
> detect and implement the different types of quadding. Note that Acrobat
> does not seem to distribute the text the same way we do, but I don't see
> any reason to try and mimic it.
> Expected Differences
> Bug689450.pdf Bug692968.pdf 1503_text_missing .pdf Bug690526.pdf Bug692591.pdf
> these files have appearance streams that do not match up with the field values.
> 1783_CIDToGIDMap...pdf x_-_complex_fomr.pdf using the appearance stream
> improves the output because our synthesis is not that great.
> comb_and_password.pdf uses a combined field which we previously treated as
> text, and which we now ignore.
> gs/Resource/Init/pdf_draw.ps
> gs/Resource/Init/pdf_ops.ps

2013-08-29 16:47:29 +0100
Robin Watts <robin.watts@artifex.com>
621b010d1a6e12f7754508fee8a860345b4f84df

> Bug 694546: Fix undefined behaviour in gdevpbm.
> Thanks to jsmeix for reporting this.
> gs/devices/gdevpbm.c

2013-08-29 16:23:20 +0200
Tor Andersson <tor@ccxvii.net>
3659374423a9f7b0c4b361ce2e207549ae8b4e25

> xps: Check sfnt name table length before accessing array.
> Thanks to Shailesh Mistry.
> xps/xpsfont.c

2013-08-27 16:03:41 +0200
Tor Andersson <tor@ccxvii.net>
30355133c04d2ab3f270a6ea6ee28ae8fa91021b

> xps: Fix memory leak (bug 694469).
> Thanks to Shailesh Mistry.
> gs/base/gslibctx.c
> pl/plmain.c

2013-08-27 16:01:33 +0200
Tor Andersson <tor@ccxvii.net>
8017a6b547e12bc43d16f1057ac5dbf075a47d1e

> xps: Check for number of arguments when parsing abbreviated paths.
> Thanks to Shailesh Mistry.
> xps/xpspath.c

2013-08-27 15:45:09 +0200
Tor Andersson <tor@ccxvii.net>
9a85570458e46327dd8741c16c758669b5918ac4

> xps: Avoid infinite loop on syntax errors in abbreviated path geometry.
> Thanks to Shailesh Mistry.
> xps/xpspath.c

2013-08-27 15:43:14 +0200
Tor Andersson <tor@ccxvii.net>
82fd60791f60a00bbd42b042198d0cc2593c0790

> xps: Skip all but the first resource dictionary if there are many.
> Thanks to Shailesh Mistry.
> xps/xpspage.c
> xps/xpsresource.c

2013-08-27 15:42:44 +0200
Tor Andersson <tor@ccxvii.net>
bac315e9d796bff6707e1b96e75d403edddf7303

> xps: Ignore empty resource dictionaries.
> Thanks to Shailesh Mistry.
> xps/xpspage.c
> xps/xpsresource.c

2013-08-23 16:17:55 +0200
Tor Andersson <tor@ccxvii.net>
d4d0e216d1327dab177820e2f90cbb2dd38843c6

> xps: Check for missing pieces before dereferencing.
> Should only be able to happen if .last.piece is missing.
> Thanks to Shailesh Mistry.
> xps/xpszip.c

2013-08-23 16:11:03 +0200
Tor Andersson <tor@ccxvii.net>
62c8ba4fa3af5fbe395cd4923766ca8a44fc36f1

> xps: Check that Canvas.Resources has child node before descending.
> Thanks to Shailesh Mistry.
> xps/xpsanalyze.c

2013-08-23 16:08:37 +0200
Tor Andersson <tor@ccxvii.net>
8dc38533ab78a63c9c0a5c82ba96c45c0a9edebc

> xps: Check the existence of stripbytecounts before using in TIFF decoder.
> Thanks to Shailesh Mistry.
> xps/xpstiff.c

2013-08-27 17:34:29 +0100
Ken Sharp <ken.sharp@artifex.com>
88bce110851c10455d3165ca748a3371d9c917cc

> PostScript interpreter - make setpagedevice and EndPage work more like Adobe
> Bug 690667 "Changing PageSize during n-up processing by BeginPage/EndPage generates wrong output"
> The test job changes setpagedevice during the course of the job, and the
> EndPage takes special action depending on the page count. The first problem
> is that we don't reset the count of pages in the device, and Acrobat can
> be shown to do so on *any* call to setpagedevice (even if the dictionary
> is empty). In zsetdevice() we now reset the page count in the current device
> so that he page count is reset, even if the device doesn't change.
> Secondly we call .trysetparams before we execute the EndPage routine (if
> present). The problem here is that .trysetparams actually modifies the
> page device dictionary (and hence the device) and so attributes can change
> before the EndPage, in particular the PageSize. The /setpagedevice routine
> has been modified to move the execution of EndPage much earlier in the
> process. Again testing with Adobe Acrobat shows that the EndPage procedure
> is executed if the dictionary argument is empty, and indeed even if the
> execution of setpagedevice causes an error.
> No differences expected. Note this is a potentially destabilising change.
> gs/Resource/Init/gs_setpd.ps
> gs/psi/zdevice.c

2013-08-27 15:55:07 +0100
Ken Sharp <ken.sharp@artifex.com>
07ed0d0cb0de6ebc456a08ca0484c0e8a120b472

> PDF interpreter - clamp invalid numbers to 0 in Shading Coords
> Bug 694542 "Ghostscript failed to convert pdf file to images"
> The specimen file contains invalid numbers in the Coords array of every
> Shading dictionary. Acrobat (of course) handles this by silently converting
> all such numbers to 0.
> This commit checks the Coords of the Shading, and if any entry is not a number
> (our token parser converts invalid numbers to names) it replaces it with a
> xero.
> No differences expected
> gs/Resource/Init/pdf_draw.ps

2013-08-27 13:20:03 +0100
Chris Liddell <chris.liddell@artifex.com>
e413f6aa426fb63c2e9709ad8d28ab862bc1d44d

> Add the font embedding paragraph.
> The URW+ fonts are licensed under the GPL, with an additional allowance
> for embedding the fonts, and that embedding not affecting the license of
> the document in which the font is embedded.
> CLUSTER_UNTESTED
> gs/LICENSE

2013-08-27 11:21:37 +0100
Ken Sharp <ken.sharp@artifex.com>
8b6be8be2cdcefae39339682d45d3c009ab909ac

> pdfwrite - more discriminating tests before TrueType font combining
> Bug 694538 "Incorrect embedding of fonts"
> The test file does not appear to be the regular output of the MS Windows
> PostScript driver, it looks like several files have been stripped and then
> added together. A process liable to failure at the best of times.
> In this case we end up with a large number of incrementally downloaded,
> subset, TrueType fonts. Despite the fact that these are the same font and
> in many cases contain the same, or compatible, subsets the fonts are
> downloaded several times, which is why I believe this to be a combination
> of separately created files.
> pdfwrite tries to combine such fonts, and does so quite succcesfully in
> this case. However, the individual fonts are not all alike. Some information
> in the TrueType table is clearly copied from the original font (eg the
> numGlyphs value of 3147) and some is not. In particular the maxPoints
> value differs between two otherwise compatible subset fonts (one has additional
> glyphs). It seems Acrobat doesn't like this, it sometimes raises an error
> and does not display any glyphs whose point count exceeds the maxPoints
> value.
> This commit adds the maxPoints and maxContours values to the gs_type42_data
> structure and tracks them. Fonts are not now considered compatible if
> these values are different between them.
> This will lead to less font merging, but for sensibly created programs
> this will not be a problem, as the driver only downloads the font once. For
> programs created by jamming files together it will prevent the situation
> where we create a font which Acrobat cannot read.
> No differences expected.
> gs/base/gstype42.c
> gs/base/gxfont42.h
> gs/devices/gxfcopy.c

2013-08-26 14:31:28 +0100
Chris Liddell <chris.liddell@artifex.com>
e9b47527ec10d911f8154c60f746985e139606b8

> Bump version number
> gs/Resource/Init/gs_init.ps
> gs/base/version.mak

2013-08-30 10:00:41 +0100
Chris Liddell <chris.liddell@artifex.com>
7fcadf3b8b0ef1662419c15b8d51e36e434804be

> Update product string, dates and docs for 9.10 release.
> gs/base/gscdef.c
> gs/base/version.mak
> gs/doc/API.htm
> gs/doc/C-style.htm
> gs/doc/Commprod.htm
> gs/doc/DLL.htm
> gs/doc/Deprecated.htm
> gs/doc/Details8.htm
> gs/doc/Details9.htm
> gs/doc/Develop.htm
> gs/doc/Devices.htm
> gs/doc/Drivers.htm
> gs/doc/Fonts.htm
> gs/doc/Helpers.htm
> gs/doc/History1.htm
> gs/doc/History2.htm
> gs/doc/History3.htm
> gs/doc/History4.htm
> gs/doc/History5.htm
> gs/doc/History6.htm
> gs/doc/History7.htm
> gs/doc/History8.htm
> gs/doc/History9.htm
> gs/doc/Install.htm
> gs/doc/Issues.htm
> gs/doc/Language.htm
> gs/doc/Lib.htm
> gs/doc/Make.htm
> gs/doc/News.htm
> gs/doc/Projects.htm
> gs/doc/Ps-style.htm
> gs/doc/Ps2epsi.htm
> gs/doc/Ps2pdf.htm
> gs/doc/Ps2ps2.htm
> gs/doc/Psfiles.htm
> gs/doc/Readme.htm
> gs/doc/Release.htm
> gs/doc/Source.htm
> gs/doc/Unix-lpr.htm
> gs/doc/Use.htm
> gs/doc/WhatIsGS.htm
> gs/doc/Xfonts.htm
> gs/doc/gs-vms.hlp
> gs/doc/thirdparty.htm
> gs/man/dvipdf.1
> gs/man/font2c.1
> gs/man/gs.1
> gs/man/gslp.1
> gs/man/gsnd.1
> gs/man/pdf2dsc.1
> gs/man/pdf2ps.1
> gs/man/pf2afm.1
> gs/man/pfbtopfa.1
> gs/man/printafm.1
> gs/man/ps2ascii.1
> gs/man/ps2epsi.1
> gs/man/ps2pdf.1
> gs/man/ps2pdfwr.1
> gs/man/ps2ps.1
> gs/man/wftopfa.1

2013-08-29 16:47:29 +0100
Robin Watts <robin.watts@artifex.com>
b8d4701f17205624ebffe3d4630c9df87ac095b0

> Bug 694546: Fix undefined behaviour in gdevpbm.
> Thanks to jsmeix for reporting this.
> gs/devices/gdevpbm.c

2013-08-27 13:56:35 +0100
Chris Liddell <chris.liddell@artifex.com>
0680e46d927d1cc02a4bad4c3a90cb9adc3d4580

> Bring docs up to date for RC.
> gs/doc/API.htm
> gs/doc/C-style.htm
> gs/doc/Commprod.htm
> gs/doc/DLL.htm
> gs/doc/Deprecated.htm
> gs/doc/Details8.htm
> gs/doc/Details9.htm
> gs/doc/Develop.htm
> gs/doc/Devices.htm
> gs/doc/Drivers.htm
> gs/doc/Fonts.htm
> gs/doc/Helpers.htm
> gs/doc/History1.htm
> gs/doc/History2.htm
> gs/doc/History3.htm
> gs/doc/History4.htm
> gs/doc/History5.htm
> gs/doc/History6.htm
> gs/doc/History7.htm
> gs/doc/History8.htm
> gs/doc/History9.htm
> gs/doc/Install.htm
> gs/doc/Issues.htm
> gs/doc/Language.htm
> gs/doc/Lib.htm
> gs/doc/Make.htm
> gs/doc/News.htm
> gs/doc/Projects.htm
> gs/doc/Ps-style.htm
> gs/doc/Ps2epsi.htm
> gs/doc/Ps2pdf.htm
> gs/doc/Ps2ps2.htm
> gs/doc/Psfiles.htm
> gs/doc/Readme.htm
> gs/doc/Release.htm
> gs/doc/Source.htm
> gs/doc/Unix-lpr.htm
> gs/doc/Use.htm
> gs/doc/WhatIsGS.htm
> gs/doc/Xfonts.htm
> gs/doc/gs-vms.hlp
> gs/doc/thirdparty.htm
> gs/man/dvipdf.1
> gs/man/font2c.1
> gs/man/gs.1
> gs/man/gslp.1
> gs/man/gsnd.1
> gs/man/pdf2dsc.1
> gs/man/pdf2ps.1
> gs/man/pf2afm.1
> gs/man/pfbtopfa.1
> gs/man/printafm.1
> gs/man/ps2ascii.1
> gs/man/ps2epsi.1
> gs/man/ps2pdf.1
> gs/man/ps2pdfwr.1
> gs/man/ps2ps.1
> gs/man/wftopfa.1

2013-08-26 14:29:57 +0100
Chris Liddell <chris.liddell@artifex.com>
466d8f67a5b1ada99d05777ba33fab48a7d74bc9

> Change product string for release candidate
> gs/base/gscdef.c

## Version 9.10 (2013-08-27)

This is the ninth full release in the stable 9.x series, and is primarily a maintenance release.

Highlights in this release include:

- Background printing (BGPrint) is a new feature allowing an accumulated page clist to be rendered by one or more rendering threads whilst the interpreter (in the "main" thread) continues to accumulate the subsequent page's clist. For certain classes of file this can result in a useful performance increase. See: Banding Parameters

- GrayDetection allows suitably written devices to detect "color" input in near neutral tones (i.e. near monochrome) and to convert "on-the-fly" to pure grayscale, whilst retaining the ability to print full color on demand. This is primarily aimed at workflows where saving ink (especially color inks) is required. See: Device Parameters

- LittleCMS2 and libpng have both been updated to the latest versions.

- Support has been added to build the Ghostscript DLL for WinRT for x86, x64 and ARM (Requires MS Visual Studio 2012 Pro).

- Processing of Windows command line arguments into UTF8 (as presaged a few releases ago) has been enhanced and enabled by default.

- The URW Postscript font set has been updated to the latest version, fixing many compatibility problems with the Adobe fonts.

- Plus the usual round of bug fixes, compatibility changes, and incremental improvements.

For a list of open issues, or to report problems, please visit bugs.ghostscript.com.

### Incompatible changes

No recorded incompatible changes.

### Changelog

2013-08-29 16:47:29 +0100
Robin Watts <robin.watts@artifex.com>
b8d4701f17205624ebffe3d4630c9df87ac095b0

> Bug 694546: Fix undefined behaviour in gdevpbm.
> Thanks to jsmeix for reporting this.
> gs/devices/gdevpbm.c

2013-08-26 14:29:57 +0100
Chris Liddell <chris.liddell@artifex.com>
466d8f67a5b1ada99d05777ba33fab48a7d74bc9

> Change product string for release candidate
> gs/base/gscdef.c

2013-08-25 20:52:36 -0700
Ray Johnston <ray.johnston@artifex.com>
4a319086dd71dbcc3ec71b70277734595647784d

> Fix bug 694539. Reading off the end of the cbuf when dash pattern len is max.
> The max length dash pattern (currently 11) was used frequently in this file,
> and in at least one case, this tripped over a memmove that is way too large in
> the top_up_cbuf because the pointer was past the end of the buffer, and the
> unsigned int count was 0xffffffff. The root cause was that the cmd_largest_size
> used to set the warn_limit did not account for both the dot_length and the
> offset.
> I corrected cmd_largest_size, added some comments, and added an error message
> and ioerror return to top_up_cbuf.
> gs/base/gxcldev.h
> gs/base/gxclrast.c

2013-08-24 10:36:20 +0100
Ken Sharp <ken.sharp@artifex.com>
2001f469b539a5ccce301ace5d6384b6b7e46888

> Fix -dUseCIEColor (part of the whole VM allocation problem)
> See commit ae930279498a5961fcf5d70ffe86864883609cbc for a lengthy explanation)
> of the background to this problem.
> The fix for the original problem involved always creating the device dictionary
> for setpagdevice in local VM.
> Following on from that we discover the following in zdsp1.c
> gstate_check_space(i_ctx_t *i_ctx_p, int_gstate *isp, uint space)
> {
> /*
> * ****** WORKAROUND ALERT ******
> * This code doesn't check the space of the non-refs, or copy their
> * contents, so it can create dangling references from global VM to
> * local VM. Because of this, we simply disallow writing into gstates
> * in global VM (including creating them in the first place) if the
> * save level is greater than 0.
> * ****** WORKAROUND ALERT ******
> Now, if we execute the Display PostScript .savelocalstate routine, its vital
> that the gstate and all its contents be in global VM in order to satisfy
> the test in zdps1.c.
> So, any calls to setpagedevice before the call to .savelocal must allocate
> the page device dictionary in global VM (as a pointer to the device dictionary
> is saved in the gstate)
> Thus we need a way to tell setpagedevice to allocate its dictionary in global
> VM, even though we usually want it in local VM.
> This commit adds a somewhat hacky method for this, we insert a specific key
> /..StartupGlobal in the page device dictionary. If setpagedevice finds this
> key in the dictionary we allocate the dict in global VM, and remove the key.
> We then use this key in a couple of places in gs_init.ps where we execute
> setpagedevice *before* we've reached .savelocalstate.
> This fixes all the myriad problems with allocation states and gives us a way
> to add any more that are required.
> I've put a comment into gs_init.ps immediately before /.savelocalstate so
> at least in the future it will be easier to figure out where this is required.
> I've searched all the initialisation files looking to see if there are any
> other likely places (the INITFILES string is parsed before we get to
> .savelocalstate) and they all look acceptable. None of the routines actually
> execute setpagedevice.
> No cluster differences expected as none of this is tested
> gs/Resource/Init/gs_init.ps
> gs/Resource/Init/gs_setpd.ps

2013-08-23 09:15:32 +0100
Ken Sharp <ken.sharp@artifex.com>
c1510d726063080559e9597db7d4a686f2ca4eae

> correct some typos in PDFDocEncoding to UTF8 conversion
> Bug #694535 "Typo in charset conversion in gdevpdfe.c"
> Credit (and thanks) to Tim Waugh at Red Hat for the fix, applied here.
> No differences expected, we clearly don't have any examples that exercise
> this particular case in our test suite.
> gs/devices/vector/gdevpdfe.c

2013-08-23 08:42:46 +0100
Ken Sharp <ken.sharp@artifex.com>
ae930279498a5961fcf5d70ffe86864883609cbc

> More work related to VM mode, setpagdevice and startup conditions
> This has a lengthy bug tail attached to it, the summary follows, prior
> commits of interest are (ordered by date, earliest first):
> 073f7be1671e7fa2dbbc75984e593d2279bb05d7
> 939e32ff3c8841507aed80435269457f3caac6f5
> 774231a7db63439c72313050a750b219491c172f
> 39b494d41a814e6b27a5828030e58e0b239044fb
> Initially the bug report was #687702 "gs8.15 setpagedevice /invalidaccess",
> the problem was caused by a 'fix' for WordPerfect files which assumed a local
> VM writeable dictionary returned by currentpagedevice. The fix was to create
> a local VM copy of the dictioanry, because its acceptable to store global
> objects in local VM, but not vice versa. (073f7be1671e7fa2dbbc75984e593d2279bb05d7)
> However, if we start with -dSAFER then, quite early in gs_init.ps, we call
> /.setsafe (which called /.locksafe) which ends up executing setpagdevice
> in order to set /LockSafetyParams. This causes the page device dictionary to
> be allocated in local VM. This should not cause any problems, but.....
> setpagedevice stores a pointer to the returned dictionary in the graphics
> state, the Display PostScript initialisation code insists that all objects
> in the 'savedinitialgstate' be in global VM, and we just allocated the dict
> in local VM, so we get an error.
> This was fixed in setpagedevice by checking for a 1 element dictioanry
> with the specific key '/LockSafetyParams', and creating a global VM dict
> instead of a local one. (939e32ff3c8841507aed80435269457f3caac6f5)
> We then discovered that GSView sends PostScript containing '.locksafe',
> which triggers the check in sepagedevice and sets the VM allocation mode
> to global, causing an invalidaccess error. GSView should not be using
> undocumented internal routines but it was decided to fix this, even though
> a release had just been completed. This was done by creating a new routine
> '.locksafeglobal' which sets a key called /LockSafetyParamsGlobal and
> having setpagedevice check for that key, if discovered it creates a global
> VM dictionary and replaces the key with /LockSafetyParams. Finally /.locksafety
> was returned to its original state. (774231a7db63439c72313050a750b219491c172f)
> A new release was completed, and it then transpired that, despite having
> tested gv briefly, under certain conditions it executes a script (pdf2dsc)
> which uses pdf2dsc.ps, which calls .setsafe. This didn't seem terribly
> important and so the line was removed from the PS file.
> Ray pointed out that the .setsafe routine is (minimally) documented in
> use.htm, and it seems is important to the Unix community because of the
> 'SAFER' switch. So this commit restores /.setsafe (and the line in pdf2dsc.ps)
> and creates a new /.setsafeglobal. This is *only* executed in gs_init.ps,
> its presence is solely for the benefit of DPS so that the initial gstate
> is allocated in global VM, and must not be used anywhere else.
> Hopefully we can finally say goodbye to all this mess now.
> gs/Resource/Init/gs_init.ps
> gs/lib/pdf2dsc.ps

2013-08-22 16:07:29 +0100
Ken Sharp <ken.sharp@artifex.com>
39b494d41a814e6b27a5828030e58e0b239044fb

> remove a '.setsafe' from the PS file it doesn't work any more and nobody
> should be using undocumented internal routines anyway.
> We should probably remove pdf2dsc altogether, it relies on using parts
> of the PDF interpreter which, as far as I'm concerned, are subject to
> change without notice.
> gs/lib/pdf2dsc.ps

2013-08-22 13:33:14 +0100
Ken Sharp <ken.sharp@artifex.com>
dfd7fc9fe152245256e437141dd7780c8313c971

> pdfwrite - make the saved gstate stack dynamically allocated instead of static array
> Bug #693591 "Infinite loop writing pdf file"
> Bug #694531 " "*** File has unbalanced q/Q" infinite loop on seemingly valid file"
> The stack of saved gstates in pdfwrite was a statically allocated array of 11
> elements. Cairo produces PDF files with insane (and pointless) levels of
> Form XObject nesting which can easily break this limit (as well as causing all
> PDF consumers to render the files slowly)
> This commit replaces the fixed size array with a dynamically allocated array.
> For performance reasons we still allocate 11 elements initially, and if we
> exhaust the storage, we reallocate 5 elements larger.
> This also shows a progression in the test file 'inefficient_tiling.pdf' this
> file is produced by LaTeX but I guess it may be using Cairo behind the
> scenes.
> gs/devices/vector/gdevpdf.c
> gs/devices/vector/gdevpdfb.h
> gs/devices/vector/gdevpdfg.c
> gs/devices/vector/gdevpdfx.h

2013-08-16 10:35:58 +0100
Chris Liddell <chris.liddell@artifex.com>
868bcc0c697619a276e725fd851b5f52079e64a5

> Bring master up to date with 9.09 release branch
> update docs, version numbers, dates and product string
> Update product string, dates and changelog for 9.09 release.
> No cluster differences.
> gs/base/version.mak
> gs/doc/API.htm
> gs/doc/C-style.htm
> gs/doc/Commprod.htm
> gs/doc/DLL.htm
> gs/doc/Deprecated.htm
> gs/doc/Details8.htm
> gs/doc/Details9.htm
> gs/doc/Develop.htm
> gs/doc/Devices.htm
> gs/doc/Drivers.htm
> gs/doc/Fonts.htm
> gs/doc/Helpers.htm
> gs/doc/History1.htm
> gs/doc/History2.htm
> gs/doc/History3.htm
> gs/doc/History4.htm
> gs/doc/History5.htm
> gs/doc/History6.htm
> gs/doc/History7.htm
> gs/doc/History8.htm
> gs/doc/History9.htm
> gs/doc/Install.htm
> gs/doc/Issues.htm
> gs/doc/Language.htm
> gs/doc/Lib.htm
> gs/doc/Make.htm
> gs/doc/News.htm
> gs/doc/Projects.htm
> gs/doc/Ps-style.htm
> gs/doc/Ps2epsi.htm
> gs/doc/Ps2pdf.htm
> gs/doc/Ps2ps2.htm
> gs/doc/Psfiles.htm
> gs/doc/Readme.htm
> gs/doc/Release.htm
> gs/doc/Source.htm
> gs/doc/Unix-lpr.htm
> gs/doc/Use.htm
> gs/doc/WhatIsGS.htm
> gs/doc/Xfonts.htm
> gs/doc/gs-vms.hlp
> gs/doc/thirdparty.htm
> gs/man/dvipdf.1
> gs/man/font2c.1
> gs/man/gs.1
> gs/man/gslp.1
> gs/man/gsnd.1
> gs/man/pdf2dsc.1
> gs/man/pdf2ps.1
> gs/man/pf2afm.1
> gs/man/pfbtopfa.1
> gs/man/printafm.1
> gs/man/ps2ascii.1
> gs/man/ps2epsi.1
> gs/man/ps2pdf.1
> gs/man/ps2pdfwr.1
> gs/man/ps2ps.1
> gs/man/wftopfa.1

2013-08-21 14:26:57 +0100
Ken Sharp <ken.sharp@artifex.com>
243c299262d0e5ebac46f517e749a3d45cbe9c46

> Fix a compiler warning which exhibited a real problem
> In gdevpdfp.c remove a redefinition of 'code'. The 'for' loop uses the
> outer definition of 'code', but the inner definition is set by
> cos_dict_put_c_key_string() This means that the inner definition is never
> used, and the outer one used to control the loop is never changed, defeatimg
> the purpose.
> The other new compiler warnings in pdfwrite are either not valid (some warnings
> are incorrect) or benign and fixing them introduces other warnings.
> gs/devices/vector/gdevpdfp.c

2013-08-21 13:23:52 +0100
Ken Sharp <ken.sharp@artifex.com>
077435083eb0d8acb91686ba8b745ec8371e16fd

> Correct the evaluation order in filenameforall processing
> gs/base/gp_ntfs.c

2013-08-21 10:13:59 +0100
Ken Sharp <ken.sharp@artifex.com>
735589e5b16cf3d31c6bf73ebd75259db9d18f3c

> Yet more work on NTFS file enumeration
> Bug #686853, SaGS comment #9
> We now match the pattern template only at the top level of the recursion,
> any directories which match the pattern are enumerated, but their entire
> contents are listed.
> Multiple path separators are now removed at each level. It should now be
> impossible to reach a situation where a returned file has '\/' or similar
> contained within it.
> Illegal characters ('*' and '?') in the path will now cause no matches to
> be returned. These are of course valid after the final separator of the
> path and will match filename patterns at that level.
> I've checked this with various paths utilising multiple path separators,
> mixed use of separators, illegal escaped characters in the path and a modest
> variety of patterns. All this with COMPILE_INITS=0 and COMPILE_INITS=1 and
> in both cases with GS_NO_UTF8=1 and without specifying GS_NO_UTF8. All seems
> to be OK in all cases. None of this is tested by the cluster of course.
> CLUSTER_UNTESTED
> gs/base/gp_ntfs.c

2013-08-20 10:21:09 +0100
Chris Liddell <chris.liddell@artifex.com>
b0c3a494395db460cbb8e28a6896eebccc6b797a

> Ensure we don't overflow the filename buffer.
> No cluster differences.
> gs/base/gp_unifs.c

2013-08-20 10:23:02 +0100
Ken Sharp <ken.sharp@artifex.com>
c1544d825be1f87ed0821ef0163d08595b5fc0e6

> Make the Windows implementation of filenameforall match the Unix version
> The Unix version of filenameforall starts in the current working directory
> when no directory is specified.
> When the pattern length exceeds the available string we should return a
> rangecheck error, not an empty string.
> When the filename exceeds the available string we should return a
> rangecheck error, not a truncated string.
> CLUSTER_UNTESTED
> gs/base/gp_ntfs.c

2013-08-19 15:06:12 +0100
Ken Sharp <ken.sharp@artifex.com>
d6921b5c5ab2af44c48e0084e4a31bcd7512f183

> Allow use of '\\' for filenameforall and friends on Windows
> The commit to allow recursive directory enumeration f13bfba removed the
> code which translated '\\' into '\', which could lead to incorrect filenames
> being returned.
> This fix restores that functionality, but we still think everyone would be
> better advised to use the PostScript '/' separator instead, which works as
> well as '\' does.
> CLUSTER_UNTESTED
> gs/base/gp_ntfs.c

2013-08-18 21:05:00 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
613554e16d315c8db89653775c1fdcf682f238fe

> Add quotes around values for a conditional for VS build.
> CLUSTER_UNTESTED
> main/pcl6_msvc.mak

2013-08-16 14:00:43 +0100
Ken Sharp <ken.sharp@artifex.com>
7d93cf893d1d2fac826e3c5f81ea92123425216e

> Address gp_wgetv not finding *any* environment variables unless compiled with GS_NO_UTF8
> The string being passed in as the 'name' was a regular 1 byte C char array.
> But _wgetenv expects to be given a wide character string to find and
> treats the argument as such. This mean environment variables never matched.
> This commit mimics the code for the registry variables, and converts the
> name to a wchar before passing to _wgetenv.
> CLUSTER_UNTESTED
> gs/base/gp_wgetv.c

2013-08-02 09:32:00 +0100
Chris Liddell <chris.liddell@artifex.com>
ae09189f11f59c2d350cca820c880cd48a0657d0

> Fix a couple of very minor UFST build issues.
> Automatically drop the default Truetype fonts if we're integrating the UFST
> (with it's attendant MT fonts).
> No cluster differences.
> main/pcl6_gcc.mak
> main/pcl6_msvc.mak

2013-08-16 12:47:36 +0100
Chris Liddell <chris.liddell@artifex.com>
e67e098fa0b5bf7570453c15ccc98fabf1e561dc

> Fix GS_NO_UTF8 build problem with gs_sprintf.
> CLUSTER_UNTESTED
> gs/base/gp_wgetv.c

2013-08-16 07:58:57 +0100
Ken Sharp <ken.sharp@artifex.com>
774231a7db63439c72313050a750b219491c172f

> PS Interpreter - yet more meddling with VM allocation and setpagedevice
> Bug #694525 "GSView 5.0 does not work with GPL Ghostscript 9.08"
> Rather horrifyingly GSView uses undocumented internal operations of
> Ghostscript. In this case the changes to VM allocation mode during setpagedevice
> were being circumvented.
> This commit changes the way we detect a setpagedevice during startup, previously
> we check that the dictionary contained one key called /.LockSafetyParams
> and if so assumed that this meant we were in startup, so we set the VM
> allocation mode to global for the benefit of Display PostScxript.
> GSView ended up triggering that test, which caused a VM allocation error.
> We now look for the key /.LockSafetyParamsGlobal instead. If this is present
> we set the VM allocation mode to global and *replace* the key with
> /.LockSafetyParams instead. This allows accurate detection of the startup
> condition.
> No differences expected, GSView 5 seems to work and the original bug still
> is fixed.
> gs/Resource/Init/gs_init.ps
> gs/Resource/Init/gs_setpd.ps

2013-08-15 19:56:59 +0100
Chris Liddell <chris.liddell@artifex.com>
4be79a96fe22c988cc4d9edfedac75e6f46e15fa

> Bump version number.
> The usual cluster differences.
> gs/Resource/Init/gs_init.ps
> gs/base/version.mak

2013-08-15 16:53:17 +0100
Robin Watts <robin.watts@artifex.com>
43e4db79a40b2ac73eac2bf3732f2e2dcc122d12

> Update special antidropout downscaler code.
> In hunting for bug 694451, it looked like the problem was in the
> special antidropout downscaler for a while, but this turned out
> not to be the culprit.
> Nonetheless, the code had not been updated to take advantage of the
> 'Active' region optimisations, so we do that here.
> gs/base/sidscale.c

2013-08-15 16:09:24 +0100
Chris Liddell <chris.liddell@artifex.com>
f86ac4209753ea0e9e06a9f4c22a19a8447b5fb5

> Some chenges fed back from customer #661 and.....
> some function naming tidy ups I've been meaning to do for some time.
> The changes from #661 make the code a bit more flexible for different
> configurations of the font rendering library.
> No cluster differences.
> gs/base/fapi_ft.c
> gs/base/fapiufst.c

2013-08-15 09:06:30 +0100
Ken Sharp <ken.sharp@artifex.com>
6ba5abfa7325ae980bba37fdc71582eeca152a87

> update caption.ps so that it does not mark the page on device deactivation
> Bug #694517 "additional page with caption.ps"
> The EndPage procedure in caption.ps marks the page in the file with the
> defined caption regadless of the reason code for the EndPage. This means
> that it marks the page even on device deactivation.
> Since commit 3894e9c8a3ab125c82048da3bf81515500bb2da0 pdfwrite will emit
> pages that are marked, even if no showpage is executed (this is to match
> observed Acrobat Distiller behaviour) and this means that an extra 'blank'
> page is emitted on device deactivation.
> This commit simply modifies caption.ps so that it only writes the caption
> if the reason for calling EndPage is *not* device deactivatyion.
> gs/lib/caption.ps

2013-07-31 07:45:02 +0100
Chris Liddell <chris.liddell@artifex.com>
a65df0454d1a8de06d2d342100408482c9ec101b

> Bring master up to date with 9.08 release branch.
> Change product string for release candidate.
> No unexpected cluster differences.
> Update version and product strings for release candidate.
> Update news and history for 9.08 release.
> Update release date for 9.08 release.
> gs/base/gscdef.c
> gs/base/version.mak
> gs/doc/API.htm
> gs/doc/C-style.htm
> gs/doc/Commprod.htm
> gs/doc/DLL.htm
> gs/doc/Deprecated.htm
> gs/doc/Details8.htm
> gs/doc/Details9.htm
> gs/doc/Develop.htm
> gs/doc/Devices.htm
> gs/doc/Drivers.htm
> gs/doc/Fonts.htm
> gs/doc/Helpers.htm
> gs/doc/History1.htm
> gs/doc/History2.htm
> gs/doc/History3.htm
> gs/doc/History4.htm
> gs/doc/History5.htm
> gs/doc/History6.htm
> gs/doc/History7.htm
> gs/doc/History8.htm
> gs/doc/History9.htm
> gs/doc/Install.htm
> gs/doc/Issues.htm
> gs/doc/Language.htm
> gs/doc/Lib.htm
> gs/doc/Make.htm
> gs/doc/News.htm
> gs/doc/Projects.htm
> gs/doc/Ps-style.htm
> gs/doc/Ps2epsi.htm
> gs/doc/Ps2pdf.htm
> gs/doc/Ps2ps2.htm
> gs/doc/Psfiles.htm
> gs/doc/Readme.htm
> gs/doc/Release.htm
> gs/doc/Source.htm
> gs/doc/Unix-lpr.htm
> gs/doc/Use.htm
> gs/doc/WhatIsGS.htm
> gs/doc/Xfonts.htm
> gs/doc/gs-vms.hlp
> gs/doc/thirdparty.htm
> gs/man/dvipdf.1
> gs/man/font2c.1
> gs/man/gs.1
> gs/man/gslp.1
> gs/man/gsnd.1
> gs/man/pdf2dsc.1
> gs/man/pdf2ps.1
> gs/man/pf2afm.1
> gs/man/pfbtopfa.1
> gs/man/printafm.1
> gs/man/ps2ascii.1
> gs/man/ps2epsi.1
> gs/man/ps2pdf.1
> gs/man/ps2pdfwr.1
> gs/man/ps2ps.1
> gs/man/wftopfa.1
> gs/psi/winint.mak

2013-08-14 16:42:49 +0100
Robin Watts <robin.watts@artifex.com>
c07d6c816052686d29efdee5e94567066baaf75a

> Remove stray cluster products.
> These should never have been committed.
> clustercmd
> clusterdatestamp

2013-08-14 08:59:31 +0100
Ken Sharp <ken.sharp@artifex.com>
2c369110313fda917820faf3657dee55158b538b

> PS Interpreter - populate the /OutputDevice resource
> Bug #689500 "/OutputDevice category is empty"
> This commit uses the devices built into the executable to populate the
> /OutputDevice resource. The bug thread suggests using devicedict but we
> can't do that in gs_res.ps because it isn't set up until later. So we
> duplicate the code used to populate devicedict.
> According to the PLRM the only required member of the OutputDevice resource
> instance is the PageSize, I've chosen to copy the same values as Adobe Acrobat
> Distiller, but these can be changed if this proves to be a limitation.
> Two additional changes were required, exposed by the Quality Logic test file
> 09-59.ps
> In gdevdevn.c devn_get_params() it is possible for the function to be called
> with pequiv_colors set to NULL, this caused a seg fault. Modified the code
> so that it doesn't attempt to dereference a NULL pointer.
> The file 09-59.ps uses setpagedevice to set each possible instance of the
> OutputDevice resources, this can cause problems with some devices as it
> doesn't actually send a file. In particular with the mswinpr2 device on
> Windows, but it also caused errors on Linux. Since this is a CET file,
> gs_cet.ps was modified to delete the OutputDevice resource category and
> create a new empty one.
> Expected Differences
> 430-01.ps enumerates all the entries in /OutputDevice and so has a *lot*
> more data to print.
> gs/Resource/Init/gs_cet.ps
> gs/Resource/Init/gs_res.ps
> gs/base/gdevdevn.c

2013-08-13 00:04:57 -0700
Michael Vrhel <michael.vrhel@artifex.com>
b89761f06d297f8555f346e9c0a7850fc549c668

> Fix for problem with double application of alpha when composing isolated groups.
> gs/base/gxblend1.c

2013-08-13 13:48:52 -0700
Ray Johnston <ray.johnston@artifex.com>
6c7d9d1191ed4afad16f7bc4089a43bb18190a96

> Fix bug 694514. Don't use clist HL images in pattern-clist when interpolated.
> Since patterns that are put in the clist are large, interpolating multiple
> times for every band intersected by the pattern can kill performance.
> clustercmd
> clusterdatestamp
> gs/base/gxclimag.c
> gs/base/lib.mak

2013-08-13 15:30:55 +0100
Chris Liddell <chris.liddell@artifex.com>
d7c310e59953aacdeb642ce202c0911071a80d31

> Bug 694513: force chars to signed on AIX with Luratech
> The Lutatech JBIG2 decoder requires signed chars, so add the requisit flags for
> for the Luratech build to ensure that happens.
> No cluster differences.
> gs/configure.ac

2013-08-09 17:02:40 -0700
Ray Johnston <ray.johnston@artifex.com>
e9f0f0eb05ee0abea13deabab6617d20e1913e83

> Fix bug 694455. Incorrect CTM when rendering SMasks.
> The clippath was incorrect due to the CTM. As specified in 7.5.4 of the PDF spec:
> The mask's coordinate system is defined by concatenating the transformation
> matrix specified by the Matrix entry in the transparency group's form dictionary
> (see Section 4.9.1, "Form Dictionaries") with the current transformation matrix
> at the moment the soft mask is established in the graphics state with the gs
> operator.
> This fixes the customer's file and also results in a progression on
> comparefiles/Bug693681.pdf where extra data was previously showing.
> gs/Resource/Init/pdf_draw.ps

2013-08-09 16:00:23 +0100
Ken Sharp <ken.sharp@artifex.com>
e72c03d49e6c0e107afa32b5b2b8a6cf9d43b663

> PDF Interpreter - undo commit 946f63b5748a5a19c369a1d42e653c69cd57075e
> Marcos wants to have files produce an error, so we don't run them in a
> stopped context any more.
> In fact it appears that later work means none of these files exit the
> interpreter on error any more, they do produce PostScript error messages
> though.
> 1305_-_crypt_filter_length_ignored.pdf.pdf
> 1479_-_does_not_render.pdf
> 1931_-_crypt_version_5_revision_6.pdf
> 692248_-_recursive_ObjStm_ref.pdf
> 692248_-_wrong_ObjStm_ref.pdf.pdf
> 694313_-_double-free_during_reparation_fails_.pdf
> 694313_-_empty_xref.pdf
> Adobe_LiveCycle_DRM_protection_sample_Adobe.APS_-_adbe.pdrl.v0_fails_.pdf
> MSVR_176_-_missing_range_check_in_pdf_repair_fails_.pdf
> MSVR_201_-_missing_CIDSystemInfo.pdf
> annotations_without_font.pdf
> double_indirect_reference.pdf
> huge_cmap_values.pdf
> recursive_indirect_reference.pdf
> recursive_outline.pdf
> repairing_leaks_object.pdf
> x_-_SumatraPDF1.1DOS.pdf
> all now produce errors again
> gs/Resource/Init/pdf_main.ps

2013-08-09 15:15:53 +0100
Chris Liddell <chris.liddell@artifex.com>
44800428c346804af98b1d9b2e86b6d8e61b858b

> Delete the ._.DS_Store .DS_Store files.....
> which cause problems decompressing release archives on OS X.
> gs/lcms2/Projects/mac/.DS_Store
> gs/lcms2/Projects/mac/._.DS_Store

2013-08-09 13:50:19 +0100
Ken Sharp <ken.sharp@artifex.com>
010e9990d734a8a2361663338b1fbd605d0ca052

> PDF interpreter and pdfwrite - better handling of Outlines and Dests
> Bug #690253 "'pdfmark destination page' error while splitting a PDF: confusing output and invalid links."
> Several parts to this, we had already removed the 'ERROR' from the message
> emitted when a DEST or OUT pdfmark pointed to a page outside the valid range.
> This commit makes pdfmark produce an error when an Outline has an invalid
> range (DEST laready did). We also wrap pdfmark invocations in 'stopped' so
> that we can trap the error. This allows us to elide Links and Outlines to
> invalid pages (previously the links remained, but did nothing useful).
> Since the bug was raised, we now also use the '%d' syntax to split PDF
> files. This would still produce invalid links, because the page number
> would not be invalid.
> We now check the OutputFile when opening a PDF file, and if it contains
> '%d' we set a couple of flags which will skip Outline and Dest link creation
> as these would never be correct.
> gs/Resource/Init/pdf_main.ps
> gs/devices/vector/gdevpdfm.c

2013-08-08 08:50:23 +0100
Ken Sharp <ken.sharp@artifex.com>
a850d6c6d14f3a40bb8d40e471bf4822ead8580d

> PDF Interpreter - update to 073f460af5bb37edb1849c5d6235048598100437
> Bug #694508 "Regression: error writing PDF file starting with
> 72b397ecb4f5be3fdbf6da4a90a306d259ec3e93"
> The commit 073f460af5bb37edb1849c5d6235048598100437 had an error in the
> handling of named actions, which I didn't previously have a test case for.
> NB the commit in the bug title is incorrect, I'm not clear on why Marcos
> thought this was the commit which introduced the error.
> This commit fixes that and allows me to test the named actions, which now
> work correctly.
> gs/Resource/Init/pdf_main.ps

2013-08-07 13:18:16 +0100
Ken Sharp <ken.sharp@artifex.com>
073f460af5bb37edb1849c5d6235048598100437

> PDF interpreter - improve handling of pdfmarks when we have multiple input files
> Bug #688542 "Bookmarks Get Lost In PDF"
> Bug #688829 "Merging PDF files using gs: outlines and links not updated"
> The pdfmarks generated by the PDF interpreter for Outlines and Links use the
> page number relative to the start of the current input file. For single
> input files this works fine, but when we have multiple input files, we end
> up with outlines and links pointing to the wrong place.
> To resolve this we need to know, at the start of any PDF file, how many pages
> have already been processed, and then we will add this value to the nominal
> page number when creating the pdfmarks.
> Hin-Tak provided a solution (#688829) that used globaldict, which Alex rejected
> for that reason. This commit executes currentpagedevice at the start of every
> PDF input file, and stores in in /CumulativePageCount. We can then use this
> to generate pdfmarks which are correct.
> Even if PDF and PostScript input files are mingled, the PDF-generated pdfmarks
> will still be correct.
> We won't make any attempt to correct PostScript input, if you are creating a
> PostScript program, you should get it right. If you really must merge, then
> use pdfwrite to create the individual PDF files, and then merge those.
> It is possible that other types of generated pdfmark will need similar
> alteration, we'll tackle those as they turn up.
> gs/Resource/Init/pdf_main.ps

2013-08-05 17:42:53 +0100
Ken Sharp <ken.sharp@artifex.com>
22e66c90bf173e4787717137a25833b4aa823993

> PDF interpreter - increased checking of Outlines, to avoid errors
> Bug #694503 "Regression: output pdf file blank starting with 0c8150ab6b2b8ceaa17cc1b1933d523764ffe114"
> After attempting to recover from broken objects, it was possible to
> throw an error when processing Outlines, because the recovered object
> was of the wrong type. This could cause PDF files with broken /Outlines to
> fail with pdfwrite, where previously they would write a file, but drop the
> /Outlines. (this only occurs wiht pdfwrite, because we ignore Outlines
> when rendering)
> This commit restores the previous behaviour by checking the type of the returned
> object.
> gs/Resource/Init/pdf_main.ps

2013-08-05 13:46:02 +0100
Ken Sharp <ken.sharp@artifex.com>
72b397ecb4f5be3fdbf6da4a90a306d259ec3e93

> PDF interpreter run .reusablestreamdecode in 'stopped' to handle errors
> Bug #694437 " Infinitely many warnings: **** File has unbalanced q/Q operators (too many Q's) ****"
> The infinite recursion is due to not updating the current file position, and
> rerunning the same code, which results in the same error.
> To handle this we wrap the exeuction of reusablestreamdecode in a 'stopped'
> context, so that we cna capture the error, and move the file pointer as
> required. The job still throws warnings, but the resulting PDF is the same
> as displayed by Acrobat with the original file.
> gs/Resource/Init/pdf_draw.ps

2013-08-02 22:26:09 +0100
Chris Liddell <chris.liddell@artifex.com>
dc77b50bdb6abe88446dc7cdb9d7bd77a90dbfea

> Bug 694502: reverse of dictomark for PDFs
> The order with which the key/value pairs in a <<>> (apparently) differs between
> Postscript and PDF. Postscript pushes the objects onto the stack, then pops
> them in pairs, so the order is reversed compared to the order they were
> encountered. PDF handles them in the order they were encountered.
> This is, of course, only a problem when there are duplicate keys.
> Thus in PS "<< /a 1 /a 2>>" the key "/a" ends up with the value "1". In PDF, "/a" gets
> the value "2".
> No cluster differences.
> gs/psi/int.mak
> gs/psi/zdict.c

2013-08-02 16:51:33 +0100
Ken Sharp <ken.sharp@artifex.com>
d22c7a5b454ca8e021eb6b71c87627bfb8546edb

> Improve use of stopped to guard against PDF interpreter exit
> Improvements to commit 946f63b5748a5a19c369a1d42e653c69cd57075e:
> 1) Add an error message so that the file does not silently fail to process.
> 2) Check PDFSTOPONERROR and do not run in a stopped context if this is set.
> gs/Resource/Init/pdf_main.ps

2013-08-02 15:13:18 +0100
Ken Sharp <ken.sharp@artifex.com>
946f63b5748a5a19c369a1d42e653c69cd57075e

> run PDF files totally in a stopped context to prevent interpreter exit on error
> What it sys on the tin..... Several recent bug reports cause the interpreter
> to exit if it provokes a PostScript error. Running the PDF file in a stopped
> context prevents that from happening.
> Bug #694472, but many others up to #694449 are affected similarly.
> gs/Resource/Init/pdf_main.ps

2013-08-02 11:15:09 +0100
Ken Sharp <ken.sharp@artifex.com>
709c87fb7837993cb96eaa508c66381c1696ebdf

> add extra error checking of the Trailer dictionary
> Bug #694474 the file is badly damaged, and Acrobat won't open it. The only
> problem from our perspective is that the error generated causes the
> interpreter to exit (because there is no Trailer dict). Added more checks
> before use to ensure we don't generate errors with missing (empty) trailer
> dictionaries.
> A number of other files no longer cause errors when run with the cluster.
> gs/Resource/Init/pdf_main.ps
> gs/Resource/Init/pdf_rbld.ps

2013-08-02 09:39:17 +0100
Ken Sharp <ken.sharp@artifex.com>
0c8150ab6b2b8ceaa17cc1b1933d523764ffe114

> Attempt to handle broken object definitions (garbage on stack)
> If we have certain kinds of broken object definitions we can end up with
> more than one object on the stack when we encounter an endobj (or a new
> object definition before encountering an endobj for the previous object).
> Previously we would throw an error and ignore the object (define it as null)
> now we attempt to recover by removing objects from the stack until we have
> a stack of the form 'n n object' where the 'n' represents an integer.
> The bug #694443 now runs to completion although the output is empty. Given
> how badly broken this file is I don't propose to do any more with it.
> gs/Resource/Init/pdf_base.ps

2013-07-31 15:09:47 +0100
Ken Sharp <ken.sharp@artifex.com>
2667fbaa1c6c5ba84acc04ccc5b7b97723c09ad1

> PDF interpreter - remove lower limit on PDF files, improve broken file handling
> At some time in the past we set a lower limit of 400 bytes for PDF files,
> regarding anything less as invalid. While this may or may not be true, it
> prevents us repairing broken files that small. Removed the limit.
> When repairing a broken xref, we attempt to use the last startxref to find
> the tgrailer dictionary. If the startxref is followed by anything other than
> an integer we should ignore it.
> These both arise from Bug #694443 "/undefined in xref". The bug is not fixed
> because the file exhibits still more faults.
> Expected differences:
> The files 694317_-_minimal.pdf, broken_EOF_object_overwrites_good_object,
> missing_endobj_swallows_following_obj and missing_page_tree.pdf no longer
> produce errors.
> gs/Resource/Init/pdf_main.ps
> gs/Resource/Init/pdf_rbld.ps

2013-07-31 07:41:57 +0100
Chris Liddell <chris.liddell@artifex.com>
91a5d41eb1fea65adb1110ffa2a3b769263b7635

> Bump version for pending release.
> No unexpected cluster differences
> gs/Resource/Init/gs_init.ps
> gs/base/version.mak

2013-08-21 14:15:15 +0100
Chris Liddell <chris.liddell@artifex.com>
952b06580b96045a6b052af9a1842d9f770ccd1b

> Update product string, dates and changelog for 9.09 release.
> gs/base/gscdef.c
> gs/base/version.mak
> gs/doc/API.htm
> gs/doc/C-style.htm
> gs/doc/Commprod.htm
> gs/doc/DLL.htm
> gs/doc/Deprecated.htm
> gs/doc/Details8.htm
> gs/doc/Details9.htm
> gs/doc/Develop.htm
> gs/doc/Devices.htm
> gs/doc/Drivers.htm
> gs/doc/Fonts.htm
> gs/doc/Helpers.htm
> gs/doc/History1.htm
> gs/doc/History2.htm
> gs/doc/History3.htm
> gs/doc/History4.htm
> gs/doc/History5.htm
> gs/doc/History6.htm
> gs/doc/History7.htm
> gs/doc/History8.htm
> gs/doc/History9.htm
> gs/doc/Install.htm
> gs/doc/Issues.htm
> gs/doc/Language.htm
> gs/doc/Lib.htm
> gs/doc/Make.htm
> gs/doc/News.htm
> gs/doc/Projects.htm
> gs/doc/Ps-style.htm
> gs/doc/Ps2epsi.htm
> gs/doc/Ps2pdf.htm
> gs/doc/Ps2ps2.htm
> gs/doc/Psfiles.htm
> gs/doc/Readme.htm
> gs/doc/Release.htm
> gs/doc/Source.htm
> gs/doc/Unix-lpr.htm
> gs/doc/Use.htm
> gs/doc/WhatIsGS.htm
> gs/doc/Xfonts.htm
> gs/doc/gs-vms.hlp
> gs/doc/thirdparty.htm
> gs/man/dvipdf.1
> gs/man/font2c.1
> gs/man/gs.1
> gs/man/gslp.1
> gs/man/gsnd.1
> gs/man/pdf2dsc.1
> gs/man/pdf2ps.1
> gs/man/pf2afm.1
> gs/man/pfbtopfa.1
> gs/man/printafm.1
> gs/man/ps2ascii.1
> gs/man/ps2epsi.1
> gs/man/ps2pdf.1
> gs/man/ps2pdfwr.1
> gs/man/ps2ps.1
> gs/man/wftopfa.1

2013-08-20 10:21:09 +0100
Chris Liddell <chris.liddell@artifex.com>
ba1dedf24849295e107df180a291eba99bb33531

> Ensure we don't overflow the filename buffer.
> No cluster differences.
> gs/base/gp_unifs.c

2013-08-20 10:23:02 +0100
Ken Sharp <ken.sharp@artifex.com>
36088d57f45958b3647b21f5ee3908377f113682

> Make the Windows implementation of filenameforall match the Unix version
> The Unix version of filenameforall starts in the current working directory
> when no directory is specified.
> When the pattern length exceeds the available string we should return a
> rangecheck error, not an empty string.
> When the filename exceeds the available string we should return a
> rangecheck error, not a truncated string.
> CLUSTER_UNTESTED
> gs/base/gp_ntfs.c

2013-08-19 15:06:12 +0100
Ken Sharp <ken.sharp@artifex.com>
167ca10abb0a90c4a28a381223afd6fb80347282

> Allow use of '\\' for filenameforall and friends on Windows
> The commit to allow recursive directory enumeration f13bfba removed the
> code which translated '\\' into '\', which could lead to incorrect filenames
> being returned.
> This fix restores that functionality, but we still think everyone would be
> better advised to use the PostScript '/' separator instead, which works as
> well as '\' does.
> CLUSTER_UNTESTED
> gs/base/gp_ntfs.c

2013-08-16 10:35:58 +0100
Chris Liddell <chris.liddell@artifex.com>
36c5b40dd44d7ef8de4aeba40c5d6c817882b594

> update docs, version numbers, dates and product string
> gs/Resource/Init/gs_init.ps
> gs/base/version.mak
> gs/doc/API.htm
> gs/doc/C-style.htm
> gs/doc/Commprod.htm
> gs/doc/DLL.htm
> gs/doc/Deprecated.htm
> gs/doc/Details8.htm
> gs/doc/Details9.htm
> gs/doc/Develop.htm
> gs/doc/Devices.htm
> gs/doc/Drivers.htm
> gs/doc/Fonts.htm
> gs/doc/Helpers.htm
> gs/doc/History1.htm
> gs/doc/History2.htm
> gs/doc/History3.htm
> gs/doc/History4.htm
> gs/doc/History5.htm
> gs/doc/History6.htm
> gs/doc/History7.htm
> gs/doc/History8.htm
> gs/doc/History9.htm
> gs/doc/Install.htm
> gs/doc/Issues.htm
> gs/doc/Language.htm
> gs/doc/Lib.htm
> gs/doc/Make.htm
> gs/doc/News.htm
> gs/doc/Projects.htm
> gs/doc/Ps-style.htm
> gs/doc/Ps2epsi.htm
> gs/doc/Ps2pdf.htm
> gs/doc/Ps2ps2.htm
> gs/doc/Psfiles.htm
> gs/doc/Readme.htm
> gs/doc/Release.htm
> gs/doc/Source.htm
> gs/doc/Unix-lpr.htm
> gs/doc/Use.htm
> gs/doc/WhatIsGS.htm
> gs/doc/Xfonts.htm
> gs/doc/gs-vms.hlp
> gs/doc/thirdparty.htm
> gs/man/dvipdf.1
> gs/man/font2c.1
> gs/man/gs.1
> gs/man/gslp.1
> gs/man/gsnd.1
> gs/man/pdf2dsc.1
> gs/man/pdf2ps.1
> gs/man/pf2afm.1
> gs/man/pfbtopfa.1
> gs/man/printafm.1
> gs/man/ps2ascii.1
> gs/man/ps2epsi.1
> gs/man/ps2pdf.1
> gs/man/ps2pdfwr.1
> gs/man/ps2ps.1
> gs/man/wftopfa.1

2013-08-16 10:26:47 +0100
Chris Liddell <chris.liddell@artifex.com>
e1c028424f6900412241c076f11f4d9f2409cdb0

> Set product string for release candidate 1
> gs/base/gscdef.c

2013-08-16 14:00:43 +0100
Ken Sharp <ken.sharp@artifex.com>
397abe5622f0a1a9963617fbf1509015563be6fc

> Address gp_wgetv not finding *any* environment variables unless compiled with GS_NO_UTF8
> The string being passed in as the 'name' was a regular 1 byte C char array.
> But _wgetenv expects to be given a wide character string to find and
> treats the argument as such. This mean environment variables never matched.
> This commit mimics the code for the registry variables, and converts the
> name to a wchar before passing to _wgetenv.
> CLUSTER_UNTESTED
> gs/base/gp_wgetv.c

2013-08-16 12:47:36 +0100
Chris Liddell <chris.liddell@artifex.com>
8b5a86bad386569f921d0322bf113fa82b3d4529

> Fix GS_NO_UTF8 build problem with gs_sprintf.
> CLUSTER_UNTESTED
> gs/base/gp_wgetv.c

2013-08-16 07:58:57 +0100
Ken Sharp <ken.sharp@artifex.com>
182beda4d5199210c4c796c8c501e6e4bb5aa2de

> PS Interpreter - yet more meddling with VM allocation and setpagedevice
> Bug #694525 "GSView 5.0 does not work with GPL Ghostscript 9.08"
> Rather horrifyingly GSView uses undocumented internal operations of
> Ghostscript. In this case the changes to VM allocation mode during setpagedevice
> were being circumvented.
> This commit changes the way we detect a setpagedevice during startup, previously
> we check that the dictionary contained one key called /.LockSafetyParams
> and if so assumed that this meant we were in startup, so we set the VM
> allocation mode to global for the benefit of Display PostScxript.
> GSView ended up triggering that test, which caused a VM allocation error.
> We now look for the key /.LockSafetyParamsGlobal instead. If this is present
> we set the VM allocation mode to global and *replace* the key with
> /.LockSafetyParams instead. This allows accurate detection of the startup
> condition.
> No differences expected, GSView 5 seems to work and the original bug still
> is fixed.
> gs/Resource/Init/gs_init.ps
> gs/Resource/Init/gs_setpd.ps

2013-08-15 12:23:23 +0100
Robin Watts <robin.watts@artifex.com>
dde6d480e632eefbe5ccd42bc52b456582514a2a

> Bug 694451: Solve problems with interpolated landscape images.
> The portrait image code accumulates pixels into scanlines, and then
> plots the whole scanline at once. The landscape image code follows
> this lead by accumulating pixels into 'scancolumns' and then plots
> the whole column at once.
> Unfortunately this accumulation for columns goes wrong in the case
> where we are working at < 8 bpp (as the transposition of rows to
> columns fails). This causes images with runs of identical pixels in
> to be 'squished' vertically.
> We work around this here in the < 8 bpp case by repeating the writes
> of each pixel so whole bytes are filled. This is suboptimal, but
> doing anything else is tricky with the macros the way they are.
> gs/base/gxiscale.c

2013-08-14 14:43:00 +0100
Chris Liddell <chris.liddell@artifex.com>
951be31dd84da8f355bfada103ce7e62d5e8c3b2

> Update release date for 9.08 release.
> gs/base/gscdef.c
> gs/base/version.mak
> gs/doc/API.htm
> gs/doc/C-style.htm
> gs/doc/Commprod.htm
> gs/doc/DLL.htm
> gs/doc/Deprecated.htm
> gs/doc/Details8.htm
> gs/doc/Details9.htm
> gs/doc/Develop.htm
> gs/doc/Devices.htm
> gs/doc/Drivers.htm
> gs/doc/Fonts.htm
> gs/doc/Helpers.htm
> gs/doc/History1.htm
> gs/doc/History2.htm
> gs/doc/History3.htm
> gs/doc/History4.htm
> gs/doc/History5.htm
> gs/doc/History6.htm
> gs/doc/History7.htm
> gs/doc/History8.htm
> gs/doc/History9.htm
> gs/doc/Install.htm
> gs/doc/Issues.htm
> gs/doc/Language.htm
> gs/doc/Lib.htm
> gs/doc/Make.htm
> gs/doc/News.htm
> gs/doc/Projects.htm
> gs/doc/Ps-style.htm
> gs/doc/Ps2epsi.htm
> gs/doc/Ps2pdf.htm
> gs/doc/Ps2ps2.htm
> gs/doc/Psfiles.htm
> gs/doc/Readme.htm
> gs/doc/Release.htm
> gs/doc/Source.htm
> gs/doc/Unix-lpr.htm
> gs/doc/Use.htm
> gs/doc/WhatIsGS.htm
> gs/doc/Xfonts.htm
> gs/doc/gs-vms.hlp
> gs/doc/thirdparty.htm
> gs/man/dvipdf.1
> gs/man/font2c.1
> gs/man/gs.1
> gs/man/gslp.1
> gs/man/gsnd.1
> gs/man/pdf2dsc.1
> gs/man/pdf2ps.1
> gs/man/pf2afm.1
> gs/man/pfbtopfa.1
> gs/man/printafm.1
> gs/man/ps2ascii.1
> gs/man/ps2epsi.1
> gs/man/ps2pdf.1
> gs/man/ps2pdfwr.1
> gs/man/ps2ps.1
> gs/man/wftopfa.1

2013-08-09 15:15:53 +0100
Chris Liddell <chris.liddell@artifex.com>
d3d413364f81c379754b7738c58bb7b74b7ed3c4

> Delete the ._.DS_Store .DS_Store files.....
> which cause problems decompressing release archives on OS X.
> gs/lcms2/Projects/mac/.DS_Store
> gs/lcms2/Projects/mac/._.DS_Store

2013-08-09 09:10:37 +0100
Chris Liddell <chris.liddell@artifex.com>
e656ce0949b0e8cb8bebc22c820b279b9c2eefa0

> Update news and history for 9.08 release.
> gs/doc/History9.htm
> gs/doc/News.htm

2013-08-08 14:53:48 +0100
Chris Liddell <chris.liddell@artifex.com>
80d7e88123fe9df85cdaeb345c133e3043ddda15

> Update version and product strings for release candidate.
> gs/base/version.mak
> gs/doc/API.htm
> gs/doc/C-style.htm
> gs/doc/Commprod.htm
> gs/doc/DLL.htm
> gs/doc/Deprecated.htm
> gs/doc/Details8.htm
> gs/doc/Details9.htm
> gs/doc/Develop.htm
> gs/doc/Devices.htm
> gs/doc/Drivers.htm
> gs/doc/Fonts.htm
> gs/doc/Helpers.htm
> gs/doc/History1.htm
> gs/doc/History2.htm
> gs/doc/History3.htm
> gs/doc/History4.htm
> gs/doc/History5.htm
> gs/doc/History6.htm
> gs/doc/History7.htm
> gs/doc/History8.htm
> gs/doc/History9.htm
> gs/doc/Install.htm
> gs/doc/Issues.htm
> gs/doc/Language.htm
> gs/doc/Lib.htm
> gs/doc/Make.htm
> gs/doc/News.htm
> gs/doc/Projects.htm
> gs/doc/Ps-style.htm
> gs/doc/Ps2epsi.htm
> gs/doc/Ps2pdf.htm
> gs/doc/Ps2ps2.htm
> gs/doc/Psfiles.htm
> gs/doc/Readme.htm
> gs/doc/Release.htm
> gs/doc/Source.htm
> gs/doc/Unix-lpr.htm
> gs/doc/Use.htm
> gs/doc/WhatIsGS.htm
> gs/doc/Xfonts.htm
> gs/doc/gs-vms.hlp
> gs/doc/thirdparty.htm
> gs/man/dvipdf.1
> gs/man/font2c.1
> gs/man/gs.1
> gs/man/gslp.1
> gs/man/gsnd.1
> gs/man/pdf2dsc.1
> gs/man/pdf2ps.1
> gs/man/pf2afm.1
> gs/man/pfbtopfa.1
> gs/man/printafm.1
> gs/man/ps2ascii.1
> gs/man/ps2epsi.1
> gs/man/ps2pdf.1
> gs/man/ps2pdfwr.1
> gs/man/ps2ps.1
> gs/man/wftopfa.1
> gs/psi/winint.mak

2013-07-31 07:45:02 +0100
Chris Liddell <chris.liddell@artifex.com>
b836761d02ca5829e9ff3f5a64437c3bf29b10db

> Change product string for release candidate.
> No unexpected cluster differences.
> gs/base/gscdef.c

2013-08-20 10:21:09 +0100
Chris Liddell <chris.liddell@artifex.com>
ba1dedf24849295e107df180a291eba99bb33531

> Ensure we don't overflow the filename buffer.
> No cluster differences.
> gs/base/gp_unifs.c

2013-08-20 10:23:02 +0100
Ken Sharp <ken.sharp@artifex.com>
36088d57f45958b3647b21f5ee3908377f113682

> Make the Windows implementation of filenameforall match the Unix version
> The Unix version of filenameforall starts in the current working directory
> when no directory is specified.
> When the pattern length exceeds the available string we should return a
> rangecheck error, not an empty string.
> When the filename exceeds the available string we should return a
> rangecheck error, not a truncated string.
> CLUSTER_UNTESTED
> gs/base/gp_ntfs.c

2013-08-19 15:06:12 +0100
Ken Sharp <ken.sharp@artifex.com>
167ca10abb0a90c4a28a381223afd6fb80347282

> Allow use of '\\' for filenameforall and friends on Windows
> The commit to allow recursive directory enumeration f13bfba removed the
> code which translated '\\' into '\', which could lead to incorrect filenames
> being returned.
> This fix restores that functionality, but we still think everyone would be
> better advised to use the PostScript '/' separator instead, which works as
> well as '\' does.
> CLUSTER_UNTESTED
> gs/base/gp_ntfs.c

2013-08-08 14:53:48 +0100
Chris Liddell <chris.liddell@artifex.com>
80d7e88123fe9df85cdaeb345c133e3043ddda15

> Update version and product strings for release candidate.
> gs/base/version.mak
> gs/doc/API.htm
> gs/doc/C-style.htm
> gs/doc/Commprod.htm
> gs/doc/DLL.htm
> gs/doc/Deprecated.htm
> gs/doc/Details8.htm
> gs/doc/Details9.htm
> gs/doc/Develop.htm
> gs/doc/Devices.htm
> gs/doc/Drivers.htm
> gs/doc/Fonts.htm
> gs/doc/Helpers.htm
> gs/doc/History1.htm
> gs/doc/History2.htm
> gs/doc/History3.htm
> gs/doc/History4.htm
> gs/doc/History5.htm
> gs/doc/History6.htm
> gs/doc/History7.htm
> gs/doc/History8.htm
> gs/doc/History9.htm
> gs/doc/Install.htm
> gs/doc/Issues.htm
> gs/doc/Language.htm
> gs/doc/Lib.htm
> gs/doc/Make.htm
> gs/doc/News.htm
> gs/doc/Projects.htm
> gs/doc/Ps-style.htm
> gs/doc/Ps2epsi.htm
> gs/doc/Ps2pdf.htm
> gs/doc/Ps2ps2.htm
> gs/doc/Psfiles.htm
> gs/doc/Readme.htm
> gs/doc/Release.htm
> gs/doc/Source.htm
> gs/doc/Unix-lpr.htm
> gs/doc/Use.htm
> gs/doc/WhatIsGS.htm
> gs/doc/Xfonts.htm
> gs/doc/gs-vms.hlp
> gs/doc/thirdparty.htm
> gs/man/dvipdf.1
> gs/man/font2c.1
> gs/man/gs.1
> gs/man/gslp.1
> gs/man/gsnd.1
> gs/man/pdf2dsc.1
> gs/man/pdf2ps.1
> gs/man/pf2afm.1
> gs/man/pfbtopfa.1
> gs/man/printafm.1
> gs/man/ps2ascii.1
> gs/man/ps2epsi.1
> gs/man/ps2pdf.1
> gs/man/ps2pdfwr.1
> gs/man/ps2ps.1
> gs/man/wftopfa.1
> gs/psi/winint.mak

2013-07-31 07:45:02 +0100
Chris Liddell <chris.liddell@artifex.com>
b836761d02ca5829e9ff3f5a64437c3bf29b10db

> Change product string for release candidate.
> No unexpected cluster differences.
> gs/base/gscdef.c

2013-07-31 07:38:05 +0100
Chris Liddell <chris.liddell@artifex.com>
5f71fefc4425c86e682a58c6f692f99978fafdb8

> Remove reference to cups/gstopxl from configure.ac
> No cluster differences
> gs/configure.ac

2013-07-30 17:53:00 +0100
Chris Liddell <chris.liddell@artifex.com>
2db3d0bc1d7bc9e223ac0bcf79c28c234eb906cd

> Tidy some MSVC build issues:
> Remove spurious explicit "/DDEBUG" directive when linking genarch.exe.
> Set debug options for "aux tools" when doing a debug build.
> Fix MSVC "clean" target to handle "aux" directory. We weren't deleting all
> the files.
> CLUSTER_UNTESTED
> gs/base/msvccmd.mak
> gs/base/msvclib.mak
> gs/base/msvctail.mak
> gs/base/winlib.mak

2013-07-30 20:40:22 +0200
Till Kamppeter <till.kamppeter@gmail.com>
1c22d3214dff6fedd7b8aaba092dd52eb3b415fd

> Merge branch 'master' of ghostscript.com:/home/git/ghostpdl

2013-07-30 11:48:07 -0600
Henry Stiles <henry.stiles@artifex.com>
216b2692178e1113ab7252bf700cd980f5939a89

> Fix 694434, fix incorrect parsing of corrupt file.
> Invalid PJL was not properly ignored upon parsing.
> pl/pjparse.c

2013-07-30 20:29:01 +0200
Till Kamppeter <till.kamppeter@gmail.com>
9304a21699a6c17579fae32f44f5c92a37c13e2d

> Moved CUPS filters gstoraster and gstopxl to cups-filters
> As Ghostscript's CUPS filters gstoraster and gstopxl need changes to
> allow PPD-less printing on IPP printers and these changes introduce
> a new dependency on the libcupsfilters library of the cups-filters
> project, we have moved these filters to cups-filters now.
> In addition, the pdftoraster filter for Poppler-based conversion
> of PDF input to CUPS Raster is also not part of Poppler but part
> of cups-filters. So we get a more symmetric distribution.
> Also maintenance of the filters will get easier this way, especially
> duplicate code can move into libcupsfilters.
> cups-filters is a free software package hosted by OpenPrinting and it
> contains all CUPS filters needed by CUPS under Linux and additional
> utilities for CUPS. The filters are not part of the CUPS project at
> Apple any more since CUPS 1.6.x.
> See
> http://www.linuxfoundation.org/collaborate/workgroups/openprinting/cups-filters
> gs/Makefile.in
> gs/configure.ac
> gs/cups/colord.c
> gs/cups/colord.h
> gs/cups/cups.mak
> gs/cups/gstopxl.in
> gs/cups/gstoraster.c
> gs/cups/gstoraster.convs
> gs/cups/pxlcolor.ppd
> gs/cups/pxlmono.ppd

2013-07-30 10:05:49 +0100
Chris Liddell <chris.liddell@artifex.com>
91d104f9800b8e8e655a5cc1895b626ad57e40e5

> Remove debug statement.....
> .....left in by mistake.
> CLUSTER_UNTESTED
> gs/psi/msvc.mak

2013-07-29 23:56:56 -0700
Michael Vrhel <michael.vrhel@artifex.com>
e736e0a6730ee7e047bfd1ad701055eec6dffe85

> Fix for Bug 694439. We were not checking the code when we had invalid proc
> During the creation of a DeviceN colorspace we were not following up with
> an error condition.
> gs/psi/zcolor.c

2013-07-29 13:34:17 -0700
Ray Johnston <ray.johnston@artifex.com>
5e303dc64dbe55a5ce42e766e5d6a9753a9d387d

> Fix Windows sscanf %p incompatibility with Trio sprintf.
> Windows is internally consistent, but writes %p as 8 or 16 hex chars
> and it's sscanf expects that format. Trio follows the linux style of
> %p which has a leading "0x" followed by the characters. Reading an
> address from a string is required for memfile_fopen and memfile_unlink
> which are changed to use gs_sscanf which is added to gssprintf.*
> gs/base/gssprintf.c
> gs/base/gssprintf.h
> gs/base/gxclmem.c
> gs/base/lib.mak

2013-07-29 13:28:09 -0700
Ray Johnston <ray.johnston@artifex.com>
51309bce92631066e36f117a2e012e05877d6b76

> Remove unused local declaration of a dev_spec_op.
> gs/devices/gdevplib.c

2013-07-17 14:29:28 +0100
Chris Liddell <chris.liddell@artifex.com>
ebc7505be6340baa73b9c281ef6c593305be3aac

> Changes to allow building gs for WinRT/ARM
> The contents of the windows-arm-msvc.h file may need modified.
> No cluster differences.
> gs/arch/windows-arm-msvc.h
> gs/base/lib.mak
> gs/base/msvccmd.mak
> gs/base/msvctail.mak
> gs/base/winlib.mak
> gs/base/winplat.mak
> gs/base/winrtsup.cpp
> gs/ghostscript_rt.vcxproj
> gs/openjpeg/libopenjpeg/opj_includes.h
> gs/psi/gsdllARM32metro.def
> gs/psi/msvc.mak

2013-07-25 18:44:48 +0100
Robin Watts <robin.watts@artifex.com>
eddf4893e0e31b1801298eca37d68cd308408283

> Push optimisations back into lcms2.
> They don't work as well as a plugin factory. I am discussing why this
> is the case with Marti.
> gs/base/gsicc_lcms2.c
> gs/base/lcms2.mak
> gs/base/lib.mak
> gs/ghostscript.vcproj
> gs/lcms2/include/lcms2_extras.h
> gs/lcms2/src/cmsxform.c
> gs/lcms2/src/extra_xforms.c

2013-07-25 18:30:06 +0100
Robin Watts <robin.watts@artifex.com>
2c2bae08a0a4ec697e95f1732db1246a9fd3401a

> Enable our optimisations for lcms2 as a transform factory.
> Not all enabled as there seem to be some problems. Talking to
> Marti about this now.
> gs/base/gsicc_lcms2.c
> gs/base/lib.mak
> gs/lcms2/src/extra_xform.h
> gs/lcms2/src/extra_xforms.c

2013-07-25 11:27:20 +0100
Ken Sharp <ken.sharp@artifex.com>
6ddaa1b971f4d6f96bd57d82484399df82035d9a

> pdfwrite - new colour code
> We were not using the converted colours for certain spaces, because we were
> modifying the 'paint' values, instead of the drawing colour values.
> gs/devices/vector/gdevpdfg.c

2013-07-18 15:03:56 +0100
Robin Watts <robin.watts@artifex.com>
b1e63d6e5776c700bf01cb5c1038e8f0b57d29ca

> Import LCMS 2.5
> Move our optimisations out into an 'extras' plugin, disabled for now.
> gs/base/gsicc_lcms2.c
> gs/base/lcms2.mak
> gs/ghostscript.vcproj
> gs/lcms2/AUTHORS
> gs/lcms2/ChangeLog
> gs/lcms2/Makefile.am
> gs/lcms2/Makefile.in
> gs/lcms2/NEWS
> gs/lcms2/Projects/.gitignore
> gs/lcms2/Projects/VC2010/jpegicc/jpegicc.vcxproj
> gs/lcms2/Projects/VC2010/lcms2.rc
> gs/lcms2/Projects/VC2010/lcms2.sln
> gs/lcms2/Projects/VC2010/lcms2_DLL/lcms2_DLL.vcxproj
> gs/lcms2/Projects/VC2010/lcms2_static/lcms2_static.vcxproj
> gs/lcms2/Projects/VC2010/linkicc/linkicc.vcxproj
> gs/lcms2/Projects/VC2010/psicc/psicc.vcxproj
> gs/lcms2/Projects/VC2010/testbed/testbed.vcxproj
> gs/lcms2/Projects/VC2010/tiffdiff/tiffdiff.vcxproj
> gs/lcms2/Projects/VC2010/tifficc/tifficc.vcxproj
> gs/lcms2/Projects/VC2010/transicc/transicc.vcxproj
> gs/lcms2/aclocal.m4
> gs/lcms2/configure
> gs/lcms2/configure.ac
> gs/lcms2/doc/LittleCMS2.4 API.pdf
> gs/lcms2/doc/LittleCMS2.4 Plugin API.pdf
> gs/lcms2/doc/LittleCMS2.4 tutorial.pdf
> gs/lcms2/doc/LittleCMS2.5 API.pdf
> gs/lcms2/doc/LittleCMS2.5 Plugin API.pdf
> gs/lcms2/doc/LittleCMS2.5 tutorial.pdf
> gs/lcms2/include/Makefile.in
> gs/lcms2/include/lcms2.h
> gs/lcms2/include/lcms2_extras.h
> gs/lcms2/src/Makefile.in
> gs/lcms2/src/cmscam02.c
> gs/lcms2/src/cmscgats.c
> gs/lcms2/src/cmscnvrt.c
> gs/lcms2/src/cmserr.c
> gs/lcms2/src/cmsgamma.c
> gs/lcms2/src/cmsgmt.c
> gs/lcms2/src/cmsintrp.c
> gs/lcms2/src/cmsio0.c
> gs/lcms2/src/cmsio1.c
> gs/lcms2/src/cmslut.c
> gs/lcms2/src/cmsmd5.c
> gs/lcms2/src/cmsmtrx.c
> gs/lcms2/src/cmsnamed.c
> gs/lcms2/src/cmsopt.c
> gs/lcms2/src/cmspack.c
> gs/lcms2/src/cmspcs.c
> gs/lcms2/src/cmsplugin.c
> gs/lcms2/src/cmsps2.c
> gs/lcms2/src/cmssamp.c
> gs/lcms2/src/cmssm.c
> gs/lcms2/src/cmstypes.c
> gs/lcms2/src/cmsvirt.c
> gs/lcms2/src/cmswtpnt.c
> gs/lcms2/src/cmsxform.c
> gs/lcms2/src/cmsxform.h
> gs/lcms2/src/cmsxform_extras.c
> gs/lcms2/src/extra_xform.h
> gs/lcms2/src/extra_xforms.c
> gs/lcms2/src/lcms2.def
> gs/lcms2/src/lcms2_internal.h
> gs/lcms2/testbed/Makefile.in
> gs/lcms2/testbed/testcms2.c
> gs/lcms2/utils/common/vprf.c
> gs/lcms2/utils/jpgicc/Makefile.in
> gs/lcms2/utils/jpgicc/jpgicc.c
> gs/lcms2/utils/linkicc/Makefile.in
> gs/lcms2/utils/linkicc/linkicc.c
> gs/lcms2/utils/psicc/Makefile.in
> gs/lcms2/utils/psicc/psicc.c
> gs/lcms2/utils/tificc/Makefile.in
> gs/lcms2/utils/tificc/tificc.c
> gs/lcms2/utils/transicc/Makefile.in
> gs/lcms2/utils/transicc/transicc.c

2013-07-24 13:35:45 +0100
Ken Sharp <ken.sharp@artifex.com>
25a2563e775d849c17885305a4e459a328c2761b

> pdfwrite - new colour code, handle 'RGB' same as sRGB for allowed spaces
> We were trying to write Shading dictionaries with invalid colour spaces,
> this way we degenerate to rectangles which is ugly but works.
> gs/devices/vector/gdevpdfg.c

2013-07-23 09:45:02 -0700
Ray Johnston <ray.johnston@artifex.com>
a8384d57fad56058d494616ba196401542a540bc

> Fix bug 694423. Segfault in clist image writing at some resolutions.
> There was an incorrect check for past the end of the page (obo).
> gs/base/gxclimag.c

2013-07-23 14:02:41 +0100
Ken Sharp <ken.sharp@artifex.com>
af38eee8f23f51f74e67cc52d2b72e2dd365bace

> pdfwrite - new colour code
> Concretize_color doesn't work the way I thought it did. Instead of returning
> components in the original base space, it returns components for the current
> ProcessColorModel, this has resulted in the removal of several steps.
> Modified the code which writes converted base spaces for Separation and
> DeviceN spaces, so that the space can be used for images, as well as for
> linework.
> The code is now no longer crashes when the ColorConversionStrategy is
> CMYK.
> There are still some oddities with CIE/RGB to CMYK conversion, there are
> some problems with CMYK output with type 4 images. Still need to test
> Gray and RGB strategies, and redo LeaveColorUnchanged and UseDeviceIndependentCOlor
> with the latest changes.
> gs/devices/vector/gdevpdfg.c
> gs/devices/vector/gdevpdfg.h
> gs/devices/vector/gdevpdfi.c

2013-07-22 16:38:22 +0100
Ken Sharp <ken.sharp@artifex.com>
c0d9447b67dcef12d9d321a128985ee77e46fabd

> pdfwrite - new colour conversion code, fix Indexed Separation/DeviceN
> The previous code for converting the base space of a Separation or DeviceN
> space didn't cater for the possibility of a /Indexed space. This code now
> does.
> In addition we do a better job of identifying when a base space needs
> converted, there was similar problem here leading to us converting (eg)
> CMYK to CMYK.
> There are some oddities with RGB->CMYK conversion that I need to discuss
> with Michael.
> gs/devices/vector/gdevpdfc.c
> gs/devices/vector/gdevpdfg.c
> gs/devices/vector/gdevpdfg.h

2013-07-19 13:22:55 -0700
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
9b1a5d0dce3a375ccd4be010d50b3d91929bb982

> Fixed a couple of errors in previous commit.
> gs/base/gscie.c
> gs/base/gxhintn.c

2013-07-19 13:10:48 -0700
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
37aca23d758c3b5cb53da10aaeccd623f625e01a

> Remove C++ style comments.
> These cause issues with some versions of the AIX C compiler.
> gs/base/gscdevn.c
> gs/base/gscie.c
> gs/base/gxhintn.c
> gs/base/sjbig2.c
> gs/base/sjpx_openjpeg.c

2013-07-18 09:10:54 -0400
James Cloos <cloos@jhcloos.com>
7f764e594f2f23bac77748693d1c8e886af5b103

> Remove MaxBufferedTotal, MaxBufferedArea and MaxBufferedCount
> If MaxBitmap is set but MaxBufferedTotal and/or MaxBufferedArea are too small
> some documents will fail to display.
> X servers and client boxen have much more ram than they did 10–20 years ago;
> limiting the size of client-side caches beyond what MaxBitmap supports has
> little remaining value.
> So deprecate and remove those limits.
> Signed-off-by: Henry Stiles henry.stiles@artifex.com
> gs/devices/gdevx.c
> gs/devices/gdevx.h
> gs/devices/gdevxini.c
> gs/doc/Use.htm

2013-07-17 21:43:23 +0100
Chris Liddell <chris.liddell@artifex.com>
11dca09b381cac3a85625d7a408ccdf7458b1f9e

> Bug 694421: use correct .notdef in CIDType 2 fonts
> When cmap table is too short for the CID we're looking for, use the CharStrings
> dictionary to get the GID of the .notdef glyph instead of throwing an error.
> No cluster differences.
> gs/psi/zfapi.c

2013-07-15 23:17:44 +0000
Hin-Tak Leung <hintak@ghostscript.com>
94196ed84e5b8d264522b378972472ad4b54ed90

> Silent a "Value not read" compiler warning.
> It is true that the value is no longer used after this point,
> therefore no need to update further. Though it might be
> confusing if its value for its intended meaning is used
> again in the future, say, to detect broken input files.
> Comment it out for now.
> pxl/pxvendor.c

2013-07-15 14:37:10 -0600
Henry Stiles <henry.stiles@artifex.com>
777307f9e2aa4c2d74e96dd9c3f1630677c680a6

> Fix 694416, the default DCT color transform was not set up correctly.
> The fix was derived directly from MuPDF and is consistent with the
> documentation.
> gs/base/sdctd.c

2013-07-13 12:27:55 +0100
Chris Liddell <chris.liddell@artifex.com>
9834a3b011070a5565b5dcc536f6c2eace10569c

> Changes to allow mingw DLL build
> Building the mingw DLL still uses the "so" target.
> Also, tidy up and rationalise the way the "so" target works on OS X. It no
> longer relies on a special subtarget.
> No cluster differences.
> gs/Makefile.in
> gs/base/unix-dll.mak
> gs/base/unixhead.mak
> gs/configure.ac

2013-07-14 23:30:50 +0000
Hin-Tak Leung <hintak@ghostscript.com>
37b9962406c99564f6ac16e37540a45cfae5d557

> Bug 693661 - implement HP CLJ 3500/3550/3600 emulation
> The actual subject of the bug report is
> "pcl6 interpreter exited with error code -995".
> This patch adds two new files, pxl/pxvendor.{c,h} which implement
> HP CLJ 3500/3550/3600 emulation, plus small associated changes
> in existing files.
> Included and somewhat less related are:
> - a small change of pl/plmain.c to not repeat repeated error messages,
> - switching some 12-year-old debug code from '|' (experimental)
> to '|' (interpreter), to make genuine exp code devel easier.
> - a minor bug fix to px_attribute_names in
> pxl/pxptable.c reported elsewhere which affects debug messages,
> - some stubs in pxl/pxsessio.c and tools/pxldis.py
> for HP 1011/1012/1015 emulation.
> Where/what those are should be fairly obvious.
> No cluster differences.
> gs/base/gdevpxat.h
> gs/base/gdevpxen.h
> pl/plmain.c
> pxl/pxl.mak
> pxl/pxptable.c
> pxl/pxsessio.c
> pxl/pxstate.h
> pxl/pxvendor.c
> pxl/pxvendor.h
> tools/pxldis.py

2013-07-12 12:56:50 +0100
Ken Sharp <ken.sharp@artifex.com>
f3fdc7a37f529f0562a4290d3fce4cced2cd4820

> PDF interpreter - set colour nad space at the time the relevant operators execute
> In the past we have only set the colour space and colour values for stroke
> and fill when we actually perform a stroke or fill operation. At the time
> the space and colour was set we would simply store the data.
> This can cause problems with a sequence like this:
> /CS0 cs 0.2 0.1 0 0 scn
> q
> ....
> f
> Q
> q
> ....
> f
> Q
> Each time we set the colour and space we then restore back to a point
> before that space was set. On the next fill we need to set the space again.
> If the colour space is an expensive one to set (eg ICCBased) then we waste
> a lot of time.
> The 'simple' solution is to set the colour space at the time it is set in
> the PDF file. However, this also meant setting the colour values at the
> time they are set (or we could get space and colour unsynchronised). This
> further led to the discovery that the transparency code can set colours in
> a different space to the saved space (eg for an SMask). So it was necessary
> to have an additional set of routines, one which simply stores the state
> and one which stores and sets it to be the current space/colour.
> The time taken for the specimen file is reduced from approximately 4.5
> minutes to around 3.5 seconds. In addition the file CATX1101.pdf shows a
> progression with pdfwrite (gray drop shadow was missing). Because pdfwrite
> no longer swaps colour spaces so frequently with text, text is more often
> emitted as a single operation, which leads to smaller files (15% smaller
> in one case) but does show some very minor (1 pixel) positioning changes
> in text.
> gs/Resource/Init/pdf_draw.ps
> gs/Resource/Init/pdf_ops.ps

2013-06-11 22:49:05 +0200
zeniko <zeniko@gmail.com>
c15166f8be1e1081e5b2beecf46b25f1cbd14d5f

> Bug 694125: prevent heap underflow
> jbig2_decode_mmr_line checks the arguments to jbig2_set_bits since the
> fixes to issue 693050, however these checks still allow for the starting
> index to be negative which results in a write underflow; fixes
> 2860.pdf.asan.9.2069
> gs/jbig2dec/jbig2_mmr.c

2013-07-11 08:39:34 +0100
Chris Liddell <chris.liddell@artifex.com>
076ffc56da93051fb14930394b2026e1821f3cb7

> Bugs 693828: pull in new URW+ GPL fonts.
> Also 693827, 688557, 691909, 690896 and 687297.
> Many differences: most files that use the standard font set change. Changes of
> note are that in Nimbus L Sans Italic several of the "symbol" glyphs (like
> /plus, /plusminus etc) used to be italicised and are now not. This actually
> matches the Adobe equivalent font.
> Also there are some cases of the /M glyph being narrower than previously, again
> this is correct wrt to the Adobe equivalent.
> gs/Resource/Font/CenturySchL-Bold
> gs/Resource/Font/CenturySchL-BoldItal
> gs/Resource/Font/CenturySchL-Ital
> gs/Resource/Font/CenturySchL-Roma
> gs/Resource/Font/Dingbats
> gs/Resource/Font/NimbusMonL-Bold
> gs/Resource/Font/NimbusMonL-BoldObli
> gs/Resource/Font/NimbusMonL-Regu
> gs/Resource/Font/NimbusMonL-ReguObli
> gs/Resource/Font/NimbusRomNo9L-Medi
> gs/Resource/Font/NimbusRomNo9L-MediItal
> gs/Resource/Font/NimbusRomNo9L-Regu
> gs/Resource/Font/NimbusRomNo9L-ReguItal
> gs/Resource/Font/NimbusSanL-Bold
> gs/Resource/Font/NimbusSanL-BoldCond
> gs/Resource/Font/NimbusSanL-BoldCondItal
> gs/Resource/Font/NimbusSanL-BoldItal
> gs/Resource/Font/NimbusSanL-Regu
> gs/Resource/Font/NimbusSanL-ReguCond
> gs/Resource/Font/NimbusSanL-ReguCondItal
> gs/Resource/Font/NimbusSanL-ReguItal
> gs/Resource/Font/StandardSymL
> gs/Resource/Font/URWBookmanL-DemiBold
> gs/Resource/Font/URWBookmanL-DemiBoldItal
> gs/Resource/Font/URWBookmanL-Ligh
> gs/Resource/Font/URWBookmanL-LighItal
> gs/Resource/Font/URWChanceryL-MediItal
> gs/Resource/Font/URWGothicL-Book
> gs/Resource/Font/URWGothicL-BookObli
> gs/Resource/Font/URWGothicL-Demi
> gs/Resource/Font/URWGothicL-DemiObli
> gs/Resource/Font/URWPalladioL-Bold
> gs/Resource/Font/URWPalladioL-BoldItal
> gs/Resource/Font/URWPalladioL-Ital
> gs/Resource/Font/URWPalladioL-Roma

2013-07-11 08:33:35 +0100
Chris Liddell <chris.liddell@artifex.com>
283427799129175b4b6338e718aca0c26d917a54

> Make W/W* "context" survive text operations.
> If we have a text operation between a W/W* operator and the path operation that
> ends the W/W* context, we end up entering an infinite loop because the W/W*
> context prevents us from writing the changes to the graphics state required
> to render the text.
> To handle this, we now end the W/W* context, and store the dictionary
> temporarily while we complete the text operation, then restore W/W* context
> after.
> It is not clear how this is supposed to interact with the clipping text
> rendering modes, but on the basis of solving an infinite loop, I'm committing
> this, and will address issues if they arise.
> No cluster differences.
> gs/Resource/Init/pdf_ops.ps

2013-07-09 10:58:01 +0100
Ken Sharp <ken.sharp@artifex.com>
0903afb23777cfee2cb2a5015990c174e6a54742

> pdfwrite - Fix image writing code when converting colour spaces (old CMS code)
> Bug #694401 "pdfwrite produces incorrect pdf file"
> The command line for this bug specifies -dPDFSETTINGS=/ebook. This sets a
> number of parameters, specifically it sets ColorConversionStrategy to sRGB.
> The input file contains an image in DeviceGray with 1 bit per component,
> the specified colour conversion strategy means we convert this to RGB.
> The original image was drawn with a resolution of 200 dpi, which does not
> trigger monochrome downsampling in this setup (300 dpi). However when
> converted into a colour image it does trigger downsampling as the threshold
> for colour images is 72 dpi in this configuration.
> The combination of colour conversion and image downsampling seriously
> confused the horrific code in pdfwrite, and led to use writing out the wrong
> amount of data for the image as well as corrupting the image data as it
> passed through the filters.
> This patch sorts this out by setting various parameters, and copying/restoring
> them as required to initialise the various filters correctly.
> For some reason this shows a difference with test file Bug691425.pdf but the
> visual appeaance is the same.
> gs/devices/vector/gdevpdfi.c

2013-07-09 07:54:37 +0100
Ken Sharp <ken.sharp@artifex.com>
a9f3d46240cda455d8f42feee2350f40fa26e3e7

> Fix a benign compiler warning
> Check a return code and take appropriate action, this was a pre-existing
> fault flagged up when the code changed with the prior commit.
> gs/devices/vector/gdevpdtt.c

2013-07-08 08:09:12 -0600
Henry Stiles <henry.stiles@artifex.com>
8accdfa6986e7247103e80b7c12dd6b39ddf8a4c

> Remove code supporting obsolete color spaces.
> pcl/pccid.c

2013-07-06 21:05:06 -0600
Henry Stiles <henry.stiles@artifex.com>
392041413cb1d11dff0af986b41f871c19287f56

> Remove Java based PCL viewer and its supporting code.
> pcl/pcpage.c
> pl/pjparse.c
> pl/plmain.c
> pl/plmain.h
> tools/viewer/Gpickle.java
> tools/viewer/GpickleObserver.java
> tools/viewer/GpickleThread.java
> tools/viewer/Gview.java
> tools/viewer/JavaDoc/allclasses-frame.html
> tools/viewer/JavaDoc/deprecated-list.html
> tools/viewer/JavaDoc/gpickle.html
> tools/viewer/JavaDoc/gpickleobserver.html
> tools/viewer/JavaDoc/gpicklethread.html
> tools/viewer/JavaDoc/gview.html
> tools/viewer/JavaDoc/help-doc.html
> tools/viewer/JavaDoc/index-all.html
> tools/viewer/JavaDoc/index.html
> tools/viewer/JavaDoc/nav.html
> tools/viewer/JavaDoc/overview-tree.html
> tools/viewer/JavaDoc/package-frame.html
> tools/viewer/JavaDoc/package-list
> tools/viewer/JavaDoc/package-summary.html
> tools/viewer/JavaDoc/package-tree.html
> tools/viewer/JavaDoc/packages.html
> tools/viewer/JavaDoc/serialized-form.html
> tools/viewer/JavaDoc/stylesheet.css
> tools/viewer/Nav.java
> tools/viewer/README

2013-07-06 21:04:35 -0600
Henry Stiles <henry.stiles@artifex.com>
2035b67856e69b75c5466d44fd287f1d0cd721b3

> Debug statement to indicate implicit raster exit.
> pcl/rtgmode.c

2013-07-05 09:07:05 +0100
Ken Sharp <ken.sharp@artifex.com>
34e2ae40bff4d288da83dcd739e50287bf7c3c2e

> pdfwrite - implement idioms for PScript 5 artificial bld text
> Bug #688007 "cjk bold fonts printed many times"
> The artifical emboldening of fonts in the pscript 5 DLL works by drawing
> the same text 4 times in slightly different positions. THis causes
> pdfwrite to emit 4 sets of text.
> Here we implement idiomns for the range of 'show' operations valid in
> Pscript5, and if the device supports text rendering modes we draw the text
> only once in text rednering mode 2 (fill and then stroke). The Pscript5
> code uses 'sBdx' to determine the offset of the text, but this is actually
> a constant derived by dividing the target print resolution by 300. We use
> a fixed figure derived heuristically instead.
> During the work it became apparent that the existing code in pdfwrite to
> handle stroked text didn't work properly as it could emit stroke
> parameters during the course of a text object, which Acrobat ignores. SO
> the code has been altered to exit the text object whenever text is
> stroked. This is inefficient as we might not need to emit any stroke
> parameters, but it solves the problem, and text rendering modes are not
> widely used.
> This shows a small progression in pdf-t3-simple.pdf and some small
> differences in other files.
> gs/Resource/IdiomSet/Pscript5Idiom
> gs/devices/vector/gdevpdtt.c

2013-07-05 16:16:27 -0600
Henry Stiles <henry.stiles@artifex.com>
27332dab4d0b6ec7bab5cafef86a693c5d600dd7

> Partially address 694378 - mispositiosed graphics.
> Implement the GL Frame Advance (FR) technical extension with a simple
> page feed.
> pcl/pgconfig.c
> pcl/pgmand.h

2013-07-02 13:03:51 +0100
Chris Liddell <chris.liddell@artifex.com>
a8d0fa19f927d045b81ec0380ea7448de38176d9

> Disable OpenJPEG SSE on Windows again.
> Shelly reports that enabling SSE in Windows causes crashes in most of the
> JPX test jobs. At least for the present, disable it.
> CLUSTER_UNTESTED
> gs/psi/msvc.mak

2013-07-03 09:50:54 +0100
Ken Sharp <ken.sharp@artifex.com>
3123e3ad0299dbc1cefc77f342e5f23e7be28a71

> Fix a minor compiler warning in the previous commit
> gs/devices/vector/gdevpdfd.c

2013-07-03 09:05:16 +0100
Ken Sharp <ken.sharp@artifex.com>
489253b834075391d7826bc81ef52ede34f8289f

> pdfwrite - better identify rectangular clips, and emit as rectangles
> Bug #687931 "GS produces large PDF files"
> The file uses *many* rectangular clips to draw through, previously pdfwrite
> mostly emitted these as a sequence of lines, because only a small class of
> clip paths could be identified as rectangular.
> This commit levers the existing gx_path_is_rectangle to identify many more
> rectangular clip paths, and emit them using the 're' operator instead, which
> is more compact on output.
> The specimen file now produces 30% smaller PDF files.
> This does introduce some differences, in the main these are very small single
> pixel or one pixel wide lines. In the case of the Quality Logic test suite, the
> 'frame' for the tests is drawn through a clip, and one edge is now slightly
> wider, since it better matches the width of the other edges this is a
> progression. It affects a large number of QL tests.
> gs/base/gxcpath.c
> gs/base/gxpath.h
> gs/devices/vector/gdevpdfd.c

2013-07-02 10:31:48 +0100
Ken Sharp <ken.sharp@artifex.com>
939e32ff3c8841507aed80435269457f3caac6f5

> More work on setpagedevice and global allocation mode
> The commit 073f7be1671e7fa2dbbc75984e593d2279bb05d7 solved one problem,
> but introduced another. Specifically Ghostscript feiled to start when
> -dSAFER was specified.
> The reasons are convoluted, the background is as follows:
> Adobe interpreters appear to always return a local VM writeable dictionary
> from currentpagedevice (despite that fact that the spec clearly says its
> read-only). WordPerfect files have, in the past at least, relied upon this
> and tried to write to the dictionary.
> To solve this, our currentpagedevice copies child dictionaries to dictionaries
> allocated in local VM (and writeable). This fails if we attempt to do a
> setpagedevice while the VM allocation mode is local, because the parent
> dictionary is in global VM, and we then attempt to put locally allocated
> children in it.
> The earlier commit resolved this by forcing the VM allocation mode to local
> during the course of setpagedevice, which meant that the dictionary returned
> by currentpagedevice was allocated in local VM, so it was safe to put the
> child dictionaries in it.
> But, if we run with -dSAFER, the in gs_init.ps we do an early call to
> setpagedevice in order to set /.LockSafetyParams. We do this while the VM
> allocation mode is global. Note that setpagedevice stores a pointer to the
> returned dictionary in the graphics state. Now, when we run the Display
> PostScript startup code, it insists that all objects in the 'savedinitialgstate'
> must be in global VM. But we've saved the current page deice there, and it
> was allocated in local VM, which leads to an error.
> So in order to satisfy the WP bug, we need to have the children allocated in
> local VM. In order to call setpagedevice when the allocation mode is global
> we need to create the page device dict in local VM. In order to satisfy the
> DPS code, we need to allocate the page device dict in global VM.
> Oops.
> This commit attempts to work around this by setting the VM allocation mode
> to local for the course of setpagedevice, but *not* when we are executing
> the code for -dSAFER.
> This is a hacky solution, and I suspect prone to failure, but probably only
> if we change the startup code, which we rarely do.
> No diffrences expected
> gs/Resource/Init/gs_setpd.ps

2013-06-29 15:53:58 +0100
Ken Sharp <ken.sharp@artifex.com>
06d63d8edfd5d8eac76b96ea2e66f5cf165b6997

> Fix a typo in txtwrite, this may be related to bug #694389
> gs/devices/vector/gdevtxtw.c

2013-06-29 09:38:53 +0100
Ken Sharp <ken.sharp@artifex.com>
f560b73066ee787678a31973bca411bedc6ca0f6

> fix a minor compiler warning
> gs/psi/zdevice.c

2013-06-28 09:18:49 +0100
Ken Sharp <ken.sharp@artifex.com>
13105ccf9c02d29058ab0ff3f9bdb48387ec7b6e

> Invalidate device refs on the operand stack when we change device
> Bug #690925 "SEGV after "gsave nulldevice currentdevice grestore setdevice"
> currentdevice stores a reference containing a pointer to the current device
> structure on the operand stack. If we close the device, then attempt to do
> 'setdevice' using the stored pointer from the operand stack we can get a
> seg fault if we have restored away the device, because the device structure
> memory has been released.
> Altered nulldevice and setdevice so that when we change devices we scour
> the operand stack looking for saved references to devices. If we find any
> we NULL the pointer to the device. This allows us to check for a NULL device
> pointer in setdevice and raise an error instead of crashing.
> No differences expected.
> gs/psi/zdevice.c

2013-06-27 14:58:13 -0600
Henry Stiles <henry.stiles@artifex.com>
d5d3b85af33c679927e908154482fab576922fc0

> Fix bug #694355, incorrect rendering of raster image.
> This problem is very similar to bug #693111, and I don't think we have
> a clear handle on how the interpreter should behave when locked out
> commands are received in raster mode (with RTL). For this problem we
> don't shut down graphics when receiving the render algorithm command,
> the other bug involved a transparency command. A new bug will be
> opened to review both of these bugs. Although, both fixes are
> effective and safe, I'm afraid they don't address the underlying
> issue.
> pcl/pcpalet.c

2013-06-27 14:51:50 -0600
Henry Stiles <henry.stiles@artifex.com>
7b7cb6d314aab998d8b40e1ff782149aebbf06a2

> Reassign devices owned by Alex.
> doc/who_owns_what.txt

2013-06-27 15:41:49 +0100
Ken Sharp <ken.sharp@artifex.com>
1fc07e783d8758e4bfdc8b8ebe68a875b30568ae

> commit 9034712 used abs, which oddly caused many timeouts. Multiplying by
> -1 instead seems to solve this.....
> gs/base/gsptype1.c

2013-06-27 15:39:19 +0100
Ken Sharp <ken.sharp@artifex.com>
9034712f22eff916280f4555d88237da99bcaeda

> When clamping pattern BBox to page, make sure to scan in proper direction
> Bug #694385 "endless loop in pattern"
> The code for clamping the pattern BBox to the page starts left and below the
> page, and then scans across and up detecting if any part of the pattern is
> on the page.
> Unfortunately, this didn't account for negative xstep and ystep. Because
> we are only scanning the area, the easiest solution is just to abs() the
> values, so that we are sure to scan left-right and bottom-top.
> No differences expected.
> gs/base/gsptype1.c

2013-06-08 09:12:30 -0700
Michael Vrhel <michael.vrhel@artifex.com>
c27113ab96a8010b59652bde975eec68865aebb5

> Change in behavior for overprint. Fixes bugs 694295 694296 and 694067
> With this change we now do simulated overprinting of cmyk AND spot colorants
> for contone cmyk devices by default. If -dSimulateOverprint=false is specified we
> will not simulate overprinting of any colors.
> Also, cmyk simulation of spot colors with separation devices is not handled.
> i.e. if you specify -dSimulateOverprint=true -dMaxSpots=0 -sDEVICE=tiffsep1
> you will see the spot colors blended in CMYK space if overprint has been
> specified in the document.
> Note that not all overprint situations can be simulated accurately with this
> approach. For example, if I have a spot color that resulted in a CMYK value
> of 0 0 100 0 after the alternate tint transform and then I did an overprint with
> a CMYK value of 0 0 1 0, the color should still be a bright yellow but will actually
> be almost no color. The issue is that we can not distinguish this case from one
> where we had first laid down a CMYK of 0 0 100 0 followed by the overprint of 0 0 1 0
> which should be a light yellow. The documentation has been updated to point this out.
> I reviewed all the diffs that came up in the bmpcmp and reviewed the Ghent overprint
> files.
> gs/base/gscdevn.c
> gs/base/gscsepr.c
> gs/base/gsdparam.c
> gs/base/gsicc.c
> gs/base/gsicc_manage.c
> gs/base/gsovrc.c
> gs/base/gsstate.c
> gs/base/lib.mak
> gs/doc/Use.htm

2013-06-26 17:16:35 +0100
Ken Sharp <ken.sharp@artifex.com>
073f7be1671e7fa2dbbc75984e593d2279bb05d7

> Ensure all objects created for use during setpagdevice are in local VM
> Bug #687702 "gs8.15 setpagedevice /invalidaccess"
> The problem is caused by currentpagdevice returning a dictionary allocated
> in the current (global) VM. We later create an OutputAttributes dictionary
> which is in local VM, and store it in the dictionary returned. This fails
> of course.
> Since these objects are only used internally to construct various intermediate
> structures during the course of a setpagedevice, the easiest solution to this
> is to force the VM allocation mode to local for the duration of setpagedevice.
> No differences expected.
> gs/Resource/Init/gs_setpd.ps

2013-06-26 13:18:43 +0100
Chris Liddell <chris.liddell@artifex.com>
bcc1052afdec7b4da66c832c97bcba990a1863e0

> Bug #686853 "filenameforall enumerates incompatible with Adobe"
> Fix the Unix/Linux file enumeration code to correctly recurse into
> directories.
> This causes differences in many of the Quality Logic Postscript LL3 test suite
> tests because it can now overflow the size of the "scratch" string used in the
> tests and that results (correctly) in a rangecheck error from filenameforall.
> Obviously, that depends on from where in the directory hierarchy the executable
> is being run, and the contents of the directory structure below that.
> gs/base/gp_unifs.c

2013-06-24 15:20:03 +0100
Ken Sharp <ken.sharp@artifex.com>
f13bfba957c536630a241351df49c5007a0664d9

> rework the NTFS file enumeration to rescurse into sub-directories
> Bug #686853 "filenameforall enumerates incompatible with Adobe"
> Existing code did not recurse into sub-directories whereas Adobe interpreters
> do (but they do not list sub-directory names, just their contents).
> In addition the Linux and Windows code has long been incompatible, because
> the Linux code *does* list the sub-directory names, even though it doesn't
> recurse into them.
> With this patch the NTFS file system code now recurses and lists the
> sub-directory contents in the same fashion as Adobe.
> The Linux file system code needs work. After discussion with Chris we have
> decided not to proceed with the same work on VMS, OS/2 or DOS, as we don't
> even have systems to test the code compilation, let alone its execution.
> All these Operating Systems are obselete, and nobody ahs complained about
> the existing code in many years, so we don't expect to offer a bounty
> for adding this. However, if anyone has access to an appropriate system and
> wants to offer us a patch, we will probably adopt it.
> No differences expected, the cluster doesn't run NTFS.
> gs/base/gp_ntfs.c

2013-06-26 13:17:41 +0100
Ken Sharp <ken.sharp@artifex.com>
16733f6f179bcb98c371915a738b01a4e1f26ac2

> Add some Encodings listed in the PLRM
> Bug #688710 "Fix the Encoding resource category"
> As noted int he bug thread I so not consider it worthwhile to tackle some
> of the propsed work described there. However the CE Encoding is missing,
> as are also the ExpertEncoding and ExpertSubsetEncoding resources.
> This commit adds all three resources and the NotDefEncoding which is present
> in Adobe Acrobat Distiller. We also revisit the patch (gs-cvs rev
> 6834) originally committed against this bug, which prevented the Subversion
> source control directory being enumerated as an Encoding resource. Since we
> no longer use Subversion, and the current system doesn't rely on hidden
> sub-directories, this is no longer required.
> No differences expected
> gs/Resource/Encoding/CEEncoding
> gs/Resource/Encoding/ExpertEncoding
> gs/Resource/Encoding/ExpertSubsetEncoding
> gs/Resource/Encoding/NotDefEncoding
> gs/Resource/Init/gs_fntem.ps

2013-06-25 09:05:10 +0100
Hin-Tak Leung <hintak@ghostscript.com>
341dfa13b8ad4afadf8b2a8a7302422755911b36

> Bug 690692: more robust check for TTF/OTF files
> No cluster differences.
> gs/Resource/Init/gs_ttf.ps

2013-06-25 08:55:08 +0100
Chris Liddell <chris.liddell@artifex.com>
200dc18647ae24995e28607f838d77affbfc7638

> Set colors up correctly when rendering Type 3 glyph
> In the 'd1' operator, if the glyph metrics are clearly wrong, we fall back to
> rendering the glyph uncached. The original code failed to do the required
> color setup in this path through the code.
> The simplest solution, rather than repeat the same code, is to call the 'd0'
> operator, after appropriate stack manipulations.
> Noticed in passing working on an issue from customer 532.
> No cluster differences.
> gs/Resource/Init/pdf_font.ps

2013-06-20 13:24:01 -0700
Ray Johnston <ray.johnston@artifex.com>
10f6e526ec702fd8b74405d3e7461b428bdbdf31

> Fix wrong GrayDetection when images have MultipleDataSources true - cust 801.
> Since we already had a buffer, we unpack the samples from the planes into the
> buffer using 'spread' to space them so they form a chunky pixel buffer for
> row_has_color. Refactor the unpacking into the buffer out of row_has_color to
> the caller where we have the planes array. Note that the buffer returned from
> the 'unpack' proc may be the original data source so we save that for calling
> row_has_color.
> gs/base/gxclimag.c

2013-06-21 07:43:15 +0100
Chris Liddell <chris.liddell@artifex.com>
8ff1b883db9e7d2cd8c940a5ea7f0e4bad78903d

> Move winrt platform build into "base".
> One file required for the winrt platform was being built in psi/msvc.mak, this
> moves it to winlib.mak with the rest of the platform.
> CLUSTER_UNTESTED
> gs/base/winlib.mak
> gs/psi/msvc.mak

2013-06-19 19:10:21 +0100
Chris Liddell <chris.liddell@artifex.com>
b405fdcb395f2b48226af7a55a714d4dd3d50a75

> Define GS_NO_UTF8 for mingw
> Noticed in passing, GS_NO_UTF8 is needed for mingw.
> No cluster differences.
> gs/configure.ac

2013-06-19 18:14:13 +0100
Chris Liddell <chris.liddell@artifex.com>
14a88dcf3fb49d1fd31b0a6500e22c7d066a1185

> Enable SSE2 code in openJPEG on Windows.
> CLUSTER_UNTESTED
> gs/psi/msvc.mak

2013-06-19 17:04:31 +0100
Chris Liddell <chris.liddell@artifex.com>
10de1e0bf9f3abd9c74401258388067c6e2ec36f

> valgrind: fix invalid read error in png devices
> Noticed passing, several of the png devices left the downscale factor and
> min feature size entries in the device uninitialized.
> No cluster differences.
> gs/devices/gdevpng.c

2013-06-19 16:25:17 +0100
Chris Liddell <chris.liddell@artifex.com>
f1b0e276370fd632ac7e18c39cffe9972fe67444

> Bug 693934: CCITT Fax decode - cope with negative run length
> In various places in the fax decode code we coped with the run length being
> negative - in just a few we didn't.
> We'll now cope gracefully with negative run lengths in places.
> No cluster differences.
> gs/base/scfd.c

2013-06-19 16:29:42 +0200
Till Kamppeter <till.kamppeter@gmail.com>
b871884a283bbe8d908f47844ffff4cf6f009803

> White-space clean-up in gstoraster
> gs/cups/gstoraster.c

2013-06-19 15:26:12 +0200
Till Kamppeter <till.kamppeter@gmail.com>
1149c245e70fcf6b0445f0958a7c1bb972b26f63

> Fixed also the suppression of color management via colord in gstoraster
> See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712045.
> gs/cups/gstoraster.c

2013-06-19 14:52:25 +0200
Till Kamppeter <till.kamppeter@gmail.com>
1b87b820854525f9709f19f3bb932e4f75210637

> Make colord-supplied ICC profile getting applied by gstoraster
> Patches from Debian bug #712045:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712045
> Thanks to Alexey Galakhov for the bug report and the patches.
> gs/cups/gstoraster.c

2013-06-19 11:32:19 +0100
Ken Sharp <ken.sharp@artifex.com>
daceba62fcce274fc62e750ac186b3a9026554ad

> PDF interpreter - ignore invalid /DecodeParams for streams
> Bug #694353 "**** File has unbalanced q/Q operators (too many Q's) **** endless loop"
> The PDF file is invalid, it has a /Filters array with 2 elements, and a
> /DecodeParams array with 1 element. The DecodeParams array must have either
> the same number of elements as the Filters, or not be present (default).
> We now test the length of each array and ignore the DecodeParams if the lengths
> are not the same (as we have no way to know which Params relate to which Filter)
> No differences expected
> gs/Resource/Init/pdf_base.ps

2013-06-19 08:53:01 +0100
Chris Liddell <chris.liddell@artifex.com>
1c9ac1bc3caaad5d2ea9e277d1b89a5c56b31c5c

> Bug 694357: allow override of gcc's __SSE__ define
> OpenJPEG uses gcc's "built-in" preprocessor define of __SSE__ to determine
> whether to use its SSE2 code. As we have a configure option to disable SSE2
> use in Ghostscript, that option now also overrides the gcc define thus
> disabling SSE2 in OpenJPEG, too.
> This currently only works for gcc.
> No cluster differences.
> gs/configure.ac

2013-06-18 16:50:17 +0100
Chris Liddell <chris.liddell@artifex.com>
fea396d5d3202bf3c6b1207b5c8a17b979d0bb4f

> Bug 694318: remove reference to freed resource
> When we're about to free a PDF resource object in pdfwrite, make sure we remove
> references to it in the substream stack.
> No cluster differences
> gs/devices/vector/gdevpdf.c
> gs/devices/vector/gdevpdfu.c

2013-06-18 12:02:01 +0100
Ken Sharp <ken.sharp@artifex.com>
95cd6ab8bf3a8866a5a10571a0c034869a4ba064

> PDF interpreter - handle empty cref by rebuilding it.
> Bug #694342 "Error: /typecheck in --run-- reading PDF file"
> The PDF interpreter didn't notice that an empty xref (the xref token
> immediately followed by the trailer token) was not a valid xref. Later we
> would attempt to use the empty xref, and fail.
> We now check the length of 'Objects' when we find the trailer token and if
> it is 0 we throw an error. This causes the PDF itnerpreter to rebuild the
> xref table by rescanning the whole file.
> gs/Resource/Init/pdf_main.ps

2013-06-18 08:20:04 +0100
Chris Liddell <chris.liddell@artifex.com>
bd2887990301b12c2b11df323ee726855129a637

> Bug 694354: cope being unable to read a candidate font file
> On Unix, things like directories can be opened as "files". In the font code,
> we attempt to open a candidate font file, and if that fails, handle it. We
> then read some data from the file to validate it as a suitable font file. If
> the data we read reveals it to be an unsuitable file, we handle that.
> We were not handling the case where we could open the "file" but could not
> read from it.
> No cluster differences.
> gs/Resource/Init/gs_fonts.ps

2013-06-17 15:46:52 +0100
Chris Liddell <chris.liddell@artifex.com>
bd08091d295effb51de2cc7e739870e7b2628e38

> Bug 694319: "finalize" a font stream before return an error.
> pdfwrite and pswrite could, in the event of an error during font writing, leave
> the "stream" for the font in a) an invalid state, and b) in place for the
> continued writing of the output file.
> This caused memory corruption, seg fault etc.
> No cluster differences.
> gs/devices/vector/gdevpdtb.c

2013-06-17 13:01:43 +0200
Till Kamppeter <till.kamppeter@gmail.com>
489811e366495db7374f2cf3c71bd4a9bdf77360

> Prevent gstoraster from hanging on Ghostscript failure
> Thanks to Olivier Blin for this patch.
> Original discription in the bug report (bug 693336):
> When gs fails and the input file is bigger than the pipe capicity
> (65536 bytes on Linux), gstoraster will hang. In this case, write()
> will block because the pipe is full and no reader is emptying it. The
> gs child process becomes a zombie, and write() will not fail until its
> zombie is gone, which never happens with the current code.
> This patch fixes the issue by adding a child reaper, which will make
> write() fail when the child dies, either because of the SIGCHLD signal
> coming, or because of a broken pipe error in write().
> gs/cups/gstoraster.c

2013-06-17 08:52:37 +0100
Chris Liddell <chris.liddell@artifex.com>
579e9024d1bc358fe12bcceb00e1ba1797e473ec

> Bug 694319 (related): bounds checking T1 op stack
> Add some lower bounds checking for the operand stack, to one of the Type 1
> charstring interpreters used by pdf/ps2write.
> This fixes one of the memory corruption problems with Bug693711.pdf.
> No cluster differences.
> gs/base/gxtype1.c

2013-06-15 10:00:35 +0100
Ken Sharp <ken.sharp@artifex.com>
0c9e630460084182f0347570b38aa606a5a8a2e8

> pdfwrite - silence a Valgrind warning by initialising a variable
> The memory is uninitialised because the file provokes an error, and
> pdfwrite gets confused about which file it is supposed to be in, The net
> result is that an MD5 hash is not generated and we end up with some memory
> not being initialised.
> This simply sets the memory to 0 which silences Valgrind, it makes no
> attempt to improve the output.
> No differences expected.
> gs/devices/vector/gdevpdfe.c

2013-06-14 09:59:55 -0700
Ray Johnston <ray.johnston@artifex.com>
65744368052b127b596014d55a6ea776808a6640

> Fix gs_pdf14_device_color_mon_set and remove compiler warnings.
> The previous function only set the value to false, and this should
> set the value to the bool 'monitoring' that is the second arg.
> gs/base/gdevp14.c
> gs/base/gsicc_monitorcm.c

2013-06-14 11:04:31 +0100
Chris Liddell <chris.liddell@artifex.com>
cb2e0f784882696e930e5077ecb1a2feef76fadf

> Fix pointer confusion in gs_private_st_ptrs2_final()
> The order of the pointer arguments in one of the "sub-macros" used in the
> definition of gs_private_st_ptrs2_final() was wrong.
> No cluster differences.
> gs/base/gsstruct.h

2013-06-12 12:39:13 -0700
Ray Johnston <ray.johnston@artifex.com>
f75e1cf3d4f4e4e809e94efc29b4046fe07f00c5

> Fix Graydetection for pages after the first color page for cust 801.
> We need to restore pageneutralcolor if graydetection is true, but also
> we need to reestablish the monitoring color procedures, so we add a
> gsicc_mcm_begin_monitor for the purpose. We change the pdf14 device
> hook to allow the target device monitoring to be turned on or off.
> gs/base/gdevp14.c
> gs/base/gdevp14.h
> gs/base/gdevprn.c
> gs/base/gscms.h
> gs/base/gsdevice.c
> gs/base/gsicc_cache.c
> gs/base/gsicc_cms.h
> gs/base/gsicc_monitorcm.c
> gs/base/gsicc_nocm.c
> gs/base/gsicc_replacecm.c
> gs/devices/gdevpbm.c

2013-06-13 08:12:35 +0100
Chris Liddell <chris.liddell@artifex.com>
5dd1d9a83d41ea9d2542e435172ff4fa7c163828

> Bug 690639: change the order we do character mapping in TTFs
> Instead of combining the encoding from the PDF with the Adobe Glyph List to
> get a comprehensive list of glyph name mappings, then building a character
> code to GID mapping from that, and (potentially) using the TTF post table to
> fill in any gaps, we now build a mapping directly from the AGL, then (possibly)
> fill in any gaps from the TTF post table, and *finally* fill in any remaining
> gaps using the PDF's encoding.
> This handles a case where the contents of the TTF cmap table don't match the
> contents of the post table.
> No cluster differences.
> gs/Resource/Init/gs_ttf.ps

2013-06-11 18:51:18 +0100
Robin Watts <robin.watts@artifex.com>
e209e22862bd7af4362e08f1aa8f0025341356f0

> Add tiffscaled32 device (32bpp CMYK output with downscaling)
> Update documentation.
> gs/base/gxdownscale.c
> gs/base/macos-mcp.mak
> gs/base/openvms.mak
> gs/base/unix-gcc.mak
> gs/base/unixansi.mak
> gs/devices/devs.mak
> gs/devices/gdevtsep.c
> gs/doc/Devices.htm
> gs/psi/msvc.mak
> main/pcl6_gcc.mak
> main/pcl6_msvc.mak

2013-06-09 13:54:46 -0400
Chris Liddell <chris.liddell@artifex.com>
617143bb943a6540c751195c60b68387f2b06b88

> Bug 694270: (valgrind) initialize structure
> Initialize the Type 1 state structure before using it.
> No cluster differences.
> gs/devices/gxfcopy.c

2013-06-05 10:06:46 -0700
Michael Vrhel <michael.vrhel@artifex.com>
1cf483079386814249cfa831cfbe7491b59dc602

> Fix for bug 694293. We are improperly clipping to the soft mask bounding box.
> If the background alpha value for the softmask is something other than 0 we cannot
> clip to the soft mask bounding box as regions that are outside this area will be
> using the background alpha as their softmask value. Also, we were not accounting
> for the different size of the softmask when compositing. Progressions occurred in
> three test files with this fix in addition to fixing the customer file.
> gs/base/gdevp14.c
> gs/base/gxblend1.c

2013-05-16 14:52:31 +0100
Chris Liddell <chris.liddell@artifex.com>
61961d2828e427134f32a90f7477b4c91aae0c57

> Bug 694065: address libtiff issues with WinRT build
> The defaullt libtiff I/O functions use some methods proscribed in the WinRT world.
> Ghostscript does not rely on these defaults, supplying our own I/O hooks
> when we invoke libtiff.
> So, if we're building libtiff into GS (as in the default and preferred
> configuration), we leave out those default calls, and replace them with stubs
> to keep the linker happy. Currently, these are empty stubs, and apply to all
> builds, which may cause issues if anyone relies on linking to our built-in
> libtiff, and uses these calls. If that proves to be the case, we can easily
> fill-in the stubs with appropriate code, but working through the GS I/O
> calls.
> This also has the advantage that any port to a weird platform, we only
> need to port the Ghostscript I/O, and we don't have to worry about libtiff.
> If we're using a "shared" libtiff, these stubs are not included.
> Unfortunately, libtiff does not pass around a context to the memory
> management functions, so we currently still have no method of using the
> Ghostscript memory manager.
> Update to libpng 1.6.2
> libpng 1.6.x dispenses with one of the function calls (lstrlenA) not allowed
> in the WinRT build.
> The other (ExitProcess) we work around in the makefiles, replacing it
> with a simple "exit". This should never be a problem since we actually
> rely on setjmp/longjmp for libpng error handling, and libpng code checks
> for that option before it will get to the "exit" call.
> Re-enable TIFF and PNG devices for WinRT
> Rename 'PLATFORM' to 'GSPLATFORM'
> nmake (at least in VS2012) defines 'PLATFORM' for certain configurations
> which interfered with our use of it, so make it more Ghostscript-centric.
> No cluster differences.
> gs/base/gs.mak
> gs/base/gstiffio.c
> gs/base/gstiffio.h
> gs/base/macos-mcp.mak
> gs/base/msvclib.mak
> gs/base/openvms.mak
> gs/base/openvms.mmk
> gs/base/png.mak
> gs/base/tiff.mak
> gs/base/unixhead.mak
> gs/base/winlib.mak
> gs/configure.ac
> gs/devices/devs.mak
> gs/devices/gdevtfax.c
> gs/devices/gdevtfnx.c
> gs/devices/gdevtifs.c
> gs/devices/gdevtifs.h
> gs/devices/gdevtsep.c
> gs/libpng/ANNOUNCE
> gs/libpng/CHANGES
> gs/libpng/CMakeLists.txt
> gs/libpng/INSTALL
> gs/libpng/LICENSE
> gs/libpng/Makefile.am
> gs/libpng/Makefile.in
> gs/libpng/README
> gs/libpng/aclocal.m4
> gs/libpng/arm/arm_init.c
> gs/libpng/arm/filter_neon.S
> gs/libpng/autogen.sh
> gs/libpng/config.guess
> gs/libpng/config.h.in
> gs/libpng/config.sub
> gs/libpng/configure.ac
> gs/libpng/contrib/examples/README.txt
> gs/libpng/contrib/examples/iccfrompng.c
> gs/libpng/contrib/examples/pngpixel.c
> gs/libpng/contrib/examples/pngtopng.c
> gs/libpng/contrib/gregbook/Makefile.sgi
> gs/libpng/contrib/gregbook/Makefile.unx
> gs/libpng/contrib/gregbook/readpng.c
> gs/libpng/contrib/gregbook/readpng2.c
> gs/libpng/contrib/gregbook/writepng.c
> gs/libpng/contrib/libtests/fakepng.c
> gs/libpng/contrib/libtests/gentests.sh
> gs/libpng/contrib/libtests/makepng.c
> gs/libpng/contrib/libtests/pngstest.c
> gs/libpng/contrib/libtests/pngunknown.c
> gs/libpng/contrib/libtests/pngvalid.c
> gs/libpng/contrib/libtests/readpng.c
> gs/libpng/contrib/libtests/tarith.c
> gs/libpng/contrib/libtests/timepng.c
> gs/libpng/contrib/pngminim/README
> gs/libpng/contrib/pngminim/decoder/makefile
> gs/libpng/contrib/pngminim/decoder/pngusr.dfa
> gs/libpng/contrib/pngminim/decoder/pngusr.h
> gs/libpng/contrib/pngminim/encoder/README
> gs/libpng/contrib/pngminim/encoder/makefile
> gs/libpng/contrib/pngminim/encoder/pngusr.dfa
> gs/libpng/contrib/pngminim/encoder/pngusr.h
> gs/libpng/contrib/pngminim/preader/makefile
> gs/libpng/contrib/pngminim/preader/pngusr.dfa
> gs/libpng/contrib/pngminim/preader/pngusr.h
> gs/libpng/contrib/pngminus/makefile.std
> gs/libpng/contrib/pngminus/png2pnm.c
> gs/libpng/contrib/pngminus/pnm2png.c
> gs/libpng/contrib/pngsuite/README
> gs/libpng/contrib/pngsuite/ftbbn0g01.png
> gs/libpng/contrib/pngsuite/ftbbn0g02.png
> gs/libpng/contrib/pngsuite/ftbbn0g04.png
> gs/libpng/contrib/pngsuite/ftbbn1g04.png
> gs/libpng/contrib/pngsuite/ftbwn0g16.png
> gs/libpng/contrib/pngsuite/ftbwn1g16.png
> gs/libpng/contrib/pngsuite/ftp0n0g08.png
> gs/libpng/contrib/pngsuite/ftp0n1g08.png
> gs/libpng/contrib/tools/README.txt
> gs/libpng/contrib/tools/checksum-icc.c
> gs/libpng/contrib/tools/chkfmt
> gs/libpng/contrib/tools/cvtcolor.c
> gs/libpng/contrib/tools/fixitxt.c
> gs/libpng/contrib/tools/intgamma.sh
> gs/libpng/contrib/tools/makesRGB.c
> gs/libpng/contrib/tools/sRGB.h
> gs/libpng/contrib/visupng/PngFile.c
> gs/libpng/contrib/visupng/PngFile.h
> gs/libpng/contrib/visupng/VisualPng.c
> gs/libpng/depcomp
> gs/libpng/example.c
> gs/libpng/install-sh
> gs/libpng/libpng-config.in
> gs/libpng/libpng-manual.txt
> gs/libpng/libpng.3
> gs/libpng/libpngpf.3
> gs/libpng/ltmain.sh
> gs/libpng/missing
> gs/libpng/png.5
> gs/libpng/png.c
> gs/libpng/png.h
> gs/libpng/pngconf.h
> gs/libpng/pngerror.c
> gs/libpng/pngget.c
> gs/libpng/pnginfo.h
> gs/libpng/pngmem.c
> gs/libpng/pngpread.c
> gs/libpng/pngpriv.h
> gs/libpng/pngread.c
> gs/libpng/pngrio.c
> gs/libpng/pngrtran.c
> gs/libpng/pngrutil.c
> gs/libpng/pngset.c
> gs/libpng/pngstruct.h
> gs/libpng/pngtest.c
> gs/libpng/pngtest.png
> gs/libpng/pngtrans.c
> gs/libpng/pngwio.c
> gs/libpng/pngwrite.c
> gs/libpng/pngwtran.c
> gs/libpng/pngwutil.c
> gs/libpng/projects/owatcom/libpng.wpj
> gs/libpng/projects/owatcom/pngstest.tgt
> gs/libpng/projects/visualc71/README.txt
> gs/libpng/projects/visualc71/libpng.vcproj
> gs/libpng/projects/visualc71/pngtest.vcproj
> gs/libpng/projects/vstudio/WARNING
> gs/libpng/projects/vstudio/libpng/libpng.vcxproj
> gs/libpng/projects/vstudio/pnglibconf/pnglibconf.vcxproj
> gs/libpng/projects/vstudio/pngstest/pngstest.vcxproj
> gs/libpng/projects/vstudio/pngtest/pngtest.vcxproj
> gs/libpng/projects/vstudio/pngunknown/pngunknown.vcxproj
> gs/libpng/projects/vstudio/pngvalid/pngvalid.vcxproj
> gs/libpng/projects/vstudio/readme.txt
> gs/libpng/projects/vstudio/vstudio.sln
> gs/libpng/projects/vstudio/zlib.props
> gs/libpng/projects/vstudio/zlib/zlib.vcxproj
> gs/libpng/scripts/README.txt
> gs/libpng/scripts/checksym.awk
> gs/libpng/scripts/chkfmt
> gs/libpng/scripts/def.dfn
> gs/libpng/scripts/descrip.mms
> gs/libpng/scripts/dfn.awk
> gs/libpng/scripts/intprefix.dfn
> gs/libpng/scripts/libpng-config-head.in
> gs/libpng/scripts/libpng.pc.in
> gs/libpng/scripts/libtool.m4
> gs/libpng/scripts/ltoptions.m4
> gs/libpng/scripts/ltsugar.m4
> gs/libpng/scripts/ltversion.m4
> gs/libpng/scripts/lt~obsolete.m4
> gs/libpng/scripts/macro.lst
> gs/libpng/scripts/makefile.32sunu
> gs/libpng/scripts/makefile.64sunu
> gs/libpng/scripts/makefile.aix
> gs/libpng/scripts/makefile.bc32
> gs/libpng/scripts/makefile.beos
> gs/libpng/scripts/makefile.bor
> gs/libpng/scripts/makefile.cegcc
> gs/libpng/scripts/makefile.darwin
> gs/libpng/scripts/makefile.dec
> gs/libpng/scripts/makefile.dj2
> gs/libpng/scripts/makefile.elf
> gs/libpng/scripts/makefile.freebsd
> gs/libpng/scripts/makefile.gcc
> gs/libpng/scripts/makefile.hp64
> gs/libpng/scripts/makefile.hpgcc
> gs/libpng/scripts/makefile.hpux
> gs/libpng/scripts/makefile.ibmc
> gs/libpng/scripts/makefile.intel
> gs/libpng/scripts/makefile.knr
> gs/libpng/scripts/makefile.linux
> gs/libpng/scripts/makefile.mips
> gs/libpng/scripts/makefile.msc
> gs/libpng/scripts/makefile.msys
> gs/libpng/scripts/makefile.ne12bsd
> gs/libpng/scripts/makefile.netbsd
> gs/libpng/scripts/makefile.openbsd
> gs/libpng/scripts/makefile.sco
> gs/libpng/scripts/makefile.sggcc
> gs/libpng/scripts/makefile.sgi
> gs/libpng/scripts/makefile.so9
> gs/libpng/scripts/makefile.solaris
> gs/libpng/scripts/makefile.solaris-x86
> gs/libpng/scripts/makefile.std
> gs/libpng/scripts/makefile.sunos
> gs/libpng/scripts/makefile.tc3
> gs/libpng/scripts/makefile.vcwin32
> gs/libpng/scripts/makevms.com
> gs/libpng/scripts/options.awk
> gs/libpng/scripts/pnglibconf.dfa
> gs/libpng/scripts/pnglibconf.h.prebuilt
> gs/libpng/scripts/pnglibconf.mak
> gs/libpng/scripts/prefix.dfn
> gs/libpng/scripts/sym.dfn
> gs/libpng/scripts/symbols.def
> gs/libpng/scripts/symbols.dfn
> gs/libpng/scripts/vers.dfn
> gs/libpng/test-driver
> gs/libpng/test-pngtest.sh
> gs/libpng/test-pngvalid-full.sh
> gs/libpng/test-pngvalid-simple.sh
> gs/libpng/tests/pngstest
> gs/libpng/tests/pngstest-0g01
> gs/libpng/tests/pngstest-0g02
> gs/libpng/tests/pngstest-0g04
> gs/libpng/tests/pngstest-0g08
> gs/libpng/tests/pngstest-0g16
> gs/libpng/tests/pngstest-2c08
> gs/libpng/tests/pngstest-2c16
> gs/libpng/tests/pngstest-3p01
> gs/libpng/tests/pngstest-3p02
> gs/libpng/tests/pngstest-3p04
> gs/libpng/tests/pngstest-3p08
> gs/libpng/tests/pngstest-4a08
> gs/libpng/tests/pngstest-4a16
> gs/libpng/tests/pngstest-6a08
> gs/libpng/tests/pngstest-6a16
> gs/libpng/tests/pngstest-error
> gs/libpng/tests/pngtest
> gs/libpng/tests/pngunknown-IDAT
> gs/libpng/tests/pngunknown-discard
> gs/libpng/tests/pngunknown-if-safe
> gs/libpng/tests/pngunknown-sAPI
> gs/libpng/tests/pngunknown-sTER
> gs/libpng/tests/pngunknown-save
> gs/libpng/tests/pngunknown-vpAg
> gs/libpng/tests/pngvalid-gamma-16-to-8
> gs/libpng/tests/pngvalid-gamma-alpha-mode
> gs/libpng/tests/pngvalid-gamma-background
> gs/libpng/tests/pngvalid-gamma-expand16-alpha-mode
> gs/libpng/tests/pngvalid-gamma-expand16-background
> gs/libpng/tests/pngvalid-gamma-expand16-transform
> gs/libpng/tests/pngvalid-gamma-sbit
> gs/libpng/tests/pngvalid-gamma-threshold
> gs/libpng/tests/pngvalid-gamma-transform
> gs/libpng/tests/pngvalid-progressive-interlace-size
> gs/libpng/tests/pngvalid-progressive-interlace-standard
> gs/libpng/tests/pngvalid-progressive-interlace-transform
> gs/libpng/tests/pngvalid-progressive-standard
> gs/libpng/tests/pngvalid-standard
> gs/psi/msvc.mak
> gs/psi/os2.mak

2013-06-05 08:17:22 +0100
Ken Sharp <ken.sharp@artifex.com>
0de588b3705131067078d9cac84d5bc6ff0a77e9

> pdfwrite - squelch a couple of minor compiler warnings
> No differences expected
> gs/devices/vector/gdevpdfg.c

2013-06-04 13:46:07 -0700
Ray Johnston <ray.johnston@artifex.com>
1271b370117a9622fc255df665c007487e16296f

> Fix bug 694290 caused by an image totally off the page.
> This went away with the change to clipping, commit e0ba422, but we
> might as well fix this long standing issue as well.
> gs/base/gxclimag.c

2013-06-04 13:01:21 -0700
Ray Johnston <ray.johnston@artifex.com>
55fbadd981f3ca78f0920342a7ebaca4eab20cfa

> Fix SEGV when -ZL is used.
> The stream state memory is NULL, so use local_memory when printing.
> gs/base/gxclread.c

2013-06-04 10:52:14 -0700
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
d38f691578b52aa954ec9354b59919026d7e46f7

> Fixed GhostPCL -DPACIFY_VALGRIND missing symbol issue.
> pl/plplatf.c

2013-06-04 18:34:45 +0100
Ken Sharp <ken.sharp@artifex.com>
7719dd1084cf57cb415b8a64ea2ee09a6eb39ee2

> pdfwrite - silence valgrind warning
> Bug #694267
> "Valgrind issues found by fuzzing in process_text_modify_width (gdevpdte.c:1104)"
> I'm pretty sure this is functionally benign because the values read are not
> actually used, but setting them to zero silences the warning.
> No differences expected.
> gs/devices/vector/gdevpdtt.c

2013-06-04 13:14:52 +0100
Ken Sharp <ken.sharp@artifex.com>
549cf6ae1bf57fc8d84d0598f04a861378e0e5ea

> pdfwrite - colour management, convert Separation and DeviceN base spaces
> When the input is DeviceN or Separation, the color conversion strategy is
> Gray, RGB or CMYK, and the alternate space is not compatible, convert the
> alternate space. We do this by constructing either an exponential (Separation)
> or sampled (DeviceN) function, we sample the end points of each ink,
> convert the alternate space representation to the requested device space
> and use those as the data points ofr the function.
> The representation probably isn't that great, since it linearly interpolates
> between the (very few) sample points, but it does the job adequately, and
> preserves the Separation/DeviceN space while still creating an appropriate
> colour space in the output.
> No differences expected, this code not in use yet.
> gs/devices/vector/gdevpdfc.c
> gs/devices/vector/gdevpdfc.h
> gs/devices/vector/gdevpdfg.c

2013-06-04 09:44:33 +0100
Ken Sharp <ken.sharp@artifex.com>
662c5022b6731a4cff0c026c0ef62322aaaf396c

> pdfwrite - additional error checking on named destinations
> Bug #694194 "Seg faults found by fuzzing in pdfmark_DOCVIEW"
> The routine for creating a named destination could return an error if the
> destination page was outside the valid range (-2 in this case), but the
> DOCVIEW pdfmark wasn't testing the returned value.
> Added code to give a meaningful error and return a rangecheck error when this
> occurs.
> No differences expected.
> gs/devices/vector/gdevpdfm.c

2013-06-03 13:10:10 -0700
Ray Johnston <ray.johnston@artifex.com>
e0ba4228f11f9a5af359915878176efee8dc73f5

> Fix clipping bugs 693509 and 690036.
> The Adobe scan conversion rules call for the clip path to use the same
> rule as for filling. Thus we need to apply the 'adjust' to do the any part
> of pixel rule. Differences are expected, but bmpcmp doesn't show any.
> gs/base/gxcpath.c

2013-06-03 08:31:56 +0100
Chris Liddell <chris.liddell@artifex.com>
761e413514c7f9374f54e8ffef3c1d7ebf824e28

> Bug 694272: bounds check TTF outline points flags
> Reading the points "flags" from the TTF stream, we weren't bounds checking when
> the flag value is a repeated one, so we could trundle off the end of the buffer.
> No cluster differences.
> gs/base/ttfmain.c

2013-05-31 09:46:10 -0700
Ray Johnston <ray.johnston@artifex.com>
1eef08f4aaf485a18422e9fbcfd6ac8cbfb03cdb

> Temporarily disable BGPrint for the cups device until differences fixed.
> By using gdev_prn_output_page background printing is not performed.
> gs/cups/gdevcups.c

2013-05-30 15:48:33 -0700
Michael Vrhel <michael.vrhel@artifex.com>
483e100c06e647d8ba2d68beef09c1c241fd328d

> Addition of ETS code and project into gs/toolbin/halftone
> gs/toolbin/halftone/ETS/COPYING.txt
> gs/toolbin/halftone/ETS/Makefile_avec
> gs/toolbin/halftone/ETS/Makefile_sse2
> gs/toolbin/halftone/ETS/README.txt
> gs/toolbin/halftone/ETS/_eb_sse2.s
> gs/toolbin/halftone/ETS/build.bat
> gs/toolbin/halftone/ETS/eb_avec.c
> gs/toolbin/halftone/ETS/eb_avec.h
> gs/toolbin/halftone/ETS/eb_sse2.s
> gs/toolbin/halftone/ETS/ei03.pdf
> gs/toolbin/halftone/ETS/ets.c
> gs/toolbin/halftone/ETS/ets.h
> gs/toolbin/halftone/ETS/ipview.html
> gs/toolbin/halftone/ETS/test_ets.c
> gs/toolbin/halftone/ETS/tm.h
> gs/toolbin/halftone/ETS/win32/ETS.sln
> gs/toolbin/halftone/ETS/win32/ETS.vcproj

2013-05-30 15:40:34 -0700
Michael Vrhel <michael.vrhel@artifex.com>
69cce78d20f9ee34954812e72ad6f3e4bf085374

> Addition of -dPreBandThreshold information into documentation
> gs/doc/Use.htm

2013-05-29 21:59:45 -0700
Ray Johnston <ray.johnston@artifex.com>
0c55548b5fbf6fabdc7c5766c162b0cd67597627

> Fix incorrect Gray Detection on pages after the first color page.
> Reported by customer 801. The pageneutralcolor element of the icc_struct
> was not being reset, so once it was set for 'color' all subsequent pages
> would be seen as color.
> gs/base/gdevprn.c

2013-05-30 13:47:20 +0100
Chris Liddell <chris.liddell@artifex.com>
b09746cd4c822c2a72f146e74ff48c4ca4a94807

> Bug 694059: support all available TIFF compressions
> Previously, we weren't allowing certain valid (but possibly not terribly
> sensible) combinations of bit depth and compression - for those, tiffsep
> would silently ignore the setting and use a default.
> This has been relaxed, although certain combinations are not supported by
> libtiff are still proscribed (CRLE/G4/G3 and multibit per sample - for
> example, 8 bits per sample cannot be combined with CCITT Group 4 fax).
> Those now generate an error message and a rangecheck error.
> No cluster differences.
> gs/devices/gdevtifs.c
> gs/devices/gdevtsep.c

2013-05-30 14:41:07 +0200
Till Kamppeter <till.kamppeter@gmail.com>
c374882e38fdac7ef766c9ac1ec8674e02bd56bc

> Added support for printer calibration to the gstoraster CUPS filter
> For doing calibration printouts the color management in the print filter
> chain needs to get turned off. This is done by calling Ghostscript with the
> "-dUseFastColor" command line option. Inhibiting color management can be done
> via colord, with a command like
> colormgr device-inhibit /org/freedesktop/ColorManager/devices/<printer> 0
> or by sending the calibration print job with the option "color-management=off".
> Thanks to Richard Hughes for the patch.
> gs/cups/colord.c
> gs/cups/colord.h
> gs/cups/gstoraster.c

2013-05-29 11:24:02 -0700
Ray Johnston <ray.johnston@artifex.com>
89c224b029357002c48660dae98de2d1e560d4e0

> Fix for too many entries in an image Decode array reported by cust 532.
> This is an out-of spec file, but as usual, since Adobe handles it, so we do too.
> Allow too many by setting over_error to 0 when we load the Decode array.
> This required a change to dict_float_array_param so that it will load the
> requested number of elements (and return that count) when over_erro == 0.
> Also clean up the indenting and get rid of the unused decode_size variable.
> gs/psi/idparam.c
> gs/psi/zimage.c

2013-05-29 11:46:45 -0700
Ray Johnston <ray.johnston@artifex.com>
6ceadc6f2da001b183d700186e6b5e622bcb22cf

> Add missing include when GS_NO_UTF8=1
> gs/base/gp_wgetv.c

2013-05-29 17:24:32 +0100
Ken Sharp <ken.sharp@artifex.com>
2d04d5942b3e97b06a7ac4ed767a6c481d4421f4

> pdfwrite - improve handling of Unicode names
> Bug#694277 " Improve pdfmark processing to handle unusual names in named destinations"
> We can't handle Unicode names in PDF, technically we should write these as
> strings and enter them in the names table, but we don't have a mechanism for
> that for pdfmarks.
> Instead we leave them as names using the special processing in pdfwrite, but
> extended with additional markers. When writing these out pdfwrite converts
> the NULLs to an arbitrary string. This works adequately for the bug as
> these are named destinations, but its possible that other kinds of names
> might be visible in the PDF application and would give the wrong result.
> So this is at best a patch.
> No differences expected.
> gs/Resource/Init/gs_pdfwr.ps
> gs/devices/vector/gdevpdfr.c
> gs/devices/vector/gdevpdfu.c

2013-05-28 11:17:21 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
c2503db1c461d7d3af7c8f69a193fb978d8377b3

> Bug 694138: Fix component number validation in ICC colorspace
> gs/psi/zcolor.c

2013-05-24 17:40:42 +0100
Robin Watts <robin.watts@artifex.com>
69ea64d08a97da7afcfb0790f916f1ff4adf115e

> Fix MuPDF fuzzing SEGV
> Move the indexing of an array AFTER the check for whether the
> index is suitable.
> gs/jbig2dec/jbig2_text.c

2013-05-24 16:22:47 +0100
Robin Watts <robin.watts@artifex.com>
f40a8ab6a7326d1643852e7c9049a9b875131824

> JBIG2Dec: MUPDF fuzzing SEGV fixes
> The changes herein solve SEGVs (and valgrind failures) seen when
> fuzzing mupdf. The following are some files that show these up:
> tests_private/fuzzing/mupdf/280.pdf.SIGSEGV.93c.2002
> tests_private/fuzzing/mupdf/1112.pdf.SIGSEGV.9ab.128
> tests_private/fuzzing/mupdf/1136.pdf.SIGSEGV.93c.154
> gs/jbig2dec/jbig2_generic.c
> gs/jbig2dec/jbig2_symbol_dict.c

2013-05-27 09:23:35 +0100
Ken Sharp <ken.sharp@artifex.com>
c00e028429fa7bbbe1f3902286d5b3710b670815

> pdfwrite - better support for PageLabels
> Bug #693929 " Regression: Error: /undefined in --run--"
> This code now properly flattens a PageLabels number tree into a single node
> tree, which it converts to a string for inclusion in the output.
> In addition to flattening the tree we also perform considerable error checking
> on the tree construction, and we limit the number of page elements to 1000.
> This is because PostScript strings are limited to 64k and we use a string to
> pass the data to the device for inclusion. If we exceed 1000 elements then
> we simply abort the PageLabels (and print a warning on the back channel)
> No differences expected, this is not a printing eleent
> gs/Resource/Init/gs_pdfwr.ps

2013-05-26 13:08:46 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
3282874fbe636652df435fdacef4ebc3f3ee426b

> Bug 694087: Detect and correct wrong /Subtype of CID font
> This attribute appears to be tested again somewhere else.
> Changing the attribute to the correct value clears the bug.
> gs/Resource/Init/pdf_font.ps

2013-05-26 03:01:24 -0400
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
9567219b7bd46b1d8a7cfc318788e7dc24bebc21

> Bug 694021: Patch for seg fault related issues
> The seg fault is due to the the image decoder trying to use an uninitialized
> GR_stats. This also uncovered a few other errors that are covered here :-
> 1) GR_stats is now initialised in all places to prevent it reaching
> jbig2_arith_decode with fake values
> 2) jbig2_arith_decode has been updated to prevent access outside of the
> jbig2_arith_Qe array which now returns an error in such cases.
> 3) all uses of jbig2_decode_refinement_region now check for a returning error
> and act accordingly.
> gs/jbig2dec/jbig2_arith.c
> gs/jbig2dec/jbig2_symbol_dict.c
> gs/jbig2dec/jbig2_text.c

2013-05-26 02:02:38 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
7131b2045a957089f2c7eec227c23f5fbe4ee1e7

> Bug 694100: Fix yet another automatic PDF file closure.
> Read PDF file more carefully during testing for the stream xref
> and validate the tokens to avoid reading past the EOF and
> closing the file.
> gs/Resource/Init/pdf_main.ps

2013-05-24 16:17:45 +0100
Ken Sharp <ken.sharp@artifex.com>
2f08dfcd4db7f6a95ac9ee983692d922c09a1ffd

> pdfwrite - ignore overly complex PageLabels for now
> The current PageLabels code doesn't handle anything except the simplest
> case (/Nums at the page tree root), so ignore anything more complex so
> that we don't throw an error.
> More work to do, I want to handle a proper tree.
> No differences expected.
> gs/Resource/Init/gs_pdfwr.ps

2013-05-24 16:02:21 +0100
Chris Liddell <chris.liddell@artifex.com>
66695586781291ca37d190c537784ccf94595428

> Add trio directory to zip archive target.
> CLUSTER_UNTESTED
> gs/psi/winint.mak

2013-05-24 13:41:41 +0100
Chris Liddell <chris.liddell@artifex.com>
735c3bbfecc9bbb5792c85558b4641568e316b9d

> Bug 691784 - jbig2dec WIN32 DLL with configure
> See http://bugs.ghostscript.com/show_bug.cgi?id=691784
> CLUSTER_UNTESTED
> gs/jbig2dec/configure.ac

2013-05-21 00:47:46 +0100
Robin Watts <robin.watts@artifex.com>
b44040bb9550d403313baec2bed084f1de50093a

> Fix typo in previous commit.
> I'd forced the valgrind code on to ensure it was tested, and forgot to
> disable it before commit.
> gs/base/gxclipm.c

2013-05-20 19:18:36 +0100
Robin Watts <robin.watts@artifex.com>
94bf81402c991ca8feb59012078b19b5b5d6a5dd

> Bug 693803: Add PACIFY_VALGRIND code for clip_runs_enumerate.
> gs/base/gxclipm.c

2013-05-20 15:10:07 +0100
Robin Watts <robin.watts@artifex.com>
ebbcd5b9e67b45c8d7187730d131ff43060aa247

> Bug 693807: Add PACIFY_VALGRIND code to mem_true32_copy_mono.
> Mask of uninitialised bits at the end of a tile row.
> gs/base/gdevm32.c

2013-05-17 11:02:12 -0700
Robin Watts <robin@peeves.(none)>
54683cf9303c3b9146492a9a3a5f5fbc3a7521bc

> Bug 693965: Fix SEGV in fuzzing test (corrupt image)
> Second attempt to commit this; the first time had a typo in.
> The first error given by valgrind is due to the image in this
> file being a 16bpp one with a horizontal flip. This tickles
> an incomplete case within the interpolation code. Not
> surprising as there are more options in that code than anyone
> should be expected to cope with. The code is fixed here.
> This leads on to the cause of the crash; the image has a matrix
> with a HUGE x shift on it. This upsets some of the floating
> point calculations used to calculate the render rectangle.
> This code has been hardened now to cope with such errors.
> gs/base/gxipixel.c
> gs/base/gxiscale.c

2013-05-20 12:14:00 +0100
Robin Watts <robin.watts@artifex.com>
0956abfbb0b53ecd1e8e276d6b2c603a720e6187

> Revert "Bug 693965: Fix SEGV in fuzzing test (corrupt image)"
> This reverts commit 1f80c02083b222e3f005c46e91ab4597de323371. Committed
> too early, sorry.
> gs/base/gxipixel.c
> gs/base/gxiscale.c

2013-05-20 09:30:18 +0100
Ken Sharp <ken.sharp@artifex.com>
a8487e333554f19bf8d529b9e7893ad4e16448d1

> Ensure that PCL bitmap glyphs with no data still execute setcachedevice
> This grew out of Bug #694069, in the course of resolving that problem it
> transpired that, if there was no data available for a downloaded bitmap
> character, the PCL interpreter simply returned.
> In conjunction with pdfwrite, this caused an endless loop due to the character
> cache being overfilled. We only check the availability of space in the
> character cache in setcachedevice, so its safer to make sure that we do
> call it, thereby avoiding the overfilling.
> No differences expected.
> pl/plchar.c

2013-05-18 14:42:23 -0700
Ray Johnston <ray.johnston@artifex.com>
36f1de9b5a937d535cb44bb088572b76a9c5bcbd

> Fix BGPrint mode (copy_paste error that disabled background printing.
> gs/base/gdevprn.c

2013-05-17 11:02:12 -0700
Robin Watts <robin@peeves.(none)>
1f80c02083b222e3f005c46e91ab4597de323371

> Bug 693965: Fix SEGV in fuzzing test (corrupt image)
> The first error given by valgrind is due to the image in this
> file being a 16bpp one with a horizontal flip. This tickles
> an incomplete case within the interpolation code. Not
> surprising as there are more options in that code than anyone
> should be expected to cope with. The code is fixed here.
> This leads on to the cause of the crash; the image has a matrix
> with a HUGE x shift on it. This upsets some of the floating
> point calculations used to calculate the render rectangle.
> This code has been hardened now to cope with such errors.
> gs/base/gxipixel.c
> gs/base/gxiscale.c

2013-05-16 07:34:06 +0100
Chris Liddell <chris.liddell@artifex.com>
f0ff05b449b4ecc9332029faf7e7b186b3e18052

> Add words about shared libs on OS X.
> CLUSTER_UNTESTED
> gs/doc/Make.htm

2013-05-15 06:54:53 -0700
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
eccbb7c6c0c267f6e3b7a2381b0b019140f3d831

> Added singlePagePDF mode to clusterpush.pl.
> gs/toolbin/localcluster/clusterpush.pl

2013-05-14 16:28:22 -0600
Henry Stiles <henry.stiles@artifex.com>
853678e7bd4303cd5a1b5e74dfe257fd896a106c

> Remove obsolete USECIEColor option in PCL and PXL.
> pcl/pccid.c
> pcl/pcstate.h
> pl/pjparse.c
> pxl/pxcet.txt
> pxl/pximage.c
> pxl/pxink.c
> pxl/pxpthr.c
> pxl/pxsessio.c
> pxl/pxstate.h

2013-05-14 15:33:24 -0600
Henry Stiles <henry.stiles@artifex.com>
593afcba2b670c6b1051d39d2a73ce1b386b871c

> Remove obsolete scripts
> pxl/pxprint.bat
> pxl/pxprint.tcl

2013-05-14 17:39:47 +0100
Robin Watts <robin.watts@artifex.com>
397e20418223e2faba856ae80e7945faa1a10e99

> Add gsicc_monitorcm.c to Win32 project.
> gs/ghostscript.vcproj

2013-05-14 17:24:57 +0100
Ken Sharp <ken.sharp@artifex.com>
37b08e30586434098c9f6b8dc35fa25de39f468d

> pdfwrite - when using %d in OutputFile, empty glyphs from cache
> Bug #694069
> When we are using '%d' in the Output File Name, we throw away the PDF font
> resource after every page, but the intperpreter glyph cache remains filled.
> This is a problem for type 3 fonts (specifically their PCL equivalents), as
> we won't rerun the glyph description to capture it for a type 3 font, so
> the glyphs don't get captured.
> To solve this we empty any existing cache entry before attempting to run the
> glyph. This runs into some more awkwardness with a specific kind of broken
> font (no chacracter data) in some QL test files. We work around that too.
> gs/devices/vector/gdevpdtt.c

2013-05-14 11:04:02 +0100
Chris Liddell <chris.liddell@artifex.com>
e76dc46756e89a14a3348bce12a633d32e4fa831

> Allow command line override for endian setting.
> Due bugs in certain versions of autoconf, we use an explicit check for
> endianness instead of the built-in macro. This can result in problems when
> cross compiling.
> This override allows command line options to pre-empt the explicit check.
> No cluster differences.
> configure.ac
> gs/configure.ac

2013-05-14 09:27:08 +0100
Ken Sharp <ken.sharp@artifex.com>
4692f1abb037f49bd5158fb6a988076fdc14754d

> pdfwrite - really make all TrueType fonts symbolic
> If we don't subset TrueType fonts, we still want to mark them as symbolic,
> because we never emit a /Encoding, and without that Acrobat (but not
> other readers) is unable to display some glyphs correctly.
> No differences expected.
> gs/devices/vector/gdevpdtd.c

2013-05-11 16:30:36 -0700
Ray Johnston <ray.johnston@artifex.com>
c03495a2c2df7f03d537dbbd53aedc014e0577d0

> Add documentation for BGPrint and GrayDetection.
> gs/doc/Language.htm

2013-05-09 20:47:31 -0700
Ray Johnston <ray.johnston@artifex.com>
7a8612112478196d8f047a556fdbb15d17aec7d0

> Add PSFitPage and FitPage options to allow fitting PS files to a page.
> The FitPage option is added as a convenience to set all three *FitPage
> options, so -dFitPage is the same as -dEPSFitPage -dPDFFitPage -dPSFitPage.
> The -dPSFitPage option is new and works by establishing the default
> Polcies PageSize to 13.
> When the Policy is 3 or 13, the page size matching logic rotates, scales,
> and center a PostScript file's requested page size on the best fit medium.
> When the Policy is 13, the the match_page_size enables the scaling down
> (as with Policy 3) as well as up.
> Only populate the InputAttr dictionary with the current page size if
> FIXEDMEDIA is set (explicitly, or impiled by -g) so that only that
> page size is available for match_page_size.
> When the policy is 13, we enable the PageSize in the setpagedevice
> merged request even if FIXEDMEDIA is set.
> The make_adjustment_matrix has the check for factor < 1 removed since
> this is accounted for in the caller setting the 'scale' boolean (larger).
> The documentation in doc/Use.htm is updated for both the -dPSFitPage
> option and the -dFitPage option.
> gs/Resource/Init/gs_init.ps
> gs/Resource/Init/gs_setpd.ps
> gs/doc/Use.htm
> gs/psi/zmedia2.c

2013-05-13 17:03:47 +0100
Chris Liddell <chris.liddell@artifex.com>
790240763991cf42b98b37c9dec22bf67df4c90d

> Use the srcdir variable in configure for Luratech
> One of the Luratech paths in the configure script wasn't using the srcdir
> variable so would not work correctly for "out of tree" building.
> No cluster differences.
> gs/configure.ac

2013-05-11 10:30:46 +0100
Ken Sharp <ken.sharp@artifex.com>
606f3279e00ae250bf883ce45b90d276943ffe84

> pdfwrite - don't cache high level pattern filled glyphs
> Bug #693946 "High level pattern commit causes a regression"
> If we use the cache when a glyph is filled with a high level pattern we will
> get incorrect rendering, as the pattern was not passed down to the low level
> routines. So make sure we don't cache glyphs under these conditions, nor
> consult the cache for existing cached glyphs.
> Expected Differences
> 14-07.bin and 19-10.bin should now work correctly
> gs/devices/vector/gdevpdtt.c

2013-05-10 09:57:00 +0100
Ken Sharp <ken.sharp@artifex.com>
32954e1a310eb4a3673a0eb815be8d618e17aad4

> epswrite - flush stream before writing page trailer
> Bug #694061 "epswrite generates bad file"
> The code (quite deliberately) writes the page trailer *directly to the file*
> before flushing the stream. This resulted in the page trailer being emitted
> part way through a path construction and fill. The fill is completed by the
> flushing of the stream.
> In this commit we flush the stream first.
> No differences expected, the cluster does not test epswrite.
> gs/devices/vector/gdevps.c

2013-05-10 08:31:44 +0100
Ken Sharp <ken.sharp@artifex.com>
ca6408d4bda6c899374984ba7705e734ff6c9d59

> documentation - remove duplicated epswrite section in devices.htm
> gs/doc/Devices.htm

2013-05-09 09:43:34 +0100
Chris Liddell <chris.liddell@artifex.com>
1f5bc0eb4bbb1c9512f8c63e953b9d2cd76ca563

> Bug 693964: handle missing FistChar and Widths
> When tailoring scaling a substitute font (based on the Widths array),
> handle non-spec compliant files which are missing FirstChar and Width
> entries from FontDescriptor dictionaries for non-base14 fonts.
> No cluster differences.
> gs/Resource/Init/pdf_font.ps

2013-05-08 17:00:27 -0700
Robin Watts <robin@peeves.(none)>
3aa5eb75e645d70f315193869179ec88ff20691c

> Bug 693377: Fix warning in rinkj device due to pointer cast.
> Cast via size_t to avoid warning.
> gs/devices/rinkj/evenbetter-rll.c

2013-05-08 20:28:46 +0000
Robin Watts <robin.watts@artifex.com>
d8926b7746b8acbf870b3aed93ba2a4ee799e94b

> Bug 693377: Fix some 32bit specific warnings in gdevmjc.c
> gs/contrib/japanese/gdevmjc.c

2013-05-08 13:24:14 -0700
Robin Watts <robin@peeves.(none)>
d838c5de6baa30cec31542ae8998fe3d3a5e4b31

> Bug693377: Squash some warnings in libtiff
> Avoid warnings about casting pointer to int of a different size
> by casting via size_t. Should be ptrdiff_t really, but we don't
> have that in all cases.
> gs/tiff/libtiff/tif_unix.c

2013-05-08 19:25:36 +0100
Robin Watts <robin.watts@artifex.com>
040915cc3ab82a9b0be77fa4dd27caa330f2ab5c

> Squash some warnings.
> In gs/base/gsroprun1.h we cast a pointer to an int and then & 3
> to find alignment. Given ints are always > 2 bits, this is always
> safe, but the compiler whinges anyway. We'd like to use ptrdiff_t
> instead to avoid the whinging, but it's not defined. So define
> our own using the ARCH_ macros.
> In gs/base/gxclrect.c, we check for the size of a type, and then
> shift down by it. The compiler complains that the shift may be
> too large to be defined in C, not realising that this is precisely
> what we have just checked. We work around this by shifting in 2
> stages.
> gs/base/gsroprun1.h
> gs/base/gxclrect.c

2013-05-08 11:16:05 -0600
Henry Stiles <henry.stiles@artifex.com>
ae3839979568fcb7e4a158cff48eed037830878a

> Miscellaneous warning and scan build fixes.
> gs/devices/gdevpxut.c
> gs/devices/vector/gdevsvg.c
> pcl/pcsfont.c
> pcl/pctext.c
> pxl/pxsessio.c

2013-05-08 13:13:02 +0100
Paul Gardiner <paul@glidos.net>
b652073e14ebfccf7324ae05f9bf871502560bf4

> WinRT: add build instructions
> gs/doc/Make.htm

2013-05-08 13:31:22 +0100
Chris Liddell <chris.liddell@artifex.com>
4b4cde01cf5be3d9caa813532ca93603a36d2f20

> Bug 688949: allow Ghostscript to build outside src tree
> These changes allow you to run the Ghostscript configure script and make from
> outside the source tree. Allowing the use of a "build directory" so the
> source directory stays unadulterated.
> The cluster test through up a load of compiler warnings, but none of them are
> new, as far as I can tell.
> No cluster differences.
> gs/Makefile.in
> gs/configure.ac
> gs/cups/cups.mak
> gs/devices/devs.mak

2013-05-07 17:11:19 -0600
Henry Stiles <henry.stiles@artifex.com>
9eb9408b3ccfdb8f0cf54d8ca9adcc79a102319a

> Fix 693412 fix duplex and number of copies interaction.
> Add pcl duplex command if the page count is divisible by the number of
> copies not the raw page count to properly collate duplexing jobs.
> Patch contributed by Binaria Digital.
> gs/devices/gdevdljm.c

2013-05-07 15:40:50 +0100
Paul Gardiner <paul@glidos.net>
9429a2dbfe6609939185970beb4789bd438624af

> Support building for WinRT
> .gitignore
> gs/base/gp_msdll.c
> gs/base/gp_mswin.c
> gs/base/gp_ntfs.c
> gs/base/gp_win32.c
> gs/base/gp_wpapr.c
> gs/base/gp_wsync.c
> gs/base/windows_.h
> gs/base/winrtsup.cpp
> gs/base/winrtsup.h
> gs/ghostscript_rt.vcxproj
> gs/psi/iapi.c
> gs/psi/msvc.mak
> main/pcl6_msvc.mak
> winrt/GhostPDL.sln

2013-05-07 15:34:00 +0100
Chris Liddell <chris.liddell@artifex.com>
19dc7b855696c15a074067e883a13588aca8774d

> Bug 691555: two jbig2dec patches for libpng14 Cygwin/MinGW
> from yselkowitz@users.sourceforge.net
> Adding "-lpng -lz" to LIBS causes everything to be linked against them,
> whether or not they need them. Only the jbig2dec executable uses
> libpng; libjbig2dec does not, so this causes a needless dependency on
> libpng and zlib. Instead, define a separate PNG_LIBS variable and use
> it in jpeg2dec_LDADD.
> libtool requires the -no-undefined flag on PE platforms (Cygwin/MinGW)
> in order to make a shared library due to the unique requirements of
> DLLs.
> No cluster differences.
> gs/jbig2dec/Makefile.am
> gs/jbig2dec/configure.ac

2013-05-07 15:11:10 +0100
Ken Sharp <ken.sharp@artifex.com>
cfa7da5e8b995023ab56186de1fe1e007619b63f

> vector device - ensure colour changes are not restored away by clip
> Bug #693951 "pswrite/epswrite is changing colors when creating an eps or an ps file from a ps file"
> When an image is degenerated into trapezoids, then when writing the trapezoids
> we first set the colour, then ensure any clip path is satisfied, then emit
> the trapezoid and fill it.
> However, if a clip path *is* pending, then it will emit a 'grestore' which
> restores away the colour we initially set. This commit ensures that if a
> clip is pending, we set the colour again after completing the clip.
> No differences expected.
> gs/base/gdevvec.c

2013-05-07 11:56:16 +0100
Chris Liddell <chris.liddell@artifex.com>
8128a2c74d319c430a76cca5620a6f4a77505e46

> Bug 693253: have the "-h" output mention fontconfig
> When Ghostscript is built to use fontconfig to try to find font files (in
> addition to the "normal" paths), include a note in the "-h" output
> that states fontconfig may be used.
> No cluster differences.
> gs/psi/imainarg.c

2013-04-15 18:35:36 +0100
Chris Liddell <chris.liddell@artifex.com>
e64ac4c83a4ae07dc15c4cacd7b60cba6294899a

> Bug 693843: Add a gs_sprintf() function, and supporting code
> Same as sprintf() but certain to be unaffected by localization.
> Utilizes the "trio" string library, also added here. There is one modification
> to trio, in trio.c and labelled with "/* GS Modification */" - by default, trio
> is a little aggressive in the point it switches to exponent notation, and the
> patch brings is more line with what we need/expect.
> trio also includes a sscanf() function which we can utilise if required.
> See the gs-sprintf branch for the individual commits - especially those in the
> trio source, should a trio update ever be pulled in.
> This causes rounding differences in the pdfwrite/ps2write output in a number
> of the cluster files. They all appear to be pixel variations.
> common/msvc_top.mak
> common/ugcc_top.mak
> gs/Makefile.in
> gs/base/fapiufst.c
> gs/base/gdevdevn.c
> gs/base/gdevp14.c
> gs/base/gp_macio.c
> gs/base/gp_mswin.c
> gs/base/gp_wgetv.c
> gs/base/gs.mak
> gs/base/gsalloc.c
> gs/base/gsdevice.c
> gs/base/gsdparam.c
> gs/base/gsfcmap.c
> gs/base/gsicc_create.c
> gs/base/gsicc_manage.c
> gs/base/gsiodisk.c
> gs/base/gspmdrv.c
> gs/base/gssprintf.c
> gs/base/gssprintf.h
> gs/base/gxblend.c
> gs/base/gxblend1.c
> gs/base/gxclmem.c
> gs/base/gxhintn.c
> gs/base/gxpath.c
> gs/base/gxpcmap.c
> gs/base/lib.mak
> gs/base/md5main.c
> gs/base/mkromfs.c
> gs/base/sdcparam.c
> gs/base/sjbig2.c
> gs/base/spprint.c
> gs/base/stdio_.h
> gs/base/trio.mak
> gs/base/unix-gcc.mak
> gs/base/unixansi.mak
> gs/base/winlib.mak
> gs/base/wrfont.c
> gs/base/write_t1.c
> gs/base/write_t2.c
> gs/contrib/eplaser/gdevescv.c
> gs/contrib/gdevcd8.c
> gs/contrib/gdevdj9.c
> gs/contrib/gdevhl12.c
> gs/contrib/gdevxes.c
> gs/contrib/gomni.c
> gs/contrib/japanese/dviprlib.c
> gs/contrib/japanese/gdevfmlbp.c
> gs/contrib/japanese/gdevfmpr.c
> gs/contrib/japanese/gdevj100.c
> gs/contrib/japanese/gdevlbp3.c
> gs/contrib/japanese/gdevmag.c
> gs/contrib/japanese/gdevnpdl.c
> gs/contrib/lips4/gdevl4r.c
> gs/contrib/lips4/gdevl4v.c
> gs/contrib/pcl3/src/gdevpcl3.c
> gs/cups/gdevcups.c
> gs/devices/gdev3b1.c
> gs/devices/gdev8510.c
> gs/devices/gdevccr.c
> gs/devices/gdevdjet.c
> gs/devices/gdevijs.c
> gs/devices/gdevl31s.c
> gs/devices/gdevpng.c
> gs/devices/gdevsppr.c
> gs/devices/gdevsun.c
> gs/devices/gdevtifs.c
> gs/devices/gdevtsep.c
> gs/devices/gdevupd.c
> gs/devices/gdevwpr2.c
> gs/devices/gdevxini.c
> gs/devices/vector/gdevpdf.c
> gs/devices/vector/gdevpdfb.c
> gs/devices/vector/gdevpdfe.c
> gs/devices/vector/gdevpdfg.c
> gs/devices/vector/gdevpdfi.c
> gs/devices/vector/gdevpdfm.c
> gs/devices/vector/gdevpdfo.c
> gs/devices/vector/gdevpdfr.c
> gs/devices/vector/gdevpdft.c
> gs/devices/vector/gdevpdfu.c
> gs/devices/vector/gdevpdfv.c
> gs/devices/vector/gdevpdtb.c
> gs/devices/vector/gdevpdtc.c
> gs/devices/vector/gdevpdtf.c
> gs/devices/vector/gdevpdti.c
> gs/devices/vector/gdevpdtt.c
> gs/devices/vector/gdevpdtw.c
> gs/devices/vector/gdevps.c
> gs/devices/vector/gdevpsf1.c
> gs/devices/vector/gdevpsf2.c
> gs/devices/vector/gdevsvg.c
> gs/devices/vector/gdevtxtw.c
> gs/devices/vector/gdevxps.c
> gs/psi/dmmain.c
> gs/psi/dpmain.c
> gs/psi/dscparse.c
> gs/psi/dwimg.c
> gs/psi/dwmainc.c
> gs/psi/dxmain.c
> gs/psi/int.mak
> gs/psi/iparam.c
> gs/psi/iutil.c
> gs/psi/iutil2.c
> gs/psi/msvc.mak
> gs/psi/zbfont.c
> gs/psi/zdouble.c
> gs/psi/zfapi.c
> gs/psi/zfont2.c
> gs/trio/CHANGES
> gs/trio/FILES
> gs/trio/Makefile.in
> gs/trio/README
> gs/trio/autogen.sh
> gs/trio/compare.c
> gs/trio/configure.in
> gs/trio/doc/doc.h
> gs/trio/doc/doc_dynamic.h
> gs/trio/doc/doc_printf.h
> gs/trio/doc/doc_register.h
> gs/trio/doc/doc_scanf.h
> gs/trio/doc/doc_static.h
> gs/trio/doc/footer.html
> gs/trio/doc/header.html
> gs/trio/doc/trio.cfg
> gs/trio/doc/trio.css
> gs/trio/example.c
> gs/trio/html/group___dynamic_strings.html
> gs/trio/html/group___printf.html
> gs/trio/html/group___scanf.html
> gs/trio/html/group___special_quantities.html
> gs/trio/html/group___static_strings.html
> gs/trio/html/group___user_defined.html
> gs/trio/html/index.html
> gs/trio/html/modules.html
> gs/trio/html/trio.css
> gs/trio/install-sh
> gs/trio/maketgz
> gs/trio/regression.c
> gs/trio/strio.h
> gs/trio/trio.c
> gs/trio/trio.h
> gs/trio/triodef.h
> gs/trio/trionan.c
> gs/trio/trionan.h
> gs/trio/triop.h
> gs/trio/triostr.c
> gs/trio/triostr.h
> main/pcl6_gcc.mak
> main/pcl6_msvc.mak
> pcl/pcfontpg.c
> pcl/pcht.c
> pcl/pcstatus.c
> pl/dwimg.c
> pl/dwmainc.c
> pl/pjparse.c
> pl/plmain.c
> pxl/pxerrors.c
> pxl/pxfont.c
> pxl/pxpthr.c
> svg/svg_msvc.mak
> xps/xps_msvc.mak
> xps/xpsttf.c
> xps/xpszip.c

2013-05-07 08:24:06 +0100
Ken Sharp <ken.sharp@artifex.com>
07ba8bea8e98084a156edac611a4ae92545edf06

> fix commit 2adc88900956d92433e1d97ca3a22170a462f098
> Seems there was a typo in this commit, which is fixed here.
> gs/base/gxclread.c

2013-05-07 08:18:12 +0100
Ken Sharp <ken.sharp@artifex.com>
50533c139389cdfa7c652eb60b973239033aebc3

> pdfwrite - get rid of some compiler warnings
> gs/devices/vector/gdevpdtb.c

2013-05-02 17:03:57 -0700
Ray Johnston <ray.johnston@artifex.com>
2adc88900956d92433e1d97ca3a22170a462f098

> Finish GrayDetection implementation and add pnmcmyk example device.
> The pnmcmyk device will output a P5 pgm file if the page source colors
> are all (near) neutral, otherwise will output PAM P7 32-bit CMYK.
> This device is intended to be an example for a customer.
> Note that there is a conditional compile based on PESSIMISTIC_CMYK_NEUTRAL
> that, if defined, will assume that if any C, M, or Y component has a value
> greater than DEVICE_NEUTRAL the page will be treated as color (even if all
> three components are 100%). This may be what the customer requested.
> The default comparison is based on the C, M, and Y components be close to
> each other (similar to RGB).
> Also disable graydetection during clist playback. We don't need worry about
> page mode because colors are already processed as the image is rendered
> into the page buffer, but high level images in the clist would slow down
> if graydetection was performed again.
> gs/base/gsicc_monitorcm.c
> gs/base/gxclread.c
> gs/devices/devs.mak
> gs/devices/gdevpbm.c
> gs/psi/msvc.mak

2013-05-06 17:03:10 +0100
Ken Sharp <ken.sharp@artifex.com>
b04bd6b0bb5098b809b3d06f69e2eb55905af648

> pdfwrite - DO not leave dangling references in font/matrix cache
> Bug #693948 "%d not working with pcl"
> Under some conditions (TrueType fonts, but not CID TT), we end up adding the
> font to the font/matrix cache. However, the font we add is a copy of the
> original.
> If we are using %d to emit multiple files, then we free our copies after
> every page. However, we did not purge the cache, leading to stale pointers
> in it. If we then reused a font we could end up trying to use a stale
> pointer with unfortunate results.
> This commit adds a 'notify' procedure so that we clear copied fonts from
> the cache when they are released.
> This caused one difference in the regression tests, which I do not understand
> but is not visilby different....
> Signed-off-by: Ken Sharp <ken.sharp@artifex.com>
> gs/devices/vector/gdevpdtb.c

2013-05-06 07:47:00 -0600
Henry Stiles <henry.stiles@artifex.com>
0a3d34cfec18ffd3ae1c6fd29dc3c6d4755fe5a3

> Fix font state variables not propely initialized and add character
> angle state in PXL Pass Thru mode.
> We note several progression in T427.BIN and C705.BIN with the change.
> pxl/pxpthr.c

2013-04-29 09:40:19 -0700
Ray Johnston <ray.johnston@artifex.com>
73957305ae44e43174cd8173b94c35f9f4ca55b4

> Add gdev_prn_bg_output_page (and _seekable) to support BGPrint.
> Some devices are not compatible with background printing, if they are
> not thread safe (use globals) or update the device structure.
> Simple updates to the device structure can be handled in a device's
> own output_page function that performs any actions needed before
> calling gdev_prn_bg_output_page, then performing any action needed
> after the page is printed (or started in the background). The cups
> device is an example of this.
> If the page is printed in the background, it uses a clone of the device
> structure, so any changes to that structure will not be reflected in
> the foreground device.
> The devices were reviewed and those that were changed to use gdev_prn_bg
> output_page proc should be safe for background printing, but only
> those that are used in regression testing have been tested by forcing
> BGPrint=true.
> gs/base/gdevprn.c
> gs/base/gdevprn.h
> gs/cups/gdevcups.c
> gs/devices/devs.mak
> gs/devices/gdev3852.c
> gs/devices/gdev4081.c
> gs/devices/gdev4693.c
> gs/devices/gdev8510.c
> gs/devices/gdevadmp.c
> gs/devices/gdevatx.c
> gs/devices/gdevbit.c
> gs/devices/gdevbj10.c
> gs/devices/gdevbmp.c
> gs/devices/gdevccr.c
> gs/devices/gdevcdj.c
> gs/devices/gdevcfax.c
> gs/devices/gdevcif.c
> gs/devices/gdevclj.c
> gs/devices/gdevcljc.c
> gs/devices/gdevcslw.c
> gs/devices/gdevdfax.c
> gs/devices/gdevdjet.c
> gs/devices/gdevdjtc.c
> gs/devices/gdevdm24.c
> gs/devices/gdevepsc.c
> gs/devices/gdevepsn.c
> gs/devices/gdevescp.c
> gs/devices/gdevfax.c
> gs/devices/gdevhl7x.c
> gs/devices/gdevicov.c
> gs/devices/gdevimgn.c
> gs/devices/gdevjbig2.c
> gs/devices/gdevjpeg.c
> gs/devices/gdevjpx.c
> gs/devices/gdevl31s.c
> gs/devices/gdevlbp8.c
> gs/devices/gdevlj56.c
> gs/devices/gdevlp8k.c
> gs/devices/gdevlxm.c
> gs/devices/gdevmgr.c
> gs/devices/gdevmiff.c
> gs/devices/gdevn533.c
> gs/devices/gdevo182.c
> gs/devices/gdevokii.c
> gs/devices/gdevpbm.c
> gs/devices/gdevpcx.c
> gs/devices/gdevperm.c
> gs/devices/gdevphex.c
> gs/devices/gdevpjet.c
> gs/devices/gdevplan.c
> gs/devices/gdevplib.c
> gs/devices/gdevpng.c
> gs/devices/gdevpsd.c
> gs/devices/gdevpxut.c
> gs/devices/gdevpxut.h
> gs/devices/gdevrinkj.c
> gs/devices/gdevsgi.c
> gs/devices/gdevsj48.c
> gs/devices/gdevsppr.c
> gs/devices/gdevstc.c
> gs/devices/gdevsunr.c
> gs/devices/gdevtfax.c
> gs/devices/gdevtfnx.c
> gs/devices/gdevtknk.c
> gs/devices/gdevtsep.c
> gs/devices/gdevxcf.c
> gs/devices/vector/gdevlj56.c
> gs/devices/vector/gdevpxut.c
> gs/devices/vector/gdevpxut.h

2013-04-10 20:24:02 -0700
Ray Johnston <ray.johnston@artifex.com>
c947a5c62b9eef2b2b2afcab986a5b7bbb8fc3ad

> Add BGPrint prn device parameter to render clist pages while parsing.
> This enhancement closes the clist files of the page, then starts a
> printing thread (prn_print_page_in_background) to write out the page
> and returns to allow parsing of the next page into a new set of clist
> files while the 'bg printing' thread writes out the data, performing
> compression and other conversion that the BGPrint=false mode performs
> in the main (parsing) thread.
> If NumRenderingThreads > 0, the band rendering will also be performed
> for multiple bands in separate threads.
> Thus, the parsing of pages after the first will potentially overlap
> the rendering and writing of the previous page. No queue is maintained,
> so the overlap is limited to the next page.
> If bg_print.device is not NULL, then we have a page that was rendered
> in the background that we may need to wait for before pprinting the next
> page or exiting. After we call the prn_finish_bg_print, we may need to
> re-open the printer in case it was closed (most commonly due to %d in
> the fname).
> When printing in foreground mode, the bg_print.device will be NULL.
> Note, We can't use the icc_table created for the foreground since it may
> be in GC'd memory (it must be created with the thread's allocator).
> The equivalent_cmyk_colors are needed by the backgorund print device.
> Add .EquivCMYKColors device parameter which is an array of 5 integers per
> spot color. The first integer is 'valid' followed by the 'frac' C, M, Y
> and K values. This allows the gs_putdeviceparams to have the spot color
> information.
> The foreground device was relying on the print_page procedure to free
> the separation names from a page before starting the next page. Move
> this to gdev_prn_output_page instead. Also since this is common, we
> don't need it in gdevpsd and gdevtsep print_page functions.
> Expected difference when BGPrint=true is 99-01-fixed.PS for all devices
> due to adding the .EquivCMYKColors device parameter.
> gs/base/gdevdevn.c
> gs/base/gdevprn.c
> gs/base/gdevprn.h
> gs/base/gxclist.h
> gs/base/gxclpage.c
> gs/base/gxclthrd.c
> gs/base/gxclthrd.h
> gs/base/lib.mak
> gs/devices/gdevplib.c
> gs/devices/gdevpsd.c
> gs/devices/gdevtsep.c

2013-05-05 10:05:52 +0100
Ken Sharp <ken.sharp@artifex.com>
a5874589447b76a99eef2114acd12633beed7424

> squelch a couple of minor compiler warnings
> pcl/pcpatrn.c
> pl/plchar.c

2013-05-04 09:13:12 +0100
Ken Sharp <ken.sharp@artifex.com>
e99c0e5b704954d61bfe5a26c410fdb01a3c48ae

> Initialise a pointer to non-NULL to silence static analysis warning
> The 'dereference of a non-NULL pointer' is incorrect, its not possible to
> reach the questionable de-reference with the pointer NULL but it seems the
> static analyser can't detect that. This should silence it.
> gs/devices/vector/gdevpsdi.c

2013-05-04 09:11:32 +0100
Ken Sharp <ken.sharp@artifex.com>
601084bf86031eea15312c27718d13a7beda85a9

> Include a prototype for gs_next)ids to silence a compiler warning
> pcl/pcpalet.c

2013-05-03 10:37:50 +0100
Chris Liddell <chris.liddell@artifex.com>
a5a841b816c528b6f16a83ec02020db5953dde79

> Update CFLAGS for debug build with gcc.
> Add debug flags so that as many versions as possible of gcc will include the
> macro expansion data in the debug build.
> No cluster differences.
> gs/configure.ac

2013-05-03 10:32:16 +0100
Chris Liddell <chris.liddell@artifex.com>
7db1a288da4d7838ec801e69f3e2f6bf46598aaa

> Slightly de-macro-fy scfd.c
> There were two macros used which were *way* too big for "good practice"
> coding ("get_run" and "invert_data", and one changed for convenience
> ("skip_data").
> Changing them to functions and testing shows a few seconds penalty for the
> entire test suite - an acceptable trade, IMHO.
> No cluster differences.
> gs/base/scfd.c

2013-05-03 10:19:34 +0100
Chris Liddell <chris.liddell@artifex.com>
e7de6bf79a5702b79f1960af937955c7f6627e02

> Bug 693940: remove deprecated call from gs/ijs/configure.ac
> Thanks to James Cloos for pointing it out.
> No cluster differences.
> gs/ijs/configure.ac

2013-04-29 09:02:03 +0100
Ken Sharp <ken.sharp@artifex.com>
9cd48ce016f8ce490d32679dab5de3cd781f6f85

> Add high level pattern support to PCL and HPGL
> Unlike the PXL interpreter, but like XPS, the coding has been done in the
> implementation routines rather than at the interpreter level. There are two
> reasons for this; firstly the PCL interpreter already called gx_dev_set_color
> and secondly the HPGL interpreter makes extensive use of macros which weren't
> readily amenable to being altered in a way which would have allowed the
> gs_error_Remap_Color error to be propogated upwards as required.
> There are some differences with this commit, they are either very minor or
> progressions (in my opinion).
> gs/base/gsptype1.c
> gs/base/gsptype1.h
> pcl/pcdraw.c
> pcl/pcpatrn.c
> pcl/pctop.c
> pcl/pgdraw.c
> pl/plchar.c

2013-04-30 11:09:57 +0100
Ken Sharp <ken.sharp@artifex.com>
1c6f8a9297a2b16c22145a0328734ed137c02215

> pdfwrite - handle Intellifonts as type 3 fonts
> In order to deal with high level patterns used as the fill colour for an
> Intellifont, we need to handle Intellifonts as type 3 fonts, just like
> the stick font, and PCL bitmap fonts.
> This results in numerous differences; in general text is bolder at
> low resolution, the file 23-15.bin exposes a probable GS bug where the
> glyphs are clipped at higher resolutions.
> However, text can now be searched (also copy/paste), and the PDF files are
> potentially smaller due to not having to emit each glyph description every
> time it is used.
> gs/devices/vector/gdevpdtd.c
> gs/devices/vector/gdevpdte.c
> gs/devices/vector/gdevpdtf.c
> gs/devices/vector/gdevpdti.c
> gs/devices/vector/gdevpdts.c
> gs/devices/vector/gdevpdtt.c
> gs/devices/vector/gdevpdtw.c

2013-05-02 09:56:04 +0100
Ken Sharp <ken.sharp@artifex.com>
437fd175241212c5dad1f045857956f12a588774

> pdfwrite - fix some compiler warnings introduced with the palette colour fix
> pxl/pxgstate.h
> pxl/pxink.c
> pxl/pxpaint.c
> pxl/pxparse.c

2013-04-29 17:39:07 +0100
Ken Sharp <ken.sharp@artifex.com>
1c69af7f3e9830c39eb81961e90691e2ec847342

> pdfwrite - fix buffer overrun in CIDToGIDMap
> Bug #693854 "PDFA/2b conversion crashes often"
> When converting TrueType fonts into CIDFOnts, because we are creating a PDF/A
> output file, the calculated length of the CIDToGIDMap could be out by one
> as the first CID is 0.
> This later led to us writing beyond the end of the buffer, which could cause
> real problems, depending on what was overwritten.
> No differences expected.
> gs/devices/vector/gdevpdtd.c

2013-04-29 16:18:57 +0100
Ken Sharp <ken.sharp@artifex.com>
6664f4554a5d63560f94ea99214a9ad289e8e925

> Merge branch 'PCL_palette'

2013-04-26 12:57:40 +0100
Ken Sharp <ken.sharp@artifex.com>
7086f246fa047bcb9f3e9cfaacfbdae709058b91

> Allow devices to inform the PCL interpreter that it must not alter palettes
> Bug #692786 "Problem with HPGL paletted colour"
> pdfwrite (and potentially other devices) can't cope with situations where the
> interpreter alters the 'palette' (the lookup table in a /Indexed space) after
> the space has been set to be the current color space.
> However, if we unilaterally preserve the palette, it seems that this causes
> performance problems (see bug #692786.
> Here we add a new special op 'needs_invariant_palette' which allows a device
> to communicate this. We alter the PCL interpreter to inquire the device's
> requirements, and aler pdfwrite to communicate its needs.
> This results in > 300 differences with pdfwrite, all of them progressions
> gs/base/gdevdflt.c
> gs/base/gxdevsop.h
> gs/devices/vector/gdevpdfi.c
> pcl/pcpalet.c

2013-04-29 13:01:42 +0100
Ken Sharp <ken.sharp@artifex.com>
e4ce3d9147ca6a4f2bdd9a0319b4b7d606492799

> pdfwrite - add missing line from last commit
> gs/devices/vector/gdevpsdi.c

2013-04-29 11:27:14 +0100
Ken Sharp <ken.sharp@artifex.com>
efdd46d415d7b117a6c5fcadd7c40facdd0db6af

> pdfwrite - implement bicubic downsampling
> Bug #693832 "Implement bicubic image downsampling in pdfwrite"
> Bug #693917 "pdfwrite only downsamples by integer scales"
> Adopting the patch from Math supplied in Bug #693832 resolves both
> these problems. No cluster differences as the cluster doesn't test this
> feature.
> gs/devices/vector/gdevpsdi.c
> gs/devices/vector/gdevpsds.c
> gs/devices/vector/gdevpsds.h

2013-04-27 08:18:18 +0100
Chris Liddell <chris.liddell@artifex.com>
9fac58e19010c5f0772289052082d98f5d89e9a3

> Use "seekable" rather than "positionable"
> At Ray's suggestion, tweak the names from the previous commit.
> No cluster differences.
> gs/base/gdevprn.c
> gs/base/gdevprn.h
> gs/devices/gdevbmpa.c
> gs/devices/gdevdfax.c
> gs/devices/gdevsgi.c
> gs/devices/gdevtfax.c
> gs/devices/gdevtfnx.c
> gs/devices/gdevtsep.c

2013-04-25 19:21:36 +0100
Chris Liddell <chris.liddell@artifex.com>
8bf1c216211d1bf036369fd731fafd1b30eff168

> Have gdev_prn_open_printer_seekable() work sensibly
> If gdev_prn_open_printer_seekable() gets called with the seekable flag set,
> and it can't return a seekable file object, return an error, rather than
> silently ignore the flag.
> Add a generic gdev_prn_output_page_positionable() function to replace the one
> that was dedicated to the TIFF devices, and update the TIFF devices and the
> two other devices which require positionable output files to use it.
> No cluster differences.
> gs/base/gdevprn.c
> gs/base/gdevprn.h
> gs/devices/gdevdfax.c
> gs/devices/gdevsgi.c
> gs/devices/gdevtfax.c
> gs/devices/gdevtfnx.c
> gs/devices/gdevtifs.c
> gs/devices/gdevtifs.h
> gs/devices/gdevtsep.c

2013-04-25 12:01:31 +0100
Chris Liddell <chris.liddell@artifex.com>
46d3a7b65de05a0268ce969f8070064bc14913e5

> Bug 693704: Use font name to determine italic-ness
> Allow the font name analysis to override the Italic Flags field from the font
> descriptor in determining if a font is italic or oblique.
> This results it progressions (when compared to Acrobat, and several other PDF
> readers) in these cluster files:
> prfmm.pdf
> CATX2445.pdf
> fts_23_2308.pdf
> 1265_-_portable_collection.pdf
> x_-_Times_New_Roman_wrongly_substituted_regression.pdf
> gs/Resource/Init/pdf_font.ps

2013-04-25 07:48:11 +0100
Chris Liddell <chris.liddell@artifex.com>
239b3af18363a77785837af64842afe0bc433c67

> Small doc updates.
> State clearly that the TIFF devices must use a seekable file for output.
> Update the description of CropBox - largely paraphrasing the PDFRM.
> CLUSTER_UNTESTED
> gs/doc/Devices.htm
> gs/doc/Use.htm

2013-04-24 19:56:45 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
27a54e4b455c4295e5effc8bb6a392b6a44f118c

> Bug 693933: Fix division by 0 in monotony check.
> Monotony checking procedure caused division by 0 when the start and
> the end points of the interval were the same. Any function on such a
> domain is now considered monotonic.
> gs/base/gsfunc3.c

2013-04-24 12:17:54 -0700
Ray Johnston <ray.johnston@artifex.com>
ce3ca09ca7e0b489187fc9788aaa795707f17ed1

> Fix broken windows build due to missing #include "stat_.h"
> gs/base/gp_mswin.c

2013-04-24 08:27:41 +0100
Chris Liddell <chris.liddell@artifex.com>
55bbe8836df1bb8e521a6fb4e79a91d7e0702fb1

> Bug 693932 (related): generate meaningful error
> Add a gp_fseekable() function, and use it to check the file object opened in
> gdev_prn_open_printer_seekable(). If the file is not seekable, print an error
> message and return an IOerror.
> No cluster differences.
> gs/base/gp.h
> gs/base/gp_mswin.c
> gs/base/gp_os2.c
> gs/base/gp_unifs.c
> gs/base/gp_vms.c
> gs/devices/gdevtifs.c

2013-04-22 15:56:11 -0700
Michael Vrhel <michael.vrhel@artifex.com>
e67086e1d63d449900570b30e2b2e1c91ed187a4

> Initial commit of adding neutral color monitoring
> This commit adds in the command line option -dGrayDetection=true/false. When set, the special CMM procedures
> will be inserted to monitor the presence of non-neutral colors. When a non-neutral color is encountered
> no additional monitoring will be preformed. Monitoring is done during the clist writing phase and as such
> high level images are also monitored. CMYK Colors are consider non neutral if C=M=Y=0 (or very close). RGB
> colors are considered neutral if R=G=B or very close and CIELAB colors are considered neutral if a=128 and b=128
> or very close. A fuzzy range can be set for how close we need to be via defines in the code. The
> current values were set based upon using images that were created to be monochrome in Photoshop using ICC
> profiles. Testing for this was performed for a variety of image types. The remaining part of this project,
> which relates to bug number 693583 is to do something useful with the presence of monochrome only data during
> the clist playback phase. The values pageneutralcolor = true and graydetection, which are member variables in
> cmm_dev_profile_t, during clist playback will indicate that the page is neutral. Note that the clist playback
> device should set pageneutralcolor = false during the actual playback to avoid continued monitoring of
> high level image data, which would occur as the data is pushed through the CMM. graydetection is the
> device parameter and as such, pageneutralcolor only has meaning when graydetection = true.
> gs/base/gdevp14.c
> gs/base/gdevp14.h
> gs/base/gscms.h
> gs/base/gsdparam.c
> gs/base/gsequivc.c
> gs/base/gsicc_cache.c
> gs/base/gsicc_cache.h
> gs/base/gsicc_cms.h
> gs/base/gsicc_lcms2.c
> gs/base/gsicc_manage.c
> gs/base/gsicc_monitorcm.c
> gs/base/gsicc_nocm.c
> gs/base/gsicc_replacecm.c
> gs/base/gxclimag.c
> gs/base/gximage.c
> gs/base/gxiparam.h
> gs/base/gxipixel.c
> gs/base/lib.mak

2013-04-23 00:54:24 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
07abd0c0bbddef1eed84969e9d8b7ba5f548d0d9

> Bug 687604: Reject out-of-bounds access to cvt table.
> Revert the patch b550e8c460daa0647fd1f4ce63ae3c73edc75a5c because
> it is not needed now, but it causes SEGV when cvt table is missing.
> gs/base/ttinterp.c

2013-04-22 21:28:57 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
6f51cd7b9d5c2e5185eec30579238bb14863a5e5

> Bug 693930: Accept and ignore null entries in the page tree.
> gs/Resource/Init/pdf_main.ps

2013-04-21 19:20:12 -0600
Henry Stiles <henry.stiles@artifex.com>
11638a77454ace993bf106dab3cd7e182bf1e250

> Fix 693836, valgrinds reports read of uninitialized value.
> The loop accessed memory past the end of each source line. This did
> not result in an error because we would exit the loop before the data
> was used, but nonetheless it is an invalid read outside the memory
> allocation so we rearrange the loop conditions to avoid it.
> gs/base/gdevm24.c

2013-04-21 11:29:08 +0100
Chris Liddell <chris.liddell@artifex.com>
a63c1486c770a810a6cfa24ab397ee3c3c798816

> Bug 687604: work around another broken TT font
> Fallback to rendering unhinted if Freetype returns an Invalid_Reference error.
> No cluster differences.
> gs/base/fapi_ft.c

2013-04-19 17:29:04 +0100
Ken Sharp <ken.sharp@artifex.com>
5ec87a6d6971f059c4135af3fddd17b34f20c7ae

> pdfwrite - actually assign the structure members to 0
> gs/devices/vector/gdevpdte.c

2013-04-19 14:41:21 +0100
Ken Sharp <ken.sharp@artifex.com>
9155d0f3ee7bb9ffc6cb63b21402b5219c7335f2

> pdfwrite - initialise some structure members to pacify valgrind
> pdf_glyph_widths already sets these to zero, so we only need to bother if
> we aren't using pdf_glyph_widths.
> No differences expected.
> gs/devices/vector/gdevpdte.c

2013-04-19 09:35:18 +0100
Chris Liddell <chris.liddell@artifex.com>
0d3f3ab6ceeaf2b95f9318845bce770cf44efad7

> Bug 693925: Add some checking for ufst configure option
> The two configure scripts now check for the existence of the specified UFST
> directory, and for the existence of fapiufst.mak in that directory.
> No cluster differences.
> configure.ac
> gs/configure.ac

2013-04-19 10:03:45 +0100
Ken Sharp <ken.sharp@artifex.com>
7e62f84b93a517ac43ebb5d26912a0786b37916e

> pdfwrite - fix transparency preservation with PDF/A-2
> An oversight with the introduction of PDF/A-2 could lead to transparency
> not being preserved, because we tested only the request for PDF/A without
> checking the level required.
> No Differences expected, not tested by the cluster.
> gs/devices/vector/gdevpdft.c

2013-04-19 00:13:18 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
4b0ccdcd37d8bf5924bd9572994535c5a1b20169

> Bug 693869: work around errors in dash offset calculation
> Make sure that the offsed doesn't exceed the total length of
> the dash pattern. Fix out-of-bounds access and a corresponding
> Valgrind warning.
> gs/base/gsline.c

2013-04-18 11:04:49 -0600
Henry Stiles <henry.stiles@artifex.com>
52d113e470047ea70485de785bc9a3b68731127c

> Fix typo in SVG output device (bug #693922) by Shailesh Mistry.
> gs/devices/vector/gdevsvg.c

2013-04-18 09:06:08 +0100
Ken Sharp <ken.sharp@artifex.com>
f521500bdc2d39ad5f2caf91b3630a1370a08a5f

> Add high level pattern support to the PXL interpreter
> Also, fix a possible Seg fault in pdfwrite, which was uncovered by this
> work.
> As might be expected this commit does introduce a fairly large number of
> differences in the regression tests. I've looked at them all and I'm happy
> that they are minor differences rather than faults.
> gs/devices/vector/gdevpdfb.c
> pxl/pxfont.c
> pxl/pxgstate.c
> pxl/pximage.c
> pxl/pxink.c
> pxl/pxl.mak
> pxl/pxpaint.c
> pxl/pxparse.c

2013-04-18 08:34:41 +0100
Chris Liddell <chris.liddell@artifex.com>
23e6bd304db08011b67b7f45dfcf23885fc0c8a3

> Bug 693921: "refresh" pointer when rendering glyph
> Before we call into the gs_fapi_do_char(), refresh the context pointer in the
> FAPI server data - in case the context has been moved by a GC since the font
> was created.
> No cluster differences.
> gs/psi/zfapi.c

2013-04-17 17:46:16 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
ece14831a4301dd0291184e1f27729b73d6f350b

> Bug 693919: Replace malformed numbers with 0.
> Scan BBox elements and replace non-numbers with 0. Our PDF tokenizer
> usually assumes that malformed numerals are names.
> gs/Resource/Init/pdf_main.ps

2013-04-17 14:30:10 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
d9a327b4e24043fb153996fdd18a367483d13521

> Bug 693920: Add missing dereference of an indirect object.
> gs/Resource/Init/pdf_draw.ps

2013-04-17 12:29:11 +0100
Chris Liddell <chris.liddell@artifex.com>
4dfe603dc49aeee09457ea7a0734d7484e0467ea

> Add tiff-config directory to .gitignore.
> CLUSTER_UNTESTED
> .gitignore

2013-04-15 19:10:25 +0100
Chris Liddell <chris.liddell@artifex.com>
b1254130df0da4c311e9761b5784a12c6dad1dc9

> Have tiff configure run in separate directory.
> Run libtiff's configure script in a separate directory to prevent poluting
> libtiff's source directory.
> the Ghostscript distclean target has been revised to remove the tiff config
> directory, and the ghostpdl makefile has new distclean and maintainer-clean
> targets.
> No cluster differences.
> Makefile
> common/msvc_top.mak
> configure.ac
> gs/Makefile.in
> gs/base/gs.mak
> gs/base/lcupsi.mak
> gs/base/tiff.mak
> gs/base/unix-gcc.mak
> gs/base/unixansi.mak
> gs/configure.ac
> gs/psi/msvc.mak
> gs/toolbin/localcluster/clusterpush.pl
> main/pcl6_gcc.mak
> main/pcl6_msvc.mak
> svg/svg_msvc.mak
> xps/xps_msvc.mak

2013-04-17 09:23:19 +0100
Chris Liddell <chris.liddell@artifex.com>
1c006433024cb996022db86a7e7ec59f103e8efb

> Remove the deprecated macos-fw.mak
> CLUSTER_UNTESTED
> gs/base/macos-fw.mak
> gs/doc/Develop.htm

2013-04-17 09:24:22 +0100
Chris Liddell <chris.liddell@artifex.com>
28acb04f77ba58b1507c32d52402e2ff8eaa2e40

> Raise the default VMThreshold from 1Mb to 8Mb
> This seems like a fair change based on modern hardware and, in particular
> modern PDF files. In some cases this results in a significant speed
> improvement. It may increase overall memory usage, but testing suggests only
> by an insignificant amount in the vast majority of cases.
> No cluster differences.
> gs/psi/zvmem2.c

2013-04-15 09:38:56 +0100
Chris Liddell <chris.liddell@artifex.com>
407cc61e87b0fd9d44d72ca740af7d3c85dee78d

> "starting_arg_file" should only apply once.
> The "starting_arg_file == true" setting should apply to the *first* call to
> lib_file_open() in the context of a given call to runarg(). Previously, it
> remained set for the entire duration of the runarg() call, resulting in the
> current directory being searched for any resource files required by the job.
> We also want "starting_arg_file == false" when runarg() is called to execute
> Postscript from a buffer, rather than a file argument.
> There is a very small chance this may cause problems with some strange scripts
> or utilities, but I have been unable to prompt such an issue. If one does arise,
> we may have rethink this entirely.
> No cluster differences.
> gs/psi/imainarg.c
> gs/psi/zfile.c

2013-04-13 23:21:50 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
3648ad1d3d1f47df3e4a6e36ff5160e2bff25079

> Remove spurious address-of operator.
> gs/base/gscscie.c

2013-04-13 01:36:44 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
ed31bf693b457ecd13cfa4fc67f12288241448ce

> Bug 691389: Pacify Valgrind; zero image flip buffer.
> When the image has less than 8 scanlines, flipping includes the wild
> end of the buffer and causes warnings in memflip8x8().
> gs/base/gxifast.c

2013-04-10 20:13:05 +0100
Robin Watts <robin.watts@artifex.com>
cd414f3582ef95a3b0fd941e62370053126cba5c

> Avoid potential out of bounds memory accesses
> In image_render_mono we have code that skips forwards multiple
> pixels at a time without checking for hitting the end of the
> buffer. Fix that here.
> gs/base/gximono.c

2013-03-24 11:23:01 +0000
Chris Liddell <chris.liddell@artifex.com>
ecc7a199e9307475c37fea0c44d24b85df814ead

> Bug 693488: Improved glyph name aliasing.
> Implement a more flexible approach to glyph name aliasing which handles all the
> names in the Adobe Glyph List.
> Thanks to John Wehle ( john@feith.com ) for this implementation.
> For the time being, you can use "-dUSEOLDGLYPHALIASING" to revert to the old
> code - assuming all goes well, that option will be removed for the release
> following 9.09.
> No cluster differences.
> gs/Resource/Init/gs_ttf.ps
> gs/Resource/Init/gs_type1.ps

2013-04-11 17:22:11 +0100
Ken Sharp <ken.sharp@artifex.com>
4c27c7d63acbf4500eab8d056541535ed5010b5c

> ps2write - do not emit CIEBased spaces as ICCBased for PostScript
> This was an oversight when I was trying to preserve CIEBased colour spaces,
> it turns out that its not possible to preserve them, and I accidentally left
> the code emitting them as ICCBased, which doesn't work in PostScript.
> We now fall back to the old approach, in future we hope to use LCMS2 to
> create a CIEBased space from the ICCBased profile for us.
> No differences expected, code not enabled by default
> gs/devices/vector/gdevpdfc.c

2013-04-02 12:26:09 +0100
Chris Liddell <chris.liddell@artifex.com>
9ff3e23fcf1c73e83e4bbb797b9033c7a25bf255

> Bug 693804: (valgrind) initialize gs_fapi_raster
> It's easiest to set the entire struct to zeros, since we need to initalize
> nearly the entire structure anyway, before passing to the scaler/renderer.
> No cluster differences
> gs/base/gxfapi.c

2013-04-02 17:23:24 +0100
Chris Liddell <chris.liddell@artifex.com>
55c01c51ac53d244affde7b683f1f4cff24bcc46

> Bug 693785: (valgrind) make gx_hld_saved_color_equal() do explicit checks
> gx_hld_saved_color_equal() originally did a simple memcmp(), but due to padding
> and GC considerations, that isn't reliable, so it needs to compare the contents
> of the structure explicitly.
> This does cause some differences in the PCL cluster tests with pdfwrite.
> gs/base/gxhldevc.c
> gs/base/lib.mak

2013-04-03 16:42:24 +0100
Chris Liddell <chris.liddell@artifex.com>
312d3c7655e2484e27160478e3120796cf9bbe10

> Bug 693736: (valgrind) rejig a call to a function pointer
> This is just a rejig to a functionally equivalent form that valgrind seems happier with.
> It makes no real difference, but reduces the valgrind "noise" at no expense.
> No cluster differences.
> gs/psi/igc.c

2013-04-10 16:11:05 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
d73d2d365efc7331bf1dbfe70e427e8ead829778

> Bug 693738: Trap bit run search
> Fix a valgrind warning. Create a termination zone filled with
> alternating bit pattern to guarantee that a search for a bit run
> ends within the termination zone.
> gs/base/scfd.c

2013-04-08 22:42:24 -0700
Ray Johnston <ray.johnston@artifex.com>
a3225b70cb1b92ca0f657d99b3bc496e6046fc39

> Fix valgrind issue, bug 693735. image_render_mono condition using UMR.
> The psrc scanning loop did not stop at the end of the data in some
> cases. Since data past the image would tend to be variable, this
> would usually stop scanning fairly soon and the 'fit_' macro logic
> in fill/copy routines would make sure to limit the painting to a
> valid area. Strange that this didn't show up in image artifacts.
> gs/base/gximono.c

2013-04-10 00:56:15 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
897c36aa8cd754448bab5b712e48d46e2b117478

> Bug 693798: Fix buffer overrun.
> When jbig2dec detects that a run of pixels exceeds the image width,
> it clamps the beginning and end of the run to the image width+1.
> Probably, this is done to make runs that are entirely outside of the
> image to leave no marks. This patch adds 1 byte to the image
> buffer to ensure that writing 1 byte beyond the image line is valid.
> gs/jbig2dec/jbig2_image.c

2013-04-09 15:15:00 +0100
Ken Sharp <ken.sharp@artifex.com>
5f5524b1f2ab76aff70b2b4a896b9474bdfb9501

> pdfwrite - prevent rounding errors in TrueType widths
> See Bug #693825
> Rounding errors converting TrueType widths into PostScript/PDF led to us
> emitting lots of tiny glyph movements. These were visually imperceptible
> but led to larger than necessary output, because of all the tiny shifts.
> This commit fixes the widths from TrueType fonts to the nearest integer
> which makes it much more likely they will match the entries in the /W or
> /Widths arrays, and thus not result in tiny movements.
> The file in Bug #698325 is 5% smaller with this change, and the output PDF
> file does actually match the original more closely (when using a high zoom
> factor and careful inspection)
> This does (unsurprisingly) cause a lot of differences in the test suite,
> but I've looked at all of them and can see no definite problems. The
> differences are pretty much single pixel shifts and this can sometimes
> cause low resolution output to be slightly better, or slightly worse.
> gs/devices/vector/gdevpdte.c

2013-04-09 08:33:01 +0100
Ken Sharp <ken.sharp@artifex.com>
f7567c53867f01e9dd33a1f882bb489dc765b869

> pdfwrite - correct tracking of current point with word spcaing
> Bug #693285 "gs adds spaces and breaks formatting of original pdf file"
> This one is quite subtle and caused by a number of interacting issues.
> Firstly the design grid conversion of TrueType fonts can lead to TT CIDFonts
> ending up with very slightly different widths from the font to the widths in
> the /W array (rounding errors). When emitting text we then use the TJ operator
> and emit tiny movements for each glyph.
> The second part then, is the limit we have of 50 movements per TJ operation.
> There's no indication why we have this limit but I assume its some ancient
> version of Acrobat. When we get to 50 moves we close the current line of text
> and begin a new one.
> The third part is that, in order to start the new line from the correct x offset
> (so it lines up properly with the previous line), we keep a running track of
> the current position and use that to tell us where to start the new line.
> This value was getting the word spacing value applied to it whenever the
> current character was a space (0x20). However, we only apply the word spacing
> to *single* byte encodings in PDF (unlike PostScript) and the font in this
> particular file doesn't have a single byte range.
> To fix this we need to know if the text came from a (a)widthshow operation
> from PDF, or from PostScript. Fortunately the text enumerator already has
> a 'single_byte_space' member which tells us this. If it was from PDF we then
> need to check if the character encoded used 1 byte or more than one, and
> not apply the word spacing if it used more than 1. To this end we now pass
> in the number of bytes to process_text_modify_width.
> This change exhibits progressions in fts_20_2001.pdf and fts_22_2202.pdf
> gs/devices/vector/gdevpdtc.c
> gs/devices/vector/gdevpdte.c
> gs/devices/vector/gdevpdtt.h

2013-04-09 09:12:01 +0100
Chris Liddell <chris.liddell@artifex.com>
496d8d3b8ea3d560dc260b1d03d9ed45b38e6960

> Bug 693842: Fix a typo in gp_vms.c
> There was a "=" instead of "==" mistake in the file name validation code.
> Thanks to jond666@hotmail.com for pointing it out.
> CLUSTER_UNTESTED
> gs/base/gp_vms.c

2013-04-09 09:05:59 +0100
Chris Liddell <chris.liddell@artifex.com>
17bc8825debb794fc83f832b96da1ef9eead6aa4

> Bug 693846: Fix configure inclusion of gdevjbig2.dev
> There was an error in the configure so that we ended up using "jbig2.dev" in
> both the FEATURE_DEVS and DEVICE_DEVS lists.
> It now, correctly, uses gdevjbig2.dev in the DEVICE_DEVS list.
> No cluster differences.
> gs/configure.ac

2013-04-05 12:24:34 -0600
Henry Stiles <henry.stiles@artifex.com>
a4ae7c831da7e113665ae53e02b215c62bc3dbbd

> Fix 693841, the symbol set parameter could be read uninitialized.
> pxl/pxfont.c

2013-04-05 09:52:35 -0600
Henry Stiles <henry.stiles@artifex.com>
002551b7baa1e6e0a10670672d34870c3e229925

> Read the old page size from the device, not from PCL's state.
> The current paper selecting design could already have the new
> requested page size in PCL's state at this point in the code; it was
> possible to miss selecting a new paper size even though there was a
> paper size change.
> pcl/pcpage.c

2013-04-05 09:48:36 -0600
Henry Stiles <henry.stiles@artifex.com>
c77af98a0ff3d54ce52fb043149cef0a1b83e311

> More lenient interpretation of the PJL language variable.
> Accept any language variable string that contains the substring "GL"
> to indicate the job should be processed in RTL/HPGL-2 mode.
> pcl/pctop.c

2013-04-05 09:46:03 -0600
Henry Stiles <henry.stiles@artifex.com>
2892a755b3cc1e56f859046154f249afde1dcca0

> Initialize PCL completely before XL Passthrough.
> pxl/pxpthr.c

2013-04-02 17:12:04 -0600
Henry Stiles <henry.stiles@artifex.com>
86c33715ecf80e58ae4bde341820a6c76b23c288

> Fix memory corruption problem with HPGL/2 page sizes.
> Setting a page size in the HPGL/2 code depended on memory in a local
> stack frame. This problem was introduced when custom page size
> support was added to PCL which resulted in reorganizing the paper type
> set up. Unfortunately HPGL/2 - RTL mode was not updated to use the
> new paper setup when the PCL change was made.
> pcl/pcpage.c
> pcl/pcpage.h
> pcl/pgconfig.c

2013-04-04 15:47:47 +0100
Robin Watts <Robin.Watts@artifex.com>
87b4d9c7abb36040079e099600cd31a5917be31d

> Remove unneeded tests from ENABLE_VALGRIND macros.
> Now gs_alloc_fill is called correctly, I can back out these extra
> tests.
> gs/base/gsmdebug.h

2013-04-04 15:17:03 +0100
Chris Liddell <chris.liddell@artifex.com>
673511c63137ff5cf5dddcacd7ff5f1cc9f42fd3

> Correct a mistake in the memory alloc header code.
> In the -Z@ case, I had left offsets in place for filling freed memory in
> i_resize_string() which could cause gs_alloc_fill() to be called with a
> negative length.
> No cluster differences.
> gs/base/gsalloc.c

2013-04-04 01:12:45 +0100
Robin Watts <Robin.Watts@artifex.com>
773c42ffc7e1e96c0bd99c7f577090c8b0684577

> Fix ENABLE_VALGRIND problems.
> gs_alloc_fill was having a bad interaction with
> VALGRIND_MAKE_MEM_UNDEFINED in corner cases.
> gs/base/gsmdebug.h

2013-04-02 14:45:20 +0100
Robin Watts <robin.watts@artifex.com>
2e9a498db41d0d601ab736687d332b2ab3de2a54

> Add valgrind.h dependencies to lib.mak to avoid warnings.
> gs/base/lib.mak

2013-03-28 07:53:23 +0000
Chris Liddell <chris.liddell@artifex.com>
5403b7384b203c6b462f8ed3190b7962c929769c

> Add an ID to memory allocations.
> This is to aid following objects through GC.
> This is fairly straight forward with gs_struct_.... type allocations where
> there is a memory manager header structure associated with the allocation,
> so the ID is added to that.
> But so called "string" allocations (i_alloc_string() and co) are more tricky
> because these have no header, so these have the ID "tacked on" at the beginning
> of the memory allocation. This means that the memory manager and the garbage
> collector need to "just know" that the extra bytes exist.
> The assigning and incrementing of the ID variable (normally) on happen in a
> debug build. The ID variable itself can be left out by adding:
> -DGS_USE_MEMORY_HEADER_ID=0
> (or equivalent) to the compiler command line.
> Finally, in a debug build, there is a get_mem_hdr_id() convenience function
> you can call from a debugger - it takes a pointer to block of memory, and
> returns the ID assigned to the allocation. Obviously, if the function is called
> on memory automatically allocaed on the stack, it will probably cause bad
> things to happen.
> No cluster differences.
> gs/base/gsalloc.c
> gs/base/gxobj.h
> gs/psi/igcstr.c

2013-04-02 03:47:24 -0700
Robin Watts <robin@peeves.(none)>
693c516ad22bb79d7c8c85329ff6a53dc82505fc

> Memento: Improve interaction with valgrind.
> Ensure that blocks headers are correctly marked accessible/
> unaccessible.
> gs/base/memento.c

2013-04-02 11:14:41 +0100
Ken Sharp <ken.sharp@artifex.com>
b0264dc9764935e548042597ca5d3c08bc513d31

> pdfwrite - initialise a return code
> Spotted by scan-build, the return code is uninitialised when both stream
> and dictionary have previously been hashed. This would not normally cause a
> problem, but its best to be safe.
> No differences expected.
> gs/devices/vector/gdevpdfo.c

2013-04-01 16:57:37 -0700
Robin Watts <robin@peeves.(none)>
9182dfdce82310e96fbb7b92759dcc913e0f6a2e

> Update valgrind.h to include helgrind header too.
> Cope with the version of helgrind being too old that it doesn't
> provide the required macros and causes missing symbol errors.
> gs/base/gsinit.c
> gs/base/gxclfile.c
> gs/base/gxclist.c
> gs/base/gxclmem.c
> gs/base/valgrind.h
> gs/psi/imain.c

2013-04-01 10:32:28 -0700
Robin Watts <robin@peeves.(none)>
4e4883fdd27201e35b93e9fbdbe5d1f2380a030b

> Memory squeezing: Unchecked error codes.
> Fix unchecked error codes in gs_output_page.
> gs/base/gsdevice.c

2013-04-01 09:51:40 -0700
Robin Watts <robin@peeves.(none)>
952405f72db6ba9f706e75f7cbf66193a575ec98

> Bug 693824: Valgrind problems in interpolated images.
> The first of the valgrind problems reported here is a false
> positive; when scaling just a subsection of an image we
> scale extra 'support' pixels. Due to the way this works we
> end up scaling a few extra lines/columns around the rectangle
> we actually need. Some of the input values to these extra
> lines are not copied in, hence we see valgrind complaining
> about uninitialised values.
> We fix this with some PACIFY_VALGRIND code to memset the
> input buffers to 0.
> This commit also fixes valgrind errors seen later due to
> us trying to color convert color values outside of the
> active region; we fix this by restricting the area we
> color convert. This will give speedups in some cases.
> gs/base/gxiscale.c
> gs/base/siscale.c

2013-04-01 08:31:11 -0600
Henry Stiles <henry.stiles@artifex.com>
07c3453ee6545e660fe1f7215b0ba5f540b7cd7b

> Change ownership of JBIG2 to Alex.
> CLUSTER_UNTESTED
> doc/who_owns_what.txt

2013-04-01 06:20:14 -0700
Robin Watts <robin@peeves.(none)>
050745afeddbaf506ab4dd92661d583ba6e3eb06

> Valgrind: Fix spurious warnings in gc
> The Ghostscript object headers have a union of bitfields; these are
> arranged so that they are all of the form 1 bit, then n-1 bits
> (where n is a power of 2), so they pad nicely to a nice size.
> Specifically they are designed to work like this (as far as I can
> make out) to allow the 'alone' bit to be preserved during gcs
> when the n-1 bit fields are used. Valgrind, I think, finds this
> problematic.
> The fix in this commit is simply to initialise both the alone bit
> and the padding bits at the same time (any even halfway decent
> compiler should combine these into a single byte write, so we
> should actually find this new safer code is faster than the previous
> single bit initing code). This is safe because the other unions
> are only used during gc.
> Cluster testing shows no differences, and local valgrind runs
> appear cleaner.
> gs/base/gsalloc.c
> gs/base/gxobj.h
> gs/psi/igcref.c
> gs/psi/isave.c

2013-03-31 04:07:53 -0700
Robin Watts <robin@peeves.(none)>
b319291a7a57de7344122269ae56deb65121de60

> Memory squeezing fix: zsave: Fix SEGV
> When freeing saved spaces due to an allocation failure, unlink the
> space from the linked list of saved ones to prevent gc SEGV later.
> gs/psi/isave.c

2013-03-30 04:26:01 -0700
Robin Watts <robin@peeves.(none)>
fe31fceb7870b24bcf9c5b477f76943abacce75f

> Memory Squeezing: crash in gc after zsave.
> Ensure that the save structure is set up enough to be safely gc'd
> on allocation.
> gs/psi/isave.c
> gs/psi/zvmem.c

2013-03-30 03:34:04 -0700
Robin Watts <robin@peeves.(none)>
d88779e3579db3c9c134ec7c5ee54e7ab4579399

> Memory Squeezing: gsicc_manage.c: Check for allocation failures
> In faviour places we allocate pname, and then use it without
> checking. Simply add checks.
> gs/base/gsicc_manage.c

2013-03-30 09:26:53 +0000
Ken Sharp <ken.sharp@artifex.com>
97d4e9f31bb0f5d1f8feb97106fc5879bb9a4fcb

> pdfwrite - ensure a variable is initialised
> I can't see a way that this could cause the valgrind complaint in bug
> #693813, but its the only variable in the offending line which is not
> explicitly initialised. So initialise it here just in case.
> No differences expected.
> gs/devices/vector/gdevpdfc.c

2013-03-29 17:43:14 -0700
Robin Watts <robin@peeves.(none)>
f23d8aca44eee8ab1e289b350c968b074b8bec76

> Memory Squeezing: JPEG compression; avoid double free.
> The JPEG compression stream state calls gs_jpeg_destroy, but this may be
> called earlier. If this does get called earlier, ensure that we leave the
> stream in a state where it won't access freed memory.
> gs/devices/vector/gdevpsdu.c

2013-03-29 14:16:38 -0600
Henry Stiles <henry.stiles@artifex.com>
852e5451e741515551edd55916a3cf49a5a2540e

> Fix bug 693576 - bad pxl file generated.
> It was possible for the XL driver to produce XL drawing commands
> without setting the color space in advance. Thanks to Hin-Tak Leung
> for the fix.
> gs/devices/vector/gdevpx.c

2013-03-29 11:46:35 -0700
Robin Watts <robin@peeves.(none)>
00ccf0ce1304f3f6a9493138f2fb0cb00f3326f9

> Memory squeezing: JPEG encoding stream release
> When destroying a JPEG encoding stream, we assume that the setup got
> far enough to have allocated a jmpbuf and a compression struct. Add
> some checks so we cope if this is not the case.
> gs/base/sdcte.c
> gs/base/sjpegc.c

2013-03-29 11:14:29 -0700
Robin Watts <robin@peeves.(none)>
a68c6641b8b576c88c497d8089b17bc7ec32d383

> Memory squeezing: LCMS2: BuildGrayInputMatrixPipeline leak
> Avoid leak in allocation failure case.
> gs/lcms2/src/cmsio1.c

2013-03-29 09:31:07 -0700
Robin Watts <robin@peeves.(none)>
31f437e09d443e1f1ae78f4f909728b45d550695

> Memory Squeezing: LCMS2: CLUTElemDup
> Check for allocation failures and tidy up if found.
> gs/lcms2/src/cmslut.c

2013-03-29 10:01:18 -0600
Henry Stiles <henry.stiles@artifex.com>
ebf32c26d8224ab7c81766c0d516986fd1ce4027

> Fix more gnu indent unwanted side effects.
> We still have a bit more to do but this fixes the most egregious
> problems.
> pcl/pccsbase.c
> pcl/pcht.c
> pcl/pcstatus.c
> pcl/pcsymbol.c
> pcl/pcsymbol.h
> pcl/pctext.c
> pcl/pctop.c
> pcl/pgchar.c
> pcl/pgcolor.c
> pcl/pgconfig.c
> pcl/pgframe.c
> pcl/pggeom.c
> pcl/pglabel.c
> pcl/pglfill.c
> pcl/pgparse.c
> pcl/pgpoly.c
> pcl/pgvector.c
> pcl/rtmisc.c
> pcl/rtrstcmp.c
> pl/pjparse.c
> pl/pjparsei.c
> pl/plftable.h
> pl/plmain.c
> pl/plplatfps.c
> pl/pltop.c
> pxl/pxerrors.c
> pxl/pxfont.c
> pxl/pxgstate.c
> pxl/pxparse.c
> pxl/pxptable.c
> pxl/pxsessio.c
> pxl/pxstate.c

2013-03-29 08:29:31 -0700
Robin Watts <robin@peeves.(none)>
0250740ec53e8df3f2fcfd96a725574996256524

> Memory squeezing fix: LCMS2: avoid AllocateToneCurveStruct returning partial built struct.
> Simply add an extra check on the last allocation.
> gs/lcms2/src/cmsgamma.c

2013-03-29 08:22:34 -0700
Robin Watts <robin@peeves.(none)>
321c5a324977410d7fac84be174453460a3210a9

> Memory squeezing: More LCMS2 fixes.
> Fix some broken error code, add some checking where it was missing, and
> fix a potential leak.
> gs/lcms2/src/cmscnvrt.c
> gs/lcms2/src/cmslut.c

2013-03-29 12:43:33 +0000
Robin Watts <robin.watts@artifex.com>
44f807320c741d07a38bc565752160ecb8c6f71b

> Memory squeezing fix: lcms2 cmsPipeline construction
> When creating a new pipeline, lcms would often try to allocate a stage
> and pass it to cmsPipelineInsertStage without checking whether the
> allocation succeeded. cmsPipelineInsertStage would then assert (or crash)
> if it had not.
> The fix here is to change cmsPipelineInsertStage to check and return
> an error value. All calling code is then checked to test this return
> value and cope.
> gs/base/gsicc_cache.c
> gs/lcms2/include/lcms2.h
> gs/lcms2/src/cmscnvrt.c
> gs/lcms2/src/cmsgmt.c
> gs/lcms2/src/cmsio1.c
> gs/lcms2/src/cmslut.c
> gs/lcms2/src/cmsopt.c
> gs/lcms2/src/cmstypes.c
> gs/lcms2/src/cmsvirt.c

2013-03-29 10:23:50 +0000
Ken Sharp <ken.sharp@artifex.com>
8591cc53337147e77e4249a007df12cd17319d08

> pdfwrite - initialise structure member 'stream_md5_valid
> Bugs #693759, #693760, #693761
> Found by valgrind, there were conditions under which the member would not
> be initialised before we tested it, initialising it to 0 ensures this can't
> happen.
> In practice this is unlikely to ever cause a problem, but its best to be safe
> as we could conceivably attempt to access invalid memory locations if this
> member isn't initialised.
> No differences expected.
> gs/devices/vector/gdevpdfo.c

2013-03-28 17:51:17 -0700
Robin Watts <robin@peeves.(none)>
1ef00832581e1167dd3fd33ab499bcd1d895b218

> Memory squeezing bug: lcms2 MatrixElemTypeFree
> Destructors should cope with NULL.
> gs/lcms2/src/cmslut.c

2013-03-28 17:26:36 -0700
Robin Watts <robin@peeves.(none)>
47d384ef4ef6a57b346a05f320a06b08309ed2d9

> Memory squeezing fix: gsicc_get_link_profile
> Check the return from gsicc_get_profile_handle_buffer for validity
> before using it.
> gs/base/gsicc_cache.c

2013-03-28 17:18:11 -0700
Robin Watts <robin@peeves.(none)>
3dc5a28f2c7fc587f4207a593d2aa32d9565d4c9

> Memory squeezing fix: gsicc_alloc_link
> Ensure that the gsicc_link_t has a valid wait pointer so that its
> destructor can work safely in the event of the wait semaphore failing
> to allocate.
> gs/base/gsicc_cache.c

2013-03-28 21:12:18 +0000
Robin Watts <robin.watts@artifex.com>
b1d518660381c8cec7f603ef05eea85e1d683817

> Another memory squeeze fix.
> Avoid SEGV in gsicc_alloc_link_entry and callers.
> gs/base/gsicc_cache.c
> gs/base/gsicc_manage.c
> gs/base/gsicc_nocm.c
> gs/base/gsicc_replacecm.c

2013-03-28 14:25:53 -0600
Henry Stiles <henry.stiles@artifex.com>
c8e63f3b0096aac611da379b57590dca9c549aca

> Fix 693730, portion of output missing resulting from type overflow.
> PCL was storing image's source width and height in unsigned short
> integers which is not sufficient for very large HPGL/RTL plots.
> pcl/rtraster.c

2013-03-28 19:42:34 +0000
Robin Watts <robin.watts@artifex.com>
865db37918a99bdaea8825cb1173389c6541b318

> Another memory squeezing fix.
> Check allocations for failures. Free objects in the cleanup path.
> gs/base/gsicc_manage.c

2013-03-28 19:16:56 +0000
Robin Watts <robin.watts@artifex.com>
045235372355a640bdf637a6065bfc8597e00b8e

> More memory squeezing fixes.
> Fix unchecked allocations, and ensure functions are capable of
> distinguishing failed allocations from failing to finish normally
> for some other reason.
> gs/base/gsicc_cache.c
> gs/base/gsicc_manage.c

2013-03-28 17:26:44 +0000
Robin Watts <robin.watts@artifex.com>
fd3220b62484c434a7c64a4f1382a0d05c82c664

> Memory squeezing fixes.
> Unchecked allocations and return codes in the parameter handling.
> gs/base/gsdparam.c
> gs/base/gsicc_manage.c

2013-03-28 13:53:51 +0000
Ken Sharp <ken.sharp@artifex.com>
120c7069563bc01b5d23d2632803607248c5fca4

> pdfwrite fix previous commit
> Commit 0069ae367e670a80b35d9d333c99acd71dc94108 had a 'typo' and used
> the wrong member of a structure to append a hash. Because the member was
> too small this caused memory corruption and later crashes.
> Of course this only exhibits with the same hand-crafted test file....
> No differences expected
> gs/devices/vector/gdevpdfo.c

2013-03-28 13:09:11 +0000
Ken Sharp <ken.sharp@artifex.com>
0069ae367e670a80b35d9d333c99acd71dc94108

> pdfwrite - fix stream MD5 hashing
> Objects in pdfwrite use an MD5 hash to check for equality. The hash is lazily
> created, and stored for later reuse.
> The stream object hashing wasn't adding the hash of the dictionary associated
> with the stream to the hash of the stream contents. This meant that 2 streams
> with the same data, but different associated dictionaries, could be wrongly
> identified as equal.
> In practice this condition is likely to be extremely rare, it was detected
> while working on the colour code and was caused by using a hand-crafted
> PostScript file which reused many components when constructing multiple
> colour spaces.
> No differences expected
> gs/devices/vector/gdevpdfo.c

2013-03-27 17:34:41 -0700
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
0e58a662c5eaa811eafa512e9cc97ae5e1303351

> Add non-redudannt (nr) option to clusterpush.pl
> gs/toolbin/localcluster/clusterpush.pl

2013-03-27 16:34:39 -0600
Henry Stiles <henry.stiles@artifex.com>
76f9208424f41e4177cda4a468af1b0bb6a5e166

> Preliminary parsing code for the PXL VendorUnique operator.
> Some lower end HP color laser printers use an undocumented diminutive
> PXL-like language based on the VendorUnique operator. This commit
> fleshes out enough of the parsing to get through the PXL in the test
> file attached to 693661 without a syntax error. We've not done
> anything to implement VendorUnique commands beyond parsing.
> gs/base/gdevpxat.h
> pxl/pxparse.c
> pxl/pxptable.c
> pxl/pxsessio.c

2013-03-27 20:48:31 +0000
Robin Watts <robin.watts@artifex.com>
5f148d93b1c954f28fead816acb5fe7131797cf4

> Memory squeezing fix
> If ialloc_init fails part way through, we attempt to free the allocated
> objects, but we do so incorrectly as the object we get passed back is
> actually internal to the allocation that was made (and there were actually
> multiple allocations).
> We add a function to do this properly, together with a stern warning
> that this should only be used for allocation error cleanup.
> gs/base/gsalloc.c
> gs/base/gsalloc.h
> gs/psi/ialloc.c

2013-03-27 09:20:42 -0700
Robin Watts <robin@peeves.(none)>
3f07b338211b112f8af3e95dcff87269e770a311

> Another memory squeeze fix.
> Ensure enumerator is initialised enough to survive gc in case
> of later failures.
> gs/base/gp_unifs.c
> gs/psi/imain.c

2013-03-27 14:46:06 +0000
Robin Watts <robin.watts@artifex.com>
2ed2393f5a82952ba92e543a43cb39dd44c3050b

> Memory squeezing fix
> Check for allocation failure.
> gs/psi/zcontext.c

2013-03-27 14:34:33 +0000
Robin Watts <robin.watts@artifex.com>
6f7940e28090a0f4c850e7adad4554c79fb01fb8

> More memory squeezing fixes
> Clear allocated structures so they can be destructed safely in the
> event of later failures.
> gs/base/gsfont.c
> gs/base/gxccman.c

2013-03-27 14:07:17 +0000
Robin Watts <robin.watts@artifex.com>
0466008b327a5b16a051e234e4725ebfa84912f6

> Another memory squeezing problem.
> Check the result of the allocation in gx_cache_char_init before
> using it.
> gs/base/gxccman.c
> gs/base/gxfcache.h
> gs/psi/imain.c

2013-03-27 10:00:27 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
3d94f55fdc7babe5cbcf35aa0d3bdf43077a3de9

> Fix formatting bugs in halftone generators.
> gs/toolbin/halftone/gen_ordered/gen_ordered.c
> gs/toolbin/halftone/gen_stochastic/gen_stochastic.c

2013-03-27 11:58:19 +0000
Robin Watts <robin.watts@artifex.com>
0d7042456a3b0c4da39d5e9bbb46b5e5379c6dc7

> Another memory squeezing fix.
> Ensure that the op_array_tables in the interpreter context are set
> up enough that they can safely be garbage collected if allocations
> fail.
> gs/psi/imain.c

2013-03-27 03:52:51 -0700
Robin Watts <robin@peeves.(none)>
3b19ec49702466fa4a05a8b41087ef32c130806d

> More memory squeezing fixes.
> Lack of check on allocation success.
> gs/psi/icontext.c
> gs/psi/iinit.c
> gs/psi/imainarg.c
> gs/psi/zfont.c
> gs/psi/zpcolor.c

2013-03-26 14:48:04 -0700
Robin Watts <robin@peeves.(none)>
4848f7302726acef5ac8c98030ec1a14ddab06b6

> More memory squeezing fixes.
> Mostly unchecked allocation failures when setting up the gstate.
> gs/base/gscolor.c
> gs/base/gsptype1.c
> gs/base/gsstate.c
> gs/base/gxchar.c
> gs/base/gxdcolor.h

2013-03-26 13:09:49 -0700
Robin Watts <robin@peeves.(none)>
7d2e030ab25d8b31af22f0532ef813b0ff70e361

> Fix various memory squeezing errors.
> Mostly these are unchecked allocations, but some are errors in the
> cleanup paths.
> gs/base/gslibctx.c
> gs/base/gsmalloc.c
> gs/psi/gs.c
> gs/psi/imain.c
> gs/psi/interp.c
> gs/psi/zgstate.c

2013-03-26 08:42:14 -0600
Henry Stiles <henry.stiles@artifex.com>
a56fae81ef7f77b1ab6dadf38b1ea7539cfca0e4

> Free path upon fill failing - noticed in code review of ff515a6.
> pxl/pxpaint.c

2013-03-25 15:03:42 -0600
Henry Stiles <henry.stiles@artifex.com>
fca91ea554583d6f298f1c803ccf4d395b5dc94f

> Fix the fallout of a gnu indent bug introduced with the indentation
> change, commit bc86bd6.
> Unfortuntaly, gnu indent 2.2 adds new blank lines after each local
> variable declaration when the user requests that blocks of local
> declaration be separated from the procedure body with a blank line.
> This fix removes the extraneous blank lines.
> pcl/pcbiptrn.c
> pcl/pccid.c
> pcl/pccsbase.c
> pcl/pcdither.c
> pcl/pcdraw.c
> pcl/pcfont.c
> pcl/pcfontpg.c
> pcl/pcfrgrnd.c
> pcl/pcfsel.c
> pcl/pcht.c
> pcl/pcindxed.c
> pcl/pcjob.c
> pcl/pclookup.c
> pcl/pcmacros.c
> pcl/pcmtx3.c
> pcl/pcommand.c
> pcl/pcpage.c
> pcl/pcpalet.c
> pcl/pcparse.c
> pcl/pcpatrn.c
> pcl/pcpatxfm.c
> pcl/pcrect.c
> pcl/pcsfont.c
> pcl/pcstatus.c
> pcl/pcsymbol.c
> pcl/pctop.c
> pcl/pcuptrn.c
> pcl/pcursor.c
> pcl/pcwhtidx.c
> pcl/pgchar.c
> pcl/pgcolor.c
> pcl/pgconfig.c
> pcl/pgdraw.c
> pcl/pgfdata.c
> pcl/pgfont.c
> pcl/pgframe.c
> pcl/pggeom.c
> pcl/pginit.c
> pcl/pglabel.c
> pcl/pglfill.c
> pcl/pgmisc.c
> pcl/pgparse.c
> pcl/pgpoly.c
> pcl/pgvector.c
> pcl/rtgmode.c
> pcl/rtmisc.c
> pcl/rtraster.c
> pcl/rtrstcmp.c
> pl/dwimg.c
> pl/dwmainc.c
> pl/dwreg.c
> pl/pjparse.c
> pl/pjparsei.c
> pl/plalloc.c
> pl/plchar.c
> pl/pldict.c
> pl/plfapi.c
> pl/plfont.c
> pl/plht.c
> pl/pllfont.c
> pl/plmain.c
> pl/plsrgb.c
> pl/plsymbol.c
> pl/pluchar.c
> pl/plufont.c
> pl/plulfont.c
> pl/plvocab.c
> pxl/pxffont.c
> pxl/pxgstate.c
> pxl/pximage.c
> pxl/pxink.c
> pxl/pxpaint.c
> pxl/pxparse.c
> pxl/pxpthr.c
> pxl/pxsessio.c
> pxl/pxstate.c
> pxl/pxstream.c
> pxl/pxtop.c
> pxl/pxvalue.c

2013-03-25 08:47:42 -0600
Henry Stiles <henry.stiles@artifex.com>
d2a1f2e9de96d9fe70225302fd304309a19ef787

> Fix reading uninitialized point (bug #693655), remove obsolete
> supported conditional configurations and refactor.
> A logical error in paint_path resulted in reading the cursor
> uninitialized. Early in XL development NEWPATH_AFTER_PAINT and
> NO_SCALED_DASH_PATTERN were added to support incorrect language in the
> specification but their behavior is well established after 3 major
> revisions of the PCL-XL language can be safely removed allowing
> simplification of this code.
> Even with those changes the paint_path procedure was much too complex
> to be understandable, it is easy to see how a logical error would go
> unnoticed. We try to refactor the code such that client procedures
> take on some of the lifting and get rid of the gotos in hopes of
> having something cohesive and correct.
> pxl/pxpaint.c

2013-03-21 08:11:33 -0600
Henry Stiles <henry.stiles@artifex.com>
30273c4a9d9949f55dd4553dab614f1d36177377

> Remove outdated definition.
> PXL always resets the path after drawing single objects (rectangle,
> ellipse, etc.) and newer versions of the specification document this
> correctly consequently the compiler directive and alternate behavior
> can be removed.
> pxl/pxpaint.c

2013-03-26 10:20:25 +0000
Ken Sharp <ken.sharp@artifex.com>
7319905b5ba4dc3a3a66a4fa1489b653deb335fc

> pdfwrite - prevent dereference of NULL pointer when no BG/UCR info present
> Bug #693728 " Incompatible and large PDF output, and a crash with -dUCRandBGInfo=/Preserve"
> The input is XPS and XPS has no concept of BG/UCR, so the pointer to the
> information is NULL. If we had set the parameter -dUCRandBGInfo=/Preserve
> then we would attempt to dereference the NULL Pointer.
> We now check the pointer before attempting to dereference it.
> No differences expected.
> gs/devices/vector/gdevpdfg.c

2013-03-23 13:17:59 -0700
Ray Johnston <ray.johnston@artifex.com>
e76a62ee67c16f41f891a01011c7111e31643ebb

> Fix MSVC support of command line FEATURE_DEVS_EXTRA and DEVICE_DEVS_EXTRA
> In gs.mak these were both being set, which replaces the definition with nmake.
> Without these, the definition defaults to an empty string anyway.
> gs/base/gs.mak

2013-03-25 16:28:44 +0000
Ken Sharp <ken.sharp@artifex.com>
f54adf86c0f25bf9bc391e8df1af5e7ddfc0aca7

> pdfwrite - always fallback for type 4 images if we change colour space
> Type 4 (chroma keyed) images can't readily have their colour space changed,
> if we are going to a space with fewer components. For example, if we convert
> a CMYK image to Gray, then many different CMYK values will map to the same
> gray value, leading to parts of the image being masked which should not be.
> Technically it is possible to change colour space the other way, but it is
> easier for now to simply cause all such images to use the fallback code if
> we are changing colour space.
> gs/devices/vector/gdevpdfi.c

2013-03-25 16:24:53 +0000
Ken Sharp <ken.sharp@artifex.com>
e3160bc0c25969e6807161f798548b763222e585

> Change the colorSpace header entry in generated profiles to make pdfwrite happy
> The generated profiles for certain kinds of colour space were being created
> as 3CLR and 4CLR, which is absolutely fine in the general case. However,
> the new pdfwrite code uses the internal 'icc_equivalent' profile generated
> for a CIEBased PostScript colour space (previously pdfwrite generated its
> own profile).
> But The PDF Reference says that only Gray, RGB, CMYK and Lab are permissible
> values for the header. So here we pretend that the generated profiles are
> in either RGB or CMYK, so that the emitted PDF will be valid.
> Because the profiles are only used to convert into a CIE device-independent
> colour space, which will later be converted into a device space, this 'lie'
> should not cause any problems (these spaces are not currently emitted at any
> other point, and are never used as device profiles).
> No differences expected
> gs/base/gsicc_create.c

2013-03-22 10:32:07 +0000
Chris Liddell <chris.liddell@artifex.com>
563a2c68351388047d4a21501f8e042a45d0a8db

> Bug 693720: make tiffsep(1) depend on the planar device
> Update the makefiles to reflect that tiffsep is now a planar based device.
> Also fix some of the directory settings.
> No cluster differences.
> gs/base/msvctail.mak
> gs/base/unix-end.mak
> gs/devices/devs.mak

2013-03-22 10:21:47 +0000
Ken Sharp <ken.sharp@artifex.com>
2132b46fea22c8b3fc60d18eba0c2ae58162421c

> pdfwrite - only process pagelabels for pdfwrite device
> Bug #693721 "Regression: file cannot be read starting with
> 5784bfbfba7191cacce5309e88afac0851287460"
> The pagelabels are handled as device parameters rather than pdfmarks, because
> the pdfmark syntax can't handle the variety of page labels possible in a
> PDF file.
> Of course only the pdfwrite device can handle this device parameter, so we
> need to only perform this if the current device is pdfwrite.
> No differences expected, cluster only tests full builds, inclusive of
> the pdfwrite device.
> gs/Resource/Init/pdf_main.ps

2013-03-22 01:38:24 +0000
Robin Watts <robin.watts@artifex.com>
86b1d9bea8fbd9f0e7b89730a041f1edd35ee20a

> Add mujstest to list of possible user clusterpush jobs.
> gs/toolbin/localcluster/clusterpush.pl

2013-03-13 13:14:22 -0700
Ray Johnston <ray.johnston@artifex.com>
b9bb3f30028c552be77554b1e7c273625d115d95

> Fix bug 693079. Reduce stack usage for pattern_clist playback.
> There were a couple of rather large structures on the stack in
> clist_playback_band and in the tile filling. This file goes to
> 4 levels deep of clist_playback_band -- once for the main clist,
> then patterns nested 3 deep.
> gs/base/gxclrast.c

2013-03-21 12:55:07 -0700
Ray Johnston <ray.johnston@artifex.com>
9428436fa107096fd9826af8ff1a77a8616d4819

> Fix compiler warning.
> gs/base/gxclip2.h

2013-03-21 10:57:17 -0700
Ray Johnston <ray.johnston@artifex.com>
e4ddd5fbb12bce97f75d8039a863d32b81e2e67f

> Fix bug 693718: 09-03.PS clist problem with DeviceN devices and patterns.
> The clist device doesn't write masked DeviceN colors, so masked
> patterns use the gx_default_fill_path method, but the pattern logic
> optimizes masks that are solid to delete the mask (which is more
> efficient), but then the color must be converted to a non-masked
> color i.e., gx_dc_type_devn instead of gx_dc_type_devn_masked.
> This file was very resolution sensitive because the pattern was
> only solid at specific resolutions.
> Testing shows significant improvement on comparefiles/PP0001G0.pdf.psdcmyk.300.1
> gs/base/gxclip2.c
> gs/base/gxp1fill.c

2013-03-21 17:19:09 +0000
Chris Liddell <chris.liddell@artifex.com>
52ee1397fa772e6534843dcff6540fa9cb5b5f11

> Change jbig2dec license to AGPL to match Ghostscript.
> And remove an obsolete ".cvsignore" file.
> CLUSTER_UNTESTED
> gs/jbig2dec/.cvsignore
> gs/jbig2dec/COPYING
> gs/jbig2dec/LICENSE

2013-03-21 11:39:14 +0000
Chris Liddell <chris.liddell@artifex.com>
1d8da78f4ed1e472f7cfa4589122fc3392959563

> Bug 693613: add an explicit memory parameter to gs_path_enum_copy_init()
> In zpathforall() the path enumerator object is allocated with the current
> allocator for the Postscript VM mode. But gs_path_enum_copy_init() used the
> memory pointer from the graphics state for all it's allocations, and also to
> set the path enumerator's "memory" pointer.
> Clearly there was the potential for problems there: in this case, the current
> VM mode was global, but the graphics state was allocated in local. In this
> scenario, we immediately do a GC on *local* VM after zpathforall() and before
> we reach path_continue(). Because the path enumerator was allocated in global
> VM, we skip it during this GC, meaning the copied path and its contents (in
> local VM) were not marked, the memory considered free, and overwritten during
> the compaction phase.
> By adding an explicit memory parameter to gs_path_enum_copy_init() we can
> ensure that all the allocations for the path enumerator are consistent, and that
> the memory pointer in the enumerator is also correct.
> No cluster differences.
> gs/base/gspath.h
> gs/base/gspath1.c
> gs/psi/zpath1.c
> gs/psi/zupath.c

2013-03-20 18:20:37 +0000
Robin Watts <Robin.Watts@artifex.com>
8f4156a67dae6b3d6ba627a2003617ba773a19ff

> Bug 693714: Fix valgrind warnings in downsampler.
> When using the special downscalers for 2/3/4, I was miscalculating
> the input pointer for the right to left passes, leading to UMRs.
> Fixed here.
> Surprised that no one has complained of bad rendering!
> gs/base/gxdownscale.c

2013-03-20 08:38:39 +0000
Ken Sharp <ken.sharp@artifex.com>
59d1b2b25262c7995e4060ec8388abf059efcf3e

> Fix a couple of benign compiler warnings.
> gs/devices/vector/gdevpdfg.c

2013-03-19 16:55:06 +0000
Ken Sharp <ken.sharp@artifex.com>
af327b13f517a5a7e74ccafd4c325dd378f509c3

> pdfwrite - fix non-standard ranges in CIE spaces converted to ICC wiht linework
> Bug #693698 "Wrong color in file with pdfwrite"
> The specimen file claims to be Lab but actually isn't. The colour components
> are scaled to 0->100, 0->255, 0->255 instead of 0->100, -128 -> 127, -128 -> 127
> While the shading and image code scales the input values into 0->1 when emitting
> an equivalent ICCBased space, the linework code did not.
> This commit addresses that, and also adds code to deal with the same
> issue in the new colour code.
> There are a few cluster differences but the results are visually identical
> or extremely similar.
> gs/devices/vector/gdevpdfc.c
> gs/devices/vector/gdevpdfg.c
> gs/devices/vector/gdevpdfg.h

2013-03-19 09:38:01 +0000
Chris Liddell <chris.liddell@artifex.com>
0ce371636903391f165830d84dcbf6bc50a889bf

> Bug 693611: add missing pointer to pdf14_device gc funcs
> The pclist_device was missing from pdf14_device_enum_ptrs() and
> pdf14_device_reloc_ptrs().
> No cluster differences.
> gs/base/gdevp14.c

2013-03-19 09:55:13 +0000
Ken Sharp <ken.sharp@artifex.com>
46391b4a374db77027733598ec58989eb1d31e47

> pdfwrite - fix problem with discontinuous xref tables and 64-bit file sizes
> Bug #693710 "Regression: Missing output with pdfwrite and 32-bit build"
> The update to use 64-bit offsets for file sizes missed a case when finding
> the end of an xref section. This only occurs when an object has been reserved
> for future use, and then not actually used (eg a Destination for a Link on a
> page which is not then produced).
> Corrected the type from ulong to gs_offset_t.
> No differences expected.
> gs/devices/vector/gdevpdf.c

2013-03-18 20:19:48 -0600
Henry Stiles <henry.stiles@artifex.com>
bc86bd69e26b93a38ab7ee06fa2d77fb836b7c84

> Indent PCL and XL in accordance with the indentation rules in
> gs/doc/C-style.htm.
> The program GNU indent was used to make the changes and we expect
> there will be some manual cleanup over the next few days.
> pcl/pcbiptrn.c
> pcl/pcbiptrn.h
> pcl/pccid.c
> pcl/pccid.h
> pcl/pccolor.c
> pcl/pccoord.h
> pcl/pccprint.c
> pcl/pccsbase.c
> pcl/pccsbase.h
> pcl/pcdict.h
> pcl/pcdither.c
> pcl/pcdither.h
> pcl/pcdraw.c
> pcl/pcdraw.h
> pcl/pcfont.c
> pcl/pcfont.h
> pcl/pcfontpg.c
> pcl/pcfontst.h
> pcl/pcfrgrnd.c
> pcl/pcfrgrnd.h
> pcl/pcfsel.c
> pcl/pcfsel.h
> pcl/pcht.c
> pcl/pcht.h
> pcl/pcident.c
> pcl/pcident.h
> pcl/pcimpl.c
> pcl/pcindxed.c
> pcl/pcindxed.h
> pcl/pcjob.c
> pcl/pclookup.c
> pcl/pclookup.h
> pcl/pcmacros.c
> pcl/pcmisc.c
> pcl/pcmtx3.c
> pcl/pcmtx3.h
> pcl/pcommand.c
> pcl/pcommand.h
> pcl/pcpage.c
> pcl/pcpage.h
> pcl/pcpalet.c
> pcl/pcpalet.h
> pcl/pcparam.h
> pcl/pcparse.c
> pcl/pcparse.h
> pcl/pcpatrn.c
> pcl/pcpatrn.h
> pcl/pcpattyp.h
> pcl/pcpatxfm.c
> pcl/pcpatxfm.h
> pcl/pcrect.c
> pcl/pcsfont.c
> pcl/pcstate.h
> pcl/pcstatus.c
> pcl/pcsymbol.c
> pcl/pcsymbol.h
> pcl/pctext.c
> pcl/pctop.c
> pcl/pctop.h
> pcl/pctpm.h
> pcl/pcuptrn.c
> pcl/pcuptrn.h
> pcl/pcursor.c
> pcl/pcursor.h
> pcl/pcwhtidx.c
> pcl/pcwhtidx.h
> pcl/pcxfmst.h
> pcl/pgchar.c
> pcl/pgcolor.c
> pcl/pgconfig.c
> pcl/pgdraw.c
> pcl/pgdraw.h
> pcl/pgfdata.c
> pcl/pgfdata.h
> pcl/pgfont.c
> pcl/pgfont.h
> pcl/pgframe.c
> pcl/pggeom.c
> pcl/pggeom.h
> pcl/pginit.c
> pcl/pginit.h
> pcl/pglabel.c
> pcl/pglfill.c
> pcl/pgmand.h
> pcl/pgmisc.c
> pcl/pgmisc.h
> pcl/pgparse.c
> pcl/pgpoly.c
> pcl/pgstate.h
> pcl/pgvector.c
> pcl/rtgmode.c
> pcl/rtgmode.h
> pcl/rtmisc.c
> pcl/rtmisc.h
> pcl/rtraster.c
> pcl/rtraster.h
> pcl/rtrstcmp.c
> pcl/rtrstcmp.h
> pcl/rtrstst.h
> pl/dwimg.c
> pl/dwimg.h
> pl/dwmainc.c
> pl/dwreg.c
> pl/dwreg.h
> pl/pjparse.c
> pl/pjparse.h
> pl/pjparsei.c
> pl/pjtop.c
> pl/pjtop.h
> pl/plalloc.c
> pl/plapi.h
> pl/plchar.c
> pl/plchar.h
> pl/pldict.c
> pl/pldict.h
> pl/pldraw.c
> pl/pldraw.h
> pl/plfapi.c
> pl/plfapi.h
> pl/plfont.c
> pl/plfont.h
> pl/plftable.h
> pl/plht.c
> pl/plht.h
> pl/plimpl.c
> pl/pllfont.c
> pl/pllfont.h
> pl/plmain.c
> pl/plmain.h
> pl/plparse.h
> pl/plplatf.c
> pl/plplatf.h
> pl/plplatfps.c
> pl/plsrgb.c
> pl/plsrgb.h
> pl/plsymbol.c
> pl/plsymbol.h
> pl/pltop.c
> pl/pltop.h
> pl/pltoputl.c
> pl/pltoputl.h
> pl/pluchar.c
> pl/plufont.c
> pl/plufstlp.c
> pl/plufstlp.h
> pl/plufstlp1.c
> pl/plulfont.c
> pl/plvalue.c
> pl/plvalue.h
> pl/plvocab.c
> pl/realmain.c
> pxl/pxbfont.c
> pxl/pxbfont.h
> pxl/pxdict.h
> pxl/pxerrors.c
> pxl/pxerrors.h
> pxl/pxffont.c
> pxl/pxfont.c
> pxl/pxfont.h
> pxl/pxgstate.c
> pxl/pxgstate.h
> pxl/pximage.c
> pxl/pximpl.c
> pxl/pxink.c
> pxl/pxoper.h
> pxl/pxpaint.c
> pxl/pxparse.c
> pxl/pxparse.h
> pxl/pxptable.c
> pxl/pxptable.h
> pxl/pxpthr.c
> pxl/pxpthr.h
> pxl/pxsessio.c
> pxl/pxstate.c
> pxl/pxstate.h
> pxl/pxstream.c
> pxl/pxtop.c
> pxl/pxvalue.c
> pxl/pxvalue.h

2013-03-18 16:26:48 +0000
Chris Liddell <chris.liddell@artifex.com>
962b4bd30b0b85ee5c55d548144e0d4c073a7bfb

> Remove unnecessary traling $(D) from a "-I" compiler option.
> No cluster differences.
> gs/base/lib.mak

2013-03-18 10:59:37 +0000
Ken Sharp <ken.sharp@artifex.com>
ec0a5d96d02576c53cef22fe3e9bde5547c2f4ee

> pdfwrite - improve handling of broken fonts
> Bug #693711 "pdfwrite segfault"
> The specimen file contains two fonts which are badly broken, in one case
> the broken data stream decodes to a 'return' operation without a prior
> 'callsubr'. This caused the SEAC detection code to attempt to free memory
> using uninitialised data, which caused a seg fault. We now detect the call
> stack depth, and return an error if we return when no subroutine is executing.
> This caused a later heap error, as did the other font, because the regular
> type 1 font interpreter also didn't like the font data, and returned an error.
> This caused us not to write a FontFile resource, but the FontDescriptor
> writing code tried to write one anyway. Fixed by checking that there is a
> FontFile before trying to write one.
> The specimen file now runs to completion, but will not embed the broken
> fonts. As a result it will only work 'correctly' on systems which have the
> missing fonts available. Although given that these fonts are broken, it
> seems unlikely these will work anyway.
> No differences expected.
> gs/base/gxtype1.c
> gs/devices/vector/gdevpdtd.c

2013-03-18 08:36:00 +0000
Chris Liddell <chris.liddell@artifex.com>
fe7e1a32165f96d20d696c6b0349d338f1ec3666

> Bug 693712: fix the header search path
> The new devices directory wasn't correctly added to the list of "-I" compiler
> options.
> No cluster differences.
> gs/base/lib.mak

2013-03-17 17:46:54 -0600
Henry Stiles <henry.stiles@artifex.com>
ba5fb31f9029bf622bea24ac47e089c514981f7f

> Warning cleanup.
> pcl/pcl.mak
> pcl/pcpage.c
> pcl/pctext.c
> pl/pjparse.c
> pl/plfont.c
> pxl/pxerrors.c
> pxl/pxfont.c
> pxl/pxl.mak

2013-03-17 09:49:46 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
473fec16b9ff829b28d0c291eb4fc929f221d3c6

> Bug 693658: Avoid overflows in image positioning.
> Check for overflows to handle cases when CTM or ImageMatrix is too big.
> gs/base/gxifast.c
> gs/base/gxipixel.c

2013-03-16 10:38:07 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
884590d08f332a06ebf3e5db996c32210a5fc8c0

> Bug 689658: Reject excessive values in CIE color spaces.
> Reject CIE color spaces that have any of the attributes out of
> -10000..10000 range to avoid overflows and division by 0.
> This range should be sufficient for any real world color usage.
> gs/psi/zcolor.c
> gs/psi/zcrd.c

2013-03-16 09:08:05 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
56f34c8243ad078882df0f08cbfc10c6943fb3fe

> Bug 693658: Improve validation of image parameters
> To avoid overflow, check that parameter is withing the given range
> before the parameter is converted to int. Stop interpolation of 0-width
> or 0-length images because interpolation code divides by 0 in this case.
> gs/base/gxiscale.c
> gs/psi/idparam.c
> gs/psi/zimage.c

2013-03-15 10:48:15 -0600
Henry Stiles <henry.stiles@artifex.com>
93bcd2277fe838838c760c4fea827d18a445ba8f

> Bug 692722: Fix garbage in win32 console when using unicode filename.
> In Unicode build, wide-char arguments are first converted to UTF-8 and
> may be sent to stdout/stderr. So we must switch the console code page
> to CP_UTF8 during main_utf8() execution to avoid utf-8/local-codepage
> collision.
> Thanks to Mathieu Lafon for the patch.
> pl/dwmainc.c

2013-03-15 14:32:21 +0000
Chris Liddell <chris.liddell@artifex.com>
773c69e46e70bdd5482676437dafd2ca83397643

> Bug 693699: replace all fopen calls with gp_fopen
> Only exceptions are those in the platform specific code, and mkromfs.c.
> Also, add a preprocessor define so that any unintential calls directly to
> fopen will cause an error.
> No cluster differences.
> gs/base/fapi_ft.c
> gs/base/gp_dvx.c
> gs/base/gp_macio.c
> gs/base/gp_mswin.c
> gs/base/gp_os2.c
> gs/base/gp_unifs.c
> gs/base/gp_unix.c
> gs/base/gp_unix_cache.c
> gs/base/gp_vms.c
> gs/base/gsdevice.c
> gs/base/gsicc_create.c
> gs/base/gsicc_lcms.c
> gs/base/gsicc_lcms2.c
> gs/base/gsicc_manage.c
> gs/base/gsiodev.c
> gs/base/gsiodisk.c
> gs/base/gsiomacres.c
> gs/base/gsroprun.c
> gs/base/gxblend.c
> gs/base/gxblend1.c
> gs/base/gxiodev.h
> gs/base/gxpcmap.c
> gs/base/lib.mak
> gs/base/mkromfs.c
> gs/base/stdio_.h
> gs/base/strmio.c
> gs/contrib/japanese/dviprlib.c
> gs/contrib/japanese/gdevdmpr.c
> gs/contrib/pcl3/eprn/eprnparm.c
> gs/contrib/pscolor/test.c
> gs/devices/vector/gdevtxtw.c
> gs/psi/apitest.c
> gs/psi/gserver.c
> gs/psi/int.mak
> gs/psi/zfile.c
> gs/psi/ziodev2.c
> pl/pjparse.c
> pl/plmain.c
> svg/svg.mak
> svg/svgtop.c
> xps/xpszip.c

2013-03-15 10:13:05 +0000
Chris Liddell <chris.liddell@artifex.com>
5d49dbfa9c33dc67f7e5dbb0294056976de33521

> Bug 693702: fix handling of large glyphs in FAPI/UFST
> There was a logical error in the fallback case when a glyph ends up too big
> for a temporary bitmap allocation in the UFST code which caused us to render
> the "notdef" glyph instead of fallback to using the glyph outline to render
> uncached.
> CLUSTER_UNTESTED
> gs/base/fapiufst.c

2013-03-14 11:59:19 -0600
Henry Stiles <henry.stiles@artifex.com>
b243adea0a7684fdb1fe755166816bafddca7666

> Documentation typo fixed.
> CLUSTER_UNTESTED
> doc/ghostpdl.pdf
> doc/ghostpdl.tex
> doc/ghostpdl.txt

2013-03-14 09:11:07 +0000
Ken Sharp <ken.sharp@artifex.com>
5265796a4b8cb3d05dd72695373381135cb99c50

> Remove two unused variables and a redundant function call
> Flagged by compiler warnings, two variables are unused, and a function call
> to set one of them is not required.
> No differences expected
> gs/psi/zcolor.c

2013-03-13 13:39:54 -0600
Henry Stiles <henry.stiles@artifex.com>
da27879315a810e24fc881680a2ea5e8345c9bc2

> Fix trace device to compile with the new directory structure.
> The trace devices were located in the lib.mak file and stopped working
> (the compile broke) when gdevtrac.c was moved to the new devices/
> directory.
> gs/base/lib.mak
> gs/devices/devs.mak

2013-03-13 14:10:55 +0000
Chris Liddell <chris.liddell@artifex.com>
044c2d5eefff2d1c92dc830b4b424856228cd083

> Remove psmono, psgray and psrgb devices.
> Only vestige of pswrite remaining is epswrite.
> No cluster differences.
> doc/who_owns_what.txt
> gs/Makefile.in
> gs/base/macos-mcp.mak
> gs/base/openvms.mak
> gs/base/openvms.mmk
> gs/base/unix-gcc.mak
> gs/base/unixansi.mak
> gs/configure.ac
> gs/devices/devs.mak
> gs/devices/gdevpsim.c
> gs/doc/Devices.htm
> gs/psi/msvc.mak
> gs/psi/os2.mak
> gs/toolbin/pre.chk

2013-03-13 13:33:18 +0000
Ken Sharp <ken.sharp@artifex.com>
fe10fefa06fe8405a05d4370ab6deaf14e06b122

> Fix '0' return handling from dict_find_string in colour code
> Bug #693685 - Wrong assumption about dict_find_string()
> It seems that dict_find_string can return 0 when a string is not found in a
> dictionary. This commit updates the code to deal with this (apparently unusual)
> case.
> No differences expected
> gs/psi/zcolor.c

2013-03-11 16:17:49 -0400
Chris Liddell <chris.liddell@artifex.com>
8a95c1dff88559acbe451fa4b402fdae7f1818b3

> Remove pswrite device.
> epswrite and, by implication, the pswrite source remain - for now......
> No cluster differences.
> doc/who_owns_what.txt
> gs/base/macos-mcp.mak
> gs/base/macosx.mak
> gs/base/openvms.mak
> gs/base/openvms.mmk
> gs/base/unix-gcc.mak
> gs/configure.ac
> gs/devices/devs.mak
> gs/devices/vector/gdevps.c
> gs/doc/Develop.htm
> gs/doc/Devices.htm
> gs/doc/Issues.htm
> gs/doc/Projects.htm
> gs/doc/Use.htm
> gs/psi/msvc.mak
> gs/psi/os2.mak
> gs/toolbin/pre.chk
> main/pcl6_gcc.mak
> main/pcl6_msvc.mak

2013-03-13 10:27:56 +0000
Chris Liddell <chris.liddell@artifex.com>
ea86d8b5f40deff1b226c0a1bc98685f7ce34a02

> Fix a missing "!endif" in msvclib.mak
> CLUSTER_UNTESTED
> gs/base/msvclib.mak

2013-03-12 13:29:45 -0700
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
a7b3f0ce56a0c86b3b9b1c815d0c0a402e2cb3f6

> Add pdfwrite option to clusterpush.pl to run only pdfwrite and ps2write tests.
> gs/toolbin/localcluster/clusterpush.pl

2013-03-11 23:09:22 +0000
unknown <ken@.(none)>
b0a5422d62b83d961a2caa5bd271d25e08495b25

> Check return codes when handling CIE colour space parameters
> We weren't checking some parameters, which could lead to seg faults
> Bug #693659
> gs/psi/zcie.c

2013-03-11 23:05:55 +0000
unknown <ken@.(none)>
b3b835e19f8a248a16ed68394c16b1e8899cf6ac

> pdfwrite - limit number of pages to limit in spec
> Bug #693658 - file 35a5e3ba_39da0975_973319ae_a18c13ca_ce4ba9eb.SIGSEGV.b0b
> Reserving pages overflowed an integer, causing us not to reserve enough pages
> we now clamp to 2^32 -1 (see PDF spec, page numbers are defined as integers)
> This now runs out of memory and aborts the pdfmark.
> No differences expectedd
> gs/devices/vector/gdevpdfu.c

2013-03-11 17:01:39 -0400
Chris Liddell <chris.liddell@artifex.com>
943ae1102814d5248fea59b3029fa8723a47527b

> Bug 693644: Remove leftover stuff about pdfopt and dumphint
> No cluster differences
> gs/Resource/Init/gs_init.ps
> gs/base/unixinst.mak
> gs/doc/Develop.htm
> gs/doc/Psfiles.htm
> gs/doc/Use.htm
> gs/man/de/pdfopt.1
> gs/man/pdfopt.1

2013-03-11 15:40:36 -0400
Chris Liddell <chris.liddell@artifex.com>
9c78f0146d0983382b54e15433c44faabc6fffcc

> Bug 693686: Improve heurisic for vertical metrics from FT
> Freetype "derives" vertical metrics when a font does not contain any, so we
> use a heuristic to decide whether to use them, or not. With the revised FAPI
> for use with the non-PS/PDF languages, the "heurstic" was "augmented" with an
> unsuitably simple test - so now that simple test has been replaced with
> an improved heuristic which works for both PS and PCL.
> No cluster differences.
> gs/base/fapi_ft.c
> gs/base/gxfapi.c

2013-03-10 14:55:13 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
a9fa9038c30384eb8bc07aa53d115f6b9d94e46f

> Bug 693658: Reject encoding array with non-name entries.
> gs/psi/zfapi.c

2013-03-09 20:50:32 -0500
Alex Cherepanov <alex.cherepanov@artifex.com>
a431d5193985ed563a04ec71a053ddfe14026326

> Bug 693681: Thansform group /BBox by /Matrix
> gs/Resource/Init/pdf_draw.ps

2013-03-08 17:19:43 -0500
Alex Cherepanov <alex.cherepanov@artifex.com>
2cdd97670587903d4198ef7455742f0363502bb8

> Bug 693659: Check that halftone 5 has /Default component.
> gs/psi/zht2.c

2013-03-08 16:54:05 +0000
Chris Liddell <chris.liddell@artifex.com>
5f5f13ff649293cb66fa8ddcdad4a1e9bedf437f

> Bug 693683: remove not needed header.
> CLUSTER_UNTESTED
> gs/base/fapiufst.c

2013-03-07 16:56:10 -0700
Henry Stiles <henry.stiles@artifex.com>
26a55d3991398f16a71d8369944ac75ab55aa94c

> Bug 693453, remove unnecessary confusing check for a null parameter.
> The width parameter is a prerequisite and does not need to be null
> checked.
> pl/plchar.c

2013-03-08 11:08:40 +0000
Ken Sharp <ken.sharp@artifex.com>
d337f132f69f31957b4b409a7958b45bdc2089fe

> pdfwrite - Auto-rotation. Prefer auto-rotate over DSC comments
> When auto-rotation is not /None we check both the heuristically determined
> auto-rotate value and (for PostScript input) any DSC document or page level
> comments.
> Previously where these conflicted we used the DSC comments, but this seems
> obtuse when the user has asked for auto-rotation. This reverses the default
> so that auto-rotation will be preferred.
> Also updated the documentation which incorrectly stated that Orientation
> DSC comments were ignored.
> Expected differences
> A few files are now rotated where previously they were not
> gs/devices/vector/gdevpdf.c
> gs/doc/Ps2pdf.htm

2013-03-08 10:45:30 +0000
Chris Liddell <chris.liddell@artifex.com>
2ec451c463a73f66891356081f1bc9d3972a0358

> Remove a pointless relative path in the VS project
> CLUSTER_UNTESTED
> gs/ghostscript.vcproj

2013-03-08 10:29:33 +0000
Chris Liddell <chris.liddell@artifex.com>
4aa99bb81e72592ed9adcdf6cfec8fadc001ba62

> Add the VS project changes for the new devices dir
> These changes somehow went awol when I committed the directory reorg.
> CLUSTER_UNTESTED
> gs/ghostscript.vcproj

2013-03-07 23:44:25 -0800
Ray Johnston <ray.johnston@artifex.com>
7cc7b0adb8203fbc94ce4613e4eefa12d9de0b2c

> Fix compiler warning and trailing whitespace issues.
> gs/base/gsequivc.c

2013-03-07 16:18:47 -0800
Ray Johnston <ray.johnston@artifex.com>
7fd565cebe1add96bf09527530c1f30365090cc5

> Clean up some indents that used tabs.
> gs/base/gdevp14.c

2013-01-12 19:41:09 -0800
Ray Johnston <ray.johnston@artifex.com>
6c4990bb6f8f4e5d7484b9b183ea9caaa5eaedee

> Remove force of -Z: used during development.
> gs/psi/imain.c

2012-08-27 15:57:59 -0700
Ray Johnston <ray.johnston@artifex.com>
abc6c492a11f63ee416ecd287d980a0cb134421e

> Finally get rid of band_complexity and write/read color_usage_array from clist.
> This also gets rid of the hackish fixed length band_color_usage in the page_info
> in favor of a dynamically allocated structure that has one entry per band.
> A few minor git gripes cleaned up for the commit (trailing whitespace) in the
> affected files.
> gs/base/gdevppla.c
> gs/base/gdevppla.h
> gs/base/gdevprn.c
> gs/base/gdevprn.h
> gs/base/gxband.h
> gs/base/gxcldev.h
> gs/base/gxclimag.c
> gs/base/gxclist.c
> gs/base/gxclist.h
> gs/base/gxclpath.c
> gs/base/gxclread.c
> gs/base/gxclrect.c
> gs/base/gxclthrd.c
> gs/base/gxclutil.c
> gs/base/gxdevbuf.h
> gs/devices/gdevijs.c
> gs/devices/gdevplib.c
> gs/devices/gdevpng.c
> gs/psi/imain.c

2012-05-09 09:31:46 -0700
Ray Johnston <ray.johnston@artifex.com>
aa5ee8102a4a98c8cef55b4ee9f347b9bdf94036

> Optimize PDF 1.4 transparency when using the clist.
> Keep track of the bbox for the actual transparency rect in each band,
> and skip pdf14 compositor actions on playback for bands with an empty
> bbox. Bands that only paint to the page level with alpha == 1 don't
> need the compositor. -Z: prints the number of bands skipped.
> gs/base/gdevp14.c
> gs/base/gdevprn.c
> gs/base/gsropt.h
> gs/base/gxband.h
> gs/base/gxcldev.h
> gs/base/gxclimag.c
> gs/base/gxclist.c
> gs/base/gxclist.h
> gs/base/gxclpath.c
> gs/base/gxclrast.c
> gs/base/gxclread.c
> gs/base/gxclrect.c
> gs/base/gxclutil.c
> gs/base/lib.mak

2013-03-07 14:06:36 -0800
Ray Johnston <ray.johnston@artifex.com>
dde01090d9251f0752583fa0524d0db7e5b1531d

> Fix indeterminate results caused by UMR of render_cond.
> Seen with tests_private/pdf/PDFIA1.7_SUBSET/CATX4988.pdf and other
> files (psdcmyk device). Function capture_spot_equivalent_cmyk_colors
> uses a 'temp_profile' but didn't initialize the rendercond
> array which could change the link profile that was generated.
> Also (just in case) set the devicegraytok element.
> gs/base/gsequivc.c

2013-03-06 11:17:49 -0800
Ray Johnston <ray.johnston@artifex.com>
b2716c4d4862d357d52e3046f512bf4a93b71296

> Fix missing dependency of gxpcolor.h
> gs/base/lib.mak

2013-03-07 14:05:59 -0500
Alex Cherepanov <alex.cherepanov@artifex.com>
0deeb9ece0637d0d1e8f2d6d03cea3e245330856

> Bug 693659: Check that CalRGB is a dictionary.
> gs/psi/zcolor.c

2013-03-07 13:40:58 -0500
Alex Cherepanov <alex.cherepanov@artifex.com>
4e43623be06fc7dbae01071ab78b5e9f9e70f133

> Bug 693659: Check that halftone name is a name.
> gs/psi/zht2.c

2013-03-07 12:41:53 -0500
Alex Cherepanov <alex.cherepanov@artifex.com>
8f972acdde3a09fc37e76826dafec44f8d9ee603

> Bug 693659: Check for file name buffer overflow.
> gs/psi/zfile.c

2013-03-07 09:15:07 -0500
Alex Cherepanov <alex.cherepanov@artifex.com>
2e32682a2530afae04e2d1988da06740d92f7808

> Bug 693659: Skip empty strings in sfnts array.
> gs/psi/zfapi.c

2013-03-07 00:45:41 +0000
Robin Watts <robin.watts@artifex.com>
6961e71d7b6b9162f6b75fae60469175a4c8d43e

> Bug 692862: Fix stroking problem with antialiasing
> The fix for bug 691228 causes problems in some cases; when joining
> two segment that are directly in line with the next, we add a
> circular line cap to ensure correct rendering. Which side of this
> end cap we end up on depends on which direction the line then
> continues in.
> gs/base/gxstroke.c

2013-03-06 09:30:38 -0800
Ray Johnston <ray.johnston@artifex.com>
d3d66fddadc345aab1139397e10b1ab200af2c99

> Fix infinite recursion (caused segfault) introduced with commit 70ba7029.
> The fix to mem_planar_fill_rectangle_hl_color did not account for the
> devn_masked color type which can also be handled.
> gs/base/gdevmpla.c

2013-03-06 10:15:14 -0500
Alex Cherepanov <alex.cherepanov@artifex.com>
0f541c553afe098f84f19557e4a19bb18e803b91

> Bug 693659: Reject functions with 1-point domain.
> gs/psi/zfunc.c

2013-02-26 18:01:40 +0000
Chris Liddell <chris.liddell@artifex.com>
f1488c5aff54f37ee67759827d4298592af5dbc8

> Move output devices to their own directory.
> Also put the vector devices in their own directory, so we have:
> gs/devices
> and
> gs/devices/vector
> This is a first pass - further refinement may be required!
> No cluster differences.
> common/msvc_top.mak
> common/ugcc_top.mak
> gs/Makefile.in
> gs/autogen.sh
> gs/base/Makefile.in
> gs/base/configure.ac
> gs/base/contrib.mak
> gs/base/devs.mak
> gs/base/gdev3852.c
> gs/base/gdev3b1.c
> gs/base/gdev4081.c
> gs/base/gdev4693.c
> gs/base/gdev8510.c
> gs/base/gdev8bcm.c
> gs/base/gdev8bcm.h
> gs/base/gdevadmp.c
> gs/base/gdevagl.c
> gs/base/gdevagl.h
> gs/base/gdevatx.c
> gs/base/gdevbit.c
> gs/base/gdevbj10.c
> gs/base/gdevbjc.h
> gs/base/gdevbjcl.c
> gs/base/gdevbjcl.h
> gs/base/gdevbmp.c
> gs/base/gdevbmp.h
> gs/base/gdevbmpa.c
> gs/base/gdevbmpc.c
> gs/base/gdevccr.c
> gs/base/gdevcdj.c
> gs/base/gdevcfax.c
> gs/base/gdevcif.c
> gs/base/gdevclj.c
> gs/base/gdevcljc.c
> gs/base/gdevcp50.c
> gs/base/gdevcslw.c
> gs/base/gdevdfax.c
> gs/base/gdevdjet.c
> gs/base/gdevdjtc.c
> gs/base/gdevdljm.c
> gs/base/gdevdljm.h
> gs/base/gdevdm24.c
> gs/base/gdevdsp.c
> gs/base/gdevdsp.h
> gs/base/gdevdsp2.h
> gs/base/gdevepsc.c
> gs/base/gdevepsn.c
> gs/base/gdevescp.c
> gs/base/gdevevga.c
> gs/base/gdevfax.c
> gs/base/gdevfax.h
> gs/base/gdevherc.c
> gs/base/gdevhl7x.c
> gs/base/gdevicov.c
> gs/base/gdevifno.c
> gs/base/gdevijs.c
> gs/base/gdevimgn.c
> gs/base/gdevjbig2.c
> gs/base/gdevjpeg.c
> gs/base/gdevjpx.c
> gs/base/gdevl256.c
> gs/base/gdevl31s.c
> gs/base/gdevlbp8.c
> gs/base/gdevlj56.c
> gs/base/gdevlp8k.c
> gs/base/gdevlxm.c
> gs/base/gdevmac.c
> gs/base/gdevmac.h
> gs/base/gdevmacpictop.h
> gs/base/gdevmacttf.h
> gs/base/gdevmeds.c
> gs/base/gdevmeds.h
> gs/base/gdevmgr.c
> gs/base/gdevmgr.h
> gs/base/gdevmiff.c
> gs/base/gdevmswn.c
> gs/base/gdevmswn.h
> gs/base/gdevmsxf.c
> gs/base/gdevn533.c
> gs/base/gdevo182.c
> gs/base/gdevokii.c
> gs/base/gdevos2p.c
> gs/base/gdevp2up.c
> gs/base/gdevpbm.c
> gs/base/gdevpcfb.c
> gs/base/gdevpcfb.h
> gs/base/gdevpcl.c
> gs/base/gdevpcl.h
> gs/base/gdevpcx.c
> gs/base/gdevpdf.c
> gs/base/gdevpdfb.c
> gs/base/gdevpdfb.h
> gs/base/gdevpdfc.c
> gs/base/gdevpdfc.h
> gs/base/gdevpdfd.c
> gs/base/gdevpdfe.c
> gs/base/gdevpdfg.c
> gs/base/gdevpdfg.h
> gs/base/gdevpdfi.c
> gs/base/gdevpdfj.c
> gs/base/gdevpdfk.c
> gs/base/gdevpdfm.c
> gs/base/gdevpdfo.c
> gs/base/gdevpdfo.h
> gs/base/gdevpdfp.c
> gs/base/gdevpdfr.c
> gs/base/gdevpdft.c
> gs/base/gdevpdfu.c
> gs/base/gdevpdfv.c
> gs/base/gdevpdfx.h
> gs/base/gdevpdt.c
> gs/base/gdevpdt.h
> gs/base/gdevpdtb.c
> gs/base/gdevpdtb.h
> gs/base/gdevpdtc.c
> gs/base/gdevpdtd.c
> gs/base/gdevpdtd.h
> gs/base/gdevpdte.c
> gs/base/gdevpdtf.c
> gs/base/gdevpdtf.h
> gs/base/gdevpdti.c
> gs/base/gdevpdti.h
> gs/base/gdevpdts.c
> gs/base/gdevpdts.h
> gs/base/gdevpdtt.c
> gs/base/gdevpdtt.h
> gs/base/gdevpdtv.c
> gs/base/gdevpdtv.h
> gs/base/gdevpdtw.c
> gs/base/gdevpdtw.h
> gs/base/gdevpdtx.h
> gs/base/gdevpe.c
> gs/base/gdevperm.c
> gs/base/gdevphex.c
> gs/base/gdevpjet.c
> gs/base/gdevplan.c
> gs/base/gdevplib.c
> gs/base/gdevplib.h
> gs/base/gdevpm.h
> gs/base/gdevpng.c
> gs/base/gdevps.c
> gs/base/gdevpsd.c
> gs/base/gdevpsdf.h
> gs/base/gdevpsdi.c
> gs/base/gdevpsdp.c
> gs/base/gdevpsds.c
> gs/base/gdevpsds.h
> gs/base/gdevpsdu.c
> gs/base/gdevpsf.h
> gs/base/gdevpsf1.c
> gs/base/gdevpsf2.c
> gs/base/gdevpsfm.c
> gs/base/gdevpsft.c
> gs/base/gdevpsfu.c
> gs/base/gdevpsfx.c
> gs/base/gdevpsim.c
> gs/base/gdevpsu.c
> gs/base/gdevpsu.h
> gs/base/gdevpx.c
> gs/base/gdevpxut.c
> gs/base/gdevpxut.h
> gs/base/gdevrinkj.c
> gs/base/gdevs3ga.c
> gs/base/gdevsco.c
> gs/base/gdevsgi.c
> gs/base/gdevsgi.h
> gs/base/gdevsj48.c
> gs/base/gdevsnfb.c
> gs/base/gdevsppr.c
> gs/base/gdevstc.c
> gs/base/gdevstc.h
> gs/base/gdevstc1.c
> gs/base/gdevstc2.c
> gs/base/gdevstc3.c
> gs/base/gdevstc4.c
> gs/base/gdevsun.c
> gs/base/gdevsunr.c
> gs/base/gdevsvg.c
> gs/base/gdevsvga.c
> gs/base/gdevsvga.h
> gs/base/gdevtfax.c
> gs/base/gdevtfax.h
> gs/base/gdevtfnx.c
> gs/base/gdevtifs.c
> gs/base/gdevtifs.h
> gs/base/gdevtknk.c
> gs/base/gdevtrac.c
> gs/base/gdevtsep.c
> gs/base/gdevtxtw.c
> gs/base/gdevupd.c
> gs/base/gdevvglb.c
> gs/base/gdevwddb.c
> gs/base/gdevwdib.c
> gs/base/gdevwpr2.c
> gs/base/gdevwprn.c
> gs/base/gdevx.c
> gs/base/gdevx.h
> gs/base/gdevxalt.c
> gs/base/gdevxcf.c
> gs/base/gdevxcmp.c
> gs/base/gdevxcmp.h
> gs/base/gdevxini.c
> gs/base/gdevxps.c
> gs/base/gdevxres.c
> gs/base/gxfcopy.c
> gs/base/gxfcopy.h
> gs/base/lib.mak
> gs/base/macos-mcp.mak
> gs/base/macosx.mak
> gs/base/minftrsz.c
> gs/base/minftrsz.h
> gs/base/msvclib.mak
> gs/base/opdfread.h
> gs/base/openvms.mak
> gs/base/openvms.mmk
> gs/base/pcwin.mak
> gs/base/rinkj/evenbetter-rll.c
> gs/base/rinkj/evenbetter-rll.h
> gs/base/rinkj/rinkj-byte-stream.c
> gs/base/rinkj/rinkj-byte-stream.h
> gs/base/rinkj/rinkj-config.c
> gs/base/rinkj/rinkj-config.h
> gs/base/rinkj/rinkj-device.c
> gs/base/rinkj/rinkj-device.h
> gs/base/rinkj/rinkj-dither.c
> gs/base/rinkj/rinkj-dither.h
> gs/base/rinkj/rinkj-epson870.c
> gs/base/rinkj/rinkj-epson870.h
> gs/base/rinkj/rinkj-screen-eb.c
> gs/base/rinkj/rinkj-screen-eb.h
> gs/base/ugcclib.mak
> gs/base/unix-dll.mak
> gs/base/unix-gcc.mak
> gs/base/unixansi.mak
> gs/base/whitelst.c
> gs/base/whitelst.h
> gs/base/winlib.mak
> gs/configure.ac
> gs/contrib/contrib.mak
> gs/devices/contrib.mak
> gs/devices/devs.mak
> gs/devices/gdev3852.c
> gs/devices/gdev3b1.c
> gs/devices/gdev4081.c
> gs/devices/gdev4693.c
> gs/devices/gdev8510.c
> gs/devices/gdev8bcm.c
> gs/devices/gdev8bcm.h
> gs/devices/gdevadmp.c
> gs/devices/gdevatx.c
> gs/devices/gdevbit.c
> gs/devices/gdevbj10.c
> gs/devices/gdevbjc.h
> gs/devices/gdevbjcl.c
> gs/devices/gdevbjcl.h
> gs/devices/gdevbmp.c
> gs/devices/gdevbmp.h
> gs/devices/gdevbmpa.c
> gs/devices/gdevbmpc.c
> gs/devices/gdevccr.c
> gs/devices/gdevcdj.c
> gs/devices/gdevcfax.c
> gs/devices/gdevcif.c
> gs/devices/gdevclj.c
> gs/devices/gdevcljc.c
> gs/devices/gdevcp50.c
> gs/devices/gdevcslw.c
> gs/devices/gdevdfax.c
> gs/devices/gdevdjet.c
> gs/devices/gdevdjtc.c
> gs/devices/gdevdljm.c
> gs/devices/gdevdljm.h
> gs/devices/gdevdm24.c
> gs/devices/gdevdsp.c
> gs/devices/gdevdsp.h
> gs/devices/gdevdsp2.h
> gs/devices/gdevepsc.c
> gs/devices/gdevepsn.c
> gs/devices/gdevescp.c
> gs/devices/gdevevga.c
> gs/devices/gdevfax.c
> gs/devices/gdevfax.h
> gs/devices/gdevherc.c
> gs/devices/gdevhl7x.c
> gs/devices/gdevicov.c
> gs/devices/gdevifno.c
> gs/devices/gdevijs.c
> gs/devices/gdevimgn.c
> gs/devices/gdevjbig2.c
> gs/devices/gdevjpeg.c
> gs/devices/gdevjpx.c
> gs/devices/gdevl256.c
> gs/devices/gdevl31s.c
> gs/devices/gdevlbp8.c
> gs/devices/gdevlp8k.c
> gs/devices/gdevlxm.c
> gs/devices/gdevmac.c
> gs/devices/gdevmac.h
> gs/devices/gdevmacpictop.h
> gs/devices/gdevmacttf.h
> gs/devices/gdevmeds.c
> gs/devices/gdevmeds.h
> gs/devices/gdevmgr.c
> gs/devices/gdevmgr.h
> gs/devices/gdevmiff.c
> gs/devices/gdevmswn.c
> gs/devices/gdevmswn.h
> gs/devices/gdevmsxf.c
> gs/devices/gdevn533.c
> gs/devices/gdevo182.c
> gs/devices/gdevokii.c
> gs/devices/gdevos2p.c
> gs/devices/gdevp2up.c
> gs/devices/gdevpbm.c
> gs/devices/gdevpcfb.c
> gs/devices/gdevpcfb.h
> gs/devices/gdevpcl.c
> gs/devices/gdevpcl.h
> gs/devices/gdevpcx.c
> gs/devices/gdevpe.c
> gs/devices/gdevperm.c
> gs/devices/gdevphex.c
> gs/devices/gdevpjet.c
> gs/devices/gdevplan.c
> gs/devices/gdevplib.c
> gs/devices/gdevplib.h
> gs/devices/gdevpm.h
> gs/devices/gdevpng.c
> gs/devices/gdevpsd.c
> gs/devices/gdevpsim.c
> gs/devices/gdevrinkj.c
> gs/devices/gdevs3ga.c
> gs/devices/gdevsco.c
> gs/devices/gdevsgi.c
> gs/devices/gdevsgi.h
> gs/devices/gdevsj48.c
> gs/devices/gdevsnfb.c
> gs/devices/gdevsppr.c
> gs/devices/gdevstc.c
> gs/devices/gdevstc.h
> gs/devices/gdevstc1.c
> gs/devices/gdevstc2.c
> gs/devices/gdevstc3.c
> gs/devices/gdevstc4.c
> gs/devices/gdevsun.c
> gs/devices/gdevsunr.c
> gs/devices/gdevsvga.c
> gs/devices/gdevsvga.h
> gs/devices/gdevtfax.c
> gs/devices/gdevtfax.h
> gs/devices/gdevtfnx.c
> gs/devices/gdevtifs.c
> gs/devices/gdevtifs.h
> gs/devices/gdevtknk.c
> gs/devices/gdevtrac.c
> gs/devices/gdevtsep.c
> gs/devices/gdevupd.c
> gs/devices/gdevvglb.c
> gs/devices/gdevwddb.c
> gs/devices/gdevwdib.c
> gs/devices/gdevwpr2.c
> gs/devices/gdevwprn.c
> gs/devices/gdevx.c
> gs/devices/gdevx.h
> gs/devices/gdevxalt.c
> gs/devices/gdevxcf.c
> gs/devices/gdevxcmp.c
> gs/devices/gdevxcmp.h
> gs/devices/gdevxini.c
> gs/devices/gdevxres.c
> gs/devices/gxfcopy.c
> gs/devices/gxfcopy.h
> gs/devices/minftrsz.c
> gs/devices/minftrsz.h
> gs/devices/rinkj/evenbetter-rll.c
> gs/devices/rinkj/evenbetter-rll.h
> gs/devices/rinkj/rinkj-byte-stream.c
> gs/devices/rinkj/rinkj-byte-stream.h
> gs/devices/rinkj/rinkj-config.c
> gs/devices/rinkj/rinkj-config.h
> gs/devices/rinkj/rinkj-device.c
> gs/devices/rinkj/rinkj-device.h
> gs/devices/rinkj/rinkj-dither.c
> gs/devices/rinkj/rinkj-dither.h
> gs/devices/rinkj/rinkj-epson870.c
> gs/devices/rinkj/rinkj-epson870.h
> gs/devices/rinkj/rinkj-screen-eb.c
> gs/devices/rinkj/rinkj-screen-eb.h
> gs/devices/vector/gdevagl.c
> gs/devices/vector/gdevagl.h
> gs/devices/vector/gdevlj56.c
> gs/devices/vector/gdevpdf.c
> gs/devices/vector/gdevpdfb.c
> gs/devices/vector/gdevpdfb.h
> gs/devices/vector/gdevpdfc.c
> gs/devices/vector/gdevpdfc.h
> gs/devices/vector/gdevpdfd.c
> gs/devices/vector/gdevpdfe.c
> gs/devices/vector/gdevpdfg.c
> gs/devices/vector/gdevpdfg.h
> gs/devices/vector/gdevpdfi.c
> gs/devices/vector/gdevpdfj.c
> gs/devices/vector/gdevpdfk.c
> gs/devices/vector/gdevpdfm.c
> gs/devices/vector/gdevpdfo.c
> gs/devices/vector/gdevpdfo.h
> gs/devices/vector/gdevpdfp.c
> gs/devices/vector/gdevpdfr.c
> gs/devices/vector/gdevpdft.c
> gs/devices/vector/gdevpdfu.c
> gs/devices/vector/gdevpdfv.c
> gs/devices/vector/gdevpdfx.h
> gs/devices/vector/gdevpdt.c
> gs/devices/vector/gdevpdt.h
> gs/devices/vector/gdevpdtb.c
> gs/devices/vector/gdevpdtb.h
> gs/devices/vector/gdevpdtc.c
> gs/devices/vector/gdevpdtd.c
> gs/devices/vector/gdevpdtd.h
> gs/devices/vector/gdevpdte.c
> gs/devices/vector/gdevpdtf.c
> gs/devices/vector/gdevpdtf.h
> gs/devices/vector/gdevpdti.c
> gs/devices/vector/gdevpdti.h
> gs/devices/vector/gdevpdts.c
> gs/devices/vector/gdevpdts.h
> gs/devices/vector/gdevpdtt.c
> gs/devices/vector/gdevpdtt.h
> gs/devices/vector/gdevpdtv.c
> gs/devices/vector/gdevpdtv.h
> gs/devices/vector/gdevpdtw.c
> gs/devices/vector/gdevpdtw.h
> gs/devices/vector/gdevpdtx.h
> gs/devices/vector/gdevps.c
> gs/devices/vector/gdevpsdf.h
> gs/devices/vector/gdevpsdi.c
> gs/devices/vector/gdevpsdp.c
> gs/devices/vector/gdevpsds.c
> gs/devices/vector/gdevpsds.h
> gs/devices/vector/gdevpsdu.c
> gs/devices/vector/gdevpsf.h
> gs/devices/vector/gdevpsf1.c
> gs/devices/vector/gdevpsf2.c
> gs/devices/vector/gdevpsfm.c
> gs/devices/vector/gdevpsft.c
> gs/devices/vector/gdevpsfu.c
> gs/devices/vector/gdevpsfx.c
> gs/devices/vector/gdevpsu.c
> gs/devices/vector/gdevpsu.h
> gs/devices/vector/gdevpx.c
> gs/devices/vector/gdevpxut.c
> gs/devices/vector/gdevpxut.h
> gs/devices/vector/gdevsvg.c
> gs/devices/vector/gdevtxtw.c
> gs/devices/vector/gdevxps.c
> gs/devices/vector/opdfread.h
> gs/devices/vector/whitelst.c
> gs/devices/vector/whitelst.h
> gs/psi/int.mak
> gs/psi/msvc.mak
> gs/psi/winint.mak
> gs/psi/zfapi.c
> main/pcl6_gcc.mak
> main/pcl6_msvc.mak
> pl/pl.mak
> svg/svg_gcc.mak
> svg/svg_msvc.mak
> xps/xps_gcc.mak
> xps/xps_msvc.mak

2013-03-06 01:43:29 -0500
Alex Cherepanov <alex.cherepanov@artifex.com>
6207ac0c8158b28bd2e9ff8633dd94fc91d98057

> Bug 693659: fix integer overflow in Type 2 font parser.
> gs/psi/zfont2.c

2013-03-06 00:44:26 -0500
Alex Cherepanov <alex.cherepanov@artifex.com>
4147f14b1460c35620cb117821fcb01f3b7a1e3d

> Bug 693659: Improve argument validation in ArcfourDecode operator.
> gs/psi/zfarc4.c

2013-03-05 19:08:49 -0800
Ray Johnston <ray.johnston@artifex.com>
70ba7029bc563bab7a24bff27decad5feceba4f8

> Fix indeterminate page background with plank and comparefiles/104-01.ps
> This file uses the PS erasepage operator to paint the background to
> a non-white value. The mem_planar_fill_rectangle_hl_color used the
> 'devn' colors without checking the type. With the plank device these
> colors were 'pure' or 'ht_binary' so the devn values were bogus.
> If the color type was binary, an address was used as color values.
> A pure color was OK as long as the number of planes did not exceed
> the size of the gx_color_index and the bytes in the color index
> corresponded to the planes.
> Also add warning (DEBUG build) if mem_planar_strip_tile_rect_devn
> ever uses non-devn colors.
> Progressions with 104-01.ps, 12-05.PS, 12-07B.PS and 29-07A.PS
> gs/base/gdevmpla.c
> gs/base/lib.mak

2013-03-05 22:24:56 -0500
Alex Cherepanov <alex.cherepanov@artifex.com>
04986f44befa8d71e64a94fafc31ee000c48cc78

> Bug 693659: Add check for 0 pointer to zlib message.
> gs/base/szlibd.c

2013-03-05 11:52:58 -0800
Ray Johnston <ray.johnston@artifex.com>
675682cee0a3dc6cd346084489712505f5ff3ee4

> Fix image_color_cache_init to avoid using out of range data.
> If the indexed color space hival is less than the num_entries in
> the color_cache, the code would just convert using values past
> the end of the lookup data, and image_render_mono_ht did not
> clamp values either.
> Seen with pbmraw sumatra/x_-_integer_overflow_in_fz_newpixmap.pdf
> This file shows clear progression, some other files show differences
> but all seem trivial and are pcl files. Maybe a ROP problem.
> gs/base/gxipixel.c

2013-03-05 12:48:14 -0500
Alex Cherepanov <alex.cherepanov@artifex.com>
69858556e95a2762ef48109ab7b265f2e87e2272

> Bug 693659: Fix access to /Colorants entry in DeviceN CSA.
> gs/psi/zcolor.c

2013-03-05 01:40:11 -0500
Alex Cherepanov <alex.cherepanov@artifex.com>
0950755f0dc971ebe2387a587688075751eb0905

> Bug 693659: Fix underflow checking in Type 2 parser.
> gs/psi/zfont2.c

2013-03-05 12:16:51 +0000
Chris Liddell <chris.liddell@artifex.com>
486ee97ee8e11cc1edce8998d0a85907c16721f5

> Bug 693674: introduce memory limit for UFST bitmaps
> Previously, UFST had "unlimited" memory for glyph bitmaps. This appears to allow
> bitmaps large enough to cause an overflow in the UFST rendering code.
> Now there is a limit on the memory UFST can allocate for a bitmap (tied to the
> maximum "interim" bitmap Ghostscript will allocate when creating an entry for
> the glyph cache).
> This has two benefits: prevents the crash by avoiding the rendering overflow in
> UFST, and prevents us from pointlessly allocating huge glyph bitmaps in cases
> where we really want to render from an outline anyway.
> No cluster differences.
> gs/base/gxchar.c
> gs/base/gxchar.h
> gs/base/gxfapi.c
> gs/base/gxfapiu.c

2013-03-05 10:29:02 +0000
Ken Sharp <ken.sharp@artifex.com>
26b50d7d18681f25ae0a435830fb291814b889b1

> pdfwrite - new colour code, fix image conversion to base space
> An oversight in the code led to images (other than imagemasks) not being
> converted to the specified process colour.
> No differences expected
> gs/base/gdevpdfi.c

2013-03-05 10:08:54 +0000
Ken Sharp <ken.sharp@artifex.com>
db3494dbb682781aca7651ffc60d80a8eeefec72

> pdfwrite - new colour code fix a Seg fault with Sep/DeviceN
> When converting Separation or DeviceN spaces to a device space we actually
> (currently) write them as ICCBased spaces. But the 'convert' flag was left
> at non-zero, leading to us attempting to convert. Since the original space
> wasn't recorded, this caused a seg fault.
> No differences expected
> gs/base/gdevpdfi.c

2013-03-04 20:43:19 -0800
Ray Johnston <ray.johnston@artifex.com>
1625318452fd5e8045b69ed440f17ce58625efce

> Further improvement and cleanup on clist_copy_planes and the reader.
> The clist writer clist_copy_planes (should be / is) never called with
> plane_height == 0, so we pre-calculate the maxheight and use that to
> clamp re.height, rather than doing the /=2 that copy_mono does. Also
> use data_bits_size rather than cbuf_size (even though they are currently
> the same) as the limit for holding all planes of uncmopressed data (for
> the reader call to copy_planes -- NOT including the compression tag byte)
> Also add documentation for copy_planes to doc/Drivers.htm
> 0002-Change-fill_rectanble_hl_color-calling-sequence-to-i.patch
> gs/base/gxclbits.c
> gs/base/gxcldev.h
> gs/base/gxclimag.c
> gs/base/gxclrast.c
> gs/base/gxclrect.c
> gs/base/gxht_thresh.c
> gs/base/gxp1fill.c
> gs/doc/Drivers.htm

2013-03-04 17:52:27 -0500
Alex Cherepanov <alex.cherepanov@artifex.com>
b4420888ddc9764177a89c1c3d36c64a1253f7b6

> Bug 693658: Add DSC continuation support to all operators.
> gs/psi/dscparse.c

2013-03-04 21:45:02 +0000
Ken Sharp <ken.sharp@artifex.com>
498b2eaa9c0476ba7a5223b554a620776a831442

> pdfwrite - fix a compiler warning
> gs/base/gdevpdfg.c

2013-03-04 15:04:07 +0000
Ken Sharp <ken.sharp@artifex.com>
e1c4496d4b0706d125b43dc9b0a8e3c4a1c93e50

> pdfwrite/ps2write - new colour work correct handling of complex /Indexed spaces
> Fix conversion of complex Indexed spaces to device spaces. There are some
> odd differences, which I think are due to some kind of rouding in the
> Indexed spaces, need to consult with Michael.
> No differences expected.
> gs/base/gdevpdfg.c

2013-03-04 09:53:22 +0000
Ken Sharp <ken.sharp@artifex.com>
2aab19e3b28a001b0f3d3b1424ee54078f420afb

> pdfwrite/ps2write - New colour conversion, fix default space detection
> When we get a /Indexed space, we check the base space and if it is an ICC
> space we further check to see if it is a space which we substituted for
> one of the device spaces, and if the current strategy means we should not
> convert such a space.
> Some missing braces meant that if the test failed we didn't write the colour
> space at all.
> No differences expected
> gs/base/gdevpdfg.c

2013-03-04 09:50:44 +0000
Ken Sharp <ken.sharp@artifex.com>
4b7bdcea310131174c051bf6f92b9dc2416bc9c3

> pdfwrite/ps2write - New colour code, remove suprious checks
> There are some checks against colour space conversions which are appropriate
> for the old code, but not the new, and which fall back to 'LeaveColorUnchanged'
> if triggered.
> Only perform these checks if we are using the old colour conversion code to
> prevent the warning and fallback.
> No differences expected.
> gs/base/gdevpdfc.c

2013-03-03 15:35:16 -0800
Ray Johnston <ray.johnston@artifex.com>
ef4a83251dc9e404deba855ff4838f405b81db3d

> Fix clist problems with writing and reading bitmaps when planes > 1
> When writing, plane data size did not include the height, so sometimes
> cmd_write_buffer would be called between writing the planes. During
> reading, we need to top up the cbuf for all planes including the first
> (pln==0). Also fix some formatting issues.
> gs/base/gxclrast.c
> gs/base/gxclrect.c

2013-03-02 20:48:34 -0800
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
da11422e0d11cad9a0de1615f11f525a1788c442

> Add the ability to write HSI compressed Raw files to fuzzy.c.
> gs/toolbin/tests/fuzzy.c

2013-03-02 21:06:19 -0700
Henry Stiles <henry.stiles@artifex.com>
b87b6dc49e4720cb8d4da0715a823263e84c5e85

> Merge branch 'newbranch' - should have been names xpswrite_branch.
> gs/base/Makefile.in
> gs/base/configure.ac
> gs/psi/msvc.mak
> main/pcl6_gcc.mak
> main/pcl6_msvc.mak

2013-03-02 20:37:28 -0700
Henry Stiles <henry.stiles@artifex.com>
c9c89a9628730bfdbe709023735206deb200b378

> Fix problem with multipage output in xpswrite.
> It turns out that any device graphics routine has to access the stream
> through the vector device call gdev_vector_stream() to guarantee
> beginpage will be called. A better solution to this problem would be
> to decouple the begin page procedure call and accessing the current
> stream.
> gs/base/gdevxps.c

2013-03-02 19:54:57 -0700
Henry Stiles <henry.stiles@artifex.com>
8b5840b6e797f2fa6c81c409dcbc14e51b207ab6

> A first rough cut of the XPS writing device.
> This version is limited to high level path drawing and rectangles so
> it is quite limited.
> gs/base/Makefile.in
> gs/base/configure.ac
> gs/base/devs.mak
> gs/base/gdevxps.c
> gs/psi/msvc.mak
> main/pcl6_gcc.mak
> main/pcl6_msvc.mak

2013-03-01 00:56:04 -0500
Math <mlafon@gmail.com>
7e04ea83379ea210c227f87c9e859e0a3ab2ebfd

> Bug 693507: check for out-of-bounds access
> Report error in get_next_word() functions on out-of-bounds access and
> handling of this error in both arithmetic and huffman decoders.
> When decoding a corrupted document, the arithmetic decoder can hit the end
> of the Jbig2 stream. The problem was that get_next_word() returned 0 in
> that case and that this lead to an infinite loop.
> gs/jbig2dec/jbig2.c
> gs/jbig2dec/jbig2_arith.c
> gs/jbig2dec/jbig2_arith_iaid.c
> gs/jbig2dec/jbig2_arith_int.c
> gs/jbig2dec/jbig2_generic.c
> gs/jbig2dec/jbig2_huffman.c
> gs/jbig2dec/jbig2_huffman.h
> gs/jbig2dec/jbig2_priv.h
> gs/jbig2dec/jbig2_refinement.c
> gs/jbig2dec/jbig2_symbol_dict.c
> gs/jbig2dec/jbig2_text.c

2013-02-28 13:57:05 -0800
Ray Johnston <ray.johnston@artifex.com>
9173f87798321425604340241a2ce3bf20ed9cf0

> Remove debug statement inadvertently committed with SMask fix.
> gs/Resource/Init/pdf_draw.ps

2013-02-28 15:58:39 +0000
Robin Watts <robin.watts@artifex.com>
3037c72c3fd81f11813c3a7fdc94a870e17e5c30

> Bug 693615: fix typos in utf8 conversion.
> Thanks to Chris Dance for pointing these out.
> gs/base/gp_wutf8.c

2013-02-26 12:04:54 -0800
Ray Johnston <ray.johnston@artifex.com>
a4e3e55ca44958a72a3879a565255a2acba8eae5

> Bug 693115: Fix Smask handling in the interpreter and prevent multiple rendering
> The SMask was being rendered before every object, and a subsequent SMask
> set with a 'gs' operator (ExtGState) was being rendered with a previous
> SMask rather than simply replacing it. By setting the SoftMask to a new
> value (neither //null, nor the paramdict) we can still detect that a
> SMask is in effect, and thus create transparency groups as needed, but
> we no longer render the mask multiple times, improving performance.
> In .execmaskgroup, after rendering the SMask into a mask_stack maskbuf,
> zap it, using 'where' to find the ExtGState dictionary that holds it.
> All differences seen with cluster regression are either progressions
> or are very minor except sumatra/VOX.pdf with pdfwrite, but this was
> broken previously. Now it's still broken, but differently.
> gs/Resource/Init/pdf_draw.ps
> gs/Resource/Init/pdf_ops.ps

2013-02-27 14:00:16 +0000
Robin Watts <robin.watts@artifex.com>
0df3602a923dff2e834fdd0191b6fd2b8ef523b5

> Fix Profile build on Windows
> It seems that the profile: target isn't being recognised in the makefile.
> Possibly because profile has special meaning to nmake? I cannot see an
> alternative profile: target anywhere in our makefiles.
> As a fix, I have added profile-target: and we now invoke that.
> gs/ghostscript.vcproj
> gs/psi/msvc.mak

2013-02-26 18:23:26 -0800
Michael Vrhel <michael.vrhel@artifex.com>
d6f83c3aec8ad94b013df125f9feae719c52b941

> Fix for an issue found in Bug 69365. Color space linearity check in shading code.
> The transparency device, if one exists should be used with this check.
> gs/base/gxshade6.c

2013-02-26 13:44:47 +0000
Robin Watts <robin.watts@artifex.com>
1f4996e6547bb89cbd92868224a2101c773c886b

> Avoid warning in gp_local_arg_encoding_get_codepoint.
> gs/base/gp_win32.c

2013-02-25 16:44:35 +0000
Ken Sharp <ken.sharp@artifex.com>
d62df7283d8618f92b2956b1d36e23c9f0075dd3

> txtwrite - fix fallback to single characters.
> There were some serious logical flaws in the Unicode creation, when there
> is no Unicode information available and we try to manufacture some.
> The glyph name matching was completely broken, and not only failed to match
> glyph names but broke the fallback to the original character codes too.
> This seems to do a much better job (and no longer crashes either).
> No differences expected, we don't test txtwrite
> gs/base/gdevtxtw.c

2013-02-25 08:22:15 -0800
Robin Watts <robin@peeves.(none)>
ce794d70d543d4d7de8615dcdc249516c05ff87b

> Bug 693655: Fix valgrind error in stroking.
> The code was treating gaps like dashes, which is fine
> except for the fact that gaps have no tangent entry
> and so we were accessing off the end of a buffer in some
> cases.
> gs/base/gxstroke.c

2013-02-25 08:02:00 +0000
Chris Liddell <chris.liddell@artifex.com>
c73f7af0cbd7305d8b61c2f3de973e8f163971d0

> Remove the executable bits from gdevsvg.c permissions.
> CLUSTER_UNTESTED
> gs/base/gdevsvg.c

2013-02-21 16:58:33 -0700
Henry Stiles <henry.stiles@artifex.com>
95f7ded85191aa93f0c6792cb7dccc0447c698bd

> Fix PXL PassThrough test file failure.
> C705.BIN failed due to unitialized PCL state variables when switching
> from PXL to PCL mode. Certainly this problem is a regression and must
> have happened when the new variables were added to PCL, but the fix is
> straightforward and we dispense with the usual postmortem history
> investigation.
> pxl/pxpthr.c

2013-02-21 19:40:22 +0000
Chris Liddell <chris.liddell@artifex.com>
380f18a0d97ce4b67b26e011aac391a4a1024b8e

> Update Make.htm....
> .. to reflect that we now support the "ppc" architecture for universal
> binaries on OS X.
> CLUSTER_UNTESTED
> gs/doc/Make.htm

2013-02-21 14:39:25 +0000
Chris Liddell <chris.liddell@artifex.com>
95ce731715a326cd345cd00b93bfc6e2588d8a33

> Bug 693645: Add a PPC section to the predefined MacOS X arch.h
> As a side effect of this, we should now be able to build universal binaries
> that include PPC.
> No cluster differences.
> gs/arch/osx-x86-x86_64-gcc.h
> gs/arch/osx-x86-x86_64-ppc-gcc.h
> gs/base/configure.ac

2013-02-20 12:14:45 -0500
Alex Cherepanov <alex.cherepanov@artifex.com>
52be57a96605ad59c0b3146611276e5ee237cb7e

> Bug 693646: Add /PageCount system parameter
> This parameter is documented in PLRM 3 and required by some test files.
> Genoa tests also require /PageCount to be non-decreasing even when
> the job switches between pagedevice and nulldevioce.
> gs/psi/icontext.c
> gs/psi/icstate.h
> gs/psi/zusparam.c

2013-02-19 10:40:32 +0000
Chris Liddell <chris.liddell@artifex.com>
f9bb4bd85d718e1db84d5f1e2a7685b0b3288df6

> Bug 693631: Handle a missing metric in the FAPI/UFST code.
> CLUSTER_UNTESTED
> gs/base/fapiufst.c

2013-02-18 11:34:06 +0000
Robin Watts <robin.watts@artifex.com>
fb3f60161917b1dcb04616a2787b4398be467603

> Bug 693212: Fix strange artifacts with thin lines.
> Ghostscript includes special code for 'thin' lines. These are
> a fudge at best.
> To avoid dropouts in such lines, caused by the end points of various
> lines not being drawn, we introduced a further fudge (see bug 687721).
> This would restore the end points on lines in some circumstances.
> This fudge causes the effect reported in bug 693212.
> The correct fix should be to completely remove thin line support from
> gs, as at best we are fudging a fudge. Given that this seems unlikely
> to happen, we will make do for now by tweaking the fudge introduced
> for bug 687721 so that it triggers in fewer cases (specifically, it
> will never trigger for horizontal or vertical lines).
> This is more in keeping with the intention of that change anyway.
> This does produce diffs, but no disastrous ones.
> gs/base/gdevddrw.c

2013-01-17 15:33:30 +0000
Robin Watts <robin.watts@artifex.com>
6811e33b61f3434af519b3af5e4d4aec742848ef

> pdf14_compose_group speedups
> Following on from previous commit (pdf14_mark_fill_rectangle speedups)
> we apply similar ideas to pdf14_compose_group.
> 1) Reverse loops to count downwards.
> 2) Increment tos_pixel and nos_pixel after each pixel to avoid having
> to add x to their index everywhere.
> 3) Reduce the number of variables used within the loop.
> These fixes do not go as far as the pdf14_mark_fill_rectangle ones
> did; there is still scope for more optimisations here.
> gs/base/gxblend1.c

2012-09-25 12:39:12 +0100
Robin Watts <robin.watts@artifex.com>
4c1a3aac35f1b4b7711c2e9e2f0f38fe121f51db

> Command line argument character encoding handling rework.
> Recap of the situation: Historically gs has always taken command
> line args in whatever the 'local' encoding of that OS is; for windows
> this means they are encoded as per the currently selected codepage;
> for mac/linux this tends to mean utf8.
> Similarly, whenever gs goes to access a file, it would pass the filenames
> to the platform specific file opening code - on windows this would
> assume that it was in the local encoding, and on linux would assume
> utf8.
> There are downsides to dealing with codepage encoding - not least the
> fact that some files can't be accessed easily, or that the behaviour
> of PS programs may change according to what platform we are on.
> Last year we added code so that gs on windows would run as a unicode app,
> and would take the supplied unicode argv and convert to utf8 before
> passing them to the core of gs. The file reading functions would then
> convert from utf8 back to unicode before opening the files. This
> code was disabled by default, but seemed to work well in tests.
> 1 objection was raised to this - namely that we were redefining the
> meaning of the entry points (to take utf8 rather than locally encoded
> args) and that this might break legacy code. So, it was suggested that
> we add a new entry point specifically for utf8, and that we deprecate
> the old entry point.
> In starting this work, I spotted another problem; gs supports the
> '@file' arg (where more command line args can be given in a file).
> The current solution of rewriting the command line args does not
> address this.
> Instead, we update the gsargs arg handling code with a 'get_codepoint'
> function pointer. We update the arg_next function to use this to
> decode the supplied args (or OPTIONS or file contents) into simple
> unicode characters. We then write these into the returned arg
> string as utf8 (or in the case of GS_NO_UTF8 builds, as 8 bit 'clean'
> characters).
> This commit adds a new gsapi_set_arg_encoding function, that allows
> the caller to set the encoding used for the args/strings supplied
> to the subsequent functions. By default, 'local' encoding is assumed,
> hence preserving existing behaviour. By calling:
> gs_set_arg_encoding(minst, GS_ARG_ENCODING_UTF8);
> we can get the UTF8 encoding that we desire. We leave ourselves scope
> for supporting other encodings (such as EBCDIC?) in the future.
> The commit also changes it so that the gs always runs with UTF8 encoding
> internally by default; to avoid it, make with 'GS_NO_UTF8=1'.
> For the benefit of windows users we implement UTF16LE encoding (i.e.
> wchar_t's). And we expose this through the gsapi level as
> gsapi_run_fileW (and gsapi_init_with_argsW) so that .net can bind
> nicely to it without any casting trickery being required.
> Many thanks to Sags for his tireless efforts and comments while
> this work was underway.
> gs/base/gdevwpr2.c
> gs/base/gp.h
> gs/base/gp_mswin.c
> gs/base/gp_ntfs.c
> gs/base/gp_wgetv.c
> gs/base/gp_win32.c
> gs/base/gp_wutf8.c
> gs/base/gsargs.c
> gs/base/gsargs.h
> gs/base/gsdll.h
> gs/base/windows_.h
> gs/doc/API.htm
> gs/psi/dwdll.c
> gs/psi/dwdll.h
> gs/psi/dwmain.c
> gs/psi/dwmainc.c
> gs/psi/dwnodll.c
> gs/psi/dwtext.c
> gs/psi/dwtext.h
> gs/psi/gsdll.c
> gs/psi/gsdll2.def
> gs/psi/gsdll32.def
> gs/psi/gsdll32metro.def
> gs/psi/gsdll64.def
> gs/psi/gsdll64metro.def
> gs/psi/iapi.c
> gs/psi/iapi.h
> gs/psi/imainarg.c
> gs/psi/imainarg.h
> gs/psi/iminst.h
> gs/psi/msvc.mak
> language_switch/pspcl6_msvc.mak
> main/pcl6_msvc.mak
> pl/dwmainc.c
> pl/plmain.c

2013-02-18 10:28:30 +0000
Robin Watts <robin.watts@artifex.com>
f8337b57ab9a311f19b86ed0508bdd0fef8fdded

> Remove repeated TAG settings.
> Spotted by Henry, these have been there since before time began (or
> since before the git history at least).
> gs/base/gspaint.c
> gs/base/gstext.c

2013-02-16 08:41:45 +0000
Chris Liddell <chris.liddell@artifex.com>
45ae250e1537eaf71367ac306154ee383a437b88

> Bug 693643: add UseBigTIFF initializers to tiffpack/lzw
> No cluster differences.
> gs/base/gdevtfax.c

2013-02-15 12:19:20 +0000
Ken Sharp <ken.sharp@artifex.com>
ed7fe80176219a7755b8c1fe12ff0ae23c536d49

> ps2write - improve handling of complex colour spaces
> Part of the rework on colour handling.
> When we write complex spaces (eg /Indexed with a /CIEBased space) and we
> use the underlying space (CIEBased) on its own, we only write the underlying
> space once, and refer to it form the complex space.
> However if we use the underlying space first, then it gets 'resolved', ie
> it has all the indirect references replaced. When we then use the complex
> space, any references in the underlying space have already been resolved.
> Normally this is not a problem because when we try to resolve any indirect
> references, we check to see if the object is an indirect reference by testing
> a number of its features. This works well but *if* the tint transform is
> already resolved, *and* it has fewer than 2 elements, then this would provoke
> an error, because the code did not test the length of the array (after already
> checking its type) before attempting to extract objects form it.
> This patch merely checks the array length and assumes it is not an indirect
> reference if the array is too short.
> No differences expected.
> gs/base/opdfread.h

2013-01-31 10:44:39 +0000
Chris Liddell <chris.liddell@artifex.com>
f39a68d4f1a1ba7674c5d57fa9347e01526fe6c3

> Merge the doc updates from 9.07 branch onto master
> Update documentation for release candidate 1
> Revise release date and product string for 9.07 release.
> Color feature news additions.
> gs/doc/API.htm
> gs/doc/C-style.htm
> gs/doc/Commprod.htm
> gs/doc/DLL.htm
> gs/doc/Deprecated.htm
> gs/doc/Details8.htm
> gs/doc/Details9.htm
> gs/doc/Develop.htm
> gs/doc/Devices.htm
> gs/doc/Drivers.htm
> gs/doc/Fonts.htm
> gs/doc/Helpers.htm
> gs/doc/History1.htm
> gs/doc/History2.htm
> gs/doc/History3.htm
> gs/doc/History4.htm
> gs/doc/History5.htm
> gs/doc/History6.htm
> gs/doc/History7.htm
> gs/doc/History8.htm
> gs/doc/History9.htm
> gs/doc/Install.htm
> gs/doc/Issues.htm
> gs/doc/Language.htm
> gs/doc/Lib.htm
> gs/doc/Make.htm
> gs/doc/News.htm
> gs/doc/Projects.htm
> gs/doc/Ps-style.htm
> gs/doc/Ps2epsi.htm
> gs/doc/Ps2pdf.htm
> gs/doc/Ps2ps2.htm
> gs/doc/Psfiles.htm
> gs/doc/Readme.htm
> gs/doc/Release.htm
> gs/doc/Source.htm
> gs/doc/Unix-lpr.htm
> gs/doc/Use.htm
> gs/doc/WhatIsGS.htm
> gs/doc/Xfonts.htm
> gs/doc/gs-vms.hlp
> gs/doc/thirdparty.htm
> gs/man/dvipdf.1
> gs/man/font2c.1
> gs/man/gs.1
> gs/man/gslp.1
> gs/man/gsnd.1
> gs/man/pdf2dsc.1
> gs/man/pdf2ps.1
> gs/man/pdfopt.1
> gs/man/pf2afm.1
> gs/man/pfbtopfa.1
> gs/man/printafm.1
> gs/man/ps2ascii.1
> gs/man/ps2epsi.1
> gs/man/ps2pdf.1
> gs/man/ps2pdfwr.1
> gs/man/ps2ps.1
> gs/man/wftopfa.1

2013-02-14 10:11:39 +0000
Ken Sharp <ken.sharp@artifex.com>
df71c577b5ff73c0ec8aa632d92ffbe90215e344

> ps2write - colour conversion work Indexed colour spaces
> When dealing with /Indexed colour spaces we concretize to the base space,
> if there is no ICC profile associated with the base space then we can't
> use it to get the number of colour components to convert, so use the
> base space Num_components instead.
> Prevents crashes with Indexed spaces with complex base types (for example
> /CIEBased spaces)
> No differences expected.
> gs/base/gdevpdfg.c

2013-02-14 08:23:49 +0000
Ken Sharp <ken.sharp@artifex.com>
329259532c31ba1b762cdea12d64a332ee0d2cf8

> pdfwrite - include a definition to silence a compiler warning
> gs/base/gdevpdfg.c

2013-02-13 13:44:54 +0000
Ken Sharp <ken.sharp@artifex.com>
536e65260e103bc37705f03350ec4b01c37515a0

> ps2write - detect the 'standard' ICC replacements for device space
> When we get an ICCBased space which is our replacement for one of the device
> spaces, detect it and emit the original space instead.
> Should lead to many more device spaces being preserved properly when the
> colour conversion strategy is LeaveColorUnchanged.
> No differences expected
> gs/base/gdevpdfg.c

2013-02-13 08:17:20 +0000
Ken Sharp <ken.sharp@artifex.com>
9220fe3bacb5a8b82cc7a6b25fb8d6db2456b0da

> pdfwrite - silence more compiler warnings
> gs/base/gdevpdfp.c

2013-02-13 08:17:03 +0000
Ken Sharp <ken.sharp@artifex.com>
b4b0bc9738f132c21ea2f5e8a15c60422bee1e5b

> pdfwrite - silence some compiler warnings
> gs/base/gdevpsds.c

2013-02-12 12:47:02 -0800
Ray Johnston <ray.johnston@artifex.com>
6b6dabb3ce69162c88a616a61f086164cbe91460

> Initial commit of the Stochastic Threshold Array generation program.
> gs/toolbin/halftone/gen_stochastic/gen_stochastic.c
> gs/toolbin/halftone/gen_stochastic/gen_stochastic.sln
> gs/toolbin/halftone/gen_stochastic/gen_stochastic.vcproj

2013-02-12 09:08:03 -0800
Michael Vrhel <michael.vrhel@artifex.com>
389fbbbc82693094357d95276a4362d701e380b1

> Update header in screen generation code.
> gs/toolbin/halftone/gen_ordered/gen_ordered.c

2013-02-12 14:57:06 +0000
Ken Sharp <ken.sharp@artifex.com>
602e9553829fe955055da289ca010d72e7b86f7f

> pdfwrite/ps2write - first part of reworking colour management
> This commit provides a new path through the pdfwrite code and uses the ICC
> CMS for linework/text, which it did not previously use. The image code already#
> used the CMS, at least in part.
> There is a 'place holder' switch called PDFUseOldCMS, defaulting to true
> at the moment, which controls whether we use the old path or the new.
> The new colour code already shows marked improvements with the LeaveColorUnchanged,
> in particular /Separation and /Indexed /Device* colour spaces are now preserved
> when going to PostScript, which they were not before.
> There are also some changes which affect the embedding of ICCBased spaces, and seem
> to improve a small number of these.
> When enabled this does cause a *large* number of differences, however these
> are all either progressions, or very minor differences, invisible to the naked eye.
> gs/base/gdevpdfb.h
> gs/base/gdevpdfg.c
> gs/base/gdevpdfi.c
> gs/base/gdevpdfk.c
> gs/base/gdevpdfp.c
> gs/base/gdevpdfx.h
> gs/base/gdevpsdf.h
> gs/base/gdevpsdi.c
> gs/base/gdevpsds.c
> gs/base/gdevpsds.h

2013-02-11 13:19:09 +0000
Ken Sharp <ken.sharp@artifex.com>
12798e902f56cc647fbf213ad632d52114b90687

> pdfwrite - fix type 1 to type 2 font converter
> Bug #693633 "Font character missing in PDF output - appears in other devices and older versions"
> Type 2 fonts are required to start the path operations with a moveto class
> operation, not a lineto, type 1 fonts do not have this restriction. So when
> converting from type 1 to type 2 we must detect if the initial operation is
> a 'line' or a 'move' and emit an explcit 'move' in the case where the first
> operation is a line.
> The code to do this was assuming that if there were operands on the stack
> this meant that the glyph width (from the hsbw operator) was present.
> However, this is not true if the font contains any hinting operations as
> the width must be emitted as part of those hints.
> This caused the code to emit confused and invalid type 2 CharStrings.
> Fixed by adding a boolean to track whether the stack contains the glyph
> width or not, and test that instead of the number of operands.
> No differences expected
> gs/base/gdevpsfx.c

2013-02-07 14:42:10 -0800
Ray Johnston <ray.johnston@artifex.com>
f15e0f899fd19162d5de8e0963c58f160bd49796

> Bug 693621: Clist logic didn't properly reset after erasepage.
> The "normal" page rendering logic works because it flushes the buffer
> memory to the clist, then after the page is printed, it clears out
> the clist data for the next page. By changing the clist_fillpage to
> do this (without actually rendering anything) we now clear out the
> clist for a new page. This has the advantage that any clist operations
> accumulated prior to the fillpage will be discarded, INCLUDING any
> previous fillpage operations which gets rid of duplicate fillpage
> actions which can be time consuming, particularly on embedded systems
> or printers.
> gs/base/gxclrect.c

2013-02-07 17:51:46 -0500
Alex Cherepanov <alex.cherepanov@artifex.com>
415da137afa2a64cdd6e2bc679c3c269e0d96c73

> Bug 693617: Don't allow nesting of BT operators.
> Check whether BT operator is executed in a text context and close
> the external context.
> gs/Resource/Init/pdf_ops.ps

2013-02-06 16:55:44 -0500
Alex Cherepanov <alex.cherepanov@artifex.com>
591a6e95b11f07611f612a691c7e06e169c1fe93

> Bug 392622: Fix handling of big CMap objects.
> Add a missing error code check, which caused SEGV when an index points
> beyond the CMap. Fix PS code that truncated CMmaps to 2^17 - 4 bytes.
> gs/Resource/Init/pdf_font.ps
> gs/psi/zfapi.c

2013-02-06 10:17:26 -0700
Henry Stiles <henrys@henrysx6.(none)>
a6628fdb771f71c20ad55db026de79d507b42e03

> Remove unused GC definitions and declarations.
> PCL does not use garbage collection. Having unused definitions
> clutters up the code and gives the false impression the code will work
> with the ghostscript garbage collector built in. The various routines
> to enumerate and relocate pointers have never been maintained and are
> surely out of date.
> pcl/pccid.h
> pcl/pccsbase.c
> pcl/pccsbase.h
> pcl/pcdither.c
> pcl/pcdither.h
> pcl/pcdraw.c
> pcl/pcfrgrnd.c
> pcl/pcfrgrnd.h
> pcl/pcht.c
> pcl/pcht.h
> pcl/pcindxed.c
> pcl/pcindxed.h
> pcl/pclookup.c
> pcl/pclookup.h
> pcl/pcpalet.c
> pcl/pcpalet.h
> pcl/pcpatrn.c
> pcl/pcpatrn.h
> pcl/pcpattyp.h
> pcl/pcuptrn.c
> pcl/rtraster.c
> pcl/rtrstcmp.h
> pxl/pxgstate.h
> pxl/pximage.c
> pxl/pxparse.c

2012-08-01 14:07:49 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
53e2990bde0966173a954e51c388e4d26af40c15

> Fix lcms2 64-bit value decoding on big endian systems
> that lack 64-bit types or have these types missed by configuration.
> Conflicts:
> gs/lcms2/src/cmsplugin.c
> gs/lcms2/src/cmsplugin.c

2013-02-04 18:15:39 -0700
Henry Stiles <henry.stiles@artifex.com>
81d51fb27178b2a218403ffe350695f27cfa76dd

> Fixes Bug 693616 - GhostPCL locks up with -dFirstPage.
> The GL/2 parser should cancel the current command for errors or it is
> possible for the parser to continue without advancing causing an
> infinite loop.
> pcl/pgconfig.c
> pcl/pgparse.c

2013-02-04 14:01:09 -0700
Henry Stiles <henry.stiles@artifex.com>
a14ef732dade2dce6de07edf3a4c10294671a11e

> Fix bug #693608 duplexing command not feeding page.
> The PCL select side duplex command does a formfeed unconditionally,
> the other duplex command which sets the duplexing mode does a
> conditional (if page is marked form feed). Before this fix we had
> both conditionally feed.
> pcl/pcjob.c

2013-02-04 18:32:32 +0000
Ken Sharp <ken.sharp@artifex.com>
25291a2f9b01504fbbe70153c07920b016b9f010

> pdfwrite - alter escapement of text strings in outlines
> Bug 693614 "pdfmark: accented character "c" in titles of generated
> PDF bookmarks is not displayed properly"
> I believe this is actually an Acrobat bug, the text string emits the
> Unicode 0x01 0x0d as a binary 0x01 and an escaped character '\n'. This
> follows the rulses for text strings. However Acrobat files to display
> the Title correctly.
> Running the file through Distiller I find that the string is emitted as
> 0x01 '\015', the octal representation of 0x0d.
> This commit alters the escapement of characters in outlines so that they
> always end up as octal escapes. This seems to pacify Acrobat.
> No differences expected
> gs/base/gdevpdfm.c

2013-02-04 09:56:21 +0000
Ken Sharp <ken.sharp@artifex.com>
2b0a50081bc45d7b28b4c3dcb1a19a46a66d4216

> pdfwrite - fix bug with 64-bit file offsets to permit large files
> Bug #693610 " Regression: pdfwrite seg fault with the 32 bit build
> starting with 9b10f8c659ffc643ab71c6180a70da4f39075578"
> When doing the work to use 64-bit file offsets, and thus permit files in
> excess of 4GB, I missed an instance.When creating the xref table, if an
> object is unused (which is rare but possible), we need to scan past it in
> the xref offsets temporary file. We do this by calculating the position of
> the next object id in the file.
> However, instead of using the size of a gp_offset_t (which is what is written
> into the file) we were still using the size of an unsigned long. Because
> these are the same on a 64-bit build the regular cluster test doesn't catch
> this.
> Fixed simply by using the correct size. No differences expected, as explained
> above this only exhibits on platforms where gp_offset_t and unsigned long
> have different sizes.
> gs/base/gdevpdf.c

2013-01-30 16:36:00 +0000
Chris Liddell <chris.liddell@artifex.com>
060b8b1f34bb73a44978729dd3a49db25861bbab

> pdfwrite: don't try to free static allocated string
> If a font is identified as one of the base 14, the font name in BaseFont is
> just a pointer to the entry in the statically declared "standard_font_info"
> table.
> Avoid freeing the name if it's marked "is_standard".
> No cluster differences.
> gs/base/gdevpdtf.c

2013-01-30 16:22:21 -0700
Henry Stiles <henry.stiles@artifex.com>
e982362054609c92d84aa9688246e39a65c4d860

> Bug 693030 - duplexing page problem fixed in PXL output device.
> Upon media changes or even duplexing changes the PXL device did not
> switch back to the front page. Thanks to Hin-Tak Leung for fixing
> this.
> gs/base/gdevpx.c
> gs/base/gdevpxut.c

2013-01-30 14:07:41 -0700
Henry Stiles <henry.stiles@artifex.com>
140bfcf881a24e4f915e467a89b8a96592551846

> Fix Bug #692914 - Postscript MediaType lost.
> Thanks to Hin-Tak Leung for adding support for MediaType to PXL output
> drivers.
> gs/base/gdevlj56.c
> gs/base/gdevpx.c
> gs/base/gdevpxut.c
> gs/base/gdevpxut.h

2013-01-30 13:51:51 +0000
Chris Liddell <chris.liddell@artifex.com>
9fb635f0a6e1695b7a88822c75e22d40a9ba5116

> Bug 693572 (redux): handle missing a glyph outline - again.
> It turns out that some devices (pdfwrite!) have a problem with receiving a
> completely empty path for an outline glyph, so......
> If the outline is missing, create a path with just a moveto and closepath.
> No cluster differences.
> gs/base/fapi_ft.c

2013-01-30 13:37:47 +0000
Chris Liddell <chris.liddell@artifex.com>
508a79ca38cb857229f0e29236e95059a8d54799

> Bug 693398: avoid marking/reloc'ing unsuitable pointer
> The gx_image_enum object contains a pointer (cie_range) to the CIE range in
> the color space, if it's for an image in certain types of CIE space. The
> pointer points *into* an area of allocated memory, and not to the "top" of
> the allocated block. As a result, when garbage collection tries to relocate,
> there isn't a valid header structure, and the values it ends up using for the
> relocation are nonsense.
> Removing the cie_range pointer from the GC pointer enumeration is not
> because the color space structure and it's contents can move. Since this is
> a fairly rare case, and the CIE range lookup is trivial, the cie_range
> pointer is replaced with a boolean (so we decide *whether* to use the range
> only once), and then the range itself is retrieved at the time it's used.
> No cluster differences.
> gs/base/gxi12bit.c
> gs/base/gxicolor.c
> gs/base/gximage.h
> gs/base/gximono.c
> gs/base/gxipixel.c

2013-01-27 14:03:05 -0800
Ray Johnston <ray.johnston@artifex.com>
803a59ecfd925dafe325d263ecf0a1734113ffef

> Bug 693590: MT rendering has wrong 'supports_devn' and incomplete color_info
> Shadings use the comp_bits, comp_mask and comp_shift which must match
> the main thread's setting, so we copy the color_info from the clist
> device.
> Also the thread's icc_struct->supports_devn must correspond to the main
> thread's device (regressions with psdcmyk detected this).
> gs/base/gxclthrd.c

2013-01-29 17:45:45 -0500
Alex Cherepanov <alex.cherepanov@artifex.com>
1ae60ab98eef2d376b65f9c50ba2840b1577030b

> Bug 693026: Fix SEGV when @FILE can't open.
> Argument processing happens early during Ghostscript start-up process.
> Be prepared, that not all structures have been initialized yet.
> gs/base/gsargs.c
> gs/base/gsargs.h
> gs/base/gsiodev.c
> gs/psi/imainarg.c
> pl/plmain.c

2013-01-29 15:12:04 +0000
Chris Liddell <chris.liddell@artifex.com>
f372552beb9105a8768b6b3002bf29b6a7b7278b

> Bug 693599: Change the function configure checks for in liblcms2.
> The lcms2 API changed at 2.2, adding the cmsGetTransformOutputFormat()
> call. When we're checking if we can use the system's lcms2, change the
> autoconf check to look for cmsGetTransformOutputFormat().
> No cluster differences.
> gs/base/configure.ac

2013-01-29 10:32:30 +0000
Chris Liddell <chris.liddell@artifex.com>
56337a050812f072a2669b395119e016cb750e60

> Add the make fix from 1fbd0191 to the Mac specific subtarget.
> CLUSTER_UNTESTED
> gs/base/unix-dll.mak

2013-01-29 10:12:00 +0000
Chris Liddell <chris.liddell@artifex.com>
1fbd0191d1801fc49e362374a7ca6a387e03b9f8

> Work around a make problem with "so" target
> GNU make 3.82 appears to have a bug which causes problems with our "so"
> targets. The "so" targets rely on recursice make calls to build various
> subtargets, the shared library and the two executables that link to the shared
> library.
> On the final recursive make call (to build the executables), GNU make 3.82
> wrongly identifies that one dependency (psbase.dev) has changed, and decides it
> must rebuild the shared library. By this stage, however, the compiler options
> have been setup to build an executable, rather than the shared library.
> As a result, we build an executable with the name of the shared lib, and
> then try to link that into an executable, which results in linker errors.
> As it happens, the use of recursive make calls means we can safely drop a
> dependency, which will prevent make from re-evaluating the problematic target,
> and thus avoiding the problem arising.
> CLUSTER_UNTESTED
> gs/base/unix-dll.mak

2013-01-29 09:30:56 +0000
Chris Liddell <chris.liddell@artifex.com>
980a1a28a010fcbfa62208f022454e5fa6b8dc2c

> Bump version number to 9.08.
> gs/Resource/Init/gs_init.ps
> gs/base/version.mak

2013-02-12 15:44:33 +0000
Chris Liddell <chris.liddell@artifex.com>
76b4193e5d8cb280f4795b0e959657ad695ad54d

> Revise release date and product string for 9.07 release.
> Color feature news additions.
> gs/base/gscdef.c
> gs/base/version.mak
> gs/doc/API.htm
> gs/doc/C-style.htm
> gs/doc/Commprod.htm
> gs/doc/DLL.htm
> gs/doc/Deprecated.htm
> gs/doc/Details8.htm
> gs/doc/Details9.htm
> gs/doc/Develop.htm
> gs/doc/Devices.htm
> gs/doc/Drivers.htm
> gs/doc/Fonts.htm
> gs/doc/Helpers.htm
> gs/doc/History1.htm
> gs/doc/History2.htm
> gs/doc/History3.htm
> gs/doc/History4.htm
> gs/doc/History5.htm
> gs/doc/History6.htm
> gs/doc/History7.htm
> gs/doc/History8.htm
> gs/doc/History9.htm
> gs/doc/Install.htm
> gs/doc/Issues.htm
> gs/doc/Language.htm
> gs/doc/Lib.htm
> gs/doc/Make.htm
> gs/doc/News.htm
> gs/doc/Projects.htm
> gs/doc/Ps-style.htm
> gs/doc/Ps2epsi.htm
> gs/doc/Ps2pdf.htm
> gs/doc/Ps2ps2.htm
> gs/doc/Psfiles.htm
> gs/doc/Readme.htm
> gs/doc/Release.htm
> gs/doc/Source.htm
> gs/doc/Unix-lpr.htm
> gs/doc/Use.htm
> gs/doc/WhatIsGS.htm
> gs/doc/Xfonts.htm
> gs/doc/gs-vms.hlp
> gs/doc/thirdparty.htm
> gs/man/dvipdf.1
> gs/man/font2c.1
> gs/man/gs.1
> gs/man/gslp.1
> gs/man/gsnd.1
> gs/man/pdf2dsc.1
> gs/man/pdf2ps.1
> gs/man/pdfopt.1
> gs/man/pf2afm.1
> gs/man/pfbtopfa.1
> gs/man/printafm.1
> gs/man/ps2ascii.1
> gs/man/ps2epsi.1
> gs/man/ps2pdf.1
> gs/man/ps2pdfwr.1
> gs/man/ps2ps.1
> gs/man/wftopfa.1

2012-08-01 14:07:49 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
8fbcb3a68ca46ff9f56863d19a7c3342b53c220e

> Fix lcms2 64-bit value decoding on big endian systems
> that lack 64-bit types or have these types missed by configuration.
> Conflicts:
> gs/lcms2/src/cmsplugin.c
> gs/lcms2/src/cmsplugin.c

2013-01-31 10:44:39 +0000
Chris Liddell <chris.liddell@artifex.com>
885d3646213fc2dfacf7a49d6d546e15eaff190e

> Update documentation for release candidate 1
> gs/doc/API.htm
> gs/doc/C-style.htm
> gs/doc/Commprod.htm
> gs/doc/DLL.htm
> gs/doc/Deprecated.htm
> gs/doc/Details8.htm
> gs/doc/Details9.htm
> gs/doc/Develop.htm
> gs/doc/Devices.htm
> gs/doc/Drivers.htm
> gs/doc/Fonts.htm
> gs/doc/Helpers.htm
> gs/doc/History1.htm
> gs/doc/History2.htm
> gs/doc/History3.htm
> gs/doc/History4.htm
> gs/doc/History5.htm
> gs/doc/History6.htm
> gs/doc/History7.htm
> gs/doc/History8.htm
> gs/doc/History9.htm
> gs/doc/Install.htm
> gs/doc/Issues.htm
> gs/doc/Language.htm
> gs/doc/Lib.htm
> gs/doc/Make.htm
> gs/doc/News.htm
> gs/doc/Projects.htm
> gs/doc/Ps-style.htm
> gs/doc/Ps2epsi.htm
> gs/doc/Ps2pdf.htm
> gs/doc/Ps2ps2.htm
> gs/doc/Psfiles.htm
> gs/doc/Readme.htm
> gs/doc/Release.htm
> gs/doc/Source.htm
> gs/doc/Unix-lpr.htm
> gs/doc/Use.htm
> gs/doc/WhatIsGS.htm
> gs/doc/Xfonts.htm
> gs/doc/gs-vms.hlp
> gs/doc/thirdparty.htm
> gs/man/dvipdf.1
> gs/man/font2c.1
> gs/man/gs.1
> gs/man/gslp.1
> gs/man/gsnd.1
> gs/man/pdf2dsc.1
> gs/man/pdf2ps.1
> gs/man/pdfopt.1
> gs/man/pf2afm.1
> gs/man/pfbtopfa.1
> gs/man/printafm.1
> gs/man/ps2ascii.1
> gs/man/ps2epsi.1
> gs/man/ps2pdf.1
> gs/man/ps2pdfwr.1
> gs/man/ps2ps.1
> gs/man/wftopfa.1

2013-01-31 09:28:04 +0000
Chris Liddell <chris.liddell@artifex.com>
dbcde58e3c01b4b9f996d9e962a074e46697698d

> Add "Release Candidate 1" to GS_PRODUCTFAMILY
> Fix release date.
> gs/base/gscdef.c
> gs/base/version.mak

2013-01-30 16:22:21 -0700
Henry Stiles <henry.stiles@artifex.com>
1db3e495532a23b3c736dd54215ecb82374837fe

> Bug 693030 - duplexing page problem fixed in PXL output device.
> Upon media changes or even duplexing changes the PXL device did not
> switch back to the front page. Thanks to Hin-Tak Leung for fixing
> this.
> gs/base/gdevpx.c
> gs/base/gdevpxut.c

2013-01-30 14:07:41 -0700
Henry Stiles <henry.stiles@artifex.com>
6e13685e1768771f87c94bdb2aaaab4d011d601c

> Fix Bug #692914 - Postscript MediaType lost.
> Thanks to Hin-Tak Leung for adding support for MediaType to PXL output
> drivers.
> gs/base/gdevlj56.c
> gs/base/gdevpx.c
> gs/base/gdevpxut.c
> gs/base/gdevpxut.h

2013-01-30 13:51:51 +0000
Chris Liddell <chris.liddell@artifex.com>
9c11bdaf7701b2736060ce291ae22fb0105ffaf5

> Bug 693572 (redux): handle missing a glyph outline - again.
> It turns out that some devices (pdfwrite!) have a problem with receiving a
> completely empty path for an outline glyph, so......
> If the outline is missing, create a path with just a moveto and closepath.
> No cluster differences.
> gs/base/fapi_ft.c

2013-01-30 13:37:47 +0000
Chris Liddell <chris.liddell@artifex.com>
4704c9dc5d345fa6d81513fe9d5ea13aa199ae01

> Bug 693398: avoid marking/reloc'ing unsuitable pointer
> The gx_image_enum object contains a pointer (cie_range) to the CIE range in
> the color space, if it's for an image in certain types of CIE space. The
> pointer points *into* an area of allocated memory, and not to the "top" of
> the allocated block. As a result, when garbage collection tries to relocate,
> there isn't a valid header structure, and the values it ends up using for the
> relocation are nonsense.
> Removing the cie_range pointer from the GC pointer enumeration is not
> because the color space structure and it's contents can move. Since this is
> a fairly rare case, and the CIE range lookup is trivial, the cie_range
> pointer is replaced with a boolean (so we decide *whether* to use the range
> only once), and then the range itself is retrieved at the time it's used.
> No cluster differences.
> gs/base/gxi12bit.c
> gs/base/gxicolor.c
> gs/base/gximage.h
> gs/base/gximono.c
> gs/base/gxipixel.c

2013-01-29 17:45:45 -0500
Alex Cherepanov <alex.cherepanov@artifex.com>
295a195f85ced8b965f65bbc1fe6c3cf78c36e51

> Bug 693026: Fix SEGV when @FILE can't open.
> Argument processing happens early during Ghostscript start-up process.
> Be prepared, that not all structures have been initialized yet.
> gs/base/gsargs.c
> gs/base/gsargs.h
> gs/base/gsiodev.c
> gs/psi/imainarg.c
> pl/plmain.c

2013-01-27 14:03:05 -0800
Ray Johnston <ray.johnston@artifex.com>
ab9615d43302f03ce57fdd8e849ec52e870983e4

> Bug 693590: MT rendering has wrong 'supports_devn' and incomplete color_info
> Shadings use the comp_bits, comp_mask and comp_shift which must match
> the main thread's setting, so we copy the color_info from the clist
> device.
> Also the thread's icc_struct->supports_devn must correspond to the main
> thread's device (regressions with psdcmyk detected this).
> gs/base/gxclthrd.c

2013-01-29 15:12:04 +0000
Chris Liddell <chris.liddell@artifex.com>
62df74b7ef081a9f35028b493843a4624048f7af

> Bug 693599: Change the function configure checks for in liblcms2.
> The lcms2 API changed at 2.2, adding the cmsGetTransformOutputFormat()
> call. When we're checking if we can use the system's lcms2, change the
> autoconf check to look for cmsGetTransformOutputFormat().
> No cluster differences.
> gs/base/configure.ac

2013-01-29 10:32:30 +0000
Chris Liddell <chris.liddell@artifex.com>
3c7aa3543e098620d70c5df143513718d3e83b12

> Add the make fix from 1fbd0191 to the Mac specific subtarget.
> CLUSTER_UNTESTED
> gs/base/unix-dll.mak

2013-01-29 10:12:00 +0000
Chris Liddell <chris.liddell@artifex.com>
3233283cfe4370fb826998d14954e4870155c80e

> Work around a make problem with "so" target
> GNU make 3.82 appears to have a bug which causes problems with our "so"
> targets. The "so" targets rely on recursice make calls to build various
> subtargets, the shared library and the two executables that link to the shared
> library.
> On the final recursive make call (to build the executables), GNU make 3.82
> wrongly identifies that one dependency (psbase.dev) has changed, and decides it
> must rebuild the shared library. By this stage, however, the compiler options
> have been setup to build an executable, rather than the shared library.
> As a result, we build an executable with the name of the shared lib, and
> then try to link that into an executable, which results in linker errors.
> As it happens, the use of recursive make calls means we can safely drop a
> dependency, which will prevent make from re-evaluating the problematic target,
> and thus avoiding the problem arising.
> CLUSTER_UNTESTED
> gs/base/unix-dll.mak

## Version 9.09 (2013-02-14)

The 9.09 release was quickly superseded by 9.10 after a bug was found that prevented -dUeCIEColor from working was discovered. Please use 9.10.

## Version 9.07 (2013-02-14)

This is the seventh full release in the stable 9.x series.

Highlights in this release include:

- As of this release (9.07), Ghostscript and GhostPDL are distributed under the GNU Affero General Public License (AGPL).

- Ghostscript now has the option to be built as thread safe. Note that not all devices are thread safe. See the GS_THREADSAFE option in: GS_THREADSAFE

- The pdfwrite devices now supports linearized (or optimized for fast web view) output directly ("-dFastWebView")

- The Font API (FAPI) has been moved from the Postscript interpreter (psi) into the graphics library (base), and extended to support the other languages (PCL/PXL/XPS). All interpreters now use Freetype by default to render all viable font types.

- Ghostscript has been extended to support Postscript string and array objects with >64k entries.

- Ghostscript has been extended to support file sizes >4Gb - in particular reading and writing PDF files. As a side effect of this, Ghostscript also now supports 64 bit Postscript integer objects.

- All CMYK devices can now support simulated overprint of spot colors using the "-dSimulateOverprint" command line option.

- Support for use of DeviceN ICC color profiles as the output profile with the tiffsep and psdcmyk devices.

- Support for customized named color handling with DeviceN colors

- Support for black point compensation

- Support for K preservation in CMYK to CMYK conversions

- Support for DeviceLink profiles for graphic, image and text objects

- Support for custom color replacement

- Increased control in specifying color conversions as a function of object type

  Full details of the color management features can be found in: GS9_Color_Management.pdf

- Provide BigTIFF output option: the tiff devices can write BigTIFF files using the "-dUseBigTIFF" option. This requires libtiff version >=4.0.0 (the option is ignored for versions <4.0.0)

- LittleCMS updated to 2.4

- Plus the usual round of bug fixes, compatibility changes, and incremental improvements.

For a list of open issues, or to report problems, please visit bugs.ghostscript.com.

### Incompatible changes

No recorded incompatible changes.

### Changelog

2013-01-30 16:22:21 -0700
Henry Stiles <henry.stiles@artifex.com>
1db3e495532a23b3c736dd54215ecb82374837fe

> Bug 693030 - duplexing page problem fixed in PXL output device.
> Upon media changes or even duplexing changes the PXL device did not
> switch back to the front page. Thanks to Hin-Tak Leung for fixing
> this.
> gs/base/gdevpx.c
> gs/base/gdevpxut.c

2013-01-30 14:07:41 -0700
Henry Stiles <henry.stiles@artifex.com>
6e13685e1768771f87c94bdb2aaaab4d011d601c

> Fix Bug #692914 - Postscript MediaType lost.
> Thanks to Hin-Tak Leung for adding support for MediaType to PXL output
> drivers.
> gs/base/gdevlj56.c
> gs/base/gdevpx.c
> gs/base/gdevpxut.c
> gs/base/gdevpxut.h

2013-01-30 13:51:51 +0000
Chris Liddell <chris.liddell@artifex.com>
9c11bdaf7701b2736060ce291ae22fb0105ffaf5

> Bug 693572 (redux): handle missing a glyph outline - again.
> It turns out that some devices (pdfwrite!) have a problem with receiving a
> completely empty path for an outline glyph, so......
> If the outline is missing, create a path with just a moveto and closepath.
> No cluster differences.
> gs/base/fapi_ft.c

2013-01-30 13:37:47 +0000
Chris Liddell <chris.liddell@artifex.com>
4704c9dc5d345fa6d81513fe9d5ea13aa199ae01

> Bug 693398: avoid marking/reloc'ing unsuitable pointer
> The gx_image_enum object contains a pointer (cie_range) to the CIE range in
> the color space, if it's for an image in certain types of CIE space. The
> pointer points *into* an area of allocated memory, and not to the "top" of
> the allocated block. As a result, when garbage collection tries to relocate,
> there isn't a valid header structure, and the values it ends up using for the
> relocation are nonsense.
> Removing the cie_range pointer from the GC pointer enumeration is not
> because the color space structure and it's contents can move. Since this is
> a fairly rare case, and the CIE range lookup is trivial, the cie_range
> pointer is replaced with a boolean (so we decide *whether* to use the range
> only once), and then the range itself is retrieved at the time it's used.
> No cluster differences.
> gs/base/gxi12bit.c
> gs/base/gxicolor.c
> gs/base/gximage.h
> gs/base/gximono.c
> gs/base/gxipixel.c

2013-01-29 17:45:45 -0500
Alex Cherepanov <alex.cherepanov@artifex.com>
295a195f85ced8b965f65bbc1fe6c3cf78c36e51

> Bug 693026: Fix SEGV when @FILE can't open.
> Argument processing happens early during Ghostscript start-up process.
> Be prepared, that not all structures have been initialized yet.
> gs/base/gsargs.c
> gs/base/gsargs.h
> gs/base/gsiodev.c
> gs/psi/imainarg.c
> pl/plmain.c

2013-01-27 14:03:05 -0800
Ray Johnston <ray.johnston@artifex.com>
ab9615d43302f03ce57fdd8e849ec52e870983e4

> Bug 693590: MT rendering has wrong 'supports_devn' and incomplete color_info
> Shadings use the comp_bits, comp_mask and comp_shift which must match
> the main thread's setting, so we copy the color_info from the clist
> device.
> Also the thread's icc_struct->supports_devn must correspond to the main
> thread's device (regressions with psdcmyk detected this).
> gs/base/gxclthrd.c

2013-01-29 15:12:04 +0000
Chris Liddell <chris.liddell@artifex.com>
62df74b7ef081a9f35028b493843a4624048f7af

> Bug 693599: Change the function configure checks for in liblcms2.
> The lcms2 API changed at 2.2, adding the cmsGetTransformOutputFormat()
> call. When we're checking if we can use the system's lcms2, change the
> autoconf check to look for cmsGetTransformOutputFormat().
> No cluster differences.
> gs/base/configure.ac

2013-01-29 10:32:30 +0000
Chris Liddell <chris.liddell@artifex.com>
3c7aa3543e098620d70c5df143513718d3e83b12

> Add the make fix from 1fbd0191 to the Mac specific subtarget.
> CLUSTER_UNTESTED
> gs/base/unix-dll.mak

2013-01-29 10:12:00 +0000
Chris Liddell <chris.liddell@artifex.com>
3233283cfe4370fb826998d14954e4870155c80e

> Work around a make problem with "so" target
> GNU make 3.82 appears to have a bug which causes problems with our "so"
> targets. The "so" targets rely on recursice make calls to build various
> subtargets, the shared library and the two executables that link to the shared
> library.
> On the final recursive make call (to build the executables), GNU make 3.82
> wrongly identifies that one dependency (psbase.dev) has changed, and decides it
> must rebuild the shared library. By this stage, however, the compiler options
> have been setup to build an executable, rather than the shared library.
> As a result, we build an executable with the name of the shared lib, and
> then try to link that into an executable, which results in linker errors.
> As it happens, the use of recursive make calls means we can safely drop a
> dependency, which will prevent make from re-evaluating the problematic target,
> and thus avoiding the problem arising.
> CLUSTER_UNTESTED
> gs/base/unix-dll.mak

2013-01-28 17:32:15 -0500
Alex Cherepanov <alex.cherepanov@artifex.com>
bbfbdf7574e6ac46b65b76b06dea6a4e94d35f31

> Bug 693284: Prevent read access violation.
> Check whether there's enough data.
> gs/jbig2dec/jbig2_symbol_dict.c

2013-01-28 16:34:20 -0500
Alex Cherepanov <alex.cherepanov@artifex.com>
7ba5e87d05bb2bfff4e475fa21bd8558896ca053

> Bug 693284: Detect missing glyphs and fail.
> gs/jbig2dec/jbig2_symbol_dict.c
> gs/jbig2dec/jbig2_text.c

2013-01-28 15:34:38 -0500
Alex Cherepanov <alex.cherepanov@artifex.com>
33794a10191cf1e5c1b41410ee068ba71cf3825c

> Bug 693284: Conditional inclusion of memento header.
> gs/jbig2dec/jbig2.h

2013-01-28 13:34:01 -0500
Alex Cherepanov <alex.cherepanov@artifex.com>
ccae004db8b875086995353c299cee196dd326fb

> Bug 693284: Break an infinite loop.
> gs/jbig2dec/jbig2_symbol_dict.c

2013-01-28 11:56:37 -0500
Alex Cherepanov <alex.cherepanov@artifex.com>
4b6594315066b8ded562111472aa5933c6c54238

> Bug 693284: Fix 32 vs 64-bit typ[e mismatch.
> gs/jbig2dec/jbig2_symbol_dict.c

2013-01-28 11:09:04 -0500
Alex Cherepanov <alex.cherepanov@artifex.com>
eea1deb225c19ab7a29b7ccdb33290d757853f1b

> Bug 693284: Don't shift 32-bit value by 32.
> gs/jbig2dec/jbig2_huffman.c

2013-01-28 09:03:30 +0000
Chris Liddell <chris.liddell@artifex.com>
9cf877b78dbe7d077d1369b07bdaf73ba8415e01

> Handle cases where pointer alignment does not match pointer size.
> On some hardware, pointer alignment does not necessarily match the size
> of a pointer - handle that in genarch.
> No cluster differences
> gs/base/genarch.c

2013-01-28 08:55:02 +0000
Chris Liddell <chris.liddell@artifex.com>
8120955272fe1c9d1a8182c2dbba44758d3d3091

> Fix unaligned pointer access.
> In pdf_add_subset_prefix() change so that the hashing code accesses
> the buffer byte at a time, rather than short at a time, and increment
> through the buffer "sizeof(short)" bytes at a time. The former ensures
> we never risk an unaligned memory access on strict alignment
> architectures, and the latter ensures we hash all the relevant data
> correctly.
> No cluster differences.
> gs/base/gdevpdtb.c

2013-01-28 08:57:12 +0000
Ken Sharp <ken.sharp@artifex.com>
daeb0a9a52f865e9088c29511fd397d8356ca775

> pdfwrite - record the usage of outlines, articles, named dests and labels
> When linearising, I forgot to add the dictionaries, referenced from the
> Catalog, for Outlines, Threads, Named desintations and Page Lanels to
> the usage record. This meant these dictionaries were accidentally
> dropped from the final PDF file.
> Here we just record their usage.
> No diffrences expected.
> gs/base/gdevpdf.c

2013-01-27 14:06:05 -0500
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
07d5a619b525898759a7468631a6cb775edf5bd6

> Bug 691246: Handle inverted symbol region.
> Propagate combination operator and also fix an error in coding XNOR
> logical operation.
> gs/jbig2dec/jbig2_generic.c
> gs/jbig2dec/jbig2_image.c
> gs/jbig2dec/jbig2_page.c

2013-01-27 01:46:17 -0500
Alex Cherepanov <alex.cherepanov@artifex.com>
0e140900d2f1eca99ad64c5bdef131cddc55e5ef

> Bug 693513: Detect and reject negative parameters.
> Fix detection of negative width and height attributes.
> Add detection of negative number of dictionary symbols.
> gs/jbig2dec/jbig2_symbol_dict.c

2013-01-26 21:47:12 -0700
Henry Stiles <henry.stiles@artifex.com>
152d0cec22438acbb6a5cd50a65b0f9f8c729195

> Fix bug #693586 - clist error message.
> The error was caused by sending image data to the library after the
> page was output, now graphics mode is flushed and closed before the
> page is output. The bug was introduced by ea54a03 which closed
> graphics mode at the time of "end job" which could occur after output
> page. We do need to leave that commit intact as the job could end
> without outputting a page, and the raster state would not be cleaned
> up.
> pcl/pcpage.c

2013-01-26 21:43:50 -0700
Henry Stiles <henry.stiles@artifex.com>
386b7ab3dcdf165d6a9cae58a871e0bb78b7bdac

> dwmainc.c include file dependencies added to makefile.
> main/pcl6_msvc.mak

2013-01-26 19:58:46 -0500
Alex Cherepanov <alex.cherepanov@artifex.com>
e40d514124722e7babf4acaf1db5eb4e372b5f72

> Bug 693496: Fix 16-bit gray image on CMYK devices on 32-bit platforms.
> Use platform-independent way (memcmp) to compare color values instead of
> instead of relying on the word sizes. Old code missed some of the
> color components on 32-bit computers.
> gs/base/gxi12bit.c

2013-01-25 22:46:38 -0500
Alex Cherepanov <alex.cherepanov@artifex.com>
81a36cc82e8680ac6bf7f0808402bf6ff02920ea

> Bug 693587: Make EOL check a little more strict.
> Don't skip space character after finding \r. Just peek for the following
> \n and stop scanning.
> gs/Resource/Init/pdf_base.ps

2013-01-25 15:29:12 -0500
Alex Cherepanov <alex.cherepanov@artifex.com>
a438b95a287f36b721331c50a4c47985616a0c19

> Bug 693584: Fix annotation scaling.
> Fix incorrect scaling of annotations with appearance subdirectories. Old code
> always failed to find the actual appearance dictionary and used identity
> scaling in such cases.
> gs/Resource/Init/pdf_draw.ps

2013-01-25 09:50:41 -0800
Michael Vrhel <michael.vrhel@artifex.com>
5fa93a84163a0e2680ead7e76425c92da24bce5c

> Another documentation update of the color architecture.
> gs/doc/GS9_Color_Management.pdf
> gs/doc/GS9_Color_Management.tex

2013-01-24 21:42:03 -0800
Michael Vrhel <michael.vrhel@artifex.com>
52cb8e94511a3a5acd8d3a21f6a22cf24d52962e

> Update of color management document for 9.07 release
> gs/doc/GS9_Color_Management.pdf
> gs/doc/GS9_Color_Management.tex

2013-01-24 12:58:58 -0700
Henry Stiles <henry.stiles@artifex.com>
210c9344792bcf95c540f93428562c34104ffb28

> Set stdio streams to binary, bug #693543.
> This is exactly the same solution used in gs/base/dwmainc.c. The
> commit also removes extraneous include files. Updating the associated
> dwmain makefile target with the new include file dependencies is
> forthcoming.
> pl/dwmainc.c

2013-01-24 12:05:41 +0000
Chris Liddell <chris.liddell@artifex.com>
400e64a36f1f18e3642b705d926c49c42adc8599

> Bug 693571: properly close allocator chunk during save
> During a save operation, we "close" the open chunk and save the state of the
> current generation of an allocator before creating a new generation and opening
> a new chunk for the new generation.
> After doing that, we try to eliminate any redundant changes listed for the
> "saved" allocator instance. That can end freeing memory in the "closed" chunk,
> leaving it in an unstable state, and causing the garbage collector to try to
> validate already freed memory.
> In drop_redundant_changes() we now call alloc_open_chunk() and
> alloc_close_chunk() so that, in event we do disard changes (thus freeing
> memory), the allocator is left in an internally consistent state, and
> avoids confusing the chunk validation code during garbage collection.
> No cluster differences.
> gs/psi/isave.c

2013-01-24 11:56:25 +0000
Chris Liddell <chris.liddell@artifex.com>
149811fa66aaaf272a1377e9df1a79f3752e0299

> Update int_freed_top in the correct chunk
> In i_free_object() we were identifying the correct chunk for the memory
> address we were freeing, but then always updating int_freed_top in the
> current chunk. This could cause us to fail to consolidate free blocks when
> we possibly could, or to attempt to do so when it would be pointless.
> So we now identify whether the address is in the current chunk, and write
> int_freed_top in that, or use the actual chunk pointer for the freed
> memory block.
> No cluster differences.
> gs/base/gsalloc.c

2013-01-24 11:44:39 +0000
Chris Liddell <chris.liddell@artifex.com>
0f0a42367372cffeb80e32a4244dc74031fda077

> Use the correct memory pointer for glyph cache init
> The PS interpreter initialised the glyph cache using the "imemory"
> pointer for the cache memory. But if the cache gets resized via
> a setuserparams or setcacheparams, the graphics libarary would then
> use the "stable_memory" pointer to free the original memory, and allocate
> the new. Thus illiciting warning about "memory not owned by allocator" when
> running with -ZA
> Switch the PS interpreter initialisation to also use "stable_memory".
> No cluster differences.
> gs/psi/zfont.c

2013-01-24 11:36:16 +0000
Chris Liddell <chris.liddell@artifex.com>
3b2819779786467f3ed6799242947d811186a29a

> Change the memory pointer used for if_debug2m()
> The cmem pointer can be null in stream_finalize() if it is called from the
> garbage collector. Use the memory pointer from the stream object instead.
> No cluster differences.
> gs/base/stream.c

2013-01-23 16:11:32 +0000
Chris Liddell <chris.liddell@artifex.com>
57744bd8af3b06cea888b7a66c8349c5096b748d

> Bug 693572: handle missing a glyph outline.
> We purposefully ignore some errors during glyph creation. In that event,
> the path creation for an outline glyph, we weren't checking for the
> outline being missing.
> No cluster differences.
> gs/base/fapi_ft.c

2013-01-23 09:06:04 +0000
Ken Sharp <ken.sharp@artifex.com>
bb8f4582d893aab544597599b9498e38dfa12de4

> ps2write - Don't add PageLabels to the Catalog when we get a relevant pdfmark
> Bug 693551 " Regression: "Error handled by opdfread.ps : rangecheck" starting with 5784bfbfba7191cacce5309e88afac0851287460"
> opdfread.ps doesn't know what to do with a PageLabel, so don't emit them
> Not sure why this didn't show up in the original cluster test
> gs/base/gdevpdfp.c

2013-01-23 08:19:24 +0000
Ken Sharp <ken.sharp@artifex.com>
5874ad1dfa17839d499db8b041a5fc9bdbfd6b22

> Properly initialise 'clip' device
> Bug #693575 "segfault with ps2write and -dDisablePAPI"
> Although labeled as a PS writer problem this is in fact a general bug. In
> gx_image_fill_masked we call gx_image_fill_masked_start() with a pointer
> to a gx_device * which we expect to be filled in.
> This will be the device which accumulates the clip, if the current target
> device can accumulate clips then we use it, otherwise we set up an
> accumulation device.
> However there was a path through gx_image_fill_masked_start which did not
> set the device, leading to the variable being left uninitialised and
> causing a later crash.
> This patch initialises the variable to the current device before calling
> gx_image_fill_masked_start and also fixes the code path in that routine
> so that it always fills in the device. Just to be safe.
> No differences expected.
> gs/base/gximask.c

2013-01-23 08:46:58 +0100
Till Kamppeter <till.kamppeter@gmail.com>
5420903e1cbccc8c27c8e9f82c21efd9fef36366

> Silenced compiler warnings in cups/gdevcups.c.
> gs/cups/gdevcups.c

2013-01-22 20:25:18 -0800
Ray Johnston <ray.johnston@artifex.com>
f0f048ae68e9b93b536a52c783b566652ab72b3e

> Bug 693573; Prevent multiple free when MT rendering cannot start any threads
> When the MT rendering fails to start any device after the thread's
> chunk allocator was set up, multiple free of the allocator would occur
> because the thread's 'memory' was not set to NULL.
> gs/base/gxclthrd.c

2013-01-22 21:24:17 -0700
Henry Stiles <henry.stiles@artifex.com>
76fa834e14471fb54e3dd23802a8c8f53d7fda0e

> Fix warning, missing declaration, in the previous commit
> ea54a0304934c570a51ca5eec216b0480f2b5be5
> pcl/pcl.mak
> pcl/pctop.c

2013-01-22 20:07:57 -0500
Alex Cherepanov <alex.cherepanov@artifex.com>
81ea731e97a93a5c9e3f59d7f67f8b3aa5c495c8

> Bug 693570: Clear operand stack finishing PDF page.
> Clear all objects that may be left behind by PDF command streams.
> Stray composite objects interfere with a restore operator at the
> end of the page.
> gs/Resource/Init/pdf_main.ps

2013-01-22 18:04:09 -0700
Henry Stiles <henry.stiles@artifex.com>
298abec0432d87b25e57b2ab549b1817f396e851

> Remove a bogus comment, lineprinter font is bound.
> pl/plftable.h

2013-01-22 17:51:08 -0700
Henry Stiles <henry.stiles@artifex.com>
ea54a0304934c570a51ca5eec216b0480f2b5be5

> Fixes interpreter crash see bug #693543.
> If a PCL job exited in the middle of a raster stream graphics mode was
> not terminated properly at the end of the job, instead we tried to
> shut down graphics later at the time of interpreter shutdown which
> leads to a unordered freeing of resources.
> pcl/pctop.c
> pcl/rtgmode.c

2013-01-22 21:06:37 +0100
Till Kamppeter <till.kamppeter@gmail.com>
188e13b462ce0d606735b53e22bdba667e391c00

> CUPS Raster "cups" device: Improvements for pages size matching with PPD
> These changes improve the matching of the sizes of the incoming pages with
> the page sizes available for thr printer according to the PPD file.
> Instead of stopping to searcg through the PPDs page sizes when a size
> gets found which fits within the limits, we always go through all page
> sizes to find the best match. We consider the best match the size with
> the name given on the command line/by the input file and matching the
> size of the current page within the limits, second level is a match of
> size and margins and third level is only matching the size. If there
> is more than one match of the same level, the product of the
> horizontal and vertival size deviation counts.
> In addition, we let the gstoraster wrapper CUPS filter for Ghostscript
> call Ghostscript with all parameters on the command line (especially
> also the page size name) also when the input is PostScript.
> gs/cups/gdevcups.c
> gs/cups/gstoraster.c

2013-01-18 13:14:15 -0800
Ray Johnston <ray.johnston@artifex.com>
2ae1a17c87e2e0d6de13d3a354129ff09668bb32

> Fix Bug 693422. SEGV due to transparency and patterns
> This change disables the check when doing the pattern_cache_lookup,
> since transparency ops that set the colorspace may have been omitted
> from bands where they are not needed, but a large pattern may have
> been written to all bands. Thanks to Alex for finding this.
> gs/base/gsptype1.c

2013-01-17 14:25:25 -0500
Alex Cherepanov <alex.cherepanov@artifex.com>
96a8e3595982078f0bfd6a93cb51e420f25fdc31

> Bug 693550: Consider max color index -1 as 255.
> gs/Resource/Init/pdf_draw.ps

2013-01-17 18:44:10 +0000
Robin Watts <robin.watts@artifex.com>
57a5089f1e2c2a83eceec81dfa2facf5f9fb51e0

> Bug 693541: Fix color setup in pdf14_create_clist_device.
> When we create a pdf14 clist device (a pdf14cmykspot device, in this
> case) in pdf14_create_clist_device, we are at pains to set the
> num_components and max_components appropriately. At no point do we
> similarly sanitise the depth however.
> The fix applied here is an exact parallel to the first commit for
> this bug.
> gs/base/gdevp14.c

2013-01-17 12:22:34 -0700
Henry Stiles <henry.stiles@artifex.com>
8e57017fa3eaeb1c2034eb0925e0da2f38e286d3

> Fixes 693552 - regression with polygon handling.
> The previous fix, b2796b4d58, did not properly handle the pathological
> case of adding an HPGL/2 sub-polygon to an empty polygon path.
> pcl/pgpoly.c

2013-01-17 17:58:01 +0000
Robin Watts <robin.watts@artifex.com>
2a3bf5a4865d2d97e46742d14814758bb70abf53

> Bug 693541: Fix 'undefined filename' error
> If '%' is used in a separation name (say "45% 286 overprinting 186"),
> then when the file is opened, we interpret the % as a format specifier
> and we complain. Simple fix is to replace '%' with '_' when generating
> the tif filenames.
> The file now runs further, and hits another (unrelated) pattern cache
> problem.
> gs/base/gdevtsep.c

2013-01-15 13:31:50 +0000
Robin Watts <robin.watts@artifex.com>
045ad34f5074874c38e77919db920c5ed45dc5f5

> Bug 693541: Fix planar depth calculation from color_info.
> At various places in the code, we assume that for a planar device:
> dev->color_info.depth = dev->color_info.num_components * plane_depth
> This is NOT necessarily the case (due to tag planes etc).
> We therefore avoid the need for this calculation by adjusting the
> return value from gxdso_is_native_planar; rather than returning 0
> or 1 (for not-planar or planar), we now return 0 or the depth of
> the planes.
> The logic in pdf14_create_clist_device is updated to use this. This
> gets the file mentioned in the bug through to another (seemingly
> unrelated) crash that I will investigate next.
> gs/base/gdevdrop.c
> gs/base/gdevmpla.c
> gs/base/gdevp14.c
> gs/base/gdevppla.c
> gs/base/gxclimag.c
> gs/base/gxclist.c
> gs/base/gxclist.h
> gs/base/gxcolor2.h
> gs/base/gxdevsop.h
> gs/base/gxht_thresh.c
> gs/base/gxicolor.c
> gs/base/gximono.c
> gs/base/gxp1fill.c
> gs/base/gxpcmap.c

2013-01-16 12:08:24 -0800
Ray Johnston <ray.johnston@artifex.com>
37e07e95a5588c2feaba60bbf506a7a9e433a43c

> Fix bug 693557: SEGV regression with NumRenderingThreads > 0 in pattern_load
> This was due to the pdf14 device changing num_components during clist playback
> when it had not changed during writing the clist. When a pattern tried to load
> it failed the check that the depth of the pattern matched the depth of the
> device. This was traced to picking the pdf14cmyk device during rendering instead
> of the pdf14CMYKspot device because the thread's max_components was set to 4,
> not 14 (as during clist writing). Fix the MaxSeparations in gsdparam to return
> max_components instead of num_components, then fix devn_get_params to pass the
> PageSpotColors param and the setting of num_components in devn_put_params to
> ignore max_separations since that doesn't make sense.
> gs/base/gdevdevn.c
> gs/base/gsdparam.c

2013-01-16 21:54:23 +0000
Robin Watts <robin.watts@artifex.com>
cb51890a39bb97de55c5ce4734c55cba060d8e79

> pdf14_mark_rectangle speedups
> Customer 532 report 3 files that perform slower than they would like.
> Profiling of these files shows that they all make heavy use of
> fill rectangle calls on a pdf14 device. This means lots of time
> is spent in pdf14_mark_fill_rectangle, and the subsidiary function
> it calls, art_pdf_composite_pixel_alpha_8.
> This commit introduces various optimisations:
> 1) We avoid the collation/decollation copies for the additive
> case by using a new function (art_pdf_composite_alpha_8_fast) that
> takes the planeheight as an arg. This may do the collation/decollation
> internally if required.
> 2) We pull the logic for the 2 fast cases out of
> art_pdf_composite_pixel_alpha_8_fast.
> 3) We rejig the loops to count downwards where possible.
> 4) We reduce the number of variables in use within the loop by
> updating rowstride/alpha_g_off/shape_off/tag_off etc before the
> loop.
> 5) We modify the values of src_alpha and shape before the loop to
> avoid repeated calculations within the loops.
> 6) We add a special case loop to handle the num_comp == 1 && additive
> case (as typically seem with monochrome or grayscale devices). This uses
> an even simpler art_pdf_composite_alpha_8_fast_mono routine (no loops
> and fewer multiplies).
> Feedback from customer 532 is that these changes (backported to their
> 8.71 based system) gives a noticable speedup.
> gs/base/gdevp14.c
> gs/base/gxblend.c
> gs/base/gxblend.h

2013-01-11 09:55:22 -0800
Michael Vrhel <michael.vrhel@artifex.com>
ed38aa2fffd43cc0b38a4a0d1d66ec304ef0924e

> Fix for issue with transparency B stroke fill operation with softmask
> During a B operation (Stroke and fill) with transparency we push a knockout group to make sure
> the stroke blows away the fill rather than blending. When there was a softmask present, we
> were not passing along the soft mask for the fill portions during the group compositing operation.
> gs/base/gxblend.c
> gs/base/gxblend.h
> gs/base/gxblend1.c

2013-01-10 12:17:08 -0800
Ray Johnston <ray.johnston@artifex.com>
1bc2a56f913ff1fa3f7af06000a4c6dd5c948afd

> Fix bug 693361: Rendering threads unsafe use of main thread allocator.
> The PCL main thread allocator is not thread safe, and the rendering
> threads would end up using this allocator to form link profiles (in
> the lcms logic) because the device profile had the 'memory' allocator
> set to the main thread's allocator.
> The fix found by Robin Watts was to use the thread's device (which
> have a copy of the device profile with the thread's memory allocator,
> set by gs_putdeviceparams) in the call to create_buf_device.
> gs/base/gxclthrd.c

2013-01-10 12:08:03 -0500
Alex Cherepanov <alex.cherepanov@artifex.com>
79e780b55d1e832895b3a9c6aa13017a57d1ca72

> Big 693185: Suppress unbalanced q/Q warning.
> When the stream run is aborted, the processed part is likely to have
> more q than Q. Reporting this fact to the user is misleading, because
> it's an interpretation artifact rather than the file property.
> gs/Resource/Init/pdf_base.ps
> gs/Resource/Init/pdf_main.ps

2013-01-09 13:26:43 +0000
Ken Sharp <ken.sharp@artifex.com>
e8d295679c4b6eabe71256b748282be048b27c05

> pdfwrite - when handling PaintType 2 fonts, cater for rotatedt text
> We handle PaintType 2 fonts in PDF output by leaving them as regular type 1
> fonts but setting the text rendering mode to 1 (stroke). Naturally we also
> have to calculate an appropriate stroke width based on the font matrix,
> text point size and, for PDF, the text matrix.
> Previously we handled rotated FontMatrix entries, but didn't check for a
> rotated text matrix, which led to a multiplication by 0 and setting the
> stroke width much too narrow.
> No differences expected.
> gs/base/gdevpdtt.c

2013-01-09 02:12:56 -0500
Alex Cherepanov <alex.cherepanov@artifex.com>
339fcbd26065c2771a33ea8c805ff70bd097684a

> Bug 693033: Build shading in stopped context.
> Move shading dictionary construction into a stopped context. New code
> just drops a shading that cannot be constructed or rendered instead of
> aborting the whole stream run.
> gs/Resource/Init/pdf_draw.ps

2013-01-08 14:17:44 -0500
Alex Cherepanov <alex.cherepanov@artifex.com>
cf46f4c8ce91e6d62c902e58c79267934eed6eda

> Bug 693420: Add missing initialization of sim_overprint.
> Valgrind detects that sim_overprint is not initialised in this case.
> Normally, gcc has it set to 0 and produces normal output. Setting it
> to 1 creates the same incorrect output as reported.
> gs/base/gsicc_manage.c

2013-01-08 17:45:46 +0000
Chris Liddell <chris.liddell@artifex.com>
bb5a79b39e4ada667ac2e9c91179da29bafbd129

> Fix "fallback" to know about Microtype fonts
> In the event that FAPI fails to handle a font, there is a (temporary) fallback
> to the AFS code.
> That fallback *must* not be used for the Microtype fonts loaded via UFST, since
> the font loading code uses the error return to determine that we've loaded all
> the fonts from the FCO.
> No cluster differences.
> pl/plfapi.c

2013-01-08 17:03:21 +0000
Chris Liddell <chris.liddell@artifex.com>
693b5421da925b627b7ce573ea7346b5d3611de9

> Bug 693538: tweak TTF cmap format 4 parsing.
> Empty segments in the cmap table (that is, those where the start character code
> is the same as the end code) aren't ignored, we correctly "fake" a one entry
> segment. It seems, however, that we should *not* do that when the start and
> end codes are zero - in that case, we should ignore it.
> No cluster differences.
> gs/Resource/Init/gs_ttf.ps

2013-01-08 08:47:01 +0000
Chris Liddell <chris.liddell@artifex.com>
3cc531830906a291d4d088e31936a92d7324e53c

> Switch Ghostscript/GhostPDL to Affero GPL
> As discussed on IRC, e-mail and at the last staff meeting.
> COPYING
> LICENSE
> gs/LICENSE
> gs/doc/COPYING
> gs/doc/Commprod.htm
> gs/doc/Readme.htm
> gs/doc/WhatIsGS.htm
> gs/examples/cjk/all_ac1.ps
> gs/examples/cjk/all_ag1.ps
> gs/examples/cjk/all_aj1.ps
> gs/examples/cjk/all_aj2.ps
> gs/examples/cjk/all_ak1.ps
> gs/examples/cjk/gscjk_ac.ps
> gs/examples/cjk/gscjk_ag.ps
> gs/examples/cjk/gscjk_aj.ps
> gs/examples/cjk/gscjk_ak.ps
> gs/examples/cjk/iso2022.ps
> gs/examples/cjk/iso2022v.ps

2013-01-07 22:05:54 -0500
Alex Cherepanov <alex.cherepanov@artifex.com>
e49f26eedd54120b615487db37dbdc1429685f79

> Bug 693539: Add duplex option to gslp utility.
> Commit a contributed patch that adds a duplex option to gslp script.
> gs/lib/gslp.ps

2013-01-07 13:29:03 -0500
Alex Cherepanov <alex.cherepanov@artifex.com>
2f85458194f235cf9236214b49c385e9bad4e11e

> bug 693485: Handle single '~' as EOF in PDF
> Accept single '~' as a valid end of stream indicator in PDF files.
> Acrobat Reader accepts this kind of PDF files without warnings.
> gs/base/sa85d.c

2013-01-07 13:53:14 +0000
Chris Liddell <chris.liddell@artifex.com>
27df0d4971de23a82f0284c28aeb6e36cf355e46

> Bug 693532: Fix GTK+ 2.x fallback.
> The conditions under which to test for and use GTK+ 2.x were incorrect.
> No cluster differences.
> gs/base/configure.ac

2013-01-07 08:33:05 +0000
Chris Liddell <chris.liddell@artifex.com>
e639c0764cc50640135528fa6b0faac233bd87d2

> Fix indeterminism with FAPi and artificial bold glyphs
> Copy the raster lines from the FAPI bitmap into a temporary, appropriately
> aligned buffer before doing the "smearing".
> Also ensure that the FAPI settings for XL downloaded font and emboldening are
> correct.
> Potentially affects all PCL/PXL test files with emboldening and XL fonts.
> gs/base/gxfapi.c
> pl/plfapi.c

2013-01-04 20:34:47 -0500
Alex Cherepanov <alex.cherepanov@artifex.com>
def5e256da42d12cf8103fa7481380b6df84aa96

> Bug 93512: Add -dUseArtBox option.
> ArtBox is often the smallest of all boxes. This option can be useful
> when the file should be cropped to the smallest box without loss of
> the contemt. Thanks to Marcos for the patch.
> gs/Resource/Init/pdf_main.ps
> gs/doc/Use.htm

2013-01-04 02:39:34 -0500
Alex Cherepanov <alex.cherepanov@artifex.com>
5124cc05570819036a7bf689dbed91f57f74ba24

> Bug 693528: trap errors in ToUnicode CMap
> Read ToUnicode CMap in a stopped context. Ignore the CMap if
> reading fails.
> gs/Resource/Init/pdf_font.ps

2013-01-02 17:21:24 +0000
Ken Sharp <ken.sharp@artifex.com>
af5ba82a0c147b207d276a1acb9daa7bf7665227

> pdfwritre - change fixed buffer for CIDSystemInfo to dynamic allocation
> Bug #693514 "Broken PDF produced from PostScript by Windows 8 Microsoft
> PS Class Driver"
> The problem is that the CIDSystemInfo Registry and Ordering produced by
> the Microsoft XPS to PS device is > 32 characters. The code to write the
> CIDSystemInfo used a fixed buffer of 32 characters. If that overflowed we
> returned a limitcheck which caused pdfwrite to attempt a type 3 fallback
> which also failed.
> Changed the code to (more logically) allocate a buffer for the temporary
> usage. Also if this fails we return a VMerror which doesn't trigger an
> attempt to fall back to type 3.
> No Expected Differences
> gs/base/gdevpdtw.c

2012-12-28 18:32:37 -0500
Alex Cherepanov <alex.cherepanov@artifex.com>
bc70bf785efcb1a3f9c995b5d8b4c1c29dc881e5

> Bug 693511: Ignore spurious ET operator
> Ignore ET operator when it appears outside of BT context and issue
> a warning.
> gs/Resource/Init/pdf_ops.ps

2012-12-28 10:20:44 -0800
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
fea783c88450639227cfc456557ce16c348c9a67

> Fixed minor typo in documentation.
> gs/doc/Make.htm

2012-12-25 13:27:35 -0500
Alex Cherepanov <alex.cherepanov@artifex.com>
ec5b8eb0ccf0fc6881a6ffd2d190aa40e1faef1c

> Bug 693490: Warn about searching external contexts.
> gs/Resource/Init/pdf_main.ps

2012-12-25 12:58:02 -0500
Alex Cherepanov <alex.cherepanov@artifex.com>
23e7e3054c095cd5157f2f7768f95a75b86f9779

> Bug 693490: Search all XObject resources.
> Adobe Acrobat appears to search all nested XObjects for resource names
> contrary to the PDF specification. This patch follows the reference
> implementation and saves a pointer to XObject resource dictionary on
> the graphic state. When a resource cannot be found in a standard way,
> the stack of graphic states is searched.
> gs/Resource/Init/pdf_draw.ps
> gs/Resource/Init/pdf_main.ps

2012-12-22 12:21:38 -0800
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
b25fb04f7210656dd987cf23151aec08f4a9f2ee

> Documentation update (Bug 693491).
> gs/doc/Make.htm

2012-12-22 09:57:10 -0800
Michael Vrhel <michael.vrhel@artifex.com>
6ca50ddca3268fe4626279c591e6fe3dce4c4228

> Have the PDF14 device properly set up some of its color info
> The lack of setting the comp_bits components in the color info when we have
> the pdf14 CMYKSpot device caused an issue in the shading code. Fixes
> Bug 693480.
> gs/base/gdevp14.c

2012-12-13 11:23:41 -0800
Michael Vrhel <michael.vrhel@artifex.com>
1276ea02ac198b92788e3f6fac704c6ae2c2c4c7

> Enable proper blending to occur when we draw transparency patterns.
> This fixes Bug 693498. Previously we were not getting the blending information to
> the group that we push to draw into. Also, there was a difference in how the clist
> and non-clist pattern cases had to be handled. In the clist case, we do not know
> what the blend mode for a group encompassing the pattern would be until the pattern is
> run through the clist. Hence its logic with respect to transparency required a change.
> Also fixed a bug that occurred when we used the -Zv debug option.
> gs/base/gdevp14.c
> gs/base/gsptype1.c
> gs/base/gxblend.h
> gs/base/gxblend1.c

2012-12-14 11:45:41 +0000
Chris Liddell <chris.liddell@artifex.com>
316c27810d36e234fa4b254765e35268cfadbc27

> Remove some debugging code
> left in accidentally.
> No cluster differences.
> gs/base/configure.ac

2012-12-13 16:10:03 +0000
Chris Liddell <chris.liddell@artifex.com>
e5508fa002678eff5012ce09621d2b94c66e55a5

> Allow opt out of GNU make feature.
> As we currently only use one GNU make only feature, allow the user
> to opt out of it at configure time with "--without-gnu-make".
> Tested with Sun make and Sun dmake.
> No cluster differences.
> gs/base/Makefile.in
> gs/base/configure.ac

2012-12-13 18:44:14 +0000
Robin Watts <robin.watts@artifex.com>
da6307c97ac317a41e518c1db659a9dd88188669

> Fix pthreads error handling mistake.
> This bug was inherited from the mupdf example code I stole it from.
> It seems that pthreads signals errors as non zero, not negative.
> gs/psi/apitest.c

2012-12-13 16:56:09 +0000
Robin Watts <robin.watts@artifex.com>
776fe65eb131dd05728d8a448b6e4ce8dea5a9e0

> Document GS_THREADSAFE option
> gs/doc/API.htm

2012-12-13 15:44:23 +0000
Chris Liddell <chris.liddell@artifex.com>
e4e84ee2f724710d3a34119c13a621bd32c283d2

> Bug 693501: have configure detect and handle memalign
> OpenJPEG uses memalign, if available, but has a rather poor test for it being
> available.
> This change has configure check for memalign, and augment the compiler command
> line to replace memalign with a normal malloc for the OpenJPEG code.
> So, several BSD variants, AIX etc should now build okay.
> No cluster differences.
> gs/base/configure.ac

2012-12-13 14:59:19 +0000
Chris Liddell <chris.liddell@artifex.com>
bbc2e3b761fd58e1cfe155840c0b948e71c5f37d

> Fix the SHARE_ZLIB build.
> Add an EXTRALIBS variable for the aux programs (AUXEXTRALIBS) so that
> the "-l" directives get included, and in the correct position on the
> compiler/linker command line.
> No cluster differences.
> gs/base/Makefile.in
> gs/base/unix-aux.mak

2012-12-12 10:23:27 -0800
Michael Vrhel <michael.vrhel@artifex.com>
ee7fdd12e17fad500202234e04035d85fb70ebd0

> Perform range restriction after tint transform of separation color.
> Fixes bug 693497. Thanks to Alex for solving the issue before I even had a look at it.
> gs/base/gscsepr.c

2012-12-09 09:48:14 -0800
Chris Liddell <chris.liddell@artifex.com>
363443d8b2e8373541a886ed16ad281bfd6d31f4

> Fix memory leaks from FAPI/FT glyph data buffers.
> No cluster differences.
> gs/base/fapi_ft.c

2012-12-08 17:53:34 -0800
Chris Liddell <chris.liddell@artifex.com>
078175e8df7835ff4df00e53b256a9c7fbd32ed7

> Fix pl_fapi_passfont() return code.
> For now we want to fall back to the AFS code if FAPI can't handle a font.
> No cluster differences.
> pl/plfapi.c

2012-12-08 22:29:57 -0800
Ray Johnston <ray.johnston@artifex.com>
a8e20d4064e3df5fbb347a0cc8176635ce842e33

> Fix ARCH_SIZEOF_GX_COLOR_INDEX that mistakenly got committed in git-confusion.
> ARCH_SIZEOF_COLOR_INDEX was in a local branch that got had the problem and
> got pushed when trying to work from my confused git repo.
> gs/base/gxclutil.c

2012-12-08 14:46:27 -0800
Ray Johnston <ray.johnston@artifex.com>
9305f19f4ce60e9fbd3e15d1f22ceaa28502f95b

> Get rid of compiler warnings when SIZEOF_GX_COLOR_INDEX is 4.
> gs/base/gxclutil.c

2012-12-08 10:57:04 -0800
Chris Liddell <chris.liddell@artifex.com>
024697aa2aec80c2e162a2e7a0707006b418e0e3

> Fix a little bitrot in the trace device(s).
> CLUSTER_UNTESTED
> gs/base/gdevtrac.c

2012-12-07 21:07:17 -0500
Alex Cherepanov <alex.cherepanov@artifex.com>
482da0636bf70aea3bd44839e27eee650e430982

> Bug 690778: revert big resource hack.
> Revert most of the commit 93ffd5c00fef9f616fa6785106935344f6db69b5,
> which worked around 64K limit in resource dictionaries. gs now can
> create big objects directly.
> gs/Resource/Init/pdf_base.ps
> gs/Resource/Init/pdf_main.ps

2012-12-05 20:36:59 +0000
Chris Liddell <chris.liddell@artifex.com>
01d43e701413c63dc3d7f85b4c5d748b7b7da8c9

> Add some missing header dependencies.
> No cluster differences.
> pl/pl.mak

2012-12-05 19:32:45 +0000
Chris Liddell <chris.liddell@artifex.com>
0e107d4c37b14c21f5d855b70443873e9e9e9a8e

> Make MAX_TOKEN big enough for large paths
> Recommended by Nelson Beebe - his work reviewed a large number of common (and
> not so common) environments, and the largest allowable "monolithic" path is
> 4096 characters, so I've made MAX_TOKEN that size.
> No cluster differences.
> gs/base/genconf.c

2012-12-05 12:44:38 +0000
Chris Liddell <chris.liddell@artifex.com>
49571b9821b825cafd9691a7d25dfdeebbf9dd7d

> Various fixes for FAPI/UFST.
> Allow the "old school", non-FAPI PCL/UFST build to continue to work.
> Add support for UFST 5.x with FAPI.
> For XL format downloaded TTFs, disable hinting.
> This causes differences in ~161 cluster PCL test files - that is, files that
> have XL format downloaded Truetype fonts in them.
> config.mak.in
> configure.ac
> gs/base/configure.ac
> gs/base/fapi_ft.c
> gs/base/fapiufst.c
> gs/base/gxfapi.c
> gs/base/gxfapiu.c
> gs/psi/zfapi.c
> main/pcl6_gcc.mak
> pl/pl.mak
> pl/plfapi.c
> pl/plftable.h
> pl/pllfont.c
> pl/plulfont.c

2012-12-04 08:39:14 +0000
Chris Liddell <chris.liddell@artifex.com>
59d840fc9bdcf7d7ebb03d4d2d3f1e4d5d927d14

> Bug 693479: add missing CID to glyph index step
> For TTF CIDFonts loaded from disk (usually as a substitute), and using an
> Identity ordering, there was a missing step to get from the CID to the TTF
> GID. This caused problems when a PDF included a non-identity CIDToGIDMap.
> No cluster differences.
> gs/psi/zfapi.c

2012-12-03 17:32:56 +0000
Ken Sharp <ken.sharp@artifex.com>
5b4cea1173891c7c7252eb790af8357c9065a5ce

> pdfwrite - improve locaFormat fix
> commit 4d20aa6061c6bc802c1ff8e031cfb434dd7fd490 sets the top byte of the
> locaFormat in the HEAD table to be the same as 'indexToLocFormat. It
> should actually always be 0, fixed here.
> gs/base/gdevpsft.c

2012-12-03 12:10:12 +0000
Ken Sharp <ken.sharp@artifex.com>
4d20aa6061c6bc802c1ff8e031cfb434dd7fd490

> pdfwrite - fix incorrect TrueType locaFormat.
> Some TrueType fonts have the locaFormat specified incorrectly in little
> endian format. Our code always writes short loca entries, and sets the
> low order byte of the locaFormat to 0 (short entries).
> It wasn't setting the high order byte, because it should never be
> anything other than 0. However these incorrect fonts set the high order
> byte instead of the low order. It seems TrueType consumers treat the format
> as 0 or NOT 0 rather than chekcing the value, which meant we were leaving
> the format incorrectly set.
> This simple patch sets both bytes of the format in the HEAD table and fixes
> the problem.
> Expected differences
> Bug691850.pdf and Bug691035b.pdf show significant progressions
> gs/base/gdevpsft.c

2012-12-01 09:44:56 +0000
Ken Sharp <ken.sharp@artifex.com>
3a4439baee68c440da7164daf55de04a4d48609a

> pdfwrite - fix bug in commit a3d00daf5f9abb1209cb750a95e23bc6951c1c63
> missed an entry in the PDFDocEncoding lookup table, also fixed a minor
> error message and corrected an index.
> No differences expected.
> gs/base/gdevpdfe.c

2012-11-30 17:03:02 -0800
Michael Vrhel <michael.vrhel@artifex.com>
8ebecfe095e4585523fcbddbe1785473e0374b54

> Fix so that the blackpoint is set to a proper enumerated value
> Fixes bug 692530
> gs/base/gdevpsd.c
> gs/base/gdevrinkj.c
> gs/base/gdevxcf.c

2012-11-30 16:51:48 -0800
Michael Vrhel <michael.vrhel@artifex.com>
c8fc6c53f0bce4be54c016ddd78f6cfe4d44419a

> Avoid inserting the ICC profile into the halftoned TIFF output files.
> Fixes bug 693060
> gs/base/gdevtifs.c

2012-11-30 17:04:59 +0000
Robin Watts <robin.watts@artifex.com>
0bc3c907260275bf96a4d3e894e4a8146ddbb856

> Remove .DS_Store files from lcms2 directory
> These seem to upset at least one unzipping utility on the Mac, and
> they serve no useful purpose for us.
> gs/lcms2/Projects/mac/LittleCMS/.DS_Store
> gs/lcms2/Projects/mac/LittleCMS/._.DS_Store

2012-11-30 16:02:22 +0000
Ken Sharp <ken.sharp@artifex.com>
a3d00daf5f9abb1209cb750a95e23bc6951c1c63

> pdfwrite - convert non-UTF-16BE doc info to UTF-8 assuming PDFDocEncoding
> Bug #693477 "Encoding of pdf metadata do not comply with pdf standard"
> When processing Document info there is a pdfwrite parameter 'PDFDSCEncoding'
> which, if present, is used to process the string into ASCII. However, if
> this parameter is not supplied, we don't re-encode the string at all. Since
> the XML must be UTF-8, this is potentially a problem.
> Since we cannot know the source of the docinfo string (existing PDF, DOCINFO
> pdfmark, or DSC comments in PostScript) we cannot make any judgement about
> the encoding of the string data in the absence of PDFDSCENcoding. So we
> choose to assume that its encoded using PDFDocEncoding if it does not
> have a UTF-16BE BOM (which is the only other format permitted).
> This should at least mean that the Docinfo and XML match and are legal.
> No differences expected, the cluster doesn't check the XML
> gs/base/gdevpdfe.c

2012-11-30 07:55:46 -0700
Henry Stiles <henry.stiles@artifex.com>
bb97932923e94ef0806909718da693bf7655631f

> Fix 693269 - CCITT raster not using monochrome palette.
> The RTL CCITT raster compression modes always use monochrome colors (a
> palette with 1 bit per index). In our code this is somewhat awkward
> requiring rebuilding the PCL raster and part of the graphics library
> state as the compression mode can be changed after raster mode has
> been entered and initialized with a color palette.
> pcl/pccid.c
> pcl/pccid.h
> pcl/pcpalet.h
> pcl/rtgmode.c
> pcl/rtgmode.h
> pcl/rtrstst.h

2012-11-30 07:46:01 -0700
Henry Stiles <henry.stiles@artifex.com>
df30839b4058ba92dd85883516258ce08eaca628

> Bug 693437 - Improves PCL font selection.
> We do not have perfect emulation of PCL font selection by attribute,
> but this change does move us closer to the HP behavior. In particular
> any font family attribute command (bold, italic etc.) cancels a
> pending font selection by id, (i.e. the next selection will not use
> the font id as a selection criteria).
> pcl/pcfont.c
> pcl/pcfont.h
> pcl/pcfontpg.c
> pcl/pcfsel.c
> pcl/pcsfont.c
> pcl/pcsymbol.c
> pcl/pctext.c

2012-11-29 09:00:30 +0000
Chris Liddell <chris.liddell@artifex.com>
64ada98bdec11021ada90ddd21b8d9cdd9ee61a2

> Make genconf's token buffer big enough for long paths
> Thanks to Chen Qi ( Qi.Chen@windriver.com ) for pointing out the problem.
> No cluster differences.
> gs/base/genconf.c

2012-11-29 08:05:34 +0000
Chris Liddell <chris.liddell@artifex.com>
e02795887e3dd4fb75aaa90dc0bcf6d861246f4c

> Bug 693474: Make ps2pdf14 script executable
> CLUSTER_UNTESTED
> gs/lib/ps2pdf14

2012-11-29 01:55:36 -0500
Alex Cherepanov <alex.cherepanov@artifex.com>
9e89056ce7f1998ac22cb274fd0ed29458ee5d35

> Bug 693476: don't dump producer info for valid files
> Don't dump producer info when the file is valid but GS cannot
> process it for some reason. For instance, when the password is
> missing or invalid.
> gs/Resource/Init/pdf_sec.ps

2012-11-27 11:57:49 -0500
Alex Cherepanov <alex.cherepanov@artifex.com>
9b59e4d156deae8afd6c8eecad3ce8b83b2d7664

> Bug 693450: Add platform-dependent validation for file name characters.
> Add a new function to the portability layer that verifies, whether
> a given character can be used in a file name. Convert separation
> names to valid file names.
> gs/base/devs.mak
> gs/base/gdevtsep.c
> gs/base/gp.h
> gs/base/gp_dosfs.c
> gs/base/gp_macio.c
> gs/base/gp_ntfs.c
> gs/base/gp_os2fs.c
> gs/base/gp_unifn.c
> gs/base/gp_vms.c

2012-11-27 01:04:52 -0500
Alex Cherepanov <alex.cherepanov@artifex.com>
f27a0b8a47f0faadb6797132d6b9ef00a1823529

> Make PDF path construction operators more robust.
> Ignore the path construction operator that fails for some reason,
> and continue. Also correct the pdfemptycount value during form
> processing to match reality.
> gs/Resource/Init/pdf_draw.ps

2012-11-21 10:15:49 +0000
Ken Sharp <ken.sharp@artifex.com>
6f18589768e763238b5c45e46ba55dfef7dd59ae

> pdfwrite - properly set the PreserveSMask parameter for non-transparent output
> The PDF interpreter has historically handled SMasks by passing them directly to
> the device, when the device is pdfwrite. This was altered to use a device
> parameter rather than checking the3 device name.
> This did not alter the functionality, which has always bee incorrect when
> pdfwrite is not preserving transparency. We now alter the value of the
> device parameter if we are instead rendering the transparent content to an
> image. SMasks should now behave correctly when using PDF/A-1, PDF/X or
> when setting the CompatibilityLevel to less than 1.4.
> No differences expected as this is not cluster tested.
> gs/base/gdevpdfp.c

2012-11-20 17:19:44 +0000
Chris Liddell <chris.liddell@artifex.com>
481e7652bffc369fd0b7bc5b52aebde2328c4c5d

> Don't use return_error() for something not really an error
> Quietens down the -Z# output.
> No cluster differences.
> gs/base/fapi_ft.c

2012-11-19 19:38:59 +0000
Ken Sharp <ken.sharp@artifex.com>
123c7fbf7f31e42dff306a6d0b993224387b1b3c

> pdfwrite - further TrueType composite glyph improvement. Bug #693444
> When we encounter a TrueType composite glyph, we add the 2 component glyphs
> to the table of names, so that we generate a correct CMAP subtable in the
> embedded subset font.
> However, the name is based on the GID of the glyph, and if the GID happens
> match a name in the font Encoding (type 42 font) *and* we use the glyph
> which really corresponds to that name (but obviously has a different GID)
> then we would end up with the wrong CMAP generated.
> By not removing the GS_MIN_GLYPH_INDEX bias we create a new name which is
> numeric and based on the GID. This guarantees no name collisions.
> This leads to a regression in an XPS test file, but I think it is of the
> 'wrong before, differently wrong now' category and propose to ignore it on
> that basis. (its a change in spacing, which cannot be directly affected by
> this change.
> gs/base/gxfcopy.c

2012-11-18 09:51:34 -0700
Henry Stiles <henry.stiles@artifex.com>
787b044f67826cfc0c8b9fda01728cb602b4c212

> Bug #693111 fix refinement.
> Refine the fix 8bec29de to add a configuration option so individual
> commands can be selected for the unusual behavior of being ignored in
> raster mode. I don't think we have a solid understanding of this
> problem and this makes the fix significantly less likely to result in
> a regression.
> pcl/pcommand.h
> pcl/pcparse.c
> pcl/pcpatrn.c
> pcl/rtgmode.c
> pcl/rtgmode.h

2012-11-17 10:57:53 -0700
Henry Stiles <henry.stiles@artifex.com>
8bec29de4c0b67873d1e33e77296eed410be172e

> Fixes Bug 693311 - Black rectangle output instead of expected image.
> Normally if the PCL interpreter receives a command while processing
> raster or an image, the command is ignored and raster is shut down.
> These so called "locked out" commands do not close out the raster on
> plotters using the HPGL/2-RTL emulation.
> pcl/pcparse.c
> pcl/rtgmode.c
> pcl/rtgmode.h

2012-11-16 14:56:12 +0000
Chris Liddell <chris.liddell@artifex.com>
6a00be33f0127db231ca42f97e1f8b6ca4f69ecf

> Bug 693451: avoid notdef "special casing" for cid fonts.
> Bug692320.pdf should display as before the FAPI work.
> gs/base/fapi_ft.c

2012-11-14 16:52:27 -0800
Michael Vrhel <michael.vrhel@artifex.com>
9cb6ee748223ec3373151047d921d75bbeffc4e9

> Fix for issues with icc output intent
> Proper rendering of the output rendering intent Ghent test files to RGB based devices require that
> the output intent profile is used as a proofing profile. Unfortunately littleCMS does not allow one
> to specify different rendering intents to use when connecting a group of profiles together. This
> is needed to render these files correctly. The solution was to create a device link profile for the
> first rendering intent (e.g perceptual) when going from source to proof. Then the remainder of the
> transforms are handled in a relative colorimetric manner from proof to destination and possibly through
> the device's link profile.
> gs/base/gsicc_cache.c
> gs/base/gsicc_lcms2.c

2012-11-13 23:20:39 +0000
Chris Liddell <chris.liddell@artifex.com>
8ebb6896c6f7ba59a6e7dec1267a65a66f817f1c

> Use consistent ctm scale for metrics retrieval.
> This minimises differences at different resolutions, and uses a scale chosen to
> minimise rounding errors.
> Also, fix handling of missing glyph in the glyph metrics retrieval function.
> Lots of cluster differences in PCL/PXL tests.
> pl/plfapi.c

2012-11-13 23:18:17 +0000
Chris Liddell <chris.liddell@artifex.com>
a372bbae80c5b14cf68d2893db790acfef4a4f86

> Remove (temporarily?) the Makefile exclusion.
> We can't simply exclude Makefile, since the GhostPDL top Makefile is not a derived file.
> CLUSTER_UNTESTED
> gs/toolbin/localcluster/clusterpush.pl

2012-11-13 18:02:39 +0000
Chris Liddell <chris.liddell@artifex.com>
1e05c7a541280979e0884f8ea1c1cee6eba8f229

> Fix the language_switch Windows build with new fapi code.
> CLUSTER_UNTESTED
> language_switch/pspcl6_msvc.mak

2012-11-13 17:01:53 +0000
Ken Sharp <ken.sharp@artifex.com>
e1af42f1cca2cfb1f3f0c2d9e59e46bb8697fa27

> pdfwrite - amended white list for font DRM
> Copied again from teh Adobe web site, but mergin with the old list rather
> than replacing. It looks like Adobe have changed some of their font names.
> This shows a difference in fonts.pdf, beacuse we are now permitted to embed
> Mathematical Pi. THis is a progression
> gs/base/whitelst.c

2012-11-13 12:59:17 +0000
Chris Liddell <chris.liddell@artifex.com>
c54b37f8a5ad111dbfad499ba1c642ba404f5e93

> Fix a couple of Windows build issues with the new fapi code
> CLUSTER_UNTESTED
> gs/base/winlib.mak
> main/pcl6_msvc.mak
> xps/xps_msvc.mak

2012-06-01 15:44:11 +0100
Chris Liddell <chris.liddell@artifex.com>
58937f6debfbed7675a0ce5cb8d0aa629e3fa7b8

> Extend/modify FAPI for use by PDLs other than PS/PDF.
> All languages take a -dDisableFAPI option which reverts to the AFS code.
> On Unuix type systems
> ./configure --disable-fapi
> and on Windows, adding "FT_BRIDGE=0"
> create builds without the FAPI font handling.
> Both of these will be removed as the FAPI code matures.
> Move Font API from psi into base.
> Split the FAPI functions into the interpreter dependent ones, and the "core"
> functions. Move the core functions into the graphics library.
> Change fapi.dev to fapi_ps.dev
> Since the old fapi.dev is now split into core and PS dependent parts, the
> old fapi.dev gets renamed as fapi_ps.dev
> Basic TrueType support thru FAPI for pcl and pxl.
> Doesn't include artificial boldening.
> Basic FAPI functions working with XPS interpreter.
> (Mostly) Make PCL/UFST work through gs_fapi API
> Bug 693188: don't skip glyphs with degenerate matrices
> In commit 752397ab, the fix for Bug 692263 was to skip over glyphs when the
> matrix in force for the glyph had a zero scale in either dimension.
> It seems that this approach had potentially unfavourable side effects in the
> glyph cache.
> So, when we encounter a degenerate matrix rendering a glyph, we now force a
> minimal, non-zero scale before attempting to render the glyph. This placates
> the glyph cache.
> Cluster testing shows (tiny) progressions in Bug689006.pdf, Bug690179.pdf,
> and Bug692634.ps, and pixel differences, not identifiable as progressions
> or regressions in Bug690497.pdf and 12-07C.PS.
> Conflicts:
> gs/psi/fapiufst.c
> gs/psi/ifapi.h
> gs/psi/zfapi.c
> Revise gs_fapi_available and zFAPIavailable so they can check for
> a specific fapi server being available (as well as just fapi itself being
> available.
> Tidy up header includes, and header dependencies.
> Typos, warnings and dependency mistakes.
> Handle FAPI having no servers gracefully in PCL and XPS
> Use existing API to retrieve glyph metrics.
> Fix some PCL/PXL spacing problems.
> Improve handling of notdefs in PCL/PXL
> Some reformatting.
> Update fapi call in xps and fix some merge mistakes.
> Change gs_fapi_do_char() parameters to gs_glyph and gs_char types.
> Handle GS_NO_CHAR value better.
> Remove deprecated char_code entry
> Provide method for client to request ttf cmap in fapi.
> Skip "unencodable" glyphs (that is character codes whose "decoding" results
> in a gs_no_glyph glyph value).
> Fix (finally, I think) the PCL notdef problems, and PCL text orientation.
> Also, a GL spacing problem. Amend the Postscript size to work with these
> changes.
> FAPI API and warnings clean up.
> Identify glyph index or otherwise....
> ...in the FAPI PS world.
> fix a missing dependency
> Include stdint_.h in gxfapi.h....
> so int64_t is available. Add dependency.
> Fix typo in dependency.
> Changes to build gs_fapi on Windows.
> Fix a typo
> <sigh> another "notdef" handling revision
> Add PCL/XL glyph boldening (bitmap smearing) to FAPI.
> Remove some debug code accidentally left in.
> Provide a "-dDisableFAPI" command line option for pcl/pxl/xps.
> It's added in a very noddy way for two reasons: it needs acted upon
> before the interpreter is initialised, and second to make it more
> obvious to remove when we've gained confidence in the new fapi code.
> Split fapi server builds out of lib.mak and into separate makefiles.
> Add one commercial server build to the Ghostscript/GhostPDL build system, so
> it no longer needs built separately.
> Also fix a couple of dependency typos/errors.
> Some tweaks to get the build changes working on Windows
> Delete makefile....
> Revise build changes.
> Cluster differences in every PCL/PXL/XPS file with text display in a Truetype/Opentype font (including CFF).
> common/msvc_top.mak
> common/ugcc_top.mak
> config.mak.in
> configure.ac
> gs/Resource/Init/gs_fapi.ps
> gs/base/Makefile.in
> gs/base/configure.ac
> gs/base/fapi_bs.mak
> gs/base/fapi_ft.c
> gs/base/fapibstm.c
> gs/base/fapiufst.c
> gs/base/gconf.c
> gs/base/genconf.c
> gs/base/gscdefs.h
> gs/base/gsinit.c
> gs/base/gslibctx.h
> gs/base/gxfapi.c
> gs/base/gxfapi.h
> gs/base/gxfapiu.c
> gs/base/gxfapiu.h
> gs/base/gxfont.h
> gs/base/lib.mak
> gs/base/stub.mak
> gs/base/winlib.mak
> gs/base/wrfont.c
> gs/base/wrfont.h
> gs/base/write_t1.c
> gs/base/write_t1.h
> gs/base/write_t2.c
> gs/base/write_t2.h
> gs/psi/fapi_ft.c
> gs/psi/fapibstm.c
> gs/psi/fapiufst.c
> gs/psi/ifapi.h
> gs/psi/int.mak
> gs/psi/msvc.mak
> gs/psi/wrfont.c
> gs/psi/wrfont.h
> gs/psi/write_t1.c
> gs/psi/write_t1.h
> gs/psi/write_t2.c
> gs/psi/write_t2.h
> gs/psi/zfapi.c
> language_switch/pspcl6_gcc.mak
> main/pcl6_msvc.mak
> pcl/pcfontpg.c
> pcl/pcfsel.c
> pcl/pcl.mak
> pcl/pcsfont.c
> pl/pl.mak
> pl/plchar.c
> pl/plchar.h
> pl/plfapi.c
> pl/plfapi.h
> pl/plfont.c
> pl/plfont.h
> pl/plftable.c
> pl/plftable.h
> pl/pllfont.c
> pl/pllfont.h
> pl/plmain.c
> pl/pluchar.c
> pl/plufont.c
> pl/plufstlp.c
> pl/plufstlp.h
> pl/plufstlp1.c
> pl/plulfont.c
> pxl/pxfont.c
> pxl/pxl.mak
> xps/ghostxps.h
> xps/xps.mak
> xps/xps_msvc.mak
> xps/xpscff.c
> xps/xpsfapi.c
> xps/xpsfapi.h
> xps/xpsttf.c

2012-11-12 20:05:31 -0700
Henry Stiles <henry.stiles@artifex.com>
a971121e9e50c672908f1b3185f42d497adf0b02

> New PCL-XL paper sizes fixing part of bug 693399.
> Thanks to Hin-Tak Leung for providing these new non standard paper
> sizes to support Ricoh specific PCL-XL.
> gs/base/gdevpx.c
> gs/base/gdevpxen.h
> gs/base/gdevpxut.c

2012-11-12 18:24:08 -0700
Henry Stiles <henry.stiles@artifex.com>
b2796b4d588d83730c1d97c7fc035454cfe8157a

> Fix part of bug #693415. HPGL's command to create a sub-polygon
> closed paths unconditionally.
> Thanks to Norbert Janssen for providing a fix to conditionally close
> the path only if the current pen is down. The fix revealed another
> problem where PCL was not creating a new sub-path when the current pen
> was up and drawing a circle (CI). This is remedied with issuing a
> "moveto" not "gapto" when starting the circle. Currently the only
> means of doing a moveto explicitly is to temporarily disable the "hpgl
> path mode" while calling the gs_moveto() procedure. This arrangement
> will likely be improved in the future by adding a gapto function to
> the graphics library language interface.
> These changes result in fixing the original source problem and several
> improvements in the PCL CET. A few new minor discrepancies
> (regressions) were found in the CET's and another test (all documented
> in the bug), these were either inconsequential or deferrable and we
> feel this change is substantial progress and should not be held up for
> the other issues to be addressed.
> pcl/pgdraw.c
> pcl/pgpoly.c
> pcl/pgvector.c

2012-11-12 10:43:00 -0800
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
586d4a1669b0be9c05f7fcc45cbfc72a0dde5026

> Present clusterpush.pl from pushing Makefile(s).
> gs/toolbin/localcluster/clusterpush.pl

2012-11-12 13:23:48 +0000
Chris Liddell <chris.liddell@artifex.com>
2c38e570321bb56e8c2d2a897502d207028e1c83

> Bug 693436: Resolve issues with FTS and 64 bit PS ints
> There was a number parsing case I had missed in special casing CPSI_mode for
> QL test compatibility.
> Also, there were some issues with gs_cet.ps - some of the objects it replaced were left
> writeable, and/or were off the wrong type.
> Cluster differences: we should now be able to pass all the FTS tests by using gs_cet.ps.
> gs/Resource/Init/gs_cet.ps
> gs/psi/iscannum.c

2012-11-12 13:23:09 +0000
Ken Sharp <ken.sharp@artifex,com>
e6759327b6b8338491bf86ac3aa0179f47dc047d

> pdfwrite - revert white list change which seemed to cause errors
> gs/base/whitelst.c

2012-11-12 11:23:50 +0000
Ken Sharp <ken.sharp@artifex,com>
24de0d2174103bb98d0c3ffbdf09c1081bbc98ef

> pdfwrite - update the 'white list' of fonts
> Some TrueType fonts have unintentional DRM applied, this commit updates
> the Adobe 'white list' of fonts which may be embedded, even if the DRM
> flags say otherwise.
> No differences expected
> gs/base/whitelst.c

2012-11-11 09:33:12 -0700
Henry Stiles <henry.stiles@artifex.com>
39e56129466aa8d0b84c8c1267dbaef9dcefd2bd

> Fixes 693399, PXL file errors out when color palette is too large.
> The color palette should be truncated upon overflow, previously we
> produced an error. Thanks to Hin-Tak Leung for the analysis and fix.
> pxl/pxink.c

2012-11-11 08:41:03 -0700
Henry Stiles <henry.stiles@artifex.com>
774e27302ec3b228f6cef6abf04c18066edd5525

> Hin-Tak Leung's fix for bug 693413 - large output file size due to
> images being decimated to rectangles.
> The fix allows any orthogonal image, given the color information can
> be properly represented in a PXL, to be converted directly to a PXL
> image. The change has not been cluster tested, the PXL device is
> tested in the overnight testing and there is no practical means to
> test the device's code change with all test files locally, so the
> commit also serves as a test submission.
> gs/base/gdevpx.c

2012-11-09 12:34:01 -0700
Henry Stiles <henry.stiles@artifex.com>
a8de3e6dc0152b137c38078d80a3c40517095f91

> Fixes 693385 Font id selection wrong when using SI (Shift In) and SO
> (Shift out) commands and inappropriate switch to ID in font selection.
> The SO and SI were decaching the current font table, effectively
> changing font ID selection to family selection. 2 additional and
> closely related changes were provided by Norbert Janssen: the selected
> by id state was being disabled during font selection even if font
> selection had no effect and upon selection be id we were decaching
> both font tables.
> All of these changes are certainly in the right direction but seem to
> have unmasked some obscure problems which will be addressed in a
> separate bug. Here are the expected regression test files for this
> commit:
> tests_private/pcl/pcl5ccet/18-20.BIN
> tests_private/pcl/pcl5ccet/19-05.BIN
> tests_private/pcl/pcl5ccet/19-11.BIN
> tests_private/pcl/pcl5ccet/19-12.BIN
> tests_private/pcl/pcl5ccet/19-13.BIN
> tests_private/pcl/pcl5ccet/19-14.BIN
> tests_private/pcl/pcl5efts/fts.0280
> tests_private/pcl/pcl5efts/fts.0341
> tests_private/pcl/pcl5efts/fts.0380
> pcl/pcfont.c
> pcl/pcfsel.c
> pcl/pctext.c

2012-11-06 15:51:23 +0000
Chris Liddell <chris.liddell@artifex.com>
a0a4fd51a9c17a1b17d0cc9eccfef51e96ea8d04

> Bug 693430: missing "fallback" for DecodeParams entry
> In a ResuableStreamDecode filter with an array of subfilters (/Filter entry
> in the parameter dictionary). If teh DecodeParams array also exists, and has
> one or more entries set to "null", we weren't pushing an empty dictionary
> onto the stack for the subsequent call to the filter operator.
> The equivalent code for a totally absent DecodeParams array was already
> correct.
> No cluster differences.
> gs/Resource/Init/gs_frsd.ps

2012-11-05 21:30:48 +0000
Robin Watts <robin.watts@artifex.com>
048b221e76fba80663f073f8312802bcdf168c52

> Bug 693166: Speed images through the clist.
> In investigating bug 693166 Ray spotted that the calculation of which
> bands were touched by images was slack in the presence of a clipping
> path - he proposed a simple patch to fix this.
> Unfortunately it had a knock on effect where vertical offsets could be
> introduced into the topmost band. This is fixed here by a second small
> change in image_band_box.
> Cluster testing shows 10 small changes, all well within the usual
> clist differences.
> gs/base/gxclimag.c

2012-11-05 09:16:10 -0700
Henry Stiles <henry.stiles@artifex.com>
782d5c4083217d7225a843bf6bad254dca4c2e8c

> Fixes bug #693429 process raw HPGL files.
> The PCL parser will now recognize HPGL files if the files start with
> the commands "IN" or "DF" and if the parser is using the RTL
> personality.
> pcl/pcl.mak
> pcl/pcparse.c
> pcl/rtmisc.c
> pcl/rtmisc.h
> pcl6/pcl6.xcodeproj/project.pbxproj

2012-11-02 22:55:24 -0700
Michael Vrhel <michael.vrhel@artifex.com>
119f9ced7dc9be5f412ed587381627babb29d3ed

> Fix for missing code to grab the device profile. Thanks to sags for finding this.
> gs/base/gsicc_cache.c

2012-11-01 16:05:13 +0000
Robin Watts <robin.watts@artifex.com>
0cefc049bdd1eee78f14c97129627af766e022c9

> Fix tiffsep and introduce tiffscaled4 device.
> The tiffsep device was supposed to be able to be called with
> -dBitsPerComponent set to 1,2,4 or 8 to allow differing bit
> depths of output. This setting would work for the separation
> planes, but would not produce a composite when bpc was not 8
> due to the code not supporting that.
> We add code here to generate composites in 1,2 and 4 bit modes
> too, along with some sanity checking of the compression mode.
> We also add a tiffscaled4 mode where we produce 1bpc cmyk from
> a downscaled dither of 8bpc cmyk.
> gs/base/devs.mak
> gs/base/gdevtsep.c
> gs/base/gxdownscale.c
> gs/base/unixansi.mak
> gs/psi/msvc.mak
> main/pcl6_gcc.mak
> main/pcl6_msvc.mak

2012-11-01 15:24:04 +0000
Ken Sharp <ken.sharp@artifex,com>
9b10f8c659ffc643ab71c6180a70da4f39075578

> pdfwrite/ps2write - enable 64-bit file handling
> Subsequent to commit c81c8f1b8740c484ec332080b5ce5f718357694d it is now
> possible to have 64-bit offsets returned by stell, and this makeds it possible,
> for the first time, to write PDF files > 4GB.
> There's a fair amount of reworking in here, but we can now produce very large
> temporary files, and from that produce very large PDF and PostScript output.
> There are some restrictions; no stream can exceed 2GB and no font can exceed 2GB
> As might be expected this is *not* well tested as we don't actually have any
> test files which exercise this. I have tested PDF and PostScript file production
> with a single file which produces a 10GB temporary file, a 7 GB PDF file and a 6GB
> PostScript file.
> The resulting PDF file opens with Adobe Acrobat and can Ghostscript, and the
> PostScript file can be consumed by Adobe Distiller and Ghostscript.
> Nevertheless, bugs are possible.
> No differences expected as this is not lcuster tested.
> gs/base/gdevpdf.c
> gs/base/gdevpdfb.c
> gs/base/gdevpdfo.c
> gs/base/gdevpdfu.c
> gs/base/gdevpdfx.h
> gs/base/gdevpdti.c
> gs/base/gdevpsf1.c
> gs/base/gdevpsf2.c
> gs/base/gdevpsft.c

2012-10-29 17:28:05 -0600
Henry Stiles <henry.stiles@artifex.com>
84498da1627a85e340c7670b8c7a617e38b9efb7

> Support PJL language string HP-GL/2.
> The language string HP-GL/2 now selects the "RTL" mode in PCL. It
> should also be used to select the language HP-GL/2 upon language
> switch, but only one language string is supported per emulation, and
> the feature is not really needed. Any HPGL/2 rtl file should select
> the PCL emulation anyway because of the character of the input stream
> and the HP-GL/2 PJL command will select the RTL personality.
> pcl/pctop.c

2012-09-25 11:19:21 +0100
Chris Liddell <chris.liddell@artifex.com>
c81c8f1b8740c484ec332080b5ce5f718357694d

> 64 bit stream offsets and 64 bit PS integers objects
> Revise the stream and "gp_" file APIs to support file sizes >4Gb (on suitable
> systems).
> I've added a gs_offset_t type which, by default is a 64 bit signed type (this
> matches the standard lib's 64 bit "off_t" type). For ports that may want to
> use an alternative type, define "GS_OFFSET_T" to the desired type on the
> compiler command line.
> By default, Ghostscript will now use 64 bit integer objects in Postscript. Again,
> for porting ease, one can opt for 32 bit integer objects by defining PSINT32BIT=1
> on the compiler command line.
> The handling of integer objects in various operators has been "augmented" so that
> when working in "CPSI compatibility mode", intepreting and manipulating integer
> objects will see them "clamped" to 32 bit signed values. This allows Ghostscript
> to still pass the Quality Logic tests which spuriously rely on 32 bit integer
> objects.
> There is a minor tweek in the PS interpreter's handling of Truetype fonts (*not*
> Type 42), where the algorithm used to create an XUID relied on 32 bit integers.
> There is a small performance penalty in this, but my testing suggests that it is
> smaller than the time resolution of our testing capabilities (i.e. there are
> greater variances between test runs than between the 32 and 64 bit objects code).
> We can now interpret PDF files >4Gb.
> In addition, the graphics library will now include inttypes.h (in stdint_.h) if
> it is available in order to make the "PRI...." printf and co formatting macros
> available. If inttypes.h is not available, there are fallback definitions of the
> most used of those. These can also be defined on the compiler command line for
> specific ports, if required.
> A custom "PRI..." macro has been added in the Postscript interpreter,
> "PRIpsint", which is defined appropriately when integer objects are 64 or
> 32 bit.
> This commit does *not* revise the device API to handle 64 bit integer values
> (in the one case where this is required, we use a string to hold the 64 bit value,
> I suggest continuing this, so the device API remains consistent across ports).
> I do expect a bug tail with this, as we start to encounter more >4Gb PDFs.
> Cluster differences are restricted to the 3 QL Postscript test jobs that have
> ended up in comparefiles (and thus are not run with the gs_cet.ps setup).
> config.mak.in
> configure.ac
> gs/Resource/Init/gs_ttf.ps
> gs/base/Makefile.in
> gs/base/configure.ac
> gs/base/devs.mak
> gs/base/gdevpsf2.c
> gs/base/gdevpsft.c
> gs/base/gdevtifs.c
> gs/base/gp_mswin.c
> gs/base/gp_unifs.c
> gs/base/gsiorom.c
> gs/base/gxclist.c
> gs/base/gxclrast.c
> gs/base/lib.mak
> gs/base/scommon.h
> gs/base/sfxfd.c
> gs/base/sfxstdio.c
> gs/base/std.h
> gs/base/stdint_.h
> gs/base/stdpre.h
> gs/base/stream.c
> gs/base/stream.h
> gs/base/strmio.c
> gs/base/strmio.h
> gs/base/tiff.mak
> gs/psi/btoken.h
> gs/psi/fapi_ft.c
> gs/psi/idebug.c
> gs/psi/ilocate.c
> gs/psi/int.mak
> gs/psi/interp.c
> gs/psi/iparam.c
> gs/psi/iref.h
> gs/psi/iscan.c
> gs/psi/iscan.h
> gs/psi/iscanbin.c
> gs/psi/iscannum.c
> gs/psi/iutil.c
> gs/psi/opextern.h
> gs/psi/zarith.c
> gs/psi/zfapi.c
> gs/psi/zfcid0.c
> gs/psi/zfileio.c
> gs/psi/zfjpx.c
> gs/psi/zfrsd.c
> gs/psi/zmisc.c
> gs/psi/zrelbit.c
> gs/psi/ztype.c
> pl/pl.mak
> pl/plfont.h
> pl/pllfont.c

2012-10-30 13:05:11 +0000
Robin Watts <robin.watts@artifex.com>
dfde821467a4770499b52fbfb2c665a74ed379c0

> Fix silly dependency typo in lib.mak.
> Thanks to Chris for pointing this out.
> gs/base/lib.mak

2012-10-29 20:20:22 +0000
Robin Watts <robin.watts@artifex.com>
aa7d7ffcc390b05a8e36b6cf85e4688ae69c2a85

> Fix interpolation code to behave consistently in the presence of pdf14.
> There are special cases in the setup of the image interpolation code
> designed to kick in in the presence of halftoning devices and either
> limit the amount or change the nature of the interpolation done.
> The test for this is confused by the presence of a pdf14 device though.
> We move the special cases down into a device specific op call to avoid
> this. This also means that devices can have finer control over exactly
> when these operations are used.
> One possibility would be to expose them as device params, but I haven't
> done that here yet.
> gs/base/gdevdflt.c
> gs/base/gxdevsop.h
> gs/base/gxiscale.c
> gs/base/lib.mak
> gs/ghostscript.vcproj

2012-10-28 16:00:01 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
49f1bba50c096dee3230e5221db4d5275b8e12e7

> Fix optional content support for inline images. Because of the lack
> of test cases, the old code has never been tested.
> gs/Resource/Init/pdf_draw.ps

2012-10-27 19:10:13 -0700
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
88bf2cb37c0cb1c88ea03abb567dc7e0afdfef47

> Refined the list of files to exclude in clsuterpush.pl.
> gs/toolbin/localcluster/clusterpush.pl

2012-10-22 17:31:27 +0100
Robin Watts <robin.watts@artifex.com>
045e544c507b151daebc19aaf21a8b13b6c4a844

> Support rotated images with interpolation.
> See bug 690246.
> Testing this on the cluster with a patch that enables interpolation
> for all landscape jobs reveals no problems.
> gs/base/gxcindex.h
> gs/base/gximage.h
> gs/base/gxipixel.c
> gs/base/gxiscale.c

2012-10-25 16:43:37 -0700
Michael Vrhel <michael.vrhel@artifex.com>
f4b2deea2aa129048014771c19ef9fb3c317de7e

> Addition of support for the black preservation methods in littleCMS
> This is for bug 692223. With this commit now have support to specify black preservation on a object level (e.g. graphic, image or text).
> gs/base/gscms.h
> gs/base/gsdparam.c
> gs/base/gsicc_cache.c
> gs/base/gsicc_manage.c
> gs/base/gsicc_manage.h
> gs/doc/Use.htm

2012-10-26 01:04:03 +0100
Robin Watts <robin.watts@artifex.com>
9c3de1fb29628f83ae7d48238e0dd0f3f35ecda1

> Fix typo in last commit.
> Missing 'int' in definition.
> gs/base/gxiscale.c

2012-10-25 20:44:53 +0100
Robin Watts <robin.watts@artifex.com>
d68bdb872b1071e42dd937ca7526e5e2cfc9bca7

> Fix problem in interpolation code.
> When interpolating, if we are in an indexed space, we should
> only offset by 1 component per sample, not as many components
> as there are in the base space.
> This shows up problems with the forthcoming landscape commit,
> but is fixed here separately as it is actually unrelated.
> gs/base/gxiscale.c

2012-10-25 13:44:22 +0100
Ken Sharp <ken.sharp@artifex,com>
97e17a24e89bb0f893fd43af35e774054e41eadc

> ps2write - while stripping OtherSubrs, don't try to index off stack
> The code assmued that a Callsubr operator woudl be preceded by the subr index
> but in this case the subr index is provided by another Subr (crazy font...).
> All we need to do is cdheck the stack index, and if its 0, not index from the
> stack but simply write the Callsubr operator.
> Fixed Bug #693325
> Expected Differences
> tpc2.ps should no longer seg fault on the cluster with ps2write.
> gs/base/gdevpsf1.c

2012-10-24 19:10:36 +0100
Robin Watts <robin.watts@artifex.com>
c31725843fc3195970d12baad2916bf4dc3a5097

> Bug 693407: Portion of image missing with interpolation
> The 'only interpolate the portion of the bitmap required' code was
> going wrong in the case of X flipped bitmaps.
> gs/base/gxipixel.c
> gs/base/gxiscale.c

2012-10-24 10:02:00 -0700
Michael Vrhel <michael.vrhel@artifex.com>
f25f5e6f94ada1b3908b85ac68cabe2b9831d803

> Enable default spot name usage when output profile is NCLR
> Previously I had added the requirement that we used something like
> -sICCOutputColors="Cyan, Magenta, Yellow, Black, Orange, Violet"
> when using an NCLR ICC profile for the device profile (valid only for
> tiffsep and psdcmyk devices). This was to ensure proper naming of the
> profile colorants. It was pointed out by a customer that they would
> prefer to have a set of default names so this was now added.
> If -sICCOutputColors is not specified and we are using an NCLR ICC profile,
> then we will have spot colors from the profile named ICC_COLOR_0, ICC_COLOR_1
> etc.
> gs/base/gdevpsd.c
> gs/base/gdevtsep.c
> gs/base/gsicc_manage.c

2012-10-23 16:35:54 -0600
Henry Stiles <henry.stiles@artifex.com>
793971fc49dd62d02d92f4761c40f63a29eabd67

> Setting the default line attributes was done 2 places in the code.
> pcl/pglfill.c

2012-10-22 16:24:46 -0600
Henry Stiles <henry.stiles@artifex.com>
270fade3cd436aa8abe8d1ef00f4db4ba1f766f3

> Bug #693381, Norbert Jannsen's fix to track and home the pcl cursor
> appropriately.
> pcl/pcommand.c
> pcl/pcpage.c
> pcl/pcpage.h
> pcl/pcstate.h
> pcl/pcursor.c

2012-10-12 19:46:00 +0100
Robin Watts <robin.watts@artifex.com>
68dd69edbd8e2728207f18435be933bdca461a6f

> Make stcolor device threadsafe by removing static.
> Remove from list of unthreadsafe devices.
> gs/base/configure.ac
> gs/base/gdevstc.c
> gs/base/gdevstc.h
> gs/base/gdevstc4.c

2012-10-22 14:47:05 +0100
Robin Watts <robin.watts@artifex.com>
36d9731f83201002df6a91699f86e84c8d8530b1

> Fix -Zb decode flags.
> Some of the debugging code that had been changed to provide memory
> pointers to the debugging print functions was attempting to
> retrive a memory pointer from a stream that was on the stack.
> Stack based streams have null memory pointers, resulting in SEGVs
> when the pointers were used.
> Revert these calls back to the non threadsafe ones.
> gs/base/gximage.c

2012-10-21 11:49:26 -0600
Henry Stiles <henry.stiles@artifex.com>
16423bc7bb7c800122f04ec16869a88dcb6d69b0

> Fixes 693395 default screen vector fill percentage incorrect.
> Another inconsistency across HP devices: HP plotters apparently
> default to a 50% fill if the Screened Vector (SV) command requests
> shading but doesn't specify a percentage. On HP Printers the command
> is ignored if the percentage is not provided explicitly.
> pcl/pglfill.c

2012-10-16 19:15:34 -0700
Michael Vrhel <michael.vrhel@artifex.com>
0442ce0c95ffb9a33eba5c2303172e029883f2fb

> Add in support for spot color overprinting with standard CMYK devices
> Currently only the psdcmyk and tiffsep devices provide simulation of spot
> color overprinting. With the following commit it is possible to get
> simulation of overprinting with other CMYK based devices. This is done
> using the command line option -dSimulateOverprint. The simulation is
> achieved by having the overprint device blend the CMYK colorant with what
> ever has currently been drawn.
> gs/base/gdevp14.c
> gs/base/gdevp14.h
> gs/base/gscdevn.c
> gs/base/gscms.h
> gs/base/gscsepr.c
> gs/base/gscspace.c
> gs/base/gsdparam.c
> gs/base/gsovrc.c
> gs/base/gsovrc.h
> gs/base/gstrans.h
> gs/base/gxblend.h
> gs/base/gxblend1.c
> gs/base/gxcspace.h
> gs/base/gxoprect.c
> gs/base/gxoprect.h

2012-10-19 17:32:57 +0100
Ken Sharp <ken.sharp@artifex,com>
19f407d322ba43e1aff403f625bd4d2a723f5e65

> pdfwrite - bug #691653 Regression: /undefined in --run-- with pdfwrite starting with r11667
> The underlying problem is related to writing an ICCBased space corresponding
> to an Lab space. However, the fallback when this fails does actually work.
> The fault was caused by us writing out (and referencing from the page object)
> broen Shading, colourpsace and Pattern entries, which were never actually used.
> By removing the references from the page (but continuing to emit the broken
> objects) 'corrects' this, and other files.
> Expected Differences : bug689880.pdf should now work.
> gs/base/gdevpdfg.c
> gs/base/gdevpdfu.c
> gs/base/gdevpdfv.c

2012-10-17 23:02:51 -0700
Michael Vrhel <michael.vrhel@artifex.com>
7d028b4cb4693468b2cb842a156a52f127262e55

> Update source color example file.
> gs/toolbin/color/src_color/objsrc_profiles_example.txt

2012-10-17 21:35:16 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
515767b6e4fb37b6259fbe0d6dec429f0d1727f9

> Bug 693390: recover yet another broken PDF file
> Recognize and fix a case when <</ColorSpace/DeviceRGB>> is used instead of CSA.
> Also fix a real bug that prevented definition /DefaultXXX color spaces as
> device color spaces by PDF file.
> gs/Resource/Init/pdf_draw.ps
> gs/Resource/Init/pdf_main.ps

2012-10-16 18:45:22 -0700
Michael Vrhel <michael.vrhel@artifex.com>
cf41720e6d559213802caa3f47edb82182cc7565

> The manner in which the icc profile serial header structure was defined is plagued with alignment problems
> This fix avoids the use of the sizeof operation to specify the size of the serial header portion.
> Thanks to Robin for his help in tracking down this issue.
> gs/base/gscms.h
> gs/base/gsicc.c
> gs/base/gsicc_manage.c
> gs/base/gxclist.c

2012-10-17 09:49:09 +0100
Chris Liddell <chris.liddell@artifex.com>
a4cbd97bfe01b2c850902d8ee0983eda61fdb64d

> Bug 693389: add inkcov device to Windows build.
> CLUSTER_UNTESTED
> gs/psi/msvc.mak

2012-10-16 08:51:58 +0100
Ken Sharp <ken.sharp@artifex,com>
2741c775675f23403470cb680adbd0025e716e70

> add the 'debugaux' directory to the ignore list for Git
> .gitignore

2012-10-13 02:42:15 -0700
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
ba77ca58e9ccf711a975b69c888f34e5371e4628

> Fix issue with ./configure not correctly checking for files in contrib.
> For reasons that aren't clear the code "!(test ...)" doesn't work in
> bash on AIX; this commit replaces it with "! test ...". Hopefully this
> won't fail on some other operating system.
> gs/base/configure.ac

2012-10-12 19:06:08 +0100
Robin Watts <robin.watts@artifex.com>
d5904741b3e29c481bf0411c7fadd2c297b66828

> Remove statics from lxm3200 device.
> Remove this from the list of unthreadsafe devices.
> gs/base/configure.ac
> gs/contrib/gdevlx32.c
> gs/psi/msvc.mak

2012-10-12 18:33:55 +0100
Robin Watts <robin.watts@artifex.com>
f8d61ad9460e59381ca9239c383ec3f91d2e1679

> Fix cdj970 and fmlbp devices to be threadsafe.
> Avoid use of global variables.
> Remove these from the list of unthreadsafe devices.
> gs/base/configure.ac
> gs/contrib/gdevdj9.c
> gs/contrib/japanese/gdevfmlbp.c

2012-10-12 17:54:51 +0100
Robin Watts <robin.watts@artifex.com>
cb6bedc4c5b81c4cb074d1c784573fd96165cc8e

> Fix cp50 device to avoid use of global.
> Move 'int copies' into the device structure.
> Remove cp50 from list of un-threadsafe devices.
> gs/base/configure.ac
> gs/base/gdevcp50.c
> gs/psi/msvc.mak

2012-10-12 16:53:18 +0100
Robin Watts <robin.watts@artifex.com>
50ecd470347d33cef82fabb02b555f6854345485

> Fix contrib bjc devices to avoid global use.
> Should now be threadsafe, so remove these devices from the list of
> thread unsafe ones.
> gs/base/configure.ac
> gs/contrib/gdevbjc_.c
> gs/contrib/gdevbjc_.h
> gs/contrib/gdevbjca.c
> gs/psi/msvc.mak

2012-10-12 16:01:47 +0100
Chris Liddell <chris.liddell@artifex.com>
96e2afac86b8241e4e2dd758d2caf0c6434a102a

> Fix the check for duplicate entries.......
> ....in the list of devices excluded from a threadsafe build.
> No cluster differences.
> gs/base/configure.ac

2012-10-12 12:39:53 +0100
Robin Watts <robin.watts@artifex.com>
821d4c00e4507c0f68fd1eafb00622cbabcd1343

> Remove calls to gs_lib_ctx_get_non_gc_memory_t from contrib devices.
> This leaves the only calls to gs_lib_ctx_get_non_gc_memory_t being
> from the lcms v1 wrapper code (expected as lcms v1 is not thread
> safe), and from the gp_check_interrupts implementations (though these
> should no longer be required).
> Update the list of "not thread safe" devices in configure.ac; lots
> of devices are now thread safe. The ones that remain 'not thread safe'
> are those that use static variables (see bug 693376).
> gs/base/configure.ac
> gs/contrib/gdevcd8.c
> gs/contrib/gdevdj9.c
> gs/contrib/gdevgdi.c
> gs/contrib/gdevln03.c
> gs/contrib/gdevlx32.c
> gs/contrib/gdevlx7.c
> gs/contrib/gdevmd2k.c
> gs/contrib/gdevop4w.c
> gs/contrib/gdevxes.c
> gs/contrib/gomni.c
> gs/contrib/japanese/gdev10v.c
> gs/contrib/japanese/gdevalps.c
> gs/contrib/japanese/gdevdmpr.c
> gs/contrib/japanese/gdevespg.c
> gs/contrib/japanese/gdevfmlbp.c
> gs/contrib/japanese/gdevfmpr.c
> gs/contrib/japanese/gdevj100.c
> gs/contrib/japanese/gdevlbp3.c
> gs/contrib/japanese/gdevmag.c
> gs/contrib/japanese/gdevmjc.c
> gs/contrib/japanese/gdevnpdl.c
> gs/contrib/japanese/gdevp201.c
> gs/contrib/japanese/gdevrpdl.c
> gs/contrib/lips4/gdevl4r.c
> gs/contrib/lips4/gdevlprn.c
> gs/contrib/pcl3/eprn/eprnparm.c
> gs/contrib/pcl3/eprn/gdeveprn.c
> gs/contrib/pcl3/src/gdevpcl3.c

2012-10-12 10:22:38 +0100
Chris Liddell <chris.liddell@artifex.com>
10c70931c243f9d53c2df8b5f9e92fc93acfd4c9

> Add a --enable-threadsafe option to configure
> This adds -dGS_THREADSAFE to the CFLAGS, *and* filters the devices to remove
> non-threadsafe ones.
> The list of non-threadsafe devices is near the top of configure.ac (search
> for NTS_DEVS).
> No cluster differences.
> gs/base/configure.ac

2012-10-11 19:50:58 +0100
Robin Watts <robin.watts@artifex.com>
7012db5af074788bf7bf14ef3718fe72eae3e701

> Add Release-contrib and Debug-contrib VS Configuration.
> Also make the existing Debug-cups configuration show up in the solution
> properties.
> Building for any of these configurations only affects the ghostscript
> builds.
> common/msvc_top.mak
> gs/base/winlib.mak
> gs/ghostscript.vcproj
> gs/psi/msvc.mak
> main/pcl6_msvc.mak
> win32/GhostPDL.sln

2012-10-11 18:50:38 +0100
Robin Watts <robin.watts@artifex.com>
415be58773ac3ebedbe92c6cbdaa5cda9efebc9a

> Fix windows compilation of pcl3 devices.
> The pcl3 devices include support for a pagecount module that doesn't
> work under windows. The documentation for these devices suggests that
> they can be made to work by predefining EPRN_NO_PAGECOUNTFILE and
> editing the dependencies in the makefile to remove the need for
> pagefile.c.
> This commit simplifies that by making that symbol be defined
> automatically on a windows build, and nobbling pagefile.c with a
> gs/contrib/pcl3/eprn/eprnparm.c
> gs/contrib/pcl3/eprn/pagecount.c
> gs/contrib/pcl3/eprn/pagecount.h

2012-10-11 18:49:02 +0100
Robin Watts <robin.watts@artifex.com>
1d45b315e8f88b2d78eccba1a5943e59b3b6b14e

> Fix typo in commit/commit.mak
> The compile rule for gdevp201.obj was broken in a way that doesn't
> matter on unix, but upsets nmake.
> gs/contrib/contrib.mak

2012-10-11 08:54:32 -0700
Robin Watts <robin@peeves.(none)>
70e02af6a3a80586a506c18343aca7c297cbaae6

> Fix GS_THREADSAFE builds.
> mkromfs.c needed to not define some functions in GS_THREADSAFE cases.
> gxclutil.c had a mismatch between code to collect stats and code to
> print it.
> gs/base/gxclutil.c
> gs/base/mkromfs.c

2012-10-11 15:25:22 +0100
Robin Watts <robin.watts@artifex.com>
70488a2214a0ae36ad8ec0ca8b4ae0dff9745eb3

> Tweak gscms interface to avoid use of globals.
> Previously the only way to implement gscms_get_clrtname was to use a
> static buffer and to return a pointer to it. We change the interface
> so that gscms_get_clrtname takes a memory pointer, and allocates
> space for the returned thing.
> The LCMS2 implementation of this still uses a 256 byte stack based
> buffer as part of it's operation (so could potentially have problems
> with colorants longer than 256 bytes), but there is no way to avoid
> this in the current LCMS interface.
> gs/base/gsicc_cms.h
> gs/base/gsicc_lcms.c
> gs/base/gsicc_lcms2.c
> gs/base/gsicc_manage.c

2012-10-10 20:25:02 +0100
Robin Watts <robin.watts@artifex.com>
8e3cac4974512416582461af4776120de5b08c07

> Disable stat collection in GS_THREADSAFE builds.
> The collection of statistics for debugging is implemented in a
> non-threadsafe way. Disable it in GS_THREADSAFE builds.
> gs/base/gxcldev.h
> gs/base/gxclpath.c
> gs/base/gxclutil.c
> gs/base/gxfill.c
> gs/base/gxfill.h
> gs/base/gxifast.c
> gs/base/gxshade6.c
> gs/base/scfe.c
> gs/base/ttinterp.c
> gs/contrib/pcl3/eprn/mediasize.c
> gs/contrib/pcl3/src/pclcap.c

2012-10-10 16:25:10 -0700
Ray Johnston <ray.johnston@artifex.com>
dcd936432eb37fc5e3590a9377b1e3521ce70042

> Fix typo that was setting pattern clist BandHeight using size.x instead of .y
> This (AFAICT) didn't hurt because the clist_init_bands forced patterns to be
> nbands == 1, but was wrong and may confuse code that relies on BandHeight.
> gs/base/gxpcmap.c

2012-10-10 15:25:08 +0100
Robin Watts <robin.watts@artifex.com>
20693cec8d771eb16412a3296c0a16bbbf2ec852

> Ensure that all devices have non-NULL memory pointers.
> We use the memory pointers to get to the lib_ctx, hence having NULL
> memory pointers in device structures causes headaches.
> Checking the comments in gxdevcli.h it seems that memory should
> be NULL iff it's in a static prototype. Therefore anywhere that uses
> gx_device_init and passes a NULL pointer is suspect.
> Some places call gx_device_init and then set the memory pointer
> manually afterwards, to ensure that the reference counting is setup
> so that it does not attempt to free the device structure when all
> instances are gone. This is to indicate that the device structure
> is on the stack.
> As a neater alternative to this, we offer a gx_device_init_on_stack
> function that does the same thing, but makes this explicit.
> gs/base/gsdevice.c
> gs/base/gxacpath.c
> gs/base/gxclip.c
> gs/base/gxclip2.c
> gs/base/gxclip2.h
> gs/base/gxdevcli.h
> gs/base/gxmclip.c
> gs/base/gxmclip.h
> gs/base/gxp1fill.c
> gs/psi/zupath.c

2012-10-09 16:17:53 +0100
Robin Watts <robin.watts@artifex.com>
3231e8923e2bf4d535340a4d4a4335457c8ad1cf

> gp_check_interrupts GP_THREADSAFE fixes.
> When building with GP_THREADSAFE, gs_lib_ctx_get_non_gc_memory_t is
> not defined. This will cause at least 2 versions of gp_check_interrupts
> to fail. We patch them here to at least compile correctly.
> Also fix some places where the memory pointers used were invalid.
> Also fix a couple of calls to process_interrupts with explicitly NULL
> memory pointers.
> gs/base/gp_macpoll.c
> gs/base/gp_mspol.c
> gs/base/sfxstdio.c
> gs/base/stream.c
> gs/psi/iscan.c

2012-10-09 16:15:37 +0100
Robin Watts <robin.watts@artifex.com>
1793f3733ddb587a92efae41e188b7131eb2aa57

> Second attempt at fixing debugging printing with clists.
> The band file reading stream does not have a valid memory pointer
> as the structure is allocated on the stack, and to have a valid
> memory pointer would make the stream attempt to free the structure
> on a close.
> Here we add a 'local_memory' pointer that we use both for debugging
> printing, and for calls to process_interrupts.
> gs/base/gxclread.c

2012-10-10 16:18:49 +0100
Chris Liddell <chris.liddell@artifex.com>
586f1f5e9a29e1826b70cdd5aa1a77aa6b835f33

> Provide way for output pagesize to image size in view___.ps tools.
> For viewjpeg.ps and viewgif.ps this adds new procedures "viewJPEGgetsize" and
> "viewGIFgetsize" which return the dimensions of the input impage, thus allowing
> the caller to set the page size.
> For viewmiff.ps, viewpbm.ps, viewpcx.ps they take a new parameter "FITPAGE"
> which tell the utilities to fit the page to the image - they still honour the SCALE
> parameter, which is also used when setting the pagesize.
> CLUSTER_UNTESTED
> gs/lib/viewgif.ps
> gs/lib/viewjpeg.ps
> gs/lib/viewmiff.ps
> gs/lib/viewpbm.ps
> gs/lib/viewpcx.ps

2012-10-09 21:17:00 -0700
Michael Vrhel <michael.vrhel@artifex.com>
0dc01b095200fa4e04a9934c58ad97ff50c56916

> Addition of an internal CMM for direct color replacement of text, graphic and image RGB or CMYK colors
> This option is used with the -sSourceObjectICC file. Similar to the option to set None to request that
> no color management be used for a particular object type, here we use the keyword Replace to indicate
> that for that object type the colorants will be replaced by the method set up in gsicc_replacecm.c
> Currently to demonstrate its usage it provides a "negative" color mapping operation.
> gs/base/gdevp14.c
> gs/base/gscdevn.c
> gs/base/gscms.h
> gs/base/gscsepr.c
> gs/base/gsicc.c
> gs/base/gsicc_cache.c
> gs/base/gsicc_cms.h
> gs/base/gsicc_manage.c
> gs/base/gsicc_manage.h
> gs/base/gsicc_nocm.c
> gs/base/gsicc_replacecm.c
> gs/base/gxclimag.c
> gs/base/gxcmap.c
> gs/base/gxi12bit.c
> gs/base/gxicolor.c
> gs/base/gximono.c
> gs/base/gxiscale.c
> gs/base/gxshade.c
> gs/base/lib.mak
> gs/ghostscript.vcproj
> xps/xpsgradient.c

2012-10-09 13:17:25 -0600
Henry Stiles <henry.stiles@artifex.com>
a650680c5be1e034b8d4a5f6cd2704ae65182e43

> Fixes 693370 - the default join should be none not mitered.
> pcl/pgdraw.c

2012-10-08 17:24:48 +0100
Robin Watts <robin.watts@artifex.com>
6f7a425bbc0b560a776a76293b4a1fdaffc76248

> Bug 693328: Ensure that clist reader/writer devices stay in sync.
> The number of components records in reader/writers can get out of
> sync due to some 'limiting' code in the writer not being present in
> the reader.
> My first attempt at fixing this was to copy those few lines from
> pdf14_create_clist_device into gs_pdf14_device_push, but this caused
> SEGVs in some non-clist cases (72dpi CATX9004.pdf unbanded for example).
> Staring at the code a bit it seems odd to open a device and then change
> the number of colors in it; changing the number of colors *then* opening
> it makes much more sense. I have therefore moved the limiting code up
> a few lines in both pdf14_create_clist_device and gs_pdf14_device_push
> and everything seems much happier.
> 2 diffs shown in the cluster, 1 clearly a progression, 1 neutral.
> gs/base/gdevp14.c

2012-10-08 19:35:17 +0100
Robin Watts <robin.watts@artifex.com>
92f024cba125df4729f6a51fdf7b59e46fc71457

> Revert commit dcdc149 which broke various cluster tests.
> It seems that we can't put a valid mem pointer into the clist
> stream reading code, as the stream code takes this as an indication
> that the stream state should be freed on closedown.
> gs/base/gxclread.c

2012-10-08 17:31:01 +0100
Robin Watts <robin.watts@artifex.com>
b07dca2069a45793b70cb7faf51f53d932144a28

> Fix multi-threaded rendering use of wrong gs_memory_t.
> When we create rendering threads, we create a gs_memory_t * for each.
> The idea is that every thread should exclusively use its own gs_memory_t
> to avoid conflicts. The gsicc_cache was being setup to use the incorrect
> one.
> This was found (by Ray) when investigating bug 693361. This solves
> this particular error, but does not completely solve the bug.
> gs/base/gxclthrd.c

2012-10-08 17:28:52 +0100
Robin Watts <robin.watts@artifex.com>
dcdc149c49b2556e2038df4eab0da7f49de46100

> Fix clist stream memory initialisation.
> The clist file playback stream has never had it's memory pointer setup
> correctly - probably because it has never needed it. Now it does need it
> due to to the debugging print functions.
> gs/base/gxclread.c

2012-10-08 17:28:32 +0100
Robin Watts <robin.watts@artifex.com>
98946c1f9c015a6bbbb55a9401e4eeca47ce7147

> Whitespace tweak.
> gs/base/gxclrast.c

2012-10-08 10:30:29 +0100
Ken Sharp <ken.sharp@artifex.com>
f9c849768bdb3553ffeac74b74b04749e91bf4d5

> pdfwrite - when resizing arrays due to incrementally downloaded fonts, increase CIDToGODMapLength
> When TrueType fonts are incrementally downloaded, its possible for new character
> codes to exceed the number of glyphs originally defined in the TrueType tables.
> When this happens we resize various entries in our copy of the font. However
> the change to dynamically storing CIDToGIDMap and CIDSet (for PDF/A) omitted
> to increase the variable recording the array size (although the array was correctly
> resized).
> This led to glyphs with CIDs higher than the initial number of glyphs not having
> an entry in CIDToGIDMap, and tehrefore being treated as /.notdef
> No differences expected.
> gs/base/gdevpdtf.c

2012-10-07 19:30:21 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
6cbb5969cc2edab6417c673194f1c1d019d275ef

> Bug 693339: Replace malloc() with GS memory allocators in JPX code.
> We have 2 implementations of JPX decoding filters based on Luratech
> and OpenJpeg libraries. The Luratech one is now clean. The API to
> the library supports custom memory allocators.
> The OpenJpeg case is more difficult. The calls to malloc() in the
> wrapper code has been eliminated, but the library calls malloc()
> directly. To use a custom allcator one has to extend the API and
> change the signatures of all functions that allocate memory.
> gs/base/lib.mak
> gs/base/sjpx_luratech.c
> gs/base/sjpx_luratech.h
> gs/base/sjpx_openjpeg.c
> gs/base/sjpx_openjpeg.h
> gs/psi/zfjpx.c

2012-10-07 11:26:17 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
7f4726e7764a09b8d68927924e54d1ad23e284d1

> Bug 691931: Patch to resolve error in the number parser, the file now renders paths correctly
> but not the text which is not currently supported.
> svg/ghostsvg.h
> svg/svgshapes.c
> svg/svgtypes.c

2012-10-07 11:19:00 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
8785fa4c81b377abc633cd0baeffb7abd85b45d7

> Bug 693239: Prevent segfault due to optional width/height attributes.
> svg/svgdoc.c

2012-10-05 22:48:58 -0600
Henry Stiles <henry.stiles@artifex.com>
119de6b66bf1874c545b221a974ce88c78e462e8

> more warning fixes
> pl/plufont.c

2012-10-05 22:48:11 -0600
Henry Stiles <henry.stiles@artifex.com>
341865d2554ef04c0f873344f2a2d582a8353944

> more warning fixes
> pl/plulfont.c

2012-10-05 22:39:06 -0600
Henry Stiles <henry.stiles@artifex.com>
22ab5ef64b6364534012abecdf29b76402e7a08f

> warning cleanup
> pl/pluchar.c

2012-10-05 13:11:16 -0700
Michael Vrhel <michael.vrhel@artifex.com>
f5513b716ce5ce510120e2a08a766281d2b00c28

> Allow use of Device Link ICC Profile for source objects
> With the -sSourceObjectICC=filename option, it is now possible to specify a device link source
> profile for CMYK/RGB graphic, image and text objects. When such a profile is specified, the mapping
> will go from source directly to device values. Note that the use of a proofing profile is not
> possible and the device profile itself is not used in this transformation. However the device link
> profile that is associated with the device and specified with -sDeviceLinkProfile is included
> in the transform.
> gs/base/gscms.h
> gs/base/gsicc_cache.c
> gs/base/gsicc_cms.h
> gs/base/gsicc_lcms.c
> gs/base/gsicc_lcms2.c
> gs/base/gsicc_manage.c

2012-10-05 06:40:12 +0100
Ken Sharp <ken.sharp@artifex.com>
44687f1488b97bc007c6cfb02d4a25bcb3fd94e0

> pdfwrite - linearisation, correctly prevent buffer overrun
> Picked up by the compiler on the Mac.the test was impossible, because a byte
> cannot exceed a value of 255. The value (whcih triggers a buffer flush and reset)
> shuold of course have been 254, as it now is.
> No differences ewxpected
> gs/base/gdevpdf.c

2012-10-04 10:43:51 -0700
Michael Vrhel <michael.vrhel@artifex.com>
fc7c0751108e823d311418bfed920a5a4b3ed37b

> Expansion of spot color replacement to handle the mixing of DeviceN Colors
> The named color profile structure will now also be used for mixing of DeviceN colorants.
> This includes an update of the example to show the results.
> gs/base/gscdevn.c
> gs/base/gscsepr.c
> gs/base/gsicc_cache.c
> gs/base/gsicc_cache.h
> gs/base/lib.mak
> gs/toolbin/color/named_color/named_color_table.txt
> gs/toolbin/color/named_color/named_colors.pdf

2012-10-04 19:19:58 -0600
Henry Stiles <henry.stiles@artifex.com>
c0b2a6eb8b26af6f1cea99efd97354ee3c22f28a

> These header files should have been added with the warning message
> cleanup commit (deeef25).
> pcl/rtmisc.h
> pl/plchar.h

2012-10-04 13:32:47 -0600
Henry Stiles <henry.stiles@artifex.com>
deeef25f35ff78e75a5ad6d056c481f1b1013c66

> Warning cleanup.
> pcl/pcdraw.c
> pcl/pcfsel.c
> pcl/pcindxed.c
> pcl/pcl.mak
> pcl/pcpatrn.c
> pcl/pcstatus.c
> pcl/pcuptrn.c
> pcl/pgfdata.c
> pcl/pgfdata.h
> pcl/pgfont.c
> pcl/pgmand.h
> pcl/rtmisc.c
> pl/pl.mak
> pl/plchar.c
> pl/plfont.c
> pl/plfont.h
> pl/plplatf.c
> pl/plsrgb.c
> pl/pluchar.c
> pxl/pxffont.c
> pxl/pxfont.c
> pxl/pxfont.h
> pxl/pxgstate.h
> pxl/pxl.mak
> pxl/pxpthr.c
> pxl/pxpthr.h
> pxl/pxstate.c
> pxl/pxstate.h
> pxl/pxtop.c

2012-10-02 21:51:18 -0700
Michael Vrhel <michael.vrhel@artifex.com>
18f1da650322713395aceafb25f495149c8f0cda

> Turn on ability to specify no color management from the srcgtag structure for different objects
> With this, it is possible in the srcgtag structure to specify that we will not do color management
> for RGB or CMYK graphic, image and text objects. This is done by specifying the keyword None after
> the particular tag. For example "Graphic_CMYK None" in the file that is used with the -sSourceObjectICC
> command option. In the above case, all CMYK source graphics would be mapped using the unmanaged color
> methods (e.g. 255-X) Also we added in support for preserveK, override source ICC and black point
> compensation on an object based case. Had to worry about the case where the profile passes through
> the clist in the commit and had to add in a new parameter to the profile to ensure that the rendering
> conditions are associated with the source profile. Also fixed a bug to keep from changing the number of
> channels in the link format.
> gs/base/gdevp14.c
> gs/base/gscms.h
> gs/base/gscsepr.c
> gs/base/gsicc.c
> gs/base/gsicc_cache.c
> gs/base/gsicc_lcms2.c
> gs/base/gsicc_manage.c
> gs/base/gsicc_nocm.c
> gs/base/gxclimag.c
> gs/base/gxclist.c
> gs/base/gxclist.h
> gs/base/gxcmap.c
> gs/base/gxi12bit.c
> gs/base/gxicolor.c
> gs/base/gximono.c
> gs/base/gxiscale.c
> gs/base/gxshade.c
> xps/xpsgradient.c

2012-10-04 10:02:02 +0100
Chris Liddell <chris.liddell@artifex.com>
44616dd78f9af00a47a4c27e5491537df28cd964

> Eliminate last_char global variable.
> last_char value is now stored in the pl_font_s structure.
> pl/plchar.c
> pl/plfont.c
> pl/plfont.h

2012-10-03 09:29:47 +0100
Ken Sharp <ken.sharp@artifex.com>
37e1da602cff3378b3d985637dc582f206aa5cd8

> txtwrite - fix a typo causing text to be incorrect
> When the text operation was TEXT_FROM_CHARS or TEXT_FROM_SINGLE_CHAR the code
> was referencing the 'bytes' structure member, not the 'chars' structure member.
> Also fixed a potential signed/unsigned mismatch in pdfwrite and a 32/64 bit
> mismatch in txtwrite, both picked up by Henry. It would be nice to know why
> the 'new compiler warnings' check didn't flag these, possibly they predate
> that check.
> No differences expected.
> gs/base/gdevpdf.c
> gs/base/gdevtxtw.c

2012-10-01 10:48:01 -0700
Michael Vrhel <michael.vrhel@artifex.com>
ae25729f69a9ece10d6fdbb0c0c213c4e27aea7c

> Change to a more sane storage of the color rendering conditions to s common structure type
> As more conditions variables are introduced, e.g. rendering intent, black point compensation, preserve black
> etc. it has become clear that we need a structure for these variables making it easy to introduce new ones.
> Also clean up a lot of the usage methods to ensure that proper override occurs without having to set a
> pile of command line options.
> gs/Resource/Init/gs_lev2.ps
> gs/base/gdevp14.c
> gs/base/gscms.h
> gs/base/gscspace.c
> gs/base/gsdevice.c
> gs/base/gsdparam.c
> gs/base/gsequivc.c
> gs/base/gsicc_cache.c
> gs/base/gsicc_lcms2.c
> gs/base/gsicc_manage.c
> gs/base/gsicc_manage.h
> gs/base/gstrans.c
> gs/base/gxclimag.c
> gs/base/gxcmap.c
> gs/psi/zusparam.c

2012-10-02 20:37:15 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
f1a459c6e695f065f036db4a8946ae726ee69eac

> Bug 693285: Apply update of original patch from zeniko. We now check that the symbol dictionary
> being imported is not empty. Also prevent seg faults resulting from the threadsafe update.
> gs/base/sjbig2.c
> gs/jbig2dec/jbig2_symbol_dict.c

2012-10-02 13:18:25 -0600
Henry Stiles <henry.stiles@artifex.com>
80dc061ed4717eef205be05e764ac4f1b8c67632

> fix mismatched parameter type, possibly associated with bug #693362
> pcl/pgfont.c
> pl/plchar.c
> pl/plfont.c
> pl/plfont.h

2012-10-02 12:48:13 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
281b221f4632ba243efa325663dfb223d42028ff

> Add missing initialisation of override_bp
> Fix a Valgrind warning and a possible cause of indeterminism.
> gs/base/gsicc_manage.c

2012-10-02 13:26:48 +0100
Chris Liddell <chris.liddell@artifex.com>
7c47cd47fc96a2f8af5723dbe777526a7fc64c9a

> White space and warning fixes for bigtiff commit.
> No cluster differences.
> gs/base/gdevtfax.c
> gs/base/gdevtifs.c
> gs/base/gdevtsep.c

2012-10-02 11:07:09 +0100
Ken Sharp <ken.sharp@artifex.com>
5784bfbfba7191cacce5309e88afac0851287460

> Add preservation of PageLabels from input PDF files when using pdfwrite
> Bug #692901 "Preserve Page labels from input PDF when the output is PDF"
> Because hte defined pdfmark /PAGELABEL is not flexible enough to handle all
> the possible kinds of page labels in PDF, and because it transpires we don't
> emit pdfmarks when producing PostScript with ps2write, this feature does
> not use teh pdfmark syntax.
> It does work in a broadly similar way, we create a string from the PageLabels
> entry in the Catalog dictionary (if present) and then pass that via put_params
> with a parameter naem of pdfpagelabels (pdfmark uses a name of pdfmark).
> This string is then stored in the Catalog dictionary, and emitted when the
> output PDF is created.
> I'm unable to test this against the original report, as no specimen PDF file
> was provided.
> No differences expected, this makes no changes in rendering.
> gs/Resource/Init/gs_pdfwr.ps
> gs/Resource/Init/pdf_main.ps
> gs/base/gdevpdfp.c

2012-09-28 09:23:36 +0100
Chris Liddell <chris.liddell@artifex.com>
79af8e5bff7321b6985ea0bd5dd5b4a5a4c2590a

> Provide bigtiff output option.
> All the tiff devices now support the device parameter "-dUseBigTIFF" which
> tells them to write their output in "bigtiff" format, rather than "normal"
> tiff.
> In the event that we overflow the allowed file size in normal tiff, the existing
> error message is augmented with a hint to try bigtiff output.
> To implement the above warning has meant adding warning and error handling hooks
> for libtiff, and also adding file I/O hooks for libtiff.
> This requires libtiff version >=4.0.0, so linking with older libtiff versions
> will cause us to ignore the UseBigTIFF setting.
> No cluster differences.
> gs/base/gdevtfax.c
> gs/base/gdevtfnx.c
> gs/base/gdevtifs.c
> gs/base/gdevtifs.h
> gs/base/gdevtsep.c

2012-10-01 08:41:11 +0100
Ken Sharp <ken.sharp@artifex.com>
b81847783db2c17e11d40feeb0812ff7d129aca9

> Bug #691319 - Preserve Flags (/F) from Text annotations
> When creating pdfmarks for the benefit of pdfwrite, the PDF interpreter
> only handles two types of annotation, Text and Link. We were handling the
> Flags entry for Link annotations, but not for Text annotations.
> Here we preserve the Flags for text annotations too.
> No differences expected, not tested by cluster.
> gs/Resource/Init/pdf_main.ps

2012-09-28 14:40:35 +0100
Ken Sharp <ken.sharp@artifex.com>
4b9424c7bf7c74613cd004195592d41893dd3bd5

> Remove more traces of pdfopt from the repository and documentation
> gs/doc/Develop.htm
> gs/doc/Ps2pdf.htm
> gs/doc/Psfiles.htm
> gs/lib/pdfopt
> gs/lib/pdfopt.bat

2012-09-28 14:34:27 +0100
Ken Sharp <ken.sharp@artifex.com>
260ddb3e53ffe852a8994dd00719931ca3f2beec

> With the addition of linearisation to pdfwrite, pdfopt.ps has become
> redundant. Since it is difficult to maintain, has a number of bugs, and is
> believed not to work properly anyway, it is now deprecagted and hence
> removed from the repository.
> gs/lib/pdfopt.ps

2012-09-28 13:08:06 +0100
Ken Sharp <ken.sharp@artifex.com>
f2a40a3a7edd6d27caeaa19f7f644adf31ee972c

> pdfwrite - linearisation completion
> Update ps2pdf.htm documentation
> CHange parameter name to 'FastWebView'
> Don't writ the xref on the initial file, as we don't need it and it makes
> the original file slightly smaller, which reduces the chances that we will
> have to pad the linearised file. (The linearised file must be no smaller
> than the original, because we do not close the file, we just seek around and
> rewrite it). Same with the trailer dictionary.
> Fix 'rewrite object' so that dictioanry and array objects can be of any size
> previously we had assunmed they would be less than 64k, but some complex
> files broke that.
> If the linearised file is smaller than the original, we need to add white
> space to bring it up to the same size, or we will be left with garbage at
> the end. Worse, the garbage may well contain a partial invalid xref.
> Remove the check for one page files as Adobe specifically allows linearising
> single page documents....
> gs/base/gdevpdf.c
> gs/base/gdevpdfp.c
> gs/doc/Ps2pdf.htm

2012-09-28 07:54:54 +0100
Chris Liddell <chris.liddell@artifex.com>
3c23fe12abb6a158abf1c515601db7b2f94c5463

> Reinstate tiffsep1 and svgwrite in the device lists
> I accidentally left out tiffsep1 when I consolidated the two lists of TIFF
> devices, so putting it back now.
> svgwrite was removed a while ago due to being incomplete and flaky, but there
> has been ongoing interest in the device, some patches posted, so reinstate it
> to make it easier for people to test/debug/develop.
> It's included in the "FILES" class of devices.
> No cluster differences.
> gs/base/configure.ac

2012-09-27 10:18:27 -0700
Michael Vrhel <michael.vrhel@artifex.com>
3a0483fddf55e091aafa1bd4822bd77b19b481b3

> Update Use.htm with ICC command updates.
> gs/doc/Use.htm

2012-09-27 10:06:51 -0700
Michael Vrhel <michael.vrhel@artifex.com>
666890f41d3ca928498a8652fa7d102cd9f22191

> Update color document with recent changes.
> gs/doc/GS9_Color_Management.pdf
> gs/doc/GS9_Color_Management.tex

2012-09-27 17:21:16 +0100
Ken Sharp <ken.sharp@artifex.com>
53547c0892c48e248a146667f280886b362befc1

> pdfwrite - linearisation, fix some seg faults
> The code was inadvertently incrementing an array index twice, leading to
> out of bounds memory access, and consequent memory corruption.
> No differences expected, this is not cluster tested.
> gs/base/gdevpdf.c

2012-09-24 23:15:43 -0700
Michael Vrhel <michael.vrhel@artifex.com>
408cbb83103ba9cf6996eeebaa02995cd9f535ad

> Addition of support for allowing control over the use of black point compensation in color management
> Black point compensation is a new extended graphic state entry in the extended graphic
> state with PDF 2.0 . This change adds it to the graphic state. This update also allows
> the same type of override control for black point that we currently have for the
> rendering intent. This includes specification of its use by source object type with
> the use of -sSourceObjectICC for source RGB and CMYK graphic, images and text objects.
> Alternatively, control can be achieved for the whole document via object type
> by specification -dBlackPtComp=0/1. Alternatively, you can specify control
> on an object based method using -dGraphBlackPt=0/1
> -dImageBlackPtComp=0/1 -dTextBlackPtComp=0/1. All of these
> will require the setting of -dOverrideBP to ensure that the document content does not
> interfere with the command line setting. Note that these are not true/false settings
> but integer values like the rendering intent. This is to allow the easy expansion
> to other black point compensation options as described by Bug 692223.
> gs/Resource/Init/gs_lev2.ps
> gs/base/gdevp14.c
> gs/base/gscms.h
> gs/base/gscsepr.c
> gs/base/gscspace.c
> gs/base/gsdparam.c
> gs/base/gsequivc.c
> gs/base/gsicc.c
> gs/base/gsicc_cache.c
> gs/base/gsicc_lcms2.c
> gs/base/gsicc_manage.c
> gs/base/gsicc_manage.h
> gs/base/gsstate.c
> gs/base/gsstate.h
> gs/base/gstrans.c
> gs/base/gxclimag.c
> gs/base/gxcmap.c
> gs/base/gxi12bit.c
> gs/base/gxicolor.c
> gs/base/gximono.c
> gs/base/gxiscale.c
> gs/base/gxistate.h
> gs/base/gxshade.c
> gs/psi/zcolor3.c
> gs/psi/zusparam.c
> gs/toolbin/color/src_color/objsrc_profiles_example.txt
> xps/xpsgradient.c

2012-09-26 11:02:22 +0100
Robin Watts <robin.watts@artifex.com>
1770ca69b258c571565d9a6fc7bb9fb0ebd539e4

> Bug 693357: Fix typo
> In the big debugging printf commit of the other day, I introduced a
> typo into the luratech jbig2 code. Fixed here.
> gs/base/sjbig2_luratech.c

2012-09-26 10:52:46 +0100
Robin Watts <robin.watts@artifex.com>
45ba06c92cf7cb290b1c76f4380606323579e5b9

> Fix DEBUG mode SEGVs; bug 693359
> In at least a couple of places I was reading a memory pointer from a
> structure that wasn't filled in. Simple fixes here.
> This solves the crashing with -ZBb in any file with an image pointed
> out by Henry on irc.
> I'm sure there will be more such problems due to the wide ranging
> nature of the commit that changed this; hopefully all will be as
> simple to solve as this.
> gs/base/gxipixel.c
> gs/base/gxp1fill.c

2012-09-26 09:06:22 +0100
Ken Sharp <ken.sharp@artifex.com>
3894e9c8a3ab125c82048da3bf81515500bb2da0

> pdfwrite - emit partial pages
> previously, if an input file made marks on the page but did not call
> showpage (or equivalent in other languages), pdfwrite would write all the
> objects to the file, but would not add the final partial page to the Pages
> tree, which meant that the final page didn't appear.
> It seems that Adobe Acrobat behaves differently, and produces the final page
> under these conditions. This commit changes our behaviour to match the
> observed Adobe behaviour.
> This was noticed when running some Quality Logic test files, it appears that
> the cluster runs in a mode where these partial pages were always emitted
> anyway (because of the CET conformance hacks) so there are only a few files
> which display any differences.
> gs/base/gdevpdf.c

2012-09-25 19:43:21 +0100
Robin Watts <robin.watts@artifex.com>
1deb66b8f5e53f8a560ced10fe777a55e42fc6f2

> Fix garbage collection troubles with icc code.
> Historically, due to lcms/lcms2 allocating stuff using malloc/free
> the profiles haven't been subject to garbage collection. When I
> fixed gscms_create/destroy not being called properly, this caused
> lcms2 to start allocating blocks properly with the gs allocators.
> To ensure that these blocks weren't unexpectedly garbage collected
> away, I modified one of the calls from gsicc_cache.c to the gscms
> layer to pass in a non_gc memory pointer. This worked well, but I
> missed a second call in which I should have done the same.
> Fixed here. This cures bug 693349.
> gs/base/gsicc_cache.c

2012-09-21 12:34:16 -0700
Ray Johnston <ray.johnston@artifex.com>
873455f29e399fc5f7b489c50cfb869fdc26cb0d

> Simplify mkromfs build dependencies, add needed debug and error printing.
> Since mkromfs minimal memory implementation left the gs_lib_ctx set to NULL,
> the errwrite and outwrite functions would de-reference a NULL causing a
> Segmentation violation if gp_unix ever printed anything. This removes the
> need for the gsmisc.o altogether and removes the need for gslibctx.o and
> the dummy gscms functions.
> gs/base/mkromfs.c
> gs/base/unix-aux.mak

2012-09-24 09:25:35 -0700
Michael Vrhel <michael.vrhel@artifex.com>
bb0ef5ed637757290a88709fa1543585b29ccc54

> Update color management documentation with information about NCLR ICC profile usage.
> gs/doc/GS9_Color_Management.pdf
> gs/doc/GS9_Color_Management.tex

2012-09-24 09:22:41 -0700
Michael Vrhel <michael.vrhel@artifex.com>
5176cb8c3882de51e413880ec2818a45a9d7c139

> Fix a few typos.
> gs/doc/Use.htm

2012-09-21 22:48:37 -0700
Michael Vrhel <michael.vrhel@artifex.com>
8227d2d46b516b75a4383466eb243b725f3124b0

> Support for the use of N-CLR ICC output profiles extended to the tiffsep device.
> The documentation on the use of this option was also updated.
> gs/base/gdevdevn.h
> gs/base/gdevpsd.c
> gs/base/gdevtsep.c
> gs/doc/Use.htm

2012-09-20 22:55:45 -0700
Michael Vrhel <michael.vrhel@artifex.com>
8a1ca14aab8f3ef6a7ffaa554d4e1d348b7561a7

> Bulk of work to demonstrate the use of DeviceN ICC output profile.
> This adds support to the psdcmyk device as well as the required changes in
> the graphics library. Through the use of the LIMIT_TO_ICC define in gdevpsd, it is
> possible to limit the colorants to those defined by the ICC output profile.
> Setting to 1 will limit it setting to 0 will allow all spots (up to the maximum)
> to be created. If spot names in the document match those in the command line
> with -sICCOutputColors, then those colorants and hence separation will be treated
> the same.
> gs/base/gdevpsd.c
> gs/base/gscdevn.c
> gs/base/gscms.h
> gs/base/gscsepr.c
> gs/base/gsequivc.c
> gs/base/gsicc.c
> gs/base/gsicc_manage.c
> gs/base/gsicc_manage.h
> gs/base/gxcmap.c
> gs/base/gxistate.h
> gs/base/lib.mak

2012-09-21 18:49:41 +0100
Robin Watts <robin.watts@artifex.com>
51bc075100060ca1f90dd5d3d6c467597202d27d

> Import LCMS 2.4 (patched)
> Here we import LCMS 2.4 with our existing patches into gs.
> Cluster testing this shows various changes; most of these are just
> small rounding issues. It is possible that some of this is due to
> Marti adopting our revised 16 -> 8 code and having pushed it further
> through the code than we had.
> Also there are changes to the black point compensation code designed
> to more accurately match Adobe. For some test files that have
> deliberately extreme profiles we get noticably different results.
> Supposedly this is because those profiles do not round trip nicely,
> but after discussing it with Michael he says it's nothing to worry
> about.
> gs/base/lcms2.mak
> gs/ghostscript.vcproj
> gs/lcms2/AUTHORS
> gs/lcms2/ChangeLog
> gs/lcms2/Makefile.in
> gs/lcms2/Projects/.gitignore
> gs/lcms2/Projects/BorlandC_5.5/lcms2.rc
> gs/lcms2/Projects/BorlandC_5.5/lcmsdll.lk
> gs/lcms2/Projects/BorlandC_5.5/lcmsdll.lst
> gs/lcms2/Projects/VC2008/lcms2_DLL/lcms2_DLL.vcproj
> gs/lcms2/Projects/VC2008/lcms2_static/lcms2_static.vcproj
> gs/lcms2/Projects/VC2010/jpegicc/jpegicc.vcxproj
> gs/lcms2/Projects/VC2010/lcms2.sln
> gs/lcms2/Projects/VC2010/lcms2_DLL/lcms2_DLL.vcxproj
> gs/lcms2/Projects/VC2010/lcms2_DLL/lcms2_DLL.vcxproj.filters
> gs/lcms2/Projects/VC2010/lcms2_static/lcms2_static.vcxproj
> gs/lcms2/Projects/VC2010/lcms2_static/lcms2_static.vcxproj.filters
> gs/lcms2/Projects/VC2010/linkicc/linkicc.vcxproj
> gs/lcms2/Projects/VC2010/psicc/psicc.vcxproj
> gs/lcms2/Projects/VC2010/testbed/testbed.vcxproj
> gs/lcms2/Projects/VC2010/tiffdiff/tiffdiff.vcxproj
> gs/lcms2/Projects/VC2010/tifficc/tifficc.vcxproj
> gs/lcms2/Projects/VC2010/transicc/transicc.vcxproj
> gs/lcms2/Projects/mac/._.DS_Store
> gs/lcms2/Projects/mac/LittleCMS/._.DS_Store
> gs/lcms2/Projects/mac/LittleCMS/Info.plist
> gs/lcms2/Projects/mac/LittleCMS/LittleCMS.xcodeproj/mariama.mode1v3
> gs/lcms2/Projects/mac/LittleCMS/LittleCMS.xcodeproj/mariama.pbxuser
> gs/lcms2/Projects/mac/LittleCMS/LittleCMS.xcodeproj/project.pbxproj
> gs/lcms2/aclocal.m4
> gs/lcms2/configure
> gs/lcms2/configure.ac
> gs/lcms2/doc/LittleCMS2.3 API.pdf
> gs/lcms2/doc/LittleCMS2.3 Plugin API.pdf
> gs/lcms2/doc/LittleCMS2.3 tutorial.pdf
> gs/lcms2/doc/LittleCMS2.4 API.pdf
> gs/lcms2/doc/LittleCMS2.4 Plugin API.pdf
> gs/lcms2/doc/LittleCMS2.4 tutorial.pdf
> gs/lcms2/include/Makefile.in
> gs/lcms2/include/lcms2.h
> gs/lcms2/include/lcms2_extras.h
> gs/lcms2/include/lcms2_plugin.h
> gs/lcms2/src/Makefile.am
> gs/lcms2/src/Makefile.in
> gs/lcms2/src/cmscam02.c
> gs/lcms2/src/cmscgats.c
> gs/lcms2/src/cmscnvrt.c
> gs/lcms2/src/cmserr.c
> gs/lcms2/src/cmsgamma.c
> gs/lcms2/src/cmsgmt.c
> gs/lcms2/src/cmshalf.c
> gs/lcms2/src/cmsintrp.c
> gs/lcms2/src/cmsio0.c
> gs/lcms2/src/cmsio1.c
> gs/lcms2/src/cmslut.c
> gs/lcms2/src/cmsmd5.c
> gs/lcms2/src/cmsmtrx.c
> gs/lcms2/src/cmsnamed.c
> gs/lcms2/src/cmsopt.c
> gs/lcms2/src/cmspack.c
> gs/lcms2/src/cmspcs.c
> gs/lcms2/src/cmsplugin.c
> gs/lcms2/src/cmsps2.c
> gs/lcms2/src/cmssamp.c
> gs/lcms2/src/cmssm.c
> gs/lcms2/src/cmstypes.c
> gs/lcms2/src/cmsvirt.c
> gs/lcms2/src/cmswtpnt.c
> gs/lcms2/src/cmsxform.c
> gs/lcms2/src/cmsxform.h
> gs/lcms2/src/cmsxform_extras.c
> gs/lcms2/src/lcms2.def
> gs/lcms2/src/lcms2_internal.h
> gs/lcms2/testbed/Makefile.am
> gs/lcms2/testbed/Makefile.in
> gs/lcms2/testbed/testcms2.c
> gs/lcms2/utils/common/utils.h
> gs/lcms2/utils/common/vprf.c
> gs/lcms2/utils/common/xgetopt.c
> gs/lcms2/utils/delphi/lcms2dll.pas
> gs/lcms2/utils/jpgicc/Makefile.in
> gs/lcms2/utils/jpgicc/jpgicc.c
> gs/lcms2/utils/linkicc/Makefile.in
> gs/lcms2/utils/psicc/Makefile.in
> gs/lcms2/utils/tificc/Makefile.in
> gs/lcms2/utils/tificc/tificc.c
> gs/lcms2/utils/transicc/Makefile.in
> gs/lcms2/utils/transicc/transicc.c

2012-09-21 19:07:48 +0100
Robin Watts <robin.watts@artifex.com>
2346369bb7536062946d409f940e865791afc34a

> Fix typo in previous commit; return NULL in void function.
> MSVC and gcc both accept it with a warning, hence I didn't spot it.
> Sorry.
> gs/base/gslibctx.c

2012-08-25 00:38:56 +0100
Robin Watts <robin.watts@artifex.com>
0eae840336f244e5b0d195109e1dd9e104396d87

> Arrange for gscms_create/destroy to be called correctly.
> gscms_create should be called before any other cms call is made,
> but it's not being. It not being called has meant that lcms has
> always been using malloc/free rather than the gs allocation
> functions. Fix some bugs in those allocation functions that show
> up now they are used.
> Also ensure that pointers are correctly enumerated.
> Ensure that cms set context pointer actually makes it into links.
> Update gscms interface to ensure that errors on gscms_create can
> be responded to.
> This work has exposed a problem wrt the context pointer in the
> gscms interface, so we fix that here too.
> The theory has always been that we can drop new and different
> CMS engines into ghostscript, by wrapping each one with some code
> that implements the gscms_ functions from gsicc_cms.h.
> While this interface was developing, I started to add support for
> a context pointer, but looking back at it, it seems I never
> completed the work and it was left in a state where it was useless.
> After much discussion with Michael, we've decided that the best way
> to proceed is to arrange for gscms_create to be called when gs
> starts up (just after the base level allocator is created), and for
> gscms_destroy to be called as gs exits (just before the base level
> allocator is destroyed).
> This base level allocator is passed into gscms_create/gscms_destroy
> so it can safely allocate memory. Furthermore, we have done away
> with explicitly passing the cms_context pointer around, as it was
> not really any use in its current form. Instead, we have added
> functions to get/set the context pointer in the gs_lib_ctx.
> void *gs_lib_ctx_get_cms_context( const gs_memory_t *mem );
> void gs_lib_ctx_set_cms_context( const gs_memory_t *mem, void *cms_context );
> As the gscms functions take mem pointers in all the interesting
> places, this should be sufficient.
> As mkromfs calls the gs lib ctx init stuff, we have had to add stubs
> for gscms_create/destroy to mkromfs.c.
> gs/base/gscms.h
> gs/base/gsicc_cache.c
> gs/base/gsicc_cache.h
> gs/base/gsicc_cms.h
> gs/base/gsicc_lcms.c
> gs/base/gsicc_lcms2.c
> gs/base/gsicc_manage.c
> gs/base/gsicc_nocm.c
> gs/base/gslibctx.c
> gs/base/gslibctx.h
> gs/base/gsmalloc.c
> gs/base/mkromfs.c

2012-09-21 13:52:25 +0100
Robin Watts <robin.watts@artifex.com>
8ef93d4d8f33149cb7d244da52d47e82a11f9019

> Fix LCMS threading issue with plugin registration.
> When registering a plugin, allocations can be done. This can result
> in calls back to the user supplied malloc functions, which assume
> that a cmsContext will be supplied. In the current code there is
> no way to pass a cmsContext into the plugin registration.
> We therefore add a new function cmsPluginTHR that does take such a
> context.
> Currently this isn't called yet, as gscms_create/destroy aren't correctly
> called.
> gs/lcms2/include/lcms2.h
> gs/lcms2/src/cmscnvrt.c
> gs/lcms2/src/cmsgamma.c
> gs/lcms2/src/cmsopt.c
> gs/lcms2/src/cmspack.c
> gs/lcms2/src/cmsplugin.c
> gs/lcms2/src/cmstypes.c
> gs/lcms2/src/lcms2_internal.h

2012-09-20 20:12:27 +0100
Robin Watts <Robin.Watts@artifex.com>
81946ddaca41eb0726d4435a6217b3e017bd7a8c

> Patch LCMS threading bug.
> LCMS maintains a ContextID for the sake of the allocator callbacks.
> In the call sequence through, it was losing this and ending up with
> the allocators being called with NULL.
> Simple fix.
> gs/lcms2/src/cmssamp.c

2012-09-20 17:18:39 +0100
Ken Sharp <ken.sharp@artifex.com>
7a70a32618642f17104747dc2f5785775b42495b

> pdfwrite - linearisation, correctly renumber resoruces in arrays
> The code to renumber resources was only checking for indirect references in
> dictionaries, we need to check arrays as well.
> No differences expected.
> gs/base/gdevpdf.c

2012-09-20 15:47:08 +0100
Ken Sharp <ken.sharp@artifex.com>
455ecb61885dcceccb23fb16518bb1790c40eb40

> pdfwrite - linearisation bug fixes
> Allow return code to be 0 when seeking so we don't lose the first part of
> the linearised file.
> If the input job makes marks on the final page, but does not call showpage,
> we discard the final page. This can lead to resources being marked as 'used'
> on pages that no longer exist. We now ignore such usage.
> Fix an 'off by 1' error when indexing an array using paeg numbers
> (page numebrs are 1->n, array is 0->n-1)
> Put a #ifdef round some debug prints so they don't end up in the cluster log
> Some resources are only used by other resources (eg Encoding) and should take
> on the Page Usage of their parent. If the parent resource was shared we werne't
> correclty updating the child with all the pages the parent was used on.
> Some memory was being double freed causing seg faults.
> No differences expetced as cluster doesn't test linearisation.
> gs/base/gdevpdf.c

2012-09-19 16:42:42 +0100
Robin Watts <Robin.Watts@artifex.com>
cd4826a3a5e3000df0e5f787e3b6ceec88c43885

> Remove gs_lib_ctx_get_non_gc_memory_t in GS_THREADSAFE builds.
> gs_lib_ctx_get_non_gc_memory_t relied on a static to implement it,
> so is incompatible with multi-threaded builds. Removing it
> causes various devices/bits of code to break. We fix the
> important (i.e. mostly non-contrib) devices that use it here.
> We also rework the gscms/lcms interface code to avoid it too.
> With this commit in, helgrind apitests tiger to ppmraw as being
> clean.
> gs/base/gdevrinkj.c
> gs/base/gdevxcf.c
> gs/base/gsicc_cache.c
> gs/base/gsicc_cms.h
> gs/base/gsicc_lcms.c
> gs/base/gsicc_lcms2.c
> gs/base/gsicc_manage.c
> gs/base/gsicc_manage.h
> gs/base/gslibctx.c
> gs/base/gslibctx.h
> gs/psi/zicc.c

2012-09-19 16:16:32 +0100
Robin Watts <Robin.Watts@artifex.com>
9ccfc96d8885b419437f985baa7d26db3ff1950a

> Add some PACIFY_VALGRIND magic for helgrind.
> Various bits of code (notably gs_debug, some clist function pointers
> and some constants in lcms) are held in statics. We accept that
> gs_debug is going to be thread unsafe and choose to ignore it.
> The others are initialised multiple times (to the same values) and
> then never changed.
> Helgrind is not smart enough to see that these are repeatedly
> updated to the same values, so flags an error every time they are
> written to.
> We therefore add a bit of Valgrind magic before these places to
> tell it to ignore these addresses when checking.
> gs/base/gsinit.c
> gs/base/gxclfile.c
> gs/base/gxclist.c
> gs/base/gxclmem.c
> gs/lcms2/src/cmserr.c
> gs/lcms2/src/cmswtpnt.c
> gs/psi/imain.c
> pl/plplatf.c
> pl/plplatfps.c

2012-09-19 16:11:58 +0100
Robin Watts <Robin.Watts@artifex.com>
9171c68f18ba278aa72df4a30ba89bb5400bdd79

> Disable various bits of debugging stats etc for GS_THREADSAFE
> Various bits of code use statics to gather statistics in DEBUG
> builds; disable these in GS_THREADSAFE builds as they are
> incompatible with multi-threaded operation.
> gs/base/gdevm24.c
> gs/base/gdevm40.c
> gs/base/gdevm48.c
> gs/base/gdevm56.c
> gs/base/gdevm64.c
> gs/base/gxclip.c
> gs/base/gxfill.c
> gs/psi/idict.c
> gs/psi/idstack.c
> gs/psi/interp.c

2012-09-19 13:05:20 +0100
Robin Watts <Robin.Watts@artifex.com>
2e03d8c5aac80eb56cb9097a316dc36bf311d380

> Update LCMS2 to avoid race condition in Tag handling.
> LCMS2 as supplied (in both 2.3 and 2.4 at least) is broken w.r.t
> multitasking due to a race condition in the Tag handling.
> When a TagTypeHandler is needed, it is looked up from a system table.
> The existing code then writes into this table with the ContextID and
> calls the handler. This is a race condition if 2 threads are using
> the same TagTypeHandler at a time.
> The fix implemented here is to copy the TagTypeHandler structure to a
> local one, write the ContextID into that, and then call through that.
> gs/lcms2/src/cmsio0.c

2012-09-13 00:40:03 +0100
Robin Watts <robin.watts@artifex.com>
6777c88fab2afc3e6558fda1dfb51110088ede61

> Introduce GS_THREADSAFE define and modify printing calls.
> Lots of debugging/error information is printed using eprintf and
> dlprintf etc. These functions do not take a gs_memory_t * and are
> not safe for use within code that runs under multiple instances
> created by gsapi.
> Introduce new versions (dmprintf, dmlprintf etc) that DO take a
> gs_memory_ *, and move as much of ghostscript/ghostpdl's usage
> over to these as possible. I have not touched the contrib directory,
> and some locations in the code do not easily have a gs_memory_t
> to hand, so I have left them be.
> If the GS_THREADSAFE define is made during building, then the
> functions that don't take an explicit memory handle are #defined
> away to nothing.
> If the GS_THREADSAFE define is made, we disable the gsapi check that
> checks for a single init.
> gs/base/gdebug.h
> gs/base/gdevabuf.c
> gs/base/gdevbbox.c
> gs/base/gdevdbit.c
> gs/base/gdevdevn.c
> gs/base/gdevdevn.h
> gs/base/gdevdflt.c
> gs/base/gdevdrop.c
> gs/base/gdevfax.c
> gs/base/gdevhl7x.c
> gs/base/gdevifno.c
> gs/base/gdevijs.c
> gs/base/gdevjpx.c
> gs/base/gdevm1.c
> gs/base/gdevm24.c
> gs/base/gdevmr1.c
> gs/base/gdevmr8n.c
> gs/base/gdevnfwd.c
> gs/base/gdevp14.c
> gs/base/gdevpbm.c
> gs/base/gdevpdf.c
> gs/base/gdevpdfu.c
> gs/base/gdevperm.c
> gs/base/gdevplan.c
> gs/base/gdevplib.c
> gs/base/gdevprn.c
> gs/base/gdevpsd.c
> gs/base/gdevpsds.c
> gs/base/gdevpsf2.c
> gs/base/gdevpsft.c
> gs/base/gdevpsfx.c
> gs/base/gdevpx.c
> gs/base/gdevrinkj.c
> gs/base/gdevsppr.c
> gs/base/gdevsvg.c
> gs/base/gdevsvga.c
> gs/base/gdevtrac.c
> gs/base/gdevtsep.c
> gs/base/gdevx.c
> gs/base/gdevxcf.c
> gs/base/gdevxcmp.c
> gs/base/gp_unifs.c
> gs/base/gp_unix.c
> gs/base/gsalloc.c
> gs/base/gsalphac.c
> gs/base/gscdevn.c
> gs/base/gschar0.c
> gs/base/gscie.c
> gs/base/gsciemap.c
> gs/base/gscoord.c
> gs/base/gscsepr.c
> gs/base/gscspace.c
> gs/base/gsequivc.c
> gs/base/gserrors.h
> gs/base/gsfcmap1.c
> gs/base/gsfont.c
> gs/base/gshsb.c
> gs/base/gsht.c
> gs/base/gsht1.c
> gs/base/gshtscr.c
> gs/base/gsicc.c
> gs/base/gsicc_cache.c
> gs/base/gsicc_manage.c
> gs/base/gsicc_profilecache.c
> gs/base/gsimage.c
> gs/base/gslib.c
> gs/base/gslibctx.c
> gs/base/gsmalloc.c
> gs/base/gsmchunk.c
> gs/base/gsmemory.c
> gs/base/gsmisc.c
> gs/base/gsovrc.c
> gs/base/gspath.c
> gs/base/gspath1.c
> gs/base/gsptype1.c
> gs/base/gsrefct.h
> gs/base/gsstate.c
> gs/base/gsstruct.h
> gs/base/gstrans.c
> gs/base/gstype1.c
> gs/base/gstype2.c
> gs/base/gstype42.c
> gs/base/gxacpath.c
> gs/base/gxalloc.h
> gs/base/gxblend.c
> gs/base/gxblend1.c
> gs/base/gxccache.c
> gs/base/gxccman.c
> gs/base/gxchar.c
> gs/base/gxclbits.c
> gs/base/gxcldev.h
> gs/base/gxclimag.c
> gs/base/gxclip.c
> gs/base/gxclip2.c
> gs/base/gxclipm.c
> gs/base/gxclist.c
> gs/base/gxclmem.c
> gs/base/gxclpath.c
> gs/base/gxclrast.c
> gs/base/gxclread.c
> gs/base/gxclrect.c
> gs/base/gxclthrd.c
> gs/base/gxclutil.c
> gs/base/gxcmap.c
> gs/base/gxcpath.c
> gs/base/gxdcconv.c
> gs/base/gxdevndi.c
> gs/base/gxdtfill.h
> gs/base/gxfapiu.c
> gs/base/gxfill.c
> gs/base/gxfillsl.h
> gs/base/gxfilltr.h
> gs/base/gxht.c
> gs/base/gxi12bit.c
> gs/base/gxicolor.c
> gs/base/gxidata.c
> gs/base/gxifast.c
> gs/base/gximag3x.c
> gs/base/gximage.c
> gs/base/gximage3.c
> gs/base/gximono.c
> gs/base/gxipixel.c
> gs/base/gxiscale.c
> gs/base/gxmclip.c
> gs/base/gxp1fill.c
> gs/base/gxpath.c
> gs/base/gxpath.h
> gs/base/gxpcmap.c
> gs/base/gxpflat.c
> gs/base/gxstroke.c
> gs/base/gxtype1.c
> gs/base/lib.mak
> gs/base/sbwbs.c
> gs/base/scfd.c
> gs/base/scfe.c
> gs/base/sdctd.c
> gs/base/sdcte.c
> gs/base/sfilter2.c
> gs/base/sfxfd.c
> gs/base/sfxstdio.c
> gs/base/shc.h
> gs/base/shcgen.c
> gs/base/sidscale.c
> gs/base/siscale.c
> gs/base/sjbig2.c
> gs/base/sjbig2_luratech.c
> gs/base/sjpx_luratech.c
> gs/base/slzwd.c
> gs/base/slzwe.c
> gs/base/std.h
> gs/base/stream.c
> gs/contrib/pcl3/eprn/eprnparm.c
> gs/contrib/pcl3/eprn/eprnrend.c
> gs/contrib/pcl3/eprn/gdeveprn.c
> gs/contrib/pcl3/src/gdevpcl3.c
> gs/cups/gdevcups.c
> gs/psi/fapiufst.c
> gs/psi/ialloc.c
> gs/psi/iapi.c
> gs/psi/idebug.c
> gs/psi/idict.c
> gs/psi/idisp.c
> gs/psi/idstack.c
> gs/psi/igc.c
> gs/psi/igcref.c
> gs/psi/igcstr.c
> gs/psi/igcstr.h
> gs/psi/ilocate.c
> gs/psi/imain.c
> gs/psi/imainarg.c
> gs/psi/iname.c
> gs/psi/interp.c
> gs/psi/ireclaim.c
> gs/psi/isave.c
> gs/psi/iscan.c
> gs/psi/zcie.c
> gs/psi/zcolor.c
> gs/psi/zcontext.c
> gs/psi/zdscpars.c
> gs/psi/zfapi.c
> gs/psi/zfcid0.c
> gs/psi/zfile.c
> gs/psi/zfjbig2.c
> gs/psi/zfjpx.c
> gs/psi/zicc.c
> gs/psi/zpcolor.c
> gs/psi/zvmem.c
> pcl/pccid.c
> pcl/pccid.h
> pcl/pccsbase.c
> pcl/pcfont.c
> pcl/pcfsel.c
> pcl/pcindxed.c
> pcl/pcmacros.c
> pcl/pcpage.c
> pcl/pcparse.c
> pcl/pcpatrn.c
> pcl/pcsfont.c
> pcl/pcsymbol.c
> pcl/pctext.c
> pcl/pctop.c
> pcl/pgconfig.c
> pcl/pgdraw.c
> pcl/pginit.c
> pcl/pglabel.c
> pcl/pgmisc.c
> pcl/pgparse.c
> pcl/pgvector.c
> pl/pjparse.c
> pl/plchar.c
> pl/plfont.c
> pl/pllfont.c
> pl/plmain.c
> pl/plsrgb.c
> pl/plsymbol.c
> pl/plsymbol.h
> pl/pluchar.c
> pl/plulfont.c
> pxl/pxffont.c
> pxl/pxfont.c
> pxl/pxgstate.c
> pxl/pximage.c
> pxl/pxink.c
> pxl/pxparse.c
> pxl/pxpthr.c
> pxl/pxsessio.c
> svg/svgshapes.c
> svg/svgtop.c
> xps/ghostxps.h
> xps/xpsanalyze.c
> xps/xpscff.c
> xps/xpsdoc.c
> xps/xpsglyphs.c
> xps/xpsgradient.c
> xps/xpsimage.c
> xps/xpspage.c
> xps/xpspath.c
> xps/xpsresource.c
> xps/xpstop.c
> xps/xpsttf.c
> xps/xpsxml.c
> xps/xpszip.c

2012-09-18 05:06:55 -0700
Robin Watts <robin@peeves.(none)>
1fa1eca3be2955e1ed1f8433c18d06417ea85f4c

> Perl script to drive apitest.
> Runs over a given set of devices/set of test files. Run apitest on each
> checking that output/stdout/stderr etc are the same for all threads.
> gs/toolbin/apitest.pl

2012-09-09 07:58:30 -0700
Robin Watts <robin.watts@artifex.com>
4c74f2aa1128c39a2f75a6626f6a59d4f854dc94

> Simple apitest program.
> Requires pthreads. Build with "make apitest" within gs.
> Invoke with a ghostscript like command line: e.g.
> bin/apitest -sDEVICE=pdfwrite -o outfile.%d. examples/tiger.eps
> The command line must have a -o in it, because it rewrites the
> "outfile.%d." to be "outfile.%d.THREADNUM" where THREADNUM is 0 to 9
> (change NUM_THREADS in psi/apitest.c to change this).
> stdout and stderr are redirected to each stdout.THREADNUM and
> stderr.THREADNUM respectively.
> gs/base/ugcclib.mak
> gs/base/unix-end.mak
> gs/base/unixlink.mak
> gs/psi/apitest.c
> gs/psi/iapi.c
> gs/psi/int.mak

2012-09-18 09:54:01 +0100
Ken Sharp <ken.sharp@artifex.com>
88077be834a9034282355e76bac1e76b66778483

> Add a newline to the end of the file because Visual Studio won't correctly
> compile it otherwise.
> gs/base/gscms.h

2012-09-17 22:47:51 -0700
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
8d274958209aed769e9804d0704c199b8f5cb4af

> Added 'relaxtimeout' option to clusterpush.pl (and to the documentation).
> gs/toolbin/localcluster/clusterpush.pl
> gs/toolbin/localcluster/clusterpush.txt

2012-08-12 04:32:52 -0700
Michael Vrhel <michael.vrhel@artifex.com>
82c3d60735ef1a7e702db6833c1c709edeaca1d4

> Initial work towards adding in support for use of DeviceN ICC color profiles as the output profile.
> gs/base/gdevpdfk.c
> gs/base/gscms.h
> gs/base/gsdparam.c
> gs/base/gsequivc.c
> gs/base/gsicc_manage.c
> gs/base/gsicc_manage.h

2012-09-17 08:53:10 +0100
Ken Sharp <ken.sharp@artifex.com>
928e28bc3521f479eb997eddfd8cffcb7a042cea

> pdfwrite - improve Outline handling when processing a subset of pages from PDF input
> The Outline pdfmarks could get confused if a leaf node was elided due to its
> Viwe or Dest page lying outside the range of pages processed from a PDF file.
> This could lead to nesting going wrong and trying to create more than 32 levels
> of nodes.
> This commit moves the checking of the Dest and View pages from the PDF interpreter
> into pdfwrite, which means pdfwrite now needs to pick up the FirstPage and
> LastPage switches. If a destination page lies outside the processed range we
> need to preserve it (so that the tree works out properly), but we don't write
> the View or Dest property, so that we don't point to non-existent pages.
> No differences epxected this is not cluster tested.
> gs/Resource/Init/pdf_main.ps
> gs/base/gdevpdfb.h
> gs/base/gdevpdfm.c
> gs/base/gdevpdfp.c
> gs/base/gdevpdfx.h

2012-09-14 23:09:51 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
486dd619f9a705e4f9871974a5f0833964c1f32a

> Bug 688288: Finish transparency structure cleanup
> Finish the cleanup started by rev. 0025b68a2df. Remove implementation
> of zdiscardtransparencygroup and zdiscardtransparencymask operators from
> the code base and their invocation from PDF interpreter.
> gs/Resource/Init/pdf_draw.ps
> gs/Resource/Init/pdf_main.ps
> gs/psi/ztrans.c

2012-09-14 11:11:46 +0100
Ken Sharp <ken.sharp@artifex.com>
4808e18412d21da480ed7a7628015941fc596a08

> pdfwrite - track form depth when creating forms with BP pdfmark
> Bug #693327
> In order to properly set the co-ordinate space for patterns inside forms
> we need to know the form's default co-ordinate space. To do this we keep
> a record of the nested form depth. However this wasn't being updated when
> we created a new form with the /BP pdfmark.
> This commit fixes that.
> gs/base/gdevpdfm.c

2012-09-14 09:59:22 +0100
Ken Sharp <ken.sharp@artifex.com>
dfcfd64d31e6e6c5e07dfcb793e0c781e180afd0

> pdfwrite, ps2write, txtwrite - add support for RTL DL
> Commit 062c0b5847519633e4349cf3a1f0830e529c4842 implements the HPGL/RTL
> Download Character (DL) operation. This commit adds support for the new
> font type defined as part of that update.
> Text using the DL font should now be preserved as text using a type 3 font
> in pdfwrite or ps2write, permitting search and copy operations, and should
> be extracted properly by the txtwrite device.
> No differences expected
> gs/base/gdevpdtd.c
> gs/base/gdevpdte.c
> gs/base/gdevpdtf.c
> gs/base/gdevpdti.c
> gs/base/gdevpdts.c
> gs/base/gdevpdtt.c
> gs/base/gdevpdtw.c
> gs/base/gdevtxtw.c

2012-09-12 10:34:22 -0700
Michael Vrhel <michael.vrhel@artifex.com>
0025b68a2df2f7c68cdcf4ebe0b3b9901c6a3698

> Clean up of some of the transparency structures
> The graphic state had vestiges of someones attempt to put the transparency
> stack into the graphic state. This is confusing for those looking at the code.
> This clean up is suggested in Bug 688288.
> gs/base/gdevp14.c
> gs/base/gdevpdfb.h
> gs/base/gdevpdfg.c
> gs/base/gdevpdft.c
> gs/base/gdevpdfx.h
> gs/base/gsistate.c
> gs/base/gsstate.c
> gs/base/gstparam.h
> gs/base/gstrans.c
> gs/base/gstrans.h
> gs/base/gxdevcli.h
> gs/base/gxistate.h
> gs/base/gzstate.h
> gs/psi/ztrans.c

2012-09-13 15:58:33 +0100
Ken Sharp <ken.sharp@artifex.com>
bfae0b91bbe273318284a01d67b746b365827bb6

> ps2write - correct %%BoundingBox comment
> The upper right y co-ordinate of the bounding box was being incorrectly
> set. Also added the %%HiResBoundingBox comment. Although this is not a
> DSC 3 standard comment it is widely used.
> No diffrences expected.
> gs/base/gdevpdfu.c

2012-09-13 14:53:15 +0100
Ken Sharp <ken.sharp@artifex.com>
44d00dd1bd34e2fb735d4682b73d880e208f92bd

> pdfwrite - improve subset font prefix generation
> We generate the prefix for a subset font by creating a hash from the
> usage pattern of glyphs in a font. If the font was already subset, and
> 'compact' (ie glyphs are used in order from 1 to n), then it was possible
> to generate the same prefix for two differetn subsets of the same font.
> In fact this is always possible, but here we add a heuristic which uses
> the MD5 hash we create for stream objects as an additional hash when
> generating the subset prefix. This does not guarantee that name collisions
> won't occur but should reduce the incidence still further.
> No differences expected.
> gs/base/gdevpdtb.c
> gs/base/gdevpdtb.h
> gs/base/gdevpdtd.c
> gs/base/gdevpdtd.h
> gs/base/gdevpdtf.c

2012-09-13 14:48:25 +0100
Ken Sharp <ken.sharp@artifex.com>
e8cfe956fe45fa949d22b10e2af665506e49fde4

> pdfwrite - linearisation, cater for unused objects
> If we had an object which wasn't used on any page then we would try to add
> it to the page or shared hints, which we obviously shouldn't, and which could
> potentially cause a seg fault.
> With this change we simply don't add such objects to the hints.
> gs/base/gdevpdf.c

2012-09-13 08:31:24 +0100
Ken Sharp <ken.sharp@artifex.com>
23d410c021a2b038ac5535e9eb028d6a808801ea

> pdfwrite - squash compiler warnings
> a couple of compiler warnings on debug print messages.
> gs/base/gdevpdf.c

2012-09-12 16:27:04 +0100
Ken Sharp <ken.sharp@artifex.com>
8e1ab0bc7410ec278f489a2e0c469a23b7aa17e9

> pdfwrite - fix ridiculous typo in last commit....
> gs/base/gdevpdf.c

2012-09-12 16:17:41 +0100
Ken Sharp <ken.sharp@artifex.com>
119717599c8ab62b037f61b8f042a1eeae39b2f4

> pdfwrite - linearisation fix stupid mistake causing infinte loop
> gs/base/gdevpdf.c

2012-09-12 12:54:54 +0100
Ken Sharp <ken.sharp@artifex.com>
a010600d3d99b16251fbfa5fede57d4583978632

> pdfwrite - fix another compiler warning
> This warning didn't show up previously, I have no idea why.
> gs/base/gdevpdf.c

2012-09-12 10:08:27 +0100
Ken Sharp <ken.sharp@artifex.com>
aa335a8a51261060aab8726fd300161d3b6f4334

> pdfwrite - linearisation, tidy up compiler warnings
> also remove an accidentally commited change which led to us writing
> invalid xref tables.
> gs/base/gdevpdf.c

2012-09-06 11:33:42 -0700
Michael Vrhel <michael.vrhel@artifex.com>
fc538635d876a99e7cfc32b4c525126093fea67a

> Add in option of -dPreBandThreshold=true/false to specify thresholding prior to clist
> When halftoning, it may be advantageous from a memory storage to halftone an image pre-clist.
> This adds code to check if the halftoned image at device resolution is smaller than the source
> image. It it is, then the image will by default be rendered before going into the clist.
> This option is turned off through the use of the device parameter -dPreBandThreshold=false
> gs/base/gscms.h
> gs/base/gsdparam.c
> gs/base/gsequivc.c
> gs/base/gsicc_manage.c
> gs/base/gxclimag.c
> gs/base/lib.mak

2012-09-11 12:51:05 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
8c77c16ad0f4e2bd107f6fa1a024c412e889a0ba

> Convert BitsPerComponent to an integer when we get a float.
> gs/Resource/Init/pdf_draw.ps

2012-09-11 09:53:46 -0600
Henry Stiles <henry.stiles@artifex.com>
062c0b5847519633e4349cf3a1f0830e529c4842

> HPGL/RTL DL (Download Character) implementation.
> gs/base/gxftype.h
> pcl/pgchar.c
> pcl/pgfdata.c
> pcl/pgfdata.h
> pcl/pgfont.c
> pcl/pgfont.h
> pcl/pglabel.c
> pcl/pgmand.h
> pcl/pgstate.h

2012-09-07 13:13:30 -0600
Henry Stiles <henry.stiles@artifex.com>
423501bbe9be110622edf4ef001edbd289136ee0

> A silly typo in an accessor function.
> Fortunately, this function is mainly used only for debugging purposes.
> pcl/pccid.c

2012-09-12 14:39:10 +0100
Ken Sharp <ken.sharp@artifex.com>
1245d1ad8e4400b6689132d32ee174041eaa60e4

> pdfwrite - sanitise linearisation file accesses to be 64-bit
> Change all the fteel/fseel calls to use gp_***_64 so that we don't trip
> over a maximum 4Gb.
> gs/base/gdevpdf.c

2012-09-10 16:14:15 -0700
Michael Vrhel <michael.vrhel@artifex.com>
5a1438b9f9d27be7e423300f563833a9d0d03ee4

> Fix for an indeterminism in the fast thresholding code
> A byte of nonsense data was getting included with the image data to which we were thresholding
> in very special resolution cases.
> gs/base/gxicolor.c
> gs/base/gximono.c

2012-09-10 21:48:00 +0100
unknown <ken@.(none)>
3904374b1a567ecbad3d496fc0cdac354225224a

> pdfwrite - linearisation, memory cleanup
> Free all the memory used in the course of producing a linearised PDF file.
> No differences expected, not tested by cluster
> gs/base/gdevpdf.c

2012-09-09 18:43:52 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
3a56f4eb5a9f15795725374b297edab0fb8ebc5d

> Bug 693045: Correctly restore PS stack when PDF stream run aborts.
> gs/Resource/Init/pdf_draw.ps

2012-09-09 11:33:53 -0700
Tor Andersson <tor.andersson@artifex.com>
7de89cff326888d9129b0ae6e4d003fd538b8321

> Merge 'gs/jbig2dec/' from jbig2dec.git using git-subtree
> git-subtree-dir: gs/jbig2dec
> git-subtree-mainline: faac14fb1532533a811649cef2b68cf95ec50fdf
> git-subtree-split: 7a82fc0abd135e08875ec4941ba43e832bc1b7f3
> gs/jbig2dec/.cvsignore
> gs/jbig2dec/.gitignore

2012-08-29 16:19:55 +0100
Chris Liddell <chris.liddell@artifex.com>
7a82fc0abd135e08875ec4941ba43e832bc1b7f3

> Remove dependence on jbig2dec auto-generated files
> Also provide a workaround for LCMS2 on systems without sqrtf().
> No cluster differences
> os_types.h

2012-08-24 15:19:29 +0100
Chris Liddell <chris.liddell@artifex.com>
3a424b8fa0e30b76b49b9c2f2fe167e5dc653073

> Update the libpng check to a non-deprecated API call.
> configure.ac

2012-08-23 15:09:41 +0100
Robin Watts <robin.watts@artifex.com>
07abb8a54e2d910e3b5a73341b7912948e0d0b61

> Bug 693298; Memento tweak for memset compile problem.
> Don't define memset if someone has already #defined it. Thanks to
> William Bader.
> memento.c

2012-08-23 15:03:03 +0100
Robin Watts <robin.watts@artifex.com>
5e5cff776abeb065e2c4ef5092256486fc3a2d35

> Revert "Move memento include from jbig2.h to jbig2_priv.h"
> This reverts commit 91744cfb2fe5d8b5b66d31077b4b22c6b3c905a2.
> This broke the memento build of gs due to the #defining of
> free/realloc. For now, we'll have to live with the include
> in the public header.
> jbig2.h
> jbig2_priv.h

2012-08-23 13:34:43 +0100
Robin Watts <robin.watts@artifex.com>
91744cfb2fe5d8b5b66d31077b4b22c6b3c905a2

> Move memento include from jbig2.h to jbig2_priv.h
> There is no need to expose memento outside of jbig2. Thanks to
> zeniko for the discussion in bug 693284 that lead to this.
> jbig2.h
> jbig2_priv.h

2012-08-13 17:03:22 +0100
Chris Liddell <chris.liddell@artifex.com>
13cc9dc158f12c3f446579655e942e44ac158634

> Update copyright headers.
> config_win32.h
> jbig2.c
> jbig2.h
> jbig2_arith.c
> jbig2_arith.h
> jbig2_arith_iaid.c
> jbig2_arith_iaid.h
> jbig2_arith_int.c
> jbig2_arith_int.h
> jbig2_generic.c
> jbig2_generic.h
> jbig2_halftone.c
> jbig2_halftone.h
> jbig2_huffman.c
> jbig2_huffman.h
> jbig2_hufftab.h
> jbig2_image.c
> jbig2_image.h
> jbig2_image_pbm.c
> jbig2_image_png.c
> jbig2_metadata.c
> jbig2_metadata.h
> jbig2_mmr.c
> jbig2_mmr.h
> jbig2_page.c
> jbig2_priv.h
> jbig2_refinement.c
> jbig2_segment.c
> jbig2_symbol_dict.c
> jbig2_symbol_dict.h
> jbig2_text.c
> jbig2_text.h
> jbig2dec.c
> memcmp.c
> memento.c
> memento.h
> os_types.h
> pbm2png.c

2012-08-06 17:13:39 +0200
Sebastian Rasmussen <sebras@gmail.com>
48fd721f3fb53b3fd10456e508b06d808ee9e647

> Bug 693256: Free GR_/GB_stats......
> ....as long as retaining them is yet to be implemented
> jbig2_symbol_dict.c

2012-08-06 15:24:43 +0100
Chris Liddell <chris.liddell@artifex.com>
28cc0cf46dc9455545631e54070edc2a8adc15e0

> Remove files for unsupported build tools.
> Jamfile
> SConstruct

2012-06-08 15:51:43 +0100
Robin Watts <Robin.Watts@artifex.com>
536620333aa7b752506626dce651ede08e2cdbc9

> Enable Memento to be used with jbig2dec
> ./configure or ./autogen.sh as usual, then
> "make XCFLAGS=-DMEMENTO".
> This involves duplicating memento within jbig2dec. We disable the GS
> specific build hacks, and add just one more; if GSBUILD is defined
> then jbig2 uses the version of memento from base, rather than the version
> of memento from inside jbig2. This avoids any potential problems with
> version skew.
> Makefile.am
> jbig2.h
> memento.c
> memento.h

2012-07-03 22:52:19 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
e37802e46e06e7c3d9f01d626b244771bcad76a1

> Bug 693050 : Fix compiler warnings
> jbig2_halftone.c

2012-07-02 22:49:17 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
1b311c624ce08c9c702ba4e88e2b0d787830334d

> Bug 693050 : Fix valgrind error in 0CF9 folder
> jbig2_refinement.c

2012-07-02 21:53:20 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
50d99ce72e1722427415ac745445dc1ca7e67c83

> Bug 693050 : Fix error handling in 0717 folder
> jbig2_halftone.c
> jbig2_mmr.c

2012-06-23 23:57:19 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
576c7d4162890ecee3b7322fd5665a8ae3c2d6d7

> Bug 693050 : Fix error handling in dcbd folder
> jbig2_page.c

2012-06-23 23:00:47 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
7feea483a0354e13c42ffa239b9b0c2d00f08428

> Bug 693050 : Fix error handling in 9557 folder
> jbig2_symbol_dict.c

2012-06-23 22:14:43 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
6f9608495e1f4b1fcac518378a44e8704d943dd7

> Bug 693050 : Fix memory leak in 4faa folder
> jbig2_symbol_dict.c

2012-06-23 21:12:19 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
9df6dfdae0f2ffba6f1335a8a6c5e2a2274e0d84

> Bug 693050 : Fix error handling in 2908 folder
> jbig2_halftone.c

2012-06-22 22:25:44 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
8033c8336691c0b833cde32d47f4bbf8d7f4d4f2

> Bug 693050 : Fix memory leak in 146f folder
> jbig2_mmr.c
> jbig2_symbol_dict.c

2012-06-22 16:56:39 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
a8ca8ed551e2897c422d0b6d46f1bd8ce30311b9

> Bug 693050 : Fix minor typos and memory leak in 040d folder
> jbig2_arith.c
> jbig2_image.c
> jbig2_symbol_dict.c
> jbig2_text.c

2012-06-20 18:18:02 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
76c000e507efff47e6f625bddef0a93323a7cc9d

> Bug 690723 : Prevent over writing unallocated memory when parsing an image
> jbig2_mmr.c

2012-06-15 19:22:52 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
9cf138eae6a1ac6554ecc3414224fecb0ba2ec2b

> Bug 693050 : Fixes CERT reported issues labelled DestAv
> jbig2.c
> jbig2_priv.h
> jbig2_symbol_dict.c
> jbig2_symbol_dict.h

2012-06-14 17:06:16 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
1c933c8c1d2beb7b6c6747c29fec58c6d6b8a02c

> Bug 693050 : Fixes CERT reported issues labelled SourceAvNearNull
> jbig2_image.c
> jbig2_symbol_dict.c
> jbig2_text.c

2012-06-06 17:16:53 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
3eff8ef1daf4de5232cb432fd685f6befdac1906

> Bug 693050 : Fixes CERT reported issue labelled HeapError
> jbig2.c
> jbig2_image.c
> jbig2_metadata.c
> jbig2_priv.h
> jbig2_symbol_dict.c
> jbig2_text.c

2012-06-05 16:39:39 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
08bc90379a7bd5d8eead94ae872f6fc6cc93a6fb

> Bug 693025 : Correct memory leaks reported by Zeniko
> jbig2_symbol_dict.c

2012-05-31 17:51:51 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
017f11f142bdea0965f453d64a31ef02b3271cba

> Bug 693025: Correct typos reported by Zeniko
> jbig2_huffman.c
> jbig2_symbol_dict.c

2012-05-30 17:42:29 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
90f453a7ea397418ed33966e6b94650efd99284f

> Bug 693050 : Fixes CERT reported issue labelled DestAvNearNull
> jbig2_image.c
> jbig2_page.c
> jbig2_symbol_dict.c
> jbig2_text.c

2012-05-27 23:35:06 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
26565665591e250cfbda9bc6d8834f8a2922d206

> Bug 693050 : Fixes CERT reported issue labelled BranchAvNearNull
> jbig2_symbol_dict.c

2012-05-27 22:47:02 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
bb27f271e4b508d63ca4f572b733e36977f0cbc4

> Bug 693050 : Fixes CERT reported issue labelled BlockMoveAv
> jbig2_symbol_dict.c

2012-05-27 21:43:27 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
dbf31907db5654184b9e7bca5d700f72deccc9fa

> Bug 693050 : Fixes CERT reported issue labelled SegFaultOnPc
> jbig2_generic.c
> jbig2_image.c

2012-05-14 18:08:00 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
4886f1c69e712a730399da308bfb1b731a652cbb

> Bug 693025: Updated patch from Zeniko to fix various crashes and leaks
> jbig2_halftone.c
> jbig2_huffman.c
> jbig2_image.c
> jbig2_refinement.c
> jbig2_segment.c
> jbig2_symbol_dict.c
> jbig2_text.c

2012-02-09 00:00:31 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
a27094d1833bf10c9ab3b612182aa23f4eb3044f

> Bug 690974: This patch from Gorac implements the generic refinement region decoding procedure for when TPGRON is TRUE.
> jbig2_refinement.c

2012-02-08 23:13:13 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
a43f448139d0a72688c9191adab0718b9ef43ec5

> Bug 690870: This patch prevents the image compositing occurring if the src is outside of the clip region.
> jbig2_image.c

2012-01-25 19:21:08 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
33e85ea71051ad64ca4bb8b874dcf8bed9b66e62

> Bug 691254: This patch prevents the seg fault in Jbig2_042_14.pdf.
> jbig2_symbol_dict.c
> jbig2_text.c

2012-01-24 13:20:11 +0000
Robin Watts <robin.watts@artifex.com>
1d120cab65c74fe97e4e4512f6a034f0fba0cac5

> Tweak jbig2dec to cope better with NULLs.
> Fix various destructors in jbig2dec to cope with being called
> with image = NULL. This cures a problem in mupdf where it SEGVs
> when called on "1239 - skip invalid content streams.pdf" from the
> sumatra test set.
> jbig2_image.c

2012-01-13 10:40:50 -0700
Henry Stiles <henry.stiles@artifex.com>
b1bfe4ae823054ac2dc94af15246fa489304cf80

> Bug 691230, basic jbig2 halftone image support.
> Thanks to George Gottleuber for this work.
> jbig2_halftone.c
> jbig2_halftone.h
> jbig2_mmr.c
> jbig2_mmr.h
> jbig2_segment.c

2012-01-10 22:24:35 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
a42adfaa785b05670af63f8767c3ff55636c6686

> Bug 691267: Check all realloc error paths.
> jbig2.c
> jbig2_huffman.c
> jbig2_page.c
> jbig2_symbol_dict.c
> jbig2_text.c

2011-11-29 20:33:16 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
1fddee262691d23dc283965c0dbe0e0de2c85bf9

> Bug 691267: jbig2dec needs to check malloc() return values
> This fix checks all return paths to ensure that the appropriate error
> is returned on failure from any malloc() call within jbig2dec.
> jbig2.c
> jbig2_arith.c
> jbig2_arith_iaid.c
> jbig2_arith_int.c
> jbig2_generic.c
> jbig2_halftone.c
> jbig2_huffman.c
> jbig2_image.c
> jbig2_metadata.c
> jbig2_page.c
> jbig2_refinement.c
> jbig2_segment.c
> jbig2_symbol_dict.c
> jbig2_text.c

2011-11-20 10:29:47 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
f680c2d09d76172f7adee998608a8df0b8d2828c

> Fix 691958: check for an image before marking a page complete. Also update return code to handle errors correctly.
> jbig2_page.c

2011-06-01 16:22:40 +0100
Robin Watts <Robin.Watts@artifex.com>
609901fe1d5496caeae2289ee20d7be965e413b0

> Tweak jbig2dec os_types.h for android mupdf build.
> If HAVE_STDINT_H is defined we are supposed to be getting our definitions
> from stdint.h. Instead the header defines them anyway. Fix this. This showed
> up when building MuPDF for Android.
> os_types.h

2011-05-11 15:39:06 -0600
Henry Stiles <henry.stiles@artifex.com>
6e49f7e6d0c680ad0962cf7c620d67aa943c48a7

> Fixes bug #689870 - add proper big endian number accessors.
> Previously only an unsigned accessor was provided and it was being
> used to read both signed and unsigned quantities.
> jbig2.c
> jbig2_halftone.c
> jbig2_page.c
> jbig2_priv.h
> jbig2_segment.c
> jbig2_symbol_dict.c
> jbig2_text.c

2011-05-11 15:18:11 -0600
Henry Stiles <henry.stiles@artifex.com>
ae98887d657761ac4d15881da559bb9ae24f26e7

> Fixes 690889, potential null dereference.
> Prevent a theoretical (no test file) null dereference. There are
> several of these cases identified by by static analysis. We believe
> the authors intent was to pass the word stream if the arithmetic state
> was not set, as in the other call of the same function.
> jbig2_symbol_dict.c

2010-08-11 16:17:45 +0000
Henry Stiles <henry.stiles@artifex.com>
ea866acb21033fd3cfe345352852ea1202ce2e32

> Fix bug # 691532. Do not attempt to clone an image that does not exist, each completed page should have an associated image. We'd like to handle this corrupt file with a better fix, for example the absence of an end page segement is clearly a problem with respect to the specification, but Adobe and Artifex have chosen to support other "off spec" streams so more subtle and less obvious error checking is needed. Thanks to Tim Waugh for analysis on this problem.
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@11622 a1074d23-0009-0410-80fe-cf8c14f379e6
> jbig2_page.c

2010-07-30 11:03:27 +0000
Till Kamppeter <till.kamppeter@gmail.com>
ca94f2ac3ab6cdbb6a36a72cae385afb4f25d4e8

> On Tru64 the integer types are in inttypes.h and not in stdint.h as in VMS
> Bug 691463, required for jbig2dec.
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@11563 a1074d23-0009-0410-80fe-cf8c14f379e6
> os_types.h

2010-07-20 09:46:34 +0000
masaki <masaki@a1074d23-0009-0410-80fe-cf8c14f379e6>
c29b63557cb191f2b9371a06a73a11bc4b8f5544

> Add support for user defined huffman table.
> This code adds support for segment type 53 segments, which supplies
> inline huffman code table. Bug 689853.
> Many thanks to Justin Greer.
> git-svn-id: svn+ssh://svn.ghostscript.com/svn/ghostscript/trunk/gs/jbig2dec@11526 a1074d23-0009-0410-80fe-cf8c14f379e6
> (cherry picked from commit e51f8e400e4502d7a6d60ee31890a195f55d1b64)
> Signed-off-by: Masaki Ushizaka <masaki@ghostscript.com>
> jbig2_huffman.c
> jbig2_huffman.h
> jbig2_segment.c
> jbig2_symbol_dict.c
> jbig2_text.c

2010-07-20 08:01:29 +0000
Masaki Ushizaka <masaki@ghostscript.com>
d26c7e4f39f76fe70cc61d6dc14d05a042a9be48

> Fix jbig2_image_set_pixel function prototype
> The declaration of jbig2_image_set_pixel was differenct between
> jbig2_image.h and jbig2_image.c (int value vs bool value). And
> prevented compiling it by MSVC comiler in C++ mode.
> This patch fixes it. Bug #691461.
> jbig2_image.h
> jbig2_image_pbm.c
> jbig2dec.c

2010-07-16 09:13:41 +0000
Masaki Ushizaka <masaki@ghostscript.com>
c5d61c78c0de785b74b86d4e5298e3cc7b9e2b68

> A little fix to allocating memory size
> jbig2_huffman.c

2010-07-15 00:49:09 +0200
Tor Andersson <tor.andersson@gmail.com>
e12fa07da845515911db8be2f7cfa8ef551061ba

> Use the jbig2_new and jbig2_renew macros instead of calling
> jbig2_alloc and jbig2_realloc directly. Also adds a few typecasts
> and #defines required to compile the source as C++.
> jbig2.c
> jbig2_arith.c
> jbig2_arith_iaid.c
> jbig2_generic.c
> jbig2_halftone.c
> jbig2_huffman.c
> jbig2_image.c
> jbig2_metadata.c
> jbig2_page.c
> jbig2_priv.h
> jbig2_refinement.c
> jbig2_segment.c
> jbig2_symbol_dict.c
> jbig2_text.c
> jbig2dec.c

2010-07-15 00:42:38 +0200
Tor Andersson <tor.andersson@gmail.com>
31dd7ef66dbd1c34df08365aa3c36e6391617f37

> Update VERSION define in config_win32.h
> config_win32.h

2010-07-15 00:41:46 +0200
Tor Andersson <tor.andersson@gmail.com>
941b73315a166fe07e0f1a1b81171477285280f7

> Add Makefile.unix -- a simple makefile for unix-like systems.
> Makefile.unix

2010-07-15 00:35:58 +0200
Tor Andersson <tor.andersson@gmail.com>
f6066822041bbffd7169fd4bfc19c48daae8f155

> Fix memory leak of the word stream struct.
> jbig2_text.c

2010-06-22 06:12:54 +0000
masaki <masaki@a1074d23-0009-0410-80fe-cf8c14f379e6>
ad707fba426702631466973e6e80c48d16398b88

> Fix for bug 689836 and 691248.
> Bug 689836 - Huffman tables with only positive values are decoded incorrectly
> Bug 691248 - jbig2dec doesn't handle 042_11 (Huffman Symbol Region)
> This patch fixes mulfunctions seen on standard huffman table K, L, M and N.
> A difference will be seen on tests_private/comparefiles/Bug690360.pdf.
> This file was affected by table K mulfunction and this is a improvement.
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk/gs/jbig2dec/@11415 a1074d23-0009-0410-80fe-cf8c14f379e6
> (cherry picked from commit d59bf48fcaefb0cb531d90cb748c173198a10f54)
> Signed-off-by: Masaki Ushizaka <masaki@ghostscript.com>
> jbig2_hufftab.h

2010-06-22 05:59:23 +0000
masaki <masaki@a1074d23-0009-0410-80fe-cf8c14f379e6>
606ce11fc930769a5bdf920a5902c158be8b3d5f

> Added test code for every line of each standard huffman tables.
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk/gs/jbig2dec/@11413 a1074d23-0009-0410-80fe-cf8c14f379e6
> (cherry picked from commit aae02dab94f439a69744f4686c81d5633c8816a6)
> Signed-off-by: Masaki Ushizaka <masaki@ghostscript.com>
> jbig2_huffman.c

2010-05-15 06:27:41 +0000
hintak <hintak@a1074d23-0009-0410-80fe-cf8c14f379e6>
a54c8df662d4ab88afef6fcaa6c324030224d77d

> try to make 'make -f base/unix-gcc.mak so' work
> When not run through ./configure, HAVE_CONFIG_H isn't defined and
> the jbig2 codes drop through to generic unknown unix platform - so we put some
> generic unix values here.
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk/gs/jbig2dec/@11254 a1074d23-0009-0410-80fe-cf8c14f379e6
> (cherry picked from commit 27d16d20f97555d2874d9f04b374053ccd0731b7)
> Signed-off-by: Masaki Ushizaka <masaki@ghostscript.com>
> os_types.h

2010-05-14 04:18:42 +0000
hintak <hintak@a1074d23-0009-0410-80fe-cf8c14f379e6>
6ef4989dcc7b51c9e8565258aa2a8a63e43d6b35

> uint8_t type located in usual header on HP-UX needed for jbig2dec ; bug 688184
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk/gs/jbig2dec/@11238 a1074d23-0009-0410-80fe-cf8c14f379e6
> (cherry picked from commit 15d65a1fded828b25ca20886cd3ca8bb7522a96f)
> Signed-off-by: Masaki Ushizaka <masaki@ghostscript.com>
> os_types.h

2010-04-21 07:20:14 +0000
masaki <masaki@a1074d23-0009-0410-80fe-cf8c14f379e6>
f51764fe4b4b31733ac1dc5c3d103106b9594c8d

> A fix for a regression introduced by r11074 (bug 690094).
> As I changed image number to be incremented when 'exflag' is false,
> the problem of 'exrunlength' when SDHUFF == 1 was unveiled.
> This fixes it.
> JBIG2 images with SDHUFF == 1 should have been having trouble
> between r11074 and this revision. No other difference expected.
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk/gs/jbig2dec/@11093 a1074d23-0009-0410-80fe-cf8c14f379e6
> (cherry picked from commit 44b9be2b31622c91b8cb3e4acc6160269630d838)
> Signed-off-by: Masaki Ushizaka <masaki@ghostscript.com>
> jbig2_symbol_dict.c

2010-04-15 09:53:33 +0000
masaki <masaki@a1074d23-0009-0410-80fe-cf8c14f379e6>
342ea4778d0ab98d8aabbaf62c2866afb804359d

> A fix for 690094, "missing letters replaced by little vertical lines".
> This problem was in jbig2dec function jbig2_decode_symbol_dict().
> The image number was not incremented correctly when it built
> symbol dictionary.
> No difference expected, other than JBIG2 pdf files suffered by
> this problem.
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk/gs/jbig2dec/@11074 a1074d23-0009-0410-80fe-cf8c14f379e6
> (cherry picked from commit 75a5fa486571d0a9696976c290960f1bfdc7191b)
> Signed-off-by: Masaki Ushizaka <masaki@ghostscript.com>
> jbig2_symbol_dict.c

2010-04-14 02:31:58 +0000
masaki <masaki@a1074d23-0009-0410-80fe-cf8c14f379e6>
eb629c8ff915730ff737ca6e4d564cc88ddafb22

> Fixed jbig2dec command getopt() parameter for -v option.
> Not used by ghostscript itself but worth for standalone debugging.
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk/gs/jbig2dec/@11067 a1074d23-0009-0410-80fe-cf8c14f379e6
> (cherry picked from commit c72d87c7d7b32f0d33d5e5b9e72aca701dd80e01)
> Signed-off-by: Masaki Ushizaka <masaki@ghostscript.com>
> jbig2dec.c

2010-04-14 02:26:16 +0000
masaki <masaki@a1074d23-0009-0410-80fe-cf8c14f379e6>
b1ddf3c7a00c9f216f9a0bbd1285376c1e121dec

> Fixed an indent. No influence on code.
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk/gs/jbig2dec/@11066 a1074d23-0009-0410-80fe-cf8c14f379e6
> (cherry picked from commit a6717367dee7a863788d74522e5ace5b548d80e1)
> Signed-off-by: Masaki Ushizaka <masaki@ghostscript.com>
> jbig2_symbol_dict.c

2010-04-13 09:50:08 +0000
masaki <masaki@a1074d23-0009-0410-80fe-cf8c14f379e6>
f901b18ac90d291b98a1463e92f8d26c6f320c3e

> A fix for 691081, 691206, and part of 690094.
> From r9769, jbig2dec wasn't capable of decoding some JBIG2 files
> and throwing a error "jbig2dec FATAL ERROR runlength too large in
> export symbol table (XXX > XX - XX) (segment 0xXX)".
> This was caused by accidentaly bound checking export symbol table
> size with number of non-export symbol. This fixes it.
> No differences expected, other than JBIG2 files suffered from this
> problem.
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk/gs/jbig2dec/@11057 a1074d23-0009-0410-80fe-cf8c14f379e6
> (cherry picked from commit e2c24fec806a2a84427ecfff9a9bbd078ca460bd)
> Signed-off-by: Masaki Ushizaka <masaki@ghostscript.com>
> jbig2_symbol_dict.c

2010-02-02 11:09:54 -0800
Ralph Giles <giles@ghostscript.com>
58b513e3ec60feac13ea429c4aff12ea8a8de91d

> Bump versioning for the 0.11 release.
> The libtool shared library versioning starts with this release.
> CHANGES
> configure.ac
> jbig2dec-0.11/CHANGES
> jbig2dec.1

2010-02-02 11:03:37 -0800
Ralph Giles <giles@ghostscript.com>
fa1bd62f45b780d5c8cbadaf66a25b03688590c5

> The inclusion of JBIG2 in PDF 1.4 is no longer new news.
> README

2010-02-02 11:03:05 -0800
Ralph Giles <giles@ghostscript.com>
da42a22f05eb8af12a797c12bee3e5c121fe2842

> Correct a whitespace formatting issue in the usage text.
> jbig2dec.c

2010-02-02 11:01:42 -0800
Ralph Giles <giles@ghostscript.com>
dd0c94f5c32a01ff8b7d502071495ba475fe8f8a

> Fix a manpage grammar error.
> jbig2dec.1

2010-02-02 11:01:10 -0800
Ralph Giles <giles@ghostscript.com>
373b4606ef4b573e855b6be78fabd2496112da3b

> Update change log for the 0.11 release.
> CHANGES
> jbig2dec-0.11/CHANGES

2009-11-23 16:49:06 -0800
Ralph Giles <giles@cirrus.local>
a841c2481b35b7bf1bf5970a11ac750ff3a3ee2c

> Implement generic region decode with typical prediction.
> Patch from Gorac. Ghostscript bugs 690791 and 690913.
> jbig2_generic.c

2009-11-20 09:46:39 -0800
Ralph Giles <giles@ghostscript.com>
ad742b847dbb39b1376664d77fae0f8b31ae65f0

> Skip generic regions using TPGDON and issue a warning.
> We don't yet implement this, and discarding the data is better than
> proceeding with the incorrect decoding proceedures, which generally
> just produce noise. Ghostscript bug 690791.
> jbig2_generic.c

2009-11-16 11:17:51 -0800
Ralph Giles <giles@ghostscript.com>
fd7cb7fa6152573ab11ebfbce45582fa1652f117

> Correct bitmap offsets when setting transposed text.
> Previously, the code was switching width and height, not just S and T
> coordinates. We now properly decode the 042_19.jb2 test file.
> Thanks to Drugo Pedrouvene for pointing out the issue. Bug 690923.
> jbig2_text.c

2009-10-29 22:00:35 -0700
Ralph Giles <giles@ghostscript.com>
dcf0bd8c4288ff30d152b3741bc78c9fa055e49c

> Make -v print only info-level messages by default.
> Previously -v set the verbosity level to 9. Anything 3 or greater
> prints all debug messages, which can be quite overwhelming when
> individual decode elements are traced. Now the default with -v is 2.
> Run jbig2dec --verbose=3 to recover the old behaviour.
> jbig2dec.1
> jbig2dec.c

2009-10-29 21:59:47 -0700
Ralph Giles <giles@ghostscript.com>
c1fddcf71a0cd81c02f7b52b757ea20c05f4292a

> Improve grammar in the usage message.
> jbig2dec.c

2009-10-29 21:49:49 -0700
Ralph Giles <giles@ghostscript.com>
cf7917e8948a9296cd6bfdb0a1615287b88b769f

> Fix comment formatting.
> jbig2dec.c

2009-10-29 21:19:54 -0700
Ralph Giles <giles@ghostscript.com>
7018021f8232f62ff9c6822092405dd0467abb09

> Update the COPYING file to the text of the GPLv3.
> The jbig2dec package is still licensed GPLv2 or later, but we want
> to encourage use under the GPLv3.
> COPYING

2009-10-29 16:52:50 -0700
Ralph Giles <giles@ghostscript.com>
f8e18fdeb01cdbd9530804077beed6cac38ef077

> Have the scons build automatically determine the version string.
> SConstruct tries to call 'git describe --tags' which produces a version
> string based on the most recent tag, with the number of commits and
> current commit hash appended if HEAD isn't a tagged revision.
> If that command fails (i.e. building from a release tarball or another
> version control system) it attempts to read the CHANGES file and uses
> the first version number there.
> SConstruct

2009-10-29 16:29:04 -0700
Ralph Giles <giles@ghostscript.com>
f34a521eba46e811287fb4f35519fc32f0b6d4e8

> Update the version number in the scons build description.
> SConstruct

2009-10-29 16:04:42 -0700
Ralph Giles <giles@ghostscript.com>
077b6518dffc75dc74fc5e6990c8529f44cb47a0

> Remove the include of ~/.jamrules.
> This was part of Tor's original commit, and was intended to set some
> common default options among projects. However, it generates a warning
> when the file is not available, and we now set thing like optimization
> level and warning flags directly.
> Jamfile

2009-10-29 15:59:57 -0700
Ralph Giles <giles@ghostscript.com>
bba07df1f607891f15bec1f1ace673f23d8360e2

> The jam build no longer requires a config.h.
> Instead it sets the needed defines itself.
> Jamfile

2009-10-28 13:45:00 -0700
Ralph Giles <giles@ghostscript.com>
fe50e6202700ad508c7f91e04330a962970ead5f

> Remove _parse_ from the segment decode routines.
> Our use wasn't consistent here; some decoders were jbig2_foo() and
> others were jbig2_parse_bar(). Prefer the shorter names and keep
> _parse_ only for the header and dispatch routines which don't themselves
> decode the segment bodies.
> jbig2_metadata.c
> jbig2_metadata.h
> jbig2_page.c
> jbig2_priv.h
> jbig2_segment.c
> jbig2_text.c

2009-10-28 12:22:40 -0700
Ralph Giles <giles@ghostscript.com>
d2849e9e31de7cb3a921f9c69a9a4ecfd06feb02

> Remove an unused variable.
> jbig2_halftone.c

2009-10-28 12:19:57 -0700
Ralph Giles <giles@ghostscript.com>
b108cbcfc9a2c7d10e70bd2bdc3a3a938ea3adb7

> Add prototypes for the publicly referenced halftone functions.
> Corrects a missing prototype warning.
> jbig2_priv.h

2009-10-28 12:07:19 -0700
Ralph Giles <giles@ghostscript.com>
47bd82353ae27eb2c53e7253c39b70ef2e147ab2

> Build optimized with debugging symbols and all warnings under jam.
> Previously we used the default rules which are just 'cc'. This aligns
> the behaviour with the other builds and lets of take advantage of jam's
> cleaner output to see warnings more easily.
> Jamfile

2009-07-24 16:33:01 -0700
Ralph Giles <giles@ghostscript.com>
20e5cd8ca494d3e715bcc38701cfd5923225415d

> Fix a typo in a debug statement.
> jbig2_image.c

2009-07-16 01:52:01 -0700
Ralph Giles <giles@ghostscript.com>
b76f84cbe3982b71357c727c208401d6645ecad3

> Clone and release the page images returned to the client.
> jbig2_page.c

2009-07-16 01:32:29 -0700
Ralph Giles <giles@ghostscript.com>
70a3ad1514050d5babcc18fb1bd327db1cfbfdc8

> Remove a specious comment.
> Originally I thought we might need to access pages in random order,
> but I don't think this is necessary.
> jbig2_page.c

2009-07-16 01:56:34 -0700
Ralph Giles <giles@ghostscript.com>
56d7948b4d9f3825a20f0cb6cc26a0a3b6ae34f1

> Check more return codes from jbig2_image_new().
> There are still a number of unchecked instances in jbig2_symbol_dict.
> jbig2_generic.c
> jbig2_halftone.c
> jbig2_page.c
> jbig2_refinement.c
> jbig2_text.c

2009-07-15 22:28:42 -0700
Ralph Giles <giles@snow.ghostscript.com>
19dabb532ae37749fdb6c06447e2dfcf0e216e9b

> Check for NULL before freeing metadata or symbol segment results.
> This protects against segfault during early termination.
> jbig2_segment.c

2009-07-15 22:28:03 -0700
Ralph Giles <giles@ghostscript.com>
2e9e3314b4264e547ce9372b4bcd2f20c50b5357

> Document that jbig2_data_in() can return -1 on fatal errors.
> jbig2.c

2009-07-15 22:11:21 -0700
Ralph Giles <giles@ghostscript.com>
f96255c8451e2d07406e2bd5f513f1d0aec34f29

> Check the return code from jbig2_data_in().
> This avoids printing multiple 'Not a JBIG2 file header' errors on
> corrupt or invalid files.
> jbig2dec.c

2009-06-17 13:01:40 -0700
Ralph Giles <giles@ghostscript.com>
1fde432da43cbe5bc34f3a95ee5d2f2466090e52

> Add the jbig2dec manpage to the automake install and dist targets.
> Makefile.am

2009-06-17 12:29:38 -0700
Ralph Giles <giles@ghostscript.com>
ff59dbf7c7302a1a55768e0cdcbcdd4661b0b77c

> Manpage updates.
> List the file.jbig2 and the embedded global+page stream pair
> invocations separately, since they are exclusive.
> Give a more complete description and elaborate on some of the options.
> Use dot-macros instead of backslash commands for most of the formatting.
> This isn't any less confusing because of the need to use double quotes
> to enforce whitespace when alternating styles, but I still find it
> more reasonable.
> Fix a couple of spelling errors.
> jbig2dec.1

2009-06-17 12:26:10 -0700
Ralph Giles <giles@ghostscript.com>
e11f98fa775d99a531f18f5f4bffc754a205ce8f

> Add a manpage for the jbig2dec example client.
> Contributed by Sebastian Rassmussen.
> jbig2dec.1

2009-06-12 17:16:00 -0700
Ralph Giles <giles@ghostscript.com>
e20020b1bd4fae157236fc9716cafa17481e3171

> Build a shared library with GNU libtool.
> Previously we used autoconf and automake, but just build a static
> library. This commit checks for libtoolize in autogen.sh and adds
> support for libtool to the configure.an and Makefile.am scripts.
> We use this to build both static and dynamic versions of the jbig2dec
> library, including soname versioning for the later.
> Based on a patch by Sebastian Rasmussen.
> Makefile.am
> autogen.sh
> configure.ac

2009-05-29 07:25:13 -0700
Ralph Giles <giles@ghostscript.com>
5ae432288a105122d92f490d2d9cf212dae8aab4

> Initialize the pattern dict data offset to zero before first use.
> Warning flagged by Coverity.
> jbig2_halftone.c

2009-05-28 23:20:21 -0700
Ralph Giles <giles@ghostscript.com>
37e002db7ffce8121bd060c86fd9f0609879e99b

> Bump version after the 0.10 release.
> CHANGES
> configure.ac

2009-05-28 21:49:29 -0700
Ralph Giles <giles@ghostscript.com>
0d287050828a5878bb61e6971220d25674bae77e

> Set release date and package version for the 0.10 release.
> CHANGES
> configure.ac

2009-05-28 21:11:06 -0700
Ralph Giles <giles@ghostscript.com>
29d7c56e2aea052d51f33820a3f68f4e4a636c08

> Add some missing files to the automake build for distribution.
> Makefile.am

2009-05-28 20:39:36 -0700
Ralph Giles <giles@ghostscript.com>
95e63680521ba68e3c21ca1e2bf9fee3a2c1958d

> Update changes with major points since the last release.
> CHANGES

2009-04-01 15:52:17 -0700
Ralph Giles <giles@ghostscript.com>
4e62b3968d0d897bb9a24ba7f75504f476e33ba6

> Bounds check exported symbol run-lengths. CVE-2009-0196.
> The final symbol dictionary is built from a combination of symbols
> from referenced dictionaries and new symbols coded in the current
> segment. Because the symbols can be composed and refined, not all
> coded symbols are necessarily exported.
> The list of symbols to export from those constructed by the decoding
> process is coded as a series of on/off run-lengths. Previously we
> accepted the value read as the run-length, even though this could
> result in writing off the end of the exported symbol array. This
> commit checks the read value against the number of elements remaining
> in the export array and throws a fatal error if there is an overflow.
> Thanks for Alin Rad Pop of Secunia Research for pointing out the issue.
> jbig2_symbol_dict.c

2009-05-22 23:21:48 +0200
Ralph Giles <giles@ghostscript.com>
86e0b052dc32de4e0f9a3cbc7dbf27211a2b3182

> Fix the jam build to work without config.h.
> Previously, the Jamfile assumed a config.h had be created, usually by
> running the configure script, but possibly also created manually. This
> is extra work for those wanting a quick build. Therefore we pass some
> defines on the compiler command line instead.
> These are also likely to be wrong: we assume libpng is available on
> all non-windows platforms. It's an incremental improvement, however,
> and actual build-time configuration based on detected resources is
> difficult in Jam.
> Jamfile

2009-05-22 23:14:33 +0200
Ralph Giles <giles@ghostscript.com>
8e6b447d8bddabc0acd5834fa493110b1bb3e9c7

> Provide fallbacks in jbig2dec.c if PACKAGE and VERSION aren't defined.
> Normally, the configure script defines PACKAGE and VERSION, based on
> its initializers. However, config.h is in fact optional, so we shouldn't
> assume these are set. Since we use these to implement the command
> 'jbig2dec --version', we provide fallbacks in the source file to
> simplify compiling outside the autotools build.
> jbig2dec.c

2009-04-16 00:08:49 -0700
Ralph Giles <giles@ghostscript.com>
3c7c73d634dda170455d3cd7a1ef08a038e63cbb

> Add a missing include in the halftone code.
> jbig2_decode_pattern_dict() calls jbig2_decode_generic_mmr() but
> wasn't including jbig2_mmr.h which declares that function.
> Fixes a compiler warning on gcc and clang.
> jbig2_halftone.c

2009-04-15 19:26:39 -0700
Ralph Giles <giles@ghostscript.com>
d1a03359b9f267714f60662dc021eef4054ae202

> Check the return value of sscanf when parsing pbm dimensions.
> This is a follow-on to the previous commit. It shouldn't be
> possible to reach the sscanf with less than one digit in the
> parse buffer, but we abort anyway in case sscanf can't find
> anything. If the code could proceed from that point with an
> uninitialized value in the dim array the call to jbig2_image_new()
> could request excessive resources.
> jbig2_image_pbm.c

2009-04-15 18:41:10 -0700
Ralph Giles <giles@ghostscript.com>
83c67854e5e0fd06045bd5e8fc53f98e1ddb9b76

> Move an eof check out of a while loop where it was never called.
> This section was flagged by coverity. Not because the eof check was
> never executed, but because of casting away the possible EOF return
> value of fgetc() inside the while condition. The isdigit() call would
> still terminate the while on eof, and the worst that would happen
> is that the allocated image would be smaller than intended and the
> eof would be caught after trying to read the data, so this was not
> a serious issue.
> This commit removes the meaningless eof check inside the digit-copying
> while loop and adds a specific check before. It also avoids copying the
> first non-digit character to the parse buffer, which should resolve the
> coverity warning.
> jbig2_image_pbm.c

2009-04-01 17:40:01 -0700
Ralph Giles <giles@ghostscript.com>
9b525fc5d325e559dae1f9fb7d3956b8407df3d5

> Ask git to ignore normal build products.
> .gitignore

2009-04-01 17:38:47 -0700
Ralph Giles <giles@ghostscript.com>
da580ddc6398b1818fc20036b79a89a7856b0296

> Correct a typo in a debug message.
> jbig2_image.c

2009-04-01 17:38:19 -0700
Ralph Giles <giles@ghostscript.com>
c0c36828c7ded70a82bb65affd3cf10ef7ddc5ea

> Remove a debug printout.
> This was added in f1d00697, but isn't necessary beyond the initial
> testing prior to that commit.
> jbig2_huffman.c

2009-03-31 21:35:17 -0700
Ralph Giles <giles@ghostscript.com>
76b6b9ec30859f32293286b3837f17a8252d010c

> Close the output pbm file after writing to it.
> Resource leak reported by Coverity.
> jbig2_image_pbm.c

2009-03-31 21:32:38 -0700
Ralph Giles <giles@ghostscript.com>
ceb71749c865a4a4cd4c5a6ed0b052dff533a76c

> Rename a local variable to avoid shadowing a function argument.
> The code was correct, but confusing. Resolves a Coverity warning.
> jbig2_text.c

2009-03-31 21:29:09 -0700
Ralph Giles <giles@ghostscript.com>
fdefccb83e29b399d3c3935ed2ada533fb57bdd0

> Remove unnecessary header includes.
> jbig2.c

2009-03-31 21:24:16 -0700
Ralph Giles <giles@ghostscript.com>
261eb20b93e2fa36f34748be10232160955719cd

> Remove an unnecessary header include.
> jbig2_refinement.c

2009-03-30 18:35:21 -0700
Ralph Giles <giles@ghostscript.com>
f1d00697525dd2d7a5f63f96e01ad0d99e673b13

> Restore the proper size of the huffman symbol length histogram.
> The previous size as 256 KB, but LENCOUNT's highest index is PREFLEN
> (or LENMAX - 1, but LENMAX is the largest value of PREFLEN) and that
> comes from a byte member of a Jbig2HuffmanEntry. Therefore 256 members
> are all that is necessary, or 1 KB on most machines.
> This was changed in commit a0531af8 (jbig2dec svn c430) apparently in
> the mistaken belief that it needed to scale with the size of the table
> itself. In that revision the previous stack allocation of 256 elements
> was replaced with the 1k, which later became 64k, generally overflowing
> the stack. While 256 elements is a reasonable stack allocation, it's
> safer to continue using the heap.
> jbig2_huffman.c

2009-03-30 18:17:55 -0700
Ralph Giles <giles@ghostscript.com>
63e0436a711c59f7fae6cfd721b90428ae19a7b3

> Dynamically allocate and initialize the huffman symbol length histogram.
> Previously we allocated it on the stack, but it's quite large (256K)
> and we were assuming it was initialized to zero. Issue flagged by
> Coverity.
> jbig2_huffman.c

2009-03-30 18:00:39 -0700
Ralph Giles <giles@ghostscript.com>
45f462f813cfef6be8f6755ebe02e8744222b3b1

> Initialize Jbig2TextRegionParams.sbrat even when it is not used.
> This avoids valgrind warnings in a later debug message which
> unconditionally prints them out. After a patch by Alex Cherepanov,
> ghostscript svn commit 9578.
> jbig2_text.c

2009-03-30 17:45:50 -0700
Ralph Giles <giles@ghostscript.com>
e2e186837bedf8211405c14b75c54849241193cd

> Only define vnsprintf on MSVC versions prior to 9.
> Visual Studio 2008 defines vnsprintf() in its stdio.h and our mapping
> from _vnsprintf() conflicts. After a patch by Michael Vrhel, ghostscript
> svn commits 8734 and 8735.
> config_win32.h

2009-02-27 00:09:03 -0800
Ralph Giles <giles@ghostscript.com>
aaed7c2e751f82d585f9b4d94601b48bfd196b6f

> Protect refinement debug image dumps from the normal debug build.
> jbig2_refinement.c

2009-02-26 23:53:08 -0800
Ralph Giles <giles@ghostscript.com>
5f76927a09fc65adff87042eb0667ded96fef537

> Add the (unfinished) halftone source to the Jam build.
> Jamfile

2009-02-26 23:46:59 -0800
Ralph Giles <giles@ghostscript.com>
4d45e847d00a560fcd9a4ae917cda83a6dbf1686

> Update the contact address in the file headers.
> config_win32.h
> jbig2.c
> jbig2.h
> jbig2_arith.c
> jbig2_arith.h
> jbig2_arith_iaid.c
> jbig2_arith_iaid.h
> jbig2_arith_int.c
> jbig2_arith_int.h
> jbig2_generic.c
> jbig2_generic.h
> jbig2_halftone.c
> jbig2_huffman.c
> jbig2_huffman.h
> jbig2_hufftab.h
> jbig2_image.c
> jbig2_image.h
> jbig2_image_pbm.c
> jbig2_image_png.c
> jbig2_metadata.c
> jbig2_metadata.h
> jbig2_mmr.c
> jbig2_mmr.h
> jbig2_page.c
> jbig2_priv.h
> jbig2_refinement.c
> jbig2_segment.c
> jbig2_symbol_dict.c
> jbig2_symbol_dict.h
> jbig2_text.c
> jbig2_text.h
> jbig2dec.c
> memcmp.c
> os_types.h
> pbm2png.c

2009-02-26 18:02:37 -0800
Ralph Giles <giles@ghostscript.com>
4d57cb4f565736e5a8473876dcd56464cd3aba70

> Regularize the headers and clean up some additional whitespace.
> jbig2.c
> jbig2_generic.c
> jbig2_mmr.c
> jbig2_priv.h
> jbig2_symbol_dict.c
> jbig2_symbol_dict.h

2009-02-24 18:29:48 -0800
Ralph Giles <giles@ghostscript.com>
75de8111f83acd49a2eb75bed348cb4fac9f1e97

> Remove trailing whitespace.
> autogen.sh
> jbig2.h
> jbig2_arith.h
> jbig2_arith_iaid.h
> jbig2_arith_int.h
> jbig2_generic.c
> jbig2_generic.h
> jbig2_huffman.h
> jbig2_image.h
> jbig2_image_pbm.c
> jbig2_image_png.c
> jbig2_metadata.h
> jbig2_mmr.h
> jbig2_symbol_dict.c
> jbig2_symbol_dict.h
> jbig2_text.c
> jbig2_text.h
> memcmp.c

2009-02-24 17:13:38 -0800
Ralph Giles <giles@rain.(none)>
4db6758c0acf306c07cea834e22414d2db42b56a

> Remove Id and other svn keyword substitution lines.
> These were sometimes helpful in backtracking from isolated source
> copies to a specific revision in a centralized version control
> system, but git has poor support for such things. They are also
> much less necessary now that public source repositories are a
> more common part of development workflows.
> Jamfile
> Makefile.am
> autogen.sh
> config_win32.h
> configure.ac
> jbig2.c
> jbig2.h
> jbig2_arith.c
> jbig2_arith.h
> jbig2_arith_iaid.c
> jbig2_arith_iaid.h
> jbig2_arith_int.c
> jbig2_arith_int.h
> jbig2_generic.c
> jbig2_generic.h
> jbig2_halftone.c
> jbig2_huffman.c
> jbig2_huffman.h
> jbig2_hufftab.h
> jbig2_image.c
> jbig2_image.h
> jbig2_image_pbm.c
> jbig2_image_png.c
> jbig2_metadata.c
> jbig2_metadata.h
> jbig2_mmr.c
> jbig2_mmr.h
> jbig2_page.c
> jbig2_priv.h
> jbig2_refinement.c
> jbig2_segment.c
> jbig2_symbol_dict.c
> jbig2_symbol_dict.h
> jbig2_text.c
> jbig2_text.h
> jbig2dec.c
> memcmp.c
> os_types.h
> pbm2png.c
> test_jbig2dec.py

2008-05-26 18:52:22 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
d5db893a4dfe988b1ecea14595f3c7605ee166ea

> Work around broken streams created by Xerox WorkCentre products, where
> the final segment length is written as -1. Ghostscript bug 689841.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@468 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_page.c

2008-05-17 00:08:26 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
2dea640032a72f9756cdccd54352c10b18348f56

> More whitespace cleanup.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@467 ded80894-8fb9-0310-811b-c03f3676ab4d
> config_win32.h
> jbig2_arith_iaid.c
> jbig2_halftone.c
> jbig2_huffman.c
> jbig2_hufftab.h
> jbig2_metadata.c
> jbig2_priv.h
> jbig2dec.c
> os_types.h
> pbm2png.c
> sha1.c

2008-05-16 23:58:59 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
f125f9553a1e3c8088cf59df7c983aef3785641a

> Only check for a code length antecedent under RUNCODE32. RUNCODE33 and
> RUNCODE34 specify a repeat of zero so a previous code length isn't
> necessary.
> Thanks to Justin Greer for catching this. Ghostscript bug 689835.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@466 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_text.c

2008-05-16 23:48:20 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
c744e7207254f6719eb011a3a0b4984fdfa369dd

> Clean up trailing whitespace.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@465 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2.c
> jbig2_arith.c
> jbig2_arith_int.c
> jbig2_generic.c
> jbig2_image.c
> jbig2_mmr.c
> jbig2_page.c
> jbig2_refinement.c
> jbig2_segment.c
> jbig2_symbol_dict.c
> jbig2_text.c

2008-05-09 13:54:32 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
e4e8acebad09764a3be793082de99bd1679ef0c0

> Runcodes 33 and 34 repeat a zero code length symbol id, not the previous
> symbol like runcode 32.
> Thanks to Justin Greer for the fix. Ghostscript bug 689824.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@464 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_text.c

2008-05-09 13:41:01 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
46555913d6ed4b5479b50f45564ed94c478af863

> Support for aggregate symbol coding, patch from Ghostscript trunk.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@463 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_refinement.c
> jbig2_symbol_dict.c
> jbig2_text.c
> jbig2_text.h

2008-05-09 13:38:29 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
e3092e1ff329e834e0e131ada149c692cff01688

> Windows build fixes. Patch from Ghostscript trunk.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@462 ded80894-8fb9-0310-811b-c03f3676ab4d
> config_win32.h
> msvc.mak
> os_types.h

2008-05-07 21:37:02 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
381e60a9cbb6b42136e67e4dd48e67cb438b5a2d

> Update copyright headers. Ownership has been transferred
> to Artifex.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@461 ded80894-8fb9-0310-811b-c03f3676ab4d
> config_win32.h
> jbig2.c
> jbig2.h
> jbig2_arith.c
> jbig2_arith.h
> jbig2_arith_iaid.c
> jbig2_arith_iaid.h
> jbig2_arith_int.c
> jbig2_arith_int.h
> jbig2_generic.c
> jbig2_generic.h
> jbig2_halftone.c
> jbig2_huffman.c
> jbig2_huffman.h
> jbig2_hufftab.h
> jbig2_image.c
> jbig2_image.h
> jbig2_image_pbm.c
> jbig2_image_png.c
> jbig2_metadata.c
> jbig2_metadata.h
> jbig2_mmr.c
> jbig2_mmr.h
> jbig2_page.c
> jbig2_priv.h
> jbig2_refinement.c
> jbig2_segment.c
> jbig2_symbol_dict.c
> jbig2_symbol_dict.h
> jbig2_text.c
> jbig2_text.h
> jbig2dec.c
> memcmp.c
> os_types.h
> pbm2png.c

2008-05-07 21:30:33 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
86131c28d05eb84cbd8878c2fc6d3a6282b79cbc

> Set eol-style on the source files.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@460 ded80894-8fb9-0310-811b-c03f3676ab4d
> config_win32.h
> jbig2_arith_iaid.c
> jbig2_arith_iaid.h
> jbig2_arith_int.c
> jbig2_arith_int.h
> jbig2_image_png.c
> jbig2_metadata.h
> jbig2_mmr.h
> pbm2png.c

2007-11-09 01:13:21 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
4446e2678f3bd9faa211a5d5bd50ac8f8c461a42

> Change the license from GPLv2 to GPLv2 or later.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@459 ded80894-8fb9-0310-811b-c03f3676ab4d
> LICENSE

2007-10-25 22:20:54 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
416c12b80383fe829edf8e986a0d5c860f8fabe6

> Set appropriate ignores.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@458 ded80894-8fb9-0310-811b-c03f3676ab4d

2007-10-25 22:13:42 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
e2a295a921ad73b46c69bc33c67d8717b94d9b4e

> Remove some gcc warnings.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@457 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_generic.c
> jbig2_image.h
> jbig2_page.c
> jbig2_refinement.c
> jbig2_symbol_dict.c
> jbig2_text.c

2007-10-25 22:13:23 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
639e20afb817afd493b3802643f3dcf363962fce

> Update autogen.sh to detect automake 1.10 and later.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@456 ded80894-8fb9-0310-811b-c03f3676ab4d
> autogen.sh

2007-10-25 21:57:25 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
6f92ef3754dff5fdf82a809662476c330b25e20c

> Add AM_PROG_CC_C_O as requested by automake 1.10.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@455 ded80894-8fb9-0310-811b-c03f3676ab4d
> configure.ac

2007-02-06 08:10:58 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
ad85e74393cfb2667ea1f15756502ea2bc3cf3d9

> Add a new header for declaring the public text region functions.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@454 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_text.h

2007-02-05 23:42:18 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
41b78a49bf9e00d0d78532581b7e72836935f3d5

> Export jbig2_decode_text_region() for use in aggregate symbol encoding
> and stub out the setup for the call. Work in progress implementing
> support for this function.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@453 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_refinement.c
> jbig2_symbol_dict.c
> jbig2_text.c

2007-02-05 22:59:10 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
4cec0516180e0a8a79e88de5fbb12a28b3f64439

> Rewrite the test script to use a custom test class.
> Previously we used the python unittest module, but we don't use most of
> its features, and it's quite weak for this kind of file-based external
> testing. So we lose on using a familiar api, but this doesn't add much
> code, and we can now add long-desired features like 'xfail' results.
> This grew out of work revising the Ghostscript test code for
> parallelization.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@452 ded80894-8fb9-0310-811b-c03f3676ab4d
> test_jbig2dec.py

2006-07-27 00:54:08 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
94071092c25507e1dd00451f89c0e82d45f65503

> Bump version number, post release.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@449 ded80894-8fb9-0310-811b-c03f3676ab4d
> CHANGES
> configure.ac

2006-07-26 23:57:39 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
9c04190c5824e209be28d5079787c3f05b5c1b3e

> Update version info for the 0.9 release.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@447 ded80894-8fb9-0310-811b-c03f3676ab4d
> CHANGES
> configure.ac

2006-05-15 21:16:42 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
3421407ecff3d48427a0a848f58a0d1affe2c44b

> Correct a typo resulting in inproper glyph placement with transposed text and a top left reference corner. Fixes bug 688645.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@446 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_text.c

2006-02-17 20:25:07 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
34abc7a906ef9716d01ec93d74036a0be53a742c

> Update my email address; artofcode.com no longer works.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@445 ded80894-8fb9-0310-811b-c03f3676ab4d
> sha1.c

2005-12-18 18:12:33 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
3753ca9c4e9543d34f6e20c5c55eef15fc6afcf8

> Correct an invalid return value. Thanks to Leonardo for pointing this
> out.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@444 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_text.c

2005-12-06 01:50:08 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
d94bdb63779c6d3bfa43197c791912cb954ae109

> Update changelog.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@443 ded80894-8fb9-0310-811b-c03f3676ab4d
> CHANGES

2005-12-06 01:47:35 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
a9d42d067a6cd01c9f1fd73b00ff9c69c6ba85c6

> The SBDSOFFSET field is a *signed* 5 bit integer, so we need to sign
> extend when reading the field to get the proper value. We now correctly
> handle the 042_20.jb2 test stream.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@442 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_text.c

2005-12-05 23:39:55 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
994516f6db541df5f57d3de4851313af6a260f68

> Add -DJBIG2_DEBUG to the default scons build.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@441 ded80894-8fb9-0310-811b-c03f3676ab4d
> SConstruct

2005-12-03 07:26:21 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
49d3aed4dd6a1adc1ab03702cf324103febae1e6

> Fix data for Huffman table B.12.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@440 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_hufftab.h

2005-12-03 03:35:00 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
49519f4cfa5ca7d4f06ab11261e86a0d5aa55c64

> Correct an operator precedence bug that was corrupting reading of uncompressed
> collective bitmaps. Also improve debugging messages.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@439 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_symbol_dict.c

2005-12-01 23:56:54 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
0d020e4fcfa9039853e76f0456e65805cff3d19d

> Promote artimetic debug printout code to JBIG2_DECODE_ARITH from
> plain JBIG2_DEBUG to cut down on noise.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@438 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_arith.c

2005-12-01 21:52:38 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
391a059aad7b801f004b01e17663a4024294d6ef

> Handle immediate lossless generic regions the same as immediate generic
> regions. Fixes bug 688397.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@437 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_segment.c

2005-09-01 04:13:36 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
b78900486172244c39187e89a085b12f2b6abdb1

> Some minor corrections and bug fixes.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@436 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_symbol_dict.c
> jbig2_text.c

2005-08-31 16:41:42 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
6a99885954277048b0d73840941dc47ede4c103a

> Make a Jbig2WordStream return zeros past the end of the defined
> buffer, as can happen when the huffman decoder tries to fill
> its 'next_word' lookahead near the end of a segment.
> Previously, we just relied on there being some data we could
> read (and then ignore) which usually worked, but caused a
> segfault with the 688080.pdf test file due to chance read
> buffer alignment.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@435 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2.c

2005-08-30 02:05:05 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
8acccc58c83123286b0954053a7dd899de5a0630

> Fix some small bugs and add additional error checking to the
> huffman decoding support.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@434 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_huffman.c
> jbig2_text.c

2005-08-28 00:10:20 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
e2ff5e373bd8ecda6db43c6b6414c8a3f3248297

> Comment clean-up.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@433 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_huffman.c
> jbig2_text.c

2005-08-25 08:14:21 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
d23b5e5b4d8fabdf51d202094ac4259d59dcc974

> Work-in-progress commit of huffman text region support. Fix a number
> of bugs in jbig2_huffman_get_bits() and implement symbol id huffman
> table decode (a custom table is always included inline in the text
> region segment header.)
> However, the constructed table gives an out-of-bounds symbol id on
> the first read with the UBC test file.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@432 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_huffman.c
> jbig2_text.c

2005-08-23 06:09:55 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
d2d97abc0be98770dc506620f5f8921900e55e5e

> Work-in-progress commit of huffman text region support. Initial implemetation of symbol id huffman
> table decode.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@431 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_text.c

2005-08-17 20:03:18 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
a0531af83d6d29abe2fccb488fa7b741d68cb3fd

> Hack around the lack of subtree support in jbig2_huffman_table_build()
> by allocating a bigger flat table. This should be fixed the correct
> way at some point, but lets us proceed with huffman text region
> decoding implementation in the meantime.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@430 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_huffman.c

2005-08-16 23:57:25 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
5bbd972edf6b6441248d4201cd61767fa521cc97

> Work-in-progress commit. Partial implementation of Huffman text region
> support.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@429 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_text.c

2005-08-16 21:41:38 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
d22a2ed8db5f8d99345b08762cabebcbc5873d64

> Copy out the collective bitmap symbols for huffman symbol dictionaries.
> Also, some additional debug print pruning.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@428 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_symbol_dict.c

2005-08-16 21:16:22 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
3c04507a4138266c8266cc01886ca70ae8a9fa93

> Implement reading an uncompressed collective symbol bitmap.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@427 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_symbol_dict.c

2005-08-16 20:38:03 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
338f0fbd294ee0dc9cbfabd7a15cce0ac657a708

> Remove huffman debugging printouts. Preserve the state dump functions
> for future use, but #ifdef protect them.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@426 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_huffman.c
> jbig2_huffman.h
> jbig2_symbol_dict.c

2005-08-16 20:20:08 +0000
ray <ray@ded80894-8fb9-0310-811b-c03f3676ab4d>
df910b6ffff7ae54db6c2d2430709ebb911eda49

> Fix for shift right 32 bits of unsigned int being treated as shift right 0.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@425 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_huffman.c

2005-08-04 07:05:05 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
720e508d03bae14bf0e412abb37ad08ecde72e46

> Work-in-progress commit of halftone dictionary implementation. This
> is enabled in the scons build, but not the standard one.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@423 ded80894-8fb9-0310-811b-c03f3676ab4d
> SConstruct
> jbig2_halftone.c
> jbig2_segment.c

2005-08-04 07:03:05 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
3fb9f08036565d4bd4147283e2e685217b6e4b55

> bstract the GB_stats size calculation into a function.
> Also some comment cleanup.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@422 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_arith.h
> jbig2_generic.c
> jbig2_generic.h
> jbig2_text.c

2005-07-28 00:59:59 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
45a5c57347f7b7569808933207bb03c8edf30315

> Warning cleanup. Implement an unoptimized version of the REPLACE image
> composition operator.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@421 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_image.c

2005-07-27 23:55:54 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
9d9c7e26944b07cda1c81242b66aea7bbdfc1150

> Some code cleanup. Remember the external combination op for region
> segments and use it. Also add the missing REPLACE operator to the
> enum (but not yet implemented in the compositor). Only some routines
> can use this one. Also add some missing prototypes.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@420 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_priv.h
> jbig2_refinement.c
> jbig2_segment.c
> jbig2_text.c

2005-07-27 23:49:03 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
dcb83f94c6dc0280a8edeb4dc303fc1451bcd881

> Fix an off-by-one in reading the SBDEFPIXEL and SBCOMBOP fields of
> the text region segment flags, which caused us to clear the region
> background to the wrong value. Bug 688244.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@419 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_text.c

2005-07-27 17:29:03 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
4a8c95e32a1a05dbf5587ff2262ea225f2dd6c2b

> Commit an off-by-one fix from Alex Cherepanov related to bug 688244.
> Also #ifdef protect a debug image dump that was preventing compilation
> in Ghostscript.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@418 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_symbol_dict.c

2005-07-27 08:29:56 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
0d128dbed01e775befd59050c415b5aa7f21562d

> Work in progress commit of huffman support. This version is still buggy and
> includes some serious debug spew.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@417 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_huffman.c
> jbig2_symbol_dict.c

2005-07-13 16:51:13 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
4cc11bea50d585804e93b985e7d7e8504990911b

> Work-in-progress check in of huffman symbol dictionary support.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@416 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_huffman.c
> jbig2_huffman.h
> jbig2_symbol_dict.c

2005-07-13 16:28:44 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
1b6a01e666d0dbcd355c0b84fba43c1d02fb4b37

> Move a repeated calculation out of a loop.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@415 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_image.c

2005-06-20 11:09:19 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
46ff1e6277a432b9e1d18784ab5c30fc40b45476

> Minor cleanup of unimplemented huffman sections.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@414 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_symbol_dict.c

2005-06-19 14:16:14 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
1eb7ae738d7af4508d7cbc547c0e386d55821820

> Properly initialize the decode result field of the segment header struct
> to NULL to avoid problems on free. Bug 688053.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@413 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_segment.c

2005-06-15 14:09:35 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
84de63772c46a85128b6ada79cd2203918c7dec2

> Fail on fatal symbol dict decoding errors.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@412 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_symbol_dict.c

2005-06-08 14:23:43 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
e5bdc75cc8afaf2630953f1784381cc6c9305e36

> Add support for striped page decode. We still return a full
> page buffer, so there is no savings in memory footprint.
> We now decode 042_9.jb2 from the UBC test streams.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@411 ded80894-8fb9-0310-811b-c03f3676ab4d
> CHANGES
> jbig2.h
> jbig2_generic.c
> jbig2_image.c
> jbig2_page.c
> jbig2_priv.h
> jbig2_refinement.c
> jbig2_segment.c

2005-06-08 14:23:23 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
d954b0f143afbf16da24b2ea0a54d88b39af4129

> Work in progress commit to support huffman text regions. Parse
> and intantiate the huffman tables for text region decoding.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@410 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_text.c

2005-06-08 14:20:45 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
b28d531ea50bf15cc80cb068192b47b57a8916ce

> Implement remaining standard huffman tables.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@409 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_huffman.h
> jbig2_hufftab.h

2005-06-08 14:19:35 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
2ff386d420a62438df630a8b0ba3a022469cd3f8

> Turn on -Wall when compiling with gcc.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@408 ded80894-8fb9-0310-811b-c03f3676ab4d
> configure.ac

2005-05-24 03:49:47 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
0a9dae0a3c665ce5c758f1575e0c8f08075aaf3c

> Update the arith and huffman tests to run with the new code. We now
> compile with -DTEST and link to the rest of the library since that's
> required to access the allocator. In theory, that means we have duplicate
> symbols, but GNU ld seems to cope. If it's a problem the test programs can
> be split into separate source files.
> Note that the arith test doesn't actually verify its results; it just
> prints the results when compiled with -DJBIG2_DEBUG.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@407 ded80894-8fb9-0310-811b-c03f3676ab4d
> Makefile.am
> jbig2_arith.c
> jbig2_huffman.c
> jbig2_symbol_dict.c

2005-05-18 00:42:24 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
d78f4fbaac91f43bd14ac7d54c60e8edb0fa5bfe

> Attempt to hook the self tests into the scons build. This is supposed
> to work with the development version, but does not.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@406 ded80894-8fb9-0310-811b-c03f3676ab4d
> SConstruct

2005-05-11 07:14:25 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
cc3a563ea709064bf47147bd817a962e368a5c2a

> Export the pre-defined huffman tables for external use.
> Read the huffman fields of the symbol dictionary header and allocate
> appropriate tables and decoder context. This is a prerequisite for
> handling huffman-coded symbol dicts.i
> Part of the fix for bug 688009.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@405 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_huffman.c
> jbig2_huffman.h
> jbig2_hufftab.h
> jbig2_symbol_dict.c

2005-05-03 02:27:12 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
34b95add346fa8b27064e007da4e86eadc466bbd

> Allocate a huffman decoder for symbol dictionaries that require it.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@404 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_symbol_dict.c

2005-05-03 02:25:08 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
67a0de3abce1a5ea08260cf937754ecfadbe7b41

> Update the huffman decoder interface.
> Move hufftab.h with the static table definitions to only be included once
> from huffman.c.
> Use the client-replaceable jbig2_alloc() instead of bare malloc().
> Add a 'free' call for the huffman state. This just calls jbig2_free().
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@403 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_huffman.c
> jbig2_huffman.h
> jbig2_hufftab.h

2005-05-03 01:10:27 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
1e2d6eade5dd4755e15db66e539256aa407b6d08

> Re enable the huffman and arithmetic coder unit tests.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@402 ded80894-8fb9-0310-811b-c03f3676ab4d
> Makefile.am

2005-05-02 20:49:28 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
7fa4382f2f5cac1f1471617a23c9d1affa994e18

> Alter our portability fallback implementation of memcmp() to properly return
> negative values is the first argument is "less than" the second. The previous
> one was fine for our purposes, but could cause problems if it was accidentally
> used by client applications.
> Thanks to Ray Johnston for pointing this out.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@401 ded80894-8fb9-0310-811b-c03f3676ab4d
> memcmp.c

2005-04-28 04:44:30 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
65885f2808d815a4ce41d4712c19dc1dac61b6ab

> Add the changelog to the distribution.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@400 ded80894-8fb9-0310-811b-c03f3676ab4d
> Makefile.am

2005-04-28 04:37:42 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
40379d7c353d1326615e08e64684fdc4065544ec

> Add experimental scons build file.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@399 ded80894-8fb9-0310-811b-c03f3676ab4d
> SConstruct

2005-04-28 04:36:32 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
0c358eca216ac6fb627a0d920c7fb9eb3f53d014

> Fix implicit cast warnings from MSVC. Bug 687988.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@398 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_symbol_dict.c

2005-04-28 04:35:55 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
26c310efdb8e8a914c36ffe7a4944448144adeef

> Bump the version number for new development work.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@397 ded80894-8fb9-0310-811b-c03f3676ab4d
> CHANGES
> configure.ac

2005-04-28 04:31:34 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
b67e1875a83632bc7e43e44d0a98ccc64c030b94

> Update version and changelog for the 0.8 release.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@395 ded80894-8fb9-0310-811b-c03f3676ab4d
> CHANGES
> configure.ac

2005-04-06 18:14:30 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
c49714a02996d398353fe76f51ef084dcaa99602

> Add an explicit cast to quiet a warning on MSVC. Bug 687988.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@393 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_symbol_dict.c

2005-04-06 00:29:36 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
2561fd5c9ed06af167a245e2a09732a68655c8fb

> Add a cast to in checking a range against an unsigned value.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@392 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_symbol_dict.c

2005-04-05 23:40:12 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
cf7b160a37331362d7bcff571e13e57d20193377

> Minor comment cleanup.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@391 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_image_pbm.c

2005-04-05 23:39:53 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
c5393dfc4025b41895565f5b2a2f1786bffdf980

> dd a missing break; in the segment release dispatch. Release of symbol
> dictionary segments was falling through and causing a double free of
> the result. Bug 688004.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@390 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_segment.c

2005-01-19 19:31:33 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
c04c341b8cfbd2ee7b58269147a41bf6c24d7b7e

> #ifdef out the cygwin stdint-from-sys/types fixup. Newer cygwin seems to provide
> them all, but still not define stdint.h. Bug 687873.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@389 ded80894-8fb9-0310-811b-c03f3676ab4d
> os_types.h

2005-01-04 07:05:39 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
fdc9d09b305474bffc749d23b51e025bba7fa567

> Correct some memory leaks in text region decoding: properly free arith
> and word stream state, and release refined glyph images after
> compositing.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@388 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_text.c

2005-01-04 07:04:17 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
3cf2d67fafefb607c8d436f2185d092457274cdb

> Correctly free the (dynamic) glyph array when freeing a symbol
> dictionary.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@387 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_symbol_dict.c

2005-01-04 05:17:39 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
ad0de34366fd42c8f95d519dccb91115c4278580

> Also correctly free the integer arith coding contexts in symbol
> dictionary decode.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@386 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_symbol_dict.c

2005-01-04 05:07:45 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
bff29a59cb009b2cb0b397c137e8576e9f3acb0b

> Properly free the arith and word stream states in symbol dictionary decoding.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@385 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_symbol_dict.c

2005-01-04 04:53:16 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
81b746740b074f5a0a8b539bc4954dad5c5797be

> Properly free some segment results when the segment header structures
> are freed. Symbol dictionaries are released, intermediate segment images
> are released if they haven't already been released and nulled after
> their use in the decode process, and metadata structures are properly
> freed.
> Resolves all known leaks with the first 7 ubc test streams.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@384 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2.c
> jbig2_refinement.c
> jbig2_segment.c

2005-01-04 04:41:56 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
304420e16947853c697c9f50eb9e7c3cdd64f80c

> Properly free tag and value strings from inside the metadata struct. We
> now assume we own those pointers, which is fine if jbig2_metadata_add()
> is used to construct them.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@383 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_metadata.c

2005-01-04 04:40:18 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
e641718f01a0a45ec8cfc89602daa345bb9383f8

> Minor cleanup: remove an unnecessary check before releasing an immediate
> text region after decode and composite, and simply reference to the page
> image itself.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@382 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_text.c

2005-01-04 00:53:10 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
e3a50c85fa43ebff2b3164e05cf3988c326cfb27

> Properly free arithmetic coding and word stream states after region
> decode. Also use the allocator defined in the library context instead
> of raw malloc for the arith state.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@381 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_arith.c
> jbig2_generic.c
> jbig2_refinement.c

2005-01-04 00:34:16 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
de271483ae5bf0ee87b73b44d9d433d4ca6a920a

> Properly free the decoded page image array on context free.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@380 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2.c

2005-01-04 00:32:36 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
f72323e48008adb89a21bf01770a9583f456ff36

> Simplify the ubc teststream hashes.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@379 ded80894-8fb9-0310-811b-c03f3676ab4d
> test_jbig2dec.py

2004-12-23 12:53:49 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
eb7f46063eb1b3e220c13839ef622c29bcf5834f

> Properly mask the last row byte in the shift == 0 compositor
> case. Fixes bug 687843.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@374 ded80894-8fb9-0310-811b-c03f3676ab4d
> CHANGES
> jbig2_image.c

2004-12-23 12:07:53 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
99672eb6ce4dad97c3ff22f9768b0073f730331e

> update changelog.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@373 ded80894-8fb9-0310-811b-c03f3676ab4d
> CHANGES

2004-12-23 11:54:43 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
6f0b0d1802ad565e908adac9601e650bdfb8af94

> Implement a slow general fallback for image compositing. This adds
> support for non-OR composition operators.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@372 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_image.c

2004-12-22 09:34:29 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
7d9a6439364da7ea94311d69f877ae37485fd1f7

> Clarify variable references to better match the spec.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@371 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_text.c

2004-12-22 01:36:38 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
b62aa9dd9154eba7122c56cab886207dce972cb1

> Trivial whitespace fix.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@370 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_page.c

2004-12-21 22:59:04 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
afe3a66d19d98cf0017f4c7b433ae65b2286e259

> replace individual memset calls for clearing images with a new
> jbig2_image_clear() utility function.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@369 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2.h
> jbig2_image.c
> jbig2_page.c
> jbig2_text.c

2004-12-21 01:05:59 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
d264e8daa8c30ea3d4d43e287bcc97462f244e9e

> Initialize the initial text region segment bitmap to zero.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@368 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_text.c

2004-12-21 00:35:02 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
50493055b3f099f6670df3ab2011af8085ba49c5

> Re-assign the return value of jbig2_realloc() when growning the page
> size array. Previously it was dropped which could cause crashes on some
> systems processing documents with more than 4 pages. Thanks to Jan
> Patera for reporting this.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@367 ded80894-8fb9-0310-811b-c03f3676ab4d
> CHANGES
> jbig2_page.c

2004-12-13 20:00:09 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
28e7ac27b12c59c271eacca8eb70dc97fe991c5b

> Fix and error return. The normal 'return jbig2_error(ctx, JBIG2_SEVERITY_FATAL,...)'
> idiom doesn't work when the function returns a pointer instead of an error code.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@366 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_symbol_dict.c

2004-12-08 22:49:47 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
a065bcb4b13998d875073212087b2a84aa132cc7

> Bump version number post-release, and correct a CHANGES typo.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@365 ded80894-8fb9-0310-811b-c03f3676ab4d
> CHANGES
> configure.ac

2004-12-08 21:00:32 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
afc8acb7f41c4569e208301153449c2fd8dbd9da

> Set the release date.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@360 ded80894-8fb9-0310-811b-c03f3676ab4d
> CHANGES

2004-12-08 20:49:19 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
0577ac1d30bd76622e9c2cd36ff573b3e144b19c

> Error if the symbol id indicated for refinement in a refagg symbol
> dictionary segment is out of range. UBC test stream 042_13 triggers
> this, we don't fix this here, only handle the error more verbosely.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@359 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_symbol_dict.c

2004-12-07 01:37:45 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
0aa9e029d3d78790d747b8fd6c62f2f6ffe403f5

> Bump the version number for release.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@358 ded80894-8fb9-0310-811b-c03f3676ab4d
> configure.ac

2004-12-07 01:23:24 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
422bfff0efc1eaedd88e5aa876a96ae36fbd13bb

> Add jbig2_refinement.c to the Jam and MSVC builds.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@357 ded80894-8fb9-0310-811b-c03f3676ab4d
> Jamfile
> msvc.mak

2004-12-06 05:37:42 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
389ea3e65131d1644f3c894bd67c6dc433ccb0ec

> Code cleanup. The refinement region decode procedures use a 'GR' prefix
> in the spec even when the function is identical to the 'GB' prefix
> variables in the generic region procedures. Change our code to match.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@356 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_refinement.c

2004-12-06 05:36:28 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
65b51e728aed87dfeb43227218be0c5cc4d642af

> Correct the test for the nominal generic region template 0 AT pixel
> positions. The previous change invoked the optimized routine for the
> wrong template, causing a regression with ubc test stream 042_10.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@355 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_generic.c

2004-12-05 04:15:42 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
5bbe12052a1a34c065451a2c10741021caf6887c

> Update the changelog
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@354 ded80894-8fb9-0310-811b-c03f3676ab4d
> CHANGES

2004-12-05 04:15:13 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
801c41b10d75f023ff2387aac576f5f3c152a308

> Add an unoptimized generic decoder for generic region template 0. We now
> properly decode UBC test stream 042_7.jb2.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@353 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_generic.c

2004-12-05 03:48:36 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
2b6179196091f01a58c17a79024d7ee5243ab8a2

> Add a generic but unoptimized handler for generic region arithmetic
> template 3, and an optimized but untested handler for the default AT
> pixel position. We now properly decode 042_6.jb2 from the UBC test
> suite.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@352 ded80894-8fb9-0310-811b-c03f3676ab4d
> CHANGES
> jbig2_generic.c

2004-12-04 02:29:17 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
b8fc23e4731a172600282a65e9602ff1963bfead

> Implement non-standard AT positions in the unoptimized version
> of the refinement region template. We now properly decode ubc
> test stream 042_23.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@351 ded80894-8fb9-0310-811b-c03f3676ab4d
> CHANGES
> jbig2_refinement.c

2004-12-04 02:24:11 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
42c0312cc2855d2cc0d83954968c65a8e5e6107d

> The gbat and grat content pixel offset arrays are signed.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@350 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_generic.c
> jbig2_generic.h
> jbig2_refinement.c

2004-12-03 17:04:07 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
91496de8718924d6b112c093ea51894210ed8d3d

> Remove the reference image debug dump.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@349 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_refinement.c

2004-12-03 17:03:02 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
c51afb6cce1f14340b7ec8476c64949b469614a7

> #ifdef protect a debug image dump.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@348 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_refinement.c

2004-12-03 06:55:35 +0000
raph <raph@ded80894-8fb9-0310-811b-c03f3676ab4d>
8a90500857d4c0d9a6628196447002efe68a0f46

> Implement text refinement regions (SBREFINE = 1 in text segments).
> jbig2dec commandline now decodes 1page-output.jbig2 from bug #687575.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@347 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_text.c

2004-12-01 22:19:57 +0000
raph <raph@ded80894-8fb9-0310-811b-c03f3676ab4d>
74eba6a78944ccfada0ab7dc50f6363cfd225cbf

> Implements IAID procedure for decoding reference symbol id's in symbol
> dict segs (was incorrectly using generic int procedure). Fixes off-by-
> one test for image bounds in jbig2_image_get_pixel and
> jbig2_image_set_pixel.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@346 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_image.c
> jbig2_symbol_dict.c

2004-12-01 19:50:07 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
a4d66009ee206247b2d9e61615a6fefbc49468c4

> Use the correct definition of the SDREFAGG flag to switch GR_stats allocation.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@345 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_symbol_dict.c

2004-12-01 19:45:29 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
804b91c488cbb7ea22bad56edd0b39384066c908

> Correct a typo, and switch allocation of GR_stats on SDREFAGG instead of SDRTEMPLATE.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@344 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_symbol_dict.c

2004-12-01 19:40:05 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
d89f78a5cb864865e102192f5a44d6b149f0bf71

> Trial implementation of separate GR_stats for refinement arithmetic coding.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@343 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_symbol_dict.c

2004-12-01 19:26:13 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
d489de65d56c8277d5b078759c20a921f429cd63

> Zero the sdrat values if they are not going to be used. Avoids a UMR in a later debug message.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@342 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_symbol_dict.c

2004-12-01 18:51:14 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
ccb4bbffa33b6c0e33b9bc6844ddf69d155c9eb3

> Fix an error in REFAGG decoding, and properly warn that REFAGGNINST > 1 isn't yes implemented.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@341 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_symbol_dict.c

2004-12-01 18:50:06 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
f2bc04b3071d5617851f2255e73d3444ac179dfb

> Update changelog with recent new features.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@340 ded80894-8fb9-0310-811b-c03f3676ab4d
> CHANGES

2004-12-01 18:21:52 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
8291bc316fc9882c419c9fcd11dbd8f19d497402

> Protect the refinement region debug output with an #ifdef.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@339 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_refinement.c

2004-11-24 19:35:47 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
b588b1a9e9599c5041db8279d953bb3aee57371c

> Implement an unoptimized version of refinement region template 0.
> We now decode ubc test stream 042_21.jb2.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@338 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_refinement.c

2004-11-24 19:29:07 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
ccd602286a7f176ffb0fffc68be453d443f0644e

> Invert the check for refinement region movable template
> offsets. This was the last bug in the refinement region
> segment handling code, we now handle the ubc 042_22.jb2
> test file!
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@337 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_refinement.c

2004-11-24 19:26:35 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
c3f6e30d4f07e021cc818e584b085456b25865e6

> Rename the refinement region typical prediction flag
> TPGRON in correspondence with the spec.
> Also fixes some index comparison errors.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@336 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_generic.h
> jbig2_refinement.c
> jbig2_symbol_dict.c

2004-11-24 17:52:32 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
a01d4e48567de8c803e993a76b5d7749f597875d

> Correct the size of the GB_stats allocation for the refinement
> templates; the sizes were reversed.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@335 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_refinement.c

2004-11-24 17:50:30 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
e7c951253f1d39e3a6451cc476f89fd1a5827d97

> correct a typo
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@334 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_refinement.c

2004-11-24 17:49:18 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
faf1a86071f89a81fd9c5f34840bb03a90650c50

> We no longer need the result debug image; page composition is working ok.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@333 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_refinement.c

2004-11-24 07:14:03 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
cf1418dc01a996a8f351918a5fd6202ce02a22d5

> Implement generic refinement region segment handling. Decoding is still
> not correct.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@332 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_refinement.c
> jbig2_segment.c

2004-11-24 07:13:11 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
e161b891ac484992cfff4127332498fb46125fa8

> Clean up some debug messages.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@331 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_image.c
> jbig2_image.h

2004-11-24 03:03:12 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
581b2c04128ae030deba492ea9a4dfc64a033eae

> Correct a typo in reading the SBRAT offsets in text segments.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@330 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_text.c

2004-11-17 19:29:25 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
b4c9f4c43bb969875ad842658e269646abaeb96e

> Promote the debugging get/set pixel routines to general availability.
> Also, fix a bit order bug: we follow the pbm convention, where MSb is
> leftmost, not rightmost.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@329 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_image.c
> jbig2_image.h
> jbig2_refinement.c

2004-10-22 22:28:07 +0000
root <root@ded80894-8fb9-0310-811b-c03f3676ab4d>
2c22eeab4e9a67bb218cb4e03df9ed9bad3b6647

> Build an unoptimized version of the refinement template context calculation
> to assist with debugging. This one doesn't seem to work either.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@328 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_refinement.c

2004-10-22 22:21:19 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
65a3e8bfeba6213859690722281ca290fe3e7d20

> minor comment reformatting
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@327 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_generic.c
> jbig2_generic.h

2004-10-08 01:29:10 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
872c0bb40abd41f305e2cd27a3673fe2f28b9ea6

> correct shift offsets
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@326 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_refinement.c

2004-10-03 21:14:57 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
441dc4f503432969833a7124b45e1e98ffe7cb81

> Additional work on refinement region template 1. Context update still
> incorrect.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@325 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_refinement.c

2004-10-02 07:08:22 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
5d03d94b2004361b89cbf977ad5519b661c2aea7

> Commit of work in progress to support refinement region decode. First
> draft of template 1.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@324 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_refinement.c

2004-09-29 14:15:40 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
0c8fe23adba1f24273186b4a7379f588437d9f5d

> Work in progress of refinement region support. Call logic for refagg
> symbol dictionary entries.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@323 ded80894-8fb9-0310-811b-c03f3676ab4d
> Makefile.am
> jbig2_refinement.c
> jbig2_symbol_dict.c

2004-09-29 13:48:42 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
ef32d14a8d786981905bed84313d250d39b6dead

> Turn on all warnings by default.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@322 ded80894-8fb9-0310-811b-c03f3676ab4d
> configure.ac

2004-08-18 01:11:38 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
f5e8721505beec15991f7660b67fa9dbfd037b7f

> correct some property settings in the source repository
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@321 ded80894-8fb9-0310-811b-c03f3676ab4d
> test_jbig2dec.py

2004-08-18 01:04:28 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
b17636877d0742ea430c1efc646b1e9c68b70014

> enable Id keyword substitution on the new file
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@320 ded80894-8fb9-0310-811b-c03f3676ab4d

2004-08-18 01:03:14 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
1efb1d79e3dead9e474ff89cd0ce0d6c87d21ca3

> It looks like templates aren't shared between generic and generic refinement decoding, so split
> the routines into separate files.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@319 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_generic.c
> jbig2_refinement.c

2004-08-13 00:00:17 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
508693c17eb8f052fbcc0ea4976cb326e746c2f0

> Work in progress to implement generic refinement regions and aggregate symbol coding.
> Commit to avoid losing work.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@318 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_generic.c
> jbig2_generic.h
> jbig2_symbol_dict.c

2004-08-11 16:38:39 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
19918285ec07521885d12a624507435a3da9f473

> correct a typo in the previous commit
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@317 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_page.c

2004-08-10 22:36:14 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
a1f9f214d267dced3b00c96708c95e89d674790a

> Include stdio.h when required for pbm debug output.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@316 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_page.c

2004-08-10 22:34:59 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
4813245d60e430c1b9528a4aa018ee6d45b28add

> document previous fix
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@315 ded80894-8fb9-0310-811b-c03f3676ab4d
> CHANGES

2004-08-10 22:33:46 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
b5264ffff604bc9da416b86b6ed382aa75638dc9

> Properly initialize the page buffer to the default pixel value.
> This caused, among other potential bugs, garbage and overlay
> effects under some malloc implementatons, though not on GNU/Linux.
> Fixes Ghostscript bugs 687530 and 687609. Thanks to Oleg Panashchenko
> for analysis.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@314 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_page.c

2004-08-06 05:01:36 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
99264987a0799fca10e9ccd0aeff86713878ba67

> Actually implement the 'or later' part of the automake version
> detection.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@313 ded80894-8fb9-0310-811b-c03f3676ab4d
> autogen.sh

2004-07-06 13:32:01 +0000
tor <tor@ded80894-8fb9-0310-811b-c03f3676ab4d>
18b2ab815f85ec97de3dcdc2088d4986f1676b84

> added a rudimentary jamfile
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@312 ded80894-8fb9-0310-811b-c03f3676ab4d
> Jamfile

2004-04-08 08:40:49 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
ca77e2fee1e77118981d33fb1b9ab5803717e343

> Initialize some variables to avoid spurious warnings from gcc.
> These are all used only in one code path or another, so there was no
> danger of unitialized use. However, by the same token we lose nothing by
> setting a default to quiet the warning.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@311 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_text.c

2004-04-08 08:36:12 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
09e114b5849ac066755ae1625104896d232ef168

> Remove some unused variables. Bug 687413.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@310 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_generic.c

2004-03-24 07:49:53 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
da420b02de6412f053b759cd04d498762ac62fbe

> Check for defined(HAVE_CONFIG_H) instead of just a non-false value. Corrects a warning on the
> Intel compiler. Ghostscript bug 687320.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@309 ded80894-8fb9-0310-811b-c03f3676ab4d
> os_types.h

2003-12-31 16:38:08 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
365418bd41891ad1627a4bf612dccd51492f6c2c

> Helps to actually increment the version number.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@307 ded80894-8fb9-0310-811b-c03f3676ab4d
> CHANGES

2003-12-31 16:29:40 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
b5715735568f8cdb7cce148b9335933ad20d3cd5

> Update version and changelog for 0.6 release.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@306 ded80894-8fb9-0310-811b-c03f3676ab4d
> CHANGES
> configure.ac

2003-12-31 16:25:47 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
297c9b5fdba66116c2e975789ad7d2d640123114

> Portability update. Newer cygwin does provide stdint.h, conflicting with the work-around we
> installed for older cygwin. Thanks to Alex Cherpanov for this.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@305 ded80894-8fb9-0310-811b-c03f3676ab4d
> os_types.h

2003-12-31 16:25:00 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
49cc61770c6fadfa7a4f2a214a7040db129f3a08

> Apparently forgot to bump the version number in configure.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@304 ded80894-8fb9-0310-811b-c03f3676ab4d
> configure.ac

2003-12-04 16:24:55 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
344fc838a5c35bf4ccef6ec2259b3a317135ab36

> Update changelog for 0.5 release.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@301 ded80894-8fb9-0310-811b-c03f3676ab4d
> CHANGES

2003-12-04 16:19:42 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
a413dad44bd527f43968e32258aed7a20245f5d5

> Remove symbol dictionary export routine debugging prints and modify the dump_symbol_dictionary()
> call so that it does not require stdio.h.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@300 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_symbol_dict.c

2003-12-04 16:11:27 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
204d69f4fce9cf5ee00e0fce774a622e9fca109f

> We no longer need to artificially recurse when building the list of referred symbol dictionaries
> now that we properly construct an exported result.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@299 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_symbol_dict.c

2003-12-04 15:54:34 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
a82d670d005fdd3e4fc877fddcf69ff01f6d53df

> Remove an unused local variable.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@298 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_symbol_dict.c

2003-12-03 05:42:07 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
e242d111c02050235102d9e466e9a4d6435f7867

> Avoid an unitialized variable warning.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@297 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_symbol_dict.c

2003-12-03 00:22:13 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
cb7d209f4e106ec97471b98efdce93814326c8cd

> First stab at parsing the export symbol bitfield and building a proper export dictionary.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@296 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_symbol_dict.c

2003-12-01 19:46:01 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
0a88581c12e2d029bb42aa7d2c745645a3a5d6fe

> Split an expression into two pieces to avoid confusion over order of operations.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@295 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_image.c

2003-12-01 18:02:00 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
02da65fafcef22d50df76638362b946d6a2ec96b

> Add a cast to avoid an incompatible pointer type warning.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@294 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_text.c

2003-12-01 17:54:07 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
12ab5048f182dda7a778b678781e604e6d3abbe6

> Prefer uint8_t to byte in some internal functions.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@293 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_generic.c
> jbig2_page.c
> jbig2_priv.h
> jbig2_segment.c

2003-12-01 17:53:45 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
8d833614a9cdc49e405d72bbf1658859e4468df1

> Correct a warning. Offset, then cast to non-const, not the other way around.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@292 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_metadata.c

2003-12-01 17:44:19 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
7adeea559e68d424dd78ce440536ac2d78fc2a8c

> Add a prototype for the extension segment parser.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@291 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_priv.h

2003-11-11 13:49:50 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
018ec13e4a810da97e57725731d80ca3bff4b5af

> Make Jbig2SymbolDict more object like. Work in progress to unify
> inheritance.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@290 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_symbol_dict.c
> jbig2_symbol_dict.h

2003-11-11 13:15:00 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
5933c48096aca791162c655d9570b2922835cdf6

> Make the symbol dict lookup code public and move it out of jbig2_text.c.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@289 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_symbol_dict.c
> jbig2_symbol_dict.h
> jbig2_text.c

2003-11-10 20:54:09 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
02a9540fdd75a6ed8bfada759b46a42199d84d67

> Properly quote nested M4 macros. The old code breaks in autoconf 2.58.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@288 ded80894-8fb9-0310-811b-c03f3676ab4d
> configure.ac

2003-11-10 17:02:21 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
75c1235ecc921075cb4ec9c2c25e5008d9efad75

> Correct arguments to jbig2_image_free().
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@287 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_image.c

2003-11-09 13:59:03 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
995e4a01171a87bd2453fb05b13612e76720cd26

> Add reference counting to the image structure to permit sharing of the glyph images
> between symbol dictionaries.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@286 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2.h
> jbig2_generic.c
> jbig2_image.c
> jbig2_image_pbm.c
> jbig2_text.c

2003-11-06 18:08:48 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
8f2d8d661e4230e61e095e336f1b14c739b62ba0

> Fix a bug with text region rendering in the Patent.pdf example file from
> the adobe's encoder.
> The problem was that we weren't handling the export/import of symbols
> from dictionaries referred to by the symbol dictionaries referred to by
> the text region segment.
> This patch is just a quick fix: we recurse when building the list of
> referred to symbol dictionaries at text region decode time, which
> allows us to get at all the symbols. This works because the adobe
> encoder (at least in this file) always exports all the symbols, imported
> and encoded, in each dictionary. If it did not, we would have offset
> errors in the symbol lookup.
> A proper fix requires decoding the exported symbol flags and building an
> export version of SBSYMS to store in the segment result that includes
> the symbols imported from any other dictionaries. All while
> intelligently sharing the decoded glyph data, of course.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@285 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_text.c

2003-11-03 16:39:41 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
51ae6b8a96296c1aab50df9d8cee662d09f155bf

> Add a missing header. Record warning fixes in the changelog.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@284 ded80894-8fb9-0310-811b-c03f3676ab4d
> CHANGES
> jbig2_segment.c

2003-11-03 16:38:57 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
04b5524d8767196d4331887cfc6641ada5e5bf42

> Add a 'default' case to the output file format switch to clear up some
> warnings.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@283 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2dec.c

2003-11-03 16:34:12 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
d46b5050cb2ba55fbeb32e70ae368e614ff33d5a

> Remove an unused variable.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@282 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2dec.c

2003-11-03 16:32:15 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
a9edf8c0252898ffb46431e8b5f7bc79d19634f6

> Add string.h for memset().
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@281 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_mmr.c

2003-10-31 12:17:33 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
e3232929d33a254885ae6b63e2281eda9595af1e

> Cosmetic changes to the bootstrap script.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@280 ded80894-8fb9-0310-811b-c03f3676ab4d
> autogen.sh

2003-10-27 10:28:24 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
350f6edb35cbe35fbb0ac7add1a1c7e46147a763

> Add a cast to correct an MSVC warning.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@279 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_text.c

2003-10-01 19:30:10 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
e552e5440e5e285d7df43789a444ccba5727d642

> Remove an unnecessary check for the symbol id < 0 (it's unsigned) and
> correct a type mismatch. Both of these may have been causing warnings on
> MSVC. Thanks to Igor Melichev for tracking down the problem.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@278 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_text.c

2003-10-01 17:05:28 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
539a19a063a962277c04f2c36dbdebc9bad28649

> Add protection against uninitialized dictionary lists, as can happen for
> example when parsing a huffman-coded dictionary (nyi).
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@277 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_text.c

2003-10-01 14:21:19 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
1fd3f35b2f031f1cad486daeff3f625588745e33

> Correct an allocation size bug that caused memory access errors when the
> initial buffer handed to jbig_data_in() didn't match the internal 4k
> size. Thanks to Tor for reporting the bug.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@276 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2.c
> jbig2dec.c

2003-09-29 15:33:48 +0000
tor <tor@ded80894-8fb9-0310-811b-c03f3676ab4d>
bcc1da0257a3f721a4ca95421a996969b8bfb2f6

> Bounds checking and fixed bug with a0 and black background
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@275 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_mmr.c

2003-09-04 04:56:28 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
848fce58b72d73a7345e713f26591674bd019c78

> Update the changelog (nothing new to report).
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@274 ded80894-8fb9-0310-811b-c03f3676ab4d
> CHANGES

2003-09-03 07:27:00 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
c5bd9271ff22faa44bfe4d0120562c52fa964237

> Add some uint*_t typedefs for cygwin. Cygwin apparently doesn't provide stdint.h, but does define
> some of the types in sys/types.h which conflict with the versions in config_types.h. We only use
> sys/types.h in snprintf.c, but it's pulled in by Ghostscript's portability cruft when we're
> compiling in rather than linking to that program. Thus we must circumvent the config_types.h
> definitions on that platfrom.
> After a patch by Alex Cherepanov.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@273 ded80894-8fb9-0310-811b-c03f3676ab4d
> os_types.h

2003-09-03 06:40:03 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
9d23c17acdea2efdbed778078e377c3325106de2

> Add double include protection to os_types.h.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@272 ded80894-8fb9-0310-811b-c03f3676ab4d
> os_types.h

2003-09-03 02:56:29 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
29466e003185c7d4ea43e3a1633c0aa8a6286e7f

> Apply a patch to support compilation on VMS (as part of Ghostscript with openvms.mmk). Closes
> http://bugs.ghostscript.com/show_bug.cgi?id=686966.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@271 ded80894-8fb9-0310-811b-c03f3676ab4d
> os_types.h
> snprintf.c

2003-08-01 14:57:32 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
a11b2b5223c1f1704105ed5a26c319e7efeba5de

> Enable dist-zip since that packaging was the most popular on
> sourceforge.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@270 ded80894-8fb9-0310-811b-c03f3676ab4d
> Makefile.am

2003-08-01 14:34:10 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
cd3bd3d78bb76152b58a6d529a4c34970fb03986

> Set release date for 0.4 release.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@267 ded80894-8fb9-0310-811b-c03f3676ab4d
> CHANGES

2003-07-16 00:52:05 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
b26c92852bd3474fab9730bbcdadf81613ebef7d

> Replace the if tree for choosing sized int types with an easier to read
> case statement.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@266 ded80894-8fb9-0310-811b-c03f3676ab4d
> configure.ac

2003-07-16 00:40:34 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
231a82bff53bdc53098672af60c6436ca99faca4

> Use JBIG2_DEBUG instead of plain DEBUG for compile-conditional debugging
> output. This reduces unnecessary output when we're compiled with our
> client's CFLAGS. Request from Ray Johnston.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@265 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_arith.c
> jbig2_image.c
> jbig2_symbol_dict.c
> jbig2_text.c

2003-06-17 19:24:09 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
69366cad35ef4da5c3c030a4e34c667df2fe900a

> Automake automatically distributes COPYING, but not LICENSE. :)
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@264 ded80894-8fb9-0310-811b-c03f3676ab4d
> Makefile.am

2003-06-14 11:11:24 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
db0078f2e4e5a4db5bf4d489c05a4047a89a0b90

> Some wording cleanup.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@263 ded80894-8fb9-0310-811b-c03f3676ab4d
> configure.ac

2003-06-14 10:20:56 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
c98a1913b50905360c05449ca30084ed51c6658a

> Grant GPL exception for linking to AFPL Ghostscript.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@262 ded80894-8fb9-0310-811b-c03f3676ab4d
> LICENSE

2003-06-14 10:15:52 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
c0bc856d478246a9a5f0f6b264880fee99084a87

> Add banner change to the changelog.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@261 ded80894-8fb9-0310-811b-c03f3676ab4d
> CHANGES

2003-06-14 09:40:02 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
8cb34f5bcc802d6ce57a78b50dc9c75eb0fe0667

> Turn on keyword substitution so our $Id$ lines get updated in
> subversion.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@260 ded80894-8fb9-0310-811b-c03f3676ab4d
> configure.ac

2003-06-13 22:42:55 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
43fcbcd7acbd0b2d64a770ca39590e2356df4337

> Update the license headers to use the same legal redirect as Ghostscript
> does. The individual files point to the file LICENSE which contains the
> real license (a pointer to the GPL in COPYING). This simplifies
> remarking for commercial distribution.
> Also some minor additional debug prints in the symbol lookup code.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@259 ded80894-8fb9-0310-811b-c03f3676ab4d
> LICENSE
> config_win32.h
> jbig2.c
> jbig2.h
> jbig2_arith.c
> jbig2_arith.h
> jbig2_arith_iaid.c
> jbig2_arith_iaid.h
> jbig2_arith_int.c
> jbig2_arith_int.h
> jbig2_generic.c
> jbig2_generic.h
> jbig2_huffman.c
> jbig2_huffman.h
> jbig2_hufftab.h
> jbig2_image.c
> jbig2_image.h
> jbig2_image_pbm.c
> jbig2_image_png.c
> jbig2_metadata.c
> jbig2_metadata.h
> jbig2_mmr.c
> jbig2_mmr.h
> jbig2_page.c
> jbig2_priv.h
> jbig2_segment.c
> jbig2_symbol_dict.c
> jbig2_symbol_dict.h
> jbig2_text.c
> jbig2dec.c
> memcmp.c
> os_types.h
> pbm2png.c

2003-05-20 12:03:43 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
54850de6b0bf55dd409a699be469a133be564028

> Bump version number post-commit.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@258 ded80894-8fb9-0310-811b-c03f3676ab4d
> CHANGES
> configure.ac

2003-05-20 10:39:43 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
0797f658a74d280ca5bcec76ca932475d3b24be9

> Set date for 0.3 release.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@255 ded80894-8fb9-0310-811b-c03f3676ab4d
> CHANGES

2003-05-20 10:34:03 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
cf4c5147c8ecf2babc6a1a816d27ddaf784b2a0f

> Update changelog.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@254 ded80894-8fb9-0310-811b-c03f3676ab4d
> CHANGES

2003-05-20 10:31:54 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
4be0d08eaeb704454a7bf1dc95e7b6739fface4e

> Complete implementation of mmr decoding. We now pass another of the ubc test bitstreams!
> (042_3.jb2, mmr generic region) Patch from Tor Andersson.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@253 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_mmr.c

2003-05-20 10:30:43 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
01736665634a1be9b07b275a5a365b56f445d965

> Recorrect a typo in the recommit.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@252 ded80894-8fb9-0310-811b-c03f3676ab4d
> os_types.h

2003-05-07 22:45:42 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
72f228cadf2b189713cdcb92c1cb20facdab0822

> correct a typo.
> (recommitted after repository became corrupt. original change date Wed May 7 05:00:33 2003)
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@251 ded80894-8fb9-0310-811b-c03f3676ab4d
> configure.ac

2003-05-07 22:44:43 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
96c0fc6a33671822f63d5941e045c8f88e8e3241

> Add Theo deRaadt's portable (v)snprintf implementation for portability, under
> the BSD license, including advertising. A simple check was added to the configure
> script, but no prototypes, so it may not help any on systems without the functions.
> Submission from Jouk Jansen to allow compilation into Ghostscript on OpenVMS.
> (recommitted after repository became corrupt. original change date Wed May 7 04:17:39 2003)
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@250 ded80894-8fb9-0310-811b-c03f3676ab4d
> configure.ac
> snprintf.c

2003-05-07 22:41:01 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
c65c52c0638fdfd3613fc7becd77410769ac62ec

> Move HAVE_LIBPNG to the msvc makefile; this shouldn't necessarily be included in the win32 build
> (e.g. in ghostscript) so we only define it in our local msvc makefile.
> (recommitted after repository became corrupt. original change Wed May 7 03:48:12 2003)
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@249 ded80894-8fb9-0310-811b-c03f3676ab4d
> config_win32.h
> msvc.mak

2003-05-07 22:39:09 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
1ed232578276caf6e999a2a9c0b6fd8952af659c

> Further conditionalize the symbol dictionary debug dump: it's now enabled with DUMP_SYMDICT
> instead of just DEBUG.
> (recommitted after repository became corrupt. original change date Mon May 5 10:26:31 2003)
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@248 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_symbol_dict.c

2003-05-07 22:34:38 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
2f525802258cbed79e961d81e15390adf0f597ee

> Avoid a (spurious) uninitialized variable warning.
> (recommitted after repository became corrupt. original change date Mon May 5 10:23:28 2003)
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@247 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_text.c

2003-05-07 22:33:22 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
e3539c7888e025ebd0847d7099cf0a88b2465c8e

> Pass the segment number to fprintf in the default error handler.
> (recommitted after repository became corrupt. original change date Mon May 5 10:22:41 2003)
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@246 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2.c

2003-05-07 22:32:15 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
5c9498154bb7e722777fcda2294b31535ef06e08

> Bump version number post-release.
> (recommitted after repository became corrupt. original change date Wed Apr 16 19:42:34 2003)
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@245 ded80894-8fb9-0310-811b-c03f3676ab4d
> CHANGES
> config_win32.h
> configure.ac

2003-05-07 22:25:18 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
48db6a4570673a48ee2c911d2259c79437080b54

> Add brief instructions for building zlib and libpng under MSVC.
> Contributed by Russell Lang.
> (recommitted after repository became corrupt. original change date Wed Apr 16 19:00:23 2003)
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@242 ded80894-8fb9-0310-811b-c03f3676ab4d
> msvc.mak

2003-05-07 16:09:29 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
bfea189549eccb3a6f1a81bbd1bbb092ab789b35

> Mention adobe encoder handling in the changelog. We still don't handle multi-page (separate global
> stream) documents properly.
> (recommitted after repository became corrupt. original change dated Wed Apr 16 18:45:19 2003)
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@241 ded80894-8fb9-0310-811b-c03f3676ab4d
> CHANGES

2003-05-07 16:07:31 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
bf2f470f28a35f6670aa9b31214e0624364f992f

> strncasecmp() isn't portable. work around until we can provide our own.
> (recommitted after repository became corrupt. original change dated Wed Apr 16 18:44:11 2003)
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@240 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2dec.c

2003-05-07 16:05:37 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
09f3c413c9112606dc3afae719884151280f4e9d

> Update changelog for release.
> (recommitted after repository became corrupt. original change dated Wed Apr 16 18:13:29 2003)
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@239 ded80894-8fb9-0310-811b-c03f3676ab4d
> CHANGES

2003-05-07 16:04:12 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
a6217b4a900b82dd6af3076e964382a402c0bfbf

> It turned out not to be feasible to share rules between our MSVC
> makefile and the integration makefile in ghostscript, so remove it.
> msvc.mak is returned to it's previous state except for some additions
> made when common.mak was introduced.
> (recommitted after repository became corrupt. original change dated Apr 16 18:10:01 2003)
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@238 ded80894-8fb9-0310-811b-c03f3676ab4d
> common.mak
> msvc.mak

2003-05-07 16:02:11 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
816d22aedc4bf1bc5d629f3b94b801c2ccf14693

> Remove the warnings flag; -Wall is gcc-specific so we need to turn it on from inside configure if
> at all. There is an AC_COMPILE_WARNINGS() in the GNU ac-archive.
> (recommitted after the repository became corrupt. original change dated Wed Apr 16 15:56:27 2003)
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@237 ded80894-8fb9-0310-811b-c03f3676ab4d
> Makefile.am

2003-05-07 16:00:32 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
e3d615c2d58020492dda10a84ac06977a76035ef

> MacOS generally has stdint.h available (Apple's tools on MacOS X or recent Metrowerks CodeWarrior)
> but may not be using the autoconf detection. Include it in such cases.
> (recommitted after repository became corrupt. original change date Wed Apr 16 15:48:14 2003)
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@236 ded80894-8fb9-0310-811b-c03f3676ab4d
> os_types.h

2003-05-07 15:59:19 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
7b85c55864583c6955e69f192795a66312b6aabd

> Add -Wall to the CFLAGS.
> (recommitted after repository became corrupt. original change date Wed Apr 16 15:45:59 2003)
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@235 ded80894-8fb9-0310-811b-c03f3676ab4d
> Makefile.am

2003-05-07 15:56:59 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
9e4350a4eedb67290d35526d526878ab99d8a1a2

> Change the declaration to match the prototype.
> (recommitted after repository became corrupt; original change Wed Apr 16 15:45:15 2003)
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@234 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2.c

2003-04-02 16:17:01 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
de8bf02d7172eba62b4d6a66c608cd9d11773d1e

> Free the output filename.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@232 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2dec.c

2003-04-02 16:12:17 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
246505fd73f229f252b2ad368006ce234a09b7b9

> Try to set the output format based on the extension given in -o if any.
> Also fixes a bug where the format was undefined with -o. (yay valgrind!)
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@231 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2dec.c

2003-04-01 21:57:40 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
362445ced69525d1556b72de5c078b87eed56625

> Implement the '-t' option for setting the output file format.
> Useful for forcing pbm output even when compiled with png support.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@230 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2dec.c

2003-04-01 21:00:23 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
e07cbaf880581cb1f808e409725d2b94c55a8630

> Allocate sufficient memory for the referred-to segment list.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@229 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_segment.c

2003-04-01 20:56:59 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
f5ff079d941a29486cc74bf08715b2a24c775af5

> Add some additional comments.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@228 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2.c

2003-03-31 21:27:05 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
5e95bfa1388379875a3b329b83046b997c15d853

> Abstract common build rules to a separate makefile to facilitate building into ghostscript.
> Someone should test that msvc.mak still works.
> Ideally we'll make autogen.sh re-create common.mak at some point.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@227 ded80894-8fb9-0310-811b-c03f3676ab4d
> common.mak
> msvc.mak

2003-03-25 00:17:45 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
96f6a87358df7183b9070a8441cce4a2c2e46541

> add some comments
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@226 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_segment.c

2003-03-23 22:24:24 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
8f68c407604a7584cbd9c0b2323530b2451b24eb

> Mention the new subversion repository.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@225 ded80894-8fb9-0310-811b-c03f3676ab4d
> README

2003-03-10 14:44:01 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
65b4b234ef4c5d12d8d5f9d624d51595f9e8f14f

> add a debug message about segment page association
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@222 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_segment.c

2003-03-05 14:29:35 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
f93bc27cbd73b33ac30122d2ca64aab63ce0e327

> Make jbig2_find_segment() part of the public api and move it to jbig2_segment.c.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@221 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2.h
> jbig2_segment.c
> jbig2_text.c

2003-03-05 12:25:54 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
ce9531e0941d40cd301d1c1dfd15d6b0a4289cc8

> correct a nested debug #ifdef
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@220 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_symbol_dict.c

2003-03-05 03:32:41 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
c63db75d9076c14e2e7f89f4d93950f51a30d606

> Update copyright dates on new files.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@219 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_metadata.c
> jbig2_metadata.h

2003-03-05 02:44:43 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
22881a46c322b45b34e20b9270e825dbe5c2c1a1

> Add support for ASCII-format comment extension segments. So far it's just
> useful for printing out the contents through the error callback; eventually
> there should be a public interface of the metadata tables and references from
> the associated ctx/page/segments.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@218 ded80894-8fb9-0310-811b-c03f3676ab4d
> Makefile.am
> jbig2_metadata.c
> jbig2_metadata.h
> jbig2_segment.c

2003-03-04 17:29:24 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
4f74ab25a2904a70c3e1e017090aed00cbd4cae3

> Code cleanup: re-order a buffer-size check in the segement header parser to avoid a memory leak on
> failure.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@217 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_segment.c

2003-03-04 16:52:48 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
21c62259b5fa2ca459e5d0285ba35e1498523b95

> Switch to automake 1.7 and move the options to Makefile.am.
> Sorry, calling automake-1.6 on macosx was causing wierd errors. This was just
> easier. I hope that with 1.7 the am maintainers are finally getting things stable.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@216 ded80894-8fb9-0310-811b-c03f3676ab4d
> Makefile.am
> autogen.sh

2003-03-04 16:15:36 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
274ae8d1af9e66b43712a2ca589884cea01e9aee

> Remove the check for malloc. Since we're assuming C99, it will definitely be there, and recent
> versions of autoconf expect to be able to substitute a wrapper than handles malloc(0) a feature
> we don't depend on.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@215 ded80894-8fb9-0310-811b-c03f3676ab4d
> configure.ac

2003-03-04 15:39:00 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
cb59bb24b925af295e1a387fc72042c143018e0e

> Correct a typo in the previous commit.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@214 ded80894-8fb9-0310-811b-c03f3676ab4d
> autogen.sh

2003-03-04 15:24:58 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
e6ad78534cb77c4ae3beb02c2843f6a546794f13

> Try to make autogen.sh smarter about automake version mismatch.
> This is really silly, but there's a serious problem with incompatibility
> between the various versions of automake, and while there is a mechanism
> for requesting a particular version in the Makefile.am, most
> installations don't make use of this information, and you're supposed to
> know which automake to call. Since this obviates the point of autogen,
> we attempt to match a requested version in AUTOMAKE_HEADERS to likely
> executables. Probably not very robust.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@213 ded80894-8fb9-0310-811b-c03f3676ab4d
> autogen.sh

2003-02-11 22:59:54 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
cfe0afbb44960be129c6d25fe3287d1ecfc15474

> Correct some accidentally-introduced line breaks in the sha1 code.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@212 ded80894-8fb9-0310-811b-c03f3676ab4d
> sha1.c

2003-02-07 05:14:09 +0000
raph <raph@ded80894-8fb9-0310-811b-c03f3676ab4d>
5fb176e3daee8d87d1b6a25eb4d71b03a20694ea

> Debug message for "referred to segment" had an extra level of
> redirection.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@211 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_segment.c

2003-02-07 05:06:46 +0000
raph <raph@ded80894-8fb9-0310-811b-c03f3676ab4d>
376546a60ce0bf4ff095f234b1d8ad429b6b450b

> Fixes: make find_segment search globals, and also fix off-by-one.
> Disable memcpy optimization in jbig2_image_compose, because it's not
> always valid.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@210 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_image.c
> jbig2_text.c

2003-02-05 15:27:42 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
5e048fb252ff7f9b0355e444b0fb65804e68e1c7

> Use a namespace-prefixed, more verbose name for the MMR huffman tables. They
> were of course conflicting with their counterparts in Ghostscript.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@209 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_mmr.c

2003-02-05 15:09:59 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
fce47c5bcdb3d0fe30fdc0ac0868a27a76198a2a

> Add double-include protection to the public header.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@208 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2.h

2003-02-03 20:04:11 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
66d05e3c767bad968a98b9f63a88b07cb9df624f

> Provide a default error handler if the client doesn't specify one,
> analogous to what we do with the allocator. Also, check for failure
> of the initial context allocator and improve api description in the
> public header file.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@207 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2.c
> jbig2.h

2003-01-27 16:49:28 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
8fd3ed86d9a6b47715235d32994bd355f5d99f69

> add some files to cvsignore
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@206 ded80894-8fb9-0310-811b-c03f3676ab4d
> .cvsignore

2002-11-14 12:19:14 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
5df2b837e72d1d781fcc29c0d21f82222c2e7af4

> Add the three-page test file from appendix h of the jbig2 spec. This version
> was extracted from the final candidate draft but is identical to the officially
> ratified versions.
> Note that we can't actually handle this file yet.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@205 ded80894-8fb9-0310-811b-c03f3676ab4d
> annex-h.jbig2

2002-08-15 14:57:53 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
f24a7a84cca3fefe41cc459baf692fee6f0cd2ce

> document portability fixes
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@204 ded80894-8fb9-0310-811b-c03f3676ab4d
> CHANGES

2002-08-15 14:54:45 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
73934fd922618a011046c6fcbd844b26854b584f

> Remove //-style comments for the benifit of those not using gcc.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@203 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_image.c
> jbig2_image_pbm.c
> jbig2_mmr.c
> jbig2_page.c
> jbig2_symbol_dict.c
> jbig2_text.c
> jbig2dec.c

2002-08-15 13:52:28 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
c6d9d6dd41f859c4dd3fb53c4fccc0ca34ca6a87

> checkpoint commit: do-nothing -t option for setting output file type.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@202 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2dec.c

2002-08-15 11:55:34 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
771b3b4d02bb7f12c9e08cc602261857499ccefb

> Prepend -lpng -lz to LIBS to preserve link order dependencies.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@201 ded80894-8fb9-0310-811b-c03f3676ab4d
> configure.ac

2002-08-14 16:58:00 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
f5911b3cda06461a8f4fab259bb6f86d5453a0bb

> correct order of pow() check
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@200 ded80894-8fb9-0310-811b-c03f3676ab4d
> configure.ac

2002-08-14 16:07:52 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
d113ae2198cca92f0c82f55e1cb792fa66cc6004

> Add a --with-libpng[=prefix] option. This can be used to specify the
> prefix where libpng is installed (assuming prefix/include, prefix/lib)
> if it's not on the default search path. It can also be used (as --without-libpng)
> to explicitely disable the png output option.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@199 ded80894-8fb9-0310-811b-c03f3676ab4d
> configure.ac

2002-08-14 14:21:15 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
63165e5f84efb734262603fe81633d7d89e18fe8

> libpng calls pow() which on some systems means we need -lm.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@198 ded80894-8fb9-0310-811b-c03f3676ab4d
> configure.ac

2002-08-14 11:44:53 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
377728e4294c745faeec8f63523621e3839bb8ee

> Remove //-style comments.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@197 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_image_pbm.c

2002-08-14 10:31:08 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
229557eb1f5fefdb69c63d38140edbbf5c7b6b6b

> Declare the test vector (strings) as char instead of unsigned char. We already cast to (uint8_t*) before passing to the hash routines, and the declaration caused a signed/unsigned warning in strlen() on some systems. Thanks to Tom Kacvinsky for this one.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@196 ded80894-8fb9-0310-811b-c03f3676ab4d
> sha1.c

2002-08-14 10:25:59 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
834b69f7023a5a3ea9c6e853cde1b67cbce29589

> remove spurious semicolon. thanks to Tom Kacvinsky for catching this.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@195 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_arith.c

2002-08-14 10:22:57 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
f30fb27aea0ad95045aa6ce8ae51335268762cf7

> Fix up file-ending newlines. After a patch from Tom Kacvinsky.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@194 ded80894-8fb9-0310-811b-c03f3676ab4d
> sha1.c
> sha1.h

2002-08-10 10:39:20 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
865f3114b422acadb98f51f9ffdaf92bfe8e680d

> refine const ** to const * const * to avoid warnings.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@193 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_text.c

2002-08-07 12:50:33 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
85bf278b42fe3059dc8774d6f257dbc07ac50679

> Use callbacks for writing png data out to a file. This is necessary when
> dynamically linking to libpng on win32 when different run-times are used
> for each library. Patch from Russell Lang.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@192 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_image_png.c

2002-08-07 10:18:42 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
6aa746d4788e43727f93ed58581ef13f45f5e4b1

> bump version post release
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@191 ded80894-8fb9-0310-811b-c03f3676ab4d
> CHANGES
> config_win32.h
> configure.ac

2002-08-06 14:35:38 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
45ced1e5e5c2cb8401bc7784297a905aba29051d

> cvsignore additions
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@190 ded80894-8fb9-0310-811b-c03f3676ab4d
> .cvsignore

2002-08-06 11:52:43 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
8a586cd6708d8255128081511e072778cd3f0d76

> fixup install target
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@188 ded80894-8fb9-0310-811b-c03f3676ab4d
> Makefile.am

2002-08-06 11:31:53 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
037a0bdc906e729e42ecb6914c722db0a8f27270

> fix a typo
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@186 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_image_png.c

2002-08-06 11:30:58 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
4b55adb9e7e662440502d9a7a5558ce69f3f1dff

> Wrap the README at 72 character-per-line and add links to the website and
> mailing list.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@184 ded80894-8fb9-0310-811b-c03f3676ab4d
> README

2002-08-06 11:27:08 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
4fa4291e3366e1794fcb594d5b1c1aea8c293e2f

> add the msvc makefile to the dist target
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@183 ded80894-8fb9-0310-811b-c03f3676ab4d
> Makefile.am

2002-08-06 11:15:29 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
bad2f808eed9cae57d030f76b3bb22f57618115e

> Add some casts to avoid MSVC warnings where it improves readability.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@181 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_arith.c

2002-08-06 10:57:49 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
db6ba0ba18e02d73fcfcbdbddde043f8b841130f

> Document png_init_io() not working on win32 when libpng is a dll. Please
> link statically.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@180 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_image_png.c

2002-08-06 10:54:19 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
f5debdea11d7e557cacc8d101d2b37784cba2668

> MSVC makefile updates from Russell Lang.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@178 ded80894-8fb9-0310-811b-c03f3676ab4d
> msvc.mak

2002-08-05 23:07:54 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
9fae8ec8e63aaa7eabdf3a1b87271da507e079d1

> additional code cleanup inspired by compiler warnings
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@176 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_mmr.c
> jbig2_text.c

2002-08-05 23:00:52 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
f8a8d032eda34625e956ad44a607c4243001ea81

> remove unused variables
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@174 ded80894-8fb9-0310-811b-c03f3676ab4d
> sha1.c

2002-08-05 22:56:51 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
b9bdc3ab0c142018713b9ff4155b55525035b061

> Fix incorrect check for error condition; thanks to Russell Lang's MSVC
> compile log for this.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@172 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2dec.c

2002-08-05 22:55:02 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
15db0db751e9ea2df2f56c25cce79c02b8bab9be

> include string.h for str* prototypes.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@170 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2.c

2002-08-05 22:47:53 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
19968191d0e439174a62e9db1acda370373014ab

> make the buffer rd/wr offsets unsigned ints to avoid signed/unsigned
> warnings. they should really be offset_t, but we're scared to use that
> because no one else does.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@168 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_priv.h

2002-08-05 22:46:00 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
a889e79e5e6b5815428ad9dbe56b11a65c8aa395

> remove an unused variable
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@166 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_page.c

2002-08-05 22:28:15 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
2c6315036696b95ebec9dbb770283fee37b076fd

> Define PACKAGE and VERSION for the win32 build
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@164 ded80894-8fb9-0310-811b-c03f3676ab4d
> config_win32.h

2002-08-05 22:26:21 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
554d849f37c9e0a6b715378feca28c1187fc3c75

> remove an unreferenced variable.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@163 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_text.c

2002-08-05 21:43:26 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
12819e23ead5fb7b54d28df3802d4678c0350a86

> properly pass in the client params with the error callback when opening embedded streams
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@162 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2dec.c

2002-08-05 18:06:37 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
0f4c012e1c266f010bb0f04b1319e9d5f82308dc

> Add headers and test script to Makefile.am so they get distributed.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@161 ded80894-8fb9-0310-811b-c03f3676ab4d
> Makefile.am

2002-08-05 18:06:06 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
84599735f9e9e101f3f7a93002127b60248c7fa3

> remove redundant package and version indications
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@159 ded80894-8fb9-0310-811b-c03f3676ab4d
> configure.ac

2002-08-05 17:10:44 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
6455a4bffb866a47732b574d1f2fd105f8b03544

> Add a memcmp() implementation, pulled in by autoconf if it's not available
> or the system version is broken. Don't know where the header's supposed to
> come from, since it defines no symbol for conditionalizing a prototype.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@157 ded80894-8fb9-0310-811b-c03f3676ab4d
> memcmp.c

2002-08-05 16:56:19 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
d77b454b4a356db81c8db7d0f74e5dc13dc46707

> mention reg testing in changelog
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@155 ded80894-8fb9-0310-811b-c03f3676ab4d
> CHANGES

2002-07-20 17:23:15 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
0a3078ab2eb1718856a54d53056da4b68d976932

> move repeated configuration includes to a new os_types.h
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@153 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2.c
> jbig2_arith.c
> jbig2_arith_iaid.c
> jbig2_arith_int.c
> jbig2_generic.c
> jbig2_huffman.c
> jbig2_image.c
> jbig2_image_pbm.c
> jbig2_image_png.c
> jbig2_mmr.c
> jbig2_page.c
> jbig2_segment.c
> jbig2_symbol_dict.c
> jbig2_text.c
> jbig2dec.c
> os_types.h
> sha1.c

2002-07-20 17:06:04 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
7a07db105fb7181327662b01282ccae6b69fa67b

> require automake 1.6
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@152 ded80894-8fb9-0310-811b-c03f3676ab4d
> Makefile.am

2002-07-20 16:19:33 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
988dc4fc92252070dfdc00c7aa44ebc91c2c7a74

> minor rearrange
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@151 ded80894-8fb9-0310-811b-c03f3676ab4d
> sha1.c

2002-07-20 16:09:08 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
4d306e9ed969ff29bbceb2092ca67d9671e04a6a

> document endian worry
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@150 ded80894-8fb9-0310-811b-c03f3676ab4d
> sha1.c

2002-07-20 16:05:14 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
201eeb8a511e28806bf1786ff1b57b8331b34808

> Remove an obsolete AC_SUBST
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@149 ded80894-8fb9-0310-811b-c03f3676ab4d
> configure.ac

2002-07-20 16:07:34 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
a61fc54c09021114fae3744f16f4fa6fb79192be

> Space after testing message elipsis.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@148 ded80894-8fb9-0310-811b-c03f3676ab4d
> sha1.c

2002-07-20 16:02:24 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
bf37c640d04807206926a1fe7b7c501db9225452

> Replace (optional) linking to the openssl implementation of SHA-1, which
> is not GPL compatible with a native implementation based on Steve Reid's
> public domain implementation from sea-to-sky.net. Our version remains
> public domain, but now requires our autotools-generated headers.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@146 ded80894-8fb9-0310-811b-c03f3676ab4d
> Makefile.am
> configure.ac
> jbig2dec.c
> sha1.c
> sha1.h

2002-07-17 23:59:29 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
950df8201674a19af5fa5ff61ba7b006b0691edb

> Use the recommended 'generalized' digest api from openssl, still computing
> SHA-1. Treat the hash bytes as unsigned; update the ubc hash values to
> properly printed ones. N.B.: the printing hash still doesn't match the one
> generated by invoking 'openssl dgst -sha1 -hex' on the pbm output with the
> header stripped. I don't understand why.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@144 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2dec.c
> test_jbig2dec.py

2002-07-17 13:59:47 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
e21659fda78e53fdcbed87290a51a178d26788f6

> Add a regression test script based on the python unittest framework.
> It looks for known files, runs 'jbig2dec --hash' and compares the result
> to the known correct value. Currently it looks for the ubc test files
> in '../ubc/'
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@143 ded80894-8fb9-0310-811b-c03f3676ab4d
> Makefile.am
> test_jbig2dec.py

2002-07-17 13:52:53 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
d88cf9f4fdb0b874f9544ac54bcbf3b536665096

> comment out debug printouts
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@142 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_mmr.c

2002-07-16 21:19:09 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
7d8a599b44667b94b66cc94d818ff62ea7826d3d

> implement --quiet and --verbose. Verbosity now defaults to '1', which
> only warnings and fatal errors. -v recovers the old behavior. intermediate
> levels can be set with --verbose=n. -q/--quiet is the same as --verbose=0;
> it should supress all messages.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@141 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2dec.c

2002-07-15 23:50:47 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
427435dd1db50cb1b88000e6f785fcfe74c3bb0e

> implement --version
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@140 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2dec.c

2002-07-15 23:25:30 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
dabd594f325487412c44b593b8aae566c3fc9eab

> add config_types.h.in, generated by autogen.sh, to the AM MAINTAINERCLEANFILES variable.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@139 ded80894-8fb9-0310-811b-c03f3676ab4d
> Makefile.am

2002-07-15 20:01:01 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
d53ab5a9d654df525f522afb43c6afeb6c1b6d4b

> Add a '--hash' cmdline option to print the SHA-1 hash of the decoded
> document. Useful for regression testing. We currently use the openssl/
> libcrypto implemention; there's provision for fallback to a local version
> but I've not written one yet. It should probably just be the default once
> provided.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@138 ded80894-8fb9-0310-811b-c03f3676ab4d
> configure.ac
> jbig2dec.c

2002-07-13 01:22:50 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
778b53afed3f8cd0caa85d81a3f1fd0a3a35c446

> update configure.ac to 2.53, use AC_LIBOBJ() instead of updating LIBOBJS directly
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@137 ded80894-8fb9-0310-811b-c03f3676ab4d
> configure.ac

2002-07-13 01:10:00 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
da5605986165e0acfde37fda4dfe594eba8d95d0

> remove 'can define uint32_t as' messages and fix a typo
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@136 ded80894-8fb9-0310-811b-c03f3676ab4d
> configure.ac

2002-07-13 01:04:32 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
31aeca142b98bd794167a31c741bf73b191d6adb

> Don't use shell expansions in the init macro arguments; autoconf now provides m4 macros for that.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@135 ded80894-8fb9-0310-811b-c03f3676ab4d
> configure.ac

2002-07-13 00:32:43 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
f9e3d8813674fe45ec12a3b75f5ab9024747a41d

> make jbig2_decode_text_region() static
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@134 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_text.c

2002-07-13 00:32:13 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
8c096907fe8dd6484d21c45b96ed035fee36b776

> Fix up make_output_filename(), improve usage message.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@133 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2dec.c

2002-07-13 00:03:52 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
372fddd151857b3047e1487589e88f4555c0ec9a

> ui cleanup. output filename generation is broken
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@132 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2dec.c

2002-07-09 10:39:08 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
e7ee4564585ddd8cd3ab20af5df840d818be0751

> protect definitions of TRUE/FALSE
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@131 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_priv.h

2002-07-09 10:13:13 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
21b56ef9c96211883841f4b55342c805a09619a4

> Prefer #if defined()
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@130 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_symbol_dict.c

2002-07-09 10:09:19 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
6bb931251b4346a34dca8eafdfa1157c3bf7b339

> Correct win32 headers dependency.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@129 ded80894-8fb9-0310-811b-c03f3676ab4d
> msvc.mak

2002-07-09 09:49:31 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
9f0cd84893d4b71effe4bfd4595d59a5be7f6fc5

> We now decode the CVision Starr Report page embedded stream, once extracted from the pdf.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@128 ded80894-8fb9-0310-811b-c03f3676ab4d
> CHANGES

2002-07-09 09:45:32 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
75e38f7a64fa7aace00e9a8a48cdfe1904adecc5

> Work around missing end-of-page segment in CVision's PDF-embedded jbig2 streams.
> jbig2_complete_page() becomes a public function marking the current page finished
> so the client can call it at end-of-data, since data-shovel interface has no way
> of passing that out-of-band. The segment dispatch calls a new jbig2_parse_end_of_page()
> which does error checking and then calls jbig2_complete_page().
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@126 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2.h
> jbig2_page.c
> jbig2_priv.h
> jbig2_segment.c
> jbig2dec.c

2002-07-09 09:38:37 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
d7d07a0b4a33596ac29f0e3809720e829cf1427b

> Correct the dictionary-referral logic in the text segment decoder. Previously
> we were using the decode order index to lookup the referenced segments(s) but
> this breaks if the segment numbers don't begin and 0 and increase one-by-one.
> We now search backward looking for a matching segment number. Should replace
> this with a binary search once we start seeing bigger files.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@125 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_text.c

2002-07-08 19:23:11 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
66b303cfa844f3f8afcebb5d212520cf6de77f7a

> additional debug messages
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@124 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_priv.h
> jbig2_segment.c

2002-07-08 19:21:35 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
ca393a748cf39ff0818a4183a6deb272ade44bfb

> Fix parsing of sequential files.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@123 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2.c

2002-07-08 14:54:02 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
0e74e387b2ac9dfb748dc090528bc1debe347afa

> Add support for building under Microsoft Visual C++ after a patch from Russell Lang. Please test.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@121 ded80894-8fb9-0310-811b-c03f3676ab4d
> config_win32.h
> jbig2.c
> jbig2_arith.c
> jbig2_arith_iaid.c
> jbig2_arith_int.c
> jbig2_generic.c
> jbig2_huffman.c
> jbig2_image.c
> jbig2_image_pbm.c
> jbig2_image_png.c
> jbig2_mmr.c
> jbig2_page.c
> jbig2_segment.c
> jbig2_symbol_dict.c
> jbig2_text.c
> jbig2dec.c
> msvc.mak
> pbm2png.c

2002-07-08 14:26:03 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
44cbf7cdc4d9c545004218ffc10c41b2fab7c38c

> Remove the internal include of stdint.h from jbig2.h, enforcing the requirement
> that the calling C file to do so.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@120 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2.h
> jbig2_image_pbm.c

2002-07-08 14:19:51 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
7ea3cbeb28b39fe56c7d791361f969b255fb59bd

> Add a CHANGES document.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@119 ded80894-8fb9-0310-811b-c03f3676ab4d
> CHANGES

2002-07-08 14:13:04 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
eb37c87f0474f8d055520f3cda6fb0ddec667bbf

> add pbm2png to cvsignore
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@117 ded80894-8fb9-0310-811b-c03f3676ab4d
> .cvsignore

2002-07-08 14:11:36 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
12c09379bf9380ca153eff8f96ebb84f00d7a000

> Update pbm2png.c to pass a jbig2 context for the allocator, so that
> it can be linked against the current routines.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@116 ded80894-8fb9-0310-811b-c03f3676ab4d
> pbm2png.c

2002-07-08 14:10:27 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
c860cbae3e0b07420dfd2407173673a451a36237

> Don't look for png.h specifically. This was causing problems with png.h was in an -I in CFLAGS, but not the standard place.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@115 ded80894-8fb9-0310-811b-c03f3676ab4d
> configure.ac

2002-07-08 13:45:50 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
af9ddb9b26b13821f97d789f866c09c15bcc254e

> add config_types.h(.in) to cvsignore
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@114 ded80894-8fb9-0310-811b-c03f3676ab4d
> .cvsignore

2002-07-08 13:40:15 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
b9d1e45dc2ee18fe0935e174499779f5b2505028

> Work around stdint.h portability problems. If the C99 header isn't available,
> look for uint32_t in a few other likely headers. Also try and discover appropriate
> sizes and use our own typedefs if no useful header is found.
> All this goes into a new generated header file 'config_types.h'. We abuse
> autogen.sh to create the template so it doesn't clutter cvs for non-autotools
> builds.
> Include config.h and config_types.h into every file that includes jbig2_priv.h
> so ensure the types are defined.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@112 ded80894-8fb9-0310-811b-c03f3676ab4d
> autogen.sh
> configure.ac
> jbig2.c
> jbig2_arith.c
> jbig2_arith_iaid.c
> jbig2_arith_int.c
> jbig2_generic.c
> jbig2_huffman.c
> jbig2_image.c
> jbig2_image_png.c
> jbig2_mmr.c
> jbig2_page.c
> jbig2_segment.c
> jbig2_symbol_dict.c
> jbig2_text.c
> jbig2dec.c

2002-07-07 20:38:26 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
63beb9c3beb1b0a0ab3579ab8e7b17b02c0f76f9

> minor rename
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@111 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_page.c
> jbig2_priv.h
> jbig2_segment.c
> jbig2_text.c

2002-07-07 20:30:57 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
6c00475e659e7f29c142e879ec3dd9d4b5375ee5

> Handle lossy and intermediate text regions as well as lossless immediate.
> Store the bitmap for intermediate text regions into the segment's result field for later use by a refinement region.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@110 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_segment.c
> jbig2_text.c

2002-07-04 16:33:44 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
d85ffd487d624754ce5784fb970e939bc8b9dd5c

> API renames. Main loop is now jbig_data_in(data); image=jbig2_page_out();
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@109 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2.c
> jbig2.h
> jbig2_page.c
> jbig2_segment.c
> jbig2dec.c

2002-07-04 13:54:09 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
f94a083d0d5f35721a1fbdd61f2b908ae41b9189

> cvsignore update
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@108 ded80894-8fb9-0310-811b-c03f3676ab4d
> .cvsignore

2002-07-04 13:53:38 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
4c517739877594997a67dfd383c80c8d3dacc96b

> fill out the README
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@107 ded80894-8fb9-0310-811b-c03f3676ab4d
> README

2002-07-04 13:34:29 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
2048089ff9b99ac20bcfcb4dad4b2238e796db68

> Clean up some warnings from MSVC. Thanks to Russell Lang for the report.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@105 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2.c
> jbig2_arith_iaid.c
> jbig2_arith_int.c
> jbig2_generic.c
> jbig2_generic.h
> jbig2_image.c
> jbig2_image_pbm.c
> jbig2_mmr.c
> jbig2_page.c
> jbig2_priv.h
> jbig2_segment.c
> jbig2_symbol_dict.c

2002-07-04 12:08:03 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
6515f25ce92cb589a7ed16217dffcc012e08a4ea

> Code cleanup (obsuscation?) Turn off excessive debugging output.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@104 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_image.c
> jbig2_text.c

2002-07-03 21:51:09 +0000
raph <raph@ded80894-8fb9-0310-811b-c03f3676ab4d>
cdac7ee4efe0e16a97c2d564af1b59b60f66e2d3

> Fix image compositor. Code is not beautiful, but works.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@103 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_image.c

2002-07-03 19:54:43 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
f4a16df4d230a900f2068a268103184da90097e4

> checkpoint compositor development
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@102 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_image.c

2002-07-03 19:43:21 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
a6820e140bc4b306fb7852ae4994bf6d38f2a906

> As per raph's suggestion, switch to byte-wise addressing for the image data.
> It solves some endianness problems, and saves a significant amount of memory
> since page and pattern dictionaries contain many small (< 32 pixels wide)
> images.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@101 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2.h
> jbig2_image.c
> jbig2_image_pbm.c

2002-07-03 14:56:15 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
55a01f747fb2b992f7b777f1a2d7ee8cac1e13af

> Compositors now producing reasonable-looking output.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@100 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_image.c

2002-07-03 00:55:44 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
6b872950543e8b6179b301da282baed48ddd6a67

> checkpoint commit of compositor.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@99 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_image.c

2002-07-03 00:30:20 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
154b1f71742acab16d9106796cede9c3f12a65c8

> Oops. Previous stride calculation was correct.
> Also remove obsolete png test code.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@98 ded80894-8fb9-0310-811b-c03f3676ab4d
> Makefile.am
> jbig2_image.c
> jbig2_image_png.c

2002-07-03 00:10:07 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
3b182de2e206756ddcdd715d8f561273f75a62c2

> We've been using (and want) the image stride in bytes, not words.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@97 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2.h
> jbig2_image.c

2002-07-03 00:08:40 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
a5f7064637d1d9efe7c0a0920d81f70f99c6d456

> #ifdef the debug fprintf()s. comment cleanup. actually transpose on TRANSPOSED.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@96 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_text.c

2002-07-01 19:34:31 +0000
raph <raph@ded80894-8fb9-0310-811b-c03f3676ab4d>
6c52ccfe9970dc5b709c378d49187ebb2874aa81

> Text region decoding now seems to decode 042_10.jb2 correctly. Added
> IAID decoding procedure. Changed jbig2_decode_text_region to use IAID
> procedure. Fixed off-by-one errors in corner alignment calculations.
> Added for (;;) loop for 3c, corresponding to looping over all symbol
> instances in a strip (outer while loop corresponds to looping over all
> strips in the region). Fixed predicates in CURS updating logic.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@94 ded80894-8fb9-0310-811b-c03f3676ab4d
> Makefile.am
> jbig2_arith_iaid.c
> jbig2_arith_iaid.h
> jbig2_text.c

2002-06-27 14:02:08 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
91c71a44412a052616c45f6e50a0431a103514a8

> checkpoint in-progress text decoder. close but no data yet.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@93 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_text.c

2002-06-24 23:28:13 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
ef06d243c1a26abd9223181b8c5751ceb051258e

> another checkpoint of text region decoding work. referred-to segment info is correct now.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@92 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2.c
> jbig2_priv.h
> jbig2_segment.c
> jbig2_text.c

2002-06-24 19:09:47 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
5613e3f978e406268fe5c42b7da322c0e4bfa7a9

> checkpoint in-progress text region decoding procedures
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@91 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_symbol_dict.c
> jbig2_text.c

2002-06-24 18:44:45 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
a6752fd2a6859efeabbb29954d5b5d34ec0eb96b

> use the correct number of bytes in reading the referred-to segment numbers. (still untested)
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@90 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_segment.c

2002-06-24 18:40:01 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
6cb5f391cd0ec8bdc0485780697793b71004429c

> Save referred-to segment numbers. (untested)
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@89 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_segment.c

2002-06-24 15:51:57 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
fcc43c7fb7d236c2c30a2b9eba5fdd52bb84f56a

> checkpointing work on text region decoder.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@88 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_generic.c
> jbig2_image.c
> jbig2_priv.h
> jbig2_symbol_dict.c
> jbig2_text.c

2002-06-22 21:20:38 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
468a9f35baa5c64f3be49f60ba800f72dba501ef

> Store the decoded symbol dictionary in the result field of the corresponding
> segment.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@86 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_symbol_dict.c
> jbig2_symbol_dict.h

2002-06-22 16:05:45 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
f2ac7803db2d376bab0734f3e7629faea7bc7297

> Gratuitous renaming. Promote the segment header to Jbig2Segment and use it
> to store intermediate results rather than the results objects raph had sketched.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@84 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2.c
> jbig2.h
> jbig2_generic.c
> jbig2_generic.h
> jbig2_mmr.c
> jbig2_mmr.h
> jbig2_page.c
> jbig2_priv.h
> jbig2_segment.c
> jbig2_symbol_dict.c
> jbig2_symbol_dict.h
> jbig2_text.c

2002-06-22 10:08:43 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
7fc72d14be2af5e15866a9124a99b6dafea65dcd

> Treat seg_idx=-1 specially in the error callback, since we're using that for
> cases where the segment number is inappropriate or not available.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@83 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2dec.c

2002-06-22 09:58:26 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
8384a640605066b60d21140504f92d31dd77947f

> Interpret '-' as an output filename meaning stdout.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@82 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2dec.c

2002-06-22 09:47:31 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
72591b23f58efc91e6b92b85540825f29344d520

> remove the redundant width and height fields from Jbig2GenericRegionParams
> in favor of the dimensions of the passed Jbig2Image
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@81 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_generic.c
> jbig2_generic.h
> jbig2_symbol_dict.c

2002-06-21 23:11:29 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
8f1012147073d64f79de947930f1ac6b4fca959a

> restore original behavior for -DOUTPUT_PBM
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@80 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_symbol_dict.c

2002-06-21 22:56:54 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
30beab7a07268fe5ccd204fdc621a7fee3489e8f

> Update decode_symbol_dict() to use images, fixing a type-related bug from the earlier changes.
> Report debug messages through the official mechanism.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@79 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_symbol_dict.c

2002-06-21 22:54:03 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
69b79684b3f800c7e22dcd16a1fd28a33d067e92

> remove dead code
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@78 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_symbol_dict.c

2002-06-21 19:11:28 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
acf706d0e91ebcf8b3d73c83d168af6e2de05a25

> remove dead code
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@77 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2dec.c

2002-06-21 19:10:02 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
123697184141b211dfd599a1fb2eb94e8079ce5e

> Generic regions decode into Jbig2Image structures, which are then (trivially)
> composited with the page buffer as the final step in handling the segment.
> We now write the page data out at out.png or out.pbm. Compile with -DOUTPUT_PBM
> for the old behavior.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@76 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2.h
> jbig2_generic.c
> jbig2_generic.h
> jbig2_image.c
> jbig2_image_pbm.c
> jbig2_mmr.c
> jbig2_mmr.h
> jbig2_page.c
> jbig2_priv.h
> jbig2dec.c

2002-06-20 15:42:48 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
ed23b26857f9d5324a52730e7504c1a14a2d3161

> Beginnings of text segment handling. Parse (most of) the text region
> segment header. Move the region segment info parser to jbig2_segment.c
> and jbig2_priv.h since this is shared by all region segment types.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@75 ded80894-8fb9-0310-811b-c03f3676ab4d
> Makefile.am
> jbig2_generic.c
> jbig2_priv.h
> jbig2_segment.c
> jbig2_symbol_dict.c
> jbig2_text.c

2002-06-20 15:40:36 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
22320087293f0de716d1e214ee74e1e1da822234

> Fix a precedence bug which prevented using the first page structure.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@74 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_page.c

2002-06-18 13:40:29 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
0cad58a5a6857aebb665c79706ba33acabc550fd

> Handle 'page info' segments, and allocate an image buffer based on the page size.
> also adds hooks for final compositing and output of the page buffer.
> in addition, minor code massage and dead code removal; make the image structure
> public.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@72 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2.c
> jbig2.h
> jbig2_image.h
> jbig2_page.c
> jbig2_priv.h
> jbig2_segment.c
> jbig2dec.c

2002-06-18 09:46:45 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
033b9666bac46060559b74b2f2a620fde5fc7f32

> Add warnings for remaining unhandled segment types. remove dead code.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@71 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_segment.c

2002-06-17 21:11:51 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
867871515b0d0bce9d092e66a1a787b45681ad76

> add prototypes for segment header routines
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@70 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2.h

2002-06-17 21:06:38 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
5219d82fa11b750c446a1d00d2bc269cea245610

> Further segment code rearrangement. Add some comments and promote some bitwise types to unsigned. Also add some diagnostic messages on segment type.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@69 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2.c
> jbig2_segment.c

2002-06-17 16:30:20 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
dcb620344060d47d77e620d23c0e3e6aa3838f6b

> Update the image routines to use the ctx structure for dynamic memory and remove the test framework.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@68 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_image.c
> jbig2_image.h
> jbig2_image_pbm.c

2002-06-17 13:27:07 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
f46505e1adb56bcac9bbf00ec8b264dc50963764

> add some autotools files to .cvsignore
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@67 ded80894-8fb9-0310-811b-c03f3676ab4d
> .cvsignore

2002-06-15 16:16:20 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
559870f8c41c8e7741035e28801cf6f8a911bd25

> actually add the segment header source
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@66 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_segment.c

2002-06-15 16:02:56 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
c47c3b08840eb8e709fad19c018845d2ec00087d

> add segment routines in a separate file. prune the semi-dead jbig2dec.h in
> favor of jbig2.h and jbig2_priv.h. Update to C99 fixed-width types.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@64 ded80894-8fb9-0310-811b-c03f3676ab4d
> Makefile.am
> jbig2.h
> jbig2_huffman.c
> jbig2_huffman.h
> jbig2_hufftab.h
> jbig2_image.c
> jbig2_image_pbm.c
> jbig2_image_png.c
> jbig2_page.c
> jbig2_page.h
> jbig2_priv.h
> jbig2dec.c
> jbig2dec.h

2002-06-15 15:47:21 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
2dce5e044ea710e68b1716ca543800c64ad633aa

> Add -lpng to LIBS when the png library is available.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@63 ded80894-8fb9-0310-811b-c03f3676ab4d
> configure.ac

2002-06-15 14:15:12 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
57c5cda834b84dbec0f4898427bf4283dc2c327d

> Add page segment parse and dump routines.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@62 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_page.c
> jbig2_page.h

2002-06-15 14:12:50 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
e22ae8f124c9ed5a3ccadbad3a302285d94ffc4c

> minor code rearrangement and comments
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@61 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2.c
> jbig2_symbol_dict.c
> jbig2_symbol_dict.h
> jbig2dec.c

2002-06-05 00:15:57 +0000
raph <raph@ded80894-8fb9-0310-811b-c03f3676ab4d>
43bf50d093b48ad481fc24656b66d34422ac07dc

> Brings code into line with spec. This fixes the SOFTWARE_CONVENTION case
> as well. Thanks to William Rucklidge for spec clarification.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@60 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_arith.c

2002-06-05 00:03:49 +0000
raph <raph@ded80894-8fb9-0310-811b-c03f3676ab4d>
8055e400b7d9b32c355e8c7dc2cf286a59dc1ece

> Fixes bug in arithmetic integer decoding procedure. Thanks to William
> Rucklidge for providing trace data to help track down the problem.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@59 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_arith_int.c

2002-06-04 16:51:02 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
2d6d6e0c7b2c97e52a3363eae09841a17fe8e272

> Add pbm import support and a simple 'pbm2png' implementation as a test harness for the image code. No makefile support--just didn't want to lose the code.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@58 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_image.h
> jbig2_image_pbm.c
> pbm2png.c

2002-06-04 16:47:09 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
f508fadb8bfad2296ff963203183ea25ec6d8080

> add some description of the decoder commandline options
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@57 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2dec.c

2002-05-09 02:29:10 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
693e8b2190c36a706b8b5de4bc3771d8d0acbcd3

> add getopt implementation for portability to systems w/o getopt_long()
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@55 ded80894-8fb9-0310-811b-c03f3676ab4d
> getopt.c
> getopt.h
> getopt1.c

2002-05-08 03:03:18 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
04d17fa29806f730e03290b7ab4ee415600ba9e7

> Code cleanup and rearrangement.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@54 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_mmr.c
> jbig2_symbol_dict.c
> jbig2dec.c

2002-05-08 02:36:04 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
42ead910c9d9d4e3f6dd69e91be16f5de42ffef7

> Rename the png output source files, and add pbm output support. Also allow
> writing to a FILE* instead of a filename so we can send things to stdout, etc.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@53 ded80894-8fb9-0310-811b-c03f3676ab4d
> Makefile.am
> jbig2_image.c
> jbig2_image.h
> jbig2_image_pbm.c
> jbig2_image_png.c
> png_image.c
> png_image.h

2002-05-08 02:28:02 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
0459e440350325b04aaa0bd1f70120ce1066716b

> add autotools files to .cvsignore
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@52 ded80894-8fb9-0310-811b-c03f3676ab4d
> .cvsignore

2002-05-08 02:27:29 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
f12873269a2ab271026afa7640bbba2a73a6a5a7

> Autoheader and configure fixups.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@51 ded80894-8fb9-0310-811b-c03f3676ab4d
> configure.ac

2002-05-08 00:59:20 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
ab76b7e32ea5c79915b5ebe94a84ae8b4b29ee78

> Rought autotools support.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@50 ded80894-8fb9-0310-811b-c03f3676ab4d
> Makefile.am
> autogen.sh
> configure.ac
> makefile

2002-04-25 23:24:35 +0000
raph <raph@ded80894-8fb9-0310-811b-c03f3676ab4d>
0f218050d34326a38a89f07e772a7c4fc350fb10

> Makefile changes to add jbig2_mmr functions.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@49 ded80894-8fb9-0310-811b-c03f3676ab4d
> makefile

2002-04-25 23:24:08 +0000
raph <raph@ded80894-8fb9-0310-811b-c03f3676ab4d>
971100aa3b5f56756fbd31a03ca4212209881f09

> Adds partial support for mmr (CCITT 2D fax) decoding. This commit can
> scan Huffman codes, but does not apply the logic to produce run lengths.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@48 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_generic.c
> jbig2_mmr.c
> jbig2_mmr.h
> jbig2_symbol_dict.c

2002-03-28 08:28:02 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
98a2ac892b58569ae1a5a258c0b502fbf56da0b4

> basic getopt-based commandline parsing
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@47 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2dec.c

2002-02-19 07:09:16 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
ef36831c93670a262622d3acad6a208d73d1d81e

> simple code cleanup. add license headers, include jbig2dec.h with dead code.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@46 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2.h
> jbig2_generic.c
> jbig2_generic.h
> jbig2dec.c
> jbig2dec.h

2002-02-19 05:48:44 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
5d215388772fd0c2931cdc4cafca74c1256bfea6

> Abstract the compiler command.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@45 ded80894-8fb9-0310-811b-c03f3676ab4d
> makefile

2002-02-16 07:25:36 +0000
raph <raph@ded80894-8fb9-0310-811b-c03f3676ab4d>
625abbded569d5ffde7301d497158b0116313f21

> Lots of changes: Added template 0 generic decoder. Added "results"
> mechanism to Jbig2Ctx for storing the decoded results, but not yet
> any segments which store their results there. Changed generic region
> API slightly so callers could pass in more context (needed for
> generic region decoding other than generic). Added arithmetic integer
> decoder. Started symbol dictionary decoder. Currently, this decodes
> about 200 symbols from the cvision global dict, then goes haywire.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@43 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2.c
> jbig2_arith.c
> jbig2_arith.h
> jbig2_arith_int.c
> jbig2_arith_int.h
> jbig2_generic.c
> jbig2_generic.h
> jbig2_priv.h
> jbig2_symbol_dict.c
> jbig2_symbol_dict.h
> jbig2dec.c
> makefile

2002-02-15 20:46:30 +0000
raph <raph@ded80894-8fb9-0310-811b-c03f3676ab4d>
107138382e590d3851ba1b5e897a33f2cf27ee4b

> A good start at generic region decoding. The added jbig2_generic code
> handles GBTEMPLATE=1 with vanilla options and the adaptive template
> pixels in their nominal locations. This is sufficient to successfully
> decode the 042_4.jb2 test stream.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@42 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2.c
> jbig2_arith.c
> jbig2_generic.c
> jbig2_generic.h
> jbig2_priv.h
> makefile

2002-02-13 08:47:18 +0000
raph <raph@ded80894-8fb9-0310-811b-c03f3676ab4d>
0a9304dad738268b27556717bf83936c15618506

> Implementation of new API as discussed on jbig2-dev. Not all logic
> of existing jbig2dec.c has been ported to new codebase - in
> particular, jbig2_read_symbol_dictionary and jbig2_read_page_info.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@41 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2.c
> jbig2.h
> jbig2_priv.h
> jbig2dec.c
> jbig2dec.h
> makefile

2002-02-12 02:19:36 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
3a77ab1dd49743f0ed9cc0ad862671f462781bd1

> 'normalize' formatting.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@40 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2dec.c

2002-02-12 02:19:08 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
a2eca8001a79d7df3c848139519bf7b7b9778113

> Standard protection against multiple and C++ inclusion.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@39 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2dec.h

2002-02-10 01:17:26 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
ce1259d7b14345427766fb5c541b41b2c5e1f203

> Update usage to reflect the embedded stream mode.
> Normalize formatting :)
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@38 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2dec.c

2002-02-09 22:31:53 +0000
raph <raph@ded80894-8fb9-0310-811b-c03f3676ab4d>
f0780d5ad41298cf609f8e27d869c534dbcdaa23

> Adds some support for "embedded" format, with separate global and page
> streams. Also fixes some minor bugs.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@37 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2dec.c

2001-08-13 20:31:59 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
30034932cea9e2e37d781763d36b06607b8337be

> Fix image stride calculation, and generate a simpler (checkerboard) test pattern.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@36 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_image.c
> png_image.c

2001-08-13 19:51:16 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
595741f11dc91377adf4093b88abccb5b1b30660

> one-line readme
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@35 ded80894-8fb9-0310-811b-c03f3676ab4d
> README

2001-08-13 19:50:52 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
e42dde61dd9441585efa5874880b1c42dc90687c

> start of a .cvsignore
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@34 ded80894-8fb9-0310-811b-c03f3676ab4d
> .cvsignore
> jbig2_hufftab.h

2001-08-11 06:46:15 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
b82c5a1be026e14a63c6e3ede436acf9590a7610

> png output now compiles
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@33 ded80894-8fb9-0310-811b-c03f3676ab4d
> makefile
> png_image.c

2001-08-10 23:29:28 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
7181b7a84184562ccf72e34c11f75b158b58e61b

> initial image buffer and png output routines
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@32 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_image.c
> jbig2_image.h
> makefile
> png_image.c
> png_image.h

2001-07-05 22:37:44 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
15fbf3afe60b17b958fd38ed902ddae67554f804

> more general huffmann test routine
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@31 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_huffman.c

2001-06-26 00:30:00 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
678523a15572456b68612fafc422d4dee29ca59c

> move the huffman tables to a separate header
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@30 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_huffman.c
> jbig2_huffman.h
> jbig2_hufftab.h
> jbig2dec.c

2001-06-14 23:09:23 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
47a138b6362c314be4cfd91977ac61b3cf772e0f

> complain if the file uses the 'random access' layout which we don't handle yet.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@29 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2dec.c

2001-06-14 08:25:01 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
83513ef82b18de95374d8e6c229658735d76af32

> attempt to skip the right number of bytes in long-form segment references.
> attempt to read long page association fields properly. both untested.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@28 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2dec.c

2001-06-12 23:35:53 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
f1a9f2cddd17bc53e0b3952b5f05c7427a493ba7

> added parser for the page info segment
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@27 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2dec.c

2001-06-12 09:56:33 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
8a02a862c8fa9f0bb5def02e5ea9ccc1414dabe6

> added complete list of segement types to dump_segment()
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@26 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2dec.c

2001-06-12 09:15:13 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
d498a8c2f375315c2de3c62ea270e447bf0bde44

> make get_next_word return uint32
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@25 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2dec.c
> jbig2dec.h

2001-06-12 09:09:04 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
f77dcdbe70ec1ba574ba25c37de81dfaf27ebc52

> more general huffmann test code, borrowing from the arith version.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@24 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_huffman.c

2001-06-10 08:43:48 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
bfc0107419650f5f696115c4accf1ab88b923c43

> minor comment update
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@23 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_huffman.c

2001-06-10 07:15:10 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
c5b572ab3f1e3a243408b84498bb7d7dce808b71

> added 'make clean' target
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@22 ded80894-8fb9-0310-811b-c03f3676ab4d
> makefile

2001-06-10 07:09:18 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
d9367f7452f9117ce3a7f7649966cb42a2c33995

> added copyright statements to the source files
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@21 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_arith.c
> jbig2_arith.h
> jbig2_huffman.c
> jbig2_huffman.h
> jbig2dec.c
> jbig2dec.h

2001-06-10 07:03:08 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
a2cb3337c3f559fc65d3122d649386c797fbc949

> updated includes for the jbig2dec.h name change
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@20 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_arith.c
> jbig2_huffman.c
> jbig2dec.c
> makefile

2001-06-10 06:50:58 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
4369688dfbf2235ed466f38af4ddd11ab781ceaf

> renamed jbig2.* to the more eponymous jbig2dec.*
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@19 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2.c
> jbig2.h
> jbig2dec.c
> jbig2dec.h

2001-05-31 06:23:32 +0000
raph <raph@ded80894-8fb9-0310-811b-c03f3676ab4d>
9cd558cd34c857cb3fc15167a754d1619ecc57d3

> Fixed API so that context is now an argument to the arithmetic decode
> procedure. Context is also now packed into a byte, and context changes
> are done with a single xor.
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@18 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_arith.c
> jbig2_arith.h
> makefile

2001-05-30 21:36:25 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
fa37e9a7b8c933da66c2850a22c10559f38c68bb

> added GPL license
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@16 ded80894-8fb9-0310-811b-c03f3676ab4d
> COPYING

2001-05-30 21:05:43 +0000
giles <giles@ded80894-8fb9-0310-811b-c03f3676ab4d>
df5789c4fe4bc7085bac37a70e630c326ffd3965

> add missing stdio include
> git-svn-id: http://svn.ghostscript.com/jbig2dec/trunk@15 ded80894-8fb9-0310-811b-c03f3676ab4d
> jbig2_arith.c

2012-09-08 09:58:53 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
faac14fb1532533a811649cef2b68cf95ec50fdf

> Bug 693291: Quote shell variables to support spaces in path.
> gs/base/configure.ac

2012-08-10 09:27:00 +0100
Ken Sharp <ken.sharp@artifex.com>
7254338bbdcc9b80805c644712edd5d24b781fcb

> pdfwrite - linearisation.
> First attempt to make pdfwrite emit linearised PDF. THis basiclaly works
> but needs some attention to the shared object table, and memory cleanup
> still needs to be done.
> pdfwrite - linearisation project, ma ny changes
> Alter rewrite_object to parse the object and alter teh numbers of any objects which it
> references
> modify rewrite_object to record the offset of the nely rewritten object in the
> linearised file, so we cna later write an xref.
> Numerous 'off by 1' bug fixes relating to object 0 and whether pages are
> numberd from 0 or not.
> Write all pages and their objects, and shared objects, in the correct order.
> Write a primary xref table.
> Record CharProc resource usage by fonts.
> pdfwrite - linearisation code
> Add code to rewrite the secondary xref with the actual offsets of the objects
> Write a dummy primary hint stream
> Record the offsets of the primary hint stream and linearisation dictionary.
> pdfwrite - linearisation
> It turns out that for the hint stream we need to know which objects are used
> on every page (shared or not).
> This change laters the record for each resoruce to add an array of integers
> documenting which page(s) the resource is used on, as well as whether it is
> shared or not and so on.
> This means that instead of a simple chunk of memory, the record is now a gc
> object, properly tracked and relocated and so on.
> Added code to track the location of some more objects in the linearised file,
> for the benefit of the linearisation dictionary.
> Added code to rewrite the linearisation dictionary with the final numbers, and the trailer dict with the correct numbers too.
> pdfwrite - linearisation various changes
> Remove some unused variables to silence compiler warnings
> Sort out the object numbering so that the seocond page is object
> number 1 (this is a requirement, but its not obvious in the spec). Make sure
> the 'part 9' objects (Info dict, metadata etc) have number that start after
> all the page objects, unique objects per page, and shared objects.
> Move the hint stream generation so that the hint stream is *after* page 1 and its
> resoruces as this is easier to deal with.
> pdfwrite - linearisation work
> preparing to write hint streams:
> first we go back to using a temp file instead of a specific filename (except
> when explicitly debugging).
> second we only reorder the existing objects and the linearisation dict.
> next we copy these re-oredered objects from the temp file, and insert the
> dummy primary hint stream at the correct location.
> Finally we write the primary xref, but taking the size of the inserted hint stream
> into account for the offsets.
> In a fit of tidying up, use gp_fseek_64 instead of fseek. Still work to do here.
> pdfwrite - linearisation
> add preliminary code to write a hint stream (still needs work)
> Fix code which wrote teh page object twice for each page.
> Various white space tweaking to make the output closer to the MuPDF output
> in an abortive attempt to find out why files are not identified as linearised
> by Acrobat
> pdfwrite - linearisation, make files at least 4k
> I don't believe it.....
> Acrobat won't recognise a file as linearised unless it is at least 4k!
> Also added some comments regarding various implementation notes from the
> 1.7 reference
> pdfwrite - linearisation, move code into a routine of its own
> Modularise the linearisation code somewhat by making it a new routine
> instead of bloating pdf_close still further.
> pdfwrite - linearisation, fixes for hint writing
> gs/base/gdevpdf.c
> gs/base/gdevpdfb.h
> gs/base/gdevpdfx.h
> gs/base/gdevpdti.c

2012-08-09 12:24:49 +0100
Ken Sharp <ken.sharp@artifex.com>
b16e0ada5e05737890e5bc340fdb181715ca4794

> Fix the allocation of teh Offsets table so that it doesn't get overrun while
> storing xrefs.
> gs/base/gdevpdf.c

2012-08-09 12:15:57 +0100
Ken Sharp <ken.sharp@artifex.com>
e6a0ca2b94e4a80d02c2b85044b613d92d416249

> fix the size of LastResource so that the Offsets table is large enough to hold all the objects
> gs/base/gdevpdf.c

2012-08-09 11:30:45 +0100
Ken Sharp <ken.sharp@artifex.com>
b085cd2bb5f95fdf842ad05615e9f411b823d79a

> Temporary commit for linearisation code in pdfwrite
> gs/base/gdevpdf.c
> gs/base/gdevpdfb.h
> gs/base/gdevpdfe.c
> gs/base/gdevpdfp.c
> gs/base/gdevpdfu.c
> gs/base/gdevpdfx.h
> gs/base/gdevpdtd.c
> gs/base/gdevpdtd.h
> gs/base/gdevpdtw.c

2012-09-05 20:03:34 -0700
Michael Vrhel <michael.vrhel@artifex.com>
c26a59a07d226db58c2952aeab65df4d58ee78c2

> Make sure overprint works with shading pattern. Fix for Bug 693018
> For some reason it was believed that overprint was not used with shading patterns
> and so it was disabled. Also had to make sure that the graphic state stored in
> the pattern instance was all up to date with the overprint state.
> gs/base/gsptype2.c

2012-08-17 12:43:55 -0700
Michael Vrhel <michael.vrhel@artifex.com>
1ab39e3d51a4d4fc78bd2532ef7141a57db50149

> Enabling of fast threshold code for color source images as well as monochrome images to cmyk devices
> Many cases where we could be using the fast thresholding code were disabled due to issues that this
> commit fixes. Some items such as the conversions to planar when the color management transform was
> the identity were not in place. In addition, for subtractive devices, the polarity of the threshold
> array was wrong.
> gs/base/gsht.c
> gs/base/gsicc_nocm.c
> gs/base/gxht_thresh.c
> gs/base/gxht_thresh.h
> gs/base/gxicolor.c
> gs/base/gxidata.c
> gs/base/gximage.h
> gs/base/gximono.c
> gs/base/gxipixel.c

2012-09-04 10:04:26 -0700
Michael Vrhel <michael.vrhel@artifex.com>
4e7d82066d92d4a4a2709c5dde4c35a4521d029e

> Add overprint support into the pdf14 device group composing
> This fixes Bug 693300. This this file had two images. One in a separation color space,
> the other an RGB color space each in their own transparency group.
> Overprint mode was enabled during the spot image drawing, which occurs after the RGB image is drawn.
> During the group pop, there was no code in pdf14_compose_group to account for the overprint condition
> gs/base/gdevp14.c
> gs/base/gsovrc.c
> gs/base/gxblend.h
> gs/base/gxblend1.c

2012-09-03 18:44:22 -0700
Ray Johnston <ray.johnston@artifex.com>
23796278944b89b2afe2906cb0f725e9c6c8ce11

> Fix clist_copy_planes to insure that all planes written together. Bug 693234.
> The code at 'copy:' checked to make sure that the planes would fit in a
> single cbuf, but did not check to make sure that all of the planes fit in
> the remaining space in the BufferSpace from 'cnext' to 'cend'. The fix is
> to call cmd_write_buffer if all planes don't fit in the current BufferSpace
> so that an 'end_run' byte will not be inserted in the data stream.
> gs/base/gxclrect.c

2012-09-04 13:37:28 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
c62f5a9f5ead465c1d0fbf2826ba5a00b48a1fdb

> Fix all GCC warnings in Luratech JPX interface.
> gs/base/sjpx_luratech.c

2012-08-29 16:19:55 +0100
Chris Liddell <chris.liddell@artifex.com>
40c3e3f2b337d5aad89d49dd9f56bfedf6bcf5e5

> Remove dependence on jbig2dec auto-generated files
> Also provide a workaround for LCMS2 on systems without sqrtf().
> No cluster differences
> gs/base/Makefile.in
> gs/base/configure.ac
> gs/jbig2dec/Makefile.in
> gs/jbig2dec/aclocal.m4
> gs/jbig2dec/compile
> gs/jbig2dec/config.guess
> gs/jbig2dec/config.h.in
> gs/jbig2dec/config.sub
> gs/jbig2dec/config_types.h.in
> gs/jbig2dec/configure
> gs/jbig2dec/depcomp
> gs/jbig2dec/install-sh
> gs/jbig2dec/ltmain.sh
> gs/jbig2dec/missing
> gs/jbig2dec/mkinstalldirs
> gs/jbig2dec/os_types.h
> gs/jbig2dec/snprintf.c
> gs/jbig2dec/stamp-h1

2012-09-03 20:44:43 -0700
Michael Vrhel <michael.vrhel@artifex.com>
26d8aeede6ce52c5a31720980cfcd096f6bd9f10

> Another softmask memory leak fixed for Bug 693312
> Leak was caused by the improper freeing when we have a soft mask created in a band
> where it was not needed.
> gs/base/gdevp14.c

2012-09-03 21:58:34 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
50ed871322720a7e0a01bf7e52509b77529c105e

> Bug 693317: ignore multiple tokens between obj and endobj
> Detect malformed objects that parse as multiple tokens, replace
> the tokens with null, and issue a warning.
> gs/Resource/Init/pdf_base.ps

2012-09-03 07:55:32 -0700
Michael Vrhel <michael.vrhel@artifex.com>
e37fa70cb16f286ad00b5573e6d548066d2c913e

> Fix for memory leak in pdf14 softmask stack. Bug 693312
> When a new mask was getting created, it was possible that the stack was already set up with
> softmasks. When blowing away the old mask we need to make sure to go through and clean up
> the stack.
> gs/base/gdevp14.c

2012-08-30 08:10:41 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
7ade6182ba16cbaf3084a1c9865f265cdd71525f

> Bug 692849: Prevent memory corruption by using temp buffer in CCITT decompression.
> pcl/rtraster.c

2012-08-27 10:12:04 -0600
Henry Stiles <henry.stiles@artifex.com>
4bc9598dbefcda47a483ea489409af412467d07f

> Remove obsolete call to set the path mode. This is now only enable on
> a per graphic basis as needed.
> CLUSTER_UNTESTED
> pcl/pctop.c

2012-08-25 22:02:06 -0700
Ray Johnston <ray.johnston@artifex.com>
11bb4d6d57ea1a65b254e3013f5d16f406457793

> Fix another warning detected by Visual Studio (negating an unsigned int).
> gs/base/gxfcache.h

2012-08-25 18:21:28 -0700
Ray Johnston <ray.johnston@artifex.com>
f939737f2e6479b815de40f46c20b07f40241124

> Get rid of const warnings with Visual Studio.
> There are still warnings, but at least the ones that are easy to fix
> are now gone.
> gs/base/gdevdevn.c
> gs/base/gdevdevn.h
> gs/base/gdevdsp.c
> gs/base/gdevmpla.c
> gs/base/gdevp14.c
> gs/base/gxblend.c
> gs/base/gxclip.c
> gs/base/gxipixel.c
> gs/base/gxpcmap.c
> gs/base/gxshade.c
> gs/psi/zcie.c

2012-08-25 18:18:06 -0700
Ray Johnston <ray.johnston@artifex.com>
bac3f4be13b133b0c097a6ec426894ddc491f2e0

> Change TILE_TYPE_MASK size to avoid a truncation warning from VS.
> The value 0x80000000 is problematic for the enum with Visual Studio.
> The TilingType values are from 1 to 3, so 3 bits is plenty.
> gs/base/gsptype1.c

2012-08-25 15:15:38 -0700
Ray Johnston <ray.johnston@artifex.com>
6b12966f995393edb220c4b7bc94bc6eeef48987

> Change hpgl_path_mode to 'bool' (and hpglpathmode PS operators).
> In cleaning up some of the type mismatch warnings with VS, this
> needed to be consistent. There are no current users of the PS
> operators, but now these are <bool> .sethpglpathmode - and
> .currenthpglpathmode <bool>.
> gs/base/gsstate.c
> gs/base/gsstate.h
> gs/psi/zgstate.c

2012-08-24 19:03:34 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
d840d02d5fd655c397b08e01a273a4e4e757f96e

> Bug 692604: improve error messages for invalid arguments.
> Inclide the invalid argument in the error message. Suggest to use -s
> instead of -d when the token is an executable name. Most likely,
> the user just tried to define a string.
> gs/psi/imainarg.c

2012-08-24 15:29:21 +0100
Chris Liddell <chris.liddell@artifex.com>
1e6c15fa2ee91c760943a3edd16e123f6879eb45

> Bring ghostpdl in-line with jbig2dec
> No cluster differences.
> gs/jbig2dec/Makefile.am

2012-08-24 01:47:45 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
ebe054e32a88a5ea4a52367066f8a8259dd3d5db

> Bug 693299: fix handling of array form of /FilterParms in pdfopt
> Array form of /FilterParms attribute was processed like a dictionary,
> smashing the stack, and causing a PS error later.
> gs/lib/pdfopt.ps

2012-08-22 12:26:33 -0700
Ray Johnston <ray.johnston@artifex.com>
bb15658bdf6b463e62b34e1c3fa779942fa24902

> Fix clist probelms with copy_planes, writer and reader out of sync.
> When uncompressed data was written to the clist with height > 1,
> the last line was not padded. The reader was reading as if all
> lines had the padding. Also fixed cmd_read_short_bits to skip
> the memmove in cases where width_bytes == raster or height == 1.
> gs/base/gxclrast.c

2012-08-23 15:12:13 +0100
Robin Watts <robin.watts@artifex.com>
0279e3ba6819d41a36125fba934aba489e03617b

> Bug 693298; Memento build tweak for memset.
> Don't define memset if someone else has already #defined it. Thanks
> to William Bader.
> gs/base/memento.c
> gs/jbig2dec/memento.c

2012-08-23 15:01:03 +0100
Robin Watts <robin.watts@artifex.com>
2dba4f48cfe258c957da2754547fe22a5cc764f6

> Fix broken Windows build with patch fb55f251.
> This is an extended version of a commit from Ray, fixing a mistake
> that I made. Ray's original version didn't make it into the repo
> due to git problems.
> Initialising a struct to { } doesn't work with VS. { 0 } is OK.
> gs/base/gsptype1.c
> gs/base/gxcht.c
> gs/base/gxclist.c
> gs/psi/iinit.c
> gs/psi/zmisc2.c

2012-08-23 14:59:05 +0100
Robin Watts <robin.watts@artifex.com>
04a0440368a18978049b999722320cbc850c7621

> Revert "Move memento include from jbig2.h to jbig2_priv.h"
> This reverts commit b6dc615180c04d016c6df4e9e7598a0d7c9df02b.
> This broke the memento build of gs due to the #defining of
> free/realloc. For now, we'll have to live with the include
> in the public header.
> gs/jbig2dec/jbig2.h
> gs/jbig2dec/jbig2_priv.h

2012-08-23 13:34:43 +0100
Robin Watts <robin.watts@artifex.com>
b6dc615180c04d016c6df4e9e7598a0d7c9df02b

> Move memento include from jbig2.h to jbig2_priv.h
> There is no need to expose memento outside of jbig2. Thanks to
> zeniko for the discussion in bug 693284 that lead to this.
> gs/jbig2dec/jbig2.h
> gs/jbig2dec/jbig2_priv.h

2012-08-23 02:10:20 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
2740bef445c51680d831ec40753436291f01760a

> Bug 693268: reinstate big references.
> To make big references compatible with 8-byte alignment on 32-bit Windows
> force ref structure to take 16 bytes by adding a dummy uint64_t member
> to the union.
> gs/psi/iref.h

2012-08-23 00:00:31 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
eb62043f520985f28ccaf265258ddb31cee79e1e

> Get rid of staticly allocated pseudo-references.
> Replace staticly initialized pseudo-references with C strings to
> simplify experiments with reference sizes.
> gs/Resource/Init/gs_init.ps
> gs/Resource/Init/gs_res.ps
> gs/psi/iconf.c
> gs/psi/iconf.h
> gs/psi/imain.c
> gs/psi/imainarg.c

2012-08-22 11:20:24 -0700
Robin Watts <robin@peeves.(none)>
1e53dc6b19a96abed3b4a10c12a284d096b37701

> More PACIFY_VALGRIND magic
> While working on bug 693278, valgrind was showing use of
> uninitialised values. This turns out to be (in part) due to the
> clist recording the padding in bitmaps (which can be uninited).
> The PACIFY_VALGRIND magic added here allows this file to run valgrind
> clean.
> gs/base/gsptype1.c
> gs/base/gxcht.c

2012-08-22 09:19:39 -0700
Robin Watts <robin@peeves.(none)>
20adaa4a395059c3234c5b49979dc21f70e95bbf

> Add some PACIFY_VALGRIND stuff for refs.
> Seen while investigating bug 693278.
> gs/psi/iinit.c
> gs/psi/zmisc2.c

2012-08-22 03:43:09 -0700
Robin Watts <robin@peeves.(none)>
fb55f251b06fbfdf40cad66432369c4b09aa7627

> Add code to mask harmless valgrind warnings in DEBUG or PACIFY_VALGRIND builds
> Spotted while investigating bug 693278.
> gs/base/gsptype1.c
> gs/base/gxclist.c

2012-08-21 11:44:46 -0700
Robin Watts <robin@peeves.(none)>
69727555e1ff7be4f0af4d8b79f33408181d25ba

> Bug 693278: SEGV in 09-50.PS - bad enumeration of device colors
> Masked device colors were all being enumerated as if they were
> binary halftones. Colored halftones need to be handled differently
> and this was causing this problem. It looks like devn device colors
> should also be handled differently, so changed here too.
> gs/base/gsptype1.c

2012-08-20 15:16:18 +0100
Robin Watts <robin.watts@artifex.com>
d527eade5778811475ea8be4cbba4eeec573b28a

> Big 693272; fix SEGV due to optimised interpolation.
> When calculating the leftmargin to skip over due to the clipping
> region, we were failing to allow for the fact that dst_width might
> be negative due to an image being horizontally flipped.
> Simply using any_abs solves the SEGV and does the right thing, I
> believe.
> gs/base/gxiscale.c

2012-08-18 00:22:53 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
39fda0d88d35e2df4787b88b7d3e23eb74d59f49

> Bug 692210: fix potential indeterminism in zsetcolor()
> The value of a partly-initialized color created by zsetcolor()
> is copied to graphic state and compared with other colors by
> memcmp() in gx_hld_saved_color_equal() Full initialization is
> the easiest way to avoid indeterminism.
> gs/psi/zcolor.c

2012-08-17 22:32:25 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
32e1d6b480017d0655b8926b69bb3b7617730665

> Bug 692910: fix quoted arguments in ps2epsi.bat
> Strip the quotes before assigning the values to environment variables.
> Use the original quoted arguments elsewhere.
> gs/lib/ps2epsi.bat

2012-08-17 15:16:41 +0100
Chris Liddell <chris.liddell@artifex.com>
de8f9636ef6bdbb8af039a44443d7e05c990848e

> Bug 692040 - automake-1.8 is required in ijs sources
> credit to Richard Hughes ( richard@hughsie.com ) for the patch.
> No cluster differences.
> gs/ijs/Makefile.am

2012-08-17 15:09:24 +0100
Chris Liddell <chris.liddell@artifex.com>
d6d4cc55caed5462d7c4b41eb52da93bba854589

> Bug 692552: Direct building of MacOS X universal binaries
> Building universal binaries on OS X is now supported, removing the
> need to build for each architecture, and "lipo" files together.
> For this, configure should be called thus:
> ./configure CC="gcc -arch i386 -arch x86_64" CPP="gcc -E"
> and then invoke "make" normally.
> Universal binaries including PPC support are not currently supported.
> No cluster differences.
> gs/arch/osx-x86-x86_64-gcc.h
> gs/base/Makefile.in
> gs/base/configure.ac
> gs/doc/Make.htm

2012-08-09 11:50:21 +0100
Chris Liddell <chris.liddell@artifex.com>
fe79c76c8254faba9a2b422543062a577a375fee

> Bug 692750: have gdevwpr2 "manage" device icc profiles
> gdevwpr2 is one of the rare devices that can change its color space during its
> lifetime. Such devices need to "manage" their device ICC profiles directly.
> As the cups device is similar, these changes are loosely based on the
> analogous part of gdevcups.c.
> No cluster differences.
> gs/base/gdevwpr2.c
> gs/base/pcwin.mak

2012-08-17 09:09:58 +0100
Chris Liddell <chris.liddell@artifex.com>
9a114739f6e1f8837be17305784fc2ca9cbb6450

> Bug 693279: font: default base encoding
> There is some guess work here: Acrobat appears to be always using
> StandardEcoding as the default encoding for (at least) some non-symbolic
> fonts (rather than, as the spec states, the encoding specified by the font).
> As this is contrary to spec, and we only have a CFF example, I've restricted
> this to only apply to fonts with Subtype Type1C *and* that result in a Type 2
> PS font.
> No cluster differences.
> gs/Resource/Init/pdf_font.ps

2012-08-15 21:32:15 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
d5c42d3a14cee808fd889c14805a69adae8eb5b9

> Bug 688978: Generate DOCINFO pdfmark
> Pass the content of /Info dictionary to the interpreter using
> DOCINFO pdfmark. Also improve error recovery to avoid regression
> on one of our test cases that has broken /Info dictionary.
> gs/Resource/Init/pdf_base.ps
> gs/Resource/Init/pdf_main.ps

2012-08-15 02:19:50 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
9c76d00aaf4504cb65fc82771b705c9dc529084a

> Bug 687950: pass all PDF boxes to pdfmark
> gs/Resource/Init/pdf_main.ps

2012-08-15 00:27:48 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
437360af2799796c42304faaf9a0cc1e5c6f908c

> Bug 690568: Type usage problem on Itanium.
> Commit a contributed patch for Itanium. The patch looks reasonable: size_t is
> a better type than unsigned int to express the offset. The patch has no effect
> on our regression testing.
> gs/base/gxobj.h
> gs/psi/igc.c

2012-08-14 18:04:36 -0700
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
dc97d97b74f15a98219f45942485244da1e11bce

> Add support for 32 bit compile tests in clusterpush.pl
> gs/toolbin/localcluster/clusterpush.pl

2012-08-14 13:54:36 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
79f9321f6331a6598b6c52887890f0d03afa9f96

> Bug 693273: Use standard setpagedevice instead of a simplified one.
> Don't try to save a few milliseconds per page at the expense of correctness.
> gs/Resource/Init/pdf_main.ps

2012-08-13 02:14:41 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
238d6b887693b3dca97ab72d0e669670d8a53079

> Partly revert the commit for big objet support.
> Unfortunately, 12-byte ref causes SEGV on Win32. 64 and 32 bit Linux
> builds were fine. max object sizes are back to 64K.
> gs/psi/iref.h

2012-08-10 12:12:00 -0600
Henry Stiles <henry.stiles@artifex.com>
cfedd260650e7f615ec35cf88bd1bfd00ec502c9

> Fixes 693267 and 693162, the default VMI (vertical motion index) and
> PCL orientaion were not consistent.
> pcl/pcpage.c
> pcl/pcursor.c
> pcl/pcursor.h
> pl/pjparse.c

2012-08-10 11:59:05 -0600
Henry Stiles <henry.stiles@artifex.com>
6dd836c62658cfe38bf2988fd55ee05a9a3870d9

> Adds debug logging for pcl macros.
> pcl/pcmacros.c

2012-08-10 12:59:25 +0100
Robin Watts <robin.watts@artifex.com>
39c501a222658d754b9ab9540f283d7bd05e19ad

> Fix scaling issues seen with fast halftoning code.
> We were missing out the right hand column of source data in images
> (see the turkeys on 09-47N page 2 in comparison to png or
> USE_FAST_CODE=0 renderings); fix this by not subtracting 1 from
> src_size. Don't subtract 1 from data_length (or dest width) either
> to match.
> Change dda to do a 'half step' to ensure we are sampling from the
> centre of each pixel (avoids a shift to the right in zoomed up
> images). This requires a new dda init macro - remove the old
> (unused, slower) dda formulation to avoid having to think too hard.
> gs/base/gxdda.h
> gs/base/gxicolor.c
> gs/base/gximono.c

2012-08-10 14:22:49 -0700
Ray Johnston <ray.johnston@artifex.com>
dba8f75023dc5b1abac7e338a541360a106d9956

> Fix bug 690963. Update the plane_extract device for hl color handling.
> The plane_extract device (used by pksmraw, pamcmyk32, and bmpsep1 as
> well as gdevbjc_.c) was never updated for many of the newer device
> procedures, including fillpage. This is handled by extending the
> prototype procs for the device so that gx_device_forward_fill_in_procs
> does not use the procs from the target.
> gs/base/gdevplnx.c

2012-08-10 15:59:15 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
86f9af6937e76e10a7adad201b06c337b1a9240b

> Increase max object size to 16M.
> Increase the size of rsize member of the ref structure from ushort
> to uint_32. This is needed to support large composite objects permitted by current
> PDF specification. On 64-bit systems the actual size of ref didn't change.
> On 32-bit systems the ref has grown to 12 bytes, which caused a couple of
> changes in the alignment and padding code. Finally, the max size of all
> composite objects has been increased to 16M.
> This patch leaves large objects exposed PS interpreter.
> Traditional PS limits can be re-imposed on the PS interpreter if
> needed.
> The patch results in a couple of progressions on the PDF test base,
> and a few expected differences on PS test files that test traditional
> limits on composite PS objects.
> gs/doc/Language.htm
> gs/psi/igcref.c
> gs/psi/int.mak
> gs/psi/iref.h
> gs/psi/zpacked.c

2012-08-10 13:03:33 +0100
Robin Watts <robin.watts@artifex.com>
d3ea65bd08665e48525a4f8694276814fdebded7

> Correct fast halftoning code in multi plane case.
> We were using an incorrect stride in a calculation, resulting in
> corrupted output.
> gs/base/gxht_thresh.c

2012-08-10 09:02:32 +0100
Chris Liddell <chris.liddell@artifex.com>
c004cd6856445cdb5fccc40b5393ffb72a0d9433

> Fix the nsis installer config file.
> CLUSTER_UNTESTED
> gs/psi/nsisinst.nsi

2012-08-09 09:34:02 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
23087cc653c4fcaf401715d7f5c6a4509576a21f

> Merge remote-tracking branches 'origin' and 'origin/OpenJpeg-1.5'

2012-08-09 00:51:35 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
946c6312efc2cbf74875d19fd7b49f3505ab7a81

> Apply a patch for CVE-2012-3358
> See http://code.google.com/p/openjpeg/source/detail?r=1727
> Other CVE patches are not needed for v.1.5.
> gs/openjpeg/libopenjpeg/j2k.c

2012-08-09 00:45:09 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
ef85034141b90c05ba0bc5e2ad40f834205b4f2a

> Reapply our patches to OpenJpeg-1.5
> gs/openjpeg/libopenjpeg/image.c
> gs/openjpeg/libopenjpeg/j2k.c
> gs/openjpeg/libopenjpeg/jp2.c
> gs/openjpeg/libopenjpeg/jp2.h
> gs/openjpeg/libopenjpeg/openjpeg.c
> gs/openjpeg/libopenjpeg/openjpeg.h
> gs/openjpeg/libopenjpeg/opj_malloc.h
> gs/openjpeg/libopenjpeg/tcd.c

2012-08-08 20:36:38 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
4e3808ff733ed0d485b67211ad5bcf7aa992c739

> Import original OpenJpeg 1.5
> This revision doesn't compile. It's here to establish a reference
> for the diffs.
> gs/base/openjpeg.mak
> gs/openjpeg/libopenjpeg/CMakeLists.txt
> gs/openjpeg/libopenjpeg/Makefile.am
> gs/openjpeg/libopenjpeg/Makefile.in
> gs/openjpeg/libopenjpeg/cidx_manager.c
> gs/openjpeg/libopenjpeg/cidx_manager.h
> gs/openjpeg/libopenjpeg/cio.c
> gs/openjpeg/libopenjpeg/cio.h
> gs/openjpeg/libopenjpeg/dwt.c
> gs/openjpeg/libopenjpeg/event.c
> gs/openjpeg/libopenjpeg/event.h
> gs/openjpeg/libopenjpeg/image.c
> gs/openjpeg/libopenjpeg/image.h
> gs/openjpeg/libopenjpeg/indexbox_manager.h
> gs/openjpeg/libopenjpeg/j2k.c
> gs/openjpeg/libopenjpeg/j2k.h
> gs/openjpeg/libopenjpeg/j2k_lib.c
> gs/openjpeg/libopenjpeg/j2k_lib.h
> gs/openjpeg/libopenjpeg/jp2.c
> gs/openjpeg/libopenjpeg/jp2.h
> gs/openjpeg/libopenjpeg/mqc.c
> gs/openjpeg/libopenjpeg/openjpeg.c
> gs/openjpeg/libopenjpeg/openjpeg.h
> gs/openjpeg/libopenjpeg/opj_includes.h
> gs/openjpeg/libopenjpeg/opj_malloc.h
> gs/openjpeg/libopenjpeg/phix_manager.c
> gs/openjpeg/libopenjpeg/pi.c
> gs/openjpeg/libopenjpeg/pi.h
> gs/openjpeg/libopenjpeg/ppix_manager.c
> gs/openjpeg/libopenjpeg/t1.c
> gs/openjpeg/libopenjpeg/t2.c
> gs/openjpeg/libopenjpeg/tcd.c
> gs/openjpeg/libopenjpeg/tcd.h
> gs/openjpeg/libopenjpeg/thix_manager.c
> gs/openjpeg/libopenjpeg/tpix_manager.c
> gs/openjpeg/opj_config.h.in.user

2012-07-31 15:25:13 +0100
Chris Liddell <chris.liddell@artifex.com>
38da6175372319af334d1eb7a4474c98f6881f3d

> Pull doc changes from 9.06 release branch.
> Update docs for 9.06 release candidate 1.
> Update changelog with post 9.06rc1 changes.
> Update release date in docs.
> CLUSTER_UNTESTED
> gs/doc/API.htm
> gs/doc/C-style.htm
> gs/doc/Commprod.htm
> gs/doc/DLL.htm
> gs/doc/Deprecated.htm
> gs/doc/Details8.htm
> gs/doc/Details9.htm
> gs/doc/Develop.htm
> gs/doc/Devices.htm
> gs/doc/Drivers.htm
> gs/doc/Fonts.htm
> gs/doc/Helpers.htm
> gs/doc/History1.htm
> gs/doc/History2.htm
> gs/doc/History3.htm
> gs/doc/History4.htm
> gs/doc/History5.htm
> gs/doc/History6.htm
> gs/doc/History7.htm
> gs/doc/History8.htm
> gs/doc/History9.htm
> gs/doc/Install.htm
> gs/doc/Issues.htm
> gs/doc/Language.htm
> gs/doc/Lib.htm
> gs/doc/Make.htm
> gs/doc/News.htm
> gs/doc/Projects.htm
> gs/doc/Ps-style.htm
> gs/doc/Ps2epsi.htm
> gs/doc/Ps2pdf.htm
> gs/doc/Ps2ps2.htm
> gs/doc/Psfiles.htm
> gs/doc/Readme.htm
> gs/doc/Release.htm
> gs/doc/Source.htm
> gs/doc/Unix-lpr.htm
> gs/doc/Use.htm
> gs/doc/WhatIsGS.htm
> gs/doc/Xfonts.htm
> gs/doc/gs-vms.hlp
> gs/doc/thirdparty.htm
> gs/man/dvipdf.1
> gs/man/font2c.1
> gs/man/gs.1
> gs/man/gslp.1
> gs/man/gsnd.1
> gs/man/pdf2dsc.1
> gs/man/pdf2ps.1
> gs/man/pdfopt.1
> gs/man/pf2afm.1
> gs/man/pfbtopfa.1
> gs/man/printafm.1
> gs/man/ps2ascii.1
> gs/man/ps2epsi.1
> gs/man/ps2pdf.1
> gs/man/ps2pdfwr.1
> gs/man/ps2ps.1
> gs/man/wftopfa.1

2012-08-06 23:37:19 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
402806536e6ce5eb7b76eb7a4c5725ec2bbc4e80

> Backport patches CVE problems.
> CVE-2009-5030 http://code.google.com/p/openjpeg/source/detail?r=1703
> CVE-2012-1499 http://code.google.com/p/openjpeg/source/detail?r=1330
> CVE-2012-3358 http://code.google.com/p/openjpeg/source/detail?r=1727
> gs/openjpeg/libopenjpeg/j2k.c
> gs/openjpeg/libopenjpeg/jp2.c
> gs/openjpeg/libopenjpeg/tcd.c

2012-08-06 18:05:58 +0100
Chris Liddell <chris.liddell@artifex.com>
b3ffd243ae375288c7c08607056dd08dae51018f

> Remove devcups from default devices on Windows
> Since devcups and its infrastructure were only added to gs to allow gs
> developers who work on Windows to debug cups problems, it's not really
> relevant for normal use.
> This change makes it optional, by adding WITH_CUPS=1 to the nmake command
> line arguments.
> CLUSTER_UNTESTED
> gs/ghostscript.vcproj
> gs/psi/msvc.mak

2012-08-06 17:13:39 +0200
Sebastian Rasmussen <sebras@gmail.com>
010b1adedf128a7079729d10ad5a8c1b97c8acec

> Bug 693256: Free GR_/GB_stats.....
> .....as long as retaining them is yet to be implemented
> No cluster differences.
> gs/jbig2dec/jbig2_symbol_dict.c

2012-08-06 16:00:08 +0100
Chris Liddell <chris.liddell@artifex.com>
5ae5e2a73654cb9d2845e053428ebfddd3670c2d

> Workaround libpaper's poor memory management.
> libpaper allocates using the stdlib malloc(), and expects the calling code
> to release the memory via stdlib free().
> Normally this works fine, but Memento hooks malloc() and free() in the
> pre-processor, so it sees the free() call, but not the malloc() call.
> This can result in confusing, spurious errors from memento.
> No cluster differences.
> gs/base/gp_upapr.c

2012-08-06 08:43:48 +0100
Chris Liddell <chris.liddell@artifex.com>
327da990d82209c411841bbade4fc2a77fb326e7

> Bug 693223: remove apparently moribund dumphint tool
> dumphint.ps and the scripts which call it seem to be of almost no value
> these days, and appear to have suffered "bit rot". So remove them.
> CLUSTER_UNTESTED
> gs/lib/dumphint
> gs/lib/dumphint.bat
> gs/lib/dumphint.ps

2012-08-04 09:18:50 +0100
Ken Sharp <ken.sharp@artifex.com>
5ec908d81e3dc999f694356a970f63b66f7e5976

> pdfwrite - fix PDF/X-3 annotation check
> The previous commit 7167ebcceae78be8dcec24a059f936a861769cd5 incorrectly
> checked the location of the annotation on the page, and prevented any annotation
> in PDF/X-3 output, whereaas annotations off the page are actually permitted.
> No differences expected
> gs/base/gdevpdfm.c

2012-08-03 18:49:32 +0100
Robin Watts <Robin.Watts@artifex.com>
27f22e3a48bafc8a663e08ac1aeb310b302055af

> First attempt at Windows 8 "Metro" compatibility.
> Standard MSVC builds will work for Windows 8 in desktop mode. The
> complexity comes in supporting Windows RT (or "Metro" as Microsoft
> have been calling it). To do Metro builds you need to download
> Microsoft Visual C 2012 Express, and install it into a preview copy
> of Windows 8.
> MSVC 2012 Express will not import the existing Solution file (probably
> because it's nmake based), so I've been compiling from the command
> line.
> Open a "VS2012 x86 Native Tools Command Prompt" and cd to the gs
> directory. Then use:
> nmake -f psi\msvc32.mak SBR=1 DEVSTUDIO=1 METRO=1
> to build. For PCL change to main, then use:
> nmake -f pcl6_msvc.mak SBR=1 DEVSTUDIO=1 METRO=1
> etc.
> Things to note:
> * There is no message loop in Windows RT and the window handling is
> all via different APIs anyway - so we only support the console
> exe, with no display device.
> * We have no registry access so the code just looks at the usual
> environment variables.
> * Cups has been disabled (as libcups wants to do useful things like
> http, which won't currently compile under Windows RT).
> gs/base/gp_mswin.c
> gs/base/gp_wgetv.c
> gs/base/msvctail.mak
> gs/base/winlib.mak
> gs/psi/dwdll.c
> gs/psi/dwmainc.c
> gs/psi/gsdll32metro.def
> gs/psi/gsdll64metro.def
> gs/psi/msvc.mak
> gs/psi/winint.mak
> language_switch/pspcl6_msvc.mak
> main/pcl6_msvc.mak
> pl/dwmainc.c

2012-08-03 00:32:32 -0700
Ray Johnston <ray.johnston@artifex.com>
6070a6f33bebf7538e48219010bc1e4de8341ea8

> Rip out jasper -- openjpeg is our JPX implementation.
> gs/base/Makefile.in
> gs/base/configure.ac
> gs/base/gs.mak
> gs/base/jasper.mak
> gs/base/lib.mak
> gs/base/macgenmcpxml.sh
> gs/base/macos-mcp.mak
> gs/base/msvclib.mak
> gs/base/openvms.mak
> gs/base/openvms.mmk
> gs/base/sjpx.c
> gs/base/sjpx.h
> gs/base/winlib.mak
> gs/jasper/COPYRIGHT
> gs/jasper/INSTALL
> gs/jasper/LICENSE
> gs/jasper/Makefile.am
> gs/jasper/Makefile.in
> gs/jasper/NEWS
> gs/jasper/README
> gs/jasper/acaux/compile
> gs/jasper/acaux/config.guess
> gs/jasper/acaux/config.sub
> gs/jasper/acaux/depcomp
> gs/jasper/acaux/install-sh
> gs/jasper/acaux/ltmain.sh
> gs/jasper/acaux/missing
> gs/jasper/aclocal.m4
> gs/jasper/configure
> gs/jasper/configure.ac
> gs/jasper/data/Makefile.am
> gs/jasper/data/colorprofiles/README
> gs/jasper/data/colorprofiles/erimm.icm
> gs/jasper/data/colorprofiles/esrgb.icm
> gs/jasper/data/colorprofiles/esrgbgrey.icm
> gs/jasper/data/colorprofiles/grey.icm
> gs/jasper/data/colorprofiles/greyromm.icm
> gs/jasper/data/colorprofiles/romm.icm
> gs/jasper/data/colorprofiles/sgray.icm
> gs/jasper/data/colorprofiles/srgb.icm
> gs/jasper/data/colorprofiles/sycc.icm
> gs/jasper/data/images/README
> gs/jasper/data/images/example.mif
> gs/jasper/data/images/example.mif0
> gs/jasper/data/images/feep.pnm
> gs/jasper/data/images/feep2.pnm
> gs/jasper/data/images/goldenears.bmp
> gs/jasper/data/images/goldenears.jpg
> gs/jasper/data/images/goldenears.pnm
> gs/jasper/data/images/goldenears.ras
> gs/jasper/data/images/goldenears_gray.jpg
> gs/jasper/data/images/goldenears_gray.pnm
> gs/jasper/data/images/goldenears_gray.ras
> gs/jasper/data/images/small_16x1.pgm
> gs/jasper/data/images/small_1x1.pgm
> gs/jasper/data/images/stawamuschief.pnm
> gs/jasper/data/images/stawamuschief_gray.pnm
> gs/jasper/data/images/test.pnm
> gs/jasper/doc/README
> gs/jasper/doc/jasper.pdf
> gs/jasper/doc/jpeg2000.pdf
> gs/jasper/jasper.spec
> gs/jasper/jasper.spec.in
> gs/jasper/src/Makefile.am
> gs/jasper/src/Makefile.in
> gs/jasper/src/README
> gs/jasper/src/appl/Makefile.am
> gs/jasper/src/appl/Makefile.in
> gs/jasper/src/appl/dummy.c
> gs/jasper/src/appl/imgcmp.c
> gs/jasper/src/appl/imginfo.c
> gs/jasper/src/appl/jasper.c
> gs/jasper/src/appl/jasper_sdl.c
> gs/jasper/src/appl/jiv.c
> gs/jasper/src/libjasper/Makefile.am
> gs/jasper/src/libjasper/Makefile.in
> gs/jasper/src/libjasper/README
> gs/jasper/src/libjasper/base/Makefile.am
> gs/jasper/src/libjasper/base/Makefile.in
> gs/jasper/src/libjasper/base/jas_cm.c
> gs/jasper/src/libjasper/base/jas_debug.c
> gs/jasper/src/libjasper/base/jas_getopt.c
> gs/jasper/src/libjasper/base/jas_icc.c
> gs/jasper/src/libjasper/base/jas_iccdata.c
> gs/jasper/src/libjasper/base/jas_image.c
> gs/jasper/src/libjasper/base/jas_init.c
> gs/jasper/src/libjasper/base/jas_malloc.c
> gs/jasper/src/libjasper/base/jas_seq.c
> gs/jasper/src/libjasper/base/jas_stream.c
> gs/jasper/src/libjasper/base/jas_string.c
> gs/jasper/src/libjasper/base/jas_tvp.c
> gs/jasper/src/libjasper/base/jas_version.c
> gs/jasper/src/libjasper/bmp/Makefile.am
> gs/jasper/src/libjasper/bmp/Makefile.in
> gs/jasper/src/libjasper/bmp/bmp_cod.c
> gs/jasper/src/libjasper/bmp/bmp_cod.h
> gs/jasper/src/libjasper/bmp/bmp_dec.c
> gs/jasper/src/libjasper/bmp/bmp_enc.c
> gs/jasper/src/libjasper/bmp/bmp_enc.h
> gs/jasper/src/libjasper/dummy.c
> gs/jasper/src/libjasper/include/Makefile.am
> gs/jasper/src/libjasper/include/Makefile.in
> gs/jasper/src/libjasper/include/jasper/Makefile.am
> gs/jasper/src/libjasper/include/jasper/Makefile.in
> gs/jasper/src/libjasper/include/jasper/jas_cm.h
> gs/jasper/src/libjasper/include/jasper/jas_config.h
> gs/jasper/src/libjasper/include/jasper/jas_config_ac.h.in
> gs/jasper/src/libjasper/include/jasper/jas_config_win32.h
> gs/jasper/src/libjasper/include/jasper/jas_debug.h
> gs/jasper/src/libjasper/include/jasper/jas_fix.h
> gs/jasper/src/libjasper/include/jasper/jas_getopt.h
> gs/jasper/src/libjasper/include/jasper/jas_icc.h
> gs/jasper/src/libjasper/include/jasper/jas_image.h
> gs/jasper/src/libjasper/include/jasper/jas_init.h
> gs/jasper/src/libjasper/include/jasper/jas_malloc.h
> gs/jasper/src/libjasper/include/jasper/jas_math.h
> gs/jasper/src/libjasper/include/jasper/jas_seq.h
> gs/jasper/src/libjasper/include/jasper/jas_stream.h
> gs/jasper/src/libjasper/include/jasper/jas_string.h
> gs/jasper/src/libjasper/include/jasper/jas_tvp.h
> gs/jasper/src/libjasper/include/jasper/jas_types.h
> gs/jasper/src/libjasper/include/jasper/jas_version.h
> gs/jasper/src/libjasper/include/jasper/jasper.h
> gs/jasper/src/libjasper/jp2/Makefile.am
> gs/jasper/src/libjasper/jp2/Makefile.in
> gs/jasper/src/libjasper/jp2/jp2_cod.c
> gs/jasper/src/libjasper/jp2/jp2_cod.h
> gs/jasper/src/libjasper/jp2/jp2_dec.c
> gs/jasper/src/libjasper/jp2/jp2_dec.h
> gs/jasper/src/libjasper/jp2/jp2_enc.c
> gs/jasper/src/libjasper/jpc/Makefile.am
> gs/jasper/src/libjasper/jpc/Makefile.in
> gs/jasper/src/libjasper/jpc/jpc_bs.c
> gs/jasper/src/libjasper/jpc/jpc_bs.h
> gs/jasper/src/libjasper/jpc/jpc_cod.h
> gs/jasper/src/libjasper/jpc/jpc_cs.c
> gs/jasper/src/libjasper/jpc/jpc_cs.h
> gs/jasper/src/libjasper/jpc/jpc_dec.c
> gs/jasper/src/libjasper/jpc/jpc_dec.h
> gs/jasper/src/libjasper/jpc/jpc_enc.c
> gs/jasper/src/libjasper/jpc/jpc_enc.h
> gs/jasper/src/libjasper/jpc/jpc_fix.h
> gs/jasper/src/libjasper/jpc/jpc_flt.h
> gs/jasper/src/libjasper/jpc/jpc_math.c
> gs/jasper/src/libjasper/jpc/jpc_math.h
> gs/jasper/src/libjasper/jpc/jpc_mct.c
> gs/jasper/src/libjasper/jpc/jpc_mct.h
> gs/jasper/src/libjasper/jpc/jpc_mqcod.c
> gs/jasper/src/libjasper/jpc/jpc_mqcod.h
> gs/jasper/src/libjasper/jpc/jpc_mqdec.c
> gs/jasper/src/libjasper/jpc/jpc_mqdec.h
> gs/jasper/src/libjasper/jpc/jpc_mqenc.c
> gs/jasper/src/libjasper/jpc/jpc_mqenc.h
> gs/jasper/src/libjasper/jpc/jpc_qmfb.c
> gs/jasper/src/libjasper/jpc/jpc_qmfb.h
> gs/jasper/src/libjasper/jpc/jpc_t1cod.c
> gs/jasper/src/libjasper/jpc/jpc_t1cod.h
> gs/jasper/src/libjasper/jpc/jpc_t1dec.c
> gs/jasper/src/libjasper/jpc/jpc_t1dec.h
> gs/jasper/src/libjasper/jpc/jpc_t1enc.c
> gs/jasper/src/libjasper/jpc/jpc_t1enc.h
> gs/jasper/src/libjasper/jpc/jpc_t2cod.c
> gs/jasper/src/libjasper/jpc/jpc_t2cod.h
> gs/jasper/src/libjasper/jpc/jpc_t2dec.c
> gs/jasper/src/libjasper/jpc/jpc_t2dec.h
> gs/jasper/src/libjasper/jpc/jpc_t2enc.c
> gs/jasper/src/libjasper/jpc/jpc_t2enc.h
> gs/jasper/src/libjasper/jpc/jpc_tagtree.c
> gs/jasper/src/libjasper/jpc/jpc_tagtree.h
> gs/jasper/src/libjasper/jpc/jpc_tsfb.c
> gs/jasper/src/libjasper/jpc/jpc_tsfb.h
> gs/jasper/src/libjasper/jpc/jpc_util.c
> gs/jasper/src/libjasper/jpc/jpc_util.h
> gs/jasper/src/libjasper/jpg/Makefile.am
> gs/jasper/src/libjasper/jpg/Makefile.in
> gs/jasper/src/libjasper/jpg/README
> gs/jasper/src/libjasper/jpg/jpg_cod.h
> gs/jasper/src/libjasper/jpg/jpg_dec.c
> gs/jasper/src/libjasper/jpg/jpg_dummy.c
> gs/jasper/src/libjasper/jpg/jpg_enc.c
> gs/jasper/src/libjasper/jpg/jpg_enc.h
> gs/jasper/src/libjasper/jpg/jpg_jpeglib.h
> gs/jasper/src/libjasper/jpg/jpg_val.c
> gs/jasper/src/libjasper/mif/Makefile.am
> gs/jasper/src/libjasper/mif/Makefile.in
> gs/jasper/src/libjasper/mif/README
> gs/jasper/src/libjasper/mif/mif_cod.c
> gs/jasper/src/libjasper/mif/mif_cod.h
> gs/jasper/src/libjasper/pgx/Makefile.am
> gs/jasper/src/libjasper/pgx/Makefile.in
> gs/jasper/src/libjasper/pgx/pgx_cod.c
> gs/jasper/src/libjasper/pgx/pgx_cod.h
> gs/jasper/src/libjasper/pgx/pgx_dec.c
> gs/jasper/src/libjasper/pgx/pgx_enc.c
> gs/jasper/src/libjasper/pgx/pgx_enc.h
> gs/jasper/src/libjasper/pnm/Makefile.am
> gs/jasper/src/libjasper/pnm/Makefile.in
> gs/jasper/src/libjasper/pnm/pnm_cod.c
> gs/jasper/src/libjasper/pnm/pnm_cod.h
> gs/jasper/src/libjasper/pnm/pnm_dec.c
> gs/jasper/src/libjasper/pnm/pnm_enc.c
> gs/jasper/src/libjasper/pnm/pnm_enc.h
> gs/jasper/src/libjasper/ras/Makefile.am
> gs/jasper/src/libjasper/ras/Makefile.in
> gs/jasper/src/libjasper/ras/ras_cod.c
> gs/jasper/src/libjasper/ras/ras_cod.h
> gs/jasper/src/libjasper/ras/ras_dec.c
> gs/jasper/src/libjasper/ras/ras_enc.c
> gs/jasper/src/libjasper/ras/ras_enc.h
> gs/jasper/src/msvc/Makefile.am
> gs/jasper/src/msvc/Makefile.in
> gs/jasper/src/msvc/README
> gs/jasper/src/msvc/imgcmp.dsp
> gs/jasper/src/msvc/imginfo.dsp
> gs/jasper/src/msvc/jasper.dsp
> gs/jasper/src/msvc/jasper.dsw
> gs/jasper/src/msvc/jiv.dsp
> gs/jasper/src/msvc/libjasper.dsp
> gs/psi/int.mak
> gs/psi/msvc.mak
> gs/psi/nsisinst.nsi
> gs/psi/winint.mak

2012-08-03 09:52:09 +0100
Ken Sharp <ken.sharp@artifex.com>
7167ebcceae78be8dcec24a059f936a861769cd5

> pdfwrite - check annotation placement and Box sizes for PDF/X-3 validity
> Bug #693233 "PDF/X-3 created using ghostscript gives preflight errors"
> We were not checking the bounds of annotations to ensure they were outside
> the TrimBox or BleedBox (if present). Annotations are not permitted in the
> printable area of a PDF/X-3 file.
> In addition we were not checking to see that the TrimBox bounds did not exceed
> the BleedBox or MediaBox.
> There seems to be a bug in the Acrobat validation tool which insists that the
> CropBox must not extend past the BleedBox. I can find no justification for
> this in the specification, and indeed the PDF 1.7 spec notes that the CropBox has
> 'no defined relationship with any of the other boundaries' so for now I've chosen
> to ignore this restriction.
> No differences expected as PDF/X-3 output is not cluster tested
> gs/base/gdevpdf.c
> gs/base/gdevpdfm.c
> gs/base/gdevpdfo.c
> gs/base/gdevpdfo.h

2012-08-02 23:14:09 -0700
Ray Johnston <ray.johnston@artifex.com>
b40b8fdcfdf4fc9f46fd5d2f8e7b88796490970a

> Bug 693185. The limitcheck in validatedevicenspace must match int_remap_color_info_s.
> Commit e884e3 masked the failure, but since the test in validatedevicenspace
> used GS_CLIENT_COLOR_MAX_COMPONENTS, the array bounds could still be exceeded.
> Note that the confusing error message from the PDF interpreter from comment 1
> still exists unless -dPDFSTOPONERROR is used, which gives a more meaningful
> 'limitcheck' immediately following the 'Do' of the image with 17 DeviceN
> components. Bug 693185 is reopened for the error message as P3.
> gs/base/gsccolor.h
> gs/psi/icremap.h
> gs/psi/zcolor.c

2012-08-02 17:27:32 -0700
Ray Johnston <ray.johnston@artifex.com>
d8ca80d1cb480702c109414c46e381981c94ddcb

> Get rid of 'icclib' since we now use lcms2 (or optionally lcms).
> common/msvc_top.mak
> common/ugcc_top.mak
> gs/base/Makefile.in
> gs/base/gdevpdfk.c
> gs/base/gs.mak
> gs/base/icclib.mak
> gs/base/ijs.mak
> gs/base/macos-mcp.mak
> gs/base/macosx.mak
> gs/base/openvms.mak
> gs/base/openvms.mmk
> gs/base/ugcclib.mak
> gs/base/unix-gcc.mak
> gs/base/unixansi.mak
> gs/base/winlib.mak
> gs/icclib/Licence.txt
> gs/icclib/NOTES
> gs/icclib/Readme.txt
> gs/icclib/icc.c
> gs/icclib/icc.h
> gs/icclib/icc9809.h
> gs/psi/os2.mak
> gs/psi/winint.mak
> gs/psi/zicc.c
> language_switch/pspcl6_gcc.mak
> language_switch/pspcl6_msvc.mak
> main/pcl6_gcc.mak
> main/pcl6_msvc.mak
> svg/svg_gcc.mak
> svg/svg_msvc.mak
> xps/xps_gcc.mak
> xps/xps_msvc.mak

2012-08-02 20:34:26 -0700
Michael Vrhel <michael.vrhel@artifex.com>
a884b57b792291a6c713600662ab60718aca3e4f

> Update documentation for tiffsep planar device
> Add in comments about the use of -dMaxSpots as well as the fact that the device,
> and psdcmyk are planar and limited to 64 colorants per page. Also add in a
> hint about using -dMaxSpots when we are processing a Postscript file and bump
> up to the default max limit of 10 colorants. Tested it and it worked nicely.
> Thanks Robin Watts.
> gs/base/gdevpsd.c
> gs/base/gdevtsep.c
> gs/doc/Devices.htm

2012-08-02 18:27:45 +0100
Robin Watts <robin.watts@artifex.com>
cfbd3faf503983d35dec119bc4e618e7bae0af30

> Add -dMaxSpots for tiffsep and psd devices.
> psd and tiffsep devices now run with GS_SOFT_MAX_SPOTS spots enabled
> by default (GS_CLIENT_COLOR_MAX_COMPONENTS-4 unless predefined
> differently at build time). The user can change this value using
> -dMaxSpots=X (where 0 <= X <= GS_CLIENT_COLOR_MAX_COMPONENTS-4).
> gs/base/gdevpsd.c
> gs/base/gdevtsep.c
> gs/base/gsccolor.h

2012-08-01 17:13:23 +0100
Robin Watts <robin.watts@artifex.com>
974ba5dde88108ba54c10e8c4f2c59fbce2db5cd

> Add new 'const' compression method for clist bits.
> Spot that the compressed bitmap is all identically the same byte
> value (most likely 0 or FF), and if so, send just a single byte.
> gs/base/gsbitops.c
> gs/base/gsbitops.h
> gs/base/gxclbits.c
> gs/base/gxcldev.h
> gs/base/gxclrast.c

2012-08-02 09:09:05 +0100
Ken Sharp <ken.sharp@artifex.com>
fe9465d90b4662eb56c7d0686ea87603b5c238b3

> ps2write - don't leave our dictionary on the stack at temination of the output
> Bug #693241 " save / restore around pdf2ps output causes invalidrestore"
> Although the output of ps2write isn't intended for encapsulation, we do intend
> one day to produce an eps2write (or something) which will be. So we may as
> well fix this now.
> Previously we left our internal dictionary on the dictionary stack at the
> end of the output, here we simply 'end' it which removes it from the stack and
> make the output better suited for encapsulation.
> No differences expected
> gs/base/gdevpdf.c

2012-08-01 22:14:44 +0100
Chris Liddell <chris.liddell@artifex.com>
2d613c33cda3b5c83ce83a6d9a48a0f5014c922f

> Fix the -disable-gtk "so" build option
> No cluster differences.
> gs/base/configure.ac

2012-08-01 14:07:49 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
004aeab5298b0a42ff08a1c9e626f41cf799039c

> Fix lcms2 64-bit value decoding on big endian systems
> that lack 64-bit types or have these types missed by configuration.
> gs/lcms2/src/cmsplugin.c

2012-07-31 16:51:58 -0700
Ray Johnston <ray.johnston@artifex.com>
c1532d478d06dcd26d1307942705ce1f05135b7b

> Fix parenthesis typo that caused the return code from sscanf to be ignored.
> gs/psi/imainarg.c

2012-07-31 12:26:39 -0700
Ray Johnston <ray.johnston@artifex.com>
60028f89756d3027ddf7f4a1dab09c06d0b1c81a

> Add common unix style scaling suffix support for -d____= parameters.
> Supported suffixes are 'k' and 'K' ( *= 1024), 'm' and 'M' ( *= 1024*1024)
> and 'g' and 'G' ( *= 1024*1024*1024). Note that only 1g will not overflow.
> No support is provided for .5g or 1.5g values, but this is better than
> nothing. Both ghostscript and the other ghostpdl apps (that use plmain.c)
> now provide this support.
> gs/psi/imainarg.c
> pl/plmain.c

2012-07-31 17:53:58 +0100
Robin Watts <robin.watts@artifex.com>
5876c67ba54ca41499fe4e595d140afa5d0c6120

> Update tiffsep/tiffsep1 documentation w.r.t downscaler.
> Document 32 and 34 ratios. Add extra info to tiffsep1 to distinguish
> it from tiffsep in 1bpp mode.
> gs/doc/Devices.htm

2012-07-30 11:17:55 -0700
Ray Johnston <ray.johnston@artifex.com>
19c07c2f90a4fefd149c5e6d32ecb4496f9f01a4

> Fix the confusion w.r.t fill_rectangle_hl_color between int and fixed coordinates
> This isn't widely used -- for gs_fillpage and for gs_rectfill, but some uses
> were using 'fixed' coordinates (such as gdevpdfd.c) and others implementation
> behaved as if the rect contained 'int' pixel coordinates (gxdcolor.c).
> gs/base/gdevabuf.c
> gs/base/gdevdsha.c
> gs/base/gdevmpla.c
> gs/base/gdevnfwd.c
> gs/base/gdevp14.c
> gs/base/gsdps1.c
> gs/base/gsovrc.c
> gs/base/gxclip.c
> gs/base/gxclip2.c
> gs/base/gxclipm.c
> gs/base/gxclrast.c
> gs/base/gxclrect.c
> gs/base/gxdcolor.c
> gs/base/gxpcmap.c

2012-07-31 10:50:43 +0100
Robin Watts <robin.watts@artifex.com>
7eabd219b61418db08f1e707deb3dc9e753661f1

> Fix link warnings about bad memset in gdevtsep.c
> Due to a mistake on my part, the tiffsep device had a couple of
> memsets in that did nothing; these were intended to clear an array
> of pointers before use. Not clearing the array would only have been
> a problem if we'd hit an error condition in a very small region of
> code, but nonetheless, this is a fix.
> gs/base/gdevtsep.c

2012-07-31 08:26:34 +0100
Chris Liddell <chris.liddell@artifex.com>
1ba0272f00c1de822fff0ac4087446c45f46aeb6

> Bump the master version number.
> gs/Resource/Init/gs_init.ps
> gs/base/version.mak

2012-08-07 11:49:41 +0100
Chris Liddell <chris.liddell@artifex.com>
ed033afdc6dcd4a964dd6c54a08e53e807a33a4e

> Update changelog with post 9.06rc1 changes.
> Update release date in docs.
> gs/doc/API.htm
> gs/doc/C-style.htm
> gs/doc/Commprod.htm
> gs/doc/DLL.htm
> gs/doc/Deprecated.htm
> gs/doc/Details8.htm
> gs/doc/Details9.htm
> gs/doc/Develop.htm
> gs/doc/Devices.htm
> gs/doc/Drivers.htm
> gs/doc/Fonts.htm
> gs/doc/Helpers.htm
> gs/doc/History1.htm
> gs/doc/History2.htm
> gs/doc/History3.htm
> gs/doc/History4.htm
> gs/doc/History5.htm
> gs/doc/History6.htm
> gs/doc/History7.htm
> gs/doc/History8.htm
> gs/doc/History9.htm
> gs/doc/Install.htm
> gs/doc/Issues.htm
> gs/doc/Language.htm
> gs/doc/Lib.htm
> gs/doc/Make.htm
> gs/doc/News.htm
> gs/doc/Projects.htm
> gs/doc/Ps-style.htm
> gs/doc/Ps2epsi.htm
> gs/doc/Ps2pdf.htm
> gs/doc/Ps2ps2.htm
> gs/doc/Psfiles.htm
> gs/doc/Readme.htm
> gs/doc/Release.htm
> gs/doc/Source.htm
> gs/doc/Unix-lpr.htm
> gs/doc/Use.htm
> gs/doc/WhatIsGS.htm
> gs/doc/Xfonts.htm
> gs/doc/gs-vms.hlp
> gs/doc/thirdparty.htm
> gs/man/dvipdf.1
> gs/man/font2c.1
> gs/man/gs.1
> gs/man/gslp.1
> gs/man/gsnd.1
> gs/man/pdf2dsc.1
> gs/man/pdf2ps.1
> gs/man/pdfopt.1
> gs/man/pf2afm.1
> gs/man/pfbtopfa.1
> gs/man/printafm.1
> gs/man/ps2ascii.1
> gs/man/ps2epsi.1
> gs/man/ps2pdf.1
> gs/man/ps2pdfwr.1
> gs/man/ps2ps.1
> gs/man/wftopfa.1

2012-08-08 08:42:26 +0100
Chris Liddell <chris.liddell@artifex.com>
22d614c608778edf3fc6ba2481813c9e9e57cc2e

> Update product string and release date.
> gs/base/gscdef.c
> gs/base/version.mak

2012-08-06 23:37:19 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
291872308da215e1d7e12c8375fcf10dd5e651d2

> Backport patches CVE problems.
> CVE-2009-5030 http://code.google.com/p/openjpeg/source/detail?r=1703
> CVE-2012-1499 http://code.google.com/p/openjpeg/source/detail?r=1330
> CVE-2012-3358 http://code.google.com/p/openjpeg/source/detail?r=1727
> gs/openjpeg/libopenjpeg/j2k.c
> gs/openjpeg/libopenjpeg/jp2.c
> gs/openjpeg/libopenjpeg/tcd.c

2012-08-06 08:43:48 +0100
Chris Liddell <chris.liddell@artifex.com>
20157526924fbe59436170085a17e530d08e9807

> Bug 693223: remove apparently moribund dumphint tool
> dumphint.ps and the scripts which call it seem to be of almost no value
> these days, and appear to have suffered "bit rot". So remove them.
> CLUSTER_UNTESTED
> gs/lib/dumphint
> gs/lib/dumphint.bat
> gs/lib/dumphint.ps

2012-08-02 23:14:09 -0700
Ray Johnston <ray.johnston@artifex.com>
e48e87f883df0d39d1409d814c5d15444c3dca07

> Bug 693185. The limitcheck in validatedevicenspace must match int_remap_color_info_s.
> Commit e884e3 masked the failure, but since the test in validatedevicenspace
> used GS_CLIENT_COLOR_MAX_COMPONENTS, the array bounds could still be exceeded.
> Note that the confusing error message from the PDF interpreter from comment 1
> still exists unless -dPDFSTOPONERROR is used, which gives a more meaningful
> 'limitcheck' immediately following the 'Do' of the image with 17 DeviceN
> components. Bug 693185 is reopened for the error message as P3.
> gs/base/gsccolor.h
> gs/psi/icremap.h
> gs/psi/zcolor.c

2012-08-02 20:34:26 -0700
Michael Vrhel <michael.vrhel@artifex.com>
588c2ee040526fbea470e36e7cbc8e87a503cab9

> Update documentation for tiffsep planar device
> Add in comments about the use of -dMaxSpots as well as the fact that the device,
> and psdcmyk are planar and limited to 64 colorants per page. Also add in a
> hint about using -dMaxSpots when we are processing a Postscript file and bump
> up to the default max limit of 10 colorants. Tested it and it worked nicely.
> Thanks Robin Watts.
> gs/base/gdevpsd.c
> gs/base/gdevtsep.c
> gs/doc/Devices.htm

2012-08-02 18:27:45 +0100
Robin Watts <robin.watts@artifex.com>
836a551b97dd4a8436608b6dcebe8f8fb8632bcd

> Add -dMaxSpots for tiffsep and psd devices.
> psd and tiffsep devices now run with GS_SOFT_MAX_SPOTS spots enabled
> by default (ten, unless predefined differently at build time). The
> user can change this value using -dMaxSpots=X (where
> 0 <= X <= GS_CLIENT_COLOR_MAX_COMPONENTS-4).
> gs/base/gdevpsd.c
> gs/base/gdevtsep.c
> gs/base/gsccolor.h

2012-08-01 22:14:44 +0100
Chris Liddell <chris.liddell@artifex.com>
d723d72b3c9f7e171299a5ccc70a5f1ca715a50a

> Fix the -disable-gtk "so" build option
> No cluster differences.
> gs/base/configure.ac

2012-08-01 14:07:49 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
7e7b4ae93066b841c0b1eac539c220b79d7f7a5d

> Fix lcms2 64-bit value decoding on big endian systems
> that lack 64-bit types or have these types missed by configuration.
> gs/lcms2/src/cmsplugin.c

2012-07-31 17:53:58 +0100
Robin Watts <robin.watts@artifex.com>
c832985cab3b769d460a3f3e0ae894c2a84fa1ba

> Update tiffsep/tiffsep1 documentation w.r.t downscaler.
> Document 32 and 34 ratios. Add extra info to tiffsep1 to distinguish
> it from tiffsep in 1bpp mode.
> gs/doc/Devices.htm

2012-07-31 15:25:13 +0100
Chris Liddell <chris.liddell@artifex.com>
af22330035dc852635b2102353cec1a94504cb88

> Update docs for 9.06 release candidate 1.
> gs/doc/API.htm
> gs/doc/C-style.htm
> gs/doc/Commprod.htm
> gs/doc/DLL.htm
> gs/doc/Deprecated.htm
> gs/doc/Details8.htm
> gs/doc/Details9.htm
> gs/doc/Develop.htm
> gs/doc/Devices.htm
> gs/doc/Drivers.htm
> gs/doc/Fonts.htm
> gs/doc/Helpers.htm
> gs/doc/History1.htm
> gs/doc/History2.htm
> gs/doc/History3.htm
> gs/doc/History4.htm
> gs/doc/History5.htm
> gs/doc/History6.htm
> gs/doc/History7.htm
> gs/doc/History8.htm
> gs/doc/History9.htm
> gs/doc/Install.htm
> gs/doc/Issues.htm
> gs/doc/Language.htm
> gs/doc/Lib.htm
> gs/doc/Make.htm
> gs/doc/News.htm
> gs/doc/Projects.htm
> gs/doc/Ps-style.htm
> gs/doc/Ps2epsi.htm
> gs/doc/Ps2pdf.htm
> gs/doc/Ps2ps2.htm
> gs/doc/Psfiles.htm
> gs/doc/Readme.htm
> gs/doc/Release.htm
> gs/doc/Source.htm
> gs/doc/Unix-lpr.htm
> gs/doc/Use.htm
> gs/doc/WhatIsGS.htm
> gs/doc/Xfonts.htm
> gs/doc/gs-vms.hlp
> gs/doc/thirdparty.htm
> gs/man/dvipdf.1
> gs/man/font2c.1
> gs/man/gs.1
> gs/man/gslp.1
> gs/man/gsnd.1
> gs/man/pdf2dsc.1
> gs/man/pdf2ps.1
> gs/man/pdfopt.1
> gs/man/pf2afm.1
> gs/man/pfbtopfa.1
> gs/man/printafm.1
> gs/man/ps2ascii.1
> gs/man/ps2epsi.1
> gs/man/ps2pdf.1
> gs/man/ps2pdfwr.1
> gs/man/ps2ps.1
> gs/man/wftopfa.1

2012-07-31 10:50:43 +0100
Robin Watts <robin.watts@artifex.com>
76722bee735462eedf4f4c6d9dfa552e3c1f7ebc

> Fix link warnings about bad memset in gdevtsep.c
> Due to a mistake on my part, the tiffsep device had a couple of
> memsets in that did nothing; these were intended to clear an array
> of pointers before use. Not clearing the array would only have been
> a problem if we'd hit an error condition in a very small region of
> code, but nonetheless, this is a fix.
> gs/base/gdevtsep.c

2012-07-31 08:40:18 +0100
Chris Liddell <chris.liddell@artifex.com>
1e7ca769528b822b94ad8d1e498bde44d861637b

> Product string and date updates.
> gs/base/gscdef.c
> gs/base/version.mak

## Version 9.06 (2012-07-31)

This is the sixth full release in the stable 9.x series.

Highlights in this release include:

- PDF/A-2 - pdfwrite now supports the creation of PDF/A-2 files. The 'PDFA' command line switch can now take a numeric parameter:

  - 0 = not PDF/A compliant
  - 1 = PDF/A-1b compliant
  - 2 = PDF/A-2b compliant

  Simply specifying "-dPDFA" continues to have the old behaviour of creating PDF/A-1b files. For PDF/A-2 the command line should include "-dPDFA=2".

- pdfwrite "Server mode" - pdfwrite can now be run in "server mode" which allows the device to be closed without closing the interpreter. This means it is no longer necessary to terminate GS before starting a new PDF conversion. This leads on to:

- pdfwrite now supports the "%d" format in the OutputFile switch. If this is set then pdfwrite will output each page of input to an individual file.

- ps2write - recent exposure to a range of PostScript devices has thrown up some interesting deficiencies in those devices. ps2write now emits PostScript in slightly different ways in order to produce output on a wider variety of devices. In some cases this also results in improved print times but it is still important to set the resolution appropriately for the output device, especially if the input contains transparency.

- Ghostscript can now use output intents defined in PDFs by using the "-dUsePDFX3Profile" command line option. See ICC Color Parameters for details.

- tiffsep/tiffsep1: support for large numbers of separations improved. The previous implementation of those devices utilised a "compressed color encoding" to represent the tints for all the plates in one 64 bit value. As the number of plates increased, fewer bits were available for the tint for each plate, ultimately resulting in an "unencodable pixels" error. These revisions remove the reliance on the compressed color encoding, thus ensuring that we have a consistent color bit depth, regardless of the number of plates, and ensuring the "unencodable pixels" error will never occur.

  Also as a result of these changes, there are substantial performance improvements in jobs with separations and transparency.

- tiffsep, psdcmyk and psdrgb now support the "downscaler" functionality. This brings the "tiffscaled" style functionality to the DeviceN output devices, so jobs can be rendered internally in contone and at a high resolution, and the output optionally downsampled by a level specified by "-dDownScaleFactor=n", and also optionally error diffused to 1bpp output.

- Third party libraries: libtiff, libpng, libjpeg , Freetype and zlib have all be updated.

- clist storage, for rendering pages in bands, is now a run-time option: -sBandListStorage={file|memory}.

- Plus the usual round of bug fixes, compatibility changes, and incremental improvements.

In addition, Ghostscript and GhostPDL 8.71 are now unsupported, and those still using those versions (or earlier ones) should migrate to 9.x as soon as possible since many improvements, features and fixes from the 9.x versions are impractical or impossible to back-port to these legacy versions.

For a list of open issues, or to report problems, please visit bugs.ghostscript.com.

### Incompatible changes

No recorded incompatible changes.

### Changelog

2012-08-06 23:37:19 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
291872308da215e1d7e12c8375fcf10dd5e651d2

> Backport patches CVE problems.
> CVE-2009-5030 http://code.google.com/p/openjpeg/source/detail?r=1703
> CVE-2012-1499 http://code.google.com/p/openjpeg/source/detail?r=1330
> CVE-2012-3358 http://code.google.com/p/openjpeg/source/detail?r=1727
> gs/openjpeg/libopenjpeg/j2k.c
> gs/openjpeg/libopenjpeg/jp2.c
> gs/openjpeg/libopenjpeg/tcd.c

2012-08-06 08:43:48 +0100
Chris Liddell <chris.liddell@artifex.com>
20157526924fbe59436170085a17e530d08e9807

> Bug 693223: remove apparently moribund dumphint tool
> dumphint.ps and the scripts which call it seem to be of almost no value
> these days, and appear to have suffered "bit rot". So remove them.
> CLUSTER_UNTESTED
> gs/lib/dumphint
> gs/lib/dumphint.bat
> gs/lib/dumphint.ps

2012-08-02 23:14:09 -0700
Ray Johnston <ray.johnston@artifex.com>
e48e87f883df0d39d1409d814c5d15444c3dca07

> Bug 693185. The limitcheck in validatedevicenspace must match int_remap_color_info_s.
> Commit e884e3 masked the failure, but since the test in validatedevicenspace
> used GS_CLIENT_COLOR_MAX_COMPONENTS, the array bounds could still be exceeded.
> Note that the confusing error message from the PDF interpreter from comment 1
> still exists unless -dPDFSTOPONERROR is used, which gives a more meaningful
> 'limitcheck' immediately following the 'Do' of the image with 17 DeviceN
> components. Bug 693185 is reopened for the error message as P3.
> gs/base/gsccolor.h
> gs/psi/icremap.h
> gs/psi/zcolor.c

2012-08-02 20:34:26 -0700
Michael Vrhel <michael.vrhel@artifex.com>
588c2ee040526fbea470e36e7cbc8e87a503cab9

> Update documentation for tiffsep planar device
> Add in comments about the use of -dMaxSpots as well as the fact that the device,
> and psdcmyk are planar and limited to 64 colorants per page. Also add in a
> hint about using -dMaxSpots when we are processing a Postscript file and bump
> up to the default max limit of 10 colorants. Tested it and it worked nicely.
> Thanks Robin Watts.
> gs/base/gdevpsd.c
> gs/base/gdevtsep.c
> gs/doc/Devices.htm

2012-08-02 18:27:45 +0100
Robin Watts <robin.watts@artifex.com>
836a551b97dd4a8436608b6dcebe8f8fb8632bcd

> Add -dMaxSpots for tiffsep and psd devices.
> psd and tiffsep devices now run with GS_SOFT_MAX_SPOTS spots enabled
> by default (ten, unless predefined differently at build time). The
> user can change this value using -dMaxSpots=X (where
> 0 <= X <= GS_CLIENT_COLOR_MAX_COMPONENTS-4).
> gs/base/gdevpsd.c
> gs/base/gdevtsep.c
> gs/base/gsccolor.h

2012-08-01 22:14:44 +0100
Chris Liddell <chris.liddell@artifex.com>
d723d72b3c9f7e171299a5ccc70a5f1ca715a50a

> Fix the -disable-gtk "so" build option
> No cluster differences.
> gs/base/configure.ac

2012-08-01 14:07:49 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
7e7b4ae93066b841c0b1eac539c220b79d7f7a5d

> Fix lcms2 64-bit value decoding on big endian systems
> that lack 64-bit types or have these types missed by configuration.
> gs/lcms2/src/cmsplugin.c

2012-07-31 17:53:58 +0100
Robin Watts <robin.watts@artifex.com>
c832985cab3b769d460a3f3e0ae894c2a84fa1ba

> Update tiffsep/tiffsep1 documentation w.r.t downscaler.
> Document 32 and 34 ratios. Add extra info to tiffsep1 to distinguish
> it from tiffsep in 1bpp mode.
> gs/doc/Devices.htm

2012-07-31 15:25:13 +0100
Chris Liddell <chris.liddell@artifex.com>
af22330035dc852635b2102353cec1a94504cb88

> Update docs for 9.06 release candidate 1.
> gs/doc/API.htm
> gs/doc/C-style.htm
> gs/doc/Commprod.htm
> gs/doc/DLL.htm
> gs/doc/Deprecated.htm
> gs/doc/Details8.htm
> gs/doc/Details9.htm
> gs/doc/Develop.htm
> gs/doc/Devices.htm
> gs/doc/Drivers.htm
> gs/doc/Fonts.htm
> gs/doc/Helpers.htm
> gs/doc/History1.htm
> gs/doc/History2.htm
> gs/doc/History3.htm
> gs/doc/History4.htm
> gs/doc/History5.htm
> gs/doc/History6.htm
> gs/doc/History7.htm
> gs/doc/History8.htm
> gs/doc/History9.htm
> gs/doc/Install.htm
> gs/doc/Issues.htm
> gs/doc/Language.htm
> gs/doc/Lib.htm
> gs/doc/Make.htm
> gs/doc/News.htm
> gs/doc/Projects.htm
> gs/doc/Ps-style.htm
> gs/doc/Ps2epsi.htm
> gs/doc/Ps2pdf.htm
> gs/doc/Ps2ps2.htm
> gs/doc/Psfiles.htm
> gs/doc/Readme.htm
> gs/doc/Release.htm
> gs/doc/Source.htm
> gs/doc/Unix-lpr.htm
> gs/doc/Use.htm
> gs/doc/WhatIsGS.htm
> gs/doc/Xfonts.htm
> gs/doc/gs-vms.hlp
> gs/doc/thirdparty.htm
> gs/man/dvipdf.1
> gs/man/font2c.1
> gs/man/gs.1
> gs/man/gslp.1
> gs/man/gsnd.1
> gs/man/pdf2dsc.1
> gs/man/pdf2ps.1
> gs/man/pdfopt.1
> gs/man/pf2afm.1
> gs/man/pfbtopfa.1
> gs/man/printafm.1
> gs/man/ps2ascii.1
> gs/man/ps2epsi.1
> gs/man/ps2pdf.1
> gs/man/ps2pdfwr.1
> gs/man/ps2ps.1
> gs/man/wftopfa.1

2012-07-31 10:50:43 +0100
Robin Watts <robin.watts@artifex.com>
76722bee735462eedf4f4c6d9dfa552e3c1f7ebc

> Fix link warnings about bad memset in gdevtsep.c
> Due to a mistake on my part, the tiffsep device had a couple of
> memsets in that did nothing; these were intended to clear an array
> of pointers before use. Not clearing the array would only have been
> a problem if we'd hit an error condition in a very small region of
> code, but nonetheless, this is a fix.
> gs/base/gdevtsep.c

2012-07-31 08:40:18 +0100
Chris Liddell <chris.liddell@artifex.com>
1e7ca769528b822b94ad8d1e498bde44d861637b

> Product string and date updates.
> gs/base/gscdef.c
> gs/base/version.mak

2012-07-30 19:05:08 +0100
Robin Watts <robin.watts@artifex.com>
443ad5a4885be7abf5a1e0777275eefbc5322cd2

> Up default GS_CLIENT_COLOR_MAX_COMPONENTS to 32.
> The planar changes have enabled us to increase the default maximum
> number of spot changes to 32. Tests show only a few differences
> due to roundings.
> Hopefully we can push it to 64 soon.
> gs/base/gsccolor.h

2012-07-27 13:47:49 -0700
Michael Vrhel <michael.vrhel@artifex.com>
71c939e116dcffe72bf0c8ece9c647805da7e655

> Pass the data_cs information into the minimal needed clist icc profile information
> The knowledge that the source space is gray is needed so that we handle the gray_to_K
> mapping correctly when going out to CMYK devices. Fixes a rendering issue in 29-07A.PS.
> Thanks to Robin Watts for doing a lot of the detective work.
> gs/base/gxclimag.c
> gs/base/gxclist.h
> gs/base/gxclrast.c

2012-07-25 23:58:40 -0700
Ray Johnston <ray.johnston@artifex.com>
428869d288d87d95fbcb5dcf8a0563003ff26294

> Fix bug 693220. The pdf14 device used compressed encoding in clist mode.
> The pdf14 device clist mode did not respect the USE_COMPRESSED_ENCODING
> setting always using compressed encoding, and ended up writing pure
> colors with num_bytes == -3. This was undetected because tiffsep1 is not
> part of the regression testing, and because the tiffsep1 device did not
> use 'planar' mode as the tiffsep device did. Also fixed some blanks before
> line ends and tab indents.
> Also, since planar mode is more efficient and allows for > 8 colorants
> tiffsep1 was changed to use planar mode, getting rid of the need for
> compressed color encoding in this file (maybe the last one).
> gs/base/gdevp14.c
> gs/base/gdevtsep.c

2012-07-26 18:55:30 +0100
Robin Watts <robin.watts@artifex.com>
8dfd92bc9d91105bd678940c20479fc9ecebbbdb

> Fix clist_copy_planes causing clist corruption.
> When clist_copy_planes is used with a planar device, it used to
> leave a gap (9 bytes in the debugging example), then write the
> first planes data. Then it would write each subsequent plane (preceeded
> with a single byte gap). Then it would fill in the 9 bytes.
> Unfortunately, if the buffer filled up while copying one of the
> non-initial planes in, the date would be copied away and stored before
> the header was filled in.
> This leads to clist corruption, and all sorts of problems ranging from
> rendering issues to SEGVs.
> The fix is to move the header writing forward to immediately after
> the first plane is successfully written.
> This was causing problems with a 72dpi unbanded rendering of
> tests_private/comparefiles/Bug692517.pdf to the psdcmyk device
> with GS_CLIENT_COLOR_MAX_COMPONENTS set to 32, but was also
> causing problems without the change in MAX_COMPONENTS.
> gs/base/gxclrect.c

2012-07-26 13:32:36 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
f43f3d2016ae165a392fad962cda196e60587f8c

> Bug 693147: monitors need max alignmrnt.
> On 32-bit SunOS 5.11 gp_monitor structure need larger alignment than
> 4-byte pointer. Make it an union and add 64-bit attributes to ensure
> proper alignment.
> gs/base/gpsync.h

2012-07-25 16:45:38 -0700
Michael Vrhel <michael.vrhel@artifex.com>
d3bfe9bf857bb804a9bf710cccb36e3b78b9d663

> Fix so that the image_render_frac handles sep color spaces correctly
> The separation color spaces were not being handled properly in this renderer.
> Also, if the device supported devn colors we were not packing them into the
> correct type.
> gs/base/gxi12bit.c
> gs/base/lib.mak

2012-07-25 22:02:00 -0700
Michael Vrhel <michael.vrhel@artifex.com>
c8fc89fe8d72ad87158569825ddf421887c47713

> Replace magic 32 number with MAX_COMPONENTS_IN_DEVN
> gs/base/gsccolor.h
> gs/psi/icremap.h

2012-07-24 21:40:05 -0700
Michael Vrhel <michael.vrhel@artifex.com>
e884e39691346b35ea8b87fe26d8d98857689397

> Change the remap_color_info structure so that we can support up to 32 colorants DeviceN
> AR supports up to 32 colorants in a DeviceN color space and this brings us in line with
> that product's limits. Note that if the number of colorants is greater than
> GS_CLIENT_COLOR_MAX_COMPONENTS then we end up using the alternate tint transform.
> Previously, the tint transform would fail if we encountered a color DeviceN color
> space with more that GS_CLIENT_COLOR_MAX_COMPONENTS colorants. This fixes bug 693185
> gs/psi/icremap.h

2012-07-25 13:26:41 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
61fd8053c2c0b653df3d461b791ca3f61767c4f5

> Bug 693210: check for scanning big arrays
> Check whether the size of an scanned array exceed the current
> max_arra_size and throw /limitcheck. Old code tried to allocate big
> arrays, which caused a cascade of obscure errors.
> gs/psi/iscan.c

2012-07-25 18:12:23 +0100
Robin Watts <robin.watts@artifex.com>
1e0744128be80ff2a0acb48a2c5e018dbb32c168

> More fixes for deep color in the clist.
> In the previous commit I missed the reading code for the delta color
> form. Updated here.
> gs/base/gxclrast.c

2012-07-25 14:14:25 +0100
Chris Liddell <chris.liddell@artifex.com>
b750aec711bde8505173622d590eabdda2f3d789

> Bug 692824: only apply word spacing to single byte space
> PDF word spacing is defined as only applying to character codes of one byte
> with the value 32. We were using widthshow/awidthshow to implement word
> spacing, but the character matching for those means any character code
> with the value 32 will have the width applied: so both <32> and <0032> will
> have word spacing applied, where only the former should.
> I've added two customer operators (.pdfwidthshow and .pdfawidthshow) which the
> PDF interpreter now uses. Those trigger a small additional capability in the
> graphics lib code which ensures space is only allowed to be the single byte
> value 32.
> Cluster progressions with this patch seen in fts_20_2001.pdf and
> fts_22_2202.pdf - no other differences.
> gs/Resource/Init/pdf_ops.ps
> gs/base/gstext.c
> gs/base/gxchar.c
> gs/base/gxtext.h
> gs/psi/zchar.c

2012-07-25 13:40:31 +0100
Robin Watts <robin.watts@artifex.com>
ee0365f54e5d2cd80f5cae501d13d796094d022a

> Avoid cmd_put_color being confused by deep color.
> With high level color, we can have depths that are too bit to fit in
> a gx_color_index. cmd_put_color has no idea how many bits of a
> gx_color_index are used, so assumes that as many bits are used as
> are in the target depth. The encoding used goes wrong when the number
> of bits is bigger it guesses at is bigger than the number of bits in
> a gx_color_index.
> The fix is simply to change the writing and reading code to be smarter
> about guessing; when writing/reading a gx_color_index you can never
> need to write more bits than there are actually in a gx_color_index.
> While debugging this code, I spotted that the devn_{write,read}_color
> routines were always leaving an unused byte at the end of their commands.
> Trim that here.
> gs/base/gxclrast.c
> gs/base/gxclutil.c
> gs/base/gxdcolor.c

2012-07-25 13:05:35 +0100
Chris Liddell <chris.liddell@artifex.com>
7de5b7e3b3c64f8c7dd01df54e8223ab1275684a

> Remove a couple of unused variables.
> CLUSTER_UNTESTED
> gs/base/gxblend.c

2012-07-25 08:12:19 +0100
Chris Liddell <chris.liddell@artifex.com>
0caff3862d36e99ba5d14077c58e88bd9a082c83

> Bug 693216: replace "word-wise" copies with memcpy()
> Various places in the blending code used a loop to explicitly copy bytes from
> the input buffer to the output, with the comment that the idiom used was
> actually quicker than using memcpy(). The idiom in question relies on casting
> the byte buffer to a four byte type. This raises the spectre of unaligned
> accesses.
> Testing suggests any difference between the word-wise copying and "modern"
> memcpy implementations is non-existent, or too small to measure (my tests
> showed more variation between runs than between the two implementations).
> We reckon the memcpy() solution is more maintainable in the long term than
> forcing the buffers into alignment.
> No cluster differences.
> gs/base/gxblend.c

2012-07-20 15:46:06 +0100
Robin Watts <robin.watts@artifex.com>
a06bb8cfd8791254655889d85a1d37f173f53597

> Rework colors_used to be a color_usage bitfield.
> Previously, the clist would collate the colors used in a band/page
> by ORing together any color indexs uses into a single gx_color_index.
> This relies on the gx_color_index being able to represent the whole
> depth.
> This is dodgy with compressed encoding, and fails entirely with the
> new planar based tiffsep/psdcmyk and high level color stuff, as the
> total depth can far exceed the number of bits available in a
> gx_color_index.
> The fix here is to change to using a bitfield (gx_color_usage_bits)
> for this record; this allows us to have up to 64 colorants with a
> standard build.
> The code here is still imperfect for all the reasons listed within
> the original code (only works for subtractive spaces, can falsely
> detect 'no colors used', etc), but it is at least consistently
> imperfect now.
> gs/base/gdevpbm.c
> gs/base/gdevprn.c
> gs/base/gdevprn.h
> gs/base/gxband.h
> gs/base/gxcldev.h
> gs/base/gxclimag.c
> gs/base/gxclist.c
> gs/base/gxclist.h
> gs/base/gxclpath.c
> gs/base/gxclpath.h
> gs/base/gxclread.c
> gs/base/gxclrect.c

2012-07-24 16:28:00 +0100
Chris Liddell <chris.liddell@artifex.com>
7319a6de58e1986c5500d6181db158d3084da099

> Bug 693219 - Clarify default output device description
> Patch submitted by: roucaries.bastien+gs@gmail.com
> CLUSTER_UNTESTED
> gs/man/gs.1

2012-07-24 15:16:46 +0100
Robin Watts <robin.watts@artifex.com>
83f1aed5358d314cc52b5c243f94bbecb1e4469b

> When unpacking 16 bit image data, unpack it all.
> Ensure we don't miss the last one off. Differences appear on the right
> hand edge of the images when rendering:
> gs -dNOINTERPOLATE -o out-%d.psd -sDEVICE=psdcmyk -r300 -dMaxBitmap=10000 fts_02_0200.pdf
> vs
> gs -dNOINTERPOLATE --debug=memfill-empty -o out-%d.psd -sDEVICE=psdcmyk -r300 -dMaxBitmap=10000 fts_02_0200.pdf
> gs/base/gxi16bit.c

2012-07-23 17:19:21 +0100
Robin Watts <robin.watts@artifex.com>
ef036b230f33ce1d9cdd135655319d3828ca6008

> Bug 693204: Fix masked devn uncolored pattern error
> In the old (non device n) code copy_portrait calls
> gx_dc_default_fill_masked which calls gx_device_color_fill_rectangle
> (actually gx_dc_pure_masked_fill_rect).
> In the new code copy_portrait calls gx_dc_devn_fill_masked. This
> function is almost identical, but results in calls to the
> fill_rectangle_hl_color device procedure. This turns out to be
> clist_fill_rectangle_hl_color, which tries to cmd_put_drawing_color.
> This fails (and indeed would have failed in the old code) as we cannot
> serialise a masked color.
> If instead of calling the device procedure to fill_rectangle_hl_color,
> we call the device color procedure to fill a rectangle, this exactly
> mirrors the old code, and indeed results in calls to the
> fill_rectangle_hl_color code in a way that don't give errors.
> gs/base/gxdcolor.c

2012-07-23 14:27:30 +0100
Chris Liddell <chris.liddell@artifex.com>
f661e5225bb017d15b50c2aecda7d4283f8f3aa9

> Bug 693205: check for "sane" page dimensions in x11 drivers
> In the x11 devices, the page size is used to request the window dimensions from
> X, and X does not support 0 x 0 sized windows.
> If a page size is, or rounds to 0 x 0, inform the user, and return a
> rangecheck error.
> CLUSTER_UNTESTED
> gs/base/gdevxini.c

2012-07-23 14:15:01 +0100
Chris Liddell <chris.liddell@artifex.com>
7dfac701b8a36395a88a69b3a1e9eeaaa70c6b0b

> Bug 693208: improve error feedback (when we can)
> Have configure check for the presence of strerror() and if it's available,
> have gp_strerror() call it.
> No cluster differences.
> gs/base/Makefile.in
> gs/base/configure.ac
> gs/base/gp_unix.c

2012-07-22 13:30:12 -0700
Ray Johnston <ray.johnston@artifex.com>
9ef234a8a065f2240173bd1d5131418d171fbf4a

> Another fix for bug 692542 for garbled output with NumRenderingThreads > 1.
> The multi-threaded rendering "predicts" which direction to start threads,
> but the 'next_band' calculation in clist_get_band_from_thread was not
> correct if the thread prediction was incorrect as it would be if the
> device requested bands in other than the normal order as happens when
> the device makes multiple rendering passes (psdcmyk) or NumCopies > 1.
> Also, depending on the number of bands, 'clist_teardown_render_threads'
> could free the main thread's 'data' area, then later point the cdev->data
> to the freed block, also leaving one of the thread's data blocks leaked
> (releasing the chunk memory for the thread would free this, so the leak
> would be temporary).
> gs/base/gxclist.h
> gs/base/gxclthrd.c

2012-07-20 22:46:02 -0700
Michael Vrhel <michael.vrhel@artifex.com>
5a7b42637b166615c3c1e3b553bd86d1dced329b

> Fix so that when we are doing the sep devices with spots the blend spaces for transparency remain separated
> This fixes bug 693144 first part which is the segv for Bug6992217.pdf which likely existed prior to the
> planar change for the sep devices. The issue with 12-07C.PS is different. In any event, the
> issue was that there was a fill with a pattern in a softmask and there was an RGB transparency group
> within the pattern. With the separation devices, the blending space is maintained as a subtractive
> space to allow blending of all the spot colorants which means that the parent group is always maintained.
> There is a discussion about this in the PDF specification with respect to spot colors and transparency
> blending. In any event, the current code has some confusion since the decision as to if we should use
> the group color space was based upon the device name (e.g. pdf14cmykspot) which became a problem when we
> had the pdf14clistgray device when the pattern was a clist.
> gs/base/gdevp14.c

2012-07-20 15:33:24 +0100
Ken Sharp <ken.sharp@artifex.com>
9986753fb7e45556980e5b661dedba2fe9d2f92c

> ps2write - Emit a %%BeginResource for FOntFile resources
> Previously we were emittign an %%EndResource comment but not a %%BeginResource
> No differences sxpected
> gs/base/gdevpdtd.c

2012-07-20 13:48:17 +0100
Chris Liddell <chris.liddell@artifex.com>
3f0bee24591c8f690bd121fee272d925247ce307

> Stamp on a warning in fapiufst.c
> Sort out the path length, and parameters to strncat() with the stand gs maximum path length value.
> No cluster differences.
> gs/psi/fapiufst.c

2012-07-19 19:02:04 +0100
Robin Watts <robin.watts@artifex.com>
39f5af403d9cf49b9419a85e3569436907ade65d

> Solve psdcmyk SEGVs when max components reaches 32.
> Max components reaching 32 means that the total depth reaches 256.
> Attempting to pack 256 into a byte for the clist leads to obvious
> problems.
> gs/base/gsptype1.c

2012-07-20 00:03:13 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
1213e26fd9d71526855e1978c7440f7175413fcb

> Bug 693199: Ignore broken %%ViewingOrientation
> Add a check whether the comment has been parsed successfully.
> If not, ignore the comment.
> gs/psi/zdscpars.c

2012-07-20 10:27:32 +0100
Ken Sharp <ken.sharp@artifex.com>
01dc18e8418fc44a993840f0aeaf741929c1921a

> ps2write - Always ascii hex encode the eexec portion of type 1 fonts
> Bug #693197 "ps2write outputs Type 1 fonts in pfb format"
> Technically it is possible for the eexec portion of a type 1 font to be in
> binary or ascii hex. Because we always ascii85 encode binary data if the
> device does not support it, we left eexec portion as binary.
> However it seems that at least some printers (Kyocera, possibly others) are
> unable to deal with this.
> This patch means that we alays use ascii hex data for the eexec encrypted
> portion of a type 1 font. We did consider making this a command line option
> but were unable to find any other tools which emitted binary here so opted
> simply to conform.
> All the investigation and the original patch (see bug report) by Chris Liddell
> No differences expected
> gs/base/gdevpdtb.c
> gs/base/gdevpsf1.c

2012-07-19 15:40:03 -0700
Ray Johnston <ray.johnston@artifex.com>
04392ddc8b6a369b0ec4dfd9d0e9c894d1aa729e

> Fix bug 692542. NumRenderingThreads > 1 failed with planar devices.
> The tile_cache_size was inconsistent resulting in the 'data' area
> being miscalculated if the prn_device was set up in planar mode.
> gs/base/gxclthrd.c

2012-07-19 13:16:29 -0700
Michael Vrhel <michael.vrhel@artifex.com>
c7f3d73ea47bba783872ac193585601a4760dcfd

> Fix for bug in the named color example support
> When the example in gs\toolbin\color\named_color is run we get a segv. It was due to
> the name information not getting set up in the nameed color structure that the example uses.
> It essentially uses an ICC for with the named spot color data packed into the buffer.
> gs/base/gsicc_manage.c

2012-07-19 12:42:38 -0700
Michael Vrhel <michael.vrhel@artifex.com>
ddc361cee517d73f4977c7600d9853cc1813ad1f

> Fix of bug in setting source based rendering intent for RGB objects
> There were several typos caused by copy and past of the CMYK code for
> setting rendering intents. Thanks to Stefan Lietermann for finding this.
> gs/base/gsicc_manage.c

2012-07-18 23:05:23 -0700
Michael Vrhel <michael.vrhel@artifex.com>
17a42fca39c61c256cc5bab4d343f6bf38ae5109

> Add in support for copy_planes into the overprint device
> The copy_planes procedure is used during the default copy_alpha_hl_color and if we
> are going out to the overprint device, we need to make sure to copy only those
> planes that are specified in the drawn components vector. We also needed to
> distinguish from this case and a copy_planes coming from the pattern tiling code.
> This was done by adding in a copy_alpha_hl_color proc for the overprint device that
> sets a flag and calls the default copy_alpha_hl_color so that later when we get
> back to the overprint device's copy_planes proc we will know to do the over print
> rather than just pass things along to the target device. Fixes Bug 693184.
> gs/base/gsovrc.c

2012-07-19 16:37:27 +0100
Chris Liddell <chris.liddell@artifex.com>
44b01d274db5272055de6afb3d72788b6db84d53

> Bug 693188: don't skip glyphs with degenerate matrices
> In commit 752397ab, the fix for Bug 692263 was to skip over glyphs when the
> matrix in force for the glyph had a zero scale in either dimension.
> It seems that this approach had potentially unfavourable side effects in the
> glyph cache.
> So, when we encounter a degenerate matrix rendering a glyph, we now force a
> minimal, non-zero scale before attempting to render the glyph. This placates
> the glyph cache.
> Cluster testing shows (tiny) progressions in Bug689006.pdf, Bug690179.pdf,
> and Bug692634.ps, and pixel differences, not identifiable as progressions
> or regressions in Bug690497.pdf and 12-07C.PS.
> gs/psi/fapi_ft.c
> gs/psi/fapibstm.c
> gs/psi/fapiufst.c
> gs/psi/ifapi.h
> gs/psi/zfapi.c

2012-07-18 20:57:54 +0100
Robin Watts <robin.watts@artifex.com>
71ddb93b2b679c980a4024fcc1089c2d56abc3ab

> Recognise Darken and Lighten as idempotent rendering modes.
> No need to set the lop_pdf14 bit, and consequently makes files that
> use stroking with Darken/Lighten much faster. See Bug 693173.
> gs/base/gdevp14.c

2012-07-18 13:11:35 +0100
Robin Watts <robin.watts@artifex.com>
8a25653ddb875c29172b62eff48bec0147d09aab

> Update scrollbar handling in Windows windows.
> Drag ghostscript kicking and screaming into the 1980s by adding
> proportional scrollbar handling.
> gs/psi/dwimg.c
> gs/psi/dwtext.c
> pl/dwimg.c

2012-07-17 12:52:59 -0700
Michael Vrhel <michael.vrhel@artifex.com>
d7b56aa8c3b39e58d2b5faefd33ecb7e377f097e

> Fix for bug in clist copy planes procedure.
> The clist copy planes procedure was not indexing through the planes during the clist writing.
> The 2nd plane was getting replicated into all the other subsequent planes. This is a bug fix
> for 693061. I also added a message for when we are in debug and going out to a device that
> supports devn color to notify us of a case where we have DeviceN color spaces with \None colorants.
> As mentioned in bug 693061 Comment 5 this causes a problem for the composite preview in the
> separation devices. Ink amounts for the separations will be correct, but without having the \None
> colorant ink amounts, the preview is not going to be correct.
> gs/base/devs.mak
> gs/base/gsequivc.c
> gs/base/gxclrect.c

2012-07-13 13:05:06 +0100
Robin Watts <robin.watts@artifex.com>
a88326f1ca382092c889ffa9be1abe857c118a34

> Bug 693166: Optimise interpolation
> When interpolating, ghostscript pays no heed to the clipping rectangle.
> Hence if we scale (say) a 256x256 image up to (say)17067x17067, even
> though only a small portion of the scaled up image is actually visible
> we scale the whole lot only to throw away 90%+ of it.
> To fix this, we have to extend the capabilities of the interpolation
> code.
> The existing code already copes with only being given data for a
> subsection of the image (for when we split images in the clist, I
> guess). This rectangle is referred to in the code as being 'the
> subrectangle we are rendering', when it's actually 'the subtrectangle
> we are being given data for'. We update the description to be more
> accurate.
> We introduce a new rectangle, 'the render rectangle' to indicate the
> subrectangle that we are actually rendering - this will always be a
> subset of the data rectangle.
> If we are given a clipping rectangle, we read the outer bbox from it,
> and map this back into the source space of the image; we intersect this
> with the data rectangle to get the render rectangle.
> We update the scaling stream filter to set an 'Active' flag to say
> whether we are inside the render rectangle or not. If not, we can
> safely skip lines in their totality. By default we leave this set to
> 1, so that any scaling cores that aren't updated to know about this
> will perform in the old way.
> We update the scaling code to make use of the Active flag; whole lines
> are skipped if we aren't in the active region, and if we are, we skip
> prefixes/suffixes of unused pixels.
> We update the scaling cores themselves to avoid calculating values
> outside the active regions.
> Note that for simplicity we still allocate space as if we were
> accessing the whole line. We still calculate contributions for the whole
> of the images; to do otherwise would require significant changes to
> the weight generation code, and this isn't a huge consumer of time.
> gs/base/gximage.h
> gs/base/gxipixel.c
> gs/base/gxiscale.c
> gs/base/siscale.c
> gs/base/sisparam.h

2012-07-17 13:28:01 +0100
Robin Watts <robin.watts@artifex.com>
cbcd1dc873db397af0866f9fd54a70421dc6692f

> Tweak interpolation calculations
> In preparation for the next commit, tweak the image interpolation
> calculations; rather than doing a matrix multiplication and then
> only using the X coords from it, change to doing both width and
> height calculations in the same way.
> This causes various (350ish) small changes in interpolation output
> due to rounding issues.
> gs/base/gxiscale.c

2012-07-16 22:16:35 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
2f12f569672d84a1846905c41701fca52f8dc55e

> Bug 689376: fix //name handling on command prompt.
> We allocate %statementedit in the system memory. When a is read from
> the command prompt we use gs_scan_token() to determine, whether the
> line has a complete token. If the line has immediately evaluated names,
> gs_scan_token() fails. This is interpreted as the end of the input.
> If the line buffer has a complete token, the buffer is rescanned
> and everything is fine. Otherwise, scanning a prematurely closed buffer
> causes an error.
> All we need to do to fix this is to force local memory allocation
> instead of inheriting system memory from %statementedit. The scanned
> token is discarded after determining whether the input line is
> complete.
> gs/psi/ziodev.c

2012-07-16 13:00:46 +0100
Ken Sharp <ken.sharp@artifex.com>
b49d3c75a70cbdcdb2214f22ad1a1f62f1bb90fc

> ps2write - create document %%BoundingBox from teh individual page Bounding boxes
> Bug #693181
> The document level BoundingBox is supposed to be the intersection of the
> boundingbox of all the pages, whereas in fact it is the device media size.
> Now we create the document BoundingBox by taking largest dimensions from all
> the pages in the output.
> NB the BoundingBox for each page is given from the media request, so this is
> not a true BoundingBox anyway, but at least it is better then before.
> gs/base/gdevpdfu.c

2012-07-14 16:25:13 -0700
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
479b462ffa4663a71a88d185aaf7cc5c4f5d1903

> Replaced an '==' that was incorrectly being used for equality testing in configure with '='.
> gs/tiff/configure
> gs/tiff/configure.ac

2012-07-13 12:25:27 +0100
Chris Liddell <chris.liddell@artifex.com>
808f39dd443b1e475f6d9bfd320d79d793124d3f

> Bug 692684: stack variable corruption
> In alloc_restore_step_in(), we have to make sure that, whenever we back up
> a memory space to the previous save level, we hold onto the gc_status.psignal
> pointer, and put it into the restored memory space. In case the "save"
> happened during an earlier call to interp() and co.
> No cluster differences.
> gs/psi/isave.c

2012-07-13 14:14:47 -0700
Michael Vrhel <michael.vrhel@artifex.com>
fef9eef583d2ac227d3f9037785e27f1d5ecfc0d

> Fix for missing variable set in overprint code from enhancement of simulated RGB overprint
> Fixes Bug 693085
> gs/base/gscspace.c

2012-07-13 16:15:22 -0400
Wendy <wendyst2@gmail.com>
cdf018f4dc9e7765a8c3851c2e66edaad5642a0b

> Add missing '\n' to the last line, required by MSVC 7.
> gs/base/gxcldev.h

2012-07-13 13:54:36 +0100
Ken Sharp <ken.sharp@artifex.com>
57fe0115f01724b3c50812678c63924d008a01d9

> pdfwrite - code cleanup
> Deprecated the undocumented 'MaxViewerMemorySize' parameter whcih wasn't in
> fact being used anywhere useful.
> Deprecated the 'pdf_write_and_free_all_resoruces' function which is not used
> after deprecating MaxViewerMemorySize.
> Deprecated the function 'pdf_glyph_origin' as it is unused
> made 'write-font_resources' non-static so it can be called from pdf_close
> Deprecated pdf_close_text_document and moved the code (which actually writes
> fonts and font descriptors) into pdf_close so that its easier to follow the
> control flow. Also cleaned up the code so that it isn't one huge 'if' test
> but each function call is separated out for easier debugging.
> Made a number of '#if 0' blocks into '#ifdef DEPRECATED_906'. All blocks of
> code marked this way will be removed after the release of 9.06.
> Removed a number of cases where we had #define labels with a bug number, these
> now use the #ifdef DEPRECATED_906 lable or are simply removed and the code
> compiled in.
> Simlarly with '#define RIGHT_SBW' and '#if !RIGHT_SBW'
> Updated the ps2ps2.htm document to remove the reference to MaxViewerMemorySize.
> No differences expected.
> gs/Resource/Init/gs_pdfwr.ps
> gs/base/gdevpdf.c
> gs/base/gdevpdfb.h
> gs/base/gdevpdfc.c
> gs/base/gdevpdfp.c
> gs/base/gdevpdfu.c
> gs/base/gdevpdfx.h
> gs/base/gdevpdt.h
> gs/base/gdevpdte.c
> gs/base/gdevpdtf.h
> gs/base/gdevpdtt.c
> gs/base/gdevpdtw.c
> gs/base/gdevpsds.c
> gs/doc/Ps2ps2.htm

2012-07-12 11:56:12 +0100
Chris Liddell <chris.liddell@artifex.com>
9d73413d5ccb44b11a644848422dfb17e51eb7da

> Changes to build on msys/mingw
> Allows all the system header presence macros previously set in unix-aux.mak to
> be set by configure instead. The tests remain unix-aux.mak for backwards
> compatibility.
> This also changes those macros to the "tri-value" style:
> undefined, defined 0 and defined 1.
> Also removes jbig2dec/config_types.h from source control.
> No cluter differences.
> gs/base/Makefile.in
> gs/base/configure.ac
> gs/base/dirent_.h
> gs/base/gp_unifn.c
> gs/base/gp_unifs.c
> gs/base/openvms.mak
> gs/base/pipe_.h
> gs/base/time_.h
> gs/base/unix-aux.mak
> gs/doc/Make.htm
> gs/jbig2dec/config_types.h

2012-07-12 17:15:13 +0100
Ken Sharp <ken.sharp@artifex.com>
aa35587db7ba9dc469060d30d3313b318ca45bd5

> make the SEAC detector and type 1 -> type 2 charstring converter tolerate broken fonts
> Bug #693170 "ps2pdf crashes on a given file"
> The fonts in the PostScript file are invalid in that some of the glyphs do not
> end with an 'endchar' or other valid termination operator. This was causing
> a buffer overrun which eventually could cause access to invalid memory and a crash.
> Added limit checking where it was missing and choose to return an 'unknown'
> error so that code which is able to handle this can detect the condition. Code
> which is not expecting this contdition will continue to signal an error.
> No differences expected
> gs/base/gdevpsfx.c
> gs/base/gxtype1.c
> gs/base/gxtype1.h

2012-07-12 15:44:52 +0100
Robin Watts <robin.watts@artifex.com>
82ef3429ec2f3fc891a2f61455027842b7aa7581

> Revert "Move GC flag from stack to gs_lib_ctx."
> This reverts commit 39b0a515d5101cf48ae35f1ebb14e4558cb78e88.
> That commit doubled the runtime in cluster testing, so presumably
> gc was being triggered too often.
> gs/base/gslibctx.h
> gs/psi/imain.c
> gs/psi/interp.c

2012-07-12 08:42:38 -0400
SaGS <sags5495@hotmail.com>
b2e2def97f5b1664dc3d8e2be942a2de5857b802

> Bug 693155: 'resourceforall' returns truncated names for /CMap resources.
> (A)
> Comments say that gs_init.ps::.generate_dir_list_templates_with_length returns
> the legth of the "directory" part, but if actually returned the length of
> "[base] directory" + "template" - 1.
> (B)
> gs_res.ps::ResourceForAll passes part of the real "directory" (the "Category/")
> as part of the "template" argument of .generate_dir_list_templates_with_length,
> but failed to take into consideration the length of this string when cutting
> "directory" from the full filespec in order to remain with the resource name.
> Note that .generate_dir_list_templates_with_length does not check if its
> "template" argument contains directories too so cannot adjust the returned
> length. The code as written intends to deal with resource names that include
> .file_name_separator (see discussion on Bug 688737 "'resourceforall' truncates
> names of file-based resources"); such a resource name would be
> "Times/Cyrillic".
> gs/Resource/Init/gs_init.ps
> gs/Resource/Init/gs_res.ps

2012-07-12 13:29:24 +0100
Robin Watts <robin.watts@artifex.com>
29a16f87849a874cd872fc8e2beab2b3986eea51

> Bug 693171: Patch OpenJPEG to avoid SEGVs with broken files.
> Patch from Shailesh Mistry. In the case of corrupt files, tiles
> were failing to be allocated, leaving the code attempting to
> work with non existent tiles. The fix is to spot the failure,
> mark the tiles as being non-existence and then to check this
> before accessing them.
> gs/openjpeg/libopenjpeg/j2k.c
> gs/openjpeg/libopenjpeg/tcd.c

2012-07-12 11:44:29 +0100
Chris Liddell <chris.liddell@artifex.com>
514595fc2cc84f51efdef563cf7a35a0050902e5

> Bug 693038 - allow gsx to build against GTK+ 3.x
> Patch from galtgendo@gmail.com applied with changes to maintain compatibility
> with GTK+ 2.x, and replace a function deprecated in GTK+ 3.x.
> This patch drops GTK+ 1.x support.
> No cluster differences.
> gs/base/configure.ac
> gs/psi/dxmain.c

2012-07-12 09:20:35 +0100
Chris Liddell <chris.liddell@artifex.com>
b6252440c644b4f172c517a931fd3da73828f64c

> Fix for OpenJPEG build on FreeBSD
> Make sure OpenJPEG does not try to use memalign() on FreeBSD systems.
> Credit to Alex Zimnitsky ( aavzz@yandex.ru ) for the patch.
> No cluster differences.
> gs/openjpeg/libopenjpeg/opj_malloc.h

2012-07-12 00:11:37 -0400
SaGS <sags5495@hotmail.com>
e0deadb4b3661e6c4e0811b45d1c251e124632be

> Remove an additional, incorrect, search for resources,
> intended for OpenVMS only.
> ResourceForAll used a 2nd template for searching file-based resources,
> GenericResourceDir + Category
> + .file_name_separator + originaltemplate + .file_name_separator + "*"
> in addition to the standard
> GenericResourceDir + Category + .file_name_separator + originaltemplate
> This was documented as needed for OpenVMS, but it results in
> dev:[genericresourcedir.Category]originaltemplate]* ("]" twice)
> which is definitely invalid. It is also unnecessary, the "standard" one is OK.
> For other platforms, this 2nd form may or may not be syntacticly valid ("*?",
> coming in form the original template, in the "directory" part), but it's
> definitely not useful.
> Of course, it remains the question what was the intent of the person who added
> these lines (in case we should keep the code but fix it). I considered:
> - "dev:[genericresourcedir.Category.*]template", but this searches one
> directory level too deep.
> - "dev:[genericresourcedir.Category]template;*", but this would load all
> versions of a same file. Definitely not what we want, because we may end
> with an obsolete (old) copy of the resource.
> - "dev:[genericresourcedir.Category]template.*", but this is unnecessary. And
> maybe more important is that the exact template used is the responsability
> of the caller; I see no reason for ResourceForAll to modify it.
> The most precise documentation on OpenVMS path syntax I found is "Guide to
> OpenVMS File Applications"
> <http://h71000.www7.hp.com/doc/731final/documentation/pdf/ovms_731_file_app.pdf>
> available from <http://h71000.www7.hp.com/doc/os83_index.html>.
> I also asked on comp.os.vms, and the response I got confirmed the form used is
> invalid.
> gs/Resource/Init/gs_res.ps

2012-07-11 23:17:36 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
39b0a515d5101cf48ae35f1ebb14e4558cb78e88

> Move GC flag from stack to gs_lib_ctx.
> Move the GC flag from the stack, where it can go out of scope to
> lib context structure (gs_lib_ctx_t), which is allocated quite
> early in stable memory and never goes out of scope.
> Revert the commit a39e4831ba0d74d742b365f3b3b1af192731303c for the
> bug 692684 because it didn't really fix anything. That patch just
> changed the stack layout and masked the effect of writing into an
> out-of-scope location.
> The sample file 34_all.PS no longer causes SEGV but continues to
> have a resolution-dependant rendering of one character.
> gs/base/gslibctx.h
> gs/psi/imain.c
> gs/psi/interp.c

2012-07-11 18:27:44 +0200
Till Kamppeter <till.kamppeter@gmail.com>
c304a350330b3e333b34c048de009967f1a6caa1

> Fixed typos in comments.
> gs/base/lcms.mak
> gs/base/lcms2.mak

2012-07-11 15:51:27 +0100
Chris Liddell <chris.liddell@artifex.com>
4f6b98548bec2c10b10207d4f25b805fc393ade8

> Bug 693176: write transparent type2 pattern color to clist
> When using a clist, ensure that the all the color space data for the
> pattern gets written to the clist, *and* that the clist correctly
> records all the relevant transparency data.
> I'm at a loss to explain how COMPILE_INITS influenced this, but this
> change brings the clist/non-clist output and code in line with each
> other.
> No cluster differences.
> gs/base/gdevp14.c

2012-07-10 15:03:49 -0700
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
c7d2fbfef2ea176472c4459b3772ef3ac496ee5d

> Expanded -dDOINTERPOLATE section of Use.htm based on Robin's description of same.
> gs/doc/Use.htm

2012-07-09 14:04:16 -0700
Michael Vrhel <michael.vrhel@artifex.com>
f5d0a752ccd610aa4a3946e30e2a0917cacacf28

> Fix for mistake in commit 951adcd6 . which was the xps transparency fix
> Fixes the reopening of bug 693042
> xps/xpspath.c

2012-07-09 14:12:24 +0100
Chris Liddell <chris.liddell@artifex.com>
711883fd711772b7856e19207cc64f829033e254

> Bug 693172: Truetype: disable hinting for broken glyph program
> In the AFS Truetype code, if we encounter a glyph with a broken bytecode
> program reset and retry the glyph with the bytcode interpreter disabled.
> This reflects what the FAPI/Freetype does, and what most other TTF consumers
> seem to do.
> No cluster differences.
> gs/base/ttfmain.c

2012-07-07 13:50:54 -0700
Ray Johnston <ray.johnston@artifex.com>
c1815bdb424390c21289287d13f7e8747792c098

> Simplify the ICC options PS code to do a single .setuserparams2
> Use an array of names to collect all options that were set from the command
> line and then do a single .setuserparams2 invocation.
> gs/Resource/Init/gs_lev2.ps

2012-07-06 16:38:55 -0600
Henry Stiles <henry.stiles@artifex.com>
149974a4a14999d5e336911b262600e5fa950e18

> Fixes bug 693162, shifted text due to Vertical Motion Index command not
> resetting the cursor to the home position.
> pcl/pcpage.c
> pcl/pcursor.c

2012-07-06 00:15:51 -0700
Michael Vrhel <michael.vrhel@artifex.com>
74897ff7aeecb9a76dde73a6554444b40a89beec

> Use .setuserparams2 instead of .setuserparams when setting the ICC user params
> Thanks to Chris for pointing this out. If we use .setuserparams then in gs_lev2.ps the
> various user params such as /DefaultCMYKProfile are set. This sets the profile
> in the icc manager properly to what ever was set on the command line.
> Unfortunately, the currentuserparams dictionary (or what ever object it is)
> that is maintained by the interpreter is not updated with the same value, but
> instead it has an old default value that it obtained from an earlier call of
> .currentuserparams. During a vm_reclaim, context_state_store stores the
> outdated userparam information and then context_state_load does a call to
> set_user_params with this outdated userparams information. setuserparams2
> takes care of this by getting the interpreters list in sync at the time we do
> the setting of the parameter. Fixes bug 693159
> gs/Resource/Init/gs_lev2.ps

2012-06-29 17:39:31 -0700
Michael Vrhel <michael.vrhel@artifex.com>
951adcd68cf899a472b8c280e58fd7ff589badd3

> Fix in XPS interpreter to ensures we only push the smallest transparency group needed + more
> For a path that included an opacity mask, the XPS interpreter was pushing a soft mask
> that included the entire page (it actually just looked at the current clip path). This
> fix incorporates the path that we are filling in the computation of the transparency group
> size. Also, there were issues with the softmasks in general that were causing them to be
> double applied. Fixes 693042 and also provides improvements for 690951. Also this should fix 693137 and 692892
> gs/base/gspath.c
> gs/base/gstrans.c
> gs/base/gstrans.h
> gs/base/gxpath.h
> gs/base/lib.mak
> gs/psi/ztrans.c
> xps/ghostxps.h
> xps/xpsglyphs.c
> xps/xpsgradient.c
> xps/xpsimage.c
> xps/xpsopacity.c
> xps/xpspage.c
> xps/xpspath.c
> xps/xpstile.c

2012-07-04 17:32:21 +0200
Tor Andersson <tor@ccxvii.net>
2f71f5166422d5c61cb13c6078b2dfb1c3234db7

> Implement XPS style simulations using shearing and fill+stroke.
> Special case for pdfwrite to pass through Tr mode without using charpath
> by looking for PreserveTrMode in the device parameters.
> Fixes bug 689278.
> xps/ghostxps.h
> xps/xpsglyphs.c
> xps/xpstop.c

2012-07-03 22:52:19 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
31d9fb2b771272d7ba4712d8887c668d0e86d82e

> Bug 693050 : Fix compiler warnings
> gs/jbig2dec/jbig2_halftone.c

2012-07-03 15:48:43 +0100
Ken Sharp <ken.sharp@artifex.com>
0bc05670e841517b8a2041999c19c19507874a4a

> pdfwrite - when we have /Indexed space or non-identity transfer use lossless compression
> Bug #689506
> level 1 output from PScript5.dll can create a fake 'Indexed' space by using
> a non-identity transfer function. Also if we do have a real /Indexed space,
> then using lossy compression or downsmapling (other than Subsample) results
> in garbage output.
> Previously we disabled compression and subsampling when either condition was
> true, but this leads to large files under some conditions. The code here instead
> overrides any downsampling and uses Subsample instead, and selects a lossless
> compression scheme.
> This results in smaller files for some conditions without affecting ordinary files.
> Also removed a line with a C++ style comment
> No differences expected.
> gs/base/gdevpdfi.c

2012-07-03 14:55:30 +0100
Chris Liddell <chris.liddell@artifex.com>
ceac6867c04ef61e5529b0af14a2c4b641ca4206

> Bug 693164: PDF (partially) ignore tr mode for type 3 fonts
> The PDF spec states that: "The text rendering mode has no effect on text
> displayed in a Type 3 font" - unfortunately, not only does Acrobat not
> behave like that, it behaves differently with various versions Acrobat.
> Worse, Acrobat X Pro seems to produce different results depending on how you
> load the file!
> This change makes GS match Acrobat X Pro, which ignores text rendering modes
> for Type 3 fonts, except mode 3 (non-marking).
> As well as the problem file now working, this causes tiny differences in outline
> for Bug692129.pdf, chartab.pdf. It causes a progression with pdf-t3-simple.pdf
> which now renders more like Acro X.
> gs/Resource/Init/pdf_ops.ps

2012-07-02 22:49:17 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
e9bbff5f116eccd87946df28fced66ba42cbad1d

> Bug 693050 : Fix valgrind error in 0CF9 folder
> gs/jbig2dec/jbig2_refinement.c

2012-07-02 21:53:20 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
aad5317a0e77dac6fd2766b99c12c3ca7874c7d4

> Bug 693050 : Fix error handling in 0717 folder
> gs/jbig2dec/jbig2_halftone.c
> gs/jbig2dec/jbig2_mmr.c

2012-06-01 14:05:03 -0700
Michael Vrhel <michael.vrhel@artifex.com>
3a5a524ea71a58cc0e9e0200bb98a2fc341ec033

> Fix for broken AA support for devices that support the devn color type
> This fix involved the addition of a copy_alpha_hl_color for passing along the devn color
> value when doing the copy_alpha procedure. This required support through the clist,
> special handing in the pdf14 device and a default procedure for the operation.
> The only devices that should be affected are tiffsep and psdcmyk. Support for 16bit psd
> devices may have issues and I will go back to check on this later as a customer is waiting
> for this for 8 bit tiffsep.
> gs/base/gdevabuf.c
> gs/base/gdevdbit.c
> gs/base/gdevdflt.c
> gs/base/gdevmem.c
> gs/base/gdevmem.h
> gs/base/gdevmpla.c
> gs/base/gdevnfwd.c
> gs/base/gdevp14.c
> gs/base/gsdcolor.h
> gs/base/gspaint.c
> gs/base/gxccman.c
> gs/base/gxcldev.h
> gs/base/gxclip.c
> gs/base/gxclip.h
> gs/base/gxclip2.c
> gs/base/gxclipm.c
> gs/base/gxclist.c
> gs/base/gxclpath.h
> gs/base/gxclrast.c
> gs/base/gxclrect.c
> gs/base/gxdevcli.h
> gs/base/gxdevice.h
> gs/base/gxdevmem.h

2012-06-28 10:53:31 -0600
Henry Stiles <henry.stiles@artifex.com>
58d67647585fdb2707ccdb5eccc0123c77fbe495

> Bug 693156 - incorrect units.
> PCL distinguishes between device units and native units, and before
> this change we had interpreted them to be the same, resulting in what
> appeared to resolution dependencies in HPGL/2 - RTL. The native units
> can now be set by the PJL resolution given on the command line
> independent of the physical units of the device.
> pcl/pcjob.c

2012-06-28 11:07:22 +0100
Ken Sharp <ken.sharp@artifex.com>
dc797976bca27ea5c706d93f5fcb42b5386cc6ed

> pdfwrite - store widths for regular fonts when there is a vertical displacement.
> Bug #691369 "Widths array in font dictionary contains incorrect values for rotated text"
> Similar to bug #692365 but this time for regular fonts not CIDFonts. If there
> is any vertcial displacement of the glyph then we did not store teh glyph
> width, leading to it being emitted as 0.
> Fix is very similar also.
> No differences expected.
> gs/base/gdevpdte.c
> gs/base/gdevpdtt.c

2012-06-27 09:34:03 +0100
Ken Sharp <ken.sharp@artifex.com>
2ff29d1f499451c63ddb8b3cc152cb2eda4b5e33

> pdfwrite - record glyph vertical metrics evne when the position vector has a vertical shift
> Bug #692365
> The store_glyph_width routine returns >0 if there is any vertical shift in
> addition to a width, this is defined as 'not safe to cache'. The routine
> pdf_glyph_widths ORs that into its return value and passes the data back.
> scan_cmap_text was checking that value before recording the width, and not
> recording it if it was > 0. This is incorrect, at least when in vertical writing
> mode, as this is the only place that we record the vertical metrics for use
> in the W2 array. If we don't record them here this information is lost. Also
> we don't need to worry about the vertical movement here as that is dealt with
> elswewhere by modifying the text matrix.
> This was leading to pdfwrite emitting a /W2 entry with all 0 values [0 0 0]
> which caused significant misplacement of glyphs.
> Expected Differences
> Bug692576.ps exhibits a progression
> gs/base/gdevpdtc.c

2012-06-27 09:07:06 +0100
Chris Liddell <chris.liddell@artifex.com>
d026537beaf869a2792cf5d97e8b5c3555875f28

> Bug 693158: initialise the fapi_raster structure before use
> Fixes several valgrind errors about use of uninitialised values.
> No cluster differences expected.
> gs/psi/zfapi.c

2012-06-27 07:50:25 +0100
Chris Liddell <chris.liddell@artifex.com>
bc9efbeb2e69cd6d1aac4d14f30ba3b170e6a8f7

> Fix a small typo in README.txt
> CLUSTER_UNTESTED
> README.txt

2012-06-26 15:34:44 +0100
Robin Watts <robin.watts@artifex.com>
526c580e272ee15c488b9fe4845482a30ce05eef

> Bug 693064: raise maximum possible GS_CLIENT_COLOR_MAX_COMPONENTS to 32
> By default we support a maximum of 14 components. Supposedly this can be
> increased by raising GS_CLIENT_COLOR_MAX_COMPONENTS to a larger number
> on startup, but this starts to cause problems in various places throughout
> the code.
> The first such place is in the bpc_to_depth function (found in gdevdevn
> and various other places), where the calculation goes wrong for anything
> above 31 components at 8 bpc. We fix that here.
> This allows us to get to 32 components. To raise it above 32 presents
> problems on most architectures as the code assumes elsewhere that we
> can use a bitmask to represent which components are present.
> We may be able to tweak the code to use a uint64_t instead, in which
> case we can probably get to 64 components; is that high enough?
> gs/base/gdevdevn.c
> gs/base/gdevrinkj.c
> gs/base/gdevxcf.c
> gs/base/gxclist.c

2012-06-24 11:11:52 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
49fd8e8156bb5b751ff8a03e86ea61cb9c496a6b

> Bug 693142: Fix shape of highlight annotation.
> Draw rotated highlight annotation correctly. Fix a bug in calculation
> of the centers of the small arcs at the ends of the highlighted area.
> gs/Resource/Init/pdf_draw.ps

2012-06-23 23:57:19 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
5eff06782ad8c9b09f132add0d5f8a7458e0c7b2

> Bug 693050 : Fix error handling in dcbd folder
> gs/jbig2dec/jbig2_page.c

2012-06-23 23:00:47 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
b93322df872c8ff026127ea54fe86d3d940f1866

> Bug 693050 : Fix error handling in 9557 folder
> gs/jbig2dec/jbig2_symbol_dict.c

2012-06-23 22:14:43 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
ed7a9680adc24f0063455196d817810ff623f32a

> Bug 693050 : Fix memory leak in 4faa folder
> gs/jbig2dec/jbig2_symbol_dict.c

2012-06-23 21:12:19 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
b306b997740d3ad904d8dc6b82ee981b1db52bd2

> Bug 693050 : Fix error handling in 2908 folder
> gs/jbig2dec/jbig2_halftone.c

2012-06-22 22:25:44 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
8c497936e37bdf430b87fd65db3fa6070716fcdf

> Bug 693050 : Fix memory leak in 146f folder
> gs/jbig2dec/jbig2_mmr.c
> gs/jbig2dec/jbig2_symbol_dict.c

2012-06-22 16:56:39 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
b73adca0e4e3b9ad4a2e4fd5ba16f845362fa37b

> Bug 693050 : Fix minor typos and memory leak in 040d folder
> gs/jbig2dec/jbig2_arith.c
> gs/jbig2dec/jbig2_image.c
> gs/jbig2dec/jbig2_symbol_dict.c
> gs/jbig2dec/jbig2_text.c

2012-06-20 18:18:02 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
dc77e931b2a6118092bac21b4dd38bc10d41e644

> Bug 690723 : Prevent over writing unallocated memory when parsing an image
> gs/jbig2dec/jbig2_mmr.c

2012-06-19 11:57:57 +0100
Chris Liddell <chris.liddell@artifex.com>
9eb67bc021dda346896786e0d813245387649ce2

> Fix a parallel build problem......
> A couple of places that depend upon gconfig.h had their dependency listed as
> being gconfxx.h (would be created dynamically by its own target) and would
> then copy gconfxx.h to gconfig.h (I have no idea why this extra complication
> is there, but.....).
> With an unfortunate, but not uncommon confluence of two make instances, both
> instances could end up trying to copy gconfxx.h to gconfig.h, thus causing
> Unix "cp" (at least) to throw an error, and the build to fail.
> Now gconfig.h has its own target (which depends on gconfxx.h), and that
> target is where gconfxx.h is copied to gconfig.h, thus allowing make to
> correctly track the creation of the file.
> No cluster differences.
> gs/base/gs.mak
> gs/base/lib.mak
> gs/psi/int.mak

2012-06-18 16:51:30 +0100
Robin Watts <robin.watts@artifex.com>
7f98970a6c0e641e87eb202dc2087814249d0408

> Add 3:2 and 3:4 downscaling to tiffsep/psd/downscaler.
> Currently the downscaler can only downscale in integer increments. To
> accomodate a potential need to efficiently scale 1200 -> 800 and
> 600 -> 800 dpi, we introduce new functionality to allow 3:2 and 3:4
> scaling modes.
> We shoehorn these into the existing scaler system by using DownScaleFactor
> settings of 32 and 34 respectively; any other DownScaleFactor > 8 will
> give a rangecheck error.
> This has required some changes within the downscaler code itself, and
> will require more changes in any device that wants to use these. Currently
> the cores are only provided in the planar modes; hence tiffsep and psd are
> the only devices that have been updated to work with this.
> gs/base/gdevpsd.c
> gs/base/gdevtifs.c
> gs/base/gdevtsep.c
> gs/base/gxdownscale.c
> gs/base/gxdownscale.h

2012-06-18 13:42:07 +0200
Tor Andersson <tor.andersson@artifex.com>
7cd694d6e98719b77095069007e472334e16dd0e

> Check for opacity 0.0 in xps transparency analysis.
> Objects with opacity 0.0 are skipped by the parser, so we don't
> have to install transparency device for them.
> xps/xpsanalyze.c

2012-05-01 12:16:08 +0100
Tor Andersson <tor@ccxvii.net>
32c5d9122cf7ea813755d079f80445e6f2d842f4

> Move the has_transparency flag into the xps context.
> Patterns to set the uses_transparency flag. The current transparency scan
> doesn't resolve resources that have been inherited from a higher level.
> Doing this would require rewriting the entire transparency scanning and
> involve a lot more parsing. Instead we reuse the results from the
> original transparency scan we do at the beginning of the page.
> Fix bug 692513.
> xps/ghostxps.h
> xps/xpspage.c
> xps/xpstile.c

2012-06-18 10:01:46 +0100
Chris Liddell <chris.liddell@artifex.com>
0a33ed5b599d73509d0cde7e84e257e89ff1c1fb

> Fix comment delineation.
> I accidentally used the wrong comment delineator when I updated the copyright.
> CLUSTER_UNTESTED
> gs/toolbin/pdfinflt.ps

2012-06-15 19:22:52 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
64984bdf351dc27e40cbe5af5751dcdfcb448366

> Bug 693050 : Fixes CERT reported issues labelled DestAv
> gs/jbig2dec/jbig2.c
> gs/jbig2dec/jbig2_priv.h
> gs/jbig2dec/jbig2_symbol_dict.c
> gs/jbig2dec/jbig2_symbol_dict.h

2012-06-15 14:38:15 +0100
Chris Liddell <chris.liddell@artifex.com>
28a37f219de0bbd04bef9026812cbb9ea42a9910

> Add a default shared lib extension.
> Just a minor tweak so the dynamic library extension is set to *something*
> even on unrecognised platforms.
> No cluster differences.
> gs/base/configure.ac

2012-06-15 14:01:27 +0100
Chris Liddell <chris.liddell@artifex.com>
7c9a1a772cef2339c110238b40c73e8039dca2eb

> Revert some copyrights accidentally changed in the recent revamp
> Three files which are copyright FSF.
> Thanks to zeniko for spotting the mistake.
> No cluster differences.
> gs/jbig2dec/getopt.c
> gs/jbig2dec/getopt.h
> gs/jbig2dec/getopt1.c

2012-06-15 13:44:27 +0100
Chris Liddell <chris.liddell@artifex.com>
cd2cb0829b3a8ffe0e8a3bd87c08941663d691f9

> Bug 693113: configure set shared lib file extension
> Have the configure set the file extension for the shared library. This is
> purely to handle Apple's (pointless?) decision to make OS X use ".dylib" as
> the shared library extension, rather than the ".so" used by every other
> Unix-a-like.
> No cluster differences.
> gs/base/Makefile.in
> gs/base/configure.ac
> gs/base/macos-mcp.mak
> gs/base/macosx.mak
> gs/base/unix-dll.mak
> gs/base/unix-gcc.mak

2012-06-15 08:35:50 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
570984d2074289bb06261112d26bc323725c321e

> Bug 693119: Tweak EOL detection after 'stream'
> Modify EOL processing after 'stream' operator to accept a new class of
> broken PDF files. GS now stops skipping spaces when it finds '\n' or a
> non-space character.
> gs/Resource/Init/pdf_base.ps

2012-06-14 17:06:16 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
8988c41bf227e5f370fba7592bfd18e85330b0c2

> Bug 693050 : Fixes CERT reported issues labelled SourceAvNearNull
> gs/jbig2dec/jbig2_image.c
> gs/jbig2dec/jbig2_symbol_dict.c
> gs/jbig2dec/jbig2_text.c

2012-06-14 16:36:11 +0100
Ken Sharp <ken.sharp@artifex.com>
53cc9631a7725b0f6a20d815252c3a23b978d8ee

> Update pdf_info.ps to report the UserUnit for a page, if present.
> This allows users to correctly calculate media and crop sizes from the
> relevant 'Box' arrats.
> Not cluster tested
> gs/toolbin/pdf_info.ps

2012-06-13 14:24:18 -0600
Henry Stiles <henry.stiles@artifex.com>
d8fd89891d07d4b04cf180c3f5a4ac4388c769ce

> Fixes Bug 692991 - XL assembler and dissasembler now work with python 3.
> Thanks to Hin-Tak Leung for these changes.
> tools/pxlasm.py
> tools/pxldis.py

2012-06-13 13:29:35 -0600
Henry Stiles <henry.stiles@artifex.com>
76aad1b9e4eb2ae30d42b995a3ba8998b8e0820f

> Bug 690585 - Use the defalt strip copy rop routine when the
> destination is not included.
> Thanks to Hin-Tak Leung for this fix.
> CLUSTER UNTESTED
> gs/base/gdevpx.c

2012-06-13 18:40:02 +0100
Chris Liddell <chris.liddell@artifex.com>
c87f2d826726f8b1108d233096fa6fd4a872b020

> Fix parameter passed to dict_find_string()
> Parameter was a ref *, should have been a ref **.
> No cluster differences.
> gs/psi/zchar42.c

2012-06-13 18:37:27 +0100
Chris Liddell <chris.liddell@artifex.com>
e786619c57be0c846051ec264eb80b69a9ca42de

> Bug 693116: disable lzma compression in libtiff
> lzma is not part of base line tiff, but is enabled by default in libtiff, since
> we only support base line, disable lzma.
> No cluster differences.
> configure.ac
> gs/base/configure.ac

2012-06-13 13:15:32 +0100
Chris Liddell <chris.liddell@artifex.com>
85be3180530043232160745b04af9d293bd60fad

> Squash a warning in commit fae7be45
> No cluster differences.
> gs/psi/int.mak
> gs/psi/zchar42.c

2012-06-13 11:14:12 +0100
Chris Liddell <chris.liddell@artifex.com>
39433fce0a15c5cae831848edd4cefd55019a241

> Update copyright "headers".
> As agreed on IRC and via e-mail:
> Reinstate the reference to the LICENSE file.
> Remove copyright references to Aladdin Enterprises and artofcode (some
> references remain in comments about historical copyright assignments, and
> the like), in favour of Artifex copyright notices.
> Update copyright dates.
> Remove the $Id$ "tag".
> Since the move to git, the $Id$ "tag" comment in each file is redundant.
> No cluster differences.
> Makefile
> autogen.sh
> common/cp.bat
> common/gccdefs.mak
> common/generic.mak
> common/msvc_top.mak
> common/msvcdefs.mak
> common/mv.bat
> common/pcdefs.mak
> common/rm.bat
> common/sgidefs.mak
> common/ugcc_top.mak
> common/unixdefs.mak
> config.mak.in
> configure.ac
> gs/Resource/CIDFont/ArtifexBullet
> gs/Resource/CMap/Identity-UTF16-H
> gs/Resource/ColorSpace/DefaultCMYK
> gs/Resource/ColorSpace/DefaultGray
> gs/Resource/ColorSpace/DefaultRGB
> gs/Resource/ColorSpace/TrivialCMYK
> gs/Resource/ColorSpace/sGray
> gs/Resource/ColorSpace/sRGB
> gs/Resource/Decoding/FCO_Dingbats
> gs/Resource/Decoding/FCO_Symbol
> gs/Resource/Decoding/FCO_Unicode
> gs/Resource/Decoding/FCO_Wingdings
> gs/Resource/Decoding/Latin1
> gs/Resource/Decoding/StandardEncoding
> gs/Resource/Decoding/Unicode
> gs/Resource/Encoding/Wingdings
> gs/Resource/Init/FCOfontmap-PCLPS2
> gs/Resource/Init/Fontmap.GS
> gs/Resource/Init/cidfmap
> gs/Resource/Init/gs_agl.ps
> gs/Resource/Init/gs_btokn.ps
> gs/Resource/Init/gs_cet.ps
> gs/Resource/Init/gs_cff.ps
> gs/Resource/Init/gs_cidcm.ps
> gs/Resource/Init/gs_ciddc.ps
> gs/Resource/Init/gs_cidfm.ps
> gs/Resource/Init/gs_cidfn.ps
> gs/Resource/Init/gs_cidtt.ps
> gs/Resource/Init/gs_cmap.ps
> gs/Resource/Init/gs_cspace.ps
> gs/Resource/Init/gs_css_e.ps
> gs/Resource/Init/gs_dbt_e.ps
> gs/Resource/Init/gs_diskf.ps
> gs/Resource/Init/gs_diskn.ps
> gs/Resource/Init/gs_dpnxt.ps
> gs/Resource/Init/gs_dps.ps
> gs/Resource/Init/gs_dps1.ps
> gs/Resource/Init/gs_dps2.ps
> gs/Resource/Init/gs_dscp.ps
> gs/Resource/Init/gs_epsf.ps
> gs/Resource/Init/gs_fapi.ps
> gs/Resource/Init/gs_fntem.ps
> gs/Resource/Init/gs_fonts.ps
> gs/Resource/Init/gs_frsd.ps
> gs/Resource/Init/gs_icc.ps
> gs/Resource/Init/gs_il1_e.ps
> gs/Resource/Init/gs_img.ps
> gs/Resource/Init/gs_init.ps
> gs/Resource/Init/gs_l2img.ps
> gs/Resource/Init/gs_lev2.ps
> gs/Resource/Init/gs_ll3.ps
> gs/Resource/Init/gs_mex_e.ps
> gs/Resource/Init/gs_mgl_e.ps
> gs/Resource/Init/gs_mro_e.ps
> gs/Resource/Init/gs_pdf_e.ps
> gs/Resource/Init/gs_pdfwr.ps
> gs/Resource/Init/gs_res.ps
> gs/Resource/Init/gs_resmp.ps
> gs/Resource/Init/gs_setpd.ps
> gs/Resource/Init/gs_statd.ps
> gs/Resource/Init/gs_std_e.ps
> gs/Resource/Init/gs_sym_e.ps
> gs/Resource/Init/gs_trap.ps
> gs/Resource/Init/gs_ttf.ps
> gs/Resource/Init/gs_typ32.ps
> gs/Resource/Init/gs_typ42.ps
> gs/Resource/Init/gs_type1.ps
> gs/Resource/Init/gs_wan_e.ps
> gs/Resource/Init/pdf_base.ps
> gs/Resource/Init/pdf_cslayer.ps
> gs/Resource/Init/pdf_draw.ps
> gs/Resource/Init/pdf_font.ps
> gs/Resource/Init/pdf_main.ps
> gs/Resource/Init/pdf_ops.ps
> gs/Resource/Init/pdf_rbld.ps
> gs/Resource/Init/pdf_sec.ps
> gs/Resource/Init/xlatmap
> gs/Resource/SubstCID/CNS1-WMode
> gs/Resource/SubstCID/GB1-WMode
> gs/Resource/SubstCID/Japan1-WMode
> gs/Resource/SubstCID/Korea1-WMode
> gs/arch/windows-x64-msvc.h
> gs/arch/windows-x86-msvc.h
> gs/autogen.sh
> gs/base/ConvertUTF.c
> gs/base/ConvertUTF.h
> gs/base/Makefile.in
> gs/base/aes.c
> gs/base/aes.h
> gs/base/all-arch.mak
> gs/base/assert_.h
> gs/base/bench.c
> gs/base/catmake
> gs/base/configure.ac
> gs/base/contrib.mak
> gs/base/cp.bat
> gs/base/cp.cmd
> gs/base/ctype_.h
> gs/base/devs.mak
> gs/base/dirent_.h
> gs/base/dos_.h
> gs/base/echogs.c
> gs/base/errno_.h
> gs/base/expat.mak
> gs/base/fcntl_.h
> gs/base/freetype.mak
> gs/base/gconf.c
> gs/base/gconf.h
> gs/base/gdbflags.h
> gs/base/gdebug.h
> gs/base/gdev3852.c
> gs/base/gdev3b1.c
> gs/base/gdev4081.c
> gs/base/gdev4693.c
> gs/base/gdev8510.c
> gs/base/gdev8bcm.c
> gs/base/gdev8bcm.h
> gs/base/gdevabuf.c
> gs/base/gdevadmp.c
> gs/base/gdevagl.c
> gs/base/gdevagl.h
> gs/base/gdevatx.c
> gs/base/gdevbbox.c
> gs/base/gdevbbox.h
> gs/base/gdevbit.c
> gs/base/gdevbj10.c
> gs/base/gdevbjc.h
> gs/base/gdevbjcl.c
> gs/base/gdevbjcl.h
> gs/base/gdevbmp.c
> gs/base/gdevbmp.h
> gs/base/gdevbmpa.c
> gs/base/gdevbmpc.c
> gs/base/gdevccr.c
> gs/base/gdevcdj.c
> gs/base/gdevcfax.c
> gs/base/gdevcif.c
> gs/base/gdevclj.c
> gs/base/gdevcljc.c
> gs/base/gdevcp50.c
> gs/base/gdevcslw.c
> gs/base/gdevdbit.c
> gs/base/gdevdcrd.c
> gs/base/gdevdcrd.h
> gs/base/gdevddrw.c
> gs/base/gdevddrw.h
> gs/base/gdevdevn.c
> gs/base/gdevdevn.h
> gs/base/gdevdfax.c
> gs/base/gdevdflt.c
> gs/base/gdevdgbr.c
> gs/base/gdevdjet.c
> gs/base/gdevdjtc.c
> gs/base/gdevdljm.c
> gs/base/gdevdljm.h
> gs/base/gdevdm24.c
> gs/base/gdevdrop.c
> gs/base/gdevdsha.c
> gs/base/gdevdsp.c
> gs/base/gdevdsp.h
> gs/base/gdevdsp2.h
> gs/base/gdevemap.c
> gs/base/gdevepsc.c
> gs/base/gdevepsn.c
> gs/base/gdevescp.c
> gs/base/gdevevga.c
> gs/base/gdevfax.c
> gs/base/gdevfax.h
> gs/base/gdevherc.c
> gs/base/gdevhit.c
> gs/base/gdevhl7x.c
> gs/base/gdevicov.c
> gs/base/gdevifno.c
> gs/base/gdevijs.c
> gs/base/gdevimgn.c
> gs/base/gdevjbig2.c
> gs/base/gdevjpeg.c
> gs/base/gdevjpx.c
> gs/base/gdevl256.c
> gs/base/gdevl31s.c
> gs/base/gdevlbp8.c
> gs/base/gdevlj56.c
> gs/base/gdevlp8k.c
> gs/base/gdevlxm.c
> gs/base/gdevm1.c
> gs/base/gdevm16.c
> gs/base/gdevm2.c
> gs/base/gdevm24.c
> gs/base/gdevm32.c
> gs/base/gdevm4.c
> gs/base/gdevm40.c
> gs/base/gdevm48.c
> gs/base/gdevm56.c
> gs/base/gdevm64.c
> gs/base/gdevm8.c
> gs/base/gdevmac.c
> gs/base/gdevmac.h
> gs/base/gdevmacpictop.h
> gs/base/gdevmacttf.h
> gs/base/gdevmeds.c
> gs/base/gdevmeds.h
> gs/base/gdevmem.c
> gs/base/gdevmem.h
> gs/base/gdevmgr.c
> gs/base/gdevmgr.h
> gs/base/gdevmiff.c
> gs/base/gdevmpla.c
> gs/base/gdevmpla.h
> gs/base/gdevmr1.c
> gs/base/gdevmr2n.c
> gs/base/gdevmr8n.c
> gs/base/gdevmrop.h
> gs/base/gdevmrun.c
> gs/base/gdevmrun.h
> gs/base/gdevmswn.c
> gs/base/gdevmswn.h
> gs/base/gdevmsxf.c
> gs/base/gdevmx.c
> gs/base/gdevn533.c
> gs/base/gdevnfwd.c
> gs/base/gdevo182.c
> gs/base/gdevokii.c
> gs/base/gdevos2p.c
> gs/base/gdevp14.c
> gs/base/gdevp14.h
> gs/base/gdevp2up.c
> gs/base/gdevpbm.c
> gs/base/gdevpccm.c
> gs/base/gdevpccm.h
> gs/base/gdevpcfb.c
> gs/base/gdevpcfb.h
> gs/base/gdevpcl.c
> gs/base/gdevpcl.h
> gs/base/gdevpcx.c
> gs/base/gdevpdf.c
> gs/base/gdevpdfb.c
> gs/base/gdevpdfb.h
> gs/base/gdevpdfc.c
> gs/base/gdevpdfc.h
> gs/base/gdevpdfd.c
> gs/base/gdevpdfe.c
> gs/base/gdevpdfg.c
> gs/base/gdevpdfg.h
> gs/base/gdevpdfi.c
> gs/base/gdevpdfj.c
> gs/base/gdevpdfk.c
> gs/base/gdevpdfm.c
> gs/base/gdevpdfo.c
> gs/base/gdevpdfo.h
> gs/base/gdevpdfp.c
> gs/base/gdevpdfr.c
> gs/base/gdevpdft.c
> gs/base/gdevpdfu.c
> gs/base/gdevpdfv.c
> gs/base/gdevpdfx.h
> gs/base/gdevpdt.c
> gs/base/gdevpdt.h
> gs/base/gdevpdtb.c
> gs/base/gdevpdtb.h
> gs/base/gdevpdtc.c
> gs/base/gdevpdtd.c
> gs/base/gdevpdtd.h
> gs/base/gdevpdte.c
> gs/base/gdevpdtf.c
> gs/base/gdevpdtf.h
> gs/base/gdevpdti.c
> gs/base/gdevpdti.h
> gs/base/gdevpdts.c
> gs/base/gdevpdts.h
> gs/base/gdevpdtt.c
> gs/base/gdevpdtt.h
> gs/base/gdevpdtv.c
> gs/base/gdevpdtv.h
> gs/base/gdevpdtw.c
> gs/base/gdevpdtw.h
> gs/base/gdevpdtx.h
> gs/base/gdevpe.c
> gs/base/gdevperm.c
> gs/base/gdevphex.c
> gs/base/gdevpipe.c
> gs/base/gdevpjet.c
> gs/base/gdevplan.c
> gs/base/gdevplib.c
> gs/base/gdevplib.h
> gs/base/gdevplnx.c
> gs/base/gdevplnx.h
> gs/base/gdevpm.h
> gs/base/gdevpng.c
> gs/base/gdevppla.c
> gs/base/gdevppla.h
> gs/base/gdevprn.c
> gs/base/gdevprn.h
> gs/base/gdevprna.c
> gs/base/gdevprna.h
> gs/base/gdevps.c
> gs/base/gdevpsd.c
> gs/base/gdevpsdf.h
> gs/base/gdevpsdi.c
> gs/base/gdevpsdp.c
> gs/base/gdevpsds.c
> gs/base/gdevpsds.h
> gs/base/gdevpsdu.c
> gs/base/gdevpsf.h
> gs/base/gdevpsf1.c
> gs/base/gdevpsf2.c
> gs/base/gdevpsfm.c
> gs/base/gdevpsft.c
> gs/base/gdevpsfu.c
> gs/base/gdevpsfx.c
> gs/base/gdevpsim.c
> gs/base/gdevpsu.c
> gs/base/gdevpsu.h
> gs/base/gdevpx.c
> gs/base/gdevpxat.h
> gs/base/gdevpxen.h
> gs/base/gdevpxop.h
> gs/base/gdevpxut.c
> gs/base/gdevpxut.h
> gs/base/gdevrinkj.c
> gs/base/gdevrops.c
> gs/base/gdevs3ga.c
> gs/base/gdevsco.c
> gs/base/gdevsgi.c
> gs/base/gdevsgi.h
> gs/base/gdevsj48.c
> gs/base/gdevsnfb.c
> gs/base/gdevsppr.c
> gs/base/gdevstc.c
> gs/base/gdevstc.h
> gs/base/gdevstc1.c
> gs/base/gdevstc2.c
> gs/base/gdevstc3.c
> gs/base/gdevstc4.c
> gs/base/gdevsun.c
> gs/base/gdevsunr.c
> gs/base/gdevsvg.c
> gs/base/gdevsvga.c
> gs/base/gdevsvga.h
> gs/base/gdevtfax.c
> gs/base/gdevtfax.h
> gs/base/gdevtfnx.c
> gs/base/gdevtifs.c
> gs/base/gdevtifs.h
> gs/base/gdevtknk.c
> gs/base/gdevtrac.c
> gs/base/gdevtsep.c
> gs/base/gdevtxtw.c
> gs/base/gdevupd.c
> gs/base/gdevvec.c
> gs/base/gdevvec.h
> gs/base/gdevvglb.c
> gs/base/gdevwddb.c
> gs/base/gdevwdib.c
> gs/base/gdevwpr2.c
> gs/base/gdevwprn.c
> gs/base/gdevx.c
> gs/base/gdevx.h
> gs/base/gdevxalt.c
> gs/base/gdevxcf.c
> gs/base/gdevxcmp.c
> gs/base/gdevxcmp.h
> gs/base/gdevxini.c
> gs/base/gdevxres.c
> gs/base/genarch.c
> gs/base/genconf.c
> gs/base/gendev.c
> gs/base/genht.c
> gs/base/gp.h
> gs/base/gp_dosfe.c
> gs/base/gp_dosfs.c
> gs/base/gp_dvx.c
> gs/base/gp_getnv.c
> gs/base/gp_mac.c
> gs/base/gp_mac.h
> gs/base/gp_macio.c
> gs/base/gp_macpoll.c
> gs/base/gp_mktmp.c
> gs/base/gp_msdll.c
> gs/base/gp_msdos.c
> gs/base/gp_mshdl.c
> gs/base/gp_mslib.c
> gs/base/gp_mspol.c
> gs/base/gp_msprn.c
> gs/base/gp_mswin.c
> gs/base/gp_mswin.h
> gs/base/gp_nsync.c
> gs/base/gp_ntfs.c
> gs/base/gp_os2.c
> gs/base/gp_os2.h
> gs/base/gp_os2fs.c
> gs/base/gp_os2pr.c
> gs/base/gp_os9.c
> gs/base/gp_paper.c
> gs/base/gp_psync.c
> gs/base/gp_stdia.c
> gs/base/gp_stdin.c
> gs/base/gp_strdl.c
> gs/base/gp_sysv.c
> gs/base/gp_unifn.c
> gs/base/gp_unifs.c
> gs/base/gp_unix.c
> gs/base/gp_unix_cache.c
> gs/base/gp_upapr.c
> gs/base/gp_vms.c
> gs/base/gp_wgetv.c
> gs/base/gp_win32.c
> gs/base/gp_wpapr.c
> gs/base/gp_wsync.c
> gs/base/gp_wutf8.c
> gs/base/gpcheck.h
> gs/base/gpgetenv.h
> gs/base/gpmisc.c
> gs/base/gpmisc.h
> gs/base/gpsync.h
> gs/base/gs.mak
> gs/base/gs_dll_call.h
> gs/base/gs_mgl_e.h
> gs/base/gs_mro_e.h
> gs/base/gsalloc.c
> gs/base/gsalloc.h
> gs/base/gsalpha.c
> gs/base/gsalpha.h
> gs/base/gsalphac.c
> gs/base/gsalphac.h
> gs/base/gsargs.c
> gs/base/gsargs.h
> gs/base/gsbitcom.c
> gs/base/gsbitmap.h
> gs/base/gsbitops.c
> gs/base/gsbitops.h
> gs/base/gsbittab.c
> gs/base/gsbittab.h
> gs/base/gsccode.h
> gs/base/gsccolor.h
> gs/base/gscdef.c
> gs/base/gscdefs.h
> gs/base/gscdevn.c
> gs/base/gscdevn.h
> gs/base/gscedata.c
> gs/base/gscedata.h
> gs/base/gscencs.c
> gs/base/gscencs.h
> gs/base/gschar.c
> gs/base/gschar.h
> gs/base/gschar0.c
> gs/base/gscicach.c
> gs/base/gscicach.h
> gs/base/gscie.c
> gs/base/gscie.h
> gs/base/gsciemap.c
> gs/base/gscindex.h
> gs/base/gsclipsr.c
> gs/base/gsclipsr.h
> gs/base/gscms.h
> gs/base/gscolor.c
> gs/base/gscolor.h
> gs/base/gscolor1.c
> gs/base/gscolor1.h
> gs/base/gscolor2.c
> gs/base/gscolor2.h
> gs/base/gscolor3.c
> gs/base/gscolor3.h
> gs/base/gscolorbuffer.c
> gs/base/gscolorbuffer.h
> gs/base/gscompt.h
> gs/base/gscoord.c
> gs/base/gscoord.h
> gs/base/gscparam.c
> gs/base/gscpixel.c
> gs/base/gscpixel.h
> gs/base/gscpm.h
> gs/base/gscrd.c
> gs/base/gscrd.h
> gs/base/gscrdp.c
> gs/base/gscrdp.h
> gs/base/gscrypt1.c
> gs/base/gscrypt1.h
> gs/base/gscscie.c
> gs/base/gscsel.h
> gs/base/gscsepr.c
> gs/base/gscsepr.h
> gs/base/gscspace.c
> gs/base/gscspace.h
> gs/base/gscssub.c
> gs/base/gscssub.h
> gs/base/gsdcolor.h
> gs/base/gsdevice.c
> gs/base/gsdevice.h
> gs/base/gsdevmem.c
> gs/base/gsdfilt.c
> gs/base/gsdfilt.h
> gs/base/gsdll.h
> gs/base/gsdllwin.h
> gs/base/gsdparam.c
> gs/base/gsdpnext.h
> gs/base/gsdps.c
> gs/base/gsdps.h
> gs/base/gsdps1.c
> gs/base/gsdsrc.c
> gs/base/gsdsrc.h
> gs/base/gsequivc.c
> gs/base/gsequivc.h
> gs/base/gserrors.h
> gs/base/gsexit.h
> gs/base/gsfcid.c
> gs/base/gsfcid2.c
> gs/base/gsfcmap.c
> gs/base/gsfcmap.h
> gs/base/gsfcmap1.c
> gs/base/gsflip.c
> gs/base/gsflip.h
> gs/base/gsfname.c
> gs/base/gsfname.h
> gs/base/gsfont.c
> gs/base/gsfont.h
> gs/base/gsfont0.c
> gs/base/gsfont0c.c
> gs/base/gsfunc.c
> gs/base/gsfunc.h
> gs/base/gsfunc0.c
> gs/base/gsfunc0.h
> gs/base/gsfunc3.c
> gs/base/gsfunc3.h
> gs/base/gsfunc4.c
> gs/base/gsfunc4.h
> gs/base/gsgc.h
> gs/base/gsgcache.c
> gs/base/gsgcache.h
> gs/base/gsgdata.c
> gs/base/gsgdata.h
> gs/base/gshsb.c
> gs/base/gshsb.h
> gs/base/gsht.c
> gs/base/gsht.h
> gs/base/gsht1.c
> gs/base/gsht1.h
> gs/base/gshtscr.c
> gs/base/gshtx.c
> gs/base/gshtx.h
> gs/base/gsicc.c
> gs/base/gsicc.h
> gs/base/gsicc_cache.c
> gs/base/gsicc_cache.h
> gs/base/gsicc_cms.h
> gs/base/gsicc_create.c
> gs/base/gsicc_create.h
> gs/base/gsicc_lcms.c
> gs/base/gsicc_lcms2.c
> gs/base/gsicc_manage.c
> gs/base/gsicc_manage.h
> gs/base/gsicc_nocm.c
> gs/base/gsicc_profilecache.c
> gs/base/gsicc_profilecache.h
> gs/base/gsimage.c
> gs/base/gsimage.h
> gs/base/gsimpath.c
> gs/base/gsinit.c
> gs/base/gsio.h
> gs/base/gsiodev.c
> gs/base/gsiodevs.c
> gs/base/gsiodisk.c
> gs/base/gsiomacres.c
> gs/base/gsiorom.c
> gs/base/gsiorom.h
> gs/base/gsipar3x.h
> gs/base/gsiparam.h
> gs/base/gsiparm2.h
> gs/base/gsiparm3.h
> gs/base/gsiparm4.h
> gs/base/gsistate.c
> gs/base/gsjconf.h
> gs/base/gsjmorec.h
> gs/base/gslib.c
> gs/base/gslib.h
> gs/base/gslibctx.c
> gs/base/gslibctx.h
> gs/base/gsline.c
> gs/base/gsline.h
> gs/base/gslparam.h
> gs/base/gsmalloc.c
> gs/base/gsmalloc.h
> gs/base/gsmatrix.c
> gs/base/gsmatrix.h
> gs/base/gsmchunk.c
> gs/base/gsmchunk.h
> gs/base/gsmdebug.h
> gs/base/gsmemlok.c
> gs/base/gsmemlok.h
> gs/base/gsmemory.c
> gs/base/gsmemory.h
> gs/base/gsmemraw.h
> gs/base/gsmemret.c
> gs/base/gsmemret.h
> gs/base/gsmisc.c
> gs/base/gsnamecl.c
> gs/base/gsnamecl.h
> gs/base/gsncdummy.c
> gs/base/gsncdummy.h
> gs/base/gsnogc.c
> gs/base/gsnogc.h
> gs/base/gsnotify.c
> gs/base/gsnotify.h
> gs/base/gsovrc.c
> gs/base/gsovrc.h
> gs/base/gspaint.c
> gs/base/gspaint.h
> gs/base/gsparam.c
> gs/base/gsparam.h
> gs/base/gsparam2.c
> gs/base/gsparams.c
> gs/base/gsparams.h
> gs/base/gsparamx.c
> gs/base/gsparamx.h
> gs/base/gspath.c
> gs/base/gspath.h
> gs/base/gspath1.c
> gs/base/gspath2.h
> gs/base/gspcolor.c
> gs/base/gspcolor.h
> gs/base/gspenum.h
> gs/base/gspmdrv.c
> gs/base/gspmdrv.h
> gs/base/gspmdrv.rc
> gs/base/gsptype1.c
> gs/base/gsptype1.h
> gs/base/gsptype2.c
> gs/base/gsptype2.h
> gs/base/gsrect.h
> gs/base/gsrefct.h
> gs/base/gsromfs0.c
> gs/base/gsrop.c
> gs/base/gsrop.h
> gs/base/gsroprun.c
> gs/base/gsroprun1.h
> gs/base/gsroprun24.h
> gs/base/gsroprun8.h
> gs/base/gsropt.h
> gs/base/gsroptab.c
> gs/base/gsserial.c
> gs/base/gsserial.h
> gs/base/gsshade.c
> gs/base/gsshade.h
> gs/base/gsstate.c
> gs/base/gsstate.h
> gs/base/gsstruct.h
> gs/base/gsstype.h
> gs/base/gstext.c
> gs/base/gstext.h
> gs/base/gstparam.h
> gs/base/gstrans.c
> gs/base/gstrans.h
> gs/base/gstrap.c
> gs/base/gstrap.h
> gs/base/gstype1.c
> gs/base/gstype1.h
> gs/base/gstype2.c
> gs/base/gstype42.c
> gs/base/gstypes.h
> gs/base/gsuid.h
> gs/base/gsutil.c
> gs/base/gsutil.h
> gs/base/gswin.rc
> gs/base/gsxfont.h
> gs/base/gx.h
> gs/base/gxacpath.c
> gs/base/gxalloc.h
> gs/base/gxalpha.h
> gs/base/gxarith.h
> gs/base/gxband.h
> gs/base/gxbcache.c
> gs/base/gxbcache.h
> gs/base/gxbitfmt.h
> gs/base/gxbitmap.h
> gs/base/gxbitops.h
> gs/base/gxblend.c
> gs/base/gxblend.h
> gs/base/gxblend1.c
> gs/base/gxccache.c
> gs/base/gxccman.c
> gs/base/gxcdevn.h
> gs/base/gxchar.c
> gs/base/gxchar.h
> gs/base/gxchrout.c
> gs/base/gxchrout.h
> gs/base/gxcht.c
> gs/base/gxcid.h
> gs/base/gxcie.h
> gs/base/gxcindex.h
> gs/base/gxclbits.c
> gs/base/gxcldev.h
> gs/base/gxclfile.c
> gs/base/gxclimag.c
> gs/base/gxclio.h
> gs/base/gxclip.c
> gs/base/gxclip.h
> gs/base/gxclip2.c
> gs/base/gxclip2.h
> gs/base/gxclipm.c
> gs/base/gxclipm.h
> gs/base/gxclipsr.h
> gs/base/gxclist.c
> gs/base/gxclist.h
> gs/base/gxcllzw.c
> gs/base/gxclmem.c
> gs/base/gxclmem.h
> gs/base/gxclpage.c
> gs/base/gxclpage.h
> gs/base/gxclpath.c
> gs/base/gxclpath.h
> gs/base/gxclrast.c
> gs/base/gxclread.c
> gs/base/gxclrect.c
> gs/base/gxclthrd.c
> gs/base/gxclthrd.h
> gs/base/gxclutil.c
> gs/base/gxclzlib.c
> gs/base/gxcmap.c
> gs/base/gxcmap.h
> gs/base/gxcolor2.h
> gs/base/gxcomp.h
> gs/base/gxcoord.h
> gs/base/gxcpath.c
> gs/base/gxcpath.h
> gs/base/gxcspace.h
> gs/base/gxctable.c
> gs/base/gxctable.h
> gs/base/gxcvalue.h
> gs/base/gxdcconv.c
> gs/base/gxdcconv.h
> gs/base/gxdcolor.c
> gs/base/gxdcolor.h
> gs/base/gxdda.h
> gs/base/gxdevbuf.h
> gs/base/gxdevcli.h
> gs/base/gxdevice.h
> gs/base/gxdevmem.h
> gs/base/gxdevndi.c
> gs/base/gxdevndi.h
> gs/base/gxdevrop.h
> gs/base/gxdevsop.h
> gs/base/gxdht.h
> gs/base/gxdhtres.h
> gs/base/gxdhtserial.c
> gs/base/gxdhtserial.h
> gs/base/gxdither.h
> gs/base/gxdownscale.c
> gs/base/gxdownscale.h
> gs/base/gxdtfill.h
> gs/base/gxfapiu.c
> gs/base/gxfapiu.h
> gs/base/gxfarith.h
> gs/base/gxfcache.h
> gs/base/gxfcid.h
> gs/base/gxfcmap.h
> gs/base/gxfcmap1.h
> gs/base/gxfcopy.c
> gs/base/gxfcopy.h
> gs/base/gxfdrop.c
> gs/base/gxfdrop.h
> gs/base/gxfill.c
> gs/base/gxfill.h
> gs/base/gxfillsl.h
> gs/base/gxfilltr.h
> gs/base/gxfillts.h
> gs/base/gxfixed.h
> gs/base/gxfmap.h
> gs/base/gxfont.h
> gs/base/gxfont0.h
> gs/base/gxfont0c.h
> gs/base/gxfont1.h
> gs/base/gxfont42.h
> gs/base/gxfrac.h
> gs/base/gxftype.h
> gs/base/gxfunc.h
> gs/base/gxgetbit.h
> gs/base/gxhintn.c
> gs/base/gxhintn.h
> gs/base/gxhintn1.c
> gs/base/gxhldevc.c
> gs/base/gxhldevc.h
> gs/base/gxht.c
> gs/base/gxht.h
> gs/base/gxht_thresh.c
> gs/base/gxht_thresh.h
> gs/base/gxhtbit.c
> gs/base/gxhttile.h
> gs/base/gxhttype.h
> gs/base/gxi12bit.c
> gs/base/gxi16bit.c
> gs/base/gxiclass.h
> gs/base/gxicolor.c
> gs/base/gxidata.c
> gs/base/gxifast.c
> gs/base/gximag3x.c
> gs/base/gximag3x.h
> gs/base/gximage.c
> gs/base/gximage.h
> gs/base/gximage1.c
> gs/base/gximage2.c
> gs/base/gximage3.c
> gs/base/gximage3.h
> gs/base/gximage4.c
> gs/base/gximask.c
> gs/base/gximask.h
> gs/base/gximono.c
> gs/base/gxino12b.c
> gs/base/gxino16b.c
> gs/base/gxiodev.h
> gs/base/gxiparam.h
> gs/base/gxipixel.c
> gs/base/gxiscale.c
> gs/base/gxistate.h
> gs/base/gxline.h
> gs/base/gxlum.h
> gs/base/gxmatrix.h
> gs/base/gxmclip.c
> gs/base/gxmclip.h
> gs/base/gxobj.h
> gs/base/gxoprect.c
> gs/base/gxoprect.h
> gs/base/gxp1fill.c
> gs/base/gxp1impl.h
> gs/base/gxpageq.c
> gs/base/gxpageq.h
> gs/base/gxpaint.c
> gs/base/gxpaint.h
> gs/base/gxpath.c
> gs/base/gxpath.h
> gs/base/gxpath2.c
> gs/base/gxpcache.h
> gs/base/gxpcmap.c
> gs/base/gxpcolor.h
> gs/base/gxpcopy.c
> gs/base/gxpdash.c
> gs/base/gxpflat.c
> gs/base/gxrplane.h
> gs/base/gxsample.c
> gs/base/gxsample.h
> gs/base/gxsamplp.h
> gs/base/gxshade.c
> gs/base/gxshade.h
> gs/base/gxshade1.c
> gs/base/gxshade4.c
> gs/base/gxshade4.h
> gs/base/gxshade6.c
> gs/base/gxstate.h
> gs/base/gxstdio.h
> gs/base/gxstroke.c
> gs/base/gxsync.c
> gs/base/gxsync.h
> gs/base/gxtext.h
> gs/base/gxtmap.h
> gs/base/gxttf.h
> gs/base/gxttfb.c
> gs/base/gxttfb.h
> gs/base/gxtype1.c
> gs/base/gxtype1.h
> gs/base/gxxfont.h
> gs/base/gzacpath.h
> gs/base/gzcpath.h
> gs/base/gzht.h
> gs/base/gzline.h
> gs/base/gzpath.h
> gs/base/gzspotan.c
> gs/base/gzspotan.h
> gs/base/gzstate.h
> gs/base/icclib.mak
> gs/base/ijs.mak
> gs/base/instcopy
> gs/base/jasper.mak
> gs/base/jbig2.mak
> gs/base/jerror_.h
> gs/base/jpeg.mak
> gs/base/jpegxr.mak
> gs/base/lcms.mak
> gs/base/lcms2.mak
> gs/base/lcups.mak
> gs/base/lcupsi.mak
> gs/base/ldf_jb2.mak
> gs/base/lib.mak
> gs/base/locale_.h
> gs/base/lwf_jp2.mak
> gs/base/macgenmcpxml.sh
> gs/base/macos-fw.mak
> gs/base/macos-mcp.mak
> gs/base/macos_carbon_d_pre.h
> gs/base/macos_carbon_pre.h
> gs/base/macos_classic_d_pre.h
> gs/base/macosx.mak
> gs/base/macsystypes.h
> gs/base/malloc_.h
> gs/base/math_.h
> gs/base/md5.c
> gs/base/md5.h
> gs/base/md5main.c
> gs/base/memento.c
> gs/base/memento.h
> gs/base/memory_.h
> gs/base/minftrsz.c
> gs/base/minftrsz.h
> gs/base/mkromfs.c
> gs/base/msvccmd.mak
> gs/base/msvclib.mak
> gs/base/msvctail.mak
> gs/base/mv.bat
> gs/base/mv.cmd
> gs/base/opdfread.h
> gs/base/openjpeg.mak
> gs/base/openvms.mak
> gs/base/openvms.mmk
> gs/base/pcwin.mak
> gs/base/pipe_.h
> gs/base/png.mak
> gs/base/png_.h
> gs/base/rinkj/evenbetter-rll.c
> gs/base/rinkj/evenbetter-rll.h
> gs/base/rinkj/rinkj-byte-stream.c
> gs/base/rinkj/rinkj-byte-stream.h
> gs/base/rinkj/rinkj-config.c
> gs/base/rinkj/rinkj-config.h
> gs/base/rinkj/rinkj-device.c
> gs/base/rinkj/rinkj-device.h
> gs/base/rinkj/rinkj-dither.c
> gs/base/rinkj/rinkj-dither.h
> gs/base/rinkj/rinkj-epson870.c
> gs/base/rinkj/rinkj-epson870.h
> gs/base/rinkj/rinkj-screen-eb.c
> gs/base/rinkj/rinkj-screen-eb.h
> gs/base/rm.bat
> gs/base/rm.cmd
> gs/base/sa85d.c
> gs/base/sa85d.h
> gs/base/sa85x.h
> gs/base/saes.c
> gs/base/saes.h
> gs/base/sarc4.c
> gs/base/sarc4.h
> gs/base/sbcp.c
> gs/base/sbcp.h
> gs/base/sbhc.c
> gs/base/sbhc.h
> gs/base/sbtx.h
> gs/base/sbwbs.c
> gs/base/sbwbs.h
> gs/base/scanchar.h
> gs/base/scantab.c
> gs/base/scf.h
> gs/base/scfd.c
> gs/base/scfdgen.c
> gs/base/scfdtab.c
> gs/base/scfe.c
> gs/base/scfetab.c
> gs/base/scfparam.c
> gs/base/scfx.h
> gs/base/scommon.h
> gs/base/sdcparam.c
> gs/base/sdcparam.h
> gs/base/sdct.h
> gs/base/sdctc.c
> gs/base/sdctd.c
> gs/base/sdcte.c
> gs/base/sddparam.c
> gs/base/sdeparam.c
> gs/base/seexec.c
> gs/base/setjmp_.h
> gs/base/sfilter.h
> gs/base/sfilter2.c
> gs/base/sfxboth.c
> gs/base/sfxcommon.c
> gs/base/sfxfd.c
> gs/base/sfxstdio.c
> gs/base/shc.c
> gs/base/shc.h
> gs/base/shcgen.c
> gs/base/shcgen.h
> gs/base/sidscale.c
> gs/base/sidscale.h
> gs/base/siinterp.c
> gs/base/siinterp.h
> gs/base/simscale.c
> gs/base/simscale.h
> gs/base/siscale.c
> gs/base/siscale.h
> gs/base/sisparam.h
> gs/base/sjbig2.c
> gs/base/sjbig2.h
> gs/base/sjbig2_luratech.c
> gs/base/sjbig2_luratech.h
> gs/base/sjpeg.h
> gs/base/sjpegc.c
> gs/base/sjpegd.c
> gs/base/sjpege.c
> gs/base/sjpx.c
> gs/base/sjpx.h
> gs/base/sjpx_luratech.c
> gs/base/sjpx_luratech.h
> gs/base/sjpx_openjpeg.c
> gs/base/sjpx_openjpeg.h
> gs/base/slzwc.c
> gs/base/slzwd.c
> gs/base/slzwe.c
> gs/base/slzwx.h
> gs/base/smd5.c
> gs/base/smd5.h
> gs/base/smtf.c
> gs/base/smtf.h
> gs/base/spdiff.c
> gs/base/spdiffx.h
> gs/base/spngp.c
> gs/base/spngpx.h
> gs/base/spprint.c
> gs/base/spprint.h
> gs/base/spsdf.c
> gs/base/spsdf.h
> gs/base/srdline.h
> gs/base/srld.c
> gs/base/srle.c
> gs/base/srlx.h
> gs/base/ssha2.c
> gs/base/ssha2.h
> gs/base/sstring.c
> gs/base/sstring.h
> gs/base/stat_.h
> gs/base/std.h
> gs/base/stdint_.h
> gs/base/stdio_.h
> gs/base/stdpn.h
> gs/base/stdpre.h
> gs/base/stream.c
> gs/base/stream.h
> gs/base/strimpl.h
> gs/base/string_.h
> gs/base/strmio.c
> gs/base/strmio.h
> gs/base/szlibc.c
> gs/base/szlibd.c
> gs/base/szlibe.c
> gs/base/szlibx.h
> gs/base/szlibxx.h
> gs/base/tiff.mak
> gs/base/time_.h
> gs/base/ttcalc.c
> gs/base/ttcalc.h
> gs/base/ttcommon.h
> gs/base/ttconf.h
> gs/base/ttconfig.h
> gs/base/ttfinp.c
> gs/base/ttfinp.h
> gs/base/ttfmain.c
> gs/base/ttfmemd.c
> gs/base/ttfmemd.h
> gs/base/ttfoutl.h
> gs/base/ttfsfnt.h
> gs/base/ttinterp.c
> gs/base/ttinterp.h
> gs/base/ttload.c
> gs/base/ttload.h
> gs/base/ttmisc.h
> gs/base/ttobjs.c
> gs/base/ttobjs.h
> gs/base/tttables.h
> gs/base/tttype.h
> gs/base/tttypes.h
> gs/base/ugcclib.mak
> gs/base/unistd_.h
> gs/base/unix-aux.mak
> gs/base/unix-dll.mak
> gs/base/unix-end.mak
> gs/base/unix-gcc.mak
> gs/base/unixansi.mak
> gs/base/unixhead.mak
> gs/base/unixinst.mak
> gs/base/unixlink.mak
> gs/base/valgrind.h
> gs/base/vdtrace.c
> gs/base/vdtrace.h
> gs/base/version.mak
> gs/base/vms_x_fix.h
> gs/base/vmsmath.h
> gs/base/whitelst.c
> gs/base/whitelst.h
> gs/base/windows_.h
> gs/base/winlib.mak
> gs/base/winplat.mak
> gs/base/x_.h
> gs/base/zlib.mak
> gs/cups/colord.c
> gs/cups/colord.h
> gs/cups/cups.mak
> gs/cups/gdevcups.c
> gs/cups/gstopxl.in
> gs/cups/gstoraster.c
> gs/cups/pxlcolor.ppd
> gs/cups/pxlmono.ppd
> gs/doc/API.htm
> gs/doc/C-style.htm
> gs/doc/Changes.htm
> gs/doc/Commprod.htm
> gs/doc/DLL.htm
> gs/doc/Deprecated.htm
> gs/doc/Details.htm
> gs/doc/Details8.htm
> gs/doc/Details9.htm
> gs/doc/Develop.htm
> gs/doc/Devices.htm
> gs/doc/Drivers.htm
> gs/doc/Fonts.htm
> gs/doc/Helpers.htm
> gs/doc/Hershey.htm
> gs/doc/History1.htm
> gs/doc/History2.htm
> gs/doc/History3.htm
> gs/doc/History4.htm
> gs/doc/History5.htm
> gs/doc/History6.htm
> gs/doc/History7.htm
> gs/doc/History8.htm
> gs/doc/History9.htm
> gs/doc/Install.htm
> gs/doc/Issues.htm
> gs/doc/Language.htm
> gs/doc/Lib.htm
> gs/doc/Make.htm
> gs/doc/News.htm
> gs/doc/Projects.htm
> gs/doc/Ps-style.htm
> gs/doc/Ps2epsi.htm
> gs/doc/Ps2pdf.htm
> gs/doc/Ps2ps2.htm
> gs/doc/Psfiles.htm
> gs/doc/Readme.htm
> gs/doc/Release.htm
> gs/doc/Source.htm
> gs/doc/Unix-lpr.htm
> gs/doc/Use.htm
> gs/doc/WhatIsGS.htm
> gs/doc/Xfonts.htm
> gs/doc/gs-vms.hlp
> gs/doc/gs.css
> gs/doc/index.html
> gs/doc/pscet_status.txt
> gs/doc/thirdparty.htm
> gs/examples/waterfal.ps
> gs/freetype/src/gzip/adler32.c
> gs/freetype/src/gzip/zconf.h
> gs/freetype/src/gzip/zutil.c
> gs/freetype/src/gzip/zutil.h
> gs/ijs/Makefile.am
> gs/ijs/configure.ac
> gs/jasper/src/libjasper/base/jas_cm.c
> gs/jasper/src/libjasper/base/jas_getopt.c
> gs/jasper/src/libjasper/base/jas_image.c
> gs/jasper/src/libjasper/base/jas_malloc.c
> gs/jasper/src/libjasper/base/jas_seq.c
> gs/jasper/src/libjasper/base/jas_stream.c
> gs/jasper/src/libjasper/base/jas_string.c
> gs/jasper/src/libjasper/base/jas_tvp.c
> gs/jasper/src/libjasper/bmp/bmp_cod.c
> gs/jasper/src/libjasper/bmp/bmp_cod.h
> gs/jasper/src/libjasper/bmp/bmp_dec.c
> gs/jasper/src/libjasper/bmp/bmp_enc.c
> gs/jasper/src/libjasper/include/jasper/jas_cm.h
> gs/jasper/src/libjasper/include/jasper/jas_debug.h
> gs/jasper/src/libjasper/include/jasper/jas_fix.h
> gs/jasper/src/libjasper/include/jasper/jas_getopt.h
> gs/jasper/src/libjasper/include/jasper/jas_image.h
> gs/jasper/src/libjasper/include/jasper/jas_malloc.h
> gs/jasper/src/libjasper/include/jasper/jas_math.h
> gs/jasper/src/libjasper/include/jasper/jas_seq.h
> gs/jasper/src/libjasper/include/jasper/jas_stream.h
> gs/jasper/src/libjasper/include/jasper/jas_string.h
> gs/jasper/src/libjasper/include/jasper/jas_tvp.h
> gs/jasper/src/libjasper/include/jasper/jas_types.h
> gs/jasper/src/libjasper/include/jasper/jas_version.h
> gs/jasper/src/libjasper/jp2/jp2_cod.c
> gs/jasper/src/libjasper/jp2/jp2_cod.h
> gs/jasper/src/libjasper/jp2/jp2_enc.c
> gs/jasper/src/libjasper/jpc/jpc_bs.c
> gs/jasper/src/libjasper/jpc/jpc_bs.h
> gs/jasper/src/libjasper/jpc/jpc_cod.h
> gs/jasper/src/libjasper/jpc/jpc_cs.c
> gs/jasper/src/libjasper/jpc/jpc_cs.h
> gs/jasper/src/libjasper/jpc/jpc_dec.c
> gs/jasper/src/libjasper/jpc/jpc_dec.h
> gs/jasper/src/libjasper/jpc/jpc_enc.c
> gs/jasper/src/libjasper/jpc/jpc_enc.h
> gs/jasper/src/libjasper/jpc/jpc_fix.h
> gs/jasper/src/libjasper/jpc/jpc_flt.h
> gs/jasper/src/libjasper/jpc/jpc_math.c
> gs/jasper/src/libjasper/jpc/jpc_mct.c
> gs/jasper/src/libjasper/jpc/jpc_mct.h
> gs/jasper/src/libjasper/jpc/jpc_mqcod.c
> gs/jasper/src/libjasper/jpc/jpc_mqcod.h
> gs/jasper/src/libjasper/jpc/jpc_mqdec.c
> gs/jasper/src/libjasper/jpc/jpc_mqdec.h
> gs/jasper/src/libjasper/jpc/jpc_mqenc.c
> gs/jasper/src/libjasper/jpc/jpc_mqenc.h
> gs/jasper/src/libjasper/jpc/jpc_qmfb.c
> gs/jasper/src/libjasper/jpc/jpc_qmfb.h
> gs/jasper/src/libjasper/jpc/jpc_t1cod.c
> gs/jasper/src/libjasper/jpc/jpc_t1cod.h
> gs/jasper/src/libjasper/jpc/jpc_t1dec.c
> gs/jasper/src/libjasper/jpc/jpc_t1dec.h
> gs/jasper/src/libjasper/jpc/jpc_t1enc.c
> gs/jasper/src/libjasper/jpc/jpc_t1enc.h
> gs/jasper/src/libjasper/jpc/jpc_t2cod.c
> gs/jasper/src/libjasper/jpc/jpc_t2cod.h
> gs/jasper/src/libjasper/jpc/jpc_t2dec.c
> gs/jasper/src/libjasper/jpc/jpc_t2dec.h
> gs/jasper/src/libjasper/jpc/jpc_t2enc.c
> gs/jasper/src/libjasper/jpc/jpc_t2enc.h
> gs/jasper/src/libjasper/jpc/jpc_tagtree.c
> gs/jasper/src/libjasper/jpc/jpc_tagtree.h
> gs/jasper/src/libjasper/jpc/jpc_tsfb.c
> gs/jasper/src/libjasper/jpc/jpc_tsfb.h
> gs/jasper/src/libjasper/jpc/jpc_util.c
> gs/jasper/src/libjasper/jpg/jpg_cod.h
> gs/jasper/src/libjasper/pgx/pgx_cod.h
> gs/jasper/src/libjasper/pnm/pnm_cod.c
> gs/jasper/src/libjasper/pnm/pnm_cod.h
> gs/jasper/src/libjasper/pnm/pnm_dec.c
> gs/jasper/src/libjasper/pnm/pnm_enc.c
> gs/jasper/src/libjasper/ras/ras_cod.c
> gs/jasper/src/libjasper/ras/ras_cod.h
> gs/jasper/src/libjasper/ras/ras_dec.c
> gs/jasper/src/libjasper/ras/ras_enc.c
> gs/jbig2dec/config_types.h
> gs/jbig2dec/config_types.h.in
> gs/jbig2dec/config_win32.h
> gs/jbig2dec/getopt.c
> gs/jbig2dec/getopt.h
> gs/jbig2dec/getopt1.c
> gs/jbig2dec/jbig2.c
> gs/jbig2dec/jbig2.h
> gs/jbig2dec/jbig2_arith.c
> gs/jbig2dec/jbig2_arith.h
> gs/jbig2dec/jbig2_arith_iaid.c
> gs/jbig2dec/jbig2_arith_iaid.h
> gs/jbig2dec/jbig2_arith_int.c
> gs/jbig2dec/jbig2_arith_int.h
> gs/jbig2dec/jbig2_generic.c
> gs/jbig2dec/jbig2_generic.h
> gs/jbig2dec/jbig2_halftone.c
> gs/jbig2dec/jbig2_halftone.h
> gs/jbig2dec/jbig2_huffman.c
> gs/jbig2dec/jbig2_huffman.h
> gs/jbig2dec/jbig2_hufftab.h
> gs/jbig2dec/jbig2_image.c
> gs/jbig2dec/jbig2_image.h
> gs/jbig2dec/jbig2_image_pbm.c
> gs/jbig2dec/jbig2_image_png.c
> gs/jbig2dec/jbig2_metadata.c
> gs/jbig2dec/jbig2_metadata.h
> gs/jbig2dec/jbig2_mmr.c
> gs/jbig2dec/jbig2_mmr.h
> gs/jbig2dec/jbig2_page.c
> gs/jbig2dec/jbig2_priv.h
> gs/jbig2dec/jbig2_refinement.c
> gs/jbig2dec/jbig2_segment.c
> gs/jbig2dec/jbig2_symbol_dict.c
> gs/jbig2dec/jbig2_symbol_dict.h
> gs/jbig2dec/jbig2_text.c
> gs/jbig2dec/jbig2_text.h
> gs/jbig2dec/jbig2dec.c
> gs/jbig2dec/memcmp.c
> gs/jbig2dec/memento.c
> gs/jbig2dec/memento.h
> gs/jbig2dec/os_types.h
> gs/jbig2dec/pbm2png.c
> gs/jbig2dec/snprintf.c
> gs/lib/FAPIconfig-FCO
> gs/lib/FCOfontmap-PCLPS3
> gs/lib/FCOfontmap-PS3
> gs/lib/Fontmap.ATB
> gs/lib/Fontmap.ATM
> gs/lib/Fontmap.OS2
> gs/lib/Fontmap.SGI
> gs/lib/Fontmap.Sol
> gs/lib/Fontmap.URW-136.T1
> gs/lib/Fontmap.URW-136.TT
> gs/lib/Fontmap.Ult
> gs/lib/Fontmap.VMS
> gs/lib/PDFA_def.ps
> gs/lib/PDFX_def.ps
> gs/lib/acctest.ps
> gs/lib/addxchar.ps
> gs/lib/align.ps
> gs/lib/caption.ps
> gs/lib/cat.ps
> gs/lib/cid2code.ps
> gs/lib/decrypt.ps
> gs/lib/docie.ps
> gs/lib/dumphint
> gs/lib/dumphint.bat
> gs/lib/dumphint.ps
> gs/lib/dvipdf
> gs/lib/eps2eps
> gs/lib/eps2eps.bat
> gs/lib/eps2eps.cmd
> gs/lib/font2c
> gs/lib/font2c.bat
> gs/lib/font2c.cmd
> gs/lib/font2c.ps
> gs/lib/font2pcl.ps
> gs/lib/gs_ce_e.ps
> gs/lib/gs_cmdl.ps
> gs/lib/gs_fform.ps
> gs/lib/gs_il2_e.ps
> gs/lib/gs_kanji.ps
> gs/lib/gs_ksb_e.ps
> gs/lib/gs_lgo_e.ps
> gs/lib/gs_lgx_e.ps
> gs/lib/gs_pfile.ps
> gs/lib/gs_rdlin.ps
> gs/lib/gs_wl1_e.ps
> gs/lib/gs_wl2_e.ps
> gs/lib/gs_wl5_e.ps
> gs/lib/gsbj
> gs/lib/gsbj.bat
> gs/lib/gsdj
> gs/lib/gsdj.bat
> gs/lib/gsdj500
> gs/lib/gsdj500.bat
> gs/lib/gslj
> gs/lib/gslj.bat
> gs/lib/gslp
> gs/lib/gslp.bat
> gs/lib/gslp.ps
> gs/lib/gsnd
> gs/lib/gsnd.bat
> gs/lib/gsndt.bat
> gs/lib/gsnup.ps
> gs/lib/gssetgs.bat
> gs/lib/gssetgs32.bat
> gs/lib/gssetgs64.bat
> gs/lib/gst.bat
> gs/lib/gstt.bat
> gs/lib/ht_ccsto.ps
> gs/lib/image-qa.ps
> gs/lib/impath.ps
> gs/lib/jispaper.ps
> gs/lib/jobseparator.ps
> gs/lib/landscap.ps
> gs/lib/level1.ps
> gs/lib/lines.ps
> gs/lib/lp386.bat
> gs/lib/lp386r2.bat
> gs/lib/lpgs.bat
> gs/lib/lpr2.bat
> gs/lib/lprsetup.sh
> gs/lib/markhint.ps
> gs/lib/markpath.ps
> gs/lib/mkcidfm.ps
> gs/lib/opdfread.ps
> gs/lib/packfile.ps
> gs/lib/pcharstr.ps
> gs/lib/pdf2dsc
> gs/lib/pdf2dsc.bat
> gs/lib/pdf2dsc.ps
> gs/lib/pdf2ps
> gs/lib/pdf2ps.bat
> gs/lib/pdf2ps.cmd
> gs/lib/pdfopt
> gs/lib/pdfopt.bat
> gs/lib/pdfopt.ps
> gs/lib/pdfwrite.ps
> gs/lib/pf2afm
> gs/lib/pf2afm.bat
> gs/lib/pf2afm.cmd
> gs/lib/pf2afm.ps
> gs/lib/pfbtopfa
> gs/lib/pfbtopfa.bat
> gs/lib/pfbtopfa.ps
> gs/lib/pftogsf.bat
> gs/lib/ppath.ps
> gs/lib/pphs
> gs/lib/pphs.ps
> gs/lib/prfont.ps
> gs/lib/printafm
> gs/lib/printafm.ps
> gs/lib/ps2ai.ps
> gs/lib/ps2ascii
> gs/lib/ps2ascii.bat
> gs/lib/ps2ascii.cmd
> gs/lib/ps2ascii.ps
> gs/lib/ps2epsi
> gs/lib/ps2epsi.bat
> gs/lib/ps2epsi.cmd
> gs/lib/ps2epsi.ps
> gs/lib/ps2pdf
> gs/lib/ps2pdf.bat
> gs/lib/ps2pdf.cmd
> gs/lib/ps2pdf12
> gs/lib/ps2pdf12.bat
> gs/lib/ps2pdf12.cmd
> gs/lib/ps2pdf13
> gs/lib/ps2pdf13.bat
> gs/lib/ps2pdf13.cmd
> gs/lib/ps2pdf14
> gs/lib/ps2pdf14.bat
> gs/lib/ps2pdf14.cmd
> gs/lib/ps2pdfwr
> gs/lib/ps2pdfxx.bat
> gs/lib/ps2ps
> gs/lib/ps2ps.bat
> gs/lib/ps2ps.cmd
> gs/lib/ps2ps2
> gs/lib/ps2ps2.bat
> gs/lib/ps2ps2.cmd
> gs/lib/rollconv.ps
> gs/lib/showchar.ps
> gs/lib/stcinfo.ps
> gs/lib/stcolor.ps
> gs/lib/stocht.ps
> gs/lib/traceimg.ps
> gs/lib/traceop.ps
> gs/lib/type1enc.ps
> gs/lib/type1ops.ps
> gs/lib/uninfo.ps
> gs/lib/unix-lpr.sh
> gs/lib/unprot.ps
> gs/lib/viewcmyk.ps
> gs/lib/viewgif.ps
> gs/lib/viewjpeg.ps
> gs/lib/viewmiff.ps
> gs/lib/viewpbm.ps
> gs/lib/viewpcx.ps
> gs/lib/viewps2a.ps
> gs/lib/viewrgb.ps
> gs/lib/wftopfa
> gs/lib/wftopfa.ps
> gs/lib/winmaps.ps
> gs/lib/wmakebat.bat
> gs/lib/wrfont.ps
> gs/lib/zeroline.ps
> gs/man/de/dvipdf.1
> gs/man/de/font2c.1
> gs/man/de/gsnd.1
> gs/man/de/pdf2dsc.1
> gs/man/de/pdf2ps.1
> gs/man/de/pdfopt.1
> gs/man/de/printafm.1
> gs/man/de/ps2ascii.1
> gs/man/de/ps2pdf.1
> gs/man/de/ps2ps.1
> gs/man/de/wftopfa.1
> gs/man/dvipdf.1
> gs/man/eps2eps.1
> gs/man/font2c.1
> gs/man/gs.1
> gs/man/gslp.1
> gs/man/gsnd.1
> gs/man/pdf2dsc.1
> gs/man/pdf2ps.1
> gs/man/pdfopt.1
> gs/man/pf2afm.1
> gs/man/pfbtopfa.1
> gs/man/printafm.1
> gs/man/ps2ascii.1
> gs/man/ps2epsi.1
> gs/man/ps2pdf.1
> gs/man/ps2pdfwr.1
> gs/man/ps2ps.1
> gs/man/wftopfa.1
> gs/psi/bfont.h
> gs/psi/btoken.h
> gs/psi/dmmain.c
> gs/psi/dmmain.r
> gs/psi/dpmain.c
> gs/psi/dscparse.c
> gs/psi/dscparse.h
> gs/psi/dstack.h
> gs/psi/dwdll.c
> gs/psi/dwdll.h
> gs/psi/dwimg.c
> gs/psi/dwimg.h
> gs/psi/dwmain.c
> gs/psi/dwmain.rc
> gs/psi/dwmainc.c
> gs/psi/dwnodll.c
> gs/psi/dwreg.c
> gs/psi/dwreg.h
> gs/psi/dwres.h
> gs/psi/dwtext.c
> gs/psi/dwtext.h
> gs/psi/dwtrace.c
> gs/psi/dwtrace.h
> gs/psi/dxmain.c
> gs/psi/dxmainc.c
> gs/psi/estack.h
> gs/psi/fapi_ft.c
> gs/psi/fapibstm.c
> gs/psi/fapiufst.c
> gs/psi/files.h
> gs/psi/ghost.h
> gs/psi/gs.c
> gs/psi/gsdll.c
> gs/psi/gsdll2.rc
> gs/psi/gsdll32.rc
> gs/psi/gserver.c
> gs/psi/gsos2.rc
> gs/psi/ialloc.c
> gs/psi/ialloc.h
> gs/psi/iapi.c
> gs/psi/iapi.h
> gs/psi/iastate.h
> gs/psi/iastruct.h
> gs/psi/ibnum.c
> gs/psi/ibnum.h
> gs/psi/ichar.h
> gs/psi/ichar1.h
> gs/psi/icharout.h
> gs/psi/icid.h
> gs/psi/icie.h
> gs/psi/icolor.h
> gs/psi/iconf.c
> gs/psi/iconf.h
> gs/psi/icontext.c
> gs/psi/icontext.h
> gs/psi/icremap.h
> gs/psi/icsmap.h
> gs/psi/icstate.h
> gs/psi/iddict.h
> gs/psi/iddstack.h
> gs/psi/idebug.c
> gs/psi/idebug.h
> gs/psi/idict.c
> gs/psi/idict.h
> gs/psi/idictdef.h
> gs/psi/idicttpl.h
> gs/psi/idisp.c
> gs/psi/idisp.h
> gs/psi/idosave.h
> gs/psi/idparam.c
> gs/psi/idparam.h
> gs/psi/idsdata.h
> gs/psi/idstack.c
> gs/psi/idstack.h
> gs/psi/ierrors.h
> gs/psi/iesdata.h
> gs/psi/iestack.h
> gs/psi/ifapi.h
> gs/psi/ifcid.h
> gs/psi/ifilter.h
> gs/psi/ifilter2.h
> gs/psi/ifont.h
> gs/psi/ifont1.h
> gs/psi/ifont2.h
> gs/psi/ifont42.h
> gs/psi/ifrpred.h
> gs/psi/ifunc.h
> gs/psi/ifwpred.h
> gs/psi/igc.c
> gs/psi/igc.h
> gs/psi/igcref.c
> gs/psi/igcstr.c
> gs/psi/igcstr.h
> gs/psi/igstate.h
> gs/psi/iht.h
> gs/psi/iimage.h
> gs/psi/iimage2.h
> gs/psi/iinit.c
> gs/psi/iinit.h
> gs/psi/ilevel.h
> gs/psi/ilocate.c
> gs/psi/imain.c
> gs/psi/imain.h
> gs/psi/imainarg.c
> gs/psi/imainarg.h
> gs/psi/imemory.h
> gs/psi/iminst.h
> gs/psi/iname.c
> gs/psi/iname.h
> gs/psi/inamedef.h
> gs/psi/inameidx.h
> gs/psi/inames.h
> gs/psi/inamestr.h
> gs/psi/inobtokn.c
> gs/psi/inouparm.c
> gs/psi/int.mak
> gs/psi/interp.c
> gs/psi/interp.h
> gs/psi/iosdata.h
> gs/psi/iostack.h
> gs/psi/ipacked.h
> gs/psi/iparam.c
> gs/psi/iparam.h
> gs/psi/iparray.h
> gs/psi/ipcolor.h
> gs/psi/iplugin.c
> gs/psi/iplugin.h
> gs/psi/ireclaim.c
> gs/psi/iref.h
> gs/psi/isave.c
> gs/psi/isave.h
> gs/psi/iscan.c
> gs/psi/iscan.h
> gs/psi/iscanbin.c
> gs/psi/iscanbin.h
> gs/psi/iscannum.c
> gs/psi/iscannum.h
> gs/psi/isdata.h
> gs/psi/isstate.h
> gs/psi/istack.c
> gs/psi/istack.h
> gs/psi/istkparm.h
> gs/psi/istream.h
> gs/psi/istruct.h
> gs/psi/itoken.h
> gs/psi/iutil.c
> gs/psi/iutil.h
> gs/psi/iutil2.c
> gs/psi/iutil2.h
> gs/psi/ivmem2.h
> gs/psi/ivmspace.h
> gs/psi/main.h
> gs/psi/mkfilelt.cpp
> gs/psi/msvc.mak
> gs/psi/msvc32.mak
> gs/psi/msvc64.mak
> gs/psi/nsisinst.nsi
> gs/psi/oparc.h
> gs/psi/opcheck.h
> gs/psi/opdef.h
> gs/psi/oper.h
> gs/psi/opextern.h
> gs/psi/os2.mak
> gs/psi/ostack.h
> gs/psi/psromfs.mak
> gs/psi/sfilter1.c
> gs/psi/store.h
> gs/psi/winint.mak
> gs/psi/wrfont.c
> gs/psi/wrfont.h
> gs/psi/write_t1.c
> gs/psi/write_t1.h
> gs/psi/write_t2.c
> gs/psi/write_t2.h
> gs/psi/zalg.c
> gs/psi/zarith.c
> gs/psi/zarray.c
> gs/psi/zbfont.c
> gs/psi/zbseq.c
> gs/psi/zcfont.c
> gs/psi/zchar.c
> gs/psi/zchar1.c
> gs/psi/zchar2.c
> gs/psi/zchar32.c
> gs/psi/zchar42.c
> gs/psi/zchar42.h
> gs/psi/zcharout.c
> gs/psi/zcharx.c
> gs/psi/zcid.c
> gs/psi/zcidtest.c
> gs/psi/zcie.c
> gs/psi/zcie.h
> gs/psi/zcolor.c
> gs/psi/zcolor.h
> gs/psi/zcolor1.c
> gs/psi/zcolor2.c
> gs/psi/zcolor3.c
> gs/psi/zcontext.c
> gs/psi/zcontrol.c
> gs/psi/zcrd.c
> gs/psi/zcsdevn.c
> gs/psi/zcsindex.c
> gs/psi/zcspixel.c
> gs/psi/zcssepr.c
> gs/psi/zdevcal.c
> gs/psi/zdevice.c
> gs/psi/zdevice2.c
> gs/psi/zdfilter.c
> gs/psi/zdict.c
> gs/psi/zdosio.c
> gs/psi/zdouble.c
> gs/psi/zdpnext.c
> gs/psi/zdps.c
> gs/psi/zdps1.c
> gs/psi/zdscpars.c
> gs/psi/zfaes.c
> gs/psi/zfapi.c
> gs/psi/zfarc4.c
> gs/psi/zfbcp.c
> gs/psi/zfcid.c
> gs/psi/zfcid0.c
> gs/psi/zfcid1.c
> gs/psi/zfcmap.c
> gs/psi/zfdctd.c
> gs/psi/zfdcte.c
> gs/psi/zfdecode.c
> gs/psi/zfile.c
> gs/psi/zfile.h
> gs/psi/zfile1.c
> gs/psi/zfileio.c
> gs/psi/zfilter.c
> gs/psi/zfilter2.c
> gs/psi/zfilterx.c
> gs/psi/zfimscale.c
> gs/psi/zfjbig2.c
> gs/psi/zfjpx.c
> gs/psi/zfmd5.c
> gs/psi/zfont.c
> gs/psi/zfont0.c
> gs/psi/zfont1.c
> gs/psi/zfont2.c
> gs/psi/zfont32.c
> gs/psi/zfont42.c
> gs/psi/zfontenum.c
> gs/psi/zfproc.c
> gs/psi/zfrsd.c
> gs/psi/zfrsd.h
> gs/psi/zfsample.c
> gs/psi/zfsha2.c
> gs/psi/zfunc.c
> gs/psi/zfunc.h
> gs/psi/zfunc0.c
> gs/psi/zfunc3.c
> gs/psi/zfunc4.c
> gs/psi/zfzlib.c
> gs/psi/zgeneric.c
> gs/psi/zgstate.c
> gs/psi/zhsb.c
> gs/psi/zht.c
> gs/psi/zht1.c
> gs/psi/zht2.c
> gs/psi/zht2.h
> gs/psi/zicc.c
> gs/psi/zicc.h
> gs/psi/zimage.c
> gs/psi/zimage2.c
> gs/psi/zimage3.c
> gs/psi/ziodev.c
> gs/psi/ziodev2.c
> gs/psi/ziodevs.c
> gs/psi/ziodevsc.c
> gs/psi/zmath.c
> gs/psi/zmatrix.c
> gs/psi/zmedia2.c
> gs/psi/zmisc.c
> gs/psi/zmisc1.c
> gs/psi/zmisc2.c
> gs/psi/zmisc3.c
> gs/psi/zncdummy.c
> gs/psi/zpacked.c
> gs/psi/zpaint.c
> gs/psi/zpath.c
> gs/psi/zpath1.c
> gs/psi/zpcolor.c
> gs/psi/zpdfops.c
> gs/psi/zrelbit.c
> gs/psi/zrop.c
> gs/psi/zshade.c
> gs/psi/zstack.c
> gs/psi/zstring.c
> gs/psi/zsysvm.c
> gs/psi/ztoken.c
> gs/psi/ztrans.c
> gs/psi/ztrap.c
> gs/psi/ztype.c
> gs/psi/zupath.c
> gs/psi/zusparam.c
> gs/psi/zutf8.c
> gs/psi/zvmem.c
> gs/psi/zvmem2.c
> gs/psi/zwinutf8.c
> gs/toolbin/GenSubstCID.ps
> gs/toolbin/afmutil.py
> gs/toolbin/bughunt.sh
> gs/toolbin/color/icc_creator/ICC_Creator/CIELAB.h
> gs/toolbin/color/icc_creator/ICC_Creator/ICC_Creator.cpp
> gs/toolbin/color/icc_creator/ICC_Creator/ICC_Creator.h
> gs/toolbin/color/icc_creator/ICC_Creator/ICC_CreatorDlg.cpp
> gs/toolbin/color/icc_creator/ICC_Creator/ICC_CreatorDlg.h
> gs/toolbin/color/icc_creator/ICC_Creator/icc_create.cpp
> gs/toolbin/color/icc_creator/ICC_Creator/icc_create.h
> gs/toolbin/color/icc_creator/README.txt
> gs/toolbin/drawafm.ps
> gs/toolbin/encs2c.ps
> gs/toolbin/errlist.tcl
> gs/toolbin/extractFonts.ps
> gs/toolbin/extractICCprofiles.ps
> gs/toolbin/gen_ldf_jb2.py
> gs/toolbin/genfontmap.ps
> gs/toolbin/gitlog2changelog.py
> gs/toolbin/gsmake
> gs/toolbin/gsmake.tcl
> gs/toolbin/halftone/gen_ordered/README
> gs/toolbin/halftone/gen_ordered/gen_ordered.c
> gs/toolbin/headers.tcl
> gs/toolbin/jpxtopdf.c
> gs/toolbin/leaks.tcl
> gs/toolbin/makehist.tcl
> gs/toolbin/memory.py
> gs/toolbin/ocheck.py
> gs/toolbin/pdf_info.ps
> gs/toolbin/pdfinflt.ps
> gs/toolbin/pre.tcl
> gs/toolbin/precheck.tcl
> gs/toolbin/pscet_status.pl
> gs/toolbin/smoke.ps
> gs/toolbin/split_changelog.py
> gs/toolbin/suite.tcl
> gs/toolbin/tests/build_revision.py
> gs/toolbin/tests/check_all.py
> gs/toolbin/tests/check_comments.py
> gs/toolbin/tests/check_dirs.py
> gs/toolbin/tests/check_docrefs.py
> gs/toolbin/tests/check_source.py
> gs/toolbin/tests/cmpi.py
> gs/toolbin/tests/compare_checksumdb.py
> gs/toolbin/tests/compare_checksums.py
> gs/toolbin/tests/dump_checksum.py
> gs/toolbin/tests/dump_checksum_plus.py
> gs/toolbin/tests/dump_checksum_raw.py
> gs/toolbin/tests/fuzzy.c
> gs/toolbin/tests/get_baseline_log.py
> gs/toolbin/tests/get_baselines.py
> gs/toolbin/tests/gscheck_all.py
> gs/toolbin/tests/gscheck_fuzzypdf.py
> gs/toolbin/tests/gscheck_pdfwrite.py
> gs/toolbin/tests/gscheck_raster.py
> gs/toolbin/tests/gscheck_testfiles.py
> gs/toolbin/tests/gsconf.py
> gs/toolbin/tests/gsparamsets.py
> gs/toolbin/tests/gssum.py
> gs/toolbin/tests/gstestgs.py
> gs/toolbin/tests/gstestutils.py
> gs/toolbin/tests/gsutil.py
> gs/toolbin/tests/make_baselinedb.py
> gs/toolbin/tests/make_testdb.py
> gs/toolbin/tests/make_two_pdfversions
> gs/toolbin/tests/make_two_versions
> gs/toolbin/tests/myoptparse.py
> gs/toolbin/tests/rasterdb.py
> gs/toolbin/tests/revert_baseline
> gs/toolbin/tests/revert_pdfbaseline
> gs/toolbin/tests/run_nightly.py
> gs/toolbin/tests/run_parallel
> gs/toolbin/tests/run_regression.py
> gs/toolbin/tests/testdiff.py
> gs/toolbin/tests/update_baseline.py
> gs/toolbin/tests/update_specific
> gs/toolbin/tmake.tcl
> gs/zlib/ChangeLog
> gs/zlib/adler32.c
> gs/zlib/compress.c
> gs/zlib/crc32.c
> gs/zlib/deflate.c
> gs/zlib/deflate.h
> gs/zlib/test/example.c
> gs/zlib/test/minigzip.c
> gs/zlib/trees.c
> gs/zlib/uncompr.c
> gs/zlib/zconf.h
> gs/zlib/zconf.h.cmakein
> gs/zlib/zconf.h.in
> gs/zlib/zutil.c
> gs/zlib/zutil.h
> language_switch/pspcl6_gcc.mak
> language_switch/pspcl6_msvc.mak
> pcl/pcbiptrn.c
> pcl/pcbiptrn.h
> pcl/pccid.c
> pcl/pccid.h
> pcl/pccolor.c
> pcl/pccoord.h
> pcl/pccprint.c
> pcl/pccsbase.c
> pcl/pccsbase.h
> pcl/pcdict.h
> pcl/pcdither.c
> pcl/pcdither.h
> pcl/pcdraw.c
> pcl/pcdraw.h
> pcl/pcfont.c
> pcl/pcfont.h
> pcl/pcfontpg.c
> pcl/pcfontst.h
> pcl/pcfrgrnd.c
> pcl/pcfrgrnd.h
> pcl/pcfsel.c
> pcl/pcfsel.h
> pcl/pcht.c
> pcl/pcht.h
> pcl/pcident.c
> pcl/pcident.h
> pcl/pcimpl.c
> pcl/pcindxed.c
> pcl/pcindxed.h
> pcl/pcjob.c
> pcl/pcl.mak
> pcl/pcl_top.mak
> pcl/pclookup.c
> pcl/pclookup.h
> pcl/pcmacros.c
> pcl/pcmisc.c
> pcl/pcmtx3.c
> pcl/pcmtx3.h
> pcl/pcommand.c
> pcl/pcommand.h
> pcl/pcpage.c
> pcl/pcpage.h
> pcl/pcpalet.c
> pcl/pcpalet.h
> pcl/pcparam.h
> pcl/pcparse.c
> pcl/pcparse.h
> pcl/pcpatrn.c
> pcl/pcpatrn.h
> pcl/pcpattyp.h
> pcl/pcpatxfm.c
> pcl/pcpatxfm.h
> pcl/pcrect.c
> pcl/pcsfont.c
> pcl/pcstate.h
> pcl/pcstatus.c
> pcl/pcsymbol.c
> pcl/pcsymbol.h
> pcl/pctext.c
> pcl/pctop.c
> pcl/pctop.h
> pcl/pctpm.h
> pcl/pcuptrn.c
> pcl/pcuptrn.h
> pcl/pcursor.c
> pcl/pcursor.h
> pcl/pcwhtidx.c
> pcl/pcwhtidx.h
> pcl/pcxfmst.h
> pcl/pgchar.c
> pcl/pgcolor.c
> pcl/pgconfig.c
> pcl/pgdraw.c
> pcl/pgdraw.h
> pcl/pgfdata.c
> pcl/pgfdata.h
> pcl/pgfont.c
> pcl/pgfont.h
> pcl/pgframe.c
> pcl/pggeom.c
> pcl/pggeom.h
> pcl/pginit.c
> pcl/pginit.h
> pcl/pglabel.c
> pcl/pglfill.c
> pcl/pgmand.h
> pcl/pgmisc.c
> pcl/pgmisc.h
> pcl/pgparse.c
> pcl/pgpoly.c
> pcl/pgstate.h
> pcl/pgvector.c
> pcl/rtgmode.c
> pcl/rtgmode.h
> pcl/rtmisc.c
> pcl/rtraster.c
> pcl/rtraster.h
> pcl/rtrstcmp.c
> pcl/rtrstcmp.h
> pcl/rtrstst.h
> pl/dwimg.c
> pl/dwimg.h
> pl/dwmainc.c
> pl/dwreg.c
> pl/dwreg.h
> pl/dwres.h
> pl/pjparse.c
> pl/pjparse.h
> pl/pjparsei.c
> pl/pjtop.c
> pl/pjtop.h
> pl/pl.mak
> pl/plalloc.c
> pl/plalloc.h
> pl/plapi.h
> pl/plchar.c
> pl/pldebug.h
> pl/pldict.c
> pl/pldict.h
> pl/pldraw.c
> pl/pldraw.h
> pl/plfont.c
> pl/plfont.h
> pl/plftable.c
> pl/plftable.h
> pl/plht.c
> pl/plht.h
> pl/plimpl.c
> pl/pllfont.c
> pl/pllfont.h
> pl/plmain.c
> pl/plmain.h
> pl/plparse.h
> pl/plplatf.c
> pl/plplatf.h
> pl/plplatfps.c
> pl/plsrgb.c
> pl/plsrgb.h
> pl/plsymbol.c
> pl/plsymbol.h
> pl/pltop.c
> pl/pltop.h
> pl/pltoputl.c
> pl/pltoputl.h
> pl/pluchar.c
> pl/plufont.c
> pl/plulfont.c
> pl/plvalue.c
> pl/plvalue.h
> pl/plvocab.c
> pl/plvocab.h
> pl/realmain.c
> psi/psi.mak
> psi/psitop.c
> pxl/pxasm.ps
> pxl/pxattr.h
> pxl/pxbfont.c
> pxl/pxbfont.h
> pxl/pxbfont.ps
> pxl/pxcet.txt
> pxl/pxdict.h
> pxl/pxdiff.txt
> pxl/pxenum.h
> pxl/pxerrors.c
> pxl/pxerrors.h
> pxl/pxffont.c
> pxl/pxfont.c
> pxl/pxfont.h
> pxl/pxfts.txt
> pxl/pxgstate.c
> pxl/pxgstate.h
> pxl/pximage.c
> pxl/pximpl.c
> pxl/pxink.c
> pxl/pxl.mak
> pxl/pxlib.txt
> pxl/pxoper.h
> pxl/pxpaint.c
> pxl/pxparse.c
> pxl/pxparse.h
> pxl/pxptable.c
> pxl/pxptable.h
> pxl/pxpthr.c
> pxl/pxpthr.h
> pxl/pxsessio.c
> pxl/pxspec.txt
> pxl/pxstate.c
> pxl/pxstate.h
> pxl/pxstream.c
> pxl/pxsymbol.ps
> pxl/pxsymbol.psc
> pxl/pxsymbol.psh
> pxl/pxtag.h
> pxl/pxtop.c
> pxl/pxvalue.c
> pxl/pxvalue.h
> svg/ghostsvg.h
> svg/svg.mak
> svg/svg_gcc.mak
> svg/svg_msvc.mak
> svg/svgcolor.c
> svg/svgcolorlist.h
> svg/svgdoc.c
> svg/svgshapes.c
> svg/svgtop.c
> svg/svgtransform.c
> svg/svgtypes.c
> svg/svgxml.c
> tools/gslite/gslt.h
> tools/gslite/gslt_font.h
> tools/gslite/gslt_font_api.c
> tools/gslite/gslt_font_api.h
> tools/gslite/gslt_font_api_test.c
> tools/gslite/gslt_font_cache.c
> tools/gslite/gslt_font_cff.c
> tools/gslite/gslt_font_encoding.c
> tools/gslite/gslt_font_glyph.c
> tools/gslite/gslt_font_int.h
> tools/gslite/gslt_font_test.c
> tools/gslite/gslt_font_ttf.c
> tools/gslite/gslt_image.c
> tools/gslite/gslt_image.h
> tools/gslite/gslt_image_jpeg.c
> tools/gslite/gslt_image_png.c
> tools/gslite/gslt_image_test.c
> tools/gslite/gslt_image_threads_test.c
> tools/gslite/gslt_image_tiff.c
> tools/gslite/gslt_init.c
> tools/gslite/gslt_stubs.c
> tools/gslite/gslt_test.c
> tools/null.pxl
> tools/suite.tcl
> xps/ghostxps.h
> xps/xps.mak
> xps/xps_gcc.mak
> xps/xps_msvc.mak
> xps/xpsanalyze.c
> xps/xpscff.c
> xps/xpscolor.c
> xps/xpscommon.c
> xps/xpscrc.c
> xps/xpsdoc.c
> xps/xpsfont.c
> xps/xpsglyphs.c
> xps/xpsgradient.c
> xps/xpshash.c
> xps/xpsimage.c
> xps/xpsjpeg.c
> xps/xpsjxr.c
> xps/xpsmem.c
> xps/xpsopacity.c
> xps/xpspage.c
> xps/xpspath.c
> xps/xpspng.c
> xps/xpsresource.c
> xps/xpstiff.c
> xps/xpstile.c
> xps/xpstop.c
> xps/xpsttf.c
> xps/xpsutf.c
> xps/xpsvisual.c
> xps/xpsxml.c
> xps/xpszip.c

2012-06-13 12:22:13 +0100
Chris Liddell <chris.liddell@artifex.com>
fae7be45fb7f2e9be889c07dc9d29e7ea1975dc9

> Bug 692365: Don't derive metrics for CIDFontType 2.
> pdfwrite uses zchar42_set_cache() to get the glyph metrics for a glyph from
> CIDFontType 2 font. It turns out, that function contained the same faking
> of vertical metrics as the FAPI code originally had. That's a problem because
> a PS font without vertical metrics should be treated as horizontal, regardless
> of the wmode value.
> We *only* want to derive vertical metrics for TTF fonts read from disk being
> used to emulate a missing CIDFont with wmode 1.
> No cluster differences.
> gs/psi/zchar42.c

2012-06-11 14:09:28 +0100
Chris Liddell <chris.liddell@artifex.com>
b4dbdb142e340596d9a8b440ca415832c39caef2

> Update libjpeg to 8d.
> gs/jpeg/Makefile.in
> gs/jpeg/README
> gs/jpeg/aclocal.m4
> gs/jpeg/change.log
> gs/jpeg/cjpeg.1
> gs/jpeg/cjpeg.c
> gs/jpeg/config.guess
> gs/jpeg/config.sub
> gs/jpeg/configure
> gs/jpeg/configure.ac
> gs/jpeg/depcomp
> gs/jpeg/install-sh
> gs/jpeg/install.txt
> gs/jpeg/jaricom.c
> gs/jpeg/jcarith.c
> gs/jpeg/jccoefct.c
> gs/jpeg/jccolor.c
> gs/jpeg/jconfig.mc6
> gs/jpeg/jctrans.c
> gs/jpeg/jdarith.c
> gs/jpeg/jdatadst.c
> gs/jpeg/jdatasrc.c
> gs/jpeg/jdcoefct.c
> gs/jpeg/jdcolor.c
> gs/jpeg/jdmaster.c
> gs/jpeg/jmemmgr.c
> gs/jpeg/jmorecfg.h
> gs/jpeg/jpegint.h
> gs/jpeg/jpeglib.h
> gs/jpeg/jpegtran.c
> gs/jpeg/jquant1.c
> gs/jpeg/jquant2.c
> gs/jpeg/jutils.c
> gs/jpeg/jversion.h
> gs/jpeg/libjpeg.txt
> gs/jpeg/ltmain.sh
> gs/jpeg/structure.txt
> gs/jpeg/transupp.c
> gs/jpeg/transupp.h
> gs/jpeg/usage.txt

2012-06-11 11:37:57 +0100
Chris Liddell <chris.liddell@artifex.com>
2214fb3da464f702ab4bd46d653aef1c9b69d483

> Update zlib to 1.2.7
> No cluster differences.
> gs/zlib/CMakeLists.txt
> gs/zlib/ChangeLog
> gs/zlib/FAQ
> gs/zlib/INDEX
> gs/zlib/Makefile
> gs/zlib/Makefile.in
> gs/zlib/README
> gs/zlib/adler32.c
> gs/zlib/algorithm.txt
> gs/zlib/amiga/Makefile.pup
> gs/zlib/amiga/Makefile.sas
> gs/zlib/as400/bndsrc
> gs/zlib/as400/compile.clp
> gs/zlib/as400/readme.txt
> gs/zlib/as400/zlib.inc
> gs/zlib/compress.c
> gs/zlib/configure
> gs/zlib/contrib/README.contrib
> gs/zlib/contrib/amd64/amd64-match.S
> gs/zlib/contrib/asm586/README.586
> gs/zlib/contrib/asm586/match.S
> gs/zlib/contrib/asm686/README.686
> gs/zlib/contrib/asm686/match.S
> gs/zlib/contrib/delphi/ZLib.pas
> gs/zlib/contrib/delphi/zlibd32.mak
> gs/zlib/contrib/dotzlib/DotZLib.build
> gs/zlib/contrib/dotzlib/DotZLib.chm
> gs/zlib/contrib/dotzlib/DotZLib/AssemblyInfo.cs
> gs/zlib/contrib/dotzlib/DotZLib/ChecksumImpl.cs
> gs/zlib/contrib/dotzlib/DotZLib/CircularBuffer.cs
> gs/zlib/contrib/dotzlib/DotZLib/CodecBase.cs
> gs/zlib/contrib/dotzlib/DotZLib/Deflater.cs
> gs/zlib/contrib/dotzlib/DotZLib/DotZLib.cs
> gs/zlib/contrib/dotzlib/DotZLib/GZipStream.cs
> gs/zlib/contrib/dotzlib/DotZLib/Inflater.cs
> gs/zlib/contrib/dotzlib/DotZLib/UnitTests.cs
> gs/zlib/contrib/dotzlib/readme.txt
> gs/zlib/contrib/gcc_gvmat64/gvmat64.S
> gs/zlib/contrib/infback9/infback9.c
> gs/zlib/contrib/infback9/inftree9.c
> gs/zlib/contrib/infback9/inftree9.h
> gs/zlib/contrib/inflate86/inffas86.c
> gs/zlib/contrib/masm686/match.asm
> gs/zlib/contrib/masmx64/gvmat64.asm
> gs/zlib/contrib/masmx64/gvmat64.obj
> gs/zlib/contrib/masmx64/inffas8664.c
> gs/zlib/contrib/masmx64/inffasx64.asm
> gs/zlib/contrib/masmx64/inffasx64.obj
> gs/zlib/contrib/masmx64/readme.txt
> gs/zlib/contrib/masmx86/bld_ml32.bat
> gs/zlib/contrib/masmx86/gvmat32.asm
> gs/zlib/contrib/masmx86/gvmat32.obj
> gs/zlib/contrib/masmx86/gvmat32c.c
> gs/zlib/contrib/masmx86/inffas32.asm
> gs/zlib/contrib/masmx86/inffas32.obj
> gs/zlib/contrib/masmx86/match686.asm
> gs/zlib/contrib/masmx86/mkasm.bat
> gs/zlib/contrib/masmx86/readme.txt
> gs/zlib/contrib/minizip/ChangeLogUnzip
> gs/zlib/contrib/minizip/Makefile.am
> gs/zlib/contrib/minizip/MiniZip64_Changes.txt
> gs/zlib/contrib/minizip/MiniZip64_info.txt
> gs/zlib/contrib/minizip/configure.ac
> gs/zlib/contrib/minizip/crypt.h
> gs/zlib/contrib/minizip/ioapi.c
> gs/zlib/contrib/minizip/ioapi.h
> gs/zlib/contrib/minizip/iowin32.c
> gs/zlib/contrib/minizip/iowin32.h
> gs/zlib/contrib/minizip/make_vms.com
> gs/zlib/contrib/minizip/miniunz.c
> gs/zlib/contrib/minizip/minizip.c
> gs/zlib/contrib/minizip/minizip.pc.in
> gs/zlib/contrib/minizip/mztools.c
> gs/zlib/contrib/minizip/mztools.h
> gs/zlib/contrib/minizip/unzip.c
> gs/zlib/contrib/minizip/unzip.h
> gs/zlib/contrib/minizip/zip.c
> gs/zlib/contrib/minizip/zip.h
> gs/zlib/contrib/pascal/zlibd32.mak
> gs/zlib/contrib/pascal/zlibpas.pas
> gs/zlib/contrib/puff/Makefile
> gs/zlib/contrib/puff/puff.c
> gs/zlib/contrib/puff/puff.h
> gs/zlib/contrib/puff/pufftest.c
> gs/zlib/contrib/puff/zeros.raw
> gs/zlib/contrib/testzlib/testzlib.c
> gs/zlib/contrib/vstudio/readme.txt
> gs/zlib/contrib/vstudio/vc10/miniunz.vcxproj
> gs/zlib/contrib/vstudio/vc10/miniunz.vcxproj.filters
> gs/zlib/contrib/vstudio/vc10/miniunz.vcxproj.user
> gs/zlib/contrib/vstudio/vc10/minizip.vcxproj
> gs/zlib/contrib/vstudio/vc10/minizip.vcxproj.filters
> gs/zlib/contrib/vstudio/vc10/minizip.vcxproj.user
> gs/zlib/contrib/vstudio/vc10/testzlib.vcxproj
> gs/zlib/contrib/vstudio/vc10/testzlib.vcxproj.filters
> gs/zlib/contrib/vstudio/vc10/testzlib.vcxproj.user
> gs/zlib/contrib/vstudio/vc10/testzlibdll.vcxproj
> gs/zlib/contrib/vstudio/vc10/testzlibdll.vcxproj.filters
> gs/zlib/contrib/vstudio/vc10/testzlibdll.vcxproj.user
> gs/zlib/contrib/vstudio/vc10/zlib.rc
> gs/zlib/contrib/vstudio/vc10/zlibstat.vcxproj
> gs/zlib/contrib/vstudio/vc10/zlibstat.vcxproj.filters
> gs/zlib/contrib/vstudio/vc10/zlibstat.vcxproj.user
> gs/zlib/contrib/vstudio/vc10/zlibvc.def
> gs/zlib/contrib/vstudio/vc10/zlibvc.sln
> gs/zlib/contrib/vstudio/vc10/zlibvc.vcxproj
> gs/zlib/contrib/vstudio/vc10/zlibvc.vcxproj.filters
> gs/zlib/contrib/vstudio/vc10/zlibvc.vcxproj.user
> gs/zlib/contrib/vstudio/vc7/miniunz.vcproj
> gs/zlib/contrib/vstudio/vc7/minizip.vcproj
> gs/zlib/contrib/vstudio/vc7/testzlib.vcproj
> gs/zlib/contrib/vstudio/vc7/zlib.rc
> gs/zlib/contrib/vstudio/vc7/zlibstat.vcproj
> gs/zlib/contrib/vstudio/vc7/zlibvc.def
> gs/zlib/contrib/vstudio/vc7/zlibvc.sln
> gs/zlib/contrib/vstudio/vc7/zlibvc.vcproj
> gs/zlib/contrib/vstudio/vc8/miniunz.vcproj
> gs/zlib/contrib/vstudio/vc8/minizip.vcproj
> gs/zlib/contrib/vstudio/vc8/testzlib.vcproj
> gs/zlib/contrib/vstudio/vc8/testzlibdll.vcproj
> gs/zlib/contrib/vstudio/vc8/zlib.rc
> gs/zlib/contrib/vstudio/vc8/zlibstat.vcproj
> gs/zlib/contrib/vstudio/vc8/zlibvc.def
> gs/zlib/contrib/vstudio/vc8/zlibvc.sln
> gs/zlib/contrib/vstudio/vc8/zlibvc.vcproj
> gs/zlib/contrib/vstudio/vc9/miniunz.vcproj
> gs/zlib/contrib/vstudio/vc9/minizip.vcproj
> gs/zlib/contrib/vstudio/vc9/testzlib.vcproj
> gs/zlib/contrib/vstudio/vc9/testzlibdll.vcproj
> gs/zlib/contrib/vstudio/vc9/zlib.rc
> gs/zlib/contrib/vstudio/vc9/zlibstat.vcproj
> gs/zlib/contrib/vstudio/vc9/zlibvc.def
> gs/zlib/contrib/vstudio/vc9/zlibvc.sln
> gs/zlib/contrib/vstudio/vc9/zlibvc.vcproj
> gs/zlib/crc32.c
> gs/zlib/crc32.h
> gs/zlib/deflate.c
> gs/zlib/deflate.h
> gs/zlib/doc/algorithm.txt
> gs/zlib/doc/rfc1950.txt
> gs/zlib/doc/rfc1951.txt
> gs/zlib/doc/rfc1952.txt
> gs/zlib/doc/txtvsbin.txt
> gs/zlib/example.c
> gs/zlib/examples/README.examples
> gs/zlib/examples/enough.c
> gs/zlib/examples/gun.c
> gs/zlib/examples/gzlog.c
> gs/zlib/examples/gzlog.h
> gs/zlib/examples/zlib_how.html
> gs/zlib/examples/zpipe.c
> gs/zlib/examples/zran.c
> gs/zlib/gzclose.c
> gs/zlib/gzguts.h
> gs/zlib/gzio.c
> gs/zlib/gzlib.c
> gs/zlib/gzread.c
> gs/zlib/gzwrite.c
> gs/zlib/infback.c
> gs/zlib/inffast.c
> gs/zlib/inffast.h
> gs/zlib/inffixed.h
> gs/zlib/inflate.c
> gs/zlib/inflate.h
> gs/zlib/inftrees.c
> gs/zlib/inftrees.h
> gs/zlib/make_vms.com
> gs/zlib/minigzip.c
> gs/zlib/msdos/Makefile.bor
> gs/zlib/msdos/Makefile.dj2
> gs/zlib/msdos/Makefile.emx
> gs/zlib/msdos/Makefile.msc
> gs/zlib/msdos/Makefile.tc
> gs/zlib/nintendods/Makefile
> gs/zlib/nintendods/README
> gs/zlib/old/Makefile.emx
> gs/zlib/old/zlib.html
> gs/zlib/projects/README.projects
> gs/zlib/projects/visualc6/README.txt
> gs/zlib/projects/visualc6/example.dsp
> gs/zlib/projects/visualc6/minigzip.dsp
> gs/zlib/projects/visualc6/zlib.dsp
> gs/zlib/projects/visualc6/zlib.dsw
> gs/zlib/qnx/package.qpg
> gs/zlib/test/example.c
> gs/zlib/test/infcover.c
> gs/zlib/test/minigzip.c
> gs/zlib/treebuild.xml
> gs/zlib/trees.c
> gs/zlib/trees.h
> gs/zlib/uncompr.c
> gs/zlib/watcom/watcom_f.mak
> gs/zlib/watcom/watcom_l.mak
> gs/zlib/win32/DLL_FAQ.txt
> gs/zlib/win32/Makefile.bor
> gs/zlib/win32/Makefile.emx
> gs/zlib/win32/Makefile.gcc
> gs/zlib/win32/Makefile.msc
> gs/zlib/win32/README-WIN32.txt
> gs/zlib/win32/zlib.def
> gs/zlib/win32/zlib1.rc
> gs/zlib/zconf.h
> gs/zlib/zconf.h.cmakein
> gs/zlib/zconf.h.in
> gs/zlib/zconf.in.h
> gs/zlib/zlib.3
> gs/zlib/zlib.3.pdf
> gs/zlib/zlib.h
> gs/zlib/zlib.map
> gs/zlib/zlib.pc.cmakein
> gs/zlib/zlib.pc.in
> gs/zlib/zlib2ansi
> gs/zlib/zutil.c
> gs/zlib/zutil.h

2012-06-11 09:11:18 +0100
Chris Liddell <chris.liddell@artifex.com>
3c419d97583ed1c234d53bd9c0efac2ef9fff320

> Update libtiff to 4.0.1.
> Remove globals from tif_pixarlog.c
> Re-apply commit 786269bafff68f1965b1536acef11f25e0cd44d0
> Also reapply some portability changes to tiffiop.h.
> No cluster differences.
> gs/tiff/ChangeLog
> gs/tiff/HOWTO-RELEASE
> gs/tiff/Makefile.am
> gs/tiff/Makefile.in
> gs/tiff/Makefile.vc
> gs/tiff/README
> gs/tiff/RELEASE-DATE
> gs/tiff/TODO
> gs/tiff/VERSION
> gs/tiff/aclocal.m4
> gs/tiff/autogen.sh
> gs/tiff/build/Makefile.am
> gs/tiff/build/Makefile.in
> gs/tiff/config/config.guess
> gs/tiff/config/config.sub
> gs/tiff/config/depcomp
> gs/tiff/config/install-sh
> gs/tiff/config/ltmain.sh
> gs/tiff/config/missing
> gs/tiff/config/mkinstalldirs
> gs/tiff/configure
> gs/tiff/configure.ac
> gs/tiff/configure.com
> gs/tiff/contrib/Makefile.am
> gs/tiff/contrib/Makefile.in
> gs/tiff/contrib/acorn/Makefile.acorn
> gs/tiff/contrib/acorn/Makefile.am
> gs/tiff/contrib/acorn/Makefile.in
> gs/tiff/contrib/acorn/ReadMe
> gs/tiff/contrib/acorn/SetVars
> gs/tiff/contrib/acorn/cleanlib
> gs/tiff/contrib/acorn/convert
> gs/tiff/contrib/acorn/install
> gs/tiff/contrib/addtiffo/Makefile.am
> gs/tiff/contrib/addtiffo/Makefile.in
> gs/tiff/contrib/addtiffo/addtiffo.c
> gs/tiff/contrib/addtiffo/tif_overview.c
> gs/tiff/contrib/addtiffo/tif_ovrcache.c
> gs/tiff/contrib/addtiffo/tif_ovrcache.h
> gs/tiff/contrib/dbs/Makefile.am
> gs/tiff/contrib/dbs/Makefile.in
> gs/tiff/contrib/dbs/tiff-bi.c
> gs/tiff/contrib/dbs/tiff-grayscale.c
> gs/tiff/contrib/dbs/tiff-palette.c
> gs/tiff/contrib/dbs/tiff-rgb.c
> gs/tiff/contrib/dbs/xtiff/Makefile.am
> gs/tiff/contrib/dbs/xtiff/Makefile.in
> gs/tiff/contrib/dbs/xtiff/patchlevel.h
> gs/tiff/contrib/dbs/xtiff/xtiff.c
> gs/tiff/contrib/dbs/xtiff/xtifficon.h
> gs/tiff/contrib/iptcutil/Makefile.in
> gs/tiff/contrib/iptcutil/iptcutil.c
> gs/tiff/contrib/mac-cw/Makefile.am
> gs/tiff/contrib/mac-cw/Makefile.in
> gs/tiff/contrib/mac-cw/Makefile.script
> gs/tiff/contrib/mac-cw/README
> gs/tiff/contrib/mac-cw/mac_main.c
> gs/tiff/contrib/mac-cw/mac_main.h
> gs/tiff/contrib/mac-cw/metrowerks.note
> gs/tiff/contrib/mac-cw/mkg3_main.c
> gs/tiff/contrib/mac-cw/version.h
> gs/tiff/contrib/mac-mpw/BUILD.mpw
> gs/tiff/contrib/mac-mpw/Makefile.am
> gs/tiff/contrib/mac-mpw/Makefile.in
> gs/tiff/contrib/mac-mpw/README
> gs/tiff/contrib/mac-mpw/libtiff.make
> gs/tiff/contrib/mac-mpw/mactrans.c
> gs/tiff/contrib/mac-mpw/port.make
> gs/tiff/contrib/mac-mpw/tools.make
> gs/tiff/contrib/mac-mpw/top.make
> gs/tiff/contrib/mfs/Makefile.am
> gs/tiff/contrib/mfs/Makefile.in
> gs/tiff/contrib/mfs/mfs_file.c
> gs/tiff/contrib/pds/Makefile.am
> gs/tiff/contrib/pds/Makefile.in
> gs/tiff/contrib/pds/tif_imageiter.c
> gs/tiff/contrib/pds/tif_imageiter.h
> gs/tiff/contrib/pds/tif_pdsdirread.c
> gs/tiff/contrib/pds/tif_pdsdirwrite.c
> gs/tiff/contrib/ras/Makefile.am
> gs/tiff/contrib/ras/Makefile.in
> gs/tiff/contrib/ras/ras2tif.c
> gs/tiff/contrib/ras/tif2ras.c
> gs/tiff/contrib/stream/Makefile.am
> gs/tiff/contrib/stream/Makefile.in
> gs/tiff/contrib/stream/tiffstream.cpp
> gs/tiff/contrib/stream/tiffstream.h
> gs/tiff/contrib/tags/Makefile.am
> gs/tiff/contrib/tags/Makefile.in
> gs/tiff/contrib/tags/listtif.c
> gs/tiff/contrib/tags/maketif.c
> gs/tiff/contrib/tags/xtif_dir.c
> gs/tiff/contrib/tags/xtiffio.h
> gs/tiff/contrib/tags/xtiffiop.h
> gs/tiff/contrib/win_dib/Makefile.am
> gs/tiff/contrib/win_dib/Makefile.in
> gs/tiff/contrib/win_dib/Tiffile.cpp
> gs/tiff/contrib/win_dib/tiff2dib.c
> gs/tiff/html/Makefile.am
> gs/tiff/html/Makefile.in
> gs/tiff/html/bugs.html
> gs/tiff/html/build.html
> gs/tiff/html/document.html
> gs/tiff/html/images/Makefile.in
> gs/tiff/html/index.html
> gs/tiff/html/man/Makefile.in
> gs/tiff/html/man/TIFFClose.3tiff.html
> gs/tiff/html/man/TIFFDataWidth.3tiff.html
> gs/tiff/html/man/TIFFError.3tiff.html
> gs/tiff/html/man/TIFFFlush.3tiff.html
> gs/tiff/html/man/TIFFGetField.3tiff.html
> gs/tiff/html/man/TIFFOpen.3tiff.html
> gs/tiff/html/man/TIFFPrintDirectory.3tiff.html
> gs/tiff/html/man/TIFFRGBAImage.3tiff.html
> gs/tiff/html/man/TIFFReadDirectory.3tiff.html
> gs/tiff/html/man/TIFFReadEncodedStrip.3tiff.html
> gs/tiff/html/man/TIFFReadEncodedTile.3tiff.html
> gs/tiff/html/man/TIFFReadRGBAImage.3tiff.html
> gs/tiff/html/man/TIFFReadRGBAStrip.3tiff.html
> gs/tiff/html/man/TIFFReadRGBATile.3tiff.html
> gs/tiff/html/man/TIFFReadRawStrip.3tiff.html
> gs/tiff/html/man/TIFFReadRawTile.3tiff.html
> gs/tiff/html/man/TIFFReadScanline.3tiff.html
> gs/tiff/html/man/TIFFReadTile.3tiff.html
> gs/tiff/html/man/TIFFSetDirectory.3tiff.html
> gs/tiff/html/man/TIFFSetField.3tiff.html
> gs/tiff/html/man/TIFFWarning.3tiff.html
> gs/tiff/html/man/TIFFWriteDirectory.3tiff.html
> gs/tiff/html/man/TIFFWriteEncodedStrip.3tiff.html
> gs/tiff/html/man/TIFFWriteEncodedTile.3tiff.html
> gs/tiff/html/man/TIFFWriteRawStrip.3tiff.html
> gs/tiff/html/man/TIFFWriteRawTile.3tiff.html
> gs/tiff/html/man/TIFFWriteScanline.3tiff.html
> gs/tiff/html/man/TIFFWriteTile.3tiff.html
> gs/tiff/html/man/TIFFbuffer.3tiff.html
> gs/tiff/html/man/TIFFcodec.3tiff.html
> gs/tiff/html/man/TIFFcolor.3tiff.html
> gs/tiff/html/man/TIFFmemory.3tiff.html
> gs/tiff/html/man/TIFFquery.3tiff.html
> gs/tiff/html/man/TIFFsize.3tiff.html
> gs/tiff/html/man/TIFFstrip.3tiff.html
> gs/tiff/html/man/TIFFswab.3tiff.html
> gs/tiff/html/man/TIFFtile.3tiff.html
> gs/tiff/html/man/fax2ps.1.html
> gs/tiff/html/man/fax2tiff.1.html
> gs/tiff/html/man/gif2tiff.1.html
> gs/tiff/html/man/libtiff.3tiff.html
> gs/tiff/html/man/pal2rgb.1.html
> gs/tiff/html/man/ppm2tiff.1.html
> gs/tiff/html/man/ras2tiff.1.html
> gs/tiff/html/man/raw2tiff.1.html
> gs/tiff/html/man/rgb2ycbcr.1.html
> gs/tiff/html/man/sgi2tiff.1.html
> gs/tiff/html/man/thumbnail.1.html
> gs/tiff/html/man/tiff2bw.1.html
> gs/tiff/html/man/tiff2pdf.1.html
> gs/tiff/html/man/tiff2ps.1.html
> gs/tiff/html/man/tiff2rgba.1.html
> gs/tiff/html/man/tiffcmp.1.html
> gs/tiff/html/man/tiffcp.1.html
> gs/tiff/html/man/tiffcrop.1.html
> gs/tiff/html/man/tiffdither.1.html
> gs/tiff/html/man/tiffdump.1.html
> gs/tiff/html/man/tiffgt.1.html
> gs/tiff/html/man/tiffinfo.1.html
> gs/tiff/html/man/tiffmedian.1.html
> gs/tiff/html/man/tiffset.1.html
> gs/tiff/html/man/tiffsplit.1.html
> gs/tiff/html/man/tiffsv.1.html
> gs/tiff/html/tools.html
> gs/tiff/html/v3.9.0beta.html
> gs/tiff/html/v3.9.1.html
> gs/tiff/html/v3.9.2.html
> gs/tiff/html/v4.0.0.html
> gs/tiff/libtiff-4.pc.in
> gs/tiff/libtiff/Makefile.am
> gs/tiff/libtiff/Makefile.in
> gs/tiff/libtiff/Makefile.vc
> gs/tiff/libtiff/libtiff.def
> gs/tiff/libtiff/libtiff.map
> gs/tiff/libtiff/libtiffxx.map
> gs/tiff/libtiff/mkg3states.c
> gs/tiff/libtiff/oog_table.h
> gs/tiff/libtiff/t4.h
> gs/tiff/libtiff/tif_acorn.c
> gs/tiff/libtiff/tif_apple.c
> gs/tiff/libtiff/tif_atari.c
> gs/tiff/libtiff/tif_aux.c
> gs/tiff/libtiff/tif_close.c
> gs/tiff/libtiff/tif_codec.c
> gs/tiff/libtiff/tif_color.c
> gs/tiff/libtiff/tif_compress.c
> gs/tiff/libtiff/tif_config.h.in
> gs/tiff/libtiff/tif_config.vc.h
> gs/tiff/libtiff/tif_config.wince.h
> gs/tiff/libtiff/tif_dir.c
> gs/tiff/libtiff/tif_dir.h
> gs/tiff/libtiff/tif_dirinfo.c
> gs/tiff/libtiff/tif_dirread.c
> gs/tiff/libtiff/tif_dirwrite.c
> gs/tiff/libtiff/tif_dumpmode.c
> gs/tiff/libtiff/tif_error.c
> gs/tiff/libtiff/tif_extension.c
> gs/tiff/libtiff/tif_fax3.c
> gs/tiff/libtiff/tif_fax3.h
> gs/tiff/libtiff/tif_fax3sm.c
> gs/tiff/libtiff/tif_flush.c
> gs/tiff/libtiff/tif_getimage.c
> gs/tiff/libtiff/tif_jbig.c
> gs/tiff/libtiff/tif_jpeg.c
> gs/tiff/libtiff/tif_jpeg_12.c
> gs/tiff/libtiff/tif_luv.c
> gs/tiff/libtiff/tif_lzma.c
> gs/tiff/libtiff/tif_lzw.c
> gs/tiff/libtiff/tif_msdos.c
> gs/tiff/libtiff/tif_next.c
> gs/tiff/libtiff/tif_ojpeg.c
> gs/tiff/libtiff/tif_open.c
> gs/tiff/libtiff/tif_packbits.c
> gs/tiff/libtiff/tif_pixarlog.c
> gs/tiff/libtiff/tif_predict.c
> gs/tiff/libtiff/tif_predict.h
> gs/tiff/libtiff/tif_print.c
> gs/tiff/libtiff/tif_read.c
> gs/tiff/libtiff/tif_stream.cxx
> gs/tiff/libtiff/tif_strip.c
> gs/tiff/libtiff/tif_swab.c
> gs/tiff/libtiff/tif_thunder.c
> gs/tiff/libtiff/tif_tile.c
> gs/tiff/libtiff/tif_unix.c
> gs/tiff/libtiff/tif_version.c
> gs/tiff/libtiff/tif_warning.c
> gs/tiff/libtiff/tif_win3.c
> gs/tiff/libtiff/tif_win32.c
> gs/tiff/libtiff/tif_write.c
> gs/tiff/libtiff/tif_zip.c
> gs/tiff/libtiff/tiff.h
> gs/tiff/libtiff/tiffconf.h.in
> gs/tiff/libtiff/tiffconf.vc.h
> gs/tiff/libtiff/tiffconf.wince.h
> gs/tiff/libtiff/tiffio.h
> gs/tiff/libtiff/tiffio.hxx
> gs/tiff/libtiff/tiffiop.h
> gs/tiff/libtiff/tiffvers.h
> gs/tiff/libtiff/uvcode.h
> gs/tiff/m4/acinclude.m4
> gs/tiff/m4/libtool.m4
> gs/tiff/m4/ltoptions.m4
> gs/tiff/m4/ltversion.m4
> gs/tiff/m4/lt~obsolete.m4
> gs/tiff/man/Makefile.in
> gs/tiff/man/TIFFClose.3tiff
> gs/tiff/man/TIFFDataWidth.3tiff
> gs/tiff/man/TIFFError.3tiff
> gs/tiff/man/TIFFFlush.3tiff
> gs/tiff/man/TIFFGetField.3tiff
> gs/tiff/man/TIFFOpen.3tiff
> gs/tiff/man/TIFFPrintDirectory.3tiff
> gs/tiff/man/TIFFRGBAImage.3tiff
> gs/tiff/man/TIFFReadDirectory.3tiff
> gs/tiff/man/TIFFReadEncodedStrip.3tiff
> gs/tiff/man/TIFFReadEncodedTile.3tiff
> gs/tiff/man/TIFFReadRGBAImage.3tiff
> gs/tiff/man/TIFFReadRGBAStrip.3tiff
> gs/tiff/man/TIFFReadRGBATile.3tiff
> gs/tiff/man/TIFFReadRawStrip.3tiff
> gs/tiff/man/TIFFReadRawTile.3tiff
> gs/tiff/man/TIFFReadScanline.3tiff
> gs/tiff/man/TIFFReadTile.3tiff
> gs/tiff/man/TIFFSetDirectory.3tiff
> gs/tiff/man/TIFFSetField.3tiff
> gs/tiff/man/TIFFWarning.3tiff
> gs/tiff/man/TIFFWriteDirectory.3tiff
> gs/tiff/man/TIFFWriteEncodedStrip.3tiff
> gs/tiff/man/TIFFWriteEncodedTile.3tiff
> gs/tiff/man/TIFFWriteRawStrip.3tiff
> gs/tiff/man/TIFFWriteRawTile.3tiff
> gs/tiff/man/TIFFWriteScanline.3tiff
> gs/tiff/man/TIFFWriteTile.3tiff
> gs/tiff/man/TIFFbuffer.3tiff
> gs/tiff/man/TIFFcodec.3tiff
> gs/tiff/man/TIFFcolor.3tiff
> gs/tiff/man/TIFFmemory.3tiff
> gs/tiff/man/TIFFquery.3tiff
> gs/tiff/man/TIFFsize.3tiff
> gs/tiff/man/TIFFstrip.3tiff
> gs/tiff/man/TIFFswab.3tiff
> gs/tiff/man/TIFFtile.3tiff
> gs/tiff/man/bmp2tiff.1
> gs/tiff/man/fax2ps.1
> gs/tiff/man/fax2tiff.1
> gs/tiff/man/gif2tiff.1
> gs/tiff/man/libtiff.3tiff
> gs/tiff/man/pal2rgb.1
> gs/tiff/man/ppm2tiff.1
> gs/tiff/man/ras2tiff.1
> gs/tiff/man/raw2tiff.1
> gs/tiff/man/rgb2ycbcr.1
> gs/tiff/man/sgi2tiff.1
> gs/tiff/man/thumbnail.1
> gs/tiff/man/tiff2bw.1
> gs/tiff/man/tiff2pdf.1
> gs/tiff/man/tiff2ps.1
> gs/tiff/man/tiff2rgba.1
> gs/tiff/man/tiffcmp.1
> gs/tiff/man/tiffcp.1
> gs/tiff/man/tiffcrop.1
> gs/tiff/man/tiffdither.1
> gs/tiff/man/tiffdump.1
> gs/tiff/man/tiffgt.1
> gs/tiff/man/tiffinfo.1
> gs/tiff/man/tiffmedian.1
> gs/tiff/man/tiffset.1
> gs/tiff/man/tiffsplit.1
> gs/tiff/man/tiffsv.1
> gs/tiff/port/Makefile.am
> gs/tiff/port/Makefile.in
> gs/tiff/port/dummy.c
> gs/tiff/port/getopt.c
> gs/tiff/port/libport.h
> gs/tiff/port/strcasecmp.c
> gs/tiff/port/strtoull.c
> gs/tiff/test/Makefile.am
> gs/tiff/test/Makefile.in
> gs/tiff/test/ascii_tag.c
> gs/tiff/test/bmp2tiff_palette.sh
> gs/tiff/test/bmp2tiff_rgb.sh
> gs/tiff/test/check_tag.c
> gs/tiff/test/common.sh
> gs/tiff/test/gif2tiff.sh
> gs/tiff/test/images/README.txt
> gs/tiff/test/images/logluv-3c-16b.tiff
> gs/tiff/test/images/minisblack-1c-16b.tiff
> gs/tiff/test/images/minisblack-1c-8b.pgm
> gs/tiff/test/images/minisblack-1c-8b.tiff
> gs/tiff/test/images/minisblack-2c-8b-alpha.tiff
> gs/tiff/test/images/miniswhite-1c-1b.pbm
> gs/tiff/test/images/miniswhite-1c-1b.tiff
> gs/tiff/test/images/palette-1c-1b.tiff
> gs/tiff/test/images/palette-1c-4b.tiff
> gs/tiff/test/images/palette-1c-8b.bmp
> gs/tiff/test/images/palette-1c-8b.gif
> gs/tiff/test/images/palette-1c-8b.tiff
> gs/tiff/test/images/rgb-3c-16b.tiff
> gs/tiff/test/images/rgb-3c-8b.bmp
> gs/tiff/test/images/rgb-3c-8b.ppm
> gs/tiff/test/images/rgb-3c-8b.tiff
> gs/tiff/test/long_tag.c
> gs/tiff/test/ppm2tiff_pbm.sh
> gs/tiff/test/ppm2tiff_pgm.sh
> gs/tiff/test/ppm2tiff_ppm.sh
> gs/tiff/test/rewrite_tag.c
> gs/tiff/test/short_tag.c
> gs/tiff/test/strip.c
> gs/tiff/test/strip_rw.c
> gs/tiff/test/tiff2pdf.sh
> gs/tiff/test/tiff2ps-EPS1.sh
> gs/tiff/test/tiff2ps-PS1.sh
> gs/tiff/test/tiff2ps-PS2.sh
> gs/tiff/test/tiff2ps-PS3.sh
> gs/tiff/test/tiff2rgba-logluv-3c-16b.sh
> gs/tiff/test/tiff2rgba-minisblack-1c-16b.sh
> gs/tiff/test/tiff2rgba-minisblack-1c-8b.sh
> gs/tiff/test/tiff2rgba-minisblack-2c-8b-alpha.sh
> gs/tiff/test/tiff2rgba-miniswhite-1c-1b.sh
> gs/tiff/test/tiff2rgba-palette-1c-1b.sh
> gs/tiff/test/tiff2rgba-palette-1c-4b.sh
> gs/tiff/test/tiff2rgba-palette-1c-8b.sh
> gs/tiff/test/tiff2rgba-rgb-3c-16b.sh
> gs/tiff/test/tiff2rgba-rgb-3c-8b.sh
> gs/tiff/test/tiffcp-g3-1d-fill.sh
> gs/tiff/test/tiffcp-g3-1d.sh
> gs/tiff/test/tiffcp-g3-2d-fill.sh
> gs/tiff/test/tiffcp-g3-2d.sh
> gs/tiff/test/tiffcp-g3.sh
> gs/tiff/test/tiffcp-g4.sh
> gs/tiff/test/tiffcp-logluv.sh
> gs/tiff/test/tiffcp-split-join.sh
> gs/tiff/test/tiffcp-split.sh
> gs/tiff/test/tiffcp-thumbnail.sh
> gs/tiff/test/tiffcrop-R90-logluv-3c-16b.sh
> gs/tiff/test/tiffcrop-R90-minisblack-1c-16b.sh
> gs/tiff/test/tiffcrop-R90-minisblack-1c-8b.sh
> gs/tiff/test/tiffcrop-R90-minisblack-2c-8b-alpha.sh
> gs/tiff/test/tiffcrop-R90-miniswhite-1c-1b.sh
> gs/tiff/test/tiffcrop-R90-palette-1c-1b.sh
> gs/tiff/test/tiffcrop-R90-palette-1c-4b.sh
> gs/tiff/test/tiffcrop-R90-palette-1c-8b.sh
> gs/tiff/test/tiffcrop-R90-rgb-3c-16b.sh
> gs/tiff/test/tiffcrop-R90-rgb-3c-8b.sh
> gs/tiff/test/tiffcrop-doubleflip-logluv-3c-16b.sh
> gs/tiff/test/tiffcrop-doubleflip-minisblack-1c-16b.sh
> gs/tiff/test/tiffcrop-doubleflip-minisblack-1c-8b.sh
> gs/tiff/test/tiffcrop-doubleflip-minisblack-2c-8b-alpha.sh
> gs/tiff/test/tiffcrop-doubleflip-miniswhite-1c-1b.sh
> gs/tiff/test/tiffcrop-doubleflip-palette-1c-1b.sh
> gs/tiff/test/tiffcrop-doubleflip-palette-1c-4b.sh
> gs/tiff/test/tiffcrop-doubleflip-palette-1c-8b.sh
> gs/tiff/test/tiffcrop-doubleflip-rgb-3c-16b.sh
> gs/tiff/test/tiffcrop-doubleflip-rgb-3c-8b.sh
> gs/tiff/test/tiffcrop-extract-logluv-3c-16b.sh
> gs/tiff/test/tiffcrop-extract-minisblack-1c-16b.sh
> gs/tiff/test/tiffcrop-extract-minisblack-1c-8b.sh
> gs/tiff/test/tiffcrop-extract-minisblack-2c-8b-alpha.sh
> gs/tiff/test/tiffcrop-extract-miniswhite-1c-1b.sh
> gs/tiff/test/tiffcrop-extract-palette-1c-1b.sh
> gs/tiff/test/tiffcrop-extract-palette-1c-4b.sh
> gs/tiff/test/tiffcrop-extract-palette-1c-8b.sh
> gs/tiff/test/tiffcrop-extract-rgb-3c-16b.sh
> gs/tiff/test/tiffcrop-extract-rgb-3c-8b.sh
> gs/tiff/test/tiffcrop-extractz14-logluv-3c-16b.sh
> gs/tiff/test/tiffcrop-extractz14-minisblack-1c-16b.sh
> gs/tiff/test/tiffcrop-extractz14-minisblack-1c-8b.sh
> gs/tiff/test/tiffcrop-extractz14-minisblack-2c-8b-alpha.sh
> gs/tiff/test/tiffcrop-extractz14-miniswhite-1c-1b.sh
> gs/tiff/test/tiffcrop-extractz14-palette-1c-1b.sh
> gs/tiff/test/tiffcrop-extractz14-palette-1c-4b.sh
> gs/tiff/test/tiffcrop-extractz14-palette-1c-8b.sh
> gs/tiff/test/tiffcrop-extractz14-rgb-3c-16b.sh
> gs/tiff/test/tiffcrop-extractz14-rgb-3c-8b.sh
> gs/tiff/test/tiffdump.sh
> gs/tiff/test/tiffinfo.sh
> gs/tiff/test/tifftest.h
> gs/tiff/tools/Makefile.am
> gs/tiff/tools/Makefile.in
> gs/tiff/tools/Makefile.vc
> gs/tiff/tools/bmp2tiff.c
> gs/tiff/tools/fax2ps.c
> gs/tiff/tools/fax2tiff.c
> gs/tiff/tools/gif2tiff.c
> gs/tiff/tools/pal2rgb.c
> gs/tiff/tools/ppm2tiff.c
> gs/tiff/tools/ras2tiff.c
> gs/tiff/tools/rasterfile.h
> gs/tiff/tools/raw2tiff.c
> gs/tiff/tools/rgb2ycbcr.c
> gs/tiff/tools/sgi2tiff.c
> gs/tiff/tools/sgisv.c
> gs/tiff/tools/thumbnail.c
> gs/tiff/tools/tiff2bw.c
> gs/tiff/tools/tiff2pdf.c
> gs/tiff/tools/tiff2ps.c
> gs/tiff/tools/tiff2rgba.c
> gs/tiff/tools/tiffcmp.c
> gs/tiff/tools/tiffcp.c
> gs/tiff/tools/tiffcrop.c
> gs/tiff/tools/tiffdither.c
> gs/tiff/tools/tiffdump.c
> gs/tiff/tools/tiffgt.c
> gs/tiff/tools/tiffinfo.c
> gs/tiff/tools/tiffmedian.c
> gs/tiff/tools/tiffset.c
> gs/tiff/tools/tiffsplit.c
> gs/tiff/tools/ycbcr.c

2012-06-09 01:16:35 +0100
Robin Watts <robin.watts@artifex.com>
63a26299f47bb9931a2b47772c95c38594535041

> Update the example build line given at the top of bmpcmp.c
> gs/toolbin/bmpcmp.c

2012-06-07 17:21:55 +0100
Robin Watts <robin.watts@artifex.com>
3cb19e101513e8fa99f86e959a493d7d57b9a69a

> Indentation fixes, plus avoid SEGVs in low memory cases.
> If allocations fail, spot that and return an error rather than
> dereferencing NULL pointers.
> gs/base/gdevp14.c

2012-06-08 15:51:43 +0100
Robin Watts <Robin.Watts@artifex.com>
e0fd2c6fe5cdba60e0252993319408ce8962afd3

> Enable Memento to be used with jbig2dec
> ./configure as usual, then "make XCFLAGS=-DMEMENTO".
> This involves duplicating memento within jbig2dec. We disable the GS
> specific build hacks, and add just one more; if GSBUILD is defined
> then jbig2 uses the version of memento from base, rather than the version
> of memento from inside jbig2. This avoids any potential problems with
> version skew.
> gs/base/jbig2.mak
> gs/jbig2dec/Makefile.in
> gs/jbig2dec/jbig2.h
> gs/jbig2dec/memento.c
> gs/jbig2dec/memento.h

2012-06-08 13:02:43 +0100
Chris Liddell <chris.liddell@artifex.com>
d7d86ee955e58d18f4ff3071c0f41c4e3f75aaea

> Update libpng to version 1.5.10
> Minor build revisions to deal with new libpng version:
> We copy the predefined pnglibconf.h into the build directory, and have
> libpng include it from there (it's less invasive than running the libpng
> configure script).
> We have to use the same kind of compiler incantation as lcms.mak because
> libpng 1.5.x suffers compatibility problems with /Za in Visual Studio
> as lcms does.
> Minor revision to XPS png reading code to cope with libpng 1.5.x API:
> Primarily, the 1.5.x API has made the png_info data type opaque to the calling
> code, so all access to the it contains *must* be done through function calls.
> No cluster differences expected.
> gs/base/png.mak
> gs/libpng/ANNOUNCE
> gs/libpng/CHANGES
> gs/libpng/CMakeLists.txt
> gs/libpng/INSTALL
> gs/libpng/KNOWNBUG
> gs/libpng/LICENSE
> gs/libpng/Makefile.am
> gs/libpng/Makefile.in
> gs/libpng/README
> gs/libpng/TODO
> gs/libpng/Y2KINFO
> gs/libpng/aclocal.m4
> gs/libpng/arm/filter_neon.S
> gs/libpng/autogen.sh
> gs/libpng/config.guess
> gs/libpng/config.h.in
> gs/libpng/config.sub
> gs/libpng/configure
> gs/libpng/configure.ac
> gs/libpng/contrib/README.txt
> gs/libpng/contrib/gregbook/COPYING
> gs/libpng/contrib/gregbook/Makefile.sgi
> gs/libpng/contrib/gregbook/Makefile.unx
> gs/libpng/contrib/gregbook/Makefile.w32
> gs/libpng/contrib/gregbook/README
> gs/libpng/contrib/gregbook/makevms.com
> gs/libpng/contrib/gregbook/readpng.c
> gs/libpng/contrib/gregbook/readpng2.c
> gs/libpng/contrib/gregbook/readpng2.h
> gs/libpng/contrib/gregbook/rpng-win.c
> gs/libpng/contrib/gregbook/rpng-x.c
> gs/libpng/contrib/gregbook/rpng2-win.c
> gs/libpng/contrib/gregbook/rpng2-x.c
> gs/libpng/contrib/gregbook/writepng.c
> gs/libpng/contrib/libtests/pngvalid.c
> gs/libpng/contrib/pngminim/README
> gs/libpng/contrib/pngminim/decoder/README
> gs/libpng/contrib/pngminim/decoder/gather.sh
> gs/libpng/contrib/pngminim/decoder/makefile
> gs/libpng/contrib/pngminim/decoder/pngusr.dfa
> gs/libpng/contrib/pngminim/decoder/pngusr.h
> gs/libpng/contrib/pngminim/encoder/README
> gs/libpng/contrib/pngminim/encoder/dummy_inflate.c
> gs/libpng/contrib/pngminim/encoder/gather.sh
> gs/libpng/contrib/pngminim/encoder/makefile
> gs/libpng/contrib/pngminim/encoder/pngusr.dfa
> gs/libpng/contrib/pngminim/encoder/pngusr.h
> gs/libpng/contrib/pngminim/preader/README
> gs/libpng/contrib/pngminim/preader/gather.sh
> gs/libpng/contrib/pngminim/preader/makefile
> gs/libpng/contrib/pngminim/preader/pngusr.dfa
> gs/libpng/contrib/pngminim/preader/pngusr.h
> gs/libpng/contrib/pngminus/makefile.std
> gs/libpng/contrib/pngminus/png2pnm.c
> gs/libpng/contrib/pngsuite/README
> gs/libpng/contrib/pngsuite/ftbbn1g04.png
> gs/libpng/contrib/pngsuite/ftbbn2c16.png
> gs/libpng/contrib/pngsuite/ftbbn3p08.png
> gs/libpng/contrib/pngsuite/ftbgn2c16.png
> gs/libpng/contrib/pngsuite/ftbgn3p08.png
> gs/libpng/contrib/pngsuite/ftbrn2c08.png
> gs/libpng/contrib/pngsuite/ftbwn1g16.png
> gs/libpng/contrib/pngsuite/ftbwn3p08.png
> gs/libpng/contrib/pngsuite/ftbyn3p08.png
> gs/libpng/contrib/pngsuite/ftp0n1g08.png
> gs/libpng/contrib/pngsuite/ftp0n2c08.png
> gs/libpng/contrib/pngsuite/ftp0n3p08.png
> gs/libpng/contrib/pngsuite/ftp1n3p08.png
> gs/libpng/contrib/visupng/PngFile.c
> gs/libpng/contrib/visupng/PngFile.h
> gs/libpng/contrib/visupng/README.txt
> gs/libpng/contrib/visupng/VisualPng.c
> gs/libpng/contrib/visupng/VisualPng.dsp
> gs/libpng/contrib/visupng/resource.h
> gs/libpng/depcomp
> gs/libpng/example.c
> gs/libpng/install-sh
> gs/libpng/libpng-1.2.42.txt
> gs/libpng/libpng-1.2.44.txt
> gs/libpng/libpng-config.in
> gs/libpng/libpng-manual.txt
> gs/libpng/libpng.3
> gs/libpng/libpng.pc.in
> gs/libpng/libpngpf.3
> gs/libpng/ltmain.sh
> gs/libpng/mkinstalldirs
> gs/libpng/png.5
> gs/libpng/png.c
> gs/libpng/png.h
> gs/libpng/pngconf.h
> gs/libpng/pngdebug.h
> gs/libpng/pngerror.c
> gs/libpng/pnggccrd.c
> gs/libpng/pngget.c
> gs/libpng/pnginfo.h
> gs/libpng/pngmem.c
> gs/libpng/pngpread.c
> gs/libpng/pngpriv.h
> gs/libpng/pngread.c
> gs/libpng/pngrio.c
> gs/libpng/pngrtran.c
> gs/libpng/pngrutil.c
> gs/libpng/pngset.c
> gs/libpng/pngstruct.h
> gs/libpng/pngtest.c
> gs/libpng/pngtest.png
> gs/libpng/pngtrans.c
> gs/libpng/pngusr.dfa
> gs/libpng/pngvcrd.c
> gs/libpng/pngwio.c
> gs/libpng/pngwrite.c
> gs/libpng/pngwtran.c
> gs/libpng/pngwutil.c
> gs/libpng/projects/beos/x86-shared.proj
> gs/libpng/projects/beos/x86-shared.txt
> gs/libpng/projects/beos/x86-static.proj
> gs/libpng/projects/beos/x86-static.txt
> gs/libpng/projects/cbuilder5/libpng.bpf
> gs/libpng/projects/cbuilder5/libpng.bpg
> gs/libpng/projects/cbuilder5/libpng.bpr
> gs/libpng/projects/cbuilder5/libpng.cpp
> gs/libpng/projects/cbuilder5/libpng.readme.txt
> gs/libpng/projects/cbuilder5/libpngstat.bpf
> gs/libpng/projects/cbuilder5/libpngstat.bpr
> gs/libpng/projects/cbuilder5/zlib.readme.txt
> gs/libpng/projects/netware.txt
> gs/libpng/projects/owatcom/libpng.tgt
> gs/libpng/projects/owatcom/libpng.wpj
> gs/libpng/projects/owatcom/pngconfig.mak
> gs/libpng/projects/owatcom/pngtest.tgt
> gs/libpng/projects/owatcom/pngvalid.tgt
> gs/libpng/projects/visualc6/README.txt
> gs/libpng/projects/visualc6/libpng.dsp
> gs/libpng/projects/visualc6/libpng.dsw
> gs/libpng/projects/visualc6/pngtest.dsp
> gs/libpng/projects/visualc71/PRJ0041.mak
> gs/libpng/projects/visualc71/README.txt
> gs/libpng/projects/visualc71/README_zlib.txt
> gs/libpng/projects/visualc71/libpng.sln
> gs/libpng/projects/visualc71/libpng.vcproj
> gs/libpng/projects/visualc71/pngtest.vcproj
> gs/libpng/projects/visualc71/zlib.vcproj
> gs/libpng/projects/vstudio/libpng/libpng.vcxproj
> gs/libpng/projects/vstudio/pnglibconf/pnglibconf.vcxproj
> gs/libpng/projects/vstudio/pngtest/pngtest.vcxproj
> gs/libpng/projects/vstudio/pngvalid/pngvalid.vcxproj
> gs/libpng/projects/vstudio/readme.txt
> gs/libpng/projects/vstudio/vstudio.sln
> gs/libpng/projects/vstudio/zlib.props
> gs/libpng/projects/vstudio/zlib/zlib.vcxproj
> gs/libpng/projects/wince.txt
> gs/libpng/projects/xcode/Info.plist
> gs/libpng/projects/xcode/libpng.xcodeproj/.gitignore
> gs/libpng/projects/xcode/libpng.xcodeproj/project.pbxproj
> gs/libpng/scripts/README.txt
> gs/libpng/scripts/checksym.awk
> gs/libpng/scripts/chkfmt
> gs/libpng/scripts/def.dfn
> gs/libpng/scripts/descrip.mms
> gs/libpng/scripts/libpng-config-head.in
> gs/libpng/scripts/libpng-config.in
> gs/libpng/scripts/libpng.icc
> gs/libpng/scripts/libpng.pc-configure.in
> gs/libpng/scripts/libpng.pc.in
> gs/libpng/scripts/makefile.32sunu
> gs/libpng/scripts/makefile.64sunu
> gs/libpng/scripts/makefile.acorn
> gs/libpng/scripts/makefile.aix
> gs/libpng/scripts/makefile.amiga
> gs/libpng/scripts/makefile.atari
> gs/libpng/scripts/makefile.bc32
> gs/libpng/scripts/makefile.beos
> gs/libpng/scripts/makefile.bor
> gs/libpng/scripts/makefile.cegcc
> gs/libpng/scripts/makefile.cygwin
> gs/libpng/scripts/makefile.darwin
> gs/libpng/scripts/makefile.dec
> gs/libpng/scripts/makefile.dj2
> gs/libpng/scripts/makefile.elf
> gs/libpng/scripts/makefile.freebsd
> gs/libpng/scripts/makefile.gcc
> gs/libpng/scripts/makefile.gcmmx
> gs/libpng/scripts/makefile.hp64
> gs/libpng/scripts/makefile.hpgcc
> gs/libpng/scripts/makefile.hpux
> gs/libpng/scripts/makefile.ibmc
> gs/libpng/scripts/makefile.intel
> gs/libpng/scripts/makefile.knr
> gs/libpng/scripts/makefile.linux
> gs/libpng/scripts/makefile.mingw
> gs/libpng/scripts/makefile.mips
> gs/libpng/scripts/makefile.msc
> gs/libpng/scripts/makefile.ne12bsd
> gs/libpng/scripts/makefile.netbsd
> gs/libpng/scripts/makefile.nommx
> gs/libpng/scripts/makefile.openbsd
> gs/libpng/scripts/makefile.os2
> gs/libpng/scripts/makefile.sco
> gs/libpng/scripts/makefile.sggcc
> gs/libpng/scripts/makefile.sgi
> gs/libpng/scripts/makefile.so9
> gs/libpng/scripts/makefile.solaris
> gs/libpng/scripts/makefile.solaris-x86
> gs/libpng/scripts/makefile.std
> gs/libpng/scripts/makefile.sunos
> gs/libpng/scripts/makefile.tc3
> gs/libpng/scripts/makefile.vcawin32
> gs/libpng/scripts/makefile.vcwin32
> gs/libpng/scripts/makefile.watcom
> gs/libpng/scripts/makevms.com
> gs/libpng/scripts/options.awk
> gs/libpng/scripts/png32ce.def
> gs/libpng/scripts/pnglibconf.dfa
> gs/libpng/scripts/pnglibconf.h.prebuilt
> gs/libpng/scripts/pnglibconf.mak
> gs/libpng/scripts/pngos2.def
> gs/libpng/scripts/pngw32.def
> gs/libpng/scripts/pngw32.rc
> gs/libpng/scripts/pngwin.rc
> gs/libpng/scripts/smakefile.ppc
> gs/libpng/scripts/sym.dfn
> gs/libpng/scripts/symbols.def
> gs/libpng/scripts/symbols.dfn
> gs/libpng/scripts/vers.dfn
> gs/libpng/test-pngtest.sh
> gs/libpng/test-pngvalid-full.sh
> gs/libpng/test-pngvalid-simple.sh
> xps/xpspng.c

2012-06-08 13:21:44 +0100
Robin Watts <robin.watts@artifex.com>
a85db51fecf74ba66bada63afece1799d58681ce

> Update bmpcmp png reading to cope with 8bit grayscale pngs.
> This used to work, but became broken with the device n support (when I
> stripped out the 8bpp operating modes)
> gs/toolbin/bmpcmp.c

2012-06-08 11:05:52 +0100
Ken Sharp <ken.sharp@artifex.com>
304d22a1744fa6ac07355703069cacd54f0c3ac4

> Move 'HighLevelDevice' from pdfwrite to gdevvec.c so vector devices inherit it.
> The 'HighLevelDevice' parameter was only defined for pdfwrite/ps2write, here
> we remove it from there and instead put it in the 'vector' device, so that
> all deices based on the vector device will have the paramter set.
> No differences expected
> gs/base/gdevpdfb.h
> gs/base/gdevpdfp.c
> gs/base/gdevpdfx.h
> gs/base/gdevvec.c

2012-06-07 16:47:10 +0100
Ken Sharp <ken.sharp@artifex.com>
1c8138bc1db9b3627a2ba1047568c385568061d0

> pdfwrite - fix handling of transparent images from PDF interpreter
> The PDF interperter can insert extra groups when dealing with transparent
> images, which we don't want to emit in the output PDF. These are marked
> by a 'image_with_SMask' flag.
> Previously we stored a boolean in the device structure, and tested that, if
> it was true we skipped the begin and transparency group operations.
> It turns out that it is possible to get a new group *inside* the generated
> group we are skipping, if that happens then the second group would reset
> the flag. This led to us skipping the 'begin' but not the 'end' with predictabley
> bad consequences.
> In this commit we alter the boolena to an unsigned int, and treat it as a
> series of bits. We flip the bits based on the 'FormDepth' which we track
> separately. This allows up to 32 levels of nesting which ought to be enough
> to deal even with Cairo files.
> Expected differences
> Bug689897.pdf exhibits small differences, not visually apparent. I believe this
> is a progression but its so slight as to be difficult to tell.
> gs/base/gdevpdft.c
> gs/base/gdevpdfx.h

2012-06-07 13:20:08 +0100
Robin Watts <robin.watts@artifex.com>
683bcefa2a8a05fb57d2d0d2d7aebf16de6bd11d

> Add new '--debug=gc-disable' flag to completely disable gc.
> Because I don't have any more hair to pull out.
> gs/base/gdbflags.h
> gs/psi/interp.c

2012-06-06 23:02:15 +0100
Robin Watts <robin.watts@artifex.com>
eb4f815d9b21a42280acb7ad2447ce69577b4ae5

> Fix pdf14_push_transparency_state stack handling.
> Rather than creating a new mask and adding it as the previous one,
> we should be making the new mask the topmost one on the stack.
> This way pop and push correctly do the opposite thing.
> gs/base/gdevp14.c

2012-06-06 17:16:53 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
6d24d5b9135f8ef6aa4da51a03952d5b39beb59a

> Bug 693050 : Fixes CERT reported issue labelled HeapError
> gs/jbig2dec/jbig2.c
> gs/jbig2dec/jbig2_image.c
> gs/jbig2dec/jbig2_metadata.c
> gs/jbig2dec/jbig2_priv.h
> gs/jbig2dec/jbig2_symbol_dict.c
> gs/jbig2dec/jbig2_text.c

2012-06-06 10:48:44 +0100
Chris Liddell <chris.liddell@artifex.com>
a0c6b9f271d715f122c01fc0fbbfd8d6cdf9c372

> Bug 693002 (again): fix doc and example file install list
> There were a number of missing files from the Unix install targets for
> the documentation and example files. Also, there were a few files in the
> list which no longer exist.
> No cluster differences.
> gs/base/unixinst.mak

2012-06-06 09:23:57 +0100
Chris Liddell <chris.liddell@artifex.com>
07799bffd70992116da89ed4d1717ce441f71461

> Bug 693094 related: missing libtiff build failure.
> If libtiff is missing, we correctly disabled the devices classified as
> "tiff devices", but left the "fax devices" in place, and the fax devices
> depend on libtiff.
> We'll now disable *all* the libtiff dependent devices if libtiff is not found.
> No cluster differences.
> gs/base/configure.ac

2012-06-06 09:38:39 +0100
Ken Sharp <ken.sharp@artifex.com>
cf75bee36e3a42f1bc253563a11169b47b92d307

> pdfwrite - don't write CIDSet for subset CIDFonts when emitting PDF/A-2
> The specification for CIDSet has changed for PDF/A-2 and I am currently
> unable to create a CIDSet which the Acrobat pre-flught tool will validate.
> Since PDF/A-2 now makes CIDSet optional, this commit omits it when we are
> producing PDF/A-2, so that we can create a valid file.
> No differences expected
> gs/base/gdevpdtd.c

2012-06-05 17:44:16 -0600
Henry Stiles <henry.stiles@artifex.com>
5fdae25deb3fa189f9d01a573fa77c2ec0f968ba

> Complete support for HPGL/2 new fill code, bug 692809.
> The new implementation which eliminates many unnecessary "moveto's"
> resulted in unexpected improvements in several CET files where
> creating a new subpath caused a join to be missing.
> pcl/pgdraw.c
> pcl/pgdraw.h
> pcl/pgpoly.c
> pcl/pgvector.c

2012-05-31 15:23:12 -0600
Henry Stiles <henry.stiles@artifex.com>
d303c79851b02aa810525bdaa4751c8247b66912

> A new state variable added that indicates if a high level device is in use.
> pcl/pcstate.h
> pcl/pctop.c
> pl/plmain.c
> pl/plmain.h
> pl/pltop.h

2012-05-19 16:53:26 -0600
Henry Stiles <henry.stiles@artifex.com>
8cbdd395e653227966a682b9b2de869565b49b5e

> Fixes 693049 - incorrect ccitt raster output.
> The CCITT filter was initialized to an additive color space instead of
> subtractive. Problem analyzed by Shailesh Mistry.
> pcl/rtraster.c

2012-05-16 15:26:11 -0600
Henry Stiles <henry.stiles@artifex.com>
868eda64307dabd30e308e07962346ef5991d3e3

> Changes to support the new fill code which allows filling when the pen is up.
> With the graphics library implementation of the hpgl/2 style fill code
> it is necessary to avoid unnecessary consecutive moveto's which were
> harmless in the previous code. In particular, closepath works
> differently if there are 2 or more consecutive moveto's. Using normal
> PostScript style paths the closepath will return to the last moveto in
> the path, the new code will convert a consecutive moveto to "gapto"
> and retain the first moveto and closepath will return to the original
> moveto.
> pcl/pgconfig.c
> pcl/pgdraw.c
> pcl/pglabel.c
> pcl/pgpoly.c
> pcl/pgvector.c

2012-05-07 07:45:46 -0600
Henry Stiles <henry.stiles@artifex.com>
c89c0b750594deac1b091776d18a9f0ed718ab60

> Debugging for dumping data from PCL commands that specify byte data
> and a data length.
> pcl/pcparse.c

2012-05-18 15:29:05 -0700
Ray Johnston <ray.johnston@artifex.com>
3e81e6caf112d59e31c17924ee89d7f3abddd7b1

> Fix bug 693034 -- correct comment in gxdevcl.h for GX_CINFO_UNKNOWN_SEP_LIN
> gs/base/gxdevcli.h

2012-06-05 16:39:39 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
54144189c8093c5c09d2f50d8cd57abc34ddd385

> Bug 693025 : Correct memory leaks reported by Zeniko
> gs/jbig2dec/jbig2_symbol_dict.c

2012-06-05 09:48:58 +0100
Chris Liddell <chris.liddell@artifex.com>
ad53769b1d690e790750f01bd6420fb2b8b76279

> Bug 693088: fix romfs?.dev dependency typo
> The two romfs?.dev targets had ECHO_XE in their dependencies, and it shouldbe
> ECHOGS_XE.
> No cluster differences.
> gs/base/lib.mak

2012-06-04 17:02:46 +0100
Robin Watts <robin.watts@artifex.com>
5b52e4534a2a7b9bc5d19a749df60e636ac4aa65

> Tweak filenames from RAW_DUMP debugging code.
> Output 2 digits before ")".
> In multistage output, put 'a', 'b', 'c' etc after ")" to ensure
> that they appear in alphasorted results in the same order as they
> are produced.
> gs/base/gdevp14.c
> gs/base/gxblend.c
> gs/base/gxblend1.c

2012-06-04 15:22:57 +0100
Ken Sharp <ken.sharp@artifex.com>
316a85cd0c7311716e85dc8f5ab32e36301e829c

> pdfwrite - Make sure TT fonts in PDF files are named using the PDF font name
> Bug #693086
> The problem was that the TrueType code used by the PDF interpreter uses the
> font name from the TrueType font, not the name from the PDF file. If two
> subsets are present then pdfwrite is unable to distinguish them if the
> Encodings are apparently the same (as they are here) as the fonts have have
> the same name internally, even though they are different in the PDF.
> TrueType CIDFonts already take the font naem form the PDF file and apply that
> so here we simply do the same for regular TrueType fonts.
> This causes a small difference in Bug689073.pdf, apparently becuase it
> contains two fonts called Arial,Bold
> gs/Resource/Init/gs_ttf.ps
> gs/Resource/Init/pdf_font.ps

2012-06-03 13:37:58 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
a6e24b063febdc3286015e94854cac156e70e2f1

> Rename pdf_open_document() to pdfwrite_pdf_open_document() to avoid a
> name conflict with mupdf.
> gs/base/gdevpdf.c
> gs/base/gdevpdfp.c
> gs/base/gdevpdfu.c
> gs/base/gdevpdfx.h

2012-06-01 11:50:32 -0700
Michael Vrhel <michael.vrhel@artifex.com>
c7aeb590a7a435d746a9400a15f8392746ac53c4

> Addition of capability for overprint simulation for CMYK colorants with RGB target device
> To have an RGB device do this simulation of CMYK overprinting you should have the device set
> its opmode in color info from GX_CINFO_OPMODE_UNKNOWN to GX_CINFO_OPMODE_RGB. In addition,
> to ensure consistent color in the document you should use the -dUseFastColor option since
> simulated RGB overprinting uses unmanaged color transformations.
> The fix required the addition of a compositor parameter which was a k value to be make use
> when we had K overprinting occurring.
> To port this fix to an earlier ghostscript release (pre-ICC) you will want to create a
> gx_set_overprint_DeviceRGB procedure for the gs_color_space_type_DeviceRGB type. This will
> be similar to gx_set_overprint_DeviceCMYK except it will end up calling gx_set_overprint_rgb
> instead of gx_set_overprint_cmyk. See changes in gsicc.c.
> gs/base/gscdevn.c
> gs/base/gscsepr.c
> gs/base/gscspace.c
> gs/base/gsicc.c
> gs/base/gsovrc.c
> gs/base/gsovrc.h
> gs/base/gxcspace.h
> gs/base/gxdevcli.h
> gs/base/gxoprect.c
> gs/base/gxoprect.h

2012-06-01 20:11:09 +0100
Robin Watts <robin.watts@artifex.com>
20e81025390c8487cb9794b37148f4bee9063bdc

> Update RAW_DUMP_AS_PAM to cope with tag planes, and greyscale spaces.
> gs/base/gxblend.c

2012-06-01 09:21:38 -0700
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
b1558100af4820b8718e7e346c3225d48eecf07c

> Fix minor typo in German man page - Bug 693080
> gs/man/de/pdf2dsc.1

2012-05-31 17:51:51 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
9cddb4c193c6123140c6f7b1960db34025f86e40

> Bug 693025: Correct typos reported by Zeniko
> gs/jbig2dec/jbig2_huffman.c
> gs/jbig2dec/jbig2_symbol_dict.c

2012-05-31 14:43:11 +0100
Ken Sharp <ken.sharp@artifex.com>
da9b12c5056369c5593d5b3604e787052fdd2f13

> pdfwrite - properly mark cos_stream as closed when closing associated stream
> Bug #6930 "Regression: /rangecheck in --pdfmark-- starting with 25b6a2cdeb5a90bb7803958f2bf15b618fbcf120"
> Commit 25b6a2cdeb5a90bb7803958f2bf15b618fbcf120 was a little too
> enthusiastic. In addition to properly closing the streams, I inadvertently
> removed the code which marks the pdfwrite cos_stream object as closed when
> we close the stream.
> Ordinarily this doesn't matter, but the pdfmark code checks to maek sure the
> stream associated with a named object is closed when it is used, and the
> removal of the code left it apparently open, causing the error.
> No differences expected
> gs/base/gdevpdti.c

2012-05-31 10:59:03 +0100
Ken Sharp <ken.sharp@artifex.com>
33dda0841be40cc8da9f350d10749ce8f4142fb7

> pdfwrite - memory problems, don't free dictionary parameter lists too early
> Bug #693069 "Regression: lockup with pdfwrite"
> The image dictioanry parameter lists for distillerparams were being freed
> after they were added to the 'parent' parameter list. If the same memory
> should then be reused for another parameter, the parent list would end up
> with corrupted linked list pointers leading to a variety of problems
> includign seg faults and loops.
> Although this appears as a regression its not really. The existing code only
> worked by fluke, all that the offending commit did was change he memory
> layout, triggering the problem.
> My initial feeling was that the c_param_write code should 'deep copy' dict
> parameters, just as it does for other complex objects. However reviewing the
> existing usage makes it clear that this is *not* what is done at present.
> Instead the list is simply inserted, and only freed when the parent list is
> released. This seems to me to be poor design, because other complex types
> are handled differntly, but that's the way it is. Copying the dictionary
> would mean reviewing all the places that use it and modifying them. It
> makes more sense to alter the pdfwrite code so that it doesn't release and
> free the dictioanry list.
> Took the opportunity to refactor a few places in the code which use massive
> 'if' clauses which call code. This construct is confusing and difficult to
> debug.
> No expected differences
> gs/base/gdevpsdp.c

2012-05-30 17:42:29 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
c579ff60fd8f7a83d46a87ed0813536871c4d13e

> Bug 693050 : Fixes CERT reported issue labelled DestAvNearNull
> gs/jbig2dec/jbig2_image.c
> gs/jbig2dec/jbig2_page.c
> gs/jbig2dec/jbig2_symbol_dict.c
> gs/jbig2dec/jbig2_text.c

2012-05-29 11:04:55 -0700
Michael Vrhel <michael.vrhel@artifex.com>
9623d013b27cd25257fa21ddb7d2df9c75f3e52d

> Fix for mistake in hashcode setting for CMM used with UseFastColor option
> Fixes bug 693036
> gs/base/gsicc_cache.c
> gs/base/gsicc_nocm.c

2012-05-28 13:05:00 +0100
Robin Watts <robin.watts@artifex.com>
f30e8944b915936befffbadc036e1de16659914e

> Add 16bpp support to downscaler.
> Currently unused, but passes local tests with James Cloos' proposed
> psdcmyk16 and psdrgb16 devices.
> gs/base/gdevpsd.c
> gs/base/gdevtsep.c
> gs/base/gxdownscale.c
> gs/base/gxdownscale.h

2012-05-27 23:35:06 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
c3c704eeab14e5d6401edd69867b06c812ce8f5a

> Bug 693050 : Fixes CERT reported issue labelled BranchAvNearNull
> gs/jbig2dec/jbig2_symbol_dict.c

2012-05-27 22:47:02 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
321055631457902050df08e645b0f91536cdd417

> Bug 693050 : Fixes CERT reported issue labelled BlockMoveAv
> gs/jbig2dec/jbig2_symbol_dict.c

2012-05-27 21:43:27 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
fb006f93c6fb6278a58886e0f72a5836c674ed22

> Bug 693050 : Fixes CERT reported issue labelled SegFaultOnPc
> gs/jbig2dec/jbig2_generic.c
> gs/jbig2dec/jbig2_image.c

2012-05-26 09:07:54 +0100
Ken Sharp <ken.sharp@artifex.com>
13922518fea2f417ff2d2dfa153c95396616e8ae

> pdfwrite - remove unused variable to silence compiler warning
> Although the warning is flagged as new, I don't think it is, its just that
> the variable declaration has moved to a new line as a result of a commit
> and so it appears to be new.
> In any event, the variable is unused and has been removed.
> gs/base/gdevpsf1.c

2012-05-25 17:55:31 +0100
Robin Watts <robin.watts@artifex.com>
fad17657f6f583dbdef5a634d0f11dd79e446ffe

> Bug 693070: psdrgb wasn't giving corrupted output.
> There were actually 2 bugs in here. The first one was spotted and
> fixed by James Cloos - many thanks; the arguments to memcpy were
> reversed.
> The second one was to do with the fact that postscript operation
> now thinks it has 14 colors. When we encode/decode, we were packing
> the colors into a word in such a way that we were losing the interesting
> ones off the top. Reverse the order of packing, and all is well.
> This still leaves an "interesting" fact about this device; we loop:
> for (chan_idx = 0; chan_idx < num_comp; chan_idx++)
> ...
> for (j = 0; j < xc->height; j++)
> ...
> get_bits_rectangle
> So, in the case where we have n components, and more than 1 band
> we'll be rendering the entire file n times - despite the fact that
> we request all the colors each time!
> gs/base/gdevpsd.c

2012-05-25 16:35:19 +0100
Robin Watts <robin.watts@artifex.com>
1c9e30044d1d698701091c9913a81e4b3688a134

> Add new -debug=validate-chunks debug flag.
> This causes a validation to be run after every operator is interpreted.
> Also, update the chunk validation code to give more informative error
> messages when problems are found. (For instance, if a reference is
> found to be duff, it's often the source of that reference you are
> interested in, not the reference itself).
> gs/base/gdbflags.h
> gs/base/gsmisc.c
> gs/psi/ialloc.h
> gs/psi/ilocate.c
> gs/psi/interp.c
> gs/psi/zvmem.c

2012-05-25 14:12:37 +0100
Ken Sharp <ken.sharp@artifex.com>
c6f9e998b9ab277f85815b927a841c26c507928a

> pdfwrite - fix /OtherSubr stripping with Multiple Master fonts
> Commit:
> 9f656faebac150c6aceca16c5ef6a78b92b6da43
> exposed a problem with this code, when we are stripping /OtherSubrs from MM
> fonts, the new CharString could be larger than the original (this can't
> happen for non-MM fonts). Because we only allocated a buffer big enough to
> hold the original (unstripped) data, we ended up with a buffer overflow.
> The code now calls the 'strip' routine twice, the first time to calculate
> how big a buffer will be required, the second time to actually do the work.
> This will fix the crash in test-setweightvector.ps introduced by the
> earlier commit
> gs/base/gdevpsf1.c

2012-05-25 14:08:52 +0100
Ken Sharp <ken.sharp@artifex.com>
9f656faebac150c6aceca16c5ef6a78b92b6da43

> pdfwrite - address problems with stringwidth and composite fonts
> Bug #693059 "Asian fonts placed badly with pdfwrite output"
> The problem here was caused by the way that pdf_process_string deals with 'widths'
> when responding to a strginwidth operation versus a regular show.
> When handling stringwidth the width of each glyph is added to the enumerator
> 'returned.total_width'. However, when handling a regular show, the width of
> the glyphs are simply stored directly into 'returned.total_width'.
> To handle the latter case the higher level code maintains its own total width
> but that was getting confused when a stringwidth was used.
> Ideally we would fix pdf_process_string to behave the same whether in response
> to a stringwidht or a show, but that routine is called from other places and
> making it coherent looks difficult. Instead we now process stringwidth
> differently form show, and don't accuulate wodths when we have a steingwidth
> operation in the higher level composite font code routines.
> No differences expected
> gs/base/gdevpdtc.c

2012-05-24 09:03:09 +0100
Robin Watts <robin.watts@artifex.com>
e21f69e10ddd68ea807773a8b57e10d23bd74a4f

> Fix a couple of error messages in bmpcmp
> gs/toolbin/bmpcmp.c

2012-05-23 15:53:53 +0100
Robin Watts <robin.watts@artifex.com>
e13b5cf5b8c7db67f88c5da62eeb8c8a4d077436

> Update psdcmyk and psdrgb to use the downscaler.
> gs/base/gdevpsd.c
> gs/base/gdevtsep.c

2012-05-23 10:18:56 +0100
Robin Watts <robin.watts@artifex.com>
27afc73a71b9c059b9d5358ed816cdf50e0a1f08

> Fix 2 'unused variable' warnings in downscaler.
> gs/base/gxdownscale.c

2012-05-22 20:42:31 +0100
Robin Watts <robin.watts@artifex.com>
ce801afb90764b4863dab9e51bc18082222fb3ce

> Unroll some loops in the downscaler for speed.
> Time to render first 10 pages of pdf_reference17.pdf to tiff:
> @200dpi = 5.2s
> @600dpi downscaled by 3 = 7.2s (before this)
> @600dpi downscaled by 3 = 6.5s (after this)
> gs/base/gxdownscale.c

2012-05-22 13:35:31 +0100
Robin Watts <robin.watts@artifex.com>
15cc33536ada0b4cb105110a48df0132539c54db

> Add downscaler functionality to tiffsep.
> Update tiffsep to call the downscaler. This means adding MinFeatureSize
> and DownScaleFactor to tiffsep. Also add BitsPerComponent to allow us to
> specify 8 (default) or 1 (monochrome). MinFeatureSize is ignored except
> in monochrome mode.
> This has meant slight reworking of the downscaler to cope with planar
> buffers, and its use of get_bits_rectangle rather than get_bits.
> Also updated docs, and fixed some leaks on memory allocation failures
> within tiffsep.
> gs/base/gdevtsep.c
> gs/base/gxdownscale.c
> gs/base/gxdownscale.h
> gs/base/lib.mak
> gs/doc/Devices.htm

2012-05-21 08:54:59 +0100
Ken Sharp <ken.sharp@artifex.com>
4677f28c2a0bf72a6bc89e785cc651d3deedc043

> txtwrite - Bug #693046 handle TEXT_FROM_CHARS and TEXT_FROM_SINGLE_CHAR ops
> I seem to have overlooked these operations when writing the original code,
> probably because I couldn't' find any test cases. However PCL seems to make
> extensive use of them, and the lack of code causes access outside array
> boundaries.
> Fixed here in a simplistic fashion, which seems to work well.
> No differences expected, txtwrite is not cluster tested
> gs/base/gdevtxtw.c

2012-05-20 16:31:14 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
535d11e8a1d667a3d71680b27f18e4a89df98b2d

> Bug 693044: fix pdfopt utility.
> Disable checking for the max pdf object number during PDF linearisation,
> because linearisation adds a few new objects to the PDF file.
> gs/lib/pdfopt.ps

2012-05-18 14:32:56 +0100
Ken Sharp <ken.sharp@artifex.com>
40cc976eae680d6a6f1297c5a0d556a37e9eb4b8

> txtwrite - clean up some benign silly compiler warnings
> gs/base/gdevtxtw.c

2012-05-18 12:56:17 +0100
Ken Sharp <ken.sharp@artifex.com>
44869447f94a15ae0082b89668576636e4c39575

> txtwrite - add a 'do nothing' rop device method to avoid errors
> gs/base/gdevtxtw.c

2012-05-16 14:55:02 +0100
Robin Watts <robin.watts@artifex.com>
1831d329606c767069dbc706632c4b30db4488ce

> Attempt to fix dashing in hpgl path mode.
> We were giving up dashing as soon as we hit the first gap in a path.
> Fix by treating gaps as an 'ink off' dash segment.
> gs/base/gxpdash.c

2012-05-16 18:22:38 +0100
Robin Watts <robin.watts@artifex.com>
422773777f1e6df2fd4decb3ca6b65801acfc1ac

> Update bmpcmp to cope with rgb and greyscale psd files.
> Also have a better stab at handling spot equivalent colors.
> CLUSTER_UNTESTED.
> gs/toolbin/bmpcmp.c

2012-05-15 20:00:19 +0100
Robin Watts <robin.watts@artifex.com>
8610551db7cc10c72d7a6bbfaa7ffe61d521a5d9

> Memento tweak: Allow MEMENTO_LEAKONLY to be defined by command line
> Currently Memento undefines MEMENTO_LEAKONLY at the top of memento.c.
> Change it here not to do that, so it can be supplied as part of a
> CFLAGS or XCFLAGS line.
> CLUSTER_UNTESTED.
> gs/base/memento.c

2012-05-15 19:44:50 +0100
Robin Watts <robin.watts@artifex.com>
a846030605e04c09265241853ed5ac3442c258e9

> Leak checking tweaks; memory finalisation and param handling
> When Ghostscript shuts down, it closes its malloc handler, which frees
> all the outstanding blocks it knows about. This is unhelpful behaviour
> when checking for leaks, so we disable this freeing in MEMENTO builds.
> Also, the Ghostscript arg handling code is quite keen on 'arg_copy'ing
> args only to pass them into routines that immediate copy them again
> into heap allocated buffers. These copies are then allowed to leak.
> Where it is obviously safe, avoid these copies. Where it's not so clear
> free them (using a new arg_free function).
> gs/base/gsargs.c
> gs/base/gsargs.h
> gs/base/gsmalloc.c
> gs/psi/imainarg.c

2012-05-15 18:22:06 +0100
Robin Watts <robin.watts@artifex.com>
b549f7df132df28783e34ef6839812b691c9eed5

> Bug 693039: Fix Memento crashes
> After reallocing a block, it is best to avoid reading from the old
> location. (Read flags, then realloc, then write flags).
> Also some minor tweaks to avoid warnings etc.
> gs/base/memento.c

2012-05-15 12:10:14 +0100
Chris Liddell <chris.liddell@artifex.com>
be37389c29534ffd9ce6bb31353f4f8c0273bfd3

> Add a bunch of derived files to .gitignore
> CLUSTER_UNTESTED
> .gitignore

2012-05-15 12:08:18 +0100
Chris Liddell <chris.liddell@artifex.com>
676ca45571121495de22c02ac7b03da14f75525c

> Call libtiff configure from ghostpdl configure.
> We had worked around the lack of a ghostpdl configure script by calling the
> libtiff configure from the Makefile - which is a horrible hack.
> Now that ghostpdl has a configure script, we can do the right thing, and call
> the libtiff script from the ghostodl one.
> No cluster differences.
> Makefile
> configure.ac

2012-05-14 21:00:46 +0100
Chris Liddell <chris.liddell@artifex.com>
827e5420e2d0b3c1bb3b9e656c27236ac650eacc

> Really remove derived files from jbig2dec directory
> No cluster differences.
> gs/jbig2dec/config.h
> gs/jbig2dec/libtool

2012-05-14 18:08:00 +0100
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
26ac0d3505530c6782dffeeaa053328a481afcb0

> Bug 693025: Updated patch from Zeniko to fix various crashes and leaks
> gs/jbig2dec/jbig2_halftone.c
> gs/jbig2dec/jbig2_huffman.c
> gs/jbig2dec/jbig2_image.c
> gs/jbig2dec/jbig2_refinement.c
> gs/jbig2dec/jbig2_segment.c
> gs/jbig2dec/jbig2_symbol_dict.c
> gs/jbig2dec/jbig2_text.c

2012-05-14 14:26:24 +0100
Ken Sharp <ken.sharp@artifex.com>
2699766796d407f04e790ca1374f68be00532847

> remove an unused variable to silence a compiler warning
> gs/base/gdevpdtt.c

2012-05-14 13:35:51 +0100
Ken Sharp <ken.sharp@artifex.com>
8ea8d0df81d2552a3470bbf708b91fb4467a5be2

> pdfwrite - memory fixes. don't track pdf_font_cache in GS fonts
> pdfwrite maintains a 'font cache' of PDF font objects which are related to
> GS fonts. Previously these were tracked by adding a pointer to the GS font,
> and freeing the memory when the font was unloaded, by using the gs_notify_register
> callback.
> This causes problems when we are in 'file per page' mode. We want to discard
> and rebuild the font cache at the end of each page, so we don't try to
> reuse font objects. But if we discard the memory, the font is still pointing
> at it. This causes later memory problems.
> The simplest solution is to stop tracking the elements in the GS fonts. This
> means that an element will persist and be stale after the font goes out of
> scope, but its a fairly small amount of memory per font. We now clean up the
> PDF font cache and all the elements in pdf_close along with all the other memory.
> The 'file per page' mode using the '-sOutputFilename=%d.pdf' syntax now seems
> to work correctly. There does not seem to be any great amount of memory leakage
> now either.
> The next step is to implement a 'server' mode application and use that to
> check that there are no remaining memory leaks
> No differences expected
> gs/base/gdevpdtt.c

2012-05-11 09:57:23 -0700
Ray Johnston <ray.johnston@artifex.com>
6b31a6466c0819db229cbde420c72789eecdbe2d

> Add missing part of commit to prevent access to freed memory.
> Somehow when applying this part of the reverted patch, this line (the
> one that actually prevented the access to freed memory) was missed.
> gs/base/gsicc_profilecache.c

2012-05-11 16:33:53 +0100
Ken Sharp <ken.sharp@artifex.com>
f9c1df276e998fc754d5c0e416c606cc5404a495

> pdfwrite - memory clean up. Clear outlines
> The outline objects are released in write_outline, but the entries in the
> device were not previously cleared leaving them pointing to freed memory.
> gs/base/gdevpdf.c

2012-05-11 11:38:32 +0100
Ken Sharp <ken.sharp@artifex.com>
08d715446bb97015d16e085aa8f8c4bd8f73c2cc

> pdfrite - memory cleanup, free Annotations
> Annotations weren't being freed along with their enclosing Page structure
> Add some comments about what is stored where, and when it is released, in
> a few places
> gs/base/gdevpdf.c
> gs/base/gdevpdtt.c

2012-05-10 13:24:15 -0700
Michael Vrhel <michael.vrhel@artifex.com>
54ecaf86c6fa0c4a31fb17e0c21361cb134ec376

> CIELAB vector and CIELAB images have to use a slightly different remap proc.
> The image data is already scaled as needed for the ICC code to handle directly.
> Vector colors require the decode from real CIELAB values. This fix was missing
> in the in image interpolation code. Fix for Bug 692885
> gs/base/gxiscale.c
> gs/base/lib.mak

2012-04-11 15:07:43 -0700
Michael Vrhel <michael.vrhel@artifex.com>
79925e26467289515d4cf499d2c3a2d3b1cdcaa4

> Delay of obtaining handles from CMM for default profiles
> Obtaining the profiles handles for all the default profiles in
> the ICC manager eats up a tiny amount of time on startup. For
> some customers that start and stop gs over and over instead of
> running in server mode, this startup time is an issue. This
> fix performs the initialization in a lazy manner, obtaining the
> profile handle only when finally needed.
> This commit also fixed some issues with images that are in the
> LAB color space.
> gs/base/gdevp14.c
> gs/base/gscdevn.c
> gs/base/gscsepr.c
> gs/base/gsicc.c
> gs/base/gsicc.h
> gs/base/gsicc_cache.c
> gs/base/gsicc_manage.c
> gs/base/gsicc_manage.h
> gs/base/gstrans.c
> gs/base/gxclimag.c
> gs/base/gxcmap.c
> gs/base/gxicolor.c
> gs/base/lib.mak

2012-05-09 22:01:46 -0700
Ray Johnston <ray.johnston@artifex.com>
c6d74690be87eb37ca5b4590ed6b44673e4125c7

> Fix bug 692372 and bug 693001 to free semaphores without leaking memory.
> The original fix (fe8d7b6) for 692372 released the semaphores, but resulted
> in memory leaks of many other parts of the imager state. The leak was fixed
> by reverting the above change. This change insures that sempahores are not
> leaked by adding 'finalization' to the icc_linkcache and icc_link structs.
> gs/base/gsicc_cache.c
> gs/base/gsistate.c
> gs/base/gsstruct.h

2012-05-09 09:56:00 -0700
Ray Johnston <ray.johnston@artifex.com>
055ed5f7a69ad5cf4181cf337abf2245df668c01

> Prevent reference to freed memory when freeing the profile cache.
> gs/base/gsicc_profilecache.c

2012-05-09 09:51:11 -0700
Ray Johnston <ray.johnston@artifex.com>
af974d1bd4b4f0470e77d28eb0cdcb72def2de76

> Revert "Fix bug 692372: Add finalize for imager_state to ref_count decrement icc structs."
> This reverts commit fe8d7b6aebfed3c724a860e31ff170764d5429dc.
> This commit resulted in a subsantial memory leak detected with PCL. See
> bug 693001. The finalization should be for the icc structs that have
> semaphores.
> gs/base/gsicc_profilecache.c
> gs/base/gsistate.c
> gs/base/gsstate.c
> gs/base/gxistate.h
> gs/base/gzstate.h

2012-05-09 13:07:39 +0100
Chris Liddell <chris.liddell@artifex.com>
0ee6bd45c59c2ae99ec30cba4dae22d1f2e20dc4

> Remove a couple of derived files from jbig2dec.
> No cluster differences.
> gs/jbig2dec/libtool

2012-05-09 09:52:11 +0100
Ken Sharp <ken.sharp@artifex.com>
a32c42253c299d55d44ad39ba3d998fcebbef7ba

> pdfwrite - memory cleanup; use correct allocater, don't free tracked object
> Previously the code to free font resources was using the wrong memory
> allocator to free some objects, fixed here.
> It also seems that, contrary to what I thought Function resources *are*
> tracked by 'last_resource' in teh pdfwrite device structure. So its important
> not to free those twice.
> No differences expected
> gs/base/gdevpdf.c
> gs/base/gdevpdtf.c

2012-05-07 19:14:28 +0100
Chris Liddell <chris.liddell@artifex.com>
365df54880adff1bd0b7d983c440fb518250c9f0

> Fix a warning in zfapi.c
> No cluster differences.
> gs/psi/zfapi.c

2012-05-07 17:47:33 +0100
Robin Watts <robin.watts@artifex.com>
949993da66cd9850ce47c7319465aed42585b261

> Tweak bmpcmp error message
> gs/toolbin/bmpcmp.c

2012-05-07 16:34:51 +0100
Chris Liddell <chris.liddell@artifex.com>
fee1ab3e7e38c3e2bd82a855d7bdec2c18751320

> Bug 693023: fix $Blend in Type 1 font serialization
> When serializing a MultipleMaster font, we were writing both a 'boiler plate'
> $Blend procedure, and a broken $Blend from the font dictionary - broken because
> the code to read the procedure from the dictionary ignored name objects.
> In general, this was fine, as all the current FAPI scalers ignore the $Blend.
> A problem arose because the code which calculated size of the procedure did
> handle PS name objects, so we ended up with unitialized bytes trailing the
> dictionary data, which could cause the scaler to error.
> No cluster differences.
> gs/psi/write_t1.c
> gs/psi/zfapi.c

2012-05-03 12:13:06 -0700
Michael Vrhel <michael.vrhel@artifex.com>
7b81312d205a2f9b89f40da4b4f6b67bcacd8ef1

> Fix for issues in use of /SeparationOrder and /SeparationColorNames
> Several issues and quite a bit of confusion in the code with respect
> to this option. I believe this should clear some things up.
> Documentation still needs to be updated as to how this option functions
> and what devices it actually works with. Note that
> SeparationOrder and SeparationColorNames really only works for the
> tiffsep device. The psdcmyk device was never really set up for use
> with this option. Not sure if we want to add it. Also, I discovered
> that with the disabling of compressed color encoding, the tiffsep1
> device renders incorrectly. I had not converted this device to planar
> as I had thought that it performed halftoning during rendering. I
> did not realize it was rendering 8 bit data and then doing
> a thresholding operation. We may want to just move this to a planar
> based device. In that case, we could use the fast planar halftoning.
> Note that with this fix, the device will only create output for the
> colorants listed in /SeparationOrder. The psdcmyk device was not
> making use of the /SeparationOrder information properly. It is now
> which makes for some different renderings in the ps3cet/29-07*.ps test
> files which exercise /SeparationOrder changes. In such a case, the
> device will not output any missing colorants, which previously
> it was doing.
> gs/base/gdevdevn.c
> gs/base/gdevpsd.c
> gs/base/gdevtsep.c

2012-05-05 11:21:31 +0100
Ken Sharp <ken.sharp@artifex.com>
c5f91f9fa29922713d3751654dda09ccc8518801

> pdfwrite - memory leaks with CIDFonts
> Move the code to free font resources from the 'pdf close' into a separate
> routine in the font handling module. Additionally call it for CIDFont
> resoruces as well as Font resources (the code copes with freeing both)
> No differences expected
> gs/base/gdevpdf.c
> gs/base/gdevpdtf.c
> gs/base/gdevpdtf.h

2012-05-05 01:03:31 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
922400e9056ad46a27e0ab5964213415061bd801

> Bug 693027: Add missing spot color extraction from shading patterns.
> Old code processed all patterns as tiled patterns and missed the
> shading color space.
> gs/Resource/Init/pdf_main.ps

2012-05-04 15:19:15 +0100
Chris Liddell <chris.liddell@artifex.com>
b2b2473f2064b4abd835449b761e46fdbb5a47f1

> Bring the gs/jbig2dec directory in line with jbig2dec repos.
> Mainly autoconf source files like configure.ac
> No cluster differences.
> gs/jbig2dec/Makefile.in
> gs/jbig2dec/aclocal.m4
> gs/jbig2dec/annex-h.jbig2
> gs/jbig2dec/autogen.sh
> gs/jbig2dec/compile
> gs/jbig2dec/config.guess
> gs/jbig2dec/config.h
> gs/jbig2dec/config.h.in
> gs/jbig2dec/config.sub
> gs/jbig2dec/configure
> gs/jbig2dec/depcomp
> gs/jbig2dec/install-sh
> gs/jbig2dec/libtool
> gs/jbig2dec/ltmain.sh
> gs/jbig2dec/missing
> gs/jbig2dec/pbm2png.c
> gs/jbig2dec/stamp-h1

2012-04-19 16:44:48 +0100
Ken Sharp <ken.sharp@artifex.com>
19e1c90a1185b681e081cc50ea64a73e8fd8f9b7

> pdfwrite - address memory leaks
> First pass at cleaning up pdfwrite's memory 'management'.
> Add clean up code in pdf_close for fonts, font descriptors, type 3 CharProc
> and Pattern resources.
> Since we only need the object number for a reference we now create a new
> type of cos object 'reference'. This only contains the object ID so that
> we cna write out the reference. We also set the ID to 0 after we write it
> as this will allow us to free the object. (id == 0 is a crazy reference
> counting thing, it seems)
> Free the 'aside' associated with a pattern after releasing it.
> free ExtGState resources at close.
> There was no code to free CMaps, none at all. Added routines to free regular
> CMaps and ToUnicode CMaps, and added code to pdfwrite to call these in order
> to actually free CMap resources.
> When manufacturing a BaseFont, if we already have a BaseFont name, dispose
> of it before assigning a new one. Previously this leaked the string
> containing the name.
> release font resoruce objects
> when freeing a font descriptor, free the object as well as the glyphs
> Free copied base font FontName string on close
> This is opaque data specific to each font type, so we may need to add
> specific cleanup routines, but this is a start.
> Secondly, when pdfwrite copeis a font it makes 2 copies, a subset and a
> complete copy. However the complete copy can fail because of an unused
> glyph. So we dicard the complete copy and carry on with the subset. In
> this case we didnt' clean up the 'complete' copy.
> Modified the previous code into one routine to free copied fonts, when we
> discard a (complete) copied font during font copying free the font copy.
> free Encoding from copied fonts if present
> Also, change the text for font freeing so it makes sense.
> Free copied font 'data' when freeing copied font
> Free the 'base_font' structure when freeing FontDescriptors
> release colour spaces.
> Make a routine to free colour spaces, and have it free the 'serialized'
> color space memory.
> Free the page dictionary when we free pages.
> We seem to have (at least) two different kinds of param lists which are used
> to deal with getting/setting device params. The PostScript interpreter uses
> 'ref_params' and the PCL interpreter uses 'c_params'.
> The problem is that 'ref_params_end_write_collection' frees the list memory
> but 'c_params_end_write_collection' does not. Since these are accessed through
> methods in the list, we don't know whether we need to free the memory or not.
> This leads to a memory leak when using the PCL interpreter.
> I suspect this is a bug in the implementation, but for now I've modified
> 'ref_params_end_write_collection' so that it nulls the pointer to the list
> when it frees it. The code in gdevdsp.c can then test to see whether the
> memory needs to be freed (non-NULL) or not.
> For some reason this leads to a Seg Fault with fts_09_0923.pdf, but I
> can't see why. I believe this is unrelated, so will investigate it further
> after this work is completed.
> Also changed a typecast to eliminate a warning
> create a routine to clean up the 'text data' and call it. Add the
> 'standard fonts' to the clenaup in there.
> Clean up a number of allocations (name index stack, namespace
> stack etc).
> Add code to free Funtiocn resource dictionaries, objects and resources,
> These were missed previously, because the development was done in PCL and
> teh PCL interpreter can't trigger the use of Functions.
> Add code to clean up Shading and group dictionary resources. Add code to
> clear the resource chains on close so that we don't end up trying to use
> freed memory pointers.
> gs/base/gdevpdf.c
> gs/base/gdevpdfc.c
> gs/base/gdevpdfg.h
> gs/base/gdevpdfi.c
> gs/base/gdevpdfo.c
> gs/base/gdevpdfo.h
> gs/base/gdevpdfu.c
> gs/base/gdevpdfv.c
> gs/base/gdevpdfx.h
> gs/base/gdevpdt.c
> gs/base/gdevpdt.h
> gs/base/gdevpdtb.c
> gs/base/gdevpdtd.c
> gs/base/gdevpdtd.h
> gs/base/gdevpdtf.c
> gs/base/gdevpdti.c
> gs/base/gdevpdti.h
> gs/base/gdevpsdp.c
> gs/base/gsfcmap.c
> gs/base/gsfcmap.h
> gs/base/gxfcmap.h
> gs/base/gxfcopy.c
> gs/base/gxfcopy.h
> gs/psi/iparam.c

2012-05-01 12:29:03 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
714b375a58593b62a38c3fa5dfacd0fae2d7d1f9

> Bug 693006: Guess malformed numbers.
> If an unknown PDF operator has only [-.0-9], consider it a malformed
> number and replace with 0.
> gs/Resource/Init/pdf_base.ps

2012-05-01 01:41:25 -0700
Michael Vrhel <michael.vrhel@artifex.com>
885289be955a17cb75a401a71d3b6529c755e96b

> Fix for another indeterminism from 60640aeb33b18f9a9fcd76fc6f1083d7c7635f2
> gs/base/gxdcolor.c

2012-05-01 01:41:18 -0700
Ray Johnston <ray.johnston@artifex.com>
c51dd0ad9b442a05844e1b8eb3e4b511af8c0392

> Optimize transparency bbox for image SMask.
> SMask with GreyBackground != 1.0 needs to use parent bbox, but image
> SMask only paint the image area so the BC cannot affect areas outside.
> gs/base/gdevp14.c

2012-04-30 15:11:38 -0700
Michael Vrhel <michael.vrhel@artifex.com>
af102f5fe9a91a071b2d01c3e8ee35a0c99275ea

> Fix for indeterminism introduced in 60640aeb33b18f9a9fcd76fc6f1083d7c7635f24
> The shading code was using the number of components of the target device
> in making a linearity determination. It should make use of the destination
> ICC profile in that computation.
> gs/base/gsicc.c

2012-04-29 23:36:02 -0700
Michael Vrhel <michael.vrhel@artifex.com>
e8f8eed2369d5e8709acd0aa65306758aa322e3d

> Initialize color procs for clip list accumulator
> There are calls made during filling with this device to get the black point
> of the device due to some ROP related call. The device did not have any
> procedures for mapping colors or for decode and encode. Fix for Bug 692720.
> gs/base/gxacpath.c

2012-04-30 15:27:30 +0100
Chris Liddell <chris.liddell@artifex.com>
3cde6d6d3d24a0930d591df9914ddda194d13b37

> Bug 692459: stop tiffsep(1) overwriting pages already written
> The tiffsep and tiffsep1 devices both get closed and reopen when the separations
> change (communicated by put_params). Previously this caused the output files to
> be closed and reopened - not a problem when writing each page to its own set of
> files, but when writing multipage tiffs, it resulted in all pages up to that
> point to be overwritten.
> We now have tiffsep and tiffsep1 handle their own file "management", and prevent
> output files from being closed and reopened when the device is closed and
> reopened due to a put_params call.
> No cluster differences.
> gs/base/gdevtsep.c

2012-04-27 18:46:27 +0100
Robin Watts <robin.watts@artifex.com>
60640aeb33b18f9a9fcd76fc6f1083d7c7635f24

> * Change of the tiffsep and psdcmyk device to planar devices.
> This change in these devices was made to remove the 64 bit limitation of
> our existing color encoding which limits us to 8 colorants without
> compressed color encoding. The motivation for this work is that even
> with compressed color encoding we were starting
> to encounter files with transparency in particular that exceeded the
> capabilities of encoding, leading to dropped colors. With this fix, we
> encode through the clist the DeviceN color values. The buffers for the
> devices are maintained as planar buffers and fills occur with the high level
> device colors.
> Support was added to handle the devn color type through the shading code. The old
> code would have supported only 8 colorants in a shading.
> Support was also added to the transparency code to enable the use of the put_image
> procedure which for the planar device saves quite a bit of time since we can do the
> copy_planes proc directly from the pdf14 planar buffer to the planar memory device buffer.
> The pdf14 device also had to support fill_rectangle_hl_color.
> Changes were also made to the pattern tiling code so that we avoid any planar to chunky and
> back to planar conversions. These were being done to handle ROPs. Even when there were
> not any ROPs to perform we were going through strip_tile_rop operations since the
> gx_default_strip_tile_rectangle did not support planar to planar. That support is added
> with this commit.
> Support had to be added to the overprint compositor to support the new color type with
> fill_rectangle_hl_color.
> Support had to be added to the clist for fill_rectangle_hl_color. This required changes
> on both the writing and reading side. It is possible that the amount of data written
> for these commands could be reduced and that is commented in the code.
> Support also had to be added to the clip device and the mask_clip device as well
> for uncolored patterns. Also the tile clip device required support and the transparency device
> required support for copy_planes. This last function needs to be optimized.
> Both of the separation devices (tiffsep and psdcmyk) that we currently have are updated to
> support this method. There is an #if option in each device file to return the
> code back to the old chunky format.
> A new device procedure for handling strip tiling of masks with devn colors had
> to be added. Functionality was only required for the mem planar and clist devices.
> Also, it was found that the tiffsep and psdcmyk devices were maintaining separations
> (spot colors) across pages. That is if page 1 had a spot color, subsequent pages
> created a separation for that spot
> even if those pages did not contain it. This was fixed so that separations for a page
> are only created for the spots that occur on that page.
> A fix was also made to ensure that we had proper handling for the None colorants when
> they are part of the DeviceN color space.
> gs/base/devs.mak
> gs/base/gdevbbox.c
> gs/base/gdevdbit.c
> gs/base/gdevdevn.c
> gs/base/gdevdevn.h
> gs/base/gdevdflt.c
> gs/base/gdevdsha.c
> gs/base/gdevmem.c
> gs/base/gdevmem.h
> gs/base/gdevmpla.c
> gs/base/gdevmx.c
> gs/base/gdevnfwd.c
> gs/base/gdevp14.c
> gs/base/gdevpdfi.c
> gs/base/gdevppla.c
> gs/base/gdevprn.c
> gs/base/gdevpsd.c
> gs/base/gdevtsep.c
> gs/base/gscdevn.c
> gs/base/gscicach.c
> gs/base/gscms.h
> gs/base/gscsepr.c
> gs/base/gsdcolor.h
> gs/base/gsdps1.c
> gs/base/gsequivc.c
> gs/base/gsicc_manage.c
> gs/base/gsovrc.c
> gs/base/gsptype1.c
> gs/base/gxblend.h
> gs/base/gxblend1.c
> gs/base/gxcldev.h
> gs/base/gxclimag.c
> gs/base/gxclip.c
> gs/base/gxclip.h
> gs/base/gxclip2.c
> gs/base/gxclipm.c
> gs/base/gxclist.c
> gs/base/gxclpath.c
> gs/base/gxclpath.h
> gs/base/gxclrast.c
> gs/base/gxclrect.c
> gs/base/gxcmap.c
> gs/base/gxdcolor.c
> gs/base/gxdcolor.h
> gs/base/gxdevcli.h
> gs/base/gxdevice.h
> gs/base/gxdevsop.h
> gs/base/gxgetbit.h
> gs/base/gxht.c
> gs/base/gxicolor.c
> gs/base/gxp1fill.c
> gs/base/gxp1impl.h
> gs/base/gxpcmap.c
> gs/base/gxpcolor.h
> gs/base/gxshade6.c
> gs/base/lib.mak

2012-04-26 15:11:18 +0100
Robin Watts <robin.watts@artifex.com>
dd09a0706ab09a54f5fbb05c63420c86375b45bf

> Memento tweaks; add Memento_breakOnFree/Realloc functionality.
> Memento_breakOnFree(address) will cause a breakpoint when the block
> including a given address is freed. If the block is realloced (and
> hence moves elsewhere) the breakpoint is not triggered until the new
> block is itself freed.
> Memento_breakOnRealloc(address) will cause a breakpoint when the block
> including a given address is freed or realloced.
> gs/base/memento.c
> gs/base/memento.h

2012-04-25 17:33:59 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
012aef926d1e33cc64c32bf8e94ef92a299d73f9

> Bug 692243: Replace dictionary look-up with .execn
> Replace a fragment that stores line width in a dictionary with an equivalent
> code that uses execution stack and .execn . These tricks are needed to keep
> the stack depth constant.
> gs/Resource/Init/pdf_ops.ps

2012-04-25 00:08:53 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
70d513095fba13b20e6bba5bb77805b5233028d1

> Bug 692243: Fix a typo in absolute value comparison.
> gs/Resource/Init/pdf_ops.ps

2012-04-24 17:35:10 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
f1830075608195e2976751303d220fda3f796abb

> Bug 692969: Don't verify PDF 1.5 xref.
> Don't verify stream xref table because we cannot repair PDF files with
> new object format. Such verification only increases the chance that the
> file fails.
> gs/Resource/Init/pdf_main.ps

2012-04-24 15:06:16 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
430e9e345c84912f953161aa843b37f235c97708

> Bug 693000: Verify /Subtype of CIDFont resource.
> Check whether CIDFont resource refers to a Type 1 file and process
> it accordingly.
> gs/Resource/Init/pdf_font.ps

2012-04-24 17:48:12 +0000
Robin Watts <robin.watts@artifex.com>
b5d2134b8ebea14594411580776f1bce5c40363c

> Add gx_forward_copy_planes.
> Add this to the overprint device.
> gs/base/gdevnfwd.c
> gs/base/gsovrc.c
> gs/base/gxdevice.h

2012-04-24 10:15:59 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
c2a982ffda019b2822799a918d53022ec06342fa

> Pacify Valgrind: don't calculate unused values from undefined data.
> gs/lcms2/src/cmsopt.c

2012-04-24 10:19:01 +0100
Chris Liddell <chris.liddell@artifex.com>
f10560765a226f668b72fd9b8298d644cbce08ab

> Bug 693002: Add recently added files to install-doc target.
> thirdparty.htm WhatIsGS.htm GS9_Color_Management.pdf
> No cluster differences.
> gs/base/unixinst.mak

2012-04-23 23:44:18 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
d561224d1495321d40012230abbcf835b298f557

> Bug 692983: Require EOD mark in ASCII85 string.
> Make sure that ASCII85-encoded string is terminated with '~>' and
> throw an error if it isn't. Old code accepted EOF as a valid
> termination for a string token.
> gs/base/sa85d.c
> gs/base/sa85d.h
> gs/psi/iscan.c

2012-04-23 20:03:50 +0100
Robin Watts <robin.watts@artifex.com>
ec092a2630dd215a317f509ca283fc5cfb4e8b02

> Planar device memory setup tweaks.
> When setting up a memory planar device, we currently build a mask
> out of the plane information supplied to us about how to pack
> colors into a gx_color_index. This seems like a reasonable thing to
> do as we will always need to pack colors into a gx_color_index at
> some point.
> As part of his work on tiffsep, Michael is about to lift this
> requirement though, enabling us to cope with larger numbers of
> spots. The code as is fails on certain machines/compilers due to
> C's undefined behaviour when shifting by more bits than are in the
> variable. We spot this case explicitly, and don't bother checking
> for overlap in this case.
> gs/base/gdevmpla.c

2012-04-23 15:51:17 +0100
Chris Liddell <chris.liddell@artifex.com>
3a8fbd9c52897cccce7cb6e61e06acb1fe8bff7f

> Fix uninitialised variable access
> Previous commit highlighted a missing a return value check which could result
> in an uninitialised variable being accessed.
> gs/psi/zfapi.c

2012-04-23 13:36:53 +0100
Chris Liddell <chris.liddell@artifex.com>
f57b7562c79a9e3649e95e7bafa6193b571154bb

> Handle the remaining CIDFonts that FAPI was missing.
> This causes a number of cluster file differences, almost all are the usual
> single pixel differences. There are few cases slightly better, and a few
> slightly worse.
> One file is a "regression" (depending on your point of view) which is badq.pdf
> where the two contours making up the lower case "q" both go in the same
> direction, so non-zero winding for filling results in the "loop" in the "q"
> being completely filled.
> The font is to blame here, but I will continue to look into a solution for
> Freetype.
> gs/psi/zfapi.c

2012-04-21 13:46:37 +0100
Robin Watts <robin.watts@artifex.com>
b40ce1e58c211008831971f3866cb49e912a1e4f

> bmpcmp: Error handling tweaks.
> When failing to match a page due to differences in number of colors
> or sizes etc, output the page number and continue looking at other
> pages in the file.
> gs/toolbin/bmpcmp.c

2012-04-20 13:52:33 -0600
Henry Stiles <henry.stiles@artifex.com>
a943658240231bede6cd5f04d7f1bfa713918ccf

> Fixes 692992. Implicit closepaths not properly detected.
> GL/2 closepaths, implicitly detected when the first point of a subpath
> and last are equal, were not recognized in some cases because we were
> doing a comparison of transformed floating point values, the
> comparison is now done correctly in fixed point.
> Many regression test files have progressions where the first and last
> point of a path now have a proper join where one did not exist before.
> pcl/pgdraw.c

2012-03-14 22:29:40 -0600
Henry Stiles <henry.stiles@artifex.com>
579e0e04b0d83d4364c9c4e42dcced8ca85fc634

> Remove obsolete bug list.
> tools/bug-list.txt

2012-04-20 14:58:18 +0100
Chris Liddell <chris.liddell@artifex.com>
b9350f4a92c1765d13afbff3e6a4576c33290d91

> Default to Windows UNICODE file names "off".
> Bring the PCL build in-line with Ghostscript so that the halding of UNICODE file names
> is disabled in the default build.
> As with Ghostscript, adding "USEUNICODE=1" to the nmake parameters will enable that code.
> CLUSTER_UNTESTED
> main/pcl6_msvc.mak

2012-04-20 07:20:16 +0100
Chris Liddell <Chris.Liddell@artifex.com>
67a924e4b93987d2c915a161ce67bdf9c1d6d4a5

> Bug 692962: fix endian issue with lcms2 i/face
> In the lcms2 interface code, am endian flag was being set on big endian
> platforms, and it shouldn't be.
> No cluster differences.
> gs/base/gsicc_lcms2.c

2012-04-19 14:27:57 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
d252b4f9d3a949778894a86bb71cc2206fce11cf

> Bug 692968: regenerate some appearances.
> Regenerate appearance streams when it is requested by the file
> and implemented in PDF interpreter. (NeedAppearances is set)
> Otherwise, continue to use appearance streams provided by the
> file.
> gs/Resource/Init/pdf_draw.ps

2012-04-17 10:39:30 +0100
Chris Liddell <chris.liddell@artifex.com>
2d76c9849ea165176dc836f926ba1604e8e85513

> Small change to djet500C device.
> Remove an optimisation that seems to cause issues with newer HP Deskjets.
> The device previously would determine how much (if any) of the right side
> of a given scanline was blank, and drop those samples - thus avoiding sending
> unmarked samples to the printer.
> On recent Deskjets, this resulted those unmarked samples printing black. We
> retain the similar optimisation for skipping entirely unmarked scanlines.
> No cluster differences.
> gs/base/gdevdjtc.c

2012-04-16 10:32:06 -0700
Ray Johnston <ray.johnston@artifex.com>
adb39bd6b16e20c7c6cf235518fc98ab242552e7

> Fix segfault caused by change in zcharx (34f32ee) seen with 11-13.PS.
> Under some error conditions, the 'penum' was not being set, and we would
> de-reference whatever (undefined) value was laying around. Initialize it
> to NULL and check before clearing pointers. I couldn't get this to fail
> in a debug or profile build -- only a release build.
> gs/psi/zcharx.c

2012-04-16 09:04:39 -0700
Ray Johnston <ray.johnston@artifex.com>
67894626809b89f813d3ed580210ee11da72af52

> Fix segfault in 12-13.PS CET. Yet another ref counted pointer not being cleared.
> gs/base/gscscie.c

2012-04-15 16:53:58 -0700
Ray Johnston <ray.johnston@artifex.com>
ffedf4d9c97b1f502e47bab7aed8ee2531c3de5c

> Fix ref counting of CIEBased 'params' during alloc_restore_all with 11-19.PS CET.
> The 'const' had to be broken to allow the pointer to be set to NULL when the object is freed
> due to reference count going to zero. Debug build showed an error message due to ref_count
> going below zero, but since this is referencing freed memory, can cause a segfault.
> gs/base/gscscie.c

2012-04-12 11:55:50 -0700
Ray Johnston <ray.johnston@artifex.com>
34f32ee8cb08590aeaaab23d1e14ee48c9932fb2

> Fix 692707. Clear pointers in text_enum when freeing the widths array.
> When an error occurred (as with the CET ILLEGAL test in 33_all.ps) the widths array would be freed,
> but the pointer in the gs_text_enum_t (text.x_widths, text.y_widths) was not cleared.
> gs/psi/zcharx.c

2012-04-14 12:52:51 +0000
Robin Watts <robin.watts@artifex.com>
fd34d1533bfef0ec2a12500ea8b9fe80249cb990

> bmpcmp: Flip psdcmyk images to be the right way up.
> gs/toolbin/bmpcmp.c

2012-04-13 19:36:36 +0000
Robin Watts <robin.watts@artifex.com>
365d6f549be4f8fd289adb06078d568ae37b108a

> Update bmpcmp to (at least try to) honour the color mapping for psd spots.
> We read the color info for the spots, and we try to apply it when mapping
> down to cmyk. It's entirely possible that the color information needs
> to be inverted or reordered or something, but I don't have anything
> that can display psd files to check.
> Talk to Michael about this when he returns. This is better than nothing.
> gs/toolbin/bmpcmp.c

2012-02-27 03:11:02 +0000
Robin Watts <robin.watts@artifex.com>
d1579963f90d1bfff7fa7e6e7a0417fa8be266b4

> Support HPGL style path handling.
> HPGL handles paths slightly differently to the postscript imaging model.
> When a path is filled, successive moveto's are treated as linetos.
> (i.e. the 'place we close the path to' is left at the first moveto,
> and the area remains fillable). Stroking is unaffected however.
> To model this in Ghostscript we add a new path segment type 's_gap'.
> The filling code treats this as a lineto. The stroking code is updated
> to not stroke such edges (and not to break the subpath at this point).
> We add a new parameter to the imager state (hpgl_path_mode), new
> accessor functions (gs_sethpglpathmode, gs_currenthpglpathmode),
> and new postscript operators (.sethpglpathmode and .currenthpglpathmode).
> If hpgl path mode is set to a non-zero value, then path construction
> treats movetos in an open subpath as gaptos.
> Currently this is disabled (see pcl/pctop.c for where it would be
> enabled) until we get the pcl interpreter to generate paths in
> exactly the right form.
> Still to do:
> * Update PDF write to spot such paths and to convert them as
> appropriate when writing out.
> gs/base/gdevpdfd.c
> gs/base/gdevtrac.c
> gs/base/gdevvec.c
> gs/base/gspath.c
> gs/base/gspath1.c
> gs/base/gspenum.h
> gs/base/gsstate.c
> gs/base/gsstate.h
> gs/base/gxclpath.c
> gs/base/gxclpath.h
> gs/base/gxclrast.c
> gs/base/gxcpath.c
> gs/base/gxistate.h
> gs/base/gxline.h
> gs/base/gxpath.c
> gs/base/gxpath.h
> gs/base/gxpath2.c
> gs/base/gxpcopy.c
> gs/base/gxpdash.c
> gs/base/gxstroke.c
> gs/base/gxttfb.c
> gs/base/gzpath.h
> gs/doc/Language.htm
> gs/psi/zgstate.c
> pcl/pctop.c

2012-04-13 18:51:34 +0000
Robin Watts <robin.watts@artifex.com>
34b74d7bb34390ad75ba8ca52b6bd5e94e85a51e

> bmpcmp: Another attempt to make cmyk + spots psdcmyk files work.
> Hopefully this should work; we now make the diff map, then
> convert down to cmyk (by dropping the spots), then convert
> cmyk -> rgb.
> Next step is to add the spots into the cmyk as we map down.
> gs/toolbin/bmpcmp.c

2012-04-13 18:34:00 +0100
Robin Watts <robin.watts@artifex.com>
42af17e78ebac4e31e4694d949ef5dfadeacb4fd

> Update bmpcmp so that it saves pngs from bpp > 32 psdcmyk images
> I'd forgotten to update the png saving code.
> gs/toolbin/bmpcmp.c

2012-04-12 16:41:59 -0600
Henry Stiles <henry.stiles@artifex.com>
35908068027eb9b7d2a6d1adaf371bc9fdeeb800

> Modified to not ignore error codes, no expected differences.
> gs/base/gxp1fill.c

2012-04-12 09:34:32 -0600
Henry Stiles <henry.stiles@artifex.com>
1b355f679fd03a5d5d334b6d74202d9c3d58110b

> Fix 692970 - device reference counting incorrect.
> The tile clipping device did not properly release its reference to the
> target device.
> gs/base/gxclip2.c
> gs/base/gxclip2.h
> gs/base/gxp1fill.c

2012-04-11 14:42:51 -0700
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
3769efbb709889aae39f905dd04b72a81bc37f3d

> Fix make clean for GhostPDL.
> common/ugcc_top.mak

2012-04-11 09:50:55 +0100
Robin Watts <robin.watts@artifex.com>
42c6f088344544b5e854899e4126e0d3ec4ee496

> Slight hack in gsmchunk.c for Memento builds.
> In Memento builds we nobble the chunk manager to only put a single
> block in each chunk. As such, the debugging is much nicer if we
> label the chunks with the block name rather than "chunk_mem_node_add".
> gs/base/gsmchunk.c

2012-04-10 18:04:39 +0100
Robin Watts <robin.watts@artifex.com>
ebc8452e68710ace66b3acca4d1701bfa6f59143

> Add Memento_label calls to gs_heap_alloc_bytes malloc calls.
> Should get us a lot more information in the debug output of
> Memento.
> gs/base/gsmalloc.c

2012-04-10 17:49:33 +0100
Robin Watts <robin.watts@artifex.com>
113beaf41ec17de71a57ffda7324442fe2000623

> Tidy up pattern accumulator device handling code.
> Hopefully slightly more comprehensible. Does the same job as before.
> gs/base/gxpcmap.c

2012-04-09 09:32:12 -0700
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
612f02c29f356c44ca72ec31eb6a64b65d7e7d04

> Print out message from bmpcmp.c if no differences detected.
> gs/toolbin/bmpcmp.c

2012-04-08 15:40:42 -0700
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
5e0dd327627f3c5dfe50f51ab583b5d696957972

> Prefaced bmpcmp.c error messages with 'bmpcmp:'.
> gs/toolbin/bmpcmp.c

2012-04-06 23:43:04 +0100
Robin Watts <robin.watts@artifex.com>
b5431c68e9c666e3c8010202e9501f101f6725d9

> Remove the need for seeking in bmpcmp when reading psdcmyk files.
> The cluster likes to drive bmpcmp from pipes.
> gs/toolbin/bmpcmp.c

2012-04-06 14:22:33 -0700
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
554b5c6088a1f53a648b5702a3245bdbba884ffa

> Fixed bmpcmp.c to properly set *cmyk in psd_read().
> gs/toolbin/bmpcmp.c

2012-04-06 16:53:07 +0100
Robin Watts <robin.watts@artifex.com>
20dcd26801be3d10bd5ebd596b50eaa3908050be

> Add psdcmyk support to bmpcmp.
> bmpcmp now reads psdcmyk files. It will read all n planes (cmyk +
> spots) and search in them for diffs. When it comes to output
> the differences are highlighted correctly in the diff image,
> but only the cmyk planes are used to create the output images
> (i.e. spots are not mapped down to cmyk currently).
> gs/toolbin/bmpcmp.c

2012-04-05 16:21:05 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
8e97d23a41580b3609a7b98dc90c4a59c6d093e8

> Bug 692967: drop incorrect filter parameters.
> Check for an empty array given as filter parameters and
> intrrpret it as no parameters.
> gs/Resource/Init/pdf_base.ps

2012-04-05 11:06:36 +0100
Ken Sharp <ken.sharp@artifex.com>
c3679722d0c3ade2f644bad1c5b7fafde8de5fb6

> Add the 32-bit Memento directories to .gitignore
> .gitignore

2012-04-02 17:47:41 +0100
Chris Liddell <chris.liddell@artifex.com>
6e7d591ae3b2dab7808406e6052a4b79b05f2633

> Fix a makefile typo....
> Back in an previous commit, I made a typo for the cross platform makefile
> variables - I used '_D_' instead of 'D_'
> No cluster differences.
> gs/base/lib.mak

2012-04-02 17:08:15 +0100
Chris Liddell <chris.liddell@artifex.com>
82eb1a659a96fcd834d0e673c7c8f36781499959

> Bug 692761: some errors reported by cppcheck
> Patch from Joshua Beck ( jxb091000@utdallas.edu ) addressing issues
> identified by cppcheck.
> No cluster differences.
> gs/base/genconf.c
> gs/base/gsiomacres.c
> gs/base/mkromfs.c
> gs/psi/dwmainc.c

2012-03-30 13:36:37 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
1ff339b6aca7087e32be7516fda9ef0b9df38e72

> Bug 692767: Render shading as a group.
> Render shading as an isolated group if the file has a soft mask.
> gs/Resource/Init/pdf_draw.ps

2012-03-30 11:59:14 +0100
Ken Sharp <ken.sharp@artifex.com>
8eb4118573d2d6959f8578a10f9d76ce9d802799

> PDF interpreter - preserve CIDSystemInfo in embedded CID fonts
> The PDF interpreter was not preserving the CIDSystemInfo from CIDFonts in
> PDF files (the TrueType code did not allow for this to be done)
> Updated the TrueType CIDFont building code to accept a CIDSystemInfo dictionary
> as a parameter, and teh PDF interpreter to pass it form the original
> CIDFont.
> No differences expected as this is not tested
> gs/Resource/Init/gs_ttf.ps
> gs/Resource/Init/pdf_font.ps

2012-03-29 08:50:13 -0700
Ray Johnston <ray.johnston@artifex.com>
67e3458154d8ef718be5a495aa64dc77c59393fe

> Fix bugs 692542 and 692706, bad rendering of copies after first page with NumRenderingThreads > 1
> The clist_get_band_from_thread logic would get confused as to the lookahead_direction if the
> requested thread was the first or last and the most recent previously rendered thread didn't
> match.
> gs/base/gxclthrd.c

2012-03-29 16:05:44 +0100
Ken Sharp <ken.sharp@artifex.com>
0604c2368ca3fd75be1c26ce6c7697cbce55968f

> Fix a minor compiler warning by casting a pointer.
> gs/base/gdevpdtt.c

2012-03-29 11:38:54 +0100
Ken Sharp <ken.sharp@artifex.com>
be6456331f4cff58f11f681450166fe2309e2ad5

> pdfwrite - when a Charstring is not found for a glyph use the /.notdef width instead of 0
> Bug #692944 the file uses an embedded font which does not include a /space
> glyph, but proceeds to use the space anyway. We were using a widht of 0 in
> this case but the file programmatically spaces glyphs to a predefined size.
> This was causing the PDF to be incorrectly spaced.
> We now use the width of the /.notdef glyph instead for sizing calculations,
> since this si the glyph which will eventually be used.
> This exhibits a small difference in 30-06.ps but since this is testing
> missing glyphs in a QL test file, I'm going to accept it as a difference in
> order to improve the result with files of this type.
> gs/base/gdevpdte.c
> gs/base/gdevpdtt.c

2012-03-29 02:23:20 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
23e8552bb2c1849c118d9f5d81f5629ebe436acb

> Bug 692886: use sequential page numbers in PDF collections.
> Use sequential page numbering for -dFirstPage and -dLastPage parameters
> when they are used with PDF Collections.
> gs/Resource/Init/pdf_main.ps
> gs/doc/Use.htm

2012-03-28 13:52:27 -0700
Ray Johnston <ray.johnston@artifex.com>
aa9f730f07f8d471c222956e6a532ab2698ef58e

> Fix bug 692688: pdf14_copy_alpha did not move the source data pointer when adjusting for y<rect.p.y
> The pdf14_copy_alpha doesn't use the 'fit_copy' macro since that macro has specific variables
> embedded, but the when the 'h' and 'y' are adjusted, the source data pointer needs to move to
> the first line that will be used.
> gs/base/gdevp14.c

2012-03-28 17:03:25 +0100
Chris Liddell <chris.liddell@artifex.com>
a1075141f25f7bf38bf372f9ccc65dfd9c0c8baa

> Bug 692950: further revise falling back to unhinted rendering.
> In the FAPI/FT interface, we caught some errors from Freetype to do with the
> byte code hinting in TrueType fonts - when they occur we retry the glyph
> rendering with hinting disabled.
> This commit expands that to *any* error from the byte code interpreter will
> now cause us to retry unhinted.
> (the core problem in this case seems to be scale depending operations in the
> font program, which is supposed not to be permitted).
> No cluster differences.
> gs/psi/fapi_ft.c

2012-03-27 19:29:56 -0700
Ray Johnston <ray.johnston@artifex.com>
5b50a46f4ed3e54fec6727a1ad52258e5d32b0a9

> Add -sBandListStorage={file|memory} option and default to no bitmap compression if file clist.
> Also alphabetize the clist options and remove the arbitrary 10000 minimum for MaxBitmap
> (now -dMaxBitmap=0 is legal). The change to not compress bitmaps (using CCITT) when going
> to disk based clist improves performance.
> gs/base/gdevprn.c
> gs/base/gdevprn.h
> gs/base/gxclbits.c
> gs/base/gxclist.c
> gs/base/lib.mak
> gs/doc/Language.htm

2012-03-26 18:57:48 +0100
Chris Liddell <chris.liddell@artifex.com>
6a13e642324435d92f2f79f6c28b5f25758a249c

> Ensure FAPI uses appropriate glyph name for metrics.
> Found investigating a customer 532 report: Ghostscript "augments" glyph names
> under certain circumstances, and depending on the font type, FAPI may have to
> remove that augmentation (mainly when disc based fonts are being used).
> FAPI was then using the un-augmented glyph name to read the glyph metrics,
> which caused the wrong metrics to be used because the metrics(s) dictionary was
> created with the augmented glyph name in place.
> Causes a difference in the cluster file Bug691031.pdf - this is
> progression.
> gs/psi/zfapi.c

2012-03-26 14:44:05 +0100
Chris Liddell <chris.liddell@artifex.com>
9ca16b047d2ee4dc862aa18465c80c2250c213c5

> Bug 692938: fix link error on AIX
> AIX 5.x (probably others) don't have memalign, so update the conditions
> under which openjpeg will (try to) use memalign to exclude AIX systems.
> No cluster differences.
> gs/openjpeg/libopenjpeg/opj_malloc.h

2012-03-22 15:08:43 +0000
Ken Sharp <ken.sharp@artifex.com>
701b769786f6e2b036df8427c17c6a5dc294a672

> pdfwrite - update CIDSet emission for PDF/A-2 compatibility
> This completes the work for creation of PDF/A-2 files. Note that Acrobat X
> preflight complains about the CIDSet we include in PDF/A-2 files. However I
> believe that the current code is correct, and that the Acrobat preflight is
> incorrect. The PDF-Tools validator is completely happy with our CIDSet.
> I'm unable to fathom what it is the Acrobat preflight tool wants. The old
> PDF/A-1 CIDSet is flagged as invalid, as is every premutation of values I
> can think of.
> In the absence of any example file to look at, or a definitive resource on
> the subject, I'm comitting this and concluding the development. I will of
> course be happy to work on the CIDSet emission if someone can bring more
> information.
> No differences expected PDF/A is not tested by the cluster.
> gs/base/gdevpdtd.c

2012-03-21 09:36:40 -0600
Henry Stiles <henry.stiles@artifex.com>
b68ee69570803001a959721209fff6a2e4430f84

> Improves 692527 - the missing characters now print and the prototype
> svg device now works with many more files.
> Before this change very few jobs would work, the color state wasn't
> updated properly.
> CLUSTER_UNTESTED
> gs/base/gdevsvg.c

2012-03-21 14:22:35 +0000
Chris Liddell <chris.liddell@artifex.com>
8031fd574e3949cf1e17eed0372034e522580dca

> Bug 692850: FAPI: clamp fixed-point overflows instead of error.
> This job ends up with an insanely big scale factor when trying rendering glyphs
> from a font. Obviously that ends up too big to render to a bitmap in the
> font renderer, so we build a path instead.
> Previously, during FAPI path extraction, if the coordinates overflowed what we
> can represent in our fixed point representation, give a rangecheck error. But
> the AFS code seems to clamp the coordinate to something we can represent, and
> carry on.
> Do the same in FAPI.
> No cluster differences.
> gs/psi/zfapi.c

2012-03-15 11:51:23 +0000
Chris Liddell <chris.liddell@artifex.com>
0c0f193bc6673fd4c6c257fd8c6fe740882c6023

> Another Freetype fix.
> From:
> http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=b43e0f44
> gs/freetype/src/type1/t1load.c

2012-03-14 14:49:19 +0000
Chris Liddell <chris.liddell@artifex.com>
eb20f1cf128936c871e1ccb8161db382e866336a

> Backport incremental interface fix from FT git.
> http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=9a55cb
> CLUSTER_UNTESTED
> gs/freetype/src/type1/t1load.c

2012-03-14 14:48:31 +0000
Chris Liddell <chris.liddell@artifex.com>
078d7ccbeb5250c93b758c6566d368c11c1da986

> Update to Freetype 2.4.9
> CLUSTER_UNTESTED
> gs/freetype/ChangeLog
> gs/freetype/Jamfile
> gs/freetype/README
> gs/freetype/autogen.sh
> gs/freetype/builds/amiga/makefile
> gs/freetype/builds/amiga/makefile.os4
> gs/freetype/builds/amiga/smakefile
> gs/freetype/builds/amiga/src/base/ftsystem.c
> gs/freetype/builds/mac/FreeType.m68k_cfm.make.txt
> gs/freetype/builds/mac/FreeType.m68k_far.make.txt
> gs/freetype/builds/mac/FreeType.ppc_carbon.make.txt
> gs/freetype/builds/mac/FreeType.ppc_classic.make.txt
> gs/freetype/builds/mac/ftmac.c
> gs/freetype/builds/symbian/bld.inf
> gs/freetype/builds/symbian/freetype.mmp
> gs/freetype/builds/toplevel.mk
> gs/freetype/builds/unix/.gitignore
> gs/freetype/builds/unix/aclocal.m4
> gs/freetype/builds/unix/config.guess
> gs/freetype/builds/unix/config.sub
> gs/freetype/builds/unix/configure
> gs/freetype/builds/unix/configure.ac
> gs/freetype/builds/unix/configure.raw
> gs/freetype/builds/unix/detect.mk
> gs/freetype/builds/unix/freetype-config.in
> gs/freetype/builds/unix/freetype2.in
> gs/freetype/builds/unix/ftconfig.in
> gs/freetype/builds/unix/install-sh
> gs/freetype/builds/unix/ltmain.sh
> gs/freetype/builds/vms/ftconfig.h
> gs/freetype/builds/vms/ftsystem.c
> gs/freetype/builds/win32/vc2005/freetype.vcproj
> gs/freetype/builds/win32/vc2005/index.html
> gs/freetype/builds/win32/vc2008/freetype.vcproj
> gs/freetype/builds/win32/vc2008/index.html
> gs/freetype/builds/win32/vc2010/freetype.sln
> gs/freetype/builds/win32/vc2010/freetype.vcxproj
> gs/freetype/builds/win32/vc2010/freetype.vcxproj.filters
> gs/freetype/builds/win32/vc2010/index.html
> gs/freetype/builds/win32/visualc/freetype.dsp
> gs/freetype/builds/win32/visualc/freetype.vcproj
> gs/freetype/builds/win32/visualc/index.html
> gs/freetype/builds/win32/visualce/freetype.dsp
> gs/freetype/builds/win32/visualce/freetype.vcproj
> gs/freetype/builds/win32/visualce/index.html
> gs/freetype/builds/wince/vc2005-ce/freetype.vcproj
> gs/freetype/builds/wince/vc2005-ce/index.html
> gs/freetype/builds/wince/vc2008-ce/freetype.vcproj
> gs/freetype/builds/wince/vc2008-ce/index.html
> gs/freetype/configure
> gs/freetype/devel/ftoption.h
> gs/freetype/docs/CHANGES
> gs/freetype/docs/GPL.TXT
> gs/freetype/docs/GPLv2.TXT
> gs/freetype/docs/INSTALL
> gs/freetype/docs/INSTALL.ANY
> gs/freetype/docs/INSTALL.UNIX
> gs/freetype/docs/LICENSE.TXT
> gs/freetype/docs/PROBLEMS
> gs/freetype/docs/UPGRADE.UNIX
> gs/freetype/docs/VERSION.DLL
> gs/freetype/docs/formats.txt
> gs/freetype/docs/reference/.gitignore
> gs/freetype/docs/reference/ft2-base_interface.html
> gs/freetype/docs/reference/ft2-basic_types.html
> gs/freetype/docs/reference/ft2-bdf_fonts.html
> gs/freetype/docs/reference/ft2-bitmap_handling.html
> gs/freetype/docs/reference/ft2-bzip2.html
> gs/freetype/docs/reference/ft2-cache_subsystem.html
> gs/freetype/docs/reference/ft2-cid_fonts.html
> gs/freetype/docs/reference/ft2-computations.html
> gs/freetype/docs/reference/ft2-font_formats.html
> gs/freetype/docs/reference/ft2-gasp_table.html
> gs/freetype/docs/reference/ft2-glyph_management.html
> gs/freetype/docs/reference/ft2-glyph_stroker.html
> gs/freetype/docs/reference/ft2-glyph_variants.html
> gs/freetype/docs/reference/ft2-gx_validation.html
> gs/freetype/docs/reference/ft2-gzip.html
> gs/freetype/docs/reference/ft2-header_file_macros.html
> gs/freetype/docs/reference/ft2-incremental.html
> gs/freetype/docs/reference/ft2-index.html
> gs/freetype/docs/reference/ft2-lcd_filtering.html
> gs/freetype/docs/reference/ft2-list_processing.html
> gs/freetype/docs/reference/ft2-lzw.html
> gs/freetype/docs/reference/ft2-mac_specific.html
> gs/freetype/docs/reference/ft2-module_management.html
> gs/freetype/docs/reference/ft2-multiple_masters.html
> gs/freetype/docs/reference/ft2-ot_validation.html
> gs/freetype/docs/reference/ft2-outline_processing.html
> gs/freetype/docs/reference/ft2-pfr_fonts.html
> gs/freetype/docs/reference/ft2-quick_advance.html
> gs/freetype/docs/reference/ft2-raster.html
> gs/freetype/docs/reference/ft2-sfnt_names.html
> gs/freetype/docs/reference/ft2-sizes_management.html
> gs/freetype/docs/reference/ft2-system_interface.html
> gs/freetype/docs/reference/ft2-toc.html
> gs/freetype/docs/reference/ft2-truetype_engine.html
> gs/freetype/docs/reference/ft2-truetype_tables.html
> gs/freetype/docs/reference/ft2-type1_tables.html
> gs/freetype/docs/reference/ft2-user_allocation.html
> gs/freetype/docs/reference/ft2-version.html
> gs/freetype/docs/reference/ft2-winfnt_fonts.html
> gs/freetype/docs/release
> gs/freetype/include/freetype/config/ftconfig.h
> gs/freetype/include/freetype/config/ftheader.h
> gs/freetype/include/freetype/config/ftoption.h
> gs/freetype/include/freetype/config/ftstdlib.h
> gs/freetype/include/freetype/freetype.h
> gs/freetype/include/freetype/ftbbox.h
> gs/freetype/include/freetype/ftbzip2.h
> gs/freetype/include/freetype/ftcache.h
> gs/freetype/include/freetype/ftchapters.h
> gs/freetype/include/freetype/fterrdef.h
> gs/freetype/include/freetype/fterrors.h
> gs/freetype/include/freetype/ftgasp.h
> gs/freetype/include/freetype/ftglyph.h
> gs/freetype/include/freetype/ftmoderr.h
> gs/freetype/include/freetype/ftoutln.h
> gs/freetype/include/freetype/ftrender.h
> gs/freetype/include/freetype/ftstroke.h
> gs/freetype/include/freetype/fttypes.h
> gs/freetype/include/freetype/internal/autohint.h
> gs/freetype/include/freetype/internal/ftdriver.h
> gs/freetype/include/freetype/internal/ftobjs.h
> gs/freetype/include/freetype/internal/ftpic.h
> gs/freetype/include/freetype/internal/ftrfork.h
> gs/freetype/include/freetype/internal/ftserv.h
> gs/freetype/include/freetype/internal/ftstream.h
> gs/freetype/include/freetype/internal/fttrace.h
> gs/freetype/include/freetype/internal/pcftypes.h
> gs/freetype/include/freetype/internal/pshints.h
> gs/freetype/include/freetype/internal/services/svbdf.h
> gs/freetype/include/freetype/internal/services/svcid.h
> gs/freetype/include/freetype/internal/services/svgldict.h
> gs/freetype/include/freetype/internal/services/svmm.h
> gs/freetype/include/freetype/internal/services/svpostnm.h
> gs/freetype/include/freetype/internal/services/svpscmap.h
> gs/freetype/include/freetype/internal/services/svpsinfo.h
> gs/freetype/include/freetype/internal/services/svsfnt.h
> gs/freetype/include/freetype/internal/services/svttcmap.h
> gs/freetype/include/freetype/internal/services/svttglyf.h
> gs/freetype/include/freetype/internal/sfnt.h
> gs/freetype/include/freetype/internal/t1types.h
> gs/freetype/include/freetype/internal/tttypes.h
> gs/freetype/include/freetype/t1tables.h
> gs/freetype/include/freetype/tttables.h
> gs/freetype/modules.cfg
> gs/freetype/objs/.gitignore
> gs/freetype/src/autofit/afangles.c
> gs/freetype/src/autofit/afcjk.c
> gs/freetype/src/autofit/afcjk.h
> gs/freetype/src/autofit/afdummy.c
> gs/freetype/src/autofit/afdummy.h
> gs/freetype/src/autofit/aferrors.h
> gs/freetype/src/autofit/afglobal.c
> gs/freetype/src/autofit/afglobal.h
> gs/freetype/src/autofit/afhints.c
> gs/freetype/src/autofit/afhints.h
> gs/freetype/src/autofit/afindic.c
> gs/freetype/src/autofit/aflatin.c
> gs/freetype/src/autofit/aflatin.h
> gs/freetype/src/autofit/aflatin2.c
> gs/freetype/src/autofit/afloader.c
> gs/freetype/src/autofit/afloader.h
> gs/freetype/src/autofit/afmodule.c
> gs/freetype/src/autofit/afpic.c
> gs/freetype/src/autofit/afpic.h
> gs/freetype/src/autofit/aftypes.h
> gs/freetype/src/autofit/afwarp.c
> gs/freetype/src/autofit/autofit.c
> gs/freetype/src/autofit/rules.mk
> gs/freetype/src/base/basepic.c
> gs/freetype/src/base/basepic.h
> gs/freetype/src/base/ftadvanc.c
> gs/freetype/src/base/ftbase.c
> gs/freetype/src/base/ftbase.h
> gs/freetype/src/base/ftbitmap.c
> gs/freetype/src/base/ftcalc.c
> gs/freetype/src/base/ftdbgmem.c
> gs/freetype/src/base/ftglyph.c
> gs/freetype/src/base/ftinit.c
> gs/freetype/src/base/ftmac.c
> gs/freetype/src/base/ftobjs.c
> gs/freetype/src/base/ftoutln.c
> gs/freetype/src/base/ftpatent.c
> gs/freetype/src/base/ftpic.c
> gs/freetype/src/base/ftrfork.c
> gs/freetype/src/base/ftstream.c
> gs/freetype/src/base/ftstroke.c
> gs/freetype/src/base/ftsystem.c
> gs/freetype/src/base/fttype1.c
> gs/freetype/src/bdf/README
> gs/freetype/src/bdf/bdf.h
> gs/freetype/src/bdf/bdfdrivr.c
> gs/freetype/src/bdf/bdfdrivr.h
> gs/freetype/src/bdf/bdferror.h
> gs/freetype/src/bdf/bdflib.c
> gs/freetype/src/bzip2/Jamfile
> gs/freetype/src/bzip2/ftbzip2.c
> gs/freetype/src/bzip2/rules.mk
> gs/freetype/src/cache/ftcbasic.c
> gs/freetype/src/cache/ftccache.c
> gs/freetype/src/cache/ftccache.h
> gs/freetype/src/cache/ftccback.h
> gs/freetype/src/cache/ftccmap.c
> gs/freetype/src/cache/ftcerror.h
> gs/freetype/src/cache/ftcglyph.c
> gs/freetype/src/cache/ftcglyph.h
> gs/freetype/src/cache/ftcmanag.c
> gs/freetype/src/cache/ftcmanag.h
> gs/freetype/src/cache/ftcmru.c
> gs/freetype/src/cache/ftcsbits.c
> gs/freetype/src/cache/ftcsbits.h
> gs/freetype/src/cff/cffdrivr.c
> gs/freetype/src/cff/cfferrs.h
> gs/freetype/src/cff/cffgload.c
> gs/freetype/src/cff/cffload.c
> gs/freetype/src/cff/cffload.h
> gs/freetype/src/cff/cffobjs.c
> gs/freetype/src/cff/cffparse.c
> gs/freetype/src/cff/cffparse.h
> gs/freetype/src/cff/cffpic.c
> gs/freetype/src/cff/cffpic.h
> gs/freetype/src/cff/cfftoken.h
> gs/freetype/src/cff/cfftypes.h
> gs/freetype/src/cff/rules.mk
> gs/freetype/src/cid/ciderrs.h
> gs/freetype/src/cid/cidgload.c
> gs/freetype/src/cid/cidload.c
> gs/freetype/src/cid/cidobjs.c
> gs/freetype/src/cid/cidparse.c
> gs/freetype/src/cid/cidriver.c
> gs/freetype/src/cid/cidriver.h
> gs/freetype/src/gxvalid/gxvcommn.c
> gs/freetype/src/gxvalid/gxvcommn.h
> gs/freetype/src/gxvalid/gxverror.h
> gs/freetype/src/gxvalid/gxvfeat.c
> gs/freetype/src/gxvalid/gxvjust.c
> gs/freetype/src/gxvalid/gxvkern.c
> gs/freetype/src/gxvalid/gxvmod.c
> gs/freetype/src/gxvalid/gxvmod.h
> gs/freetype/src/gxvalid/gxvmort.c
> gs/freetype/src/gxvalid/gxvmort0.c
> gs/freetype/src/gxvalid/gxvmort1.c
> gs/freetype/src/gxvalid/gxvmort2.c
> gs/freetype/src/gxvalid/gxvmort5.c
> gs/freetype/src/gxvalid/gxvmorx.c
> gs/freetype/src/gxvalid/gxvmorx0.c
> gs/freetype/src/gxvalid/gxvmorx1.c
> gs/freetype/src/gxvalid/gxvmorx2.c
> gs/freetype/src/gxvalid/gxvmorx5.c
> gs/freetype/src/gxvalid/gxvprop.c
> gs/freetype/src/gxvalid/gxvtrak.c
> gs/freetype/src/gzip/ftgzip.c
> gs/freetype/src/lzw/ftlzw.c
> gs/freetype/src/lzw/ftzopen.c
> gs/freetype/src/otvalid/otverror.h
> gs/freetype/src/otvalid/otvmod.c
> gs/freetype/src/otvalid/otvmod.h
> gs/freetype/src/pcf/README
> gs/freetype/src/pcf/pcf.h
> gs/freetype/src/pcf/pcfdrivr.c
> gs/freetype/src/pcf/pcfdrivr.h
> gs/freetype/src/pcf/pcferror.h
> gs/freetype/src/pcf/pcfread.c
> gs/freetype/src/pfr/pfrdrivr.c
> gs/freetype/src/pfr/pfrdrivr.h
> gs/freetype/src/pfr/pfrerror.h
> gs/freetype/src/pfr/pfrload.c
> gs/freetype/src/pfr/pfrobjs.c
> gs/freetype/src/psaux/afmparse.c
> gs/freetype/src/psaux/psauxerr.h
> gs/freetype/src/psaux/psauxmod.c
> gs/freetype/src/psaux/psauxmod.h
> gs/freetype/src/psaux/psconv.c
> gs/freetype/src/psaux/psobjs.c
> gs/freetype/src/psaux/t1cmap.c
> gs/freetype/src/psaux/t1decode.c
> gs/freetype/src/pshinter/pshnterr.h
> gs/freetype/src/pshinter/pshpic.c
> gs/freetype/src/pshinter/pshpic.h
> gs/freetype/src/pshinter/rules.mk
> gs/freetype/src/psnames/psmodule.c
> gs/freetype/src/psnames/psnamerr.h
> gs/freetype/src/psnames/pspic.c
> gs/freetype/src/psnames/pspic.h
> gs/freetype/src/psnames/pstables.h
> gs/freetype/src/psnames/rules.mk
> gs/freetype/src/raster/ftraster.c
> gs/freetype/src/raster/ftrend1.c
> gs/freetype/src/raster/rasterrs.h
> gs/freetype/src/raster/rastpic.c
> gs/freetype/src/raster/rastpic.h
> gs/freetype/src/raster/rules.mk
> gs/freetype/src/sfnt/rules.mk
> gs/freetype/src/sfnt/sfdriver.c
> gs/freetype/src/sfnt/sferrors.h
> gs/freetype/src/sfnt/sfntpic.c
> gs/freetype/src/sfnt/sfntpic.h
> gs/freetype/src/sfnt/sfobjs.c
> gs/freetype/src/sfnt/ttcmap.c
> gs/freetype/src/sfnt/ttcmap.h
> gs/freetype/src/sfnt/ttload.c
> gs/freetype/src/sfnt/ttmtx.c
> gs/freetype/src/sfnt/ttsbit.c
> gs/freetype/src/smooth/ftgrays.c
> gs/freetype/src/smooth/ftsmerrs.h
> gs/freetype/src/smooth/ftsmooth.c
> gs/freetype/src/smooth/ftspic.c
> gs/freetype/src/smooth/ftspic.h
> gs/freetype/src/smooth/rules.mk
> gs/freetype/src/tools/apinames.c
> gs/freetype/src/tools/docmaker/.gitignore
> gs/freetype/src/tools/glnames.py
> gs/freetype/src/truetype/rules.mk
> gs/freetype/src/truetype/ttdriver.c
> gs/freetype/src/truetype/tterrors.h
> gs/freetype/src/truetype/ttgload.c
> gs/freetype/src/truetype/ttgload.h
> gs/freetype/src/truetype/ttgxvar.c
> gs/freetype/src/truetype/ttinterp.c
> gs/freetype/src/truetype/ttinterp.h
> gs/freetype/src/truetype/ttobjs.c
> gs/freetype/src/truetype/ttobjs.h
> gs/freetype/src/truetype/ttpic.c
> gs/freetype/src/truetype/ttpic.h
> gs/freetype/src/truetype/ttpload.c
> gs/freetype/src/type1/t1afm.c
> gs/freetype/src/type1/t1driver.c
> gs/freetype/src/type1/t1driver.h
> gs/freetype/src/type1/t1errors.h
> gs/freetype/src/type1/t1gload.c
> gs/freetype/src/type1/t1gload.h
> gs/freetype/src/type1/t1load.c
> gs/freetype/src/type1/t1objs.c
> gs/freetype/src/type1/t1objs.h
> gs/freetype/src/type1/t1parse.c
> gs/freetype/src/type1/t1tokens.h
> gs/freetype/src/type42/t42drivr.c
> gs/freetype/src/type42/t42drivr.h
> gs/freetype/src/type42/t42error.h
> gs/freetype/src/type42/t42objs.c
> gs/freetype/src/type42/t42objs.h
> gs/freetype/src/type42/t42parse.c
> gs/freetype/src/winfonts/fnterrs.h
> gs/freetype/src/winfonts/winfnt.c
> gs/freetype/src/winfonts/winfnt.h

2012-03-20 16:56:36 -0600
Henry Stiles <henry.stiles@artifex.com>
dcf401ee8172aaff5363b2fc86e166f73225e429

> Close the device before exiting PCL, XPS and friends.
> The languages deallocated the memory associated with a device but
> never did the associated gs_closedevice(). This might have some
> effect on 692816 where indeterminate output was observed on stdout.
> Without the close device call the "OutputFile" was never actually
> closed (fclose), and so there might have been a missing flush. All of
> that is speculation, I wasn't able to reproduce the indeterminism -
> but we want the closedevice anyway so here it is.
> pl/plmain.c

2012-03-20 11:35:04 -0700
Ray Johnston <ray.johnston@artifex.com>
731707a165665554577d3779fdeb93eb49ab2a52

> Fix Visual Studio PROFILE=1 builds so that Instrumented performance analyzer works.
> We were missing the /PROFILE linker option.
> gs/psi/msvc.mak

2012-03-19 18:02:47 +0000
Chris Liddell <chris.liddell@artifex.com>
a2371ed3ee29b5470dd892b78249d64d8f4466f4

> Clean up warnings.
> Clean up a couple of warnings I introduced in:
> f63237e1bb9a85124349ec0d0eae58737d7cb5ee
> No cluster differences expected.
> gs/base/gxccache.c
> gs/base/lib.mak

2012-03-19 10:06:10 +0000
Ken Sharp <ken.sharp@artifex.com>
d6f83dfa81a2073c3d1f67a30aee7e8407e4685a

> ps2write - work-around bugs in Brother printer CCITTFaxDecode filter
> Raised on irc by Till Kamppeter, see Ubuntu bug :
> https://bugs.launchpad.net/ubuntu/+source/cups/+bug/955553
> After much work by Chris Liddell and Bruce Stough it transpires that at
> least some Brother printers have a bug in their CCITTFaxDecode filter,
> especially with small amounts of data.
> Since the ps2write otuput for bitmapped glyhs (which is required when the
> input is a CIDFont) always uses the CCITTFax filter, this led to corrupted
> output from the Brother (Note this is a bug in the *printer* not ps2write)
> This patch adds a new command line parameter 'NoT3CCITT' which disables
> compression of bitmapped glyphs. It should only be used with printers which
> have a problem with CCITTFax data, and in that case should also be used with
> the EncodeMonoImages switch to disable compression of monochrome images. Eg:
> -dNoT3CCITT -dEncodeMonoImages=false
> No differences expected as these are not tested by our regression tests
> gs/base/gdevpdfb.c
> gs/base/gdevpdfb.h
> gs/base/gdevpdfp.c
> gs/base/gdevpdfx.h

2012-03-18 22:34:39 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
1c558e93a7f63b470880ea44fbf883c61de4b13a

> Bug 692589: Copy CIDSystemInfo from PDF to CMap
> Collect CIDSystemInfo attributes from PDF CMap dictionary and copy
> them to the embedded CMap resource.
> gs/Resource/Init/pdf_font.ps

2012-03-16 14:25:06 -0600
Henry Stiles <henry.stiles@artifex.com>
2cd895c6ad8e4e1ace368d04a783bf0cccb30f3c

> Fixes Bug 692931 - Regression: seg fault
> The ICC parameters were set when the interpreter was allocated before
> the the command line options were actually set, resulting in a crash.
> xps/xpstop.c

2012-03-16 09:35:53 +0000
Ken Sharp <ken.sharp@artifex.com>
25b6a2cdeb5a90bb7803958f2bf15b618fbcf120

> pdfwrite - cure memory leaks caused by 'aside' streams
> When writing an object it can happen that pdfwrite needs to write another
> object (Eg a ToUnicode CMap in a font), it does this with an 'aside' which
> opens a Ghostscritp stream to contain the data.
> The code to do this uses low level access to the stream code, but it did
> not previously correctly free the memory used by the stream and its associated
> buffer leading to memory leaks.
> By closing the entire stream when we close the filters we get the stream and
> all its memory freed, so we do that here to cure the memory leak.
> Inspecting the four other cases in the pdfwrite code they appear to be OK.
> No differences expected.
> gs/base/gdevpdti.c

2012-03-16 00:51:54 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
ca6e4653abdc2921e44f416633b7d5e4bc5f4382

> Add indexed color space support to the ICC extraction tool.
> Recognize ICC color spaces referenced by indexed color spaces and
> process them the same way as stand-alone ICC color spaces.
> gs/toolbin/extractICCprofiles.ps

2012-03-15 12:07:51 -0700
Michael Vrhel <michael.vrhel@artifex.com>
044b6ca010ecb8f264fcd4b3515051c037659967

> Fix for broken setting of Default ICC profiles
> A recent change http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=d6f504174bd51d22cc43b2f87bee8c275c004cc1
> broke the ability to set the profiles. Previously there was a check in gsicc_set_profile to
> avoid reseting the profiles. Once removed, the call from gsicc_init_manager was always blowing
> away any non default settings for the defaults. A check was added into gsicc_init_manager to
> avoid this.
> gs/base/gsicc_manage.c

2012-03-15 09:58:51 -0700
Michael Vrhel <michael.vrhel@artifex.com>
72fe9304f98beff3c97347d6e402bb812136de49

> Fix for memory issue in icc user params
> The icc user parameters where improperly being set as being persistent
> for the user params list when they were not. In the case when we are
> using the output intent profile, one of the default profiles is freed
> and replaced by the output intent profile. In this case, the default
> profile contained the string that was used for the user params. During
> a VMreclaim, we would then go and restore the user params and
> unfortunately this default one had been freed.
> gs/base/gsicc_manage.c

2012-03-14 09:15:36 -0700
Michael Vrhel <michael.vrhel@artifex.com>
82d1d263a13ccfe64e78cd0e6f1cf1a275adcb9c

> Update of Use.htm to include description of -dUsePDFX3Profile
> gs/doc/Use.htm

2012-03-02 10:52:19 -0800
Michael Vrhel <michael.vrhel@artifex.com>
1d8c46688c07cec9e58f492223d1a9c92f4374e4

> Output Intent Implementation Part 2
> The interpreter part of the output intent plus fixes in the c code.
> Thanks to Alex for his help on this.
> gs/Resource/Init/pdf_draw.ps
> gs/Resource/Init/pdf_main.ps
> gs/base/gsicc_manage.c
> gs/psi/zicc.c

2012-03-13 22:45:00 -0700
Michael Vrhel <michael.vrhel@artifex.com>
0eae84aaf7a1c27f077d4aff3050ae48bb5a6aaa

> Fix for broken tiff devices due to use of huge signed number in overflow test
> 0xFFFFFFFF is used in a calculation to see how close we are to the 4G limit in
> a tiff file. Problem was this was cast as a long which, in a 32 bit
> system ends up being -1.
> gs/base/gdevtsep.c

2012-03-13 10:13:06 -0700
Ray Johnston <ray.johnston@artifex.com>
aa131f2321abe0e65415242a4563fbf3fba005fa

> Make -dPDFA backwards compatible, equivalent to -dPDFA=1
> As of commit d0371d9 the actual device parameter was changed to be an int.
> This change detects if it is defined as a boolean and sets it to 1 if so.
> gs/Resource/Init/gs_init.ps

2012-03-13 09:37:15 +0000
Ken Sharp <ken.sharp@artifex.com>
d21eb36fda00dcfefc2e65c2202cb0536562385d

> pdfwrite - correction to PDF/A processing
> The previous commit for PDF/A prcoessing did not properly check the PDF/A
> level in the PostScript handlers, and treated any setting as being PDF/A.
> In fact only settings greater than 0 shuold be checked, 0 means 'not PDF/A'
> Add code in gdev_pdf_put_params to ensure that PDFA has a permitted value
> (0->2) and signal rangecheck if not.
> No differences expected.
> gs/Resource/Init/gs_cspace.ps
> gs/Resource/Init/gs_pdfwr.ps
> gs/base/gdevpdfp.c

2012-03-13 09:20:59 +0000
Ken Sharp <ken.sharp@artifex.com>
d0371d915bae6b3d52487d49e470b0e560837ab2

> pdfwrite - first pass at PDF/A-2 output
> This is the first part of making it possible to produce PDF/A-2b output from
> pdfwrite.
> The PDFA switch has changed from a boolean to an integer, where the value gives
> the level of PDF/A compatibility. This has knock-on effects throughout the
> C and PostScript code which has been revised to expect an integer instead
> of boolean value.
> When PDFA has the value 2 we no longer flatten transparency, and we write
> '2' in the pdfaid field in the XMP metadata.
> PDF/A-1b output still seems to work correctly, but it is unlikely that the
> work so far is sufficient for correct PDF/A-2 output.
> No differences expected as the cluster does not test PDF/A output.
> gs/Resource/Init/gs_cspace.ps
> gs/Resource/Init/gs_pdfwr.ps
> gs/base/gdevpdfb.c
> gs/base/gdevpdfc.c
> gs/base/gdevpdfe.c
> gs/base/gdevpdfg.c
> gs/base/gdevpdfj.c
> gs/base/gdevpdfm.c
> gs/base/gdevpdfo.c
> gs/base/gdevpdfp.c
> gs/base/gdevpdfu.c
> gs/base/gdevpdfx.h
> gs/base/gdevpdtb.c
> gs/base/gdevpdtd.c
> gs/base/gdevpdte.c
> gs/base/gdevpdtf.c
> gs/base/gdevpdti.c
> gs/base/gdevpdtt.c
> gs/base/gdevpdtw.c
> gs/doc/Ps2pdf.htm

2012-03-12 21:57:09 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
bdcf6ae7c1dab92c48715982ae804211dc558a78

> Bug 692851: Implement the case of bps < 8 for Luratech JPX decoder
> Implement a missing case of Luratech JPX with components > 1, and
> bps < 8. Also fix incorrect bit shift calculation in OpenJpeg
> part.
> gs/base/sjpx_luratech.c
> gs/base/sjpx_openjpeg.c

2012-03-10 00:15:41 +0000
Robin Watts <robin.watts@artifex.com>
5352d4cf5b3fd17a22b4a126fe5d5fdceb0ad7b6

> Revert "Support HPGL style path handling. (Work in progress)"
> This reverts commit 93bf2df8f6a6b2ed60a8c3f5037865b8646243db.
> gs/base/gdevpdfd.c
> gs/base/gdevtrac.c
> gs/base/gdevvec.c
> gs/base/gspath.c
> gs/base/gspath1.c
> gs/base/gspenum.h
> gs/base/gsstate.c
> gs/base/gsstate.h
> gs/base/gxclpath.c
> gs/base/gxcpath.c
> gs/base/gxistate.h
> gs/base/gxline.h
> gs/base/gxpath.c
> gs/base/gxpath.h
> gs/base/gxpath2.c
> gs/base/gxpcopy.c
> gs/base/gxpdash.c
> gs/base/gxstroke.c
> gs/base/gxttfb.c
> gs/base/gzpath.h
> gs/psi/zgstate.c

2012-03-09 15:31:50 -0800
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
b89c0e35a15e3a786da346d3cd63d0c558a9fb6a

> Hack to fix memento.c build problem on Mac OS X.
> gs/base/memento.c

2012-03-09 13:53:55 -0800
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
dc98b15546522ce28edad3f129f1ae8e05300a34

> Change compression of the tiffsep device composite output to match the separations.
> Previous to this commit the tiffsep device would always write out
> an uncompressed composite file; the separation files were lzw
> compressed by default and this could be changed via the -sCompression=
> option. Now the compression of the composite file is the same as
> that of the separation files.
> Fixes Bug 692907.
> gs/base/gdevtsep.c
> gs/doc/Devices.htm

2012-02-27 03:11:02 +0000
Robin Watts <robin.watts@artifex.com>
93bf2df8f6a6b2ed60a8c3f5037865b8646243db

> Support HPGL style path handling. (Work in progress)
> HPGL handles paths slightly differently to the postscript imaging model.
> When a path is filled, successive moveto's are treated as linetos.
> (i.e. the 'place we close the path to' is left at the first moveto,
> and the area remains fillable). Stroking is unaffected however.
> To model this in Ghostscript we add a new path segment type 's_gap'.
> The filling code treats this as a lineto. The stroking code is updated
> to not stroke such edges (and not to break the subpath at this point).
> We add a new parameter to the imager state (hpgl_fill_mode), new
> accessor functions (gs_sethpglfillmode, gs_currenthpglfillmode),
> and new postscript operators (.sethpglfillmode and .currenthpglfillmode).
> If hpgl fill mode is set to a non-zero value, then path construction
> treats movetos in an open subpath as gaptos.
> Still to do:
> * Double check the output from this code matches HPGL.
> * Update the clist code to send hpgl fill mode changes.
> * Update PDF write to spot such paths and to convert them as
> appropriate when writing out.
> gs/base/gdevpdfd.c
> gs/base/gdevtrac.c
> gs/base/gdevvec.c
> gs/base/gspath.c
> gs/base/gspath1.c
> gs/base/gspenum.h
> gs/base/gsstate.c
> gs/base/gsstate.h
> gs/base/gxclpath.c
> gs/base/gxcpath.c
> gs/base/gxistate.h
> gs/base/gxline.h
> gs/base/gxpath.c
> gs/base/gxpath.h
> gs/base/gxpath2.c
> gs/base/gxpcopy.c
> gs/base/gxpdash.c
> gs/base/gxstroke.c
> gs/base/gxttfb.c
> gs/base/gzpath.h
> gs/psi/zgstate.c

2012-03-09 17:58:13 +0000
Robin Watts <robin.watts@artifex.com>
91b362b05a16c4d74f9309d92fa7387899fed53a

> Fix typo in last commit that stopped Memento builds working.
> Committed before VS had saved out. Sorry.
> CLUSTER_UNTESTED.
> gs/base/memento.c

2012-03-09 16:57:13 +0000
Robin Watts <robin.watts@artifex.com>
c66ce76a0c6f8edb075f28ffe1e8f326cc9eb40c

> Updated Memento pulled in from mupdf. Plus nesting fixes.
> Bring in Memento from MuPDF (where it has had some more tweaks
> added). Fix the nested display code. Add hack to ignore prev/next
> pointers in chunk blocks.
> CLUSTER_UNTESTED.
> gs/base/memento.c
> gs/base/memento.h

2012-03-09 14:47:43 +0000
Robin Watts <robin.watts@artifex.com>
75bc089fe804d692d8ac86a6f19be807980084f3

> Fix Memento GhostPDL builds to actually build Memento on windows.
> Windows makefiles were failing to pass the MEMENTO flag down due
> to some makefile wackiness.
> CLUSTER_UNTESTED.
> common/msvc_top.mak
> gs/base/msvclib.mak

2012-03-09 10:41:29 +0000
Ken Sharp <ken.sharp@artifex.com>
7629dfecfafa5b3fc82b3767a786b732a0b17645

> colour handling - ensure ink names are maintained in the name table while in use
> Bug #692884 "Empty Spotcolor Name in generated PDF"
> The ink name wasn't being marked as 'in use' by the colour space structure
> and so was being freed by a garbage collection, resulting in an empty name.
> Robin Watts supplied this patch which allows us to *much* more easily mark
> names as in use, and also kindly updated the colour handling as well.
> No differences expected.
> gs/base/gscdevn.c
> gs/base/gscsepr.c
> gs/base/gslib.c
> gs/base/gsstruct.h
> gs/psi/igc.c
> pl/plplatf.c

2012-03-07 17:56:47 -0700
Henry Stiles <henry.stiles@artifex.com>
e76a4d070d7d6d90cc7d09849108bca806a9b253

> Change the icc user parameter operators to use the graphics state not
> the imager state.
> gs/base/gsicc_manage.c
> gs/base/gsicc_manage.h
> gs/psi/zusparam.c

2012-03-07 17:43:07 +0000
Robin Watts <robin.watts@artifex.com>
ff83bab4ddf49c5bbbce9a37cfa8e4d5c42c9009

> Add MEMENTO to preprocessor definition list in the VS solution.
> No difference to builds, but may make intellisense work better
> for Memento builds.
> gs/ghostscript.vcproj
> win32/language_switch.vcproj
> win32/pcl.vcproj
> win32/svg.vcproj
> win32/xps.vcproj

2012-03-07 17:41:32 +0000
Robin Watts <robin.watts@artifex.com>
b47dc4f294e2b267d139001c6c749603e6ba2570

> Tweak rm.bat (and hence fix 'clean' builds on windows)
> Cope with -r command. Add /Q flag to erase call (so it doesn't prompt
> before deleting).
> gs/base/rm.bat

2012-03-07 17:13:35 +0000
Chris Liddell <chris.liddell@artifex.com>
f63237e1bb9a85124349ec0d0eae58737d7cb5ee

> Problems with glyphs, T1 patterns and transparecy.....
> From investigations of a problem reported by customer 532.
> When imaging a cached glyph, if the glyph bitmap cannot be inserted into the
> clist tile cache, we'd normally resort to degenerating the glyph bitmap into
> rectangles, and writing those to the clist. When the glyph is filled with a
> tiling (Type 1) pattern, this means going through the pattern tiling code.
> The problem is when transparency is involved (i.e. if the pattern is in a trans
> group, or contains a transparency group) the tiling code cannot reliably
> degerate to rectangles at this stage. This usually just works due to the various
> fallbacks in the clist writing code and the glyph imaging code, but
> occasionally glyphs can either disappear, or other problems occur.
> This change makes us use that "fallback" route for all glyphs when we're
> filling a glyph with a type 1 pattern, with transprency involved and we're
> writing to a clist device.
> NOTE: this is analogous to what the FAPI does in similar circumstances for
> uncached glyphs.
> No cluster differences.
> gs/base/gsptype1.c
> gs/base/gsptype1.h
> gs/base/gxccache.c

2012-03-06 09:06:55 -0800
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
23e37b6fc4d79741007cc18d770bb3e449e53014

> Fix the checks in gdevtsep.c missed by commit e954dd4683c35dbd66de3e045d979ebbf20c4d72
> Henry pointed out that my e954dd4683c35dbd66de3e045d979ebbf20c4d72
> fix was incomplete; this commit replaces the remaining max_long
> references with 2^32-1.
> gs/base/gdevtsep.c

2012-03-01 13:47:18 -0700
Henry Stiles <henry.stiles@artifex.com>
0611ef428368816b4f123003df98263e674eab5a

> Add command line parsing for icc user parameters.
> pcl/pctop.c
> pl/plmain.c
> pl/plmain.h
> pl/pltop.h
> pxl/pxtop.c
> xps/xpstop.c

2012-03-05 19:21:53 -0800
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
e954dd4683c35dbd66de3e045d979ebbf20c4d72

> Fix detection of TIFF file size overflow in tiffsep.
> The TIFF spec limits files to 4 Gigs. The code to detect attempts
> to write files that were larger than this in gdevtsep.c was broken
> on systems were a long != 32 bit.
> Fixes Bug 692896.
> gs/base/gdevtsep.c

2012-02-29 12:55:19 -0800
Michael Vrhel <michael.vrhel@artifex.com>
d6f504174bd51d22cc43b2f87bee8c275c004cc1

> User params reset issue of icc profile strings
> If the user params end up getting set during a vmreclaim
> while we are in a swapped icc profile situation when
> processing a softmask we were ending up freeing profiles
> that should not have been freed. This issue was masked
> by a check that was disallowing profiling settings in
> the manager once they were already set. Also discovered
> issues with a corner case where we have a softmask that
> includes a pattern with a softmask.
> gs/base/gdevp14.c
> gs/base/gscms.h
> gs/base/gsicc_manage.c

2012-03-03 16:41:59 -0700
Henry Stiles <henry.stiles@artifex.com>
32463b4fe74f855e39be7b5eb74d8be444fffae3

> Fix 692893 gl/2 rectangles not properly placed.
> When resetting the hpgl/2 page parameters we were setting scaling to
> its default value overriding any setting in the PCL job. HP does not
> reset the scaling as might be expected.
> pcl/pginit.c

2012-03-03 11:03:53 -0700
Henry Stiles <henry.stiles@artifex.com>
0c98813be9c1a24bbcf9ca0c1d4127cb4aa4209f

> Fixes bug 692894, orientation of pcl pages incorrect.
> This is a case of the current code emulating undocumented behavior
> incorrectly. It appears the HP printers resets the print direction
> upon receiving a new page size command. Previously we tried to emulate
> this by not resetting the logical page orientation which is incorrect
> but happened to print the tests we had correctly.
> pcl/pcpage.c
> pcl/pcstate.h

2012-02-17 13:51:23 -0700
Henry Stiles <henry.stiles@artifex.com>
9d10c339014b9e554116ef55c697f50109071bb2

> Better error handling in the absence of fonts.
> pcl/pcfsel.c
> pcl/pctext.c

2012-03-02 22:34:20 -0800
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
7180b9328f00fb5df41e6d019e16f70ae4f66ec7

> Clean up of distclean target in Makefile.
> Improve the distclean target so that the Memento obj and bin directory
> contents are deleted and also remove the debug, pg, memento, and
> production obj and bin directories.
> gs/base/Makefile.in
> gs/base/gs.mak
> gs/base/unix-dll.mak

2012-03-02 11:50:41 +0000
Chris Liddell <chris.liddell@artifex.com>
ceef3232c1fce21f65d4ba43bb54eaf678389bfd

> Bug 692891: don't hack the libjpeg mem manager....
> When linking with a shared libjpeg library, don't include the non-public
> libjpeg API hack to replace it's low level memory manager with Ghostscript's.
> But still do so when using our "local" libjpeg source.
> No cluster differences.
> gs/base/sjpegc.c

2012-03-02 11:41:21 +0000
Chris Liddell <chris.liddell@artifex.com>
aa3a2bb36828d07c2b71ff0a37f784d8e6fb0f5a

> Fix the "WHICH_CMS" setting.....
> ...so it uses the $(D_) and $(_D_) variables instead of -D directly.
> No cluster differences.
> gs/base/lib.mak

2012-03-01 11:06:54 +0000
Ken Sharp <ken.sharp@artifex.com>
2a57a68efe18dd4f7898b180400a95d7baccfbc2

> pdfwrite - Improve handling of PCL downloaded TrueType fonts
> Bug #692629. PCL TrueType fonts are missing some important tables for the
> purposes of pdfwrite. In particular the CMAP table, which makes it impossible
> to create glyph names.
> This causes an error which *should* have resulted in pdfwrite falling back to
> bitmaps. In the case of a single glyph, or a string where the fiirst glyph fails,
> this did work correctly, but when one or more initial glyphs did work, the
> calling code did not expect an error from TrueType fonts and failed to cope
> properly by continuing to process the remaining glyphs.
> Added TrueType fonts to the list which may error in this fashion.
> Expected Differences:
> AS40AOJ3.BIN
> LW97DOJ2.BIN
> SW108OJ2.BIN
> VerdanaItalic.prn
> bug689100.xl
> bug689905.xl
> All exhibit significant progressions (text was previously missing)
> gs/base/gdevpdtt.c

2012-03-01 07:43:13 +0000
Chris Liddell <chris.liddell@artifex.com>
867fb8607edd04b0b1c8e8bd635347a542b0f50f

> Bug 692602: revise script vs job confusion
> Slight revision to the previous change, again from jrnieder@gmail.com.
> CLUSTER_UNTESTED
> gs/man/gs.1

2012-02-29 16:46:33 +0000
Chris Liddell <chris.liddell@artifex.com>
90e6a864f0e4b4b0e6d6a0a1258295cf1cb3e1a6

> Bug 692602: revise SAFER section in the man page
> patch courtesy of Jonathan Nieder ( jrnieder@gmail.com ).
> CLUSTER_UNTESTED
> gs/man/gs.1

2012-02-29 11:20:50 +0000
Robin Watts <robin.watts@artifex.com>
3648acb1e3fd3e07faceedde1a71e1b282e25de3

> Revert "Support HPGL style path handling."
> This reverts commit 43f3cdae4bdf00c09fdd69c53c03fb99d0b4aca1.
> This caused unexpected changes in many postscript files. Reverting
> until I can figure out why.
> gs/base/gdevpdfd.c
> gs/base/gdevtrac.c
> gs/base/gdevvec.c
> gs/base/gspath.c
> gs/base/gspath1.c
> gs/base/gspenum.h
> gs/base/gsstate.c
> gs/base/gsstate.h
> gs/base/gxclpath.c
> gs/base/gxclpath.h
> gs/base/gxclrast.c
> gs/base/gxcpath.c
> gs/base/gxistate.h
> gs/base/gxline.h
> gs/base/gxpath.c
> gs/base/gxpath.h
> gs/base/gxpath2.c
> gs/base/gxpcopy.c
> gs/base/gxpdash.c
> gs/base/gxstroke.c
> gs/base/gxttfb.c
> gs/base/gzpath.h
> gs/doc/Language.htm
> gs/psi/zgstate.c

2012-02-29 08:31:44 +0000
Ken Sharp <ken.sharp@artifex.com>
34b2e8fd2c33a7fc349b0c51046c3d0c99b74d0c

> pdfwrite - Fix XMP ModDate metaData
> The XMP metadata Modification date was being written using the Creation
> date instead of the Modification date.
> No differences expected, metadata is not checked by regression tests
> gs/base/gdevpdfe.c

2012-02-28 12:01:12 -0800
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
8e228753bde054e549c8643cf726c951a512a4a6

> Another fix to fuzzy.c dealing with different sized input files.
> gs/toolbin/tests/fuzzy.c

2012-02-27 03:11:02 +0000
Robin Watts <robin.watts@artifex.com>
43f3cdae4bdf00c09fdd69c53c03fb99d0b4aca1

> Support HPGL style path handling.
> HPGL handles paths slightly differently to the postscript imaging model.
> When a path is filled, successive moveto's are treated as linetos.
> (i.e. the 'place we close the path to' is left at the first moveto,
> and the area remains fillable). Stroking is unaffected however.
> To model this in Ghostscript we add a new path segment type 's_gap'.
> The filling code treats this as a lineto. The stroking code is updated
> to not stroke such edges (and not to break the subpath at this point).
> We add a new parameter to the imager state (hpgl_path_mode), new
> accessor functions (gs_sethpglpathmode, gs_currenthpglpathmode),
> and new postscript operators (.sethpglpathmode and .currenthpglpathmode).
> If hpgl path mode is set to a non-zero value, then path construction
> treats movetos in an open subpath as gaptos.
> Still to do:
> * Update PDF write to spot such paths and to convert them as
> appropriate when writing out.
> gs/base/gdevpdfd.c
> gs/base/gdevtrac.c
> gs/base/gdevvec.c
> gs/base/gspath.c
> gs/base/gspath1.c
> gs/base/gspenum.h
> gs/base/gsstate.c
> gs/base/gsstate.h
> gs/base/gxclpath.c
> gs/base/gxclpath.h
> gs/base/gxclrast.c
> gs/base/gxcpath.c
> gs/base/gxistate.h
> gs/base/gxline.h
> gs/base/gxpath.c
> gs/base/gxpath.h
> gs/base/gxpath2.c
> gs/base/gxpcopy.c
> gs/base/gxpdash.c
> gs/base/gxstroke.c
> gs/base/gxttfb.c
> gs/base/gzpath.h
> gs/doc/Language.htm
> gs/psi/zgstate.c

2012-02-24 22:37:26 -0800
Michael Vrhel <michael.vrhel@artifex.com>
0d095e8511ec1469b0ef4cb741d1fba9363570e7

> Movement of code for setting ICC system/user params into graphics lib.
> The code that set the system/user params related to ICC profiles was
> contained in the zusparam.c file. This file is not used with the
> other languages (e.g. xps and pcl). The functions that do the actual
> work have been moved to gsicc_manage reducing any code duplication for
> the other languages.
> gs/base/gsicc_manage.c
> gs/base/gsicc_manage.h
> gs/psi/zusparam.c

2012-02-25 14:54:03 -0500
Alex Cherepanov <alex.cherepanov@artifex.com>
6d93192f3469bedb51f73abc0a1f8f71d3bfba24

> Bug 692878: Convert Type 4 image with invalid mask to Type 1
> Improve the revision 3de55841eefb38c751772ac767c5abab155d7d91.
> Convert Type 4 images with invalid /Mask attribute to Type 1
> images. Previous version used the mask [1 0] in such cases,
> which was not compatible with pdfwrite.
> gs/Resource/Init/pdf_draw.ps

2012-02-25 15:07:08 +0000
unknown <ken@.(none)>
7d97d5dcfcfb580177566b0f03d75048485683ac

> Bug #692880 Correct the initial Windows display device flags for PCL
> The flags used for the Windows display device were incorrect and caused
> at least some rasterops not to display correctly.
> No expetced differences, the display device, and Windows builds, are not
> cluster tested.
> pl/dwmainc.c

2012-02-24 21:25:08 -0500
Alex Cherepanov <alex.cherepanov@artifex.com>
b9971445d1460a3b0c57b176c73d722ed6db99e1

> Add "-I directories" option.
> Add a new form of -I option similar to -o, where the directory list
> is taken from the next parameter. This form is more convenient to use
> on UN*X command line with tilda expansion.
> gs/doc/Use.htm
> gs/psi/imainarg.c

2012-02-24 20:45:31 -0500
Alex Cherepanov <alex.cherepanov@artifex.com>
9178d875547dafe5f89ae7bbbe9f4fd83e18000c

> Bug 692867: ignore PDF path operators without current point
> Run l, c, v, y in a stopped context. When they fail (presumably
> with /nocurrentpoint), ignore the operator and continue.
> gs/Resource/Init/pdf_draw.ps

2012-02-21 11:30:58 -0800
Michael Vrhel <michael.vrhel@artifex.com>
2c4aa5f1a90ee03aacce58f24b819cab3bdd1625

> Fix for bug 692865. Make XPS interpreter use ICC color spaces for default
> The XPS interpreter was still using Device color spaces for its default
> color spaces. This fix has it use ICC color spaces by default which
> is required by the spec. This revealed an issue with the color space
> handling of the opacity masks. These were getting drawn in sRGB color
> space but the transparency group is linear gray. Since we are drawing
> the opacity mask as a luminosity mask that is gray we ended up
> mapping through a nonlinearity.
> gs/base/gscspace.c
> gs/base/gscspace.h
> gs/base/gxblend.c
> xps/ghostxps.h
> xps/xpsgradient.c
> xps/xpsimage.c
> xps/xpsopacity.c
> xps/xpspage.c
> xps/xpstop.c

2012-02-24 18:39:09 -0500
Alex Cherepanov <alex.cherepanov@artifex.com>
77a8045048a4aaa727f700187816170d7fbd072c

> Bug 692832: Drop setcachedevice calls with large arguments.
> Reject setcachedevice arguments that are too big and, probably, invalid.
> The threshold, 32000, is arbitrary. Normal fonts have the values about 1000.
> gs/base/gxchar.c

2012-02-24 18:27:41 -0500
Alex Cherepanov <alex.cherepanov@artifex.com>
9aedcfcd26aea249e0a06061f4d2e579fa5cdffc

> Bug 692859: Add Portfolio support to pdf_info.ps
> Enumerate PDF subfiles in PDF collection (=portfolio) and apply
> the old pdf_info.ps to every component.
> gs/toolbin/pdf_info.ps

2012-02-23 01:25:59 -0500
Alex Cherepanov <alex.cherepanov@artifex.com>
3de55841eefb38c751772ac767c5abab155d7d91

> Bug 692851: Fix OpenJpeg JPX with components > 1, and bps < 8
> Fix packing of multi-component color values with bps < 8 into the
> output stream. This results in progressions on Bug691843.pdf, and
> minor differences in Bug690147.pdf
> gs/base/sjpx_openjpeg.c

2012-02-22 09:40:31 -0800
Michael Vrhel <michael.vrhel@artifex.com>
b105c3678ff3c22ab65995953b4599d8c5c37a7e

> Typo fix in non color managed transform
> Thanks to Peter Skarpetis for finding this.
> gs/base/gxblend1.c

2012-02-22 11:27:16 -0500
Alex Cherepanov <alex.cherepanov@artifex.com>
b4a8edb730e25f5c03103a2bb687e223a440d990

> Bug 692852: Broken /Mask in 1 bpc /Indexed images
> Following AR9 implementation, add special processing for
> repairing a broken /Mask attribute of 1 bpc indexed images.
> Ignore the whole Mask if its first element is out of range.
> Replace the second component with 1 when it's out of range.
> gs/Resource/Init/pdf_draw.ps

2012-02-20 06:23:06 -0800
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
ed07da9075aa82bc0c4335228cc9c934e6efdb45

> Revert 2e807ab6d4eecfce43561b9e8d5b66386a5165ee and fix fuzzy.c correctly.
> gs/toolbin/tests/fuzzy.c

2012-02-19 15:45:43 -0800
Ray Johnston <ray.johnston@artifex.com>
e277c5e8d76325f56259a4f930caa166a594cfc0

> Improve image performance by rotating Width 1 images to Height 1.
> The image code makes a call to 'image_render' for each line of the Height. This defeats the joining
> of any same color pixels into a larger rectangle and also creates extra overhead. Problem analyzed
> with profiles from cust 532 file "PWTTQ1CC.pdf". Regression testing shows some single pixel differences
> presumably due to rounding, but no obvious problems.
> gs/psi/zimage.c

2012-02-18 09:28:14 -0800
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
2e807ab6d4eecfce43561b9e8d5b66386a5165ee

> Make fuzzy not lock up when comparing images of different sizes.
> gs/toolbin/tests/fuzzy.c

2012-02-16 20:03:26 +0000
Robin Watts <robin.watts@artifex.com>
d00354a21670d16f00c96228591b3d8213d6a590

> Fix interpolation of indexed colorspaces.
> WMB1102317A01.pdf (supplied by a customer) shows a problem with
> Interpolation of Index colorspaces.
> Specifically, we have an Indexed DeviceGrey space (which is, in
> the new world order, an Indexed ICC space, with 1 component).
> At line 678 of gxiscale.c we correctly detect that pcs->type->index
> is Indexed, and therefore use the base space as the 'actual' space.
> At line 683 we find the concrete space (which in this case is
> exactly the same space). We then decide whether we are working in
> an icc world, or a device_color world by checking for the presence
> of icc data. The old code used to (incorrectly) check pcs (the
> indexed space), when it should really have checked the concrete
> space.
> The remaining changes in the code are purely tidying:
> * avoid calling concrete_space a second time (when pconcs already
> holds the answer)
> * pass pconcs as an arg when calling pconcs->type->remap_concrete_color
> rather than pactual_cs. At that point pactual_cs and pconcs must
> be identical, but it's nicer to be consistent.
> This produces 3 differences in the cluster tests, all in the cups
> tests. These can be reproduced locally using tiffsep.
> comparefiles/148-11.ps.cups.300.1
> Definite progression
> PDFIA1.7_SUBSET/CATX1028.pdf.cups.300.1
> Looks like progression to me
> ps/ps3cet/12-07B.PS.cups.300.1
> Definite progressions on page 12-15. A problem still exists on
> page 12 though, but that's unaffected by this change.
> gs/base/gxiscale.c

2012-02-16 18:16:16 +0000
Robin Watts <robin.watts@artifex.com>
21579b00e53b97cd655f164bb92c5280c586e365

> Output helpful debug warning when tif output would be too large.
> Currently we just raise a rangecheck, which can be very confusing.
> CLUSTER_UNTESTED.
> gs/base/gdevtsep.c

2012-02-15 19:03:56 +0000
Robin Watts <robin.watts@artifex.com>
43b14b24fcc13d816dd41ca335d52cd3074bd0d8

> Update garbage collection to cope with pdf14_compressed_color_list.
> A second list of compressed colors was recently added to the
> gdevn_params structure, but this wasn't added to the garbage
> collection routines. Fixed here.
> gs/base/gdevp14.c
> gs/base/gdevpsd.c
> gs/base/gdevtsep.c

2012-02-15 19:02:34 +0000
Robin Watts <robin.watts@artifex.com>
d375ea1908bfe1770b108a6c7d1e7cdbe38b99f2

> Fix Division by Zero in interpolated scaler.
> If we find we are scaling an image to be zero width or
> height, handle the image without interpolation.
> gs/base/gxiscale.c

2012-02-14 18:11:15 -0700
Henry Stiles <henry.stiles@artifex.com>
0a0aa751d8cb5d49052a0c4ed3ae38ad66b9fb8e

> Fix 692857, wrong current unit initialization in HPGL/2-RTL.
> The code was actually written fixed once correcly but then was broken
> with a bad fix (5ad194f) largely because we didn't have good bookkeeping
> for the original fix. Hopefully now that we have an associated bug
> report and test file a similar problem won't happen again.
> pcl/pcjob.c

2012-02-14 14:57:07 +0000
Robin Watts <robin.watts@artifex.com>
00a96d35b30d77f8dfbc8ae12326c81053fc50c9

> Fix Bug 692854; tweak gdev_prn color procs.
> A previous commit (cf37ea5) changed the prn device macros to
> duplicate map_color_rgb/map_rgb_color to encode/decode_color.
> I thought this was safe as the default color encoding/decoding
> functions were actually implemented as encode/decode, rather
> than map_ variants.
> Unfortunately, this falls down when other devices (such as the
> tiffscaled ones) provide genuine map_ functions rather than
> encode/decodes.
> So, a small tweak to the macros is required; we now duplicate
> to encode/decode only if specifically told to - and the macros
> that use the defaults specifically say to. Other devices should
> remain unchanged.
> gs/base/gdevprn.h

2012-02-13 08:46:29 -0800
Michael Vrhel <michael.vrhel@artifex.com>
ba2a8e63783227033506688bebccf664b2b922c7

> C portion for making use of output intent ICC profile.
> This commit puts into place the c-code for making use of an
> ICC profile stream from the PDF interpreter for setting of the
> output intent. This is done through the use of zset_outputintent.
> This function will make the various settings of the icc profiles
> in the device and in the icc manager based upon the process model
> of the target device and the icc profile of the output intent. It
> will be up to the interpreter to make the call to .set_outputintent
> with the proper output intent ICCBased dictionary on the top of the
> stack. This should be done in the interpreter after the device has
> been set up and all the default ICC profiles are in place. The
> interpreter should make the call if we have specified -dUsePDFX3Profile.
> The first output intent that is present in the file should be used,
> unless someone specifies a different intent through the use of
> –dOutputIntent=x . In this case, the x+1 output intent (if it
> exists) will be used. Note that if the particular output intent does
> not include an ICC profile entry (DestOutputProfile), then the output
> intent will not be used. In this case, we will eventually want to
> specify what the OutputConditionIdentifier was for that particular
> intent if it was missing the DestOutputProfile.
> gs/base/gdevpdfk.c
> gs/base/gscms.h
> gs/base/gsequivc.c
> gs/base/gsicc_manage.c
> gs/base/gsicc_manage.h
> gs/psi/int.mak
> gs/psi/zicc.c

2012-02-12 21:14:34 -0700
Henry Stiles <henry.stiles@artifex.com>
7aa3debb84673b38d805aa6de1afce60f0d6c6ab

> Improve character fills, bug #692849.
> The unusual loops inside the characters (graphic 3 and 8 center of
> page) were caused by trying to edge stick and arc fonts which aren't
> outlines but paths (stroked fonts).
> pcl/pgdraw.c
> pcl/pglabel.c
> pcl/pgmisc.h

2012-02-10 18:13:00 -0700
Henry Stiles <henry.stiles@artifex.com>
bcdb21c092a4a788d7252cc1b560aa427743a197

> Improvements for bug 692849.
> Better emulation of HP printers in the absence of a requested pattern.
> pcl/pcl.mak
> pcl/pglfill.c

2012-02-10 11:29:16 -0700
Henry Stiles <henry.stiles@artifex.com>
a81f5d7f83271e2e3e0fb28ad32c9fb337c8553a

> Bug 692849, missing green filled boxes fixed.
> The green boxes for fill type 22 (user defined) were missing because
> the download pattern command was disabled in HPGL-2/RTL mode.
> pcl/pcuptrn.c

2012-02-09 17:24:34 -0700
Henry Stiles <henry.stiles@artifex.com>
1bf302eec20ce9b543aee523b441dd7adc677cc0

> Remove relic data files used by the wts device.
> CMYK.icc
> Makefile
> link.icc
> sRGB.icc
> wts_dump_0
> wts_plane_0
> wts_plane_1
> wts_plane_2
> wts_plane_3

2012-02-09 17:15:41 -0700
Henry Stiles <henry.stiles@artifex.com>
e2867c6bcb2dc6cf9325e9ac87f980684469dee4

> PCL shared library build for unix.
> Makefile
> common/ugcc_top.mak
> main/pcl6_gcc.mak

2012-02-10 17:24:00 +0000
Robin Watts <robin.watts@artifex.com>
a13600f1c241c3e36dbe4973e9d78a8934b16004

> Further clipping optimisations.
> When clipping the region to be used for an image plot, reduce the
> rectangle by the outer box of the clipping path before checking to
> see if a clip is needed or not.
> This enables us to avoid a clipping device in more cases.
> gs/base/gxclip.c

2012-02-10 17:20:36 +0000
Robin Watts <robin.watts@artifex.com>
cf37ea5d017193c76341aafd60e35d3b1826046f

> Prn device changes to encode/decode_color.
> At the moment, prn devices do not implement encode_decode/color,
> choosing instead to provide map_rgb_color/map_color_rgb which
> just get called through a 'backwards compatibility' layer.
> In fact, they actually implement encode/decode_rgb rather than
> map_rgb_color/map_color_rgb, so we just copy the entries here.
> No changes expected in cluster.
> gs/base/gdevprn.h

2012-02-09 00:00:31 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
082c31b99fd38ebb1a9bc678d06ac9791db2e222

> Bug 690974: This patch from Gorac implements the generic refinement region
> decoding procedure for when TPGRON is TRUE.
> gs/jbig2dec/jbig2_refinement.c

2012-02-08 23:13:13 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
8b150573a88276849b32b359030fc195786d2be8

> Bug 690870: This patch prevents the image compositing occurring if the src
> is outside of the clip region.
> gs/jbig2dec/jbig2_image.c

2012-02-08 09:50:34 -0800
Michael Vrhel <michael.vrhel@artifex.com>
059dfa8389ff1dde2bb35237b12f72c6fd62da9b

> Fix for bug 682719. Fix bad icc profiles in examples/annots.pdf
> The ICC profiles in annots.pdf were missing all sorts of required information in
> the header.
> gs/examples/annots.pdf

2012-02-08 08:40:12 +0000
Chris Liddell <chris.liddell@artifex.com>
a2390c3b6be80d1147f1ef60c16c70d75033a475

> Amend date and update changelog for 9.05 release.
> CLUSTER_UNTESTED
> gs/base/version.mak
> gs/doc/API.htm
> gs/doc/C-style.htm
> gs/doc/Commprod.htm
> gs/doc/DLL.htm
> gs/doc/Deprecated.htm
> gs/doc/Details8.htm
> gs/doc/Details9.htm
> gs/doc/Develop.htm
> gs/doc/Devices.htm
> gs/doc/Drivers.htm
> gs/doc/Fonts.htm
> gs/doc/Helpers.htm
> gs/doc/History1.htm
> gs/doc/History2.htm
> gs/doc/History3.htm
> gs/doc/History4.htm
> gs/doc/History5.htm
> gs/doc/History6.htm
> gs/doc/History7.htm
> gs/doc/History8.htm
> gs/doc/History9.htm
> gs/doc/Install.htm
> gs/doc/Issues.htm
> gs/doc/Language.htm
> gs/doc/Lib.htm
> gs/doc/Make.htm
> gs/doc/News.htm
> gs/doc/Projects.htm
> gs/doc/Ps-style.htm
> gs/doc/Ps2epsi.htm
> gs/doc/Ps2pdf.htm
> gs/doc/Ps2ps2.htm
> gs/doc/Psfiles.htm
> gs/doc/Readme.htm
> gs/doc/Release.htm
> gs/doc/Source.htm
> gs/doc/Unix-lpr.htm
> gs/doc/Use.htm
> gs/doc/WhatIsGS.htm
> gs/doc/Xfonts.htm
> gs/doc/gs-vms.hlp
> gs/doc/thirdparty.htm
> gs/man/dvipdf.1
> gs/man/font2c.1
> gs/man/gs.1
> gs/man/gslp.1
> gs/man/gsnd.1
> gs/man/pdf2dsc.1
> gs/man/pdf2ps.1
> gs/man/pdfopt.1
> gs/man/pf2afm.1
> gs/man/pfbtopfa.1
> gs/man/printafm.1
> gs/man/ps2ascii.1
> gs/man/ps2epsi.1
> gs/man/ps2pdf.1
> gs/man/ps2pdfwr.1
> gs/man/ps2ps.1
> gs/man/wftopfa.1

2012-02-01 10:59:52 +0000
Chris Liddell <chris.liddell@artifex.com>
eed3745432f9bce3e20d9b634d78d1a72dbbf040

> Update docs for 9.05 release candidate.
> CLUSTER_UNTESTED
> gs/doc/History9.htm

2012-02-08 15:01:57 +0000
Ken Sharp <ken.sharp@artifex.com>
0816e3b87ec1843a31e3075a4fa382e844a46158

> Bug #688227 Alter the PostScript 'show' operators so that the show enumerator is in local VM
> As described in the bug, it seems to be technically possible for a local font to be
> referenced from a show enumerator. If the enumerator is in global VM this
> causes a garbage collector crash.
> This code modifies the PostScript 'show' family of operators so that the
> enumerator is always allocated from local VM, avoiding the problem.
> There is no specimen or method of reproduction supplied in the bug report so
> this is rather speculative, however it runs a cluster test without problem.
> If it does cause any problems we should simply revert this change.
> As part of this change it was noticed that there are a number of procedures
> defined in gschar.c which are apparently dead code and these have been removed.
> No expected differences.
> gs/base/gschar.c
> gs/base/gschar.h
> gs/psi/zchar.c
> gs/psi/zcharx.c

2012-02-07 09:23:30 +0000
Ken Sharp <ken.sharp@artifex.com>
a6a7d7b62d5bb5cbe00c1051d8a9cb749e43fe86

> pdfwrite - fallback to 'LeaveColorunchanged' if we cannot deal with color conversion
> Some of the PDFSETTINGS collection of settings set the ColorConversionStrategy
> to spaces which may not be possible (in the current architecture) to convert
> every colour space into. For example ICCBased spaces. This causes a fairly
> incomprehensible error to be thrown.
> In future we intend to do a better job with colour taking advantage of the
> built-in colour management, but for now we simply choose to change the
> ColorConversionStrategy to 'LeaveColorUnchanged' and emit a warning.
> Bug #692030 and Bug #692108
> No Expected Differences as this is not tested by the cluster
> gs/base/gdevpdfc.c

2012-02-06 12:01:53 +0000
Robin Watts <robin.watts@artifex.com>
e448aeaf3d3d572bf4e91d9acdf3fa623ed9b6fb

> Clipping optimisations; avoid needless clipping device.
> When filling a mask, check any clipping path given; if it trivially
> includes all the mask, then don't bother creating a clipping
> device. If it trivially excludes, then don't bother plotting at all.
> If the bbox partially covers the area, then reduce the area
> of the mask.
> This gives a 6-8% speedup of customer 532's test files; they are
> filling a mask with a halftone, which breaks down into lots of
> short run, 1 pixel high rectangles. Avoiding the clipping device
> avoids lots of function call overhead.
> gs/base/gdevdbit.c
> gs/base/gxclip.c
> gs/base/gxcpath.h

2012-02-06 15:37:04 +0000
Robin Watts <robin.watts@artifex.com>
09a47e5c2b0fff0d2598e38305bc3d0bc050a26f

> Remove overzealous call to image_init_clues.
> Investigation of customer 532's problem files lead Ray to
> spot that we are blowing away the color clues on every call to
> image_render_mono (called for every scanline in an image at
> least), rather than just once per image.
> Here, therefore, we change to call image_init_clues in
> gs_image_class_3_mono (the function that returns image_render_mono)
> rather than in image_render_mono itself.
> gs/base/gximono.c

2012-02-06 15:25:33 +0000
Robin Watts <robin.watts@artifex.com>
ea8d2baefa33457d89b4daa8a80dd1898a362bd3

> Remove last vestiges of halftone cache.
> Back in 2002 code was committed (as part of the DeviceN work) that
> removed the halftone cache from the image state. The last vestiges
> of this were functions:
> gx_check_tile_cache_current
> gx_check_tile_cache
> gx_check_tile_size
> All these were hardwired to return a constant value, but the calls
> to them were never removed from the code.
> Here, we remove those calls. No differences should be given.
> gs/base/gxht.c
> gs/base/gximono.c
> gs/base/gxipixel.c
> gs/base/gzht.h

2012-02-06 10:55:59 +0000
Chris Liddell <chris.liddell@artifex.com>
013136f0e1050dc25c441fdf49dbfeb21ce0ee7a

> Bug 692838: fix building against system zlib
> Commit 75ff1314c3de8fb5df702211b6effb6df2b87faa broke building against the
> system zlib by adding an explicit dependency on a file in the "local" zlib
> source directory.
> Ensure that dependency only applies when building non-shared zlib.
> Also, at some point, the mkromfs with shared zlib has been broken, so fix that
> by passing the "-lz" option to the CCAUX compiler variable.
> No cluster differences.
> gs/base/Makefile.in
> gs/base/configure.ac
> gs/base/lib.mak

2012-02-04 21:14:04 -0800
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
75ff1314c3de8fb5df702211b6effb6df2b87faa

> Added dependencies to base/lib.mak.
> gs/base/gs.mak
> gs/base/lib.mak

2012-02-04 11:09:47 +0000
Ken Sharp <ken.sharp@artifex.com>
051ed7e56c0d3ef36149c45610bd19a0e55647c0

> ps2write - Handle nested patterns better
> Patterns inside patterns were not working properly, because PDF and PostScript
> handle this differently. opdfread.ps resets teh graphics state CTM to the
> identity when drawing patterns, because the PDF spec says patterns are always
> referenced to the default co-ordinate space and in order that the matrix gets
> applied correctly we need to reset the CTM.
> However, when the pattern is inside another pattern, the defualt co-ordinate
> space is that of the enclosing pattern, so restting the CTM is a problem. We
> can't simply avoid the reset as normal patterns would stop working. We can't
> 'undo#' the pattern matrix in PostScript, because we don't know what the
> resolution scaling was.
> So we track the pattern depth in ps2write, and the accumulated matrix transforms
> from all the patterns so far. Then we apply that accumulated matrix to any new
> pattern when the pattern depth is not zero.
> This works, but is not 100% reliable, 2 patterns inside a single parent would
> be concatenated, resulting in the second pattern being incorrect. However the
> nested pattern situation is rare enough that I'm going to leave this as it is.
> Expected Differences:
> 09_47N.pdf
> Bug6901014_org_Chromium_AN03F.pdf
> these files now work correctly with ps2write.
> gs/base/gdevpdfb.h
> gs/base/gdevpdfi.c
> gs/base/gdevpdfv.c
> gs/base/gdevpdfx.h

2012-02-03 17:50:37 -0700
Henry Stiles <henry.stiles@artifex.com>
e7c3c6e02fac1a6e24030a2815645610b42fde47

> Fixes 692387, the font rotation code did not work properly for some
> rotations.
> There are many progressions and small character placement adjustments
> in many regression files. The latter due to how the rotation matrix
> is now calculated with a rounded angle.
> pcl/pglabel.c

2012-02-02 17:31:27 -0700
Henry Stiles <henry.stiles@artifex.com>
2cffba33ed7bb6aafe9176688535eab290cb20f0

> RTL mode's print direction is always rotated with respect to the
> physical page size.
> pcl/pcpage.c

2012-02-03 16:18:01 +0000
Chris Liddell <chris.liddell@artifex.com>
84abcb901a8451ece9f23fda4b17f670b335eb07

> Propogate dynmic device flags to 'so' subtarget.
> When I brought the Makefile into line with convention for some of the FLAGS
> variables, I forgot to add the new 'AC_CFLAGS' value to the subtarget for
> the dynamic library build.
> No cluster differences.
> gs/base/unix-dll.mak

2012-02-03 16:20:25 +0100
Till Kamppeter <till.kamppeter@gmail.com>
03ab853b064b491cb463e392fe6988e904d76fd5

> CUPS Raster: Fixed rotating of input pages with unknown sizes
> gs/cups/gdevcups.c

2012-02-02 21:02:26 +0100
Till Kamppeter <till.kamppeter@gmail.com>
d0b64a75d54948b3f07da0128bb0002523a39040

> CUPS Raster: More on improving page size fitting
> Raised the tolerance of matching the document's page sizes with the PPD's
> page sizes on the short dimension to 2 %. This also covers the overspray
> full-bleed page sizes of HPLIP.
> gs/cups/gdevcups.c

2012-02-02 20:43:22 +0100
Till Kamppeter <till.kamppeter@gmail.com>
2d4fac37ee36948c0b30e6b95292b68f718cafdc

> Merge branch 'master' of ghostscript.com:/home/git/ghostpdl

2012-02-02 12:14:41 -0700
Henry Stiles <henry.stiles@artifex.com>
72887eac758eba7638258b6b375347ee16efbbdc

> Add 4 new raster decompression methods to PCL.
> HPGL/2 and RTL plotters support the following decompression methods:
> uncompressed block (#4), CCITT group 3 1 dimensional (#6), CCITT group
> 3 2 dimensional (#7), CCITT group 4 2 dimensional (#8). These have
> gotten little testing we only have a couple test files at the current
> time.
> pcl/pcl.mak
> pcl/rtgmode.c
> pcl/rtraster.c
> pcl/rtrstcmp.c
> pcl/rtrstcmp.h

2012-02-02 19:37:07 +0100
Till Kamppeter <till.kamppeter@gmail.com>
49be0086211ef92988468cee4bad5d361b8b6c7d

> Improved page size matching in the CUPS Raster output device
> The tolerances when comparing the page sizes in the document with the
> sizes in the PPD file are changed to 1% for the short dimension of the
> page and 5% for the long dimension. The 1% for the short dimension is
> more or less the same as the 5.0pt used before (on letter or A4
> paper). The 5% can cover the half inch deviation which HP puts into
> the sheet length for their duplex paper sizes on ink jets.
> If there is no matching paper size in the PPD and therefore the paper
> size is considered custom, the page will be rotated in the case that
> it does not fit into the maximum custom paper size (= printer
> dimensions) but fits rotated.
> With these measures, pages with slightly incorrectly defined size or
> slightly incorrectly defined sizes in the PPD file (like the different
> entries for one and the same paper size in the PPDs of HPLIP) will
> find their size in the PPD and so rotated if needed.
> This avoids cut-off print outs or even crashes of the printer
> (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/917148) due to
> landscape pages not getting rotated.
> gs/cups/gdevcups.c

2012-01-31 12:55:34 -0800
Michael Vrhel <michael.vrhel@artifex.com>
ee811255187a9367a090ce542e78c13912e92ca6

> Device Link and Proof Profile fix
> If a proofing profile or a device link profile are
> specified, the link transform is more than likely not going
> to be identity. This fix ensures that the transform
> is properly applied.
> gs/base/gsicc_cache.c

2012-01-31 18:20:00 +0000
Chris Liddell <chris.liddell@artifex.com>
a68dde56d66d7a5b9aabf0c742efb77b5fbdca03

> Bug 690473: scale substitute fonts to fit in Widths.
> Compare the width of the glyphs in a substitute font with those in the PDF
> Widths array, and scale the font down to fit better, if necessary. This
> does not add scaling up the font.
> This changes a number of cluster files - most are progressions, some are just
> different (no worse, no better), none that I consider regressions.
> gs/Resource/Init/pdf_font.ps

2012-01-30 15:28:05 -0800
Michael Vrhel <michael.vrhel@artifex.com>
d630ef2c042179ecf0443b15b488194690f6b980

> Make device link profile work with lcms2. Also update documentation and add error handling.
> The device link profile handling was put in place when we had lcms 1.8 but was not ported
> over to the 2.0 interface.
> gs/base/gsicc.c
> gs/base/gsicc_lcms2.c
> gs/doc/Use.htm

2012-01-31 18:04:01 +0000
Chris Liddell <chris.liddell@artifex.com>
306f7dce4e74bc715a91dd892eab78f856cf11da

> Have gitlog2changelog.py use html code for "quote" char
> CLUSTER_UNTESTED
> gs/toolbin/gitlog2changelog.py

2012-01-31 17:49:42 +0000
Robin Watts <robin.watts@artifex.com>
3c61e0b90b63dbef94f75e370ccef9dd5a077c26

> Add new "WhatIsGS.htm" document
> This explains how Ghostscript, GhostPCL, GhostXPS, etc are related.
> gs/doc/Readme.htm
> gs/doc/WhatIsGS.htm

2012-01-31 11:26:31 -0500
Alex Cherepanov <alex.cherepanov@artifex.com>
ddedf257534b7c628442d92f771dc8240cf546a7

> Bug 691483: Fix access to PDF collections.
> Fix a bug in enumeration of a name tree that prevented acceaa to some
> files in the PDF file collection when the name tree was more than
> one level deep.
> gs/Resource/Init/pdf_main.ps

2012-01-31 12:01:53 +0000
Chris Liddell <chris.liddell@artifex.com>
26a96f7660a921d80dba77ef0220845918cfd4a8

> Have plver.mak use Ghostscript version.mak version number
> No (significant) cluster differences.
> common/msvc_top.mak
> pl/pl.mak

2012-01-31 08:12:14 +0000
Ken Sharp <ken.sharp@artifex.com>
20cd9c7595492684ac564789afeb2df1b6066554

> ps2write - silence a benign compiler warning
> Picked up by scan-build; presumably this only gets run for commits, not
> for regular cluster tests as it didn't show up previously.
> gs/base/gdevpdfc.c

2012-01-30 20:26:30 +0000
Chris Liddell <chris.liddell@artifex.com>
ca932b9ee0a84e7725b347d9fc99ef8b2b3ad8c8

> gitlog2changelog.py use html sequence for '&'
> Thanks to SaGS for pointing it out.
> CLUSTER_UNTESTED
> gs/toolbin/gitlog2changelog.py

2012-01-30 18:14:22 +0000
Chris Liddell <chris.liddell@artifex.com>
69d0fee61911ef6044b07cd7b36bc2148e6bb214

> Tweak gitlog2changelog.py to avoid trailing whitespace
> CLUSTER_UNTESTED
> gs/toolbin/gitlog2changelog.py

2012-01-30 17:41:35 +0000
Chris Liddell <chris.liddell@artifex.com>
08a189c3b72e6bf89ae938b0bbacbbf113e0e346

> Improve the html output of the changelog generator.
> There were some compatibility problems with the html from the git log to
> html changelog generator - such as including '<' and '>' characters in
> text to be displayed.
> Also, improve the actual formatting slightly.
> CLUSTER_UNTESTED
> gs/toolbin/gitlog2changelog.py

2012-01-30 17:46:27 +0000
Chris Liddell <chris.liddell@artifex.com>
5dd29e182ea1fec5e504558173bbb875501d04a1

> Move the JPEG XR code to a separate section......
> ... for non-GPL compatible, open source licensed code.
> CLUSTER_UNTESTED
> gs/doc/thirdparty.htm

2012-01-30 13:32:05 +0000
Ken Sharp <ken.sharp@artifex.com>
ef2a4bfbf4f590635277299bf0e0d7aaea1f392b

> ps2write - correctly convert ICCBased *image* colour spaces
> Previously we handled ICCbased spaces by pretending they were device spaces
> with the same number of components as the ICCBased space. This works
> suprisingly well, but fails utterly for Lab spaces where images come out
> completely incorrect.
> We now convert the image data to the current device space. We do not yet handle
> vector colour spaces, this will be handled by a future rewrite of the colour
> handling to permit much better control over colour space handling.
> This change causes quite a number o differences in the regression suite.
> These fall into one of 4 causes:
> 1) Colour space conversion; previously ICCBases spaces with 1 or 4 components
> would be handled as grey or CMYK respectively. They are now converted to the
> device space (RGB by default). This causes some colour changes, especially
> in halftoned output with a 1 component space. These are not incorrect as can
> be seen from the contone output
> 2) There are some minor shifts in colour caused by correctly handling the
> ICCBased space, in general these are progressions (especially the Altona
> suite).
> 3) Handling of Lab colour spaces. These now work correctly where previously
> they did not. Especially catx4929.pdf and IA3Z3476.pdf
> 4) Honouring rendering intents. Files hwich used a rendering intent now are
> correctly converted. cf Bug #691926, comment 3.
> 5) There seems to be a possible problem with converting some CalRGB spaces,
> the resulting output seems 'blue' with respect to the Acrobat otuput. In the
> case of 1 file which contains scanned images of books, it is clear from the
> original book covers that the output is incorrect. Michael suggest this may be
> a White POitn problem. A separate bug report will be filed for this. Ghostscript
> rendering of the original matches the ps2write output.
> gs/base/gdevpdfc.c
> gs/base/gdevpdfg.h
> gs/base/gdevpdfi.c

2012-01-30 13:25:17 +0000
Chris Liddell <chris.liddell@artifex.com>
58e2df820785b88a544f625de35fbcb39c35b305

> Update LICENSE
> Revise the LICENSE file to reflect the latest Adobe CMap license
> conditions, and to note that there is an Artifex copyright CMap in the
> CMap directory.
> Also, add a note about the JPEX XR source license.
> CLUSTER_UNTESTED
> gs/LICENSE

2012-01-30 13:23:18 +0000
Chris Liddell <chris.liddell@artifex.com>
523697346bbc88bf309cb44b47f53516c33917f7

> Increment Ghostscript version on master to 9.06.
> No (important) cluster differences.
> gs/Resource/Init/gs_init.ps
> gs/base/version.mak

2012-02-08 08:42:09 +0000
Chris Liddell <chris.liddell@artifex.com>
593431146ef93a53744a04c2a571a6f1f40b0084

> Remove "RELEASE CANDIDATE" from product string.
> CLUSTER_UNTESTED
> gs/base/gscdef.c

2012-02-08 08:40:12 +0000
Chris Liddell <chris.liddell@artifex.com>
c1d20ffdb4d184c9019ee7f58bc279c6d633d05d

> Amend date and update changelog for 9.05 release.
> CLUSTER_UNTESTED
> gs/base/version.mak
> gs/doc/API.htm
> gs/doc/C-style.htm
> gs/doc/Commprod.htm
> gs/doc/DLL.htm
> gs/doc/Deprecated.htm
> gs/doc/Details8.htm
> gs/doc/Details9.htm
> gs/doc/Develop.htm
> gs/doc/Devices.htm
> gs/doc/Drivers.htm
> gs/doc/Fonts.htm
> gs/doc/Helpers.htm
> gs/doc/History1.htm
> gs/doc/History2.htm
> gs/doc/History3.htm
> gs/doc/History4.htm
> gs/doc/History5.htm
> gs/doc/History6.htm
> gs/doc/History7.htm
> gs/doc/History8.htm
> gs/doc/History9.htm
> gs/doc/Install.htm
> gs/doc/Issues.htm
> gs/doc/Language.htm
> gs/doc/Lib.htm
> gs/doc/Make.htm
> gs/doc/News.htm
> gs/doc/Projects.htm
> gs/doc/Ps-style.htm
> gs/doc/Ps2epsi.htm
> gs/doc/Ps2pdf.htm
> gs/doc/Ps2ps2.htm
> gs/doc/Psfiles.htm
> gs/doc/Readme.htm
> gs/doc/Release.htm
> gs/doc/Source.htm
> gs/doc/Unix-lpr.htm
> gs/doc/Use.htm
> gs/doc/WhatIsGS.htm
> gs/doc/Xfonts.htm
> gs/doc/gs-vms.hlp
> gs/doc/thirdparty.htm
> gs/man/dvipdf.1
> gs/man/font2c.1
> gs/man/gs.1
> gs/man/gslp.1
> gs/man/gsnd.1
> gs/man/pdf2dsc.1
> gs/man/pdf2ps.1
> gs/man/pdfopt.1
> gs/man/pf2afm.1
> gs/man/pfbtopfa.1
> gs/man/printafm.1
> gs/man/ps2ascii.1
> gs/man/ps2epsi.1
> gs/man/ps2pdf.1
> gs/man/ps2pdfwr.1
> gs/man/ps2ps.1
> gs/man/wftopfa.1

2012-02-03 16:18:01 +0000
Chris Liddell <chris.liddell@artifex.com>
dd4c7f1f03aa7ea18d43db224126502725af91ba

> Propogate dynmic device flags to 'so' subtarget.
> When I brought the Makefile into line with convention for some of the FLAGS
> variables, I forgot to add the new 'AC_CFLAGS' value to the subtarget for
> the dynamic library build.
> No cluster differences.
> gs/base/unix-dll.mak

2012-02-03 16:20:25 +0100
Till Kamppeter <till.kamppeter@gmail.com>
e837609b2955680dc59ca4f357076be7cd819a46

> CUPS Raster: Fixed rotating of input pages with unknown sizes
> gs/cups/gdevcups.c

2012-02-02 21:02:26 +0100
Till Kamppeter <till.kamppeter@gmail.com>
c3464da3ee42b8af645af6eadabea4977d948b1a

> CUPS Raster: More on improving page size fitting
> Raised the tolerance of matching the document's page sizes with the PPD's
> page sizes on the short dimension to 2 %. This also covers the overspray
> full-bleed page sizes of HPLIP.
> gs/cups/gdevcups.c

2012-02-02 19:37:07 +0100
Till Kamppeter <till.kamppeter@gmail.com>
c12ed06596207d895739b41e5c920af0aa48a2ff

> Improved page size matching in the CUPS Raster output device
> The tolerances when comparing the page sizes in the document with the
> sizes in the PPD file are changed to 1% for the short dimension of the
> page and 5% for the long dimension. The 1% for the short dimension is
> more or less the same as the 5.0pt used before (on letter or A4
> paper). The 5% can cover the half inch deviation which HP puts into
> the sheet length for their duplex paper sizes on ink jets.
> If there is no matching paper size in the PPD and therefore the paper
> size is considered custom, the page will be rotated in the case that
> it does not fit into the maximum custom paper size (= printer
> dimensions) but fits rotated.
> With these measures, pages with slightly incorrectly defined size or
> slightly incorrectly defined sizes in the PPD file (like the different
> entries for one and the same paper size in the PPDs of HPLIP) will
> find their size in the PPD and so rotated if needed.
> This avoids cut-off print outs or even crashes of the printer
> (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/917148) due to
> landscape pages not getting rotated.
> gs/cups/gdevcups.c

2012-02-01 11:06:38 +0000
Chris Liddell <chris.liddell@artifex.com>
f945ac6dd076b367fb9a9d8851cca783049b77a0

> Change product string to "RELEASE CANDIDATE 1"
> gs/base/gscdef.c

2012-02-01 10:59:52 +0000
Chris Liddell <chris.liddell@artifex.com>
5f1a49cb3b05b5fed23e7eab99d6e036f16921dd

> Update docs for 9.05 release candidate.
> CLUSTER_UNTESTED
> gs/doc/History9.htm

2012-01-31 12:55:34 -0800
Michael Vrhel <michael.vrhel@artifex.com>
ffca2758193c517edf1d20c6af17acd85f8d5f99

> Device Link and Proof Profile fix
> If a proofing profile or a device link profile are
> specified, the link transform is more than likely not going
> to be identity. This fix ensures that the transform
> is properly applied.
> gs/base/gsicc_cache.c

2012-01-30 15:28:05 -0800
Michael Vrhel <michael.vrhel@artifex.com>
dbf3d3403bc928c183b0674aa5adbb6263d56e42

> Make device link profile work with lcms2. Also update documentation and add error handling.
> The device link profile handling was put in place when we had lcms 1.8 but was not ported
> over to the 2.0 interface.
> gs/base/gsicc.c
> gs/base/gsicc_lcms2.c
> gs/doc/Use.htm

2012-01-31 18:04:01 +0000
Chris Liddell <chris.liddell@artifex.com>
55049debcc22152c42a62b1fc350eb087125be5a

> Have gitlog2changelog.py use html code for "quote" char
> CLUSTER_UNTESTED
> gs/toolbin/gitlog2changelog.py

2012-01-31 17:49:42 +0000
Robin Watts <robin.watts@artifex.com>
6123f6bc89a9c682dd0e0b8cb62d526fdca1b50a

> Add new "WhatIsGS.htm" document
> This explains how Ghostscript, GhostPCL, GhostXPS, etc are related.
> gs/doc/Readme.htm
> gs/doc/WhatIsGS.htm

2012-01-31 11:26:31 -0500
Alex Cherepanov <alex.cherepanov@artifex.com>
1216fd5e30a1a09b8b381d4e43d795728a030cc8

> Bug 691483: Fix access to PDF collections.
> Fix a bug in enumeration of a name tree that prevented acceaa to some
> files in the PDF file collection when the name tree was more than
> one level deep.
> gs/Resource/Init/pdf_main.ps

2012-01-31 08:12:14 +0000
Ken Sharp <ken.sharp@artifex.com>
0a549a4395c169a547e95a2905650dbc05388794

> ps2write - silence a benign compiler warning
> Picked up by scan-build; presumably this only gets run for commits, not
> for regular cluster tests as it didn't show up previously.
> gs/base/gdevpdfc.c

2012-01-31 12:01:53 +0000
Chris Liddell <chris.liddell@artifex.com>
4003b18b598c81df02d3d2c043276d54e7de7c6d

> Have plver.mak use Ghostscript version.mak version number
> No (significant) cluster differences.
> common/msvc_top.mak
> pl/pl.mak

2012-01-30 20:39:29 +0000
Chris Liddell <chris.liddell@artifex.com>
613b796e44ad8e29d9b4f8166a8b19796f1a024c

> Change a couple of '&' to &amp;
> CLUSTER_UNTESTED
> gs/doc/History9.htm

2012-01-30 20:26:30 +0000
Chris Liddell <chris.liddell@artifex.com>
f58e15f60683f2be163e0a64ef1a86141a0d45c3

> gitlog2changelog.py use html sequence for '&'
> Thanks to SaGS for pointing it out.
> CLUSTER_UNTESTED
> gs/toolbin/gitlog2changelog.py

2012-01-30 18:14:22 +0000
Chris Liddell <chris.liddell@artifex.com>
7a9e90a4710a90ce3d12da590280e91166eb2dc5

> Tweak gitlog2changelog.py to avoid trailing whitespace
> CLUSTER_UNTESTED
> gs/toolbin/gitlog2changelog.py

2012-01-30 18:00:23 +0000
Chris Liddell <chris.liddell@artifex.com>
4aaa5f1594df678db91e3e9e913d1b27d5f7cd05

> Update docs in prep for 9.05 release candidate
> CLUSTER_UNTESTED
> gs/doc/API.htm
> gs/doc/C-style.htm
> gs/doc/Commprod.htm
> gs/doc/DLL.htm
> gs/doc/Deprecated.htm
> gs/doc/Details8.htm
> gs/doc/Details9.htm
> gs/doc/Develop.htm
> gs/doc/Devices.htm
> gs/doc/Drivers.htm
> gs/doc/Fonts.htm
> gs/doc/Helpers.htm
> gs/doc/History1.htm
> gs/doc/History2.htm
> gs/doc/History3.htm
> gs/doc/History4.htm
> gs/doc/History5.htm
> gs/doc/History6.htm
> gs/doc/History7.htm
> gs/doc/History8.htm
> gs/doc/History9.htm
> gs/doc/Install.htm
> gs/doc/Issues.htm
> gs/doc/Language.htm
> gs/doc/Lib.htm
> gs/doc/Make.htm
> gs/doc/News.htm
> gs/doc/Projects.htm
> gs/doc/Ps-style.htm
> gs/doc/Ps2epsi.htm
> gs/doc/Ps2pdf.htm
> gs/doc/Ps2ps2.htm
> gs/doc/Psfiles.htm
> gs/doc/Readme.htm
> gs/doc/Release.htm
> gs/doc/Source.htm
> gs/doc/Unix-lpr.htm
> gs/doc/Use.htm
> gs/doc/Xfonts.htm
> gs/doc/gs-vms.hlp
> gs/doc/thirdparty.htm
> gs/man/dvipdf.1
> gs/man/font2c.1
> gs/man/gs.1
> gs/man/gslp.1
> gs/man/gsnd.1
> gs/man/pdf2dsc.1
> gs/man/pdf2ps.1
> gs/man/pdfopt.1
> gs/man/pf2afm.1
> gs/man/pfbtopfa.1
> gs/man/printafm.1
> gs/man/ps2ascii.1
> gs/man/ps2epsi.1
> gs/man/ps2pdf.1
> gs/man/ps2pdfwr.1
> gs/man/ps2ps.1
> gs/man/wftopfa.1

2012-01-30 17:59:49 +0000
Chris Liddell <chris.liddell@artifex.com>
60ef9ebafb60f60cb709f7cb48ff15b94bad45fe

> Change product string in prep for 9.05 release candidate
> CLUSTER_UNTESTED
> gs/base/version.mak

2012-01-30 17:46:27 +0000
Chris Liddell <chris.liddell@artifex.com>
16195b5e1c104405e095753bc1343597cad32a28

> Move the JPEG XR code to a separate section......
> ... for non-GPL compatible, open source licensed code.
> CLUSTER_UNTESTED
> gs/doc/thirdparty.htm

2012-01-30 17:41:35 +0000
Chris Liddell <chris.liddell@artifex.com>
4961e763aeb795e7dc91dc64575837d170cca367

> Improve the html output of the changelog generator.
> There were some compatibility problems with the html from the git log to
> html changelog generator - such as including '<' and '>' characters in
> text to be displayed.
> Also, improve the actual formatting slightly.
> CLUSTER_UNTESTED
> gs/toolbin/gitlog2changelog.py

2012-01-30 13:32:05 +0000
Ken Sharp <ken.sharp@artifex.com>
c3cc9b71fb9f1fe64556ecad34418bb4cf44ba7f

> ps2write - correctly convert ICCBased *image* colour spaces
> Previously we handled ICCbased spaces by pretending they were device spaces
> with the same number of components as the ICCBased space. This works
> suprisingly well, but fails utterly for Lab spaces where images come out
> completely incorrect.
> We now convert the image data to the current device space. We do not yet handle
> vector colour spaces, this will be handled by a future rewrite of the colour
> handling to permit much better control over colour space handling.
> This change causes quite a number o differences in the regression suite.
> These fall into one of 4 causes:
> 1) Colour space conversion; previously ICCBases spaces with 1 or 4 components
> would be handled as grey or CMYK respectively. They are now converted to the
> device space (RGB by default). This causes some colour changes, especially
> in halftoned output with a 1 component space. These are not incorrect as can
> be seen from the contone output
> 2) There are some minor shifts in colour caused by correctly handling the
> ICCBased space, in general these are progressions (especially the Altona
> suite).
> 3) Handling of Lab colour spaces. These now work correctly where previously
> they did not. Especially catx4929.pdf and IA3Z3476.pdf
> 4) Honouring rendering intents. Files hwich used a rendering intent now are
> correctly converted. cf Bug #691926, comment 3.
> 5) There seems to be a possible problem with converting some CalRGB spaces,
> the resulting output seems 'blue' with respect to the Acrobat otuput. In the
> case of 1 file which contains scanned images of books, it is clear from the
> original book covers that the output is incorrect. Michael suggest this may be
> a White POitn problem. A separate bug report will be filed for this. Ghostscript
> rendering of the original matches the ps2write output.
> gs/base/gdevpdfc.c
> gs/base/gdevpdfg.h
> gs/base/gdevpdfi.c

2012-01-30 13:25:17 +0000
Chris Liddell <chris.liddell@artifex.com>
2bb769a5b1ff2d1b8a5e6f0320cb210befe3f5bd

> Update LICENSE
> Revise the LICENSE file to reflect the latest Adobe CMap license
> conditions, and to note that there is an Artifex copyright CMap in the
> CMap directory.
> Also, add a note about the JPEX XR source license.
> CLUSTER_UNTESTED
> gs/LICENSE

## Version 9.05 (2012-02-08)

This is the fifth full release in the stable 9.x series.

Highlights in this release include:

- Ghostscript's PDF interpreter is now able to make use of the DroidSansFallback TrueType font to automatically substitute for missing CIDFonts. Whilst it is always best to ensure the original CIDFont is available for the best and most accurate output, the ability to make an automatic substitution will be valuable for those merely viewing or proofing such files.

- This release includes support for a proofing ICC profile. The command option is specified using -sProofProfile=filename. With this option, the color output will emulate what would be obtained had the source file been rendered on a device defined by the proofing profile. (See GS9_Color_Management.pdf for details.)

- This release includes support for a device link ICC profile. The command option is specified using -sDeviceLinkProfile=filename. With this option, the device link profile is added to the end of the link transform from source to destination. In this case, one can include a command line option like "-sDevice=tiff32nc -sOutputICCProfile=srgb.icc -sDeviceLinkProfile=linkRGBtoCMYK.icc" and source colors will be mapped through sRGB and through the device link profile to CMYK values for the device. (See GS9_Color_Management.pdf for details.)

- Ghostscript now supports "unmanaged color transformations" for source DeviceXXX colors (in other words, they use a simplistic conversion, rather than the ICC profile based color workflow). This is beneficial in uses where performance takes precedence over ultimate color fidelity (the command line parameter -dUseFastColor enables this).

- The font set distributed with Ghostscript has been changed to the standard 35 Postscript-compatible fonts distributed by URW.

- Ghostscript now includes a simple ink-coverage device, contributed by Sebastian Kapfer (inkconv).

- The TIFF, JPEG and PNG output devices now support embedding of the device ICC profile in the output file.

- Ghostscript now ships modified OpenJPEG sources for JPEG2000 decoding (replacing JasPer - although JasPer is still included for this release). Performance, reliability and memory use whilst decoding JPX streams are all improved (in many cases, significantly).

- jbig2dec now has simple halftone region support.

- The ps2write device has had a large number of output quality and stability improvements.

- The txtwrite output was modified so that it more closely matches the output from MuPDF, if requested. Note that the algorithms used by the two products are not identical and may return slightly differing results.

(See Devices.htm for details)

For a list of open issues, or to report problems, please visit bugs.ghostscript.com.

### Incompatible changes

No recorded incompatible changes.

### Changelog

2012-02-03 16:18:01 +0000
Chris Liddell <chris.liddell@artifex.com>
dd4c7f1f03aa7ea18d43db224126502725af91ba

> Propogate dynmic device flags to 'so' subtarget.
> When I brought the Makefile into line with convention for some of the FLAGS
> variables, I forgot to add the new 'AC_CFLAGS' value to the subtarget for
> the dynamic library build.
> No cluster differences.
> gs/base/unix-dll.mak

2012-02-03 16:20:25 +0100
Till Kamppeter <till.kamppeter@gmail.com>
e837609b2955680dc59ca4f357076be7cd819a46

> CUPS Raster: Fixed rotating of input pages with unknown sizes
> gs/cups/gdevcups.c

2012-02-02 21:02:26 +0100
Till Kamppeter <till.kamppeter@gmail.com>
c3464da3ee42b8af645af6eadabea4977d948b1a

> CUPS Raster: More on improving page size fitting
> Raised the tolerance of matching the document's page sizes with the PPD's
> page sizes on the short dimension to 2 %. This also covers the overspray
> full-bleed page sizes of HPLIP.
> gs/cups/gdevcups.c

2012-02-02 19:37:07 +0100
Till Kamppeter <till.kamppeter@gmail.com>
c12ed06596207d895739b41e5c920af0aa48a2ff

> Improved page size matching in the CUPS Raster output device
> The tolerances when comparing the page sizes in the document with the
> sizes in the PPD file are changed to 1% for the short dimension of the
> page and 5% for the long dimension. The 1% for the short dimension is
> more or less the same as the 5.0pt used before (on letter or A4
> paper). The 5% can cover the half inch deviation which HP puts into
> the sheet length for their duplex paper sizes on ink jets.
> If there is no matching paper size in the PPD and therefore the paper
> size is considered custom, the page will be rotated in the case that
> it does not fit into the maximum custom paper size (= printer
> dimensions) but fits rotated.
> With these measures, pages with slightly incorrectly defined size or
> slightly incorrectly defined sizes in the PPD file (like the different
> entries for one and the same paper size in the PPDs of HPLIP) will
> find their size in the PPD and so rotated if needed.
> This avoids cut-off print outs or even crashes of the printer
> (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/917148) due to
> landscape pages not getting rotated.
> gs/cups/gdevcups.c

2012-02-01 11:06:38 +0000
Chris Liddell <chris.liddell@artifex.com>
f945ac6dd076b367fb9a9d8851cca783049b77a0

> Change product string to "RELEASE CANDIDATE 1"
> gs/base/gscdef.c

2012-02-01 10:59:52 +0000
Chris Liddell <chris.liddell@artifex.com>
5f1a49cb3b05b5fed23e7eab99d6e036f16921dd

> Update docs for 9.05 release candidate.
> CLUSTER_UNTESTED
> gs/doc/History9.htm

2012-01-31 12:55:34 -0800
Michael Vrhel <michael.vrhel@artifex.com>
ffca2758193c517edf1d20c6af17acd85f8d5f99

> Device Link and Proof Profile fix
> If a proofing profile or a device link profile are
> specified, the link transform is more than likely not going
> to be identity. This fix ensures that the transform
> is properly applied.
> gs/base/gsicc_cache.c

2012-01-30 15:28:05 -0800
Michael Vrhel <michael.vrhel@artifex.com>
dbf3d3403bc928c183b0674aa5adbb6263d56e42

> Make device link profile work with lcms2. Also update documentation and add error handling.
> The device link profile handling was put in place when we had lcms 1.8 but was not ported
> over to the 2.0 interface.
> gs/base/gsicc.c
> gs/base/gsicc_lcms2.c
> gs/doc/Use.htm

2012-01-31 18:04:01 +0000
Chris Liddell <chris.liddell@artifex.com>
55049debcc22152c42a62b1fc350eb087125be5a

> Have gitlog2changelog.py use html code for "quote" char
> CLUSTER_UNTESTED
> gs/toolbin/gitlog2changelog.py

2012-01-31 17:49:42 +0000
Robin Watts <robin.watts@artifex.com>
6123f6bc89a9c682dd0e0b8cb62d526fdca1b50a

> Add new "WhatIsGS.htm" document
> This explains how Ghostscript, GhostPCL, GhostXPS, etc are related.
> gs/doc/Readme.htm
> gs/doc/WhatIsGS.htm

2012-01-31 11:26:31 -0500
Alex Cherepanov <alex.cherepanov@artifex.com>
1216fd5e30a1a09b8b381d4e43d795728a030cc8

> Bug 691483: Fix access to PDF collections.
> Fix a bug in enumeration of a name tree that prevented acceaa to some
> files in the PDF file collection when the name tree was more than
> one level deep.
> gs/Resource/Init/pdf_main.ps

2012-01-31 08:12:14 +0000
Ken Sharp <ken.sharp@artifex.com>
0a549a4395c169a547e95a2905650dbc05388794

> ps2write - silence a benign compiler warning
> Picked up by scan-build; presumably this only gets run for commits, not
> for regular cluster tests as it didn't show up previously.
> gs/base/gdevpdfc.c

2012-01-31 12:01:53 +0000
Chris Liddell <chris.liddell@artifex.com>
4003b18b598c81df02d3d2c043276d54e7de7c6d

> Have plver.mak use Ghostscript version.mak version number
> No (significant) cluster differences.
> common/msvc_top.mak
> pl/pl.mak

2012-01-30 20:39:29 +0000
Chris Liddell <chris.liddell@artifex.com>
613b796e44ad8e29d9b4f8166a8b19796f1a024c

> Change a couple of '&' to &amp;
> CLUSTER_UNTESTED
> gs/doc/History9.htm

2012-01-30 20:26:30 +0000
Chris Liddell <chris.liddell@artifex.com>
f58e15f60683f2be163e0a64ef1a86141a0d45c3

> gitlog2changelog.py use html sequence for '&'
> Thanks to SaGS for pointing it out.
> CLUSTER_UNTESTED
> gs/toolbin/gitlog2changelog.py

2012-01-30 18:14:22 +0000
Chris Liddell <chris.liddell@artifex.com>
7a9e90a4710a90ce3d12da590280e91166eb2dc5

> Tweak gitlog2changelog.py to avoid trailing whitespace
> CLUSTER_UNTESTED
> gs/toolbin/gitlog2changelog.py

2012-01-30 18:00:23 +0000
Chris Liddell <chris.liddell@artifex.com>
4aaa5f1594df678db91e3e9e913d1b27d5f7cd05

> Update docs in prep for 9.05 release candidate
> CLUSTER_UNTESTED
> gs/doc/API.htm
> gs/doc/C-style.htm
> gs/doc/Commprod.htm
> gs/doc/DLL.htm
> gs/doc/Deprecated.htm
> gs/doc/Details8.htm
> gs/doc/Details9.htm
> gs/doc/Develop.htm
> gs/doc/Devices.htm
> gs/doc/Drivers.htm
> gs/doc/Fonts.htm
> gs/doc/Helpers.htm
> gs/doc/History1.htm
> gs/doc/History2.htm
> gs/doc/History3.htm
> gs/doc/History4.htm
> gs/doc/History5.htm
> gs/doc/History6.htm
> gs/doc/History7.htm
> gs/doc/History8.htm
> gs/doc/History9.htm
> gs/doc/Install.htm
> gs/doc/Issues.htm
> gs/doc/Language.htm
> gs/doc/Lib.htm
> gs/doc/Make.htm
> gs/doc/News.htm
> gs/doc/Projects.htm
> gs/doc/Ps-style.htm
> gs/doc/Ps2epsi.htm
> gs/doc/Ps2pdf.htm
> gs/doc/Ps2ps2.htm
> gs/doc/Psfiles.htm
> gs/doc/Readme.htm
> gs/doc/Release.htm
> gs/doc/Source.htm
> gs/doc/Unix-lpr.htm
> gs/doc/Use.htm
> gs/doc/Xfonts.htm
> gs/doc/gs-vms.hlp
> gs/doc/thirdparty.htm
> gs/man/dvipdf.1
> gs/man/font2c.1
> gs/man/gs.1
> gs/man/gslp.1
> gs/man/gsnd.1
> gs/man/pdf2dsc.1
> gs/man/pdf2ps.1
> gs/man/pdfopt.1
> gs/man/pf2afm.1
> gs/man/pfbtopfa.1
> gs/man/printafm.1
> gs/man/ps2ascii.1
> gs/man/ps2epsi.1
> gs/man/ps2pdf.1
> gs/man/ps2pdfwr.1
> gs/man/ps2ps.1
> gs/man/wftopfa.1

2012-01-30 17:59:49 +0000
Chris Liddell <chris.liddell@artifex.com>
60ef9ebafb60f60cb709f7cb48ff15b94bad45fe

> Change product string in prep for 9.05 release candidate
> CLUSTER_UNTESTED
> gs/base/version.mak

2012-01-30 17:46:27 +0000
Chris Liddell <chris.liddell@artifex.com>
16195b5e1c104405e095753bc1343597cad32a28

> Move the JPEG XR code to a separate section......
> ... for non-GPL compatible, open source licensed code.
> CLUSTER_UNTESTED
> gs/doc/thirdparty.htm

2012-01-30 17:41:35 +0000
Chris Liddell <chris.liddell@artifex.com>
4961e763aeb795e7dc91dc64575837d170cca367

> Improve the html output of the changelog generator.
> There were some compatibility problems with the html from the git log to
> html changelog generator - such as including '<' and '>' characters in
> text to be displayed.
> Also, improve the actual formatting slightly.
> CLUSTER_UNTESTED
> gs/toolbin/gitlog2changelog.py

2012-01-30 13:32:05 +0000
Ken Sharp <ken.sharp@artifex.com>
c3cc9b71fb9f1fe64556ecad34418bb4cf44ba7f

> ps2write - correctly convert ICCBased *image* colour spaces
> Previously we handled ICCbased spaces by pretending they were device spaces
> with the same number of components as the ICCBased space. This works
> suprisingly well, but fails utterly for Lab spaces where images come out
> completely incorrect.
> We now convert the image data to the current device space. We do not yet handle
> vector colour spaces, this will be handled by a future rewrite of the colour
> handling to permit much better control over colour space handling.
> This change causes quite a number o differences in the regression suite.
> These fall into one of 4 causes:
> 1) Colour space conversion; previously ICCBases spaces with 1 or 4 components
> would be handled as grey or CMYK respectively. They are now converted to the
> device space (RGB by default). This causes some colour changes, especially
> in halftoned output with a 1 component space. These are not incorrect as can
> be seen from the contone output
> 2) There are some minor shifts in colour caused by correctly handling the
> ICCBased space, in general these are progressions (especially the Altona
> suite).
> 3) Handling of Lab colour spaces. These now work correctly where previously
> they did not. Especially catx4929.pdf and IA3Z3476.pdf
> 4) Honouring rendering intents. Files hwich used a rendering intent now are
> correctly converted. cf Bug #691926, comment 3.
> 5) There seems to be a possible problem with converting some CalRGB spaces,
> the resulting output seems 'blue' with respect to the Acrobat otuput. In the
> case of 1 file which contains scanned images of books, it is clear from the
> original book covers that the output is incorrect. Michael suggest this may be
> a White POitn problem. A separate bug report will be filed for this. Ghostscript
> rendering of the original matches the ps2write output.
> gs/base/gdevpdfc.c
> gs/base/gdevpdfg.h
> gs/base/gdevpdfi.c

2012-01-30 13:25:17 +0000
Chris Liddell <chris.liddell@artifex.com>
2bb769a5b1ff2d1b8a5e6f0320cb210befe3f5bd

> Update LICENSE
> Revise the LICENSE file to reflect the latest Adobe CMap license
> conditions, and to note that there is an Artifex copyright CMap in the
> CMap directory.
> Also, add a note about the JPEX XR source license.
> CLUSTER_UNTESTED
> gs/LICENSE

2012-01-28 01:24:50 -0500
Alex Cherepanov <alex.cherepanov@artifex.com>
4e25d12238406245ade09eaeb3dd815933f7bcb2

> Bug 692704: Don't reset PageSpotColors after every page
> Don't reset PageSpotColors after every PDF page. Do it once when
> PDF is closed. first, this resetting serves no useful purpose.
> Second, this change avoids re-initialisation of tiffsep and psdcmyk
> devices, which causes overwriting of the first page.
> The fix results in progressions in all multi-page PDF files on
> psdcmyk device.
> gs/Resource/Init/pdf_main.ps

2012-01-27 09:57:33 +0000
Chris Liddell <chris.liddell@artifex.com>
d385d65cddb8770c0b6e08d0a34609d0951eab1f

> Add a link in Readme.htm to the new thirdparty.htm
> CLUSTER_UNTESTED
> gs/doc/Readme.htm

2012-01-26 16:58:02 +0000
Robin Watts <robin.watts@artifex.com>
b6cc2a2539097d71ec200591788134703a2840a1

> XPS Whitespace handling fix
> Update the xps point reading code to use strtod rather than atof;
> this returns us an updated string pointer, rather than relying
> on us second-guessing where it may end up.
> Change xps_get_point to return this updated pointer, and change some
> calls of this to avoid having to skip whitespace (and potentially
> getting it wrong) after the call.
> Spotted as part of the commit to take the latest XPS changes into
> MuPDF.
> xps/ghostxps.h
> xps/xpspath.c

2012-01-26 15:17:34 +0000
Ken Sharp <ken.sharp@artifex.com>
8eb237bc17ea481f75f482288c854ca42b31466b

> ps2write - do not allow Widths aray to alter /.notdef width.
> The way the Widths array works, if the Encoding has a /.notdef entry then
> the width of the /.notdef is altered to that width.
> If we have an earlier re-assignment, this breaks the assigned width.
> The file catx1490.pdf relies on a ./notdef to draw a 'box' (crazy but
> that's what it does). If we redefine the width tehn it is incorrect.
> Expected differences
> Catx1490.pdf
> Bug691221.pdf
> Bug689757.pdf
> THe latter two are minor differences, but slight progressions
> gs/base/opdfread.h
> gs/lib/opdfread.ps

2012-01-26 11:07:06 +0000
Chris Liddell <chris.liddell@artifex.com>
043a20124c63ee48f874e8a9d869098d099c6d19

> Have the "configure" build cope with missing "contrib"
> For the Artifex commercial release, we remove the files from the contrib
> directory. This meant a successful build had to be "configured" with the
> --without-contrib option.
> Now, configure looks for a specific file in "contrib", and if it is not there
> the contributed drivers are automatically disabled.
> No cluster differences.
> gs/base/configure.ac

2012-01-25 19:58:52 +0000
Robin Watts <robin.watts@artifex.com>
0fb4785ef74fd22b8c1cced5ec16bd28d5bcc666

> Fix Bug 692343 - ignore invalid padding length bytes.
> AES streams contain padding at the end to bring them up to 16
> byte chunks. The last byte of the plaintext is supposed to be
> a value between 1 and 16 telling us how many bytes to ignore
> from the last one? (Why 16? 15 would make more sense).
> If the padding byte was out of range we would previously have
> thrown an error. Here we change to just warn and set the
> padding length to 0. This means we'll err on the side of making
> the stream too long, which is better than the alternative.
> gs/base/saes.c

2012-01-25 19:21:08 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
845ac2669008d3c8daf6461c0fda3b0496d7443e

> Bug 691254: This patch prevents the seg fault in Jbig2_042_14.pdf.
> gs/jbig2dec/jbig2_symbol_dict.c
> gs/jbig2dec/jbig2_text.c

2012-01-25 08:14:22 +0000
Ken Sharp <ken.sharp@artifex.com>
679964341b8543bc37bf3cb783f12434af829f64

> ps2write - properly check number of components when converting Image type 3/4
> The code to limit optimisation of image type 3 or 4 into an imagemask was
> testing to see if the routine which returned the numebr of components in
> the colour space was a particular routine, instead of testing the return
> value of that routine to see if it was 1.
> Expected Differences
> Bug689717.pdf
> ImageProb2.pdf
> 12-07c.ps
> all now render correctly or (in the case of 12-07c.ps) exhibit useful
> progressions, when converted to PostScript using ps2write
> gs/base/gdevpdfi.c

2012-01-24 12:59:20 -0800
Michael Vrhel <michael.vrhel@artifex.com>
83ce7cf6c9252c39e280040b12db1dcfbd8a7cb2

> Fix for bug 692733. Pattern clist improperly cleared.
> The pattern code was performing an initial clear of the pattern. This is OK
> when the pattern is not a clist since the mask was not drawn in when this
> fill occurs (seee gx_erase_colored_pattern). Unfortunately this rect fill
> was getting into the pattern clist which is should not.
> gs/base/gxpcmap.c
> gs/psi/zpcolor.c

2012-01-24 16:44:07 +0000
Chris Liddell <chris.liddell@artifex.com>
1fab5a6b3945ba46fadd326e01f25e94f8af0886

> Note that we patch lcms2 in thirdparty.htm
> CLUSTER_UNTESTED
> gs/doc/thirdparty.htm

2012-01-24 16:22:41 +0000
Chris Liddell <chris.liddell@artifex.com>
345be99ff34a6023dd28c06869ff8db41a3c640c

> Add a file detailing our use of third party libraries.
> Including, name, version, purpose, license and URL.
> CLUSTER_UNTESTED
> gs/doc/thirdparty.htm

2012-01-24 13:20:11 +0000
Robin Watts <robin.watts@artifex.com>
fb56842749e5430ed18d938eb78d1cf24c3e9759

> Tweak jbig2dec to cope better with NULLs.
> Fix various destructors in jbig2dec to cope with being called
> with image = NULL. This cures a problem in mupdf where it SEGVs
> when called on "1239 - skip invalid content streams.pdf" from the
> sumatra test set.
> gs/jbig2dec/jbig2_image.c

2012-01-24 12:03:43 +0000
Chris Liddell <chris.liddell@artifex.com>
a92b0c487e0e003a6a69b93acb7c1ef84d2f9683

> Add details to Make.htm about Luratech
> Make it clear that if there, Luratech will be used automatically.
> Add details about disabling automatic Luratech inclusion.
> CLUSTER_UNTESTED
> gs/doc/Make.htm

2012-01-24 11:49:43 +0000
Chris Liddell <chris.liddell@artifex.com>
672fba9c5396ff7079e166a7535b879deffd801a

> Bug 691184: update doc and example for getenv in cidfmap
> Add information to the cidfmap section of Use.htm mentioning the ability to
> use "getenv" to influence paths to font files in cidfmap.
> And fix the example in cidfmap.
> CLUSTER_UNTESTED
> gs/Resource/Init/cidfmap
> gs/doc/Use.htm

2012-01-24 11:44:34 +0000
Chris Liddell <chris.liddell@artifex.com>
997f750a5dd4cf70b18d011e3297dd7c8f4abd97

> Bug 692810: fix OpenJPEG section of configure --help
> I forgot to reverse the logic of the help message when I made OpenJPEG the
> default JPEG2000 decoder - so the option is now to *disable* it.
> No cluster differences.
> gs/base/configure.ac

2012-01-23 22:52:33 -0800
Michael Vrhel <michael.vrhel@artifex.com>
1f3469404c599093df2e6c8157ac70111b0c80e2

> Revert "Addition of objects to support the output intent."
> This reverts commit 89546758c858d53c105dfc73fc4d108171b8437d.
> Something appears to be wrong with this when I was doing some other testing
> although it did ok in the cluster push.
> gs/base/gdevp14.c
> gs/base/gscms.h
> gs/base/gsdparam.c
> gs/base/gsequivc.c
> gs/base/gsicc_manage.c

2012-01-23 09:59:35 -0800
Michael Vrhel <michael.vrhel@artifex.com>
89546758c858d53c105dfc73fc4d108171b8437d

> Addition of objects to support the output intent.
> This doesn't do anything yet. There will be another commit for the
> PDF interpreter to make use of these objects.
> gs/base/gdevp14.c
> gs/base/gscms.h
> gs/base/gsdparam.c
> gs/base/gsequivc.c
> gs/base/gsicc_manage.c

2012-01-23 11:12:04 +0000
Ken Sharp <ken.sharp@artifex.com>
315a899b2f9bd8be2f247550a05d807a8c698f07

> ps2write/pdfwrite - Don't arbitrarily change VVECTOR0 flag in type 1 info
> Way back in 2003 code was added 'in lieu of proper CDevProc processing' to
> alter the behaviour of pdfwrite. In particular a flag was set which always
> causes pdfwrite to handle width chnages.
> However, we do now handle CDevProc correctly, and the arbitrary assignment
> of this flag causes serious problems for pdfwrite & ps2write in the
> (admittedly rare and unreasonable) case where the FontMatrix of an already
> used font is modified.
> Expected Differences:
> 14-12.ps
> 16-05.ps
> Both now work better with ps2write and pdfwrite, though not 100% correct
> gs/base/gxtype1.c

2012-01-21 14:07:15 -0500
Alex Cherepanov <alex.cherepanov@artifex.com>
d0d411c0830b81fa9fb38e3f938ac855fde9a6e3

> Bug 692798: Ignore the request for undefined color space.
> Ignore the attempt to set an undefined color spece resource,
> issue a warning, and continue.
> gs/Resource/Init/pdf_draw.ps

2012-01-18 12:32:13 -0800
Michael Vrhel <michael.vrhel@artifex.com>
eaaa284dcd5901de156c52c0dc0aff78816e4b81

> Fix for bug 692787. Rending Intent aliased with Blending mode in clist
> When I had added the rendering intent into the clist misc parameters I did not
> have enough bits to fit everything into a single byte.
> gs/base/gxclpath.c
> gs/base/gxclrast.c

2012-01-20 15:26:15 +0000
Chris Liddell <chris.liddell@artifex.com>
cf6946a1762b975a0450e0d11bdcb13889cdd877

> Add a note about building on Mac.......
> .....with MacPorts installed.
> CLUSTER_UNTESTED
> gs/doc/Make.htm

2012-01-18 09:31:53 -0800
Ray Johnston <ray.johnston@artifex.com>
5e7702813865b8c149f7a8462491d4ca72e70e8e

> Fix pdfwrite and other vector devices for changing filename and separate pages
> Previously vector devices did not allow changing OutputFile and (most) did not support the %d
> OutputFile to generate single page files (pswrite was the exception). The function used by
> pswrite was generalized and renamed gx_outputfile_is_separate_pages for general use. If this
> returns true vector devices will close and reopen after each page. The PageCount will then be
> used in the formation of the filename for the next page.
> Since vector devices open an write the OutputFile when the device is opened the file will be
> written even if there is no input, and if a format specifier is used in the OutputFile, then
> an extra blank page will be written (maybe this will be fixed later).
> For example, now pdfwrite can be used in server mode by changing the OutputFile device param
> which will cause the current collection of pages to be written to the PDF file, and a new
> PDF will be started. This is most useful from gsapi calls, but creating two PDF's from one
> invocation of gs via the command line would be:
> gs -sDEVICE=pdfwrite -o tiger.pdf examples/tiger.eps \
> -c "<< /OutputFile (colorcir.pdf) >> setpagedevice" \
> -f examples/colorcir.ps
> gs/base/gdevpdf.c
> gs/base/gdevps.c
> gs/base/gdevpx.c
> gs/base/gdevsvg.c
> gs/base/gdevvec.c
> gs/base/gsdevice.c
> gs/base/gxdevice.h
> gs/doc/Ps2pdf.htm
> gs/doc/Use.htm

2012-01-19 10:37:43 +0000
Chris Liddell <chris.liddell@artifex.com>
7d0f46b66b275c794dd87525e066e84ccabb4f96

> Bug 692801: Fix build with shared lcms2 and "so" target
> The targets for the lcms2 integration were mixed up, meaning the shared
> lib build had a couple of dependencies on our "local" lcms2 source files.
> The "so" target failed because the compiler for the lcms2 integration
> code used the wrong compiler variable (and consequently dropped some
> vital flags).
> No cluster differences.
> gs/base/lib.mak

2012-01-19 09:41:53 +0000
Ken Sharp <ken.sharp@artifex.com>
a75b5a720684d6e599c28cae9abb9357aa97d7b3

> ps2write - alter /NumCopies handling.
> Previously we mimicked /NumCopies and /#copies by using copypage. This is
> unreliable because copypage differs on level 3 devices and won't work as
> expected. Also it breaks DSC compliance and is probably undesirable with
> other PostScript processors such as CUPS.
> This commit alters the behaviour so that we use copypage only if the flag
> DoNumCopies is true *and* we ProduceDSC is not true. This changes the
> default to match pdfwrite and what I think is most logical while preserving
> the ability to use copypage in environments where its use can be supported.
> Expected Differences
> Any files using /NumCopies or /#copies will behave differently, producing
> fewer (blank!) pages than before. In our test suite I think this only
> affects the Quality Logic files. In particular 268-03.ps and 29-07b.ps
> gs/base/gdevpdf.c
> gs/doc/Ps2ps2.htm

2012-01-18 12:24:15 -0700
Henry Stiles <henry.stiles@artifex.com>
2a7bf50f7cb797b0f3213eb091960700c0ff50e6

> Integrates the new URW WingDing font.
> For reasons unknown URW has named the font NewDingbats. This will
> result in many healthy progressions in the regression test suite.
> pl/plftable.c
> urwfonts/NewDingbats.ttf

2012-01-18 12:05:36 -0700
Henry Stiles <henry.stiles@artifex.com>
71bb3ba36e2d15ec409185c69716c7cf40b89ea2

> Prevent double file close on font file.
> Introduced with the recent change to close font files at
> initialization. If a file in the font directory could not be found in
> the font table (was not a known font) the file would be closed twice.
> pl/pllfont.c

2012-01-18 10:22:47 -0700
Henry Stiles <henry.stiles@artifex.com>
406c8ff0f0414294e52d27d706db51dd11f83725

> PJL support for the resolution variable.
> The PJL resolution variable is now properly supported, for example "PJL
> SET RESOLUTION = 300" will see the resolution for the next job to 300
> but will be overridden if -r is given directly on the command line.
> Note the PJL resolution is only one value, there is no way to specify
> asymmetric resolution as there is with the -r option.
> pcl/pcjob.c
> pcl/pcstate.h
> pcl/pctop.c
> pl/pjparse.c
> pl/plmain.c
> pl/plmain.h
> pl/pltop.h

2012-01-17 14:45:50 -0700
Henry Stiles <henry.stiles@artifex.com>
b3e60553237af409e4d23d5c8dd39eb136665752

> Close PCL font files after initial read.
> Upon startup PCL reads all the font files to gather attribute
> information but the files were being left open wasting file handles.
> This change closes the files.
> pl/pllfont.c

2012-01-17 14:42:43 -0700
Henry Stiles <henry.stiles@artifex.com>
5ad194fca3c799f3928d714567a17c5d8361a424

> Reverts 3ab47d0e1e357a16cf5b35747b10b26d99b4d6f0, bad fix.
> Now that we have a larger corpus of hpgl/2-rtl files it is clear this
> fix cannot be right, something must have been wrong with the analysis,
> unfortunately the, referenced test file from the logs ("sprinkler")
> seems to be gone.
> pcl/pcjob.c

2012-01-12 15:31:35 -0700
Henry Stiles <henry.stiles@artifex.com>
39eb74a7a55793f6acdc473efd014a95a93f7542

> Shell script to convert HPGL/2-RTL to PDF.
> Aside from the obvious purpose of converting hpgl/2 files to pdf, the
> script demonstrates how to use the bounding box device to find the
> extant of the graphics in the gl/2 file and then use those bounding
> box coordinates to defiine a plot size for the file so there is no
> white space margin. This is commonly needed as the plot size command
> in GL/2 files specifies a plot much larger than needed.
> tools/plot2pdf.sh

2012-01-12 12:07:37 -0700
Henry Stiles <henry.stiles@artifex.com>
dbab71fabce6bdeda5f478a077f739457e88f542

> Refines '-J' option to process Exit Language properly.
> The previous set up sent a truncated string to the PJL parser so Exit
> Language was never returned. Now all the output is sent and the Exit
> Language code is required otherwise an error is returned.
> pl/plmain.c

2012-01-12 09:47:07 -0700
Henry Stiles <henry.stiles@artifex.com>
84cb959e0a2ed1cb0a898b8e2bebf120f55ebc57

> Allow multiple PJL commands with the -J option.
> Previously only 1 PJL command could be issued on the command line with
> the -J option. Now multiple commands may be issued by separating
> commands with a semicolon:
> pcl6 -lRTL -J"@PJL DEFAULT PLOTSIZEOVERRIDE=ON;\
> @PJL DEFAULT PLOTSIZE1=10000;@PJL DEFAULT PLOTSIZE2=8000"
> Unfortunately, the odd behavior of HP's PJL parser does not allow
> whitespace before "@PJL" which should start a new command each on a
> different line, similarly there can be no leading white space at the
> beginning or after a semicolon.
> pl/plmain.c

2012-01-18 10:27:40 +0000
Chris Liddell <chris.liddell@artifex.com>
0c2d126b790a81d2f9338834429cc46fcc84dab2

> Bug 692788: Wrong and missing manpage links in unixinst.mak
> Patch from Stefan Bruens ( stefan.bruens@rwth-aachen.de ).
> No cluster differences.
> gs/base/unixinst.mak

2012-01-18 08:33:00 +0000
Chris Liddell <chris.liddell@artifex.com>
25198491321b0540910d9aaa6dcc4367f2098dab

> Bug 692789: add some buffer limit protection.
> In one place add buffer overrun protection and error out, and in another,
> error out if the incoming string is greater than the buffer length (in this
> case there would be no buffer overrun, as we only read a buffer full of
> data).
> No cluster differences.
> gs/base/echogs.c

2012-01-16 11:23:18 +0000
Chris Liddell <chris.liddell@artifex.com>
91f728c058e3ab4705e53916d07597c7a755c730

> Fix pdfwrite's stringwidth for text rendering mode 3
> pdfwrite provides it's own "low level" stringwidth code, which includes code to
> convert the resulting coordinates into user space. Unexplicably, this
> conversion to user space was *not* applied when text rendering more 3 was in
> force.
> This caused a problem for a pending enhancement.
> No cluster differences.
> gs/base/gdevpdte.c

2012-01-16 10:19:50 +0000
Ken Sharp <ken.sharp@artifex.com>
3efaa3a6fabad09a4442f281fdbccc33f0474ea0

> ps2write - Prevent charpath optimisation to Tr for ps2write
> As a legacy of the old Text rendering mode code there is an optimisation in
> pdfwrite which detects sequences such as "true charpath gsave fill grestore
> stroke" and converts them to Text rendering mode 2.
> However, ps2write doesn't support text rendering modes, so if the colour changes
> then this produces incorrect output.
> Disabling the optimisation when the device is ps2write cures the problem.
> Expected Differences
> Progressions in:
> Bug687817.ps
> Bug690164.ps
> Catx6562.pdf
> Small (single pixel) diffferences in a number of files due to the emission
> of a path rather than executing charpath.
> gs/base/gdevpdfd.c

2012-01-13 10:16:03 -0800
Michael Vrhel <michael.vrhel@artifex.com>
85a94168a4e64199b5a237dbf0d262f5e457440f

> Fix typo in document. 9.05 not 9.5
> gs/doc/GS9_Color_Management.pdf
> gs/doc/GS9_Color_Management.tex

2012-01-13 10:40:50 -0700
Henry Stiles <henry.stiles@artifex.com>
a9e65e32b4a12c0f5de8ed6a3dcd38b3216f3ae1

> Bug 691230, basic jbig2 halftone image support.
> Thanks to George Gottleuber for this work.
> gs/base/jbig2.mak
> gs/jbig2dec/jbig2_halftone.c
> gs/jbig2dec/jbig2_halftone.h
> gs/jbig2dec/jbig2_mmr.c
> gs/jbig2dec/jbig2_mmr.h
> gs/jbig2dec/jbig2_segment.c

2012-01-13 14:23:19 +0000
Robin Watts <robin.watts@artifex.com>
993377ba237144726cd25e2d8851c70090370dd4

> Optimise TetrahedralInterp16 in lcms2
> Port Michaels optimisations from lcms1, and further tweak
> for speed.
> gs/lcms2/src/cmsintrp.c

2012-01-13 13:45:44 +0000
Chris Liddell <chris.liddell@artifex.com>
8e03b7f4769120ba60224cc6484b8766b386e054

> Better lcms2 support in autoconf build
> Make reverting to lcms a configure option, make lcms2 the default in configure
> allow linking of the system lcms2.
> Improve the feedback a little.
> No cluster differences.
> gs/base/Makefile.in
> gs/base/configure.ac

2012-01-13 01:02:52 +0000
Robin Watts <robin.watts@artifex.com>
4e400364e182ae838a9a844ea40c4cca8d33bc09

> Silence lcms2 warnings.
> Make a few functions static. Announce some in the headers.
> Fix some #ifdefferey.
> gs/base/gsicc_lcms2.c
> gs/lcms2/include/lcms2.h
> gs/lcms2/src/cmspack.c
> gs/lcms2/src/cmstypes.c
> gs/lcms2/src/cmsxform.c
> gs/lcms2/src/lcms2_internal.h

2012-01-12 16:05:09 -0800
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
cf11f0f7e68ac576138e49ab8d2c05a0121c6997

> Change default cms to be lcms2 (for autogen.sh builds).
> Continuation of commit 319474974fe4ddb99d29e8d3976afcc25f0e54ba.
> gs/base/Makefile.in

2012-01-12 11:22:18 -0800
Michael Vrhel <michael.vrhel@artifex.com>
8aa37658b48f4fbda7551598f8de216f2d3dd33d

> Update of color documentation
> The new document includes several figures. Rather than clutter the tree with the additional figures that LaTeX uses in creating the pdf, I removed the figures folder. The new LaTeX file uses PDFLaTeX to create the pdf rather than the dvi2ps approach.
> gs/doc/GS9_Color_Management.pdf
> gs/doc/GS9_Color_Management.tex
> gs/doc/figures/Ghost.eps
> gs/doc/figures/Overview.eps

2012-01-12 15:23:20 +0000
Ken Sharp <ken.sharp@artifex.com>
afad2d730c8f5f6137791259fab3c45fda0f6862

> ps2write - When converting shaded fills to image+clip, preserve insidenes rule
> ps2write cannot preserve a fill with a Shading pattern, so it converts these
> to an image and a clip (the path to fill is converted to a clip path).
> However it did not preserve the 'insideness' winding rule which meant that
> both eofill and fill were converted to 'clip' when eofill should be converted
> to eoclip.
> Expected Differences
> fts_31_3110.pdf
> fts_31_3115.pdf
> fts_31_3118.pdf
> 09-47A.ps
> 09-47B.ps
> 09-47C.ps
> 09-47D.ps
> 09-47E.ps
> 09-47G.ps
> 09-47H.ps
> 09-47I.ps
> 09-47J.ps
> 09-47K.ps
> 09-47L.ps
> 09-47M.ps
> 18-02A.ps
> 18-02B.ps
> 18-02F.ps
> 23-12W.ps
> All show progressions with ps2write
> gs/base/gdevpdfd.c

2012-01-11 11:25:41 +0000
Robin Watts <robin.watts@artifex.com>
f6b83ef318aaf22b84cdeca55ba40208b9c3caad

> Port color transform speedups from lcms1 to lcms2.
> Use a chameleonic header file to generate optimised transform
> functions.
> gs/base/lcms2.mak
> gs/lcms2/src/cmspack.c
> gs/lcms2/src/cmsxform.c
> gs/lcms2/src/cmsxform.h

2012-01-10 14:41:36 -0700
Henry Stiles <henry.stiles@artifex.com>
defb2b18e49123f4cad571070156a27ece868652

> Adds the bbox device.
> main/pcl6_gcc.mak
> main/pcl6_msvc.mak

2012-01-10 21:16:10 -0800
Michael Vrhel <michael.vrhel@artifex.com>
f50368d684e84fe63579494b3e3efe0e4f39f98c

> Clean up of the icc color code.
> Remove objects and redundant functions that were introduced over the
> past couple years. Found these while writing the documentation.
> gs/base/gdevpdfi.c
> gs/base/gdevpsd.c
> gs/base/gdevrinkj.c
> gs/base/gdevxcf.c
> gs/base/gscms.h
> gs/base/gscsepr.c
> gs/base/gsicc.c
> gs/base/gsicc_cache.c
> gs/base/gsicc_cache.h
> gs/base/gsicc_cms.h
> gs/base/gsicc_lcms.c
> gs/base/gsicc_lcms2.c
> gs/base/gsicc_manage.c
> gs/base/gsicc_manage.h
> gs/base/gsicc_nocm.c
> gs/base/gxcmap.c
> xps/xpsgradient.c

2012-01-10 18:27:46 -0800
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
9e2df6f6194c5091dbfc6bde2218569645f5c89a

> Make fuzzy not seg fault when comparing images of different sizes.
> Horrible hack to allow fuzzy to compare two files that have different
> dimensions (necessary when compareing outupt from muPDF vs. Ghostscript).
> gs/toolbin/tests/fuzzy.c

2012-01-10 23:05:58 +0000
Robin Watts <robin.watts@artifex.com>
319474974fe4ddb99d29e8d3976afcc25f0e54ba

> Change default cms to be lcms2 (for non-windows builds)
> Forgot to change the unix builds. Expect lots of small changes in
> the cluster.
> common/ugcc_top.mak
> gs/base/macos-mcp.mak
> gs/base/macosx.mak
> gs/base/openvms.mak
> gs/base/unix-gcc.mak
> gs/base/unixansi.mak

2012-01-10 22:24:35 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
c0573245db4f03c6cdca24906d73151a4e9be3c9

> Bug 691267: Check all realloc error paths.
> gs/base/sjbig2.c
> gs/jbig2dec/jbig2.c
> gs/jbig2dec/jbig2_huffman.c
> gs/jbig2dec/jbig2_page.c
> gs/jbig2dec/jbig2_symbol_dict.c
> gs/jbig2dec/jbig2_text.c

2012-01-10 22:09:28 +0000
Robin Watts <robin.watts@artifex.com>
4e1c54b4c4cbc12185e44a758dcfae8f6095fa6c

> Add 2 more files missing from solution.
> CLUSTER_UNTESTED.
> gs/ghostscript.vcproj

2012-01-10 22:08:28 +0000
Robin Watts <robin.watts@artifex.com>
9d23e07f6895eb581eaea17bf812be9f89d207b3

> Change default cms to lcms2.
> Expect lots of small changes.
> gs/base/winlib.mak

2012-01-10 19:47:56 +0000
Robin Watts <robin.watts@artifex.com>
2468c2bce2ae03750ccab220b16fa6a62b31135f

> Move icc34.h from lcms directory to gs/base
> It's not supplied as part of the lib, and we need it for lcms,
> lcms2, the non-cmm cmm and the creation tools, so having it
> somewhere central seems sensible.
> gs/base/icc34.h
> gs/base/lcms.mak
> gs/base/lcms2.mak
> gs/base/lib.mak
> gs/lcms/include/icc34.h

2012-01-10 19:45:25 +0000
Robin Watts <robin.watts@artifex.com>
d1a09075987875224abdaf8d6c62fdf40895ba98

> LCMS2 fix: MSVC version check uses <= rather than <
> Checking for <= 1400 includes VS2005. The intent is to only include
> VS2003. Change to < and all is well.
> gs/lcms2/src/lcms2_internal.h

2012-01-10 19:16:34 +0000
Robin Watts <robin.watts@artifex.com>
df2872f8b3cff582871ae15f4c3221bcb6e607fc

> Add lcms2 entries to Visual Studio Solution.
> Doesn't make any difference to building - just enables us to search
> for code etc more easily.
> gs/ghostscript.vcproj

2012-01-10 10:55:10 -0800
Michael Vrhel <michael.vrhel@artifex.com>
3996236547b4f6b2c4e0d60cd7b4196c33123ac0

> Update of our lcms2 directory to 2.3 release
> gs/lcms2/AUTHORS
> gs/lcms2/ChangeLog
> gs/lcms2/Projects/BorlandC_5.5/lcms2.rc
> gs/lcms2/Projects/VC2008/lcms2.rc
> gs/lcms2/Projects/VC2010/lcms2.rc
> gs/lcms2/Projects/mac/.DS_Store
> gs/lcms2/Projects/mac/LittleCMS/.DS_Store
> gs/lcms2/bin/Bin.txt
> gs/lcms2/bin/Thumbs.db
> gs/lcms2/configure
> gs/lcms2/configure.ac
> gs/lcms2/doc/LittleCMS2.0 API.pdf
> gs/lcms2/doc/LittleCMS2.0 Plugin API.pdf
> gs/lcms2/doc/LittleCMS2.0 tutorial.pdf
> gs/lcms2/doc/LittleCMS2.1 API.pdf
> gs/lcms2/doc/LittleCMS2.1 Plugin API.pdf
> gs/lcms2/doc/LittleCMS2.1 tutorial.pdf
> gs/lcms2/doc/LittleCMS2.3 API.pdf
> gs/lcms2/doc/LittleCMS2.3 Plugin API.pdf
> gs/lcms2/doc/LittleCMS2.3 tutorial.pdf
> gs/lcms2/doc/src.zip
> gs/lcms2/include/icc34.h
> gs/lcms2/include/lcms2.h
> gs/lcms2/lcms2.pc.in
> gs/lcms2/src/cmscgats.c
> gs/lcms2/src/cmscnvrt.c
> gs/lcms2/src/cmserr.c
> gs/lcms2/src/cmsio1.c
> gs/lcms2/src/cmslut.c
> gs/lcms2/src/cmsnamed.c
> gs/lcms2/src/cmsopt.c
> gs/lcms2/src/cmspack.c
> gs/lcms2/src/cmsplugin.c
> gs/lcms2/src/cmssm.c
> gs/lcms2/src/cmstypes.c
> gs/lcms2/src/cmsvirt.c
> gs/lcms2/src/cmswtpnt.c
> gs/lcms2/src/cmsxform.c
> gs/lcms2/src/lcms2.def
> gs/lcms2/src/lcms2_internal.h
> gs/lcms2/testbed/USWebCoatedSWOP.icc
> gs/lcms2/testbed/UncoatedFOGRA29.icc
> gs/lcms2/testbed/sRGBSpac.icm
> gs/lcms2/testbed/sRGB_Color_Space_Profile.icm
> gs/lcms2/testbed/sRGB_v4_ICC_preference.icc
> gs/lcms2/testbed/test1.icc
> gs/lcms2/testbed/test2.icc
> gs/lcms2/testbed/test3.icc
> gs/lcms2/testbed/test4.icc
> gs/lcms2/testbed/test5.icc
> gs/lcms2/testbed/testcms2.c
> gs/lcms2/utils/common/vprf.c
> gs/lcms2/utils/delphi/lcms2.dll
> gs/lcms2/utils/linkicc/linkicc.c
> gs/lcms2/utils/samples/roundtrip.c
> gs/lcms2/utils/tificc/tificc.c
> gs/lcms2/utils/transicc/transicc.c

2012-01-09 11:06:41 -0700
Henry Stiles <henry.stiles@artifex.com>
20a53310422c41df4f48deef3f704b39c291a5f2

> PLOTSIZEROTATE is no longer used with the current scheme to initialize
> HPGL-2/RTL (see last few commits).
> CLUSTER_UNTESTED
> pl/pjparse.c

2012-01-09 10:48:58 -0700
Henry Stiles <henry.stiles@artifex.com>
96726af52822d442cceb1531c1d12bd6141ac322

> The previous standalone GL/2 mode is incompatible with how the
> transformations are set up in PCL. We have found that plots for
> standalone mode can be viewed properly in HPGL-2/RTL mode. We think
> this is the best alternative for now, if we get into the business of
> emulating individual plotters the issue can be revisited.
> pcl/pgdraw.c

2012-01-08 12:57:46 -0700
Henry Stiles <henry.stiles@artifex.com>
1e6d68e396ec5842af5b8cb5cb226c9de1f46d31

> The HPGL-2/RTL work of the last few commits introduce a regression -
> disabling bound coordinates in normal PCL mode.
> pcl/pgdraw.c

2012-01-07 22:09:50 -0700
Henry Stiles <henry.stiles@artifex.com>
d18b90db02540b1bf1005537aa38b42ef2486f43

> Implements transformations and clipping needed by HPGL/2-RTL. The
> previous setup was only appropriate for HPGL standalone mode and only
> appeared to work based on the small number of example files we had at
> the time.
> pcl/pcpage.c
> pcl/pgconfig.c
> pcl/pgdraw.c

2012-01-07 22:02:59 -0700
Henry Stiles <henry.stiles@artifex.com>
9f40ae210f923553413e44135e796fcb981ec34e

> Presentation mode 3 and clipping when the cap is coincident with the
> logical page is not seen in the HPGL-2/RTL examples we have. There
> might be something more complicated going on here, it would be
> difficult to determine without a device to run experiments.
> pcl/rtgmode.c

2012-01-07 21:58:50 -0700
Henry Stiles <henry.stiles@artifex.com>
3687f6b4cbafd91d5f29c604f86a56a5b118001f

> Support the geometry option on the command line, note this really
> duplicates the functionality of setting a media size using PJL, but we
> implement it anyway because users prefer the familiarity of the
> option.
> pcl/pcpage.c
> pcl/pcstate.h
> pcl/pctop.c
> pl/plmain.c
> pl/plmain.h
> pl/pltop.h

2012-01-07 21:35:57 -0700
Henry Stiles <henry.stiles@artifex.com>
275066d79d9f01a90f0fd91bc8448c5746cbac2c

> The default top and left margin are 0 in HPGL-2/RTL mode, not the standard
> PCL values.
> pcl/pcpage.c

2012-01-07 21:09:37 -0700
Henry Stiles <henry.stiles@artifex.com>
5a1eda769a573ef37e2930502c25bfab8d1fb457

> The transformation setup for HPGL-2 and RTL was really only correct
> for standalone mode (GL only). So we have to save the entry operand
> to the "Enter HPGL/2 command" in the state so it can be used when the
> transformation matrices are recalculated.
> pcl/pcommand.c
> pcl/pcstate.h
> pcl/pgdraw.c
> pcl/rtmisc.c

2012-01-07 20:50:17 -0700
Henry Stiles <henry.stiles@artifex.com>
9632b092e1d3ea35c855ae1ccba78fd2e4695d9a

> Remove unnecessary warning of dubious origin.
> CLUSTER_UNTESTED
> pcl/pcursor.c

2011-12-20 18:19:40 -0700
Henry Stiles <henry.stiles@artifex.com>
9d5c4a0e75e89618e08418ec50809bcbc9886fcf

> Conditionalize a debug message.
> CLUSTER_UNTESTED
> pl/plfont.c

2011-12-20 11:45:52 -0700
Henry Stiles <henry.stiles@artifex.com>
bddfe691c7caae4653cb9ad46645443274fe42a2

> The new ICC flow does not require CRD's and we now do not selectively
> choose halftones based on setting from the palette vs. the foreground,
> the latter, an implemented but never used feature.
> pcl/pcdraw.c
> pcl/pcht.c
> pcl/pcht.h
> pcl/pcpatrn.c
> pcl/pgdraw.c

2012-01-08 16:32:03 -0500
Alex Cherepanov <alex.cherepanov@artifex.com>
acf3f93fa0b9b0b0af938d0517045446e0d94042

> Add missing '\n' before EOF.
> Add missing '\n' to the last line of gdevp14.c.
> This caused compilation errors on MSVC 7.
> gs/base/gdevp14.c

2012-01-06 12:14:15 +0000
Ken Sharp <ken.sharp@artifex.com>
de1badc8e7dcf9b2728f46c5a187a2b76a1bf682

> ps2write - Properly handle masked images with interpolation
> ps2write converts type 3 and 4 (masked) images into an image and clip
> combination. The clip is created from the mask, and the image is rendered
> to a memory device. Note that the memory device canvas is just large enough to
> contain the image.
> The image is drawn as a series of rectangular fills, and our 'local conveter'
> device shifts these from the original page location to the correct (relocated to 0,0)
> position in the memory device.
> However, if interpolation is true for the image, then we don't get a series
> of rectangular fills, we get a 'copy_color' instead which the converter
> device didn't handle. Adding a copy_color method which properly translates the
> image position solves the problem.
> Expected Differences
> Progressions in Bug691210.pdf, 12-07B.ps and 12-07C.ps
> gs/base/gdevpdfd.c
> gs/base/gdevpdfx.h

2012-01-06 11:49:13 +0000
Chris Liddell <chris.liddell@artifex.com>
62633d12eb583116c0a0e1f888c283977cb593b2

> Bug 692764: check Freetype is new enough
> We must use Freetype v 2.4.0 at the earliest, so configure will now check that
> if being asked to use a shared Freetype lib.
> Add a configure check for Freetype shared lib that doesn't depend on pkg-config.
> Move the warning about falling back to the deprecated AFS code to the end of
> the configure output.
> No cluster differences.
> gs/base/configure.ac

2012-01-05 22:09:09 -0800
Michael Vrhel <michael.vrhel@artifex.com>
c3bf6f733b8aed99f2a87058b8689c063beae9a0

> Fixed missing Rendering Intent Override in gs_lev2.ps
> In creating some examples and writing the documentation I
> discovered that this was missing and so none of the
> rendering intent settings were working.
> gs/Resource/Init/gs_lev2.ps

2012-01-05 13:41:17 -0800
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
da508b027e16d926f2e200fd6ff17d58f3392855

> Added the ability to clusterpush.pl mupdf.
> This feature is still largely untested and known problems remain,
> in particular there is an issue with the wrong information in the
> email report for the first mupdf clusterpush following a ghostscript
> clusterpush.
> gs/toolbin/localcluster/clusterpush.pl

2012-01-05 10:05:51 -0800
Michael Vrhel <michael.vrhel@artifex.com>
f45061bbea6a75abe17187fd06b67ad36fc7e779

> Fix memory issue when creating source color structure
> One of the objects in the source color structure was getting allocated in
> GC memory where it should have been in non-GC memory.
> gs/base/gsicc_manage.c

2012-01-05 16:13:07 +0000
Robin Watts <robin.watts@artifex.com>
d3bd93d8da482714c30e58731829cac4f9e3510e

> Add RAW_DUMP_AS_PAM option.
> If RAW_DUMP_AS_PAM is enabled, then (where possible) we RAW_DUMP
> blends as pam rather than raw files. Easier for people without
> full photoshop to handle.
> gs/base/gxblend.c
> gs/base/gxblend.h

2012-01-03 17:50:07 +0000
Chris Liddell <chris.liddell@artifex.com>
e503591e1cc9d6f6c4c91fd5e0500df0cb6df21b

> Revise example in comments.
> Revise the example using "getenv" to correcly account for the return values of getenv.
> CLUSTER_UNTESTED
> gs/Resource/Init/cidfmap

2012-01-03 16:10:02 +0000
Chris Liddell <chris.liddell@artifex.com>
c974aa83b814e9bf9c3e1b29493edb8cd5ed8091

> Bug 692641 (again): prevent symbol name clash
> Another case where our "internal" SHA symbols could clash with the "real"
> OpenSSL ones if libgs is being statically linked. As before, trivial rename
> to avoid this (courtesy of Alan Hourihane - alanh@fairlite.co.uk).
> No cluster differences.
> gs/base/sha2.c

2012-01-03 13:08:07 +0000
Ken Sharp <ken.sharp@artifex.com>
d48a3d162fd38aaa2582e32565c07df41e7c02cb

> pdfwrite/ps2write - Properly validate BitsPerComponent for images
> Suprisingly (to me) the BitsPerComponent value for images is not validated
> at the interpreter (language) level, but is handled in the graphics library.
> pdfwrite and ps2write were not validating the BitsPerComponent, other than
> to check it was 8 or less, and so could create invalid images in the PDF or
> PostScritp output.
> This commit adds the missing checks.
> Expected Differences
> 12-07a.ps - ps2write no longer produces an invalid PostScript file
> 12-07a.ps - pdfwrite no longer produces an invalid PDF file
> 12-02.ps - ps2write no longer produces an invalid PostScript file
> 12-02.ps - pdfwrite no longer produces an invalid PDF file
> gs/base/gdevpdfi.c

2012-01-03 09:20:05 +0000
Ken Sharp <ken.sharp@artifex.com>
8cfb57fdd350cbda7578226b150ed0014d5949c9

> ps2write - fix uncoloured Pattern spaces with a complex colour space
> Certain kinds of colour space, eg /Separation, can have a function which
> converts to the alternate space. If one of these was used as the colour
> space for an uncoloured pattern then the function was not properly loaded
> from the object defuinition, leading to an invalid colour space declaration.
> This tests the initial space to see if it is /Pattern and if it is, checks
> to see if the pattern is uncoloured (the array contains more than /Pattern).
> If so we test the colour space and, if it is an array, process the array as
> a colour space, which properly dereferences all the elements.
> Expected Differences:
> 09-47a.ps, 09-47b.ps and 18-02b.ps should now work correctly.
> gs/base/opdfread.h
> gs/lib/opdfread.ps

2011-12-28 14:37:49 -0800
Michael Vrhel <michael.vrhel@artifex.com>
4e681a04de79896406946d5487efe0a37eb6d2b2

> Proof and DeviceLink ICC profile support
> This enables the use of the device link and/or a proofing profile. When
> present, the transformations are as follows
> src profile -> PCS -> proof -> PCS -> proof -> PCS -> device profile -> device link
> where PCS is the profile connection space. The CMM obviously would
> normally mash these together in a single transform. This is what
> occurs in lcms.
> This implies that the output color space for the device link
> profile must match the color model for the real target device and
> that the input color space for the device link profile must match
> the color space specified for the device profile.
> Still need to do some additional testing and update documentation.
> gs/base/gsicc.c
> gs/base/gsicc_cache.c
> gs/base/gsicc_cache.h
> gs/base/gsicc_cms.h
> gs/base/gsicc_lcms.c
> gs/base/gsicc_lcms2.c
> gs/base/gsicc_manage.c
> gs/base/gxi12bit.c
> gs/base/gxicolor.c
> gs/base/gximono.c
> gs/base/gxiscale.c

2011-12-22 09:55:25 -0800
Michael Vrhel <michael.vrhel@artifex.com>
d4625c5b5a262501fefabe68f2bbea000dcecb52

> Movement of proof profile an device link profile to device.
> The proofing profile and the device link profile are now in the device's
> profile structure. This makes it much easier to include in the proofing
> profile and/or the device link profile during the link transformation
> creation. This commit includes all the changes except for the actual
> creation of the link with the proof. That will come in a separate commit
> since there are a lot of changes in this commit and I want to spend
> a little more time on that to make it clean and
> dependent upon the capabilities of the CMM. The reason is that there are
> some CMMs that support the chaining together of multiple transformations and
> some that do not. Those that do not may not be able to handle both a
> proofing profile AND a device link profile. We want to handle that case
> gracefully.
> gs/Resource/Init/gs_lev2.ps
> gs/base/gdevp14.c
> gs/base/gdevpdfk.c
> gs/base/gscms.h
> gs/base/gsdparam.c
> gs/base/gsequivc.c
> gs/base/gsicc.c
> gs/base/gsicc_cache.c
> gs/base/gsicc_cache.h
> gs/base/gsicc_lcms.c
> gs/base/gsicc_manage.c
> gs/base/gsicc_nocm.c
> gs/base/gxcmap.c
> gs/base/gxi12bit.c
> gs/base/gxicolor.c
> gs/base/gximono.c
> gs/base/gxiscale.c
> gs/base/gxshade.c
> gs/psi/zusparam.c
> xps/xpsgradient.c

2011-12-23 11:50:08 -0800
Robin Watts <robin@peeves.(none)>
63571a25cbd787573f0c4918abe7c783f5e5209c

> Memento/Valgrind integration tweak.
> Ensure block header is set to be readable when reading blk->tail
> to avoid spurious read errors.
> gs/base/memento.c

2011-12-23 15:56:43 +0000
Ken Sharp <ken.sharp@artifex.com>
1430adef1955c8c85001b2fbcd371bfccfead179

> ps2write - Correct the DecodeLMN matrix creation for a CalGray -> CIEBasedA
> When converting a CalGray to a CIEBasedA dpace, the Gamma from the CalGray is
> used to create a DecodeLMN array. However the code only created a single
> executable array, when it is required to be an array of 3 procedures.
> Expected Diffrences
> 09-34.ps no longer fails when converted via ps2write
> gs/base/opdfread.h
> gs/lib/opdfread.ps

2011-12-23 08:06:18 +0000
Ken Sharp <ken.sharp@artifex.com>
b1ca1565f903490bd71dcc8182e69d4ab5eb6c3a

> Initialise a pointer to silence a compiler warning
> In fact this is benign, the code can't get here without previously allocating
> and initialising the pointer, but that takes place in another branch and
> static analysis can't reveal that.
> gs/base/gdevtxtw.c

2011-12-22 16:21:10 +0000
Ken Sharp <ken.sharp@artifex.com>
e758e15df0497f85c6843b57e65a6d7f072cf815

> Prevent a crash trying to get MissingWidth from sa non-CID font in txtwrite
> gs/base/gdevtxtw.c

2011-12-22 15:29:26 +0000
Ken Sharp <ken.sharp@artifex.com>
2eb7ab1f1e57d118259ae7bf2fce9c2872152478

> Txtwrite - initialise members of an array, silences compiler warning.
> gs/base/gdevtxtw.c

2011-12-22 14:45:17 +0000
Chris Liddell <chris.liddell@artifex.com>
b90f64665896669124bb6f219a77a556371c67c8

> Revise DisplayHandle documentation in API.htm
> CLUSTER_UNTESTED
> gs/doc/API.htm

2011-12-22 14:47:24 +0000
Ken Sharp <ken.sharp@artifex.com>
e391e19723bad3de19beb2fa584f0d9c8b62cac9

> Correctly read all parameters in put_params as well as get_params
> Fixes the txtwrite device with the language switch build
> gs/base/gdevtxtw.c

2011-12-22 12:42:53 +0000
Ken Sharp <ken.sharp@artifex.com>
1eb9f0069dce7d626118333fd51477d734daa88e

> Add the txtwrite device to PCL and language switch and supply a method
> for get_page_device in txtwrite (prevents SEGV)
> gs/base/gdevtxtw.c
> main/pcl6_gcc.mak
> main/pcl6_msvc.mak

2011-12-21 12:25:57 -0800
Michael Vrhel <michael.vrhel@artifex.com>
157a91639635abad452872cf521f743bbadb0c68

> Addition of debug output for icc color conversions
> To get detailed information about ICC profile allocations,
> mappings, profile creations from PS color objects and
> link creations use the command line option --debug=icc
> gs/base/gdbflags.h
> gs/base/gsciemap.c
> gs/base/gsicc.c
> gs/base/gsicc_cache.c
> gs/base/gsicc_manage.c
> gs/base/gxclthrd.c

2011-12-21 17:51:31 +0000
Chris Liddell <chris.liddell@artifex.com>
4e99a07ab13789ae7d561390bf0f07721fbf4917

> Clean up some target mess left over from earlier commit.
> I missed some changes from the removal of the old installer, some
> targets were still there which relied on the removed files.
> Also, a name didn't make any sense.
> CLUSTER_UNTESTED
> gs/psi/msvc.mak
> gs/psi/winint.mak

2011-12-21 17:07:45 +0000
Chris Liddell <chris.liddell@artifex.com>
2cba2590e1a8edfef6f0b13f8d392a756f889690

> Bug 692089 (prt 2): Update Install.htm with 64 bit versions of Windows binaries
> CLUSTER_UNTESTED
> gs/doc/Install.htm

2011-12-21 17:00:03 +0000
Chris Liddell <chris.liddell@artifex.com>
37053da2b828df8101be25eed9bfadf3c13dbd7b

> Bug 692089 (prt 1): install gssetgs.bat suitable for current installer.
> As the istaller knows whether it is installer the 32 bit or 64 bit version
> of Ghostscript, the installer now chooses between two gssetgs.bat versions
> so that the other batch files find the appropriate GS exe.
> CLUSTER_UNTESTED
> gs/lib/gssetgs32.bat
> gs/lib/gssetgs64.bat
> gs/psi/msvc.mak
> gs/psi/nsisinst.nsi

2011-12-21 16:56:47 +0000
Chris Liddell <chris.liddell@artifex.com>
a11f84267931e805148ed63025002851d3f3d2eb

> Remove source files for the old Ghostscript installer.
> CLUSTER_UNTESTED
> gs/psi/dwinst.cpp
> gs/psi/dwinst.h
> gs/psi/dwsetup.cpp
> gs/psi/dwsetup.h
> gs/psi/dwsetup.rc
> gs/psi/dwuninst.cpp
> gs/psi/dwuninst.h
> gs/psi/dwuninst.rc

2011-12-21 15:20:37 +0000
Chris Liddell <chris.liddell@artifex.com>
83b1e0429c3ab74da7dd1c9b78401671bac4d6f6

> Make OpenJPEG the default for JPXDecode.
> This introduces differences for all the cluster tests with JPX encoded image
> data in them.
> gs/base/configure.ac
> gs/psi/msvc.mak

2011-12-21 13:23:57 +0000
Chris Liddell <chris.liddell@artifex.com>
4bcc37370e97105ae3d4aff085b15541a7cd6a51

> Bug 692754: have configure setup endian setting for lcms
> The lcms header files have some educated guesses for the current platform
> big/little endianness, but they are not comprehensive (for example, PA-RISC
> HP UX defeats it).
> So, add a test to our configure scripts, and pass the setting as required as a
> compiler option for lcms. NOTE: I added an explicit test for endianness because
> the autoconf built-in test has problems in recent releases.
> Also, noticed in passing: revise the other explicit compile/link tests to use
> the AC_LANG_PROGRAM() macro - currently not doing so produces a warning, but
> the implication is future versions will throw an error.
> No cluster differences.
> config.mak.in
> configure.ac
> gs/base/Makefile.in
> gs/base/configure.ac
> gs/base/lcms.mak
> gs/base/lcms2.mak

2011-12-21 09:16:50 +0000
Ken Sharp <ken.sharp@artifex.com>
39182690d9d7242d7a8e6e2f5fe9aff52d0ee3ab

> ps2write - Use Font level Resources for type 3 font CharProcs
> Part of Bug #691928, file tpc2.ps. It is possible (in PDF) for a font to have
> Resources separately from teh page stream. This is properly catered for in
> PDF interpreters.
> However, ps2write's prolog only allowed resources defined at the page level
> when executing CharProc procedures from a type 3 font (because we are in the
> page stream at the time, not the font object).
> If the type 3 font executes findfont, and the font is not defined at the page
> level (often the case for the Quark q font and other substitutes) then the
> font cannot be found. Due to a quirk of the way fonts are defined, the *first*
> page to use the type 3 font always includes definitions for any fonts used by
> the type 3 font, so this problem only exhibits on mutiple page documents.
> This was tricky to fix, we cannot simply replace the Resources in the current
> Context, as we need to return to the pre-existing Context after running the
> CharProc. Additionally, type 3 fonts can execute other type 3 fonts which may
> themselves call other fonts. It was neccesary to implement a stack of saved
> resources in order to deal with this situation.
> Expected Differences
> tpc2.ps should now work properly with ps2write
> gs/base/opdfread.h
> gs/lib/opdfread.ps

2011-12-20 11:42:18 -0800
Michael Vrhel <michael.vrhel@artifex.com>
fa34b3ab12b15f5e1ace688f00c28a75667afdb4

> Fix for bug 691998 avoid the creation of the CRD cache.
> Since we are using ICC profiles to define the output color to not create the
> cache for the CRD.
> gs/psi/zcrd.c

2011-12-19 17:54:51 +0000
Chris Liddell <chris.liddell@artifex.com>
c85b3957cb896af69d8b7f630a56635cc0eb7a8c

> Revise the SSE2 tests to work with Sun cc compiler
> The Sun/Oracle C compiler doesn't throw an error when compiling SSE2 code
> without the requisite SSE2 command line option, and building non-
> optimized.
> This commit applies a more stringent test, and ensures we use the optimized
> build option when we do the test build/link.
> Also, adds some use feedback for the SSE2, byteswap intrinsic and byteswap
> header tests.
> No cluster differences.
> configure.ac
> gs/base/configure.ac

2011-12-19 15:33:01 +0000
Chris Liddell <chris.liddell@artifex.com>
6a4ff3a5c387f8958016b3678d919373c57ec5bd

> CIDFont substitution tweak for *Light,Bold fonts
> When we have to substitute for a "Light" style CIDFont which has been made
> bold, don't apply artificial emboldening unless the substitute font is
> also a "Light".
> No cluster differences.
> gs/Resource/Init/pdf_font.ps

2011-12-19 08:00:17 +0000
Ken Sharp <ken.sharp@artifex.com>
269ddabfb17657114b8e09b0c2fb2ee8440d92df

> Check a return code, silences a compiler warning and is more robust
> gs/base/gxfcopy.c

2011-12-17 14:08:37 -0500
Alex Cherepanov <alex.cherepanov@artifex.com>
464ef7f26f33b3f8a5d4c8732674e75a6aff39dc

> Bug 692747: Trap errors in operator sh and continue.
> Execute .shfill operator in a stopped contect, trap errors,
> issue a warning, and continue.
> gs/Resource/Init/pdf_draw.ps

2011-12-15 13:54:15 +0000
Chris Liddell <chris.liddell@artifex.com>
ea9a951756d495c6b8e427cbcea80fb94f9ccaa5

> Bug 687297: Revert to the URW fonts
> Revert to using the "pristine" URW fonts.
> Cluster differences: every job which uses one of the base 35 fonts.
> gs/Resource/Font/CenturySchL-Bold
> gs/Resource/Font/CenturySchL-BoldItal
> gs/Resource/Font/CenturySchL-Ital
> gs/Resource/Font/CenturySchL-Roma
> gs/Resource/Font/Dingbats
> gs/Resource/Font/NimbusMonL-Bold
> gs/Resource/Font/NimbusMonL-BoldObli
> gs/Resource/Font/NimbusMonL-Regu
> gs/Resource/Font/NimbusMonL-ReguObli
> gs/Resource/Font/NimbusRomNo9L-Medi
> gs/Resource/Font/NimbusRomNo9L-MediItal
> gs/Resource/Font/NimbusRomNo9L-Regu
> gs/Resource/Font/NimbusRomNo9L-ReguItal
> gs/Resource/Font/NimbusSanL-Bold
> gs/Resource/Font/NimbusSanL-BoldCond
> gs/Resource/Font/NimbusSanL-BoldCondItal
> gs/Resource/Font/NimbusSanL-BoldItal
> gs/Resource/Font/NimbusSanL-Regu
> gs/Resource/Font/NimbusSanL-ReguCond
> gs/Resource/Font/NimbusSanL-ReguCondItal
> gs/Resource/Font/NimbusSanL-ReguItal
> gs/Resource/Font/StandardSymL
> gs/Resource/Font/URWBookmanL-DemiBold
> gs/Resource/Font/URWBookmanL-DemiBoldItal
> gs/Resource/Font/URWBookmanL-Ligh
> gs/Resource/Font/URWBookmanL-LighItal
> gs/Resource/Font/URWChanceryL-MediItal
> gs/Resource/Font/URWGothicL-Book
> gs/Resource/Font/URWGothicL-BookObli
> gs/Resource/Font/URWGothicL-Demi
> gs/Resource/Font/URWGothicL-DemiObli
> gs/Resource/Font/URWPalladioL-Bold
> gs/Resource/Font/URWPalladioL-BoldItal
> gs/Resource/Font/URWPalladioL-Ital
> gs/Resource/Font/URWPalladioL-Roma

2011-12-14 16:23:24 +0000
Chris Liddell <chris.liddell@artifex.com>
3875e5a471e3f9b9b4a2f5ea03e37b59fcd8913c

> Bug 690779 (pt2): revisions to CIDFont substition.
> The original code (commit 18a51701) didn't work well with pdfwrite, so this
> revision handles substition by modifying the CIDFont resource .map dictionary.
> This means that the "fake" CIDFont is created with the requested parameters
> from the start.
> Also, add command line paramters and environment variables to control the
> path to and file name of the subsitute TTF.
> Differences in Bug692320.pdf.
> No other cluster differences.
> gs/Resource/Init/gs_cidfm.ps
> gs/Resource/Init/pdf_font.ps
> gs/doc/Use.htm

2011-12-14 09:10:55 +0000
Chris Liddell <chris.liddell@artifex.com>
ce35f1657aac012a492f05f61b56a605243fe83e

> Re-enable CDevProc for substituted CIDFonts.
> Previously, CDevProc execution was disabled for CIDFonts which had been
> substituted by a TTF (through cidfmap, for example) because the index that
> gets passed to zchar_set_cache() is the TTF GID, not the CID, and the
> CDevProc requires the CID.
> We can, however, retrieve the CID from the text enumerator, and pass that to
> the CDevProc, which is what this commit implements.
> Cluster differences in Bug692320.pdf because we now reposition glyphs with the
> CDevProc where we previously were not.
> No other differences.
> gs/psi/zcharout.c

2011-12-13 12:47:57 +0000
Robin Watts <robin.watts@artifex.com>
863d3d5383aaf59a04715115f72651cbbb3d8435

> Fix for bug 688387; Type 3 image range checking is too restrictive.
> Modified version of patch from Olavi Sakari.
> For explicit masking, regenerate the mask matrix from the image
> matrix, with scaling changes to allow for different widths/heights.
> Cluster testing shows differences in:
> tests_private/comparefiles/468-01.ps (We now match acrobat)
> tests_private/comparefiles/Bug690237.pdf (rounding diffs, fine)
> tests_private/ps/ps3cet/12-07C.PS (content now appears)
> gs/base/gximage3.c

2011-12-13 11:19:08 -0700
Henry Stiles <henry.stiles@artifex.com>
93bdb2010c0c1ce074c3cd4bddc6a77f6808d920

> Common subexpression elimination - no expected changes.
> pcl/pcindxed.c

2011-12-12 21:58:38 -0700
Henry Stiles <henry.stiles@artifex.com>
e04069bf8549eba33e7ba71398769609b72d2026

> Reorganize the initialization of the pen width and residual palette
> color entries. In particular, the pen width initialization was
> incorrect, applying default pen widths to pens that shouldn't be
> reset. This changes result in progressions for the following files:
> tests_private/pcl/pcl5ccet/31-09.BIN
> tests_private/pcl/pcl5ccet/34-03.BIN
> tests_private/xl/pcl6cet3.0/C705.bin
> pcl/pcindxed.c

2011-12-12 09:58:43 -0700
Henry Stiles <henry.stiles@artifex.com>
abf148da6950f4f39d57603fb316584ea0975fa7

> Addresses 692051, the palette string's allocated size always
> matches the number of entries in the palette times 3 (bytes).
> pcl/pcindxed.c

2011-12-12 09:57:30 -0700
Henry Stiles <henry.stiles@artifex.com>
0880ae03de6174fc13c3016a1c0f49c850047df7

> Make fuction static.
> CLUSTER_UNTESTED
> pcl/pcpalet.c

2011-12-12 09:54:30 -0700
Henry Stiles <henry.stiles@artifex.com>
a074d9ebc08bda2680133ae3fc09fd9ff55637be

> Fix long standing problem where too many palette entries were
> initialized. This was not an issue with a fixed static palette but
> with the new dynamic palettes forthcoming this would cause writing
> past the end of the palette data string.
> pcl/pcindxed.c

2011-12-09 09:37:26 -0700
Henry Stiles <henry.stiles@artifex.com>
dea0afb058b76ea57832f6e48a0bfc080898e9cb

> Back out valgrind workarounds to resize and initialize indexed color
> spaces. A more complete solution is forthcoming.
> pcl/pcindxed.c

2011-12-08 23:18:54 -0700
Henry Stiles <henry.stiles@artifex.com>
aacecd032249027269e896ebc0abada3a8e82945

> Extra debugging support for PCL color spaces.
> CLUSTER_UNTESTED
> pcl/pccid.c
> pcl/pccid.h
> pcl/pccsbase.c
> pcl/pcindxed.c
> pcl/pcpatrn.c

2011-12-13 15:21:42 +0000
Ken Sharp <ken.sharp@artifex.com>
5f5921ad464e39676328705c874485e66a6d6469

> Fix crash when using a TrueType substitute for a missing CIDFont with pdfwrite
> The changes to better handle PCL fonts accidentally left out an important
> test which could lead to a seg fault if a PDF file was processed which
> contained a reference to a non-embedded CIDFont, and we had defined a
> TrueType substitute to use instead.
> This restores the old behaviour of exiting with an error.
> Bug692320 should no longer seg fault with cluster testing.
> gs/base/gdevpdtt.c

2011-12-13 11:46:53 +0000
Chris Liddell <chris.liddell@artifex.com>
18a5170163b690647f70d58e4c9d75873cd1324b

> Bug 690779: Provide fallback for missing CIDFonts in PDF
> Rather than throw an error when a PDF references a CIDFont that is not
> available, we'll now fall back to using DroidSansFallback.ttf, by default.
> This gives a reasonable analogue of other PDF consumers' behavior.
> Results in extensive differences in Bug692320.pdf because we now complete
> content streams, and image the text they contain, rather than skipping
> them. NOTE: this does not make the output from Bug692320.pdf "correct", but
> arguably makes it "less wrong".
> Other than that, no differences.
> gs/DroidSansFallback.NOTICE
> gs/Resource/CIDFSubst/DroidSansFallback.ttf
> gs/Resource/CIDFont/ArtifexBullet
> gs/Resource/Init/gs_ciddc.ps
> gs/Resource/Init/gs_cidfm.ps
> gs/Resource/Init/gs_init.ps
> gs/Resource/Init/gs_ttf.ps
> gs/Resource/Init/pdf_font.ps
> gs/Resource/Init/xlatmap
> gs/doc/Use.htm
> gs/psi/psromfs.mak

2011-12-12 15:38:32 +0000
Chris Liddell <chris.liddell@artifex.com>
405d67e60c1b943f4faeed728bace0f2103a7ec8

> Bug 692736: fix logic contolling FAPI's bitmap production.
> Non-marking operations (such as stringwidth) sometimes require FAPI to produce
> a bitmap. We were taking the "slegdehammer" approach of always producing a
> bitmap, and throwing it away when not required.
> This commit fixes the decision on whether we should produce a bitmap.
> No cluster differences.
> gs/psi/fapi_ft.c
> gs/psi/zfapi.c

2011-12-12 14:29:29 +0000
Chris Liddell <chris.liddell@artifex.com>
77f2e7c475bdf79e478d59c878d6ae30c53c5a17

> Add missing dependencies for gdevicov.c.
> No cluster differences.
> gs/base/lib.mak

2011-12-10 16:41:06 -0800
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
70b1623bf91ea2a75da69f40caefb7efa56f49d9

> Add ink coverage device: inkconv. Resolves Bug 692665.
> Add the inkcov device, written by sebastian.kapfer@physik.uni-erlangen.de.
> This dummy device produce output listing the percentage of pixels
> containing c, m, y, and k ink.
> No cluster differences expected since this device isn't tested by the
> cluster.
> gs/base/configure.ac
> gs/base/gdevicov.c
> gs/base/lib.mak
> gs/base/macos-mcp.mak
> gs/base/macosx.mak
> gs/base/openvms.mak
> gs/base/unix-gcc.mak
> gs/base/unixansi.mak
> gs/ghostscript.vcproj

2011-12-09 10:01:57 +0000
Chris Liddell <chris.liddell@artifex.com>
9a2555a91fbc2fa73a6e2f8f4035b58b4ff5ae57

> Bug 692686: use same scan conversion settings for "clip" as for "fill"
> The PDF job in question renders most of its text as simple text render mode 0,
> but about three glyphs are done using tr mode 7, and showing an image through
> the resulting clip.
> The problem is that when we image a glyph, we use fill_adjust 0 (rather than the
> default of ~0.3), otherwise glyphs are overly bold. When using one of the clip
> text modes in PDF, however, we still used the default fill_adjust, which
> resulted in an overly "bold" clip path.
> This causes a number of cluster differences: several are progressions, the
> others are pixel differences - mostly cases where resolution and/or zoom level
> affect whether we precisely match Acrobat.
> gs/Resource/Init/pdf_ops.ps

2011-12-09 10:07:33 +0000
Ken Sharp <ken.sharp@artifex.com>
5359a2d0bf10568102f85d797a91c0595518ae23

> Do not use hexadecimal names for type42 Charstrings and Encoding
> Bug #692711 - When creating CharStrings and Encoding for an embedded
> TrueType font, to create a type 42 font, we need to supply numeric names
> according to the spec. We were doing this using hex values which has the
> unfortunate effect of creating 5 of the names as /A to /F.
> These are not numeric! In fact they duplicate 5 of the Ghostscript
> standard names. While this is not actually a problem when rendering, it
> *is* a problem for ps2write because it uses the names to rebuild the font
> for embedding. If the name is one of the standard names then it leads
> (through complex routes) to us creating a CMAP subtable where the GID is
> not correct, we use the value of the stadnard name instead of the correct
> numeric value.
> By using decimal numbers we avoid this problem.
> This change exhibits progressions in the regression files Bug688421.pdf
> (which is now 100% correct with the earlier fixes for composite glyphs)
> and Bug691121.pdf
> gs/Resource/Init/gs_ttf.ps

2011-12-09 09:43:53 +0000
Chris Liddell <chris.liddell@artifex.com>
db2cf48ecc2e287d2685c4b43fa7bcaa0fde1721

> Bug 692730: fix confusion in stream opening for FAPI/FT
> When I wrote the custom stream code so that Freetype uses the Ghostscript
> stream functions, I misunderstood a couple of aspects of the Ghostscript
> stream opening code, especially where paths did not include a Postscript
> device.
> I believe this resolves that.
> No cluster differences.
> gs/psi/fapi_ft.c

2011-12-08 21:35:46 -0800
Michael Vrhel <michael.vrhel@artifex.com>
8ac67fdf4beb52a8f804b146a13af208004c6f88

> Fix for accidental changes in ghostscript.vcproj during previous commit.
> Problem was caused by the fact that I add added a file that I wanted in the
> project display but I am running a newer version of visual studio compared to
> what we maintain in the trunk.
> gs/ghostscript.vcproj

2011-12-06 12:52:31 -0800
Michael Vrhel <michael.vrhel@artifex.com>
592047c6c30012f86ada508870554c9eff9a749a

> Allow use of unmanaged color transformations for source DeviceXXX colors
> This introduces a CMM that can hand back "links" to gs where the
> links in this case contain pointers to the simple procedures that
> transform between the various color spaces. This CMM (or non-CMM) can
> be invoked when we encounter DeviceRGB, DeviceGray or DeviceCMYK color
> spaces by use of the parameter -dUseFastColor.
> gs/base/gdevp14.c
> gs/base/gdevpsd.c
> gs/base/gdevrinkj.c
> gs/base/gdevxcf.c
> gs/base/gscms.h
> gs/base/gsdparam.c
> gs/base/gsequivc.c
> gs/base/gsicc.c
> gs/base/gsicc_cache.c
> gs/base/gsicc_cache.h
> gs/base/gsicc_cms.h
> gs/base/gsicc_lcms.c
> gs/base/gsicc_lcms2.c
> gs/base/gsicc_manage.c
> gs/base/gsicc_nocm.c
> gs/base/gxblend.c
> gs/base/gxblend.h
> gs/base/gxcmap.c
> gs/base/gxi12bit.c
> gs/base/gxicolor.c
> gs/base/gxipixel.c
> gs/base/gxiscale.c
> gs/base/lib.mak
> gs/ghostscript.vcproj
> xps/xpsgradient.c

2011-12-08 15:18:16 -0800
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
2ab94321918a4d4575435361e685836016ee9368

> Removed cgm devices. Fixed Bug 692401.
> No cluster differences expected, since the cluster doesn't test any of the cgm devices.
> gs/base/configure.ac
> gs/base/devs.mak
> gs/base/gdevcgm.c
> gs/base/gdevcgml.c
> gs/base/gdevcgml.h
> gs/base/gdevcgmx.h
> gs/doc/Develop.htm
> gs/doc/Drivers.htm

2011-12-07 15:32:14 +0000
Chris Liddell <chris.liddell@artifex.com>
f52122736b932c511a02b095d056cfb3a19a7fa8

> Bug 692641: Misc build fixes for static systems
> Patch contributed by Alan Hourihane ( alanh@fairlite.co.uk ) to improve
> compatibility with system which need static linking. So disable dynmic devices
> unless they explicitly enabled, rename our internal SHA functions so they don't
> clash when libssl is linked in.
> Finally, a fix so configure doesn't assume pkgconfig availability (although it
> is widely available, it is not "standard").
> No cluster differences.
> gs/base/configure.ac
> gs/base/sha2.c
> gs/base/sha2.h
> gs/base/ssha2.c

2011-12-06 13:38:01 -0800
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
3d64dd5fa86827f374ded02b220cf9bddbc852c7

> Another parital fix for Bug 692434.
> gs/base/gdevddrw.c

2011-12-06 13:34:47 -0800
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
0b21c79855e8f50a218a478bf9fc9d10e20c4db4

> Partial fix for Bug 692434, removed some of the memcmp() of structures.
> No cluster differences expected.
> gs/base/gdevdevn.c
> gs/base/gdevpdfg.c
> gs/base/gdevpdti.c
> gs/base/gdevpdts.c
> gs/base/gdevprn.c
> gs/base/gsequivc.h
> gs/base/gsfont.c
> gs/base/gsmatrix.c
> gs/base/gsmatrix.h

2011-12-06 19:20:28 +0000
Robin Watts <robin.watts@artifex.com>
9335aeee4aab3e7454c827fc3a327437dec85637

> Bug 692526: Partial fix (clipping path initialisation)
> Ghostscript paths have a 'local_segments' structure inside them
> enabling them to be allocated entirely on the stack. Clipping
> paths contain paths, so have the same structure. When a new
> clipping path is initialised on the stack, it can share the
> segments from an existing clipping path.
> If this existing clipping path is on the stack, and 'goes away'
> (due to garbage collection etc) the new clipping path can be left
> holding pointers to invalid data. As such there is code in the gs
> lib to detect that a clipping path is being asked to share
> segments from another stack allocated clipping path, and to refuse.
> The file referenced in the bug runs into exactly this situation.
> It is however entirely safe, as the lifespan of the second clipping
> path is 'nested' safely within the lifespan of the original.
> I have therefore introduced another function that allows the
> initialisation to be done as long as the caller guarantees that it
> is safely nested.
> This is sufficient to avoid the warning messages, and the file now
> runs to completion successfully.
> So why is this only a partial fix?
> The original code refuses to initialise the clip path, and returns
> a (negative) error code. This is caught by the calling code and
> various things are not done. Later, a compositor comes to be shut
> down, and pdf14_compose_group is called.
> This finds that maskbuf != NULL, but maskbuf->transfer_fn == NULL.
> This leads to a SEGV.
> Something (presumably in the cleanup code that should be handling
> the error) is leaving the compositor in an unexpected state however.
> The code change here stops the error return code, so the cleanup code
> is not called, and the regression is fixed. It leaves the broken
> cleanup code in there though - I'll leave the bug open until this is
> fixed.
> gs/base/gdevp14.c
> gs/base/gxcpath.c
> gs/base/gxfill.c
> gs/base/gxpath.h

2011-12-05 11:36:19 -0800
Michael Vrhel <michael.vrhel@artifex.com>
a7b85f9823b1a1dea1530716a3e2fb3dd2f75c9c

> Fix for bug 692567. Knockout support in pdf14_copy_alpha
> During a combined stroke and fill we push a knockout group for the stroke. This was not being handled properly in the pdf14 device's copy_alpha operation.
> gs/base/gdevp14.c

2011-11-17 10:19:42 -0800
Michael Vrhel <michael.vrhel@artifex.com>
2cde54397abe935ff96300a4ac2588b40ad68d2b

> Embedding of device ICC profile into JPEG output device
> Addresses bug 692186. This includes the fix to make sure the profile
> is not used for pdfwrite image output.
> gs/base/gdevjpeg.c
> gs/base/gdevpsdu.c
> gs/base/sdct.h
> gs/base/sdcte.c
> gs/psi/zfdcte.c

2011-12-04 20:58:58 -0800
Michael Vrhel <michael.vrhel@artifex.com>
224672fa4af11c4723c38ea11b4d51503a96f609

> Fix for bug 692717. Initialization of ICC profile data range in pdf14_put_image
> The ICC profile that is used to specify the PDF14 image data was not having its
> range values properly initialized.
> gs/base/gdevp14.c
> gs/base/gsicc_manage.c
> gs/base/gsicc_manage.h

2011-12-03 22:33:04 -0800
Michael Vrhel <michael.vrhel@artifex.com>
fd7c24da5b84f99605a38108c8cc0bfae813fbf4

> Fix for bug 692692. Anti-alias with pdf14 device.
> This fixes several bugs that were present in the pdf14 copy alpha
> procedure.
> gs/base/gdevp14.c

2011-11-29 20:33:16 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
d20a6cb9f12682804af2e74ec5d6bb75ca9d5410

> Bug 691267: jbig2dec needs to check malloc() return values
> This fix checks all return paths to ensure that the appropriate error
> is returned on failure from any malloc() call within jbig2dec.
> gs/base/sjbig2.c
> gs/jbig2dec/jbig2.c
> gs/jbig2dec/jbig2_arith.c
> gs/jbig2dec/jbig2_arith_iaid.c
> gs/jbig2dec/jbig2_arith_int.c
> gs/jbig2dec/jbig2_generic.c
> gs/jbig2dec/jbig2_halftone.c
> gs/jbig2dec/jbig2_huffman.c
> gs/jbig2dec/jbig2_image.c
> gs/jbig2dec/jbig2_metadata.c
> gs/jbig2dec/jbig2_page.c
> gs/jbig2dec/jbig2_refinement.c
> gs/jbig2dec/jbig2_segment.c
> gs/jbig2dec/jbig2_symbol_dict.c
> gs/jbig2dec/jbig2_text.c

2011-11-28 10:06:39 +0000
Chris Liddell <chris.liddell@artifex.com>
79de8a34f93165b5839f9fcbd75be9ca0048fd21

> Bug 692694: unaligned memory access in image ht code.
> When image data does not land exactly on the necessary alignment for SSE2
> optimisations, we handle the "left over" samples on their own, before the
> suitably aligned samples. When we come to copy the halftoned data to the
> target device, we first handle the "left over" samples, and then the
> SSE2 aligned samples in separate calls to copy_mono/copy_plane. The "left
> over" samples never number more than 16.
> Previously, after dealing with the non-SSE2 aligned samples, we'd increment
> the samples pointer two bytes (to skip the up to 16 bits of unaligned samples).
> The problem is, that causes us to 32 bits at time, on 16 bit aligned boundaries,
> which on SPARC causes a bus error.
> We now use the copy_mono/copy_plane API parameter which gives the function an
> offset into the samples which is should use before starting the operation.
> Implementations of copy_mono/copy_plane must handle non-aligned samples
> gracefully anyway.
> No cluster differences.
> gs/base/gxht_thresh.c

2011-11-27 13:23:46 -0500
Alex Cherepanov <alex.cherepanov@artifex.com>
a39e4831ba0d74d742b365f3b3b1af192731303c

> Bug 692684: stop gcc optimization bug.
> Divide gs_main_init2() into two functions to work around a bug in
> gcc 4.5.1 with -O2 option. The bug caused gcc to drop 2nd
> assignment to i_ctx_p and resulted in SEGV error later on.
> gs/psi/imain.c

2011-11-25 17:37:39 -0500
Alex Cherepanov <alex.cherepanov@artifex.com>
fa65667a25048b730e629bd4d8544d621cae2810

> Clean-up txtwrite device.
> Make debug tracing use a special flag instead of DEBUG.
> Fix two cases of '=' used instead of '=='.
> Fix all gcc warnings.
> Add proper dependencies to the makefile.
> gs/base/devs.mak
> gs/base/gdevtxtw.c

2011-11-25 12:24:11 -0500
Alex Cherepanov <alex.cherepanov@artifex.com>
e46cb584f6ab876828bb5c7943881cfbbc549e43

> Add missing txtwrite device to autoconf-based build.
> gs/base/configure.ac

2011-11-25 15:50:42 +0000
Ken Sharp <ken.sharp@artifex.com>
979f2182372d924ce69f8d904e87173107209b6b

> ps2write - fix conversion of escaped string to Hex string
> This is used when Indexed spac es are encountered, the lookup table is
> created as an escaped string, but written to the output as a Hex string.
> The conversion was not catering for the 'special' escaped characters,
> \r, \n, \b, \t and \f
> This results in a number of differences, casreful comparison shows them all
> to be progressions:
> Bug6901014_launch_leaflet.pdf
> annot-fit-bbox-in-rect.pdf
> 0.pdf
> 01_001.pdf
> 148-11.ps
> 1_2001.pdf
> Altona.Page_3.2002-09-27.pdf
> Altona_Technical_1v1_x3.pdf
> Bug687840.pdf
> Bug689083.pdf
> Bug689189.pdf
> Bug689362.pdf
> Bug689748.pdf
> Bug690109.pdf
> Bug690348.pdf
> Bug690395.pdf
> Bug690489.pdf
> Bug690559.pdf
> Bug691045.pdf
> Bug691228.pdf
> Bug691335.eps
> Bug691734.ps
> Bug691740.pdf
> Bug691816.pdf
> Bug691941.pdf
> Bug692365.pdf
> H00216q.pdf
> MagicEye.pdf
> NECPNTD.pdf
> Openhuis_pdf_zw.pdf
> PixelisAd.pdf
> RealCities.pdf
> S2_Digitalproof-Forum_x3k.pdf
> adesso2.pdf
> bulletin.pdf
> dave.pdf
> file.pdf
> file2.pdf
> japan.ps
> korea.ps
> messenger.pdf
> messenger16.pdf
> p2b-100.pdf
> CATX0249.pdf
> CATX1028.pdf
> CATX1421.pdf
> CATX1593.pdf
> CATX2050.pdf
> CATX2181.pdf
> CATX2447.pdf
> CATX2905.pdf
> CATX2937.pdf
> CATX3740.pdf
> CATX3783.pdf
> CATX4574.pdf
> CATX4879.pdf
> CATX4998.pdf
> CATX5365.pdf
> CATX6460.pdf
> CATX7581.pdf
> CATX7762.pdf
> CATX8839.pdf
> CATX9297.pdf
> IA3Z0248.pdf
> IA3Z0440.pdf
> IA3Z1148.pdf
> IA3Z1284.pdf
> IA3Z3096.pdf
> IA3Z3100.pdf
> IA3Z3298.pdf
> IA3Z3881.pdf
> IA3Z4393.pdf
> IA3Z4925.pdf
> gs/base/gdevpdfu.c

2011-11-25 15:27:03 +0000
Chris Liddell <chris.liddell@artifex.com>
3f99f9c568fa7a93ce4ca5acdc0c8fed6cf505bd

> Add a "dummy" call to validate UFST font.
> It turns out that UFST's CGIFfont() call does little or no validation of the
> font for which it is creating an object. So, add a "dummy" call to
> CGIFfont_metrics() which will return an error if, for example, a request
> for a font index which doesn't exist in the current FCO is made.
> CLUSTER_UNTESTED
> gs/psi/fapiufst.c

2011-11-21 20:31:09 +0000
Robin Watts <robin.watts@artifex.com>
83788c03875545d620e6885e4f5ab4af08f8f55b

> Bug 692666: grid fit images.
> The file in bug 692666 draws many thin horizontal rectangles, then draws
> 1 pixel high images on top of each one. Current gs 'thickens' the
> rectangles (due to the 'any part of a pixel' rule), and they overwrite
> the previously drawn image - hence it appears black.
> The problem is thus that the images are not similarly stretched.
> Images are not supposed to use the "any part of a pixel" rule, where
> vectors are, but the fact this file works in acrobat would seem to
> contradict that. Instead we try a simple fix; if we are using the
> 'any part of a pixel' file (i.e. fill_adjust != 0), and we meet an
> ImageMask image that is either 1 pixel high, or 1 pixel wide, then we
> ensure that it is 'stretched' to completely fill any pixels that it
> touches.
> We specifically do NOT perform this stretching if we are in the process
> of rendering a glyph.
> This produces various rendering diffs, none that offensive.
> gs/base/gxipixel.c

2011-11-23 15:36:11 +0000
Ken Sharp <ken.sharp@artifex.com>
4298afc461ec583637d5ce2b41facc40403867d5

> Correct CIDSet and CIDToGIDMap generation when LastChar > number of glyphs
> More CIDSet work. WHen LastChar is > number of glyphs in font (already a subset)
> we were setting the length of the CIDToGIDMap and the CIDSet to the LastChar
> value. This should be LastChar + 1 to allow for the /.notdef.
> No differences expected, this only happens when generating PDF/A which is not tested.
> gs/base/gdevpdtd.c

2011-11-22 17:58:47 +0000
Chris Liddell <chris.liddell@artifex.com>
7cf40e90d53c0a86b05561985608d3d292025a00

> Bug 692681: handle invalid Encoding arrays in Type 3 fonts
> Distiller quietly converts the contents the contents of a Type 3 font's encoding
> array to names (at least if they are integer objects), whilst CPSI throws an
> error.
> We will now do as Distiller and convert to name objects, unless we are in "CPSI
> compatibility mode", when we will throw an error.
> No cluster differences.
> gs/psi/zbfont.c

2011-11-19 00:02:59 +0000
Robin Watts <robin.watts@artifex.com>
365dd132567f8007176ca48d36741b6c98d4a514

> Bug 692512: fts_10xx.xps shows white lines in pattern.
> The matrix used for the pattern is skewed; this was enough to avoid
> my previous fix being used. Amend the tests to cope with the skewed
> case too. We may need to cope with 90 degree rotated/skewed cases too.
> gs/base/gsptype1.c

2011-11-18 23:59:14 +0000
Robin Watts <robin.watts@artifex.com>
6fc9006fb9e381c42308d7d7967fdcac5f31e26d

> Bug 692512: Disable stroke adjust in xps to avoid gradient issues.
> The fts_1003.xps file has a series of parallel lines (as separate
> strokes) to make up a gradient. Having stroke adjust enabled
> causes gaps (white lines) to appear between them.
> Tests show that simply disabling stroke adjust all the time gives
> nasty effects (thickening of lines). We therefore disable it just
> for patterns here. This is enough to fix the current bug.
> xps/xpstile.c

2011-11-22 08:15:27 +0000
Ken Sharp <ken.sharp@artifex.com>
5cce07051c3616c250a960ae48759a1c1af2fb47

> ps2write - only execute setpagedevice if /PageSize changes
> Bug #692691
> The ps2write output (being based on pdfwrite) always emits a /MediaBox as
> this is a required key for PDF. Previously the PostScript prolog would
> always emit a setpagedevice using the MediaBox as the PageSize entry.
> This caused a problem for CUPS as it inserts PPD code into the ps2write
> output, and if this enables Duplex then each invocation of setpagedevice
> will flush the accumulated output, which defeats Duplex.
> The prolog code now tests the current page size and only executes
> setpagedevice if the newly requested size differs from the current size. In
> a simple attempt to ignore small differences we round the current and requested
> media sizes, and convert to integers before comparison.
> No differences expected in regression tests
> gs/base/opdfread.h
> gs/lib/opdfread.ps

2011-11-21 18:56:17 +0000
Chris Liddell <chris.liddell@artifex.com>
8a14c04c93138fab042063999af3610ea7b9852a

> Revisions for Freetype custom stream use.
> There were some subtleties of FT's custom stream use that I misunderstood:
> unused entries in the structures must be null/zero, and the stream length
> is required data.
> Also, reorganise the code so building the stream object is contained in
> a dedicated function.
> No cluster differences.
> gs/psi/fapi_ft.c

2011-11-21 11:10:22 -0800
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
fc8350604816f8314cb8c6355bfb9335feab5561

> Fix one of the casts from b6cd8ce7351fc7bb759b5b7dcea7e74b2abb3850
> The cast in the calls to hpgl_args_add_int() in pcl/pgconfig.c:hpgl_IR()
> was wrong. The entire second argument needed to be cast to int32, not
> just the results of the division. This caused regressions in a bunch
> of the nightly/cluster test files, e.g.:
> main/obj/pcl6 -sDEVICE=ppmraw -r75 -o test.ppm fts.1930
> pcl/pgconfig.c

2011-11-21 15:38:07 +0000
Chris Liddell <chris.liddell@artifex.com>
590dcb6b2df9f4722b4f78607d35bd9c374624b1

> Bug 692672: slightly revise symbolic fonts in PDFs
> This is a slightly better of approximation of what Acrobat does in the out
> of spec condition when a font has both an encoding in the font object and
> the symbolic flag set in the descriptor's flags entry.
> If the flags say symbolic, *and* the font contains a symbol cmap table,
> ignore Encoding if there is one, treat as symbolic.
> If the flags say symbolic, and the font doesn't have a symbol cmap, but we do
> have an Encoding, treat it as non-symbolic if we don't have an Encoding, try
> the MacRoman cmap table.
> Finally, if none of that works, remove the Encoding, and treat it as
> non-symbolic. This part is the biggest guess at Acrobat's behavior.
> The various tests used in investigating what Acrobat does are attached to the
> bug (692672).
> No cluster differences.
> gs/Resource/Init/gs_ttf.ps
> gs/Resource/Init/pdf_font.ps

2011-11-21 08:55:17 +0000
Ken Sharp <ken.sharp@artifex.com>
bd108fc1a4b52c885a8e26362f346c0cd2fb6670

> Update to Commit 63a5fe390d2534f6b48e2dd58f46ed9941582e83
> This added detection of URW font names and their replacement with base 14
> font names, when the fonts are not embedded. One of the Base 14 names
> was not correct.
> gs/base/gdevpdtb.c

2011-11-21 08:47:51 +0000
Ken Sharp <ken.sharp@artifex.com>
e2215693fe25a78865632b6bbbd52a3b4f2ab95c

> Fix some minor return code inconsistencies.
> Bug #692682, spotted by Alex, fix up a couple of inconsistent return values.
> gs/base/gdevpdfo.c

2011-11-21 08:12:45 +0000
Ken Sharp <ken.sharp@artifex.com>
cd8f3973ac735480fcd02de9e0214de80ea79e94

> ps2write - fix handling of format 4 CMAP subtables in TrueType fonts
> Bug #692687. Format 4 CMAP subtables are intended for use where the range
> of glyphs are not continuous, but the code for building a CharStrings
> dictionary (to handle the font as type 42) was treating them as if they
> were continuous, and starting from 0.
> This led to the CharStrings dictionary, which maps glyph names to TrueType
> Glyph IDS, being built incorrectly and incorrect, mostly /.notdef, glyphs
> being used.
> Regression testing shows no regressions and the following test files exhibit
> progressions:
> Bug6901014_Additional_testcase.pdf
> Bug6901014_SMP_Warwick_14.pdf
> Altona.Page_3.2002-09-27.pdf
> Altona_Technical_1v1_x3.pdf
> Bug687828.pdf
> Bug688421.pdf
> Bug688946.pdf
> Bug689014.pdf
> Bug689754.ps
> Bug690269.ps
> Bug691116.pdf
> Bug691733.ps
> Faktura.pdf
> altona_technical_1v2_x3.pdf
> test_multipage_prob.pdf
> type42_glyph_index.ps
> CATX4030.pdf
> CATX9201.pdf
> IA3Z4488.pdf
> gs/base/opdfread.h
> gs/lib/opdfread.ps

2011-11-21 01:26:01 -0500
Alex Cherepanov <alex.cherepanov@artifex.com>
ae0f7a3be733a04293a757f6ae395391339b78f5

> Finish interface to OpenJpeg library.
> This version handles all out tests correctly, although all files
> show minor differences in color values. The build process has
> not been changed and continues to build Jasper by default.
> gs/base/sjpx_openjpeg.c
> gs/base/sjpx_openjpeg.h
> gs/openjpeg/libopenjpeg/image.c
> gs/openjpeg/libopenjpeg/jp2.c
> gs/openjpeg/libopenjpeg/jp2.h
> gs/openjpeg/libopenjpeg/openjpeg.c
> gs/openjpeg/libopenjpeg/openjpeg.h
> gs/openjpeg/libopenjpeg/tcd.c

2011-11-20 10:29:47 +0000
Shailesh Mistry <shailesh.mistry@hotmail.co.uk>
f7f2daea2778213306a3edfe87a8f72af494427a

> Fix 691958: check for an image before marking a page complete.
> Also update return code to handle errors correctly.
> gs/jbig2dec/jbig2_page.c

2011-11-20 10:43:51 -0700
Henry Stiles <henry.stiles@artifex.com>
44049d64ebd14bd76f94d87cd0fd55ea725f7510

> Update ownership.
> CLUSTER_UNTESTED
> doc/who_owns_what.txt

2011-11-18 14:42:40 -0700
Henry Stiles <henry.stiles@artifex.com>
38cb1fd0cb7f38e6d7cf4b4fe06809865ccd0fff

> Fix 692559, integrate Josef Hinteregger's patch to detect a font
> directory without fonts and continue gracefully.
> pl/pllfont.c

2011-11-18 14:09:04 -0700
Henry Stiles <henry.stiles@artifex.com>
3457a11ec419dcce4cd9e444674967b4dd5e8740

> The indeterminism in the test file TIFFOffsetA4PL.pcl was caused by
> the new custom page size implementation. The new code updates the
> current page structure instead of creating a new one - later the page
> size logic doesn't recognize a page size change and doesn't clear the
> page (erasepage) properly. The custom page size implementation is
> less than ideal, but the simple fix here is to just erase the page
> unconditionally when the custom page size command is received. There
> was no bug reported for this problem.
> pcl/pcpage.c

2011-11-17 17:59:41 -0700
Henry Stiles <henry.stiles@artifex.com>
f482ab7c57e8a20f760be5b329bee528a66e7927

> Capitalize a symbolic constant.
> pcl/pcpage.c

2011-11-17 17:44:49 -0700
Henry Stiles <henry.stiles@artifex.com>
7b9a1eeaa1fce33270957e302e09189c6202f1a5

> Fix 692677, in passthrough mode we initialize the PCL interpreter with
> the paper size current in PXL's state. Previously the there could be
> a mismatch in paper size which could lead to, for example, an A4
> memory buffer erased as if it were LETTER, this left a small strip at
> the bottom of the page uninitialized.
> pxl/pxpthr.c

2011-11-17 17:43:05 -0700
Henry Stiles <henry.stiles@artifex.com>
fdb03e00c09a32d23a831cecfea9f4b1955b9b7a

> A new interface procedure to allow the languages to invoke the PJL parser.
> pl/pjparsei.c
> pl/pjtop.c
> pl/pjtop.h

2011-11-17 17:39:28 -0700
Henry Stiles <henry.stiles@artifex.com>
fc3aa53aafc7b73ae9703d253ae4040658e22b74

> The "wide a4" state variable could be used unitialized when using
> custom paper sizes.
> pcl/pcpage.c

2011-11-15 11:26:36 -0800
Michael Vrhel <michael.vrhel@artifex.com>
27806596e3c2820064788bba903cc569ce89f1e7

> Removal of WTS from code.
> Plan is to suggest the use of screens generated with gs\toolbin\halftone\gen_ordered
> gs/base/gdevdflt.c
> gs/base/gp.h
> gs/base/gsdcolor.h
> gs/base/gsdps1.c
> gs/base/gsht.c
> gs/base/gsht1.c
> gs/base/gshtscr.c
> gs/base/gslibctx.h
> gs/base/gswts.c
> gs/base/gswts.h
> gs/base/gxbitfmt.h
> gs/base/gxclread.c
> gs/base/gxdcolor.c
> gs/base/gxdcolor.h
> gs/base/gxdevcli.h
> gs/base/gxdevndi.c
> gs/base/gxdht.h
> gs/base/gxdhtserial.c
> gs/base/gxht.h
> gs/base/gxshade.c
> gs/base/gxwts.c
> gs/base/gxwts.h
> gs/base/lib.mak
> gs/doc/Language.htm
> gs/ghostscript.vcproj
> gs/psi/zusparam.c
> pl/plsrgb.c

2011-11-17 12:05:24 -0800
Michael Vrhel <michael.vrhel@artifex.com>
aef9ee68391088d1c7e371a6f1e3fa4092688eae

> Revert "Embedding of device ICC profile into JPEG output device"
> This reverts commit 23a2b8e765a4d56cfeacddaaaa497e817bec499e.
> Need to see how this screws up pdfwrite.
> gs/base/gdevjpeg.c
> gs/base/sdct.h
> gs/base/sdcte.c

2011-11-17 10:19:42 -0800
Michael Vrhel <michael.vrhel@artifex.com>
23a2b8e765a4d56cfeacddaaaa497e817bec499e

> Embedding of device ICC profile into JPEG output device
> Addresses bug 692186.
> gs/base/gdevjpeg.c
> gs/base/sdct.h
> gs/base/sdcte.c

2011-11-16 10:32:30 -0800
Michael Vrhel <michael.vrhel@artifex.com>
6fbdd32889dfa9d318170e63245755057bb8b401

> Save ICC profile in TIFF and PNG device output.
> This addresses Bug 692183. The patch for the TIFF case was not
> quite sufficient due to changes in the device profile structure,
> issues regarding the separations from the tiffsep device, and
> how we handle the case when the output profile is CIELAB.
> gs/base/gdevpng.c
> gs/base/gdevtifs.c
> gs/base/gdevtsep.c

2011-11-15 18:02:06 +0000
Chris Liddell <chris.liddell@artifex.com>
3a088c1913fae07ea8016ef29853610741e16851

> Bug 692683: revise FAPI/FT code so it uses the GS file handling
> When the Freetype interface was called to create a font object with a path
> to the font file, it previously simply passed the path into Freetype, and
> left it to handle the file details.
> This revision changes that so that we build a custom Freetype stream object
> which uses the Ghostscript file API to access the data. We generally prefer
> to operate that way anyway, and (more importantly) this allows FT "direct"
> acccess to font files stored in our ROM filesystem.
> No cluster differences.
> gs/psi/fapi_ft.c

2011-11-15 17:25:27 +0000
Chris Liddell <chris.liddell@artifex.com>
445f78bf167f27a5358bff72d314d6ecc83a5384

> Add a wildcard to CIDFont mkromfs parameter
> To correctly including the _contents_ of the Resource/CIDFont directory
> when building the rom filesystem, we need a wildcardm, so it ends up
> as "Resource/CIDFont/*"
> No cluster differences.
> gs/psi/psromfs.mak

2011-11-14 22:37:28 -0800
Michael Vrhel <michael.vrhel@artifex.com>
f0b1c2aefaed5ba17fea69848c0b5489b541c4cf

> Clarification of the gen_ordered settings and README.
> The current default value for -s (size of the super cell) is 1
> which indicates that them smallest possible size should be used.
> This occurs regardless of the requested quantization levels.
> This is clarified in the README and a message is displayed
> during the creation of the screen providing a minimum suggested
> value for -s to achieve the number of requested levels.
> gs/toolbin/halftone/gen_ordered/README
> gs/toolbin/halftone/gen_ordered/gen_ordered.c

2011-11-14 10:10:05 -0800
Michael Vrhel <michael.vrhel@artifex.com>
0cf2574289f8825620dd805f49f1cfaab04f005b

> Addition of thresholding functions for subtractive color spaces.
> Previously, I had swapped the threshold and the image data to handle the subtractive case.
> Unfortunately due to the way things were written that caused issues. So for now we added
> unique functions for the subtractive case to avoid an additional conditional in the low
> level part of the code.
> gs/base/gxht_thresh.c
> gs/base/gxht_thresh.h

2011-11-14 18:11:44 +0000
Robin Watts <robin.watts@artifex.com>
3becda050c87511153170a85c7d3414e9a78e189

> Squash some more PCL warnings.
> Implicit typecasts made explicit.
> gs/base/gdevclj.c
> pcl/pcrect.c
> pl/plchar.c
> pxl/pxerrors.c
> pxl/pxgstate.c

2011-11-14 12:19:32 +0000
Robin Watts <robin.watts@artifex.com>
96ab69c8bcc1bcf3e366b494ed099dc5b46009fe

> Planar rop fixes; extensive changes throughout code.
> The changes here are largely forced upon us by the rop source device,
> the internal mechanism used within the gs lib to cope with performing
> rop operations with drawing operations. The rop source device is
> created and is given a 'source'. Any operations then done to that device
> are then passed on to its target device rewritten into a form that will
> cause the output to be ropped with the source.
> This causes problems when the source is in planar format (such as when
> the source is a pattern tile intended for use on a planar device). There
> is no way to call strip_copy_rop with planar data currently, neither
> can it easily be shoehorned through. We therefore add a new
> 'strip_copy_rop2' entrypoint that takes an additional 'planar_height'
> parameter that gives the number of lines of data before the next
> planes data starts.
> We add implementations of this call throughout the code; some are
> very simple (bbox, null, trace, clip, clip2, clip2, tile_clip etc).
> Others 'common up' with the strip_copy_rop (gx_default,
> mem_planar).
> The underlying memory devices should never be called with strip_copy_rop2
> as the planar data will always be rewritten to chunky format before
> this happens. We are free to change this approach later if we want.
> The gx_rop_source_t structure used by the rop source device is extended
> to have a new planar_height field, and the rop source device itself
> extended to pass this on. Various places that create this structure now
> initialise that correctly.
> The clist reader/writer is updated to send the extra planar_height
> field through and call strip_cop_rop or strip_copy_rop2 as appropriate.
> In a similar vein, we are forced to change the copy_plane entry point
> to be copy_planes (as it is impossible (or very hard at least) for the
> rop source device to implement copy_plane).
> This incorporates changes from Michael to the new "fast threshold" image
> halftoning code to make it use the new copy_planes operation.
> gs/base/gdevbbox.c
> gs/base/gdevdflt.c
> gs/base/gdevdrop.c
> gs/base/gdevmem.h
> gs/base/gdevmpla.c
> gs/base/gdevnfwd.c
> gs/base/gdevrops.c
> gs/base/gdevtrac.c
> gs/base/gxacpath.c
> gs/base/gxcht.c
> gs/base/gxcldev.h
> gs/base/gxclimag.c
> gs/base/gxclip.c
> gs/base/gxclip.h
> gs/base/gxclip2.c
> gs/base/gxclipm.c
> gs/base/gxclist.c
> gs/base/gxclrast.c
> gs/base/gxclrect.c
> gs/base/gxdcolor.c
> gs/base/gxdcolor.h
> gs/base/gxdevcli.h
> gs/base/gxdevice.h
> gs/base/gxht.c
> gs/base/gxht_thresh.c
> gs/base/gxht_thresh.h
> gs/base/gxicolor.c
> gs/base/gximage.h
> gs/base/gximono.c
> gs/base/gxp1fill.c
> gs/base/gxpcmap.c

2011-11-14 08:31:38 -0800
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
940b007282d74686a20aa5cf434d20353680344c

> Fixed a template -> templat for the Luratech build.
> gs/base/gdevpsdi.c

2011-11-14 10:39:24 +0000
Ken Sharp <ken.sharp@artifex.com>
08dc12934adaa27978ec264dbf9c691a18d8c429

> ps2write - improve TrueType composite glyph handling
> Bug #692626, #696264.
> When emitting a TrueType font from a CIDFont with TrueType outlines if a
> glyph was a composite glyph we did not create an entry in name table for
> any components of the glyph which were not already present in the output
> font.
> This caused problems creating the CMAP subtable for the embedded TrueType
> font.
> This patch shows progressions with ps2write and files CATX4638.pdf, bug690450.pdf.
> A regresison with pdfwrite and file bug688421.pdf and a difference in
> Bug 691121.pdf with pswrite (wrong before, differnetly wrong now)
> Despite the regression I'm committing it, as it shows significant improvements
> for ps2write.
> gs/base/gxfcopy.c

2011-11-12 19:44:39 +0100
Till Kamppeter <till.kamppeter@gmail.com>
ed8664ed1a8a797d949270d707966aadefb3b9e8

> Renamed the PXL CUPS filter from "pstopxl" to "gstopxl", as like "gstoraster"
> it understands both PostScript and PDF as input.
> gs/base/configure.ac
> gs/cups/cups.mak
> gs/cups/gstopxl.in
> gs/cups/pstopxl.in
> gs/cups/pxlcolor.ppd
> gs/cups/pxlmono.ppd

2011-11-11 21:09:02 -0500
Alex Cherepanov <alex.cherepanov@artifex.com>
8c3d5996d379818c8c0422bb8330840d0fb12645

> Bug 692675: drop ivalid filter parameters.
> Check for /dicttype instead of null. Drop null and invalid filter
> parameters at once.
> gs/Resource/Init/pdf_base.ps

2011-11-11 14:09:09 -0700
Henry Stiles <henry.stiles@artifex.com>
9a015bf889ea43c050fcf652c37d3c786483e243

> The PXL assembler and dissassembler had the incorrect attribute code
> for PCLSelectFont and the PCLSelectFont attribute name was missing
> from a debug name table.
> CLUSTER_UNTESTED
> pxl/pxptable.c
> tools/pxlasm.py
> tools/pxldis.py

2011-11-11 00:07:57 -0700
Henry Stiles <henry.stiles@artifex.com>
d53286dbb42db66166b7af2f68a63baf7da43791

> Fix 690417 - new PCL command "set logical page". This allows the user
> to provide arbitrary width, height and offsets which are then
> associated with the currently selected paper.
> pcl/pcl.mak
> pcl/pcpage.c

2011-11-10 21:57:16 +0000
Robin Watts <robin.watts@artifex.com>
b6cd8ce7351fc7bb759b5b7dcea7e74b2abb3850

> Squash warnings in pcl/pxl.
> Mostly making type coercions explicit.
> pcl/pcbiptrn.c
> pcl/pccid.c
> pcl/pccsbase.c
> pcl/pcfont.c
> pcl/pcfontpg.c
> pcl/pcfsel.c
> pcl/pcindxed.c
> pcl/pcjob.c
> pcl/pcpage.c
> pcl/pcpatrn.c
> pcl/pcrect.c
> pcl/pcsfont.c
> pcl/pctext.c
> pcl/pcuptrn.c
> pcl/pcursor.c
> pcl/pgconfig.c
> pcl/pgframe.c
> pcl/pgpoly.c
> pcl/rtgmode.c
> pcl/rtmisc.c
> pcl/rtraster.c
> pl/pjparse.c
> pl/plchar.c
> pl/plsrgb.c
> pxl/pxink.c
> pxl/pxsessio.c

2011-11-10 20:49:55 +0000
Robin Watts <robin.watts@artifex.com>
42aa659090c896b807745b4eba81335dbd8e8d92

> Replace 'this' with 'self'.
> Using C++ reserved words in ghostscript is bad form, especially as
> MSVC gets confused by them when debugging.
> I haven't changed the use of 'this' in zlib as it's not ours to change.
> gs/base/gscicach.c
> gs/base/gsgcache.c
> gs/base/gxclist.c
> gs/base/gxhintn.c
> gs/base/gxhintn1.c
> gs/base/gximono.c
> gs/base/gxpflat.c
> gs/base/gxttfb.c
> gs/base/ttfmain.c

2011-11-10 20:11:03 +0000
Robin Watts <robin.watts@artifex.com>
d81dffe6142ead8245baacf12f3b2ae4fe20b206

> Squash warnings in MSVC build.
> All self evident, really. Lots of char's that should be bytes etc.
> gs/base/gdevclj.c
> gs/base/gdevpdtw.c
> gs/base/gdevtsep.c
> gs/base/gp_wgetv.c
> gs/base/gsicc_cache.c
> gs/base/gxicolor.c
> gs/base/gxipixel.c
> gs/base/sidscale.c
> pcl/pcht.c
> pcl/rtmisc.c
> pl/plchar.c
> pl/plfont.c
> xps/xpspath.c

2011-11-10 19:09:05 +0000
Robin Watts <robin.watts@artifex.com>
d182ddaf5d46dc68d7f266fcb7f4de1ed64b7b56

> Replace all uses of 'template' with 'templat'.
> Using C++ reserved words is bad form, if only because they upset MSVC
> when debugging.
> gs/base/gdevcfax.c
> gs/base/gdevfax.c
> gs/base/gdevjbig2.c
> gs/base/gdevjpeg.c
> gs/base/gdevjpx.c
> gs/base/gdevpdfd.c
> gs/base/gdevpdfi.c
> gs/base/gdevpdfm.c
> gs/base/gdevpdfo.c
> gs/base/gdevpdfu.c
> gs/base/gdevpdfv.c
> gs/base/gdevpsdi.c
> gs/base/gdevpsdp.c
> gs/base/gdevpsds.c
> gs/base/gdevpsdu.c
> gs/base/gdevpsim.c
> gs/base/genconf.c
> gs/base/gsfunc4.c
> gs/base/gsptype1.c
> gs/base/gsptype2.c
> gs/base/gsptype2.h
> gs/base/gstrans.c
> gs/base/gxclbits.c
> gs/base/gxcllzw.c
> gs/base/gxclmem.c
> gs/base/gxclzlib.c
> gs/base/gxcolor2.h
> gs/base/gxidata.c
> gs/base/gxiscale.c
> gs/base/gxpcmap.c
> gs/base/scommon.h
> gs/base/sdct.h
> gs/base/sdctd.c
> gs/base/sdcte.c
> gs/base/smd5.c
> gs/base/spsdf.c
> gs/base/ssha2.c
> gs/base/stream.c
> gs/psi/fapi_ft.c
> gs/psi/ifilter.h
> gs/psi/ifrpred.h
> gs/psi/ifwpred.h
> gs/psi/iscan.c
> gs/psi/zfapi.c
> gs/psi/zfdctd.c
> gs/psi/zfdcte.c
> gs/psi/zfdecode.c
> gs/psi/zfile.c
> gs/psi/zfilter.c
> gs/psi/zfilter2.c
> gs/psi/zfproc.c
> gs/psi/zfrsd.c
> gs/psi/zmisc1.c
> gs/psi/zpcolor.c
> gs/psi/zshade.c
> pxl/pximage.c
> pxl/pxink.c
> xps/xpsjpeg.c
> xps/xpstiff.c

2011-11-10 11:08:56 -0800
Ray Johnston <ray.johnston@artifex.com>
108bf3d9fd2770c1b97a4eabcd4f09dd13c7fe18

> Fix several problems with the 16-bit PS output from gen_ordered.
> CLUSTER_UNTESTED
> gs/toolbin/halftone/gen_ordered/gen_ordered.c

2011-11-10 10:35:57 -0800
Ray Johnston <ray.johnston@artifex.com>
73770f28c263a514a318aa91af24b26814062bd1

> Change options and README for gen_ordered.c and fix 16-bit PS output.
> Also add check for missing value for an option (get_arg returning NULL) and add specific 'format' for
> 16-bit .raw (raw16) (reserving the -b option for number of bits 1, 2, 4) for multi-level threshold
> arrays.
> CLUSTER_UNTESTED
> gs/toolbin/halftone/gen_ordered/README
> gs/toolbin/halftone/gen_ordered/gen_ordered.c

2011-11-10 09:01:28 -0800
Ray Johnston <ray.johnston@artifex.com>
cde0561c8ffc71c231a0aeff399852c43ab7a9e8

> Move the ordered dither screen creation tool to toolbin/halftone/gen_ordered.
> Previously this was buried under the toolbin/color directory. Also by putting it into gen_ordered, we
> prepare for the addition of gen_stochastic and threshold_remap tools related halftone tools. Michael
> Vrhel as agreed with this change.
> CLUSTER_UNTESTED
> gs/toolbin/color/halftone/README
> gs/toolbin/color/halftone/halfttoning.sln
> gs/toolbin/color/halftone/halfttoning/halftone.c
> gs/toolbin/color/halftone/halfttoning/halfttoning.vcproj
> gs/toolbin/halftone/gen_ordered/README
> gs/toolbin/halftone/gen_ordered/gen_ordered.c
> gs/toolbin/halftone/gen_ordered/gen_ordered.sln
> gs/toolbin/halftone/gen_ordered/gen_ordered.vcproj

2011-08-31 18:39:24 +0100
Robin Watts <Robin.Watts@artifex.com>
1da2a46ed9f6ae0b0afc5fd4417943a36e532171

> More work on bug 690538: introduce macros for color rounding.
> Introduce new macros to gxcvalue.h header file that defines helpful macros
> for colour depth changing.
> COLROUND macros do rounding (16->n bits), COLDUP macros do bit duplication
> (n->16 bits). Use these macros in various places throughout the code.
> Also tweak the gx_color_value_to_byte macro to round in the same way.
> Colors for devices that use these functions are now rounded in the same way
> that lcms does.
> Change as many encode_color routines as I can find to use this new code
> rather than simply truncating.
> gs/base/gdevbit.c
> gs/base/gdevcdj.c
> gs/base/gdevdevn.c
> gs/base/gdevdsp.c
> gs/base/gdevperm.c
> gs/base/gdevplan.c
> gs/base/gdevplib.c
> gs/base/gdevpsd.c
> gs/base/gdevrinkj.c
> gs/base/gdevtsep.c
> gs/base/gdevxcf.c
> gs/base/gxblend1.c
> gs/base/gxcmap.c
> gs/base/gxcvalue.h

2011-11-09 17:46:06 +0000
Robin Watts <robin.watts@artifex.com>
4ccf3ba715990923281126bd9b300aa645d7a1d6

> Squash some warnings produced in the last memento fix.
> giving me a warning on MSVC).
> Remove unused variable.
> gs/psi/zmisc.c

2011-11-09 16:29:24 +0000
Ken Sharp <ken.sharp@artifex.com>
36e4f24d76e9f33bf5b531b8bd7d2c31ebee9153

> Properly finalize the DCT-writing memory device to avoid memory leaks
> Bug #692670 "Ghostscript uses 2 gigs of memory reading file". When writing
> images a JPEG the pdfwrite code creates a memory device temporarily. It
> was not, however, finalizing the device. Previously this did not cause a
> problem, but with the ICC colour work, this left the ICC buffers set up,
> causing a ~6Kb per image memory leak.
> This commit explicitly finalizes the device, which frees the memory and
> gets rid of the leak.
> No differences expected
> gs/base/gdevpsdi.c

2011-11-09 13:12:49 +0000
Robin Watts <robin.watts@artifex.com>
136065f0fcaa871376561a1c81c16c7d9b2bb3c7

> Memento 'list blocks' tweaks.
> Make Memento_listBlocks() function non-static.
> Add new Memento_listNewBlocks() function.
> Add flags word to Memento block header, only 1 bit of which is used
> curently (to indicate that a block is new since the last listNewBlocks
> call).
> Add .mementolistnewblocks postscript operator.
> Add (commented out) code in gs_init.ps to call vmreclaim and then
> .mementolistnewblocks at the end of each showpage. This allows
> tracking of blocks that 'leak' during each page (where 'leak' doesn't
> necessarily mean truly leak).
> gs/Resource/Init/gs_init.ps
> gs/base/memento.c
> gs/base/memento.h
> gs/psi/zmisc.c

2011-11-08 08:25:13 +0000
Ken Sharp <ken.sharp@artifex.com>
138d68e2d7dd5567c7a24740ec71858e24342a1f

> Fix type 1 font copying code SEAC scanner.
> When embedding type 1/CFF fotns the code scans the glyphs to see is any of
> them are SEAC (Single Encoding Accented Characters) glyphs and expands
> them if they are.
> The CFF parsing was skipping over the 'shotint' operator (itself an awful hack)
> instead of pushing the value onto the stack. If the shortint was the index
> for a /Subr this led to the wrong Subr being called. Because Subrs expect
> parameters on the stack, calling the wrong one leads to stack cuorruption
> and in this case caused a crash.
> No differences expected.
> gs/base/gxtype1.c

2011-11-08 02:40:09 -0500
Alex Cherepanov <alex.cherepanov@artifex.com>
3c5ba8fd910be3985212b104f2c111556db4b871

> Bug 692648: dead code in gdevcp50.c
> Remove ineffective error checks after functiom calls. Real error
> processing is done at the end of the function, when device is
> closed. Found by Coverity.
> gs/base/gdevcp50.c

2011-11-08 02:16:57 -0500
Tim Waugh <twaugh@redhat.com>
5915259f6800b600fff1af9e4d40f5dddee8f477

> Bug 692649: dead code in gxi12bit.c and gxicolor.c
> The dead fragments are rudiments (rather than logic problems)
> and so can be safely removed. Found by Coverity.
> gs/base/gxi12bit.c
> gs/base/gxicolor.c

2011-11-08 01:57:42 -0500
Alex Cherepanov <alex.cherepanov@artifex.com>
724390c14c6f52489d83df18f7cfcd6a4be7bced

> Bug 692647: Mistaken comparison instead of assignment.
> Fix two obvious typos in a contributed Japanese driver.
> gs/contrib/japanese/gdevmjc.c

2011-11-08 01:33:49 -0500
Alex Cherepanov <alex.cherepanov@artifex.com>
595309e7b1883b985756510ee210bd3176a0da3a

> Bug 692598: bad sizeof() usage in gxfcopy.c
> Use the right type to calculate the size of an array of unsigned long.
> Old code used sizeof(gs_glyph *) instead of sizeof(unsigned long).
> Memory corruption was possible when sizeof(long) > sizeof(void *).
> The problem was found by Coverity.
> gs/base/gxfcopy.c

2011-11-08 01:26:56 -0500
Alex Cherepanov <alex.cherepanov@artifex.com>
4a6124a3870a07ff19562559e6d155560d22c01d

> Fix a typo s/elseif/elsif/ in clusterpush.pl
> gs/toolbin/localcluster/clusterpush.pl

2011-11-07 10:53:09 -0700
Henry Stiles <henry.stiles@artifex.com>
91ce46e08ae37a9c5116bc379b7712c10df5a8f2

> Fix 692614 - the unsolid pattern should be used when the gl/2 white
> pattern is specified. Also, progressions noted in PCL5 CET 32-01.
> pcl/pcpatrn.c

2011-11-07 16:52:38 +0000
Robin Watts <robin.watts@artifex.com>
a4230e24b386ac647b0562cb2bf34c25043a1903

> Change to clusterpush to allow filters.
> Change here (and throughout cluster code) to allow filtering of the jobs
> to be scheduled.
> Rather than simply doing:
> clusterpush.pl gs
> you can now do:
> clusterpush.pl gs filter=ppmraw
> and have it only test the ppmraw files. Or you can specifiy a list
> of filters that must all pass:
> clusterpush.pl xps filter=ppmraw,xpsfts-a4
> This will test the xpsfts-a4 files through the ppmraw device only.
> Or you can specify several filters to broaden the scope:
> clusterpush.pl gs filter=ppmraw,72 filter=pgmraw,300
> And it will test ppmraw files at 72 dpi and pgmraw files at 300dpi.
> The filtering is done on the 'test' string formed by the cluster
> code (that is, test__file__path.device.res.band)
> gs/toolbin/localcluster/clusterpush.pl

2011-11-07 12:10:16 +0000
Robin Watts <robin.watts@artifex.com>
ab54e1549793df22e0eddf43033494ea6ab0544b

> Fix for (part of) Bug 692513. (xps pattern white lines)
> XPS renders with the "pixel centres covered" rule, rather than the
> "any part of a pixel" rule. As such fill_adjust is 0. This exposes
> limitations in ghostscripts pattern tile handling code.
> When we come to create a pattern tile, if the pattern is (for instance)
> 7.5x7.5 device pixels in size, we round this to the nearest integer
> and end up with an 8x8 pattern tile. For PS/PDF (which has a non zero
> fill_adjust) the pattern will still cause the entire range of pattern
> pixels to be drawn.
> With XPS (and it's 0 fill_adjust) the patterns frequently leave gaps
> around the edge of the enlarged tile, resulting in white lines in the
> final image.
> My first attempt at a fix for this was to scale the pattern up by
> the appropriate amount to ensure it filled the pattern tile (8/7.5
> in the example). This works, but causes thousands of diffs; having
> examined them all in a bmpcmp, it feels like a win, to me.
> However, consulting with Tor and Michael and checking the XPS spec
> leads me to believe that that we shouldn't be using TilingType 1
> anyway; xps patterns are supposed to be accurately positioned (if not
> accurately rendered). As such we should be using TilingType 2.
> The patch here therefore forces XPS to use TilingType 2. This does not
> solve the problem in itself, as we can still get these white lines.
> Furthermore the definition of what TilingType 2 does in postscript
> prohibits us from scaling the pattern cell.
> The solution adopted here, therefore, is to spot that we are using
> TilingType 2, and a fill adjust of 0, and to translate the pattern
> by half the change in size; this should ensure that 'edge to edge'
> pattern cells should cover all the pixel centres appropriate and
> the white lines should disappear.
> This appears to work except for one disappearing grid in Page 2 of
> tests_private/xps/xpsfts-a4/fts_01xx.xps.ppmraw.72.0. I will look
> into this before pushing this commit.
> gs/base/gscoord.c
> gs/base/gscoord.h
> gs/base/gsptype1.c
> xps/xpstile.c

2011-11-06 13:54:03 -0800
Ray Johnston <ray.johnston@artifex.com>
61074849e40ec86302e06bf0ef18f0872f8cf99a

> Fix bug 692623. clist_get_data and clist_put_data changed to use int64_t offset.
> The above functions are used by gx_dc_pattern_read_raster and gx_dc_pattern_write_raster
> which are instances of the dev_color_proc_read and dev_color_proc_write procs of the
> gx_device_color_type_s struct. The definitions for all color types is changed to use
> int64_t (as well as the prototype) and the stdint_.h is added to gxdcolor.h.
> gs/base/gsptype1.c
> gs/base/gxcht.c
> gs/base/gxclist.c
> gs/base/gxclist.h
> gs/base/gxdcolor.c
> gs/base/gxdcolor.h
> gs/base/gxht.c
> gs/base/gxwts.c
> gs/base/lib.mak

2011-11-07 13:28:56 +0000
Ken Sharp <ken.sharp@artifex.com>
b9bcbb7d1ae61b2ccf5a6761a176ead71d327d27

> Fix a couple of benign compiler warnings.
> gs/base/gdevpdtw.c

2011-11-07 02:17:07 -0500
Tim Waugh <twaugh@redhat.com>
d1440326b1ef9a8aa539e9a2a6f8d0c32b1e879b

> Bug 692651: fix possible 0 dereference in error handler.
> At the end of gstate_alloc_parts(), gstate_free_parts() might be
> called with parts->path == 0; but gx_path_free() will de-reference it.
> Found using Coverity.
> gs/base/gsstate.c

2011-11-07 10:48:42 +0000
Chris Liddell <chris.liddell@artifex.com>
c4e3f9c1d245e374eb30cc179e27bdcd2746812c

> Bug 692661: setup dict and op stacks for executing a "charproc"
> When an (invalid!!) Type 1 font has a procedure instead of a charstring
> we weren't setting up the stacks correctly in FAPI before executing the
> proc.
> No cluster differences.
> gs/psi/zfapi.c

2011-11-07 09:57:41 +0000
Ken Sharp <ken.sharp@artifex.com>
63a5fe390d2534f6b48e2dd58f46ed9941582e83

> pdfwrite - Improve font naming when standard fonts are not embedded.
> Bug #692608; When the input is PCL, 'standard' font names are used (eg Courier),
> and font embedding is false, the output PDF file contains the names of the
> URW fonts which are used as substittues for the standard fonts.
> This means that the resulting PDF needs to be read on a system with URW fonts
> installed, or the fonts will be substituted, which may result in poor choices.
> By instead embedding the correct original (standard) font name we can get
> better substitution.
> Thanks to Hin-Tak Leung for the original work and the patch which has been
> adopted with slight modifications to pacify compilers.
> No diffreences expected.
> gs/base/gdevpdtb.c
> gs/base/gdevpdtb.h
> gs/base/gdevpdtd.c
> gs/base/gdevpdtw.c

2011-11-07 00:27:34 -0500
Tim Waugh <twaugh@redhat.com>
184e6fe81072d94489223ce4d4a9ba085843258c

> Bug 692653: fix base pattern color space check.
> Old code tested an uninitialized value instead of the base color
> space, found using Coverity.
> gs/base/gsptype1.c

2011-11-06 10:59:41 +0000
Chris Liddell <chris.liddell@artifex.com>
850145bc08fd8ebcc4cc9c6827cde750d9ed9acf

> Bug 692470: remove sscanf() in CFF code
> On Linux (at least) the locale affects the behaviour of sscanf(): certain
> languages use a comma (",") for the decimal point, rather than a full stop
> ("."). Setting one of those locales (such as Spanish) causes sscanf() to fail
> when parsing a number with a fractional component in the CFF interpreter.
> Replace the sscanf() call in the CFF interpreter with a call to Ghostscript
> PS interpreter's internal scan_number() function which is unaffected by locale.
> No cluster differences.
> gs/psi/zfont2.c

2011-11-04 10:02:38 +0000
Chris Liddell <chris.liddell@artifex.com>
2a3a329ab0ee0e2f4971ee0327ae78d532399619

> Bug 692646: remove bad call to memcmp()
> The memcmp() to compare the matrices (to decide if we need to rescale the font)
> was the address of the pointer to the matrix, rather than the pointer itself.
> This change addresses that by changing the memcmp() to an explicit check for
> the equality of each element of the arrays. The reason I've opted for this is
> because, for example, [1 -0 0 1 0 0] == [1 0 0 1 0 0] which an explicit
> equality check will evaluate correctly, but a memcmp() will fail the check.
> This causes what seems to be a progression in comparefiles/Bug689006.pdf.
> Other than that, no cluster differences are expected.
> gs/psi/zfapi.c

2011-11-03 18:00:41 +0000
Chris Liddell <chris.liddell@artifex.com>
42146da35d49aa1debc683d7285fcd8cefc1f9f8

> Let configure check for time.h
> Recent Linux distributions defeat the check in unix-aux.mak for sys/time.h
> with the hard coded path. So have configure check for it, and its
> setting take precedence over the unix-aux.mak.
> No cluster differences.
> config.mak.in
> configure.ac

2011-11-02 19:32:04 +0000
Robin Watts <robin.watts@artifex.com>
d42d005f6adcb9e6911418a6b61c43df87fb7513

> Fix for (part of) bug 692513.
> When drawing the a radial shading, we approximate the join between the
> two circles by 4 tensor patches based on joining the 4 quadrants of
> the circles in question. The order in which these were being drawn was
> causing unexpected overwriting of pixels.
> Here I have rejigged the order in which they are drawn to solve the
> problem.
> Cluster testing shows various progressions, and only one regression.
> This has been noted as Bug 692657, and shows signs of it being an
> independent bug.
> gs/base/gxshade1.c

2011-11-02 19:34:50 +0000
Robin Watts <robin.watts@artifex.com>
1bcd6274fbe15784fa0726f234b0608b994abbd7

> Fix MEMENTO build; pacify valgrind code was in the wrong place.
> I'd added a memset to pacify valgrind, but had left it in the
> middle of variable declarations; gcc was accepting this, but
> MSVC was (rightly) complaining. Simple fix is to move it down.
> CLUSTER_UNTESTED as cluster does not test MEMENTO builds.
> gs/base/gxcht.c

2011-11-03 11:11:27 +0000
Ken Sharp <ken.sharp@artifex.com>
cc592c4162673a99932cdcdc64b39e0abe5aff9e

> Further enhance txtwrite output; detect blocks of text.
> Yet another output mode for txtwrite will now attempt to detect blocks of
> text and output the blocks. This is similar to the MuPDF '-ttt' output
> but, since the algorithm is entirely different, the output will not be
> identical.
> Updated the documentation in devices.htm.
> No differences expected, txtwrite is not regression tested.
> gs/base/gdevtxtw.c
> gs/doc/Devices.htm

2011-11-02 15:10:25 -0700
Michael Vrhel <michael.vrhel@artifex.com>
65486b6c7533f0be9e15a8380729fdb5032e0bef

> Fix for bug 692639. PDF14 mono device initialization.
> With the fix of the max_gray initialization in pdf14 device to avoid halftoning during interpolation of images (see description in 2b91a85069d421465220a83c82ea491733d15017)
> a conflict occurred when checking if the device was separable and
> linear. Setting of the dither_grays for the pdf14 gray device
> fixes this issue.
> gs/base/gdevp14.c

2011-10-31 12:36:29 +0000
Robin Watts <robin.watts@artifex.com>
e4a9ab0594ccb8beb43c0bc83ba0b41deeb128ff

> Fix stroke_adjust logic; apply adjust in fewer cases.
> In 'adjust_stroke', we decide whether to apply stroke adjustment or not.
> With the logic as it stands, the only time we DO NOT apply stroke
> adjustment is when stroke adjustment is disabled, AND we have a diagonal
> stroke segment.
> My understanding of stroke adjustment is that it is only supposed to
> apply when we have a horizontal or vertical line, AND when it is
> configured on. In line with this, I have changed the logic so that
> we DO NOT apply stroke adjustment either when stroke adjustment is
> disable, OR we have a diagonal stroke segment.
> This produces many thousands of differences in the cluster testing, but
> having looked through the first bmpcmp load of them (1000 files), they
> all look to be exactly as expected with no changes so horrific as to
> stop this commit.
> gs/base/gxstroke.c

2011-10-30 02:45:48 -0400
Tim Waugh <twaugh@redhat.com>
78727e97d82435052df2f8e0333e47671bafbc59

> Bug 692594: gdevijs: add missing error check.
> Add missing error check, found using Coverity.
> gs/base/gdevijs.c

2011-10-30 00:20:30 -0400
Tim Waugh <twaugh@redhat.com>
8adebdf0f6e87f36792637ff88db874ea86fd803

> Bug 692596: fix memory leaks in rinkj-epson870.c.
> There were a few memory leaks in rinkj-epson870.c in error handling
> branches, found using Coverity.
> gs/base/rinkj/rinkj-epson870.c

2011-10-29 23:46:28 -0400
Tim Waugh <twaugh@redhat.com>
af01406940d211167c202cbc54c3ff7ad31d5c0e

> Bug 692595: fix memory leaks in gp_unix_cache.c
> There were some memory leaks in gp_unix_cache.c, found using Coverity.
> gs/base/gp_unix_cache.c

2011-10-29 20:03:40 -0700
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
9c803e62759fd9d38c088aa8c24d71640ecfb51d

> Added a final return to --debug message.
> gs/base/gsmisc.c

2011-10-29 21:54:51 -0400
Tim Waugh <twaugh@redhat.com>
66567074a91d05a27f2439cbcc43e2d2301a776f

> Bug 692597: bad sizeof() usage in base/sdcparam.c
> Taking sizeof() of an array parameter gives the size of the pointer,
> not the array; found using Coverity.
> gs/base/sdcparam.c

2011-10-29 18:14:14 -0400
Tim Waugh <twaugh@redhat.com>
4c00d4bc5eb87191674463af9444c457ac361c07

> Bug 692599: fix bad sizeof() usage in base/sha2.c
> sizeof() was being used incorrectly in base/sha2.c,
> found using Coverity.
> gs/base/sha2.c

2011-10-29 14:09:56 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
6116f7e9633c7c112c09c048b317de34c060ba5b

> Bug 692502: add missing dereference of an indirect object.
> Fix access to indirect /Names and /Nums objects in name and number
> trees, respectively.
> gs/Resource/Init/pdf_base.ps

2011-10-29 16:47:58 +0100
Chris Liddell <chris.liddell@artifex.com>
d8089a9dcf0971a1131f8391049c602a61852f65

> Bug 692634: handle skipping "cached" outline glyphs
> Avoid trying to access a FAPI outline when glyph scaling has collapsed to zero.
> No cluster differences.
> gs/psi/zfapi.c

2011-10-28 15:45:56 +0100
Robin Watts <robin.watts@artifex.com>
38e7372c539bcc6174c42be2d438d8311da2cff2

> Fix ppm color reversal in bmpcmp.
> When I did the recent speedups, I inadvertantly reversed the rgb order
> when reading ppm files. Fixed here.
> gs/toolbin/bmpcmp.c

2011-10-28 01:59:47 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
6dc04dcacd37256f8d0c61cec49975ba67297873

> Bug 692590: Ignore self-referencing /SMask attribute.
> Check whether /SMask attribute points to its own dictionary and
> ignore it when it does.
> gs/Resource/Init/pdf_draw.ps

2011-10-19 13:26:44 -0700
Ray Johnston <ray.johnston@artifex.com>
7b2b1f7f7989ab0106627f420e7a4848619355df

> Fix enhancement bug 692615: Create a platform specific hook to set the serialnumber
> The main change is to add the hook, but for common platforms, try to get a reasonably
> unique serialnumber based on the hardware (we hope). Initial platform in this patch is
> only Windows. We would like to support linux/unix and mac OS/X. If the mechanism fails,
> just return gs_serialnumber set from GS_SERIALNUMBER in gscdefs.c
> gs/base/gp.h
> gs/base/gp_dvx.c
> gs/base/gp_mac.c
> gs/base/gp_msdos.c
> gs/base/gp_os2.c
> gs/base/gp_unix.c
> gs/base/gp_vms.c
> gs/base/gp_wgetv.c
> gs/psi/imain.c
> gs/psi/zmisc.c

2011-10-22 23:51:42 -0700
Michael Vrhel <michael.vrhel@artifex.com>
2b91a85069d421465220a83c82ea491733d15017

> Fix for Bug 692505 XPS patterns with transparency.
> There were essentially three issues two in the xps interpreter and one in the graphics library.
> First in the xps interpreter we need to know if the pattern object has transparency and to
> set up the pattern object for the graphics library so that the graphics library will
> know to push the pdf14 device on the pattern accumulator object.
> We also had the issue that we were not undoing the pre-multiplied alpha in the tiff image
> in the interpreter.
> Second issue is that in ghostscript, we call pattern_paint_finish from
> the pdf interpreter when we are all done setting things up for the pattern. This is now
> handled prior to the call before gx_pattern_cache_add_entry which is where it is done in
> pattern_paint_finish.
> Also, some debugging of the mask stack was added in gdevp14.c. This was needed to track down
> a bug that become visible when I added in the pattern transparency support. The issue
> was that the parent PDF14 device may often have a valid soft mask in its mask stack if there
> had been a previous soft mask push. Since we made the soft mask state be part of the q Q
> operations in the PDF interpreter (the soft mask is actually part of the extended graphics state
> in PDF), we have to make sure to pop the soft mask we we are all
> done using it in the XPS interpreter. I added the appropriate commands for that.
> There was also an issue that cropped up with the pdf14 device and the interaction of the image
> interpolation code. We always interpolate image in XPS and it turned out that if we had an
> opacity mask pattern created with an image we installed a gray pdf14 device for the pattern.
> The interpolation code was incorrectly using halftoning for the pdf14 gray device due to the
> color info settings in that device.
> This commit results in many progressions in PDF and XPS (450 differences). In PDF, if the
> target was a gray devices and the content had
> interpolated images with transparency we see progressions due to the fact that we were improperly
> halftoning the images when the trans device is a contone device. In XPS, several missing
> figures now are visible and we correctly handle tiling with objects that have transparency.
> gs/base/gdevp14.c
> gs/base/gxpcmap.c
> gs/base/lib.mak
> xps/xpsgradient.c
> xps/xpsimage.c
> xps/xpsopacity.c
> xps/xpstile.c

2011-10-27 13:44:05 +0100
Robin Watts <robin.watts@artifex.com>
58722d520578050aad3d81c0f5fb477bc701a944

> Fix warning; initial_decode was declared to return an int rather than void.
> initial_decode never returns a value, neither does any caller check for
> one. Change it to be void.
> gs/base/gxiscale.c

2011-10-27 13:24:08 +0100
Robin Watts <robin.watts@artifex.com>
f75ccf57f4d052652204f6508f4f9949d3448840

> Correct direction of implication for gs_debug_flags.
> I had incorrectly implemented the implication table; a => A rather than
> A => a. Corrected here.
> CLUSTER_UNTESTED
> gs/base/gdbflags.h
> gs/base/gdebug.h
> gs/base/gsmisc.c

2011-10-27 10:42:18 +0100
Ken Sharp <ken.sharp@artifex.com>
59b1c64adb147a209b6468a669146edf13973a4b

> Make txtwrite 'XML' output compatible with MuPDF output.
> The txtwrite device now outputs 'XML' (something like XML) in a compatible
> fashion to the '-ttt' output from MuPDF. It does not yet attempt to create
> blocks of text, it just outputs the data it received as it received it,
> there is no ordering of the data whatsoever. The format is compatible with
> the MuPDF format though.
> No differences expected, txtwrie is not cluster tested.
> gs/base/gdevtxtw.c

2011-10-24 16:07:50 -0700
Ray Johnston <ray.johnston@artifex.com>
97e6cdad5061fe92d16aae87524fe985c8436796

> Fix bug 692618. Crash and Object not in any chunk error and VMerror.
> Actually two problems showed up after the previous commit related to this bug. A crash
> could occur (or cause "Object not in any chunk") because the pdf14 device did not use
> stable_memory for separation names. The second issue was a VMerror when the decision
> for banded (clist) mode was flawed, because if the device supported separations the
> estimates for transparency buffers was too small because the call to
> gdev_prn_allocate_memory was sometimes called with new_width, hew_height = 0,0 which
> expected the 0,0 to be ignored. The new_width and new_height are only used from
> gdev_prn_reallocate_memory.
> The non-encodable pixel issue still remains.
> gs/base/gdevmem.c
> gs/base/gdevp14.c
> gs/base/gdevprn.c
> gs/base/gstrans.h
> gs/base/lib.mak

2011-10-26 16:40:30 +0100
Chris Liddell <chris.liddell@artifex.com>
cf8815855af78ddc9d4d9bebafbb21bff603e71d

> Bug 692605: resolve FAPI/UFST matrix clash
> The Microtype fonts require a unit design grid, but many jobs assume that the
> standard fonts set have a design grid of 1000x1000. For those two conflicting
> requirements to be satisfied, the UFST integration layer has to compensate
> for the scaling.
> As usual with the UFST code, that exposed a host of other problems, including
> failing to produce a bitmap sometimes when one is require for the glyph cache
> and failing to handle a glyph too big for UFST to image (i.e. fallback to an
> outline) in some cases.
> No cluster differences expected.
> gs/Resource/Init/gs_fapi.ps
> gs/psi/fapiufst.c
> gs/psi/zfapi.c

2011-10-25 20:30:29 +0100
Robin Watts <robin.watts@artifex.com>
8e8f10150dd2404757d648a1568c1002dd5310b4

> More gs_debug_flags fixes.
> Today, I am less than competent. Hopefully this will fix it.
> My previous attempt to move gs_debug_flags from header to c file was
> thrwarted by my missing an 'extern' out.
> This now compiles on both linux and windows without warnings, I think.
> gs/base/gdebug.h

2011-10-25 20:19:24 +0100
Robin Watts <robin.watts@artifex.com>
b5f56c0c13c92232c9f77b548476fa10f1aec28f

> Fix silly mistake in gs_debug_flags changes.
> I'd inadvertently caused the gs_debug_flags tables to be built in every
> object that included gdebug.h.
> Move them into gsmisc.c.
> gs/base/gdebug.h
> gs/base/gsmisc.c

2011-10-25 19:37:52 +0100
Robin Watts <robin.watts@artifex.com>
f1a8b636cc4fe9419b31ed21c62b6e8d40fa4f1e

> Fix warning; remove static definition for non-existent function.
> I added, then removed a function, and left a static prototype in place
> that was causing a warning. Remove that.
> CLUSTER_UNTESTED.
> gs/psi/imainarg.c

2011-10-25 19:04:13 +0100
Robin Watts <robin.watts@artifex.com>
370a5fae98c76c76df84ad35f79ce849a7ecf015

> Add 'implication' table for gs_debug operations.
> Previously setting an upper case debug flag would imply the lower case
> equivalent. Now we extend (break) that system so that any flag can
> imply any other flag (and indeed we can have a chain of implied flags).
> This frees up lots of uppercase flags for us to use.
> gs/base/gdbflags.h
> gs/base/gdebug.h
> gs/base/gsmisc.c

2011-10-25 16:27:57 +0100
Robin Watts <robin.watts@artifex.com>
d644cdc4b16cb92a70af3fea16c40cd39bc700a6

> Add new 'long form' debugging flags.
> Add a table of 'known' debugging flags to ghostscript (gdbflags.h). These
> list all the currently defined -Z flags, together with 'long form' names
> for them (i.e. --debug=tiling will do the same as -Zt).
> Add a new routine to list the known flags (and hook this up so that
> --debug on the command line lists the flags).
> Add a new routine to parse a set of flags passed to --define= on the
> command line (and hook that up).
> The code that does:
> if_debug6('c',...)
> all remains unchanged, but we now have the ability to add new flags,
> and to do:
> if_debug6(gs_debug_flag_whatever, ...)
> in the same way. This frees us from the limitations of only having
> a limited number of easily representable 'character' flags.
> gs/base/gdbflags.h
> gs/base/gdebug.h
> gs/base/gsmisc.c
> gs/doc/Use.htm
> gs/ghostscript.vcproj
> gs/psi/imainarg.c
> pl/plmain.c

2011-10-17 21:12:40 +0100
Robin Watts <Robin.Watts@artifex.com>
b7bcf1a9efdbcd8c0ebac2eeece8c81f61d18396

> Tiny whitespace fix.
> CLUSTER_UNTESTED.
> gs/base/gxicolor.c

2011-10-25 08:28:31 -0600
Henry Stiles <henry.stiles@artifex.com>
f9f50966fe6baecb1c9ebefa44594e7c21d9d194

> Make common warning message only output when pcl font parsing
> debugging is enabled (-Z=).
> CLUSTER_UNTESTED
> pl/plfont.c

2011-10-25 10:05:53 +0100
Ken Sharp <ken.sharp@artifex.com>
cf7e75532e0f16c819954b71a686fb5b83c47c61

> Add UTF-8 as an output option to the txtwrite device.
> The TextFormat parameter now has three values; 0, 1 or 2 to allow for 'XML'
> output with full information, simple UCS2 or simple UTF-8 output.
> Altered the meanings of the TextFormat so that 0 is now the 'XML' output
> which allows a more sensible selection of 1 for UCS2 or 2 for UTF-8, since
> these output foramts are otherwise identical. Modified the default to be
> '2' (UTF-8).
> Updated the documentation in devices.htm.
> Also removed a number of C++ comments.
> No differences expected, this device is not cluster tested.
> gs/base/gdevtxtw.c
> gs/doc/Devices.htm

2011-10-24 16:48:44 +0100
Ken Sharp <ken.sharp@artifex.com>
b5fa52b7e60a7eb23b77c4fd117ed37eb04263b5

> Bug #692621 Ensure that when copying width information, we create an array as large as the new MaxCID value
> Commit 312255297353a9f62b5090e9137586a8ecfc8601 create the new MaxCID entry
> for CIDFont type 0 fonts which use a GlyphDirectory. We must use the same
> value when creating the arrays to store the widths of the glyphs, or we will
> no have a large enough array, leading to soem glyphs getting the Default Width.
> No differences expected
> gs/base/gdevpdtt.c

2011-10-22 19:43:48 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
33e827eb32d282a550e2f7a9fdb786dd777b0903

> Bug 692622: spurious warnings on Indexed colour spaces.
> Fix indexed color space processing code that miscalculated
> the length of an index table when the table stream was compressed.
> gs/Resource/Init/pdf_draw.ps

2011-10-20 22:11:00 -0700
Ray Johnston <ray.johnston@artifex.com>
7ebbcae24116a37b2f32f52bc7330383752f903f

> Fix bug 692618. Clear pointers to compressed color structured in pdf14 device.
> After the devn compressed color structures were freed, the pointers were not reset to
> NULL so subsequent GC would trace into freed or re-used memory. -Z? showed errors and,
> depending on memory contents and usage could result in a seg fault. Also add 'mem'
> element to the compressed_color_list structure to be used when freeing to avoid
> confusion about the correct allocator.
> Issue with non-encodable colors is _not_ fixed by this, only the segfault.
> gs/base/gdevdevn.c
> gs/base/gdevdevn.h
> gs/base/gdevp14.c

2011-10-21 23:27:50 -0700
Michael Vrhel <michael.vrhel@artifex.com>
a298a05dcf4ce3f1f530759680a2f65c3e72e3fc

> Fix to handle tiff associated alpha images correctly in XPS
> TIFF images in XPS can come with an alpha channel that may or may
> not be premultiplied. In our existing XPS flow, we currently store
> the alpha channel in a separate channel and treat it as an image mask
> in the graphics library. This is fine, but if the image data was
> premultiplied by the alpha data, we will need to undo this operation
> otherwise we end up applying the mask on image data that is already
> scaled by the alpha data.
> xps/xpstiff.c

2011-10-21 10:52:26 +0100
Ken Sharp <ken.sharp@artifex.com>
312255297353a9f62b5090e9137586a8ecfc8601

> Font copying does not work with CIDFonts using dictioanry form of GlyphDirectory
> Bug #692573, the font copying code uses 'slots' to record glyph data, which
> are entries in an array. The index into the array can be a name or a CID.
> This assumes that CIDCount (the number of glyphs in the font) is the same as
> the maximum CID (ie the range is continuous), which is generally true.
> However, the dictionary form of GlyphDirectory allows for discontinuous CIDs.
> This meant that the array was too small to use the CID as an index.
> Fixing this efficeintly would mean completely rewriting the code in gxfcopy.c
> so that it uses some kind of dictionary structure instead of an array. Instead
> I've chosen to find the highest CID in the font (by enumerating the GlyphDirectory)
> and use that to create he array with enough entries. Inefficient use of memory
> but it saves having to re-architect the code.
> The text that was previously missing is now present, and this reveals a new
> problem, some of the text is incorrectly spaced after conversion with pdfwrite.
> I'll open this as a new bug.
> No differences expected
> gs/base/gxfcid.h
> gs/base/gxfcopy.c
> gs/psi/zfcid.c

2011-10-20 23:04:31 -0700
Michael Vrhel <michael.vrhel@artifex.com>
41faddadc03e389f4f1b3c3d9a4f6bdf36ebbfb1

> Fix for bug 692511 Dash cap rendering in XPS
> There was an issue that we were setting both the end cap and the dash
> caps to the starting cap value for the stroke when we went through
> clist rendering. Page mode worked correctly. Clusterpush shows no
> diffs with XPS rendering since all tests are done in Page mode.
> gs/base/gxclpath.c
> gs/base/gxclrast.c

2011-10-19 23:27:30 -0700
Michael Vrhel <michael.vrhel@artifex.com>
91dc74950f0a9ce391de0f0f1f0be5220a68db04

> Fix for Bug 692510 white space XPS interpreter fix
> XPS interpreter was not very robust in its handling of white space in
> many locations. I created a general function to handle this in place
> of the many uses of sscanf in the interpreter.
> xps/ghostxps.h
> xps/xpsgradient.c
> xps/xpspath.c

2011-10-19 14:53:30 -0700
Michael Vrhel <michael.vrhel@artifex.com>
856eedc584a224bd311fa7688fc29ba487521dfb

> Fix for Bug 692509. Issues with parsing of dashed line attributes.
> Problem was caused by a space preceding the ending quote, which gave
> the dashed line lengths.
> xps/xpspath.c

2011-10-19 10:29:18 -0700
Robin Watts <robin@peeves.(none)>
3d3e4f5d6e83539fc5a5877ef6d1e3591ec25c49

> Memento buld tweak; valgrind warnings quieted for temporary buffers.
> Temporary buffers are used in the planar device and the color halftoning.
> These are uninitialised by default, which means that the last 'part byte'
> transferred is thought of as being undefined in valgrind.
> In memento builds we memset them to 0 to avoid this.
> CLUSTER_UNTESTED as memento builds are not testing in the cluster.
> gs/base/gdevmpla.c
> gs/base/gxcht.c

2011-10-19 10:25:27 -0700
Robin Watts <robin@peeves.(none)>
99f7cf83e2bef8b1d61126c065328f7f91ba1fce

> Add some more excludes to the clusterpush.pl rsync.
> Specifically, avoid the memento, profiling and 64bit directories
> as well as any .pngs.
> CLUSTER_UNTESTED.
> gs/toolbin/localcluster/clusterpush.pl

2011-10-19 10:23:14 -0700
Robin Watts <robin@peeves.(none)>
bace25f82cd2d84d951a33eb5a9797435f50b836

> Remove rop_source member from gxp1fill.c
> When set, this member variable was only ever set to be the same as
> the 'source' member variable, and then forced to be non-NULL.
> By doing this forcing at the last moment, we get exactly the same
> behaviour with less confusing code.
> No differences shown during cluster testing.
> gs/base/gxp1fill.c

2011-10-19 17:31:47 +0100
Chris Liddell <chris.liddell@artifex.com>
e383ccc9e7f56435a8f89cf65125ee1eb6a880e5

> Fix FAPI charpath handling.
> The way FAPI appended the segments of a charpath to the current path was
> incorrect, and in extremely rare cases could cause an error (due to an
> attempt to draw outside the established bounding box in the path
> structure).
> ps3cet/11-20.PS now runs without a "Font Renderer Plugin .... error"
> Other than 11-20.PS, no cluster differences expected.
> gs/psi/zfapi.c

2011-10-18 22:12:24 -0700
Michael Vrhel <michael.vrhel@artifex.com>
357009d7fc55166a6e8f9da539e1f785d05e9b6c

> Maintain 16bit precision in threshold array creation.
> Also add option to output either 8bit or 16bit data
> including a type 16 halftone dictionary
> gs/toolbin/color/halftone/halfttoning/halftone.c

2011-10-17 12:26:17 -0700
Ray Johnston <ray.johnston@artifex.com>
4d0f6ec0fc64eba04cc85693d16bc7158599578b

> Fix bug 691978: Ignore PS vmreclaim requests for GC. Only GC when vmthreshold exceeded.
> Some poorly designed PostScript creators make liberal use of '2 vmreclaim' which would
> trigger a full GC (mark/scan/reloc) pass each time. The document with the bug did this
> > 10,000 times. Since the vmthreshold already triggers GC when the allocated amount
> exceeds the threshold, we don't need to really do anything when a job requests GC.
> Change "internal" (infrequent) interpreter uses to use '2 .vmreclaim'. Speeds up the
> file from the bug by 79X !
> Also fix areas that didn't update i_ctx_p after running the interpreter (which may do
> a GC) and a minor typo in gs.c noticed while scanning for all instances of this.
> gs/Resource/Init/gs_init.ps
> gs/Resource/Init/gs_lev2.ps
> gs/psi/gs.c
> gs/psi/idisp.c
> gs/psi/imain.c
> psi/psitop.c

2011-10-17 20:48:26 -0700
Michael Vrhel <michael.vrhel@artifex.com>
bcfc1a94c76d84511cec09673e220b8bf15823e9

> Make it possible to output turn on sequence for ordered dithered screens
> This enables us to use the linearize_threshold program that Ray wrote to apply a TRC
> to our screen.
> gs/toolbin/color/halftone/halfttoning/halftone.c

2011-10-17 15:57:50 -0700
Michael Vrhel <michael.vrhel@artifex.com>
253285f2a4cb681d601817185d6dba083d8b117e

> Addition of support for different vertical and horizontal resolution in ordered dithered screen creation.
> The support for this was already in place in the code. It was only was a matter of getting the parameters set.
> gs/toolbin/color/halftone/halfttoning/halftone.c

2011-10-17 20:15:56 +0100
Robin Watts <Robin.Watts@artifex.com>
312a786bd935908c2c0c0cb428ae066b7f01a8e3

> Fix pxlasm.py on windows.
> pxlasm.py outputs to stdout. On windows stdout is not binary safe by
> default. Fix it with a couple of lines cribbed from stackoverflow.
> I have now successfully used pxldis and pxlasm on windows.
> tools/pxlasm.py

2011-10-17 11:08:18 +0100
Robin Watts <Robin.Watts@artifex.com>
0f20243b7ec6ea8f6a9b7826ac8ca2e1cebbacda

> Fix longstanding color halftone limitation.
> gx_dc_ht_colored_fill_rectangle in gxcht.c contains a long standing
> limitation (bug/defect), in that when doing strip_copy_rop with
> subrectangles, it fails to offset the source samples for each call.
> This is noted in the form of a comment.
> This is fixed here.
> There appears to be an underlying bug in this code (or in the code it
> calls) in that the 'optimisation' case (do it all in a single
> tile, rather than subdividing) gives different results to the normal
> (subdividing) case. See bug 692609.
> This can be shown with tests_private/pcl/pcl5cats/Subset/PWEP6SC1.BIN
> at 300dpi with or without banding to the plank or pamcmyk4 device.
> The limitation that this patch fixes does NOT solve the problem - but
> I fixed it in the hopes that it would. Committing the code here as it's
> an improvement anyway.
> gs/base/gxcht.c

2011-10-17 00:35:20 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
85e64010450ebafb453b4028356a6ccd20e440b8

> Bug 692574: libjasper: creating temp failed due to buffer overflow.
> Increase the size of a temp file buffer to accomodate larger path names
> needed for mkstemp (instead of tmpnam that was used originally).
> Thanks to Henk Jan Priester for the patch.
> gs/jasper/src/libjasper/include/jasper/jas_stream.h

2011-10-14 23:00:03 -0700
Michael Vrhel <michael.vrhel@artifex.com>
2e92d2916a189d19213d830956a2e02f7cfb6872

> Addition of dot shape specification in ordered dither screen threshold array creation.
> This provides a number of example dot shapes including, circles, diamonds, lines and
> inverted circles. Also cleaned up the code a bit.
> gs/toolbin/color/halftone/halfttoning/halftone.c

2011-10-14 19:17:34 +0100
Ken Sharp <ken.sharp@artifex.com>
9cbeac223ffa44dd6cac3954e1f420501d5f29ae

> Silence a clang warning
> gs/base/gdevpdtt.c

2011-10-14 17:07:38 +0100
Robin Watts <Robin.Watts@artifex.com>
7b498fc5e1d0532f60e70e244edfc58bbeb18a50

> Fix planar device bug; tiles becoming corrupted on gc.
> The relocation code for memory devices had not been updated to cope
> with planar stuff; as such only the first 'mdev->height' line pointers
> were being updated. This was showing up in plank vs pamcmyk4 testing
> as some planes of patterns being corrupted.
> gs/base/gdevmem.c

2011-10-14 15:17:49 +0100
Ken Sharp <ken.sharp@artifex.com>
419d3f8f787d90a71623b27100972eca64d03cc1

> Better preservation of PDF text rendering modes in pdfwrite.
> Bug #688267, #692243. The 'swapcolors' is now moved into pdfwrite, instead
> of being performed in PostScript in the PDF interpreter. The 'spaced'
> variants of show now perform simlar techniques to the 'pdfwrite' text rendering
> routines, when teh device supports text rendering modes.
> Caveats: pdfwrite always emits text enclosed in gsave/grestore. Because of
> this we cannot preserve any of the text rendering modes involoving clipping
> as the grestore also restores the clip path! So we subtract 4 from the mode
> and emit the text that way, then handle the clip separately.
> Because text_process doesn't expect to receive gs_error_Remap_Color errors
> (which cause the interpreter to run Pattern PaintProcs usually) we can't
> set the stroke colour during text processing (which is how it worked before).
> Instead we set the colours during text_begin. We don't actually write the colours
> to the PDF file at that point though, because that causes problems synchronising
> graphics states. Instead we leave the emission of the colour unchanged, we
> just evaluate the colours in text_begin.
> There is some weirdness in the PDF interpreter which I do not understand.
> Most cases are surrounded by 'currentlinewidth exch.......setlinewidth'
> which preserves the current line width in case we have to change it for
> stroked text. In one case, however, this causes files to fail with an error.
> I have tried without success to unravel the PDF interpreter to figure out
> what is going on. Since I can't work it out I have created a dictionary,
> stored the linewidth in that, and then pulled it back out and restored at
> the end. I did try wrapping a gsave/grestore round the operation (taking
> care to preserve the modfified currentpoint) but that caused even more
> problems. Again I have no idea why.
> I would like Alex to look into this so I'm leaving one of the bugs open
> and re-assigning to him. Also he will probably want to reformat the code
> I've added to the PDF interpreter.
> gs/Resource/Init/pdf_ops.ps
> gs/base/gdevpdfb.h
> gs/base/gdevpdfg.c
> gs/base/gdevpdfx.h
> gs/base/gdevpdte.c
> gs/base/gdevpdts.c
> gs/base/gdevpdts.h
> gs/base/gdevpdtt.c
> gs/base/gserrors.h

2011-10-14 10:40:27 +0100
Chris Liddell <chris.liddell@artifex.com>
83d6f1c5d048d70e89c3e13ef11f87a28e414a7a

> Squash a couple of warning in the previous commit.
> No functional change.
> CLUSTER_UNTESTED
> gs/psi/fapi_ft.c

2011-10-14 10:19:15 +0100
Chris Liddell <chris.liddell@artifex.com>
056c8a6dc2409db6ac06ead1fc1b58b277400b04

> Bug 692578: improve FAPI/FT handling of non-square resolutions
> The previous code only worked correctly for glyphs rotated by a multiple
> of 90 degrees, any interim rotation would show a shearing effect.
> We'll now apply the "non-squareness" scaling in the matrix, rather in the
> resution which we pass to Freetype. We have to do this because Freetype
> treats the resolution as being in "glyph space", which means it is "incorrect"
> for any rotated/sheared glyph.
> No cluster differences.
> gs/psi/fapi_ft.c

2011-10-12 22:16:52 -0700
Ray Johnston <ray.johnston@artifex.com>
b49fc2b7fbd16c81a3480660d27d36ebe94ab6d2

> Fix Bug 692584. Fix wrong sprintf format specifier types. Thanks to Arthur Ford.
> gs/base/gdevtxtw.c

2011-10-11 16:08:00 -0700
Ray Johnston <ray.johnston@artifex.com>
c5cc5db0746981baaad4c07cca370541254e03be

> Fix PDFFitPage when PDF orientation doesn't match page orientation.
> There was logic to determine if the pdf Box (after /Rotate is applied) orientation
> matches the orientation of the PageSize (landscape vs. portrait), but the rotation to
> make the image match the Page orientation was missing. Previously this caused the
> scaling to be wrong and caused the image to be clipped. Adding the 90 degree rotate
> fixes it. Feature needed by customer 531.
> gs/Resource/Init/pdf_main.ps

2011-10-12 20:15:51 +0100
Robin Watts <Robin.Watts@artifex.com>
c6accc37afd5d124c1feaea6481a771f2d1e6662

> Solve more plank rop problems with the clist.
> In the planar memory device, protect against C's broken %. As we don't
> replicate the textures, ensure we only set the size for a single repetition.
> When placing new tiles into the clist, ensure we calculate the number of
> bytes used correctly (previously reuse of tile n would fail as tile n+1
> would have overwritten its data).
> gs/base/gdevmpla.c
> gs/base/gxclbits.c

2011-10-12 17:22:49 +0100
Chris Liddell <chris.liddell@artifex.com>
0d472d36958ba10ce3e5747f91776ad2d53530c7

> Bug 692534: revert to unit matrix for Microtype fonts.
> I changed the MT fonts to use a "conventional" Type 1 font matrix to
> make a Quality Logic file "work" as expected - it's a daft test which
> makes the invalid assumption that the fonts in the standard font set
> will *always* use a 1000x1000 design matrix. That assumption is invalid
> since nothing in the spec dictates that the standard fonts must be Type 1
> (clearly as in this case we're using MT fonts!), nor even that Type 1
> fonts have to use a 1000x1000 font matrix.
> As the change breaks a valid file, to try to satisfy a file which relies
> on an invalid assumption, I'm reverting it.
> CLUSTER_UNTESTED.
> gs/Resource/Init/gs_fapi.ps
> gs/psi/fapiufst.c

2011-10-12 16:59:24 +0100
Chris Liddell <chris.liddell@artifex.com>
1a9f315d20871be0498bd7a1fc94cbd2a47ebc4f

> Bug 692550: address scanline alignment in halftone
> Apply Ghostscript's usual raster memory alignment to interim
> bitmap memory for the threshold halftone code. This ensures
> scanlines are correctly aligned for mem_mono_copy_mono(), and
> prevents a bus error on SPARC.
> No cluster differences expected.
> gs/base/gxht_thresh.c

2011-10-12 16:23:45 +0100
Robin Watts <Robin.Watts@artifex.com>
f6ed8f824fc3ca41ba0296131646d10e29657bda

> Fix more plank rop problems (shown in plank vs pamcmyk4 testing)
> I'd missed one case where we are writing a texture bitmap to the clist,
> so we were only writing the first plane.
> I'd also missed a case when reading bits back from the clist (showed
> up with 1x1 textures).
> gs/base/gxclbits.c
> gs/base/gxclrast.c

2011-10-12 13:36:22 +0100
Chris Liddell <chris.liddell@artifex.com>
d670fb3473fbb455881125086f649e416ea755fe

> Bug 689450: deal with invalid font entry in res dict.
> In the event that an entry in a resource dictionary for a font is or
> references an invalid object type (i.e. not a dictionary), issue a
> warning and use the same logic as we do for a missing font resource.
> For this error, we'll also honor the PDFSTOPONERROR setting.
> In addition, as I was touching the logic around the same place, this
> commit changes the missing font resource case to also honor PDFSTOPONERROR.
> No cluster differences expected.
> gs/Resource/Init/pdf_font.ps

2011-10-12 00:58:50 +0100
Robin Watts <Robin.Watts@artifex.com>
237f8f0204a7e11db79fa60ec21503cfd0953116

> Remove duplicated line from gxicolor.c
> In my previous commit I inadvertantly duplicated a line. Fixed here.
> No ill effects, but removing for neatness.
> gs/base/gxicolor.c

2011-10-11 22:07:39 +0100
Robin Watts <Robin.Watts@artifex.com>
fc7bfc56e9132ade936d92e397cc8820bb8a8115

> Fix uninitialised 'num_planes' in texture for strip_copy_rop call.
> Was causing some differences in plank vs pamcmyk4 testing.
> gs/base/gxcht.c

2011-10-11 10:02:48 -0700
Michael Vrhel <michael.vrhel@artifex.com>
e96836194b0eb6085f59d41feb445d60f946dda9

> Fix of bugs in halftone ordered screen creation code
> This fixes several bugs. Including fixes for issues with modulo operation on negative numbers,
> integer division, faulty logic that prevented maximum lpi screens and non-dithered ordered screens.
> gs/toolbin/color/halftone/halfttoning/halftone.c

2011-10-11 17:36:48 +0100
Robin Watts <Robin.Watts@artifex.com>
fecf36b333ddac3e469512be536a498382741003

> Fix Bug 692569; SEGV in threshold halftoning code.
> penum->xci can be negative in clist rendering of landscape cases.
> The % operator in C is broken (or at least counter-intuitive) so
> the code goes wrong; fix it up with some tweaks to the logic
> afterwards.
> In a future commit, we'll move from % 16 to & 15 (does the right thing,
> and is a lot faster).
> No differences expected.
> gs/base/gxicolor.c
> gs/base/gximono.c

2011-10-10 11:42:29 -0700
Ray Johnston <ray.johnston@artifex.com>
5ce12e824d7e4cb5e54f8ba730cbf6939d20834e

> Fix Bug 692224: Handle transparent background with custom fillpage in pngalpha
> The previous hack looked for the entire page being filled with white and then filled
> with transparent (0xffffffff). With a pngalpha_fillpage we simply fill with that color
> which actually allows the page to be filled with non-transparent white if desired.
> Remove the pngalpha_fill_rectangle hack.
> gs/base/gdevpng.c

2011-10-09 01:10:38 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
f790680acba5c1574728d5ff40124f9e27762d2a

> Bug 692571: Fix ouf-of-buffer access in Luratech jb2 interface.
> Luratech jb2 library can requiet data outside of the input buffer
> if it is fed a corrupted data stream. The old code tried to detect
> this but failed because of the missed signed-to-unsighed promotion.
> gs/base/sjbig2_luratech.c

2011-10-07 21:36:55 +0100
Robin Watts <Robin.Watts@artifex.com>
c760cef454473970972260b5b1c7ab078711e43d

> Resolve more plank/pamcmyk4 differences (banding).
> When coding planar data into the clist, I'd missed the 'short' case,
> and so only the first plane was being coded; this was causing knock
> on effects of rectangles being wrong giving large blocks of color
> in the output.
> gs/base/gxclrast.c

2011-10-07 12:49:09 +0100
Ken Sharp <ken.sharp@artifex.com>
62166be1e0beaa765daf96b77a8e6b1ee99a9b52

> Remove the 'return' from the macro gx_set_dev_color
> Macros shouldn't do a return, its highly surprising to a developer. In addition
> I need access to the return value for pdfwrite, and potentially other
> devices may do so as well. In this case the return value is Remap_color
> which happens when a Pattern is set.
> No differences expected in regression tests.
> gs/base/gsdps1.c
> gs/base/gsimage.c
> gs/base/gspaint.c
> gs/base/gstext.c
> gs/base/gxccache.c
> gs/base/gxdcolor.h
> pl/plchar.c
> pl/pldraw.c

2011-10-06 07:24:57 -0700
Ray Johnston <ray.johnston@artifex.com>
1225753bd332857b02e546d20bc35d821fd20f58

> Improve PDFFitPage to center the PDF Box on the page.
> This was requested by customer 531 and seems reasonable. We didn't document exactly
> where the PDF was placed on the page after 'fitting', so centering seems like an
> acceptable behavior, so I didn't add a command line option to lower/left position.
> If we get any complaints, we can add this.
> gs/Resource/Init/pdf_main.ps

2011-10-05 11:30:21 -0700
Ray Johnston <ray.johnston@artifex.com>
d5f1e72357d77dbb03abe0442ac8b8b09d27ceb6

> Fix bug 692568. Set up initial clist_color_info to match pdf14 device.
> For the funky RGBW device, since it is 4 component additive color the pdf14 logic chose
> a pdf14_clist_RGB_device which has 3 components and a depth of 24. The clist logic uses
> the clist_color_info.depth which was never set correctly to match the pdf14 device (depth
> = 24), so it wrote 32-bits and only read 24, causing the clist reader to bomb.
> gs/base/gdevp14.c

2011-10-04 10:30:56 -0700
Ray Johnston <ray.johnston@artifex.com>
49e6b0c7144a4a694271e2f24edf03b16ecc14e1

> Require CUPS_DEBUG2 to enable noisy gdevcups messages instead of just DEBUG
> Using a DEBUG build with the cups device was extremely slow and painful for complex
> files. This is easy to enable via build -DCUPS_DEBUG2 or uncommenting the #define
> in gdevcups.c
> gs/cups/gdevcups.c

2011-10-03 19:51:15 -0700
Michael Vrhel <michael.vrhel@artifex.com>
77e2fb25375f50389bfe6942507a0a513fa83ee9

> Fix for Bug 692507
> The image interpolation code did not make use of the proper unpacking
> routine when the data was 16bit and we were using the faster ICC
> based renderer, which avoided the conversion to the frac type.
> gs/base/gxino16b.c
> gs/base/gxiscale.c

2011-10-03 17:15:53 +0100
Robin Watts <Robin.Watts@artifex.com>
e776cc41b9da0a535adde126464d6af906b082ae

> Fix for Bug 692553; SEGV in fast thresholding halftoning code.
> Stupid C got the % operation wrong.
> In this instance, it gives an unexpected negative value causing out of
> bounds offsets. Simple fix is to offset by the period if it's negative.
> gs/base/gxht_thresh.c

2011-09-29 19:07:44 +0100
Robin Watts <Robin.Watts@artifex.com>
3420c5c029771eee268d049fe9b6869221b18d48

> Add num_planes to gx_strip_bitmap for planar devices.
> Here we alter all existing uses (that I can find) to set num_planes
> as appropriate.
> We update the clist code to encode/decode the new num_planes field. In
> order to fit the extra bit required to signal that this is present into
> the encoding byte we optimise the representation of depth down to 4 bits
> from 5.
> We remove the lop_t_is_planar hack as we now have a cleaner scheme for
> signalling it.
> This should hopefully remove the last differences between pamcmyk4 and
> plank.
> gs/base/gdevdbit.c
> gs/base/gdevdrop.c
> gs/base/gdevmpla.c
> gs/base/gdevmr2n.c
> gs/base/gsptype1.c
> gs/base/gsropt.h
> gs/base/gxbitmap.h
> gs/base/gxcht.c
> gs/base/gxclbits.c
> gs/base/gxcldev.h
> gs/base/gxclimag.c
> gs/base/gxclist.h
> gs/base/gxclrast.c
> gs/base/gxht.c
> gs/base/gximage3.c
> gs/base/gxp1fill.c
> gs/base/gxpcmap.c
> gs/doc/Drivers.htm

2011-10-02 22:26:58 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
8e6d888502506e061241f2cdeb7c3f76d4dfb04f

> Bug 692560: read objects with invalid obj# as nulls.
> According to PDF spec, objects with invalid object numbers should
> be considered null objects. GS finally implements this.
> gs/Resource/Init/pdf_base.ps
> gs/Resource/Init/pdf_main.ps

2011-09-30 12:46:53 -0700
Michael Vrhel <michael.vrhel@artifex.com>
3380bef5e77ddfaa8aab496a4da13fd297480bd1

> Fix for bug 692558
> Issue was that the pdf14 device profile was getting set from an ICC profile that
> was contained in the source profile for the transparency group. This needs to
> be detected when we are getting the device parameters.
> gs/base/gsdparam.c

2011-09-30 17:52:57 +0100
Chris Liddell <chris.liddell@artifex.com>
b39b7cbfcf8719b9f41153ccf6172fbf8f800642

> Some tweaks to allow "make so" to build in Mac OSX.
> The change still results in a ".so" object file, rather than usual Mac
> ".dylib" file, but other than the name, they are internally identical.
> No cluster differences.
> gs/base/Makefile.in
> gs/base/configure.ac
> gs/base/unix-dll.mak

2011-09-30 16:00:51 +0100
Chris Liddell <chris.liddell@artifex.com>
b295fcef1b5a32e299f50f99248ae05099bd757d

> Remove the option to build with an external LCMS
> Given the extent which our bundled LittleCMS has diverged from the
> official release, remove the capability to build with another, at least
> until there is an lcms release incorprating the fixes we require.
> No cluster differences
> gs/base/Makefile.in
> gs/base/configure.ac

2011-09-30 10:30:05 +0100
Chris Liddell <chris.liddell@artifex.com>
54ee17d027c6be432a742ca5d313a56ac317361f

> Bug 692561: fix handling of tr 3 in setshowstate
> In setshowstate we have to work around buggy PDFs in a manner which
> means we "show" the text in question, but then rely on a charpath
> operation to update the current point accurately. The problem was
> that the currentpoint had already been updated by the show operation.
> This change ensures we return the currentpoint to the correct position
> before doing to charpath to get the accurate text advance.
> No cluster differences.
> gs/Resource/Init/pdf_ops.ps

2011-09-29 15:45:04 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
63f2476edccc4860312737b61e86c929c340cb72

> Bug 692557: Tolerate null XObjects
> Check for null XObjects during PDF resource enumeration and
> ignore them. Since null objects can appear anywhere in PDF file,
> the sample file was OK, but GS didn't handle this case before.
> gs/Resource/Init/pdf_main.ps

2011-09-28 20:44:53 -0700
Michael Vrhel <michael.vrhel@artifex.com>
03b20ec31afa843d5a4bac878568f60abcdea5fc

> Fix for Bug 692494 and Bug 692433. Overprint issues.
> The fix for bug 692494 involved making sure that we use the original floating point values in
> determining if we have a nonzero component so that overprint mode occurs properly
> for very small values. Thanks to Ken and Ray for the initial analysis on this bug.
> A study of 692433 revealed that AR does not do overprint simulation when the source
> ICC profile does not match the destination profile. To test this, I created a
> test file that had 2 overlapping fills with CMYK values that were specified by
> SWOP CMYK values. If the simulation profile in AR matched this profile, then overprinting
> was properly displayed by AR. If not, then overprinting was not displayed. This
> makes sense as the overprinted inks really should be in the color space for the
> target device. Hence, if the source and destination profiles do not match we will
> not be showing overprint This test file is called overprint_icc.pdf and will be added to
> our test files.
> gs/base/gscspace.c

2011-09-29 16:15:01 +0100
Robin Watts <Robin.Watts@artifex.com>
86bd5228ef5f88b747dd228a4b90938d3c9defa5

> Speed optimisations to bmpcmp
> pam/pnm/pgm reading was using repeated fgetc calls. Change it here to
> use fread and then shuffle the buffer around.
> gs/toolbin/bmpcmp.c

2011-09-29 16:03:06 +0100
Robin Watts <Robin.Watts@artifex.com>
9b60dc77805746ca685e272abe9b3f056320d612

> Partial fix for planar device pattern rop problems.
> plank vs pamcmyk4 tests have revealed various files still rendering wrongly
> in plank format. These are to do with a halftone being rendered as a pattern
> and then used as part of a rop.
> Specifically, if the 'rop source' device is used, then it is fed a pattern
> tile that is in planar format. When this calls strip_copy_rop, the pattern
> tiles data is used as the 'T' field; strip_copy_rop assumes that both T
> and S are always in chunky format, and so garbage is read for the T plane.
> The fix, implemented here, is to spot that the pattern tile is planar, and
> to set a new bit (lop_t_is_planar) in the lop to indicate this fact. The
> planar device can then catch this bit and can handle it.
> Currently, this is implemented by doing a planar_to_chunky operation into
> a temporary buffer, performing the strip_copy_rop, and then freeing the
> buffer. Later we may well implement cores that can cope with the common
> cases with T being still in planar form.
> This commit only fixes unbanded operation; currently when the clist writer
> puts the tile into the clist, it has no way of indicating that the tile
> is in planar format, hence only writes 1/4 of the data. I need to talk to
> Ray and Michael about this. This is broken already, so this commit shouldn't
> make anything worse.
> I have updated the docs (out of date since 1998, at least) in related areas,
> and fixed some broken english.
> gs/base/gdevdrop.c
> gs/base/gdevmpla.c
> gs/base/gsropt.h
> gs/base/gxcht.c
> gs/base/gxp1fill.c
> gs/doc/Drivers.htm

2011-09-29 14:35:12 +0100
Robin Watts <Robin.Watts@artifex.com>
d4741818da0a3f9a5a7ab98c328795dde6f850cb

> Add Memento targets to unix/autoconf makefiles.
> Add new targets to unix makefiles (pcl-memento, xps-memento etc) that
> build executables into memobj. Parallels the work done with the windows
> builds.
> Makefile
> common/ugcc_top.mak
> gs/base/Makefile.in
> gs/base/macosx.mak
> gs/base/ugcclib.mak
> gs/base/unix-end.mak
> gs/base/unix-gcc.mak
> gs/base/unixansi.mak

2011-08-18 17:01:43 -0700
Ray Johnston <ray.johnston@artifex.com>
fe8d7b6aebfed3c724a860e31ff170764d5429dc

> Fix bug 692372: Add finalize for imager_state to ref_count decrement icc structs.
> The graphics atates were being freed by the 'alloc_restore_all' done during gs_lib_finit
> but the icc_link_cache was not getting its ref_count decremented, so it never freed the
> semaphore which caused handles to be lost by windows. The rc_gsicc_profile_cache_free
> function is also fixed to save the 'next' pointer to avoid dereferencing freed memory.
> Note that we _should_ be able to call gs_imager_state_release to decrement the counts
> of ALL of the elements, but the ref counting of the other elements is _so_ badly
> maintained that some elements (dev_ht and halftone) are prematurely freed by this.
> This change is enough to fix the bug and pass cluster regression.
> gs/base/gsicc_profilecache.c
> gs/base/gsistate.c
> gs/base/gsstate.c
> gs/base/gxistate.h
> gs/base/gzstate.h

2011-09-28 09:33:31 -0600
Henry Stiles <henry.stiles@artifex.com>
02bdba18be7f2b78ca03d3f4126cef830eab28eb

> Fixes 692544, an "off by one" error in the parser caused a pcl data
> scanning command at the end of a stream to be skipped. No expected
> differences.
> pcl/pcparse.c

2011-09-28 09:32:07 -0600
Henry Stiles <henry.stiles@artifex.com>
f21756f217abc06b41d09946cffad083c8992ac5

> Change to new indenting style, no expected differences.
> pcl/pcparse.c

2011-09-28 11:29:27 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
326f67e01b02936dfdf5d51b918e3d1878765282

> Bug 692551. Remove .min for compatibility with other interpreters.
> gs/lib/prfont.ps

2011-09-27 11:36:28 -0700
Michael Vrhel <michael.vrhel@artifex.com>
48e7b9e6aaf93eded227a089b94f90db209476ff

> Fix for Bug 692378
> The function which decodes runs of compressed color values was not reseting
> the solid color value as we looped through the line. So, if it was altered
> during one compressed color decode in the line, subsequent values were affected.
> gs/base/gdevdevn.c

2011-09-27 09:15:59 +0100
Chris Liddell <chris.liddell@artifex.com>
ddf450125929a9c261b3f7f99ec29c8da69b0207

> Bug 692529: reduce potential rounding errors in FAPI/FT
> Tweak the heuristic used for avoiding over/underflow problems when converting
> scaling to pass into Freetype. This change distributes the over/underflow
> protection more evenly between Freetype's resolution, size and matrix
> parameters. This prevents the resolution parameter from getting excessively
> small, and grid fitting producing unacceptable rounding errors.
> This causes differences in about 20 cluster jobs, they are all small changes
> in the position of glyphs - neither regressions nor progressions.
> gs/psi/fapi_ft.c

2011-09-26 13:19:34 -0700
Michael Vrhel <michael.vrhel@artifex.com>
f97a9171cfb7f1081040a7bd56c4238105e6865a

> Fix for bug 692537
> Need to make sure that the color mapping information (what colorants are supported and what
> their index is) is updated in gx_set_overprint_DeviceN before setting up the overprint information.
> gs/base/gscdevn.c
> gs/base/gsovrc.c

2011-09-26 12:03:36 +0100
Robin Watts <Robin.Watts@artifex.com>
692f2f74da514b5ba42179ea357263aa77caacd7

> Fix cmyk 1bpc planar rop SEGVs.
> The new cmyk 1bpc planar rop code does not cope with transparent rops.
> Reflect this in the if's surrounding the code that calls it.
> gs/base/gdevmpla.c

2011-09-24 08:42:38 -0700
Michael Vrhel <michael.vrhel@artifex.com>
3ee407fafffce3d680039f0f094081e46d9bc6d3

> Fix so that fast thresholding code works with simple orders.
> Simple orders are those that are represented by shifts of a smaller template.
> gs/base/gsht.c
> gs/base/gxht_thresh.c

2011-09-23 23:23:02 -0700
Michael Vrhel <michael.vrhel@artifex.com>
545cd811c4a2c33c472f302088a10a807e98d9be

> Fix for Bug 692339
> Threshold creation code in the tiffsep1 code was not handled correctly when the dorder was a simple form
> that included a repeated shift.
> gs/base/gdevtsep.c

2011-09-23 20:26:09 +0100
Robin Watts <Robin.Watts@artifex.com>
24ff7262bc333194c27c463b88fd54a1217faac7

> More optimisations to planar_cmyk4bit_strip_copy_rop
> Fix some bugs that would again only show up when width > 8.
> Add a new case (the hairiest) to the function. The others should all be
> easier from here on in if we decide to do them.
> CLUSTER_UNTESTED as plank is not enabled on pcl yet.
> gs/base/gdevmpla.c

2011-09-23 17:00:02 +0100
Chris Liddell <chris.liddell@artifex.com>
5688545987a05f38359298e7649bdebe8e87dcaf

> Bug 692532: fix setting the ICCProfilesDir userparam
> Change from .setuserparams to .setuserparams2 when setting the
> ICCProfilesDir entry so that the Postscript world dictionary gets updated
> along with the internal values stored in the current context.
> No cluster differences.
> gs/Resource/Init/gs_lev2.ps

2011-09-23 16:35:10 +0100
Robin Watts <Robin.Watts@artifex.com>
f7a01d98266270908f041b1d2b78b2777cc577a8

> Fix to planar_cmyk4bit_strip_copy_rop.
> The previous version would have gone wrong for any use of the new case
> where width > 8. I missed this as (presumably) my test case doesn't
> exercise the new code, and the cluster is not testing plank on pcl files.
> gs/base/gdevmpla.c

2011-09-23 15:16:38 +0100
Robin Watts <Robin.Watts@artifex.com>
2946424a03da33d2f00d27626c4692f8942f7f04

> More planar_cmyk4bit_strip_copy_rop optimisations.
> Firstly, fix a bug that was present in the previous version; cproc,
> mproc and yproc could not be set when they were used. Also, we
> incorrectly failed to check for scolors being non NULL before calling
> this routine.
> We fix this latter problem, by implementing the scolors == NULL case.
> This drastically speeds up the time for pcl/pcl5cats/Subset/PL2KCSC2.BIN
> (plank 300dpi, banded).
> gs/base/gdevmpla.c

2011-09-23 12:09:03 +0100
Ken Sharp <ken.sharp@artifex.com>
1f426395a41ef2fc8a68b24b9970194127d0def2

> Fix some minor compiler warnings introduced in commit
> 237f153545faec22782b64016b5f14dabb4cf6ed
> gs/base/gdevpsf1.c

2011-09-23 11:23:35 +0100
Chris Liddell <chris.liddell@artifex.com>
7e048c5e4c4ea35d22801196af1e6bc8886e87d5

> Bug 692532 (part): catch error return, prevent crash.
> This fixes the crash by catching an error, but doesn't fix the underlying
> problem of not finding the ICC profile file.
> No cluster differences.
> gs/base/gstrans.c

2011-09-23 11:03:24 +0100
Ken Sharp <ken.sharp@artifex.com>
237f153545faec22782b64016b5f14dabb4cf6ed

> Bug #692488 add limited support for MM fonts to ps2write
> ps2write currently emits MM fonts with the WeightVector but no other parts
> of the font, and so it is not a valid MM font. However it also emits MM
> OtherSubr calls in the CharString, which is not legal and causes errors.
> This code parses (but does not interpret) the Subrs and CharStrings and
> removes the blending values, leaving only the base values.
> This is not a comprehensive solution, the parser can be defeated by a
> sufficiently convoluted CharString/Subr combination and in addition the
> code should really blend the vlaues instead of discarding them. This would
> require writing a new version of 'psf_convert_type1_to_type2' which emits
> type 1 CharStrings instead of type 2. The bug has been left open and
> converted to an enhancement to reflect this ambition.
> This code shows 2 progressions in the regression test suite:
> test-setweightvector.ps
> fts_20_2005.pdf
> gs/base/gdevpsf1.c

2011-09-23 00:50:34 +0100
Robin Watts <Robin.Watts@artifex.com>
36a46a8bfdf60fb682d5acf200b9da7d5d57ed51

> Optimise mem_planar_copy_color_4to1 (table based version).
> Performance testing plank shows tests_private/comparefiles/knight.pdf
> taking a much longer time with plank than pamcmyk4. A large amount of
> time seems to be spend in mem_planar_copy_color_4to1.
> The implementation seems to fare badly on x86 due to branches skipping
> ahead that cannot be predicted. A table based implementation seems to
> halve the runtime of the problem file (300dpi, no banding).
> gs/base/gdevmpla.c

2011-09-22 18:14:06 +0100
Robin Watts <Robin.Watts@artifex.com>
65092efad877169870f9d907eda46a9b8298c1aa

> Add special case code for rops in cmyk 1bpc planar space.
> We add special case code to speed planar rops. Should give identical
> results to the original method of doing it (planar_to_chunky, cmyk
> to rgb, apply rop, cmyk back to rgb and split out to planes), but
> rolls all that into a single traversal of the data, and doesn't
> call the map functions for every single pixel.
> Speeds 600 dpi unbanded planks processing of lj5200_pcl6_mono_PWTW51DC.prn
> from 58 seconds to 22.
> gs/base/gdevmpla.c

2011-09-21 17:57:55 +0100
Robin Watts <Robin.Watts@artifex.com>
53900176669849e91b2563ea57568db41e55d2d9

> Add special case for faster planar rops in greyscale and rgb modes.
> If we're doing a planar rop, and (S is either unused, or constant) and
> (T is either unused, or constant), and (we're in rgb or greyscale), then
> we can treat each component separately. This avoids pulling the planes
> together, converting to rgb, doing the rop, converting back to cmyk and
> splitting back out again.
> I had hoped to use a variant of this code to do cmyk rops too, but that
> turned out to be impossible; even if we 'rewrite' the rop on entry to
> change it from an rgb one to a cmy one, the non-orthogonal nature of the
> K plane bites us.
> CLUSTER_UNTESTED as not currently enabled on the cluster.
> gs/base/gdevmpla.c

2011-09-21 17:48:51 +0100
Robin Watts <Robin.Watts@artifex.com>
33e280b132b5527e4a9cb5683d10f9395f45bb92

> Add map_color_rgb functions to cmyk plan devices (required for rops).
> Contrary to the documentation, it is important to provide a map_color_rgb
> so that rops work.
> CLUSTER_UNTESTED as only the plank device is enabled in testing, and that
> one is unchanged.
> gs/base/gdevplan.c

2011-09-21 17:39:45 +0100
Robin Watts <Robin.Watts@artifex.com>
1e2b027a201b1aeeebfff807a45f1e1cb021dc0e

> Add 24bit case to pack_planar_from_standard (also fix <=8 bit case)
> pack_planar_to_standard is missing the 24 bit case; trivially add it in.
> Also, the <= 8 bit case looks horribly broken to me; rewrite it here,
> keeping old code around in case I am (again) proven to be a loon.
> CLUSTER_UNTESTED as this code isn't executed in any tests currently.
> gs/base/gdevdrop.c

2011-09-21 16:18:02 +0100
Chris Liddell <chris.liddell@artifex.com>
16aebf73c4eb716b5393bf0912b7b740a3867bf8

> Bug 692300: Allow cidfmap to have paths to CIDFont files
> Revise the cidfmap handling so that it can be used to point Ghostscript
> at Postscript CIDFont files that are outside the normal resource search
> path (i.e. not in "Resource/CIDFont").
> CLUSTER_UNTESTED
> gs/Resource/Init/gs_cidfm.ps
> gs/doc/Use.htm

2011-09-20 16:14:27 -0700
Michael Vrhel <michael.vrhel@artifex.com>
36925c8f0864e8ecd54625011696d4bcdbc26fcc

> Fix for bug 692517
> The icc_table member variable needs to be allocated in stable memory. This way
> it is not freed during a restore. This was occurring when we had a clist
> device member variable in a pattern followed by a restore.
> gs/base/gxclist.c
> gs/base/gxclist.h
> gs/base/gxclread.c

2011-09-20 09:58:48 +0100
Ken Sharp <ken.sharp@artifex.com>
40bdfff14aa2d3190526f44d4ef81d3c8c65be3f

> Bug #692520 (partial, pdfwrite portion only) fix return testing
> The cos_c_string_value function returns a pointer (to a parameter passed to it!)
> which is cast to an int and tested for negativity. This is terrible practice.
> On 64- bit machines the pointer doesn't fit into an int and on 32-bit machines it
> will erroneously detect an error if a valid pointer exceeeds 2GB.
> The only reason for the test is to allow the funciton call to be included
> in the body of an 'if' test, which is a hideous way of constructing the
> code.
> This commit reformats the code, and does away with the irrelevant return code
> test.
> No differences expected, this path is not tested by the cluster.
> gs/base/gdevpdfc.c

2011-09-19 17:20:51 -0700
Michael Vrhel <michael.vrhel@artifex.com>
6e2eda3cca4f8e13a9139c77aad5da524fa62d76

> Avoid mixed double float operations.
> On my machine moving over to float to avoid the mixed double/float operation slowed things
> down even more. We may want to revisit this later. Diffs were minor and had about
> 10 percent speed up on interpolation with this change.
> gs/base/siscale.c

2011-09-19 15:39:42 +0100
Chris Liddell <chris.liddell@artifex.com>
a44f19c56f98f3d700f617701d581e6932c964a9

> FAPI/UFST revisions.
> 1) Modify FAPI/UFST to use a chunk allocator for its memory (this reflects a
> similar change in FAPI/FT).
> 2) "Side-port" changes from the integration project for customer 532.
> 3) Address a couple of stability/output error problems that came up testing
> the above changes.
> CLUSTER_UNTESTED
> gs/Resource/Init/gs_fapi.ps
> gs/psi/fapiufst.c
> gs/psi/zfapi.c

2011-09-19 13:52:31 +0100
Ken Sharp <ken.sharp@artifex.com>
13028e7b90dba007183c4b64a5d6b1363e30c993

> Bug #692515, array index out of bounds (static analysis)
> The routine pdf_SepCMYK_ConvertToRGB accessed element 5 of an array
> passed as a parameter, when it should have accessed element 4 in order to
> convert a CMYK value into an RGB value.
> The code path is only exercised when creating PDF/A or PDF/X, the
> ProcessColorModel is DeviceRGB, and the input contains a /Separation or
> /DeviceN colour space with a DeviceCMYK /Alterenate space.
> No differences expected.
> gs/base/gdevpdfc.c

2011-09-16 15:15:45 +0100
Robin Watts <Robin.Watts@artifex.com>
64a7f79fbc184fddc10f635cfeabf8c44db46d90

> Fix MSVC gs Profile builds.
> In my recent rework of the makefiles, I broke gs profile builds (in that
> they were built as release builds). Trivial fix.
> gs/psi/msvc.mak

2011-09-15 20:36:31 +0100
Robin Watts <Robin.Watts@artifex.com>
50d947b5f4801d1042166acbd8b5aed982f57697

> Allow planar device to make use of special getbits handling for 1bit cmyk.
> We have a special function gx_get_bits_copy_cmyk_1bit, used to quickly
> map cmyk (1bpc) to rgb. Our use of this is dependant on the
> gxdso_is_std_cmyk_1bit call. Unfortunately this was broken for planar
> devices, so plank was never getting the speed benefits of this routine.
> Fixed here.
> gs/base/gdevmpla.c

2011-09-14 12:40:48 -0700
Michael Vrhel <michael.vrhel@artifex.com>
6aa157b438ac69f9732b9f7b29e8570cceb50e8e

> Fix for bug 692323. Performs color management before spatial interpolation with enlargements.
> This avoids expensive color management operations when we are doing spatial interpolation.
> Also a code reduction with this commit.
> gs/base/gxiscale.c
> gs/base/sidscale.c
> gs/base/siinterp.c
> gs/base/siscale.c
> gs/base/sisparam.h
> gs/psi/zfimscale.c

2011-09-14 13:29:09 +0100
Chris Liddell <chris.liddell@artifex.com>
d4c7212427ea85c6d8d9c9a46a178af54c9b96d3

> Bug 691991: allow extra compile/link flags.
> The XCFLAGS and XLDFLAGS should be available to be specified as parameters to
> "make", but they were being used by the autoconf tools. This change moves the
> autconf set flags into their own variables, leaving XCFLAGS and XLDFLAGS for
> use at the make command line. Similarly, it adds an XTRALIBS variable which
> can also be set from the make command line.
> This is a slight modification of a patch originally from William Bader.
> No cluster differences.
> gs/base/Makefile.in

2011-09-13 14:03:12 +0100
Chris Liddell <chris.liddell@artifex.com>
83e1c7b77e8a23ed0683b3677a7cccba94ad5fe8

> Bug 692491: change FAPI/Freetype to use chunk allocator
> Previously FAPI/FT was using the heap allocator, which caused performance
> problems due to its linear search of allocated blocks to validate before
> freeing a block. The linear searching was fixed previously, but on some
> platforms the C lib's malloc/free are bottlenecks, so using a chunk
> allocator instance makes sense for allocate/release pattern we see from
> Freetype.
> No cluster differences.
> gs/psi/fapi_ft.c

2011-09-10 10:23:50 -0500
Robin Watts <robin.watts@artifex.com>
e5d8d4d6514600f49a6aae2811e3b6fd33c2ef54

> Speed up heap freeing (gs_heap_free_object) by avoiding search.
> Inspired by Bug #687475. Remove the search through every allocated block
> when freeing a heap block. Drastically increases the speed. Will hopefully
> help other things too.
> If people really want to test that blocks are valid on free, build with
> Memento, which captures this in a much more useful way.
> gs/base/gsmalloc.c

2011-09-10 10:09:23 -0500
Robin Watts <robin.watts@artifex.com>
1e3da08d9eb07a9d9650f5deeccf376da6db5722

> Update xcode project to allow profiling.
> xcode/GhostPDL/GhostPDL.xcodeproj/xcshareddata/xcschemes/ghostscript.xcscheme
> xcode/GhostPDL/GhostPDL.xcodeproj/xcshareddata/xcschemes/language_switch.xcscheme
> xcode/GhostPDL/GhostPDL.xcodeproj/xcshareddata/xcschemes/pcl.xcscheme
> xcode/GhostPDL/GhostPDL.xcodeproj/xcshareddata/xcschemes/svg.xcscheme
> xcode/GhostPDL/GhostPDL.xcodeproj/xcshareddata/xcschemes/xps.xcscheme

2011-09-09 13:40:30 -0700
Michael Vrhel <michael.vrhel@artifex.com>
3329928934123e2d3033309aa79c6ca18d975528

> Update lcms2.1 to lcms2.2 plus fix some bit rot
> Checked to see if this fixed Bug 692121 and unfortunately it did not. Working to create this with
> tools contained in lcms2 so that I can kick the issue up to Marti.
> gs/base/gsicc_lcms2.c
> gs/base/lib.mak
> gs/lcms2/AUTHORS
> gs/lcms2/COPYING
> gs/lcms2/ChangeLog
> gs/lcms2/Makefile.in
> gs/lcms2/Projects/BorlandC_5.5/lcms2.rc
> gs/lcms2/Projects/VC2008/lcms2.rc
> gs/lcms2/Projects/VC2010/lcms2.rc
> gs/lcms2/Projects/VC2010/resource.h
> gs/lcms2/aclocal.m4
> gs/lcms2/config.guess
> gs/lcms2/config.sub
> gs/lcms2/configure
> gs/lcms2/configure.ac
> gs/lcms2/include/Makefile.in
> gs/lcms2/include/lcms2.h
> gs/lcms2/install-sh
> gs/lcms2/ltmain.sh
> gs/lcms2/src/Makefile.in
> gs/lcms2/src/cmscnvrt.c
> gs/lcms2/src/cmserr.c
> gs/lcms2/src/cmsgamma.c
> gs/lcms2/src/cmsgmt.c
> gs/lcms2/src/cmsio0.c
> gs/lcms2/src/cmsio1.c
> gs/lcms2/src/cmslut.c
> gs/lcms2/src/cmsnamed.c
> gs/lcms2/src/cmspack.c
> gs/lcms2/src/cmstypes.c
> gs/lcms2/src/cmsxform.c
> gs/lcms2/src/lcms2_internal.h
> gs/lcms2/testbed/Makefile.am
> gs/lcms2/testbed/Makefile.in
> gs/lcms2/testbed/testcms2.c
> gs/lcms2/utils/delphi/lcms2dll.pas
> gs/lcms2/utils/jpgicc/Makefile.in
> gs/lcms2/utils/linkicc/Makefile.in
> gs/lcms2/utils/psicc/Makefile.in
> gs/lcms2/utils/tificc/Makefile.in
> gs/lcms2/utils/transicc/Makefile.in
> gs/lcms2/utils/transicc/transicc.c

2011-09-09 16:27:04 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
5f82fe2ef9d4d21950f9cf76c82911b9f977e2b1

> Bug 692492: Accept empty xref sections.
> Change xref parser to accept xref sections that have no entries.
> gs/Resource/Init/pdf_main.ps

2011-09-08 21:13:39 -0700
Michael Vrhel <michael.vrhel@artifex.com>
7d59aae1041ac22608f7f470f3f3644c1f7523bd

> Fix for patterns with plank device, transparency, and clist.
> It turns out that when we right the tile raster for the clist we don't
> really know what the "true" target of the pattern is only the final
> target device. In this particular situation, the target for the pattern
> is a pdf14 device, the tile has no transparency, and the final target
> is a planar device. When ended up assuming the tile was planar which
> it was not and ended up with a seg fault
> gs/base/gsptype1.c
> gs/base/gxcolor2.h
> gs/base/gxpcmap.c
> gs/base/gxpcolor.h

2011-09-08 13:59:03 +0100
Robin Watts <robin.watts@artifex.com>
968040d1ef877607fb6b6bed67e7c2d54c0b4dd1

> Add massively hacky and horrible clang_wrapper to xcode build.
> This is REALLY nasty, but seems to work; at least I get sensible
> results thrown back into Xcode when I build with analyze.
> xcode/GhostPDL/GhostPDL.xcodeproj/project.xcworkspace/xcuserdata/robin.xcuserdatad/UserInterfaceState.xcuserstate
> xcode/GhostPDL/GhostPDL.xcodeproj/project.xcworkspace/xcuserdata/robin.xcuserdatad/WorkspaceSettings.xcsettings
> xcode/Makefile
> xcode/clang_wrapper.c
> xcode/resolve.sh

2011-09-07 23:37:29 +0100
Robin Watts <Robin.Watts@artifex.com>
618f03fce59282255e7d251875dd1d9ff5b35bf6

> Remove unused variable introduced in last commit.
> gs/base/gdevplan.c

2011-09-07 20:27:26 +0100
Robin Watts <Robin.Watts@artifex.com>
6a505dc016f8d34444f7b431a220320e005df201

> Put map_color_rgb function back into planar devices to fix pcl
> It appears that the rop code requires map_color_rgb to work properly.
> Reinstate the old functions to get us up and running.
> gs/base/gdevplan.c
> gs/base/gdevplib.c

2011-09-07 00:28:21 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
b3ee2cd07fc7bdfbc3014316f0d4f7da54c900ee

> Bug 692352: excessive memory use by shading
> Reduce memory usege in smooth shading by running the shading code
> in save-restore contest. Although resolved shading is no longer
> cached by PDF interpreter, reduced memory usage greatly speeds-up
> processing of the files with many shadings.
> gs/Resource/Init/pdf_draw.ps

2011-09-06 20:42:36 +0100
Robin Watts <robin.watts@artifex.com>
5426550f44025e7ec5c802b27d379f7ffee5ed01

> New simple xcode project for GhostPDL/Ghostscript.
> Still very experimental, but seems to build. Debugging seems to work.
> Analysis doesn't work (usefully) yet due to clang not reporting full
> pathnames. This can be solved by a wrapper. TODO: Write it.
> xcode/GhostPDL.xcodeproj/default.pbxuser
> xcode/GhostPDL.xcodeproj/project.pbxproj
> xcode/GhostPDL/GhostPDL.xcodeproj/project.pbxproj
> xcode/GhostPDL/GhostPDL.xcodeproj/project.xcworkspace/contents.xcworkspacedata
> xcode/GhostPDL/GhostPDL.xcodeproj/project.xcworkspace/xcuserdata/robin.xcuserdatad/UserInterfaceState.xcuserstate
> xcode/GhostPDL/GhostPDL.xcodeproj/project.xcworkspace/xcuserdata/robin.xcuserdatad/WorkspaceSettings.xcsettings
> xcode/GhostPDL/GhostPDL.xcodeproj/xcshareddata/xcschemes/GhostPDL.xcscheme
> xcode/GhostPDL/GhostPDL.xcodeproj/xcshareddata/xcschemes/ghostscript.xcscheme
> xcode/GhostPDL/GhostPDL.xcodeproj/xcshareddata/xcschemes/language_switch.xcscheme
> xcode/GhostPDL/GhostPDL.xcodeproj/xcshareddata/xcschemes/pcl.xcscheme
> xcode/GhostPDL/GhostPDL.xcodeproj/xcshareddata/xcschemes/svg.xcscheme
> xcode/GhostPDL/GhostPDL.xcodeproj/xcshareddata/xcschemes/xps.xcscheme
> xcode/Makefile
> xcode/clang_wrapper.sh
> xcode/xcode.mak

2011-09-06 12:22:46 +0100
Robin Watts <Robin.Watts@artifex.com>
15e70ed9fc7b28a02b9eff6491fe5137cedc7798

> genarch tweak for cross-compiling; supply ready made arch files.
> Previously genarch would unconditionally generate an arch.h file for the
> current platform every time it was called. This fails for cross-compiling,
> forcing the makefile to be edited every time. In this commit we add a
> tweak that solves this problem.
> Now, genarch can optionally copy an existing arch.h file; if the make
> (or nmake) invocation has TARGET_ARCH_FILE=path/to/existing-arch.h added
> to it, then instead of generating an arch.h for the current (host)
> platform, it will instead copy the supplied one (assumed to be appropriate
> for the target platform).
> MSVC builds are updated here to automatically pick a TARGET_ARCH_FILE
> based upon the WIN64 define. This should allow us to build 32bit binaries
> on a 64bit box from the Visual Studio solution. We still cannot build
> 64bit binaries on a 32bit box using the unedited solution, as we have
> no way to detect the type of box we are on, and hence cannot select
> the appropriate AUX compiler to use.
> A new directory, 'gs/arch' is added, containing the 2 windows msvc arch.h
> files. More files can be added in future, ideally keeping to the
> <os>-<architecture>-<toolset>.h naming convention.
> gs/arch/windows-x64-msvc.h
> gs/arch/windows-x86-msvc.h
> gs/base/genarch.c
> gs/base/lib.mak
> gs/ghostscript.vcproj
> gs/psi/msvc.mak

2011-09-05 15:46:01 +0100
Robin Watts <Robin.Watts@artifex.com>
cb5b14133b516323694dcb99c7594337e84d5e3f

> Add Memento configuration to Visual Studio projects (and gs makefile)
> When swapping between memento and non-memento builds, a complete rebuild
> is required due to the pervasive nature of the memento defines. As such
> it makes sense to have it as a separate configuration in the project.
> Memento directories are named 'memobj', 'memobj64', 'membin' etc in
> keeping with 'debugobj', and 'profobj' etc.
> Also, take the opportunity to fix a couple of small things in the visual
> studio files. Firstly, the 64 bit profile build targets were incorrect
> (weren't setting paths etc).
> Secondly, we remove the use of nmake /A for the rebuild step, and instead
> rely on an explicit clean call, then a rebuild; this means we get
> consistent results for a rebuild compared to a clean then a build.
> As part of this work, we add logic to the (MSVC) makefiles to detect
> MEMENTO=1 and PROFILE=1. If set, these change the default DEBUG, TDEBUG
> and DEBUGSYM flags as appropriate, and change the default output
> directory names. This keeps the invocations from Visual Studio sane
> (as I found lots of mistakes in them as I looked through).
> Also fix some places where we were failing to set and pass on
> BINDIR/PSOBJDIR resulting in stray directories being created.
> CLUSTER_UNTESTED
> common/msvc_top.mak
> gs/ghostscript.vcproj
> gs/psi/msvc.mak
> language_switch/pspcl6_msvc.mak
> main/pcl6_msvc.mak
> psi/psi.mak
> svg/svg_msvc.mak
> win32/GhostPDL.sln
> win32/ReadMe.txt
> win32/language_switch.vcproj
> win32/pcl.vcproj
> win32/svg.vcproj
> win32/xps.vcproj
> xps/xps_msvc.mak

2011-09-05 10:20:14 +0100
Chris Liddell <chris.liddell@artifex.com>
2fab16e3cbf8b2a18aa82c6beee76e261e530b9f

> Bug 692365: Don't derive metrics for CIDFontType 2.
> If the metrics don't exist in a CID font, we attempt to derive "sane"
> metrics from the bounding box information. This is problematic since a
> font (even with WMode 1) missing vertical metrics should be treated as a
> horizontal (i.e. WMode 0).
> However, we *do* still want to derive vertical metrics, for a vertical
> writing font when we're using a Truetype font as a substitute for a
> "real" CIDFont.
> No cluster differences expected.
> gs/psi/zfapi.c

2011-09-04 10:26:49 +0100
Chris Liddell <chris.liddell@artifex.com>
6b7da277a6b7477b0d7114a6203d4112c0ad631f

> Fix glyph cleanup after error
> When cleaning up the freetype glyph after a glyph interpretation error
> use the glyph type field in the glyph structure to differentiate between
> freeing an outline or a bitmap glyph - rather than the glyph type we
> requested.
> No cluster differences expected.
> gs/psi/fapi_ft.c

2011-09-03 20:38:47 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
42582272f2b4dce1ccd5c600a2d6dc71794b4d3e

> Bug 692033: fix LZWEncode filter
> Increment code size before writing out EOD when the last code reaches
> the current limit code. Fix incorrect bytes or decoding errors at
> the end of some LZW-encoded streams.
> gs/base/slzwe.c

2011-09-03 09:19:49 +0100
Ken Sharp <ken.sharp@artifex.com>
6a2a8987a7c7d0f98dcf640f72e64256c1f84eb2

> Remove the insistence on DeviceGray or DeviceCMYK from pdfa_def.ps and remove
> the directive not to use DeviceRGB from the documentation.
> There is no requirement in the PDF/A-1 specification that prevents the use of
> DeviceRGB.
> gs/doc/Ps2pdf.htm
> gs/lib/PDFA_def.ps

2011-09-01 18:32:07 +0100
Robin Watts <Robin.Watts@artifex.com>
c1a22bfd63734c93fc8d9df65e58f83fbd6a3376

> Bug 692481: Fix for remainder of issue; oversize JPEG data causes hang.
> If the JPEG lib exits without decoding anything, and the buffer was full,
> attempt a compaction; if the compaction succeeds (bytes were saved), then
> continue, otherwise bale with an error to avoid us infinitely looping
> as we repeatedly try to decode the same data.
> The 'buffer is full' condition is the tricky one; we cannot know the
> exact size of the buffer, but we can know the minimum size we requested,
> so we use that as a close approximation.
> Also tweak the pxl handling of error conditions passed back from the
> jpeg decoder. Ensure that pxls use of streams set the templates.
> gs/base/sdctd.c
> pxl/pximage.c

2011-09-01 11:35:52 -0700
Michael Vrhel <michael.vrhel@artifex.com>
f1c4efc10e7aad61f08e979493773a29d973c43c

> Speed up of lcms 16bit tetrahedral interpolation code.
> This color table interpolation is used primarily where we have 16 bit image data or
> are doing spatial interpolation of image data. The change introduces
> some very minor changes across quite a few files that have 16 bit
> data or for which spatial interpolation is occurring. No changes occur at the white
> or black table points.
> The code differences involved moving the decision tree outside the loop and performing
> the normalization divide by an add and shift.
> This change can be readily moved to lcms2.
> gs/lcms/src/cmsintrp.c

2011-09-02 17:16:22 +0100
Ken Sharp <ken.sharp@artifex.com>
8b660e2678b3c6f4592269d14e3767aca3dd51e0

> Bug #692136 Change the FontBBox we use when a type 3 font has a NULL bbox.
> PCL creates type 3 fonts where the BBox is 0 0 0 0. This causes Acrobat problems,
> so we replace it with a 'default'. Previously this was 0 0 1000 1000, but this
> is incorrect for the type 3 fonts created from PCL, and makes it impossible
> to search/highlight text in the resulting PDF.
> We now check for a type 3 font with an all zero BBox, and instead use 0 0 1 -1
> which for PCL fonts works well. Regression tests show no differences with this
> change, and hopefully its no more incorrect than it was before.
> No differences expected.
> gs/base/gdevpdtt.c

2011-09-02 11:43:04 +0100
Chris Liddell <chris.liddell@artifex.com>
f2d80d64b5f863ba17f428b96967fe1c1ce0d870

> Bug 692484 - Fix build failure with gold linker...
> ....due to freetype underlinking.
> Credit to Timo Gurr ( timo.gurr@gmail.com ) for the patch
> CLUSTER_UNTESTED
> gs/base/Makefile.in

2011-09-02 10:09:42 +0100
Chris Liddell <chris.liddell@artifex.com>
ee226f558f5b73005ba0594cd3861ce431c08a1b

> Bug 692483 - Fix the unix install to include {Details,History}9.htm
> Credit to Timo Gurr ( timo.gurr@gmail.com ) for the patch.
> CLUSTER_UNTESTED
> gs/base/unixinst.mak

2011-09-01 09:54:53 -0700
Michael Vrhel <michael.vrhel@artifex.com>
2881a8db54afddc1708febaa1de51e6808a416f9

> Make sure planar pattern buffer size is correctly computed for clist writing.
> gs/base/gsptype1.c

2011-09-01 17:15:41 +0100
Robin Watts <Robin.Watts@artifex.com>
a00c728c4c3ffa2392765294bc21b90b6e38496f

> Bug 692481; partial fix - jpeg data with excess 0xFFs.
> Ghostscript passes buffers full of data to the jpeg library. The jpeg
> library decodes one (or more) scanlines of data from this data and
> returns it to ghostscript.
> In the event that the jpeg library can't decode an entire scanline from
> the buffer supplied, it 'suspends' itself (i.e. restores its internal
> state to the beginning of the last scanline, and returns having consumed
> no data).
> This means that if we ever have a scanline of jpeg data that is too large
> to fit in the stream buffer, we will go into an infinite loop.
> This commit is a partial fix for the issue; if we return from the jpeg
> lib having consumed no data and having produced no output, we attempt to
> compact the data in the jpeg stream. We do this by compacting strings of
> 0xFF bytes to a single 0xFF byte. (Strings of 0xFF bytes are forbidden by
> the spec, but are treated by the library as a single one).
> This is sufficient to solve the problem with the supplied corrupted file,
> but still leaves us vulnerable to files that have more than 0x800 bytes
> in any given single scanline.
> A proper fix would require us to spot that the buffer was 'full' and that
> the compaction process saved no bytes. Spotting that the compaction
> process saved no bytes is easy. Spotting that the buffer is 'full' is not
> currently possible as stream->cbsize is not available at the point
> where the test needs to be done.
> gs/base/sdctd.c

2011-09-01 08:29:03 +0100
Ken Sharp <ken.sharp@artifex.com>
ad0cf1990ae540252f68c50fa4627ed3b1752b89

> Bug #692457 If a PCL pattern turns out to be a flat fill, still update the saved colour.
> If a PCL pattern turned out to be a simple colour (black or white) we optimise
> the output and don't emit a pattern. However, we do still need to update the
> saved colour in our private state, because we will still be changing the colour. If
> we don't do that then our saved state does not reflect the actual content of
> the PDF file, and we can emit incorrect colours.
> No differences expected.
> gs/base/gdevpdfg.c

2011-08-31 18:32:40 +0100
Robin Watts <Robin.Watts@artifex.com>
a2d547dd3378afdb63681e9262e3bedd2abb3e53

> Memento fixes; Memento code in gsalloc was broken.
> The memento code in gsalloc.c intended to allow for memory squeezing
> was inadvertantly relying on C extensions. Fixed here.
> CLUSTER_UNTESTED.
> gs/base/gsalloc.c

2011-08-31 18:06:17 +0100
Robin Watts <Robin.Watts@artifex.com>
af34c29e19ce012f71cb3713d4756ee43d6aa1d0

> Fix mem buffer raster calc in height=1 case.
> gs -r72 -sDEVICE=plank -o o.ppm tests_private/pdf/PDFIA1.7_SUBSET/CATX0198.pdf
> would SEGV when run, due to a planar pattern buffer of 1x1 being created;
> this would calculate a bad raster value, which was then copied into the
> pattern tile, and would cause problems.
> gs/base/gdevmpla.c

2011-08-30 18:24:57 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
fc3adb358eb5c0175fc5e24d7f275ffe2ac39fb9

> Bug 692409: check file name length
> Check the length of a file name argument and throw /limitcheck when
> it exceed the size of the internal buffer. Avoid undefined behaviour
> and possible security issues.
> gs/base/gdevprn.c

2011-08-30 19:22:35 +0100
Robin Watts <Robin.Watts@artifex.com>
2b898bdf0ba77853f4af9da4e39141189a1580a1

> Change planar devices to use encode/decode_color only.
> Simplify the code by removing deprecated color mapping functions. In
> particular this fixes a problem whereby encode_color for the plank
> device was returning a color index encoded as rgb, and hence confusing
> the overprint device.
> CLUSTER_UNTESTED as the plan* and plib* devices are not tested at the moment.
> gs/base/gdevplan.c
> gs/base/gdevplib.c

2011-08-30 19:21:44 +0100
Robin Watts <Robin.Watts@artifex.com>
605557a6e3741abe837445da32f378a7bb751e8f

> Minor whitespace adjustment.
> Correct indentation to avoid confusing simpletons like me.
> CLUSTER_UNTESTED.
> gs/base/gsbitops.c

2011-08-30 10:22:45 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
b08778372c45bdf77e60db7374d1d18b6b340b10

> Bug 692054: clear currentpoint after stroking empty path
> Make gs compatible with Adobe implementation and avoid creation
> of an uninitialized currentpoint value. Flag currentpoint as not
> defined after stroking an empty path.
> gs/base/gspaint.c

2011-08-29 20:24:17 +0100
Robin Watts <Robin.Watts@artifex.com>
619bfae87817cbb5633853f943dd3c7b101568c9

> Bug 692476: simple non-trans tiling to planar devices - workaround.
> Non transparent tiling of 'simple' coloured pattern tiles fails when
> going to planar devices. In this commit we simply disable the simple
> path in this case. Testing seems to indicate that everything will work
> OK now.
> Bug 692476 has been opened to remind us to optimise this when possible.
> gs/base/gxp1fill.c

2011-08-29 18:39:57 +0100
Robin Watts <Robin.Watts@artifex.com>
d0f9685b775092c820e3b4748f0fe09eb7880a55

> Disable mono threshold based halftoning for cmyk planar devices
> Currently we allow the mono threshold based halftoning routines to be
> called for CMYK planar devices. Disable this for now as it doesn't work.
> When we have the rest of the planar device testing out correctly we'll
> revisit this, debug it, and reenable it.
> gs/base/gximono.c

2011-08-29 13:50:25 +0100
Robin Watts <Robin.Watts@artifex.com>
385edc256d11fd9c0d9ae6af1e94ea145b15b393

> Tweak bmpcmp to put the threshold and window settings into the meta files.
> Useful for debugging. CLUSTER_UNTESTED.
> gs/toolbin/bmpcmp.c

2011-08-29 00:39:26 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
a8dbb2a904d52a9cce21db397b0918ce2d733214

> Bug 692447: Handle unfinished 'W' mode.
> When the content stream sets 'W' or 'W*' clip modes but doesn't
> complete them with a filling operator, Ghostscript leaves a
> dictionary on the dictionary stack that interferes with PDF graphic
> state processing. This patch does the following:
> - drops "W" in the sequence 'W Q"
> - ignores graphic state changes, e.g. in "W 0 G"
> - takes into account possible presence of non-graphic-state
> dictionaries during clean-ups.
> gs/Resource/Init/pdf_draw.ps
> gs/Resource/Init/pdf_main.ps
> gs/Resource/Init/pdf_ops.ps

2011-08-29 01:49:41 +0200
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
4d4b6f695ca058a36141e4f81313533c819def73

> Make plank and pamcmyk4 files easier to compare.
> Change pamcmyk4 files so that MAXVALUE is 255 (instead of 1) and add
> a comment to the plank file header.
> gs/base/gdevpbm.c
> gs/base/gdevplan.c

2011-08-26 10:05:17 -0700
Michael Vrhel <michael.vrhel@artifex.com>
7fee00e442130e0aa3118fec975882008e750ebd

> Allow planar devices to store patterns as bitmaps not clist only
> CLUSTER_UNTESTED
> gs/base/gxpcmap.c

2011-08-26 18:41:36 +0200
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
a9b386efabd5aab3913554641c66306e6bd79b58

> Add the various plan* devices to the default build.
> gs/base/configure.ac

2011-08-26 09:20:57 +0100
Chris Liddell <chris.liddell@artifex.com>
e665cacbe15d9cedb09334451cedd223a38a5ac3

> Bug 692435: fix PDF pre-rendering spot color search.
> Before we start rendering a page, we search the resources for the page
> (including its descendent objects), so that we can pass the information
> to the device prior to rendering. What we weren't doing was searching
> the parents of the page object (we were, however, doing so during the
> stream interpetation for rendering), thus in rare, but valid files, we
> could miss setting up the page device for spot colors.
> No cluster differences expected.
> gs/Resource/Init/pdf_main.ps

2011-08-23 10:31:03 -0700
Michael Vrhel <michael.vrhel@artifex.com>
aa715abee9f38daba6c9504495dca309e8e3ed64

> Fix so pattern debug code dumps planar bitmap.
> gs/base/gxpcmap.c

2011-08-23 16:26:24 -0700
Michael Vrhel <michael.vrhel@artifex.com>
cb54af824c8f0aa343167b1e8b99dd1d53e47955

> non-clist pattern rendering for planar devices.
> gs/base/gxp1fill.c
> gs/base/lib.mak

2011-08-25 19:02:57 +0100
Chris Liddell <chris.liddell@artifex.com>
c2f005a525f49bf43fb796908e0ab9c4b6ed58a4

> Another typo in News.htm and History9.htm
> CLUSTER_UNTESTED
> gs/doc/History9.htm
> gs/doc/News.htm

2011-08-25 18:28:37 +0100
Robin Watts <Robin.Watts@artifex.com>
409b62a948d75263131e09fd9a9e389d704d2b4c

> Add copy_plane operation to tile_clip device (gxclip2.c)
> Just a copy of copy_color, with an extra plane field.
> Not currently ever called, but required as work towards solving the
> planar pattern issues, we believe.
> gs/base/gxclip2.c

2011-08-25 17:35:36 +0100
Chris Liddell <chris.liddell@artifex.com>
cf495c68e94b061c89eca678bf863775ce1b8a53

> Bug 692461: Typos in News.htm and History9.htm
> CLUSTER_UNTESTED
> gs/doc/History9.htm
> gs/doc/News.htm

2011-08-05 20:49:57 +0100
Robin Watts <Robin.Watts@artifex.com>
8005a687146fd19ca5e6a80cfc2f20b9fd675e41

> Remove unused variable in shading code.
> km is never used, so remove it. No cluster differences expected.
> gs/base/gxshade6.c

2011-08-24 11:20:11 +0100
Ken Sharp <ken.sharp@artifex.com>
8cbd67605010b927192acb590b9a1fd8bf45a2a3

> Bug #692344 Make sure we do not dereference a NULL clip path when freeing
> When creating the 'privately allocated' parts of a gstate it is possible to
> fail to allocate a clip path. In this case we free the clip path, but if its
> notbeen allocated then it is NULL, and the free routine unconditionally
> de-references it.
> Added a NULL pointer to check to prevent this. I *believe* this fixes the bug
> but just changing the code made the allocation succeed when I tested it, so I
> am not absolutely certain. This patch does fix a genuine failure though.
> gs/base/gxcpath.c

2011-08-24 01:40:56 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
827b098f50d296dd0c9399ec82f1988c1de7b62d

> Bug 692445, tolerate short xref entries
> Fix a bug in the code that handles invalid xref entries and try
> to continue processing by repositioning PDF stream after the actial
> end of the entry.
> gs/Resource/Init/pdf_main.ps

2011-08-23 16:24:53 -0700
Michael Vrhel <michael.vrhel@artifex.com>
1c88a42f2409c30b3d2b955922efd8e00714c1cc

> Forcing of clist only rendering of patterns if target device is planar.
> This enables us to achieve proper rendering until we get the procedures straight
> for the non-clist case.
> gs/base/gxpcmap.c

2011-08-23 10:35:04 -0700
Michael Vrhel <michael.vrhel@artifex.com>
f215836c60865eaa2da4bed711215eae2b906c49

> Revert "Fix for Bug 687695." Fixes Bug 692454
> This reverts commit c7404eceab4d308c67130f43e9a4d4c0b58cd73c.
> That commit broke all the tiff devices.
> gs/base/gdevdgbr.c

2011-08-23 13:15:25 +0100
Ken Sharp <ken.sharp@artifex.com>
ec7e68e9054c8b1e91f588a358101c24d281555b

> Bug #692105. Increase the maximum input/output dimesnions of sampled functions.
> The maximum number of inputs and outputs allowed in a sampled function is a
> compile-time value. This particular PDF file had 20 colorants, and a sampled
> function with 20 inputs and 4 outputs to convert it into CMYK.
> This broke the maximu, even though GS had been compiled with GS_CLIENT_COLOR_MAX_XOMPONENTS
> increased to allow the PostScript version (which doesn't use a sampled function)
> to complete.
> This patch permits a new compile-time define GS_CLIENT_SAMPLED_FN_MAX_COMPONENTS
> which can be used to increase this value. If this is not declared then we now use
> the GS_CLIENT_COLOR_MAX_COMPONENTS as it is likely we will encounter sampled functiosn
> with that many components
> No differences expected
> gs/base/gsfunc0.c

2011-08-22 15:42:10 +0100
Ken Sharp <ken.sharp@artifex.com>
ebc42b7b7b27977bac17a9f5a9f0626bcfdf8a16

> Fix pattern matrix problems when the pattern is used in a Form and creating PDF.
> Bug #691800 exhibited a problem using a Shading (type 2 pattern) in a form.
> This is unusual because hte only way to get a Form out of pdfwrite is to involve transparency.
> When a pattern is used in a form, we do not apply the current CTM, but the
> CTM of the enclosing context. In this case we were still applying the outermost
> context, not the CTM of the page stream (which is the enclosing context of the form).
> Fixing this revealed other problems.
> I've moved the form counting out of the transparency group and into the form
> dictionary creation code where it makes much more sense. This allows me to
> change the 'FormDepth' checks so that we only undo the page content scaling
> if the formdepth is 0.
> In the long run we may need to keep a stack of gstatas (or more accurately the
> CTM) so that if we get nested forms we can apply the correct CTM to any patterns
> in the form. For now, this isn't required, we don't have any test files which nest
> more than 1 form deep.
> This fixes Bug #691800. I also see progressions in the following files:
> Bug6901014_CityMap-evince-pdftopdf.pdf
> Bug691783.pdf
> fts_04_0403.pdf
> fts_06_0608.pdf
> fts_09_0919.pdf
> fts_12_1202.pdf
> fts_12_1205.pdf
> fts_14_1416.pdf
> fts_15_1508.pdf
> fts_15_1510.pdf
> fts_15_1512.pdf
> fts_15_1514.pdf
> fts_15_1516.pdf
> fts_15_1518.pdf
> fts_15_1520.pdf
> fts_28_2803.pdf
> fts_28_2804.pdf
> fts_31_3107.pdf
> gs/base/gdevpdft.c
> gs/base/gdevpdfv.c

2011-08-19 08:42:14 -0700
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
c387412a0267a51fb1b6d3a51c7e70a20533bd50

> Added comments regarding compare_gdev_prn_space_params().
> Added a couple of comments to the header files that declare the
> structures that compare_gdev_prn_space_params() compares warning
> that changes/additions to the structures will require changes to
> that function as well.
> No expected cluster differences since no code changed.
> gs/base/gdevprn.h
> gs/base/gxband.h

2011-08-19 15:14:33 +0100
Chris Liddell <chris.liddell@artifex.com>
493fddf61a96d6dc07c3f376bbb052990ec6a742

> Bug 689283: latest pcl3/doc/reports.txt file
> Our contrib/pcl3 was already at the latest release, but the reports.txt
> file had additions post-release.
> CLUSTER_UNTESTED
> gs/contrib/pcl3/doc/reports.txt

2011-08-19 14:00:43 +0100
Chris Liddell <chris.liddell@artifex.com>
fa67a1d0f4b31841d02f2b6322b53da8a3874cfd

> Bug 692426 (tweak): eliminate warning
> If unix-aux.mak finds sys/time.h exists, make definition it adds to
> gconfig_.h conditional on it not being defined already (it can now
> be defined in the compiler flags as setup by configure).
> No cluster differences.
> gs/base/unix-aux.mak

2011-08-19 13:38:04 +0100
Chris Liddell <chris.liddell@artifex.com>
0ab8cd1259dc76f6b3465f1ccd08a7509428e021

> Reinstate Identity-UTF16-H and UniHojo-UCS2-H CMaps
> We need these in order to use Truetype fonts to emulate CIDFonts,
> see gs_ciddc.ps
> CLUSTER_UNTESTED
> gs/Resource/CMap/Identity-UTF16-H
> gs/Resource/CMap/UniHojo-UCS2-H

2011-08-19 11:48:38 +0100
Chris Liddell <chris.liddell@artifex.com>
714766fb1546616f09dafa8c9d7b4563dd10c65c

> Bug 692426: let configure check for sys/time.h
> The configure script will now check for whether sys/time.h exists, so we
> don't rely on hard coded path check in unix-aux.mak - the checks in
> unix-aux.mak remain for the benefit of those who maintain their own
> makefiles.
> No cluster differences.
> gs/base/configure.ac

2011-08-18 23:10:20 -0700
Michael Vrhel <michael.vrhel@artifex.com>
c7404eceab4d308c67130f43e9a4d4c0b58cd73c

> Fix for Bug 687695.
> Patch supplied by Shailesh Mistry
> gs/base/gdevdgbr.c

2011-08-18 23:06:49 -0700
Michael Vrhel <michael.vrhel@artifex.com>
cb9c046b29cc449fb8e147a4117b7b81dec934a0

> Fix for compiler warnings
> CLUSTER UNTESTED
> gs/base/gxipixel.c

2011-08-17 08:35:48 -0700
Michael Vrhel <michael.vrhel@artifex.com>
942ebdc7700baf85bac4ed76af2fd845f8b7edd3

> Fix for bug 692083. Improper decode scaling was occurring during creation of the color cache.
> gs/base/gxipixel.c

2011-08-18 08:36:40 +0100
Ken Sharp <ken.sharp@artifex.com>
22ff0a3aad850d34d203a629735a94a2e253682a

> Bug #689290 Handle image masks with a height of 1.
> Adopting the patch supplied by Shailesh Mistry which properly processes
> soft mask images with a height of 1.
> This also allows us to do away with an ugly hack to avoid an endless loop.
> By not processing single scan line images we would exit gx_image3x_plane_data
> returning '1' which meant we hadn't processed all the data, which led to
> gx_image3x_plane_data being called again, indefinitely....
> The file for bug 689290 now processes correctly with all devices.
> In addition fts_26_2604.pdf when converted to PDF shows differences, I'm
> not sure why, but they are impossible to detect visually so I don't think
> we should be concerned.
> gs/base/gximag3x.c

2011-08-17 10:31:11 +0100
Chris Liddell <chris.liddell@artifex.com>
766df64767959a3c69357cb8698b4c286957af4d

> Suppress some warnings in gdevcups.c
> As cups_set_color_info() now does things that can fail, it has to return
> an error value (getting rid of the "code set but never used" warning).
> Also, add a "default:" case to a switch to get rid of the warning about
> enum values not handled in a switch - the default case does nothing, so
> behaviour is unchanged.
> Finally, tidy up the initialization of an array of arrays of arrays, getting
> rid of a warning about missing braces.
> No cluster differences.
> gs/cups/gdevcups.c

2011-08-16 19:49:21 -0700
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
b75eacf6a9b3a66265a0194ab21e0971f6e0b44c

> Missed a couple of files that should have been changed as part of the previous commit.
> common/msvc_top.mak
> gs/doc/Develop.htm
> main/pcl6_gcc.mak
> main/pcl6_msvc.mak

2011-08-16 19:19:32 -0700
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
a49306bd0942aaea1bd035d285977c3f1cec0c2e

> Bug 692400. Removed imdi and related devices (wtsimdi and wtscmyk).
> Devices were example devices that have been obsoleted by ICC color
> management.
> gs/base/Makefile.in
> gs/base/configure.ac
> gs/base/devs.mak
> gs/base/gdevimdi.c
> gs/base/gdevwts.c
> gs/base/gs.mak
> gs/base/macos-mcp.mak
> gs/base/macosx.mak
> gs/base/msvclib.mak
> gs/base/openvms.mak
> gs/base/ugcclib.mak
> gs/base/unix-gcc.mak
> gs/base/unixansi.mak
> gs/base/wtsimdi.c
> gs/ghostscript.vcproj
> gs/imdi/Jamfile
> gs/imdi/LICENSE
> gs/imdi/README
> gs/imdi/arch.h
> gs/imdi/cctiff.c
> gs/imdi/cgen.c
> gs/imdi/config.h
> gs/imdi/copyright.h
> gs/imdi/imdi.c
> gs/imdi/imdi.h
> gs/imdi/imdi_gen.c
> gs/imdi/imdi_gen.h
> gs/imdi/imdi_imp.h
> gs/imdi/imdi_k.c
> gs/imdi/imdi_k.h
> gs/imdi/imdi_tab.c
> gs/imdi/imdi_tab.h
> gs/psi/msvc.mak
> gs/psi/os2.mak

2011-08-16 23:59:51 +0100
Chris Liddell <chris.liddell@artifex.com>
781b7387334f9c9d98220567f59e5fe1843ad43d

> Bug 691922: handle color model change in gdevcups.c
> Revise the previous method for setting a suitable ICC profile when the cups
> color model changes, and ensure that the raster memory gets recreated
> afterwards.
> No cluster differences.
> gs/cups/gdevcups.c

2011-08-16 16:48:01 -0600
Henry Stiles <henry.stiles@artifex.com>
9c074dc8c611a9d225a50ae690dcc8250542c7e9

> Fixes 691820 by removing the device, the authors in the contrib.mak
> and source code file (gdevlx50.c) have been sent email the device is
> broken.
> CLUSTER_UNTESTED
> gs/base/configure.ac
> gs/contrib/contrib.mak
> gs/contrib/gdevlx50.c

2011-08-16 22:45:30 +0100
Chris Liddell <chris.liddell@artifex.com>
58d19521e19252f45ec0d4c212fe938580fbeb54

> Sort line endings problem.
> gs/openjpeg/libopenjpeg/opj_malloc.h

2011-08-16 08:57:46 -0700
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
399c536b8c8fda93071e2895ab88ea11b92e1eb5

> Bug 688651. Change EPSON ESC/P change color command from ascii to unsigned char.
> I don't have an Epson printer to test this with, but it seems
> reaonable that the command would not use and ascii parameter.
> gs/base/gdevepsc.c

2011-08-16 16:30:01 +0100
Chris Liddell <chris.liddell@artifex.com>
d9c04fa861359debdf95d698549a08253283d45f

> Correct a typo checking if we really need to change profiles.
> No cluster differences.
> gs/base/gsicc_manage.c

2011-08-16 02:30:38 +0200
Till Kamppeter <till.kamppeter@gmail.com>
d8da050fcfcb6bd62024ab007d4ad2c6a7b8920b

> CUPS Raster: Improved recognition of black pixels on CMYK -> RGBW conversion
> To improve on bug 691922.
> gs/cups/gdevcups.c

2011-08-15 23:47:55 +0200
Till Kamppeter <till.kamppeter@gmail.com>
1920f21e245e9e1c1ed9e8df1314b4b548088db5

> Set correct default color profiles for all color spaces of the CUPS Raster device
> If no output profile is supplied by the user via
> "-sOutputICCProfile=...", set a default profile appropriate to the
> selected color space (RGBish additive, CMYKish subtractive, or
> grayscale). This should really be the last piece of the fix for bug
> 691922.
> gs/cups/gdevcups.c

2011-08-15 23:10:14 +0200
Till Kamppeter <till.kamppeter@gmail.com>
05b517bd3d350e08c08604dcf72741188b4d586e

> Eliminated compiler warning in gdevcups.c.
> gs/cups/gdevcups.c

2011-08-15 11:57:26 -0700
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
78272d055d4c1ca8fbd301130473d00f611bd64e

> Fixed compiler warning in base/gdevprn.c.
> gs/base/gdevprn.c

2011-08-15 14:04:17 +0200
Till Kamppeter <till.kamppeter@gmail.com>
eb6b63157d90bed5df4b5dd134b5581b4a38ae39

> Let the CUPS Raster output device generate RGBW as defined in the CUPS documentation
> The CUPS Raster output device ("cups") has an RGBW output color
> space. This was intended to produce standard RGB plus an extra channel
> which marks true black pixels by being 0 and for all non-black pixels
> having all bits set to 1. This mode is designed to control the use of
> black ink or toner for black text in printed documents.
> The RGBW output of Ghostscript's CUPS Raster output device was
> actually inverted CMYK, an RGBW which is known to be used by
> projectors.
> The HPLIP printer drivers worked around this bug being able to
> understand both modes correctly and so printouts on HP printers were
> correct before, too, but we need to follow the documentation of CUPS,
> so that if other printer manufacturers/driver developers make use of
> the RGBW mode get correct results.
> This finally fixes bug 691922.
> CUPS documentation:
> http://www.cups.org/documentation.php/doc-1.5/spec-raster.html
> Section: Pixel Value Coding, CUPS_CSPACE_RGBW
> gs/cups/gdevcups.c

2011-08-15 01:39:00 -0700
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
28f0da42cbffd79ba747a3e14a899dda5e7a4bd7

> Fix for Bug 692375. Comparing two structures with memcmp() is a bad idea.
> Code in gdevprn.c relied on memcmp() to compare two structures;
> this isn't allowed by C since there can be gaps in the structure
> due to padding. This issue was exposed when llvm-gcc became the
> default compiler in Xcode 4. The fix is to compare the structures
> element by element.
> For more information see: http://c-faq.com/struct/compare.html
> No expected cluster difference since none of the cluster nodes use
> llvm-gcc.
> gs/base/gdevprn.c

2011-08-15 07:58:13 +0100
Ken Sharp <ken.sharp@artifex.com>
f369ae5a30143cdfc27df96de9b1b5bab1c72c6f

> Bug #692422. When creating a UUID for PDF files, an earlier change added
> 'uuid:' to the XML.
> This potentially caused a buffer overrun leading to a string not being
> NULL-terminated and causing a corrupted UUID to be written. Although I
> am unable to reproduce this, this patch resolves the problem for the customer.
> gs/base/gdevpdfe.c

2011-08-13 10:15:17 -0700
Michael Vrhel <michael.vrhel@artifex.com>
3c15d3495e4e47a41938710bf2657d0c674f1e55

> Fix for bug 692392. This makes sure that the transfer function is only applied to the K channel when we are mapping gray to CMYK.
> Also fix for case in which interpolation of 12bit images does not work when using the ICC rendering operation.
> gs/base/gdevp14.c
> gs/base/gdevplnx.c
> gs/base/gsciemap.c
> gs/base/gsequivc.c
> gs/base/gsicc.c
> gs/base/gxcmap.c
> gs/base/gxcmap.h
> gs/base/gxi12bit.c
> gs/base/gxiscale.c
> gs/base/lib.mak

2011-08-12 18:34:55 +0100
Chris Liddell <chris.liddell@artifex.com>
97aef7a14df2e7e552592cf4a79c28747948d106

> Add the relevant part of the OpenJPEG code to our repos.
> We only need the "library" part, not the example apps and third party
> libraries (only used by the example apps), and they add up to a lot of space.
> CLUSTER_UNTESTED
> gs/openjpeg/libopenjpeg/CMakeLists.txt
> gs/openjpeg/libopenjpeg/Makefile.am
> gs/openjpeg/libopenjpeg/Makefile.in
> gs/openjpeg/libopenjpeg/bio.c
> gs/openjpeg/libopenjpeg/bio.h
> gs/openjpeg/libopenjpeg/cio.c
> gs/openjpeg/libopenjpeg/cio.h
> gs/openjpeg/libopenjpeg/dwt.c
> gs/openjpeg/libopenjpeg/dwt.h
> gs/openjpeg/libopenjpeg/event.c
> gs/openjpeg/libopenjpeg/event.h
> gs/openjpeg/libopenjpeg/fix.h
> gs/openjpeg/libopenjpeg/image.c
> gs/openjpeg/libopenjpeg/image.h
> gs/openjpeg/libopenjpeg/int.h
> gs/openjpeg/libopenjpeg/j2k.c
> gs/openjpeg/libopenjpeg/j2k.h
> gs/openjpeg/libopenjpeg/j2k_lib.c
> gs/openjpeg/libopenjpeg/j2k_lib.h
> gs/openjpeg/libopenjpeg/jp2.c
> gs/openjpeg/libopenjpeg/jp2.h
> gs/openjpeg/libopenjpeg/jpt.c
> gs/openjpeg/libopenjpeg/jpt.h
> gs/openjpeg/libopenjpeg/mct.c
> gs/openjpeg/libopenjpeg/mct.h
> gs/openjpeg/libopenjpeg/mqc.c
> gs/openjpeg/libopenjpeg/mqc.h
> gs/openjpeg/libopenjpeg/openjpeg.c
> gs/openjpeg/libopenjpeg/openjpeg.h
> gs/openjpeg/libopenjpeg/opj_includes.h
> gs/openjpeg/libopenjpeg/opj_malloc.h
> gs/openjpeg/libopenjpeg/pi.c
> gs/openjpeg/libopenjpeg/pi.h
> gs/openjpeg/libopenjpeg/raw.c
> gs/openjpeg/libopenjpeg/raw.h
> gs/openjpeg/libopenjpeg/t1.c
> gs/openjpeg/libopenjpeg/t1.h
> gs/openjpeg/libopenjpeg/t1_generate_luts.c
> gs/openjpeg/libopenjpeg/t1_luts.h
> gs/openjpeg/libopenjpeg/t2.c
> gs/openjpeg/libopenjpeg/t2.h
> gs/openjpeg/libopenjpeg/tcd.c
> gs/openjpeg/libopenjpeg/tcd.h
> gs/openjpeg/libopenjpeg/tgt.c
> gs/openjpeg/libopenjpeg/tgt.h
> gs/openjpeg/opj_config.h.in.user

2011-08-12 22:24:32 +0200
Till Kamppeter <till.kamppeter@gmail.com>
46b4ee6b5ef44838ea5c60aeeab76047a666d561

> Fixed landscape orientation printing of PXL drivers pxlmono/pxlcolor
> Bug 692128.
> Thanks to Tim Waugh from Red Hat for the patch.
> gs/base/gdevpxut.c

2011-08-12 18:19:59 +0100
Chris Liddell <chris.liddell@artifex.com>
5d45b3c3bc664f7e8a81e85c812dd100543d4cd9

> Bug 690054: fix a bunch of warnings in base/
> A couple were real functional problems (left-overs from old API
> versions), the rest were the usual benign but irritating noise.
> No cluster differences.
> gs/base/gdevimdi.c
> gs/base/gdevokii.c
> gs/base/gdevphex.c
> gs/base/gdevsunr.c
> gs/base/gdevtsep.c
> gs/base/gdevwts.c

2011-08-12 15:33:40 +0100
Chris Liddell <chris.liddell@artifex.com>
78fe552263a621714c8335ec46f4493121856192

> Bug 690566: small conformance changes to PPD
> Include change so (I think) the PPDs are now conformant, but leave out the
> ones that change the default media.
> Credit to Werner Fink ( werner@suse.de ) for the changes.
> CLUSTER_UNTESTED
> gs/lib/cbjc600.ppd
> gs/lib/cbjc800.ppd

2011-08-12 15:18:50 +0100
Chris Liddell <chris.liddell@artifex.com>
8c523f7a77a4f8f3da47bdb452f8df7cc30812ce

> Bug 690565: bring the header include up-to-date.
> Pull in the tiny part of the patch in the above bug that is relevant
> to the current source.
> No cluster differences.
> gs/contrib/lips4/gdevl4v.c

2011-08-12 14:05:14 +0100
Chris Liddell <chris.liddell@artifex.com>
d9e044eeec3f747be7a0d8270b52cd8a8b4d88c5

> Bug 692188: CMS code doesn't compile using HP cc compiler
> Fix for lcms definition of "LCMS_INLINE" on the HP compiler.
> Credit to Ian Ashley ( ian.ashley@opentext.com ) for the patch.
> No cluster differences.
> gs/lcms/include/lcms.h

2011-08-12 13:52:02 +0100
Chris Liddell <chris.liddell@artifex.com>
091636d3d688823d3c4062471700085ca8c91fd1

> Bug 692417: fix a configure problem on OpenBSD
> credit to Henk Jan Priester ( hjpriester@gmail.com ) for the patch.
> No cluster differences.
> gs/base/configure.ac

2011-08-12 13:43:53 +0100
Chris Liddell <chris.liddell@artifex.com>
cacd7dc3e8c6ab4d601330161cd44e3e66eecefa

> Bug 691430: Make OpenJPEG a configure-able option.
> No cluster differences.
> gs/base/Makefile.in
> gs/base/configure.ac
> gs/base/openjpeg.mak

2011-08-09 11:52:06 -0700
Michael Vrhel <michael.vrhel@artifex.com>
8cf0fb4b1e6ee17bdc0fe5e198b593244c89281d

> Fixes for various compiler warnings in the ICC code
> gs/base/gdevxcf.c
> gs/base/gscdevn.c
> gs/base/gsciemap.c
> gs/base/gsdparam.c
> gs/base/gsicc.c
> gs/base/gsicc_cache.c
> gs/base/gsicc_cache.h
> gs/base/gsicc_create.c
> gs/base/gsicc_manage.c
> gs/base/gsicc_manage.h
> gs/base/gxclimag.c
> gs/base/gxcmap.c
> gs/psi/zcie.c

2011-08-10 21:27:35 +0100
Chris Liddell <chris.liddell@artifex.com>
d63a63c74e7d84aeb48024526b6af7ecaf343733

> Fix the Mac platform test in the luratech section.
> No cluster differences.
> gs/base/configure.ac

2011-08-10 10:27:03 +0100
Chris Liddell <chris.liddell@artifex.com>
edd256d908da6ad77d3e595febffcc3717d5e900

> Bug 692367: add gs_memory_t arg to finalize method
> By adding a gs_memory_t argument to the object "finalize" method, we can
> dispense with the pointer-pun hackery that stores the memory context
> in an extra struct array element of the IO device table, so it's availabe
> in the finalize method.
> Although primarily addresses one hack, this commit touches a number of files
> because it affects every object with a "finalize" method.
> This also addresses an error condition cleanup of a partially create IO
> device table.
> No cluster differences.
> gs/base/gdevdevn.c
> gs/base/gdevpdf.c
> gs/base/gdevpsd.c
> gs/base/gdevtsep.c
> gs/base/gsalloc.c
> gs/base/gscspace.c
> gs/base/gsdevice.c
> gs/base/gsfcid.c
> gs/base/gsfont.c
> gs/base/gsicc.c
> gs/base/gsiodev.c
> gs/base/gsmalloc.c
> gs/base/gsmchunk.c
> gs/base/gsstype.h
> gs/base/stream.c
> gs/psi/igc.c
> gs/psi/igc.h
> gs/psi/iname.c
> gs/psi/isave.c
> gs/psi/zdscpars.c
> gs/psi/zfjbig2.c
> xps/xpsfont.c

2011-08-09 23:57:26 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
7ac24676ec25007066576852934cdfaacd8aae91

> The first OpenJPEG effort.
> Add JPEG 2000 implementation based on OpenJPEG library.
> This revision does yet not support the following features:
> - CMYK and eYCC color spaces
> - downsampled color planes
> - alpha transparency planes.
> gs/base/Makefile.in
> gs/base/gs.mak
> gs/base/lib.mak
> gs/base/macos-mcp.mak
> gs/base/openjpeg.mak
> gs/base/sjpx_openjpeg.c
> gs/base/sjpx_openjpeg.h
> gs/base/winlib.mak
> gs/psi/int.mak
> gs/psi/msvc.mak
> gs/psi/zfjpx.c

2011-08-09 20:07:12 -0700
Michael Vrhel <michael.vrhel@artifex.com>
9b8671d7d27c3d203a55e3f357c1435d1dfd72a3

> Add includes for error handling. Windows build failed to link for me without these.
> CLUSTER_UNTESTED
> gs/base/gp_mshdl.c
> gs/base/gsicc_lcms.c
> gs/base/lib.mak
> gs/base/winlib.mak

2011-08-09 22:56:26 +0700
Robin Watts <robin.watts@artifex.com>
1eb77139f09b98671e8e83b921f1c351df4ecb84

> Fix (currently harmless) typo in gxdownscale.c
> I was testing adjust_width before accessing adjust_width_proc, when
> it would have been better to test adjust_width_proc. Currently
> adjust_width != 0 is true iff adjust_width_proc != NULL, so no
> harm other than possible warnings.
> gs/base/gxdownscale.c

2011-08-09 09:41:07 -0600
Henry Stiles <henry.stiles@artifex.com>
8f2ecf42738966678a8826d8de9c60c4f3684600

> Remove gserror.h, its contents have been moved to gserrors.h so we
> only need have one include file to use for error reporting.
> gs/base/gdevdbit.c
> gs/base/gdevhit.c
> gs/base/gdevimdi.c
> gs/base/gdevm1.c
> gs/base/gdevpipe.c
> gs/base/gp_mshdl.c
> gs/base/gp_msprn.c
> gs/base/gp_nsync.c
> gs/base/gp_os2pr.c
> gs/base/gp_psync.c
> gs/base/gp_win32.c
> gs/base/gp_wsync.c
> gs/base/gsbitops.c
> gs/base/gscencs.c
> gs/base/gserror.h
> gs/base/gserrors.h
> gs/base/gsfname.c
> gs/base/gsicc_lcms.c
> gs/base/gsicc_lcms2.c
> gs/base/gsiomacres.c
> gs/base/gsmalloc.c
> gs/base/gsmisc.c
> gs/base/gsparamx.c
> gs/base/gstext.c
> gs/base/gsutil.c
> gs/base/gx.h
> gs/base/gxclfile.c
> gs/base/gxdownscale.c
> gs/base/lib.mak
> gs/base/minftrsz.c
> gs/base/saes.c
> gs/base/sarc4.c
> gs/base/scfparam.c
> gs/base/sdcparam.c
> gs/base/sddparam.c
> gs/base/sdeparam.c
> gs/base/sfxcommon.c
> gs/base/sfxstdio.c
> gs/base/shcgen.c
> gs/base/simscale.c
> gs/base/sjbig2.c
> gs/base/sjbig2_luratech.c
> gs/base/sjpegd.c
> gs/base/sjpx.c
> gs/base/sjpx_luratech.c
> gs/base/spsdf.c
> gs/base/szlibc.c
> gs/base/winlib.mak
> gs/ghostscript.vcproj
> gs/psi/fapi_ft.c
> gs/psi/int.mak
> gs/psi/os2.mak
> gs/psi/zicc.c
> pcl/pcl.mak
> pcl/pgfdata.c
> pl/pl.mak
> pl/plchar.c
> pl/pldraw.c
> pl/plfont.c
> pl/pluchar.c
> pl/plufont.c
> pl/plulfont.c
> pxl/pxl.mak
> pxl/pxoper.h
> pxl/pxparse.c
> svg/ghostsvg.h
> svg/svg.mak
> tools/gslite/gslt_font_api.c
> tools/gslite/gslt_font_api_test.c
> tools/gslite/gslt_font_int.h
> tools/gslite/gslt_font_test.c
> tools/gslite/gslt_image.c
> tools/gslite/gslt_image_jpeg.c
> tools/gslite/gslt_image_png.c
> tools/gslite/gslt_image_tiff.c
> xps/ghostxps.h

2011-08-08 04:36:56 -0700
Robin Watts <robin@peeves.(none)>
02ced7b54e8c10bb6ded0efff72990a88ec50027

> Add backtrace to memento SEGV handler.
> Simple backtrace handling; thanks to Tor for the pointer to the
> stackoverflow article.
> This only works with libc based compilers, and may possibly get the
> bottom couple of entries on the stack wrong. It also doesn't give
> file and line references, but it does at least give the function
> names.
> Other suggestions in the article offered other ways of working, but
> they all rely on other libraries, or non-portable features, so this
> seems the best possible first step.
> gs/base/memento.c

2011-08-06 16:33:49 -0700
Robin Watts <robin@peeves.(none)>
4b069b32b3c09eef440d5770d654208c0930c54a

> Improved squeeze2html.pl script; add -q option.
> New -q option to omit 'green' runs from the file. Saves substantially
> on disc space.
> It may now be better to use this as a pipe from a gs process doing
> memory squeezing to save disc space. e.g:
> MEMENTO_SQUEEZEAT=1 gs -sDEVICE=png16m -o /dev/null tiger.eps |
> squeeze2html.pl -q | gzip -9c > out.html.gz
> (the theory being that the omission of 'green' runs saves more space
> than the html overhead).
> The output of the above invocation *without* going through squeeze2html.pl
> hit 2.7Gig before I killed it, so be warned!
> gs/toolbin/squeeze2html.pl

2011-08-06 14:05:20 -0700
Michael Vrhel <michael.vrhel@artifex.com>
2168e49ea9aa05ef23110addea20c3f29b66bae6

> Fix for Bug 690137
> The attempts to get the range properly set up for when we have an ICC profile for CIELAB.
> The issue is that we may have vector drawings that are encoded across the range of real
> CIELAB values like [100,0] [-128, 127] [-128, 127]. Image data of course is not encoded
> in this form. This fix corrects for this difference.
> gs/base/devs.mak
> gs/base/gdevpdfi.c
> gs/base/gsicc_manage.c
> gs/base/gsicc_manage.h
> gs/psi/zicc.c

2011-08-06 14:28:11 -0700
Robin Watts <robin@peeves.(none)>
bfa6e6513b95f51fda49666b6a28af6c60c66e1b

> First version of script to make memento squeezing memory readable.
> Build gs with Memento enabled: make debug XCFLAGS="-DMEMENTO"
> Then run a mem squeeze:
> MEMENTO_SQUEEZEAT=1 gs -sDEVICE=png16m -o /dev/null tiger.eps 2>&1 > log
> Then this script will turn 'log' into something much more readable.
> squeeze2html.pl < log > out.html
> Though you may want to use:
> head -10000 log | squeeze2html.pl > out.html
> to control the size.
> Red boxes are squeezepoints where we SEGV. Yellow are points where we leak.
> Green where we complete cleanly.
> To reproduce a single point (say number 52) in the debugger use:
> MEMENTO_FAILAT=52 gdb --args gs -sDEVICE=png16m -o /dev/null tiger.eps
> Then 'run' when gdb starts.
> gs/toolbin/squeeze2html.pl

2011-08-05 16:45:44 +0100
Chris Liddell <chris.liddell@artifex.com>
bd0ffdf2bfd324656206b93498b2814ad2d4e36d

> Pull final doc changes from the gs904 branch to master.
> "Bring the changelog up to date since the RC, and revise the date."
> CLUSTER_UNTESTED
> gs/doc/API.htm
> gs/doc/C-style.htm
> gs/doc/Commprod.htm
> gs/doc/DLL.htm
> gs/doc/Deprecated.htm
> gs/doc/Details8.htm
> gs/doc/Details9.htm
> gs/doc/Develop.htm
> gs/doc/Devices.htm
> gs/doc/Drivers.htm
> gs/doc/Fonts.htm
> gs/doc/Helpers.htm
> gs/doc/History1.htm
> gs/doc/History2.htm
> gs/doc/History3.htm
> gs/doc/History4.htm
> gs/doc/History5.htm
> gs/doc/History6.htm
> gs/doc/History7.htm
> gs/doc/History8.htm
> gs/doc/History9.htm
> gs/doc/Install.htm
> gs/doc/Issues.htm
> gs/doc/Language.htm
> gs/doc/Lib.htm
> gs/doc/Make.htm
> gs/doc/News.htm
> gs/doc/Projects.htm
> gs/doc/Ps-style.htm
> gs/doc/Ps2epsi.htm
> gs/doc/Ps2pdf.htm
> gs/doc/Ps2ps2.htm
> gs/doc/Psfiles.htm
> gs/doc/Readme.htm
> gs/doc/Release.htm
> gs/doc/Source.htm
> gs/doc/Unix-lpr.htm
> gs/doc/Use.htm
> gs/doc/Xfonts.htm
> gs/doc/gs-vms.hlp
> gs/man/dvipdf.1
> gs/man/font2c.1
> gs/man/gs.1
> gs/man/gslp.1
> gs/man/gsnd.1
> gs/man/pdf2dsc.1
> gs/man/pdf2ps.1
> gs/man/pdfopt.1
> gs/man/pf2afm.1
> gs/man/pfbtopfa.1
> gs/man/printafm.1
> gs/man/ps2ascii.1
> gs/man/ps2epsi.1
> gs/man/ps2pdf.1
> gs/man/ps2pdfwr.1
> gs/man/ps2ps.1
> gs/man/wftopfa.1

2011-08-05 16:15:02 +0100
Chris Liddell <chris.liddell@artifex.com>
4916cc6cd1a8d5eb8ef411b4c00952dfea44b36f

> Merge doc changes from the gs904 branch to master.
> "Update the docs, version numbers, and dates for 9.04 rc1"
> CLUSTER_UNTESTED
> gs/doc/API.htm
> gs/doc/C-style.htm
> gs/doc/Commprod.htm
> gs/doc/DLL.htm
> gs/doc/Deprecated.htm
> gs/doc/Details8.htm
> gs/doc/Details9.htm
> gs/doc/Develop.htm
> gs/doc/Devices.htm
> gs/doc/Drivers.htm
> gs/doc/Fonts.htm
> gs/doc/Helpers.htm
> gs/doc/History1.htm
> gs/doc/History2.htm
> gs/doc/History3.htm
> gs/doc/History4.htm
> gs/doc/History5.htm
> gs/doc/History6.htm
> gs/doc/History7.htm
> gs/doc/History8.htm
> gs/doc/History9.htm
> gs/doc/Install.htm
> gs/doc/Issues.htm
> gs/doc/Language.htm
> gs/doc/Lib.htm
> gs/doc/Make.htm
> gs/doc/News.htm
> gs/doc/Projects.htm
> gs/doc/Ps-style.htm
> gs/doc/Ps2epsi.htm
> gs/doc/Ps2pdf.htm
> gs/doc/Ps2ps2.htm
> gs/doc/Psfiles.htm
> gs/doc/Readme.htm
> gs/doc/Release.htm
> gs/doc/Source.htm
> gs/doc/Unix-lpr.htm
> gs/doc/Use.htm
> gs/doc/Xfonts.htm
> gs/doc/gs-vms.hlp
> gs/man/dvipdf.1
> gs/man/font2c.1
> gs/man/gs.1
> gs/man/gslp.1
> gs/man/gsnd.1
> gs/man/pdf2dsc.1
> gs/man/pdf2ps.1
> gs/man/pdfopt.1
> gs/man/pf2afm.1
> gs/man/pfbtopfa.1
> gs/man/printafm.1
> gs/man/ps2ascii.1
> gs/man/ps2epsi.1
> gs/man/ps2pdf.1
> gs/man/ps2pdfwr.1
> gs/man/ps2ps.1
> gs/man/wftopfa.1

2011-08-05 09:02:28 -0600
Henry Stiles <henry.stiles@artifex.com>
6a537abc3001a8a1919672a6d936521eba40615a

> 9.04 NEWS file.
> NEWS

2011-08-05 12:07:10 +0100
Chris Liddell <chris.liddell@artifex.com>
74264d5900bb6e4a5cacadfb67db198dcd5fef4e

> Ensure Win UNICODE/UTF8 code is disabled for ls build
> CLUSTER_UNTESTED
> language_switch/pspcl6_msvc.mak

2011-08-05 12:05:23 +0100
Chris Liddell <chris.liddell@artifex.com>
b5ae769f4f5ac9c72f2e960314d0e44c7655e85a

> Remove a now spurious debug message.
> CLUSTER_UNTESTED
> gs/cups/gdevcups.c

2011-08-04 15:14:05 -0600
Henry Stiles <henry.stiles@artifex.com>
7e4051fa5cde4102b2d3e1d53b528e0797718a10

> Fix 692369 add erasepage back to device initialization in the language
> switch build.
> psi/psitop.c

2011-08-04 12:59:49 -0700
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
b00d53f8060554976be107b5009b96b76fbd46b6

> Added a couple of dependencies to fix parallel make.
> gs/base/lib.mak
> gs/contrib/contrib.mak

2011-08-04 14:40:12 +0100
Chris Liddell <chris.liddell@artifex.com>
3e07ccf224b0811b017fd41d1fdb24310240294a

> Bug 691586: again, ensure that GS knows when cups changes the media size
> Move the fix for Bug 692393 to immediately after the call to
> gdev_prn_put_params() - before the call to gx_device_set_media_size()
> as that can also change the device's width and height settings.
> With this fix, I have also removed the temporary workaround put in place
> with commits 16c410fc29575abffb60926949433653186915fd and
> bd33c8f57b1a6e3d365ef0efd8dd7571a14310fa.
> No cluster differences.
> gs/cups/gdevcups.c

2011-08-04 10:05:13 +0100
Chris Liddell <chris.liddell@artifex.com>
2f4dd0504e9a51dd1c4ad2da1c5135b9e4c67d26

> Revise Luratech section of build docs.......
> ... to reflect that we now look for the Luratech code under
> gs/luratech/ldf_jb2 and gs/luratech/lwf_jp2 instead of gs/lwf_jp2 and
> gs/ldf_jb2
> CLUSTER_UNTESTED
> gs/doc/Make.htm

2011-08-03 17:44:55 +0100
Chris Liddell <chris.liddell@artifex.com>
b5ef299133e7248ca88819d2fa446828e173ad24

> Bug 692393: ensure GS realises cups changed the page dimensions.
> After having done media selection from the cups media list, we need to
> ensure that GS realises that page dimensions in the device structure
> may have changed since the raster memory was last created - this ensures
> that GS will reallocate the memory, and correctly setup the
> line_ptrs array for the new page size.
> No cluster differences.
> gs/cups/gdevcups.c

2011-08-02 18:19:35 +0100
Robin Watts <Robin.Watts@artifex.com>
ff6e0443bb89434f5c37790fbbf0a5467c2ce2d3

> Memento_failThisEvent addition and usage in chunk allocator.
> Add a new Memento function (Memento_failThisEvent) and calls to it from
> the chunk allocator. This should allow us to do memory squeezing tests
> that check chunk allocator allocations too.
> Tweaks to Memento to ensure it defines MEMENTO_HAS_FORK on both unix
> and macosx automatically.
> No cluster differences expected.
> gs/base/gsalloc.c
> gs/base/memento.c
> gs/base/memento.h

2011-08-02 18:32:09 +0100
Robin Watts <robin.watts@artifex.com>
49f11634e3ade5a0ffaf3d2de4389d59fcfb4769

> Remove unused rectangle arg from shading internals. Add comments.
> Tiny changes, done while trying to follow the code in search of
> a bugfix.
> No cluster differences expected.
> gs/base/gxshade1.c
> gs/base/gxshade6.c

2011-08-02 09:38:39 +0100
Ken Sharp <ken.sharp@artifex.com>
60dd70326d2294a0927696ad261d4aa92c67d5a4

> Typo in opdfread header file 'excp' should have been 'exp'.
> Fixes bug #692387
> gs/base/opdfread.h

2011-08-01 15:36:52 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
4eee9bcfcc2ab0f6be5e997a3c8d87fafab60c4e

> Remove an extra copy of gs_cet.ps from %rom% .
> gs/psi/psromfs.mak

2011-08-01 16:15:55 +0100
Robin Watts <Robin.Watts@artifex.com>
c0040ecf8553bdd9f8028fe5f816af24e5070d29

> Backout accidental commit of bbb8f98; "Alexs patch."
> As part of investigations into 692352 I committed Alex's patch locally.
> Unfortunately, I then let it escape into the wider world.
> Backing it out now with apologies to everyone.
> gs/Resource/Init/pdf_draw.ps

2011-08-01 16:28:52 +0200
Till Kamppeter <till.kamppeter@gmail.com>
f23b5bbfec46882da955409e70a0bfbff6f43827

> Fixes on the gstoraster CUPS filter
> 1. gstoraster crashes when run outside CUPS (bug #692384)
> 2. All error messages issued by gstoraster are without newline (bug #692385)
> Thanks to Tim Waugh from Red Hat for the patches.
> gs/cups/colord.c
> gs/cups/gstoraster.c

2011-08-01 12:18:25 +0100
Robin Watts <Robin.Watts@artifex.com>
bd33c8f57b1a6e3d365ef0efd8dd7571a14310fa

> Tweak to tkampeters previous commit to workaround bug 691586.
> Avoid warnings given on some platforms about "unreachable code" by
> using an informative #define.
> No cluster differences expected.
> gs/cups/gdevcups.c

2011-08-01 13:05:09 +0200
Till Kamppeter <till.kamppeter@gmail.com>
16c410fc29575abffb60926949433653186915fd

> CUPS Raster output device: Ignore RIP_MAX_CACHE environment variable
> Ghostscript is (at least currently) not able to work with hard-limited
> space parameters. It crashes with a segmentation fault on many input
> files then. Leaving the setting of these parameters fully automatic
> Ghostscript works just fine. As in most distributions (Currently all
> except Debian, Ubuntu, and their derivatives) CUPS imposes a hard
> limit via the RIP_MAX_CACHE environment variable, the only way to
> assure reliable working of Ghostscript is to ignore the parameter,
> leaving the space parameters in automatic mode. For CUPS this should
> be no regression, as print queues with other Ghostscript drivers (like
> pxlcolor, ljet4, ...) worked without hard limits all the time and no
> one complained.
> To ignore this RIP_MAX_CACHE we simply add a "return" right at the
> beginning of this function. It will be removed when a real fix gets
> into place.
> See http://bugs.ghostscript.com/show_bug.cgi?id=691586
> gs/cups/gdevcups.c

2011-08-01 00:37:33 -0700
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
e57a8e14f12ef4a4a62f471be55c13ada2aef159

> Changes to clusterpush.pl documentation.
> gs/toolbin/localcluster/clusterpush.txt

2011-07-30 17:48:14 +0100
Robin Watts <Robin.Watts@artifex.com>
951dee021a45d501e159a3b08624979604e906f5

> Fix bug 692349: UNICODE build of gs not available with VS2003 or VS6.
> Apply a slightly tweaked version of alexchers patch to define wmemset
> when it's not provided by the headers.
> No cluster differences expected.
> gs/psi/dwtext.c
> gs/psi/msvc.mak

2011-07-28 18:14:34 +0100
Robin Watts <Robin.Watts@artifex.com>
bbb8f980f19149b769f602dd4594aa6ec6ceeb29

> Alexs patch.
> gs/Resource/Init/pdf_draw.ps

2011-07-30 11:56:53 +0200
Till Kamppeter <till.kamppeter@gmail.com>
6c5f9661790b886a681b8926126875e6df59cbb1

> Added "-dNOINTERPOLATE" to the Ghostscript command lines of the CUPS filters
> This makes rendering significantly faster and the output of normal
> files comming as print jobs from applications does not show any
> visible difference.
> gs/cups/gstoraster.c
> gs/cups/pstopxl.in

2011-07-29 14:01:58 -0700
Michael Vrhel <michael.vrhel@artifex.com>
0132422fe0543a9473b1605a79f2dd46018de4e2

> Another fix for cups RGBW. This gets the color set up properly for RGB.
> gs/base/gsicc_manage.c
> gs/base/gsicc_manage.h
> gs/cups/gdevcups.c

2011-07-29 15:27:13 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
87045a3280e268a52f0d738d34f2a6a3ea093406

> Bug 691184: Improve comments in cidfmap file.
> Add a comment to cidfmap file that shows how to use getenv operator
> to construct a path dynamically.
> gs/Resource/Init/cidfmap

2011-07-29 12:18:04 -0700
Michael Vrhel <michael.vrhel@artifex.com>
84177fe99ebd2fa75abe690e0f2a0ef7d7b762e1

> Fix for cups RGBW color space so that transparency works properly.
> gs/cups/gdevcups.c

2011-07-29 08:14:04 -0700
Michael Vrhel <michael.vrhel@artifex.com>
c90da1237c8d88547377511e7b9d27348f3d7b31

> A test for fixing RGBW in gdevcups.c
> gs/cups/gdevcups.c

2011-07-29 19:40:45 +0100
Robin Watts <Robin.Watts@artifex.com>
3d6c383d5e6c9eb23c3b150f4b7e87dc3cb3cf2b

> Speedup for Mementos checking of freed filled blocks.
> Check an (aligned) int at a time rather than a byte at a time.
> CLUSTER_UNTESTED as this is not enabled.
> gs/base/memento.c

2011-07-29 15:42:49 +0100
Robin Watts <Robin.Watts@artifex.com>
802e977e87ba0d96445e06aa83f32dd31a79f677

> Fix compile_inits=1 ufst builds; don't compact the FCOfontmap-PCLPS2 file.
> The FCOfontmap-PCLPS2 file isn't *really* postscript, so don't compact
> it. Fixes bug 692383 (at least for the non 9.04 case).
> gs/psi/psromfs.mak

2011-07-29 10:16:39 +0100
Chris Liddell <chris.liddell@artifex.com>
217f9712df606e4dedc8afe1220e6b30df627516

> Increment version number for "master".
> gs/Resource/Init/gs_init.ps
> gs/base/version.mak
> pl/pl.mak

2011-07-29 09:40:34 +0100
Chris Liddell <chris.liddell@artifex.com>
1689828742df05af2f82d3b70f16b8c9457aeed1

> Change the expected directory for luratech.
> For the build system to automatically include the luratech JPX and JBIG2
> code, we previously checked for the existence of lwf_jp2 and ldf_jb2
> directories under the Ghostscript source dir. This changes it to check
> for <gs>/luratech/lwf_jp2 and <gs>/luratech/ldf_jb2 instead.
> CLUSTER_UNTESTED
> gs/base/configure.ac
> gs/psi/msvc.mak

2011-07-28 22:28:37 -0600
Henry Stiles <henry.stiles@artifex.com>
c99e0da7b93c065dc22e185e89a48f702c5ab417

> Restore X11 device to the default unix device.
> In setting up autoconf to detect X11 (9b7298f) the X11 devices were
> not put back at the beginning of the device list and so were no longer
> the default device.
> main/pcl6_gcc.mak

2011-07-28 17:16:35 +0100
Robin Watts <Robin.Watts@artifex.com>
4f2d3c7b6c8e08a39de3ef1490562937d0f539ff

> Changes to lcms v1 to spot failed allocations.
> lcms v1 sometimes forgets to deal with failed allocations. Patch at
> least some of these problems.
> Driven by bug 692352. Sufficient to make it run to completion now.
> gs/lcms/src/cmsgmt.c
> gs/lcms/src/cmslut.c
> gs/lcms/src/cmsps2.c
> gs/lcms/src/cmssamp.c
> gs/lcms/src/cmsvirt.c
> gs/lcms/src/cmswtpnt.c
> gs/lcms/src/cmsxform.c

2011-07-28 17:08:58 +0100
Robin Watts <Robin.Watts@artifex.com>
393685fddae380778e970345dbdca60274a31e69

> Check for failure to allocate icclink in shading.
> When calling shade_init_fill_state, check for a return code to indicate
> failure. Trigger this case when an attempt to allocate an icclink
> fails.
> No cluster differences expected.
> gs/base/gxshade.c
> gs/base/gxshade.h
> gs/base/gxshade1.c
> gs/base/gxshade4.c

2011-07-28 15:07:14 +0100
Robin Watts <Robin.Watts@artifex.com>
d91b0da2e3dd20561724d574f21882f703bd861c

> Fix typo in rc_decrement description string.
> Simple typo fix. CLUSTER_UNTESTED.
> gs/base/gxclrast.c

2011-07-28 14:03:55 +0100
Chris Liddell <chris.liddell@artifex.com>
e82868f118963df1c86f288ea5b7e50116be75b2

> Work around a bug in gcc 3.4.6 on SPARC.
> gcc 3.4.6 SPARC (possibly versions/ports) when compiling:
> "psc->feof(psc->file)" seems to be unable to differentiate between
> "feof" element in the structure, and "feof()" function from the
> std library, and as a result gives a syntax error.
> So I've renamed the structure entry "peof", and the other two file
> handling function pointers similarly.
> No cluster differences.
> gs/base/mkromfs.c

2011-07-28 10:21:31 +0100
Chris Liddell <chris.liddell@artifex.com>
1ae27b694439c3f7f9d721cbc2c832247e18f4aa

> Disable the Windows UNICODE/UTF8 code for now.
> CLUSTER_UNTESTED
> gs/psi/msvc.mak

2011-07-27 22:12:41 -0700
Michael Vrhel <michael.vrhel@artifex.com>
32b447cba35edb7272eacfef755edec4a174e01e

> Update of Use.htm to include new color control options.
> gs/doc/Use.htm

2011-07-27 16:25:19 +0100
Robin Watts <Robin.Watts@artifex.com>
b3dbb094608e2d5699c6d77d42f4919c0299a02a

> Fix Bug 692368; SEGV with clist transparency pattern in clist rendering.
> The invocation/file given in the bug uses banded rendering (clist).
> While drawing a band, it uses a pattern with transparency, that is
> itself rendered by a clist (using the new pattern clist code).
> A fill rectangle is being done that tries to call the pattern clist
> tiling code without the fill_trans_buffer having been setup, and
> this causes a SEGV.
> The reason for this appears to be that the device used by the
> banded isn't a pdf14 device - instead it's a clipper device wrapping
> the pdf14 device. The clipper device does not call gx_forward_fill_path,
> but instead calls gx_default_fill_path, meaning that the special
> pdf14 handling done to setup the fill_trans_buffer isn't done.
> Making the commit call onwards to gx_forward_fill_path doesn't solve the
> problem either, as that results in no actual clipping being done.
> The fix, therefore appears to be to implement a clipping version of
> fill_path.
> No cluster differences expected.
> gs/base/gdevp14.c
> gs/base/gxclip.c
> gs/base/gxclip.h

2011-07-27 22:14:10 +0200
Till Kamppeter <till.kamppeter@gmail.com>
bf9dc23000675d406d73d987dcc168f6b875ef75

> Fixed the problem that PCL-XL output files got huge after introduction of color management
> The pxlmono and pxlcolor output devices produce PCL XL (PCL 6). With
> the introduction of color management, the size of the output files
> often got 10 times larger as before and so PCL XL jobs often did not
> print as they exhausted the memory of the printer.
> According to the contributor of this patch, Shailesh Mistry, the PDFs
> leading to that problem have a DeviceRGB image which is translated
> into an ICC profile and passed up but the pcl/pxl can not handle
> it. This patch looks for incoming ICC profiles and resolves it into
> the base colour which can be handled at this level.
> The patch returns the size of the PCL XL output files to the old
> values from Ghostscript 8.x.
> Fixes bug 692329.
> gs/base/gdevpx.c

2011-07-27 20:37:20 +0200
Till Kamppeter <till.kamppeter@gmail.com>
6ab36cb4256fbd9aa005b79e317ff0993f4acf3e

> Fixes on the "pstopxl" CUPS filter
> 1. Use POSIX and not Perl regular expressions with sed. This makes the
> script working on a wider scope of systems (Bug #692328).
> 2. Switch the Ghostscript output device "pxlmono" if the "pxlcolor" is
> used but "Gray" chosen as "ColorModel" setting. Monochrome
> "BitsPerPixel" settings do not work with "pxlcolor".
> gs/cups/pstopxl.in

2011-07-27 10:41:14 -0700
Michael Vrhel <michael.vrhel@artifex.com>
9dca5a4f0eb97ccd33f2503b5e1106c4e1747c5e

> Fix for Windows Display Device showing gray only
> This returns the use of DeviceGrayToK=true/false to set
> if the user wants DeviceGray to map to K only for a
> CMYK device. Also, this fixes a problem where high
> level gray scale images were always going to composite
> an not K only. Bug 692204.
> gs/base/gsdparam.c
> gs/base/gsicc_manage.c
> gs/base/gxclrast.c
> gs/psi/zdevice.c

2011-07-27 09:14:04 -0700
Michael Vrhel <michael.vrhel@artifex.com>
927c37a3adec70858787de954cfc620801bf65e5

> Replacement of default gray ICC profile with Artifex generated versions
> I reviewed the bmpcmp results and the relatively few diffs are minor.
> gs/iccprofiles/default_gray.icc
> gs/iccprofiles/sgray.icc

2011-07-26 16:19:42 -0600
Henry Stiles <henry.stiles@artifex.com>
68a0f6217428daf297d73589821b62ba2e862d0f

> Bug 692376, synchronize the cmap file to Ken Lunde's sourceforge
> release.
> gs/Resource/CMap/90ms-RKSJ-UCS2
> gs/Resource/CMap/90pv-RKSJ-UCS2
> gs/Resource/CMap/90pv-RKSJ-UCS2C
> gs/Resource/CMap/Adobe-CNS1-B5pc
> gs/Resource/CMap/Adobe-CNS1-ETenms-B5
> gs/Resource/CMap/Adobe-CNS1-H-CID
> gs/Resource/CMap/Adobe-CNS1-H-Host
> gs/Resource/CMap/Adobe-CNS1-H-Mac
> gs/Resource/CMap/Adobe-CNS1-UCS2
> gs/Resource/CMap/Adobe-GB1-GBK-EUC
> gs/Resource/CMap/Adobe-GB1-GBpc-EUC
> gs/Resource/CMap/Adobe-GB1-H-CID
> gs/Resource/CMap/Adobe-GB1-H-Host
> gs/Resource/CMap/Adobe-GB1-H-Mac
> gs/Resource/CMap/Adobe-GB1-UCS2
> gs/Resource/CMap/Adobe-Japan1-90ms-RKSJ
> gs/Resource/CMap/Adobe-Japan1-90pv-RKSJ
> gs/Resource/CMap/Adobe-Japan1-H-CID
> gs/Resource/CMap/Adobe-Japan1-H-Host
> gs/Resource/CMap/Adobe-Japan1-H-Mac
> gs/Resource/CMap/Adobe-Japan1-PS-H
> gs/Resource/CMap/Adobe-Japan1-PS-V
> gs/Resource/CMap/Adobe-Japan1-UCS2
> gs/Resource/CMap/Adobe-Japan2-0
> gs/Resource/CMap/Adobe-Korea1-H-CID
> gs/Resource/CMap/Adobe-Korea1-H-Host
> gs/Resource/CMap/Adobe-Korea1-H-Mac
> gs/Resource/CMap/Adobe-Korea1-KSCms-UHC
> gs/Resource/CMap/Adobe-Korea1-KSCpc-EUC
> gs/Resource/CMap/Adobe-Korea1-UCS2
> gs/Resource/CMap/B5pc-UCS2
> gs/Resource/CMap/B5pc-UCS2C
> gs/Resource/CMap/CNS01-RKSJ-H
> gs/Resource/CMap/CNS02-RKSJ-H
> gs/Resource/CMap/CNS03-RKSJ-H
> gs/Resource/CMap/CNS04-RKSJ-H
> gs/Resource/CMap/CNS05-RKSJ-H
> gs/Resource/CMap/CNS06-RKSJ-H
> gs/Resource/CMap/CNS07-RKSJ-H
> gs/Resource/CMap/CNS15-RKSJ-H
> gs/Resource/CMap/ETen-B5-UCS2
> gs/Resource/CMap/GB-RKSJ-H
> gs/Resource/CMap/GBK-EUC-UCS2
> gs/Resource/CMap/GBT-RKSJ-H
> gs/Resource/CMap/GBpc-EUC-UCS2
> gs/Resource/CMap/GBpc-EUC-UCS2C
> gs/Resource/CMap/HK-RKSJ-H
> gs/Resource/CMap/Hojo-EUC-H
> gs/Resource/CMap/Hojo-EUC-V
> gs/Resource/CMap/Hojo-H
> gs/Resource/CMap/Hojo-RKSJ-H
> gs/Resource/CMap/Hojo-V
> gs/Resource/CMap/Identity-UTF16-H
> gs/Resource/CMap/Identity-UTF16-V
> gs/Resource/CMap/KSC-RKSJ-H
> gs/Resource/CMap/KSC2-RKSJ-H
> gs/Resource/CMap/KSCms-UHC-UCS2
> gs/Resource/CMap/KSCpc-EUC-UCS2
> gs/Resource/CMap/KSCpc-EUC-UCS2C
> gs/Resource/CMap/TCVN-RKSJ-H
> gs/Resource/CMap/UCS2-90ms-RKSJ
> gs/Resource/CMap/UCS2-90pv-RKSJ
> gs/Resource/CMap/UCS2-B5pc
> gs/Resource/CMap/UCS2-ETen-B5
> gs/Resource/CMap/UCS2-GBK-EUC
> gs/Resource/CMap/UCS2-GBpc-EUC
> gs/Resource/CMap/UCS2-KSCms-UHC
> gs/Resource/CMap/UCS2-KSCpc-EUC
> gs/Resource/CMap/UniCNS-UTF16-H
> gs/Resource/CMap/UniCNS-UTF32-H
> gs/Resource/CMap/UniCNS-UTF8-H
> gs/Resource/CMap/UniGB-UTF16-H
> gs/Resource/CMap/UniGB-UTF32-H
> gs/Resource/CMap/UniGB-UTF8-H
> gs/Resource/CMap/UniHojo-UCS2-H
> gs/Resource/CMap/UniHojo-UCS2-V
> gs/Resource/CMap/UniHojo-UTF16-H
> gs/Resource/CMap/UniHojo-UTF16-V
> gs/Resource/CMap/UniHojo-UTF32-H
> gs/Resource/CMap/UniHojo-UTF32-V
> gs/Resource/CMap/UniHojo-UTF8-H
> gs/Resource/CMap/UniHojo-UTF8-V
> gs/Resource/CMap/UniJIS-UTF16-H
> gs/Resource/CMap/UniJIS-UTF32-H
> gs/Resource/CMap/UniJIS-UTF8-H
> gs/Resource/CMap/UniJIS2004-UTF16-H
> gs/Resource/CMap/UniJIS2004-UTF32-H
> gs/Resource/CMap/UniJIS2004-UTF8-H
> gs/Resource/CMap/UniJISX0213-UTF32-H
> gs/Resource/CMap/UniJISX02132004-UTF32-H
> gs/Resource/CMap/UniKS-UTF16-H
> gs/Resource/CMap/UniKS-UTF32-H
> gs/Resource/CMap/UniKS-UTF8-H

2011-07-26 15:56:48 -0600
Henry Stiles <henry.stiles@artifex.com>
9adac36488e3a7dd6ed92b80dfcfb1b2866ef50b

> Fix broken build - make requires tab separators, not spaces.
> gs/base/devs.mak

2011-07-25 16:29:28 +0100
Robin Watts <Robin.Watts@artifex.com>
0eaf43f99eaeadda5118335ec1feb26db1733aed

> Further updates to mkromfs ps compaction.
> Refactor the postscript compaction routines into a state machine.
> Add options to compact using binary postscript encodings, currently
> disabled until we drop language level 1 from the interpreter.
> Further refactor it to allow it to work from a generic file-like
> interface, rather than a file. This enables us to use it on the
> merged file (which is held in memory, not on disc) too.
> With binary encoding enabled we get the rom down to 6.8Meg. Without
> that we get 7.1Meg. Without any compaction, 7.8Meg.
> No cluster differences expected.
> gs/base/mkromfs.c

2011-07-26 20:21:29 +0100
Ken Sharp <ken.sharp@artifex.com>
7d2d1f22ddf751fe2d6e3f9c5821fbc30a102a6a

> Include only one copy of hte Adbove Glyph List
> ps2write and text write both need copies of the Adobe Glyph List, we were
> holding one copy each, this commit makes them use the same information, saving space.
> Also resolves Bug #688709 "Updated Adobe Glyph List"
> No differences expected.
> gs/base/devs.mak
> gs/base/gdevagl.c
> gs/base/gdevagl.h
> gs/base/gdevpdfu.c
> gs/base/gdevtxtw.c
> gs/base/gs_agl.h

2011-07-25 09:05:44 -0700
Ray Johnston <ray.johnston@artifex.com>
cb048fc7c5fdfe82550b8f0a80de2ff5fd64739f

> Fix freeing of monitor and semaphores for ICC cache. Bug 692372, customer 580.
> Rather than gs_free_object, monitors and semaphores should be freed with the functions
> which clean up and OS interface parts, gx_monitor_free and gx_semaphore_free. By not
> doing this we were leaving handles in use on Windows.
> gs/base/gsicc_cache.c

2011-07-26 12:16:04 -0700
Michael Vrhel <michael.vrhel@artifex.com>
0644acdc8866c32e16df09fae182efa3cddb23d5

> Change of Default CMYK profile to one created by us to emulate V2 SWOP with reduced footprint.
> Reviewed differences from this commit. With bmpcmp -16 the diffs amounted to halftone differences
> with nothing visible.
> gs/iccprofiles/default_cmyk.icc

2011-07-23 00:46:01 +0100
Robin Watts <Robin.Watts@artifex.com>
6039e0750306e2c3442b03c9ed5f7afee33a5540

> mkromfs improvements, plus associated makefile changes.
> Enable Rays code to flatten the gs startup postscript files into one.
> The code failed if the line length was too short, and could corrupt
> data when splitting over 2 blocks. Both fixed.
> Also add -C and -B options to allow us to compact other postscript
> files (without flattening). Very simple operation, but seems effective.
> Saves 640k on rom size after compression.
> Cluster testing shows 6 changes to the halftoning on cups files.
> Impossible to tell if they are progressions or regressions, but
> seems unlikely to be caused by this.
> gs/base/mkromfs.c
> gs/psi/psromfs.mak

2011-07-26 14:49:26 +0100
Chris Liddell <chris.liddell@artifex.com>
5e687126be8f4b7bc870fc58530f9343392670b5

> Bug 691699: user specified cups install paths.
> Not quite as the bug describes, but we now implement --with-cups-serverbin,
> --with-cups-serverroot and --with-cups-datadir to allow the user to
> override the paths normally read from the cups-config utility.
> No cluster differences.
> gs/base/configure.ac

2011-07-26 13:15:44 +0100
Chris Liddell <chris.liddell@artifex.com>
1094db4129bb70f9f7a0222683bc7f299cf4629a

> Bug 691956: make installing the cups tools optional
> Introduces a --with-cups-install option to configure. To include the
> cups tools and associated data files in Ghostscript's "install" target
> you will have to specify "--with-cups-install" at configure time.
> No cluster differences.
> gs/base/Makefile.in
> gs/base/configure.ac
> gs/cups/cups.mak

2011-07-25 22:42:34 -0700
Michael Vrhel <michael.vrhel@artifex.com>
eaec68d05c8d223cb97d89b6a3a9a96e550feeb2

> Change of default_rgb.icc to our own sRGB ICC profile.
> This results in very minor color diffs in a few files. I reviewed the diffs and everything is fine.
> gs/iccprofiles/default_rgb.icc
> gs/iccprofiles/srgb.icc

2011-07-25 19:03:42 -0600
Henry Stiles <henry.stiles@artifex.com>
7ddcbdfbded0bae41818eeed4470686c911f2bc7

> Fixes 692360 - the x11cmyk get bits procedure would only work properly
> with a client supplied data pointer.
> gs/base/gdevxalt.c

2011-07-25 12:34:59 -0600
Henry Stiles <henry.stiles@artifex.com>
b9ff4a970e22194ecc894fe2460b88bc01726067

> Fixes 689502 - remove obsolete scripts.
> CLUSTER_UNTESTED
> gs/lib/bdftops
> gs/lib/bdftops.bat
> gs/lib/bdftops.cmd
> gs/lib/bdftops.ps
> gs/lib/fixmswrd.pl
> gs/lib/pv.sh

2011-08-05 09:02:28 -0600
Henry Stiles <henry.stiles@artifex.com>
91954fa8aadd8f7168a4bfa5e219c5c73a5e7477

> 9.04 NEWS file.
> NEWS

2011-08-05 12:07:10 +0100
Chris Liddell <chris.liddell@artifex.com>
24dd98a5274a3c43bb2b8d09ad3a29faa77e2aa8

> Ensure Win UNICODE/UTF8 code is disabled for ls build
> CLUSTER_UNTESTED
> language_switch/pspcl6_msvc.mak

2011-08-05 12:05:23 +0100
Chris Liddell <chris.liddell@artifex.com>
fac99700ffb230eaa4563dafd5af07033e5c608e

> Remove a now spurious debug message.
> CLUSTER_UNTESTED
> gs/cups/gdevcups.c

2011-08-05 09:47:19 +0100
Chris Liddell <chris.liddell@artifex.com>
ba7dbfdcaf930889e8f278629d646685ccf69405

> Prep the 9.04 release.
> Remove the "RELEASE CANDIDATE" string, bring the changelog up to date since
> the RC, and revise the date.
> CLUSTER_UNTESTED
> gs/base/gscdef.c
> gs/base/version.mak
> gs/doc/API.htm
> gs/doc/C-style.htm
> gs/doc/Commprod.htm
> gs/doc/DLL.htm
> gs/doc/Deprecated.htm
> gs/doc/Details8.htm
> gs/doc/Details9.htm
> gs/doc/Develop.htm
> gs/doc/Devices.htm
> gs/doc/Drivers.htm
> gs/doc/Fonts.htm
> gs/doc/Helpers.htm
> gs/doc/History1.htm
> gs/doc/History2.htm
> gs/doc/History3.htm
> gs/doc/History4.htm
> gs/doc/History5.htm
> gs/doc/History6.htm
> gs/doc/History7.htm
> gs/doc/History8.htm
> gs/doc/History9.htm
> gs/doc/Install.htm
> gs/doc/Issues.htm
> gs/doc/Language.htm
> gs/doc/Lib.htm
> gs/doc/Make.htm
> gs/doc/News.htm
> gs/doc/Projects.htm
> gs/doc/Ps-style.htm
> gs/doc/Ps2epsi.htm
> gs/doc/Ps2pdf.htm
> gs/doc/Ps2ps2.htm
> gs/doc/Psfiles.htm
> gs/doc/Readme.htm
> gs/doc/Release.htm
> gs/doc/Source.htm
> gs/doc/Unix-lpr.htm
> gs/doc/Use.htm
> gs/doc/Xfonts.htm
> gs/doc/gs-vms.hlp
> gs/man/dvipdf.1
> gs/man/font2c.1
> gs/man/gs.1
> gs/man/gslp.1
> gs/man/gsnd.1
> gs/man/pdf2dsc.1
> gs/man/pdf2ps.1
> gs/man/pdfopt.1
> gs/man/pf2afm.1
> gs/man/pfbtopfa.1
> gs/man/printafm.1
> gs/man/ps2ascii.1
> gs/man/ps2epsi.1
> gs/man/ps2pdf.1
> gs/man/ps2pdfwr.1
> gs/man/ps2ps.1
> gs/man/wftopfa.1

2011-08-04 14:40:12 +0100
Chris Liddell <chris.liddell@artifex.com>
e173d22697b5489624783a805311337d053e53fe

> Bug 691586: again, ensure that GS knows when cups changes the media size
> Move the fix for Bug 692393 to immediately after the call to
> gdev_prn_put_params() - before the call to gx_device_set_media_size()
> as that can also change the device's width and height settings.
> With this fix, I have also removed the temporary workaround put in place
> with commits 16c410fc29575abffb60926949433653186915fd and
> bd33c8f57b1a6e3d365ef0efd8dd7571a14310fa.
> No cluster differences.
> gs/cups/gdevcups.c

2011-08-04 10:05:13 +0100
Chris Liddell <chris.liddell@artifex.com>
6fc00870dd9d1e17709b532f425578b229a61544

> Revise Luratech section of build docs.......
> ... to reflect that we now look for the Luratech code under
> gs/luratech/ldf_jb2 and gs/luratech/lwf_jp2 instead of gs/lwf_jp2 and
> gs/ldf_jb2
> CLUSTER_UNTESTED
> gs/doc/Make.htm

2011-08-03 17:44:55 +0100
Chris Liddell <chris.liddell@artifex.com>
a26ed9754118ab5a6027346f2e4d0c41077dfc1c

> Bug 692393: ensure GS realises cups changed the page dimensions.
> After having done media selection from the cups media list, we need to
> ensure that GS realises that page dimensions in the device structure
> may have changed since the raster memory was last created - this ensures
> that GS will reallocate the memory, and correctly setup the
> line_ptrs array for the new page size.
> No cluster differences.
> gs/cups/gdevcups.c

2011-08-01 16:28:52 +0200
Till Kamppeter <till.kamppeter@gmail.com>
e6f2128efc15316a586813ff314bc037b1d36856

> Fixes on the gstoraster CUPS filter
> 1. gstoraster crashes when run outside CUPS (bug #692384)
> 2. All error messages issued by gstoraster are without newline (bug #692385)
> Thanks to Tim Waugh from Red Hat for the patches.
> gs/cups/colord.c
> gs/cups/gstoraster.c

2011-07-30 17:48:14 +0100
Robin Watts <Robin.Watts@artifex.com>
9fcefea7e6e770efed7a237c3fc0e8649fba342a

> Fix bug 692349: UNICODE build of gs not available with VS2003 or VS6.
> Apply a slightly tweaked version of alexchers patch to define wmemset
> when it's not provided by the headers.
> No cluster differences expected.
> gs/psi/dwtext.c
> gs/psi/msvc.mak

2011-08-01 12:18:25 +0100
Robin Watts <Robin.Watts@artifex.com>
690a9464f7a7ff524519587b95ba8505b0f823d9

> Tweak to tkampeters previous commit to workaround bug 691586.
> Avoid warnings given on some platforms about "unreachable code" by
> using an informative #define.
> No cluster differences expected.
> gs/cups/gdevcups.c

2011-08-01 13:05:09 +0200
Till Kamppeter <till.kamppeter@gmail.com>
b4c67383d9e71b468b5384b7a63095864d3a9ae7

> CUPS Raster output device: Ignore RIP_MAX_CACHE environment variable
> Ghostscript is (at least currently) not able to work with hard-limited
> space parameters. It crashes with a segmentation fault on many input
> files then. Leaving the setting of these parameters fully automatic
> Ghostscript works just fine. As in most distributions (Currently all
> except Debian, Ubuntu, and their derivatives) CUPS imposes a hard
> limit via the RIP_MAX_CACHE environment variable, the only way to
> assure reliable working of Ghostscript is to ignore the parameter,
> leaving the space parameters in automatic mode. For CUPS this should
> be no regression, as print queues with other Ghostscript drivers (like
> pxlcolor, ljet4, ...) worked without hard limits all the time and no
> one complained.
> To ignore this RIP_MAX_CACHE we simply add a "return" right at the
> beginning of this function. It will be removed when a real fix gets
> into place.
> See http://bugs.ghostscript.com/show_bug.cgi?id=691586
> gs/cups/gdevcups.c

2011-07-30 11:56:53 +0200
Till Kamppeter <till.kamppeter@gmail.com>
83abb6ca67829a1273ed4fdfc894a6af44c5c5ad

> Added "-dNOINTERPOLATE" to the Ghostscript command lines of the CUPS filters
> This makes rendering significantly faster and the output of normal
> files comming as print jobs from applications does not show any
> visible difference.
> gs/cups/gstoraster.c
> gs/cups/pstopxl.in

2011-07-29 14:01:58 -0700
Michael Vrhel <michael.vrhel@artifex.com>
83c7aba31ab324d015a39ec23ab9eb861c23d787

> Another fix for cups RGBW. This gets the color set up properly for RGB.
> gs/base/gsicc_manage.c
> gs/base/gsicc_manage.h
> gs/cups/gdevcups.c

2011-07-29 12:18:04 -0700
Michael Vrhel <michael.vrhel@artifex.com>
db4b6b6d07c2b4a97bd0add6e3169874ec2d1af7

> Fix for cups RGBW color space so that transparency works properly.
> gs/cups/gdevcups.c

2011-07-29 08:14:04 -0700
Michael Vrhel <michael.vrhel@artifex.com>
d1d700d4d052e3a9a061e5d6c61e3a4a30e5135d

> A test for fixing RGBW in gdevcups.c
> gs/cups/gdevcups.c

2011-07-29 10:12:26 +0100
Chris Liddell <chris.liddell@artifex.com>
43f6fff7185f868104f6ba4afc102af4f9fe8f3f

> Update the docs, version numbers, and dates for 9.04 rc1
> gs/base/gscdef.c
> gs/base/version.mak
> gs/doc/API.htm
> gs/doc/C-style.htm
> gs/doc/Commprod.htm
> gs/doc/DLL.htm
> gs/doc/Deprecated.htm
> gs/doc/Details8.htm
> gs/doc/Details9.htm
> gs/doc/Develop.htm
> gs/doc/Devices.htm
> gs/doc/Drivers.htm
> gs/doc/Fonts.htm
> gs/doc/Helpers.htm
> gs/doc/History1.htm
> gs/doc/History2.htm
> gs/doc/History3.htm
> gs/doc/History4.htm
> gs/doc/History5.htm
> gs/doc/History6.htm
> gs/doc/History7.htm
> gs/doc/History8.htm
> gs/doc/History9.htm
> gs/doc/Install.htm
> gs/doc/Issues.htm
> gs/doc/Language.htm
> gs/doc/Lib.htm
> gs/doc/Make.htm
> gs/doc/News.htm
> gs/doc/Projects.htm
> gs/doc/Ps-style.htm
> gs/doc/Ps2epsi.htm
> gs/doc/Ps2pdf.htm
> gs/doc/Ps2ps2.htm
> gs/doc/Psfiles.htm
> gs/doc/Readme.htm
> gs/doc/Release.htm
> gs/doc/Source.htm
> gs/doc/Unix-lpr.htm
> gs/doc/Use.htm
> gs/doc/Xfonts.htm
> gs/doc/gs-vms.hlp
> gs/man/dvipdf.1
> gs/man/font2c.1
> gs/man/gs.1
> gs/man/gslp.1
> gs/man/gsnd.1
> gs/man/pdf2dsc.1
> gs/man/pdf2ps.1
> gs/man/pdfopt.1
> gs/man/pf2afm.1
> gs/man/pfbtopfa.1
> gs/man/printafm.1
> gs/man/ps2ascii.1
> gs/man/ps2epsi.1
> gs/man/ps2pdf.1
> gs/man/ps2pdfwr.1
> gs/man/ps2ps.1
> gs/man/wftopfa.1
> pl/pl.mak

2011-07-29 09:40:34 +0100
Chris Liddell <chris.liddell@artifex.com>
d248b98753421668ca683d074709a9422267b9ba

> Change the expected directory for luratech.
> For the build system to automatically include the luratech JPX and JBIG2
> code, we previously checked for the existence of lwf_jp2 and ldf_jb2
> directories under the Ghostscript source dir. This changes it to check
> for <gs>/luratech/lwf_jp2 and <gs>/luratech/ldf_jb2 instead.
> CLUSTER_UNTESTED
> gs/base/configure.ac
> gs/psi/msvc.mak

2011-07-28 22:28:37 -0600
Henry Stiles <henry.stiles@artifex.com>
ea57ffb4eb8e3c2bd9ae80547cd7ad011631e212

> Restore X11 device to the default unix device.
> In setting up autoconf to detect X11 (9b7298f) the X11 devices were
> not put back at the beginning of the device list and so were no longer
> the default device.
> main/pcl6_gcc.mak

2011-07-28 17:16:35 +0100
Robin Watts <Robin.Watts@artifex.com>
c1cfbc2655dce2a1c3cc73caf0af54a51db61bfe

> Changes to lcms v1 to spot failed allocations.
> lcms v1 sometimes forgets to deal with failed allocations. Patch at
> least some of these problems.
> Driven by bug 692352. Sufficient to make it run to completion now.
> gs/lcms/src/cmsgmt.c
> gs/lcms/src/cmslut.c
> gs/lcms/src/cmsps2.c
> gs/lcms/src/cmssamp.c
> gs/lcms/src/cmsvirt.c
> gs/lcms/src/cmswtpnt.c
> gs/lcms/src/cmsxform.c

2011-07-28 17:08:58 +0100
Robin Watts <Robin.Watts@artifex.com>
0f6629c581fb56ca33fb7ec57d757ea96f236887

> Check for failure to allocate icclink in shading.
> When calling shade_init_fill_state, check for a return code to indicate
> failure. Trigger this case when an attempt to allocate an icclink
> fails.
> No cluster differences expected.
> gs/base/gxshade.c
> gs/base/gxshade.h
> gs/base/gxshade1.c
> gs/base/gxshade4.c

2011-07-28 15:07:14 +0100
Robin Watts <Robin.Watts@artifex.com>
f31edd69e23236fbae4b986883df8e0f43f15af6

> Fix typo in rc_decrement description string.
> Simple typo fix. CLUSTER_UNTESTED.
> gs/base/gxclrast.c

2011-07-28 10:21:31 +0100
Chris Liddell <chris.liddell@artifex.com>
2364173a3ea2ac1e58b53a68e775d98157035b03

> Disable the Windows UNICODE/UTF8 code for now.
> CLUSTER_UNTESTED
> gs/psi/msvc.mak

2011-07-27 22:12:41 -0700
Michael Vrhel <michael.vrhel@artifex.com>
cf056ad9ccf42b8c31e6c84ed0ee6d30e0fb7455

> Update of Use.htm to include new color control options.
> gs/doc/Use.htm

2011-07-27 16:25:19 +0100
Robin Watts <Robin.Watts@artifex.com>
12faa934ff19d95f08fc9db33d7a6b288ba67ee2

> Fix Bug 692368; SEGV with clist transparency pattern in clist rendering.
> The invocation/file given in the bug uses banded rendering (clist).
> While drawing a band, it uses a pattern with transparency, that is
> itself rendered by a clist (using the new pattern clist code).
> A fill rectangle is being done that tries to call the pattern clist
> tiling code without the fill_trans_buffer having been setup, and
> this causes a SEGV.
> The reason for this appears to be that the device used by the
> banded isn't a pdf14 device - instead it's a clipper device wrapping
> the pdf14 device. The clipper device does not call gx_forward_fill_path,
> but instead calls gx_default_fill_path, meaning that the special
> pdf14 handling done to setup the fill_trans_buffer isn't done.
> Making the commit call onwards to gx_forward_fill_path doesn't solve the
> problem either, as that results in no actual clipping being done.
> The fix, therefore appears to be to implement a clipping version of
> fill_path.
> No cluster differences expected.
> gs/base/gdevp14.c
> gs/base/gxclip.c
> gs/base/gxclip.h

2011-07-27 22:14:10 +0200
Till Kamppeter <till.kamppeter@gmail.com>
3639f0da216f0472658b37ee96726b80abdc7d56

> Fixed the problem that PCL-XL output files got huge after introduction of color management
> The pxlmono and pxlcolor output devices produce PCL XL (PCL 6). With
> the introduction of color management, the size of the output files
> often got 10 times larger as before and so PCL XL jobs often did not
> print as they exhausted the memory of the printer.
> According to the contributor of this patch, Shailesh Mistry, the PDFs
> leading to that problem have a DeviceRGB image which is translated
> into an ICC profile and passed up but the pcl/pxl can not handle
> it. This patch looks for incoming ICC profiles and resolves it into
> the base colour which can be handled at this level.
> The patch returns the size of the PCL XL output files to the old
> values from Ghostscript 8.x.
> Fixes bug 692329.
> gs/base/gdevpx.c

2011-07-27 20:37:20 +0200
Till Kamppeter <till.kamppeter@gmail.com>
d6e940a92e47f0110438cf2f9bd6ebffa2f9e211

> Fixes on the "pstopxl" CUPS filter
> 1. Use POSIX and not Perl regular expressions with sed. This makes the
> script working on a wider scope of systems (Bug #692328).
> 2. Switch the Ghostscript output device "pxlmono" if the "pxlcolor" is
> used but "Gray" chosen as "ColorModel" setting. Monochrome
> "BitsPerPixel" settings do not work with "pxlcolor".
> gs/cups/pstopxl.in

2011-07-27 10:41:14 -0700
Michael Vrhel <michael.vrhel@artifex.com>
fead331855bddda90406d220e84fe5a284b2daa9

> Fix for Windows Display Device showing gray only
> This returns the use of DeviceGrayToK=true/false to set
> if the user wants DeviceGray to map to K only for a
> CMYK device. Also, this fixes a problem where high
> level gray scale images were always going to composite
> an not K only. Bug 692204.
> gs/base/gsdparam.c
> gs/base/gsicc_manage.c
> gs/base/gxclrast.c
> gs/psi/zdevice.c

2011-07-27 09:14:04 -0700
Michael Vrhel <michael.vrhel@artifex.com>
dc18980047abde427405973a6c9452959fb8e93c

> Replacement of default gray ICC profile with Artifex generated versions
> I reviewed the bmpcmp results and the relatively few diffs are minor.
> gs/iccprofiles/default_gray.icc
> gs/iccprofiles/sgray.icc

2011-07-26 12:16:04 -0700
Michael Vrhel <michael.vrhel@artifex.com>
cdbc852a9220c324b9094c448e29ce3548a5b8c3

> Change of Default CMYK profile to one created by us to emulate V2 SWOP with reduced footprint.
> Reviewed differences from this commit. With bmpcmp -16 the diffs amounted to halftone differences
> with nothing visible.
> gs/iccprofiles/default_cmyk.icc

2011-07-25 22:42:34 -0700
Michael Vrhel <michael.vrhel@artifex.com>
dca23749d5222c591927e78fd4f79a8d649ecd7c

> Change of default_rgb.icc to our own sRGB ICC profile.
> This results in very minor color diffs in a few files. I reviewed the diffs and everything is fine.
> gs/iccprofiles/default_rgb.icc
> gs/iccprofiles/srgb.icc

2011-07-25 19:03:42 -0600
Henry Stiles <henry.stiles@artifex.com>
ba7054ed86bdb26c1c19aad0d5a4313e8b96c4df

> Fixes 692360 - the x11cmyk get bits procedure would only work properly
> with a client supplied data pointer.
> gs/base/gdevxalt.c

2011-07-25 12:34:59 -0600
Henry Stiles <henry.stiles@artifex.com>
2ed6a01d99cc63f9953be1e29b9d05643e9ada73

> Fixes 689502 - remove obsolete scripts.
> CLUSTER_UNTESTED
> gs/lib/bdftops
> gs/lib/bdftops.bat
> gs/lib/bdftops.cmd
> gs/lib/bdftops.ps
> gs/lib/fixmswrd.pl
> gs/lib/pv.sh

2011-07-26 13:15:44 +0100
Chris Liddell <chris.liddell@artifex.com>
7ec7b1463507ba578e123dc15f4219472a09930f

> Bug 691956: make installing the cups tools optional
> Introduces a --with-cups-install option to configure. To include the
> cups tools and associated data files in Ghostscript's "install" target
> you will have to specify "--with-cups-install" at configure time.
> No cluster differences.
> gs/base/Makefile.in
> gs/base/configure.ac
> gs/cups/cups.mak

## Version 9.04 (2011-08-05)

This is the fourth full release in the stable 9.x series.

This release includes fixes and solutions for a number of serious problems from the earlier 9.x releases and so we strongly encourage those using earlier 9.x releases to upgrade to this new version, to reap the benefits of those fixes.

In addition, those still using Ghostscript 8.71 and earlier should begin migration to 9.x soon since many improvements, features and fixes from the 9.x versions are impractical to back-port to these legacy versions.

Highlights in this release include:

- Transition source base to git source control - not a big deal for most users, but an important change for those who develop Ghostscript and GhostPDL.
- This release introduces flexibility for controlling color based upon the graphic object type. In particular, it is now possible to specify unique output ICC profiles and rendering intents for vector graphic, image and text portions of a document. It is also possible to override source color specifications and use specified ICC profiles and rendering intents for RGB and CMYK vector graphics, images and text portions of a document. Finally, DeviceGray source colors can now easily be specified to map either to K only or composite CMYK when the output device supports CMYK colorants.
- New tiffscaled8 and tiffscaled24 devices. Add new tiffscaled8 and tiffscaled24 devices, copied and modified from tiffscaled. These output grayscale and 24bit rgb instead of tiffscaleds mono output. MinFeatureSize is ignored for these devices as it's meaningless for contone output. Downscaling is also now supported for png16m and pnggray, and a new pngmonod device has been implemented which uses grayscale rendering internally and then downscales/min_feature_sizes/error diffuses to monochrome.
- The PDF interpreter will now try to continue interpreting a PDF after encountering an error in a stream. The previous bevahior can be reinstated by passing -dPDFSTOPONERROR to Ghostscript.
- Re-enable x11alpha as the default device on Unix systems, now that compatibility problems between anti-aliased output and transparency are resolved.
- Update libjpeg to version 8c.
- Experimental Text output/extraction device

  The txtwrite device has undergone some development, and now has genuine functionality. It accepts any input format which GhostPDL supports, and uses a combination of methods to try and determine the Unicode values for any text contained in the document.

  The code descends a hierarchy of methods in this process, starting with the most reliable and only falling back to less reliable methods when better methods fail. The current hierarchy is as follows:

  1. ToUnicode CMaps (PostScript or PDF) or GlyphNamesToUnicode tables (PostScript).
  2. Glyph names of the form 'unixxxx'.
  3. Glyph names defined in the Adobe Glyph List document.
  4. Input character code.

  Method 1 is highly reliable, method 4 is a best guess and not terribly reliable, though it will work for many files. It is probably most reliable for PostScript and PCL files.

  The device currently has one parameter 'TextFormat' which controls whether the output is Unicode text reflecting the layout of the original document (-dTextFormat=0) or a format intended for use by developers which includes the Unicode text and some formatting information, such as the size and position of the text, and the font in use (-dTextFormat=1).

  Note that his device does not do OCR (Optical Character Recognition) it is not capable of finding 'text' which is part of an image. However it will recover the 'invisible' text from PDF documents which have been scanned and OCR'ed by Acrobat for searching. Such text has a render mode of 3.

  This is the first release of this code and is very much an alpha release, we expect problems.

  In particular the TextFormat=0 output is likely to be incorrect, and will only work with top-to-bottom left-to-right text. It will probably also be confused by landscape documents printed on portrait media.

  TextFormat=1 should be more reliable, but there may be cases where text is dropped from the output. Text in PostScript documents using charpath is not yet supported for example.

  We do encourage feedback on the state of this device, and would be interested in hearing what kind of output would be useful for developers using TextFormat=1. For now, however, please do not raise bugs through Bugzilla, instead please send feedback to the gs-devel mailing list.

- Experimental Unicode/UTF8 Support on Windows

  This release introduces some experimental build-time optional support for UNICODE pathnames on Windows. Essentially this works by following the model that Linux (and MacOS) have followed for years.

  If this code is enabled, then the way ghostscript handles command lines, registry settings, file accesses and other api calls with top bit set characters in (i.e. codes >= 128) will change. The net benefit of this change is that ghostscript will now be able to cope with accessing files with unicode characters (i.e. codes >= 256) in their pathnames.

  This behavior is all completely transparent to users, with the exception of those calling the gsapi functions with strings including 'extended ascii' (i.e. characters with codes >= 128 and <= 255). These characters include accented latin characters, such as u + umlaut, a + grave etc. The changes required for code that is affected by this are relatively minor, but as this is a change to the current API, we are announcing it in advance, and inviting comments.

  As of the 9.04 release, the code is disabled. For those who wish to experiment you will need to build Ghostscript from source, and either pass USEUNICODE=1 when you invoke nmake or edit psi/msvc.mak to remove the /DWINDOWS_NO_UNICODE option from CFLAGS.

  WARNING: Our intention, subject to feedback, is to enable this by default in near-future releases (hopefully, the next major release). If you make use of the affected APIs you should be prepared for the change to occur - be aware, however, that the current code is experimental and, depending on the feedback we get, maybe subject to change.

  NOTE: this whole change refers to file paths, command line parameters and so on - it does not imply that we have unilaterally extended Postscript to understand UNICODE.

  More details:

  To give an example, suppose we have a file 'EXAMPLE' we'd like to invoke ghostscript on, where 'EXAMPLE' is actually a string that contains some characters with codes >= 128.

  On Linux (or MacOS X), when ghostscript is called from a shell, e.g.

  gs EXAMPLE

  the command is UTF8 encoded; this means that characters with codes < 128 are left unchanged, and characters >= 128 are encoded into multiple bytes. This encoded string is then passed to the standard 'main' entrypoint in the gs executable.

  Ghostscript proceeds internally without any special handling of these multibyte characters at all. When it comes to access files it therefore passes out the UTF8 encoded strings to the standard OS file handling routines. These routines are designed to take pathnames in UTF8 format, and thus the files are accessed as normal.

  If the Ghostscript executable outputs these (or other) strings to its stdout, the shell again converts the output from UTF8 back to unicode in order to display it.

  The net effect is that the caller can seamlessly pass in unicode filenames, has his fileaccesses work out and gets unicode output without the core of ghostscript ever having to worry about it.

  The code change discussed here endeavours to make Windows follow the same pattern as closely as possible.

  When Windows executables are invoked, they can either be called through an 'ascii' entrypoint (main), or through a unicode ('wide') entrypoint (wmain). The difference is invisible to the caller, except that unicode executables can accept characters >= 256 in their invocations.

  The new code changes ghostscript from being an ascii executable to being a unicode one. The Windows specific outer layer takes the unicode command string and UTF8 encodes it before passing it to the ghostscript core.

  Similarly, the Windows specific filing system calls are updated to accept utf8 encoded strings from the core, and to convert them to unicode before operating on them.

  The Windows gui app (gswin32.exe, NOT gswin32c.exe) is also updated to convert stdin/stdout between unicode and utf8 as appropriate, allowing unicode strings to be copied/pasted to/from other apps.

  All of this should be completely transparent to the user, and no code changes should be required. The one area where changes may be required are where ghostscript is invoked through the gsapi functions.

  Currently, on Linux (and MacOS X) any strings sent over the gsapi are assumed to be utf8 encoded (and thus can represent any Unicode character). On Windows, they are assumed simply to be in extended ASCII (and can therefore represent any character < 256 in the current codepage). With the proposed change, Windows will move to be in step with Linux. No differences will be caused to anyone who only uses chars <= 128, but those people using character codes between 128 and 256 (or indeed wanting to use higher codes) will need to utf8 encode the strings before calling gsapi functions.

  Such encoding/decoding is a very simple process, and code for both directions can be found in psi/dwmain.c, psi/dwmainc.c and psi/dwtext.c.

  Again, we welcome feedback on this feature, in this case problems or suggestions about the implementation can be submitted via Bugzilla but for detailed discussion about the approach for which we opted, it would be more beneficial discuss it (preferably) on our IRC channel #ghostscript on freenode.net, or on the gs-devel mailing list.

For a list of open issues, or to report problems, please visit bugs.ghostscript.com.

### Incompatible changes

Deprecated file "gs/base/errors.h" removed, psi/ierrors.h should be used instead.

The eXternal Fonts (XFonts) functionality, marked as deprecated in 9.02 has now been fully removed.

No other recorded incompatible changes.

### Changelog

2011-08-04 14:40:12 +0100
Chris Liddell <chris.liddell@artifex.com>
e173d22697b5489624783a805311337d053e53fe

> Bug 691586: again, ensure that GS knows when cups changes the media size
> Move the fix for Bug 692393 to immediately after the call to
> gdev_prn_put_params() - before the call to gx_device_set_media_size()
> as that can also change the device's width and height settings.
> With this fix, I have also removed the temporary workaround put in place
> with commits 16c410fc29575abffb60926949433653186915fd and
> bd33c8f57b1a6e3d365ef0efd8dd7571a14310fa.
> No cluster differences.
> gs/cups/gdevcups.c

2011-08-04 10:05:13 +0100
Chris Liddell <chris.liddell@artifex.com>
6fc00870dd9d1e17709b532f425578b229a61544

> Revise Luratech section of build docs.......
> ... to reflect that we now look for the Luratech code under
> gs/luratech/ldf_jb2 and gs/luratech/lwf_jp2 instead of gs/lwf_jp2 and
> gs/ldf_jb2
> CLUSTER_UNTESTED
> gs/doc/Make.htm

2011-08-03 17:44:55 +0100
Chris Liddell <chris.liddell@artifex.com>
a26ed9754118ab5a6027346f2e4d0c41077dfc1c

> Bug 692393: ensure GS realises cups changed the page dimensions.
> After having done media selection from the cups media list, we need to
> ensure that GS realises that page dimensions in the device structure
> may have changed since the raster memory was last created - this ensures
> that GS will reallocate the memory, and correctly setup the
> line_ptrs array for the new page size.
> No cluster differences.
> gs/cups/gdevcups.c

2011-08-01 16:28:52 +0200
Till Kamppeter <till.kamppeter@gmail.com>
e6f2128efc15316a586813ff314bc037b1d36856

> Fixes on the gstoraster CUPS filter
> 1. gstoraster crashes when run outside CUPS (bug #692384)
> 2. All error messages issued by gstoraster are without newline (bug #692385)
> Thanks to Tim Waugh from Red Hat for the patches.
> gs/cups/colord.c
> gs/cups/gstoraster.c

2011-07-30 17:48:14 +0100
Robin Watts <Robin.Watts@artifex.com>
9fcefea7e6e770efed7a237c3fc0e8649fba342a

> Fix bug 692349: UNICODE build of gs not available with VS2003 or VS6.
> Apply a slightly tweaked version of alexchers patch to define wmemset
> when it's not provided by the headers.
> No cluster differences expected.
> gs/psi/dwtext.c
> gs/psi/msvc.mak

2011-08-01 12:18:25 +0100
Robin Watts <Robin.Watts@artifex.com>
690a9464f7a7ff524519587b95ba8505b0f823d9

> Tweak to tkampeters previous commit to workaround bug 691586.
> Avoid warnings given on some platforms about "unreachable code" by
> using an informative #define.
> No cluster differences expected.
> gs/cups/gdevcups.c

2011-08-01 13:05:09 +0200
Till Kamppeter <till.kamppeter@gmail.com>
b4c67383d9e71b468b5384b7a63095864d3a9ae7

> CUPS Raster output device: Ignore RIP_MAX_CACHE environment variable
> Ghostscript is (at least currently) not able to work with hard-limited
> space parameters. It crashes with a segmentation fault on many input
> files then. Leaving the setting of these parameters fully automatic
> Ghostscript works just fine. As in most distributions (Currently all
> except Debian, Ubuntu, and their derivatives) CUPS imposes a hard
> limit via the RIP_MAX_CACHE environment variable, the only way to
> assure reliable working of Ghostscript is to ignore the parameter,
> leaving the space parameters in automatic mode. For CUPS this should
> be no regression, as print queues with other Ghostscript drivers (like
> pxlcolor, ljet4, ...) worked without hard limits all the time and no
> one complained.
> To ignore this RIP_MAX_CACHE we simply add a "return" right at the
> beginning of this function. It will be removed when a real fix gets
> into place.
> See http://bugs.ghostscript.com/show_bug.cgi?id=691586
> gs/cups/gdevcups.c

2011-07-30 11:56:53 +0200
Till Kamppeter <till.kamppeter@gmail.com>
83abb6ca67829a1273ed4fdfc894a6af44c5c5ad

> Added "-dNOINTERPOLATE" to the Ghostscript command lines of the CUPS filters
> This makes rendering significantly faster and the output of normal
> files comming as print jobs from applications does not show any
> visible difference.
> gs/cups/gstoraster.c
> gs/cups/pstopxl.in

2011-07-29 14:01:58 -0700
Michael Vrhel <michael.vrhel@artifex.com>
83c7aba31ab324d015a39ec23ab9eb861c23d787

> Another fix for cups RGBW. This gets the color set up properly for RGB.
> gs/base/gsicc_manage.c
> gs/base/gsicc_manage.h
> gs/cups/gdevcups.c

2011-07-29 12:18:04 -0700
Michael Vrhel <michael.vrhel@artifex.com>
db4b6b6d07c2b4a97bd0add6e3169874ec2d1af7

> Fix for cups RGBW color space so that transparency works properly.
> gs/cups/gdevcups.c

2011-07-29 08:14:04 -0700
Michael Vrhel <michael.vrhel@artifex.com>
d1d700d4d052e3a9a061e5d6c61e3a4a30e5135d

> A test for fixing RGBW in gdevcups.c
> gs/cups/gdevcups.c

2011-07-29 10:12:26 +0100
Chris Liddell <chris.liddell@artifex.com>
43f6fff7185f868104f6ba4afc102af4f9fe8f3f

> Update the docs, version numbers, and dates for 9.04 rc1
> gs/base/gscdef.c
> gs/base/version.mak
> gs/doc/API.htm
> gs/doc/C-style.htm
> gs/doc/Commprod.htm
> gs/doc/DLL.htm
> gs/doc/Deprecated.htm
> gs/doc/Details8.htm
> gs/doc/Details9.htm
> gs/doc/Develop.htm
> gs/doc/Devices.htm
> gs/doc/Drivers.htm
> gs/doc/Fonts.htm
> gs/doc/Helpers.htm
> gs/doc/History1.htm
> gs/doc/History2.htm
> gs/doc/History3.htm
> gs/doc/History4.htm
> gs/doc/History5.htm
> gs/doc/History6.htm
> gs/doc/History7.htm
> gs/doc/History8.htm
> gs/doc/History9.htm
> gs/doc/Install.htm
> gs/doc/Issues.htm
> gs/doc/Language.htm
> gs/doc/Lib.htm
> gs/doc/Make.htm
> gs/doc/News.htm
> gs/doc/Projects.htm
> gs/doc/Ps-style.htm
> gs/doc/Ps2epsi.htm
> gs/doc/Ps2pdf.htm
> gs/doc/Ps2ps2.htm
> gs/doc/Psfiles.htm
> gs/doc/Readme.htm
> gs/doc/Release.htm
> gs/doc/Source.htm
> gs/doc/Unix-lpr.htm
> gs/doc/Use.htm
> gs/doc/Xfonts.htm
> gs/doc/gs-vms.hlp
> gs/man/dvipdf.1
> gs/man/font2c.1
> gs/man/gs.1
> gs/man/gslp.1
> gs/man/gsnd.1
> gs/man/pdf2dsc.1
> gs/man/pdf2ps.1
> gs/man/pdfopt.1
> gs/man/pf2afm.1
> gs/man/pfbtopfa.1
> gs/man/printafm.1
> gs/man/ps2ascii.1
> gs/man/ps2epsi.1
> gs/man/ps2pdf.1
> gs/man/ps2pdfwr.1
> gs/man/ps2ps.1
> gs/man/wftopfa.1
> pl/pl.mak

2011-07-29 09:40:34 +0100
Chris Liddell <chris.liddell@artifex.com>
d248b98753421668ca683d074709a9422267b9ba

> Change the expected directory for luratech.
> For the build system to automatically include the luratech JPX and JBIG2
> code, we previously checked for the existence of lwf_jp2 and ldf_jb2
> directories under the Ghostscript source dir. This changes it to check
> for <gs>/luratech/lwf_jp2 and <gs>/luratech/ldf_jb2 instead.
> CLUSTER_UNTESTED
> gs/base/configure.ac
> gs/psi/msvc.mak

2011-07-28 22:28:37 -0600
Henry Stiles <henry.stiles@artifex.com>
ea57ffb4eb8e3c2bd9ae80547cd7ad011631e212

> Restore X11 device to the default unix device.
> In setting up autoconf to detect X11 (9b7298f) the X11 devices were
> not put back at the beginning of the device list and so were no longer
> the default device.
> main/pcl6_gcc.mak

2011-07-28 17:16:35 +0100
Robin Watts <Robin.Watts@artifex.com>
c1cfbc2655dce2a1c3cc73caf0af54a51db61bfe

> Changes to lcms v1 to spot failed allocations.
> lcms v1 sometimes forgets to deal with failed allocations. Patch at
> least some of these problems.
> Driven by bug 692352. Sufficient to make it run to completion now.
> gs/lcms/src/cmsgmt.c
> gs/lcms/src/cmslut.c
> gs/lcms/src/cmsps2.c
> gs/lcms/src/cmssamp.c
> gs/lcms/src/cmsvirt.c
> gs/lcms/src/cmswtpnt.c
> gs/lcms/src/cmsxform.c

2011-07-28 17:08:58 +0100
Robin Watts <Robin.Watts@artifex.com>
0f6629c581fb56ca33fb7ec57d757ea96f236887

> Check for failure to allocate icclink in shading.
> When calling shade_init_fill_state, check for a return code to indicate
> failure. Trigger this case when an attempt to allocate an icclink
> fails.
> No cluster differences expected.
> gs/base/gxshade.c
> gs/base/gxshade.h
> gs/base/gxshade1.c
> gs/base/gxshade4.c

2011-07-28 15:07:14 +0100
Robin Watts <Robin.Watts@artifex.com>
f31edd69e23236fbae4b986883df8e0f43f15af6

> Fix typo in rc_decrement description string.
> Simple typo fix. CLUSTER_UNTESTED.
> gs/base/gxclrast.c

### Changelog

2011-07-28 10:21:31 +0100
Chris Liddell <chris.liddell@artifex.com>
2364173a3ea2ac1e58b53a68e775d98157035b03

> Disable the Windows UNICODE/UTF8 code for now.
> CLUSTER_UNTESTED
> gs/psi/msvc.mak

2011-07-27 22:12:41 -0700
Michael Vrhel <michael.vrhel@artifex.com>
cf056ad9ccf42b8c31e6c84ed0ee6d30e0fb7455

> Update of Use.htm to include new color control options.
> gs/doc/Use.htm

2011-07-27 16:25:19 +0100
Robin Watts <Robin.Watts@artifex.com>
12faa934ff19d95f08fc9db33d7a6b288ba67ee2

> Fix Bug 692368; SEGV with clist transparency pattern in clist rendering.
> The invocation/file given in the bug uses banded rendering (clist).
> While drawing a band, it uses a pattern with transparency, that is
> itself rendered by a clist (using the new pattern clist code).
> A fill rectangle is being done that tries to call the pattern clist
> tiling code without the fill_trans_buffer having been setup, and
> this causes a SEGV.
> The reason for this appears to be that the device used by the
> banded isn't a pdf14 device - instead it's a clipper device wrapping
> the pdf14 device. The clipper device does not call gx_forward_fill_path,
> but instead calls gx_default_fill_path, meaning that the special
> pdf14 handling done to setup the fill_trans_buffer isn't done.
> Making the commit call onwards to gx_forward_fill_path doesn't solve the
> problem either, as that results in no actual clipping being done.
> The fix, therefore appears to be to implement a clipping version of
> fill_path.
> No cluster differences expected.
> gs/base/gdevp14.c
> gs/base/gxclip.c
> gs/base/gxclip.h

2011-07-27 22:14:10 +0200
Till Kamppeter <till.kamppeter@gmail.com>
3639f0da216f0472658b37ee96726b80abdc7d56

> Fixed the problem that PCL-XL output files got huge after introduction of color management
> The pxlmono and pxlcolor output devices produce PCL XL (PCL 6). With
> the introduction of color management, the size of the output files
> often got 10 times larger as before and so PCL XL jobs often did not
> print as they exhausted the memory of the printer.
> According to the contributor of this patch, Shailesh Mistry, the PDFs
> leading to that problem have a DeviceRGB image which is translated
> into an ICC profile and passed up but the pcl/pxl can not handle
> it. This patch looks for incoming ICC profiles and resolves it into
> the base colour which can be handled at this level.
> The patch returns the size of the PCL XL output files to the old
> values from Ghostscript 8.x.
> Fixes bug 692329.
> gs/base/gdevpx.c

2011-07-27 20:37:20 +0200
Till Kamppeter <till.kamppeter@gmail.com>
d6e940a92e47f0110438cf2f9bd6ebffa2f9e211

> Fixes on the "pstopxl" CUPS filter
> 1. Use POSIX and not Perl regular expressions with sed. This makes the
> script working on a wider scope of systems (Bug #692328).
> 2. Switch the Ghostscript output device "pxlmono" if the "pxlcolor" is
> used but "Gray" chosen as "ColorModel" setting. Monochrome
> "BitsPerPixel" settings do not work with "pxlcolor".
> gs/cups/pstopxl.in

2011-07-27 10:41:14 -0700
Michael Vrhel <michael.vrhel@artifex.com>
fead331855bddda90406d220e84fe5a284b2daa9

> Fix for Windows Display Device showing gray only
> This returns the use of DeviceGrayToK=true/false to set
> if the user wants DeviceGray to map to K only for a
> CMYK device. Also, this fixes a problem where high
> level gray scale images were always going to composite
> an not K only. Bug 692204.
> gs/base/gsdparam.c
> gs/base/gsicc_manage.c
> gs/base/gxclrast.c
> gs/psi/zdevice.c

2011-07-27 09:14:04 -0700
Michael Vrhel <michael.vrhel@artifex.com>
dc18980047abde427405973a6c9452959fb8e93c

> Replacement of default gray ICC profile with Artifex generated versions
> I reviewed the bmpcmp results and the relatively few diffs are minor.
> gs/iccprofiles/default_gray.icc
> gs/iccprofiles/sgray.icc

2011-07-26 12:16:04 -0700
Michael Vrhel <michael.vrhel@artifex.com>
cdbc852a9220c324b9094c448e29ce3548a5b8c3

> Change of Default CMYK profile to one created by us to emulate V2 SWOP with reduced footprint.
> Reviewed differences from this commit. With bmpcmp -16 the diffs amounted to halftone differences
> with nothing visible.
> gs/iccprofiles/default_cmyk.icc

2011-07-25 22:42:34 -0700
Michael Vrhel <michael.vrhel@artifex.com>
dca23749d5222c591927e78fd4f79a8d649ecd7c

> Change of default_rgb.icc to our own sRGB ICC profile.
> This results in very minor color diffs in a few files. I reviewed the diffs and everything is fine.
> gs/iccprofiles/default_rgb.icc
> gs/iccprofiles/srgb.icc

2011-07-25 19:03:42 -0600
Henry Stiles <henry.stiles@artifex.com>
ba7054ed86bdb26c1c19aad0d5a4313e8b96c4df

> Fixes 692360 - the x11cmyk get bits procedure would only work properly
> with a client supplied data pointer.
> gs/base/gdevxalt.c

2011-07-25 12:34:59 -0600
Henry Stiles <henry.stiles@artifex.com>
2ed6a01d99cc63f9953be1e29b9d05643e9ada73

> Fixes 689502 - remove obsolete scripts.
> CLUSTER_UNTESTED
> gs/lib/bdftops
> gs/lib/bdftops.bat
> gs/lib/bdftops.cmd
> gs/lib/bdftops.ps
> gs/lib/fixmswrd.pl
> gs/lib/pv.sh

2011-07-26 13:15:44 +0100
Chris Liddell <chris.liddell@artifex.com>
7ec7b1463507ba578e123dc15f4219472a09930f

> Bug 691956: make installing the cups tools optional
> Introduces a --with-cups-install option to configure. To include the
> cups tools and associated data files in Ghostscript's "install" target
> you will have to specify "--with-cups-install" at configure time.
> No cluster differences.
> gs/base/Makefile.in
> gs/base/configure.ac
> gs/cups/cups.mak

2011-07-25 16:25:20 +0100
Chris Liddell <chris.liddell@artifex.com>
f62ce181e3a68d7f652d9e903c70bd1a67423782

> Bug 692367: NULL out pointers for three tables in the context
> Add "finalize" methods for gs_name_table, io_device_table and
> font_dir tables which ensure that the pointers in the lib
> context are set to NULL when the memory is released.
> No cluster differences.
> gs/base/gsfont.c
> gs/base/gsiodev.c
> gs/base/gsstruct.h
> gs/base/gxfcache.h
> gs/psi/iname.c

2011-07-25 16:19:19 +0100
Ken Sharp <ken.sharp@artifex.com>
7dee8c1639a55e5b6ae4051afcfed9caa82e48b5

> Remove the last traces of OPDFReadProcsetPath
> The old Procsets had to be moved from PostScript resources to C files, in order that
> ps2write work with non-PostScript interpreters (XPS, PCL). As a result the
> old OPDFReadProcsetPath is no longer used and has been removed.
> gs/Resource/Init/gs_pdfwr.ps
> gs/base/gdevpdf.c
> gs/base/gdevpdfb.h
> gs/base/gdevpdfp.c
> gs/base/gdevpdfu.c
> gs/base/gdevpdfx.h

2011-07-25 09:05:05 +0100
Ken Sharp <ken.sharp@artifex.com>
1562de0f7dc0615ed1397f42a7ad0eb23f4dcf22

> Add some minimal documentation regarding the txtwrite device to devices.htm.
> gs/doc/Devices.htm

2011-07-25 08:44:42 +0100
Ken Sharp <ken.sharp@artifex.com>
4e6a7b5c6fc0c202ba0d962cd19578162e1ce726

> Add functionality to the textwrite device.
> The existing textwrite device was a null device which emitted nothing. This
> version actually extracts text from input documents. It uses ToUnicode CMaps,
> GlyphNames2Unicode tables and glyph names in an attempt to map incoming text into
> Unicode (UTF-16) values.
> It currently has one switch 'TextFormat' which has two possible values, 0 or 1.
> -dTextFormat=0 outputs a 'layout' representation of the original text. This
> will attempt to produce text output which is similar in appearance to the original.
> -dTextFormat=1 simply emits all the text as it is encountered, along with information
> about the text state. It outputs the Font name, point size, rendering mode and
> writing mode (WMode) as well as the start and ending co-ordinates of the text on the page
> and the Unicode string representing the text. This is intended for those who
> would like to manipulate the text into other formats.
> The Adobe Glyph Names list is now embedded in the executable twice, in two
> incompatible forms. A future enhanvement will be to only embed the list once.
> gs/base/gdevagl.h
> gs/base/gdevtxtw.c

2011-07-24 16:03:31 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
128b9fce26e82ef38cedded8fc35a4c99ef55bee

> Fix a trivial Valgrind warning.
> Reorder a logical expression to prevent the access to an unitialized
> value. The only effect of the patch is some noise reduction in the
> Valgrind log.
> gs/base/gdevp14.c

2011-07-24 16:38:35 +0000
Robin Watts <robin@ghostscript.com>
961a9a98ecff7a30503ee0bd5d2973263114def7

> Backout commit 7f5d3d7; 8 bit display device palette change.
> Reverting earlier commit made to attempt to fix bug 692235. While
> this change does give the display device a much nicer palette
> to work with in 8 bits, it will break with all code that currently
> exists to interface to the display device, such as gsview, as the
> palette is not exported with the data.
> Due to the looming release and the questions remaining to be answered
> on the bug, we pull the change for now.
> gs/base/gdevdsp.c
> gs/psi/dpmain.c
> gs/psi/dwimg.c
> gs/psi/dxmain.c
> pl/dwimg.c

2011-07-20 23:28:19 -0700
Ray Johnston <ray.johnston@artifex.com>
68bf978d614ec610333abd6a51b88fc3e05689f7

> Fix compiler warnings.
> Check return code from "get_profile" dev_proc in gs_nulldevice.c and get rid of the
> implicit declaration for gdev_mem_set_planar.
> gs/base/gsdevice.c
> gs/base/gxpcmap.c

2011-07-22 10:36:36 -0700
Michael Vrhel <michael.vrhel@artifex.com>
d3302b1176683dc9e4cb5cb8ed9f42bffa0888ee

> Fix for bug 692204. This forces DeviceGray to K only for CMYK devices.
> This is performed by default now. To return to a composite type mapping
> that makes use of the true DeviceProfile, use the option -dDeviceGrayToK=false.
> This commit includes a fix to rename the device member variable
> icc_array to icc_struct to reduce confusion in reading the code.
> gs/Resource/Init/gs_lev2.ps
> gs/base/gdevp14.c
> gs/base/gdevpdfk.c
> gs/base/gdevtfnx.c
> gs/base/gdevtsep.c
> gs/base/gdevvec.c
> gs/base/gdevxini.c
> gs/base/gscms.h
> gs/base/gsdevice.c
> gs/base/gsdparam.c
> gs/base/gsequivc.c
> gs/base/gsicc.c
> gs/base/gsicc_cache.c
> gs/base/gsicc_cache.h
> gs/base/gsicc_manage.c
> gs/base/gsicc_manage.h
> gs/base/gslib.c
> gs/base/gxclthrd.c
> gs/base/gxcmap.c
> gs/base/gxdevcli.h
> gs/base/gximag3x.c
> gs/iccprofiles/gray_to_k.icc

2011-07-21 20:42:33 +0100
Robin Watts <Robin.Watts@artifex.com>
7f5d3d7b298bbabc13a484e38e749d572d817bc8

> Fix bug 692235: Rendering to 8bit colors shows bad colors.
> The display device uses an RGBK space for 8 bit rendering. Currently
> this corresponds to a palette of 96 colors; 2 bits each for R,G,B,
> supplemented by 16 greys.
> This review alters it to use a 6x6x6 RGB cube, supplemented by 40 grey
> levels.
> In fact, this is slightly wasteful as we repeat the black and white
> representations as color and as greyscale, but it's a huge improvement
> on what we had before.
> No cluster differences expected as we don't test the display device.
> gs/base/gdevdsp.c
> gs/psi/dpmain.c
> gs/psi/dwimg.c
> gs/psi/dxmain.c
> pl/dwimg.c

2011-07-22 23:27:18 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
4c2a089d0378402f374cb9004ac0faa3ff82d3c3

> Bug 692361, trap errors produced by --token--
> Thap errors thrown by --token--, adjust the stack, and rethrow.
> Rev. 4c6809dfa1c539d757c30f572922e05cd1436698 made the errors
> that occur during reading of the contents steam recoverable,
> but missed the case, when the error happens in the --token--.
> gs/Resource/Init/pdf_base.ps

2011-07-21 21:50:59 -0700
Michael Vrhel <michael.vrhel@artifex.com>
9d37cdcdbcb3b3bb23d0eab06d1683735303d5e1

> Fix for bug 692364 in which we were were not handing the initial DeviceGray profiles correctly
> When the graphic state is started, the color spaces are first set to DeviceGray. In certain documents
> this is then the color space that is used for drawing and in fact the erase page will initially
> occur with this color space. If I have a destination ICC profile like CIELAB, then this is
> a problem since we will end up mapping DeviceGray to RGB with the old procedures giving us a
> CIELAB value of [255 255 255] which is a very bright red. With this fix we in the
> DeviceGray mapping we fix the colorspace to be ICC based and pass then handle the procedure with
> the ICC mapping. A minor fix was also needed in the pdf14device put_image where we use a
> DeviceGray color space, which happens to have an ICC profile. We now correctly create the
> ICC profile. Note that this will cause significant diffs in the cluster push as DeviceGray
> colors that were mapped to pure K before for a CMYK device (due to the fact that we were not
> installing the proper color space) will now map to composite black. This
> issue will be addressed shortly by another commit where we by default map all DeviceGray
> colors to K only in the CMYK devices.
> gs/base/gdevp14.c
> gs/base/gxcmap.c
> gs/base/lib.mak

2011-07-21 16:40:21 +0100
Robin Watts <Robin.Watts@artifex.com>
554ce829a9eb59da437541e2efbc646d9edc2805

> Fix Bug 692355; gswin32 has garbage chars in window title bars.
> Existing ghostscript includes windows.h without defining UNICODE, but
> calls the unicode versions of functions where appropriate. Here we
> move to defining UNICODE before including windows.h, but we keep to
> the practise of calling A or W specific variants as much as possible.
> Partly this is because of time before the release, but mostly a fear
> that this might lead to a Pandoras box of changes.
> gs/psi/dwtext.c
> gs/psi/dwtext.h

2011-07-19 20:02:50 +0100
Robin Watts <Robin.Watts@artifex.com>
c9a8f8b3b0327bb62fc79cfe93d6bd79f997a2b6

> pdf14 'dirty' rect optimisations.
> Rename 'bbox' to 'dirty' - makes the purpose of the field much clearer.
> Export dirty rectangle pointer in gx_pattern_trans_t structure.
> Remove automatic expansion of 'dirty' rects to full rect boundary.
> Ensure tiling code sets dirty rectangle as expected.
> Remove debugging printfs.
> Testing shows 491 differences. 16 or so real changes (all neutral or
> progressions), but most of them in the cups device. Manual testing
> shows no changes at all - no idea what's going on there.
> gs/base/gdevp14.c
> gs/base/gdevp14.h
> gs/base/gxblend1.c
> gs/base/gxp1fill.c
> gs/base/gxpcolor.h

2011-07-20 15:24:58 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
4a1159926a8094f19bcacddf0503b5a06edd9184

> Bug 692362, tolerate stream object without stream.
> Check for the case, where the modified stream dictionary is missing
> /File attribute (probably, because the original stream object was
> missing the stream body) and substitute an empty stream.
> gs/Resource/Init/pdf_base.ps

2011-07-20 20:03:02 +0000
Robin Watts <robin@ghostscript.com>
145a853a0f9ed9d58b76413a5c77aa026500af93

> Add finalize function to pattern clist device.
> This may need to do more than it does, but the immediate drive for
> this is to correctly drop the reference count on the target device
> on closedown. This is sufficient to stop the SEGV seen on the final
> garbage collection done on stars.pdf.
> The garbage collector was finding an unfreed pdf14 device, and stepping
> into the target onto to find that the target had been destroyed already.
> No cluster differences shown in testing.
> gs/base/gxpcmap.c

2011-07-20 10:29:47 -0700
Ray Johnston <ray.johnston@artifex.com>
10cd4a92cd64252635c3c7f9a189f857bc59bf97

> Fix for missing ICCProfilesDir during some device init. Move profiledir to gs_lib_ctx.
> The business of trying to keep the profile directory in the device and keeping it in
> sync with the value used in the icc_manager led to problems when some devices were
> initialized. This change moves the profiledir (and its len) into the gs_lib_ctx_t
> (pseudo- global) which is accessible by the icc_manager and devices via the
> gs_memory_t pointer.
> Remove the no longer needed functions to set and sync the profile in the device and
> replace gsicc_set_icc_directory with gs_lib_ctx_set_icc_directory.
> Thanks to Michael Vrhel for adding to this patch to make it build on linux and
> build the other parsers.
> gs/base/gscms.h
> gs/base/gsdevice.c
> gs/base/gsdparam.c
> gs/base/gsicc_manage.c
> gs/base/gsicc_manage.h
> gs/base/gslibctx.c
> gs/base/gslibctx.h
> gs/base/lib.mak
> gs/base/msvclib.mak
> gs/psi/int.mak
> gs/psi/zdevice.c
> gs/psi/zusparam.c
> pcl/pctop.c
> psi/psitop.c
> pxl/pxpthr.c
> pxl/pxtop.c
> svg/svgtop.c
> xps/xpstop.c

2011-07-20 11:43:40 -0700
Michael Vrhel <michael.vrhel@artifex.com>
b07cfe2e168d004ed1a4365e985d90c88fa61725

> Fix for Bug 692074. Make sure the ht thresholding code writes out device white and device black.
> This should also fix a polarity issue that we had with the plank device.
> gs/base/gxht_thresh.c

2011-07-20 18:24:31 +0000
Robin Watts <robin@ghostscript.com>
9a91acb5411b457383e59ed4bbefeb0247862228

> Reverse the polarity of cups 'gray' colorspaces.
> Cups colspace 0 is the inverse of colspace 3.
> gs/toolbin/bmpcmp.c

2011-07-20 14:48:55 +0100
Chris Liddell <chris.liddell@artifex.com>
467b64692f0b74244fd0bc0748309d05b2f09294

> Remove the eXternal Fonts functionality.
> The XFonts feature was of very limited utility these days, and
> was deprecated a couple of releases ago. This commit removes
> the unloved and rather bit-rotten feature completely.
> This does not really "fix" Bug 692357, but renders it pointless.
> No cluster differences.
> gs/base/devs.mak
> gs/base/gdevmac.c
> gs/base/gdevmac.h
> gs/base/gdevmacxf.c
> gs/base/gdevx.c
> gs/base/gdevx.h
> gs/base/gdevxini.c
> gs/base/gdevxres.c
> gs/base/gdevxxf.c
> gs/base/gxccache.c
> gs/base/gxccman.c
> gs/base/gxchar.c
> gs/base/gxchar.h
> gs/base/gxfcache.h
> gs/base/macos-mcp.mak
> gs/doc/Xfonts.htm

2011-07-20 14:36:10 +0100
Chris Liddell <chris.liddell@artifex.com>
5ca50b1770ae583490954f1546b17bad421fbc9f

> Bug 692359: Retain WMode from CMaps embedded in PDFs
> The read_CMap procedure skips everything in the embedded
> CMap file stream except the actual character ranges (as does
> Acrobat), thus we lose the WMode setting (if present) from
> the stream. Nor were we propagating the value from the PDF
> CMap stream dict.
> This revision ensures we propagate the WMode value the PDF
> CMap stream dictionary (if present), which matches Acrobat's
> behaviour.
> No cluster differences.
> gs/Resource/Init/pdf_font.ps

2011-07-19 21:57:35 -0600
Henry Stiles <henry.stiles@artifex.com>
a46123967e919fdd557411d2b0d177e6be2722e3

> Fixes 692234 premature erasepage.
> The page was being erased before the postscript interpreter was
> properly initialized. In particular for the crash in this bug a
> default halftone has to be installed before erasepage.
> psi/psitop.c

2011-07-19 17:12:23 +0100
Robin Watts <Robin.Watts@artifex.com>
a6ec8697315e39dabd565a1ca114d3b42f006324

> Small Memento tweaks.
> When moving a block to the tail of the freelist, ensure that its next pointer
> is set to NULL.
> When doing 'setParanoia' ensure that any existing countdown is reset.
> No cluster changes.
> gs/base/memento.c

2011-07-19 10:05:14 +0100
Chris Liddell <chris.liddell@artifex.com>
923d5ca0673442a9e8d4921812ac4fbd75433140

> Fix a warning I introduced, and a couple of others
> gs/base/gdevpng.c

2011-07-18 10:46:05 -0700
Michael Vrhel <michael.vrhel@artifex.com>
9ed6be44e85f03f4a22064b698b3c0ea8c818b53

> Fix so that rendering intent makes it properly through clist along with expanded RI capabilities
> This fixes bug 692139, also adds support for the ability to override the
> internal rendering intent(s) with an externally set rendering intent. Also,
> it is possible to specify specific rendering intents for RGB graphics, images
> and text as well as CMYK graphic images and text. Progressions occur in the
> regression test suite. In particular the file icc_rendering_intent.pdf at 300dpi
> now renders correctly.
> gs/base/gscms.h
> gs/base/gsicc_cache.c
> gs/base/gsicc_manage.c
> gs/base/gxclimag.c
> gs/base/gxclpath.c
> gs/base/gxclrast.c
> gs/base/lib.mak

2011-07-18 17:07:08 +0100
Chris Liddell <chris.liddell@artifex.com>
385f519d34703ba88d107649fb59452617590194

> Remove the PNG_INTERNAL define from the PNG device.
> PNG_INTERNAL being defined exposes libpng's internal APIs which we should
> certainly not be using, and do not appear to. I'm guess that this was
> done to work around an issue in an earlier libpng version, and is no
> longer relevant.
> No cluster differences
> gs/base/gdevpng.c

2011-07-17 09:45:35 -0700
Ray Johnston <ray.johnston@artifex.com>
44a2fd0bb1e2dd12e9ba475da0bdbb93081325d5

> Fix crashes and assertion on 32-bit Windows builds. Bugs 692347, 692348.
> Thanks to SaGS for these fixes. Assertion and crash were found during final checkout of
> the 9.03 release, as well as on the master branch. Partly these problems came from the
> UTF-8 changes.
> VS treats the "char" type as signed by default. When extended characters are promoted
> to ints, the values are negative in the range -128 to -1. These values (except -1
> which conflicts with EOF) are not valid for the "is*()" family of functions.
> For GS_ registry entries that are not set, the utf8 version of 'gp_getenv_registry()'
> incorrectly returned an 'insufficient buffer space' verdict and let the 'needed
> buffer size' to 0 (cbData = 0 after 'RegQueryValueExW()'). The call to fetch the
> value was then made also with a 0-sized buffer, did the same thing, and left the
> buffer for the value undefined. There were also other problems, for example
> non-REG_SZ entries were ignored only when the value was actually requested (not
> during the request for the buffer size) and the function was doing 'free(wp)' with
> wp == NULL in a few cases.
> No cluster differences.
> CLUSTER_UNTESTED
> gs/base/gp_wgetv.c
> gs/base/gsargs.c

2011-07-18 12:52:55 +0100
Robin Watts <Robin.Watts@artifex.com>
80f11f7c17fd2d58eded8e8721a6932a0384f5f5

> Fix plane calculations in planar pattern management.
> The calculation of the depth/shift to use depth in planar pattern management
> was wrong due to a silly typo.
> This doesn't make it work, just solves an obvious problem.
> No cluster differences expected.
> gs/base/gxpcmap.c

2011-07-16 15:22:03 +0000
Robin Watts <robin@ghostscript.com>
ed9ba4062880109265bf286cb2e3fdc7527fe841

> Pattern accumulator changes to support planar output devices.
> When creating the memory buffer for a painttype 1 pattern tile, check
> to see if the underlying device is planar - if it is, then create the
> memory buffer as planar too.
> The code to tile out the planar pattern buffers still needs fixing, but
> this allows halftoning jobs to run to completion at least.
> No cluster differences shown.
> gs/base/gxpcmap.c

2011-07-16 12:58:35 +0000
Robin Watts <robin@ghostscript.com>
a438a9f7d363f76013e1c614fc0818fe081875ad

> Fix pattern cache tile accounting.
> When putting tiles into the pattern cache, we estimate the size we need
> up front (or in the clist case, calculate it exactly). We then clear
> that many bytes in the pattern cache, and add the new tile using that
> estimated size. When we come to evict we recalculate the exact size and
> evict based on that.
> This causes a mismatch whereby the pattern cache thinks it has the wrong
> number of bits cached. When this is an underestimation, we just end up
> using more memory than we'd like. When it overestimates however, we can
> get into an infinite loop trying to evict things.
> The fix is to record the number of bits we've accounted for in every
> tile and thus always count the same coming out as we did coming in.
> If we really want to account for the correct values rather than the
> estimate we can do that, but we must adjust pcache->bits_cache and
> ctile->used appropriately.
> No bug associated with this, but it was triggered by a forthcoming
> commit to make the pattern accumulator use planar buffers for planar
> devices.
> No differences in cluster testing.
> gs/base/gsptype1.c
> gs/base/gxpcmap.c
> gs/base/gxpcolor.h

2011-07-15 20:03:50 -0600
Henry Stiles <henry.stiles@artifex.com>
9b7298f794a4d9bdf5f2bc9dd8401cbfa458a018

> Autoconf changes for X11 and threads.
> config.mak.in
> configure.ac
> main/pcl6_gcc.mak

2011-07-15 18:46:37 +0100
Chris Liddell <chris.liddell@artifex.com>
10fa3cdcae73e526d6279e5a70522d821d08469d

> Set the defines needed to build luratech on WIN64
> CLUSTER_UNTESTED
> gs/psi/msvc.mak

2011-07-15 10:42:30 -0700
Michael Vrhel <michael.vrhel@artifex.com>
bfc0768f53bf96acfbbcf184fe83a09d85b4f5b4

> Addition of an destination ICC profile for demonstrating the setting of rendering intent
> gs/toolbin/color/src_color/cmyk_des_renderintent.icc

2011-07-15 15:12:02 +0100
Chris Liddell <chris.liddell@artifex.com>
2472633cba1418733d079dea15f624c3649bf6dc

> Fix the shared library builds.
> The corrected dependencies in lib.mak broke the shared lib bulids,
> so the rules needed split up to cover the shared and non-shared
> cases.
> gs/base/configure.ac
> gs/base/gs.mak
> gs/base/lib.mak

2011-07-15 14:35:04 +0100
Chris Liddell <chris.liddell@artifex.com>
b0277439b2de03cfcae9282f02021bec72aaa91a

> Resolve a build issue with 64 Windows.
> CLUSTER_UNTESTED
> gs/base/msvctail.mak

2011-07-15 12:51:00 +0100
Robin Watts <Robin.Watts@artifex.com>
9be999c3d781ff92b5498d8cc89b0d2c1fcdc69e

> Fix crashes due to uninitialised reschedule and time_slice procs.
> Freek Kempe reports problems when ghostscript is built with just
> psl3 and pdf FEATURE_DEVS, due to the context entries for
> time_slice_proc and reschedule_proc being uninitialised.
> We take on a (very slightly modified) version of his suggested fix;
> they are now initialised to a dummy procedure, and can be overridden
> by zcontext_init later if required.
> No cluster differences seen.
> gs/psi/icontext.c

2011-07-15 08:57:45 +0100
Chris Liddell <chris.liddell@artifex.com>
7d56fdb732eda354c1c0ccd53e62306caf4f600f

> Small formatting change for the html changelog
> gs/toolbin/gitlog2changelog.py

2011-07-15 08:51:36 +0100
Chris Liddell <chris.liddell@artifex.com>
fc670d3f5dd1e066a838165acec54b2859b1ed78

> Increment the Ghostscript version number to 9.04.
> gs/Resource/Init/gs_init.ps
> gs/base/version.mak

2011-07-15 07:01:39 +0100
Chris Liddell <chris.liddell@artifex.com>
7e299cc60681c53113f513f95a940ef0349219f9

> Fix an error in the Win64 building of genarch.exe
> It was using AUXDIR instead of AUX for the path.
> CLUSTER_UNTESTED
> gs/base/msvctail.mak

2011-07-14 14:19:37 -0700
Michael Vrhel <michael.vrhel@artifex.com>
f98534e2952fb2c2bfa5a3604233d69c76713a41

> Addition of support to override the document specified rendering intent(s)
> Also this includes fixes so that if the source color profiles are specified
> the rendering intents associated with those will be used.
> gs/Resource/Init/gs_lev2.ps
> gs/base/gscms.h
> gs/base/gsicc_cache.c
> gs/base/gsicc_manage.c
> gs/base/gsicc_manage.h
> gs/psi/zusparam.c

2011-07-14 16:07:03 +0100
Chris Liddell <chris.liddell@artifex.com>
fb5f2b5f317f9df6a1258ba53c17da84292cafee

> Small fix to changes for Bug 688528.
> The fix for Bug 688528 contained a conditional error checking for
> a return value of greater than zero when in fact it should be
> greater than or equal to zero.
> No cluster differences.
> gs/base/gdevvec.c

2011-07-14 10:08:02 +0100
Chris Liddell <chris.liddell@artifex.com>
7694aad7c0d84ea8c95acff6ca9b189016c280d1

> Revise error/warning on PDF missing CIDFont.
> Now that GS will attempt to continue interpreting a PDF after an error
> in a given content stream, revise the message we emit when he hit a
> missing CIDFont in a PDF condition to reflect that. If PDFSTOPONERROR
> keep the previous message.
> Also, add a "flush" at the end of each message to ensure they don't get
> mangled by later, high priority messages.
> No cluster differences.
> gs/Resource/Init/pdf_font.ps

2011-07-14 10:03:35 +0100
Chris Liddell <chris.liddell@artifex.com>
62ce501c977ae1a6cb5c38dac545616111c51ed2

> Compile out the Unicode path/parameter code with VC7 and before
> Visual C 7 (Visual Studio 2003) and earlier do not have all the "wide char"
> related library functions needed for the Windows Unicode path and
> parameter handling, causing a link error.
> So when building with VC7 and earlier, leave out the Unicode stuff.
> No cluster differences.
> CLUSTER_UNTESTED
> gs/psi/msvc.mak

2011-07-13 14:34:32 -0700
Michael Vrhel <michael.vrhel@artifex.com>
ed92ea1c85f7ee188d0ab242e72ca2f220367ed8

> Addition of ICC profile for demonstrating use of rendering intent on source color
> gs/toolbin/color/src_color/cmyk_src_renderintent.icc

2011-07-13 10:08:29 -0700
Ray Johnston <ray.johnston@artifex.com>
880f2b2b80ce8f1506b2ec9d81ba73737dfaa4af

> Add flush after -sGenericResourceDir warning message.
> I often have seen this message get garbled by having other messages on stderr "jump in"
> so that the message on stdout gets split up. The "flush" prevents that.
> gs/Resource/Init/gs_res.ps

2011-07-12 19:26:21 -0700
Michael Vrhel <michael.vrhel@artifex.com>
46db3bca63834ae3b3881022fbc9300de8690d10

> Fix so that when the null device is installed it is initialized with the proper icc directory
> This fixes issues on windows when going to the bbox device but there are still issues on linux.
> gs/base/gsdevice.c

2011-07-12 14:07:22 -0700
Michael Vrhel <michael.vrhel@artifex.com>
6b237cb27450a0d09ad982bd45e2e15829ae974f

> Addition of code to support source color management dependent upon the graphic type
> Also fix of the example file that demonstrates this feature.
> gs/base/gscms.h
> gs/base/gsicc_cache.c
> gs/base/gsicc_manage.c
> gs/base/gsicc_manage.h
> gs/base/gxclimag.c
> gs/examples/text_graph_image_cmyk_rgb.pdf

2011-07-12 20:11:46 +0100
Chris Liddell <chris.liddell@artifex.com>
a06634a969ea9b0db2d0840d8641847247056145

> Update autoconf build and the Windows build to use Luratech
> if the directories are found where we expect.
> Include options on each build to disable using Luratech explicitly.
> Document the change in Make.htm
> No cluster differences.
> gs/base/Makefile.in
> gs/base/configure.ac
> gs/doc/Make.htm
> gs/psi/msvc.mak

2011-07-12 19:15:33 +0100
Chris Liddell <chris.liddell@artifex.com>
15d3904a43b2dddda12ed842000d9668c2aff8d7

> Add a simple git log to html changelog script.
> CLUSTER_UNTESTED
> gs/toolbin/gitlog2changelog.py

2011-07-12 17:28:45 +0100
Chris Liddell <chris.liddell@artifex.com>
89de03454ba02713403571cb1cdd1312ae818f81

> Bug 692338: address performance regression in FAPI
> Previously I changed FAPI to only dispose of the outline or
> bitmap part of the Freetype glyph, intead of the entire
> internal glyph object, so as avoid freeing, re-allocating
> and initialising a glyph object for every glyph. That seemed
> to cause a memory leak, so I reverted it.
> This commit does it properly, addresing the memory leak by
> correctly freeing the memory that Freetype returns to us
> *containing* the pointer to the bitmap or outline, as well
> as the bitmap/outline data.
> This is measurably quicker than the previous method.
> No cluster differences expected.
> gs/psi/fapi_ft.c

2011-07-12 06:50:46 -0700
Michael Vrhel <michael.vrhel@artifex.com>
b6a234634d7987890851cb4375e0520ba8dd0750

> Addition of code to support override of internal ICC profiles
> gs/Resource/Init/gs_lev2.ps
> gs/base/gsicc_manage.c
> gs/base/gsicc_manage.h
> gs/psi/zicc.c
> gs/psi/zusparam.c

2011-07-11 09:22:20 +0100
Chris Liddell <chris.liddell@artifex.com>
99cbbdaad585b78dfd32db6dc59c08f9743d8d6a

> Add debugbin to the list of directories to ignore.
> CLUSTER_UNTESTED
> gs/toolbin/localcluster/clusterpush.pl

2011-07-11 09:14:34 +0100
Chris Liddell <chris.liddell@artifex.com>
ee688b964bee8f9562ce92835b2478f88b0dbe31

> Bug 692327: Support libpng 1.5.x API
> Revise to support the latest libpng API, conditionally compiled based on
> the PNG_LIBPNG_VER_MINOR.
> No cluster differences expected.
> gs/base/gdevpng.c

2011-07-10 13:14:04 -0700
Michael Vrhel <michael.vrhel@artifex.com>
d1a349055450612218848e8d15fb6c1a4cc22f5b

> Addition of pdf example file to demonstrate source color graphic object control
> gs/examples/text_graph_image_cmyk_rgb.pdf

2011-07-10 12:54:02 -0700
Michael Vrhel <michael.vrhel@artifex.com>
2065f62ecb27abd974803207a0be160264944401

> reorganization of files for demonstrating source color control based upon graphic type.
> gs/toolbin/color/icc_creator/effects/cmyk_src_cyan.icc
> gs/toolbin/color/icc_creator/effects/cmyk_src_magenta.icc
> gs/toolbin/color/icc_creator/effects/cmyk_src_yellow.icc
> gs/toolbin/color/icc_creator/effects/rgb_source_blue.icc
> gs/toolbin/color/icc_creator/effects/rgb_source_green.icc
> gs/toolbin/color/icc_creator/effects/rgb_source_red.icc
> gs/toolbin/color/src_color/cmyk_src_cyan.icc
> gs/toolbin/color/src_color/cmyk_src_magenta.icc
> gs/toolbin/color/src_color/cmyk_src_yellow.icc
> gs/toolbin/color/src_color/objsrc_profiles_example.txt
> gs/toolbin/color/src_color/rgb_source_blue.icc
> gs/toolbin/color/src_color/rgb_source_green.icc
> gs/toolbin/color/src_color/rgb_source_red.icc

2011-07-10 12:19:33 -0700
Michael Vrhel <michael.vrhel@artifex.com>
213fd2eb89c8a818c546cb888fde6bb67d481c07

> Addition of special effect ICC CMYK source profiles
> A set of CMYK based profiles for demonstrating the usage of source
> color graphic object type dependent color management
> gs/toolbin/color/icc_creator/effects/cmyk_src_cyan.icc
> gs/toolbin/color/icc_creator/effects/cmyk_src_magenta.icc
> gs/toolbin/color/icc_creator/effects/cmyk_src_yellow.icc

2011-07-10 09:39:21 -0700
Michael Vrhel <michael.vrhel@artifex.com>
f24c2cb3f3e030068e48b9c608ebf87e70679547

> Addition of special effect RGB ICC profiles
> These profiles are for use in demonstrating the use of graphic object
> specific color management on source RGB objects.
> gs/toolbin/color/icc_creator/effects/rgb_source_blue.icc
> gs/toolbin/color/icc_creator/effects/rgb_source_green.icc
> gs/toolbin/color/icc_creator/effects/rgb_source_red.icc

2011-07-09 22:47:53 -0700
Michael Vrhel <michael.vrhel@artifex.com>
048a939c8c5880d1f89f3f61df78e147910cb1d0

> Fix for bug 692333.
> Caused by insufficient testing for change in color run when spot colors
> are present during the DeviceN color rendering. Cluster push shows a
> diff in Bug691425.pdf bmpcmp seemed OK.
> gs/base/gxicolor.c

2011-07-08 14:11:52 -0700
Ray Johnston <ray.johnston@artifex.com>
ec7d65ce2cccbc97a2b696ceecb2ba7d329eff79

> Fix initialization in gs_nulldevice (PS nulldevice operator) Bug 692334.
> The gs_nulldevice was setting the get_profile proc to gx_forward_get_profile so the
> icc_array was coming from the current device in the graphics state but that did not
> match the color_info num_components and polarity leading to incorrect values returned
> if gscms_transform_color_buffer set the OutputFormat to 1 (for the nulldevice) of a
> link handle, but a subsequent call to gscms_transform_color with the same link handle
> expected more than one component.
> The initialization of the default profile can only be done if the io_device_table has
> been initialized since this function is called during gs_lib_init1 with the table NULL.
> This change fixes 12-07D.ps differences introduced in the 'tagfix' patch, but does NOT
> introduce any changes to gscms_transform_color_buffer to avoid changing the number
> of components or issue a warning as mentioned in the bug.
> EXPECTED_DIFFERENCES:
> 12-07D should revert to the output prior to the tagfix change (06df93f)
> gs/base/gsdevice.c

2011-07-08 16:41:47 -0700
Michael Vrhel <michael.vrhel@artifex.com>
c48d47e85a27149ecbd84512c8ed80e3d3ab498c

> Fix for graphic tag setting during forward procedure.
> CLUSTER_UNTESTED
> gs/base/gdevnfwd.c

2011-07-08 12:52:25 -0700
Michael Vrhel <michael.vrhel@artifex.com>
c72586e85c6c8953cf3a1cbc32b48949c7622bb4

> Rename variables and objects to be denoted as source graphic tags
> With recent commit of changes to object tags as being a graphic type tag
> it made sense to rename the source color object types similarly.
> CLUSTER_UNTESTED
> gs/base/gscms.h
> gs/base/gsicc_manage.c
> gs/base/gsicc_manage.h
> gs/psi/zusparam.c

2011-07-08 11:42:37 -0700
Michael Vrhel <michael.vrhel@artifex.com>
4df7c79bc1c4df59818ddbc53b20eb1315e7cb48

> Rename of misnamed file.
> CLUSTER_UNTESTED
> gs/toolbin/color/icc_creator/effects/k_only..txt
> gs/toolbin/color/icc_creator/effects/k_only.txt

2011-06-23 11:55:14 -0700
Ray Johnston <ray.johnston@artifex.com>
06df93f6babc540b8e29ae7cc1fcaed888142d52

> Rename object_tag to graphics_type_tag and move to the device for MT rendering.
> The memory->gs_lib_ctx->BITTAG hack was inherently NOT safe for use by multiple
> rendering threads. Devices that want to encode the tag info in the gx_color_index
> need the tag, so we have moved this to the device structure. Multiple rendering
> threads each have unique buffer devices, so this allows clist playback to set
> and use the appropriate tag as the bands are played back without thread
> interference.
> Rename the gs_object_tag_type_t to gs_graphics_type_t to make it more unique for
> grep based searching and prevent confusion with other uses of the term 'object'.
> Move the enum to gscms.h with the 'set' functions prototyped in gxdevcli.h.
> Just as for the device's cmm_dev_profile_t information, the tag needs to be
> forwarded by devices in the chain (clipper, compositor) so that these 'helper'
> filtering devices don't interfere with the setting of the tag. The tag value is
> maintained in all devices in the chain so a 'get_graphics_type_tag' dev_proc
> is not needed -- the dev->graphics_type_tag can be access directly.
> Previously, tags were not recorded except for devices that enabled tags.
> Now tags are tracked for all devices for use in selecting an ICC profile
> and a device can signal that it maintains tags by setting GS_DEVICE_ENCODES_TAGS
> for use by compositors that want to know whether or not to maintain a tag
> plane, such as the pdf14 device.
> Also replace the old 'get_object_type' that the anti-aliasing used with the
> single approach for consistency and to cure problems (not identifed) with using
> AA when other devices are interposed in the chain (clipper, compositor).
> EXPECTED_DIFFERENCES:
> Various 12-07D.PS PS LL3 CET files will show color differences on page 3 (GLOBINT)
> as described in Bug692334.
> gs/base/gdevabuf.c
> gs/base/gdevbit.c
> gs/base/gdevddrw.c
> gs/base/gdevdflt.c
> gs/base/gdevimdi.c
> gs/base/gdevmem.c
> gs/base/gdevnfwd.c
> gs/base/gdevp14.c
> gs/base/gdevprn.h
> gs/base/gdevpsd.c
> gs/base/gdevrinkj.c
> gs/base/gdevrops.c
> gs/base/gdevwts.c
> gs/base/gdevxcf.c
> gs/base/gscms.h
> gs/base/gscsepr.c
> gs/base/gsdevice.c
> gs/base/gsdps1.c
> gs/base/gsequivc.c
> gs/base/gsicc.c
> gs/base/gsicc_cache.c
> gs/base/gsicc_manage.c
> gs/base/gsicc_manage.h
> gs/base/gsimage.c
> gs/base/gslibctx.c
> gs/base/gslibctx.h
> gs/base/gsnamecl.c
> gs/base/gsncdummy.c
> gs/base/gspaint.c
> gs/base/gstext.c
> gs/base/gstrans.c
> gs/base/gsutil.c
> gs/base/gsutil.h
> gs/base/gxacpath.c
> gs/base/gxblend1.c
> gs/base/gxclip.c
> gs/base/gxclipm.c
> gs/base/gxclist.c
> gs/base/gxclrast.c
> gs/base/gxcmap.c
> gs/base/gxdevcli.h
> gs/base/gxdevice.h
> gs/base/gxi12bit.c
> gs/base/gxicolor.c
> gs/base/gximono.c
> gs/base/gxiscale.c
> gs/base/gxistate.h
> gs/base/gxpcmap.c
> gs/base/gxshade.c
> xps/xpsgradient.c

2011-07-08 14:12:51 +0100
Robin Watts <Robin.Watts@artifex.com>
73c09fa015d1e5a19083001bc343abbb67992c9d

> Fix Bug 692331: SEGV in image interpolation.
> In fixing bug 692225, it seems I broke this.
> In the setup code that decides whether decoding is required or not, I
> was incorrectly choosing to use the 'decode' case, when in fact the
> 'decoding' is done later for CIE colorspaces. As such I should have used
> the no-decode case.
> Fixing this appears to cure the problem.
> gs/base/gxiscale.c

2011-07-08 11:14:08 +0100
Chris Liddell <chris.liddell@artifex.com>
02a53b643780f40f5d8947272eabb947002c40b3

> Bug 692322: Clarify in ps2pdf manpage that output goes to cwd by default.
> Credit to Jonathan Nieder <jrnieder@gmail.com>.
> CLUSTER_UNTESTED
> gs/man/ps2pdf.1

2011-07-07 20:50:35 +0000
Robin Watts <robin@ghostscript.com>
0e0db1ca146d82f6a1b0ae90f7146e7d65ffbba9

> Fix bug 692330: SEGV in clist memfile fseek.
> The icc unserialise profile code ftells, then reads, then fseeks to
> maintain the position of the stream. The fseek was leaving the stream
> in an illegal state (the pointer was exactly at the end of the last
> block at the end of the file). Internally we are supposed to always
> have memory allocated for us to write into, and in this circumstance
> we didn't.
> The fseek code was actually correct, as was the ftell code. The problem
> lay in the fwrite code that left the stream in an illegal state.
> The fix is simply to change the fwrite logic slightly; we are guaranteed
> to have space on entry to the loop, so we just need to ensure we have
> space on exit.
> Cluster testing shows no differences (or none due to this change at least).
> gs/base/gxclmem.c
> gs/base/gxclread.c

2011-07-06 23:12:51 -0600
Henry Stiles <henry.stiles@artifex.com>
91c925158fd8bb84c0d44dff2ec4888dc4d6168e

> Updates PDL README.txt
> README.txt

2011-07-07 13:47:03 +0100
Chris Liddell <chris.liddell@artifex.com>
8191a2e349d1f8787b2f4805d770fa8b11f82d18

> Bug 688528-addendum: quell warnings and handle errors.
> gs/base/gdevvec.c
> gs/base/gsdevice.c
> gs/base/gximag3x.c

2011-07-07 10:41:27 +0100
Chris Liddell <chris.liddell@artifex.com>
dadc4955945d8004785ed13095ea9ea79c0f13a6

> Bug 688528: set ICC profiles for interal uses of bbox device.
> If we create a bbox device internally (i.e. not as an output device)
> we must still ensure that the device has ICC profiles set in it. In
> this case, it simply inherits the profile array from the parent
> device.
> This also meant moving the ICC manager initialization to before the
> device "open" call in gs_setdevice_no_erase() because the device set
> can also open another device (in this case, pswrite's "open" has the
> effect, via the vector device, of setting a bbox device instance, so
> there must be an array of ICC profiles at that stage for bbox to
> inherit.
> No cluster differences expected.
> gs/base/gdevvec.c
> gs/base/gsdevice.c
> gs/base/gslib.c
> gs/base/gximag3x.c

2011-07-06 22:05:43 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
73bfbe4b5f6e7090c2b6aad0183ddc8a186d5788

> Fix Cygwin build.
> Some Cygwin tools use \r\n line endings. Add transliteration of \r
> to the space character to compensate for this lossage.
> gs/base/configure.ac

2011-07-06 17:29:24 -0600
Henry Stiles <henry.stiles@artifex.com>
7531d50c7b6dec596e142ff555f3cbfc28613abe

> Shailesh Mistry's fix for 692311 - corrupt character rendering.
> In adaptive compression mode the seed row for delta row compression
> was not properly cleared. With this change the code is now compatible
> with HP monochrome printers, previously the Artifex code was
> compatible with HP Color Laserjets. We do not implement a device
> specific switch - for example the new code could be enabled if the
> current mode of emulation was PCL5E (mono PCL) and not PCL5C (color
> PCL) allowing emulation of both product types. However the corrupt
> character output of HP color printers is probably never an intended
> result.
> pcl/rtraster.c

2011-07-05 11:04:27 -0600
Henry Stiles <henry.stiles@artifex.com>
6e1c268d0ceb3d39e33d242132a917ac27cc2491

> Fix allocator and cleanup.
> Use global allocator in the font directory not the local allocator in
> the graphics state. Move the cache size assignment to the end of the
> procedure after any error can occur and trivial style changes.
> gs/base/gsfont.c

2011-06-29 23:29:44 -0600
Henry Stiles <henry.stiles@artifex.com>
00dbc00bbbbc5dd7d3ec4fce2ac5ed72a4e13bde

> Implement gs_setcachesize properly.
> The previous implementation simply set the cache size state value but
> didn't attempt to rebuild the cache. The new font cache size is
> provided by size operand of setcacheparams.
> We also limit the size operand to the values discovered used by CPSI, the
> range is device dependent and the CPSI range appears reasonable.
> gs/base/gsfont.c

2011-06-23 12:58:53 -0600
Henry Stiles <henry.stiles@artifex.com>
ee351ae182d5f5fabe36f0ce9216a4da39c1c831

> Removes obsolete code.
> The is callback used to be used to delete all characters from the
> cache, we don't do that anymore.
> pcl/pcfont.c

2011-06-18 18:03:44 -0600
Henry Stiles <henry.stiles@artifex.com>
f91aa55a593789c3e342f649e1ebd7f575008e2c

> Fix bug #692246 infinite loop searching the character table.
> Set up the number of characters in the table and the maximum amount of
> memory used by the font cache such that we maintain the invariant that
> we will run out of memory before running out of table entries. Thanks
> to Shailesh Mistry for assistance in analyzing this problem.
> gs/base/gxccman.c

2011-07-06 13:30:23 +0100
Chris Liddell <chris.liddell@artifex.com>
e5a37634a8e15a945e7f5ea4aca68ab8e1e34d3a

> Bug 692318: Ensure that compiler flags are used for the "aux" files.
> For a normal host build, the build tools (genarch, genconf etc) should be
> built with the same compiler flags as Ghostscript/Ghost*. In this case
> the integer type used for encoded color values was not getting used
> when compiling genarch.
> Also, add a warning when tiffsep does have to skip one or more plates, with
> a pointer to the relevant documentation. Lastly, update the doc to reflect
> that the contone preview output may not be as expected if the job uses
> overprint.
> No cluster differences expected.
> common/ugcc_top.mak
> gs/base/gdevtsep.c
> gs/base/msvccmd.mak
> gs/base/msvctail.mak
> gs/base/unix-aux.mak
> gs/doc/Devices.htm

2011-07-04 23:55:57 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
836ac602259ed7e6dfa2845ce78c5fcb516c72e1

> Bug 692026: Replace vsprintf() with vsnprintf()
> vsnprintf() is a safer function. No new compatibility problams are
> expected because vsnprintf() is already used it in Ghostscript.
> gs/base/gxttfb.c
> gs/base/rinkj/rinkj-byte-stream.c

2011-07-02 13:50:28 -0700
Ray Johnston <ray.johnston@artifex.com>
02ef306436f521a059356bbe41805499204051fc

> Change to using encode_color instead of map_rgb_color since map_rgb_color are obsolete.
> The encode_color proc replaced this and devices may not have it set to a valid proc.
> Detected under certain circumstances with the tiffsep device using compressed color
> encoding.
> gs/base/gdevmem.c
> gs/base/gdevmr1.c

2011-07-01 16:46:32 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
c841237f86505fad348295dfb17aea45beed4c89

> Bug 692320: check page count type.
> Check the type of /Count attrubute before using it. Reject invalid
> values and types and scan the page tree instead.
> gs/Resource/Init/pdf_main.ps

2011-07-01 18:03:19 +0100
Robin Watts <Robin.Watts@artifex.com>
52d2decab7955e61a605ab44acb88a08eb79b9cb

> Clist change for plane rop operations.
> If strip_copy_rop is called with the 'lop_planar' indicator bit set in
> the rop, it should encode just a planes worth of data.
> The reading side of clists works without change, I believe.
> gs/base/gxclrect.c

2011-07-01 12:31:54 +0100
Robin Watts <Robin.Watts@artifex.com>
e14ea75d716da7ecdef2211a5d60e46deec55b9f

> Fix clist planar device detection.
> When the clist interrogates a device to see if it is a planar one, it was
> getting the wrong answer due to only the planar memory buffer device
> responding to the question. We fix the main planar device to respond too
> here.
> Also, any device that doesn't understand the is_native_planar question
> would respond -1; the existing code would take this to mean that it is
> planar. The code now only triggers on positive responses.
> No cluster differences expected.
> gs/base/gdevppla.c
> gs/base/gxclist.c

2011-06-30 12:17:08 -0700
Ray Johnston <ray.johnston@artifex.com>
93b4821ada53277b61efb87cbb12eb6a6f71ced0

> FIx segfaults caused by missing prototype causing pointer truncation.
> The gs_state_memory() function prototype is in gxstate.h but this was not being included
> by this file, so on 64-bit builds it truncatad the memory pointer to 32-bits. Tripped over
> on the macpro when doing ps2write. Problematic call was line 1086.
> gs/base/gdevpdfd.c

2011-06-30 20:02:09 +0100
Robin Watts <Robin.Watts@artifex.com>
0038b2fadb34d57f5d43d51d313eb8bc121e929b

> Fix error in plib and plan devices not properly closing down.
> plib_close and plan_close were failing to call the underlying device
> close method, hence leaking.
> CLUSTER_UNTESTED.
> gs/base/gdevplan.c
> gs/base/gdevplib.c

2011-06-30 18:19:30 +0100
Robin Watts <Robin.Watts@artifex.com>
b62b3a9ce165ebca357ebf6b4e2ff4cae8d630d3

> Fix leak of icc_profile in clist playback.
> When reading an icc_profile profile from the clist we were forgetting to
> decrement it's reference count, and so it was being leaked.
> Also fix a whitespace issue.
> No cluster differences expected.
> gs/base/gscspace.h
> gs/base/gxclrast.c

2011-06-30 17:05:19 +0100
Robin Watts <Robin.Watts@artifex.com>
5baa14a107150a5ba4189ff830f21bfdd7da528c

> More Makefile dependency tweaks.
> Limit our insistence on gnu make (for order only dependencies) to
> the autoconf generated makefiles.
> gs/base/Makefile.in
> gs/base/gs.mak
> gs/base/openvms.mak
> gs/base/unix-gcc.mak
> gs/base/unixhead.mak

2011-06-30 16:42:24 +0100
Robin Watts <Robin.Watts@artifex.com>
396fa30df058ccd35375a08e5385fa4251d4b714

> Various Memento changes.
> Add MEMENTO_LEAKONLY option to speed Memento (avoids filling memory and
> checking the filled values for consistency).
> Also, rewrite freelist management to avoid delays when making room.
> Memento in MEMENTO_LEAKONLY now runs almost as fast as normal code.
> Also change gsalloc.c and gsmchunk.c to fall through to the normal malloc
> (and hence Memento) for all blocks (when MEMENTO is defined). No changes
> to normal operation.
> CLUSTER_UNTESTED.
> gs/base/gsalloc.c
> gs/base/gsmchunk.c
> gs/base/malloc_.h
> gs/base/memento.c

2011-06-30 14:24:17 +0100
Robin Watts <Robin.Watts@artifex.com>
44a609ed782883815571bcbc1ed7a602db03c786

> Another attempt at proper directory dependencies.
> The previous attempt failed due to directories getting their timestamp
> updated whenever the contents changed - hence causing stuff to be
> always out of date.
> The 'correct' fix appears to be to use order only dependencies. We do
> this in a portable way by defining a MAKEDIRS variable, that should
> always be the last dependency listed. Unix builds define this to
> "| directories", windows builds leave it blank.
> Testing this work in turn showed up more problems with device
> dependencies - also fixed here.
> gs/base/devs.mak
> gs/base/gs.mak
> gs/base/ijs.mak
> gs/base/jpeg.mak
> gs/base/lib.mak
> gs/base/msvclib.mak
> gs/base/openvms.mak
> gs/base/unix-aux.mak
> gs/base/unix-dll.mak
> gs/base/unix-end.mak
> gs/base/unixhead.mak
> gs/base/unixinst.mak
> gs/psi/msvc.mak

2011-06-30 13:55:54 +0100
Ken Sharp <ken.sharp@artifex.com>
93df8de63350ec70d38cc79494a47cf0a6e172b9

> More changes for CIDSet.
> Make sure that if the CID (LastChar) is greater than num_glyphs, then use LastChar
> for the length of CIDSet and CIDToGIDMap.
> gs/base/gdevpdtd.c

2011-06-29 21:39:01 +0100
Robin Watts <Robin.Watts@artifex.com>
4a65a114f83a6826679625ef8686c1f43c648b43

> Fix leaks in icc code seen during performance testing.
> Whilst performance testing the new thresholding code against the plank
> device as follows:
> pcl6.exe -sDEVICE=plank -o nul: -r600 lj4700_pcl5_color_AC8Z51CC.prn
> various leaks were seen (I used Memento to see them).
> This fixes at least some of them, namely those due to us forgetting to free
> a buffer used to read an icc profile into from the clist.
> Various small bits of error case code is also fixed here.
> gs/base/gxclrast.c
> gs/base/gxclread.c
> gs/base/gxicolor.c

2011-06-29 21:39:58 +0100
Robin Watts <Robin.Watts@artifex.com>
3992ee84c892ed2fcc16b3bd0e89d7e9d878bbaa

> Add STDDIRS dependencies to unix-aux too.
> This prevented configured debug gs builds from working (and possibly others).
> gs/base/unix-aux.mak

2011-06-29 20:55:42 +0100
Robin Watts <Robin.Watts@artifex.com>
22f63a9438d563c3f36a2e652784d53be028bd7d

> Tweak to gsicc_manage.c to avoid potential leak.
> Examining the code, if gsicc_set_icc_directory is called with namelen=0
> then the existing code will allocate a 1 byte buffer and store it in
> the icc_manager.
> If the same function is called again, in the same way, this buffer
> will not be freed before it is overwritten.
> The fix is simply to test for icc_manager->profiledir being non NULL
> rather than the namelen > 0.
> gs/base/gsicc_manage.c

2011-06-29 15:10:03 +0100
Robin Watts <Robin.Watts@artifex.com>
3a26f3c1aa08e6bd4b4550e066da449fb61ee2cf

> Makefile dependency fixes.
> Ray pointed out yesterday that the gs makefile has a malformed dependency
> rule ensuring that the object dirs are created before any compilation
> is done. This doesn't show itself when make is invoked to use a single
> build task at once, but parallel invocations (e.g. make -f 5) can fall
> foul fof it.
> The fix is to properly make every .$(OBJ) file depend on STDDIRS.
> gs/base/lib.mak
> gs/base/msvclib.mak
> gs/base/msvctail.mak
> gs/base/unix-end.mak
> gs/base/unixhead.mak
> gs/psi/msvc.mak
> gs/toolbin/checkdeps.pl

2011-06-29 08:17:46 +0100
Ken Sharp <ken.sharp@artifex.com>
865dca5781dcb4fea12d1349d4f7392d7d809c42

> Change the documented default settings for ps2write to match reality.
> gs/doc/Ps2ps2.htm

2011-06-28 21:55:44 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
c6a8de32823db74a0da27187b7fb049b337c2573

> Bug 692305: Remove -dSAFER from pfbtopfa
> Remove -dSAFER flag from pfbtopfa and wftopfa scripts because it
> interferes with the the normal operation of Ghostscript and serves
> no purpose. No client code is executed by these utilities.
> gs/lib/pfbtopfa
> gs/lib/pfbtopfa.bat
> gs/lib/wftopfa

2011-06-28 21:54:31 +0100
Chris Liddell <chris.liddell@artifex.com>
31cb1ff75d4a77ac32854a68f56d973d06b5da10

> Bug 692310 Add another fallback case for an FT error.
> Add a fallback for the FT_Err_Invalid_Reference error from Freetype.
> As this is a hinting error, we'll fall back to rendering the glyph
> unhinted.
> No cluster differences.
> gs/psi/fapi_ft.c

2011-06-28 20:09:11 +0100
Robin Watts <Robin.Watts@artifex.com>
a1ee78a6de94b8b4292b9ce3b71b54ed3ae7502b

> Fix for Bug 692303, antialiasing problems.
> In trying to fix Bug 692081, I'd inadvertantly broken antialiased
> operation on shapes with multiple 'alpha=0'/'alpha-non-zero'
> transitions.
> My understanding of Peters line accumulator macros was incomplete.
> This new version seems to fix both cases.
> gs/base/gsbitops.h
> gs/base/gxcindex.h

2011-06-28 20:08:40 +0100
Robin Watts <Robin.Watts@artifex.com>
4d44e8a15bfa263b54b369940db9d8ec97d4fc48

> Fix typo in comment.
> CLUSTER_UNTESTED
> gs/base/gxfill.c

2011-06-28 13:12:34 +0100
Robin Watts <Robin.Watts@artifex.com>
11fa4e84f504bdbd9e78495cf5214e49554383b0

> More 'aux' makefile changes.
> Configured gs builds were still not putting the aux directory in the
> right place. Reworked here.
> This has meant changing the horrible 'RELDIR' hack for a slightly
> less horrible hack using 'BUILDDIRPREFIX'. In turn this has meant
> that the shared object targets have one mroe layer of recursion in
> the make, but it's still at the top level, and (arguably) clearer
> now than it was before.
> gs/base/Makefile.in
> gs/base/configure.ac
> gs/base/gs.mak
> gs/base/macos-fw.mak
> gs/base/macosx.mak
> gs/base/ugcclib.mak
> gs/base/unix-dll.mak
> gs/base/unix-end.mak
> gs/base/unix-gcc.mak
> gs/base/unixansi.mak

2011-06-27 20:09:20 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
680d0f9b0a30de60c3289b827714be3f5adc65b1

> Rename -dPDFNOSTOPPED to -dPDFSTOPONERROR
> gs/Resource/Init/gs_init.ps
> gs/Resource/Init/pdf_base.ps
> gs/doc/Use.htm

2011-06-27 19:34:37 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
66700ec35f74a6e049ed6654283418a6d23bfb3e

> Bug 692301: Support /Filter array with /JPXDecode
> Fix a bug in /JPXDecode filter handler that generated bad
> /DecodeParms when /JPXDecode filter was used in a /Filter
> array. Remove some obsolete code related to /JPXDecode.
> gs/Resource/Init/pdf_base.ps
> gs/Resource/Init/pdf_draw.ps

2011-06-27 14:06:27 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
2f08f6f0c1b9bae95387534617005df0b4b7e46f

> Add -dPDFNOSTOPPED option.
> Norrmally, PDF interpreter tries to repair all problems in PDF files.
> -dPDFNOSTOPPED option skips some of the stopped contexts. On error,
> instead of printing a warning and continue, PDF interpreter drops into
> a PostScript error handler that prints detailed information about the
> problem and kills the job.
> gs/Resource/Init/gs_init.ps
> gs/Resource/Init/pdf_base.ps
> gs/doc/Use.htm

2011-06-27 09:22:30 -0600
Henry Stiles <henry.stiles@artifex.com>
9b9d97a5a2c299595048c72fa10e1a2b2845ff58

> Add planar device to the Windows build.
> main/pcl6_msvc.mak

2011-06-27 14:35:52 +0100
Ken Sharp <ken.sharp@artifex.com>
5e292c6c611659105f9bbc50ad33518c97a1923d

> bug #692304 Don't emit '0 g' for 'erasepage'
> showpage causes a fill of an empty path, apparently as part of the erasepage mechanism.
> When used with pdfwrite, with -dUseCIEColor -dPDFA and no Output Intent specified
> this can lead to us emitting a '0 g' in a PDF/A file, whic his only valid if an OutputIntent is specified.
> Fixed by ignoring empty paths. Despite the comment in gdev_pdf_fill_path we
> do not seem to need to do this for text or clips. Probably since I moved the
> 'pdf_set_drawing_color' code out of pdf_reset_color so that we could write colours in a text context.
> This exhibits one progression, with ps2write 'Bug6901014_CImg_flyer.pdf' now
> draws all the output instead of dropping portions of it due to a 'nocurrentpoint' error.
> gs/base/gdevpdfd.c

2011-06-26 11:20:33 +0100
Chris Liddell <chris.liddell@artifex.com>
f3b1a56bb0c5d716868b7914bee6c3740f3f035a

> Update to libjpeg 8c.
> Combines (from libs-update branch) the commits:
> Commit a vanilla copy of libjpeg-8c.
> And the makefile changes to let it build.
> Commit our patch to the libjpeg source.
> Add our patches to the jpeg-8c src.
> This changes every cluster test which contains DCT/JPEG data, but
> they are all very small colour shifts that are invisible
> to the naked eye - as expected by this type of update.
> gs/base/jpeg.mak
> gs/jpeg/Makefile.am
> gs/jpeg/Makefile.in
> gs/jpeg/README
> gs/jpeg/aclocal.m4
> gs/jpeg/ansi2knr.c
> gs/jpeg/cderror.h
> gs/jpeg/cdjpeg.h
> gs/jpeg/change.log
> gs/jpeg/cjpeg.1
> gs/jpeg/cjpeg.c
> gs/jpeg/ckconfig.c
> gs/jpeg/coderules.doc
> gs/jpeg/coderules.txt
> gs/jpeg/config.guess
> gs/jpeg/config.sub
> gs/jpeg/configure
> gs/jpeg/configure.ac
> gs/jpeg/depcomp
> gs/jpeg/djpeg.1
> gs/jpeg/djpeg.c
> gs/jpeg/example.c
> gs/jpeg/filelist.doc
> gs/jpeg/filelist.txt
> gs/jpeg/install-sh
> gs/jpeg/install.doc
> gs/jpeg/install.txt
> gs/jpeg/jaricom.c
> gs/jpeg/jcapimin.c
> gs/jpeg/jcarith.c
> gs/jpeg/jccoefct.c
> gs/jpeg/jcdctmgr.c
> gs/jpeg/jchuff.c
> gs/jpeg/jchuff.h
> gs/jpeg/jcinit.c
> gs/jpeg/jcmainct.c
> gs/jpeg/jcmarker.c
> gs/jpeg/jcmaster.c
> gs/jpeg/jconfig.bcc
> gs/jpeg/jconfig.cfg
> gs/jpeg/jconfig.dj
> gs/jpeg/jconfig.doc
> gs/jpeg/jconfig.mac
> gs/jpeg/jconfig.manx
> gs/jpeg/jconfig.mc6
> gs/jpeg/jconfig.sas
> gs/jpeg/jconfig.st
> gs/jpeg/jconfig.txt
> gs/jpeg/jconfig.vc
> gs/jpeg/jconfig.vms
> gs/jpeg/jconfig.wat
> gs/jpeg/jcparam.c
> gs/jpeg/jcphuff.c
> gs/jpeg/jcprepct.c
> gs/jpeg/jcsample.c
> gs/jpeg/jctrans.c
> gs/jpeg/jdapimin.c
> gs/jpeg/jdapistd.c
> gs/jpeg/jdarith.c
> gs/jpeg/jdatadst.c
> gs/jpeg/jdatasrc.c
> gs/jpeg/jdcoefct.c
> gs/jpeg/jdct.h
> gs/jpeg/jddctmgr.c
> gs/jpeg/jdhuff.c
> gs/jpeg/jdhuff.h
> gs/jpeg/jdinput.c
> gs/jpeg/jdmainct.c
> gs/jpeg/jdmarker.c
> gs/jpeg/jdmaster.c
> gs/jpeg/jdphuff.c
> gs/jpeg/jdsample.c
> gs/jpeg/jdtrans.c
> gs/jpeg/jerror.h
> gs/jpeg/jfdctflt.c
> gs/jpeg/jfdctfst.c
> gs/jpeg/jfdctint.c
> gs/jpeg/jidctflt.c
> gs/jpeg/jidctint.c
> gs/jpeg/jidctred.c
> gs/jpeg/jmorecfg.h
> gs/jpeg/jpegint.h
> gs/jpeg/jpeglib.h
> gs/jpeg/jpegtran.1
> gs/jpeg/jpegtran.c
> gs/jpeg/jutils.c
> gs/jpeg/jversion.h
> gs/jpeg/libjpeg.doc
> gs/jpeg/libjpeg.map
> gs/jpeg/libjpeg.txt
> gs/jpeg/ltconfig
> gs/jpeg/ltmain.sh
> gs/jpeg/makcjpeg.st
> gs/jpeg/makdjpeg.st
> gs/jpeg/makeadsw.vc6
> gs/jpeg/makeapps.ds
> gs/jpeg/makeasln.v10
> gs/jpeg/makecdep.vc6
> gs/jpeg/makecdsp.vc6
> gs/jpeg/makecfil.v10
> gs/jpeg/makecmak.vc6
> gs/jpeg/makecvcx.v10
> gs/jpeg/makeddep.vc6
> gs/jpeg/makeddsp.vc6
> gs/jpeg/makedfil.v10
> gs/jpeg/makedmak.vc6
> gs/jpeg/makedvcx.v10
> gs/jpeg/makefile.ansi
> gs/jpeg/makefile.bcc
> gs/jpeg/makefile.cfg
> gs/jpeg/makefile.dj
> gs/jpeg/makefile.manx
> gs/jpeg/makefile.mc6
> gs/jpeg/makefile.mms
> gs/jpeg/makefile.sas
> gs/jpeg/makefile.unix
> gs/jpeg/makefile.vc
> gs/jpeg/makefile.vms
> gs/jpeg/makefile.wat
> gs/jpeg/makejdep.vc6
> gs/jpeg/makejdsp.vc6
> gs/jpeg/makejdsw.vc6
> gs/jpeg/makejfil.v10
> gs/jpeg/makejmak.vc6
> gs/jpeg/makejsln.v10
> gs/jpeg/makejvcx.v10
> gs/jpeg/makelib.ds
> gs/jpeg/makeproj.mac
> gs/jpeg/makerdep.vc6
> gs/jpeg/makerdsp.vc6
> gs/jpeg/makerfil.v10
> gs/jpeg/makermak.vc6
> gs/jpeg/makervcx.v10
> gs/jpeg/maketdep.vc6
> gs/jpeg/maketdsp.vc6
> gs/jpeg/maketfil.v10
> gs/jpeg/maketmak.vc6
> gs/jpeg/maketvcx.v10
> gs/jpeg/makewdep.vc6
> gs/jpeg/makewdsp.vc6
> gs/jpeg/makewfil.v10
> gs/jpeg/makewmak.vc6
> gs/jpeg/makewvcx.v10
> gs/jpeg/makljpeg.st
> gs/jpeg/maktjpeg.st
> gs/jpeg/missing
> gs/jpeg/rdbmp.c
> gs/jpeg/rdjpgcom.1
> gs/jpeg/rdjpgcom.c
> gs/jpeg/rdppm.c
> gs/jpeg/rdswitch.c
> gs/jpeg/structure.doc
> gs/jpeg/structure.txt
> gs/jpeg/testimg.bmp
> gs/jpeg/testimg.jpg
> gs/jpeg/testimg.ppm
> gs/jpeg/testimgp.jpg
> gs/jpeg/transupp.c
> gs/jpeg/transupp.h
> gs/jpeg/usage.doc
> gs/jpeg/usage.txt
> gs/jpeg/wizard.doc
> gs/jpeg/wizard.txt
> gs/jpeg/wrppm.c

2011-06-26 23:12:38 -0700
Michael Vrhel <michael.vrhel@artifex.com>
5b7a917fa6d092f76a0400e1bce70d02b8b724f1

> Fix for compiler complaint.
> CLUSTER_UNTESTED
> gs/base/gsicc_manage.c

2011-06-25 11:07:25 -0700
Michael Vrhel <michael.vrhel@artifex.com>
f4e1d4b280f6e6ff73d630e2b103a1a6b50c03d9

> Fix for icc directory and icc device profile initialization.
> gs/base/gscms.h
> gs/base/gsdevice.c
> gs/base/gsdparam.c
> gs/base/gsicc_manage.c
> gs/base/gsicc_manage.h
> gs/base/lib.mak
> gs/psi/zdevice.c
> pcl/pctop.c
> psi/psitop.c
> pxl/pxpthr.c
> pxl/pxtop.c
> svg/svgtop.c
> xps/xpstop.c

2011-06-24 18:46:51 +0100
Robin Watts <Robin.Watts@artifex.com>
7af1ebacdb9947ea5197523bcda7764431769e8f

> Add copy_plane to rop source device.
> This uses 'creative engineering' (aka a blatant hack) to allow copy_color
> to be implemented in the "rop source" device.
> We implement a copy_plane entrypoint for the rop source device, that
> does exactly the same as copy_color, except that it abuses the lop
> value passed to the gx_device_color_fill_rectangle by setting a new
> bit (lop_planar) and pickling the plane number into the high bits.
> This is detected in mem_planar_strip_copy_rop and unpicked to a call
> to the appropriate plane.
> Care must be taken when doing rops on the planar device, as
> processing any rop on the device that involves 'D' calls get_bit_rectangle
> which can cause a call to convert from planar to chunky if mishandled.
> The solution is to ensure that we always remove our get_bits_rectangle
> implementation when passing on a ropping call.
> gs/base/gdevmpla.c
> gs/base/gdevrops.c
> gs/base/gsropt.h

2011-06-24 17:38:55 +0100
Chris Liddell <chris.liddell@artifex.com>
0c927bb3e177b5b34ebb1b1f7fa2d9669614fbaf

> Bug 692274: handle vastly different magnitudes in x/y scale
> If the difference in the scale on the x and y axes is large
> (in this case, a factor of 1000), the value scaling we do
> to pass into Freetype can run over/under flow when applied
> to both. The solution is to apply the value scaling
> separately for x and y axes. But the quality is very
> marginally better when the two are scaled together, so we
> do that normally, and only fall back to the separate handling
> when the x and y scales differ by more than 512.
> No cluster differences expected.
> gs/psi/fapi_ft.c

2011-06-24 12:11:48 +0100
Robin Watts <Robin.Watts@artifex.com>
90324e2c6466978f3c01e4a5a3c27d916b9ba9fa

> Fix 'aux' cluster breakages. Move aux into obj.
> Move aux directories into the appropriate obj directories.
> Makes cleaning easier, and is neater overall.
> Also fix some unrelated problems with cleaning in the msvc builds.
> common/msvc_top.mak
> common/pcdefs.mak
> gs/base/all-arch.mak
> gs/psi/msvc.mak
> gs/psi/os2.mak
> gs/toolbin/localcluster/clusterpush.pl
> main/pcl6_gcc.mak
> main/pcl6_msvc.mak

2011-06-23 12:53:01 -0600
Henry Stiles <henry.stiles@artifex.com>
7f2d55272963b039a472adbd26bb9a111e5d31ac

> Use filenames instead of stdin and stdout.
> The original example c programs used stdin and stdout instead of
> reading directly from files. The C programs were changed to use files
> but the associated shell script wasn't updated.
> tools/GOT/dotags.sh

2011-06-22 21:39:01 +0100
Robin Watts <Robin.Watts@artifex.com>
ca0f4ff4a0df386dd4d494a418f09336d06c2451

> Cross compilation (AUX) changes to ghostscript and ghostpdl.
> Introduce a new 'aux' directory and appropriate defines to allow
> easier cross-compilation of gs/ghostpdl.
> common/gccdefs.mak
> common/generic.mak
> common/msvc_top.mak
> common/ugcc_top.mak
> gs/base/Makefile.in
> gs/base/all-arch.mak
> gs/base/gs.mak
> gs/base/lib.mak
> gs/base/msvccmd.mak
> gs/base/msvctail.mak
> gs/base/unix-aux.mak
> gs/base/unix-end.mak
> gs/base/zlib.mak
> gs/psi/msvc.mak
> gs/psi/os2.mak
> main/pcl6_gcc.mak
> main/pcl6_msvc.mak
> pl/pl.mak

2011-06-22 20:05:15 +0100
Chris Liddell <chris.liddell@artifex.com>
3b3261eca08cd73ca355b28fe5125c98d411820d

> Bug 692297: reinstate the proper way to release FT glyphs.
> FT_Glyph_Done is the correct method for freeing both bitmap and
> outline glyphs from Freetype.
> No cluster differences expected.
> gs/psi/fapi_ft.c

2011-06-22 10:46:18 -0700
Ray Johnston <ray.johnston@artifex.com>
f8c4663d5108ca0b7416bf35ba37a8bb63f0b8ed

> Improve documentation about gsapi_set_poll
> gs/doc/API.htm

2011-06-22 10:17:32 -0700
Michael Vrhel <michael.vrhel@artifex.com>
b28982145ccdea3a39f7ad13d7f5c8a00f14f83d

> Replace previous commit file with smaller file.
> CLUSTER_UNTESTED
> gs/examples/text_graphic_image.pdf

2011-06-22 10:12:33 -0700
Michael Vrhel <michael.vrhel@artifex.com>
314d8b86434396afe96ce915dbb1cb0ff01b2047

> Addition of simple example file with text graphic and image objects.
> CLUSTER_UNTESTED
> gs/examples/text_graphic_image.pdf

2011-06-22 09:05:28 -0700
Michael Vrhel <michael.vrhel@artifex.com>
e3def0b758231cd1c5c0510945cef0dd3d938393

> Support for fast thresholding to CMYK planar devices
> Code works for various orientations for color as well as indexed (mono) images.
> There is an inversion (polarity) issue remaining to track down as well as one potential
> rendering issue during the buffer clean up with landscape images. These
> will be resolved shortly. For now, code is sufficiently complete to begin
> timing testing and optimizations. To use specify
> -dCOLORSCREEN -sDEVICE=plank
> and enable processing of color images by setting use_fast_thresh = true
> on line 67 in gxicolor.c
> gs/base/gxht_thresh.c
> gs/base/gxht_thresh.h
> gs/base/gxicolor.c
> gs/base/gxidata.c
> gs/base/gximono.c
> gs/base/lib.mak

2011-06-21 18:52:03 +0100
Robin Watts <Robin.Watts@artifex.com>
fef629cab877b0bbf4f86777f37038d1f37de838

> Fix cut/paste tiffscaled typo in docs.
> CLUSTER_UNTESTED.
> gs/doc/Devices.htm

2011-06-21 16:45:52 +0100
Chris Liddell <chris.liddell@artifex.com>
368e14c73337b42a24299445a660f029d2c26861

> Reinstate the configure check for cups/raster.h.
> Several Linux distributions seem to have neglected to make
> the cups development package depend on the cupsimage
> development package, but we need both for the cups device.
> No cluster differences expected.
> CLUSTER_UNTESTED
> gs/base/configure.ac

2011-06-21 12:31:45 +0100
Ken Sharp <ken.sharp@artifex.com>
dfc53c791d8a121273bd22bbc0c04fd3ed375cdf

> Bug #692218 Create comatible CIDSet
> The fix in Bug 692218 did not (apparently) work for the SolidWorks
> PDF/A validator. This patch sets the number of entries in a CIDSet to
> be the number of glyphs in the font program, and makes the number of entries
> in a CIDToGIDMap the same.
> Together with the commit 27b740 here:
> http://ghostscript.com/pipermail/gs-cvs/2011-June/013024.html
> this now seems to work correctly.
> gs/base/gdevpdtd.c

2011-06-21 12:08:58 +0100
Ken Sharp <ken.sharp@artifex.com>
136934cf60977e5ca6c1a77f8fd4d30a8512b206

> Allow pdfwrite and ps2write to use 64-bit file pointers raising the 4Gb file limit.
> Bug #692290 ps2write and pdfwrite have been using gp_open_scratch_file,
> fseek and ftell, which limit the size of a temporary file to 4GB. This
> commit uses gp_open_scratch_file_64, gp_ftell_64 and gp_fseek_64 whcih
> should allow 64-bit file access on systems which support it.
> Unfortunately I haven't been able to concoct a test for this, so the
> 64-bit code is not tested. However it continues to work normally with the
> clustre regression tests.
> gs/base/gdevpdf.c
> gs/base/gdevpdfo.c
> gs/base/gdevpdfp.c
> gs/base/gdevpdfu.c
> gs/base/gdevpdfx.h
> gs/base/gdevpsu.c
> gs/base/gdevpsu.h

2011-06-20 17:57:46 +0100
Robin Watts <Robin.Watts@artifex.com>
da1152191fb97516b82303ab187b08c971bfd360

> Fix Bug 692057, 'hang' while converting mask->rectangle list.
> Previously the clip accumulator code would attempt to add a new
> rectangle would always search backwards from the tail of the
> list when looking for a new place to insert a rectangle.
> This works well when rectangles are coming in at (or near) the
> end of the list. For cases where this doesn't happen we quickly
> break down to O(n^2) operation.
> The example file on the bug shows one such circumstance, where
> we process a landscape image; this results in the masks coming
> in as '8 bit columns'. The first column accumulates nicely,
> subsequent ones do not.
> The fix here, as suggested by Chris Liddell, is to store the
> 'last insert point', and to search from that. Locality of
> reference should pay off here and lead to much improved
> performance. Certainly tests with the example file show that we
> complete within 2.5 minutes on my machine, compared to 1.5 minutes
> with -dMaxPatternBitmap=32000000, and an unknown time over 5 minutes
> with the old code.
> gs/base/gxacpath.c
> gs/base/gxcpath.c
> gs/base/gxcpath.h

2011-06-20 09:56:37 -0600
Henry Stiles <henry.stiles@artifex.com>
19f10a95bae408363a77f5a2fd05f69350269cb7

> Merge branch 'deprecate_crd_and_cleanup'

2011-06-03 00:15:50 -0600
Henry Stiles <henry.stiles@artifex.com>
476256194a8886951885a4e9ce71972504161192

> Deprecate CRDs in PCL
> pcl/pccrd.c
> pcl/pccrd.h
> pcl/pcdraw.c
> pcl/pcfrgrnd.c
> pcl/pcfrgrnd.h
> pcl/pcl.mak
> pcl/pcommand.c
> pcl/pcpalet.c
> pcl/pcpalet.h
> pcl/pcpatrn.c
> pcl/pcpattyp.h
> pcl/pcstate.h
> pcl/pctop.c

2011-06-02 16:55:55 -0600
Henry Stiles <henry.stiles@artifex.com>
1c1c457a4262f1ef539ec75792c57494c8a746b2

> Trivial warning fixes
> pcl/pcindxed.c
> pcl/pcpage.c

2011-06-02 14:18:35 -0600
Henry Stiles <henry.stiles@artifex.com>
854a16b3eefc0d3b434f446db84e3a9317eda49e

> Make page size procedure robust against paper size table changes.
> pcl/pcpage.c

2011-06-01 11:52:40 -0600
Henry Stiles <henry.stiles@artifex.com>
b89ab3397895d41818170a7f4ea893bbb1580e79

> Clean up warnings and problems identified with static analysis.
> pcl/pcstatus.c
> pcl/pctext.c
> pcl/pctop.c
> pcl/pcuptrn.c
> pcl/pgdraw.c
> pcl/pglabel.c
> pcl/pgvector.c
> pl/pjparse.c
> pl/plchar.c
> pxl/pxfont.c

2011-05-27 14:30:10 -0600
Henry Stiles <henry.stiles@artifex.com>
22b24ea5e3006b4cdc0394c9360423f02b6d3bf9

> Code cleanup directed by static analysis tools.
> Changes function not properly made static, removes unread and unused
> variables.
> pxl/pxpthr.c
> pxl/pxsessio.c
> pxl/pxtop.c

2011-05-27 13:48:38 -0600
Henry Stiles <henry.stiles@artifex.com>
00d4d232283b2eb6c9820618d04b5d4c9eb8a7b3

> Makes procedure static.
> pcl/pctop.c

2011-05-27 13:45:03 -0600
Henry Stiles <henry.stiles@artifex.com>
d98ceb81d6d45f4a2bc49b2f28dd16fe94fea601

> Fixes static analyzer discovered logic error.
> With an array size of 0, the line dash pattern should not be accessed.
> pxl/pxgstate.c

2011-06-20 15:43:34 +0100
Ken Sharp <ken.sharp@artifex.com>
9d0ded9edc84704afd3724b3c7810c035dc4e699

> Permit the calculation of CIDSet and CIDToGIDMap size, for PDF/A validation
> The SolidWorks PDF/A validator complains about the CIDSet we produce for
> embedded TrueType fonts, converted to CIDFonts, when creating PDF/A files.
> I'm still not exactly sure what its complaining about but I'm working with
> our customer to resolve this. In the meantime, this code makes it easier
> to play with teh emission of CIDSet and CIDToGIDMap.
> gs/base/gdevpdtb.c
> gs/base/gdevpdtd.c
> gs/base/gdevpdtf.c
> gs/base/gdevpdtf.h
> gs/base/gdevpdtw.c

2011-06-20 11:17:26 +0100
Ken Sharp <ken.sharp@artifex.com>
27b7404218093f3d1cf414b52721c8a24dbc2746

> ps2write output crashes with limitcheck error after converting large documents
> Adopting patch from 'Steve166' (bug # 692172) with a little gratuitous
> reformatting. (note that opdfread.ps is now compiled in as opdfread.h)
> This converts the directory of objects from an array to a dictionary of dictionaries
> which allows for a more or less unlimited (64k*64k) number of objects.
> No cluster differences expected.
> gs/base/opdfread.h
> gs/lib/opdfread.ps

2011-06-20 03:12:22 -0700
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
0700f67de273e92f06a1e4a0e67e3d023fc29442

> Added dependencies to various makefiles to fix parallel make.
> gs/base/lib.mak
> gs/contrib/contrib.mak

2011-06-17 23:20:30 +0000
Robin Watts <robin@ghostscript.com>
29c7111f3fc5eb4878e875674750c79b1bd85bcc

> Add gdevplan.c to ghostscript visual studio project.
> Should have done this earlier, but forgot. CLUSTER UNTESTED as windows
> only.
> gs/ghostscript.vcproj

2011-06-17 21:08:49 +0100
Robin Watts <Robin.Watts@artifex.com>
75e1e089f68480b68bb9548ba1e6cf0b9d0f73e0

> Fix windows compile breakage; missing definition of int64_t.
> Simply add a #include "stdint_.h" to the top of a file; breakage
> presumably caused by the dependency changes done earlier.
> CLUSTER_UNTESTED.
> gs/base/gstparam.h

2011-06-17 12:34:26 -0700
Michael Vrhel <michael.vrhel@artifex.com>
b058182285c21ff142e46997fd3b8510b6993d66

> Fix for improper offset in contone data. Halftone project only.
> CLUSTER_UNTESTED
> gs/base/gxicolor.c

2011-06-17 12:32:11 -0700
Michael Vrhel <michael.vrhel@artifex.com>
096e21027a7ff99cf0e3d0d1e24dac29b2d69f12

> Fix for Bug 692286 - Image too light -- not fully opaque
> when I did some of the work on the compositor queue I had set things up so that the
> update of the blend parameters would be written only into the same bands as the group
> push. The approach of writing only in the bands of the group bounding box will not
> work in general, for example if we have nested groups that only partially overlap. The
> solution is that we have to write the blend parameters in all bands.
> gs/base/gdevp14.c

2011-06-17 10:37:44 -0700
Ray Johnston <ray.johnston@artifex.com>
ee45ee90570975275ad6b826b377d6852b651b6a

> Fix bug 692254 performance problem with pattern that bbox overflowed fixed.
> The compute_inst_matrix relied on the gx_translate_to_fixed but when the
> tx, ty was outside the valid area (txy_fixed_valid false) the float2fixed
> would overflow and change the sign. This killed the performance when the
> j0, i0 loop in tile by steps calculated a VERY large loop range from large
> negative to large positive value.
> The gx_path_translate may not be needed for in this path, but it is included
> since that was in the gx_path_translate_to_fixed. Quick check showed that the
> path is empty as expected, but the call is harmless.
> gs/base/gsptype1.c

2011-06-17 19:43:09 +0100
Robin Watts <Robin.Watts@artifex.com>
9dd7c86d0619a9293f6476092765b86abab3baf1

> Move planar dev_spec_op into core planar device.
> Rather than having plib and plan devices provide a dev_spec_op that
> responds to gxdso_is_native_planar, put the responsibility for this
> into the core planar memory device.
> This not only simplifies the code, it actually fixes a problem whereby
> the memory device was overwriting it with the default.
> gs/base/gdevmpla.c
> gs/base/gdevplan.c
> gs/base/gdevplib.c

2011-06-03 09:55:57 -0700
Ray Johnston <ray.johnston@artifex.com>
a2a0b404be0365a2f789e154733ab51db3b3aa99

> Add an example that uses PostScript to do simple transparency.
> CLUSTER_UNTESTED.
> gs/examples/transparency_example.ps

2011-06-17 17:53:53 +0000
Robin Watts <robin@ghostscript.com>
f80bc7001e2e250348a6db82aa50d25d18848b66

> Enable plan devices in non-windows builds.
> No cluster differences expected.
> gs/base/unix-gcc.mak
> main/pcl6_gcc.mak

2011-06-17 17:11:27 +0000
Robin Watts <robin@ghostscript.com>
4ed123916f3f3373d5648011ea03c3cd969e00c1

> Fix for Bug 692285: phase shift in patterns in long image.
> The phase for a pattern mask was being held in a short, rather
> than in an int. Unsurprisingly this caused problems when the
> phase overflowed. Simple fix is to use an int instead.
> Cluster testing shows no changes.
> gs/base/gsdcolor.h

2011-06-17 13:21:05 +0100
Chris Liddell <chris.liddell@artifex.com>
b8326c843f0d14b55b7b5cc3694977df73d4a0e4

> Remove circular dependency involving gscms.h.
> Robin Watts identified that gscms.h relies on gsutil.h
> which relies on gxstate.h, which relies on gscspace.h which
> relies on gscms.h
> Adding a couple of opaque declarations to gscspace.h (along with
> relevant declaration guards) removes this circular dependency.
> No cluster differences.
> gs/base/gscms.h
> gs/base/gscspace.h

2011-06-17 09:43:21 +0100
Chris Liddell <chris.liddell@artifex.com>
af98a55ac576545d9495cef0884462b7b2fb8205

> Tidy up some of the GS<->FT number conversions.
> gs/psi/fapi_ft.c

2011-06-17 09:49:14 +0000
Robin Watts <robin@ghostscript.com>
7a8971739d33a18dd7d433adcabf2e2dea5b6ba8

> New lib.mak dependency checker, and update lib.mak using it.
> Invoke gs/toolbin/checkdeps.pl and it performs rudimentary
> and easily confused checks on the dependencies in lib.mak.
> It may be simple, but it spots MANY problems, the important
> of which are fixed here.
> It gets easily confused by files not being in the expected
> paths (but these are easy for an operator to spot and ignore).
> No cluster differences expected.
> gs/base/gxstroke.c
> gs/base/lib.mak
> gs/toolbin/checkdeps.pl

2011-06-17 09:30:32 +0100
Chris Liddell <chris.liddell@artifex.com>
2cd56d061e655569ec473d605caae9552355a59f

> Bug 689546: Add clist.dev to the core lib dependencies.
> I previously noted that the clist device is essentially always required
> now, but I used a less than ideal method to address it: having it as
> a dependency of the gdevprn.o object.
> The correct solution, done here, is to include the clist device in the
> libs.dev file, thus making it a direct requirement of the core lib.
> No cluster differences.
> gs/base/lib.mak

2011-06-16 12:11:41 -0700
Michael Vrhel <michael.vrhel@artifex.com>
449e9c8909e5e0cbf92497f1d95bfe60e8e89f6e

> Addition of copy_plane command for clist
> The command closely mimics the copy_mono command and as such shares its
> command operator. With a bit of work it would be possible to get some minor
> code reduction but the recursive nature of the functions makes it a bit
> tricky.
> gs/base/gxcldev.h
> gs/base/gxclimag.c
> gs/base/gxclist.c
> gs/base/gxclist.h
> gs/base/gxclrast.c
> gs/base/gxclrect.c
> gs/base/lib.mak

2011-06-16 14:55:07 +0100
Robin Watts <Robin.Watts@artifex.com>
e34770c45cefbe6c4cf2d564269ff849282dd10f

> Second attempt to add plan devices.
> Add new 'plan' family of planar devices.
> Equivalent to the plib devices, but without the necessity to always band,
> and not using the band donor.
> From the end users point of view, these output ppm etc and are probably
> therefore not that useful as is. They serve the twin purposes of allowing
> us to test planar output, and to act as a basis for devices that need
> planar non-interlaced output.
> The development of these devices showed a problem with
> gx_get_bits_return_pointer in the planar case. When called, it would
> assume that the start of the first line of the first plane was at
> 'base', and that subsequent planes could be reached by adding
> raster * height to it. Unfortunately, clist_rasterize_lines resets the
> buffer device at the end, so that height is unrelated (often 1).
> The fix implemented here is to change gx_get_bits_return_pointer to take
> a pointer to the line pointers, rather than a direct base value. This
> means we can always find the subsequent planes correctly.
> In my initial attempt at this, I broke the code by failing to notice that
> gdevmem.c passes the same base pointer to gx_get_bits_copy. Fixed here.
> Cluster testing shows it be OK this time around.
> gs/base/devs.mak
> gs/base/gdevdgbr.c
> gs/base/gdevmem.c
> gs/base/gdevmpla.c
> gs/base/gdevplan.c
> gs/base/gdevplib.c
> gs/base/gxgetbit.h
> gs/psi/msvc.mak

2011-06-16 11:49:18 +0000
Robin Watts <robin@ghostscript.com>
11e242eae4d9c78a556b030ef5e69cb0c94e0d48

> Backout previous commit of 'plan' devices.
> The previous commit caused large numbers of changes. Back it out while
> I investigate why.
> gs/base/devs.mak
> gs/base/gdevdgbr.c
> gs/base/gdevmem.c
> gs/base/gdevmpla.c
> gs/base/gdevplan.c
> gs/base/gdevplib.c
> gs/base/gxgetbit.h
> gs/psi/msvc.mak

2011-06-16 10:00:33 +0100
Robin Watts <Robin.Watts@artifex.com>
583e964a55bf50dc28d1467fd9e9bad7bc03849a

> Add new 'plan' family of planar devices.
> Equivalent to the plib devices, but without the necessity to always band,
> and not using the band donor.
> From the end users point of view, these output ppm etc and are probably
> therefore not that useful as is. They serve the twin purposes of allowing
> us to test planar output, and to act as a basis for devices that need
> planar non-interlaced output.
> gs/base/devs.mak
> gs/base/gdevdgbr.c
> gs/base/gdevmem.c
> gs/base/gdevmpla.c
> gs/base/gdevplan.c
> gs/base/gdevplib.c
> gs/base/gxgetbit.h
> gs/psi/msvc.mak

2011-06-14 18:56:03 +0100
Robin Watts <Robin.Watts@artifex.com>
a36cd9f5c60607dfbc12caadb0987b89ecfa27e7

> Update gx_path_print (and gx_path_dump) to output postscript.
> Same information as before is output, just in a a slightly different
> order. This means we can paste it back into a postscript file with
> less editing.
> CLUSTER_UNTESTED as this is never called in production code.
> gs/base/gxpath.c

2011-06-14 19:15:29 +0100
Robin Watts <Robin.Watts@artifex.com>
c442d7d0d5b11addc39519b155b93b3677c11c4d

> Add memento.c/memento.h to VS project
> Forgot to add these when they were created.
> CLUSTER_UNTESTED as windows only.
> gs/ghostscript.vcproj

2011-06-16 09:56:47 +0100
Ken Sharp <ken.sharp@artifex.com>
7de54e55e57f4046196c0909da247f98ef26b46d

> Extend the uuid change in commit g0b7cd7c to cover Instance UIDs as well as Document UIDs.
> No differences expetced.
> gs/base/gdevpdfe.c

2011-06-15 19:36:31 +0100
Ken Sharp <ken.sharp@artifex.com>
45663bbeb798d7a851546a4d6ccf8954e16696ae

> (pdfwrite) Bug #692280 "Incorrect ToUnicode CMap when the input is a PDF with a 2-byte ToUnicode"
> The code was handling Type 0 fonts as if they were type 1, which meant a maximum
> of 256 entries. Fixed by treating them as TrueType CIDFonts (2 byte codes, maximum
> 64K entries)
> This may need later testing with more extensive collections of conts, we possibly should treat them as regular CIDFotns.
> gs/base/gdevpdte.c

2011-06-15 12:18:16 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
10fad95042303b1996d8565a40d8ca4d5c4eed06

> Dump unchanged MediaBox and CropBox values.
> Output unmodified values of /MediaBox and /CropBox attributes.
> This is done on request from a customer, but should also benefit
> every pdf_info.ps user. This change is not backward compatible.
> gs/toolbin/pdf_info.ps

2011-06-15 01:53:26 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
28ab2c1fafd763c7ab1074c91bf217bbbc871fe7

> Bug 691335: Fix Photoshop EPS separations.
> Use DSC comments to get separation names. If the output device supports
> separations (i.e. has big /MaxSeparations attribute), set /SeparationColorNames
> accordingly. Fix DSC handler; make it ignore the comments after %%EndComments
> to avoid handling of DSC comments in nested EPS documents. Drop strange
> code that runs tint transform function when any of the colorant names is
> is a standard name (Gray, Red, Cyan, ...).
> gs/Resource/Init/gs_epsf.ps
> gs/psi/zcolor.c

2011-06-14 16:52:57 +0100
Ken Sharp <ken.sharp@artifex.com>
0b7cd7ca121ac440d5607cc6795ba8bcd7c20c85

> (pdfwrite) Bug #692268 "pdfwrite sets xapMM:DocumentID incorrectly"
> The XML emission in pdfwrite was simply pasting the UUID as a hex string,
> whereas the spec says it must be a URI.
> This change adds the 'uri:' which is required for compliance.
> No cluster differences expected.
> gs/base/gdevpdfe.c

2011-05-26 10:58:31 +0100
Ken Sharp <ken.sharp@artifex.com>
cba939306ceacde74aac1d9b69ca6cf08ce1ebce

> Use correct enumerator for PCL type 3 fonts in pdfwrite
> Part of the change for type 3 fonts from PCL used the wrong enumerator.
> The code relies on a text enumerator actually being a show enumerator,
> which is guaranteed true if we use the right one, but may not be if we
> use the wrong one.
> This didn't seem to be causing any problems, but fixed anyway.
> gs/base/gdevpdtt.c

2011-06-11 20:52:20 -0400
Ken Sharp <ken.sharp@artifex.com>
49ae789184ebb094c29b14a6778e8fa823f6637a

> Bug 691706: Keep page number with /View
> If we have a View and a Page, but no matrix (not required if we have
> a /View [/Fit]) then do not discard the page number but use it as a
> /Page argument (adding one because pdfmark starts from page 1, not 0).
> gs/Resource/Init/pdf_main.ps

2011-06-11 16:26:11 -0700
Michael Vrhel <michael.vrhel@artifex.com>
03bce08fdcb15702abf4cafbe8723dc8b9b7bd6f

> Fix for aliasing of icc link hash code
> This fixes a problem that existed in the computation of the ICC
> hash code. This was the source of the problem in Bug 692265 (bug fixed with
> this commit in file gsicc_cache.c). Also some error checking code and
> addition of code to handle the transfer function when doing the fast
> thresholding of color images.
> gs/base/gdevp14.c
> gs/base/gsicc_cache.c
> gs/base/gsicc_lcms.c
> gs/base/gxcmap.c
> gs/base/gxcmap.h
> gs/base/gxicolor.c

2011-06-11 10:27:53 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
4c6809dfa1c539d757c30f572922e05cd1436698

> Bug 692252: Trap contents stream errors
> Run PDF operator streams in a stopped context. Stop processing of the
> stream on error, but continue to process rest of the file. Remove a
> hack that defined 'inf' as 0.
> gs/Resource/Init/pdf_base.ps
> gs/Resource/Init/pdf_draw.ps

2011-06-10 00:10:39 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
f256d925aba7bd2c552e3598b5782bc3ab09cf4f

> Bug 692258: Search annots, forms, patterns for fonts.
> Besides the contents, look into annotations to identify fonts used by
> the PDF file. Add recursive enumeration of Form and Pattern resources.
> gs/toolbin/pdf_info.ps

2011-06-09 16:07:15 +0100
Robin Watts <Robin.Watts@artifex.com>
ce51b64c335d6c995c003497988d0327c64985cb

> Add Sags unicode patch for gswin32c stdin/out.
> Patch from Sags to read/write stdin/stdout as unicode and convert
> to/from utf8 when passing to/reading from the core.
> Once again, build with WINDOWS_NO_UNICODE to preserve old behaviour.
> See bug 692770.
> CLUSTER_UNTESTED.
> gs/psi/dwmainc.c

2011-06-09 16:11:00 +0100
Robin Watts <Robin.Watts@artifex.com>
c39c030b850848540a5df1fc25c4dc76ee90040b

> More unicode changes for gswin32
> Taken on (most of) a patch from Russell Lang to dwtext.c, with bugfixes
> to the changes I made yesterday. The bits of the patch I didn't take
> on, were to do with running gswin32 as a true Unicode application.
> Currently we are an ANSI application with a Unicode window. Moving to
> be a true Unicode application may have knock on effects I am unsure of
> (and would certainly leave us different to gswin32c.exe). I don't think
> we lose anything by staying as we are.
> CLUSTER_UNTESTED.
> gs/psi/dwtext.c

2011-06-09 12:09:38 +0100
Chris Liddell <chris.liddell@artifex.com>
752397ab6f16aad4147d6e7101373edd7c9d14d5

> Bug 692263 spot and elide glyphs with zero dimensions.
> A glyph with a zero scale in either dimension could cause divide by
> zero errors in a number of places in the FAPI *interface* code
> (that is: fapi_ft.c, fapiufst.c and fapibstm.c). So catch and handle
> the case early by skipping such case. The wrinkle is charpath operations
> which *must* create a path, even of zero dimensions.
> No cluster differences.
> gs/psi/fapi_ft.c
> gs/psi/fapibstm.c
> gs/psi/fapiufst.c
> gs/psi/ifapi.h
> gs/psi/zfapi.c

2011-06-08 18:36:35 +0100
Robin Watts <Robin.Watts@artifex.com>
199498069233c98424567d22964dd1934c9f766e

> Windows gs console window unicode changes.
> Changes to dwtext.c to allow unicode operation.
> The window is created as a Unicode one, so we get unicode character codes
> delivered to us as they are typed. We convert these incoming key codes
> into utf8, as the gs core expects. Any output from the core is converted
> from utf8 to unicode, and the window now displays unicode.
> The net effect is that the window looks like it's behaving exactly like
> a unix window does.
> The copy and paste functions are updated to cut and paste unicode too.
> As usual, building with WINDOWS_NO_UNICODE preserves existing behaviour
> (useful for windows 95/98/me builds).
> The sole difference in behaviour is that the copy function now removes
> trailing blank lines from the output, as this is never what you want.
> CLUSTER_UNTESTED as windows only changes.
> gs/psi/dwtext.c
> gs/psi/dwtext.h

2011-06-08 14:55:28 +0100
Robin Watts <Robin.Watts@artifex.com>
afda147d56efff03ff6967a91a0436732d7b38fc

> Tweaks to windows makefiles.
> Eliminate some noise during windows builds. Thanks to Norbert Janssen for
> this.
> CLUSTER_UNTESTED
> gs/base/msvctail.mak
> main/pcl6_msvc.mak

2011-06-08 10:05:21 +0100
Robin Watts <Robin.Watts@artifex.com>
3367282be8da9713c0cd7a95a56c59a6b4e69a6e

> Add file missed from last nights commit, 232b1d3.
> Forgot to add the new file :(
> gs/base/gp_wutf8.c

2011-06-07 15:25:57 -0700
Michael Vrhel <michael.vrhel@artifex.com>
6a436e0f9992ab5734b21b796a02ed0976ba1d5b

> Work toward getting fast thresholding for color output devices and color input images
> To make my life easier, this updates msvc.mak to include the planar devices.
> Changes in image_render_mono_ht to work towards the case where the output device is not mono.
> Minor fixes in gxicolor.c in the portion of code that steps through the planes.
> Addition of copy_plan operations in gxht_thresh.c for CMYK planar devices.
> Addition of clip_copy_plane for the clip device (thanks Robin Watts).
> gs/base/gxht_thresh.c
> gs/base/gxht_thresh.h
> gs/base/gxicolor.c
> gs/base/gximono.c
> gs/base/lib.mak
> gs/psi/msvc.mak

2011-06-08 00:02:44 +0100
Robin Watts <Robin.Watts@artifex.com>
232b1d36ad90b8d8be357033a80162fdd9de7aa8

> More work on unicode handling under windows.
> Continuing from commit 0ea739147, fix other issues, including:
> * OpenPrinter calls changed to use OpenPrinterW.
> * FindFirstFile/FindNextFile changed to use FindFirstFileW/FindNextFileW.
> * gp_getenv windows specific registry lookups changed to use unicode
> versions.
> * GetProfileString changed to use GetProfileStringW.
> * Add unicode changes to gswin32 as well as gswin32c.exe.
> This hopefully concludes the bulk of the work on unicode support. Possible
> areas to consider in future include:
> * changing gswin32 so that cut and pasting operates in unicode
> * make gswin32 display text in unicode
> * modify stdin to go from unicode to utf8, and stdout to go from utf8
> back to unicode.
> I hope no idea if any of those are possible or not.
> Testing seems to indicate that this all works OK, but I am not ideally
> set up here.
> For safety, I have introduced a WINDOWS_NO_UNICODE define. If this is
> predefined during a build then this will cause the code to drop back to
> the old mode of operation.
> gs/base/gdevwpr2.c
> gs/base/gp_msprn.c
> gs/base/gp_mswin.c
> gs/base/gp_mswin.h
> gs/base/gp_ntfs.c
> gs/base/gp_wgetv.c
> gs/base/msvctail.mak
> gs/base/windows_.h
> gs/base/winlib.mak
> gs/ghostscript.vcproj
> gs/psi/dwmain.c
> gs/psi/dwmainc.c
> gs/psi/msvc.mak
> pl/dwmainc.c

2011-06-06 22:13:07 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
8b90a80fe86364c0b6c1cad12cfb241c66943c24

> Bug 688064: Add AdjustWidth=WIDTH
> Extend AdjustWidth option to support adjustment to any width. This option
> now accepts the following values;
> 0 - no adjustment, the same as before
> 1 - low res fax adjustments, the same as before
> >1 - adjust to the given width, regardless of the document width.
> gs/base/gdevfax.c
> gs/base/gdevpng.c
> gs/base/gdevtifs.c
> gs/base/gdevtifs.h
> gs/base/gxdownscale.c
> gs/base/gxdownscale.h
> gs/base/minftrsz.c
> gs/base/minftrsz.h
> gs/doc/Devices.htm

2011-06-06 21:00:41 +0100
Robin Watts <Robin.Watts@artifex.com>
f92a542b0475a12f4724d3e57f232cafbe17ce50

> Bug 691118: Fix radial shading bug
> Bug 691118 describes a bug with radial shadings in a PDF file.
> Back in r7982 (git 69a43b0) (16 May 2007) Igor introduced some cunning
> code to speed radial shadings. It would spot that the shading was large
> in comparison with the area being filled, and produce a smaller,
> equivalent shading.
> Essentially, it would take the destination rectangle, and figure out
> where in the shading the 'extremes' of that rectangle would come from
> (allowing for distortion in shape generation) and ensure that the newly
> generated shading covered the same area.
> Either the corners of the rectangle could be extremes, or points on the
> side. The code for the points on the sides was broken due to a typo
> causing the X and Y cases to be switched.
> All that is required to solve the bug is to change the == to !=.
> In researching the problem however, I recommented lots of the code to
> make it more comprehensible (to me at least!) along with introducing
> some temporary variables to make it clearer and avoid needless
> recomputation of values. I am committing this as I believe it's a step
> forward for the code, even though it doesn't actually make a
> difference.
> 48 differences in non-pdfwrite/ps2write tests. 11 in pdfwrite, 17 in
> ps2write. Checked with bmpcmp, all unnoticable to the naked eye, so
> presumably progressions.
> gs/base/gxshade1.c

2011-06-06 14:59:09 +0100
Robin Watts <Robin.Watts@artifex.com>
82dc5982726c8ea05c3be6faa2f370a62f11a94a

> Fix Bug 689737: antialiasing issues with patterns.
> Bug 689737 shows mismatches between rendering with and without
> antialiasing when PaintType 2 patterns are used.
> Following Michaels analysis of the bug, the fix seems to be very simple;
> when opening a pattern accumulator device, if the PaintType is 2, then
> set color_info.anti_alias.graphics_bits to 1. We also set
> color_info.anti_alias.text_bits to 1, even though this is unlikely to
> make a difference if freetype is used.
> No expected cluster differences as antialiasing isn't used in any
> cluster tests.
> This commit also removes a FIXME (as I've checked with Michael), and
> improves the commenting on the device proc structure (which I'd done
> when trying a different device proc based fix, but is an improvement
> anyway).
> gs/base/gxpcmap.c

2011-06-05 23:42:14 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
a0720527bcabb2732c3c06dfe3cae1f9c9ea9318

> Bug 692252: define 'inf' as 0
> Work around a bug in PDF file that has 'inf' instead of a number
> in the content stream. Define a PDF operator 'inf' that returns 0
> and issues a warning.
> gs/Resource/Init/pdf_draw.ps

2011-06-04 22:04:12 +0100
Robin Watts <Robin.Watts@artifex.com>
0ea739147fd02ee0e63e58c036bb63fa841ddd3c

> Bug 691222: Make windows build use UTF-8 encoding.
> We change the windows builds to use the 'wmain' rather than 'main'
> entrypoints. This means we get the command line supplied in 'wchar_t's
> rather than chars. We convert back to chars using UTF-8 encoding, and
> call (what was) the main entrypoint.
> This means that we can cope with unicode filenames/paths etc.
> To match the encoding, we therefore need to wrap every use of the
> filenames with the associated utf-8 -> wchar_t conversion and use
> the unicode file access functions (_wfopen instead of fopen etc)
> instead.
> Simple testing seems to indicate that this works. I think I've got
> every occurence of file access, but it's possible I've missed some. If so
> I'll fix them piecemeal as they are reported.
> This should solve bug 691222, and hopefully 691117.
> gs/base/gp_mswin.c
> gs/psi/dwmainc.c
> pl/dwmainc.c

2011-06-04 22:09:58 +0100
Robin Watts <Robin.Watts@artifex.com>
4aff3e0d813cb00eb62db9720cf99b2d419f999a

> Move various uses of fopen to use gp_fopen.
> For portability we should be using gp_fopen, not fopen.
> gs/base/gdevdevn.c
> gs/base/gdevimdi.c
> gs/base/gdevrinkj.c
> gs/base/gdevtxtw.c
> gs/base/gdevwts.c
> gs/psi/imainarg.c

2011-06-04 00:35:37 -0700
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
77b456f298aeabaa4b27b63a9ead0aa0470ac5b8

> Removed HAVE_HYPOT from configure scripts.
> This revision disables checking for a system hypot() function and is
> a followup to 7dcc68ce753175a9c686021d53a061253e2787c3 which modified
> math_.h to always use our internal hypot() function.
> No expected cluster differences.
> config.mak.in
> configure.ac
> gs/base/Makefile.in
> gs/base/configure.ac
> gs/base/macosx.mak
> gs/base/unix-gcc.mak

2011-06-03 17:33:51 +0100
Robin Watts <Robin.Watts@artifex.com>
31174084f95474f9c0edfd4c534c3b1654c02255

> Fix bug 692226; stray pixels in skewed masked image
> When painting a masked image, we first plot a scanlines worth of
> mask pixels to a mask plane. This is then used in a clipping device to
> clip the image pixels that follow thereafter.
> In the code that plots the masked pixels it currently gathers up 'runs'
> of identical pixels and plots them all at once. This works fine for
> portrait and landscape images, but for skewed ones has problems due to
> rounding errors. By plotting large runs of pixels at once, we can a) get
> gaps between subsequent rows of masked pixels, and b) get a mismatch
> between the pixels covered by the mask and the image. These manifest
> as holes in the image.
> The image code already has a comment in it to the effect that we cannot
> amalgamate large blocks due to rounding errors.
> This fix therefore extends this policy (of not amalgamating) to skewed
> masked images too.
> 426 non-pdfwrite/pswrite differences expected. 79 pdfwrite. 31 ps2write.
> Checked with bmpcmp and all seem either progressions or neutral.
> gs/base/gximono.c

2011-06-03 19:07:47 +0100
Robin Watts <Robin.Watts@artifex.com>
9c5325b7778074c3add1f682058260d7f8154386

> Add clip_copy_plane device procedure.
> Cut and pasted with obvious changes from clip_copy_mono. Nothing remarkable
> worth mentioning.
> Not used in current code, so CLUSTER_UNTESTED.
> gs/base/gxclip.c
> gs/base/gxclip.h

2011-06-03 17:32:09 +0100
Robin Watts <Robin.Watts@artifex.com>
7c8855aed043415063ad7472eb2af4320d4544eb

> Add rasterop to FEATURE_DEVS in msvc makefile.
> The rasterop module is already added by default under unix, so this moves
> windows into line.
> CLUSTER_UNTESTED
> gs/psi/msvc.mak

2011-06-03 12:29:50 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
636788a8e6d2133a7e3294ee4e1b573c64e1254a

> Bug 691906, Drop symbolic flag with named encodings.
> PDF font descriptor has 3 attributes that affect whether the TT font
> is processed as symbolic one. The spec is not clear what to do when
> the attributes conflict. This revision consigers fonts that have
> /WinAnsiEncoding or /MacRomanEncoding as non-symbolic regardless of
> the flags.
> gs/Resource/Init/pdf_font.ps

2011-06-02 20:49:27 -0700
Michael Vrhel <michael.vrhel@artifex.com>
6558511800f1f467b66e8e220b80ac99d6ee6f69

> Addition of code to parse the file for the source object color description
> The file toolbin/color/src_color/objsrc_profiles_example.txt provides example
> content where we have the key word for the profile, the profile and the rendering
> intent. Next step is to implement the usage of these profiles in the link
> construction.
> gs/base/gscms.h
> gs/base/gsicc_manage.c
> gs/base/gsicc_manage.h
> gs/toolbin/color/src_color/objsrc_profiles_example.txt

2011-06-02 12:38:40 +0100
Robin Watts <Robin.Watts@artifex.com>
585cac9d3aa6bca9e877c3e12ef3e28fd4f7f571

> Fix bug 691152; gradients appear 'stepped'.
> The original bug report was that tiffsep and tiff24nc give noticably
> different results. This turns out to be because tiffsep is set to use
> non 'linear-and-separable' colours.
> When shadings are rendered, they are 'decomposed' down into smaller
> and smaller regions, until they are smaller than a given threshold.
> These regions are then filled either with linear filled traps (in the
> linear and separable case) or with constant colour (in the non linear
> and separable case). This means that we can get away with a larger
> threshold in the linear and separable case (tiff24nc) and still see
> smooth results.
> The original version of the code (pre SVN rev 7936) used to decompose
> until the regions were smaller than a pixel. At rev 7936 this was
> upped to be 1 point (1/72 of an inch) (or 1 pixel, whatever was
> larger). Reverting to this original code solves the problem by making
> the constant color regions small enough so that they still look
> smooth.
> There would therefore appear to be several possible approaches to
> solve the problem:
> 1) We could back out the change in 7936. This trades time (27% in the
> worst measured test case) for correctness.
> 2) We could change tiffsep to use linear and separable colours.
> I've opted for an approach based on 1) here, because a bmpcmp clearly
> shows easily visible differences in some files in other devices, for
> example:
> tests_private/comparefiles/470-01.ps.pgmraw.300.0
> By default, the code now operates as pre revision 7936. Should the
> change in speed be considered unacceptable, gs can be build with the
> symbol MAX_SHADING_RESOLUTION defined to maximum dpi to which shadings
> should be decomposed; building with -DMAX_SHADING_RESOLUTION=72 will
> give the same results as the existing code.
> gs/base/gxshade6.c

2011-06-01 11:12:31 -0600
Henry Stiles <henry.stiles@artifex.com>
4132ef5d36ff63b2b84f9864b7240609ac84ac38

> Enhance autoconf tests for SSE2 and byte swapping support.
> Previously we only checked if the test programs compile, now we check
> if they compile and link.
> configure.ac
> gs/base/configure.ac

2011-06-01 16:22:40 +0100
Robin Watts <Robin.Watts@artifex.com>
f83e6d48c33ff1edd2aecbe4482b8a1374808951

> Tweak jbig2dec os_types.h for android mupdf build.
> If HAVE_STDINT_H is defined we are supposed to be getting our definitions
> from stdint.h. Instead the header defines them anyway. Fix this. This showed
> up when building MuPDF for Android.
> gs/jbig2dec/os_types.h

2011-06-01 09:47:56 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
e895d3aae94fa6ca1c53c4e7a47f5894ee3c5943

> Bug 591335: Get ink names from images.
> Fixes a bug in indexed color space handler that prevented proper
> recursion into the base color space, and add /Image /XObject
> to the list of resources that are searched for separation color names.
> gs/Resource/Init/pdf_main.ps

2011-05-31 23:39:45 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
db4af9eaf902dbac931ca8c88c586df9d160fb72

> Bug 692245: Make pattern handler more robust.
> Make pattern handling code tolerant to pattern streams that leave
> some junk on the operand stack.
> gs/Resource/Init/pdf_draw.ps

2011-05-31 09:23:10 -0700
Michael Vrhel <michael.vrhel@artifex.com>
000e8614d2229335ed269f9ebc9a42e33b035f83

> Fix for issues in the setting of the newer ICC device parameters
> This fixes issues that were introduced when I added the new device
> parameters for rendering intent. Also, this adds in a new structure
> for defining different ICC profiles for the SOURCE colors
> of objects (e.g. text image graphic). This will be set as a user
> parameter and stored in the icc manager. Next step in this is
> to get things initialized and then use the associated profiles.
> gs/Resource/Init/gs_lev2.ps
> gs/base/gscms.h
> gs/base/gsdparam.c
> gs/base/gsicc_manage.c
> gs/base/gsicc_manage.h
> gs/psi/zusparam.c

2011-05-31 01:14:21 -0700
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
d0055ac144c1f1a51e906976b85e8e2119b5a2db

> Change rsync max-size in clusterpush.pl to 10 megs.
> To prevent accidently transferring large log files to the casper during
> a clusterpush the rsync in that script was limited to 2.5 megs via the
> the --max-size option. However a recently added source file, imdi_k.c,
> is 2.6 megs, so the max-size limit has been increased to 10 megs.
> gs/toolbin/localcluster/clusterpush.pl

2011-05-31 00:19:38 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
16e928c697f4282c830ab57b7e16347b0b5b086f

> Bug 692242, drop outlines without /Title.
> Ignore outlines without a required /Title attribute and
> issue a warning.
> gs/Resource/Init/pdf_main.ps

2011-05-30 20:26:53 +0100
Robin Watts <Robin.Watts@artifex.com>
91b9580bf09b81126d6a99c6fe3e0048972fe3d0

> Fix Bug 692225. Interpolate and Decode don't play nice.
> Bug 692225 gives an example where an Image with both a Decode array
> and interpolation set to true gives bad results.
> The problem was with a branch of the if in image_render_interpolate_icc
> that was assuming that any decode array given was [0 1]. The fix here is
> simply to test for whether need_decode is set.
> No changes seen on clusterpushing.
> Check this with Michael quand il sont retourne.
> gs/base/gxiscale.c

2011-05-30 14:21:02 +0100
Robin Watts <Robin.Watts@artifex.com>
9fd0b414427b58fc79dae23cb11607ea5fcd0890

> Updated gitpush.sh script.
> Fixed script in light of kens experiences. Better error messages, more
> thorough (i.e. any!) checking. Some documentation in the script.
> gs/toolbin/localcluster/gitpush.sh

2011-05-28 18:04:24 +0100
Robin Watts <Robin.Watts@artifex.com>
543fd70fd3b6afc75a767ba1a41663ec3a982866

> Excellently crufty gitpush script to interface with cluster.
> In your local git repo, do the following:
> git remote add regression@ghostscript.com:/home/regression/cluster/gitbridge/ghostpdl
> Ensure that you are setup to be able to ssh into ghostscript.com as the
> regression user.
> Then:
> git config alias.cluster '!gs/toolbin/localcluster/gitpush.sh'
> Then you can:
> git cluster
> in exactly the same way as we used to be able to be able to:
> gs/toolbin/localcluster/clusterpush.pl
> CLUSTER_UNTESTED.
> gs/toolbin/localcluster/gitpush.sh

2011-05-28 08:49:10 +0100
Chris Liddell <chris.liddell@artifex.com>
94f1a552f75647f142b85e5f30c075c19dde0084

> Bug 692240: Gracefully handle incomplete FontBBox arrays.
> The FAPI code would throw an error if the FontBBox array had fewer
> than four values. We'll now replace the broken array with a valid
> one.
> No cluster differences expected.
> gs/psi/zfapi.c

2011-05-27 10:15:08 -0700
Ray Johnston <ray.johnston@artifex.com>
20520230859eaa315a52731c1361be650c7e4999

> Bug 692237. Fix memfile_unlink to use %p instead of 0x%0x
> When the change was made (8e0f0dfb Ralph Giles 2008-09-10 21:35:24) the unlink
> was missed. The %p is more portable in that it handles 32 or 64 bit addresses
> as strings. Thanks to Norbert Janssen for finding this.
> gs/base/gxclmem.c

2011-05-27 18:07:10 +0100
Chris Liddell <chris.liddell@artifex.com>
5974e9171854673d86e0c47a1d1cfef1ff9a5cb1

> Address a compiler warning.
> No cluster differences.
> gs/psi/imain.c

2011-05-27 17:32:36 +0100
Chris Liddell <chris.liddell@artifex.com>
6a743893666fa2c00244f291b83208e5cb961a27

> Bug 692238: fix a couple of typos in News.htm.
> CLUSTER_UNTESTED
> gs/doc/News.htm

2011-05-27 15:58:28 +0100
Chris Liddell <chris.liddell@artifex.com>
9a83627c1c0015a446fbf087848e98234a2bdddb

> Bug 692220: have the lib file arrays extend as required.
> Previously we had a hard limit of GS_MAX_LIB_DIRS on the number of entries
> allowed in the lib search path. This change makes GS_MAX_LIB_DIRS the
> default space available, but allows the arrays to extend as required.
> No cluster differences expected.
> gs/psi/imain.c
> gs/psi/imainarg.c

2011-05-27 10:15:37 +0100
Chris Liddell <chris.liddell@artifex.com>
96da6c46750074869c5bcaeeba7e204d8df83a16

> Have clusterpush.pl check for/use CLUSTER_USER env var.
> For anyone that uses a different local login than their user name
> for the cluster, rather than have to specify the user name on the
> command line every time, you can now set CLUSTER_USER in your
> shell, and clusterpush.pl will use that, before going to check
> USER and USERNAME as before.
> CLUSTER_UNTESTED
> gs/toolbin/localcluster/clusterpush.pl
> gs/toolbin/localcluster/clusterpush.txt

2011-05-26 11:20:10 -0700
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
998fc31cc9bd717190b0313eb246c14fe6303602

> Restore Makefile to clusterpush.pl file list.
> Removed Makefile from the list of files excluded from the rsync
> operation in clusterpush.pl since the ghostpdl Makefile is not
> built by a configure/autogen.sh operation.
> gs/toolbin/localcluster/clusterpush.pl

2011-05-26 01:09:55 -0700
Ray Johnston <ray.johnston@artifex.com>
eb0b920bd993d1b03478c9ba4dfc54e995ec7bac

> Fix minor typo.
> gs/base/gsmchunk.c

2011-05-25 23:47:04 -0600
Henry Stiles <henry.stiles@artifex.com>
ec6afb99389c13414a43820908e090841b6bcd75

> Fixes Bug 692232 - landscape printed on portrait media.
> Add the ability to pass postscript names on the command line - so now
> AutoRotatePages can be set. The other way of fixing this - specifying
> a different MediaBox would be awkward in the current PCL design.
> pl/plmain.c

2011-05-24 08:08:35 -0700
Ray Johnston <ray.johnston@artifex.com>
25de59220e9472e6de1acc046c317141a1751770

> Fix for Bug 692217 nested trans_pattern_clist SEGV
> This was caused by a clip device created for tiling a mask with a transparent
> pattern rendered with a clist. The clip device used for rendering did not
> get its color_info updated when its target (pdf14) changed the color_info,
> specifically the depth.
> Fixed by grabbing the target color_info after calling the target's compositor.
> gs/base/gdevnfwd.c

2011-05-25 20:55:29 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
b8a35e6cf6f0394487c9e46d989ea57dd0e4203d

> Bug 692229, rename variables in Luratech license blocks.
> Change variable names in rarely compiled blocks related to Luratech
> license key to match the declarations.
> gs/base/sjpx_luratech.c

2011-05-25 19:55:04 +0000
Robin Watts <robin@ghostscript.com>
1de7e6dcb4a89cfdbc93ef176cee17f2e1b430f3

> Revised clusterpush.pl; msys git operation
> Changes to accomodate clusterpushing from windows msys git shells.
> This relies on various other tools being added to the path. See
> forthcoming email.
> CLUSTER_UNTESTED.
> gs/toolbin/localcluster/clusterpush.pl

2011-05-25 11:11:25 +0000
Robin Watts <robin@ghostscript.com>
177d0f5ef5d3d2f992b10750e072dc91696c92cc

> Update gitsetup.h; remove --local.
> Remove a --local from a command that upsets old versions of git, while
> not making a difference to later versions. Thanks to Ray for pointing this
> out.
> CLUSTER_UNTESTED.
> gs/toolbin/gitsetup.sh

2011-05-25 06:54:07 +0000
Ray Johnston <ray.johnston@artifex.com>
ebefadf4428a0fd4ca4607221bb59e2e0343b35b

> Fix executable property to +x.
> gs/toolbin/gitsetup.sh

2011-05-24 16:23:32 +0100
Robin Watts <Robin.Watts@artifex.com>
8151aa54b8a71e5c9929bb43390a9be1b4b8d042

> Add gitsetup.sh to gs/toolbin.
> Simple script for doing the 'obvious' configuration to a freshly checked
> out git clone of ghostscript.
> CLUSTER_UNTESTED.
> gs/toolbin/gitsetup.sh

2011-05-24 07:53:59 -0700
Robin Watts
4dc31e78ea0b58973f5a97319eafcbc10e5b9f2b

> Add autoconf check for bswap32/byteswap.h availability.
> As per bug 692211, add some autoconf magic to detect the presence of
> __builtin_bswap32 and/or byteswap.h.
> No expected cluster changes.
> config.mak.in
> configure.ac
> gs/base/Makefile.in
> gs/base/configure.ac
> gs/base/gsropt.h

2011-05-24 12:38:27 +0100
Robin Watts <Robin.Watts@artifex.com>
38720da47205c029d9bee6c3b792791b6f39277d

> mem_mono_copy_mono optimisations.
> Working on Norberts latest test files, I have changed mem_mono_copy_mono
> to only use copy_rop if the runs are large enough for it to get a
> benefit. Currently this threshold is set to 32 pixels (1 word).
> This is sufficiently high that we get 9.01 or better performance on all the
> test files, but might benefit from further tuning later.
> gs/base/gdevm1.c

2011-05-24 08:35:18 +0100
Ken Sharp <ken.sharp@artifex.com>
b246d9d85c119f101956ba07cf9e1c8b9f510b49

> pdfwrite : set bit 0 of CIDSet.
> Set the CID 0 bit of the CIDSet array, so that this glyph is marked as
> being present, when converting TrueType fonts to CIDFonts for PDF/A
> output.
> CID 0 is required to be present for all CIDFonts, it is the /.notdef
> equivalent.
> gs/base/gdevpdtd.c

2011-05-20 20:45:41 +0100
Robin Watts <Robin.Watts@artifex.com>
99b6056dda5ccf74a270d5ca3dbbe2319dc2c219

> Fix for pdfwritten fts_42xx.xps crashing in transparency stuff.
> See Bug 692219. This may well be patching symptoms rather than correctly
> addressing the problem, but it's low impact, and shouldn't create any new
> problems. We can always back it out after michael has had time to look.
> gs/base/gxblend1.c
> gs/base/gxpcmap.c

2011-05-23 15:42:46 +0100
Robin Watts <Robin.Watts@artifex.com>
86e887eab1634dc9bceec1e1479c11fe03835e96

> mem_mono_strip_copy_rop_dev opts; non-texture 'short' case.
> Attempt to optimise for latest test cases from Norbert.
> Use reverted, and optimised old code for the width < 32 no texture case.
> gs/base/gdevm1.c

2011-05-23 16:41:17 +0100
Ken Sharp <ken.sharp@artifex.com>
54796e82370348412811db945b95c42953ce0957

> Bug #692202 Bug in display_raster function
> The calculation of bytewidth, the number of bytes required for a row of
> pixels, only worked correctly when the colour depth was a multiple of 8.
> Since the device is a display device, and has since become used as a
> general method for getting data out of GS, this is not reasonable
> (monochrome and greyscale devices are less than 8 bits)
> Modified as suggested by Martin Osieka to round up the calculation.
> gs/base/gdevdsp.c

2011-05-23 08:08:23 +0100
Ken Sharp <ken.sharp@artifex.com>
7fcb89d46d42eb8806d226d3eb39a64f2ad0fe08

> Squash a very minor compiler warning
> gs/base/gdevpdtt.c

2011-05-22 22:23:49 +0100
Robin Watts <Robin.Watts@artifex.com>
b7d52f725a7c4ef939469f757687a86252fade9c

> Add Memory squeezing functionality to Memento.
> If you build with MEMENTO_HAS_FORK predefined, then in-app memory
> squeezing is enabled.
> export MEMENTO_SQUEEZEAT=1 then run the app, and it will do some magic
> with repeated forks to test the "failure to allocate" paths through the code.
> All the allocation events before the MEMENTO_SQUEEZEATth one will proceed
> as normal. After that, on every allocation, the code will fork. The child
> will proceed with every allocation failing until the program exits
> (hopefully cleanly, but sometimes leaking memory, sometimes dying with a
> SEGV due to failure to cleanup properly). When the child exits, the
> parent carries on execution (until the next allocation, when the same fork
> process happens again).
> CLUSTER_UNTESTED as disabled by default.
> gs/base/memento.c

2011-05-22 08:36:29 -0700
Michael Vrhel <michael.vrhel@artifex.com>
1be218b08069f483ba53eacddc6f7cfbe96957ea

> Fixes in ICC profile handling and device parameters
> This fixes some issues that were encountered when setting ICC
> profiles on the command line. One issue is that the put_profile
> procedure needs to be initialized a bit earlier which required
> a change in gdevprn.h In addition, when the output profile is
> specified to be the CIELAB profile and there is transparency in
> the file there was a rc issue with the profile when going through
> the clist. This also includes code to handle the rendering intent device
> parameters for object types.
> gs/base/gdevp14.c
> gs/base/gdevprn.h
> gs/base/gscdevn.c
> gs/base/gsdparam.c
> gs/base/gsicc_manage.c
> gs/base/gsicc_manage.h
> gs/base/gxclthrd.c

2011-05-22 08:32:34 -0700
Michael Vrhel <michael.vrhel@artifex.com>
185b6f5db3771f6501d55b7b0b6c6ca8663b24c5

> Update of ICC Creator
> Update to ICC creator project to enable the creation of special effect profiles.
> Also addition of profiles to demonstrate object dependent color management.
> gs/toolbin/color/icc_creator/ICC_Creator/ICC_Creator.rc
> gs/toolbin/color/icc_creator/ICC_Creator/ICC_CreatorDlg.cpp
> gs/toolbin/color/icc_creator/ICC_Creator/ICC_CreatorDlg.h
> gs/toolbin/color/icc_creator/ICC_Creator/icc_create.cpp
> gs/toolbin/color/icc_creator/ICC_Creator/icc_create.h
> gs/toolbin/color/icc_creator/ICC_Creator/resource.h
> gs/toolbin/color/icc_creator/effects/black_output.icc
> gs/toolbin/color/icc_creator/effects/c_only.txt
> gs/toolbin/color/icc_creator/effects/cyan_output.icc
> gs/toolbin/color/icc_creator/effects/k_only..txt
> gs/toolbin/color/icc_creator/effects/m_only.txt
> gs/toolbin/color/icc_creator/effects/magenta_output.icc
> gs/toolbin/color/icc_creator/effects/y_only.txt
> gs/toolbin/color/icc_creator/effects/yellow_output.icc

2011-05-22 00:03:57 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
70912a68940b1361e8d33a239a57280eead00bfc

> Fix optional inline image skipping.
> Use newly created function that calculates the number of components
> of a given image and fix calculation of the inline image size that
> is used to skip optional inline images.
> gs/Resource/Init/pdf_draw.ps

2011-05-21 01:15:49 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
3ac9479be8db8eb44f3787d54a171747b61c2b44

> Bug 692213: verify /Default* colorspaces.
> Check that the number of components of /DefaultGray, /DefaultRGB, and
> /DefaultCMYK is correct, and reject inappropriate color spaces.
> Also fix the code that forces update of the color space at the
> beginning of the page when the page defines any of /Defailt* color
> spaces. This hack has been written long ago but it was unreachable.
> gs/Resource/Init/pdf_draw.ps
> gs/Resource/Init/pdf_main.ps

2011-05-20 19:59:16 +0100
Ken Sharp <ken.sharp@artifex.com>
4c64b898e1dc2b3532e0fe6c18a292fa58843207

> Merge branch 'Type3_PCL'
> gs/base/gdevpdtd.c

2011-05-20 19:43:55 +0100
Ken Sharp <ken.sharp@artifex.com>
83318bd849910c6c79f0ea5cb11912557ac01307

> Final type 3 font modifications for PCL
> We need to probe the glyph cache in process_text_modify_width as well
> process_text_return_width, this is a possible path through the code,
> depending on the exact combination of text operations.
> Remove debugging code
> Tidy up some declarations and casting of poitners to make compilers
> happy.
> gs/base/gdevpdte.c
> gs/base/gdevpdtt.c
> gs/base/gxccache.c

2011-05-20 12:03:14 +0100
Ken Sharp <ken.sharp@artifex.com>
96b967aac2176d9cd96167cc1430bb76074d6384

> Add some prints to caching
> Set the FtonMatrix to the identity when making the CTM the identity, so that these don't get applied twice.
> gs/base/gdevpdtt.c
> gs/base/gxccache.c

2011-05-19 13:51:24 +0100
Ken Sharp <ken.sharp@artifex.com>
0b8df1bfb7f5496ba5b644b21c7586fda6dcdc46

> Add some extra debugging printouts
> Fix log2_scale and depth when creating and testing cache entries in order
> to make sure they are coherent (we don't actually use the entries so the
> values aren't important, as long as they are the same)
> When using PCL bitmap fonts we do want to note glyphs set with setcharwidth
> as cached, as well as those with setcachedevice. (the same is not true
> for PostScript)
> gs/base/gdevpdte.c
> gs/base/gdevpdti.c
> gs/base/gdevpdtt.c

2011-05-17 15:53:56 +0100
Ken Sharp <ken.sharp@artifex.com>
49921ad78b31af5ab8803d6de886d93106c0db0c

> Add another new font type 'ft_PCL_user_defined' for the PCL bitmap
> font.
> Update various parts of the code to treat the new font the same as a
> PostScript type 3 font.
> In pdfwrite, if we capture a CharpProcs, and its for a PCL bitmap font
> then add a cache entry. We do NOT do this for most other fonts, only
> when rendering a glyph. When assembling text, if the font is a PCL
> bitmap font, tehn after checking to see if we've already used it, check
> to see if there is a cache entry. If the PCL job has reused this character
> code with a different bitmap it will haev flushed the cache entry. If we
> font this has happened then capture the new glyph. NB if we are capturing
> a new definition (font->used[[] is valid) then we know this is a redefinition
> so capture into a different font using the old style 'default' implementation.
> gs/base/gdevpdtd.c
> gs/base/gdevpdte.c
> gs/base/gdevpdtf.c
> gs/base/gdevpdti.c
> gs/base/gdevpdts.c
> gs/base/gdevpdtt.c
> gs/base/gdevpdtw.c
> gs/base/gstext.c
> gs/base/gxchar.c
> gs/base/gxftype.h
> gs/base/gxpaint.c
> pcl/pgfont.c
> pl/plfont.c

2011-05-13 19:57:44 +0100
Ken Sharp <ken.sharp@artifex.com>
97fbf9fd981cdda1d6db80c2a808e3935b1809f3

> Apparently missed in previous commit. Update so that stick fonts are
> identified as such to pdfwrite.
> gs/base/gdevpdtd.c

2011-05-13 19:53:56 +0100
Ken Sharp <ken.sharp@artifex.com>
fa801aa476fc200d397f0c72c383462eaad88267

> Add a new font type 'ft_GL2_stick_user_defined' and use it as the FontType
> of the HP/GL2 stick font. Modify code throughout to treat it the same as
> 'ft_user_defined', ie a type 3 font.
> Allow pdfwrite to attach a type 3 'PDF font' to a stick font (normally the
> types are required to be the same).
> Alter the way we calculate the 'default' device matrix during stick font
> accumulation so that we get better stroke widhts.
> Now that we cna identify a stick font, check for anamorphic scaling before
> accumulating the glyphs. If anamorphic scaling, then *don't* treat this as
> a font. THis is because the stroke width will be inconsistent.
> gs/base/gdevpdte.c
> gs/base/gdevpdtf.c
> gs/base/gdevpdti.c
> gs/base/gdevpdts.c
> gs/base/gdevpdtt.c
> gs/base/gdevpdtw.c
> gs/base/gstext.c
> gs/base/gxchar.c
> gs/base/gxftype.h
> gs/base/gxpaint.c

2011-05-12 16:04:17 +0100
Ken Sharp <ken.sharp@artifex.com>
6a1c8f107029e92509dfbcaf4aaf1d691d27abe5

> Alter the way we handle missing glyph names, use the saem code as for
> composite fonts.
> Don't assume the CharProc matrix will be upright when creating the dummy
> 'initial' matrix, copy and scale all the values.
> gs/base/gdevpdtt.c

2011-05-11 15:46:23 +0100
Ken Sharp <ken.sharp@artifex.com>
d2ce995693b6c279ea207081728f6906a02e718a

> More type 3 font madness
> Use the device level 'PS_accumulator' flag in various places instead of
> the more kludgy test against penuym->pte_default being NULL.
> If we don't get a glyph name back from the interpreter (PCL) then invent
> one instead of giving up with an error.
> If we are not a type 3 accumulator, then don't undo the factor of 100
> scaling applied to the device width and height, we only do that for PS.
> Add a routine to return a special 'initial' matrix during the course of
> type 3 accumulation. The PCL stick font uses this to set the line width
> and we need to account for various PS/PDF scaling which will otherwise
> be ignored.
> Make sure we don't try and accumulate a charproc when its being run for a
> charpath operation.
> gs/base/gdevpdfb.h
> gs/base/gdevpdfx.h
> gs/base/gdevpdtt.c

2011-05-06 15:35:13 +0100
Ken Sharp <ken.sharp@artifex.com>
bc6a5bdd6329a0027d0c162e29eda277f85c2a8a

> Type PCL fonts again.
> Put back the matrix scaling in pdf_text_set_cache, even though the matrix
> shoudl always be the identity here when running PCL. Best to be safe.
> set_charproc_attrs emitted a 'd1' setcachedevice, but didn't check if
> the glyph was flipped. For PCL this led to ury being less than lly, and
> so the glyph was elided. Added check to make sure these are correct. This
> required removal of 'const' from an arry as well.
> gs/base/gdevpdfx.h
> gs/base/gdevpdti.c
> gs/base/gdevpdtt.c

2011-05-06 15:06:22 +0100
Ken Sharp <ken.sharp@artifex.com>
8730b9f1c3c1977805a9f0ad830b0268170343c4

> More type 3 changes
> Don't scale the CTM by 100 (done for FreeType) when handling PCL fonts
> in install_charproc_accum, set the boolean to complete_charproc_accum so
> that we don't 'undo' the factor of 100 scaling when the font is PCL.
> Add code to set_charproc_attrs to determine whether this is a 'scale 100'
> (ie PostScript) type 3 font or not, if its not then don't undo the scaling
> by 100 of the CTM.
> When accumulating a chraproc, before setting the CTM to identity matrix
> also set the current point to 0,0, which ensures that that the current point
> doesn't get baked into the character description. Also invalidate the
> 'char_tm' txy_fixed_valid member of the graphics state, this will force
> a recalculation of char_tm using the new identity matrix.
> gs/base/gdevpdfx.h
> gs/base/gdevpdti.c
> gs/base/gdevpdtt.c

2011-05-06 12:29:38 +0100
Ken Sharp <ken.sharp@artifex.com>
1b7695b7f2fe4dac0e228294b944b667e617e822

> More PCL type 3 improvements
> Add code to initialise the returned character code, so that the charproc
> is assigned the correct character code. Further test for PCL fonts in
> pdf_text_set_cache and don't try to use a show enumerator to get the
> 'output_char_code' when we are doing PCL, instead use the one from the
> text enumerator 'returned' structure. Normally this would not be valid
> yet as this is filled in after we've completed the 'show', but we
> set this before startig the show, from the text string, so that it will be
> valid.
> gs/base/gdevpdtt.c

2011-05-06 11:49:19 +0100
Ken Sharp <ken.sharp@artifex.com>
3791899545ad61db983158e468d29de85153f94a

> More type 3 PCL fonts
> Attempt to get gsave/grestore counting correct by addig requied gs_gsave.
> Add code to invalidate the char_ctm as we have altered the CTM to identity
> for capture, and don't want to use the char_ctm (values are restored later).
> gs/base/gdevpdtt.c

2011-05-05 15:26:17 +0100
Ken Sharp <ken.sharp@artifex.com>
1ccea133c3b21570c6400337dbe260791da8807d

> Add in basic handling for PCL type 3 fonts. Now setss up the accumulator
> patches the enumerator procs so that the pdfwrite set_cache is used when
> setcachedevice is issued.
> Text matrices are wrong in many places leading to empty output.
> gs/base/gdevpdtt.c

2011-05-05 14:50:33 +0100
Ken Sharp <ken.sharp@artifex.com>
fa5cce2824ade8c280adf370686e20e661d0c3e3

> Add handler for PCL type 3 fonts. For now this throws an error, just while
> I make sure it doesn't break any PS/PDF files.
> gs/base/gdevpdtt.c

2011-05-05 13:15:19 +0100
Ken Sharp <ken.sharp@artifex.com>
f5cc30c83a05acacfd9c2e18b72e7e716c38d024

> File missed in previous commit
> gs/base/gdevpdtt.c

2011-05-05 13:13:27 +0100
Ken Sharp <ken.sharp@artifex.com>
7838510e494245cc5e5349f2ea0d5ff9028c96d0

> Add better PCL type 3 font handling, step 1
> First, break all the code for starting and stopping accumulators
> into procedures, because the existing code is too hard to read.
> gs/base/gdevpdfb.c
> gs/base/gdevpdfb.h
> gs/base/gdevpdfx.h
> gs/base/gdevpdti.c
> gs/base/gdevpdtt.h

2011-04-29 16:42:30 +0100
Ken Sharp <ken.sharp@artifex.com>
947e90ad0229b6333d6eb61e7f54ac33b200ab28

> initial changes for capturing PCL type 3 fonts in pdfwrite
> Seems to be OK now with PS/PCL, does not crash any longer with PCL, but capture is incorrect.
> gs/base/gdevpdfb.c
> gs/base/gdevpdfb.h
> gs/base/gdevpdfx.h
> gs/base/gdevpdti.c
> gs/base/gdevpdtt.c
> gs/base/gdevpdtt.h

2011-05-20 18:22:37 +0100
Chris Liddell <chris.liddell@artifex.com>
1ab5da13a846b9fde15c2863b6b75ae5b28d22d8

> Bug 692218: Incorrect CIDtoGIDMap length causing crash.
> In pdfwrite's pdf_convert_truetype_font_descriptor() function,
> the lengths of both the CIDtoGIDMap and the CIDSet were being set
> to the number of in use CID's in the font, whereas they need to
> be, and were being filled, as being LastChar + 1 entries long.
> As well as memory corruption, the contents would have been wrong,
> too.
> No cluster differences expected.
> gs/base/gdevpdtd.c

2011-05-20 12:46:09 +0000
Robin Watts <robin@ghostscript.com>
0805588e9bcaec02b4eef4582db6ab23ae8ea1b1

> Fix Bug 692216. Remove zero height traps from shadings.
> The simplified file in Bug 692216 shows a division by zero error when
> filling a trapezoid with zero height. The fix is simply to update
> the code not to draw zero height traps.
> This should be safe as any fill adjustment is done well before this point.
> The cluster shows just one difference. Looking at it in a bmpcmp it does
> look suspicious, but it's not clear whether it's a progression or a
> regression. Ken informs me he's seen the same differences before with
> unrelated changes, so perhaps it's an indeterminism.
> The code seems more sensible this way round anyway.
> gs/base/gxshade6.c

2011-05-20 07:58:28 +0100
Chris Liddell <chris.liddell@artifex.com>
c6341648ed83b1a3dde948bdf8bcf54a2f275fe5

> Reinstate x11alpha as the default device on Unix.
> With the recent revisions to make transparency play nicely
> with anti-aliased output, should now be safe to use as the
> default device.
> CLUSTER_UNTESTED
> gs/base/Makefile.in

2011-05-19 14:55:52 -0600
Henry Stiles <henry.stiles@artifex.com>
9de72911de76b582f028c70564b1539f913b517c

> Make directories silently.
> The previous mkdir incantantation had unwanted warning messages if the
> directory already existed. Thanks to Norbert Janssen for the patch.
> CLUSTER_UNTESTED
> common/msvc_top.mak

2011-05-18 19:04:26 -0600
Henry Stiles <henry.stiles@artifex.com>
413e6e5a1c7ccc3d86678a54e93130ca182f9e98

> Simplify the svg device state.
> Represent colors directly with color indices not strings.
> This will address bug 691886 indirectly but wasn't the motivation
> for changing the state value types.
> gs/base/gdevsvg.c

2011-05-16 13:28:46 -0600
Henry Stiles <henry.stiles@artifex.com>
86da13321eaa87a01b804af3619d30f8a7263f5e

> Decrease debugging verbosity.
> Change default printing to be conditonal on high level device
> debug flag '_'.
> gs/base/gdevsvg.c

2011-05-19 18:32:07 +0100
Chris Liddell <chris.liddell@artifex.com>
4812b7189345fa94075445d8e8d5eef7eb04cdab

> Explicitly disable libtiff's jbig code.
> Add the --disable-jbig option to both Ghostscript and GhostPDL's
> calls to the libtiff configure script, otherwise, if the build
> system has libjbig installed, libtiff's jbig code is enabled,
> and we don't want/need it.
> Bug 692214.
> Makefile
> gs/base/configure.ac

2011-05-19 16:58:33 +0000
Robin Watts <robin@ghostscript.com>
8f4b7b96b14df2bef1564e00c72f087f72bb8f56

> More Memento tweaks. Thanks to Dave Thomas.
> Remove unused variables/unneeded inits.
> CLUSTER_UNTESTED.
> gs/base/memento.c

2011-05-19 15:26:05 +0000
Robin Watts <robin@ghostscript.com>
b35b5d610738a521cfe6374965a8f6c4d6b5d477

> Correct memset prototype in memento.c. D'Oh.
> CLUSTER_UNTESTED.
> gs/base/memento.c

2011-05-19 15:34:31 +0100
Robin Watts <Robin.Watts@artifex.com>
44e59fd123729ba05f8728f01d13406d3e283855

> Merge branch 'patt_trans_clist'

2011-05-19 15:01:14 +0100
Robin Watts <Robin.Watts@artifex.com>
3bf453e7987830459ca677c8fa1b93fbd6c4a7e3

> Fix for icc profile refcounting.
> Take new reference before discarding old one, lest we throw away the
> last reference and then can't pick it up again.
> This solves the SEGV with:
> gs\debugbin\gswin32c.exe -sDEVICE=ppmraw -o out.ppm
> -r300 ..\ghostpcl\tests_private\comparefiles\Bug689690.pdf
> No cluster differences expected.
> gs/base/gdevp14.c

2011-05-19 13:35:37 +0100
Robin Watts <Robin.Watts@artifex.com>
bc9e69257a1605d67aca0cd121e167d7e0ae22be

> Merge branch 'master' into patt_trans_clist
> I expect this to leave me with all files working except for Bug689690.pdf
> which has profile reference counting problems introduced from the trunk.
> For example:
> gs\debugbin\gswin32c.exe -sDEVICE=ppmraw -o out.ppm
> -r300 ..\ghostpcl\tests_private\comparefiles\Bug689690.pdf
> gs/base/gdevp14.c
> gs/base/gsicc_manage.c
> gs/base/gxclrast.c

2011-05-18 15:57:45 +0000
Robin Watts <robin@ghostscript.com>
5cff633dff1b8b91afb97925f8a4f7781db5a9b2

> Fix SEGV in tile_rect_trans_simple.
> If the left hand copy region started to the right of the subtile that was
> actually populated, we would attempt a copy with a negative length. Simple
> fix is to check for this case.
> This should resolve the 5 xps SEGVs.
> gs/base/gxp1fill.c

2011-05-17 23:37:56 +0000
Robin Watts <robin@ghostscript.com>
128650aac51fcf723428b8a902c4e3af7d1d058f

> Fix SEGV in Bug691538.pdf.
> Local testing with:
> gs -dNOGC -Z@? -r300 -sDEVICE=pbmraw -dMaxBitmap=30000000 -o nul: ..\ghostpcl\tests_private\comparefiles\Bug691538.pdf
> shows a SEGV on windows with a debug build. Removing the reference
> decrement solves it and doesn't show any leaks.
> Oddly the cluster doesn't show the SEGV any more, but it did previously.
> gs/base/gxpcmap.c

2011-05-17 18:13:17 +0100
Robin Watts <Robin.Watts@artifex.com>
6780bf7996f1d5a0be5b0dc55e89ea48bf89980e

> Memento realloc fix.
> Memento was filling the 'new' section of realloced blocks incorrectly,
> resulting in memory overwrites.
> gs/base/memento.c

2011-05-17 15:53:01 +0100
Robin Watts <Robin.Watts@artifex.com>
ce8bddd7cef1f9e0d2c2ae28b82d513a6cfa9dce

> Merge branch 'master' into patt_trans_clist
> gs/base/gdevnfwd.c
> gs/base/gdevp14.c
> gs/base/gsicc.c
> gs/base/gsicc_manage.c
> gs/base/gstrans.c
> gs/base/gxclrast.c
> gs/base/gxdevice.h
> gs/ghostscript.vcproj

2011-05-17 15:42:11 +0100
Robin Watts <Robin.Watts@artifex.com>
1b7bf4222988019f17a454ce7a6b841d586c3d4d

> Comment and error code handling tweaks to gdevp14.c
> Correct a typo, update a comment, and avoid a SEGV in the case where
> an allocation of an iccsmask fails.
> No cluster differences expected.
> gs/base/gdevp14.c

2011-05-17 15:38:38 +0100
Robin Watts <Robin.Watts@artifex.com>
6283d613595f2c42a461d2cb8cfddb2e0a6fc168

> Tiny tweak to leaks.tcl
> Tweak leaks.tcl so it doesn't think the file is empty if 'memory allocated'
> is on the first line of the log.
> CLUSTER_UNTESTED.
> gs/toolbin/leaks.tcl

2011-05-17 15:23:24 +0100
Robin Watts <Robin.Watts@artifex.com>
4ec504eeddfd5e17ca5f1b4e58090fb0c1b15201

> Rework colorspace ref counting of cmm_icc_profile_data.
> Previously the code seemed to be trying to take one reference to
> cmm_icc_profile_data for every reference taken to the colorspace. We rework
> this here to only take a single reference to cmm_icc_profile_data for each
> colorspace. This solves at least one SEGV.
> gs/base/gscdevn.c
> gs/base/gscscie.c
> gs/base/gscspace.c
> gs/base/gsicc.c
> gs/base/gsicc_manage.c
> gs/base/gxipixel.c
> gs/base/gxshade.c
> gs/psi/zicc.c

2011-05-12 17:49:46 +0100
Robin Watts <Robin.Watts@artifex.com>
a0ac4ac2082132905463703ddd8b6db6fd95e4fb

> Squash another warning; gdevp14.c.
> Remove an unused variable definition (that is shadowed later on).
> CLUSTER_UNTESTED.
> gs/base/gdevp14.c

2011-05-12 17:41:17 +0100
Robin Watts <Robin.Watts@artifex.com>
d40646d2f1c48c174fad480c03309707b16659c7

> Squash warning.
> Remove unused variable, left over from merge.
> CLUSTER_UNTESTED
> gs/base/gdevnfwd.c

2011-05-12 17:01:59 +0100
Robin Watts <Robin.Watts@artifex.com>
6d910ef6207e3704f1050cd46c481ac81b681261

> Fix SEGVs seen due to icc profile data being freed.
> If we swap the ICC profile data for a colorspace due to starting/stopping
> use of an smask, we must also adjust the reference counts. Hopefully this
> will solve all the SEGVs we see. It does solve at least one.
> gs/base/gdevp14.c

2011-05-12 15:26:56 +0100
Robin Watts <Robin.Watts@artifex.com>
4d9eb7298700e0b4c484f164805d556c03c22b24

> Merge branch 'master' into patt_trans_clist
> Conflicts:
> gs/base/gdevnfwd.c
> gs/base/gxdevice.h
> gs/toolbin/bmpcmp.c
> All trivially resolved except for gdevnfwd.c where I backed out one of the
> fixes from 8ae4342 on instruction from Michael.
> gs/base/gdevnfwd.c
> gs/base/gdevp14.c
> gs/base/gsicc.c
> gs/base/gstrans.c
> gs/base/gxclip.c
> gs/base/gxdevice.h
> gs/base/gxpcmap.c

2011-05-04 20:00:50 +0100
Robin Watts <Robin.Watts@artifex.com>
9d8dc0278374c7c5bb4868a1ed356b8b5f8ece8a

> Whitespace fixes + Return from gx_forward_create_compositor.
> Fix up some stray trailing whitespace.
> Also, gx_forward_create_compositor was neglecting to return a value.
> gs/base/gdevnfwd.c
> gs/base/gdevp14.c

2011-05-03 20:36:49 -0700
Michael Vrhel <michael.vrhel@artifex.com>
8ae4342084cbfc46782ca3fc23b4965f910f3c51

> Fixes for 2 issues. If a clip device is inserted in front of a pdf14 compositor, the ICC profile of the clip device needs to be updated if the compositor action results in a device profile change. Also fix so that when the soft mask ICC profiles are swapped in or out the graphic state ICC profiles are also updated.
> gs/base/gdevnfwd.c
> gs/base/gdevp14.c

2011-05-03 17:30:58 +0100
Robin Watts <Robin.Watts@artifex.com>
e0e5e5c874d7546805558a00bec9c54ebd0770e5

> Backout strokeafterfill stuff, as it proved unnecessary.
> Remove commit eaae298 as it turns out not to be required.
> gs/base/gspaint.c
> gs/base/gspath.h
> gs/base/gxistate.h
> gs/psi/zpaint.c

2011-05-02 19:39:22 +0000
Robin Watts <robin@ghostscript.com>
04eef3817a5a6d3fee054338629b1e50eaa4ee0f

> Merge branch 'master' into patt_trans_clist

2011-05-02 19:28:39 +0000
Robin Watts <robin@ghostscript.com>
df2175e571369df32fc66e375357bc69976c5fed

> Put back default map_rgb_color forwarding.
> At some point around the creation of this branch (which corresponded to our
> move from SVN to git) we lost a line in gdevnfwd.c that sets up a default
> forwarding for map_rgb_color. We don't know why it went, so we're putting it
> back in. This probably hasn't caused any problems as it's a deprecated
> function now.
> gs/base/gdevnfwd.c

2011-05-02 20:02:59 +0100
Robin Watts <Robin.Watts@artifex.com>
8eed15b976995b889a2498b064b53397a7d164a1

> Add gxdevsop.h to VS solution.
> Don't know why this wasn't in before...
> CLUSTER_UNTESTED.
> gs/ghostscript.vcproj

2011-05-02 19:50:04 +0100
Robin Watts <Robin.Watts@artifex.com>
8d52d58da97faadd2dcd009f9a5381e87182789d

> Pacify valgrind (and improve performance?) with tiny change.
> A tiny change to gxclrast.c where we initialise state_tile.size.{x,y}.
> This stops valgrind giving warnings. While the code works OK without
> this (I believe), it can cause various %, /, gcd operations. These are
> all expensive operations and are neatly sidestepped by the simple
> expedient of setting the variable to 0 to start with.
> gs/base/gxclrast.c

2011-05-02 18:32:06 +0000
Robin Watts <robin@ghostscript.com>
4cd416d1e5f46c01ce9827b803035a939872e7f7

> Fix clipping problems with composited pattern clists.
> When using a clist to fill a clipped area with a pattern, the current
> code can drop the clipping device out of the chain. This change solves that
> problem.
> When we create a new compositor, we generally want that compositor to become
> the top device in the chain, so all new drawing commands go to it. In the
> pattern clist case however, we don't create a new compositor - we reuse an
> existing one. It's important in this case *not* to take this as our new
> target, otherwise the higher devices in the chain (such as the clipper
> device) are lost.
> This was shown when rendering pattrans_big.pdf at 300dpi banded to the pkm
> device.
> gs/base/gxclrast.c

2011-05-02 11:21:50 -0700
Michael Vrhel <michael.vrhel@artifex.com>
1d33714d197a3335ad34d21e70fc767cf42b369d

> Fix for typo in pointer name during initialization of shape buffer during transparency pattern filling.
> gs/base/gxp1fill.c

2011-05-02 18:53:00 +0100
Robin Watts <Robin.Watts@artifex.com>
600aa9cc10d4439823de265d2805617154294ee7

> Quiet valgrind warning, and remove misleading init.
> When run with valgrind on:
> gs -sDEVICE=pbmraw -r300 -dMaxBitmap=100000000 -o out.pbm Bug690189c.pdf
> Valgrind complains that params.GrayBackground is used without being
> initialised. We fix this here by amending gs_trans_mask_params_init.
> In so doing, we note that in zbegintransparencymaskgroup we were setting
> params.ColorSpace, only to call gs_trans_mask_params_init and have it
> overwrite it. To avoid confusion we therefore remove this needless init.
> No cluster differences seen in testing.
> gs/base/gstrans.c
> gs/psi/ztrans.c

2011-05-02 14:51:26 +0100
Robin Watts <Robin.Watts@artifex.com>
1dbe20d53a4443a70692e9b7807cfb8a158229d0

> Add support for cups (1bpp) files to bmpcmp.
> gs/toolbin/bmpcmp.c

2011-04-30 17:55:42 +0100
Robin Watts <Robin.Watts@artifex.com>
eaae298fcfe31efda0166786c5624ef8fefd0e12

> Add new .strokeafterfill ps operator/graphics state bit.
> We add a new .strokeafterfill ps operator that takes a bool, and sets it in
> the graphics state. The intention is that this will allow us to spot the
> case where we are executing the stroke part of a combined 'fill and stroke'
> operation (as required by pdf). This should allow us to solve the
> remaining problems with the pdf14/knockout group.
> No cluster differences expected.
> gs/base/gspaint.c
> gs/base/gspath.h
> gs/base/gxistate.h
> gs/psi/zpaint.c

2011-04-29 19:41:50 +0100
Robin Watts <Robin.Watts@artifex.com>
96339fd0f400d7c0534a8ff73c355787d7773297

> Correct typo in comment. CLUSTER_UNTESTED.
> gs/base/gxfillsl.h

2011-04-29 19:39:27 +0100
Robin Watts <Robin.Watts@artifex.com>
6ac5520977be5b3ee198c155ef395c6406962db4

> Whitespace fixes.
> gs/base/gdevp14.c
> gs/base/gsicc.c

2011-04-27 22:41:28 -0700
Michael Vrhel <michael.vrhel@artifex.com>
c9de3e70e4027fb86dde6079a48b29cfd6825c72

> Revert "MSVC changes plus gitignore for patt_trans_clist"
> This reverts commit 01c9c2bd3dbd8be851b2e8dde68885413807e704.
> .gitignore
> gs/ghostscript.vcproj
> win32/GhostPDL.sln
> win32/GhostPDL.suo
> win32/language_switch.vcproj
> win32/language_switch.vcproj.michaelv-PC.michaelv.user
> win32/pcl.vcproj
> win32/pcl.vcproj.michaelv-PC.michaelv.user
> win32/svg.vcproj
> win32/svg.vcproj.michaelv-PC.michaelv.user
> win32/xps.vcproj
> win32/xps.vcproj.michaelv-PC.michaelv.user

2011-04-27 22:27:39 -0700
Michael Vrhel <michael.vrhel@artifex.com>
4b191e99538574a67178a8a4df0e19f380d47403

> Fix for reference counting issue of the compositor device at
> the end of the clist playback. In most cases, the compositor rc
> should be 1 at this point and so the device is closed and then
> freed. The case, when it is not 1 is when we have a pattern
> that has a transparency and is stored in a clist. In this case
> the target for the pattern clist device is the main pdf14 device and
> we increment the rc during this assignment. So, when the
> playback completes, the rc of the compositor is 2. We do not
> want to close and free the compositor, since it is part of the
> main clist that we have going on. Instead we only want to
> decrement the rc. The test file pattrans_big.pdf is now
> handled correctly but has a rendering/tiling issue it appears.
> gs/base/gxclrast.c

2011-04-27 22:20:56 -0700
Michael Vrhel <michael.vrhel@artifex.com>
01c9c2bd3dbd8be851b2e8dde68885413807e704

> MSVC changes plus gitignore for patt_trans_clist
> .gitignore
> gs/ghostscript.vcproj
> win32/GhostPDL.sln
> win32/GhostPDL.suo
> win32/language_switch.vcproj
> win32/language_switch.vcproj.michaelv-PC.michaelv.user
> win32/pcl.vcproj
> win32/pcl.vcproj.michaelv-PC.michaelv.user
> win32/svg.vcproj
> win32/svg.vcproj.michaelv-PC.michaelv.user
> win32/xps.vcproj
> win32/xps.vcproj.michaelv-PC.michaelv.user

2011-04-27 18:43:52 +0000
Robin Watts <robin@ghostscript.com>
82437e248e95c3e9830720feaf5030d37950b091

> Whitespace fixups.
> gs/base/gxpcmap.c

2011-04-27 18:42:10 +0000
Robin Watts <robin@ghostscript.com>
bdbb2b5da2ad758d07dfefc84b2a53c00ba091d4

> Revert SVN commit 12934, ref count checking before free in gxclrast.c
> A couple of weeks ago, I applied a wild stab in the dark to solve a problem
> that I cannot now locate. Having discussed it with Michael it seems that this
> was (at best) just masking another problem (the incorrect ref count
> initialisation of compositors). This has been fixed, so my faulty attempt
> can be backed out.
> We leave a debug only check in there to catch this situation. This should be
> replaced by an assert when we have such things.
> gs/base/gxclrast.c

2011-04-27 15:25:22 +0100
Robin Watts <Robin.Watts@artifex.com>
bdfb4cf85e6c7d78dbeecfb8c6dd06c1eed14714

> Fix overflow in pattern tile size estimation code.
> gs/base/gxpcmap.c

2011-04-27 10:46:22 +0000
Robin Watts <robin@ghostscript.com>
1540df197675f2935c6d743927ad25df0396dfff

> Merge branch 'master' into patt_trans_clist
> gs/base/gstrans.c

2011-04-26 13:23:00 -0700
Michael Vrhel <michael.vrhel@artifex.com>
212d2dba16a53088ba6de69266603db847069ec7

> Check to make sure an empty deviceN params member does not lead to an improper path during the device creation.
> gs/base/gdevp14.c

2011-04-26 19:40:25 +0100
Robin Watts <Robin.Watts@artifex.com>
696ee8153b72d20484e66f5da43b6ee6027fddc4

> Remove partial merge left over from svn conversion.
> gs/base/gsptype1.c

2011-02-09 21:38:24 +0000
mvrhel
ebf1da59669bb51701c3df9747ebe3f4fe9f6b26

> Work on the pattern transparency clist code.
> A squashed and rebased patch based on the following svn commits.
> Author: robin
> Date: Tue Apr 19 12:40:00 2011 +0000
> Various fixes to the transparency clist branch to correctly use
> just the subrectangle of transparency tiles that is actually present.
> Getting this in before the Great Git Change this afternoon.
> git-svn-id: http://svn.ghostscript.com/ghostscript/branches/patt_trans_clist_gs@12407 a1074d23-0009-0410-80fe-cf8c14f379e6
> Author: ray
> Date: Fri Apr 8 16:56:48 2011 +0000
> A couple of minor fixes that help things along, get past compile errors.
> git-svn-id: http://svn.ghostscript.com/ghostscript/branches/patt_trans_clist_gs@12379 a1074d23-0009-0410-80fe-cf8c14f379e6
> Author: mvrhel
> Date: Wed Feb 9 21:38:24 2011 +0000
> Initial commit of work so far on getting the pattern transparency
> clist code working. Much of this comes from work that Ray and I did
> for customer 532. The remaining portion of the work is primarily
> in pdf14_tile_pattern_fill in gdevp14.c, where we need to make
> sure that the group that we are going to push is the intersection
> with the rect from trans pattern since we only use the part that we
> drew into in the pattern creation and not the whole group buffer. I
> had not worked on this in a few weeks so I don't have more details
> right now. I will spend a day on it this week to see exactly what
> remains to be done.
> git-svn-id: http://svn.ghostscript.com/ghostscript/branches/patt_trans_clist_gs@12137 a1074d23-0009-0410-80fe-cf8c14f379e6
> gs/base/gdevnfwd.c
> gs/base/gdevp14.c
> gs/base/gdevp14.h
> gs/base/gsptype1.c
> gs/base/gsptype1.h
> gs/base/gstrans.c
> gs/base/gstrans.h
> gs/base/gxclip.c
> gs/base/gxdevice.h
> gs/base/gxp1fill.c
> gs/base/gxpcmap.c
> gs/base/gxpcolor.h
> gs/psi/zpcolor.c
> gs/psi/ztrans.c
> svg/svgdoc.c
> xps/xpspage.c

2011-05-19 15:27:07 +0100
Robin Watts <Robin.Watts@artifex.com>
e60ed1f615f7347dc9318b2c8e17851fb3a6199a

> Address bug 692211; byteswap.h not present on FreeBSD.
> After googling it seems like the correct thing to do is to use gcc builtin
> intrinsics for byteswapping from 4.3 upwards, and to use byteswap.h
> for all other versions of gcc >= 2.0. This should address the problem.
> gs/base/gsropt.h

2011-05-19 12:28:06 +0000
Robin Watts <robin@ghostscript.com>
f66aa4e491ecff0a5787c4f4a8c8ace1cb7d3432

> Minor tweaks to memento.
> Improve debugging output, documentation. Fix the time at which the sequence
> counter is incremented to give less confusing messages. Add Memento_inited
> function to breakpoint on.
> Not enabled in cluster so, CLUSTER_UNTESTED.
> gs/base/lib.mak
> gs/base/memento.c
> gs/base/memento.h

2011-05-18 12:28:05 -0600
Henry Stiles <henry.stiles@artifex.com>
ef883a068ea54fca1569e5389f7ccfa6aa01e6a8

> Merge branch 'pcl_documentation'

2011-05-14 15:15:32 -0600
Henry Stiles <henry.stiles@artifex.com>
21503ee8197c9707f8ced1c92593c4e279687ee2

> Long overdue update of the PCL documentation.
> doc/ghostpdl.pdf
> doc/ghostpdl.tex
> doc/ghostpdl.txt

2011-05-18 17:48:10 +0100
Robin Watts <Robin.Watts@artifex.com>
62b57818e9117c1ebfe32894464ab12956826f7d

> Workaround SEGV in clist with fillpage (Bug 692076).
> This is a simple patch for the symptoms, not a proper cure, but it suffices
> to get it out of regression test error lists.
> gs/base/gxclrast.c

2011-05-18 15:05:28 +0100
Chris Liddell <chris.liddell@artifex.com>
1a7d4d447c2fc05240ab258f4eb232080fd1fb5f

> Revise 64 bit build options for VS2010.
> Mainly, there was come confusion between the WIN64 setting
> for the type of build, and the BUILD_SYSTEM setting for
> whether the system is 32 or 64 bit.
> NOTE: 64 bit builds on 32 bit systems do not work, and
> I do not intend to attempt to make them work.
> Bug 692126
> CLUSTER_UNTESTED
> gs/psi/msvc.mak

2011-05-18 08:21:21 +0100
Chris Liddell <chris.liddell@artifex.com>
f9cf64f56577b593f424c7d661b5fb8ea7a53216

> Reinstate the Mememto build rules.....
> ....that went AWOL with commit 447c1a791d28fb72b196f75356bc411ef45afbdd
> No cluster differences expected.
> gs/base/lib.mak

2011-05-17 23:43:14 -0700
Michael Vrhel <michael.vrhel@artifex.com>
447c1a791d28fb72b196f75356bc411ef45afbdd

> Fix for MT crashes in lcms
> It turns out that lcms is can not safely share
> profiles between threads when creating links. This
> was fixed by placing a mutex lock around the profile
> creation. It also turns out that lcms can not
> use the same link to do transformations between threads.
> This was solved by disabling the shared cache between
> the threads. Finally there was a race condition in
> reference counting the device ICC profile in the pdf14
> device. Also, this commit includes a fix for a memory
> leak in the pdf_mask object in gdevp14.
> gs/base/gdevp14.c
> gs/base/gscms.h
> gs/base/gsicc_cache.c
> gs/base/gsicc_lcms.c
> gs/base/gsicc_manage.c
> gs/base/gxcldev.h
> gs/base/gxclthrd.c
> gs/base/lib.mak

2011-05-17 22:33:15 +0100
Robin Watts <Robin.Watts@artifex.com>
8d9bc767c0c59a7effa7652cbcbde14ab82de249

> Make Memento work with valgrind, plus fix unix build issues.
> Various fixes for Memento, most especially to ensure it works with
> Valgrind (lots of valgrind calls to make memory readable/hide it again).
> No cluster differences expected.
> gs/base/lib.mak
> gs/base/memento.c
> gs/base/memento.h
> gs/base/unix-aux.mak

2011-05-17 15:29:53 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
cbe9dcfc93812aae26ffd5c2bebbe5b2dc1a4623

> Bug 692209: tolerate missing /Length in PDF stream.
> Add branches that deal with a missing /Length attribute in the
> PDF string directory. The sample file misspells /Length as /Lenght
> but the patch addresses a more general problem.
> gs/Resource/Init/pdf_base.ps

2011-05-17 11:28:50 -0700
Ray Johnston <ray.johnston@artifex.com>
784c8aa262a2a71659ce2d882c424e0254368a10

> Fix ref counting for icc_array
> Copy the icc_array BEFORE putdeviceparams so we don't end up creating extra ones, and bump the shared icc_array.
> The finalize when the device is freed will decrement the ref count.
> gs/base/gxclthrd.c

2011-05-17 18:13:17 +0100
Robin Watts <Robin.Watts@artifex.com>
bc9c681b53babcab8d5e6bd102bfb0c51b8b7ed1

> Memento realloc fix.
> Memento was filling the 'new' section of realloced blocks incorrectly,
> resulting in memory overwrites.
> CLUSTER_UNTESTED as Memento is not enabled by default.
> gs/base/memento.c

2011-05-17 12:03:33 +0000
Robin Watts <robin@ghostscript.com>
2b7e6a4174a58cf0c395e4950a428a722607f860

> Initial commit of new Memento module (attempt #2)
> Memento is a simple memory checking module; it helps to track memory
> corruption and leaks. To use it, build with -DMEMENTO.
> Still to do: Valgrind integration.
> No cluster differences expected.
> gs/base/lib.mak
> gs/base/malloc_.h
> gs/base/memento.c
> gs/base/memento.h

2011-05-15 15:50:40 -0700
Michael Vrhel <michael.vrhel@artifex.com>
1787ce3393956701e6241b8efc6f575887c3f5c1

> Change in device ICC profile handling
> This is the major portion of the code needed to achieve object dependent
> color management. This fixes the problems that existed in the
> previous code with the device parameters and introduces an array of
> ICC profiles in the device structure. The code was cluster pushed and
> showed some very minor differences in a couple files but they appear to be
> OK with bmpcmp. I still need to do further testing to verify that all the
> functionality is correct (e.g. make sure setting the text profile properly
> affects the text only). In addition, the rendering intent options need to be
> implemented.
> I also need to check that nothing was broken with respect to MT
> rendering and some of the devices that are not tested with cluster
> pushing (e.g. the display device and the x11alpha device).
> gs/base/devs.mak
> gs/base/gdevbit.c
> gs/base/gdevnfwd.c
> gs/base/gdevp14.c
> gs/base/gdevpdf.c
> gs/base/gdevpdfk.c
> gs/base/gdevpng.c
> gs/base/gdevpsdi.c
> gs/base/gdevtfnx.c
> gs/base/gdevtsep.c
> gs/base/gdevxini.c
> gs/base/gscms.h
> gs/base/gscsepr.c
> gs/base/gsdevice.c
> gs/base/gsdparam.c
> gs/base/gsequivc.c
> gs/base/gsicc.c
> gs/base/gsicc_cache.c
> gs/base/gsicc_manage.c
> gs/base/gsicc_manage.h
> gs/base/gstrans.c
> gs/base/gxclrast.c
> gs/base/gxclthrd.c
> gs/base/gxcmap.c
> gs/base/gxdevcli.h
> gs/base/gxdevice.h
> gs/base/gxi12bit.c
> gs/base/gxicolor.c
> gs/base/gximag3x.c
> gs/base/gximono.c
> gs/base/gxiscale.c
> gs/base/lib.mak
> gs/psi/zdevice.c
> gs/psi/zusparam.c
> pcl/pctop.c
> psi/psi.mak
> psi/psitop.c
> pxl/pxpthr.c
> pxl/pxtop.c
> svg/svgtop.c
> xps/xpstop.c

2011-05-13 10:52:18 -0700
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
c622f66846aa6b8124b1dffed7dbdaedabedd93f

> Modified clusterpush.pl to not rsync Makefiles
> Modified clusterpush.pl to not rsync Makefiles and config.log files.
> Also removed the various files that have been moved to the cluster.git
> repository.
> No expected cluster differences.
> gs/toolbin/localcluster/bmps2html.pl
> gs/toolbin/localcluster/build.pl
> gs/toolbin/localcluster/cachearchive.pl
> gs/toolbin/localcluster/checkSize.pl
> gs/toolbin/localcluster/clustermaster.pl
> gs/toolbin/localcluster/clustermonitor.cgi
> gs/toolbin/localcluster/clustermonitor.pl
> gs/toolbin/localcluster/clusterpull.sh
> gs/toolbin/localcluster/clusterpush.pl
> gs/toolbin/localcluster/compare.pl
> gs/toolbin/localcluster/comparerevs.pl
> gs/toolbin/localcluster/dashboard.html
> gs/toolbin/localcluster/nightly.pl
> gs/toolbin/localcluster/pngs2html.pl
> gs/toolbin/localcluster/readlog.pl
> gs/toolbin/localcluster/readme
> gs/toolbin/localcluster/run.pl
> gs/toolbin/localcluster/setupcluster
> gs/toolbin/localcluster/weekly.sh

2011-05-13 09:42:41 -0700
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
7dcc68ce753175a9c686021d53a061253e2787c3

> Modified math_.h to use our hypot().
> The system hypot() function gives slightly different results on Linux vs
> Mac OS X systems for same input values. This minor difference results
> in rendering variations in some files, confounding the regression
> test system.
> This revision changes math_.h to use our hypot() in all cases instead
> of the system one (previously our function was used on those platforms
> where there was no system hypot() function).
> Testing by Robin shows that our function is faster than the system one,
> so another reason to make this change.
> Fixes Bug 692197.
> Cluster differences on some nodes expected in:
> tests_private__pcl__pcl5ccet__28-10.BIN ppmraw
> tests_private__pcl__pcl5ccet__32-01.BIN pbmraw
> tests_private__pcl__pcl5cfts__fts.2210a pbmraw
> tests_private__pcl__pcl5efts__fts.1810 ppmraw
> tests_private__pcl__pcl5efts__fts.2132 pbmraw
> tests_private__pcl__pcl5efts__fts.2291 pbmraw
> tests_private__pcl__pcl5efts__fts.2350 pbmraw
> gs/base/math_.h

2011-05-13 09:33:29 +0000
Robin Watts <robin@ghostscript.com>
4bd5322f27e9b95716323bdd000e312418a59676

> Further tweak to lcms cached transforms.
> Use int comparisons rather than memcmp. No differences shown in cluster
> testing.
> gs/lcms/src/cmsxform.h

2011-05-12 23:14:47 +0000
Robin Watts <robin@ghostscript.com>
3767ee67758778d00c9c5c879ade41fc9f41c83b

> Simplify LCMS cached transform template.
> I'd overengineered the cached transform template code; the cache is
> reset on every format change, so there is no need to check for that
> in the transform function.
> No expected performance increase, but the code is less complex. No
> differences seen in cluster testing. CLUSTER_UNTESTED.
> gs/lcms/src/cmsxform.h

2011-05-12 17:57:55 +0100
Robin Watts <Robin.Watts@artifex.com>
8bcf5d9dd0c4088a811f85121addb238c9240478

> Add new lcms source/header file to ghostscript.vcproj.
> No cluster differences as this isn't tested. CLUSTER_UNTESTED.
> gs/ghostscript.vcproj

2011-05-12 16:06:08 +0000
Robin Watts <robin@ghostscript.com>
d324305b11fd0bb399c868fe87b26cb768dc06c5

> LCMS (v1) Optimisations for CachedXFORM etc.
> Optimise CachedXFORM (and related functions) by using a 'template' header
> file and repeatedly including it with different options to generate
> different specific versions of the code.
> This gives a 10% improvement on 568.40345_VO_nr_3_vpeSR18.xl (a file where
> most of the time is spent in clipping).
> No expected cluster differences. I've just done a full test with a bmpcmp
> and it showed no differences, but in light of what happened last time I
> committed this, I am not going to use the magic rune to stop the cluster
> rechecking it on commit.
> gs/base/lcms.mak
> gs/lcms/include/lcms.h
> gs/lcms/src/cmspack.c
> gs/lcms/src/cmsxform.c
> gs/lcms/src/cmsxform.h

2011-05-12 15:08:01 +0100
Robin Watts <Robin.Watts@artifex.com>
e79fff7a2b215103c795b74d4abe162bf8ca3486

> Change PSI so -Z! works by default in debug builds.
> Previously, the -Z! option (to show the name of each PS operator as it is
> executed) has only been available in DEBUG builds that specifically use
> the DEBUG_TRACE_PS_OPERATORS option. This change ensures that it is available
> in ALL debug builds, and in any release build where the
> DEBUG_TRACE_PS_OPERATORS symbol is predefined.
> The reason for historically having it as a separate option was because
> checking for whether the ! debug flag was set on every operator was felt
> to be too large an overhead. I have arranged the code so that this overhead
> is minimised now - in debug builds we only get the extra overhead when
> the -Z! is specified on the command line.
> In normal release builds there is no change to the overhead. In release
> builds with DEBUG_TRACE_PS_OPERATORS, the same overheads apply as in
> DEBUG builds (that is a small additional overhead when -Z! is not used
> and a larger one when it is).
> No cluster differences expected.
> gs/psi/iinit.c
> gs/psi/iinit.h
> gs/psi/interp.c

2011-05-11 15:39:06 -0600
Henry Stiles <henry.stiles@artifex.com>
7d77dabf5a1e24118455a5c0417ae75c5d5dcf60

> Fixes bug #689870 - add proper big endian number accessors.
> Previously only an unsigned accessor was provided and it was being
> used to read both signed and unsigned quantities.
> gs/jbig2dec/jbig2.c
> gs/jbig2dec/jbig2_halftone.c
> gs/jbig2dec/jbig2_page.c
> gs/jbig2dec/jbig2_priv.h
> gs/jbig2dec/jbig2_segment.c
> gs/jbig2dec/jbig2_symbol_dict.c
> gs/jbig2dec/jbig2_text.c

2011-05-11 15:18:11 -0600
Henry Stiles <henry.stiles@artifex.com>
7c309e8a33333da3c124732bb6b00b0701e85579

> Fixes 690889, potential null dereference.
> Prevent a theoretical (no test file) null dereference. There are
> several of these cases identified by by static analysis. We believe
> the authors intent was to pass the word stream if the arithmetic state
> was not set, as in the other call of the same function.
> gs/jbig2dec/jbig2_symbol_dict.c

2011-05-11 17:12:59 +0000
Robin Watts <robin@ghostscript.com>
2bde8dc655c36ef729964980aa373c26dbe873e5

> Backout 6469f73 pending investigation of unexpected differences.
> gs/base/lcms.mak
> gs/lcms/include/lcms.h
> gs/lcms/src/cmspack.c
> gs/lcms/src/cmsxform.c

2011-05-11 16:17:05 +0000
Robin Watts <robin@ghostscript.com>
6469f738123e0c212473f11d38e88bb3650a9087

> LCMS (v1) optimisations for CachedXFORM etc.
> Optimise CachedXFORM (and related functions) by using a 'template' header
> file and repeatedly including it with different options to generate
> different specific versions of the code.
> This gives a 10% improvement on 568.40345_VO_nr_3_vpeSR18.xl (a file where
> most of the time is spent in clipping).
> No expected cluster differences.
> gs/base/lcms.mak
> gs/lcms/include/lcms.h
> gs/lcms/src/cmspack.c
> gs/lcms/src/cmsxform.c
> gs/lcms/src/cmsxform.h

2011-05-02 19:50:04 +0100
Robin Watts <Robin.Watts@artifex.com>
1d07f53add51362ce5887b599f2dcb360f9cf348

> Pacify valgrind (and improve performance?) with tiny change.
> A tiny change to gxclrast.c where we initialise state_tile.size.{x,y}.
> This stops valgrind giving warnings. While the code works OK without
> this (I believe), it can cause various %, /, gcd operations. These are
> all expensive operations and are neatly sidestepped by the simple
> expedient of setting the variable to 0 to start with.
> gs/base/gxclrast.c

2011-05-10 19:29:49 +0100
Robin Watts <Robin.Watts@artifex.com>
f6f6de913f2f20914ed641a0331e405011d6565b

> Add LAND_BITS define to landscape mono halftoning code.
> The monochrome halftone thresholding code relies on collating incoming
> scanline data into 'scancolumn' buffers. When we have 16 bytes in these
> buffers, they halftoned and flushed through copy_mono.
> copy_mono would prefer to work with longer than 16 byte runs, so we
> remove the hardcoded 16s from throughout the code and replace it with
> a #defined value. A side effect of this is that the code becomes
> slightly clearer.
> Sadly, it seems this doesn't give the expected speedups; testing here
> indicates that both 32 and 128 run slower, possibly due to cache effects.
> Nonetheless we commit the code in case inspiration strikes us later on.
> No cluster differences expected.
> gs/base/gsiparam.h
> gs/base/gxht_thresh.c
> gs/base/gximono.c

2011-05-10 19:24:55 +0100
Robin Watts <Robin.Watts@artifex.com>
21cfb2e3b6c0d15c84b748586c51969daae58345

> LCMS performance tweak; ToFixedDomain/FromFixedDomain.
> Make ToFixedDomain/FromFixedDomains #defines rather than inline functions.
> MSVC doesn't inline them, and they are used in speed critical areas.
> No cluster differences expected.
> gs/lcms/include/lcms.h

2011-05-02 18:53:00 +0100
Robin Watts <Robin.Watts@artifex.com>
eef6a4d712a79a5f8d5f48f43c2572d5f002fc38

> Quiet valgrind warning, and remove misleading init.
> Cherry picked from patt_trans_clist branch to fix bug 692138.
> When run with valgrind on:
> gs -sDEVICE=pbmraw -r300 -dMaxBitmap=100000000 -o out.pbm Bug690189c.pdf
> Valgrind complains that params.GrayBackground is used without being
> initialised. We fix this here by amending gs_trans_mask_params_init.
> In so doing, we note that in zbegintransparencymaskgroup we were setting
> params.ColorSpace, only to call gs_trans_mask_params_init and have it
> overwrite it. To avoid confusion we therefore remove this needless init.
> No cluster differences seen in testing.
> gs/base/gstrans.c
> gs/psi/ztrans.c

2011-05-10 09:16:17 +0000
Robin Watts <robin@ghostscript.com>
b1cf87e28636a4922505e9c486b59e64c857717f

> Optimisations for mem_mono_strip_copy_rop_dev.
> Now that mem_mono_strip_copy_rop_dev is working reliably, cut out the
> excess debugging code so we can see the wood for the trees.
> To cope with situations where we get narrow texture tiles, reinstate the
> old code (as rop_run relies on longer runs to get traction). Add new cases
> for no-textures to avoid nested loops etc.
> This all seems to help with the performance of cicero_call.
> No cluster differences expected.
> gs/base/gdevm1.c

2011-05-10 08:39:19 +0000
Robin Watts <robin@ghostscript.com>
2429ef51f12477d083bfcd3f15f97f90bb653b52

> Optimisations to gximono.c; special case the spp_out == 1 case.
> Simple optimisations to the hotspots in image_render_mono_ht.
> No real differences seen in cluster testing.
> gs/base/gximono.c

2011-05-09 23:46:09 +0000
Robin Watts <robin@ghostscript.com>
bf8d753f7346c0c97bd4109f0684993ab0a46041

> New gxdda.h formulation.
> Rejig the gxdda macros slightly. We store more 'natural' values internally
> and get code that optimises slightly better.
> No differences expected in cluster testing (1 SEGV shown in my testing, but
> I think that's random).
> gs/base/gxdda.h
> gs/base/gxi12bit.c
> gs/base/sidscale.c

2011-05-10 00:21:21 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
0f5928344123e31229d31eb81e3f09b528170e38

> Execute linkdest procedure in a stopped context to trap errors caused
> by out-of-range link destinations that can occur in an invalid files or
> during processing of a page range. Bug 692200.
> gs/Resource/Init/pdf_main.ps

2011-05-09 14:47:48 -0600
Henry Stiles <henry.stiles@artifex.com>
df4e669177f7757a5c054084f4990599bef5c355

> Remove unused file should have been committed with e55d362f.
> gs/base/gsnorop.c

2011-05-09 13:16:31 -0600
Henry Stiles <henry.stiles@artifex.com>
e55d362f3370b4bff0d72dc58c4b7a08b0dba71a

> Incorporate raster operation library into the core graphics library.
> We were going to fold the roblib in for simplicity, more recently
> the graphics library code has been refactored such that the raster op
> library is always required. For example operations previously done in
> the copy_mono code are now done with the raster op code.
> CLUSTER_UNTESTED
> gs/base/Makefile.in
> gs/base/lib.mak
> gs/base/msvclib.mak
> gs/base/ugcclib.mak
> language_switch/pspcl6_gcc.mak
> language_switch/pspcl6_msvc.mak
> main/pcl6_gcc.mak
> main/pcl6_msvc.mak

2011-05-05 16:16:22 +0100
Chris Liddell <chris.liddell@artifex.com>
60d4b088c6d314079643a92a3c4e983b116600a9

> Use defined default page size for nullpage device.
> The nullpage device previously used a 1"x1" default page size, this changes it
> to use the same default setting as other page devices (this can be Letter or
> A4, set in a makefile).
> Also, add some lower bounds checking to gslp.ps so that it will error out if
> the page size is too small to hold at least one line of text.
> No cluster difference expected.
> gs/base/gdevnfwd.c
> gs/lib/gslp.ps

2011-05-08 11:26:15 -0700
Michael Vrhel <michael.vrhel@artifex.com>
c677c48f278aba56d45bf2601ed5d152287540f1

> Fix for compiler warning
> gs/base/gsdevice.c

2011-05-07 23:21:38 -0700
Michael Vrhel <michael.vrhel@artifex.com>
b1d311f06250a07d4c360e67369980d199722694

> Significant change in how the device profile is handled in ghostscript. This
> change adds in a new device procedure called get_profile, which is going to
> typically be set to gx_forward_get_profile or gx_default_get_profile. Most
> internal devices like the pattern accumulator, the clip device, memory devices,
> will use the gx_forward_get_profile procedure. In this way, the profile is
> typically only maintained by the the target device. The gdevp14 device is the significant internal device that takes special handling due to the way that it
> can change its ICC profile based upon the current transparency group color space. The get_profile procedure also passes along information about the object
> type so that we will be able to easily add in the device dependent color
> management. The rendering intent, which can also be object dependent is also returned by the call. This change has been cluster tested and showed no differences.
> gs/base/gdevbit.c
> gs/base/gdevdflt.c
> gs/base/gdevmem.c
> gs/base/gdevnfwd.c
> gs/base/gdevp14.c
> gs/base/gdevprn.c
> gs/base/gdevrops.c
> gs/base/gscms.h
> gs/base/gscsepr.c
> gs/base/gsdevice.c
> gs/base/gsequivc.c
> gs/base/gsicc.c
> gs/base/gsicc_cache.c
> gs/base/gstrans.c
> gs/base/gxccman.c
> gs/base/gxclip.c
> gs/base/gxclipm.c
> gs/base/gxclist.c
> gs/base/gxcmap.c
> gs/base/gxcmap.h
> gs/base/gxdevcli.h
> gs/base/gxdevice.h
> gs/base/gxi12bit.c
> gs/base/gxicolor.c
> gs/base/gximag3x.c
> gs/base/gximono.c
> gs/base/gxiscale.c
> gs/base/gxpcmap.c
> gs/contrib/opvp/gdevopvp.c

2011-05-06 08:57:07 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
a065765cd3529d17ba687954d8f4deacd8319247

> Add a missing check of the return value from runarg(). Bug 692189.
> gs/psi/imainarg.c

2011-05-06 01:13:51 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
2822d8a9f4186aa14f3913258841b74ff87309cf

> Check the type of /File and /Length attributes during XForm identification
> to avoud confusion with appearance subdictionary, which can include any
> attributes (including /File or /Length) pointing to a dictionary. Bug 692192.
> gs/Resource/Init/pdf_draw.ps

2011-05-04 15:38:22 +0000
Robin Watts <robin@ghostscript.com>
2756e4d6160f73af7bf5ed913af207914aeee588

> Invert bmpcmps reading of cups files.
> I had black <-> white. Easy fix.
> gs/toolbin/bmpcmp.c

2011-05-04 15:08:36 +0100
Robin Watts <Robin.Watts@artifex.com>
e97bf09450c5a08b591e0fca4ef59a21fb78b6ef

> Fix bmpcmp to read cups colorspace=0 files too.
> CLUSTER_UNTESTED.
> gs/toolbin/bmpcmp.c

2011-05-04 00:45:28 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
2f0b609805f1abf42b4b10dd721d9fef3001a847

> Accept and skip any number of whitespace characters (including
> just spaces) after the entry count in the xref table. Remove /lineeq
> and /linene procedures that are no longer used. Bug 692177.
> gs/Resource/Init/pdf_main.ps

2011-05-03 08:58:18 -0600
Henry Stiles <henry.stiles@artifex.com>
af70515f6dcd1ffae90250697325fee224182e17

> Retain or bias the reference count of the rop texture device.
> The image code was using the rop texture device without any reference
> counting, explicitly freeing the device when it was done. That was
> fine if the device was the only device in the chain, however, linking
> in other devices could lead indirectly to unintended freeing of the
> rop device. A crash was seen in the the XL test file C705.BIN but
> only with halftoning at particular resolutions like 72 dpi. We did
> not study why the crash was limited to particular resolutions and
> devices.
> gs/base/gxipixel.c

2011-05-03 17:45:45 +0100
Robin Watts <Robin.Watts@artifex.com>
afcbace446526e29bae11ce53bac5769a409e56f

> Add gx_device_dump debugging function.
> In DEBUG builds gx_device_dump(gx_device *dev, char *text); prints a
> recursive listing of devices, their refcounts and names, and targets.
> If anyone spots a forwarding device this doesn't work with, please let me
> know.
> No cluster differences expected.
> gs/base/gdevnfwd.c
> gs/base/gdevp14.c
> gs/base/gxdevcli.h
> gs/base/gxdevsop.h

2011-05-03 16:39:13 +0000
Robin Watts <robin@ghostscript.com>
6d5e2bde4fe7a42bdd631fb0756f4fafc460ec41

> Fix copy_plane; was always copying into plane 0.
> When writing copy_plane, I had neglected to offset into the data
> according to the plane required.
> CLUSTER_UNTESTED.
> gs/base/gdevmpla.c

2011-05-02 14:51:26 +0100
Robin Watts <Robin.Watts@artifex.com>
a78476dd0be85f69885f2614be5ab614b03c9168

> Add support for cups (1bpp) files to bmpcmp.
> gs/toolbin/bmpcmp.c

2011-05-02 20:41:12 +0100
Robin Watts <Robin.Watts@artifex.com>
cc3562ce331bc45a89cebd49c91e10149b5a90b2

> Solve windows debug build crash on exit with cups device.
> It seems that the cups device takes it upon itself to close the output file
> rather than leaving it for the ghostscript core to close as every other
> device does. This upsets the windows DLL file handling.
> The solution is simply to remove the lines that close the file. I've
> checked both with Till and Ken, and they concur. Thanks.
> No cluster differences expected.
> gs/cups/gdevcups.c

2011-05-02 14:32:18 +0100
Chris Liddell <chris.liddell@artifex.com>
e784a5443d0bee380d1ad32055ad3075e3aa0995

> Change error return to remove confusion over meaning.
> When we encounter a font whose charstring has been replaced with a PS
> procedure, we were returning FT_Err_Invalid_File_Format, and using that
> as a hint we should try to execute it as a PS procedure. This
> turns out to be problematic as it is also the error return generated by
> Freetype for an invalid charstring. In the case of an invalid charstring
> we should fall back to the notdef, not attempt to execute the object as
> Postscript.
> So, change the error return value that *we* generate, and subsequently
> check for, to FT_Err_Unknown_File_Format, which FT should never,
> normally, generate during glyph interpretation. This means, in this
> case, we correctly identify a failed attempt to interpret a charstring,
> and use the notdef fallback - instead of, eventually, throwing an
> error.
> Bug 692176.
> No cluster differences expected.
> gs/psi/fapi_ft.c

2011-04-30 19:01:53 +0100
Robin Watts <Robin.Watts@artifex.com>
5091054103f3b07bbae8ab2fc75e6c6cc3fd7a86

> Remove unused variable.
> gs/base/gdevpng.c

2011-04-30 18:11:47 +0100
Robin Watts <Robin.Watts@artifex.com>
dcae57315a683272c799545783694c43545b6fe0

> Fix PNG device error when no downscale specified.
> When I introduced the downscaling to selected png devices, I neglected to
> set a sensible default value for downscale factor. This means that if you
> attempt to set any device parameters, without specifying -dDownScaleFactor
> then you get a rangecheck error. This commit fixes that.
> No cluster changes expected.
> gs/base/gdevpng.c

2011-04-30 08:38:31 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
c98ade33d2b8fbc0ca6579c6d9e0ceb425374b0c

> Normalize pattern /BBox in PDF interpreter before passing it to PS
> to avoid a /rangecheck error. Bug 692174.
> gs/Resource/Init/pdf_draw.ps

2011-04-27 22:27:39 -0700
Michael Vrhel <michael.vrhel@artifex.com>
b128a1424550b3462348bd40ecd768356cdb08ae

> Fix for reference counting issue of the compositor device at
> the end of the clist playback. In most cases, the compositor rc
> should be 1 at this point and so the device is closed and then
> freed. The case, when it is not 1 is when we have a pattern
> that has a transparency and is stored in a clist. In this case
> the target for the pattern clist device is the main pdf14 device and
> we increment the rc during this assignment. So, when the
> playback completes, the rc of the compositor is 2. We do not
> want to close and free the compositor, since it is part of the
> main clist that we have going on. Instead we only want to
> decrement the rc. The test file pattrans_big.pdf is now
> handled correctly but has a rendering/tiling issue it appears.
> This commit (from the patt_trans_clist_branch) has been cherry-picked
> to the trunk to solve the SEGV in bug #692160. This leaves pdf14
> compositors leaking though.
> gs/base/gxclrast.c

2011-04-28 20:23:29 +0100
Robin Watts <Robin.Watts@artifex.com>
1553ea878b414b4ac389f7cec4c2076bc52be966

> Stop compiler turning for loop into memset in halftoning code.
> The msvc compiler cleverly spots that a for loop can be turned
> into a memset. Unfortunately it can't know that the values for
> which the loop is called are normally so small that the calling
> of the function costs more than simply doing the stores.
> The fix is to cast the pointer to which we are storing to be
> volatile. This saves a significant chunk of runtime for:
> pcl6.exe -sDEVICE=bit -r600 -o null: -dLeadingEdge=3
> cicero_call_CRF03-all-in_adobe-8_358p_xNuv288.xl
> No cluster differences expected.
> gs/base/gxht_thresh.c

2011-04-28 17:19:14 +0100
Chris Liddell <chris.liddell@artifex.com>
dd0ead1acfd2cf2fea4e417afdd4b52b06d8c3ad

> Ensure optimization flags get propogated for lcms
> An inconcistency between definitions in the Unix and Windows builds meant
> that on Windows several compiler flags (including that for optimization)
> was not being used when buliding the lcms source files. The confusion
> stems from Ghostscript requiring /Za to compile, and lcms failing to
> compile with /Za.
> Bug 692173.
> No cluster differences expected.
> gs/base/msvccmd.mak

2011-04-28 16:20:38 +0100
Robin Watts <Robin.Watts@artifex.com>
98a891175a74e4fdbdd2b5dc10a7fa60b9f75e16

> Add special case runrops for rops 0xF0 and CC (copy S and copy T).
> This is in response to Norberts complaints about the speed of 9.02 with
> cicero_call_CRF03-all-in_adobe-8_358p_xNuv288.xl and others.
> gs/base/gsroprun.c

2011-04-28 09:01:05 +0100
Chris Liddell <chris.liddell@artifex.com>
26e55117205eaf76dfa6011c29e287f84ec99799

> Change to include psi/ierrors.h.
> psitop.c previously included the deprecated header file base/errors.h
> which has now been removed. psi/ierrors.h is the correct header to
> include.
> No cluster differences expected.
> psi/psitop.c

2011-04-28 08:10:39 +0100
Chris Liddell <chris.liddell@artifex.com>
7132af8bb76824feb241374cf152349995b6cc10

> Remove the deprecated errors.h file.
> Related to Bug 692151 in that it rendered the bug invalid.
> No cluster differences expected.
> gs/base/errors.h

2011-04-25 18:58:52 -0600
Henry Stiles <henry.stiles@artifex.com>
0361e41b57f8f4d798eb42e6320e6e96c355169d

> PJL filesystem commands can be made static.
> Warning cleanup - make local functions static.
> Use %s if the argument is not literal to address the warning "format
> not a string literal and no format arguments".
> Presumably a format specifier could appear in the character array
> resulting in an argument mismatch.
> pl/pjparse.c
> pl/pjparsei.c
> pl/plmain.c
> pxl/pxtop.c

2011-04-25 17:53:50 -0600
Henry Stiles <henry.stiles@artifex.com>
732dc98f92f2132f21811cf8b2612c1091e65050

> Partially refactor image api so it can be shared between pcl and pxl,
> also to move away from using the obsolete image api.
> pl/pldraw.c
> pl/pldraw.h
> pxl/pximage.c
> pxl/pxink.c

2011-04-26 19:20:25 +0100
Robin Watts <Robin.Watts@artifex.com>
262c866a71d08c1709484d95ffb3639f53156078

> Fix for bug 692081. Antialiasing patterns results in white holes.
> gx_default_copy_alpha simulates alpha by weighted average of RGB values.
> When the alpha value is zero, the current implementation reads the current
> background value, and just writes it back. This has the effect of making
> any device that watches what devices get written to think that that pixel
> is solid. (One such device is the pattern tile device where it collects what
> pixels have been marked, and what haven't).
> The CORRECT way to do this is to stop the line accumulation at that point,
> flush everything to there, then start again a pixel later.
> Doing this solves the bug, and causes no cluster changes.
> gs/base/gdevdbit.c
> gs/base/gxcindex.h

2011-04-26 12:37:14 +0100
Robin Watts <Robin.Watts@artifex.com>
11b5fb512393a6e9d9bdf6c076dc388ebd8c7c3f

> Fix warnings (unused variables and missing cases in switches).
> gs/base/gdevddrw.c
> gs/base/gstrans.c
> gs/base/gxblend1.c
> gs/base/gxiscale.c
> gs/base/gxstroke.c
> gs/psi/zicc.c

2011-04-26 10:34:46 +0100
Robin Watts <Robin.Watts@artifex.com>
a349c53ca01df5e425f25d1fa14d38c43d95b60c

> Removed unused variables to quiet warnings.
> gs/base/gdevtifs.c
> gs/base/gxdownscale.c

2011-04-25 22:56:41 -0700
Michael Vrhel <michael.vrhel@artifex.com>
79e14a10307ba37bcf00af1b05c1c52875d9774a

> Fix for multithreaded rendering crash that can occur due to race conditions between threads with the increment and decrement of the icc link cache object during the rendering of the bands. Fix involved place a lock around the operations. Thanks to Ray for helping with this.
> gs/base/gxclrast.c
> gs/base/gxclthrd.c

2011-04-25 17:37:09 -0700
Michael Vrhel <michael.vrhel@artifex.com>
03cb94a9da2cddd2b7055e8565dd797c67bf56f4

> Fix for memory leak in gdevp14 device. This involved making sure the overprint compositor was initialized retained with a ref count of 1 like the pdf14 device.
> gs/base/gsovrc.c
> gs/base/gxclrast.c

2011-04-26 00:53:07 +0100
Robin Watts <Robin.Watts@artifex.com>
16789dc892db636719383c2542aa9cec04092e4d

> Fix memory overwrite in png devices.
> In my fiddling with the png devices the other day to add downscaling, I
> omitted to extend the size of two of them (png16m and png48). This meant
> that png16m was overwriting 8 bytes of memory after its device structure.
> Fix this to solve a SEGV when DownScaleFactor is used.
> gs/base/gdevpng.c

2011-04-24 20:35:45 -0400
Alex Cherepanov <alex.cherepanov@artifex.com>
f5a6de969ae67a2318115c5e8e6e2b3b06fc58f3

> Split large beginbfrange..endbfrange blocks in ToUnicode CMaps into
> speed up operand stack manipulation, esp. "counttomark -3 roll". Bug 691908.
> gs/Resource/Init/pdf_font.ps

2011-04-25 09:31:32 -0600
Henry Stiles <henry.stiles@artifex.com>
3b66709cafd05910f2442250e12d1918f239c34b

> The new custom paper size implementation introduced a bug in
> passthrough mode requiring additional state setup when we switch from
> PXL to PCL state.
> pcl/pcpage.c
> pxl/pxpthr.c

2011-04-22 15:40:50 -0600
henrys <henry.stiles@artifex.com>
460ff495a31f8a87d0ed677eed2660fca79369fc

> Revision 43a5362 modified a global variable. We address that by
> making the page table a dynamic member of the pcl state.
> pcl/pcommand.c
> pcl/pcpage.c
> pcl/pcstate.h
> pcl/pcxfmst.h

2011-04-20 23:25:50 -0600
henrys <henry.stiles@artifex.com>
e5a9f968265abc47a85811e620c79bedf87b1da0

> Josef Hinteregger's patch to implement custom paper sizes in PJL and PCL,
> bug #691587.
> pcl/pcpage.c
> pl/pjparse.c

2011-04-20 23:20:34 -0700
Michael Vrhel <michael.vrhel@artifex.com>
4ddefa258ee17e359429c901ef8a0a8f3b234083

> Fix to stop reset of ICC profile directory to the default directory (which is the romfs) when there is a VMreclaim. Previously if the VMreclaim happens while we are still in the process of initializing the icc manager this can cause a crash. This was the source of the crash with the tiffsep device when COMPILE_INITS=0.
> gs/base/gsicc_manage.c

2011-04-22 18:08:10 +0100
Robin Watts <Robin.Watts@artifex.com>
1b3908faa01c7ef6197374a27b1a5861f0a383fe

> Extend downscaling to png devices too (from tiffscaled).
> Extract the code to do downscaling/min feature size from tiffscaled{,8,24}
> into a new gx_downscaler class. Make tiffscaled{,8,24} call this new class
> with no change in functionality.
> Make png devices call this new code. Only png16m and pnggray are actually
> affected by downscaling though. Add a new pngmonod device to do grayscale
> rendering internally and to downscale/min_feature_size/error diffuse to
> monochrome.
> gs/base/devs.mak
> gs/base/gdevpng.c
> gs/base/gdevprn.c
> gs/base/gdevtifs.c
> gs/base/gxdownscale.c
> gs/base/gxdownscale.h
> gs/base/lib.mak
> gs/base/macos-mcp.mak
> gs/base/macosx.mak
> gs/base/openvms.mak
> gs/base/unix-gcc.mak
> gs/base/unixansi.mak
> gs/doc/Devices.htm
> gs/ghostscript.vcproj
> gs/psi/msvc.mak
> gs/psi/os2.mak
> main/pcl6_gcc.mak
> main/pcl6_msvc.mak

2011-04-20 10:40:58 -0700
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
8a203b909d59f8aa649492c23fa570afe3a61565

> Revert of a4c4877b35b6782ef64b382713eaa6bcd4eca8d6 since we decided to rename the directories back to their before svn => git transition names.
> gs/toolbin/localcluster/clusterpush.pl

2011-04-20 09:17:25 -0700
mvrhel <michael.vrhel@artifex.com>
20b6c78ff6fb123bc11a068ca329a96d2452b529

> Fix for issue when creating ICC profiles from DEF/G structures. As a few progressions and fixes bug 692156 and likely bug 691977
> gs/base/gsicc_create.c

2011-04-19 21:23:01 -0700
Marcos H. Woehrmann <marcos.woehrmann@artifex.com>
a4c4877b35b6782ef64b382713eaa6bcd4eca8d6

> Modified clusterpush.pl to account for the new directory structure introduced with the svn => git transition.
> gs/toolbin/localcluster/clusterpush.pl

2011-04-20 14:56:12 +0100
Robin Watts <Robin.Watts@artifex.com>
0f57eacebce435c7da518b2d17638036a3ae5a40

> Add bin directories to .gitignore file.
> Also add some comments with useful lines that people might want to copy
> to their local .git/info/exclude file.
> .gitignore

2011-04-20 14:46:26 +0100
Robin Watts <Robin.Watts@artifex.com>
c10532c1b2e63dd6d6d95f1a0b578eb865ff4d9a

> New tiffscaled8 and tiffscaled24 devices.
> Add new tiffscaled8 and tiffscaled24 devices, copied and modified from
> tiffscaled. These output greyscale and 24bit rgb instead of tiffscaleds
> mono output. MinFeatureSize is ignored for these devices as it's meaningless
> for contone output.
> Error Diffusion is still done, but is almost certainly a waste of time - it
> was just simpler to make the code work this way. If performance is an issue,
> we can remove that later.
> gs/base/configure.ac
> gs/base/devs.mak
> gs/base/gdevtifs.c
> gs/base/gdevtifs.h
> gs/base/gdevtsep.c
> gs/base/macos-mcp.mak
> gs/base/openvms.mak
> gs/base/unix-gcc.mak
> gs/base/unixansi.mak
> gs/doc/Devices.htm
> gs/psi/msvc.mak
> main/pcl6_gcc.mak
> main/pcl6_msvc.mak

2011-04-20 00:00:45 +0200
Tor Andersson
f6e8c8d24c4a2f66b45ce04ab544aaf8b305a0d1

> Change GS_PRODUCTFAMILY to say GIT instead of SVN PRERELEASE.
> gs/base/gscdef.c

2011-04-19 23:58:23 +0200
Tor Andersson
c91007a224a533fb7582646d98b6bf1721f4f297

> Clean up file permissions.
> COPYING.AFPL
> gs/examples/golfer.eps
> gs/examples/tiger.eps
> gs/ghostscript-ufst.vcproj
> gs/ghostscript.vcproj
> gs/psi/winint.mak
> tools/Acrobat2Tiff/Acrobat2Tiff.sln
> tools/Acrobat2Tiff/Acrobat2Tiff/Acrobat2Tiff.vb
> tools/Acrobat2Tiff/Acrobat2Tiff/Acrobat2Tiff.vbproj
> tools/Acrobat2Tiff/Acrobat2Tiff/Acrobat2Tiff/Application.Designer.vb
> tools/Acrobat2Tiff/Acrobat2Tiff/Acrobat2Tiff/Application.myapp
> tools/Acrobat2Tiff/Acrobat2Tiff/Acrobat2Tiff/AssemblyInfo.vb
> tools/Acrobat2Tiff/Acrobat2Tiff/Acrobat2Tiff/Resources.Designer.vb
> tools/Acrobat2Tiff/Acrobat2Tiff/Acrobat2Tiff/Resources.resx
> tools/Acrobat2Tiff/Acrobat2Tiff/Acrobat2Tiff/Settings.Designer.vb
> tools/Acrobat2Tiff/Acrobat2Tiff/Acrobat2Tiff/Settings.settings
> tools/Acrobat2Tiff/Acrobat2Tiff/bin/Release/Acrobat2Tiff.xml
> tools/Acrobat2Tiff/Acrobat2Tiff/bin/Release/Interop.Acrobat.dll
> tools/cmpi/cmpi.bkl
> tools/cmpi/cmpi.cpp
> tools/cmpi/cmpi.dsp
> tools/cmpi/cmpi.dsw
> tools/cmpi/cmpi.pro
> tools/cmpi/cmpi.rc
> tools/cmpi/cmpi.sln
> tools/cmpi/cmpi.suo
> tools/cmpi/cmpi.vcp
> tools/cmpi/cmpi.vcproj
> tools/cmpi/cmpi.vcw
> tools/cmpi/descrip.mms
> tools/cmpi/makefile.bcc
> tools/cmpi/makefile.dmc
> tools/cmpi/makefile.dms
> tools/cmpi/makefile.dos
> tools/cmpi/makefile.gcc
> tools/cmpi/makefile.sc
> tools/cmpi/makefile.unx
> tools/cmpi/makefile.va
> tools/cmpi/makefile.vc
> tools/cmpi/makefile.wat
> tools/tiger.svg
> tools/xps2tiff/README
> tools/xps2tiff/xps2tiff.sln
> tools/xps2tiff/xps2tiff/AssemblyInfo.cpp
> tools/xps2tiff/xps2tiff/stdafx.cpp
> tools/xps2tiff/xps2tiff/xps2tiff.cpp
> tools/xps2tiff/xps2tiff/xps2tiff.vcproj
> win32/GhostPDL.sln
> win32/ReadMe.txt
> win32/language_switch.vcproj
> win32/pcl.vcproj
> win32/svg.vcproj
> win32/xps.vcproj

2011-04-19 23:49:56 +0200
Tor Andersson
781969994b5381ba4bed03beef217f9bde6e7c58

> Indent with spaces and strip trailing whitespace.
> gs/Resource/Init/gs_agl.ps
> gs/Resource/Init/gs_btokn.ps
> gs/Resource/Init/gs_cet.ps
> gs/Resource/Init/gs_cff.ps
> gs/Resource/Init/gs_cidcm.ps
> gs/Resource/Init/gs_ciddc.ps
> gs/Resource/Init/gs_cidfm.ps
> gs/Resource/Init/gs_cidfn.ps
> gs/Resource/Init/gs_cidtt.ps
> gs/Resource/Init/gs_cmap.ps
> gs/Resource/Init/gs_cspace.ps
> gs/Resource/Init/gs_css_e.ps
> gs/Resource/Init/gs_dbt_e.ps
> gs/Resource/Init/gs_diskf.ps
> gs/Resource/Init/gs_diskn.ps
> gs/Resource/Init/gs_dpnxt.ps
> gs/Resource/Init/gs_dps.ps
> gs/Resource/Init/gs_dps1.ps
> gs/Resource/Init/gs_dps2.ps
> gs/Resource/Init/gs_dscp.ps
> gs/Resource/Init/gs_epsf.ps
> gs/Resource/Init/gs_fapi.ps
> gs/Resource/Init/gs_fntem.ps
> gs/Resource/Init/gs_fonts.ps
> gs/Resource/Init/gs_frsd.ps
> gs/Resource/Init/gs_icc.ps
> gs/Resource/Init/gs_il1_e.ps
> gs/Resource/Init/gs_img.ps
> gs/Resource/Init/gs_init.ps
> gs/Resource/Init/gs_l2img.ps
> gs/Resource/Init/gs_lev2.ps
> gs/Resource/Init/gs_ll3.ps
> gs/Resource/Init/gs_mex_e.ps
> gs/Resource/Init/gs_mgl_e.ps
> gs/Resource/Init/gs_mro_e.ps
> gs/Resource/Init/gs_pdf_e.ps
> gs/Resource/Init/gs_pdfwr.ps
> gs/Resource/Init/gs_res.ps
> gs/Resource/Init/gs_resmp.ps
> gs/Resource/Init/gs_setpd.ps
> gs/Resource/Init/gs_statd.ps
> gs/Resource/Init/gs_std_e.ps
> gs/Resource/Init/gs_sym_e.ps
> gs/Resource/Init/gs_trap.ps
> gs/Resource/Init/gs_ttf.ps
> gs/Resource/Init/gs_typ32.ps
> gs/Resource/Init/gs_typ42.ps
> gs/Resource/Init/gs_type1.ps
> gs/Resource/Init/gs_wan_e.ps
> gs/Resource/Init/pdf_base.ps
> gs/Resource/Init/pdf_cslayer.ps
> gs/Resource/Init/pdf_draw.ps
> gs/Resource/Init/pdf_font.ps
> gs/Resource/Init/pdf_main.ps
> gs/Resource/Init/pdf_ops.ps
> gs/Resource/Init/pdf_rbld.ps
> gs/Resource/Init/pdf_sec.ps
> gs/base/ConvertUTF.c
> gs/base/ConvertUTF.h
> gs/base/aes.c
> gs/base/aes.h
> gs/base/assert_.h
> gs/base/ctype_.h
> gs/base/dirent_.h
> gs/base/dos_.h
> gs/base/echogs.c
> gs/base/errno_.h
> gs/base/errors.h
> gs/base/fcntl_.h
> gs/base/gconf.c
> gs/base/gconf.h
> gs/base/gdebug.h
> gs/base/gdev3852.c
> gs/base/gdev3b1.c
> gs/base/gdev4081.c
> gs/base/gdev4693.c
> gs/base/gdev8510.c
> gs/base/gdev8bcm.c
> gs/base/gdev8bcm.h
> gs/base/gdevabuf.c
> gs/base/gdevadmp.c
> gs/base/gdevatx.c
> gs/base/gdevbbox.c
> gs/base/gdevbbox.h
> gs/base/gdevbit.c
> gs/base/gdevbj10.c
> gs/base/gdevbjc.h
> gs/base/gdevbjcl.c
> gs/base/gdevbjcl.h
> gs/base/gdevbmp.c
> gs/base/gdevbmp.h
> gs/base/gdevbmpa.c
> gs/base/gdevbmpc.c
> gs/base/gdevccr.c
> gs/base/gdevcdj.c
> gs/base/gdevcfax.c
> gs/base/gdevcgm.c
> gs/base/gdevcgml.c
> gs/base/gdevcgml.h
> gs/base/gdevcgmx.h
> gs/base/gdevcif.c
> gs/base/gdevclj.c
> gs/base/gdevcljc.c
> gs/base/gdevcp50.c
> gs/base/gdevcslw.c
> gs/base/gdevdbit.c
> gs/base/gdevdcrd.c
> gs/base/gdevdcrd.h
> gs/base/gdevddrw.c
> gs/base/gdevddrw.h
> gs/base/gdevdevn.c
> gs/base/gdevdevn.h
> gs/base/gdevdfax.c
> gs/base/gdevdflt.c
> gs/base/gdevdgbr.c
> gs/base/gdevdjet.c
> gs/base/gdevdjtc.c
> gs/base/gdevdljm.c
> gs/base/gdevdljm.h
> gs/base/gdevdm24.c
> gs/base/gdevdsha.c
> gs/base/gdevdsp.c
> gs/base/gdevdsp.h
> gs/base/gdevdsp2.h
> gs/base/gdevemap.c
> gs/base/gdevepsc.c
> gs/base/gdevepsn.c
> gs/base/gdevescp.c
> gs/base/gdevevga.c
> gs/base/gdevfax.c
> gs/base/gdevfax.h
> gs/base/gdevherc.c
> gs/base/gdevhit.c
> gs/base/gdevhl7x.c
> gs/base/gdevifno.c
> gs/base/gdevijs.c
> gs/base/gdevimdi.c
> gs/base/gdevimgn.c
> gs/base/gdevjbig2.c
> gs/base/gdevjpeg.c
> gs/base/gdevjpx.c
> gs/base/gdevl256.c
> gs/base/gdevl31s.c
> gs/base/gdevlbp8.c
> gs/base/gdevlj56.c
> gs/base/gdevlp8k.c
> gs/base/gdevlxm.c
> gs/base/gdevm1.c
> gs/base/gdevm16.c
> gs/base/gdevm2.c
> gs/base/gdevm24.c
> gs/base/gdevm32.c
> gs/base/gdevm4.c
> gs/base/gdevm40.c
> gs/base/gdevm48.c
> gs/base/gdevm56.c
> gs/base/gdevm64.c
> gs/base/gdevmac.c
> gs/base/gdevmac.h
> gs/base/gdevmacpictop.h
> gs/base/gdevmacttf.h
> gs/base/gdevmacxf.c
> gs/base/gdevmeds.c
> gs/base/gdevmeds.h
> gs/base/gdevmem.c
> gs/base/gdevmem.h
> gs/base/gdevmgr.c
> gs/base/gdevmgr.h
> gs/base/gdevmiff.c
> gs/base/gdevmpla.h
> gs/base/gdevmr1.c
> gs/base/gdevmr2n.c
> gs/base/gdevmrop.h
> gs/base/gdevmrun.c
> gs/base/gdevmrun.h
> gs/base/gdevmswn.c
> gs/base/gdevmswn.h
> gs/base/gdevmsxf.c
> gs/base/gdevn533.c
> gs/base/gdevnfwd.c
> gs/base/gdevo182.c
> gs/base/gdevokii.c
> gs/base/gdevos2p.c
> gs/base/gdevp14.c
> gs/base/gdevp14.h
> gs/base/gdevp2up.c
> gs/base/gdevpbm.c
> gs/base/gdevpccm.c
> gs/base/gdevpccm.h
> gs/base/gdevpcfb.c
> gs/base/gdevpcfb.h
> gs/base/gdevpcl.c
> gs/base/gdevpcl.h
> gs/base/gdevpcx.c
> gs/base/gdevpdf.c
> gs/base/gdevpdfb.c
> gs/base/gdevpdfb.h
> gs/base/gdevpdfc.c
> gs/base/gdevpdfc.h
> gs/base/gdevpdfd.c
> gs/base/gdevpdfe.c
> gs/base/gdevpdfg.c
> gs/base/gdevpdfg.h
> gs/base/gdevpdfi.c
> gs/base/gdevpdfj.c
> gs/base/gdevpdfk.c
> gs/base/gdevpdfm.c
> gs/base/gdevpdfo.c
> gs/base/gdevpdfo.h
> gs/base/gdevpdfp.c
> gs/base/gdevpdfr.c
> gs/base/gdevpdft.c
> gs/base/gdevpdfu.c
> gs/base/gdevpdfv.c
> gs/base/gdevpdfx.h
> gs/base/gdevpdt.c
> gs/base/gdevpdt.h
> gs/base/gdevpdtb.c
> gs/base/gdevpdtb.h
> gs/base/gdevpdtc.c
> gs/base/gdevpdtd.c
> gs/base/gdevpdtd.h
> gs/base/gdevpdte.c
> gs/base/gdevpdtf.c
> gs/base/gdevpdtf.h
> gs/base/gdevpdti.c
> gs/base/gdevpdti.h
> gs/base/gdevpdts.c
> gs/base/gdevpdts.h
> gs/base/gdevpdtt.c
> gs/base/gdevpdtt.h
> gs/base/gdevpdtv.c
> gs/base/gdevpdtv.h
> gs/base/gdevpdtw.c
> gs/base/gdevpdtw.h
> gs/base/gdevpdtx.h
> gs/base/gdevpe.c
> gs/base/gdevperm.c
> gs/base/gdevphex.c
> gs/base/gdevpipe.c
> gs/base/gdevpjet.c
> gs/base/gdevplib.c
> gs/base/gdevplnx.c
> gs/base/gdevplnx.h
> gs/base/gdevpm.h
> gs/base/gdevpng.c
> gs/base/gdevppla.c
> gs/base/gdevppla.h
> gs/base/gdevprn.c
> gs/base/gdevprn.h
> gs/base/gdevprna.c
> gs/base/gdevprna.h
> gs/base/gdevps.c
> gs/base/gdevpsd.c
> gs/base/gdevpsdf.h
> gs/base/gdevpsdi.c
> gs/base/gdevpsdp.c
> gs/base/gdevpsds.c
> gs/base/gdevpsds.h
> gs/base/gdevpsdu.c
> gs/base/gdevpsf.h
> gs/base/gdevpsf1.c
> gs/base/gdevpsf2.c
> gs/base/gdevpsfm.c
> gs/base/gdevpsft.c
> gs/base/gdevpsfu.c
> gs/base/gdevpsfx.c
> gs/base/gdevpsim.c
> gs/base/gdevpsu.c
> gs/base/gdevpsu.h
> gs/base/gdevpx.c
> gs/base/gdevpxen.h
> gs/base/gdevpxop.h
> gs/base/gdevpxut.c
> gs/base/gdevpxut.h
> gs/base/gdevrinkj.c
> gs/base/gdevrops.c
> gs/base/gdevs3ga.c
> gs/base/gdevsco.c
> gs/base/gdevsgi.c
> gs/base/gdevsgi.h
> gs/base/gdevsj48.c
> gs/base/gdevsnfb.c
> gs/base/gdevsppr.c
> gs/base/gdevstc.c
> gs/base/gdevstc.h
> gs/base/gdevstc1.c
> gs/base/gdevstc2.c
> gs/base/gdevstc3.c
> gs/base/gdevstc4.c
> gs/base/gdevsun.c
> gs/base/gdevsunr.c
> gs/base/gdevsvg.c
> gs/base/gdevsvga.c
> gs/base/gdevsvga.h
> gs/base/gdevtfax.c
> gs/base/gdevtfax.h
> gs/base/gdevtfnx.c
> gs/base/gdevtifs.c
> gs/base/gdevtifs.h
> gs/base/gdevtknk.c
> gs/base/gdevtrac.c
> gs/base/gdevtsep.c
> gs/base/gdevtxtw.c
> gs/base/gdevupd.c
> gs/base/gdevvec.c
> gs/base/gdevvec.h
> gs/base/gdevvglb.c
> gs/base/gdevwddb.c
> gs/base/gdevwdib.c
> gs/base/gdevwpr2.c
> gs/base/gdevwprn.c
> gs/base/gdevwts.c
> gs/base/gdevx.c
> gs/base/gdevx.h
> gs/base/gdevxalt.c
> gs/base/gdevxcf.c
> gs/base/gdevxcmp.c
> gs/base/gdevxcmp.h
> gs/base/gdevxini.c
> gs/base/gdevxres.c
> gs/base/gdevxxf.c
> gs/base/genarch.c
> gs/base/genconf.c
> gs/base/gendev.c
> gs/base/genht.c
> gs/base/gp.h
> gs/base/gp_dosfe.c
> gs/base/gp_dosfs.c
> gs/base/gp_dvx.c
> gs/base/gp_getnv.c
> gs/base/gp_mac.c
> gs/base/gp_mac.h
> gs/base/gp_macio.c
> gs/base/gp_macpoll.c
> gs/base/gp_mktmp.c
> gs/base/gp_msdll.c
> gs/base/gp_msdos.c
> gs/base/gp_mshdl.c
> gs/base/gp_mslib.c
> gs/base/gp_mspol.c
> gs/base/gp_msprn.c
> gs/base/gp_mswin.c
> gs/base/gp_mswin.h
> gs/base/gp_nsync.c
> gs/base/gp_ntfs.c
> gs/base/gp_os2.c
> gs/base/gp_os2.h
> gs/base/gp_os2fs.c
> gs/base/gp_os2pr.c
> gs/base/gp_os9.c
> gs/base/gp_paper.c
> gs/base/gp_psync.c
> gs/base/gp_stdia.c
> gs/base/gp_stdin.c
> gs/base/gp_strdl.c
> gs/base/gp_sysv.c
> gs/base/gp_unix.c
> gs/base/gp_unix_cache.c
> gs/base/gp_upapr.c
> gs/base/gp_vms.c
> gs/base/gp_wgetv.c
> gs/base/gp_win32.c
> gs/base/gp_wpapr.c
> gs/base/gp_wsync.c
> gs/base/gpcheck.h
> gs/base/gpgetenv.h
> gs/base/gpmisc.c
> gs/base/gpmisc.h
> gs/base/gs_agl.h
> gs/base/gs_dll_call.h
> gs/base/gs_mgl_e.h
> gs/base/gs_mro_e.h
> gs/base/gsalloc.c
> gs/base/gsalloc.h
> gs/base/gsalpha.c
> gs/base/gsalpha.h
> gs/base/gsalphac.c
> gs/base/gsalphac.h
> gs/base/gsargs.c
> gs/base/gsargs.h
> gs/base/gsbitcom.c
> gs/base/gsbitmap.h
> gs/base/gsbitops.c
> gs/base/gsbittab.c
> gs/base/gsbittab.h
> gs/base/gsccode.h
> gs/base/gsccolor.h
> gs/base/gscdef.c
> gs/base/gscdefs.h
> gs/base/gscdevn.c
> gs/base/gscdevn.h
> gs/base/gscedata.c
> gs/base/gscedata.h
> gs/base/gscencs.c
> gs/base/gscencs.h
> gs/base/gschar.c
> gs/base/gschar.h
> gs/base/gschar0.c
> gs/base/gscicach.c
> gs/base/gscicach.h
> gs/base/gscie.c
> gs/base/gscie.h
> gs/base/gsciemap.c
> gs/base/gscindex.h
> gs/base/gsclipsr.c
> gs/base/gsclipsr.h
> gs/base/gscms.h
> gs/base/gscolor.c
> gs/base/gscolor.h
> gs/base/gscolor1.c
> gs/base/gscolor1.h
> gs/base/gscolor2.c
> gs/base/gscolor2.h
> gs/base/gscolor3.c
> gs/base/gscolor3.h
> gs/base/gscolorbuffer.c
> gs/base/gscolorbuffer.h
> gs/base/gscompt.h
> gs/base/gscoord.c
> gs/base/gscoord.h
> gs/base/gscparam.c
> gs/base/gscpixel.c
> gs/base/gscpixel.h
> gs/base/gscpm.h
> gs/base/gscrd.c
> gs/base/gscrd.h
> gs/base/gscrdp.c
> gs/base/gscrdp.h
> gs/base/gscrypt1.c
> gs/base/gscrypt1.h
> gs/base/gscscie.c
> gs/base/gscsel.h
> gs/base/gscsepr.c
> gs/base/gscsepr.h
> gs/base/gscspace.c
> gs/base/gscspace.h
> gs/base/gscssub.c
> gs/base/gscssub.h
> gs/base/gsdcolor.h
> gs/base/gsdevice.c
> gs/base/gsdevice.h
> gs/base/gsdevmem.c
> gs/base/gsdfilt.c
> gs/base/gsdfilt.h
> gs/base/gsdll.h
> gs/base/gsdllwin.h
> gs/base/gsdparam.c
> gs/base/gsdpnext.h
> gs/base/gsdps.c
> gs/base/gsdps.h
> gs/base/gsdps1.c
> gs/base/gsdsrc.c
> gs/base/gsdsrc.h
> gs/base/gsequivc.c
> gs/base/gsequivc.h
> gs/base/gserror.h
> gs/base/gserrors.h
> gs/base/gsexit.h
> gs/base/gsfcid.c
> gs/base/gsfcid2.c
> gs/base/gsfcmap.c
> gs/base/gsfcmap.h
> gs/base/gsfcmap1.c
> gs/base/gsflip.c
> gs/base/gsflip.h
> gs/base/gsfname.c
> gs/base/gsfname.h
> gs/base/gsfont.c
> gs/base/gsfont.h
> gs/base/gsfont0.c
> gs/base/gsfont0c.c
> gs/base/gsfunc.c
> gs/base/gsfunc.h
> gs/base/gsfunc0.c
> gs/base/gsfunc0.h
> gs/base/gsfunc3.c
> gs/base/gsfunc3.h
> gs/base/gsfunc4.c
> gs/base/gsfunc4.h
> gs/base/gsgc.h
> gs/base/gsgcache.c
> gs/base/gsgcache.h
> gs/base/gsgdata.c
> gs/base/gsgdata.h
> gs/base/gshsb.c
> gs/base/gshsb.h
> gs/base/gsht.c
> gs/base/gsht.h
> gs/base/gsht1.c
> gs/base/gsht1.h
> gs/base/gshtscr.c
> gs/base/gshtx.c
> gs/base/gshtx.h
> gs/base/gsicc.c
> gs/base/gsicc.h
> gs/base/gsicc_cache.c
> gs/base/gsicc_cache.h
> gs/base/gsicc_cms.h
> gs/base/gsicc_create.c
> gs/base/gsicc_create.h
> gs/base/gsicc_lcms.c
> gs/base/gsicc_lcms2.c
> gs/base/gsicc_manage.c
> gs/base/gsicc_manage.h
> gs/base/gsicc_profilecache.c
> gs/base/gsicc_profilecache.h
> gs/base/gsimage.c
> gs/base/gsimage.h
> gs/base/gsimpath.c
> gs/base/gsinit.c
> gs/base/gsio.h
> gs/base/gsiodev.c
> gs/base/gsiodevs.c
> gs/base/gsiodisk.c
> gs/base/gsiomacres.c
> gs/base/gsiorom.c
> gs/base/gsiorom.h
> gs/base/gsipar3x.h
> gs/base/gsiparam.h
> gs/base/gsiparm2.h
> gs/base/gsiparm3.h
> gs/base/gsiparm4.h
> gs/base/gsistate.c
> gs/base/gsjconf.h
> gs/base/gsjmorec.h
> gs/base/gslib.c
> gs/base/gslib.h
> gs/base/gslibctx.c
> gs/base/gslibctx.h
> gs/base/gsline.c
> gs/base/gsline.h
> gs/base/gslparam.h
> gs/base/gsmalloc.c
> gs/base/gsmalloc.h
> gs/base/gsmatrix.c
> gs/base/gsmatrix.h
> gs/base/gsmchunk.c
> gs/base/gsmchunk.h
> gs/base/gsmdebug.h
> gs/base/gsmemlok.c
> gs/base/gsmemlok.h
> gs/base/gsmemory.c
> gs/base/gsmemory.h
> gs/base/gsmemraw.h
> gs/base/gsmemret.c
> gs/base/gsmemret.h
> gs/base/gsmisc.c
> gs/base/gsnamecl.c
> gs/base/gsnamecl.h
> gs/base/gsncdummy.c
> gs/base/gsncdummy.h
> gs/base/gsnogc.c
> gs/base/gsnogc.h
> gs/base/gsnorop.c
> gs/base/gsnotify.c
> gs/base/gsnotify.h
> gs/base/gsovrc.c
> gs/base/gsovrc.h
> gs/base/gspaint.c
> gs/base/gspaint.h
> gs/base/gsparam.c
> gs/base/gsparam.h
> gs/base/gsparam2.c
> gs/base/gsparams.c
> gs/base/gsparams.h
> gs/base/gsparamx.c
> gs/base/gsparamx.h
> gs/base/gspath.c
> gs/base/gspath.h
> gs/base/gspath1.c
> gs/base/gspath2.h
> gs/base/gspcolor.c
> gs/base/gspcolor.h
> gs/base/gspenum.h
> gs/base/gspmdrv.c
> gs/base/gspmdrv.h
> gs/base/gsptype1.c
> gs/base/gsptype1.h
> gs/base/gsptype2.c
> gs/base/gsptype2.h
> gs/base/gsrect.h
> gs/base/gsrefct.h
> gs/base/gsromfs0.c
> gs/base/gsrop.c
> gs/base/gsrop.h
> gs/base/gsroprun.c
> gs/base/gsropt.h
> gs/base/gsroptab.c
> gs/base/gsserial.c
> gs/base/gsserial.h
> gs/base/gsshade.c
> gs/base/gsshade.h
> gs/base/gsstate.c
> gs/base/gsstate.h
> gs/base/gsstruct.h
> gs/base/gsstype.h
> gs/base/gstext.c
> gs/base/gstext.h
> gs/base/gstparam.h
> gs/base/gstrans.c
> gs/base/gstrans.h
> gs/base/gstrap.c
> gs/base/gstrap.h
> gs/base/gstype1.c
> gs/base/gstype1.h
> gs/base/gstype2.c
> gs/base/gstype42.c
> gs/base/gstypes.h
> gs/base/gsuid.h
> gs/base/gsutil.c
> gs/base/gsutil.h
> gs/base/gswts.c
> gs/base/gswts.h
> gs/base/gsxfont.h
> gs/base/gx.h
> gs/base/gxacpath.c
> gs/base/gxalloc.h
> gs/base/gxalpha.h
> gs/base/gxarith.h
> gs/base/gxband.h
> gs/base/gxbcache.c
> gs/base/gxbcache.h
> gs/base/gxbitfmt.h
> gs/base/gxbitmap.h
> gs/base/gxbitops.h
> gs/base/gxblend.c
> gs/base/gxblend.h
> gs/base/gxblend1.c
> gs/base/gxccache.c
> gs/base/gxccman.c
> gs/base/gxcdevn.h
> gs/base/gxchar.h
> gs/base/gxchrout.c
> gs/base/gxchrout.h
> gs/base/gxcht.c
> gs/base/gxcid.h
> gs/base/gxcie.h
> gs/base/gxcindex.h
> gs/base/gxclbits.c
> gs/base/gxcldev.h
> gs/base/gxclfile.c
> gs/base/gxclimag.c
> gs/base/gxclio.h
> gs/base/gxclip.c
> gs/base/gxclip.h
> gs/base/gxclip2.c
> gs/base/gxclip2.h
> gs/base/gxclipm.c
> gs/base/gxclipm.h
> gs/base/gxclipsr.h
> gs/base/gxclist.c
> gs/base/gxclist.h
> gs/base/gxcllzw.c
> gs/base/gxclmem.c
> gs/base/gxclmem.h
> gs/base/gxclpage.c
> gs/base/gxclpage.h
> gs/base/gxclpath.c
> gs/base/gxclpath.h
> gs/base/gxclrast.c
> gs/base/gxclread.c
> gs/base/gxclrect.c
> gs/base/gxclthrd.c
> gs/base/gxclthrd.h
> gs/base/gxclutil.c
> gs/base/gxcmap.c
> gs/base/gxcmap.h
> gs/base/gxcolor2.h
> gs/base/gxcomp.h
> gs/base/gxcoord.h
> gs/base/gxcpath.c
> gs/base/gxcpath.h
> gs/base/gxcspace.h
> gs/base/gxctable.c
> gs/base/gxctable.h
> gs/base/gxcvalue.h
> gs/base/gxdcconv.c
> gs/base/gxdcconv.h
> gs/base/gxdcolor.c
> gs/base/gxdcolor.h
> gs/base/gxdda.h
> gs/base/gxdevbuf.h
> gs/base/gxdevcli.h
> gs/base/gxdevmem.h
> gs/base/gxdevndi.c
> gs/base/gxdevndi.h
> gs/base/gxdevrop.h
> gs/base/gxdevsop.h
> gs/base/gxdht.h
> gs/base/gxdhtres.h
> gs/base/gxdhtserial.c
> gs/base/gxdhtserial.h
> gs/base/gxdither.h
> gs/base/gxdtfill.h
> gs/base/gxfapiu.c
> gs/base/gxfapiu.h
> gs/base/gxfarith.h
> gs/base/gxfcache.h
> gs/base/gxfcid.h
> gs/base/gxfcmap.h
> gs/base/gxfcmap1.h
> gs/base/gxfcopy.c
> gs/base/gxfcopy.h
> gs/base/gxfdrop.c
> gs/base/gxfdrop.h
> gs/base/gxfill.c
> gs/base/gxfill.h
> gs/base/gxfillsl.h
> gs/base/gxfilltr.h
> gs/base/gxfillts.h
> gs/base/gxfixed.h
> gs/base/gxfmap.h
> gs/base/gxfont.h
> gs/base/gxfont0.h
> gs/base/gxfont0c.h
> gs/base/gxfont1.h
> gs/base/gxfont42.h
> gs/base/gxfrac.h
> gs/base/gxftype.h
> gs/base/gxfunc.h
> gs/base/gxgetbit.h
> gs/base/gxhintn.c
> gs/base/gxhintn.h
> gs/base/gxhintn1.c
> gs/base/gxhldevc.c
> gs/base/gxhldevc.h
> gs/base/gxht.c
> gs/base/gxht.h
> gs/base/gxht_thresh.c
> gs/base/gxht_thresh.h
> gs/base/gxhtbit.c
> gs/base/gxhttile.h
> gs/base/gxhttype.h
> gs/base/gxi12bit.c
> gs/base/gxi16bit.c
> gs/base/gxiclass.h
> gs/base/gxicolor.c
> gs/base/gxidata.c
> gs/base/gxifast.c
> gs/base/gximag3x.c
> gs/base/gximag3x.h
> gs/base/gximage.c
> gs/base/gximage.h
> gs/base/gximage1.c
> gs/base/gximage2.c
> gs/base/gximage3.c
> gs/base/gximage3.h
> gs/base/gximage4.c
> gs/base/gximask.c
> gs/base/gximask.h
> gs/base/gximono.c
> gs/base/gxino12b.c
> gs/base/gxino16b.c
> gs/base/gxiodev.h
> gs/base/gxiparam.h
> gs/base/gxipixel.c
> gs/base/gxiscale.c
> gs/base/gxistate.h
> gs/base/gxline.h
> gs/base/gxlum.h
> gs/base/gxmatrix.h
> gs/base/gxmclip.c
> gs/base/gxmclip.h
> gs/base/gxobj.h
> gs/base/gxoprect.c
> gs/base/gxoprect.h
> gs/base/gxp1fill.c
> gs/base/gxp1impl.h
> gs/base/gxpageq.c
> gs/base/gxpageq.h
> gs/base/gxpaint.c
> gs/base/gxpaint.h
> gs/base/gxpath.c
> gs/base/gxpath.h
> gs/base/gxpath2.c
> gs/base/gxpcache.h
> gs/base/gxpcmap.c
> gs/base/gxpcolor.h
> gs/base/gxpcopy.c
> gs/base/gxpdash.c
> gs/base/gxpflat.c
> gs/base/gxrplane.h
> gs/base/gxsample.c
> gs/base/gxsample.h
> gs/base/gxsamplp.h
> gs/base/gxshade.c
> gs/base/gxshade.h
> gs/base/gxshade1.c
> gs/base/gxshade4.c
> gs/base/gxshade4.h
> gs/base/gxshade6.c
> gs/base/gxstate.h
> gs/base/gxstdio.h
> gs/base/gxstroke.c
> gs/base/gxsync.c
> gs/base/gxsync.h
> gs/base/gxtext.h
> gs/base/gxtmap.h
> gs/base/gxttf.h
> gs/base/gxttfb.c
> gs/base/gxttfb.h
> gs/base/gxtype1.c
> gs/base/gxtype1.h
> gs/base/gxwts.c
> gs/base/gxwts.h
> gs/base/gxxfont.h
> gs/base/gzacpath.h
> gs/base/gzcpath.h
> gs/base/gzht.h
> gs/base/gzline.h
> gs/base/gzpath.h
> gs/base/gzspotan.c
> gs/base/gzspotan.h
> gs/base/gzstate.h
> gs/base/jerror_.h
> gs/base/locale_.h
> gs/base/macos_carbon_d_pre.h
> gs/base/macos_carbon_pre.h
> gs/base/macos_classic_d_pre.h
> gs/base/macsystypes.h
> gs/base/malloc_.h
> gs/base/math_.h
> gs/base/md5.c
> gs/base/md5.h
> gs/base/md5main.c
> gs/base/memory_.h
> gs/base/minftrsz.c
> gs/base/mkromfs.c
> gs/base/opdfread.h
> gs/base/pipe_.h
> gs/base/png_.h
> gs/base/rinkj/evenbetter-rll.c
> gs/base/rinkj/evenbetter-rll.h
> gs/base/rinkj/rinkj-byte-stream.c
> gs/base/rinkj/rinkj-byte-stream.h
> gs/base/rinkj/rinkj-config.c
> gs/base/rinkj/rinkj-config.h
> gs/base/rinkj/rinkj-device.c
> gs/base/rinkj/rinkj-device.h
> gs/base/rinkj/rinkj-dither.c
> gs/base/rinkj/rinkj-dither.h
> gs/base/rinkj/rinkj-epson870.c
> gs/base/rinkj/rinkj-epson870.h
> gs/base/rinkj/rinkj-screen-eb.c
> gs/base/rinkj/rinkj-screen-eb.h
> gs/base/sa85d.c
> gs/base/sa85d.h
> gs/base/sa85x.h
> gs/base/saes.c
> gs/base/saes.h
> gs/base/sarc4.c
> gs/base/sarc4.h
> gs/base/sbcp.c
> gs/base/sbcp.h
> gs/base/sbhc.c
> gs/base/sbhc.h
> gs/base/sbtx.h
> gs/base/sbwbs.c
> gs/base/sbwbs.h
> gs/base/scanchar.h
> gs/base/scantab.c
> gs/base/scf.h
> gs/base/scfd.c
> gs/base/scfdgen.c
> gs/base/scfdtab.c
> gs/base/scfe.c
> gs/base/scfetab.c
> gs/base/scfparam.c
> gs/base/scfx.h
> gs/base/scommon.h
> gs/base/sdcparam.c
> gs/base/sdcparam.h
> gs/base/sdct.h
> gs/base/sdctd.c
> gs/base/sdcte.c
> gs/base/sddparam.c
> gs/base/sdeparam.c
> gs/base/seexec.c
> gs/base/setjmp_.h
> gs/base/sfilter.h
> gs/base/sfilter2.c
> gs/base/sfxboth.c
> gs/base/sfxcommon.c
> gs/base/sfxfd.c
> gs/base/sfxstdio.c
> gs/base/sha2.c
> gs/base/sha2.h
> gs/base/shc.c
> gs/base/shc.h
> gs/base/shcgen.c
> gs/base/shcgen.h
> gs/base/sidscale.c
> gs/base/sidscale.h
> gs/base/siinterp.c
> gs/base/siinterp.h
> gs/base/simscale.c
> gs/base/simscale.h
> gs/base/siscale.c
> gs/base/siscale.h
> gs/base/sisparam.h
> gs/base/sjbig2.c
> gs/base/sjbig2.h
> gs/base/sjbig2_luratech.c
> gs/base/sjbig2_luratech.h
> gs/base/sjpeg.h
> gs/base/sjpegc.c
> gs/base/sjpegd.c
> gs/base/sjpege.c
> gs/base/sjpx.c
> gs/base/sjpx_luratech.c
> gs/base/sjpx_luratech.h
> gs/base/slzwc.c
> gs/base/slzwd.c
> gs/base/slzwe.c
> gs/base/slzwx.h
> gs/base/smd5.c
> gs/base/smd5.h
> gs/base/smtf.c
> gs/base/smtf.h
> gs/base/spdiff.c
> gs/base/spdiffx.h
> gs/base/spngp.c
> gs/base/spngpx.h
> gs/base/spprint.c
> gs/base/spprint.h
> gs/base/spsdf.c
> gs/base/spsdf.h
> gs/base/srdline.h
> gs/base/srld.c
> gs/base/srle.c
> gs/base/srlx.h
> gs/base/ssha2.c
> gs/base/sstring.c
> gs/base/sstring.h
> gs/base/stat_.h
> gs/base/std.h
> gs/base/stdint_.h
> gs/base/stdio_.h
> gs/base/stdpn.h
> gs/base/stdpre.h
> gs/base/stream.c
> gs/base/stream.h
> gs/base/strimpl.h
> gs/base/string_.h
> gs/base/strmio.h
> gs/base/szlibc.c
> gs/base/szlibe.c
> gs/base/szlibx.h
> gs/base/szlibxx.h
> gs/base/time_.h
> gs/base/ttcalc.c
> gs/base/ttcalc.h
> gs/base/ttcommon.h
> gs/base/ttconf.h
> gs/base/ttconfig.h
> gs/base/ttfinp.c
> gs/base/ttfinp.h
> gs/base/ttfmain.c
> gs/base/ttfmemd.c
> gs/base/ttfmemd.h
> gs/base/ttfoutl.h
> gs/base/ttfsfnt.h
> gs/base/ttinterp.c
> gs/base/ttinterp.h
> gs/base/ttload.c
> gs/base/ttload.h
> gs/base/ttmisc.h
> gs/base/ttobjs.c
> gs/base/ttobjs.h
> gs/base/tttables.h
> gs/base/tttype.h
> gs/base/tttypes.h
> gs/base/unistd_.h
> gs/base/valgrind.h
> gs/base/vdtrace.c
> gs/base/vdtrace.h
> gs/base/vms_x_fix.h
> gs/base/vmsmath.h
> gs/base/whitelst.c
> gs/base/whitelst.h
> gs/base/windows_.h
> gs/base/wtsimdi.c
> gs/base/x_.h
> gs/contrib/defs.h
> gs/contrib/eplaser/gdevescv.c
> gs/contrib/eplaser/gdevescv.h
> gs/contrib/gdevbjc_.c
> gs/contrib/gdevbjc_.h
> gs/contrib/gdevbjca.c
> gs/contrib/gdevcd8.c
> gs/contrib/gdevdj9.c
> gs/contrib/gdevgdi.c
> gs/contrib/gdevhl12.c
> gs/contrib/gdevln03.c
> gs/contrib/gdevlx32.c
> gs/contrib/gdevlx50.c
> gs/contrib/gdevlx7.c
> gs/contrib/gdevmd2k.c
> gs/contrib/gdevop4w.c
> gs/contrib/gdevxes.c
> gs/contrib/gomni.c
> gs/contrib/japanese/dviprlib.c
> gs/contrib/japanese/dviprlib.h
> gs/contrib/japanese/gdev10v.c
> gs/contrib/japanese/gdevalps.c
> gs/contrib/japanese/gdevdmpr.c
> gs/contrib/japanese/gdevespg.c
> gs/contrib/japanese/gdevfmlbp.c
> gs/contrib/japanese/gdevfmpr.c
> gs/contrib/japanese/gdevj100.c
> gs/contrib/japanese/gdevlbp3.c
> gs/contrib/japanese/gdevmag.c
> gs/contrib/japanese/gdevmjc.c
> gs/contrib/japanese/gdevmjc.h
> gs/contrib/japanese/gdevml6.c
> gs/contrib/japanese/gdevnpdl.c
> gs/contrib/japanese/gdevp201.c
> gs/contrib/japanese/gdevrpdl.c
> gs/contrib/lips4/gdevl4r.c
> gs/contrib/lips4/gdevl4v.c
> gs/contrib/lips4/gdevlips.c
> gs/contrib/lips4/gdevlips.h
> gs/contrib/lips4/gdevlprn.c
> gs/contrib/lips4/gdevlprn.h
> gs/contrib/opvp/gdevopvp.c
> gs/contrib/opvp/opvp.h
> gs/contrib/opvp/opvp_0_2_0.h
> gs/contrib/opvp/opvp_common.h
> gs/contrib/pcl3/eprn/eprnfs.c
> gs/contrib/pcl3/eprn/eprnparm.c
> gs/contrib/pcl3/eprn/eprnrend.c
> gs/contrib/pcl3/eprn/gdeveprn.h
> gs/contrib/pcl3/eprn/mediasize.c
> gs/contrib/pcl3/eprn/mediasize.h
> gs/contrib/pcl3/eprn/pagecount.c
> gs/contrib/pcl3/ps/calign.ps
> gs/contrib/pcl3/ps/levels-test.ps
> gs/contrib/pcl3/src/pcl3opts.c
> gs/contrib/pcl3/src/pclcap.c
> gs/contrib/pcl3/src/pclcomp.c
> gs/contrib/pcl3/src/pclgen.c
> gs/contrib/pcl3/src/pclgen.h
> gs/contrib/pcl3/src/pclscan.c
> gs/contrib/pcl3/src/pclscan.h
> gs/contrib/pcl3/src/pclsize.c
> gs/contrib/pcl3/src/pclsize.h
> gs/contrib/pscolor/black.ps
> gs/contrib/pscolor/color.ps
> gs/contrib/pscolor/input.ps
> gs/contrib/pscolor/test.c
> gs/icclib/icc.c
> gs/icclib/icc.h
> gs/icclib/icc9809.h
> gs/ijs/ijs.c
> gs/ijs/ijs_client.c
> gs/ijs/ijs_client.h
> gs/ijs/ijs_client_example.c
> gs/ijs/ijs_exec_unix.c
> gs/ijs/ijs_exec_win.c
> gs/ijs/ijs_server.c
> gs/ijs/ijs_server.h
> gs/ijs/ijs_server_example.c
> gs/ijs/ijs_spec.ps
> gs/imdi/arch.h
> gs/imdi/cctiff.c
> gs/imdi/cgen.c
> gs/imdi/config.h
> gs/imdi/copyright.h
> gs/imdi/imdi.c
> gs/imdi/imdi.h
> gs/imdi/imdi_gen.c
> gs/imdi/imdi_gen.h
> gs/imdi/imdi_imp.h
> gs/imdi/imdi_k.c
> gs/imdi/imdi_k.h
> gs/imdi/imdi_tab.c
> gs/imdi/imdi_tab.h
> gs/lib/EndOfTask.ps
> gs/lib/PDFA_def.ps
> gs/lib/PDFX_def.ps
> gs/lib/acctest.ps
> gs/lib/addxchar.ps
> gs/lib/align.ps
> gs/lib/bdftops.ps
> gs/lib/caption.ps
> gs/lib/cat.ps
> gs/lib/cid2code.ps
> gs/lib/docie.ps
> gs/lib/dumphint.ps
> gs/lib/font2c.ps
> gs/lib/font2pcl.ps
> gs/lib/gs_ce_e.ps
> gs/lib/gs_cmdl.ps
> gs/lib/gs_fform.ps
> gs/lib/gs_il2_e.ps
> gs/lib/gs_kanji.ps
> gs/lib/gs_ksb_e.ps
> gs/lib/gs_lgo_e.ps
> gs/lib/gs_lgx_e.ps
> gs/lib/gs_pfile.ps
> gs/lib/gs_rdlin.ps
> gs/lib/gs_wl1_e.ps
> gs/lib/gs_wl2_e.ps
> gs/lib/gs_wl5_e.ps
> gs/lib/gslp.ps
> gs/lib/gsnup.ps
> gs/lib/image-qa.ps
> gs/lib/impath.ps
> gs/lib/jispaper.ps
> gs/lib/landscap.ps
> gs/lib/lines.ps
> gs/lib/markhint.ps
> gs/lib/markpath.ps
> gs/lib/mkcidfm.ps
> gs/lib/opdfread.ps
> gs/lib/packfile.ps
> gs/lib/pcharstr.ps
> gs/lib/pdf2dsc.ps
> gs/lib/pdfopt.ps
> gs/lib/pdfwrite.ps
> gs/lib/pf2afm.ps
> gs/lib/pfbtopfa.ps
> gs/lib/ppath.ps
> gs/lib/pphs.ps
> gs/lib/prfont.ps
> gs/lib/printafm.ps
> gs/lib/ps2ai.ps
> gs/lib/ps2ascii.ps
> gs/lib/ps2epsi.ps
> gs/lib/rollconv.ps
> gs/lib/showchar.ps
> gs/lib/stcinfo.ps
> gs/lib/stcolor.ps
> gs/lib/stocht.ps
> gs/lib/traceimg.ps
> gs/lib/traceop.ps
> gs/lib/type1enc.ps
> gs/lib/type1ops.ps
> gs/lib/uninfo.ps
> gs/lib/unprot.ps
> gs/lib/viewcmyk.ps
> gs/lib/viewgif.ps
> gs/lib/viewjpeg.ps
> gs/lib/viewmiff.ps
> gs/lib/viewpbm.ps
> gs/lib/viewpcx.ps
> gs/lib/viewps2a.ps
> gs/lib/viewrgb.ps
> gs/lib/wftopfa.ps
> gs/lib/winmaps.ps
> gs/lib/wrfont.ps
> gs/lib/zeroline.ps
> gs/psi/bfont.h
> gs/psi/btoken.h
> gs/psi/dmmain.c
> gs/psi/dpmain.c
> gs/psi/dscparse.c
> gs/psi/dscparse.h
> gs/psi/dstack.h
> gs/psi/dwdll.c
> gs/psi/dwdll.h
> gs/psi/dwimg.c
> gs/psi/dwimg.h
> gs/psi/dwinst.h
> gs/psi/dwmain.c
> gs/psi/dwmainc.c
> gs/psi/dwnodll.c
> gs/psi/dwreg.c
> gs/psi/dwreg.h
> gs/psi/dwres.h
> gs/psi/dwsetup.h
> gs/psi/dwtext.c
> gs/psi/dwtext.h
> gs/psi/dwtrace.c
> gs/psi/dwtrace.h
> gs/psi/dwuninst.h
> gs/psi/dxmain.c
> gs/psi/dxmainc.c
> gs/psi/estack.h
> gs/psi/fapi_ft.c
> gs/psi/fapibstm.c
> gs/psi/fapiufst.c
> gs/psi/files.h
> gs/psi/ghost.h
> gs/psi/gs.c
> gs/psi/gsdll.c
> gs/psi/gserver.c
> gs/psi/ialloc.c
> gs/psi/ialloc.h
> gs/psi/iapi.c
> gs/psi/iapi.h
> gs/psi/iastate.h
> gs/psi/iastruct.h
> gs/psi/ibnum.c
> gs/psi/ibnum.h
> gs/psi/ichar.h
> gs/psi/ichar1.h
> gs/psi/icharout.h
> gs/psi/icid.h
> gs/psi/icie.h
> gs/psi/icolor.h
> gs/psi/iconf.c
> gs/psi/iconf.h
> gs/psi/icontext.c
> gs/psi/icontext.h
> gs/psi/icremap.h
> gs/psi/icsmap.h
> gs/psi/icstate.h
> gs/psi/iddict.h
> gs/psi/iddstack.h
> gs/psi/idebug.c
> gs/psi/idebug.h
> gs/psi/idict.c
> gs/psi/idict.h
> gs/psi/idictdef.h
> gs/psi/idicttpl.h
> gs/psi/idisp.c
> gs/psi/idisp.h
> gs/psi/idosave.h
> gs/psi/idparam.c
> gs/psi/idparam.h
> gs/psi/idsdata.h
> gs/psi/idstack.c
> gs/psi/idstack.h
> gs/psi/ierrors.h
> gs/psi/iesdata.h
> gs/psi/iestack.h
> gs/psi/ifapi.h
> gs/psi/ifcid.h
> gs/psi/ifilter.h
> gs/psi/ifilter2.h
> gs/psi/ifont.h
> gs/psi/ifont1.h
> gs/psi/ifont2.h
> gs/psi/ifont42.h
> gs/psi/ifrpred.h
> gs/psi/ifunc.h
> gs/psi/ifwpred.h
> gs/psi/igc.c
> gs/psi/igc.h
> gs/psi/igcref.c
> gs/psi/igcstr.c
> gs/psi/igcstr.h
> gs/psi/igstate.h
> gs/psi/iht.h
> gs/psi/iimage.h
> gs/psi/iimage2.h
> gs/psi/iinit.c
> gs/psi/iinit.h
> gs/psi/ilevel.h
> gs/psi/ilocate.c
> gs/psi/imain.c
> gs/psi/imain.h
> gs/psi/imainarg.h
> gs/psi/imemory.h
> gs/psi/iminst.h
> gs/psi/iname.c
> gs/psi/iname.h
> gs/psi/inamedef.h
> gs/psi/inameidx.h
> gs/psi/inames.h
> gs/psi/inamestr.h
> gs/psi/inobtokn.c
> gs/psi/inouparm.c
> gs/psi/interp.h
> gs/psi/iosdata.h
> gs/psi/iostack.h
> gs/psi/ipacked.h
> gs/psi/iparam.c
> gs/psi/iparam.h
> gs/psi/iparray.h
> gs/psi/ipcolor.h
> gs/psi/iplugin.c
> gs/psi/iplugin.h
> gs/psi/ireclaim.c
> gs/psi/iref.h
> gs/psi/isave.c
> gs/psi/isave.h
> gs/psi/iscanbin.c
> gs/psi/iscanbin.h
> gs/psi/iscannum.c
> gs/psi/iscannum.h
> gs/psi/isdata.h
> gs/psi/isstate.h
> gs/psi/istack.c
> gs/psi/istack.h
> gs/psi/istkparm.h
> gs/psi/istream.h
> gs/psi/istruct.h
> gs/psi/iutil.c
> gs/psi/iutil.h
> gs/psi/iutil2.c
> gs/psi/iutil2.h
> gs/psi/ivmem2.h
> gs/psi/ivmspace.h
> gs/psi/main.h
> gs/psi/oparc.h
> gs/psi/opcheck.h
> gs/psi/opdef.h
> gs/psi/oper.h
> gs/psi/opextern.h
> gs/psi/ostack.h
> gs/psi/sfilter1.c
> gs/psi/store.h
> gs/psi/wrfont.c
> gs/psi/wrfont.h
> gs/psi/write_t1.c
> gs/psi/write_t1.h
> gs/psi/write_t2.c
> gs/psi/write_t2.h
> gs/psi/zalg.c
> gs/psi/zarith.c
> gs/psi/zarray.c
> gs/psi/zbfont.c
> gs/psi/zbseq.c
> gs/psi/zcfont.c
> gs/psi/zchar.c
> gs/psi/zchar1.c
> gs/psi/zchar2.c
> gs/psi/zchar32.c
> gs/psi/zchar42.c
> gs/psi/zchar42.h
> gs/psi/zcharout.c
> gs/psi/zcharx.c
> gs/psi/zcid.c
> gs/psi/zcidtest.c
> gs/psi/zcie.c
> gs/psi/zcie.h
> gs/psi/zcolor.c
> gs/psi/zcolor.h
> gs/psi/zcolor1.c
> gs/psi/zcolor2.c
> gs/psi/zcolor3.c
> gs/psi/zcontext.c
> gs/psi/zcontrol.c
> gs/psi/zcrd.c
> gs/psi/zcsdevn.c
> gs/psi/zcsindex.c
> gs/psi/zcspixel.c
> gs/psi/zcssepr.c
> gs/psi/zdevcal.c
> gs/psi/zdevice.c
> gs/psi/zdevice2.c
> gs/psi/zdfilter.c
> gs/psi/zdict.c
> gs/psi/zdosio.c
> gs/psi/zdouble.c
> gs/psi/zdpnext.c
> gs/psi/zdps.c
> gs/psi/zdps1.c
> gs/psi/zdscpars.c
> gs/psi/zfaes.c
> gs/psi/zfapi.c
> gs/psi/zfarc4.c
> gs/psi/zfbcp.c
> gs/psi/zfcid.c
> gs/psi/zfcid0.c
> gs/psi/zfcid1.c
> gs/psi/zfcmap.c
> gs/psi/zfdctd.c
> gs/psi/zfdcte.c
> gs/psi/zfdecode.c
> gs/psi/zfile.c
> gs/psi/zfile.h
> gs/psi/zfile1.c
> gs/psi/zfileio.c
> gs/psi/zfilter.c
> gs/psi/zfilter2.c
> gs/psi/zfilterx.c
> gs/psi/zfimscale.c
> gs/psi/zfjbig2.c
> gs/psi/zfjpx.c
> gs/psi/zfmd5.c
> gs/psi/zfont.c
> gs/psi/zfont0.c
> gs/psi/zfont1.c
> gs/psi/zfont2.c
> gs/psi/zfont32.c
> gs/psi/zfont42.c
> gs/psi/zfontenum.c
> gs/psi/zfproc.c
> gs/psi/zfrsd.c
> gs/psi/zfrsd.h
> gs/psi/zfsample.c
> gs/psi/zfunc.c
> gs/psi/zfunc.h
> gs/psi/zfunc0.c
> gs/psi/zfunc3.c
> gs/psi/zfunc4.c
> gs/psi/zfzlib.c
> gs/psi/zgeneric.c
> gs/psi/zgstate.c
> gs/psi/zhsb.c
> gs/psi/zht.c
> gs/psi/zht1.c
> gs/psi/zht2.c
> gs/psi/zht2.h
> gs/psi/zicc.c
> gs/psi/zicc.h
> gs/psi/zimage.c
> gs/psi/zimage2.c
> gs/psi/zimage3.c
> gs/psi/ziodev2.c
> gs/psi/ziodevs.c
> gs/psi/ziodevsc.c
> gs/psi/zmath.c
> gs/psi/zmatrix.c
> gs/psi/zmedia2.c
> gs/psi/zmisc.c
> gs/psi/zmisc1.c
> gs/psi/zmisc2.c
> gs/psi/zmisc3.c
> gs/psi/zncdummy.c
> gs/psi/zpacked.c
> gs/psi/zpaint.c
> gs/psi/zpath.c
> gs/psi/zpath1.c
> gs/psi/zpcolor.c
> gs/psi/zpdfops.c
> gs/psi/zrelbit.c
> gs/psi/zrop.c
> gs/psi/zshade.c
> gs/psi/zstack.c
> gs/psi/zstring.c
> gs/psi/zsysvm.c
> gs/psi/ztrans.c
> gs/psi/ztrap.c
> gs/psi/zupath.c
> gs/psi/zusparam.c
> gs/psi/zutf8.c
> gs/psi/zvmem.c
> gs/psi/zvmem2.c
> gs/psi/zwinutf8.c
> gs/toolbin/GenSubstCID.ps
> gs/toolbin/bmpcmp.c
> gs/toolbin/color/halftone/halfttoning/halftone.c
> gs/toolbin/color/icc_creator/ICC_Creator/CIELAB.h
> gs/toolbin/color/icc_creator/ICC_Creator/ICC_Creator.h
> gs/toolbin/color/icc_creator/ICC_Creator/ICC_CreatorDlg.h
> gs/toolbin/color/icc_creator/ICC_Creator/icc34.h
> gs/toolbin/color/icc_creator/ICC_Creator/icc_create.h
> gs/toolbin/color/icc_creator/ICC_Creator/resource.h
> gs/toolbin/color/icc_creator/ICC_Creator/stdafx.h
> gs/toolbin/color/icc_creator/ICC_Creator/targetver.h
> gs/toolbin/drawafm.ps
> gs/toolbin/encs2c.ps
> gs/toolbin/extractFonts.ps
> gs/toolbin/extractICCprofiles.ps
> gs/toolbin/genfontmap.ps
> gs/toolbin/jpxtopdf.c
> gs/toolbin/pdf_info.ps
> gs/toolbin/pdfinflt.ps
> gs/toolbin/tests/fuzzy.c
> pcl/pcbiptrn.c
> pcl/pccid.c
> pcl/pccolor.c
> pcl/pccprint.c
> pcl/pccrd.c
> pcl/pccrd.h
> pcl/pccsbase.c
> pcl/pccsbase.h
> pcl/pcdict.h
> pcl/pcdraw.c
> pcl/pcfont.c
> pcl/pcfont.h
> pcl/pcfontpg.c
> pcl/pcfrgrnd.c
> pcl/pcfrgrnd.h
> pcl/pcfsel.c
> pcl/pcfsel.h
> pcl/pcht.c
> pcl/pcht.h
> pcl/pcimpl.c
> pcl/pcindxed.c
> pcl/pcindxed.h
> pcl/pcjob.c
> pcl/pclookup.c
> pcl/pclookup.h
> pcl/pcmacros.c
> pcl/pcmisc.c
> pcl/pcmtx3.c
> pcl/pcmtx3.h
> pcl/pcommand.c
> pcl/pcommand.h
> pcl/pcpage.c
> pcl/pcpalet.c
> pcl/pcpalet.h
> pcl/pcparse.c
> pcl/pcparse.h
> pcl/pcpatrn.c
> pcl/pcpatrn.h
> pcl/pcpattyp.h
> pcl/pcpatxfm.c
> pcl/pcpatxfm.h
> pcl/pcrect.c
> pcl/pcsfont.c
> pcl/pcstate.h
> pcl/pcstatus.c
> pcl/pcsymbol.c
> pcl/pcsymbol.h
> pcl/pctext.c
> pcl/pctop.c
> pcl/pctop.h
> pcl/pctpm.h
> pcl/pcuptrn.c
> pcl/pcursor.c
> pcl/pcwhtidx.c
> pcl/pcxfmst.h
> pcl/pgchar.c
> pcl/pgcolor.c
> pcl/pgconfig.c
> pcl/pgdraw.c
> pcl/pgdraw.h
> pcl/pgfdata.c
> pcl/pgfdata.h
> pcl/pgfont.c
> pcl/pgframe.c
> pcl/pggeom.c
> pcl/pggeom.h
> pcl/pglabel.c
> pcl/pglfill.c
> pcl/pgmisc.c
> pcl/pgmisc.h
> pcl/pgparse.c
> pcl/pgpoly.c
> pcl/pgstate.h
> pcl/rtgmode.c
> pcl/rtgmode.h
> pcl/rtmisc.c
> pcl/rtraster.c
> pcl/rtrstcmp.c
> pcl/rtrstcmp.h
> pcl/rtrstst.h
> pl/dwimg.c
> pl/dwimg.h
> pl/dwmainc.c
> pl/dwreg.c
> pl/dwreg.h
> pl/dwres.h
> pl/pjparse.c
> pl/pjparse.h
> pl/pjparsei.c
> pl/pjtop.c
> pl/pjtop.h
> pl/plalloc.c
> pl/plalloc.h
> pl/plapi.h
> pl/plchar.c
> pl/pldict.c
> pl/pldict.h
> pl/pldraw.c
> pl/plfont.c
> pl/plfont.h
> pl/plftable.c
> pl/plht.c
> pl/plimpl.c
> pl/pllfont.c
> pl/plmain.c
> pl/plplatf.c
> pl/plplatf.h
> pl/plplatfps.c
> pl/plsrgb.c
> pl/plsymbol.c
> pl/plsymbol.h
> pl/pltop.c
> pl/pltop.h
> pl/pltoputl.c
> pl/pltoputl.h
> pl/pluchar.c
> pl/plufont.c
> pl/plulfont.c
> pl/plvocab.c
> psi/psitop.c
> pxl/pxasm.ps
> pxl/pxbfont.c
> pxl/pxbfont.ps
> pxl/pxerrors.h
> pxl/pxffont.c
> pxl/pxfont.c
> pxl/pxgstate.c
> pxl/pxgstate.h
> pxl/pximage.c
> pxl/pximpl.c
> pxl/pxink.c
> pxl/pxoper.h
> pxl/pxpaint.c
> pxl/pxparse.c
> pxl/pxparse.h
> pxl/pxpthr.c
> pxl/pxsessio.c
> pxl/pxstate.c
> pxl/pxstate.h
> pxl/pxstream.c
> pxl/pxsymbol.ps
> pxl/pxtop.c
> pxl/pxvalue.c
> pxl/pxvalue.h
> svg/ghostsvg.h
> svg/svgcolor.c
> svg/svgdoc.c
> svg/svgshapes.c
> svg/svgtop.c
> svg/svgtransform.c
> svg/svgtypes.c
> svg/svgxml.c
> tools/GOT/detag.c
> tools/GOT/tagimage.c
> tools/gslite/gslt.h
> tools/gslite/gslt_alloc.c
> tools/gslite/gslt_alloc.h
> tools/gslite/gslt_font.h
> tools/gslite/gslt_font_api.c
> tools/gslite/gslt_font_api.h
> tools/gslite/gslt_font_api_test.c
> tools/gslite/gslt_font_cache.c
> tools/gslite/gslt_font_cff.c
> tools/gslite/gslt_font_encoding.c
> tools/gslite/gslt_font_glyph.c
> tools/gslite/gslt_font_int.h
> tools/gslite/gslt_font_test.c
> tools/gslite/gslt_font_ttf.c
> tools/gslite/gslt_image.c
> tools/gslite/gslt_image.h
> tools/gslite/gslt_image_jpeg.c
> tools/gslite/gslt_image_png.c
> tools/gslite/gslt_image_test.c
> tools/gslite/gslt_image_threads_test.c
> tools/gslite/gslt_image_tiff.c
> tools/gslite/gslt_init.c
> tools/gslite/gslt_test.c
> tools/tt2pcl.c
> tools/xps2tiff/xps2tiff/stdafx.h
> xps/xpsgradient.c

2011-04-19 23:40:49 +0200
Tor Andersson
0b17959f31afe3baffbc328e7f92e88e634ad8b8

> Introduce end-of-line normalization.
> .gitattributes
> .gitignore
> COPYING.AFPL
> gs/.gitignore
> gs/Resource/Init/FAPIcidfmap
> gs/Resource/Init/FAPIconfig
> gs/Resource/Init/FAPIfontmap
> gs/Resource/Init/gs_agl.ps
> gs/Resource/Init/gs_mgl_e.ps
> gs/Resource/Init/gs_mro_e.ps
> gs/base/gdevplib.c
> gs/base/gs_agl.h
> gs/base/gs_mgl_e.h
> gs/base/gs_mro_e.h
> gs/base/gsicc_lcms2.c
> gs/base/gxht_thresh.c
> gs/base/gxht_thresh.h
> gs/base/lcups.mak
> gs/base/lcupsi.mak
> gs/base/opdfread.h
> gs/base/whitelst.c
> gs/base/whitelst.h
> gs/cups/libs/filter/image-colorspace.c
> gs/doc/Details9.htm
> gs/doc/GS9_Color_Management.tex
> gs/doc/History9.htm
> gs/doc/figures/Overview.eps
> gs/expat/examples/elements.dsp
> gs/expat/examples/outline.dsp
> gs/expat/expat.dsw
> gs/expat/lib/expat.dsp
> gs/expat/lib/expat_static.dsp
> gs/expat/lib/expatw.dsp
> gs/expat/lib/expatw_static.dsp
> gs/expat/tests/benchmark/benchmark.dsp
> gs/expat/tests/benchmark/benchmark.dsw
> gs/expat/xmlwf/xmlwf.dsp
> gs/freetype/builds/win32/vc2005/freetype.sln
> gs/freetype/builds/win32/vc2005/freetype.vcproj
> gs/freetype/builds/win32/vc2008/freetype.sln
> gs/freetype/builds/win32/vc2008/freetype.vcproj
> gs/freetype/builds/win32/visualc/freetype.dsp
> gs/freetype/builds/win32/visualc/freetype.dsw
> gs/freetype/builds/win32/visualc/freetype.sln
> gs/freetype/builds/win32/visualc/freetype.vcproj
> gs/freetype/builds/win32/visualce/freetype.dsp
> gs/freetype/builds/win32/visualce/freetype.dsw
> gs/freetype/builds/win32/visualce/freetype.vcproj
> gs/freetype/builds/wince/vc2005-ce/freetype.sln
> gs/freetype/builds/wince/vc2005-ce/freetype.vcproj
> gs/freetype/builds/wince/vc2008-ce/freetype.sln
> gs/freetype/builds/wince/vc2008-ce/freetype.vcproj
> gs/ghostscript-ufst.vcproj
> gs/ghostscript.vcproj
> gs/jasper/src/msvc/imgcmp.dsp
> gs/jasper/src/msvc/imginfo.dsp
> gs/jasper/src/msvc/jasper.dsp
> gs/jasper/src/msvc/jasper.dsw
> gs/jasper/src/msvc/jiv.dsp
> gs/jasper/src/msvc/libjasper.dsp
> gs/jpegxr/APP.rc
> gs/jpegxr/APP.vcproj
> gs/jpegxr/DLL.rc
> gs/jpegxr/DLL.vcproj
> gs/jpegxr/JPEG-XR.sln
> gs/lcms/Delphi/Samples/MAKETEST.BAT
> gs/lcms/Delphi/Samples/gamutchk.pas
> gs/lcms/Projects/BorlandC_5.5/lcms.rc
> gs/lcms/Projects/BorlandC_5.5/lcmsdll.lk
> gs/lcms/Projects/BorlandC_5.5/lcmsdll.lst
> gs/lcms/Projects/BorlandC_5.5/mklcmsdll.bat
> gs/lcms/Projects/VC2005/Python.vcproj
> gs/lcms/Projects/VC2005/Testbed.vcproj
> gs/lcms/Projects/VC2005/icc2ps.vcproj
> gs/lcms/Projects/VC2005/icclink.vcproj
> gs/lcms/Projects/VC2005/icctrans.vcproj
> gs/lcms/Projects/VC2005/jpegicc.vcproj
> gs/lcms/Projects/VC2005/lcms.rc
> gs/lcms/Projects/VC2005/lcms.sln
> gs/lcms/Projects/VC2005/lcms.vcproj
> gs/lcms/Projects/VC2005/lcmsdll.vcproj
> gs/lcms/Projects/VC2005/tiffdiff.vcproj
> gs/lcms/Projects/VC2005/tifficc.vcproj
> gs/lcms/Projects/VC2008/Python.vcproj
> gs/lcms/Projects/VC2008/Testbed.vcproj
> gs/lcms/Projects/VC2008/icc2ps.vcproj
> gs/lcms/Projects/VC2008/icclink.vcproj
> gs/lcms/Projects/VC2008/icctrans.vcproj
> gs/lcms/Projects/VC2008/jpegicc.vcproj
> gs/lcms/Projects/VC2008/lcms.rc
> gs/lcms/Projects/VC2008/lcms.sln
> gs/lcms/Projects/VC2008/lcms.vcproj
> gs/lcms/Projects/VC2008/lcmsdll.vcproj
> gs/lcms/Projects/VC2008/tiffdiff.vcproj
> gs/lcms/Projects/VC2008/tifficc.vcproj
> gs/lcms/Projects/VC6/Python.dsp
> gs/lcms/Projects/VC6/Python.plg
> gs/lcms/Projects/VC6/Testbed.dsp
> gs/lcms/Projects/VC6/Testbed.plg
> gs/lcms/Projects/VC6/icc2ps.dsp
> gs/lcms/Projects/VC6/icclink.dsp
> gs/lcms/Projects/VC6/icctrans.dsp
> gs/lcms/Projects/VC6/jpegicc.dsp
> gs/lcms/Projects/VC6/lcms.dsp
> gs/lcms/Projects/VC6/lcms.dsw
> gs/lcms/Projects/VC6/lcms.rc
> gs/lcms/Projects/VC6/lcmsdll.dsp
> gs/lcms/Projects/VC6/tifficc.dsp
> gs/lcms/Projects/VC7/Python.vcproj
> gs/lcms/Projects/VC7/Testbed.vcproj
> gs/lcms/Projects/VC7/icc2ps.vcproj
> gs/lcms/Projects/VC7/icclink.vcproj
> gs/lcms/Projects/VC7/icctrans.vcproj
> gs/lcms/Projects/VC7/jpegicc.vcproj
> gs/lcms/Projects/VC7/lcms.rc
> gs/lcms/Projects/VC7/lcms.sln
> gs/lcms/Projects/VC7/lcms.vcproj
> gs/lcms/Projects/VC7/lcmsdll.vcproj
> gs/lcms/Projects/VC7/tiffdiff.vcproj
> gs/lcms/Projects/VC7/tifficc.vcproj
> gs/lcms2/Projects/VC2010/lcms2_static/lcms2_static.vcxproj
> gs/lcms2/utils/delphi/delphidemo.dpr
> gs/lcms2/utils/delphi/delphidemo.dproj
> gs/lcms2/utils/delphi/demo1.pas
> gs/lcms2/utils/delphi/lcms2dll.pas
> gs/lcms2/utils/matlab/icctrans.c
> gs/lib/opdfread.ps
> gs/libpng/contrib/visupng/VisualPng.dsp
> gs/libpng/contrib/visupng/VisualPng.dsw
> gs/libpng/contrib/visupng/VisualPng.rc
> gs/libpng/projects/cbuilder5/libpng.bpf
> gs/libpng/projects/cbuilder5/libpng.bpg
> gs/libpng/projects/cbuilder5/libpng.bpr
> gs/libpng/projects/cbuilder5/libpng.cpp
> gs/libpng/projects/cbuilder5/libpngstat.bpf
> gs/libpng/projects/cbuilder5/libpngstat.bpr
> gs/libpng/projects/visualc6/libpng.dsp
> gs/libpng/projects/visualc6/libpng.dsw
> gs/libpng/projects/visualc6/pngtest.dsp
> gs/libpng/projects/visualc71/libpng.sln
> gs/libpng/projects/visualc71/libpng.vcproj
> gs/libpng/projects/visualc71/pngtest.vcproj
> gs/libpng/projects/visualc71/zlib.vcproj
> gs/psi/dw64c.def
> gs/psi/dwmain64.def
> gs/psi/gsdll64.def
> gs/psi/msvc.mak
> gs/psi/msvc64.mak
> gs/psi/nsisinst.nsi
> gs/tiff/man/tiffcrop.1
> gs/toolbin/color/halftone/README
> gs/toolbin/color/halftone/halfttoning.sln
> gs/toolbin/color/halftone/halfttoning/halftone.c
> gs/toolbin/color/halftone/halfttoning/halfttoning.vcproj
> gs/toolbin/color/icc_creator/ICC_Creator.sln
> gs/toolbin/color/icc_creator/ICC_Creator/ICC_Creator.rc
> gs/toolbin/color/icc_creator/ICC_Creator/ICC_Creator.vcproj
> gs/toolbin/color/icc_creator/ucr_bg.txt
> gs/toolbin/gen_ldf_jb2.py
> gs/toolbin/pdf_info.ps
> gs/zlib/contrib/dotzlib/DotZLib.build
> gs/zlib/contrib/dotzlib/DotZLib.sln
> gs/zlib/contrib/dotzlib/DotZLib/AssemblyInfo.cs
> gs/zlib/contrib/dotzlib/DotZLib/ChecksumImpl.cs
> gs/zlib/contrib/dotzlib/DotZLib/CircularBuffer.cs
> gs/zlib/contrib/dotzlib/DotZLib/CodecBase.cs
> gs/zlib/contrib/dotzlib/DotZLib/Deflater.cs
> gs/zlib/contrib/dotzlib/DotZLib/DotZLib.cs
> gs/zlib/contrib/dotzlib/DotZLib/DotZLib.csproj
> gs/zlib/contrib/dotzlib/DotZLib/GZipStream.cs
> gs/zlib/contrib/dotzlib/DotZLib/Inflater.cs
> gs/zlib/contrib/dotzlib/DotZLib/UnitTests.cs
> gs/zlib/contrib/masm686/match.asm
> gs/zlib/contrib/masmx64/bld_ml64.bat
> gs/zlib/contrib/masmx64/gvmat64.asm
> gs/zlib/contrib/masmx64/inffas8664.c
> gs/zlib/contrib/masmx64/inffasx64.asm
> gs/zlib/contrib/masmx86/bld_ml32.bat
> gs/zlib/contrib/masmx86/gvmat32.asm
> gs/zlib/contrib/masmx86/gvmat32c.c
> gs/zlib/contrib/masmx86/inffas32.asm
> gs/zlib/contrib/masmx86/mkasm.bat
> gs/zlib/contrib/vstudio/vc7/miniunz.vcproj
> gs/zlib/contrib/vstudio/vc7/minizip.vcproj
> gs/zlib/contrib/vstudio/vc7/testzlib.vcproj
> gs/zlib/contrib/vstudio/vc7/zlib.rc
> gs/zlib/contrib/vstudio/vc7/zlibstat.vcproj
> gs/zlib/contrib/vstudio/vc7/zlibvc.def
> gs/zlib/contrib/vstudio/vc7/zlibvc.sln
> gs/zlib/contrib/vstudio/vc7/zlibvc.vcproj
> gs/zlib/contrib/vstudio/vc8/miniunz.vcproj
> gs/zlib/contrib/vstudio/vc8/minizip.vcproj
> gs/zlib/contrib/vstudio/vc8/testzlib.vcproj
> gs/zlib/contrib/vstudio/vc8/testzlibdll.vcproj
> gs/zlib/contrib/vstudio/vc8/zlib.rc
> gs/zlib/contrib/vstudio/vc8/zlibstat.vcproj
> gs/zlib/contrib/vstudio/vc8/zlibvc.def
> gs/zlib/contrib/vstudio/vc8/zlibvc.sln
> gs/zlib/contrib/vstudio/vc8/zlibvc.vcproj
> gs/zlib/projects/visualc6/example.dsp
> gs/zlib/projects/visualc6/minigzip.dsp
> gs/zlib/projects/visualc6/zlib.dsp
> gs/zlib/projects/visualc6/zlib.dsw
> pl/dwimg.c
> pl/dwimg.h
> pl/dwmainc.c
> pl/dwreg.c
> pl/dwreg.h
> pl/dwres.h
> tools/Acrobat2Tiff/Acrobat2Tiff.sln
> tools/Acrobat2Tiff/Acrobat2Tiff/Acrobat2Tiff.vb
> tools/Acrobat2Tiff/Acrobat2Tiff/Acrobat2Tiff.vbproj
> tools/Acrobat2Tiff/Acrobat2Tiff/Acrobat2Tiff/Application.Designer.vb
> tools/Acrobat2Tiff/Acrobat2Tiff/Acrobat2Tiff/Application.myapp
> tools/Acrobat2Tiff/Acrobat2Tiff/Acrobat2Tiff/AssemblyInfo.vb
> tools/Acrobat2Tiff/Acrobat2Tiff/Acrobat2Tiff/Resources.Designer.vb
> tools/Acrobat2Tiff/Acrobat2Tiff/Acrobat2Tiff/Resources.resx
> tools/Acrobat2Tiff/Acrobat2Tiff/Acrobat2Tiff/Settings.Designer.vb
> tools/Acrobat2Tiff/Acrobat2Tiff/Acrobat2Tiff/Settings.settings
> tools/Acrobat2Tiff/Acrobat2Tiff/bin/Release/Acrobat2Tiff.xml
> tools/GOT/detag.c
> tools/GOT/tagimage.c
> tools/cmpi/cmpi.bkl
> tools/cmpi/cmpi.cpp
> tools/cmpi/cmpi.dsp
> tools/cmpi/cmpi.dsw
> tools/cmpi/cmpi.pro
> tools/cmpi/cmpi.rc
> tools/cmpi/cmpi.sln
> tools/cmpi/cmpi.vcp
> tools/cmpi/cmpi.vcproj
> tools/cmpi/cmpi.vcw
> tools/cmpi/descrip.mms
> tools/cmpi/makefile.bcc
> tools/cmpi/makefile.dmc
> tools/cmpi/makefile.dms
> tools/cmpi/makefile.dos
> tools/cmpi/makefile.gcc
> tools/cmpi/makefile.sc
> tools/cmpi/makefile.unx
> tools/cmpi/makefile.va
> tools/cmpi/makefile.vc
> tools/cmpi/makefile.wat
> tools/xps2tiff/README
> tools/xps2tiff/xps2tiff.sln
> tools/xps2tiff/xps2tiff/AssemblyInfo.cpp
> tools/xps2tiff/xps2tiff/stdafx.cpp
> tools/xps2tiff/xps2tiff/stdafx.h
> tools/xps2tiff/xps2tiff/xps2tiff.cpp
> tools/xps2tiff/xps2tiff/xps2tiff.vcproj
> win32/GhostPDL.sln
> win32/language_switch.vcproj
> win32/pcl.vcproj
> win32/svg.vcproj
> win32/xps.vcproj

2011-04-19 14:01:55 +0000
Robin Watts <Robin.Watts@artifex.com>
1eadba53383fad842dbc5e72ca137914a83b63e6

> Changes to localcluster code to attempt to implement bmpcmphead. This certainly
> doesn't break anything, but I don't actually ever seem to get any differences
> out when running bmpcmphead.
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12408 a1074d23-0009-0410-80fe-cf8c14f379e6
> gs/toolbin/localcluster/build.pl
> gs/toolbin/localcluster/clustermaster.pl
> gs/toolbin/localcluster/run.pl

2011-04-19 10:06:23 +0000
Robin Watts <Robin.Watts@artifex.com>
c9e506d7e910f6560c97a81de704296236a782cb

> Fix for bug 692152.
> We 'bend' the size of pattern tiles, against the spec, ostensibly to better
> match Acrobat. The fix here is simply to avoid such bending in the case where
> TilingType is 2. According to the spec, TilingType 2 says specifically not
> to use the same device pixel size for every repeat of the pattern, and that
> is exactly what we were doing.
> This cures the original bug, and produces 464 changes in the cluster tests.
> Some (like ps3cet/18-02B.PS) are clear progressions. Others are less obviously
> improvements, but comparison with Acrobat (and discussion with Ken/Chris)
> shows that it's no worse than before, just 'different'.
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12405 a1074d23-0009-0410-80fe-cf8c14f379e6
> gs/base/gsptype1.c

2011-04-18 22:58:18 +0000
Alex Cherepanov <alex.cherepanov@artifex.com>
a05ab8a88d5bc33c068a8e05ecba5f1adf3f3645

> Fix reading of an embedded ICC profile from DSC comments and a
> potential SEGV when the value of /N exceeds 8. Bug 692156.
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12404 a1074d23-0009-0410-80fe-cf8c14f379e6
> gs/Resource/Init/gs_icc.ps
> gs/psi/zcolor.c

2011-04-18 20:34:34 +0000
Michael Vrhel <michael.vrhel@artifex.com>
64bfc773be69bd422c95bca132c47782a421dc3a

> Further movement toward getting fast thresholding operations working for CMYK output devices. Addition of special op to detect if a device is a planar type, creation of threshold screen for all the planes and spatial resampling of color input to output resolution for portrait case. A commit to get things in trunk before we convert from SVN to git.
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12403 a1074d23-0009-0410-80fe-cf8c14f379e6
> gs/base/gdevdflt.c
> gs/base/gdevplib.c
> gs/base/gxdevsop.h
> gs/base/gxht_thresh.c
> gs/base/gxicolor.c
> gs/base/lib.mak

2011-04-18 18:41:26 +0000
Alex Cherepanov <alex.cherepanov@artifex.com>
25152b1f7b5317ef1c3efd438a4d5ce26bcca5ba

> Consider any xref entry with 0 offset as a free entry. Earlier revisions
> rebuilt the xref table when offset == 0 but generation != 0.
> However, rebuilding is an unreliable process and should be avoided if
> possible. Bug 692159.
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12402 a1074d23-0009-0410-80fe-cf8c14f379e6
> gs/Resource/Init/pdf_main.ps

2011-04-18 07:58:13 +0000
Chris Liddell <chris.liddell@artifex.com>
7169dc6a5af38e1955c660813ed6e62392dc0deb

> Add a fallback check for libpaper support.
> Older versions of autogen appear to have a bug which causes the AC_CHECK_LIB
> macro to mis-identify the libpaper development library as being present when
> it is not.
> So add a second check check based on the presence of paper.h using
> AC_CHECK_HEADER().
> No cluster differences expected.
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12401 a1074d23-0009-0410-80fe-cf8c14f379e6
> gs/base/configure.ac

2011-04-16 14:21:57 +0000
Alex Cherepanov <alex.cherepanov@artifex.com>
848275e2554bb57ebf2e12dabc47fc2922e7b877

> Instead of searching for %%EOF marker (which is often damaged) and browsing the
> file backwards, search for 'startxref' and take the next token as an xref
> position. Besides fixing the reported bug, this greatly simplifies the search
> for xref position. Bug 692153.
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12400 a1074d23-0009-0410-80fe-cf8c14f379e6
> gs/Resource/Init/pdf_base.ps
> gs/Resource/Init/pdf_main.ps

2011-04-14 20:59:18 +0000
Michael Vrhel <michael.vrhel@artifex.com>
3be81f880b7f0a31d3c213ad4245d0bbfeb0b5ef

> code to support rendering color source images to a mono device using thresholding. The code is currently disabled pending additional testing.
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12397 a1074d23-0009-0410-80fe-cf8c14f379e6
> gs/base/gxicolor.c

2011-04-13 22:17:12 +0000
Michael Vrhel <michael.vrhel@artifex.com>
4a3666ee2833e877a26ef75fece00fd6fad14c93

> Reorganization of thresholding code to make it easier to get the threshold operation working for color images as input as well as the case when we go to a cmyk planar device.
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12396 a1074d23-0009-0410-80fe-cf8c14f379e6
> gs/base/gxht_thresh.c
> gs/base/gxht_thresh.h
> gs/base/gxicolor.c
> gs/base/gximono.c
> gs/base/lib.mak

2011-04-13 16:21:07 +0000
Robin Watts <Robin.Watts@artifex.com>
3791878570227c7f5f1c07891c066fab3db2e5d3

> Fix reference counting of compositors in clist rendering; previously
> the code assumed that it was the only claimant of a compositor and
> closed/freed the device regardless of the reference count.
> Cluster testing shows no differences.
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12394 a1074d23-0009-0410-80fe-cf8c14f379e6
> gs/base/gxclrast.c

2011-04-13 13:30:03 +0000
Ken Sharp <ken.sharp@artifex.com>
29ff2a6f7d27ac9b19887ecc9243a6a8bc6aa9b8

> Fix (pdfwrite) : Restore TT->CIDFOnt conversion
> When creating PDF/A output, the Acrobat pre-flight tool throws out subset TrueType fonts
> which are symbolic. Its not clear why, since the spec says that subset TrueType fonts
> are permitted and does not require any additional information (such as /CharSet for
> type 1 fonts).
> If we instead create a CIDFont with a CIDSet, then the pre-flight tool is happy (and
> also, usefully, doesn't complain about multiple CMAP subtables), so here we spot
> that there is no preferred Encoding (always the case with Symbolic fonts) and make
> the conversion.
> No differences expected.
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12393 a1074d23-0009-0410-80fe-cf8c14f379e6
> gs/base/gdevpdtf.c

2011-04-13 04:47:52 +0000
Ray Johnston <ray.johnston@artifex.com>
124ab469aa0ad450a46d909e99c1b5d7072e646b

> Fix for PCL when NumRenderingThreads > 0. PCL uses a memory allocator that is
> not thread safe (chunk memory) but the mt rendering needs a thread safe base
> allocator since the main thread may be allocating as well as the rendering
> threads. This problem was seen with a couple of 'performance' documents, but
> could fail on any document. Bug 692111 for customer #661.
> cluster testing showed no regressions, as expected since it didn't use MT
> rendering.
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12392 a1074d23-0009-0410-80fe-cf8c14f379e6
> gs/base/gsalloc.c
> gs/base/gsmalloc.c
> gs/base/gsmchunk.c
> gs/base/gsmemlok.c
> gs/base/gsmemory.h
> gs/base/gsmemret.c
> gs/base/gxclread.c
> gs/base/gxclthrd.c

2011-04-12 20:08:59 +0000
Ray Johnston <ray.johnston@artifex.com>
fdac37730cb0f86e8cd1efad2c49243c5ea5ec0b

> Add some more useful stuff to pdf_info.ps: Default dumps Media paramters and
> fonts that are needed, but not embedded and standard fonts. Media parameters
> now include Rotate value and states if the page has transparency.
> Also allow this to be used more conveniently with the -- syntax:
> gs {-q} -- toolbin/pdf_info.ps inputfile.pdf
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12391 a1074d23-0009-0410-80fe-cf8c14f379e6
> gs/toolbin/pdf_info.ps

2011-04-12 15:19:15 +0000
Ken Sharp <ken.sharp@artifex.com>
78bb9a6585153e2cf0cbcc689706cd89d68b5b7b

> Fix PostScript colour handling
> Bug #692116 "gs crash while executing stop operator"
> The problem was caused by a mismatch between the graphics library and the PostScript
> interpreter. When executing setcachedevice the graphcis library can set the colour
> space to DeviceGray. Because it is unaware of the 'higher level' members of the graphics
> state which belong to the PostScript interpreter it does not, and cannot, set the
> *PostScript* graphics state colour space to the same space.
> Normally this does not matter, because after the glyph is complete the colour space is
> restored. However, if a currentgray/currentrgb/currentcmyk operator is executed after
> the graphics library has set the space to DeviceGray, but before it has restored the
> space, then the PostScript space will be incorrect. This leads to the PostScript
> handling trying to access more elements from the stack than 'currentcolor' put there
> (currentcolor uses the underlying space, not the PostScript space), and causes errors.
> There isn't a really good way to handle this, because we can't put information about
> the PostScript state into the graphics library. So I've chosen to check the underlying
> colour space when processing currentgray etc, and if the space in the graphics
> library is DeviceGray and does not match the expected PostScript space, then instead
> of raising an error we proceed as if the PostScript space had been DeviceGray all
> along.
> No differences expected
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12389 a1074d23-0009-0410-80fe-cf8c14f379e6
> gs/psi/zcolor.c

2011-04-12 09:12:59 +0000
Chris Liddell <chris.liddell@artifex.com>
1b48fe7a0a2bd2aa49cd6cbf0ec5de3abcab7c89

> Fix the GS_LIB registry value.
> The GS_LIB registry entry was missing the "lib" directory.
> Also, tidy up some of the uninstall rules.
> No cluster differences.
> Bug 692140
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12388 a1074d23-0009-0410-80fe-cf8c14f379e6
> gs/psi/nsisinst.nsi

2011-04-12 06:44:27 +0000
Michael Vrhel <michael.vrhel@artifex.com>
f0a9ab32440ecade2d301187489805284cbf1a9d

> Forgot to save the readme
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12387 a1074d23-0009-0410-80fe-cf8c14f379e6
> gs/toolbin/color/icc_creator/README.txt

2011-04-12 06:38:17 +0000
Michael Vrhel <michael.vrhel@artifex.com>
d90c248c90cb8e12c6613d32b347846a64f91ca6

> Addition of one more profile, which is a CMYK profile but which only outputs in the K channel and a ifdef in the code to generate this thing.
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12386 a1074d23-0009-0410-80fe-cf8c14f379e6
> gs/toolbin/color/icc_creator/ICC Profiles/cmyk_k_ouput_only.icc
> gs/toolbin/color/icc_creator/ICC_Creator/icc_create.cpp

2011-04-12 06:17:59 +0000
Michael Vrhel <michael.vrhel@artifex.com>
a031163dc9ada140b6e606582c29c9515fc7d839

> Fix for an issue related to white point for the cmyk profile also fix for when UCR/BG is used in the profile creation.
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12385 a1074d23-0009-0410-80fe-cf8c14f379e6
> gs/toolbin/color/icc_creator/ICC Profiles/ps_emulate_cmyk.icc
> gs/toolbin/color/icc_creator/ICC_Creator/icc_create.cpp

2011-04-12 05:11:30 +0000
Michael Vrhel <michael.vrhel@artifex.com>
6acec66087ba2de2d99c42c9e1d33cdb89473089

> Addition of ICC profiles that properly emulate the PS color mappings
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12384 a1074d23-0009-0410-80fe-cf8c14f379e6
> gs/toolbin/color/icc_creator/ICC Profiles/ps_emulate_cmyk.icc
> gs/toolbin/color/icc_creator/ICC Profiles/ps_emulate_gray.icc
> gs/toolbin/color/icc_creator/ICC Profiles/ps_emulate_rgb.icc

2011-04-12 05:02:03 +0000
Michael Vrhel <michael.vrhel@artifex.com>
151535c554165c2f03fbe07098cc45fb0b341f67

> Fix for bugs in ICC creator tool related primarily to the CMYK profile for simulating PS color conversions. Added in a option so that we do the CPSI like conversion and also added in the ability to define UCR/BG and pack those mappings into ICC profiles. These fixes were needed to take care of an issue found by customer 850.
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12383 a1074d23-0009-0410-80fe-cf8c14f379e6
> gs/toolbin/color/halftone/README
> gs/toolbin/color/icc_creator/ICC_Creator/CIELAB.h
> gs/toolbin/color/icc_creator/ICC_Creator/ICC_Creator.rc
> gs/toolbin/color/icc_creator/ICC_Creator/ICC_CreatorDlg.cpp
> gs/toolbin/color/icc_creator/ICC_Creator/ICC_CreatorDlg.h
> gs/toolbin/color/icc_creator/ICC_Creator/icc_create.cpp
> gs/toolbin/color/icc_creator/ICC_Creator/icc_create.h
> gs/toolbin/color/icc_creator/ICC_Creator/resource.h
> gs/toolbin/color/icc_creator/README.txt
> gs/toolbin/color/icc_creator/ucr_bg.txt

2011-04-11 15:59:22 +0000
Ken Sharp <ken.sharp@artifex.com>
4509a49f66c24f3a5590aadaaee30325676df877

> Fix (colour handling) : crash when executing 'stop'
> This is part of the fix for bug #692116. The crash in that report is caused because the
> continuation procedures for the colour handling are sometimes pushed with a
> push_mark_estack where the opproc has a value of 0. This is not valid and I always
> intended to fix it, but forgot.
> This changes all uses of push_mark_estack so that the opproc is set to a valid routine
> which does nothing, thus solving the crash and exposing the real problem. The only
> reason we get a crash is because we are executing stop as part of the error handler,
> because currentgray returned an error.
> No differences expected.
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12382 a1074d23-0009-0410-80fe-cf8c14f379e6
> gs/psi/zcolor.c

2011-04-09 07:06:43 +0000
Alex Cherepanov <alex.cherepanov@artifex.com>
6cb2c7110447967b01f19415ae0ff0f8dd1a251b

> Add special processing for a broken PDF file that uses bare stream
> dictionaries instead of ICCBased color space arrays. Bug 692213.
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12381 a1074d23-0009-0410-80fe-cf8c14f379e6
> gs/Resource/Init/pdf_draw.ps

2011-04-08 17:03:54 +0000
Michael Vrhel <michael.vrhel@artifex.com>
0791cc859ad38053ab3d3eef50169ac259f771cb

> Fix for x11alpha device when the source file has transparency. Two issues existed. One, found by henry, was that the target device of the x11alpha device was not inheriting the icc profile of the x11alpha device. The other was that the x11alpha device was using the bbox compositor procedure, which has some operations in it related to checking if the device has a target and the pdf14 device will target the target of the bbox device. This is not what we want for the x11alpha device. This should fix a lot of the x11alpha bugs Basically any source files that had transparency would have failed prior to this fix.
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12380 a1074d23-0009-0410-80fe-cf8c14f379e6
> gs/base/gdevxini.c

2011-04-08 13:34:53 +0000
Robin Watts <Robin.Watts@artifex.com>
507cbee1403b20b2c3fec692f746f41d9d985566

> Fix Bug 692129. If an image is scaled to zero height and interpolation
> is on, we end up mallocing a zero byte buffer and then overrunning it.
> The fix is to detect this scaling, and still allocate a 1 pixel high
> buffer.
> No cluster differences expected.
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12378 a1074d23-0009-0410-80fe-cf8c14f379e6
> gs/base/siscale.c

2011-04-08 08:48:17 +0000
Ken Sharp <ken.sharp@artifex.com>
1b6c7591e0f62007e4cf690d2f2fcbb56be9f989

> Fix GSLite : update to changes in decode_glyph method
> Revision 12374 altered the decode_glyph font method to take an additional parameter,
> the character code. This commit updates the GSLite code routines to take the extra
> parameter
> No differences expected, I don't think this is tested (or even compiled)
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12377 a1074d23-0009-0410-80fe-cf8c14f379e6
> tools/gslite/gslt_font_api.c
> tools/gslite/gslt_font_cff.c
> tools/gslite/gslt_font_ttf.c
> tools/gslite/gslt_test.c

2011-04-08 08:36:35 +0000
Ken Sharp <ken.sharp@artifex.com>
cc053e229b4a2dd03ff83673bfb819be51e970c3

> Fix XPS and PCL interpreters : Change to decode_glyph routine
> The decode_glyph font method was changed to pass in the character code in revision
> 12374, but I missed the fact that these methods also exist in the XPS and PCL
> interpreters.
> This revision simply updates the methods with the additional parameter.
> No differences expected.
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12376 a1074d23-0009-0410-80fe-cf8c14f379e6
> pl/plfont.c
> xps/xpscff.c
> xps/xpsttf.c

2011-04-07 15:52:45 +0000
Chris Liddell <chris.liddell@artifex.com>
a69dfc3caebd4f16ab8ba7f1c888bdbed6e5dbce

> Resolve a path problem when running mkcidfm.ps.
> mkcidfm.ps did not handle the path to the Windows
> font directory using back slash directory delimiters
> so the nsis script now replaces all the back slash
> delimiters with forward slash, with which mkcidfm.ps
> works correctly.
> Bug 691511
> No cluster differences expected.
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12375 a1074d23-0009-0410-80fe-cf8c14f379e6
> gs/psi/nsisinst.nsi

2011-04-07 15:48:21 +0000
Ken Sharp <ken.sharp@artifex.com>
24c562b9bcedcd9e6bd1d63a06c09eba52a24cbd

> Fix (pdfwrite) : Not using ToUnicode CMaps under some conditions
> Bug #692119 "Cannot copy text from Ghostscript generated PDF/A document"
> The PDF interpreter converts ToUnicode CMaps into GlyphNames2Unicode dictionaries, to
> do this it uses the Encoding to convert the character codes into glyph names. Of course
> for CIDFonts we don't want to do this, and so when there is no Encoding we instead
> put the Unicode value directly into the dictionary using the CID as an index.
> If the font has no Encoding (which is optional in PDF) then we do the same for a
> regular font. However, by the time pdfwrite sees the font we have had to add an Encoding
> as its not valid for us to define a regular font with no Encoding.
> So pdfwrite converts the character code into a (bogus) glyph name, and then tries to
> look up that glyph name in the GlyphNames2Unicode dictionary. Obviously this fails.
> I've extended the 'decode_glyph' call so that it takes both the glyph name and the
> character code, for CID fonts the character code is always -1. If the glyph name can't
> be found in the GlyphNames2Unicode dictionary then we try to use the character code
> instead.
> This works for this test case, and I don't think its likely to produce worse results
> than the old code. Regression tests show no differences, but since they don't test
> ToUnicode CMaps they weren't expected to. My own tests seem to be OK but I can't say
> I'm terribly sure about this one.
> Expected Differences
> None
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12374 a1074d23-0009-0410-80fe-cf8c14f379e6
> gs/base/gdevpdtc.c
> gs/base/gdevpdte.c
> gs/base/gsfont.c
> gs/base/gxfont.h
> gs/psi/bfont.h
> gs/psi/zbfont.c

2011-04-07 03:30:16 +0000
Michael Vrhel <michael.vrhel@artifex.com>
8170bf69742a320e7e28bffa58cbf0f0f14f2eb0

> Fix for 692123. It was necessary to make sure that the blending state of the pdf14 device is updated when we have the alpha buffer device installed in front of the pdf14 device.
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12373 a1074d23-0009-0410-80fe-cf8c14f379e6
> gs/base/gdevdflt.c
> gs/base/gdevp14.c
> gs/base/gspaint.c
> gs/base/gstrans.c
> gs/base/gstrans.h
> gs/base/gxdevsop.h
> gs/base/lib.mak

2011-04-06 18:33:27 +0000
Robin Watts <Robin.Watts@artifex.com>
c03e320614893bb304b6c63e02a597d0153df031

> Change lcms2 memory handling and update lib.
> As of this commit, we can (and do) run a completely unchanged library.
> This includes our tiny tweak to be able to get the input/output formats for
> a given transform. Also update our interface code so that we use the plugin
> mechanism to redirect malloc/free etc through us rather than hacking the
> code direct. Thanks to Marti Maria for both of these.
> No cluster changes as this code is not tested. CLUSTER_UNTESTED.
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12372 a1074d23-0009-0410-80fe-cf8c14f379e6
> gs/base/gsicc_lcms2.c
> gs/lcms2/AUTHORS
> gs/lcms2/ChangeLog
> gs/lcms2/Makefile.in
> gs/lcms2/configure
> gs/lcms2/configure.ac
> gs/lcms2/doc/LittleCMS2.1 API.pdf
> gs/lcms2/include/Makefile.in
> gs/lcms2/include/lcms2.h
> gs/lcms2/src/Makefile.in
> gs/lcms2/src/cmscnvrt.c
> gs/lcms2/src/cmserr.c
> gs/lcms2/src/cmsxform.c
> gs/lcms2/src/lcms2_internal.h
> gs/lcms2/testbed/Makefile.in
> gs/lcms2/utils/jpgicc/Makefile.in
> gs/lcms2/utils/linkicc/Makefile.in
> gs/lcms2/utils/linkicc/linkicc.1
> gs/lcms2/utils/linkicc/linkicc.c
> gs/lcms2/utils/psicc/Makefile.in
> gs/lcms2/utils/tificc/Makefile.in
> gs/lcms2/utils/transicc/Makefile.in

2011-04-06 17:41:50 +0000
Chris Liddell <chris.liddell@artifex.com>
a54df2d2b0e78777a037ceacfba76dd47d9993d3

> Resolve a crash to due an unexpected CMap object type.
> The code was not checking that the CMap object was a string or an array (of
> strings) before trying read bytes from it. If the CMap actually turned out
> to be an unexpected object, such as an integer, it would cause a crash.
> Credit to Ken Sharp for the patch.
> Bug 692124
> No cluster differences expected.
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12371 a1074d23-0009-0410-80fe-cf8c14f379e6
> gs/psi/zfapi.c

2011-04-06 12:13:55 +0000
Ken Sharp <ken.sharp@artifex.com>
d97f8c354d97c8ec941c2d4b702b7d17ab0e03b3

> Fix (ps2write/pdfwrite) : bitmapped font problem
> When producing an inline image representing a glyph which could not be embedded as text,
> the code emitted the matrix setup for the image before opening the context. If there
> was (for example) a pending text operation this caused the matrix setup to appear in
> the text context instead of the image context, leading to the image disappearing.
> Opening the image context before emitting the matrix solves the problem.
> Expected Differences
> The output from ps2write (resolution = 300 dpi) with the file
> 'metrics_no_bbox.ps'
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12370 a1074d23-0009-0410-80fe-cf8c14f379e6
> gs/base/gdevpdfb.c

2011-04-05 15:01:49 +0000
Chris Liddell <chris.liddell@artifex.com>
2d72418b094cb62501d6af82a845848d01134119

> The FAPI code was relying on the result of gx_compute_text_oversampling()
> to ascertain whether anti-aliasing is in force.
> This is insufficient, as it turns out, and we actually need to base the
> decision on the alpha bits as requested by the device.
> No cluster differences expected.
> Bug 692120.
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12369 a1074d23-0009-0410-80fe-cf8c14f379e6
> gs/psi/zfapi.c

2011-04-04 16:33:13 +0000
Robin Watts <Robin.Watts@artifex.com>
f4a6e441bbe26758d4d3d9c62c369fde2b0e9643

> Squash some warnings in the lcms v2 interface code. No expected differences.
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12368 a1074d23-0009-0410-80fe-cf8c14f379e6
> gs/base/gsicc_lcms2.c

2011-04-04 14:42:57 +0000
Robin Watts <Robin.Watts@artifex.com>
b359a954d93cd140b3e000c107854b021ccd9189

> Squash 4 warnings in the lcmvs v1 stuff.
> No cluster differences expected (and testing shows none, so CLUSTER_UNTESTED).
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12367 a1074d23-0009-0410-80fe-cf8c14f379e6
> gs/base/gsicc_cms.h
> gs/base/gsicc_manage.c

2011-04-04 07:40:55 +0000
Ken Sharp <ken.sharp@artifex.com>
1f92f1449bf208c8f7a878c8f149ca67cd62ab49

> Alter the generation of Decode array entries for images using Indexed colour spaces by
> using bit shifting instead of simple 'exp' operator.
> No differences expected, code is equivalent.
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12366 a1074d23-0009-0410-80fe-cf8c14f379e6
> gs/base/opdfread.h
> gs/lib/opdfread.ps

2011-04-03 20:40:27 +0000
Gheorghe Savulescu <sags@ghostscript.com>
b58247cecc1fd272e12adc26890d912346dd92c5

> Bug 689093 #21/ HTML compatibility:
> Do not use SHORTTAGS (the "<tag ... />" form) in HTML.
> Bug 689093 #21/ HTML compatibility
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12365 a1074d23-0009-0410-80fe-cf8c14f379e6
> gs/doc/Drivers.htm

2011-04-03 20:39:48 +0000
Gheorghe Savulescu <sags@ghostscript.com>
d52ff94dea3bb3db0dc4c9ee1c8e89d48b1fb7ed

> Bug 689093 #20/ HTML compatibility
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12364 a1074d23-0009-0410-80fe-cf8c14f379e6
> gs/doc/API.htm
> gs/doc/C-style.htm
> gs/doc/Changes.htm
> gs/doc/Commprod.htm
> gs/doc/DLL.htm
> gs/doc/Deprecated.htm
> gs/doc/Develop.htm
> gs/doc/Devices.htm
> gs/doc/Drivers.htm
> gs/doc/Fonts.htm
> gs/doc/Helpers.htm
> gs/doc/Hershey.htm
> gs/doc/History1.htm
> gs/doc/History2.htm
> gs/doc/History3.htm
> gs/doc/History4.htm
> gs/doc/History5.htm
> gs/doc/History6.htm
> gs/doc/History7.htm
> gs/doc/Install.htm
> gs/doc/Issues.htm
> gs/doc/Language.htm
> gs/doc/Lib.htm
> gs/doc/Make.htm
> gs/doc/News.htm
> gs/doc/Projects.htm
> gs/doc/Ps-style.htm
> gs/doc/Ps2epsi.htm
> gs/doc/Ps2pdf.htm
> gs/doc/Ps2ps2.htm
> gs/doc/Psfiles.htm
> gs/doc/Readme.htm
> gs/doc/Release.htm
> gs/doc/Source.htm
> gs/doc/Unix-lpr.htm
> gs/doc/Use.htm
> gs/doc/Xfonts.htm
> gs/doc/index.html

2011-04-03 20:39:13 +0000
Gheorghe Savulescu <sags@ghostscript.com>
591b83fa9500a99ff8d24ddd7aa8962bd44312d6

> Bug 689093 #19/ CSS conformance:
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12363 a1074d23-0009-0410-80fe-cf8c14f379e6
> gs/doc/gs.css

2011-04-03 20:39:01 +0000
Gheorghe Savulescu <sags@ghostscript.com>
464ee97310cd5c003d3683f2a2ceb16691394813

> Bug 689093 #18bis/ SVN damage:
> Replace ijs\ijs_spec.pdf, with a good copy.
> This file is currently damaged in the SVN Repository. The damage seem to have
> happened during the conversion of the Repository from CVS to Subversion. This copy
> of the file comes from the last CVS version available; the copy in the 1st SVN
> checkout I have is already damaged. Note the "/CreationDate" inside the pdf is the
> same as in the current (damaged) version and the last change to this file is very
> old, so this file's substantive content did not change after the migration to SVN.
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12362 a1074d23-0009-0410-80fe-cf8c14f379e6
> gs/ijs/ijs_spec.pdf

2011-04-03 20:38:09 +0000
Gheorghe Savulescu <sags@ghostscript.com>
bbb639d51f543398c6e318075656af4857ad58b5

> Bug 689093 #18/ SVN damage:
> This patch changes files that contain "$Id..." as text in order to
> protect the apparent keyword from being expanded by SubVersion. The
> methods used are as follows:
> - for HTML: use the numeric entity "$" instead of "$".
> - for C and Python: if the parser finds 2 consecutive string
> literals, separated by nothing but whitespace, then it
> automatically treats them as if it were a single, longer, string
> obtained from concatenating the 2 original ones. Thus, the patch
> replaces '"$Id"' => '"$" "Id$"'.
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12361 a1074d23-0009-0410-80fe-cf8c14f379e6
> gs/base/scfdgen.c
> gs/doc/C-style.htm
> gs/doc/Deprecated.htm
> gs/doc/Details.htm
> gs/doc/Details8.htm
> gs/doc/Details9.htm
> gs/doc/Develop.htm
> gs/doc/Devices.htm
> gs/doc/Drivers.htm
> gs/doc/Hershey.htm
> gs/doc/History1.htm
> gs/doc/History2.htm
> gs/doc/History3.htm
> gs/doc/History4.htm
> gs/doc/History5.htm
> gs/doc/History6.htm
> gs/doc/History7.htm
> gs/doc/History8.htm
> gs/doc/History9.htm
> gs/doc/Install.htm
> gs/doc/Issues.htm
> gs/doc/Make.htm
> gs/doc/Ps-style.htm
> gs/doc/Release.htm
> gs/doc/Use.htm
> gs/toolbin/gen_ldf_jb2.py
> gs/toolbin/split_changelog.py

2011-04-03 20:27:35 +0000
Gheorghe Savulescu <sags@ghostscript.com>
5ff3a16a18372eff2b65054ced9b0cd283ad1ea9

> looks like a SVN keyword, toolbin\split_changelog.py outputs it as-is
> to HTML and later SVN expands it as a keyword. The result is the text
> displayed differs. This patch extends the substitutions done for
> character entities to include "$" => "$"; there won't be any
> "$"-as-text, and thus no "$Keyword..$"-as-text, anymore.
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12360 a1074d23-0009-0410-80fe-cf8c14f379e6
> gs/toolbin/split_changelog.py

2011-04-03 20:25:28 +0000
Gheorghe Savulescu <sags@ghostscript.com>
5b7d759adc6fb7f5ab85b72c195aaa4cc8a9882b

> toolbin\split_changelog.py encodes text coming from log messages as
> utf-8. The patch changes it to output a "<meta/>" element specifying
> the charset used, otherwise browsers that are not set for utf-8 by
> default won't necessarily display the file correctly [if message
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12359 a1074d23-0009-0410-80fe-cf8c14f379e6
> gs/doc/Details.htm
> gs/doc/Details8.htm
> gs/doc/Details9.htm
> gs/doc/History8.htm
> gs/doc/History9.htm
> gs/toolbin/split_changelog.py

2011-04-03 20:25:06 +0000
Gheorghe Savulescu <sags@ghostscript.com>
399081713e3314b04fa4404e870434f0bacb4590

> Bug 689093 #15 (note: there's no #14)/ HTML conformance
> explicitly declare the encoding used. Files Details(|8|9).htm and
> History(8|9).htm may need extended characters coming from commit logs, and will
> be handled by a later patch. Other files only need 7-bit ASCII.
> This patch also contains a small change not related to HTML-conformance:
> a missing space in doc\Language.htm ("... for[NO SPACE HERE]1-, ...").
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12358 a1074d23-0009-0410-80fe-cf8c14f379e6
> gs/doc/Language.htm
> gs/doc/Make.htm
> gs/doc/Ps2pdf.htm

2011-04-03 20:24:56 +0000
Gheorghe Savulescu <sags@ghostscript.com>
ce833816683f46ec1acd966c4c86a01a33b2f687

> Bug 689093 #13/ HTML conformance:
> 'align="middle"' should be 'align="center"'
> "Middle" is only for vertical alignment ("valign="); for the
> horizontal alignment use "center".
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12357 a1074d23-0009-0410-80fe-cf8c14f379e6
> gs/doc/Deprecated.htm

2011-04-03 20:24:48 +0000
Gheorghe Savulescu <sags@ghostscript.com>
394631da0981713367ca2472be75445bd0fb0d56

> Bug 689093 #12 (note: there's no #11)/ HTML conformance
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12356 a1074d23-0009-0410-80fe-cf8c14f379e6
> gs/doc/Changes.htm
> gs/doc/Deprecated.htm
> gs/doc/Details9.htm
> gs/doc/Devices.htm
> gs/doc/Drivers.htm
> gs/doc/History9.htm
> gs/doc/Make.htm
> gs/doc/News.htm

2011-04-03 20:24:30 +0000
Gheorghe Savulescu <sags@ghostscript.com>
a17d948ba8edffee3d5cdd710ed495da93d72bda

> Bug 689093 #10/ HTML conformance
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12355 a1074d23-0009-0410-80fe-cf8c14f379e6
> gs/doc/API.htm
> gs/doc/DLL.htm
> gs/doc/Deprecated.htm
> gs/doc/Devices.htm
> gs/doc/Drivers.htm
> gs/doc/Fonts.htm
> gs/doc/Helpers.htm
> gs/doc/Install.htm
> gs/doc/Language.htm
> gs/doc/Lib.htm
> gs/doc/Make.htm
> gs/doc/Projects.htm
> gs/doc/Ps-style.htm
> gs/doc/Ps2epsi.htm
> gs/doc/Ps2pdf.htm
> gs/doc/Ps2ps2.htm
> gs/doc/Psfiles.htm
> gs/doc/Release.htm
> gs/doc/Source.htm
> gs/doc/Unix-lpr.htm
> gs/doc/Use.htm
> gs/doc/Xfonts.htm

2011-04-03 20:24:19 +0000
Gheorghe Savulescu <sags@ghostscript.com>
01a5f1374998c9d24e021ee8851ae36cb58a8230

> Bug 689093 #09/ HTML conformance
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12354 a1074d23-0009-0410-80fe-cf8c14f379e6
> gs/doc/History6.htm
> gs/doc/History7.htm

2011-04-03 20:24:04 +0000
Gheorghe Savulescu <sags@ghostscript.com>
2692aa2af43e7f1d3655fabad728ceca9157f9b5

> Bug 689093 #08/ HTML conformance
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12353 a1074d23-0009-0410-80fe-cf8c14f379e6
> gs/doc/Details8.htm
> gs/doc/History8.htm

2011-04-03 20:23:39 +0000
Gheorghe Savulescu <sags@ghostscript.com>
7215a52b4ae31ceb807da776b2c06f368dc9e275

> Bug 689093 #07/ HTML conformance
> gs/doc/Details.htm

2011-04-03 20:22:54 +0000
Gheorghe Savulescu <sags@ghostscript.com>
9be02f9987043d2f1c4ea6bb1da403e9bbeaa535

> Bug 689093 #06/ HTML conformance
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12351 a1074d23-0009-0410-80fe-cf8c14f379e6
> gs/toolbin/split_changelog.py

2011-04-03 20:22:27 +0000
Gheorghe Savulescu <sags@ghostscript.com>
33674899f2fca8b2ed947862131bc57eb99c749a

> Bug 689093 #05/ HTML conformance
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12350 a1074d23-0009-0410-80fe-cf8c14f379e6
> gs/doc/API.htm
> gs/doc/C-style.htm
> gs/doc/Deprecated.htm
> gs/doc/Details8.htm
> gs/doc/Develop.htm
> gs/doc/Devices.htm
> gs/doc/Drivers.htm
> gs/doc/History5.htm
> gs/doc/History6.htm
> gs/doc/History7.htm
> gs/doc/History8.htm
> gs/doc/Issues.htm
> gs/doc/Language.htm
> gs/doc/Make.htm
> gs/doc/Ps-style.htm
> gs/doc/Release.htm
> gs/doc/Use.htm

2011-04-03 20:21:59 +0000
Gheorghe Savulescu <sags@ghostscript.com>
6b853264c8be1ce8efdf0f511889647d2e3251fa

> Bug 689093 #04/ HTML conformance
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12349 a1074d23-0009-0410-80fe-cf8c14f379e6
> gs/doc/Details8.htm
> gs/doc/History8.htm

2011-04-03 20:21:48 +0000
Gheorghe Savulescu <sags@ghostscript.com>
24d88fd4b1c8c57e01ba295de69b6ff8a7c3431b

> Bug 689093 #03/ HTML conformance
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12348 a1074d23-0009-0410-80fe-cf8c14f379e6
> gs/toolbin/split_changelog.py

2011-04-03 20:20:32 +0000
Gheorghe Savulescu <sags@ghostscript.com>
81cda2e93b17532409bdea39168db92bf2552919

> Bug 689093 #02/ HTML conformance:
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12347 a1074d23-0009-0410-80fe-cf8c14f379e6
> gs/doc/API.htm
> gs/doc/C-style.htm
> gs/doc/Commprod.htm
> gs/doc/DLL.htm
> gs/doc/Deprecated.htm
> gs/doc/Details8.htm
> gs/doc/Details9.htm
> gs/doc/Develop.htm
> gs/doc/Devices.htm
> gs/doc/Drivers.htm
> gs/doc/Fonts.htm
> gs/doc/Helpers.htm
> gs/doc/History1.htm
> gs/doc/History2.htm
> gs/doc/History3.htm
> gs/doc/History4.htm
> gs/doc/History5.htm
> gs/doc/History6.htm
> gs/doc/History7.htm
> gs/doc/History8.htm
> gs/doc/History9.htm
> gs/doc/Install.htm
> gs/doc/Issues.htm
> gs/doc/Language.htm
> gs/doc/Lib.htm
> gs/doc/Make.htm
> gs/doc/News.htm
> gs/doc/Projects.htm
> gs/doc/Ps-style.htm
> gs/doc/Ps2epsi.htm
> gs/doc/Ps2pdf.htm
> gs/doc/Ps2ps2.htm
> gs/doc/Psfiles.htm
> gs/doc/Readme.htm
> gs/doc/Release.htm
> gs/doc/Source.htm
> gs/doc/Unix-lpr.htm
> gs/doc/Use.htm
> gs/doc/Xfonts.htm

2011-04-03 20:19:46 +0000
Gheorghe Savulescu <sags@ghostscript.com>
a5a20b7b8c0443ac5fd8c88bdb3af37390e4bf5c

> Bug 689093 #01/ HTML conformance
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12346 a1074d23-0009-0410-80fe-cf8c14f379e6
> gs/toolbin/makehist.tcl

2011-04-01 23:17:22 +0000
Henry Stiles <henry.stiles@artifex.com>
2674c673a3f4f29c9ca1620c36a97e0bd89c0e18

> Remove temporary development definition used to identify the graphics
> library supported the new ICC code.
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12345 a1074d23-0009-0410-80fe-cf8c14f379e6
> gs/base/gsicc_manage.h
> pcl/pctop.c
> pxl/pxgstate.c
> pxl/pxpthr.c
> pxl/pxtop.c
> xps/xpstop.c

2011-04-01 22:58:42 +0000
Henry Stiles <henry.stiles@artifex.com>
ad470fdd8c23d7597260ec1c068da69075e1d7f8

> Fixes 691870 where the banding code was using an ICC color and the
> "setcolorspace" so the image type was not being set to icc, we do this
> "setcolorspace" so the image type was not being set to icc, we do this
> now explicitly in the PCL/XL code now.
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12344 a1074d23-0009-0410-80fe-cf8c14f379e6
> pxl/pxgstate.c

2011-04-01 18:42:42 +0000
Robin Watts <Robin.Watts@artifex.com>
a51bd3e408207936f0e795280a71253695a9d57e

> Add 2 files missed in commit 12341. These ones WILL have mattered.
> Apoligies for this. A combination of git svn eating my first attempt
> at committing it, and my own base level of incompetence caused this.
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12343 a1074d23-0009-0410-80fe-cf8c14f379e6
> gs/base/gsicc_cms.h
> gs/base/gsicc_lcms.c
> gs/base/lcms2.mak

2011-04-01 18:38:52 +0000
Robin Watts <Robin.Watts@artifex.com>
b3ce17fce356461895d536c65d39defdb0137b06

> Add file that somehow got missed in the lcms2 commit (r12340).
> Not enabled by default so CLUSTER_UNTESTED.
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12342 a1074d23-0009-0410-80fe-cf8c14f379e6
> gs/base/gsicc_lcms2.c

2011-04-01 18:05:33 +0000
Michael Vrhel <michael.vrhel@artifex.com>
b3703b36cb5544d9defd00780d814caed4eae5b4

> Fix so that we have proper antialiasing with softmasks. Fixes bug 687674
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12341 a1074d23-0009-0410-80fe-cf8c14f379e6
> gs/base/gdevp14.c

2011-04-01 18:00:12 +0000
Robin Watts <Robin.Watts@artifex.com>
50ecc84d5463bd013f794a9dd53254c2e295a85e

> Initial import of LittleCMS v2.1 into the Ghostscript/GhostPDL
> build, with simple integration. LittleCMS version 1 is still used by default,
> so no cluster differences expected.
> The version of little cms imported was taken from the lcms git repository,
> commit 314bc7201d340ab303b36a0ade2c37cf40b83a3b, and then a couple of
> small tweaks were applied:
> * lcms2 currently offers no way to get the input/output format for a
> transform, so I add 2 functions (cmsGetTransformInputFormat and
> cmsGetTransformOutputFormat) to do this.
> * lcms2 currently offers no easy way to redirect malloc/free operations
> away from it's internal implementation, so we add a define (LCMS_USER_ALLOC)
> to allow us to be able to define our own functions. This mirrors the
> work done in lcms1 by Michael, I believe.
> The choice of which version of lcms to build with is made by the WHICH_CMS
> define option in the makefile. Currently this is set to lcms by default,
> but can be changed to lcms2 to allow lcms2 to be used instead.
> To make this work, various small tweaks have been required. Firstly, we
> rename gsicc_littlecms.h to gsicc_cms.h, reflecting the fact that this is
> not littlecms specific - rather, it defines the interface that any cms
> would have to provide in order to work with Ghostscript/GhostPDL.
> Secondly, we rename gsicc_littlecms.c to gsicc_lcms.c to make the makefile
> macros easier.
> We add a gsicc_lcms2.c file (derived from copying and editing gsicc_lcms.c)
> that interfaces with lcms2.
> Currently lcms2 builds and appears to run without crashing, but gives
> differing results in some cases. This will need to be solved before we can
> swap over to using lcms2 by default.
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12340 a1074d23-0009-0410-80fe-cf8c14f379e6
> common/msvc_top.mak
> common/ugcc_top.mak
> gs/base/Makefile.in
> gs/base/configure.ac
> gs/base/gs.mak
> gs/base/gsicc.c
> gs/base/gsicc_cache.c
> gs/base/gsicc_littlecms.c
> gs/base/gsicc_littlecms.h
> gs/base/gsicc_manage.h
> gs/base/gxi12bit.c
> gs/base/gxicolor.c
> gs/base/gximono.c
> gs/base/gxipixel.c
> gs/base/lcms.mak
> gs/base/lib.mak
> gs/base/macos-mcp.mak
> gs/base/macosx.mak
> gs/base/msvclib.mak
> gs/base/openvms.mak
> gs/base/ugcclib.mak
> gs/base/unix-gcc.mak
> gs/base/unixansi.mak
> gs/base/winlib.mak
> gs/ghostscript.vcproj
> gs/lcms2/AUTHORS
> gs/lcms2/COPYING
> gs/lcms2/ChangeLog
> gs/lcms2/INSTALL
> gs/lcms2/Lib/BC/BC.txt
> gs/lcms2/Lib/MS/MS.TXT
> gs/lcms2/Makefile.am
> gs/lcms2/Makefile.in
> gs/lcms2/NEWS
> gs/lcms2/Projects/BorlandC_5.5/lcms2.rc
> gs/lcms2/Projects/BorlandC_5.5/lcmsdll.lk
> gs/lcms2/Projects/BorlandC_5.5/lcmsdll.lst
> gs/lcms2/Projects/BorlandC_5.5/mklcmsdll.bat
> gs/lcms2/Projects/VC2008/jpegicc/jpegicc.vcproj
> gs/lcms2/Projects/VC2008/lcms2.rc
> gs/lcms2/Projects/VC2008/lcms2.sln
> gs/lcms2/Projects/VC2008/lcms2_DLL/lcms2_DLL.vcproj
> gs/lcms2/Projects/VC2008/lcms2_static/lcms2_static.vcproj
> gs/lcms2/Projects/VC2008/linkicc/linkicc.vcproj
> gs/lcms2/Projects/VC2008/psicc/psicc.vcproj
> gs/lcms2/Projects/VC2008/resource.h
> gs/lcms2/Projects/VC2008/testbed/testbed.vcproj
> gs/lcms2/Projects/VC2008/tiffdiff/tiffdiff.vcproj
> gs/lcms2/Projects/VC2008/tifficc/tifficc.vcproj
> gs/lcms2/Projects/VC2008/transicc/transicc.vcproj
> gs/lcms2/Projects/VC2010/jpegicc/jpegicc.vcproj
> gs/lcms2/Projects/VC2010/jpegicc/jpegicc.vcxproj
> gs/lcms2/Projects/VC2010/jpegicc/jpegicc.vcxproj.filters
> gs/lcms2/Projects/VC2010/lcms2.rc
> gs/lcms2/Projects/VC2010/lcms2.sln
> gs/lcms2/Projects/VC2010/lcms2_DLL/lcms2_DLL.vcproj
> gs/lcms2/Projects/VC2010/lcms2_DLL/lcms2_DLL.vcxproj
> gs/lcms2/Projects/VC2010/lcms2_DLL/lcms2_DLL.vcxproj.filters
> gs/lcms2/Projects/VC2010/lcms2_static/lcms2_static.vcproj
> gs/lcms2/Projects/VC2010/lcms2_static/lcms2_static.vcxproj
> gs/lcms2/Projects/VC2010/lcms2_static/lcms2_static.vcxproj.filters
> gs/lcms2/Projects/VC2010/linkicc/linkicc.vcproj
> gs/lcms2/Projects/VC2010/linkicc/linkicc.vcxproj
> gs/lcms2/Projects/VC2010/linkicc/linkicc.vcxproj.filters
> gs/lcms2/Projects/VC2010/psicc/psicc.vcproj
> gs/lcms2/Projects/VC2010/psicc/psicc.vcxproj
> gs/lcms2/Projects/VC2010/psicc/psicc.vcxproj.filters
> gs/lcms2/Projects/VC2010/resource.h
> gs/lcms2/Projects/VC2010/testbed/testbed.vcproj
> gs/lcms2/Projects/VC2010/testbed/testbed.vcxproj
> gs/lcms2/Projects/VC2010/testbed/testbed.vcxproj.filters
> gs/lcms2/Projects/VC2010/tiffdiff/tiffdiff.vcproj
> gs/lcms2/Projects/VC2010/tiffdiff/tiffdiff.vcxproj
> gs/lcms2/Projects/VC2010/tiffdiff/tiffdiff.vcxproj.filters
> gs/lcms2/Projects/VC2010/tifficc/tifficc.vcproj
> gs/lcms2/Projects/VC2010/tifficc/tifficc.vcxproj
> gs/lcms2/Projects/VC2010/tifficc/tifficc.vcxproj.filters
> gs/lcms2/Projects/VC2010/transicc/transicc.vcproj
> gs/lcms2/Projects/VC2010/transicc/transicc.vcxproj
> gs/lcms2/Projects/VC2010/transicc/transicc.vcxproj.filters
> gs/lcms2/Projects/mac/._.DS_Store
> gs/lcms2/Projects/mac/LittleCMS/._.DS_Store
> gs/lcms2/Projects/mac/LittleCMS/English.lproj/InfoPlist.strings
> gs/lcms2/Projects/mac/LittleCMS/Info.plist
> gs/lcms2/Projects/mac/LittleCMS/LittleCMS.xcodeproj/mariama.mode1v3
> gs/lcms2/Projects/mac/LittleCMS/LittleCMS.xcodeproj/mariama.pbxuser
> gs/lcms2/Projects/mac/LittleCMS/LittleCMS.xcodeproj/project.pbxproj
> gs/lcms2/Projects/mac/LittleCMS/LittleCMS_Prefix.pch
> gs/lcms2/Projects/mac/LittleCMS/TestBed-Info.plist
> gs/lcms2/README.1ST
> gs/lcms2/aclocal.m4
> gs/lcms2/autogen.sh
> gs/lcms2/bin/Bin.txt
> gs/lcms2/bin/Thumbs.db
> gs/lcms2/config.guess
> gs/lcms2/config.sub
> gs/lcms2/configure
> gs/lcms2/configure.ac
> gs/lcms2/depcomp
> gs/lcms2/doc/LittleCMS2.0 API.pdf
> gs/lcms2/doc/LittleCMS2.0 Plugin API.pdf
> gs/lcms2/doc/LittleCMS2.0 tutorial.pdf
> gs/lcms2/doc/LittleCMS2.1 API.pdf
> gs/lcms2/doc/LittleCMS2.1 Plugin API.pdf
> gs/lcms2/doc/LittleCMS2.1 tutorial.pdf
> gs/lcms2/include/Makefile.am
> gs/lcms2/include/Makefile.in
> gs/lcms2/include/icc34.h
> gs/lcms2/include/lcms2.h
> gs/lcms2/include/lcms2_plugin.h
> gs/lcms2/install-sh
> gs/lcms2/lcms2.pc.in
> gs/lcms2/ltmain.sh
> gs/lcms2/missing
> gs/lcms2/src/Makefile.am
> gs/lcms2/src/Makefile.in
> gs/lcms2/src/cmscam02.c
> gs/lcms2/src/cmscgats.c
> gs/lcms2/src/cmscnvrt.c
> gs/lcms2/src/cmserr.c
> gs/lcms2/src/cmsgamma.c
> gs/lcms2/src/cmsgmt.c
> gs/lcms2/src/cmsintrp.c
> gs/lcms2/src/cmsio0.c
> gs/lcms2/src/cmsio1.c
> gs/lcms2/src/cmslut.c
> gs/lcms2/src/cmsmd5.c
> gs/lcms2/src/cmsmtrx.c
> gs/lcms2/src/cmsnamed.c
> gs/lcms2/src/cmsopt.c
> gs/lcms2/src/cmspack.c
> gs/lcms2/src/cmspcs.c
> gs/lcms2/src/cmsplugin.c
> gs/lcms2/src/cmsps2.c
> gs/lcms2/src/cmssamp.c
> gs/lcms2/src/cmssm.c
> gs/lcms2/src/cmstypes.c
> gs/lcms2/src/cmsvirt.c
> gs/lcms2/src/cmswtpnt.c
> gs/lcms2/src/cmsxform.c
> gs/lcms2/src/lcms2.def
> gs/lcms2/src/lcms2_internal.h
> gs/lcms2/testbed/Makefile.am
> gs/lcms2/testbed/Makefile.in
> gs/lcms2/testbed/USWebCoatedSWOP.icc
> gs/lcms2/testbed/UncoatedFOGRA29.icc
> gs/lcms2/testbed/bad.icc
> gs/lcms2/testbed/sRGBSpac.icm
> gs/lcms2/testbed/sRGB_Color_Space_Profile.icm
> gs/lcms2/testbed/sRGB_v4_ICC_preference.icc
> gs/lcms2/testbed/testcms2.c
> gs/lcms2/testbed/testthread.cpp
> gs/lcms2/testbed/toosmall.icc
> gs/lcms2/utils/common/utils.h
> gs/lcms2/utils/common/vprf.c
> gs/lcms2/utils/common/xgetopt.c
> gs/lcms2/utils/delphi/delphidemo.dpr
> gs/lcms2/utils/delphi/delphidemo.dproj
> gs/lcms2/utils/delphi/delphidemo.res
> gs/lcms2/utils/delphi/demo1.dfm
> gs/lcms2/utils/delphi/demo1.pas
> gs/lcms2/utils/delphi/lcms2dll.pas
> gs/lcms2/utils/jpgicc/Makefile.am
> gs/lcms2/utils/jpgicc/Makefile.in
> gs/lcms2/utils/jpgicc/iccjpeg.c
> gs/lcms2/utils/jpgicc/iccjpeg.h
> gs/lcms2/utils/jpgicc/jpgicc.1
> gs/lcms2/utils/jpgicc/jpgicc.c
> gs/lcms2/utils/linkicc/Makefile.am
> gs/lcms2/utils/linkicc/Makefile.in
> gs/lcms2/utils/linkicc/linkicc.1
> gs/lcms2/utils/linkicc/linkicc.c
> gs/lcms2/utils/matlab/icctrans.c
> gs/lcms2/utils/matlab/lcms_rsp
> gs/lcms2/utils/psicc/Makefile.am
> gs/lcms2/utils/psicc/Makefile.in
> gs/lcms2/utils/psicc/psicc.1
> gs/lcms2/utils/psicc/psicc.c
> gs/lcms2/utils/samples/Makefile.am
> gs/lcms2/utils/samples/Makefile.in
> gs/lcms2/utils/samples/itufax.c
> gs/lcms2/utils/samples/mkcmy.c
> gs/lcms2/utils/samples/mkgrayer.c
> gs/lcms2/utils/samples/mktiff8.c
> gs/lcms2/utils/samples/roundtrip.c
> gs/lcms2/utils/samples/vericc.c
> gs/lcms2/utils/samples/wtpt.1
> gs/lcms2/utils/samples/wtpt.c
> gs/lcms2/utils/tificc/Makefile.am
> gs/lcms2/utils/tificc/Makefile.in
> gs/lcms2/utils/tificc/tifdiff.c
> gs/lcms2/utils/tificc/tificc.1
> gs/lcms2/utils/tificc/tificc.c
> gs/lcms2/utils/transicc/Makefile.am
> gs/lcms2/utils/transicc/Makefile.in
> gs/lcms2/utils/transicc/transicc.1
> gs/lcms2/utils/transicc/transicc.c
> gs/psi/int.mak
> gs/psi/msvc.mak
> gs/psi/os2.mak
> main/pcl6_gcc.mak
> main/pcl6_msvc.mak

2011-04-01 16:44:50 +0000
Michael Vrhel <michael.vrhel@artifex.com>
b960ff15c895dbe5a7d6baf470ad8a12949ad054

> Fix for mistaken double allocation of threshold array object. Thanks to ray for finding this.
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12339 a1074d23-0009-0410-80fe-cf8c14f379e6
> gs/base/gsht.c

2011-04-01 16:39:59 +0000
Michael Vrhel <michael.vrhel@artifex.com>
66adf73f5cbaa010b6a7ee730384c3a58752bff3

> Fix so that anti-aliasing works when the source file contains transparency. This involved the addition of a copy_alpha procedure for the gdevp14 device. In addition, the anti-aliasing parameters for the target device are passed along to the gdevp14 device. The gdevp14 clist device uses the forward copy alpha operation, so that we end up using the clist_copy_alpha operation. Then during the clist reading phase we use the gdevp14 device's copy_alpha command.
> There are two things that I do need to do in relation to this commit. One is that the operation that actually computes and applies the alpha associated with the transparency needs to be optimized so that we are not doing floating point math. Also, support needs to be added for knockout fills. However, for the vast majority of files with transparency we should now have support with -dGraphicAlphaBits and -dTextAlphaBits.
> I will open a bug on the two outstanding issues so that I don't forget.
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12338 a1074d23-0009-0410-80fe-cf8c14f379e6
> gs/base/gdevnfwd.c
> gs/base/gdevp14.c

2011-03-31 17:30:58 +0000
Henry Stiles <henry.stiles@artifex.com>
7825ac4552256609c8060b5af13bb168170db6eb

> Bug #692100, padding was being treated inconsistently within 2
> procedures resulting in UMR's and incorrect results. I'm afraid we
> still don't understand the details of HP's seemingly bug-ridden
> padding implementation but this fix at least makes the code internally
> consistent.
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12337 a1074d23-0009-0410-80fe-cf8c14f379e6
> pxl/pximage.c

2011-03-31 17:22:23 +0000
Henry Stiles <henry.stiles@artifex.com>
91b7f320484904d60e8cf017611f5a8da4a6c685

> Fixes 692109, the "no argument case" of the HPGL/2 INPUT RELATIVE
> Fixes 692109, the "no argument case" of the HPGL/2 INPUT RELATIVE
> command did not properly initialized the operands to their defaults.
> Only likely to be seen in unusual test cases. Fixes indeterminacy
> in CET 32-07.BIN reported in the regression tests.
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12336 a1074d23-0009-0410-80fe-cf8c14f379e6
> pcl/pgconfig.c

2011-03-31 15:36:32 +0000
Chris Liddell <chris.liddell@artifex.com>
65ea9547d5760284c68da6b6b413d335e4e68ed1

> The last of Hintak's (usable) improvements to the nsis installer
> script, plus a tweak or two.
> Make the cidfmap generation a tickbox option on the final page.
> Add a link to the uninstaller from the Start Menu group.
> No cluster differences
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12335 a1074d23-0009-0410-80fe-cf8c14f379e6
> gs/psi/nsisinst.nsi

2011-03-30 15:33:28 +0000
Chris Liddell <chris.liddell@artifex.com>
700f41807524588d82a674c3618322f71bbe9d7b

> Bring the nsis installer script and it's caller up
> to date.
> Vast majority of the credit to Hintak for this.
> No cluster differences.
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12334 a1074d23-0009-0410-80fe-cf8c14f379e6
> gs/psi/nsisinst.nsi
> gs/psi/winint.mak

2011-03-30 12:23:41 +0000
Robin Watts <Robin.Watts@artifex.com>
c428998ab5d6b6f164de9474c25ee788ae4ef77f

> Squash a warning in a device call.
> No cluster differences expected.
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12333 a1074d23-0009-0410-80fe-cf8c14f379e6
> gs/base/gxclpath.c

2011-03-30 11:13:37 +0000
Tor Andersson
807af34ac8671f03b8c73cca2cdbebca796c716e

> xps: Fix bug when parsing cluster mappings.
> We incorrectly encoded and emitted all characters in a
> Many-to-One cluster mapping, resulting in extraneous characters
> where ligatures were used. A (2:1) cluster map for the ligature
> "fi" has two characters (f, i) and one glyph (fi). We showed it
> as two glyphs (fi, i) instead of skipping the second character
> while decoding the cluster map.
> This fixes multiple errors in MXDW/TypeSamples.xps
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12332 a1074d23-0009-0410-80fe-cf8c14f379e6
> xps/xpsglyphs.c

2011-03-30 10:17:57 +0000
Robin Watts <Robin.Watts@artifex.com>
2e594aee0d69b99a17fa9cd3cf21696773afde43

> Add gs/doc to Visual Studio project, enabling documentation to be easily
> edited in the Visual Studio editor.
> No cluster differences expected.
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12331 a1074d23-0009-0410-80fe-cf8c14f379e6
> gs/ghostscript.vcproj

2011-03-30 10:17:42 +0000
Robin Watts <Robin.Watts@artifex.com>
790f395b044a7e7179c3ca918e30475827c8a30b

> Add documentation for dev_spec_op to Devices.htm.
> No cluster changes.
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12330 a1074d23-0009-0410-80fe-cf8c14f379e6
> gs/doc/Drivers.htm

2011-03-30 10:17:26 +0000
Robin Watts <Robin.Watts@artifex.com>
a243545401bf0fdb8b1a18e7e5379119c56aecfa

> Add new copy_plane device procedure; arguments as for copy_color with an
> extra int to identify which plane we want to work on.
> The call effectively says "Copy this pixmap into the specified plane of this
> device". It is envisaged that it will only be defined for planar devices.
> For now clients can detect whether or not to use this based on whether the
> function pointer is non NULL. If need be (to cope with forwarding devices)
> we can add a dev_spec_op.
> No cluster differences expected.
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12329 a1074d23-0009-0410-80fe-cf8c14f379e6
> gs/base/gdevdflt.c
> gs/base/gdevmpla.c
> gs/base/gxdevcli.h

2011-03-30 10:17:10 +0000
Robin Watts <Robin.Watts@artifex.com>
3bdda000eabced6e4c015af4c6dbb5b02f1abdda

> Add new dev_spec_op operation for spotting that a device maps colours in
> the 'standard' 1bit cmyk way, and use that rather than manually checking
> function pointers. This allows bitcmyk, pamcmyk4 and plibk devices to
> correctly spot the optimisation in get_bits (used for rops that use D).
> Testing locally indicates that the special case is now taken, but that no
> differences are seen in the results (as we would hope).
> No cluster differences expected.
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12328 a1074d23-0009-0410-80fe-cf8c14f379e6
> gs/base/gdevdflt.c
> gs/base/gdevdgbr.c
> gs/base/gdevdrop.c
> gs/base/gxclpath.c
> gs/base/gxdevsop.h

2011-03-30 10:16:54 +0000
Robin Watts <Robin.Watts@artifex.com>
f81e8f47c06572ecc4f7e3fcc03ca4db60507ce4

> Tweak dev_spec_op implementations so that they correctly forward through
> to the 'default' (or base) implementations for unknown operations. Stupid
> of me to have got this wrong initially, as it is one of the main purposes
> of this mechanism.
> No cluster differences expected.
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12327 a1074d23-0009-0410-80fe-cf8c14f379e6
> gs/base/gdevnfwd.c
> gs/base/gdevpdfd.c
> gs/base/gdevpdfi.c
> gs/base/gxacpath.c

2011-03-30 10:15:18 +0000
Robin Watts <Robin.Watts@artifex.com>
bca8531f23845a6c70cf938fb0ab1bc6e9f14fd9

> Add new dev_spec_op call to device procs table, along with gxdevsop.h header
> that defines the operation enumeration for it.
> Move existing calls of pattern_manage across to using dev_spec_op instead.
> Add comments to the pattern management definitions noting that it is
> deprecated and should not be used.
> No cluster differences (aside from indeterminisms).
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12326 a1074d23-0009-0410-80fe-cf8c14f379e6
> gs/base/gdevbbox.c
> gs/base/gdevdflt.c
> gs/base/gdevdrop.c
> gs/base/gdevnfwd.c
> gs/base/gdevp14.c
> gs/base/gdevpdfb.h
> gs/base/gdevpdfd.c
> gs/base/gdevpdfi.c
> gs/base/gdevpdfx.h
> gs/base/gdevrops.c
> gs/base/gscolor3.c
> gs/base/gsimage.c
> gs/base/gsptype1.c
> gs/base/gsptype2.c
> gs/base/gxacpath.c
> gs/base/gxcldev.h
> gs/base/gxclip.c
> gs/base/gxclip2.c
> gs/base/gxclipm.c
> gs/base/gxclist.c
> gs/base/gxclrect.c
> gs/base/gxdevcli.h
> gs/base/gxdevice.h
> gs/base/gxdevsop.h
> gs/base/gxfill.c
> gs/base/gximask.c
> gs/base/gxpcmap.c
> gs/base/gxshade6.c
> gs/psi/zpcolor.c xps/xpstile.c

2011-03-30 09:26:50 +0000
Chris Liddell <chris.liddell@artifex.com>
ed774ca984d2566b00e212d130644abd5529235f

> Update version number post-release.
> git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12325 a1074d23-0009-0410-80fe-cf8c14f379e6
> gs/Resource/Init/gs_init.ps
> gs/base/gscdef.c
> gs/base/version.mak

## Version 9.02 (2011-03-30)

This is the third release in the stable 9.x series.

This is an "out of order" release, primarily to ensure the GPL Ghostscript release remains in version "lock-step" with the Artifex commercial release.

Highlights in this release include:

For monochrome devices, there is a new halftone technique for sampled image data. The existing technique is very efficient (and is is still used) for large areas of color, such as an area fill, but encountered performance problems dealing with sampled image data where a given colour value only covered a few pixels at a time. The new approach applies the halftone threshold array directly to the image samples.

Further performance, memory use, and stability improvements with the new features introduced in 9.00, as well as Unix/Linux build fixes, plus the usual assorted bug fixes.

For a list of open issues, or to report problems, please visit bugs.ghostscript.com.

### Incompatible changes

No recorded incompatible changes.

### Changelog

2011-03-30T06:48:01.334550Z chrisl

>     Extend the SSE2 check in both configure scripts.

>     The check now attempts to declare a variable of a type missing in older
>     versions of gcc.

>     Bug 692102

>     No cluster differences expected.

> [base/configure.ac /trunk/ghostpdl/configure.ac]

2011-03-28T08:49:48.387061Z Chris Liddell

>     Reduce duplication of changelog and news by deprecating Changes.htm and
>     Details#.htm.

>     The information will now be in two places only: the highlights summary
>     in News.htm, and the detailed changes in History#.htm.

>     Update related documentation and html links to reflect this change.

>     CLUSTER_UNTESTED

> [doc/Changes.htm doc/Readme.htm doc/Details9.htm doc/Release.htm]

2011-03-26T14:51:06.549590Z Michael Vrhel

>     Fix for issue found by Chris where we have a soft mask embedded in a softmask
>     and graphic state pushes and pops occurring.  In this case, the soft mask stack
>     that is saved gets out of sync compared to the one in the context state.
>     Use of the stack count can catch the issue and correct it.  Also a rename of
>     one of the variables in the pdf14 code to make it easier to debug.

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

2011-03-25T12:12:05.657797Z Till Kamppeter

>     Fixes concerning the compatibility of the OpenPrinting Vector ("opvp")
>     output device with Ghostscript 9.x.

>     1. If there is any ICCColor based image in the PostScript input, GS crashes.
>     2. Fallback when path is too complex for some kinds of printers. This problem
>     already existed in GS 8.x.

>     Thanks to Koji Otani from BBR Inc., Japan.

> [contrib/opvp/gdevopvp.c]

2011-03-25T10:22:06.357287Z Chris Liddell

>     The code was erroneously attempting to get a glyph name for a case where
>     we already had a glyph index for a Truetype font.

>     Add a check for object type before trying to get a string from a name object.

>     Bug 692095

>     No cluster differences expected.

> [psi/zfapi.c]

2011-03-24T17:26:17.397320Z Chris Liddell

>     Resolve build issues with language_switch and UFST.

>     I had (wrongly) assumed that the PCL/language_switch builds with UFST
>     and COMPILE_INITS=1 would have the relevant paths correctly setup for
>     the PS/PDF world to access the Microtype FCOs. It turns out they are
>     done in an incompatible manner.

>     So, I've renamed the path variables (in the makefiles) so there isn't
>     a clash between PCL and PS/PDF, ensured that the variables are correctly
>     passed through recursive (n)make calls, and tidied up the FAPI options
>     for the language_switch build.

>     Not only does this allow language_switch to build with the UFST, but the
>     Postscript interpreter does now use FAPI/UFST to access the Microtype fonts
>     for the built-in fonts, and uses FAPI/Freetype for downloaded fonts.

>     Bug 692093

>     No cluster differences expected.

> [/trunk/ghostpdl/common/msvc_top.mak /trunk/ghostpdl/language_switch/pspcl6_msvc.mak /trunk/ghostpdl/main/pcl6_gcc.mak psi/msvc.mak base/Makefile.in psi/int.mak]

2011-03-24T04:22:23.459616Z Michael Vrhel

>     Fix for compiler warning.

> [base/gdevp14.h]

2011-03-23T21:34:20.429081Z Michael Vrhel

>     This commit fixes several issues.

>     Memory leaks in the PDF14 device as well as the separation devices.
>     Fixes in PDF14 device so the the color encoder and decoder are properly updated
>     if soft masks occur with spot colors.
>     Proper copying of the devicen parameters to the clist devices in the MT
>     rendering.  This was the source of a problem when doing multi-threaded
>     rendering to separation devices.

>     This fixes bug 692087

> [base/gdevp14.c base/gsicc_cache.c base/gxclutil.c base/gdevpsd.c base/lib.mak base/gdevp14.h base/gxclthrd.c base/gdevtsep.c base/gdevdevn.c base/gxblend.c base/gdevdevn.h]

2011-03-21T11:24:17.021832Z Michael Vrhel

>     Fix for memory leaks in the pdf14 device.  These could occur with softmask and
>     graphic state changes as well as when we are going to a tiffsep device.

> [base/gdevp14.c]

2011-03-20T01:40:19.345427Z Michael Vrhel

>     Fix for bug 692087 crashes.   num_bytes - bytes_dropped was ending up negative
>     in cases where the transparency device was reducing the number of colorants
>     compared to the target device (mainly when we had a softmask) which was getting
>     passed into the clist as an unsigned value.   Now when this occurs we just use
>     the encoding of the full color value.

> [base/gxclutil.c]

2011-03-19T04:56:52.259544Z Michael Vrhel

>     A temp fix for bugs 692038 and 692065.  The clist devices that are created for
>     the threads now inherit the icc profile from the target device.  I need to set
>     things up so that the device profile is no longer reference counted since we
>     could have a race condition problem if the different threads are incrementing
>     and decrementing the count and if the command is not atomic on a particular
>     architecture.  The plan will be to no longer ref count the device profile but
>     to have it maintained until the the actual target device is destroyed. There
>     will be a bit of work to do with respect to the pdf14 device, which can have
>     a device profile that is different than the actual target device.  That profile
>     can be altered with the transparency group pushes and pops.

> [base/gxclthrd.c]

2011-03-19T00:32:37.910024Z Ray Johnston

>     Fix for some strange rendering with PDF 1.7 FTS files when we have shading and
>     transparency and are both filling and stroking text (Text Rendering modes 2
>     and 6). Customer 532.

> [Resource/Init/pdf_ops.ps]

2011-03-18T05:16:08.669973Z Michael Vrhel

>     Fix so that image_parent_type is properly initialized during clist image
>     reading.

> [base/gsiparm4.h base/gximage1.c base/gximage4.c]

2011-03-17T15:24:58.552348Z Chris Liddell

>     Escape/quote the UFST path settings in the makefile so that the macros
>     correctly expand to strings.

>     Bug 692082

>     No cluster differences expected

>     CLUSTER_UNTESTED

> [base/Makefile.in]

2011-03-17T09:54:53.062174Z Chris Liddell

>     Uncached glyphs were ignoring rendering mode 3, and being imaged
>     directly to the device - for cached glyphs the decision occurred
>     in the "show machinery".

>     This wasn't my first choice solution, but all the others I tried
>     caused problems with later use of a cached glyph (which wasn't
>     actually cached), or problems with pdfwrite, pswrite or ps2write.

>     Bug 692004

>     No cluster differences expected.

> [base/gspaint.c]

2011-03-17T09:41:16.074991Z Chris Liddell

>     Fix some issue where user specified devices didn't get the requisite
>     "$(DD)" and ".dev" runes added to them.

>     Also, rearrange the "pre-declared" device strings to be more
>     consistent within configure.ac

>     Bug 692062

>     No cluster differences expected.

> [base/configure.ac]

2011-03-15T17:59:17.340024Z Robin Watts

>     Add special case mem_planar_copy_color_4to1 code for copying bits
>     from 4 1 bit planes into 1 4 bit chunky plane.

>     This helps with performance of the plibk device.

>     No cluster differences expected.

> [base/gdevmpla.c]

2011-03-15T08:35:05.386182Z Ken Sharp

>     Fix (ps2write) : Indexed colour images have incorrect /Decode

>     Bug #691924 "Differences in colour with ps2write"

>     The problem was due to the opdfread code generating a /Decode for an Indexed
>     colour space where the value was [0 2^n] and should be [0 ((2^n) - 1)]. This
>     caused the highest image sample to be mapped to 1 past the end of the samples
>     in the colour space.

>     Normally this doesn't matter, because the values are clamped to 'hival' in the
>     Indexed space. In this case, however, the image was 2 bpp (4 values) but the
>     colour space was defined as a full 256 indices, with only the first 4 bein
>     used.

>     The incorrect Decode caused the image sample value 3 to be looked up as colour
>     space sample 4, which was set to all 0 (black) causing incorrect colour values.

> [base/opdfread.h lib/opdfread.ps]

2011-03-14T15:46:15.599171Z Robin Watts

>     Reintroduce commented out PACIFY_VALGRIND definition in gximono.c - without it
>     the comment makes no sense.

>     Add new PACIFY_VALGRIND code (and commented out definition) in
>     gxht_threshold.c.

>     Fix some line endings.

>     No real code change, so no cluster differences expected.

> [base/gximono.c base/gxht_thresh.c]

2011-03-14T15:16:08.036660Z Robin Watts

>     Fix an indetermism in the halftoning code. When mapping a y offset into a
>     row index for a halftone tile, special care needs to be taken when y is
>     negative. Proof (as if more were needed) that the % operator in C is evil.

>     The command in question was a cutdown version of C306.bin rendered at 600bpi
>     to pbmraw with dMaxBitmap=10000.

>     It now runs into a clist UMR. Will keep looking.

> [base/gximono.c]

2011-03-14T13:53:51.702509Z Ken Sharp

>     Fix (ps2write) : Don't set a default halftone.

>     Bug #691923 "Differences in dithered output with ps2write"

>     The PDF interpreter emits a setpagdevice between every page of output, in case
>     the media size has changed. The implementation of setpagedevice resets the
>     halftone to be the default halftone (106 lpi 45 degree line screen).

>     This is a problem for ps2write, and potantially pdfwrite, as there is no way to
>     differentiate between a default halftone set by setpagdevice, and a halftone
>     contained in the input file.

>     To avoid embedding an unhelpful halftone, we now check the device parameter
>     '/HighLevelDevice' in the setpagedevice implementation, and if it is present
>     and true, we do not call .setdefaulthalftone.

>     Also updates documentation on device parameters.

>     This causes differences on every 1-bit rendering test (ie pkmraw) of the
>     ps2write output file, so approximately 1300 differences are to be expected.

> [doc/Drivers.htm Resource/Init/gs_setpd.ps]

2011-03-14T13:00:03.503443Z Robin Watts

>     Fix Bug 692064. Tiffscaled device was checking on page print time that the
>     expected size of the page wouldn't make the page too large to fit in a file.
>     This code was copied from the tiffgray device (as we render internally in
>     8bpp). As we output in monochrome however (and may use compression) the
>     test is in fact bogus, and should simply be removed. We do that here.

>     It's entirely possible that we should be removing the test from the
>     tiffgray device too - most systems with 32bit longs support large files these
>     days, and compression may apply here too anyway. I'll leave this until it
>     becomes an issue though.

>     No cluster differences expected.

> [base/gdevtsep.c]

2011-03-13T11:57:08.378919Z Ken Sharp

>     Some updates to the new device parameters. It turned out that the intended
>     parameter Type32ToUnicode was incorrectly implemented. This should actually
>     have used the WantsToUnicode parameter, because the code actually controls the
>     processing of  GlyphNames2Unicode tables from Windows PostScript.

>     This means we no longer need the Type32ToUnicode parameter and it has been
>     removed.

>     Added initial documentation of these parameters.

>     This appears to cause some differences in Bug690829.ps rendered at 300 dpi.
>     This is a surprise, because the changes should have no effect on devices other
>     than pdfwrite/ps2write, but the new result is better than the old, so this is
>     a progression.

> [Resource/Init/gs_pdfwr.ps base/gdevpdfx.h base/gdevpdfp.c doc/Drivers.htm base/gdevpdfb.h]

2011-03-13T01:21:49.785339Z Ray Johnston

>     Remove spurious debug printout inserted in rev 12141 line 780:
>     1 index == 0 index ==

> [Resource/Init/pdf_draw.ps]

2011-03-11T19:24:57.067395Z Ken Sharp

>     Change the default value for the 'AllowPSRepeat' so that it defaults to allowed
>     instead of disallowed (doh!) This is important for those devices which don't
>     set the device parameter.

>     No differences expected.

> [psi/zfunc4.c]

2011-03-11T17:14:51.124213Z Ken Sharp

>     Remove a #if 0 accidentally left in the commit for revision 12282. Also
>     initialise a variable, just in case.

>     No differences expected.

> [psi/zfunc4.c]

2011-03-11T16:58:34.690669Z Ken Sharp

>     The final removal of the reliance on testing the device name to influence
>     interpreter behaviour.

>     This tests the /AllowPSRepeat paramter and flags an error if a function tries
>     to use 'repeat' when it is disallowed.

>     Still to do: write some documentation on these new parameters.

>     No differences expected.

> [psi/zfunc4.c]

2011-03-11T15:14:40.609962Z Chris Liddell

>     Add the new third party library directories to the Windows nmake zip file
>     target.

>     No cluster differences.

>     Bug 691944

>     Credit to: Gennadiy Tsarenkov.

>     CLUSTER_UNTESTED

> [psi/winint.mak]

2011-03-11T15:07:56.095474Z Chris Liddell

>     Rejig the romfs targets so that unix make can follow the dependencies.

>     This should prevent the pointless rebuilding of the romfs C source.

>     Bug 692053

>     No cluster differences expected.

> [base/lib.mak base/unix-aux.mak]

2011-03-11T09:04:24.536166Z Chris Liddell

>     Some (broken) TrueType fonts have out of order loca tables, which can result
>     in the calculated glyph data lengths being larger than the actual
>     available glyph data. Normally this does not cause a problem, but if the glyph
>     in question is in the final bytes of the stream, we encounter an unexpected
>     end of data condition when creating the glyph data buffer to pass into
>     Freetype.

>     So the FAPI interface code will now ignore that error, and adjust the byte
>     length to correctly reflect the number of bytes available in the buffer.

>     It is safe to do this because, in the event we have a genuine out-of-data
>     condition, Freetype will return an error when it tries to interpret the
>     glyph outline.

>     Bug 692043

>     No cluster differences expected.

> [psi/fapi_ft.c psi/zfapi.c]

2011-03-11T05:45:19.450208Z Alex Cherepanov

>     Fix missing header problem on older versions of MSVC.

> [base/gsropt.h]

2011-03-11T04:15:39.316030Z Michael Vrhel

>     A reorganization of the halftone code in preparation of doing thresholding of
>     color images.  This basically pulls out some code pieces that will be shared
>     in all the image thresholding cases.  No differences expected
>     (or seen in the cluster push).

> [base/gxht_thresh.h base/lib.mak base/gximono.c base/gxicolor.c base/gxht_thresh.c]

2011-03-10T17:31:38.501799Z Robin Watts

>     I missed one change in commit 12274. The detection of chunky modes should
>     look at num_planes being <= 1, not == 1.

>     I tested this locally and then clearly missed it when cluster pushing.

> [base/gdevdrop.c]

2011-03-10T16:56:15.200283Z Robin Watts

>     Planar device is broken w.r.t rops in a cmyk space - this commit fixes it.

>     The planar memory device sets itself to use gx_default_strip_copy_rop
>     rather than mem_strip_copy_rop. mem_strip_copy_rop knows that rops on
>     cmyk pixels should actually convert to rgb, perform the rop, and convert
>     back again, but doesn't know how to convert the results back when it's in
>     planar mode. gs_default_strip_copy_rop can cope with planar mode, but doesn't
>     know to convert to rgb first.

>     The first fix included here is to extend mem_strip_copy_rop to know how to
>     write back to planar format, and then to make the planar memory device use
>     mem_strip_copy_rop.

>     This then exposes various flaws in mem_strip_copy_rop, including the fact
>     that it relies on being able to set the offset in get_bits calls when this
>     is sometimes not possible. We therefore fix the code to manage offsets
>     by explicitly updating them.

>     Also, the raster used in mem_strip_copy_rop was incorrect - we use the
>     correct one and get much better results.

>     No cluster differences expected as the planar device is not tested.

> [base/gdevdrop.c base/gdevmpla.c]

2011-03-10T16:42:20.394889Z Robin Watts

>     The routines in gdevplib.c intended to map colors in cmyk form back to rgb
>     were incorrect. Fixed here.

>     No differences expected as this files isn't linked in by default.

>     CLUSTER_UNTESTED

> [base/gdevplib.c]

2011-03-10T16:27:04.913812Z Robin Watts

>     Remove the buffer blanking done in gximono.c. Previously removing this would
>     have caused indeterminisms. With the additional fix in here to limit
>     offset_bits to dest_width, however, we should get stable results.

>     This gives various differences in output (81 in pcl, presumably more in PDF
>     and PS). Bmpcmp of the pcl ones shows them as all progressions.

> [base/gximono.c]

2011-03-10T14:55:08.103488Z Ken Sharp

>     Update the remaining PostScript files (mostly the PDF interpreter) to use the
>     new device parameters instead of explicitly checking for the device being named
>     'pdfwrite' or 'ps2write'.

>     Some more modification is still required, but we're nearly there. We will
>     continue to check the device names in gs_pdfwr.ps when setting up the default
>     state for those specific devices.

>     Although not strictly a Distiller device, ps2write declares itself to be
>     'IsDistiller'. This is because some PostScript test files were found to behave
>     differently if the distillerparams operators were available, in particular
>     files would be oriented differently if the device was deemed to be a Distiller.

> [Resource/Init/gs_pdfwr.ps Resource/Init/pdf_font.ps Resource/Init/pdf_draw.ps base/gdevpdfb.h Resource/Init/gs_setpd.ps]

2011-03-10T07:31:45.990562Z Alex Cherepanov

>     Ignore null object when it is used instead of the gstate dictionary.
>     Bug 692050.

> [Resource/Init/pdf_main.ps]

2011-03-10T06:19:17.004672Z Alex Cherepanov

>     Change all instances of true, false, and null to //true, //false, and //null
>     to avoid interferance from PS files that redefine them. Bug 692041.

> [Resource/Init/gs_typ32.ps Resource/Init/gs_cidfm.ps Resource/Init/gs_mgl_e.ps Resource/Init/pdf_rbld.ps Resource/Init/gs_resmp.ps Resource/Init/gs_dscp.ps Resource/Init/gs_fonts.ps Resource/Init/gs_wan_e.ps Resource/Init/gs_mex_e.ps Resource/Init/gs_ttf.ps Resource/Init/gs_cspace.ps Resource/Init/gs_cff.ps Resource/Init/gs_dps1.ps Resource/Init/gs_lev2.ps Resource/Init/pdf_sec.ps Resource/Init/gs_l2img.ps Resource/Init/gs_cet.ps Resource/Init/gs_dbt_e.ps Resource/Init/gs_pdf_e.ps Resource/Init/gs_statd.ps Resource/Init/gs_fapi.ps Resource/Init/gs_pdfwr.ps Resource/Init/gs_cidfn.ps Resource/Init/pdf_main.ps Resource/Init/gs_dps.ps Resource/Init/gs_res.ps Resource/Init/gs_ll3.ps Resource/Init/gs_css_e.ps Resource/Init/gs_epsf.ps Resource/Init/pdf_draw.ps Resource/Init/gs_dpnxt.ps Resource/Init/gs_icc.ps Resource/Init/gs_mro_e.ps Resource/Init/pdf_ops.ps Resource/Init/gs_init.ps Resource/Init/pdf_font.ps Resource/Init/gs_ciddc.ps Resource/Init/gs_trap.ps Resource/Init/gs_cidtt.ps Resource/Init/gs_diskn.ps Resource/Init/gs_fntem.ps Resource/Init/pdf_base.ps Resource/Init/gs_sym_e.ps Resource/Init/gs_img.ps Resource/Init/gs_btokn.ps Resource/Init/gs_cidcm.ps]

2011-03-10T00:58:08.762234Z Michael Vrhel

>     Fix for bug 692038.

>     This fixes 3 issues when using a CIELAB based profile for the output device
>     ICC profile.

>     One was a problem when handling separation color spaces when they had the ALL
>     entry and we were going to an additive device.  AR does a 1-INK level for the
>     device values and no color management.  We were doing the same, but this approach
>     will not work if our destination color space is CIELAB.  Now if we are headed toward
>     CIELAB we do the 1-INK to RGB and then transform to CIELAB.

>     Another was that transparency blending should never be done in CIELAB or similar type
>     color spaces.  With transparency, the PDF14 device inherits the profile for the target
>     device and if the transparency groups don't specify a color space we would end up blending
>     in CIELAB.  The solution was to detect this situation and use the defaultRGB profile for blending.
>     Conversion to CIELAB occurs during the pdf14 put image operation.

>     Finally, with shading in transparency, we need to make sure to pass along the transparency device
>     through the shading parameters whenever we have a color mismatch between the pdf14 device and the
>     target device so that the shading will occur in the proper color space.

>     These changes are all related to a non-tested cluster case when we have -sOutputICCProfile=lab.icc

> [base/gdevp14.c base/gxcmap.c base/gstrans.c base/gxclist.h base/gdevtfnx.c base/gsfunc0.c base/devs.mak base/gsicc.c]

2011-03-09T21:32:58.461339Z Robin Watts

>     Add gxht_thresh.{c,h} to Visual C project.

>     CLUSTER_UNCHECKED

> [ghostscript.vcproj]

2011-03-09T14:44:40.068733Z Robin Watts

>     Disable PACIFY_VALGRIND in gximono.c. This define is intended to enable
>     extra code that can be performed so as to ensure that valgrind doesn't
>     report false positives. As such, disabling it should have no adverse
>     effects.

>     Unfortunately, it seems that in the portrait case, if we don't blank the
>     threshold array before we run, we get diffs. I have therefore taken this
>     memset out of the PACIFY_VALGRIND case and forced it to always happen.
>     This probably points to a bug and should be investigated properly.

>     No cluster differences expected.

> [base/gximono.c]

2011-03-08T20:00:17.821965Z Robin Watts

>     Simple optimisations to non SSE2 versions of halftoning code. There is
>     probably (certainly!) more performance to come with loop unrolling etc,
>     but this at least gets us the cheap win of avoiding repeated array accessing,
>     only setting, not blanking bits etc.

>     Cluster tests show no changes.

> [base/gxht_thresh.c]

2011-03-08T17:40:51.077420Z Robin Watts

>     Change to gsroprun1.h to avoid over/underreading the source/texture buffers.

>     Given a valid byte range we expand that to the smallest enclosing CHUNK range
>     and guarantee never to access out of that range. Previously we could read
>     one CHUNK before/after it.

>     If this is a problem, simply ensure that CHUNK is byte rather than int on
>     your platform. This now behaves better than the original code which would
>     access one byte before/after the defined range.

>     No cluster differences seen in testing.

> [base/gsroprun1.h]

2011-03-08T16:35:16.023687Z Tor Andersson

>     Add PNG reading support to the bmpcmp tool.

> [toolbin/bmpcmp.c]

2011-03-08T15:18:42.397978Z Ken Sharp

>     Update to use the new device parameter /PreserveTrMode instead of explicitly checking
>     for the device name being 'pdfwrite'.

>     No differences expected.

> [Resource/Init/pdf_ops.ps]

2011-03-08T08:27:54.788378Z Ken Sharp

>     Activate the new device parameters, and modify the resource code to use the first one
>     (AllowIncrementalCFF) instead of testing for the pdfwrite device name.

>     No differences expected.

> [Resource/Init/gs_cidfn.ps base/gdevpdfp.c]

2011-03-08T00:26:07.330315Z Robin Watts

>     When using PACIFY_VALGRIND, don't call the memory blanking when the
>     mallocs have failed.

>     This should cure the SEGVs that were introduced, but otherwise cause no
>     changes.

> [base/gximono.c]

2011-03-07T22:19:29.253652Z Michael Vrhel

>     Initialize ht landscape structure to zero when in portrait case.  There is
>     a conditional test on the value later.

> [base/gximono.c]

2011-03-07T21:57:02.879011Z Robin Watts

>     Correct line endings (were DOS, should be Unix).

>     No cluster differences.

>     CLUSTER_UNTESTED

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

2011-03-07T21:17:12.494498Z Robin Watts

>     Add new debugging define to gximono.c, PACIFY_VALGRIND.

>     This enables various small tweaks in the code that stop valgrind throwing
>     errors. We believe that all the errors thrown are false positives, but
>     we enable this define anyway until we've sorted the current indeterminisms.
>     We'll disable it in a few days when we have solved the problems and check that
>     it really doesn't cause any more.

>     Cluster results unknown; probably no change. If this solves indetermisms
>     then we'll need to understand why.

> [base/gximono.c]

2011-03-07T21:11:56.916525Z Robin Watts

>     Fix typos, one in a comment, one in an id string.

>     No cluster differences.

>     CLUSTER_UNTESTED

> [base/gxipixel.c base/gzspotan.c]

2011-03-07T18:58:08.149818Z Michael Vrhel

>     Fix for improper indexing of reversed portrait image line.  We were off
>     by one byte and ended up with one byte not set.  Def. a source of
>     indeterminism.  Thanks to Robin for tracking this down.

> [base/gximono.c]

2011-03-07T15:40:13.201330Z Ken Sharp

>     Undo revision 12243. The revision makes a debug print dependent on the value of the
>     'size_set' variable. Unfortunately, this variable is not defined in the cups_get_matrix
>     routine. It is defined in the other places it is used (cups_put_params).

>     This prevents a debug build from compiling on Windows, and I can't see how it would
>     work on any other OS when built for debug.

>     Reverted the change in order to build debug versions of Ghostscript.

> [cups/gdevcups.c]

2011-03-07T14:21:11.345196Z Ken Sharp

>     Redo revision 12248 in a way which (hopefully!) doesn't cause seg faults.

>     Still no differences expected....

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

2011-03-07T12:40:47.052280Z Chris Liddell

>     Account for fonts in which (some) charstrings have been replaced with
>     Postscript procedures when FAPI decides an outline, or just a width
>     is required. The previous code only handled this case for rendered
>     glyphs from Freetype.

>     Bug 692029

>     No cluster differences expected.

> [psi/zfapi.c]

2011-03-07T11:12:19.973357Z Ken Sharp

>     pdfwrite & ps2write enhancement

>     Add some new keys to the device parameters dictionary for these devices. These will be
>     used to replace the explicit tests against the device name in various places in future
>     commits.

>     These will also later be documented and their use suggested for any devices requiring
>     the same capabilities.

>     No differences expected, these are not used yet.

> [base/gdevpdfp.c]

2011-03-07T09:43:02.986503Z Chris Liddell

>     Update the second place where we may have to reset the Freetype glyph object.

>     Again, this means we only free the outline or bitmap data, and just let
>     Freetype "reset" its glyph object between glyphs.

>     No cluster differences expected.

> [psi/fapi_ft.c]

2011-03-07T07:08:12.439689Z Ray Johnston

>     Fix for compositor device chaining in the pdf14 device. This was detected in a
>     file that did overprint along with transparency. The pdf14 device incremented the
>     ref_count for the overprint_device, but never decremented it since the 'finalize'
>     of the pdf14 device was left at NULL rather than being set to the gx_forward_finalize
>     function which should be used. The gx_device_set_target, rather than rc_assign does
>     the proper set of the finalize proc pointer so that reference counts for the device
>     chain are properly maintained. Detected by customer 532 since their device freed
>     the clist buf_device resulting in the overprint_device having a 'target' pointer
>     to freed memory, causing a SEGV when the 'finalize' function executed.

>     No regressions expected since in the normal code, the GC frees the devices that
>     were left unreferenced by the free of the pdf14 device.

> [base/gdevp14.c]

2011-03-06T16:52:19.765042Z Michael Vrhel

>     Fix to use proper DDA incrementation for interpolation.
>     We still maintain special loops for when there is no scalin
>     or for when it is 2x.  This should fix the intdeterminism issues.
>     Tested performance on customer files and no significant difference
>     was observed.   About 1500 cluster differences will be reported with
>     this fix.

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

2011-03-06T11:15:48.120325Z Chris Liddell

>     Instead of destroying and recreating freetype's glyph object for every glyph
>     we need to render, we can just free the "transient" parts: the bitmap or the
>     outline.

>     Saves a very small amount of time, and potentially reduces memory pool
>     fragmentation.

>     No cluster differences expected.

> [psi/fapi_ft.c]

2011-03-05T17:46:46.608714Z Till Kamppeter

>     Do not do debug output of an uninitialized variable

>     Thanks to Richard Hughes (hughsient at gmail dot com) for the patch.

> [cups/gdevcups.c]

2011-03-04T19:27:50.114304Z Till Kamppeter

>     Correction on Richard Hughes' patch for color management in the CUPS filters.

> [cups/colord.c]

2011-03-04T17:51:00.067911Z Henry Stiles

>     Fix a warning and type error.  Code should produce the same results,
>     so no testing.

>     CLUSTER_UNTESTED

> [base/gdevdgbr.c]

2011-03-04T13:34:11.568425Z Robin Watts

>     Add FIXME to gximono.c about possible future optimisation, so it is not
>     forgotten.

>     CLUSTER_UNTESTED

> [base/gximono.c]

2011-03-04T09:35:04.845642Z Chris Liddell

>     Only attempt to create files in the "cups" directory if it exists.

> [base/configure.ac]

2011-03-04T06:45:29.360251Z Michael Vrhel

>     Reorganization of threshold code to move all the thresh holding operations into a new file.

> [base/gxht_thresh.h base/lib.mak base/gximono.c base/gximage.h base/gxht_thresh.c base/gsiparam.h]

2011-03-04T06:16:53.560659Z Alex Cherepanov

>     Add missing test for /packedarraytype during recursive dereferencing
>     of composite PDF objects. Bug 692018, customer 850.

> [Resource/Init/pdf_base.ps]

2011-03-03T22:20:22.363870Z Henry Stiles

>     The get_bits() device call was assumed to return copied data and fill
>     in the allocated memory pointed to by the variable row, in fact the
>     gets_bit call can also just return a pointer and row is never
>     initialized, now we detect that.  This broke raster operations for the
>     display device and appears to have resulted in the use of
>     uninitialized data in other files.  A sampling of changed files showed
>     single pixel differences in files.

> [base/gdevdgbr.c]

2011-03-03T20:29:23.683592Z Robin Watts

>     Update plibc and plibk to output pams when built with DEBUG_DUMP.

>     No cluster differences possible as this code is not used in cluster testing.

>     CLUSTER_UNTESTED

> [base/gdevplib.c]

2011-03-03T20:23:43.920044Z Robin Watts

>     Add new pamcmyk4 device. Identical to pamcmyk32 device, but works in 1 bit
>     per component, rather than 8.

>     No cluster differences expected as this code isn't tested.

> [psi/msvc.mak base/unix-gcc.mak base/gdevpbm.c base/devs.mak]

2011-03-03T17:51:48.590954Z Michael Vrhel

>     Enabling of thresholding code as default image rendering of monochrome/indexed
>     images for monochrome devices.  This will result in about 2432 differences reported.
>     I stepped through them in a bmpcmp to check for serious issues.  The minor halftone
>     differences were due to the fact that we step in the device space for pixel replication
>     in the threshold code but step in source space for the rect fill code.  Enabling this
>     code now will make it easier to track issues as we expand the use of the thresholding code.

> [base/gximono.c]

2011-03-03T15:48:46.192376Z Robin Watts

>     Add plib device (c and h) files to ghostscript project file.

>     No cluster differences expected as project file is not used by cluster.

>     CLUSTER_UNTESTED

> [ghostscript.vcproj]

2011-03-03T00:08:27.251299Z Marcos H. Woehrmann

>     Added the ability to specify bmpcmp in addition to a normal clusterpush.pl
>     operation.  Both commands will be queued in the correct order.

>     Examples:

>     ./clusterpush.pl gs bmpcmp
>     ./clusterpush.pl bmpcmp gs pcl xps ls

>     Note that the order of the options is not signficant.

>     The command line parser for clusterpush.pl changed signficantly with this
>     revision.  It should be backwards compatible with the previous version
>     but it's possible that subtle differences exist.  If a clusterpush.pl
>     command line behaves differently than you expect please open a bug.

> [toolbin/localcluster/clustermaster.pl toolbin/localcluster/clusterpush.pl toolbin/localcluster/clusterpush.txt]

2011-03-02T22:12:39.208205Z Robin Watts

>     Fix rop operation on plib device. Previously, I'd disabled get_bits_rectangle
>     on the buffer device as the data is normally in the format we need it in
>     anyway, so it's a NOP. Unfortunately it's needed for rop operation, so
>     reintroduce it.

>     To avoid infinite loops, we have to cope with GB_RETURN_POINTER. This is
>     easy to add to the gdevmpla.c device, but it's less clear that adding it
>     into the mem device is the right thing to do. We therefore introduce a
>     shim function to cope with GB_RETURN_POINTER with the mem device.

>     No cluster differences expected as this is disabled by default.

>     Testing shows that the planar device is now very close to the non planar
>     equivalent.

> [base/gdevplib.c base/gdevmpla.c]

2011-03-02T20:50:46.635530Z regression

>     Minor bug fixes and improvements to the cluster system, the most
>     signifcant of which is the addition of "CLUSTER_UNTESTED" detection.
>     If this keyword appears anywhere within the log message of a commit that
>     revision will not be tested by the cluster.

>     Less interesting changes include:

>     Fix for bmpcmp if large numbers of differences are produced

>     Addition of 'svn cleanup' calls before 'svn update' to handle nodes that
>     crashed during previous 'svn update' and left the repositories locked

>     Set status of all nodes to idle after jobs are completed.

>     Fix bugs that caused bmpcmp completed emails to be appended to the
>     previous message.

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

2011-03-02T18:51:23.645025Z Michael Vrhel

>     Introduction of a member variable in gs_image1_t, which will let us know the
>     original source type of the image.  For example if, the parent source were type3
>     this spawns two type1 images.  One for the mask and one for the image data.  The
>     mask is rendered using image render simple.  If the image is monochrome or indexed,
>     it is rendered with the renderer in gximono.c .   If we are going to a halftone
>     monochrome device, we end up using the fast threshold based renderer which has its
>     interpolation stepping in device space as opposed to source space.  This causes very
>     minor differences between the mask and the image data.  To avoid this, we use the old
>     rect_fill code for the image type3 data to ensure a more exact spatial match.

> [base/gximono.c base/gximage1.c base/gximage2.c base/gximage3.c base/gximage4.c base/gximage.h base/gximag3x.c base/gsiparam.h]

2011-03-02T13:39:52.433442Z Robin Watts

>     Fix bmpcmp bug; the map array was being incorrectly sized, resulting in
>     occasional memory corruption.

>     No cluster differences expected.

> [toolbin/bmpcmp.c]

2011-03-02T00:09:25.760114Z Robin Watts

>     Debug output for gdevplibm (monochrome planar interlaced bands) was broken
>     and writing malformed pbms. Simple fix - move the mono output code to the
>     mono branch of the if rather than the grey one.

>     No cluster differences expected.

> [base/gdevplib.c]

2011-03-01T19:30:56.622647Z Robin Watts

>     Remove DOS line endings from .gitignore files.

> [.gitignore /trunk/ghostpdl/.gitignore]

2011-03-01T17:18:30.158752Z Michael Vrhel

>     Fix for error introduced in non-SSE2 code when I removed the inclusion
>     of the transfer function into the threshold values.

> [base/gximono.c]

2011-02-28T22:31:28.419926Z Till Kamppeter

>     Added color management support to the CUPS ...toraster filters

>     Replaced the ...toraster filters by one filter executable, gstoraster,
>     written in C. This filter converts both PostScript and PDF input into
>     the CUPS Raster format using Ghostscript with the "cups" output
>     device, controlled by settings in the print queue's PPD file, by
>     command line options, and by settings embedded in a PostScript input
>     stream. This is now done with color management based on
>     printer-specific ICC profiles referenced in the PPD file or supplied
>     by the color management daemon colord. The CUPS PPD extensions
>     concerning color management
>     (http://www.cups.org/documentation.php/doc-1.4/spec-ppd.html) are made
>     use of if used and the colord daemon is used if it is present. colord
>     is accessed via D-Bus, but the new filter can also be compiled without
>     D-Bus and in this case only the CUPS PPD extensions and ICC profiles
>     assigned to the print queue are used for color management.

>     Thanks to Richard Hughes for the patch.

> [cups/pstoraster.in cups/pstoraster.convs cups/gstoraster.c cups/pdftoraster.c cups/cups.mak base/Makefile.in cups/colord.c base/configure.ac cups/gstoraster.convs cups/pdftoraster.convs cups/colord.h]

2011-02-28T20:30:43.994348Z Robin Watts

>     X offset in custom 24 -> 888 planar copy_color routine was being miscalculated.
>     Simple fix.

>     No cluster differences expected as this is untested.

> [base/gdevmpla.c]

2011-02-28T19:35:34.539587Z Robin Watts

>     Remove silly debugging hack left in gdevmpla.c by accident. Only affects
>     planar 888 devices (i.e. none enabled by default).

>     No cluster differences expected.

> [base/gdevmpla.c]

2011-02-28T19:32:37.270892Z Robin Watts

>     Add simple .gitignore files.

> [.gitignore /trunk/ghostpdl/.gitignore]

2011-02-28T10:48:11.852106Z Ken Sharp

>     Silence a compiler (scan-build) warning about a variable never being used.

> [base/gdevpdfo.c]

2011-02-28T05:23:46.157854Z Michael Vrhel

>     Fix for mis-scale on decode for render mono cache.  Fixes improper rendering
>     of 148-11.ps with new halftone code.

> [base/gxipixel.c]

2011-02-27T23:26:10.406657Z Michael Vrhel

>     Removal (or inactivation) of code to include inverse of transfer function in
>     the threshold values.  Also minor fix for scaling issue in halftone code in
>     portrait mode.  Code is inactive so no regression diffs expected.

> [base/gximono.c base/gsht.c]

2011-02-27T23:23:30.287293Z Michael Vrhel

>     Fix for a bug that was introduced with the ICC branch.  This was causing a
>     mismatch between banded an unbanded rendering and in particular had rendering
>     errors in banded mode when rendering PS and PDF files that had a non identity
>     transfer function.  Minor progression diffs in many files with very visible
>     progressions in 246-01.ps, 258-01.ps as examples.  What was happening is that
>     when running in clist mode, we were not recognizing that a transfer function was
>     present when doing the ICC branch.  Stumble upon this working the transfer function
>     in with the new threshold based halftoning code.

> [base/gxipixel.c]

2011-02-27T01:52:28.834714Z Ray Johnston

>     Fix for PDF with ASCII85Decode filter that has a dictionary (even if empty)
>     instead of a 'null' for the params. Stack has the param dict second on the
>     stack, not third. Bug 692003, customer 700.

> [Resource/Init/pdf_base.ps]

2011-02-26T19:17:52.838303Z Till Kamppeter

>     TCUPS Raster driver: The macros in the cups_put_params() function
>     could access uninitialized variables when logging error messages and
>     this could lead to a segmentation fault, making Ghostscript crashing
>     and many jobs not printed. Debian bug #615202.

> [cups/gdevcups.c]

2011-02-26T18:40:59.351498Z Ray Johnston

>     Fix for PDF 1.7 fts_08_0808.pdf which can clip the corner of the really wide
>     diagonal (magenta) stroke when banding is used. This was due to the 'extension'
>     of a square line cap being incorrectly calculated. Customer 532 issue.

> [base/gxstroke.c]

2011-02-26T18:25:08.170267Z Ray Johnston

>     Fix BUILD_SYSTEM conditional for 64 vs. 32 and add 'for Win64' message
>     to help avoid confusion during setup.

> [psi/winint.mak]

2011-02-25T23:57:50.833144Z Robin Watts

>     Fix bug reported by "new customer feb 2011", whereby gs 8.71 on an embedded
>     ppc platform is getting the colours on an image in a pdf wrong.

>     Debugging shows that in gs_indexed_limit_and_lookup we take a floating point
>     value, clip it, convert it to an int and use it to lookup which colour to use.
>     On the reference x86 run we have a value of 1 (0x3f800000 as an IEEE float).
>     On the ppc we have 0.999999 (0x3f7fffff as an IEEE float). This tiny difference
>     results in values of 1 and 0 respectively when converted to the int, giving
>     the wrong colour.

>     The fix here is to add a small epsilon before conversion.

>     A quick experiment in adding 0.5 rather than epsilon shows worse results.

>     15 cluster differences in testing, none that actually survived a bmpcmp.

> [base/gscolor2.c]

2011-02-25T19:49:39.160812Z Michael Vrhel

>     Fix so that we only do the fast code if we are in portrait or landscape mode.
>     Skewed objects will have to use the rect fill method.

> [base/gximono.c]

2011-02-25T19:33:55.727547Z Michael Vrhel

>     Addition of code to incorporate the inverse of the transfer curve into the
>     threshold matrix.  If the curve is an inverting type (e.g. 0 to 1 and 1 to 0)
>     then a the thresholding comparison is switched.  Also, if the curve is not
>     monotonic, it can not be inverted and we revert to the old rect fill method.
>     This commit has the code disabled so there should not be any regressions.

> [base/lib.mak base/gximono.c base/gzht.h base/gxdht.h base/gsht.c]

2011-02-25T18:13:49.002375Z Ray Johnston

>     Set the GS_DLL to gsdll64.dll for a 64-bit build. The file list was correct,
>     but the registry was not. Related to bug 691975 but not verified (I just
>     checked the registry using regedit).

> [psi/dwsetup.cpp]

2011-02-25T07:42:21.024741Z Chris Liddell

>     Revise how the UFST setting are handled in the makefiles.

>     The previous version relied on GNU make extensions (specifically
>     conditionals), whilst this version does not.

>     No cluster differences expected.

> [base/lib.mak psi/msvc.mak base/Makefile.in psi/int.mak]

2011-02-24T11:13:12.751072Z Chris Liddell

>     Hopefully the final iteration of allowing SHARE_ZLIB
>     to work correctly with COMPILE_INITS=1.

>     This version changes only Unix-like builds, so Windows need
>     not suffer, and also removes the reliance GNU make specific
>     extensions.

>     Bug 691986

>     No cluster differences.

> [base/unix-aux.mak]

2011-02-24T00:51:08.210054Z Robin Watts

>     Add new plib family of devices (PLanar Interlaced Buffer). These 5 devices
>     (plib = r8g8b8, plibg = g8, plibm = mono, plibc = c8m8y8k8, plibk = c1m1y1k1)
>     use a new 'band donor' interface to request a band buffer, pass back
>     rendered bands, and release bands at the end of the page.

>     The idea is that other firmware can implement this simple interface, and
>     Ghostscript can thus easily drive systems that expect planar interlaced
>     input.

>     On the whole there is relatively little new code here; the majority of the
>     work is done using the existing planar device with the odd tweak here and
>     there. Firstly, we lift the (artifical) constraints of the number of components
>     supported (so greyscale is accepted as a planar device for simplicity).
>     We spot the num_components = 1 case and just use the existing memory device
>     interface.

>     Secondly, we add a fast 888chunky to 888planar unpacking routine for use
>     with copy_color.

>     Within the plib device itself, we make use of the facility to set the line
>     indexes to allow for interlaced operation. It would be easy to extend this
>     device to offer planar non-interlaced operation too built on the same band
>     donor interface simply by omitting this code.

>     For debugging purposes we have options within the plib devices to store the
>     data returned in each band into pxm files (as appropriate to the number of
>     components). This code is deactivated by default as the output of this
>     device is via the band donor interface, not the output file.

>     No cluster differences expected as this code is disabled currently.

>     Next job: discuss with Marcos how to cluster test this.

> [base/gdevplib.c base/gdevmpla.c base/gdevplib.h base/gdevppla.c base/devs.mak]

2011-02-23T16:00:25.505362Z Robin Watts

>     Introduce and enable 8 bit rop run templated code.

>     No cluster differences shown.

> [base/gsroprun8.h base/lib.mak base/gsroprun.c ghostscript.vcproj]

2011-02-23T14:41:45.053687Z Michael Vrhel

>     Remove commented out code left over from commit 12192

> [base/lib.mak]

2011-02-23T11:54:00.145784Z Robin Watts

>     Reintroduce runrop changes to Visual Studio solution lost in recent merge
>     (r12189).

>     No cluster differences expected.

> [ghostscript.vcproj]

2011-02-23T08:25:40.039813Z Chris Liddell

>     Revision to the changes for using the system zlib.

>     r12184 caused problems on Windows.

>     This approach uses configure to determine whether
>     freetype should use the system zlib, based on whether
>     Ghostscript is using the system zlib.

>     Windows, of course, doesn't use configure, so it will
>     never attempt to the use the system zlib.

>     Bug 691986

>     No cluster differences expected

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

2011-02-23T03:26:18.063337Z Michael Vrhel

>     Temporary fix to turn off fast code for cases where the bps of the index image is not 8bps

> [base/gximono.c]

2011-02-23T01:09:08.645858Z Michael Vrhel

>     Undo of rev 12184 by commenting out the changes for now.  This change broke the windows build.

> [base/lib.mak]

2011-02-22T21:31:58.870907Z Robin Watts

>     Fix warnings caused by merging the halftone branch to the trunk in r12189.

>     No cluster differences expected.

> [base/gxipixel.c base/gximono.c base/gsht.c]

2011-02-22T20:03:37.651092Z Robin Watts

>     Forgot this file inthe last commit. Sorry!

> [base/gsroprun24.h]

2011-02-22T19:52:43.275685Z Michael Vrhel

>     Merge of halftone branch into the trunk.  The new rendering code is actually
>     disabled with this commit.  As such, there should not be any testing
>     differences.

> [base/gxipixel.c base/lib.mak base/Makefile.in base/gxcie.h /trunk/gs base/gsht.c base/gxcmap.c psi/msvc.mak ghostscript.vcproj base/gximono.c base/gzht.h base/gxidata.c base/configure.ac base/gxdht.h base/gxcmap.h base/gxicolor.c base/gximage.h base/gsciemap.c]

2011-02-22T19:38:57.296889Z Robin Watts

>     Add templated 24bit rops. Clusterpushing seems to indicate this works.

>     No cluster differences expected.

> [base/lib.mak base/gsroprun.c base/gsroprun1.h]

2011-02-22T16:10:08.900201Z Chris Liddell

>     Tweak to allow compressed romfs to be built when we're configured
>     to use the system's zlib rather than our own.

>     As a side effect of this, freetype is now configured to use the
>     same zlib instance as Ghostscript (instead of freetype's own
>     subset of zlib sources).

>     Bug 691986

>     No cluster differences expected.

> [base/freetype.mak base/lib.mak]

2011-02-22T15:44:09.440053Z Robin Watts

>     Add new gsroprun files to Visual Studio solution.

>     No cluster differences expected.

> [ghostscript.vcproj]

2011-02-22T15:28:03.132855Z Robin Watts

>     Fix DO_FILL_RECT_BY_COPY_ROP code, and enable it by default.

>     The only thing wrong with the code before is the case when strip_tile_rectangle
>     is called with both color0 and color1 being gx_no_color_index. That translates
>     to rop=0xAA (i.e. D - no change). This is actually a special case that means
>     it's really doing a copy_color operation. We handle this by punting in the
>     same way as the old code used to.

>     No cluster differences expected.

> [base/gdevm1.c]

2011-02-22T00:18:16.845591Z Robin Watts

>     Enable mono_copy_mono implemented in terms of mono_copy_rop.

>     Very small changes to the code to ensure that the copied area is correctly
>     clipped, this now gives identical results to the existing code, but should
>     be faster.

>     The tile_rectangle code is still misbehaving - will fix this in later
>     revisions (I hope).

>     No cluster differences expected.

> [base/gdevm1.c]

2011-02-21T17:12:10.825257Z Robin Watts

>     Recommit of 12163 to the trunk.

>     The fit_copy macro checks for the start address being off the top of the
>     screen, and clips it to zero. When it does this, it does: data -= y * raster,
>     which gives problems if raster is a uint ( as uint * int == uint in C) and
>     data is a 64 bit pointer.

>     The fix is simply to cast the result to an int before using it. This solves
>     various SEGVs with the mono_copy_mono using mono_copy_rop code.

>     No cluster differences expected.

> [base/gxdevice.h]

2011-02-21T16:04:25.039434Z Chris Liddell

>     The structure containing the pthreads native elements making up a
>     gp_semaphore structure was ending up incorrectly aligned on
>     sparc32 Linux systems, and caused a bus error. Annoyingly, sparc32
>     uses 32 bit pointers but requires 64 bit aligment.

>     This change enforces maximum alignment for the elements of
>     gp_semaphore, for the current platform.

>     No cluster differences expected.

>     Bug 691989

> [base/lib.mak base/gpsync.h]

2011-02-21T12:29:20.951013Z Robin Watts

>     Fix stupid typo in gsroprun.c that was causing templated rops to be different
>     to non templated rops. With this fixed the cluster shows identical results
>     (modulo indeterminisms), but the templated code is faster - so enable by
>     default.

>     No cluster differences expected.

> [base/gsroprun.c]

2011-02-20T12:41:20.382249Z Robin Watts

>     Initial reorganisation of code towards using copy_rops for copy_mono.

>     Split the guts of mem_mono_strip_copy_rop out into a separate function
>     mem_mem_strip_copy_rop_dev. This new function handles the actual copy in
>     device space, leaving the original to cope with fiddling the rop according
>     to colors.

>     This 'inner' function is moved to gdevm1.c so it is present in both gs
>     and ghostpcl builds. The existing (bitrotted) code in gdevm1.c to
>     'USE_COPY_ROP' is revamped to call mem_strip_copy_rop_dev, but is disabled
>     currently as the cluster is showing a few differences that need to be
>     tracked down.

>     Also, this introduces new code to do gsroprun's using code in a generic
>     header file that gets repeatedly #included with different options. This
>     code is currently disabled until we can verify that it gives identical
>     results. The new 'templated' code uses native ints where possible, and
>     (in initial limited testing) seems to perform better than copy_mono.

>     No cluster differences expected.

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

2011-02-19T07:01:13.923016Z Alex Cherepanov

>     Add a missing check for null value during PDF resource enumeration.
>     Bug 691892, customer 532.

> [Resource/Init/pdf_main.ps]

2011-02-18T13:22:59.764503Z Robin Watts

>     Committing fix for Bug 689031 submitted by Shailesh Mistry under the
>     bug bounty program. Tests out fine (1 minor difference, looks like a
>     progression to me).

>     See bug for full discussion, but basically this removes a few calls to
>     path_position_valid in exchange for accessing the equivalent data kept
>     locally.

> [base/gxchar.c base/gzpath.h base/gxccache.c base/gspath1.c]

2011-02-18T11:51:25.345393Z Ken Sharp

>     Enhancement (pdfwrite) : performance improvement

>     Bug #691946 "Conversion to PDF becomes slower and slower"

>     There are many places where pdfwrite compares composite objects for equality. This can
>     be a very slow process, depending on the nature of the object, and becomes progressively
>     slower as more object are added to storage.

>     Previously we had added a MD5 hash to the stream data of a cos_stream in order to
>     improve the performance when checking fonts for equality, this change takes the whole
>     process much further. We now store an MD5 'fingerprint' for each composite object,
>     initially this is not computed and is marked as not valid.

>     Whenever an equality test takes place we check to see if the composite object has an MD5
>     hash calculated, and if it does, we compare the MD5 hashes. If it does not then we
>     compute an MD5 hash, store it, and mark it as valid. Note that for cos_stream types
>     we store *two* hashes, one for the dictionary and one for the stream data.

>     If we alter the contents of a composite object then we mark its MD5 hash as invalid so
>     that we recompute it on the next occurence. Technically there could be a problem if
>     a composite object contains a composite object, and the descendant object is altered
>     after the MD5 hash is calculated for the parent. However this should not occur given
>     the way these structures are used (these are pdfwrite internal structures, *not* PS or
>     PDF objects available to the interpreter).

>     This very significantly improves performance on some files, the test file for bug
>     #691946 takes 2642 seconds without this change (and DetectDuplicateImages true) while
>     it takes 963 seconds after this change.

>     Note that this change depends on revision 12169 and should ideally be used with
>     revisions 12168 to 12171 inclusive.

>     No other differences expected.

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

2011-02-18T11:37:56.561896Z Ken Sharp

>     Fix (pdfwrite) : images being scaled incorrectly

>     Found while dealing with other problems. pdfwrite uses the image 'height' (rendered
>     height) and number of lines of data to calculate a 'scale' which it then applies to
>     the current Transformation Matrix in order to calculate an image matrix.

>     However, when an image was detected as a duplicate, the scale factor was calculated
>     from the first image's dimensions, and then applied to the CTM for the second matrix.

>     This did not appear to cause problems for PostScript and PDF but causes serious bugs
>     in a number of PCL files, and was clearly incorrect. We now save and restore the
>     height and width when substituting images to prevent this problem

> [base/gdevpdfj.c]

2011-02-18T11:32:07.033929Z Ken Sharp

>     enhancement (pdfwrite) : Allow duplication image detection to be disabled

>     pdfwrite tests every (non-inline) image against every other stored image to see if it is
>     a duplicate, and if so does not embed the duplicate in the output but simply references
>     the original.

>     This can be slow for files with many images (each stored image must be checked when a
>     new image is encountered) and may be of limited benefit.

>     The new flag DetectDuplicateImages (default true) can be used to enable or disable
>     this behaviour

>     No differences expected

> [base/gdevpdfj.c base/gdevpdfx.h base/gdevpdfp.c doc/Ps2pdf.htm base/gdevpdfb.h]

2011-02-18T11:25:24.853829Z Ken Sharp

>     Fix (pdfwrite) : Correction to an equality test

>     This fixes a long-standing bug when checking the equality of patterns.

>     We need to ensure when substituting patterns that neither of the patterns is already
>     substituted. But the code only tested one of the patterns (and was a duplicate of
>     another test), which led to incorrect results. This should always have been a problem
>     but for some reason seems to have been masked in previous releases. New code for
>     testing equality of composite objects revealed the problem.

>     No differences expected, as the problem is only revealed with code which follows in a
>     subsequent commit.

> [base/gdevpdfi.c]

2011-02-18T11:15:23.457563Z Ken Sharp

>     Fix a typo in an enumerated type. No differences expected.

> [base/gxhldevc.h base/gxhldevc.c base/gdevpdfg.c]

2011-02-15T16:36:59.934186Z Henry Stiles

>     Double the allowed space for cached chars and increase the maximum
>     byte size of a single glyph that can be cached.

> [base/gsfont.c]

2011-02-15T15:07:55.282721Z Ray Johnston

>     Fix for building the gs***w64.exe self extracting installer compatible with
>     the new 64-bit binary naming and makefile macro (BUILD_SYSTEM)

> [psi/winint.mak]

2011-02-15T09:21:28.927211Z Chris Liddell

>     Ensure that the OpenPrinting drivers get removed from the drivers list
>     if iconv/libiconv are not available.

>     The strings used to identify the drivers in the list were incorrect.

> [base/configure.ac]

2011-02-14T20:39:33.924424Z Robin Watts

>     Fix Bug 691917. In revision 11146 I made op_array_table_global and
>     op_array_table_local be elements of the context rather than being
>     globals, and changed all the code to access these elements through
>     the context.

>     Unfortunately I forgot to cope with when new contexts are generated by
>     forking execution. The correct fix is, I believe to simply copy the
>     op_table pointers over to the new context. This has been done here, and
>     seems to solve the reported bug.

>     No cluster differences expected.

> [psi/zcontext.c]

2011-02-14T11:04:39.509187Z Till Kamppeter

>     Removed a tab accidentally introduced in rev 12082.

> [Resource/Init/cidfmap]

2011-02-10T17:14:23.128533Z Chris Liddell

>     Ensure that a --build option is propogated to the other
>     configure scripts we call.

> [base/configure.ac]

2011-02-10T13:21:58.493309Z Ken Sharp

>     fix error in revision 12140

>     When fetching the size of the stream for a /Indexed colour space, omitted to check if the
>     /Length of the stream was an indirect object. Now dereference the object if this is the
>     case.

>     Should fix the 14 files with errors introduced in 12140.

> [Resource/Init/pdf_draw.ps]

2011-02-10T10:43:26.255155Z Ken Sharp

>     Fix : colour space handling bug and improved handling of broken ICC space

>     Bug #691941 "Interpretation of PDF aborts with /typecheck"

>     The PDF file in the specimen contains an invalid colour space of the form:

>     /Indexed [/ICCBased <</N 1 /Alternate [/Indexed /DeviceRGB 255 7 0 R]>>] 255 7 0 R]

>     The number of components in the ICCBased specification is incorrect, as the profile has
>     3 channels. This was not detected previously. Falling back to the /Alternate we see
>     that we have a /Indexed space depending on a /Indexed space which is also invalid, but
>     we choose to ignore this.

>     There was also a bug in the colour space handling for ICCbased spaces which caused a
>     typecheck if the alternate space was a /Indexed space.

>     Finally, the PDF interpreter is updated so that when given a stream as the data source
>     for a /Indexed space it reads and returns a string which is the greater of the declared
>     size of the stream, or the calculated size required, given the number of components.
>     Previously we always returned the calculated size, which was too little in this case
>     as the number of components in the ICCBased space is incorrect.

>     With these changes the (invalid) specimen file runs to completion.

>     No differences expected.

> [psi/zcolor.c psi/zicc.c Resource/Init/pdf_draw.ps]

2011-02-10T10:33:23.506445Z Ken Sharp

>     Fix Bug #691918

>     Update the Unicode decodings applied to TrueType fonts to match the latest Adobe glyph
>     list. Fixes some problems with incorrect mappings and adds numerous new mappings. A
>     similar but less extensive change is made to the FCO_Unicode mappings as well.

>     Thanks to SaGS for the work on this problem.

>     No differences expected as these are only used for ToUnicode CMaps.

> [Resource/Decoding/Unicode Resource/Decoding/FCO_Unicode]

## Version 9.01 (2011-02-07)

This is the second release in the stable 9.x series.

Highlights in this release include:

A new, robust CFF parser implemented in C (replacing the previous Poscript one),

tiffscaled device - this renders internally as tiffgray, but then downsamples by an integer scale factor (specified by -dDownScaleFactor=n) and error diffuses to 1bpp output. The tiffscaled device also implements limited minimum feature size functionality; by setting -dMinFeatureSize to 1, 2 or 3, the device output is guaranteed to generate minimum dot sizes as multiples of the final resolution, useful for devices that offer finer position control than dot size control.

Add DSC compatible output in ps2write.

Windows makefiles now support 64 bit builds on 64 bit systems.

A number of performance, memory use, and stability improvements with the new features introduced in 9.00, plus the usual bug fixes.

We have also dropped support for Watcom and Borland development environments. These had not been maintained for some time, and were suffering "bit rot".

For a list of open issues, or to report problems, please visit bugs.ghostscript.com.

### Incompatible changes

No recorded incompatible changes.

### Changelog

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

## Version 9.00 (2010-09-14)

This is the first release in the stable 9.x series.

This release includes a move to an ICC-based color rendering workflow. The design allows easy integration of 3rd party color management modules (CMMs) and management of DeviceN and spot source colors with ICC profiles as well as with non-ICC proprietary methods. The default CMM is the well known littleCMS. Postscript color objects and non-ICC CIE-based PDF color spaces are converted to equivalent ICC profiles enabling complete color management for all color spaces by an ICC-based CMM. New command line options enable the specification of gray, rgb and cmyk default ICC profiles as well as output device ICC profiles. The new work flow provides performance improvements in the rendering of images, shadings and transparencies. In addition, the color conversions are designed to work efficiently in multithreaded display list (c-list) rendering through the use of a shared link cache. Finally, proper ICC based rendering now occurs for ALL XPS objects including Named colors, N-Channel colors and images with internally embedded ICC profiles.

The second major change in this release is that glyph rendering for all font types except Type 3 is now handled by Freetype (via a much improved and enhanced Font API). The most obvious benefit of this is a complete, and proven implementation of the TrueType byte code interpreter (now unencumbered by patents).

Another major change is that the Postscript interpreter's graphics state now stores two separate colour space settings for stroking and filling, to better support the stroke and fill colours required by the PDF interpreter.

Finally, support for optional content has been added to the PDF interpreter.

This release also includes a number of improvements to the pdfwrite device to improve reliability and quality with PCL and XPS input. Many improvements to the support of JPX images in PDF files, PDF annotation rendering and the usual number of general bug and robustness fixes.

For security reasons, Ghostscript no longer searches the current directory by default. Use -P option to revert to old behavior.

For a list of open issues, or to report problems with this release, please visit bugs.ghostscript.com.

### Incompatible changes

No recorded incompatible changes.

### Changelog

2010-09-13T15:09:40.310889Z Chris Liddell

>     Commit the missing header changes from the previous checkin.

> [psi/ifapi.h]

2010-09-13T14:53:46.788657Z Chris Liddell

>     Another revision of the FAPI code. Due to a problem in Freetype which needs
>     further investigation, we cannot produce an outline, then decide to produce
>     a bitmap if it is small enough. We work around this by producing a bitmap,
>     and if it is too large, dispose of it, and retry with an outline, thus although
>     we still risk larger than ideal memory use, it is very short lived. A glyph
>     too large to be cached (for which we will now usually use an outline) does
>     not suffer from the Freetype issue mentioned above.

>     The maximum allowable bit for Freetype to produce is now 1.5 x the maximum
>     cache bitmap as set in the Postscript state - it is set larger than the
>     cache bitmap since it is *vital* that if GS expects a bitmap to be cache
>     we supply a bitmap. Given that the bounding boxes arrived at the GS cache
>     device and the Freetype rendering code arrived at slightly differently, there
>     would be the chance of edge cases where FAPI would produce an outline, when
>     the cache expects a bitmap. Allowing FAPI plenty of leeway avoids that.

>     The calculation to convert a quadratic to a cubic spline in the
>     Freetype interface code was slightly wrong.

>     Also, FAPI now sets the fill adjust to 0 for filling outline glyph, instead
>     of inhereting the value from the originating graphics state, which gives
>     *much* more consistent output between the bitmap and outline cases, and
>     addresses the slightly excessive boldness observed for outline glyphs since
>     the adoption of Freetype/FAPI as the default font scaler/renderer.

>     Finally, support for the existing Ghostscrit text anti-aliasing
>     capability is improved.

>     Bug 691604

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

2010-09-13T10:25:34.372202Z Chris Liddell

>     Revert revisions 11690 and later from the FAPI code (and revert version no. to 9.00)
>     to get a "good" base version, in preparation for a corrected version of the changes
>     in 11690 (and subsequent changes in the FAPI code).

> [psi/fapi_ft.c psi/zfapi.c base/version.mak Resource/Init/gs_init.ps psi/ifapi.h psi/fapiufst.c psi/fapibstm.c]

2010-09-09T13:51:48.502020Z Alex Cherepanov

>     Fix a case where /Width attribute was not checked for null.
>     Bug 691602, customer 700.

> [Resource/Init/pdf_font.ps]

2010-09-09T07:26:52.042155Z Chris Liddell

>     Fix broken version number in gs_init.ps in trunk

> [Resource/Init/gs_init.ps]

2010-09-09T06:26:54.427296Z Chris Liddell

>     Add a couple of ".0"s to ensure we get floating point division
>     to arrive at intermediate values for the conic to cubic
>     spline conversion.

> [psi/fapi_ft.c]

2010-09-09T03:45:12.738999Z Michael Vrhel

>     Fix for compiler complaint from commit of rev 11700

> [base/gdevpdfb.c base/devs.mak]

2010-09-08T23:20:36.969829Z Michael Vrhel

>     Fix to enable proper mask filling with patterns that have transparency.
>     Major change is in gdevp14.c where begin_type_image and mask_fill procedures
>     now will (if we are filling with a pattern that has transparency) push a
>     transparency group.  When we are finished processing the image, the group is
>     popped which enables proper blending.  There remains an issue with a special
>     file that Ken created when it is run in c-list mode.  A new bug will be opened
>     for this issue.  Thanks to Ray for helping with this project and finding a
>     bounding box issue in the creation of the transparency group during c-list
>     reading.

> [base/gdevp14.c base/gxclimag.c base/gsptype1.c base/lib.mak base/gxpcmap.c base/gdevpdfb.c base/gsptype1.h base/gstrans.c base/gxpcolor.h base/gxblend1.c base/gxp1fill.c base/gxp1impl.h base/gdevpdfi.c]

2010-09-08T16:22:42.112334Z Ken Sharp

>     Fix (pdfwrite) : incorrect pattern matrix calculation

>     Bug #690504 "ps2write does not work with asymmetric resolutions, like 600x1200dpi "

>     The problem was caused by frankly totally incorrect calculations when generating the
>     /Matrix for a pattern. Because we always see the CTM including the resolution scaling
>     but need to output a matrix with this removed, we scale the CTM by the inverse of the
>     resolution scaling.

>     But the calculation simply divided the CTM through by the scale factors, which is
>     totally incorrect and fails badly if the matrix involves rotation. The code now
>     correctly creates and multiplies a scale matrix. Note, the order of multiplication is
>     important here.

>     No differences expected.

> [base/gdevpdfv.c]

2010-09-08T08:30:15.885002Z Chris Liddell

>     Slight refinement in the how the FAPI character generation detects we are
>     producing anti-aliased glyphs.

>     Also, it seems that when assigning variable value to a second, larger data
>     type, whilst gcc promotes the data type before the assignment, MSVC promotes
>     the variable later, so shifting a 32 bit integer up during an assignment to
>     a 64 bit integer variable works find on gcc, but MSVC loses the most
>     significant bits. So we need to force the promotion to happen with a cast.

>     Bug 691588

> [psi/fapi_ft.c psi/zfapi.c]

2010-09-07T16:51:36.404533Z Chris Liddell

>     Add a further header to ifapi.h required for Unix/Linux builds, and
>     add the two additional headers to ifapi.h's dependencies.

> [psi/ifapi.h psi/int.mak]

2010-09-07T16:26:46.989782Z Chris Liddell

>     Pull in gp.h in ifapi.h for the int64_t type - it seems to be required on Windows.

> [psi/ifapi.h]

2010-09-07T15:32:17.143998Z Chris Liddell

>     Some fairly substantial changes to the FAPI code to get very high resolutions and
>     anti-aliased text working reliably.

>     For AA text, we now make *sure* to produce outlines for non-cached glyphs, thus
>     the GS path code can anti-alias correctly (for cached glyphs, the "show" machinery
>     does the anti-aliasing from the cache bitmap).

>     The high res problems were highlighted by the bbox device (which runs at 4000 dpi).
>     To resolve these the width and height parameters for Freetype had to have value
>     overflow compensation added, to match the existing underflow compensation.

>     FAPI/Freetype also now will only create a glyph bitmap if the bitmap size is smaller
>     than the allowable glyph cache bitmap. It may still produce a bitmap for a non-cached
>     glyph, if the cache is full, but the individual glyph bitmap is not larger than the
>     allowable glyph item - this is allow for better consistency when we're near the limit
>     of the total cache size.

>     Finally, the FAPI outline retrieval code now requires 32.32 fixed point variables (rather
>     than the previous 16.16), which prevents overflow, and improves accuracy. If also provides
>     us with the opportunity to check for overflow/underflow of the GS internal fixed point
>     variables, before calling the GS path code.

>     There are quite a few cluster changes. I have checked them all, and one is a progression
>     (missing glyphs now render) and the rest are the pixel level differences expected by
>     having GS render a path, rather than Freetype - most are due to Freetype grid fitting to
>     the glyph bitmap, and GS grid fitting to the page raster.

>     Bug 691592 - bbox issue
>     Bug 691588 - anti-aliasing

> [psi/fapi_ft.c psi/zfapi.c psi/ifapi.h psi/fapiufst.c psi/fapibstm.c]

2010-09-06T10:14:25.582663Z Ken Sharp

>     Fix (pdfwrite) : string not being re-encoded

>     Bug #690441 " Files render properly with gs, but are misformatted by ps2pdf"

>     A Coverity fix in revision 9072 prevented a crash, but also circumvented code that was
>     essential to run under some conditions. (This is described by comments in the code as a
>     'trick'). The routine created a text string with the encoded text for a font with a
>     custom encoding derived from a CIDFont with an unusual CMap.

>     In order to avoid the potential crash, but still re-encode the string, which is
>     essential, the relevant portion of the code has been copied and is exercised instead of
>     executing 'pdf_reserve_char_code_in_pdfont()'. This produces the reencoded string we
>     need, but if the encoding fails, where we would have caused a crash by dereferencing a
>     NULL pointer, we instead return an error.

>     No differences expected, we obviously don't have a test case in the regression suite.

> [base/gdevpdtt.c]

2010-09-03T15:49:54.010009Z Ray Johnston

>     Fix for hang condition in the stream logic for the luratech JPXDecode.
>     We need to return EOFC with the final bit of data. Found with PDF 1.7 FTS.

> [base/sjpx_luratech.c]

2010-09-03T08:31:32.767708Z Chris Liddell

>     A Type 0 font dictionary in a PDF which contained a spurious FontDescriptor
>     object confused the interpreter, which resulted in creating a Font resource
>     directly, rather than instantiating the DescendantFonts for the Type 0.

>     We'll now remove the spurious entry from the Type 0 dictionary, to prevent
>     any on-going confusion.

>     No cluster differences expected.

>     Bug 691589

> [Resource/Init/pdf_font.ps]

2010-09-03T07:21:06.059509Z Ken Sharp

>     typo, misplaced quote in revision 11684

> [lib/lpgs.bat]

2010-09-03T07:19:33.619992Z Ken Sharp

>     Typo, misplaced quote in revision 11684

> [lib/pdfopt.bat]

2010-09-03T06:52:44.087509Z Ken Sharp

>     More Windows batch file madness.

>     Guard all path expansion with quotes, since the Windows command shell processor is too
>     stupid to do so, even when expanding variables/arguments itself.

>     Add a trailing separator to the %TEMP% variable before specifying the filename, as
>     apparently some setups don't get a trailing separator by default. A paired separator
>     (ie \\) doesn't seem to cause a problem so this ought to be safe even if the setup
>     does have a trailing separator.

> [lib/pf2afm.bat lib/gsdj500.bat lib/ps2ascii.bat lib/ps2pdfxx.bat lib/lpr2.bat lib/gsndt.bat lib/gstt.bat lib/eps2eps.bat lib/pdf2dsc.bat lib/gsbj.bat lib/ps2epsi.bat lib/gsdj.bat lib/dumphint.bat lib/ps2ps2.bat lib/gsnd.bat lib/font2c.bat lib/pdfopt.bat lib/gst.bat lib/pdf2ps.bat lib/ps2pdf.bat lib/gslj.bat lib/bdftops.bat lib/pfbtopfa.bat lib/ps2pdf12.bat lib/ps2pdf13.bat lib/ps2pdf14.bat lib/lpgs.bat lib/gslp.bat lib/ps2ps.bat lib/pftogsf.bat]

2010-09-02T15:57:50.419060Z Ken Sharp

>     Remove a couple of duplicated font names form the embedding white list, and reduce the
>     list length #define appropriately.

> [base/whitelst.c]

2010-09-02T14:15:39.116953Z Ken Sharp

>     Include the header file purely to get the prototype for the function, otherwise gcc
>     complains.

> [base/whitelst.c]

2010-09-02T13:50:13.043694Z Ken Sharp

>     pdfwrite enhancement

>     The addition of code to test and honour the 'embedding flags' in TrueType fonts has
>     led to problems because PostScript producers are embedding type 42 fonts in the
>     PostScript which are non-embeddable and worse use a custom non-reversible encoding,
>     so that the  resulting PDF file has garbage text when a normally encoded font is used
>     as a replacement.

>     It seems that Adobe has published a 'white list' of fonts which have been granted
>     at least some embeddable rights. It isn't obvious if these are fonts which were type
>     1 (and therefore could be converted to TrueType and get incorrect embedding rights) or
>     if the fonts were originally released as TrueType with the wrong embedding rights.

>     In any event, this list has now been added to pdfwrite; if a font is encountered which
>     has restricted embedding, then its name will be checked against this list, if it is
>     found in the list then it will be considered as embeddable. We have already
>     encountered one font on this list which has a slightly different name to the original
>     (a space was removed) so spaces in the font names are ignored.

>     This list will have to change over time, and we may find other examples of characters
>     which we want to handle specially (eg oumlaut treated as o and e)

>     No differences expected as this is not tested in the current regression suite.

> [base/whitelst.c base/gdevpdtf.c base/devs.mak base/whitelst.h]

2010-09-01T18:47:52.658366Z Chris Liddell

>     Update the release notes, dates etc for a second 9.00 release candidate

> [doc/History7.htm doc/Projects.htm doc/History8.htm doc/History9.htm man/dvipdf.1 man/ps2ascii.1 doc/Use.htm doc/Readme.htm doc/Source.htm doc/Deprecated.htm man/ps2epsi.1 doc/Install.htm doc/API.htm doc/Issues.htm doc/DLL.htm doc/Drivers.htm man/pfbtopfa.1 doc/Release.htm doc/Commprod.htm doc/Xfonts.htm doc/Devices.htm doc/Language.htm man/gs.1 man/pf2afm.1 doc/Ps2ps2.htm doc/Fonts.htm man/printafm.1 doc/Ps2pdf.htm doc/Develop.htm doc/Helpers.htm man/pdf2dsc.1 doc/Psfiles.htm doc/Lib.htm doc/gs-vms.hlp man/font2c.1 man/gsnd.1 base/version.mak man/pdfopt.1 man/pdf2ps.1 man/ps2pdf.1 doc/Make.htm doc/Details8.htm doc/Details9.htm doc/Unix-lpr.htm doc/C-style.htm doc/Ps-style.htm doc/History1.htm doc/History2.htm man/gslp.1 man/wftopfa.1 doc/History3.htm man/ps2ps.1 doc/Ps2epsi.htm doc/History4.htm man/ps2pdfwr.1 doc/History5.htm doc/History6.htm]

2010-09-01T17:49:18.515475Z Chris Liddell

>     Update the release notes for the second 9.00 release candidate.

> [doc/History9.htm doc/News.htm doc/Details9.htm doc/Details.htm]

2010-09-01T13:59:34.488373Z Ken Sharp

>     Silence some compiler warnings.

>     Altered a static function to 'void' from 'int' as it returns no values and the callers
>     don't test any putative return value.

>     #ifdef a boolean declaration, as the code which uses it has been #ifdef'ed

>     Add some parameters to two functions, so that they match the prototypes, the
>     parameters are not used in these functions.

> [base/gdevpdfk.c base/gdevpdfc.c]

2010-09-01T06:08:51.456140Z Michael Vrhel

>     Fix to avoid issues with subtractive monochrome devices when we have
>     transparency.  The gray device pdf14 prototype is used in this case.
>     VERY limited testing indicates that this fixes a crash with the cups
>     device with its default settings and gives proper rendering.  More
>     complete testing is required to ensure that proper blending is being
>     performed and to investigate the other process color models that the
>     cups device supports (e.g. cmy).

> [base/gdevp14.c]

2010-08-31T23:21:15.562664Z Michael Vrhel

>     Revert back to having pdfwrite handle what to do with PS color spaces
>     instead of using the V4 profile that gsicc_create generates.  Also, fix a
>     few issues that existed with pdfwrites handling of those spaces, in particular
>     adjustments are made for non D50 white points.  D50 is the required white point
>     for the ICC profile.  About 189 pdfwrite test files will report differences.
>     I went through them with bmpcmp.    Since the profiles that were generated
>     differ between gsicc_create and pdfwrite minor color differences exist.  In
>     addition, there were some regressions that existed, which this revision will
>     fix.

> [psi/zcolor.c base/gdevpdfk.c psi/zimage.c base/gdevpdfc.c base/gsciemap.c]

2010-08-31T15:34:27.935572Z Ken Sharp

>     Fix (pdfwrite) : linewidth corruption when Tr is 1

>     Bug #690436 " (regression) re-distilling pdf causes R graphics to go block-single-color."

>     The problem was cause din the pdfwrite-specific text rendering routines. When the text
>     render mode is 1 (stroke), the linewidth is adjusted by the current text matrix. However
>     the routine to do this is called each time any element of the text 'graphics state'
>     changes. So if multiple calls to (eg) Td were made, the linewidth would be altered
>     even though there had been no change in 'w'.

>     Fixed by getting the current linewidth before the text rendering routine, and setting
>     it back to this value after the text rendering routine.

>     No expected differences. However z400454b01d4-1.pdf seems to exhibit some minor
>     differences which I am unable to reproduce locally. They are so minor that bmpcmp
>     ignores them, and on my tests the PDF files are identical bar the date/time stamps
>     and other metadata. I don't believe this is a real difference.

> [Resource/Init/pdf_ops.ps]

2010-08-28T22:04:55.196791Z Alex Cherepanov

>     Implement rendering of /Highlight annotation. Acrobat always uses transparency
>     and ignores appearance streams. Bug 691572, customer 532.

>     Progressions or minor differences (when the annotation has an appearance
>     stream) are observed in annots.pdf, CATX1385.pdf, CATX6166.pdf, CATX6508.pdf,
>     CATX7659.pdf, CATX8255.pdf, IA3Z4030.pdf, fts_32_3225.pdf

> [Resource/Init/pdf_main.ps Resource/Init/pdf_draw.ps]

2010-08-27T13:54:14.847396Z Ken Sharp

>     Fix (pdfwrite) : faulty matrix transformations for Pattern dictionaries

>     Bug #690398 "Geometric issue with pattern"
>     The problem is the definition of the default co-ordinate space. When a Pattern is at the
>     page level or drawn inside a form, we need to remove our 0.1 scaling in order to return
>     to the 'default co-ordinate space'. However, when painted on a form nested inside a
>     form, the default co-ordinate space is the parent form, so we don't need to undo
>     the scaling.

>     This is the same problem addressed for shading dictionaries in revision 11347.

> [base/gdevpdfv.c]

2010-08-27T12:10:54.938774Z Ken Sharp

>     Fix (pdfwrite) : FormDepth not tracked properly.

>     Part of the fix for Bug#690398. In order to know whether a pattern matrix should be
>     converted to the top level CTM, or to an enclosing Form CTM, we track the Form Depth
>     by noting when transparency groups begin and end (currently this is the only way to get
>     a form output by pdfwrite).

>     There was a problem with mask groups, because although pdf_begin_transparency_mask calls
>     pdf_begin_transparency_group, pdf_end_transparency_mask doe snot call
>     pdf_end_transparency_group. This resulted in the depth being incremented at the start
>     of the mask, but not decremented at the end, so patterns could be emitted at the page
>     level but with the CTM for a Form level, leading to missing content.

>     Fixed by decrementing the FormDepth appropriately.

> [base/gdevpdft.c]

2010-08-27T12:02:46.764612Z regression

>     Added the ability to specify which regression test files will only be
>     run during nightly regression testing (i.e. not for commit regression
>     tests).  To skip files add them, one per line, to the nightly_only.lst
>     file in the corresponding directory (creating this file if none exists).
>     See tests_private/customer_tests/nightly_only.lst for an example.

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

2010-08-26T23:34:28.641761Z Alex Cherepanov

>     Implement rendering of /Squiggly annotation without an appearance stream.
>     Bug 691572, customer 532.

> [Resource/Init/pdf_draw.ps]

2010-08-26T15:49:51.752958Z Ken Sharp

>     Remove an unused local variable (gcc compiler warning)

>     No differences expected

> [base/gdevpdf.c]

2010-08-24T21:37:29.611143Z Chris Liddell

>     Merge a couple of corrections from the 9.00 tag.

> [doc doc/History9.htm doc/News.htm doc/Details9.htm]

2010-08-24T20:31:40.602213Z Chris Liddell

>     Merge doc changes from 9.00 and bump version number to 9.01

> [doc/Projects.htm man/dvipdf.1 man/ps2ascii.1 doc/Use.htm man/ps2epsi.1 doc/DLL.htm doc/Drivers.htm doc/Release.htm man/gs.1 doc/Ps2pdf.htm man/printafm.1 psi/psromfs.mak psi/dxmain.c toolbin/tests/check_dirs.py doc/Helpers.htm psi/dxmainc.c man/gsnd.1 man/pdfopt.1 base/version.mak Resource/Init/gs_init.ps man/ps2pdf.1 man/pdf2ps.1 doc/News.htm doc/Details8.htm doc/Make.htm doc/Unix-lpr.htm doc/Details9.htm doc/History1.htm doc/History2.htm man/wftopfa.1 doc/History3.htm doc/History4.htm doc/Details.htm man/ps2ps.1 doc/History5.htm doc/History6.htm doc/History7.htm doc/History8.htm doc/History9.htm doc/Readme.htm doc/Source.htm doc/Deprecated.htm /trunk/gs doc/Install.htm doc/Changes.htm doc/API.htm doc/Issues.htm man/pfbtopfa.1 doc/Commprod.htm doc/Xfonts.htm doc/Devices.htm doc/Language.htm psi/dmmain.c doc/Fonts.htm doc/Ps2ps2.htm man/pf2afm.1 doc/Develop.htm man/pdf2dsc.1 psi/dmmain.r doc/Psfiles.htm doc/Lib.htm doc/gs-vms.hlp man/font2c.1 doc/C-style.htm doc/Ps-style.htm man/gslp.1 doc/Ps2epsi.htm man/ps2pdfwr.1]

2010-08-24T13:46:29.931715Z Ken Sharp

>     Enhancement - Font copying (pdfwrite)

>     Bug #691573 " invalidfont in xshow". The file does in fact contain an invalidfont, the
>     type 42 embedded fonts are defined by adding /.notdef to the CharStrings dictionary as
>     if it were the Encoding array. The key /.notdef is added 256 times with values ranging
>     from 0 to 255. Of course only the last one is actually defined.

>     This means that when we come to copy the /.notdef glyph for our font copy, the type 42
>     GID is 255. However the font does not contain a glyph with GID 255, so the copy of the
>     font fails.

>     Although this is an illegal font, Adobe Acrobat Distiller does produce a PDF file from
>     it. In order to duplicate this, code has been added when copying a font. If we fail to
>     copy a glyph, and the glyph is /.notdef and the GID is non-zero, we try to copy a glyph
>     with GID 0 instead. If that fails we error out, otherwise we use the glyph with GID 0.
>     (TrueType font /.notdef glyph has GID 0)

>     This works for the supplied file but is not, of course, a guaranteed solution since
>     another badly formed font may not contain a glyph with GID 0.

>     No Expected Differences

> [base/gxfcopy.c]

2010-08-24T12:29:59.958275Z Chris Liddell

>     In preparation for the release, add my username to real name mapping
>     in AUTHORS, add an initially empty History9.htm, and update News.htm
>     to point to it.

> [doc/History9.htm doc/News.htm doc/AUTHORS]

2010-08-23T16:49:47.032287Z Ken Sharp

>     Fix (pdfwrite) : errors in XMP metadata parsing

>     Bug #691562 "ERROR -15 closing pdfwrite device".

>     This use of a DOCINFO pdfmark exposed 3 separate bugs in pdfwrite's handling of XMP
>     metadata.

>     1) Decoding an escaped PostScript string. Unescaped characters and octal escapes worked
>     correctly, but non-octal escapes moved the index into the string one place too many.

>     2) The escape '\b' (backspace) wasn't handled and returned incorrect data. Although not
>     tested by this issue, the form feed (\f) also wasn't handled.

>     3) When converting UTF16 data to UTF-8, the end of the destination (UTF-8) buffer was
>     calculated incorrectly, causing a spurious buffer overrun error.

>     The code now handles the missing escapes, does not advance the character position after
>     decoding a non-octal escape and correctly defines the end of buffer. After this the
>     Title string displays the same in Acrobat as the same pdfmark sent through Adobe
>     Distiller.

>     No expected differences as this only affects the document metadata.

> [base/gdevpdfe.c]

2010-08-21T08:03:46.086781Z Lars Uebernickel

>     Remove unnecessary version checks for libtiff in configure.ac.

>     Since the local copy is preferred over the system's (see r11635), comparing the
>     version of the two libraries is unnecessary.

> [base/configure.ac]

2010-08-20T16:07:22.239869Z Chris Liddell

>     When we produce a glyph uncached, and it's to be filled with a
>     pattern colour space *and* there is PDF transparency involved
>     force FAPI to (try to) produce an outline (for lower level
>     code to use as a clip) instead of a bitmap (to use as a
>     mask).

>     This does produce some pixel level differences in a few
>     cluster files, but improves a load of PDF 1.7 FTS jobs.

>     Bug 691550

> [psi/zfapi.c]

2010-08-19T04:01:05.188148Z henrys

>     Fix bug #691564.  The assignment of the target device did not use the
>     proper reference counting assignment procedure resulting in a lost
>     reference to the target device.

> [base/gxpcmap.c]

2010-08-17T14:31:58.354019Z Alex Cherepanov

>     Skip opacity and unknown components during reading of JPX image data. This
>     improves image quality (compared to the previous state that interpreted an
>     opacity channel as yet another data sample) and serves as a transition to full
>     support of opacity in JPX images. Bug 691489, customer 532.

> [base/sjpx.h psi/zfjpx.c base/sjpx.c]

2010-08-17T01:22:18.729560Z Alex Cherepanov

>     Don't include opacity channels in the number-of-components count.
>     Recognize general ICC profile (type 3) and construct a corresponding
>     ICC-based color space. Bug 691470, customer 532.

> [Resource/Init/pdf_draw.ps]

2010-08-15T09:49:03.044306Z Chris Liddell

>     Ensure we only check the compatibility of the system libtiff
>     if we're actually going to use it.

>     No cluster differences expected.

>     Bug 691548

> [base/configure.ac]

2010-08-15T09:42:21.565047Z Chris Liddell

>     The "shortcut" for rendering masks use by the FAPI code for uncached
>     glyph bitmaps (gx_image_fill_masked) is only safe, in the general case
>     when drawing "plain" colours to the output. For complex colour spaces
>     (like patterns) we must use the "long hand" version.

>     This causes minor pixel level differences in some cluster tests (due
>     to rounding differences), and some (very small) progressions: there
>     are differences in about 20 cluster jobs.

>     Bug 691549.

> [psi/zfapi.c]

2010-08-14T21:10:29.198491Z Alex Cherepanov

>     Fix a memory corruption problem introduced by the rev. 11588 on some systems.
>     Free the string returned by systempapername() but don't free the static string
>     returned by defaultpapername() . Bug 691557.

> [base/gp_upapr.c]

2010-08-13T19:46:28.340691Z Ken Sharp

>     Fix (pdfwrite( : Invalid compression filter emitted.

>     Bug #691556 "Images compressed with the RunLengthDecode filter are invalid" A typo in
>     gdevpdfx.h caused the /Filter entry of an image dictionary to be written with a
>     trailing comma if the filter was RunLength.

>     No differences expected

> [base/gdevpdfx.h]

2010-08-12T18:14:30.164084Z Till Kamppeter

>     pstoraster: Removed unneeded "-dDEBUG" from Ghostscript command line.

> [cups/pstoraster.in]

2010-08-12T18:10:47.335830Z Till Kamppeter

>     CUPS Raster output device: Do verbose degug logging only if compiled in debug mode. Bug 690581.

> [cups/gdevcups.c]

2010-08-12T06:39:08.575092Z regression

>     Added support for regression testing of the cups device.

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

2010-08-12T02:55:40.283339Z Michael Vrhel

>     Fix to handle case where the profiledir is NOT set AND there is a change in
>     the process color model for the device AFTER a profile had already been set.

> [base/gsicc_manage.c]

2010-08-12T01:42:17.270497Z Alex Cherepanov

>     Implement variable text rendering for widget annotations.
>     Bug 691536, customer 532.

> [Resource/Init/pdf_main.ps Resource/Init/pdf_draw.ps]

2010-08-11T23:31:48.385487Z Michael Vrhel

>     Fix for indeterminism issue that was introduced with changes in 16bit image
>     handling.  Last subpixel element was not getting unpacked properly.

> [base/gxi16bit.c]

2010-08-11T23:05:48.288399Z Michael Vrhel

>     Another compiler complaint fix.  Proper cast of device.

> [base/gdevpsdi.c]

2010-08-11T21:31:03.877037Z Michael Vrhel

>     Fix for compiler error due to implicit declaration

> [base/gdevpsdi.c base/devs.mak]

2010-08-11T18:54:51.837319Z Michael Vrhel

>     Fix so that if the device process color model changes the profile is updated accordingly.

> [base/gsicc_manage.c]

2010-08-11T16:17:45.421152Z Henry Stiles

>     Fix bug # 691532.  Do not attempt to clone an image that does not exist,
>     each completed page should have an associated image.  We'd like to handle
>     this corrupt file with a better fix, for example the absence of an end page
>     segement is clearly a problem with respect to the specification, but Adobe and
>     Artifex have chosen to support other "off spec" streams so more subtle
>     and less obvious error checking is needed.  Thanks to Tim Waugh for analysis on
>     this problem.

> [jbig2dec/jbig2_page.c]

2010-08-11T15:22:22.427529Z Ken Sharp

>     Add some words about the ps2write device to the devices documentation.

> [doc/Devices.htm]

2010-08-10T16:44:20.491267Z regression

>     Several minor changes to the cluster regression system, the most
>     signifcant of which are:

>     seg. faults are now reported for every case (previously they were only
>     reported if they were new)

>     skip.lst files are now checked for errors

>     changes to gs/psi now test the pcl/pxl/xps products since changes to
>     Ghostscript can affect the pdfwrite path

>     the tests_private/pdf/PDF_1.7_FTS repository was added

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

2010-08-10T16:20:19.775613Z Michael Vrhel

>     Commit to move the ICC profile for the device within the device structure.
>     This will make it easier to handle dynamic changes that may occur to the
>     process color model for the device.  Also a move of device profiles into non gc
>     memory and removal of any references to profiles to the GC.    A few progressions
>     occur with this commit including Bug689918.pdf testpage.pdf.

> [base/gxi12bit.c base/gsdevice.c base/gdevpdfk.c base/gxpcmap.c base/gxdevice.h /trunk/ghostpdl/xps/xpsgradient.c base/gdevprn.c base/gdevpsdi.c base/gscsepr.c base/gscpixel.c base/gxcmap.c base/gdevbit.c base/gxclip.c base/gxicolor.c base/gximag3x.c base/gscspace.c base/gsicc.c base/gscdevn.c base/gscolor2.c base/lib.mak base/gxiscale.c base/gsicc_manage.c base/gxcspace.h base/gscicach.c base/gdevnfwd.c base/gxdevcli.h base/gdevp14.c psi/zdevice.c base/gsicc_create.c base/gsicc_cache.c base/gdevp14.h base/gsicc_cache.h base/gxccman.c base/gscms.h base/gxclist.h psi/zusparam.c base/gxshade.c base/gxblend.c base/gsequivc.c base/gsciemap.c]

2010-08-10T09:15:50.312005Z Ken Sharp

>     Enhancement : pdfwrite

>     performance enhancement for pdfwrite when handling files with large amounts of text.

>     Bug #689859 "Performance comparison versions 7.07 and 8.62 on HP-UX ia64" Alex's
>     analysis shows that pdfwrite was spending a lot of time trying to to see if two type 1
>     fonts were the same before deciding whether a glyph could be added to a font, or was
>     already present in a font copy.

>     Most of the time was spent extracting and comparing /Subrs. The new code creates a hash
>     (MD5) of both the local and global Subrs (if present) and stores that in the type 1
>     'data' field in the font (16 bytes). The hashes are created by pdfwrite only as they
>     are required, so there is no performance penalty for rendering. The hash comparison is
>     considerably quicker than the long winded Subrs comparison.

>     For many files the performance difference is minimal but for file containing lots of
>     pages, mostly composed of text, there is a considerable saving. The text files run in
>     about 60% of the time they did before this change.

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

2010-08-10T08:13:35.250205Z Chris Liddell

>     A small revision to the fix for Bug 691326: the glyphs array must have
>     at least one entry.

>     No cluster differences expected.

>     Bug 691343

> [Resource/Init/gs_ttf.ps]

2010-08-09T00:41:31.173587Z Ray Johnston

>     Free the pattern-clist devices that are created (and left for the GC to
>     free) when pattern-clist patterns are used with a device that is using the
>     clist for the page. Those that were allocated during the print_page clist
>     playback would be those that leaked. Since the devices were closed, this
>     could lead to GC referencing objects that were invalid. Related to, but
>     not the final fix to Bug 691527.

> [base/gxpcmap.c]

2010-08-09T00:07:27.505245Z Alex Cherepanov

>     Remove spurious "cvx" operators after .pushextendedgstate and
>     .popextendedgstate . Do .popextendedgstate after checking that "Q"
>     has a correspondingh "q". Bug 691538.

> [Resource/Init/pdf_ops.ps]

2010-08-07T15:58:08.066501Z Alex Cherepanov

>     Implement rendering of Widget annotation border background specified by
>     /BC and /BG entries of the appearance characteristics dictionary /MK.
>     Bug 691524, customer 532.

> [Resource/Init/pdf_draw.ps]

2010-08-06T20:21:11.891509Z Ray Johnston

>     Fix segfault seen with fts_17_1704.pdf when the clist playback of patterns
>     that had been stored as clists were attempted to be read from the clist
>     as bitmaps. This happened when -dMaxPatternBitmap=1000000 was used which
>     is smaller than the default, confusing a HACK that attempted to force
>     the use of the pattern-clist mode. Also remove some #if 0 idle code.

> [base/gsptype1.c base/gxpcmap.c base/gxcolor2.h]

2010-08-06T17:22:16.521958Z Chris Liddell

>     I missed a couple of now unused variables in the previous commit.

> [psi/iname.c]

2010-08-06T15:49:21.355481Z Ray Johnston

>     Add documentation on -dMaxPatternBitmap=# parameter in the 'Improving
>     Performance' section of the Use.htm file. The actual parameter was
>     added in rev 11605.

> [doc/Use.htm]

2010-08-06T15:03:00.994141Z Chris Liddell

>     Prevent doing a gc "unmark" on memory already (potentially)
>     freed.

>     Relates to Bug 691380. I could not reproduce the seg fault
>     as reported, but valgrind reported the write to freed memory
>     in the same place as the reported seg fault.

> [psi/iname.c]

2010-08-06T11:15:22.616992Z Ken Sharp

>     Fix pdfwrite
>     There is a hack in type 3 font creation in pdfwrite which increases the FontMatrix if
>     all the elements are very small, apparently Acrobat is unable to cope with very small
>     FontMatrix entries.

>     However, if all the entries are 0, it ends up running round a loop multiplying by 10
>     indefinitely. This change simply avoids the loop if all the matrix elements are 0.
>     Naturally this isn't a useful font, its a Quality Logic test file.

> [base/gdevpdtt.c]

2010-08-06T11:11:40.511965Z Ken Sharp

>     Revision 11600 introduced a sever regression with text in XPS files. This revision
>     addresses that by only applying the fix to preserve glyph data when the text operation
>     is TEXT_FROM_SINGLE_GLYPH as this is the only case where the affected union is a glyph
>     not a pointer to a series of glyphs, and is therefore the only case which is affected.

>     Expected Differences: All XPS files with text should again work correctly.

> [base/gdevpdte.c]

2010-08-06T08:27:20.529691Z Chris Liddell

>     Revise some of the FAPI related information.

> [doc/Use.htm doc/Make.htm doc/Develop.htm doc/Psfiles.htm]

2010-08-06T05:53:42.503244Z Alex Cherepanov

>     Implement rendering of standard Stamp and Text annotations. Ghostscript uses
>     different font than Acrobat in Stamp icons and uses the same icon for the Text
>     annotation regardless of the /Name attribute. Bug 691525, customer 532.

> [Resource/Init/pdf_draw.ps]

2010-08-06T04:24:59.663647Z Ray Johnston

>     Add a new paramter MaxPatternBitmap with a default value of 8Mb. Formerly
>     the pattern_clist mode would be used when the bitmap size exceeded 1Mb
>     and prior to rev 11___ this calculation was flawed and could allow pattern
>     bitmaps as large as 64Mb to avoid the pattern_clist mode. While the clist
>     based pattern tiling is slow, setting the threshold to 8Mb should be rare
>     enough to minimize performance impact. Bug 691512.

> [base/gsdevice.c base/gdevp14.c base/gxdevcli.h base/gsdparam.c base/gxpcmap.c base/gxdevice.h base/gdevbit.c]

2010-08-05T23:26:12.261846Z Till Kamppeter

>     CUPS Raster output device: Segmentation fault on mid-job changes of the color depth.

>     This patch prevents the crash by forcing a memory reallocation on
>     color depth changes. The approach principally works but we did not
>     decide yet whether it is the final solution, as Michael Vrhel is still
>     doing major changes in the color handling. Bug 690435.

> [cups/gdevcups.c]

2010-08-05T19:16:11.698734Z Ray Johnston

>     Fix comment about no support for BITS=4

> [lib/viewrgb.ps]

2010-08-05T19:14:00.403158Z Ray Johnston

>     Minor correction to usage string left over from when this was split out
>     from setupgs.

> [psi/mkfilelt.cpp]

2010-08-05T17:40:36.908437Z Chris Liddell

>     The "show" machinery expected that even non-marking text operations
>     (such as stringwidth) would result in a glyph bitmap which
>     could be cached (assuming the glyph would be a candidate for the
>     cache with a normal marking operation, like show).

>     FAPI, however, did not create a glyph bitmap for non-marking
>     operations, thus the cache would receive a valid, but
>     "empty" glyph. This caused Postscript that used stringwidth
>     before a show to sometimes "lose" glyphs, by using the empty
>     cached glyph.

>     FAPI's behaviour now matches the expectations of the show/cache
>     management code.

>     Causes cluster differences in Bug688372.ps, fts_31_3111.pdf, and
>     14-08.PS, these are all progressions.

>     Bug 691517

> [psi/fapi_ft.c psi/zfapi.c]

2010-08-05T15:49:39.430735Z Ken Sharp

>     Fix (pdfwrite)
>     A piece of data (pointer to glyph data) was stored and passed into a routine
>     'process_text_modify_width' which expected the glyph data to remain unchanged but
>     modified the text enumerator data. This doesn't work if the glyph data is a pointer
>     to the text enumerator data. NB the text enumerator is saved and restored around the
>     call.

>     Modified so that the calling routine makes a copy of the glyph data before calling
>     'process_text_modify_width'.

>     This should prevent 13-10.ps from entering an infinite loop.

> [base/gdevpdte.c]

2010-08-04T23:15:24.779084Z Robin Watts

>     Fix for Bug 691504 (gs taking a long time to render a file).

>     Revision 8694 changes code from using a simple cast to an int to using
>     a call to (int)floor. This fixes problems, but costs a factor of 3 in
>     processing time for heavily tiled files.

>     Here we change to using a macro version of floor instead. This removes
>     the function call and NaN handling overheads and returns us to the
>     same kind of performance as we had before.

>     We apply the same change throughout the file (i.e. all the calls to (int)floor,
>     not just the two changed in r8694.

>     There is still scope for optimising this code further, but this closes the
>     regression.

>     No differences seen in local cluster testing.

> [base/gxp1fill.c]

2010-08-04T22:59:04.842835Z Alex Cherepanov

>     Implement rendering of Underline and StrikeOut annotations without
>     appearance streams. Bug 691526, customer 532.

> [Resource/Init/pdf_draw.ps]

2010-08-03T12:02:47.197684Z Ken Sharp

>     Fix : FAPI (no bug number, discovered working on a different problem)

>     Another place where the FAPI code assumes that a text enumerator is a show_enum and
>     casts it as such. While this is true for rendering, it is not the case when capturing
>     glyphs for pdfwrite.

>     Altered the code to test if the enumerator is a show_enum and if not, to get the
>     graphics state from the enumerator 'pis' pointer instead if possible. Signal an error
>     if this is not possible.

>     No differences expected.

> [psi/zfapi.c]

2010-08-03T08:02:13.862491Z Ken Sharp

>     Enhancement : PDF interpreter. Bug #691503

>     When creating an outline (/OUT pdfmark), especially for the pdfwrite device, check the
>     destination page to see that it lies between FirstPage and LastPage; if it does not, then
>     don't emit it. This is an extension to the existing control which checked that the
>     destination page wasn't greater than the number of pages in the PDF file.

> [Resource/Init/pdf_main.ps]

2010-08-03T07:56:50.987568Z Ken Sharp

>     In the section 'Using Unicode True Type fonts', replace the example CSI array with one
>     whose values are strings, not names. These must be string values.

> [doc/Use.htm]

2010-08-02T21:30:29.939498Z Alex Cherepanov

>     Partly revert rev. 11392 that over-simplified the check for a valid obj line
>     in the PDF file. Use --search-- to reject impossible cases but revert to the
>     old logic to verify the results. Bug 691502.

> [Resource/Init/pdf_rbld.ps]

2010-08-02T16:45:00.756282Z Alex Cherepanov

>     Fix a compiler warning about a missing prototype for free()
>     caused by my previous commit.

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

2010-08-02T13:49:03.975996Z Alex Cherepanov

>     Fix a memory leak. Free the paper name string allocated amd
>     returned by libpaper.

> [base/gp_upapr.c]

2010-08-02T09:20:04.666066Z Ken Sharp

>     Missing ';' in r11586 replaced. Should build now.

> [base/gdevpdfx.h]

2010-08-02T09:06:47.523074Z Ken Sharp

>     Fix a few minor compiler warnings from gcc. No differences expected.

> [base/gdevpdfx.h base/gdevpdf.c]

2010-08-02T06:39:25.229115Z Till Kamppeter

>     Applied patch to fix "imagen" output device (bug 690561).

> [base/gdevimgn.c]

2010-08-01T08:59:15.942136Z Chris Liddell

>     Remove the now redundant --disable-cairo directives.

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

2010-07-31T16:07:37.431496Z Chris Liddell

>     Remove the "dead" devcairo device.

>     No cluster differences expected.

>     Bug 690009

> [ghostscript.vcproj base/configure.ac base/gdevcairo.c base/devs.mak]

2010-07-31T15:45:39.194094Z Chris Liddell

>     Reapply r11570

>     Copying converted samples to the output raster used the byte
>     length of the input raster, rather than the byte length of
>     the converted data. Change to use the correct length.

>     Bug 691494 - credit to SaGS for the patch.

> [base/gdevdbit.c]

2010-07-31T15:04:24.124204Z Till Kamppeter

>     No need to install Resources and iccprofiles if COMPILE_INITS=1

>     When COMPILE_INITS=1, the mentioned directories are not used and just waste
>     disk space and also confusing. Bug 689253.

> [base/unixinst.mak]

2010-07-31T00:37:07.940018Z Ray Johnston

>     Fix the calculation of the size of the pattern bitmap by correcting the
>     calculation of the effective depth (bits per pixel). PaintType 2 is the
>     uncolored (mask == 1 bit per pixel) mode, PaintType 1 is colored, thus
>     needs the full target device color_info.depth bits per pixel. Bug 691514
>     detected running the PDF 1.7 FTS for customer 532.

> [base/gxpcmap.c]

2010-07-30T23:13:52.534878Z Till Kamppeter

>     Distinguish the two uses of cdev - one from icc merge, one the from very old lpd code (bug 691463).

>     This causes a warning when building with gcc, msvc, and also DEC CC.

> [base/gdevbbox.c]

2010-07-30T21:34:19.596701Z Till Kamppeter

>     Removed unneeded ";" characters from C code to silence warnings of DEC CC (bug 691463)

> [contrib/gdevbjc_.h base/gxpcolor.h base/strmio.h base/gdevrinkj.c base/gdevbit.c base/gdevpdtf.h base/gsovrc.h]

2010-07-30T20:38:48.303275Z Till Kamppeter

>     configure script: Hide error message when "sed" does not have a "--version" option.

> [base/configure.ac]

2010-07-30T20:09:21.607711Z Till Kamppeter

>     Tips about cross-compiling 64-bit ghostscript  on 32-bit windows

>     This procedure is slightly simplier(?) than the cross-compiling instruction
>     which Russell removed with r9807 about a year ago. Note that
>     ARCH_STRUCT_ALIGN_MOD mentioned in Russell's instruction was removed
>     r6773 (in 2006) and note also that all the "genconf" references in r9807
>     should be "genarch" instead.

> [doc/Make.htm]

2010-07-30T17:15:23.787490Z Michael Vrhel

>     Fix for bug 691488.

>     This commit fixes the issues that we are seeing with the JPEG2000 images in
>     the FTS files EXCEPT for the issues related to SmaskInData.  Those images
>     will be addressed in a separate commit and will now be handled in bug
>     691470.
>     With this commit, support is in place for faster 16 bit image rendering due
>     to the improved ICC support, which lets us avoid the multiple conversions from
>     16 bit to frac to float to unsigned short to byte which occurred in the old
>     flow.  Also, the jasper interface will now, when it encounters a 16 bit or
>     12 bit image, use the higher bit depth renderer and pass the data along.
>     Previously, we were truncating to 8bits in our jasper interface.  These
>     changes have been regression tested and checked with bmpcmp.

> [base/gxi12bit.c base/lib.mak base/gxi16bit.c Resource/Init/gs_lev2.ps Resource/Init/gs_res.ps base/sjpx.c Resource/Init/pdf_draw.ps base/gximage.h]

2010-07-30T17:13:46.325084Z Michael Vrhel

>     Fix for double to float conversion warnings. Bug 691498.

> [base/gsicc_create.c]

2010-07-30T17:06:59.251898Z Henry Stiles

>     rollback to revision 11564, 11565 broke the build

> [base/gxi12bit.c base/lib.mak base/gxi16bit.c contrib/gdevbjc_.h base/gdevbbox.c base/gxpcolor.h Resource/Init/gs_res.ps Resource/Init/pdf_draw.ps base/gsovrc.h base/gdevpdtf.h base/gsicc_create.c autogen.sh Resource/Init/gs_lev2.ps base/strmio.h base/configure.ac base/gdevrinkj.c base/sjpx.c base/gdevbit.c base/gximage.h base/gdevdbit.c]

2010-07-30T14:27:07.462183Z Michael Vrhel

>     Fix for bug 691488.

>     This commit fixes the issues that we are seeing with the JPEG2000 images
>     in the FTS files EXCEPT for the issues related to SmaskInData.  Those images
>     will be addressed in a separate commit and will now be handled in bug 691470.
>     With this commit, support is in place for faster 16 bit image rendering due to
>     the improved ICC support, which lets us avoid the multiple conversions from 16
>     bit to frac to float to unsigned short to byte which occurred in the old flow.
>     Also, the jasper interface will now, when it encounters a 16 bit or 12 bit image,
>     use the higher bit depth renderer and pass the data along.  Previously, we were
>     truncating to 8bits in our jasper interface.  These changes have been regression
>     tested and checked with bmpcmp.

> [base/gxi12bit.c base/lib.mak base/gxi16bit.c Resource/Init/gs_lev2.ps Resource/Init/gs_res.ps base/sjpx.c Resource/Init/pdf_draw.ps base/gximage.h]

2010-07-30T14:08:14.058178Z Chris Liddell

>     Copying converted samples to the output raster used the byte
>     length of the input raster, rather than the byte length of
>     the converted data. Change to use the correct length.

>     Bug 691494 - credit to SaGS for the patch.

> [base/gdevdbit.c]

2010-07-30T13:59:52.334818Z Michael Vrhel

>     Fix for double to float conversion warnings. Bug 691498

> [base/gsicc_create.c]

2010-07-30T11:37:15.489627Z Till Kamppeter

>     Distinguish the two uses of cdev - one from icc merge, one the from very old lpd code (bug 691463).

>     This causes a warning when building with gcc, msvc, and also DEC CC.

> [base/gdevbbox.c]

2010-07-30T11:20:07.130600Z Till Kamppeter

>     Suppressed error message during ./configure if "sed" does not support "--version" (bug 691463)

> [base/configure.ac]

2010-07-30T11:16:17.321612Z Till Kamppeter

>     Removed unneeded ";" characters from C code to silence warnings of DEC CC (bug 691463)

> [contrib/gdevbjc_.h base/gxpcolor.h base/strmio.h base/gdevrinkj.c base/gdevbit.c base/gdevpdtf.h base/gsovrc.h]

2010-07-30T11:12:47.691429Z Till Kamppeter

>     Removed unneeded quotes in autogen.sh.

> [autogen.sh]

2010-07-30T11:10:35.977735Z Till Kamppeter

>     On Tru64 stdint.h does not exist but the types required by jbig2 are in inttypes.h there (bug 691463).

> [base/configure.ac]

2010-07-30T11:03:27.732163Z Till Kamppeter

>     On Tru64 the integer types are in inttypes.h and not in stdint.h as in VMS

>     Bug 691463, required for jbig2dec.

> [base/stdint_.h jbig2dec/os_types.h]

2010-07-30T11:00:25.895059Z Till Kamppeter

>     Replace "==" bashism by "=" in configure.ac

>     "==" is a bash extension. See bash's manpage recommending "=" for posix
>     compliance (bug 691463). This causes various tests to fail and resulted
>     in the link failure from mis-detecting omni.

> [base/configure.ac]

2010-07-30T10:56:44.338677Z Till Kamppeter

>     '%' in printf() needs to be '%%'

>     Tru64 C issues a warning (bug 691463).

> [base/mkromfs.c]

2010-07-30T10:53:30.576036Z Till Kamppeter

>     Removed duplicate AC_PATH_PROG(pkg-config) check in ./configure.

>     The extra check caused

>     ./configure: !: not found

>     messages on some platforms. Bug 691463.

> [base/configure.ac]

2010-07-30T10:14:47.310782Z Till Kamppeter

>     Update documentation as --enable-dynamics is no longer required for "make so" to work.

> [doc/Make.htm]

2010-07-30T10:10:41.906626Z Till Kamppeter

>     Added some missing initializations in DeviceN

>     This should have been part of the DeviceN change. If left unset,
>     the code path assumes color display and goes down the color display
>     path and eventually segfaults. Bug 690428.

> [base/gdevxcmp.c]

2010-07-30T09:56:23.737093Z Till Kamppeter

>     Fix time-struct related build failure with SunStudio (bug 691453).

>     Apparently many platforms and compilers, including gcc and intel C,
>     require both <sys/time.h> and <time.h>. This patch just adds Sun Pro C
>     to the list of such platforms and compilers.

> [base/time_.h]

2010-07-30T09:45:51.500432Z Till Kamppeter

>     Avoid that the x11 output device can create huge windows which crash the X server. Bug 690444.

> [base/gdevxini.c]

2010-07-30T08:58:17.493418Z Till Kamppeter

>     Assorted fixes for the modularized X11 output device

>     All object files destined for shared libraries needed to be compiled
>     with -fPIC but this is not the case for gsparamx.c, gdevemap.c, and
>     gdevxcmp.c which are required by other parts to be built as standard.

>     This change makes x11 not depend on gsparamx.c and gdevemap.c (and not
>     geeting them included in the shared library X11.so). gsparamx.c is
>     part of psdf and is usually included and available, and gdevemap.c is
>     small enough to be inserted completely where it is used.

>     gdevxcmp.c is addressed by building it with $(GLCCSHARED) and not with
>     $(GLCC).

>     In addition, $(CC_SHARED) is only used for object files, rather than
>     for linking, so DYNAMIC_CFLAGS is more appropiate here than
>     DYNAMIC_LDLAGS.

>     Bug 691510

> [base/gdevxxf.c base/Makefile.in base/devs.mak]

2010-07-29T18:28:06.621749Z Ray Johnston

>     Add a comment recommending -sstdout=%stderr with -sOutputFile=- to prevent
>     PostScript files that print from messing up the output. Bug 691507.

> [doc/Use.htm]

2010-07-29T14:29:19.627579Z Robin Watts

>     Remove unused variable left over from removal of pattern_cache_alt.

>     No expected changes.

> [base/gsstate.c]

2010-07-29T14:05:39.594612Z Ken Sharp

>     Fix (pdfwrite) : try not to write out invalid xref

>     Exposed by bug #691503. There are circumstances under which we create a reference to a
>     /Page object which does not yet exist (creating an outline tree for example). In this
>     case we create a reference to the page, and set its initial offset to the current
>     position in the PDF file. When we later write the real object we update the position
>     to reflect the point in the file where it is actually stored.

>     However, if we don't actually ever write the object (in the case above, because
>     LastPage is set before the destination page), then the object remains pointing to the
>     wrong location in the file. This is then written into the xref table, and this confuses
>     the current version of Ghostscript.

>     The patch creates new pages with an offset of 0 (which is always invalid because the
>     PDF header means the minimum offset for any object is 15). If the page is later
>     created then the offset gets updated. If it is not written, however, we now check in
>     the xref writing code to see if an object has an offset of 0. If it does, then we
>     break the xref table up and do not write an xref entry for the missing object.

>     Ghostscript is happy with this and processes the file.

>     NB the proper fix is to not emit the Outline entry for the page which will not be
>     present in the output, and a patch has been suggested to achieve this. This code has
>     some uses, however, as it may prevent this kind of problem in the future. It also
>     permits objects to be created and never referenced (presumably because they are never
>     used) without leaving invalid entries in the xref, which might be useful.

>     No expected differences.

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

2010-07-29T13:59:53.090810Z Chris Liddell

>     Two changes for two primarily pdfwrite problems with FAPI/FT.

>     The first is to only replace whichever of BuildGlyph or BuildChar
>     procedures the original font actually contained, replacing both
>     regardless confused some of "decoding" code elsewhere in GS
>     (op_show_continue_dispatch()) and we ended up receiving a valid
>     glyph to render instead of notdef. In this case we ended up incorrectly
>     stroking a charpath (this was seen with Quark's Type 3 "special effects"
>     font). With rendering output this resulted in a boldening effect on the glyph,
>     in pdfwrite, the result was strange extra lines through the glyph.

>     The second change is to due pdfwrite's use of a unit matrix for some of
>     its work. This resulted in small glyph metrics rounding to zero within
>     Freetype, and pdfwrite thinking a glyph had a width of zero. So make
>     the scale value at which we consider a glyph to be "small" an order of magnitude
>     larger, which gets compensated for in the calculation of Freetype's final
>     matrix.

>     Unfortunately this does cause ~2600 differences in the cluster tests: some
>     are progressions, most are pixel differences due to rounding differences
>     because the scaling numbers have changed in Freetype.

>     Fixes Bug 691383

> [psi/fapi_ft.c psi/zfapi.c]

2010-07-28T18:44:46.282683Z Robin Watts

>     Fix bug #691493. Revert some of the work done for gs_2_colors.

>     I had needlessly attempted to have 2 pattern_cache's, one for stroking
>     colors and one for non-stroking colors. Given that the pattern_cache is
>     indexed by color id number, this is not necessary as all the data can
>     live happily in just one instance.

>     This removes the problem seen in the bug (where it was getting into an
>     infinite loop trying to populate the cache).

>     Local cluster testing shows this produces 57 differences, all (I think)
>     non-determinisms.

> [base/gsstate.c base/gxistate.h base/gsistate.c]

2010-07-28T12:37:51.588339Z Till Kamppeter

>     CUPS Raster output device "cups": Improved support for rendering jobs with high memory demands.

>     Let Ghostscript determine the memory buffer sizes automatically (as it
>     does with all the other output devices) if the environment variable
>     RIP_MAX_CACHE is not set, zero, or does not begin with a number (like
>     "auto"). If RIP_MAX_CACHE defines a valid value, use the actual value
>     for BufferSpace and not 1/10 of it. MaxBitmap is the maximum buffer
>     size to be used when rendering in full page mode, BufferSpace is the
>     buffer size used in banding mode. Banding mode is used if MaxBitmap is
>     too small to hold one page. Bug 691499.

> [cups/gdevcups.c]

2010-07-28T09:22:49.016213Z Robin Watts

>     Add new gp_thread_start, gp_thread_finish abstraction, and deprecate old
>     gs_create_thread function. Adapt multiple rendering thread code to use
>     this new style instead. Hopefully this should solve the problems seen
>     in rare cases when a test thread doesn't get scheduled until after the
>     DLL has exited and the code isn't around any more.

>     No expected differences.

>     This code has been tested with MSVC and on linux with pthreads. While it
>     should work with Borland and Watcom (as all the headers appear consistent)
>     I have not been able to properly test it. Therefore the code is currently
>     configured to fall back to the old code, thus hopefully guaranteeing that
>     this commit won't make the operation under Borland/Watcom any worse than
>     it is now. This fallback is controlled by a single define for each of
>     these systems in gp_wsync.c, so it's easy to test. If users can report
>     success with the new code we can remove the fallback trivially.

> [base/gp_wsync.c base/gxclthrd.c base/gp_nsync.c base/gp_psync.c base/gxclthrd.h base/gpsync.h]

2010-07-28T07:36:52.403693Z Ken Sharp

>     As pointed out by SaGS in Bug #691440, comment 5(C) there was a typo in revision 11498,
>     a '>>' was accidentally dropped form the batch file.

> [lib/ps2pdf.bat]

2010-07-27T07:10:03.221027Z Chris Liddell

>     Add missing free of the new bitmap data.

> [psi/zfapi.c]

2010-07-27T07:02:47.392994Z Chris Liddell

>     Slightly revise comment for why we might need to create a new bitmap
>     in fapi_finish_render_aux()

>     No cluster differences expected.

> [psi/zfapi.c]

2010-07-26T08:48:33.786696Z Chris Liddell

>     A much better solution for Bug 691328.

>     The bitmap data coming from a font scaler/renderer may not have its raster
>     alignment as Ghostscript expects, so in the event that is the case, create
>     a bitmap which is GS compatible in the FAPI layer, before calling any
>     further operations on it.

>     This reverts the previous "hack" from r11362.

>     No cluster differences expected.

> [base/gsbitops.c psi/zfapi.c]

2010-07-24T22:57:46.607791Z Alex Cherepanov

>     Render 3D annotations (using appearance stream) on the printer device even
>     if Print flag (0x4) is not set. This is done following AR8 and AR9 example
>     but contrary to PDF 1.7 spec. Bug 691486, customer 532.

> [Resource/Init/pdf_draw.ps]

2010-07-23T20:01:28.232264Z Alex Cherepanov

>     Make *clean targets remove generated tif*.h files. Bug 691485.

> [base/gs.mak]

2010-07-23T19:01:45.196186Z Alex Cherepanov

>     Remove .dividesfnts procedure, which is not needed by PS interpreter after
>     the introduction and use of string_array_access_proc() way back in
>     revision 176. FreeType doesn't require a particular way to split sfnts
>     either. ps2write includes procedures to create a well formed Type 42 from
>     a TrueType font.

>     The error is caused by .dividesfnts only spliting strings when the split
>     offset is even. The sample file has a *long* run of cases where the split
>     offsets are odd. When an even offset is finally found, the number of buffered
>     bytes exceeds the maximum length of the string causing /rangecheck error.
>     Thanks to Chris Liddell for the analysis of the problem.
>     Bug 691473, customer 532.

> [Resource/Init/gs_ttf.ps]

2010-07-23T09:20:28.484085Z Chris Liddell

>     Commit the correct change for Bug 691427

> [base/lib.mak]

2010-07-23T08:22:43.299979Z Chris Liddell

>     Change the gsicc* targets from using GCFLAGS to CFLAGS. This ensure that the
>     options for building .so objects are correct.

>     Additionally, add the extra dependencies to the sodebug target so it works
>     correctly.

>     No cluster differences expected.

>     Bug 691427

> [base/lib.mak base/unix-dll.mak]

2010-07-23T02:57:37.996803Z Alex Cherepanov

>     Handle the case when, contrary to the spec, default viewing optional content
>     configuration dictionary has /BaseState attribute equal /OFF. Mark all OCGs
>     /OFF and unmark ON UCGs. Bug 691491, customer 532.

> [Resource/Init/pdf_main.ps]

2010-07-21T19:26:14.458296Z Michael Vrhel

>     Fix for bug 691478

>     Note that string objects that are maintained as user params must be either
>     allocated in non-gc memory or be a constant in the executable. The problem stems
>     from the way userparams are retained during garbage collection in a param_list
>     (collected by currentuserparams).  For some reason this param_list does not get
>     the pointers to strings relocated during the GC. Note that the param_dict itself
>     is correctly updated by reloc, it is just the pointers to the strings in the
>     param_list that are not traced and updated. In this particular case, ICCProfilesDir
>     sets a string in the icc_manager. When a reclaim occurs, the string is relocated
>     (when in non-gc memory and when it is noted to the gc with the proper object
>     descriptor).  Then if a set_icc_directory occurs, the user params pointer has NOT
>     been updated and validation problems will occur.  Fix for this was to make the string
>     not known to the GC and to allocate in non-gc memory.  When icc manager is deallocated,
>     the string is also deallocated.

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

2010-07-21T00:03:16.900862Z Michael Vrhel

>     Fix so that non-isolated transparency groups are rendered correctly.  This fixes a
>     rendering issue with fts_25_2524 and with a few in the test suite.  A future optimization
>     will be to avoid the extra buffer push if the blend mode is normal, since in that case we
>     can draw directly into the parent buffer.

> [base/gdevp14.c]

2010-07-20T09:46:34.095118Z Masaki Ushizaka

>     Add support for user defined huffman table.

>     This code adds support for segment type 53 segments, which supplies
>     inline huffman code table.  Bug 689853.

>     Many thanks to Justin Greer.

> [jbig2dec/jbig2_segment.c jbig2dec/jbig2_huffman.c jbig2dec/jbig2_text.c jbig2dec/jbig2_symbol_dict.c jbig2dec/jbig2_huffman.h]

2010-07-20T08:23:05.218485Z Masaki Ushizaka

>     Catching up to the latest jbig2dec source.

>     This includes following jbig2dec git commits:

>     commit d26c7e4f39f76fe70cc61d6dc14d05a042a9be48
>     Author: Masaki Ushizaka <masaki@ghostscript.com>
>     Date:   Tue Jul 20 08:01:29 2010 +0000

>     Fix jbig2_image_set_pixel function prototype

>     The declaration of jbig2_image_set_pixel was differenct between
>     jbig2_image.h and jbig2_image.c (int value vs bool value).  And
>     prevented compiling it by MSVC comiler in C++ mode.
>     This patch fixes it.  Bug #691461.

>     commit c5d61c78c0de785b74b86d4e5298e3cc7b9e2b68
>     Author: Masaki Ushizaka <masaki@ghostscript.com>
>     Date:   Fri Jul 16 09:13:41 2010 +0000

>     A little fix to allocating memory size

>     commit e12fa07da845515911db8be2f7cfa8ef551061ba
>     Author: Tor Andersson <tor.andersson@gmail.com>
>     Date:   Thu Jul 15 00:49:09 2010 +0200

>     Use the jbig2_new and jbig2_renew macros instead of calling
>     jbig2_alloc and jbig2_realloc directly. Also adds a few typecasts
>     and #defines required to compile the source as C++.

>     commit 31dd7ef66dbd1c34df08365aa3c36e6391617f37
>     Author: Tor Andersson <tor.andersson@gmail.com>
>     Date:   Thu Jul 15 00:42:38 2010 +0200

>     Update VERSION define in config_win32.h

>     commit 941b73315a166fe07e0f1a1b81171477285280f7
>     Author: Tor Andersson <tor.andersson@gmail.com>
>     Date:   Thu Jul 15 00:41:46 2010 +0200

>     Add Makefile.unix -- a simple makefile for unix-like systems.

>     commit f6066822041bbffd7169fd4bfc19c48daae8f155
>     Author: Tor Andersson <tor.andersson@gmail.com>
>     Date:   Thu Jul 15 00:35:58 2010 +0200

>     Fix memory leak of the word stream struct.

>     No visible difference expected.

> [jbig2dec/config_win32.h jbig2dec/jbig2.c jbig2dec/jbig2_image_pbm.c jbig2dec/jbig2_metadata.c jbig2dec/jbig2_image.c jbig2dec/jbig2_huffman.c jbig2dec/jbig2_text.c jbig2dec/jbig2_priv.h jbig2dec/jbig2_image.h jbig2dec/jbig2_refinement.c jbig2dec/jbig2dec.c jbig2dec/jbig2_arith_iaid.c jbig2dec/jbig2_halftone.c jbig2dec/Makefile.unix jbig2dec/jbig2_segment.c jbig2dec/jbig2_arith.c jbig2dec/jbig2_symbol_dict.c jbig2dec/jbig2_generic.c jbig2dec/jbig2_page.c]

2010-07-20T05:56:04.938511Z Michael Vrhel

>     Remove noisy warnings if embedded icc profile is not valid.  In those
>     cases, we use the default and move on.

> [psi/zicc.c]

2010-07-19T21:22:35.957060Z Michael Vrhel

>     Fix for Bug691474.  Source of error was due to icc hash code being read from clist
>     after the transfer function.  It should have been read prior to the transfer function.
>     This was the first file we have seen that had a soft mask with a transfer function.
>     Also fix for rendering of this file.  The softmasks only uses the alpha channel as
>     opposed to the luminosity of the object.  Progression with CityMap-evnice.pdf in test
>     suite.  That file must have a alpha style softmask.

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

2010-07-19T15:45:36.535276Z Chris Liddell

>     Update trunk to FreeType 2.4.1

>     The important change (from Ghostscript's point of view) is that the previously
>     patented TrueType hinting operations have been enabled by default after the
>     expiration of the patents in question.

>     This change (the hinting being enabled) causes 3060 non-pdfwrite cluster
>     changes, and 655 pdfwrite changes - these are expected, and are
>     progressions.

> [freetype/builds/unix/config.sub freetype/src/pshinter/pshglob.c freetype/src/base/ftpfr.c freetype/src/pshinter/pshglob.h freetype/src/type1/t1objs.c freetype/docs/DEBUG freetype/builds/win32/w32-dev.mk freetype/src/type1/t1objs.h freetype/docs/reference/ft2-gasp_table.html freetype/src/pshinter freetype/docs/INSTALL.CROSS freetype/src freetype/docs/reference/ft2-lcd_filtering.html freetype/src/truetype/ttgload.c freetype/builds/win32/win32-def.mk freetype/src/type1 freetype/builds/wince/vc2005-ce freetype/src/truetype/ttgload.h freetype/src/tools/ftrandom/ftrandom.c freetype/devel/ft2build.h freetype/src/tools/docmaker/formatter.py freetype/src/autofit/Jamfile freetype/src/bdf/module.mk freetype/docs/reference/ft2-glyph_stroker.html freetype/include/freetype/config/ftheader.h freetype/src/cff/Jamfile freetype/src/cff/cffparse.c freetype/src/raster/ftraster.c freetype/src/cff/cffparse.h freetype/src/cff/cffcmap.c freetype/src/raster/ftraster.h freetype/src/cff/cffcmap.h freetype/src/raster/ftrend1.c freetype/include/freetype/internal/services/svttglyf.h freetype/builds/wince/vc2005-ce/freetype.vcproj freetype/src/raster/ftrend1.h freetype/docs/INSTALL.ANY freetype/src/psnames/module.mk freetype/src/base/ftutil.c freetype/src/autofit/afglobal.c freetype/src/cache/ftcsbits.c freetype/builds/mac/ftmac.c freetype/src/autofit/afglobal.h freetype/src/pcf/rules.mk freetype/src/base/ftsystem.c freetype/src/cache/ftcsbits.h freetype/builds/amiga/include/freetype freetype/builds/mac/FreeType.m68k_cfm.make.txt freetype/src/psaux/psaux.c freetype/builds/ansi freetype/src/cff/module.mk freetype/src/pshinter/rules.mk freetype/src/pcf/pcfread.c freetype/src/bdf/bdflib.c freetype/docs/reference/ft2-list_processing.html freetype/include/freetype/ftcache.h freetype/src/pcf/pcfread.h freetype/builds/unix/ft2unix.h freetype/src/raster/Jamfile freetype/builds/atari/FREETYPE.PRJ freetype/src/gzip/rules.mk freetype/src/pshinter/pshalgo.c freetype/include/freetype/internal/services/svcid.h freetype/include/freetype/ftincrem.h freetype/src/lzw freetype/builds/compiler/bcc-dev.mk freetype/src/pshinter/pshalgo.h freetype/src/tools/test_afm.c freetype/src/psnames/psnamerr.h freetype/src/cache/ftccache.c freetype/src/cache/ftcmru.c freetype/include/freetype/config/ftstdlib.h freetype/src/cid/cidtoken.h freetype/vms_make.com freetype/include/freetype/freetype.h freetype/docs/INSTALL.UNIX freetype/src/cache/ftccache.h freetype/src/cache/ftcmru.h freetype/src/tools/cordic.py freetype/src/pfr/Jamfile freetype/src/pfr/pfrload.c freetype/src/pfr/pfr.c freetype/builds/amiga/src freetype/src/pfr/pfrload.h freetype/include/freetype/fterrdef.h freetype/builds/detect.mk freetype/src/tools/ftrandom freetype/docs/reference/ft2-cache_subsystem.html freetype/builds/win32/vc2005 freetype/src/type1/t1gload.c freetype/builds/win32/vc2008 freetype/src/base/ftbbox.c freetype/builds/dos freetype/src/otvalid/otvgdef.c freetype/src/type1/t1gload.h freetype/include/freetype/ftsystem.h freetype/docs/reference/ft2-glyph_variants.html freetype/src/bdf/bdferror.h freetype/builds/unix/aclocal.m4 freetype/src/gxvalid/rules.mk freetype/docs/reference/ft2-bdf_fonts.html freetype/src/pcf/pcf.c freetype/src/otvalid/rules.mk freetype/include/freetype/internal/services/svotval.h freetype/src/bdf/Jamfile freetype/src/gxvalid/gxvbsln.c freetype/src/pfr/pfrdrivr.c freetype/src/pcf/pcf.h freetype/builds/compiler/win-lcc.mk freetype/src/type1/Jamfile freetype/src/pfr/pfrdrivr.h freetype/src/pcf/pcferror.h freetype/src/sfnt/ttsbit0.c freetype/src/base/ftmac.c freetype/builds/mac/FreeType.ppc_classic.make.txt freetype/src/base/ftgloadr.c freetype/src/base/ftbase.c freetype/docs freetype/builds/win32/vc2005/freetype.vcproj freetype/docs/reference/.gitignore freetype/src/base/ftbase.h freetype/builds/compiler freetype/src/gxvalid/gxvmort0.c freetype/src/bdf/bdf.c freetype/builds/amiga/src/base/ftsystem.c freetype/src/bdf/bdf.h freetype/src/cff/cff.c freetype/src/gxvalid/gxvalid.c freetype/builds/win32/w32-lcc.mk freetype/include/freetype/internal/services freetype/include/freetype/internal/psaux.h freetype/src/gxvalid/gxvalid.h freetype/autogen.sh freetype/src/base/fttype1.c freetype/docs/reference/ft2-type1_tables.html freetype/src/autofit/afmodule.c freetype/builds/unix/detect.mk freetype/include freetype/src/autofit/afmodule.h freetype/builds/vms freetype/src/pfr/pfrcmap.c freetype/objs/README freetype/builds/dos/dos-wat.mk freetype/builds/exports.mk freetype/src/pfr/pfrcmap.h freetype/src/psaux/Jamfile freetype/src/cff/cffpic.c freetype/builds/amiga/smakefile freetype/src/base/ftdebug.c freetype/src/gzip/inflate.c freetype/src/cff/cffpic.h freetype/src/type1/t1driver.c freetype/src/otvalid/otvbase.c freetype/include/freetype/ftmoderr.h freetype/src/gxvalid/gxvopbd.c freetype/src/type1/t1driver.h freetype/builds/win32/vc2005/freetype.sln freetype/builds/mac freetype/builds/atari freetype/builds/compiler/visualage.mk freetype/builds/newline freetype/builds/vms/ftsystem.c freetype/src/base/basepic.c freetype/src/type1/t1parse.c freetype/src/otvalid/otvmath.c freetype/src/gxvalid/gxvmort1.c freetype/src/base/basepic.h freetype/src/psnames/rules.mk freetype/src/type1/t1parse.h freetype/docs/reference/ft2-winfnt_fonts.html freetype/src/pcf/Jamfile freetype/src/gzip/Jamfile freetype/src/base/ftbdf.c freetype/builds/mac/ascii2mpw.py freetype/builds/unix/.gitignore freetype/src/raster/module.mk freetype/src/type1/t1afm.c freetype/src/cid/cidobjs.c freetype/include/ft2build.h freetype/include/freetype/internal/services/svgxval.h freetype/include/freetype/internal/ftrfork.h freetype/builds/win32/ftdebug.c freetype/src/tools freetype/src/type1/t1afm.h freetype/src/type1/t1tokens.h freetype/src/pshinter/pshrec.c freetype/src/cid/cidobjs.h freetype/builds/dos/dos-emx.mk freetype/src/pshinter/pshrec.h freetype/src/autofit/autofit.c freetype/builds/win32/w32-wat.mk freetype/builds/wince/vc2008-ce freetype/src/truetype/ttobjs.c freetype/include/freetype/ftchapters.h freetype/src/type1/t1errors.h freetype/include/freetype/ftlzw.h freetype/src/otvalid/otvgsub.c freetype/src/truetype/ttobjs.h freetype/src/tools/apinames.c freetype/src/winfonts/fnterrs.h freetype/src/cache/ftcache.c freetype/builds/win32/visualc/freetype.sln freetype/include/freetype/ftglyph.h freetype/docs/reference/ft2-gx_validation.html freetype/builds/vms/ftconfig.h freetype/builds/win32/vc2005/index.html freetype/builds/unix/unixddef.mk freetype/src/raster/rasterrs.h freetype/src/autofit/aflatin2.c freetype/builds/dos/detect.mk freetype/src/type42/Jamfile freetype/src/base/ftpic.c freetype/builds/wince freetype/src/autofit/aflatin2.h freetype/builds/win32/w32-mingw32.mk freetype/include/freetype/fttypes.h freetype/src/cache/ftcglyph.c freetype/src/gxvalid/gxvmort2.c freetype/builds/link_std.mk freetype/src/cache/ftcglyph.h freetype/src/pshinter/pshinter.c freetype/src/cache/Jamfile freetype/src/tools/test_bbox.c freetype/include/freetype/internal/services/svpsinfo.h freetype/src/type42/t42types.h freetype/builds/os2/os2-dev.mk freetype/builds/mac/ftlib.prj.xml freetype/src/gxvalid/gxvmort.c freetype/src/raster/rastpic.c freetype/builds/win32/vc2008/index.html freetype/src/gxvalid/gxvmort.h freetype/src/gxvalid/README freetype/src/raster/rastpic.h freetype/src/tools/docmaker/docbeauty.py freetype/builds/amiga/include freetype/docs/reference/ft2-incremental.html freetype/src/gzip/ftgzip.c freetype/include/freetype/ftcid.h freetype/include/freetype/internal/services/svpfr.h freetype/builds/compiler/watcom.mk freetype/builds/dos/dos-gcc.mk freetype/src/sfnt/module.mk freetype/src/psnames freetype/docs/INSTALL freetype/src/type1/t1load.c freetype/src/gzip/inftrees.c freetype/src/gzip freetype/builds/amiga/src/base/ftdebug.c freetype/docs/INSTALL.VMS freetype/src/type1/t1load.h freetype/src/gzip/inftrees.h freetype/src/pfr/pfrsbit.c freetype/src/gxvalid/gxvfeat.c freetype/src/cff/cfftoken.h freetype/include/freetype/internal/ftgloadr.h freetype/docs/PROBLEMS freetype/builds/wince/vc2008-ce/freetype.sln freetype/src/pfr/pfrsbit.h freetype/src/truetype/Jamfile freetype/src/gxvalid/gxvfeat.h freetype/builds/unix/configure freetype/docs/reference/ft2-basic_types.html freetype/src/otvalid freetype/src/gxvalid/gxvkern.c freetype/docs/INSTALL.MAC freetype/src/cid/Jamfile freetype/include/freetype/ftmm.h freetype/builds/symbian/freetype.mmp freetype/src/base/ftglyph.c freetype/src/sfnt freetype/src/otvalid/otverror.h freetype/docs/UPGRADE.UNIX freetype/src/autofit/afcjk.c freetype/src/autofit/aftypes.h freetype/src/sfnt/sfdriver.c freetype/src/psaux/afmparse.c freetype/src/autofit/afcjk.h freetype/src/sfnt/sfobjs.c freetype/src/base/ftobjs.c freetype/src/sfnt/sfdriver.h freetype/src/psaux/afmparse.h freetype/src/sfnt/sfobjs.h freetype/src/pfr/rules.mk freetype/docs/reference/ft2-sfnt_names.html freetype/builds/win32/visualc/freetype.vcproj freetype/builds/atari/deflinejoiner.awk freetype/src/psaux/module.mk freetype/src/base/ftstroke.c freetype/src/base/ftfstype.c freetype/docs/GPL.TXT freetype/src/base/ftbitmap.c freetype/src/pshinter/pshpic.c freetype/src/winfonts freetype/builds/dos/dos-def.mk freetype/src/pshinter/pshpic.h freetype/builds/win32/w32-gcc.mk freetype/src/psnames/pstables.h freetype/src/sfnt/rules.mk freetype/builds/wince/vc2005-ce/index.html freetype/src/autofit/afpic.c freetype/docs/raster.txt freetype/builds/atari/FNames.SIC freetype/builds/atari/ATARI.H freetype/src/autofit/afpic.h freetype/src/otvalid/otvgpos.c freetype/docs/reference/ft2-multiple_masters.html freetype/src/cff/cffdrivr.c freetype/docs/reference/ft2-base_interface.html freetype/src/cid/cidriver.c freetype/builds/mac/README freetype/src/otvalid/otvgpos.h freetype/include/freetype/ftgasp.h freetype/builds/unix/unix-cc.in freetype/src/autofit/afindic.c freetype/src/cff/cffdrivr.h freetype/src/cid/cidriver.h freetype/src/autofit/afindic.h freetype/docs/INSTALL.GNU freetype/src/raster freetype/builds/unix/ft-munmap.m4 freetype/src/winfonts/module.mk freetype/src/sfnt/ttkern.c freetype/docs/reference/ft2-index.html freetype/src/gzip/infutil.c freetype/src/sfnt/sferrors.h freetype/src/psaux/t1cmap.c freetype/src/sfnt/ttkern.h freetype/src/gxvalid/gxvmort4.c freetype/src/gzip/infutil.h freetype/include/freetype/ttnameid.h freetype/src/psaux/t1cmap.h freetype/builds/os2/detect.mk freetype/src/gzip/zconf.h freetype/docs/reference/ft2-user_allocation.html freetype/src/base/ftpatent.c freetype/src/truetype/rules.mk freetype/src/truetype freetype/src/base/ftadvanc.c freetype/src/tools/docmaker/tohtml.py freetype/builds/unix/unix-dev.mk freetype/src/otvalid/otvcommn.c freetype/src/otvalid/otvalid.c freetype/include/freetype/config/ftmodule.h freetype/src/otvalid/otvcommn.h freetype/src/otvalid/otvalid.h freetype/include/freetype/ftxf86.h freetype/include/freetype/internal/ftserv.h freetype/Jamrules freetype/src/type1/module.mk freetype/builds/win32/vc2008/freetype.sln freetype/src/base/ftapi.c freetype/docs/VERSION.DLL freetype/docs/LICENSE.TXT freetype/docs/reference/ft2-gzip.html freetype/builds/compiler/emx.mk freetype/include/freetype/ftstroke.h freetype/builds/unix/unix.mk freetype/include/freetype/ftlist.h freetype/include/freetype/ftbitmap.h freetype/objs/.gitignore freetype/src/type42/t42parse.c freetype/src/bdf/bdfdrivr.c freetype/modules.cfg freetype/docs/reference/ft2-toc.html freetype/docs/reference/ft2-computations.html freetype/builds/win32/visualce/freetype.dsp freetype/ChangeLog.20 freetype/src/cid/ciderrs.h freetype/src/type42/t42parse.h freetype/ChangeLog.21 freetype/builds/unix/configure.ac freetype/ChangeLog.22 freetype/builds/unix/ftconfig.in freetype/builds/beos freetype/ChangeLog.23 freetype/src/bdf/bdfdrivr.h freetype/builds/win32/visualce/freetype.dsw freetype/include/freetype/tttables.h freetype/docs/reference/ft2-quick_advance.html freetype/builds/unix/freetype2.in freetype/src/cid/module.mk freetype/src/autofit/afdummy.c freetype/src/gxvalid freetype/docs/reference/ft2-mac_specific.html freetype/src/tools/chktrcmp.py freetype/include/freetype/internal/services/svxf86nm.h freetype/src/autofit/afdummy.h freetype/src/pcf/pcfdrivr.c freetype/include/freetype/internal/ftobjs.h freetype/builds/symbian/bld.inf freetype/src/gxvalid/gxvmort5.c freetype/src/psnames/Jamfile freetype/src/pcf/pcfdrivr.h freetype/builds/unix/ftsystem.c freetype/docs/MAKEPP freetype/Jamfile freetype/builds/win32/visualce/index.html freetype/builds/compiler/gcc-dev.mk freetype/include/freetype/ftotval.h freetype/src/tools/test_trig.c freetype/src/tools/docmaker/content.py freetype/include/freetype/ftadvanc.h freetype/builds freetype/include/freetype/internal/services/svpostnm.h freetype/builds/unix/mkinstalldirs freetype/src/cff/rules.mk freetype/src/gzip/zlib.h freetype/src/type42/t42error.h freetype/src/smooth/module.mk freetype/src/sfnt/sfnt.c freetype/docs/reference/ft2-truetype_tables.html freetype/builds/compiler/gcc.mk freetype/builds/unix/config.guess freetype/src/otvalid/Jamfile freetype/src/autofit/afloader.c freetype/include/freetype/internal/services/svkern.h freetype/builds/beos/beos-def.mk freetype/src/autofit/afloader.h freetype/src/cache/ftcerror.h freetype/src/sfnt/Jamfile freetype/src/psaux/psobjs.c freetype/src/gzip/infcodes.c freetype/src/truetype/ttpic.c freetype/src/psaux/psobjs.h freetype/docs/reference/ft2-header_file_macros.html freetype/src/pshinter/pshnterr.h freetype/docs/reference/ft2-ot_validation.html freetype/src/base/ftcalc.c freetype/src/gzip/infcodes.h freetype/src/truetype/ttpic.h freetype/src/bdf/rules.mk freetype/include/freetype/internal/tttypes.h freetype/src/psaux freetype/builds/unix/freetype2.m4 freetype/docs/reference/ft2-outline_processing.html freetype/src/gxvalid/gxvmorx0.c freetype/include/freetype/internal/ftvalid.h freetype/include/freetype/fterrors.h freetype/builds/win32/visualc/freetype.dsp freetype/src/gzip/infblock.c freetype/builds/win32/visualc/freetype.dsw freetype/src/base/ftlcdfil.c freetype/include/freetype/internal/ftmemory.h freetype/src/type1/type1.c freetype/include/freetype/ftpfr.h freetype/src/gzip/infblock.h freetype/src/type42/rules.mk freetype/src/tools/ftrandom/Makefile freetype/src/pshinter/module.mk freetype/builds/amiga/include/freetype/config/ftmodule.h freetype/src/gxvalid/gxvmorx.c freetype/docs/formats.txt freetype/builds/amiga/makefile.os4 freetype/src/cff/cffobjs.c freetype/src/smooth/ftsmooth.c freetype/src/gxvalid/gxvmorx.h freetype/include/freetype/ftoutln.h freetype/src/cff/cffobjs.h freetype/docs/reference/ft2-truetype_engine.html freetype/builds/beos/detect.mk freetype/src/smooth/ftsmooth.h freetype/include/freetype/ftsynth.h freetype/src/winfonts/rules.mk freetype/src/tools/ftrandom/README freetype/src/pcf freetype/docs/CHANGES freetype freetype/src/base freetype/src/base/ftotval.c freetype/include/freetype/tttags.h freetype/src/autofit freetype/src/truetype/module.mk freetype/include/freetype/internal/autohint.h freetype/src/tools/glnames.py freetype/src/sfnt/ttload.c freetype/src/gxvalid/gxvfgen.c freetype/builds/atari/gen-purec-patch.sh freetype/src/sfnt/ttload.h freetype/src/pfr/pfrtypes.h freetype/docs/reference/ft2-system_interface.html freetype/builds/win32/w32-bcc.mk freetype/src/pcf/README freetype/src/gxvalid/gxvtrak.c freetype/include/freetype/internal/ftdriver.h freetype/objs freetype/include/freetype/ftgzip.h freetype/include/freetype/internal/services/svbdf.h freetype/src/base/ftrfork.c freetype/src/smooth/rules.mk freetype/src/base/rules.mk freetype/src/gxvalid/gxvmorx1.c freetype/src/autofit/afwarp.c freetype/src/cid/cidload.c freetype/include/freetype/ftgxval.h freetype/src/autofit/afwarp.h freetype/builds/win32/w32-intl.mk freetype/include/freetype/internal/services/svgldict.h freetype/src/cid/cidload.h freetype/src/gxvalid/gxvprop.c freetype/docs/reference/ft2-raster.html freetype/include/freetype/ftlcdfil.h freetype/src/type42/type42.c freetype/src/tools/docmaker/sources.py freetype/src/raster/rules.mk freetype/src/truetype/ttgxvar.c freetype/src/pshinter/Jamfile freetype/src/truetype/ttdriver.c freetype/src/gxvalid/Jamfile freetype/src/truetype/ttgxvar.h freetype/src/pfr/pfrgload.c freetype/builds/unix/unix-lcc.mk freetype/src/Jamfile freetype/src/pshinter/pshmod.c freetype/src/autofit/aflatin.c freetype/src/truetype/ttdriver.h freetype/src/base/ftsnames.c freetype/src/pfr/pfrgload.h freetype/src/pshinter/pshmod.h freetype/include/freetype/internal/ftcalc.h freetype/include/freetype/ftrender.h freetype/builds/unix freetype/src/base/ftgasp.c freetype/src/autofit/aflatin.h freetype/src/base/ftdbgmem.c freetype/src/smooth/ftspic.c freetype/include/freetype/t1tables.h freetype/src/cid/cidgload.c freetype/src/base/ftoutln.c freetype/src/smooth/ftspic.h freetype/builds/compiler/intelc.mk freetype/src/base/ftwinfnt.c freetype/src/base/ftsynth.c freetype/src/cid/cidgload.h freetype/include/freetype/internal/internal.h freetype/src/sfnt/ttbdf.c freetype/src/lzw/ftlzw.c freetype/src/sfnt/ttbdf.h freetype/builds/win32/vc2008/freetype.vcproj freetype/builds/win32/w32-bccd.mk freetype/src/truetype/ttpload.c freetype/src/gxvalid/gxvmorx2.c freetype/src/truetype/ttinterp.c freetype/src/lzw/rules.mk freetype/src/truetype/ttpload.h freetype/src/base/ftxf86.c freetype/src/base/ftstream.c freetype/src/truetype/ttinterp.h freetype/src/sfnt/ttcmap.c freetype/builds/ansi/ansi.mk freetype/include/freetype/internal/services/svmm.h freetype/src/pfr freetype/builds/compiler/ansi-cc.mk freetype/src/sfnt/ttcmap.h freetype/src/gxvalid/module.mk freetype/src/gxvalid/gxvjust.c freetype/builds/toplevel.mk freetype/src/truetype/tterrors.h freetype/builds/win32 freetype/builds/symbian freetype/src/pcf/pcfutil.c freetype/src/cid/type1cid.c freetype/src/pcf/pcfutil.h freetype/src/base/ftgxval.c freetype/builds/win32/visualce freetype/include/freetype/internal/pshints.h freetype/builds/amiga freetype/builds/amiga/src/base freetype/builds/win32/w32-icc.mk freetype/src/sfnt/ttmtx.c freetype/src/psnames/psmodule.c freetype/src/sfnt/ttmtx.h freetype/builds/wince/vc2008-ce/index.html freetype/src/psaux/psauxmod.c freetype/src/pfr/module.mk freetype/src/base/ftcid.c freetype/src/psnames/psmodule.h freetype/include/freetype/ftsnames.h freetype/src/psaux/psauxmod.h freetype/README.git freetype/configure freetype/src/gzip/inffixed.h freetype/src/bdf freetype/docs/reference/ft2-pfr_fonts.html freetype/src/sfnt/ttcmapc.h freetype/docs/reference freetype/builds/os2/os2-gcc.mk freetype/builds/compiler/bcc.mk freetype/builds/link_dos.mk freetype/docs/reference/ft2-cid_fonts.html freetype/include/freetype/ftwinfnt.h freetype/builds/unix/freetype-config.in freetype/src/pfr/pfrobjs.c freetype/src/base/Jamfile freetype/docs/release freetype/include/freetype/ftimage.h freetype/src/lzw/ftzopen.c freetype/src/pfr/pfrobjs.h freetype/src/lzw/Jamfile freetype/src/truetype/truetype.c freetype/Makefile freetype/src/base/fttrigon.c freetype/builds/win32/w32-vcc.mk freetype/src/lzw/ftzopen.h freetype/src/autofit/afhints.c freetype/builds/unix/install.mk freetype/src/autofit/afhints.h freetype/builds/win32/visualce/freetype.vcproj freetype/include/freetype/ftmac.h freetype/src/psaux/rules.mk freetype/src/type1/rules.mk freetype/src/cache/ftcimage.c freetype/src/psnames/pspic.c freetype/builds/atari/README.TXT freetype/src/cache/ftcimage.h freetype/include/freetype/config/ftconfig.h freetype/src/cid/cidparse.c freetype/src/psnames/pspic.h freetype/src/cff/cfferrs.h freetype/src/cid/cidparse.h freetype/docs/reference/ft2-version.html freetype/src/smooth/Jamfile freetype/src/tools/docmaker freetype/src/gzip/adler32.c freetype/src/tools/docmaker/.gitignore freetype/include/freetype/internal/sfnt.h freetype/docs/reference/README freetype/builds/compiler/unix-lcc.mk freetype/src/winfonts/winfnt.c freetype/devel/ftoption.h freetype/builds/wince/ftdebug.c freetype/src/gzip/zutil.c freetype/src/sfnt/sfntpic.c freetype/builds/unix/unix-def.in freetype/src/winfonts/winfnt.h freetype/builds/os2/os2-def.mk freetype/src/smooth/smooth.c freetype/src/gzip/zutil.h freetype/src/sfnt/sfntpic.h freetype/devel freetype/src/smooth/ftgrays.c freetype/src/raster/ftmisc.h freetype/docs/reference/ft2-module_management.html freetype/src/gxvalid/gxvmorx4.c freetype/include/freetype/internal/pcftypes.h freetype/src/pfr/pfrerror.h freetype/src/smooth/ftgrays.h freetype/src/winfonts/Jamfile freetype/builds/beos/beos.mk freetype/src/raster/raster.c freetype/include/freetype/internal/services/svwinfnt.h freetype/docs/CUSTOMIZE freetype/include/freetype/config freetype/builds/unix/configure.raw freetype/include/freetype/internal/t1types.h freetype/builds/wince/vc2008-ce/freetype.vcproj freetype/docs/reference/ft2-font_formats.html freetype/src/otvalid/module.mk freetype/include/freetype/internal/services/svpscmap.h freetype/ChangeLog freetype/include/freetype/fttrigon.h freetype/builds/win32/visualc freetype/src/cache/ftcmanag.c freetype/docs/FTL.TXT freetype/src/sfnt/ttsbit.c freetype/README freetype/src/cache/ftcmanag.h freetype/src/sfnt/ttsbit.h freetype/builds/mac/FreeType.ppc_carbon.make.txt freetype/builds/wince/vc2005-ce/freetype.sln freetype/docs/reference/ft2-sizes_management.html freetype/src/type42/t42drivr.c freetype/src/psaux/psconv.c freetype/include/freetype/ftbdf.h freetype/include/freetype/ftsizes.h freetype/src/type42/t42drivr.h freetype/src/cff freetype/include/freetype/internal/services/svtteng.h freetype/src/psaux/psconv.h freetype/include/freetype/internal/ftdebug.h freetype/src/tools/docmaker/docmaker.py freetype/src/gxvalid/gxverror.h freetype/src/autofit/module.mk freetype/include/freetype/internal/ftstream.h freetype/src/cff/cfftypes.h freetype/builds/modules.mk freetype/src/smooth freetype/docs/reference/ft2-bitmap_handling.html freetype/src/gxvalid/gxvmorx5.c freetype/src/gxvalid/gxvmod.c freetype/builds/freetype.mk freetype/include/freetype/internal/ftpic.h freetype/src/type42 freetype/src/gxvalid/gxvmod.h freetype/include/freetype/ftbbox.h freetype/src/otvalid/otvmod.c freetype/builds/unix/install-sh freetype/src/psnames/psnames.c freetype/builds/os2 freetype/src/cid/rules.mk freetype/src/psaux/psauxerr.h freetype/src/type42/t42objs.c freetype/src/otvalid/otvmod.h freetype/src/cache/ftccmap.c freetype/src/cache/ftcbasic.c freetype/src/cache freetype/src/smooth/ftsmerrs.h freetype/src/type42/t42objs.h freetype/include/freetype/internal/services/svttcmap.h freetype/version.sed freetype/builds/amiga/include/freetype/config/ftconfig.h freetype/src/psaux/t1decode.c freetype/docs/reference/ft2-glyph_management.html freetype/src/autofit/rules.mk freetype/src/tools/docmaker/utils.py freetype/builds/win32/visualc/index.html freetype/src/psaux/t1decode.h freetype/builds/ansi/ansi-def.mk freetype/src/otvalid/otvjstf.c freetype/src/type42/module.mk freetype/src/cff/cffgload.c freetype/src/autofit/aferrors.h freetype/src/gxvalid/gxvlcar.c freetype/builds/amiga/makefile freetype/include/freetype/internal/services/svsfnt.h freetype/src/bdf/README freetype/src/base/ftinit.c freetype/src/cff/cffgload.h freetype/src/cache/ftccback.h freetype/include/freetype/internal freetype/src/base/ftmm.c freetype/src/pcf/module.mk freetype/docs/TODO freetype/docs/reference/ft2-lzw.html freetype/src/tools/Jamfile freetype/builds/win32/detect.mk freetype/builds/unix/ltmain.sh freetype/src/autofit/afangles.c freetype/include/freetype/config/ftoption.h freetype/src/gxvalid/gxvcommn.c freetype/src/cff/cffload.c freetype/include/freetype freetype/src/autofit/afangles.h freetype/builds/compiler/visualc.mk freetype/src/gxvalid/gxvcommn.h freetype/src/cff/cffload.h freetype/builds/mac/FreeType.m68k_far.make.txt freetype/builds/amiga/include/freetype/config freetype/src/sfnt/ttpost.c freetype/src/sfnt/ttpost.h freetype/src/cid freetype/src/cache/rules.mk freetype/include/freetype/ttunpat.h freetype/builds/amiga/README freetype/include/freetype/ftmodapi.h freetype/include/freetype/internal/fttrace.h]

2010-07-18T05:30:08.091459Z Alex Cherepanov

>     Implement halftones type 6, 10, 16 in PDF interpreter.
>     Use default halftone when the halftone type is incorrect.

> [Resource/Init/pdf_draw.ps]

2010-07-18T00:03:37.786299Z Alex Cherepanov

>     Recognize enumerated color space #12 as CMYK following JPX baseline spec.

> [Resource/Init/pdf_draw.ps]

2010-07-17T21:23:39.853613Z Alex Cherepanov

>     Re-implement handling of named page sizes to avoid dependence on
>     the definitions of compatibility operators (a4, letter, etc.)
>     in userdict. Bug 691458.

> [Resource/Init/gs_init.ps Resource/Init/gs_setpd.ps Resource/Init/gs_statd.ps]

2010-07-17T00:07:09.985181Z Alex Cherepanov

>     Remove unused variables CC_D and CC_INT from all makefiles.

> [psi/os2.mak base/unixhead.mak base/bcwin32.mak base/openvms.mak base/watcw32.mak base/msvccmd.mak base/wccommon.mak]

2010-07-16T20:40:49.337914Z Alex Cherepanov

>     Fix the bug that prevented recognition of GenericResourceDir/Category/Name
>     as a valid resource path and required inclusion of GenericResourceDir in
>     the search path to find the same resource by searching.

>     New procedure does the following:
>     1. Returns GenericResourceDir/Category/Name if it exists.
>     2. Searches for Category/Name in LIBPATH. Returns actual path if found.
>     3. For non-existing resources return the same path as (1).

>     Old implementation added GenericResourceDir twice, didn't close files,
>     used system memory, called expensive procedures twice, etc.

>     Regression testing shows trivial differences in 23-07.ps, which prints
>     the length of ResourceFileName procedure.
>     This is a partial fix for bug 691408.

> [Resource/Init/gs_res.ps]

2010-07-16T19:58:03.971410Z Michael Vrhel

>     Prepend icc directory to device profile name if the default name is
>     used so that we have it during clist reading.  This is a fix for the
>     iccprofiles/ problem in 691408 when compile inits is not used.  Also,
>     fix so that the profile name is allocated in non-gc memory.  This was
>     a source of issues with the userparams dict not seeming to be traced
>     or at least not getting its members relocated if a profile in the icc
>     manager was relocated.  This fixes the breaking of the psdcmyk device
>     in rev  11499.  Also removal of spurious warning messages.

> [base/gsicc_manage.c]

2010-07-15T20:42:06.487509Z Ray Johnston

>     Change pdf14_put_image so that the gx_default_begin_typed_image will
>     be able to call the device's 'begin_image' which is often hooked for
>     device specific (hardware accelerated) image rendering. This avoids
>     the default image rendering which results in LOTS of fill_rectangle
>     calls. Found with customer 532.

> [base/gdevp14.c]

2010-07-15T19:28:38.670595Z Ray Johnston

>     The other half of the version.mak change.

> [Resource/Init/gs_init.ps]

2010-07-15T18:14:17.190964Z Ray Johnston

>     Update version to 9.00 PRE-RELEASE (with a bogus date, but before Aug 1)
>     This will serve to notify folks what the next release will be (not 8.72)

> [base/version.mak]

2010-07-15T14:49:39.770856Z Alex Cherepanov

>     Improve Ghostscript operation when current directory is not included in the
>     search path.
>     1. Make file path separators at the end of LIBPATH entries optional to reduce
>     the number of trivial configuration errors.
>     2. Search LIBPATH list for valid iccprofiles/ directory as a sibling to
>     (Resource) and set it as a default to ensure a valid default.
>     This code follows /GenericResourceDir example.
>     3. Make sure that the path name derived from /GenericFontDir is is not
>     searched but other font file names are searched. Earlier code relied on
>     a feature of .libfile not searching for an absolute path and failed
>     when the path was relative.
>     Partial fix for bugs 691350, 691408.

> [Resource/Init/gs_lev2.ps Resource/Init/gs_fonts.ps Resource/Init/gs_res.ps]

2010-07-15T05:42:55.376283Z Alex Cherepanov

>     Add copying default ICC profiles to disk-install location. This is necessary
>     for the builds with COMPILE_INITS=0, which looks for ICC profiles on disk.
>     Thanks to Hin-Tak for the patch. Bug 691449.

> [base/unixinst.mak]

2010-07-14T21:25:33.726848Z Till Kamppeter

>     Allow the CUPS Raster backend alternatively output compressed (version 2)
>     CUPS Raster data (bug #689885).

> [cups/gdevcups.c]

2010-07-13T18:30:29.088597Z Chris Liddell

>     Ensure the local variable into which we read Truetype cmap table data
>     (platform ID, encoding ID etc) is actually large enough to hold all
>     the data we read into it.

>     Bug 691452 (part 1)

>     No cluster differences expected.

> [base/gsfcid2.c]

2010-07-13T08:24:56.010563Z Ken Sharp

>     Update the documentation on producing PDF/X to make it clear that -sProcessColorModel
>     is an absolute requirement, even when using -dUseCIEColor, and that the PDFA_def.ps
>     file must be edited, at the very least to alter the ICCProfile entry.

>     Also made some minor syntax changes in PDF/A and PDF/X documentation for greater clarity.

> [doc/Ps2pdf.htm]

2010-07-13T07:04:59.625768Z Michael Vrhel

>     Fix for Bug 691444.  Issue was introduced when interpolation max output range
>     was set to be 65535 so that the output could be fed directly into CMM.
>     Problem was for HT output devices like pbmraw the interpolation filter
>     ignored the max range setting and used a max value of the frac range as
>     output.  This fixes a number of files that had regressions.  Files checked
>     with bmpcmp.

> [base/sidscale.c]

2010-07-13T01:20:10.578834Z Michael Vrhel

>     Fix for bug 691445.  pdf14 mapping procs were not paying attention to the
>     trans device in the imager state.  bmpcmp showed that this fixed several
>     files.

> [base/gdevp14.c]

2010-07-12T15:03:57.186505Z Chris Liddell

>     In the event the FAPI code has to replace the FontBBox array, make sure the new
>     array is marked executable.

>     No cluster differences expected.

> [psi/zfapi.c]

2010-07-11T15:26:14.804339Z Michael Vrhel

>     Fix for overprint regressions introduced with icc branch merge.  Review of bmp
>     compares reveals that this fixes a number of issues hence the large number of
>     differences with the commit.  There is one regression introduced with this commit,
>     which is IA3Z0302.pdf.pdf.pkmraw.300 page 2 a bug will be opened for this.   Also,
>     review of Atona_Technical_1v1_x3.pdf.pam.72 reveals there some overprint issues may
>     still exist with bitmap and halftone image overprinting on top of spotcolors when
>     Overprint is true and and Overprint mode is set to On.  This issue may have existed
>     prior to the icc commit.  Will open a bug to investigate.

> [base/gsicc_create.c base/gxcspace.h base/gscspace.c base/gsicc.c]

2010-07-10T01:28:54.795367Z Ray Johnston

>     Fix 'status' operator to return false when the IODevice prefix is
>     not found instead of undefinedfilename. Found while working on 691408.

> [psi/zfile.c]

2010-07-09T18:31:19.790276Z Ray Johnston

>     Fix to use stable memory for profiledir in icc_manager structure and change
>     all 'current_' functions to return the actual value set, the default, or
>     an empty string if no default. Also set the default ICCProfilesDir to
>     %rom%iccprofiles which will work if COMPILE_INITS=1. This should also be
>     set by the PS init code (see bug 691408).

> [psi/zusparam.c]

2010-07-09T09:40:17.170342Z Ken Sharp

>     Improve Windows batch files.
>     Bug #691440 "Windows bat files use relative paths and write to non-temp dir"

>     As suggested by Bjorn Martensson in bug #691440. Altered all batch files which call
>     other batch files so that they prepend the call with the location the original
>     batch file was executed from. This allows batch files such as ps2pdf.bat to be called
>     from locations other than the Ghostscript 'lib' directory.

>     Also altered the location of temporary files created by the batch files to the Windows
>     temporary folder by using the %TEMP% environment variable. If this variable is not set
>     for some reason then this will still default to the current directory, as it does now.
>     This allows batch files to be run from directories which are read only.

>     Since these files are not used by our (Linux) cluster there will be no differences. I
>     have tested a number of the scripts, but not all of them. The ones I have tested seem
>     to work well.

>     I finally found a reference which states that the %~d batch parameter was introduced
>     to Windows in NT4, this means that these batch files will likely fail on older versions
>     of Windows (ie Windows 3.x/95/98). I don't believe we need to support such antiquated
>     Operating Systems any further.

> [lib/pf2afm.bat lib/gsdj500.bat lib/ps2ascii.bat lib/ps2pdfxx.bat lib/lpr2.bat lib/gsndt.bat lib/gstt.bat lib/eps2eps.bat lib/pdf2dsc.bat lib/gsbj.bat lib/ps2epsi.bat lib/gsdj.bat lib/dumphint.bat lib/ps2ps2.bat toolbin/msvcxml.bat lib/gsnd.bat lib/font2c.bat lib/pdfopt.bat lib/gst.bat lib/pdf2ps.bat lib/ps2pdf.bat lib/gslj.bat lib/bdftops.bat lib/pfbtopfa.bat lib/ps2pdf12.bat lib/ps2pdf13.bat lib/ps2pdf14.bat lib/gslp.bat lib/lpgs.bat lib/ps2ps.bat lib/pftogsf.bat]

2010-07-08T20:01:59.912724Z Robin Watts

>     Extend the experimental ENABLE_TRAP_AMALGAMATION code to the
>     TEMPLATE_slant_into_trapezoids cases too. The current code generates 3
>     trapezoids; the new code will (if the option is enabled) attempt to
>     amalgamate the top/bottom traps into the middle one.

>     Enabling this code (but disabling the existing code for trap amalgamation)
>     shows no differences. Enabling all the trap amalgamation code shows 888
>     differences, all fairly innocuous.

>     As this code is going in disabled, no cluster differences are expected.

> [base/gxfillts.h base/gxfill.c]

2010-07-08T16:20:20.892723Z Alex Cherepanov

>     Update the Ghostscript man page to reflect the new default for -P option
>     made by the rev. 11494.

> [man/gs.1]

2010-07-07T21:27:55.422122Z Marcos H. Woehrmann

>     clusterpush.pl with no options now tests language_switch build as well as gs, pcl, and xps.

>     Also some minor documentation improvements.

> [toolbin/localcluster/clusterpush.pl toolbin/localcluster/readme]

2010-07-07T17:47:09.812924Z Alex Cherepanov

>     Dont't search for initialization files in the current directory first
>     by default because this leads to well-known security and confusion problems.
>     Do this only on the user's request by -P switch. Also revert rev. 11468,
>     which is no longer needed. Bug 691350.

> [base/openvms.mmk psi/zfile.c doc/Use.htm base/bcwin32.mak base/ugcclib.mak base/Makefile.in base/unix-gcc.mak base/macos-mcp.mak toolbin/msvcxml.bat psi/os2.mak base/watclib.mak base/openvms.mak base/macosx.mak base/watcw32.mak psi/msvc32.mak base/unixansi.mak base/msvclib.mak]

2010-07-07T13:49:57.894248Z Ken Sharp

>     Fix : temporary memory device not finalized.

>     clist_init_data creates a temporary memory device in order to "get the memory planarity
>     set up", using a local variable to hold the device. When the function exits the
>     variable goes out of scope and disappears.

>     Because the memory device is a forwarding device it increments the reference count of
>     its target, but because it is never finalized it does not decrement the reference count
>     when it is destroyed, leading to an incorrect target reference count.

>     This only affects pdfwrite at present, but it prevents valid PDF files being written
>     because the file is only terminated when the pdfwrite device reference count reaches
>     0 and the pdfwrite device is closed.

>     Added calls to finalize the device before discarding it.

>     No expected differences.

> [base/gxclist.c]

2010-07-06T22:27:32.077335Z Alex Cherepanov

>     Increase the max number of color components to 14 to accomodate a new
>     record (13) found in the wild. Bug 691425.

> [base/gsccolor.h]

2010-07-06T09:25:40.558632Z Ken Sharp

>     Fix (pdfwrite) : Named destinations with no /Page not working properly

>     Bug #691344 "REGRESSION: ps2pdf of 8.70 generates correct hyperlinks but not ps2pdf of
>     8.71"

>     The revisions 9779 and 9788 fixed a problem where DOCVIEW pdfmarks without a /Page or
>     /View entry were producing invalid PDF files, and a problem with DEST pdfmarks arising
>     from it.

>     Because DOCVIEW and DEST pdfmarks share some common code in pdfwrite to create a
>     Destination annotation in the outptu PDF, this still left some confusion in the code.
>     The problem was that DOCVIEW pdfmarks need not contain Page or View data, but named
>     destinations *must*, but pdfmarks need not specify, in which case the current page is
>     used.

>     Added a parameter to pdf_make_dest which allows us to differentiate the two cases and
>     use the current page number for a named destination if no page is supplied.

>     The regression suite can't test this non-printing feature, so no differences are
>     expected.

> [base/gdevpdfm.c]

2010-07-06T07:04:53.806003Z Ken Sharp

>     Improve handling an error condition as suggested by Alex Cherepanov in Bug #691435,
>     comment 9.

> [base/gdevpdfj.c]

2010-07-06T00:11:44.270183Z Ray Johnston

>     Fix BAND_LIST_STORAGE=memory to handle files that create compressed memory
>     files > 2Gb. Also add code to make the reporting of these file sizes a bit
>     better, but portability may still be an issue. Reference Bug 690199 for
>     customers 850 and 531.

> [base/gxclmem.c base/gxclist.c]

2010-07-05T23:51:46.696108Z Alex Cherepanov

>     Replace all '==' executable names with '//== exec' in Ghostscript start-up
>     code because MS driver redefines '==' in a way that requires write access to
>     the top dictionary, and this is not always the case. Bug 689957.

> [Resource/Init/gs_cmap.ps Resource/Init/gs_pdfwr.ps Resource/Init/pdf_main.ps Resource/Init/gs_resmp.ps Resource/Init/pdf_font.ps Resource/Init/gs_fonts.ps Resource/Init/pdf_base.ps Resource/Init/pdf_sec.ps Resource/Init/gs_ttf.ps Resource/Init/pdf_draw.ps Resource/Init/gs_cff.ps Resource/Init/gs_fapi.ps]

2010-07-05T16:18:38.343520Z Alex Cherepanov

>     Set svn:ignore property for all remaining generated files in jasper,
>     jbig2dec, and tiff directories.

> [tiff/contrib/iptcutil tiff/contrib/tags tiff/build tiff/tools tiff tiff/contrib tiff/contrib/mac-mpw tiff/contrib/acorn tiff/html jasper/src/libjasper/include/jasper tiff/contrib/mac-cw tiff/contrib/dbs tiff/html/images tiff/man tiff/contrib/win_dib tiff/html/man tiff/libtiff tiff/test tiff/contrib/addtiffo jbig2dec tiff/port tiff/contrib/ras tiff/contrib/mfs tiff/contrib/pds tiff/contrib/dbs/xtiff tiff/contrib/stream]

2010-07-05T15:10:09.278642Z Ken Sharp

>     Add a pair of parentheses to silence a gcc compiler warning. Also extend the comment
>     slightly to be a little more informative.

>     No differences expected.

> [base/gdevpdfj.c]

2010-07-05T05:13:16.304757Z Alex Cherepanov

>     Use the presence of /CIDSystemInfo instead of /Subtype value to decide
>     whether the object is a CID font. The former is required by Acrobat, the
>     latter appears to be ignored by Acrobat, and so may be wrong. Bug 691426.

> [Resource/Init/pdf_font.ps]

2010-07-05T01:23:43.139942Z Hin-Tak Leung

>     test for emptiness of HAVE_FONTCONFIG is better than non-yes-ness of
>     enable_fontconfig;
>     fine-tuning of r11448 to --disable-cairo when fontconfig is not available or
>     user-disabled

> [base/configure.ac]

2010-07-05T01:18:30.861454Z Hin-Tak Leung

>     new/renamed documentation file libpng-1.2.44.txt missed in r11482 for
>     libpng 1.2.42->1.2.44 upgrade

> [libpng/libpng-1.2.44.txt]

2010-07-04T19:04:17.740307Z Alex Cherepanov

>     Reaplly Hin-Tak's patch, rev. 11453, which was rolled back by the rev. 11462.

>     Apply diff between stock 1.2.42 <-> 1.2.44 to upgrade to libpng 1.2.44
>     - bug
>     fixes - CVE-2010-1205. Bug 691438.

> [libpng/pngrtran.c libpng/scripts/makefile.gcmmx libpng/contrib/pngminim/encoder/gather.sh libpng/scripts/makefile.sgi libpng/scripts/makefile.sco libpng/scripts/makefile.hpgcc libpng/KNOWNBUG libpng/projects/xcode/libpng.xcodeproj/project.pbxproj libpng/scripts/pngos2.def libpng/scripts/makefile.nommx libpng/scripts/makefile.linux libpng/pngmem.c libpng/png.c libpng/contrib/pngminim/decoder/gather.sh libpng/scripts/makefile.64sunu libpng/scripts/makefile.elf libpng/scripts/libpng-config-head.in libpng/png.h libpng/CMakeLists.txt libpng/pngrio.c libpng/pngpread.c libpng/Y2KINFO libpng/scripts/makefile.netbsd libpng/pngwio.c libpng/pngrutil.c libpng/scripts/makefile.hpux libpng/scripts/makefile.darwin libpng/scripts/makefile.sggcc libpng/README libpng/contrib/pngminim/decoder/makefile libpng/scripts/makefile.32sunu libpng/libpngpf.3 libpng/scripts/makefile.solaris-x86 libpng/libpng-1.2.42.txt libpng/contrib/pngminim/preader/makefile libpng/scripts/makefile.solaris libpng/pngwtran.c libpng/contrib/pngminim/preader/gather.sh libpng/scripts/makefile.mingw libpng/scripts/makefile.aix libpng/scripts/makefile.hp64 libpng/scripts/png32ce.def libpng/scripts/makefile.beos libpng/scripts/makefile.ne12bsd libpng/pngread.c libpng/scripts/pngw32.def libpng/pngget.c libpng/INSTALL libpng/scripts/makefile.cegcc libpng/CHANGES libpng/contrib/pngminim/encoder/makefile libpng/projects/wince.txt libpng/libpng.3 libpng/example.c libpng/scripts/makefile.so9 libpng/pngwrite.c libpng/pngconf.h libpng/pngset.c libpng/LICENSE libpng/png.5 libpng/pngwutil.c libpng/scripts/makefile.openbsd libpng/scripts/makefile.dec libpng/scripts/README.txt libpng/scripts/makefile.cygwin libpng/pngtest.c libpng/ANNOUNCE libpng/scripts/libpng.pc.in]

2010-07-03T00:29:40.754683Z Hin-Tak Leung

>     missed linker defines needed to build under 64-bit windows in a
>     previous commit r11388 for bug 691302

> [psi/msvc32.mak]

2010-07-01T21:58:29.492747Z Michael Vrhel

>     Bubble up of error when allocation of default profile cmm handle fails. Fix for bug 691429

> [base/gsicc_manage.c]

2010-07-01T21:13:55.381754Z Hin-Tak Leung

>     revert r11469(r11455) - wrong fix to bug 690428

> [base/gdevxcmp.c]

2010-07-01T19:08:29.177579Z Ken Sharp

>     Enhancement (pdfwrite) : Fall back to Flate instead of JPEG when an image turns out
>     short.

>     Bug #691435 "any PDFSETTINGS besides /default gives dictfull error"

>     There are two problems; firstly when an error is encountered closing a filter the
>     error code (-1 or -2 usually) is returned and interpreted as a regular GS error,
>     resulting in ridiculous error messages. Modified to return ioerror instead.

>     Secondly, when an image terminates with insufficient data and pdfwrite is creating a
>     DCT encoded image, we can't complete the image. In this case try to fall back to the
>     simple Flate compressed stream instead.

>     No differences expected.

> [base/gdevpdfj.c]

2010-07-01T17:14:23.564053Z Michael Vrhel

>     Fix for Bug 691431.  This was caused by a PS CIE color space being
>     used for a transparency group color space.  That really should not
>     be allowed since those color spaces are unidirectional.  They are
>     installed though when -dUseCIEColor is used with a PDF file that has
>     transparency. Solution is to use the default ICC profiles for the group
>     color space when this occurs.

> [base/gstrans.c]

2010-07-01T12:19:20.914734Z Robin Watts

>     Revert revision 11472 as it breaks almost every file in the cluster tests,
>     and it's preventing other meaningful work being done.

> [base/gp_unifn.c]

2010-07-01T00:41:57.037474Z Hin-Tak Leung

>     reapply 11457

> [base/gs_dll_call.h]

2010-07-01T00:40:43.889090Z Hin-Tak Leung

>     reapply 11456

> [base/gp_unifn.c]

2010-07-01T00:36:16.428446Z Hin-Tak Leung

>     reapply 11454 for outdated config.guess config.sub. see original commit log

> [jpeg/config.guess jpeg/config.sub]

2010-07-01T00:33:05.624689Z Hin-Tak Leung

>     typo that causes linker error if one does not do make clean between builds

> [base/lib.mak]

2010-07-01T00:00:22.982087Z Hin-Tak Leung

>     reapply r11455 - see original commit log for details

> [base/gdevxcmp.c]

2010-06-30T23:34:11.835858Z Hin-Tak Leung

>     security patch from Werner Fink, to disable loading init files from
>     group/world-writable directories - bug 691350

> [psi/zfile.c]

2010-06-30T22:12:02.295636Z Michael Vrhel

>     Initialize profile member variables that are part of serialization.
>     Fix for Bug 691433

> [base/gsicc_manage.c]

2010-06-29T18:06:29.735123Z Henry Stiles

>     remove obsolete clusterpush scripts.

> [/trunk/ghostpdl/tools/clusterpush.sh toolbin/clusterpush.sh]

2010-06-29T17:17:45.269232Z Henry Stiles

>     revert back to 11450.

> [/trunk/ghostpdl/main/pcl6_gcc.mak libpng/pngrtran.c libpng/scripts/makefile.gcmmx base/ugcclib.mak libpng/contrib/pngminim/encoder/gather.sh /trunk/ghostpdl/xps/xpspath.c base/unix-gcc.mak libpng/scripts/makefile.sgi base/gp_unifn.c base/macos-mcp.mak libpng/scripts/makefile.sco libpng/scripts/makefile.hpgcc /trunk/ghostpdl/main/pcl6_msvc.mak libpng/KNOWNBUG libpng/projects/xcode/libpng.xcodeproj/project.pbxproj libpng/scripts/pngos2.def base/macosx.mak libpng/scripts/makefile.nommx libpng/scripts/makefile.linux jpeg/config.guess base/unixansi.mak libpng/pngmem.c base/msvclib.mak libpng/png.c libpng/contrib/pngminim/decoder/gather.sh libpng/scripts/makefile.64sunu jpeg/config.sub libpng/scripts/libpng-config-head.in libpng/scripts/makefile.elf libpng/png.h base/lib.mak libpng/CMakeLists.txt libpng/pngrio.c libpng/Y2KINFO libpng/pngpread.c libpng/scripts/makefile.netbsd /trunk/ghostpdl/xps/xps_msvc.mak libpng/pngwio.c libpng/pngrutil.c libpng/scripts/makefile.hpux libpng/scripts/makefile.darwin libpng/scripts/makefile.sggcc /trunk/ghostpdl/xps/xpsglyphs.c libpng/README doc/Make.htm libpng/contrib/pngminim/decoder/makefile libpng/scripts/makefile.32sunu libpng/libpngpf.3 libpng/scripts/makefile.solaris-x86 /trunk/ghostpdl/language_switch/pspcl6_msvc.mak libpng/libpng-1.2.42.txt libpng/contrib/pngminim/preader/makefile libpng/libpng-1.2.44.txt libpng/scripts/makefile.solaris base/Makefile.in libpng/pngwtran.c libpng/contrib/pngminim/preader/gather.sh /trunk/ghostpdl/xps/xpstile.c /trunk/ghostpdl/xps/xpsgradient.c libpng/scripts/makefile.hp64 base/gs_dll_call.h libpng/scripts/makefile.aix libpng/scripts/makefile.mingw libpng/scripts/png32ce.def /trunk/ghostpdl/common/msvc_top.mak libpng/scripts/makefile.beos base/watclib.mak /trunk/ghostpdl/xps/xpsopacity.c libpng/scripts/makefile.ne12bsd libpng/pngread.c /trunk/ghostpdl/xps/xpspage.c libpng/scripts/pngw32.def libpng/pngget.c libpng/INSTALL libpng/scripts/makefile.cegcc libpng/CHANGES libpng/contrib/pngminim/encoder/makefile libpng/libpng.3 libpng/example.c libpng/projects/wince.txt base/bcwin32.mak libpng/scripts/makefile.so9 libpng/pngconf.h libpng/pngwrite.c libpng/pngset.c libpng/LICENSE libpng/png.5 libpng/pngwutil.c base/openvms.mak base/gdevxcmp.c libpng/scripts/makefile.openbsd libpng/scripts/makefile.dec base/watcw32.mak base/unix-dll.mak libpng/scripts/README.txt libpng/scripts/makefile.cygwin psi/msvc32.mak libpng/pngtest.c libpng/ANNOUNCE /trunk/ghostpdl/xps/xpsimage.c libpng/scripts/libpng.pc.in]

2010-06-29T07:08:29.009258Z Hin-Tak Leung

>     more cygwin/mingw-related patches from Jan Nieuwenhuizen (lilypond/gub) ; this
>     one depends on features of GNU make, so it is added as comments to avoid
>     breaking build with non-GNU make

> [base/unix-dll.mak]

2010-06-29T07:05:45.877229Z Hin-Tak Leung

>     avoid re-define _Windows if it is already defined; one of the cygwin/mingw-related
>     patches from Jan Nieuwenhuizen (lilypond/gub)

> [base/gs_dll_call.h]

2010-06-29T07:04:25.796552Z Hin-Tak Leung

>     cygwin is one platform which uses the unix file name interface but is
>     sensitive to binary/text mode; one of the cygwin/mingw-related patches from
>     Jan Nieuwenhuizen (lilypond/gub)

> [base/gp_unifn.c]

2010-06-29T06:47:59.438186Z Hin-Tak Leung

>     gx_device_has_color() was changed 8 years ago in the deviceN commit (r2925),
>     from just color_info.numcomponents > 1 to
>     || (dev)->color_info.gray_index == GX_CINFO_COMP_NO_INDEX .

>     This has some unfortunate side-effect for continuous tone gray devices which
>     doesn't support transparency, such as a 8-bit gray X11 display, which goes
>     down the wrong code path. These are quite rare so it took 7 years for the bug
>     (bug 690428) to be seen.

> [base/gdevxcmp.c]

2010-06-29T06:05:26.121392Z Hin-Tak Leung

>     updating jpeg config.sub config.guess to that from
>     libpng 1.2.44; bug 690486

> [jpeg/config.guess jpeg/config.sub]

2010-06-29T05:30:19.407679Z Hin-Tak Leung

>     apply diff between stock 1.2.42 <-> 1.2.44 to upgrade to
>     libpng 1.2.44 - bug fixes - CVE-2010-1205

> [libpng/pngrtran.c libpng/scripts/makefile.gcmmx libpng/contrib/pngminim/encoder/gather.sh libpng/scripts/makefile.sgi libpng/scripts/makefile.sco libpng/scripts/makefile.hpgcc libpng/KNOWNBUG libpng/projects/xcode/libpng.xcodeproj/project.pbxproj libpng/scripts/pngos2.def libpng/scripts/makefile.nommx libpng/scripts/makefile.linux libpng/pngmem.c libpng/png.c libpng/contrib/pngminim/decoder/gather.sh libpng/scripts/makefile.64sunu libpng/scripts/makefile.elf libpng/scripts/libpng-config-head.in libpng/png.h libpng/CMakeLists.txt libpng/pngrio.c libpng/pngpread.c libpng/Y2KINFO libpng/scripts/makefile.netbsd libpng/pngwio.c libpng/pngrutil.c libpng/scripts/makefile.hpux libpng/scripts/makefile.darwin libpng/scripts/makefile.sggcc libpng/README libpng/contrib/pngminim/decoder/makefile libpng/scripts/makefile.32sunu libpng/libpngpf.3 libpng/scripts/makefile.solaris-x86 libpng/libpng-1.2.42.txt libpng/libpng-1.2.44.txt libpng/contrib/pngminim/preader/makefile libpng/scripts/makefile.solaris libpng/pngwtran.c libpng/contrib/pngminim/preader/gather.sh libpng/scripts/makefile.mingw libpng/scripts/makefile.aix libpng/scripts/makefile.hp64 libpng/scripts/png32ce.def libpng/scripts/makefile.beos libpng/scripts/makefile.ne12bsd libpng/pngread.c libpng/scripts/pngw32.def libpng/pngget.c libpng/INSTALL libpng/scripts/makefile.cegcc libpng/CHANGES libpng/contrib/pngminim/encoder/makefile libpng/libpng.3 libpng/projects/wince.txt libpng/example.c libpng/scripts/makefile.so9 libpng/pngwrite.c libpng/pngconf.h libpng/pngset.c libpng/LICENSE libpng/png.5 libpng/pngwutil.c libpng/scripts/makefile.openbsd libpng/scripts/makefile.dec libpng/scripts/README.txt libpng/scripts/makefile.cygwin libpng/pngtest.c libpng/ANNOUNCE libpng/scripts/libpng.pc.in]

2010-06-29T05:25:07.282125Z Hin-Tak Leung

>     change documentation as --enable-dynamics is no longer required
>     for "make so" to work

> [doc/Make.htm]

2010-06-29T05:20:09.043972Z Hin-Tak Leung

>     split lcms code build into arch-specific targets; try to make both windows
>     inline assembly and unix "make so" work simultaneously; bug 691427

> [base/watclib.mak base/lib.mak base/bcwin32.mak base/openvms.mak base/ugcclib.mak base/macosx.mak base/watcw32.mak base/Makefile.in base/unix-gcc.mak base/unixansi.mak psi/msvc32.mak base/macos-mcp.mak base/msvclib.mak]

2010-06-29T05:16:38.524502Z Hin-Tak Leung

>     move the DYNAMIC_* defines out of the --enable-dynamic condition so that it
>     applies generally; try to "make so" work with just
>     ./configure ; many bugs ask for make so to work

> [base/configure.ac]

2010-06-29T04:34:10.440639Z Hin-Tak Leung

>     switch autoconf png test away from testing for a soon-to-be-obsolete routine
>     to one we actually use, to smooth over the libpng 1.2.x to 1.4.x
>     transition; bug 691111

> [jbig2dec/configure.ac base/configure.ac]

2010-06-29T04:15:47.742872Z Hin-Tak Leung

>     make --disable-fontconfig imples --disable-cairo; bug 690690

> [base/configure.ac]

2010-06-29T04:04:53.158322Z Hin-Tak Leung

>     tries to remove empty *obj/*bin directories when invoking "make distclean"; bug 690871

> [base/unix-end.mak base/Makefile.in base/unix-dll.mak base/unix-gcc.mak base/unixansi.mak]

2010-06-29T03:48:17.519902Z Hin-Tak Leung

>     check for GNU sed and switch to alternative sed options if sed is non-GNU; bug 691292

> [cups/pstopxl.in base/configure.ac]

2010-06-29T03:44:30.895095Z Hin-Tak Leung

>     Part 2 of update (new files) posted to 687983, corrected for current svn HEAD.

> [contrib/pscolor/black.pdf contrib/pscolor/color.pdf contrib/pscolor/colorsplit.vcproj contrib/pscolor/black.ps contrib/pscolor/color.ps contrib/pscolor/common.mak contrib/pscolor/input.ps contrib/pscolor/windows.mak]

2010-06-29T03:41:18.718227Z Hin-Tak Leung

>     Part 1 of the update (modifications to checked-in files)
>     to the pscolor code posted in 687983, corrected for current svn head.

> [contrib/pscolor/Makefile contrib/pscolor/test.c contrib/pscolor/instream.yy]

2010-06-29T03:38:46.508455Z Hin-Tak Leung

>     ijs communication should be all binary; left-over uncommitted patch from past ijs-related work

> [ijs/ijs_server_example.c]

2010-06-29T03:34:45.878285Z Hin-Tak Leung

>     implements ./configure --with-ufst=UFST_ROOT_DIR ; bug 691293

> [doc/Make.htm base/Makefile.in base/configure.ac]

2010-06-29T02:32:38.254860Z Michael Vrhel

>     Removal of static prototype that has no function.

> [base/gsicc_cache.c]

2010-06-29T00:50:32.521441Z Michael Vrhel

>     Fix lack of end-of-line in file.

> [base/gsicc_littlecms.c]

2010-06-28T15:04:31.998704Z Henry Stiles

>     Fix a typo, thanks to Ken for spotting this in review.

> [base/gxpcmap.c]

2010-06-28T10:50:53.201708Z Michael Vrhel

>     Warnings of problems within lcms only occur now in debug mode.  Fix for Bug 691401

> [base/gsicc_littlecms.c]

2010-06-28T05:16:59.820980Z Michael Vrhel

>     Interface with lcms so that the memory allocators make use of ghostscript's
>     allocator.  This required fixing a few bugs in littlecms where he was using
>     free instead of _cmsFree and also having lcms.h provide the prototypes if the
>     external mem alloc is defined.  Performed cluster push with no problem.  Thanks
>     to Henry for helping me track down a 64 bit issue.

> [lcms/include/lcms.h base/lib.mak lcms/src/cmslut.c base/lcms.mak lcms/src/cmsio1.c base/gsicc_littlecms.c]

2010-06-26T20:06:13.718954Z Henry Stiles

>     The ad hoc gstate setup for patterns should not call grestore after
>     gsave when erasing colored patterns because it results in
>     "wraparound", creating another gstate (no saved gstate exists when the
>     pattern is painted), see gsstate.c:gs_grestore() vs
>     gsstate.c:gs_grestore_only().  Thanks to Ken Sharp for noticing the the
>     extra gstate.  No expected differences.

> [base/gxpcmap.c]

2010-06-26T17:59:06.494303Z Henry Stiles

>     This file should have been checked in with revision 11433 which will
>     not compile without this change.

> [base/gdevpxat.h]

2010-06-25T12:00:50.643763Z Chris Liddell

>     Provide more robust behaviour when FT fails to render a glyph. Inistead
>     of silently continuing when FT errors on a glyph, we'll now attempt to use
>     the notdef, if the notdef triggers an error, we signal the error to the GS
>     world. This ensures that any time we expect processing to continue there is
>     valid glyph information available to the cache and other downstream devices.
>     This causes one regression difference with 34_all.PS, where an extra TTF
>     notdef is rendered.

>     Bug 691416

> [psi/fapi_ft.c]

2010-06-24T07:11:11.011423Z Ken Sharp

>     Remove a couple of currently unused variables to silence a harmless compiler warning.

> [base/gdevpsft.c]

2010-06-23T17:14:40.891928Z Alex Cherepanov

>     Simplify and fix the implementation of operator --mul--, which mishandled
>     some cases like "16#80000000 -1 mul". Bug 691412.

> [psi/zarith.c]

2010-06-23T15:56:39.786311Z Ken Sharp

>     This patch adds limited support for TrueType collection fonts to pdfwrite and ps2write.

>     In the PostScript world TTC fonts are never passed down to pdfwrite, we only ever see
>     TrueType fonts. XPS, however, can pass back TrueType collection SNFTS data. This patch
>     uses the first font from the TrueType collection and writes that to the output file.
>     This may be too limited and may require further work in future.

> [base/gdevpsft.c]

2010-06-23T14:33:08.852324Z Michael Vrhel

>     Fix for bug691415.  When equivalent ICC profile is already created we
>     should just use it.  Thanks to Ken for getting the details together.

> [base/gscsepr.c]

2010-06-23T05:02:13.734047Z Michael Vrhel

>     Fix for 691359. Problem tracked down by Alex.

>     What lcms is trying to do is to figure out the best prelinearization
>     for the incoming data prior to doing the CLUT interpolation.  In the
>     case when the input is RGB based and the output Gray, lcms was using
>     uninitialized data in constructing is prelinearization.
>     Tangentially related, there could still be problems with what lcms is
>     doing here if the number of Input channels is 1 and the number of Output
>     channels is 3.  In that case, it is possible (but not likely) that I could
>     have radically different gamma behavior in each of the RGB channels.  Trans
>     in such a case would be constructed based upon only one curve based on the
>     red channel.   In the real world, this is probably not a problem but ideally
>     it would be optimal to use something that provides the best prelinearization
>     in all three channels.  That is an optimization for Marti to do and perhaps
>     is already in lcms2.

> [lcms/src/cmsgmt.c]

2010-06-22T14:54:59.999510Z Henry Stiles

>     Erase patterns with the color white instead of filling the pattern
>     bitmap with 0 or 255.

>     Previously the initialization was only used when anti aliasing was
>     enabled, now initial erasing is done for all colored patterns,
>     eliminating a long standing UMR in the pcl code where the pattern was
>     combined with the destination/source with indeterminate results.  The
>     UMR manifested in frequent regression reports in the pcl tests
>     (c321.bin for example), these reports should go away with this change,
>     though (NB) the change only masks the underlying issue.

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

2010-06-22T06:12:54.377174Z Masaki Ushizaka

>     Fix for bug 689836 and 691248.

>     Bug 689836 - Huffman tables with only positive values are decoded incorrectly
>     Bug 691248 - jbig2dec doesn't handle 042_11 (Huffman Symbol Region)

>     This patch fixes mulfunctions seen on standard huffman table K, L, M and N.
>     A difference will be seen on tests_private/comparefiles/Bug690360.pdf.
>     This file was affected by table K mulfunction and this is a improvement.

> [jbig2dec/jbig2_hufftab.h]

2010-06-22T06:00:12.605983Z Alex Cherepanov

>     Revert rev. 7964 and use a different approach: allocate all structures
>     and proceed with their initialization only if all allocations were
>     successful. Fix memory corruption that happens at the PostScript
>     stack overflow. Bug 691295.

> [psi/idosave.h psi/ialloc.c psi/isave.c]

2010-06-22T05:59:23.952778Z Masaki Ushizaka

>     Added test code for every line of each standard huffman tables.

> [jbig2dec/jbig2_huffman.c]

2010-06-22T05:15:53.089456Z Alex Cherepanov

>     Add a /.notdef entry to /CharStrings dictionary if it's missing from an
>     embedded Type1 font. Bug 691406, customer 130.

> [Resource/Init/pdf_font.ps]

2010-06-21T16:41:55.147464Z Michael Vrhel

>     Removal of improper error message.  Source of a potential access violation.

> [base/gsicc_manage.c]

2010-06-21T15:07:03.992218Z Ken Sharp

>     Add the 'gs_error_Remap_Color' pseudo-error, a duplicate -f e_Remap_Color in the
>     PostScript interpreter, to the 'base' error list so that PDL clients other than
>     PostScript can make use of it for high-level pattern support.

> [base/gserrors.h]

2010-06-21T01:14:18.832712Z Hin-Tak Leung

>     auto-detect host as *BSD and use a differently named obj directory;
>     no effect on non-*BSDs. fixes bug 687214

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

2010-06-21T00:32:43.898825Z Hin-Tak Leung

>     adding more borland-related build tips; part of borland build fixes (bug 691400)

> [doc/Make.htm]

2010-06-21T00:12:42.541103Z Hin-Tak Leung

>     got some garbage in the beginning of the file introduced in an earlier commit

> [doc/Install.htm]

2010-06-21T00:01:12.712437Z Hin-Tak Leung

>     nsis-based installer script, makefile adaptation, documentation update; bug 691363

> [psi/winint.mak doc/Release.htm psi/nsisinst.nsi doc/Install.htm]

2010-06-20T23:38:47.757390Z Hin-Tak Leung

>     borland build fix (bug 691400): borland defines P_tmpdir but not
>     _P_tmpdir; similiar difference between borlandc and msvc has been
>     seen with setmode/_setmode in the ijs code in ijs/ijs_server.c

> [jasper/src/libjasper/base/jas_stream.c]

2010-06-20T23:32:24.162240Z Hin-Tak Leung

>     borland build fix (bug 691400): update and complete documentation on
>     working around for too-many-warnings-equal-error problem of borland c++

> [doc/Make.htm]

2010-06-20T23:29:34.775566Z Hin-Tak Leung

>     borland fix (bug 691400): Borland c++ does not support c99 LL nor
>     ULL, but use i64/ui64 like MSVC for 64-bit integer literals

> [base/sha2.c]

2010-06-20T23:11:37.618908Z Hin-Tak Leung

>     4 borland build fixes (bug 691400):

>     - hook up libtiff
>     - build mkromfs
>     - build import library *.lib corresponding to the dll
>     - build the split-out make_filelist (see also r11388 for Bug 691302,
>     which does it for msvc)

> [base/bcwin32.mak]

2010-06-20T23:03:49.551572Z Hin-Tak Leung

>     borland build does not create the obj and bin directories. part of borland build fix (691400)

> [base/bcwin32.mak]

2010-06-20T22:57:32.647408Z Hin-Tak Leung

>     defines a unix target, since win32 requires specific compiler flags;
>     HP-UX make/MS nmake both issues a warning and borland make issues an
>     error for duplicate targets; fixes bug 691337, and also part of the
>     problems with borland build (bug 691400)

> [base/libtiff.mak]

2010-06-20T03:45:03.823204Z Alex Cherepanov

>     Fix malformed ICC profile generation on big endian systems, which was caused
>     by confusion between internal and external representation of an integer.

> [base/gsicc_create.c]

2010-06-20T03:01:50.289956Z Alex Cherepanov

>     Don't leave wild bytes at the end of a generated ICC profile. Fix Valgrind
>     warnings and spurious hash value differences.

> [base/gsicc_create.c]

2010-06-18T23:59:23.662717Z Michael Vrhel

>     Fix so that when the CIE color spaces are released, the icc equivalent
>     space is also rc decremented as is the profile.

> [base/gscscie.c]

2010-06-18T18:06:59.517404Z Michael Vrhel

>     Fix for memory leak in creation of icc profile from def(g) objects.

> [base/gsicc_create.c]

2010-06-18T02:00:13.716745Z Alex Cherepanov

>     Use operator --search-- instead of --token-- during PDF rebuilding
>     to reduce the load on the name table, slightly improve the speed, and
>     work around the bug 691005 in a few cases.

> [Resource/Init/pdf_rbld.ps]

2010-06-17T20:23:33.279930Z Hin-Tak Leung

>     adjust self-reference of bswin32.mak to correct location.
>     Part 1 of fix to bug 691400

> [base/bcwin32.mak]

2010-06-17T20:03:30.325885Z Hin-Tak Leung

>     mentioning -P-/-P and further reference to the INITIALIZATION FILES and
>     Use.htm in the man page. bug 691350

> [man/gs.1]

2010-06-17T19:46:05.887718Z Michael Vrhel

>     add missing type def for gsicc_create_mashed_clut

> [base/gsicc_create.c]

2010-06-17T19:38:39.362075Z Hin-Tak Leung

>     split make_filelist functionality out of setupgs, to allow UAC restriction
>     during packaging of the installer. Bug 691302

> [psi/dwsetup.cpp psi/winint.mak psi/msvc32.mak psi/mkfilelt.cpp]

2010-06-17T19:31:28.160475Z Hin-Tak Leung

>     add info about silent batch installation; bug 691268

> [doc/Install.htm]

2010-06-17T19:28:20.229863Z Michael Vrhel

>     rc_decrement any icc objects that may exist in the imager state that was
>     created for handling the conversion from PS CIE objects to ICC profiles.

> [base/gscie.c]

2010-06-17T18:04:35.295987Z Michael Vrhel

>     Free up tag list when done creating icc profile from PDF cal type.

> [base/gsicc_create.c]

2010-06-17T17:13:34.616951Z Michael Vrhel

>     Change to help track down any memory leaks related to the new icc code.
>     Also fix so that gs_init_iccmanager copies the null character from the default
>     profile string names.  There was a mismatch between what happened here and what
>     happens when the default user params are set.  This was causing the profiles to
>     reset in the manager when they did not need to be.

> [base/gsicc_manage.c]

2010-06-17T09:20:18.689467Z Ken Sharp

>     Fix (FAPI) move two FAPI related members from the show enumerator structure to the text
>     enumerator structure. This ensures that these members are always available for rendering
>     and eliminates a GPF caused when a device's text_begin method returns a text enumerator
>     rather than the show enumerator returned by gx_default_text_begin.

>     No differences expected.

> [base/gxchar.h base/gxtext.h]

2010-06-16T06:11:25.298134Z Hin-Tak Leung

>     a few more CRLF eol and svn property corrections

> [zlib/contrib/dotzlib/LICENSE_1_0.txt zlib/contrib/vstudio/readme.txt zlib/contrib/masmx64/readme.txt base/gsicc_cache.h base/gsicc_manage.c base/gsicc_manage.h zlib/projects/visualc6/README.txt zlib/contrib/dotzlib/readme.txt]

2010-06-15T17:17:15.944441Z Michael Vrhel

>     Rename of a few functions to match documentation, update of gdevwts.c to
>     use new color architecture, addition of minor utility functions for use in gxps.
>     This should not generate regressions.

> [base/lib.mak base/gsicc_littlecms.h base/gsicc_cache.h base/gsicc_manage.c base/gscms.h base/gdevwts.c base/gsicc_manage.h base/gsicc_littlecms.c]

2010-06-15T16:54:40.171304Z Michael Vrhel

>     Update of Color Architecture document in preparation for release of GS 9.0

> [doc/Color_Architecture.tex doc/figures/XPS_Integer_Gray_RGB_Image.eps doc/figures/Overview.eps doc/figures/XPS_DeviceN.eps doc/figures/PDF_Render.eps doc/figures/XPS_Render.eps doc/GS9_Color_Management.pdf doc/figures/XPS_Vector_Color.eps doc/figures/XPS_RGB_Image_Float.eps doc/figures/PS_Spec.eps doc/Color_Architecture.pdf doc/GS9_Color_Management.tex doc/figures/PS_Render.eps doc/figures/PDF_Spec.eps]

2010-06-14T23:10:27.633844Z Henry Stiles

>     Modified line endings from CRLF -> LF and propset to native.

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

2010-06-14T18:42:47.881614Z Alex Cherepanov

>     Fix yet another case where memcpy() copies a memory block on itself.
>     This doesn't cause any problems on Linux or Windows but violates the
>     spec and irks Valgrind. Bug 691394.

> [base/gsline.c]

2010-06-14T18:07:49.834071Z Chris Liddell

>     Remove the "<font> is being rendered with FAPI=<renderer>"
>     messages. But leave a warning if we fall back to the old GS renderer.

> [Resource/Init/gs_fapi.ps]

2010-06-14T11:19:07.131026Z Ken Sharp

>     Fix (pdfwrite) : limit composite object sizes when producing PDF/A

>     Bug #691370 "Dictionary size not limited for PDF/A-1"

>     The PDF/A specification insists that the implementation limitations of Acrobat as
>     defined in PDF 1.4 should be followed when producing PDF/A files. Accordingly this
>     limits the size of dictionaries to 4095 and arrays to 8191 when producing PDF/A output.

>     Since there is no way to ignore the problem, setting the PDFACompatibiltyPolicy to 1
>     'don't emit the object, carry on producing PDF/A' can't be made to work. Since the
>     user has expressed a desire for an output file, we fall back to Policy 0 'Produce a
>     regular PDF file' instead.

>     Also extend PDFACompatibilityPolicy to include policy 2 'abort'.

>     No test file for this case, no differences expected.

> [base/gdevpdfo.c]

2010-06-14T11:14:18.794921Z Ken Sharp

>     Extend to PDF/X emission the enhancement in revision 11369 which prevents emitting
>     invalid PDF/A files when glyphs are missing from fonts.

> [base/gdevpdte.c]

2010-06-14T11:12:40.380849Z Ken Sharp

>     Update the ps2pdf documenataion to reflect the fact that PDF/X-3 conversion now also
>     uses the PDFACompatibilityPolicy to control behaviour when a conforming file cannot be
>     produced.

>     Also applied some general grammatical correction to the text.

> [doc/Ps2pdf.htm]

2010-06-14T09:34:17.990404Z Ken Sharp

>     Fix (pdfwrite) : Don't emit invalid PDF/A files

>     Bug #691383 "pdfwrite emits invalid PDF/A when glyphs are missing in the input font."

>     If the input file references glyphs which are not in the font, then we could emit a
>     PDF/A file which also referenced glyph which were not present in the fonts embedded
>     in the PDF file.

>     This patch uses the PDFACompatibilityPolicy to control the action in this case, and
>     avoid emitting invalid PDF/A files.

>     Also extended the functionality of the PDFACompatibilityPolicy to allow the user to
>     abort PDF file production when a valid PDF/A file cannot be produced.

>     No expected differences as PDF/A production is not tested by regression code.

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

2010-06-12T15:19:56.267658Z Henry Stiles

>     The ICC profile file name buffer was too small to accommodate the
>     trailing null appended by strcat resulting in an invalid write to
>     memory.

> [base/gsicc_manage.c]

2010-06-11T17:24:06.899434Z Chris Liddell

>     In the event of a FreeType error when scaling a font face, don't clean
>     up the FT data, but leave it to the garbage collector
>     to call the font object's "finalize" function, which will then
>     clean up the FT data.
>     Secondly, add code to deal with very low resolutions underflowing some of FT's
>     fixed point code (similar to code for small scale factors).
>     Bug 691381

> [psi/fapi_ft.c]

2010-06-11T07:53:37.156852Z Ken Sharp

>     Fix pdfwrite - device reference counting problem with patterns and XPS

>     When using XPS as the input PDL, and pdfwrite as the output device, the pdfwrite device
>     was counted up by pattern accumulator allocation, but the clist accumulator never
>     counted the device down, leading to a reference count > 1 at EOJ. This meant that
>     the pdfwrite device wasn't closed, since pdfwrite only emits the PDF file when it is
>     closed this led to invalid unfinished PDF files.

>     The code here modifies the behaviour of the pattern management so that we don't use the
>     'clist' path for accumulating patterns *if* the device can accumulate patterns itself
>     *and* the PDL doesn't have_pattern_streams (to avoid pathological PDF file problems)

>     This resolves the issue with device reference counts and all the FTS XPS files now
>     produce complete PDF files.

> [base/gxpcmap.c]

2010-06-10T16:11:08.241878Z Chris Liddell

>     When extracting a path from the FAPI world (for a charpath, for example),
>     only close the path if it has been "opened".
>     This prevents empty paths from non-marking glyphs resulting in a point being
>     rendered on the page.
>     Another part of Bug 691252.
>     This change causes ~195 differences to be reported on the cluster, but they
>     are all progressions.

> [psi/zfapi.c]

2010-06-10T14:06:40.549557Z Chris Liddell

>     Make the rendering of the Truetype notdef glyph optional with the FAPI interface
>     (as per the previous behaviour).
>     A few cluster differences are expected as we have test files which use the TTF notdef,
>     I have checked all the differences, and they are correct.
>     This is part of Bug 691252

> [psi/zfapi.c]

2010-06-09T18:59:09.419344Z Robin Watts

>     Update comparerevs.pl script so that it no longer ignores hash values
>     on files taht have a non-zero error return. It now only ignores hash
>     values on timeouts (because runs can easily produce different numbers of
>     pages on each run).

>     Also, the output is updated to show error values together with hash results.
>     Error values are now always in brackets, on a red background.

> [toolbin/localcluster/comparerevs.pl]

2010-06-08T16:20:39.058317Z Chris Liddell

>     In bytes_copy_rectangle() clamp the length of each row to be copied to the
>     stride of the raster. This takes care of problems copying bitmaps from FT
>     (or potentially other font libraries) which use different alignment to
>     the "internal" rasters. Bug 691328.

> [base/gsbitops.c]

2010-06-08T01:04:10.677952Z Alex Cherepanov

>     Check whether the font has /Encoding before trying to use it. Recent FAPI
>     changes give /BuildChar procedure to all fonts including CIDFont resources.
>     So the check for non-null pfdata->BuildChar no longer guaranteed that the
>     font has /Encoding. Bug 691311.

> [psi/zchar.c]

2010-06-07T17:14:20.171809Z Michael Vrhel

>     Fix for Bug 691368.

>     lcms appears not to check its handles of link transforms when a profile is
>     released, to clear out xform->InputProfile.  Probably due to the fact that
>     lcms may not expect a change of the formatters after the link is created.
>     That would imply that we would need to create links based upon data types,
>     which is not so efficient.  Disable this check in lcms since it is only related
>     to named color profiles, which we will not run into.  Will kick this up to Marti.

> [lcms/src/cmspack.c]

2010-06-06T18:00:36.332831Z Michael Vrhel

>     Fix for Bug 691367.  Seg fault should no longer occur.  If an attempt is
>     made to set a color space in the graphic state and the ICC manager's
>     profiles have not yet been initialized, it will be taken care of.

> [base/gsicc_manage.c base/gscspace.c]

2010-06-05T20:03:55.912155Z Alex Cherepanov

>     Don't copy memory block into itself; clear a Valgrind warning.

> [base/gsdparam.c]

2010-06-05T19:20:40.615579Z Michael Vrhel

>     Fix for indeterminisms in some PS files where the alternate tint transform
>     color space for a DeviceN or Separation color space is CIE based.  Previously
>     we were  returning either CMYK, or RGB based based upon the channel count for
>     the CIE space.  Now we are returning an equivalent ICC based color space.  Also
>     minor fix for uninitialized memory in generated profile.

> [base/gscdevn.c base/gsicc_create.c base/gscsepr.c]

2010-06-03T16:57:17.441589Z Hin-Tak Leung

>     observe minst->search_here_first condition in file search; bug 691350

> [psi/zfile.c]

2010-06-03T00:32:07.629281Z Hin-Tak Leung

>     Adding -P- and -dSAFER to many POSIX shell scripts, win32 and OS/2 batch scripts; bug 691355

> [lib/bjc610b4.upp lib/bjc610b6.upp lib/lp386.bat lib/bjc610b7.upp lib/bjc610b8.upp lib/gsndt.bat lib/pdf2dsc lib/eps2eps.bat lib/st640plg.upp lib/ras8m.upp lib/ras24.upp lib/pv.sh lib/bj8oh06n.upp lib/necp2x.upp lib/stc600p.upp lib/pfbtopfa.bat lib/stc640p.upp lib/wftopfa lib/ps2ps lib/stc2s_h.upp lib/stc500ph.upp lib/ps2ps.cmd lib/pphs lib/stcany_h.upp lib/pf2afm lib/gsdj500 lib/dnj750c.upp lib/pf2afm.cmd lib/stc600pl.upp lib/stc800pl.upp lib/gsbj lib/ps2epsi lib/ps2epsi.cmd lib/dnj750m.upp lib/dumphint lib/gsnd lib/font2c lib/gsdj.bat lib/pdfopt lib/ras32.upp lib/ps2ps2.bat lib/pdf2ps lib/ps2pdf.cmd lib/pdf2ps.cmd lib/stc500p.upp lib/cdj690.upp lib/stc600ih.upp lib/st640p.upp lib/stc_h.upp lib/gslj.bat lib/stcany.upp lib/stc800ih.upp lib/bdftops.bat lib/stc_l.upp lib/ras1.upp lib/gslp.bat lib/lpgs.bat lib/st640ihg.upp lib/ras3.upp lib/stc1520h.upp lib/ras4.upp lib/stc300.upp lib/bj8ts06n.upp lib/eps2eps lib/ps2ascii.bat lib/eps2eps.cmd lib/stc2_h.upp lib/pdf2dsc.bat lib/stc.upp lib/stc300bl.upp lib/stc300bm.upp lib/bj8pp12f.upp lib/pfbtopfa lib/stc800p.upp lib/bjc610a0.upp lib/bj8gc12f.upp lib/st640pg.upp lib/bjc610a1.upp lib/cdj690ec.upp lib/bjc610a2.upp lib/ps2ps.bat lib/bjc610a3.upp lib/bjc610a4.upp lib/bjc610a5.upp lib/bj8hg12f.upp lib/stc2.upp lib/st640pl.upp lib/bjc610a6.upp lib/printafm lib/bjc610a7.upp lib/pf2afm.bat lib/gsdj500.bat lib/bjc610a8.upp lib/ps2pdfxx.bat lib/lpr2.bat lib/lp386r2.bat lib/stc200_h.upp lib/unix-lpr.sh lib/gsdj lib/necp2x6.upp lib/ps2ps2 lib/ps2epsi.bat lib/gsbj.bat lib/bj8pa06n.upp lib/ps2ps2.cmd lib/dumphint.bat lib/cdj550.upp lib/gslj lib/gsnd.bat lib/font2c.bat lib/bdftops lib/pdfopt.bat lib/pdf2ps.bat lib/st640ih.upp lib/gslp lib/ps2pdfwr lib/bjc610b1.upp lib/bjc610b2.upp lib/dvipdf lib/ps2ascii lib/bjc610b3.upp lib/pftogsf.bat]

2010-06-02T17:45:39.111970Z Robin Watts

>     Introduce new ENABLE_TRAP_AMALGAMATION build define. If set at build time
>     then code is introduced to gxfillts.h to try to amalgamate some of the
>     rectangles produced into the surrounding trapezoids.

>     This can cause small rendering differences due to the difference in rounding
>     within scan conversion and trap extraction.

>     The option is disabled by default.

>     No expected differences with it disabled. 439 non pdfwrite differences, 99
>     differences with it enabled.

> [base/gxfillts.h]

2010-06-02T08:37:07.985901Z Ken Sharp

>     Revision 11348 accidentally included a number of font definitions in an updated cidfmap,
>     This removes those definitions, which should not be present.

> [Resource/Init/cidfmap]

2010-06-02T08:29:23.801870Z Ken Sharp

>     Documentation change
>     Updated the comments at the head of the file to make it plain that the entries in the
>     CSI array must be strings, not names. Although this is clearly documented in use.htm
>     we have recently had several reports in which users have been trying to set name values
>     in the array.

>     Also added a pointer to the documentation as a further hint.

> [Resource/Init/cidfmap]

2010-06-02T07:46:57.542525Z Ken Sharp

>     Fix pdfwrite, faulty matrix transformations for Shading dictionaries

>     Bug #691352 "cairo pdf mis-distilled"

>     Patterns in PDF are unpleasantly complicated by the need to transform the pattern to
>     the 'default co-ordinate space'. Normally this means that we undo the resolution scaling
>     which is normally applied to the CTM.

>     For page streams this works well, but for forms the 'default co-ordinate space' is
>     the space of the parent. For one level of form there is therefore no difference between
>     the page and the form. When forms are nested however, the lower form's space becomes
>     that of the parent. This means that patterns inside forms, which are nested inside
>     another form, need to be transformed to the parent form co-ordinate space, not the
>     page space.

>     Since we don't currently emit forms from pdfwrite for anything except transparency
>     groups what this means in practice is that we don't undo the CTM transformation if
>     we are rendering a pattern inside a form, nested inside at least one other form.

> [base/gdevpdfx.h base/gdevpdft.c base/gdevpdfv.c base/gdevpdfb.h]

2010-06-01T17:41:20.224359Z Michael Vrhel

>     Rename of gsicccache.c/h to gsicc_cache.c/h  and gsiccmanage.c/h to
>     gsicc_manage.c/h to fall in line with the name space of the other files
>     that came from the icc branch.  Currently working on the documentation
>     and it is clear that this is needed (and I wish I had done it earlier).

> [/trunk/ghostpdl/pxl/pxpthr.c /trunk/ghostpdl/pxl/pxl.mak /trunk/ghostpdl/xps/ghostxps.h base/gsiccmanage.c base/gxshade1.c base/gsiccmanage.h base/gscsepr.c base/gxshade4.c base/gxshade6.c /trunk/ghostpdl/pxl/pxtop.c base/gxcmap.c ghostscript.vcproj base/gsistate.c /trunk/ghostpdl/pcl/pcl.mak base/gdevrinkj.c base/gdevwts.c base/gdevxcf.c base/gxicolor.c base/devs.mak base/gsicc.c base/gdevimdi.c base/gscdevn.c base/gxclread.c base/gdevpsd.c base/lib.mak base/gxiscale.c base/gsicc_manage.c psi/int.mak /trunk/ghostpdl/pxl/pxgstate.c /trunk/ghostpdl/pcl/pctop.c base/gsicc_manage.h psi/zicc.c psi/zdevice.c base/gdevp14.c base/gsstate.c base/gsicc_cache.c base/gsicc_create.c psi/zcie.c base/gsicccache.c base/gxclist.c base/gsicc_cache.h base/gsicccache.h base/gstrans.c base/gscms.h base/gxidata.c base/gdevpdfc.c base/gxblend.c base/gxshade.c psi/zusparam.c base/gdevpdfg.c base/gxp1fill.c base/gxclrast.c base/gsciemap.c]

2010-05-31T14:49:14.514014Z Hin-Tak Leung

>     for "ln -s base/unix-gcc.mak Makefile; make" builds, do
>     not modularize X, nor build most of the modularzed linux modules,
>     since they depend on the linux GNU linker

> [base/unix-gcc.mak]

2010-05-31T14:41:08.956692Z Hin-Tak Leung

>     another attempt to make "ln -s base/unix-gcc.mak Makefile; make"
>     to work; libtiff really want configure so we hook it in

> [base/libtiff.mak]

2010-05-31T09:58:14.532526Z Hin-Tak Leung

>     more icc branch merge related change to make
>     "make -f base/unix-gcc.mak" and other targets work"

> [base/unix-gcc.mak base/unixansi.mak]

2010-05-28T18:07:08.826907Z Henry Stiles

>     Fixes bug #690793.  PJL Formlines was not set correctly if the paper
>     size changed.  Also, refactors such that PXL and PJL get paper sizes
>     from the same source table.

> [/trunk/ghostpdl/pl/pl.mak /trunk/ghostpdl/pxl/pxl.mak /trunk/ghostpdl/pl/pjparse.c /trunk/ghostpdl/pxl/pxsessio.c /trunk/ghostpdl/pxl/pxstate.h base/gdevpxen.h base/gdevpxut.c]

2010-05-27T21:02:21.460781Z Michael Vrhel

>     Fix so that shading strokes that go through the clist transparency code
>     communicate the transparency device so that the proper color information
>     is used as opposed to the color information related to the final target
>     device.  This should fix the indeterminism with bug688807.pdf when going
>     out to a monochrome device.

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

2010-05-27T15:30:01.093150Z Henry Stiles

>     Forward declarations for statics functions were accidentally placed in
>     the header file instead of the c file.

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

2010-05-27T00:44:57.701730Z Michael Vrhel

>     Fix for indeterminism when using psdcmyk device and interpolated images.
>     For cases where the device profile has fewer components than the actual
>     number of device colorants we need to use the slower interpolation code.
>     Otherwise we end up encoding uninitialized memory.

> [base/gxiscale.c]

2010-05-26T22:01:50.106123Z Michael Vrhel

>     Fix for bug690218.   For clist reader the pdf14 device was getting its color
>     information set based upon the number of spot colorants in the page.  The real
>     number should be based upon the number of actual components the device is capable
>     of handling.  This occurs when using separation device with a limited set of
>     colorants invoked via a command like
>     -c "<< /SeparationColorNames [ /Cyan /Magenta /Yellow /Black ]

>     /SeparationOrder [ /Cyan /Magenta /Yellow /Black ] >> setpagedevice"

> [base/gdevp14.c]

2010-05-26T18:16:52.113331Z Michael Vrhel

>     Improvements and fixes in icc search path description and bolder alert with
>     respect to Windows delimiter \" interpretation . Thanks to Ray.

> [doc/Use.htm]

2010-05-26T16:08:36.881438Z Henry Stiles

>     The languages (pcl, xps, pclxl) debug builds were broken with the icc
>     branch merge, gs_abort() is not supported.  The code has been changed
>     similarly to the old exit upon failed assertion code in gsalloc.c
>     where gs_abort() is replaced with return, fixes bug #691340.

> [base/gsicc_profilecache.c]

2010-05-26T03:07:02.463936Z Michael Vrhel

>     Addition of lcms and new icc files to Visual studio solution.  Also did a
>     little organizing of the files in the explorer window base folder.

> [ghostscript.vcproj]

2010-05-25T20:43:02.039929Z Michael Vrhel

>     Update of documentation, clarifying the search methods used for finding the icc profiles.

> [doc/Use.htm]

2010-05-25T19:38:23.177347Z Michael Vrhel

>     Removal of iccprofiles/ from default icc profile names and post-pend %rom%
>     with iccprofiles/ .  This is in preparation for having the ps init code
>     initialize a default value for ICCProfilesDir (which will be ./iccprofiles/ )
>     so that code works with COMPILE_INITS=0 when not in the base directory and
>     when -sICCProfilesDir is not specified on the command line.

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

2010-05-25T17:15:59.119523Z Hin-Tak Leung

>     make static some private functions to remove compiler warnings

> [contrib/gdevgdi.c base/gdevcairo.c contrib/gdevlx50.c]

2010-05-25T17:14:27.480893Z Hin-Tak Leung

>     make private functions static to silence some missing prototype warning

> [imdi/cgen.c imdi/imdi_k.c]

2010-05-25T17:13:18.238667Z Hin-Tak Leung

>     silent one compiler warning

> [base/gxstroke.c]

2010-05-25T13:50:21.339560Z Ken Sharp

>     Fix copy CIDFontType 2 properly
>     Bug #690930 "Unicode Output: DEVICE=pdfwrite"

>     When making a copy of a CIDFont with TrueType outlines (CIDFontType 2) for the
>     benefit of pdfwrite, do not simply copy the subst_CID_on_WMode structure member as
>     this will be restored away along with the font at end of page. Instead make a new
>     structure and store that in the copied font.

>     No differences expected, local cluster test shows a few but I think (hope) these are
>     related to the ICC branch merge.

> [base/gxfcopy.c]

2010-05-25T10:22:09.642632Z Chris Liddell

>     Bug 691336: Resolve some confusion between the original global variable
>     removal changes, and subsequent changes, that could result in warning emprintf
>     calls using a memory pointer that could not exist at that stage.

> [psi/fapiufst.c]

2010-05-25T08:31:57.775100Z Ken Sharp

>     Silence a couple of gcc compiler warnings introduced with the ICC merge.

> [base/gdevpdfk.c base/gdevpdfc.c]

2010-05-24T23:06:59.017275Z Hin-Tak Leung

>     Another bunch of CRLF to LF's.

>     find . -type f | grep -v 'svn-base' | xargs file | grep CRLF | \
>     grep -v -E '\.(dsp|dsw|sln|rc):' | grep -v -E \
>     '(cbuilder5|masm|dotzlib|vstudio|BorlandC_5.5|visualc6)' | cut -d ':' -f 1 | \
>     xargs -n 1 svn propset svn:eol-style native
>     find . -type f | grep -v 'svn-base' | xargs file | grep CRLF | \
>     grep -v -E '\.(dsp|dsw|sln|rc):' | grep -v -E \
>     '(cbuilder5|masm|dotzlib|vstudio|BorlandC_5.5|visualc6)' | cut -d ':' -f 1 | \
>     xargs dos2unix

> [tiff/nmake.opt psi/zcolor.h toolbin/color/icc_creator/ICC_Creator/stdafx.h lib/cat.ps toolbin/color/icc_creator/ICC_Creator/ICC_CreatorDlg.cpp toolbin/color/icc_creator/example/cielab_values.txt toolbin/color/icc_creator/ICC_Creator/icc34.h contrib/lxm3200-tweaked/LICENSE toolbin/color/icc_creator/README.txt toolbin/color/icc_creator/ICC_Creator/ICC_Creator.cpp toolbin/color/named_color/named_color_table.txt zlib/contrib/testzlib/testzlib.txt lib/Fontmap.URW-136.T1 toolbin/color/icc_creator/example/tritone_names.txt zlib/contrib/testzlib/testzlib.c toolbin/color/icc_creator/ICC_Creator/CIELAB.h toolbin/color/icc_creator/ICC_Creator/icc_create.h base/gsicc_profilecache.c toolbin/color/icc_creator/ICC_Creator/stdafx.cpp toolbin/color/icc_creator/ICC_Creator/resource.h base/gsicc_profilecache.h toolbin/color/icc_creator/example/tritone_cielab.txt base/gsicc_create.c toolbin/color/icc_creator/ICC_Creator/targetver.h toolbin/color/icc_creator/ICC_Creator/ICC_CreatorDlg.h toolbin/color/icc_creator/ICC_Creator/res/ICC_Creator.rc2 psi/zcie.h psi/write_t2.c base/gsicc_create.h toolbin/color/icc_creator/example/color_names.txt base/gscms.h toolbin/color/icc_creator/ICC_Creator/icc_create.cpp toolbin/color/icc_creator/ICC_Creator/ICC_Creator.h psi/fapibstm.c lib/Fontmap.URW-136.TT]

2010-05-24T22:34:00.748368Z Hin-Tak Leung

>     remove some more CR's and more eol-style native.

>     find . -type f   -exec file {} \; |grep 'CRLF' | grep -v '/Projects' | \
>     grep -v 'svn-base' | cut -f 1 -d ':' | xargs -n 1 svn propset \
>     svn:eol-style native
>     find . -type f   -exec file {} \; |grep 'CRLF' | grep -v '/Projects' | \
>     grep -v 'svn-base' | cut -f 1 -d ':' | xargs -n 1 dos2unix

> [lcms/Delphi/delphidemo.dof lcms/src/makefile.simple lcms/Delphi/demo1.pas lcms/python/testbed/srgb2xyz.py lcms/Delphi/Samples/create.pas lcms/python/testbed/srgb2lab.py lcms/Delphi/delphidemo.dpr lcms/python/testbed/cam02.py lcms/makefile.simple lcms/samples/makefile.simple lcms/Delphi/Samples/TEST.PAS lcms/Delphi/delphidemo.cfg lcms/python/testbed/createmsh.py lcms/python/testbed/lab2adobe.py lcms/Delphi/Samples/testfrm.pas lcms/Delphi/Samples/testwp.pas lcms/src/lcms.def lcms/Delphi/Samples/getxyz.pas]

2010-05-24T22:26:37.131050Z Hin-Tak Leung

>     manually fixing the last few files which escaped fileutils' identification.

> [lcms/python/lcms.py lcms/COPYING lcms/src/cmscam97.c lcms/aclocal.m4 lcms/ltmain.sh lcms/README.1ST lcms/configure.ac]

2010-05-24T22:20:52.689626Z Hin-Tak Leung

>     Changes c/c++/shell script/english text to native text and strip off CR.

>     find . -type f   -exec grep -l '\r\n' {} \; | grep -v 'svn-base' | \
>     grep -v '\.vcproj' | grep -v '/Projects' | xargs -n 1 file |  \
>     grep -E '(ASCII C\+\+ program text|ISO\-8859 English text|ASCII \
>     C program text|shell script text executable)' | cut -f 1 -d ':'  |\
>     xargs dos2unix
>     find . -type f   -exec grep -l '\r\n' {} \; | grep -v 'svn-base' | \
>     grep -v '\.vcproj' | grep -v '/Projects' | xargs -n 1 file |  grep -E \
>     '(ASCII C\+\+ program text|ISO\-8859 English text|ASCII C program text|\
>     shell script text executable)' | cut -f 1 -d ':'  | xargs svn propset \
>     svn:eol-style native

> [lcms/doc/TUTORIAL.TXT lcms/matlab/icctrans.c lcms/src/cmswtpnt.c lcms/tifficc/getopt.c lcms/src/cmsgamma.c lcms/src/cmsnamed.c lcms/samples/vprf.c lcms/src/cmserr.c lcms/samples/mkcmy.c lcms/src/cmsmtrx.c lcms/src/cmsxform.c.orig lcms/samples/icc2ps.c lcms/python/lcms_wrap.cxx lcms/tifficc/tiffdiff.c lcms/src/cmssamp.c lcms/samples/xgetopt.c lcms/Delphi/lcmsdll.pas lcms/include/icc34.h.in lcms/src/cmsmatsh.c lcms/src/cmspack.c lcms/jpegicc/jpegicc.c lcms/jpegicc/iccjpeg.c lcms/samples/icctrans.c lcms/testbed/testcms.c lcms/samples/mktiff8.c lcms/jpegicc/iccjpeg.h lcms/tifficc/tifficc.c lcms/src/cmsvirt.c lcms/src/cmspcs.c lcms/samples/icclink.c lcms/src/cmsgmt.c lcms/src/cmsio0.c lcms/src/cmsio1.c lcms/samples/mkgrayer.c lcms/filter.c lcms/python/lcms.i lcms/src/cmsxform.c lcms/src/cmsintrp.c lcms/src/cmscnvrt.c lcms/include/lcms.h lcms/doc/LCMSAPI.TXT lcms/src/cmscgats.c lcms/src/cmscam02.c lcms/include/icc34.h lcms/src/cmslut.c lcms/src/cmsps2.c lcms/samples/wtpt.c lcms/samples/itufax.c]

2010-05-24T22:07:41.207483Z Hin-Tak Leung

>     remove executable bits from files which don't need them.

>     find . -type f -executable  -exec file {} \; \
>     | grep -v 'shell script text executable' \
>     | cut -f 1 -d ':' |xargs -n 1 svn propdel svn:executable

>     The last commit was created by:

>     find . -type f -executable  -exec file {} \; \
>     | grep 'script text executable' \
>     | cut -f 1 -d ':' |xargs -n 1 svn propset svn:eol-style native

> [lcms/Projects/VC6/lcms.rc lcms/Projects/VC7/lcms.rc lcms/bin/Bin.txt lcms/Delphi/Samples/create.pas lcms/samples/vprf.c lcms/configure.ac lcms/README.1ST lcms/lcms.pc.in lcms/Projects/VC2008/lcms.sln lcms/testbed/sRGBSpac.icm lcms/Projects/VC2008/lcms.vcproj lcms/python/testbed/lab2adobe.py lcms/Delphi/demo1.dfm lcms/samples/xgetopt.c lcms/Projects/VC2005/icclink.vcproj lcms/Projects/VC6/icclink.dsp lcms/Projects/VC7/lcms.vcproj lcms/src/cmscam97.c lcms/testbed/testcms.c lcms/Projects/VC6/icc2ps.dsp lcms/Projects/VC7/icctrans.vcproj lcms/python/testbed/srgb2lab.py lcms/Projects/VC7/tifficc.vcproj lcms/filter.c lcms/Projects/VC6/lcms.dsp lcms/Delphi/delphidemo.cfg lcms/Projects/VC7/icc2ps.vcproj lcms/Projects/VC6/lcms.dsw lcms/Delphi/Samples/testwp.pas lcms/Projects/VC7/lcms.sln lcms/Projects/VC2008/tifficc.vcproj lcms/Projects/VC2005/resource.h lcms/python/testbed/whtpnt.py lcms/doc/TUTORIAL.TXT lcms/src/cmswtpnt.c lcms/Projects/VC2005/Python.vcproj lcms/Projects/BorlandC_5.5/mklcmsdll.bat lcms/include/Makefile.am lcms/Projects/VC7/jpegicc.vcproj lcms/install.gcc lcms/samples/wtpt.1 lcms/Projects/BorlandC_5.5/lcmsdll.lk lcms/src/cmserr.c lcms/makefile.simple lcms/Projects/BorlandC_5.5/lcms.rc lcms/samples/mkcmy.c lcms/src/cmsmtrx.c lcms/Makefile.am lcms/python/testbed/sRGB Color Space Profile.icm lcms/Projects/VC2008/jpegicc.vcproj lcms/Projects/VC7/lcmsdll.vcproj lcms/AUTHORS lcms/samples/icc2ps.1 lcms/Projects/VC2008/resource.h lcms/src/makefile.simple lcms/samples/mktiff8.c lcms/python/testbed/virtprf.py lcms/python/testbed/clamp.py lcms/Projects/BorlandC_5.5/lcmsdll.lst lcms/src/cmsvirt.c lcms/src/cmspcs.c lcms/src/cmsio0.c lcms/python/testbed/cam02.py lcms/Projects/VC6/resource.h lcms/src/cmsxform.c lcms/python/lcms.i lcms/src/cmsintrp.c lcms/Projects/VC2008/lcmsdll.vcproj lcms/jpegicc/jpegicc.1 lcms/COPYING lcms/Projects/VC2005/lcms.rc lcms/samples/icctrans.1 lcms/Projects/VC7/tiffdiff.vcproj lcms/src/cmscgats.c lcms/Projects/VC2008/lcms.rc lcms/tifficc/tifficc.1 lcms/src/cmscam02.c lcms/matlab/icctrans.matlab.pdf lcms/python/testbed/createmsh.py lcms/src/cmslut.c lcms/tifficc/Makefile.am lcms/Lib/MS/MS.TXT lcms/samples/wtpt.c lcms/Projects/VC6/tifficc.dsp lcms/Projects/VC7/Testbed.vcproj lcms/python/testbed/gamma.py lcms/samples/itufax.c lcms/python/Makefile.am lcms/Delphi/demo1.pas lcms/src/cmsgamma.c lcms/Projects/VC6/Python.dsp lcms/Projects/VC2008/Python.vcproj lcms/src/cmsnamed.c lcms/src/cmsxform.c.orig lcms/Projects/VC6/lcmsdll.dsp lcms/Projects/VC2008/Testbed.vcproj lcms/Projects/VC2005/lcms.vcproj lcms/python/testbed/AdobeRGB1998.icc lcms/samples/icc2ps.c lcms/tifficc/tiffdiff.c lcms/samples/makefile.simple lcms/Delphi/Samples/TEST.PAS lcms/src/cmssamp.c lcms/NEWS lcms/samples/Makefile.am lcms/Projects/VC2005/icctrans.vcproj lcms/Projects/VC2005/tifficc.vcproj lcms/Delphi/lcmsdll.pas lcms/Projects/VC2008/icctrans.vcproj lcms/include/icc34.h.in lcms/Delphi/delphidemo.dof lcms/Projects/VC6/lcms.opt lcms/src/cmsmatsh.c lcms/src/cmspack.c lcms/Projects/VC6/Python.plg lcms/jpegicc/jpegicc.c lcms/samples/icctrans.c lcms/Delphi/Samples/MAKETEST.BAT lcms/Projects/VC2005/icc2ps.vcproj lcms/ltmain.sh lcms/Delphi/Samples/gamutchk.pas lcms/tifficc/tifficc.c lcms/Projects/VC2005/lcms.sln lcms/src/cmsio1.c lcms/Projects/VC6/Testbed.dsp lcms/INSTALL lcms/Projects/VC7/icclink.vcproj lcms/jpegicc/makefile.simple lcms/jpegicc/Makefile.am lcms/Projects/VC2005/jpegicc.vcproj lcms/samples/icclink.1 lcms/Delphi/Samples/testfrm.pas lcms/Projects/VC6/jpegicc.dsp lcms/Projects/VC6/icctrans.dsp lcms/src/lcms.def lcms/Delphi/demo1.dcu lcms/Delphi/Samples/getxyz.pas lcms/matlab/icctrans.c lcms/ChangeLog lcms/Projects/VC2008/icclink.vcproj lcms/tifficc/getopt.c lcms/Lib/BC/BC.txt lcms/testbed/makefile.simple lcms/Projects/VC6/Testbed.plg lcms/Delphi/delphidemo.dpr lcms/testbed/Makefile.am lcms/Projects/VC2005/lcmsdll.vcproj lcms/Projects/VC7/resource.h lcms/Projects/VC7/Python.vcproj lcms/Delphi/demo1.ddp lcms/python/testbed/cam97.py lcms/jpegicc/iccjpeg.c lcms/python/testbed/constant.py lcms/Projects/VC2005/tiffdiff.vcproj lcms/python/testbed/srgb2xyz.py lcms/python/testbed/info.py lcms/jpegicc/iccjpeg.h lcms/Projects/VC2008/tiffdiff.vcproj lcms/Projects/VC2008/icc2ps.vcproj lcms/src/Makefile.am lcms/samples/icclink.c lcms/src/cmsgmt.c lcms/Projects/VC2005/Testbed.vcproj lcms/samples/mkgrayer.c lcms/include/lcms.h lcms/Delphi/delphidemo.res lcms/src/cmscnvrt.c lcms/python/swig_lcms lcms/doc/LCMSAPI.TXT lcms/python/testbed/sRGB2adobe.py lcms/tifficc/makefile.simple lcms/include/icc34.h lcms/src/cmsps2.c]

2010-05-24T22:02:13.500457Z Hin-Tak Leung

>     make all shell scripts in the lcms directory eol-style native.

> [lcms/depcomp lcms/compile lcms/missing lcms/config.guess lcms/config.sub lcms/install-sh lcms/mkinstalldirs lcms/configure]

2010-05-24T18:36:16.496917Z Alex Cherepanov

>     Add missing EOL to the last line in one of the new ICC files
>     because MSVC 6 requires this.

> [base/gsiccmanage.c]

2010-05-24T16:31:58.315172Z Michael Vrhel

>     Merge of icc_work branch into trunk.
>     These changes make the color architecture of the graphics library ICC-based.
>     All colors are now managed in terms of ICC profiles including PS CIE color
>     spaces, for which equivalent ICC profiles are created.    A big feature of
>     this change is that it makes it very easy to interface a color management
>     module (CMM) to ghostscript.   The default CMM is now littleCMS and the
>     interface to littleCMS is contained in gsicc_littlecms.c .
>     New member variables were added to the imager state including an ICC manager,
>     which stores the default ICC profiles; a link cache, which reduces the cost of
>     creating links between ICC profiles, and a profile cache which stores color
>     spaces created from PS CIE, PDF CalRGB and PDF CalGray colors spaces.
>     A new directory named iccprofiles has been added.  It contains the default
>     ICC profiles used if none are specified in the command line.  If
>     COMPILE_INITS=1, these will be included in the ROM file system.  The new
>     command line options related to ICC profiles are described in the Use.htm
>     documentation.
>     For c-list based rendering, all ICC profiles used in the rendering are stored in
>     the c-list.   During multi-threaded c-list reading, a link cache is associated with
>     the primary reader device and is shared amongst the various threads.
>     Efficiency improvements were made in the handling of soft mask groups, shading
>     smoothness calculations, and color image rendering.
>     For details on the branch, please see the commits that were made within the
>     branch.  There remain indeterminisms to fix.  The files affected include
>     Bug688807.pdf,  Bug688845.eps, Bug690208.pdf, 09-34.PS, CATX0988.pdf,
>     CATX1028.pdf,  CATX1101.pdf,  CATX5529.pdf.
>     Rendering issues to investigate include Bug689830.pdf, fts43xx.xps (page 3)
>     (shopping cart image), Bug689880.pdf, Bug691002.pdf, Bug689968.pdf,
>     Bug688584.ps (page 4), catx4949.pdf.
>     Note that the number of differences generated with the merge amounts to
>     pretty much every file.
>     Thanks to everyone who helped and provided input in this work, especially
>     Ray Johnston.

> [base/gdevpdfk.c base/gxclimag.c doc/Use.htm base/gdevdflt.c psi/icie.h base/gxpcmap.c base/gxpcolor.h lcms base/gscsepr.c base/gxshade4.c base/gxclthrd.c base/gxcmap.c base/gscscie.c base/gdevwts.c base/gsistate.c base/msvclib.mak base/gxclpage.c base/gscolor2.c base/gsicc_profilecache.c base/gxistate.h base/gscolor2.h base/gsicc_profilecache.h iccprofiles base/gdevp14.c base/gsicc_create.c base/gdevp14.h base/gsicc_create.h psi/write_t2.c psi/zusparam.c base/gdevpbm.c psi/zcolor.c psi/ztrans.c base/gdevpdft.c base/gxshade1.c /trunk/gs base/gdevpsdi.c psi/ireclaim.c psi/os2.mak base/watclib.mak Resource/Init/gs_lev2.ps base/gdevpsdu.c base/gscie.c base/gxclutil.c base/gscolor3.c base/gdevpsd.c base/gscie.h base/gxiscale.c base/gxcldev.h Resource/Init/gs_res.ps base/gxifast.c base/gxdevcli.h base/openvms.mak base/watcw32.mak base/gscms.h psi/msvc32.mak base/gsalloc.c base/lcms.mak base/gxp1fill.c base/gximage.h base/gsciemap.c base/gdevpx.c psi/zcsdevn.c base/ugcclib.mak base/unix-gcc.mak base/gsovrc.c base/gxcie.h base/macos-mcp.mak base/gxshade6.c base/macosx.mak base/gsccolor.h base/gdevrinkj.c base/unixansi.mak base/devs.mak base/gsicc.c base/gxipixel.c base/lib.mak psi/zimage.c base/gsicc.h psi/dxmain.c psi/dxmainc.c Resource/Init/pdf_draw.ps base/gscolor.c Resource/Init/pdf_ops.ps psi/zdevice.c psi/zcie.c psi/zdpnext.c base/gxclist.c psi/zcie.h base/gximono.c base/gxidata.c base/gstrans.c psi/iimage.h base/gdevpdfb.c base/gxclist.h base/gxshade.c base/gstrans.h base/gxclrast.c psi/zncdummy.c base/gxshade.h toolbin/color base/gsiccmanage.c base/Makefile.in base/gdevpdfv.c base/gsiccmanage.h base/gsicc_littlecms.c base/gxclpath.c base/gsicc_littlecms.h psi/icontext.c base/gxclpath.h base/gsstruct.h base/gdevxcf.c base/gxicolor.c base/gscspace.c base/gdevimdi.c base/gscdevn.c base/gscolor1.c base/gxclread.c base/gscspace.h base/bcwin32.mak base/gsdparam.c base/gs.mak psi/zshade.c base/gdevbbox.c psi/int.mak base/gxcspace.h psi/zicc.c base/gsstate.c base/winlib.mak base/gsicccache.c psi/zicc.h psi/zimage3.c base/gsicccache.h base/gdevpdfc.c base/gstparam.h base/gxblend.c base/gdevpdfg.c base/gxblend.h]

2010-05-24T02:01:13.653152Z Alex Cherepanov

>     Recognize Corel tint transform function and replace it with an equivalent
>     calculator function. Bug 690986.

> [psi/zfunc4.c]

2010-05-23T00:15:25.592930Z Alex Cherepanov

>     Decide whether load a CFF font as a simple font or a CIDFont based on the
>     /Subtype of the font object instead of the /Subtype of the font stream.
>     Acrobat appears to ignore the latter. Bug 691334.

> [Resource/Init/pdf_font.ps]

2010-05-22T09:17:30.088324Z Ken Sharp

>     Explicit pointer cast to silence a gcc compiler warning.

> [base/gxp1fill.c]

2010-05-21T15:16:07.910956Z Alex Cherepanov

>     Following Acrobat implementation but contrary to TTF spec, consider cmap entry
>     that has endCode < startCode as an entry with endCode == startCode.
>     According to the spec, "to use these arrays, it is necessary to search for the
>     first endCode that is greater than or equal to the character code to be
>     mapped. If the corresponding startCode is less than or equal to the character
>     code ...". I.e. an entry with endCode < startCode should have no effect.
>     Thanks to Ken for the patch. Bug 691326.

> [Resource/Init/gs_ttf.ps]

2010-05-21T08:14:56.354805Z Ken Sharp

>     Fix: device reference counting problem with patterns and clipping

>     Bug #690572 more details here. The problem was caused by installing a clip device while
>     drawing a pattern tile. This patch initialises the finalize member of the structure
>     where the clip device will be created to NULL. If a clip device is required, the member
>     will be initialised to a real routine. After drawing the pattern cell, if the finalize
>     routine is non-NULL we execute it.

>     This correctly dereferences the forwarded device if we create a clipping device.

> [base/gxp1fill.c]

2010-05-21T06:35:11.431787Z Hin-Tak Leung

>     adding missing dependencies so that setupgs and uninstgs can be built ahead or independent of the main targets

> [psi/winint.mak psi/msvc32.mak]

2010-05-20T07:31:06.101672Z regression

>     The clustermaster.pl code now checks the pid in the lock file to see if the
>     task is running.  Also no longer test pdfwrite with the language switch build.

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

2010-05-20T06:24:43.585523Z Hin-Tak Leung

>     Fix up the eol-style of the rest of the executable files by hand.
>     Remove executable bit from toolbin/bmpcmp.c

> [toolbin/bmpcmp.c jbig2dec/ltmain.sh tiff/config/ltmain.sh libpng/contrib/pngminim/encoder/gather.sh libpng/contrib/pngminim/preader/gather.sh libpng/scripts/libpng-config-body.in libpng/contrib/pngminim/decoder/gather.sh toolbin/tests/gsvalidate.py]

2010-05-20T06:10:20.265063Z Hin-Tak Leung

>     Set other type of shell script as native text.

>     find . -type f -executable  -exec file {} \; | \
>     grep 'script text executable'  | grep -v 'POSIX'  | \
>     cut -f 1 -d ':' |xargs -n 1 svn propset svn:eol-style native

> [toolbin/localcluster/bmps2html.pl toolbin/tests/dump_checksum.py toolbin/tests/gscheck_testfiles.py toolbin/tests/dump_checksum_plus.py toolbin/localcluster/readlog.pl toolbin/search-svn-revs toolbin/localcluster/clustermonitor.cgi toolbin/localcluster/clusterpush.pl toolbin/tests/dump_checksum_raw.py toolbin/localcluster/compare.pl toolbin/localcluster/comparerevs.pl toolbin/tests/find_unique_file.py toolbin/localcluster/clustermaster.pl toolbin/localcluster/weekly.sh toolbin/localcluster/build.pl toolbin/tests/build_revision.py toolbin/htmldiff.pl toolbin/tests/compare_checksumdb.py toolbin/tests/update_baseline.py toolbin/tests/make_baselinedb.py toolbin/tests/validate.py toolbin/bugsByEngineer.pl toolbin/localcluster/clusterpull.sh toolbin/tests/regen_filelist.py toolbin/localcluster/pngs2html.pl toolbin/localcluster/nightly.pl freetype/builds/mac/ascii2mpw.py toolbin/tests/compare_checksums.py toolbin/tests/run_nightly.py toolbin/tests/regen_baseline.py toolbin/tests/myoptparse.py toolbin/tests/get_baselines.py toolbin/tests/run_regression.py toolbin/localcluster/setupcluster toolbin/localcluster/clustermonitor.pl toolbin/tests/testdiff.py toolbin/tests/updatelistpdf.py toolbin/tests/run_series.py toolbin/tests/updatelist.py toolbin/localcluster/run.pl toolbin/tests/get_baseline_log.py toolbin/performance.pl toolbin/localcluster/cachearchive.pl toolbin/tests/make_testdb.py toolbin/tests/collate.py]

2010-05-20T06:01:41.643170Z Hin-Tak Leung

>     Set all identifiable shell script as native text

>     find . -type f -executable  -exec file {} \; | \
>     grep 'POSIX shell script text executable' | \
>     cut -f 1 -d ':' |xargs -n 1 svn propset svn:eol-style native

> [libpng/missing cups/pstoraster.in libpng/test-pngtest.sh cups/pstopxl.in libpng/install-sh jbig2dec/configure libpng/configure contrib/pcl3/ppd/catppd toolbin/clusterpush.sh libpng/depcomp jpeg/install-sh jbig2dec/config.guess contrib/pcl3/lib/if-pcl3 freetype/configure libpng/config.guess jasper/configure tiff/config/missing jbig2dec/config.sub jpeg/configure libpng/config.sub tiff/config/install-sh jpeg/config.guess zlib/configure jpeg/config.sub tiff/config/depcomp libpng/scripts/libpng-config-head.in tiff/config/compile libpng/scripts/libpng-config.in libpng/autogen.sh tiff/config/config.guess jbig2dec/mkinstalldirs jpeg/ltconfig tiff/config/config.sub libpng/mkinstalldirs contrib/epson740/ps-to-printer.fpi_rh5.2 jasper/acaux/missing jasper/acaux/install-sh tiff/autogen.sh freetype/builds/unix/install-sh freetype/builds/unix/mkinstalldirs tiff/configure jasper/acaux/depcomp jasper/acaux/compile tiff/config/mkinstalldirs jasper/acaux/config.guess contrib/pcl3/lib/cups-pcl3 jasper/acaux/config.sub]

2010-05-20T05:52:35.456761Z Hin-Tak Leung

>     Avoid raw carriage returns in configure which confuses svn

>     This is a known bug apparently of autoconf 2.63 which was fixed. Here is the upstream log entry:
>     http://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=commitdiff;h=cb34ecf

>     2008-10-27  Eric Blake  <ebb9@byu.net>

>     Avoid raw carriage return in scripts.
>     * lib/autoconf/status.m4 (_AC_OUTPUT_FILES_PREPARE): Generate CR
>     via tr, rather than with literal byte.
>     * THANKS: Update.
>     Reported by Steven R. Loomis; patch suggested by Thomas Dickey.

> [jbig2dec/configure]

2010-05-19T14:51:38.835112Z Robin Watts

>     Some work towards (but not a complete cure for) bug 691030.

>     Previously XXX_slant_into_trapezoids would check for 2 'simple' cases,
>     and bale into the fully general fill_slant_adjust function otherwise.
>     The simple cases were where the top span was a subset of the bottom one, or
>     vice versa.

>     Unfortunately the way the code to test for these cases was originally written,
>     one of these special cases could be used for shaped with vertical sides, and
>     the other couldn't.

>     By rewriting the test slightly, both cases can be used with trapezoids that
>     have one vertical side.

>     For good measure we also extract the 'rectangle' case out separately.

>     Cluster testing shows no differences (barring a couple of indeterminisms).

>     This reduces the output from 5 shapes (2 rectangles, 3 traps) to 3 (2
>     rectangles, 1 trap). One of the rectangles is still a repeat, but it's
>     a step in the right direction.

> [base/gxfillts.h]

2010-05-19T10:09:05.486708Z Masaki Ushizaka

>     Bug 691291. Fix reading uninitialized memory.

>     The change I made in r10603 had a problem comparing with
>     uninitialized data when using Roman fonts.
>     The side effect was slowing down font rendering a little.
>     In this change I added extra initializer and made
>     intention of the 'if' condition more clear.
>     No difference on outputs expected nor observed by localcluster
>     tests.

> [base/gschar0.c]

2010-05-19T07:42:20.717044Z Masaki Ushizaka

>     Follow-up to r11278.  Removing jbig2dec/config.h.

>     r11278 enabled jbig2dec/configure to be run.
>     I agree with the change but jbig2dec/config.h was also under
>     subversion control.  With r11278, after someone runs
>     'configure' or 'autogen.sh', jbig2dec/config.h become
>     modified status.
>     jbig2dec/config.h doesn't need to be here.  Deleting.

>     Related bug: 691304 & 691312.

> [jbig2dec/config.h]

2010-05-18T22:40:39.023883Z Hin-Tak Leung

>     define -DHAVE_CONFIG_H and run jbig2dec/configure from top-level configure.
>     The fixes some portability issues seen on opensolaris; further follow-up to bug 691304

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

2010-05-18T22:29:47.346946Z Hin-Tak Leung

>     typo in one word. bug 691323

> [doc/Readme.htm]

2010-05-18T22:23:13.250745Z regression

>     Minor changes to cluster code:

>     support language switch build testing
>     recover from disk full errors
>     automatically create directories needed for new nodes in run.pl

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

2010-05-18T12:22:48.908526Z Masaki Ushizaka

>     Disabling compiler warnings for discarding 'const'.

> [jasper/src/libjasper/base/jas_image.c jasper/src/libjasper/include/jasper/jas_image.h]

2010-05-18T08:55:18.202611Z Chris Liddell

>     Bug 691313: remove the IBM Omni driver from the default build on Linux.
>     Previously it could be excluded by giving configure "--without-omni",
>     this revision reverses the logic, so Omni can be include by giving
>     configure "--with-omni".

> [base/configure.ac]

2010-05-18T04:32:25.607601Z Marcos H. Woehrmann

>     Change the order in which jobs that take too long are killed on the cluster
>     nodes to prevent leftover jobs when running bmpcmp.

> [toolbin/localcluster/run.pl]

2010-05-17T15:48:38.534341Z Ken Sharp

>     Fix - type 1/CFF font interpreter.
>     The gs_type1_piece_codes routine interprets a type 1 or CFF glyph program to determine
>     whether the glyph is composed of two subglyphs (a SEAC).

>     There was a problem with the CFF opcode cntrmask which did not cater for the case where
>     it is called with a number of operands on the stack. In this case the operands are to
>     be interpreted as vstem hints. Because this was not done, the interpreter had the wrong
>     number of hints, and so did not interpret enough of the following bytes as mask data for
>     the cntrmask operation. This led to attempting to interpret data as operands, which
>     caused corrupted glyphs as well as potential crashes.

>     This does not appear to be tested by any of our current test files (according to a
>     cluster test), so no differences are expected.

> [base/gxtype1.c]

2010-05-17T08:25:06.874101Z Ken Sharp

>     white space change only, committed to make a regression run as the test for the
>     previous revision was interrupted.

> [psi/write_t1.c]

2010-05-17T07:55:43.268496Z Ken Sharp

>     Silence some compiler and make warnings.

> [psi/write_t1.c psi/int.mak psi/write_t1.h]

2010-05-17T04:39:57.140765Z Hin-Tak Leung

>     adding check for header stringprep.h; fix bug 691312

> [base/configure.ac]

2010-05-17T03:59:31.965365Z Hin-Tak Leung

>     Fixes portability issue properly with r11256 (which is identical with r11520),
>     first discovered by Ralph 6 months ago with r10520
>     which results in its being reverted in r10540 .

>     ******************************
>     Revert c10520 which causes problems with the MSVC build.

>     $(CC_) enforces 'ansi' C under msvc32.mak, disabling any Microsoft
>     extensions. This often causes problems with 3rd party libraries
>     which try to take advantage of those extensions.

>     This means that the -fPIC flag is again not propagated in the GCC
>     build; this is just to unbreak the build until I can test a different
>     solution which works on both platforms.
>     ******************************
>     As Ralph explained then, some of libtiff requires non-ansi extensions to work.

>     The main culpit is tif_win32.c (which includes <windows.h>) and some of the
>     file IO flags not being defined. So this commit fix the ansi issue properly.

> [tiff/libtiff/tiffiop.h base/libtiff.mak]

2010-05-17T03:47:02.654413Z Hin-Tak Leung

>     fix windows build breakage in r11249

>     This change (defining TIFFCONFIG_SUFFIX) should have been part of
>     r11249 (create tif_config.h for non-autoconf build)
>     which in turn should have been part of
>     r11241 (hook up libtiff with non-autoconf build via
>     "make -f base/unix-gcc.mak" and "make -f base/unixansi.mak")

>     The explanation is that in r10317 where Lars originally hooked up libtiff,
>     tif_config.h is generated by libtiff/configure (which is driven by the
>     top-level configure), but special provision is provided for non-autoconf build
>     (win32 and VMS) by copying from a canned header file.
>     If one chooses to bypass the top-level configure, *on every platform*
>     (win32, VMS, and non-autoconf unix build), one must provide similiar special
>     provision as well.

>     Personally I'll prefer not to support non-autoconf unix build.

> [base/unix-gcc.mak base/unixansi.mak base/libtiff.mak]

2010-05-16T18:32:40.253209Z Marcos H. Woehrmann

>     Changes to the nightly regression testing system to support weekly testing.

> [toolbin/localcluster/nightly.pl toolbin/localcluster/weekly.sh toolbin/localcluster/runNightly.pl toolbin/localcluster/run.pl]

2010-05-15T10:57:14.279373Z Hin-Tak Leung

>     rename PDEP to TIFFDEP to avoid clashing with PDEP from libpng.mak; bug 691299

> [base/libtiff.mak]

2010-05-15T10:55:47.722308Z Hin-Tak Leung

>     comment out a later duplcate definition; bug 691299

> [base/lib.mak]

2010-05-15T09:50:05.378608Z Hin-Tak Leung

>     latest version of these files from Adobe's web site: http://download.macromedia.com/pub/opensource/cmap/

> [Resource/CMap/UniGB-UTF8-H Resource/CMap/UniJIS2004-UTF32-H Resource/CMap/UniJIS2004-UTF16-H Resource/CMap/UniJIS2004-UTF8-H Resource/CMap/UniCNS-UTF32-H Resource/CMap/UniJISX0213-UTF32-H Resource/CMap/UniCNS-UTF16-H Resource/CMap/UniJIS-UTF32-H Resource/CMap/UniCNS-UTF8-H Resource/CMap/UniJIS-UTF16-H Resource/CMap/UniGB-UTF32-H Resource/CMap/UniJIS-UTF8-H Resource/CMap/UniJISX02132004-UTF32-H Resource/CMap/UniGB-UTF16-H]

2010-05-15T09:46:15.270585Z Ken Sharp

>     Add skeleton support for the Bitstream font engine. In its current form this only allows
>     for type 1 PostScritp fonts, CFF is trivial to add, as should be support for Bitstream's
>     own compressed format. Addition of type 42/TrueType fonts should be patterned after
>     FreeType, as there is support in Bitstream for a callback to provide TrueType
>     outlines. There is no such provision for PostScript fonts.

>     To build; define BITSTREAM_BRIDGE=1 and BITSTREAM_ROOT="", the root should point one
>     level above the 'core' directory. In the current code this would be :
>     "/bitstream/FontFusion 4.5a SDK"

> [psi/zfapi.c psi/ifapi.h psi/write_t1.c psi/int.mak psi/msvc32.mak psi/fapibstm.c]

2010-05-15T08:17:59.395641Z Hin-Tak Leung

>     better way of defining SOC_LOADER when try ing to do "make -f base/unix-gcc.mak so"

> [base/unix-dll.mak base/unix-gcc.mak]

2010-05-15T08:06:46.613460Z Hin-Tak Leung

>     The final part of trying to "ln -s base/unix-gcc.mak Makefile ; make so" work.

>     There were some fundamental problems with the older version: The so target really
>     should be built in three distinct stages with three different FLAGS - the
>     utils (genarch, gechogs) executable part, the shared library part, and the two final
>     executable part. The library should be built with the shared-object flags, but neither
>     of the utils nor the final executables should be built with "-shared", since they are
>     executables and not libraries. Hope this is clear.

>     There is also a little problem from SOC_LOADER not being defined if this file
>     is not used from ./configure's Makefile.

> [base/unix-dll.mak]

2010-05-15T07:58:16.778296Z Hin-Tak Leung

>     use CC_ instead of CC like everywhere else, to make the "so" target work

> [base/libtiff.mak]

2010-05-15T06:30:20.380857Z Hin-Tak Leung

>     "-shared" is a linker flag and not a compiler (object code
>     generation) flag; another piece of trying to
>     make "make -f base/unix-gcc.mak" work

> [base/unix-gcc.mak]

2010-05-15T06:27:41.486639Z Hin-Tak Leung

>     try to make 'make -f base/unix-gcc.mak so' work
>     When not run through ./configure, HAVE_CONFIG_H isn't defined and
>     the jbig2 codes drop through to generic unknown unix platform - so we put some
>     generic unix values here.

> [jbig2dec/os_types.h]

2010-05-15T06:23:35.840946Z Hin-Tak Leung

>     correct documentation on how make so should work -
>     ./configure --enable-dynamic is required

> [doc/Make.htm]

2010-05-15T03:36:29.389869Z Hin-Tak Leung

>     adding new header dependencies from the recent remove-globals effort

> [base/lib.mak]

2010-05-15T03:13:49.664716Z Hin-Tak Leung

>     adding a needed include to silent a compiler warning introduced by the
>     recent remove-globals effort

> [base/gslibctx.c]

2010-05-15T03:12:31.280935Z Hin-Tak Leung

>     another fix to bug 691306
>     This was broken in r2746 (June 2002) which nobody has noticed for 8 years.
>     This code path is only used for 'make -f unixansi.mak' (very generic unix cc compiler).

> [base/gp_unifs.c]

2010-05-15T03:09:09.671905Z Hin-Tak Leung

>     generate tif_config.h if it is not there. part of fixes to bug 691306

> [base/libtiff.mak]

2010-05-15T03:06:53.120732Z Hin-Tak Leung

>     adding comments about the vga devices being Linux specific

> [base/unix-gcc.mak]

2010-05-15T03:05:54.250134Z Hin-Tak Leung

>     part of fix to bug 691306.

>     These two devices has been broken since r2925 (DeviceN, August 2002),
>     but not built by default at all. They were blindly enabled in
>     unix-gcc.mak amongst the ESP merge from Till, and it would appear that
>     nobody has noticed since the merge (8.57-8.60) until now.

> [base/gdevl256.c base/gdevvglb.c]

2010-05-15T02:58:14.802157Z Hin-Tak Leung

>     freetype2 dependency in base/unixansi.mak to
>     make "make -f base/unixansi.mak" work;
>     another part for bug 691306

> [base/unixansi.mak]

2010-05-15T02:57:22.770443Z Hin-Tak Leung

>     freetype2 dependency in base/unix-gcc.mak to
>     make "make -f base/unix-gcc.mak" work; bug 691306

> [base/unix-gcc.mak]

2010-05-15T02:55:30.474135Z Hin-Tak Leung

>     add documentation about the default internal resolution for pdfwrite is 720dpi

> [doc/Ps2pdf.htm]

2010-05-15T02:54:08.145913Z Hin-Tak Leung

>     add documentation about how to force-embedding the basic 14 fonts

> [doc/Ps2pdf.htm]

2010-05-15T02:52:47.037525Z Hin-Tak Leung

>     fix an obvious typo in the makefile

> [base/libtiff.mak]

2010-05-14T16:46:05.198340Z Marcos H. Woehrmann

>     Added support to unix-gcc.mak and unixansi.mak to build/use libtiff
>     (also fixed some typos and made the device lists more similar).

>     Note because of the FreeType code these files do not work with
>     the current head (they work with ghostscript-8.71).

>     Fixes Bug 691301.

> [base/unix-gcc.mak base/unixansi.mak]

2010-05-14T04:23:14.678757Z Hin-Tak Leung

>     remove one extra tab introduced in r10994; non-GNU Make on Tru64 and HP-UX is
>     picky. Bug 688184 and bug 691299

> [psi/psromfs.mak]

2010-05-14T04:20:29.682174Z Hin-Tak Leung

>     HP compiler quirk - apparently the same workaround is needed for SUN Pro C and
>     GCC 1.x (see a few lines before this change) ; bug 688184

> [contrib/opvp/opvp.h]

2010-05-14T04:18:42.997881Z Hin-Tak Leung

>     uint8_t type located in usual header on HP-UX needed for jbig2dec ; bug 688184

> [jbig2dec/os_types.h]

2010-05-14T04:16:54.357328Z Hin-Tak Leung

>     fix conflicting types against HP-UX system header in jasper; bug 688184

> [jasper/src/libjasper/include/jasper/jas_types.h]

2010-05-13T20:08:08.900471Z Robin Watts

>     Nudge the windows solution/makefiles closer to supporting 64 bit builds
>     by defining WIN64 and amending makefiles to pass the define on through
>     recursive calls.

> [/trunk/ghostpdl/win32/xps.vcproj ghostscript-ufst.vcproj ghostscript.vcproj /trunk/ghostpdl/win32/pcl.vcproj /trunk/ghostpdl/win32/svg.vcproj psi/msvc32.mak /trunk/ghostpdl/main/pcl6_msvc.mak /trunk/ghostpdl/win32/language_switch.vcproj]

2010-05-13T16:49:47.848287Z Hin-Tak Leung

>     adding NULL check before closedevice - bug report 691296 and patch from Tim Waugh. Thanks.

> [base/gdevbbox.c]

2010-05-13T08:55:42.013750Z Ken Sharp

>     Changes only in white space, to provoke another regression test.

> [psi/zfapi.c]

2010-05-13T08:30:02.236776Z Ken Sharp

>     No changes, just an attempt to provoke some regression runs.

> [psi/zfapi.c]

2010-05-13T08:05:16.555333Z Ken Sharp

>     Fix FAPI interface
>     There is code in the FAPI interface for replacing a font's /FontBBox entry, this
>     sometimes has to create a new array to insert into the dictionary, if the old array is
>     not suitable for storing real values.

>     The code to do this continued using ref_assign_old, as it had done for replacing the
>     values in an existing array. This appears to be incorrect, when created the refs in a
>     new array are uninitialised so attempting to use ref_assign_old tries to use
>     uninitialised data.

>     Modified to use ref_assign_new instead, as indicated by the comments in store.h

>     This *may* reduce some of the non-deterministic behaviour, possibly with files such
>     as ShadowText.eps

> [psi/zfapi.c]

2010-05-12T08:44:16.052741Z Chris Liddell

>     Elimate an irksome compiler warning introduced in r11221

> [psi/zcolor.c]

2010-05-12T01:43:18.946640Z Hin-Tak Leung

>     adding documentation about the -dDisableFAPI=true switch in various places

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

2010-05-11T22:05:22.389565Z regression

>     The local cluster now tests the language switch build (ls).

> [toolbin/localcluster/clustermaster.pl toolbin/localcluster/build.pl toolbin/localcluster/clusterpush.pl toolbin/localcluster/run.pl toolbin/localcluster/clusterpush.txt]

2010-05-11T21:21:19.118628Z Robin Watts

>     Add x64 platform target to Visual Studio projects. I can't
>     test it myself due to not having a 64bit Windows setup,
>     but it at least starts building and then falls over when
>     it tries to run a 64bit exe as part of the build process.

> [/trunk/ghostpdl/win32/xps.vcproj ghostscript-ufst.vcproj /trunk/ghostpdl/win32/pcl.vcproj /trunk/ghostpdl/win32/svg.vcproj /trunk/ghostpdl/win32/language_switch.vcproj]

2010-05-11T21:02:09.407086Z regression

>     Minor improvement to cluster node log collection code.

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

2010-05-11T20:41:10.123188Z Robin Watts

>     bmpcmp was reporting the wrong page number for images, due to me forgetting
>     to increment the imagecount when images were loaded. Fixed here.

> [toolbin/bmpcmp.c]

2010-05-11T17:25:01.376580Z Chris Liddell

>     Bugs 690356 and 690832: have the colour space object take a copy of string
>     data associated with an indexed colour space lookup table. This prevents the
>     colour space finalising code (gx_final_Indexed) freeing the contents of a
>     Postscript object which may still be in use.

> [psi/zcolor.c]

2010-05-11T15:44:21.967848Z Ken Sharp

>     Fix (FAPI)
>     The PDF interpreter, when a font is missing, and it has the 'small caps' flag set,
>     creates a substitute by altering the CharStrings of the substitute font, replacing
>     the lower case glyph CharStrings with procedures which 'show' the upper case glyph at a
>     reduced size.

>     This ends up in the FAPI code as a t_mixedarray type which was being missed by the check
>     for a t_array, added previously to handle arbitrary procedures in a type 1 font. After
>     extending the check to include t_mixedarray it was clear that the SEAC processing was
>     also messing up the dictionary lookup, so it was necessary to restore a value which
>     had been overwritten in case a SEAC turned up.

>     zero-length-font.pdf should now work as it does without FAPI, no other differences
>     expected.

> [psi/fapi_ft.c psi/zfapi.c]

2010-05-11T14:34:32.672494Z Chris Liddell

>     Revise the UFST interface code for PCL/PXL and GS to work with the changes to
>     eliminate global variables in the Artifex code base.
>     NOTE: the UFST_REENTRANT configuration was broken, and still is (it has been
>     since the creation of gxfapiu.[ch] files. To be resolved in the future. At
>     this time, therefore, no build integrating UFST can be thread safe.

> [/trunk/ghostpdl/pl/plulfont.c psi/fapiufst.c base/gxfapiu.c base/gxfapiu.h]

2010-05-11T13:24:43.420456Z Robin Watts

>     Fix for bug 691249 - error caused by failing to initialise new member of
>     libctx that was previously a global.

>     We now memset the contents of libctx to 0 after mallocing it, and then
>     explicitly set the non-zero/NULL/false values. This is safer long term as
>     it protects us from making the same mistake in future.

> [base/gslibctx.c]

2010-05-11T12:41:44.704781Z Hin-Tak Leung

>     replace "/*" by "<slash><star>" to avoid
>     compiler warning about comments inside comment

> [base/mkromfs.c]

2010-05-11T11:55:10.416074Z Michael Vrhel

>     Debug code for helping in debug of 689737.  The pattern that is created is 1
>     bpp.  With this code the pattern bit map is dumped for opening with photoshop
>     as a raw 8bit image.  The source of the problem appears to be incorrect
>     creation of the pattern bit map when GraphicAlphaBits is set to greater than
>     1.

> [base/gxpcmap.c]

2010-05-11T09:35:16.657505Z Ken Sharp

>     Fix (fonts)
>     Bug #691290 "new freetype code gives error /typecheck in definefont"

>     When creating a Decoding from an Encoding array, treat null objects the same as /.notdef
>     (ie not encoded).

>     No differences expected.

> [Resource/Init/gs_fntem.ps]

2010-05-10T15:17:25.103327Z Ken Sharp

>     Fix (FreeType) : illegal use of setcurrentpoint not handled as per Adobe.
>     Bug #691172, file type1-ce1_setcurrentpoint.ps

>     The PostScript file includes a font which illegally uses setcurrentpoint to establish an
>     absolute x/y position. The spec is quite clear that this operator is *only* meaningful
>     when processing the results of an OtherSubr, so this usage is definitely illegal.

>     Not only does it use setcurrentpoint but, unlike previous uses we have seen, it does not
>     simply establish 0,0 as the initial point, which can be safely ignored, it actually
>     uses it to displace the outline vertically.

>     FreeType normally just puts two uninitialised variables on the stack, ignores the
>     setcurrentpoint and pops the two dummy values. Instead, we now push the current x and
>     y co-ordinates when we get a '0 callothersubr'. In setcurrentpoint we then use the
>     top two values on the stack to set the current point. This now works for the illegal
>     usage seen here, the previous illegal usage, and does not break well-formed fonts
>     which actually use the OtherSubrs to set the point.

> [freetype/src/psaux/t1decode.c]

2010-05-10T12:29:09.676516Z Michael Vrhel

>     Retry of fix for Bug 69048 (this one actually builds...) Again this should
>     only be a factor when using GraphicsAlphaBits.  The fix was to make sure
>     that when GraphicsAlphaBits is used we initialize the pattern bits buffer.
>     Otherwise the get_bits operation used during the gx_default_copy_alpha grabs
>     uninitialized memory.  Since we do not test with GraphicsAlphabits in the
>     regression testing I don't expect there to be any differences.

> [base/lib.mak base/gxpcmap.c base/gxdevmem.h base/gdevabuf.c base/gspaint.c]

2010-05-10T01:57:42.574530Z Michael Vrhel

>     Reversion to 11210 until I figure out what went wrong...

> [base/gsutil.h base/lib.mak base/gxpcmap.c base/gspaint.c base/gsutil.c]

2010-05-09T23:10:59.799862Z Michael Vrhel

>     Fix for Bug 690487.  This should only be a factor when using GraphicsAlphaBits.
>     The fix was to make sure that when GraphicsAlphaBits is used we initialize the
>     pattern bits buffer.  Otherwise the get_bits operation used during the
>     gx_default_copy_alpha grabs uninitialized memory.  Since we do not test with
>     GraphicsAlphabits in the regression testing I don't expect there to be any
>     differences.

> [base/gsutil.h base/lib.mak base/gxpcmap.c base/gspaint.c base/gsutil.c]

2010-05-08T22:30:46.926748Z Alex Cherepanov

>     Update license headers of a few retaining files with AFPL header.
>     Bug 691285.

> [Resource/Decoding/StandardEncoding Resource/Decoding/Latin1]

2010-05-08T21:22:13.614092Z regression

>     Whitespace changes only.

> [toolbin/localcluster/run.pl]

2010-05-08T21:12:23.981766Z regression

>     Minor changes to cluster software:

>     Check svn commands for errors and retry.

>     Gather individual logs and md5sums after each job is completed
>     rather than at the end of all jobs.

> [toolbin/localcluster/run.pl]

2010-05-08T20:47:25.658412Z Marcos H. Woehrmann

>     Minor changes to the cluster software:

>     Added a lock file to the clusterpull.sh task
>     Updated the documentation to explain how to temporarily disable a node.

> [toolbin/localcluster/clusterpull.sh toolbin/localcluster/readme]

2010-05-08T15:56:46.469253Z Alex Cherepanov

>     Detect and break an infinite loop when some of the image data source are
>     at EOF, some are not, and the image code doesn't take more data.
>     Bug 691285.

> [psi/zimage.c]

2010-05-08T09:59:55.023824Z Ken Sharp

>     Initialise a structure to silence a Coverity warning.

> [base/gdevpdfj.c]

2010-05-08T08:57:57.923764Z Ken Sharp

>     Really, properly, silence the gcc compiler this time....

> [base/gdevpdte.c]

2010-05-07T14:30:08.276765Z Ray Johnston

>     Fix clist_band_height to use the macro defined in gxband.h as other
>     code does to prevent future bitrot. Also use macros for the clist_ cfname,
>     cfile, bfname, bfile.

> [base/gxclist.h]

2010-05-07T14:23:18.978837Z Ray Johnston

>     Fix number of elements in the BAND_PARAMS_INITIAL initializer macro to
>     correspond to the size of gx_band_params_t (needed since rev 5751).

> [base/gxband.h]

2010-05-07T12:16:50.113521Z Ken Sharp

>     Silence some compiler warnings about not checking the return value from fread.

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

2010-05-07T12:12:47.989467Z Ken Sharp

>     Initialise the members of a local structure to silence a (spurious) compiler and
>     Coverity warning.

> [base/gdevpdte.c]

2010-05-07T08:17:29.050795Z Ken Sharp

>     Silence a GCC compiler warning, no differences expected.

> [psi/zfapi.c]

2010-05-06T16:04:27.459137Z Robin Watts

>     Remove gs_debug_out global variable as it is never used.

>     No differences expected or seen with local cluster testing.

> [base/bench.c base/gsmisc.c]

2010-05-06T16:03:43.016324Z Robin Watts

>     Update overprint device to avoid writing back to 3 global variables
>     ({generic,no,sep}_overptint_procs). We still have those global variables
>     but each instantiated device takes copies of them and does any writing back
>     into the copies. This is part of the work for bug 691207.

>     No differences expected or shown by local cluster testing.

> [base/gsovrc.c]

2010-05-06T16:00:28.103268Z Robin Watts

>     Move gs_interp_reschedule_proc, gs_interp_time_slice_proc, and
>     gs_interp_time_slice_ticks into context to avoid global variables as
>     part of the work for bug 691207.

>     No differences expected or seen with local cluster testing.

> [psi/icontext.c psi/zcontext.c psi/icstate.h psi/interp.c]

2010-05-06T15:25:10.815510Z Ken Sharp

>     Fix (FAPI & FreeType)

>     Bug #691284 "Error: /unknownerror in --.FAPIBuildChar"
>     The issue is caused because the PostScript file adds to an existing type 1 font a
>     CharString entry which is not in type 1 CharString format. I would have thought this
>     to be illegal but other PostScript interpreters (specifically Distiller) are happy
>     with it.

>     Modifed the FAPI interface so that after retrieving a type 1, non-CID, CharString we
>     test to see if it is a procedure, if it is, then we return an error from the FAPI
>     code to the caller (in this case the FreeType interface).

>     Modified the FreeType interface so that if the CharString retrieval returns an error
>     we return a  specific (otherwise unused) error to the caller, in this case the
>     FreeType engine. On return from FreeType to the interface we test for the specific
>     FreeType error (FT_ERR_Invalid_File_Format) and if this is detected then instead of
>     returning an error to FAPI, we add one to the character index (to ensure it isn't 0)
>     and return that to FAPI.

>     Finally, in the FAPI code, after 'rendering' the glyph, if we were returned a value
>     > 0 then we assume that 'something went wrong' with the CharString. As a last-ditch
>     effort we use the return value -1 to retrieve the CharString, and then 'exec' it.

>     NB if we fail to retrieve the CharString at this level, we return an invalidfont error.

> [psi/fapi_ft.c psi/zfapi.c psi/ifapi.h]

2010-05-06T03:04:41.737028Z Alex Cherepanov

>     Fix compilation errors on Visual C that wants "ui64" suffix instead of "ULL"
>     for "unsigned long long" numerals.

> [base/sha2.c]

2010-05-05T20:30:19.371369Z Robin Watts

>     Remove 2 unused globals. These should have been removed as part of 11146.

>     No differences expected.

> [psi/iinit.c]

2010-05-05T19:58:05.790577Z regression

>     Minor changes to the local cluster:

>     Report md5sum differences even in files that generate an error during processing.
>     Archive the email and log files for all revisions, including those which had compile errors.

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

2010-05-05T18:14:21.583279Z Robin Watts

>     More work towards bug 691207 (global variable removal).

>     There are 4 places is xps where we do eprintfs that access mem_err_print.
>     This resolves 1, the other 3 should never be called in files we support.

>     Resolve 4 const warnings from jasper.

>     Remove 2 calls to gs_lib_ctx_get_non_gc_memory_t from the cups driver. This
>     means the only places left calling this are devices in gs\contrib.

>     Convert calls to errprint_nomem to calls to errprint (in gdevx.c, gxttb.c,
>     gdevupd.c)

>     The only places using mem_err_print are therefore:

>     * calls to debug printing functions
>     * devices in gs/contrib calling gs_lib_gtx_get_non_gc_memory, errprint_nomem,
>     and eprintf.
>     * jasper calling eprintf.
>     * gdevsco.c (but that seems intrinsically single threaded to me as only one
>     thing can be using the console at a time, presumably)
>     * signal handlers in os2 and iwatc for catching numeric exceptions.
>     * Various devices in gs/base still call errprintf_nomem - some in DEBUG only
>     code, but some not.
>     * The gs_throw_imp function.

>     I think this may be as good as we can get at this point.

>     No differences expected, or shown by local cluster testing.

> [/trunk/ghostpdl/xps/xpsfont.c base/gdevx.c base/gdevupd.c base/gxttfb.c cups/gdevcups.c jasper/src/libjasper/base/jas_image.c jasper/src/libjasper/include/jasper/jas_image.h]

2010-05-05T16:25:49.238174Z Robin Watts

>     More work for bug 691207 (remove global vars). Change the gp_ interface and
>     all its implementations to pass a gs_memory_t in some cases to allow eprintf
>     calls to be made safely.

>     Also fix a 'const' warning in pxl/pxfont.c and pcl/pcsymbol.c

>     No differences expected, or shown by local cluster testing.

> [base/gp_os2.c base/gdevos2p.c base/gsdevice.c psi/zfile.c base/gp_os2pr.c base/gp_vms.c base/gdevwprn.c base/gxclfile.c base/gp_iwatc.c base/gp_os2.h base/gp_os9.c base/gdevwpr2.c /trunk/ghostpdl/pcl/pcsymbol.c /trunk/ghostpdl/xps/xpstop.c base/gp_unix.c /trunk/ghostpdl/psi/psitop.c base/gp_unifs.c base/gp.h base/gp_macio.c base/bench.c base/gdevpdf.c base/gp_os2fs.c /trunk/ghostpdl/pxl/pxfont.c base/gp_mswin.c base/gp_dvx.c]

2010-05-05T06:47:20.379288Z Masaki Ushizaka

>     A fix for 691164 "PDF loads blank when not Administrator on Vista using GS 8.7".

>     The problem was in JasPer library.  It tried to create temporary file in
>     current directory (HAVE_MKSTEMP), or root directory (Windows and others).
>     When those directories are read only, it failed to decode images.

>     This patch introduces searching of TMPDIR, TEMP and TMP environment varibales
>     and use them for temporary files.

>     Localcluster test reported no differences.

> [jasper/src/libjasper/base/jas_stream.c jasper/src/libjasper/include/jasper/jas_stream.h]

2010-05-05T03:08:00.170436Z Hin-Tak Leung

>     adding --ldflags to cups.mak ; bug 690268

> [cups/cups.mak]

2010-05-04T23:11:46.700325Z Hin-Tak Leung

>     Incoporate the reporter's suggested change to config.guess , bug 69020

>     It appears that the same change is already in automake-1.11 (and after 1.7),
>     so the change is correct. If we merge with upstream again, it is possible that
>     this might be overwritten. Hopefully when that happens, the config.guess from
>     newer upstream will have this change.

> [jasper/acaux/config.guess]

2010-05-04T22:52:33.245666Z Hin-Tak Leung

>     minor wording and grammar corrections. Bug 690005

> [doc/Use.htm]

2010-05-04T19:05:37.567635Z Robin Watts

>     A couple of calls to eprintf missed from the previous commit.

>     No expected changes.

> [base/gsfcid.c]

2010-05-04T19:04:51.514942Z Marcos H. Woehrmann

>     Improved the localcluster readme instructions.

> [toolbin/localcluster/readme]

2010-05-04T18:47:12.330141Z Robin Watts

>     As part of the work for bug 691207 (remove global variables) we introduce
>     a new set of macros, "emprintfX". These do the same as the "eprintfX"
>     macros, except they take an explicit memory reference rather than using
>     the mem_err_print global.

>     The plan is to move everything possible over to using emprintf, leaving
>     callers of eprintf as 'unsafe' in multithreaded builds.

>     This review changes all callers of eprintf in ghostscript except:
>     gdevsco.c, gp_iwatc.c, gp_macio.c, gp_mswin.c, gp_os2.c, gp_os2pr.c,
>     gp_unifs.c, gp_vms.c, gsfid.c, contrib\*, jasper\*.

>     1 instance in gzspotan.c remains unchanged, but it should never be used.

>     Local cluster testing shows no build problems.

> [psi/fapi_ft.c base/gdevpdfj.c base/gsdevice.c base/gdevos2p.c psi/zfapi.c base/gdevijs.c base/gdevpdfm.c base/gdevpx.c base/gxclfile.c base/gdevpdtb.c base/gdevpdfp.c base/gdevpdtc.c psi/fapiufst.c base/gdevpdtf.c base/gdevpdfu.c base/gxblend1.c base/gspaint.c base/gdevxini.c base/gxcmap.c base/gxclthrd.c base/gdevpsdu.c base/gdevpdtt.c base/gstype42.c base/gdevpsft.c base/gsmisc.c base/gdevsgi.c base/gxclmem.c base/gxttfb.c base/std.h base/gslib.c base/gxtype1.c base/gzspotan.c psi/imainarg.c base/gdevpe.c base/gdevsun.c base/gdevxcmp.c psi/imain.c base/gsiorom.c base/gdevpdf.c base/gdevtsep.c contrib/japanese/gdevdmpr.c base/gxclrast.c base/gdevpdfi.c]

2010-05-04T16:03:29.077971Z regression

>     Changed casper3.ghostscript.com to casper.ghostscript.com (no reason to test this, how can it possibly fail?).

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

2010-05-04T12:34:27.748154Z Robin Watts

>     As part of the efforts towards bug 691207 (global variables must be removed)
>     this commit reduces the reliance on mem_err_print.

>     Currently all calls to errwrite and errflush get the stdin/out/err details
>     from a global mem_err_print. For multithreaded gs this will result in output
>     going to the wrong place if any of them are redirected. This review splits
>     errwrite into 2 variants, errwrite and errwrite_nomem. The first takes an
>     explicit mem pointer. The second continues to assume a global one.

>     The plan is to make everything possible use the first. Currently debugging
>     calls and some 'stubborn' devices continue to call errwrite_nomem.

>     Local cluster testing shows no differences.

> [base/gdevos2p.c base/gdevsppr.c base/gdevpdfm.c base/gdevsunr.c base/gdevpx.c base/gdevupd.c base/gdevimgn.c base/gdevwpr2.c base/ttfmain.c base/ttfoutl.h base/gp_unifs.c /trunk/ghostpdl/psi/psitop.c base/gdev4693.c /trunk/ghostpdl/xps/xpsfont.c base/strmio.c /trunk/ghostpdl/pxl/pxtop.c contrib/pcl3/src/gdevpcl3.c base/gsmisc.c base/gdevwddb.c base/gsargs.c base/szlibd.c /trunk/ghostpdl/pl/plmain.c base/gxttfb.c base/std.h base/gdevifno.c /trunk/ghostpdl/xps/xpscff.c /trunk/ghostpdl/pcl/pctop.c contrib/pcl3/eprn/gdeveprn.c base/gdevcdj.c psi/ziodevsc.c base/gdevx.c base/gslibctx.c contrib/pcl3/eprn/eprnparm.c toolbin/localcluster/run.pl base/gdevhl7x.c]

2010-05-03T16:57:35.641421Z Henry Stiles

>     Fix compiler warning (return from incompatible pointer type)
>     introduced with making the font cache part of the library context,
>     revision 11165.

> [psi/isave.c]

2010-05-03T16:48:16.934577Z Lars Uebernickel

>     Applied Michael Constant's patch to support reading 256-bit AES encrypted PDFs
>     (bug #690702).

>     Minor modifications were made to the original patch to make it work with the
>     current trunk.

>     Aaron Gifford's SHA-2 implementation is included (BSD licensed).

>     Libidn is added as an optional dependency to support unicode passwords.  If it
>     is not installed, only ASCII passwords are supported.

> [base/errno_.h psi/zfaes.c psi/gs.c base/saes.c base/lib.mak base/sha2.c doc/Use.htm base/saes.h base/Makefile.in psi/int.mak psi/zutf8.c base/sha2.h base/locale_.h psi/zpdfops.c psi/zfsha2.c psi/zwinutf8.c psi/winint.mak base/ssha2.c base/configure.ac Resource/Init/pdf_sec.ps psi/msvc32.mak base/ssha2.h]

2010-05-03T13:25:52.802113Z Ken Sharp

>     Fix (pdfwrite) incorrect ToUnicode CMap.
>     Bug #691274 "Missing or incorrect ToUnicode when using Identity ordering"

>     pdfwrite emits ToUnicode CMaps in PDF files which always use 2 bytes for the key
>     length. That is 0x21 is represented as <0021>, since these are hex strings there should
>     in fact be no difference between <21> and <0021>. It is clear from the ToUnicode
>     Mapping file tutorial that this is correct for mapping files.

>     However, a PDF file is not a CMap file. It appears that Acrobat does not like
>     beginbfrange data which is padded with zeros (it seems happy with codespacerange and
>     destination codes which are 0 padded though).

>     This patch outputs ToUnicode CMaps which are not padded with 0, ie 0x21 is emitted as
>     <0021>, for the srcCodeLo and SrcCodeHi parameters in a beginbfrange operation. The
>     destination codes remain zero-padded.

>     Technically this would be incorrect for a real CMap file, but we don't write those
>     out so this should not be an issue. The change is limited to ToUnicode CMaps and does
>     not affect any other kind of CMap.

>     I believe the change will affect the data emitted for the beginbfrange,
>     beginbfchar, begincidchar, beginnotdefchar, beginnotdefrange and begincidrange
>     operators. It does *not* affect the begincodespacerange operator; although Acrobat
>     Distiller writes this without zero padding tests show that Acrobat is happy reading
>     zero-padded code space ranges.

>     ToUnicode information is not used in rendering PDF files, so regression testing should
>     show no differences. Local testing of a limited number of files doesn't reveal any
>     problems, but this change has not been well tested.

> [base/gsfcmap.c]

2010-05-03T04:13:30.766321Z Hin-Tak Leung

>     Fix unix so build regression; fixes regression from r9948 which was committed for bug 690695

> [base/unix-dll.mak]

2010-05-03T03:59:03.969165Z Hin-Tak Leung

>     fixes multiple jpeg devices listed in gs -h (bug 691176)

> [base/libtiff.mak]

2010-05-03T03:14:34.052929Z Hin-Tak Leung

>     Rewording build instructions for unix systems, and adding more warnings about
>     instructions for legacy old systems being deprecated; bug 691264.

> [doc/Make.htm]

2010-05-02T00:19:52.718987Z Robin Watts

>     Script to generate an html page that graphically show the differences
>     between local cluster regression run results between arbitrary revisions.

>     Usage information given in file. Must be run on the cluster master machine
>     (i.e. casper).

> [toolbin/localcluster/comparerevs.pl]

2010-05-01T23:22:33.008186Z Henry Stiles

>     Continue work to remove globals (691207).  The font cache is no longer
>     global but part of the library context.

> [psi/isave.h psi/bfont.h base/gslibctx.c psi/zfcid0.c psi/zfcid1.c psi/zfont.c psi/zfont0.c psi/zfont1.c psi/zbfont.c psi/zusparam.c base/gslibctx.h psi/zfont32.c psi/zfont42.c psi/isave.c]

2010-05-01T09:23:24.281883Z Ken Sharp

>     Modify the 'C' defaults of the pdfwrite device

>     Bug #691259 "HPGL graphic followed by raster graphic results in incorrect pdf"
>     The pdfwrite device is initialised in 'C', and then partly overridden by PostScript
>     initialisation. The problem is that non-PostScript input does not (cannot) execute the
>     PostScript initialisation, and so the defaults are left as those done in 'C'.

>     Not only do these defaults not match the documented defaults in ps2pdf.htm, they are
>     not particularly well selected. In this case the problem was caused by sending image
>     data at 150 dpi, but only a single scan line at a time. The default setting for
>     pdfwrite was to downsample image data to 72 dpi, this caused us to subsample (the
>     default downsampling) by a factor of more than 2, which led to our single scan line
>     becoming less than half a scan line, and so disappearing altogether.

>     This patch addresses this issue by altering a number of the defaults to more sensible
>     values. In particular we disable downsampling and enable image compression for gray
>     and colour images. This has the fortunate result of making most PDF output files
>     smaller than before, even though we are now storing more image data.

> [base/gdevpsdf.h]

2010-05-01T01:59:46.738263Z Alex Cherepanov

>     Check all PDF files for transparency features because some files have
>     incorrect version number but Acrobat renders them just fine. Bug 691273.

> [Resource/Init/pdf_main.ps]

2010-04-30T15:54:08.117709Z Ken Sharp

>     Testing a white space change for cluster regression tests, this will be overwritten later.

> [base/gdevpsdf.h]

2010-04-29T21:51:34.733741Z Till Kamppeter

>     rev 11149 for fixing bug 691014 had still some compiler warnings. This rev fixes them.

> [cups/gdevcups.c]

2010-04-29T18:32:44.398974Z Robin Watts

>     Remove the 'parent' parameter from gs_malloc_init calls. It only serves to
>     allow libctx's to be shared between instances, and we'll never want to do
>     that. It's unused at the moment anyway, so this doesn't impact anything.

>     No expected differences.

> [psi/gs.c base/gsinit.c base/gslib.c base/gsmalloc.c /trunk/ghostpdl/pl/plalloc.c psi/iapi.c base/gsmalloc.h]

2010-04-29T04:19:15.713592Z Hin-Tak Leung

>     Doubling the arbitrary 0x100000 alloc size limit; the alloc_size_is_ok() check is
>     complied out and replaced with DO_NOTHING in release build so this has effect only
>     on debug builds. Fixes Bug 691271 .

> [base/gsalloc.c]

2010-04-28T23:19:01.308642Z Robin Watts

>     Eliminate some warnings in gxcht.c (keep shifts < size of uint).

>     No local cluster differences reported, or expected.

> [base/gxcht.c]

2010-04-28T22:37:01.089543Z Till Kamppeter

>     Fixed segfaults caused by setting and changing the page geometry parameters incorrectly (bug #691014).

> [cups/gdevcups.c]

2010-04-28T21:57:29.180527Z Alex Cherepanov

>     Associate cached font instance with PDF font resource dictionary instead of
>     font descriptor. The latter may be shared by font resource dictionaries with
>     different encodings causing incorrect rendering. Bug 690714.

> [Resource/Init/pdf_font.ps]

2010-04-28T20:24:41.808400Z Robin Watts

>     Move op_array_table_global and op_array_table_local away from being
>     globals and into i_ctx_p. This requires various knock on changes
>     throughout the code to enable them to be recovered from the context
>     (which may itself need to be recovered from a memory pointer).

>     Also, the garbage collection is altered slightly; rather than the
>     op_arrays being special cased (as special objects that have to have
>     their component parts registered as roots for the garbage collection) we
>     move them inline into i_ctx_t and amend the gc routines for that
>     structure. Thanks to Alex for his help with this.

>     No differences expected, or shown with local cluster testing.

> [psi/iinit.c psi/icontext.c psi/imain.c psi/idebug.c psi/icstate.h psi/interp.c psi/igc.c psi/opdef.h psi/zmisc.c psi/iutil.c]

2010-04-28T20:19:40.848310Z Robin Watts

>     Simple fix to remove dict_default_pack from being a global bool.
>     (Make it an enum instead).

>     No changes expected or shown by local cluster testing.

> [psi/idict.c]

2010-04-28T17:18:52.709002Z Chris Liddell

>     Ensure that multiplication gets applied prior to type casting.

> [psi/fapi_ft.c]

2010-04-28T14:41:02.575217Z Robin Watts

>     Add missing cast to fapi_ft.c to quiet a warning. This was missed out of
>     yesterdays commit of such fixes.

>     No expected diffs.

> [psi/fapi_ft.c]

2010-04-28T11:40:24.316225Z Robin Watts

>     Small tweaks to Ghostscript initialisation to check for malloc failures etc.
>     This would very rarely have been a problem in current code, but would be
>     more of an issue in multithreaded operation as running out of memory
>     while forking a new instance is more likely.

>     No expected differences, but the local cluster code seems to be claiming
>     differences for an unchanged tree at the moment, so if 3 or so non-pdfwrite
>     errors and 1800ish pdfwrite errors show up, it's not because of this.

> [psi/gs.c psi/imain.c base/gsmalloc.c psi/iapi.c]

2010-04-27T16:06:05.631664Z Chris Liddell

>     Add back in a call removed in (a merging) error in my previous commit (11137).

> [psi/fapi_ft.c]

2010-04-27T14:53:14.939131Z Chris Liddell

>     Bug 691260: make the FAPI and Freetype related warning messages debug only,
>     and depend on -Zm for the FAPI warnings or -Z1 for the Freetype warnings.
>     Also address compiler warnings in fapi_ft.c.

> [psi/fapi_ft.c psi/zfapi.c]

2010-04-27T14:27:08.849186Z Robin Watts

>     Silence some warnings, either by including new headers or by introducing
>     explicit casts.

>     No differences shown by local cluster testing (of pcl and gs only as xps is
>     currently broken).

> [base/gxdcconv.c base/gsptype1.c base/gdevpx.c base/gstrans.c base/gdevrinkj.c base/gxfill.c base/gxstroke.c psi/zmisc.c]

2010-04-27T09:56:26.779813Z Till Kamppeter

>     Made the CUPS Raster output device working in a multi-threaded mode, removing all
>     global variables. Thanks to James Cloos for the patch. Fixes bug #691241.

> [cups/gdevcups.c]

2010-04-26T15:29:28.937213Z Alex Cherepanov

>     Remember the allocator in the dynamically allocated scanner_state to ensure
>     proper deallocation. Current allocation may be reset when a PS error occurs.
>     Bug 691167.

> [psi/ztoken.c psi/iscan.c psi/iscan.h]

2010-04-26T09:04:35.569612Z Chris Liddell

>     Ensure that the BuildChar object is not the null object before trying access its contents.

> [psi/zfapi.c]

2010-04-26T05:58:46.519692Z Michael Vrhel

>     Change so that when a graphic state is restored, the overprint compositor
>     action only occurs if there is a change from the current overprint state.
>     This fixes a problem in one of the files associated with bug 691014.  In
>     the particular file, overprint compositor actions were getting placed into
>     a pattern clist.  The file in fact had no overprint settings.
>     Ran regression test, no differences expected.

> [base/gsstate.c]

2010-04-25T23:47:56.048527Z Alex Cherepanov

>     Add ANSI/ASME Y14.1 A - F paper sizes named ANSI_A - ANSI_F for completeness.
>     Bug 691217.

> [Resource/Init/gs_statd.ps]

2010-04-25T22:45:48.099475Z Till Kamppeter

>     Minor clean-ups: Added some parantheses to casts and initialized allocated memory.

> [cups/gdevcups.c]

2010-04-25T22:32:09.854994Z Michael Vrhel

>     (empty)

> [base/gximono.c]

2010-04-25T21:52:42.447453Z Till Kamppeter

>     Introduced a real get_color_comp_index() method, to fix bug #690338 correctly.

> [cups/gdevcups.c]

2010-04-25T18:47:28.775496Z Alex Cherepanov

>     Add -dNONATIVEFONTMAP option to disable the use of font map and corresponding
>     fonts installed on underlying platform. This may be needed to ensure consistent
>     rendering on the platforms with different fonts, for instance,
>     during regression testing. Bug 691240.

> [doc/Use.htm Resource/Init/gs_fonts.ps]

2010-04-25T00:41:40.540207Z Michael Vrhel

>     Fix for Bug 691014.  Problem was caused by the fact that we had a soft
>     mask present and a pattern with no transparency.  This means the PDF14
>     device is installed and more importantly that transparency state pushes
>     and pops occur to keep the softmask in sync with the graphic state.  This
>     particular files pattern is installed as a clist, which happens to not have
>     any transparency.  The transparency state pushes and pops were getting placed
>     into the pattern clist when the Q and q operations occurred in the pattern, which
>     was causing problems since the pattern clist device had no pdf14 device installed to
>     handle such commands.
>     The solution is to check, when a transparency compositor action is to occur, if the
>     current device is a pattern accumulator or a pattern-clist device.  If it is, then
>     the pattern instance is checked to see if it has transparency.  If it does not, then
>     the transparency state chance is ignored.  This all occurs on the clist writing phase
>     in the gs_trans functions.

>     In addition, a fix was made so that the pdf14custom device sets up it's color information
>     correctly.  For subtractive devices that do not have cmyk process colorants the custompdf14
>     device is installed.  This pdf14 device was obtaining its color_info from the target device.
>     The pdf14 device must be continuous tone even if the target device is not.

>     Ran a regression test and saw no differences.

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

2010-04-24T22:21:26.893815Z Alex Cherepanov

>     Remove rudimentary code that maps out-of-range character codes to 0 causing
>     dictionary overflow in some cases. Unlike earlier array, dictionary
>     representation of 'cmap' table doesn't need this. Bug 691253, customer 780.

> [Resource/Init/gs_ttf.ps]

2010-04-23T12:56:00.372874Z Chris Liddell

>     Resolve issues with the language_switch Ghostscript build for Windows, since
>     Freetype enabled became the default for the normal GS build.

> [/trunk/ghostpdl/common/msvc_top.mak /trunk/ghostpdl/language_switch/pspcl6_msvc.mak /trunk/ghostpdl/psi/psitop.c psi/msvc32.mak]

2010-04-23T04:10:50.732099Z Michael Vrhel

>     Fix of minor memory leak found by Ray.  maskbuf entry of transparency ctx
>     object was not getting freed.  The large mask buffer, which is a member
>     variable of maskbuf was getting freed but not this 12 byte structure.
>     No expected differences.

> [base/gdevp14.c]

2010-04-23T03:25:33.581070Z Alex Cherepanov

>     Always load CFF font as a CIDFont when it is used as a descendant font of a
>     composite font in PDF file. Bug 691253.

> [Resource/Init/pdf_font.ps]

2010-04-22T12:28:16.186930Z Alex Cherepanov

>     Trap errors that happen in the font reader, issue a warning, and proceed as
>     if the font was not embedded. Bug 691242.

> [Resource/Init/pdf_font.ps]

2010-04-22T04:20:00.389442Z Alex Cherepanov

>     Don't use precompiled headers on MSVC 6 and 7 because it causes compilation
>     error C2006 in freetype, which uses #include MACRO .

> [base/msvccmd.mak]

2010-04-21T19:51:07.227636Z Robin Watts

>     Add missing header file from revision 11097.

> [base/gdevpdtd.h]

2010-04-21T19:26:13.171574Z Robin Watts

>     Revert macro magic from gserror.h introduced in r11097, due to it being
>     broken when used as an expression. Sorry.

> [base/gserror.h]

2010-04-21T18:12:56.928835Z Robin Watts

>     Another set of very simple tweaks to a range of source files to remove
>     warnings. Nothing contentious in here I hope!

>     base/gdevpdf.c: Make the fact we're ignoring the return value of fread
>     explicit by casting to void.

>     base/gdevsj48.c: Remove unused var.

>     base/gdevtknk.c: Avoid gcc warning by not needlessly assigning within
>     expression.

>     base/gdevimgn.c: Fix type declaration, make function static.

>     base/gxdcolor.c: Remove unused var.

>     base/gdevwts.c: Comment out unused function, cast unused return value from
>     fread to void, remove unused vars.

>     base/gdevo182.c: Be more explicit in type definition to stop warning.

>     base/gdevlp8k.c: Remove unused var.

>     base/gdevpdfu.c: Cast unused return value from fread to void.

>     base/gdevlbp8.c: Cast unused return value from fread to void.

>     base/gdevokii.c: Explicit cast to int to shut up stupid compiler.

>     base/gdevpdtd.c: Add const to arg to avoid warning.

>     base/gserror.h: Do some macro magic to ensure that the macro always evaluates
>     it's arg strictly once, insists on being followed by a semicolon, and behaves
>     well with surrounding if/else structures etc.

>     base/gxp1fill.c: Remove unused var.

> [base/gdevlbp8.c base/gdevtknk.c base/gdevsj48.c base/gdevo182.c base/gdevpdf.c base/gdevimgn.c base/gdevokii.c base/gdevpdtd.c base/gxdcolor.c base/gdevwts.c base/gdevlp8k.c base/gdevpdfu.c base/gxp1fill.c base/gserror.h]

2010-04-21T17:55:08.584502Z Robin Watts

>     Fix for a problem in the rinkj driver for Epson Stylus Photo 2200.
>     The code was accessing indexes 4,5,6 in plane_offsets[6] and hence was
>     running off the end of the array. This was causing a warning at compile time
>     but never caused a segv as it was merely corrupting the next entry in the
>     structure which was reset to 0 shortly afterwards.

>     Presumably the offset for one of the planes would be wrong though causing
>     a loss of quality.

> [base/rinkj/rinkj-epson870.c]

2010-04-21T17:23:31.243056Z Robin Watts

>     Remove several occurrences of calls to gs_lib_ctx_get_non_gc_memory_t().
>     The only code that now needs this is gp_macpoll.c and gp_mspol.c for when
>     CHECK_INTERRUPTS is defined. This reduces the need for mem_err_print.

>     The only other code that uses mem_err_print is errflush() and errwrite().
>     Potentially these could be nobbled for a multithreaded build.

>     The changes here rely on the memory pointers being set up correctly. While
>     local cluster testing gives this a clean bill of health, it's possible that
>     problems will appear with files in the wider world - we'll just have to fix
>     these as they are reported.

> [base/gdevjpeg.c base/sjpx_luratech.c base/strmio.c base/gxttfb.c psi/zfdctd.c base/sdctc.c psi/zfdcte.c psi/zfjpx.c base/sjpx.c]

2010-04-21T15:08:47.471495Z Robin Watts

>     Move CPSI_mode from being a global to living in the libctx, as part of the
>     efforts for bug 691207 (remove global variables).

>     I originally tried moving CPSI_mode into the imager state, which would have
>     been slightly nicer, but had to abandon this due to problems interacting
>     with the command list code. My first thought to make this work was to
>     push the value of CPSI_mode into the clist at initial clist creation time.
>     As the setting of CPSI_mode isn't vectored through the device, we can't
>     detect changes in its setting, but then changing CPSI_mode during the
>     lifespan of a clist would give unpredictable results anyway in many cases.

>     Sadly this was doomed to failure as if a page device is started up that
>     uses the clist code to do banding, then the command list is created before
>     CPSI_mode is enabled, and we'd operate with the incorrect value.

>     Moving CPSI_mode into libctx means we keep exactly the same behaviour as
>     we have now. This has required various functions throughout the code to
>     pass a gs_memory_t * around.

>     Localcluster testing reveals no problems.

> [psi/zfunc3.c psi/zupath.c base/gsdps1.c base/gdevdevn.c base/gxblend1.c base/gspaint.c base/gxstroke.c psi/zmisc.c base/gdevperm.c base/gxdcconv.c base/gdevpsds.c base/gxcmap.c base/gxdcconv.h psi/zfont.c base/gdevrinkj.c base/gdevbit.c base/gsmisc.c base/gxfill.c base/gdevxcf.c base/gxicolor.c base/gdevpsd.c psi/zimage.c base/gsfont.c contrib/opvp/gdevopvp.c base/gsfont.h base/gsstate.c base/gslibctx.c base/gsstate.h psi/zcharx.c psi/zusparam.c base/gslibctx.h base/gsequivc.c psi/zchar.c]

2010-04-21T07:20:14.808042Z Masaki Ushizaka

>     A fix for a regression introduced by r11074 (bug 690094).

>     As I changed image number to be incremented when 'exflag' is false,
>     the problem of 'exrunlength' when SDHUFF == 1 was unveiled.
>     This fixes it.
>     JBIG2 images with SDHUFF == 1 should have been having trouble
>     between r11074 and this revision.  No other difference expected.

> [jbig2dec/jbig2_symbol_dict.c]

2010-04-20T18:52:36.186732Z Robin Watts

>     A series of tiny changes to various files to stop compiler warnings.
>     Nothing contentious in here, so I hope component owners don't object.

>     psi/zpdfops.c: Make zpdfinkpath function static.

>     psi/zcie.c: cie_cache_finish1 is an unused function; #if 0 it with a note.

>     psi/zicc.c: Remove 2 unused variables from a function.

>     psi/zcolor.c: Add a 'default' case to a switch to stop a 'variable RGB
>     might be used uninitialised' warning. Remove out of date comment and make
>     zswapcolors static.

>     psi/zfcid1.c: Convert some unused variables to comments.

>     base/gp_unix_cache.c: Make the fact we are ignoring the return value from
>     fread explicit by casting to void.

>     base/gstype42.c: Move an unused var into a #if 0 section, comment out an
>     unused function.

>     base/gstrans.c: Use 'any_abs' rather than 'abs' (to avoid abs being used
>     without definition).

>     base/gxshade6.c: Remove unused function

>     base/gxclfile.c: Make the fact we are ignoring the return value to freopen
>     explicit by casting to void.

> [base/gxshade6.c psi/zcolor.c psi/zicc.c psi/zcie.c base/gp_unix_cache.c base/gxclfile.c base/gstrans.c base/gstype42.c psi/zfcid1.c psi/zpdfops.c base/echogs.c]

2010-04-19T16:15:13.462842Z Lars Uebernickel

>     Made oog_encode in tif_luv.c reentrant by precalculating oog_tables.

>     oog_tables was calculated on-demand when writing TIFF files in LogLuv Encoding.
>     Since it didn't depend on anything dynamic, I replaced this code with a static
>     const array.  The array only consisted of 100 ints - the net library size
>     actually went down a few bytes after this change.

>     This is part of bug #691207 (global variables must be removed).

> [tiff/libtiff/oog_table.h tiff/libtiff/tif_luv.c]

2010-04-19T11:56:27.260655Z Lars Uebernickel

>     Removed global variables in libtiff's tif_pixarlog.c.

>     This is part of #691207 (global variables must be removed).

> [tiff/libtiff/tif_pixarlog.c]

2010-04-19T09:47:14.697946Z Lars Uebernickel

>     Removed TIFFReassignTagToIgnore in the local libtiff copy.

>     It wasn't reentrant due to static variables and has been deprecated for a while
>     now.  GhostScript does not use it at all.  Libtiff HEAD also has this function
>     removed, it was only kept in 3.x for backwards compatibility.

> [tiff/libtiff/tif_dir.c]

2010-04-15T18:58:00.960218Z Robin Watts

>     New Visual Stdio project file for building ufst version of ghostscript.

>     Currently assumes that the ufst code will be found in C:\ufst, but this can
>     be edited in the nmake invocation lines within the Project settings.

> [ghostscript-ufst.vcproj]

2010-04-15T18:41:31.569934Z Robin Watts

>     Update msvc32.mak with various ufst make targets. This allows a
>     ghostscript-ufst Visual Studio project to be constructed.

>     No differences to existing builds.

> [psi/msvc32.mak]

2010-04-15T17:13:30.072845Z Robin Watts

>     Remove invalid_file_stream and invalid_file_entry global variables,
>     as part of the effort for bug 691207 (remove global variables).

>     We move invalid_file_stream to be a non-gc chunk allocated to be in
>     i_ctx_t, and invalid_file_entry can then be replaced by
>     i_ctx_p->invalid_file_stream. The only tricky bits are a) the need to ensure
>     that i_ctx_p is available everywhere where it is needed, and b) making sure
>     that invalid_file_stream doesn't move when i_ctx_p is relocated.

>     No changes shown by localcluster testing (though a previous version of the
>     patch did fail during gc, so the relavent code is getting tested).

> [psi/zfile.c psi/ztoken.c psi/zcontrol.c psi/zshade.c psi/zcontext.c psi/zfcid0.c psi/zfcid1.c psi/zicc.c psi/zfrsd.c psi/icontext.c psi/zvmem.c psi/ziodev.c psi/zfileio.c psi/interp.c psi/icstate.h psi/files.h]

2010-04-15T16:13:10.848189Z Lars Uebernickel

>     Backported and applied libtiff patches from libtiff bugs #2125 and #2125.
>     These get rid of some of the global variables in libtiff (in particular
>     rgb_refblackwhite and whitepoint in tif_aux.c).

>     This is part of the multi-threaded gs effort (bug #691207).

> [tiff/libtiff/tif_dirinfo.c tiff/libtiff/tif_aux.c tiff/libtiff/tif_dir.c tiff/man/TIFFGetField.3tiff tiff/libtiff/tif_dir.h tiff/libtiff/tif_ojpeg.c tiff/libtiff/tif_jpeg.c]

2010-04-15T14:48:36.373936Z Robin Watts

>     Fix for bug 691244, reported/patch supplied by Norbert Janssen. In
>     revision 11045, I'd moved some globals into the libctx, which is
>     accessed via the gs_memory_t pointer. This has required certain
>     functions to now take a gs_memory_t pointer as an extra arg. In
>     this particular case the gs_memory_t pointer in question could be
>     NULL. The fix is to use one obtained from gs_lib_ctx_get_non_gc_memory_t,
>     a call to which happens conveniently to be on the previous line.

>     gs_lib_ctx_get_non_gs_memory_t is going to be painful to remove later on,
>     but at least this fix gets us up and running again now.

>     No expected differences.

> [base/strmio.c]

2010-04-15T09:53:33.313864Z Masaki Ushizaka

>     A fix for 690094, "missing letters replaced by little vertical lines".

>     This problem was in jbig2dec function jbig2_decode_symbol_dict().
>     The image number was not incremented correctly when it built
>     symbol dictionary.
>     No difference expected, other than JBIG2 pdf files suffered by
>     this problem.

> [jbig2dec/jbig2_symbol_dict.c]

2010-04-15T08:30:48.171463Z Chris Liddell

>     Resolve a Freetype build problem on Mac - solution suggested by Tor and Henry.

> [base/freetype.mak]

2010-04-14T19:29:56.362613Z Robin Watts

>     Update the clist band list compressor code to work without using global
>     variables as part of the workd for bug 691207 (remove global variables).

>     The old code used to call a function to read an initialise global structure,
>     then based on that allocate storage and copy the structure into it. The new
>     code essentially does 2 calls; one that serves to get the size, and another
>     that serves to initialise the newly allocated structure.

>     To facilitate testing, this introduces a new TEST_BAND_LIST_COMPRESSION
>     define. If built with this as a define, the code sets the compression
>     threshold to 1K, thus forcing the use of compression. A local cluster
>     push with this in reveals just one problem, and that seems to be in the
>     existing code whereby inflateEnd can be incorectly called on a NULL derived
>     pointer. A fix for that is included too.

>     No expected differences.

> [base/gxcllzw.c base/gxclmem.c base/lib.mak base/gxclzlib.c base/gxclmem.h base/szlibd.c]

2010-04-14T16:25:11.391305Z Chris Liddell

>     Reverse the previous build options for Freetype integration: now
>     --disable-freetype for configure on Unix type systems or pass FT_BRIDGE=0
>     to nmake on Windows if you do not want to integrate Freetype.

> [base/configure.ac psi/msvc32.mak]

2010-04-14T16:03:29.953276Z Ken Sharp

>     Fix FreeType FAPI
>     No bug for this (probably should be). Noticed while testing that using a TrueType to
>     replace a missing CIDFont (ie entry in cidfmap) was rendering the wrong glyphs, and
>     applying a vertical advance.

>     The incorrect glyph seems to be because we were incorrectly stating that the character
>     index was not a glyph ID, which it is in this case.

>     The second problem was more difficult. FreeType manufactures vertical advance metrics
>     for all TrueType glyphs, we override those in the incremental interface callback, but
>     when the TT is a CIDFont on disk, we don't use the incremental interface and so have
>     no opportunity to override the metric.

>     Addressed this by checking in load_glyph to see if the current font is not type 1
>     (ie its TT), *is* a CIDFont, and is not a vertical font (WMode is 0). In this case
>     we simply override the vertical advance and maek it 0.

> [psi/fapi_ft.c psi/zfapi.c]

2010-04-14T14:11:19.891045Z Robin Watts

>     Move real_time_0 from being a static variable in zmisc.c to being an entry
>     int libctx. Instead of initialisation happening in zmisc it now happens in
>     gslibctx.c. Part of the effort for bug 691027 (remove global vars).

>     This variable isn't strictly speaking necessary, but apparently some FTS
>     tests behave better if realtime starts from 0, and it isn't a big problem.

>     No differences shown in localcluster testing.

> [base/gslibctx.c base/gslibctx.h psi/zmisc.c]

2010-04-14T10:03:31.189133Z Hin-Tak Leung

>     a few more comments about some microsoft CJK fonts

> [lib/mkcidfm.ps]

2010-04-14T02:31:58.209185Z Masaki Ushizaka

>     Fixed jbig2dec command getopt() parameter for -v option.  Not used by
>     ghostscript itself but worth for standalone debugging.

> [jbig2dec/jbig2dec.c]

2010-04-14T02:26:16.603254Z Masaki Ushizaka

>     Fixed an indent. No influence on code.

> [jbig2dec/jbig2_symbol_dict.c]

2010-04-13T14:52:16.370358Z Henry Stiles

>     Gets rid us of 2 global variables in jasper (jas_image_numfmts and
>     jas_image_fmtinfos).  In so doing we take the liberty of simplifiying
>     jasper's startup.  The configured codecs (we only use 2: jpc and jp2)
>     were set at compile time anyway so the the methods to "add formats"
>     and "clear formats" have been replaced with a static table.

> [jasper/src/appl/imgcmp.c jasper/src/appl/jasper.c jasper/src/appl/imginfo.c jasper/src/libjasper/base/jas_image.c jasper/src/libjasper/base/jas_init.c jasper/src/libjasper/include/jasper/jas_image.h]

2010-04-13T14:29:59.699580Z Robin Watts

>     Remove BITTAG global variable by moving it into the libctx, as part of
>     efforts towards bug 691207 (multithreaded gs). This has required several
>     accessor functions to gain gs_memory_t * arguments.

>     No differences expected, or shown by localcluster testing.

> [base/gsnamecl.c base/gsutil.h base/gslibctx.c base/gdevbit.c base/gslibctx.h base/gsutil.c]

2010-04-13T13:06:54.792469Z Ken Sharp

>     Fix FreeType
>     A prior update which re-initialised a glyph index to prevent old Metrics override
>     values persisting after a glyph was discarded did not check the ft_inc_int member of
>     the 'FF_face' structure before dereferncing it, leading to a potential crash if the
>     font was not incrementally loaded.

>     The code now checks the value before attempting to dereference the pointer.

> [psi/fapi_ft.c]

2010-04-13T12:50:40.024266Z Ken Sharp

>     Modify FAPI support files
>     Moved FAPIConfig, FAPIcidfmap and FAPIfontmap from the 'lib' directory to the
>     'Resource/Init' directory, so that they get built in when COMPILE_INITS=1.

>     Also modified gs_fapi.ps to contain default values for the contents of FAPIConfig which
>     map all fonts to the FAPI engine (FreeType for now). Modified FAPIConfig so that the
>     usual contents are commented out. This should allow the possibility of overriding the
>     default values by putting new values in FAPIConfig.

> [lib/FAPIcidfmap lib/FAPIfontmap lib/FAPIconfig Resource/Init/FAPIcidfmap Resource/Init/FAPIfontmap Resource/Init/FAPIconfig Resource/Init/gs_fapi.ps]

2010-04-13T12:15:42.067350Z Robin Watts

>     Move global variables from gshtscr.c (screen_accurate_screens,
>     screen_min_screen_levels, screen_use_wts) into libctx. This has
>     meant updating the functions to read/write these to take a
>     gs_memory_t pointer too. Part of the efforts for bug 691207.

>     No differences shown by localcluster testing.

> [base/gshtscr.c base/gxht.h psi/zusparam.c base/gslibctx.h base/gsht.c base/gsht1.c psi/zht.c psi/zht2.c]

2010-04-13T09:50:08.611008Z Masaki Ushizaka

>     A fix for 691081, 691206, and part of 690094.

>     From r9769, jbig2dec wasn't capable of decoding some JBIG2 files and throwing
>     a error "jbig2dec FATAL ERROR runlength too large in export symbol table
>     (XXX > XX - XX) (segment 0xXX)".
>     This was caused by accidentaly bound checking export symbol table size with
>     number of non-export symbol.  This fixes it.
>     No differences expected, other than JBIG2 files suffered from this problem.

> [jbig2dec/jbig2_symbol_dict.c]

2010-04-13T09:38:22.017180Z Chris Liddell

>     Minor revision to FAPI code to better ensure GS errors in callbacks
>     survive through the font renderer library.

> [psi/fapi_ft.c psi/zfapi.c psi/ifapi.h psi/fapiufst.c]

2010-04-13T03:25:58.022387Z Henry Stiles

>     Make the CIESpaces array and its elements constant so it is not
>     confused with global modifiable data.

> [psi/zcolor.c]

2010-04-12T10:44:43.428786Z Chris Liddell

>     Remove the hardcoded identity matrix in the Type 1 serialization code in
>     favour of the new FAPI call allowing the interface code to dictate the matrix
>     to be used.

> [psi/zfapi.c]

2010-04-10T09:35:54.039788Z Ken Sharp

>     Remove extraneous debug statement in revision 11050.

> [Resource/Init/gs_fapi.ps]

2010-04-10T09:28:50.393011Z Ken Sharp

>     FAPI Enhancement
>     We need a way in the initial release where we set FreeType as the default font scaler to
>     switch it off and revert back to the Ghostscript internal font scaler, in case there
>     are significant problems. Bug #691237

>     This allows the user to either send PostScript or set a command line value to create
>     a key called DisableFAPI, if the value is true then FAPI will no longer be active, and
>     so the GS font scaler will be used.

>     Can also be set with -dDisableFAPI=true at the command line.

> [Resource/Init/gs_fapi.ps]

2010-04-09T18:22:38.657773Z regression

>     Fixed a recently introduced bug in the cluster that caused gs head to
>     be used when compiling GhostPCL/GhostXPS even if a previous revision
>     should have been used (as is the case when two or more commits occur
>     while the cluster is busy).

> [toolbin/localcluster/run.pl]

2010-04-09T17:49:20.410599Z regression

>     Minor tweaks/improvements to the cluster code:

>     Fixed bug which occasionally left jobs running on macpro.

>     Clusterpush.pl when run with user==Michael Vrhel now compares to icc_work branch.

>     Report all icc_work branch errors (not just new ones).

>     Collect time to run information.

>     No longer cache mupdf results.

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

2010-04-09T14:51:26.314389Z Ken Sharp

>     Fix UFST and enhance FAPI
>     Define a new API call for FAPI to allow font engines to replace a FontMatrix. This is
>     to allow FreeType to replace the FotnMatrix with the identity as it makes the 2-step
>     scaling performed by FreeType simpler.

>     Modified compute_em_scale so that it uses the new API call instead of blindly replacing
>     the FontMatrix.

>     Restored the calculation in FAPI_do_char which unwinds the FontMatrix from the CTM
>     when calculating the scale factor. Use the new API call to retrieve the desired
>     FontMatrix rather than pulling it directly from the font as before.

> [psi/fapi_ft.c psi/zfapi.c psi/ifapi.h psi/fapiufst.c]

2010-04-09T08:13:56.362732Z Ken Sharp

>     Fix Bug #691180
>     This alters the described 'odd behaviour' of the font substitution code whereby fonts
>     whose name does not contain either 'Serif' or 'Sans' are substituted with Helvetica,
>     but those which contain 'Italic' are substituted with Times. Italic fonts are now
>     treated the same as Oblique fonts, and substituted with Helvetica, unless the font
>     is identified as a serif font.

>     This may cause some substitution differences with regression files.

> [Resource/Init/gs_fonts.ps]

2010-04-08T21:42:54.260278Z Robin Watts

>     Move io_device_table from being a global static in gsiodev.c into
>     the library context. In order to retrieve it we need to update
>     lots of functions to take a gs_memory_t * as well.

>     Localcluster testing shows no expected differences.

> [base/gsdevice.c psi/zfile.c base/gdevupd.c base/gsiodev.c base/gxdevice.h psi/ziodev2.c base/gdevprn.c psi/ziodevsc.c base/sfxcommon.c psi/zfrsd.c base/gxiodev.h base/strmio.c base/gslibctx.c base/gsfname.c psi/ziodev.c base/gdevtsep.c psi/zcrd.c base/gslibctx.h base/gsfname.h base/gdevps.c]

2010-04-08T16:05:50.601517Z Ken Sharp

>     Fix TrueType interpreter Bug #691227
>     Another nasty hack for another broken TrueType font. In this case the font tries to
>     execute a DeltaP instruction with an argument greater than the number of points in the
>     glyph, which is an error.

>     FreeType's interpreter has this comment

>     /* XXX: Because some popular fonts contain some invalid DeltaP */
>     /*      instructions, we simply ignore them when the stacked   */
>     /*      point reference is off limit, rather than returning an */
>     /*      error.  As a delta instruction doesn't change a glyph  */
>     /*      in great ways, this shouldn't be a problem.            */

>     This patch more or less mimics this in our code.

> [base/ttinterp.c]

2010-04-08T15:54:31.828558Z Ralph Giles

>     Remove the commented out invocations of autoheader and aclocal/automake
>     in the autotools bootstrap script.

>     The various autotools modules must be invoked in a specific order, and
>     usually with non-default options. We only use autoconf in our build,
>     not any of the other tools which layer on top of it, but I had left
>     their invocations in the script, but commented out, so make it easier
>     to add them at a later date.

>     It's been some years since autogen.sh was added, and we still have no
>     plans to adopt automake. Also, the script didn't include support for
>     libtoolize (which is glibtoolize of MacOS X)  nor for detecting the
>     appropriate automake version, so it seems simpler to just remove the
>     commented out lines to avoid confusion.

> [autogen.sh]

2010-04-08T15:39:26.443280Z Robin Watts

>     Stop a function scope static from being static as nothing was gained by it,
>     and this removes it from the list of global variables as part of the efforts
>     for bug 691207 (multithreaded safety).

>     No expected differences.

> [base/gdevupd.c]

2010-04-08T15:29:26.540666Z Robin Watts

>     Change a static (that happens to be const) to be a static const to remove
>     it from the global variable list for bug 691207.

>     No expected differences.

> [base/gdevifno.c]

2010-04-08T15:22:28.719732Z Robin Watts

>     Remove globals from gdevmgr.c as part of efforts on bug 691207 (multithreaded
>     safety).

>     Move 5 tables from being file level statics to living in the device structure.

>     Checked by doing back to back builds and verifying that the same output is
>     given for tiger.eps in both cases.

>     No expected differences.

> [base/gdevmgr.c]

2010-04-08T15:16:51.654028Z Robin Watts

>     Remove the function scope static variables from gdevcdj.c as part of the
>     efforts for bug 691207 (multithreaded safety). These only affect the
>     ESC/P driver.

>     There are 4 variables in play here. real_rows doesn't actually need to be
>     static at all as it is always set before being used. The other 3 (ln_idx,
>     vskip1 and vskip2) all go into the 'ep_globals' structure.

>     There is a subtle change in behaviour here; previously these variables were
>     initialised to zero on execution start (and again on every flush). Now they
>     are initialised to zero at the start of every page (and again on every flush).
>     This means that leftover vskips are no longer carried forwards from page to
>     page. This seems like a good thing to me.

> [base/gdevcdj.c]

2010-04-08T14:30:41.679319Z Robin Watts

>     Make a table of 4 zeros be static const, and update the cast where they are
>     used to also be static const. This should remove them from the global variable
>     list in bug 691207.

> [contrib/japanese/gdev10v.c]

2010-04-08T11:56:29.059369Z Robin Watts

>     Remove global variables in gdevcdj.c as part of the effort for bug 691207.

>     The ESC/P based printing code in gdevcdj.c uses various global variables; we
>     gather them into a struct here, and pass the struct between the 2 functions
>     concerned.

>     This device isn't used in the default build, so no point in testing with the
>     localcluster. Enabling it locally and doing before/after tests shows that
>     identical results are given for rendering tiger.eps.

>     A side effect of this commit is to remove the nasty shadowing of the img_rows
>     variable (doubly nasty because of it's use within a macro). This meant that I
>     had the code wrong for a while, so I know the test is actually testing the
>     right thing.

> [base/gdevcdj.c]

2010-04-07T17:18:46.406090Z Robin Watts

>     Remove global variable lbp8_end from gdevlbp8.c - it was permanently NULL
>     so removing it isn't hard, or risky. This will help towards the "No global
>     variables" goal (bug 691207).

>     No expected differences.

> [base/gdevlbp8.c]

2010-04-07T13:23:37.938542Z Chris Liddell

>     Revise the interface code and the use of FT so that both use GS managed
>     memory, rather than the stdlib memory routines (malloc/free and co.).

> [psi/fapi_ft.c]

2010-04-07T13:13:57.741241Z Robin Watts

>     Fix for bug 691228, problems with wide strokes with round caps/joins with
>     antialiasing enabled.

>     2 small problems in the same code. In the antialiased case, we stroke by
>     forming 2 paths (one up either side of the line) and then reverse one and
>     concatenate it. This should happen whenever we meet a closepath, but due to
>     a misplaced return, was being missed out in some round join cases.

>     Also, when using a round join in the case where 2 lines meet 'in-line' we
>     would inadvertently leave the point on the wrong side of the line.

>     No changes in localcluster testing as this only affects antialiased results
>     and that's not tested currently.

> [base/gxstroke.c]

2010-04-06T19:26:40.921375Z Robin Watts

>     Another attempt to fix Bug 691115. This corrects the clipping of a trapezoid
>     to a rectangle within the shading code. My previous attempt had failed to
>     allow for one case.

>     This causes 116 non-pdfwrite diffs, and 23 pdfwrite ones, all checked using
>     bmpcmp and found to be acceptable.

> [base/gxshade6.c]

2010-04-06T17:15:54.520182Z Michael Vrhel

>     Update of fuzzy to report average and max color errors.  This is useful
>     for continuous tone images only.  If the max error reaches the largest
>     possible, the calculations for these values are not performed.

> [toolbin/tests/fuzzy.c]

2010-04-06T14:14:43.252652Z Ken Sharp

>     Fix FAPI and FreeType interface.
>     The Metrics override was broken, the code to retrieve the /Metrics entries (1 to 4
>     values) stored the results in an array in a different order to the code which read the
>     values back.

>     In addition the FreeType code did not reset the 'glyph_metrics_index' if a glyph had no
>     metrics override, which could lead to us using the metrics overrides from a prior glyph
>     if we had already encountered one using an override.

> [psi/fapi_ft.c psi/zfapi.c]

2010-04-06T10:08:31.160988Z Ken Sharp

>     Fix FreeType.
>     The revision 11012 fixed a problem with an invalid font but accidentally introduced a
>     regression because an 'else' clause was missed.

> [freetype/src/psaux/psobjs.c]

2010-04-06T08:14:44.802475Z Chris Liddell

>     Resolve two compiler warnings - no behaviour change expected

> [psi/zfapi.c]

2010-04-05T23:50:00.539571Z Hin-Tak Leung

>     adding comments about using globs not expandable by shell; bug 691229

> [base/mkromfs.c]

2010-04-05T17:24:12.188391Z Hin-Tak Leung

>     adding escaped quotes around $0 in "basename $0" ; 2nd part of bug 691219

> [lib/pdf2ps lib/eps2eps lib/pfbtopfa lib/ps2epsi lib/ps2pdfwr lib/ps2ps lib/dumphint lib/ps2ps2 lib/dvipdf lib/pdfopt]

2010-04-05T17:22:10.077618Z Hin-Tak Leung

>     adding escaped quotes around $0 in "dirname $0" ; bug 691219

> [lib/printafm lib/eps2eps lib/pdf2dsc lib/gsbj lib/ps2epsi lib/gsdj lib/dumphint lib/gsnd lib/font2c lib/pdfopt lib/pdf2ps lib/ps2pdf lib/gslj lib/pfbtopfa lib/bdftops lib/ps2pdf12 lib/ps2pdf13 lib/ps2pdf14 lib/gslp lib/wftopfa lib/ps2pdfwr lib/ps2ps lib/pphs lib/pf2afm lib/gsdj500]

2010-04-05T17:13:34.259627Z Hin-Tak Leung

>     adding reference to msmin04, msgoth04 and ngulim,nbantang; fixes the remaining issues in bug 689456

> [lib/mkcidfm.ps]

2010-04-05T15:48:47.768122Z Ken Sharp

>     Fix line endings. The previous commit (11012) accidentally used DOS line endings which
>     made it appear every line in the file was different.

> [freetype/src/psaux/psobjs.c]

2010-04-05T15:31:11.441559Z Ken Sharp

>     Fix FreeType
>     When using bitmaps from a TrueType/Type42 font FreeType uses a heuristic approach to
>     synthesize vertical metrics for the glyphs, including a horizontal advance. As in the
>     past, this works well as long as the client knows whether the advance direction is
>     horizontal or vertical and uses the correct advance.

>     However we don't know that, so we don't want the vertical advance.

>     Its easiest jut to have FreeType ignore embedded bitmaps and use the outlines, in which
>     case we don't get the invented vertical advance. Not only that but the rendered bitmap
>     is a better match for the cases where we don't have a pre-built bitmap, so consistency
>     is improved with this patch as well.

> [psi/fapi_ft.c]

2010-04-05T15:27:25.365922Z Ken Sharp

>     Fix FreeType
>     The test file objlune_font2_mine.ps contains a Type 1 font which has a technically
>     invalid glyph. The glyph executes a 'lineto' class operation before a 'moveto' class
>     operation.

>     Although illegal it seems that all other PostScript RIPs ignore this requirement, this
>     patch removes the error check in FreeType to conform with other interpreters.

> [freetype/src/psaux/psobjs.c]

2010-04-05T11:33:32.361294Z Chris Liddell

>     Update the to latest FT code from the FT git repository.

> [freetype/src/pshinter/pshglob.c freetype/src/base/ftpfr.c freetype/src/pshinter/pshglob.h freetype/src/type1/t1objs.c freetype/docs/DEBUG freetype/src/type1/t1objs.h freetype/docs/INSTALL.CROSS freetype/src/truetype/ttgload.c freetype/src/truetype/ttgload.h freetype/src/tools/ftrandom/ftrandom.c freetype/devel/ft2build.h freetype/src/tools/docmaker/formatter.py freetype/src/autofit/Jamfile freetype/src/bdf/module.mk freetype/include/freetype/config/ftheader.h freetype/src/cff/Jamfile freetype/src/cff/cffparse.c freetype/src/raster/ftraster.c freetype/src/cff/cffparse.h freetype/src/cff/cffcmap.c freetype/src/raster/ftraster.h freetype/src/cff/cffcmap.h freetype/src/raster/ftrend1.c freetype/include/freetype/internal/services/svttglyf.h freetype/src/raster/ftrend1.h freetype/builds/wince/vc2005-ce/freetype.vcproj freetype/docs/INSTALL.ANY freetype/src/psnames/module.mk freetype/src/base/ftutil.c freetype/src/autofit/afglobal.c freetype/src/cache/ftcsbits.c freetype/src/autofit/afglobal.h freetype/src/pcf/rules.mk freetype/src/base/ftsystem.c freetype/src/cache/ftcsbits.h freetype/src/psaux/psaux.c freetype/src/cff/module.mk freetype/src/pshinter/rules.mk freetype/src/pcf/pcfread.c freetype/src/bdf/bdflib.c freetype/src/pcf/pcfread.h freetype/include/freetype/ftcache.h freetype/src/raster/Jamfile freetype/src/gzip/rules.mk freetype/src/pshinter/pshalgo.c freetype/include/freetype/ftincrem.h freetype/include/freetype/internal/services/svcid.h freetype/src/pshinter/pshalgo.h freetype/src/psnames/psnamerr.h freetype/src/tools/test_afm.c freetype/src/cache/ftccache.c freetype/src/cache/ftcmru.c freetype/include/freetype/config/ftstdlib.h freetype/src/cid/cidtoken.h freetype/include/freetype/freetype.h freetype/vms_make.com freetype/src/cache/ftccache.h freetype/src/cache/ftcmru.h freetype/docs/INSTALL.UNIX freetype/src/tools/cordic.py freetype/src/pfr/Jamfile freetype/src/pfr/pfr.c freetype/src/pfr/pfrload.c freetype/src/pfr/pfrload.h freetype/include/freetype/fterrdef.h freetype/src/type1/t1gload.c freetype/src/base/ftbbox.c freetype/src/otvalid/otvgdef.c freetype/src/type1/t1gload.h freetype/include/freetype/ftsystem.h freetype/src/bdf/bdferror.h freetype/src/gxvalid/rules.mk freetype/src/pcf/pcf.c freetype/src/bdf/Jamfile freetype/src/gxvalid/gxvbsln.c freetype/include/freetype/internal/services/svotval.h freetype/src/otvalid/rules.mk freetype/src/pfr/pfrdrivr.c freetype/src/pcf/pcf.h freetype/src/type1/Jamfile freetype/src/pfr/pfrdrivr.h freetype/src/pcf/pcferror.h freetype/src/sfnt/ttsbit0.c freetype/src/base/ftmac.c freetype/src/base/ftgloadr.c freetype/src/base/ftbase.c freetype/builds/win32/vc2005/freetype.vcproj freetype/src/base/ftbase.h freetype/src/gxvalid/gxvmort0.c freetype/src/bdf/bdf.c freetype/src/bdf/bdf.h freetype/src/gxvalid/gxvalid.c freetype/src/cff/cff.c freetype/include/freetype/internal/psaux.h freetype/src/gxvalid/gxvalid.h freetype/autogen.sh freetype/src/base/fttype1.c freetype/src/autofit/afmodule.c freetype/src/autofit/afmodule.h freetype/src/pfr/pfrcmap.c freetype/src/pfr/pfrcmap.h freetype/src/psaux/Jamfile freetype/src/cff/cffpic.c freetype/src/base/ftdebug.c freetype/src/gzip/inflate.c freetype/src/cff/cffpic.h freetype/src/type1/t1driver.c freetype/src/otvalid/otvbase.c freetype/include/freetype/ftmoderr.h freetype/src/gxvalid/gxvopbd.c freetype/src/type1/t1driver.h freetype/src/base/basepic.c freetype/src/type1/t1parse.c freetype/src/otvalid/otvmath.c freetype/src/gxvalid/gxvmort1.c freetype/src/base/basepic.h freetype/src/psnames/rules.mk freetype/src/type1/t1parse.h freetype/src/pcf/Jamfile freetype/src/gzip/Jamfile freetype/src/base/ftbdf.c freetype/src/type1/t1afm.c freetype/src/raster/module.mk freetype/src/cid/cidobjs.c freetype/include/ft2build.h freetype/include/freetype/internal/services/svgxval.h freetype/include/freetype/internal/ftrfork.h freetype/src/type1/t1tokens.h freetype/src/type1/t1afm.h freetype/src/pshinter/pshrec.c freetype/src/cid/cidobjs.h freetype/src/pshinter/pshrec.h freetype/src/truetype/ttobjs.c freetype/src/autofit/autofit.c freetype/include/freetype/ftchapters.h freetype/src/type1/t1errors.h freetype/include/freetype/ftlzw.h freetype/src/truetype/ttobjs.h freetype/src/otvalid/otvgsub.c freetype/src/tools/apinames.c freetype/src/winfonts/fnterrs.h freetype/src/cache/ftcache.c freetype/include/freetype/ftglyph.h freetype/builds/win32/vc2005/index.html freetype/src/raster/rasterrs.h freetype/src/autofit/aflatin2.c freetype/src/type42/Jamfile freetype/src/base/ftpic.c freetype/src/autofit/aflatin2.h freetype/include/freetype/fttypes.h freetype/src/cache/ftcglyph.c freetype/src/gxvalid/gxvmort2.c freetype/src/pshinter/pshinter.c freetype/src/cache/ftcglyph.h freetype/src/tools/test_bbox.c freetype/src/cache/Jamfile freetype/src/type42/t42types.h freetype/include/freetype/internal/services/svpsinfo.h freetype/src/gxvalid/gxvmort.c freetype/src/raster/rastpic.c freetype/builds/win32/vc2008/index.html freetype/src/gxvalid/gxvmort.h freetype/src/gxvalid/README freetype/src/tools/docmaker/docbeauty.py freetype/src/raster/rastpic.h freetype/src/gzip/ftgzip.c freetype/include/freetype/ftcid.h freetype/include/freetype/internal/services/svpfr.h freetype/src/sfnt/module.mk freetype/src/type1/t1load.c freetype/docs/INSTALL freetype/src/gzip/inftrees.c freetype/docs/INSTALL.VMS freetype/src/type1/t1load.h freetype/src/gzip/inftrees.h freetype/src/pfr/pfrsbit.c freetype/src/cff/cfftoken.h freetype/src/gxvalid/gxvfeat.c freetype/include/freetype/internal/ftgloadr.h freetype/docs/PROBLEMS freetype/src/pfr/pfrsbit.h freetype/src/gxvalid/gxvfeat.h freetype/src/truetype/Jamfile freetype/src/gxvalid/gxvkern.c freetype/docs/INSTALL.MAC freetype/src/cid/Jamfile freetype/src/base/ftglyph.c freetype/include/freetype/ftmm.h freetype/src/otvalid/otverror.h freetype/docs/UPGRADE.UNIX freetype/src/autofit/afcjk.c freetype/src/autofit/aftypes.h freetype/src/psaux/afmparse.c freetype/src/sfnt/sfdriver.c freetype/src/autofit/afcjk.h freetype/src/sfnt/sfobjs.c freetype/src/base/ftobjs.c freetype/src/psaux/afmparse.h freetype/src/sfnt/sfdriver.h freetype/src/sfnt/sfobjs.h freetype/src/pfr/rules.mk freetype/src/psaux/module.mk freetype/src/base/ftstroke.c freetype/src/base/ftfstype.c freetype/docs/GPL.TXT freetype/src/base/ftbitmap.c freetype/src/pshinter/pshpic.c freetype/src/pshinter/pshpic.h freetype/src/psnames/pstables.h freetype/src/sfnt/rules.mk freetype/builds/wince/vc2005-ce/index.html freetype/src/autofit/afpic.c freetype/docs/PATENTS freetype/docs/raster.txt freetype/src/autofit/afpic.h freetype/src/cff/cffdrivr.c freetype/src/otvalid/otvgpos.c freetype/src/cid/cidriver.c freetype/src/cff/cffdrivr.h freetype/include/freetype/ftgasp.h freetype/src/autofit/afindic.c freetype/src/otvalid/otvgpos.h freetype/src/cid/cidriver.h freetype/src/autofit/afindic.h freetype/docs/INSTALL.GNU freetype/src/winfonts/module.mk freetype/src/sfnt/ttkern.c freetype/src/gzip/infutil.c freetype/src/sfnt/sferrors.h freetype/src/psaux/t1cmap.c freetype/src/sfnt/ttkern.h freetype/src/gxvalid/gxvmort4.c freetype/src/gzip/infutil.h freetype/include/freetype/ttnameid.h freetype/src/psaux/t1cmap.h freetype/src/gzip/zconf.h freetype/src/base/ftpatent.c freetype/src/truetype/rules.mk freetype/src/base/ftadvanc.c freetype/src/tools/docmaker/tohtml.py freetype/src/otvalid/otvalid.c freetype/src/otvalid/otvcommn.c freetype/include/freetype/config/ftmodule.h freetype/include/freetype/ftxf86.h freetype/src/otvalid/otvalid.h freetype/src/otvalid/otvcommn.h freetype/include/freetype/internal/ftserv.h freetype/Jamrules freetype/src/type1/module.mk freetype/src/base/ftapi.c freetype/docs/VERSION.DLL freetype/docs/LICENSE.TXT freetype/include/freetype/ftstroke.h freetype/include/freetype/ftlist.h freetype/include/freetype/ftbitmap.h freetype/src/type42/t42parse.c freetype/src/bdf/bdfdrivr.c freetype/modules.cfg freetype/builds/win32/visualce/freetype.dsp freetype/src/cid/ciderrs.h freetype/ChangeLog.20 freetype/ChangeLog.21 freetype/src/type42/t42parse.h freetype/ChangeLog.22 freetype/src/bdf/bdfdrivr.h freetype/include/freetype/tttables.h freetype/src/cid/module.mk freetype/src/autofit/afdummy.c freetype/src/tools/chktrcmp.py freetype/include/freetype/internal/services/svxf86nm.h freetype/src/autofit/afdummy.h freetype/include/freetype/internal/ftobjs.h freetype/src/pcf/pcfdrivr.c freetype/src/gxvalid/gxvmort5.c freetype/src/pcf/pcfdrivr.h freetype/src/psnames/Jamfile freetype/docs/MAKEPP freetype/Jamfile freetype/builds/win32/visualce/index.html freetype/include/freetype/ftotval.h freetype/src/tools/test_trig.c freetype/src/tools/docmaker/content.py freetype/include/freetype/ftadvanc.h freetype/include/freetype/internal/services/svpostnm.h freetype/src/cff/rules.mk freetype/src/gzip/zlib.h freetype/src/type42/t42error.h freetype/src/smooth/module.mk freetype/src/sfnt/sfnt.c freetype/src/autofit/afloader.c freetype/src/otvalid/Jamfile freetype/include/freetype/internal/services/svkern.h freetype/src/autofit/afloader.h freetype/src/cache/ftcerror.h freetype/src/psaux/psobjs.c freetype/src/sfnt/Jamfile freetype/src/gzip/infcodes.c freetype/src/truetype/ttpic.c freetype/src/psaux/psobjs.h freetype/src/base/ftcalc.c freetype/src/pshinter/pshnterr.h freetype/src/gzip/infcodes.h freetype/src/truetype/ttpic.h freetype/src/bdf/rules.mk freetype/include/freetype/internal/tttypes.h freetype/src/gxvalid/gxvmorx0.c freetype/include/freetype/internal/ftvalid.h freetype/include/freetype/fterrors.h freetype/builds/win32/visualc/freetype.dsp freetype/src/gzip/infblock.c freetype/src/base/ftlcdfil.c freetype/include/freetype/internal/ftmemory.h freetype/src/type1/type1.c freetype/include/freetype/ftpfr.h freetype/src/gzip/infblock.h freetype/src/pshinter/module.mk freetype/src/tools/ftrandom/Makefile freetype/src/type42/rules.mk freetype/src/gxvalid/gxvmorx.c freetype/docs/formats.txt freetype/src/cff/cffobjs.c freetype/src/smooth/ftsmooth.c freetype/src/gxvalid/gxvmorx.h freetype/src/cff/cffobjs.h freetype/include/freetype/ftoutln.h freetype/src/smooth/ftsmooth.h freetype/include/freetype/ftsynth.h freetype/src/tools/ftrandom/README freetype/src/winfonts/rules.mk freetype/docs/CHANGES freetype/src/base/ftotval.c freetype/include/freetype/tttags.h freetype/src/truetype/module.mk freetype/include/freetype/internal/autohint.h freetype/src/tools/glnames.py freetype/src/sfnt/ttload.c freetype/src/gxvalid/gxvfgen.c freetype/src/sfnt/ttload.h freetype/src/pfr/pfrtypes.h freetype/src/gxvalid/gxvtrak.c freetype/src/pcf/README freetype/include/freetype/internal/ftdriver.h freetype/include/freetype/ftgzip.h freetype/src/base/ftrfork.c freetype/include/freetype/internal/services/svbdf.h freetype/src/smooth/rules.mk freetype/src/gxvalid/gxvmorx1.c freetype/src/base/rules.mk freetype/src/autofit/afwarp.c freetype/src/cid/cidload.c freetype/include/freetype/ftgxval.h freetype/src/autofit/afwarp.h freetype/include/freetype/internal/services/svgldict.h freetype/src/cid/cidload.h freetype/src/gxvalid/gxvprop.c freetype/include/freetype/ftlcdfil.h freetype/src/tools/docmaker/sources.py freetype/src/type42/type42.c freetype/src/raster/rules.mk freetype/src/truetype/ttgxvar.c freetype/src/pshinter/Jamfile freetype/src/truetype/ttdriver.c freetype/src/gxvalid/Jamfile freetype/src/truetype/ttgxvar.h freetype/src/pfr/pfrgload.c freetype/src/Jamfile freetype/src/pshinter/pshmod.c freetype/src/truetype/ttdriver.h freetype/src/autofit/aflatin.c freetype/src/pfr/pfrgload.h freetype/src/base/ftsnames.c freetype/src/pshinter/pshmod.h freetype/include/freetype/internal/ftcalc.h freetype/include/freetype/ftrender.h freetype/src/base/ftgasp.c freetype/src/autofit/aflatin.h freetype/src/base/ftdbgmem.c freetype/docs/TRUETYPE freetype/src/smooth/ftspic.c freetype/include/freetype/t1tables.h freetype/src/cid/cidgload.c freetype/src/base/ftoutln.c freetype/src/smooth/ftspic.h freetype/src/base/ftsynth.c freetype/src/base/ftwinfnt.c freetype/src/cid/cidgload.h freetype/include/freetype/internal/internal.h freetype/src/sfnt/ttbdf.c freetype/src/sfnt/ttbdf.h freetype/src/lzw/ftlzw.c freetype/builds/win32/vc2008/freetype.vcproj freetype/src/truetype/ttpload.c freetype/src/gxvalid/gxvmorx2.c freetype/src/truetype/ttinterp.c freetype/src/lzw/rules.mk freetype/src/truetype/ttpload.h freetype/src/truetype/ttinterp.h freetype/src/base/ftxf86.c freetype/src/base/ftstream.c freetype/src/sfnt/ttcmap.c freetype/include/freetype/internal/services/svmm.h freetype/src/sfnt/ttcmap.h freetype/src/gxvalid/module.mk freetype/src/gxvalid/gxvjust.c freetype/src/truetype/tterrors.h freetype/src/pcf/pcfutil.c freetype/src/cid/type1cid.c freetype/src/pcf/pcfutil.h freetype/src/base/ftgxval.c freetype/include/freetype/internal/pshints.h freetype/src/sfnt/ttmtx.c freetype/src/psnames/psmodule.c freetype/src/sfnt/ttmtx.h freetype/src/psaux/psauxmod.c freetype/builds/wince/vc2008-ce/index.html freetype/src/pfr/module.mk freetype/src/psnames/psmodule.h freetype/src/base/ftcid.c freetype/include/freetype/ftsnames.h freetype/src/psaux/psauxmod.h freetype/README.git freetype/configure freetype/src/sfnt/ttcmapc.h freetype/src/gzip/inffixed.h freetype/include/freetype/ftwinfnt.h freetype/src/pfr/pfrobjs.c freetype/src/base/Jamfile freetype/include/freetype/ftimage.h freetype/docs/release freetype/src/pfr/pfrobjs.h freetype/src/lzw/ftzopen.c freetype/src/truetype/truetype.c freetype/src/lzw/Jamfile freetype/Makefile freetype/src/lzw/ftzopen.h freetype/src/base/fttrigon.c freetype/src/autofit/afhints.c freetype/src/autofit/afhints.h freetype/builds/win32/visualce/freetype.vcproj freetype/include/freetype/ftmac.h freetype/src/psaux/rules.mk freetype/src/type1/rules.mk freetype/src/cache/ftcimage.c freetype/src/psnames/pspic.c freetype/src/cache/ftcimage.h freetype/include/freetype/config/ftconfig.h freetype/src/cid/cidparse.c freetype/src/psnames/pspic.h freetype/src/cff/cfferrs.h freetype/src/cid/cidparse.h freetype/src/smooth/Jamfile freetype/src/gzip/adler32.c freetype/include/freetype/internal/sfnt.h freetype/docs/reference/README freetype/src/winfonts/winfnt.c freetype/devel/ftoption.h freetype/src/sfnt/sfntpic.c freetype/src/gzip/zutil.c freetype/src/winfonts/winfnt.h freetype/src/smooth/smooth.c freetype/src/sfnt/sfntpic.h freetype/src/gzip/zutil.h freetype/src/smooth/ftgrays.c freetype/src/raster/ftmisc.h freetype/src/gxvalid/gxvmorx4.c freetype/src/winfonts/Jamfile freetype/include/freetype/internal/pcftypes.h freetype/src/smooth/ftgrays.h freetype/src/pfr/pfrerror.h freetype/src/raster/raster.c freetype/include/freetype/internal/services/svwinfnt.h freetype/docs/CUSTOMIZE freetype/builds/unix/configure.raw freetype/include/freetype/internal/t1types.h freetype/builds/wince/vc2008-ce/freetype.vcproj freetype/src/otvalid/module.mk freetype/ChangeLog freetype/include/freetype/internal/services/svpscmap.h freetype/include/freetype/fttrigon.h freetype/docs/FTL.TXT freetype/src/cache/ftcmanag.c freetype/src/sfnt/ttsbit.c freetype/README freetype/src/cache/ftcmanag.h freetype/src/sfnt/ttsbit.h freetype/src/type42/t42drivr.c freetype/src/psaux/psconv.c freetype/include/freetype/ftbdf.h freetype/include/freetype/ftsizes.h freetype/src/type42/t42drivr.h freetype/src/psaux/psconv.h freetype/include/freetype/internal/services/svtteng.h freetype/include/freetype/internal/ftdebug.h freetype/src/tools/docmaker/docmaker.py freetype/src/gxvalid/gxverror.h freetype/src/autofit/module.mk freetype/include/freetype/internal/ftstream.h freetype/src/cff/cfftypes.h freetype/src/gxvalid/gxvmorx5.c freetype/src/gxvalid/gxvmod.c freetype/include/freetype/internal/ftpic.h freetype/src/gxvalid/gxvmod.h freetype/include/freetype/ftbbox.h freetype/src/otvalid/otvmod.c freetype/src/psnames/psnames.c freetype/src/cid/rules.mk freetype/src/psaux/psauxerr.h freetype/src/type42/t42objs.c freetype/src/otvalid/otvmod.h freetype/src/cache/ftccmap.c freetype/src/cache/ftcbasic.c freetype/src/type42/t42objs.h freetype/src/smooth/ftsmerrs.h freetype/include/freetype/internal/services/svttcmap.h freetype/version.sed freetype/src/psaux/t1decode.c freetype/src/autofit/rules.mk freetype/src/tools/docmaker/utils.py freetype/builds/win32/visualc/index.html freetype/src/psaux/t1decode.h freetype/src/type42/module.mk freetype/src/otvalid/otvjstf.c freetype/src/autofit/aferrors.h freetype/src/cff/cffgload.c freetype/src/gxvalid/gxvlcar.c freetype/include/freetype/internal/services/svsfnt.h freetype/src/base/ftinit.c freetype/src/bdf/README freetype/src/cache/ftccback.h freetype/src/cff/cffgload.h freetype/src/base/ftmm.c freetype/src/pcf/module.mk freetype/docs/TODO freetype/src/tools/Jamfile freetype/src/autofit/afangles.c freetype/include/freetype/config/ftoption.h freetype/src/cff/cffload.c freetype/src/gxvalid/gxvcommn.c freetype/src/autofit/afangles.h freetype/src/cff/cffload.h freetype/src/gxvalid/gxvcommn.h freetype/src/sfnt/ttpost.c freetype/src/sfnt/ttpost.h freetype/src/cache/rules.mk freetype/include/freetype/ttunpat.h freetype/include/freetype/ftmodapi.h freetype/include/freetype/internal/fttrace.h]

2010-04-05T10:03:59.155794Z Chris Liddell

>     Fix the FAPI implementation of finding the appropriate bytes for a given
>     character code from an array of strings representing a CMap.

> [psi/zfapi.c]

2010-04-02T12:31:23.439338Z Ken Sharp

>     'Fix' FAPI with FreeType.

>     FreeType's hinting is worse than useless for type 1 fonts, its actually harmful. It
>     distorts the glyph shape because it hints an unscaled outline. While it would be best
>     to fix FreeType's hinting this is a large project. For now this patch disables FreeType
>     hinting when handling type 1 fonts.

>     This resolves many spacing issues as well as fixing the stroke/fill mismatch with
>     ia3z3519.pdf and the incorrectly scaled outline in womanface.pdf.

> [psi/fapi_ft.c]

2010-04-02T09:19:23.286738Z Chris Liddell

>     Extend Ken's change to avoid using FT's "synthetic" vertical metrics
>     for Type42 fonts to cover all fonts using TTF outlines (so CIDType 2 fonts, as
>     well).

> [psi/fapi_ft.c]

2010-04-02T09:06:53.941441Z Ken Sharp

>     Fix a bug in the FreeType scan conversion.

>     A multiply and divide to calculate the slope of a line did not account for the
>     possibility of overflow during multiplication. Using the supplied SMulDiv routine fixes
>     the problem.

>     The patch has been supplied upstream to the FreeType development team.

> [freetype/src/raster/ftraster.c]

2010-04-01T13:32:52.153614Z Robin Watts

>     Slight tidy up to gs_2_colors code: Given that the cie_joint_caches_alt is
>     now kept in the imager state rather than the graphics state, move the
>     reference counting/initialisation for the same into the imager state
>     too. No difference in operation, but just a bit tidier.

>     No expected differences, though the cluster may show 2colCIEtest.pdf as
>     failing if it hasn't propogated around the nodes yet.

> [base/gsstate.c base/gsistate.c]

2010-03-31T15:43:06.179195Z Chris Liddell

>     Bounds check the correct object when looking up a CID map

> [psi/zfapi.c]

2010-03-31T14:40:31.704728Z Chris Liddell

>     Correct a logical error/typo in the fallback to non-hinted condition.

> [psi/fapi_ft.c]

2010-03-31T13:22:01.442343Z Chris Liddell

>     Prevent applying the nominalWidthX for T2 fonts, when FT already applies
>     it for us. Previously, the code was actually erroneously adding the
>     defaultWidthX. Since this use of nominalWidthX *may* be renderer dependent,
>     it is now controlled by the can_replace_metrics() call.

> [psi/zfapi.c]

2010-03-31T13:16:41.790764Z Chris Liddell

>     In the even a glyph name is not found in the CharStrings dictionary, fall
>     back to using the .notdef (instead of returning an error).

> [psi/zfapi.c]

2010-03-31T13:07:44.152960Z Chris Liddell

>     For certain errors from FT, retry interpretting the glyph without hinting - this more
>     closely matches the existing behaviour.

> [psi/fapi_ft.c]

2010-03-31T11:32:10.299125Z Robin Watts

>     Remove unused variable. No expected differences.

> [base/gsstate.c]

2010-03-31T01:20:18.778513Z Ray Johnston

>     Temporary reversion of previous mkromfs commit to remove -g until it works
>     correctly (fooled by a GS_LIB environment variable during testing)

> [psi/psromfs.mak]

2010-03-30T22:59:53.311321Z Ray Johnston

>     Implement '-g' option in mkromfs to fold in some of the older 'genint'
>     functions (collect all init files into a single gs_init.ps, strip
>     whitespace and comments). Also change mkromfs so that wildcard expansion
>     must be specified using '*' on the command line which also means that
>     single explicit files can now be put into the %rom% file system.

>     Add many missed dependencies to the list for the 'gsromfs.c' %rom% file
>     system (CMap, ColorSpace, Decoding, Encoding, Font, IdiomSet, ProcSet,
>     SubstCID) and separate out miscellenaeous files.

>     Remove old geninit references from makefiles: psi/int.mak psi/os2.mak,
>     base/bcwin32.mak, base/msvctail.mak, base/winlib.mak, base/macos-mcp.mak,
>     base/openvms.mak, base/lib.mak, base/unix-aux.mak base/watcw32.mak,
>     base/wctail.mak

> [base/wctail.mak psi/os2.mak base/lib.mak base/bcwin32.mak base/openvms.mak base/mkromfs.c base/gs.mak base/watcw32.mak psi/psromfs.mak psi/int.mak base/unix-aux.mak base/macos-mcp.mak base/msvctail.mak]

2010-03-30T18:40:34.337393Z Robin Watts

>     Fix bug 691132 by ensuring that whenever we set a line width, we set
>     it to the absolute value of the line width. This seems consistent with
>     PDF, and cures the clipping problem in PCL referred to by the bug.

>     No expected differences.

> [base/gxline.h]

2010-03-30T14:46:56.884951Z Robin Watts

>     In the gs_2_colors branch I had made 2 copies of the color state and swapped
>     between them. I had included dev_ht as part of this 'split' state, which
>     was a significant contributor to the slowdown due to it forcing repeated
>     writing of the halftone data to the clist. Also, it required significant
>     extra work on every setscreen or setcolorscreen operation.

>     Discussions with Henry/Ray/Kens et al lead to the realisation this wasn't
>     required. This patch therefore backs out the dev_ht split, and the changes
>     to zsetscreen and zsetcolorscreen. Additional code is however required to
>     clear the 'alternative' dev_color when a halftone is installed to stop the
>     'swapped out' color pointing to an illegal halftone cache.

>     This runs through local testing with no diffs showing (though some
>     strangeness was observed with an earlier version of this patch in
>     regression testing - Marcos has captured this with bug 691223).

>     This seems to have helped with the largest slowdowns, but there are still
>     significant differences in some cases. Very preliminary investigations seem
>     to show more time being spent in the interpreter/gc mechanism. Continuing
>     to investigate.

> [base/gsstate.c base/gxistate.h base/gsht.c base/gxdcolor.h base/gzstate.h psi/zht.c psi/zht1.c]

2010-03-30T10:16:57.091024Z Ken Sharp

>     New Fontmap files for the URW fonts, both type 1 and TrueType formats.

>     The file Fontmap.URW-136.T1 contains definitions for the type 1 fonts (the URW PFB
>     fonts must be in the search path).

>     The file Fontmap.URW-136.TT contains definitions for the TrueType fonts (the URW TTF
>     fonts must be in the search path).

>     Currently neither of these work 100% because of problems with the URW font sets
>     (several incorrectly named fonts, and in one case an illegal type 1 font)

> [lib/Fontmap.URW-136.T1 lib/Fontmap.URW-136.TT]

2010-03-29T19:10:49.447074Z Alex Cherepanov

>     Drop 'loca' entries that point beyond 'glyf' table during re-spliting
>     sfnts glyfs strings. Bug 691221.

> [Resource/Init/gs_ttf.ps]

2010-03-29T07:52:49.284823Z Chris Liddell

>     Change the FT interface code so we always use metrics retrieved from Freetype,
>     rather than attempting to "fabricate" metrics (which have already
>     been handled correctly by FT).

> [psi/fapi_ft.c]

2010-03-27T01:59:55.922560Z Robin Watts

>     Fix compilation error in pngs2html.pl (forgot to define variable).

> [toolbin/localcluster/pngs2html.pl]

2010-03-26T10:28:56.873949Z Masaki Ushizaka

>     A leftover from r10603 (Makefile change).

> [base/lib.mak]

2010-03-26T00:20:16.302228Z Robin Watts

>     Updated localcluster bmpcmp html generation script. Bitmaps produced are now
>     zoomable.

> [toolbin/localcluster/pngs2html.pl]

2010-03-24T12:47:59.902550Z Robin Watts

>     Fix for bug 691115.

>     In some circumstances, the shading code can get all the way to the point of
>     marking the screen/page without ever clipping to the relavent region. This
>     produces cases where we "draw outside the lines". Often this is masked by
>     the fact that we only ever draw as far out of the lines as would be covered
>     by an area of constant color (typically a small area).

>     The fix for this is to spot the unclipped case when we come to render
>     trapezoids to the screen, and to clip the trapezoid into (at most) 3
>     smaller trapezoids.

>     This causes 104 non-pdfwrite differences, and 24 pdfwrite ones. Examination
>     using localcuster bmpcmp shows them all to be acceptable.

> [base/gxshade6.c]

2010-03-24T12:05:47.469905Z Robin Watts

>     Tweak to bmpcmp: Darken the third image (the diff image) to make changes
>     stand out better.

> [toolbin/bmpcmp.c]

2010-03-24T00:10:27.875727Z Robin Watts

>     Correct DOS line endings in bmpcmp.c.

>     Fix bug whereby areas with no changes in were still be saved out.

> [toolbin/bmpcmp.c]

2010-03-23T19:14:32.177681Z Robin Watts

>     Correct problem with bmpcmp whereby certain sizes of changed areas within
>     images could cause overlapping output bitmaps. This causes problems with
>     the output of bitmaps now due to the new 'in-place' generation of the diff
>     bitmap. Fixed by choosing sizes more smartly.

> [toolbin/bmpcmp.c]

2010-03-23T09:02:16.120692Z Till Kamppeter

>     CUPS Raster output device: Error out correctly with the return_error() macro
>     and not with "gs_exit(); exit()", force banding mode as there are
>     files which do not render otherwise (Bug #691170).

> [cups/gdevcups.c]

2010-03-23T00:06:59.853037Z Till Kamppeter

>     Code clean-ups in the "cups" output device to fix the segfaults
>     in bug #691170 and bug #691014 (but does not fix the bugs yet).

> [cups/gdevcups.c]

2010-03-22T14:18:42.718453Z Chris Liddell

>     Handle CID fonts whose GDBytes != 2 - previously GDBytes was hardcoded as 2.

> [psi/zfapi.c]

2010-03-22T06:43:08.806820Z Marcos H. Woehrmann

>     Added the ability to specify bmpcmp options when running clusterpush.pl, e.g.:

>     clusterpush.pl bmpcmp -w 9 -t 10

>     No validation is done on the options; bad options will result in no bmpcmp output being generated.

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

2010-03-21T05:01:50.135122Z Marcos H. Woehrmann

>     Fixed maxdiffs argument in bmpcmp.c (was acting as maxpage).

> [toolbin/bmpcmp.c]

2010-03-21T03:23:53.245152Z Marcos H. Woehrmann

>     Fixed a couple of compiler warnings in bmpcmp.c

> [toolbin/bmpcmp.c]

2010-03-19T18:30:04.447497Z Ralph Giles

>     Compute AES cypher tables at compile time instead of run time.

>     The aes implementation needs some tables of data to perform its
>     calculations. In a thread-safety review, Henry spotted that the
>     tables were global variables with no mutex isolation.

>     I believe this is actually ok. There is a static flag marking whether
>     the tables are initialized. If they are not, a call to aes_setkey_*
>     will invoke aes_gen_tables to initialize them, then set the flag.
>     However, aes_gen_tables operates deterministically, always writing
>     the same data sequence to the globals. So while there is a race
>     where two threads could be executing aes_gen_tables at the same time,
>     or while another thread is accessing the same tables, there is no
>     read-modify-write step which could create inconsistent data.

>     Nevertheless, the tables are small relative to our application, and
>     there is a compile time option XYSSL_AES_ROM_TABLES which generates
>     the data at compile time and stores it static const. This commit
>     turns on that option, allowing the compiler to put the data in a
>     non-writable segment and making the careful thread safety analysis
>     above unnecessary.

>     There should be no difference in behaviour, and Henry has verified
>     that the two code paths result in identical table data.

> [base/aes.c]

2010-03-18T11:39:38.599047Z Ken Sharp

>     Update the list of face substitutions in .substitutefaces to include all the fonts we
>     define in Fontmap.GS (if not already defined).

>     Bug #691180, if we have a font defined in the Fontmap then we don't use the additional
>     information in a PDF file FontDescriptor. Instead we stick with whatever font the PS
>     substitution comes up with (if the font is not present). If a member of the family is
>     not defined we do use the FontDescriptor. This can lead to different choices for the
>     substitute font. By defining the font in the substitutefaces array we can attempt to get
>     a consistent result.

>     This *will* lead to differences in the regression suite as we are now substituting
>     different fonts for some missing faces. Apparently only with the test file for this
>     bug though.

> [Resource/Init/gs_fonts.ps]

2010-03-18T00:57:10.529905Z Robin Watts

>     Merge gs_2_colors branch down to trunk.

>     This adds a new set of color state information to the graphics/imager
>     state, along with a new non-standard postscript operator .swapcolors to
>     toggle between them.

>     The Postscript interpreter is updated to use one set of color information
>     for stroking, and the other for all non-stroking colors.

>     This produces differences in just 2 pdfwrite tests, due to rounding errors
>     due to changes in the way pdf with non-zero rendering modes is emitted now.

> [psi/zcolor.c base/gsdps1.c base/gdevpdft.c base/gxccache.c /trunk/gs base/gspaint.c base/gscsepr.c base/gsimage.c base/gxchar.c base/gsptype1.c base/gxcmap.c psi/interp.c base/gzstate.h psi/dmmain.c base/gscspace.c base/gscolor1.c base/gscdevn.c base/gscolor2.c base/gscie.c base/gxistate.h psi/psromfs.mak psi/dxmain.c base/gxcspace.h base/gxhldevc.c psi/dxmainc.c psi/dmmain.r Resource/Init/pdf_draw.ps psi/zht1.c base/gscolor.c psi/zicc.c psi/zchar1.c base/gxpaint.c base/gsstate.c Resource/Init/pdf_ops.ps psi/zcie.c base/gstext.c Resource/Init/pdf_font.ps base/gstrans.c psi/zht.c base/gsequivc.c base/gxdcolor.h psi/igstate.h base/gspcolor.c]

2010-03-17T21:41:13.190501Z Robin Watts

>     bmpcmp tweak to allow maximum/minimum bitmap sizes to be set from the
>     command line.

> [toolbin/bmpcmp.c]

2010-03-17T20:12:25.972208Z Robin Watts

>     MSVC whinges when asked to shift by 32 or more bits at once. Simple tweaks
>     to fool the compiler and eliminate warnings.

>     No expected differences.

> [base/gdevm64.c base/gdevm56.c base/gdevm48.c base/gdevm40.c base/gxclrast.c]

2010-03-17T18:54:12.480084Z Robin Watts

>     Tweak to gxcmap.c to remove warnings about shifting by more than 32 bits on
>     MSVC builds.

>     No expected differences.

> [base/gxcmap.c]

2010-03-17T17:30:27.541399Z Robin Watts

>     Revised bmpcmp.
>     * Redone command line handling
>     * Ability to read PAMs (so we can read CMYK stuff now)
>     * "Fuzzy" behaviour (both compatible and exhaustive modes)
>     * New behaviour using map bitmap to avoid rediffing multiple times.
>     * CMYK -> RGB conversion as last step before PNG/BMP writing.

>     Still to do:
>     * Output number of fuzzy matches etc to the meta file.

> [toolbin/bmpcmp.c]

2010-03-15T19:18:55.825828Z Lars Uebernickel

>     Change default TIFF strip size to one megabyte.

>     Many fax readers have problems reading TIFF images which are chunked into
>     strips, and one megabyte is larger than the biggest expected fax page.  Hence,
>     ghostscript's default TIFF output will be accepted by those readers.

> [base/gdevtifs.h]

2010-03-15T19:00:43.589302Z Lars Uebernickel

>     Write TIFF directories before the page data.  This might help bug #691172 and
>     probably some other non-conforming TIFF readers.

> [base/gdevtifs.c base/gdevtsep.c base/gdevtfnx.c]

2010-03-15T15:21:55.436137Z Alex Cherepanov

>     Don't throw an error when a filter returns 0 bytes and a normal return code.
>     This often happens with eexecDecode filter, which has to return the control
>     to the interpreter after every space character since Adobe no longer adds
>     zeros at the end of the encoded block. Document new return code 2 used by
>     eexecDecode filter. Bug 690909.

> [base/sstring.c base/seexec.c psi/iscan.c]

2010-03-15T14:56:15.278449Z Lars Uebernickel

>     Partial fix for bug #691172: The tiff resolution tags are floating point values
>     and need to be passed as such to TIFFSetField.

> [base/gdevtifs.c]

2010-03-15T07:44:38.447170Z Lars Uebernickel

>     Applied Tim Waugh's patch from bug #691171: A NULL check for the argument of
>     TIFFCleanup was missing, which caused a segfault when opening the output device
>     failed for any of the devices in gdevtfax.c.

> [base/gdevtfax.c]

2010-03-15T06:34:34.317078Z regression

>     Added support for mupdf testing in local regression suite.

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

2010-03-15T06:31:25.268888Z Marcos H. Woehrmann

>     Changes to the local cluster code:

>     added bmpcmp documentation to clusterpush.txt
>     new file, runNightly.pl, for nightly regression testing
>     readlog.pl, build.pl, and run.pl changes for nightly regression use

> [toolbin/localcluster/readlog.pl toolbin/localcluster/build.pl toolbin/localcluster/runNightly.pl toolbin/localcluster/run.pl toolbin/localcluster/clusterpush.txt]

2010-03-11T17:36:30.596061Z Chris Liddell

>     Apply a change submitted to FT and accepted - see FT bug #27442

> [freetype/src/raster/ftraster.c]

2010-03-11T05:01:22.057384Z Marcos H. Woehrmann

>     Run svn update on the ghostscript source even for clusterpush runs to make sure that bmpcmp.c is current.

> [toolbin/localcluster/run.pl]

2010-03-10T17:41:09.765460Z regression

>     Minor cleanup of the local cluster code.

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

2010-03-10T16:42:26.014885Z Robin Watts

>     Fix bug in bmpcmp.c: When reading images from multi-image sets, we stop
>     the comparison process as soon as we fail to find any differences in the
>     current image. With this fix we correctly keep searching to the end.

> [toolbin/bmpcmp.c]

2010-03-10T15:05:57.116970Z Chris Liddell

>     Change how we derive the glyph metrics from FT: we now interpret the glyph
>     description only once, scaled and hinted, and then calculate the metrics
>     from that. It's more accurate, accounts for hints that extend the glyph outline
>     and should be a worthwhile speed improvement.

> [psi/fapi_ft.c]

2010-03-10T12:51:50.027959Z Robin Watts

>     Change the condition under which we update the overprint device when restoring
>     a graphics state to be more relaxed; rather than updating if the overprint
>     state has changed we now update if it was enabled, or it if it is enabled.

>     The logic behind this is that it will still fire in all the same conditions
>     it did before, but will also fire when we restore from a state that had it
>     enabled to another state that had it enabled. This should be entirely
>     harmless, but will allow the state to be updated in the case where a
>     colorspace has been updated.

>     This causes 2 differences in the tests, that only show up in psd files.
>     All indications seem to be that these files really are identical. But if
>     they aren't, I believe they should be progressions, rather than regressions.

>     This moves the trunk more into line with the output of the gs_2_colors branch.

> [base/gsstate.c]

2010-03-10T06:13:23.278865Z Marcos H. Woehrmann

>     Added local modes to build.pl and run.pl in preparation for use as part of the nightly regression.

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

2010-03-10T05:19:59.535554Z Ray Johnston

>     Fix for SEGV with the psdcmyk device on 258-01.ps. This was a fundamental memory
>     problem with any device that used the compressed_color_list functions in gdevdevn.c
>     since a 'restore' could free structures which were still needed by the device.
>     Use stable_memory to avoid this. Bug 691150.

> [base/gdevdevn.c]

2010-03-09T17:27:07.400171Z Robin Watts

>     Another tweak to the local cluster bmpcmp html page generation. I managed to
>     miss renaming the images in the second column.

> [toolbin/localcluster/pngs2html.pl]

2010-03-09T17:22:39.470336Z Robin Watts

>     Another tweak to the localcluster bmpcmp html page generation javascript;
>     quote the string to avoid it being converted to an int.

> [toolbin/localcluster/pngs2html.pl]

2010-03-09T17:22:35.452303Z Till Kamppeter

>     Let pdftoraster not exit before the Ghostscript sub-process finishes. Thanks to Tim Waugh from Red Hat for the patch.

> [cups/pdftoraster.c]

2010-03-09T17:15:22.155871Z Robin Watts

>     Fix pngs2html.pl to number images according to both directory and image
>     number (needed now as images restart from 0 within each directory). This
>     really should fix the bmpcmp html output.

> [toolbin/localcluster/pngs2html.pl]

2010-03-09T17:08:42.132281Z Robin Watts

>     More fixes for the bmpcmp html page generations javascript.

>     Change code to pass numbers to swap() rather than strings as javascripts
>     conversion of strings to ints is... unhelpful.

> [toolbin/localcluster/bmps2html.pl toolbin/localcluster/pngs2html.pl]

2010-03-09T16:50:48.278966Z Robin Watts

>     Misplaced bracket in the javascript meant that only the first images would
>     swap on mouseover properly. Fixed here.

> [toolbin/localcluster/bmps2html.pl toolbin/localcluster/pngs2html.pl]

2010-03-09T16:39:21.328229Z Robin Watts

>     Fix javascript problems in bmpcmp output page generation. What sort of
>     stupid broken language depends on whitespace?

> [toolbin/localcluster/bmps2html.pl toolbin/localcluster/pngs2html.pl]

2010-03-09T16:35:06.527087Z Till Kamppeter

>     Fixes on CUPS Raster output device:
>     - Fixed memory reallocation on bitmap size change. Reallocation is not only
>     needed when dimendions and margins change, but also when the color depth
>     changes. Fixes bugs #691029 and #691108.
>     - Fixed arrayoption() macro in cups_put_params() function. Array values did
>     not get actually set in cups.header data structure. Bug only showed via
>     a compiler warning.
>     - Silenced compiler warning by presetting c0..c3 in cups_map_cmyk() to zero.

> [cups/gdevcups.c]

2010-03-09T16:29:31.666786Z Robin Watts

>     Attempted fix for bmpcmp output javascript problems with the coordinate
>     tracking.

> [toolbin/localcluster/pngs2html.pl]

2010-03-09T16:11:59.669918Z Robin Watts

>     Fix typos in the javascript code for pngs2html.pl and bmps2html.pl; this should
>     get at least some of it working, but the coord stuff still baffles me.

>     Also fix a typo that was causing the wrong "third image" to appear.

> [toolbin/localcluster/bmps2html.pl toolbin/localcluster/pngs2html.pl]

2010-03-09T01:46:06.865448Z Marcos H. Woehrmann

>     Fixed longstanding bug fuzzy.c that caused pbm files to be misread.

> [toolbin/tests/fuzzy.c]

2010-03-08T21:57:05.576067Z Hin-Tak Leung

>     updating documentation to mention how to run mkcidfm.ps manually; bug 688437

> [doc/Use.htm]

2010-03-08T21:54:37.005008Z Hin-Tak Leung

>     convert font file name to lowser case before matching; make it possible for upper case ARIALUNI.TTF to match; bug 688437

> [lib/mkcidfm.ps]

2010-03-08T21:49:56.216990Z Hin-Tak Leung

>     updating windows CJK font substitution list for more commonly found MS CJK fonts; bug 688437

> [lib/mkcidfm.ps]

2010-03-08T21:47:15.240330Z Hin-Tak Leung

>     revert to r8185 version of the korean example - it was removed in r8190 and a
>     corrupted version r9325 was subsequently checked in; found during fixing bug
>     688437 (incompete font substitution list)

> [examples/cjk/gscjk_ak.ps]

2010-03-08T16:20:53.842289Z Ken Sharp

>     Ongoing bug fixes for #690448.
>     The FreeType code will synthesize vertical metrics for TrueType (Type 42) fonts which do
>     not contain a vmtx table. This includes the vertical advance, which will be returned
>     to the FAPI code, and used even if there were originally no vertical metrics and the
>     font should not have any vertical advance.

>     Modified the metrics override callback, called by FT, so that if the font is a TT font,
>     and this is a vertical metrics call, we set the advance to 0. This prevents the
>     synthesized metrics from incorrectly advancing the glyph vertically.

>     This may eventually be a problem if we find a CIDFont with Type42 outlines which relies
>     on the vmtx table in the font rather than the Metrics2 or CDevProc overrides to position
>     the glyphs. Since this facility was only added in CPSI 3011 it is unlikely we will ever
>     encounter such a font. THis has not been done at present, as the information (WMode=1)
>     is not currently available to the code called from FreeType to override the metrics,
>     and would need to be added.

>     Also, fixed an issue where the 'advance_v' member of the metrics structure was left
>     uninitialised if a horizontal override took place. This could cause glyphs to be
>     mis-positioned vertically.

> [psi/fapi_ft.c]

2010-03-08T15:41:20.817468Z Ken Sharp

>     revert revision 10871, we will tackle this problem in the FAPI FreeType interface code
>     instead of in FreeType itself.

> [psi/fapi_ft.c]

2010-03-08T15:22:57.356559Z Ken Sharp

>     revert revision 10871, we will address the matter of FreeType creating synthetic vertical
>     metrics when none exist by overriding the synthetic metrics in the FAPI FreeType interface
>     code instead.

> [freetype/src/truetype/ttgload.c freetype/include/freetype/freetype.h]

2010-03-08T09:28:49.484133Z Chris Liddell

>     Latest improvements to the FAPI/FT bridge code. This code resolves the
>     issues with font matrices which do more than just scale. It is not yet
>     "finished", but is too big a step forward to risk losing.

> [psi/fapi_ft.c psi/zfapi.c]

2010-03-05T21:01:34.974121Z Marcos H. Woehrmann

>     Added bmpcmp option to clusterpush.pl.

> [toolbin/localcluster/clusterpush.pl]

2010-03-05T19:25:34.812546Z regression

>     Export results of local cluster bmpcmp command to web.

> [toolbin/localcluster/clustermaster.pl]

2010-03-05T16:50:00.654216Z regression

>     Update the local cluster code to use the new pbm->png mode of bmpcmp.

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

2010-03-05T16:47:10.049203Z Marcos H. Woehrmann

>     Minor changes due to bugzilla update.

> [toolbin/bugsByEngineer.pl]

2010-03-05T13:24:34.158774Z Ken Sharp

>     Fix FreeType
>     Ongoing fixes for bug #690448. In this case FreeType generates vertical metrics for
>     TrueType (in our case Type 42) fonts which lack vhea/vmtx tables, which is generally
>     the case.

>     These metrics are useful to a 'normal' TrueType consumer which has a notion of the
>     orientation of the writing direction. However in PostScript we don;t know that, so we
>     apply both the horizontal and vertical advance widths.

>     If the vertical advance should be 0 (because its not specified) then creating one causes
>     the glyphs to be misplaced.

>     This code adds a new load flag to FreeType 'FT_LOAD_NO_SYNTHETIC_METRICS', and sets
>     this flag in the FAPI FreeType interface code, which prevents FreeType from manufacturing a bogus vertical advance.

> [psi/fapi_ft.c freetype/src/truetype/ttgload.c freetype/include/freetype/freetype.h]

2010-03-05T09:23:47.698736Z Lars Uebernickel

>     Open tiffsep and tiffsep1 output files as seekable.

>     All files written by libtiff have to be seekable when writing multiple pages,
>     because libtiff tries to access previously written page dictionaries.  This
>     fixes bug 691160.

> [base/gdevtsep.c]

2010-03-05T07:01:13.637667Z Marcos H. Woehrmann

>     Fix pbm reading and png writing in bmpcmp.c.

> [toolbin/bmpcmp.c]

2010-03-05T05:32:24.962092Z regression

>     Added pngs2html.pl to repository: take a directory full of png files
>     generated by the increasingly poorly named bmpcmp.c and generate web pages
>     (like bmps2html.pl but without the bmp->png conversion).

> [toolbin/localcluster/pngs2html.pl]

2010-03-03T21:21:07.833457Z Ralph Giles

>     Flip images from RGB to BGR pixel format when reading ppm files,
>     and flip them back to RGB when writing png files.

>     This adapts all the current routines to assume the BGRx storage
>     format used by the bmp image format for the internal representation,
>     as is already done with the row order.

> [toolbin/bmpcmp.c]

2010-03-03T21:21:04.624166Z Ralph Giles

>     Also save the difference image as a png when bmpcmp is compiled with HAVE_LIBPNG.

> [toolbin/bmpcmp.c]

2010-03-03T20:30:01.695369Z Robin Watts

>     Fix stupid memory overwrite bug on bmp load.

> [toolbin/bmpcmp.c]

2010-03-03T20:03:29.767395Z Robin Watts

>     bmpcmp.c tweaks: Add (largely untested) code to allow "plain" (ascii) ppm,
>     pgm, pbm files. Also fix some compile warnings on 64bit platforms. Now
>     compiles cleanly with -Wall.

> [toolbin/bmpcmp.c]

2010-03-03T19:07:12.236947Z Ralph Giles

>     Add optional support for png output to the bmpcmp utility.

>     When compiled with the HAVE_LIBPNG preprocessor symbol defined, and
>     linking with libpng, the utility will save its output focus images
>     in RGB png format. Currently, only 32 bit RGBx pixel data is supported.

> [toolbin/bmpcmp.c]

2010-03-02T22:49:02.357333Z Robin Watts

>     Attempt to fix the javascript in the created files. The change to use
>     numeric filenames padded to 5 chars had broken the javascript. This
>     might fix it.

> [toolbin/localcluster/bmps2html.pl]

2010-03-02T21:26:36.100914Z regression

>     More changes towards having a bmpcmp running on the local cluster.

> [toolbin/localcluster/bmps2html.pl toolbin/localcluster/clustermaster.pl toolbin/localcluster/build.pl]

2010-03-02T21:12:59.888859Z Robin Watts

>     Updated bmpcmp to avoid inverting pnms on reading.

>     Also improve reading of non 32bpp bitmaps - still not quite right.

> [toolbin/bmpcmp.c]

2010-03-02T00:15:58.939654Z Marcos H. Woehrmann

>     Added partial support for "clusterpush.pl bmpcmp" (which will allow
>     users to generate bitmap comparisons of their most recent clusterpush
>     job and trunk).

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

2010-03-01T17:44:40.662743Z Ralph Giles

>     Add support to the autoconf and msvc builds to compile in a copy of
>     the FreeType2 library from local source.

>     Previously, the FAPI bridge for freetype required that the library
>     be compiled externally and include and link flags passed through
>     the FT_CFLAGS and FT_LIBS makefile variables. We now include a copy
>     of the freetype source in the tree, to make it easier to find a
>     compatible version of the source and to simplify building for
>     platforms that don't provide a system freetype.

>     Now, to enable both freetype and the FAPI bridge, pass --enable-freetype
>     to the configure script. This will set FT_BRIDGE=1 and the other required
>     variables. The configure script will prefer local source in gs/freetype2
>     to the copy in gs/freetype to simplify testing against upstream.

>     To enable freetype in the msvc build, pass FT_BRIDGE=1 on the nmake command
>     line.

>     Note that the fallback is now FT_BRIDGE=0, not FT_BRIDGE undefined; this
>     will require changes in any custom top-level makefiles.

> [base/winlib.mak doc/Make.htm base/gs.mak base/Makefile.in psi/int.mak base/configure.ac psi/msvc32.mak]

2010-03-01T15:34:56.724940Z Henry Stiles

>     Fixes bug #691154 and the regressions associated with revision 10823.
>     Unfortunately, performance-wise, the wtsimdi device must always use a
>     contone buffer until we've had a chance to see which raster operations
>     can be eliminated correctly.

> [base/gdevwts.c]

2010-02-28T22:57:02.883228Z Hin-Tak Leung

>     First half of patch from John Wehle for bug 691149 - vac C compiler on AIX 5.2 does
>     not like function with a void prototype returning a void function e.g.

>     ------------------
>     void func1();

>     void funct2() {
>     return funct1();
>     }
>     ------------------

>     The 2nd half of the submitted patch was committed as part of r10826 .

> [base/gdevpx.c]

2010-02-28T17:26:09.949555Z Henry Stiles

>     Fixes part of 691149 - void function returning value, thanks to John
>     Wehle for the fix.  Also, there were several compiler warnings in this
>     file related to the casting of the gs memory type pointer which have
>     been cleaned up as well.

> [base/gsnogc.c]

2010-02-28T14:52:00.838160Z Hin-Tak Leung

>     The distclean make target should call pgclean to clean up profile build also.

> [base/Makefile.in]

2010-02-28T01:19:26.994088Z Alex Cherepanov

>     Following PDF reference, version 1.7, section 10.10, crop /TrimBox and /CropBox
>     by the /MediaBox. Bug 691145.

> [Resource/Init/pdf_main.ps]

2010-02-27T23:29:31.437722Z Henry Stiles

>     Fixes bug #691147 customer 861, the optimization to strength reduce
>     the raster operation here is wrong, it is premised on the assumption
>     the colors are opaque.  If either texture or source is transparent the
>     strength reduction which effectively ignores the source or pattern is
>     wrong and it will subsequently cause opaque painting.  We've simply
>     removed the optimization instead of conditionalizing on opaque cases,
>     because tests indicate the reduction not that significant.  The
>     example in the bug report was reduced from a file in the XL ATS 305
>     test suite.  The following customer reported bugs in that test suite
>     are fixed by this change:

>     FH905UJ1.BIN pp 1,2,3,4
>     FH906UJ1.BIN pp 1-6
>     MA2K7UJ2.BIN pp 1-10
>     PW2K6UJ1.BIN pp 2
>     PWTTDUJ3.BIN pp 1

> [base/gxipixel.c]

2010-02-27T20:24:13.417473Z Alex Cherepanov

>     Upgrade Adobe Glyph List to v. 2.0. AGL is used for character mapping in
>     non-symbolic TrueType fonts in PDF files. Bug 691116.

> [Resource/Init/gs_agl.ps]

2010-02-27T16:56:47.050522Z Alex Cherepanov

>     Add missing newline in a TTF debug message.

> [Resource/Init/gs_ttf.ps]

2010-02-26T17:11:28.684024Z Ralph Giles

>     Correct a typo in the freetype makefile which prevented the inclusion
>     of ftlzw.c.

> [base/freetype.mak]

2010-02-26T06:41:31.056673Z Ralph Giles

>     Fixes to our makefile for the third-party freetype library.

>     I'd missed a number of "optional" files in the original commit, but
>     didn't notice because other dependencies, which themselves link to
>     the system freetype library on linux were providing definitions of
>     the missing symbols. These are now included in our build.

>     We now generate freetype.dev by copying freetype_$(SHARE_FT) within
>     freetype.mak, the same was this option is handled in the other third-
>     party makefiles.

>     We set native line endings and Id keyword substitution for this file
>     in the Subversion repository.

> [base/freetype.mak]

2010-02-25T11:04:59.765077Z Chris Liddell

>     add quotes around the expansion of DEVSTUDIO variable when it's used for
>     the recursive nmake call for debug targets - in case it has white space in it.

> [psi/msvc32.mak]

2010-02-25T08:21:46.259499Z Masaki Ushizaka

>     Fix for bug 691103.  The pdfwrite device now considers FDArray fonts'
>     FontMatrix and writes correct W/W2/DW/DW2 widths for CIDFont with unusual
>     FontMatrix.  This also fixes a problem gs_font::orig_FontMatrix not being
>     initialized for CIDFont.
>     Bug687832.pdf and Bug690834.ps will show differences which are improvements.

> [Resource/Init/gs_cidfn.ps base/gdevpdtt.c]

2010-02-24T20:26:57.347460Z Ralph Giles

>     Add a generic makefile for compiling the freetype library
>     as part of the Ghostscript monolithic build.

>     Including makefiles should define FTSRCDIR, FTGENDIR and FTOBJDIR,
>     similar to other third party libraries.

> [base/freetype.mak]

2010-02-24T19:59:05.197182Z Ralph Giles

>     Copy our local branch of the freetype library source into the gs tree.

>     This was the intended result of commit 10804, but an ommitted path element
>     placed it in the repository root instead.

> [freetype]

2010-02-24T19:38:11.435012Z Ralph Giles

>     Correct a typo in a dependency specification for wrfont.c.

>     The typo (stdio_h for stdio__h) prevented the dependency on arch.h
>     from being declared, generating a temporary error in a sufficiently
>     parallel make invocation.

> [psi/int.mak]

2010-02-24T19:27:11.525322Z regression

>     Changed naming scheme for regressions from 00000-00000 to 00000 (i.e. no longer treat Ghostscript and GhostPDL revisions independently).

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

2010-02-24T18:22:35.905364Z Ralph Giles

>     Move the fontconfig check into the libraries section of the configure script.

> [base/configure.ac]

2010-02-24T18:16:45.225914Z Chris Liddell

>     ensure the DEVSTUDIO value is propagated when we recursively nmake for the debug targets.

> [psi/msvc32.mak]

2010-02-24T17:28:23.116518Z Ralph Giles

>     Remove a spurious circular symlink accidentally included in the libpng-1.2.42
>     source import.

> [libpng/libpng]

2010-02-24T09:58:02.654907Z Ken Sharp

>     Fix, ignore a class of broken TrueType font.
>     Bug #691121 "gs stops in interpreting tt instructions". The font executes an MDRP
>     instruction with point number 28, the glyph only contains 28 points numbered 0 to 27 so
>     the interpreter (correctly) flags an error.

>     Windows and FT both appear to silently ignore the error and the instruction (definitely
>     the case for FreeType). Modified Ins_MDRP to simply return if the indicated point is
>     outside the number of points in this case.

> [base/ttinterp.c]

2010-02-23T22:29:18.142249Z Henry Stiles

>     Fixes bug 690967, a diagnostic problem with dumping memory the debug
>     -ZA option.  See the comment in the code for details, the change has
>     no effect on production builds.

> [base/gsalloc.c]

2010-02-23T21:58:15.181686Z Alex Cherepanov

>     Fix obviously wrong code in .fixsethalftonescreen procedure that is used by
>     the setscreen (and setcolorscreen) procedure and caused a PS error if the
>     third 'proc' argument to setscreen is a read-only Halftone type 1 dictionary.
>     Thanks to Jonathan Dagresta for the patch. Bug 691130, customer 1130.

> [Resource/Init/gs_dps2.ps]

2010-02-23T20:56:21.262529Z Alex Cherepanov

>     Simplify sed script that extracts libTiff version number for compatibility
>     with AIX sed. Include our portable header before tiff.h to make sure that
>     all stdint types are found. Bug 691102.

> [base/gdevtifs.c base/gdevtsep.c base/configure.ac base/gdevtfnx.c base/devs.mak base/gdevtfax.c]

2010-02-23T10:01:54.545437Z Ken Sharp

>     Fix (pdfwrite)
>     Bug #691133. If producing PDF/A output. and a DOCINFO pdfmark string was UTF_16BE
>     encoded *and* contained a numeric character, then decode_escape incorrectly consumed
>     any numeric characters following the first octal byte of the UTF16 code.

>     This was caused by decode_escape assuming that octal sequences are terminated by
>     non-numeric characters which is clearly wrong. The octal escape decoding loop is now
>     terminated when :
>     1) 3 numeric characters are read from the string
>     2) No more data is available in the string
>     3) A non-numeric character is encountered in the string.

> [base/gdevpdfe.c]

2010-02-22T11:45:33.943563Z Chris Liddell

>     resolve inappropriate variable type (signed vs unsigned) and comparisons with
>     the wrong variable when writing the local subrs info to the serialized T2 Private
>     dictionary.

> [psi/write_t2.c]

2010-02-21T17:57:24.841443Z regression

>     Added regression testing of the icc_work branch to the local cluster.

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

2010-02-21T03:57:26.068286Z Marcos H. Woehrmann

>     Add cast to bmpcmp.c to quiet useless compiler warning.

> [toolbin/bmpcmp.c]

2010-02-21T03:51:51.891247Z regression

>     Several minor changes to local cluster code to improve reliability and increase performance.

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

2010-02-21T03:38:29.059238Z Alex Cherepanov

>     Update pdf2dsc.ps to match the changes in pdf_main.ps introduced by
>     the rev. 10341. Thanks to William Bader for the patch. Bug 691124.

> [lib/pdf2dsc.ps]

2010-02-21T02:57:05.611462Z Alex Cherepanov

>     Include stat_.h before estack.h, which defines esp macro.
>     Prevent a spurious macro substitution in Cygwin version of signal.h.
>     Bug 691123, customers 661.

> [psi/zfapi.c psi/int.mak]

2010-02-17T17:02:27.004947Z Henry Stiles

>     Adds placeholder files to trunk so the other languages (pcl, xps and
>     svg) can built with the icc branch and trunk.  Each of these files
>     will be replaced with real files when the icc branch is merged into
>     the trunk.

> [base/lcms.mak base/gsiccmanage.h]

2010-02-16T18:12:57.832463Z Robin Watts

>     Tiny tweaks to clusterpush.pl to make it work on windows. First, wrap the
>     $HOME directory in additional quotes to allow for awkward windows users
>     with spaces in their names. Secondly, add a crude mapping for people whos
>     windows names are not the same as the usernames. This can unquestionably
>     be done more nicely, but the simple version will do for now.

> [toolbin/localcluster/clusterpush.pl]

2010-02-16T17:07:49.079920Z Alex Cherepanov

>     Add missing dereferencing of indirect objects in /Mask array.
>     Bug 691112, customers 870.

> [Resource/Init/pdf_draw.ps]

2010-02-12T15:27:23.315268Z Ken Sharp

>     Sort out some minor benign compiler warnings. No differences expected.

> [base/gdevpdfe.c]

2010-02-12T15:17:16.629322Z Ken Sharp

>     Fix colour processing. It was possible for nested ICCBased colour spaces (ie an ICCBased
>     space whose Alternate is another ICCBased space) to cause segmentation faults.

>     This was due to the fact that the conversion to base colour continuation procedure
>     'currentbasecolor_cont' was supposed to scan the space from the initial declaration
>     each time round a loop. However a reassignment of an array pointer caused it to
>     rescan from the last processed colour array instead.

>     Normally this does not cause problems, but in the case of nested ICCBased it caused
>     us to generate an error.

>     Fixed by re-initialising the array pointer at the start of the loop.

> [psi/zcolor.c]

2010-02-11T16:28:20.347398Z Ken Sharp

>     Fix (pdfwrite) bug #691104 "pdfwrite emits garbage in the XMP metadata when DOCINFO
>     pdfmarks contain UTF-16BE text strings"

>     There were several problems. Firstly the undoing of PostScript string escapes was wrong,
>     Octal escapes consumed too many characters, and several escape sequences weren't
>     recognised.

>     Secondly the XMP emission didn't expect to receive UTF-16BE strings and didn't convert
>     them to UTF-8 for inclusion in the metadata.

>     This patch fixes the broken octal escapes, adds teh unprocessed escapes and checks the
>     DOCINFo strings before sending to XMP. If they include the UTF-16BE Byte Order Mark
>     then convert the strings to UTF-8.

> [base/gdevpdfe.c]

2010-02-10T20:27:33.989189Z Ralph Giles

>     Bump the versioning after the 8.71 release.

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

Copyright © 2000-2019 Artifex Software, Inc. All rights reserved.

This software is provided AS-IS with no warranty, either express or implied. This software is distributed under license and may not be copied, modified or distributed except as expressly authorized under the terms of that license. Refer to licensing information at https://www.artifex.com or contact Artifex Software, Inc., 1305 Grant Avenue - Suite 200, Novato, CA 94945, U.S.A., +1(415)492-9861, for further information.

Ghostscript version 9.52, 19 March 2020