Named Styles -vs- Embeded Styles

Scrivener Wish List
1

Remember the Big Debate in the late 90s over styling web pages using HTML font tags -vs- using CSS? That debate existed because embedding styles into each element of your document is hugely limiting and just plain sucks.

In contrast, all major word processors (and web pages) can use named styles. Yes, lots of people using a word processor manually click on font size, centered text, italicize, etc. But then lots of people are doing it the hard way, and they make a lot of unnecessary work for themselves. I used to do that too. It’s really a boon to learn the proper use of your favorite word processor.

Did you know that in LibreOffice I can instantly restyle my whole document by importing the named styles from another document? With inheritance (called cascading in CSS) I can create a root style, then child styles based on my root style. So, for example, to change font, line spacing, or other some other aspect, I need only change it in my root style. The change ripples through only the appropriate parts of the whole document. Far superior to Ctrl-A, updating your font (or whatever), then spending the next hour manually finding and fixing those elements you didn’t want changed.

I even used named styles for inline elements, like interior monologue, foreign words, etc. If some old-school editor asks for my manuscript and he prefers underline to italic, I need only change my style and all instances of italics turn into underlines. Or let’s say I want to change from Times New Roman to Palatino, which has badly squished italics. I can go into my style and leave the italics, but set letter spacing to 108%.

RTF is like old-school HTML: styles are embedded directly into your document. I looked over MS’s specs for RTF and it looks like maybe named styles can be used, but it’s not clear. Either way Scrivener embeds styles. Yes, there are Formatting Presets, but those only paint your style choice into the document. If I later change a Formatting Preset, that change has no effect on my document.

Worse, when I export Scrivener to my word processor, the only style I get is Default. All styling is embedded into each and every element, to bend Default so it matches the look of the RTF file. I must then go into my word processor and set styles everywhere. Sometimes italics drop off during this procedure, forcing me to proof my file before I can do anything else.

So, my wish is Named Styles in Scrivener.

If that means abandoning RTF, so be it. RTF is sooo 1999. ODT, DOCX (does MS make the specs for that public?) or even HTML/CSS completely blows away RTF. Or make up your own XML-based file format. Or use E-Pub3 (which is mostly HTML/CSS).

Thanks a million.

2

EPub 3 would be a terrible choice for an editable format - it’s a reader format and is not designed for editing at all. Likewise any sort of HTML is a bad choice for editing rich text, because HTML is primarily designed for web pages, and doesn’t support a tonne of stuff needed by word processors (tabs for one).

Docx is a public format - I wrote my own importer/exporter from scratch for the iOS version. It would be a bad choice of internal format, however, because the number of apps that can open .docx is limited. RTF is a plain text-based standard that can be opened in many, many apps across all platforms. Its age isn’t an argument against it, quite the opposite.

Besides, RTF supports named styles, it’s just Apple’s implementation of it that doesn’t.

The next major (paid) version of Scrivener will support named styles, too. They won’t be cascading, however (no support for “based on” or root styles, each style is independent).

3

To the OP, I have set up presets in Scrivener which assign ruler details plus a different colour to each text paragraph type. I have a customised standard compile to RTF, which has font override setting everything to Adobe Garamond Pro. Italics and bold within the body paragraphs and the colour are preserved, but all body paragraphs have the same font size, ruler and tab settings; headings are exported at different sizes.

I use Nisus Writer Pro rather than LibreOffice. I have an NWP macro—with a keyboard shortcut assigned—that asks me to choose a style collection and applies it, then runs through the file replacing all the heading sizes with the appropriate heading styles, finds in turn the text in each of the colours putting the paragraphs found into the appropriate style and removing the colour assignation … and does other odd jobs like finding all the text in Chinese characters and marking it as Chinese and in the appropriate font. So all I have to do is open the compiled RTF in NWP and then run the macro over it.

For a 40-page document, the process takes about 10 seconds and results in a document where every heading and paragraph is assigned to appropriate styles. NWP has cascading styles, so for documents that I’m going to be exchanging with colleagues who don’t have Adobe Garamond Pro, I merely have to change the font of the “Normal” paragraph to a font they will have … TNR at worst. And to back up what Keith says, NWP uses RTF as its default format.

I’m sure you could set up a similar process in LibreOffice; the key is using colours to distinguish paragraph styles.

Interesting … the non-cascading bit. Styles will still be incredibly useful, however, particularly if they can be project specific rather than global, as the current presets are.

Mr X

4

RTF forever, please! There’s no HTML editor without an “Edit Source” tab, and the need of one, its use inimical to the creative flow. The HTML manuscript accrues nested tags that are the devil to get rid of. And the writer must format in terms of those tags if he wants CSS to be able to pull the strings later. Two blocks might appear to be formatted alike, but will compile very differently if they don’t share the same tags or classes.

The “cascade” is an array of overrides of overrides in an accumulation of dialects. Whereas with Scrivener we have just enough WYSIWYG elemental formatting at the point of creation, and can introduce our overrides at compile time. Before then, a writer’s environment, mercifully TinyMCE free.

Rgds – Jerome

5

Xiamenese,

thanks for your input. Would it be possible to have your NWP macro? (I was not aware that you can build macros with Nisus) It sounds very interesting…
Thanks.
Have a nice day.

6

Hi especiale,

Thanks for your interest. NWP has an extremely powerful macro language. I’m no macro writer, but Martin at Nisus is extremely helpful and there are a number of users on the Nisus forums who are expert at putting together macros—‘phspaelti’ for one—who are very generous with their time and knowledge.

My macro is almost entirely the work of Martin, who took the time to sort out my feeble efforts. I posted it here:

Feel free to get in touch either through that thread or this one, or send me a PM, if you need any help making any adjustments to your preferred font, etc.

Mr X

7

Thank you. I will try the macro and report if I get issues.
Have a wonderful day!
ES

8

YAYYYY!!!

When, by chance, might I be able to pay for that version of Scrivener? I’d love to do so immediately.

9

That, sir, is freaking awesome! I’m on board.

10

Hmmm. I get what you’re saying. Use macros in the word processor to pick out different paragraph types and apply my favorite styles to those. I’ll give it a try.

To all:

There are functional parallels between different rich text file formats. Probably because they all use text structured into headings, paragraphs, sentences, etc. HTML makes the explicit distinction that there are two basic types of “text chunks”: block and inline. I’ve not seen it stated anywhere, but MS Word seems to follow this model, and LO Write puts block and inline styles under different tabs, and introduces a third type: page (which is irrelevant in the world of HTML). MS Word doesn’t seem to have named page styles, but embeds the styling into the document (why converting from ODT to DOCX sometimes fails).

Page acts as the framework (and where you build structures like columns). Blocks stack vertically in the page (think one paragraph after another). Inline groups words within a block (such as internal monologue). In HTML one could do all this (minus page) using only

and tags. For example
can be a visual replacement for

, assuming one has their CSS setup properly (does nothing for blind people using a page reader, so not recommended for use “in the wild”).

The point is, a blob of text is just a blob of text until we somehow mark it and give it meaning. “Heading 1”, or

, or whatever is relevant because we give it relevance (how we style it is a separate issue). The exact file format used within an app is largely irrelevant, as long as it’s capable of supporting what we need. If RTF works, that’s awesome. If it’s 95% of the way there, then don’t be afraid to turn to the dark side, accept your inner Microsoft, and “embrace and extend.” :smiley:

KB:

I too have had “interesting” experiences with passing RTF files from app to app and platform to platform.

11

It gives me hope when I hear that the next version of Scrivener will support styles. I really like what I see in Scrivener so far (just purchased it)… That said, the absence of support for MS Word styles is a real deal-killer. I am an author (several bestsellers) and there is no way I can work without full interoperability between Scrivener and MS Word:

  1. Export to MS Word retaining styles.
  2. Import from MS Word retaining styles
  3. Import from MS Word identifying chapters, sections, etc. by style

Publishers want MS Word files. Editors at publishing houses work in MS Word and send back the results of their work marked up in MS Word. Also Scrivener is not a full function word processor yet. IMO until it is a full function word processor equal to Word, I see it as a very useful tool for research, beat sheets, background work, outlining, and analysis… i.e. pretty much everything except writing the manuscript itself…

Scrivener looks so promising… Thank you for creating such a cool piece of work.

12

Hi Kevin,

Thanks for trying Scrivener, and for the kind words.

Obviously, everyone has different needs and preferences when writing. Scrivener has always been chiefly intended for the compositional stages, and as such has never tried to replicate everything a word processor can do because its main features lie elsewhere. It does have most of the important word processing functions for writing books, however (styles in the current version aside).

I therefore entirely accept that Scrivener might not be the right tool of you because of your desire for styles, which I believe is all you are saying; if, however, you mean to say that Scrivener in its current form would not be useful for authors (best-selling or not) in general, then that would be like me telling you that your books will never be bestsellers until you add a turning point on page 100 and a reversal on page 173. :slight_smile: Which is to say that we have hundreds of thousands of users using Scrivener to write novels and books, and we know (from feedback and social media) that a decent number of those are bestselling authors such as yourself. As I say, I’m sure that’s not what you mean anyway, but without meaning to sound defensive, I feel I do have to defend my creation on that point!

Our next major (paid) update will add styles support, though, so I hope you come back and check it out again then. (1) and (3) on your list will be supported. (2) will also be supported, but an imported Word document will only retain its styles as long as those styles are already defined in Scrivener (because Scrivener can import many documents and does not work with only one). You can import styles directly from a Word document, though, so you don’t have to define them manually.

All the best,
Keith

13

But will there be separate paragraph and character styles with proper precedence? E.g. if I have a paragraph style P-BodyStandard which also defines a character style element (guess that will be possible?), say for my default font A, and within a paragraph with P-BodyStandard applied, a piece of text gets applied a character style T-IntMonologue which defines font B, will it supersede font A for that piece of text then?

As an illustration, I use css for style indicators and colours for different fonts. So when the text is styled like this:

[code]


Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla - here a piece of interior monologue - Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla.

[/code] will the text look like this? Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla - here a piece of interior monologue - Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla Bla.
14

Yes, character styles will supersede para+char styles.

15

Keith,
I, too, am eager to see the styles implemented. All of my work in Scrivener is non fiction, manuals, operational guidelines, employee handbooks and the like for a fire department (you might say fire brigade). Many of my documents are built of 100 or so relatively independent procedures, guidelines, or policies. Scrivener is the only thing that keeps it all organized and coherent, but still relatively independent. I consider the Scrivener version to be the master document. The output to Word is a finishing touch.

With 100 policies, each with 4 - 7 sections, all the headers, bullet lists, etc are a lot to keep track of. Interestingly, some times the hierachical numbering works just fine when importing to word. Other times, word interprets any numbered section header as a number list, and parks a 1. In front of that hierarchical number. I haven’t figured out the rhyme or reason that happens in some places and not others. There must be some sort of hidden code in the compile that tells Word that the section header is a numbered list.

I really appreciate the work you and the L&L group have put into this.

Have a great day,
Jeff

16

I am very much looking forward to this!

May I ask if it will also be possible to use these styles at MMD > LaTeX export to set up automatic conversion of, let’s say, a text block that has a block-quote-style in Scrivener, to the appropriate \blockquote{LaTeX command}?

(If that’s not yet planned, please take that as a feature request …)

Thank you very much!

17

A statement like this warms my heart. (Although I bet there are plenty of people who want Scrivener to do it all–from organizing the research through delivering typeset books to readers.)

Why I want Scrivener to support named styles. My current workflow:

  1. Compile from Scrivener to my favorite word processor (LibreOffice).
  2. Import my custom styles: “Load styles…” and “From file…”. (about 3 seconds)
  3. Set the styles on the pages: Typically the title page, front matter, and the manuscript body.
  4. Set my styles on every block-type entity (e.g. paragraphs) within my manuscript. Not too horrible as 95% (or more) are “MS Basic Paragraph”, then I go back and set the styles for the exceptions.
  5. Manually scan though the manuscript and set the inline styles. ** E.g. the italicized stuff (mostly). LibreOffice has one ugly habit here, if a paragraph is all italicized then the italics vanish when the paragraph is restyled. So I gotta be careful.
  6. Select the whole manuscript and do a “Format / Clear direct formatting”.
  7. Save. Done!

What I’m hoping will happen when custom styles come to Scrivener. First, I create my custom named styles in Scrivener. They work. Then:

  1. When I do step 1 the styles with their names will appear in the word processor file.
  2. I only need to tweak my custom styles once (and save them) because step 2 will load my tweaks.
  3. Still do step 3. (Not even MS Word supports named styles on pages.) But it’s never more than 30 seconds of work in LibreOffice anyway.
  4. Skip step 4.
  5. Step 5 will be necessary if Scrivener only supports named block-type styles (styles on paragraphs). If Scrivener also supports named inline styles (and I use them ** ) then I can skip 5. However by not resetting styles, LibreOffice won’t clobber my “all italics” paragraphs.
  6. Do steps 6 and 7.

I don’t need or want Scrivener to be brilliant at complex page layouts or crazy style tricks. I can do that in a tool specially designed for the task. But if I render one paragraph differently from another, I do want Scrivener to help me out by tagging those paragraphs when I compile my project.

Thanks a million. I hope you find this useful. :smiley:

** Why inline styles rather than just italics or bold or whatever? #1] Persistence. Setting an inline style survives all but explicitly deleting that style. #2] Redefinition for special cases (using a font without italics or bold, using a font with particularly ugly italic or bold forms, swapping between italics and underline, or temporarily setting a background color so you can find all foreign words at a glance (as an example)). #3] New uses for inline styles, such as marking characters’ dialog so it can be isolated for editing (then the effect of the style hidden without needing to strip the styles).