Hi Till,
Le jeudi, 18 août 2016, 02.26:58 h CEST Till Kamppeter a écrit :
> I have released cups-filters 1.11.1 now, with the following changes:
ACK, thanks.
> - pdftops: Added support for MuPDF as PDF renderer. MuPDF can
> be selected by the "pdftops-renderer=mupdf" option.
> - Build system: Allow building cups-filters without Poppler
> (--disable-poppler in ./configure command line) This skips
> the build of pdftoraster, bannertopdf, pdftoijs, and
> pdftoopvp and the installation of these filters and their
> auxiliary files. With this cups-filters can be easily
> installed on mobile/appliance systems with MuPDF as the only
> PDF interpreter.
> - mupdftoraster: Added filter to support MuPDF as PDF
> interpreter. MuPDF is a lightweight PDF interpreter
> especially interesting for mobile systems and
> appliances. Thanks to Pranjal Bhor for contributing this as
> part of his Google Summer of Code project.
I don't understand the way you have reflected this in the Debian packaging,
especially in the "cups-filters" vs "cups-filters-core-drivers" separation.
My understanding has always been that cups-filters-core-drivers would contain
the small set of tools for minimal footprint; and that cups-filters would
contain (and pull) all the bells and whistles.
Why is it then that mupdftoraster is gone to cups-filters; while pdftoraster
(poppler) goes to cups-filters-core-drivers ? This seems counter-intuitive for
me; shouldn't we have a very minimal cups-filters-core-drivers (with small
tools and minimal footprint), and a bigger cups-filters?
In any case, in the Ubuntu package, MuPDF (aka /usr/bin/mutool, in mupdf-
tools' package) isn't pulled through Depends/Recommends, at all, so the filter
will be buggy and/or non-functional.
It'd also be great to have autopkgtests for these independent packages, so as
to maintain their "API" somewhat clear (and stable).
--
Cheers,
OdyX
