Topic analysis

Silurus/ooxml: Pixel-faithful Office documents, rendered in the browser

This entire codebase — Rust parsers, TypeScript renderers, tests, and tooling — was implemented by Claude (Anthropic's AI assistant) through iterative prompting. No human-written application code exists in this repository. A browser-based viewer for Office Open XML documents that renders to an HTML Canvas element. The parsers are written in Rust and compiled to WebAssembly; the renderers use the Canvas 2D API. Each format also exposes a headless engine ( DocxDocument / XlsxWorkbook / PptxPresentation ) that renders into any caller-supplied canvas, so you can compose your own UI — scroll views, thumbnail grids, master-detail panes — instead of being locked into the built-in viewer. See the Examples section in the Storybook demo . Bundler note : this package embeds .wasm files. With Vite add vite-plugin-wasm ; with webpack use experiments.asyncWebAssembly . Bundle size note : the package is ESM-only ( .mjs ). npm's Unpacked Size sums all four entry bundles, including the opt-in math engine (MathJax + STIX Two Math, ~3 MB). What actually lands in your app is much smaller — import only the format you need (e.g. @silurus/ooxml/pptx ). The math engine is a separate entry ( @silurus/ooxml/math ): it is bundled only if you import it and pass it to a viewer (see Rendering equations ). Viewers that never receive a math engine — and all xlsx usage — tree-shake the ~3 MB away entirely. OMML equations ( m:oMath / m:oMathPara ) in .docx / .pptx are rendered with MathJax + STIX Two Math . That engine is ~3 MB, so it is opt-in : import the math engine from the separate @silurus/ooxml/math entry and pass it to the viewer. Pass it and equations render; omit it and the engine is referenced nowhere, so a bundler tree-shakes the ~3 MB away entirely (equations are simply skipped). It is fully self-contained: no network, no cross-origin requests. The same math engine works for PptxViewer and the headless DocxDocument / PptxPresentation APIs (which take math in their options). xlsx has no equation support and never references the engine. All three formats follow the same shape: the worker parses the .docx / .xlsx / .pptx archive via WASM and posts a JSON model back to the main thread, where the renderer draws to the canvas. Rendering stays on the main thread so the canvas shares the document's FontFaceSet — an OffscreenCanvas in a worker has its own font registry and would silently fall back to a system font, producing subtly different text measurements (and wrap positions) from the installed theme webfonts. @silurus/ooxml-core holds the cross-format primitives that the three renderers all depend on: a unified chart renderer (bar / line / area / radar / waterfall), shape helpers ( resolveFill , applyStroke , buildCustomPath , hexToRgba ), the autoResize viewer utility, and the shared type definitions. Add "allowSyntheticDefaultImports": true and configure @angular-builders/custom-webpack (or use esbuild builder) with WASM support in your Angular workspace. A note on text selection. Across DOCX / PPTX / XLSX, text selection is currently implemented by rendering glyphs to the canvas while overlaying a transparent DOM layer that mirrors the canvas text positions for native browser selection. This dual-layer approach is a deliberate stop-gap: once the Canvas drawElement API (proposed in WICG/html-in-canvas , currently in Chromium Origin Trial) ships across browsers, the project plans to migrate to a single DOM-as-source-of-truth pipeline where the canvas mirrors the DOM directly — eliminating the duplication while keeping z-order correctness and native selection / a11y.