You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pdfbox.apache.org by "Tilman Hausherr (Jira)" <ji...@apache.org> on 2026/10/07 20:08:00 UTC
[jira] [Comment Edited] (PDFBOX-6271) `getNormalAppearanceStream` marks annotation appearance stream as dirty
[ https://issues.apache.org/jira/browse/PDFBOX-6271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18124451#comment-18124451 ]
Tilman Hausherr edited comment on PDFBOX-6271 at 10/7/26 8:07 PM:
------------------------------------------------------------------
There are many such cases where PDFBox repairs broken PDFs. I'd agree that the specific behavior in your two reproducers isn't needed at all (and it should be fixed), but you'll get the same in other occurrences when rendering.
was (Author: tilman):
There are many such cases where PDFBox repairs broken PDFs. I'd agree that the specific behavior in your two reproducers isn't needed at all, but you'll get the same in other occurrences when rendering.
> `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: dev-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: dev-help@pdfbox.apache.org