Hooray, solved!
Sorry, it took so long to get back and post here; I actually solved this fairly quickly, but I had several other things I had to handle.
The root of the problem was in my OPF file. The <dc:rights> tag contained a copyright that was several paragraphs (a tad unnecessary, but there you are). InDesign had inserted "Line Separator" and "Paragraph Separator" characters at the end of each line, which are invisible in my chosen text editor, Sublime. (They don't even act like newlines, so the text ran together, which could have been an indicator that there was something wrong.)
These two Unicode characters, U+2028 and U+2029, are somewhat infamous in the Javascript/JSON realm. Googling them reveals
this post as one of the top hits, which says:
Quote:
Basically if my JSON strings contains a U+2028 character (Unicode line separator) or U+2029 character (Unicode paragraph separator) then this is perfectly valid JSON. However when using JSONP the JSON gets executed as JavaScript and no string in JavaScript can contain a literal U+2028 or a U+2029 as it will break the JavaScript.
...
Essentially if these characters were inside strings in my JSONP data being sent to the client this would throw a line or paragraph break into the string which would break the JavaScript and stop it executing.
|
So when azkcreator converts the KF8 file into the AZK (which contains blobs of JSON) you are fine, but when K4iOS uses Javascript to convert the JSON blobs into a KCR, things break down. Specifically, in my case, the OPF file did not process/transform correctly, and the book would not open.
I added a Regex Replace function to my processing scripts that looks for those two characters and removes them from any files. After this change, I was able to create the AZK, load it into K4iOS, and the book opened fine.
Otherwise:
Quote:
Originally Posted by Hitch
You all know I'm not coder, just a poor bookmaker. But in terms of troubleshooting, using fonts, for the purposes of testing an AZK, is worthless, as K4iOS is a KF7 reader.
|
Hm, are you sure that K4iOS is a KF7 reader? I mean, I'm sure that you'd know better than I, but when I side-load my book via AZK, the fonts show up just fine. Can you go into detail?
Quote:
Originally Posted by Hitch
Speaking of which, for you, however: have you tried loading the same source file at the KDP, and seeing if the post-build MOBI (Step 7, I understand it is now) works on your iPad? Just as a comparative test?
|
I actually did load the book up through Amazon, purchased it, and downloaded it to my device--and it worked fine. I suppose that in the cloud, Amazon is not using Javascript to do their conversions.
But at least now I can sideload to do quality checks, though.
(Did I understand your question correctly? I'm not precisely sure what the "post-build MOBI" is, or what Step 7 is. I didn't personally load the file up onto Amazon, so if you're referring to the KDP loading process, that would be why I'm drawing a blank.)
Anyway, my final question would be on your statement that K4iOS is a KF7 reader. If it's a KF7 reader, why does my sideloaded book (via AZK, which Amazon seems to think is the right way) show my embedded fonts? Do I need to investigate more on any differences between sideloading AZK and going via Amazon's cloud?