pskumaresh06/wasmtex-playground

Purpose and Entry Points

WASMTeX Playground is a browser-hosted LaTeX editor/compiler with PDF preview. The primary client entry is index.html, using the JavaScript compiler wrapper in PdfTeXEngine.js. Deployment starts through docker-compose.yml, which serves static browser assets and a separate TeXLive compilation service.

Browser Editor and Compile Orchestration

index.html owns the interactive UI: source editing, project/image upload, compile actions, console output, PDF preview/download, and default-asset status. It passes LaTeX source and uploaded files into the compiler-facing JavaScript layer.

• index.html

• PdfTeXEngine.js

In-Browser PdfTeX Runtime

The browser path uses a PdfTeX engine compiled to WebAssembly. The wrapper exposes compiler lifecycle and its in-memory filesystem to the UI; compilation consumes .tex plus assets and emits PDF bytes and logs. This is the key browser/runtime boundary: no browser filesystem access is assumed, so source, uploads, and bundled assets must be materialized in the engine’s virtual filesystem.

• PdfTeXEngine.js

• wasm-builder/pdftex.wasm/PdfTeXEngine.js

• wasm-builder/pdftex.wasm/library.js

Default Asset Layer

A repository-provided TeX asset corpus supplies document classes, packages, format files, fonts, maps, and graphics support. The client is designed to load these resources into compiler memory, allowing documents to resolve \usepackage, classes, and included resources without user upload. The asset boundary is filename/package resolution inside PdfTeX rather than application-level APIs.

• default-assets/

• default-assets/neopdftex.fmt

• default-assets/article.cls

Containerized Server Compilation

Docker Compose also provisions texlive-ondemand, a Python/Wsgi service on port 5002, alongside a static server on port 8002. This creates a second compilation boundary: browser UI/static delivery versus server-side TeXLive compilation. The service includes a precompiled format and custom kpathsea/PdfTeX integration for locating TeX resources.

• docker-compose.yml

• texlive-ondemand/app.py

• texlive-ondemand/wsgi.py

Native/Server PdfTeX Resource Resolution

The server compiler service is built around Python plus a native pykpathsea_pdftex implementation/setup, with a packaged neopdftex.fmt. It is responsible for invoking/configuring the TeX runtime and resolving TeX inputs in the service environment.

• texlive-ondemand/kpathsea_pdftex_setup.py

• texlive-ondemand/pykpathsea_pdftex.c

• texlive-ondemand/neopdftex.fmt

WASM Build Pipeline and Engine Sources

wasm-builder/pdftex.wasm contains the Emscripten build target, generated/runtime glue, PdfTeX sources, and embedded PDF-processing dependencies. Its Makefile produces the WebAssembly engine consumed by the frontend; rebuilding requires Emscripten SDK 3.1.46 per the README. Core engine execution enters through C glue and PdfTeX’s TeX implementation.

• wasm-builder/pdftex.wasm/Makefile

• wasm-builder/pdftex.wasm/main.c

• wasm-builder/pdftex.wasm/tex/pdftex0.c

Primary Flow

User edits/uploads → index.html selects a main .tex and gathers assets → default and user files are written to the compiler virtual filesystem → PdfTeX compiles against format/package resources → PDF bytes render in the preview and become downloadable; logs/errors return to the console UI. Docker adds static delivery and an optional/separate TeXLive-backed compiler endpoint, but the central product capability is the WebAssembly PdfTeX path.