# NOTICE

## Origin of this code

The TypeScript source and compiled JavaScript runtime integration work in this repository is
original work by **Sythos (https://www.sythos.net)**. No third-party barcode
source code is copied into or shipped by this package. Public or normative
format values may be represented in original Sythos data structures, with
provenance and legal-review status recorded where required.

The symbologies are implemented from **published descriptions of the formats**
(which are systems and facts, not works of authorship) and from **constant
tables generated by this project's own scripts** in `tools/`, wherever a table
is derivable rather than arbitrary.

## What "third-party" means here

| | |
|---|---|
| Runtime dependencies | **none** |
| Bundled third-party code | **none** |
| Third-party licenses applying to the distributed package | **none** |

The `LICENSE` file carries the full MIT text plus an informational appendix
inventorying specification copyrights, patent history and trademarks that
surround these symbologies. The appendix is an engineering record, not legal
advice, and does not resolve obligations in every jurisdiction.

## Where other barcode libraries may and may not appear

The line is drawn at **invoke vs. incorporate**:

| | |
|---|---|
| Running an independent implementation during **testing**, comparing its output to ours | **allowed** |
| Copying its source code into this project | **not done** |
| Consulting public technical material or an implementation during review | allowed with provenance |

Such outputs are facts about a published symbology. Comparing against them is a
testing activity; it does not place their code in the distributed package and
is not a legal conclusion about derivative works.

No third-party barcode code is a runtime dependency, and none of it ships in the
published package. See `LICENSE` §2.

## How correctness is verified

Five independent mechanisms. The first four require no other barcode
implementation to exist at all; the fifth is the cross-check.

**1. Self-validating tables.** Where a constant table is redundant with
geometry, the redundancy is checked. QR's error-correction block table is the
clearest case: for every one of the 160 version/ECC-level combinations, the sum
of data and ECC codewords across all blocks *must* equal the symbol's total
codeword capacity — and that capacity is computed independently from the module
geometry (symbol size, minus finder, timing, alignment, format and version
areas, divided by 8). A single mistyped digit anywhere in that table breaks the
identity and fails the test. The table cannot be quietly wrong.

**2. Structural invariants.** Reed–Solomon must correct up to the theoretical
limit of `floor((n-k)/2)` symbol errors and no further; a wrong generator
polynomial or a mishandled field operation fails this well before any symbol is
produced. Checksums, guard patterns and mode-length constraints are asserted
per format.

**3. Reference values computed from first principles.** Where a published
worked example exists in the format's public documentation, its intermediate
values are checked — not copied code, just the arithmetic any correct
implementation must reproduce.

**4. The real world — the decisive test.** `git/examples/create.html` renders any
symbol to the screen; a phone camera or a supermarket scanner reads it or does
not. This is the strongest oracle available and the one that actually matters,
because it tests against the installed base of real scanners rather than
against one other library's opinion. **A format is not considered finished
until a symbol it produced has been read by a device this project did not
write.**

**5. Differential testing against independent implementations.** Random
payloads across every version and ECC level are encoded here and decoded by
several unrelated third-party barcode implementations — and vice versa. These
are invoked as black boxes; their source and tables are not shipped by this
project.
Agreement across implementations that share no lineage is strong evidence of
correctness; disagreement localises a bug immediately.

Note that round-trip testing (encode → decode with our own code) is used for
regression coverage but is explicitly **not** treated as proof of correctness:
it is symmetric, so a fault applied consistently in both directions passes it
while producing symbols no scanner can read. Mechanisms 1, 4 and 5 exist
precisely to catch that class of fault.

## Attribution log

Records any constant table whose values were transcribed from a documented
source rather than generated by `tools/`. Each entry names the source and the
date of transcription.

| PDF417 pattern ordering | AIM USS-PDF417 public reference ([reference copy](https://www.expresscorp.com/uploads/specifications/44/USS-PDF-417.pdf)), Appendix H / Table H1, represented in the TypeScript source `src/ts/pdf417/tables.ts` and emitted to `src/js/pdf417/tables.js`; accessed 2026-08-11. The reference copy is attributed here; its copyright and redistribution terms remain under legal review. |
| PDF417 black-box verification | ZXing Java 3.5.3 and bwip-js 4.5.1 were invoked as external black boxes on 2026-08-11 for bidirectional Text/Numeric/UTF-8 vectors. Their source and tables are not shipped. |
| PDF417 device evidence | User-provided 6/6 continuous-camera attestations on Pixel 10/Android 17/Chrome and iPhone 17/Safari, including printed Brother MFC-L2710DW symbols, low light/flash, blur and motion; recorded as user evidence, not independently captured by this repository. |
| MicroPDF417 technical and provenance review | [ISO/IEC 24728:2006](https://www.iso.org/standard/38838.html), [Wikipedia overview](https://en.wikipedia.org/wiki/MicroPDF417), [US 6,047,892 record](https://patents.google.com/patent/US6047892A/en) and its [direct PDF](https://patentimages.storage.googleapis.com/0a/79/f5/e8d374043414f3/US6047892.pdf) were consulted on 2026-08-11. ZXing-C++, Zint and bwip-js were consulted for implementation/review or black-box validation. No third-party source code is copied or shipped; normative/public values are represented in original Sythos data structures, with provenance and legal review pending. |
| Micro QR technical and interoperability review | ISO/IEC 18004 public technical material, DENSO WAVE's [Micro QR overview](https://www.qrcode.com/en/codes/microqr.html), Segno and ZXing-C++ were consulted on 2026-08-12 for format rules, fixture checks and black-box comparison. No third-party source code is copied or shipped; Micro QR values are represented in original Sythos structures. ECI, FNC1 and Structured Append are outside the current Micro QR API scope. Standard copyright, patent and trademark questions remain subject to legal review. |
| rMQR technical and interoperability review | ISO/IEC 23941:2022 public metadata, DENSO WAVE's [rMQR overview](https://www.denso-wave.com/en/adcd/fundamental/2dcode/qrc/rmqr.html), and ZXing-C++ were consulted on 2026-08-12 for the 32 geometry/ECC layouts and black-box checks. No third-party source code is copied or shipped; rMQR values are represented in original Sythos structures. Standard copyright, patent and trademark questions remain subject to legal review. |
| FrameQR Code | DENSO WAVE's [FrameQR overview](https://www.qrcode.com/en/codes/frameqr.html), [product page](https://www.denso-wave.com/en/system/qr/product/frame.html) and [public announcement](https://www.denso-wave.com/en/adcd/info/detail__272.html) were consulted on 2026-08-13. The public material is used only to document the proprietary-format boundary; the distributed implementation is the separate non-certified `sythos-canvas-qr/1` profile. ZXing Java 3.5.3 was used only as an independent black-box runtime check: QR Model 2 control passed, `FRAME_QR` native capability was unavailable, and the profile was decoded as ordinary QR. No ZXing source code or tables are copied or shipped; native DENSO interoperability is not claimed. |
| Aztec Rune and Compact PDF417 | ISO/IEC public technical descriptions and ZXing-C++ 3.1.1 were consulted on 2026-08-13. ZXing-C++ was used exclusively as an independent black-box validation tool; no source code or table is copied or shipped. Aztec Rune values were compared exhaustively; Compact PDF417 geometry and payload vectors were compared independently. |
| EAN-2 and EAN-5 supplements | ISO/IEC 15420, GS1 public specifications and ZXing-C++ 3.1.1 were consulted on 2026-08-13. The add-on parity, guard and checksum routines are original Sythos code; ZXing-C++ was used only for independent add-on validation. |
| GS1 DataBar physical variants | ISO/IEC 24724 and public GS1 material were consulted on 2026-08-30. The Omnidirectional/Truncated, Limited, Stacked, Stacked Omnidirectional and Expanded encoders/decoders use original Sythos arithmetic and strict geometry checks. The Expanded reader covers the general-purpose path plus the common compressed GTIN-14 method; its detector remains a clean, single-symbol linear profile. Independent implementations were used only as black-box verification; no third-party source code or table is copied or shipped. |
| MaxiCode | ISO/IEC 16023 public descriptions and independent implementation behavior were consulted on 2026-08-30. The fixed-grid placement, Modes 2–5 primary/secondary handling, ISO-8859-1 Code Sets A–E and Reed–Solomon path are original Sythos code. Independent runtimes were used only for black-box review; no third-party source code or table is copied or shipped. The detector is limited to one clean, prominent 30×33 symbol and does not claim arbitrary perspective or multi-symbol scene support. |
| Code 11 and MSI Plessey image readers | Published format descriptions and the existing Sythos writer tables were used to implement the scanline readers on 2026-08-13. No third-party source code or table is copied or shipped; checksum and start/stop validation remain original Sythos code. |
| Telepen Alpha and Numeric | Public Telepen descriptions were consulted on 2026-08-30 for seven-bit parity, narrow/wide glyph rules, Numeric pair compaction and modulo-127 checksum behavior. The implementation generates its glyph mapping algorithmically in original Sythos TypeScript; no third-party table or source is copied or shipped. ZXing-C++ and BWIPP/bwip-js were used solely as independent black-box validation tools. |
| Code 25 family | Public descriptions of Code 25/Standard 2 of 5, Industrial 2 of 5 and IATA 2 of 5 were consulted on 2026-08-30 for the two-wide-bar digit grammar and guard frames. Original Sythos TypeScript expands the run-width rules algorithmically and validates structure/check digits. BWIPP/bwip-js was used only as a local black-box counter-check; no third-party source or table is copied or shipped. |
| Data Logic 2 of 5 (China Post) | Public descriptions of Data Logic 2 of 5 (also documented as China Post Barcode) were consulted on 2026-09-01 for its width-modulated digit grammar and IATA-style guard frame. Original Sythos TypeScript expands the run-width rules algorithmically and validates structure/check digits; the 2:1 wide:narrow ratio is intentionally rejected because it produces a reversed-image ambiguity in this digit grammar, found during implementation testing. Zint (libzint, BSD-3-Clause) was used only as a local black-box counter-check of the digit width table; no third-party source or table is copied or shipped. See `licenses/data-logic-2-of-5.license`. |
| Facing Identification Mark (FIM) | USPS Publication 25 ("Designing Letter and Reply Mail"), chapter 10, was consulted on 2026-09-01 for the five fixed nine-position patterns (A-E) and their palindrome structure. This is the same public USPS documentation basis already used for the postal 4-state family (`licenses/postal.license`). The bar presence/absence pattern is original Sythos data; no third-party source or table is copied or shipped. The reader's false-positive rate was verified with an adversarial sweep (random noise and checkerboard textures across multiple render scales) during implementation. See `licenses/facing-identification-mark.license`. |
| ITF-6 | JIS X 0502 (1987) and ISO/IEC 16390 (the underlying ITF symbology, already implemented) were consulted on 2026-09-01. ITF-6 is not a new digit grammar: it reuses this project's existing ITF encoder and its existing alternating-3/1 modulo-10 check digit routine (the same one used for ITF-14 and EAN), constrained to six digits with a mandatory check digit. No third-party source or table is copied or shipped. See `licenses/itf-6.license`. |
| JAN (Japanese Article Number) | ISO/IEC 15420 and public GS1 material on the Japan-assigned 45x/49x prefix range were consulted on 2026-09-01. JAN is not a new symbology or check digit algorithm: it is this project's existing EAN-13 encoder with a prefix validation added, following the exact same shared-decoder pattern already used for ISBN. No source code or table from any other implementation is copied or shipped. See `licenses/jan.license`. |
| Matrix 2 of 5 | Public descriptions of Matrix 2 of 5 were consulted on 2026-09-01. It reuses the width-modulated digit table already implemented for Data Logic 2 of 5 with its own, independently verified guard frame; the same 2:1 wide:narrow ratio rejection already documented for Data Logic applies here too, since both share the digit table. Zint (libzint, BSD-3-Clause) was used only as a local black-box counter-check of the guard-frame structure; no third-party source or table is copied or shipped. See `licenses/matrix-2-of-5.license`. |
| Plessey Code | Public descriptions of Plessey Code (the format MSI Plessey, already shipped as `msi`, is a variant of) were consulted on 2026-09-01, including the sixteen-value reversed-BCD digit table, guard frame and the mandatory CRC-8 check (polynomial x^8+x^7+x^6+x^5+x^3+1). The polynomial was cross-verified across two independent public technical descriptions plus Zint's (libzint, BSD-3-Clause) own generator constant before an original Sythos bitwise implementation was written. Zint was used only as a local black-box counter-check of the digit table and guard frame; no third-party source or table is copied or shipped. See `licenses/plessey.license`. |
| Code 32 and PZN | Public descriptions and independent format behaviour were consulted on 2026-08-30 for Code 32 base-32/vowel-skipping/check-digit rules and PZN-7/PZN-8 modulo-11 validation. The carrier and arithmetic are original Sythos code. BWIPP/bwip-js was used only as a local black-box counter-check; no third-party source or table is copied or shipped. |
| Postal 4-state family | Public descriptions of USPS POSTNET/PLANET/IMb, Royal Mail RM4SCC, KIX, Australia Post and Japan Post were consulted on 2026-08-31 for their operator-specific state alphabets, framing, checks and payload envelopes. The shared classifier, check routines, Australia GF(64) parity and IMb combinatorial mapping are original Sythos TypeScript. BWIPP/bwip-js was used exclusively as a local black-box validation tool for all seven formats; no third-party source, table or runtime dependency is copied or shipped. See `licenses/postal.license`. |
| Codablock-F and Code 16K | Public stacked Code 128 descriptions and the USS Code 16K reference were consulted on 2026-08-31 for row geometry, Code 128 framing and check boundaries. The encoders, readers and detectors are original Sythos TypeScript. Independent implementations, when used, are black-box validation only; no third-party source, table or runtime dependency is copied or shipped. Patent, trademark and specification licensing positions remain subject to legal review. |
| KarTrak ACI (experimental, colour-coded) | The raw wikitext of Wikipedia's "KarTrak" article and Ian Cranstone's independent nakina.net technical guide were consulted on 2026-09-01 for the colour-to-value table and 13-line label structure; the two agree exactly on every table entry. The START/STOP marker glyph geometry was additionally verified pixel-for-pixel against the article's own reference SVG diagrams on Wikimedia Commons, after an earlier automated fetch of the rendered page was found to have transposed the table's rows and columns. The mod-11 weighted checksum was independently confirmed by reproducing the article's own worked example ("Start 8350199918 Stop 5") from only the payload digits. The `PolychromeMatrix`/`toColorImageData`/`classifyGrid` colour primitives and the `src/ts/kartrak/` format module built on them are original Sythos TypeScript; no third-party source, table or image asset is copied or shipped. See `licenses/kartrak-aci.license` and `docs/COLOR_PIPELINE_NOTES.md`. |
| PostBar (Canada Post CPC four-state, C10/D22/G12) | US Patent 5,602,382A ("Multiple Bar Code Processing," Canada Post Corporation, filed 1994, granted 1997) was consulted on 2026-09-01, read directly from its rendered page images rather than any automated text/OCR extraction of the PDF, which was found to garble the two-column symbol tables (both this project's own `pdftotext -layout` and an earlier independent fetch of the same patent produced internally inconsistent results; the actual scanned pages are completely legible). The 'A'/'N'/'Z' character tables, field layouts for the C10/D22/G12 profiles, and the Reed-Solomon parameters are original Sythos data, transcribed directly from the page images and independently verified by reproducing the patent's own fully worked PostBar.C10 example (DCI=Z, postal code K1S 5B6, machine ID DHAH) exactly, symbol for symbol, plus PostBar.D22's own worked example. Reed-Solomon arithmetic reuses this project's existing `core/galois-field.ts` `GF64` constant and `core/reed-solomon.ts` generic codec (already used elsewhere in this SDK), not a new implementation. No source code, table or image asset from any other barcode implementation is copied or shipped; none is known to publicly implement PostBar (BWIPP, Zint and ZXing were checked). See `licenses/postbar.license`. |
| DX Film Edge Barcode | US Patent 4,965,628A ("Photographic Film With Latent Image Multi-Field Bar Code and Eye-Readable Symbols," Eastman Kodak, filed 1989, granted 1990) was consulted on 2026-09-01, read directly from its own page images. Its high-level summary states a 7-bit frame-number field, which conflicts with real film samples; the raw wikitext of Wikipedia's "DX encoding" article (citing a 2017 peer-reviewed archival-science paper analyzing real film) and Zint's `dxfilmedge.c`, consulted only as an independent black-box behavioural reference, both agree on 6 bits and clarify the two "unassigned" bit positions as fixed separators — this SDK follows that real-world-verified structure. The bit-field layout, fixed clock-track patterns and parity algorithm are original Sythos code; no source code, table or image asset from any other implementation is copied or shipped. See `licenses/dx-film-edge-barcode.license`. |
| DotCode | Public AIM/GS1 descriptions, the DotCode overview and Zint's public backend were consulted on 2026-08-31 for the alternating-dot geometry, five-of-nine patterns, masks and correction profile. The encoder, reader and detector are original Sythos TypeScript. Zint, ZXing and other software are independent black-box references only; no third-party source, table or runtime dependency is copied or shipped. Patent, trademark and specification licensing positions remain subject to legal review. |
| Han Xin Code | Public Han Xin format descriptions and independent implementation behaviour were consulted on 2026-08-31 for the bounded compact versions 1–3 profile. The encoder, reader, detector and GF(256) correction path are original Sythos TypeScript. Independent software is used only as a black-box validation reference; no third-party source, table or runtime dependency is copied or shipped. Version, patent, trademark and specification licensing positions remain subject to legal review. |
| GS1 DataBar Composite | ISO/IEC 24723 and public GS1 material were consulted on 2026-08-31 for the bounded Sythos profile that links one validated DataBar host to one strict MicroPDF417-derived CC-A or CC-B component. The marker, composition, linkage and detector are original Sythos TypeScript. Independent implementations are black-box validation tools only; no third-party source, table or runtime dependency is copied or shipped. This profile does not claim complete ISO/IEC 24723 conformance or certification; patent, trademark and specification positions remain subject to legal review. |
| GS1-128 semantic layer | The existing shared GS1 Application Identifier metadata and public GS1 descriptions were reused on 2026-08-13. FNC1 classification and parsing are original Sythos integration code; no third-party decoder is a runtime dependency. |
| Payload conventions (vCard, VIN, SPARQCode, Swiss QR-bill, SEPA/EPC QR, AAMVA) | None of these six is a barcode symbology; each is a structured payload convention carried by an already-implemented one (`qr`, `code39` or `pdf417`), added 2026-09-02. RFC 6350 (vCard) and ISO 3779/FMVSS 115 (VIN check digit) are widely published standards. SPARQCode's own conventions were found, on research, to already be public (URI schemes, RFC 5870, `WIFI:`, vCard) rather than a proprietary MSKYNET format. Swiss QR-bill was implemented from SIX Interbank Clearing's own "Swiss Implementation Guidelines for the QR-bill" v2.3 PDF, including independently reproducing the document's own Annex B "Modulo 10 recursive" check-digit worked example byte-for-byte before accepting the algorithm (the table itself is a diagram image in the source PDF, not extractable text). SEPA/EPC QR was implemented from the European Payments Council's own EPC069-12 v3.1 PDF, with the trailing-empty-field-omission rule verified against both of that document's own worked examples. AAMVA was implemented from AAMVA's own 2020 DL/ID Card Design Standard PDF, with the header/offset/length computation independently verified against that document's own D.13 worked example. AADHAAR was investigated for the same treatment and deliberately excluded instead, since a "valid" Aadhaar QR code requires UIDAI's own private signing key — see `docs/guides/legal-exclusions.md`. No source code, table or image asset from any external implementation is copied or shipped; every builder is original Sythos TypeScript written from the standards' own published text. See `licenses/payload-conventions.license`. |
| JAB Code (experimental, colour-coded) | The reference implementation's own C source (github.com/jabcode/jabcode, MIT since April 2026, LGPL before that) was consulted on 2026-09-02, read directly rather than any secondary description, for the default 8-colour palette, alignment-pattern position tables, LDPC pseudo-random generator/matrix construction/Gauss-Jordan elimination, byte-mode data segment format and module placement. This project implements only the reference encoder's own "default mode" fast path (8 colours, ECC level 3, mask type 7, no metadata Part I/II) plus byte-mode-only data encoding — a deliberate scope reduction from the full ISO/IEC 23634:2022 specification, documented in `docs/JABCODE_NOTES.md`. No compiler was available to build the reference as a decode oracle, so verification is self-consistency only (this project's own encoder and decoder agree with each other), not confirmed interop with the real jabcode library — an indexing bug this process itself found and fixed (a mis-sized array causing a silent out-of-bounds write on a JS typed array) is recorded in that file as evidence of the verification process, not evidence of a resolved interop question. `PerspectiveTransform`, `PolychromeMatrix`, `toColorImageData` and `classifyGrid` are this project's own pre-existing primitives, reused rather than copied from the reference. No source code, table or image asset from the reference implementation or any other barcode implementation is copied or shipped. See `licenses/jab-code.license` and `docs/JABCODE_NOTES.md`. |

## Verification log

Records the scoped review labels used by the inventory. Current labels include
`[VERIFIED FACT]`, `[REGISTRY CHECK REQUIRED]`, `[PATENT FAMILY REVIEW REQUIRED]`,
`[LICENSE TERMS REVIEW REQUIRED]` and `[LEGAL REVIEW]`.