Go to beginning/start - solved at last

[Tugger]

Is it easy for you to build a Calibre plugin version? I want to try it but don't really want to get into installing Python etc. I will be able to try it on several books that manifest the problem in different ways, as well as my test file. Thanks.

[DiapDealer]

Easy is pretty relative.

It would probably be "easy," but creating any interface plugin for calibre tends to become quite involved. At this point, I'm thinking it's probably not worth the effort for this small bit of functionality alone. Until such time as this functionality becomes incorporated into the "split" feature of MobiUnpack's core code, I'm afraid the stand-alone script will have to suffice. Sorry.

Anybody else is free to take up the cause, though!

[Tugger]

Ok, please can I clarify what I need to do.

1. Start by making my revised .mobi file. Use the existing MobiUnpack and edit the extracted source, fixing the font problem and adding the code for the start postion. Drop the opf onto KP and I have my revised .mobi file.

2. Having installed Python (from where?), run the script, point it at my revised .mobi file, creating a fixed version.

3. Test the fixed version on the device.

4. If it is OK, upload the revised unfixed file to KDP.

And a question. If the fixed file is put on a device where it didn't need to be fixed, e.g. the Touch, does it work OK or did it become broken by being fixed?

Finally, if one uploaded the fixed file to KDP what would happen?

[pdurrant]

Originally Posted by Tugger

And a question. If the fixed file is put on a device where it didn't need to be fixed, e.g. the Touch, does it work OK or did it become broken by being fixed?

Finally, if one uploaded the fixed file to KDP what would happen?

No idea.
No idea.

When you find out, let us know!

[Tugger]

Please can you confirm that my steps 1-4 are correct.

Do I want to install Python 2.7 or 3.3?

[Doitsu]

Originally Posted by Tugger

Please can you confirm that my steps 1-4 are correct.

That depends on your source files. I'd create an epub with Sigl first, though, and skip the unpack part unless you need to create a highly optimized Mobi7 file for older Kindles and other Mobi compatible eBook readers.

Originally Posted by Tugger

Do I want to install Python 2.7 or 3.3?

ActivePython 2.7

[Tugger]

I did the following after installing python and working out how to run the latest unpack script.

Please can you confirm that this is the correct procedure one should now follow?

1. Start with my .mobi from the InDesign plugin.
2. Unpack it using the normal Calibre version of the plugin.
3. Edit to fix the font problem.
4. Edit to put in the line in the opf and an anchor before the title of Chapter 1.
5. Drop opf on Previewer.
6. Check file in previewer - all OK, starts at Chapter 1.
7. Copy to device. It starts incorrectly at the TOC.

All as expected. Now to test the start position on device:

8. Take the .mobi we were just testing and split it using the new unpack.
9. Take the .azw3 and load into Calibre.
10. Test it in Previewer. All correct.
11. Test it in the device. It works correctly.

In step 8 I did get one error message about metadata which I assume is irrelevant:

Processing K8 format Ebook ...
Warning: Unknown metadata with id 534 found
Unpack raw markup language
Unpacking images, resources, fonts, etc
Write K8 ncx
Building proper xhtml for each file
Write opf
Completed

So if this was a real book I would then take the mobi made in step 7 and upload it to KDP?

I've attached the test .azw3 file so perhaps someone can try it on different Kindle devices, i.e. Touch and Fire. I've had to change the extension from .azw3 to .doc - just rename it back.

[pdurrant]

Originally Posted by Tugger

8. Take the .mobi we were just testing and split it using the new unpack.
9. Take the .azw3 and load into Calibre.

Using unpack is, perhaps, overkill for what you're testing. You could just use my 'fixing' script from this post, now you have python installed.

But whichever script you use, you can now do the testing you wanted to do.

And yes, upload the file from step 7, not one that's been messed around with by my script or mobiunpack.

[Doitsu]

Originally Posted by Tugger

1. Start with my .mobi from the InDesign plugin

It might be easier if you generated .ePubs with InDesign. KindleGen can compile them and if you rename them to .zip, you can navigate them with Windows Explorer and replace files. (Don't unzip them, though.)
Exporting ePubs might also solve your unspecified font problem, and, depending on the InDesign version that you have, you might even be able to define the Go to Beginning anchor and the corresponding guide item directly in InDesign.

[Tugger]

Originally Posted by Doitsu

It might be easier if you generated .ePubs with InDesign. KindleGen can compile them and if you rename them to .zip, you can navigate them with Windows Explorer and replace files. (Don't unzip them, though.)
Exporting ePubs might also solve your unspecified font problem, and, depending on the InDesign version that you have, you might even be able to define the Go to Beginning anchor and the corresponding guide item directly in InDesign.

The font problem is described here:
http://www.mobileread.com/forums/sho...d.php?t=191385
I don't know if the ePub would have the same problem. InDesign obviously has to have font sizes in pixels. Does the export to ePub keep that or convert to ems? The Amazon export creeates a CSS file with pixels.

I have assumed perhaps wrongly that Amazon's Kindle export would be better, otherwise why did they bother to develop it. It does seem very clever with TOCs and their styles, allowing a quite different TOC design for the export. It is still in beta.

Can one really set an anchor for the start that works with ePub export? Is that true? How - or where - is this documented? (I'm using the latest version).

Apart from the font bug and the start problem (both now solved) it all works very well. I have books with lots of chapters, footnotes, hyperlinks within the book, images. And it only takes seconds to import an RTF and then enhance it.

[DiapDealer]

Originally Posted by Doitsu

It might be easier if you generated .ePubs with InDesign. KindleGen can compile them and if you rename them to .zip, you can navigate them with Windows Explorer and replace files. (Don't unzip them, though.)
Exporting ePubs might also solve your unspecified font problem, and, depending on the InDesign version that you have, you might even be able to define the Go to Beginning anchor and the corresponding guide item directly in InDesign.

In this instance, I know why Tugger is doing it the way he/she is. And it's a valid reason. Creating an ePub with InDesign is going to result in an ePub that doesn't have the special media-queries already in place that allow you to tweak certain aspects of the mobi format and the KF8 format independently. He would have to know how to manually add the correct media queries to the epub to fine-tune how kindlegen builds the two halves of the hybrid file before feeding it to kindlegen.

By using the InDesign Amazon plugin, those media-queries are created for him, and are already in the source portion of the generated mobi. All that remains to be done is to unzip that source and tweak—rather than trying to create those media-query sections—before re-feeding it to Kindlegen.

An ePub produced by InDesign would probably need even more tweaking before it was in any kind of shape to be considered "good" mobi source-code. This way, at least, the xhtml and css is being created with the mobi format in mind all along. It may not be perfect, but it's a lot farther ahead of the curve than straight-up, InDesign xhtml/css would be without the Amazon plugin.

[Doitsu]

I didn't know that the InDesign Kindle plugin adds media queries to the .html code. In this case it really doesn't make sense to create an ePub first.

[Tugger]

Originally Posted by NiLuJe

@pdurrant: Here we go!

File Type: zip Mobi_Unpack_v054b.zip (47.2 KB, 7 views)
File Type: txt mobi_unpack_startoffset_kg25-v3.patch.txt (6.4 KB, 3 views)

To split the .mobi to create the test file to load on the K3 I'm currently using the file you uploaded in message 53, v054b.

You also uploaded a patch.txt file which I have not downloaded. I assume I don't need it??

(PS to @diapDealer: He.)

[DiapDealer]

Originally Posted by Tugger

(PS to @diapDealer: He.)

That's the impression I got, but I didn't want to appear presumptuous.

[NiLuJe]

@Tugger: Nope, you don't need the patch, that was for the dev/curious, to see the changes at a glance without having to run a diff manually .