Correction: That’s how *PDFBox* is designed.
> On 10 Nov 2015, at 10:15, John Hewson <[email protected]> wrote: > >> >> On 10 Nov 2015, at 03:30, Maruan Sahyoun <[email protected]> wrote: >> >> Hi, >> >> as discussed on >> http://stackoverflow.com/questions/33383389/pdfbox-how-can-a-pdacroform-be-flattened/33489651#33489651 >> now we have a flatten() method there is also the need to (re-) generate the >> appearances on demand. The same applies if we'd like to flatten annotations. >> With the current package and class structure that would go into PDAcroForm >> for interactive forms. >> >> What I'm proposing is - instead of adding to the PD model - have user case >> oriented functionality in a new package (services or so) so we have COS >> (abstraction of low level PDF elements), PD (abstraction of COS for PDF >> elements) and services (application of PD model to 'do' something with the >> PDF). As we add higher level functionality this would help us keeping the PD >> model clean. > > You’re under-selling PD here. PD *is* a high-level abstraction, it’s not just > a wrapper around COS, look at PDFont for example. PDDocument lets you ‘do’ > something with a document, PDPage lets you ‘do’ something with a Page, and > PDAcroForm lets you ‘do’ something with an acro form. That’s what PD is all > about. > > The only caveat is that PD is tied to a single document, so we recently > introduced the “multipdf” package. But any functionality which manipulates a > single PDF should be in PD. That’s how PDF is designed. > > — John > >> A similar approach could also be taken e.g. for signing a PDF ... >> >> WDYT? >> >> Maruan >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> <mailto:[email protected]> >> For additional commands, e-mail: [email protected] >> <mailto:[email protected]>
