Tex2Png Bundle Laravel Package

Technical Evaluation

Architecture fit. gregwar/tex2png-bundle is a Symfony bundle, not a Laravel package. It registers a Tex2png service into the Symfony DI container and exposes Twig helpers; there is no Laravel service provider, facade, config publish tag, or package auto-discovery entry. In a Laravel codebase the bundle wrapper is dead weight — the reusable asset is the Gregwar\Tex2pngBundle\Tex2png class itself (a ~200-line wrapper that shells out to latex and dvipng via symfony/process), which is simple enough to vendor or re-implement. Treat this as "a small unmaintained library with a framework adapter we do not use," not as an ecosystem integration.

Integration feasibility. Moderate to low. Two hard gates: (1) Composer constraints — the bundle targets Symfony 2.x/3.x-era framework-bundle and process versions and will almost certainly collide with Laravel 10/11 requirements; installation likely fails without forking or --ignore-platform-reqs. (2) Runtime dependency on TeX Live binaries (latex, dvipng) present on every node that renders. There is no PHP-only path; this is a subprocess wrapper around a native toolchain.

Technical risk. High. The package shows 4 stars and 0 dependents — effectively no community, no downstream validation, and no visible maintenance. It is an abandoned early-2010s component. Security surface is the real concern: user-supplied LaTeX passed to a local latex binary enables \input/\include local file disclosure, \write18 shell escape if enabled, and trivial resource-exhaustion (deeply nested or looping constructs, huge \foreach). You inherit full liability for sandboxing, timeouts, and input sanitisation.

Key questions. Does the product genuinely require server-side raster output, or would client-side KaTeX/MathJax (or KaTeX SSR in Node) satisfy the requirement at zero infrastructure cost? What is the render volume and is it latency-tolerant (queueable) or synchronous? Is the LaTeX input authored by us or by end users? What is the target PHP/Laravel version? Is there appetite to own a fork indefinitely?

Integration Approach

Stack fit. Do not install the bundle. Either require the underlying gregwar/tex2png library (verify PHP 8.x compatibility first) or copy the Tex2png class into app/Support/ — it is small, MIT-licensed, and gives you a stable seam. Wrap it in an application-level TexRenderer interface with a single render(string $latex, array $options): string contract, bound in a service provider and configured via config/tex2png.php (binary paths, dpi, cache TTL, timeout).

Migration approach. Run a time-boxed spike in a disposable container image (texlive-latex-base, texlive-latex-extra, dvipng) to confirm the class works under the current PHP version and that output quality meets design requirements. If the upstream constraints block install, vendor the file and drop the Composer dependency entirely — this is the expected outcome and should be planned for, not discovered late.

Compatibility. Expect friction on symfony/process version pinning, PHP 8.1+ deprecations (dynamic properties, implicit nullable params), and the absence of Laravel auto-discovery. Storage should route through Laravel's Storage facade rather than the library's filesystem writes, so cache lives on a shared volume or object store rather than a container-local temp dir.

Sequencing. (1) Spike and PHP-8 validation. (2) TexRenderer abstraction + provider + config. (3) Container/AMI update with TeX binaries and an immutable image. (4) Queue-backed rendering job with hash-keyed cache (sha256(latex + dpi + options)). (5) Error and fallback path (render failure → placeholder or plain-text formula). (6) Only then expose to production traffic. Keeping the interface in place means a later swap to KaTeX SSR touches one binding.

Operational Impact

Maintenance. Effectively unmaintained upstream — assume you own every future fix. Budget for a named internal owner and a fork in your VCS. No security advisories will arrive; you must self-monitor the LaTeX toolchain, which has its own CVE history.

Support. No vendor, no community, no issue triage. Internal documentation and a runbook are mandatory, particularly around TeX error diagnostics (the library surfaces latex stderr inconsistently, so capture and log it yourself).

Scaling. Rendering is CPU-bound and process-spawn bound; expect roughly 100–300 ms per formula plus binary cold-start. Do not render inline on web requests. Push to a queue with a dedicated worker pool sized to CPU, and cache aggressively — the cache hit rate is the dominant cost lever since formulas are highly repetitive. Horizontal scale requires every worker node to carry a ~500 MB–1 GB TeX image, which slows deploys and cold starts and complicates autoscaling compared to a stateless PHP fleet.

Failure modes. Missing or version-drifted binaries; invalid LaTeX producing non-zero exit or silent blank output; hangs and timeouts from pathological input (enforce a hard Process timeout and memory cap); temp-file collisions under concurrency if the library reuses a shared working directory; disk exhaustion from orphaned temp artefacts; cache stampedes on popular formulas. The file-disclosure vector from \input on untrusted input is the highest-severity failure mode and should be treated as a blocker until mitigated (sandboxed working directory, restricted TeX config, or input validation).

Ramp-up. Low conceptual complexity — a mid-level engineer can wrap the renderer in a day. The real cost is operational: container image management, TeX toolchain familiarity, and sandboxing review. Given the score of 0.24 and zero dependents, the recommendation is to adopt only as vendored, internally-owned code behind an abstraction, or to replace the need entirely with a client-side or Node-based renderer and avoid the server-side TeX footprint.