"margin-top" property is converted into <number>em when converting into MOBI breaking iOS rendering

[rfog]

This seems to be a combination of a bug in iOS Kindle App and another in Calibre mobi converter.

Happens in Calibre 5.21.0 under macOS Big Sur 11.4 and as far as I remember since a lot of previous versions because this issue made me stop using Kindle apps for reading non Amazon purchased books.

I'm pasting here the explanation given by "jhowell" user in Mobileread as it describes the exact problem in great detail:

"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."

I can add that with a value of 20% in that property still happens, and the workaround I've found reduce the issue but not eliminate it. I've created a rule in Look & Feel -> Transform Styles that replaces a value >= 20% by 10em in "margin-top" and then the conversion seems done right but still starting of each chapter is shown very strange.

This is the post in Mobilieread cited above that clarifies the issue: https://www.mobileread.com/forums/showpost.php?p=4131186&postcount=8

And here is the entire thread: https://www.mobileread.com/forums/showthread.php?p=4131186#post4131186

I'm trying to report iOS Kindle App to Amazon but seems an impossible task to report bugs to them. If someone here knows how to report to them, please let me know.

I'm attaching one scrambled ePub sample and the resulting mobi.

[Kovid Goyal (kovid)]

I'm afraid I dont follow at all. First of all are you talking about
historic MOBI or azw3?? Historic MOBI supports no CSS and defintely
doesnt have either em based or percentage based units. If you are
talking about azw3 (i.e. new mobi) then please attach a sample epub file
that shows the issue when converted.

 status incomplete

[rfog (rfog)]

Kovid, you have attached inside the ZIP the original ePub and the generated mobi, that has been generated as "both" in the "MOBI file type" option in "MOBI output".

I absolutely ignore all about mobi (new or old) format internals, and I'm based in jhowell comment.

The fact is that a book converted from ePub with "margin-top" set to any value higher than 20% for first paragraph in chapter, and "both" as "MOBI file type" end with a MOBI that is wrong rendered in iOS Kinde application.

[Kovid Goyal (kovid)]

Converting your attached epub file to azw3 with default settings results in

.saltoinicio {
    display: block;
    line-height: 1.25em;
    text-align: justify;
    text-indent: 0;
    margin: 33% 0 0
    }

as expected.

[John Howell (jhowell-o)]

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.

[John Howell (jhowell-o)]

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.

[Kovid Goyal (kovid)]

Interesting MOBI historically never supported percentages for margin
values, only plain numbers. Presumably amazon changed their renderer to
add support at some point.

I'm afraid I am not interested in changing the calibre mobi output
plugin to use percentages, it's a large and invasive change that could
well break other things in what is an extremely stable and legacy
format. I will however special case handling of percentages in margins
to use the standard kindle profile rather than the user selected one.

[Kovid Goyal (kovid)]

Fixed in branch master. The fix will be in the next release. calibre is usually released every alternate Friday.

 status fixreleased

[John Howell (jhowell-o)]

I tried the change and it worked well for me. It solves the problem with a minimum of disruption.

Thank you!