revealjs format extension `logo:` resolves to a broken path in subfolder documents when the project has a `_brand.yml`

[cynthiahqy]

I have:

• searched the issue tracker for similar issues
• installed the latest version of Quarto CLI (1.10.18)
• formatted my issue following the Bug Reports guide

Bug description

A revealjs format extension that sets logo: (path relative to the extension folder) works in a website project until the project also has a brand: file. With a brand file, documents in a subdirectory get <img src="../../_extensions/<ext>/logo.png">, a path that points outside _site and is not copied into the output, so the logo 404s once the site is deployed. Documents in the project root are fine, and without brand: the logo is correctly copied to site_libs/quarto-contrib/... for both.

This looks like the same root cause described in #14075 (project-relative logo paths corrected to document-relative paths after merging with brand), which fixed Typst only and noted "related bugs in dashboard and revealjs which might need a similar fix". Related: #11982 (brand logo paths in subdirectories; closed).

The brand file does not need to contain a logo. Its mere presence changes how the extension's logo: is resolved.

How this was found

I maintain a Quarto course website and was extracting its slide theme into a reusable format extension, quarto-lmu-revealjs, used by a website template, quarto-lmu-subject-template. The extension originally set logo: in its _extension.yml. Slides in the project root showed the logo, but slides in week subfolders (02-topic/slides.qmd) had a broken image, because the rendered path was ../../_extensions/lmu/logos/..., which is outside _site and never copied. Testing showed the trigger is a brand: entry in _quarto.yml (removing it makes the subfolder logo work). The minimal repro below is independent of those repos.

Workaround currently used in the template: the extension no longer sets a default logo:, and the logo is set in the project instead (_brand.yml logo: and a project-root-relative logo: in _slides.yml). See _brand.yml and _slides.yml in the template repo.

Disclosure: this report was drafted by an AI assistant (Claude Sonnet 5, via Claude Code) working in my repository. The repro was run and its output observed on Quarto 1.10.18 in that session; I have reviewed the text before posting.

Steps to reproduce

.
├── _extensions/repro/
│   ├── _extension.yml
│   └── logo.png            # any png
├── _brand.yml
├── _quarto.yml
├── root.qmd
└── sub/deck.qmd

_extensions/repro/_extension.yml

title: Repro
author: x
version: 1.0.0
contributes:
  formats:
    revealjs:
      logo: logo.png

_quarto.yml

project:
  type: website
brand: _brand.yml

_brand.yml

color:
  primary: "#00883A"

root.qmd and sub/deck.qmd (identical apart from title)

---
title: test
format: repro-revealjs
---

## slide

quarto render
grep -o '<img src="[^"]*" class="slide-logo">' _site/root.html _site/sub/deck.html
find _site -name logo.png

Actual behavior

With brand: _brand.yml:

_site/root.html:     <img src="site_libs/quarto-contrib/quarto-project/repro/logo.png" class="slide-logo">
_site/sub/deck.html: <img src="../../_extensions/repro/logo.png" class="slide-logo">

Only _site/site_libs/quarto-contrib/quarto-project/repro/logo.png exists. The ../../_extensions/... path from _site/sub/ resolves outside the output directory.

Expected behavior

sub/deck.html should reference ../site_libs/quarto-contrib/quarto-project/repro/logo.png, as it does when brand: is removed from _quarto.yml.

Notes

• Removing brand: from _quarto.yml makes both documents correct.
• Setting the logo in the project instead (e.g. logo: in _brand.yml, or a project-root-relative logo: in document metadata) works; only the extension-provided default is affected.
• format-resources and logo: {path: ...} in the extension did not change the result.

Your environment

• macOS (Darwin 25.6.0), Quarto CLI 1.10.18 (Homebrew cask)
• Also observed on 1.9.36

Quarto check output

Quarto 1.10.18
[✓] Checking environment information...
      Quarto cache location: ~/Library/Caches/quarto
[✓] Checking versions of quarto binary dependencies...
      Pandoc version 3.10.0: OK
      Dart Sass version 1.101.0: OK
      Deno version 2.7.14: OK
      NOTE: Typst version 0.14.2 does not strictly match 0.15.1 and strict checking is enabled. Please use 0.15.1.
[✓] Checking versions of quarto dependencies......OK
[✓] Checking Quarto installation......OK
      Version: 1.10.18
      Path: /Applications/quarto/bin
[✓] Checking tools....................OK
      TinyTeX: (not installed)
      Chrome Headless Shell: (not installed)
      VeraPDF: (not installed)
[✓] Checking LaTeX....................OK
      Using: Installation From Path
      Path: /Library/TeX/texbin
      Version: 2025
[✓] Checking Chrome Headless....................OK
      Using: Chrome found on system
      Path: /Applications/Google Chrome.app/Contents/MacOS/Google Chrome
      Source: MacOS known location
[✓] Checking basic markdown render....OK
[✓] Checking R installation...........OK
      Version: 4.5.2
      Path: /Library/Frameworks/R.framework/Versions/4.5-arm64/Resources
      LibPaths:
        - ~/Library/R/arm64/4.5/library
        - /Library/Frameworks/R.framework/Versions/4.5-arm64/Resources/library
      knitr: 1.52
      rmarkdown: 2.32
[✓] Checking Knitr engine render......OK
[✓] Checking Python 3 installation....OK
      Version: 3.14.3
      Path: /opt/homebrew/opt/python@3.14/bin/python3.14
      Jupyter: (None)
      Jupyter is not available in this Python installation.
      Install with python3 -m pip install jupyter
[✓] Checking Julia installation...

(Home directory paths shortened to ~.)

[mcanouil]

I can reproduce this on the current main, and it's a regression from 1.8. I tested with the ghcr.io/mcanouil/quarto-codespaces images. The logo works in 1.7.34 and breaks in 1.8.27, 1.9.38 and 1.10.18.

The cause is logoAddLeadingSlashes, added in #13279 to fix #11982. When a project has a brand and the document sits in a subfolder, it adds a / to every logo path. It expects the path to be relative to the project, and it expects a later step to turn the / back into a relative path. Neither is always true.

• quarto-cli/src/core/brand/brand.ts

  Lines 406 to 432 in ced2f79

  	const ensureLeadingSlashIfNotExternal = (path: string) =>
  	isExternalPath(path) ? path : ensureLeadingSlash(path);
  	export function logoAddLeadingSlashes(
  	spec: NormalizedLogoLightDarkSpecifier | undefined,
  	brand: LightDarkBrand | undefined,
  	input: string | undefined,
  	): NormalizedLogoLightDarkSpecifier | undefined {
  	if (!spec) {
  	return spec;
  	}
  	if (input) {
  	const inputDir = dirname(resolve(input));
  	if (!brand || inputDir === brand.light?.projectDir) {
  	return spec;
  	}
  	}
  	return {
  	light: spec.light && {
  	...spec.light,
  	path: ensureLeadingSlashIfNotExternal(spec.light.path),
  	},
  	dark: spec.dark && {
  	...spec.dark,
  	path: ensureLeadingSlashIfNotExternal(spec.dark.path),
  	},
  	};

An extension's logo: is already relative to the document at that point. So ../_extensions/repro/logo.png becomes /../_extensions/repro/logo.png. The website resolver then gives ../../_extensions/repro/logo.png. That path doesn't start with _extensions/, so the logo is never copied to site_libs/.

• quarto-cli/src/extension/extension.ts

  Lines 163 to 188 in ced2f79

  	export function projectExtensionPathResolver(
  	libDir: string,
  	projectDir: string,
  	) {
  	return (href: string, projectOffset: string) => {
  	const projectRelativeHref = relative(projectOffset, href);
  	if (
  	projectRelativeHref.startsWith("_extensions/") ||
  	projectRelativeHref.startsWith("_extensions\\")
  	) {
  	const projectTargetHref = projectRelativeHref.replace(
  	/^_extensions/,
  	`${libDir}/quarto-contrib/quarto-project`,
  	);
  	copyResourceFile(
  	projectDir,
  	join(projectDir, projectRelativeHref),
  	join(projectDir, projectTargetHref),
  	);
  	return join(projectOffset, projectTargetHref);
  	}
  	return href;
  	};

Dashboards call the same helper and break in the same way.

• quarto-cli/src/format/dashboard/format-dashboard.ts

  Lines 134 to 139 in ced2f79

  	let logo = resolveLogo(brand, logoSpec, [
  	"small",
  	"medium",
  	"large",
  	]);
  	logo = logoAddLeadingSlashes(logo, brand, input);

Default projects (not websites) have a related problem, even without an extension. With logo: small: images/logo.png in _brand.yml, a reveal.js deck in sub/ gets src="/images/logo.png". Outside websites, nothing turns that / back into a relative path. With embed-resources: true, the render stops with a bare ERROR: Error. Pandoc's real message is /images/logo.png: withBinaryFile: does not exist, but Quarto doesn't show it. This case was already broken in 1.7.34, where the logo was simply missing. Since 1.8, the render fails.

The Typst fix in #14075 points to a way out. It adds the / only to logo paths that come from the brand, before they're merged with the document's logo. The same approach would fix extension logos in reveal.js and dashboards. Default projects would still need the / turned back into a relative path.

• quarto-cli/src/format/typst/format-typst.ts

  Lines 107 to 122 in ced2f79

  	const brand = format.render.brand;
  	// For Typst, convert brand logo paths to project-absolute (with /)
  	// before merging with document logo metadata. Typst resolves / paths
  	// via --root which points to the project directory.
  	const typstBrand = brandWithAbsoluteLogoPaths(brand);
  	const logoSpec = format
  	.metadata[kLogo] as LogoLightDarkSpecifierPathOptional;
  	const sizeOrder: BrandNamedLogo[] = [
  	"small",
  	"medium",
  	"large",
  	];
  	// temporary: if document logo has object or light/dark objects
  	// without path, do our own findLogo to add the path
  	// typst is the exception not needing path but we'll probably deprecate this
  	const logo = fillLogoPaths(typstBrand, logoSpec, sizeOrder);