fix: Typst extension logo path resolution in subdirectories (#13917)

[gordonwoodhull]

Summary

• Fixes extension logo paths being incorrectly double-prefixed with project offset when rendering from subdirectories
• Extension-resolved paths (containing _extensions or starting with ..) are already input-relative and should not have projectOffset() applied
• Adds test case verifying extension logos work correctly from subdirectories

Problem

When using a custom Typst format extension with a logo, rendering from a subdirectory fails:

metadata
  logo: ../_extensions/issue/quarto-icon.svg  # correct input-relative path

error: failed to load file (access denied)
    image("../../_extensions/issue/quarto-icon.svg")  # incorrectly double-prefixed
    = hint: cannot read file outside of project root

The bug was introduced in commit 533784522 which added projectOffset() to logo paths for brand.yml support, but incorrectly applied it to all logo paths including extension-resolved ones.

Solution

In src/resources/filters/quarto-post/typst-brand-yaml.lua, detect extension-resolved paths and skip the project offset:

if imageFilename[1] ~= "/" and _quarto.projectOffset() ~= "." then
  local is_extension_path = string.find(imageFilename, "_extensions") or
    string.sub(imageFilename, 1, 2) == ".."
  if not is_extension_path then
    local offset = _quarto.projectOffset()
    imageFilename = pandoc.path.join({offset, imageFilename})
  end
end

This is the same pattern used in PR #13902 for font-paths.

Related

• Same underlying issue as In custom typst format extension, relative or project relative font-paths not working #13745 / PR fix: resolve relative font-paths in typst extensions (#13745) #13902 (font-paths)
• See plans/brand-extension-path-resolution.md for detailed analysis of both path systems

Fixes #13917

Test plan

• New smoke test in tests/docs/smoke-all/typst/extension-logo/ verifies correct path in generated .typ file
• CI tests pass

🤖 Generated with Claude Code

[posit-snyk-bot]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scanner	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[mcanouil]

FWI, the issue does not seem limited to logo, other resources are impacted.

I updated my reprex:

git clone --filter=blob:none --sparse https://github.com/mcanouil/quarto-issues-experiments.git
cd quarto-issues-experiments
git sparse-checkout set quarto-cli-13917

Extensions resources should never have ../ prepended to them.
Extensions are at the root and it seems --root is set to _quarto.yml location when sent to typst, so the paths have no reasons to get project offset when in a project and when Quarto extensions resources from my understanding.

[gordonwoodhull]

I asked the critical code reviewer for feedback on both this and #13745 and among other things it said this:

7. The real fix is upstream

The root cause is toInputRelativePaths() transforming paths without tagging them as
"already transformed." A cleaner fix would be:

• Have toInputRelativePaths() return a typed object { path: string, isInputRelative:
  boolean }
• Or use a sentinel prefix that downstream code can detect and strip
• Or don't transform extension paths at all and handle them differently downstream

The current approach is whack-a-mole.

Thus my paralysis in merging either fix. We can't really make our paths typed in the current codebase, but yes that is the root cause of all these miserable path problems.

I'm looking into the use of more project-relative or absolute paths as a better fix. But I won't get to it until I get back.