If you’re running Mojave, try a little experiment. First, switch to Dark Mode. Then open Apple’s Calculator, in the Window menu set it to Show Paper Tape, then tap in a few calculations to put some text on that tape. In the File menu use the Print Tape command. You should see something like this:

You can call this a bug if you like, but this is so general a problem that it must surely now be a feature: Mojave’s much-vaunted Dark Mode makes a nonsense of printing. The reason for this is Apple’s inability to temper the longstanding principle of WYSIWYG with its novel concept of Appearances, and a bit of common sense.

Underlying the macOS interface is a large support library, AppKit, which contains most of the features which the user recognises as Cocoa. Within AppKit, there is extensive support for views, which now includes displaying them in both Light and Dark Modes, as the two types of Appearance. Apple devoted two long and intense sessions at WWDC last June to consider the ins and outs of designing for Dark Mode, and implementing it in apps. Look through the slides from those, though, and you won’t find any mention of printing.

Now that Apple has abandoned all its systematic guides to developers, you won’t find any mention of Appearances or Dark Mode in its former accounts of AppKit or printing. Instead, developers are offered sketchy overviews, where for instance, Supporting Dark Mode in Your Interface simply states
“Apps should support both appearances, but there may be reasons to support one appearance over another. For example, even in Dark Mode, you may want to adopt a light background for printed content.”
and
“If your design requires opting out of one appearance, you can tell AppKit which appearance you want to use. For example, you might adopt a dark appearance for your app at all times because it highlights your content better. You might also adopt a light appearance for user documents or printable content.”

Sure enough, that’s what apps like Pages do. They don’t actually offer a full-blown Dark Mode because they remain truly WYSIWYG, provided that you’re printing all your Pages documents out on white paper. But using them when in Dark Mode is trying to work with someone shining a flashlight in your eyes. I find it more comfortable just to abandon Dark Mode altogether when working in apps which don’t do dark properly. None of this was discussed at WWDC, of course.

Apple does now offer an app which edits Rich Text documents in Dark Mode and prints them properly: TextEdit version 1.14 (341).

What that version of TextEdit does is the best solution for Calculator and those other thousands of apps which rely on AppKit to handle their Appearances and printing: when rendering a view for printing, it always does so in Light Mode, even though your Mac may be running in Dark Mode. This may not be truly WYSIWYG, but it’s eminent common sense.

Noting that few apps seem to have discovered the secret of printing in Dark Mode, I set off to discover what in AppKit supports this sensible behaviour. This is tricky, given the limited documentation, but eventually I found the answer in the AppKit release notes for Mojave. At first, this seems to contradict experience, saying
“When you print an NSView through an NSPrintOperation, its appearance now gets temporarily replaced by the aqua appearance during rendering. This is done to avoid printing with an inherited dark appearance.”

But that isn’t how AppKit works in Mojave, until you read on to the next paragraph:
“To avoid altering the contents of on-screen windows, the darkAqua appearance isn’t replaced when printing views that are simultaneously hosted in a window.”

So the WYSIWYGers triumphed over common sense: unless you use a separate off-screen view (which you fix in Light Mode) to print part of a window which is being displayed, in Dark Mode it will be printed as an abominable mess. This leaves every developer having to re-invent their own way of solving this problem, which is exactly what has happened.

Here’s my own example, in DelightEd. Print when a window is in Light Mode, and everything is fine.

Do the same when the window is in Dark Mode, and you’ll regret it.

Does anyone at Apple seriously believe that users want to see that sort of page emerge from their printers? Or even in PDFs? But by the time that Apple has reluctantly accepted that it made the wrong call, everyone will have overridden this misbehaviour in their own apps. This defeats the whole purpose of having large class libraries such as AppKit, and just creates unnecessary work for a great many developers.

Meanwhile users are left wondering how Apple, which places such emphasis on good design, could possibly have got this so badly wrong.