Quarto 1.10.18 Mac PDF Export Failure: 2026 Troubleshooting

The Quarto release list includes version 1.10.18. Confirm the version actually running on your Mac instead of assuming the version in an application menu, old terminal window, or previous project is the one handling the render.

Before changing settings or installing packages, save:

• The complete render command, including the directory from which you ran it.
• All terminal output, including lines before the final failure message.
• The source document and project configuration as they were when the failure occurred.
• A copy of the rendered files and any temporary output you need to understand the failure.
• The output of quarto --version and relevant environment details.

Use quarto --version to identify the executable responding in that terminal. Then compare your command and working directory with the Quarto render command reference. A wrong input file, a different Quarto executable, or a command launched outside the project can look like a rendering defect when it is actually an invocation problem.

Treat these symptoms as separate cases:

• No PDF appears: identify whether Quarto stopped before document execution, during it, or while compiling the PDF.
• The command reports an error: locate the earliest actionable error in the log. The final failure message may only report that an earlier stage stopped.
• The PDF exists but content is missing or stale: check whether code ran, whether references were updated, and whether a cached or frozen result is being reused.

A minimal document helps distinguish a general toolchain problem from one limited to a particular paper. Create a separate test file with a title, a short paragraph, and the PDF output format. Render it from the same terminal. Do not include confidential research data. If this small file fails too, focus on the environment and PDF toolchain. If it succeeds, the original project contains a dependency or configuration worth isolating.

Keep the original project unchanged until you can reproduce the failure from a copy.

A document can fail before LaTeX is involved. Check the source file, project directory, output format, YAML, filters, and template references. The Quarto project documentation describes how project configuration affects documents rendered within a project. Compare the configuration of the failing document with the settings you expect to apply.

Work through these checks:

• Confirm the input file name and path in the render command.
• Confirm that you launched the command from the intended project directory.
• Inspect YAML indentation, delimiters, and values around the output format.
• Check that every referenced filter, template, resource, or included file exists at the path the project expects.
• Review project-level settings that may apply even when they are not repeated in the document.
• Compare the requested output format with the format Quarto reports rendering.

Change one setting at a time. Keep the original log, render again, and note which change altered the result. If the minimal document succeeds but the paper fails before code execution or PDF compilation, return to document structure and project configuration rather than reinstalling a TeX distribution.

The Quarto PDF configuration reference is the place to verify supported PDF format options. Use it to check the option you are changing instead of copying a setting from a different project and assuming it applies unchanged.

A rendered research document has multiple stages. R or Python code may fail before PDF generation begins; alternatively, code may run and the subsequent LaTeX compilation may fail. The distinction determines which dependencies you should investigate.

Start at the earliest relevant error in the log. Look for evidence that the document execution stage started, whether the failing chunk produced output, and whether the PDF engine began compiling. A message naming a missing package or an unavailable interpreter suggests an execution-environment issue. A message from the TeX compiler after Quarto has produced an intermediate document points toward PDF compilation. Do not diagnose the whole pipeline from the last line alone.

Make a copy of the document and reduce it to a representative code chunk. Check that the document declares the intended execution engine and that its interpreter or kernel is available in the same environment where you run Quarto. A working R session or Python notebook elsewhere on the Mac does not establish that the render process can use the same interpreter, libraries, or environment variables.

Check whether caching or frozen output could make old results appear current. Compare the rendered output with the code and data in the copy you are testing. When you need to determine whether a chunk executes during the current render, use a controlled test that cannot be mistaken for an old result. Avoid changing project-wide cache settings on the original project before you have preserved its state and documented the test.

A useful boundary is:

• If a representative chunk cannot run on its own, investigate the interpreter, kernel, package dependencies, or execution configuration.
• If the chunk runs and produces fresh output but PDF creation stops later, investigate the selected PDF engine and TeX dependencies.
• If the PDF builds but shows old or absent results, verify execution and caching before changing the layout toolchain.

Use these branches after you have a saved log and a minimal test. Choose the first condition that matches the evidence; do not make several environment changes at once.

• If even the minimal document fails before code runs, inspect the command, Quarto executable, project directory, and YAML. Then rerun the test after correcting only the confirmed issue.
• If the minimal document runs but one code chunk fails, test the relevant R or Python interpreter and its dependencies separately. Return to PDF compilation only after the chunk produces fresh output.
• If code completes and the log reports an unavailable engine or a TeX error, confirm the PDF engine Quarto selected and the executable path available to that render. Compare the log before and after a single, documented toolchain change.
• If the PDF is created but glyphs, references, figures, or cross-references are wrong, isolate that content type in a small document. Check font coverage, resource paths, bibliography inputs, and the related processing messages.
• If you cannot reproduce the failure without sensitive data, stop copying real data into test environments. Ask your institution which approved, sanitized sample or isolated environment can be used instead.

Use this comparison to decide what to investigate next. It is not a claim that one engine or TeX setup works for every project.

Quarto supports different PDF engines and documents the available choices in its PDF engine guide. The guide also covers TinyTeX. Do not assume that Quarto is calling the TeX executable you normally use in a terminal, or that the Mac’s default installation is the engine selected by the project.

Read the render output to determine which engine and path were used. You can also check what the current shell resolves with command -v lualatex. That lookup is useful evidence, but it does not prove that Quarto invoked the same executable. Compare the shell result with the render diagnostics and the project’s PDF settings.

The Quarto troubleshooting documentation provides official guidance for investigating rendering and installation issues. Use it alongside the PDF engine guide to check missing TeX packages, engine configuration, and automatic package installation. If you already have a TeX distribution, record its path and state before trying Quarto-managed TinyTeX. Avoid installing another distribution or changing PATH until you know which toolchain the failing render uses.

For a Mac LaTeX error, follow this sequence:

• Confirm that the log reaches PDF compilation.
• Identify the engine named in the log and its resolved executable.
• Read the first TeX error that explains the failure, not only the final summary.
• Check whether the error names a missing package, unavailable font, invalid command, or missing file.
• Make one targeted change, rerun the minimal document, and compare the new log.

A successful TeX compile does not prove that the output’s fonts or research content are correct. If characters are missing, verify the requested font family and its coverage in the actual rendering environment. A font available to a graphical application may not be available to a command-line render. Test a small document containing the affected symbols or language before editing the main paper.

For a PDF with missing figures, check the resource paths and the step that generates each figure. For references or cross-references that do not update, inspect the bibliography input and processing messages. Quarto’s citations and references documentation explains the supported citation workflow. A bibliography problem should not automatically be treated as a LaTeX installation problem.

What should you inspect first when LaTeX reports an error?

Find the first specific error in the complete log, then check whether it names the engine, a missing package, a font, or an input file. Confirm the selected engine and test it with a minimal document. If the minimal file fails in the same way, continue with the TeX setup. If it succeeds, reintroduce your paper’s components in isolation.

How should you investigate missing fonts or characters?

Verify the engine, the exact font family requested, and whether that font is available to the command-line rendering environment. Test only the affected characters in a minimal PDF. Then inspect the generated file to confirm the glyphs appear as intended. Do not infer font coverage from how another application displays the same text.

How can you tell which lualatex Quarto actually used?

Compare the render log’s engine information with the result of command -v lualatex in the shell where you run Quarto. The shell lookup alone is not proof of Quarto’s resolved path. Check the document or project’s PDF engine setting and use the Quarto diagnostics to confirm what the render process selected.

How can you separate an R or Python chunk error from a PDF compiler error?

Identify the earliest failing stage. If the interpreter, kernel, or package fails while a chunk runs, investigate code execution. If the chunk produces fresh output and the log later reports a TeX failure, investigate PDF compilation. Reproduce the relevant chunk with sanitized inputs, and check that cached output is not being mistaken for a new execution.

Once the minimal document works, restore your research project in a copy. Add components in groups: project settings and templates, then code, then figures, then references and font-dependent content. Render and compare after each addition. If the failure returns, you have narrowed the cause without replacing the original project’s evidence or changing several dependencies at once.

Use this acceptance checklist before you deliver the PDF:

• [ ] Record the Quarto version, render command, working directory, and selected PDF engine.
• [ ] Confirm that the code output reflects the current inputs, not a cached or frozen result.
• [ ] Open the final PDF and check page layout, figures, symbols, and font rendering.
• [ ] Confirm that citations and cross-references appear as required by your project.
• [ ] Compare key tables, figures, and reported values with the underlying research outputs.
• [ ] Save the working command and environment notes with the project’s delivery records.

A completed render confirms only that the document produced a PDF. It does not validate calculations, source data, interpretation, or compliance with a journal or university style guide. Those checks remain part of research review and final submission.

If your local Mac repeatedly fails and the project specifically depends on macOS, a separate environment can help determine whether the problem is local to your installation. Use only a sanitized project or data approved for that environment. Before choosing a remote Mac, verify your institution’s data-handling rules and confirm how you will access, test, and retrieve the output.

A Linux or Windows lab machine cannot directly confirm behavior that depends on a macOS toolchain. A second local installation can also leave you managing competing TeX paths and package states. A remote Mac adds network and data-governance considerations, so it is not a fit for restricted data that cannot leave an approved boundary or workflows requiring local hardware access. For a controlled macOS comparison, review CALMVPS pricing and available Mac options, then check whether the access and terms fit your project before you move any files. If the project is stable and needs sustained, dedicated local use, compare rental with buying and maintaining a Mac instead.