Ebook Reader Fury

[d351r3d]

Originally Posted by pdurrant

Clearly I've misunderstood what you're trying to achieve.

I wanted to know why the apps are doing what they do and it has nothing to do with how I'm formatting the CSS or HTML. It has to do with the apps being limited. Which is a bummer. My question should've been, if I would've known that the apps were this limiting because no one actually formats anything in the corporate digital book world.

[d351r3d]

Originally Posted by DiapDealer

You don't have to. That's pretty-much the point.

Make sure it's neat; make sure it validates; make sure it looks clean on mainstream retail devices/apps, and move on. Trying to micromanage the typographical experience every single reader has on every single device or app when looking at your work is pointless: it can't be successfully done (and quite often isn't at all appreciated if it's forced upon them with no option to override). Let the user/renderer decide what font, font-size, line-height, margins, etc... to apply and move on.

That's what I was going to do. I just wanted to grasp what's going on. I thought I was just not doing it right. I was doing it right the apps just don't care.

[DiapDealer]

There's usually hoops you can jump through to fix some quirk of some particular rendering system, but those workarounds can also expose new quirks on different systems. You end up chasing your own tail for mostly no gain.

The heading tag causing a page-break on Moon Reader is probably one of those quirks. But there may also be a Moon Reader user setting that stops that from happening (I've no idea for sure: Moon Reader's user preferences are dauntingly all-encompassing). The point is that Moon Reader users who the page-breaks bother will know about such a setting and "fix it", and those who it doesn't bother won't be bothered by it.

[d351r3d]

Originally Posted by DiapDealer

There's usually hoops you can jump through to fix some quirk of some particular rendering system, but those workarounds can also expose new quirks on different systems. You end up chasing your own tail for mostly no gain.

The heading tag causing a page-break on Moon Reader is probably one of those quirks. But there may also be a Moon Reader user setting that stops that from happening (I've no idea for sure: Moon Reader's user preferences are dauntingly all-encompassing). The point is that Moon Reader users who the page-breaks bother will know about such a setting and "fix it", and those who it doesn't bother won't be bothered by it.

I'm going to do the bare minimum which is what I was trying to do. I did learn a lot of stuff along the way trying to figure it out. I'm just a bit salty and that's about it. Lol

[d351r3d]

Originally Posted by pdurrant

It may be that Moon Reader just assumes that any headings should come at the top of the page. Make them <p> paragraphs and apply a CSS style to them instead?

Is there a way to say do it the paragraph way and then use another way, say anchors to get the same effect in the TOS and not have it act all weird and glitchy in Moon+ Reader?

[pdurrant]

Originally Posted by d351r3d

Is there a way to say do it the paragraph way and then use another way, say anchors to get the same effect and not have it act all weird and glitchy in Moon+ Reader?

No idea. <h#> tags don't actually mean anything, although some sofwtare will treat them in special ways (e.g. to automatically generate a table of contents). there's nothing that can be done with a <h#> tage that can't be done with a styled <p> or even <div> tag.

[d351r3d]

Originally Posted by pdurrant

No idea. <h#> tags don't actually mean anything, although some sofwtare will treat them in special ways (e.g. to automatically generate a table of contents). there's nothing that can be done with a <h#> tage that can't be done with a styled <p> or even <div> tag.

It works with anchors. A bit to do with that in the TOC Editor but well worth it. No more h# and it looks better in Everything. Good times.

[Mister L]

Originally Posted by pdurrant

No idea. <h#> tags don't actually mean anything, although some sofwtare will treat them in special ways (e.g. to automatically generate a table of contents). there's nothing that can be done with a <h#> tage that can't be done with a styled <p> or even <div> tag.

I'm not sure that's a good way to put it. It's completely true that you can style a p or a div tag to look like a heading and to the reader there will be no difference. However the h tags have a semantic meaning (h = "heading" and the numbers 1-6 allow you to create a hierarchy with titles, subtitles etc.) which is useful for creating the toc in Sigil but also can be very important for other reasons, for example for accessibility (e.g. screen readers for blind people). If a reader turns off the css styles, h tags will still be displayed with default html styling that makes it clear they are headings and not just a paragraph of body text.

Semantically correct tags should always be used for their semantic value rather than for their appearance, and should never be mimicked on default tags (p, div) with css when the default tags are insufficiently specific.

[JSWolf]

Originally Posted by Mister L

I'm not sure that's a good way to put it. It's completely true that you can style a p or a div tag to look like a heading and to the reader there will be no difference. However the h tags have a semantic meaning (h = "heading" and the numbers 1-6 allow you to create a hierarchy with titles, subtitles etc.) which is useful for creating the toc in Sigil but also can be very important for other reasons, for example for accessibility (e.g. screen readers for blind people). If a reader turns off the css styles, h tags will still be displayed with default html styling that makes it clear they are headings and not just a paragraph of body text.

Semantically correct tags should always be used for their semantic value rather than for their appearance, and should never be mimicked on default tags (p, div) with css when the default tags are insufficiently specific.

I agree that the correct tags should be used. But if you don't go int the code to have a look, would you know the difference between <p class="chapter"> or <h2 class="chapter">? I wouldn't know the difference. When I clean up eBooks, I do leave the chapter header with the <p that the publisher put in. All I do is fix the class. If I was needing to generate a new ToC, <p would be replaced with <h2. But I don't know of any case (once the ePub is made) where there is any noticeable difference between <p and <h2 with the chapter class.

[Nightflyer]

“Epub Reader Fury” was so benign and lacking any description, and yet so intriguing, I had to read the thread.

Title doesn’t fit the subject, as innumerable threads are furious. This one, not as much.

“ Moon+ Reader just seems to do whatever it wants” would be descriptive and useful.

[d351r3d]

Originally Posted by Nightflyer

“Epub Reader Fury” was so benign and lacking any description, and yet so intriguing, I had to read the thread.

Title doesn’t fit the subject, as innumerable threads are furious. This one, not as much.

In the past I would've laid down more fire and brimstone. I just wanted to know why what I was doing wasn't working and showing up how html and css say it should render. I learned to ignore what the epub reader apps do because they are all mostly wrong. Not the epub creator as long as they're sticking to the laws that deal with epubs. Like Moon+ Reader. I just deleted it and was like here's your bad review for your terrible app and I finished the Bible and the Qur'an with this forums help. The help here is worth more than any app.

[Mister L]

Originally Posted by JSWolf

I agree that the correct tags should be used. But if you don't go int the code to have a look, would you know the difference between <p class="chapter"> or <h2 class="chapter">? I wouldn't know the difference. When I clean up eBooks, I do leave the chapter header with the <p that the publisher put in. All I do is fix the class. If I was needing to generate a new ToC, <p would be replaced with <h2. But I don't know of any case (once the ePub is made) where there is any noticeable difference between <p and <h2 with the chapter class.

You might not know the difference as a human reader looking only at the rendered code. However the rendering engine knows the difference, and off the top of my head I can think of 2 situations when this is a problem (and there are probably more), as I mentioned in my previous post:

1. A blind person is reading the book using a text-to-speech app. The app will treat the title as a regular paragraph because as far as it knows, it is a regular paragraph (it only understands semantic html, not css). This will have an effect on the way the text is presented and also navigation through the text.

2. You decide you don't like the way the book looks and turn off the original CSS styles (many reading apps let you do this): in this case, the semantically correct <h2 class="chapter"> will still be presented as titles (html with no css has default styles for h tags), whereas a <p class="chapter"> will just look like a plain paragraph (the same as plain text is displayed in a .txt file).

[JSWolf]

Originally Posted by Mister L

You might not know the difference as a human reader looking only at the rendered code. However the rendering engine knows the difference, and off the top of my head I can think of 2 situations when this is a problem (and there are probably more), as I mentioned in my previous post:

1. A blind person is reading the book using a text-to-speech app. The app will treat the title as a regular paragraph because as far as it knows, it is a regular paragraph (it only understands semantic html, not css). This will have an effect on the way the text is presented and also navigation through the text.

2. You decide you don't like the way the book looks and turn off the original CSS styles (many reading apps let you do this): in this case, the semantically correct <h2 class="chapter"> will still be presented as titles (html with no css has default styles for h tags), whereas a <p class="chapter"> will just look like a plain paragraph (the same as plain text is displayed in a .txt file).

1. What text-to-speech program reads chapter headers with an <h? differently then the same chapter header with a <p?

2. Why would you want to turn off the CSS? That's not a solution for anything. If I turned off or deleted the CSS, I get a basically unreadable eBook.

[DiapDealer]

Originally Posted by JSWolf

1. What text-to-speech program reads chapter headers with an <h? differently then the same chapter header with a <p?.

My guess would be just about all of them.

[Mister L]

Originally Posted by JSWolf

1. What text-to-speech program reads chapter headers with an <h? differently then the same chapter header with a <p?

Originally Posted by DiapDealer

My guess would be just about all of them.

Same, my guess would also be all of them worth mentioning.

Originally Posted by JSWolf

2. Why would you want to turn off the CSS? That's not a solution for anything. If I turned off or deleted the CSS, I get a basically unreadable eBook.

If an ebook is "basically unreadable" without the help of css, it means the person who made the ebook is doing html (very, very) wrong. CSS is purely for aesthetic styling, making it pretty. The underlying structure and semantic meaning (heading vs paragraph vs citation, emphasis...) should always be handled by the html.

Just as an experiment, take an epub with proper semantic html and delete / disactivate the css, and compare that to an epub without correctly structured text after deleting the css. Bear in mind that to all machines (for text-to-speech etc.), html with no semantic structure is more or less the same as trying to read a novel in .txt format, to a human.