[moving conversation back to public list] Quoting Till Kamppeter (2016-08-22 19:13:49) > On 08/22/2016 01:01 PM, Didier 'OdyX' Raboud wrote: > > 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?). Sounds good with package name clearly indicating which renderer is used. In isolation it sounds sensible to use ORed list, but how does it fit into the larger picture? Will minimal implementation then always be default, also for larger systems? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
Attachment:
signature.asc
Description: signature