> Date: Wed, 24 Sep 2008 16:20:05 +0200 > From: Juan Pedro Bolivar Puente <[EMAIL PROTECTED]> > > [EMAIL PROTECTED] wrote: > > Hi Gerel. > > > > I think the Stream module documentation is missing the deallocation > > operation, > > the one that deallocs the memory used by the filter itself. > > ## > > pdf_status_t pdf_stm_f_somefilter_dealloc (void **state); > > ### > > > > As I mentioned in a previous email the pdf_stm_destroy() operation > > will take care about the memory used by 'state' (if any) by calling > > pdf_dealloc. > > > > > > Is that enough? What if the 'state' contains non-trivial data structures? > > Another question, after having received a finish_p in an apply, does the > possibility exist of receiving more data in the future? If that is true > (it could allow more freedom) > > I suggest a new interface with 5 operations defined by the filter > (params ommited):
Hey JP, I don't know if that schema makes a difference. To me the most difficult thing when writing the RL filter, was dealing with the trailing character AND the output bytes available, that's why I set a minimum cache size (i.e. the maximum bytes you would be forced to write when finishing) for it. And I guess you can't avoid that, the finish function you suggest should do a 'filter flush' anyways. cheers -gerel
