* PdfMerger: Allow to select the pages when merging documents
Supersede #245
* Impose artificial limit in the amount of page, that a node can contain
Plus, Use IReadOnlyList instead of IReadOnlyCollection
This is a naive implementation, because if you copy multiple pages from the same document, the recipient document would be bloated with duplicated resources
You can create new content stream (NewContentStreamAfter, NewContentStreamBefore) and select (SelectContentStream) which one we are editing at the moment
filter provider becomes single instance and no longer has constructor parameters.
tokenizers use list and stringbuilder pools to reduce allocations.
system font finder becomes static to preserve file cache across all documents.
adds color profiles/output intents and an xmp metadata stream to the document in order to be compliant with pdf/a-1b (basic). this compliance level is toggled on the builder since it will generate larger files and set to 'off/none' by default. pdf/a documents are also not able to use standard fonts so using a font when the compliance level is not none will throw.
returns a reference to the added image object when calling addjpeg so that it can be shared between or within pages meaning the image is only written to the output file once but can appear multiple times.
this image doesn't seem to be displaying correctly in adobe reader.
since jpegs can be trivially embedded in pdf documents without changes to the data stream this is the first image format we will support. currently this is a naive approach which doesn't share an image resources between pages. ideally we will either de-duplicated images when added, return a re-usable key once an image is added, or both.
Anyway, the DataToken properties most are readonly, If you want to change something. You have to crate a new token anyway. Discussion: https://github.com/UglyToad/PdfPig/pull/150
This class would allow us to lazily flush resource. This would allow us to make changes to them, while new content is pushed. Compress, Merge, Deduplicate, etc...
after we split the solution into multiple projects the xml doc comments were no longer packed in the generated nuget package. in addition they were only generated for the net standard 2.0 target framework.
this change generates comments for all target frameworks and makes sure they're included in the generated package. it also adds missing doc comments where they weren't included on the public api and clears up a couple of minor formatting issues in the affected files.
most of the cross-reference code is the earliest code in the project and hasn't been revisited since then. the issue #88 has been reopened due to a bug with brute-force searching so this tidies up the code in this area ahead of trying to fix the bug.