[
https://issues.apache.org/jira/browse/PDFBOX-5583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17712782#comment-17712782
]
Michael Klink commented on PDFBOX-5583:
---------------------------------------
I think you overestimate what {{setNeedToBeUpdated}} does.
In your code there is the assumption that that method updates the _contents_ of
the object in question to match changes in related properties. In particular
you seem to assume that the method updates an appearance to use updated default
appearance strings and updated default resources.
This is not the case. {{setNeedToBeUpdated}} merely marks the object to be
included in an incremental update if the document is saved incrementally. But
the object will be included with the contents it has at the time of saving. So
if you don't update the contents of the appearance stream you marked, the
appearance stream will be stored with the old contents. Thus, you will not see
any differences in the displayed PDF.
Furthermore, I'm not sure how exactly new font subsets are actually created.
It's automatically done for fonts used on pages, but for fonts used only
elsewhere you may have to do some extra housekeeping...
Essentially the method is a bit mis-named, it probably should have been
something like {{setNeedToBeStored}}.
> Adding font (or changing font subset) not coming through in saveIncremental
> ---------------------------------------------------------------------------
>
> Key: PDFBOX-5583
> URL: https://issues.apache.org/jira/browse/PDFBOX-5583
> Project: PDFBox
> Issue Type: Bug
> Components: AcroForm, PDModel, Signing
> Affects Versions: 2.0.24
> Reporter: Chris Newhouse
> Priority: Major
> Attachments: image-2023-03-31-17-40-48-710.png,
> update-after-signature-includes-font-change.pdf,
> update-after-signature-that-changes-font-two.pdf
>
>
> In an effort to keep file sizes small, we leverage Font Subsets in our PDFs.
> Also, we already have "incremental change and signing" (where fields are
> changed _after_ a signature, without voiding the prior signature thanks to
> using `saveIncremental` and signing the changes) working just fine in most
> cases.
> However, when the Font on a field is changed or a new Font Subset must be
> added to the document because the characters used in a field with a
> tightly-subsetted Font, things don't work correctly:
> * The signatures stay valid, which is great
> * But the new Font information does not appear to get written to new version
> appendix, so you get nonsense rendering in a PDF viewer since the field still
> points to a Font resource that is either not there or is a subset that does
> not contain all the necessary characters. I'm not super proficient in this so
> I don't know exactly what's going on.
>
> I have ensured that the fields we update are getting marked as
> `setNeedToBeUpdated(true)` (this is, I believe, why the fields changes _do_
> end up in the version changes), it just seems that the Font resources are not
> getting updated in the version.
> I have also tried to mark the document's PDResource as
> `setNeedToBeUpdated(true)` but to no avail.
>
> Is this behavior possible/allowed? Is it a bug or am I doing something wrong?
>
> I have included an example file where the field named
> `incrementalChangeField` goes from `NotoSans-Regular` to
> `NotoSansCJK-Regular` during the incremental change, but the font resource
> does not get added.
> Thanks for your time!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
