I don't know exactly what OverLeaf does. I can confirm that
\scrollmode
\documentclass{article}
\usepackage[utf8]{inputenc}
\begin{document}
\textbf{abc}
\textba{def}
\textsf{ghi}
\textit{jkl}
\end{document}
fails to compile with an error. Initially, I thought that this must be because OverLeaf used the --halt-on-error
option because pdflatex --halt-on-error
fails to compile with an error on the command line, too.
However, changing
\scrollmode
to
\batchmode
causes compilation to merely pause before continuing when compiling locally, even with --halt-on-error
. However, on OverLeaf, compilation still fails with an error.
The log file begins with this:
This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016/Debian) (preloaded format=pdflatex 2016.11.17) 24 NOV 2016 02:33
entering extended mode
\write18 enabled.
file:line:error style messages enabled.
%&-line parsing enabled.
In contrast, compiling locally:
This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) (preloaded format=pdflatex 2016.11.20) 24 NOV 2016 02:27
entering extended mode
restricted \write18 enabled.
%&-line parsing enabled.
The file:line:error style messages enabled.
is just because OverLeaf must pass --file-line-error
to pdflatex
. This doesn't stop \batchmode
continuing compilation - at least, it doesn't do that locally. Nor does adding --shell-escape
which explains the absence of restricted
in OverLeaf's log. (Presumably, they are restricting things globally regardless.) None of this is surprising - it would be odd if these options made a difference. I'm just recording the fact that I double-checked just to be safe.
I'm guessing that some other process is interrupting compilation in case of error, although it is always possible, I guess, that the installation has been modified to do this no matter what. But I'd guess an independent process, since they are using such a process to interrupt compilation in other cases e.g. if compilation takes too long, it will be terminated. So I'm guessing that their monitoring process also stops compilation in the case of error and regardless of anything the user does.
This is only a guess, but, if it is right, then there is nothing you can do unless you can persuade OverLeaf to change the way that process works.
I should say that I'm not at all sure about any of this and mainly post this so that the more knowledgeable may see what OverLeaf is doing and provide interpretation and explanation!
You cannot use biblatex
and natbib
. You can get natbib
support within biblatex
, but you cannot use natbib
. This is independent of the Biblatex style you select. It matters not whether it is apalike
or something else.
Biblatex uses its own interface for formatting the citations and bibliography. It does not use BibTeX .bst
files, which are at the core of natbib
's approach. No BibTeX styles are compatible with Biblatex. They are quite different ways of managing the references and bibliography.
If you want to use Biblatex, you need to stick to Biblatex's interface. If you want natbib
, drop biblatex
.
That is, the best practice when using natbib
and Biblatex, regardless of style, is
Don't!
Best Answer
There are two things causing errors:
In the
center
environment you have an opening brace ({
) without a closing brace. As it stands, you can just remove that brace.titlesec
is apparently not compatible with the KOMA-classes. I don't know if there is a way to use both, but the simplest solutions is eitherRemove
\usepackage[clearempty]{titlesec}
, orUse
book
instead ofscrbook
.In addition, Overleaf doesn't seem to be able to deal with
biblatex
. Removing that package, and it compiles fine. This is a bit strange, considering thatbiblatex
isn't used at all, and there are no errors in the.log
file or the.blg
file. I have no idea what's going on, at the moment. Even this minimal file makes Overleaf throw an error, even though there is no actual error:I sent a message to Overleaf about this.