[
https://issues.apache.org/jira/browse/PDFBOX-6271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jakob Heher updated PDFBOX-6271:
--------------------------------
Description:
Calling `getNormalAppearanceStream` on an annotation marks the appearance
stream as dirty. This causes it to be re-emitted in a subsequent incremental
update save.
In particular, PDFRenderer's `renderPageToGraphics` can also trigger this bug
down-stack (which is how we ran into it; we render the document page to
determine where to place a subsequent signature annotation, and the previous
signature annotation's appearance stream was re-emitted).
The cause is that the `PDXObject` constructor taking `COSStream` (which the
`PDFormXObject` constructor delegates to) unconditionally calls `setName` ->
`setItem` to set the correct type/subtype values. `setItem` then
unconditionally marks the dictionary as dirty. This is the same fundamental
cause as PDFBOX-6270.
A minimal reproducer is attached. A sample PDF file exhibiting this bug is also
attached.
A suggested fix would be to make the `setItem` invocations conditional. This
likely applies to more than just PDFormXObject, it is just the context in which
we encountered the bug.
*AI disclaimer:* I used ChatGPT to perform the cause analysis after noticing
the erroneous behavior in production, and to generate an initial reproducer.
However, I have manually refined the reproducer, and have manually verified the
erroneous behavior in the source tree. I have written this bug report by hand.
I am confident that this is a real bug.
was:
Calling `getNormalAppearanceStream` on an annotation marks the appearance
stream as dirty. This causes it to be re-emitted in a subsequent incremental
update save.
In particular, Renderer's `renderPageToGraphics` can also trigger this bug
down-stack (which is how we ran into it; we render the document page to
determine where to place a subsequent signature annotation, and the previous
signature annotation's appearance stream was re-emitted).
The cause is that the `PDXObject` constructor taking `COSStream` (which the
`PDFormXObject` constructor delegates to) unconditionally calls `setName` ->
`setItem` to set the correct type/subtype values. `setItem` then
unconditionally marks the dictionary as dirty. This is the same fundamental
cause as PDFBOX-6270.
A minimal reproducer is attached. A sample PDF file exhibiting this bug is also
attached.
A suggested fix would be to make the `setItem` invocations conditional. This
likely applies to more than just PDFormXObject, it is just the context in which
we encountered the bug.
*AI disclaimer:* I used ChatGPT to perform the cause analysis after noticing
the erroneous behavior in production, and to generate an initial reproducer.
However, I have manually refined the reproducer, and have manually verified the
erroneous behavior in the source tree. I have written this bug report by hand.
I am confident that this is a real bug.
> `getNormalAppearanceStream` marks annotation appearance stream as dirty
> -----------------------------------------------------------------------
>
> Key: PDFBOX-6271
> URL: https://issues.apache.org/jira/browse/PDFBOX-6271
> Project: PDFBox
> Issue Type: Bug
> Affects Versions: 3.0.6 PDFBox
> Reporter: Jakob Heher
> Priority: Major
> Attachments: Repro2FormXObjectConstructor.java, double-signed.pdf
>
>
> Calling `getNormalAppearanceStream` on an annotation marks the appearance
> stream as dirty. This causes it to be re-emitted in a subsequent incremental
> update save.
> In particular, PDFRenderer's `renderPageToGraphics` can also trigger this bug
> down-stack (which is how we ran into it; we render the document page to
> determine where to place a subsequent signature annotation, and the previous
> signature annotation's appearance stream was re-emitted).
> The cause is that the `PDXObject` constructor taking `COSStream` (which the
> `PDFormXObject` constructor delegates to) unconditionally calls `setName` ->
> `setItem` to set the correct type/subtype values. `setItem` then
> unconditionally marks the dictionary as dirty. This is the same fundamental
> cause as PDFBOX-6270.
> A minimal reproducer is attached. A sample PDF file exhibiting this bug is
> also attached.
> A suggested fix would be to make the `setItem` invocations conditional. This
> likely applies to more than just PDFormXObject, it is just the context in
> which we encountered the bug.
> *AI disclaimer:* I used ChatGPT to perform the cause analysis after noticing
> the erroneous behavior in production, and to generate an initial reproducer.
> However, I have manually refined the reproducer, and have manually verified
> the erroneous behavior in the source tree. I have written this bug report by
> hand. I am confident that this is a real bug.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
