Tc Lib Pdf Page Laravel Package

Technical Evaluation

Architecture fit. This is a leaf-level geometry component, not a PDF engine and not a Laravel package. It models page dimensions, orientation, unit conversion, and the PDF box set (MediaBox, CropBox, TrimBox, BleedBox, ArtBox). There is no service provider, config file, facade, or framework coupling of any kind — it is plain namespaced PHP under \Com\Tecnick\Pdf\Page. The constructor signature ('mm', Color\Pdf, Encrypt\Encrypt, two booleans) is the tell: the library assumes it is being composed inside the tecnickcom/tc-lib-pdf stack, not instantiated by application code. The correct architectural placement for a Laravel application is therefore a transitive dependency behind the aggregate tc-lib-pdf package, consumed through an internal rendering abstraction. A direct composer require of this package alone buys us nothing renderable — it produces page metadata structures that some other layer must serialize.

Integration feasibility. Mechanically trivial: one Composer command, no native compilation, only zlib required, PHP 8.2+. The cost is not installation, it is ownership. Adopting this library effectively means adopting the tc-lib-pdf composition layer (fonts, images, colors, encryption, output), because this package is not useful in isolation. That is a pipeline decision, not a dependency decision.

Technical risk.

• License ambiguity. GitHub reports NOASSERTION while the README states LGPL-3.0. For a hosted SaaS this is typically acceptable (dynamic linking via Composer, no distribution), but any on-prem, desktop, or appliance distribution requires legal review before we build on it. Resolve this before the spike, not after.
• Bus factor. Seven stars, zero listed dependents, single named maintainer. The 100M+ install claim belongs to the TCPDF lineage, not to this repository, and should not be read as support for this specific package.
• Provenance oddity. Last release dated 2026-10-24 — a future date relative to normal observation windows. Verify tags are signed and that the Packagist artifact matches the GitHub tag before pinning.
• Maturity signal is "readme" — the API reference is auto-generated source docs, with no narrative guidance on box semantics, unit handling, or orientation edge cases.
• Version velocity. Releases appear as frequent 4.16.x patches. Good cadence, but we must confirm semver discipline empirically rather than assume it.

Key questions for the team.

1. Is the requirement "generate PDFs" or "control page geometry precisely"? If the former, this package is the wrong unit of evaluation — evaluate tc-lib-pdf as a whole.
2. What is our distribution model (SaaS-only vs. shippable artifact)? This determines whether LGPL is a blocker.
3. Does the PHP 8.2 floor conflict with any Laravel version or hosting constraint we currently support?
4. Who owns the upgrade cadence and the fork-and-patch contingency if upstream stalls?
5. What is our current renderer (dompdf, mPDF, elibyy/tcpdf-laravel), and what is the cost of switching versus staying?
6. Do we need print-production boxes (Trim/Bleed) or only screen-oriented MediaBox? Print semantics justify the complexity; a screen-only invoice does not.

Integration Approach

Stack fit. Composer-native and PSR-4, so it drops into Laravel cleanly through the aggregate package. Requires PHP 8.2+ and zlib; confirm the extension is enabled in every runtime image, queue worker, and CI container. Generate PDFs inside queued jobs, never in the request cycle, and bind the renderer through the service container so the library never appears in controllers, models, or Blade.

Migration path. If we are on elibyy/tcpdf-laravel or legacy TCPDF, tc-lib-pdf is the maintained successor and the migration is conceptually a lift-and-shift with namespace and API changes. If we are on dompdf or mPDF, the migration is larger: different coordinate conventions, different box defaults, different font handling. In both cases the migration vehicle should be an internal interface — something like App\Contracts\PdfRenderer with render(DocumentSpec): StreamedResponse — so call sites depend on our abstraction and the library choice remains reversible.

Compatibility. The risk surface is semantic, not syntactic: unit assumptions (points vs. millimeters), orientation inheritance across pages, origin at bottom-left, and default box values. These are exactly the things that produce plausible-looking but wrong output — a 3mm bleed that silently becomes 0, or a landscape page that renders portrait. Compatibility must be proven with golden-file regression tests that assert numeric box dimensions per page, not visual diffs alone.

Sequencing.

1. Legal/license sign-off on LGPL-3.0 and the NOASSERTION discrepancy.
2. Timeboxed spike (2–3 days) against the aggregate tc-lib-pdf, not this leaf, on one representative document.
3. Introduce the PdfRenderer abstraction and route one existing template through it.
4. Build golden-file tests covering multi-page, mixed orientation, custom sizes, and bleed/trim.
5. Canary on a low-risk report (internal statements, not invoices or regulated documents).
6. Retire or freeze the prior renderer behind a feature flag for one release cycle.

Operational Impact

Maintenance. Pin exact versions (no floating ^4.16), enable Renovate/Dependabot, and review changelogs per bump given the patch-level release cadence. Budget one engineer-day per quarter for dependency hygiene. Given the single-maintainer profile, maintain a documented fork-and-patch contingency: we must be able to patch a box calculation locally within a day if upstream goes quiet.

Support. Community-only, GitHub-issues-based, no vendor SLA. There is no one to escalate to. This means our internal runbook must cover: which versions are approved, how to reproduce a geometry bug, and the escalation path to the platform owner. Consider sponsoring upstream if it becomes load-bearing — it is cheap insurance against abandonment and signals our dependency to the maintainer.

Scaling. Page geometry itself is effectively free (microseconds, negligible memory). The scaling cost lives in the surrounding composition stack: font subsetting, image embedding, and object graph assembly are CPU- and memory-bound. Design for stateless queue workers with a hard cap on page count per job, stream output to object storage rather than buffering in memory, and set explicit memory limits that fail the job rather than the worker. Horizontal scaling is straightforward because rendering is side-effect-free.

Failure modes.

• Missing zlib extension → hard failure at autoload/bootstrap; catch in CI.
• Invalid box or orientation parameters → typed exceptions (a genuine strength; fail fast and log).
• Unit/orientation mismatches → silent, plausible, wrong output. This is the highest-severity mode for anything print-bound.
• Memory exhaustion on large or image-heavy documents → worker death if uncapped; enforce limits.
• Layout drift across patch versions → mitigated only by golden-file tests.
• License contamination if we ever ship a binary or appliance → legal, not technical, remediation.
• Upstream abandonment → mitigated by the fork contingency and abstraction boundary.

Ramp-up. The API surface is small enough that a competent PHP developer can produce a working spike in a day or two. The real ramp is domain knowledge: PDF units, box semantics, orientation inheritance, and coordinate origin. Budget roughly one to two weeks to get from spike to a hardened, tested, observable pipeline including the abstraction layer, regression fixtures, queue integration, and monitoring.

TPM recommendation. Do not adopt this package directly. Evaluate and adopt tecnickcom/tc-lib-pdf as the unit of decision, gate on license confirmation, wrap it behind an internal PdfRenderer contract, and prove correctness with dimensional regression tests before any customer-facing document depends on it.