stet 0.1.2

stet-cli bugfix release

Versions 0.1.0 and 0.1.1 of stet-cli have been yanked from crates.io. If you previously installed either one, upgrade with:

cargo install stet-cli --force

What was broken

The stet binary's context setup never registered the embedded resource bundle (init scripts, encodings, CMaps, fonts, ICC profile) into its virtual filesystem. Instead it walked up from the binary location via find_resource_path() looking for a resources/ directory on disk. For anyone who installed via cargo install stet-cli — with no resource tree adjacent to ~/.cargo/bin/stet — findresource for the viewer's OutputDevice failed, the CLI fell back to a PNG-writing rasterizer, and every PostScript page rendered in the interactive viewer would silently write a rogue .png file next to the input.

What's fixed in 0.1.2

stet-cli now calls stet::embedded_resources::register_all() at context creation, matching what the stet facade library has always done. The binary is fully self-contained — no resources/ directory required, no rogue PNGs, viewer mode behaves correctly.

Scope

• Affected: stet-cli 0.1.0 and 0.1.1 (yanked).
• Not affected: the stet library crate (used via Interpreter), stet-pdf-reader, stet-fonts, stet-graphics, and every other library crate in the workspace. All of those were and remain correct.