PostScript’s sudden death in Sonoma | Hacker News Reader

PostScript’s sudden death in Sonoma

eclecticlight.co

269 pointshomarp151 comments

They probably want to eliminate an attack vector. Removing PostScript support from WebKit/Safari seems like the right decision in light of PostScript’s waning relevance as a publishing format.

Not sure about EPS - last I used it was for vector graphics within LaTeX documents. That was in the early 2000s.

I am sure that applications targeting designers will integrate alternatives like Ghostscript soon enough.

> Not sure about EPS - last I used it was for vector graphics within LaTeX documents. That was in the early 2000s.

People really should use pdflatex at the very least now. The original latex has too many issues and quirks.

pdflatex doesn't really help here. pdflatex allows you to bypass dvi, the native TeX output format. The input for latex may well still include eps image files though.

True. Of course you can still use EPS, you just have to find another program to view them in. And isn’t there a tool in most TeX pakages that can convert it to PDF, then you should be able to use that at as an input if it makes it easier?

I used to use PDF because you could easily export them from Illustrator and suck them straight in to xelatex or pdflatex (but this was years ago, so I can’t remember all the specifics)

With pdflatex you can also directly use pdf files for things like figures, whilst standard latex requires postscript files.

At least it was the case when it mattered to me, now I mostly moved to LuaLaTeX anyway for other reasons.

When I was in academia, I was among the first in our department that moved from latex to pdflatex. One of my motivations was that (E)PS files could be huge, particularly for bitmap graphics, whereas pdflatex supports PNG and JPEG as well as compression of PDF itself. That helped a lot when disk quotas at the time were very limited.

I disagree, there are at least 2 reasons why eps can be better. a) you can exactly match the fonts in an eps figure to a latex file, which will look much better. b) you can use \psfrag to change text to get proper mathematics in figures, like gamma2 in an eps becomes $\gamma^2$ c) maybe also, the pstricks package is very nice, but does not work with pdflatex if pdflatex could do both, I would switch today but

Good points.

An attack vector, or a vector attack?

Attack vector (https://en.m.wikipedia.org/wiki/Attack_vector)

I think it was a joke.

Vector (https://en.wikipedia.org/wiki/Vector_graphics) attack!

A vector attack vector.

Roger, Roger.

Git clearance, Clarence.

Security was Microsoft’s stated reason for a similar change in 2017, when they removed the ability to insert EPS images into Microsoft Office documents:

https://support.microsoft.com/en-us/office/support-for-eps-i...

EPS is definitely still in semi-common use in the graphic design & printing industry. It has been replaced by PDF as an export and interchange format but you will still come across tons of (legacy) EPS logos and assets from companies that get included in documents all the time. But generally you would be using Adobe’s stuff for this work, so OS-level support is less important.

I recently retooled a corporate document pipeline to use FPDF.

This library doesn't natively support anything other than PNG, but there is a small superclass that has been contributed to add EPS functionality.

I actually pulled an SVG copy of the required corporate logos and converted them to EPS with Inkscape. Oddly, I had to save them upside-down, then edit the comments in the preamble to more closely match Adobe Illustrator before they would render properly.

I also tried TCPDF, but I found odd reliability problems.

RIP PostScript. (Not to be confused with PostScript RIP.)

This is perfect. Not a single wasted syllable.

Oh, do I share the fun with those without grey hair...

RIP = Raster Image Processor, often a standalone computer acting as a front-end for a printer. It accepts jobs, runs the PostScript, and converts it to a format native to the printer.

At some point, it has to render a bitmap. Conceptually simple, but the frame buffer is going to be multiple megabytes.

When PostScript was young, megabytes of RAM could require thousands of dollars.

The CPU running PostScript was itself a rather powerful machine for the time.

And then, the software license for the PostScript running on the RIP...

I ran a network of 200 Macs, and for a number of years, the most powerful computer on that network was the printer.

I have an sgi o2 that was originally the RIP for some sort of fancy print system. Which blew my mind. I mean sure the o2 was sort of the low end system of it's generation. But that is still a 10-20 thousand dollar computer. And you are wasting it on the infernal print queue.

I sort of get it now, it's 1996, you have a million dollar printer, you want to make sure the computer assigned to handle the images can keep up with it, the o2 is probably a good fit.

The other fun fact about the o2 is apparently the oil companies liked it. It is a unified memory architecture. On the one hand this means it's graphics were far slower than it's big brother, the octane, On the other the octane has at most 16 megabytes of video memory. you could get close to a gigabyte of memory in the o2 and and you could use as much of that for video memory as you could get away with. Great for those large geological survey visualizations.

I wondered if I were remembering correctly: an SGI O2 RIP for a huge HP inkjet poster printer.

An advertising agency had such a setup for in-house production. 1998.

At work, we still have EFI Fiery RIPs that feed huge color Konica Minolta digital printers.

Those bastards! What ever will I do with my HP LaserJet 4 PostScript cartridge? It was perfectly usable!

Apple is removing a number of scripting environments from OS X, so they won't have to maintain them.

Not sure if they can remove Perl; it's tangled up in standard C libraries I think, and would be hard to kill.

> Not sure if they can remove Perl; it's tangled up in standard C libraries I think

Indeed.

    char *cmd = "/usr/bin/perl -e 'print join(chr(0), @ARGV), chr(0)' -- ";

(https://github.com/Apple-FOSS-Mirror/Libc/blob/2ca2ae7464771...)

That’s to implement wordexp, a POSIX function that probably is best avoided unless you really really need it.

I think the sanest implementation would move lots of code from the shell into the standard C library, but that probably has its own problems, as FreeBSD does something similar. https://man.freebsd.org/cgi/man.cgi?query=wordexp&apropos=0&...:

”IMPLEMENTATION NOTES

The wordexp() function is implemented using the undocumented freebsd_wordexp shell built-in command.”

OpenBSD actually has the sanest approach. “The only winning move is not to play.” or, in Theo’s words, “I think we should stand up to crap and not ever impliment it” (https://www.mail-archive.com/tech@openbsd.org/msg02325.html)

This is probably a nice project to throw to a team at Apple that wants to ship something in Rust. Many years ago, you had to write the C library in C, but those days are over, and doing a bunch of string processing doesn't sound that fun. (If the code's already written, sure, keep it. But if you're writing brand new code to replace Perl oneliners, there are probably a lot of fun bugs you're going to add with a C rewrite.)

The problem is not the doing it in C, but the precisely matching the behavior of some existing code.

I wonder how hard it is to just compile the perl (as a library from the perl codebase) vs calling the executable

It seems that's a decent middle ground unless there's not a good API on the perl side

Yup, absolutely. My take is that because you get to do something fun (start from scratch in a good language), the thousands of test cases you have to write and then run against the old implementation doesn't feel so bad. (I have to imagine a good amount of mailing list archeology will also be required. "How did Linux mess this up in 1992?" etc.)

Apple have chosen to go all in on Swift for their first-party code, from the kernel to the libraries to the apps. Even things running on microcontrollers (but there’s no official or standard embedded Swift subset yet).

It’s quite interesting actually that they’ve very intentionally focused on building two-way transition layers so they can start gradually integrating Swift into codebases built in C and Objective-C, and recently new support for C++ and Objective-C++. Which is the best way to do it, big rewrites are the worst, after years of effort you often have a replacement with fewer features than the old one! So being able to replace little bits at a time and write new features in a new language is cool.

See this talk for the details on that - https://youtube.com/watch?v=lgivCGdmFrw

So don’t expect to see any Rust code from Apple, although of course they might ship third party things written in it at some point.

They are definitely working a long term plan. The development apple has been doing with identity since they bought NeXT is very sophisticated. I think they are about to make a major push that will put their ecosystem at another level.

Interestingly the entire NextStep UI was built on a graphics format called Display Postscript when Apple acquired it as the foundation of OS X

https://en.m.wikipedia.org/wiki/Display_PostScript

an idea that NeXT copied from Sun Microsystems NeWS

Is there a citation for that? I thought Adobe built this with NeXT separately but clearly Adobe would know of NeWS too.

Here's a comment from 2016 that quotes technical discussions from 1988. It is clear that the Display Postscript implementers had detailed knowledge of NeWS.

"In a few cases they picked the same names and operator spec as us, but in general they didn't try to be compatible. A few incompatibilities seem gratuitious to me."

https://news.ycombinator.com/item?id=11520455

That’s interesting; thanks.

The other thing that Apple did while developing OSX was to replace Display PostScript with an in-house implementation of Adobe's open PDF specification.

https://en.wikipedia.org/wiki/Quartz_2D

Beacuse Apple and Adobe could not agree on licensing costs.

I think it had just as much to do with adding a better compositing layer. That was when suddenly the GUI had a third dimension.

> I’m now starting to see warnings from third-party app developers that, in Sonoma, their apps will be unable to open or import EPS files, for example, as they can no longer convert them using Quartz in macOS 14. Although the impact on most of us should be very small or negligible, if you do still use EPS or PostScript at any scale, you will need to prepare a solution for continuing to do so after upgrading to Sonoma. I wish you success.

I work with dozens of graphic designers and am quite certain that zero (0) of them know this is coming.

Do they actually deliver PS/EPS though? Based on industry standards I'm kind of assuming they all work with AI/PDF, and maybe SVG (but that's pretty specific to web rather than graphics design in general) if they're working with vector deliverables. I can't remember the last time I heard of someone voluntarily exporting to PS (and certainly not ever since PDF became an ISO standard 15 years ago)

I get asked "what format do you want this in, EPS?" maybe a couple times a year.

Some day I'd like to write a blog post about the peculiar relationship between designers/artists and technology… as a whole they seem to have an awful time moving on from the tools they were trained with.

anecdote — I was chatting with one of the most famous book cover designers in the world a few years back, he was still using Quark X-Press 4 on a Mac that ran OS X with "Rosetta" (10.6?). These people are real and are the whole reason why Adobe.

I don't think it's a training isuse. It's a "if something goes wrong with the output, it's my neck on the chopping block" issue.

There is vanishingly little value in deviating from a known-good workflow until you have a good reason to.

There's also a significant chunk of "I need to be able to open the back catalogue of customer artwork without worrying about whether something's shifted slightly." Import filters for opening legacy formats in newer software can be notoriously bad in that regard.

No, I completely disagree. The guy from that anecdote, he's a vice president of one of the largest publishers in America. Nobody's gonna say no to him. And most designers I know are independents.

Do you know the restaurant industry term mis en place? It's this practice of laying out your tools at the beginning of your work shift, so you can grab the knife or the salt or the mixing bowl without even looking. Disrupting a chef's mis en place is an great way to get stabbed.

An even modestly talented graphic designer doesn't look at their keyboard or desktop at all while they're working, they exhibit fantastic amounts of muscle memory while navigating their various screens and palettes.

They also suffer from an unfortunate lack of neural plasticity. There is no room in their day or desire for picking up new techniques, they're way more interested in the ideas they're absorbed with.

Creative people suffer from a lack of neural plasticity? Interesting…

I think neural plasticity is better allocated to the niche specific ideas they're working with than to re-learn the UX/UI some Product Manager looking for a bonus or raise or whatever, thought a good idea.

I've had to disable the new bubbles download from chrome in so many places already, even my fucking dentist couldn't produce a recipe because they couldn't find the new UI.

professionals like their tools to be reliable and not at the whims of capital greedy corps.

> They also suffer from an unfortunate lack of neural plasticity. There is no room in their day or desire for picking up new techniques, they're way more interested in the ideas they're absorbed with.

Don't confuse "lack of neural plasticity" with lack of tolerance for tech industry's bullshit. They most likely have a strong case to make that those updates are unnecessary, and likely making a perfectly fine workflow worse. Computers, in general, have been getting increasingly less ergonomic and less functional over time, and the decrease in ergonomics affects even the most specialized software aimed at professionals.

I get that, but it cuts both ways.

The whole "Adobe CC" thing is also tech industry bullshit, and it is far beyond many designers to even take modest steps to update their skillset.

I sometimes work with one graphic designer who delivers web design in PDFs built in Adobe InDesign and expects everything to be pixel-perfect. It's madness.

Printing is in this department too.

I have a friend who makes automotive decals, and he got a new (to him) large format Epson printer last year. The seller included a circa 2014 Mac Mini which has all the software installed and setup for the printer, as apparently it's painful to setup and doesn't work well with Windows.

And the friend uses CorelDRAW for making designs. When he first told me I didn't believe him that it is still around :D

Someone needs to do a "what computer scientists don't know about color" article.

Like, in CYMK is black <0,0,0,1> or <1,1,1,1>? Depends.

Is this a graphics designers' equivalent to the difference between 0 and -0?

No, on actual paper one is darker and more saturated than the other. Unlike RGB, CMYK is subtractive, so “all of everything” gives you black, not white.

https://www.rightbydelzer.com/standard-black-vs-rich-black

Digitally these should be equivalent. Physically, I'd assume it's just as likely that adding CMY pigments would dilute the K and make it less purely black - but, per link you shared, it seems it's the opposite, and I didn't even realize this is an actual technique. Thanks for posting!

They aren’t using water based ogments. Dilution isn’t a thing.

<1,1,1,1> exceeds the ink-limit, try <.4,.4,.4,1>

paper documents haven't significantly changed in the past forty years. consider eps feature complete

EPS is a vector format that I know any design-related computer from the last 20 years can open. If you’re giving a file to an unknown party through an intermediary, like for a printer, vinyl cut, etc, I don’t see why not use it. It’s never once been a problem.

Usually I provide art in EPS, PDF, and JPEG/PNG, since one of the 3 works for almost any use.

We are "technologists" and love technology. We love to argue about new features, shortcuts, new file formats etc. Artists want the tools out of the way, they are thinking about art and the end result. They will use a 50-year-old computer if they are productive at it and gets them the results they want quickly. In fact, doesn't George R R Martin use Wordstar for DOS or something like that?

People who actually use software to get work done tend to hate changes. A UI redesign means a lot of wasted time and lost money. A feature that goes away means that muscle memory is invalidated, generally for no measurable gain.

This was more relevant before CC but I still tend to include EPS in exports as a fallback option.

Absolutely. The standard for printing banners / logos on tables etc. at trade conferences is definitely still EPS, from my experience coordinating with conference planners in the last 3 years.

Presumably those print shops have a Photoshop license, which would mean they're unaffected by this.

It's about interoperability. Many more apps import and/or export EPS than proprietary AI. and many of them did it using built-in macOS means.

In this sense EPS is more like SVG, but print friendly and less prone to misinterpreting

> I can't remember the last time I heard of someone voluntarily exporting to PS

you'd be amazed at what people will do. i did the initial layout for a company's product labels in Illustrator with all files saved as *ai files. after the hand off, the person taking over the tasks ran into issues. they had no idea how to use Illustrator, and re-did the entire layout in Photoshop. when you only have a hammer, everything looks like a nail.

so i can see someone trying to export as EPS because "it's vector" from something like photoshop.

Until recently I was using PostScript and EPS regularly. I'd use a PostScript program to step-and-repeat EPS artwork for a business form or raffle ticket, and apply consecutive numbers in the appropriate place. I'd then use GhostScript to render a final multi-page PDF for printing. I also used it to send artwork to an imagesetter. Yes, they're still used in some sectors, and while the RIP software we had supported PDF, I had much better control of the machine using PostScript with a PPD.

Well I exported to ps this morning, since I used the pstricks package in latex.

It is the best way I have seen to make diagrams with code, which can be very convenient.

so python takes instrument data and writes latex with pstricks, then to ps to pdf/svg/png/* to insert into whatever doc my colleagues are making

We are continually evaluating alternatives as latex is a heavy dependency, but nothing works as well, yet.

and even more importantly it has worked for 10 years and likely will work for the next 50 years with exactly the same code.

I have worked in graphic design for nearly 20 years, and I doubt anyone will actually miss this at scale.

If you're working with EPS, you are working in specific non-Apple applications that work with EPS. You're in InDesign or Illustrator, neither of which use the system libraries for EPS parsing.

I have EPS files from 25 years ago that I still want to be able to open, these old graphics that help me remember my dad, a graphic designer. This sucks.

I don't think Ghostscript is going anywhere. You should be able to use it

Is anything stopping you from converting them to PDF?

Just that until now I didn't realize I would need to.

Why? Just install ghostscript, works fine?

I looked just now and I actually have an EPS of something I drew on a mac SE in 1993. It's amazing how if you can manage not to lose all your files over time, they become an archaeology site documenting long stretches of your life.

See Ghostgum

http://www.ghostgum.com.au/

Wow. That’s amazing. I have a bunch of Hollerith punched cards from my dad. I guess my kids will have a bunch of jpeg files from me…

There are many graphics editors that still support eps (Illustrator, Affinity stuff, Inkscape); the format is well described and as it basically does not move anymore, the existing convertors will work, like ghostscript (although the Affero GPL is annoying but thats not for this discussion)

It’s much better than to have docx or photoshop.

It’s just removed from the base OS for probably both licensing and security reasons.

I bought Affinity Designer because I updated my Mac and Adobe CS6 (which I used Illustrator from) no longer worked.

It’s really great, if you do that kind of thing I second it for sure.

Seconded.

Between Pixelmator and Affinity Designer I've officially kicked Adobe to the curb.

For this type of "still use an old thing" it's easier to setup an emulator/VM imo. It's not native but you don't have to worry about small quirks/bugs/changes over the years.

For things sufficiently old that copyright/licensing isn't an issue, sometimes you can just download a ready built machine.

I mean… no offense man but if you were relying on built-in support in an operating system to access stuff, that was never going to pan out long term. You should find software to open and convert those to something more accessible now, before it becomes even more challenging.

I've still got PCX and BMP files I drew as a kid in the 80s that work fine in every major OS

Until support is removed for the crime of being "too old".

Digital archival support rot marches on and formats will die for lack documentation and usable converters.

You can still open them in a graphics editor but cannot preview them in the OS.

I was really shocked when I found that Preview in Ventura would no longer open PS and EPS files a small but annoying reduction in quality of life for me

when preview stopped opening video files that had a codec other than ProRes or H.264, it just felt broken to me as well. for the longest time, one of the first things i'd add to any new OS install were the QT extensions of the other codecs. now, that's no longer supported.

I've heard QuickTime extensions will come back in Sonoma

Do this no longer work? https://github.com/sindresorhus/quick-look-plugins

https://github.com/Marginal/QLVideo

This is very unfortunate. I've always found it annoying how Mac OS' Preview.app "natively" supports PostScript but will stubbornly convert it to a PDF and delete the original PS file.

I do not have concrete statistics to back this up, but in my experience, a gzipped PostScript documentat is often smaller than an equivalent PDF, and unlike PDF, it's marginally easier to edit by hand after decompressing. Also, the PDFs created by Quartz PDFContext is often needlessly large and tools like pdftk have been able to losslessly compress them, whereas Quartz' own compression filter seems like the equivalent of JPEG compression at quality 0.

The only practical advantage of PDF to me is the presence of an alpha channel, but that is basically it. With that said, PostScript documents themselves being a sort of program has always been a security nightmare for some, so I understand the removal on Apple's side. During the OS X Tiger days, I recall a simple infinite loop in PS could've stalled Preview's PS-to-PDF converter. Being able to properly sandbox PS seems like too much effort at this point given the ubiquity of PDF.

> Mac OS' Preview.app "natively" supports PostScript but will stubbornly convert it to a PDF and delete the original PS file

A "preVIEW" app that DELETES a file is an abomination that only Apple could ever get away with.

> ...tools like pdftk have been able to losslessly compress them...

I have had good luck with pdfsizeopt.

https://github.com/pts/pdfsizeopt

One would think that Apple should be able to sandbox Preview to maintain functionality whilst avoiding security issues.

Mac's native handling of PS has always been a slick differentiator -- seems a shame to throw that away.

Sandboxing makes a lot of sense — perhaps virtualizing older macOS versions could give people what they need.

Yet there is Ghostscript, which could also be run in a VM for extra security. It's a tool I still need in order to keep from distributing licensed fonts in PDFs — turning a PDF into PS, then back into a PDF, is a handy trick.

Haven't played with Ghostscript in ages but will always have a soft spot for it.

That said, using it (in a VM) as a workaround requires more steps and a bit more technical interaction that destroys the original seamless experience. Apple has been aggressive about tightening down the OS (still pissed that strace is neutered by default); taking the security approach of just not doing the work at all is really lame on their part.

Theoretically they provide the ability to do just what I'm suggesting: https://developer.apple.com/documentation/xcode/configuring-...

Well I guess they learned from Microsoft's mistakes and are lowering their exposure while their Mac install base is still low enough?

It is getting ridiculous that I have to run multiple VMs for accessing old programs and data; but then at least I should be grateful we have functioning VMs?

Most likely an analysis of cost vs benefits resulted in a decision for deprecation first and removal later

I was thinking that a quick web app to convert your old EPS file might be a good way to execute the code in a sandbox. I don't know if we can get ghostscript to run in WASM

If there's one thing infosec types universally do not trust to improve security, it's sandboxing. Just look at all the discourse spilled over the recent WebP vulnerability.

Is suspect Apple’s experience with Blastdoor[1] has made them unwilling to go that route.

Blastdoor is meant to provide a secure sandbox for processing images and other data that arrives in iMessages. Puts all the potentially dangerous format decoders in a little box, and viciously kills anything that starts behaving odd when passed something to process. It certainly improved iOS security, but also quickly proved to be less than bulletproof, mostly due to just how much freedom older image formats provide.

Ultimately code that isn’t in the OS can’t be exploited. Images decoders have a long history of being exploit vectors that are very hard to close. At a certain point simply not shipping them is the best course of action, doesn’t prevent people from adding them later, but at least only those who need the functionality are in the firing line (which reduces the incentive for exploiting those formats, and indirectly ends up providing further protection to those that need to work with the formats).

[1] https://www.macrumors.com/2021/01/28/messages-blastdoor-ios-...

Preview has already been sandboxed for years.

I was thinking of that around the "stack-based interpreted language" paragraph. Mozilla's RLBox/wasm2c approach would be good for this, for example. Postscript can still mix data and code, but it won't jump outside of the sandbox, and the rest of the program treats its output as untrusted.

https://hacks.mozilla.org/2021/12/webassembly-and-back-again...

If I remember, PostScript had a fairly eye-watering licensing fee.

I know that it added a great deal to the price of printers, if I got them with actual (as opposed to emulated) PS.

Was it only the license fees or the fact that (for the time at least) it required powerful hardware ?

For example, if memory serves me right, at the time of the introduction the LaserWriter had a more powerful cpu than the Mac that it was supposed to go with.

The original Apple LaserWriter had a Motorola 68000 CPU running at 12 MHz, 512 KB of workspace RAM, and a 1 MB frame buffer. That wasn't cheap, but Adobe's pricing of the PostScript license was still very steep and contributed significantly to the high printer costs. Adobe's greed over licensing fees caused serious conflicts between Apple and Adobe.

To give people an idea: that's 3x the RAM and about 2x the CPU power of the contemporary Macintosh (512k of ram (not expandable), and a 7.8MHz).

It wasn't until the Macintosh II came out that there was a mac that was strictly more powerful than the LaserWriter, and by then the LaserWriter IINTX was available; similar CPU to the Mac II, but more base memory and could be expanded to more total memory.

Yes, until about 1995, a new laser printer could have a more powerful CPU and more RAM than a fairly common (even new) office computer driving it. That stopped at about Pentium 100 speed and 6 MB of RAM because normal use cases didn't need more than that.

PostScript is also deprecated in PDF 2.0.

What does this mean? Did the PDF standard include all of PostScript as part of it (I thought PDF was more like a subset?) or did it allow (but no longer allows) embedding PostScript objects?

Yes, parts (or all) of a PDF page could be expressed in PostScript as special objects. The separate (from PostScript) regular drawing primitives of PDF are inspired by PostScript, but those only form a sub-language within the PDF format, which adds enveloping structures and many other features.

I don't use macOS so am unaffected, although I would think that they shouldn't need to support PostScript in the Preview. PostScript is not that good format for publishing and documents anyways (for, among other reasons, security), but it is good as a programming language.

I still do often use PostScript, but I have Ghostscript and the graphical output of the program (if it has any; some of them don't) can be made in many file formats, including PNG, PDF, PCL, etc (it doesn't have SVG output, although that might be helpful if you are making diagrams).

(There are some features I think would be good to add into PostScript, such as alpha transparency, auto-allocation (by specifying null where the object is expected; this is most useful for readline, in case you do not know the length of the input), a "unread" operator (like ungetc in C), being able to specify encodings separately from fonts, and others. Some features are in Ghostscript and are good to have, such as ARGUMENTS and %pipe%, and I do commonly use ARGUMENTS.)

(PDF isn't good either though, but at least it is a format for publishing and documents, despite its problems.)

Seems like PostScript is too powerful for the security conscious world. This is probably a good move. It's unfortunate though, I liked PostScript and all the stuff you can do with it[1].

What's the new standard for vector graphics going forward? SVG? glTF?

[1] For example: https://uguu.org/src_udonge_ps.html

PDF is the obvious successor. Though there are some things you can do with PS you can't do with PDF, because PDF AFAIU isn't a Turing complete language (though newer versions of PDF allow embedding of Javascript, IIRC).

> (though newer versions of PDF allow embedding of Javascript, IIRC)

Which comes with its own security issues/problems, especially since adobe is the leading figure of pdf viewing/processing. PDF 2.0 removed a lot of old crap, like xfa… and postscript but they kept JavaScript

Sometimes I remember the way MIDI file playback disappeared from QuickTime, and then QuickTime itself disappeared.

I'm not even sure when it happened.

Last I tried I could still load them into GarageBand, but that app by itself is clunky and slow and 10x the size of the entire hard drive I was using back in the day, and the sound fonts feel all wrong anyway.

Postscript is really easy to generate from shell scripts; I wrote a little thing that did labels for our (physical books) library.

Not sure what I'd use for alternative. I'm sure there are many little modules that would help. Or I could just install Postscript. But it's nice to have things with fewer dependencies.

SVG?

SVG would be the 21st century PostScript, yes.

But...

Output of SVG in actual print can be quite unpredictable. Of course, I'd stick to a particular implementation, and just aim for it to come out right. Should be pretty simple.

Back when XML was the only way to go, there was a page-description language built on top. And it ultimately generates... PDF!

https://en.m.wikipedia.org/wiki/XSL_Formatting_Objects

XSL-FO was a good idea, but it never went anywhere. Processors were costly and underfeatured, HTML+CSS ran circles around it. IIRC, XSL-FO didn't even have floats for a long time!

It's a pity that there appears to be little interest for page-oriented features of CSS: breaks, headers, footers, numbering, etc. Most don't work well or at all.

If you want to convert a postscript file (or .eps) to PDF you can use ImageMagick:

  convert -density 300 input.ps -quality 100 output.pdf

If you're interested in this kind of thing, I packaged a lot of functionality (including zip files) into an open source doc viewer called "chai" (that also works on mac, install deps via brew).

Please note its focus is on security rather than looks so it converts docs to page images that you then view in (an optionally local) web client.

You can easily modify the convert process to move it to PDF rather than page images tho. Check it out: https://github.com/dosyago/chai

At a quick glance that looks like it will rasterize the vectors, which is usually not what you want to do with an EPS.

Good point! I will investigate that, even it's not relevant to my chai app I think it's interesting and worthwhile to know if the convert command will do that!

edit: ChatGPT thinks you might be right! It also says: If you specifically need to maintain the vector properties of the EPS file when converting to PDF, you might want to use a tool designed to work with vector formats, such as epstopdf, which is a utility that comes with most TeX distributions.

TCPDF has full support for rendering an EPS into a PDF.

It can be fussy.

https://tcpdf.org/

Terrible and sad!

I've come across issues on my Linux machine too. Gnome's Evince Document Viewer will display a Postscript file just fine, but printing just produces blank pages. Maybe it's a printer issue? But I have tried different printers.

I use Postscript to generate labels. Much lighter weight than TeX and way easier to code than PDF. But now I have to convert them to PDF in order to print.

Apple should be more open about their removals. It isn't clear how this affects their CUPS implementation or PostScript printers https://github.com/apple/cups

About time. PDF has been a superior ad better supported alternative for over two decades. That some people still rely on this flawed thirty year old software is puzzling to me.

Hmm... I wonder if this is this why opening man pages with Preview suddenly stopped working in Monterey while ago?

I just opened a tax return document in pdf format and it looked fine but printed garbled text. That’s not what this is, right? The file wasn’t encrypted either.

For reference, PS support for Preview was removed in Ventura.

I asked mobile ChatGPT (free version) about rewriting PostScript in Rust. It indicated it would be a complex project, gave an overview and indicated it did not have access to the PostScript documentation (for some reason).

The reaction to this is as if every computer on the planet is losing the ability to open with PS/EPS. PS/EPS were not native MacOS files until the infusion of NeXTSTEP code into MacOS in the form of OS X.

I've lived in a mixed system world for a long time, opening PS/EPS on Windows has always required extra software. You can convert it on Linux easy enough, or just install Ghostscript on MacOS.

Either way, the time of PS/EPS as a regular and common interchange data format is long gone.

It’s in the very first paragraph of the article:

> If there’s one language that’s been at the heart of the Macintosh for the last 39 years it’s PostScript, the page description language developed by the founders of Adobe, the late John Warnock and Charles Geschke, and their team of engineers. It brought the Mac’s first commercial success in desktop publishing, in PostScript fonts, and early PostScript printers including Apple’s game-changing LaserWriter. Although Mac OS X never inherited NeXTStep’s Display PostScript, its descendant Quartz and Core Graphics are still based on PostScript’s relative PDF.

> PS/EPS were not native MacOS files until the infusion of NeXTSTEP code into MacOS in the form of OS X.

I agree it’s probably not a big deal, but let’s be fair here. That was 22 years ago. Classic MacOS was only around for 17 (1984-2001).

It’s a native format for macOS starting in 10.0 and prior to that an extra native format for NeXT starting in 1989 - when the macOS lineage began (note the lowercase ‘m’)

> It’s a native format for macOS

NextStep licensed Adobe's Display PostScript for it's graphics subsystem, but when MacOS was developed Apple replaced Display PostScript with an in house implementation of the open PDF spec that they called Quartz 2D.

> Quartz 2D is available to all macOS and iOS application environments and provides resolution-independent and device-independent rendering of bitmap graphics, text, and vectors both on-screen and in preparation for printing.

The drawing model utilized by Quartz 2D is based on PDF specification 1.4.

https://en.wikipedia.org/wiki/Quartz_2D

So now both Adobe and Apple have dropped PostScript in favor of PDF.

I jokingly thought the .ps format was used by computer science departments to punish Windows users, with the Ghostscript installation process being part of that conspiracy.

Adobe itself has deprecated PostScript in favor of it's PDF implementation, and has removed support for True Type and Type 1 Postscript fonts from their products.

Fixed, thanks.

(deprecated)

> (deprecated)

The font support?

It was depreciated a couple of years ago and has been removed from current versions of the software as of this year.

> As announced in January 2021, support for all Type 1 fonts in Adobe products is ended after January 2023. Users no longer have the ability to author content using Type 1 fonts in updated Adobe products.

Adobe software will not recognize the presence of Type 1 fonts, even if you have Type 1 fonts installed in your desktop operating system:

https://helpx.adobe.com/fonts/kb/postscript-type-1-fonts-end...

It's the end of an era.

depreciated != deprecated

I think they were correcting the spelling from depreciated to deprecated

depreciation is what happens to you car. deprecation is what happens to file formats.

True, unless Adobe considers PS support to be a fixed asset

Type 1 fonts are still supported on macOS though.

Apple seems on a quest to make macOS less useful (removing unix languages, format support) in the hope that it will make it more secure and mantainable.

I don't think the trade-offs are worth it.

The enshitification of "progress" marches on under unquestioned faith that "newer is always better". And someone got impact credit on their next performance review for taking away functionality. Plus, Apple never listens to users.. they know it all and know better.

> in the hope that it will make it more secure and mantainable.

Or rather in the certainty that it will require less experienced manpower, i.e. will be cheaper.

Reply on news.ycombinator.com