Re: [pdf-devel] [patch] convert LZW filter to new API

[jemarch]

   The problem is that there is a point in the LZW decoding where there is
   no way to distinguish between an EOF and ENINPUT.

Is the input buffer empty in those situations? See below.

   I've reviewed pdf_stm_filter_apply and what is happening is:

     1. The ambiguous situation where different behaviour for EOF/ENINPUT
   is required arises. The LZW decoder returns ENINPUT.
     2. pdf_stm_filter_apply checks the LZW decoder return value. On
   ENINPUT it then checks the actual input to see if there is more data to
   feed the filter.
     3. As there is no more data, then it asumes EOF, and returns.

Note that when a filter returns ENINPUT and then the backend returns
EOF, the filter is called again with finish_p == TRUE and and empty
input buffer.  In that case, the protocol says that the filter should
_not_ return ENINPUT again.

The case where the filter returns ENINPUT and there is still data in
the input buffer is _not_ considered: the filter should "consume" all
the contents in the input buffer before to return ENINPUT, storing it
in some internal storage if needed.

So your 3. point would only occur if the filter returns ENINPUT after
it got a finish_p == TRUE call.  And that is the "EOF condition" you
are asking for.

     4. As a result, there are pending decoded bytes in the internal state
   that are never flushed because the filter did not know that an EOF
   ocurred.

The filter knows it when it gets a call with finish_p == TRUE.

-- 
Jose E. Marchesi
address@hidden

GNU Project
http://www.gnu.org