Comment 6 for bug 1785230

For now, the best workaround for distros appears to be reverting the libImageProcessor related changes to HPCupsFilter::processRasterData(), as Debian seems to have done already. It's likely "just" an optimization that enhances the rendering of rastered pages. (Some public information about the purpose of imageProcessorProcessLine() would be desirable).

@Srinivas, there's a mechanism already in place to download the binary plugins for various printer models. Can you consider a similar mechanism for libImageProcessor? Thus, rather then shipping it with hplip and linking with it hard, you could offer to download it with the plugin helper in hp-setup. The CUPS filter code would then try to and dlopen() it, and just skip calling the related functions if the library isn't found, falling back to in 3.18.6 behavior.

In any case, it would be highly desirable to have libImageProcessor available not only for x86 and x86_64, but (at least) also for arm32 and arm64 (for which you provide the plugins).