Google Play Books and Nested Lists - Some Weird Display Issue

[Hitch]

Originally Posted by rsuchwani

I've explained everything to the Author, but the Author wants to sail the waters on his own terms.



I've extensively tested MicroDrie's solution in a number of ways and on different devices it works really well except on Tolino (vision 5). This device doesn't acknowledge the indents at all. For reference, I'm including the link to the screenshots and the ePub file.

Screenshots

ePub

Exported PDF

With all due respect, all of these, except the iPad, are apps, not devices, are they not? Tolino, Reasily...they're all apps, which means that most of them are actually web-based or browser-based, which means, yes, they'll work. ???? And the iPad is actually just an app that's based on a specific TABLET device--not a real, dedicated Reader, either, and which has a larger set of working "outside the eBook box" HTML, too.

Never mind. I officially give up now.

Hitch

[rsuchwani]

Originally Posted by Hitch

With all due respect, all of these, except the iPad, are apps, not devices, are they not? Tolino, Reasily...they're all apps, which means that most of them are actually web-based or browser-based, which means, yes, they'll work. ???? And the iPad is actually just an app that's based on a specific TABLET device--not a real, dedicated Reader, either, and which has a larger set of working "outside the eBook box" HTML, too.

Never mind. I officially give up now.

Hitch

Hitch,

I'm grateful that you've taken out time to respond to my question from early on and provided me with the years worth of insights, but so far only MicroDrie has 'actually' thought of finding the solution to remedy my issue.

And may be the current suggested solution only work on 'apps' not on 'actual' devices but I only have access to those mentioned apps/device so my test ranges to only those.

But since you have access to almost all the devices given that you run the eBook conversion company, will you be able to actually test the ePub on devices and find out whether the solution works or not?

[Quoth]

You are focusing on the wrong problem and losing sight of the big picture. And the Elephant.

[Hitch]

Originally Posted by rsuchwani

Hitch,

I'm grateful that you've taken out time to respond to my question from early on and provided me with the years worth of insights, but so far only MicroDrie has 'actually' thought of finding the solution to remedy my issue.

And may be the current suggested solution only work on 'apps' not on 'actual' devices but I only have access to those mentioned apps/device so my test ranges to only those.

But since you have access to almost all the devices given that you run the eBook conversion company, will you be able to actually test the ePub on devices and find out whether the solution works or not?

Yes, MicroDrie mucked around and found a "solution" that works--on browsers and software readers. The reason that the rest of the schmucks here didn't even try it is because we KNOW that tables are murky at best, in ebook readers and that when they carry over multiple screens, as yours do, you are courting Mephistopheles. And here's the real kick in the ass--even if they work when sideloaded, you just can't be sure what the processing might do, once the book is live. (To wit, the problem of using embedded spans, on Nooks. Worked fine when sideloaded and puked and kablooie'd in the real, post-processing devices.)

You surely know exactly what you're asking; sideloading this to every device in my stable would not be quick.

Perhaps some of the other denizens of the deep here might step up, with their hard devices, too, and spare me some aggro? Since I have not one but TWO employees sidelined by Ida?

And lastly--customer and client education is part of what we are required to do. SOMETIMES, you just have to tell a client that what they want is NOT DOABLE or that if you do, the fix may be worse than the illness. This, imho, is one of those times.

Hitch

[Tex2002ans]

Originally Posted by Hitch

The reason that the rest of the schmucks here didn't even try it is because we KNOW that tables are murky at best, in ebook readers and that when they carry over multiple screens, as yours do, you are courting Mephistopheles.

Yes, exactly. Tables with cells with lots of text are horribly broken on many devices/readers.

And then imagine someone reading on a cellphone + a much larger font, you can easily overload it with a larger-than-screen cell. On many devices, poof, that text is now inaccessible because next page will be the next cell.

Not to mention Text-to-Speech issues. (Information in <table>s that aren't actually tables!)

Originally Posted by Hitch

And lastly--customer and client education is part of what we are required to do. SOMETIMES, you just have to tell a client that what they want is NOT DOABLE or that if you do, the fix may be worse than the illness. This, imho, is one of those times.

Similar to relying on CSS3 content. Heck, you can't even rely on start or list-style either.

It's one of the reasons why, sadly, instead of relying <ul> + <ol>... we tend to "hardcode" the lists.

Instead of:

<ol>
	<li>One</li>
	<li>Two</li>
	<li>Three</li>
</ol>

we recommend the hardcoded numbers:

<div class="ol">
	<p class="list">1. One</p>
	<p class="list">2. Two</p>
	<p class="list">3. Three</p>
</div>

The hardcoded list of numbers will never go wrong. Where <ol> can go wrong, especially if you:

• rely on start
  
  • Starting at 100.
    
  • Counting by 2.
    
    • 1, 3, 5, 7
  • Skipping a number.
    
    • 1, 2, 5
• Use more complicated anything-but-default numbering
  
  • Roman numerals = i, ii, iii
    
  • Greek Letters = α, β, γ
    
  • Old Hungarian*
    
  • (a)
    
  • [a]
    
  • a)
    
  • 1.1
    

Same with <ul>, there were many bugs across devices, so a:

<ul>
	<li>Item 1</li>
	<li>Item 2</li>
	<li>Item 3</li>
</ul>

we recommend the hardcoded:

<div class="ul">
	<p class="list">• Item 1</p>
	<p class="list">• Item 2</p>
	<p class="list">• Item 3</p>
</div>

When you have extremely basic lists, you'll still probably be fine with using <ol> or <ul>.

But once you start reaching more complicated cases, such as:

• deeply nested lists
• different-than-default bullets

then you start reaching the EPUB reader bugs.

This is where hardcoding lists would win out.

- - - - -

Side Note: Lists in EPUB are, sadly, one of the few cases where I go for less Accessibility + much uglier (and harder to maintain) code.

... But then you get maximum compatibility across real-world devices.

* Note: Old Hungarian, was an RTL runic language. Fascinating stuff. I only learned about it since LibreOffice recently added it for Lists + Page Numbering + Transliteration.

[rsuchwani]

Guys,

I'm really very thankful for all the guidance, tips, suggestions, and advice that you've given to me regarding the matter I was facing.

For now, this particular issue with Google Play Books has taken the backseat and the author/client is more focused on the marketing phase.

Once again, I'm really really grateful for being a part of this fantastic community.

Thank you all.