Error in rendering LaTeX -> PDF

LaTeX newbie question…

I was trying out the sample project that Ioa uploaded to this thread: … 21&t=53144

TeXShop is giving me the following error (which I can’t copy as text for some reason):
LaTeX Error.png

I’m running Scrivener 3.0.3, and have installed pandoc- (though it appears I didn’t need it for my current attempts).

Any clues as to why I’m getting this error? I get a similar error for any project I try to compile using MMD->LaTex, and then press “typeset” in TeXShop when the raw LaTeX loads into its editor.

Edit: I discovered through my research that I’m running MacTex 2017, and am now in the process of downloading MacTex 2018. I’m assuming the issue is that the Tex install is out of date, and working from there. My wifi here is extremely slow, so I may not find out if this fixes the issue for a couple of days, so if you don’t think the version is the issue, or if the latest version may not be compatible with Scrivener, let me know.


Not a bad idea to update to the latest TeXLive, but I think in this case it’s a simple matter of the document class you are using not having a designation for “parts”. The signifant wording is: “Undefined control sequence”, which is LaTeX’s way of saying “Bad command or file name”.

On the MMD side of things, adjusting the “Base Header Level” metadata key to “2” or greater is usually the best way to handle the problem. That will cause level one headers to functionally act like level two headers (and on down), and print themselves as \chapter instead of \part. Check the compile metadata tab in my example project to see where that key goes. I boosted it to 2 as I didn’t want parts in the example.

Of course if you actually do need parts, then it would probably be best to switch document classes.

To be clear, I got this error with your (unmodified) sample project… so unless you attached a version without the base header level set to 2, or unless I need to do something other than just hit “compile” to make it work, then the issue must be with my setup.

Strange, I just double-checked the attached download and it is definitely set to Base Header Level 2, and when I compile it I get:

\chapter{Single Column Chapter }

So that’s one weird thing. The other weird thing is that I definitely designed a part page for that format (I just changed the header level out of taste, not necessity). There shouldn’t be any errors for that reason alone.

After attempting (with many distractions… my life is full of them these days), to uninstall pandoc and MacTex (including library files), and re-installing the Scrivener package (without messing with settings files at all), I’m experiencing the same issue.

I just tried editing the compile preset that you used (modern 2-column layout), making it support MMD (just checking the supported file type). The result is maybe useful.

[code]Title: Multicolumn Example
Subtitle: Pure Scrivener Goodness
Author: AmberV
Base Header Level: 2
Base Header Level: 1

Single Column Chapter

Dri srung gronk ozlint; zeuhl la, ti dri. Relnag xi nalista dri lydran wynlarce, prinquis zorl nalista, zeuhl re obrikt relnag erk wynlarce wex pank gronk…[/code]

So, maybe the issue is that Scrivener is inserting two “Base Header Level” directives? Would that cause this error?

I’m at a loss as to what to do; I created another Mac user account, downloaded the .zip of your sample project, and got the same issue with baseline Scrivener & LaTeX settings, so my problem is system-wide. If this is an MMD issue and not a LaTeX issue, then it must be a broken installation of pandoc, right? How can I determine if Scrivener is using its bundled MMD install versus an externally installed one?

Edit: Okay, I’ve tried running “multimarkdown” in Terminal, and it’s coming from /usr/local/bin/. This must have come from my recent pandoc install. Unfortunately, whenever I search for “uninstall pandoc”, I get posts linking to a perl script that errors out (404 not found). I guess I’ll start digging into that script to see if I can just manually delete all the files installed by pandoc. Any tips would be appreciated.

Okay, so the pandoc installer doesn’t install a multimarkdown executable; it’s just these files (fyi, if you download a .pkg file and start it up, CMD-i will show a window that contains a list of files it will install.

. ./usr ./usr/local ./usr/local/bin ./usr/local/bin/pandoc ./usr/local/bin/pandoc-citeproc ./usr/local/share ./usr/local/share/man ./usr/local/share/man/man1 ./usr/local/share/man/man1/pandoc-citeproc.1 ./usr/local/share/man/man1/pandoc.1
I assume that Scrivener doesn’t install “multimarkdown” into /usr/local/bin… Maybe I did several months ago? I must have, because after trying the above trick on the multimarkdown pkg installer, it appears that it installs the following…

./usr/local/bin/mmd ./usr/local/bin/mmd2all ./usr/local/bin/mmd2envelope ./usr/local/bin/mmd2odf ./usr/local/bin/mmd2opml ./usr/local/bin/mmd2pdf ./usr/local/bin/mmd2tex ./usr/local/bin/multimarkdown

… and after I moved the above files to a backup folder, Scrivener compiles a PDF correctly!


Okay! From that description it sounds like you had installed your own copy of MultiMarkdown some time ago, and it was handling this quirk in an unexpected fashion. Here’s how all of this fits together, by the way:

  • Scrivener has a copy of MultiMarkdown (v6.3.2) embedded within its .app bundle. For anyone that does not have MMD or Pandoc installed, that means they will get the basic “MMD→X” options listed at the bottom of the Compile For menu, no matter what. This is also the full extent of what Scrivener can do for sandbox-limited users.
  • When you load compile, Scrivener does some file system checks:

[list][*] Does it look like you have pdflatex installed somewhere? If so: then add the MMD→PDF option to the Compile For menu.

  • Do you have your own copy of MultiMarkdown installed? If so, switch off usage of the internal version and use the installed version instead.
  • Do you have a copy of Pandoc installed? If so, add all of the Pandoc→X options to the Compile For menu.

Theory aside, this illuminated a flaw in the built-in Modern format! It definitely should not have a “Base Header Level” metadata key saved into it. I think I had that in there when I wasn’t sure if I could get the Part pages looking the way I wanted, and then isntead of taking it out I set it to “1” once I got them working. Oops!

Perhaps the version of MMD you had installed was old enough that it handled duplicate keys differently from my system, and that’s why we were getting different results from the same output.

Well, I’ll have the format itself fixed for 3.0.4 (as well as the Markdown Outliner format, which also has a baked in Base Header Level).