You mean MultiMarkdown > PDF? What does the log show:
Show pdf log ⟨Direct-sale only⟩ When using the mmd → pdf conversion option, this
option will print the LaTeX log ﬁle that is generated when typesetting the document.
Use this to help locate and ﬁx problematic formatting, ﬁgure out errors that block
output and so forth.
It is not entirely clear from the manual that only pdflatex is used, the first reference is:
Using the LaTeX typesetting engine, produces a simple ready-to-print pdf ﬁle. This
option will not appear unless pdﬂatex or xelatex has been installed on the system. It
will not appear at all if you purchased from Apple’s Mac App Store. – TABLE 23.2
I would argue that xelatex should be the default and pdflatex only used as a fallback. Though even then I cannot see how only pdflatex would be installed; even the minimal TeX installers like BasicTeX or TinyTeX include xelatex and lualatex engines…
Actually, no, I was thinking to the direct PDF compile option. By collecting information from the manual and the forum, I had inferred that this option uses pdflatex as the print engine.
In general, I think I understand that pdflatex is the default engine for Scrivener, but you can install other options, including xelatex. If wanting to go the MultiMarkdown > PDF route, one should indicate the engine in the Processing pane or the compile format.
According to an answer you gave for the Pandoc route, I guess the arguments should be -t latex --pdf-engine=xelatex, but I’m not totally sure about it when going the MultiMarkdown way.
It seems it uses pdflatex, instead. At least, this is what I read in the Scrivener manual:
Since Scrivener uses the latter [pdflatex] for its direct-to-PDF option
That’s interesting, because it would offer a different output type from the Apple Print dialog.
To put things in perspective, the above citation comes from this longer passage:
For Best Results, use XeLaTeX
This design makes use of system fonts, and as such it will look much nicer when typeset using the XeLaTeX engine, rather than pdflatex Since Scrivener uses the latter for its direct-to-PDF option, it has been set up to handle non-system fonts as a fallback. It will also use a standard three- asterisk section break instead of a Unicode glyph, in this fallback mode.
I think Mark is right, the standard default PDF output does not use LaTeX. The bits of the manual you are referring to is the MultiMarkdown chapter, so indeed this has to use LaTeX. I do agree this distinction was not not entirely clear me from the manual…
Yes for Pandoc that is correct, and I don’t know how you can specify which engine to use when using the MMD ⇨ PDF, the compile options don’t seem to include that and you can’t access to post-processing pane like you can for plain MMD/Pandoc; I’m sure @AmberV will enlighten us as to where this is specified for MMD ⇨ PDF, and also why xelatex isn’t the default…
On page 598, where it comes under MultiMarkdown Conversion it says “This option will not appear unless pdflatex or xelatex has been installed on the system.” and your quote is from page 866, at the end of D.6 MultiMarkdown LaTeX and PDF. D 6.5 is Modern (Custom LaTeX), which it says is based on the “Modern” compile format for RTF. The note you quote explains why “Modern (Custom LaTeX)” can use system, ergo TrueType, fonts.
Now, maybe that is where you’re at, but if you choose “Compile to: PDF” at the top of the dialog, MMD is not involved at all and I’m pretty sure it uses Apple’s PDF layout engine, so users who don’t use MMD, can compile to PDF without having any LaTeX engine installed.
This isn’t an MMD behaviour we are triggering, but rather Scrivener is handling the LaTeX workflow directly. We look up where pdflatex is located, generate the .tex file from the .md output, and then run it through three times.
I do agree that at this point in time it would be safe to switch to using XeLaTeX, and probably latexmk at well to step back from handling the nitty-gritty details. I think most distributions these days have both of those tools by default, and those that don’t probably would throw missing package errors all over the place from the stock boilerplate MMD stuff anyway.
I’ve got it on my list to have that adjustment made at some point. In the meanwhile, as I say in the manual, the PDF option is generally only useful for quick and dirty proofing anyway, and then only for relatively simple documents that do not need additional processing done for bibliographies and such.
If it doesn’t work, just compile to .tex. With LaTeX Workshop in VS Code all properly configured you don’t even have to do anything yourself. It automatically detects the .tex file being modified and rebuilds to PDF in the background. If you have your PDF reader open already, and it’s a reader that can detect disk changes, you’ll get an updated PDF in the same amount of time it would take for Scrivener to orchestrate the whole thing itself, anyway.
I don’t think there is any one single preferred way, nor one objectively best way. Use the Processing pane with the “MultiMarkdown” option, or the method I described with a secondary stage so you can have the .tex and .log file to work with as well, or live with pdflatex issues and limitations. They all have their pros and cons. I prefer a secondary tool because it’s a million times faster to typeset a typo out from a .tex file than it is to recompile from scratch. Compiling is almost always the slowest part of the process.
I very much second @AmberV’s approach. I think having the .tex file and just running the final step from there allows you to fix any LaTeX problems much more quickly. You could automate this with a small script as needed…
To add to the panoply of options for producing a PDF, there are differences between using MMD⇨LATEX directly, or using the Pandoc-mode of MMD and then using the post-processor with Pandoc (or even Quarto, a Pandoc derivative). The benefits of MMD⇨LATEX I think are the fact the compile format includes the LaTeX template in the UI (keeping most of the tweaking inside Scrivener) and its relative simplicity.
The benefit of Pandoc involves the greater flexibility through the use of a templating language via metadata and things like document filters and other tweaks that can be applied. Pandoc also enables you to use other PDF generation engines like ConTeXt, or even using HTML+CSS publishing engines like PrinceXML or PagedJS…