Thank you for the suggestion! I think that would also be good step to ‘update’ the old file formats for archival purposes too? Anything that can combine or save a step in my mountain of things to do is a huge bonus!
Scrivener’s compile feature is full featured and before assuming you can’t do “complicated formatting”, best to learn more about compiling. There are some really good books available, along with the Scrivener User Manual. Before going much further and doing a lot of posting here, get one or two of those books and start writing and compiling. Get some experience with the tool, or pick another tool to get some experience. Focus.
I think you will find that styles are not that important in Scrivener, say compared to Microsoft Word. Minimise the use of styles and let the formatting be controlled by the compile settings.
Just to clarify - my reference to styles & sections was in reference to the compile settings, not character/paragraph. One thing I have learned is that WYSIWYG is NOT what I’m going to get with what I am writing, linking, including, and citing. I use “no style” as much as possible in that respect. I do have experience with compiling but not in v.3, and not with a lot of the technical details I’m including now.
As far as complicated, I do believe I have already done due diligence reading up on what I can and cannot do strictly within Scrivener alone, but if my conclusions are wrong, I’d be more that happy to hear it! The following is not MY idea for my ultimate output, but is an industry standard I am conforming to.
My “complicated styles/formatting” includes
- multiple numbered diagrams, figures, charts, maps and images in multiple formats along with their re-sizing, layering, placement.
- many of the non-text items will need to be annotated with sources or credits. Some will need details highlighted in some manner. Of course, all references to them will be links in the manuscript (which I think markdown can handle).
- several hundred sections that require a very specific tab/indent? combination. At it’s most basic, they are numbered lists with heading(s) which include a numbering system that combines I II III, 123, i ii iii, and ABC/abc. Some levels must be in italics, small caps and/or a different font size. Occasionally, there is another sub-heading within the numbered list.
- in the same sections as these lists, the (margins?) of the numbered lists also contain two additional (columns? for lack of a better term) to the left and one to the right that may or may not cross-reference other numbered sections of the text (preferably automatically). Occasionally, this font will be a different font size from other text in it’s section, depending upon which level it appears in. (All the numbers in these three columns remain the same size throughout regardless of the font size/italics/small cap used in the corresponding numbered list level.)
- extensive footnotes to appear on the same page as the assertions
- a TOC, bibliography, and an extensive Index (plus optional appendixes)
- most important, I will need to be able to output these “numbered lists” to the Word “Normal” template for the Historical Society publication, as well as pdf, ebook, and a more formal hard copy yet to be decided.
If I can do all this solely within Scrivener, PLEASE point me in the right direction!
Right, this is an important distinction you have discovered. Styles for formatting are totally optional, BUT styles for semantic structuring is essential for more complex projects like yours. The way to think about this is: Section Types are larger blocks of identified “stuff” you may need to move around in terms of outlining. Paragraph styles are smaller semantic blocks of “stuff” you may move around less, and inline styles are semantically identified word runs of “stuff”. You can make them look distinct in the editor, but the major point you have identified is as a way to structure work so the compiler can hook into them.
There is absolutely no markdown in Scrivener for most markdown workflows either — both types of templates do the work in the background. I think the LaTeX template is brilliant and works well [EDIT: when you know you will only ever use LaTex for final output]!
The LaTex template uses both styles (equations, lists and the like) and section types (headings, appendix etc.) to convert semantic intent to structured LaTeX. Without styles and section types these templates (whether direct LaTex or markdown) would not be viable…
Thank you nontroppo! Your ‘technical’ descriptions of ‘stuff’ made me chuckle, and certainly helps to ‘define’ that stuff in laymen’s terms.
I often think of the semantics like I do a collection but in reverse. Hmm, what does all this ‘stuff’ have in common, is it level/outline specific, and should it all look the same in the final output? Is everything a header at the same level in the outline of: the series? one of the books? a part, section or subsection? Is this a group of all text in the default paragraph style with no special anything? Is everything a transcription that must pass through to compile as-is? etc. etc.
If only my crystal ball wasn’t out for repairs.
Well, not my experience. My deliverables (which tend to be >100 pages or so) are LaTeX → PDF, but in Scrivener with same project, can change output to other compile output formats and filetypes (PDF, DOCX, RTF, etc.) and seems to work. Often use PDF’s for drafts of parts of the deliverable for review by others. I can look at the other methods in due course.
Good to know, that is a testament to Scrivener’s flexibility (or your ninja-skills in the compiler
)…
What I take from all of this is the importance of having a clear, hierarchical, Binder set up. Yes, you can move things around but whatever you use in the end to get your stuff out there—LaTex, Typst, Quarto, RTF, DOCX, PDF—if everything is organised clearly and meaningfully in the Binder, it is fairly easy to move between output tools as @rms points out. In a way, Scrivener 2 (1.x on Windows) experience is useful as it forced this on the user, where Scrivener 3 is much looser for RTF/DOCX/PDF compiling, as Section Types+Section formats is more agnostic when it comes to Binder hierarchy.
To that I would add the suggestion that when it comes to Binder documents, keeping them as small as makes sense uses Scrivener at its best; particularly tables, diagrams, images, etc. all going into their own Binder documents.
So, apart from getting your old documents into RTF or other usable format, I’d be thinking about how to best structure the Binder. Get that right and then you can give your mind to output tools later.
Mark
More a usability aspect. It’s a web-based database, and I personally have trouble finding what I want in it, as the way it’s organized doesn’t seem to work well with my brain. It’s usually not that the info isn’t there, but it never seems to be under the topic I expect, and I have trouble finding search terms to display the info I want.
Probably will work for you then. The only real problem I’ve had was getting an old-fashioned “.doc” (as opposed to the more modern “.docx”) in and out. Can’t really blame it for not supporting an obsolete format… But it will export as either .docx or (if I recall correctly) .rtf, one or the other of which should work with Scrivener just fine.
This sounds like a case of great minds think alike… I have the exact same problem with web-based help! (This will be good to keep in mind) Thank you Silverdragon!
Thank you Mark. That is something I have also come to the conclusion of. I generally do have very short docs with one cohesive element. They are seldom more than a page or few. I hadn’t thought of putting all the non-text ‘stuff’ in their own docs until this discussion, but now I see several benefits of doing so.
Absolutely! Getting the structure right for multiple outputs has been foremost in my endeavors. I have some tweaking to do with some older structure stuff, but I’m pretty confident that I’ll be able to bring the old docs in and drop them right where they belong.
I have a much better understanding of where that should be now.
I want to say THANK YOU! to everyone who put in their 2 cents here. Y’all have really helped me wrap my head around where I’m at in the process and on a number of different levels. I truly appreciate your time, knowledge and willingness to share.
LibreOffice vs Word
To give a disclaimer, I haven’t had a copy of MS Word installed anywhere since around 2012. That said, I’ve heard a lot about Word in its present state, have looked up how to do things with it, and I know some of its technical limitations from the angle of .docx production, so I know a little—and of what I know, I would say to that main point of your question: LibreOffice at a conceptual level has the objectively superior and easier to use model for document design and production automation in conjunction with tools like Scrivener.
You can certainly get to the same point with Word, but it will also probably require programming macros to avoid a lot of manual post-compile labour. This is of course how the pros do it, and how they get an author’s manuscript into InDesign or whatever is used to make the actual book. The question is whether one as an individual wants to try and replicate such an industrial-strength process for themselves, when there might be something orthogonal to that that is easier to learn and implement.
So to summarise why I’d say it is better for the typical author: the way in which it works is highly compatible with what you can produce from Scrivener, and is a better platform for post-compile production and design (in that, with a carefully prepared workflow you don’t have to do any work to get gorgeous documents Scrivener cannot make, which is ordinarily the kind of thing mainly Markdown users enjoy).
My criteria there is a bit biased toward “best practice” document design, I will admit. Thus, when I say LibreOffice’s model is superior, from that context, it is because of these three words: stylesheet driven design. It is by far the best mainstream word processor I have seen for being able to design a document from top to bottom with stylesheets. What that means in practice for a Scrivener user is that what you need from the compiler is far simpler than what you need for Word, which is not very stylesheet driven.
With LibreOffice you can push all of the design over to LibreOffice, and can invest your learning time on a system that actually does a lot of layout-oriented stuff, rather than one that does a little bit, and often not terribly well. Here is a post that goes into a little why this is a good way to work, and here is another that discussed the practical application a bit further. There are posts further down as well for context, as it was initially misunderstood that I was advocating one compile and then spend hours changing settings in LibreOffice every time. What makes LibreOffice so good with Scrivener is that you don’t have to do that.
LibreOffice works a bit more like a desktop publishing tool, in that it has page styles. The header and the footer, whether the section starts on the left or right page in the book, even the shape of the paper—all of that is governed by the document’s stylesheet. But what makes that special is that text styles can trigger page styles, which is the secret sauce that makes Scrivener and LibreOffice good companions.
In practical terms, that means a level one heading, as compiled by Scrivener, when dropped into a prepared LibreOffice document can go on to trigger a page style, which will declare it should have a page break, starting on the right side of the book, suppress the header and use an alternate footer (just to list a few common desires—we could also draw a box around the page or swap to landscape orientation or any number of wild things). This page style itself can then trigger a different page style following it, probably a “Left Page” style, which in turn triggers a “Right Page” style following it, and so on, for alternating header/footer/offset margin layouts and so forth.
With a setup like that you can get a nearly complete design almost straight out of Scrivener, doing things Scrivener cannot do itself, by doing little more than using styles properly in Scrivener. When working that way, one uses a much smaller subset of the compiler, and rather doesn’t care much about what the styled text looks like. LibreOffice will be taking over all of that, from page numbering to chapter/section numbering to the way different paragraphs look.
From what I understand, Word requires one to be much more heavy-handed when it comes to things like that, and it is more difficult to get a “best practices” document straight out of Scrivener because to accomplish that the only good way of doing so is with manual labour (or again, macros).
You will for instance primarily be interested in learning styles, section types and layouts. That’s about it! You will have no need for separators and will want to turn them all off. The Styles pane in the format designer will largely be used to create a list of names that you use in Layouts to create “Heading 1”, “Heading 2” and so on structure. The Page Setup area can and should be zeroed out. Like I say, you’ll be learning a subset of what Scrivener can do, because less is more in this workflow.
Incidentally, Mellel is a lot like this as well. However it is Mac-only. There may be other equally stylesheet-driven tools out there, but I would bet most aren’t free or cheap, and most in that category will be industrial-strength stuff like InDesign and Affinity Publisher.
And I couldn’t let a post go without saying that realistically that is a better target than any word processor, which like Scrivener, are also writing tools, not book-making tools. But, LibreOffice is closer to a book-making tool than any word processor I’ve seen, and its PDF output is probably acceptable in terms of typesetting quality.
Markup vs GUI
Since it was brought up, for systems like LaTeX vs word processing, which includes other markup systems to be clear, I think the main difference between the two could be best summed up by putting it this way: how do you best learn how to use software?
If you prefer software that puts all of the possible options in front of you using a graphical user interface, then systems like LaTeX will probably be frustrating to learn. But if you’re like me, and you find wading through tabbed dialogue boxes to be annoying and find it easier to just search for the right ‘command’ to type into the top of your document to make your footnote numbering different, then stuff like LaTeX will not be so bad to learn.
Either way, one will expend a lot of effort learning these systems. They are all complicated because they must address almost everything people need to do. They just express their complication in different ways, and are more or less conducive to different personal preferences.
That said, one needn’t conceptualise all of the markup realm as being so difficult as LaTeX. There are great alternatives to that system out there today which also follow the same rough ideas of using marked up text to generate formatted output, rather than learning layout software to do that in a visual environment. Some are even based on HTML and CSS principles, which are easy to learn and something not unfamiliar to many (certainly anyone who has tried to make an ebook should at least know a little of that). Some systems, like Quarto and Pandoc, make it possible to tap into more difficult systems like LaTeX without having to learn much about it, and by using a much simpler form of markup.
It can be an interesting and rewarding path, and given how the workflow to get there involves plain-text files, it is often more conducive to automation than the graphical path, which more depends on developers making good import/export code and so on. But again I would only recommend it if you like the premise itself, because honestly that’s probably the main appeal to using such systems in the first place. The capability comparisons are otherwise fairly even. There are publishers that use graphical workflows and publishers that use plain-text workflows, like DocBook and LaTeX.
Holy cow! I was happy that Libre was compatible in general with Scrivener and could convert my old file formats. I had no idea it played this well with Scrivener!
I initially was only considering how I could incorporate non-text images, TOC,s, and indexes. I see I wasn’t thinking big enough.
These capabilities… I can certainly see this as a “simple” way to produce all the “little” bits, books, and articles on a much quicker timeline from within the big project as it doesn’t include the added headache of learning new language(s).
Learning the interface… Yes, but that is a whole lot less daunting than learning anything in a foreign language.
Thank you once again for adding a whole 'nother dimension to the workflow possibilities!
{Now to check out your links and get back to the manual… )
Does this only function with text styles? Or can paragraph/list styles also trigger page styles?
Ioa, could you explain what you mean by “dropped” please?
Does this mean that one would compile the draft to odt then apply the Libre template/stylesheet? Or would I copy the compiled odt and paste it into the prepared Libre template/stylesheet?
You can see what I am talking about in the Edit Style dialogue of LibreOffice. Right-click on any paragraph style, and select the Text Flow tab. Under the section on “Breaks” you will find the relevant options for defining the type of break, where it falls, and whether to trigger a page style change.
You would either create a fresh document from a template you’ve created, or open an ODT that already exists for this purpose, and use Insert ▸ Text from File...
, indicating the compiled .rtf, .docx or .odt file. RTF is probably fine, since again all you need here are style names applied to the text, and RTF involves less complexity on Scrivener’s side. If things don’t look right at first, select all and use Format ▸ Clear Direct Formatting
, after insertion.
I’ve never tried copy and paste… maybe that works? These things seem worth trying anyway. There is no harm in that. If it doesn’t work just File ▸ Reload
and try something else.
If you were to use Scrivener with Pandoc, you could apply the template automagically during compile, so that your styles would work directly in the ODT file generated from Scrivener with no fiddling. The steps are:
- Make a template, based on the default:
pandoc -o custom.odt --print-default-data-file reference.odt
— this gives you acustom.odt
you can edit in LO changing each style and relationship. You can add custom styles too. - Use Scrivener to call pandoc using the following setting:
--to odt --reference-doc=/path/to/custom.odt
— Pandoc uses this template to make the output doc using the styles in custom.odt
As we’ve discussed before, you can use Styles in Scrivener to trigger Styles in LO (e.g. the Scrivener Caption
style becomes FigureCaption
in LO). You can also apply any named styles even if they are not the common ones. For example the Scrivener compiler could convert paragraph and character styles to the following:
::: {custom-style="CuriousAside"}
This is text with a `placeholder`{custom-style="Placeholder"} text style.
And this is text with a `teletype`{custom-style="Teletype"}
text style.
:::
This makes the paragraph style CuriousAside
and the inline styles include Placeholder
and Teletype
in LO. As an added bonus, at least when I last checked several years ago, Pandoc’s ODT was “cleaner” than Scrivener.
It would be helpful to understand why you want to ditch MS. If it’s just the subscription model, for example, well they do actually offer a one-off payment option.
The reason I ask is that MS Office does all the things you ask in your wish list and more, and the fact that you say you use spreadsheets extensively will always make me recommend MS Office first as Excel is an incredible program and all the other I have tried are just toys. And nothing out there opens and plays nicely with your back catalogue of Word files nearly as well as Word itself.
So I’m back to my original question. What actually is wrong with MS Office that makes you want to get rid of it? It’s hard to recommend an alternative that improves your experience without knowing what to avoid!
Thanks for chiming in pigfender!
The subscription model is my main peeve. Office 365 doesn’t suit me at all. (Internet access is not a constant for me.) I need something that can live alone on my computer and work anytime I need it.
I did look at the MS one-of, but didn’t see the entire suite offered. For the price they charge for of a fraction of the suite, I didn’t see enough value; nor did I see any reassurance that it would be continually supported for a reasonable amount of time for my liking. To the contrary, it was full of reasons why the one-of was a bad idea. (Add the fact that the help files, and a lot of the templates and addons are non-existant without internet access.) Last I looked, Access was on its way out for database integration as well.
At least with Libre, I can download the manuals for offline help, and it has the whole suite that integrates together. I know it’s not perfect, but the price is right.
Btw, I totally agree that Excel rocks. That is what took me so long to decide to change. Word, not so much. I still have an offline computer running (2003?) that is my fallback.