Footnote problem in kepub conversion

[theducks]

Wolfie ???
Fake small caps use real uppercase with a reduced font size (~.85em)

Real smallcaps just use the style

Fake, is because not all devices do the real kind (or poorly)

[JSWolf]

Originally Posted by theducks

Wolfie ???
Fake small caps use real uppercase with a reduced font size (~.85em)

Real smallcaps just use the style

Fake, is because not all devices do the real kind (or poorly)

Most eBooks with smallcaps use the fake variety.

[Quoth]

Originally Posted by JSWolf

Most eBooks with smallcaps use the fake variety.

I'd not be dogmatic on that.

[JSWolf]

Originally Posted by Quoth

I'd not be dogmatic on that.

I've seen many more eBooks with fake smallcaps then real smallcaps.

[DNSB]

Originally Posted by JSWolf

I've seen many more eBooks with fake smallcaps then real smallcaps.

Around here, it runs about 75% fake/25% real. A big enough percentage that I'm not going to guess which is used in any new ePubs.

[nabsltd]

Originally Posted by DNSB

Around here, it runs about 75% fake/25% real. A big enough percentage that I'm not going to guess which is used in any new ePubs.

This is another one of the many problems that could be solved if people who edit eBooks bothered to take the time to learn how reading software works.

Using font-variant: small-caps and lowercase text will always result in small caps on all modern CSS renderers. If the reading font has the "scap" OpenType feature, then the software will use real small caps (or at least those supplied by the font). OTOH, if the reading font doesn't have "scap", then the renderer will synthesize small caps by using reduced height uppercase.

So, by always using "real" small caps, you end up with the best possible display...either true small caps, or the exact same display you get with uppercase text and font-size: 0.8em.

[Quoth]

Originally Posted by nabsltd

Using font-variant: small-caps and lowercase text will always result in small caps on all modern CSS renderers. If the reading font has the "scap" OpenType feature, then the software will use real small caps (or at least those supplied by the font).

Ah, but how many people are not on "modern" CSS renderers or there isn't "scap" OpenType feature?

I understand what you are saying, but have you any idea how many people it doesn't apply to?

Curiously the actual text with the CSS for SMALL CAPS I've seen is often in ALL CAPS, no doubt for the ereaders and apps that don't understand.

The universal cowardly solution is of course to not even simulate small caps at all. It's often done at the start of a chapter, when technically it's only things like 7 PM or 425 BC that "need" it, but even then not all style guides demand it. Some USA newspapers.

[theducks]

Look at some of the Reading hardware MR members STILL use.

When was the last time an Update of the firmware (reading app), was even available? (and that assumes the owner knows how to load it)

Also look at why Calibre still offers versions way way back.
Why? Because not everybody works for places that keep hardware and OS up to date (or has a personal budget that allows unneeded upgrades)
For many, Run it till it drops is a reality.
WE are lucky and have a place to keep our computer and read comfortably. Many don't even have plenty of food.

[JSWolf]

Originally Posted by nabsltd

This is another one of the many problems that could be solved if people who edit eBooks bothered to take the time to learn how reading software works.

Using font-variant: small-caps and lowercase text will always result in small caps on all modern CSS renderers. If the reading font has the "scap" OpenType feature, then the software will use real small caps (or at least those supplied by the font). OTOH, if the reading font doesn't have "scap", then the renderer will synthesize small caps by using reduced height uppercase.

So, by always using "real" small caps, you end up with the best possible display...either true small caps, or the exact same display you get with uppercase text and font-size: 0.8em.

It's actually better to use simulated smallcaps. You don't know what font is going to be used and you don't know what reading software is going to be used.

[DNSB]

Originally Posted by JSWolf

It's actually better to use simulated smallcaps. You don't know what font is going to be used and you don't know what reading software is going to be used.

But simulated small caps are all too often UGLY!

And here I thought from your posts, that you were all about producing the best looking ebook. Disillusionment sets in.

[JSWolf]

Originally Posted by DNSB

But simulated small caps are all too often UGLY!

And here I thought from your posts, that you were all about producing the best looking ebook. Disillusionment sets it.

I know simulated smallcaps are not great. But as I use a Kobo and I use RMSDK mostly, either I have simulated smallcaps or I have uppercase. I'll go for the simulated smallcaps.

[Quoth]

Originally Posted by DNSB

But simulated small caps are all too often UGLY!

And here I thought from your posts, that you were all about producing the best looking ebook. Disillusionment sets it.

Yes, not doing them at all looks better!

[nabsltd]

Originally Posted by Quoth

Ah, but how many people are not on "modern" CSS renderers or there isn't "scap" OpenType feature?

I understand what you are saying, but have you any idea how many people it doesn't apply to?

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.

[nabsltd]

Originally Posted by JSWolf

It's actually better to use simulated smallcaps. You don't know what font is going to be used and you don't know what reading software is going to be used.

Using real smallcaps will fall back to simulated if real ones aren't available. This has been around since CSS 2.1, which is now a 12 year old final standard, with working documents more than 15 years old. If your reader can't support a 12 year old standard that has been replaced with a newer one, then you need to get a new reader.

So, it's always better to use real.

[DNSB]

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.

And yet we look at the number of posts from people who use renderers such as Moon+ where to even enable it's limited CSS support calls for digging down multiple levels and yet they claim those crippled applications are the best ePub reader experience.

To you, to me and likely to many MobileRead users, CSS support is important, to others, it seems that if the renderer shows the book one level above a pure text file, they are happy.