Re: [pdf-devel] Predictor filter

[Ed]

I've unassigned this task and reverted the progress to 0. I'm not
going to have time to do this. Sorry for wasting your time.

On 23 January 2011 22:36, Jose E. Marchesi <address@hidden> wrote:
> You could write little bitmaps by hand to test the predictors.  Consider
> for example the following gradient (the P2 identifies the pbm as an
> ASCII portable bitmap, 6 3 are the dimensions and the 10 is the number
> of gray values between black and white).
>
> P2
> 6 3
> 10
> 2 2 1 1 0 0
> 2 2 1 1 0 0
> 2 2 1 1 0 0

Of course, I could. But this doesn't really get to the bottom of the
problem. It doesn't test any of the assumptions the code makes, it
merely tests that the assumptions are implemented correctly, which is
the most basic confirmation above testing something compiles. I tried
using an LZW stream stacked with the predictor stream (as it would
need to be) to read real PDF streams, but that didn't work at all. I
also had trouble generating real PDF streams with known bitmaps -
because I don't have a program that will compress small bitmaps when
it embeds them in PDF. I could've checked the leading few pixels with
time, but I haven't had that time.

I wanted to put here some notes as a help to whoever ends up doing
this. The critical problem is buffering. The buffer size is not
settable by the filter itself. That means the buffer will not in
general contain a whole number of scanlines (or indeed an entire
scanline). I believe that the easiest way to handle this is to hold a
partial scanline carried from the previous buffer as part of the
filter. It would be better to split the implementation into DEC and
ENC parts as other filters do. This is already nearly present in the
code and not difficult to do. It simplifies things considerably. There
should be a note somewhere that PNG is not really PNG but PDF-PNG
which uses different constants (and allows TIFF!).

I hope this helps someone.

Best of luck,

Ed