[
https://issues.apache.org/jira/browse/PDFBOX-2580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14308395#comment-14308395
]
John Hewson commented on PDFBOX-2580:
-------------------------------------
This functionality belongs in the PD model. The PD model provides a
higher-level API for representing and manipulating PDF file components.
PDImage, PDFont, PDColorSpace, and PDPageTree are great examples such
high-level functionality.
It should be obvious that PDAppearanceString belongs in the PD model, what with
it being in the name of the class. Furthermore, AppearanceGenerator is an
internal implementation detail and shouldn't be public, but this has been made
impossible by not having it in the same package as PDField.
There might be scope in the future for some super-high-level form classes which
belong in their own package, but the contents of this package is currently
textbook PD functionality, so I'm going to move PDAppearanceString and its
helpers back to pdmodel.interactive.form, where they belong.
> Decouple forms filling from interactive.form PD Model
> -----------------------------------------------------
>
> Key: PDFBOX-2580
> URL: https://issues.apache.org/jira/browse/PDFBOX-2580
> Project: PDFBox
> Issue Type: Improvement
> Components: AcroForm
> Reporter: Maruan Sahyoun
> Assignee: Maruan Sahyoun
> Fix For: 2.0.0
>
>
> The interactive.form PD model currently holds classes reflecting the various
> fields intermixed with appearance generation and layout handling.
> In order to separate the PD model from the service of forms filling and
> appearance generation this functionality shall be moved into a new package.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
