[
https://issues.apache.org/jira/browse/PDFBOX-2580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14312658#comment-14312658
]
John Hewson edited comment on PDFBOX-2580 at 2/9/15 7:08 PM:
-------------------------------------------------------------
{quote}
Some of it is base CSS support for rich text, a formatting capability, XFA if
we want to support XFA based AcroForms, default styles for fields and some
more. CSS and XFA not being part of core PDF and styling being unspecified.
{quote}
XFA rich text strings and their CSS2 styling are part of core PDF and are
needed in pdfbox core for rendering, which would result in a dependency cycle
where the forms module depends on core, and core depends on the forms module,
i.e. this means that such a forms module is really just a part of core, as
neither could be used in isolation.
{quote}
What I do know is all that is added now is only needed for interact forms
filling. It's not needed for rendering (apart from XFA), it's not needed for
merging. That's why I wanted to put in into an extra 'layer' sitting above and
using the PD model.
{quote}
Actually, appearance string generation will be needed for rendering. Any field
which we can generate an appearance for is likewise a field which another PDF
generator may have omitted an appearance for, and we'll need to generate it. So
appearance generation is a core dependency of rendering.
{quote}
Now if some comes by and asks for a smaller PDFBox we can ask a simple question
'Do you need to fill in forms'. Dependent on his answer he can include or
exclude the package from his custom build.
IMHO if we think about modularization we shall also think about layering
PDFBox. We shall also think about package interdependencies.
{quote}
As I've said above, that's not a useful modularisation because it doesn't
reduce any dependencies or help the user achieve a goal which they perviously
could not. There is no advantage to having a seperate forms package which
itself depends upon pdfbox core, especially as core itself will depend upon the
forms package for rendering. All users of pdfbox, whatever their goal will
simply have to redistribute both core and the forms module at all times. A user
wanting to do a custom build of PDFBox is far better served by using ProGuard,
which is free and open source, because we can never anticipate what such a
user's custom needs are going to be ahead of time.
{quote}
It's good that we agree that interactive forms support needs to be enhanced. We
have different opinions on where that should go mostly being irrelevant to the
majority of our users. Let's keep that topic open for another two days and see
if there is additional input for one or the other approach giving Andreas,
Tilman and others a little time to add if they want to.
{quote}
Yes, lets do that.
{quote}
If there is no support for .service I'll move everything into o.a.p.pdmodel
later this week.
{quote}
Remember that it's easy for us to move package-private classes in o.a.p.pdmodel
out into a separate public package at a later date, so moving everything back
there doesn't have to be permanent. I think the next step after this is to
discuss what new forms classes are needed for 2.0 (names and responsibilities
of each class), so that we can make any breaking changes ASAP, I'm happy to
help out with this if needed.
was (Author: jahewson):
{quote}
Some of it is base CSS support for rich text, a formatting capability, XFA if
we want to support XFA based AcroForms, default styles for fields and some
more. CSS and XFA not being part of core PDF and styling being unspecified.
{quote}
XFA rich text strings and their CSS2 styling are part of core PDF and are
needed in pdfbox core for rendering, which would result in a dependency cycle
where the forms module depends on core, and core depends on the forms module,
i.e. this means that such a forms module is really just a part of core, as
neither can be used in isolation.
{quote}
What I do know is all that is added now is only needed for interact forms
filling. It's not needed for rendering (apart from XFA), it's not needed for
merging. That's why I wanted to put in into an extra 'layer' sitting above and
using the PD model.
{quote}
Actually, appearance string generation will be needed for rendering. Any field
which we can generate an appearance for is likewise a field which another PDF
generator may have omitted an appearance for, and we'll need to generate it. So
appearance generation is a core dependency of rendering.
{quote}
Now if some comes by and asks for a smaller PDFBox we can ask a simple question
'Do you need to fill in forms'. Dependent on his answer he can include or
exclude the package from his custom build.
IMHO if we think about modularization we shall also think about layering
PDFBox. We shall also think about package interdependencies.
{quote}
As I've said above, that's not a useful modularisation because it doesn't
reduce any dependencies or help the user achieve a goal which they perviously
could not. There is no advantage to having a seperate forms package which
itself depends upon pdfbox core, especially as core itself will depend upon the
forms package for rendering. All users of pdfbox, whatever their goal will
simply have to redistribute both core and the forms module at all times. A user
wanting to do a custom build of PDFBox is far better served by using ProGuard,
which is free and open source, because we can never anticipate what such a
user's custom needs are going to be ahead of time.
{quote}
It's good that we agree that interactive forms support needs to be enhanced. We
have different opinions on where that should go mostly being irrelevant to the
majority of our users. Let's keep that topic open for another two days and see
if there is additional input for one or the other approach giving Andreas,
Tilman and others a little time to add if they want to.
{quote}
Yes, lets do that.
{quote}
If there is no support for .service I'll move everything into o.a.p.pdmodel
later this week.
{quote}
Remember that it's easy for us to move package-private classes in o.a.p.pdmodel
out into a separate public package at a later date, so moving everything back
there doesn't have to be permanent. I think the next step after this is to
discuss what new forms classes are needed for 2.0 (names and responsibilities
of each class), so that we can make any breaking changes ASAP, I'm happy to
help out with this if needed.
> 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
>
> Attachments: sonar.png
>
>
> 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
