Re: [pdf-devel] Predictor filter

[Jose E. Marchesi]

    I can't persuade bzr to give me any kind of useful history information
    (i.e. bzr blame tells me revisions which it then appears unable to
    diff reliably). As far as I can tell, there were no test cases for the
    predictor stuff before. There are certainly none now, commented out or
    otherwise (according to "find -name *.c | xargs grep -i pred").

There were no tests checking the previous implementation.
    
    How do I find out if it works? I re-installed it in the pdf-filter
    application, but what can I do with that application? Since it works
    by scanlines, and has a large range of formats, typing in test data by
    hand to standard input would be both quite challenging and probably
    unproductive.

You can find several unit tests for the currently implemented filters in
both torture/unit/base/stm/pdf-stm-read.c and
torture/unit/base/stm/pdf-stm-write.c. I guess that a similar approach
could be used to test the predictor filters.

If you need to store large test data (such as a file containing the
expected results) you can create new files in torture/testdata/.
    
    Additionally, is there any documentation for the architecture (beyond
    high level fluff?). I copied the implementation of the LZW filter, but
    I couldn't work out what the finish_p parameter meant in the apply
    function.. Is this some cue to write a trailer if needed? I ignored it
    on the basis that the predictor stuff hadn't needed such a flag
    before, but this was just a guess.

The architecture of the stream filters is documented in
doc/gnupdf-arch.texi, section "Stream filters".  Your premise about the
utility of finish_p is correct.
    
-- 
Jose E. Marchesi    address@hidden
GNU Project         http://www.gnu.org