Re: [pdf-devel] Problems in the stream implementation

[Juan Pedro Bolivar Puente]

address@hidden wrote:
>  > Date: Wed, 01 Oct 2008 22:23:58 +0200
>  > From: Juan Pedro Bolivar Puente <address@hidden>
>  > 
>  > Hi,
>  > 
>  > While writing the LZW filter implementation some doubts arose (I'm a
>  > corner case maniac, sorry :)):
>  > 
>  > Marchesi, why didn't you use circular buffers as we discussed in the
>  > GHM instead of those fill-rewind buffers you are using? I was wondering
>  > how the filter had to behave in case it needs to leave some data in the
>  > input buffer. I can happen quite often, as the "compression ratio" of
>  > most algorithms can easily go over 1.0 (they generate more data than
>  > they take).
> 
> I guess the buffers are intended to be circular, check the pdf_stm_buffer.c
> file. The filters should see it as circular. The thing is that the Stream
> code is not behaving as intended with the buffers.
> 

I've read all the filter's implementation and none is using the filters
as circullar. Yes, you are assuming that the end of the buffer input
data is the buffer.wp but you are always considering that buffer.wp >
buffer.rp. That is why the reset function is needed and that is why
nothing is working.

In a real circullar buffer you must considere the buffer like a "clock"
and the pointers as the "hands of the clock". So sometimes while wp < rp
the actual free espace in the buffer is (size - rp + wp)... But you
cannot know if the buffer have been overflowed without keeping an
additional counter...

As that pointer mangling can be tedious I suggested jemarch to use an
ring buffer ADT which abstracted the write and read operations and gave
him a first implementation I already had done for another project which
could be easily adapted to be used in GNU Pdf.

Trust me, the only way to solve this problem is to use a real circular
buffer. Actually, I think that it would also make the filter's
implementation more clear by not using pointers directly.

JP