Live data from Hacker News

New Ghostscript PDF interpreter

ghostscript.com

11–20 of 98 posts

Re: New Ghostscript PDF interpreter

#11

Given the mention of security issues in their custom PostScript extensions, and that PDF files are often malformed, I wonder why they chose C as the language for the new interpreter. I don't want to write a typical HN comment ( cough use Rust for everything :)) but surely there is _some_ better language for entirely new development of a secure and fast parser in 2022. The post has no explananation of this choice. Doe…

My guess is that since the rest of the project (not in PS itself) is in C, it’s in C. And it may be borrowing from the PS interpreter codebase. I dunno.

Requiring another skillset, toolchain, etc. is onerous and has to be weighed in those decisions. Rust is cool for sure, but difficult to adopt in brownfield projects because of humans more than tech.

Also, it wasn’t written on in 2022, just made the default now. GS is a venerable codebase, and jumping on a “new” language bandwagon may have seemed dangerous at the time it was started.

All conjecture. I’m not an expert or involved.

Re: New Ghostscript PDF interpreter

#12
post #6

Does anyone know much about the Artifex team? How big it is etc? They seem to be the kings of working with PDFs. I’ve not really looked at the Ghostscript code (and I’m surprised to hear their interpreter was still in postscript), but I’ve looked through the mupdf code and what I saw was really nice. In any case, I appreciate the work they’ve done in providing fantastic tools to the world for decades now.

I don't know the current team, but I have met its founder: L. Peter Deutsch [1].

James Gosling, inventor of Java, once described him as the "greatest programmer in the world". They both used to work at Sun Microsystems.

[1] https://en.wikipedia.org/wiki/L._Peter_Deutsch

Re: New Ghostscript PDF interpreter

#13
post #9

Given the mention of security issues in their custom PostScript extensions, and that PDF files are often malformed, I wonder why they chose C as the language for the new interpreter. I don't want to write a typical HN comment ( cough use Rust for everything :)) but surely there is _some_ better language for entirely new development of a secure and fast parser in 2022. The post has no explananation of this choice. Doe…

Beyond a lack of memory safety, C has another issue that makes me dislike it for this kind of application: C has a very minimal set of built in data structures. Combined with a lack of generics, this means that using, say, a dictionary means that quite a bit of the implementation gets hard coded into every site that uses the dictionary. This is almost invariably done with lots of pointers (since C has no better-const…

> this means that using, say, a dictionary means that quite a bit of the implementation gets hard coded into every site that uses the dictionary

I don't understand this part of your comment. There's nothing preventing you from designing a nice well-encapsulated map/dictionary data structure in C and I'm sure there are many many libraries that do just that.

I do agree though that having such basic data structures in the standard library, as modern C++ does, is usually preferable.

Re: New Ghostscript PDF interpreter

#15

Given the mention of security issues in their custom PostScript extensions, and that PDF files are often malformed, I wonder why they chose C as the language for the new interpreter. I don't want to write a typical HN comment ( cough use Rust for everything :)) but surely there is _some_ better language for entirely new development of a secure and fast parser in 2022. The post has no explananation of this choice. Doe…

It looks like it needs to interoperable with the rest of their codebase which was already written in C

> The new PDF interpreter is written entirely in C, but interfaces to the same underlying graphics library as the existing PostScript interpreter. So operations in PDF should render exactly the same as they always have (this is affected slightly by differing numerical accuracy), all the same devices that are currently supported by the Ghostscript family, and any new ones in the future should work seamlessly.

Re: New Ghostscript PDF interpreter

#16

Given the mention of security issues in their custom PostScript extensions, and that PDF files are often malformed, I wonder why they chose C as the language for the new interpreter. I don't want to write a typical HN comment ( cough use Rust for everything :)) but surely there is _some_ better language for entirely new development of a secure and fast parser in 2022. The post has no explananation of this choice. Doe…

One reason may be that they want to build a high level wrapper of that C API, something that is well documented in some languages (i.e. Python)

Re: New Ghostscript PDF interpreter

#17

Given the mention of security issues in their custom PostScript extensions, and that PDF files are often malformed, I wonder why they chose C as the language for the new interpreter. I don't want to write a typical HN comment ( cough use Rust for everything :)) but surely there is _some_ better language for entirely new development of a secure and fast parser in 2022. The post has no explananation of this choice. Doe…

We (Latacora) previously advised clients to encapsulate GhostScript processing in something with a hard security boundary (like a Lambda) and I am not expecting the new implementation to change that.

Re: New Ghostscript PDF interpreter

#19

Given the mention of security issues in their custom PostScript extensions, and that PDF files are often malformed, I wonder why they chose C as the language for the new interpreter. I don't want to write a typical HN comment ( cough use Rust for everything :)) but surely there is _some_ better language for entirely new development of a secure and fast parser in 2022. The post has no explananation of this choice. Doe…

WUFFS seems like a great option for this.

Re: New Ghostscript PDF interpreter

#20

Given the mention of security issues in their custom PostScript extensions, and that PDF files are often malformed, I wonder why they chose C as the language for the new interpreter. I don't want to write a typical HN comment ( cough use Rust for everything :)) but surely there is _some_ better language for entirely new development of a secure and fast parser in 2022. The post has no explananation of this choice. Doe…

It looks like it needs to interoperable with the rest of their codebase which was already written in C > The new PDF interpreter is written entirely in C, but interfaces to the same underlying graphics library as the existing PostScript interpreter. So operations in PDF should render exactly the same as they always have (this is affected slightly by differing numerical accuracy), all the same devices that are current…

That is not an argument at least for rust since its super easy to consume and offer a C interface. I think it's more of a shift in mentality that needs to occur.
Post reply on HN