Is there a tool like Sigil to edit mobi ebooks?

[theducks]

Plus 1

The horse is dead.

There are so many features and modes of use that it can cause confusion on what does what to whom.

[eschwartz]

Originally Posted by DiapDealer

Sure.
But for my own part; KindleUnpack, Sigil, or calibre's editor never really factored into it. I was simply responding to your (still incorrect) claim that we had an editor that allows us to "directly edit" an azw3's source. I'm just willing, now, to allow you to believe that's what we have.

See above (yours) under "pedantry". And as far as the pedantry goes, I agree with you!



Is there something about MobileRead that requires people to argue with people who don't disagree? Because that pretty much seems to define this thread now.


Yes, I know you weren't the one doing the non-pedantic arguing.

[DiapDealer]

Originally Posted by eschwartz

See above (yours) under "pedantry". And as far as the pedantry goes, I agree with you!



Is there something about MobileRead that requires people to argue with people who don't disagree? Because that pretty much seems to define this thread now.


Yes, I know you weren't the one doing the non-pedantic arguing.

I must've missed the part where you agreed with me that azw3 files are not being directly edited. Sorry.

[eschwartz]

Originally Posted by DiapDealer

I must've missed the part where you agreed with me that azw3 files are not being directly edited. Sorry.

Not explicitly, but sheesh, I didn't really discuss that as regarding the land of pedantry.

[mrmikel]

I just hate to see two people who I greatly respect, Hitch and Kovid, getting at such loggerheads over this stuff.

AZW3 is a nice feature, but of no use to her organization and their workflow is built around Sigil. Why change? I am still using a DOS based database program in a virtual machine because all of my records are in the format. No percentage in disrupting work for no increase in efficiency. In fact it would guarantee a decrease in efficiency for a time.

Seems to me that basic problem is that you can only publish to Kindle formats and that output can not be used directly by any editor, if I understand things. This makes things much harder for content packagers than epub which is used directly by the device in the format in which it can be directly edited.

And there are epub publisher word processors who output might even be used directly for sale. I don't that any word processor is available to make Kindle documents for sale directly.

[mrmikel]

When the discussion becomes one of the level of pedantry, one should be careful of another level, inanity.

My own concern is regarding insanity, trying to find a dangling paragraph tag in 630 lines of code!

[eschwartz]

I would imagine the bigger problem is the inability to convert cleanly to EPUB, and being unable to feed AZW3 to kindlegen -- so why start with it if you don't need to?

I don't like editing AZW3 either -- because it requires decompiling and recompiling to open/save, I guess, whereas EPUB can simply be decompressed. But it is handy for touchups if it is the base format. Speaking purely as a consumer of the Kindle Store, of course.

That being said, I do like editing EPUBs, specifically in calibre editor. I was still new to the scene when it came out, so I tried both and stuck with calibre. I like the fact that it doesn't change even folder structure without being prompted, and I don't believe in WYSINWYW editing. But I wasn't used to Sigil beforehand, and calibre appealed to my inner geek.

[mrmikel]

Sigil has an environment which is more comforting for a beginner, even having WYSISYG entry. The fact that use of it makes for inelegant code does not make the code less useful. It also gives a pre-cooked structure for those whose life is not consumed by epub/html/css trivia.

But this all boils down to personal taste. There are millions of users of Calibre who organize their entire libraries with it. I only use the conversion and editor function. Each to his or her own. It is after all only ebooks.

[kovidgoyal]

All I want to emphasize is that the calibre editor, unlike calibre conversions, does not flatten css. This is a misconception I see a lot, therefore I wish to combat it. I have absolutely nothing against any other tool or workflow. Everyone should feel free to use whatever floats their individual boats, be it kindlegen or Sigil, or unzip+notepad or whatever. Once again,

the calibre editor has no relation to calibre conversions and does not, in any way, flatten or otherwise modify your css or html

@Hitch: I apologise if I was overly vehement but this is a misconception that needs to be corrected, and you were, perhaps inadvertently, furthering it.

[Hitch]

Originally Posted by kovidgoyal

All I want to emphasize is that the calibre editor, unlike calibre conversions, does not flatten css. This is a misconception I see a lot, therefore I wish to combat it. I have absolutely nothing against any other tool or workflow. Everyone should feel free to use whatever floats their individual boats, be it kindlegen or Sigil, or unzip+notepad or whatever. Once again,

the calibre editor has no relation to calibre conversions and does not, in any way, flatten or otherwise modify your css or html

@Hitch: I apologise if I was overly vehement but this is a misconception that needs to be corrected, and you were, perhaps inadvertently, furthering it.

Kovid:

I'm sorry about the mis-discussion, HOWEVER it occurred. For the record, if I could open a Kf8-mobi, with a .mobi file extension, edit it with Calibre, save and be done, I'd love it. But I can't use the awz3 file extension, for my business, so: I have never even tried it. I don't profess to have tried it. And, yes, I was thinking about the aspect that, arguably, I could use--the conversion. So: I apologize for anything I said that could have been inferred, by anyone, as a slam at CALIBRE. I really was just thinking about "intermediate," not...not anything more than that.

Apology accepted, and folks: let's move on. There's enough freaking drama with the illiterati out there, those of us HERE, at MR, which I mostly consider to be a haven of smart, (like the Straight Dopers), should NOT add to it.

This is the ONE place I come to for no other motive, no sales pitches, no PR, no "social media" (the bane of my existence), I'm not trying to right wrongs (like the endless BAD info at the KDP), and I just want to HANG OUT. I don't get clients from here, I don't do anything here but be ME. I don't have to see kitteh pics, or hear what someone had for lunch. For me, this is my personal corner coffeeshop (or bar, whatev), and I'd like to see it stay that way.

Hitch

[shotsky]

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.

In my case, I receive ebooks in epub, azw3, mobi, and a few others. My goal is to open the ebook, extract the html, merge the html into a single file and eventually convert the html into a text file with links to photos, that goes into another program. I don't MAKE ebooks, I receive ebooks and convert them to text, all the while handling all the Unicode characters by converting them to the ANSI range when necessary. (Single fraction 1/3 is converted to the three characters, 1, /, and 3. And those games people play with sub and super to invent fractions are also converted to normal three character fractions. It is easy to handle characters, but in addition to that, I need to also identify all the text items on each page. The problem with using Calibre to make an htmlz file, which DOES put all the files into a single html file, is that it renames classes and elements in an unexpected manner, which causes the original meaning of the text that followes to be lost. For example, the original html may call a number class a 'numerator', and another a 'denominator'. When Calibre converts it, they will no longer say 'numerator' and 'denominator', but calibre59 and calibre60. It is no longer possible to know that is a fraction.
My current solution is to run Calibre in debug mode and use the Input folder that results for all of my work. That is all original html, untouched by calibre's renaming of classes. For epubs, that means all the pages are separate files, but the mobi's are all in one file. I don't know why the difference, but my code does rebuild the epub pages into a single html file, stripping all headers and replacing all the html code with html5 code. So my goal of having a single html file without renamed classes is achieved, and my software proceeds to dissect the content using whatever classes and/or other tags were originally provided. It is an AWFUL lot of work to do all that, when all I wanted in the first place was the original html, in a single html file, such as is created by the htmlz convert, only without all the renaming. If htmlz convert worked off the files in the input folder resulting from debug, it would be perfect. But it works off the 'processed' folder, which is substantially different, and in my case, unusable.

[mrmikel]

There is a difference between the conversion function of calibre and the calibre editor. The calibre editor can be started separately. It doesn't change any files imported into it, and you can just import the files directly.

You can edit them, create a table of contents and save them as azw3 or epub.

You can change fractions to unicode fractions.

If you already have calibre installed you can start the editor by itself with
Program Files\calibre2\ebook-edit in Windows.

[DiapDealer]

Well yes, in that case, you're (@shotsky) doing MUCH more than editing an ebook. Let's face it: combining everything into a single html file (when it wasn't in a single html file to begin with) is going to be a fairly involved process no matter how you go about it. IDs that used to be unique, might not be unique any more; all links will need to be adjusted--IDs may need to be created to accommodate url fragments in those adjusted links; styles/css will need to be combined and/or edited. There's a lot to do for an automated tool to keep stuff valid (even if you don't need it all to be technically valid).

The problem with using Calibre to make an htmlz file, which DOES put all the files into a single html file, is that it renames classes and elements in an unexpected manner, which causes the original meaning of the text that followes to be lost.

That's just it, though. It's not in an "unexpected manner" if you think about it. All those things I mentioned above are WHY those changes have to happen--so that it will "work" for every case thrown at it. Also keep in mind that you're still talking about a "conversion" not an edit.

I'm afraid that in your case, manually merging files is probably always going to be the "best" approach (even if it is the most tedious). As soon as you look to automate portions of your process, you're going to have to sacrifice control of the output. That part never changes.

If your ultimate goal is to extract all the text, I would seriously suggest finding a way to do so that doesn't involve combining all html files into one file as the very first step.

[Toxaris]

In my new version of the add-in tools for Word you can import ePUB into Word. The stylenames would be retained. If you have different stylesheets in an ePUB, that should work.
A word of warning though, currently only CSS1 is supported. So only simple formatting is retained. Although that usually would not be a big issue, as the stylenames (and thus structure if wisely used) is retained.

That release of the tools is expected in about two weeks after testing is completed.

[shotsky]

Originally Posted by mrmikel

There is a difference between the conversion function of calibre and the calibre editor. The calibre editor can be started separately. It doesn't change any files imported into it, and you can just import the files directly.

You can edit them, create a table of contents and save them as azw3 or epub.

You can change fractions to unicode fractions.

If you already have calibre installed you can start the editor by itself with
Program Files\calibre2\ebook-edit in Windows.

The Calibre editor will not edit mobi - it has to be converted first, and then the damage is done. That is why I originally was looking for something that could simply extract mobi files to html (or htmlz, with no renamed classes.) Note that I don't have any problem with ADDED classes, I have a problem with RENAMING classes that tell what something is, to 'calibrexx', especially when it is not needed within one ebook, because existing classes have meaning, and those classes could simply be used by Calibre instead of renaming them. If it left the original classes, etc, alone, there would be no problem, and I could use htmlz as I had planned to do. Calibre could also add id tags instead of renaming existing classes, which should still achieve the intended result.
I can handle epubs externally by renaming, unzipping, and rebuilding as I wish. Can't do that with mobi. I want a solution that works for any ebook, because I don't want to have different users of my tools to have to install different programs for different ebooks they work with. Calibre, in debug mode, DOES at least give me an almost standardized method. Upon rebuilding what I need from the input folder, I delete the entire debug folder, leaving only files of interest behind in a work folder.