Paragraph spacing where there shouldn't be any + editor zooming changes font properties

[Sinistrail]

Hi everyone, I originally posted this on Reddit – it was late in the night yesterday and I thought I couldn’t sign up here before checking out with a copy of Scrivener or something, but I eventually figured out it might also help posting it here.

I’ll make it briefer this time – here’s the TL;DR:

1. paragraph spacing is set at 0,00 pt but it’s still adding tiny amounts of spacing after every paragraph, which means that at times it’s cutting 1-2 lines from near the bottom of some page’s margins, making the PDF uneven;
2. zooming the page view in the editor alters the amount of text on every page.

This is what I mean for my second problem:

There was a screenshot here but the forum won’t let me put pictures in my post.

And here’s the first – I compiled a PDF with two pages, one consisting of a sentence spread over two lines copy-pasted until the bottom, and the second one with the same sentence forming paragraphs of three paragraphs instead. Here’s the proof, already noticeable by viewing a portion close to the top of the page, that the one with more paragraphs is reaching the bottom earlier due to more paragraphs adding some sort of extra spacing – despite me having set it to 0,00.

Ditto.

I know that Scrivener’s not exactly WYSIWYG as a lot of stuff can be realised post-compiling only from what I get, but are these two alterations supposed to happen in the editor? Have I forgot to check another option in some extra menu or is it a bug? I am tagging it as one for the moment. Thank you in advance!

[For reference, I am on Scrivener 3.1.1.]

[AntoniDol]

Are you sure that Before paragraph or After Paragraph settings in Line Spacing window are set to zero?
(Find Line Spacing with the Other… option at the bottom of the Line Spacing drop-down list in the Formatting Toolbar)
These settings are also available on the formatting options for Section Layouts you might use to compile.

[Sinistrail]

Thank you Antoni for the reply, the forum tells me that I’m now able to post images.
Yes, that window is where I’ve tried setting it to 0, and I saw the program also differentiates between multiplied and single line spacing even if they’re the same at 1 (the flavour text you get it when you hover over the numbers in the editor tells you if it’s “single 1.0x” or “multiplied 1.0x”). Switching between them does nothing of course, as they’re both the same number.
Since you also mentioned the compile options, I went into the compile menu again now to see if the section layout submenus had some options pertaining that, but I only saw some checkable boxes for indentation stuff when it came to paragraphs. The only times I saw that the line and paragraph spacing numbers came up again was in the Compile Format Designer > Section Layout window, but everything seems normal.

I’ll put the images here – this was the first pic showing how zooming the editor changes the font behaviour:

And this was the second one, showing lines in compiled PDF pages looking different both from the editor and from each other due to those phantom paragraph spaces being added, even if they’re on the same line number. Again, with spacing set at 0, this shouldn’t happen, right?

Now it should make more sense.

[JimRac]

@Sinistrail

I’ll put the images here – this was the first pic showing how zooming the editor changes the font behaviour:

Unless I’m misunderstanding something, to me this editor behavior is correct and expected.

It appears that you have setting Use fixed width editor enabled, which makes the editor size static (fixed width).

If you zoom / increase the font but leave the editor container at the same size, then naturally the words will not fit the same in the editor, and will wrap at different places.

Something to try: Disable File > Options > Appearance > Main Editor > Use fixed width editor, restart Scrivener, then experiment with increasing the zoom. Is the behavior now what you were expecting?

Best,
Jim

[Sinistrail]

Hi Jim,
I’m not increasing the absolute font size nor the size of the page in the screenshots --still 9 pt or whatever it was for the font when I took that, still roughly 13,5 x 21 cm for the page – but I’m increasing the zoom of the editor, the classic CTRL + scrollwheel action you do in any program. The one whose value is at the bottom left of the editor, where you can read “number%”.

I’ve also now disabled the fixed width editor, but it just breaks the page view. After restarting a margin is slightly cut off and a border has disappeared (for those worried, my graphics card is alright, it’s Scrivener):

To show how everything should at least behave normally, I’ve opened a LibreOffice document which I made sure had the same configuration as my Scrivener file (no extra paragraph spacing, this time on the default A4 paper size). Here I’m zooming the page again in LO, which naturally opens on its own version of the page view, and keeps the text in place, as also shown by a line I’ve drawn to help:

The exported PDF also has no paragraph spacing problems.

Scrivener, even after selecting all of the text and clicking OK while making sure it’s got no spacing (single or multiple), still adds subtle amounts of paragraph spacing both in the view and the compiling. Changing font does not help:

[kewms]

Scrivener is not a WYSIWYG editor.

Increasing the Editor zoom does not affect the underlying text, but does increase the display size. This is the expected behavior.

If the output PDF document doesn’t look like you expect, you should check the Compile settings, not the Editor settings.

[JimRac]

@Sinistrail

I’ve also now disabled the fixed width editor, but it just breaks the page view. After restarting a margin is slightly cut off and a border has disappeared (for those worried, my graphics card is alright, it’s Scrivener):

Are you by any chance using Composition Mode in the above screenshot?

If not, please post a screenshot of your entire Scrivener window, not just a snippet of the editor.

Best,
Jim

[Sinistrail]

I have now reset the options and editor formatting to default. Scrivener now opens the pages like it’s its first time, with Sitka as a default font, standard A4 page rather than the page I devised in the compiling menu, etc… I just left the page view, icons I added on top and checked the box to hide the folder path at the top of the window for this screenshot, but everything else is reset.
Now, these screenshots are also taken with the page view layout taken from the page setup options (so again, default A4 with 1" borders), and not from the compile settings like previously.

@JimRac

Are you by any chance using Composition Mode in the above screenshot?

If not, please post a screenshot of your entire Scrivener window, not just a snippet of the editor.

I have not used Composition Mode yet. Here’s two full desktop screenshots of me zooming the editor out again. The “and” changes line.

Filling a page to the brim and zooming in makes this text overflow into a new page (I’ve specifically noticed that zooming out at the max makes this text stay in a page and a half, but as I’m slowly zooming in, the white space thins out until the text becomes over 2 pages, meaning that zooming makes the text larger in the editor):

@kewms

If the output PDF document doesn’t look like you expect, you should check the Compile settings, not the Editor settings.

After creating a new format in the Compile Overview window, leaving it on default (even after checking if the section layouts had different paragraph spacing for the text body or some other quirk – everything seems normal) and compiling it, there’s still some sort of ~0,1 pt of paragraph spacing being added, like in the page view. All pages have a correct baseline on the first line, but the pages with more paragraphs “drop” faster and push a line out because of the above. This is the bottom of a resulting compiled PDF:

@kewms

Scrivener is not a WYSIWYG editor.

Increasing the Editor zoom does not affect the underlying text, but does increase the display size. This is the expected behavior.

It is indeed not WYSIWYG since page numbers, headers, footers, alternating margins, taking in/out notes comes later when compiling but to an extent it does show how a page should look like. So far it does make sense to me to think that (1) the font size changing when zooming the view and (2) adding paragraph spacing when it’s at zero – unless I missed an option for this one – are bugs.

[rms]

the format in the writing/editing part of Scrivener is independent of the output from the compile part.

You should consider to stop trying to bend Scrivener to your will and instead use a WYSIWYG tool, eg Microsoft Word. Saves everyone a lot of time

[Sinistrail]

If I wanted to simply typeset, you’d be right, I have Affinity Publisher (InDesign for poor – erm, resolute people) and I can even make the craziest magazine layouts possible. But this paragraph part is still curious to me, I want to know where that extra spacing is coming from after I’ve reset everything… if it’s present both in the view and after compiling, this means it’s either a shared behaviour, or that there are two separate things left to modify. And I don’t trust the text changing like that, WYSIWYG or not it’s weird that a program would ask the user to set a page and character size before deciding it would not scale them proportionally, no?

I don’t want no disorganised monopage Word-like view to write in. I essentially like the concepts behind this program which is why I’m trying to get used to it before I buy it.

[kewms]

I was not able to duplicate this. In my test, zooming in Page View resized the entire page, preserving line breaks. Please open a support ticket, here:

Contact Us

with a copy of the project demonstrating the behavior. You can email a project by using the File → Backup → Backup To command, and checking the box to create a ZIP backup.

As a general principle, though, if you are evaluating Scrivener based on how the view in the Editor transfers to the output document, you are missing the point.

[JimRac]

Hi Sinistrail,

My response is only in regards to what you’re seeing in the editor, not in the compiler.

I was unable to reproduce what you’re seeing in Page View. In my test, same as @kewms, zooming in or out in Page View resized the entire page. Something is going on with your Scriv settings or configuration that is different from ours. Hopefully L&L Support can dig into it and figure it out.

That said, Scrivener was still changing the number of words and lines that fit on the virtual “page” depending on what the zoom was.

@Sinistrail

And I don’t trust the text changing like that, WYSIWYG or not it’s weird that a program would ask the user to set a page and character size before deciding it would not scale them proportionally, no?

At the risk of repeating what the others have already said above, one of the foundational concepts of Scrivener is separation of formatting in the writing environment vs. formatting of the output(s). When people say, “Scrivener’s not WYSIWIG,” that’s what they mean.

Scrivener’s Page View is a feature of the writing environment, and you are taking the name “Page View” way too literally. The feature is merely a concession to folks who like working within a page-like view. To quote the manual, Section 16.2 Page View:

For most uses, page view is for simulating the look and feel of writing on real
pages, and is thus an aesthetic preference, not a print preview tool.

To give you another way of looking at it: Before responding to your post today, after 7 or so years of using Scrivener on a near daily basis, I had never opened File > Page Setup before. I have never had the need to check or change the settings in Page Setup, because those settings are irrelevant to most uses of Scrivener. Output settings are configured in Compile, not in File > Page Setup.

My recommendations are, if you haven’t already, read Chapter 1 Philosophy (page and a half) in the manual (Help > Scrivener Manual). Do the tutorial (Help > Interactive Tutorial). Play around with the various tools available in the writing environment. Then try the Compiler–go through the example in the Tutorial.

Best,
Jim

[Sinistrail]

It’s moot by now but what is it that you folks couldn’t replicate specifically in the editor? I think it’s actually the same for all of us and we miscommunicated a little bit, the page resizes. My fault, I should’ve uploaded a video.

Anyways – I pretty much got curved by support but I didn’t get shot down. Briefly, this is what happened after the last messages:

• Uninstalling and reinstalling Scrivener didn’t help. Same problem.
• I tried the other 3.x versions to see if something broke between the releases. Output still not correct among the versions.
• Ye olde Scrivener version 1.9.xyz… outputs the file correctly?!
• I peruse the manual to see if the paragraph spacing is correct on that manuscript too… well, there’s a lot of spaced paragraphs due to all the bullet points but normal ones have 0 extra spacing indeed… and the manual itself says it was typeset in Scrivener 3.1? But that version still has that problem for me!
• Wait… could it be that they typeset it on Mac since it’s their main platform?
• Ok, let me get my friend to download the latest version and send me something… wait, the spaces are right?!
• Maybe it’s my PC… let me try my laptop… still broken – because it’s the Windows version!

(That’s not a 3.1.1.0 repetition in the pic, that’s the laptop’s output and the last one’s my normal PC. All of these bounded boxes are anchored to the exact vector nodes or bounding boxes in the PDF outputs from each version and are set in the same font, for the record.).

Well, I guess this is the best proof I can provide. Something’s definitely wonky. Sorry for being nitpicky, but I’m glad it was a worthwhile waste of time!

[drmajorbob]

@Sinistrail

Something’s definitely wonky.

I can’t tell what you meant all that to represent. Screenshots of the Editor? In Page View?

If it doesn’t happen in Compiled output, nobody cares. No WYSIWYG here.

If it does happen in Compiled output (pdf preferably), it still doesn’t look like an important amount of extra space.

[AmberV]

@Sinistrail

I peruse the manual to see if the paragraph spacing is correct on that manuscript too… well, there’s a lot of spaced paragraphs due to all the bullet points but normal ones have 0 extra spacing indeed… and the manual itself says it was typeset in Scrivener 3.1? But that version still has that problem for me!

Specifically to that point, the user manual is typeset using LaTeX, so the process is more akin to going through Affinity Publisher in terms of separation from the writing process to final production. I wouldn’t ever consider using Scrivener to create a PDF that other people read. It’s PDF output is more along the lines of a proofing tool.

That aside, you shouldn’t be getting a substantially different form of paragraph design unless the compile settings are doing so. If you use “Default” for example, as a compile format in the left sidebar, you should see something closer to the original. If you select something like Manuscript (Times) you should see something very unlike the original. Thus, it would be possible to write using 2.0 line-height source and compile to 1.0 line-height output, to describe an inverse of what I think you’re seeing. In short the input doesn’t matter a whole lot unless you specifically tell the compiler to use it verbatim, which is how “Default” works.

Wait… could it be that they typeset it on Mac since it’s their main platform?

I can typeset it on my Linux machine as well, but again we’re talking about LaTeX at that point. The main reason the source .tex file isn’t compiled using the Windows version, at this time, is down to a few bugs in some of the more esoteric and advanced mechanisms making it impossible to do so. For example, the links at the end of major sections that take you back to the chapter ToC don’t work correctly, because the placeholder (<$levelN_title>) used to reference them addresses the wrong binder item.

I would also add that the common catch-all phrase, “not a WYSIWYG program” is often bandied about to mean a number of different things. To the underlying philosophy of providing a comfortable writing environment that needn’t adhere to the form of the output, this is the most obvious application of the phrase. But it also ends up being used to generally caution against expecting a level of sophistication in the overall software that would normally be developed toward that ideal—like having perfect typesetting at all zoom levels and so forth. More of our development time gets spent on the sort of things you describe wanting of it, the organisation system, being able to write into a large outline instead of a mono-view environment and so forth. Given that, much less time is spent toward creating a pitch perfect text layout engine—to the point that on both platforms we use largely off-the-shelf text editing engines.

It sounds to me like you have a good concept of the software’s intended limitations and design intentions, i.e. more the original and more obvious application of “not WYSIWYG”, but are maybe expecting a bit too much of it at the detailing level. My pardon if I read you wrong in that.