v4.0.1

[4.0.1] - 2026-09-21

A same-day patch for one colour bug. If you build decks that use layout or master placeholders,
rebuild them with this version.

Corrected after publishing. The first version of these notes said 4.0.0 introduced this. It
did not: it widened an older defect. The two call forms and their histories are set out below.

Fixed

• Text targeting a placeholder no longer has black written into it. addText(…, { placeholder: 'title' }) emitted an explicit <a:solidFill><a:srgbClr val="000000"/></a:solidFill> on the run,
  so text whose whole purpose is to take its colour from the layout or master stopped following the
  theme: a recoloured master left the slide's own text black. The colour default has always been
  suppressed for placeholder-targeting text, but it tested the bag it was handed, and cleanOpts
  runs once for the shape and again for each of its runs, where a run carries only what the caller
  wrote on that run. So the shape was spared and the run inside it was not. The question asked is
  now whether the text targets a placeholder, which is the object's answer as much as the run's. A
  colour the caller does state still arrives, through RUN_INHERITABLE_OPTIONS, and nothing else
  about the default changes.

  The two call forms were affected at different times. addText([{ text }], { placeholder }), the
  array and multi-paragraph form, has been baking black for as long as the guard has read one bag.
  addText('x', { placeholder }), the string form, was spared by accident until 4.0.0: it handed
  ONE options object to both the shape and its lone run, so the run's bag was the shape's and
  carried the key. Removing that aliasing, so a run no longer inherits the shape's shadow, took
  the key this default was reading and the string form started baking black too. So 4.0.0 widened
  an older defect rather than introducing one, and this release fixes both forms.

  Downstream impact: a deck built with 4.0.0 carries the baked colour wherever it targets a
  placeholder, and one built earlier carries it wherever it did so through the array form;
  rebuilding with this version restores inheritance in both cases. Every byte-identity gate stayed
  green throughout, because no showcase deck states an inherited placeholder colour, which is also
  why the new coverage goes through the emitted package rather than the corpus. It was caught by
  pptx-html's fidelity oracle, which reported the construct text.color.inherited moving on its
  corpus decks: first disappearing from four of them on the 4.0.0 bump, then appearing on two more
  than its baseline once this fix landed, which is what showed the older half.

Full changelog: https://github.com/shbernal/ts-pptx/blob/v4.0.1/CHANGELOG.md