> 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); >
Great :) The LZW filters use non-trivial data structures, so these are great news. > 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. > The purpose of the additional start/stop interface is to avoid having to realloc the data structures used by the filter in case a reset is needed. Anyway, it is a "how I would have done it suggestion" but the current interface is ok, we don't have to mess with it. The only thing that I still don't understand (and my suggestion about the other interface was to make it more explicit) is in which state the filter is left after receiving a "finish_p". It must assume that I can be invoqued again with more new data? > 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)... I had not read your response to Alex's question about encoding a "mode" attribute in the param's hash, sorry. Thanks, JP PS: Psychosynth is now GNU Psychosynth :) I told Nacho to create a MediaWiki for it and another for GNU Jump. I told him to steal your GNU PDF MediaWiki theme so we gain a homogeneous web-experience among mediawikied GNU projects.
