That’s a good question, and one that has a few different answers, depending on exactly how you would like to approach using Scrivener. I don’t believe it has been asked yet in the context of Scrivener 3, which changes things considerably for the better for those working in some form of markup. While on the surface it may seem like a program aimed purely at the Word and self-pub crowd—we in fact put a lot of time and effort into its technical capabilities.
While I do not write in LaTeX directly, it is something that I make use of through the use of generators (via Markdown). The important thing is that I’m in the same rough category as you are in that I don’t want to use Scrivener for its formatting features per se—I use it more like a glorified text editor, and in my opinion there are few downsides to doing so. The main one worth mentioning is a lack of syntax highlighting and typing aids—stuff you might appreciate as a TeXstudio user. Depending on how you want to approach things, that may not be as big of a drawback as it might seem at first.
So here are some rough directions one could take:
Using Markdown
We might as well get this one out of the way. Scrivener integrates directly with MultiMarkdown to produce .tex files from rudimentary and simple to work with extended Markdown. It also supports custom post-processing, meaning that if you prefer another system like Pandoc, it would be simple to set up the compiler to integrate with it (or indeed any system capable of automation via the shell). While Markdown syntax itself is fairly limited to the basics, it is pretty easy to do whatever you want in terms of inserting raw LaTeX that bypassing Markdown processing. To get an idea of what is possible, have a look at our user manual from the Help menu. That is 100% Scrivener/MultiMarkdown → LaTeX. I only have to do one thing outside of Scrivener before generating a PDF: compress the source graphics for download quality.
Downside is, if you’ve already got a lot written in LaTeX syntax, it’s not a straightforward process to switch over to Markdown. With source material that isn’t too complex however, a few search and replaces might sort out the bulk of it.
Upside is that Scrivener can handle a lot of busy work for you. Headings, footnotes, figure management and even optionally more complex structures like tables and lists can be converted to Markdown, and then from there to LaTeX.
For Pure LateX
As you know, .tex files are just text files, and raw text can be typed in just about anywhere a keyboard inputs letters into a window. You certainly don’t need anything fancy, and Scrivener serves as a good enough host for raw text as most text editors—and in some ways it works better. For example, in a regular old text editor you usually can’t highlight an arbitrary sentence for editorial purposes, or attach a comment, or build a network of useful hyperlinks that help you get around in your own work. But if you prefer not even these tools, an easy way of working around the syntax highlighting issue is to simply use Scrivener to store the milestones and copy and paste back and forth between your favourite editor to the the actual typing. I worked that way for years, before settling on preferring the rich text features enough to make that workflow less viable. But that’s one way to take advantage of a well-modded text editor while still benefiting from what Scrivener gives you for the bigger picture. For some things it is just easier to do things that way (I’d imagine equations might be one of them).
The basic idea here though is that Scrivener’s compiler will strip the raw text out of the editor and glue it all together into one long .tex file for you. Being able to break down a long document into a detailed topical outline is useful no matter what method you use while typing. I know people that use Scrivener to compose raw HTML, XML and yes LaTeX as well.
Text with Benefits
Aside from the editorial features mentioned before—inline annotations and using italics as informal (output invisible) markup, etc.—Scrivener can do a lot by way of functional markup as well. It’s not going to be as pure of an experience as LyX might be, but think more along those lines—where what you’re looking at in the editor while you write is a balance between aesthetics and semantics. You might set a heading style to some text, not with the idea of making it look the way it will in PDF, but so that the text is styled and can be compiled with \chapter{Blah} printed around it.
Styles are only one way in which the compiler can help you scale back how much syntax you’re typing and reading around. In terms of generating container code to be applied to your outline semantically, it can do quite a bit within the structural realm as well.
- For example, instead of styling a header in the editor like that, you can have the outline headings themselves generate LaTeX syntax using compile Layouts. These layouts can have prefix and suffixes themselves, giving you the opportunity to insert environment stuff around the text they’ll be printing—for example creating an outline node in Scrivener with a “Sidebar” type could be applied to a Layout template that inserts \begin{marginpar} and \end{marginpar} around the text.
- Separators can insert code in between sections conditionally, making it possible to build larger structural blocks out of a sequence of smaller outline items, insert page break or other flow control, start and stop multi-column treatment, etc. etc.
- Overall document prefix and suffix can be added, for your preamble and footer.
- The Markup preference pane will be of huge benefit if you want to turn hyperlinks, simple italics and images in the editor into LaTeX.
Overall, we made it a point to make sure Scrivener’s .txt support was robust enough to handle the creation of a valid XML file without any post-processing or fixing up post-compile. Given that XML is even stricter than LaTeX, you should have no problems building markup with the system.
I don’t know if I’d call it easy, it’s the kind of thing you’d have to invest a good bit of time into developing the workflow initially—but once you do develop it, then it does get easy. To again refer to the user manual: the compile settings for that project probably took all together two or three weeks to put together. I didn’t do it all at once, I’d add features only as I needed them spread out over the course of the writing process—but the point is at this point to generate a PDF I only need to do two things: compile the .tex and then typeset it (and yes, compress the images). I can’t even bring water to a boil in the amount of time it takes to spin off a distribution-ready PDF. It may have taken some effort to get it that way, but at this point, it’s easy.
A Little of This and a Little of That
As you can probably tell, all of the above is rather fluid. You could for the most part take things very simply and just treat Scrivener as a plain-text handler with an extremely basic compile setup that takes five minutes to put together—and for a little spice you could add one style that makes your life easier and puts a paragraph into a quote environment. You don’t have to entirely discard the concept of a purist workflow if you design a simple Layout that prints “\chapter{” and “}” around the binder name for the types of outline items that use the layout.
Start simple, and incrementally add what makes your lifer simpler, and I think Scrivener do well for you, no matter what level of involvement you wish to take it to. From something that merely stitches 500 .txt files together into one and calls it .tex, to a complex engine capable of taking what looks like a word processing environment, turning it into a .tex file, Bibdesk integration, typesetting it and uploading the finished and typeset PDF automatically via FTP the uni servers. With its broad support for markup generation and programmable back-end, there are few practical limits to what it can do.
That’s all a rather high level overview of the basic capabilities. Let me know if you have any specific questions about implementation and capabilities.
