> 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] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
