Read three keys for what they are, not for one shape each

[jakejackson1]

Closes #104.

The three reads that remained after #95, #96 and #98: each a key read without checking it is there, each in a different file. None is reached by anything in tests/data/ttf or packages/ today — they were found rendering the current google/fonts releases under error_reporting(E_ALL), where a diagnostic is a failed render and a family that cannot render at useOTL => 0xFF ships at 0 instead.

1. A contextual locl entry has no top-level replace

The pre-pass that indexes single-glyph locl substitutions read ['replace'] on every entry tagged locl. A contextual entry keeps its replacements in ['rules'] and has no such key. The loop twenty lines below it already tells the two apart — elseif (!isset($v['context'])) — and the pre-pass now does too.

Nothing is indexed either way: null was discarded by the same test that discards a replacement of the wrong length. One warning per font load, for each of Noto Sans Devanagari and Noto Sans Bengali.

2. A joining form can be more than one glyph

$rtlpua[] = $sub took ['replace'] for one glyph. A joining form can be a Multiple Substitution — the dotless form of a letter and the dots to draw under it — and the whole string went in as if it were one. hexdec() raised PHP 8's invalid-characters deprecation on it, 30 times per load of Noto Sans Arabic, and returned a number far outside E000-F8FF, so every glyph named in it was dropped.

The three sites that collect these glyphs now share one method, which splits. The list is what magic_reverse_dir reads to know which PUA codepoints are right-to-left, and a mark only ever drawn as part of a joining form belongs in it.

This is the one behaviour any of the three moves. Over 104 fonts — packages/, tests/data/ttf and the current releases of the five families the issue names — the parser output is identical but for rtlPUAstr on the two Arabic fonts, which each gain one PUA codepoint. Neither reaches a page: Arabic::glyphs() returns one glyph for one character, so mPDF's Arabic shaper cannot apply a multi-glyph joining form at all. That limitation is left alone here.

3. A glyph substituted before the SEA reordering has no category

The South East Asian shaper categorises every character, groups them into clusters, then applies locl and ccmp before reordering each cluster — and the reorderer reads ['sea_category'] on the last glyph of a broken cluster.

GSUBsubstitute() already carries a category onto the glyphs it makes, for the Indic, Khmer, Sinhala and Myanmar shapers. The SEA shaper never had a branch. Lanna Alif's ccmp ligates a Sakot with the consonant after it, and a Sakot with nothing in front of it is a broken cluster, so the ligature is exactly what the reorderer asks about.

On the trigger, since a comment on the issue narrowed this half to a cluster of one element: that holds for Noto Sans Tai Tham and is not the rule. Lanna Alif warns on a cluster of two. The difference is U+25CC — Noto Sans Tai Tham has none, so nothing is inserted ahead of the ligature and the cluster is the ligature alone; Lanna Alif has one, and the cluster is the dotted circle then the ligature. Both read $end - 1 and both find the glyph the locl/ccmp pass made. What the read turns on is that the last element came out of that pass, not how many elements there are — so a guard placed on the length would cover only one of the two fonts.

The comment's 21-token split reproduces exactly against notosanstaitham-R.ttf: the 7 tokens it lists warn, the 14 do not, 1A64 1A62 is clean and 1A64 1A62 1A62 warns. All 21 are clean with this fix, and the drawn text is identical before and after it.

Its stronger point stands, and is the real cost: those seven tokens are shaped, so a font that falls back to useOTL => 0 loses that work. 1A73 1A62 draws E225 at 0xFF and two unshaped characters at 0. The magnitude is narrower than every cluster in the document — over 710 runs of the Tai Tham block only 7 draw differently at 0xFF than at 0 — but those 7 include the pre-base matra reordering 1A20 1A55 → 1A55 1A20, which is the visually significant kind.

This is #89 and #96 one script over, answered the same way: at the seam where the glyph is made, with the category of the character it replaces.

What moves on a page

Nothing. Two sweeps stand behind that:

sweep	runs	result
parser output over 104 fonts	104	identical but rtlPUAstr on 2 Arabic fonts, +1 codepoint each
drawn text, Tai Tham and New Tai Lue and Arabic blocks in 5 fonts	2,969	identical

The Tai Tham snapshot was generated against the code before the fix as well as after, and is byte-identical.

Test fonts

• NotoSansDevanagari-ContextualLocl-Subset — 4 glyphs of Noto Sans Devanagari 2.005 (OFL 1.1): the contextual locl of the Santali language system, backtracking an independent vowel to substitute a Santali nukta
• NotoSansArabic-MultipleForm-Subset — 8 glyphs of Noto Sans Arabic 2.012 (OFL 1.1): the Farsi Yeh, whose initial and medial forms replace it with the dotless form and the pair of dots under it, and a Beh to join it to

Both golden masters cover them from here. The parser fixture holds rtlPUAstr; the dump fixture holds every diagnostic raised reading the font, so either read coming back is a diff rather than a warning nobody sees. A test beside them asserts each font loads clean, since a deprecation is not converted to an exception and would otherwise pass unnoticed.

Not in this PR

The Gurmukhi diagnostic reported in a comment on #104 is #102, and is fixed separately.

🤖 Generated with Claude Code