What exactly are Standard Ebook's "advanced epubs"?

[davidfor]

Originally Posted by JSWolf

Most novels do not have pictures or footnotes. I know some do and it you want to read the footnotes or be able to zoom the graphics, yes, KePub is better. But some books I've recently read that had footnotes I did not need t use a single footnotes as the footnotes were references to citations that I was not going to read. I don't need to know what publication some bit of the book was taken from. But be that it may, the problem is that these eBooks do not work with RMSDK.

If you look at Sony, nook, and Pocketbook, they all use some version RMSDK. Not everyone installs KOReader or even knows about it. So why insist on code that doesn't work?

I tested with @Davidfor's fix and it did not work, but removing that media query did allow the eBook to mostly work. But it still needs fixing because not all formatting working. But the code does not need to be so complicated I formatted the eBook with a lot simpler CSS code. And it's much more compatible.

Firstly, it does work. I was careful in my testing. I tested it on more than one book, including the original version of the one you edited, and more than one device. If you think it is broken, post the book to prove you got it right. Did you actually put it on a Kobo device?

And I'm curious about what formatting didn't work. I can think of some, but, that is stuff that would fail because it is not supported under ePub2 or the RMSDK, but, that is expected and they fail gracefully. I'm thinking of things like small-caps.

And you are wrong overall here. Your code will work for the RMSDK based ereaders, but, does not take advantage of newer features in other ereaders or apps. Some of those things are good to do. Including that @media query, if it is doing what I believe it is doing. Unfortunately, I don't have something I can test it on. They are trying to produce books with some style and automate the build as much as possible. That will mean some concessions, but, overall, I think the books look good where they work. I'm mainly disagreeing with what the base level support should be. I can demonstrate the "Compatible epub" does not work in two environments. I can think of at least one more where I am sure it won't, plus a couple of others where it probably won't work. That makes use of the word "Compatible" questionable.

[robin_reala]

By definition, we only work on PD “classics”.

Anyway, thanks for the tip on the @media block problem. That’s easy enough to fix, and I’ve PRed it for Alex to merge later: https://github.com/standardebooks/tools/pull/385

If there are other things that would make the RMSDK experience better without causing problems for more modern reading systems then I’m sure we’d be happy to take them. Maybe you could clarify the suggested widows / orphans fix?

I’m going to investigate ligatures in the Kobo renderer too. There are CSS flags to enable them globally, so it might be a simple fix if it has built in support.

[JSWolf]

Originally Posted by robin_reala

By definition, we only work on PD “classics”.

Anyway, thanks for the tip on the @media block problem. That’s easy enough to fix, and I’ve PRed it for Alex to merge later: https://github.com/standardebooks/tools/pull/385

If there are other things that would make the RMSDK experience better without causing problems for more modern reading systems then I’m sure we’d be happy to take them. Maybe you could clarify the suggested widows / orphans fix?

I’m going to investigate ligatures in the Kobo renderer too. There are CSS flags to enable them globally, so it might be a simple fix if it has built in support.

For KePub, you also need to have the text fully justified or you cannot add in the code needed to enable hyphenation which you should also do.

As for what formatting would need fixing to work in RMSDK, I'll take a better look.

[robin_reala]

You can definitely have left-justification and hyphenation on kepubs. The first line of a book I recently worked on hyphenates after “Navi” in the word “Navigation”, and it’s left justified. Maybe there’s a difference between hyphens: auto in CSS, and automatically inserting soft hyphens at hyphenation points (which is what we do).

[acabal]

Originally Posted by davidfor

Which to choose really comes down to personal opinion. And whether people can be bothered installing the software to change books to kepubs. There are differences in the font handling and epub does win out there. For example, the Adobe RMSDK will use ligatures, whereas the kepub renderer won't. And for an ugly error in a kepub, just look for a em-dash in a justified book. Some people think these things are important. Some don't care.

You're describing the entire problem. We get to make one epub, and because each renderer is precious in its own special way, there's not going to be one epub that works perfectly in all renderers. Concessions are going to be made, just like they were for websites in the IE6 days when each web browser did things differently. One of those concessions is deeming software as out-of-date and not supported if it cannot read files in a 9-year-old standard.

Originally Posted by davidfor

And the fact that these are not compatible with these older devices means that you are alienating a group of people that might need these books. There are still plenty of people using these old devices.

The fact that old devices no longer receive firmware updates, and that this forum is, in 2020, recommending closed-source abandonware from 2012 as the default ereading program, is the core problem. Perhaps instead of sneering at the volunteers bringing free ebooks, we should sneer at the device makers who force closed source software on us that locks us into a crappy ereading experience for literally a decade. Consumers should perhaps think twice before buying a device they have no control over. And perhaps this forum should consider recommending a newer open-source alternative, instead of a ancient abandonware that due to its closed-source nature can never be upgraded. I can't wait to return to this forum in 2030 to hear how ADE 2.0.1 is still the ereading champion and how literally everyone and their mother is still using it, and by the way we recommend AOL Instant Messenger as the best chat program.

Originally Posted by davidfor

Whether you make this change or not is up to you. But, at the moment, your claim of "Compatible epub" is not particularly valid.

Clearly we disagree on this front. Fortunately we have statistics on our side; this has never come up in the ~6 years SE has been around and the many millions of ebook downloads in that time.

Originally Posted by davidfor

From my experience, the differences in rendering between the different renderers are rarely significant.

This is simply not true and anyone working on ebooks in the past decade will tell you that each renderer has its own rendering quirks and problems. They might not be as obvious if you're working on a plain prose novel with literally no formatting, but those are not as common as you seem to suggest. As Robin stated 40% of our corpus has endnotes, for example; and it's not like new books don't have their own unique formatting requirements. Again, developing ebooks today is like developing for the web during IE6. You get to distribute one file, to a bunch of different renderers with different ideas of how to render.

In any case, I think I'm done here. We seem to fundamentally disagree on the definition of what compatibility means, and that's fine. Our definition does not include your favorite ereader; but that does not make it untrue, because the favorite ereader of this forum is abandonware and would be considered unsupported by any reasonable technical body. The only truly compatible format is plain text, after all.

I'll once again extend my invitation to any of you to join our volunteers and fix any problems you see yourselves: https://github.com/standardebooks/tools As with all volunteer-based projects, lecturing their contributors is rarely the way to enact the change one wants to see. The best way to prove one's technical chops is with real contributions.

[PeterT]

You do realize that Kobo eReaders do get regular updates? The only models not getting any upgrades are the original Kobo's (Bluetooth and WiFi). The mini does not get official support but the correct build can be downloaded to it.

[Bookstooge]

Originally Posted by acabal

lecturing their contributors is rarely the way to enact the change one wants to see. The best way to prove one's technical chops is with real contributions.

Have I completely misread all the previous posts? Or is this one of the most ironic statements here on MR?

[JSWolf]

Originally Posted by robin_reala

You can definitely have left-justification and hyphenation on kepubs. The first line of a book I recently worked on hyphenates after “Navi” in the word “Navigation”, and it’s left justified. Maybe there’s a difference between hyphens: auto in CSS, and automatically inserting soft hyphens at hyphenation points (which is what we do).

RMSDK on Kobo does not hyphenate if the text is left justified. SO in order to allow RMSDK on Kobo to justify, the text has to be fully justified. Besides, most prefer full justification.

[JSWolf]

Originally Posted by acabal

You're describing the entire problem. We get to make one epub, and because each renderer is precious in its own special way, there's not going to be one epub that works perfectly in all renderers. Concessions are going to be made, just like they were for websites in the IE6 days when each web browser did things differently. One of those concessions is deeming software as out-of-date and not supported if it cannot read files in a 9-year-old standard.

Please download the ePub I fixed up and posted in this thread. .Please try it on all the renderers that you test with and even test with ADE 2.0.1 and you'll see that it works on all of them. I have a very simple CSS that allows the ePub to render correctly in more places then yours does. I would like you to prove to me that I am wrong. I dare you to find a renderer that my changes faill to render correctly.

[pdurrant]

This thread seems to have become rather heated. I remind all members of the need to discuss things politely.

[pdurrant]

Anyone wishing to make improvements to the way Standard Ebooks presents their ebooks should remember that they are not hand-crafting individual books, but have books in a standard format which is then automatically processed to produce variants ('compatible' epub, kepub, etc).

Suggesting changes to individual books isn't very useful. Suggesting changes to the code that produces the variants to increase compatibility without compromising modern coding standards, would help.

davidfor's example of the media query is excellent. A simple change that does not compromise on the modern standards, but enables older systems to render the book more faithfully.

Similar suggestions will, I expect, be welcomed by Standard Ebooks.

[davidfor]

Originally Posted by JSWolf

RMSDK on Kobo does not hyphenate if the text is left justified. SO in order to allow RMSDK on Kobo to justify, the text has to be fully justified. Besides, most prefer full justification.

And the first thing I do when I fiddle with a book is to remove the justification. If I want it justified for some reason, I will do it on the device. By not having it hard-coded in the book, everyone can be happy.

[davidfor]

Originally Posted by pdurrant

Anyone wishing to make improvements to the way Standard Ebooks presents their ebooks should remember that they are not hand-crafting individual books, but have books in a standard format which is then automatically processed to produce variants ('compatible' epub, kepub, etc).

And I'd like to be clear, I basically agree with what Standard Ebooks are doing. I'm not sure if I agree with style they use, but, I think I prefer it to what Jon wants to use. My issue is with how the books are labelled for use. And that when we started looking at these, the "compatible epub" were not. Or at least I have no idea what they are supposed to be compatible with.

[JSWolf]

Originally Posted by davidfor

And the first thing I do when I fiddle with a book is to remove the justification. If I want it justified for some reason, I will do it on the device. By not having it hard-coded in the book, everyone can be happy.

That won't work for some Readers such as the old Sony Readers. They didn't have a way to justify the text other then in the CSS. And if the compatible ePub do get fixed to actually be compatible, then those that have a program or a Reader that doesn't allow switching justification, are stuck with left justified. I'm not saying you are wrong, but more people do prefer full then left.

In the poll on MR about left or full justification, 19 people voted left, 21 voted full, and 5 voted don't care.

[JSWolf]

Originally Posted by davidfor

And I'd like to be clear, I basically agree with what Standard Ebooks are doing. I'm not sure if I agree with style they use, but, I think I prefer it to what Jon wants to use. My issue is with how the books are labelled for use. And that when we started looking at these, the "compatible epub" were not. Or at least I have no idea what they are supposed to be compatible with.

What I think is the best way to handle the problem is to use simple compatible CSS for the compatible ePub and to keep ePub 3 to the advanced ePub. That works for more people. Anyone who needs accessibility would not be using a program that didn't handle ePub 3,