Files
ranger ab8d007b72 feat: ORP anchor on the middle word in Sentence mode (v1.1.3)
David proposed: "for sentence we can add in the red letter to keep
the eye in the middle of the sentence block."

Sentence mode now picks the middle word of each sentence (by word
index) and applies the same ORP-character formula used in Word mode.
The single red letter gives the eye a fixed anchor; the rest of
the sentence is absorbed peripherally instead of saccading.

This matters most at high WPM (post v1.1.1/v1.1.2 — Sentence mode
now goes up to 3000 WPM with a 400ms minimum-display floor). Without
an anchor, the eye scans from the left as if reading normally and
runs out of time. With the anchor, the eye fixates immediately and
the whole sentence registers in one peripheral-vision read.

Paragraph mode still renders plain text — a single ORP on a
multi-line block doesn't give a useful fixation point. Per-sentence
ORP within paragraphs could come in a future release if needed.
2026-05-27 02:50:01 +01:00

124 lines
7.1 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# Changelog
All notable changes to **Ranger Reader** are documented here.
Format: [Keep a Changelog 1.1.0](https://keepachangelog.com/en/1.1.0/) — versioning: [SemVer](https://semver.org/).
---
## [Unreleased]
---
## [1.1.3] — 2026-05-27
### Added — ORP anchor in Sentence mode
Sentence mode now displays one red letter near the middle of each sentence — same ORP (Optimal Recognition Point) treatment used in Word mode, scaled up to sentence size. The eye fixates on the red character and processes the rest of the sentence peripherally instead of saccading across the line.
The anchor is calculated by finding the **middle word of the sentence** (by word index, not character index — keeps the anchor word-aligned), then applying the standard ORP-character formula to that word:
| Word length | ORP position (0-indexed) |
|---|---|
| 1 character | char 0 |
| 2-4 characters | char 1 |
| 5-9 characters | char 2 |
| 10-13 characters | char 3 |
| 14+ characters | char 4 |
For a 9-word sentence, the middle word is index 4. If that word is "evaluation" (10 chars), the ORP character is `l` (`eva*l*uation`) — that's the red letter on screen.
### Why this helps high-WPM Sentence mode
At 3000 WPM with the v1.1.2 lower floors, sentences flash by in 400-800 ms. Without an eye anchor, the eye starts scanning from the left as if reading normally, and runs out of time before the sentence advances. With the red ORP letter near the middle, the eye fixates on the anchor immediately and absorbs the sentence in a single peripheral-vision read. This is what makes high-WPM RSVP comprehensible rather than just fast.
### Paragraph mode
Paragraph mode still renders plain text without an ORP anchor. A single anchor character on a multi-line block doesn't give the eye a useful fixation point (it still needs to saccade between lines). Per-sentence ORP within paragraphs could be added in a future version if the use case emerges.
---
## [1.1.2] — 2026-05-27
### Fixed — High WPM in Sentence / Paragraph modes was clamped by a too-conservative minimum-display floor
After v1.1.1 raised the WPM cap to 3000 in Sentence and Paragraph modes, David noticed that pushing the slider from 1500 to 3000 didn't actually speed up reading — the chunks were still sitting on screen for the same amount of time.
Root cause: the v1.1.0 minimum-display floor was **1500 ms per chunk** (set conservatively to prevent flash-frame illegibility). At 3000 WPM, any sentence under ~60 words mathematically wants to display for under 1500 ms — but the floor clamped them all to 1500 ms, so the calculated speed-up never reached the user.
Lowered floors:
- **Sentence mode**: 1500 ms → **400 ms** (eye can absorb a short sentence in well under half a second once it's on screen)
- **Paragraph mode**: 1500 ms → **800 ms** (paragraphs are denser; need slightly more time even at high WPM)
Maximum cap stays at 12 s for very long paragraphs at very low WPM.
At 3000 WPM with the new floors, a 20-word sentence displays for **500 ms** (was 1500 ms — 3× faster) and a 60-word paragraph displays for **1750 ms** (was 1500 ms — uncapped formula now visible).
This makes the WPM slider actually behave the way users expect: higher WPM = faster reading, all the way up to 3000.
### Clarification
The reader does NOT iterate word-by-word inside a chunk in Sentence or Paragraph modes. The whole sentence or paragraph is rendered in one DOM update; only the auto-advance interval is calculated from word count. The word count is used as a proxy for "how long does a reader need to absorb this chunk," not as a per-word display loop.
---
## [1.1.1] — 2026-05-27
### Changed — Mode-aware WPM ceiling
The WPM slider's maximum value now adapts to the active reading mode:
- **Word** mode: 1500 WPM ceiling (human single-word recognition limit — beyond ~25 ms per word the brain stops registering individual words)
- **Sentence** and **Paragraph** modes: 3000 WPM ceiling. In chunk modes the "WPM" controls auto-advance timing across larger display units, so higher values still produce comprehensible reading speeds (a 20-word sentence at 3000 WPM still gets ~400 ms of display time, which is well within visual-recognition comfort)
Switching from a high-WPM chunk mode back to Word mode automatically clamps the current value down to 1500, preventing accidentally-illegible word-mode playback.
The `+` keyboard shortcut now respects the mode-specific ceiling.
### Why this matters
For skim-pass reading on long thesis papers, the previous 1500 WPM cap in Sentence mode was too conservative. With a 20-word sentence at 1500 WPM the display held each sentence for ~1 s — comfortable but slower than necessary for already-known territory. 3000 WPM cuts that to ~400 ms, suitable for the Preview / Postview phases of structured reading (preview chapters, scan for known concepts, identify sections that warrant a slower second-pass read).
---
## [1.1.0] — 2026-05-27
### Added — Sentence and Paragraph reading modes
The single-word RSVP display from v1.0 is now one of three modes selectable via the toggle in the header (or keyboard `1` / `2` / `3`):
- **Word** (`1`) — original RSVP, one word at a time with ORP focal-character coloring
- **Sentence** (`2`) — one full sentence at a time, auto-advancing on `(words / WPM) × 1.25` interval, clamped to 1.512 s per chunk
- **Paragraph** (`3`) — one paragraph at a time, larger reading area, `(words / WPM) × 1.40` interval
The sentence splitter handles common academic-text false positives — titles (`Mr.`, `Dr.`, `Prof.`), Latin (`e.g.`, `i.e.`, `et al.`), abbreviations (`Vol.`, `Fig.`, `Eq.`, `Ref.`), and decimal numbers — by guarding them before splitting on `.!?` followed by whitespace and capital letter.
Paragraph splitting is on blank-line separation (the conventional output of `pdftotext`).
Other v1.1 polish:
- Stage centre guide-lines hidden in Sentence / Paragraph modes (single-word framing isn't needed)
- Skip-distance adapts per mode: ± 10 in Word mode, ± 1 in chunk modes
- Meta text adapts to mode: `N / total words` / `sentences` / `paragraphs`
- Time-remaining always computed in raw words regardless of mode (so 500 WPM means 500 WPM everywhere)
- Mode is persisted alongside text + WPM + position in `localStorage`
- v1.1 version stamp visible in header
---
## [1.0.0] — 2026-05-27
Initial release.
### Added
- Single-word RSVP display with WPM slider (2001500, default 500)
- ORP (Optimal Recognition Point) focal-character coloring in red
- Punctuation-aware pause: 2.5× for period/exclamation/question, 1.7× for comma/semicolon/colon, 1.3× for closing brackets
- Progress bar + meta (`N / total words · ~X min remaining at Y WPM`)
- Keyboard shortcuts (`Space`, `←`/`→`, `+`/``, `R`)
- Drag-and-drop `.txt` file loading anywhere on the page
- `localStorage` persistence — text, WPM and position survive page reloads
- Dark-mode WP-tone palette (accessible-contrast colour scheme)
- "Done" state turns the display green when the paper finishes
Single self-contained HTML file. No dependencies, no install, no network calls. Runs in any modern browser, fully offline.