Re: [pdf-devel] Filters deallocation

[Juan Pedro Bolivar Puente]

> 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.