Re: cups-filters 1.11.1 released!

[Till Kamppeter <till.kamppeter@gmail.com>]

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