On Sun 13 Mar 2022 at 14:38:13 +0100, Daniel Gröber wrote:
[...]
> 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
>
On Sun 13 Mar 2022 at 17:07:19 +0100, d...@darkboxed.org wrote:
> On Sun, Mar 13, 2022 at 04:03:44PM +, Brian Potkin wrote:
> > 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
On Sun, Mar 13, 2022 at 04:03:44PM +, Brian Potkin wrote:
> 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
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 +, Brian Potkin wrote:
> > You have just confirmed that the printing system (CUPS + cups-filters
> > + (optionally) cups-browsed) works effieiently and as designed.
> >
>
Hi Brian and Simon,
On Sat, Mar 12, 2022 at 08:56:38PM +, 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
On Sat 12 Mar 2022 at 23:35:25 +, Simon McVittie wrote:
> On Sat, 12 Mar 2022 at 20:56:38 +, Brian Potkin wrote:
> > 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?
>
> cups upstream's
On Sat, 12 Mar 2022 at 20:56:38 +, Brian Potkin wrote:
> 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?
cups upstream's medium to long term plan seems to be that toolkits like
GTK and Qt should
On Sat 26 Feb 2022 at 19:43:08 +0100, Daniel Gröber wrote:
> Here are my test results:
>
> TLDR:
>
> - Printing via cups entry (be that cups-browsed or manual) always succeeds
You have just confirmed that the printing system (CUPS + cups-filters
+ (optionally) cups-browsed) works effieiently
Addendum:
I've had another closer look at the temporary queues code and upstream
discussions and I seem to have neglected the most significant configuration
for mr6.1. Namely "without cups-browsed or manual config". This in fact
works now because libgtk specifically doesn't try to just send
Here are my test results:
TLDR:
- Printing via cups entry (be that cups-browsed or manual) always succeeds
- Printing via libgtk's fallback entry always fails
- Both proposed fixes work and succeed in removing the duplicate entry for
cups-browsed, but not for a manually added printer with
On Mon, 21 Feb 2022 at 22:20:31 +0100, d...@darkboxed.org wrote:
> I'll make some time this weekend to test both versions. Should be pretty
> quick as long as you don't need test results for a clean system -- do you?
The more testing you can do, the better, but upgrading the packages on
an
Hi Simon,
Thanks for working on this, I do appreciate it :)
On Sun, Feb 20, 2022 at 05:19:32PM +, Simon McVittie wrote:
> On Mon, 26 Jul 2021 at 02:24:06 +0200, Daniel Gröber wrote:
> > I was seeing the exact same problem
>
> That doesn't appear to be the exact same problem: Zack said that
Here is hopefully a better solution for GTK 3 in bullseye:
https://people.debian.org/~smcv/bullseye-gtk-printing/mr6.1/
or if the release team will not accept that, then this:
https://people.debian.org/~smcv/bullseye-gtk-printing/mr9.1/
Please try those (in preference to mr6, mr9) and
On Sun, 20 Feb 2022 at 17:35:23 +, Simon McVittie wrote:
> GTK with merge request 6 (full backport from 3.24.29)
...
> With cups-browsed only: Two printers appear, labelled
> HP_Color_LaserJet_MFP_M277dw_xx and HP_Color_LaserJet_MFP_M277dw_xx_.
This seems to be a mismatch between the
On Sun, 20 Feb 2022 at 17:35:23 +, Simon McVittie wrote:
> With cups-browsed only: Two printers appear, labelled
> HP_Color_LaserJet_MFP_M277dw_xx and HP_Color_LaserJet_MFP_M277dw_xx_.
I think this is because the mDNS name of my printer happens to end with
a parenthesis (it's "HP
On Sun, 20 Feb 2022 at 17:19:32 +, Simon McVittie wrote:
> When reporting test results, please answer these questions:
>
> * Which versions of cups-daemon and cups-filters-core-drivers are installed?
> * How many printers are physically present on your network?
> * Have you configured a
On Sun, 20 Feb 2022 at 17:19:36 +, Simon McVittie wrote:
> I will reply to the bug with my own test results.
> * Which versions of cups-daemon and cups-filters-core-drivers are installed?
cups-daemon 2.3.3op2-3+deb11u1
cups-filters-core-drivers 1.28.7-1
> * How many printers are
On Tue, 16 Feb 2021 at 11:55:28 -0500, Zack Weinberg wrote:
> I have only one printer, a network-attached Brother HL model. CUPS
> autodetects it somehow and creates a queue for it:
>
> $ lpstat -e
> Brother_HL_L2350DW_series
>
> This queue shows up twice in the GTK print dialog box, with two
>
Hi Zack,
I was seeing the exact same problem and I posted a patch fixing the issue:
https://salsa.debian.org/gnome-team/gtk3/-/merge_requests/9
Could you test it to see if it fixes the problem for you too?
--Daniel
Package: libgtk-3-0
Version: 3.24.24-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: za...@panix.com
I have only one printer, a network-attached Brother HL model. CUPS
autodetects it somehow and creates a queue for it:
$ lpstat -e
Brother_HL_L2350DW_series
This queue shows up twice in the GTK
20 matches
Mail list logo
