Ebook Reader Fury

[jackie_w]

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 Mister L

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

Which programs/apps are you referring to with "all of them worth mentioning"?

I've been using TTS on Windows and Android for several years. As far as I can tell none of the TTS progs/apps pay any attention to which tags are used (<h1-6>, <em>, <i> etc) in the epub HTML.

What little "context intelligence" does exist in TTS seems to me to be dependent on the Voice you use to do the speaking and I'm not aware that any of the Voices I've used changed depending on HTML tag.

If you know different, I'm all ears, because I find the lack of progress over the last decade in TTS for Joe Public's own ebooks to be depressing. Too much money to be made selling Audible subscriptions using real voice artistes.

Originally Posted by Mister L

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.

I see no evidence that your average TTS app for ebooks doesn't do exactly that, i.e. convert to txt before speaking.

[stumped]

Originally Posted by d351r3d

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.

It is unfair to blame apps, that many thousands of users like, just because you do not like how they render one (probably badly coded) e book. Try writing your own. See if you can do better

moon reader has thousands and thousands of 5 star reviews. Are all those customers idiots, or do they perchance use reputable better quality book sources?

[jackie_w]

Originally Posted by stumped

moon reader has thousands and thousands of 5 star reviews. Are all those customers idiots, or do they perchance use reputable better quality book sources?

The longer you spend reading the hyperbolic, moronic rantings that pass for Android app reviews, the harder it is to answer the question "Are all those customers idiots?"

[JSWolf]

Originally Posted by Mister L

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.

I did your experiment and I was correct. Removing the CSS makes it unreadable. Why would you want to remove the CSS anyway?

[stumped]

Originally Posted by jackie_w

The longer you spend reading the hyperbolic, moronic rantings that pass for Android app reviews, the harder it is to answer the question "Are all those customers idiots?"

well ok but lets be statistical . Checking google play Uk ( which is probably only a small part of overall sales) - over 97,000 people have reviewed moon reader pro, the overwhelming majority gave it 5 stars.
even if a generous 10% of those reviewers are nutters who need to go get a life, that's a solid base. If i had a product that 90K people liked enough to leave a +ve review , I'd be quite happy.

to say that the app author "does not care" because of how the app renders some probably bad source code of a book is really unfair. To extend that to all authors of all apps do not care leaves me , well "uncaring" about this guys opinion
perhaps he should just memorise his Quran in the traditional manner , then he'd not have to endure looking at the bad electronic presentation

[DiapDealer]

Originally Posted by jackie_w

I've been using TTS on Windows and Android for several years. As far as I can tell none of the TTS progs/apps pay any attention to which tags are used (<h1-6>, <em>, <i> etc) in the epub HTML.

You're sure? There's not a longer pause after an h tag chapter-title is read before beginning the first paragraph of the chapter? And if there is... how does it know to pause longer if it's not the tag being used?

I would expect the pause between p -> p tags to be much shorter than the pause between h3 -> p tags.

Hence, I would suspect that chapter titles created with styled p tags would tend to be blurred together a bit more with the first paragraph of a chapter than a chapter with a semantically correct h-tag title would be.

[DiapDealer]

Originally Posted by stumped

moon reader has thousands and thousands of 5 star reviews. Are all those customers idiots, or do they perchance use reputable better quality book sources?

I think you're missing the point a bit. It's quite possible for an app that's fantastic for readers to be simultaneously awful for creators that are striving to create a particular look.

So no, I don't think Moon Reader's customers are idiots. I think they just care more about how they want their ebook to look, and less about how the author/publisher wants it to look. That may be as it should be in this electronic day and age, but it still doesn't change the fact that Moon Reader probably shouldn't be used by content creators to see how their code/css is going being rendered by reading apps.

My beef with Moon has always been that it fails to even attempt to show me an ebook in the way its creator wanted me to see it. Doesn't make it a bad app. Nor does it make me an idiot for wishing it did have a better "publisher mode." Just makes it the wrong app for me and some others.

And his statement was technically correct in the first place. Moon Reader doesn't care how he wanted it to look. It cares about how its users want it to look. So it's not really "blame" per se, as much as it is acknowledgement. "Apps gonna do what apps gonna do. I can't change that."

It's OK for people to criticize your favorite Android reading app. Everybody has different needs.

[stumped]

i thought publisher mode was as the name implies. though TBF, not many books are published for 5 inch phones - which were the original target device market for moon ?

For creators who demand a particular authentic look, as specified by their god of choice, there is PDF, papyrus scrolls, or Stone Tablets.

( moon includes a quite convincing marble tablet background theme )

[jackie_w]

Originally Posted by DiapDealer

You're sure? There's not a longer pause after an h tag chapter-title is read before beginning the first paragraph of the chapter? And if there is... how does it know to pause longer if it's not the tag being used?

It's not noticeable to me but YMMV. I cannot personally detect any pause difference if the difference is measured in milliseconds. I don't have any problems with any of the apps I've used when they speak headings, <p> or <h?>.

My original point is more relevant when trying to detect a voice difference when text is wrapped in <i>, <em>, <b>, <strong> tags. I can't hear any difference. Perhaps this comment would have been better suited to that other recent thread discussing the merits of if/when you should use <em> rather than <i>, <strong> rather than <b>.

I don't test every TTS app with every voice every week. It's quite possible some apps have greatly improved their capabilities. In which case I'd love to hear about them. TTS is important to me and I'd like to use the 'best' available on Android.

[DiapDealer]

Originally Posted by stumped

i thought publisher mode was as the name implies. though TBF, not many books are published for 5 inch phones - which were the original target device market for moon ?

In my opinion, Moon's publisher mode has never been that great at rendering things how other commercial epub reading apps tend to render them. Plus Moon's Publisher Mode is considered a "preview." One which you have to search to find the option that allows the Publisher Preview button to even be shown on the title bar so you can click it.

Look, I'm sure it works wonderfully for many. But for me, it takes way too many liberties with formatting and overrides right out of the gate. I have no problem with giving users the option to override anything and everything. I have a problem with everything already being overriden just by installing the app. It's a huge chore just for me to find my way back to "normal" from the installation defaults. I just want to be able to read my purchases close to the way they were published. And I want to be able to do so by default.

Standard css first-line paragraph indents being disabled/overriden by default?? What sort of nonsense is that? Why would I have to "turn on" something that the book's css already had turned on? That's bass-ackwards to me.

I prefer an app that allows me to take the time to figure out how to "blow up" anything and everything I want to blow up in an ebook; not one that blows everything up from the get-go, and makes me figure out how to put most of it back together again.

Moon Reader+ seems great for those who have a vested interest in every ebook they open being presented in a very similar, very curated, very personal way. I'm happy for them. I'm just not one of those users. I'm OK with different books looking different. In fact, I like it. I don't want them all homogenized.

[JSWolf]

Why is it that most ePub reading programs for Android have no idea what CSS is?

[DiapDealer]

Originally Posted by JSWolf

Why is it that most ePub reading programs for Android have no idea what CSS is?

They know perfectly well what CSS is. They're just often injecting their own css instead of what comes with the book. It's a conscious design choice. Not an error, or a lack of understanding about css. They simply can't honor the publisher's css AND give Android users all the customization options they're accustomed to having.

[JSWolf]

Originally Posted by DiapDealer

They know perfectly well what CSS is. They're just often injecting their own css instead of what comes with the book. It's a conscious design choice. Not an error, or a lack of understanding about css. They simply can't honor the publisher's css AND give Android users all the customization options they're accustomed to having.

The way to do it (IMHO) is to have an off setting for each customization. That way you can either go with the CSS or customize for each setting.

Do these Android programs respect embedded font?

[DiapDealer]

Originally Posted by JSWolf

Do these Android programs respect embedded font?

No clue. I don't really use them any more. I check them out from time to time to see what may have changed, but then I'm usually right back to using the app connected to the store I bought the ebook from to read it: the Kindle app for kindle formats, and the Kobo and Google reading apps for epubs.

I'm not the obsessive shifter/tweaker/formatter/DeDRMer I used to be. I'm fairly "Buy with the app; Download with the app; Read with the app" these days.

[jackie_w]

Originally Posted by JSWolf

Do these Android programs respect embedded font?

You've said in the past that you've never used an Android reader app so I'm not sure why you're worried about it.

However, in answer to your question - they vary. The ones based on the Adobe or Webkit rendering engines are good enough for me. The ones based on the CoolReader engine not so much. The latter are the ones which seem to prioritise user CSS overrides over book's own CSS.

It's a bit like the variety in eink devices, though. It can depend on how the HTML tags controlling the embedded font have been set up. Applying the embedded font to a <span> may have a better chance of surviving than applying to a <p> or <div> if a user has also enabled a 'Customise font' option for the main body text.