Scrivener 3.5.2 and Inconsistent Italics Formatting with Custom Style

I’ve used Scrivener to publish 12 novels and I’m preparing to publish a new trilogy. I use a custom style that changes the font to Courier because fixed-width fonts are easier for me to read. When I write, I sometimes apply italics (usually with Cmd-I) to paragraphs here and there; sometimes to individual words. It has never been a problem.

When I create a new manuscript, I copy the fonts forward from the previous. It saves set up time.

In novel #14, the compile no longer preserves the italics until about 2/3 of the way through the book. Then it starts working again. I’ve tried compiling to different format (DOCX, DOC, and ODT) with the same results.

If I change the style in a sample paragraph to “No Style,” I have to reapply italics. If I do that, italics again show up in the compiled version. Trouble is, I really don’t want to have to go back through my entire manuscript, remove formatting (and by doing so make it a lot harder to read), and re-apply italics.

The issue is even more confusing to me because the next book, which relies on the styles I copied from the book with which I’m having the issue, is just fine – italics made it to the compiled version.

For the first 2/3 of this book, italics show in the editor. But they get stripped going to the compiled version.

I’ve tried multiple output formats, including the built-in and one I created. The results are the same.

I’ve never seen anything like this in Scrivener.

Any ideas on what I can check? I’d like to get this book up for preorder, but that’s not happening until I figure this out. I could go through and manually format the DOCX, but that’s insane – I’d need to do it every time I fix something, and God knows that’s going to happen at least one.

Thanks in advance for any suggestions/insight anyone can offer.

Some more behavior: if I highlight a paragraph with the custom style “Crow Typewriter” (yeah, I know – not terribly creative, but it reminds me of my Smith Corona Classic 12) and create a new style from that selection called “Crow Typewriter Italics,” guess what?

If compiles as italic.

I made no other change. I just created a new style from the selection of the old style.

Does that give any kind of insight/clue?

It could mean that your first style is in the compile format’s styles list, and formatted without italics there.

Or maybe somehow your initial style got corrupted. (If that’s even possible.)

1 Like

That’s plausible, but there’s one thing that bothers me – why does it start working 2/3 of the way into the book?

I also thought about corruption, and I wondered if I should try to dive into the files in the *.scriv directory. But that sounds like a disaster waiting to happen.

Do you know of a way to check either of those things? I tried looking all through the Compiles menus, but I didn’t see how it would even undo italics. Do you know where to check? I can’t see any of those options unless I look at an export style I copied; but the settings between a manuscript that works looks identical to the one that’s not working. That part makes some sense, because I copied them.

I had something that worked for 13 manuscripts, so I kept using it!

It also works for the 15th. It’s just this 14th that’s acting up.

Thanks for sharing your thoughts!

Well, you could run Zap Gremlins for starters – can’t hurt.

Else, in your first post you say :

I suppose you meant styles, but still, what do you mean by that? How do you copy styles? (If styles it is ; but why would fonts have to be imported to a new project?) Perhaps doing what you do the way you do it, you carry an issue from your last project into the next – and on and on?
You could instead use a project template, or import styles, or use


if this feature exists in the Mac version…

. . . . . . . . .

If you’ve pasted text fetched off of the web directly into your project without using Paste and Match Style, there is a chance that it could cause this sort of issues at compile.

. . . . . . .

Ultimately, if all else fails, you could use the half and half procedure :
You compile half your project.
If all is fine, it means that the issue is in the other half.
You compile half of this other half.
If all is fine, it means the issue is in the other half. (Reapeat the above, and on and on.)
If the issue is present, it means the issue is in this half. (Compile the other half to be sure it doesn’t hold another instance of the issue, then repeat the above, and on and on.)
Until you end up with the faulty document identified.

1 Like

Hi! Thanks for the suggestion of Zap Gremlins. I’d never heard of it. It didn’t have any impact, but it’s good to know about. By that, I mean I highlighted everything in chapters 2, selected Zap Gremlins, saved the project, and tried a new compile. The problem presisted.

Yeah, I meant styles. When I start a new project, the first thing I do after naming it is Format → Style → Import Styles. Then I select the previous project.

What’s odd, is that I’ve done this for 13 projects prior to this, and they all work. I also created the 15th project from this one (the 14th), and the 15th works just fine.

So if I read your response correctly, my process matches your second option when you said, “you could instead use a project template, or import styles, or use.”

It’s good to know that’s on the right track.

I think I’ve done what you’ve suggested in regard to compiles/isolation. There are 34 chapters/documents in my project. The first works fine; sections 2 through 21 don’t work; 22 through 34 work without issue.

That’s part of the reason this is driving me crazy.

I started looking at the Scrivener Settiongs/compile.xml file, but it’s using a lot of GUIDs, and I don’t know what they refer to. I suppose I could copy a working compile.xml, but without knowing more, I’m hesitant.

Thanks for your fast responses! I appreciate it.

The problem starting at your chapter 2 could be caused by something in chapter 1, or even perhaps another one elsewhere. I would personally take the time to backup my project and run Zap Gremlins for the whole project.

Pretty sure that’s a waste of your time. The issue won’t be in there. You need to fix what triggers it. And since “it works here but not there”, that means that it is in your content. (I’m 99.9% sure of that.)

You could also ask support to have a look at your project / issue.
They are trustable, efficient and friendly.

2 Likes

I tried your advice – I highlighted the text in each chapter and ran Edit → Text Tidying → Zap Gremlins. There was no change in behavior.

I agree with your reasoning – there’s something in my content that’s telling Scrivener to ignore my italics. I just can’t imagine what it is.

I might well open a support ticket. If that’s a thing! Or I might just accept the fact I have a few more days of editing.

I just can’t get my head around what would stop it working in book 14 chapters 2 through 21 and allow it to restart in chapter 22. Then work fine in the next book with the styles copied from book 14!

I very much appreciate your responses. I didn’t know about Zap Gremlins, and I know that I haven’t done anything obviously wrong.

Thanks!

[You are very much welcome. :slight_smile: ]

The issue is likely not with the style. The issue causes the style to fail, but it ain’t the style(s) that has or have an issue.

I would :
BACKUP the project.
Then, compile the whole manuscript, but not chapter two. (Uncheck it, exclude from compile.)

If this compile works fine, you are in luck.
Take a snapshot of the document(s) making up your chapter 2.
Then, select all of the content of your chapter 2 document(s) (one by one, if more than one) in the editor, cut, and paste it right back using Paste and Match Style.
Compile the whole manuscript again, this time including chapter 2.
If all is fine, reformat chapter two.
Your problem should then be solved.
Compile and confirm.

. . . . . . .

Otherwise…

Should you contact them, include a link to this thread so that they have all the details.

1 Like

Still no joy.

I even tried to skip chapter 1, keeping in mind your observation that the problem might have been before chapter 2.

Thanks for the link to support! I’ll make use of it.

Thanks again, and please enjoy the rest of your weekend!

1 Like

For your future reference, using a defined style for your regular body text is pretty much asking for a headache — in fact it might be giving you a headache right now!

If you want to always see a fixed-width font in your Scrivener editor pane, set this as part of your Default Paragraph specification in Scrivener settings. Now when you create docs, they will already have the look you like to work with. So, your regular body text can just remain classified as No Style — which Scriv will like much better. (You can also set a default paragraph look for just a single project, but it sounds like you want this look globally.)

Of course, when compiling you can say right in the main compile dialogue box what font should be used in your compiled output — whether the same or different.

3 Likes

Well, I appreciate your feedback, and I don’t necessarily dispute your advice. But I’ve written 15 complete novels and have started a 16th – over a million and a half words, and this is the first problem I’ve had. Well, excepting the first version that worked with MacOS Tahoe.

I may give that a shot, but I’d like to understand why the style worked for the other 14 novels and decided to take a break during only part of this one.

Maybe I’m off-base, but I kinda expect styles to work. But I get it – I keep my use simple and try not to stress the edge cases. Those can be problematic.

Plus, I want to get to the bottom of this because setting text to No Style removes italics, and it’s a 91,000 word manuscript. I do not want to go back through and reformat the whole thing.

Thanks for your feedback – I’ll keep it in mind when I start my next project.

Using a style for italics (character attributes style) rather than just italicizing the text using the format bar is standard usage and perfectly fine.

But using a style as your default formatting isn’t. (Should you be doing that.)
It is not catastrophic – but it makes the compiler not as versatile.

2 Likes