A Highlight That Stays on Its Sentence

You highlight a sentence on page 214, close the book, and come back with the font one size larger. The sentence is now on page 231, and the highlight is sitting on it anyway. Shrink the font, and the sentence slides back to page 198, highlight still attached. Nothing about the sentence changed. Only the pages moved, because the pages were never part of the book.

Page 214 was never an address

A printed book has pages that stay put. A reflowable book does not. The reader lays the text out fresh every time it opens: font size, line spacing, margins, screen width. Each of those decides where one page ends and the next begins, so a page number is a measurement of the current layout, not a location in the text. Save "page 214" and you have saved a snapshot of settings that no longer exist the moment the reader changes them. The highlight has to be tied to something the layout cannot move.

The address counts down through the document

The stored address works from the inside of the book outward. It names the chapter, then counts elements: this paragraph is the tenth child of its container, that container the fourth child of its parent, and so on down to the text itself. A mark in the middle of a sentence adds one more number, a character offset into that text: the fifth character in, say, rather than the start of the paragraph. Change the font and every page boundary shifts, but the paragraph is still the tenth child of its container and the character is still the fifth one in. The address never mentions a screen, a font size, or a page, so none of those can invalidate it.

A highlight has two ends

A bookmark is a single point: one spot to return to. A highlight is a span, and a single point cannot hold it. The stored form carries three pieces: a shared path to the passage, a start point, and an end point, each with its own character offset. The selected words themselves are saved alongside, together with a little of the text on either side. When the book reopens, the reader walks the same element counts to the same passage and marks from the start offset to the end offset. If the sentence now wraps across three lines instead of two, the span wraps with it, because the span is defined by where the words begin and end, not by the rectangle they happened to occupy on screen.

The page furniture is not counted

One detail makes this hold up in practice. The reader wraps the text in its own containers to draw pages on screen, and those wrappers sit in the document tree right where the counting happens. If they were counted, every change to the paging machinery would shift every address by one. The lookup skips them: when it walks the children of a node, it leaves out the viewport and pager wrappers and counts only the book's own elements. Temporary identifiers the renderer invents while laying out a page are stripped out before the address is saved, for the same reason. Nothing the reader adds to display the book is allowed to become part of the book's address.

Reopen the book at a different font size and the highlight is not recalculated or repaired. It was never stored in terms the font size could touch. The sentence moved to another page, and the highlight went with the sentence, because that is what it was attached to all along.