Why does the font change after I paste an image in TextEdit?

Question

Here is a simple sequence of actions in TextEdit in macOS 10.13.6 that produces an unexpected side-effect. I don’t understand why, and would like to know how to prevent it.

1. Create a new document in TextEdit (using ⌘-n or menu item File ➜ New).
2. Look at the style bar at the top, and note the font & font size. The font that TextEdit uses at this point is what I set in my TextEdit preferences for "Rich Text Font". (In my case, Roboto 14pt.)
3. Capture an image to the clipboard, e.g., using the standard macOS facility for capturing a portion of the screen as an image to the clipboard. (Any image will do.)
4. Paste the image in the document (using ⌘-v or menu item Edit ➜ Paste).
5. Look at the style bar again: the font & font size have changed to Helvetica 12pt.

This affects text that you type in the document: if you type text before you paste in an image, the text will be in the font and font size you set in your preferences; once you paste in an image, any text that you type in the document after the location of the image will use a different font & font size. (It is not merely a glitch in the style displayed in the style bar.)

Why does the font change? What controls this behavior? And how can I make it stop changing, so that text typed after step #4 continues to be the font set in my “Rich Text & Note Font” preference instead of being switched to Helvetica 12pt?

In case it is relevant, here is an image of my TextEdit Preferences panel:

Answer 1

I can consistently reproduce this behaviour in TextEdit.app and Notes.app on macOS Catalina 10.15.3 (19D76). This happens with any kind of image insertion (eg. clipboard, drag & drop).

I don't know how to prevent it from happening when you're appending an image to text, but maybe you'll get what you want by inserting an image into the middle of formatted text; then the before/after text preserves original formatting. One thing that worked well for me is typing a space, then tapping the left arrow ◀️ key once before pasting an image.

I'll go into more detail below about what else I learned.

---

The font always reverts to Helvetica 12 pt after pasting an image, regardless of any settings I tried. This seems to be a hardcoded, unchangeable system default. Although I haven't yet tried using TinkerTool to change system-wide font settings.

Peeking into RTFD files

I'm not sure how to peek at the in-memory state of NSTextView but if we save the file to disk then we can inspect the content of the RTF file. We're looking for a font-size directive like \fs12 or \fs24. Actually the original RTF file format doesn't support images, so we're really talking about .rtfd (RTF Directory) bundles here.

At first I compared two files, one where no image had yet been pasted, and another where the image was pasted and then removed. Interestingly, the file contents were identical! This suggests that there is no intentional change of text format settings, and that reverting to Helvetica 12 pt is directly connected to the presence of the image.

Then I inspected a file where I had appended the same image multiple times. The same image directive occurs in repeat without any text formatting directives. In particular, \fs12 never appears in the file.

\f0\fs48 \cf0 Hello World
\fs24 {{\NeXTGraphic Pasted Graphic.png \width500 \height520 \appleattachmentpadding0 \appleembedtype0 \appleaqc}}
{{\NeXTGraphic Pasted Graphic.png \width500 \height520 \appleattachmentpadding0 \appleembedtype0 \appleaqc}}
{{\NeXTGraphic Pasted Graphic.png \width500 \height520 \appleattachmentpadding0 \appleembedtype0 \appleaqc}}

Based on this, I can quite conclusively determine that this pasting behaviour is related to in-memory handling of formatted text. In other words, this seems to be a peculiarity of Apple's implementation of NSTextView.

It seems unlikely to me that this is the behaviour that Apple's software engineers intended to create. If it was intentional, then it would be off-topic to speculate about why. But since it does appear to be a bug, instead I would direct you to Apple's page where you can write feedback for macOS.

Possible leads for future investigation

How can we directly inspect the contents of the clipboard? Is there any text formatting information associated with an image in the clipboard?

We could probably identify a smaller case to reproduce this issue by directly manipulating an NSMutableAttributedString. It's been a while since I did Mac development, but I would probably focus my attention on appendAttributedString: or insertAttributedString:atIndex:.

Answer 2

If you copied the image from another text app, like Word or Pages, then you may also be copying the text formatting at the position of the image in that document.

To ensure that this doesn't happen, use Paste and Match Style, which is Shift Alt Command V

However, you are right that this occurs even when no text formatting exists. The most likely answer is that it's a bug -- an undesirable and overlooked aspect of the code.

Answer 3

I found so far no possibility to circumvent this bug. The problem arises regardless of the technique, i.e. whether I drag drop a picture or use the clipboard or remove all formatting of the clipboard before pasting. Thus it seems users can do nothing about it and Apple needs to fix it.

Perhaps for some the following AppleScript may be helpful if you add pictures only at the end and run this script with a shortcut right after having inserted a picture, i.e. as long as it stays selected and before continuing writing:

property myFontSize : 14 -- Set the value to your default font size as e.g. set in the TextEdit preferences
tell application "TextEdit"
    tell front document
        tell its last character
            set size to myFontSize
        end tell
    end tell
end tell

or more generic when inserting pictures anywhere in the text document and as long as the inserted picture remains selected (or you select it yourself once more)

property myFontSize : 14 -- Set the value to your default font size as e.g. set in the TextEdit preferences

on run {}
    tell application "System Events" to set {ixBeg, ixEnd} to value of attribute "AXSelectedTextRange" of ¬
        text area 1 of scroll area 1 of front window of application process "TextEdit"
    tell application "TextEdit"
        set size of front document's characters ixBeg thru ixEnd to myFontSize
    end tell
end run

The latter inspired by ccstone @ TextEdit set size only sets current text, not subsequent text

Note, I found both AppleScripts working under macOS 13.6.1 (Ventura) (on a Silicon Mac).