Convert PostScript to PDF locally

There are numerous websites that will let you upload a PostScript (.ps) file and download it as a PDF. Some of these online file format conversion sites look sketchy, and the ones that seem more reputable don’t always do a good job.

If you want to convert PostScript to PDF locally, I’d suggest trying the Ghostscript utility ps2pdf. I’ve had good luck with it.

To convert the file to the file output.pdf you simply say

    ps2pdf output.pdf

If ps2pdf is not installed on your computer, you can run

    sudo apt install ghostscript

on Linux.

Windows installation

On Windows, you can install Ghostscript by first installing WSL then using the command above.

I’m half joking. That advice sounds like something the stereotypical arrogant Unix user would say: the way to run software on Windows is to first install Linux, then run the software in Linux. You can install a Windows port of Ghostscript directly on Windows.


But in all seriousness, I’ve used Windows ports of Unix-first software for a long time with mixed success. Sometimes the ports work seamlessly, but often they fail or half work. I find it less frustrating to use WSL (Windows Subsystem for Linux) to run software on Windows that was first written for Unix.

WSL is not a virtual machine per se but an implementation of Linux using the Windows API. It starts up quickly, and it’s well integrated with Windows. I have no complaints with it.

Related posts

One thought on “Convert PostScript to PDF locally

  1. While the original WSL (now called WSL1) uses a compatibility layer (much like Cygwin, though truly integrated with the OS), the newer WSL2 (rolling out now) uses a very lightweight VM that runs a Real Linux Kernel. Both WSL versions will be retained and maintained going forward.

    While it may not be part of the initial WSL2 release, it will be possible to switch an installed Linux instance between WSL1 and WSL2 as needs dictate. (It is technically possible under the initial WSL2 release, but doing so is a bit clunky.) Initially, it may be best to use separate installations of a desired Linux distro for WSL1 and WSL2, then configure them for a shared userspace.

    Each WSL version has its advantages and limitations. WSL1 cleanly shares CPU and memory with Windows, while WSL2 needs cores and memory to be partitioned between Windows and Linux (though this limitation may ease with planned Win10 changes).

    An advantage of WSL1 is that all processor and memory resources are dynamically shared between WSL1 and Windows. At the very lowest level, WSL1 tasks *are* Win10 tasks, though this level is below that seen by Windows’ Task Manager.

    The WSL1 adaptation layer doesn’t cover all the Linux kernel APIs, but it covers 99.9% of common use. Pretty much everything “Just Works”.

    I find WSL1 to be very friendly, great for having Linux close at hand without the need for any high-level administration or system partitioning. However, such convenience has costs, and WSL1’s adaptation layer imposes multiple inefficiencies and slowdowns, most notably a high cost for filesystem access. WSL2 seeks to eliminate these inefficiencies, though it does impose others.

    The advantages of WSL2 include gaining access to the Linux kernel’s advanced networking capabilities and direct hardware access via Linux device drivers, especially USB devices and disks with non-Win10 filesystems. (Oh, Lord, may I never again have to configure VLANs under Win10. Ugh.)

    One important difference between WSL2 and VMs (like VirtualBox, KVM, Xen, etc.) is that WSL2 uses only Hyper-V, while third-party VMs can use other hypervisors. There likely will still be cases where only a non-Hyper-V VM will do, such as running non-Hyper-V VM images created by others.

    There is also the edge-case of running VMs for dissimilar CPU architectures, such as running an ARM VM on an x86 system, generally facilitated by emulator tools such as QEMU that do not run under Hyper-V. This is often needed by developers to create software for dissimilar hardware that doesn’t yet exist, so the software will be ready for the hardware launch. While such emulators can be run as normal Windows or Linux tasks, speed improves when they can bypass the host OS.

Comments are closed.