Tutorial - How to Create a MobiPocket eBook

[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

[tompe]

I understand you practical viewpoint. I just think that you should not support secret or proprietary format by using them if you can aviod it. That might put some pressure on companies to release details about their format.

And people putting books on MobilRead should definitely avoid to use the high compression format.

[cmbs]

Originally Posted by DMcCunney

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

I use high compression. The files are perfectly readable on the desktop reader and my cybook. Nobody has said anything about not being able to read the files I've posted. I will continue to use high compression, I don't see any reason to have larger files than necessary, I prefer them small as I can get them.

[cmbs]

I just don't feel obligated to provide you with something you can take apart, nor do I think anyone else is obligated to do so. There's nothing wrong with doing so, but at the same time, it's not obligatory.

Instead of complaining you can't take it apart, maybe you could have the attitude of being thankful for what someone did create and share.

[DMcCunney]

Originally Posted by cmbs

I just don't feel obligated to provide you with something you can take apart, nor do I think anyone else is obligated to do so. There's nothing wrong with doing so, but at the same time, it's not obligatory.

He does have an objection I consider valid: the FBReader ebook viewer displays Mobi documents, but can't handle the high compression variant. FBReader runs on an assortment of things MobiReader doesn't: http://www.fbreader.org/downloads.php

While I prefer Plucker for my own use, Plucker is largely PalmOS specific. (There is a product called Vade Mecum that reads Plucker files on PocketPCs, and FBReader reads Plucker files, too.)

I'm experimenting with MobiPocket because it seems to be the most broadly supported format. If I'm going to create ebooks for others to read, I want to make them available to the widest possible audience.
______
Dennis

[Jiiri]

Originally Posted by cmbs

I just don't feel obligated to provide you with something you can take apart, nor do I think anyone else is obligated to do so. There's nothing wrong with doing so, but at the same time, it's not obligatory.

Instead of complaining you can't take it apart, maybe you could have the attitude of being thankful for what someone did create and share.

It is disingenuous to take what I or anyone else in this thread has written as 'complaining you can't take it apart.'

I do prefer to be able to re-format some things, and I said so in polite, friendly terms. This response is a little excessive for the discussion we're having, in my opinion, and is a little upsetting - I feel like the tone of the thread has been constructive. Responding in harsh tones is a great way to discourage new members like myself from posting their thoughts.

Jiiri

[cmbs]

Dennis, here is a suggestion for you. Why not just upload a high compression and a standard compression version, put them in the same post so people can download whichever one they want.

You can also do like most people who post books in this forum do- make multiple file types and post in all the mobile read ebook forums.

[DMcCunney]

Originally Posted by cmbs

Dennis, here is a suggestion for you. Why not just upload a high compression and a standard compression version, put them in the same post so people can download whichever one they want.

I may do just that, once I have stuff ready.

You can also do like most people who post books in this forum do- make multiple file types and post in all the mobile read ebook forums.

Mobi first, since I have devices that read that. I have no objection to creating other formats if the tools are available and I can use the same source files, but since I don't have those devices, it would be hard for me to test my work.
______
Dennis

[HarryT]

The free Sony "Connect" software (or whatever it's called these days) contains a well-nigh perfect emulation of a Sony Reader and allows you to read Reader books on the PC. It's what I use to test all my Sony Reader format books before posting.

[tompe]

Just to clarify. With a file using high compression you get directly the following disadvantages:

• FBReader cannot read the file so you cannot read the book on Linux machines like Nokia N770, N800, N810 or on Asus EEC or on OLPC computers.
  
• Some people convert prc files to im files. That will not be possible.
  
• You cannot convert the prc file to a file readable on a Sony Reader

So if your goal is to have many people read the book you should not post the book in high compressin format. If that is not your goal than I assume the points above does not matter.

[DMcCunney]

Originally Posted by HarryT

The free Sony "Connect" software (or whatever it's called these days) contains a well-nigh perfect emulation of a Sony Reader and allows you to read Reader books on the PC. It's what I use to test all my Sony Reader format books before posting.

Thanks, Harry. Grabbed it and tried it on a book posted here. Sony's site made finding it a bit of a chore, however.

I'll worry about mastering Book Designer and Mobi Creator first, however.
______
Dennis