[
https://issues.apache.org/jira/browse/PDFBOX-2580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14310721#comment-14310721
]
Maruan Sahyoun commented on PDFBOX-2580:
----------------------------------------
Let me give you some background on the overall theme of the changes. The
background of the initiative of enhancing AcroForms support is to try to make
it a first class citizen within PDFBox (which it currently isn't).
The first step was to redefine the PD model to be in line with the PDF
specification. In addition most of the parameters which required COS model data
has been changed to use Java builtin types. E.g. setting the value of a
RadioButton is now done using a String value where it has been a COSName
before. This is to further shield the user from dealing with the COS model in
the PD model.
The next step - and this is one of the reasons why the .services.forms package
has been created - is to further enhance the usability of forms filling and
creation. As of today creating a new form field users need to know that they
have to create a field, have to create an annotation, set the annotation to be
used within the field, apply styling to the annotation .... - not very user
friendly.
In addition the appearance generation of form fields is - apart from the plain
mechanism - undocumented in the specification. Things like line spacing of
multiline text fields, font mapping, padding etc. are not part of the PDF
specification.
Further more appearance generation can't be made dependent on setting the field
value and only done there as there are forms where the appearance needs to be
regenerated using the current field value. This is the case if the
NeedAppearances flag has been set in the form. E.g. if a form has that flag set
and we do render the form, prior to doing the rendering the appearance stream
for the AcroForm fields needs to be (re-) generated. That is the reason why the
AppearanceGenerator is publicly available and not package private and not
hidden behind the field value setting.
So .services.forms should be the new home for a higher level forms API (of
course the package name could be discussed upon but I didn't want to make a
package directly under o.a.pdfbox as a similar approach needs to be taken for
annotations). The reason I'm establishing it now is to be able to build on that
developing that higher level API without the need to do another major release
to repackage. So user can expect and trust that a high level AcroForms API is
in that package with further abstractions to our low level PD (or even COS)
model.
Finally wrt to naming. The name PDAppearanceString has been left intact while
I'm reworking the very procedural code. There is nothing like an
AppearanceString in PDF. The current functionality is something between
handling a Default Appearance String and creating an appearance stream.
I do hope that clarifies the reasoning behind the changes with a quick overview.
> Decouple implementation specific forms handling 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: [email protected]
For additional commands, e-mail: [email protected]
