Bug 238583

Summary: print/gv: X11 resource "gsCmdConvPDF" is defined specifying nonexistent gs device "pswrite"
Product: Ports & Packages Reporter: david
Component: Individual Port(s)Assignee: freebsd-ports-bugs (Nobody) <ports-bugs>
Status: Open ---    
Severity: Affects Some People CC: mbeis
Priority: --- Keywords: needs-qa
Version: LatestFlags: koobs: maintainer-feedback? (mbeis)
Hardware: Any   
OS: Any   
Bug Depends on: 245692    
Bug Blocks:    

Description david 2019-06-15 17:05:59 UTC
This is running:
albert(11.3)[1] uname -a
FreeBSD albert.catwhisker.org 11.3-BETA3 FreeBSD 11.3-BETA3 #998  r348830M/348832: Sun Jun  9 03:47:33 PDT 2019     root@freebeast.catwhisker.org:/common/S1/obj/usr/src/sys/ALBERT  amd64

with these ports installed:
albert(11.3)[2] pkg info -o gv\* ghostscript\*
gv-3.7.4_5                     print/gv
ghostscript9-agpl-base-9.27_2  print/ghostscript9-agpl-base
ghostscript9-agpl-x11-9.27     print/ghostscript9-agpl-x11

albert(11.3)[3] gs -h | grep 'ps[^ ]*write'
   eplcolor eplmono eps2write eps9high eps9mid epson epsonc escp escpage
   pr1000_4 pr150 pr201 ps2write psdcmyk psdcmyk16 psdcmykog psdrgb psdrgb16
   x11cmyk8 x11gray2 x11gray4 x11mono xcf xes xpswrite

albert(11.3)[4] grep gsCmdConvPDF /usr/local/{share/gv/gv_system.ad,lib/X11/app-defaults/GV}
/usr/local/share/gv/gv_system.ad:GV.gsCmdConvPDF:       gs -dNOPAUSE -dQUIET -dBATCH -sDEVICE=pswrite -sOutputFile=%s -f %s -c save pop quit
/usr/local/lib/X11/app-defaults/GV:!GV.gsCmdConvPDF:    gs -dNOPAUSE -dQUIET -dBATCH -sDEVICE=pswrite -sOutputFile=%s -f %s -c save pop quit

From file:///usr/local/share/doc/ghostscript/9.27/Devices.htm#PS:
4.2 PS2 writer

The ps2write device outputs postscript language level 2. It is recommnded that this device is used for PostScript output. There is no longer any support for creating PostScript level 1 output.

(I reached the above by selecting the "PostScript file output" link from file:///usr/local/share/doc/ghostscript/9.27/Devices.htm.)

End-user-visible symptoms of the issue:
Attempting to print from gv fails; if the user happens to notice, a message is emitted (to the controlling tty, if there is one), e.g.:
albert(11.3)[19] gv bike.pdf 
Unknown device: pswrite
lpr: No file in print request.

As a circumvention, I tried placing:
! Fix gv conversion from PDF to PostScript
GV.gsCmdConvPDF:                gs -dNOPAUSE -dQUIET -dBATCH -sDEVICE=ps2write -sOutputFile=%s -f %s -c save pop quit

in the file where I keep my personal X11-related resources (~/.Xresources), then running "xrdb -merge ~/.Xresources".  While this no longer generates error messages, and does print the file, I find that the image is slightly offset and (as a result) trimmed (since the printer in question is a laser printer, and has  an "unprintable margin" of about 0.5" or so).  I am not clear on how to address this.

In passing, I note that "info gv" claims (under "(gv)Resources of gv"):
     The command used to convert a PDF file to PostScript.

     It defaults to `gs -dNODISPLAY -dQUIET  -dNOPAUSE -sPSFile=%s %s
     -c quit'

I tried specifying that purported default in ~/.Xresources; it also fails.

It is also possible that gv ought not be attempting to "convert to PostScript" when the invoker wishes to print: apparently generating PostScript has fallen out of fashion, and folks/applications are expected to only use PDF nowadays.
Comment 1 Kubilay Kocak freebsd_committer freebsd_triage 2020-04-18 01:59:56 UTC
^Triage: New maintainer as of ports r531940, request feedback
Comment 2 Marco Beishuizen 2020-04-18 08:48:24 UTC
Got the same problem here. I don't have the solution yet so I need to investigate further.
Comment 3 Marco Beishuizen 2020-04-18 11:18:13 UTC
Solved it here by changing the "Ghostscript Options" in gv a little. In there is an input field for "Convert PDF" that says:

gs -dNOPAUSE -dQUIET -dBATCH -sDEVICE=pswrite -sOutputFile=%s -f %s -c save pop quit

In my case changing the "-sDEVICE=pswrite" to "-sDEVICE=ps2write" makes gv print again.

Does this help?

Comment 4 david 2020-04-18 12:06:44 UTC
Thank you for looking into the issue.

As I noted in the initial report, specifying "ps2write" (instead of "pswrite") does avoid the error and causes printing to occur.

Checking just a couple of minutes ago, the image appears to be printed appropriately -- the previously-reported "offset" issue is not apparent.