Tc Lib Unicode Data Laravel Package

Product Decisions This Supports

• RTL and multilingual document support. This package supplies the Bidi_Class, bracket-pairing, mirroring and Arabic shaping tables that a text layout engine needs to render Hebrew, Arabic, Persian and mixed-direction content correctly. If PDF or document export is on the roadmap and international customers are on the account list, this is the unglamorous substrate that makes that feature possible.
• Build vs. buy for Unicode data. Generating Unicode Character Database tables in-house is a recurring maintenance tax with no product differentiation. This package externalizes the data behind a namespaced API (Type::getType, Type::getBidiClass, Arabic::getJoiningType) and a versioned regeneration path (make gendata UCDVERSION=17.0.0), so the decision becomes "do we vendor the tables or own the pipeline?" The honest answer for most teams is vendor.
• Correctness scope for a text-layout epic. The API surface tells you exactly what is and isn't covered: bidirectional classes, mirroring (UAX #9 rule L4), brackets (rule N0), and Arabic joining/presentation forms. That maps cleanly to a backlog: bidi reordering, bracket matching, Arabic shaping. Grapheme clustering, normalization, and collation are not here — useful for sizing what else you'd need.
• Unicode version currency as a support concern. Type::UNICODE_VERSION exposes the UCD release the tables derive from. That turns "are we current with Unicode 17?" from an open-ended research question into a tracked, schedulable dependency bump.
• Roadmap sequencing. This package is a leaf dependency of the TCPDF/tc-lib-pdf stack (100M+ installs claimed for the ecosystem). Adopting it early, before you've hand-written your own bidi shim, is far cheaper than retrofitting later — but it also means your text pipeline inherits the ecosystem's conventions, including the 3.x breaking changes to Type::UNI and Pattern documented in the upgrade notes.
• Vendor and compliance review trigger. The license resolves to LGPL v3 while Packagist metadata reports NOASSERTION. That mismatch is a legal-review item, not an engineering one, and it should be resolved before the dependency appears in a distributed binary or an on-prem appliance.

When to Consider This Package

Adopt when:

• You are building text rendering or PDF generation in PHP and need bidirectional text, bracket mirroring, or Arabic shaping rather than plain left-to-right Latin output.
• You are already in the tc-lib-pdf / TCPDF ecosystem — this is a first-class runtime dependency there, and the integration is essentially free.
• You want a pure-data dependency: no runtime logic, no I/O, deterministic behavior, and a documented regeneration path when a new UCD release lands. That is an easy thing to audit and a hard thing to get wrong.
• You are comfortable on PHP 8.2+ and want the tables rather than the algorithm — your own layout engine consumes them.
• The 3.x semantics fit your model: Type::getType() resolving unlisted code points, and code-point-based Pattern::RTL / Pattern::ARABIC regexes requiring valid UTF-8 input.

Look elsewhere when:

• You need normalization, grapheme segmentation, collation, or locale-aware sorting. This package does not provide them, and stacking it with a partial solution will not get you to ICU parity.
• You need non-PHP coverage, or a single dependency that spans services in multiple languages. Prefer ICU or a language-agnostic Unicode library and keep one source of truth.
• You are not doing complex-script layout. If your output is Latin-only, this adds a dependency and an LGPL review for no user-visible benefit.
• Supply-chain risk tolerance is low. Community signal is thin — 5 stars, 0 dependents, a single maintainer, and a readme-level maturity rating. The ecosystem pedigree is real, but the package itself is not independently battle-tested. If your policy requires multiple maintainers or broad adoption, this fails the screen; pin the version and be prepared to fork the tables if maintenance lapses.
• You need vendor support, SLAs, or security response commitments. There are none here beyond the project's own SECURITY.md.

How to Pitch It (Stakeholders)

To executives: This is a small, data-only dependency that determines whether our generated documents render Arabic, Hebrew and mixed-direction text correctly, or as garbled boxes. It is not a feature; it is the correctness floor under a feature. The cost is a Composer line and a license review. The alternative — building Unicode tables ourselves — is weeks of engineering plus permanent upkeep every time the Unicode standard revises, with zero competitive upside. The ecosystem behind it powers a very large installed base of PHP PDF generation, which is the strongest signal available; the package's own community footprint is small, so we pin the version and treat table regeneration as an owned, scheduled task rather than assuming upstream will carry it.

To engineering: The API is deliberately narrow and data-only — Type, Pattern, Mirror, Bracket, Arabic — covering Bidi_Class (UAX #9), Bidi_Mirroring_Glyph (rule L4), BidiBrackets (rule N0), and Arabic joining types and presentation forms. It does not give you the bidi algorithm, normalization, or shaping logic; that is still ours to write. Requirements are PHP 8.2+ and Composer. Two things to internalize before you start: the 3.x upgrade removes L-class code points from Type::UNI (use Type::getType() instead of array fallbacks), and the Pattern regexes are code-point based with the u modifier, so validate UTF-8 at the boundary. Tables regenerate via make gendata UCDVERSION=… followed by make qa, which is our lever for staying current on Unicode releases.

To legal and security: Two items to close before this ships in anything distributed. First, the repository declares LGPL v3 while Packagist reports NOASSERTION — get a definitive read on the license and confirm our linking and distribution model is compatible. Second, this is a single-maintainer package with minimal independent adoption; record it on the dependency watchlist, pin the version, and note that forking the generated tables is a realistic contingency if upstream goes quiet. Neither is a blocker for evaluation work.