> On 8 Jan 2015, at 13:03, Tilman Hausherr <thaush...@t-online.de> wrote: > > Am 08.01.2015 um 08:01 schrieb Maruan Sahyoun: >> 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. >>> >> I like the idea to simplify importing a page as a form object as although >> it's in place the function is hidden in the LayerUtility (although we have a >> sample now ho to do it). What I propose it to do it in stages >> >> a) Have the constructor like PDFormXObject form = new PDFormXObject(page) >> and reuse the existing code internally so we have the API in place for 2.0 >> b) do the changes to the inner workings at a later stage for 2.1 >> >> There are two main reasons for that >> a) I suspect as you go you will find that there need to be changes to the >> existing COS model with the potential for new regressions >> b) a) has the risk of further moving out PDFBox 2.0 > > Indeed - we're not even finished with the regressions from the last > shuffling. New regressions would be even harder to fix because they can't be > assigned to a specific change. > > I have the theory (based on my observations here) that regressions get harder > to solve with time, and that the difficulty is not linear. > > And yes, we shouldn't open new "big change" construction sites. This should > be done after 2.0. >
It’s not a big change though, it’s a tiny change. It’s completely unfair to compare this to something like rendering where we’re trying to figure out edge cases in the PDF spec. We’re talking about a problem which is understandable by reading the first chapter of any introductory book on Java. It’s not rocket science. > > Tilman > >> >> IMHO: very good idea and initiative; has to be done; shall be done later >> >> BR >> >> Maruan >> >>> 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? >>> >>> -- John >>> >> >
