gutenbergtools / ebookmaker

The Project Gutenberg tool to generate EPUBs and other ebook formats.
GNU General Public License v3.0
85 stars 18 forks source link

epub3 with Kindle for IOS does not display certain .x-ebookmaker blocks #131

Open charliehoward4dp opened 2 years ago

charliehoward4dp commented 2 years ago

The attached zip contains an html file and associated image folder that works properly with most ereaders, including with the Kindle Previewer 3 app on Windows, but does not work properly with the Kindle for IOS app on an iphone or ipad. A small change to the css allows it to work with most ereaders, including Kindle for IOS. The change is to remove ".x-ebookmaker " from lines 294-301.

Those css lines are intended to approximately center poetry blocks on epub readers, and they do that successfully on most ereaders, including the Kindle Previewer 3 app on Windows.

The problem is that, on the most recent Kindle for IOS app, those poetry blocks are not displayed at all. Instead, there are several blank lines where the poetry should be.

However, if ".x-ebookmaker " is removed from lines 294-301, the generated epub3 DOES display the poetry blocks on all ereaders, including Kindle for IOS.

The drawback to not using .x-ebookmaker on those lines is that the poetry blocks will not be centered as well in Browsers as they are when inline-blocks are used.

Although inline-blocks work surprisingly well with many ereaders, that cannot be used with certain eReaders: Nook discards any part of an ILB that doesn't fit on the page where the block begins, while Amazon's send-to-Kindle and Kindle Previewer 3 flatly reject them as invalid files.

The epub/mobis I've been using were created by the version 0.12.14 of eBookMaker, which is supplied with the latest test version of Guiguts (1.5.0-test9).

scott.zip

windymilla commented 2 years ago

Not having an IOS-based device, I can't test this directly. I did rename the epub3 to scott-images-epub3.zip and looked inside. The 1.css file looks correct, including the following CSS:

.x-ebookmaker .poetry-container.w25 {
    text-align: center;
    width: 30em
    }

The file 4704623872810410155_scott-24.html.xhtml which contains an example of poetry using the above w25 class also looks correct. It has the x-ebookmaker class on the <body>.

Given that it works correctly on other readers, it looks like the bug might be in Kindle for IOS, since the same ebookmaker output is being used on those devices. To check I understand correctly, it seems that it fails when the CSS selector uses the "is a descendant of" mechanism?

One way to test this further would be to add a div around the bit of poetry at line 4357:

<div class="x-ebookmaker">
<div class="poetry-container w25">
<div class="poetry">
  <div class="stanza">
    <div class="verse indent0">‘Washed their fair garments in the days of peace.’</div>
  </div>
</div>
</div>
</div>

Check if that works.

Then, change that added div line at 4357 to

<div class="mytestclass">

and edit line 294 to be

  .mytestclass .poetry-container.w25 {text-align: center; width: 30em;}

If that still fails, it shows that it is not related to the x-ebookmaker class.

eshellman commented 2 years ago

reading this thread: https://www.mobileread.com/forums/showthread.php?t=346530&highlight=send-to-kindle suggests that Amazon is so screwed up and behind schedule with their epub3 conversion that it would be a fool's errand to try to "fix" anything for the transitory benefit of making the kindle experience work today.

On the second-to-last page there's a hint of what might be happening TOC links using the body element screw up the entire TOC. The same bug is probably responsible for the behavior that Charlie reports.

If in 6 months, the same thing is happening, we can think about producing "EPUB for Kindle" versions.On the other hand, if all we have to do is move the x-ebookmaker class to a wrapper div, and it works with send-to-kindle... I would love to just abanndon MOBI for good.

The Scott epub css is is very sophiticated!

https://effectiviology.com/premature-optimization/

On Oct 5, 2022, at 5:07 AM, Nigel @.***> wrote:

Not having an IOS-based device, I can't test this directly. I did rename the epub3 to scott-images-epub3.zip https://github.com/gutenbergtools/ebookmaker/files/9714202/scott-images-epub3.zip and looked inside. The 1.css file looks correct, including the following CSS:

.x-ebookmaker .poetry-container.w25 { text-align: center; width: 30em } The file 4704623872810410155_scott-24.html.xhtml which contains an example of poetry using the above w25 class also looks correct. It has the x-ebookmaker class on the .

Given that it works correctly on other readers, it looks like the bug might be in Kindle for IOS, since the same ebookmaker output is being used on those devices. To check I understand correctly, it seems that it fails when the CSS selector uses the "is a descendant of" mechanism?

One way to test this further would be to add a div around the bit of poetry at line 4357:

‘Washed their fair garments in the days of peace.’

Check if that works.

Then, change that added div line at 4357 to

and edit line 294 to be .mytestclass .poetry-container.w25 {text-align: center; width: 30em;} If that still fails, it shows that it is not related to the x-ebookmaker class. — Reply to this email directly, view it on GitHub , or unsubscribe . You are receiving this because you are subscribed to this thread.
charliehoward4dp commented 2 years ago

Found and fixed(?) the problem: delete line 250, which reads: .poetry br {display: none;}

It isn't used any more, and I have no idea why it would cause a problem.

If others agree, someone can close this.

eshellman commented 2 years ago

kindlegen would crash if there was a link pointing to something in dispay:none so maybe this is just the same code

charliehoward4dp commented 2 years ago

I just downloaded an .epub and a .mobi from a poetry book I posted to PG in 2019. It used spans instead of css selectors to indent verses, and each line had to end with <br /></span> to force a new line for the next verse. In the css, .poem br {display: none;} was needed because some browsers or ereaders ( don't remember the details) would otherwise double-space lines ending that way.

I sent both to my iphone through Amazon's delivery service (really the only way to add things to a Kindle library). The .epub was accepted and the poems displayed properly on the phone. The .mobi was instantly rejected and Amazon sent me this email:

======================

Dear Kindle Customer,

Thank you for using the Send to Kindle service to send personal documents to your Kindle library. We noticed that the following document(s), sent by you at 02:41 AM on Thu, Oct 06, 2022 GMT are in MOBI (.mobi, .azw) formats:

We wanted to let you know that starting August 2022, you’ll no longer be able to send MOBI (.mobi, .azw) files to your Kindle library. Any MOBI files already in your library will not be affected by this change. MOBI is an older file format and won’t support the newest Kindle features for documents. Any existing MOBI files you want to read with our most up-to-date features for documents will need to be re-sent in a compatible format.

Compatible formats now include EPUB (.epub), which you can send to your library using your Send to Kindle email address. We’ll also be adding EPUB support to the free Kindle app for iOS and Android devices and the Send to Kindle desktop app for PC and Mac. Regards, Amazon Kindle Support

==================

(Back to my comments:) Note the August, 2022 date. People no longer can add .mobi's to their Kindle libraries, although they can continue using what's already in their libraries. Based on that, is there any reason for PG (or DP) to continue creating, testing, or offering .mobi's?