Exporting styles (especially block quotes)

I’ve been playing with Scrivener for about a week now, and although I love it, I’m worried that it won’t do a few things that I really need it to do. Here’s the biggie…

I’m writing my dissertation in philosophy and sometimes I need to quote a paragraph or more from another text. The standard way to do this is to block quote it (i.e. indent both sides). I have created a style in Scrivener that does this, but when I compile a draft or print, the right indents get dropped. (Yes, I’ve tried every permutation of the “preserve formatting” and “override text formatting” checkboxes. Also, I’ve tried opening the compiled drafts in Word, Pages, and Mellel and exporting as both RTF and DOC. The problem persists.) Is it not possible to print or export block quoted text in Scrivener? That would make me very sad.

The broader concern is that Scrivener’s “you can always clean it up later in a word processor” approach means that I can’t really style as I write at all. Is there really no way to export styles? Can’t I somehow flag a piece of text as a title or a section header in such a way that I can then pick that style up in my work processor and change the formatting of all the titles or headers at the same time? In the case of the block quote problem, it wouldn’t really matter that the right indents get dropped if I could just quickly edit the “Block Quote” style and fix it, but I can’t seem to do that. I’m pretty sure this data can be contained in the .DOC format because if I create a document in Pages, style it, save it as a .DOC, and then open it in Word, all of the style names are preserved.

And just because it frustrates me, why do footnotes disappear when I open a compiled draft in Pages, but not when I open it in Mellel?

Steve (wishing he could hit the “purchase” button in peace)

I have just tested it again to confirm that nothing is haywire, and there is indeed support for retaining indent ruler settings when compiling. I created a test project with two identical files, each with a block quote in them. On the second, I checked off “Preserve formatting” in the Inspector, and then compiled with “Override text formatting…” turned on. The first test section lost the blockquote (which is proper) and the second test section retained all formatting, including font and ruler styles (left and right indent). This was opened in Nisus, Mellel, and TextEdit. They all opened it just fine. Export format was RTF.

I have attached this test project below with an exaggerated right-indent.

indents.scriv.zip (25.8 KB)

What do your right indents look like, in the project itself? Is the blue (or graphite) downward-pointing arrow moved inward on the right? That’s the only way I know of to indent, but perhaps you’ve done something else that isn’t conveying correctly to other word processors.

Also, what happens when you drag the exported RTF back into Scrivener?

The broader concern is that Scrivener’s “you can always clean it up later in a word processor” approach means that I can’t really style as I write at all. Is there really no way to export styles?

That depends on what you mean by styles. If you mean true styles where text is formatting according to some central style manager, then no. Scrivener uses Apple’s style system, which is just a write-once system. I like to call it Favourites instead of styles, because it is really just a format brush. Once you apply it there is zero connexion back to the “style” that created it.

I’m pretty sure this data can be contained in the .DOC format because if I create a document in Pages, style it, save it as a .DOC, and then open it in Word, all of the style names are preserved.

You are absolutely right, but now you are talking about technology that isn’t available to the Apple text system. The doc format is certainly capable of styles, and Pages is pretty good at working with Doc files, however Apple never thought it a good idea to bring that ability to the rest of the system, leaving it locked up in Pages. Everyone else is stuck using these write-once favourites, and doc exporters that are extremely simplistic.

And just because it frustrates me, why do footnotes disappear when I open a compiled draft in Pages, but not when I open it in Mellel?

It frustrates everyone involved, developers included!

This happens because Pages isn’t a very good RTF reader. Since Apple again saw no wisdom in giving developers access to the Pages format, let alone a pre-packaged exporter they could use, everyone is locked out of it. You can’t use RTF because Pages sucks at RTF. You can’t use doc because everything else is stuck with a bad doc exporter. :slight_smile:

It’s especially annoying because Pages is an Apple product and thus a Mac mainstay, so everyone just assumes that Pages should work with everything, or that making software work with Pages should be simple. Write to Apple and complain. That’s the best we can do.

Scrivener works best with word processors that are adept with RTF, since that is the format that has the best support in the system, and Scrivener’s greatly enhanced that support beyond what the system can provide by itself. So Nisus, Word, and OpenOffice are the best Mac-available word processors. Mellel does pretty well, but is not quite as fully featured in terms of RTF import.

Anyway, give the test project I created a shot and see if it works for you.

Just a few things…

  1. I am very impressed by the speedy reply. Nice work.
  2. It turns out the block quote export error was located between the monitor and the chair. I hadn’t set the right margin in far enough to show up once the document was in page layout view. Silly me.
  3. Although it is probably true that Pages sucks at importing RTFs, it’s surely possible to generate RTF output that is Pages-friendly (RTF is hardly a complicated file format). So, the best you could do would be to work around Apple’s bugs and make your product compatible with theirs until they get around to fixing things. (Isn’t that what everyone does with Microsoft products?) As you say, everyone will expect your product to work with Pages. Meeting customer expectations is a good thing.

Thanks again,
Steve (who will now very likely hit the “purchase” button at the end of the trial period)

Ah, that’s a sneaky one. I’ll have to file that away for future support cases.

In a sense, that is what already happens. RTF, given the nature of the format, can be read in an à la carte sense. You can write a simple RTF editor that only understands bold, and you would get bold text, but everything else would be ignored and lost. To apply that simple analogy to your suggestion: it wouldn’t make sense to code an RTF exporter that only exports bold, because that is what will happen anyway with the receiving application. At a much more complex level, that is what is happening with Pages. Scrivener puts things in the file, using standard RTF specifications to do so, but since Page’s wasn’t coded to understand the full specs, it simply discards what it doesn’t fathom. Creating an RTF that didn’t have footnotes wouldn’t actually result in anything different at all.

So, that leaves flattening. That is, generating lookalikes to real features. Footnotes are a good example there as well. You can insert a “[#]” in one spot, and then at the end of the document, a corresponding “[#] Content of footnote”. It will be an pseudo-endnote, by necessity, but at least you get the data. You can already do this by using RTFD, which is Apple’s extended RTF format which they decided to create instead of implementing proper inline media support (go figure). When you export via RTFD in Scrivener, you will get flattened footnotes. So, that’s one (admittedly not very useful way to get footnotes into Pages). RTFD is the second best way to communicate with basic Cocoa Mac applications (like most of them), and Pages.

The best way, and it is a way that a number die-hard Pages users around here use, is conversion. Export your RTF from Scrivener as per normal, but then load it into a word processor that is both RTF and DOC savvy. OpenOffice is the best free alternative; Microsoft Word, obviously is going to be the best if you have it; and it might be that Nisus Writer Pro can do this as well. So the idea is to generate a good DOC file (which alas, Scrivener cannot do as Apple’s doc exporter is even harder to fix) from the original RTF file. Pages can do DOC files, so problem solved.

It seems like a lot of work, but given that compiling to the word processor is not something you’ll likely be doing terribly frequently, it’s not too much of a hassle. For most people anyway.

Hopefully this paints a better picture. I think Scrivener is doing as much as it can, given the constraints of the situation (without abandoning all feature development for at least a year, just to work on custom-coded exporters for all the popular word processors). The alternatives are either to fake features, that is provided; or provide some viable route, which is also provided via a full featured universal format that can be adjusted to work with Pages.

Just to elaborate on what Ioa has explained, from a technical perspective (not that Ioa’s wasn’t technical!):

First, you need to understand that Scrivener is coded by one person (me!), as we are a very small company. Thus we don’t have a whole team able to develop importers and exporters. Instead, I rely on the standard Apple OS X importers and exporters as a base - the ones they provide to developers, which are “showcased”, if that is the word, in TextEdit. I have then expanded on these or written importers or exporters for formats not provided. For instance, I have written my own importers and exporters for the Final Draft FDX format, and I have greatly expanded on the standard RTF importers and exporters provided by Apple.

A note on this: Because the OS X text system doesn’t support footnotes or comments out of the box, none of the importers or exporters they provide to developers include any support for footnotes or endnotes, including the RTF translators. But because RTF is essentially a marked-up plain text format, I have managed to hack and extend the provided translators to add support for headers and footers, images, footnotes and comments (none of which are supported by the standard importer or exporter - just try saving or loading complex RTF files in TextEdit).

Now, Pages can import four main formats for import (ignoring the .pages format itself, which I’ll get to in a bit): .doc, .docx, .rtf and .rtfd.

Let’s start with RTF. You suggest:

My response to that would be: tell that to Apple! (And actually we’ll have to disagree about how complicated it is: biblioscape.com/rtf15_spec.htm .) What do you mean by generating RTF output that is Pages-friendly, though? RTF is a format with specifications. Scrivener does its best to abide by those specifications. It’s not that Pages does things in a funny way, or could read footnotes if you inserted them in the RTF in a different way - it’s just that Pages uses the same RTF importer/exporter that TextEdit uses, with all its limitations (they have not extended it as I have). In fact, their RTF importer is even worse as it ignores page breaks as well as footnotes, comments, images, headers and footers and so on.

So the fault here is entirely Pages’, not Scrivener’s. Scrivener generates good RTF which can be read in any full-featured word processor that properly supports RTF - Word, Nisus, Mellel, OpenOffice and so on. There is nothing Scrivener can place in generated RTF files that will force Pages to read in footnotes or images and so on, any more than Scrivener can force TextEdit to read these things, or any more than Scrivener can force a plain text program to read images. Pages just ignores them, because Pages does not parse all of the RTF, only the basics.

So, what about the other formats?

Ioa suggested RTFD, and this is indeed most likely the best format for going from Scrivener to Pages. Pages at least reads images in from the RTFD file (whereas it doesn’t from RTF). But the RTFD format doesn’t support footnotes, so Scrivener “flattens” them and places them at the end of the file - so they will appear in Pages, but not as “true”, Pages footnotes. You would need to reformat them to be true footnotes again. This is just a limitation of the RTFD format. (Note: Scrivener doesn’t flatten footnotes for RTF, as that format supports true footnotes so it would be silly for Scrivener to flatten them when other word processors can read them properly - it is just that Pages ignores them.)

Finally, we come to .doc and .docx. Now, Pages fully supports both these formats, and can read headers and footers, images, footnotes and comments and so on. But sadly, Scrivener doesn’t fully support these formats. Scrivener’s export to these formats cannot include footnotes, images, comments or headers and footers. This is because Scrivener - being coded by a one-man team - relies on the standard .doc and .docx exporters provided by Apple to developers in the Cocoa text system, which have these limitations. Even worse, these exporters strip out indents and line spacing too! But unfortunately, unlike RTF, it’s not possible for me to extend these formats to add these features. .doc is a binary format, which means that you can’t just open it up and add the necessary codes; .docx is XML-based, but a complex one. I can’t just search for terms and add in the necessary codes as I can with RTF - I would need to write a .docx exporter from scratch. And I don’t have the resources to write my own .docx or .doc exporters, as that would take me about a year, doing nothing else!

Finally, there is the .pages format itself, of course. But this isn’t a possibility either, as Apple don’t make it available to third-party developers. (I would love to support the Pages format, and would willingly spend a few months trying to support it were it worth it.) For a start, while they provide developers with exporters to formats such as .doc, .docx, .html, .odt and more, they do not provide developers with any exporters to the .pages format. (They never provided AppleWorks importers or exporters, either.) I can’t write my own, either. I mentioned above that I wrote my own translators for the FDX format - this is because I got in touch with Final Draft and they were kind enough to make the specifications available to me, so I was able to write the XML code based on their specs. But Apple have made it clear that they don’t have any intention to make the .pages XML format public. They posted some basic information on the format for Pages 1.0 a few years ago, which you can find here:

developer.apple.com/mac/library/ … ction.html

But the format has changed since then, and as they say:


And they haven’t published anything since.

Thus, currently the best option for going to Pages - if you want to retain everything - is, as Ioa says, to export as RTF and then to open the file in Word and Save As .doc or .docx. Then open the resulting fully-featured Word-generated .doc or .docx file in Pages.

Ultimately, Pages was designed as a Word alternative. Apple have concentrated chiefly on it being able to exchange files with the two main Word formats, and don’t seem to have much interest in making it interoperable with a wider range of programs (no Open Office support, for instance).

I hope this gives you some context. While meeting (entirely reasonable) customer expectations is indeed a good thing, sadly we have to operate with what we have, and currently there isn’t much we can do about the limitations in the .doc or .docx exporters, or about Pages’ RTF limitations. It’s an unfortunate Catch-22 situation in the case of Pages.

All the best,

P.S. Please do take the time to send your feedback to the Pages team, too:


Maybe if enough users ask them for decent RTF import/export, with comments, footnotes, headers, footers and images, they might listen. Be sure to tell them why you need it - for collaborating with word processors and writing programs other than Word (not just Scrivener, but Nisus, Mellel etc too). I mean, if I can add support for these things, I bet the Pages team could add it in a few days.

You guys are great. Your in depth explanations and helpful advice do make me much more comfortable taking the Scrivener plunge.

I always completely understood the problem with exporting .DOC (which is an abomination). I’m now convinced that nothing better can be done with .RTF (which is sad, but clearly Apple’s fault). I had been assuming that Pages could at least export and then import its own .RTF files without losing footnotes and that you could mimic how it did that. Apparently, as I just tested, it cannot do even that. Yipes!

I will be filling my complaint with Apple.

It seems like the best solution, on your end, would be a better DOCX exporter, since Pages reads those pretty well, in my experience. That would also, in theory, allow you to hold on to style markers (which would be a nice big feature addition for those of us who love styles). But of course developer time is always limited and that may not be a very high priority. Put it on my wish list.

From my end, I now have things exporting to .RTF in a way that Mellel and I are both relatively happy with. Thanks again for all the help.

Time to get back to writing…

Steve (who is now only waiting to hit “purchase” until the end of the trial period to increase his chances of being in the free upgrade range for 2.0)

That would be nice in the long run, certainly. Perhaps when Scrivener is more mature - at version 2.5 or 3.0, who knows - then I might get more time to look into something like this. I tried to take a look at the .docx documentation recently… And it’s a behemoth. (Also, Apple’s implementation of tables and lists - especially lists - in the text system are a bit “black boxy”, making it very hard to code importers or exporters that would be able to create or interpret tables or lists… Which may lead needing to implement a different tables and lists system. It would certainly be “down the rabbit hole”!)

RTF does actually support styles - just not the Apple-generated RTF, and that’s one thing that is a bit more difficult to hack into the existing exporter. Also, Scrivener itself hasn’t got any real understand of styles. You can create TextEdit styles - the standard OS X ones that are built into the ruler - but “styles” is a bit of a misnomer for them; they are more like “favourites”. Certainly styles comes up around here from time to time, but that’s another rabbit hole (although one definitely on the radar). It entails first coding a styles system for Scrivener, but then, once a styles system exists, user expectation will be for the styles to get carried across to the various formats, which again leads back to having to write my own importers/exporters for everything.

Hmm, maybe one day we’ll be big enough to afford a team for all of this sort of stuff!

Nearly there…

All the best,

This leads back to an old question of mine: is it the RTF 1.5 spec you are aiming at?

Most of the RTF code is created by Apple. I only add a few extra bits - images, footnotes, comments and headers and footers. Although I often use the 1.5 RTF docs as a reference simply because the Biblioscape presents them nicely, I have ensured they meet 1.9 criteria.

I don’t recall you asking this question before - what are you driving at (I know you’re driving at something :slight_smile: )?

:slight_smile: you know me…
It was the discussion about a possible solution for round-tripping Sente documents:


And here:


I’m not sure how bookmarks could correspond to Scrivener Links. Bookmarks just allow you to define a range in the text that you can jump to from the bookmarks pane in Word, for instance. Scrivener Links are links from one part of a document to another document. There’s nothing in Scrivener that really corresponds to RTF bookmarks.


I think the idea would be that since Scrivener exports a bunch of documents into a single manuscript, the whatever Scrivener Links that pointed to other areas of the draft would do so via bookmarks. But is that something that RTF can do? I’ve never seen an RTF document link to itself like in a table of contents scenario, like PDF can do.

No, that’s what I mean - RTF bookmarks can’t do that. They’re not comparable to Scrivener links, they just allow the RTF editor to create a list of bookmarks in a window somewhere which you can click on to go to. Nothing more than that.

No, the idea was simply to bookmark Sente-generated titles in an exported RTF with an ID (or better UUID). Such bookmarks could be used to write in import routine that splits the RTF again into its original Sente documents (taking hierarchy and sequence from the binder and not the RTF document). This would cover 90% of my round-tripping, collaboration, and proof-reading needs.

The idea of RTF hyperlinks (not Sente links) I brought up after Keith said that RTF does not offer bookmarks in a way that could be used to this end. I suggested that RTF hyperlinks could replace bookmarks for this purpose, that they could be based on Sente links, and possibly define their own protocoll (sentelink://).


I’ve just been playing around with Word’s INCLUDETEXT functions, and have looked at the result of linking multiple RTF files into a single RTF master document. Word copies the full text of each piece into the master document after a delimiter describing the link. The delimiter looks like INCLUDETEXT "Macintosh HD:Users:greg:Spool:foobar.rtf" \\c MSRTF I don’t know anything else about this format; for example, whether the specification of the included file path can be relative. Perhaps it would be possible for Scrivener to insert these optionally into the compiled draft to identify which Scrivener files they came from, and then later to read back edited sections into their original files.

There seem to be side effects of using INCLUDETEXT; for example, in certain Word view modes the text is displayed with a grey background.

Anyway, the embedded link to specific included files appears potentially useful.

Greg Shenaut

I too am a brand-new user with an issue with Block Quotes. I usually write articles in LaTeX, but for the first time in a zillion years I am writing a book with one co-author, and everything needs to be in Word.

My question: Once I’ve set up a Block Quote style as discussed, is there any way for me to preserve the style of the Block Quote but only of the Block Quote when I compile to Word, without having to make the Block Quote its own separate chunk of text (scrivening?). I really want that Block Quote indented and single spaced in the compiled Word draft, but for the rest of the compiled Word draft I really want 12 pt Courier double spaced, no matter what I typed.

Not at the moment, no - the only way would be not to have the formatting overridden on Compile. (Remember that you don’t have to have the formatting overridden - you can write using the formatting you want to be used in the final document - just turn off “Override formatting” in the Formatting pane of Compile Draft. If you turn off that, the text of documents will be exported exactly as-is, and block quotes will therefore remain intact.) Version 2.0 will allow you to define certain blocks of text within a document to be left alone.
All the best,

I think this means Scrivener just isn’t going to make sense for me until 2.0 comes out.

For me, Scrivener’s big advantages are (a) being able to work on whatever size chunks I want to and rearrange, etc., and (b) being NOT WYSIWYG–my late 40’s eyes really like being able to type in Optima in 14 or 18 pt font on screen, and having this compile to the Courier 12 pt double-space to deliver the manuscript.

But in nonfiction, I really need block quotes, and this means that I have to break each chunk of writing into before the quote, the quote, and after the quote, which is not the natural thing to do, and in addition, I need to set up the block quote in Scrivener to display as 12 pt Courier if that’s what I want in the output.

Back to Word (ugh!) and I’ll check back in when 2.0 is released.

Fair enough!