With a book recently completed in Scriv 3.0.1 I had no issues compiling to the ePub format. But when I compile to .mobi, I get an error message with the following:
Warning(prcgen):W14001: Hyperlink not resolved: C:\Users\Brax\AppData\Local\Temp\mbp_7E5_A_1B_D_9_19_97_3E64_5438_1\OPS\scrivcmt:\46553C6B-9E69-41C2-93FB-42885E7ADC4E
Warning(prcgen):W14002: Some hyperlinks could not be resolved.
I’ve checked all the hyperlinks in my book and all are in working order. What might I be missing?
Thanks.
PS> Updated to 3.1 and still get the error message.
Possibly not the type of reply you hoped for, but *.mobi has been deprecated and Amazon don’t use it any more, although it has legacy uses in their SendToKindle app, from what I remember.
I never use it any more. If I want to proof something on my Kindle, I change the epub3 file extension to .png and use the STK app, then when I open it on the reader it sees it as an ebook.
If you have some other use for it, looking forward to learning what else it’s still good for.
Thanks, Teriodin. I’m aware that Amazon doesn’t use it anymore, but I still have readers with older Kindles asking for it. Maybe it’s time to move on past .mobi altogether.
Actually, although Amazon no longer accepts mobi files for upload, it appears they’re still sending out some form of mobi files for their books. At least, that’s what I rec’d with the last ebook I ordered from them.
I ran the epub file through Kindle Previewer and did a quality check. It found 4 problem spots and gave me the locations. It appears that with my ‘(Preview)’ links for my other books, the trailing ) still had a defunct link attached to it. I fixed those and re-ran the epub thru Kindle Previewer. No quality issues found. Yet, when I then compile for .mobi, I’m still getting the same error.
The error looks like a stray comment or footnotes that is not being processed properly by the compiler. Would you be willing to send a copy of the project to tech support so that we can take a look at it and fix the bug?
If you’d rather, you could send a stripped down version of the project that only has the paragraphs with comments and footnotes that are broken. So long as the compile settings and all are the same, it doesn’t matter to us whether the rest of the book is there or not, only the part that breaks.
AmberV, thanks for the reply. I tried stripping out the page where Kindle Previewer said it’s breaking and setting it up in its own project with the same compile features. It compiled without a problem, so now I’m trying to figure out what’s different. I unchecked every chapter/section of the book, and one by one added them back to the compilation. I finally found one section which triggered the error, and curiously, it doesn’t even have any obvious hyperlinks. I don’t recall having any hyperlinks in it or its footnotes that I might have removed. Anyway, I copied that to the test project and duplicated the error. I’ll send the test project.
Okay! That might explain why it is malfunctioning then, if there aren’t actually any real footnotes or comments in the section. It could be some other bug left stray hyperlink formatting somehow, and so we’re looking at a remnant of that. This could correlate with dragging the item to a new test project, because when you do that internal links are evaluated for whether they would remain relevant, and if they aren’t, they are stripped out.
So that approach might serve as a way of fixing this problem on your end. Just drag the sections throwing errors into a blank project, then drag them back and set the originals aside, outside of the Draft. Alternatively you could cut the text entirely and then use Paste and Match Style to paste as plain-text, which will remove any hidden or broken links naturally.
Which method to use depends on whether you have lots of formatting, versus lots of inspector feature usage on the items. If you use lots of both and either workaround would mean some labour—I guess it’s a toss up.
My bad. In my mind I’m thinking of footnotes like in a printed book and of hyperlinks as links to the web and not to footnotes. But, in an ebook, hyperlinks would also link to footnotes. .
Anyway, yes, there are three footnotes in this section. When I cut and pasted it into a separate project, it didn’t fix the problem. I’ve sent that project file to Astrid. In the meantime, I’m going to remove each of those footnotes in this section, and re-do them to see if that fixes the problem
Oh, and my bad as well, I didn’t explain that very well—since in Scrivener if you use comments and footnotes in the sidebar, then they will actually technically be links in the editor. They are just special links that are designed to load a particular piece of interface. The scrivcmt://1E2F591C-8605-409C-85EA-8EA7C4815678 bit that you see is the trace of that link that somehow got left behind.
But yes, footnotes are also just circular links in ebooks as well.
At any rate I just got the test project forwarded to me, so I’ll take a look at it. Thanks!
Okay, It appears the third footnote is the problem. I removed each footnote one at a time, copied them into Word, and recompiled the project each time. The error persisted until I removed the third footnote. I then closed down Scrivener, reopened it, and added each footnote back one at a time, recompiling each time. No error until I added that third footnote back. It was copied from Word and pasted into the footnote. Can’t say as I see any specific problem in the footnote’s text.
Great, that will make my job easier in finding which one is the culprit. My wild guess is that there is some weird Word formatting that our RTF parser doesn’t know how to handle, and it gave up, which resulted in it leaving behind nothing but the broken link in the output. But we’ll see!
For the meanwhile I’d advise retyping in the problematic footnote from scratch.
That’s the same type of problem as before. Since it is ePub though, it is a lot easier to find where it is as you can open it up in an editor like Sigil, and find exactly what line it is talking about, and trace it back to the source.
I downloaded Sigil and went hunting through 'line 11’s. Naturally, in the footnotes, ALL of the footnotes are in line 11. And when I got to the troublemaker footnote, here’s what I found:
DuRand, JA and Manikam, T., “The 144,000 Undefiled Levites of Revelation 14:1-5 and the link to the defiled watchers of 1 Enoch 1-****36.", Ekklesiastikos Pharos 94.1, 2012, pg. 123-136.
Needless to say, that scrivcmt: between 1- and 36 shouldn’t be there. Don’t know if that helps you.
Okay, I can clearly see the nature of the problem, and have an idea of how it might have come about. Firstly, is it possible for there to be footnotes within footnotes in Word? If so that might explain it—but I can reproduce the creation of the problem in Scrivener as well, by copying some text with a linked footnote in the text, and then pasting that into a new footnote. The link to the original footnote is not removed, but is rendered invisible until you compile. So that’s something we need to fix.
In the meanwhile, if you come across this problem again, here are some tips for much more efficiently solving validation problems:
Download and install the ePubCheck plugin for Sigil. ePubCheck all on its own is invaluable if you intend to get into ebook publishing, because as you’ve seen, the error reporting in readers and such can be extremely useless. “Line 11” left you wasting who knows how long trying to find the file, where as ePub check will tell you precisely, down to the letter of the line, where the problem is. Better yet, when integrated with Sigil, the error report (run the checker on your open .epub file via the Plugins menu) will display each problem as a line in a report that you can double-click on that jumps you straight to the spot.
That’s my bad. ePubCheck plugin used to come preinstalled in Sigil and was part of the regular validation check. But it seems now it’s a separate thing.
Okay, say you don’t want to install plugins though—you can still often find problems based upon the text given in the error report. For example, you could have searched the whole ebook for “scrivcmt” rather than looking for it by hand. Just press Ctrl+F and make sure the “Mode” switch along the bottom is set to “All HTML Files” in the middle.
All right, so that should help you find the problem more efficiently. Once you know where it is, to fix it in Scrivener:
In the main editor, select the problematic footnote marker, or a bit of text around it as well.
Use the Edit ▸ Transformations ▸ Convert Inspector Footnotes to Inline Footnotes.
The bad link should now be plainly visible. You won’t be able to delete it normally because it is a bad link. Just select a bit before and after it and retype that bit.
Select the entire inline footnote, and use the Transformations menu to convert it back to an inspector footnote.
It’s a few steps, but that should be easier than retyping in the whole thing—and you could do that in the inspector footnote as well if you know exactly where it is too. But now that you know how it got to be that way you can watch out for accidentally pasting nested footnotes and avoid the problem before it creates errors.
Thanks, Amber. I was able to correct my issue by retyping the one footnote, as you had suggested earlier. Re: pasting from Word, I don’t use Word when writing my books until the very end where I use it to check spelling and grammar and to fine-tune the format before sending it to a printer. So, all of my footnotes were originally typed in, which means cutting and pasting from Word might not be the real issue here. None were cut and paste. I only did that while troubleshooting this problem in an effort to save myself the time of retyping them. I typically write fiction, so footnotes aren’t an issue. My one other non-fiction book was done with Scriv 1, and I had no problems with it. Glad this helped pinpoint a bug to fix in Scriv 3.1.
