- Does jbtronics/dompdf-font-loader-bundle work with Laravel?
- No. It is a Symfony bundle whose value lives in its DI extension and a WarmableInterface cache warmer, and neither fires under Laravel's container. You can Composer-install it, but you get the dependency surface and zero behavior. Port the font-registration pattern natively instead.
- How do I install this bundle in a Laravel application?
- There is no meaningful installation path. Symfony components do coexist with Illuminate, so the package installs, but there is no bundle registration, no service provider auto-discovery, and no cache-warming contract, so nothing registers your fonts. Treat the repository as a design reference rather than a dependency.
- How do I load custom fonts into Dompdf with barryvdh/laravel-dompdf?
- Point font_dir, font_cache and temp_dir in config/dompdf.php at a writable path such as storage/app/dompdf, then register each family with FontMetrics::registerFont() from a config/pdf-fonts.php mapping. Generate the .ufm metrics ahead of first render via an Artisan command run at deploy time. That is the same shape the bundle uses, minus the Symfony packaging.
- Why are my custom fonts not showing up in generated PDFs?
- The most common cause is a font cache path mismatch: fonts warmed into one directory while Dompdf renders against vendor/dompdf/dompdf/lib/fonts, which is not writable in most production images. Dompdf then silently falls back to core fonts with no error. Also confirm isRemoteEnabled is false for any @font-face source and that your font files are actually TrueType.
- Which Dompdf version does this bundle support?
- The bundle targets Dompdf 2.x, which writes .ufm metrics plus installed-fonts.json; the older 0.8.x line used a different metrics format. Its constraint must overlap whatever barryvdh/laravel-dompdf pins in your lockfile. A mismatch produces metrics files that silently never apply.
- How do I warm the Dompdf font cache during a Laravel deployment?
- Write an Artisan command that loops your configured families and calls FontMetrics::registerFont(), then invoke it from your deploy pipeline or container entrypoint. Do not assume the cache persists: immutable images and autoscaled fleets need it baked at build time or written on container start. Rendering in queue workers versus web requests only changes whether warmup is a latency issue or purely a correctness one.
- Can I use OTF or variable fonts with Dompdf?
- TrueType (.ttf) is well supported; OpenType/CFF (.otf) is only partially supported and will bite on many brand-supplied fonts. Convert to TTF where licensing allows, and remember remote @font-face loading is disabled by default. CJK and RTL families also produce multi-megabyte metrics files that materially change warm time and memory.
- How do I test that custom fonts actually render in my PDFs?
- Use golden-file PDF snapshot tests: render a fixture template, extract the text layer and compare, or rasterize and diff against a baseline. A missing font still produces a valid PDF, so without a visual or text assertion the failure is invisible. Add at least one fixture per registered family, including an accented glyph.
- Is there a Laravel-native alternative to this Symfony bundle?
- No package does exactly this for Laravel. The practical equivalent is roughly 60 to 120 lines of your own code: a config/pdf-fonts.php mapping, a FontRegistrar singleton wrapping FontMetrics::registerFont(), a service provider binding, and a pdf:fonts:warm Artisan command. Forking the bundle and stripping its Symfony DI surface is also viable given its small size.
- What are the maintenance and licensing risks of adopting this package?
- It is MIT licensed with a small surface area, so forking or copying the font-loading service is cheap if you want the maintainer's edge-case handling. The real risk is not the package but Dompdf major-version coupling and font cache path divergence. As an unmodified dependency in a Laravel app it buys nothing and only adds upgrade surface.