deps(deps): bump printpdf from 0.9.1 to 0.10.1

[dependabot]

⚠️ Dependabot is rebasing this PR ⚠️

Rebasing might not happen immediately, so don't worry if this takes some time.

Note: if you make any changes to this PR yourself, they will take precedence over the rebase.

---

Bumps printpdf from 0.9.1 to 0.10.1.

Changelog

Sourced from printpdf's changelog.

0.10.1 - font embedding hotfix

If you are on 0.10.0, upgrade. In 0.10.0 every external font embedded as an empty /FontFile2: readers reported "Cannot extract the embedded font", pdffonts reported "Embedded font file may be invalid", and no glyph rendered. A PDF that should have been 165 KB came out at 2.7 KB. Nothing warned and nothing failed.

0.10.0 cannot be repaired by releasing a fixed azul-layout. Cargo reads azul-layout = "0.0.9" as ^0.0.9 := >=0.0.9, <0.0.10, so for 0.0.z versions only 0.0.9 ever satisfies it - 0.10.0 is permanently pinned to the broken dependency. The fix had to come from printpdf, and it does: printpdf now retains font bytes itself and no longer depends on azul's retention policy at all.

Fixed

• External fonts embed as an empty /FontFile2. azul_layout::ParsedFont::from_bytes does not retain the source bytes (a deliberate perf change - layout and rasterization never read them, and retaining them duplicated a 4.27 MiB .ttc once per face). printpdf read them straight off the struct and .unwrap_or_default()'d the None into an empty Vec. printpdf::ParsedFont is now its own type, which attaches the source bytes explicitly, so embedding is correct against any azul-layout.
• Subset fonts had no .notdef. allsorts requires glyph 0 to be present and first in the subset glyph list; printpdf passed only the used glyphs, so the first real glyph was renumbered into slot 0. Subsetting "Roboto" produced R→0, b→1, o→2, t→3, and the R was drawn as .notdef.
• CFF/OpenType fonts were mislabelled. An OTTO font was written as CIDFontType2 + /FontFile2, both of which mean "TrueType glyf outlines". The descendant subtype is now taken from the sfnt magic of the program actually being embedded, and a full OTTO sfnt is written to /FontFile3 as /Subtype /OpenType.
• Built-in fonts emitted UTF-8 into a WinAnsiEncoding stream (#273). "Grüße aus Köln" extracted as "Grüße aus Köln" - the text was not copy-able or searchable. printpdf now owns the WinAnsi encoding table.
• The ' and " operators ignored the selected font, emitting raw UTF-8 - wrong for a WinAnsi built-in font and for an Identity-H external font, where the bytes must be glyph ids. The used-glyph collector also ignored them, so a page that drew text only via '/" registered no glyphs, its font was skipped as unused, and the text disappeared from the PDF entirely.
• A font that cannot be embedded now raises a PdfWarnMsg::error and omits /FontFile rather than writing a zero-length one. A missing font is a legal font that readers substitute for; an empty font program is a corrupt one they reject.

Changed

• printpdf::ParsedFont is now a printpdf type (a newtype over azul_layout::ParsedFont, with Deref, so the existing API is unchanged). It guarantees the source bytes are retained. ParsedFont::from_bytes, field access and method calls all work as before; into_inner() / as_azul() reach the underlying azul face, and printpdf::font::AzulParsedFont re-exports it.
• text_layout now pulls in rust-fontconfig, which is needed to name the type that carries the retained bytes.

... (truncated)

Commits

• See full diff in compare view

[dependabot]

Dependabot tried to update this pull request, but something went wrong. We're looking into it, but in the meantime you can retry the update by commenting @dependabot recreate.

[proggeramlug]

Heads-up before this gets merged as a security fix: it does not resolve RUSTSEC-2026-0187.

I checked out this branch and inspected its Cargo.lock:

printpdf  0.9.1 -> 0.10.1   (this PR)
lopdf     0.39.0 -> 0.39.0  (UNCHANGED — the vulnerable version)

The advisory is against lopdf 0.39.0 (severity 7.5, high) and requires >= 0.42.0. printpdf 0.10.1 still depends on 0.39.0, so cargo audit stays red after this merge.

The bump is still fine on its own merits — just don't let it close the security item. Tracked with the full picture in #7555, including the second advisory (rkyv 0.7.46 via rust_decimal) and the more serious structural problem: security-audit is a required context and has been red on main for its last six completed runs, which means every merge is currently bypassing it.