[dependabot]

Bumps the gomod group with 1 update in the /bench directory: golang.org/x/image.
Bumps the gomod group with 3 updates in the /harness directory: github.com/go-pdfkit/reader, github.com/go-pdfkit/render and github.com/klippa-app/go-pdfium.

Updates golang.org/x/image from 0.46.0 to 0.47.0

Commits

• c437a91 go.mod: update golang.org/x dependencies
• See full diff in compare view

Updates github.com/go-pdfkit/reader from 0.6.0 to 0.9.0

Release notes

Sourced from github.com/go-pdfkit/reader's releases.

v0.8.0 — an Operation says which bytes of the stream it is

Operation gains Start and End: the byte range of the operation in the stream it was scanned from — Start at its first operand (or at the operator when it has none), End just past the operator.

⛔ They are here so a content stream can be edited in place

A tool that wants to put something before every BT has two honest ways to find one:

• re-serialise the whole stream, which risks changing what an inline image's bytes mean;
• know where the operator was — and this scanner is the only thing that does.

BT appears inside strings, inside names, and inside an inline image's data, and a byte search cannot tell those from an operator. The test pins the discriminator:

(BT in a string) Tj  BT /F1 12 Tf ET
 ^ byte search: 1                      ← inside somebody's text
                     ^ the scan: 20     ← the operator

A tool splicing at index 1 corrupts the string.

Two details that are easy to get wrong

• End is the lexer's position, not the operator's start plus its length. An inline image's operator token is BI and its operation runs to the EI three keywords later, so measuring from the operator would put the end in the middle of the image's data — where a splice corrupts the image instead of the stream around it. Asserted;
• Start is the first operand's position, so splicing before an operation does not land between its operands and its operator. 1 0 0 RG starts at the 1, not at the RG.

The ranges of a stream are asserted ordered and disjoint, which is what lets a caller splice at several of them in one pass, and a stream with rubbish in it keeps honest ranges around what the scan stepped over.

Why in reader rather than in the caller

Three packages already scan content streams through this one scanner — extract, render and latex — so the primitive is shared already; what was missing was the one fact only the scan has. The first consumer is go-pdfkit/ops, for a verb that recolours text without touching anything else.

Checks

... (truncated)

Commits

• b3ad122 TextString: what the document says in a human language (#34)
• 9f160d6 An Operation says which bytes of the stream it is (#33)
• 0b1ae6a ci: move the Go pin from 1.27.1 to 1.27.2 (#32)
• 1fc4b80 build: raise the Go floor to 1.27.1 (#30)
• 34a97c1 Let the lane's name say how it ran (#28)
• 98fdaa6 Run the tests on macOS and Windows, which were only ever cross-compiled (#27)
• d5b36b3 Run the 386 lane without an emulator, because qemu-i386 loses float state (#26)
• 1c95bd4 Run the tests where poppler does not go, and on 32-bit (#25)
• d297ebe chore(deps): update dependency go to v1.27.1 (#24)
• 7f75070 chore(deps): update dependency go to v1.27.0 (#22)
• Additional commits viewable in compare view

Updates github.com/go-pdfkit/render from 0.67.0 to 0.69.0

Release notes

Sourced from github.com/go-pdfkit/render's releases.

v0.69.0

Release backfilled on 2026-10-26; tag created 2026-10-20.

Commits since v0.68.0:

• d6de036b fix(deps): update dependencies (#119)
• d128cba4 Security: bump go-images/jpeg2000 to v0.13.8, a PDF could crash Page (#120)

v0.68.0

Release backfilled on 2026-10-26; tag created 2026-10-18.

Commits since v0.67.2:

• c3ea7ae9 fix(deps): update dependencies (#110)
• a80d887c A form XObject's incomplete /Resources no longer shadows the enclosing ones (#103)
• 3ad80798 Three timing tests take their two minima INTERLEAVED, not in blocks (#106)
• 7d8ddd37 README: name the decoders, because which one runs is the point (#107)
• 0755d968 Run on arm64 LINUX and on the BSDs, rather than only building for them (#111)
• 4e54b0b5 Images returns the inline ones, so 4 147 pictures of one population can be compared at all (#105)
• 3bb5dcfb Benchmarks, because "would SIMD help" cannot be asked without a baseline (#112)
• bc1e496d ci: move the Go pin from 1.27.1 to 1.27.2 (#115)
• 2e048628 fix(deps): update dependencies (#114)
• 2efa2338 Count the asks instead of timing them (#116)
• 3f9096dc Bump go-images/jpeg2000 v0.13.3 -> v0.13.5 (#117)
• 83c95751 Bump go-images/jpeg2000 v0.13.5 -> v0.13.7 (#118)

Commits

• d128cba Security: bump go-images/jpeg2000 to v0.13.8, a PDF could crash Page (#120)
• d6de036 fix(deps): update dependencies (#119)
• 83c9575 Bump go-images/jpeg2000 v0.13.5 -> v0.13.7 (#118)
• 3f9096d Bump go-images/jpeg2000 v0.13.3 -> v0.13.5 (#117)
• 2efa233 Count the asks instead of timing them (#116)
• 2e04862 fix(deps): update dependencies (#114)
• bc1e496 ci: move the Go pin from 1.27.1 to 1.27.2 (#115)
• 3bb5dcf Benchmarks, because "would SIMD help" cannot be asked without a baseline (#112)
• 4e54b0b Images returns the inline ones, so 4 147 pictures of one population can be co...
• 0755d96 Run on arm64 LINUX and on the BSDs, rather than only building for them (#111)
• Additional commits viewable in compare view

Updates github.com/klippa-app/go-pdfium from 1.21.1 to 1.21.4

Release notes

Sourced from github.com/klippa-app/go-pdfium's releases.

v1.21.4

What's Changed

• Update Pdfium to 8111 by @​jerbob92 in klippa-app/go-pdfium#383
• Bump github.com/onsi/ginkgo/v2 from 2.33.0 to 2.33.1 by @​dependabot[bot] in klippa-app/go-pdfium#381
• Bump golang.org/x/text from 0.42.0 to 0.43.0 by @​dependabot[bot] in klippa-app/go-pdfium#382

PDFium update to 8111

PDFium has been updated to 8111 and the new experimental methods FPDFPageObj_GetRenderedFillPattern, FPDFAttachment_GetAFRelationship, and FPDF_StructElement_GetRawType. The WebAssembly version is now compiled with Emscripten 6.0.13.

More patches have been upstreamed in PDFium 8111, so upgrading your PDFium version to 8111 should give you a nice speed improvement if you're rendering PDFs. This speed improvement mostly affects rendering of PDFs that have images.

Full Changelog: klippa-app/go-pdfium@v1.21.3...v1.21.4

v1.21.3

What's Changed

• Exclude shared_tests/testdata from the module zip by @​trcyberoptic in klippa-app/go-pdfium#380

New Contributors

• @​trcyberoptic made their first contribution in klippa-app/go-pdfium#380

Full Changelog: klippa-app/go-pdfium@v1.21.2...v1.21.3

v1.21.2

What's Changed

• fix: decode PDFium text as UTF-16LE without looking for a byte order mark by @​gkswns0531 in klippa-app/go-pdfium#379

New Contributors

• @​gkswns0531 made their first contribution in klippa-app/go-pdfium#379

Full Changelog: klippa-app/go-pdfium@v1.21.1...v1.21.2

Commits

• 7d0f255 Merge pull request #382 from klippa-app/dependabot/go_modules/golang.org/x/te...
• f9cba4a Merge pull request #381 from klippa-app/dependabot/go_modules/github.com/onsi...
• 6e87499 Merge pull request #383 from klippa-app/feature/update-pdfium-to-8111
• 11bf9b4 Update Pdfium to 8111
• 4083eee Bump golang.org/x/text from 0.42.0 to 0.43.0
• 8b3788f Bump github.com/onsi/ginkgo/v2 from 2.33.0 to 2.33.1
• b3dd06d Merge pull request #380 from trcyberoptic/exclude-testdata-from-module-zip
• 7cad800 Exclude shared_tests/testdata from the module zip
• 8edf929 Merge pull request #379 from gkswns0531/fix/utf16le-no-bom-detection
• 8ee16e6 fix: decode PDFium text as UTF-16LE without looking for a byte order mark
• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore <dependency name> major version will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
• @dependabot ignore <dependency name> minor version will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
• @dependabot ignore <dependency name> will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
• @dependabot unignore <dependency name> will remove all of the ignore conditions of the specified dependency
• @dependabot unignore <dependency name> <ignore condition> will remove the ignore condition of the specified dependency and ignore conditions