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.
Walter, firefox doesn't use gtk20 (except for Adobe Flash plugin) but the patch applies against both gtk20 and gtk30.
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.
No problem (was my error with the title).
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.
Created attachment 196976 [details]
Alternate patch to fix GTK
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.
Have you tried to submit the patch/rationale upstream? gnome@ (downstream) is understaffed and, probably, doesn't have enough expertise to review.
Offhand, I wouldn't know how to do that ...
I created an account on Gnome's GitLab server and created an issue for this: https://gitlab.gnome.org/GNOME/gtk/issues/1385
I created a pull request in the Gnome repo. It was marked for GTK4.
Ping! There are more people who are missing the LPR printing capability in Firefox!
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.
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.
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.
(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.
A commit references this bug:
Date: Mon May 11 13:11:53 UTC 2020
New revision: 534912
www/firefox: backport NSS 3.52 support after r533597
Reported by: Tomasz "CeDeROM" CEDRO, Roman
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.
The 2018-09-03 patch still applies cleanly to gtk2-2.24.32 and gtk3-3.24.10_1.