Three Young Rust Tools Rework Document Pipelines
PhotoCraft, typdiff, and TeXres take sharply different approaches to making creative and publishing workflows local, inspectable, and easier to package.
Tools in this story
- PhotoCraft — Project website
- typdiff — Project website
- texres — Project website

Three projects, one recurring instinct
PhotoCraft, typdiff, and TeXres are not a suite. They do not share a maintainer, file format, or promised integration. What connects them is a young-project instinct: take a workflow normally spread across a large application or distribution, rebuild a focused path in Rust, and expose enough structure that users can inspect the result. Each project published its first non-prerelease build in 2026. That makes them interesting experiments, not automatic replacements for mature tools.
PhotoCraft is the broadest bet. Its first release appeared on October 2, two days after the public repository was created. The project describes a native editor with layers, masks, adjustments, type, vectors, brushes, local selection tools, GPU rendering, and layered PSD or PSB support. It targets desktop platforms and the browser, while its engine-first architecture also supports command-line and structured automation. The ambition is immediately legible: familiar image-editing concepts, local files, and a permissively licensed implementation rather than a web wrapper.
The project is equally direct about its state. Its repository labels the application early alpha. The roadmap warns that a feature-surface estimate can overstate user-facing readiness, and the issue tracker contains reports about brush behavior, transforms, large documents, and interface details. That public friction is useful evidence of actual testing, but it is also a reason to work on copies and keep an established editor nearby. Homebrew now distributes the application, which lowers the evaluation barrier without changing those maturity facts.
A diff that remains a document
typdiff makes a narrower intervention. Given old and new Typst sources, it emits another Typst document containing addition and deletion markup. It parses headings, paragraphs, and list structures, performs block and word comparisons, and uses character-level handling for Chinese, Japanese, and Korean text. The resulting source can be compiled into a visual PDF redline. That is different from merely coloring a raw text patch: the review artifact remains inside the document system.
Its first v0.1.0 release arrived on February 18. An independent Typst feature discussion supplies an early usage signal: participants describe visual diffs as useful for manuscripts, peer-review responses, legal redlines, internal documentation, and CI artifacts, and later point to typdiff as a working parser-aware option. That discussion does not prove broad adoption, but it demonstrates a concrete need outside the project’s own README.
The boundaries matter. Raw blocks, equations, and function calls are atomic, so reviewers should not assume every semantic change receives a fine-grained explanation. typdiff produces Typst; a separate Typst compiler produces the PDF. For source review, ordinary Git diff remains simpler. The tool becomes valuable when a reader needs a document-shaped comparison rather than only changed lines.
A TeX distribution compressed into one executable
TeXres tackles packaging rather than editing or comparison. Its first v0.1.0 release appeared on September 16. The project combines pdfLaTeX, XeLaTeX, LuaLaTeX, formats, a package archive, fonts, BibTeX, and Biber in a Rust-written distribution that says it downloads nothing during a build. The front-end reruns the necessary passes until references converge, supports watch mode, and offers C and WebAssembly interfaces for in-memory compilation. Its CI compares output with TeX Live 2026.
That design promises a smaller operational surface, not a simpler language. LaTeX documents can depend on obscure packages, engine behavior, fonts, and years of compatibility assumptions. TeXres uses a bundled font set rather than system fonts; additional fonts must travel with the project. ARM64 Linux requires a recent glibc, while musl systems are unsupported. A responsible trial starts with representative documents and compares PDFs, logs, bibliography output, links, and font substitution before changing a production pipeline.
Evaluate outcomes, not implementation language
Rust is part of all three stories, but it is not the user benefit by itself. The measurable questions sit at the workflow boundary:
- Does PhotoCraft round-trip the layered files and color modes a team actually uses?
- Does typdiff make review faster without hiding important source changes?
- Does TeXres reproduce the documents, packages, fonts, and bibliography behavior a project depends on?
The projects’ youth makes those tests especially important. PhotoCraft already attracts active bug reports and package-manager distribution; typdiff has surfaced in a pre-existing community discussion about visual review; TeXres exposes hundreds of commits and explicit compatibility claims in public. Those are meaningful usage and development signals, but none is a guarantee of production fitness.
The compelling shared direction is control. Image operations stay local and scriptable. A diff becomes inspectable source rather than an opaque screenshot. A typesetting environment can travel as a bounded executable and archive. If those properties solve a real constraint, each tool now has enough public evidence for a careful pilot. The right next step is not wholesale migration; it is one representative file, one reproducible comparison, and a written record of what still fails.