How do I get rid of Table of Contents?

[DiapDealer]

Most EPUB2 reading systems can handle very simple (text-based, novel-like) EPUB3s with no trouble. But EPUB2 requires an NCX. So most people include a fallback NCX in their basic EPUB3s to ensure compatibility with most rendering engines.

Any EPUB3 rendering engine worth its salt will handle an EPUB3 without an NCX, though.

[Tex2002ans]

Originally Posted by bookman156

I wonder why EPUB3 should be such a tortuous process for a simple book. I'd probably find it easier if I had a complex book, there's the irony...

??? I don't know where you are coming up with all of this.

For your very specific case, a single-chapter book with no headings or anything...

All you have to do is:

1. Tools > Table of Contents > Edit Table of Contents.

2. Your "Edit Table Of Contents" page looks like this:

TOC Entry    | Target
_____________|_____________
Start        | Text/Section0001.xhtml

3. Double-Click in the 1st column, 1st row.

Change "Start" to whatever you want to appear in the TOC.

4. Double-Click in the 2nd column, 1st row.

Change the file to your very first chapter's filename:

• Text/Example.File.xhtml

Press OK.

Done.

- - -

As I explained before, things are much easier if you use actual headings (<h1>-><h6>) in your files:

<h1>Title of Article</h1>

<p>[... Begin your text here.]</p>

then all this TOC stuff can be auto-generated for you:

• Tools > Table of Contents > Generate Table of Contents

But with a single chapter, it's still simple even the "fully manual" way.

Side Note: And I'm having a hard time even imagining a book without a heading at all. (Your book has to have some sort of title, right?)

Originally Posted by DiapDealer

Most EPUB2 reading systems can handle very simple (text-based, novel-like) EPUB3s with no trouble. But EPUB2 requires an NCX. So most people include a fallback NCX in their basic EPUB3s to ensure compatibility with most rendering engines.

For your basic Fiction book, there won't be much difference between EPUB2 + EPUB3...

Most of these EPUB3-specific things come up when you're dealing with Non-Fiction and more complicated edge cases like:

• Footnotes
  
• Figures
  
• Captions
  
• Equations/Formulas (MathML)
  
• [...]

In bookman156's case, they don't have to worry about those.

(And there are still proper ways to handle these which works in EPUB2 AND EPUB3. There's not much reason to use the EPUB3-only way.)

Originally Posted by bookman156

I see Sigil has can generate an NCX for EPUB3, which I hadn't noticed. But is there a list anywhere of what readers/programs actually need NCX in EPUB3?

Many devices out there are not EPUB3.

Creating an NCX makes it fully compatible with EPUB2 devices, and in no way harms the EPUB3. There are no downsides to creating an NCX file.

The EPUB3 devices will read the nav.xhtml file.

The EPUB2 devices will read the toc.ncx file.

And like we keep on saying, simple, basic, Fiction books will work fine. You are imagining tons of complications where there is none.

Originally Posted by bookman156

Even the book EPUB 3 Best Practices, which I've just read finding nothing else on the subject, is ten years old.

Reality is, there's still a ton of EPUB2 devices out there.

EPUB3 books, if you design them properly, will be fully backwards compatible.

Imagine EPUB3 like EPUB2+enhancements.

(In Web Design, this philosophy is called "Progressive Enhancement".)

There are many things you can do in an EPUB3, which will work in more modern/newer devices:

• Marking footnotes as footnotes.
  
  • Popup footnotes.
    
• Using some CSS3.
  
  • Better typography, better hyphenation, etc.
    
  • Old-Style Figures or Proportional Numbers
    
  • OpenType Ligatures
    

If these enhancements aren't supported, it doesn't harm the book in any way, it just "won't look as pretty".

But you HAVE to keep in mind fallback code.

You cannot just throw compatibility to the wind by only focusing on the newest/latest-and-greatest/bleeding-edge programs/devices.

For example:

• What if your device doesn't support HTML5 <figure> or <figcaption>?
  
  • (Hint: EPUB2 devices won't understand that. Use <div>s instead.)
    
• What if you're renumbering footnotes using CSS3 counters?
  
  • Won't work on much, and definitely not on old devices.
    
  • (Use hardcoded numbers instead.)
    
• Fixed-Layout Books
  
  • Which only work on a small subset of devices and not across stores.
    
  • Very bad idea 99% of the time.
    

Side Note: Similar to the initial iPad. See many of the horror stories of Apple screwing those early users over. iBooks on iPad 1 ≠ iBooks on iPad 2+.

Also, see the garbage heaped out of InDesign which "works" and "look good" on the latest version of iBooks, but would completely fail if you tried opening that abysmal code on any other devices.

Or see the absolute pile of trash "EPUB"s coming out of Google Docs, which in no way would work on actual ereaders.

Originally Posted by bookman156

Even WOFF fonts are ignored in Kobo.

WOFF (and WOFF2) was invented long after EPUB3 came out. No older devices can support it.

Keep using OTF or TTF fonts. This ensures maximum compatibility.

See my posts in:

• 2019: "Font Best Practices"

Same with Variable Fonts. These things did not even exist when many of the devices came out, and they are barely even supported in newer OSes/programs.

Originally Posted by bookman156

How come Firefox and Chrome can use such things as font variant for small caps but for an EPUB I'll either have to ignore it or make a less good span class?

Use "font-variant: small-caps".

If the device supports it, great. If not, no big deal.

In most use-cases, the smallcaps are things that are decorative only (first word). Very rarely are they essential.

For some smallcaps discussion, see my posts in:

• 2019: "Replacing a single letter"

Originally Posted by bookman156

Forgive me for finding all this very strange. Why don't ereaders just use a vastly superior web browser engine, all we're paying for really is the e-ink screen.

... Power. Cost. Reliability. Scalability.

Why isn't everyone using my super duper bleeding edge NVIDIA GPU + 128-core machine + 64 GB or RAM in my $3000 computer?

How dare you use a low-powered, 8-year-old, cheap device with low RAM?

Why isn't everyone supporting the latest standard that just came out 2 seconds ago? (And is barely even supported across programs.)

Even in your favorite font world, there are about 4 competing OpenType implementations for "color in fonts". No single OS handles all of them. I described all of that in the "Variable Fonts" thread above.

Multiply that by every other issue under the sun... and the reality of making, producing, maintaining devices... is not as pretty as the theoretical.

Originally Posted by bookman156

I honestly wonder how someone finds out useful information like that and what it's ramifications are. I used to think designing for web browsers was a pain but that's improved considerably and they're free to test in. Here it seems one has no idea what the terrain is really like without asking a stack of pointed questions of people who've been looking at it for a long long time.

The renderer used on actual ereaders? See my post:

• 2019: "Epub-problems in tablets" (Post #27)

It pretty much just boils down to these main ones:

EPUB2 had 1 renderer:

• RMSDK (Adobe)
  
  • You could use an older version of Adobe Digital Editions 2.0 to "emulate" the older e-readers.

EPUB3 has 3 competing ones:

• Readium
• Nickel (Kobo)
• Webkit (iBooks)

That covers all the big devices/stores.

If you're selling EPUBs in actual storefronts, that's all you really need to test/care about.

- - -

Side Note: Then you have the piles and piles of non-standards-compliant crap "apps" out there (Moon+ Reader).

If you want to read more about that, see my posts in:

• 2020: "Colored Text, EPUB, Android Dark Mode"

- - -

If you wanted to see what specific HTML/CSS is supported on what devices...

EPUBTest.org used to have a lot info.

For more details, see the bottom of my post in:

• 2019: "Font Best Practices" (Post #4)

but like I warned, it doesn't matter if the latest bleeding edge font-/image-format is supported on the latest version of iBooks or whatever... 99% of the devices will not—and won't ever—support that, so it wouldn't be smart to use it in your ebooks.

Instead of designing an EPUB3-only book that can be "properly read" in 1% of the readers. Screw 99% of your actual customer base.

Better to settle into the lowest common denominator, with little EPUB3 enhancements on top.

This way EVERYONE can read the book fine. And that 1% on the bleeding edge? Well, they get nice little tweaks on top.

[DNSB]

Originally Posted by bookman156

I honestly wonder how someone finds out useful information like that and what it's ramifications are. I used to think designing for web browsers was a pain but that's improved considerably and they're free to test in. Here it seems one has no idea what the terrain is really like without asking a stack of pointed questions of people who've been looking at it for a long long time.

An epub2 ebook must have a NCX document. Period. End of discussion. It's part of the epub2 specification.

Just as an epub3 ebook must have a NAV document. It's part of the epub3 specification. An epub3 ebook can have a NCX document for backwards compatibility but it is not required.

Sigil can automagically generate a NCX from the NAV document for when epub2 compatibility is needed.

As for web browsers? My experience has been that most web browsers are designed to attempt to work around non-standard code found on too bleeping many web pages. Our corporate web pages are filled with code designed to attempt to allow our web pages to look half decent on Windows, MacOSX, Linus, iOS/iPadOS, various flavours of Android and the mass of different web browsers running on those OS that our web pages are viewed with.

[DNSB]

Originally Posted by Tex2002ans

Why isn't everyone using my super duper bleeding edge NVIDIA GPU + 128-core machine + 64 GB or RAM in my $3000 computer?

How did you manage to get a 128 core CPU from only $3000? Our 64 core, 128 thread Threadripper machines cost more than that just for the CPU (~$7200 Cdn). BTW, they also make great room heaters.

[Tex2002ans]

Originally Posted by DNSB

How did you manage to get a 128 core CPU from only $3000? Our 64 core, 128 thread Threadripper machines cost more than that just for the CPU (~$7200 Cdn). BTW, they also make great room heaters.

lol. I was just throwing out random numbers/pricing.

(In a few more years, those chips'll drop down in price though. )

Here I am stuck on my ONLY 4-core/8-thread Intel, getting jealous of all the latest bleeding edge benchmarks.

.... If only I could get a job like my man, Phoronix, constantly benchmarking and testing the latest stuff:

• AMD EPYC 7773X "Milan-X" Performance Continues To Impress With Tremendous Opportunity For Large-Cache Server CPUs
  
• AMD EPYC 7003 "Milan" Linux Benchmarks - Superb Performance
  
• Ampere Altra Max M128-30 Linux Performance Preview
  
• Windows vs. Linux Scaling Performance From 16 To 128 Threads With AMD Ryzen Threadripper 3990X

beautiful... beautiful...

- - -

And then I keep reading about the bleeding edge Linux stuff, and wonder when the heck that gloriousness will finally be trickling down to the normal humans.

Like:

• Linux Scheduler Build Improvements From "Fast Kernel Headers" Queued, FKH v3 Posted
  
  • Ingo Molnar touching pretty much every single Linux file lowering build times by >80%... by simply getting rid of tons of complicated dependencies.
    
• Latest Linux Code Smashes 14M IOPS Per-Core With Intel Core i9 12900K + Optane
  
  • Jens Axboe (and others) rewriting and optimizing I/O to push godly amounts per core... going from ~2 million to ~15+ million iops within the past year.
    

- - -

Side Note: Kind of feels like me following the bleeding edge of LibreOffice.

The past ~12 months, I've been helping answer questions + write mini-tutorials on the subreddit. (Spreading the good word on Styles, converting lots of people!)

I've gotten sucked into QA + submitting bug reports (6 of my bugs have already been fixed within the past few months).

I'm constantly updating to the latest versions as they come out.

And then you run across the reality of "the public"... where many people are:

• running ANCIENT versions of LibreOffice
  
  • ~50% of downloads, millions of people, are still getting 10-year-old OpenOffice!!!
    
  • It's only been within the last few years where LibreOffice numbers have finally surpassed OpenOffice.
• getting crashes and bugs that have already been fixed years ago
  
• missing out on tons of great functionality
  
• [...]

bookman156's mind is going to be blown... WEBP images are just now getting support in:

• Microsoft Office (August 2021)
  
• + LibreOffice (7.4) (coming out in August)

And these are BLEEDING EDGE office programs.

Want to guess how many people aren't using these latest-and-greatest versions? Tons.

Want to guess how smart it is to use WEBP in ebooks, even though it's "now supported in EPUB3" (as of November 2019)? Very dumb.

(Firefox just got WEBP support in January 2019.)

Now Google is trying to work towards WEBP2...

AV1 + AVIF are just gaining adoption (hardware encoding/decoding making it into this year's flagship smartphone chips)... and you want to be shoving AVIFs into static e-readers from before these formats even existed? lol.

Reality is, you convert the images to JPG / PNG, and shove them in your ebook—this would work across 100% of all devices, not <1% that supports WEBP.

[JSWolf]

In order to make sure your ePub 3 eBook works well enough with ePub 2, I suggest you download and install Adobe Digital Editions 2.0.1 and use that to test your eBook.

You can get ADE 2.0.1 for Windows or MAC (32-bit) here. Adobe took down the page, but The Wayback Machine still has it.
https://web.archive.org/web/20200619...downloads.html

[bookman156]

It's here: https://archive.org/details/ade-2.0.1

Is ADE 2.0.1 the last one that was purely EPUB2? I have ADE 4.5 installed currently on my old PC.

[bookman156]

As for web browsers? My experience has been that most web browsers are designed to attempt to work around non-standard code found on too bleeping many web pages.

In the distant past, maybe, but these days they work well with quite a range of valid code.

https://caniuse.com/

[bookman156]

Use "font-variant: small-caps".

If the device supports it, great. If not, no big deal.

In most use-cases, the smallcaps are things that are decorative only (first word). Very rarely are they essential.

It depends. For some thing like '7am' the 'am' would be better as small caps, but it doesn't matter too much if not. But for historical works littered with BC/AD and BCE/CE then small caps I would say are essential. Some might regard it as a nicety, but obviously 'bc/ad' are going to be a bad fallback, so you'd either be forced to use full caps, which can dominate a page far too much, or a span class and smaller font size.

[bookman156]

WOFF (and WOFF2) was invented long after EPUB3 came out. No older devices can support it.

WOFF has been around for quite a while but if not supported in devices it doesn't matter since the only reason to use it on the web is quicker loading of embedded fonts to avoid the flash of unstyled content. Doesn't matter to make a slightly smaller EPUB.

OTF is fine for me now I know that WOFF is poorly supported. I simply assumed ereaders were better than they are after all these years, which I won't do again. But certainly readers like BibiReader and even Sigil itself support WOFF, which led me astray.

[Hitch]

Originally Posted by bookman156

It depends. For some thing like '7am' the 'am' would be better as small caps, but it doesn't matter too much if not. But for historical works littered with BC/AD and BCE/CE then small caps I would say are essential. Some might regard it as a nicety, but obviously 'bc/ad' are going to be a bad fallback, so you'd either be forced to use full caps, which can dominate a page far too much, or a span class and smaller font size.

That's all well and good, IF IF IF you can embed a smallcaps font. Hell, if one even exists for the font in question. eReaders don't create the fonts on the fly; the font (the specific font within the typeface) must be embedded into the file being read. Thus, you can "write" smallcap coding from now until hell freezes over, but if the font (e.g., Adobe Caslon SmallCaps) is not toted along with the ePUB, the face will not display.

AND, that only works if a) the device supports font embedding and b) the user remembers to turn ON publisher fonts. (And on Paperwhites, a shockingly high number of users seem to think that "publisher fonts" is some sort of highly-contagious device STD that is ne'er to be turned on....)

Oh and let's not forget what happens with the user changes fonts--say, to Helvetica. Or Bookerly, or...whatever, a typeface that doesn't even have smallcaps. Oooops....

The other alternative is that you create faux small-caps--the dreaded all-caps at 80% of the like.

Honestly, talk about hot buttons. Don't get me started about SMALLCAPS, of all the cursed things. I love grand lovely book design as much as the next guy, but...eBooks, and the vast alternative universes between various and sundry eBook readers and software...that's a whole other dimension.

Hitch

[JSWolf]

Speaking of smallcaps. I am not a fan of them to start the chapters/section break.

If you use a font that has small caps in it and the program that's displaying the eBook supports font-variant: small-caps; then all is good as the small caps will look good and not simulated.

But most books don't use small caps too much so simulated is easy enough to ignore. As to the size, I use 0.8333em. I don't know if that's the correct size or not, but it looks good enough to me.

[bookman156]

That's all well and good, IF IF IF you can embed a smallcaps font.

That's why I was saying that the publisher is forced to ignore proper smallcaps and to either use full caps or use a smaller font size as a pseudo smallcaps span class.

I have done a book with such smallcaps for BCE/CE and though it doesn't satisfy the typographer in me it is better than having full caps.

[bookman156]

on Paperwhites, a shockingly high number of users seem to think that "publisher fonts" is some sort of highly-contagious device STD that is ne'er to be turned on....

I have a Paperwhite and I have never seen 'Publisher Font' in the list, probably too old a device. But it occurs to me if I haven't seen it a number of times, because there simply wasn't one, you just stop looking.

[JSWolf]

Originally Posted by bookman156

I have a Paperwhite and I have never seen 'Publisher Font' in the list, probably too old a device. But it occurs to me if I haven't seen it a number of times, because there simply wasn't one, you just stop looking.

Publisher Font only is selectable if the eBook you are viewing has at least one embedded font.