Release

Liteleaf 0.8-r23 speeds up compilation, saving, and PDF loading

From email configuration to compatible PDF loading, versions 0.8-r20 through 0.8-r23 reduce waiting and make Liteleaf operations more observable.

Liteleaf 0.8-r23 concludes a cycle of improvements aimed at reducing the wait between saving, compiling, and reviewing a document. Since 0.8-r19, the work has also expanded administrative configuration, compiler observability, and PDF viewer compatibility while preserving existing deployment behavior.

Version 0.8-r20 added a dedicated Email area to Administration. It allows the public URL, sender identity, and SMTP username to be configured and applied immediately without restarting Liteleaf. The same effective URL is now used for password recovery, registration, invitations, email confirmation, and tests. The SMTP endpoint, port, and password remain exclusively in the environment, and administrative values can return to inheriting it at any time. The editor bar also reveals the full content of truncated notices when hovered or reached with the keyboard.

Version 0.8-r21 brought the largest compilation changes. Safe auxiliary LaTeX artifacts can now be reused per project, while latexmk coordinates indexes and glossaries without a redundant external pass. Normal compilations of the same revision, engine, and root document become idempotent; “Clean and compile” continues to perform a complete rebuild when one is needed.

The optimization comes with visible measurements. Status and /metrics separate preparation from execution, record cache hits, and expose compilation counters. Prometheus and Grafana can be enabled through docker-compose.full.yml, with a provisioned dashboard and alerts, without adding services to the basic Compose or standalone profiles. When this option is used, CLI backups can also include and verify the Grafana database in the new bundle format.

The viewer now identifies each PDF by its artifact, uses ETag, and loads pages on demand. The result therefore refreshes after compilation without losing the currently visible position. In 0.8-r22, this flow gained broader compatibility: current browsers continue to receive the modern PDF.js build, while browsers without recent JavaScript features silently select the official legacy build. The library and worker stay paired at versioned local URLs, and failures are shown as localized messages instead of internal library details.

Finally, 0.8-r23 also reduces the time around compilation. The relay wakes immediately after the outbox commit, reducing pre-LaTeX latency, while status distinguishes dispatch time from time spent waiting for a worker. Ctrl+S responds immediately, coalesces repeated manual saves, and replaces polling with event-driven collaborative confirmation, including automatic resynchronization when needed.

The editor complements these changes with a cleaner header: the compact, monochrome logo is integrated into the Menu and followed by an independent home button. Rename actions appear only on the tree row under hover or focus, and LaTeX and BibTeX comments receive blue highlighting in both light and dark themes. Together, versions 0.8-r20 through 0.8-r23 make the path from a confirmed edit to the new PDF on screen shorter and more transparent.

← Back to the blog