If you don’t want that to happen, decide what you want to override and act accordingly.
In the Mac Scrivener manual, Section 24.5 discusses Styles, and that’s what I had in mind. I’m sorry for the confusion.
Katherine
Do Word styles operate in the same way?
Word styles and Scrivener styles are different, as I assume you know.
The Scrivener → Word conversion should behave the same way for both Mac and Windows Scrivener.
Katherine
Well, well. That is not at all how I expected it to work. In all the word processors I have used (first on CP/M and later on DOS, Windows and Linux) styles could be modified by the ad-hoc application of formatting such as bold, italics, center, right-align, nested lists, etc on top of the styles. I have no experience with Apple products so maybe they work differently.
I quite understand that Scrivener is not a word processor and that the design choice was to act for writers who create bulk text with no or little formatting and that the compile process will later produce the formats they need. But seeing the format bar as a basic element of the GUI did lead me to believe that the format elements on that bar would be useful to me.
Writing non-fiction stuff, I feel more comfortable using some limited formatting to raise the level of information availability to the reader. At present, I do not feel able to leave that part of the creative process until later. Perhaps, in the fulness of time, I shall understand how to retain the formatting I want by improved use of the compile process in Scrivener.
In the meantime, thank you all for the responses and I am happy to have made an output from Scrivener which I can now format in my word processor. A happy side effect of Scrivener’s lack of format when creating is that I found my output to be 260 pages prior to setting my desired page layout. What I took to be one book will have to be split into at least two books.
1 Like
You can retain the formatting you want, if you understand how it works. I’ve never had any problem with it, because I use “no style” for all but exceptions such as headings and block quotes — where I’ve never needed to bold some words but not others, or italicize some but not all.
Here’s an example of the power Scrivener’s styles can bring to the process.
I’m writing sciFi (never to be completed, but still) in which a significant part of the dialog travels across a much more powerful world wide web between people (or artificial intelligences) using brain modems. I don’t want to say every time: “this was a Babel-connect transmission”, so I want a way to make it obvious. Quotation marks do that for spoken communication, and I don’t want to reuse them for this. I experimented with using «» instead of “” to enclose this kind of dialog, but what if I change my mind later? What if I want to put that dialog between em-dashes or exclamation marks?
As an experiment, I just now created a character style called “babel” and applied it to a few examples.
Three lines of it display with «the old method» vs the new method (red letters) in the Editor (first screenshot). The second screenshot shows the same text after Compile, in a PDF. The style is nothing but “red letters” in the Editor, but I redefine the style in Compile to make it black letters and add the «brackets». If I decide to, for instance, reverse the brackets as in »new method«, I can make the change in Compile in seconds.
The “babel” character style doesn’t prevent me using a paragraph style in the same paragraphs, by the way. I can highlight the text and use ⌘⌥8 to apply the character style, then ⌘⌥7 to apply the paragraph style.
No, I don’t know. That is, I know they’re separate beasts, but I don’t know if they behave differently. I haven’t used Word in many years (thank the gods!), and I don’t recall ever facing this “ad hoc” formatting issue (or use case).
Drmajorbob’s examples are good. The fundamental thing to remember, though, is that Scrivener’s Compile command inserts a layer between what you see in the Editor and the output document that simply does not exist in any other tool.
The “normal” way to work in Scrivener is to avoid using a “normal” or “body” style, reserving styles for exceptional cases. You can use bold, italics, and so on as you normally would, and expect that those elements will pass through to the output document.
You can achieve the same result if you do use a “body” style, but in that case you need to be aware that the Compile command may re-interpret the style to do something other than you expect. Whether the additional complexity is worthwhile depends on what you are attempting to do.
Scrivener is capable of handling extremely complex documents – its own manual, for starters – but as complexity increases you should expect to invest more time in making the Compile command do what you want. Allowing generous lead time and experimenting with smaller projects are both good ideas.
Katherine
1 Like
Well said, Katherine.
Thanks to the explanations of drmajorbob and Katherine, I have succeeded in making a character style and applying it within my body text paragraph style and getting it to survive compile. I haven’t explored yet all the issues but I am interigued by a couple of effects which appear to me to be anomalous.
In my home made text-body paragraph style, if I use the format bar’s tools for bold and italics, they do not survive compile and this is quite consistent with what Bob, Katherine and the manual have explained. If I use the inbuilt ‘emphasis’ style and my home made ‘bold’ character style, both formattings survive compile and it seems that this is quite as it should be.
Where I find it a little strange is that when I apply ( still within my home made text body paragraph style) the inbuilt character style ‘emphasis’ - the text in Scrivener displays as italic and the italic button on the format bar ‘lights up’ just as if I had clicked it or used the shortcut. But when I apply my home made ‘bold’ character style, Scrivener does not display bold nor does the bold button on the format bar light up. If I want a wysiwyg presentation in Scrivener, I have to click the format button or use Ctrl+B in addition to applying my bold char style…
During the creation of my bold style, I was able to create a shortcut but the possibilities were limited to Alt+Shift+a number (and it has to be top row number and not right hand end number pad). This makes a poor shortcut and in any case, Ctrl+B is pretty well universally the ‘bold’ shortcut these days.
Is there anything I could do to put my home made ‘bold’ style on the same footing as the in-built ‘emphasis’ style and be able to use the Ctrl+B shortcut ?
The other effect that seems strange is that at least some of the inbuilt paragraph styles can accept some ad-hoc formatting from the format bar. For example, the Block Quote and the Centered Text paragraph styles both accept bold and italics from the format bar buttons and these effects survive the compile process. If they can do this, there would seem to be no reason, other than developers’ choice, to exclude home made paragraph styles from these benefits.
1 Like
If you want WYSIWYG, don’t use styles at all … or use them as I do, for paragraph styles where there’s no need for ad hoc character formatting.
If you want other shortcuts, try a Windows alternative to Keyboard Maestro:
https://alternativeto.net/software/keyboard-maestro/?platform=windows
Block Quote and Centered Text are paragraph styles, so ad hoc character formatting passes through. If a style doesn’t allow that, it’s a character or paragraph+character style.
What happened to the images in my example?
But there is no “rebuild the HTML” option at “…”.
I am also facing this issue.
IMO, the whole idea of the User Interface is to represent what is there, what the computer sees.
I can’t comprehend calling this as anything other than a bug. If ctrl-b or ctrl-i affect the user’s view of a word, it should affect the data equally.
If using the button or shortcut does not actually change the character style, then it should be disabled until fixed.
.
I have a separate style and font for most character dialogue in my novel. The loss of bold, italics, and underline on Compile is not a minor thing.
Even halfway through when I have noticed this, that’s a real time investment to create and apply a character style to every relevant word. Aggravatingly so, and that seems the “best” workaround, assuming it functions.
Is there some better way to manually edit styles than “redefine from selection”?
It is wild to me that there’s no actual menu, where one can see the actual values being saved and used. Instead, such things are fragmented all over. Needing to check the Spacings, Indents, ect, every time just to find out what values are actually in that style is a PitA.
.
.
For anyone else finding this thread with the same issue, here’s what I have learned.
A key issue is that on creation of a Paragraph Style the option Formatting: defaults to “save all formatting”
You think you are making a paragraph style, but it’s not.
Despite the UI claiming its a paragraph style, and lacking the UI window for a 3rd option, it’s a “both” by default.
I do not know the potential benefit of ever selecting this option, never allow this default.
If your style was set to paragraph only, all use of the B or I buttons/shortcuts seem to survive Compile in my quick tests.
Selecting “save character attributes” in the drop down is the only way to get/create a character style at all, and manually using/selecting one will successfully Compile into a final product as well. Do note that these are specific/exclusive. If you want to bold and italicize, that’s a third character style w/ both.
Maddeningly, underline does not function. If I use a paragraph-only style, then use the button to underline a word, it will be removed in the final compile.
Neither the paragraph-only w/ button/shortcut, nor the manual character style override appear to survive Compile. Fuck.
Would be real nice if I could so much as get back to that style creation menu! Only exists on creation once, then you can never even SEE that dropdown again, and there’s literally no way to ever know if your paragraph style is actually a paragraph style, or a “both” monster.
Being unable to change this dropdown selection, every style in my project is going to need to be recreated and every line reapplied. The cherry on top is the shortcut, color, and name frustrations, which will be many.
.
Again, this is still a bug.
Any use of word-specific bolding, ect should either apply to the Compile, or be disabled so as to not trick the user. At worst, attempting to bold something already within a "both"monster style should kick out a popup explaining why it’s not possible.
The entire point of the Compile command is that the user doesn’t necessarily want what they see in the Editor to pass through to the output document.
Suppose, for example, that as a revision tool you use a style to format John’s dialogue in green and Mary’s in blue. Is it a good thing or a bad thing that the Compile command allows you to revert both to normal text?
1 Like
Dude, that’s an absurd thing to compare with bold text not Compiling through and you know it.
And the entire point of that interface bar is to EDIT the TEXT.
This is not some visual aid. This is outside the realm of the “unintuitive” especially when underline seems to have no way to persist when a paragraph style is involved.
No it’s not. I use bold text to indicate things requiring further attention all the time.
Scrivener is not a WYSIWYG editor. It does not want to be a WYSIWYG editor.
2 Likes
Really?
You bold text for that purpose? Not highlight, todo comment, nor any other function actually designed for that use?
You slightly thicken the visible text, in a way that is unsearchable and indistinguishable in any way other than manually scrolling and seeing that difference?
And you leave this text bold after the fact, confident the Compile will remove it from the output?
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, they usually point to the included 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.
.
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’ve gone through all this agony and can sympathise with many of your comments. But the key to this is, as kewms says:
" Scrivener is not a WYSIWYG editor. It does not want to be a WYSIWYG editor."
The producers have decided on the limits they wish for their product. I’ve come to terms with that. I stick with Scrivener for its excellent facilities provided by the Binder and having research documents bundled into the main scrivener files - all this stuff in one place.
Then when I arrive at a complete first draft, I export to my Word Processor where page layout and styles can be made to my requirements. This includes good implementation of nested lists, not losing the suffix of image files after import, being able to wrap text around images.
I have selected the tools appropriate to each phase of my process. This causes me less pain and grief in the long term.
For what it’s worth, in many conversations with writers around the world, I’ve found that very few make full use of styles in their writing. They will happily use ‘return’ repeated times to make space between paragraphs and all these ‘malpractices’ have an impact in the conversion to epub format.
5 Likes