Re: [pdf-devel] Bug in LZW filter?

[Aleksander Morgado]

> 
> On 03.09.2011 22:46, Aleksander Morgado wrote:
> > Great, good catch. Would it be possible to have some unit test for this
> > specific issue as well?
> 
> I made some test files and added these to the unit test. It showed up,
> that the encoder was broken too (because they work symmetrical).
> 

That was likely to happen yes.

> Additional tests showed that encoding with EarlyChange = 0 (very
> unusual) needs a bigger table (LZW_MAX_DICTSIZE + 1). I have done a lot
> of testing and the LZW encoder (with EarlyChange = 0) now outputs the
> same files as PDFlib-Lite-5.0.4p1 does. (PDFlib-Lite-5.0.4p1 is the only
> encoder with EarlyChange = 0 I found)
> 

So the changes done will make it work both with EarlyChange=0 and
EarlyChange=1, I am assuming.

> The attached patch contains:
> * fixes in the LZW filter
> * new test files
> * unit test that uses the new test files
> 

Could you maybe try to explain one by one the changes in
'src/base/pdf-stm-f-lzw.c'? They seem pretty straightforward, but I
would like to know the reasoning behind each of them. Are they all due
to needing a bigger table with EarlyChange=0?

Are we testing these fixes with more than one dataset? How sure are we
that we're not fixing one test case and breaking all the others?

I'm tempted to push the fix, but I would like to have some other pair of
eyes looking at the changes. Someone with some experience in LZW?

> Is it desirable to include the PDF-Files (2 files with each 20KB) which
> where used to extract test files TD00006..9? (ATM they are excluded from
> the patch)
> 

I would keep the generated test files only.

-- 
Aleksander

signature.asc
Description: This is a digitally signed message part