print/cups-filters, print/libcupsfilters and print/libppd
Edgar Fuß <[email protected]> Wed, 29 Jul 2026 12:44:53 +0200
| Newsgroups | gmane.os.netbsd.devel.packages |
|---|---|
| Message-ID | <[email protected]> |
Does someone with CUPS knowledge understand the relationship between the cups-filters, libcupsfilters and libppd packages? Both somehow use (or don't use) renderers like poppler, ghostscript and mutools and seem to have some (optional?) use of dbus for colour management. I added options originally to cupsfilters, then, as some part seems to have been factored out into libppd, there, to select which (in my use case, PDF-to-PS) renderers to include and set CUPS' default PDF-to-PS-renderer; I also have -dbus in PKG_DEFAULT_OPTIONS since I only use those packages on a server. I (and apperantly, others before) additionally seem to have got confused by cups-filters having been split out of cups-browsed (which, itself, seems to be completely useless now it can't send any kind of browse messages anymore), and mistakenly removed dbus from cups-filters, not realizing it was used for colour management. Can someone in the know shed some light on this? I know my questions are mostly questions about upstream's infinite wisdom, but maybe someone did already dig through this. I.e.: -- why did upstream factor out libcupsfilters? -- why did upstream factor out libppd? -- why does upstream think it's libppd's job to render PDF to PS? -- whould it make sense to add options to cups-filters to select renderers? -- is it possible to build all this bunch of packages without dbus?