Wkhtmltoimage I386 Laravel Package

Product Decisions This Supports

• Feature: HTML-to-image rendering. This package enables server-side conversion of rendered HTML (templates, dashboards, invoices, receipts, report snapshots, share/OG images) into static image files without running a browser service. That directly supports decisions like "can we offer PNG export of this report?" or "can we generate a preview thumbnail at submission time?"
• Build vs. buy (well, "borrow"). Adopting this is a buy-nothing decision: you're not licensing a rendering vendor, you're vendoring a static upstream binary through Composer. The PM decision is whether no commercial cost and no build pipeline outweighs no support contract, no upstream patches, and architecture lock-in.
• Roadmap sequencing. Image export is usually a "nice-to-have that becomes a must-have" once customers need artifacts outside the app (email attachments, Slack/Teams posts, audit evidence, print handoffs). If a roadmap item depends on visual artifacts, this package is the cheapest unblock—but it should not be the long-term platform bet.
• Scope boundary: image, not PDF. This is the wkhtmltoimage half of the wkhtmltopdf project. If the roadmap bundles PDF generation, treat them as one evaluation, but recognize they ship as separate packages and separate binaries.
• Prototyping and internal tooling. Suitable for spike work, internal admin/reporting tools, backfills, and one-off evidence capture where a broken render costs a retry, not a customer.
• Migration planning. Because the last release is 2018 and the upstream QtWebKit renderer is legacy, adopting this is also a decision to schedule a replacement (headless Chromium/Gotenberg/Browsershot) on the roadmap. Price that into the estimate, not just the Composer require.

When to Consider This Package

Consider it when:

• Your target runtime is Linux i386 (32-bit) or you control the container image and architecture, and you specifically need a pinned, version-tagged binary that arrives via Composer rather than the OS package manager.
• You want deterministic dependency resolution (the git tag equals the binary version, e.g. 0.12.4) so CI images are reproducible without apt-get drift.
• You already have a wkhtmltoimage rendering pipeline and just want the binary delivered as a vendor path (vendor/bin/wkhtmltoimage-i386) with no install step.
• The task is low-volume, non-critical, or internal: generating thumbnails, previews, or test fixtures where a degraded render is acceptable.
• You're working in a locked-down/offline build and can't add system packages or external rendering services.

Look elsewhere (or plan to migrate) when:

• Your production fleet is x86_64/ARM64 — the sibling wkhtmltoimage-amd64 package is the relevant one, and this package is only relevant if you're genuinely on i386. Most modern infrastructure is not.
• You need modern CSS/JS fidelity (flexbox/grid gaps, modern fonts, JS frameworks, WebP/AVIF, CSS variables). QtWebKit is old and will not match what users see in a current browser.
• Security and compliance matter: an unmaintained 2018 binary with no patch cadence is a supply-chain and vulnerability-scan finding, and LGPL-3.0 obligations need a legal/redistribution review if you ship it in a product image.
• You need ongoing vendor support, SLAs, or a CVE response path — there is none here, and the upstream project is effectively dormant.
• You want one rendering component for PDF and image — evaluate a maintained renderer (headless Chromium, Gotenberg, Browsershot, or a managed rendering API) so you're not maintaining two abandonware paths.
• Volume is high enough that cold-start/throughput and memory matter; a single-binary CLI per render needs a queue, concurrency control, and timeouts you'll own.

Baseline signals to weigh: 33 stars, 0 dependents, last release January 2018, no README beyond install instructions. Treat this as a thin distribution wrapper, not a maintained library. The engineering risk lives in the upstream binary; the PM risk is that nobody is watching it.

How to Pitch It (Stakeholders)

For executives (one paragraph): We can add "export this to an image" capability quickly and at zero license cost by pulling a precompiled HTML-to-image renderer into our Composer dependencies. It requires no new vendor contract, no build pipeline, and no headless browser service—useful for report previews, receipt images, share cards, and internal evidence capture. The tradeoff is that the underlying renderer is a legacy engine with a 2018-era binary, no support path, and 32-bit-only packaging, so this is a tactical unblock, not a strategic platform. Recommendation: approve for a scoped, low-risk use case or prototype, and fund a migration plan to a maintained renderer before the feature becomes customer-critical. Budget the migration now; it's cheaper than the incident.

For engineering (one paragraph): This package is a Composer-shipped static wkhtmltoimage binary for Linux i386, versioned by git tag (0.12.4) and symlinked to vendor/bin. Wrap it behind a HtmlToImageRenderer interface with explicit timeouts, temp-file cleanup, and a queue—never call it synchronously in a request path. Isolate it: single adapter class, feature flag, and a golden-file render test so a swap to Chromium/Gotenberg is a one-file change. Note the arch mismatch if your CI or production is x86_64/ARM (use the -amd64 variant or install upstream), pin the version exactly, and record the LGPL-3.0 redistribution obligation in your OSS inventory. Assume no upstream fixes: treat any rendering bug as "work around it" and keep the escape hatch warm.