Re: cups-filters 1.11.1 released!

[Till Kamppeter]

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!

[Jonas Smedegaard]

[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!

[Till Kamppeter]

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

Bug#835911: hplip: please switch from dbus-x11 to default-dbus-session-bus | dbus-session-bus

[Simon McVittie]

Package: hplip-gui
Version: 3.16.7+repack0-1
Severity: normal
User: d...@packages.debian.org
Usertags: dbus-launch default-dbus-session-bus

As described in 
I'm trying to reduce how much dbus-launch is used in Debian.
This package currently Recommends dbus-x11 as a way to get a session bus.

This package falls into the "other software that relies on D-Bus"
category: please replace

Depends: dbus-x11

with

Depends: default-dbus-session-bus | dbus-session-bus

so that either dbus-user-session or dbus-x11 can be used. My short-term
goal with this is that major desktop environments in Debian stretch should
be able to run with either dbus-user-session or dbus-x11, with the other
one uninstalled.

Thanks,
S