Skip to content

The deck on standard output is the renderer's own bytes - #24

Merged
fabeat merged 3 commits into
mainfrom
feature/file-finder
Oct 30, 2026
Merged

fabeat merged 3 commits into
mainfrom
feature/file-finder

Conversation

@fabeat

@fabeat fabeat commented Oct 29, 2026

Copy link
Copy Markdown
Contributor

The deck on standard output is the renderer's own bytes, and theme init reads a theme back the way the library reads one.

The deck to standard output

mdoffice slides to-pptx -o - wrote the deck to a temporary file, read it back and removed it. Its own comment said why:

The renderer writes the file rather than returning its bytes, so to standard output means to a temporary file that is read back and removed. A .pptx is a zip archive, and building one in memory would mean carrying PHPWord's writer around a second path for the sake of a pipe.

The renderer returns its bytes now. PresentationRenderer::toString(Deck $deck): string gives the deck as the bytes of a .pptx — it stages to a temporary file of the library's own and reads that back, so the command no longer has to make one. The command's temporary(), its finally and its cleanup all go away with it.

Every other output still goes through render($deck, $path).

theme init — a break the library's change caused

ThemeLoader::load()'s first parameter is now a theme's name rather than its directory. theme init was passing a directory, so against the new libraries it refused every deck with "… is not a theme: it has no theme.yml".

It now passes the directory's own name with a finder rooted at its parent — the shape ThemeResolver uses. The failure messages, and the theme.yml, layouts.yml and template.pptx that are read, are unchanged.

What did not change

No command, no option, no exit code and no message. The two other library call sites — MarkdownToWord::__construct()'s new trailing named parameters, and TemplateFile::__construct()'s — needed no change at all.

The tests

  • a deck written to standard output is the same deck written to a file — compared by the ppt/slides/slideN.xml parts, never by the archive bytes, because a zip stores 2-second timestamps and docProps/core.xml carries creation and modification times. The test also asserts there are three parts, so two empty sets would not pass;
  • a piped run leaves no file behind in the system temp directory — the whole directory diffed before and after, for a successful run and for a refused one. The library stages its own file there now, so a glob of the command's own prefix would have been blind to it;
  • the theme theme init writes is resolved through the library's own ThemeResolver, the way a deck beside it finds one.

The release

This branch needs the two libraries merged and released before it is released, not before it is merged: the archive build resolves them from their GitHub releases, so it cannot succeed until they carry a published tag in the ^0.3 series.

The renderer writes the deck to a file and reads it back for a pipe, so the
command staged a file of its own in the system temp directory and took it
away again. The renderer returns the bytes of a deck now, and the command
asks it for them: the deck that leaves through standard output is the deck
the command writes to a file, and nothing of the tool's is left behind.
The loader resolves a theme by name and asks a finder where that name is,
so the command reads the theme it wrote the way the library resolves every
other one. The template is read from the theme's own directory, which is
where the command wrote it and where the loader found it.
… is named

The temp-directory test diffed the whole listing of the system temp directory,
so any other process on the machine could fail it: a browser, a package manager,
another test run. It looks at the staged files now, under the prefixes the
library and the command stage them with, and the library's own staging file is
one of them. The widened intent stays — a file the library leaves behind is
still a file the test finds — but nothing else in the directory is any of the
test's business.

The release note said that a theme the command writes is one the library can
draw a deck in. That holds where the theme sits in a themes/<name> directory,
and not where the command's own default writes it: beside the deck, where a
deck names it by its path. The note says which is which now, and a test says it
in code — the theme the command writes by default is one a deck names by its
path — so the note and the command cannot drift apart without a test noticing.

The claim guard reads the changelog as well as the README, so a release note
cannot say again what the code does not do.
@sonarqubecloud

Copy link
Copy Markdown

@fabeat
fabeat merged commit 9342d7c into main Oct 30, 2026
7 checks passed
@fabeat
fabeat deleted the feature/file-finder branch October 30, 2026 09:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant