Re: cups-filters 1.11.1 released!
Hi again Till, Sorry for the delay. #life As you might have seen, I have finally uploaded 1.11.4-1 with your packaging, as I didn't want to block on this discussion any further. Le lundi, 22 août 2016, 14.13:49 h CEST Till Kamppeter a écrit : > On 08/22/2016 01:01 PM, Didier 'OdyX' Raboud wrote: > > 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? > > (…) > 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. ACK. Your business. > 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 That separation is fine, but I want to understand more precisely under which situations which renderer is used. I seem to remember that under some circumstances, ghostscript would be preferred over poppler, or the inverse; I can't recall out the precise details right now. So… Are these three entirely interchangeable, and would provide the same experience across the whole printers' ecosystem, or does one need (e.g.) ghostscript for Epson printers, and poppler for HP printers ? I don't want to worsen the experience by removing one of these renderers, especially not shortly before Debian's freeze. > 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. I need a better understanding of the "surface coverage" of the various renderers before ironing out a plan. -- Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Re: cups-filters 1.11.1 released!
On 08/29/2016 04:52 PM, Jonas Smedegaard wrote: 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? For larger systems we should perhaps seed the support for additional PDF renderers. Ideal woyld also be that if the base system had for example only Poppler as renderer that if one installs Ghostscript that then also cups-filters-ghostscript gets installed, but I do not have an idea yet how to best do it without circular dependencies. Till
Re: cups-filters 1.11.1 released!
[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 signature.asc Description: signature
Re: cups-filters 1.11.1 released!
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
Re: cups-filters 1.11.1 released!
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
cups-filters 1.11.1 released!
Hi, I have released cups-filters 1.11.1 now, with the following changes: - pdftops: Added support for MuPDF as PDF renderer. MuPDF can be selected by the "pdftops-renderer=mupdf" option. - rastertops: Removed unneeded page logging. - rastertops: Fixed DSC comments, some were only preceded by a single '%' instead of a double "%%". - gstoraster, pdftops, foomatic-rip: Use -dNOMEDIAATTRS when calling Ghostscript. This way Ghostscript does not try to match media sizes with internal lists. - 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. - gstoraster: Fix setting of width and height of the page in pixels when there is no Resolution option in the PPD. - cups-browsed, implicitclass: Avoid the use of files for the communication between cups-browsed and the load-balancing backend implicitclass. Instead of in a file, cups-brwsed stores the destination server name in an option (which CUPS saves in printers.conf) which the implicitclass backend reads via IPP. This not only makes it easier to run cups-filters in a sandbox, but it is also better in terms of system security. - cups-browsed: Allow configuring where the files produced by cups-browsed will get stored. This makes it easier to run cups-filters in a sandbox. - beh: Fixed printing multiple copies with beh (Ubuntu bug #1605514). - cups-browsed: Fixed several memory leaks, especially when using IPP requests and DNS-SD TXT record look-ups. Thanks to Ivo Straka for finding them with Valgrind and supplying patches to fix them (Bug #1365, Bug #1368, Ubuntu bug #1203276). - libcupsfilters: Added missing "#include " to make sure that the package builds on all systems (Bug #1366). I have committed this already to the Debian GIT repo, but I have also released 1.11.1-0ubuntu1 (no changes compared to Debian repo) directly to Yakkety because of the Ubuntu Feature Freeze today. So you do not need to hurry this into Debian to meet the Ubuntu Freeze. I can sync the Debian releases again at any time after the Freeze if they are only bug fixes. Till
