[gs-cvs] rev 7105 - trunk/gs/src

[leonardo at ghostscript.com]

Author: leonardo
Date: 2006-10-12 17:02:34 -0700 (Thu, 12 Oct 2006)
New Revision: 7105

Modified:
   trunk/gs/src/gxclutil.c
Log:
Fix (clist) : CCITTFaxDecode consumed extra byte.

DETAILS :

Debugged with ghostpcl ppmraw -r216 c327.bin .

This patch is based on my understanding of the problem,
which was obtained within a short time frame.
Therefore I'm, not sure that all statements of this comment
are necessarily correct.

The old code didn't write the EOD sequence for CCITTFax data.
Such behavior was designed many years ago in order to write 
a smaller clist output. A year ago the CCITTFaxDecode filter 
was improved with a workaround for an incorrect behavior of 
Adobe Acrobat, which writes an EOD when it is not required 
(see the gs revision 6123).
The workaround looks ahead for EOD and consumes it if it appears.

However doing that improvement, nobody took care about the
clist reader, which didn't write EOD and catenates other data
after CCITTFax data. If the subsequent data occasionally look as EOD,
they are erroneusely consumed by CCITTFaxDecode, 
and the clist reader continues with a wrong position.
It caused unpredictable behavoir and stochastic crashes.

This patch forces writing the CCITTFax EOD for clist. 
Maybe it's not the best fix, but it is what we can do
within the short time frame.

EXPECTED DIFFERENCES :

None.


Modified: trunk/gs/src/gxclutil.c
===================================================================
--- trunk/gs/src/gxclutil.c	2006-10-11 21:12:53 UTC (rev 7104)
+++ trunk/gs/src/gxclutil.c	2006-10-13 00:02:34 UTC (rev 7105)
@@ -673,7 +673,13 @@
 {
     ss->K = -1;
     ss->Columns = width;
+#if 0 /* Disabled due to a crash with ppmraw -r216 c327.bin :
+	 the decoding filter overruns in 1 byte.         
+       */
     ss->EndOfBlock = false;
+#else
+    ss->EndOfBlock = true;
+#endif
     ss->BlackIs1 = true;
     ss->DecodedByteAlign = align_bitmap_mod;
 }