Print Laravel Package

Product Decisions This Supports

• Document-generation features: invoices, statements, shipping labels, certificates, and reports all need explicit page dimensions and margins. This package supplies typed primitives (Paper, PageLayout) so product decisions like "A4 by default, US Letter for NA tenants" become configuration, not hardcoded strings scattered across templates.
• Regional/multi-tenant output: standardize paper size and layout per market or per customer without forking rendering code — supporting decisions about white-labeling, localization, and per-account document settings.
• Build vs. buy for the print domain layer: the package itself is small (paper dimensions + layout value objects) under MIT. The realistic "build" alternative is a handful of enums and a DTO; the realistic "buy" argument is interoperability with print-contracts and the wider rekalogika print ecosystem. This is a low-cost, low-ceiling dependency — a supporting decision, not a platform bet.
• Architecture roadmap for a document service: it cleanly separates describing a page from rendering it, which supports a roadmap where rendering backends (dompdf, mPDF, headless browser) can be swapped independently of the document model.
• Vendor/ecosystem evaluation: 0 stars, 0 dependents, read-only split repo. This should feed a "do we standardize on rekalogika for print?" decision rather than being adopted in isolation.

When to Consider This Package

Adopt when:

• You are already using rekalogika/print-contracts or other rekalogika print packages — this is the matching implementation, not a standalone tool.
• You need framework-agnostic, typed paper/page-layout primitives and want a shared contract across multiple renderers or services.
• You are building an internal print/document pipeline and want a clean domain layer beneath your own abstraction (recommended: wrap it).
• You value type safety over magic strings for sizes, orientation, and margins, and your team is comfortable with PSR-style contracts-plus-implementation packages.

Look elsewhere when:

• You need actual PDF/print rendering — this does not render anything; use dompdf, mPDF, Browsershot, or a hosted service.
• You need HTML templating, pagination, or layout engines — out of scope.
• You require community validation and maintenance guarantees — zero stars and zero dependents is a real signal; assume you may need to vendor or fork.
• Your need is one hardcoded paper size — a constant or enum is cheaper than a dependency.
• You need advanced print concerns (bleed, imposition, CMYK, prepress) — not covered.

How to Pitch It (Stakeholders)

Executives: This is a small, MIT-licensed building block that standardizes how our products describe paper size and page layout for generated documents. Cost and lock-in risk are near zero, but so is standalone value — it only pays off as part of a broader document/print initiative. It should be framed as a tactical dependency, not a strategic platform choice.

Engineering: It provides typed Paper and PageLayout value objects against print-contracts, replacing string-based page configuration and making renderer swaps cheaper. Caveats to state plainly: the repository is a read-only split of a contracts package, has no visible adoption, and no dependents — pin versions, wrap it behind our own interface, and treat it as an internal utility rather than a load-bearing dependency. The print-contracts abstraction is the real reason to engage; the implementation is incidental.