08 — Reuse and vendoring candidates: a survey of ~/Projects

Status 2026-09-15: survey requested by the founder ("look at every project in ~/Projects, find things already implemented we could reuse for the PDF stack"), run as five parallel passes (codecs/ compression; the RUSSL monorepo; fonts/PostScript/SVG/rendering; the NewDocFormat/ndf cluster; a sweep of everything else) across both the Mac and big-1. This file is the consolidated result. Nothing here has been ported or committed into any apdf-* crate — this is a candidate list for the founder and for lane briefs to draw on, gated the same way as everything else in this roadmap by the pause on 06-decisions.md. Every crate named below is either already on the internal Kellnr registry (import today, zero extra work) or a vendoring/publishing candidate under the same authorisation as LICENSE.md/SOUS_LICENCE.md (D-13 for permissive material; anything not permissive gets its own SOUS_LICENCE.md entry before use, same as every other artefact).

Read this first — five things that change how you read the rest of the file:

1. ndf-pdf looks like it is being edited right now, by someone else. ~/Projects/Rust/ NewDocFormat/crates/ndf-pdf on big-1 (158,181 lines) is a sibling, independently-written PDF implementation — not legacy code asklera-PDF was extracted from, a second, still-active implementation living in a different project. Its working tree shows uncommitted changes and mtimes from essentially the time of this survey. Do not touch or port anything from it without finding out who is working on it first. See §A.
2. There are three parallel from-scratch codec ecosystems, not one: ~/Projects/CODECS (russl-codec-*, ~148 crates, mostly published on Kellnr already), ~/Projects/Rust/Image ("Iris", iris-codec-*, ~140 crates, clean-room, not yet published), and a COMPRESSION sub-workspace inside ~/Projects/Rust/MYLIB that may duplicate or predate CODECS. This needs a founder-level consolidation decision (§B) before any of them becomes "the" dependency for a given PDF filter — right now the same filter (JBIG2, CCITT, JPEG, LZW, Flate) usually exists clean-room-implemented twice.
3. The JPEG 2000 / JPX family in CODECS is licensed Proprietary, unlike its Flate/LZW/CCITT/ JBIG2 siblings which are MIT OR Apache-2.0. This is a real, already-existing precedent for the open-core split under discussion in D-1: keep advanced/differentiating codecs closed, keep the commodity ones open.
4. Kellnr version strings can lie about content (known project gotcha, kellnr-same-version- different-content.md). Several crates named below sit at 0.1.4-beta.3. Diff the actual .crate tarball against current source before depending on version numbers alone.
5. Two clusters are reverse-engineered material and must go through the clean-room ABI-firewall process, never copied directly: ~/Projects/InDesign and ~/Projects/Affinity/ affinity_decompile (Ghidra/DWARF/PDB decompilation of Adobe InDesign and Affinity). See §G.

Quick reference — PDF filter/feature → candidate crate

A. ndf-pdf — a second, active PDF implementation (highest-urgency finding)

~/Projects/Rust/NewDocFormat/crates/ndf-pdf on big-1, Apache-2.0, same author, 158,181 lines, forbid(unsafe_code), RUSSL crypto throughout (same doctrine as asklera-PDF). It is the PDF↔NDF bridge for NewDocFormat, a separate clean-room document-format project — not the origin asklera-PDF was extracted from, a sibling that kept going. Coverage includes several things still open in asklera-PDF's own roadmap: full PDF 1.0–2.0 parser (lenient+strict), IR, writer, XFA parsing, JBIG2/CCITT/JPX decode wiring, CFF/Type1/sfnt handling with embedded-font subsetting, AFM widths, encoding tables, ICC, PAdES-style sign+verify+RFC 3161 timestamp, accessibility tagging, prepress marks, and a large edit/ module: merge/split/rotate/stamp/watermark/redact/flatten/ outline/attach/OCG/textsearch/linearize/pagebox/session/JavaScript handling/form-create. Redaction, linearization, JS-subset handling (D-30) and XFA (P3-g) are all still open items here.

The two codebases are already cross-pollinating: recent commits (fd6ee5346, 44cde347e, 2026-09-12/13) show ndf-pdf's security handler now consumes asklera-PDF's own apdf-crypt/ apdf-object from Kellnr, and two other recent commits fixed bugs described as "same as apdf-font 0102ffa" / "same as apdf-filter ba2615b" — the same defect, found and fixed twice, independently.

Recommendation: a dedicated reconciliation lane, module by module, deciding per module "port", "leave to ndf-pdf as the NDF↔PDF bridge only", or "already superseded by apdf-*". Not a blanket import — the two codebases have diverged designs and silently merging risks exactly the double-bug pattern already observed. First step before any of that: find out who is actively editing it right now and coordinate, per the concurrent-edit signal above.

~/Projects/Rust/pdf-corpus-real (1.8 GB, 1,491 files: arxiv/generated/govt/scanned/verapdf/web) is a real-world, non-adversarial PDF corpus assembled alongside ndf-pdf's work, PROVENANCE.md marks it non-redistributable — usable as an additional internal-only oracle corpus, genuinely different in distribution from what is already in tests/corpus. ~/Projects/Rust/ ndf-import-helper's ndf_census/pdf_scene binaries batch-analyse a whole corpus and tabulate feature usage — worth mirroring in apdf-cli if it doesn't already do this (this is exactly brainstorm idea #8, SafeDocs-at-scale). NDF_RUST (native GPU desktop editor), NDF_WEB (marketing site), ndf-clean-check/ndf-freshclone-issue2 (disposable fresh-clone checks), ndf-clrev (a bare symlink to RUSSL) and ndf-corpus-out (235 MB of test-run output, not a corpus) carry no further reuse value for asklera-PDF.

B. Codecs and compression

B.1 ~/Projects/CODECS (~/Projects/Rust/CODECS on the Mac side's mental map — physically at

/home/ezechiel203/Projects/CODECS, symlinked into ~/Projects/Rust/)

The workspace already backing asklera-PDF's own filters (russl-codec-*/russl-entropy-*, ~148 crates, MIT OR Apache-2.0 except the JPEG 2000 family). See the quick-reference table above for the filter-by-filter mapping; beyond those, russl-entropy-mq (MQ arithmetic coder, T.800 Annex C / T.88 Annex E, shared by JPEG2000 and JBIG2) and russl-bitio/russl-checksum (CRC-32/Adler-32) are already-published utility dependencies underneath the filter crates. russl-codec-pdf ("clean-room PDF embedded-image extractor, image XObject extraction only", not yet on Kellnr) is narrow enough to be superseded by asklera-PDF itself — useful only as a cross-check, not for reuse. russl-codec-mrc is a false-friend name collision: cryo-EM/ crystallography MRC2014 volume data, unrelated to Mixed Raster Content compression — skip for that purpose.

B.2 ~/Projects/Rust/Image ("Iris"; iris-psres-wt/iris-pstype1-wt/iris-svgfilt-wt are

just topic-branch worktrees of this same repo)

A second, largely parallel, zero-crates.io-dependency clean-room codec ecosystem, ~140 crates, MIT OR Apache-2.0, not yet published to Kellnr at all. Beyond the codec mirror (quick-reference table above), it has a document-composition layer CODECS does not:

• iris-doc-pdf — 62,000–72,000 lines depending on counting method — "PDF as a paged document: compose images into a PDF, and read pages back out." By far the largest single crate found in this whole survey. Narrower in purpose than asklera-PDF (image-in/pages-out, not full ISO 32000-2), independently designed. Do not merge wholesale — mine it for edge cases and cross-oracle test vectors, evaluate deliberately, don't treat it as a drop-in.
• iris-doc-ps — bounded PostScript/EPS interpreter, see the D-37 row above.
• iris-doc-crypto — "PDF standard-security-handler decryption, over audited RUSSL primitives" — same crypto rule as asklera-PDF; worth diffing against apdf-crypt's standard security handler for gaps or cross-validation.
• iris-doc-font, iris-doc-djvu — see quick-reference table.
• iris-py — PyO3 bindings for Iris (a Pillow-alternative), deliberately kept outside the zero-dep workspace since PyO3 is third-party. Not reusable for PDF directly, but a ready-made template for asklera-PDF's own Phase-1 Python bindings (D-6 ADR-bindings, PyO3/maturin) — same thin-cdylib-wrapper pattern is directly transferable.

Open question for the founder (not resolved by this survey): why two near-parallel codec stacks exist side by side (russl-codec-* vs iris-codec-*) — whether "Iris"/Image was a separate product line (print/imaging-focused) rather than redundant effort. Answering this decides whether CODECS or Iris (or both, kept for cross-validation) becomes canonical for asklera-PDF.

B.3 The JPX licensing precedent (feeds D-1)

CODECS' entire JPEG 2000 / JPX family is marked license = "Proprietary" while every sibling codec in the same workspace (Flate, LZW, CCITT, JBIG2) is MIT OR Apache-2.0. This is a real, already-in-production precedent for the open-core distribution model under discussion (D-1): keep the commodity filters permissive (what gets embedded everywhere), keep the differentiating one closed. Iris's JPX equivalent is MIT OR Apache-2.0, so if JPX needs to stay open for some reason, that's the fallback.

B.4 General-purpose compression research

~/Projects/Rust/NewComprAlgo (crate strux; NewComprAlgo-findings/-main are copies; STRIX/ COMPR_STRIX/strox are earlier, superseded iterations — STRIX even has its own PROJECT-CLOSE.md) — see the quick-reference table. ~/Projects/HUTTER (top-level, not under Rust/) is unrelated Hutter-Prize neural text-compression research (LSTM), no plausible reuse path for binary/structured PDF stream compression. ~/Projects/Rust/MYLIB's COMPRESSION sub-workspace (lzma/bzip2/lzo/lzfse/lzx/lz4/snappy) needs a dedup check against CODECS before being treated as an independent source — it may duplicate or predate it.

B.5 Test corpora (internal-only — never redistribute, same policy as every third-party corpus already in this project)

djvu-corpus (1.5 GB, 176 real scanned DjVu documents from Wikimedia Commons, per-file licensed in work/real_manifest.tsv), ps-corpus/ps-extra (PostScript/EPS from cairo-pdftocairo, groff-grops, Ghostscript, ImageMagick, jburkardt — PROVENANCE.md+MANIFEST.tsv), svg-corpus/ svg-extra (W3C SVG 1.1 suite, resvg-tests, Wikimedia SVGs, icon sets, plus resvg/usvg themselves in svg-extra — those two crates are permissively licensed and worth evaluating as an alternative SVG rasterizer to iris-codec-svg, independent of the corpus question).

C. The RUSSL monorepo — answering three open ADR questions (D-6)

Surveyed at ~/Projects/Rust/RUST_PROJ_RSMBD/crates/RUSSL (1,142 russl-* crates), cross-checked against the live Kellnr registry.

• ADR-pcsc — partial hit, smaller gap than it looked. No PC/SC transport crate exists (russl-iso7816's own doc explicitly excludes PC/SC/CCID/NFC/T=0/T=1 framing as "out of scope; a caller supplies a CardTransport"). But the two layers above transport already exist: russl-pkcs11 (Kellnr 0.3.0, "PKCS#11 ABI, client and backend-driven provider primitives", 23 tests against a disposable SoftHSM/OpenSC/OpenSSL oracle — not multi-vendor-certified) and russl-iso7816 (local only 0.1.0, no_std, forbid(unsafe_code), 5 tests, full APDU codec + BER-TLV + Secure Messaging, 3DES/retail-MAC byte-for-byte verified against ICAO 9303 Pt.11 App.D.4). Once a CardTransport exists (the external pcsc crate, or a new minimal RUSSL wrapper over PCSC-lite/WinSCard), the rest of the generic smartcard stack in the roadmap's §G is already there.
• ADR-xml — answered, RUSSL has it. russl-xmlsec (Kellnr 0.1.1, 15 tests, C14N 1.0/1.1/exclusive + XMLDSig 1.1 with structural signature-wrapping defences already designed in) covers the XAdES/canonicalization need directly. russl-xmlenc (Kellnr 0.1.0, decrypt-only by design) covers XML decryption if that's ever needed. Integrate russl-xmlsec rather than extending asklera-PDF's own minimal XML reader for canonicalization.
• ADR-zip — partial hit. No standalone general-purpose zip crate, but russl-asic (local only 0.1.0, 3 tests, "Associated Signature Containers (ETSI EN 319 162): strict ZIP reader/ writer, ASiC-S/ASiC-E model, manifests and coverage") bundles one (zip.rs), hostile-input-first. This is also a direct, already-planned dependency for lane P3-h ("ASiC/XAdES containers") in 05-battle-order.md — not a new find so much as something already sitting there unintegrated. Whether zip.rs is generic enough for OFD/EA-PDF or hardwired to ASiC's mimetype-first/STORED rule needs a one-file read before reuse; if it's ASiC-coupled, the zip gap for the fully generic case stays open (external permissive crate under D-13).

Also found, relevant to PAdES/LTV beyond what's already integrated: russl-tsa (Kellnr 0.1.5, 11 tests, no_std-capable, RFC 3161 TSA protocol), russl-crl-validator (Kellnr 0.1.1, pure Rust RFC 5280, 10 tests — bundled signature verification is Ed25519-only), russl-ocsp- responder (Kellnr 0.1.1, RFC 6960 server-side, 8 tests — new relative to what asklera-PDF already has client-side), russl-x509-ocsp (Kellnr 0.1.2, RFC 6960 client, 8 tests) — worth a diff against whatever OCSP/CRL crates are already integrated, these may be newer/alternate rather than duplicate. russl-archive-crypto (local only, WinZip AES AE-1/AE-2, 7-Zip AES-256 KDF, legacy ZipCrypto — explicitly not a container-format parser) matters only if a password-protected ZIP payload (an encrypted OFD/ASiC) ever needs decrypting. No RUSSL finding for barcode/QR, hyphenation, text-shaping, ICC colour or fonts, as expected for a crypto monorepo.

D. Fonts, PostScript, SVG, rendering (see also §B.2 for the Iris codec/doc crates)

• ~/Projects/PRISM-VG (note: at ~/Projects/PRISM-VG, not under ~/Projects/Rust/) — see the D-9 row in the quick-reference table. MIT OR Apache-2.0, actively developed (daily commits, WASM demo, font-fallback work), but built on the Blitz browser-engine stack (blitz-dom/ blitz-html/blitz-paint, alpha versions) plus kurbo/peniko/skrifa/anyrender — a real departure from this project's audited/first-party-only dependency posture. Vendor with adaptation, and give it its own ADR before adopting, don't default-yes it.
• ~/Projects/Rust/prism (NDF Prism, distinct from PRISM-VG above) — a non-destructive imaging format (RAW-style master + render-op recipe) with print CMYK/spot-ink + ICC awareness and medical (DICOM-class) windowing, Apache-2.0, unsafe_code = forbid, cleanly extracted from the NDF monorepo as its own workspace. Not a PDF crate itself — a cross-vertical reference for §K (prepress/print) and §L (health) ICC/CMYK handling, not a direct dependency.
• ~/Projects/Rust/UI_VITRAIL_PROJECT — a full native Rust UI framework (desktop/mobile/web, own rasterizer/text stack/scene graph, hot reload, WYSIWYG designer, MCP server, headless UI testing via vitrail-sim), actively developed (daily commits). Candidate base for roadmap lane P2-f (PDF inspector/linter GUI, "egui → WASM"). This is heavyweight and still-evolving with a large surface (Android/iOS packaging, app-store crates); evaluate specifically its rendering/ canvas layer for a lightweight inspector, not the whole framework — its own ADR-level decision, not a default yes.

E. Signing, trust, and timestamping servers (~/Projects/WEB_PLATFORM) — production-grade

The strongest cluster found outside the codec/font space — tested against real external oracles, not prototypes:

• ~/Projects/WEB_PLATFORM/tsa (asklera-tsa-server) — a complete RFC 3161 timestamping authority, ETSI EN 319 421-compliant, serial-log discipline, tested against real OpenSSL TS exchanges (tests/openssl_ts.rs). Directly backs PAdES-T/LT/LTA timestamp levels (F-034).
• ~/Projects/WEB_PLATFORM/signing (asklera-signing-server) — a full AdES signing service (B-B/B-T/B-LT/B-LTA) on top of russl-cades, verified against the EU's own DSS validator (TOTAL_PASSED per EN 319 102-1), with tests/long_term.rs proving the LTA construction end-to-end against a real RFC 3161 exchange. Keeps the private key out of the crate — KMS/HSM/ smartcard-ready by design, exactly the shape needed for lane P3-e's external-signer trait. Use as the direct architectural template — likely a direct code source — for PAdES level orchestration; russl-cades (CAdES, PAdES's sibling format) should be checked for reuse alongside it.
• ~/Projects/WEB_PLATFORM/id-platform/crates/asklera-trustlist — a complete, tested EU LOTL + national Trusted-List parser/verifier doing the two-step anchor verification correctly (LOTL against OJ-published anchors, national lists against LOTL-declared certs, never trusting a self-declared KeyInfo), plus status/freshness/point-in-time checks (tests/lotl.rs, real_list.rs, point_in_time.rs, vectors/). This is precisely lane P3-e's EU trust-store requirement (F-034) — reuse directly rather than reimplement.
• ~/Projects/WEB_PLATFORM/preservation (asklera-preservation-server) — archival evidence-record sealing/renewal (RFC 4998 ERS via russl-ers, hash-tree renewal, testable at arbitrary now). Template/source for PDF/A + PAdES-LTA long-term validation renewal (brainstorm idea #19, "PDF time machine"; archival vertical P4).
• ~/Projects/WEB_PLATFORM/id-platform/crates/asklera-id-server (mdoc.rs, eudi.rs) — ISO/IEC 18013-5 mdoc verification and EUDI Wallet (OpenID4VP/SD-JWT VC) presentation verification against a trust list. Relevant to atlas §O (government identity/barcodes) and brainstorm #12 (signed 2D barcodes / credential-bearing documents) — lower priority than the four above, worth linking regardless.

F. Smartcard/HSM design references

• ~/Projects/HSM_KEY_Project (Mac, mirrored at big-1 under MAC_IMPORTS/) — real Rust HSM firmware: hsm-applet-piv, hsm-applet-openpgp, hsm-proto-iso7816, hsm-usb-ccid, hsm-test-vectors. Candidate source/oracle for the generic smartcard layer's PIV/OpenPGP applet and ISO 7816 protocol handling (atlas §G, D-19); hsm-test-vectors is particularly useful as an oracle.
• ~/Projects/libcps (Mac — the deprecated pre-libcps-rs repo, distinct from the current libcps-rs) — crates libcps-pkcs11, libcps-pkcs15, libcps-piv, libcps-pcsc, libcps-ctk (CryptoTokenKit). Mine for the architecture/interface shape of the generic PKCS#11/PKCS#15/PIV/ PC-SC/CTK path even though the crate itself is deprecated and less safe than libcps-rs per existing project notes — a design reference to port, not a code source to copy wholesale; audit anything actually taken.

G. Reverse-engineered material — clean-room process only, never direct reuse

~/Projects/InDesign and ~/Projects/Affinity/affinity_decompile (big-1) are active Ghidra/ DWARF/PDB decompilation of Adobe InDesign v21.4.1 and Affinity (RTTI/vtable recovery, object-model reconstruction, symbol databases) — exactly the kind of PDF-adjacent prior art one would want to learn from, and exactly the kind of material this project's existing clean-room ABI-firewall policy exists for. No code from here may be copied directly. Any reuse must go through the two-agent firewall already established for this project: one agent reads the decompiled material and writes a specification; a separate, isolated agent implements from that specification only, never seeing the decompiled source. This survey did not read decompiled code bodies, only confirmed scope.

H. Patterns worth copying (not code, but approach)

• ndf-import-helper's ndf_census/pdf_scene binaries (batch-analyse a whole corpus, tabulate feature usage) — check whether apdf-cli already does this; if not, this is exactly brainstorm idea #8 (SafeDocs-at-scale) waiting to be mirrored.
• iris-py's thin-cdylib PyO3 wrapper — a ready template for asklera-PDF's own Phase-1 Python bindings (D-6 ADR-bindings).

I. Checked and excluded

Confirmed unrelated to the PDF stack, no further action: the CPU-emulation/retro-computing/ compiler-backend cluster (ElectroSim, ChipSim, ALPHA, per-language scratch dirs C/Cpp/ Haskell/Java/Js/Lua/Ruby/Scala/Ts, i8085*, i286_builder…i686_builder, early-x86-llvm*, x8616*, rustc-x8616*, rustc-ice-*, martypc, llvm21-src, retro_pc_stuff) — a separate, unrelated research program; text_to_web (a directory-listing HTTP server, AGPL, nothing document-related); vlc-rs (empty stub); revenant-rs, ferry-rs (design-phase only, no code, unrelated domains); WEB_PLATFORM/crypto-manifest (retired into russl-cbom, an SBOM concern not a PDF one); WEB_PLATFORM/adid, agecheck (a different, "generalist" cybersecurity brand); ~/Projects/ref (already fully tracked in SOUS_LICENCE.md and atlas §F); ~/Projects/RESEARCH/compression (papers, overlaps §B.4, no new code); Asklera/ ASKLERA big-1 mirrors and Asklera-core (already tracked in project memory, out of this survey's depth budget); on the Mac: apicrypt-py, efficience_icanopee, SrvSVcnam_engine, DrSante_export, doctolib_109, Doctolib_119 (RE/export dumps of third-party health/billing software, unrelated product line), CryptiLib (CPS vulnerability-research scripts), ANS_AUDIT (just holds known cvlib-rs/libcps-rs checkouts), AUDIT_FRANCE (separate audit programme), ISCSI-macos (unrelated storage protocol), www.docbetry.fr (personal-site infra — its Markdown→HTML pattern is already mirrored in the pdf-job.asklera.fr render server itself), cps-vitale-desktop (a Tauri/Svelte UI pattern reference only, not a code source), Mountit/ Mountit-web (a separate cloud-storage product), FORKS (unrelated external tool forks: pcloud-rs, lsd, lsd-next, nvim-treesitter-eze, zellij), MAC_IMPORTS (confirmed mirror of the Mac tree, no independent content), REVENUE, bluebear, smbr-client, prng, Misc.

J. Immediate open questions for the founder

1. Who is editing ndf-pdf right now? (§A) — coordinate before any reconciliation lane starts.
2. Consolidate or keep both codec ecosystems? russl-codec-* vs iris-codec-* implement the same filters twice, independently, clean-room both times (§B.2). Kellnr publication, dependency weight, and future maintenance all depend on this answer.
3. The JPX proprietary-vs-permissive split already exists in CODECS (§B.3) — a live precedent for D-1, worth citing there.
4. russl-codec-jpeg's arithmetic-coding path is ported from libjpeg-turbo — verify that licence specifically before vendoring that code path; the rest of the crate is clean-room.
5. Publish Iris's ~140 iris-* crates to Kellnr, or leave them as a reference/oracle only? Depends on question 2.
6. PRISM-VG and UI_VITRAIL_PROJECT both pull in heavyweight/alpha dependency chains (Blitz; a full app-platform's worth of crates respectively) — each needs its own ADR-level review before adoption, not a default yes, even though both are strong functional matches (D-9 and P2-f).

Cross-references: this file is linked from 00-README.md's file index, from 05-battle-order.md (lanes P2-f, P3-e, P3-f, P3-h), and from 06-decisions.md (D-1, D-6, D-9, D-19, D-37).