Weave Code
Pdf Bundle Laravel Package
siphoc/pdf-bundle
Siphoc PDF Bundle is a Symfony/PHP bundle that wraps wkhtmltopdf to generate PDFs from HTML strings or URLs. It provides service-based rendering, configurable binary paths and command options, and convenient streamed or downloadable responses for invoices, reports, tickets, and other printable docum...
Symfony2 PDF Bundle.
Frequently asked questions about Pdf Bundle
- Is siphoc/pdf-bundle a Laravel package?
- No. siphoc/pdf-bundle is a Symfony2 bundle that registers a PDF service through the Symfony service container; it has no Laravel service provider, no publishable config/pdf.php, no facade, and no Laravel-style container binding. In a Laravel application its architectural fit is effectively zero, so treat it as a reference pattern rather than a dependency.
- Can I install siphoc/pdf-bundle in Laravel 9, 10, or 11?
- You should not. There is no Laravel service provider or facade, so installing it would mean reimplementing its Symfony DI wiring for a framework generation Laravel never shared. The practical path is to skip the bundle and bind your own PdfRenderer contract to a maintained renderer or an out-of-process service.
- What does the Siphoc PDF Bundle actually do?
- It wraps wkhtmltopdf and exposes a configurable service that converts HTML strings or rendered templates into PDF bytes, with configurable binary paths and command options. You inject that service into controllers or other services and return the generated file as a streamed or downloadable response. Typical uses are invoices, reports, tickets, and other printable documents.
- Which Symfony and PHP versions does it support?
- The bundle targets Symfony 2.7/2.8 on PHP 5.6 through 7.1, which is the only environment where it installs without heroics. It does not fit modern Symfony with Flex, and it is not compatible with Laravel 9 to 11 on PHP 8.1 and newer. Expect Composer constraint conflicts on PHP 8 and on modern PSR-4 and PSR-11 wiring.
- Is siphoc/pdf-bundle maintained and safe for production?
- Technical risk is high. Symfony 2.x is end-of-life with no security backports, the bundle has around 14 stars and zero dependents, and there is no visible maintenance cadence. The real CVE surface is the wrapped PDF engine and its transitive dependencies, especially if any template input is user-influenced. Documentation is sparse enough that behavior has to be read out of the source.
- What are the best alternatives to this bundle for Laravel PDF generation?
- For Laravel, go directly to a maintained renderer such as dompdf- or Snappy-style packages, or preferably an HTTP-based rendering service such as headless Chromium, Gotenberg, or a managed API. Define a single PdfRenderer contract with render(string $html, array $options): string, bind it in a service provider, and keep templates and business logic in the application. That keeps document generation out of your framework upgrade path.
- How do I migrate off siphoc/pdf-bundle in an inherited Symfony app?
- In an inherited Symfony 2.x codebase, pin and quarantine the bundle as a stopgap and wrap its existing service behind your own PdfRenderer contract. Then swap the binding in a branch to an out-of-process renderer. Size the migration ticket by extracting the PDF layer entirely rather than carrying the bundle through the next framework upgrade.
- Does it support Unicode, custom fonts, CSS, PDF/A, or tagged accessibility?
- Output fidelity is determined by the wrapped engine, not the bundle, so features like Unicode, custom fonts, CSS subsetting, PDF/A, and tagged accessibility depend on the pinned wkhtmltopdf version and your configuration. Behavior must largely be read out of the source because documentation is sparse. Test your actual document tiers against the exact engine version before committing.
- How should I test PDF output and handle production concerns?
- Pin transitive dependencies, run an SCA scan against the resolved lockfile, and test on the exact production PHP patch version. Output differences across engine versions are the quiet failure mode: fonts, page breaks, and metadata can change without errors. Add golden-file or visual regression checks for representative invoices and reports.
- Is it worth forking the bundle, and is the license clean?
- Check the license and copyright first; a fork is only viable if they are clean enough to patch and redistribute, and the bundle is small enough that extraction may be cheaper than long-term maintenance. For a Laravel target, do not fork, because reimplementing the thin HTML-to-bytes service against a supported engine is simpler. In diligence, treat the bundle as an architectural reference and a legacy-footprint signal.
Weaver
How can I help you explore Laravel packages today?