How many mobi readers vs. kf8?

[Hitch]

Originally Posted by Doitsu

I found it at the bottom of the main index.php page:

The full path is:

http://www.booknook.biz/index.php/our-services/348-about-us

Unfortunately, the contact link on the same page is also broken:

http://www.booknook.biz/index.php/faux-contact

THANK YOU.

You're absolutely right. I created those little suckers, and somehow hard-coded those links in, (relatively, of course, but using the item ID, etc.) before we did the SEO optimization. THANKS, going (dashing, one might say) over there right now to fix.

(Fixed, thanks: my ponderment is, why didn't Joomla update those links, in those wee modules, when the OTHERS did? Hmph. Bloody hell. Although, personally, I think that "faux-contact" was a CLUE.)

Hitch

[mattmc]

Originally Posted by Doitsu

However, based on mattmc's K4iOS, AZK, The Latest post it looks like Amazon delivers a file format to K4iOS that is very close to the format that AZKCreator.exe generates.

I asked mattmc to chime in on this, however, since he hasn't visited in MR in weeks, we might not get an answer.

Perhaps it's not so bad that I play necromancer on this thread--it's only been dead three weeks or so. Not even enough time for rigor mortis to set in!

Sorry for my absence, Doitsu. I actually still have some more comments to put in that other thread...I'll get to that.

On the current topic, this is actually an important subject for me right now. I do wish that Amazon provided figures for device & firmware versions on the market, at least in terms of what's accessing their stores. Apple provides this data to iOS developers, in terms of who is using what operating system.

Anyway, when I started off in eBook development, I specifically purchased a Kindle Keyboard to preview old KF7 files...but I've begun to suspect that it's a K3, and started looking around for a used DX, just so I can be totally sure about what I'm seeing. (I think I'd heard from @Hitch that her company employs DXs for KF7 checking...maybe not.)

On the subject of the Kindle Apps, I can't speak for KDroid or KCloud, but I have investimagated K4iOS some, so there's a few things I do know:

First, to be clear: AZK is an intermediate file format, between what comes out of Kindlegen (compound KF7/KF8), and what K4iOS actually reads. Based on my testing, when you give an AZK file to K4iOS, it converts it into a .KCR file. So it's just a bridge.

Secondly: Some eBooks that are delivered from Amazon to K4iOS are KCR, while others are AZW. I'm not sure why.

Thirdly: Given that KF7 is a file format, specifically a binary mobipocket database format, K4iOS is definitively not a "KF7 reader", for the simple reason that it reads KCR files as well. I'm not sure if there's a way to tell if the AZW files that I saw in there were KF7 or KF8 or what, but if they are KF7, maybe K4iOS can read both KF7 and KCR?...

Fourthly, if we assume that K4iOS can read both KF7 and KCR, it's possible that what Hitch has seen with K4iOS in terms of formatting weirdness could be related to the KF7 format rather than the K4iOS rendering engine. What you get in the screen is the product of an interesting dance between the content in the file and the rendering engine, and K4iOS is most certainly a different rendering engine than K1, K2, and DX.

Fifthly, and as an irritating note: IIRC, I did see some minor differences between the KCR files downloaded from Amazon, and the KCR that was created by sideloading an AZK file. That might account for Hitch's perception that AZK -> K4iOS != KDP -> K4iOS. Frankly, I wouldn't be surprised if Amazon's content delivery backend handled things different than AZKCreator and/or K4iOS's AZK -> KCR converter. They're just a large enough company with enough on their hands to not handle delicate things like this well.

Anyway, my summary concept would be that the KApps are not "KF7", but are perhaps not KF8 either. Perhaps they are just...KCR. (Hooray, perhaps the most untested file format!)

=====

P.S.:
I did claim in another thread that fonts carried through from EPUB -> KF8 -> AZK -> K4iOS, refuting Hitch's assertion that K4iOS was KF7-only, upon which she asked for screenshots, and I never delivered. So I will try to post those here and/or there.

P.P.S.:
Most of my testing and viewing into the underbelly of K4iOS has occurred on an iPad 1, running iOS 5.1.1, with K4iOS 3.9.2.

[Hitch]

My request, just to clarify, is for screenshots displaying embedded fonts carrying through on a PUBLISHED book, on K4iOS. Not a side-loaded book or a previewed book, an Indy-pubbed (so, uploaded via the KDP) published book.

Updated to add: the lastest KPG's (Kindle Publishing Guidelines) did confirm info on using media queries, generally, for the iOS, which is GREAT.

Updated to add, 2: we're looking at some recently-pubbed books from some clients of ours, that have embedded fonts. Will update if needed.

ETA, 3: we don't know when this started, but we just downloaded a book, to a different iPad, that we'd downloaded when this thread started, and now, it has the embedded sans font in the pullquotes. BUT, this is new. I know for a fact that this wasn't working just a few months ago.

Hitch

[mattmc]

As a note, I did put a thumbnail in the other thread, but it was via AZK, not KDP. Ah well.

Originally Posted by Hitch

We don't know when this started, but we just downloaded a book, to a different iPad, that we'd downloaded when this thread started, and now, it has the embedded sans font in the pullquotes. BUT, this is new. I know for a fact that this wasn't working just a few months ago.

Hitch

Nice. I do wonder what would happen if I took my book through KDP and stuck it in my K4iOS 3.9.2. If the fonts displayed properly, and they weren't for you only a few months ago, it would mean that there had been something broken with Amazon's KDP conversion machinery until recently. Because I certainly haven't updated K4iOS in...a while.

Anyway, I may check that out.

Hitch, is there any sort of centralized repository of information about making eBooks? Being a programmer, it's the kind of thing I might be inclined to throw in a Github repo (a la Kobo Lab's ebook spec). I know there's a Wiki for Mobileread, but it just comes across as unwieldy.

I ask because I'm slowly developing a lot of links, articles, pieces of information, formatting tidbits, compatibility issues, etc. that I'm keeping for myself. Things like "if you put media queries in a style sheet, Nook Color ignores the entire style sheet", or how to CSS night mode in iBooks, or why the "Go To > Table of Contents" button wouldn't work on K2/K3, etc.

I happened to notice your comment about the Voyage 50% image size bug in this thread, and I wouldn't have had any idea about it otherwise. I had almost decided not to buy a Voyage, that it had to be similar enough to the PW2 that I needn't spend the money.

Anyway, maybe the Wiki is the answer, but I find myself dissatisfied.

-Matt

[eschwartz]

Hmm, I don't personally see much difference in using a Wiki vs. markdown -- except that many people can edit a Wiki, but only a collaborator can edit a github repository.

Unless you mean ease of actual editing?

[Hitch]

Originally Posted by mattmc

As a note, I did put a thumbnail in the other thread, but it was via AZK, not KDP. Ah well.

The AZK format's been working for some time. It was the post-publishing books that haven't been dramatically different than MOBI/KF7 for the last few years, and certainly, by way of our testing, which is fairly extensive. AND, moreover, I've discussed this very thing with Amazon's ECR, so I don't think I'm deluded.

Nice. I do wonder what would happen if I took my book through KDP and stuck it in my K4iOS 3.9.2. If the fonts displayed properly, and they weren't for you only a few months ago, it would mean that there had been something broken with Amazon's KDP conversion machinery until recently. Because I certainly haven't updated K4iOS in...a while.

Anyway, I may check that out.

Bear in mind that there is yet another part of the publishing process, called the PW (Publishing Workflow) that happens AFTER you hit "save and publish" that yet alters the book further. For example, setting the SRL (Start Reading Location): that is set in the PW, not before one hits "save and publish." It's one of the reasons it's so elusive to fix. I've seen books that looked good-to-super on the Preview, that didn't, post-publication (back on the iOS issue).

I can also attest that sometime in the last few weeks, divs sized with % started to work, post-PW, the way that they ought to, for K4iOS. That's a pleasant thing. We've been wrangling some pullquotes that needed that to be "perfect" (as if such a thing actually exists in the eBook world) and I'm pleased to say that today, we see that some we tested two weeks ago, that didn't work, ARE working today. Same book, same coding.

Hitch, is there any sort of centralized repository of information about making eBooks? Being a programmer, it's the kind of thing I might be inclined to throw in a Github repo (a la Kobo Lab's ebook spec). I know there's a Wiki for Mobileread, but it just comes across as unwieldy.

I ask because I'm slowly developing a lot of links, articles, pieces of information, formatting tidbits, compatibility issues, etc. that I'm keeping for myself. Things like "if you put media queries in a style sheet, Nook Color ignores the entire style sheet", or how to CSS night mode in iBooks, or why the "Go To > Table of Contents" button wouldn't work on K2/K3, etc.

I happened to notice your comment about the Voyage 50% image size bug in this thread, and I wouldn't have had any idea about it otherwise. I had almost decided not to buy a Voyage, that it had to be similar enough to the PW2 that I needn't spend the money.

Anyway, maybe the Wiki is the answer, but I find myself dissatisfied.

-Matt

I don't know of any centralized repository, above and beyond what's here. Liz Castro started her blog way back and sought support for it, and even though a number of us did (support it), it went the way of the dodo, vis-a-vis eBooks. Maybe she just didn't feel that there was enough interesting stuff left to investigate. ;-)

And other than here, everybody else is either a) making their own books, to publish, as Indy Authors/Publishers, and not that interested in a repository, or b) they're like me, with their own shops, and we're more focused on trying to stay ahead of the horrors of the retailers, or those of the clients, than we are on contributing to a repository. Not to mention, speaking for myself, it gets sort of tiring. I mean, there are things (like the SRL) that have changed 3, 4 5 times in fewer years. NCXes, TOC's, and the like--what works one day doesn't the next. It's hard to keep up with, but you have to if you're doing it commercially.

(Sorry--I thought I'd posted this yesterday, and somehow, left the damn browser window up, instead of hitting "send" or "post" or whatever.)

Hitch

[mattmc]

Originally Posted by eschwartz

Hmm, I don't personally see much difference in using a Wiki vs. markdown -- except that many people can edit a Wiki, but only a collaborator can edit a github repository.

Unless you mean ease of actual editing?

Hm, there's just something about a Github repo that seems more lucid than the MobileRead wiki. Maybe because everything is in folders? Hard to put my finger on it.

Interestingly enough, I found that Github repos do come with a wiki automatically, and they can be edited by anyone if you configure it that way.

But yes, I do prefer markdown to markup for editing. The syntax highlighting and various other features of GH-flavored markdown are very tailored towards code, which is what we're dealing with when we talk about the ins and outs of advanced eBook creation. GH is also suitable for holding scripts for processing markup/CSS (maybe nobody else has those, but I do).

Anyway...maybe I'm being elitist, but I'm very tempted.

Originally Posted by Hitch

Bear in mind that there is yet another part of the publishing process, called the PW (Publishing Workflow) that happens AFTER you hit "save and publish" that yet alters the book further. For example, setting the SRL (Start Reading Location): that is set in the PW, not before one hits "save and publish."

I'll admit that, while I have months of eBook coding and testing under my belt, I haven't actually run anything through KDP to date, which means you far outrank me in experience there. I've never even heard of the PW, and my impression on the SRL was that you simply have <reference type="text"/> in your OPF guide, and that's taken care of. Do you have any articles, threads, or on-the-spot wisdom on PW and the SRL that you'd care to share?

Overall, I am glad that K4iOS is shaping up! (Just in time for me...)

Originally Posted by Hitch

I don't know of any centralized repository, above and beyond what's here. Liz Castro started her blog way back and sought support for it, and even though a number of us did (support it), it went the way of the dodo, vis-a-vis eBooks. Maybe she just didn't feel that there was enough interesting stuff left to investigate. ;-)

And other than here, everybody else is either a) making their own books, to publish, as Indy Authors/Publishers, and not that interested in a repository, or b) they're like me, with their own shops, and we're more focused on trying to stay ahead of the horrors of the retailers, or those of the clients, than we are on contributing to a repository. Not to mention, speaking for myself, it gets sort of tiring. I mean, there are things (like the SRL) that have changed 3, 4 5 times in fewer years. NCXes, TOC's, and the like--what works one day doesn't the next. It's hard to keep up with, but you have to if you're doing it commercially.

(Aside: does Liz ever hit up MobileRead? Her blog has helped me out of some tight spots and I really respect her trailblazing ways.)

I definitely get what you mean. It's a bit like, if you do it every day, all the data is in your head, so putting it online is just more effort. To me, there are really three primary sources of information for eBook creators:

1. MobileRead Forums & Wiki
2. Official Guidelines From Companies
3. Random Articles & Forum Threads

...Basically, your best friend is Google.

[DaleDe]

Our wiki is a known repository. It supports wiki syntax and passes through HTML syntax. No, it is not a file system but there is support for categories that can be used similarly with the additional feature of multiple categories for the same page. eProduction also uses our pages. I don't understand the idea of needing folder support since you can easily build a master page and link everything from there. It is a great place for collaborative documentation and specifications, and can be linked easily to a discussion page in this forum.

Dale

[Hitch]

Originally Posted by DaleDe

Our wiki is a known repository. It supports wiki syntax and passes through HTML syntax. No, it is not a file system but there is support for categories that can be used similarly with the additional feature of multiple categories for the same page. eProduction also uses our pages. I don't understand the idea of needing folder support since you can easily build a master page and link everything from there. It is a great place for collaborative documentation and specifications, and can be linked easily to a discussion page in this forum.

Dale

Yes. I tend to agree on this. I've got stuff that has been posted here, Pablo's tutorial is here, Diap and Kevin, etc., all post on the wiki...and while I would never say, "everybody who's anybody posts here," it's kinda sorta true.

Yes, some folks who have been around a while don't (usually commercial producers who don't have any interest in sharing the info, or folks like Liz who, while contributing heavily via her blog, is also selling books on the topic), but...there is an inherent conflict of interest for the people who do this professionally. We can all act like there isn't, but there is, no matter what. So the people who know the most, who learn the most through the daily grind, are the least likely to add to anything, whether it's a wiki or a github repository. I know of at least 5 commercial producers who would never in a billion years contribute here or at KDP Forums, or anyplace else. Fortunately, we have a number of commercial producers here that do contribute, but ALL of us have secret sauce that we don't share. ALL. Whether it's scripts, tricks, knowledge...it just IS. And given the ever-increasing presence of DIY this or that or browser-based systems, etc. (all contributing to author-publishers knowing LESS about what it takes to make the books, not MORE), it's hardly surprising that commercial producers are less likely to "donate" knowledge.

I won't bore everyone here with my own experiences with this, but suffice to say, every commercial producer that's been around for >5 years has had at least one, more likely, several experiences that are VERY off-putting in the "contribute knowledge" arena.

Vis-à-vis Liz:
(mattmc said):

(Aside: does Liz ever hit up MobileRead? Her blog has helped me out of some tight spots and I really respect her trailblazing ways.)

...I think I remember seeing her post here once? Does that sound right, @Dale? She may post in some of the sub-forums I don't inhabit, of course, like the Lounge (I'm almost never there) or some of the author forums (ditto).

...Basically, your best friend is Google.

Myyyyeeeeeeeeeeeeeeeeh, maybe. As with all things, there's a crapload of truly BAD information out there. I've lost track of the number of extremely popular, heavily-cited and linked-to, "Hey, you too can make your own book for Kindle by doing X-Y-Z!" blogs that are utter bollox. That have completely ERRONEOUS information. Fortunately, yes, there is MR. I strongly feel that any "repository" ought to be here, simply because so much of it already is.

FWIW.
Hitch

[Notjohn]

Originally Posted by mattmc

I've never even heard of the PW, and my impression on the SRL was that you simply have <reference type="text"/> in your OPF guide, and that's taken care of.

Yes, it's taken care of, but it doesn't work in any consistent fashion. (I have uploaded a book with the title page labeled as "text" and have it work. But then I found a typo, corrected it, and uploaded it again... And it opened in the middle of the TOC.) The only thing that does seem to work is to include a cover and label THAT "text". But that gives you two covers, which IMHO is a worse outcome.

(I let my books convert on the KDP. Perhaps KindleGen would give a better result?)

There are a couple of threads on MobileReads on this subject.

https://www.mobileread.com/forums/sho....php?t=212660

https://www.mobileread.com/forums/sho...d.php?t=191387

[Hitch]

Originally Posted by Notjohn

Yes, it's taken care of, but it doesn't work in any consistent fashion. (I have uploaded a book with the title page labeled as "text" and have it work. But then I found a typo, corrected it, and uploaded it again... And it opened in the middle of the TOC.) The only thing that does seem to work is to include a cover and label THAT "text". But that gives you two covers, which IMHO is a worse outcome.

(I let my books convert on the KDP. Perhaps KindleGen would give a better result?)

There are a couple of threads on MobileReads on this subject.

https://www.mobileread.com/forums/sho....php?t=212660

https://www.mobileread.com/forums/sho...d.php?t=191387

No. KG does not give you a better result. The infamous, "opens in the middl e of the TOC," (*or more accurately, at the end of the TOC, or last screen thereof) issue is still quite real if you upload a MOBI, or an ePUB. Obviously, I don't have firsthand knowledge of what happens with a Word file.

Hitch

[mattmc]

Originally Posted by Notjohn

There are a couple of threads on MobileReads on this subject.

Thanks! I did try to skim through some of those, but one of those is from 2012, and another from 2013, and there's just pages and pages of stuff.

Do we have a modern TL;DR on this? Is it:

The best you can do is add the <reference type="text" /> entry to your OPF <guide>, but it's basically a crapshoot?

Does this vary on KF7 vs. KF8?

Originally Posted by Hitch

No. KG does not give you a better result. The infamous, "opens in the middl e of the TOC," (*or more accurately, at the end of the TOC, or last screen thereof) issue is still quite real if you upload a MOBI, or an ePUB.

In other words, it doesn't matter if you convert to MOBI via KG, or you let KDP do it; the SRL is modified in the MOBI as part of the PW.

I realize that this may impact a title I am I/P on, because the start location is before the main TOC. What happens if you remove the <reference type="toc"/> from your OPF <guide>? You basically lose the Go To > TOC option in the Kindle Keyboards, but does the SRL still get messed with?

[Notjohn]

Well, as I said, I found that if I included a cover and labeled it text, the book would indeed open there on my Fire HD, which is the only reading device I regularly use. And I did have a TOC (after the cover, natch!).

(But then I also had two covers, sigh.)

@Hitch: yes, I do often get books opening in the middle of the TOC, with the full TOC occupying less than a "page". Say 12 chapter titles plus the heading.

But I don't really mind. I have learned to put nothing in front of the TOC (including sometimes the title page). And I can actually use this to my advantage, where I have some enticing blurbs from earlier reviews: I know the shopper on Amazon will see them in the Look Inside sample (which always opens at the cover) but the buyer won't be forced to page past them on his gadget.

As me old Da used to say: Not a ditch to die in.