Macs and iOS devices have the benefit of not one variety of Rich Text documents, but two: RTF and RTFD. This article explores some of their features and limitations, and considers the problems of working with them alongside one another.
Rich Text Format, RTF, is one of the early formats based on mark-up languages and was developed by Microsoft’s Word development team in the 1980s, being first released in Microsoft Word 3 in 1987. The current version is 1.9, which appeared over ten years ago in 2008. Unlike proper mark-up languages, it was never intended to be human-readable, and amazingly is still fundamentally based on 7-bit ASCII plain text rather than full Unicode encoding. For example, the word Café is usually encoded in RTF as
Caf\'e9, and Unicode more generally uses escape sequences such as
\uc0\u10140 with a specific font declared in the document’s font table.
In addition to styled text, RTF supports the embedding of certain image formats and some other types of graphics, but falls far short of most modern standards for included content. It also doesn’t specify page layout.
In the late 1980s, when the NeXTSTEP operating system was being developed for Steve Jobs’ NeXT computers, it was decided to address some of the shortcomings of RTF in a derived format, Rich Text with Attachments, or Rich Text Format Directory, RTFD. This relies on a feature of NeXTSTEP in which files can be packaged together in a directory which then looks and behaves like a single file. This is done by giving the package directory an extension of .rtfd, and within it storing RTF text content in a file named TXT.rtf alongside separate files containing the included content such as images. This was implemented in the NeXT bundled text and Rich Text editor TextEdit, which made its way with RTFD into Mac OS X.
There’s an immediate problem here: aside from macOS and NeXTSTEP, other operating systems such as Windows and Linux don’t support directories acting as packages. Furthermore, regular RTF was a part of Microsoft Word, whereas the upstart RTFD wasn’t. So ever since then, like two misbehaving children, RTF and RTFD have lived their own separate lives, and getting RTFD to work in Windows has been fairly futile, just as getting Apple to support richer RTF has also failed.
This is well illustrated in the behaviour of TextEdit in macOS. Create a styled text document and TextEdit offers you the choice of saving it in RTF or RTFD. The moment you try to embed an image in it – even in a format elsewhere supported by RTF – and TextEdit forces the document to be converted to RTFD.
This schism goes deeper into macOS too. Using another editor, create an RTF document with an embedded image, and QuickLook’s thumbnails ignore the image, as does QuickLook’s preview feature. Pages is as irritatingly partisan as TextEdit, and every version of Microsoft Word ignores RTFD packages as if they were diseased. Thankfully some third-party apps still behave like adults: my favourite for working with both formats is Nisus Writer Pro, for example, which dares to give the user a choice, and can be invaluable for converting between the two formats.
RTF is undoubtedly the more convenient even if you’re not interested in cross-platform compatibility. However, you can pay for your convenience. Embed a 205 KB PNG image into a couple of lines of text, and you might find the image is converted into 4.9 MB of TIFF data in the RTF file. This is embedded as an object within the RTF source.
Because an RTF document is a single file, when opened by a sandboxed app in macOS, a single quarantine flag is written to it. The file has a UTI of public.rtf, a MIME type of text/rtf for transfer over the Internet, and the standard extension of .rtf.
For text-only documents, an RTFD package is inefficient, but the format comes into its own once you start embedding other content. Not only can you embed a wider range of images and graphics files, but you can also include PDF. These appear in TXT.rtf as linked NeXTGraphic files, revealing their origins. If you take care, you can even edit raw RTF source to remove such included pages.
Attachment of quarantine flags to RTFD is more messy: instead of putting a flag on the .rtfd package, each individual file within the folder gains its own quarantine flag. The package has a UTI of com.apple.rtfd, and uses the extension .rtfd. But, being a directory full of files, it doesn’t qualify for a MIME type, and even if a recipient is able to read RTFD, you’re going to have to put it into an archive format such as a Zip file to send it to them over the Internet. iCloud handles both RTF and RTFD documents transparently, though.
There are some really neat things you can do with RTFD documents. Assemble one containing a page or two of PDF, for example. Open the RTFD folder in the Finder, select one of those PDF pages and then use a Finder Quick Action on it to add annotations. Then re-open the original RTFD document, and those annotations now appear in that too. You can use similar actions with other included files, something that no RTF file can approach.
You’ll sometimes see RTFD packages referred to as ‘bundles’. They’re not: a bundle has quite a tightly prescribed and more complex structure, like an app or other code bundle, and within it is a Property List file named Info.plist. By comparison, RTFD packages are flat and far simpler. You still have to be careful though if you try to manipulate them directly.
So when should you use which?
RTF is ideal if you need others, who won’t be using Macs or iOS devices, to be able to view or edit the document. But it’s quite limited in what it can do, most particularly the types of content which can be embedded. If you’re just concerned with styled text without images, it’s compact and readily-accessible. It also still doesn’t use Unicode as its native text format, so for non-Roman scripts can be a pain.
If you’re confident that your document will only ever be opened on a Mac or iOS device, and particularly if you want more adventurous inclusions such as PDF, then RTFD is probably going to give you the flexibility you want. But it too hasn’t been modernised to work natively in Unicode, which is bizarre when everything else (apart from PDF) does.