Too much space between words when compiling for eBook

I am compiling my novel for Epub and Mobi, but when I read the file on my kindle, the text appears justified (which is what I want), BUT, sometimes the space between words is too big and it looks ugly.
How can I fix this?

Are you asking this as a Scrivener support question? How an ebook reader justifies text doesn’t have anything to do with designing the ebook itself, which is where I’m confused.

If you’re looking for tips on how to adjust your Kindle’s display, I can move your query to an off-topic area.

  1. Copy the file to polish in the Calibre2 folder
  2. Set all security in that folder to ALLOW
  3. Remove all spaces from filename
  4. Only give Input file name, Calibre will create _polished output file

Good input:

c:\Program Files\Calibre2>ebook-polish -H Title.epub

Good output:

--------------------------------------------- REPORT -----------------------------------
Polish: EPUB

Add soft hyphens
Soft hyphens added

Polish took: 19.3 seconds
Output written to: Title_polished.epub

c:\Program Files\Calibre2 _

Have fun!

1 Like

Hi Amber, thank you for your response.
Is not a problem with the display of the device. I double-checked (compared a dozen of ebooks I already had on my device, with the novel I compiled using Scrivener)
In all of the cases, by device default, is justified, BUT, in the case of my novel, the words can get extremely spread to strictly comply with the justify command. I think it can maybe have to do with CSS? (I am ignorant regarding CSS but that’s what I read).
Attached you can find an example of how it looks when I compile and how it looks when is another book.
Thank you for your help!

I think it can maybe have to do with CSS? (I am ignorant regarding CSS but that’s what I read).

There are things you can do with CSS that would modify how a paragraph looks, yes, like left alignment, and setting hyphenation policy. However we do not actually apply those kinds of settings because it is considered best behaviour to leave them up to the book reader, or one’s settings within that reader.

Technical Details...

You don’t have to guess about this kind of stuff, and CSS is really easy to pick up even if you don’t know much about it. I’ve compiled some test text using stock “Ebook” compile Format settings, opened the .epub file in Sigil, and here is what a typical paragraph looks like in HTML:

<p class="ps1">Erk ik lydran dri yem groum athran furng xi, groum ma... sernag gen vusp zorl cree tolaspa arul furng gronk morvit...</p>

Now that’s actually even more cluttered than it should be. Since this is just a normal paragraph it should be <p>…</p> all by itself. That is a bug.

There is a neat tool in Sigil, just like in a web browser in fact, that lets you look at all of the formatting settings that impact any element you can see in the book—even settings that are calculated on the fly, such as how wide a paragraph is:

  1. Click the “</>” button in the lower left of the Preview pane.
  2. A window will open, and within that click the top left button that looks like a mouse pointer aiming at a box. After you do this, you can then move the mouse over to the main preview pane and select the element of the book you wish to examine, such as a typical paragraph. Here, you can see I’ve picked paragraph two, from the darker blue selection highlight.
  3. The third panel shows the computed paragraph formatting. As you can see from here, we have some basic stock stuff like font size, weight (both normal), margin and indent settings. Nothing else.

We can also take a look at the stylesheet.css file in Sigil’s sidebar. Here is the CSS Scrivener adds that sets how paragraphs look:

p {
	margin: 0rem 0rem 0rem 0rem;
	text-indent: 0rem;
p + p {
	text-indent: 2.00rem;
.ps1 {
	margin-left: 0rem;
	text-indent: 1.50rem

Like I say, this is buggy. What this means is that all paragraphs should have no margins (no spacing around them), and no indents. However paragraphs following other paragraphs (p + p) should be indented 2 “rem” units, a relative em, which if you do not have typographic experience, refers to the maximum width of the font, which is its size setting, and most often the width of the em-dash (—), hence the name. So we are specifying an indent of roughly this much ⇒ (——), for all paragraphs except the first in the sequence.

Thus we can see the bug, since for some reason the compiler comes along and says, “nuh uh”, it is 1.5rem for all “.ps1” paragraphs—despite the fact that the stock Ebook compile settings are set up to use ebook paragraph formatting, which should be 2rem, and not something other than that. Who knows where 1.5 comes from, it’s a complete mystery from what I can tell.

But this is all rather somewhat of a digression that makes figuring things out and implementing your own custom formatting more difficult and less crystal clear. Point being, as you can see from the CSS that stipulates what paragraphs look like to your ebook reader, there is nothing in here about justification, alignment, hyphenation—and certainly nothing so particular as how to justify. There are ways of doing that with CSS, but they are surely if anything being utilised by the internal code that displays text in your book reader. Sigil is very “vanilla” in that it doesn’t add much to the text other than what you give it. Kindle on the other hand is very opinionated. Unfortunately Amazon does not believe in giving authors detailed design tools, so there is no way to get in there and know what your reader is really doing. We can only guess.

So in the end, I don’t know why your ebook reader is displaying text that way. It does look like it does not know how to hyphenate Spanish—so that is going to make justification more difficult for sure (do make sure you are setting the language code properly in the Metadata tab of the compile overview screen, if the reader thinks this is an English book then that might explain why it isn’t hyphenating anything). But it could also be a matter of how you are putting the book on the device, or even in fact that you are doing this at all. Do you know for instance that Amazon does not recommend design level proofing on their devices? Why? Who knows, that seems like a basic requirement for any designer—but they expect all proofing to be done in Kindle Previewer, by loading an .epub file into it. Only that is going to give you an indication of what your book will look like to other readers, when they download your book from Amazon. Loading it into an iPhone, or a Kindle is actually not accurate!

Hi Amber!
Thank you so much for your answer. It was perfectly clear and I understand now.
I’ll double-check what you suggested and I’ll try to use the kindle previewer as the main guideline to see how the ebook would look on a kindle device.