I am getting an odd error in one of my ebooks for Kindle. I call it “odd” because it happens on only one of the Kindle devices, the Paperwhite, from what I can determine. I’ve tried the ebook on the Kindle app for PC, Mac, iPhone / iPad (IOS), and Droid X (Android). I also tried it on a Kindle HDX, and on the Kindle device simulator and previewer. The error didn’t show on any of them, only on the Paperwhite. I haven’t tried it on any other e-Ink devices.
Anyway, the error I get is for footnotes (all of them), in the footnote page. It says “ERR: Undefined prefix: mbp1.” and then it lists the content of the footnote as normal. Linking back and forth from the text to the footnote works fine.
I’m using the latest version of Scrivener for Mac to create the mobi file that I upload to Amazon.
Any ideas about why this is happening? Or why it’s just for this one device? The device is new, and I don’t know if the firmware has been updated (or needs to be) to the latest version. I know with my HDX, I had to update it when I first got it.
I did check in the Kindle forums, and there was nothing in there about this, so I figured I’d try here.
The string ‘mbp1’ isn’t something I’m familiar with, though there may be some feature that triggers that in the book, that I didn’t try. What I would recommend is enabling the source file export option in the KindleGen pane so that you can better see what is going on at the code level of the e-book. If you load that footnotes.xhtml file in a plain-text editor like TextWranger, and search for “mbp1” could you copy and paste that and maybe a couple of lines around it into a response?
The mbp tag is an old one in the Kindle universe. I suspect it goes back to mobi days, whence the ‘mb’ derives. For example, in the old days, crafting a Kindle edition by hand in a text editor, you would insert a mbp:pagebreak tag (surrounded by angle brackets of course) to force a page break.
Maybe this is now deprecated (Amazon seems to prefer CSS pagebreak attributes now) and the newer devices use the new version of the kindle file format (8) but the pagewhite kindle is still using the azw or v 7 version that kindlegen creates (I think both versions are created and zipped up together) … and this mbp:1 is not the right code for those old formats, or something.
Oh and I just remembered that the mobi was actually mobipocket, so that might well be the p in mbp.
Since this all goes back a ways, I suggest your best bet is to ask around on the Kindle forum. Who knows, somebody from the Kindle team might even post a reply. If you get the info there, post back here – it might be that there is something about the way the footnotes are being generated that is a problem.
I never used footnotes, so I have no info on how mobipocket coded for them.
Ah, true there are some old MobiPocket codes for breaks, however we don’t make use of them. Sections are generated as separate XHTML files rather than as longer files with break codes, and listed in the OPF as resources. This is what establishes a “page break”. But you are right, that would be mbp:pagebreak/, not mbp1, but without seeing the actual source of the code that is generating the error it is hard to say what is going on.
Footnotes are just formatted text in HTML, Scrivener creates cross-links between the footnote marker and a return link from the reference number back to the spot of the marker, and that’s about it. Here is an example footnote:
<p class="p2"><a id="fn2"></a><a href="body.xhtml#fn2">2.</a> The content of the footnote.</p>
I never looked at the source file before… interesting.
I seem to be getting a lot of errors in XML… here’s one:
XML Parsing Error: prefix not bound to a namespace Location: file:///Users/dkilcrease/Documents/Scrivener%20Compiles/CSandPMTest.mobi/CSandPMTest_source/body2.xhtml Line Number 16, Column 110:
The best laid plans of mice and men often go awrymbp:nu1.
The “mbp:nu1” is suspicious… could that be resolving to “mbp1” and causing the error?
OK, I looked mbp:nu up, and that is a Mobipocket command, to force nonunderlined text. is for superscripts. I thought maybe the string I quoted was being interpreted somehow as a text concatenation operation. Guess not.
The error I included was from the body text, where the sentence which is footnoted appears. But, the footnote itself has this in it:
XML Parsing Error: prefix not bound to a namespace Location: file:///Users/dkilcrease/Documents/Scrivener%20Compiles/CSandPMTest.mobi/CSandPMTest_source/footnotes.xhtml Line Number 15, Column 57:
mbp:nu1. The original Scottish version of this is somewhat less comprehensible to today’s contemporary English speaker, but is still quite lyrical:
This is a little different, and is where the error is actually occurring. I go back to the mbp:nu command, which is followed this time by “1.” instead of just “1” - i.e., the 1 is followed by a period.
Also, I don’t know if this is a clue or not, but all the footnote numbers on the footnote pages are underlined, but the text isn’t.
And, one more clue… the log file has lots of these WARNINGS:
Warning(inputpreprocessor):W29004: Forcefully closed opened Tag: mbp:nu
in file: /private/var/folders/v2/kc8t1hdn5y7fv74m3x90d0rw0000gn/T/com.literatureandlatte.scrivener2/EBOOK_TEMP/CSandPMTest/contents.xhtml line: 0000016
Ah ha, that’s the setting that I didn’t try: HTML Settings, “Underline links” disabled. In that case, Scrivener will insert the mbp:nu tag (which, yes, is invalid XML but for the purposes of the Mobi format that should be okay, but perhaps it no longer is with KF8-leaning devices).
So the easiest option would be to disable that option and have underscoring in the e-book for links. From what I can tell, the modern Kindle readers do not respect this code anyway—probably for usability reasons as without it there is no indicator that a link exists (though I do agree that for footnote markers it is a touch redundant).
Checking the underscoring option seems to have fixed the error messages in both the html and log. I’ll try this on the Paperwhite and see what happens, too.
All I can surmise is that there is some old code in the Paperwhite, which makes some sense because it’s an e-Ink device and probably uses an older code base than the HDX.
Thanks, I’ll do some more tests a few different devices and see if we need to revise the usage of this code. I think this is a relatively new problem, perhaps it came up in recent firmware update. It’s the first I’ve heard of it anyway.
You know, now that I think about this, I would believe that the e-Ink devices are really just follow-on implementations of the original Kindle, which had it own operating system. But the HDX is based on Android, not the older OS. And of course, the Mac and PC apps are based on something entirely different. So maybe this problem would occur on any of the non-Android Kindles.
I recompiled my book with the “underline links” option checked, and tried it on the Paperwhite, and it worked fine with no errors.
Thanks for the help, Amber!
Now, speaking of footnotes… it sure would be great to be able to be able to insert some white space between them to improve readability… and having them pop up on the page you’re reading instead of linking to a separate index of footnotes in the back of the book would be great, too. But, I digress.
That’s one advantage of using the source file compile option. You have access to every nitty-gritty detail that goes into making the book, and thus full control over the stylesheets. There is no way we could provide easy point-and-click options for everything anyone might wish to do. Well, we could, but then the compiler would look like a nuclear power plant control room.
I don’t believe that implementation exists yet for e-readers, at least for Kindle. They probably want to avoid confusing footnotes with your own annotations, which already look a bit like footnotes and pop-up where you are.
Actually, it does exist. That’s how the Paperwhite does it now. If I could figure out how to include a small image, I’d show you. It surprised me when I saw it, too.
In fact, my Paperwhite just rebooted itself and it looks like they have pushed out a rather major update. So far we have deduced they have removed support for the MobiPocket mbp:nu tag, and inline footnotes are now implemented as you say—in fact in my testing you don’t need to do anything special at all to have them. I just compiled a stock test e-book with a few footnotes in and they are somehow picked up and recognised as footnotes, displaying in an overlay when you tap on them.
Huh, lots of new stuff. Looks like a pretty exciting update over-all. We’ll have to dig into this.
