"text-indent" not working in Kindle for iOS

[rfog]

I'm trying to convert some ePub books into mobi to be sent to Kindle for iOS but seems the application has some kind of bug that ignores this css property.

Original ePub <p> has in style.css property of "text-indent" set to 1.5em. Same ebook in Kindle e-ink devices and Android Kindle app formats right the first line in a paragraph, but Kindle for iOS not and is shown without any indentation.

This is the css part:

p {
margin: 0;
text-align: justify;
text-indent: 1.5em;
line-height: 125%;
}

Any solution to this? Thanks in advance.

[rfog]

It is even worse, at start of each chapter, it does not show first line... Sending as "Both" types of mobi seems the paragraph is resolved, but still first line of chapter is not shown.

[rfog]

Even setting the style for the paragraph from one AZW from Amazon, fails. However, the original book does not fail.

I'm start thinking this is intentional.

Seems the only way to make this work is selecting "Completely removing Margin" option in Look & Feel.

[jhowell]

I have looked at many MOBI books in Kindle for iOS and have never experienced a problem with missing text indent or missing first lines of chapters. There is likely something wrong with your book that is leading to this behavior.

Have you checked your original EPUB for problems using EPUBCheck or a similar tool?

How are you produce the MOBI file? calibre, Kindle Previewer, or something else?

Can you post a non-copyrighted sample file that exhibits this problem?

[rfog]

Originally Posted by jhowell

I have looked at many MOBI books in Kindle for iOS and have never experienced a problem with missing text indent or missing first lines of chapters. There is likely something wrong with your book that is leading to this behavior.

Have you checked your original EPUB for problems using EPUBCheck or a similar tool?

How are you produce the MOBI file? calibre, Kindle Previewer, or something else?

Can you post a non-copyrighted sample file that exhibits this problem?

The problem, AFAIK, is present in at least the more than 90 000 ePubs I have. And yes, EPUBcheck returns no error.

I produce it with Calibre.

And sorry, no, I cannot sample a non-copyrighted book. :-(

I will continue with my fight.

[JSWolf]

rfog, use the Scramble eBook plugin and try the scrambled eBook. If it still shows the error(s), then you can attach it here so it can be looked at to see what might br going on.

[rfog]

Thanks, JSWolf, I didn't knew that Calibre Plugin

Attaching original and converted scrambled from original, no special options set to do the conversion in Calibre.

Uploaded captures shows the most important issue. Central image is black but should contain some lines, the starting of the chapter. And sometimes, going back and forth between pages, the omitted lines are shown.

[jhowell]

The EPUB file has a class named saltoinicio which sets margin-top:33% for the first paragraph of a chapter. Percentage for a margin is based on the width of the container so for a typical portrait page orientation that should make the paragraph start about a quarter of the way down the page.

In the MOBI file produced by calibre that 33% is changed to instead be 150em, which is an unreasonably huge value! That looks to me like a calibre bug. This in turn appears to trigger a bug in the MOBI renderer under iOS, causing the paragraph to start on the next page with some of the initial text missing. The MOBI renderer obviously should not be doing that, but it is somewhat of a garbage-in garbage-out situation.

I converted the EPUB to MOBI using Amazon's Kindle Previewer and in the MOBI file that it creates it leaves the value at 33% and this works OK when loaded into Kindle for iOS. So one possible fix to to use that instead of calibre for this conversion.

[rfog]

Originally Posted by jhowell

The EPUB file has a class named saltoinicio which sets margin-top:33% for the first paragraph of a chapter. Percentage for a margin is based on the width of the container so for a typical portrait page orientation that should make the paragraph start about a quarter of the way down the page.

In the MOBI file produced by calibre that 33% is changed to instead be 150em, which is an unreasonably huge value! That looks to me like a calibre bug. This in turn appears to trigger a bug in the MOBI renderer under iOS, causing the paragraph to start on the next page with some of the initial text missing. The MOBI renderer obviously should not be doing that, but it is somewhat of a garbage-in garbage-out situation.

I converted the EPUB to MOBI using Amazon's Kindle Previewer and in the MOBI file that it creates it leaves the value at 33% and this works OK when loaded into Kindle for iOS. So one possible fix to to use that instead of calibre for this conversion.

Wow! Impressive explanation. Thank you very much!!!

I'm going to attack this in 3 ways.

1) File a Calibre bug based in this conversation to see if Covid can do something.
2) File a Amazon bug, as same ebook is shown right in e-ink devices and Android ones but not in iOS.
3) Change that "saltoinicio" to a reasonable value or remove it.

BTW, do someone how to file a bug to Amazon? I found nothing in their website.

[rfog]

Back again. I found a workaround for this, that is add a rule in Look & Feel.

Basically, if "magin-top" is higher or equal than 20% it is changed to "10em"

I'm attaching here.

BTW, this is basically for EPL/EPG Libraries.

[jhowell]

Originally Posted by rfog

Wow! Impressive explanation. Thank you very much!!!

I enjoy looking into odd problems like this.

Originally Posted by rfog

BTW, do someone how to file a bug to Amazon? I found nothing in their website.

I don't know of any way to get in touch with the right people and I doubt that they would do anything about this problem even if you could. Almost all books sold by Amazon are delivered in KFX format these days. MOBI and KF8 are legacy formats and the rendering software for them has not been changed in many years.

[rfog]

Filed a bug:

https://bugs.launchpad.net/calibre/+bug/1932392

(And result from Kovid). Whatever the problem could be, it is not going to be resolved. :-(

He generated one AZW well (but I wanted a mobi with "both" inside).

[rfog]

Many thanks, @jhowell, for adding to the bug report.

[jhowell]

I will repeat the two comments that I posted to the calibre bug tracker here in case they are on interest to anyone following this discussion.

----------------------------

This problem was first noticed in the Kindle for iOS app which uses the old MOBI part of the file.

In the original EPUB the file 003.xhtml starts with "<p class="saltoinicio asangre">Rwe jfbnmv qw ey Ydfjdh cxw xtytccn". The style for class "saltoinicio" in style.css is ".saltoinicio { margin-top:33%; }". So the intent is to have the paragraph start part of the way down the screen.

The corresponding old MOBI content produced by calibre is "<p height="150em" width="0pt" align="justify">Rwe jfbnmv qw ey Ydfjdh cxw xtytccn". The 33% value has been converted to 150em. This makes no sense to me. It implies that a screen width of 450em was used as the conversion factor.

This huge value causes the MOBI renderer to perform incorrectly in the Kindle for iOS app resulting in the initial text of that paragraph not being displayed.

When the same EPUB is run through kindlegen the old MOBI part of the result instead has "<p height="33%" width="0" align="justify">Rwe jfbnmv qw ey Ydfjdh cxw xtytccn". This renders much better when tested using the Kindle for iOS app and also on an old Kindle 2 device.

----------------------------

I was able to determine what is happening in this case.

I always convert using the Tablet profile in order to prevent images from being downsized. It did not occur to me that the screen size set by the Output Profile also comes into play during conversion of sizes in the content of the book. Selecting the Kindle output profile (525x640 pixels) instead of Tablet (10,000x10,000 pixels) changed the top margin from 150em down to a far more reasonable value of 5em. The resulting MOBI file renders fine under Kindle for iOS.

In the end this is a case of user error. Still, it would be nice if there was a way to avoid downsizing images while at the same time having reasonable screen dimensions for size calculations during conversion.

[rfog]

I had the exact same idea, input profile to to not downscale graphics, but I changed to Kindle and still had the same issue in other books.

We will see the next update done by Kovid in next version.