Skip to content

Don't fail getTextContent when the first text in a stream has a zero font size (issue 22381) - #22383

Closed
zhaodengfeng wants to merge 1 commit into
mozilla:masterfrom
zhaodengfeng:fix-text-content-zero-size-font
Closed

zhaodengfeng wants to merge 1 commit into
mozilla:masterfrom
zhaodengfeng:fix-text-content-zero-size-font

Conversation

@zhaodengfeng

@zhaodengfeng zhaodengfeng commented Oct 29, 2026 •

Copy link
Copy Markdown

Fixes #22381.

The text state is cloned before any Tf is applied, so its font is null and its font size is 0. When the first text shown uses a zero font size, the font size comparison in buildTextContentItem is equal, and the font name comparison then reads name from that null font. With the default ignoreErrors, all of the text on the page was dropped.

This is the shape of the invisible watermark that Aspose.PDF adds (BT /F0 0 Tf ... (<base64>) Tj ET in a form XObject), so it affects real-world documents.

test/pdfs/issue22381.pdf is the reduced file from the issue: one size-0 run followed by Visible text.

  • Unit test: getTextContent with stopAtErrors: true now returns hiddenVisible text. Without the fix it fails with Cannot read properties of null (reading 'name').
  • Ref test: added a text entry to test_manifest.json.

gulp unittestcli locally: no new failures compared with master. The remaining local failures come from linked PDFs that weren't downloaded.

…font size (issue 22381)

The text state is cloned before any `Tf` is applied, so its font is `null` and its font size is `0`. When the first text shown uses a zero font size, the font size comparison in `buildTextContentItem` is equal, and the font name comparison then reads `name` from that `null` font. With the default `ignoreErrors`, all of the text on the page was dropped.
@zhaodengfeng

Copy link
Copy Markdown
Author

@Snuffleupagus Thanks for getting this fixed so quickly in #22384. I had submitted the fix and regression test here after reporting #22381, and I see that the separate PR has now been merged.

Could you clarify why a separate PR was preferred, and whether I should close this one as superseded? I'd appreciate understanding the preferred contribution workflow for future fixes. If the work here informed the final fix or test, a cross-reference from #22384 to this PR would also help preserve that contribution history.

Thanks for your help.

@Snuffleupagus

Snuffleupagus commented Oct 30, 2026 •

Copy link
Copy Markdown
Collaborator

Note that the two PRs were submitted mere minutes apart, which means that I had obviously not seen this one while working on #22384 locally.
In this case the choice was thus between an entirely human written PR by a longtime contributor, or what appears to be a more-or-less AI generated PR submitted by a new contributor.

@zhaodengfeng

Copy link
Copy Markdown
Author

Thanks for clarifying the timing. That answers my question about the parallel PRs.

Long-standing contributions deserve respect. I would hope that respect also extends to people making their first contribution. Experience lends weight to a technical assessment; it should not take the place of one.

If there are specific problems with the code or tests, I welcome that feedback. “New contributor” and “appears AI-generated” tell me how you have categorized the submission, but little about its correctness.

As for AI-assisted development, I think the useful discussion today is about how we verify the work and take responsibility for it. If the use of AI itself is enough to end that discussion, then we probably have little more to discuss.

The issue is fixed, which was my goal in reporting it and submitting a patch. I’m happy to leave it there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

getTextContent drops all page text ("Cannot read properties of null (reading 'name')") when the first text in a stream has font size 0

2 participants