One of my styles doesn't compile correctly when all is "as is."

One of the styles I created appears the same whenever I compile in paperback 6 x 9 and “as is” mode. Happily, all of the other styles fluctuate each time I compile based on how I “redefine style from selection.” The offending style looks great while editing, but it stays stubbornly the way it started no matter how many ways I redefine it in edit mode. Thank you for your help.

I’m using Scrivener for Mac 3.3.1 on an M1 MacBook.

  1. Point of clarification: Is it that the redefining the style based on selection visibly in the Editor fails to change the look of instances of that style? Or is it rather that the style appears to change as desired, but the compiled output does not reflect the change? Your answer will determine what sort of problem you have (define style or compile).

  2. What element of the style are you trying to change? Is the recalcitrance of the problem style specific to the change you are trying to make or is it recalcitrant with respect to any change whatsoever?

If a style is listed in the Styles panel of the compile format, it is frozen to the state it was in when it got added to that panel.

So defined styles do not redefine at all, or are styles you create from scratch the problem?

Styles do not redefine unless the Compile Format explicitly tells them to.

Some of the supplied Compile Formats already know about some of the pre-defined Styles, so they may appear to behave differently, but they don’t.

If your style appears in this list :

It will redefine, but to the state it was in at the time it got added to the list.
If you modified the style afterwards, it will show in the editor, but not at compile.

To have text of a specific style compile as you see it in the editor, simply make sure it is not listed in the Styles panel of the compile format you are compiling with.

The purpose of this list is mainly to have styles be reshaped at compile. If you don’t want a style to look different per compile format, it then has no reason to be in the list. It’d be pointless.
(Unlisted styles simply compile as they are currently configured.)

I am not sure if this is what you mean, but one thing to clarify is that you can change how a style looks on output, once it has been added to a compile Format, it’s not “frozen” at the point when you added it. That is what the lower half of the Styles pane is for, and for the most part that is the designed purpose of the feature. It is so you can take whatever aesthetics you prefer while writing and have them conformed to a standard look on output (such as a submission manuscript). That’s probably what you meant, but it could be read that adding a style to this pane locks it to that formatting forever with no recourse other than to delete it (and maybe add it again).

But my guess is that the OP largely uses their own styles, but happened to use a built-in one as well (or happened to name their own to something we define), and those are all accounted for by our built-in templates to make them look like they fit in with the design intent of the Format, rather than having some random bright red 18pt sanserif font in the middle of your Adobe Garamond book, because that’s how you like seeing block quotes yourself while writing.

Taking such an opinionated format and essentially opting out of how it works almost entirely, by assigning everything to “As-Is” is one of the few ways that this described normally beneficial behaviour may work against you.

It’s a simple matter of clearing out the Styles pane in the compile format designer if that is the case, or at least that one conflicting style entry.

Though at a certain point it may be less effort to start from the “Default” Format instead of trying to undo and suppress behaviours in one that has a lot of heavy-duty configuration to track down.

AmberV is right. You may change it all you want.
But once it got added to the Styles panel’s list, any change in the editor and then the style itself will have no effect on compile, is what I meant.
Once in the list, the formatting it has in the Styles panel prevails. If you want a style to compile different than it currently does, either remove it from the list (it’ll then compile as you see it in the editor), or tweak it in the Styles panel.

Vincent, Amber, kewms, jcarman, and gr,

Thank you all. This is my first time on this forum, and it’s the kindest and most helpful forum I’ve ever been on. You helped me understand how the compile format designer controls. I had inadvertently named one of my own styles in the editor by the same name in compile format designer for Scrivener’s 6 x 9 paperback compile format, so that threw it off. Since then, I made a copy of Scrivener’s compile format for 6 x 9 paperback and have had a great time modifying things. I painted myself into a laborious corner, though, because I made all of my changes in the editor and kept the “as is” passthrough for the new paperback compile. I’ll need to step-by-step establish the same styles in the new paperback compile style sheet that I have in my editor so that I can have a “normal” editor for manuscript and an ebook, too. For those, I hope I know better: I’ll play around in the compile designer instead of the editor to get the look right next time.

Thank you all very much for your time and for sharing your expertise. It helped me a lot today.


1 Like

You are welcome. :slight_smile:

But… if I read you right, all you have to do is clear the list in the Styles panel. (?)
If you want your styles to compile as you see them in the editor, that’s all you need to do.

The questions and answers here seem to go around and around. Maybe you have it now, but here is how I would explain it. A style listed in the Styles pane of Compile is a recorded override to that style’s definition in the Editor. In that case, changing the Editor definition doesn’t change the Compile definition. If you want to change the way it’s compiled, either (1) change it in the Editor and delete that override or (2) change the style in Compile, using the Format bar and/or the Format menu.