How do I get rid of Table of Contents?

[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!

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.

[bookman156]

Define "better"? Not being a wiseass, but for what purposes precisely?

I meant better to cater for Kindle, but I see now that it was just the MOBI. It is obviously better to put it on body, always.

[bookman156]

Well, hell, if you're me, you just open Kindle Previewer 3 (you can download it from Amazon) and then drag-drop the working ePUB (the one showing you fonts in Kobo) onto it. It will process it and display the result.

I use Linux, though I could probably experiment in my old Windows laptop for that.

[bookman156]

Well, SSDD--it means that those whom have the ePUB inflicted upon them likely shan't be able to override your font choice.

No, that doesn't apply, can definitely override Publisher Font with font-family on body.

[bookman156]

when someone forces ragged-right!

Justified text on a small window is terrible. It never fully works unless you read at a tiny font size, some justified, some not managing it. And I'd never use automatic hyphenation. If they want justified they can of course look at the PDF I also supply.

[JSWolf]

Originally Posted by Hitch

Wolfie, my one Twoo Wuv:

And let's recap: exactly how many devices--not software, browser-based readers--have you seen that support "font-variant," exactly? "font-variant" is supported, in ET (Enhanced Typesetting) in KDP, but that's for KFX only, then. Just sayin'.

You either split the baby and go for smallcaps where you can, and pray a lot, or you do a faux font-variant, by using all-caps smooshed. Them's the realities.

Hitch

KePub. & KOReader both support small-caps.

[Hitch]

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!

Well, that's one of the downsides of using automagic conversion--you don't get into the guts of the thing.

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.

Nah, most people don't realize it's there because they simply don't look. The vast, vast majority of folks aren't keeping their eReading libraries in Calibre and DIY'ing their formats. When I talk about "most people" I mean your everyday, "bought this from Amazon/B&N/Kobo" folks who don't understand how the eBook magically flies through the air and lands on their eReader.

They open their first Kindle (or whatever) eBook, find the font that they like and badda-bing, that's it for eternity.

Originally Posted by bookman156

I meant better to cater for Kindle, but I see now that it was just the MOBI. It is obviously better to put it on body, always.

In ye olden days--and to this day--if you encoded an HTML font on the body tag, it absolutely WOULD prevent you from changing the main font. That's why KDP made it verboten.

Originally Posted by bookman156

No, that doesn't apply, can definitely override Publisher Font with font-family on body.

See my previous. Seriously, not kidding. HOWEVER and this has been a major bone of contention with every eBook developer/formatter, ever--it's always been 100% overridable on the Paperwhites. Not on anything else, mind you--but the PPWs? Yes. So, what you're seeing is not indicative of the overall KDP results/Kindle display results.

Originally Posted by bookman156

Justified text on a small window is terrible. It never fully works unless you read at a tiny font size, some justified, some not managing it. And I'd never use automatic hyphenation. If they want justified they can of course look at the PDF I also supply.

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.

Hitch

[JSWolf]

If you are making your eBook for sale, don't use font-variant: small-caps; as it won't work in enough places.

But if it's for your own use, go ahead and use it if what you are using supports small-caps.

[bookman156]

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.

Small window is always 'my reader'. If it looks crap in what I have, then I go for something that doesn't, ie unjustified. I think on Kobo you can justify it if it comes unjustified, can't you?

On 'my reader', I see 'Alignment' is 'Not Available'. Are you saying that's because I specified it as align-left? But if I specified it as justified maybe they won't be able to change it to unjustified either. I don't know. All I can do is make what I think is the right aesthetic decision. And, as you say, few change their settings so if I supplied justified then some may hate it as much as I do because it isn't accomplished properly in the device.

Overall of course I prefer justified. Back when I did handset letterpress I would spend hours justifying lead type text by hand, and I must admit I spend just as long on H&J violations in InDesign these days.

In my view, there is nothing uglier than badly justified text.

[bookman156]

As the only way to guarantee beautifully justified text is in print and PDF, I completely eschew it in other places. Sometimes the reader who prefers it just isn't right.

[Hitch]

Originally Posted by bookman156

Small window is always 'my reader'. If it looks crap in what I have, then I go for something that doesn't, ie unjustified. I think on Kobo you can justify it if it comes unjustified, can't you?

I don't use a KOBO for reading that much and I honestly don't remember. If we wait 5 minutes, Wolfie will come and enlighten us.

On 'my reader', I see 'Alignment' is 'Not Available'. Are you saying that's because I specified it as align-left?

If you mean that you do have align: left, then yes, that's what that generally means.

But if I specified it as justified maybe they won't be able to change it to unjustified either. I don't know. All I can do is make what I think is the right aesthetic decision. And, as you say, few change their settings so if I supplied justified then some may hate it as much as I do because it isn't accomplished properly in the device.

If you're making it for yourself, do whatever floats your boat. For your readers/buyers--don't align it at all. That way, they can choose what they want.

Overall of course I prefer justified. Back when I did handset letterpress I would spend hours justifying lead type text by hand, and I must admit I spend just as long on H&J violations in InDesign these days.

Yeah--it's hard to overlook. Just today, LOL, I had to explain to this customer--whom, by the way, has gone to great lengths to express to me her trade publishing experiences, as an 'editor,' etc. why iBooks didn't have the same line-count on all pages. (We have W/O turned "on" to 2 lines, I think it is.) You'd think she'd have noticed, wouldn't you? I mean, if the fact that the pages didn't square across the...well, for lack of a better word, the gutter, was so problematic, how come her hugely-trained expert eye didn't instantly see that 99% of those instances were orphans???? (or would have been, without the W/O coding.0

In my view, there is nothing uglier than badly justified text.

And that sentiment is lovely--in its place. We have no opportunity to kern, track and barely to lead, in eBooks. Thus, we have to be content with what we CAN do, not with what we cannot.

Originally Posted by bookman156

As the only way to guarantee beautifully justified text is in print and PDF, I completely eschew it in other places. Sometimes the reader who prefers it just isn't right.

Yes, well, as I'm the reader and it's my eyes--I am right. It matters hugely not to foist our own choices and prejudices--if they exist--on our clients' readers. Right? Right.

Hitch

[bookman156]

Having no text alignment at all, missing it out altogether, would be kinda egalitarian, if it wasn't for the fact that the default is doubtless justified. Perhaps I'm giving a few readers the chance to see what unjustified is like. They may come to prefer it in this setting.

If we're against 'foisting choices' on readers, we should just say silent and not write.

[bookman156]

(We have W/O turned "on" to 2 lines, I think it is.) You'd think she'd have noticed, wouldn't you? I mean, if the fact that the pages didn't square across the...well, for lack of a better word, the gutter, was so problematic, how come her hugely-trained expert eye didn't instantly see that 99% of those instances were orphans???? (or would have been, without the W/O coding.

I'm in two minds whether widows/orphans are better or worse than uneven spaces. As it's a reflowable ebook, widows/orphans are sort of expected, so I set it to 1, whereas uneven number of lines per page is less expected, indeed causing some consternation with this client, and they could also appear to be a deliberate space. Stuck between a rock and a hard place with this.

[phillipgessert]

Originally Posted by bookman156

Having no text alignment at all, missing it out altogether, would be kinda egalitarian, if it wasn't for the fact that the default is doubtless justified. Perhaps I'm giving a few readers the chance to see what unjustified is like. They may come to prefer it in this setting.

If we're against 'foisting choices' on readers, we should just say silent and not write.

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.

[Hitch]

Originally Posted by bookman156

I'm in two minds whether windows/orphans are better or worse than uneven spaces. As it's an reflowable ebook, windows/orphans are sort of expected, so I set it to 1, whereas uneven number of lines per page is less expected, indeed causing some consternation with this client, and they could also appear to be a deliberate space. Stuck between a rock and a hard place with this.

Y'know, I'm with you--but then, invariably, if we DO turn on W/O and they get uneven pages, they bitch and if we don't, they complain that they have W/O. I am accustomed--accustomed, mind you, not merely inured-to, receiving proof forms with hundreds of "W/O" corrections marked down for us, in ePUB/MOBI formats. I mean...it doesn't matter how many times I say "there are no w/o in eBooks" or the like, or "change the font size, so that you get a better idea of how this all works," or anything else. Invariably, a few times/month, sure 'nuff...here comes the ubiquitous widows-orphans eBook proofing form. Sigh.

(And don't get me started about print--squaring the page in today's world, versus w/o, versus aligning across the grid, versus costs. Just...don't get me started. This ain't ye olden days, when people paid normal money for print layout and expected to be in production for some months. Noooo, now, they want to match pricing for a $200 Fiverr for a 100K-word novel, AND they expect you to hand-kern and track for runts and widows/orphans. Ha.) I ran into one "print designer" for a woman who told me that she charges next to nothing--in the hundreds, for non-fiction and, wait for it, actually does sit there and hand-track and kern, line-by-line, through the entire book. Hell, for what she was being paid, I wouldn't have done it for 10 pages. Phoeey.)

Hitch