Closed ghost closed 2 years ago
First off, I'm afraid this isn't an actionable erratum, i.e. there's no "broken" feature in the standard to fix. So this probably isn't the best place to discuss.
Putting on my iText hat: this is something we've thought about in the past, and there are various challenging aspects to this problem. I won't go into detail right here, but suffice to say that this is a minefield that needs to be navigated very carefully. :)
Also, there might be a relevant talk on that topic at the upcoming PDF Days in September... ;).
As @MatthiasValvekens said, and I will put in a different way, this is not a bug but an actual feature of PDF.
PDF files represent (to the world at large) a "document" - which makes sense since that is what the "D" stands for ;). User do not expect documents to change when they are viewed - either live while open or between opens. Not only that, but most don't expect them to go anywhere near a network - hence why many viewers put up warning dialogs when a PDF tries to "phone home".
This is, of course, quite different from what users expect on the web - where content is entirely ephemeral and there it entirely based online and communication is core.
Hi all! @lrosenthol @MatthiasValvekens How are you? So... thank you for feedback! I hope to clarify some things...
Hi all! I hope to clarify some things here too...
["paragraph",
{"style":"bold",
"size":10,
"family":"halvetica",
"color":[0, 255, 221]},
"Lorem ipsum dolor sit amet, consectetur adipiscing elit."]
@raphael-louis-andress So you aren't talking about the content of a PDF being updated after it is distributed, but instead how one could manage an internal repository of documents. That would seem to be the province of Document Management Systems (as their name implies). But a DMS doesn't do document creation (in most cases, though there are exceptions in specialized fields) - such creation (or updating) must be done outside using tools such as the ones that you suggest.
And PDF creation is going to be based on the type of content that is being authored, with very different content layout and formatting needs. Consider that the content authoring functionality of a word processing program (ala MSWord or Google Docs) is completely different from that of a spreadsheet (ala MSExcel or Google Sheets) and even more so from specialized authoring tools such as AutoCAD or MuseScore. So trying to define such a system that would be "generic" seems impractical.
If you are looking for REST APIs for PDF creation. whether from markup languages such as JSON, XML or HTML or from existing authoring formats, you will find a number of them offered by members of the PDF Association.
@lrosenthol Hi! Thank you for feedback. I appreciate your comment, you were quick to respond. So... that's why I'm happy, you're amazing... It's very kind of you to read this entire message I wrote, so thank you again.
Curiosity. I would like to know more about the PDF format.
PDF is standardized as ISO 32000. Part 1 is for PDF 1.7 and Part 2 is for PDF 2.0. Those documents are the official documentation on the PDF file format.
@lrosenthol Thank you for feedback again ;D please, close this issue. everything has been resolved - you clarify all doubts. So... really, this feature doesn't make any sense.
Regarding this:
@MatthiasValvekens Hi! when you say: "Putting on my iText hat:" ... do you mean: https://itextpdf.com/en?
I work for iText. What I meant is that within the iText research team we've played around with the idea of "self-updating" PDF. I wanted to stress that that's completely orthogonal to anything in the PDF standard, since this issue tracker is really about resolving issues with the current spec. I should've made that distinction more clear.
Anyway, since you seem to be satisfied with the answers you got, I'll go ahead and close this, as you requested. :)
Describe the bug
Provide a recommendation for correction.
Additional context
References