tecnickcom/tc-lib-pdf-font
Font import, metrics, and runtime font-stack utilities for PDF generation in PHP. Supports core, Type1, and TrueType fonts, glyph width and bounding-box helpers, character fallback, and composite font encoding.
Architecture fit. tc-lib-pdf-font is a single-responsibility leaf library: font import, metric extraction, encoding handling, and font-stack (fallback-chain) management. It does not render documents — it feeds a PDF composition engine. That makes it a clean architectural fit as a transitive dependency of tecnickcom/tc-lib-pdf, but a poor fit as a direct dependency unless we are deliberately building our own composition layer on top of the tc-lib primitives. The decision to evaluate is therefore not "adopt this package" but "adopt the tc-lib-pdf family, of which this is one of ~10 lockstep-versioned modules."
Integration feasibility. Composer-only, PSR-4, no Laravel coupling, no service provider required. A working spike — load a TTF/OTF, read metrics, register a fallback stack, emit a document through tc-lib-pdf — is a 1–2 day effort. The real integration work is configuration and caching (font registry paths, metric cache backend, upload validation), not wiring.
Technical risk.
NOASSERTION. This is a hard gate, not a footnote. The TCPDF lineage is LGPL-family, but an unrecognized license string means legal must confirm before commercial distribution. Treat as blocking for a shipped product.tc-lib-pdf, which means our exposure is inherited rather than chosen. Diligence should measure the parent package, not this one.Last release: 2026-10-17 is a future date. Verify tag provenance, Packagist integrity, and that the release actually corresponds to a commit we can audit.Key questions. Which exact tc-lib-pdf version pins which font-lib version, and are they released in lockstep? Do our documents require CJK, RTL, or emoji — and does the stack handle fallback without silent glyph substitution? Who is authorized to add fonts, and where do they live (local disk vs. object storage)? What is our detection strategy for the failure mode where subsetting produces wrong glyph widths — which corrupts output visually without throwing? Who owns the license determination and by when?
Stack fit. Native to PHP/Laravel via Composer; no framework opinions to fight. The one Laravel-specific hazard is long-running workers: verify whether the font stack or metric caches are held in static/singleton state. If so, Octane and Swoole will leak fonts and metrics across requests, and the library must be resolved per-request or explicitly reset.
Migration path. If we are on TCPDF, mPDF, or dompdf, do not migrate to this package — migrate to tc-lib-pdf and accept this as an internal detail. If we are greenfield or replacing a broken font pipeline, pilot the parent package behind a PdfRenderer interface with a narrow contract (render(template, data): stream). That interface is the real deliverable; it makes the font library swappable and caps the blast radius of an upstream stall.
Compatibility. Confirm the PHP constraint against our floor (Laravel 10/11 implies 8.1+), required extensions, and supported font formats (TTF/OTF/Type1/core AFM). Expect Composer conflicts with any other PDF library over the tecnickcom/tc-lib-* namespace — do not plan to run two PDF stacks in one application.
Sequencing.
tc-lib-pdf.PdfRenderer interface; make the font registry config-driven, not hardcoded paths.Maintenance. Low code volume, non-trivial upgrade cadence across the lockstep family — a bump to one module usually means bumping all of them. Pin exact versions, never ranges, and keep a single compatibility test that renders a golden document. The maintenance burden is coordination, not code.
Support. No commercial SLA; GitHub issues only. We need an internal runbook covering font onboarding, cache invalidation, and "output looks wrong" triage. Sponsoring the maintainer is cheap insurance and buys issue visibility — recommend it as an explicit budget line.
Scaling. Font import and metric extraction are CPU-heavy but one-time per font; the correct posture is precompute-and-cache (filesystem or Redis, warmed at deploy), never parse per request. Font programs load into memory, so PDF generation belongs on queue workers with a concurrency cap, not in the request path. Watch cache growth — unbounded font caches are a slow disk-fill incident.
Failure modes. Missing glyph resolves to a substitute character rather than an error — the dangerous case, caught only by output diffing. Corrupt or hostile font files throw or fatal, caught by validation and upload gating. Octane state leakage produces cross-tenant font bleed. Upstream abandonment leaves us pinned to a version with no security patch path — the mitigation is the renderer abstraction plus a documented fallback to a maintained commercial engine.
Ramp-up. The API surface is small; the domain is not. Encodings, CID fonts, and subsetting semantics are where engineers lose time. Budget one to two developer-weeks for a mid-level engineer to reach productive confidence, and pair that with a half-day of legal review — the license question is the longest-lead item and should start on day one, not at release.
How can I help you explore Laravel packages today?