I’m proofing the final version of my book now on Kindle and I’ve just discovered that the internal links have disappeared. Links from one chapter to another are no longer in place. Is this a known bug?
I tried checking the compile option "Convert document links to HTML links and it corrupts my ToC (all that’s visible is <$TOC> and a link to my endnotes). Has anyone else run into this and found a solution?
Have you enabled Convert document links to HTML links in the gear tab of the compile overview screen? By default links are configured for internal use rather than public cross-referencing.
In my original post I indicated that I had tried that in this statement…
"I tried checking the compile option "Convert document links to HTML links and it corrupts my ToC (all that’s visible is <$TOC> and a link to my endnotes). "
When I do, the ToC looks like this…
Hmm, I don’t see a correlation between that setting and whether or not the placeholder works. I do see cases where that placeholder doesn’t work—if the contents placeholder document is using a type that is formatted with a layout for example, that can mess it up.
But to get the result you’re seeing with the checkbox triggering this behaviour, I’d need more configuration information. My result when toggling this checkbox on is:
When I uncheck the “Convert document links to HTML links” my ToC appears as below…
Also it’s not directly related to this issue, but how can I reduce the spacing between lines to tighten up the ToC. In other words, to use line breaks (⌘⌥↵) instead of hard returns?
And, why isn’t the cover appearing in the ToC?
Oh I believe you, I just don’t know how to get that result myself is what I’m saying. I tried around a half a dozen different tests and only got the expected results—so obviously I’m missing something and need your help finding it. Sample data, which checkboxes it takes to trigger the problem, etc.
You could do that if you made your own ToC page, as described in chapter 22. I would advise handling that by reducing the paragraph spacing for the lines rather than making the ToC one long paragraph with line breaks inside of it, though. Semantically speaking, you might run into issues working that way. Incidentally that approach would also let you place the ToC wherever you prefer.
Of course you would need links working to do that.
There is no way to do that. I’ve never heard of referring to the cover of a book in the table of contents. You typically just close the book if you want to see the cover, no? 
Or the digital equivalent, use the “Cover” navigation option in the menu.
I have got iBooks that list covers in the TOC. I think they fudge a cover by inserting a graphic into a page and then adding that to the TOC and listing it as Cover. There are some books which have a thumbnail cover that expands on opening, is then replaced by text, and is impossible to call up from any navigation source—not even scrolling to the start of the book. Find that disappointing, as there are times when you do want to look at or read or study a cover.
Kindle eBooks have a dedicated cover metadata, and the devices that read them tend to have an entry in the nav menu to call up that image.
ePub tends more toward loose conventions. It’s up to the reader to find the image as I understand it; most assume the first image in the book is the cover. Since the image would be on its own page, machine generated ToCs might list it as a result, since it would technically resemble a section.
That circles the square, especially the difference between Kindle and ePub. Thanks. In iBooks I create with Scrivener, covers can be viewed if scrolled to the start of the books, but they don’t get listed in the TOC or the navigation panels.
Here’s a freebie example of an iBook where it seems to be (for me, at least) impossible to call up the full-page version of the cover. The thumbnail is there on the bookshelf, and that expands when the book opens, but after the text has hoved into view, the cover can only be seen again as a thumbnail on the bookshelf.
itunes.apple.com/gb/book/nichol … 5025?mt=11
There are paid-for books like this as well.
In this example, from Anthony Doerr’s All The Light We Cannot See, the cover is listed in the TOC but not in the navigation panel. Presumably the publisher has added an extra page with the cover embedded to force it into the TOC? The navigation panel says it is showing the TOC, but the cover isn’t listed.
So, back to the issue of internal links. I finally resolved the issue. As it turns out, I had separate front matter folders for my ebook and paperback (I was still determining which docs needed to be different between the versions). And, the links for my ebook were pointing to the pages in my paperback folder. At least it’s working now.
The ToC is still misbehaving if I only provide a page with the <$toc> placeholder on it. With the “Convert document links to HTML links” box is checked, I still get a ToC that looks like the following…
If I create my own ToC, everything falls under whatever happens to be the first item on the ToC as here…
When viewed in the Kindle app, there’s also a space between the Title and Copyright listings and I have idea how to get rid of it. You can see what I mean here…
Also, I’m still struggling with one other thing keeping me from publishing my book. I have an image that refuses to be left justified. A signature in my forward needs left justification, but no matter what I do it always ends up center justified. Any solution to this?
The flatness in the book’s spine is on account of your formatting on the ToC page. With each section centre-aligned in a single column like that, it is deriving no structure from the layout and produces a flat list. If for example you select the items you want in the ToC, and use the Edit/Copy Special/Copy Documents as Structured Link List and leave the indentation intact, you should see subsections in the ToC. Accordingly, I would say the flat centre-aligned column look is better for books that don’t need structure in the ToC.
I would also suggest putting a “Heading 1” title on this page. It may not be necessary for Mobi (it is for ePub), but in my testing it improves the layout. I got some strange results when I left a title off of this page as you did. Perhaps the title space glitch is a result of that.
If that doesn’t do the trick, to better see what is going on there, I would go into the gear tab in compile overview and check off Save source files in a folder with exported Kindle file. There will be a “contents.xhtml” file in the output folder, how does that look?
Likewise, if you examine the CSS/stylesheet.css file, you will find this line:
/* Images */
img { display: block; margin: 1rem auto 1rem auto; }
That would explain why your images are centre-aligned. While you’re looking at the HTML files, you’ll note that images are identified by their file name—that would in theory give you a place to add an override in the CSS pane, for example:
#imageid { margin: 1rem 0 1rem 0; }
But there is an unfortunate flaw in the implementation at the moment, whereby the file extension of the image is included in the ID, and the use of periods in an ID is invalid CSS—or rather #imageid.png technically means element with the ID “imageid” that is also assigned to the class “png”.
I’ll have to get back with you on that one. By the way so many of these things could be fixed with direct editing of the source files or an ePub->Mobi workfow with an editor in the middle. It’s nice to get things one-shot out of the compiler, but if you’re on a publication deadline I’d just be getting thing out. Up to you—but I always switch to post-compile antics when down to the wire on a project. I can get the process streamlined later for one-click updates.
Okay I think I found an approach that works:
Throw a style on the image (I used “Left Image”).
In your CSS settings, add this:
.left-image img { margin: 1rem 0 1rem 0; }
Well, I created a style as you suggested and assigned it to the image and gave
.left-image img { margin: 1rem 0 1rem 0; }
a shot, but it didn’t work. I then modified it as
.left-image img { margin: 1rem 0 1rem 0; text-align: left; }
but it still didn’t work. The image is still centered. Any other suggestions?
This is such a simple thing in practice. Why doesn’t Scrivener offer image alignment after all this time?
Using the Mobi format will be considerably simpler in that regard, it’s more like a word processor conversion to HTML, like Scrivener has been in the past (so I don’t know what you mean about “after all this time”). If you want to make an image left-aligned, then you make it left aligned in the editor. That has worked for years.
The KF8 route is instead semantic and CSS based, so it does require a little more strategy and setup to work with. The advantage is that you do have more control, and the source material itself is cleaner and easier to work with (whereas working with RTF-HTML is a bit messy) in post-compile.
As for why the above isn’t working, I might have confused myself a bit as I was testing different methods at the time. I ran into an odd behaviour which I’ve made note of, and Keith mentions it will be fixed. Basically if you looked at your source files you may have noticed the paragraph your image was within ended up being classed as “left-image1”. For some reason it is intentionally dodging the CSS you added—and if you changed your code to “left-image1 img” then the compiler would switch to “left-image2”.
The reason it worked for me is something you can use as a work around: add a paragraph style to the Styles pane for “Left Image”. This will cause Scrivener to insert its own “.left-image” formatting in the Default Stylesheet. It won’t do anything about the image inside the paragraph, but for whatever reason it having done that to the paragraph makes it safe for you to add the “.left-image img” selector.
So to reiterate, there are a couple of early bird glitches here that are making this more complicated than it should be, but this work around won’t need to be undone later on given how it is set up.
We’ll get both the style selector and image ID problem fixed in the next update; thanks for helping us smooth out this workflow.
Okay, so I followed the directions is the last post and setting a left-justified style woks fine for the text around the image, but the image is still center justified. I added your original .left-image img { margin: 1rem 0 1rem 0; } to the custom css and it didn’t seem to have any effect.
I did note the renaming you spoke of in the compiled files, by the way.
I’ve also found that using Preserve Formatting seems to have no effect either here or elsewhere in my book. Is this not functioning in Scrivener 3? Or, could something in compile be overriding it?
You should get no renaming issues if you have created a “Left Image” style in Styles compile format pane, so double-check that you’ve got that part set up right. I can get left, centre, right aligned images, images with 1/3 and 2/3 alignment, images that float and have text wrapped around them, images with borders, etc. etc.
I also find it useful to open the relevant source file in any modern browser and use its developer tools to analyse the CSS chain—that’s how I figured out how to do the above. Maybe you’ve got the section the image is within wrapped in a div that is centre-aligning everything—so my example of removing the auto margins so that the image reverts to latent underlying defaults (which works fine in a default environment) is ending up defaulting to the next CSS in the cascade, back to centre-alignment.
That wouldn’t be effective tool even if it did work with ePub 3 and KF8 though. Recall the earlier information on what is causing images to be centre-aligned: it has been set to have automatically scaled left/right margins within the paragraph box. Even if you made the paragraph right aligned, it would have no bearing on a block element within it that is auto scaling its margins.
