You sound confident. 
Is this still going to be RTF-based?
Yep, RTF-based. My confidence may be ill-founded, though, as I havenât started implementing it yet, I just have a long list of notes about how I think it will work both conceptually and programmatically - Iâm sure Iâll run into a whole lot of hell when I actually start coding it.
Yes, I suggested something that I thought would be easier to implement (though not as WYSIWYG) without anyone having a nervous breakdown first.
If you can do it then youâll have a game-changer on your hands. Personally, I wouldnât use it; Iâm much happier to just type without distraction of formatting and let Scrivener sort all that out for me later. But I can see why many people find WYSIWYG essential.
But being able to map different styles at compile time would be very useful. You can a set of fonts that are easier to read on screen, and then change them when you go to print.
No pressure then. Good luck ⌠
I donât care in the least what the screen and text looks like when Iâm working on a manuscript. The beauty of Scrivener is thatâs how it worksâyou type and edit and stare furiously at a screen thatâs as nondescript and non-distracting as can be.
And then, when you get ready to send This Thing out into the world, you go to a completely different mindset and make it all pretty with Compile.
Except that Compile is, like, hard & stuff, and not at all intuitive, at least not to me. This is the only place I can see WYSIWYG-ery as being useful: a what-you-see-is-what-you-get compile setup, using your actual text, would be the lobsterâs waistcoat.
Embedding the styles, then, would be the key, however, because when the manuscript goes to the agent or the publisher or Word or Pages or whatever, Heading 3 is Heading 3, and not simply a block of text specified as Flush Left 1½ linespace before, 1 linespace after, 14pt BF Garamond.
Compile can never be WYSIWYG. We threw some ideas around, but itâs simply not feasible to show your manuscript being updated to reflect the Compile options while you select the options. It would entail doing all of the Compile work in the background while you edit the options, somewhere to show the preview, and even then, it wouldnât be able to show you how the work would look in the various different outputs because how it will look in Word is very different to how it will look in an e-reader, and how it will look on the Kindle is different to how it will look in a PDF viewer, and so on.
We will, of course, continue to strive to make Compile easier, but its complexity is the trade-off for the structural flexibility in Scrivener itself; you canât have one without the other, without reducing Compile to a simplified âjust output my stuff and Iâll format it laterâ thing, which can already be done anyway.
Styles will, however, at least make formatting the output a little more comprehensible to those who are used styles in the first place. (I hope.)
I think the development of style sheets should
be Scrivener developers lowest priority right nowâŚfor 2
reasons; philosophical and strategic use of
creative resources.
Scrivener is a drafting toolâŚand it does that well.
Word is a formatting toolâŚand it does drafting poorly.
I would rather see Scivener build on itâs
strengthsâŚrather than try and replicate
something that can already be done in another
product.
Plus, Styles belongs to the finished product
or the second phase or after compiling, in my opinion.
I am new to Scrivener in the last few weeks,
but I have been âsleepingâ with the manual;
meaning I have printed and binded the manual so I can
carry it with me everywhere to fully absorb it
conceptually (I only do this for software I am
serious about.)
One of the things that has impressed me about
Scrivener is how it allows you to principally
do things that Word does not or does very
poorly. Word, in my opinion, was not crafted
for content creators, but to win over output
readers. Word and Scrivener, I feel, both
start at opposite ends of the Spectrum.
But only Scrivener focuses on thought development.
I want to see Scrivener developers focus on what they do best;
the development of text into ideas.
In my opinion, styles has little to do, principally, with development.
I am a Windows corporate trainer for over 20
years. I have used Word and despised it from
my first encounter. The word processor I
remember making the biggest impact on my was
Ami Pro back in the day. Why? because some
reason I could think about what I had to write
and Ami Pro kept everything else out of the
way. I was a advertising sales person back
then and made my living getting words and
concepts onto paper. Ami Pro allowed me to do
that⌠And Scrivener seems to allow me to do
that for the first time since then.
I am a new user to Scrivener (month) but I am
not a writer. But I always wanted to be a
writer or a journalist, so I that loosely
makes me eligible to appreciate some of the
things being being expressed here.
Bottom line, I think Scrivener should innovate
with style sheets only when it can bring
something to the table uniquely different from
whatâs offered by other word processors.
And I am willing to wait for as long as that takesâŚ
I donât want to see Scrivener developers get distracted from itâs Zen!
Just to raise a point of view not considered in the geekmeâs interesting post: styles arenât just about formatting and output, they can also play a structural role. They can signal the relationships between different parts of text. e.g. this bit is a heading, and that is a paragraph that belongs to that heading, while this bit is a quotation and that bit is a continuation of the paragraph from before the quote.
The current use of presets can create a visual simulation of a relationship, but the relationship is all in the binder (which only represents hierarchical relationships). Although I love the binder, the problem is when I compile all that information is lost. But whatâs worse is, because the text is only a visual simulation of semantic relationships (e.g. red-text, italics, etc), I have to think about appearances in Scrivener in order to minimise efforts to reconstruct that information after I compile. I need to be sure that my block quote is sufficiently different to my body-text, which is sufficiently different to my continued-body-text (and so on) that I can find it all in Word later on to turn them into styles. This also has implications for presentation purposes. Not a problem for a 5-page document, but itâs tiresome for 100 pages. Stretch that out to several hundred pages or more and it gets⌠challenging.
Not that I am complaining. I really do not think I could have written my thesis without Scrivener. I suspect I would have needed to drop back to a Masters or even thrown in the towel*. I will quite happily continue using Scrivener as-is for some time. Having said that, it would have made completing my thesis even easier if Scrivener had styles.
*Which reminds me, itâs Towel Day soon (May 25). I might not be a frood, but I do know where my towel is (especially since I didnât throw it).
I worry about you. I really do.
Sorry InDesign, Scribus, PageMaker and similar are formatting tools. Word is at best an electronic typewriter. Word is no longer the de facto form for electronic publications; thereâs PDF, which Scrivener compiles to out of the box, or EPUB, which Scrivener compiles to out of the box, or TeX/LaTeX, which Scrivener compiles to out of the box but the results needs tweaking. TeX/LaTeX is the definitive formatting tool of the last 35 yearsâit hasnât been better. But all of those are the final action that is applied to a document.
Absolutely not! Styles are a major part of the writing process whether drafting or final production. In a technical text using italics for chemical formulas, or Linnean species names obscures the authorial intent. Italics and other rendition things should not be included in text. Oh yes and did you notice the foreign phrase in the previous paragraph. Use emphasis and leave the decision about how that will be presented to the user in the final step. Mark the text with appropriate elements (lazily called styles) and improve the writing of the writing 1000-fold.
I think that implementing styles means, and this is the most important part, that scrivener will be able to recognize all the instances using that specific style.
This is what it doesnât have today.
All I want is for styles to be preserved after compile to word or mellel or nisus or pages. At the moment I have to redo headings and TOC each draft of my PhD I send to my supervisor. Donât really need formating preserved just the fact that heading 1 is heading 1, body is body and caption is caption. As I have 286 headings and 2400 paragraphs at this stage it takes a long time to format the output - my supervisor insists on a table of contents that is hyperlinked to the headings.
Apart from the âchange supervisorâ jokes (sometimes they pick the strangest things to get pernickety about), it should only take a few minutes to convert everything to styles.
While there are more details in a thread around here somewhere, the gist of it is to use different formatting presets in Scrivener such that each âwill-be-a-styleâ is unique (e.g. 14pt Helvetica for Heading 1, 12pt Arial for captions, 10pt Comic Sans for Body, etc). Note that they donât need to match your intended styles in Word, only that be different from each other. Then in Word, use Find to search for all examples of each specific formatting combination and use Replace all with the relevant style. You could do all 2400 paragraphs done in one go!
Iâm betting itâs more complicated than this, but if all you need is the kind of internal link that you can do in Word (CTRL-click to follow link), then you can accomplish that by assembling your ToC in Scrivener with Scrivener Links (Edit->Scrivener Link).
As Scrivener develops its new Styles implementation, will it include the ability to set things like page colors per project? It would make it easier to identify projects when more than one is open. I know sometimes I can tell just by looking, but other times itâs, ok where am i?
Or, maybe the binderâs bg color could be per-project? Hmm⌠how about being able to define alternate âsystem stylesâ that could be selected per project?
PS. This can already be done I realize by swapping preferences in and out. But not too elegant.
That has nothing to do with text styles, and there are no plans for per-project binder or page colours, sorry.
All the best,
Keith
Original thread: 2014
While there are more details in a thread around here somewhere, the gist of it is to use different formatting presets in Scrivener such that each âwill-be-a-styleâ is unique (e.g. 14pt Helvetica for Heading 1, 12pt Arial for captions, 10pt Comic Sans for Body, etc). Note that they donât need to match your intended styles in Word, only that be different from each other. Then in Word, use Find to search for all examples of each specific formatting combination and use Replace all with the relevant style. You could do all 2400 paragraphs done in one go!
[/quote]
Follow up: 2019
Would this be the easier way to identify foreign language text w/in Scrivener to facilitate conversion at the word processing point? Any better ideas would be greatly appreciated. 
Scrivener 3 now has a Styles system. The idea is similar, except you would be defining styles and i) you donât have to make them all wacky different looking, in fact you can just have a style tone the background of the span of text so you can tell it is styled and leave all else alone, and ii) since your named styles carry over into Word, you donât have to refind a group by formatting, you can just alter the appearance of those very styles in Word as you see fit. (Or, of course, you can specify in compile settings special looks for your different styles that can be different depending on your target format.)
In short, the Style system makes all this sort of stuff much simpler than it was.
@gr, I think the post you are referring to is quoting the answer to the original question in 2014, without bb-marking it as a quote, and asking if that technique could be used to mark sections or strings in a different language than the core text.
My answer is yes, you could: set up a character style using colour or a different font for each language needed, then search for that and replace it with the body font and colour but marked with the language designation.
Until v. 3 came out, I used that technique for getting my texts styled properly in Nisus Writer Pro, using colours that were so marginally different as to be undetectable to my eye, but different nevertheless, and had the whole transformation macroised, from importing the style sheet to making the changes. Fortunately my other language was Chinese, so the macro searched for UTF character ranges, rather than colours.
Now Scriv 3 has styles, I still use the Chinese-marking part of the macro, but if I needed to use other Roman-alphabet-based languages, Iâd use the colour approach.
Mark
Thanks. Is there a âreasonâ that applying a style/color canât be achieved on a per-word basis? Selecting just one or two words, applying style, seems to engage the entire sentence.
Is your issue down to the difference between paragraph styles (if your sentence is also technically its own paragraph), and character styles?