7

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.) enter image description here
  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. enter image description here

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:

enter image description here

10
  • Are you sure the font is changing? On my machine running High Sierra the name of the font changes but the font itself is really my default font. as soon as I move the cursor, the font name returns to the original.
    – Natsfan
    Mar 10, 2020 at 21:38
  • Yes, absolutely. Typing some text makes it clear that it's changed.
    – mhucka
    Mar 10, 2020 at 21:39
  • 1
    @Allan I avoid it too! But it turns out this behavior of RTF files is exhibited by another application that uses the same underlying macOS RTF software libraries, and that application is the one I basically live in. The reason I'm asking about TextEdit is because it's easier to explain and demonstrate the problem.
    – mhucka
    Mar 10, 2020 at 23:09
  • 1
    And so does Apple Notes, though the default font is always the 'System Font' 12pt.
    – Gilby
    Mar 11, 2020 at 5:45
  • 1
    What @benwiggy said. This sounds like a bug that exists in the Cocoa text edit environment. Send feedback to Apple at apple.com/feedback/macos.html
    – Allan
    Mar 11, 2020 at 8:12

3 Answers 3

1
+50

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:.

1
  • Nice investigative work.
    – mhucka
    Mar 16, 2020 at 13:28
0

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.

3
  • 1
    That would apply to copying from an app, but I don't think it applies to capturing an image to the clipboard. If you use the standard mac method to capture a portion of the screen as an image then paste it into the TextEdit document, the image does not come from an application. Still, this is a good point.
    – mhucka
    Mar 9, 2020 at 16:38
  • If I use Paste and Match Style, what is pasted is the name of the png file I have copied to the clipboard. Or if I screenshot directly to the clipboard, it does nothing - only Paste is allowed. So this doesn't work in mhuka's scenario.
    – Gilby
    Mar 11, 2020 at 3:52
  • The menu option Paste and Match Style is unavailable for me when the clipboard contains only image data. The menu option only becomes available when my clipboard also includes text, which is not what OP described.
    – Nic
    Mar 13, 2020 at 16:01
0

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).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .