Is there a tool like Sigil to edit mobi ebooks?

[JSWolf]

Originally Posted by shotsky

The answer for me is that Calibre does not respect class names when it converts. Some class names depict what follows, and Calibre simply blindly renames them calibrexx and you lose the original meaning. That is a no starter for me, and I continue to look for a way to decompile ebooks that does not involve Calibre with its sticky fingers renaming everything.
No explanation about why this is done, just that 'I am not interested in changing it.' That is really too bad, because a number of people use Calibre to get to the source html to work on that, but with classes all renamed, it is difficult if not impossible to know what you are editing.
One example is that I work with cookbooks in mobi/epub format. Before conversion, the html class may say <div class="titlel">. Afterwards, it says <div class="calibre59">.
A cookbook with 100 'pages' has 100 recipes. All the title tags are lost, although the text of the titles is there. The point is that there is no longer a reliable tag remaining with which to automate identification of the titles.
I have found that if you use the debug function, you can get the html as it was inside the ebook before conversion takes place. However, each page is a separate html file, so editing those is nearly impossible, too, unless you can find a way to merge the html files into a single file in the correct order. Not easy, but doable with sufficient effort.

You can use the KindleUnpack plugin to decompile the Mobi and then a text editor to edit it. You would then have to use Kindlegen to make the combo Mobi/AZW3 and then KindleUnpack again to split and then replace with the Mobi only copy. But if you have an ePub, use that as the source and Kindlegen to make an AZW3. You would have to split the combo file to get just the AZW3.

[eschwartz]

Originally Posted by shotsky

The answer for me is that Calibre does not respect class names when it converts. Some class names depict what follows, and Calibre simply blindly renames them calibrexx and you lose the original meaning. That is a no starter for me, and I continue to look for a way to decompile ebooks that does not involve Calibre with its sticky fingers renaming everything.
No explanation about why this is done, just that 'I am not interested in changing it.' That is really too bad, because a number of people use Calibre to get to the source html to work on that, but with classes all renamed, it is difficult if not impossible to know what you are editing.
One example is that I work with cookbooks in mobi/epub format. Before conversion, the html class may say <div class="titlel">. Afterwards, it says <div class="calibre59">.
A cookbook with 100 'pages' has 100 recipes. All the title tags are lost, although the text of the titles is there. The point is that there is no longer a reliable tag remaining with which to automate identification of the titles.
I have found that if you use the debug function, you can get the html as it was inside the ebook before conversion takes place. However, each page is a separate html file, so editing those is nearly impossible, too, unless you can find a way to merge the html files into a single file in the correct order. Not easy, but doable with sufficient effort.

calibre is primarily geared towards the casual user who needs books on their device. Flattening the CSS makes it a lot easier to provide a consistent, effective experience for those people.

That is why we have plugins, like the one JSWolf suggested -- for people who need greater control to get at the innards of the books.

Also why we have an editor that can directly edit the source of AZW3 files.

[Notjohn]

Originally Posted by JSWolf

The best solution is to start with ePub, fix whatever the problem is and then convert that to Mobi.

I know this isn't an option for professional formatters whose clients expect to receive both an epub and a mobi, but since 2012 I've simply been uploading epubs to the Kindle Direct Publishing platform. They convert just fine, and when I download the convert book file for preview, I know that nothing has been lost or altered in the conversion process on the KDP.

(I don't include a cover in the epub, after an incident when that kept resulting in two coverage images in the published book.)

[eschwartz]

Originally Posted by Notjohn

I know this isn't an option for professional formatters whose clients expect to receive both an epub and a mobi, but since 2012 I've simply been uploading epubs to the Kindle Direct Publishing platform. They convert just fine, and when I download the convert book file for preview, I know that nothing has been lost or altered in the conversion process on the KDP.

(I don't include a cover in the epub, after an incident when that kept resulting in two coverage images in the published book.)

You could also use kindlegen/KindlePreviewer yourself, directly.

Why isn't that a suitable option for professional formatters?

[JSWolf]

Originally Posted by Notjohn

I know this isn't an option for professional formatters whose clients expect to receive both an epub and a mobi, but since 2012 I've simply been uploading epubs to the Kindle Direct Publishing platform. They convert just fine, and when I download the convert book file for preview, I know that nothing has been lost or altered in the conversion process on the KDP.

(I don't include a cover in the epub, after an incident when that kept resulting in two coverage images in the published book.)

Actually, most publishers these days create an ePub and use that to generate the Mobi/AZW3. So yes, professionals do use ePub as the source in most cases and that's a fact.

As for the double cover image, there is a way around that. I'd have to experiment to find the exact method to fix things, but you could put in the cover and not specify it for use in the ePub and specify the cover in the guide.

[Hitch]

Originally Posted by eschwartz

You could also use kindlegen/KindlePreviewer yourself, directly.

Why isn't that a suitable option for professional formatters?

eschwartz:

He means, for a company like mine, we can't just hand our clients an ePUB and tell them to upload it at the KDP. They expect a MOBI, as well. {shrug}. It's also true that for some things, there are tweaks that should be made, between an ePUBcheck-compliant ePUB and a MOBI, so...we make our mobis from the final ePUBs, with a tweak or two, to make the outcome precisely what we want.

Hitch

[DiapDealer]

Originally Posted by eschwartz

Also why we have an editor that can directly edit the source of AZW3 files.

What editor is that? Or am I misunderstanding your meaning?

[eschwartz]

Originally Posted by DiapDealer

What editor is that? Or am I misunderstanding your meaning?

Probably --- I'm referring to the fact that calibre editor can directly edit the markup in an AZW3, with no need to convert to an intermediate format (and the attendant css flattening and other conversion relics).

[DiapDealer]

But it doesn't directly edit the markup in an azw3. Sure, it's not doing full-blown conversion, but the raw markup in a binary azw3 file is not standard (x)HTML. There are no filenames, for instance, and the links are offsets, and there's proprietary elements/attributes. Those file names you see in the editor are invented by calibre when it extracts the raw markup and massages the proprietary portions into something that can be easily edited by the user. Then it compiles that back into the kindlebook's proprietary binary database format. You are very much editing an intermediate format.

[Hitch]

Originally Posted by DiapDealer

But it doesn't directly edit the markup in an azw3. Sure, it's not doing full-blown conversion, but the raw markup in a binary azw3 file is not standard (x)HTML. There are no filenames, for instance, and the links are offsets, and there's proprietary elements/attributes. Those file names you see in the editor are invented by calibre when it extracts the raw markup and massages the proprietary portions into something that can be easily edited by the user. Then it compiles that back into the kindlebook's proprietary binary database format. You are very much editing an intermediate format.

Y'know...

When I think about this--and I really don't want to make this about Calibre--I feel as though using a simple ePUB for this purpose is less of an "intermediate" method than using Calibre, for the reasons amply elaborated upon by Diap. What's "intermediate" about an ePUB, all in all? If I make a mobi, and then crack it open, by using an ePUB-->KP or KG, at least what I see when I crank that sucker open is recognizable by me. No weird flattened CSS, (per se) etc. It's the book as I made it--with some "help" from Amazon, of course.

Just sayin'.

Hitch

[kovidgoyal]

Originally Posted by DiapDealer

But it doesn't directly edit the markup in an azw3. Sure, it's not doing full-blown conversion, but the raw markup in a binary azw3 file is not standard (x)HTML. There are no filenames, for instance, and the links are offsets, and there's proprietary elements/attributes. Those file names you see in the editor are invented by calibre when it extracts the raw markup and massages the proprietary portions into something that can be easily edited by the user. Then it compiles that back into the kindlebook's proprietary binary database format. You are very much editing an intermediate format.

Let's apply a bit of reductio ad absurdum to that.

When you edit an epub file you aren't directly editing it either. An EPUB file is really a string of ones and zeros in your computer memory. You really should be editing it with a hex editor. Otherwise you are simply relying on some program, like unzip to convert that string of ones and zeros to a bunch of nice filenames that you can easily edit. Then the zip program compiles all those edited files back into epub's binary database format. Who knows what it's actually doing.

And really, *ones and zeros*. Real men dont use binary. Those ones and zeros are just an abstraction of magnetic particles on your hard disk, you should be using a scanning tunneling microsocope to toggle them individually, otherwise you are using a computer to convert those magnetic particles into ones and zeros for you to edit with a hex editor and then compile those ones and zeros back into magnetic particles.

It's turtles all the way down.

If you want to argue against using calibre's editor to edit azw3 you need to come up with something better than "it's not doing a direct edit". Something like, the editor makes changes to the file that I did not ask it to in the process of converting to/from the azw3 package. Which it does not do.

@Hitch: Why dont you actually try it, first. You will find that when you use the editor to edit an azw3 there will be no "weird flattened css".

[DiapDealer]

Originally Posted by kovidgoyal

If you want to argue against using calibre's editor to edit azw3 you need to come up with something better than "it's not doing a direct edit". Something like, the editor makes changes to the file that I did not ask it to in the process of converting to/from the azw3 package. Which it does not.

Oh, but I DON'T want to argue against (or for) using calibre's editor to edit azw3. Sorry if it seemed a was making a value judgment of some kind. I really wasn't. "Directly edit the source of an AZW3" simply struck my pedantic bone is all. I can see how it might seem like I was picking a side in the "calibre: yea or nay?" discussion, now that I re-read the entire thread, though. Guess I should have shouted "Point of Order" first.

[kovidgoyal]

Well if it is pedantry that we're indulging in here -- when you unzip an epub and edit it using a text editor, you aren't directly editing the file in the epub either.

Your text editor will convert the raw bytes of the file into a set of characters based on what it thinks the character encoding of the file you are editing is. It is these characters that you will edit (unless you are using a hex editor). There is no guarantee that the character encoding your editor uses will be the same as the character encoding any given epub viewer will use for the same file.

Not to mention that if the zip file was created using older/poorly designed zip tools, and it uses non-ascii characters in its filename, it is quite possible that the filenames you get out of the unzip tool will not be the same as the filenames that were put into the epub. Or if you are on windows and the filenames inside the zip file are longer than windows can handle, or they contain characters that are illegal in the filesystem your computer uses and on and on and on...

[DiapDealer]

I'm not certain why you seem to have taken issue with my post. Pendantry or semantics aside; I didn't mean to suggest that calibre's method of allowing users to edit AZW3s is somehow suspect or inferior. In any way. I think editing an AZW3 with calibre's editor is perfectly fine--I do it myself from time to time. I just find that many people are under the impression that azw3 is just a standard epub wrapped up in an Amazon package. I like to let people know it's not quite that simple. That's all.

My apologies if I touched a nerve. It wasn't my intention.

[kovidgoyal]

Oh, I was just indulging in a bit of pedantry of my own, this is entirely off topic as far as editing mobi files goes