I admit to never actually looking a the PDFBox Cos implementation, but every other implementation that I’ve worked with (and it’s been quite a few) have a VERY deep connection between the object and the source document. This is necessary in order to enable various features such as “on-demand read” (especially important for large arrays and streams), incremental updates and more.
It’s your library, but I would personally strongly recommended NOT going in this direction… Leonard On 1/7/15, 9:56 PM, "Andreas Lehmkuehler" <[email protected]> wrote: >Hi, > >Am 07.01.2015 um 22:42 schrieb John Hewson: >> Hi All, >> >> I’d like to bring PDFBOX-2592 to the attention of the dev mailing list. >> >> A number of users on the mailing list have asked about how to import >>pages from other PDFs as forms, our current solution is LayerUtility, >>which is depends on PDFCloneUtility. >> >> However, the design of the COS API allows for sharing of COS objects >>between documents (in the same thread). So there’s no need for all the >>copying and cloning. With only a few minor changes we could get this >>working robustly. It might also help simplify splitting and merging. >> >> I like this idea a lot and it’s pretty simple - any thoughts? >We should wait until the COSStream is refactored (split compressed and >umcompressed stream, optimize the data handling memory vs. file) and see >if your >idea will still work. > >> -- John > >BR >Andreas Lehmkühler
