Back to the Same Sentence, on Another Screen

Page Numbers and Private Bookmarks Don't Travel

Enlarge the font on a phone and a book repaginates. What was page 42 becomes page 57, and a highlight saved as "page 42" now points at the wrong paragraph. Move to a laptop with a wider window and the pagination changes again, even though not a word of the book changed. A page number records where text happened to fall on one screen at one font size. It cannot survive the next screen, because it was never a property of the text in the first place.

A bookmark saved in one reader's own format is stuck in a different way. It may not depend on pixels, but it depends on that reader: another reader has no reason to understand a private format, so the bookmark cannot be carried across. Two readers, two private systems, and a position saved in one is meaningless in the other.

Taking a CFI Apart

What travels is an address that belongs to neither reader. CFI — Canonical Fragment Identifier — is the EPUB standard's answer: an address that describes the text itself, in a form any reader that implements the standard can read. Which chapter, which paragraph inside that chapter, and how many characters into that paragraph. One such address reads epubcfi(/6/4[chap01ref]!/4/10/3:10).

Read it left to right. The epubcfi(...) wrapper says what kind of string this is. The ! splits it in two: the part before it locates the chapter inside the book, and the part after it walks down that chapter's document tree, one child at a time, until it reaches a text node. Each number steps to a child; [chap01ref] is an identifier assertion, a name the chapter is expected to carry, so the address can check it is in the right place rather than trusting the count alone. At the end, :10 means ten characters into the text node. Font size, window width, and margins never enter the string, so changing any of them leaves the address untouched. The same sentence keeps the same address wherever it is opened, and that is the whole trick: count structure, not pixels.

A Point and a Range, Written the Same Way Every Time

Two shapes cover the two jobs a reader actually does. A single point marks a reading position — the place to resume. A range marks a selection — a highlight or a note spanning from a start point to an end point. A range carries three paths instead of one: a shared path to the common container, then a start path and an end path, so both ends stay anchored in the same chapter context instead of drifting apart when the document is re-rendered.

A string that is only written once is not yet portable. It has to be written the same way every time, by every reader, or two copies of the same location will not match. That is why serializing is a canonical step: the same location always comes out as the same string. And the canonical step does real work — identifiers generated only for one rendering session, such as temporary line-number markers, are stripped on output, so an address recorded in one reader does not come back looking different in another. What travels is the address, not a snapshot of screen state: nothing about the first reader's font, window, or scroll position needs to travel, because nothing about them was ever stored.

Open It in Another Reader

Here is where the standard earns its keep. Stop at a sentence in one reader, and the position can be written out as a CFI string. Open the same book file in a different reader — one that honors CFI — hand it the string, and it lands on the same sentence. No conversion, no vendor's permission, no re-finding the passage by searching for a phrase and hoping it is the only match. The address works in the second reader for the same reason it worked in the first: both readers read the same standard, and the address describes the book, not the software. That is what makes it one address instead of two private bookmarks that happen to point at the same sentence. The same mechanism carries the rest: a highlight is a range, so its anchor travels the same way, and so does a note or a bookmark. (Syncing within a single system can use the same address, of course — but any vendor's private bookmark can do that, and that was never the hard part.)

Conditions and Limits

Two conditions, stated plainly, because the claim is only as good as they are. First, it has to be the same book file: the address counts structure, so a different edition with different chaptering will not line up. Second, the other reader has to honor CFI. A reader that does not know the standard cannot do anything with the string, and no standard fixes a reader that ignores it. The unity is real, but it is conditional on both sides reading the same standard.

There is one change this address does not survive, and it is worth stating plainly: if the chapter text itself is edited, the structure the address counts may no longer be there. That is why the terminal offset can carry a text assertion — the words immediately before and after the offset, stored alongside it. On arrival, the reader can check that the surrounding words still match. Layout changes need no such check, because layout was never part of the address; content changes get a tripwire, because content is everything the address is made of. And CFI is the EPUB mechanism: other formats have their own addresses, and this one does not pretend to cover them.

The address belongs to the book, so a position written in it can travel.