How do I get rid of Table of Contents?

[Hitch]

Originally Posted by JSWolf

In your professional opinion, do more people prefer justified or left justified eBooks?

Well, I can only go by what I see and hear--which are the largely unvarnished opinions of our 5,000+ customers, over now 7K+ eBooks, and there appears to be a pretty overwhelming demand for justification. Far larger than a 50/50% split. If we don't use it and they sideload to something like Moon+Reader, we hear about it. If we do use it, 98% of the time, they never complain but if we don't specify it, we certainly do.

Originally Posted by bookman156

Just to be clear, I would prefer justified ebooks if it could be done satisfactorily. As it can't, I prefer unjustified.

Yes--but it's literally impossible to do. There is no way, short of an infinite number of monkeys writing an infinite number of algorithms, live in little coding rooms, inside the magic device, to make that work. You can never--never--know, how many characters will be allowed on a given line. You can't know what those characters will be, or what font size--or what orientation the line will be viewed using--portrait or landscape? You don't know if you'll have runts, or widows, or orphans. It's a Dr. Strange-ness Multiverse of results out there. If you can't see the line, you can't kern it. You can't track a paragraph, to screw out a runt, because--you don't know it's going to be there.

About all you can do is pray a lot that you use a font with a solid kerning table and that the algorithms do the best that they can with it; that you get a device that does have hyphenation, so that you're not stuck with rivers (and before you say it, trust me, you can and do get rivers with unjustified text in the wild, anyway, no matter how nutty that sounds), and sit back and wait. If there are problems with the book, oh, you'll hear about it.

If there aren't, then you've done your job and you can go home happy. Personally, as I mentioned previously, we do not align our texts, other than right-aligned headings and the like. We allow the buyers--the people spending the money--to choose what they want.

It is, after all, their money.

Hitch

[bookman156]

Personally, I think an EPUB is closer to a webpage than a book, and essentially a book by virtue of length and there being an actual printed book of which this is a useful digital version. There is not this fuss over justifying webpages. Some try it, but it usually looks mannered. Unjustified is more natural and also suits responsive design. I like ebooks because the blind are getting, at least, as good as you try to do, and justification means nothing to them. I might not bother otherwise.

Yes, I know unjustified text can have rivers, but I don't regard rivers as terrible. They can actually be quite charming. What is terrible is lines not stretching all the way across in so-called justified text. That is just not good enough.

People only 'insist' on justified because it's been foist upon them as default and because they're thinking in terms of books rather than webpages. And also because they have little developed aesthetic sense in typography.

[phillipgessert]

All well and good, but how does it factor in to using that idea to try and override someone’s chosen preference? Giving someone what they don’t want is an atypical design philosophy. Especially for books.

[bookman156]

All well and good, but how does it factor in to using that idea to try and override someone’s chosen preference? Giving someone what they don’t want is an atypical design philosophy. Especially for books.

I believe in a Kobo it can be overridden. I have nothing against overriding it, but I'm not going to do something substandard in my own eyes just because Amazon makes it impossible to override it.

In any case, I'm not selling, I'm giving freely. Not that I think that matters. You might.

[phillipgessert]

If it’s free, you can follow your own compass. Personally I’d keep the design as unopinionated and flexible as possible in that situation but that is just one of many approaches. Good luck with it.

[bookman156]

Most of the justified ebooks I've seen are also impossible to override on a Kindle. Who knows why that is, when they let you override embedded font and line-height and margins? Perhaps people should be taking it up with them and designers can simply do what they think is best.

[Tex2002ans]

Originally Posted by bookman156

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.

Let me make this easy for you:

Change those to ALL CAPS.

Those examples you gave are not "essential" use-cases at all.

* * *

The only essential smallcaps I can think of—in all these years—is:

• certain Citation Styles (mostly European/Law-based)
  
  • which use smallcaps for author names and/or titles of documents.

Still, I'd argue for font-variant, or maybe font-variant: small-caps + font-weight: bold.

(So if smallcaps don't exist, at least it'll stand out from the other text.)

* * *

Side Note: If you want everything there is to know about acronyms + what to look out for + how to find/normalize them:

• 2021: "RegEx: Insert nbs between initials, etc."

Bleeding-Edge Side Note: And if you want a way of mass detecting + tagging these, the latest versions of Sigil will be able to handle this. See my brainstorming posts in:

• 2022: "Possible To-Do List for Future Sigil Releases Post Sigil 1.8"
  
  • Specifically Post #2 where I described "Advanced Find & Replace" + UPPERCASE -> <span class="smallcaps">

Originally Posted by bookman156

[...] or a span class and smaller font size.

Big mistake to try to fake:

S<small>MALL</small> C<small>APS</small>

I've described why in 2019: "Replacing a single letter".

Lots of negatives. Very few positives.

Side Note: This is one of the rare cases where me+Hitch disagree. Luckily, I have a lot more leeway in who I work with!

The publishers trust me, so I do what I think is long-term best for the code+smallcaps.

In Hitch's case, she works with all sorts of horrifying authors with horrible "tastes"!

Those F<small>AKE</small> C<small>APS</small> are no good I tell you! No dang good!!!

Originally Posted by Hitch

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.

Heh. We discussed a lot of that "Real vs. Fake Smallcaps" stuff in:

• 2021: ""Creation" of fonts ex nihilo (or how Calibre displays Bold having only Regular)"

Originally Posted by Hitch

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.

lol. Yep.

Reality:

If it's purely visual stuff, like smallcaps first words/lines... then sure, you can emulate that in CSS if you feel like it. It completely doesn't matter at all if the device doesn't support it.

• ALL CAPS all the easy cases
  
  • BC / AD / AM / PM / NATO / FBI
• <span class="smallcaps"> all the intermediate cases
  
  • <span class="smallcaps">Last, First</span>
    
  • OR Last, First

I mostly toss it in the bucket with Dropcaps (except those you shouldn't do in ebooks EVER).

They're "nice-to-have" in Print books, but in ebooks, boy, oh boy, they're hell.

Originally Posted by Hitch

Not to be obscenely lazy, but at that point, I say to myself, "Self, what typeface can I use, instead of this, that already has a smallcaps font?," and that's what I use.

Yep, exactly.

... And then you run across obscure accented characters, etc. (I ran across this when auto-generating PDF Headers/Footers based on chapter names.)

Next thing you know, you're getting Turkish dotless/dotted Iİ + Czech ČĎÝ.

There ain't no "proper smallcaps font" with these characters inside of it!

This is why I just say, do the damn font-variant, and leave it up to the device to auto-generate a fake smallcaps if it supports that.

* * *

Too little gain, but too many negatives from trying to "hack" all this crap into ebooks.

Print? Where you see the exact final output? Great! Have at it, manually tweak things to your heart's content.

Originally Posted by bookman156

Well I never! I just converted an EPUB to AZW3 in Calibre and the Publisher Font is now there. Doh! Kicking myself for not suspecting MOBI. Thanks!

Yeah, it's a little confusing because Calibre names things slightly differently.

With Amazon, you have 3 main types (MOBI/KF7, KF8, KFX).

Calibre calls them slightly different names, but it's all the same stuff.

If you want a more detailed breakdown on that, see:

• 2019: "Epub-problems in tablets" (my Post #29+)

Originally Posted by bookman156

But this may also explain why a lot of people never find the the embedded font on a Paperwhite, simply because they didn't realise the MOBI didn't embed the fonts. Something I will now be sure to point out.

Heh, like Hitch explains, the vast majority of people NEVER even dig into their settings, they don't even know the "Publisher Font" checkbox even exists.

And because publishers have tended to pump out piles of garbage, forcing embedded body fonts (instead of using the fonts SPARINGLY), ebook readers got used to completely overriding books completely with their own fonts + places like Amazon strip most fonts from the book during their ingestion process.

Originally Posted by Hitch

Define "small window." I very much prefer justification, with Enhanced Typesetting functions (hyphenation kerning, tracking, etc.) on my eInk Paperwhites. I really hate ragged-right.

Yep.

Hyphenation is one thing that has advanced a ton the past few years on the newer renderers.

Makes reading on smaller devices MUCH much better, because the inter-word gaps aren't as large.

This is one of the reasons why I love Kobo as well, because you can actually tweak/update the Hyphenation Dictionary + the left/right hyphen variables.

See JSWolf's fantastic Kobo > "Better Hyphenation" thread.

On bleeding edge CSS hyphens (and Hyphenation in general), see my posts in:

• 2021: "Welsh"
• 2021: "Add xml:lang to ePub"
• 2018: "Auto-Hyphenation"

and jhowell's "Kindle hyphenation", which describes the bleeding-edge stuff in Kindle's KFX renderer.

This is why it's important to tag your languages properly.

If you built it already tagged your ebooks properly, you instantly get these benefits as better firmware/renderers/formats come out.

- - - - - -

Complete Side Note: And, bookman156, you'll love this:

Firefox has had CSS hyphens support since 2011.

Chrome has FINALLY gotten it a few versions ago (but still barely any languages).

Talk about Google holding back typography on the web! (And being inferior to many ebook renderers!)

- - - - - -

Originally Posted by phillipgessert

It's less a matter of whether the default is justified, and more a matter of the default being whatever the reader expected to find. Good book design relies heavily on making things frictionless for the reader. For ebooks, that means making sure the book behaves the way the reader expects it to.

See my post back in 2018: "Compression of space between lines of text decreases readability - MsWord to epub":

Originally Posted by Tex2002ans

In ebooks, it's all about user choice in font and user settings. Best choice is to get out of the way and be as minimal as possible.

Stuff like line-heights, font sizes, specific fonts... that's all customizable by the user so they can read how THEY prefer.

So an ebook reader won't be reading using Times New Roman, they'll be reading using their preferred device's font.

They won't be reading at "font size 11", they'll be reading anywhere from tiny, large, or larger (poor eyesight), or anywhere in between.

They won't be reading on a 6"x9" page, they'll be reading on teeny weeny phones, up to large monitors.

In Print, you are in full control of all those variables, where in ebooks, you are pretty much in control of none.

Originally Posted by JSWolf

Left justified look like a shoddily made eBook.

Ebooks, not so bad (because I can override it with the proper setting), but if I see a Print book that's left-aligned, bleh...

Originally Posted by JSWolf

All you have to do is put the overall justification in the body style. Then if the device/program being used to read it has the ability to change justification, then it will work.

Be careful. This is not correct for Kindles.

If you set text-align: justify on Kindles, it will not let the user override. You will eventually get a KQN (Kindle Quality Notice) and get dinged for it.

You would have expected them to fix their firmware after all these years, but they still haven't.

Every other device/app under the sun allows you to override this.

(I know I wrote about it somewhere within the past few years, couldn't find the exact topic though. I think this post is almost long enough! )

It should be sensible:

• If p = text-align: left OR justify -> follow user preference
• If p = text-align: center OR right -> follow the CSS

That's how I recall it approximately working in EPUB on my Nook, Kobo, and all the apps I've tested too (PocketBook + Gitden + Thorium + [...]).

Originally Posted by bookman156

I think it's always useful to air different point of view. Sometimes, very occasionally, people even change their minds.

Again, I'd stress reading the previous topics about this. It's been discussed to death by all of us. lol.

In your favorite search engine, type:

Justification Tex2002ans site:mobileread.com
Justification Hitch site:mobileread.com

You'll stumble upon at least 10 years of "justification in ebooks" talk.

Honestly, this stuff is much better handled at the renderer level (see KFX thread). Justification/Hyphenation is one case where ebooks HAVE objectively gotten much better in the past 4 years.

But you know how you get that? Code your book right, then get the hell out of the way. The device will carry it from there.

* * *

And hell, in the future, when Variable Fonts become more ubiquitous, maybe those auto-generated smallcaps on devices might be better too.

And when you overrode their futuristic Variable Fonts with your ancient, inferior, fully-embedded TTF smallcaps file, the future reader will be shaking their fist at you after they auto-translate the book and your subset font doesn't have the proper characters.

[JSWolf]

Originally Posted by bookman156

Most of the justified ebooks I've seen are also impossible to override on a Kindle. Who knows why that is, when they let you override embedded font and line-height and margins? Perhaps people should be taking it up with them and designers can simply do what they think is best.

That's because most CSS is poorly written. There are text-align all over the place where it's not needed to specify the book's alignment. You only need to align the text once in the body style. After that it's center or right alignment as needed.

[DiapDealer]

Feel free to take this ebook design philosophy discussion somewhere else. This one is done.