When the Mac was introduced forty years ago, it came with two bundled apps, MacWrite and MacPaint. Those who wanted to style their text used MacWrite, and the basic text editor Edit worked only with plain text. At some stage between System 2 in 1987 and System 7 in 1991, Edit was replaced by TeachText, written by Bryan Stearns. Initially that could only open a single document at a time, and that was limited to 32 KB of text, but it did support basic styling such as bold and italic, all set a single font. In 1994, with System 7.1.2, that evolved into SimpleText, with support for multiple fonts and sizes, but still limited to 32 KB of text.
Over the same period, Microsoft was developing early versions of its published specification for Rich Text Format (RTF), for cross-platform interchange, primarily between its own products. Although not intended to be a markup language like HTML, RTF is based on text, and at the time that meant ASCII not Unicode. While SimpleText didn’t extend to RTF, its equivalent bundled in NeXTSTEP did.
TextEdit
With the incorporation of much from NeXTSTEP as Cocoa in Mac OS X, Apple’s new operating system came with TextEdit, and its basic word processing tools including rulers, layout and spell checking. That could work in RTF, its variant RTFD intended to work better with graphics, HTML and plain text. By Mac OS X 10.3, TextEdit could also read and write documents in Microsoft Word format.
Microsoft continued to publish updated specifications for RTF with each major revision of its Word and Office products until the last, version 1.9.1 from 2008, detailing the format for Microsoft Office 2007.
Attributed Strings
TextEdit is built on Core Foundation’s CFAttributedString, a development of text Strings (in CFString), an opaque type that specifies how the characters in the string should be rendered and displayed. This is most often accessed through the Foundation class NSAttributedString, which comes in two public classes, read-only NSAttributedString and modifiable NSMutableAttributedString. Those in turn use a dictionary of attributes assigned to one or more characters to apply styles to them. Styles are not only intended to be used for display, but for guided access using Accessibility, and support embedded links to other data such as web pages. These internal representations go beyond what’s available in RTF specifications, in a set of custom extensions described here, in a conceptual guide long-since archived and never replaced.
The AppKit class library for macOS supports easy reading of RTF into NSAttributedStrings, and writing those back out to RTF to save them to storage. Most recently, with Monterey, Apple has added another type of styled text to the API as a value type, a structure named AttributedString, that appears aimed primarily at SwiftUI and those using it.
Dark Mode
The greatest challenge to TextEdit since its release in Mac OS X has been Mojave’s Appearance modes, and nearly six years later it’s still wrestling with how best to cope with Dark mode. Purists who continue to see text editors and their rich text relatives as constructing documents for print insist that the standard appearance, regardless of the user’s choice of Appearance mode, should be black text on a white background, and that’s the model still underlying TextEdit today. Those of us who only ever view documents on displays, particularly those who prefer Dark mode, find that glaringly inappropriate, to the extent that I wrote my own Rich Text editor DelightEd to do what TextEdit refused.
Since then, TextEdit has begrudgingly offered a View option to Use Dark Background for Windows, but that hasn’t yet been added to its Settings, and is only available in Dark mode, so is easily overlooked. This is despite Apple adding support to its RTF engine to generate text that looks right whichever Appearance mode is in use. This consists of an expanded colour table defining textColor, to be used for such bi-modal text, as implemented in macOS, used by DelightEd, but spurned by TextEdit.
Yet the very first paragraph in Apple’s Best practices for Dark mode reads:
“Avoid offering an app-specific appearance setting. An app-specific appearance mode option creates more work for people because they have to adjust more than one setting to get the appearance they want. Worse, they may think your app is broken because it doesn’t respond to their systemwide appearance choice.”
Maybe this will finally be addressed when Apple rewrites TextEdit using SwiftUI.
The Eclectic Light Company 