Problem Compiling Block Quotes

I am in the early stages of learning Scrivener 3 Mac and most of the problems that I have encountered have been solved via trial and error, via this forum or on the web. So far so good and I can see the power and felxibility of the software.

There is one problem that I haven’t found an answer to. Apologies if this is a newbie mistake. I have block quotes that are formattedas a Style with Gill Sans, 12 point 1.3 line height. I have no difficulty changing these parameters to a new font or new font size etc…

However when I compile to Word the main output is fine but the the block quote is compiled with a line height of 1.0. I go into Compile, select the project format, click on the gear icon and change the line hieght to 1.3 again… Then I save. Then I re-compile and hey presto the line height is back to 1.0 and compiles as such. Other styles in the Paragraph Styles pane seem not to have this problem.

I have got everything set to ‘As Is’ (I believe) but the lineheight problem manifests itself both before and after hitting compile. For the life of me I cannot find where I have gone wrong.

Any help gratefully recieved. Please be gentle if my error is very basic.

Thanks, Miles.

One simple problem to get out of the way first: with which program are you opening the .docx file? Some programs, particularly those based upon the stock Mac text engine, the conversion from DOCX to internal RTFD causes a complete loss of line-height settings throughout the document. I don’t think that’s the problem you’re seeing though since you mention line-height variation from one style to the next—but it’s worth making sure you aren’t using TextEdit or something similarly simple.

That aside, I can’t think of what might be wrong in a general sense, with the given information. With a very simple test I do not have this issue—but I’m using the “Default” compile Format. Generally, here are things to check for:

  1. The style itself in the editor is not 1.0. Unless a Format overrides “Block Quote”, the compiler always passes through formatting for styles.
  2. And along those lines, the Format itself in the Styles panel does not have a “Block Quote” entry in the list, or if it does, it has the intended formatting supplied.

I wasn’t sure what this refers to, reading it literally. The gear icon in the top left header bar wouldn’t have anything to do with setting line-heights. So is there a missing step in here? If I click the gear icon within the Styles pane, there are no options there relating to line-height (all formatting for each style is set up in the mock editor area below the list of styles).

Thank-you for your advice yesterday evening.

I am compiling my document to Micrsoft Word and as you susepcted this doesn’t seem to be the problem.

I then compiled using the Default format and the problem has gone away. I wonder if somehow in editing the default format into a my own project format it somehow got corrupted along the way.The problem seemed only to manifest itself on the line height in the Block Quote style. Anyway all is well now.

My reference to the gear icon was to the icon that appears at the low left corner at the bootom of the Formats listing in the left side panel of the Compile screen (after clicking the compile button).

Thanks again.

Glad to hear things are working again with a settings reset. If it is not too much trouble, I’d be happy to take a look at the custom Format you created, and see if there is anything wrong with it. You can right-click on it to export to a file and attach it here (you’ll need to zip it first for the forum to accept the attachment, and feel free to use PM if you have personal info in it, like header/footer fields).

Ah, so you were editing the Format from that button, I take it to mean. Just a hint: you can simply double-click to edit!

Thanks for sending the test material! I’ve installed the Format into a test project—and indeed the problem is what I referred to earlier:

  1. First open up the compiler.
  2. Double-click on the Format you are designing in the left sidebar.
  3. Select the Styles compile format pane.
  4. You will see a list of styles that this format has been set up to “reprogram”. For something that alters the fundamentals like fonts and paragraph spacing vs indents, we often want to transform styles so that they don’t stick out like a sore thumb in the output—using your text editor formatting verbatim. So from this list, select the “Block Quote” style.
  5. In the lower half of the pane is how this style is designed. Click into the sample text to examine the settings it uses, in the Format Bar. On the right hand side (if you don’t see it, you may widen this window a bit) you should find a line-height setting, which reads “1.0”.

And there’s the culprit! You’re telling Block Quotes to use 1.0 line-height, no matter what settings you use in the project while writing, or what settings you have put into the Section Layouts. Styles always win, and Format Styles in particular have absolute control over what the text looks like (there are a few scattered exceptions, like the global font family override in the main compile overview screen).

Although it’s probably not the correct answer for this specific format, it’s also good to bear in mind that if a style looks 100% the way you want it to in the editor, you can simply delete the rule from the Format. If there is no rule, then the project’s stylesheet wins.

As an aside, earlier you mentioned using “as-is”—perhaps that was a troubleshooting step, but to clarify a bit on the implications of the above: you can certainly use Section Layouts that overwrite text formatting, along with styles. That pane along with Styles are meant to work hand in hand, where one handles text that isn’t styled and the other handles text that is (and that should be modified from its editor appearance).

Dear Amber,

Thanks again for your reply and advice.

The problem went a little deeper. I worked though items 1 to 5 multiple times in exactly the order you list. The default line height was/is 1.0 which I wanted to change. When I adjusted it to 1.2 or 1.3 then two things happened: first the line height in the dummy text on the lower part of the pane did not change and secondly when I saved with the line height set to 1.2 or 1.3 and then when I clicked on it again to check the line height was back to 1.0. i.e. I seemed to be stuck with 1.0 and unable to escape. I assumed I was missing something which was why I raised my original question. This problem was not evident with any of the other styles where changing the line height worked as it should. Hence my suspicion that something had got corrupted.

Having gone back to the Default Format and started again everything now works fine.

Thanks for the explanation about what takes priority in what circumsatnces. This will be especially helpful when/if I need to setup more complex formatting.

Best wishes
Miles.

PS In my experience such rapid response from a forum is unusual and most welcome when learning a complex piece of software.

That’s the clue—and apologies if I missed where you described this more precisely. It sounds like you’ve moved ahead with the rebuild and are making good progress with that, but for the sake of curiosity: if you run into a case where it seems like the line-height multiplier tool isn’t making a difference on the text you are trying to modify, chances are you have a more stringent underlying line-height setting that is overriding that. From the same dropdown, select “Other…” at the bottom to enter advanced options. Any of the three settings in the middle can restrict the gamut at which the line height multiple has an effect. To effectively disable these features, set the value to 0.0 points and the radio toggle to At least.

In case you’re wondering, these tools are very useful when combining inline images, super/subscripts and equations into the text. The line height multiplier operates by using the tallest element on the line, meaning a superscript can make the leading for that one line larger than the rest around it. With the line height forced to exactly the mathematical value that the multiplier would produce on a normal line, it is impossible for that to happen, producing a more professional looking even leading no matter the elements on the line.

Perfect !

Looking at the ‘misbehaving’ format the settings showing in Other were wrong. Now corrected.

Secondly, I have a lot of superscript footnote references and had noticed that the relevant lines’ leading had increased. it was something i was going to revisit later when fine tuning the project but this it’s now fixed.

It’s probably all down to finger trouble on my part. For which my apologies.

Many thanks again.

Miles.