Hi JP. I am revisiting what the ISO says about predictors and found... that predictors are not considered by the PDF as a filter, they are an internal part of the LZWDecode and FlateDecode filters as stated in the 7.4.4.3 section.
Right. I think that it is still usefull for correct decoupling that the predictors are implemented as a separate filter. Then, it is the pdf_stm_filter_install() function who must test for [LZW,Flate]Decode filters wheter they should be "predicted" first and create the predictor filter in that case. What do you think? In my opinion it is the function _calling_ pdf_stm_filter_install who should be aware of this issue, in the object layer. In the future we may want to add a GNU extension providing new compression algorithms that may get advantage of a highly predictable input, so we will want pdf_stm_filter_install to install the specified "base filter", and nothing more.
