Thomas Hoevel wrote:
1. PDFsharp was developed to deal with intact PDF files. And now we have problems reading corrupt PDF files.
I am explicitly limiting this (at least, for now) to PDFs that Adobe Acrobat opens without complaint. (For most of these PDFs, the non-existing objects are also not referenced anywhere, so they really cannot cause any problem.) Therefore, many of our users, and even the writers of the software that created those PDFs, will see these PDFs as non-corrupt and it will be hard to explain to our users why our software cannot open them.
Thomas Hoevel wrote:
2c) Lazy loading will lead to lazy exceptions. Many new problems may occur.
If we decide to implement this, we will of course run it over our own test set and make sure that everything we encounter and that is fixable within PDFsharp is fixed. This should shake out the most important ones of these.
Thomas Hoevel wrote:
Programs using PDFsharp may require many changes that deal with lazy exceptions.
You're proposing a breaking change with benefits and risks.
Yes, this is why I thought it was wise to ask you first.
Indeed, this may cause problems for programs using PDFsharp. One possible idea is to add this as an option: by default, read all objects, but allow it to be turned off if you require it. Then it remains a matter of how many PDFsharp users actually need this (and how many maintenance problems it creates).
However, if properly implemented, I think this could greatly improve PDFsharp's quality.