Quote:
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:
Code:
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:
Press OK.
Done.
- - -
As I explained before, things are much easier if you use actual headings (<h1>-><h6>) in your files:
Code:
<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?)
Quote:
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.)
Quote:
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.
Quote:
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.
- Using some CSS3.
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
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.
Quote:
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:
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.
Quote:
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:
Quote:
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.
Quote:
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:
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:
- - -
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:
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.
