Where the caret should land within a footnote's text.
The offset origin is the note's CONTENT: every character run the note contains (including a
leading fr/xo target reference, which PT9's notes pane and FootnoteItem alike render inline
at the head of the note text), AND text written directly in the note, alongside its runs rather
than inside one. It excludes the caller (FootnoteItem renders it in a separate header div), the
USFM markers themselves and the note's \cat category, which is a field on the note rather than
part of its content (see RowTextKind in footnote-caret.utils.ts).
That origin is the note's USJ text, NOT any one rendering of it, which is what lets a position
captured over a read-only row resolve inside a live editor: the editor adds its own display
artifacts around the same content (marker glyphs that are real text under markerMode: "editable", NBSP separators, structural spacers), and only the editor can tell those from
content — so EditorRef.selectNoteTextOffset resolves the offset against its own nodes rather
than any consumer walking its DOM.
'end': after the last character of the note's text.
{ utf16Offset }: a flat offset over the note's content text, in UTF-16 code units (the unit
used by DOM Selection APIs and the editor's text nodes). Offsets originate from browser caret
APIs (caretPositionFromPoint), which only produce positions at valid caret boundaries, so
surrogate pairs and combining sequences are never split by construction. An offset past the
available text resolves to 'end'.
field: 'category': the offset is into the note's \cat category value instead, which is
outside the content origin above but still text the user can edit.
glyph: the caret is inside a marker the note editor shows as editable text - a run's opening or
closing marker (\ft, \ft*, \+nd), an unmatched marker, or \cat/\cat* - rather than in
text. glyph.index says which of the markers sitting at utf16Offset (from 0: \fr*\ft puts
two between the same two characters; \cat sits at the category's start and \cat* at its
end), and glyph.offset how far into that marker's own text, its trailing separator excluded.
Addressing markers relative to the content offset keeps every content offset the same whether
or not a rendering shows markers. The note's own marker, caller and closing marker are never
addressed: the note editor governs those through its own controls.
Where the caret should land within a footnote's text.
The offset origin is the note's CONTENT: every character run the note contains (including a leading
fr/xotarget reference, which PT9's notes pane andFootnoteItemalike render inline at the head of the note text), AND text written directly in the note, alongside its runs rather than inside one. It excludes the caller (FootnoteItemrenders it in a separate header div), the USFM markers themselves and the note's\catcategory, which is a field on the note rather than part of its content (seeRowTextKindinfootnote-caret.utils.ts).That origin is the note's USJ text, NOT any one rendering of it, which is what lets a position captured over a read-only row resolve inside a live editor: the editor adds its own display artifacts around the same content (marker glyphs that are real text under
markerMode: "editable", NBSP separators, structural spacers), and only the editor can tell those from content — soEditorRef.selectNoteTextOffsetresolves the offset against its own nodes rather than any consumer walking its DOM.'end': after the last character of the note's text.{ utf16Offset }: a flat offset over the note's content text, in UTF-16 code units (the unit used by DOM Selection APIs and the editor's text nodes). Offsets originate from browser caret APIs (caretPositionFromPoint), which only produce positions at valid caret boundaries, so surrogate pairs and combining sequences are never split by construction. An offset past the available text resolves to'end'.field: 'category': the offset is into the note's\catcategory value instead, which is outside the content origin above but still text the user can edit.glyph: the caret is inside a marker the note editor shows as editable text - a run's opening or closing marker (\ft,\ft*,\+nd), an unmatched marker, or\cat/\cat*- rather than in text.glyph.indexsays which of the markers sitting atutf16Offset(from 0:\fr*\ftputs two between the same two characters;\catsits at the category's start and\cat*at its end), andglyph.offsethow far into that marker's own text, its trailing separator excluded. Addressing markers relative to the content offset keeps every content offset the same whether or not a rendering shows markers. The note's own marker, caller and closing marker are never addressed: the note editor governs those through its own controls.