Live data from Hacker News

Show HN: Doom (1993) in a PDF

doompdf.pages.dev

11–20 of 78 posts

Re: Show HN: Doom (1993) in a PDF

#16
post #10

Earlier quoted context omitted.

There's no WAD in the repo, I assume the linked PDF contains the shareware episode.

The build wgets the wad from elsewhere.

Thanks, yes it is the shareware episode.

f0cefca49926d00903cf57551d901abe doom1.wad

Re: Show HN: Doom (1993) in a PDF

#17
post #3

> limited JS runtime of the PDF engine humanity has gone too far

:-) I'll never quite appreciate why people say things like this. Having some kind of embedded scripting is useful for all sorts of things, often form validation. A sufficiently complex validation system becomes Turing complete, so you might as well skip the hassle of a custom language and go right to JavaScript. Once you have JavaScript, input, and some way of updating a graphical pixel grid, you're at Doom-completeness. I think it's a wonderful, not terrible, thing that computation and programmability are so cheap they've become ubiquitous even in the most mundane applications

Re: Show HN: Doom (1993) in a PDF

#18
post #3

> limited JS runtime of the PDF engine humanity has gone too far

:-) I'll never quite appreciate why people say things like this. Having some kind of embedded scripting is useful for all sorts of things, often form validation. A sufficiently complex validation system becomes Turing complete, so you might as well skip the hassle of a custom language and go right to JavaScript. Once you have JavaScript, input, and some way of updating a graphical pixel grid, you're at Doom-completen…

JS is what made these file types into the Pretty Dangerous Format. Numerous vulnerabilities in Adobe Acrobat surfaced thanks to the embedded JS engine.

Updating the Acrobat client across an enterprise used to be quite burdensome.

Re: Show HN: Doom (1993) in a PDF

#20
post #18

Earlier quoted context omitted.

:-) I'll never quite appreciate why people say things like this. Having some kind of embedded scripting is useful for all sorts of things, often form validation. A sufficiently complex validation system becomes Turing complete, so you might as well skip the hassle of a custom language and go right to JavaScript. Once you have JavaScript, input, and some way of updating a graphical pixel grid, you're at Doom-completen…

JS is what made these file types into the Pretty Dangerous Format. Numerous vulnerabilities in Adobe Acrobat surfaced thanks to the embedded JS engine. Updating the Acrobat client across an enterprise used to be quite burdensome.

The flip side is that because the industry has converged on just a few embedded scripting systems (JS, Lua, etc.) we can concentrate our security hardening efforts on these few engines and benefit everyone. If PDF, like PostScript, were its own custom thing, it couldn't have been able to benefit from this hardening. In the end, JS was a fine choice.
Post reply on HN