Arch Linux

All drivers are enabled in the PKGBUILD. Please try the gsx binary.

Thanks, gsx shows the ps file and works as expected. This resolves the issue. The behaviour is still different from Ubuntu where gs and gsx both open the X11 window. Also curiously `gsx -h` output is the same as `gs -h` and in particular does not show x11 as an available driver, but it works.

Another related problem I have is that the `gv` command displays an empty page with 100% cpu usage indefinitely on the same ps file which works with bare gsx. The gv interface is responsive but top shows gv using 100% cpu and the pages are blank. Do you advise creating a new issue against the gv package? It is currently orphaned, but the version is up to date.

> creating a new issue against the gv package?

Being orphaned it'll probably just gather dust. But if you report it upstream, propose a fix, etc, it might have a chance.

So it turns out there is a problem with the package, and gv is fine. I was able to enable the X11 drivers in gs and after rebuilding from source gv now displays PS files correctly.

> it turns out there is a problem with the package

And that is? C'mon...the suspense!

Sorry for the suspense! I posted that comment in the reopen box and then it wouldn't let me comment further till the issue was reopened, and then it was night :)

This time for testing I build ghostpdl from source (the same source file used by the ghostscript package) with just the --with-x option to configure. The resulting gs binary shows the x11 driver and gv works when I change the interpreter (in gv options) to point to my locally built version. For comparison, I build gs from the PKGBUILD and the resultant gs is missing the x11 driver. In this case neither gs nor gsx makes gv happy.

So, it appears that something in the PKGBUILD disables the x11 driver. Note that the "x11 driver" is needed for some functionality like gv integration, and not merely for opening a window. Please let me know if any further details are necessary. My system is fully up to date with X11 headers and libs installed. Thanks!

I debugged and straced gv and the reason it hangs is because its invocation of gs (as `gs -sDEVICE=x11`) exits with an error and results in a zombie gs child, and gv then loops forever trying to read data from the dead child gs.

Ok thanks, that's good info. Let's see if the PM has some thoughts on the issue.

The package is actually built --with-x option enabled but it seems to get lost where we remove the statically linked and probably
working gs binary and replace it with a symlink to gsc.

Please try 10.0.0-2 in testing repo.
(Check https://bugs.ghostscript.com/show_bug.cgi?id=705895 for the related culprint)

Thanks very much for the quick fix. My latex paper-writing workflow on Arch depends on this working. I'll report back ASAP.

Hi, it seems the x11 device is still missing. I get an error when I run gs:

$ /usr/bin/gs -sDEVICE=x11
GPL Ghostscript 10.0.0 (2022-09-21)
Copyright (C) 2022 Artifex Software, Inc. All rights reserved.
This software is supplied under the GNU AGPLv3 and comes with NO WARRANTY:
see the file COPYING for details.
Unknown device: x11

I see that the PKGBUILD has dropped the `--enable-dynamic` flag so not sure what the issue is. My local test build from source (directly, not using the PKGBUILD) still works.

Here for me it works starting it this way with pkg version 10.0.0-2

/usr/bin/gs -sDEVICE=x11
GPL Ghostscript 10.0.0 (2022-09-21)
Copyright (C) 2022 Artifex Software, Inc. All rights reserved.
This software is supplied under the GNU AGPLv3 and comes with NO WARRANTY:
see the file COPYING for details.

and some white X11 window pops up.

and this also seems to work here:

andyrtr@workstation64:[~]$ gs -h | grep -i x11
Default output device: x11alpha
tiffsep1 txtwrite uniprint urf x11 x11alpha x11cmyk x11cmyk2 x11cmyk4
x11cmyk8 x11gray2 x11gray4 x11mono x11rg16x x11rg32x xcf xes xpswrite

My mistake. I inadvertently used the wrong version of gs. The new package version in testing works and shows the x11 device.