# Live PDF R6 — Instant Browser Rendering Date: 2026-08-28 ## Objective Make eligible LaTeX prose edits appear in the PDF pane immediately, using the TeXpile live-preview architecture as a reference, without replacing or weakening TeXise's existing exact Live PDF (R5), manual Compile, SyncTeX, PDF export, collaboration, AI, Visual editor, storage or cloud fallback behavior. ## Architecture R6 is an optional, disposable accelerator layered over R5: 1. A successful browser R5 compile produces the exact PDF, SyncTeX map and canonical source baseline. 2. TeXise opportunistically pre-warms a **separate** BusyTeX/LuaLaTeX worker for R6. 3. A canonical source mutation is classified conservatively. 4. Eligible edits are restricted initially to one plain top-level body paragraph, one `.tex`/`.ltx` file, one exact source edit, and Source/Visual prose origins. 5. R6 compiles only that paragraph in a transient in-memory LuaLaTeX wrapper. Bibliography/index/rerun passes are explicitly disabled. 6. The last exact R5 SyncTeX generation anchors the paragraph to one proved page/column region. 7. PDF.js renders the tiny R6 PDF to a transient overlay canvas over the exact PDF page. Engine glyph scale is preserved; the overlay is never a project PDF. 8. The existing R5 debounce still runs. When the new exact PDF + same-generation SyncTeX map is accepted by `ProjectPdfService`, the R6 overlay disappears atomically. The authoritative path therefore remains: `canonical source → exact R5/full compile → PDF + SyncTeX → ProjectPdfService` R6 is only: `eligible edit → tiny local LuaLaTeX block compile → disposable overlay` ## Browser implementation versus TeXpile TeXpile Desktop can keep a native LuaLaTeX process alive and drive it through a daemon/stdin protocol. TeXise runs in a browser, and the current BusyTeX public browser API does not expose that persistent stdin-driven TeX process. R6 therefore uses the safe browser equivalent available in this codebase: a dedicated warm BusyTeX worker plus a tiny block-only LuaLaTeX compile. This removes the full-project compile from the keystroke-to-preview path while retaining exact R5 reconciliation. It does **not** claim that the browser implementation is a native TeXpile daemon. ## Fail-closed eligibility R6 phase 1 accepts only edits for which it can prove all of the following: - Live PDF is enabled, R4-certified and using the browser BusyTeX backend. - The displayed `ProjectPdfService` generation exactly matches the stored R5 baseline generation. - Exactly one source file is dirty relative to that baseline. - The source mutation has exactly one explicit edit and originates from Source or ordinary Visual prose. - Preamble and document tail are byte-identical to the exact baseline. - Exactly one body paragraph changed and all bytes outside it are unchanged. - Old and new paragraph text are plain prose without LaTeX commands, braces, math or special structural tokens. - The paragraph is not inside an active LaTeX environment. - Exact SyncTeX mappings prove one page target, a usable column width, and the baseline rendered line count. - The transient LuaLaTeX block must render the same number of line bands as the exact R5 paragraph; if reflow would add/remove lines, R6 does not paint because doing so would require shifting subsequent page content. - The source revision is still current when the block render completes. Any failed condition discards/skips the overlay and leaves exact R5 reconciliation active. ## Non-breaking guarantees - `ProjectCompileService` remains independent and unchanged as the manual compile authority. - R4 feasibility certification remains required before browser Live PDF. - R5 still compiles canonical project snapshots and remains the exact Live PDF authority. - R6 uses a separate compiler worker so R5 cancellation/supersession cannot destroy R6 state and vice versa. - R6 source wrappers are transient `__texise_live_instant__*.tex` files passed only to the in-memory compiler; no user file is modified or persisted. - PDF export/download and Free-plan watermarking continue to use `ProjectPdfService`'s exact PDF only. - The existing selectable PDF.js text layer remains above the transient overlay. - SyncTeX remains based on the last exact accepted generation. R6 does not invent temporary source mappings. - R6 never fakes page reflow: a line-count change fails closed to exact R5 rather than temporarily covering or misplacing following content. - Cloud-sticky/fallback Live PDF remains exact R5/cloud behavior; R6 is browser-local only. - AI, Review, MathLive, collaboration and structural/programmatic origins fail closed to R5 in phase 1. - Git, autosave, history and project files never receive R6 helper content. ## Key implementation files - `packages/core/service-core/src/project-live-instant.ts` - `packages/core/service-core/src/project-live-draft-service.ts` - `packages/platform/latex-compiler-browser/src/busytex-live-lua-compiler.ts` - `packages/platform/latex-compiler-browser/src/busytex-adapter.ts` - `packages/js-lib/latex-compiler/src/types.ts` - `packages/core/app/src/components/pdf-preview-pane.tsx` - `packages/core/app/src/pages/page-editor.tsx` ## Regression coverage - Pure classifier/SyncTeX targeting unit coverage in `project-live-instant.spec.ts`. - Service-level early-paint versus 800 ms exact reconciliation coverage in `project-live-draft-service.spec.ts`. - Separate warm worker/block-only compiler coverage in `busytex-live-lua-compiler-r4.spec.ts`. - Chromium release E2E added to the existing `latex-live-pdf-r5.e2e.ts` suite. - Dependency-free release regression: `scripts/bf50-live-pdf-r6-regression.test.mjs`. - R6 invariants are also included in `scripts/release-runtime-hardening.test.mjs`, `scripts/texise-release-audit.mjs`, and the BF50 source guard. ## Current limitations / next expansion gates R6 intentionally does not yet instant-patch math, lists, environments, floats, tables, figures, citations, bibliography changes, structural Visual changes, collaboration-origin edits, AI/review edits, multi-file simultaneous changes, or paragraphs already spanning pages. These all continue to receive the existing exact R5 behavior. The next safe expansion order is headings → list items → inline math → display math → simple environments → multi-file body text → certified Visual structures. Each class should be added only after overlay-versus-reconciled-PDF geometry tests show acceptable fidelity. A native persistent LuaTeX command loop would require a lower-level BusyTeX/WASM API that the current browser runtime does not provide. If that capability is added later, it can replace the tiny-document R6 backend behind the same service contract without changing R5 or the UI reconciliation model.