Insert Word Styles On Compile?

Hi guys,

Interesting feature request here, I think. There are several self-publishing platforms online (SmashWords being one of them) that require your submission to not only be in MS Word format (.doc), but also, they require that you use specific paragraph styles in your document, in order to help their “MeatGrinder” delineate between your different layout elements. However, Scrivener doesn’t support stylesheets in and of itself, which is no big deal usually. But, going back into the resulting .doc file and adding in all those paragraph styles is a REAL pain in the keister. So, would it be possible to integrate support for Word’s stylesheets in the compiler’s export module? I.e., perhaps in the formatting pane of Compile, we could specify a name for different element stylings — say “Heading 1” for the Title of all second-level Document objects, “Heading 2” for all third-level Document groups, etcetera, “Normal” for all body texts, etcetera — and then have the Compiler “construct” a set of paragraph styles and insert them into the resulting file? I know this is a lot to ask — it would require rewriting, or at least augmenting, the .doc exporter — but it would save me (and I know others) a TON of time and work, sparing us from having to go back in and manually edit Every. Single. Paragraph style. What say you?

Thanks a bunch,
Andy

I’ll let the L&L mighty respond to your feature request, but in the meantime you can easily avoid manually editing Every. Single. Paragraph style.

If you use distinct presets in Scrivener for the styles you want in Word, then you can use find and replace in Word to change each instance of a preset to the desired style. Saves lots of time (mere minutes instead of hours). Note that, in Scrivener, you do not need to match the appearance of the presets to their Word style counterparts. You need only make them sufficiently different from each other for Word to be able to distinguish them. This could be through use of font, point size, colour, indents — whatever you want to make each one unique.

For me, your solution wouldn’t work because I use the different document levels for fine-grained structural reasons (rather than, for example, headings). However, if you have your project set up this way, and you don’t have formatting that needs to be maintained, then you don’t even need to worry about presets. You could override formatting on compile and make each level unique (bold for level one, italics for level 2, orange for level 3, Verdana font for level 4, purple indented WingDings indented 1 cm for level 5, etc) then simply use the same process described above to search for each unique formatting example and Replace All with the desired style.

Hi Andy,

This is something we do want to support in the long run, as it comes up from time to time. The problem is that it will require me pretty writing a new RTF exporter from scratch. Currently, I use the Apple RTF exporter, and just hack it to add extra features such as footnotes, comments, images, headers and footers and various other elements that Apple’s standard RTF exporter doesn’t support. This is all done by inserting tags before export and then post-processing the tabs in the raw RTF. It’s complicated, but it works well and has meant that I haven’t had to spend months writing my own RTF exporter. Styles cannot be hacked in through post-processing, though, because of the way they work in RTF (and our other Word exporters are based on the RTF exporter). This is the only reason that RTF styles haven’t been added already. And of course, if I did write my own RTF exporter to support this, there would then be months of other bugs and problems in the RTF owing to it being a completely new implementation.

That said, I also have on my list a note to further explore the possibility of post-processing just paragraph styles in case it can be done - paragraph styles should be easier to post-process than character styles. I have looked into it in the past, though, and it did not work out well at all, so I’m not convinced that it wouldn’t also need a complete re-implementation.

All the best,
Keith

I also found the output of scriverner to result in more work that should be required.

I exported to epub and then fine tuned in Sigil, but found the resulting pargraph styles to be all just ‘scrivener1’, ‘scrivener2’, etc.

The Scrivener output formatting controls are constructed to all export appearance (very web 1.0), but it would help us to output for structure as well (or instead!)

It would have been much better had I been able to designate H1, H2, H3, etc. for the xhtml output, or for a Word export Heading1, Heading2, heading3, etc.
These specific heading tags make the word document understand the STRUCTURE of the document, not just the look of it.

I also think it would be much better to support styles from within Scriverner - which would then make this much easier and more consistent to export. I now regret making virtually any appearance changes in the many files that made up my book, as I ended up with 26 different paragraph styles - and I really only needed a small fraction of that.

I used a number of indented italics for long quotes. But, I didn’t get the format on each file exactly the same so, I ended up with a bunch of similar styles, that I had to go find in the post-Scrivener editing program and get them all the same.

I also found that Scrivener output copious numbers of completely unnecessary tags, essentially one inside each paragraph tag (

The flight climbed to its cruising altitude of flight level 350.

)
Simple Italics text got turned into: text instead of , or even text

The issue of getting content from Scrivener into a Word document that has properly tagged paragraph and text styles is of some importance to me. But I’m not sure I want that functionality incorporated into Scrivener itself.

I’m a technical writer and a still-learning Scrivener user. So far I am quite impressed, even delighted, with Scrivener. I very much agree with the product’s stated design goal of being a writing tool and not a page layout tool.

Conversely, like most “real” technical writers I don’t enjoy having to use Microsoft Word. In fact, the notion of keeping Scrivener’s tools and workflow “clutter free” makes Scrivener even more appealing in a specifically “it’s not Microsoft Word” sort of way.

Alas, like most working technical writers I am regularly obliged to deliver properly tagged Word files.

However, even though I have the recurring need to interoperate with Word, I think it would be disastrous if Scrivener began “supporting” Word. It seems to me that so doing could quickly become a figurative rat hole down which endless amounts of time and energy would disappear. And from which dreaded clutter would rapidly emerge.

So I find myself wondering if the trick might be to attack the problem via an external converter or plug-in. Those who had specific requirements for tagged Word format could then address those problems outside of Scrivener proper. Scrivener support, if it existed at all, could take the form of delivering a more or less standards-compliant output format that an external process could bang away on to its heart’s content.

My central point being that even though I have a very real need to regularly produce tagged Word files, I might well prefer seeing that done by some supplemental process or interchange format rather than risk incorporating Word’s clutter and clumsiness into Scrivener.

Just sayin’ is all…

Cheers, thanks, & hope this helps,
Riley
SFO

Well, a person wouldn’t HAVE to use the Word clumsiness if they didn’t want to, right? So what’s the issue with including the support?

I think the best answer to that is to reflect upon how Word has become so notoriously un-usable.

Word contains a superfluity of features that, at least in theory, one doesn’t have to use if one doesn’t want to. In practice one regularly ends up obliged to find one’s way past those features’ clutter of extraneous user interface elements; and to regularly clean up yet another mess created when one or another of Word’s obscure features springs to life unbidden.

Based on seeing what happens when a product bolts on one after another “feature” on the basis of users being free to not use them, I believe the last thing any sensible 21st century software product should aspire to is to even remotely imitate Word’s approach to design.

That’s why I’d very much prefer to export or compile from Scrivener to some generally recognized interchange format (the currently supported RTF being one of several good choices), then use some external mechanism to finish the journey into tagged Word styles. I want as little of Word’s flawed design and implementation in any non-Word tool — especially Scrivener — as possible.

I say this as one who regularly needs to deliver a properly tagged Word document but who would like to use, say, Scrivener (or at least some other non-Word authoring tool) to reach that destination.

Cheers & hope this helps,
Riley
SFO