Paragraph formatting change in Word export

Scrivener Scrivener for macOS
1

Hi forum. I know, this is yet another thread about paragraph formatting issues when exporting to Word. I wish I could find the answer, but I have scoured both this forum and elsewhere to no avail. Word’s forums send people here. Scrivener’s forums send people to Word’s forums.

Same problem others have experienced: Exporting to Word changes paragraph formatting to have an 8pt space after rather than 0pt space. This did not used to happen until the beginning of 2024 or so.

  • I have tried adjusting settings in Scrivener but may not know the best setting to change. I heard about an “override” checkbox but don’t know where to find it or what exactly it does.
  • Settings seem right on both ends. Style settings in Word seem right even down to the code level (???), but I’m not savvy in word processor programming, so I may need some assistance at one end or the other.
  • New projects with default export settings do the same thing, so it’s not a matter of copying an older project with faulty settings or something.

Here’s a weird thing, though: I created a new project recently and imported a Google doc into it using “Import and Split.” It came in fine, with correct sections and all—and when I export it to Word, it retains the 0pt After paragraph spacing! Why? How?

Any “conversation between programs” fixes since the beginning of 2024 for un-savvy people like me? Any reason why the Google doc-sourced project exports correctly while my other new projects do not? Any solutions besides “just export RTF and then convert to DOCX” or “just select all and adjust the paragraph formatting for every single one of your docs”? I export tens of docs per week for work projects, so this is quite the hassle. First-world problem, though, I know.

Thanks in advance.

2

This is going to be the most effective solution, and the one least disruptive to your overall workflow.

The issue appears to derive from our RTF → DOCX converter. Compiling from Scrivener to RTF, then using Word to convert, bypasses our converter in favor of Microsoft’s.

To help us develop a more robust solution, please send a test project that demonstrates the problem, along with the Compile format used.

2 Likes
3

Seeing as how this may be in part a bug report, I’m having difficulties getting this kind of result on my own, which I’ll go into below in more detail.

First some basic troubleshooting though: have you tried seeing if what you compile from Scrivener has this padding if you drag and drop the .docx file back into your project, say in the Research folder? Alternatively, have you tried any other word processor to look at it, like Pages or LibreOffice?

Any solutions besides “just export RTF and then convert to DOCX”

You could always try using the Java converters (those that would be used to create ODT files), provided you have Java installed. Once that is set up, and you restart the software, the Sharing: Conversions settings tab will acquire a new checkbox for using them to produce .docx files.

I should add an important caveat, that I am not opening the result in Word as I have no access to that. However I can of course look at the .docx formatting itself internally, and as well can see what it looks like in LibreOffice, which usually gives on a pretty good idea of basic formatting issues.

For the purposes of this test, use the following sample project (which also includes a copy of the DOCX I compiled from it):

paragraph_spacing_test.zip (150.3 KB)

Firstly, open the .docx file I provided, and see if you get after-para spacing. If you do, well the problem is probably outside of Scrivener then. This is a correctly formatted document.

This performs some very simple tests, using as little complexity as possible:

  • There are no styles used anywhere, all formatting is raw direct formatting.
  • There are two sections of test, testing the After Paragraph spacing value, first at 0pt as in your case, and then at 20pt to provide a control, so we can see what to expect if there is spacing.
  • Compile settings use bog standard “Default” with all Section Types assigned to the “As-Is” setting. Very little should be modified and we’re largely just glueing together text chunks into one file.

I know you said you aren’t a coder, but for this particular type of formatting, the DOCX format is not too obscure about it. Chunks of text that that deliberately have after-para spacing will have this formatting applied to them:

<w:spacing w:after="400" w:line="264" w:lineRule="auto"/>

In this case, the w:after="400" is what became of our 20pt spacing test. The unit of measurement is different, but this checks out, and if you open the compiled .docx in LibreOffice, it reports correctly:

Scrolling up to the portion of the DOCX file that presents the 0pt padded paragraphs, we find this formatting:

<w:spacing w:line="263" w:lineRule="auto"/>

The w:after attribute is gone, which should cause the text to use the default, and therein is where we might get into weirdness with how MS Word works, itself. Maybe its default is for some mysterious reason 8pts? I suppose, if that is the case, we could force it to 0pt, but in general it is very bad practice to enforce default settings into your file format. It floods the file with piles of wasteful declarations for one thing, but it then also overrides what you want to be default, should have preferences on the matter and change them.

In LibreOffice though, we get:

After you have compiled this test project for yourself, to verify whether it works or not, I would recommend modifying it with whatever settings or formatting you would need to use to reproduce it, and then attach your result as a response (drag and drop the .zipped project backup into your reply window to attach it).

1 Like