Tc Lib Barcode Laravel Package

Product Decisions This Supports

Build vs. buy (the core decision): Barcode symbology encoding is solved, specification-heavy work (Reed–Solomon error correction, GS1 check digits, USPS IMB bit-stuffing). Building it in-house is a 3–6 month distraction with permanent maintenance liability and real compliance risk. This package collapses that to a composer require plus ~1 day of glue. Recommendation: buy, wrap, and treat it as infrastructure — not a feature.

Which product bets it unlocks (prioritise by job-to-be-done, not by format list):

Output-format choice is a product choice: SVG for print fidelity and email-safe HTML, PNG for third-party API upload, and the raw bar-coordinate array for direct PDF canvas drawing. Decide per surface; don't default to PNG everywhere (quality loss on reprint, CPU cost at scale).

Data-egress / privacy position: generation is in-process, pure PHP, zero network calls. Barcode payloads frequently contain PII (addresses, order IDs, patient identifiers). Keeping generation server-side avoids shipping that data to a SaaS barcode API — a genuine differentiator vs. BarcodeAPI-style vendors, and a security-review-friendly line item.

Packaging & pricing implications: 40+ symbologies cost the same to adopt as one. Do not put QR generation behind a paywall — it's commoditised. Monetise the workflow layer instead: label templates, batch jobs, printer integrations, scan-history/audit. Barcode breadth is an enabler that reduces "we can't serve that segment" losses, not a headline feature.

Roadmap risk to socialise: advertised as "70+ barcodes," the README enumerates ~30 base symbologies plus checksum/variant modes. Plan against the enumerated list. Also treat this as table stakes with low differentiation (299 stars, minimal direct dependents, but it is the extracted encoder from the TCPDF ecosystem — a huge installed base via that lineage, which is why maturity reads higher than the star count suggests).

Effort/ROI sketch for the business case: adoption ≈ 1 day glue + 3 days PoC/scan-verification + ~0.5 day/quarter maintenance. Compared with 3–6 engineer-months to build, plus ongoing compliance rework. Payback is immediate if any one of the above segments is on the roadmap.

When to Consider This Package

Adopt when all/most of these hold:

• You are on Laravel + PHP 8.2+ and ext-gd is available (near-universal in standard images); ext-bcmath optional but recommended if PDF417/IMB throughput matters.
• You need more than QR — any linear, postal (IMB, POSTNET, Royal Mail RMS4CC), or 2D (PDF417, Aztec, DataMatrix) symbology. This is the primary reason to pick it.
• You need print-grade output (SVG or raw coordinates) alongside web output, not just a QR PNG.
• Offline/deterministic generation matters: same input → byte-identical output, so responses are cacheable by hash and testable via snapshot assertions.
• You can absorb batch generation into queued jobs (SVG/coordinate output, aggressive caching) rather than synchronous request-time rendering of thousands of PNGs.
• LGPL-3.0 is acceptable to your legal posture (unmodified library consumed via Composer is normally fine; modifications to the library itself trigger source-disclosure obligations — confirm with counsel, see the license caveat below).

Look elsewhere when any of these is true:

• You only need QR codes. Use endroid/qr-code or simplesoftwareio/simple-qrcode — smaller surface area, more idiomatic Laravel ergonomics, better docs, same result.
• You only need simple linear codes and want a Laravel-native wrapper: picqer/php-barcode-generator or milon/barcode will get you there with less integration work.
• You need decoding/scanning. This is generation-only. Pair with client-side ZXing/AI vision, or validate against your actual scanner hardware — budget a device test matrix as a real QA line item.
• You need GS1 application-identifier structuring, label template design, or compliance certification. That's your own layer (or a paid GS1/label SaaS), not this package.
• You need barcode-in-PDF as the primary output — go further up the same ecosystem (tecnickcom/tc-lib-pdf) rather than pairing this with a generic HTML→PDF tool, unless you already have a PDF pipeline (in which case the coordinate-array output drops in cleanly).
• You require a vendor SLA, >1 maintainer, or fast security response. Single-maintainer project; releases are recent and cadence is healthy, but bus factor is 1. Acceptable for infrastructure you can fork; not acceptable if your legal/procurement team demands contractual support.
• PHP < 8.2 and an upgrade isn't funded.
• Packagist metadata shows the license as NOASSERTION even though the README states LGPL-3.0. Do not ship to production until Legal reads LICENSE and confirms. This is the single hard gate on the list.

Two gates before committing (cheap, do them first):

1. Scan gate (3 days, one engineer): generate every format you actually plan to ship, print at target DPI, scan with the actual scanner hardware/pallets customers use, on both a printed and a screen surface. Encoding correctness without hardware verification is an unfounded assumption. Include check-digit and edge-case payloads (max length, leading zeros, non-ASCII).
2. License gate (parallel, Legal): confirm LGPL-3.0 obligations for Composer-linked use and get a written position on forking.

How to Pitch It (Stakeholders)

One-liner for executives: "We can ship barcode and QR generation — shipping labels, inventory tags, retail scan codes, pharma-compliant 2D codes, postal codes — in about a week of engineering instead of a quarter, using a mature, battle-tested PHP library from the TCPDF lineage. No new infrastructure, no third-party API, no customer data leaving our servers."

Executive framing (cost / risk / upside):

• Cost: ~1 week of engineering to production-grade; negligible run cost (CPU only, cacheable output).
• Upside: unblocks concrete revenue segments — retail/POS, logistics, pharmacy — and removes "we can't generate that code" from sales conversations.
• Risk: low and bounded. PHP 8.2 is already our floor or an easy upgrade; dependency footprint is ext-gd/ext-bcmath. Worst case we fork — the licence permits it.
• What it is not: not a moat. Competitors can adopt it too. The durable value is the workflow around it (label templates, batch printing, scan audit), which we own.
• Ask: approve a 3-day spike (one engineer + Legal licence read) with a go/no-go on scan verification.

For engineering:

• Pure-PHP, spec-driven encoders: ~30 base symbologies across linear / 2D / postal, with checksum variants. Outputs: SVG (inline/file/document), PNG (GD or Imagick), GD object, HTML divs, character grid, and raw bar-coordinate arrays — the last one is how you draw crisp vectors straight into PDF/label canvases.
• Deterministic output → cache by sha256(type + data + dimensions + colours); store generated SVGs in object storage; serve from a route or signed URL. Never regenerate per page view.
• Gotcha to document: the sizing API is non-obvious — width/height/padding accept signed values where negative means absolute pixels and positive means relative units (see the README quick start using -4). Pin this in internal docs and lock it with snapshot tests before other teams depend on it.
• Batch work belongs in queued jobs with chunking; keep synchronous requests to single-code rendering. Watch memory_limit on large PDF417/IMB payloads (bcmath speeds the arbitrary-precision maths; install it).
• Integration surface: bind a thin BarcodeService in the container, expose a facade/Blade component, and keep the vendor class behind that seam so swapping to endroid/qr-code or picqer later is a one-file change. Mock the service in unit tests; assert magic bytes (\x89PNG, <svg) and SVG path counts in integration tests.
• Pin the version in composer.json; watch releases; add a CODEOWNER for the wrapper.

For legal / security: no network calls, no data egress, no telemetry; input is sanitised by the encoders, but validate and length-check user-supplied payloads upstream. Licence is stated as LGPL-3.0 in the README while Packagist reports NOASSERTION — verify the LICENSE file directly before go-live, and avoid modifying the library in place.

Proposed next steps: (1) Legal reads LICENSE — 1 day. (2) PoC: BarcodeService + one PNG route + one SVG-in-PDF path — 1 day. (3) Hardware scan verification across the formats we intend to sell — 1 day. (4) Go/no-go, then wrap in a facade, add caching, queue the batch path, and document supported formats per product surface.