Great work! We had the same idea at the same time, here's my version of PDF Doom:
Source: https://github.com/thomasRinsma/pdfdoom
Playable here: https://th0mas.nl/downloads/doom.pdf
Yours is neater in many ways though!
humanity has gone too far
1. Can be easily and freely shared by email / cloud drive, including assets, images and fonts.
2. Supports form filling and saving the form data in the file directly (as opposed to sending it somewhere over HTTP). Basically the electronic equivalent of a paper form that can be filled, send by email and stay filled.
3. Supports (cryptographic) signatures that are again part of the document, and can easily and securely be verified by end users. This is a very important use case in the EU, where electronic signatures are based on cryptography, not "I pinky swear I'm John Smith" DocuSign.
4. Has perfect print fidelity.
We keep complaining about PDF (and rightly so), but there's truly no other format to replace it. The W3c / Whatwg / whatever could probably come up with one based on web technologies, but they haven't yet.
There's Epub which solves a very narrow use case of PDF (electronic book distribution where perfect control over presentation is not required), but nothing that solves the "business" use cases.
I have no idea what the folks at Adobe were thinking when they decided to add this feature that could eventually eliminate most of the benefits of their product.
None of this is to say that the Doom implementation is anything less than a very cool hack.
Then pdf came along and said: no this is too dangerous the only thing in a document should be layout information not arbitrary code.
And here we are two decades later.
My hatred of pdf has no end. It killed postscript for dynamic pages and djvu for static pages.
The fallacy I see in many comments - either directly or between the lines - is to think that since we can run Doom in PDF, hell's gates must have opened and we can do literally anything, especially anything malicious.
This is not the case.
PDF is basically comprised of immutable parts and interactive elements that user agents are supposed to render visibly distinctly. Also user agents are not supposed to run any code without explicit user interaction.
Contemporary user agents do a good job in both respects.
PDFtris and the Doom example are possible because they live in a very small niche of features that enable relatively unobtrusive still interactive form processing. Forms allow code, but do not stick out as much as other interactive elements do and they are relatively flexible. Having found that feature niche is the real genius of PDFtris and related exploits.
Still, they need user interaction. There is no way to do anything behind your back in PDF.
Another fallacy I see in this and the related threads,is that Adobe Acrobat vulnerabilities are PDF vulnerabilities. Yes, Adobe did a terrible job with Acrobat, but in my opinion not at all with the format and specification of PDF - especially not when it comes to security.
The conclusion to draw from this is that the hypothesis "the only thing in a document should be layout information not arbitrary code." is wrong and misguided, since whatever the format is, in the end "nature" (us) will make it evolve in a way that has some amount of arbitrary scriptability ; if it's not JS in PDFs it will be ActiveX controls, a government-mandated proprietary app, having to do a trip to the city hall to have the clerk play an algorithm step-by-step by hand, or something else, but something will always eventually come up to fill that void and you will have to use it whether you like it or not.
Interesting to see someone evoke DjVu.
With the exception of IW44 wavelet compression, basically everything the DjVu file format supports has a PDF equivalent. I built a tool to convert DjVu to PDF that preserves the image layers and file structure with nearly equivalent compression.
My tool did expose some edge cases in the PDF standard which was frustrating. For instance, PDF supports applying a bitonal mask to an image, but it does not specify how to apply it if the two images have different resolution (DPI). It took many years to get Apple to bring their implementation into consistency.
Adobe kept PDF as a proprietary format from 1992 to 2008. You got the reader for free ... on windows, with a single executable. You didn't get an editor and had to pay through the nose for one from Adobe.
It wasn't until the late 2010s that it actually became a free-ish standard, if you think that a 3,500 page document is a 'standard'.
The only reason why adobe did it is because djvu was eating their lunch, between 2002 and 2008 it was the defacto standard for scanned documents in academia. The documents were easy to edit. The image compression is still better than the native compression on PDF.
To add insult to injury after displacing postscript on windows in the name of security, not only did they add a scripting language to PDF, they added one written in two weeks at a time when it was so bad no one used it for anything but pop-ups and with more security vulnerabilities than you could shake a stick at. I suppose we should be happy Adobe didn't put flash in. Oh wait, they did: https://www.reddit.com/r/Adobe/comments/yqisho/flash_content...
Updating the Acrobat client across an enterprise used to be quite burdensome.
I knew PDFs could be dangerous, but I didn't realize it was because they're intentionally designed to allow embedded scripts.
However, forms could be handled by a very simple DSL that would be easy to write a safe interpreter for.
Nature is crafty. It could be the case that we humans are the replicators, not the main show.
Next step: embed Bellard's JSLinux (https://bellard.org/jslinux/) and have a fullblown OS with development environment, office suite and all inside a PDF.
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 using emacs primitives over ASCII characters, or perhaps using a technique similar to the Bad Apple vim post[1] that is #1 at the same time this post is #2.
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.
Press z several times to start
w, a, s, d to move, e to use, space to shoot. z is enter
Can you get it as small as the DOOM1.WAD file? (4 MB)
But do you all think there are other use-cases for this technology? Like, could you distribute apps using PDFs on highly constrained devices (like iphone possibly, or maybe managed devices e.g. play station, xbox, kiosks?) Just throwing out ideas.
Are there other obvious uses for this?
I think when I was playing around with adobe reader I saw you could put movies in them, too. I believe that you're able to make customization's to the menu bar. It seems to be fairly flexible for what it is.
Inb4 "this is the true hacker spirit", I know, yes, this is cool stuff and the true meaning of a hacker, but in the end I'd choose DJVU for a document format.
However, I chose the shareware version since the file size is a lot smaller and it's more recognizable to people.
f0cefca49926d00903cf57551d901abe doom1.wad
In Theatres, Near You
A disclaimer though - I don't have any experience with Doom modding. I don't know if the behavior of this feature is correct. All it does is it loads the PWAD by passing the "-file" argument to the game's main function.
I've been playing around with the version that was up yesterday. I managed to get my DOOM Resume running in the PDF https://github.com/adamrmelnyk/thisResumeRunsDoom.
Is it playable.... eh? that's another matter. I think I'd need to modify it a bunch. Right now the doors don't seem to open when playing the PDF. I could just remove them all though.