Character style lost on Compile, one cause isolated

Continuing the discussion from Scriv3: Compile to unwanted page size and other strange effects:

I wanted to make sure a thread on this longstanding issue was actually tagged as a bug.

This thread seems to indicate this bug is not limited to the Windows version, and has been around as a landmine for a long time.

~80% of users hitting the issue could be fixed just by changing the default of a new paragraph style to be a real paragraph style instead of a “both.”

But folks with underline in their dialogue seem SoL as far as I can find.

Not a bug. You have to set up your compile format. Not WYSIWYG.

Why? Not set up in your compile format? I have both Mac and Windows Scrivener. Started with Scrivener before there were styles. Got the message that it was not WYSIWYG and moved forward with it. Mayhaps you would be better to unlearn what you know about Word?

1 Like

Do you have anything more that I could search off of?

I have attempted to make a Compile format as blank and non-interactive as possible.

I have not found a way to have the 60,000 existing words output correctly with some specific Compile format option.

I have not succeeded in having any underlined words of style-specified text survive the Compile at all.


Amazing, the only 2 replies, and both whip this out as some sort of auto-win.


This is an increasingly absurd distinction in the modern era. It’s not the 80s anymore.
Moreover, anytime I’ve seen someone wave WYSIWYG around as some sort of defense against obvious improvement, the excuse is paired with the option to see the actual text that’s being auto-altered by the GUI.

Normally someone saying “hey this doesn’t seem to work right”
gets a "Oh, you can’t always trust the GUI like that, there’s more going on under the hood. Here’s how to open the hood"

If I can’t actually pop the hood and see what the real style is, that’s not a defense.

For example, web pages are “not WYSIWYG,” yet inspector windows /modes to get at the actual HTML are standard features of every browser.

We’ve reached the point where I am literally typing this comment with the “not WYSIWYG” output directly beside it.


This over-defensiveness is increasingly absurd. The inconsistency in how character and paragraph styles interact with bold, italic, and underline buttons is clearly, unambiguously, a bug.

Bug != coding error.


I almost never say something like this, but putting on my software developer hat, at the very least I could have found and fixed the default selection off of the “both” monster in less time than it would have taken to write this comment.

1 Like

We supply a format for this purpose, the “Default” Compile format. Have you tested your styled text with that format?

Yes I have tried Default, which this one is, but I have not tried all combinations of the supplemental options that I do not understand, such as the “Add font matter” checkbox.


those test test test lines use a custom character style bold for those two words, which does work.

The issue is that the buttons/shortcuts seem to apply the character styles in a way that is overwritten by the “Paragraph+character” monster styles that are the default, and which ALL of my character dialogue is.

However the manual character style assignment does it, that will correctly apply after/trump the paragraph+character default monster.

I believe that you need to include those character attributes when creating (or redefining) a style.

Do you know of a way to redefine a style into a different type? Underlines aside, that would clear 90% of my problem instantly.

The issue is that I can only access that drop-down on style creation, as far as I know I can’t update and propagate a style change to switch from the default “Paragraph+character” style and into a just “paragraph” style.

Okay, we’re making progress.

Assuming that you did nothing to the Default Compile format, the Editor formatting should pass through unchanged.

What document format are you compiling to, and what tool are you using to inspect the output file?

You can’t.
But you can create a new one that is set right from a selection of text of the previous style.

Okay. What happens if you compile to PDF? I want to eliminate the possibility that (1) the DOCX format converter is involved, and (2) that LibreOffice’s handling of styles is playing a role.

:point_right: :exploding_head:

If I have to reassign every piece of dialogue then I have to, but fuck me. The idea that I was better off with using a macro pad to swap fonts instead of “embracing Scrivener” and using styles is extremely unpleasant.

Please pack that test project into a ZIP file and open a support ticket. Reference this thread so the person responding will have this history.