(v18.104.22.168) I’m seeing a pattern here: manually changing the values of e.g. line/para spacing applied to a paragraph assigned a named paragraph style seems to have no effect on Compile output to PDF.
The only way I have been able to consistently adjust spacings when a named style is applied is to define a new style with the desired new spacings, then the result looks good in the editor and the PDF.
In other words, manually applied paragraph attributes applied to paragraphs with named styles seem to have no effect. It’s as though the named style attributes are applied last for Compile, rather than first, which would seem to be the case in the editor.
Is that by design? It feels bug-ish to me. Is everyone else in the same boat?
In the editor, if you change the attributes of a paragraph with a named style, that doesn’t change the style definition. To change the style definition, you then need to use Format > Styles > Redefine style.
Sometimes, an existing style just needs e.g. space before or after in just a few places; it’s most natural to modify the style of the paragraph in place – and I certainly wouldn’t redefined the style because that would mess up all the other instances.
Since manual changes are (mostly!) applied in the editor, the question is solidly about why they don’t propagate through the compile process (even if there isn’t an overriding Compile Options Style).
So, according to my experience, Yes, I do need to create a new one (or I set No Style and manually set the attributes (or copy/paste) in one place rather than have a style I could redefine if I wanted to)
which I never got round to answering, as it seems to me that what you were saying there links to your problem here. So this is how I see it.
If you have created yourself a “Normal” paragraph-only style, what you are really doing is merely duplicating the essence of the default set up in Options or in Project Settings, just giving it a name that mirrors what you see in Word/LibreOffice/whatever.
So now, you want paragraphs which diverge from that in terms of spacing and you add the spacing in the editor but Compile just knows it to be “Normal”, so it loses the spacing. Result, you need to make another style for paragraphs that diverge from your “Normal” style, which, in point of fact only diverges from “No Style” in name.
Anything in “No Style” on compiling to RTF is styled “Normal”; for other formats—DOCX?—it may be styled “Body”, whatever the name for the base style is in that format.
I have four paragraph-only styles that I use in the editor: “Bibliography” with hanging indent; “Block Quote” margin indents both sides; “No Indent”—although Scrivener compile can remove first-line indents after headings, blank lines etc., they are still “Normal” and if I change anything in the Normal specification in NWP, they get the indent, so I give them their style; and for my recipe collection, “Ingredients”.
I have four Heading styles, which are only applied by the compiler to Binder titles in respective Section layouts. They have font size defined but not font.
So all of those are paragraph styles that I need because they differ from the main No Style, which becomes Normal on compile.
So, to reiterate, If you removed your “Normal” style and trusted Scrivener’s “No Style” the new style you’ve created for the extra space would still give you the extra space you want. However, if you really don’t want to remove your “Normal”, there is another solution if you have further paragraphs that differ in some other way from that, and yet you don’t want to create yet another new style… experiment with Format > Preserve Formatting.
That would seem to be a lengthy agreement, i.e. Yes! If the para is “No Style”, then the only place to get the formatting is from the attribute instances, but, if a named style is applied, it takes the attributes from the named style only.
[Asides: this is my 1st Scrivener project; next time I will start with No Style (I’ve said it was a noob mistake so many times, I got bored with repeating myself), but the point remains that if one does use styles, one can only present the output according to the style definitions, it seems.
And if that is true, it seems:
a) Counterintuitive/contrary to common UI philosophy
b) Deeply counterproductive
c) Bug-ish and, one might hope, easily “fixed” one day.]
a) To me, it’s only counter-intuitive if you are still in a Word/WYSIWYG mindset. I’ve been using Scrivener since Mac v. 1.0, and what immediately grabbed me was getting away fro the wordprocessor mindset and being concerned while writing with what it looked like on the page. Scrivener breaks the mould.
b) Again, anything but counterproductive to me. I guess having been with Scrivener before it had all the current facilities must help. It made me realise how counterproductive being continually aware of formatting issues was: “Oh lord, it’s not good having the page break here! How can I rewrite to fix that?”
c) Yes, there seem to be bugs and lacunae in the Windows version. I certainly hope they’ll all get fixed in time. But, historically speaking, KB was a Windows user and wanted to have a program to write his novel that gave him the flexibility he craved. He switched to Mac on discovering that, (a) contrary to Windows at the time, the Developers kit was free; and (b) it provided him with the frameworks to enable him to realise his vision more easily. LAP and Tiho_D haven’t had the benefit of those frameworks but have had to program them themselves, so yes, I think there are a huge number of things that are on the list for them to implement or sort out, and everyone of you would probably prioritise them differently.