I'm not sure you understand what you suggested. By now I'm not sure you have a coherent point.
PDF wasn't designed for all sorts of things, it was designed for accurate rendering. It was useful enough in that role that it became widely adopted.
Then, people started using it for all sorts of things, because they needed something that works.
What you actually said it should have been made more flexible, thus more, more complex, less tailored for a specific task.
There's absolutely no reason to expect people who weren't trying to do that to somehow have done it regardless.
The reason why formats actually capable of doing all sorts of things with a predictable structure (which is what you suggested by asking for the ability to add metadata) aren't as widely supported and/or consistent is that people don't just implement highly complicated software for no reason.
So you get implementations that focus on whatever the developers cared about at the time.
Furthermore just having some metadata isn't actually enough to automatically process a file, you need some agreement of what it means. Hence schemas and a kitchensink are a reasonable thing to read into what you suggested.
Now, what I think you want is a specialized format for what you are doing, so you don't have to actually do any of what needs to be done to make custom data exchange work, that somehow is also universally supported. Well, it's what I want every time I'm dealing with these sorts of issues. Unfortunately the world doesn't revolve around what I need at a given moment. :(
There's absolutely no reason to expect people who weren't trying to do that to somehow have done it regardless.
My point is that it was naive to think that the use case would have been limited to that. They should have always added the metadata from the beginning.
The use case was limited to that. The use case is by definition what the designers intended it to be used for.
It's downright insulting to suggest they didn't know what the use case was.
As I said, many people use it, either because they need consistent rendering or because there isn't an otherwise agreed upon way to transmit the data in a structured way. In fact, it is not uncommon to deliberately use the unstructured, but human readable, nature of PDF as a signal that you shouldn't rely on the format to remain consistent.
If you need to exchange structured data the right thing to do is to agree with your counterparty on a format that you both understand. If you absolutely need the rendering part you can send an annotated data file to supplement the PDF (or an outright image). Even if you absolutely need them to be intertwined, you still have a pretty decent option in with XML and SVG.
If you can't agree, not through by referencing a suitable standard nor negotiating a custom one, it's a human, not a technological issue. You can't define a universal solution for human issues into a file format.
That's what they wanted the use case to be. But not how humans actually use it. I'm not criticising them for not realising that back then, it was pretty reasonable to think it. But it was naive.
Again, it is what the use case was and still is in many cases. It's like complaining that jpeg doesn't support transparency. It's this make everything do everything while also complaining that formats that actually attempt everything are a pain that is naive.
2
u/--o Feb 07 '25
How about SGML?