On 08/22/2016 01:01 PM, Didier 'OdyX' Raboud wrote:
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).
I quickly put up the new source for Ubuntu's Feature Freeze without
really changing the cups-filters-core-drivers which used to use Poppler
as this was on Ubuntu's phone all the time for PDF screen display.
Now my new idea for packaging is the following: As there are three PDF
renderers, Ghostscript, Poppler, and MuPDF I suggest to add three binary
packages:
cups-filters-ghostscript
cups-filters-poppler
cups-filters-mupdf
Each contains all filters (and auxiliary files like PPDs) which need the
appropriate renderer and also the corresponding *.convs file. Each
package depends on the appropriate renderer's executable (gs, pdftops,
mutool).
cups-filters-core-drivers has then an OR dependency on the three:
Depends: cups-filters-mupdf | cups-filters-poppler |
cups-filters-ghostscript
So the minimum installation pulls in the support for one renderer, so it
works if one of the renderers is installed. With the order shown above
it would also pull in MuPDF if no renderer is installed.
So small-footprint systems could be done either MuPDF-based or
Poppler-based (even Ghostscript-based, but is this then still
small-footprint?).
WDYT?
Till
