> 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? Right. If the state contains non-trivial data structures then we are fuck. I just changed the trunk to use pdf_status_t pdf_stm_f_XXX_dealloc_state (void *state); upon pdf_stm_filter_destroy. 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) /* Tells the filter to start a new data processing block. I mean, some filters might need to add some kind of header to the data, while others need to add some closing data. Precondition: the filter has been initialized. Postcondition: the filter can start processing. */ pdf_filter_start () A filter can easily implement this feature by using some boolean value in the filter's internal status, to determine if this is the first time it is invoked. To have an explicit call for this would make the algorithm implementing the filter chain more complex. /* Invoqued when there is no more data. Precondition: The filter must be started. Postcondition: The filter will not be started. The filter *can be used again* if start is invoqued again. */ pdf_filter_finish () With the current semantics you can call 'pdf_filter_init' to reset the state of the filter (the use of an explicit pdf_filter_start would invalidate this option). We can add a new function to the stream (say pdf_stm_reset (stm)) that would prune the cache buffers and would call the 'pdf_init' function for all the filters in the chain. I also purpose to decouple encode-decode filters making a separate filter for the encoder and for the decoder, as implementation usually have no similarity at all. I dont understand. That is what are doing in the new design: for each filter "type" there is an encoding filter (ahex enc) and a decoding filter (ahex dec)...
