Tc Lib Pdf Filter Laravel Package

Technical Evaluation

Architecture fit. tecnickcom/tc-lib-pdf-filter is a stateless, leaf-level utility: bytes in, bytes out. It has no coupling to Laravel, no global state, no I/O, and no container awareness. That makes it architecturally safe to drop behind a thin adapter in the App\Support\Pdf layer, but it also defines its ceiling — the package occupies exactly one stage of a PDF ingestion pipeline (stream decoding). It performs no parsing of the PDF object graph, no xref resolution, no page traversal, and no rendering. A TPM should frame this internally as "the decompression primitive," not "PDF support." Any roadmap item phrased as "read/extract/search PDFs" is at best 10–15% addressed by this dependency; the remaining work (parser, stream extraction, /DecodeParms retrieval, output post-processing) is ours to build or buy elsewhere.

Scope correction worth raising before commitment. The package description claims "decode PDF compression and encryption filters," but the README feature list contains only compression/transform filters (FlateDecode, LZWDecode, RunLengthDecode, ASCIIHexDecode, ASCII85Decode, CCITTFaxDecode, DCTDecode, JPXDecode, JBIG2Decode). Password-based decryption in PDF requires the Standard Security Handler plus RC4/AES, which is not enumerated. Prior stakeholder framing that this "decrypts password-protected PDFs" should be treated as unvalidated. If decryption is the actual business driver (legal/finance workflows), this package is likely the wrong purchase and the business case needs rework before engineering time is spent.

Integration feasibility. composer require plus ext-zlib; no service provider is required, and the public surface is small (Filter::decodeAll(array $filters, string $data) plus typed exceptions). Effort to first working call: hours. Effort to a production-safe pipeline: weeks, because of the surrounding concerns below.

Notable discrepancy: internal notes reference a Tecnickcom\TCPDF\Filters namespace and new FlateDecode() style instantiation, while the README specifies \Com\Tecnick\Pdf\Filter\Filter with a filter-name-list API. The README is authoritative; the inconsistency signals that any internal design docs drafted from memory must be re-verified against source before estimates are trusted.

Technical risk.

Key questions.

1. Is the actual requirement filter decoding or document understanding? If extraction/search/rendering, this package is a subcomponent and the estimate must include the parser.
2. Does the business case survive if decryption is not supported?
3. What is our existing PDF stack (Imagick, Ghostscript, smalot/pdfparser, setasign/fpdi)? Several already decode Flate internally — double-decoding is a real corruption risk.
4. Which filters appear in our corpus? Sample 200 real files and histogram /Filter values before committing.
5. Does decodeAll correctly invert filter order and accept /DecodeParms? If not, we own that logic.
6. What are the throughput and latency targets, and are they batch (queue) or synchronous (request path)?
7. Legal: LGPL-3.0 confirmed, and do we distribute artifacts that link it?
8. Have we validated behavior on truncated, malformed, and adversarially crafted PDFs?

Integration Approach

Stack fit. Laravel 10+ on PHP 8.2/8.3, ext-zlib present in the base image, Composer-managed. The natural home is a single PdfFilterService bound as a singleton (the library is stateless and cheap; the binding is for injection ergonomics, not lifecycle). Everything else — storage, dispatch, persistence — stays native Laravel: Storage for stream acquisition, queued jobs for batching, events for post-decode hooks, an Artisan command for backfill/reprocessing.

Compatibility constraints to check before scheduling.

• composer.json platform constraints vs. our PHP floor; 8.2 minimum is a hard gate on older services.
• Coexistence with other tc-lib-pdf-* packages or TCPDF itself — pin a consistent 2.11.x line across the graph to avoid resolution conflicts.
• Overlap with existing PDF libraries: if smalot/pdfparser is present, do not run both decode paths on the same stream.
• License posture in CI: confirm the SPDX identifier rather than relying on the registry's NOASSERTION, and record the decision.

Migration path. This is additive, not a replacement. Nothing is migrated; the package slots in where we currently shell out to qpdf/pdftk for decompression, or where we have bespoke gzuncompress calls. Treat any existing hand-rolled gzuncompress usage as technical debt to consolidate behind the adapter — that is where the real cost saving is.

Sequencing.

1. Two-day spike (gate). Decode a fixture set covering each advertised filter plus a predictor-encoded stream and an encrypted sample. Output validated with qpdf --check or round-trip comparison. Kill the initiative here if the filter histogram or encryption result is unfavorable.
2. Adapter + contract tests. Isolate the vendor API behind PdfFilterService; tests pin real fixtures so a patch bump cannot silently change output.
3. Queue job + storage. Bounded job with explicit memory and time limits, S3/local streams, failure and retry policy.
4. Guards and observability. Max input size, max decoded size, zlib expansion-ratio cap, structured logging of filter chain and byte counts, metric on failure rate.
5. Pilot on one internal batch, then ramp. Ship the Artisan command last, once the job is proven.

Operational Impact

Maintenance. Low volume, low blast radius. Pin ^2.11, review the diff (not the release notes — they are compare links only) before each bump, and hold a vendored fork as contingency. The maintenance burden that actually accrues is not the dependency; it is the pipeline we build around it, which is ours entirely.

Support. Single maintainer, GitHub issues, generated API docs. No SLA, no commercial support. Our team owns every integration bug, and upstream will not triage our parser problems. Budget internal ownership accordingly — one named owner, not "the platform team."

Scaling. CPU-bound and per-worker; horizontal scale via queue concurrency. The binding constraint is memory: the decode API is buffer-oriented, so peak RSS scales with decoded stream size (often 5–20× the compressed input). Enforce upload limits, per-stream size caps, and expansion-ratio guards at the boundary — a small malicious PDF is a cheap OOM. Keep synchronous request-path use to small, known-shape documents; route anything else through Horizon with tuned memory and timeout.

Failure modes.

The silent-garbage mode is the one to brief stakeholders on: a successful return value is not evidence of correct output. Any downstream consumer (OCR, e-signature, archival metadata) must receive validated bytes or an explicit failure.

Ramp-up. A mid-level Laravel developer is productive with the API in half a day — it is a handful of methods. The real ramp is PDF-spec literacy (filter ordering, predictors, DecodeParms, encryption handlers) at roughly one to two weeks to own the pipeline confidently. Recommend designating a single owner and writing the fixture corpus before, not after, the feature is announced on the roadmap.