/usr/share/doc/ghostscript/Details.htm

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"   "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<title>Ghostscript change history (detailed)</title>
<!-- generated by split_changelog.py from the output of cvs2cl.pl -->
<link rel=stylesheet type="text/css" href="gs.css">
</head>
<body>

<p><strong><a name="2011-03-28T084948.387061Z"></a>
2011-03-28T08:49:48.387061Z Chris Liddell</strong></p>
<blockquote>
<pre>
Reduce duplication of changelog and news by deprecating Changes.htm and
Details#.htm.

The information will now be in two places only: the highlights summary
in News.htm, and the detailed changes in History#.htm.

Update related documentation and html links to reflect this change.

CLUSTER_UNTESTED
</pre>
<p>[doc/Changes.htm doc/Readme.htm doc/Details9.htm doc/Release.htm]</p>
</blockquote>

<p><strong><a name="2011-03-26T145106.549590Z"></a>
2011-03-26T14:51:06.549590Z Michael Vrhel</strong></p>
<blockquote>
<pre>
Fix for issue found by Chris where we have a soft mask embedded in a softmask and graphic state pushes and pops occurring.  In this case, the soft mask stack that is saved gets out of sync compared to the one in the context state.    Use of the stack count can catch the issue and correct it.  Also a rename of one of the variables in the pdf14 code to make it easier to debug.</pre>
<p>[base/gdevp14.c base/gdevp14.h]</p>
</blockquote>

<p><strong><a name="2011-03-25T121205.657797Z"></a>
2011-03-25T12:12:05.657797Z Till Kamppeter</strong></p>
<blockquote>
<pre>
Fixes concerning the compatibility of the OpenPrinting Vector (&quot;opvp&quot;)
output device with Ghostscript 9.x.

1. If there is any ICCColor based image in the PostScript input, GS crashes.
2. Fallback when path is too complex for some kinds of printers. This problem
   already existed in GS 8.x.

Thanks to Koji Otani from BBR Inc., Japan.

</pre>
<p>[contrib/opvp/gdevopvp.c]</p>
</blockquote>

<p><strong><a name="2011-03-25T102206.357287Z"></a>
2011-03-25T10:22:06.357287Z Chris Liddell</strong></p>
<blockquote>
<pre>
The code was erroneously attempting to get a glyph name for a case where
we already had a glyph index for a Truetype font.

Add a check for object type before trying to get a string from a name object.


Bug 692095

No cluster differences expected.

</pre>
<p>[psi/zfapi.c]</p>
</blockquote>

<p><strong><a name="2011-03-24T172617.397320Z"></a>
2011-03-24T17:26:17.397320Z Chris Liddell</strong></p>
<blockquote>
<pre>
Resolve build issues with language_switch and UFST.

I had (wrongly) assumed that the PCL/language_switch builds with UFST
and COMPILE_INITS=1 would have the relevant paths correctly setup for
the PS/PDF world to access the Microtype FCOs. It turns out they are
done in an incompatible manner.

So, I've renamed the path variables (in the makefiles) so there isn't
a clash between PCL and PS/PDF, ensured that the variables are correctly
passed through recursive (n)make calls, and tidied up the FAPI options
for the language_switch build.

Not only does this allow language_switch to build with the UFST, but the
Postscript interpreter does now use FAPI/UFST to access the Microtype fonts
for the built-in fonts, and uses FAPI/Freetype for downloaded fonts.

Bug 692093

No cluster differences expected.

</pre>
<p>[/trunk/ghostpdl/common/msvc_top.mak /trunk/ghostpdl/language_switch/pspcl6_msvc.mak /trunk/ghostpdl/main/pcl6_gcc.mak psi/msvc.mak base/Makefile.in psi/int.mak]</p>
</blockquote>

<p><strong><a name="2011-03-24T042223.459616Z"></a>
2011-03-24T04:22:23.459616Z Michael Vrhel</strong></p>
<blockquote>
<pre>
Fix for compiler warning.</pre>
<p>[base/gdevp14.h]</p>
</blockquote>

<p><strong><a name="2011-03-23T213420.429081Z"></a>
2011-03-23T21:34:20.429081Z Michael Vrhel</strong></p>
<blockquote>
<pre>
This commit fixes several issues.

Memory leaks in the PDF14 device as well as the separation devices.
Fixes in PDF14 device so the the color encoder and decoder are properly updated if soft masks occur with spot colors.
Proper copying of the devicen parameters to the clist devices in the MT rendering.  This was the source of a problem when doing multi-threaded rendering to separation devices.

This fixes bug 692087</pre>
<p>[base/gdevp14.c base/gsicc_cache.c base/gxclutil.c base/gdevpsd.c base/lib.mak base/gdevp14.h base/gxclthrd.c base/gdevtsep.c base/gdevdevn.c base/gxblend.c base/gdevdevn.h]</p>
</blockquote>

<p><strong><a name="2011-03-21T112417.021832Z"></a>
2011-03-21T11:24:17.021832Z Michael Vrhel</strong></p>
<blockquote>
<pre>
Fix for memory leaks in the pdf14 device.  These could occur with softmask and graphic state changes as well as when we are going to a tiffsep device.  </pre>
<p>[base/gdevp14.c]</p>
</blockquote>

<p><strong><a name="2011-03-20T014019.345427Z"></a>
2011-03-20T01:40:19.345427Z Michael Vrhel</strong></p>
<blockquote>
<pre>
Fix for bug 692087 crashes.   num_bytes - bytes_dropped was ending up negative in cases where the transparency device was reducing the number of colorants compared to the target device (mainly when we had a softmask) which was getting passed into the clist as an unsigned value.   Now when this occurs we just use the encoding of the full color value.  </pre>
<p>[base/gxclutil.c]</p>
</blockquote>

<p><strong><a name="2011-03-19T045652.259544Z"></a>
2011-03-19T04:56:52.259544Z Michael Vrhel</strong></p>
<blockquote>
<pre>
A temp fix for bugs 692038 and 692065.  The clist devices that are created for the threads now inherit the icc profile from the target device.  I need to set things up so that the device profile is no longer reference counted since we could have a race condition problem if the different threads are incrementing and decrementing the count and if the command is not atomic on a particular architecture.  The plan will be to no longer ref count the device profile but to have it maintained until the the actual target device is destroyed.  There will be a bit of work to do with respect to the pdf14 device, which can have a device profile that is different than the actual target device.  That profile can be altered with the transparency group pushes and pops.</pre>
<p>[base/gxclthrd.c]</p>
</blockquote>

<p><strong><a name="2011-03-19T003237.910024Z"></a>
2011-03-19T00:32:37.910024Z Ray Johnston</strong></p>
<blockquote>
<pre>
Fix for some strange rendering with PDF 1.7 FTS files when we have shading and transparency
and are both filling and stroking text (Text Rendering modes 2 and 6). Customer 532.

</pre>
<p>[Resource/Init/pdf_ops.ps]</p>
</blockquote>

<p><strong><a name="2011-03-18T051608.669973Z"></a>
2011-03-18T05:16:08.669973Z Michael Vrhel</strong></p>
<blockquote>
<pre>
Fix so that image_parent_type is properly initialized during clist image reading.</pre>
<p>[base/gsiparm4.h base/gximage1.c base/gximage4.c]</p>
</blockquote>

<p><strong><a name="2011-03-17T152458.552348Z"></a>
2011-03-17T15:24:58.552348Z Chris Liddell</strong></p>
<blockquote>
<pre>
Escape/quote the UFST path settings in the makefile so that the macros
correctly expand to strings.

Bug 692082

No cluster differences expected

CLUSTER_UNTESTED
</pre>
<p>[base/Makefile.in]</p>
</blockquote>

<p><strong><a name="2011-03-17T095453.062174Z"></a>
2011-03-17T09:54:53.062174Z Chris Liddell</strong></p>
<blockquote>
<pre>
Uncached glyphs were ignoring rendering mode 3, and being imaged
directly to the device - for cached glyphs the decision occurred
in the &quot;show machinery&quot;.

This wasn't my first choice solution, but all the others I tried
caused problems with later use of a cached glyph (which wasn't
actually cached), or problems with pdfwrite, pswrite or ps2write.


Bug 692004

No cluster differences expected.

</pre>
<p>[base/gspaint.c]</p>
</blockquote>

<p><strong><a name="2011-03-17T094116.074991Z"></a>
2011-03-17T09:41:16.074991Z Chris Liddell</strong></p>
<blockquote>
<pre>
Fix some issue where user specified devices didn't get the requisite &quot;&#36;(DD)&quot;
and &quot;.dev&quot; runes added to them.

Also, rearrange the &quot;pre-declared&quot; device strings to be more consistent within
configure.ac


Bug 692062

No cluster differences expected.


</pre>
<p>[base/configure.ac]</p>
</blockquote>

<p><strong><a name="2011-03-15T175917.340024Z"></a>
2011-03-15T17:59:17.340024Z Robin Watts</strong></p>
<blockquote>
<pre>
Add special case mem_planar_copy_color_4to1 code for copying bits
from 4 1 bit planes into 1 4 bit chunky plane.

This helps with performance of the plibk device.

No cluster differences expected.</pre>
<p>[base/gdevmpla.c]</p>
</blockquote>

<p><strong><a name="2011-03-15T083505.386182Z"></a>
2011-03-15T08:35:05.386182Z Ken Sharp</strong></p>
<blockquote>
<pre>
Fix (ps2write) : Indexed colour images have incorrect /Decode

Bug #691924 &quot;Differences in colour with ps2write&quot;

The problem was due to the opdfread code generating a /Decode for an Indexed colour
space where the value was [0 2^n] and should be [0 ((2^n) - 1)]. This caused the
highest image sample to be mapped to 1 past the end of the samples in the colour space.

Normally this doesn't matter, because the values are clamped to 'hival' in the Indexed
space. In this case, however, the image was 2 bpp (4 values) but the colour space was
defined as a full 256 indices, with only the first 4 being used.

The incorrect Decode caused the image sample value 3 to be looked up as colour space
sample 4, which was set to all 0 (black) causing incorrect colour values.

</pre>
<p>[base/opdfread.h lib/opdfread.ps]</p>
</blockquote>

<p><strong><a name="2011-03-14T154615.599171Z"></a>
2011-03-14T15:46:15.599171Z Robin Watts</strong></p>
<blockquote>
<pre>
Reintroduce commented out PACIFY_VALGRIND definition in gximono.c - without it
the comment makes no sense.

Add new PACIFY_VALGRIND code (and commented out definition) in
gxht_threshold.c.

Fix some line endings.

No real code change, so no cluster differences expected.

</pre>
<p>[base/gximono.c base/gxht_thresh.c]</p>
</blockquote>

<p><strong><a name="2011-03-14T151608.036660Z"></a>
2011-03-14T15:16:08.036660Z Robin Watts</strong></p>
<blockquote>
<pre>
Fix an indetermism in the halftoning code. When mapping a y offset into a
row index for a halftone tile, special care needs to be taken when y is
negative. Proof (as if more were needed) that the % operator in C is evil.

The command in question was a cutdown version of C306.bin rendered at 600bpi
to pbmraw with dMaxBitmap=10000.

It now runs into a clist UMR. Will keep looking.</pre>
<p>[base/gximono.c]</p>
</blockquote>

<p><strong><a name="2011-03-14T135351.702509Z"></a>
2011-03-14T13:53:51.702509Z Ken Sharp</strong></p>
<blockquote>
<pre>
Fix (ps2write) : Don't set a default halftone.

Bug #691923 &quot;Differences in dithered output with ps2write&quot;

The PDF interpreter emits a setpagdevice between every page of output, in case the
media size has changed. The implementation of setpagedevice resets the halftone to be
the default halftone (106 lpi 45 degree line screen).

This is a problem for ps2write, and potantially pdfwrite, as there is no way to
differentiate between a default halftone set by setpagdevice, and a halftone contained
in the input file.

To avoid embedding an unhelpful halftone, we now check the device parameter
'/HighLevelDevice' in the setpagedevice implementation, and if it is present and true, 
we do not call .setdefaulthalftone.

Also updates documentation on device parameters.

This causes differences on every 1-bit rendering test (ie pkmraw) of the ps2write
output file, so approximately 1300 differences are to be expected.
</pre>
<p>[doc/Drivers.htm Resource/Init/gs_setpd.ps]</p>
</blockquote>

<p><strong><a name="2011-03-14T130003.503443Z"></a>
2011-03-14T13:00:03.503443Z Robin Watts</strong></p>
<blockquote>
<pre>
Fix Bug 692064. Tiffscaled device was checking on page print time that the
expected size of the page wouldn't make the page too large to fit in a file.
This code was copied from the tiffgray device (as we render internally in
8bpp). As we output in monochrome however (and may use compression) the
test is in fact bogus, and should simply be removed. We do that here.

It's entirely possible that we should be removing the test from the
tiffgray device too - most systems with 32bit longs support large files these
days, and compression may apply here too anyway. I'll leave this until it
becomes an issue though.

No cluster differences expected.</pre>
<p>[base/gdevtsep.c]</p>
</blockquote>

<p><strong><a name="2011-03-13T115708.378919Z"></a>
2011-03-13T11:57:08.378919Z Ken Sharp</strong></p>
<blockquote>
<pre>
Some updates to the new device parameters. It turned out that the intended parameter
Type32ToUnicode was incorrectly implemented. This should actually have used the
WantsToUnicode parameter, because the code actually controls the processing of 
GlyphNames2Unicode tables from Windows PostScript.

This means we no longer need the Type32ToUnicode parameter and it has been removed.

Added initial documentation of these parameters.

This appears to cause some differences in Bug690829.ps rendered at 300 dpi. 
This is a surprise, because the changes should have no effect on devices other than
pdfwrite/ps2write, but the new result is better than the old, so this is a progression.
</pre>
<p>[Resource/Init/gs_pdfwr.ps base/gdevpdfx.h base/gdevpdfp.c doc/Drivers.htm base/gdevpdfb.h]</p>
</blockquote>

<p><strong><a name="2011-03-13T012149.785339Z"></a>
2011-03-13T01:21:49.785339Z Ray Johnston</strong></p>
<blockquote>
<pre>
Remove spurious debug printout inserted in rev 12141 line 780:
    1 index == 0 index ==
</pre>
<p>[Resource/Init/pdf_draw.ps]</p>
</blockquote>

<p><strong><a name="2011-03-11T192457.067395Z"></a>
2011-03-11T19:24:57.067395Z Ken Sharp</strong></p>
<blockquote>
<pre>
Change the default value for the 'AllowPSRepeat' so that it defaults to allowed instead
of disallowed (doh!) This is important for those devices which don't set the device
parameter.

No differences expected.
</pre>
<p>[psi/zfunc4.c]</p>
</blockquote>

<p><strong><a name="2011-03-11T171451.124213Z"></a>
2011-03-11T17:14:51.124213Z Ken Sharp</strong></p>
<blockquote>
<pre>
Remove a #if 0 accidentally left in the commit for revision 12282. Also initialise a
variable, just in case.

No differences expected.
</pre>
<p>[psi/zfunc4.c]</p>
</blockquote>

<p><strong><a name="2011-03-11T165834.690669Z"></a>
2011-03-11T16:58:34.690669Z Ken Sharp</strong></p>
<blockquote>
<pre>
The final removal of the reliance on testing the device name to influence interpreter
behaviour.

This tests the /AllowPSRepeat paramter and flags an error if a function tries to use 
'repeat' when it is disallowed.

Still to do: write some documentation on these new parameters.

No differences expected.
</pre>
<p>[psi/zfunc4.c]</p>
</blockquote>

<p><strong><a name="2011-03-11T151440.609962Z"></a>
2011-03-11T15:14:40.609962Z Chris Liddell</strong></p>
<blockquote>
<pre>
Add the new third party library directories to the Windows nmake zip file
target.

No cluster differences.

Bug 691944

Credit to: Gennadiy Tsarenkov.

CLUSTER_UNTESTED

</pre>
<p>[psi/winint.mak]</p>
</blockquote>

<p><strong><a name="2011-03-11T150756.095474Z"></a>
2011-03-11T15:07:56.095474Z Chris Liddell</strong></p>
<blockquote>
<pre>
Rejig the romfs targets so that unix make can follow the dependencies.

This should prevent the pointless rebuilding of the romfs C source.

Bug 692053

No cluster differences expected.

</pre>
<p>[base/lib.mak base/unix-aux.mak]</p>
</blockquote>

<p><strong><a name="2011-03-11T090424.536166Z"></a>
2011-03-11T09:04:24.536166Z Chris Liddell</strong></p>
<blockquote>
<pre>
Some (broken) TrueType fonts have out of order loca tables, which can result
in the calculated glyph data lengths being larger than the actual
available glyph data. Normally this does not cause a problem, but if the glyph
in question is in the final bytes of the stream, we encounter an unexpected
end of data condition when creating the glyph data buffer to pass into
Freetype.

So the FAPI interface code will now ignore that error, and adjust the byte
length to correctly reflect the number of bytes available in the buffer.

It is safe to do this because, in the event we have a genuine out-of-data
condition, Freetype will return an error when it tries to interpret the
glyph outline.

Bug 692043

No cluster differences expected.

</pre>
<p>[psi/fapi_ft.c psi/zfapi.c]</p>
</blockquote>

<p><strong><a name="2011-03-11T054519.450208Z"></a>
2011-03-11T05:45:19.450208Z Alex Cherepanov</strong></p>
<blockquote>
<pre>
Fix missing header problem on older versions of MSVC.
</pre>
<p>[base/gsropt.h]</p>
</blockquote>

<p><strong><a name="2011-03-11T041539.316030Z"></a>
2011-03-11T04:15:39.316030Z Michael Vrhel</strong></p>
<blockquote>
<pre>
A reorganization of the halftone code in preparation of doing thresholding of color images.  This basically pulls out some code pieces that will be shared in all the image thresholding cases.  No differences expected (or seen in the cluster push).</pre>
<p>[base/gxht_thresh.h base/lib.mak base/gximono.c base/gxicolor.c base/gxht_thresh.c]</p>
</blockquote>

<p><strong><a name="2011-03-10T173138.501799Z"></a>
2011-03-10T17:31:38.501799Z Robin Watts</strong></p>
<blockquote>
<pre>
I missed one change in commit 12274. The detection of chunky modes should
look at num_planes being &lt;= 1, not == 1.

I tested this locally and then clearly missed it when cluster pushing.
</pre>
<p>[base/gdevdrop.c]</p>
</blockquote>

<p><strong><a name="2011-03-10T165615.200283Z"></a>
2011-03-10T16:56:15.200283Z Robin Watts</strong></p>
<blockquote>
<pre>
Planar device is broken w.r.t rops in a cmyk space - this commit fixes it.

The planar memory device sets itself to use gx_default_strip_copy_rop
rather than mem_strip_copy_rop. mem_strip_copy_rop knows that rops on
cmyk pixels should actually convert to rgb, perform the rop, and convert
back again, but doesn't know how to convert the results back when it's in
planar mode. gs_default_strip_copy_rop can cope with planar mode, but doesn't
know to convert to rgb first.

The first fix included here is to extend mem_strip_copy_rop to know how to
write back to planar format, and then to make the planar memory device use
mem_strip_copy_rop.

This then exposes various flaws in mem_strip_copy_rop, including the fact
that it relies on being able to set the offset in get_bits calls when this
is sometimes not possible. We therefore fix the code to manage offsets
by explicitly updating them.

Also, the raster used in mem_strip_copy_rop was incorrect - we use the 
correct one and get much better results.

No cluster differences expected as the planar device is not tested.

</pre>
<p>[base/gdevdrop.c base/gdevmpla.c]</p>
</blockquote>

<p><strong><a name="2011-03-10T164220.394889Z"></a>
2011-03-10T16:42:20.394889Z Robin Watts</strong></p>
<blockquote>
<pre>
The routines in gdevplib.c intended to map colors in cmyk form back to rgb
were incorrect. Fixed here.

No differences expected as this files isn't linked in by default.

CLUSTER_UNTESTED


</pre>
<p>[base/gdevplib.c]</p>
</blockquote>

<p><strong><a name="2011-03-10T162704.913812Z"></a>
2011-03-10T16:27:04.913812Z Robin Watts</strong></p>
<blockquote>
<pre>
Remove the buffer blanking done in gximono.c. Previously removing this would
have caused indeterminisms. With the additional fix in here to limit
offset_bits to dest_width, however, we should get stable results.

This gives various differences in output (81 in pcl, presumably more in PDF
and PS). Bmpcmp of the pcl ones shows them as all progressions.

</pre>
<p>[base/gximono.c]</p>
</blockquote>

<p><strong><a name="2011-03-10T145508.103488Z"></a>
2011-03-10T14:55:08.103488Z Ken Sharp</strong></p>
<blockquote>
<pre>
Update the remaining PostScript files (mostly the PDF interpreter) to use the new device
parameters instead of explicitly checking for the device being named 'pdfwrite' or 
'ps2write'.

Some more modification is still required, but we're nearly there. We will continue to 
check the device names in gs_pdfwr.ps when setting up the default state for those
specific devices.

Although not strictly a Distiller device, ps2write declares itself to be 'IsDistiller'. 
This is because some PostScript test files were found to behave differently if the 
distillerparams operators were available, in particular files would be oriented
differently if the device was deemed to be a Distiller.

</pre>
<p>[Resource/Init/gs_pdfwr.ps Resource/Init/pdf_font.ps Resource/Init/pdf_draw.ps base/gdevpdfb.h Resource/Init/gs_setpd.ps]</p>
</blockquote>

<p><strong><a name="2011-03-10T073145.990562Z"></a>
2011-03-10T07:31:45.990562Z Alex Cherepanov</strong></p>
<blockquote>
<pre>
Ignore null object when it is used instead of the gstate dictionary.
Bug 692050.
</pre>
<p>[Resource/Init/pdf_main.ps]</p>
</blockquote>

<p><strong><a name="2011-03-10T061917.004672Z"></a>
2011-03-10T06:19:17.004672Z Alex Cherepanov</strong></p>
<blockquote>
<pre>
Change all instances of true, false, and null to //true, //false, and //null
to avoid interferance from PS files that redefine them. Bug 692041.
</pre>
<p>[Resource/Init/gs_typ32.ps Resource/Init/gs_cidfm.ps Resource/Init/gs_mgl_e.ps Resource/Init/pdf_rbld.ps Resource/Init/gs_resmp.ps Resource/Init/gs_dscp.ps Resource/Init/gs_fonts.ps Resource/Init/gs_wan_e.ps Resource/Init/gs_mex_e.ps Resource/Init/gs_ttf.ps Resource/Init/gs_cspace.ps Resource/Init/gs_cff.ps Resource/Init/gs_dps1.ps Resource/Init/gs_lev2.ps Resource/Init/pdf_sec.ps Resource/Init/gs_l2img.ps Resource/Init/gs_cet.ps Resource/Init/gs_dbt_e.ps Resource/Init/gs_pdf_e.ps Resource/Init/gs_statd.ps Resource/Init/gs_fapi.ps Resource/Init/gs_pdfwr.ps Resource/Init/gs_cidfn.ps Resource/Init/pdf_main.ps Resource/Init/gs_dps.ps Resource/Init/gs_res.ps Resource/Init/gs_ll3.ps Resource/Init/gs_css_e.ps Resource/Init/gs_epsf.ps Resource/Init/pdf_draw.ps Resource/Init/gs_dpnxt.ps Resource/Init/gs_icc.ps Resource/Init/gs_mro_e.ps Resource/Init/pdf_ops.ps Resource/Init/gs_init.ps Resource/Init/pdf_font.ps Resource/Init/gs_ciddc.ps Resource/Init/gs_trap.ps Resource/Init/gs_cidtt.ps Resource/Init/gs_diskn.ps Resource/Init/gs_fntem.ps Resource/Init/pdf_base.ps Resource/Init/gs_sym_e.ps Resource/Init/gs_img.ps Resource/Init/gs_btokn.ps Resource/Init/gs_cidcm.ps]</p>
</blockquote>

<p><strong><a name="2011-03-10T005808.762234Z"></a>
2011-03-10T00:58:08.762234Z Michael Vrhel</strong></p>
<blockquote>
<pre>
Fix for bug 692038.

This fixes 3 issues when using a CIELAB based profile for the output device ICC profile.

One was a problem when handling separation color spaces when they had the ALL entry and we were going to an additive device.  AR does a 1-INK level for the device values and no color management.  We were doing the same, but this approach will not work if our destination color space is CIELAB.  Now if we are headed toward CIELAB we do the 1-INK to RGB and then transform to CIELAB. 

Another was that transparency blending should never be done in CIELAB or similar type color spaces.  With transparency, the PDF14 device inherits the profile for the target device and if the transparency groups don't specify a color space we would end up blending in CIELAB.  The solution was to detect this situation and use the defaultRGB profile for blending.  Conversion to CIELAB occurs during the pdf14 put image operation.  

Finally, with shading in transparency, we need to make sure to pass along the transparency device through the shading parameters whenever we have a color mismatch between the pdf14 device and the target device so that the shading will occur in the proper color space.

These changes are all related to a non-tested cluster case when we have -sOutputICCProfile=lab.icc</pre>
<p>[base/gdevp14.c base/gxcmap.c base/gstrans.c base/gxclist.h base/gdevtfnx.c base/gsfunc0.c base/devs.mak base/gsicc.c]</p>
</blockquote>

<p><strong><a name="2011-03-09T213258.461339Z"></a>
2011-03-09T21:32:58.461339Z Robin Watts</strong></p>
<blockquote>
<pre>
Add gxht_thresh.{c,h} to Visual C project.

CLUSTER_UNCHECKED</pre>
<p>[ghostscript.vcproj]</p>
</blockquote>

<p><strong><a name="2011-03-09T144440.068733Z"></a>
2011-03-09T14:44:40.068733Z Robin Watts</strong></p>
<blockquote>
<pre>
Disable PACIFY_VALGRIND in gximono.c. This define is intended to enable
extra code that can be performed so as to ensure that valgrind doesn't
report false positives. As such, disabling it should have no adverse
effects.

Unfortunately, it seems that in the portrait case, if we don't blank the
threshold array before we run, we get diffs. I have therefore taken this
memset out of the PACIFY_VALGRIND case and forced it to always happen.
This probably points to a bug and should be investigated properly.

No cluster differences expected.

</pre>
<p>[base/gximono.c]</p>
</blockquote>

<p><strong><a name="2011-03-08T200017.821965Z"></a>
2011-03-08T20:00:17.821965Z Robin Watts</strong></p>
<blockquote>
<pre>
Simple optimisations to non SSE2 versions of halftoning code. There is
probably (certainly!) more performance to come with loop unrolling etc,
but this at least gets us the cheap win of avoiding repeated array accessing,
only setting, not blanking bits etc.

Cluster tests show no changes.

</pre>
<p>[base/gxht_thresh.c]</p>
</blockquote>

<p><strong><a name="2011-03-08T174051.077420Z"></a>
2011-03-08T17:40:51.077420Z Robin Watts</strong></p>
<blockquote>
<pre>
Change to gsroprun1.h to avoid over/underreading the source/texture buffers.

Given a valid byte range we expand that to the smallest enclosing CHUNK range
and guarantee never to access out of that range. Previously we could read
one CHUNK before/after it.

If this is a problem, simply ensure that CHUNK is byte rather than int on
your platform. This now behaves better than the original code which would
access one byte before/after the defined range.

No cluster differences seen in testing.

</pre>
<p>[base/gsroprun1.h]</p>
</blockquote>

<p><strong><a name="2011-03-08T163516.023687Z"></a>
2011-03-08T16:35:16.023687Z Tor Andersson</strong></p>
<blockquote>
<pre>
Add PNG reading support to the bmpcmp tool.</pre>
<p>[toolbin/bmpcmp.c]</p>
</blockquote>

<p><strong><a name="2011-03-08T151842.397978Z"></a>
2011-03-08T15:18:42.397978Z Ken Sharp</strong></p>
<blockquote>
<pre>
Update to use the new device parameter /PreserveTrMode instead of explicitly checking
for the device name being 'pdfwrite'.

No differences expected.
</pre>
<p>[Resource/Init/pdf_ops.ps]</p>
</blockquote>

<p><strong><a name="2011-03-08T082754.788378Z"></a>
2011-03-08T08:27:54.788378Z Ken Sharp</strong></p>
<blockquote>
<pre>
Activate the new device parameters, and modify the resource code to use the first one
(AllowIncrementalCFF) instead of testing for the pdfwrite device name.

No differences expected.
</pre>
<p>[Resource/Init/gs_cidfn.ps base/gdevpdfp.c]</p>
</blockquote>

<p><strong><a name="2011-03-08T002607.330315Z"></a>
2011-03-08T00:26:07.330315Z Robin Watts</strong></p>
<blockquote>
<pre>
When using PACIFY_VALGRIND, don't call the memory blanking when the
mallocs have failed.

This should cure the SEGVs that were introduced, but otherwise cause no
changes.

</pre>
<p>[base/gximono.c]</p>
</blockquote>

<p><strong><a name="2011-03-07T221929.253652Z"></a>
2011-03-07T22:19:29.253652Z Michael Vrhel</strong></p>
<blockquote>
<pre>
Initialize ht landscape structure to zero when in portrait case.  There is a conditional test on the value later.</pre>
<p>[base/gximono.c]</p>
</blockquote>

<p><strong><a name="2011-03-07T215702.879011Z"></a>
2011-03-07T21:57:02.879011Z Robin Watts</strong></p>
<blockquote>
<pre>
Correct line endings (were DOS, should be Unix).

No cluster differences.

CLUSTER_UNTESTED

</pre>
<p>[base/gxht_thresh.h base/gxht_thresh.c]</p>
</blockquote>

<p><strong><a name="2011-03-07T211712.494498Z"></a>
2011-03-07T21:17:12.494498Z Robin Watts</strong></p>
<blockquote>
<pre>
Add new debugging define to gximono.c, PACIFY_VALGRIND.

This enables various small tweaks in the code that stop valgrind throwing
errors. We believe that all the errors thrown are false positives, but
we enable this define anyway until we've sorted the current indeterminisms.
We'll disable it in a few days when we have solved the problems and check that
it really doesn't cause any more.

Cluster results unknown; probably no change. If this solves indetermisms
then we'll need to understand why.

</pre>
<p>[base/gximono.c]</p>
</blockquote>

<p><strong><a name="2011-03-07T211156.916525Z"></a>
2011-03-07T21:11:56.916525Z Robin Watts</strong></p>
<blockquote>
<pre>
Fix typos, one in a comment, one in an id string.

No cluster differences.

CLUSTER_UNTESTED

</pre>
<p>[base/gxipixel.c base/gzspotan.c]</p>
</blockquote>

<p><strong><a name="2011-03-07T185808.149818Z"></a>
2011-03-07T18:58:08.149818Z Michael Vrhel</strong></p>
<blockquote>
<pre>
Fix for improper indexing of reversed portrait image line.  We were off by one byte and ended up with one byte not set.  Def. a source of indeterminism.  Thanks to Robin for tracking this down.</pre>
<p>[base/gximono.c]</p>
</blockquote>

<p><strong><a name="2011-03-07T154013.201330Z"></a>
2011-03-07T15:40:13.201330Z Ken Sharp</strong></p>
<blockquote>
<pre>
Undo revision 12243. The revision makes a debug print dependent on the value of the
 'size_set' variable. Unfortunately, this variable is not defined in the cups_get_matrix
routine. It is defined in the other places it is used (cups_put_params).

This prevents a debug build from compiling on Windows, and I can't see how it would
work on any other OS when built for debug.

Reverted the change in order to build debug versions of Ghostscript.
</pre>
<p>[cups/gdevcups.c]</p>
</blockquote>

<p><strong><a name="2011-03-07T142111.345196Z"></a>
2011-03-07T14:21:11.345196Z Ken Sharp</strong></p>
<blockquote>
<pre>
Redo revision 12248 in a way which (hopefully!) doesn't cause seg faults.

Still no differences expected....
</pre>
<p>[base/gdevpdfx.h base/gdevpdfp.c base/gdevpdfb.h]</p>
</blockquote>

<p><strong><a name="2011-03-07T124047.052280Z"></a>
2011-03-07T12:40:47.052280Z Chris Liddell</strong></p>
<blockquote>
<pre>
Account for fonts in which (some) charstrings have been replaced with
Postscript procedures when FAPI decides an outline, or just a width
is required. The previous code only handled this case for rendered
glyphs from Freetype.

Bug 692029

No cluster differences expected.



</pre>
<p>[psi/zfapi.c]</p>
</blockquote>

<p><strong><a name="2011-03-07T111219.973357Z"></a>
2011-03-07T11:12:19.973357Z Ken Sharp</strong></p>
<blockquote>
<pre>
pdfwrite &amp; ps2write enhancement

Add some new keys to the device parameters dictionary for these devices. These will be
used to replace the explicit tests against the device name in various places in future
commits.

These will also later be documented and their use suggested for any devices requiring
the same capabilities.

No differences expected, these are not used yet.</pre>
<p>[base/gdevpdfp.c]</p>
</blockquote>

<p><strong><a name="2011-03-07T094302.986503Z"></a>
2011-03-07T09:43:02.986503Z Chris Liddell</strong></p>
<blockquote>
<pre>
Update the second place where we may have to reset the Freetype glyph object.

Again, this means we only free the outline or bitmap data, and just let
Freetype &quot;reset&quot; its glyph object between glyphs.

No cluster differences expected.

</pre>
<p>[psi/fapi_ft.c]</p>
</blockquote>

<p><strong><a name="2011-03-07T070812.439689Z"></a>
2011-03-07T07:08:12.439689Z Ray Johnston</strong></p>
<blockquote>
<pre>
Fix for compositor device chaining in the pdf14 device. This was detected in a
file that did overprint along with transparency. The pdf14 device incremented the
ref_count for the overprint_device, but never decremented it since the 'finalize'
of the pdf14 device was left at NULL rather than being set to the gx_forward_finalize
function which should be used. The gx_device_set_target, rather than rc_assign does
the proper set of the finalize proc pointer so that reference counts for the device
chain are properly maintained. Detected by customer 532 since their device freed
the clist buf_device resulting in the overprint_device having a 'target' pointer
to freed memory, causing a SEGV when the 'finalize' function executed.

No regressions expected since in the normal code, the GC frees the devices that
were left unreferenced by the free of the pdf14 device.
</pre>
<p>[base/gdevp14.c]</p>
</blockquote>

<p><strong><a name="2011-03-06T165219.765042Z"></a>
2011-03-06T16:52:19.765042Z Michael Vrhel</strong></p>
<blockquote>
<pre>
Fix to use proper DDA incrementation for interpolation.  We still maintain special loops for when there is no scaling or for when it is 2x.  This should fix the intdeterminism issues.   Tested performance on customer files and no significant difference was observed.   About 1500 cluster differences will be reported with this fix.</pre>
<p>[base/lib.mak base/gximono.c]</p>
</blockquote>

<p><strong><a name="2011-03-06T111548.120325Z"></a>
2011-03-06T11:15:48.120325Z Chris Liddell</strong></p>
<blockquote>
<pre>
Instead of destroying and recreating freetype's glyph object for every glyph
we need to render, we can just free the &quot;transient&quot; parts: the bitmap or the
outline.

Saves a very small amount of time, and potentially reduces memory pool
fragmentation.

No cluster differences expected.

</pre>
<p>[psi/fapi_ft.c]</p>
</blockquote>

<p><strong><a name="2011-03-05T174646.608714Z"></a>
2011-03-05T17:46:46.608714Z Till Kamppeter</strong></p>
<blockquote>
<pre>
Do not do debug output of an uninitialized variable

Thanks to Richard Hughes (hughsient at gmail dot com) for the patch.

</pre>
<p>[cups/gdevcups.c]</p>
</blockquote>

<p><strong><a name="2011-03-04T192750.114304Z"></a>
2011-03-04T19:27:50.114304Z Till Kamppeter</strong></p>
<blockquote>
<pre>
Correction on Richard Hughes' patch for color management in the CUPS filters.
</pre>
<p>[cups/colord.c]</p>
</blockquote>

<p><strong><a name="2011-03-04T175100.067911Z"></a>
2011-03-04T17:51:00.067911Z Henry Stiles</strong></p>
<blockquote>
<pre>
Fix a warning and type error.  Code should produce the same results,
so no testing.

CLUSTER_UNTESTED

</pre>
<p>[base/gdevdgbr.c]</p>
</blockquote>

<p><strong><a name="2011-03-04T133411.568425Z"></a>
2011-03-04T13:34:11.568425Z Robin Watts</strong></p>
<blockquote>
<pre>
Add FIXME to gximono.c about possible future optimisation, so it is not
forgotten.

CLUSTER_UNTESTED

</pre>
<p>[base/gximono.c]</p>
</blockquote>

<p><strong><a name="2011-03-04T093504.845642Z"></a>
2011-03-04T09:35:04.845642Z Chris Liddell</strong></p>
<blockquote>
<pre>
Only attempt to create files in the &quot;cups&quot; directory if it exists.
</pre>
<p>[base/configure.ac]</p>
</blockquote>

<p><strong><a name="2011-03-04T064529.360251Z"></a>
2011-03-04T06:45:29.360251Z Michael Vrhel</strong></p>
<blockquote>
<pre>
Reorganization of threshold code to move all the thresh holding operations into a new file. </pre>
<p>[base/gxht_thresh.h base/lib.mak base/gximono.c base/gximage.h base/gxht_thresh.c base/gsiparam.h]</p>
</blockquote>

<p><strong><a name="2011-03-04T061653.560659Z"></a>
2011-03-04T06:16:53.560659Z Alex Cherepanov</strong></p>
<blockquote>
<pre>
Add missing test for /packedarraytype during recursive dereferencing
of composite PDF objects. Bug 692018, customer 850.
</pre>
<p>[Resource/Init/pdf_base.ps]</p>
</blockquote>

<p><strong><a name="2011-03-03T222022.363870Z"></a>
2011-03-03T22:20:22.363870Z Henry Stiles</strong></p>
<blockquote>
<pre>
The get_bits() device call was assumed to return copied data and fill
in the allocated memory pointed to by the variable row, in fact the
gets_bit call can also just return a pointer and row is never
initialized, now we detect that.  This broke raster operations for the
display device and appears to have resulted in the use of
uninitialized data in other files.  A sampling of changed files showed
single pixel differences in files.

</pre>
<p>[base/gdevdgbr.c]</p>
</blockquote>

<p><strong><a name="2011-03-03T202923.683592Z"></a>
2011-03-03T20:29:23.683592Z Robin Watts</strong></p>
<blockquote>
<pre>
Update plibc and plibk to output pams when built with DEBUG_DUMP.

No cluster differences possible as this code is not used in cluster testing.

CLUSTER_UNTESTED</pre>
<p>[base/gdevplib.c]</p>
</blockquote>

<p><strong><a name="2011-03-03T202343.920044Z"></a>
2011-03-03T20:23:43.920044Z Robin Watts</strong></p>
<blockquote>
<pre>
Add new pamcmyk4 device. Identical to pamcmyk32 device, but works in 1 bit
per component, rather than 8.

No cluster differences expected as this code isn't tested.</pre>
<p>[psi/msvc.mak base/unix-gcc.mak base/gdevpbm.c base/devs.mak]</p>
</blockquote>

<p><strong><a name="2011-03-03T175148.590954Z"></a>
2011-03-03T17:51:48.590954Z Michael Vrhel</strong></p>
<blockquote>
<pre>
Enabling of thresholding code as default image rendering of monochrome/indexed images for monochrome devices.  This will result in about 2432 differences reported.  I stepped through them in a bmpcmp to check for serious issues.  The minor halftone differences were due to the fact that we step in the device space for pixel replication in the threshold code but step in source space for the rect fill code.  Enabling this code now will make it easier to track issues as we expand the use of the thresholding code.</pre>
<p>[base/gximono.c]</p>
</blockquote>

<p><strong><a name="2011-03-03T154846.192376Z"></a>
2011-03-03T15:48:46.192376Z Robin Watts</strong></p>
<blockquote>
<pre>
Add plib device (c and h) files to ghostscript project file.

No cluster differences expected as project file is not used by cluster.

CLUSTER_UNTESTED</pre>
<p>[ghostscript.vcproj]</p>
</blockquote>

<p><strong><a name="2011-03-03T000827.251299Z"></a>
2011-03-03T00:08:27.251299Z Marcos H. Woehrmann</strong></p>
<blockquote>
<pre>
Added the ability to specify bmpcmp in addition to a normal clusterpush.pl
operation.  Both commands will be queued in the correct order.

Examples:

  ./clusterpush.pl gs bmpcmp
  ./clusterpush.pl bmpcmp gs pcl xps ls

Note that the order of the options is not signficant.

The command line parser for clusterpush.pl changed signficantly with this
revision.  It should be backwards compatible with the previous version
but it's possible that subtle differences exist.  If a clusterpush.pl
command line behaves differently than you expect please open a bug.

</pre>
<p>[toolbin/localcluster/clustermaster.pl toolbin/localcluster/clusterpush.pl toolbin/localcluster/clusterpush.txt]</p>
</blockquote>

<p><strong><a name="2011-03-02T221239.208205Z"></a>
2011-03-02T22:12:39.208205Z Robin Watts</strong></p>
<blockquote>
<pre>
Fix rop operation on plib device. Previously, I'd disabled get_bits_rectangle
on the buffer device as the data is normally in the format we need it in
anyway, so it's a NOP. Unfortunately it's needed for rop operation, so
reintroduce it.

To avoid infinite loops, we have to cope with GB_RETURN_POINTER. This is
easy to add to the gdevmpla.c device, but it's less clear that adding it
into the mem device is the right thing to do. We therefore introduce a
shim function to cope with GB_RETURN_POINTER with the mem device.

No cluster differences expected as this is disabled by default.

Testing shows that the planar device is now very close to the non planar
equivalent.</pre>
<p>[base/gdevplib.c base/gdevmpla.c]</p>
</blockquote>

<p><strong><a name="2011-03-02T205046.635530Z"></a>
2011-03-02T20:50:46.635530Z regression</strong></p>
<blockquote>
<pre>
Minor bug fixes and improvements to the cluster system, the most
signifcant of which is the addition of &quot;CLUSTER_UNTESTED&quot; detection.
If this keyword appears anywhere within the log message of a commit that
revision will not be tested by the cluster.

Less interesting changes include:

  Fix for bmpcmp if large numbers of differences are produced

  Addition of 'svn cleanup' calls before 'svn update' to handle nodes that
  crashed during previous 'svn update' and left the repositories locked

  Set status of all nodes to idle after jobs are completed.

  Fix bugs that caused bmpcmp completed emails to be appended to the
  previous message.

</pre>
<p>[toolbin/localcluster/clustermaster.pl toolbin/localcluster/pngs2html.pl toolbin/localcluster/build.pl toolbin/localcluster/run.pl]</p>
</blockquote>

<p><strong><a name="2011-03-02T185123.645025Z"></a>
2011-03-02T18:51:23.645025Z Michael Vrhel</strong></p>
<blockquote>
<pre>
Introduction of a member variable in gs_image1_t, which will let us know the original source type of the image.  For example if, the parent source were type3 this spawns two type1 images.  One for the mask and one for the image data.  The mask is rendered using image render simple.  If the image is monochrome or indexed, it is rendered with the renderer in gximono.c .   If we are going to a halftone monochrome device, we end up using the fast threshold based renderer which has its interpolation stepping in device space as opposed to source space.  This causes very minor differences between the mask and the image data.  To avoid this, we use the old rect_fill code for the image type3 data to ensure a more exact spatial match.</pre>
<p>[base/gximono.c base/gximage1.c base/gximage2.c base/gximage3.c base/gximage4.c base/gximage.h base/gximag3x.c base/gsiparam.h]</p>
</blockquote>

<p><strong><a name="2011-03-02T133952.433442Z"></a>
2011-03-02T13:39:52.433442Z Robin Watts</strong></p>
<blockquote>
<pre>
Fix bmpcmp bug; the map array was being incorrectly sized, resulting in
occasional memory corruption.

No cluster differences expected.</pre>
<p>[toolbin/bmpcmp.c]</p>
</blockquote>

<p><strong><a name="2011-03-02T000925.760114Z"></a>
2011-03-02T00:09:25.760114Z Robin Watts</strong></p>
<blockquote>
<pre>
Debug output for gdevplibm (monochrome planar interlaced bands) was broken
and writing malformed pbms. Simple fix - move the mono output code to the
mono branch of the if rather than the grey one.

No cluster differences expected.</pre>
<p>[base/gdevplib.c]</p>
</blockquote>

<p><strong><a name="2011-03-01T193056.622647Z"></a>
2011-03-01T19:30:56.622647Z Robin Watts</strong></p>
<blockquote>
<pre>
Remove DOS line endings from .gitignore files.</pre>
<p>[.gitignore /trunk/ghostpdl/.gitignore]</p>
</blockquote>

<p><strong><a name="2011-03-01T171830.158752Z"></a>
2011-03-01T17:18:30.158752Z Michael Vrhel</strong></p>
<blockquote>
<pre>
Fix for error introduced in non-SSE2 code when I removed the inclusion of the transfer function into the threshold values.</pre>
<p>[base/gximono.c]</p>
</blockquote>

<p><strong><a name="2011-02-28T223128.419926Z"></a>
2011-02-28T22:31:28.419926Z Till Kamppeter</strong></p>
<blockquote>
<pre>
Added color management support to the CUPS ...toraster filters

Replaced the ...toraster filters by one filter executable, gstoraster,
written in C. This filter converts both PostScript and PDF input into
the CUPS Raster format using Ghostscript with the &quot;cups&quot; output
device, controlled by settings in the print queue's PPD file, by
command line options, and by settings embedded in a PostScript input
stream. This is now done with color management based on
printer-specific ICC profiles referenced in the PPD file or supplied
by the color management daemon colord. The CUPS PPD extensions
concerning color management
(http://www.cups.org/documentation.php/doc-1.4/spec-ppd.html) are made
use of if used and the colord daemon is used if it is present. colord
is accessed via D-Bus, but the new filter can also be compiled without
D-Bus and in this case only the CUPS PPD extensions and ICC profiles
assigned to the print queue are used for color management.

Thanks to Richard Hughes for the patch.

</pre>
<p>[cups/pstoraster.in cups/pstoraster.convs cups/gstoraster.c cups/pdftoraster.c cups/cups.mak base/Makefile.in cups/colord.c base/configure.ac cups/gstoraster.convs cups/pdftoraster.convs cups/colord.h]</p>
</blockquote>

<p><strong><a name="2011-02-28T203043.994348Z"></a>
2011-02-28T20:30:43.994348Z Robin Watts</strong></p>
<blockquote>
<pre>
X offset in custom 24 -&gt; 888 planar copy_color routine was being miscalculated.
Simple fix.

No cluster differences expected as this is untested.</pre>
<p>[base/gdevmpla.c]</p>
</blockquote>

<p><strong><a name="2011-02-28T193534.539587Z"></a>
2011-02-28T19:35:34.539587Z Robin Watts</strong></p>
<blockquote>
<pre>
Remove silly debugging hack left in gdevmpla.c by accident. Only affects
planar 888 devices (i.e. none enabled by default).

No cluster differences expected.</pre>
<p>[base/gdevmpla.c]</p>
</blockquote>

<p><strong><a name="2011-02-28T193237.270892Z"></a>
2011-02-28T19:32:37.270892Z Robin Watts</strong></p>
<blockquote>
<pre>
Add simple .gitignore files.</pre>
<p>[.gitignore /trunk/ghostpdl/.gitignore]</p>
</blockquote>

<p><strong><a name="2011-02-28T104811.852106Z"></a>
2011-02-28T10:48:11.852106Z Ken Sharp</strong></p>
<blockquote>
<pre>
Silence a compiler (scan-build) warning about a variable never being used.</pre>
<p>[base/gdevpdfo.c]</p>
</blockquote>

<p><strong><a name="2011-02-28T052346.157854Z"></a>
2011-02-28T05:23:46.157854Z Michael Vrhel</strong></p>
<blockquote>
<pre>
Fix for mis-scale on decode for render mono cache.  Fixes improper rendering of 148-11.ps with new halftone code.</pre>
<p>[base/gxipixel.c]</p>
</blockquote>

<p><strong><a name="2011-02-27T232610.406657Z"></a>
2011-02-27T23:26:10.406657Z Michael Vrhel</strong></p>
<blockquote>
<pre>
Removal (or inactivation) of code to include inverse of transfer function in the threshold values.  Also minor fix for scaling issue in halftone code in portrait mode.  Code is inactive so no regression diffs expected.</pre>
<p>[base/gximono.c base/gsht.c]</p>
</blockquote>

<p><strong><a name="2011-02-27T232330.287293Z"></a>
2011-02-27T23:23:30.287293Z Michael Vrhel</strong></p>
<blockquote>
<pre>
Fix for a bug that was introduced with the ICC branch.  This was causing a mismatch between banded an unbanded rendering and in particular had rendering errors in banded mode when rendering PS and PDF files that had a non identity transfer function.  Minor progression diffs in many files with very visible progressions in 246-01.ps, 258-01.ps as examples.  What was happening is that when running in clist mode, we were not recognizing that a transfer function was present when doing the ICC branch.  Stumble upon this working the transfer function in with the new threshold based halftoning code.</pre>
<p>[base/gxipixel.c]</p>
</blockquote>

<p><strong><a name="2011-02-27T015228.834714Z"></a>
2011-02-27T01:52:28.834714Z Ray Johnston</strong></p>
<blockquote>
<pre>
Fix for PDF with ASCII85Decode filter that has a dictionary (even if empty)
instead of a 'null' for the params. Stack has the param dict second on the
stack, not third. Bug 692003, customer 700.
</pre>
<p>[Resource/Init/pdf_base.ps]</p>
</blockquote>

<p><strong><a name="2011-02-26T191752.838303Z"></a>
2011-02-26T19:17:52.838303Z Till Kamppeter</strong></p>
<blockquote>
<pre>
TCUPS Raster driver: The macros in the cups_put_params() function
could access uninitialized variables when logging error messages and
this could lead to a segmentation fault, making Ghostscript crashing
and many jobs not printed. Debian bug #615202.

</pre>
<p>[cups/gdevcups.c]</p>
</blockquote>

<p><strong><a name="2011-02-26T184059.351498Z"></a>
2011-02-26T18:40:59.351498Z Ray Johnston</strong></p>
<blockquote>
<pre>
Fix for PDF 1.7 fts_08_0808.pdf which can clip the corner of the really wide
diagonal (magenta) stroke when banding is used. This was due to the 'extension'
of a square line cap being incorrectly calculated. Customer 532 issue.
</pre>
<p>[base/gxstroke.c]</p>
</blockquote>

<p><strong><a name="2011-02-26T182508.170267Z"></a>
2011-02-26T18:25:08.170267Z Ray Johnston</strong></p>
<blockquote>
<pre>
Fix BUILD_SYSTEM conditional for 64 vs. 32 and add 'for Win64' message
to help avoid confusion during setup.
</pre>
<p>[psi/winint.mak]</p>
</blockquote>

<p><strong><a name="2011-02-25T235750.833144Z"></a>
2011-02-25T23:57:50.833144Z Robin Watts</strong></p>
<blockquote>
<pre>
Fix bug reported by &quot;new customer feb 2011&quot;, whereby gs 8.71 on an embedded
ppc platform is getting the colours on an image in a pdf wrong.

Debugging shows that in gs_indexed_limit_and_lookup we take a floating point
value, clip it, convert it to an int and use it to lookup which colour to use.
On the reference x86 run we have a value of 1 (0x3f800000 as an IEEE float).
On the ppc we have 0.999999 (0x3f7fffff as an IEEE float). This tiny difference
results in values of 1 and 0 respectively when converted to the int, giving
the wrong colour.

The fix here is to add a small epsilon before conversion.

A quick experiment in adding 0.5 rather than epsilon shows worse results.

15 cluster differences in testing, none that actually survived a bmpcmp.


</pre>
<p>[base/gscolor2.c]</p>
</blockquote>

<p><strong><a name="2011-02-25T194939.160812Z"></a>
2011-02-25T19:49:39.160812Z Michael Vrhel</strong></p>
<blockquote>
<pre>
Fix so that we only do the fast code if we are in portrait or landscape mode.  Skewed objects will have to use the rect fill method.</pre>
<p>[base/gximono.c]</p>
</blockquote>

<p><strong><a name="2011-02-25T193355.727547Z"></a>
2011-02-25T19:33:55.727547Z Michael Vrhel</strong></p>
<blockquote>
<pre>
Addition of code to incorporate the inverse of the transfer curve into the threshold matrix.  If the curve is an inverting type (e.g. 0 to 1 and 1 to 0) then a the thresholding comparison is switched.  Also, if the curve is not monotonic, it can not be inverted and we revert to the old rect fill method.  This commit has the code disabled so there should not be any regressions.</pre>
<p>[base/lib.mak base/gximono.c base/gzht.h base/gxdht.h base/gsht.c]</p>
</blockquote>

<p><strong><a name="2011-02-25T181349.002375Z"></a>
2011-02-25T18:13:49.002375Z Ray Johnston</strong></p>
<blockquote>
<pre>
Set the GS_DLL to gsdll64.dll for a 64-bit build. The file list was correct,
but the registry was not. Related to bug 691975 but not verified (I just
checked the registry using regedit).
</pre>
<p>[psi/dwsetup.cpp]</p>
</blockquote>

<p><strong><a name="2011-02-25T074221.024741Z"></a>
2011-02-25T07:42:21.024741Z Chris Liddell</strong></p>
<blockquote>
<pre>
Revise how the UFST setting are handled in the makefiles.

The previous version relied on GNU make extensions (specifically
conditionals), whilst this version does not.

No cluster differences expected.

</pre>
<p>[base/lib.mak psi/msvc.mak base/Makefile.in psi/int.mak]</p>
</blockquote>

<p><strong><a name="2011-02-24T111312.751072Z"></a>
2011-02-24T11:13:12.751072Z Chris Liddell</strong></p>
<blockquote>
<pre>
Hopefully the final iteration of allowing SHARE_ZLIB
to work correctly with COMPILE_INITS=1.

This version changes only Unix-like builds, so Windows need
not suffer, and also removes the reliance GNU make specific
extensions.

Bug 691986
	

No cluster differences.

</pre>
<p>[base/unix-aux.mak]</p>
</blockquote>

<p><strong><a name="2011-02-24T005108.210054Z"></a>
2011-02-24T00:51:08.210054Z Robin Watts</strong></p>
<blockquote>
<pre>
Add new plib family of devices (PLanar Interlaced Buffer). These 5 devices
(plib = r8g8b8, plibg = g8, plibm = mono, plibc = c8m8y8k8, plibk = c1m1y1k1)
use a new 'band donor' interface to request a band buffer, pass back
rendered bands, and release bands at the end of the page.

The idea is that other firmware can implement this simple interface, and
Ghostscript can thus easily drive systems that expect planar interlaced
input.

On the whole there is relatively little new code here; the majority of the
work is done using the existing planar device with the odd tweak here and
there. Firstly, we lift the (artifical) constraints of the number of components
supported (so greyscale is accepted as a planar device for simplicity).
We spot the num_components = 1 case and just use the existing memory device
interface.

Secondly, we add a fast 888chunky to 888planar unpacking routine for use
with copy_color.

Within the plib device itself, we make use of the facility to set the line
indexes to allow for interlaced operation. It would be easy to extend this
device to offer planar non-interlaced operation too built on the same band
donor interface simply by omitting this code.

For debugging purposes we have options within the plib devices to store the
data returned in each band into pxm files (as appropriate to the number of
components). This code is deactivated by default as the output of this
device is via the band donor interface, not the output file.

No cluster differences expected as this code is disabled currently.

Next job: discuss with Marcos how to cluster test this.

</pre>
<p>[base/gdevplib.c base/gdevmpla.c base/gdevplib.h base/gdevppla.c base/devs.mak]</p>
</blockquote>

<p><strong><a name="2011-02-23T160025.505362Z"></a>
2011-02-23T16:00:25.505362Z Robin Watts</strong></p>
<blockquote>
<pre>
Introduce and enable 8 bit rop run templated code.

No cluster differences shown.

</pre>
<p>[base/gsroprun8.h base/lib.mak base/gsroprun.c ghostscript.vcproj]</p>
</blockquote>

<p><strong><a name="2011-02-23T144145.053687Z"></a>
2011-02-23T14:41:45.053687Z Michael Vrhel</strong></p>
<blockquote>
<pre>
Remove commented out code left over from commit 12192</pre>
<p>[base/lib.mak]</p>
</blockquote>

<p><strong><a name="2011-02-23T115400.145784Z"></a>
2011-02-23T11:54:00.145784Z Robin Watts</strong></p>
<blockquote>
<pre>
Reintroduce runrop changes to Visual Studio solution lost in recent merge
(r12189).

No cluster differences expected.

</pre>
<p>[ghostscript.vcproj]</p>
</blockquote>

<p><strong><a name="2011-02-23T082540.039813Z"></a>
2011-02-23T08:25:40.039813Z Chris Liddell</strong></p>
<blockquote>
<pre>
Revision to the changes for using the system zlib.

r12184 caused problems on Windows. 

This approach uses configure to determine whether
freetype should use the system zlib, based on whether
Ghostscript is using the system zlib.

Windows, of course, doesn't use configure, so it will
never attempt to the use the system zlib.

Bug 691986

No cluster differences expected

</pre>
<p>[base/freetype.mak base/Makefile.in base/configure.ac]</p>
</blockquote>

<p><strong><a name="2011-02-23T032618.063337Z"></a>
2011-02-23T03:26:18.063337Z Michael Vrhel</strong></p>
<blockquote>
<pre>
Temporary fix to turn off fast code for cases where the bps of the index image is not 8bps</pre>
<p>[base/gximono.c]</p>
</blockquote>

<p><strong><a name="2011-02-23T010908.645858Z"></a>
2011-02-23T01:09:08.645858Z Michael Vrhel</strong></p>
<blockquote>
<pre>
Undo of rev 12184 by commenting out the changes for now.  This change broke the windows build.  </pre>
<p>[base/lib.mak]</p>
</blockquote>

<p><strong><a name="2011-02-22T213158.870907Z"></a>
2011-02-22T21:31:58.870907Z Robin Watts</strong></p>
<blockquote>
<pre>
Fix warnings caused by merging the halftone branch to the trunk in r12189.

No cluster differences expected.

</pre>
<p>[base/gxipixel.c base/gximono.c base/gsht.c]</p>
</blockquote>

<p><strong><a name="2011-02-22T200337.651092Z"></a>
2011-02-22T20:03:37.651092Z Robin Watts</strong></p>
<blockquote>
<pre>
Forgot this file inthe last commit. Sorry!

</pre>
<p>[base/gsroprun24.h]</p>
</blockquote>

<p><strong><a name="2011-02-22T195243.275685Z"></a>
2011-02-22T19:52:43.275685Z Michael Vrhel</strong></p>
<blockquote>
<pre>
Merge of halftone branch into the trunk.  The new rendering code is actually disabled with this commit.  As such, there should not be any testing differences.</pre>
<p>[base/gxipixel.c base/lib.mak base/Makefile.in base/gxcie.h /trunk/gs base/gsht.c base/gxcmap.c psi/msvc.mak ghostscript.vcproj base/gximono.c base/gzht.h base/gxidata.c base/configure.ac base/gxdht.h base/gxcmap.h base/gxicolor.c base/gximage.h base/gsciemap.c]</p>
</blockquote>

<p><strong><a name="2011-02-22T193857.296889Z"></a>
2011-02-22T19:38:57.296889Z Robin Watts</strong></p>
<blockquote>
<pre>
Add templated 24bit rops. Clusterpushing seems to indicate this works.

No cluster differences expected.

</pre>
<p>[base/lib.mak base/gsroprun.c base/gsroprun1.h]</p>
</blockquote>

<p><strong><a name="2011-02-22T161008.900201Z"></a>
2011-02-22T16:10:08.900201Z Chris Liddell</strong></p>
<blockquote>
<pre>
Tweak to allow compressed romfs to be built when we're configured
to use the system's zlib rather than our own.

As a side effect of this, freetype is now configured to use the
same zlib instance as Ghostscript (instead of freetype's own
subset of zlib sources).

Bug 691986

No cluster differences expected.

</pre>
<p>[base/freetype.mak base/lib.mak]</p>
</blockquote>

<p><strong><a name="2011-02-22T154409.440053Z"></a>
2011-02-22T15:44:09.440053Z Robin Watts</strong></p>
<blockquote>
<pre>
Add new gsroprun files to Visual Studio solution.

No cluster differences expected.

</pre>
<p>[ghostscript.vcproj]</p>
</blockquote>

<p><strong><a name="2011-02-22T152803.132855Z"></a>
2011-02-22T15:28:03.132855Z Robin Watts</strong></p>
<blockquote>
<pre>
Fix DO_FILL_RECT_BY_COPY_ROP code, and enable it by default.

The only thing wrong with the code before is the case when strip_tile_rectangle
is called with both color0 and color1 being gx_no_color_index. That translates
to rop=0xAA (i.e. D - no change). This is actually a special case that means
it's really doing a copy_color operation. We handle this by punting in the
same way as the old code used to.

No cluster differences expected.

</pre>
<p>[base/gdevm1.c]</p>
</blockquote>

<p><strong><a name="2011-02-22T001816.845591Z"></a>
2011-02-22T00:18:16.845591Z Robin Watts</strong></p>
<blockquote>
<pre>
Enable mono_copy_mono implemented in terms of mono_copy_rop.

Very small changes to the code to ensure that the copied area is correctly
clipped, this now gives identical results to the existing code, but should
be faster.

The tile_rectangle code is still misbehaving - will fix this in later
revisions (I hope).

No cluster differences expected.

</pre>
<p>[base/gdevm1.c]</p>
</blockquote>

<p><strong><a name="2011-02-21T171210.825257Z"></a>
2011-02-21T17:12:10.825257Z Robin Watts</strong></p>
<blockquote>
<pre>
Recommit of 12163 to the trunk.

The fit_copy macro checks for the start address being off the top of the
screen, and clips it to zero. When it does this, it does: data -= y * raster,
which gives problems if raster is a uint ( as uint * int == uint in C) and
data is a 64 bit pointer.

The fix is simply to cast the result to an int before using it. This solves
various SEGVs with the mono_copy_mono using mono_copy_rop code.

No cluster differences expected.

</pre>
<p>[base/gxdevice.h]</p>
</blockquote>

<p><strong><a name="2011-02-21T160425.039434Z"></a>
2011-02-21T16:04:25.039434Z Chris Liddell</strong></p>
<blockquote>
<pre>
The structure containing the pthreads native elements making up a
gp_semaphore structure was ending up incorrectly aligned on
sparc32 Linux systems, and caused a bus error. Annoyingly, sparc32
uses 32 bit pointers but requires 64 bit aligment.

This change enforces maximum alignment for the elements of
gp_semaphore, for the current platform.

No cluster differences expected.

Bug 691989

</pre>
<p>[base/lib.mak base/gpsync.h]</p>
</blockquote>

<p><strong><a name="2011-02-21T122920.951013Z"></a>
2011-02-21T12:29:20.951013Z Robin Watts</strong></p>
<blockquote>
<pre>
Fix stupid typo in gsroprun.c that was causing templated rops to be different
to non templated rops. With this fixed the cluster shows identical results
(modulo indeterminisms), but the templated code is faster - so enable by
default.

No cluster differences expected.

</pre>
<p>[base/gsroprun.c]</p>
</blockquote>

<p><strong><a name="2011-02-20T124120.382249Z"></a>
2011-02-20T12:41:20.382249Z Robin Watts</strong></p>
<blockquote>
<pre>
Initial reorganisation of code towards using copy_rops for copy_mono.

Split the guts of mem_mono_strip_copy_rop out into a separate function
mem_mem_strip_copy_rop_dev. This new function handles the actual copy in
device space, leaving the original to cope with fiddling the rop according
to colors.

This 'inner' function is moved to gdevm1.c so it is present in both gs
and ghostpcl builds. The existing (bitrotted) code in gdevm1.c to
'USE_COPY_ROP' is revamped to call mem_strip_copy_rop_dev, but is disabled
currently as the cluster is showing a few differences that need to be
tracked down.

Also, this introduces new code to do gsroprun's using code in a generic
header file that gets repeatedly #included with different options. This
code is currently disabled until we can verify that it gives identical
results. The new 'templated' code uses native ints where possible, and
(in initial limited testing) seems to perform better than copy_mono.

No cluster differences expected.

</pre>
<p>[base/gdevmem.h base/lib.mak base/gsroprun.c base/gdevm1.c base/gsropt.h base/gsroprun1.h base/gdevmr1.c]</p>
</blockquote>

<p><strong><a name="2011-02-19T070113.923016Z"></a>
2011-02-19T07:01:13.923016Z Alex Cherepanov</strong></p>
<blockquote>
<pre>
Add a missing check for null value during PDF resource enumeration.
Bug 691892, customer 532.
</pre>
<p>[Resource/Init/pdf_main.ps]</p>
</blockquote>

<p><strong><a name="2011-02-18T132259.764503Z"></a>
2011-02-18T13:22:59.764503Z Robin Watts</strong></p>
<blockquote>
<pre>
Committing fix for Bug 689031 submitted by Shailesh Mistry under the
bug bounty program. Tests out fine (1 minor difference, looks like a
progression to me).

See bug for full discussion, but basically this removes a few calls to
path_position_valid in exchange for accessing the equivalent data kept
locally.


</pre>
<p>[base/gxchar.c base/gzpath.h base/gxccache.c base/gspath1.c]</p>
</blockquote>

<p><strong><a name="2011-02-18T115125.345393Z"></a>
2011-02-18T11:51:25.345393Z Ken Sharp</strong></p>
<blockquote>
<pre>
Enhancement (pdfwrite) : performance improvement

Bug #691946 &quot;Conversion to PDF becomes slower and slower&quot;

There are many places where pdfwrite compares composite objects for equality. This can
be a very slow process, depending on the nature of the object, and becomes progressively
slower as more object are added to storage.

Previously we had added a MD5 hash to the stream data of a cos_stream in order to
improve the performance when checking fonts for equality, this change takes the whole
process much further. We now store an MD5 'fingerprint' for each composite object, 
initially this is not computed and is marked as not valid.

Whenever an equality test takes place we check to see if the composite object has an MD5
hash calculated, and if it does, we compare the MD5 hashes. If it does not then we 
compute an MD5 hash, store it, and mark it as valid. Note that for cos_stream types
we store *two* hashes, one for the dictionary and one for the stream data.

If we alter the contents of a composite object then we mark its MD5 hash as invalid so
that we recompute it on the next occurence. Technically there could be a problem if
a composite object contains a composite object, and the descendant object is altered
after the MD5 hash is calculated for the parent. However this should not occur given
the way these structures are used (these are pdfwrite internal structures, *not* PS or
PDF objects available to the interpreter).

This very significantly improves performance on some files, the test file for bug
#691946 takes 2642 seconds without this change (and DetectDuplicateImages true) while
it takes 963 seconds after this change.

Note that this change depends on revision 12169 and should ideally be used with
revisions 12168 to 12171 inclusive.

No other differences expected.
</pre>
<p>[base/gdevpdfo.c base/gdevpdfo.h]</p>
</blockquote>

<p><strong><a name="2011-02-18T113756.561896Z"></a>
2011-02-18T11:37:56.561896Z Ken Sharp</strong></p>
<blockquote>
<pre>
Fix (pdfwrite) : images being scaled incorrectly

Found while dealing with other problems. pdfwrite uses the image 'height' (rendered
height) and number of lines of data to calculate a 'scale' which it then applies to
the current Transformation Matrix in order to calculate an image matrix.

However, when an image was detected as a duplicate, the scale factor was calculated
from the first image's dimensions, and then applied to the CTM for the second matrix.

This did not appear to cause problems for PostScript and PDF but causes serious bugs
in a number of PCL files, and was clearly incorrect. We now save and restore the
height and width when substituting images to prevent this problem

</pre>
<p>[base/gdevpdfj.c]</p>
</blockquote>

<p><strong><a name="2011-02-18T113207.033929Z"></a>
2011-02-18T11:32:07.033929Z Ken Sharp</strong></p>
<blockquote>
<pre>
enhancement (pdfwrite) : Allow duplication image detection to be disabled

pdfwrite tests every (non-inline) image against every other stored image to see if it is
a duplicate, and if so does not embed the duplicate in the output but simply references
the original.

This can be slow for files with many images (each stored image must be checked when a
new image is encountered) and may be of limited benefit.

The new flag DetectDuplicateImages (default true) can be used to enable or disable
this behaviour

No differences expected
</pre>
<p>[base/gdevpdfj.c base/gdevpdfx.h base/gdevpdfp.c doc/Ps2pdf.htm base/gdevpdfb.h]</p>
</blockquote>

<p><strong><a name="2011-02-18T112524.853829Z"></a>
2011-02-18T11:25:24.853829Z Ken Sharp</strong></p>
<blockquote>
<pre>
Fix (pdfwrite) : Correction to an equality test

This fixes a long-standing bug when checking the equality of patterns. 

We need to ensure when substituting patterns that neither of the patterns is already
substituted. But the code only tested one of the patterns (and was a duplicate of
another test), which led to incorrect results. This should always have been a problem
but for some reason seems to have been masked in previous releases. New code for
testing equality of composite objects revealed the problem.

No differences expected, as the problem is only revealed with code which follows in a
subsequent commit.
</pre>
<p>[base/gdevpdfi.c]</p>
</blockquote>

<p><strong><a name="2011-02-18T111523.457563Z"></a>
2011-02-18T11:15:23.457563Z Ken Sharp</strong></p>
<blockquote>
<pre>
Fix a typo in an enumerated type. No differences expected.
</pre>
<p>[base/gxhldevc.h base/gxhldevc.c base/gdevpdfg.c]</p>
</blockquote>

<p><strong><a name="2011-02-15T163659.934186Z"></a>
2011-02-15T16:36:59.934186Z Henry Stiles</strong></p>
<blockquote>
<pre>
Double the allowed space for cached chars and increase the maximum
byte size of a single glyph that can be cached.
</pre>
<p>[base/gsfont.c]</p>
</blockquote>

<p><strong><a name="2011-02-15T150755.282721Z"></a>
2011-02-15T15:07:55.282721Z Ray Johnston</strong></p>
<blockquote>
<pre>
Fix for building the gs***w64.exe self extracting installer compatible with
the new 64-bit binary naming and makefile macro (BUILD_SYSTEM)
</pre>
<p>[psi/winint.mak]</p>
</blockquote>

<p><strong><a name="2011-02-15T092128.927211Z"></a>
2011-02-15T09:21:28.927211Z Chris Liddell</strong></p>
<blockquote>
<pre>
Ensure that the OpenPrinting drivers get removed from the drivers list
if iconv/libiconv are not available.

The strings used to identify the drivers in the list were incorrect.

</pre>
<p>[base/configure.ac]</p>
</blockquote>

<p><strong><a name="2011-02-14T203933.924424Z"></a>
2011-02-14T20:39:33.924424Z Robin Watts</strong></p>
<blockquote>
<pre>
Fix Bug 691917. In revision 11146 I made op_array_table_global and
op_array_table_local be elements of the context rather than being
globals, and changed all the code to access these elements through
the context.

Unfortunately I forgot to cope with when new contexts are generated by
forking execution. The correct fix is, I believe to simply copy the
op_table pointers over to the new context. This has been done here, and
seems to solve the reported bug.

No cluster differences expected.

</pre>
<p>[psi/zcontext.c]</p>
</blockquote>

<p><strong><a name="2011-02-14T110439.509187Z"></a>
2011-02-14T11:04:39.509187Z Till Kamppeter</strong></p>
<blockquote>
<pre>
Removed a tab accidentally introduced in rev 12082.
</pre>
<p>[Resource/Init/cidfmap]</p>
</blockquote>

<p><strong><a name="2011-02-10T171423.128533Z"></a>
2011-02-10T17:14:23.128533Z Chris Liddell</strong></p>
<blockquote>
<pre>
Ensure that a --build option is propogated to the other
configure scripts we call.

</pre>
<p>[base/configure.ac]</p>
</blockquote>

<p><strong><a name="2011-02-10T132158.493309Z"></a>
2011-02-10T13:21:58.493309Z Ken Sharp</strong></p>
<blockquote>
<pre>
fix error in revision 12140

When fetching the size of the stream for a /Indexed colour space, omitted to check if the
/Length of the stream was an indirect object. Now dereference the object if this is the
case.

Should fix the 14 files with errors introduced in 12140.
</pre>
<p>[Resource/Init/pdf_draw.ps]</p>
</blockquote>

<p><strong><a name="2011-02-10T104326.255155Z"></a>
2011-02-10T10:43:26.255155Z Ken Sharp</strong></p>
<blockquote>
<pre>
Fix : colour space handling bug and improved handling of broken ICC space

Bug #691941 &quot;Interpretation of PDF aborts with /typecheck&quot;

The PDF file in the specimen contains an invalid colour space of the form:

/Indexed [/ICCBased &lt;&lt;/N 1 /Alternate [/Indexed /DeviceRGB 255 7 0 R]&gt;&gt;] 255 7 0 R]

The number of components in the ICCBased specification is incorrect, as the profile has
3 channels. This was not detected previously. Falling back to the /Alternate we see
that we have a /Indexed space depending on a /Indexed space which is also invalid, but
we choose to ignore this.

There was also a bug in the colour space handling for ICCbased spaces which caused a
typecheck if the alternate space was a /Indexed space.

Finally, the PDF interpreter is updated so that when given a stream as the data source
for a /Indexed space it reads and returns a string which is the greater of the declared
size of the stream, or the calculated size required, given the number of components. 
Previously we always returned the calculated size, which was too little in this case
as the number of components in the ICCBased space is incorrect.

With these changes the (invalid) specimen file runs to completion. 

No differences expected.
</pre>
<p>[psi/zcolor.c psi/zicc.c Resource/Init/pdf_draw.ps]</p>
</blockquote>

<p><strong><a name="2011-02-10T103323.506445Z"></a>
2011-02-10T10:33:23.506445Z Ken Sharp</strong></p>
<blockquote>
<pre>
Fix Bug #691918

Update the Unicode decodings applied to TrueType fonts to match the latest Adobe glyph
list. Fixes some problems with incorrect mappings and adds numerous new mappings. A
similar but less extensive change is made to the FCO_Unicode mappings as well.

Thanks to SaGS for the work on this problem.

No differences expected as these are only used for ToUnicode CMaps.</pre>
<p>[Resource/Decoding/Unicode Resource/Decoding/FCO_Unicode]</p>
</blockquote>
</body>
</html>
ghostscript-doc 9.06~dfsg-2+deb8u7 / usr / share / doc / ghostscript / Details.htm
