- How do I install psliwa/php-pdf in a Laravel application?
- Install it with Composer using the psliwa/php-pdf package name, then wire it into your app manually because there is no Laravel auto-discovery integration. Expect to pin or patch dependencies on modern PHP versions, since the dependency graph is stale and may conflict with Laravel 10 or 11 constraints. A thin adapter service that resolves fonts and images through Laravel disks and writes output to storage is the cleanest integration path.
- Does psliwa/php-pdf support Laravel 10 and Laravel 11?
- There is no official Laravel version support matrix, and the package is framework-agnostic rather than tested against Laravel releases. The practical risk is Composer dependency pins and Zend Framework-era transitive packages that collide with modern Laravel applications on PHP 8.1, 8.2 or 8.3. Run a one-day spike against your real template and target PHP/Laravel matrix before committing to an estimate.
- Is psliwa/php-pdf a Laravel package with a service provider and facade?
- No. It has no Laravel service provider, facade, publishable config, queue awareness or filesystem integration. You must design the integration yourself, typically as an internal DocumentRenderer contract bound in the container and backed by psliwa/php-pdf. That wrapper also gives you a place to swap in a fallback renderer if the library proves unreliable.
- What are the runtime requirements for psliwa/php-pdf?
- The XML/CSS layout engine described in technical assessments requires the Imagick native extension, fonts and a writable temp disk, and some features may also need GD. Imagick is not a Composer line, so managed runtimes, slim container images and serverless targets may not include it. Treat extension installation as an explicit ops task and verify every target environment before rollout.
- Can psliwa/php-pdf generate invoices and reports with headers, footers and pagination?
- Yes, its strongest architectural fit is document assembly with repeated headers and footers, auto-pagination over variable-length line items, and vector or barcode content. That makes it appealing for invoices, statements, certificates and reports where HTML-to-PDF fidelity is weak. Be aware that regressions are visual, so unit tests can pass while the customer-facing PDF is wrong.
- Does psliwa/php-pdf support barcodes and vector graphics?
- It advertises barcode generation and simple drawing APIs alongside text, images, shapes and colors. The barcode path is also where legacy Zend Framework-era dependencies are most likely to conflict with their laminas successors. Budget time to patch or isolate that code if barcodes are a hard requirement.
- How should I test PDF output generated by psliwa/php-pdf?
- Use golden-file snapshot testing for representative documents, plus a fallback renderer for comparison when output changes unexpectedly. Cover at least a long tabular document, an image-heavy layout and a barcode-bearing page. Unit tests alone will not catch visual regressions in headers, pagination, font embedding or spacing.
- Is psliwa/php-pdf actively maintained and safe for production?
- Maintenance risk is high: upstream is dormant, the project has around 334 stars and no recorded dependents, and an abandoned transitive dependency chain becomes a standing CVE-triage obligation. MIT licensing is permissive and fork-friendly, which is the comfortable part. If you adopt it, quarantine it behind an internal contract and plan for owning patches or a fork.
- What are the best alternatives to psliwa/php-pdf for Laravel PDF generation?
- For HTML-first documents, dompdf, mPDF, Laravel Snappy with wkhtmltopdf, or Spatie Browsershot are more common and better validated in Laravel applications. psliwa/php-pdf is only worth considering when its pagination, repeated headers and vector or barcode capabilities are genuinely differentiated for your use case. Benchmark memory, latency and rendering fidelity against one mature alternative before deciding.
- Can psliwa/php-pdf handle Unicode, CJK, RTL text and custom fonts?
- Custom fonts are part of the advertised typography support, but Unicode, CJK and RTL behavior is not clearly established and may reflect a Latin-1-era design. Verify with your actual language requirements before estimating, because font embedding and shaping problems are expensive to fix late. If multilingual output is central to the product, a more actively maintained renderer is the safer default.