Skip to content

v0.9.17

Latest
Latest

Choose a tag to compare

View all tags
@github-actions github-actions released this 05 Sep 19:05
v0.9.17
9d080ca
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

PeachPDF 0.9.17 Release Notes

Release date: September 5, 2026
Full changelog: v0.9.16...v0.9.17
Release tag: v0.9.17

PeachPDF 0.9.17 is a follow-up bug-fix release for the opt-in PDF/A (ISO 19005) conformance mode added in v0.9.16. Every showcase in the test suite was regenerated as PDF/A and validated against the real veraPDF reference validator (rather than checking a single document, as v0.9.16's own testing did) — this surfaced five real conformance gaps, all fixed here.

Highlights

PDF/A conformance gaps found by a full-showcase veraPDF sweep (#894)

  • Two bugs shipped in v0.9.16 that made every PDF/A document generated by that version non-conformant: embedded fonts never wrote the required /CIDToGIDMap entry, and images could still carry /Interpolate true (both forbidden by ISO 19005). Both are fixed, and the fonts/images produced now report correctly under every conformance level.
  • Three further bugs affecting any generated PDF, not only PDF/A output: annotations (e.g. <a> links) never carried the required /F flags key; a binary stream whose last byte happened to equal 0x0A could desync its /Length value from the actual bytes written; and a character with no glyph in any available font (including its CSS font-family fallbacks) could still reach a text-showing operator referencing the .notdef placeholder glyph. Under PDF/A conformance, that last case is no longer silently rendered — generation now throws a descriptive exception naming the uncovered character and font, so the document author can add a fallback font or remove the character, rather than shipping a file PdfAConformance claims is conformant but isn't.
  • All 109 showcases in PeachPDF.TestHarness were regenerated as PDF/A-2b and validated with veraPDF 1.30.2: the 101 that fully cover their own text now pass with zero rule failures; the other 8 correctly reject at generation time for using a font that doesn't cover their own content (an intentional, narrow choice in those specific showcases, not a regression).

Migration notes

A link (or other) annotation's /F flags key is no longer absent. Every PDF annotation now carries an explicit /F entry (at minimum, the Print flag) instead of relying on the PDF spec's own "absent means no flags" default. This affects every generated PDF, not just PDF/A output — no visual change in mainstream viewers, but a genuine, observable difference in the raw PDF bytes that a byte-for-byte comparison against prior output would catch.

Generating a PDF/A document with a character no font can render now throws, instead of silently emitting a .notdef placeholder glyph. If a document under any PdfAConformance level uses a character not covered by its font (and no CSS font-family fallback covers it either — e.g. an emoji or a script-specific character with no matching font), PdfGenerator.GeneratePdf/AddPdfPages now throws an InvalidOperationException naming the font and explaining the fix, rather than producing a file that silently fails ISO 19005 §6.2.11.8. Non-PDF/A output is unaffected — the .notdef glyph is still rendered as before when PdfAConformance is left at its default (None).

All Merged Pull Requests

  • Fold accumulated migration notes into the v0.9.16 release notes — #893
  • Fix PDF/A conformance gaps found by a full-showcase veraPDF sweep — #894
Assets 7
Loading