Tutorial - How to Create a MobiPocket eBook

[tompe]

Originally Posted by HarryT

The "Guide" items add entries to a navigation menu on MobiPocket Reader, and the CyBook Gen3, and enable navigation icons on the iLiad. The "Table of Contents" and "Start Reading" items are standard ones, but if you don't have them all that happens is that those items don't appear on the navigation menu on the Gen3, and the corresponding buttons remain disabled on the iLiad.

Did you check that you did not get two "Start Reading" in the goto menu on the Cybook? I think I managed to get duplications of one of the entry that is always there when I played around with this a couple of weeks ago.

[HarryT]

I do get two of them, yes . I don't know of any way to avoid that - do you?

[tompe]

Originally Posted by HarryT

I do get two of them, yes . I don't know of any way to avoid that - do you?

No. But as I understood it you can call the action anything you want so maybe just calling it something else might avoid some confusion. Or maybe people will get more confused having two different entries for the same thing.

[HarryT]

Originally Posted by tompe

No. But as I understood it you can call the action anything you want so maybe just calling it something else might avoid some confusion. Or maybe people will get more confused having two different entries for the same thing.

I suppose it's a question of whether it's less confusing to have two identical menu items which do the same thing, or two different menu items which do the same thing. Doesn't really matter either way.

[wallcraft]

Originally Posted by Jiiri

One question, though. When I open any .prc file from this site in BD with the intention of implementing your changes, the photos don't show up. In your tutorial, you started with the html0 file for BD and the photos that that file referenced, but how would I go about taking a .prc file that was already built and implementing those changes after the fact, without the source files? I can open the PRC in BD, but no photos are there.

One option is Mobiperl. There are several ways you could use this, and mobi2mobi may be all you need, but mobi2html should "explode" the .prc file into html and images that can then be imported into BD.

[Jiiri]

Do I have to be a non-moron to use Mobiperl? I'd be interested in trying it out, but I have no programming knowledge or anything. The most I know is some basic HTML. Thanks for the idea, I'll go check it out and see what level of competence is required.

Jiiri

[tompe]

Originally Posted by HarryT

I suppose it's a question of whether it's less confusing to have two identical menu items which do the same thing, or two different menu items which do the same thing. Doesn't really matter either way.

I seem to remember now that in the example book I tested they were not identical. But maybe that was just that book.

[tompe]

Originally Posted by Jiiri

Do I have to be a non-moron to use Mobiperl? I'd be interested in trying it out, but I have no programming knowledge or anything. The most I know is some basic HTML. Thanks for the idea, I'll go check it out and see what level of competence is required.

To use the latest version in Windows you have to be able to install programs and use command promts. I will in a couple of days try to package the latest version as Windows binaries but the Windows binaries will always lag behind the other version if I am doing the packaging.

[wallcraft]

Originally Posted by Jiiri

Do I have to be a non-moron to use Mobiperl? I'd be interested in trying it out, but I have no programming knowledge or anything.

There is now a Windows binary, but it is still a command line program. I have started a new thread: PRC to MOBI which includes some command line usage instructions.

[DMcCunney]

Originally Posted by HarryT

The attached file is a detailed tutorial showing how to create a MobiPocket eBook using the freely available tools of Book Designer and MobiPocket Creator. It starts off with the assumption that you've already created and edited the book in Book Designer, and shows you how to go from the BD book to a properly-formatted MobiPocket book with large images, a functioning "Table of Contents" menu item, and so on.

Comments or suggestions for improvements are of course welcome.

Harry, I read through it and it's clear and concise. Thank you.

Down the road a bit, I may experiment with the command line converter, and see about scripted Mobi file generation.

One question for the group mind, however: MobiPocket Creator offers three compression options: None, Standard, and High.

I played a bit, creating a test Mobi file with each option, and all were handled just fine on my device, which is a Palm OS PDA running v5.3 beta of MobiReader for PalmOS, and by the current 6.1 MobiReader for Windows.

My inclination is to create Mobi documents using High compression, simply because there's no such thing as enough storage space. My question is whether that is known to be supported on all devices that can read Mobi files. Yes, it takes a lot longer to generate Mobi files using High compression, but I don't care. My computer is doing the work.

Comments?
______
Dennis

[tompe]

That is probably the flags:

# -c0: no compression
# -c1: standard DOC compression
# -c2: Mobipocket huffdic compression

I tested MobiPerl on this (mobi2html) and with -c2 it could not explode the file. If -c2 implies an undocumented compression format you should not use it. And that the current version of MobiPerl does not work for these files is a good reason not to use it.

[HarryT]

MobiPocket Creator recommends that "High Compression" should "only be used for very large files such as dictionaries". I always use "Standard Compression" myself.

[DMcCunney]

Originally Posted by HarryT

MobiPocket Creator recommends that "High Compression" should "only be used for very large files such as dictionaries". I always use "Standard Compression" myself.

I read their recommendation, and I know you use Standard. Since High was available, I wondered if anyone knew of platforms where it didn't work.

Tompe has weighed in with the fact that his mobiperl tools can't successfully extract a Mobi file created with it. I haven't looked to see what his perl code is doing, so I don't know why it might fail.

I've tested it here, and High Compression works fine on my PalmOS device, with as gratifying size reduction. Default Mobi compression appears to be Palm DOC compatible, meaning a variant of RLE yielding about 40% compression. High compression looks closer to what I see with Zlib -- zip/gzip compatible, with about 70% compression.

I know what I'm using for Mobi files I create for my own use...
______
Dennis

[tompe]

Originally Posted by DMcCunney

Tompe has weighed in with the fact that his mobiperl tools can't successfully extract a Mobi file created with it. I haven't looked to see what his perl code is doing, so I don't know why it might fail.

I've tested it here, and High Compression works fine on my PalmOS device, with as gratifying size reduction. Default Mobi compression appears to be Palm DOC compatible, meaning a variant of RLE yielding about 40% compression. High compression looks closer to what I see with Zlib -- zip/gzip compatible, with about 70% compression.

Well it fails because the Perl module handling the file cannot unpack a format that I think is not documented. If there is documentation available then the problem is solvable. But if the format is a secret MobiPocket format than I think it should not be used. Secret formats always leads to problems.

[DMcCunney]

Originally Posted by tompe

Well it fails because the Perl module handling the file cannot unpack a format that I think is not documented. If there is documentation available then the problem is solvable. But if the format is a secret MobiPocket format than I think it should not be used. Secret formats always leads to problems.

I have a query in at the MobiPocket forums about whether documentation for their algorithm exists.

Frankly, I'm torn. I understand your concern, but storage space is finite.

Most of my ebooks are in Plucker format, and I always use the High Compression option, which uses a Palm port of ZLib and provides zip/gzip compatible compression instead of the standard Palm "doc" compression.

If I didn't do that, I'd have had to upgrade from a 2GB SD card to a 4GB card long ago for the volume that holds my Plucker documents. (I have about 3,200 Plucker files occupying about 1.5GB on that card.)

Using High Compression in MobiPocket becomes an issue if someone wants to use MobiPerl to manipulate the files because your code can't uncompress them.

I'm mainly concerned that anyone can read a Mobi file I create. The number of folks who might want to use MobiPerl to manipulate them will be a small subset of the total number who might read them.

For stuff I create for myself, I'd likely use High Compression. For stuff I upload elsewhere, it's a quandary, and I'm thinking.
______
Dennis