The compile formats table shows all the formats supported by Scrivener, with commentary on their usage.
For most word processor-based workflows, including Microsoft Word, RTF is the best option. Nearly every word processor provides solid RTF import and export capabilities, and some even use RTF as their native file format. The one major exception to this is Pages, which has limited RTF support. You should use .doc or .docx with pages, and for the best results the improved converters should be enabled.
RTF Files Missing Some Features? With the default OS X configuration, when you double-click on RTF files in the Finder, they will be opened in TextEdit, which doesn’t support all RTF features. To open an RTF file in your desired word processor, you should open the word processor first and use File ▸ Open...
. You can use the “Get Info…” palette in Finder to change the software association with RTF either for one or all files.
Format | Extension | Description |
---|---|---|
General Purpose Formats | ||
N/A | Used to immediately print the compiled draft | |
The Portable Document Format is a (largely) uneditable format that can be opened on nearly any platform and device with minimal to no loss of display quality. | ||
Rich Text | .rtf | General purpose rich text format supporting multiple fonts, images, tables, bullet points, footnotes and comments. The standard internal format for Scrivener, and the base underlying format used for most conversions in this table. |
Rich Text with Attachments | .rtfd | Apple’s proprietary extended RTF format. Useful mainly for exporting to other Apple Cocoa applications such as TextEdit, especially if image support is needed. Incompatible with most word processors and all other computing platforms. |
Microsoft Word 97–2004 | .doc | Binary Microsoft Word document format. Use this if the target application cannot read RTF or DOCX files1. |
Microsoft Word | .docx | Microsoft’s modern XML based Word document format; preferred for usage with Word and compliant word processors1. |
OpenOffice | .odt | The OpenDocument Format is a free full-featured XML document format, supported by many word processors, including OpenOffice and Google Docs1. |
Plain Text | .txt | UTF–8 (Unicode) plain-text file. Plain text contains no formatting but can be opened almost anywhere, on all platforms and devices. |
Scriptwriting Formats | ||
Final Draft | .fdx | For transferring your script to Final Draft, this is the best option unless you have an older version of Final Draft than version 8. Maintains synopses (as scene summaries), scene titles and custom script element formatting. |
Final Draft 5–7 Converter | .fcf | Use the FCF converter when working with an older copy of Final Draft. Supports only basic screenplay formatting. |
Fountain | .fountain | A plain-text screenplay markup format ideal for working on the go. |
E-book & Web Support | ||
ePub eBook | .epub | Generate feature-rich e-books for use in portable reading devices that support the ePub format, such as the Sony Reader or iPad (ePub files can be dragged into the iTunes Library to import them into iBooks). |
Kindle eBook | .mobi | Generate feature-rich eBooks for use in portable reading devices that support the .mobi format, such as the Amazon Kindle. Requires Amazon’s KindleGen, which is only available for Intel based Macs. |
iBooks Author Chapters | .docx | The .iba format cannot be directly supported, so this method will export all sections of the book (going by page breaks) to individual .docx files, which can be easily imported into iBooks Author. |
Web Page | .html | Creates a single HTML file suitable for web-publishing. |
Web Archive | .webarchive | Much like HTML, but conveniently packages exported image files into a single bundle, using Apple’s webarchive format, which can be opened by Safari (including the Windows version) and various Mac OS X applications. Not compatible with most other browsers. |
MultiMarkdown Post-processing | ||
MultiMarkdown | .md | Export a plain-text MultiMarkdown file, useful for archiving, or further custom post-processing. |
MultiMarkdown -> LaTeX | .tex | Exports a LaTeX format file with full MultiMarkdown parsing. Note that if you are intending to export a LaTeX file that has been handwritten in Scrivener (without MMD), you should use the plain-text exporter, above. |
MultiMarkdown -> RTF | .rtf | Export an HTML-derived RTF file with partial MultiMarkdown support. Note that the RTF files generated in this fashion will be limited in features and formatting support in the same way as HTML, and is not equivalent to Scrivener’s standard RTF exporter in the word processor compatibility tables. |
MultiMarkdown -> Web Page | .html | Generates a W3C compliant HTML5 file, suitable for web-publishing or further XML post-processing. |
MultiMarkdown -> Flat XML | .fodt | This ODF compatible format is suitable for bringing your MMD project into the word processor world. At the time of this writing, LibreOffice is the main OpenOffice fork that can read .fodt files without modification. |
MultiMarkdown -> PDF | Using the LaTeX typesetting engine, produces a simple ready-to-print PDF file. This option will not appear unless pdflatex has been installed on the system. |
The provided table shows which file format constitutes the best option when exporting for use with several popular applications, and which features are supported by those programs. If you are using the improved converters, then select the format appropriate to the word processor (although RTF will most likely be just as good, and compile faster, so try that first). If the word processor you favour is not available as a specific format, use the table to select the best format. The one exception is iWork Pages. You should use DOCX with Pages.
Application | Best Format | Comments | Footnotes | Lists | Images | Head/Foot | ToC |
---|---|---|---|---|---|---|---|
Microsoft Word | RTF | X | X | X | X | X | X |
Nisus Writer Pro | RTF | X | X | X | X | X | X |
OpenOffice.org | RTF | X | X | X | X | ||
RedleX Mellel | RTF | X | X | X | X | X | |
Papyrus | RTF | X | X | X | |||
Apple Pages | RTFD | X | X | ||||
TextEdit | RTFD | X | X |
Explanation of features and how compatibility is determined:
Not included in the table are basic formatting features. Most word processors support these with only a few exceptions, as listed below (if the word processor is listed next to the formatting feature, it does not support it):
[New in 2.3] PDF files offer a great way to archive and distribute copies of your work. They look great almost everywhere you open them, can be opened on nearly anything from smartphones to workstations, and are—while not technically, effectively—static. That is, they cannot easily be edited, making them good for archival and proof distribution. Many PDF readers also come equipped with annotation tools.
There are two important modes for generating PDFs to be aware of, in the Print Settings compile option pane. If the custom converters have been enabled, this pane will appear and provide a choice between “Publishing” and “Proofing”. These are general terms, so you should read the full implications of choosing either mode when making your selection. The default is “Publishing”, which follows the model of prior versions of Scrivener. This pane is also where URL based hyperlinks can be configured.
PDFs created using the Publishing layout engine will by default include a software outline, commonly used in PDF viewers to display a navigable table of contents in a sidebar or menu.
Exported PDF files (both Publishing and Proofing) can also contain clickable internal links, taken from any document links in the text. Going back to the notion of a printable table of contents, if you followed the directions put forth there, you will have a list of binder item names linked to the original names in the binder. In the PDF, these names will be hyperlinked to the correct spot within the PDF itself. With the Publishing layout engine, you can modify how this is done, in the compile options pane, PDF Settings. Since a table of contents created in this fashion is merely a formatted list of document links, it follows that any links you create within the main text itself will also be linked.
[New in 2.3] Included in version 2.3 and greater, the Aspose document conversion engine is used for importing and exporting Microsoft Word (.doc and .docx) and OpenOffice (.odt) formats. In previous versions of the software, the default Mac OS X convertors were uses, which are fast, but have limited features and formatting problems. The Aspose engine uses Java, which on newer Macs is not installed by default. Installing Java is very easy to do. When you first request Scrivener to use the new converters, you will be directed to install Java with a single button click. This will download the latest version of Java from Apple’s repository and automatically install it into your operating system. What you gain for doing this is the ability to compile .doc/x or .odt files at the same level quality as the RTF format.
Should I Use the New Converters? If RTF has worked well for you in the past, there is no need to switch to the new converters. You will not gain anything by doing so—Scrivener in fact starts with RTF, and uses the Aspose engine to convert that RTF to the final format for you. Thus for most usages, RTF is still the preferred format; it is readily supported by most word processors and fast.
However, some applications (particularly Apple Pages and mobile office suites) cannot read RTF, or do a poor job of it. In these cases you will want to use a Word format instead, and the Aspose converters will provide the best possible option for doing so.
If you would prefer to not use the improved converters, you will need to disable them in the application Import/Export preference tab, not the compiler. This switches the feature off globally. They will no longer be used for import or export in any way.
The following table shows which file format constitutes the best option when exporting for use with several popular scriptwriting applications.
Application | Best Format | Notes |
---|---|---|
Final Draft | FDX | Supports comments and footnotes (as script notes), synopses (which become scene summaries), titles, dual dialogue (dialogue marked using “Preserve Style” in Scrivener becomes dual dialogue in Final Draft), revision marks, custom element formats. |
Final Draft 5–7 | FCF | FDX is always better, so only use this if you don’t have access to Final Draft 8 or later. FCF is essentially a plain text format and so any formatting such as bold or italics will be lost. Also note that it only supports the basic script elements—Scene Heading, Action, Character, Dialogue, Parenthetical and Transition. See below for important tips which will help avoid strange characters appearing in the export. |
Fountain Markup | .fountain | Fountain is a Markdown inspired plain-text format, and is thus suitable for writing screenplays on a wide variety of devices. Scrivener will convert its built-in scriptwriting format to Fountain’s markup automatically. |
Movie Magic Screenwriter | TXT | See below for important tips which will help avoid strange characters appearing in the export, and ensure proper element conversion. |
CeltX | TXT | As for Movie Magic Screenwriter. |
Montage | RTF or TXT | Montage will do a decent job of importing script files saved in either the RTF or TXT formats (if you use TXT, follow the same rules as for Movie Magic Screenwriter and CeltX). |
The guidelines below should be followed when exporting to the FCF or TXT formats for use with scriptwriting programs:
To avoid strange characters appearing in the export, the following preferences should be enabled in the Text Options compile pane:
In the Separators pane:
When using the TXT format, along with the above settings, “Convert indents and paragraph spacing to plain text” should be enabled when exporting to scriptwriting programs such as Movie Magic Screenwriter and CeltX. This ensures that they will recognise the elements correctly, as these programs read the whitespace and use it to convert the text to the relevant script types.
Read Working with Final Draft for more detailed information on both export and import processes with Final Draft 8 and higher.
The iBooks Author format cannot be directly saved to. As is the case with Pages, Apple has not released any support for third-party applications. Fortunately, it is fairly easy to import material into the program. Given how it is designed, it works better if each major section of the book (such as a chapter) is organised into individual files, rather than importing one large document; its capacity to split up an existing imported document is rather limited. If you intend to publish your book using iBooks Author, you should use the “iBooks Author Chapters” compile format. This will cut your book into separate .docx files wherever a page break appears in the text. You can then just drag the entire folder of compiled files into iBooks Author and continue your work in that program.
The key to this is to make sure that page breaks happen where you expect them to. This is typically handled in the Separators compile option pane, with the “Page Break Before” inspector checkbox being used in those cases where Separators cannot address outliers like a preface, copyright page, or table of contents. When using the iBooks Author format, the Separator’s pane will list “Chapter Break” as an option, instead of “Page Break”. This setting marks where one file will end and the next will begin.