Implementations

Nothing on this page is privileged by the format. The specification is public domain, an implementation needs no permission and no blessing, and the only thing that makes one correct is the specification itself. The programs below are the ones that exist today; the list is open, and a pull request adds to it.

The reference implementation

slpc-rust is a Rust workspace holding two crates: slpc, the library that reads, writes and validates containers, and slipcase, the command-line tool built on it. It is a reference implementation in the strict sense — it exists to show that the specification is implementable, and to be checked against it. Where the two disagree, the specification is right.

slipcase pack report.pdf --meta owner.toml       # writes report.pdf.slpc
slipcase info report.pdf.slpc                    # prints the metadata
slipcase repack report.pdf.slpc --meta new.toml  # changes it in place, keeping the rest
slipcase validate report.pdf.slpc                # exit 0 if conformant
slipcase unpack report.pdf.slpc --dest ./out     # writes the payload and nothing else

Wherever a file is read, - names standard input, and wherever one is written it names standard output. Exit codes tell success from bad input, from a bad command line, from a container the build cannot judge.

On Debian and Ubuntu it is sudo apt install slipcase from the Excelano apt repository; on macOS and Linux with Homebrew, brew install excelano/tap/slipcase; from source, cargo install slipcase. Windows, the curl installer and the plain release archives are covered in the repository's README, which is where the current instructions live rather than here. MIT licensed.

Applications

Slipcase Desktop opens a container, says whether it is conformant, shows the payload and the metadata travelling with it, lets the metadata be edited in place, and hands the payload to whatever the operating system already opens that kind of file with. It is on the Mac App Store, on the Microsoft Store as Slipcase, in the Excelano apt repository as slipcase-desktop, and in source at excelano/slipcase-desktop. It parses no containers itself: every read, every write and every verdict comes from slpc.

slipcase-open takes the other half of the job. Double-click a container and the payload opens in whatever application normally handles it; edit it there, save, and the edit is repacked into the container. No metadata window and no container browsing — the two products claim the same file association deliberately, and whichever was installed last wins while the other stays one click away in the Open With menu. Linux today, from the apt repository or from source; Windows and macOS are not built yet. MIT licensed.

slipcase-common is not a program. It is the media type declaration and the icon a container is drawn with, packaged once so that every Slipcase product on a Linux machine can depend on it — two packages cannot ship the same path, and an icon named for a media type is one file at one path. Without it a container draws as a blank generic document, which is the first thing somebody sees of a file format they were sent and did not ask for.

Writing your own

Read §2 for what a container is and §3 for what a program handling one must do. The second is the part that is easy to skip and is where the interesting requirements are: locate the payload by payload.file and never by position, establish uniqueness by enumerating central directory entries rather than by a name-keyed lookup, preserve metadata keys and archive members you do not recognise, write only the payload when extracting, and never apply the permission bits recorded in the archive.

Read §6 before anything that runs unattended. Identifying a container is a parse of untrusted input — a reader cannot know whether a file is a container without decompressing the metadata member and parsing it as TOML, and it must do that before anything about the file has been established. An indexer, a scanner or a shell preview handler is invoked on whatever happens to be in the directory, so the bound on what it will spend has to be in place before it knows what it is holding.

Then check yourself against the conformance corpus: eighty-seven containers with declared verdicts, built by a generator that needs nothing but Python 3.11. It covers the cases a hand-written test suite tends not to reach — a local file header disagreeing with the central directory, a CP437 name with the UTF-8 flag clear, duplicate member names, an entry that is not a regular file. It is not normative. Where a case and the specification disagree, the specification wins and the case is a bug worth reporting.

If the specification cannot answer a question you actually hit, that is the most valuable thing you can send back. Open an issue.

Adding to this list

Open a pull request against this site's repository. What is wanted is a program someone can actually obtain, a note of which version of the specification it implements, and a link to its source or its listing. Completeness is not a bar — a library that only reads containers is worth listing and worth saying so about.