Could Sigil create both EPUB and KF8?

[JSWolf]

Originally Posted by theducks

+1

Ditto!

[Hitch]

Originally Posted by Doitsu

I beg to differ.


I'm aware of that option, but why force users to open another full blown GUI application, when this functionality could be easily added by a programmer in a couple of minutes?

Why screw up Sigil, a smashingly good epub tool, when it takes 30 seconds to drag a properly-crafted ePUB onto Previewer, which you'll have to use anyway to test the book on multiple devices, assuming you don't have an iPad, a Kindle, a K-3, a Fire, a Droid tablet, and iPhone, etc.?

Based on your post history you didn't strike me as a stickler for protocol who insists on doing everything by the book. Isn't adding useful features always something that adds value to a program? IMHO, simply insisting on blindly following the "pure doctrine" doesn't make much sense.

I think everyone's entitled to their opinions, heavens know, but part of the problem here, IMHO, is the (repeating) sense that Sigil's an authoring tool. It isn't. It's a tool for people who regularly work in html, xhtml, css and regex. For WYSIWYG insta-ebook-creation, authors and small imprints can use Scrivener, JUTOH, Atlantis Word Processor, etc. My personal opinion is that this belief is fostered by the language that Sigil is a "WYSIWYG editor," which is, truth be told, pure nonsense (no offense, @user_none or @V). Just bollocks, as we see here every day in the myriad questions we get that can't be "fixed" from any WYSIWYG perspective. for that matter, take one look at the new Search and Replace functions--not exactly WYSIWYG-"author"-friendly, in any sense.

I don't understand why anyone would (routinely and repetitively) need 6 programs, but, hey--to each their own. We use a wide number, but primarily, if you're using Word, your path invariably is Word-->good html editor (like NoteTab Pro, my own fave)-->Sigil. From Sigil, if you want a MOBI, you can use Calibre if you wish, or KindleGen. Not sure what the other two programs would be, but those four pretty much cover the gamut. OO has the same path; even WordPerfect goes that way.

I agree that Amazon should add an automatically generated inline TOC to their Kindlegen ePub conversion code. However, given Amazon's track record when it comes to responding to customer requests, this is not very likely to happen anytime soon.
However, the current Sigil maintainer user_none is not bound by these limitations and could easily implement this feature.

Well, for that matter, if someone doesn't want to make their own inline TOC's, they can either use Calibre, again, or use "epubfixer," altho I find the latter very unintuitive. We have a clip that makes our inline TOC's for KindleGen, as given the Guide architecture, we don't foresee that changing anytime soon--if it were to change, I should have thought we'd see it in the Fire, (not via adding an inline TOC, but by using the ncx as does ePUB) and we didn't.

I can virtually guarantee that user_none certainly won't implement a Magic KindleGen Maker Bullet into Sigil anytime soon, and certainly not while Amazon holds mobi as proprietary. It's just not his bag, as we oldsters used to say.

Just my $.02,
Hitch

[JSWolf]

The best way to get Sigil to make Kindle compatible eBooks is to get Amazon to switch from obsolete & proprietary formats to ePub. But then, we know pigs will fly, cows will make chocolate milk, hell will freeze over, and republicans and democrats will work side-by-side for the good of the working class in the USA and we'll have peace and no wars of any kind before Amazon would dare go ePub.

[huebi]

Originally Posted by Doitsu

However, the current Sigil maintainer user_none is not bound by these limitations and could easily implement this feature.

Well, if it can be easily implemented, why dont you download the source and implement it by yourself?

[Doitsu]

I wasn't surprised by the mostly negative feedback that I received, however, what still puzzles me is the large number of followers of "pure doctrine" who kept repeating the mantra "Sigil is an ePub editor" and more or less said that even considering enhancements to support other formats borders on heresy and would surely screw up Sigil without giving any technical reasons.
I had expected more of a "hacker mentality." I.e. a keen interest in tweaking and enhancing existing tools by adding new useful features that would make life simpler for many people.
One could almost get the impression that anybody who doesn't create ePubs deserves to get punished for choosing a "lesser format."

Originally Posted by Hitch

Why screw up Sigil, a smashingly good epub tool, when it takes 30 seconds to drag a properly-crafted ePUB onto Previewer, which you'll have to use anyway to test the book on multiple devices, assuming you don't have an iPad, a Kindle, a K-3, a Fire, a Droid tablet, and iPhone, etc.?

Passing on a file name to a command line tool and executing it in the background won't significanlty change Sigil nor likely screw it up. Why force users to run a resource-hungry full-blown GUI program when a command line tool will do?

Originally Posted by Hitch

It's a tool for people who regularly work in html, xhtml, css and regex.

That's what I like about it and what I use it for, also. (I don't use Scrivener, JUTOH, Atlantis Word Processor etc. and I hardly ever edit anything in WYSIGWYG mode.)

Originally Posted by Hitch

We use a wide number, but primarily, if you're using Word, your path invariably is Word-->good html editor (like NoteTab Pro, my own fave)-->Sigil. From Sigil, if you want a MOBI, you can use Calibre if you wish, or KindleGen. Not sure what the other two programs would be, but those four pretty much cover the gamut.

I certainly don't use 6 tools. My main problem is that it's not possible to directly convert ePubs with Kindlegen, because they don't contain an inline TOC. (I could use Calibre, but since I often got unexpected and undesired results I prefer Kindlegen.) This means I have to unzip the ePub file, extract the ncx file, and generate an inline TOC from the ncx file.

Originally Posted by Hitch

Well, for that matter, if someone doesn't want to make their own inline TOC's, they can either use Calibre, again, or use "epubfixer," altho I find the latter very unintuitive.

So why force people to use "epubfixer" or other homemade solutions??

Originally Posted by Hitch

I can virtually guarantee that user_none certainly won't implement a Magic KindleGen Maker Bullet into Sigil anytime soon, and certainly not while Amazon holds mobi as proprietary. It's just not his bag, as we oldsters used to say.

It's funny that you (and many others) stressed that mobi is a proprietary format. This is only true for binary files created by Kindlegen (and Calibre).
Mobi source files are well-documented and almost identical to ePub files; without looking at the html header, only experts would be able to tell at a glance whether a certain html source file is from an ePub or a mobi project.
Besides, Sigil supports several proprietary ePub extensions introduced by Adobe for ADE. If full standards compliance were a priority, it should refuse to open ePubs with ADE extensions.

Originally Posted by huebi

Well, if it can be easily implemented, why dont you download the source and implement it by yourself?

I already created my own scripts and creating a fork for just one or two features would be overkill.

[brontus]

Hitch & Doitsu,

I was the one with the 6 programs. Prior to KF8, my workflow was:
1)OpenOffice to clean up formatting to be more ebook compatible & save as HTML
2)gEdit/Notepad++ to clean up HTML, inline TOC
3)GIMP to create or edit cover image
4)MobiPocket Creator to start process of creating mobi file
5)Back to Notepad to form toc.ncx file and edit opf file
6)Back to MPC to finish mobi file.
7)Kindle Previewer to validate.
8)Sigil with original html file of step 2, split chapters into separate files, validate epub.

6 programs. If I thought I was up to the task of extending Sigil, I would do it.

[Hitch]

Originally Posted by brontus

Hitch & Doitsu,

I was the one with the 6 programs. Prior to KF8, my workflow was:
1)OpenOffice to clean up formatting to be more ebook compatible & save as HTML
2)gEdit/Notepad++ to clean up HTML, inline TOC
3)GIMP to create or edit cover image
4)MobiPocket Creator to start process of creating mobi file
5)Back to Notepad to form toc.ncx file and edit opf file
6)Back to MPC to finish mobi file.
7)Kindle Previewer to validate.
8)Sigil with original html file of step 2, split chapters into separate files, validate epub.

6 programs. If I thought I was up to the task of extending Sigil, I would do it.

Hi, @brontu:

Well, counting GIMP is a bit much, as you'd have to use that for your cover no matter what you did.

I've no idea why you'd use MBPC-->NT or Notepad-->for the ncx and opf; we do it in Sigil when needed. Everybody has their own workflow, of course; but it seems really redundant to me. It seems that you're making the Kindle first, and the epub second--we always do the opposite, as I prefer to do the (relatively "upcoded") epub first, and then downcode for the MOBI, and add the necessary items (i.e., explicit sizing for images, etc.).

ETA: Actually...you're creating two books on two paths. That's what threw me. We use the completed ePUB, so we don't have two editing paths. Of course, we're doing this commercially, so I have to be certain I have conformed books; I make the Kindle files, literally, from the final ePUB files.

@Doitsu:

You don't need a GUI. You can drop the completed ePUB file on the command-line KindleGen, as well. You don't even need to run it from the command-line, as someone with your skillset obviously knows.

Here's my question: is your entire desire for Sigil to simply make an inline TOC? Because really, there's not much else needed for KG; so I'm inferring from your post that what you really want is an inline-TOC-maker and an integration to the KG command-line tool. Is that correct? Do I understand you rightly?

Hitch

[huebi]

Originally Posted by Doitsu

enhancing existing tools by adding new useful features that would make life simpler for many people.

Currently i can see only one or two.

[Doitsu]

Originally Posted by Hitch

so I'm inferring from your post that what you really want is an inline-TOC-maker and an integration to the KG command-line tool. Is that correct? Do I understand you rightly?

Yep, that's all I want. Too bad it's not going to happen anytime soon.

Originally Posted by huebi

Currently i can see only one or two.

Not everybody has the time to follow every thread. BTW, the ncx -> inline TOC conversion issue came up in a couple of other unrelated threads that you apparently didn't read.
The funny thing is that once the chief Sigil developer decides to add full support for ePub 3, he'll have to add an ncx to inline TOC conversion and/or an inline TOC generator anyway, because in ePub 3 ncx files are superseded by EPUB Navigation Documents, which are very similar to Mobipocket inline TOCs. For more information, see the relevant ePub 3 specification.

[st_albert]

At some point, IIRC, sigil will acquire a plug-in interface. At that time, it will be truly trivial to set up a "kindlegen" plugin, and almost as trivial to write a script that will generate an inline xhtml TOC from the toc.ncx file. Problem solved.

Actually, in my case I still probably won't bother with a kindlegen plugin, since it's already easy to run the suitably tweaked epub through kindlegen from the command line, as Hitch indicated above.

But generating an in-line TOC would be a great candidate for a plugin, IMHO.

Anyway, a plug-in architecture will be a great answer for those who need a "purple bidet" plugin, and we won't be needing to have these kinds of arguments.

[Hitch]

Originally Posted by st_albert

At some point, IIRC, sigil will acquire a plug-in interface. At that time, it will be truly trivial to set up a "kindlegen" plugin, and almost as trivial to write a script that will generate an inline xhtml TOC from the toc.ncx file. Problem solved.

Actually, in my case I still probably won't bother with a kindlegen plugin, since it's already easy to run the suitably tweaked epub through kindlegen from the command line, as Hitch indicated above.

But generating an in-line TOC would be a great candidate for a plugin, IMHO.

Anyway, a plug-in architecture will be a great answer for those who need a "purple bidet" plugin, and we won't be needing to have these kinds of arguments.

Yeah, I admit, given the simplicity of it (unlike, say, re-ordering the play order, or chapters), it does sound like a purple bidet to me--but everyone has their own wishlist. I don't, though, want to see Sigil go the way of some other tools, and lose its primary focus, which still ePUB. As we all know, we get requests to make it "word with magic epub+mobi export features" around here daily. That sentence was not directed at the OP--but we do see those requests constantly. WRT to the nav elements--as yet, as we all know, the major players aren't yet supporting ePUB3 nav elements, so if and when that occurs, it'll be interesting to see if that TYPE of navigation "page" will actually work with a mobi--or if we'll still be stuck with an inline TOC, as whilst similar, they are not the same. The nav blocks in ePUB 3 are, as I understand it, intended for larger, overview items.

For the life of me, why they supplanted the ncx--which works perfectly fine--with a bloody TYPED TOC seems utterly ridiculous...in this line of work, it's 1 step forward and three steps back. Very frustrating. Of all the major devices, I find the NookColor's ncx-viewer the easiest to use for navigation, superior to the iBooks' app and the Fire + other Kindle's "Go to TOC" function, as Nook allows you to navigate from whence you are, without jumping hither and yon first; certainly NOT the inline TOC's. Bloody tedious.

Hitch

[JSWolf]

Originally Posted by Doitsu

I wasn't surprised by the mostly negative feedback that I received, however, what still puzzles me is the large number of followers of "pure doctrine" who kept repeating the mantra "Sigil is an ePub editor" and more or less said that even considering enhancements to support other formats borders on heresy and would surely screw up Sigil without giving any technical reasons.
I had expected more of a "hacker mentality." I.e. a keen interest in tweaking and enhancing existing tools by adding new useful features that would make life simpler for many people.
One could almost get the impression that anybody who doesn't create ePubs deserves to get punished for choosing a "lesser format."

We are being punished it seems. Amazon is trying to fragment the market and doing a good job at it. We don't need multiple formats and yet here we are again with yet another format we don't need and don't want. If Amazon went ePub with the same DRM, then all would be well. But they didn't and all isn't well.

I certainly don't use 6 tools. My main problem is that it's not possible to directly convert ePubs with Kindlegen, because they don't contain an inline TOC. (I could use Calibre, but since I often got unexpected and undesired results I prefer Kindlegen.) This means I have to unzip the ePub file, extract the ncx file, and generate an inline TOC from the ncx file.

What sort of unexpected results do you get from a Calibre converted Mobi (ePub > Mobi)? I find Calibre does a better job overall then the Mobipocket tools and now that you agree that Kindlegen is junk, why not learn how to use Calibre?