We’re often advised to make best use of document metadata, those document-specific settings for author, title, keywords and so on which all the best apps offer. This article looks at how well it performs when created by different apps, in the two main types of Rich Text documents, single-file RTF and RTFD packages.

I used four different apps in my quest: TextEdit 1.14, as bundled with macOS Mojave 10.14.6, Apple’s Pages version 8.1, Microsoft Word 16.27 from the current release of Microsoft Office 365, and my favourite word processor Nisus Writer Pro version 3.0.2.

The first important observation is that only three of those four apps support document metadata: and it isn’t TextEdit which omits them, but Pages. It’s been a while since I last used Pages for any serious work, but this omission came as something of a shock. Currently, Pages can neither edit nor display document metadata such as Keywords or Comments, unless you know of a hidden mechanism which isn’t mentioned in its Help book.

For what many consider to be such a lightweight app, TextEdit does remarkably well, apart from its irritating implementation of the document metadata editor in a floating window which vanishes the moment you switch to another app. It’s accessed through the Show Properties command in the File menu, which is fairly obvious.

TextEdit embeds document metadata within RTF and RTFD documents, using a standard \info section, such as
{\info {\title Maxillofacial} {\doccomm Anathematically} {\keywords Presdidigitation}}
to set, respectively, the title, comments and keywords.

When you’ve added metadata to these sections, they’re usually shown in the Finder’s Get Info dialog, and should be found by Spotlight search too (but see my article yesterday about the confounding problems in indexing files). The time and extra effort you invest in adding good document metadata is repaid.

Microsoft Word wasn’t such a great success story, though. As might be expected, Word’s document metadata editor is easy to access through the Properties… command in the File menu, and bigger than most users could ever need, with no less than five tabs, including one which allows you to create your own custom fields such as Disposition.

I saved my example document in both Word’s native .docx and RTF formats, Word not being capable of RTFD, as I reported previously. The Finder was only able to show one metadata field (Keywords) for the .docx version in its Get Info dialog, and none appeared at all for the RTF version. Spotlight search issues required re-indexing before it would find any of the metadata, although it worked fine with those in the .docx version.

Microsoft Word’s RTF is extensive and rambling compared to that generated by other apps. The metadata are still embedded in the RTF data within an \info section much as in TextEdit’s RTF, but that was buried in all sorts of overhead.

Nisus Writer Pro’s implementation is the best of all those tested: a drop-down pane with just two tabs, the first providing standard fields, and the second allowing you to define your own custom properties. This is opened using the Properties… command in the File menu. As Nisus Writer Pro is one of the surprisingly few apps which offers full use of both RTF and RTFD formats, I tested both. But what happened next was unexpected: the Finder’s Get Info dialog was unable to see these document metadata, and Spotlight search struggled to find them too, because of the problem which I described previously.

In the RTF source generated by Nisus Writer Pro, the metadata appeared to be correctly written, again in an \info section essentially identical to that used by TextEdit and Word. TextEdit happily opened these documents and accessed their metadata as expected, but the Finder and Spotlight were less cooperative.

Stranger still are the differences in QuickLook thumbnails between what should be almost identical RTF and RTFD documents. In Dark Mode, QuickLook showed each of the RTF and RTFD documents in white text on a dark grey background, except the RTF written by Pages, whose thumbnail was displayed in black text on white.

If document metadata written into the body of Rich Text isn’t as reliable as you might want, an alternative is to write the same metadata to extended attributes (xattrs). I have a couple of free utilities, SearchKey and SearchKeyLite, which do exactly that, using xattrs which are preserved in transit through iCloud Drive. You can’t read or edit those xattrs in your Rich Text editor, and the Finder’s Get Info only shows one of them (Keywords again), but document metadata saved to xattrs appears the most reliable for Spotlight search.

The usefulness of document metadata is largely determined by its accessibility by Spotlight search. If that regularly misses files altogether, the extra effort required to add the metadata is wasted. When it works, though, it’s valuable.