@tikoci/centrs
    Preparing search index...

    Interface CoordinateAnalysis

    The full coordinate analysis of one input string.

    interface CoordinateAnalysis {
        analyzed: Uint8Array;
        ascii: boolean;
        lineStarts: number[];
        original: string;
        originalU8: Uint8Array;
        runs: CharRun[];
    }
    Index

    Properties

    analyzed: Uint8Array

    Pure-ASCII surface; analyzed.length === originalU8.length.

    ascii: boolean

    True when every code point of original is ASCII, so analyzed, originalU8 and original agree byte for byte and a byte offset IS a UTF-16 offset.

    This is the property the three coordinate spaces were defined to make checkable, and it is what lets a caller skip the mapping rather than re-derive an identity one. It is a FACT about the input, never a mode: the non-ASCII path below is unchanged and stays the only reading of a non-ASCII document.

    lineStarts: number[]

    Byte offset of each line's first character (index === 0-based line).

    original: string
    originalU8: Uint8Array
    runs: CharRun[]

    One run per code point.

    On the CoordinateAnalysis.ascii path this array is built ON FIRST READ, not by analyzeCoordinates: every caller that only needs an offset or a position can answer from arithmetic there, and materializing one object per character was the single largest allocation in the analyzer (#322). Reading it is always sound — the contract is the array, and the lazy path builds the same one the eager path would have.