Re: [pdf-devel] Patch for the Flate filter

[gerel]

 > Date: Thu, 02 Oct 2008 23:28:37 +0200
 > From: address@hidden
 > 
 >     >    + /* 
 >     >    +  * As read in the zlib documentation, our cache size must be at 
 > least 0.1%
 >     >    +  * larger than the CHUNK size, plus 12 bytes.
 >     >    +  * We assume that our cache size is of 4096 bytes.
 >     >    +  */
 >     >    +#define PDF_STM_F_FLATE_CHUNK 1024
 >     > 
 >     > What would happen if the user set a cache size of, say, 100 bytes? It
 >     > is possible to set the chunk size dinamically?
 > 
 >    Now that the issue arose I can say that this limitations are being,
 >    in part, imposed by the Stream implementation and the last apply()
 >    call JP mentioned in a previous email. The last apply() should be
 >    called until EOF and not only once as I think it does now.
 > 
 > Do the new semantics fix this problem?

Hi jemarch,

Well, let's see:

 > A limitation remains: when finish_p is PDF_TRUE the filter can assume
 > that there is room in the output buffer to hold its EOD
 > marker. Currently the minimum size is 1 since the EOD marker of the
 > ASCII Hex encoder is '>'.

There is the missing logic. It is the filter which decides when to stop
producing output, no one else.

My question comes down to this:

Is it correct to return PDF_ENOUTPUT even if the apply function is called with
finish_p=TRUE ? If the answer is yes, then the logic I mentioned above is being
considered in the architecture, and the problem has been solved. Otherwise, the
bug is still there.

I still suggests that we encapsulate the stream buffers.

cheers

-gerel