pdf-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [pdf-devel] Filters deallocation


From: jemarch
Subject: Re: [pdf-devel] Filters deallocation
Date: Fri, 26 Sep 2008 21:06:30 +0200
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (Shijō) APEL/10.6 Emacs/23.0.60 (i686-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]