Live data from Hacker News

Show HN: Doom (1993) in a PDF

doompdf.pages.dev

71–78 of 78 posts

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

#72
post #19
post #8

Portable Doom Format

As long as it is in Chrome

I think it should work in acrobat also, since that implements more of pdf's embedded javascript. I don't know of any other pdf readers which implement javascript. I assume Mozilla’s PDF.js reader doesn't support it for technical reasons, rather than ideological ones.

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

#73
post #4

One of my formative experiences as a freshman in CS (I learned to program in college) was accidentally opening a PDF with Emacs and watching as it displayed not weird binary data but a real, rendered PDF. I wondered what else it was doing behind my back that I didn't know about. Sadly, I was not able to run Doom in a PDF, in Emacs. I sense it is easier to either re-implement with a similar technique shown here, but u…

I accidentally opened a pdf with less a few weeks ago and learned about pdftotext and all the other software that pagers can use to display arbitrary documents if set up correctly.

Reminded me of how modern linux distros decide how to execute a file. When I learned about that years ago, I spent far too long getting .exe files to run in either wine or mono when run on my machine. Fun exercise, not worth it.

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

#74
post #37

am I the only dummy missing an instruction? the game takes off w/o my input, moving and blasting away. surely I'm just OOTL w/ PDF gameplay, which I blame myself for

Doom does that by default. The background of the main menu features actual gameplay from a bundled demo file.

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

#76

Earlier quoted context omitted.

I don't think forms are a bridge too far, it was very common that forms were provided as PDF and it is more convenient for the sender and receiver to fill the fields on a computer for readability, etc. before printing. However, forms could be handled by a very simple DSL that would be easy to write a safe interpreter for.

JavaScript is already a simple language. There's no requirement to have a JIT even. What makes you believe a custom language would be any safer or better in another way?

IMO the parent commenter leans to a validation-specific DSL, opposed to JS, not only because the language complexity itself, but also due to the usually wide range of objects the script engine gets access to. like title bar, URL box, window decoration, placement, mouse pointer, keystrokes, etc. in web browsers. i worry what it has got or will get access to in documents?
Post reply on HN