Pdflib Laravel Package

Product Decisions This Supports

Feature / roadmap decisions

• "Build vs. buy" for PDF generation: If a roadmap item requires server-side PDFs with rich, per-run text formatting (mixed fonts, sizes, colors, bold/italic/underline, sub/superscripts, links, tabs, padding) or complex tables that span pages, this package is a candidate to avoid building layout engines in-house. It extends FPDF/TCPDF/tFPDF rather than replacing them, so it is a thin layer on an existing dependency, not a new rendering platform.
• Table-heavy document features: Invoice line items, statements, financial summaries, report appendices, schedules, and comparison tables with row/column spans, repeating headers on page breaks, per-cell alignment, embedded images, and transparency are directly supported. This maps to roadmap items like "generate branded PDF invoices," "export reports to PDF," or "downloadable statements."
• Rich-text documents: Contracts, terms and conditions, certificates, and internal reports that need tag-driven formatting without an HTML-to-PDF pipeline. Useful when content is authored in-app and must be rendered with consistent typography rather than as HTML.
• Scope containment: Supports a decision to defer investment in a heavier HTML/CSS-to-PDF stack (Dompdf, Snappy/wkhtmltopdf, headless Chrome) when requirements are text- and table-centric rather than design-heavy.
• Use cases to prioritize: billing/invoicing, financial statements, regulatory or compliance documents, certificates, report exports, and operational checklists.
• Do not treat this as a feature: Recent release notes emphasize underline support and Laravel Pint adoption. These are incremental maintenance items, not a reason to adopt. Product framing should center on multicell + table capability, not underline styling.

Risk and sequencing decisions

• Low adoption signal: 5 stars, 0 dependents. This is a low-signal dependency. It should be scoped behind a small, reversible integration (a single renderer adapter) rather than spread across the codebase.
• Mitigation decision: Keep PDF rendering behind an internal interface so the underlying library can be swapped (TCPDF-native, Dompdf, or a hosted PDF service) without touching domain code.
• Maintenance posture: MIT-licensed, small maintainer base, recent commits from a second contributor. Viable for non-critical internal documents; treat as higher risk for high-volume, revenue-critical output until a fork/ownership plan exists.

When to Consider This Package

Consider adoption when:

• The document set is primarily text and tabular, not layout-heavy marketing collateral.
• Requirements include rich inline formatting inside cells or paragraphs — mixed styles, colors, links, sub/superscript — which base FPDF/TCPDF make tedious.
• Tables must break across pages cleanly with repeated headers and support row/column spanning.
• The team is already on PHP and ideally already using FPDF, TCPDF, or tFPDF; the package is an add-on, so the marginal dependency cost is low.
• You want a pragmatic, MIT-licensed, vendor-free option and can accept community-level support.
• The output is generated programmatically from app data rather than from authored HTML templates.
• You need a fast evaluation: examples and end-user docs for both multicell and table features are provided, so a spike is cheap.

Look elsewhere when:

• The primary requirement is HTML/CSS fidelity — CSS layouts, web fonts, flexbox/grid, complex typography. Use Dompdf, Snappy/wkhtmltopdf, or headless Chrome.
• You need interactive or accessible PDFs — form fields, tagging/PDF-UA, JavaScript, digital signatures. TCPDF itself or commercial iText/PDFTron is the better path.
• Volume and SLA matter: high-throughput, revenue-critical document generation with contractual support expectations. A 5-star, 0-dependent package cannot carry that risk alone.
• The team is not on PHP — evaluate jsPDF/PDFKit (Node) or ReportLab (Python) instead.
• Requirements are simple single-paragraph text or basic tables — base FPDF/TCPDF is sufficient and one fewer dependency.
• You need modern PHP/Laravel-native ergonomics. Despite the name and Pint usage, this is a legacy-lineage add-on with custom PDF subclasses, not a Laravel package with facades, config publishing, or Blade integration. Budget for a thin internal wrapper.

Adoption gates before commit:

1. Confirm the custom PDF subclass approach (extending FPDF/TCPDF/tFPDF to reach protected properties) is compatible with your existing PDF usage — you generally cannot mix this with an existing custom PDF class.
2. Run a spike on your hardest real template — one table with spans and a page break, one formatted paragraph.
3. Verify PHP version support against your runtime (recent releases addressed PHP 8.4 deprecations, which is a positive signal).
4. Decide the fallback owner: who forks or patches if the maintainer stops.

How to Pitch It (Stakeholders)

For executives (one paragraph): We have a recurring class of document features — invoices, statements, compliance letters, certificates, report exports — that need formatted text and multi-page, multi-column tables. evosys21/pdflib is a small MIT-licensed PHP add-on for FPDF/TCPDF/tFPDF that supplies exactly those two capabilities, with examples and documentation, at effectively zero licensing cost. It lets us ship these features without buying a document-generation platform or building a layout engine, and it sits behind a swap-ready interface so the commitment is reversible. The honest caveat: it is a small, low-adoption open-source project (5 stars, no known dependents), so we should use it for standard business documents, not for high-volume revenue-critical output, until we've validated it on our hardest template. Recommendation: approve a short, time-boxed spike, not a broad rollout — expect a decision within one sprint at minimal engineering cost.

For engineering leads:

• What it actually is: an add-on layer over FPDF/TCPDF/tFPDF providing (1) an Advanced Multicell that accepts tag-formatted strings — mixed font, size, style, color, links, tabs, sub/superscript, padding, framing, backgrounds — and (2) an Advanced Table where every cell supports that formatting, plus row/column spans, vertical and horizontal alignment, automatic page breaks with header repetition, per-cell overrides, images, and transparency.
• Integration cost: requires using the package's custom Pdf subclass (EvoSys21\PdfLib\Fpdf\Pdf, Tcpdf\Pdf, Tfpdf\Pdf) instead of your own, because it needs access to protected width/margin/font properties that FPDF exposes no setters for. If we already subclass FPDF/TCPDF, that's a real refactor — scope it.
• Architecture guidance: wrap it in an internal DocumentRenderer interface. Domain code produces a document model; the adapter renders it. This makes the library a swappable detail and contains the blast radius if the project stalls.
• Quality signals: passing build status, MIT license, docs plus runnable examples, active recent releases including PHP 8.4 deprecation fixes. Weak signals: 5 stars, 0 dependents, small maintainer pool, legacy lineage (continuation of the old interpid.eu PDF Addons).
• Do not justify adoption on the latest release notes. Underline support and Pint formatting are minor. The decision rests on multicell + table capability only.
• Suggested spike (one sprint, time-boxed): port our two hardest existing PDF templates; measure render time and memory against current output; confirm page-break and header behavior; document the migration delta for any existing custom PDF class. Kill criteria: fidelity gaps on tables or a required refactor that exceeds the box.