When compiling to Kindle ebook, does Scrivener put extra spaces between words where there are none??

The cons are really piling up in this program, add to that I can’t get an answer or support for anything.

I just purchased a few days ago and I have now spent more time trying to find answers to problems than I have spent writing.

Nice, I can’t edit my post. WHY does Scrivener add random extra spaces between words throughout my ebook?

You clearly have a problem with your ebook (looking at your other posts), but you are not giving enough detail of your issues for anybody to have a chance of helping you. The answer to your bald question is a bald ‘no, it doesn’t’ — so something’s going on and nobody can guess what it is without more information.

So, please describe what the problems are exactly, which version of the software you’re using (including Kindle), which format settings you have, screenshots of affected text in the editor and on the Kindle etc.

I may not be able to help you (I’m just another user and I don’t compile to Kindle), but give the experts a chance by giving them enough information to go on.

I’m new to Scrivener and have been overwhelmed with random problems, I don’t know which one is the greatest at the moment.
I have used the search function extensively only to find my question, or similar, having no replies. There are 20 pages of posts with no replies.

Since I made this post , I uninstalled Kindle and Scrivener, then reinstalled.
I am running Sierra on a MacBook Air, I am running the latest Kindle, the version that the app store installs as of last night, 1.21.1.

I just purchased Scrivener about a week ago after using the trial for a few weeks. I have 3.0 (75).

I deleted every .mobi file I had and created a new one last night, this one does not have the space issue on my iPhone or iPad, however it now has the issue of no indentations (per my most recent post) on the mobile platforms, but they are there on my Kindle on the Mac.

I found this https://www.literatureandlatte.com/web/forum/viewtopic.php?f=2&t=27397&p=175876&hilit=indentation#p175876 where it mentions using tab for indentations as a problem but I have never used the tab button for that, I hit enter/return.

What style am I using? That again is the most convoluted thing about this program. For example I changed the ‘title’ style in preferences to have the font and I size I want and I still can’t get the title to show anything but the same font as my text. I tried changing it manually in the title page as well.

I finally took a screenshot of how I wanted the title page to look and inserted it rather than spend hours battling Scrivener.

Thanks for responding, but ever since I purchased this program my writing has become pure frustration. I simply used pages before and the only advantage Scrivener has over that is the character files, but that’s easily remedied with another Pages document.

I want to like this program, but it doesn’t seem to like me.

Scrivener has a learning curve, for sure. It is not, and has never been, a program that you can pick up and “just use.” Most especially you can’t do this if you expect it to work like a word processor. It’s not a word processor. It is not, in any sense, a “What you see is what you get” type program.

Did you work through the entire tutorial on Mac? On Windows? If not, please take an hour or three to do so. On Mac, you can find it under the help menu, “Interactive tutorial…” item. It will be time well spent.

I have and there is nothing on why I would have paragraph indentations on Kindle for Mac, but not for IOS.
Do you know why that happens?

Sorry. No clue. :blush:

Just so no one in the future will read this and be left stumped too, I ‘fixed’ it by compiling to a regular .mobi file and not the kf8 version. I now have indentations in IOS.

Historically speaking, Kindle for iOS has lagged a bit behind Amazon’s other readers and devices, in terms of full support for KF8. In this particular case, it looks like it does not recognise the rem unit of measurement, which we use to keep the text indent scale sized relatively to the document as a whole, rather than the local context. If we used em, the indent would change width for paragraphs that had smaller or larger text than the standard body text. Using rem ensures a consistent indent width no matter the paragraph scale.

Thus, one solution would be to go into the CSS compile format pane for the KF8 settings, look for where paragraph formatting is established, and change the setting from rem to em units. For example, in the default Ebook format, you would find a line like this at the very top:

p { margin: 0rem 0% 0rem 0rem; text-indent: 1.5rem; }

When changed to the following, indents will display as expected on iOS:

p { margin: 0rem 0% 0rem 0rem; text-indent: 1.5em; }

Interestingly, Kindle for iOS seems to treat em more like rem, at least in this context. When I tested this adjustment and manually changed a single paragraph to “font-size: 220%”, the indent looks uneven everywhere except Kindle for iOS. So as far as I can tell, the above tweak would not be detrimental.

I also would like to add that the extra spaces I was seeing were real, but I found that that is common to ebooks apparently. (No, I did not know this because I always read paperbacks/hardbacks and am only trying ebooks out for what I will publishing).
From what I’ve read this is because of no hyphenated words in Kindle apparently and so it adds spaces to keep the words intact?

Thanks for the explanation above, hopefully this will help others as well. That level of technical info is out of my reach at the moment. For a simple ebook with only a cover photo, one isn’t losing any feature by using the regular .mobi format correct?

Right, I wondered if that is what you were talking about before, but since you mentioned it had gone away I let it be. Full justification is always a combination of adjusting the spacing between words, but a system that can also do hyphenation will mitigate how much spacing must be used, making the overall effect much more pleasing to read. eBooks, having descended from browser technology, did not inherently have hyphenation models built into them, meaning all justification is merely word spacing. It generally produces an ugly result (especially for short lines or large fonts), and that is why many eReaders would even ignore the request if made, and in web design full justification is often discouraged.

As for Scrivener itself, it strips alignment hints from body text entirely, in accordance with the Amazon publishing guidelines, so whatever alignment you see in the reader is entirely up to the reader. Newer Kindles with the Bookerly font will do a much better job of this by the way, with a proper mix of hyphenation and word spacing to achieve left and right justification.

I would suspect that in time eventually all eReaders will be capable of presenting a beautiful “page” at full justification, but the tech is still new and evolving. Part of the problem is that good justification is computationally expensive—a good system is not only optimising the visual quality of the line, but the lines around it, to reduce “rivers” of whitespace between words in a paragraph (an effect better seen by letting your eyes go out of focus), and also to avoid having many lines in a row that are hyphenated. That requires multiple levels of iteration, a task better suited to print than dynamic on-screen display. But I digress.

Not at all at this point in time. When you compile using the regular Mobi format, KindleGen includes both KF8 and MobiPocket formats, so older devices such as a Gen2 Kindle eInk device will look good, as well as all of the new stuff. The main advantage you do gain from using Scrivener’s new KF8 and ePub 3 formats is in the amount of technical flexibility. If one does have a good knowledge of HTML/CSS and would prefer to interface with the output more directly, it will be a superior approach as the resulting internal code is much cleaner and more semantically proper (for example, a block quote will be a blockquote HTML element rather than a paragraph styled to approximate editor settings).

If all you want is simple input/output and quasi-WYSIWYG style control, the regular Mobi/ePub2 formats are perfectly fine to use.

Ok good to know. For myself at the moment most of that is beyond my desire to know haha, but I am happy that the cluster of what I thought were bugs that hit me just when I thought I had the program figured out, have turned out to not be bugs and that’s the most relieving thing when you’ve just purchased a program.

There is still a ton of Scrivener 2 info out there and for example I was just sent looking for the ‘As is’ checkmark controls in Scrivener 2’s compile menu, and it’s not there in 3, but there are a number of people still using 2 on the Amazon forums who are (without having seen the new 3 layouts) insisting it’s the same, so that has added to the confusion for new users like myself…