Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

New Ghostscript PDF interpreter

ghostscript.com

Post reply on HN
Print view View original

21–30 of 98 posts

Re: New Ghostscript PDF interpreter

#21

Post by skemper911 »

petilon wrote: post #12
aidos wrote: 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

Three of the greatest programmers I've experienced worked there, Peter, Tor, Raph. Hats off.

Re: New Ghostscript PDF interpreter

#22

Post by winter_blue »

h2odragon wrote: post #8
vintagedave wrote: post #5

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…

I suspect they need portability more than most projects.

Are you kidding? Many other languages are as portable, if not more portable.[α] Your point would be valid in 1972, not in 2022. I can't believe you're regurgitating the same "portability" from 50 years ago, today (unless you meant it as a joke and forgot to include a /s).

[α] Languages targeting LLVM or supported by GCC are portable to every target machine code / ISA / architecture supported by those toolchains. JVM, JS, etc are portable to all the platforms they support. You don't need to do any extra work (of recompiling) if you use a bytecode VM / platform (for example, like JVM).

Re: New Ghostscript PDF interpreter

#23

Post by [deleted] »

MobiusHorizons wrote: post #15
vintagedave wrote: post #5

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…

[deleted]

Re: New Ghostscript PDF interpreter

#24

Post by vivegi »

In the past when we had to use Ghostscript for PDF processing, we always separated it out into its own process and added a whole lot of error management externally.

Even if the application was fine, you would always encounter PS/PDF files in the wild that kept stress-testing the application's memory safety.

Re: New Ghostscript PDF interpreter

#25

Post by vodou »

vfclists wrote: post #18

Using C sounds like it will bring a whole new list of exploits with it. Not good!!

C is not inherently unsafe. Sure, it hasn't "memory safety" as a feature. But there are loads of applications considered safe written in C. An experienced C programmer (with the help of tooling) can write safe C code. It is not impossible.

Re: New Ghostscript PDF interpreter

#26

Post by MobiusHorizons »

Sytten wrote: post #20
MobiusHorizons wrote: post #15

Earlier quoted context omitted.

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.

while it doesn't prevent rust from being used, it is still a hurdle which must be overcome. Building and maintaining a multi-language build system has significant costs, especially with a project with as much history and wide use as ghostscript.

Re: New Ghostscript PDF interpreter

#27

Post by vfclists »

vodou wrote: post #25
vfclists wrote: post #18

Using C sounds like it will bring a whole new list of exploits with it. Not good!!

C is not inherently unsafe. Sure, it hasn't "memory safety" as a feature. But there are loads of applications considered safe written in C. An experienced C programmer (with the help of tooling) can write safe C code. It is not impossible.

I guess "experienced C programmers" must be short supply although they have been writing C for years.

Re: New Ghostscript PDF interpreter

#28

Post by chrisseaton »

tgflynn wrote: post #13
amluto wrote: post #9

Earlier quoted context omitted.

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 t…

> There's nothing preventing you from designing a nice well-encapsulated map/dictionary data structure in C

When you write a set function for your map data structure, what type do you make the key parameter?

Re: New Ghostscript PDF interpreter

#29

Post by mistrial9 »

winter_blue wrote: post #22
h2odragon wrote: post #8

Earlier quoted context omitted.

I suspect they need portability more than most projects.

Are you kidding? Many other languages are as portable, if not more portable.[α] Your point would be valid in 1972, not in 2022. I can't believe you're regurgitating the same "portability" from 50 years ago, today (unless you meant it as a joke and forgot to include a /s). [α] Languages targeting LLVM or supported by GCC are portable to every target machine code / ISA / architecture supported by those toolchains. JVM,…

does an LLVM requirement fit the social and license goals of this eco-system fundamental project?

Re: New Ghostscript PDF interpreter

#30

Post by zbentley »

winter_blue wrote: post #22
h2odragon wrote: post #8

Earlier quoted context omitted.

I suspect they need portability more than most projects.

Are you kidding? Many other languages are as portable, if not more portable.[α] Your point would be valid in 1972, not in 2022. I can't believe you're regurgitating the same "portability" from 50 years ago, today (unless you meant it as a joke and forgot to include a /s). [α] Languages targeting LLVM or supported by GCC are portable to every target machine code / ISA / architecture supported by those toolchains. JVM,…

Well, there's portability and then there's portability. Getting LLVM to emit artifacts on a given target is easy. Getting assurance that big, complex interfaces that integrate with the underlying OS in extremely specific ways (i.e. your programming language's IO or concurrency system) behave correctly on that target, and have appropriate testing, community support, and documentation is another thing entirely.

Like, I get it. The claim that "rust isn't portable" is often used as a thought terminating cliche, and is often wrong or irrelevant in context. But the claim "X uses LLVM, LLVM can target environment Y, therefore X is fully compatible with Y" is just as reductive and misleading.

Post reply on HN