Closed benbahrenburg closed 7 years ago
I'm a little confused about what the actual use case of this is. Right now PDFDocument
s are created with a simple URL to the file. Normally if you have the PDF as raw data, you just save a temporary file in the caches directory and use that, so that you always have a reference to the file's contents and don't run into problems later on. Perhaps I need more information about the actual intended use case, but this seems like this adds unnecessary complexity to handle a rare and niche use case.
Hi @ranunez , You are correct that this is really an enterprise style feature. It is similar to how vfr reader creates their document (https://github.com/vfr/Reader/blob/master/Sources/CGPDFDocument.m). The big differences is instead of just creating a bunch of different init overrides I thought it might be easier to create a protocol strategy.
There are several reason the app might have a NSData object instead of a file URL. The biggest reason is that many applications have restrictions on writing sensitive data to disk. Others have to deal with creating CGPDFDocument directly, being able to display directly would be useful instead of having to flush to disk and re-read.
Hello,
For one of my current projects I need to be able to load pdfs from a variety of different sources. I thought maybe you would be interested in looking at if the project could benefit. Basically I added a strategy to the init of the PDFDocument that allows the strategy to create the CGPDFDocument and required fields. Since some of the options don't have associated files I had to add some optional handling for the filename and file path.
Below is the branch with the changes I've been working on. If you are interested I can work on putting together a a PR. https://github.com/benbahrenburg/iOS-PDF-Reader/tree/journey-exp