Screenplay>Change Element to Problem

Is this a bug, or pilot error?

I’m editing an FDX document I’ve brought into Scrivener using Import and Split. My Scene Headings are set to use bold and underline.

There are some action lines in all caps, and some of these have been converted accidentally to Scene headings. For example a line like:

ANGLE ON BOB

When I select the line and use Format>Screenplay>ChangeElement To to convert it to action, it succeeds in changing the format to Action, and in removing the underline, but the action line stays bold. If I type Cmd-B, it stays bold. Only if I press Cmd-B a second time does it go back to plain text.

Is this expected behavior?

The first part of that is expected, as for whatever reason, one might have used bold for their own purposes, so we would not expect that to be removed (I believe the same respect is given to italics).

The second part doesn’t sound right though, and isn’t something I see myself:

  • Does it happen if you test this out in Scrivener itself, rather than imported material?
  • Are you using a particular font worth mentioning, perhaps one that has more than two weight variants? I’ve seen similar happen before, when the text isn’t using the “Bold” weight, but is in fact “Semibold” or something.

Maybe L&L could consider changing this for Screenplay Mode. In this case, I couldn’t be using bold for my own purposes, because the global setting for Scene Heading was already set to bold. In this situation, Scrivener is just failing to convert the default Scene Heading setting to the default Action setting.

Try this:

  • Open Script Settings and change Scene Heading to bold+single underline;
  • Make a new Screenplay document and type a Scene heading;
  • Hit Return, and type an Action heading;
  • Highlight the Scene Heading and change it to Action using Change Element To;
  • The Heading will be changed to Action with no underline, but will still be bold;
  • You can turn off the bold by using Cmd-B twice.

Is this repeatable on your machine?

In this case, I couldn’t be using bold for my own purposes, because the global setting for Scene Heading was already set to bold.

I mean if you try another combination of actions, like take an Action line and make a couple words bold and another couple italic, and then convert the element to Dialogue, the bold and italic font variants will not be swapped out.

Is this repeatable on your machine?

Okay yeah that’s what I was trying, and for me it all tracks up until the last bullet point. For me I can select the text that is bold and disable it with a single ⌘B use. That’s the part that sounds a bit like a font issue to me.

I was testing with the copy of Courier Prime that comes in the software, by the way.

I understand.

I’m asking for Scrivener to recognize that Elements that are set to default to bold and/or italic are an exception. Because such elements are set by default, the styles should not be retained when converting to another Element format.

Me, too. I’ve repeated it over here using Courier Final Draft, Helvetica and Times.

I did notice that the double-bold problem only comes up if you select the entire element. If you select only one word, a single Cmd-B will work.

That may be the clue, how are you selecting the entire element? I tried both manually selecting with click and drag, and triple-clicking.

With a click and drag – here’s a screen cap:

Scriv2xBold

All right, what version of macOS are you on?

I’m running 10.14.6 (18G9323)

Same here, I can’t explain that. I guess you could maybe try clearing your font caches with Maintenance, but that feels like a bit of a long shot to me.

Yeah, especially since it does the same thing regardless of what font I use.

There is something strange going on with Scrivener on my machine. I occasionally get double Help menus. Tech support had me completely remove and reinstall Scrivener, but the problem still comes up.