Bug 231110

Summary: x11-toolkits/gtk20, x11-toolkits/gtk30: GTK print dialogs falsely believe lpr cannot accept PDF
Product: Ports & Packages Reporter: George Mitchell <george>
Component: Individual Port(s)Assignee: freebsd-desktop (Team) <desktop>
Status: Closed Overcome By Events    
Severity: Affects Many People CC: gecko, gnome, lantw44, lwhsu, scf, tcberner, vas, w.schwarzenfeld
Priority: ---    
Version: Latest   
Hardware: Any   
OS: Any   
Attachments:
Description Flags
Patch to tell GTK that lpr accepts PDF output
none
Alternate patch to fix GTK none

Description George Mitchell 2018-09-03 00:22:29 UTC
Created attachment 196805 [details]
Patch to tell GTK that lpr accepts PDF output

The LPR backend for GTK asserts that "lpr" cannot accept PDF files.  Granted, you can't tell in general whether lpr in a given situation will be able to print a PDF or not, but declaring that it can't is needlessly restrictive.  The attached patch (works for both GTK2 and GTK3) adds the "accepts-pdf" property to the lpr backend and fixes the problem.

This patch is suggested as an alternative to the patch from the freebsd-gecko email thread "firefox-60.0_2,1 missing 'Print to LPR'", from May 13, 2018, which circumvents the problem by generating PostScript output instead of PDF.  Fixing the problem in GTK means that other users of GTK won't have to create parallel workarounds.
Comment 1 Jan Beich freebsd_committer freebsd_triage 2018-09-03 19:29:25 UTC
Walter, firefox doesn't use gtk20 (except for Adobe Flash plugin) but the patch applies against both gtk20 and gtk30.
Comment 2 George Mitchell 2018-09-03 23:05:39 UTC
Is it legal to cite two port names in the title of the bug?  The problem (and the patch) apply to both gtk2 and gtk3.
Comment 3 Walter Schwarzenfeld freebsd_triage 2018-09-03 23:08:37 UTC
No problem (was my error with the title).
Comment 4 Sean Farley freebsd_committer freebsd_triage 2018-09-09 03:43:20 UTC
I had written a patch, that I had forgotten, that looks similar to yours.  It has a few differences.  I am not the best with GTK code, so I have no idea which is correct between your patch or mine in relation to the backend and is-virtual settings.  I also include accepts-ps in the function call as the lpr filter I am using handles both.
Comment 5 Sean Farley freebsd_committer freebsd_triage 2018-09-09 03:44:34 UTC
Created attachment 196976 [details]
Alternate patch to fix GTK
Comment 6 George Mitchell 2018-09-09 18:42:05 UTC
I know less about GTK probably than anyone else on the project, so someone else should probably choose between these two patches.  But the other backends don't specify "accepts-ps", so I assumed it was the default.  Also, I wrote "GTK_PRINT_BACKEND (backend)" simply because that looked similar to what I saw in the other backends.

But it does seem to me like a very good idea to incorporate one of these patches.
Comment 7 Jan Beich freebsd_committer freebsd_triage 2018-09-09 19:16:14 UTC
Have you tried to submit the patch/rationale upstream? gnome@ (downstream) is understaffed and, probably, doesn't have enough expertise to review.
Comment 8 George Mitchell 2018-09-09 19:38:04 UTC
Offhand, I wouldn't know how to do that ...
Comment 9 Sean Farley freebsd_committer freebsd_triage 2018-10-04 21:36:03 UTC
I created an account on Gnome's GitLab server and created an issue for this:  https://gitlab.gnome.org/GNOME/gtk/issues/1385
Comment 10 Sean Farley freebsd_committer freebsd_triage 2018-12-29 17:34:31 UTC
I created a pull request in the Gnome repo.  It was marked for GTK4.
https://gitlab.gnome.org/GNOME/gtk/merge_requests/418
Comment 11 Victor Sudakov 2020-05-10 15:12:13 UTC
Ping! There are more people who are missing the LPR printing capability in Firefox!
Comment 12 Victor Sudakov 2020-05-10 15:14:23 UTC
GIMP from ports still can "Print to LPR", I double-checked 10 minutes ago.

And yes, ghostscript now accepts PDF input just find, so you can configure a "ps" printer and print PDFs to it. This is what I've done.
Comment 13 Sean Farley freebsd_committer freebsd_triage 2020-05-11 02:41:21 UTC
I must admit to having forgotten about this since I have been running happily with the patch I submitted upstream in September 2018.

It should hopefully go into GTK4, but I have not followed what the status of that is.  Also, we would have to wait until Firefox moves to GTK4.  I think it should be added to ports as patch since it may be quite awhile before we see it in the applications we use.  Unless, someone has push upstream to get it into GTK3.
Comment 14 George Mitchell 2020-05-11 03:20:07 UTC
Lacking any pull with the upstream project, I've been hoping one or the other of these patches would be adopted by FreeBSD for the port since I submitted the bug.
Comment 15 Victor Sudakov 2020-05-11 06:55:01 UTC
(In reply to Sean Farley from comment #13)
> I have been running happily with the patch I submitted upstream in September 2018.

Does it still apply cleanly to current www/firefox ? Anyway, I'd hate to build firefox locally, it's too resource- and time-consuming.

Could we ask the port maintainer to add this patch to the FreeBSD ports tree? I see no harm in it.
Comment 16 commit-hook freebsd_committer freebsd_triage 2020-05-11 13:12:29 UTC
A commit references this bug:

Author: jbeich
Date: Mon May 11 13:11:53 UTC 2020
New revision: 534912
URL: https://svnweb.freebsd.org/changeset/ports/534912

Log:
  www/firefox: backport NSS 3.52 support after r533597

  PR:		231110
  Reported by:	Tomasz "CeDeROM" CEDRO, Roman

Changes:
  head/www/firefox/Makefile
  head/www/firefox/files/patch-bug1624128
Comment 17 Jan Beich freebsd_committer freebsd_triage 2020-05-11 13:20:57 UTC
Sorry, I've copy-pasted the wrong bug number into PR field. comment 16 belongs in bug 246363.

(In reply to Victor Sudakov from comment #15)
> Does it still apply cleanly to current www/firefox ?

There're no patches against www/firefox in this bug. Revert from https://lists.freebsd.org/pipermail/freebsd-gecko/2018-May/008327.html doesn't apply due to high code churn uptream.
Comment 18 George Mitchell 2020-05-11 13:36:10 UTC
The 2018-09-03 patch still applies cleanly to gtk2-2.24.32 and gtk3-3.24.10_1.
Comment 19 Sean Farley freebsd_committer freebsd_triage 2020-10-08 23:57:06 UTC
The PR was merged on October 7th, 2020 to the GNOME gtk master with a GTK4 tag:  https://gitlab.gnome.org/GNOME/gtk/-/commit/668868fb1f5c698abba764b24379a3fc4c405abe
Comment 20 George Mitchell 2020-10-09 00:09:42 UTC
It seems to me we can now close this as fixed.  Any objections?
Comment 21 Victor Sudakov 2020-10-10 08:43:53 UTC
(In reply to george from comment #20)
Let's wait for the new Firefox package (with lpr printing support) appear in the official FreeBSD package repo, and then we can close the PR.
Comment 22 Sean Farley freebsd_committer freebsd_triage 2020-10-18 16:42:35 UTC
(In reply to Victor Sudakov from comment #21)

I see two options:
- Wait until gtk3 (and gtk2) are removed from the ports tree.
- Take the patch merged into gtk4 and add it to the gtk2 and gtk3 ports.

Since the first option will most probably take years to happen, I think the second option is the best choice.
Comment 23 Sean Farley freebsd_committer freebsd_triage 2020-12-12 17:29:21 UTC
As of gtk v3.24.24, the pull request is in the library.

Changelog:  https://gitlab.gnome.org/GNOME/gtk/-/compare/3.24.23...3.24.24
Commit to v3.24.24:  https://gitlab.gnome.org/GNOME/gtk/-/commit/8d5357ee
Comment 24 Tobias C. Berner freebsd_committer freebsd_triage 2020-12-12 17:38:27 UTC
(In reply to Sean Farley from comment #23)
Moin moin 

Gtk has been updated to 3.24.24 in r557252 -- and with the next quarterly being half a month away, can we consider this resolved?


mfg Tobias
Comment 25 Sean Farley freebsd_committer freebsd_triage 2023-01-03 17:52:49 UTC
(In reply to Tobias C. Berner from comment #24)

For x11-toolkits/gtk30, this should be considered fixed.  Firefox offers "Print to LPR" in the system dialog.  A patch may be considered needed for x11-toolkits/gtk20, but Firefox no longer uses that port.
Comment 26 Sean Farley freebsd_committer freebsd_triage 2024-01-15 20:26:12 UTC
It looks like everyone feels this has been fixed upstream and subsequently updated within ports, therefore, closing this bug.