[
https://issues.apache.org/jira/browse/PDFBOX-5436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538082#comment-17538082
]
Maruan Sahyoun commented on PDFBOX-5436:
----------------------------------------
[~waiwai_] what's the reason for circumventing the generation of the
appearance? If you don't generate it the new content will not be reflected
visually. Understanding the use case might help getting a soution to your
request.
[~mkl] you are correct that only 2.0 enforces it. The reason why I decided to
always generate it regardless of the version being used is that
- a casual user doesn't necessarily understand the differences between the
versions
- expects when setting a value that it needs to be visually visible
- the setters don't care about versions (which one might consider a limitation
of PDFBox)
- ...
so that the default is "fill the field and you see the new value". For low
level access there is always the option to use the COS model.
... just to outline my thought process behind the decision. Comments/Feedback
welcome
> PDTerminalField.applyChange() no longer check for
> getAcroForm().getNeedAppearances()
> ------------------------------------------------------------------------------------
>
> Key: PDFBOX-5436
> URL: https://issues.apache.org/jira/browse/PDFBOX-5436
> Project: PDFBox
> Issue Type: Bug
> Components: AcroForm
> Affects Versions: 3.0.0 PDFBox
> Reporter: wai
> Priority: Major
>
> In version 2.0.26, I fill fields in PDF form by
> {code:java}
> PDDocument pdf = ...; // loaded a PDF form
> PDAcroForm pdfForm = pdf.getDocumentCatalog().getAcroForm();
> pdfForm.setNeedAppearances(true);
> pdfForm.getField("field_name_xxxx").setValue("some text");{code}
> Although the PDF form doesn't contain all glyph for the text set,
> {{org.apache.pdfbox.pdmodel.interactive.form.PDTerminalField.applyChange()}}
> would not apply {{constructAppearances()}} as {{setNeedAppearances(true)}}
> configured.
> However when we come to version 3.0.0-alpha3,
> {{PDTerminalField.applyChange()}} won't check the status from
> {{getAcroForm().getNeedAppearances()}} before invoking
> {{{}constructAppearances(){}}}. This behaviour contradicted the comment wrote
> "{{{}Applies a value change to the field. Generates appearances if required
> and raises events.{}}}"
> +version 2.0.26+
>
> {code:java}
> package org.apache.pdfbox.pdmodel.interactive.form;
> public abstract class PDTerminalField extends PDField
> {
> /**
> * Applies a value change to the field. Generates appearances if required
> and raises events.
> *
> * @throws IOException if the appearance couldn't be generated
> */
> protected final void applyChange() throws IOException
> {
> if (!getAcroForm().getNeedAppearances())
> {
> constructAppearances();
> }
> // if we supported JavaScript we would raise a field changed event
> here
> }{code}
>
> +3.0.0-alpha3+
>
> {code:java}
> package org.apache.pdfbox.pdmodel.interactive.form;
> public abstract class PDTerminalField extends PDField
> {
> /**
> * Applies a value change to the field. Generates appearances if required
> and raises events.
> *
> * @throws IOException if the appearance couldn't be generated
> */
> protected final void applyChange() throws IOException
> {
> constructAppearances();
> // if we supported JavaScript we would raise a field changed event
> here
> }{code}
>
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
