Style indicator?


I am really enjoying working with the new style engine in Scriv3. As I am working through my legacy projects, these all have (of course) “no style” as default. I am going through and assigning styles. That is fine, I have no problem with having to do that. However, it seems to me that it would be useful to have small style indicator off to the side just to show that this paragraph/heading/whatever has a style assigned to it. This would allow me to quickly see what still needs to be done.

I think MS Word has functionality like this. I am sorry if this is already available, but I cannot see it.

Cheers and thanks for a great app.

I’m not sure there’s a visual clue like this (though of course, the style for each individual paragraph is in the Formatting Bar), but perhaps this will help…

Firstly, don’t make any changes in Preferences > Editing > Formatting or Project > Project Settings Formatting before you do this (see last para below)!

  1. If you haven’t done this already, create your new styles (e.g. NewBlockquote)

  2. Create a Scrivening with all the relevant documents.

  3. Go to the first paragraph with the old V2 preset format that you want to change (e.g. an old Blockquote).

  4. Open the Styles Panel (Ctl-S) and from the gear icon and select ‘Select Similar Formatting’. This should highlight all the paragraphs in the Scivening which have the same formatting. Check that it’s matched them all…

  5. Keeping the selected paragraphs, in the Style Panel click on NewBlockquote – this should convert them all to your new style.

  6. Rinse and repeat with any new style you want to introduce.

I’ve just tried this out and it seems to work – I’d test it first though.

Finally, don’t make the mistake I made when I first started using the Beta of trying to have a named ‘Body’ or ‘Normal’ style. That’s what the ‘No Style’ default is for — assigning a specific style to this just confuses matters. If you want to change ‘No Style’, then use Preferences > Editing > Formatting (or Project > Project Settings > Formatting). If you make changes in either of these panels before using the steps I’ve outlined, then you’ll have lost any chance of using this method, I think.


Word has this (called styles guide), and also it can visualise formatting added that is not part of any style (direct formatting):

I use this a lot when I receive documents from collaborators, to visualise what a mess of formatting needs fixing, but while writing I don’t really use it. I think it would be nice in Scrivener as a kind of pre-flight check before a compile, to make sure styles are consistently used, but I don’t think it is an essential feature for styles.

The problem I found, when I too first started using the beta, was the opposite. I use Nisus Writer Pro and so
compile to RTF—not DOCX as I don’t use Word, though I would have expected the same there. NWP expects a ‘Normal’ style, and compiling with “No Style” doesn’t create it and I couldn’t select all in “No Style” to convert it to Normal. Selecting text with “No Style” also selects text with a style, say Block Quote, which uses the same font as No Style … margins and indentations are not picked up. So I had to create my own Normal style. Then I discovered I had to have all my styles duplicated in Compile.

I said at the time that I thought that the people who were going to find the transition to Scriv3 most difficult would be those like me who had got to grips with Compile under Scriv2 to produce documents exactly the way they wanted them, and who were going to have to learn a completely new system.

For what it’s worth, I have set up a “Standard” Compile format, with Normal and all my other styles set up, together with section types. All my texts get compiled to RTF using that, open automatically in NWP where it is easy to change any aspect of the styles. Basically, it means changing font from AGP to TNR depending on the purpose of the document, and marking any text in Chinese as being in that language—the latter achieved in a matter of seconds via a macro—but more complex changes to styles are also easy.


Just to clarify - Mark - since I also use Nisus - you create a new Normal style in Scrivener prior to compile, correct? Then it’s available in Nisus?

Yes, both in the editor, and in Compile. It’s quite some time since I set it all up, so I can’t remember all the hoops I jumped through. :slight_smile:


EDIT: One of the advantages of duplicating your styles like this is that you can set styles in the editor to use whatever font you like, and Compile with the style being picked up but a more appropriate font being applied as necessary.

Indeed, as brookter points out, in Scrivener, styles are intended to be used for the text that is different from other text. For the main body text, you should just use “No Style”. Otherwise, you’ll reduce some of the flexibility of Compile for overriding unstyled text.

All the best,

Thanks Keith I get that point. But given that “finishing” software like Nisus, Word, Pages expects a Normal/Body style, it seems Mark’s approach will be necessary for many users.

BTW There is a way to do this in Scrivener. When you define or redefine a style, the dialog box you get to set various parameters of the style includes an option to highlight the styled text with a color – precisely to show that the text has been styled. It does tint the whole area of style application, but the tinting can be set to very low opacity. You could, of course, just enable it temporarily while you worked through a process. The coloration does not show in compiled output.

Just got Scrivener 3 (it’s amazing!)
Currently going through the same process as the OP, converting my old projects and assigning styles, and was also wondering about the “no style” default.
I get both arguments for / against “no style” in relation to compile but I was wondering just for use within Scrivener how to best do the conversion.

Here’s the problem I stumbled upon:

Converting my old projects, everything becomes “no style” by default.
I go ahead and assign headings, quotes, etc.
Now let’s say I want to change the font etc. for the rest of the document, I do that in the preferences > editing > formatting.
Now I select the paragraphs with "no style"and click “no style” again from the formatting menu and it changes them all.
However, it also gets rid of all of my bold and italic formatting.
It seems then that clicking “no style” does not only assign no (paragraph) style but also acts as clearing any and all style information.
How best should I work around this?
And more generally, how do italic and bold behave? Are they similar to inline character styles?
Would it be advisable to assign them special character styles?
Would love some input!

Something that strikes me as being a better solution than brute forcing normal from the source document side is to apply that kind of modification at the compile stage. Try out the attached project for a simple demonstration of what I mean:

  • It has a couple of simple style used in the main editor, but the body text is left alone and purely flexible in terms of how Scrivener works best.

  • Open File/Compile… and try a quick test to RTF.

[list][*] You’ll note the styles look different—that’s thanks to the Manuscript (Times) format altering heading and block quote styles.

  • More importantly if you click into the body text it will be Normal.

  • Even more importantly than that, you’ll note you still have your italicised, underlined and highlighted text.
    ] So back in Scrivener, load up compile and double-click on the provided project format to edit it.

  • Firstly, in the Styles pane I did nothing special here. I could have renamed the “Body” style that is added to this format by default, but instead I selected it and clicked + to create a new paragraph style from it. I left the formatting alone because it was already the way I wanted it.

  • In Section Layouts, I edited the “Section Text” layout to (a) Override text and notes formatting, and (b) in the main body area, I used the Styles dropdown in the format bar to apply my newly created Normal style. You’ll see it’s checked off as applied, in the example.
    So, that’s it. I think the key advantage here (unless I’m missing something, and very well may be as I am not word processor person in the least :wink:) your project itself is flexible to use other formats simply, and without having to duplicate your own set of copies that have a Normal style in them. You only need to do that for the formats that will be used to create RTF files for word processor usage—and then in that sense to create that format as a special function.

Is there a solid reason to be using character formatting in your paragraph style? If you can all avoid it do so, that’s the problem. Character formatting is applied equally to the entire paragraph when these two are combined.

Oh, and there isn’t anything like what was posted above, a style browser integrated with the editor like that—but there is a Format/Style/Show Styles Panel that acts as an indicator along with being an easy to use central management area. (21.8 KB)

There is a trick here to change to a new Default Formatting, that depends on “No style” first removing a block before an inline style. Lets say your “No style” paragraphs are currently in Helvetica and you want them in Avenir.

  • Make your changes in Default Formatting (Helvetica ⇨ Avenir).
  • Select your “No style” paragraphs.
  • Apply any block style (i.e. caption ⌘⌥3)
  • Now apply “No style” back (⌘⌥0)
  • The paragraphs now use Avenir, and bold and italics are preserved.

By the way, I prefer to create “Strong”, “Emphasis” and “Strong Emphasis” inline styles and then rebind ⌘B and ⌘I so they now use my inline styles. I also do this for “Subscript”, “Superscript” etc. As much as possible I do not want to use “direct formatting”, but then I am a stylesheet fundamentalist…

EDIT: KB there would be a use case that we could use Edit ►Find by Formatting… ► Style to search for “No style” paragraphs?

How. Very. True.

Scrivener now forces the use of styles. I suppose this is useful for those who want to go back and use styles in Microsoft Word. I don’t.

Even compiling to LaTeX requires the use of styles where LaTeX is and always has been plain text.
Compiling to Markdown gives you that same error message. Markdown is plain text as well.

I thought that the transition to a new editing engine would get rid of Mac OS anomalies, but instead it seems merely to be a dding styles.

Or maybe Scrivener is “just” a word processor now. That in itself is disappointing.

Where are you getting that from? If you don’t use styles then that whole infrastructure doesn’t do anything, from top to bottom it’s latent code. In fact the whole topic here is how to use styles more aggressively, for those that need it, because the default behaviour in Scrivener is not be aggressive at all with them.

Now you’re just pulling my leg. :slight_smile: I do use styles now and then to keep a whole wad of raw syntax out of my face, but if I wanted to just type it all in myself or use Markdown vanilla the compiler wouldn’t care one bit.

Maybe you are posting in the wrong thread, in fact. Nobody here is talking about errors; not that there are any errors that would be produced because a document lacks styles.

Anyway, to get back on topic :laughing: :

That’s maybe not a bad idea, but do also note that the Edit/Select/ sub-menu has a cluster of three style-related section commands (one of which walks through a text by instance), and those all with with “No Style”. Add your shortcuts as needed.

Also the floating style panel has a gear menu where if you put the cursor in an unstyled region, you can use it to “Select All Style”, which bulk non-linear selects the document text in the current editor.

For people like pseingalt, that would select entire Draft if performed in Scrivenings mode.

And that would just fine.

Yes, I knew about the gear (⌃S is almost my favourite key binding) but I never looked in the main menu to see they were also there :slight_smile: This functionality should be discoverable enough then…

Thanks so much for these hints!

Nontroppo’s suggestion did the trick!
So, I’m assuming the default behavior is:

When changing from a style to no style, then bold/italics is preserved.
When applying no style to a no style paragraph then it gets rid of everything, including bold/italics and character formatting, and applies whatever is the default set in the prefs.
Seems like this is intended behavior, and it’s fine.

That’s actually not my concern, as I export to LaTeX (something which I still need to reconfigure, but which I’m very excited about the new options!!).

Well, I do need italics for scientific terms, emphases etc. So I had hoped that “no style” would act like a paragraph style, but it seems that it combines paragraph, font, and character information.
I might end up doing what nontroppo did, remapping cmd-I and cmd-B to actual character styles (… will figure that out after I get to setting up my export workflows).

And here is probably the only point where I’m thinking that defining a “Normal” style would probably be better than the “No style” style. One of the strengths of the style system (as well as the previous presets system) is imo that one can set paragraph and character information independently and, in addition decide whether to include font information or not (took me a while to figure it out how to best make use of that in Scriv2 but ended up loving it ever since). But there seems to be no such option for “No style”.
For example, when I want to change the font/font size/spacing info, etc. for all of the “no styles” sections but not character information like italics/bold, then going to the preferences and changing the default font won’t do anything. I have to manually select the no style sections and change the font. Or I manually select and reapply “No style” to those sections after changing the defaults in the preferences – but that will also get rid of character formatting.
Or maybe I still haven’t fully understood how no style works?

What would be the big disadvantage of defining a “Normal” style instead of “No style”? According to Keith:

Can’t I just not define any formatting or pre/suffixes for a custom Normal style, which upon export then doesn’t do anything?
(Sorry, if this is a bad question, I haven’t had the time to look in depth into the new compiler myself.)

In any case thanks so much for the comprehensive input!

This is how I understand it.

It is slightly easier to make these styles before you create your compile format. It is really simple to set up: select a bold word, type ⌃S (Styles panel), click the + icon, name it “Strong” and make it a character style. Now when you create your compile format, you can “import” this style into the compile-format-editor, and (if you use MMD to create your LaTeX) add a ** to prefix and suffix. Then in System Prefs (or BetterTouchTool etc.), rebind ⌘B to trigger “Strong”. Keith made sure these rebindings toggle ON/OFF just like the original direct formatting would.

I think for those of us who compile to plain text formats, the use of a “Normal” style is less of an issue (we don’t have override issues that other users may). Though I strongly prefer writing with styles, I have tried to stick to the recommendation of using “No style” as a base then using styles for clearly defined semantic structure. It has worked fine for me so far, but I never switch my base font/size etc. in a project so haven’t really faced this issue. In theory at least, you should be able to transform the “Normal” style just as much during compile (so I believe), but because Compile supports so many output formats, each with a different processing path, I think Keith recommends “No style” with a general “one layer of complexity less” attitude.

Yeah, I might not have elaborated on that concept well enough in my earlier how-to on applying Normal at compile time. It is of course trivial to go into the format designer, add a Normal style and then make it look like whatever you want. It’s fundamentally the same thing I was demonstrating, the only difference is that in my example the compile settings were also responsible for the application of the style itself to the text, rather than having that be something you do consistently in the text editor as you write.

The bigger problem is that you have to do that with each and every format you use, unless you really want whatever “Normal” looks like in the editor to be what it looks like no matter the format.

With the method I was describing, the choice of having “Normal” applied to all body text is specific to the format itself as a function of that format. It is saying, “computer, document, classic Nisus/Word, styled”, and the replicator obeys. But meanwhile you can switch over to Proofing and print out a PDF in double-spaced monotype with a single click.

If your text is “Normal”, you can’t as easy do that. You have to go in an manually edit the proofing format to accommodate the body text.

Ioa, thanks; that gives me real food for thought.

As a beta tester, I spent quite some time getting my head round the new compile system to get it to produce the output pretty much exactly how I wanted it. I had spent as much time over the years tinkering with the compile system in v.2 so that it would export a document using colour or size coding for which I could use a macro in NWP to convert the various elements into appropriate text styles and headings. In NWP, if I want to change the body-text font throughout, I only need to change it in the ‘Normal’ style and it cascades down.

In a way, I was using a “junior version” of what @nontroppo does, substituting NWP for MMD+Pandoc.

With the system I developed for v.2, all my documents were compiled in the same way, and in NWP the macro then imported an appropriate set of styles and applied them; a 45 page document was done in under a minute with a couple of clicks. So, essentially, I set about creating a system in v.3 that did the same, only providing the styles, rather than using colour/size coding. In that, I succeeded.

However, from what I’ve read here, I can see the limitations of the style system I’ve created, and if—as now seems possible—I need to compile to ePub/mobi, my current style system will be a hindrance rather than a help. I can also see that not having to apply Normal explicitly during writing/editing would be an advantage

So, I’ll digest what you and KB have said, and then set about seeing how to change things to be able to use “No Style” converting to Normal on compile, rather than having an explicit Normal style.