Google Play Books and Nested Lists - Some Weird Display Issue

[rsuchwani]

Originally Posted by Doitsu

You're mistaken. Apple Books (iBooks) supports both reflowable books and fixed-layout books.
Moreover, the OP stated that he encountered problems with Google Play Books.

You are right.

[MicroDrie]

Originally Posted by rsuchwani

How did you come up with this reasoning? And when did I ever say that my book is FXL and only for iBooks? The ePub (samples attached in my previous posts) is in reflowable format and can be read on any number of devices/reading systems.

You have indeed not mentioned the Layout format until now. The error behavior shown looked like a Fix Layout throwing characters away.

I use the GitDen EPUB reader because of my good experience for HTML, CSS, JavaScript and Video support. What versions 2 and 3 of your EPUB example share is that my GitDen app quits every time. I've experienced that before while testing "What Can't and What Can Do" in an EPUB.

I don't feel the need to say anything to the already given value judgment of the CSS file given by others. Certainly in an EPUB reader environment where a minimal implementation of the EPUB standard is unfortunately more the rule than the exception, I would rather opt for a "Less is more beauty" approach.

[rsuchwani]

Originally Posted by MicroDrie

I use the GitDen EPUB reader because of my good experience for HTML, CSS, JavaScript and Video support. What versions 2 and 3 of your EPUB example share is that my GitDen app quits every time. I've experienced that before while testing "What Can't and What Can Do" in an EPUB.

I don't know why the app on your phone is behaving like that, but it just works fine on my phone. See the screen record.

Spoiler:

https://drive.google.com/file/d/18CR...ew?usp=sharing

Originally Posted by MicroDrie

I don't feel the need to say anything to the already given value judgment of the CSS file given by others. Certainly in an EPUB reader environment where a minimal implementation of the EPUB standard is unfortunately more the rule than the exception, I would rather opt for a "Less is more beauty" approach.

The beauty doesn't need to be 'less' than needed. I've already mentioned that the book in question isn't your typical fiction, simple eBook with minimum and generic stylesheet. The book is a highly stylized and complex eBook that needs this stylesheet.

Anyway, thanks again for your time.

[DNSB]

Originally Posted by rsuchwani

David,

The Glyphs displays fine because I've used the Unicode characters as the list markers, very few 'fonts' don't display them. Even I remedied it by subsetting the font (that has almost all the used glyphs) and embedding it in the ePub, but that didn't resolve my issue. Please observe the attached Test ePub V03 above.

Thanks.

It doesn't matter how you refer to the glyph. If the font(s) being used to display the glyph do not have the glyph defined, it won't work. Depending on the device you are reading on and the renderer used, some will attempt to locate the glyph in all available fonts while others will use the font(s) defined in the epub.

edit: I ran your epub through epubcheck which had no issues with it. OTOH, validating your stylesheet through the W3C checker came up with multiple errors. Some of them I would disregard but there were several that caused issues on my ereaders.

1 		This profile has a very specific syntax for @charset: @charset followed by exactly one space, followed by the name of the encoding in quotes, followed immediately by a semicolon. @charset "UTF-8";
37 		Parse Error [epub|type~="toc"] ol]
41 		Parse Error [epub|type~="landmarks"]]
41 		Parse Error [epub|type~="page-list"]]

[rsuchwani]

Originally Posted by DNSB

It doesn't matter how you refer to the glyph. If the font(s) being used to display the glyph do not have the glyph defined, it won't work. Depending on the device you are reading on and the renderer used, some will attempt to locate the glyph in all available fonts while others will use the font(s) defined in the epub.

edit: I ran your epub through epubcheck which had no issues with it. OTOH, validating your stylesheet through the W3C checker came up with multiple errors. Some of them I would disregard but there were several that caused issues on my ereaders.

1 		This profile has a very specific syntax for @charset: @charset followed by exactly one space, followed by the name of the encoding in quotes, followed immediately by a semicolon. @charset "UTF-8";
37 		Parse Error [epub|type~="toc"] ol]
41 		Parse Error [epub|type~="landmarks"]]
41 		Parse Error [epub|type~="page-list"]]

Based on your thoughts/findings, I've minimalized the CSS focusing only on the selectors/styles for a single page. But the problem persists, orphan/hanging empty list markers on the following page in the content of the nested lists.

I'm attaching the ePub for your review if you (or anybody else) have time for it.

Thanks.

[MicroDrie]

Originally Posted by rsuchwani

But the problem persists, orphan/hanging empty list markers on the following page in the content of the nested lists.

I wrote before that solving all problems at once is not going to work.

Let's first look if the orphan and windows behavior has something to do with print media setting.

For the screen media display, you specify the body an orphan and window value of 2 lines. No orphan and window value for print media is specified.

@media print {
  body {
    widows: 2;
    orphans: 2;
  }
}

What is the influence if a window and orphan setting is also defined for the print media?

[Quoth]

2 is default usually if nothing is set, though it may depend on App or brand of ereader.

Does @media print etc even work at all on all ereaders (or only some) or does any change of windows or orphans from 2 need set in other classes that are in the HTML for various styles in use?

[MicroDrie]

Originally Posted by Quoth

Does @media print etc even work at all on all ereaders (or only some) or does any change of windows or orphans from 2 need set in other classes that are in the HTML for various styles in use?

Unfortunately, no one knows which E-reader supports which CSS commands. That makes it all very difficult to make EPUB that can do something more than bold, italic and underlined text.

I actually suspect that when loading the EPUB via a kind of print flow. This flow converts the reflowable EPUB to a (form of) fix-page layout. I'm basing that on the PDF in this post, showing the page numbers.

If it turns out that splitting over several pages after recording the @media print has an effect, that doesn't say anything about the support on an EPUB reader when the uploaded file is downloaded to the E-Reader. That's something we should test in the next test step

[rsuchwani]

Originally Posted by MicroDrie

I wrote before that solving all problems at once is not going to work.

Let's first look if the orphan and windows behavior has something to do with print media setting.

For the screen media display, you specify the body an orphan and window value of 2 lines. No orphan and window value for print media is specified.

@media print {
  body {
    widows: 2;
    orphans: 2;
  }
}

What is the influence if a window and orphan setting is also defined for the print media?

As I understand (or AFAIK) widows/orphans only impact the length of the paragraph, the settings, whichever may be, don't impact the list items.

My CSS has this now

body {
  font-family: 'Literata';
  font-size: 100%;
  font-weight: normal;
  text-align: justify;
  line-height: 1.35;
  margin: 0;
  padding: 0;
  -webkit-hyphens: none;
  hyphens: none;
  widows: 1;
  orphans: 1;
}

@media print {
  body {
    widows: 1;
    orphans: 1;
  }
}

But it doesn't change a thing, multilevel list or nested list's first level's marker still hanging at the top of the page without any content.

[Hitch]

Originally Posted by MicroDrie

Unfortunately, no one knows which E-reader supports which CSS commands. That makes it all very difficult to make EPUB that can do something more than bold, italic and underlined text.

I actually suspect that when loading the EPUB via a kind of print flow. This flow converts the reflowable EPUB to a (form of) fix-page layout. I'm basing that on the PDF in this post, showing the page numbers.

And, now we are all off in fairyland. A "kind of" fixed-page layout? How's that working and what are its rendering choices?

If it turns out that splitting over several pages after recording the @media print has an effect, that doesn't say anything about the support on an EPUB reader when the uploaded file is downloaded to the E-Reader. That's something we should test in the next test step

AFAIK, @media print does bupkus on real devices, but perhaps folks here have actually seen it work on one?

Hitch

[Quoth]

Originally Posted by MicroDrie

Unfortunately, no one knows which E-reader supports which CSS commands. That makes it all very difficult to make EPUB that can do something more than bold, italic and underlined text.

Not really true.

Below tested in LO Writer using and EXTRA save As in docx, but edit as ODT.
Paragraph Styles in Wordprocessor Docx (From Word or LO Writer) created as css by Calibre that work on nearly anything, even mostly KF7/Mobi:
Paragraph top margin
Paragraph bottom margin
Left indent
Right indent
First line indent. You can copy the regular paragraph style and have 2nd style with this as zero for after anything centred.
Left, centred, right or fully justified: Centred is good for headings, right for marginalia and Left for poems / lyrics
Font size, normal, bold, italic and bold+ italic.
A box and text spaced in it (one paragraph, but Newline via Shift Enter works). Line width works. Surprised me
Underline works. But only have it automatically for links
Colours / shades work, but madness.
Use Level1, Level2 for headings in TOC/NCX. Use text level for all other headings as more than two levels may not work. Becomes H1, H2 in CSS/HTML.
Use Page Break before in any paragraph style that needs to start on a new page. Might only work with H1 and H2 in mobi.
Images can be centred, left or right. Best as a separate paragraph and embedded as a character. Relative width is possible. Avoid big.
Line height works, but is a bad idea, especially for the main content / body


Things that are problems:
Choosing your own fonts works on KF8 and epub2 on ereaders that support "Publisher font". You need to embed and subset in Calibre Conversion and you may need to select Embed Fonts in wordprocessor properties, especially if a different computer is used for Calibre. Mobi-KF7 will support monospace (Courier), sans-serif and serif on a good day depending on your WP choices. But if you upload epub2 to Amazon, the resultant download in mobi-KF7 for ancient eink should be doing monospace (Courier), sans-serif and serif if the epub2 CSS makes sense. But there is NO assurance that the user will select Publisher font. Test on a Kindle (KF8) and Kobo epub2 (Not kepub) that NOT using the publisher font is still readable.

Footnote support is erratic and they are evil to edit in WP as a note can vanish if you delete the reference.
Simulate footnotes with link to anchor of the note and an anchor at source and link back. Put them either in an intermediate chapter at the end of a chapter or all at the end in an appendix chapter.

Flowing text around and image only works on some ereaders and formats. A small image in a line won't resize when people change the font size so should be avoided.
Small caps might not work.
Drop caps can be images with flowed text or "real" drop caps. The images and the font versions are quite likely to sit up on the base line on many formats and models and apps. Avoid. It's a publisher ego thing that slows people reading. Users won't miss them.

Animated images, video, sound or interactive works on hardly anything. Only a handful of epub3 apps. Better to write an app.

You can't fill in forms on most things.

Right to Left and Vertical languages may not work.

[Quoth]

Really bad Android ePub apps might ignore CSS. Lithium, Aldiko Classic and KOReader are OK, but the user can overide almost anything with KOreader.

[Quoth]

But Hitch and Tex are the gurus on this stuff.
I'm lazy so I only edit the CSS & HTML (as little as possible) of the PD books and sometimes books I buy. I only edit the LO Writer "odt", Save As docx and convert to epub2 in Calibre for our own. Any new LO style is tested on the real ereaders and Apps and if not "good", the LO style is edited, not the CSS/HTML.

New styles are now rare.

[Hitch]

Originally Posted by Quoth

But Hitch and Tex are the gurus on this stuff.
I'm lazy so I only edit the CSS & HTML (as little as possible) of the PD books and sometimes books I buy. I only edit the LO Writer "odt", Save As docx and convert to epub2 in Calibre for our own. Any new LO style is tested on the real ereaders and Apps and if not "good", the LO style is edited, not the CSS/HTML.

New styles are now rare.

No, actually, Tex is the guru. I'm just a business owner with a decade-plus in this "stuff." Tex gets down in the guts; I just happen to know this "stuff" because my business runs into it daily or even more often than that. :-)

And I have customers that want this or that, b/c it's like that in their print book, so I end up involved in it and learn that we can't do this, or we can do that.

Tex is the real guru. I'm...along for the ride. :-)

Hitch

[RbnJrg]

Originally Posted by Quoth

Really bad Android ePub apps might ignore CSS. Lithium, Aldiko Classic and KOReader are OK, but the user can overide almost anything with KOreader.

The best ereader apps (regarding as how they display an epub) are:

1) Reasily
2) Gitden
3) PocketBook
4) Lithium
5) Overdrive

The difference between 1-3 are tiny; I use mainly PocketBook because it has features not present in Reasily or Gitden (for example, Reasily doesn't have TTS nor hyphens). But the support for css3 in ereaders 1-3 is very good (to my surprise, they even support calc and custom variables).