[behdad]

Add sanitization for OFF 2026 variable composites and extended glyph repertoires. Fonts using these formats can retain their outlines, mappings, layout and variation data through sanitization, including fonts with both legacy and uppercase tables. CFSH is excluded.

• Add VARC validation for components, transforms, axis values, conditions and variation-store references. Use the current 32-bit sparse-region count and indirect axis-coordinate and delta-set INDEX offsets, as clarified in the VARC specification update.
• Support GSUB/GPOS 1.2 and GDEF 1.4, extended lookup formats, Coverage/ClassDef formats 3 and 4, and value/boolean conditions. Memoize conditions by resolved offset and retain subtree heights when checking nesting limits.
• Support MAXP, GLYF, LOCA, HHEA, HMTX, VHEA, VMTX and GVAR, including cubic outlines, 24-bit composite references and matching empty variation-table synthesis for hybrid fonts.
• Support DMAP, cmap format 15, COLR PaintGlyph2, TTC 1.1/2.1 directories, extended CFF2 glyph counts and the smaller CFF2 outline sets permitted with VARC.
• Correct collection-table cache identities and synthetic-table serialization identities, and reject duplicate directory tags before parsing. Fix two existing cleanup errors exposed by sanitizer-instrumented corpus tests.

Add regression tests for extended glyph IDs, offsets beyond 64 KiB, mixed field widths, malformed/truncated data, shared condition graphs, depth limits, and uppercase-only and hybrid font round trips. Update four VARC corpus fonts to the current variation-store encoding.

Validation: all 685 Meson tests complete successfully in both the normal and AddressSanitizer/UBSan builds: 562 passes and 123 expected rejections. The CIFuzz duplicate-tag reproducer is rejected cleanly. A separate five-minute libFuzzer/ASan run replayed the public OSS-Fuzz corpus and completed 638,152 input executions without a crash.

Also tested NotoSans-beyond64k.ttf with 104,404 glyphs. FreeType confirms identical outlines and metrics for every glyph; HarfBuzz shaping matches for 20 multilingual samples. GDEF, GPOS, GSUB and cmap remain byte-identical, and a second sanitization produces identical output.

[behdad]

@khaledhosny can you review this please?

[behdad]

Hi, I’m Codex, an AI coding agent from OpenAI. I reviewed this PR for sanitizer blockers and correctness bugs.

I would block merging on the first four findings:

1. Blocker — exponential condition-validation DoS.
   ConditionAnd/ConditionOr recursively validate every referenced child, but only recursion depth is limited. Reusing the same child twice at each level produces exponential work. A 309-byte VARC with 29 levels took 3.32 seconds to sanitize; slightly deeper inputs can effectively hang OTS. Add memoization or a global condition-edge/work budget.

2. Blocker — variation delta payloads are not sanitized.
   ParseMultiItemVariationData only validates the enclosing CFF2 Index; it never parses its TupleValues objects. I changed a 14-byte delta set to declare a 64-byte run: OTS reported success and preserved it, while fontTools rejected it as truncated. Each object must be decoded within its own bounds. Tuple cardinality should also be retained so VarIdx uses can be checked against the required axis/transform/value tuple length.

3. Blocker — axisIndicesList values are never validated.
   The parser counts tuple entries but discards their values. In a font with eight fvar axes, I changed [2,3,4] to [127,3,4]; OTS sanitized it successfully and retained axis 127. Decode these values and require every index to be below fvar.axisCount. Component axis values are similarly only skipped rather than semantically checked.

4. Blocker — zero glyph records disables the required coverage-count check.
   A count of zero is passed to ParseCoverageTable, where zero means “do not check.” Changing the fixture from four glyph records to zero while leaving four covered glyphs was accepted. Counts above 0xFFFF also disable validation. Coverage indices select glyph records, so the counts must always agree.

5. Bug — invalid five-byte uint32var values are truncated.
   The implementation acknowledges that only 0xF0 is valid but accepts 0xF1–0xFF, discarding the high bits. F1 00 00 00 00, representing 2^32, was accepted as zero. Reject any five-byte lead other than 0xF0; ideally also enforce canonical encodings.

6. Bug — Condition format 1 accepts coordinates outside the normalized range.
   The new parser checks only axisIndex. A condition spanning raw [-0x8000, 0x7FFF] was accepted, although these condition values must be between −1 and +1. The existing OTS condition validator already performs this check.

The full local 658-test suite and all GitHub checks pass, but the PR adds only good-font fixtures, so none of these rejection paths are covered.

[behdad]

I did a review with codex and addressed the findings with Claude. Should be in better shape now, but more LLM review might be justified.