History of Ghostscript versions 9.xx

Table of contents

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.21 (2017-03-16)

This is the fifteenth full release in the stable 9.x series.

Highlights in this release include:

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

Incompatible changes

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:

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

Incompatible changes

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:

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

Incompatible changes

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:

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