KF8 on Fire HD6 - Justification & Font Issues

[DreamWriter]

Originally Posted by JSWolf

I have an issue here with the text indent being 5%. That's 5% of the screen. So on different devices, you get different indents. On a Kindle DX, or the 10" Kindle Fire, you get rather overly large indents. It's bets to specify the indent in em. I use 1.2em and that works well and does not change based on the screen size.

I appreciate your comment, Jon. I have a 10.1" Android tablet with the Kindle app, and I think 5% indent looks great (it isn't a large indent at all!). I like the way it looks on smaller devices, too. My e-books have always had that and Amazon Kindle Publishing Guidelines still supports percentage indents, so I'll probably leave it that way for now, but I will definitely try 1.2em in the future to see how much of a difference it makes.

Personally, I like the 03/09/2015 version better. Even if the font weight was the same, I prefer the hyphens. Since getting the Kobo Aura H2O with has hyphenation support, I rarely see whide gaps in lines and the H2O does not go crazy hyphenating. The worst Reader is the B&B nook STR and later Readers as they really do go crazy.

I think a lot of readers would agree with you. Personally, I don't mind auto-hyphenation if it's handled well, but depending on the font (and text size), it can get excessive. For example, it often hyphenates after just two letters, hyphenates proper names, and hyphenates already-hyphenated compound words. I have not observed this in my own e-books (thankfully!), but in some auto-hyphenated Kindle e-books I've seen, it just breaks the word in the WRONG place--not even between syllables.

Here is an example from one of my e-books that I posted at the beginning of this thread so you can see what I'm talking about with the excessive two-letter hyphenation:

[sorry, image link broken]

I think that's ugly! Also, some readers absolutely HATE auto-hyphenation, to the point where they will complain to Amazon about it. Then the author receives a "quality control" notice from KDP, who may withdraw the book from sale. Readers aren't used to seeing auto-hyphenation in Kindle books; many will assume that the author/publisher made those bad hyphenation choices.

Usually there is some way to tell the rendering program not to hyphenate. This is a bunch of different commands you can use to try to turn off hyphenation if that's what you want.

body {
-epub-hyphens: none;
adobe-hyphenate: none;
-webkit-hyphens: none;
-moz-hyphens: none;
hyphens: none;
}

Yes, I posted regarding that earlier. This code does work to suppress auto-hyphenation in Kindle books:

body
{-webkit-hyphens:none;
hyphens:none;}

I tested that and wasn't happy with the results. It produced a lot of ragged-right lines, very obvious on the first page of the tested e-book.

[DreamWriter]

Originally Posted by Hitch

Dreamwriter:

I really think you ought to try one with no font calls AT ALL. No embedded font, no nuthin', and see what happens. We have to start real bracket-navigation troubleshooting, and if we can determine that a "naked" book does NOT have the bizarro-world hyphenation--at least it gives a place to start. Yes, I know what you're thinking--it's a crapload of time and testing, and only YOU can do it (as the rest of we wonks don't have published books to "play" with). But if it were me, I'd:

1. Try a book with NO font specfiied, at all. No called fonts, no embeds.
2. If that makes hyphenation issues go bye-bye, then I'd do one with "font-family:serif," and naught else.
3. Then see if THAT works correctly.
4. Then I'd do the body font call--:garamond, serif.
5. Rinse, repeat.
6. Finally, then, I'd try firstly calling a sans-serif for the chapter head, from the firmware; and then, back to embedding.

Obviously, something has changed at the KDP. But we don't have a real "control." We have too many variables. You haven't tried a really controlled experiment, narrowing your issues down to one thing at a time. You have font calls in the body; you have fonts embedded; you have a lot going on, when you think about it. And you have multiple symptoms, too--you have hyphenation, BAD hyphenation, a darker font, AND no "publisher font" option.

That's too many moving parts. The only way forward is, sadly, the hard way. That's to start at the bottom, and work your way up and out. You have to start with a naked file, no "serif," no nothing. See what result that gets. I don't see any other way around it, I really don't.

Hitch

Definitely good advice, especially since I've run out of other ideas to try! Do you suggest I upload a Kindlegen-created mobi or an epub file to KDP?

My brain is fried for today, but that is at the top of my to-do list for tomorrow. I will upload a file that has NO embedded or called fonts at all—no "font-family" anything.

Actually, that won't be a very difficult task. I have no problem navigating CSS/HTML/OPF/NCX, and I'm used to waiting for five hours between KDP uploads after doing this almost daily for a month.

After the updated book is available for sale, I'll have Kindle CS push the latest version to my devices. Sometimes I can't be 100% sure if they've actually sent me the very latest version because the changes are subtle, but this one will be very easy to tell!

I'll let you all know what happens!

Edit: Hitch, do you like 1.2em for paragraph indents, as Jon suggested, or is there another em value you prefer? I may experiment with that, too.

[DreamWriter]

Originally Posted by Hitch

Don't laugh, but it varies. I use good ol' TNR for almost anything non-fiction; I like the easy clarity of the font. I prefer Trebuchet (or Futura on the Voyage), for non-fiction that is fantastical in nature, like Harry Potter-type books, or supernatural alternate realities. (The exception being Harry Dresden. No, I don't know why; I use Bookman Antiqua for that Harry.) I use Baserville for mysteries. ;-)

I know, it's weird.

Hitch

Do licenses need to be acquired for any of the fonts you mentioned or can those particular fonts be embedded in e-books without that concern?

[Hitch]

Originally Posted by DreamWriter

Definitely good advice, especially since I've run out of other ideas to try! Do you suggest I upload a Kindlegen-created mobi or an epub file to KDP?

My brain is fried for today, but that is at the top of my to-do list for tomorrow. I will upload a file that has NO embedded or called fonts at all—no "font-family" anything.

Actually, that won't be a very difficult task. I have no problem navigating CSS/HTML/OPF/NCX, and I'm used to waiting for five hours between KDP uploads after doing this almost daily for a month.

After the updated book is available for sale, I'll have Kindle CS push the latest version to my devices. Sometimes I can't be 100% sure if they've actually sent me the very latest version because the changes are subtle, but this one will be very easy to tell!

I'll let you all know what happens!

Edit: Hitch, do you like 1.2em for paragraph indents, as Jon suggested, or is there another em value you prefer? I may experiment with that, too.

I like 1.2-1.5 em, depending on what font I think will be used, and a variety of other factors. We have many that have a simple 1em indent. 1.5 will generally get you 3-4 characters, give or take a lie or two, on a Kfire.

Originally Posted by DreamWriter

Do licenses need to be acquired for any of the fonts you mentioned or can those particular fonts be embedded in e-books without that concern?

No, no--licensed. I forget the rates for BookAntiqua, Trebuchet, etc., but if I recall correctly, none were spectacularly cheap.

HOWEVER, that being said, if you're diligent, you can usually find very good substitutes that are uber-affordable. I like PTSans, for example, for a nice sans. And honestly, PTSerif isn't bad to match it, if you want serif/sans-serif as the theme. Neuton is a viable body font. Gentium Book can be nice, too.

The trick is, in my opinion, not to just see a font and go nuts for it. Many (far too many) fonts nowadays are just slapped together, because the strokes look nice, with no consideration given to kerning, kerning pairs, the font metrics, etc. I gave an example about this very topic last night on the KDP forums (which of course went straight to mod hell..urghghghghg)...the good ol reliable print font, Garamond, has over 1300 kerning PAIRS, if you look at the three main faces: regular, bold, italic. (The topic at hand was "why can't the reading devices just kern on the fly, no matter what font size is chosen, or font" being complained about, of course, because the person asking understands nothing whatsoever about the complexities of kerning).

So, to get a real feel for it, you actually have to do an entire PRINT page of layout, and an eBook page, and then stare at it. See if anything leaps out at you. Because if you choose the wrong font (for a body), it can actually tire the eyes, strain the reader, bring an unwanted element to the reader's enjoyment of the book. And that, obviously, would be BAD.

This is why I tend to tell folks to stick to TNR and Caecilia, if they are unsure--because no two fonts in the history of humankind have ever been as tested, retested, designed, user-driven, etc., like those two. If nothing else, at least you know that they won't make your reader STOP reading early, because of eyestrain, or some other jiggery-pokery around the eyes that bothers them--even if they don't understand exactly what it is.

See what I mean?

Hitch

[Notjohn]

Originally Posted by DreamWriter

Do you suggest I upload a Kindlegen-created mobi or an epub file to KDP?

I don't know what Hitch would say to that, but I upload all my books as epubs. (And it was Hitch who told me in 2012 that epubs converted fine on the KDP.) That way I don't have to maintain two versions, for Amazon and for all the rest (though the Amazon version doesn't include a cover, while the others do).

[DreamWriter]

Originally Posted by Hitch

I like 1.2-1.5 em, depending on what font I think will be used, and a variety of other factors. We have many that have a simple 1em indent. 1.5 will generally get you 3-4 characters, give or take a lie or two, on a Kfire.

.... No, no--licensed. I forget the rates for BookAntiqua, Trebuchet, etc., but if I recall correctly, none were spectacularly cheap.

Thanks! I'll try several em indents and see how it looks on my devices.

Originally Posted by Notjohn

I don't know what Hitch would say to that, but I upload all my books as epubs. (And it was Hitch who told me in 2012 that epubs converted fine on the KDP.) That way I don't have to maintain two versions, for Amazon and for all the rest (though the Amazon version doesn't include a cover, while the others do).

Thanks, Notjohn! I've uploaded both epub and mobi in the past but always wondered if one format is more trouble-free than the other at KDP.

The last time KDP suggested a specific change in my CSS, they told me to upload a mobi. I make both files anyway, since I test the Kindlegen-created mobi on my devices and validate an epub online at IDPF before upload.

[JSWolf]

Originally Posted by Hitch

The trick is, in my opinion, not to just see a font and go nuts for it. Many (far too many) fonts nowadays are just slapped together, because the strokes look nice, with no consideration given to kerning, kerning pairs, the font metrics, etc. I gave an example about this very topic last night on the KDP forums (which of course went straight to mod hell..urghghghghg)...the good ol reliable print font, Garamond, has over 1300 kerning PAIRS, if you look at the three main faces: regular, bold, italic. (The topic at hand was "why can't the reading devices just kern on the fly, no matter what font size is chosen, or font" being complained about, of course, because the person asking understands nothing whatsoever about the complexities of kerning).

The problem is a lot of these really well made fonts such as Garamond don't work well on an eInk screen. It's the fonts that don't have kerning or are not all that well made that tend to look better on eInk. I have an iPad 4 and some of these lightweight fonts are even too lightweight for an iPad.

The other problem is that sometimes the reading program in use doesn't support kerning even if the font does.

[Hitch]

Originally Posted by JSWolf

The problem is a lot of these really well made fonts such as Garamond don't work well on an eInk screen. It's the fonts that don't have kerning or are not all that well made that tend to look better on eInk. I have an iPad 4 and some of these lightweight fonts are even too lightweight for an iPad.

The other problem is that sometimes the reading program in use doesn't support kerning even if the font does.

Agreed. Garamond, for example, looks like the dog's breakfast on MOBI tablet readers. It's far too light. That's why I tend (always) use a heavier, OS version that isn't Garamond, but resembles it a lot. For that matter, y'know, Georgia is a good reading font, on e-ink.

I don't think I know any reading system that thoroughly supports kerning, because it requires the characters. Or the slots for the characters, like in Garamond--that's 1300 characters, above and beyond the base sets.

We had a guy, that could NOT let go of some kerned pair...I think it was the kerning pairs in....now, I can't recall the font. My brain keeps thinking Linux Libertine, but that's wrong. Whatever it was, I couldn't get him to understand that just because he saw it on his computer--where he'd downloaded and installed the font--didn't mean that it would appear on the reader.

Slight bitch du jour about fonts and font embedding in source materials:

Spoiler:

I actually run into this shockingly often, and I don't mean from Trogs, either. I mean, you'd be AMAZED at how many print designers send me stuff w/o having a font actually embedded. They don't understand that what I see at this end bears ZERO resemblance to what they've sent. I'm now having to constantly check for "called fonts" against what I SEE, because of this, and that's a royal Pain in the Tuchus, lemme tell ya. Heavily prevalent with almost anything I get that has been designed on a Mac, too--there's an operating assumption that "of course" I have Font X, because a) I MUST BE using a Mac [I'm not unless I'm forced to boot up the one I keep here for just those emergencies] and b) I MUST HAVE their fave font Y. [I rarely do].

</rant>

Hitch

[JSWolf]

Originally Posted by Hitch

Agreed. Garamond, for example, looks like the dog's breakfast on MOBI tablet readers. It's far too light. That's why I tend (always) use a heavier, OS version that isn't Garamond, but resembles it a lot. For that matter, y'know, Georgia is a good reading font, on e-ink.

I don't think I know any reading system that thoroughly supports kerning, because it requires the characters. Or the slots for the characters, like in Garamond--that's 1300 characters, above and beyond the base sets.

We had a guy, that could NOT let go of some kerned pair...I think it was the kerning pairs in....now, I can't recall the font. My brain keeps thinking Linux Libertine, but that's wrong. Whatever it was, I couldn't get him to understand that just because he saw it on his computer--where he'd downloaded and installed the font--didn't mean that it would appear on the reader.

Slight bitch du jour about fonts and font embedding in source materials:

Spoiler:

I actually run into this shockingly often, and I don't mean from Trogs, either. I mean, you'd be AMAZED at how many print designers send me stuff w/o having a font actually embedded. They don't understand that what I see at this end bears ZERO resemblance to what they've sent. I'm now having to constantly check for "called fonts" against what I SEE, because of this, and that's a royal Pain in the Tuchus, lemme tell ya. Heavily prevalent with almost anything I get that has been designed on a Mac, too--there's an operating assumption that "of course" I have Font X, because a) I MUST BE using a Mac [I'm not unless I'm forced to boot up the one I keep here for just those emergencies] and b) I MUST HAVE their fave font Y. [I rarely do].

</rant>

Hitch

Ah! The famous, it's installed on my computer so just calling the font-family shows it here so it must work everywhere syndrome.

One reason I like Kobo is because you can sometimes increase the weight of a font so it looks decent/good on an eInk screen. This is only for the font on the Kobo though. It doesn't modify the font. Kindle's do the same thing with Cecelia. They modify it for heavier weight and the condensed version is made from the regular version. There is no such thing as Cecelia condensed.

[DreamWriter]

Originally Posted by Hitch

I really think you ought to try one with no font calls AT ALL. No embedded font, no nuthin', and see what happens. We have to start real bracket-navigation troubleshooting, and if we can determine that a "naked" book does NOT have the bizarro-world hyphenation--at least it gives a place to start. Yes, I know what you're thinking--it's a crapload of time and testing, and only YOU can do it (as the rest of we wonks don't have published books to "play" with). But if it were me, I'd:
[*]Try a book with NO font specfiied, at all. No called fonts, no embeds.

The e-book I'm experimenting with right now is Lotto: Blood Money. Yesterday, I removed ALL embedded and "called" fonts. There is no Fonts folder in OEBPS (I confirmed outside Sigil).

Removing all fonts did not stop the auto-hyphenation. I did notice something interesting, though. In the past, when my books were viewed in the online KDP previewer, Voyage would always display the sans serif font (unless serif was specified in CSS). With all fonts removed, Voyage text shows as serif in the previewer now. I didn't expect that. I hope that's the way it is on the actual device (I don't have one to test).

I've published two versions of Lotto since I last posted. I discovered something else that cured a long-time problem I've had with Kindlegen-created mobi files when I removed some HTML/CSS I've had some suspicion about.

I had this for initial chapter paragraphs:

<p class="firstpara"><span class="initialcap">"W</span>HAT WOULD I DO with fifty million dollars?"</p>

MOBI CSS:
span.initialcap
   {font-size:3em;
   font-weight:bold;}

KF8 CSS:
span.initialcap
   {font-size:1.5em;
   line-height:0;
   font-weight:normal;}

[I have a 3G Kindle Keyboard that I haven't updated in a long time (last update on my device is 3.3). For quite some time, Kindlegen-created mobis would intermittently mess up NCX navigation on KK, especially when jumping chapters backwards with the controller button. CSS would sometimes show at the top of the screen. This would happen when I'd change the most innocuous CSS/HTML and was very unpredictable. It drove me nuts! Well, removing the HTML and CSS above seems to have cured that problem.

EDIT: Never mind. The intermittent problems with Kindle Keyboard navigation is not solved. After I took that code out of CSS in the wee hours of the morning today, I made several more Kindlegen mobis that were fine. But later today, the problem is happening again with newly edited/Kindlegen-created files. I've thought that the issue was with Kindlegen, but it may be the very old version of Sigil I use. My computer's too outdated for the latest version. Oh, well.]

I suspect Kindlegen was choking on something in that code. It may have been the span itself or perhaps the line-height:0; in KF8 CSS (since line height cannot be less than 1.2em in Kindle books). Anyway, I'm very happy about that. That code was always troublesome anyway.

I have no idea what else in my HTML/CSS could be causing auto-hyphenation in all four of my e-books republished since mid-February. I have two CSS files, called by media queries, which I've had for years. KF8 and mobi display as I would expect, so that seems to work fine. Perhaps it really is a new "feature" for recently published e-books on the Fire HD6 (and several other Fires), despite KDP's insistence to the contrary.

[JSWolf]

Maybe someone else can see what's going on if you post the entire CSS.

[DreamWriter]

Originally Posted by JSWolf

Maybe someone else can see what's going on if you post the entire CSS.

It's very long, and there are two versions: one for mobi and one for KF8.

Edit: I posted the CSS in my next post.

[Notjohn]

Originally Posted by DreamWriter

It's very long, and there are two versions: one for mobi and one for KF8.

Is that even possible?

[Hitch]

Originally Posted by DreamWriter

It's very long, and there are two versions: one for mobi and one for KF8.

DW:

That shouldn't be. You ought to have one, reasonable-length stylesheet, with some fallback media queries for KF7. You oughtn't to have uber-lengthy stylesheets for a novel, really. Our average, includes amzn-mobi CSS sheet is <380 lines long.

Hitch

[DreamWriter]

Originally Posted by Notjohn

Is that even possible?

I use media queries to call the two stylesheets. I've done it that way for several years (since KF8 became available) and never had any problems with it.

So, here's what it looks like in each HTML file:

<head>
     <title>Chapter 1</title>
     <link href="../Styles/lotto-mobi.css" media="amzn-mobi" rel="stylesheet" type="text/css" />
     <link href="../Styles/lotto-standard.css" media="not amzn-mobi" rel="stylesheet" type="text/css" />
</head>

Most of the CSS below has been that way for several years. I never had any problems prior to uploads after early/mid-February of this year (about a month ago). Keep in mind that I even re-uploaded a 1-30-15 file on 3-6-15 that was previously fine; now, the new upload has auto-hyphenation.

This CSS is for a version of Lotto: Blood Money that I just uploaded today at 2:00 p.m. Pacific time (45 minutes ago), so it may not be available for sale/borrow yet, and the Look Inside and downloadable sample may not be available yet either. If you see centered Chapter title and no initial cap in the first paragraph, then that's probably the version with CSS below.

KF8 (lotto-standard.css):

div.title
	{margin:0;
	text-indent:0;
	text-align:center;
	font-size:1.3em;
	font-weight:bold;}

div.chapter
	{margin-top:2em;
	margin-bottom:0;
	margin-left:0;
	margin-right:0;
	padding-bottom:.3em;
	text-align:center;
	text-indent:0;
	font-size:1.7em;
	font-weight:bold;}

div.title_bottom
	{margin-top:0;
	margin-bottom:1em;
	margin-left:0;
	margin-right:0;
	text-indent:0;
	text-align:center;
	font-size:1.3em;
	font-weight:bold;}

div.copycenter
	{margin:0;
	text-indent:0;
	text-align:center;
	font-weight:normal;}

div.dots
	{margin-top:.5em;
	margin-bottom:0;
	margin-left:0;
	margin-right:0;
	color:#909090;
	text-indent:0;
	text-align:center;}

div.otherdots
	{margin-top:0;
	margin-bottom:.5em;
	margin-left:0;
	margin-right:0;
	color:#909090;
	text-indent:0;
	text-align:center;}

div.article
	{page-break-before:always;
	margin:0 .3em 0 .3em;
	padding:1em;}

p
	{margin:0;
	text-indent:1.3em;}

p.firstpara
	{margin-top:1em;
	margin-bottom:0;
	margin-left:0;
	margin-right:0;
	text-indent:0;}

p.top-para
	{margin-top:1em;
	margin-bottom:1em;
	margin-left:0;
	margin-right:0;
	text-indent:0;}

p.para
	{margin-top:0;
	margin-bottom:1em;
	margin-left:0;
	margin-right:0;
	text-indent:0;}

p.top-article
	{margin-top:1em;
	margin-bottom:1em;
	margin-left:0;
	margin-right:0;
	text-align:left;
	text-indent:0;
	font-size:1.1em;}

p.article
	{margin-top:0;
	margin-bottom:1em;
	margin-left:0;
	margin-right:0;
	text-align:left;
	text-indent:0;
	font-size:.9em;}

p.scenebreak
	{margin-top:.5em;
	margin-bottom:0;
	margin-left:0;
	margin-right:0;
	text-indent:0;}

p.toc
	{margin:0;
	text-align:center;
	text-indent:0;}

p.image
	{margin:0;
	text-align:center;
	text-indent:0;}

span.bold
	{font-weight:bold;}

span.italic
	{font-style:italic;}

a:link
	{color:blue;
	text-decoration:none;}

MOBI (lotto-mobi.css):

div.title
	{margin:0;
	text-indent:0;
	text-align:center;
	font-size:1.5em;
	font-weight:bold;}

div.chapter
	{margin-top:2em;
	margin-bottom:.5em;
	margin-left:0;
	margin-right:0;
   	padding:0;
	text-align:center;
	text-indent:0;
	font-size:2.1em;
	font-weight:bold;}

div.title_bottom
	{margin-top:0;
	margin-bottom:1em;
	margin-left:0;
	margin-right:0;
	text-indent:0;
	text-align:center;
	font-size:1.5em;
	font-weight:bold;}

div.copycenter
	{margin:0;
	text-indent:0;
	text-align:center;
	font-weight:normal;}

div.dots
	{margin:0;
	color:#909090;
	text-indent:0;
	text-align:center;}

div.otherdots
	{margin-top:0;
	margin-bottom:1em;
	margin-left:0;
	margin-right:0;
	color:#909090;
	text-indent:0;
	text-align:center;}

div.article
	{page-break-before:always;
	margin:0 2em 0 2em;
	padding:1em 1em 0 1em;}

p
	{margin:0;
	text-align:justify;
	text-indent:1.3em;}

p.firstpara
	{margin-top:1em;
	margin-bottom:0;
	margin-left:0;
	margin-right:0;
	text-align:justify;
	text-indent:0;}

p.top-para
	{margin-top:1em;
	margin-bottom:.5em;
	margin-left:0;
	margin-right:0;
	text-align:justify;
	text-indent:0;}

p.para
	{margin-top:0;
	margin-bottom:.5em;
	margin-left:0;
	margin-right:0;
	text-align:justify;
	text-indent:0;}

p.top-article
	{margin-top:1em;
	margin-bottom:.5em;
	margin-left:0;
	margin-right:0;
	text-align:left;
	text-indent:0;
	font-size:1.1em;}

p.article
	{margin-top:0;
	margin-bottom:.5em;
	margin-left:0;
	margin-right:0;
	text-align:left;
	text-indent:0;
	font-size:.9em;}

p.scenebreak
	{margin:0;
	text-align:justify;
	text-indent:0;}

p.toc
	{margin:0;
	text-align:center;
	text-indent:0;}

p.image
	{margin:0;
	text-align:center;
	text-indent:0;}

span.bold
	{font-weight:bold;}

span.italic
	{font-style:italic;}

a:link
	{color:blue;
	text-decoration:none;}

Thanks for looking!