Pdf Signable Bundle Laravel Package

Technical Evaluation

Architecture fit. The package is a Symfony bundle, not a Laravel package. Its value is concentrated in a browser-side interaction layer (PDF.js viewer, drag-and-drop signature box placement, optional AcroForm field editing) plus a thin Symfony layer for DI configuration, Twig rendering, and asset delivery. For a Laravel estate, the architectural fit is partial: the domain concept (capture signature placement metadata per PDF page) is framework-agnostic and portable, but the delivery mechanism (bundle extension, compiler passes, Twig templates, src/Resources/public/build) is not. Treat it as a frontend capability with a reference backend, not as an installable dependency.

Critical scoping note. Despite the name, this package does not appear to perform cryptographic signing, sealing, timestamping, or PAdES/PDF-A conformance. It defines coordinates. The signing engine (FPDI/TCPDF, a signing service, or a certificate-backed library) remains a separate build item. Any estimate that treats this bundle as "the signing feature" will be wrong by a large multiple.

Integration feasibility (Laravel target).

• Low-friction path: extract the PDF.js viewer + drag-and-drop module from src/Resources/assets, rebuild it as a standalone Vite/TypeScript entrypoint in the Laravel app, and own the coordinate persistence model in Laravel (Eloquent + JSON column or normalized signature_placements table). The bundle's Twig layer and Symfony DI are discarded. Estimated effort: moderate, dominated by de-Symfonyfying asset wiring and re-implementing the config surface as a Laravel config file.
• Medium-friction path: run the bundle in a small Symfony sidecar service that owns PDF + coordinate rendering, called over HTTP from Laravel. Adds a second runtime, a second deploy pipeline, and a second security surface for what is fundamentally a UI concern. Justified only if AcroForm editing turns out to be deep and hard to port.
• High-friction path: fork the bundle and add a Laravel service provider. Rejected — you inherit maintenance of a Symfony-shaped codebase while gaining nothing the extraction path doesn't give you.

Technical risk.

• Adoption risk (high). 0 stars, 0 dependents, single-maintainer signal. No evidence of production users, no external bug reports, no ecosystem validation. This is effectively unvetted code.
• Metadata anomaly (medium). "Last release: 2026-10-26" is a future date relative to typical evaluation windows. Confirm the release actually exists, that tags are signed, and that Packagist/GitHub metadata is not stale or synthetic before relying on any version constraint.
• Coordinate fidelity risk (high). Placing boxes on rotated pages, non-zero /CropBox vs /MediaBox origins, mixed page sizes, and PDF units (points vs pixels, DPI scaling) is where these tools fail in the field. Must be validated against a real corpus, not a single demo PDF.
• Scope-creep risk (medium). "Optional AcroForm editor" implies mutating existing form fields. Field renaming, duplicate field names, appearance-stream regeneration, and reader compatibility (Acrobat vs browser viewers) are notoriously fragile. Confirm whether the bundle writes PDFs at all or only produces coordinate JSON.
• Security surface (medium). Untrusted PDF upload, PDF.js version currency (historical CVEs in older PDF.js builds), signature image handling, PII retention, and CSRF/authorization on any coordinate-write endpoint.

Key questions for the maintainer / due diligence.

1. Does the bundle ever write to the PDF binary, or does it only emit coordinate metadata? Which library performs any write?
2. What is the tested PDF.js version, and how is it pinned and patched?
3. How are coordinate systems normalized — points, page rotation, CropBox, and DPI handling?
4. Is there any signing, hashing, or certificate handling at all, or is that explicitly out of scope?
5. What is the test story — unit tests on coordinate math, browser tests on the drag-and-drop UI, fixture PDFs?
6. Who maintains it, what is the commit cadence, and is there a documented BC policy?
7. Does it support multi-signer flows (N boxes across N pages) and per-recipient placement?
8. What is the accessibility story for the placement UI (keyboard placement, screen readers)?

Integration Approach

Stack fit. Target runtime PHP ≥ 8.2 with strict typing aligns with modern Laravel (10/11/12) and Symfony 7/8. Language-level compatibility is fine. Framework-level compatibility is the gap: Laravel has no bundle/DI-extension concept, no Twig by default, and a different asset story. The TypeScript/Vite frontend is the reusable core; everything else is a port.

Migration path (recommended: extract-and-own).

1. Vendor the frontend module from src/Resources/assets (not public/build) into the Laravel app's resources/js as an isolated feature module with an explicit public API: mountPlacementEditor({ pdfUrl, pageCount, placements, onSave }).
2. Reproduce the bundle's configuration surface (page selector behavior, box constraints, min/max size, snap, default signer list) as a typed options object plus config/pdf-signable.php.
3. Reimplement persistence in Laravel: a document_signature_placements table keyed by document, signer, page, and normalized rectangle (store both raw PDF points and normalized 0–1 fractions to survive re-render at different DPI).
4. Implement the write/render step separately. If AcroForm editing is genuinely required, evaluate a maintained PHP PDF library or a dedicated signing service rather than porting the bundle's editor.
5. Delete the Twig/DI layer entirely. Do not attempt to shim Symfony services into Laravel's container.

Compatibility.

• License: MIT — compatible with commercial use; retain attribution.
• Asset pipeline: both ecosystems use Vite, so the build step maps cleanly; the friction is entrypoint strategy and the Twig-injected config blob, which becomes a JSON data attribute or an API fetch.
• Blade replaces Twig one-to-one for the container element; no template logic should survive the port.
• PHP 8.2+ floor is acceptable if the platform floor matches; verify before committing, since it constrains older services.

Sequencing.

1. Spike (1–2 days): clone, run the Symfony demo, place boxes on three adversarial PDFs (rotated, mixed page sizes, cropped). Record failures.
2. Decision gate: if coordinate fidelity holds, proceed with extraction. If not, stop — the value proposition collapses.
3. Extraction (1 sprint): standalone TS module + Laravel config + storage schema; no UI polish.
4. Persistence + API (1 sprint): authenticated endpoints, validation, audit trail of placement changes.
5. Signing integration (separate epic): wire coordinates into the actual signature engine; this is the real cost center.
6. Hardening: PDF.js pinning, upload scanning, retention policy, load test of concurrent viewers.

Operational Impact

Maintenance. The dominant cost is not the code — it is ownership transfer. Post-extraction, your team owns a fork of the placement UI with no upstream to pull from. Budget ongoing time for PDF.js upgrades (security-driven, non-optional, and prone to breaking viewer APIs), browser PDF rendering regressions, and PDF-spec edge cases surfaced by customer documents. With 0 dependents and a single maintainer, upstream is not a safety net; assume it disappears.

Support. User-facing support load will concentrate on "the box doesn't line up" and "the signature appears in the wrong place on page 3." These are perception failures with real legal consequences in contract flows. Plan for a visible placement preview, an explicit signer confirmation step, and a stored audit record of who placed what, when. Do not ship a one-click "auto-place" default without a confirmation gate.

Scaling. Server-side scaling is cheap and favorable: rendering and interaction happen client-side, so the backend is mostly small JSON reads/writes — stateless, horizontally scalable, no PDF rasterization cost. The bottlenecks are (a) large PDF transfer and client memory for 100+ page documents, (b) mobile/touch drag-and-drop quality, and (c) the eventual signing service, which is CPU-heavy and must be queued and rate-limited. Keep placement and signing in separate services so placement latency is never coupled to signing throughput.

Failure modes.

• Coordinate drift after PDF re-render or version substitution → wrong-page signatures. Mitigate by storing normalized fractions plus a document hash, and refusing to reuse placements against a changed hash.
• PDF.js version regression silently breaking the viewer on a browser update — pin and regression-test.
• Partial save leaving orphan placements when a signer is removed mid-flow — require transactional placement writes.
• AcroForm mutation corrupting the source document — always operate on a copy, never the original; keep an immutable original blob.
• Upload of malicious or malformed PDFs — scan, size-cap, and process out-of-band.
• Future-dated release metadata implying an unverified artifact — pin by commit SHA and verify the tag before the first deploy.

Ramp-up. Low for a frontend engineer familiar with PDF.js and pointer events (days). Moderate for the backend engineer who must design the placement schema and signing handoff (about a week). High for whoever inherits the fork long-term, because there is no upstream documentation trail, no community, and no external bug history to learn from — institutional knowledge will live entirely in your team.

TPM recommendation. Do not adopt as a dependency. Adopt as a reference implementation for the placement UX, extracted into your own codebase and paired with a properly vetted signing engine. Approve the spike, gate on coordinate fidelity with adversarial PDFs, and treat the Symfony layer as disposable. Reassess if the project gains real dependents, published browser tests, and a maintained release history — none of which exist today.