ref: d5bbee50a019aaa91f16ab115f606739e837cb9c
dir: /sys/src/cmd/gs/doc/Details.htm/
<!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,v 1.20 2005/10/20 20:14:37 ray Exp $ -->
<link rel=stylesheet type="text/css" href="gs.css">
</head>
<body>
<p><strong><a name="2005-10-20_1946"></a>
2005-10-20 19:46 Ray Johnston</strong></p>
<blockquote>
<pre>
Update doc files and version files for 8.53 release.</pre>
<p>[doc/API.htm 1.53, doc/Bug-form.htm 1.49, doc/Bug-info.htm 1.49, doc/C-style.htm 1.55, doc/Commprod.htm 1.41, doc/Copying.htm 1.39, doc/DLL.htm 1.43, doc/Deprecated.htm 1.20, doc/Details8.htm 1.24, doc/Develop.htm 1.159, doc/Devices.htm 1.90, doc/Drivers.htm 1.58, doc/Fonts.htm 1.51, doc/Helpers.htm 1.44, doc/History1.htm 1.39, doc/History2.htm 1.39, doc/History3.htm 1.39, doc/History4.htm 1.39, doc/History5.htm 1.41, doc/History6.htm 1.56, doc/History7.htm 1.44, doc/History8.htm 1.29, doc/Htmstyle.htm 1.44, doc/Install.htm 1.56, doc/Issues.htm 1.52, doc/Language.htm 1.98, doc/Lib.htm 1.43, doc/Maintain.htm 1.50, doc/Make.htm 1.90, doc/News.htm 1.168, doc/Projects.htm 1.67, doc/Ps-style.htm 1.37, doc/Ps2epsi.htm 1.42, doc/Ps2pdf.htm 1.88, doc/Ps2ps2.htm 1.7, doc/Psfiles.htm 1.68, doc/Readme.htm 1.71, doc/Release.htm 1.95, doc/Source.htm 1.39, doc/Testing.htm 1.37, doc/Unix-lpr.htm 1.39, doc/Use.htm 1.136, doc/Xfonts.htm 1.39, doc/gs-vms.hlp 1.37, man/dvipdf.1 1.37, man/font2c.1 1.37, man/gs.1 1.38, man/gslp.1 1.37, man/gsnd.1 1.37, man/pdf2dsc.1 1.36, man/pdf2ps.1 1.38, man/pdfopt.1 1.36, man/pf2afm.1 1.37, man/pfbtopfa.1 1.38, man/printafm.1 1.37, man/ps2ascii.1 1.37, man/ps2epsi.1 1.35, man/ps2pdf.1 1.42, man/ps2pdfwr.1 1.41, man/ps2ps.1 1.44, man/wftopfa.1 1.37, src/gscdef.c 1.58, src/version.mak 1.87]</p>
</blockquote>
<p><strong><a name="2005-10-20_1942"></a>
2005-10-20 19:42 Ray Johnston</strong></p>
<blockquote>
<pre>
Remove trailing ^M (<cr>) characters.</pre>
<p>[src/gdevbmp.c 1.12, src/slzwd.c 1.7]</p>
</blockquote>
<p><strong><a name="2005-10-20_1851"></a>
2005-10-20 18:51 Raph Levien</strong></p>
<blockquote>
<pre>
Fixes broken compile on amd64 platforms (see bug #688047 for details).
This patch should be safe on all platforms with 32-bit longs, and is
my best guess as to the right thing to do on Tru64 (where long is 64
bits).</pre>
<p>[src/tttypes.h 1.3]</p>
</blockquote>
<p><strong><a name="2005-10-20_1304"></a>
2005-10-20 13:04 Igor Melichev</strong></p>
<blockquote>
<pre>
Fix (pdfwrite) : Suppress floating point number format in pdfmark operands (continued 2).
DETAILS :
Bug 688167 "change of real number fomat from fixed to exponential format".
The last patch doesn't correctly handle numbers between 1e-7 and 1e-2.
EXPECTED DIFFERENCES :
None.</pre>
<p>[lib/gs_pdfwr.ps 1.52]</p>
</blockquote>
<p><strong><a name="2005-10-18_2031"></a>
2005-10-18 20:31 Igor Melichev</strong></p>
<blockquote>
<pre>
Fix (pdfwrite) : Suppress floating point number format in pdfmark operands (continued).
DETAILS :
Bug 688167 "change of real number fomat from fixed to exponential format".
This improves the patch
http://ghostscript.com/pipermail/gs-cvs/2005-September/005717.html
with writing small reals in a fixed point number format.
We did it after Raph's request in Comment #5 of the bug 688167.
But we don't see a visible difference against the old implementation with any viewer.
Therefore we believe that we shouldn't have done it (as we did before the implementation).
Storing it now mainly for archiving purpose.
If this change causes a problem, the author has no objection for unwinding it.
EXPECTED DIFFERENCES :
None.</pre>
<p>[lib/gs_pdfwr.ps 1.51]</p>
</blockquote>
<p><strong><a name="2005-10-18_0905"></a>
2005-10-18 09:05 Igor Melichev</strong></p>
<blockquote>
<pre>
Fix (pdfwrite) : Indexed colors were distorsed with encryption.
DETAILS :
Bug 688313 "pdfwrite : image colors depend on encryption".
The old code applied encryption with a wrong (zero) object id to
the palette of the indexed color space. After a viewer decrypts
the palette with a right object id, colors appear wrong.
1. Use the PS string encoding instead the hexadecimal string encoding
while converting the palette to PDF format (gdevpdfc.c).
It provides a correct work of the part 3 below.
See also part 4 below.
2. Don't apply encryption when adding the palette
to cos object (gdevpdfc.c, devs.mak).
The old code was hacky, and new one is based on a general convention.
3. Apply encryption with a right object id
to the string which represents the palette
when writing the cos object to the output PDF file.
This is an implicit consequence of
using the PS string encoding in the part 1
due to a general convention about
applying encryption when writing cos objects to the output file.
4. Disable writing hexadecimal strings because their
encryption is not yet implemented (gdevpdfu.c).
The generated PDF may become longer in 1-2 kilobytes per palette
due to PS encoding is less effective for palettes.
This could be optimized with implelenting an encryption method
for hexadecimal encoded strings in pdf_put_encoded_hex_string,
and undo the part 1. The method should apply 3 filters :
hexadecimal string decode, arc4 encode, hexadecimal string encode,
because cos object stores strings in the outer format.
Delaying this optimization for better times.
EXPECTED DIFFERENCES :
None.</pre>
<p>[src/devs.mak 1.140, src/gdevpdfc.c 1.54, src/gdevpdfo.c 1.35, src/gdevpdfu.c 1.89]</p>
</blockquote>
<p><strong><a name="2005-10-18_0758"></a>
2005-10-18 07:58 Igor Melichev</strong></p>
<blockquote>
<pre>
Fix (pdfwrite) : Propagate error codes from pdf_write_value.
DETAILS :
This is a preparation for fixing the bug
688313 "pdfwrite : image colors depend on encryption".
In cases when no error happens, this code is algorithmocally equivalent.
EXPECTED DIFFERENCES :
None.</pre>
<p>[src/gdevpdfo.c 1.34, src/gdevpdfu.c 1.88, src/gdevpdfx.h 1.138]</p>
</blockquote>
<p><strong><a name="2005-10-17_1923"></a>
2005-10-17 19:23 Igor Melichev</strong></p>
<blockquote>
<pre>
Fix (pdfwrite) : /BP pdfmark could create dead PDF objects (continiued).
DETAILS :
Bug 687560 "Invalid PDF if /BP pdfmarks with non-unique /_objdef".
1. Prevent a potential crash while dereferencing NULL.
2. Don't put unnamed objects into local_named_objects.
Thanks to SaGS for pointing these problems out.
EXPECTED DIFFERENCES :
None.</pre>
<p>[src/gdevpdfm.c 1.50]</p>
</blockquote>
<p><strong><a name="2005-10-12_1759"></a>
2005-10-12 17:59 Igor Melichev</strong></p>
<blockquote>
<pre>
Fix : Don't instantiate pattern when rendering to null device.
DETAILS :
Bug 688308 "Error: undefined; OffendingCommand: .type1execchar".
The test case executes cshow or kshow with intrevene changing
the current color space, causing a color load callout from fill_with_rule
_after_ the callout completes. After that the check
ctile->depth == dev->color_info.depth in gx_pattern_cache_lookup fails
(not sure why - probably due to gsave-grestore in the pattern procedure).
This patch skips entire character drawing when the device is null,
so that those cumbersome stuff isn't envolved.
EXPECTED DIFFERENCES :
None.</pre>
<p>[src/gsdevice.c 1.25, src/gspaint.c 1.10, src/gxdevcli.h 1.41]</p>
</blockquote>
<p><strong><a name="2005-10-12_1105"></a>
2005-10-12 11:05 Igor Melichev</strong></p>
<blockquote>
<pre>
Implementing a pointer stability validation in the garbager, continued.
DETAILS :
This patch is currently disabled, so the change is syntactically equivalent.
Bug 688226 "The garbager must check a pointer stability.".
This fixes a minor bug in the last patch.
EXPECTED DIFFERENCES :
None.</pre>
<p>[src/ilocate.c 1.14]</p>
</blockquote>
<p><strong><a name="2005-10-12_1045"></a>
2005-10-12 10:45 Igor Melichev</strong></p>
<blockquote>
<pre>
Implementing a pointer stability validation in the garbager.
DETAILS :
This patch is currently disabled, so the change is syntacticly equivalent.
Bug 688226 "The garbager must check a pointer stability.".
This patch extends the object header with a space order number field,
and compares the origin and the destination order numbers for each pointer
while validating the heap. The enhanced object header is still
within 16 bytes with the 32-bits architecture. See ialloc_validate_pointer_stability
about the order number definition.
This patch detected so many problems while running any document,
as we can't enable it now. It is disabled with IGC_PTR_STABILITY_CHECK
macro defined in gxobj.h .
EXPECTED DIFFERENCES :
None.</pre>
<p>[src/gsalloc.c 1.24, src/gxalloc.h 1.12, src/gxobj.h 1.7, src/ialloc.c 1.8, src/ilocate.c 1.13]</p>
</blockquote>
<p><strong><a name="2005-10-12_0816"></a>
2005-10-12 08:16 Igor Melichev</strong></p>
<blockquote>
<pre>
Fix (pdfwrite) : Skip a clip path, which is set by setcachedevice (continued after July 28 205).
DETAILS :
Bug 687678 "pdfwrite : A Type 3 character cut-off".
Bug 688327 "incorrect masking fill in pdfwrite".
The old patch for this problem appears to define a too weak
condition for recognizing a clipping set by setcachedevice, sectachedevice2.
Now we think that a special stuff for this condition isn't needed because
the condition may be united with the contition for "setcharwidth" :
both things need to skip the clipping path, which was set exactly by
setcachedevice, sectachedevice2 or setcharwidth.
Checking the rectangle coordinates is not relevant.
Therefore the change consists of 2 parts :
1. Unwinding the patch http://ghostscript.com/pipermail/gs-cvs/2005-July/005625.html (IM1358)
(see also http://ghostscript.com/pipermail/gs-cvs/2005-July/005626.html).
2. Remowing the (control == TEXT_SET_CHAR_WIDTH) check from pdf_text_set_cache,
so that the "caching" clipping path will be skipped in any case.
Will add Bug688327.ps to comparefiles.
EXPECTED DIFFERENCES :
None.</pre>
<p>[src/gdevpdfb.h 1.14, src/gdevpdfd.c 1.71, src/gdevpdfx.h 1.137, src/gdevpdti.c 1.53, src/gdevpdtt.c 1.104]</p>
</blockquote>
<p><strong><a name="2005-10-11_1004"></a>
2005-10-11 10:04 Igor Melichev</strong></p>
<blockquote>
<pre>
Fix (PS interpreter) : Allocate gs_screen_enum in same space as its components.
DETAILS :
Bug 688330 "A dangling pointer in gx_screen_enum.".
The old code allocates gs_screen_enum in current memory space and frees to
the memory space of its components, which is obtained from
the 'setscreen' operand (the spot function).
In the test case the first memory space is local, and the second one is global.
We guess the last statement became true after a recent change to the PDF interpreter.
This patch allocates gs_screen_enum in same space as its components.
The pritotype of zscreen_enum_init has been changed due to no method for
obtaining a space attribute value for iref from a gs_memory_t instance
(well, generally it is impossible, but one could solve if the memory
allocator is a PS interpreter's allocator except stable ones).
We noticed that components of gs_screen_enum have pointers to memory
allocator structures, but don't list them in the related memory descriptors.
We're not sure whether a memory allocator structure may relocate or not -
our investigation through code didn't give an unique answer.
For now we leave component descriptors as they were before the patch.
EXPECTED DIFFERENCES :
None.</pre>
<p>[src/iht.h 1.6, src/zht.c 1.8, src/zht1.c 1.7, src/zht2.c 1.14]</p>
</blockquote>
<p><strong><a name="2005-10-10_1909"></a>
2005-10-10 19:09 Igor Melichev</strong></p>
<blockquote>
<pre>
Fix: Cygwin/gcc warninhs.
EXPECTED DIFFERENCES :
None.</pre>
<p>[src/devs.mak 1.139, src/gdevpdfb.c 1.34]</p>
</blockquote>
<p><strong><a name="2005-10-10_1858"></a>
2005-10-10 18:58 Igor Melichev</strong></p>
<blockquote>
<pre>
Optimizing the transparency compositor.
DETAILS :
Bug 688255 "ai7 pdf fails on 7.03, runs for ten + minutes on 8.51".
The old code always allocates a transparency buffers for entire band.
The new code accounts group bbox to minimize buffers.
Due to that buffers appear empty for many of bands.
The time consumption for the test case of the bug 688255 is dropped in about 100 times
(from 8000 seconds to 71 seconds on a 3.07GHz machine, measured with debug build).
1. The transparency bbox computes in pdf14_begin_transparency_group from
the group bbox and the CTM (gdevp14.c).
2. Handle an empty buffer pdf14_buf_new, pdf14_pop_transparency_group (gdevp14.c).
3. Fixed a bug in the rectangle clipping in
pdf14_mark_fill_rectangle, pdf14_mark_fill_rectangle_ko_simple.
The old code didn't sense it because bbox always covered entire band (gdevp14.c).
4. Write the bbox to clist in c_pdf14trans_write and read it in c_pdf14trans_read.
5. The pdf14 compositor needs CTM to transform the group bbox to the device space.
Forced the writing of CTM to clist before writing the compositor in clist_create_compositor.
(Sorry, it appears some ugly due to pcte->type->procs.write creates a body
of a command, but we need to create a set of two commands;
Another minor optimization - a narrowing the set of bands - is delayed,
see comments in code in clist_create_compositor) (gxclimag.c).
6. New functions cmd_write_ctm_return_length, cmd_write_ctm are factored out for (5)
(gxclpath.c, gxclpath.h). This part of the change is algorithmically eqiuivalent.
7. Minor change : fixed coding style of "} else {" in gdevp14.c .
EXPECTED DIFFERENCES :
None.</pre>
<p>[src/gdevp14.c 1.35, src/gxclimag.c 1.13, src/gxclpath.c 1.21, src/gxclpath.h 1.13]</p>
</blockquote>
<p><strong><a name="2005-10-07_1949"></a>
2005-10-07 19:49 Ray Johnston</strong></p>
<blockquote>
<pre>
Add missing space in CVS PRE-RELEASE string.</pre>
<p>[src/gscdef.c 1.57]</p>
</blockquote>
<p><strong><a name="2005-10-07_1946"></a>
2005-10-07 19:46 Ray Johnston</strong></p>
<blockquote>
<pre>
Bump version after the 8.52 release (to 8.53 CVS PRE-RELEASE).</pre>
<p>[doc/News.htm 1.167, lib/gs_init.ps 1.120, src/gscdef.c 1.56, src/version.mak 1.86]</p>
</blockquote>
</body>
</html>