> Date: Thu, 02 Oct 2008 23:28:37 +0200 > From: [EMAIL PROTECTED] > > > + /* > > + * 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
