Read a PDF where it is imported, and keep the text with the file

A PDF was searchable on a device once that device had opened it, because
the extracted text lived in that browser's IndexedDB and nowhere else. So
a document imported on the desktop was invisible to a search on the
phone — which is exactly the case that matters for filing invoices, since
those are imported and then never opened again.

The reading still never happens on the server. It has no PDF library and
is not getting one: the bytes arrive encrypted and are stored that way.
The device that imports the file reads it there and then, and the result
is stored beside the file in attachments.text_index, encrypted at rest
like everything else and opaque to the server. Every other device asks
for it after login and can then find a document it has never downloaded.

Not storing it was the earlier decision, on the reasoning that text
derivable from bytes the server already holds should not be kept twice.
True, and useless. A few hundred kilobytes against a file measured in
megabytes is a trade worth making.

A `null` answer is not an error — it means nobody has read this file yet.
Documents extracted before this existed are sent up the next time they
are opened.

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

readme.md

@@ -333,14 +333,14 @@ docker compose -f docker-compose.dev.yml up -d --build   # must be running
 | `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 |
+| `drawing` | 18 | strokes survive the poller, match across four viewport widths, and stay on the page they were drawn on |
 | `pdf` | 91 | import, page proportions, lazy loading, and reading with the network off |
 | `attachments-lifecycle` | 10 | a picture is kept while any version shows it, and freed once none does |
 | `conflict` | 10 | a late write wins but the state it buries survives as a version |
 | `export` | 21 | the downloaded bytes are real Markdown, ZIP and PNG, unpacked and read back |
 | `organise` | 39 | a hand-made order survives a search; separators hold their place; a note exported and imported comes back whole |
 | `offline` | 12 | a cold page load with the network off still opens notes and searches them |
-| `sync` | 5 | a PDF written on one device — document, drawing and pinned notes — reaches a second one |
+| `sync` | 7 | a PDF written on one device — document, drawing and pinned notes — reaches a second one, which can find it by its contents without opening it |
 
 Each suite creates a throwaway account through the admin API and deletes it
 afterwards, so runs leave the database as they found it. They need an admin to
@@ -399,8 +399,8 @@ and a test asserts none ever reaches the stored body. The current page is the on
 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.
+Each page can be drawn on — see [One drawing, as many pages as the
+note](#one-drawing-as-many-pages-as-the-note).
 
 ### Alignment
 
@@ -473,6 +473,11 @@ fresh device with nothing to search. After login a background pass backfills the
 missing ones into IndexedDB, slowly enough to stay out of the way, indexing each
 as it lands. Searching therefore also works offline.
 
+PDFs come after the notes in that pass. Their text is not derived from a note
+body but stored with the file, by the device that imported it — see [The reading
+happens on a device, never on the
+server](#the-reading-happens-on-a-device-never-on-the-server).
+
 Matching is AND across terms, case- and diacritic-insensitive (`kuhlschrank`
 finds *Kühlschrank*), with title matches ranked above body matches. Results show
 a snippet around the first match.
@@ -581,11 +586,34 @@ one search box finds a sentence whether it was typed or imported. Extraction run
 *after* the document is on screen and yields between pages: it must never stand
 between the reader and the first page.
 
-**The extracted text is not sent to the server.** It is derivable from a file the
-server already holds, so storing it again would cost space and a second thing to
-encrypt for nothing gained. The price is that a PDF becomes searchable on a
-device once that device has opened it — the same shape as the limitation notes
-already have, and the honest trade for not duplicating data.
+### The reading happens on a device, never on the server
+
+The server has no PDF library and no way to open one: the bytes arrive encrypted
+and are stored that way. **The device that imports the file reads it**, at import
+rather than at first open, and the result is stored beside the file in
+`attachments.text_index` — encrypted at rest like everything else, and opaque to
+the server.
+
+That is what lets a device search a document it has never opened. It is the
+precondition for filing scanned invoices: they are imported, and then never
+opened again, so waiting for someone to open one would mean waiting forever.
+
+```
+PUT  /api/attachments/:id/text   { "pages": ["page one text", "page two text"] }
+GET  /api/attachments/:id/text → { "pages": [...] }  or  { "pages": null }
+```
+
+`null` is not an error — it means nobody has read this file yet, and whichever
+device holds the bytes should. After login the search backfill asks for the text
+of every PDF the account holds, after the note bodies, and skips the ones nobody
+has read: downloading every document just to index it is not a thing to do in the
+background.
+
+This was deliberately *not* stored for a while, on the reasoning that text
+derivable from bytes the server already has should not be kept twice. True, and
+useless: a PDF imported on the desktop was invisible to a search on the phone
+until the phone had opened it. A few hundred kilobytes of text against a file
+measured in megabytes is a trade worth making.
 
 The minimal text-layer CSS is written out in `textLayer.css` rather than
 importing `pdfjs-dist/web/pdf_viewer.css`, which carries the whole reference
@@ -993,6 +1021,41 @@ encrypted at rest like note content.
 Notes drawn before this format still carry a PNG in `drawing_data_path`; it renders
 underneath any newer strokes so nothing is lost.
 
+### One drawing, as many pages as the note
+
+A note used to have exactly one sheet to draw on, which stopped making sense once
+the writing could run to four pages: the ink was stuck on the first one while the
+text carried on without it. Every page is exported anyway, so every page can be
+drawn on. Pages are numbered the way the PDF reader numbers them:
+
+```json
+{ "v": 2, "w": 1200, "h": 1600, "sheets": {
+  "1": [ { "t": "pen", "c": "#e94560", "s": 5.5, "p": [100,100, 200,180] } ],
+  "3": [ { "t": "highlighter", "c": "#f5c518", "s": 27, "p": [80,900, 900,910] } ]
+}}
+```
+
+A page nobody has drawn on is not stored, so the keys *are* the drawn pages.
+
+**A drawing that lives entirely on page one is still written in the old shape**,
+with a plain `strokes` list and no `sheets` at all. Nothing requires that — it
+means an ordinary note's drawing is stored exactly as it always was, and a device
+running an older build still shows it.
+
+While drawing there is always one blank page past the end. Pages otherwise come
+from how far the writing runs, which would leave a drawing with nowhere to go: to
+draw on page three you would first have to write three pages. Drawing on the
+spare page makes it a real one, and the page count in the toolbar counts it.
+
+The bin clears **the page being looked at**, not the whole drawing. Undo and redo
+work on the drawing as a whole, because one Undo button that means four different
+things depending on where you scrolled is not a button anyone can use.
+
+In an export, page one keeps the name a drawing has always had —
+`drawings/<note>.png`, or `<note>-drawing.png` beside a single note — and the
+rest are numbered after it. A drawing of several pages exported on its own comes
+out as a ZIP rather than as its first page alone.
+
 ---
 
 ## Conflict Resolution