Pdf Optimizer Laravel Package

Product Decisions This Supports

• Feature decisions: "compress on upload." This package makes it cheap to add automatic PDF compression to any existing document flow — invoices, statements, contracts, scanned intake forms, report exports. The PM decision is not how, it's where: synchronous on upload (simpler, adds latency to the user's request) versus an async queue job (better UX, requires workers and a status surface). The package supports both, so this can be staged.
• Build vs. buy. The actual compression is Ghostscript; this package contributes the fluent builder, Laravel disk/UploadedFile/queue adapters, config publishing, and logging. Building that in-house is a week or two of engineering plus ongoing maintenance for near-zero differentiated value. Buy — with the caveat that the "buy" is really "adopt a system binary."
• Cost and UX roadmap items this unblocks. Storage and egress reduction, staying under email attachment limits, faster downloads for customers, and accepting larger uploads without larger bills. These are quantifiable outcomes you can put a number against before committing.
• Scope boundary decision. This does not do OCR, redaction, PDF/A conversion, merging/splitting, digital signing, or forms. That is useful for roadmap hygiene: it clarifies that a "document pipeline" initiative is bigger than this package, and prevents scope creep into "while we're in there, can it also…"
• Quality-bar decision per document class. Compression is lossy in practice. The PM decision is what each document class must survive — vector-generated PDFs typically fare well; scanned/image-heavy PDFs can degrade to illegibility, which is unacceptable in legal-hold, archival, or accessibility contexts. This requires evaluating output on your own corpus, not trusting the README.
• Governance decision: Ghostscript licensing. The package is MIT, but Ghostscript is AGPL or commercial (Artifex). Shipping AGPL Ghostscript in a network-facing commercial product is a real compliance obligation. This should be resolved by legal before any design hardens — it is the single item most likely to reshape or kill the initiative.
• Dependency posture decision. ~177 stars, zero listed dependents, effectively single-maintainer. Treat as a tactical utility, not a platform bet, and fund the abstraction layer behind it so replacement is a week, not a quarter.
• Ops ownership decision. Someone must own Ghostscript version pinning, CVE patching, and image rebuilds as a standing duty. That is a real, recurring cost that rarely appears in the initial estimate.

When to Consider This Package

Adopt when:

• You are on PHP 8.2+ with Laravel 10–13 (or standalone PHP), and PDFs are already discrete artifacts in your system rather than something you'd have to restructure to isolate.
• File size is a measurable problem — storage bills, egress, attachment limits, slow downloads, or upload caps blocking customers.
• Your document corpus is predominantly vector-generated (text-based PDFs) where compression wins are large and quality loss is imperceptible.
• Your runtime can carry a pinned system binary — containers or VMs you control. Not serverless with an opaque base image.
• You have (or will build) queue infrastructure, so optimization can leave the request path.
• Your team values low ceremony: composer require, publish config, install the binary, done.
• Legal clears AGPL compliance, or budget exists for a commercial Ghostscript license.

Look elsewhere (or scope down) when:

• Legal will not accept AGPL and won't fund a commercial license. That is a hard stop, not a negotiation with engineering.
• The target runtime is immutable/serverless and can't ship and pin Ghostscript. That forces a dedicated worker service — an architecture decision, not a code decision.
• The requirement set includes OCR, redaction, PDF/A, signing, merging, or form handling. This is one component of a larger pipeline, not the pipeline.
• The corpus is scanned or image-heavy and quality is business-critical. You need content-aware or per-document-class tuning, plus a human review of output samples, before committing.
• You need an enterprise support contract, third-party security review, or a vendor accountable for CVEs.
• You require byte-reproducible output (same input → same hash) for archival or deduplication, and can't enforce strict version pinning end to end.
• You need guaranteed throughput at high volume — validate Ghostscript's p50/p95 wall-clock, CPU, and peak memory on your largest realistic documents first; the package exposes knobs but doesn't enforce limits.
• Your estate includes Windows; treat this as Unix-only.

How to Pitch It (Stakeholders)

To executives: This is a small, low-cost utility that reduces storage and bandwidth spend and improves customer experience — faster downloads, fewer "file too large" failures, larger uploads accepted without a larger bill. It is not a strategic platform investment; it's a tactical dependency that we should deliberately encapsulate so it can be swapped in about a week. The one thing that can stop it is legal: Ghostscript, which does the actual work, is AGPL or requires a commercial license from Artifex. The ask is a timeboxed spike plus a legal ruling, not a platform commitment. Bring back: measured size reduction on a sample of our real documents, a quality verdict per document class, throughput numbers on our largest files, and legal's position.

To engineering: A thin, well-behaved wrapper around the Ghostscript CLI — not a PDF engine. It leans on primitives we already use (filesystem disks, UploadedFile, queue jobs, PSR-3 logging, publishable config, execution timeouts, custom flags) rather than inventing parallel abstractions. The fluent API exposes nearly all Ghostscript options, and exportable command strings let you reproduce any failure outside the app — that debug affordance alone is worth the dependency. Onboarding is an afternoon: composer require, publish config, point at the binary. Requirements we own: provision and pin an exact Ghostscript version on every host and worker, add a startup health check that fails loudly if the binary is missing or wrong, keep optimization off the request path, and put it behind an internal interface so no domain code imports the package directly. Watch temp-file hygiene, concurrency, disk space, and timeout defaults — the package gives us the knobs but enforces nothing. Maintenance signals are reasonable: PHP 8.4/8.5, Laravel 11/12/13, Symfony 8, CI and coverage badges present, steady low-drama releases. Assume a single maintainer and plan accordingly.