Calibre 1.25.0 changing text justification seemingly at random

[papalaz]

I just upgraded my Calibre version to the latest. I have a MS Word document, the vast majority of the text of which is justified apart from image description text which is centralised. I have removed all indents from the document. Document is then converted to .html and added to Calibre, and converted to different formats. Strangely, when converting to .mobi, the resultant output has blocks of text indented (seemingly at random)--as noted, there are no indents in the source document.

When converting to .azw3, seemingly random chunks of justified text are changed to centralised. Converting to .lit, the exact same result. I cut the offending chunks of text from the source document, added a few carriage returns then repasted the text (still justified), saved as .html, re-added to Calibre then re-converted. Same result, very frustrating!

Edit:

Calibre Options:--
Look & feel: Only default font size key selected
Heuristic processing disabled
Page setup: Input profile=Default; Output profile=Kindle Paperwhite; all Margins set at 1.0 pt
Structure definition: all fields cleared, Chapter Mark=none
AZW3 output: Do not add TOC selected

I solved the above problem for .azw3 by cutting/pasting the text as described, then saving as a different .html file rather than overwriting the old. However, now the main book title (just below cover image) is displayed Left Justified, and the above method does nothing to change this.

I also tried converting to .mobi; the same problem as described above (random indents) is present, see on very first page. Same Calibre options as for AZW3.

A 2nd "problem": endnote references in my source document are not superscripted, and I have formatted them with a style that (usually) Calibre doesn't recognise as an endnote reference and so displays the references the same as the source document. This time, endnote references are superscript (which I don't like). Suggestions for this...?

Thanks!!!!

[kovidgoyal]

https://www.mobileread.com/forums/sho...d.php?t=186697

[kovidgoyal]

Attach the html document, that you are actually sending to calibre, not the .doc file.

[papalaz]

I tried to attach the .html file a number of times to begin with; I see the progress indicator go to 100%, but it doesn't appear in the list. I will try it in a different browser to see if that makes any difference...

Edit:

Ok, so I was being clueless...

.html source file now uploaded as .rar.

[kovidgoyal]

That html file is a god awful mess, follow the instructions here: http://manual.calibre-ebook.com/conv...word-documents to either convert using docx, or at least generate cleaner html.

[papalaz]

Thanks for your suggestions. I have no idea how to generate "clean .html"--I (perhaps naively) assumed that what I saw on the screen in the original .doc, and then in the .html from that .doc, was all there was to see.

I tried saving the source .doc as .docx (attached), added to Calibre & converted to .mobi. Everything looked fine apart from the seemingly random indenting of text. (See mobi1 & logmobi1).

If I then select Ignore Margins, indenting of the TOC is removed (which I don't want, see mobi2 & logmobi2).

In both of the above cases, each endnote apparently ends up on a different page when converted to .mobi.

Converting to .azw3 gives the same result (each endnote on a different page).

I tried saving the source .docx as .html then adding to Calibre & converting, but assuming that this also is not very "clean" .html, this also results in seemingly randomly indented blocks of text.

Best result so far is when converted from .docx--something I have avoided in the past due to unreliable results; I would now like to understand what is happening with the endnotes ("messy" source .docx...?)

Thanks again.

[kovidgoyal]

endnotes are always placed on separate pages. That is the most appropriate format for ebooks, it has nothing to do with the source docx. In an ebook a user jumps to an endnote by clicking a link and then jumps back by clicking the return link or the back button on the reader. Putting multiple endnotes on a single page is unnecessary in the scenario and leads to information leakage. It is only done that way in paper books to save printing costs.

[papalaz]

Strange; every book I've created in the past had all the endnotes on the same page. See for instance the attached; I think this was created with Calibre v.1.15 or thereabouts. Ok, this one has only 4 notes, but I've done others with thousands, and they're all listed on the same page, in every ebook I have previously created. This was why I raised the point--because it's the first time I've seen it. Personally I prefer them on 1 page, because firstly it allows easy referring to previous notes (simply page up or down), and secondly because especially when proof reading, in some books with a hundred consecutive "ibids", it's good to be able to see at a glance that you don't have to keep going to the endnotes.

If this is going to be the way Calibre treats endnotes from now on, is it possible to add the option to allow them on the same page?

Also, note that in this book, the endnote references are not superscripted (usually I change the footnote/endnote style in MS Word to Intense Emphasis, which in the past seemed to "spoof" Calibre into believing they were just normal links, or at least that's what I guessed was happening, as the method was pretty reliable until very recently).

[kovidgoyal]

Because you were converting from html and not docx. And no there is not going to be an option to place endnotes on the same page. I have explained why that makes no sense for ebooks, as such I have no interest in spending time on it.

[papalaz]

Ok, apologies--I didn't realise the conversion process was different for .html & .docx...

[kovidgoyal]

The conversion process is very different. You will almost always get better results from the docx.

[papalaz]

Ok, I'll have a play with .docx for a while, and possibly change my expectations. As I noted earlier, the results with .docx always seemed unreliable in the past, whereas working from a source .doc (rather than .docx) then saving as .html before conversion always gave me exactly the results I wanted.