Bless the heart of whoever looked at the PDF spec and said to themselves, "Nice, I'd like to writer a parser for this."
In fairness, I didn't write the PDF rendering. That is indeed quite a tall order.
I used to use poppler and switched to mupdf (was more active at the time, poppler seems to have picked up pace since).
The core PDF feature set isn't that bad to implement.
From what I've seen, the bad / complex parts are:
- stuff they added years later, like some XML stuff (of course you had to add XML in 2000!), JavaScript in forms
- some more complex vector graphics features like masking with vectors, support for bunch of color spaces, cmyk separation
- font handling, text rendering is surprisingly complex
- rendering fast even if PDF was badly created
- PDF is easy to screw up when you create it and boy, do people screw up in every imaginable way. You can't just say "it's bad PDF" when Adobe or Chrome opens it so a lot of effort by mupdf devs is adding heuristics to show even broken PDF docs
https://tcpdf.org/examples/example_014/
How does this even work?
You can also do animated page transitions like PowerPoint, but I don't have the right link available...
To me this is the kind of scope creep that causes a "simple" PDF renderer department to end up with 50 devs working in it full-time.
I wonder... can a PDF have an iframe that opens itself? Causing an infinie loop of it loading itself?
1. Yes we all know how stupid this was. but they wanted fillable forms and validating those forms made sense at the time. Really it was because they were trying to compete with the web.
The original spec is a bit ugly because they were saving bytes in the format (using things like single letters for dictionary keys), but some things are actually quite well thought out (Appearance Streams are great for forward and backward compatibility and are probably no. 1 reason why nothing managed to replace PDF.)
I've been wondering why they took that approach. Do you know their original reasoning? And how does it help compatibility?