stzFont

Takes a file PATH, or the font's bytes directly (so a font can come from a resource bundle, a database blob, or the network).no extension

(no comment in the source: the name reads as a sentence) id_no extension

(no comment in the source: the name reads as a sentence) sourceno extension

(no comment in the source: the name reads as a sentence) is aliveno extension

(no comment in the source: the name reads as a sentence) glyph countno extension

The chain is ORDERED and the font itself is always asked first, so a fallback never takes a glyph the author's own font could have drawn. Adding the same font twice does nothing; a font cannot fall back to itself, and neither refusal is silent.QCSXTZZZIBWU

(no comment in the source: the name reads as a sentence) fallback countno extension

(no comment in the source: the name reads as a sentence) has fallbacksno extension

(no comment in the source: the name reads as a sentence) clear fallbacksno extension

WHAT THE CHAIN DID to a given string: [ fallback, notdef ] -- how many glyphs came from a font other than this one, and how many the whole chain could not draw and which will appear as a box. A caller who knows can add a font; a caller who knows nothing cannot.no extension

(no comment in the source: the name reads as a sentence) draws every glyph ofno extension

The shaped advance width in pixels -- the number to centre or align by.no extension

How many VISUAL runs the text breaks into: 1 for pure Latin or pure Arabic, 3 for "abc عربي xyz". Bidi made inspectable.no extension

The positioned GLYPH IDs -- in visual order, eight numbers each: [ gid, x, y, byteCluster, pen, advance, clusterEnd, bidiLevel ] The mechanism, exposed: this is what proves Arabic joined rather than merely looking joined. x is the DRAW position (it carries the mark offset); [pen, pen+advance) is the HIT-TEST box -- they are different numbers and confusing them is a classic caret bug.no extension

Vertical metrics in px at this size: [ ascender, descender, lineGap ]. Ascender and descender are both POSITIVE distances from the baseline.no extension

(no comment in the source: the name reads as a sentence) line height ofno extension

THE INK of this string, px: [ above the baseline, below it ], both positive -- the union of the shaped glyphs' extents, not the font's em box. "H" reaches the cap height and 0 below; "g" reaches the x-height and its descender below. The em box (MetricsOf) is the same for every string at a size; this is the string's own.no extension

The cap height at this size, measured: the ink top of an H. What a label centred by eye is centred on -- not the em box, whose centre sits below a capital's by half the descender space nothing uses.no extension

TRUE when the paragraph's own base direction is right-to-left -- which decides where the caret sits past the last character.no extension

Byte offsets, not character counts: they are what the shaper's clusters already speak, and what StzFind and friends return. The visual rects covering the LOGICAL byte range [nStart, nEnd) -- [ [x, top, w, h], ... ], x from the text origin and y DOWN from the baseline at 0. A LIST, because a range that crosses a bidi seam is genuinely in several pieces on screen. An empty range selects nothing -- for a caret, ask CaretRectAt.no extension

bTrailing is the AFFINITY bit, and it is not decoration. At a bidi seam one byte offset has two legitimate screen positions and nothing in the text chooses between them -- the caller's affinity does. Pass back what IndexAtPoint gave you and the round trip is exact.no extension

The character under a point -- [ nIndex, bTrailing, nCaretByte ]. nIndex is the cluster's FIRST byte (what the platform APIs return); nCaretByte is that index already resolved through the affinity, so a caller who only wants "where does the caret go" reads item 3.no extension

reversibility: the two queries every platform ime demandsno extension