Weave Code
Mathml Bundle Laravel Package
mercurysolutions/mathml-bundle
The MathML Bundle for Symfony makes it easy to add MathML support to PHP applications. It provides configurable integration and Twig helpers for rendering mathematical formulas in templates, helping you keep math markup clean and consistent.
A Symfony bundle for PHPMathML integration
Frequently asked questions about Mathml Bundle
- Can I use mercurysolutions/mathml-bundle in a Laravel application?
- No, not directly. The package is a Symfony bundle built on a Bundle subclass and the Symfony DependencyInjection component, complete with a configuration tree and Twig extensions that Laravel does not provide. Laravel ships no FrameworkBundle and no Kernel::registerBundles(), so there is nothing for the bundle's glue code to attach to. Version 4.0.0 targets Symfony 7 specifically, which does not change that structural mismatch.
- Does the bundle support Laravel 11 and Laravel 12, or will Composer conflicts block installation?
- The bundle does not target Laravel at all, but dependency resolution is less of a problem than it used to be. Version 4.0.0 constrains symfony/* to ^7 and requires PHP 8.2, and Laravel 11 and 12 already ship Symfony 7.x components, so an install is less likely to collide than with the older Symfony 4/5 constraints. That removes one likely Composer conflict but does not make the bundle's runtime usable inside Laravel.
- How do I add MathML rendering to a Laravel app if this bundle won't work?
- Depend on the underlying PHPMathML library directly rather than on the Symfony bundle. Read the bundle's composer.json to see which core PHPMathML version 4.0.0 pins, require that package in your application, and register it through a small MathMLServiceProvider that binds the renderer as a singleton. Expose it with a facade or a Blade directive so templates stay clean and consistent. All the actual math markup generation lives in the core library, so you lose nothing functional by skipping the bundle.
- What does this bundle actually add on top of the PHPMathML library?
- It adds Symfony integration glue: a DependencyInjection extension with a configuration tree, YAML or XML service definitions, container aliases, and Twig helpers for rendering formulas in templates. The MathML generation itself comes from the core PHPMathML package. The 4.0.0 changelog describes framework-support and container-generation changes, so the bundle layer appears to be mostly plumbing around the library. For a Laravel integration, that plumbing is the part you discard and replace.
- Can I use the bundle's Twig helpers in Laravel Blade templates?
- No. The helpers are registered as a Twig extension, and Blade has no Twig runtime, so the functions and filters will not resolve. If you want equivalent ergonomics you would port the same rendering calls into a Blade directive or a facade method wrapping the core library. This is straightforward because the helper bodies mostly delegate to PHPMathML.
- What PHP version does mathml-bundle require, and does that conflict with Laravel's minimum?
- Version 4.0.0 requires PHP 8.2, which matches the minimum for Laravel 11 and 12, so there is no runtime conflict and no pressure to downgrade your platform. Note that the bundle's constraint tells you little about the core PHPMathML library, which is what you would actually install. Check the core package's own PHP requirement before committing, because it may still support older runtimes on a different schedule.
- What changed in version 4.0.0 and are there breaking changes?
- The 4.0.0 release is a breaking major that moves the bundle to Symfony 7 dependency injection generation and drops Symfony 2, 3, and 4 support. The changelog lists no API-level changes beyond framework support, but you should read the diff before assuming a no-op. Two questions matter for a Laravel integration: whether 4.0.0 also bumps the pinned core PHPMathML version, and whether the bundle-only changes touch any public rendering surface. Treat 4.0.0 as the authoritative release and re-verify the package metadata, since the recorded release date is anomalous.
- Is mathml-bundle actively maintained and safe to use in production?
- The 4.0.0 release is a positive maintenance signal, because dropping end-of-life Symfony versions and adding current framework support means someone is still working on it. Beyond that the risk profile is high: zero stars, zero dependents, no production validation, and a bus factor of one. The Composer namespace mercurysolutions also does not match the repository owner renaudclosset, so upstream lineage is unclear, which matters when reconciling a breaking major against any fork history. Open a GitHub issue and confirm maintainer responsiveness before building on it.
- Can I shim Symfony's dependency injection container into Laravel to make this bundle work?
- It is technically possible but not advisable. You would have to emulate Symfony 7 container semantics, including bundle registration, extension loading, and the configuration tree, which is a larger and more fragile job than writing a small Laravel provider. With 4.0.0 the shim would have to match Symfony 7 behaviour specifically, so the work got harder rather than easier. The supported path is to wrap the core PHPMathML library and skip the bundle entirely.
- Does the rendered MathML output work in browsers, screen readers, and PDF pipelines?
- That is still the open gating question and is not answered by the package documentation. You need to confirm whether the output is Presentation MathML or Content MathML, because browser rendering, assistive technology support, and PDF generation toolchains handle the two very differently. Test the core library's output against your actual consumer surfaces before committing to the integration. This evaluation should happen regardless of whether you adopt the bundle or the underlying library.
Weaver
How can I help you explore Laravel packages today?