Footnote problem in kepub conversion

[JSWolf]

Originally Posted by nabsltd

Although I know there are many people who stick with older version of firmware, I learned from my first eReader (Onyx Boox) that CSS support is probably the most important thing overall, and without a doubt the most important once you open the book.

We all complain about how MOBI sucks because it had such reduced set of CSS available (and all had to be done with style="" inside the tag. Yet, people seem more than willing to stick with older firmware that doesn't understand CSS that makes it much easier to have a well-formatted, easy-to-read book.

So, I really don't have a lot of sympathy for somebody still trying to limp along with 10-year-old eReader that hasn't had any firmware updates.

That said, small caps are just one of the many things that can be done in such a way that any reader with firmware from the past 3 years will do the right thing, and older readers will at least show the text, even if it isn't in uppercase letters that are smaller than normal. There's also options like CSS media queries, etc., that just aren't used at all by most commercial eBooks.

Sorry, but incorrect. My Kobo firmware is updated with the recent firmware. Yet the version of RMSDK used does not support small-caps. Just because the firmware is updated does not mean we will get smallcaps. So the only way to guarantee smallcaps is to use a smaller font sizes.

[nabsltd]

Originally Posted by JSWolf

Yet the version of RMSDK used does not support small-caps.

This is why I refuse to use any reader that doesn't support basic CSS correctly, especially properties that have been in the specification for 15 years.

For years, browsers implemented the CSS small-caps property as reduced-size uppercase, because there were very few fonts with true small capitals. Now, all browsers try to use true small capitals if the font supports it, but still fall back to reduced-size uppercase.

If RMSDK chooses not to do what has been done for the past decade, it doesn't deserve to be called "eReader software".

[Quoth]

An ereader is not a web browser and ebooks are not websites.

There is NO ereader that does all the CSS & HTML a website + browser can do.

[nabsltd]

Originally Posted by Quoth

There is NO ereader that does all the CSS & HTML a website + browser can do.

I'm not expecting that, but I do expect that a current release eReader will support CSS that was supported 10 years ago by every browser. If an current-release eReader uses webkit or other rendering framework as its base, there is no excuse for completely ignoring CSS properties that have been supported by that framework for over 5 years.

In other words, it's actually harder to disable support for CSS properties than to just let the framework do what it was written to do. I understand tossing out HTML and CSS support that has little use in an eReader (forms, scripting, etc.), but basic formatting that has been solved for many years makes little sense.

[JSWolf]

Originally Posted by nabsltd

I'm not expecting that, but I do expect that a current release eReader will support CSS that was supported 10 years ago by every browser. If an current-release eReader uses webkit or other rendering framework as its base, there is no excuse for completely ignoring CSS properties that have been supported by that framework for over 5 years.

In other words, it's actually harder to disable support for CSS properties than to just let the framework do what it was written to do. I understand tossing out HTML and CSS support that has little use in an eReader (forms, scripting, etc.), but basic formatting that has been solved for many years makes little sense.

RMSDK does not use webkit. There are a number of programs for reading that have nothing to do with webkit. RMSDK never used webkit. RMSDK is the framework behind Adobe Digital Editions.

[theducks]

Originally Posted by nabsltd

I'm not expecting that, but I do expect that a current release eReader will support CSS that was supported 10 years ago by every browser. If an current-release eReader uses webkit or other rendering framework as its base, there is no excuse for completely ignoring CSS properties that have been supported by that framework for over 5 years.

In other words, it's actually harder to disable support for CSS properties than to just let the framework do what it was written to do. I understand tossing out HTML and CSS support that has little use in an eReader (forms, scripting, etc.), but basic formatting that has been solved for many years makes little sense.

EPUB is a subset. Browser do full motion (animation). e-ink (a common display) does not or just barely) ipdf.org is the site to read about e-book formats

[nabsltd]

Originally Posted by JSWolf

RMSDK is the framework behind Adobe Digital Editions.

This is one of the many reasons Adobe Digital Editions sucks. Because of the "not invented here" attitude, Adobe created a CSS renderer that still can't correctly display what other CSS renderers could correctly display 15 years ago.

Every CSS renderer has its quirks, but often those exist because of a closed system (like Amazon Kindle). The more open system of Adobe Digital Editions—which needs to support EPUB from dozens of sources—should be as compliant as possible to the EPUB, XHTML, and CSS standards. Its failings are part of the reason we have such poor formatting on so many eBooks...they have to format to the lowest common denominator.

[Quoth]

ADE exists to support a closed system, Adobe DRM on epub. Also the epub specs are a subset of Web. A Website isn't an ebook. A lot of epub3 stuff doesn't apply to novels.

Poor formatting on ebooks is due to poor design choices, or trying to be too clever, or lack of expertise. You can have ebooks that look almost the same in an ereader sized window in wordprocessor, ADE epub and Kindle azw3. The kepub and kfx will render less like the original.

@nabsltd
You need to produce ebooks that suit what 95%+ of people are reading them on, not chase after what either paper or web browsers can do. Also every day I encounter appallingly designed websites, or websites that only work perfectly in Chromium and I don't encounter so many bad ebooks. The really bad ones (people that are too clever, or misusing InDesign, Vellum etc) are easily fixed in Calibre and then a pleasure to read, if well written.

Over 90% worldwide in English sales of ebook are Amazon. Slightly more than 1/2 read on Kindle App on phone/tablet (and till recently much poorer on iOS Kindle App), the rest on Kindles.
And then older Kindles are HTML3 and no embedded fonts.
You also can't make Kindle users use the Publisher settings/fonts. The default is an Amazon Theme.

Edit:
There are loads of things I would have done differently in an ebook spec. But no-one asked me.

[nabsltd]

Originally Posted by Quoth

Over 90% worldwide in English sales of ebook are Amazon. Slightly more than 1/2 read on Kindle App on phone/tablet (and till recently much poorer on iOS Kindle App), the rest on Kindles.
And then older Kindles are HTML3 and no embedded fonts.
You also can't make Kindle users use the Publisher settings/fonts. The default is an Amazon Theme.

Other than the stupid drop cap font sizing on KFX, my source EPUB looks the same when read by a variety of readers with reasonable CSS support (tables and small caps are the only things that might fall back to something that is just wrong) and on the Kindle as KFX. I use some embedded fonts for special features (handwriting, chapter names, etc.), but if the device falls back to the base font because it doesn't have the capability, that's not the end of the world. I never set the base reading font in the EPUB...even my old Onyx Boox allowed me to pick that.

If I could figure out a media query that picked just KFX so I could have drop cap formatting for that format separate, then I'd have a single file that would be fine pretty much everywhere: KFX and KF8 Kindles, and other readers that support EPUB. I really don't even try to deal with devices that only support MOBI.

[JSWolf]

Originally Posted by nabsltd

This is one of the many reasons Adobe Digital Editions sucks. Because of the "not invented here" attitude, Adobe created a CSS renderer that still can't correctly display what other CSS renderers could correctly display 15 years ago.

Every CSS renderer has its quirks, but often those exist because of a closed system (like Amazon Kindle). The more open system of Adobe Digital Editions—which needs to support EPUB from dozens of sources—should be as compliant as possible to the EPUB, XHTML, and CSS standards. Its failings are part of the reason we have such poor formatting on so many eBooks...they have to format to the lowest common denominator.

The current version of ADE does support ePub 3. The fault does not belong to Adobe but to Kobo for not implementing the latest RMSDK. But then if Kobo did implement the latest RMSDK, they would not have a need for KePub.

[DNSB]

Originally Posted by JSWolf

The current version of ADE does support ePub 3. The fault does not belong to Adobe but to Kobo for not implementing the latest RMSDK. But then if Kobo did implement the latest RMSDK, they would not have a need for KePub.

Kobo would also have to use ADEPT DRM ($$$) instead of their proprietary and free to them DRM.

Also, a comparison between Kobo's webkit based ePub3 renderer and the latest ADE shows that Kobo's renderer supports more of the ePub3 standard. Though for 99.9% of the users, I suspect they would see no difference.

[jhowell]

Originally Posted by nabsltd

If I could figure out a media query that picked just KFX so I could have drop cap formatting for that format separate, then I'd have a single file that would be fine pretty much everywhere: KFX and KF8 Kindles, and other readers that support EPUB. I really don't even try to deal with devices that only support MOBI.

@media amzn-et

[JSWolf]

Originally Posted by DNSB

Kobo would also have to use ADEPT DRM ($$$) instead of their proprietary and free to them DRM.

Also, a comparison between Kobo's webkit based ePub3 renderer and the latest ADE shows that Kobo's renderer supports more of the ePub3 standard. Though for 99.9% of the users, I suspect they would see no difference.

https://www.adobe.com/solutions/eboo...-editions.html

A richer reading experience with EPUB 3 support

ADE is ranked among the best EPUB3 readers by EPUBTest.org. The support for EPUB 3 standard allows you a richer reading experience, including: rendering of audio and video content; support for right to left reading; dynamic image resizing without loss in clarity, interactive quizzes, better rendering of math formulas and huge improvements in support for assistive technologies.

[DNSB]

Originally Posted by JSWolf

A richer reading experience with EPUB 3 support

ADE is ranked among the best EPUB3 readers by EPUBTest.org. The support for EPUB 3 standard allows you a richer reading experience, including: rendering of audio and video content; support for right to left reading; dynamic image resizing without loss in clarity, interactive quizzes, better rendering of math formulas and huge improvements in support for assistive technologies.

The latest version of ADE is getting better but it is not quite there yet. Also, since you posted the link to epubtest.org, did you actually take the trouble to browse that page? Digital Editions for Windows and MacOS managed 75% on visual adjustments. Compare those test results to Thorium on those OS.

For those who want to do their own testing, you can download the test books from epubtest.org and do your own tests.

[nabsltd]

Originally Posted by jhowell

@media amzn-et

That works perfectly. The drop cap in the EPUB via various readers now looks the same as in the KFX on the Kindle.

It also allows me to put the negative margins for Kindle into the same media query.