zenfmt 0.3.5

zenfmt 0.3.5

zenfmt 0.3.5 adds two distribution paths for the existing conversion engine.
The CLI, server, Python API, browser API, supported formats, and converted
output remain compatible with 0.3.3.

WebAssembly on npm

• The dependency-free browser distribution is now published as
  @insanai/zenfmt.
• The package contains the audited WebAssembly module, ES module adapter,
  dedicated worker, TypeScript declarations, and generated capability
  contract.
• npm publication consumes the same browser artifact that passed the release
  audit and conversion smoke test. It does not rebuild the engine.
• The package does not upload documents or add a remote conversion fallback.

Homebrew

• A self-contained Homebrew tap layout now lives under
  packaging/homebrew/ so it can move to a dedicated repository later.
• The cask selects Apple Silicon or Intel and downloads that CLI plus server
  archive directly from the tagged GitHub release.
• Homebrew does not build zenfmt and does not install Java, Python, Node, OCR,
  VLM, or model files.

Release automation

• The protected GitHub Pages environment now permits version tags matching
  v*, while main remains the only permitted branch.
• Main and tagged Pages deployments share one production concurrency group so
  two release paths do not deploy at the same time.
• PyPI continues to use the repository PYPI_API_TOKEN. npm publication uses
  the separate NPM_API_TOKEN; neither credential is available to build or
  Pages jobs.

Performance

This release changes packaging, documentation, and release automation. It does
not change the conversion engine or server runtime. The published benchmark
therefore remains the 0.3.3 reference run from the same engine code. Those
numbers describe one modest machine and the fixed corpus, not every document
or environment.

Upgrade

Replace the earlier executable with 0.3.5 and restart a running service. The
server configuration and data format remain compatible. Web applications may
install @insanai/zenfmt@0.3.5; macOS users may install the repository cask.

zenfmt 0.3.3

zenfmt 0.3.3

zenfmt 0.3.3 is a documentation and public site release. The conversion engine,
server API, secure storage, and converted output remain compatible with 0.3.2.

Multilingual documentation

• The README and practical zenfmt book are now available in English,
  Simplified Chinese, Japanese, and Korean.
• The translated books cover the first conversion, formats, loss reporting,
  command line use, Python, WebAssembly, server operation, security limits, and
  benchmark interpretation.
• Technical identifiers remain searchable in English where that is common in
  the language. ZDS records remain in English because they preserve the design
  history.
• Release assets now include a PDF book for each supported documentation
  language. Individual ZDS PDFs remain on GitHub Pages and are not duplicated
  in the release.

Public site

• A visible language selector is available throughout the site.
• The first visit to the converter follows the browser language when a matching
  translation exists. An explicit selection is remembered and takes priority.
• The converter, download, benchmark, security, navigation, search, status, and
  error text are localized.
• The translated HTML books carry their document language and localized
  accessibility labels. Site validation also checks heading fragment links.

Distribution

The native CLI and server remain one self-contained executable. The localized
site and books are build-time documentation assets and add no runtime or
companion bundle requirement to the executable.

Benchmark

The release benchmark uses the same fixed 16 file corpus and established
native, Python, browser, stage, and server lenses as 0.3.2. Docling remains in
parser-only mode with OCR, VLM, models, enrichment, and accelerators disabled.
The recorded numbers describe one reference machine and are not a promise for
every document or environment.

Across all 16 files, zenfmt's native geometric means were 6.81 ms wall time,
5.97 ms CPU time, and 5.33 MB peak resident memory. The recorded 0.3.2 values
were 6.88 ms, 6.03 ms, and 5.31 MB. These small differences are within normal
run variation and do not indicate a performance regression.

On shared files, the recorded speed, CPU, and peak memory ratios were 6.9x,
7.9x, and 10.1x for AnyDoc divided by zenfmt. They were 18.2x, 16.5x, and
16.6x for Pandoc, and 190.4x, 205.5x, and 47.5x for parser-only Docling. The
separate server lens recorded 31.1x warm latency and 34.2x sampled peak memory
for Tika divided by zenfmt. At one client, zenfmt recorded 552.7 documents per
second and Tika recorded 4.4. These ratios describe this corpus and host, not
conversion quality or every deployment.

Upgrade

Replace the 0.3.2 executable with 0.3.3 and restart a running service. Existing
server configuration, secure storage, API behavior, and converted output remain
compatible.

zenfmt 0.3.2

zenfmt 0.3.2

zenfmt 0.3.2 is a small interface and documentation release for the server and
browser converter. The conversion engine and its output remain compatible with
0.3.1.

Server interface

• The converter, account, and administration pages now use a clearer responsive
  layout with System, Light, and Dark themes. System remains the default.
• The conversion interface reads larger structured responses correctly and
  keeps the converted artifact available for preview and download.
• The public API reference is available at /docs, with the OpenAPI 3.1
  document at /openapi.json. Secure management routes still require sign in.
• The interface, OpenAPI document, migrations, and converter remain embedded in
  the single native executable. No adjacent web bundle is required.

Browser converter

• Downloaded conversions now use the derived Markdown name. For example,
  report.docx downloads as report.md.
• Browser coverage verifies that the downloaded bytes match the Markdown shown
  in the output pane.

Benchmark

The release benchmark was rerun on the fixed 16 file corpus after the interface
changes. It covers the native CLI, Python wheel, browser module, conversion
stages, and the separate server comparison. Docling remains parser only, with
OCR, VLM, models, enrichment, and accelerators disabled. The recorded results
describe one reference machine and are not a promise for every workload.

Across all 16 files, zenfmt's native geometric means were 6.88 ms wall time,
6.03 ms CPU time, and 5.31 MB peak resident memory. The recorded 0.3.1 values
were 6.91 ms, 6.04 ms, and 5.32 MB. These small differences are within normal
run variation and do not indicate a performance regression.

On shared files, the recorded speed, CPU, and peak memory ratios were 7.0x,
7.9x, and 10.2x for AnyDoc divided by zenfmt. They were 18.1x, 16.6x, and 16.6x
for Pandoc, and 195.9x, 209.1x, and 47.6x for parser only Docling. The separate
server lens recorded 32.3x warm latency and 32.4x sampled peak memory for Tika
divided by zenfmt. These ratios describe this corpus and host, not conversion
quality or every deployment.

Upgrade

Replace the 0.3.1 executable with 0.3.2 and restart a running service. Existing
server configuration, secure storage, API behavior, and converted output remain
compatible.

zenfmt 0.3.1

zenfmt 0.3.1

zenfmt 0.3.1 is a small performance release for the converter included in the
self-contained CLI and server executable.

Performance

• AST validation now reuses one bounded ancestor scratch area for the whole
  validation call instead of creating hard-cap-sized storage for each forest.
• The lowering planner now reuses one bounded alternative buffer for the
  whole plan instead of creating it for every non-exact node.
• The changes preserve the same depth limits, lowering choices, diagnostics,
  and converted bytes. They mainly help wide documents with many nodes, such
  as large CSV tables, and also reduce repeated work for HTML, EPUB, and
  presentation inputs.

The release benchmark uses the same 16-file corpus and method as 0.3.0. The
final native, Python, browser, stage, and server records identify the measured
0.3.1 revision. Results describe one modest reference machine and should not
be treated as a quality score or a promise for every document.

On the native CLI lens, the geometric means for speed, CPU use, and peak
memory were 7.0x, 7.9x, and 10.2x for AnyDoc divided by zenfmt over 14 shared
files. The corresponding ratios were 17.1x, 16.1x, and 16.6x for Pandoc over
6 files, and 192.1x, 206.4x, and 47.5x for parser-only Docling over 5 files.
The wide CSV completed in 54.0 ms, compared with 2,084.1 ms in the recorded
0.3.0 run. This comparison is useful for checking the repaired path, but it
does not imply that every workload will change by the same amount.

The separate server lens recorded 32.3x warm latency and 36.6x sampled peak
memory for Tika divided by zenfmt. At one client, zenfmt recorded 555.2
documents per second and Tika recorded 4.4. The values reflect one local host,
the pinned Tika build, and this corpus.

Benchmark presentation

• The project homepage and benchmark page present native CLI speed, CPU time,
  and peak resident memory as separate measures.
• The Apache Tika Server comparison follows the native CLI comparison and
  remains a separate long-running HTTP lens.
• The book and README use the same ratio direction and shared-file rules as
  the generated dashboard.

Upgrade

Replace the 0.3.0 executable with 0.3.1 and restart a running service. Server
configuration, secure storage, API behavior, and conversion output remain
compatible with 0.3.0.

zenfmt 0.3.0

zenfmt 0.3.0

zenfmt 0.3.0 adds a self-contained document conversion server to the existing
CLI, Zig library, Python package, and browser WebAssembly distribution.

Server

• zenfmt serve starts an anonymous loopback conversion service and embedded
  converter interface with no data directory.
• Secure mode adds durable users, two roles, sessions, API keys, CSRF
  protection, an audit log, and the administration interface through
  zenfmt serve --secure --data-dir PATH.
• POST and PUT /api/v1/convert accept raw or multipart document bytes and
  return Markdown or a structured JSON envelope. Batch conversion streams
  NDJSON responses.
• Health, readiness, Prometheus metrics, bounded connection and conversion
  admission, structured logs, graceful shutdown, and embedded interface
  assets are included in the executable.
• The interface supports System, Light, and Dark themes. System is the
  default. Secure browser tests cover bootstrap login, password change, user
  creation, role and status changes, password reset, deletion, and one-time
  secret handling.

Distribution

• Every native CLI archive contains the same single zenfmt executable with
  the server, zaxonlite store, migrations, CSS, JavaScript, and UI WebAssembly
  embedded. No Java, Python, model files, runtime bundle, or adjacent assets
  are required.
• Release gates execute that CLI and server from an empty directory on all
  seven native targets: x86_64 and ARM64 Linux with glibc and musl, x86_64 and
  ARM64 macOS, and x86_64 Windows.
• The smaller conversion-only executable remains available to source builders
  with -Dserver=false.

Benchmarks

The benchmark method now includes a model-free Docling parser comparison and
an Apache Tika Server comparison over the existing corpus. The 0.3.0 native,
Python, server, and in-process stage lenses were recorded at commit
9c69a3abdbb59e6303f11c5d3abf47bc8cda6a47.

• zenfmt converted 16 of 16 files, Docling converted 5 of 16, AnyDoc converted
  14 of 16, and Pandoc converted 6 of 16.

• On the five files shared by zenfmt and Docling, Docling's geometric mean
  wall time was 68.5 times zenfmt's. This ratio describes timing over shared
  successful files and is not a quality score.

• Median startup was 106.8 ms for zenfmt and 10,978.1 ms for Tika Server.

• Sampled peak resident memory was 53.1 MiB for zenfmt and 2,147.5 MiB for
  Tika Server. This samples each parent and its direct parser children.

• The short throughput samples at 1, 2, 4, and 8 clients were 199.5, 397.5,
  782.6, and 1,177.5 documents per second for zenfmt. Tika Server recorded
  2.9, 5.5, 7.0, and 7.2 documents per second.

These figures describe one modest machine and a small fixed corpus. The server
gate checks for a successful nonempty response but does not score semantic
quality. The Docling run used parser backends only, with no OCR, VLM, ASR,
layout model, table model, enrichment, or accelerator. The browser aggregate
was not regenerated, so the site identifies it as incomplete rather than
mixing the earlier browser result into the 0.3.0 measurements.

Upgrade

Replace the 0.2.0 executable with 0.3.0 and restart it. Existing conversion
behavior is unchanged. Secure server storage is created only when --secure
and --data-dir are supplied.

zenfmt 0.2.0

zenfmt 0.2.0

Pandoc showed how useful a universal document converter can be. zenfmt 0.2.0
continues a small attempt to explore that idea in Zig by making the existing
nineteen-reader engine available in the browser as a wasm32-freestanding
release target. The project site converts documents in a dedicated worker on
the visitor's device. It also publishes the Book, every ZDS record, target
downloads, and a benchmark whose raw measurements are available for review.

Highlights

• Browser-local document conversion with no filesystem, network, clock,
  randomness, thread, or other host imports.
• A versioned ES adapter, dedicated worker, declarations, capability document,
  internal artifact manifest, and standalone WASM module.
• A responsive 40/60 converter workspace with readable Markdown output,
  cancellation, 30-second timeout, line wrapping, theme selection, and
  Elm-style diagnostics with concrete directions.
• Multi-page HTML Book and ZDS documentation, local search, contextual help,
  side navigation, stable PDF links, and an archival Book PDF.
• Direct downloads for seven native CLI targets, seven Python wheel targets,
  the Python source distribution, WebAssembly, source, and documentation.
• SHA-256 manifests, an SPDX 2.3 release inventory, and GitHub artifact
  attestations.

Browser limits

The browser profile accepts at most 32 MiB of input, 128 MiB total archive
expansion, 64 MiB per archive entry, 64 MiB decoded text, 32 MiB embedded
resources, and 64 MiB output. Linear memory is capped at 1 GiB and the worker
is recycled at a 512 MiB high-water mark. A limit refusal explains how to use
the native CLI or Python library for larger work.

The site supports current and previous stable Chromium, Firefox, and Safari
releases that provide WebAssembly, ES modules, dedicated workers, transferable
buffers, and file APIs. Chromium is the automated release gate. Safari on
macOS and iOS remains a required manual release check; automated WebKit is not
presented as Safari coverage.

Verification

Use SHA256SUMS for downloaded files and GitHub's attestation command for
provenance:

gh attestation verify zenfmt-0.2.0-wasm32-freestanding.wasm \
  --repo insanai/zenfmt

The WASM module in the browser bundle, the standalone WASM release target, and
the module deployed to GitHub Pages are checked to be byte-identical.

Known limitations

Markdown is still the only writer. Browser benchmark rows for AnyDoc and
Pandoc remain explicitly “not benchmarked” until maintained, pinned browser
distributions satisfy the same file-to-Markdown harness; both tools remain in
the native comparison. GitHub Pages cannot deliver frame-ancestors as a
response header, so the static site can be framed; it holds no account,
credential, or server-side action.

zenfmt 0.1.0

Full Changelog: https://github.com/insanai/zenfmt/commits/v0.1.0