Sophie

Sophie

distrib > CentOS > 5 > x86_64 > by-pkgid > 1ab3b0ad0aab8c375e64a3e8e5d97007 > files > 52

ghostscript-8.70-15.el5_9.3.i386.rpm

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"   "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>Ghostscript change history (detailed)</title></title>
<!-- generated by split_changelog.py from the output of cvs2cl.pl -->
<!-- $Id: Details.htm 9906 2009-07-28 19:46:52Z giles $ -->
<link rel=stylesheet type="text/css" href="gs.css">
</head>
<body>

<p><strong><a name="2009-07-28T193506.647161Z"></a>
2009-07-28T19:35:06.647161Z Ralph Giles</strong></p>
<blockquote>
<pre>
Update release version and date for 8.70rc1.
</pre>
<p>[doc/History7.htm doc/Projects.htm doc/History8.htm man/dvipdf.1 base/gscdef.c man/ps2ascii.1 doc/Use.htm doc/Readme.htm doc/Source.htm doc/Deprecated.htm man/ps2epsi.1 doc/Install.htm doc/API.htm doc/Issues.htm doc/DLL.htm doc/Drivers.htm man/pfbtopfa.1 doc/Release.htm doc/Commprod.htm doc/Xfonts.htm doc/Devices.htm doc/Language.htm man/gs.1 man/pf2afm.1 doc/Fonts.htm doc/Ps2ps2.htm man/printafm.1 doc/Ps2pdf.htm doc/Develop.htm doc/Helpers.htm man/pdf2dsc.1 doc/Psfiles.htm doc/Lib.htm doc/gs-vms.hlp man/font2c.1 man/gsnd.1 man/pdfopt.1 doc/News.htm man/pdf2ps.1 man/ps2pdf.1 doc/Make.htm doc/Details8.htm doc/Unix-lpr.htm doc/C-style.htm doc/Ps-style.htm doc/History1.htm doc/History2.htm man/gslp.1 man/wftopfa.1 doc/History3.htm man/ps2ps.1 doc/Ps2epsi.htm doc/History4.htm man/ps2pdfwr.1 doc/History5.htm doc/History6.htm]</p>
</blockquote>

<p><strong><a name="2009-07-28T193052.619540Z"></a>
2009-07-28T19:30:52.619540Z Ralph Giles</strong></p>
<blockquote>
<pre>
Document the cat.ps utility.
</pre>
<p>[doc/Psfiles.htm]</p>
</blockquote>

<p><strong><a name="2009-07-28T191113.726309Z"></a>
2009-07-28T19:11:13.726309Z Ralph Giles</strong></p>
<blockquote>
<pre>
Add release notes for 8.70rc1.
</pre>
<p>[doc/News.htm]</p>
</blockquote>

<p><strong><a name="2009-07-28T182058.792176Z"></a>
2009-07-28T18:20:58.792176Z Alex Cherepanov</strong></p>
<blockquote>
<pre>
Change the operand types of encode_binary_token() to match the
the type of PostScript integers in the ref structure. Bug 690660.

</pre>
<p>[psi/iscanbin.c psi/btoken.h]</p>
</blockquote>

<p><strong><a name="2009-07-28T171643.839663Z"></a>
2009-07-28T17:16:43.839663Z Ralph Giles</strong></p>
<blockquote>
<pre>
Bump the release number to 8.70.

The numerous transparency and smask fixes justify a new minor number.
</pre>
<p>[base/version.mak Resource/Init/gs_init.ps doc/News.htm]</p>
</blockquote>

<p><strong><a name="2009-07-28T165534.923668Z"></a>
2009-07-28T16:55:34.923668Z Alex Cherepanov</strong></p>
<blockquote>
<pre>
Fix incorrect right shift on 64-bit platforms. PLRM defines bitshift operator
as a logical shift. On 64-bit platform, the integer operand was promoted to
64-bit long value, shifted, and assigned back to 32-bit int, effectively
emulating the sign extension.

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

<p><strong><a name="2009-07-28T164926.940894Z"></a>
2009-07-28T16:49:26.940894Z Ralph Giles</strong></p>
<blockquote>
<pre>
Work around problems with XInitImage and large rasters.

Patch from Russ Cox, fixes Bugs 689547 and 689561.

Details:

The patch sets bitmap_pad, and passes 0 for bytes_per_line in
cases were current xorg can correctly generate a value. Russ writes:

I have tracked down the problem, and it appears to be a bad interaction
between
gs and recent sanity checking in the X library.

In particular, sometimes x_copy_image in gdevx.c gets called with wide
widths but narrow raster values.  Even though the raster is apparently
wrong, the X graphics operations would work okay with that value.  But
new versions of X11 have various checks in XInitImage, one of which is
that the raster is greater than or equal to the width of the image times
the depth.

To see that this diagnosis is correct, replacing the call to XInitImage
with a call to _XInitImageFuncPtrs (which is just XInitImage without the
sanity checking) makes gs start working.  But of course
_XInitImageFuncPtrs is not a public interface function and thus probably
not the best fix.  Replacing the &quot;bytes_per_line = raster&quot; with
&quot;bytes_per_line = 0&quot; (which makes X compute the value from width and
depth) works fine in the zoom levels that would otherwise crash but
causes the previously-working zoom levels to shear the image (or worse),
presumably because the &quot;obvious&quot; raster is not the right one at those
levels.

Also, the new XInitImage also requires bitmap_pad be set always.

The patch below also fixes the problem -- I can run &quot;gv pprof.ps&quot; at all
zoom levels, and I can also zoom into regular documents.

Perhaps it is not the right fix -- perhaps the actual bug is that
x_copy_image is being called with a bad raster value in the first place.
But it does work.</pre>
<p>[base/gdevx.c]</p>
</blockquote>

<p><strong><a name="2009-07-28T162051.749226Z"></a>
2009-07-28T16:20:51.749226Z Ken Sharp</strong></p>
<blockquote>
<pre>
Fix (pdfwrite): Excessive redefinitions of CIDFonts causing memory exhaustion

Details:
bug #690642: &quot;conversion to PDF aborts after 800 pages&quot;

When instantiating a CIDFont with TrueType outlines, the TrueType interpretation code
tries to name the font using the name table from the TrueType font. If there is no name
table (as is the case for CIDFonts with TT outlines) it instead uses the XUID as the
name.

The XUID is incremented on every use, this means that each time the font is instantiated
(up to once per page when the job is PDF) we create a new CIDFont with a new name.
pdfwrite is unable to determine that these are all in fact the same original font, and
creates many fonts in the output file, eventually leading to memory exhaustion.

This change creates a new key in the current dictionary '/PDFCIDFontName', while
processing a CIDFont with TrueType outlines for a PDF file, which is the same as the
CIDFont BaseFont name. Since PDF can only have one descendant font per CIDFont this
should not cause name collisions. To avoid interference with PostScript the key is
removed from the current dictionary after use.

In the TrueType interpreter, if we are handling a CIDRFont then after loading the TT
tables we check to see if /PDFCIDFontName is defined. If it is we use it to replace the
/FontName and /CIFontName values. This means we only ever create the font with a single
name, which avoids the confusion with pdfwrite.

With this change pdfwrite only emits a single font and, usefully, it has the same name
as the font in the original PDF file. 

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

<p><strong><a name="2009-07-28T074819.388013Z"></a>
2009-07-28T07:48:19.388013Z Ralph Giles</strong></p>
<blockquote>
<pre>
Add bounds checking to various icclib functions.

Based on a set of patches by Jan Lieskovsky at Red Hat,
addressing CVE-2009-0583 and CVE-2009-0792.

Details:

Various _get_size and _write methods in icclib 2.01 were vulnerable to
integer overflow from corrupt or malicious profile data. This commit
makes a number of changes to address this.

First, it enforces bounds checking on array indicies generated through
tag data lookup or floating point calculations, either throwing an error
or clamping, depending on the context.

Second, it converts a number of malloc(nelement*size) calls into
calloc(nelements, size), passing responsibility for overflow control
to the standard library. This works on recent glibc, MacOS 10.4 (at
least) and MSVC 2005 (at least; I believe MSVC 6 doesn't check for
overflow). Systems which overcommit memory allocations generally also
lazily zero pages, so the performance implications of an overflow in
calloc() resulting in a huge allocation (or the same happening at the
request of corrupt or malicious ICC profile data) are not as bad as
might appear relative to the original malloc(). From the other side,
multi-processing systems must often zero pages delivered to malloc
anyway to prevent information leakage.

On top of Jan's patches, this commit uses a fallback for SIZE_MAX, a
stdint.h define which isn't available on all platforms (notably MSVC),
and changes a number error message to match the malloc-&gt;calloc changes.

It fixes a serious bug where the new error checking code incorrectly
rejected valid profiles with an MLUT but no black point tag.
icc_get_luobj() always tried to load the black point tag, and if it
wasn't found, icc_read_tag() would set an error flag, which was later
picked up in icmLut_read() by the check added for the results of
icmLut_get_size(). Since the black point tag is optional, and icclib
already substitutes a default (0,0,0) black point if none is contained
in the profile, we just reset the error condition within
icc_get_luobj(). vtm2k.pdf is a good testfile for this issue.

Likewise, the length of lookup tables was limited to 100 points, as a 
resource consumption constraint, but the spec allows LUTs with up
to 255 points. Bug690495.pdf from the regression suite triggered
this problem.

Thanks to Michael Vrhel for these last two fixes.

</pre>
<p>[icclib/icc.c]</p>
</blockquote>

<p><strong><a name="2009-07-27T165950.188520Z"></a>
2009-07-27T16:59:50.188520Z Till Kamppeter</strong></p>
<blockquote>
<pre>
Update of the Esc/Page laser printer drivers from Epson and Avasys, new output devices &quot;eplmono&quot; and &quot;eplcolor&quot;, and new media types.
</pre>
<p>[contrib/contrib.mak contrib/eplaser/gdevescv.h base/configure.ac contrib/eplaser/gdevescv.c]</p>
</blockquote>

<p><strong><a name="2009-07-27T003035.025070Z"></a>
2009-07-27T00:30:35.025070Z Marcos H. Woehrmann</strong></p>
<blockquote>
<pre>
The fill adjustment change in r9882 was too great; this rev changes it to 0.3 (from the original 0.25).
</pre>
<p>[base/gsstate.c]</p>
</blockquote>

<p><strong><a name="2009-07-24T190305.883160Z"></a>
2009-07-24T19:03:05.883160Z Ray Johnston</strong></p>
<blockquote>
<pre>
Add some debug that can be handy in tracing memory usage with the chunk manager.
This code has not effect on non-debug builds.
</pre>
<p>[base/gsmchunk.c]</p>
</blockquote>

<p><strong><a name="2009-07-24T142119.243209Z"></a>
2009-07-24T14:21:19.243209Z Ken Sharp</strong></p>
<blockquote>
<pre>
Fix (pdfwrite) : Incorrect table in /Unicode /Decoding Resource

Details
Bug #690648 &quot;many incorrectly encoded Latin Extended-A characters&quot;

The job in this issue contains a subset incrementally downloaded TrueType font where
the Encoding is such that the first glyph encountered is encoded at character
position 1, the second at position two and so on. In addition there is no
GlyphNames2Unicode dictionary.

pdfwrite tries, whenever possible, to write a ToUnicode CMap into the output PDF file
which allows Acrobat and other consumers to copy and paste text using Unicode values.
Since there is no Unicode information in the file, and the Encoding is distinctly 
non-standard, we fall all the way back to using the glyph names as a last ditch
attempt to generate the Unicode information.

This relies on the /Unicode /decoding resource, it seems that many glyphs in this
resource were (and possibly still may be) encoded at the wrong Unicode code points. 
This patch fixes the glyphs raised in the bug report, there may be others.

</pre>
<p>[Resource/Decoding/Unicode]</p>
</blockquote>

<p><strong><a name="2009-07-23T173417.505092Z"></a>
2009-07-23T17:34:17.505092Z Henry Stiles</strong></p>
<blockquote>
<pre>
Temporarily address bug #690646 with a fatter fill adjustment default.
This will only affect tests with resolutions less than 150 dpi.  The
change makes superfluous code in gs_init.ps which initializes the
default fill adjust to .5 iff the resolution is greater than or equal
to 150 dpi.
</pre>
<p>[base/gsstate.c]</p>
</blockquote>

<p><strong><a name="2009-07-22T210942.692668Z"></a>
2009-07-22T21:09:42.692668Z Michael Vrhel</strong></p>
<blockquote>
<pre>
The commits provides proper transparency support for fills with patterns that contain transparency. This is a merge of the pattern_trans branch into the trunk. 

DETAILS:

When a pattern contains a transparency, it should be blended with the underlying objects according to the current extended graphic state settings (e.g. knockout, blend mode etc).  Prior to this commit, patterns with transparency behaved always as knockout fills.  This fixes Bug 690467 and fixes issues for files that contain transparency patterns in the regression suite when using the pbm output device.
When a transparency is present in a pattern, a pdf14 device is pushed.  Pattern accumulation will then occur in the transparency buffer.  When the accumulation completes, the buffer that is created is no longer passed to the pattern tile object gx_pattern_trans_t through pdf14_put_image, but instead the buffer and various details about the buffer are placed in the existing planar form into a new member of gx_pattern_trans_t called ttrans.  
When a  path is to be filled with the pattern, we will be in pdf14_fill_path.  If the color to fill with is of type pattern1_color, then we will do a call to pdf14_tile_pattern_fill which pushes a transparency group the size of the path that we are filling, in the base color space of the tile.  We decompose the path to a rectangle list which is then filled using gx_trans_pattern_fill_rect.  If the fill is simple, i.e. if the tile step size and tile size are the same, then a straight forward non-overlapping fill of the rectangle occurs.  Otherwise a more complex filling occurs where the tiles may overlap.  If the tiles overlap, then blending will need to occur.  Optimizations were implemented to avoid blending if it is not required.  In addition, memcpy was used for the inner loop filling (rows) when dealing with the non overlapped case.  Going from planar data in the tile buffer to planar data in the transparency group that we are filling is much more efficient then switching between planar to chunky and back to planar like we would have had to do if we had used pdf14_put_image and stored the tile data in the buffer that is used for the nontransparency case.  Once the fill completes, the transparency group is popped, which will perform the appropriate blending with the parent group in the proper color space.
Currently it is not allowed to have the transparency tile stored as a clist.  Instead the tile is always stored in the ttrans object.  It would probably be worthwhile to fix this at some point.  When we are doing clist processing, code was added to write  (gx_dc_pattern_trans_write_raster) and read (gx_dc_pattern_read_trans_buff) the ttrans object to and from the clist.  

DIFFERENCES EXPECTED:

tests_private/comparefiles/Bug688631.pdf (pbmraw 600dpi) tests_private/comparefiles/Bug688728a.pdf (pbmraw 600dpi) tests_private/comparefiles/Bug688728b.pdf (pbmraw 600dpi)
tests_private/comparefiles/Bug689422.pdf (ppmraw 600dpi)
tests_private/comparefiles/Bug689422.pdf (pkmraw 600dpi)
tests_private/comparefiles/Bug688728.pdf (pbmraw 600dpi)
</pre>
<p>[psi/zpcolor.c base/gdevp14.c base/gsptype1.c base/lib.mak base/gdevp14.h base/gxpcmap.c base/gsptype1.h psi/int.mak base/gxpcolor.h base/gxcolor2.h /trunk/gs base/gxp1fill.c]</p>
</blockquote>

<p><strong><a name="2009-07-21T134327.037336Z"></a>
2009-07-21T13:43:27.037336Z Ken Sharp</strong></p>
<blockquote>
<pre>
Enhancement (pdfwrite) : Add a new switch 'PDFACompatibilityPolicy to control PDF/A
creation when encountering invalid content.

Details
Bug #690500 &quot;gs 8.63. Option dPDFA generating no pdf/a compliant files because of F
key.&quot; 

In the reported issue the input PDF file contains a Link annotation with no /F (Flags)
key defined. PDF/A states that only annotations with the 'Print' bit of the Flags field
are permitted. pdfwrite was emitting the annotation, thus creating an invalid PDF/A
file.

The new switch PDFCompatibilityPolicy allows the user to select the behaviour for these
kinds of events. The value defaults to 0, where the behaviour matches Acrobat, the file
is created, but is not PDF/A compliant, a warning to this effect is given. When set to
1, the content will be omitted, resulting in a compliant PDF/A file, a warning is
given for each piece of omitted content. Values other than 0 or 1 are treated as 0 and
a warning is given that the value is not understood.

Currently only implemented for annotations, it is expected this will be extended over
time.

</pre>
<p>[base/gdevpdfm.c base/gdevpdfx.h base/gdevpdfp.c doc/Ps2pdf.htm base/gdevpdfb.h]</p>
</blockquote>

<p><strong><a name="2009-07-21T045001.508924Z"></a>
2009-07-21T04:50:01.508924Z Alex Cherepanov</strong></p>
<blockquote>
<pre>
Add output buffer alignment code to one of the image handling branches
where it was omitted. Fix a SEGV on Sparc platform that cannot access
misaligned data. Bug 690613.

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

<p><strong><a name="2009-07-20T051046.340795Z"></a>
2009-07-20T05:10:46.340795Z Alex Cherepanov</strong></p>
<blockquote>
<pre>
Unobfuscate image scaling code: remove dead code, expand macros and typedefs.
All changes are algorithmically equivalent.

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

<p><strong><a name="2009-07-19T035854.979499Z"></a>
2009-07-19T03:58:54.979499Z Alex Cherepanov</strong></p>
<blockquote>
<pre>
Fix a typo in compile time flag that prevented GNU libiconv to emulate
system libiconv and caused link errors on the systems that use GNU headers
but system libraries. Bug 690123.

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

<p><strong><a name="2009-07-17T151924.111289Z"></a>
2009-07-17T15:19:24.111289Z Alex Cherepanov</strong></p>
<blockquote>
<pre>
Initialize bit accumulator in LZW encoder to clear a Purify warning about
using an uninitialised value in an expression. The value itself is unimportant
because all bits that may affect the result are shifted out.

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

<p><strong><a name="2009-07-17T140035.203729Z"></a>
2009-07-17T14:00:35.203729Z Alex Cherepanov</strong></p>
<blockquote>
<pre>
Fix processiong of numeric entry in /W2 array. Bug 690635.

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

<p><strong><a name="2009-07-15T130748.754703Z"></a>
2009-07-15T13:07:48.754703Z Ken Sharp</strong></p>
<blockquote>
<pre>
Fix (pdfwrite): Crash with font errors.

Details:
bug #690505: &quot;Regression: More issues with pdfwrite and various nightly regression
files&quot;

The font 'encode_char' method can return a 0 error code, but set the returned glyph
name to 'gs_no_glyph' to indicate that a glyph could nto be found in a valid font.

pdfwrite was then trying to get the glyph information for the 'gs_no_glyph' glyph, which
caused a crash in dict_index. Fixed by detecting the gs_no_glyph and returning an error.

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

<p><strong><a name="2009-07-14T033522.419126Z"></a>
2009-07-14T03:35:22.419126Z Alex Cherepanov</strong></p>
<blockquote>
<pre>
Switch the order of an assignment and condition to fix (harmless) reading of
uninitialized memory. Clear a Purify warning.

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

<p><strong><a name="2009-07-13T015006.521945Z"></a>
2009-07-13T01:50:06.521945Z Ray Johnston</strong></p>
<blockquote>
<pre>
Add a couple of utilities for extracting Fonts and ICC Profiles from a
PDF. I had these laying around and the need for these comes up from 
time to time. See the top of each PostScript file for usage.

DETAILS:

It is the responsibility of creators of PDF's to not embed fonts that
are identified as not to be embedded. Ghostscript (as of rev 8603)
respects the TrueType FSType FontInfo.

The copyright and license of fonts and ICC profiles in a PDF will
still be in force. Any knowledgeable user can use Ghostscript
(or many other tools) to extract this information. We provide this
utility mostly to provide the 'source' for GPL'ed fonts as required
by fonts. Fonts are programs and distribution requires distribution
of 'source', so this lets users get the source and (using a font
editor) modify the font. See bug 690533 (if you must).

</pre>
<p>[toolbin/extractICCprofiles.ps toolbin/extractFonts.ps]</p>
</blockquote>

<p><strong><a name="2009-07-11T174945.436921Z"></a>
2009-07-11T17:49:45.436921Z Ralph Giles</strong></p>
<blockquote>
<pre>
Change the GPL Ghostscript license to GPLv2 or later, instead of GPLv2-only.
</pre>
<p>[LICENSE]</p>
</blockquote>

<p><strong><a name="2009-07-09T130911.914398Z"></a>
2009-07-09T13:09:11.914398Z Alex Cherepanov</strong></p>
<blockquote>
<pre>
Don't take empty string for an answer when searching 'name' table in TrueType
font because some MS fonts have empty strings for platform IDs MS doesn't
use. Bug 690611, customer 0.

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

<p><strong><a name="2009-07-09T055944.622957Z"></a>
2009-07-09T05:59:44.622957Z Henry Stiles</strong></p>
<blockquote>
<pre>
Remove ad hoc code to draw thin rectangles.  It appears this code is
obsolete with respect to the current fill code.  Many fills adjusted
with this code will actually render without enlargement.  Differences
noted in the following files were insignificant or improvements.

comparefiles/012-05.ps
comparefiles/013-05.ps
comparefiles/067a_unc-stroke.pdf
comparefiles/298-09.ps
comparefiles/321-09.ps
comparefiles/86554321.pdf
comparefiles/Bug687603.ps
comparefiles/Bug687724.pdf
comparefiles/Bug687840.pdf
comparefiles/Bug687901.ps
comparefiles/Bug688485.pdf
comparefiles/Bug688631.pdf
comparefiles/Bug688807.pdf
comparefiles/Bug689083.pdf
comparefiles/Bug689516.pdf
comparefiles/Bug689842.pdf
comparefiles/Bug689918.pdf
comparefiles/Bug689978.pdf
comparefiles/Bug690115.pdf
comparefiles/Bug690206.pdf
comparefiles/Bug690395.pdf
comparefiles/Clarke-Tate-Manns-Chinese.ai
comparefiles/H00216q.pdf
comparefiles/LMG-40-7161-RU-DUC-01.pdf
comparefiles/Testform.v1.0.2.pdf
comparefiles/WD0010L0.pdf
comparefiles/annots.pdf
comparefiles/bug_687457.pdf
comparefiles/bulletin.pdf
comparefiles/knight.pdf
comparefiles/messenger.pdf
comparefiles/messenger16.pdf
comparefiles/p2b-100.pdf
comparefiles/z400454b01d4-1.pdf
pdf/PDFIA1.7_SUBSET/CATX2140.pdf
pdf/PDFIA1.7_SUBSET/CATX5233.pdf
pdf/PDFIA1.7_SUBSET/CATX9004.pdf
pdf/PDFIA1.7_SUBSET/CATX9214.pdf
pdf/PDFIA1.7_SUBSET/CATX9558.pdf
pdf/PDFIA1.7_SUBSET/IA3Z0005.pdf
pdf/PDFIA1.7_SUBSET/IA3Z0302.pdf
pdf/PDFIA1.7_SUBSET/IA3Z1351.pdf
pdf/PDFIA1.7_SUBSET/IA3Z3225.pdf
pdf/PDFIA1.7_SUBSET/IA3Z3356.pdf
pdf/PDFIA1.7_SUBSET/IA3Z3359.pdf
pdf/PDFIA1.7_SUBSET/IA3Z3519.pdf
pdf/PDFIA1.7_SUBSET/IA3Z3778.pdf
pdf/PDFIA1.7_SUBSET/IA3Z4373.pdf
pdf/PDFIA1.7_SUBSET/IA3Z4663.pdf
ps/ps3cet/11-01.PS
ps/ps3cet/11-26C.PS
ps/ps3cet/12-05.PS
ps/ps3cet/13-01.PS
ps/ps3cet/13-02.PS
ps/ps3cet/13-03.PS
ps/ps3cet/13-10.PS
ps/ps3cet/13-12.PS
ps/ps3cet/13-13.PS
ps/ps3cet/13-15.PS
ps/ps3cet/13-16.PS
ps/ps3cet/13-17.PS
ps/ps3cet/13-18.PS
ps/ps3cet/13-19.PS
ps/ps3cet/13-20.PS
ps/ps3cet/13-22.PS
ps/ps3cet/13-26.PS
ps/ps3cet/13-27.PS
ps/ps3cet/13-28.PS
ps/ps3cet/13-29.PS
ps/ps3cet/14-08.PS
ps/ps3cet/23-25.PS
ps/ps3cet/29-03.PS


</pre>
<p>[base/gxpaint.c base/gxcpath.c base/gxttfb.c base/gdevtrac.c base/gxacpath.c base/gxpaint.h base/gdevbbox.c base/gdevpdfd.c base/gxshade.c base/gxfill.c base/gxstroke.c base/gxclrast.c]</p>
</blockquote>

<p><strong><a name="2009-07-09T002802.323867Z"></a>
2009-07-09T00:28:02.323867Z Alex Cherepanov</strong></p>
<blockquote>
<pre>
Set default color and colorspace for colored pattern stream that relies on
default values; keep the color unset as required for uncolored pattern.
Bug 690609, customer 531.

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

<p><strong><a name="2009-07-08T141843.038306Z"></a>
2009-07-08T14:18:43.038306Z Henry Stiles</strong></p>
<blockquote>
<pre>
This patch is a continuation of revision 9842, to derive the fill
adjustment parameter from the graphics state and not assume the value
is 1/2.  Interestingly, the patch seems to result in improvements for
postscript in several regression test files.  For example cet file
13-13.ps page 3 appears to improve the clipping of the large (W)
character.  Previously the (W) character obscured the line on the top
border of the page, now the line is visible.  Unfortunately the non
banded result is still wrong and with the fix does not match the
banded output.  Analysis of this issue is incomplete and ongoing.
</pre>
<p>[base/gxclrast.c]</p>
</blockquote>

<p><strong><a name="2009-07-08T135615.311074Z"></a>
2009-07-08T13:56:15.311074Z Ken Sharp</strong></p>
<blockquote>
<pre>
Fix (CID fonts): The fallback when totally failing to find a character code in a CMap
sets the CID to 0 (/.notdef) but failed to select a descendant font.

Details:
bug #690372 &quot;Error: /undefined in %Type0BuildGlyph&quot;

The PDF file is fundamentally flawed, the font uses the /Identity-H CMap for a font, but
the font uses single bytes for each character code, where the CMap expects 2 bytes for
every character code.

The font code falls back to using CID 0 (the /.notdef equivalent), but failed to select
a descendant font before returning. Because no descendant was selected GS was attempting
to extract the glyph from the type 0 font, which has no glyphs, and therefore failed 
with an undefined error.

The code has been modified to select a descendant font before continuing under these 
conditions.

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

<p><strong><a name="2009-07-08T060240.134274Z"></a>
2009-07-08T06:02:40.134274Z Ray Johnston</strong></p>
<blockquote>
<pre>
Fix for segfault caused by dereference of a stale pointer (pgs-&gt;dev_color).
Bug 690519 detected with pkmraw during regression testing.

DETAILS:

If a GC was run during a pattern accum in the PS interpreter, the pgs-&gt;dev_color
structure could be moved. This was not tracked, probably because the dev_color
was assumed to be &quot;dynamic&quot;. The fix performs gx_unset_dev_color during the
pattern_paint_cleanup (in zpcolor.c). This minimal change is all that is needed
since only the PS interpreter runs a &quot;real&quot; GC that moves structures.

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

<p><strong><a name="2009-07-06T172039.998539Z"></a>
2009-07-06T17:20:39.998539Z Henry Stiles</strong></p>
<blockquote>
<pre>
The fill adjustment associated with the clipping path should be
derived from the graphics state, not set to the constant 1/2.  This
change results in many improvement for pcl which uses center of pixel
(fill adjust == 0) rendering.  It should result in no change for
postscript or pdf at high resolution, but we do expect many difference
at lower resolutions, where fill adjust is set to 1/4.  In the latter
case postscript and pdf paint with fill adjust set to 1/4 while
clipping paths are created with a fill adjustment of 1/2 which is
incorrect.

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

<p><strong><a name="2009-07-06T085130.498667Z"></a>
2009-07-06T08:51:30.498667Z Ken Sharp</strong></p>
<blockquote>
<pre>
Fix (graphics library) : Conversion to base colour space of an /Indexed colour space was
not catering for spaces with a string lookup instead of a procedural lookup.

Details
Bug #690587 &quot;setcolorspace + currentgray crashes GS 8.64&quot;

The conversion from a colour in an indexed space to its alternate assumed a procedural
lookup and failed badly if the space had a string lookup.

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

<p><strong><a name="2009-07-04T224506.512463Z"></a>
2009-07-04T22:45:06.512463Z Alex Cherepanov</strong></p>
<blockquote>
<pre>
Add a check for a null value of SMask attribute in ExtGState. This also works
for invalid SMask reference, which is already converted to null.
Bug 690597, customer 870.

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

<p><strong><a name="2009-07-03T215949.616755Z"></a>
2009-07-03T21:59:49.616755Z Ray Johnston</strong></p>
<blockquote>
<pre>
Fix for crash when tiles are outside printable areas seen with bug 690558.

DETAILS:

The 'fit_copy' macro adjusts the x, y, w, and h values, but since this is
a procedural macro and the 'FOR_RUNS' macro (also procedural) declares
local variables, for 'C' the 'FOR_RUNS ... END_RUNS' needs to be in
a block. The only real changes are the additions of 'fit_copy()'.

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

<p><strong><a name="2009-07-03T092702.706358Z"></a>
2009-07-03T09:27:02.706358Z Ken Sharp</strong></p>
<blockquote>
<pre>
Enhancement (TrueType fonts): Add support for Adobe's use of Identity CMap in PDF files,
when substituting a TrueType font, mapped as a CIDFont from disk, for a missing CIDFont.

Details:
bug #688515 &quot;Need method to map CIDFonts to TrueType fonts when Ordering is Identity&quot;
This issue also covers issues #689499, #688813, #689623 and #690483. 

When using a native TrueType font from disk as a replacement for a CIDFont, GS needs a
way to convert the character code used in the input file (either PostScript or PDF) into
a TrueType glyph ID (GID). 

When the TrueType font is declared (in cidfmap), the CSI entry contains an Ordering, this is concatenated with the CMAP declared in the actual TrueType font. This
information is used to create a CIDDecoding resource, certain  combinations (defined in
.CMapChooser) create CIDDecoding resources 'on the fly'.

A CIDDecoding resource simply maps a character code directly to a GID. Normally this
resource, when automatically created, is manufactured by converting the character code
to an internal code (using the declared CMap from cidfmap) and then converting the 
internal code to a GID using the TrueType CMAP table. Most often the internal code
is a Unicode code point.

The investigation in 688515 makes it clear that when we have an Identity CMap in a
PDF file the character code should be treated as the GID. This makes it very easy for 
us to construct a CIDDecoding resource, its a simple one-to-one. Unfortunately the 
existing machinery relies upon a CMap, and there is already a mapping for 
Identity.Symbol (An Identity CMap with a font whose CMAP table is a Symbol table).
We don't want to break this existing functionality, so the new code adds an entry
in .CMapChooser for Identity.Unicode (only to avoid errors) and then in the 
function which actually loads the TT font (load_sfnts in gs_cidtt.ps) we check
specifically for an Identity.Unicode Decoding. If we find one then we call a new
routine to create an Identity mapping (CIDMap) from character code to GID.

</pre>
<p>[psi/zcid.c psi/icid.h Resource/Init/gs_ciddc.ps Resource/Init/gs_cidtt.ps psi/zfcid1.c]</p>
</blockquote>

<p><strong><a name="2009-07-02T003801.021625Z"></a>
2009-07-02T00:38:01.021625Z Till Kamppeter</strong></p>
<blockquote>
<pre>
Use &quot;Perceptual&quot; as render intent for the presentation quality setting in the &quot;cdnj500&quot; (HP DesignJet) driver.
</pre>
<p>[contrib/gdevcd8.c]</p>
</blockquote>

<p><strong><a name="2009-06-30T000633.029648Z"></a>
2009-06-30T00:06:33.029648Z Alex Cherepanov</strong></p>
<blockquote>
<pre>
Extract all documents from PDF collection to temporary files and process them
in the order they are listed in the /Names array. Bug 690422, customer 531.

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

<p><strong><a name="2009-06-29T123328.939766Z"></a>
2009-06-29T12:33:28.939766Z Ken Sharp</strong></p>
<blockquote>
<pre>
gs_ciddc.ps is now in Resource/Init, not in lib as was stated in the documentation.
</pre>
<p>[doc/Language.htm]</p>
</blockquote>

<p><strong><a name="2009-06-29T093350.558685Z"></a>
2009-06-29T09:33:50.558685Z Ken Sharp</strong></p>
<blockquote>
<pre>
Enhancement (pdfwrite &amp; ps2write) : Optionally convert Separation and DeviceN spaces to their alternate space.

Detalis:
bug #690582 &quot;Disabel /Separation and /DeviceN colour space preservation&quot;

When creating a colour space for output, allow the user to insist that Separation and
DeviceN spaces be converted to their alternate space.
</pre>
<p>[base/gdevpdfx.h base/gdevpdfp.c doc/Ps2pdf.htm base/gdevpdfc.c base/gdevpdfb.h]</p>
</blockquote>

<p><strong><a name="2009-06-26T124229.607606Z"></a>
2009-06-26T12:42:29.607606Z Alex Cherepanov</strong></p>
<blockquote>
<pre>
Look into JPX stream to get color space and color depth when it is omitted
from the image dictionary. Bug 690518, customer 850.

DETAILS:
This is a minimal implementation that intentionally uses device dependent
color spaces instead of device-independent ones for full backward
compatibility. 

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

<p><strong><a name="2009-06-23T222457.094170Z"></a>
2009-06-23T22:24:57.094170Z Michael Vrhel</strong></p>
<blockquote>
<pre>
Fix for bug690546.  Problem was caused by double application of opacity for knockout fills.  The opacity was being applied in the alpha value and in the opacity value.  The alpha value is the product of the shape and opacity and can be used directly.

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

<p><strong><a name="2009-06-23T072450.757746Z"></a>
2009-06-23T07:24:50.757746Z Ken Sharp</strong></p>
<blockquote>
<pre>
Fix (pdfwrite) : Update 'where_used' in case object is used across pages

Details
Bug #690056 &quot;Error with embedded image in generated PDF: XObject not found&quot;

Pdfwrite tries to detect reuse of objects, and only emit a single copy when this occurs.
However on return from pdf_substitute_resource several places do not set the
'where_used' field. If the object is used on a different page to the one where it is 
defined, this causes it not to be listed in the page Resources.

Update two of the places where this occurs to resolve the problem.

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

<p><strong><a name="2009-06-22T112248.383638Z"></a>
2009-06-22T11:22:48.383638Z Russell Lang</strong></p>
<blockquote>
<pre>
Add the Windows installer manifest when building with Visual Studio 2008.
</pre>
<p>[psi/msvc32.mak]</p>
</blockquote>

<p><strong><a name="2009-06-22T074134.716284Z"></a>
2009-06-22T07:41:34.716284Z Ken Sharp</strong></p>
<blockquote>
<pre>
Fix a technically uninitialised variable (Coverity warning).
</pre>
<p>[base/gdevpdti.c]</p>
</blockquote>

<p><strong><a name="2009-06-22T074101.524464Z"></a>
2009-06-22T07:41:01.524464Z Ken Sharp</strong></p>
<blockquote>
<pre>
Fix a minor Coverity warning about implicit function declarations.
</pre>
<p>[base/gdevpdfb.c]</p>
</blockquote>

<p><strong><a name="2009-06-21T212233.385661Z"></a>
2009-06-21T21:22:33.385661Z Russell Lang</strong></p>
<blockquote>
<pre>
Add manifest files to the Windows setup and uninstall programs,
to force Windows Vista to run them as Administrator.
Bug 690510.
</pre>
<p>[psi/dwsetup_x64.manifest psi/dwuninst_x64.manifest psi/dwsetup_x86.manifest psi/dwuninst_x86.manifest]</p>
</blockquote>

<p><strong><a name="2009-06-21T043847.415879Z"></a>
2009-06-21T04:38:47.415879Z Russell Lang</strong></p>
<blockquote>
<pre>
Remove support for cross compiling of Win64 ghostscript on
Windows 32-bit using Visual Studio .NET 2003 with a 
Win64 compatible DDK.
Ghostscript for Win64 must now be built on 64-bit Windows,
to assist with compiled resources. 
Visual Studio 2005 and 2008 are currently supported for 64-bit.
</pre>
<p>[doc/Make.htm base/msvccmd.mak psi/msvc32.mak]</p>
</blockquote>

<p><strong><a name="2009-06-21T042305.005351Z"></a>
2009-06-21T04:23:05.005351Z Russell Lang</strong></p>
<blockquote>
<pre>
Add manifest files to the Windows setup and uninstall programs,
to force Windows Vista to run them as Administrator.
</pre>
<p>[doc/Develop.htm psi/msvc32.mak]</p>
</blockquote>

<p><strong><a name="2009-06-20T172939.375319Z"></a>
2009-06-20T17:29:39.375319Z Alex Cherepanov</strong></p>
<blockquote>
<pre>
Add TrimBox support and a corresponding -dUseTrimBox option. Bug 690547.

</pre>
<p>[Resource/Init/pdf_main.ps doc/Use.htm]</p>
</blockquote>

<p><strong><a name="2009-06-19T121420.778442Z"></a>
2009-06-19T12:14:20.778442Z Ken Sharp</strong></p>
<blockquote>
<pre>
Fix (pdfwrite) : Make type 3 bitmap font text-searchable if possible

Details
Bug #690430 &quot;PCL to PDF creates non-searchable text with incorrect font bbox&quot;

There were several changes which needed to be made here, in particular

1) Prevent the PDF text routines updating the text state when using type 3 bitmap
   fonts, as this caused each glyph to be emitted individually.

2) Change the way bitmap glyphs are recorded and drawn, previously each glyph origin
   was the top of the glyph, which meant that different height glyphs had effectively
   differing baselines. The need to shift y position caused glyphs to appear on 
   different PDF 'lines', which prevented searching

3) Hone some internal heuristics which prevented large kerning values and caused glyphs 
   to be placed individually.

</pre>
<p>[base/gdevpdti.h base/gdevpdfx.h base/gdevpdts.c base/gdevpdfb.c base/gdevpdt.h base/gdevpdti.c]</p>
</blockquote>

<p><strong><a name="2009-06-19T105311.324517Z"></a>
2009-06-19T10:53:11.324517Z Ken Sharp</strong></p>
<blockquote>
<pre>
Add a couple of missing initialisers to the PDF device structure. Spotted this problem while working on another issue.
</pre>
<p>[base/gdevpdfb.h]</p>
</blockquote>

<p><strong><a name="2009-06-18T220641.250732Z"></a>
2009-06-18T22:06:41.250732Z Marcos H. Woehrmann</strong></p>
<blockquote>
<pre>

Add A5 to the list of PCL output paper sizes.  Thanks to peter.berndts@oce.com for the patch.

Fixes bug 690532.

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

<p><strong><a name="2009-06-18T051648.708579Z"></a>
2009-06-18T05:16:48.708579Z Ralph Giles</strong></p>
<blockquote>
<pre>
Handle 4-bit grayscale JPXDecode images.

This is a minimal patch to fix bug 690174.

The file has a JPXDecode stream with 4 bits per component. The image
dictionary has the correct matching /BitsPerComponent and /ColorSpace
keys, but the stream filter was returning the pixel data as the low
nibble in 8 bit pixels.

This is a minimal fix: if the first component of the data is 4 bpc,
divide the stride in half, then in copy_row_gray, pack two pixels
per byte when returning the data.

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

<p><strong><a name="2009-06-17T032525.702690Z"></a>
2009-06-17T03:25:25.702690Z Alex Cherepanov</strong></p>
<blockquote>
<pre>
Fix memory corruption caused by long names. The length of name in the scanner
buffer may exceed the maximum name size and should be checked. Bug 690523.

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

<p><strong><a name="2009-06-17T021749.344749Z"></a>
2009-06-17T02:17:49.344749Z Alex Cherepanov</strong></p>
<blockquote>
<pre>
Fix detection of extra Q operators in the page contents stream, which never
worked before. Remove some level 1 rudiments and comment the code.
Bug 690540, customer 750.

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

<p><strong><a name="2009-06-16T220541.362092Z"></a>
2009-06-16T22:05:41.362092Z Henry Stiles</strong></p>
<blockquote>
<pre>
Add a graphics library rom file system variable.  For now this will be
used to hold the icc and wts files associated with the wtsimdi device.
No expected differences.
</pre>
<p>[base/lib.mak]</p>
</blockquote>

<p><strong><a name="2009-06-14T225722.467309Z"></a>
2009-06-14T22:57:22.467309Z Michael Vrhel</strong></p>
<blockquote>
<pre>
Fix for access violation that can occur when processing PS files with spot colors into a sep device.

DIFFERENCES EXPECTED:
None

DETAILS:
Number of separations was being obtained from page_spot_colors but should be obtained from separations.num_separations.  This was causing the elements of map_comp_to_sep[comp_num] to not be properly initialized for later use in tiffsep_print_page.</pre>
<p>[base/gdevtsep.c]</p>
</blockquote>

<p><strong><a name="2009-06-13T143318.520606Z"></a>
2009-06-13T14:33:18.520606Z Alex Cherepanov</strong></p>
<blockquote>
<pre>
Export t1_glyph_equivalence table, which provides alternative glyph names.
Modify pf2afm.ps to disable glyph aliasing and generate AFM files that
match the font. Bug 689014.

</pre>
<p>[Resource/Init/gs_type1.ps lib/pf2afm.ps]</p>
</blockquote>

<p><strong><a name="2009-06-13T012000.314754Z"></a>
2009-06-13T01:20:00.314754Z Marcos H. Woehrmann</strong></p>
<blockquote>
<pre>
Add yet another _NMAKE_VER check (9.00.30729.01) to msvc32.mak to
detect MSVC_VERSION 9 (there has be a better way of doing this).
This surpresses a couple of warnings for each cl invocation but
shouldn't effect the build.

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

<p><strong><a name="2009-06-10T131031.212563Z"></a>
2009-06-10T13:10:31.212563Z Ken Sharp</strong></p>
<blockquote>
<pre>
Fix (pdfwrite): Bug in pdfmark processing

Details
Bug #690525 &quot;hyperlinks in pdf off by one page since revision 9779&quot;

Revision 9779 fixed a problem when a DOCVIEW pdfmark did not specify a /Page or View to
open the file on. This caused an extra page reference to be created, which caused an
invalid xref to be created.

This was fixed by altering the page count, but this caused real DEST pdfmarks not to
work properly under some conditions.

Restored the page count, and used the presence of either a /Page or /View pdfmark to
generate a page number, if neither is present no page number is created. This fixes
both issues.

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

<p><strong><a name="2009-06-09T033201.703357Z"></a>
2009-06-09T03:32:01.703357Z Henry Stiles</strong></p>
<blockquote>
<pre>
Changed to use memset when filling white and black lines of a
rectangle.  This provides about a 10% speedup over copying a byte at a
time when printing long jobs where a significant amount of time is
spent whitening the page, this improvement was observed on a 2.53 GHz
Intel Core 2 Duo (Mac OS X) and we expect similar results on other
platforms.  No expected changes, the code is functionally equivalent.
</pre>
<p>[base/gdevwts.c]</p>
</blockquote>

<p><strong><a name="2009-06-08T181629.884697Z"></a>
2009-06-08T18:16:29.884697Z Ray Johnston</strong></p>
<blockquote>
<pre>
Provide for filling zero width areas to prevent dropout in some strange stroked
characters. This seems to be the intent of the code, and definitely conforms to
the PS PLRM, but the PDF Reference Manual says zero width fills may or may not
be filled (although Adobe Acrobat does). This is not (yet) enabled by default,
but is provided to simplify regression analysis and for customer 531, bug 690466.

DETAILS:

The original code in gxfill.c seems quite strange in that usually it will fill
horizontal areas sue to the 'adjust_above' and 'adjust_below', but depending
on the coordinate, this would sometimes NOT include the horizontal segment.

The change to gxfilltr.h adds vertical segments when PSEUDO_RASTERIZATION
is in the 'template' (as before) as well as when FILL_ADJUST is in the
'template' and the 'adjust' left and right values are &gt; 0.

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

<p><strong><a name="2009-06-08T031040.894198Z"></a>
2009-06-08T03:10:40.894198Z Henry Stiles</strong></p>
<blockquote>
<pre>
Previously we identified a banding device by checking if its
get_bits_rectangle procedure was the same as the procedure used in the
constant procedure declarations gs_clist_device_procs.  This
conditional has not been correct since the multi-threaded code, the
get_bits_rectangle() procedure is overridden with a new procedure
get_bits_rectangle_mt() and all devices were detected as non-banding.
We change the procedure checked to be open_device and don't expect
this to be overridden, but the code is still somewhat awkward.

The broken conditional resulted in non deterministic behavior in the
wtsimdi device, indirectly causing the complexity array to be
uninitialized.
</pre>
<p>[base/gdevprn.c]</p>
</blockquote>

<p><strong><a name="2009-06-05T125253.651342Z"></a>
2009-06-05T12:52:53.651342Z Ken Sharp</strong></p>
<blockquote>
<pre>
Fix (pdfwrite) : Bug with DOCVIEW pdfmark handling

Details
bug #690514 &quot;PageMode DOCVIEW pdfmarks result in broken PDF file&quot;

Using the the /PageMode DOCVIEW pdfmark without using another DOCVIEW pdfmark
which directly references a page (eg specifying the page to open on via /Page)
results in a spurious extra entry in the xref table, referencing the first page
object.

This is caused by the pdfwrite routine 'pdfmark_make_dest' which calls
'pdfmark_page_number'. If there is no specified /Page in the pdfmark, then a new
page reference for the 'next' page is allocated in the xref table, using the
location of the current page. This is the source of the spurious entry.

Note that the DOCVIEW code seems to assume that there be at most one /Page or /View
pdfmark in the array.

Fixed by decrementing the page count in pdfmark_page_number if the string being
parsed for a page number is empty.

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

<p><strong><a name="2009-06-05T055554.211001Z"></a>
2009-06-05T05:55:54.211001Z Alex Cherepanov</strong></p>
<blockquote>
<pre>
Switch to 32-bit PostScript integers on 64 bit platform. Bug 690474.

</pre>
<p>[psi/iparam.c psi/zfile.c psi/zfunc4.c psi/zcontrol.c psi/ibnum.c psi/ztype.c psi/zdict.c psi/iscannum.c psi/idparam.c psi/zfcid0.c psi/ibnum.h psi/zdps.c psi/zmath.c psi/iscanbin.c psi/iutil.c psi/iref.h psi/iscan.c psi/idebug.c psi/zstack.c psi/ziodev.c psi/zarith.c base/gsalloc.c psi/zgeneric.c]</p>
</blockquote>

<p><strong><a name="2009-06-05T042551.460104Z"></a>
2009-06-05T04:25:51.460104Z Alex Cherepanov</strong></p>
<blockquote>
<pre>
Validate /Border attribute of annotations. Following AR, use invisible border
when /Border value is incorrect. Bug 690509.

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

<p><strong><a name="2009-05-31T025009.248528Z"></a>
2009-05-31T02:50:09.248528Z Alex Cherepanov</strong></p>
<blockquote>
<pre>
Current PDF font loader fails when Type 1 font executes 'restore' at the end
of the file and discards all the collected data. The patch breaks the check
for /UniqueID in the font to force a branch without 'restore'. Bug 690502.

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

<p><strong><a name="2009-05-30T002220.429756Z"></a>
2009-05-30T00:22:20.429756Z Ray Johnston</strong></p>
<blockquote>
<pre>
Fix the file stream opening logic so that when the open failed, it did not leave
buffers and other structures up to the GC for collection. This only affected PS
and PDF, but happened on files that needed fonts that were not immediately in the
Fontmap. This resulted in up to on the files from bug 690422.

DETAILS:

Since the file streams were allocated in 'system' VM, and the 'limit' was not
set when the vmthreshold was set, this &quot;leak&quot; could result in excessive GC
colletion operations.

</pre>
<p>[base/sfxcommon.c base/stream.c]</p>
</blockquote>

<p><strong><a name="2009-05-29T140204.750188Z"></a>
2009-05-29T14:02:04.750188Z Ken Sharp</strong></p>
<blockquote>
<pre>
Fix (Graphics library) : Inappropriate testing of shading co-ordinates

Details
The Gouraud free-form mesh shading code was testing to see if the Xmin and Xmax
co-ordinates of the Decode array were the same, and flagging an error if so. The spec
does not say this is an error and Acrobat happily displays the PDF. In addition there
was no test against Ymin and Ymax, so the test has been removed

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

<p><strong><a name="2009-05-29T064844.622628Z"></a>
2009-05-29T06:48:44.622628Z Ralph Giles</strong></p>
<blockquote>
<pre>
Update the included copy of jbig2dec with the 0.10 release.

This merges changed made to the version of the gs tree with upstream
fixes, including the buffer overrun fix for CVE-2009-0196. See
CHANGES for a more complete summary.

</pre>
<p>[jbig2dec/aclocal.m4 jbig2dec/config_win32.h jbig2dec/sha1.c jbig2dec/jbig2_metadata.c jbig2dec/jbig2_image_pbm.c jbig2dec/install-sh jbig2dec/jbig2.c jbig2dec/jbig2_generic.h jbig2dec/jbig2_image.c jbig2dec/configure jbig2dec/Makefile.in jbig2dec/jbig2_metadata.h jbig2dec/jbig2.h jbig2dec/jbig2_priv.h jbig2dec/jbig2_image_png.c jbig2dec/jbig2_image.h jbig2dec/depcomp jbig2dec/compile jbig2dec/jbig2dec.c jbig2dec/os_types.h jbig2dec/config.h jbig2dec/configure.ac jbig2dec/jbig2_arith.c jbig2dec/jbig2_symbol_dict.c jbig2dec/jbig2_arith.h jbig2dec/jbig2_page.c jbig2dec/jbig2_symbol_dict.h jbig2dec/jbig2_arith_int.c jbig2dec/jbig2_hufftab.h jbig2dec/jbig2_huffman.c jbig2dec/jbig2_text.c jbig2dec/jbig2_arith_int.h jbig2dec/jbig2_text.h jbig2dec/jbig2_huffman.h jbig2dec/jbig2_mmr.c jbig2dec/jbig2_refinement.c jbig2dec/jbig2_arith_iaid.c jbig2dec/jbig2_mmr.h jbig2dec/memcmp.c jbig2dec/test_jbig2dec.py jbig2dec/jbig2_arith_iaid.h jbig2dec/config.h.in jbig2dec/jbig2_segment.c jbig2dec/Makefile.am jbig2dec/missing jbig2dec/jbig2_generic.c]</p>
</blockquote>

<p><strong><a name="2009-05-25T133800.787533Z"></a>
2009-05-25T13:38:00.787533Z Ken Sharp</strong></p>
<blockquote>
<pre>
Fix (colour handling): improper handling of ICCBased space with a /Alternate ICCBased
    space

Details:
bug #690495 &quot;Error: /typecheck in --@0x1007f6f0--&quot;

It is technically possible (apparently) for a PDF file to contain an ICCBased space
which has an /Alternate space which is also an ICCBased space. The existing
validation code assumed this would not be the case and reused a reference if the
latter space had no /Alternate in order to select an appropriate final Alternate.

This led to the latter ICCBased space being replaced by the selected default space,
which meant we had fewer spaces than expected when actually setting the space.

Fixed by inserting the selected appropriate default space into the ICC dictionary as
an /Alternate and revalidating the modified space.

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

<p><strong><a name="2009-05-24T101657.483100Z"></a>
2009-05-24T10:16:57.483100Z Ralph Giles</strong></p>
<blockquote>
<pre>
Fix an uninitialized variable warning in FAPI_do_char.

Details:

Previously the local variable 'code' was used for incidental return 
value checks, but *also* to set cr.is_glyph_index in in the CID font 
case. This is because cid_to_TT_charcode() returns 1 on success, but
if it can't find a character code for the given cid, it sets the
character code to zero and returns zero itself to indicate failure.

Zero makes more sense as a glyph id (.notdef) than as a character
code, so in this case it's appropriate to set is_glyph_index based
on this. The other paths which set 'code' all deal with truetype
fonts, so the default success value of zero is also correct.

However, there were in theory code paths where code was never set,
and so is_glyph_index was being set from an unitialized value; thus
the gcc warning. And the double-use of the variable 'code' was hard
to read. This commit adds a separate boolean to track whether we've
found a character code or not and sets cr.is_glyph_index based on
that.

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

<p><strong><a name="2009-05-23T191137.254849Z"></a>
2009-05-23T19:11:37.254849Z Ralph Giles</strong></p>
<blockquote>
<pre>
Remove an unnecessary duplicate typedef. Coverity issue 4183.
</pre>
<p>[base/gdevp14.h]</p>
</blockquote>

<p><strong><a name="2009-05-23T190208.125913Z"></a>
2009-05-23T19:02:08.125913Z Ralph Giles</strong></p>
<blockquote>
<pre>
Remove an unnecessary header include.

Coverity issue 2497.
</pre>
<p>[base/lib.mak base/sjpx.c]</p>
</blockquote>

<p><strong><a name="2009-05-23T183721.743759Z"></a>
2009-05-23T18:37:21.743759Z Ralph Giles</strong></p>
<blockquote>
<pre>
Remove some unused variables.

I've left one, the subarray_index, since it may be intended for future 
development. The others were all trivial.
</pre>
<p>[psi/zfapi.c]</p>
</blockquote>

<p><strong><a name="2009-05-23T165958.327296Z"></a>
2009-05-23T16:59:58.327296Z Ralph Giles</strong></p>
<blockquote>
<pre>
Correct a cut-and-paste error in r9742.

The blend values array logic for multiple master fonts was writing
integer element values with a floating point specifier. These are
normally floats, which is probably why the error wasn't noticed in
testing. Flagged by Coverity as issue 4326.
</pre>
<p>[psi/zfapi.c]</p>
</blockquote>

<p><strong><a name="2009-05-23T153633.756259Z"></a>
2009-05-23T15:36:33.756259Z Alex Cherepanov</strong></p>
<blockquote>
<pre>
Trap /ioerror and load the font by name when embedded font stream is
unreadable. Bug 690492.

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

<p><strong><a name="2009-05-22T091126.614602Z"></a>
2009-05-22T09:11:26.614602Z Ralph Giles</strong></p>
<blockquote>
<pre>
Remove a duplicate gs_memory_t structure member from the trace device.

In r8803 the image_enum memory pointer was moved from the various
subclasses into the common portion of the structure (the superclass).
In oversight, that change was not make to gdevtrac.c, breaking
compilation because of the now-duplicate member name. This went
unnoticed until now because the trace device isn't part of any
standard build.

Note that I've only fixed the compile error. I have not verified
that the trace device still functions properly.
</pre>
<p>[base/gdevtrac.c]</p>
</blockquote>

<p><strong><a name="2009-05-22T090335.793845Z"></a>
2009-05-22T09:03:35.793845Z Ralph Giles</strong></p>
<blockquote>
<pre>
Correct a typo in the unused gsparam2.c.

This was broken in r2849, but went unnoticed because the parameter
api rewrite was never developed further. This file isn't part of
any standard build.
</pre>
<p>[base/gsparam2.c]</p>
</blockquote>

<p><strong><a name="2009-05-21T234645.296083Z"></a>
2009-05-21T23:46:45.296083Z Marcos H. Woehrmann</strong></p>
<blockquote>
<pre>

Minor changes for Luratech decoders command line options.

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

<p><strong><a name="2009-05-21T191625.645959Z"></a>
2009-05-21T19:16:25.645959Z Ralph Giles</strong></p>
<blockquote>
<pre>
Update documentation with the new location for dmmain.
</pre>
<p>[doc/Develop.htm]</p>
</blockquote>

<p><strong><a name="2009-05-21T191336.537944Z"></a>
2009-05-21T19:13:36.537944Z Ralph Giles</strong></p>
<blockquote>
<pre>
Move the Classic MacOS gsapi client example code to psi, where it more 
properly belongs.
</pre>
<p>[base/dmmain.r base/dmmain.c psi/dmmain.r psi/dmmain.c]</p>
</blockquote>

<p><strong><a name="2009-05-21T191113.444391Z"></a>
2009-05-21T19:11:13.444391Z Ralph Giles</strong></p>
<blockquote>
<pre>
Comment improvement in the font api implementation.
</pre>
<p>[psi/zfapi.c base/gxfapiu.c base/gxfapiu.h]</p>
</blockquote>

<p><strong><a name="2009-05-21T124007.902153Z"></a>
2009-05-21T12:40:07.902153Z Till Kamppeter</strong></p>
<blockquote>
<pre>
The &quot;ps2write&quot; output device produces PostScript which is not DSC-conforming, so do not advertize it as DSC-conforming with a &quot;%!PS-Adobe-...&quot; magic string. Use &quot;%!&quot; instead. Otherwise the &quot;pstops&quot; CUPS filter cannot handle this output (Ubuntu bug #377011).
</pre>
<p>[base/gdevpdfu.c]</p>
</blockquote>

<p><strong><a name="2009-05-20T223312.105223Z"></a>
2009-05-20T22:33:12.105223Z Till Kamppeter</strong></p>
<blockquote>
<pre>
pstoraster did not work when called with an input file name as the 6th command line argument.
</pre>
<p>[cups/pstoraster.in]</p>
</blockquote>

<p><strong><a name="2009-05-20T223048.432212Z"></a>
2009-05-20T22:30:48.432212Z Till Kamppeter</strong></p>
<blockquote>
<pre>
Fixed recognition of page size via /cupsPageSizeName. All page sizes were considered custom sizes if /cupsPageSizeName was not set.
</pre>
<p>[cups/gdevcups.c]</p>
</blockquote>

<p><strong><a name="2009-05-20T121722.906937Z"></a>
2009-05-20T12:17:22.906937Z Tor Andersson</strong></p>
<blockquote>
<pre>
Reformat code to improve readability and fix messed up tab/space indentation. Also removed the m_ prefix on struct fields.</pre>
<p>[psi/fapi_ft.c]</p>
</blockquote>

<p><strong><a name="2009-05-19T225704.259848Z"></a>
2009-05-19T22:57:04.259848Z Alex Cherepanov</strong></p>
<blockquote>
<pre>
When /Length attribute is incorrect, PDF interpreter removes it from the
stream dictionary. Add support of missing /Length attribute to the pattern
handling code. Bug 690488.

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

<p><strong><a name="2009-05-16T152935.814286Z"></a>
2009-05-16T15:29:35.814286Z Alex Cherepanov</strong></p>
<blockquote>
<pre>
Bind all procedures in ps2ai.ps to prevent errors caused by redefined
operators, such as redefinition of 'length' as a number in
examples/colorcir.ps. Bug 690484.
</pre>
<p>[lib/ps2ai.ps]</p>
</blockquote>

<p><strong><a name="2009-05-15T121325.677962Z"></a>
2009-05-15T12:13:25.677962Z Ken Sharp</strong></p>
<blockquote>
<pre>
Fix (FAPI) : FAPI doesn't support Multiple Master fonts

Details
The FAPI code manufactures a stream containing font data for the benefit of FreeType.
However, when manufacturing a type 1 font stream it did not account for the possibility
of a Multiple Master font (or instance of a MM font). This caused FreeType to generate
an error when trying to process glyphs using MM operations.

Extended the existing code to manufacture the WeightVector array, $Blend procedure,
BlendDesignMap array, BlendDesignPositions array and BlendAxisTypes array if present
in the original font.

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

<p><strong><a name="2009-05-13T233728.142726Z"></a>
2009-05-13T23:37:28.142726Z Alex Cherepanov</strong></p>
<blockquote>
<pre>
Consider PDF files that has /StmF attribute but no /CF attribute as having
ARC4 encryption. Bug 690478.
</pre>
<p>[Resource/Init/pdf_sec.ps]</p>
</blockquote>

<p><strong><a name="2009-05-12T202211.794604Z"></a>
2009-05-12T20:22:11.794604Z Marcos H. Woehrmann</strong></p>
<blockquote>
<pre>
Removed reference to obsolete file (lwf_jp2_geo.h) that has been merged into lwf_jp2.h.
</pre>
<p>[base/lwf_jp2.mak]</p>
</blockquote>

<p><strong><a name="2009-05-12T101053.385307Z"></a>
2009-05-12T10:10:53.385307Z Ken Sharp</strong></p>
<blockquote>
<pre>
Fix (ps2write) : Crash caused when converting large shading to image.

DETAILS :

Bug 690475 &quot;ps2write&quot; segfaults on PDF file of CUPS test suite&quot;.

When converting a shading to an image for PostScript output, and the resulting image is
large (&gt; 512Kb), the code attempts to select an appropriate compression filter. As part
of doign this it probes the colour space in an attempt to determine what kind of space
it is. However this doesn't work when we have created the image ourselves, as tehre is
no associated imager state to probe the colour space resulting in a crash.

Modified the compression selection code to not probe the space if there is no imager
state.

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

<p><strong><a name="2009-05-11T151946.521973Z"></a>
2009-05-11T15:19:46.521973Z Ken Sharp</strong></p>
<blockquote>
<pre>
Fix (FAPI) : Type 2 fonts with local Subrs fail

Details
Type 2 (CFF) fonts may have both local and global subroutines. Normally fonts will only
contain a global set, while FontSet fonts may contain both a global set, and a local set
per font.

The FAPI code, when converting an internal GS representation back into a CFF stream,
incorrectly conflated the local and global Subrs into a single GSubrs (global subrs)
dict. Additionally it pushed the local subrs first. The result of this is that glyphs
using a callgsubr operator retrieved the subroutine, and glyphs using a callsubr would
fail because no local Subrs were defined.

Extended the FAPI code to retrieve the local and global subrs separately, to write a
local /Subrs dict if required, and to correctly calculate the /Subrs offset and store
it in the font Private dict when a /Subrs dict is present.

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

<p><strong><a name="2009-05-10T205612.436440Z"></a>
2009-05-10T20:56:12.436440Z Henry Stiles</strong></p>
<blockquote>
<pre>
Fill in omitted paper sizes as part of fixing bug #689677.  Thanks to
Jeffrey Vance for providing several of these paper dimensions.  No
regression differences are expected.
</pre>
<p>[base/gdevpxen.h]</p>
</blockquote>

<p><strong><a name="2009-05-10T164400.640518Z"></a>
2009-05-10T16:44:00.640518Z Marcos H. Woehrmann</strong></p>
<blockquote>
<pre>
Use 32 bits for fixed coordinates even on 64 bit cpus.

Details:

The fixed coordinate system used to be dependent on the size of a long.
On x86_64 and other 64 bit systems this was 8 bytes but 4 bytes on other
systems. 

Fixes Bug 690434.


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

<p><strong><a name="2009-05-10T025901.912309Z"></a>
2009-05-10T02:59:01.912309Z Ray Johnston</strong></p>
<blockquote>
<pre>
Fix regression caused by the changes to make PCL work. Bug 690463.

DETAILS:

The primary culprit was that the 'iblock' calculation didn't work if the
entire 'cbuf' wasn't empty. The token scanner sometimes refilled when there
was still data in the buffer. The 's_block_read_seek' also needed to make
sure that the cursor.r ptr and limit (srptr and srlimit) is set correctly
before loading the block at the new position. Tested with PCL and PS on
the cluster (and of coures on my Windows machine).
</pre>
<p>[base/gsiorom.c]</p>
</blockquote>

<p><strong><a name="2009-05-08T131326.891026Z"></a>
2009-05-08T13:13:26.891026Z Ken Sharp</strong></p>
<blockquote>
<pre>
Fix : Windows drag&amp;drop has a fixed path limit of 80 characters.

Details
Bug #690461 &quot;ghostscript can't handle files with long name-paths&quot;

The real issue is that the drag-and-drop interface had a fixed buffer of 80
characters, and was unable to process files beyond that limit.

It looks like the original code was from some boiler plate sample. Updated the code
to use the DragQeryFiles API call to find the length of the full path specification
and then malloc a buffer to hold it. Although we would never normally use the system
malloc call, this should not be a problem in the Windows-specific code.

</pre>
<p>[psi/dwtext.c psi/dwimg.c]</p>
</blockquote>

<p><strong><a name="2009-05-07T154558.755801Z"></a>
2009-05-07T15:45:58.755801Z Ken Sharp</strong></p>
<blockquote>
<pre>
Fix PostScript interpreter : ICC colour space could cause crash

Details
Bug 690472 &quot;ghostscript crashes on pdf file&quot;

The code to parse the /Range from an ICC profile stores the data in an array of floats.
However, when the Range data was present, the values were incorrectly stored at array
locations twice the proper index.

This could lead to buffer overflow which in this case corrupted the ICC dictionary being
used, causing a crash.

Surprisingly this did not come up in testing.

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

<p><strong><a name="2009-05-07T130610.554451Z"></a>
2009-05-07T13:06:10.554451Z Ken Sharp</strong></p>
<blockquote>
<pre>
Fix (FAPI) : FAPI doesn't handle Encoding arrays of type mixed_array

Details
It seems that fonts can sometimes have a 't_mixedarray' Encoding array, odd but true.
The FAPI code assumed that Encodings would either be t_array or t_shortarray. Altered
the code to allow for t_mixedarray as well.

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

<p><strong><a name="2009-05-07T124625.039496Z"></a>
2009-05-07T12:46:25.039496Z Ken Sharp</strong></p>
<blockquote>
<pre>
Fix (FAPI) : FAPI fails when FontBBox is missing

Details
(see also rev 9692) The FAPI code attempts to modify the FontBBox in the font
dictionary after rebuilding a font with a non-GS font renderer. If the FontBBox is
missing this creates an error condition. This is generally correct, FontBBox is a 
mandatory entry in a font dictionary.

However, the code can be called to define a (PDF) type1C font, a CFF font, and it is
possible (Bug689740.pdf) that the top DICT does not contain a FontBBox. In this case
we should inherit the FontBBox from the FontDescriptor in the PDF file, but we don't
have a mechanism to do that. 

Since PDF isn't a programming language the scope for using the FontBBox is pretty
limited, so for now I've chosen to ignore the error.

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

<p><strong><a name="2009-05-05T104010.582721Z"></a>
2009-05-05T10:40:10.582721Z Ken Sharp</strong></p>
<blockquote>
<pre>
The revision 9699 to quiet a Coverity warning incorrectly tested a char * instead of a
char ** for NULL.</pre>
<p>[base/gdevpdtc.c]</p>
</blockquote>

<p><strong><a name="2009-05-05T102848.253152Z"></a>
2009-05-05T10:28:48.253152Z Ken Sharp</strong></p>
<blockquote>
<pre>
revision 9714 reformatted a test in a way which left dead code behind. Put the test
back as it was, there was no functional difference anyway, this was just done for
investigative purposes.
</pre>
<p>[psi/zfapi.c]</p>
</blockquote>

<p><strong><a name="2009-05-04T105918.106139Z"></a>
2009-05-04T10:59:18.106139Z Till Kamppeter</strong></p>
<blockquote>
<pre>
Removed &quot;cupsEvenDuplex&quot; PPD keyword handling from the &quot;cups&quot; output device again. This keyword is already handled by the pstops and pdftopdf CUPS filters.
</pre>
<p>[cups/gdevcups.c]</p>
</blockquote>

<p><strong><a name="2009-05-02T031255.350064Z"></a>
2009-05-02T03:12:55.350064Z Alex Cherepanov</strong></p>
<blockquote>
<pre>
Commit .h file missed by the previous revision. Bug 690318, customer 631.
</pre>
<p>[base/gdevtifs.h]</p>
</blockquote>

<p><strong><a name="2009-05-02T003813.087492Z"></a>
2009-05-02T00:38:13.087492Z Ray Johnston</strong></p>
<blockquote>
<pre>
Supprt -dBigEndian=[true | false] so that the TIFF can be optimized for a
target host on a machine of another 'endian' byte orientation. This is a
mostly worthless change since the raster data doesn't change (only 16 or
32-bit values have endian issues). Thanks to wendyst2 at gmail.com for
this fix. Bug #690318.
</pre>
<p>[base/gdevtifs.c base/gdevtsep.c base/gdevtfnx.c base/gdevtfax.c]</p>
</blockquote>

<p><strong><a name="2009-05-02T000315.297730Z"></a>
2009-05-02T00:03:15.297730Z Ray Johnston</strong></p>
<blockquote>
<pre>
Add an 'IODevice' aware layer for filesystem enumeration 'gs_enumerate_*'
which needs to be used whenever the file is not known to be on the default
iodev (%os% by default). Use this in the PDL parser to open fonts so that
COMPILE_INITS=1 does not need the fonts on the disk.

The default PXL/PCL builds now use COMPILE_INITS=1.

Fixes bug #690367.

DETAILS:

The %rom%ttfonts/ path is placed BEFORE the built-in paths in pjparse.c,
but NOTE: the PCLFONTSOURCE environment variable will still supersede
the internal paths including %rom%ttfonts.

</pre>
<p>[base/gxiodev.h base/gsiorom.c base/gsiodev.c]</p>
</blockquote>

<p><strong><a name="2009-05-01T033924.695161Z"></a>
2009-05-01T03:39:24.695161Z Alex Cherepanov</strong></p>
<blockquote>
<pre>
Check for unbalanced q/Q operators in content streams of PDF forms.
Add missing Q when needed and issue a warning. Bug 690449, customer 870.

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

<p><strong><a name="2009-04-30T183449.698412Z"></a>
2009-04-30T18:34:49.698412Z Michael Vrhel</strong></p>
<blockquote>
<pre>
Fix for case when blending color space of soft mask is not specified.

DETAILS:

When the blending color space for the soft mask is not specified, the blending color space is set to UNKNOWN.  This is later resolved when the compositor action is handled.  In this case, the parents color space or the device color space is used for blending.  The code was in place 
to do this for a transparency group that did not have a defined color space but not for a soft mask. This caused bug 690457 with gxps which should now be resolved.

</pre>
<p>[base/gdevp14.c base/gstrans.c]</p>
</blockquote>

<p><strong><a name="2009-04-30T131410.674985Z"></a>
2009-04-30T13:14:10.674985Z Ken Sharp</strong></p>
<blockquote>
<pre>
Fix (FAPI): Incremental Type 42 font with GlyphDirectory &amp; missing glyphs fails

Details
The FAPI code assumed that the routine to extract glyph data from sfnts would always
work when a GlyphDirectory is present, and used glyf + loca if this routine failed, 
assuming that this meant there was no GlyphDirectory. However, the test file
Bug687845.ps contains a type 42 incrementally downloaded font which uses a
GlyphDirectory and also attempts to access glyphs which aren't defined in the
GlyphDirectory.

This caused the code to try and use the loca and glyf tables, which aren't present,
which caused an error.

Modified the FAPI code to return a glyph length of 0 when we have a GlyphDirectory but
no defined glyph. This causes GS to render nothing, which matches the regular result as
well as the action of Acrobat.

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

<p><strong><a name="2009-04-30T111504.348733Z"></a>
2009-04-30T11:15:04.348733Z Till Kamppeter</strong></p>
<blockquote>
<pre>
Adde support for the &quot;*APDuplexRequiresFlippedMargin:&quot; PPD keyword to the &quot;cups&quot; output device, fixed also the margin handling for custom paper sizes.
</pre>
<p>[cups/gdevcups.c]</p>
</blockquote>

<p><strong><a name="2009-04-30T104148.084860Z"></a>
2009-04-30T10:41:48.084860Z Till Kamppeter</strong></p>
<blockquote>
<pre>
Fixed unprintable margin handling of the &quot;cups&quot; output device.
</pre>
<p>[cups/gdevcups.c]</p>
</blockquote>

<p><strong><a name="2009-04-29T180250.832175Z"></a>
2009-04-29T18:02:50.832175Z Ralph Giles</strong></p>
<blockquote>
<pre>
Whitespace, line length and C-style improvements to gscolorbuffer.[ch].

These files tend to use 8 spaces instead of tabs; I haven't corrected
many of these.</pre>
<p>[base/gscolorbuffer.c base/gscolorbuffer.h]</p>
</blockquote>

<p><strong><a name="2009-04-29T170243.113835Z"></a>
2009-04-29T17:02:43.113835Z Ralph Giles</strong></p>
<blockquote>
<pre>
Remove a documentation reference to the gsindent script, which was
removed in r8455.
</pre>
<p>[doc/C-style.htm]</p>
</blockquote>

<p><strong><a name="2009-04-29T165602.841961Z"></a>
2009-04-29T16:56:02.841961Z Ralph Giles</strong></p>
<blockquote>
<pre>
Always initialize the color_remap function pointer.

Details:

NULL here means a straight memcpy, and the first case statement set
that explicitly as a fallback. However, the second did not, so it
was possible to reach the check on line 204 without initializing
color_remap.

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

<p><strong><a name="2009-04-29T163958.702496Z"></a>
2009-04-29T16:39:58.702496Z Ralph Giles</strong></p>
<blockquote>
<pre>
Set native line endings and keyword substitution on gscolorbuffer.[ch].
</pre>
<p>[base/gscolorbuffer.c base/gscolorbuffer.h]</p>
</blockquote>

<p><strong><a name="2009-04-29T112738.521368Z"></a>
2009-04-29T11:27:38.521368Z Marcos H. Woehrmann</strong></p>
<blockquote>
<pre>
Fixed compiler warning about /* within comment.
</pre>
<p>[base/gdevp14.c]</p>
</blockquote>

<p><strong><a name="2009-04-28T221103.867873Z"></a>
2009-04-28T22:11:03.867873Z Ralph Giles</strong></p>
<blockquote>
<pre>
Remove the unused including of gxlum.h in the inferno device.

The luminance weighting contants aren't used in the inferno driver.</pre>
<p>[base/gdevifno.c base/contrib.mak]</p>
</blockquote>

<p><strong><a name="2009-04-28T220604.042908Z"></a>
2009-04-28T22:06:04.042908Z Ralph Giles</strong></p>
<blockquote>
<pre>
Remove the stdlib.h include from the inferno device.

This is no longer needed since the malloc/free calls were replaced
with gs allocator calls in r9687.</pre>
<p>[base/gdevifno.c]</p>
</blockquote>

<p><strong><a name="2009-04-28T184143.426030Z"></a>
2009-04-28T18:41:43.426030Z Till Kamppeter</strong></p>
<blockquote>
<pre>
&quot;cups&quot; output device: Added support for &quot;cupsEvenDuplex&quot; PPD keyword.
</pre>
<p>[cups/gdevcups.c]</p>
</blockquote>

<p><strong><a name="2009-04-28T164409.981559Z"></a>
2009-04-28T16:44:09.981559Z Till Kamppeter</strong></p>
<blockquote>
<pre>
&quot;cups&quot; output device: Added support for the new &quot;*cupsBackSide:&quot; PPD keyword, fixed &quot;*cupsFlipDuplex:&quot; for landscape documents.
</pre>
<p>[cups/gdevcups.c]</p>
</blockquote>

<p><strong><a name="2009-04-28T151049.837556Z"></a>
2009-04-28T15:10:49.837556Z Alex Cherepanov</strong></p>
<blockquote>
<pre>
Take measures against Type 1 fonts that do 'systemdict begin' and
bypass all our font loading tricks. Bug 690450, customer 870.

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

<p><strong><a name="2009-04-28T133102.272975Z"></a>
2009-04-28T13:31:02.272975Z Ken Sharp</strong></p>
<blockquote>
<pre>
Ensure the pointer to standard cmap names is properly initialised before dereferencing
it. This is only to silence Coverity, the pointer is initialised to a static array and so
should never be invalid.

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

<p><strong><a name="2009-04-28T132346.582627Z"></a>
2009-04-28T13:23:46.582627Z Ken Sharp</strong></p>
<blockquote>
<pre>
Correct a potential buffer overrun. This looks like an oversight, the maximum size is
properly calculated taking the buffer length and data size into account, and used to
copy the data, but the trailing 0x00 (C string terminator) was written using the data
size without checking for a buffer overrun.

Warning from Coverity.
</pre>
<p>[base/gstype42.c]</p>
</blockquote>

<p><strong><a name="2009-04-28T131617.700417Z"></a>
2009-04-28T13:16:17.700417Z Ken Sharp</strong></p>
<blockquote>
<pre>
Check return value from cos_dict_put_key when writing document metadata. Warning from Coverity.
</pre>
<p>[base/gdevpdfe.c]</p>
</blockquote>

<p><strong><a name="2009-04-28T090410.426584Z"></a>
2009-04-28T09:04:10.426584Z Ken Sharp</strong></p>
<blockquote>
<pre>
Fix (pdfwrite) : Enlarge the hardcoded threshold for subsetting True Type fonts.

DETAILS :
Patch and log supplied by Leonardo.

Bug 689236 &quot;pdfwrite disregards -dSubsetFont= with TrueType&quot;. 

This fixes the valid part of the bug, which is related
to not-subsetting True Type fonts. The supplied example
exceeds the hardcoded constant of 500 glyphs,
so the font was always subset. Here we enlarge
the threshold to a more reasonable value. Note it doesn't
affect regular runs with &quot;standard&quot; distiller parameters.

ref# leo2079.

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

<p><strong><a name="2009-04-27T162433.581172Z"></a>
2009-04-27T16:24:33.581172Z Ken Sharp</strong></p>
<blockquote>
<pre>
Fix (FAPI) : FAPI fails when FontBBox is a packed array

Details
The FPAI code attempts to modify the FontBBox in the font dictionary after rebuilding a
font with a non-GS font renderer. However it assumed that the FontBBox would always be a regular array, capable of handling real numbers.

Some fonts have FontBBox arrays which only contain small integers, and which are 
therefore stored as packed arrays (t_shortarray in GS). This was cuasing the FAPI code
to throw an error.

Modified the code to replace the packed array with a full array before filling in the
new values, if the original array was packed.

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

<p><strong><a name="2009-04-27T160210.792862Z"></a>
2009-04-27T16:02:10.792862Z Till Kamppeter</strong></p>
<blockquote>
<pre>
Let &quot;cups&quot; output device take into account page size names.

The &quot;cups&quot; output device has selected the page size for determining
the margins only by the size and not by the name. So it was not
possible to have different page size entries with the same size and
different margins in the PPD, for example for fullbleed. This is fixed
now.

Fix done after a report from the HPLIP team on the OpenPrinting Summit
2009.

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

<p><strong><a name="2009-04-27T062519.306977Z"></a>
2009-04-27T06:25:19.306977Z Alex Cherepanov</strong></p>
<blockquote>
<pre>
Fix 2 oversights in AES decryption code: (1) add enumeration of ctx member in
AES state. Unmovable blocks are still garbage collected and need enumeration;
(2) use correct names to access /CFM attribute in PDF file.
Bug 688958, customers 870, 850, 531.

</pre>
<p>[base/saes.h Resource/Init/pdf_sec.ps]</p>
</blockquote>

<p><strong><a name="2009-04-24T173956.201358Z"></a>
2009-04-24T17:39:56.201358Z Ralph Giles</strong></p>
<blockquote>
<pre>
Replace malloc with gs_alloc_bytes in the inferno device.

Details:

The inferno device allocates an image writer struct in initwriteimage,
and later frees it when a null buffer is passed to writeimageblock.

We prefer to use gs_alloc_bytes instead of calling system malloc
because it respects memory contraints requested by the client. Note
however that the w pointer is local to inferno_print_page and not
traceable. This is fine and the structure doesn't have a lifetime
outside that function. If it did, it would need to be stored and
enumerated in inferno_device.

Note that this requires modifying the two utility functions to take
a memory pool pointer.</pre>
<p>[base/gdevifno.c]</p>
</blockquote>

<p><strong><a name="2009-04-24T173954.075505Z"></a>
2009-04-24T17:39:54.075505Z Ralph Giles</strong></p>
<blockquote>
<pre>
Dynamically allocate the inferno line buffer.

Previously, the scanline buffer was a 16k stack allocation. We still
reject bitmaps larger than that because of format limitations (so large
jobs above 300 dpi often fail with the inferno device) but now we
only allocate as much storage as needed, and on the heap instead of
the stack.</pre>
<p>[base/gdevifno.c]</p>
</blockquote>

<p><strong><a name="2009-04-24T141048.907852Z"></a>
2009-04-24T14:10:48.907852Z Ken Sharp</strong></p>
<blockquote>
<pre>
Enahncement (FAPI) : Allow FAPI to work with pdfwrite.

DETAILS :

FreeType could not be used with pdfwrite for any purpose, even to render
fonts for bitmap fallback. This seems overly pessimistic. 

This patch allows FAPI font rendering engines to work with pdfwrite, this 
will mean the FAPI interface is used for the selected types of font (see 
FAPI for documentation) including CharString decoding and especially 
rendering to bitmaps for type 3 font fallback.

In general pdfwrite uses its own routines to write and convert font types as
required, but it does not render any kind of font data, so if it is unable
to handle a font type it relies on the graphics library to render the glyph
to a bitmap, which is then stored in a type 3 font.

The FAPI code checks the device parameters to see if 'EmbedFontObjects' is 
true, and does not attempt to use the FAPI for fonts if it is. So firstly we
alter the device parameters in pdfwrite to set this to false.

The FAPI code was assuming that the text enumerator it received would always
be a 'show' enumerator, and extracted a pointer to the graphics state from it.
Of course if the device is pdfwrite then the text enumerator will instead be 
a pdf_text_enum. Modified the code to check the object type of the enumerator
and use the pointer to the imager state (checking it is a st_gs_state type)
if this is not a show enumerator. Also only update the 'cc' fields in the 
enumerator if this is a show enumerator.

Note that because the CharString and font validation is handled by the font
rendering engine, it may differ from the GS engine regarding the validity
of fonts.

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

<p><strong><a name="2009-04-24T010632.141706Z"></a>
2009-04-24T01:06:32.141706Z Ralph Giles</strong></p>
<blockquote>
<pre>
Allocate the inferno device's color cube dynamically.

DETAILS:

The inferno device generates a color cube on device open, ostensibly
to speed up the palette mapping. Previously this was stored in a
global array, adding 16 or 32 KB to the constant memory footprint
of ghostscript.

Instead, this commit allocates the color cube dynamically, storing
a pointer to it in the inferno_device structure. A custom structure
descriptor is added, and propagated through the new prn_device
construction macros, so it can be traced by the garbage collector.

In this way, the memory is only used when the inferno device is active.</pre>
<p>[base/gdevifno.c]</p>
</blockquote>

<p><strong><a name="2009-04-24T010630.215529Z"></a>
2009-04-24T01:06:30.215529Z Ralph Giles</strong></p>
<blockquote>
<pre>
Add a new prn_device_stype_body() construction macro.

Previously, all the printer device structures assumed there were no
additional pointer members in any subclass, and always installed the
st_device_printer structure descriptor. This may account for why so
few devices bother with point enumeration. Or perhaps it's the other
way around.

In any case, this commit adds two new construction macros for
filling in device structure templates: prn_device_stype_body and
prn_device_margins_stype_body. These take an additional argument,
the address of the subclass structure descriptor, after the device
name, and propagate it to the std_device_full_body_type macros.</pre>
<p>[base/gdevprn.h]</p>
</blockquote>

<p><strong><a name="2009-04-24T010628.058835Z"></a>
2009-04-24T01:06:28.058835Z Ralph Giles</strong></p>
<blockquote>
<pre>
Comment out the prototype for a commented out function in the inferno driver.

Fixes a gcc warning.</pre>
<p>[base/gdevifno.c]</p>
</blockquote>

<p><strong><a name="2009-04-24T010625.015250Z"></a>
2009-04-24T01:06:25.015250Z Ralph Giles</strong></p>
<blockquote>
<pre>
Add a prototype for init_p9color() in the inferno driver.

Fixes a warning on gcc.</pre>
<p>[base/gdevifno.c]</p>
</blockquote>

<p><strong><a name="2009-04-24T010622.357332Z"></a>
2009-04-24T01:06:22.357332Z Ralph Giles</strong></p>
<blockquote>
<pre>
Remove trailing whitespace in the inferno driver.</pre>
<p>[base/gdevifno.c]</p>
</blockquote>

<p><strong><a name="2009-04-22T195130.624349Z"></a>
2009-04-22T19:51:30.624349Z Michael Vrhel</strong></p>
<blockquote>
<pre>
Allow inline images in pdfwrite.

DETAILS:  

This had been disabled during the softmask branch work.  With the fix that Ray did to avoid having softmask images to be processed outside the 3X code with an extra softmask group, we can re-enable this.  From a test that Ken did we need the ability to do in-line to avoid creating large files in certain cases with pdfwrite.</pre>
<p>[base/gdevpdfi.c]</p>
</blockquote>

<p><strong><a name="2009-04-21T150101.102780Z"></a>
2009-04-21T15:01:01.102780Z Ken Sharp</strong></p>
<blockquote>
<pre>
Initialise a couple of structure members to avoid a Coverity warning.
</pre>
<p>[base/gdevpdfg.c]</p>
</blockquote>

<p><strong><a name="2009-04-21T075530.518210Z"></a>
2009-04-21T07:55:30.518210Z Ken Sharp</strong></p>
<blockquote>
<pre>
Add a check for a NULL pointer before using it. In fact this should not be possible
but it silences another Coverity warning.
</pre>
<p>[base/gdevpdtc.c]</p>
</blockquote>

<p><strong><a name="2009-04-20T193515.102625Z"></a>
2009-04-20T19:35:15.102625Z Michael Vrhel</strong></p>
<blockquote>
<pre>
Add missing gscolorbuffer.c and gscolorbuffer.h that should have been in soft mask branch merge.  See previous commit message for differences and details.</pre>
<p>[base/gscolorbuffer.c base/gscolorbuffer.h]</p>
</blockquote>

<p><strong><a name="2009-04-20T191624.907829Z"></a>
2009-04-20T19:16:24.907829Z Michael Vrhel</strong></p>
<blockquote>
<pre>
This is a merge of the smask_work branch into the trunk.  The merge fixes issues related to missing soft masks, improperly rendered soft masks and transparency group color spaces.  It addresses a number of bugs including 688728 689422 689512 689931 688601 689968 690958 690115 690157 and 690170.    

DETAILS:
This commit is a compilation of changes that occurred in the smask_work SVN branch.  That branch was created with rev 9134 on Oct 8 2008.  The final commit to that branch was with rev.  9665.  For extreme details on the changes in this commit, you can review the commit messages within that branch.
Soft masks:  The basic architecture for the soft mask remains in place; where by the soft mask is composed with the popping of the transparency group.  In performing soft mask operations, the current code pushes a soft mask, which creates a new buffer.  This buffer is then rendered into.  Once the soft mask drawing is completed, the soft mask is popped.  This operation moves the soft mask buffer into the mask buffer of the parent transparency group.  When that transparency group is popped, it should be composed with its parent layer, while being adjusted with the soft mask buffer values.  If there was never a transparency group that was popped following the soft mask, then the soft mask would not be applied.  The solution to this issue involved changes in pdfdraw.ps that forced the creation of a transparency group when one had not yet been created if a soft mask push was to occur.  When this extra group is popped, the soft mask will then be applied.  The PDF interpreter knows that a SMask exists in the ExtGstate when 'SoftMask' is not null. Since the ExtGState elements are part of the top dict, the 'begin' .. 'end'  part of the 'q' and 'Q' operators, respectively, take care of keeping the SoftMask current.  When a transparency group is executed, the SoftMask is set to null since the SMask saved in the pdf14 'maskbuf' element will be applied during the blending when the transparency group is popped.
Soft masks are now drawn in the specified group color space.  Previously, the soft mask was drawn in the target device color space and then the K channel for the CMYK case or the R channel for the RGB case were used as the soft mask luminance channel.   Now the mapping from the DeviceRGB or DeviceCMYK to a luminance component is performed as specified by the PDF specification.  If the color space is CIE based, the base device space is used.  This CIE case does not follow the PDF specification but does follow what occurs with Acrobat Reader.    Previously the code carried around the soft mask buffer as an RGB or CMYK buffer.  It is now represented by a gray buffer.
Transparency groups: Color space changes for transparency groups are now followed.  Previously, the target device color space was always used for blending.  Now the proper color space is used, with the exception of ICC and other CIE based spaces.  For those spaces the base device color space is used.  The ICC and CIE based spaces will be addressed when the ICC branch is merged.  Changing the current code to do forward and backward mappings with the ICC color spaces is beyond the work scope of the smask_work branch.    In the presence of nested transparency groups, the parent color space can be different than the child color space.  When the child is popped, its contents are now converted from the child’s color space to the parent’s color space.  Note that if the output device is a separation device, the transparency group color space is ignored and the blending is performed amongst the channels, which can be numerous if there are many spot colors.  Also note that for soft mask groups, the alternate tint transform is always used for spot colors.
To achieve these fixes, a number of changes besides those already mentioned above were required.  These include:
A dynamic update of the pdf14 device colorinfo value based upon the color space of the current transparency group.  This information is used often in deciding how to encode and decode the color data.  In the case of the clist writer and reader, the code often ends up forwarding certain operations to the target device in which case we no longer would have the colorinfo of the pdf14 device.  The solutions to this problem required the addition of a clist_color_info member value to the clist writer device.  This value is updated in the same manner that the pdf14 device will be updated during the clist reader phase thereby ensuring the proper color information is written and read.  Also required was the addition of a trans_device item to the imager state.  This was needed due to the fact that the clist writer forwards its fill path command to the target device.  In the shading code, if we have a DeviceN color space we eventually get back to pdf14_cmap functions, assuming we have a RGB or CMYK target device.  These cmap functions should make use of the clist device to map to the proper blending color space NOT the target device color space.  In the current code, the cmap functions can only see the target device and the imager state hence the solution to add trans_device to the imager state.  This is only used during clist writing and assigned during the clist writers PDF14 fill path at which point it is assigned the address of the clist writer device.  During the PDF14 cmap functions, if the trans_device is not NULL in the imager state we use that device's color mapping procs instead of the target device color mapping procs.  In this approach, we maintain access to the transparency group color space and its procedures through the imager state.  Finally, shading fills should NOT occur in the device color space when we are within a transparency group with a different color space.  To avoid this issue a boolean named has_transparency was added to the imager state.  Now if we find that we are in a transparency group during the shading fills, then the is_linear_color_applicable operation will return a false and the target color space is not used for blending.
To maintain the changing pdf14 color space information in the presence of nested groups, parent_color_info_procs was added to the already nested pdf14_buf_s where the new pdf14_parent_color_t contains the information related to the parent’s color space.   This handles the nesting of color information for the clist reader.  For the clist writer, pdf14buf is always NULL.  For this case, a pointer to a pdf14_parent_t was added to pdf14_device_s.  A stack was created and the color information is pushed on and popped off the stack as the transparency groups are pushed and popped during the clist writer phase.  
Changes were also required in pdfdraw.ps to handle the case when a transparency group does NOT define a color space.  In this case, the parent’s group color space (or the target device color space if we are at the first level) should be used.
In the presence of a monochrome target device, the previous code PDF14 device was still pushing an RGB buffer initially.  This is now changed and a monochrome buffer is created. 
There was much confusion in the code relating to the number of colors, separations, spot colors, and process colors.  This became clear when looking at a file that had over 100 colorants. GX_DEVICE_COLOR_MAX_COMPONENTS defines the max number of different colors that we currently encode.  This should include both the process colors and the spot colors.  Many parts of the code looked at these colors differently. Some portions of the code treated the number of spot colors and/or separations as having a range to GX_DEVICE_COLOR_MAX_COMPONENTS, while other parts include the process color AND the spot colors in that range.   The changes here ensure that GX_DEVICE_COLOR_MAX_COMPONENTS defines the max number for all process and spot colors.  
The current code did not recognize patterns with transparency in PDF.  Now, the presence of transparency in a pattern is detected.  If a transparency component is found, the pdf14 compositor is installed.    
Finally, pdf_draw.ps was modified so that when an image is encountered with a softmask (/doimagesmask) AND the output device is pdfwrite then we do avoid the DoImage that is used to fill the softmask buffer for the pdf14 device.  The pdfwrite device will obtain the maskdata as part of image3x.  Previously, the mask image was at times being placed in-line for the pdfwrite device during the DoImage that is associated with storing the softmask buffer in the pdf14device.  In the old flow, the SMask image was effectively being processed twice.
    
</pre>
<p>[psi/zcolor.c base/gxclimag.c base/gxpcmap.c base/gdevdevn.c psi/ztrans.c base/gsovrc.c base/gdevpdft.c base/gxblend1.c base/gxcie.h /trunk/gs base/gxshade6.c base/gxclpath.c base/gsptype1.c base/gsccolor.h base/gsptype1.h base/gsistate.c base/gximag3x.c base/gscspace.c base/gxclutil.c base/lib.mak base/gxistate.h base/gscspace.h Resource/Init/pdf_main.ps psi/int.mak Resource/Init/pdf_draw.ps psi/zpcolor.c base/gxdevcli.h Resource/Init/pdf_ops.ps base/gdevp14.c base/gxclrect.c base/gxclist.c base/gdevp14.h base/gdevtsep.c base/gxdcolor.c base/gstrans.c base/gxclist.h base/gstparam.h base/gxblend.c base/gstrans.h base/gdevpdfi.c base/gxblend.h]</p>
</blockquote>

<p><strong><a name="2009-04-20T174420.115590Z"></a>
2009-04-20T17:44:20.115590Z Till Kamppeter</strong></p>
<blockquote>
<pre>
Added &quot;cdnj500&quot; device to support HP DesignJet 500 (patch from Timur Maximov).
</pre>
<p>[contrib/gdevcd8.c contrib/contrib.mak base/configure.ac]</p>
</blockquote>

<p><strong><a name="2009-04-20T155907.741446Z"></a>
2009-04-20T15:59:07.741446Z Ken Sharp</strong></p>
<blockquote>
<pre>
Update revision 9658 to silence a second Coverity warning and potential dereference of
a NULL pointer. Should still be impossible and is definitely an error condition.
</pre>
<p>[base/gdevpdtc.c]</p>
</blockquote>

<p><strong><a name="2009-04-20T155438.325839Z"></a>
2009-04-20T15:54:38.325839Z Ken Sharp</strong></p>
<blockquote>
<pre>
Add a check to ensure a font pointer is valid before dereferencing it. This should 
always be the case, but its worth checking to avoid a crash and should silence a Coverity
warning.</pre>
<p>[base/gdevpdtc.c]</p>
</blockquote>

<p><strong><a name="2009-04-20T154356.142408Z"></a>
2009-04-20T15:43:56.142408Z Ken Sharp</strong></p>
<blockquote>
<pre>
initialise first_visit in the gs_cpath_enum structure with a dummy value. This will be
overwritten when the enumerator actually starts, this is only to silence a warning
from Coverity.
</pre>
<p>[base/gxcpath.c]</p>
</blockquote>

<p><strong><a name="2009-04-20T145933.677002Z"></a>
2009-04-20T14:59:33.677002Z Ken Sharp</strong></p>
<blockquote>
<pre>
Initialise a member of a struct to silence a Coverity warning. The warning about use of
an uninitialised variable is actually bogus, the value is copied, but not otherwise used.
</pre>
<p>[base/gdevpdfg.c]</p>
</blockquote>

<p><strong><a name="2009-04-20T143115.938087Z"></a>
2009-04-20T14:31:15.938087Z Ken Sharp</strong></p>
<blockquote>
<pre>
Check the length of the 'binary mode' file access string before strcat'ing it, to 
prevent a potential (but not actual) buffer overflow. Silences a Coverity warning.
</pre>
<p>[base/gdevpdf.c]</p>
</blockquote>

<p><strong><a name="2009-04-20T142728.365570Z"></a>
2009-04-20T14:27:28.365570Z Ken Sharp</strong></p>
<blockquote>
<pre>
Reformat a conditional sprintf to silence a Coverity warning.
</pre>
<p>[base/gdevpdfu.c]</p>
</blockquote>

<p><strong><a name="2009-04-20T123851.604664Z"></a>
2009-04-20T12:38:51.604664Z Ken Sharp</strong></p>
<blockquote>
<pre>
Fix (colour) : Ensure /UseCIEColor sets for initial space correctly.

Details
bug #690432 &quot;/UseCIEColor not working with default colour space&quot;

The change to process colour and colour space in C instead of in PostScript overlooked 
code in gs_setpd.ps  which interacts badly with an optimisation.

The optimisation skips changing colour space if its the same as the current space. But
if /UseCIEColor has changed value we must not skip the change. This was achieved 
previously by only skipping the change if UseCIEColor was false, and setting the space
to something other than DeviceGray in gs_setpd.ps.

We take advantage of the same trickery by always setting the space to something other
than DeviceGray in gs_setpd.ps, in the knowledge that initgraphics will switch the 
current space back to DeviceGray. Because the spaces don't match we will process the
change, getting the correct result for UseCIEColor.

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

<p><strong><a name="2009-04-20T120728.372687Z"></a>
2009-04-20T12:07:28.372687Z Alex Cherepanov</strong></p>
<blockquote>
<pre>
Some broken TrueType 1 fonts may declare more tables than they actualy have.
Use .peekstring instead of for readstring for resding the font directory to
avoid positioning non-seekable input stream past the 1st table data.
Bug 690423, customer 580.

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

<p><strong><a name="2009-04-20T065610.039816Z"></a>
2009-04-20T06:56:10.039816Z Ken Sharp</strong></p>
<blockquote>
<pre>
Fix (pdfwrite) : Work aroung wrong numGlyphs.

DETAILS :
Patch and log supplied by Leonardo.

Bug 690047 &quot;Incorrect cmap generated by pdfwrite&quot;.

If a source True Type font defines numGlyphs lesser then
the actually defined number of glyphs,
the old code writes an incorrect True Type header with
wrong offsets to subtables.

Since in nowadays the number of glyphs may be increased
due to font merging, we decided to write the extended subtables
with a bigger number of glyphs. See comments in code.
See enlarged_numGlyphs and related code portions.
The original numGlyphs is kept unchanged for easier debugging.

For an easier debugging added checks into psf_write_truetype_data
for comparing actual subtable offsets with ones written
into the True Type header. The new structure subtable_positions
works for that.

Also improved a printing in gs_type42_font_init.
The old code can print occasional garbage beyond the font name end.
 
ref# leo2077.

</pre>
<p>[base/gstype42.c base/gdevpsft.c]</p>
</blockquote>

<p><strong><a name="2009-04-18T220742.659183Z"></a>
2009-04-18T22:07:42.659183Z Ray Johnston</strong></p>
<blockquote>
<pre>
Improve the documentation related to the %rom$ file system, searching when the
executable is built with COMPILE_INITS=1 (the current default on most platforms)
and the (mostly deprecated) older methods for compiling Type 1 fonts and Halftone
into threshold arrays.
</pre>
<p>[doc/Use.htm doc/Make.htm]</p>
</blockquote>

<p><strong><a name="2009-04-17T081645.715059Z"></a>
2009-04-17T08:16:45.715059Z Ken Sharp</strong></p>
<blockquote>
<pre>
Change #include of stdlib.h to use angle bracket form to avoid local path searches.
</pre>
<p>[base/gdevpdfj.c]</p>
</blockquote>

<p><strong><a name="2009-04-17T003226.343700Z"></a>
2009-04-17T00:32:26.343700Z Ralph Giles</strong></p>
<blockquote>
<pre>
Remove unnecessary includes of gserrors.h in the jpeg stream module.

Fixes two coverity warnings.</pre>
<p>[base/lib.mak base/sjpegd.c base/sjpege.c]</p>
</blockquote>

<p><strong><a name="2009-04-16T160034.882286Z"></a>
2009-04-16T16:00:34.882286Z Ken Sharp</strong></p>
<blockquote>
<pre>
Fix (pdfwrite): Ignore missing side bearing/width in type 1 fonts.

Details:
Bug #689573: &quot;glyphs with no (h)sbw cause error with pdfwrite&quot;.

Fonts which contain glyphs that do not begin with a sbw or hsbw operator are
technically invalid, but Acrobat Distiller, and other PostScript rips, ignore
the error and render the glyph with a side bearing and width of 0.

Modified the type 1 font code and the type 1 to type 2 (CFF) conversion code
to assume that such glyphs have a width and side bearing of 0 and are not a
cause for error.

</pre>
<p>[base/gstype1.c base/gxtype1.c base/gdevpsfx.c]</p>
</blockquote>

<p><strong><a name="2009-04-15T200827.661663Z"></a>
2009-04-15T20:08:27.661663Z Alex Cherepanov</strong></p>
<blockquote>
<pre>
Some broken Type 1 fonts define some of the attributes in the external scope
instead of defining them in the font dictionary. The patch tries to pick
the keys from the external scope and put them back to the font dictionary.
Bug 690418, customer 1110.

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

<p><strong><a name="2009-04-15T191847.976886Z"></a>
2009-04-15T19:18:47.976886Z Henry Stiles</strong></p>
<blockquote>
<pre>
On modern processors the c library's memset is usually faster than our
custom inline coding.  At least, using memset on recent windows, mac,
and linux platforms is appreciably faster for very long simple jobs
where erasing the page is significant relative to total job time.
Using the library's memcpy needs more investigation, it does not seem
to have significant impact on performance and also results in many
regressions which we haven't checked.
</pre>
<p>[base/gdevm24.c]</p>
</blockquote>

<p><strong><a name="2009-04-15T065051.933830Z"></a>
2009-04-15T06:50:51.933830Z Alex Cherepanov</strong></p>
<blockquote>
<pre>
Detect /Pages node without /Kids and bail out early. The code that tries
to determine the number of pages in the document takes such node as a /Page
node, which causes very long search for the last page. Bug 690389.

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

<p><strong><a name="2009-04-14T045606.103942Z"></a>
2009-04-14T04:56:06.103942Z Alex Cherepanov</strong></p>
<blockquote>
<pre>
Write color to the clip list even when it has no variable data, as in
[/Separation/None ...]. Fix a bug introduced by r. 8770 that causes rendering
of invisible objects with the last visible color. Bug 690395, customer 330.

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

<p><strong><a name="2009-04-13T073920.206752Z"></a>
2009-04-13T07:39:20.206752Z Ken Sharp</strong></p>
<blockquote>
<pre>
Silence some Coverity warnings (reasonable warnings, but not actually problems).</pre>
<p>[base/gdevpdfj.c base/gdevpdtb.c base/gdevpdfe.c]</p>
</blockquote>

<p><strong><a name="2009-04-13T073125.084782Z"></a>
2009-04-13T07:31:25.084782Z Ken Sharp</strong></p>
<blockquote>
<pre>
Fix a typo in a comment.</pre>
<p>[base/gdevpdtt.c]</p>
</blockquote>

<p><strong><a name="2009-04-11T122022.013355Z"></a>
2009-04-11T12:20:22.013355Z Alex Cherepanov</strong></p>
<blockquote>
<pre>
Repair broken PDF files created by &quot;OKI HotKey&quot; that misspell &quot;endobj&quot;
as &quot;enbobj&quot;. Bug 690397.

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

<p><strong><a name="2009-04-11T045950.073474Z"></a>
2009-04-11T04:59:50.073474Z Ray Johnston</strong></p>
<blockquote>
<pre>
Fix for crash on 18-02B in clist code. The clist cbuf (on the stack) would
write past the end of the buffer are polluting the next varaible on the
stack (data_bits). Fixes 690399.

DETAILS:

This problem was introduced with r8712 (leonardo). The return value for
gx_dc_pattern_read_raster should be the number of bytes consumed, but in some
(rare) cases it would return 0, causing a later contamination of a byte past the
end of a buffer on the stack, polluting another value. The effect would be
dependent on the 'endian-ness' since only one byte was overwritten.

Also 'protection' for this condition was added in top_up_cbuf to prevent
future problems.
</pre>
<p>[base/gsptype1.c base/gxclrast.c]</p>
</blockquote>

<p><strong><a name="2009-04-10T173604.582061Z"></a>
2009-04-10T17:36:04.582061Z Ralph Giles</strong></p>
<blockquote>
<pre>
Remove the reference to needing to compile in pdfwrite, which is 
confusing to casual users. The pdfwrite device is part of all the
default builds.
</pre>
<p>[doc/Ps2pdf.htm]</p>
</blockquote>

<p><strong><a name="2009-04-09T135724.013138Z"></a>
2009-04-09T13:57:24.013138Z Ken Sharp</strong></p>
<blockquote>
<pre>
Fix (pdfwrite) : Omitted to write CIDToGIDMap when it was Identity, even if writing PDFA

Details
When writing CIDFontType2 fonts we should emit a CIDToGIDMap entry, which we do. However
if the map is the identity then we are permitted to omit it. Unless, of course, we are
writing a PDF/A compliant file, in which case we must write /Identity.

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

<p><strong><a name="2009-04-09T084423.319707Z"></a>
2009-04-09T08:44:23.319707Z Ken Sharp</strong></p>
<blockquote>
<pre>
Accidentally removed the prototype for pdf_document_metadata. Restored.</pre>
<p>[base/gdevpdfg.h]</p>
</blockquote>

<p><strong><a name="2009-04-09T083755.568580Z"></a>
2009-04-09T08:37:55.568580Z Ken Sharp</strong></p>
<blockquote>
<pre>
Fix (pdfwrite): remove unused code for Font metadata.

Details:
Bug #690391: &quot;PDF/A support generates invalid object references to font metadata&quot;.

The code for writing font metadata in PDF/A output was temporarily disabled
to fix problems with PDF/A output. 

It seems Acrobat cannot be persuaded to validate any file containing font
Metadata as PDF/A compliant, and Distiller cannot be persuaded to create
a PDF file containing font metadata.

The code has now been permanently removed.

</pre>
<p>[base/gdevpdfg.h base/gdevpdtb.c base/gdevpdfe.c]</p>
</blockquote>

<p><strong><a name="2009-04-08T211118.174166Z"></a>
2009-04-08T21:11:18.174166Z Ray Johnston</strong></p>
<blockquote>
<pre>
The massive 'DeviceN' commit (r2925) broke this. The correct b_w w_b
palette should not rely on color_info.polarity, but instead needs to
be determined from the value of color black. Inverted if black is not
0. Bug 690314 for customer #661.

DETAILS:

In page buffer mode, the 'palette' was set up during the first ht painting
operation from gdevmr1.c. This code was only used in clist mode when making
the 'buffer device' for the band.
</pre>
<p>[base/gdevmem.c]</p>
</blockquote>

<p><strong><a name="2009-04-07T160722.605043Z"></a>
2009-04-07T16:07:22.605043Z Ken Sharp</strong></p>
<blockquote>
<pre>
Removed the function pdf_color_space, which simply called pdf_color_space_named, with
two additional fixed parameters, NULL and 0.

Because these two function called each other Coverity seemed unable to deal with the
recursion and logged numerous STACK_USE errors. Also, its much easier to follow a single
function when debugging.

</pre>
<p>[base/gdevpdfk.c base/gdevpdfg.h base/gdevpdfb.c base/gdevpdfc.c base/gdevpdft.c base/gdevpdfv.c base/gdevpdfg.c base/gdevpdfi.c]</p>
</blockquote>

<p><strong><a name="2009-04-07T102002.752832Z"></a>
2009-04-07T10:20:02.752832Z Ken Sharp</strong></p>
<blockquote>
<pre>
Fix (ps2epsi): rounding problems calculating bbox.

Details:
Bug #688500 &quot;ps2epsi produces too-narrow bounding box (2)&quot;.

Text and linework rendered at low resolution can differ by a few pixels from
that rendered at higher resolution because of serifs, miters etc. The ps2epsi 
script rendered the job at low resolution and used that both to calculate the 
bounding box, as well as for the epsi preview. This could lead to small errors 
if the job was re-rendered at a higher resolution

The new approach is to use the bbox device in Ghostscript to calculate a more
accurate bounding box. This has meant altering the scripts for all the
operating systems.

Also, the ps2epsi.bat file did not work correctly under Windows Vista. A
new 'cat.ps' file has been added to gs/lib. This uses the %infile% and
%outfile% environment variables and concatenates the two files together.
This only affects the Windows batch file.

</pre>
<p>[lib/ps2epsi lib/ps2epsi.ps lib/ps2epsi.cmd lib/cat.ps lib/ps2epsi.bat]</p>
</blockquote>

<p><strong><a name="2009-04-06T153047.928660Z"></a>
2009-04-06T15:30:47.928660Z Ken Sharp</strong></p>
<blockquote>
<pre>
Fix (pdfwrite): Incorrect handling of short images with subsampling.

Details:
bug #690350 &quot;Conversion to pdf of a color pcl file generated by pjxl300 
gsview 4.9 driver&quot;

The PCL file consists of a single large image covering the page. However,
the PCL interpreter calls 'process_zero_rows' (rtraster.c) which has the
side effect (sometimes at least) of closing the image and restarting it.

Pdfwrite already has code to handle a short image like this, it replaces
the image dictionary /Height value with the number of rows of data
actually received. However, if subsampling is enabled, this can be
incorrect, some of the rows of received data may have been discarded.

Altered pdf_end_image_binary to check if subsampling is taking place and
if it is to calculate the subsample factor and divide the number of rows
of data received by the subsample factor before storing as the new /Height.

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

<p><strong><a name="2009-04-06T134844.630941Z"></a>
2009-04-06T13:48:44.630941Z Alex Cherepanov</strong></p>
<blockquote>
<pre>
Skip Identity /TR function in soft mask dictionary on PostScript level instead
of passing {} to .begintransparencymaskgroup because ref_function() only
accepts function made of data and operator %execfunction. Bug 690379.

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

<p><strong><a name="2009-04-04T163615.613476Z"></a>
2009-04-04T16:36:15.613476Z Alex Cherepanov</strong></p>
<blockquote>
<pre>
Revert initial /PolicyNotFount to 1. The previous value, 7, introduced by ESP
Ghostscript merger (rev. 8026) was non-standard and handled by Ghostscript
like 0. Fix '/undefined in --setpagedevice--' error in CUPS mode
(-dNOMEDIAATTRS) when setpagedevice request has unsupported keys. Bug 690376.
</pre>
<p>[Resource/Init/gs_setpd.ps]</p>
</blockquote>

<p><strong><a name="2009-04-04T101056.584771Z"></a>
2009-04-04T10:10:56.584771Z Ken Sharp</strong></p>
<blockquote>
<pre>
Enhancement (pdfwrite) : Allow pdfwrite to produce multiple copies of pages. New flag
        'DoNumCopies' added.

Details
Bug #690355 : &quot;pdfwrite ignores the &quot;#copies&quot; setting in PostScript input&quot;

The pdfwrite device follows the behaviour of Acrobat Distiller and ignores the /#copies
and /NumCopies settings in PostScript. This is at least partly because these can't be
expected to work properly with Destination annotations specifying a page as the
destination (eg Link or Outline annotations).

However CUPS (and potentially other PDF workflow applications) may have no way of
determining that application-produced PostScript requires multiple copies to be 
printed, after the file has been converted to PDF.

For the benefit of such applications a new flag 'DoNumCopies' has been added, if 
present then pdfwrite will duplicate each page in the output as many times as the 
/#copies or /NumCopies current setting.

There is currently no provision for reordering the pages, the duplicates follow the 
original immediately in page order.

</pre>
<p>[base/gdevpdfx.h base/gdevpdf.c base/gdevpdfp.c doc/Ps2pdf.htm base/gdevpdfu.c]</p>
</blockquote>

<p><strong><a name="2009-03-31T152150.984238Z"></a>
2009-03-31T15:21:50.984238Z Ken Sharp</strong></p>
<blockquote>
<pre>
Another case of the return value from pdf_attached_font_resource not being checked.</pre>
<p>[base/gdevpdtt.c]</p>
</blockquote>

<p><strong><a name="2009-03-31T151752.100598Z"></a>
2009-03-31T15:17:52.100598Z Ken Sharp</strong></p>
<blockquote>
<pre>
Revision 9604 left an uninitialised variable being used. Moved usage beyond initialisation.</pre>
<p>[psi/zfapi.c]</p>
</blockquote>

<p><strong><a name="2009-03-31T145918.448263Z"></a>
2009-03-31T14:59:18.448263Z Ken Sharp</strong></p>
<blockquote>
<pre>
Check the return value from pdf_attached_font_resource to silence a Coverity warning.
</pre>
<p>[base/gdevpdtt.c]</p>
</blockquote>

<p><strong><a name="2009-03-31T145209.178132Z"></a>
2009-03-31T14:52:09.178132Z Ken Sharp</strong></p>
<blockquote>
<pre>
Check the return value from pdf_open_docuemnt to fix a Coverity warning.</pre>
<p>[base/gdevpdfu.c]</p>
</blockquote>

<p><strong><a name="2009-03-31T144129.436551Z"></a>
2009-03-31T14:41:29.436551Z Ken Sharp</strong></p>
<blockquote>
<pre>
Remove some unused code relating to embedding font metadata in PDF files.</pre>
<p>[base/gdevpdfe.c]</p>
</blockquote>

<p><strong><a name="2009-03-31T143347.297209Z"></a>
2009-03-31T14:33:47.297209Z Ken Sharp</strong></p>
<blockquote>
<pre>
Remove unused variable 'glyph_index' from FAPI_do_char (gcc warning)</pre>
<p>[psi/zfapi.c]</p>
</blockquote>

<p><strong><a name="2009-03-31T143014.712906Z"></a>
2009-03-31T14:30:14.712906Z Ken Sharp</strong></p>
<blockquote>
<pre>
Remove a bunch of unused headers to silence Coverity warnings.</pre>
<p>[base/gdevpdfj.c psi/zfapi.c base/gdevpdfm.c base/gdevpdfo.c base/gdevpdtb.c base/gdevpdfp.c base/gdevpdtc.c base/gdevpdfr.c base/gdevpdte.c base/gdevpdtf.c base/gdevpdfu.c base/gdevpdti.c base/gdevpsfm.c base/gdevpdf.c base/gdevpsf2.c base/gdevps.c]</p>
</blockquote>

<p><strong><a name="2009-03-31T140120.321673Z"></a>
2009-03-31T14:01:20.321673Z Ken Sharp</strong></p>
<blockquote>
<pre>
Fix (pdfwrite): Incorrect handling of type 1 counter control hints.

Details:
bug #690349 &quot;corrupt PDF is generated out of PostScript-file with asian fonts&quot;

When converting type 1 outlines to type 2 outlines, we were not catering for
OtherSubrs 12 or 13 (counter control hints) in the first pass over the font.
These operators take a large number of arguments, and these were being left 
on the font operand stack. This quickly resulted in a stack overflow and an 
invalidfont error. We now remove the operands from the stack when we encounter 
them.

In addition, the code for writing CIDFontType0 fonts which called the conversion
routine was not checking the return value, and carried on trying to embed the font
anyway.

</pre>
<p>[base/gdevpsf2.c base/gdevpsfx.c]</p>
</blockquote>

<p><strong><a name="2009-03-30T162653.447317Z"></a>
2009-03-30T16:26:53.447317Z Ken Sharp</strong></p>
<blockquote>
<pre>
Fix (fonts): Potential dereference of NULL pointer.

Details
Flagged by Coverity, the FAPI code used op_show_find to get the text enumerator, but
did not check the return value, which can be NULL for a failure. Later the enumerator
is dereferenced, potentially causing a crash. This is actually almost certainly
impossible since this is a finish routine and the enumerator is known to have existed
previously, but its good to be safe.

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

<p><strong><a name="2009-03-28T234738.237280Z"></a>
2009-03-28T23:47:38.237280Z Alex Cherepanov</strong></p>
<blockquote>
<pre>
Recognize composite fonts and process descendant fonts according to
-dShowEmbeddedFonts flag. Bug 690363.
</pre>
<p>[toolbin/pdf_info.ps]</p>
</blockquote>

<p><strong><a name="2009-03-28T210325.515606Z"></a>
2009-03-28T21:03:25.515606Z Alex Cherepanov</strong></p>
<blockquote>
<pre>
Accept a string (instead of a name) as a possible /FontName value in
FontDescriptor. Recover broken PDF file generated by &quot;MapForm&quot;. Bug 690365.

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

<p><strong><a name="2009-03-28T193204.398772Z"></a>
2009-03-28T19:32:04.398772Z Alex Cherepanov</strong></p>
<blockquote>
<pre>
Ignore /XObject attribute if it's not a dictionary. Recover broken
PDF file generated by &quot;Allegro Design Publisher&quot;. Bug 690364, customer 870.

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

<p><strong><a name="2009-03-26T134629.711009Z"></a>
2009-03-26T13:46:29.711009Z Ken Sharp</strong></p>
<blockquote>
<pre>
Fix (pdfwrite) : NeverEmbed/AlwaysEmbed not working properly.

DETAILS :

Patch and Log supplied by Leonardo.

Bug 689610 &quot;Possible /NeverEmbed vs /AlwaysEmbed problem&quot;
The root of the problem is that (1) empty arrays did not work,
and (2) existing values of the parameters (before setdistillerparams)
were not properly accounted for in setdistillerparams.
 

In the old code, PS and C parts of &quot;embed&quot; parameters implementation
are inconsistent each to another and to the documentation. Replacing both with the
right logic defined in the Adobe Distiller Parameters specification.
The comment in gdevpsdp.c line 81 is kept as the basic interface definition.

Note: in the old code param_read_embed_array could not distinguish empty array from
no array,  but it is important for the Adobe logic.
Also psdf_put_embed_param parameters did not correspond  to the documentation in
gdevpsdp.c ln 81.

ref# leo2073.

</pre>
<p>[Resource/Init/gs_pdfwr.ps base/gdevpsdp.c]</p>
</blockquote>

<p><strong><a name="2009-03-25T130006.154261Z"></a>
2009-03-25T13:00:06.154261Z Till Kamppeter</strong></p>
<blockquote>
<pre>
Fixes in the &quot;cups&quot; (CUPS Raster) output device driver:

Fixed segmentation fault due to missing definition of get_color_comp_index() function. Used dummy function gx_error_get_color_comp_index() now (bug 690338).

Updated some (currently not used) functions to the current internal API of Ghostscript.

Made pre-initialization of device data structure complete.

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

<p><strong><a name="2009-03-25T051439.001280Z"></a>
2009-03-25T05:14:39.001280Z Alex Cherepanov</strong></p>
<blockquote>
<pre>
Don't apply mapped transfer function to the uninitialised buffer. Old code
had no effect other than causing Valgrind warnings. Bug 688908.

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

<p><strong><a name="2009-03-25T050111.445938Z"></a>
2009-03-25T05:01:11.445938Z Alex Cherepanov</strong></p>
<blockquote>
<pre>
When CCITTEncode'd stream is not properly terminated and used as an embedded
image, the filter may consume 'E' from 'EI'. Change PDF interpreter to accept
'I' as a synonym to 'EI'. Bug 690300, customer 353.

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

<p><strong><a name="2009-03-24T170750.052635Z"></a>
2009-03-24T17:07:50.052635Z Ken Sharp</strong></p>
<blockquote>
<pre>
Remove some #ifdef code and some C++ style comments from the FreeType bridge code.

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

<p><strong><a name="2009-03-24T155525.161400Z"></a>
2009-03-24T15:55:25.161400Z Ken Sharp</strong></p>
<blockquote>
<pre>
Fix (fonts) : Sheared/rotated text incorrect with FreeType bridge

Details
The FreeType code uses a different order for the transformation matrix elements, we
were sending the matrix in PostScript order, resulting in incorrect transformations.

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

<p><strong><a name="2009-03-23T151913.060013Z"></a>
2009-03-23T15:19:13.060013Z Ken Sharp</strong></p>
<blockquote>
<pre>
Fix (pdfwrite) : Wrong page orientation with italic font.

DETAILS :

Patch and log message submitted by Leonardo.

Bug 689574 &quot;italic/oblique fonts produce incorrect page orientation&quot;. 

Replacing text orientation recognition trick with a right math.

ref# leo2072.

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

<p><strong><a name="2009-03-23T141438.656422Z"></a>
2009-03-23T14:14:38.656422Z Ken Sharp</strong></p>
<blockquote>
<pre>
Fix (fonts) : Coverity warning

Details:
Move a NULL pointer check so that it is performed before dereferencing the pointer.
Warning flagged by Coverity.

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

<p><strong><a name="2009-03-23T134849.969966Z"></a>
2009-03-23T13:48:49.969966Z Ken Sharp</strong></p>
<blockquote>
<pre>
Fix (pdfwrite) : Skip OpenType tables EBDT, EBLC, EBSC.

DETAILS :

Patch and log message submitted by Leonardo.

This fixes the large size of the PDF output reported in
Bug 689209 &quot;ps2pdf doesn't subset embedded bitmaps&quot;.
The patch skips Open Type tables that are not required by
the PDF specification.

A better fix would be subsetting EBDT, EBLC, EBSC
(probably what the user wants), but we have not enough
examples for testing all possible formats of those tables.
Also it will be necessary to compact the glyph index space
and re-index subglyphs, otherwise the subclassed EBLC
is still too big. In general subsetting TrueType fonts is still
a future goal.
 

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

<p><strong><a name="2009-03-23T094003.808902Z"></a>
2009-03-23T09:40:03.808902Z Ken Sharp</strong></p>
<blockquote>
<pre>
Fix (fonts): Allow copying TT descandants of CIDFonts with no name table.

Details:
bug #690348 &quot;Error &quot;/invalidfont&quot; when generating PDF&quot;

The PDF file for this contains an embedded TrueType font, configured as a CIDFont, and
the TT name table is empty (not missing, but empty). This is probably technically
illegal.

However, we don't actually require the name table, or other font information, when
copying these fonts for pdfwrite, so we simply ignore this error in this case.

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

<p><strong><a name="2009-03-22T044307.001485Z"></a>
2009-03-22T04:43:07.001485Z Alex Cherepanov</strong></p>
<blockquote>
<pre>
Initialize Jbig2TextRegionParams.sbrat even when it is not used in
calculations because it's included in error messages causing Valgrind
warnings.

</pre>
<p>[jbig2dec/jbig2_text.c]</p>
</blockquote>

<p><strong><a name="2009-03-20T082650.704630Z"></a>
2009-03-20T08:26:50.704630Z Ken Sharp</strong></p>
<blockquote>
<pre>
Fix (pswrite) : extra '%' output in DSC comment

Details:
bug #690347 &quot;pswrite device generates %%%%BeginPageSetup&quot;

Revision 9396 moved the emission of the %%PageBoundingBox comment, but due to an
oversight caused the %%BeginPageSetup comment to be emitted with too may '%' characters.

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

<p><strong><a name="2009-03-19T211931.945883Z"></a>
2009-03-19T21:19:31.945883Z Alex Cherepanov</strong></p>
<blockquote>
<pre>
Allocate a file name string returned by .tempfile independently of the
file object. Don't free the file name string when the file is closed.
Fix a Valgrind warning and potential SEGV.

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

<p><strong><a name="2009-03-19T170134.362845Z"></a>
2009-03-19T17:01:34.362845Z Ken Sharp</strong></p>
<blockquote>
<pre>
Fix (fonts): Uninitialised variables in FreeType bridge.

Details:
bug #690344 &quot;FreeType bridge produces lots of 'clipping glyph' warnings&quot;

The FreeType bridge code failed to initialise some member variables of a structure when
retrieving glyph metrics, leading to spurious warnings.

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

<p><strong><a name="2009-03-19T164012.949694Z"></a>
2009-03-19T16:40:12.949694Z Ken Sharp</strong></p>
<blockquote>
<pre>
Fix (fonts): PaintType 2 fonts not working.

Details:
bug #689826 &quot;FT_BRIDGE crashes with CID fonts&quot;

The initial problem is that a required table, TT_cmap, was NULL, and was not tested
by the CID decoding module before attempting to use it.

Further investigation revealed a fair number of problems surrounding this are. The 
problems stem from the use of a native TrueType font on disk to replace a CIDFont (not 
from an actual CIDFont as the summary suggests). When using a CIDFont the character
code is mapped to a CID using the CMap and the CID is directly used to extract the 
glyph program from the font's CharStrings dictionary.

With a TrueType font that is not sufficient, TrueType fonts use Glyph IDs (GID) and
have a completely different method of mapping the encodings. We attempt to handle this
by converting the CID to a Unicode value, and then use the TT Unicode CMAP subtable to
convert the Unicode value to a GID.

With GS' own font handling this works, because we extract the CMAP subtable and carry
it around in the font. WHen using FreeType this is not done, and so the conversion
fails.

Modified the FAPI interface to create a new method 'check_cmap_for_glyph' which will
allow us to interrogate the TT CMAP subtable from the FAPI server. Copied sections of
CID decoding from zcid.c to zfapi.c in order to perform the same checks as our own 
code and use the correct Unicode value.

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

<p><strong><a name="2009-03-19T161019.044766Z"></a>
2009-03-19T16:10:19.044766Z Ken Sharp</strong></p>
<blockquote>
<pre>
Fix (fonts): PaintType 2 fonts not working.

Details:
bug #690343 &quot;Fonts with PaintType 2 (outline) not working with FreeType bridge&quot;

The FAPI code seems to assume that it will always get an 'e_limitcheck' error when no
raster is available. This seems to be true for glyphs too large to cache, but is not
the case when the font is intended to be an outline. In this case there is no raster, 
but the error return is not e_limitcheck.

Rather than rely on an error value, modified the code so that if the font has a 
non-zero PainType, we assume that we only have an outline.

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

<p><strong><a name="2009-03-19T155950.732428Z"></a>
2009-03-19T15:59:50.732428Z Ken Sharp</strong></p>
<blockquote>
<pre>
Fix (fonts): Crash caused by missing tests.

Details:
bug #690342 &quot;GPF/segment violation using FreeType bridge&quot;

When using a TrueType font to substitute for a CIDFont, there is no BuildCHar, and so
trying to resolve the name will fail, resulting in a GPF. Fixed by testing the name
objects before attempting to resolve them.

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

<p><strong><a name="2009-03-19T014802.632278Z"></a>
2009-03-19T01:48:02.632278Z Henry Stiles</strong></p>
<blockquote>
<pre>
Fix 689822, the previous code did not free the palette associated with
an indexed color space to remain backward compatible wih pcl and
pclxl.  The previous setup, before 8928, allowed the clients to manage
the table for memory.  The commented out code in this module was a
workaround until we fixed the pcl clients.
</pre>
<p>[base/gscolor2.c]</p>
</blockquote>

<p><strong><a name="2009-03-18T225818.105967Z"></a>
2009-03-18T22:58:18.105967Z Ralph Giles</strong></p>
<blockquote>
<pre>
Backslash-escape nested parentheses in ps strings.

This isn't necessary with the gs scanner, but is considered good practice.
Thanks to Ray Johnston for raising the issue.</pre>
<p>[Resource/Init/pdf_draw.ps]</p>
</blockquote>

<p><strong><a name="2009-03-18T215818.821466Z"></a>
2009-03-18T21:58:18.821466Z Ralph Giles</strong></p>
<blockquote>
<pre>
Correct diction in unbalanced q/Q warnings.</pre>
<p>[Resource/Init/pdf_ops.ps Resource/Init/pdf_main.ps Resource/Init/pdf_draw.ps]</p>
</blockquote>

<p><strong><a name="2009-03-15T224253.413236Z"></a>
2009-03-15T22:42:53.413236Z Alex Cherepanov</strong></p>
<blockquote>
<pre>
Add hagaki (Japanese postcard) paper size to the list of known paper sizes
because this format is widely used in Japan and popular PAPERSIZE option
takes a paper name. Bug 690213.

</pre>
<p>[doc/Use.htm Resource/Init/gs_statd.ps]</p>
</blockquote>

<p><strong><a name="2009-03-14T054400.168304Z"></a>
2009-03-14T05:44:00.168304Z Ray Johnston</strong></p>
<blockquote>
<pre>
Fix chunk_resize_object to retain the old data and add gs_debug['A'] debug
printing.
</pre>
<p>[base/gsmchunk.c]</p>
</blockquote>

<p><strong><a name="2009-03-13T001917.919125Z"></a>
2009-03-13T00:19:17.919125Z Ralph Giles</strong></p>
<blockquote>
<pre>
Correct some comment typos in the icclib wrapper.

Also removes trailing whitespace.
</pre>
<p>[base/gsicc.c]</p>
</blockquote>

<p><strong><a name="2009-03-12T194329.615649Z"></a>
2009-03-12T19:43:29.615649Z Ray Johnston</strong></p>
<blockquote>
<pre>
Fix Segfault in the 'resize_object' of the chunk memory wrapper.

DETAILS:

A typical (unfortunately) instance of using (part of) an object after
it has been freed.
</pre>
<p>[base/gsmchunk.c]</p>
</blockquote>

<p><strong><a name="2009-03-12T133223.551227Z"></a>
2009-03-12T13:32:23.551227Z Alex Cherepanov</strong></p>
<blockquote>
<pre>
Remove code that has no effect other than moving uninitialized data around
and causing Coverity warning.

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

<p><strong><a name="2009-03-12T001803.727459Z"></a>
2009-03-12T00:18:03.727459Z Marcos H. Woehrmann</strong></p>
<blockquote>
<pre>
Fixed typo introduced in r9545.
</pre>
<p>[base/gdevp14.c]</p>
</blockquote>

<p><strong><a name="2009-03-11T220055.007444Z"></a>
2009-03-11T22:00:55.007444Z Ray Johnston</strong></p>
<blockquote>
<pre>
Set the log_op (ROP) to a straightforward value when doing the pdf14 put_image
ignoring the input imager state log_op. Bug 690321.

DETAILS:

The rev 8170 alludes to doing something to prevent a similar problem (bug
689186: see DETAILS comment #2 in the log message), but this was NOT the
correct solution. When writing the transparency buffer to the target device
in the pdf14 POP_DEVICE using the &quot;put_image&quot; proc, we really need to use
a ROP that simply allows us to copy the image in 'normal' mode i.e. use
rop3_default.

The state of the low bits of the clist_playback_band imager_state.log_op is
rather arbitrary at the end of the band and not relevant to the put_image
operation.
</pre>
<p>[base/gdevp14.c]</p>
</blockquote>

<p><strong><a name="2009-03-11T134633.591266Z"></a>
2009-03-11T13:46:33.591266Z Alex Cherepanov</strong></p>
<blockquote>
<pre>
Move a variable declaration to the outer block to prevent out-of-scope access
and a corresponding Coverity warning.

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

<p><strong><a name="2009-03-11T125121.059563Z"></a>
2009-03-11T12:51:21.059563Z Alex Cherepanov</strong></p>
<blockquote>
<pre>
Propagate error code from gs_path_enum_next() upstream in operator
.getpath . Fix a Coverity warning.

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

<p><strong><a name="2009-03-10T000703.756709Z"></a>
2009-03-10T00:07:03.756709Z Ralph Giles</strong></p>
<blockquote>
<pre>
Add the soclean and debugclean targets to distclean. Bug 690263.
</pre>
<p>[base/Makefile.in]</p>
</blockquote>

<p><strong><a name="2009-03-07T225915.942227Z"></a>
2009-03-07T22:59:15.942227Z Alex Cherepanov</strong></p>
<blockquote>
<pre>
Increase operand stack to 100000 elements and change stack overflow handling.

DETAILS:
Following Adobe implementation, copy only a few top elements of the stack
to the corresponding element of the $error dictionary when the stack
overflows. Adobe copies up to 500 top elements, we copy up to 65535. This
feature enables Ghostscript to have maximum stack sizes larger than 65535.
The maximum operand stack size is set to 100000 to match Adobe interpreters.
The large stack size is needed for some PDF files that construct large
dictionaries using &lt;&lt; ... &gt;&gt; operators. Bug 690307, customer 850.

</pre>
<p>[Resource/Init/gs_init.ps psi/interp.c]</p>
</blockquote>

<p><strong><a name="2009-03-07T214616.367445Z"></a>
2009-03-07T21:46:16.367445Z Till Kamppeter</strong></p>
<blockquote>
<pre>
Let pdftoraster CUPS filter not be build with CUPS &lt; 1.2 and allow suppressing build of pdftoraster via command line option (needed for Mac OS X).
</pre>
<p>[cups/cups.mak base/Makefile.in base/configure.ac]</p>
</blockquote>

<p><strong><a name="2009-03-05T095607.987614Z"></a>
2009-03-05T09:56:07.987614Z Ralph Giles</strong></p>
<blockquote>
<pre>
Look for the 'cmap' table in the font dictionary and use it when mapping
a cid to a character code when using the FAPI bridge.

This replaces a segfault with an invalid font error. Bug 689826.

Details:

This clause in FAPI_do_char() was explicitly calling
cid_to_TT_charcode() with a NULL TT_cmap argument, which that function
dereferenced, causing a segfault. As far as Ken and I can tell, that
function can't do anything useful without the cmap table from the
underlying font, so it makes the most sense the resolve the segfault
this way.

However, the ps library code doesn't set this key in the font
dictionary, so for now this just replaces the segfault with an
/invalidfont in --.FAPIBuildGlyph-- error. We could continue
silently by ignoring the mapping if the cmap isn't available down
in TT_char_code_from_CID_no_subst() in which case that font just
would not render as part of the document. We expect to fix this on
the postscript side, so I felt this was a better course for now.</pre>
<p>[psi/zfapi.c]</p>
</blockquote>

<p><strong><a name="2009-03-04T132707.376818Z"></a>
2009-03-04T13:27:07.376818Z Ken Sharp</strong></p>
<blockquote>
<pre>
Fix the FreeType bridge code for outlines (result of charpath). 

The previous code assumed that co-ordinates returned by FT were in a 16.16 fixed
precision format, whereas they are actually in a 26.6 form. Rescale the 26.6 to 16.16
before returning to FAPI so that the conversion into GS co-ordinates works correctly.

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

<p><strong><a name="2009-03-03T162324.892806Z"></a>
2009-03-03T16:23:24.892806Z Ken Sharp</strong></p>
<blockquote>
<pre>
Fix (colour): Faulty error handling

Details:
bug #690312 &quot;gs stalls, never returns on attached figure&quot;

The job causes the 'base' (Gray, RGB, CMYK) colour code to be executed with a completely
full stack, which causes a stackoverflow because this routine needs to push the colour
space name onto the operand stack.

However, the operand stack wasn't being checked until after the continuation procedure 
had been pushed onto the execution stack, so after the error handling, we returned to
the continuation procedure, but without an appropriate operand stack. This caused a
loop to run without bounds.

Fixed by checking the operand stack beforesetting up the execution stack for the
continuation and aborting if it is full. Desk checking revealed another potential case
of the same problem, fixed in the same patch.

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

<p><strong><a name="2009-03-02T195401.945423Z"></a>
2009-03-02T19:54:01.945423Z Ray Johnston</strong></p>
<blockquote>
<pre>
Add mention of 'vewrgb.ps'. See the source for usage.
</pre>
<p>[doc/Psfiles.htm]</p>
</blockquote>

<p><strong><a name="2009-03-02T194728.992085Z"></a>
2009-03-02T19:47:28.992085Z Ralph Giles</strong></p>
<blockquote>
<pre>
Update copyright header and file metadata for viewrgb.ps.
</pre>
<p>[lib/viewrgb.ps]</p>
</blockquote>

<p><strong><a name="2009-03-02T184532.781041Z"></a>
2009-03-02T18:45:32.781041Z Ray Johnston</strong></p>
<blockquote>
<pre>
Add support for BITS=2, remove left over debugging messages. Note that
this has only been tested for BITS=1, BITS=2, BITS=8. BITS=4 is not
supported (Indexed color space is limited to palette of 4096 colors).
</pre>
<p>[lib/viewrgb.ps]</p>
</blockquote>

<p><strong><a name="2009-03-02T174422.371407Z"></a>
2009-03-02T17:44:22.371407Z Ray Johnston</strong></p>
<blockquote>
<pre>
Add a utility to view bitrgb files (derived from viewcmyk.ps)
</pre>
<p>[lib/viewrgb.ps]</p>
</blockquote>

<p><strong><a name="2009-03-02T061302.641888Z"></a>
2009-03-02T06:13:02.641888Z Alex Cherepanov</strong></p>
<blockquote>
<pre>
When /JBIG2Decode filter takes /.jbig2globalctx parameter and retains a
pointer to it, the filter must not be allocated in global memory if the
parameter is local. Bug 690308.

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

<p><strong><a name="2009-02-28T000341.220730Z"></a>
2009-02-28T00:03:41.220730Z Ralph Giles</strong></p>
<blockquote>
<pre>
Remove a continued line in a makefile variable.

Solaris 'make' doesn't like this. Bug 690311.</pre>
<p>[psi/psromfs.mak]</p>
</blockquote>

<p><strong><a name="2009-02-26T040756.132242Z"></a>
2009-02-26T04:07:56.132242Z Ray Johnston</strong></p>
<blockquote>
<pre>
Fix for access to potentially uninitialized memory in gx_hld_get_gstate_ptr
when called with an imager_state that is on the stack (as it is when this
is called from the clist). Valgrind spotted this. See coment #5 in Bug
690299.

DETAILS:

The previous method of checking the object type depended on access BEFORE
the pointer. This was (margnially) OK for allocated objects, but NOT OK
when the structure is stack based.
</pre>
<p>[base/gsstate.c base/gxclist.c base/gxistate.h base/gdevvec.c base/gxhldevc.c]</p>
</blockquote>

<p><strong><a name="2009-02-26T035158.114906Z"></a>
2009-02-26T03:51:58.114906Z Ray Johnston</strong></p>
<blockquote>
<pre>
Add some documentation on a useful debugging PS operator and it's C code hook.
</pre>
<p>[doc/Language.htm]</p>
</blockquote>

<p><strong><a name="2009-02-23T191744.665816Z"></a>
2009-02-23T19:17:44.665816Z Marcos H. Woehrmann</strong></p>
<blockquote>
<pre>

Change the maxval value for pkm and pkmraw files from 1 to 255.

Details:

Some programs (notably Adobe Photoshop through at least CS4) do not
correctly read PPM files that have a maxval!=255, displaying them
as all black (technically not entirely black, but with pixels set
to 0 or 1).  

This change causes Ghostscript to set maxval to 255 and scale the
output bitmap to 0..255.  Because PBM doesn't pack pixels in the
PPM raw format the output file size will not change; PPM files will
up to double in size (previously each pixel used 6 bytes, &quot;1 1 1 &quot;,
now each pixel uses up to 12 bytes, &quot;255 255 255 &quot;).

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

<p><strong><a name="2009-02-23T113526.753646Z"></a>
2009-02-23T11:35:26.753646Z Ken Sharp</strong></p>
<blockquote>
<pre>
Fix (ps2write)

Details
The Debug flag for the new 'center pages' switch was incorrectly spelled as PDFR_DEBUG1 instead of PDFR_DEBUG.

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

<p><strong><a name="2009-02-21T205934.903436Z"></a>
2009-02-21T20:59:34.903436Z Ralph Giles</strong></p>
<blockquote>
<pre>
Update the msvc build of the freetype bridge for the new link scheme.

This commmit fixes some errors in the earlier untested update. In addition, the earlier FT_LIB (singular) makefile variable is resurrected for the msvc build only. It is necessary because the freetype project file embeds the release number of build variant in the library filename. If FT_LIB is not set it defaults to the multi-threaded debug build of the 2.3.8 release. Obviously this should be changed when building a binary for release, or against a different version of the freetype library.</pre>
<p>[base/winlib.mak doc/Make.htm]</p>
</blockquote>

<p><strong><a name="2009-02-20T231714.675067Z"></a>
2009-02-20T23:17:14.675067Z Ralph Giles</strong></p>
<blockquote>
<pre>
Replace the hardcoded reference to the FreeType library subpaths with a
more direct specification of compile and link flags.

The msvc build is untested.

Details:

Previously, the top level makefile was supposed to define a path to the
freetype source directory, along with the platform-specific library
filename extension. From this the ft bridge makefile section generated
specific references for include paths and the library. This only worked
with a specific version of the library.

This commit removes the variable for passing the library extension,
and relies on the top-level makefile to provide the link commands,
passed in the FT_LIBS variable. Such link commands are generally
platform-specific anyway, so FT_LIB_EXT was redundant. Likewise,
the include path specifiers must be part of the FT_CFLAGS variable.

Previously, FT_LIBS was called FT_LIB. We generally use _LIB for a
single library name. Having the plural LIBS is more common for an
actual link command, which may include flags and other libraries
which are dependencies. This variable is used in the second way.

The build documentation is also updated to reflect the new scheme,
and mention the incremental font support, which seems to be disabled
in most builds.
</pre>
<p>[base/winlib.mak doc/Make.htm psi/int.mak]</p>
</blockquote>

<p><strong><a name="2009-02-20T231710.859552Z"></a>
2009-02-20T23:17:10.859552Z Ralph Giles</strong></p>
<blockquote>
<pre>
Add some missing dependencies to the interpreter makefile.

Strangely, these don't help ensure arch.h is built before write_t2.c.
</pre>
<p>[psi/int.mak]</p>
</blockquote>

<p><strong><a name="2009-02-20T231708.595733Z"></a>
2009-02-20T23:17:08.595733Z Ralph Giles</strong></p>
<blockquote>
<pre>
Replace 'Free Type' with 'FreeType' in the build documentation.
</pre>
<p>[doc/Make.htm]</p>
</blockquote>

<p><strong><a name="2009-02-20T231705.547619Z"></a>
2009-02-20T23:17:05.547619Z Ralph Giles</strong></p>
<blockquote>
<pre>
Update freetype includes to the currently recommended scheme.

Details:

In freetype2, the recommended method of including the headers is to
include &lt;ft2build.h&gt;, depending on a -I line on the compiler's command
line to select the particular location for this, usually something like
$(INCLUDE_DIR)/freetype/

This header defines macros which expand to includes for particular
features, depending on how the particular freetype instance being
built is configured.

This means that we can't have explicit dependencies on the headers we
use, so those references are also removed. This has a side effect of
making it much easier to link with a system version of freetype.

However, the fapi_ft bridge requires freetype's incremental fonts
feature, which seems not to be enabled by default.
</pre>
<p>[psi/fapi_ft.c psi/int.mak]</p>
</blockquote>

<p><strong><a name="2009-02-20T191004.104225Z"></a>
2009-02-20T19:10:04.104225Z Alex Cherepanov</strong></p>
<blockquote>
<pre>
Check that gs_init.ps can be found at $(GenericResourceDir)Init/gs_init.ps
Issue a warning if this file cannot be found. Bug 690289.

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

<p><strong><a name="2009-02-19T185321.845051Z"></a>
2009-02-19T18:53:21.845051Z Ralph Giles</strong></p>
<blockquote>
<pre>
Update our internal copy of the libpng source to the 1.2.35 release.
</pre>
<p>[libpng]</p>
</blockquote>

<p><strong><a name="2009-02-19T185224.164375Z"></a>
2009-02-19T18:52:24.164375Z Ralph Giles</strong></p>
<blockquote>
<pre>
Move the libpng source out of the way for an upgrade.
</pre>
<p>[libpng]</p>
</blockquote>

<p><strong><a name="2009-02-19T171336.155519Z"></a>
2009-02-19T17:13:36.155519Z Ray Johnston</strong></p>
<blockquote>
<pre>
Fix for segfault reported as bug 690051 caused by the assumption that the architecture
had 32-bit integers. Thanks to Wendy for the patch.
</pre>
<p>[base/gdevsgi.h base/gdevsgi.c]</p>
</blockquote>

<p><strong><a name="2009-02-17T204038.935981Z"></a>
2009-02-17T20:40:38.935981Z Alex Cherepanov</strong></p>
<blockquote>
<pre>
Remove obsolete information from Use.htm. Ghostscript now accepts PDF from
standard input and, since rev. 610 flushpage occurs even with -dNOPROMPT .

</pre>
<p>[doc/Use.htm]</p>
</blockquote>

<p><strong><a name="2009-02-16T200017.223054Z"></a>
2009-02-16T20:00:17.223054Z Ralph Giles</strong></p>
<blockquote>
<pre>
Set native eol-style on the jasper library source. Bug 690292.
</pre>
<p>[jasper/src/libjasper/include/jasper/jas_types.h jasper/src/libjasper/jpc/jpc_cs.c jasper/src/libjasper/mif/mif_cod.h jasper/src/libjasper/pgx/pgx_enc.c jasper/src/libjasper/bmp/bmp_cod.c jasper/src/libjasper/jpc/jpc_cs.h jasper/src/libjasper/ras/ras_dec.c jasper/src/libjasper/pgx/pgx_enc.h jasper/src/libjasper/bmp/bmp_cod.h jasper/src/libjasper/base/jas_version.c jasper/src/libjasper/jpc/jpc_qmfb.c jasper/src/libjasper/ras/ras_cod.c jasper/src/libjasper/base/jas_iccdata.c jasper/src/libjasper/base/jas_seq.c jasper/src/libjasper/jpg/jpg_val.c jasper/src/libjasper/jpc/jpc_qmfb.h jasper/src/libjasper/jpc/jpc_fix.h jasper/src/libjasper/jpc/jpc_tagtree.c jasper/src/libjasper/ras/ras_cod.h jasper/src/libjasper/pgx/pgx_dec.c jasper/src/libjasper/jpc/jpc_tagtree.h jasper/src/libjasper/base/jas_getopt.c jasper/src/libjasper/jpc/jpc_mqenc.c jasper/src/libjasper/include/jasper/jas_getopt.h jasper/src/libjasper/jpg/jpg_dummy.c jasper/src/libjasper/jpc/jpc_bs.c jasper/src/libjasper/include/jasper/jas_init.h jasper/src/libjasper/jpc/jpc_enc.c jasper/src/libjasper/base/jas_string.c jasper/src/libjasper/base/jas_malloc.c jasper/src/libjasper/include/jasper/jas_string.h jasper/src/libjasper/include/jasper/jas_malloc.h jasper/src/libjasper/jpc/jpc_mqenc.h jasper/src/libjasper/pgx/pgx_cod.c jasper/src/libjasper/jpc/jpc_bs.h jasper/src/libjasper/jpc/jpc_t1enc.c jasper/src/libjasper/jpc/jpc_enc.h jasper/src/libjasper/jpg/jpg_enc.c jasper/src/libjasper/pgx/pgx_cod.h jasper/src/libjasper/jpc/jpc_t1enc.h jasper/src/libjasper/jpg/jpg_enc.h jasper/src/libjasper/include/jasper/jas_version.h jasper/src/libjasper/include/jasper/jas_seq.h jasper/src/libjasper/jpc/jpc_mqdec.c jasper/src/libjasper/include/jasper/jas_math.h jasper/src/libjasper/base/jas_stream.c jasper/src/libjasper/jpc/jpc_flt.h jasper/src/libjasper/jpc/jpc_dec.c jasper/src/libjasper/include/jasper/jas_stream.h jasper/src/libjasper/base/jas_icc.c jasper/src/libjasper/jpc/jpc_mqdec.h jasper/src/libjasper/jpc/jpc_t1dec.c jasper/src/libjasper/jpc/jpc_dec.h jasper/src/libjasper/pnm/pnm_enc.c jasper/src/libjasper/jpg/jpg_dec.c jasper/src/libjasper/jp2/jp2_enc.c jasper/src/libjasper/jpc/jpc_mqcod.c jasper/src/libjasper/jpc/jpc_t1dec.h jasper/src/libjasper/pnm/pnm_enc.h jasper/src/libjasper/base/jas_tvp.c jasper/src/libjasper/jpc/jpc_mqcod.h jasper/src/libjasper/jpc/jpc_t1cod.c jasper/src/libjasper/jpc/jpc_cod.h jasper/src/libjasper/jpc/jpc_t2enc.c jasper/src/libjasper/jpc/jpc_util.c jasper/src/libjasper/jpc/jpc_t1cod.h jasper/src/libjasper/jpc/jpc_t2enc.h jasper/src/libjasper/jpc/jpc_util.h jasper/src/libjasper/jpg/jpg_cod.h jasper/src/libjasper/jpc/jpc_mct.c jasper/src/libjasper/include/jasper/jas_image.h jasper/src/libjasper/include/jasper/jas_debug.h jasper/src/libjasper/pnm/pnm_dec.c jasper/src/libjasper/jpc/jpc_mct.h jasper/src/libjasper/include/jasper/jas_config_win32.h jasper/src/libjasper/jpc/jpc_math.c jasper/src/libjasper/jp2/jp2_dec.c jasper/src/libjasper/jpg/jpg_jpeglib.h jasper/src/libjasper/jpc/jpc_math.h jasper/src/libjasper/jp2/jp2_dec.h jasper/src/libjasper/base/jas_cm.c jasper/src/libjasper/include/jasper/jas_icc.h jasper/src/libjasper/include/jasper/jas_cm.h jasper/src/libjasper/jpc/jpc_t2dec.c jasper/src/libjasper/pnm/pnm_cod.c jasper/src/libjasper/base/jas_init.c jasper/src/libjasper/jp2/jp2_cod.c jasper/src/libjasper/include/jasper/jas_config.h jasper/src/libjasper/jpc/jpc_t2dec.h jasper/src/libjasper/pnm/pnm_cod.h jasper/src/libjasper/jp2/jp2_cod.h jasper/src/libjasper/bmp/bmp_enc.c jasper/src/libjasper/include/jasper/jas_tvp.h jasper/src/libjasper/jpc/jpc_t2cod.c jasper/src/libjasper/bmp/bmp_enc.h jasper/src/libjasper/jpc/jpc_t2cod.h jasper/src/libjasper/base/jas_image.c jasper/src/libjasper/base/jas_debug.c jasper/src/libjasper/include/jasper/jas_fix.h jasper/src/libjasper/ras/ras_enc.c jasper/src/libjasper/include/jasper/jasper.h jasper/src/libjasper/ras/ras_enc.h jasper/src/libjasper/jpc/jpc_tsfb.c jasper/src/libjasper/bmp/bmp_dec.c jasper/src/libjasper/jpc/jpc_tsfb.h jasper/src/libjasper/mif/mif_cod.c]</p>
</blockquote>

<p><strong><a name="2009-02-16T195809.175955Z"></a>
2009-02-16T19:58:09.175955Z Ralph Giles</strong></p>
<blockquote>
<pre>
Convert a jasper source file to unix line endings. Bug 690292.
</pre>
<p>[jasper/src/libjasper/jpc/jpc_qmfb.c]</p>
</blockquote>

<p><strong><a name="2009-02-14T004658.521562Z"></a>
2009-02-14T00:46:58.521562Z Ralph Giles</strong></p>
<blockquote>
<pre>
Don't strip dynamic driver modules when linking them.

This is better done at the install or packaging stages if space is a 
concern.

Also, propagate LDFLAGS to the link command line. This may or may not be 
what you want, but is more likely to help helpful than not.

After a patch by Kevin Pyle. Bug 690288. Originally Gentoo bug 215913.
</pre>
<p>[base/devs.mak]</p>
</blockquote>

<p><strong><a name="2009-02-13T092234.492616Z"></a>
2009-02-13T09:22:34.492616Z Ken Sharp</strong></p>
<blockquote>
<pre>
Fix (TrueType interpreter): Ignore a 'faulty font' condition

Details:
bug #689760 &quot;Missing characters: Failed to interpret TT instructions&quot;

The font in question is technically invalid. The problem occurs in function 1 of the
FPGM table:

	00069: PUSHB[2]              0    21 
	00072: JMPR       
	00073: ABS        
	00074: DUP        
	00075: ROLL       
	00076: RCVT       
	00077: DUP        
	00078: ROLL       
	00079: SUB        
	00080: ABS        
	00081: PUSHB[1]             50 
	00083: LT         
	00084: IF         
	00085: SWAP       
	00086: EIF        
	00087: POP        
	00088: ROUND[Black] 
	00089: PUSHB[1]             64 
	00091: MAX        
	00092: ENDF       

The JMPR (jump relative) instruction is intended to resume execution at the ENDF
instruction, but the number of bytes is miscounted, falling of the end of the function.
I suspect some TT interpreters catch this by spotting the fact that the IP is past the
end of the function.

We don't seem to be able to check if we've fallen off a function, because we don't store
function lengths, so this code works around the problem by checking the opcode after we
apply the JMPR but befopre resuming execution. If the opcode is *not* ENDF, but the 
preceding opcode was, assume that we have a counting problem, and move the IP back one
instruction.

Also applied the same work around to JROT and JROF instructions.

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

<p><strong><a name="2009-02-12T210753.759360Z"></a>
2009-02-12T21:07:53.759360Z Alex Cherepanov</strong></p>
<blockquote>
<pre>
Limit the length of a buffer string for CCITTFaxEncode compression in
Type 32 font to 65535. Old code used worst case estimation (5x expansion)
that exceeded maximum string size for large glyphs. Bug 690286.

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

<p><strong><a name="2009-02-11T203513.542448Z"></a>
2009-02-11T20:35:13.542448Z Henry Stiles</strong></p>
<blockquote>
<pre>
Revert the last change which was completely wrong.  The system does
not support depth 3 as Ray pointed out.  As it turns out the depth is
corrected so there is no difference in output between the two
configurations.
</pre>
<p>[base/gdevbit.c]</p>
</blockquote>

<p><strong><a name="2009-02-11T193742.026795Z"></a>
2009-02-11T19:37:42.026795Z Henry Stiles</strong></p>
<blockquote>
<pre>
The default bitrgb device prototype specified a depth of 4 instead of
3.  This change will break all regression tests that use bitrgb
(hopefully).
</pre>
<p>[base/gdevbit.c]</p>
</blockquote>

<p><strong><a name="2009-02-11T154125.950909Z"></a>
2009-02-11T15:41:25.950909Z Ken Sharp</strong></p>
<blockquote>
<pre>
Fix (TrueType interpreter): Ignore a 'faulty font' error

Details:
bug #689471 &quot;Error in Processing Type42 Charstrings&quot;

The font in question is missing a glyph in the GLYF table, which is used 
as a component by a composite glyph. A later instruction then tries to access 
a non-existent point (probably defined in the missing component), which causes
an error.

FreeType 1 and 2 both ignore this error unless pedantic_hinting is set, other
TrueType interpreters behave similarly.

Modified the code in Ins_MIAP to ignore errors of this type, and continue.

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

<p><strong><a name="2009-02-10T195540.527955Z"></a>
2009-02-10T19:55:40.527955Z Ralph Giles</strong></p>
<blockquote>
<pre>
Move some components of the freetype bridge to the interpreter source 
directory.

These should have been put there in the source tree reorganization.
</pre>
<p>[base/write_t1.c base/wrfont.c base/write_t2.c psi/write_t1.c psi/wrfont.c psi/write_t2.c base/write_t1.h base/wrfont.h base/write_t2.h psi/write_t1.h psi/wrfont.h psi/write_t2.h]</p>
</blockquote>

<p><strong><a name="2009-02-10T173802.642910Z"></a>
2009-02-10T17:38:02.642910Z Marcos H. Woehrmann</strong></p>
<blockquote>
<pre>
Make the font cache determinstic.

Details:

Previously the font cache order was based on the value of the pair
pointer.  On some (most?) computers this resulted in the cache being
filled in a deterministic way but not on the the cluster used for
regression testing.  The cache fill order is important because it
affects which entries are removed when the cache is full which
matters because re-rendered glyphs can differ from the cached
rendering (a separate bug, 690281, has been opened for this issue).

Fixes bugs 690232 and 690233.

</pre>
<p>[base/gxfcache.h base/gsfont.c base/gxccman.c]</p>
</blockquote>

<p><strong><a name="2009-02-10T115630.899368Z"></a>
2009-02-10T11:56:30.899368Z Ken Sharp</strong></p>
<blockquote>
<pre>
Fix (graphics library): Rotated/skewed text not anti-aliased

Details:
bug #688032 &quot;Rotated text is not antialiased.&quot;

A specific test in 'show_set_scale' disabled oversampling of text if it was
rotated or skewed. Testing indicates that anti-aliasing does provide some improvement 
in text, even when it is rotated or skewed, so this test has been removed.

Also removed the compile-time option to not cache rotated glyphs by removing the
#define CACHE_ROTATED_CHARS and the test against it in show_state_setup. This allowed
the removal of the routine 'is_matrix_good_for_caching'.

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

<p><strong><a name="2009-02-10T021730.702347Z"></a>
2009-02-10T02:17:30.702347Z Ralph Giles</strong></p>
<blockquote>
<pre>
Propagate LDFLAGS when linking the pdftoraster utility. Bug 690279.

Also, move the cups link libraries to the end of the command line
for tools that require dependency order.
</pre>
<p>[cups/cups.mak]</p>
</blockquote>

<p><strong><a name="2009-02-09T221820.864249Z"></a>
2009-02-09T22:18:20.864249Z Ralph Giles</strong></p>
<blockquote>
<pre>
Protect some printf-like calls in the pcl3 output device from spurious
format specifiers. This eliminates a security-related gcc warning.

Details:

I believe the previous code was actually safe. However, this approach is
more robust. If any of the string buffers passed to errprintf() happened
to contain a format specifier (like %d) an out of bounds stack reference
could result.

This allows the default build to complete with -Werror=format-security,
which the Mandriva linux distribution is reported to be using.
</pre>
<p>[contrib/pcl3/eprn/gdeveprn.c contrib/pcl3/src/gdevpcl3.c]</p>
</blockquote>

<p><strong><a name="2009-02-09T221818.594295Z"></a>
2009-02-09T22:18:18.594295Z Ralph Giles</strong></p>
<blockquote>
<pre>
Have gs_throw_code() print the corresponding error string literally to
avoid interpretation of spurious format specifiers. This removes a
security-related gcc warning.

Details:

The previous code was safe. gs_(re)throw_code() called gs_errstr() to
convert the code to a printable string, and these contain no format
specifiers. However, the new method is more robust, and allows
compilation with -Werror=format-security which Madriva is reportedly
using by default.
</pre>
<p>[base/gserror.h]</p>
</blockquote>

<p><strong><a name="2009-02-09T003235.099915Z"></a>
2009-02-09T00:32:35.099915Z Alex Cherepanov</strong></p>
<blockquote>
<pre>
Add a reference to doc/Use.htm#CIDFontSubstitution to the message about
CIDFont substitution based on registery and ordering data. Bug 690102.

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

<p><strong><a name="2009-02-08T060554.380114Z"></a>
2009-02-08T06:05:54.380114Z Alex Cherepanov</strong></p>
<blockquote>
<pre>
Correct handling of the operand stack overflow requires one more element than
the normal case. The maximum operand stack size has been reduced by 1 element
relatively to the size set by rev. 6889 for the bug 688764. Bug 690209.

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

<p><strong><a name="2009-02-06T191754.834304Z"></a>
2009-02-06T19:17:54.834304Z Ray Johnston</strong></p>
<blockquote>
<pre>
Fix for 0 length files from the bit*** devices when -dLastLine was not set.
The LastLine now defaults to the last line of the page (height-1). Bug 690217.
Thanks to Piotr Strzelczyk for spotting this.

DETAILS:

Note that this prevents output of a single line at the top (line 0), but this
was mostly just for testing to emulate custom devices that only call 'get_bits'
on less than all of the lines which had the potential to confuse the thread
lookahead prediction logic in the multi-threaded rendering case.
</pre>
<p>[base/gdevbit.c]</p>
</blockquote>

<p><strong><a name="2009-02-05T132910.275517Z"></a>
2009-02-05T13:29:10.275517Z Ken Sharp</strong></p>
<blockquote>
<pre>
New feature (pswrite): Center pages on output, new switch -dCenterPages

Details:
bug #690100 &quot;Enhancement request: create centered output when reading PDF&quot;

Added a new switch to the collection of media handling controls supported by ps2write. The new CenterPages switch will center the output image on the media, regardless of the size of the media (if the output is larger than the media it will be truncated, but the image will still be centered on the media).

This switch is compatible with the RotatePages control, but not with SetPageSize or FitPages. Like the other switches it can be set as an argument to ps2write when creating a PostScript file (which fixes the result) or it can be supplied to the consuming interpreter in some fashion.

Updated ps2ps2.htm with the new details.

</pre>
<p>[doc/Ps2ps2.htm base/gdevpdfx.h base/gdevpdfp.c Resource/Init/opdfread.ps base/gdevpdfu.c]</p>
</blockquote>

<p><strong><a name="2009-02-04T084521.899308Z"></a>
2009-02-04T08:45:21.899308Z Ken Sharp</strong></p>
<blockquote>
<pre>
Fix (pdfwrite): Limit on CIDFont size too low

Details:
bug #688736 &quot;ps2pdf does not work on these files&quot;

The 'remaining' issue in these files is the 'error -15' problem. This is caused when writing out a subset CIDFont, and the subset grows to be a large font in its own right.

The way that CFF fonts are written, there is interaction between certain parts. The offset of various tables depends on the size of the Top Dict, but the Top Dict contains the offsets of the CharStrings and the CharSet, so its size is partially dependent on those offsets....

The code in psf_write_cid0_font() initially assigns large values (0x7fffff) to the offsets, then iterates over the data quickly converging on a suitable size of offset, which allows calculation of the Top Dict. 

The problem was that 0x7fffff was too small for the offset of the Font Dict, (which comes after the CharStrings) if the CharStrings table was very large (~8MB). While this is probably adequate in 'real life', because its unlikely a real job would contain so many different glyphs, it is simple to solve by increasing the original 'guess' from 0x7fffff to 0x1ffffff (~32MB), which should be enough for any font.

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

<p><strong><a name="2009-02-04T084440.067265Z"></a>
2009-02-04T08:44:40.067265Z Ken Sharp</strong></p>
<blockquote>
<pre>
Fix (pswrite): Incorrect A3 page size

Details:
bug #690259 &quot;A3 pagesize pointsize definition wrong in gdevpsu.c&quot;

The definition of the A3 paper size was 842 by 1190 in psw_write_page_header(). The definitions elsewhere in GS have a height of 1191 (which is closer to the ISO metric paper size).

Modified the page height to be 1191, also modified the media matching code so that it allows +/- 5 points when matching media.

Thanks to Roland Friedwagner for debugging the problem and supplying a patch, and to Alex Cherepanov for suggesting the media matching.

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

<p><strong><a name="2009-02-04T033935.058845Z"></a>
2009-02-04T03:39:35.058845Z Alex Cherepanov</strong></p>
<blockquote>
<pre>
Keep reading the data sources until all of them reach EOF instead of bailing
out when the first one reaches EOF. Different data sources can use different
compression techniques and buffer sizes. The mask in masked images also has
different length than other streams.
Bug 690237, customer 850.

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

<p><strong><a name="2009-02-03T235630.290105Z"></a>
2009-02-03T23:56:30.290105Z Alex Cherepanov</strong></p>
<blockquote>
<pre>
Add one more header type to the list of possible CFF headers.
Bug 690256, customer 210.

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

<p><strong><a name="2009-02-03T192342.937693Z"></a>
2009-02-03T19:23:42.937693Z Ralph Giles</strong></p>
<blockquote>
<pre>
Bump version number and product name after the 8.64 release.
</pre>
<p>[base/gscdef.c base/version.mak Resource/Init/gs_init.ps doc/News.htm]</p>
</blockquote>

<p><strong><a name="2009-02-03T170341.696119Z"></a>
2009-02-03T17:03:41.696119Z Ralph Giles</strong></p>
<blockquote>
<pre>
Update release date and change logs for the 8.64 release.
</pre>
<p>[doc/History7.htm doc/Projects.htm doc/History8.htm man/dvipdf.1 base/gscdef.c man/ps2ascii.1 doc/Use.htm doc/Readme.htm doc/Source.htm doc/Deprecated.htm man/ps2epsi.1 doc/Install.htm doc/API.htm doc/Issues.htm doc/DLL.htm doc/Drivers.htm man/pfbtopfa.1 doc/Release.htm doc/Commprod.htm doc/Xfonts.htm doc/Devices.htm doc/Language.htm man/gs.1 man/pf2afm.1 doc/Fonts.htm doc/Ps2ps2.htm man/printafm.1 doc/Ps2pdf.htm doc/Develop.htm doc/Helpers.htm man/pdf2dsc.1 doc/Psfiles.htm doc/Lib.htm doc/gs-vms.hlp man/font2c.1 man/gsnd.1 base/version.mak man/pdfopt.1 doc/News.htm man/pdf2ps.1 man/ps2pdf.1 doc/Make.htm doc/Details8.htm doc/Unix-lpr.htm doc/C-style.htm doc/Ps-style.htm doc/History1.htm doc/History2.htm man/gslp.1 man/wftopfa.1 doc/History3.htm man/ps2ps.1 doc/Ps2epsi.htm doc/History4.htm man/ps2pdfwr.1 doc/History5.htm doc/History6.htm]</p>
</blockquote>

<p><strong><a name="2009-02-02T191301.319812Z"></a>
2009-02-02T19:13:01.319812Z Ralph Giles</strong></p>
<blockquote>
<pre>
Update change logs and release date for 8.64rc3.
</pre>
<p>[doc/History7.htm doc/Projects.htm doc/History8.htm man/dvipdf.1 man/ps2ascii.1 doc/Use.htm doc/Readme.htm doc/Source.htm doc/Deprecated.htm man/ps2epsi.1 doc/Install.htm doc/Changes.htm doc/API.htm doc/Issues.htm doc/DLL.htm doc/Drivers.htm man/pfbtopfa.1 doc/Release.htm doc/Commprod.htm doc/Xfonts.htm doc/Devices.htm doc/Language.htm man/gs.1 man/pf2afm.1 doc/Ps2ps2.htm doc/Fonts.htm man/printafm.1 doc/Ps2pdf.htm doc/Develop.htm doc/Helpers.htm man/pdf2dsc.1 doc/Psfiles.htm doc/Lib.htm doc/gs-vms.hlp man/font2c.1 man/gsnd.1 base/version.mak man/pdfopt.1 doc/News.htm man/pdf2ps.1 man/ps2pdf.1 doc/Make.htm doc/Details8.htm doc/Unix-lpr.htm doc/C-style.htm doc/Ps-style.htm doc/History1.htm doc/History2.htm man/gslp.1 man/wftopfa.1 doc/History3.htm man/ps2ps.1 doc/Details.htm doc/Ps2epsi.htm doc/History4.htm man/ps2pdfwr.1 doc/History5.htm doc/History6.htm]</p>
</blockquote>

<p><strong><a name="2009-02-02T085811.805173Z"></a>
2009-02-02T08:58:11.805173Z Ray Johnston</strong></p>
<blockquote>
<pre>
Fix broken bbox device caused by the 'fillpage' commit of rev 9288. This
resolves bug 690260 and other cases where the bbox was all 0's.

DETAILS:

When the 'RECT_IS_PAGE' check was removed, the BBOX_INIT_BOX function was
invoked unconditionally MUCH too often, leading to an empty bbox (0's)
which also caused the x11 device to not update many areas from the under-
lying image24 buffer to the screen. The 'BBOX_INIT_BOX' should only be
needed when the params change the geometry or when 'fillpage' is done.
</pre>
<p>[base/gdevbbox.c]</p>
</blockquote>
</body>
</html>