On Sun 13 Mar 2022 at 14:38:13 +0100, Daniel Gröber wrote: > Hi Brian and Simon, > > On Sat, Mar 12, 2022 at 08:56:38PM +0000, Brian Potkin wrote: > > You have just confirmed that the printing system (CUPS + cups-filters > > + (optionally) cups-browsed) works effieiently and as designed. > > > > > Resultion: printing is still hell on earth :] > > > > libgtk is not part of the printing system; > > Erm, sorry but it is part of the printing experience from a user's POV.
True. > I wasn't trying to imply cups is the problem in fact if you read the > backlog much of my frustration is with libgtk, but hell at least I'm here > proposing patches so I feel I get to poke som fun at it. No offence > intended Simon :) > > Besides in the end it turned out libgtk with the right patch does work so > *shrug*. Having the GTK dialog on bullseye as a good citizen would be gratifying. > > > - Printing via libgtk's fallback entry always fails > > > > I wouldn't see libgtk as providing a fallbac. Why would a fallback be > > needed when the printing system does the jobi, as you have demonstrated? > > On bullseye libgtk treads its own path and ignores the CUPS APIs. It is > > little wonder users (like the bug submitter) experience consternation. > > Here I also don't quite understand libgtk upstream. I assume the intention > for the fallback is to have printing to at least work with some printers > when cups isn't running/installed. While I think that's a terrible idea we > still didn't want to break that behaviour since some users might now be > depending on it. I cannot provide code but can supply information. Perhaps there is some enlightenment at https://bugzilla.gnome.org/show_bug.cgi?id=688956 This is what began the process. Comments 5 and 6 look interesting. Printing via a GTK destination to an IPP printer has never worked for me. Even if printer information could be obtained, a Cairo-produced PDF would go to the printer and PDF is not a PDL understood by it. In what circumstances does such a destination work? Regards, Brian.
