- What are the system requirements for fruitcake/laravel-weasyprint?
- You need a Python runtime and the WeasyPrint CLI installed on the host, plus native libraries such as Pango and Cairo. The Laravel package itself is installed through Composer, but it shells out to WeasyPrint, so the binary path must be correct. Windows support is limited, and Docker images are often the easiest way to bake in Python and system dependencies.
- How do I install and configure fruitcake/laravel-weasyprint?
- Install it with Composer, then publish the package configuration and point the WeasyPrint binary setting at your installed executable. Make sure WeasyPrint runs from the command line before testing the Laravel facade. The v0.3.3 release fixed a malformed facade alias in composer.json, which improves facade autoloading reliability.
- Which Laravel and PHP versions does fruitcake/laravel-weasyprint support?
- The provided overview does not list exact Laravel and PHP constraints, so check the package composer.json before requiring it. It is pre-1.0 at v0.3.x, and the evaluation suggests confirming Laravel 8+ and PHP 7.4 or 8.x support for your project. Pin versions in Composer and test against your target Laravel release.
- Can I generate PDFs from Blade views, raw HTML, or URLs?
- Yes, the package supports rendering from Blade views, raw HTML strings, and URLs. That makes it suitable for invoices, reports, and other printable output built with familiar Laravel patterns. For CSS-heavy documents, use WeasyPrint-compatible CSS and validate page breaks, headers, and footers early.
- How do I save, download, or stream a generated PDF?
- The fluent API lets you save the generated PDF to storage, return it as a download response, or stream it to the browser. Use save for queued or background generation, and download or stream for direct user requests when the document is small enough. Avoid synchronous rendering for large PDFs in web requests.
- Can I configure the WeasyPrint binary and generation options?
- Yes, the package has publishable configuration for the WeasyPrint binary and generation options. Set the binary path per environment, especially in Docker, CI, and production. Keep WeasyPrint and system library versions pinned so rendering behavior stays consistent.
- Should I generate PDFs in a Laravel queue?
- Yes, for production and high-volume PDF generation, use Laravel queues with dedicated workers. WeasyPrint can be CPU- and memory-intensive per render, so synchronous rendering in web requests can hurt response times. Cache generated PDFs where possible and scale containerized workers horizontally.
- What production failures should I handle with WeasyPrint in Laravel?
- Watch for a missing Python binary, missing Pango or Cairo libraries, unavailable fonts, unsupported CSS features, timeouts on large documents, and permission errors on temp directories. Bake Python, WeasyPrint, and native dependencies into your Docker image or CI setup, and add health checks. Provide clear error handling and a fallback message if PDF generation is unavailable.
- How can I test PDF generation in a Laravel app?
- Use Laravel's testing helpers and mock the package facade to assert that the expected HTML, view, or options are passed to the PDF builder. Keep a small integration test that actually runs WeasyPrint in CI so environment and native-library issues are caught. Test representative CSS for page breaks, fonts, and headers or footers.
- How does it compare to DomPDF, Snappy, or Browsershot, and is it maintained?
- WeasyPrint generally offers stronger CSS Paged Media support than typical pure-PHP PDF libraries, making it a good fit for high-fidelity invoices and reports, but it adds a Python runtime dependency compared with DomPDF or Snappy. You can migrate incrementally by starting with one template and comparing output fidelity. The package is pre-1.0 at v0.3.x, so API stability is not guaranteed; v0.3.3 shows active maintenance through its facade alias fix, but support is community-driven via GitHub issues.