User Manuals & Print
@ptram: I wouldn’t have particular problems in using LaTeX, since I’ve started experimenting with it decades ago. The real issue is that I’m not particularly convinced by the appearance of projects made with LaTeX. It is perfectly appropriate in some areas (mostly academic), but I feel it might be less convincing for a commercial product. So, I would like to explore alternative routes.
On that, just in case it isn’t known, the Scrivener manuals are LaTeX. I do agree with you that most of the stock looks are very academic, as you put, which is appropriate for how it is used most often. But is quite flexible and I don’t know if there are too many things a GUI-based system can do that it can’t. I would say the difference between LaTeX and traditional DTP is more a matter of how one accomplishes the result, one being very visual and the other being not visual at all.
There are pros and cons with either method—you’ve mentioned one of the cons with visual editors: large works can cause instability and slowness. The Scrivener user manual on the other hand is not small, but it typesets to PDF without any intervention in around 15 seconds for the first run, and 5 seconds for incremental updates in proofing.
Oh, no, just asking the best it can do for me! All considered, L&L themselves have shown that you can go past the initial goal (drafting), and made their own manuals with Scrivener.
I use Scrivener for what it works best for: building structure, or for how Markdown+LaTeX works, building instructions. You mentioned the chapter pages for instance, which for me are just the name of a binder item at level 2 in the draft folder. I do nothing more than that while working, and I don’t see or work with any of the following text examples while working.
When compiling, Scrivener turns this into a simple Markdown level 2 heading:
## Interface in Overview
For how I have things set up, level 2 headings like this are chapters, so we get:
\chapter{Interface in Overview}
\label{interfaceinoverview}
So from that you get the full-page spread you see. As you can see, it is still about as abstracted from the final result as the implementation in Scrivener! It takes the name of the chapter and puts it in a text box in the upper left corner, and then takes the automatically generated number and puts it in a lower-right text box.
That all said, the way the user manual is put together does not require LaTeX. That’s 100% the compile format that I’ve built for it. I could turn around and develop and ePub format for that same project, or even InDesign! Again we are using Scrivener for its primary strength of producing structure rather than formatting, and structure as we can see from the above examples, is very far away from formatting. Markdown takes that structure it creates and turns it into document formats suitable for formatting, be that .tex, .epub, .odt or .icml.
Oh, no, just asking the best it can do for me! All considered, L&L themselves have shown that you can go past the initial goal (drafting), and made their own manuals with Scrivener.
To come back to this sentiment then, knowing the above, I wouldn’t say so much that I’m pushing Scrivener past the drafting phase—it’s more that the system I’m using with Scrivener greatly broadens the definition of drafting. I can get that user manual PDF by clicking the Compile button, but that’s not because Scrivener has anything to do with the PDF, rather it’s using a system that is really good at making PDFs, and is really good at taking structured text, from a system that is really good at producing structured text. It is in my opinion the ideal approach because it meshes a lot of mutual strengths.
You could take that approach and end up with an ICML file, yes, and with tweaking you could probably get pretty close to a “one shot” InDesign workflow that requires very little work after compiling. It’s not something I’ve ever tried myself, but knowing the extent to which this system works well for me with .tex files, given how it works, I feel it would have plenty of capability and flexibility.
While editing the raw image with dedicated editors, there are things that are more comfortable to do in the layout program. Take the shadow again: by adding this property to an object style, you can the make it lighter or darker en masse for the whole publication.
I would not say that’s a characteristic that is unique to visual layout programs—rather it’s just one of the thousands of reasons why Scrivener is not a production tool! We can after all get something like that in ePub with a very simple declaration, pasted into your compile Format’s CSS pane:
figure img {
box-shadow: 6px 6px 15px rgba(0, 0, 0, 0.42);
}
Done and dusted. Maybe you want it to be fuzzier, so you change it from 15px to 25px, and the whole book updates. You have the same kind of power with LaTeX too, of course.
But with Scrivener by itself, using no other technology and trying to replace an entire workflow? There is nothing for that, and I don’t know what it would take to make that efficient.
ePub
So speaking of CSS, and to return to something you mentioned in the first post, I think maybe we are getting hung up on the PDF a bit much, and the technology that goes into making those. For print (or digital similar), I would not ever consider using Scrivener for production. It is to my mind uniquely unsuitable for that task, while it is uniquely amazing at working with tools aimed at production. It’s a quintessential early link in the chain, not the chain—and whenever I see people trying to make it act like the latter, it seems to produce nothing but frustration (much like writing a book in InDesign itself must surely be a nightmare, I just don’t understand why anyone would try so hard to avoid using the best tool for each aspect of the job).
For ePub though, this is another matter. Ebooks do not have a very high bar when it comes to production because there is no production to speak of, from the creation side of things, outside of the manual and technical labour of assembling HTML, CSS and a few simple XML files. That part of the job is so simple that you can create an ePub file with nothing more than Finder and a coding editor.
So for that, Scrivener does quite well, not only because it is a simpler matter to produce an ebook, but again because it is really good at creating structural stuff: and ePub is all about structure.
Would I use Scrivener’s built-in ePub generator? No, mainly for these reasons:
- I prefer writing using Markdown in general, to messing around with palettes and toolbars.
- Scrivener’s ePub production actually converts the rich text source to Markdown, and then uses that to generate the HTML. So why would I rely upon machine conversion to produce source I can get just by typing? I would have to really prefer clicking on toolbars to take that approach.
- The compiler has integration for Pandoc’s ePub generator, and on the whole I would say the quality of it is cleaner and less “quirky” than the complexities that come from all of that machine-generated output. I’m not ever going to get a
<span style="color: #351799ff ">Blah blah</span> in my output, unless I myself create such a thing, whereas with Scrivener native I might very well get that and struggle to override it simply because that’s how I chose to depict some text in the editor.
Pandoc’s ePub generator takes a little more work up front, and it doesn’t have Scrivener’s CSS-generator front end that is essentially the majority of the compile settings—you have to know your CSS design to get a good result. But if you do, then having direct control over the result rather than “fighting the GUI” (how it feels for me), is preferable.
I would stress though that either Scrivener’s ePub or Scrivener+Pandoc’s is going to be great, and you will be hard-pressed to find a better ebook production platform anywhere. There are easier ones for sure (typically at the expense of flexibility, with template-driven stuff), but if you’re serious about making the best book you can, and are willing to invest time into learning HTML/CSS to do so, either of its routes will be deeply rewarding.
Also, I will sooner or later output as webhelp. How is it HTML5 export, in Scrivener?
It doesn’t. 
See the bullet point above: we use MultiMarkdown to generate the HTML for ePub3, because the Mac’s HTML converter is stuck in the year 2002.
.