[
https://issues.apache.org/jira/browse/PDFBOX-5583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17710247#comment-17710247
]
Chris Newhouse commented on PDFBOX-5583:
----------------------------------------
OK so I've managed to get things working, but in the name of clarity and
optimization, I would love some more information and help if you could provide
it. [~mkl]
Again, the general use-case and question(s) are: how do we optimally,
correctly, and minimally handle the addition or changing of (1) Fonts and
Font-subsets in the AcroForm, (2) the value and possibly Font of existing
Fields in the AcroForm, or (3) both...in an _*incremental save*_ situation?
Goals are: keep file size to a minimum, do not invalidate signatures, proper
rendering in common viewers, no errors or warnings from PDFDebugger as well as
Acrobat Pro's Pre-Flight Font check (etc).
Here's a gist I created that shows an oversimplified bit of code that we're
using currently:
[https://gist.github.com/newhouse/20982eb2487faffdc8574b41b20b186c]
The `handleAddOrUpdateFont` method will be called anytime a new Font is added
to the form by our code, or when we think that an existing Font's subset has
been expanded upon. (I would also appreciate any guidance on how to re-use an
existing subset, or easily know what characters are in an already-embedded
subset, but may not actually be present in any Field value).
The `handleFieldUpdated` method will be called whenever the value or Font of a
field is changed (or set), and will be called on every Field that uses a
previously existing Font that was updated by the `handleAddOrUpdateFont` method
above. Again, I'm not sure what things I'm missing doing, and what things may
be overkill. Or if I only need to make certain calls when I change the `value`
vs the `font`, or the `value` and the `font`.
As always, thank you very much for your help!
> 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]
