Set the note left, count its pages, choose its typeface, align its text

The column sat in the middle, so it moved as the window was resized and the
start of every line landed somewhere new. It is against the margin now.

The toolbar counts pages in the words the PDF reader uses, with a hairline where
each ends. Pages are drawn, never stored: the note stays one document, Markdown
has no page, and a check asserts none reaches the stored body. The current page
is the one under the middle of the window — measuring from the top claimed "page
1" while you stood at the foot of a two-page note, because a window is shorter
than a page.

The typeface is a per-account setting rather than a per-browser one, because a
choice about how your own notes are set should follow you to the phone. The
server takes serif, sans or mono and drops anything else; that column is written
by a browser, so it is an input like any other.

Alignment is a small extension of our own — one attribute, a parse rule, a render
rule — so the schema every stored note is validated against stays in files this
project owns. Markdown has no alignment: what CommonMark allows is embedded HTML,
so non-left blocks travel as `<div align="…">`, the one form most readers still
honour, and the importer puts it back on the paragraphs. Left is never written.

The full run caught a crash I had put in: PdfWorkspace used `noteFont` without
taking it as a prop, which the build cannot see and the type checker does not
reach in .jsx. It killed the notes panel beside a PDF, and `offline` failed with
it because the whole app was broken.

224 unit tests, 263 browser checks across twelve suites.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

readme.md

@@ -328,7 +328,7 @@ docker compose -f docker-compose.dev.yml up -d --build   # must be running
 | Suite | Checks | What it holds down |
 | --- | --- | --- |
 | `admin` | 15 | no sign-up anywhere; `/api/admin/*` refused for non-admins even when called directly |
-| `editor` | 17 | tables and their right-click menu, task lists, note links, backlinks — and that each survives a reload |
+| `editor` | 31 | tables and their right-click menu, task lists, note links, backlinks — and that each survives a reload |
 | `search-attachments` | 12 | body-only matches, ranking, umlauts; images as blob URLs, not inline bytes |
 | `history` | 10 | a large deletion is snapshotted, restoring works, restoring is itself undoable |
 | `drawing` | 7 | strokes survive the poller, and match across four viewport widths |
@@ -369,6 +369,44 @@ state of their own, so they can be read on their own.
 
 ---
 
+## Setting a note
+
+**Left-aligned, with the column against the margin.** A column that floats in the
+middle moves as the window is resized, so the start of every line lands somewhere
+new; against the margin it is always in the same place. About 73 characters to
+the line — measured, not guessed.
+
+**The typeface is a per-account setting** (Account → Profile): serif, sans or
+mono. On the account rather than in the browser, because a choice about how your
+own notes are set should follow you to the phone rather than be made again on
+every device. The server accepts those three values and drops anything else —
+that column is written by a browser, so it is an input like any other.
+
+**Pages are counted, not stored.** The toolbar says *Page 2 of 4* in the same
+words the PDF reader uses, and a hairline marks where each one ends. A page is
+the same 3:4 the canvas uses, so "page 2" means the same thing writing or
+drawing. The note itself stays one continuous document — Markdown has no page,
+and a test asserts none ever reaches the stored body. The current page is the one
+under the *middle* of the window: measuring from the top said "page 1" while you
+stood at the foot of a two-page note, because a window is shorter than a page.
+
+The drawing still covers only the first page. On a PDF the strokes are kept per
+page; on a note there is one sheet.
+
+### Alignment
+
+Markdown is often said to "basically be HTML". It is not — it allows *embedded*
+HTML, and has no alignment of its own. So alignment works fully in the app, in
+print and in the PDF, and in a `.md` file it can only travel as a tag:
+
+- Non-left blocks are wrapped in `<div align="…">`, the one form GitHub and most
+  other readers still honour. A reader that does not know it shows the text,
+  which is the right way to fail.
+- Left is never written. It is the default, and wrapping every paragraph in a div
+  would turn an ordinary note into markup for nothing.
+- The importer reads the wrapper back and puts the alignment **on the
+  paragraphs**, which is where the editor keeps it — not on a container.
+
 ## Interface language
 
 English throughout. It had drifted into two languages — the frame in English,