Preview Drops Support for PostScript Files
Starting with macOS Ventura, released this week, the built-in Preview app on Mac no longer supports PostScript (.ps) and Encapsulated PostScript (.eps) files, according to a new Apple support document. Preview can still be used to open these files on macOS Monterey and earlier. Apple did not provide a reason for the change.
This is sad, since I have tons of these files. Interestingly, the frameworks still seem to support them, as they still display properly in third-party apps such as EagleFiler and Skim.
Update (2023-02-21): Rob Griffiths:
But this now fails because Preview won’t parse the PostScript file. There are two solutions for this, one that relies on an external package (which is the solution I found), and another using only macOS’ built-in tools (which I found just after finishing this writeup).
10 Comments RSS · Twitter
[…] Michael Tsai recommends two apps: EagleFiler and Skim. Out of the apps listed here, Skim is the most similar to […]
The only reason to do this, it seems to me, is to create a path towards deprecating postscript in the frameworks.
Does Apple have to pay Adobe any kind of licensing fee for Postscript? Are they worried about it as a vector for security attacks?
Microsoft removed EPS support from Office quite a while ago, for state security reasons. I'm guessing this is the first step along those lines for Apple.
As a marketer, I only use EPS rarely anymore. Almost all print workflows are PDF-based, and in my experience Preview struggles with certain types of EPS files anyway. Fewer client proof issues for me!
The notion that a forth _interpreter_ cannot be secured seems pretty ludicrous to me. Just don't implement infile, outfile, etc.
No not infile, but writestring, readstring, etc. Whatever, the point stands: if it's interpreted, it's pretty easy to keep it from doing things you don't want.
There's more to security than writestring and readstring. Remember those old Postscript bombs which would print nonstop solid black pages?
Please, OUG, tell us how to program an operating system to decide whether an untrusted Postscript program is trying to do "things you don't want" with the user's memory and processor.
@Sam I don’t see why it couldn’t be put in a separate sandboxed process with memory and time limits, like they do for Web and iMessage content.
Sure, it’s technically possible, but “run it in a separate sandboxed process” is a fair bit more work than “un-define two functions". And what limits do you set? How long can a loop run until the system starts to think the file is malicious? Is there UI for this? etc.
The rabbit hole gets very deep, very fast, for a feature that 99.99% of users never even knew existed, and for which many free alternatives exist.
Unlike other formats, Postscript is a programming language, and Preview wasn’t designed as a runtime for untrusted programs. I think it would actually make more sense to open Postscript files with Safari.
>Sure, it’s technically possible, but “run it in a separate sandboxed process” is a fair bit more work than “un-define two functions".
Certainly. It's all about priorities — how much effort does this take, and how many will benefit?
(It's also not really _that_ much work with Apple's XPC APIs.)
>And what limits do you set? How long can a loop run until the system starts to think the file is malicious? Is there UI for this? etc.
Sure, but the Safari folks figured that out long ago. I don't know what the limit is, but at some point, Safari suspends or reloads a page if it uses too much energy. You get no control over that; all you get is a little banner at the top informing you. Likewise, Preview could run the sandbox process for ten seconds, and failing that, show an alert instead.
>for which many free alternatives exist.
But that just shifts the security issue to someone else (who may have less budget than Apple to deal with security).
