On Wednesday 02 May 2018 08:14:11 Solomon Peachy wrote: > On Wed, May 02, 2018 at 10:13:12AM +0200, Johannes Meixner wrote: > > https://github.com/apple/cups/issues/5271 > > so that adding support for CUPS command files > > seems to be a non future proof way. > > Relying on CUPS in any way is non-future-proof, because everything > that doesn't relate to being an IPP *client* has been deprecated, with > no intention of developing a replacement for any sort of > locally-attached printer. > > Meanwhile, CUPS (and cups-filters and PPDs and everything else that > CUPS has tossed or is tossing into the rubbish bin) remains the only > way to get printers that lack IPP support (ie the overwhemling > majority of what's out there, especially in the non-consumer-focused > space) to act as anything other than expensive paperweights. > Damn! I know Michael from way back in the late '80's, and when he sold himself to Apple, my alarm bells went off. And it appears they were right. We are being microshafted.
> So there are only two viable long-term paths forward for folks like > us: > > * Fork CUPS when it finally drops the deprecated stuff and carry on > as before. Note that this has already happened, resulting in > 'cups-filters'. * Develop a complete IPP server implementation that > natively interfaces with libgutenprint (as opposed to the CUPS PPD > API) This is a _huge_ undertaking that will require re-creating a > sizeable chunk of what CUPS [used to] provide. (eg job spooling, > network daemon including a proper http server, image/PDL > decode/conversion including things like N-up and manual copy and > collation support, general option enumeration and parsing, and so > forth..) > > As an aside, every proprietary OSX printer driver I've seen is in a > similar predicament, because they are also entirely dependent on > deprecated CUPS functionality. > > Meanwhile. Fully implementating the CommandFile stuff in Gutenprint > will yield several bits of internal plumbing that are necessary to > provide proper IPP functionality: > > * Reporting printer options (eg what hardware options are > present, or what kind/quantity of media is loaded) > * Setting driver defaults based on printer options > * Reporting printer status (job status, errors, counter, etc) > * Invoking printer commands (eg self-test, cleaning, alignment..) > > Some of these things exist but in an ad-hoc manner (typically > requiring use of external cmdline tools that don't integrate with > anything else). Plus, simply implementing the first will yield > immediate benefits with modern Linux desktop environments. The latter seems like the only way foward. But do you have the people resources that will take? I have benefitted greatly from cups, so if you have to crowdfund the help, count on me for a small donation, I'm on SS, but that doesn't cancel TANSTAAFL. > - Solomon -- Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene> _______________________________________________ gimp-user-list mailing list List address: gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
