Commercial ePub (3) authoring software

[icsorea]

Hi! I have been looking at various ePub authoring software for ePub (3) for commercial use in the workplace. I prefer the ones various publishers (aka the big six) use. I am familiar with both Sigil and Calibre, as I have been using these editors in my workplace to convert various PDF textbooks to ePubs.
I also wish to incorporate various multimedia content (A/V, js, among others), and using the latest standards (HTML5/CSS3) which is only supported on ePub 3.

The question at hand should state the following:
To users who work in publishing companies (more importantly, the big six - Random House, HarperCollins, Simon & Schuster, Penguin, Macmillan, Hachette), what software do you use in order to convert the books that your company publishes? Is this software a personal preference or is an industry standard?

Sadly, Sigil has a lot of downsides to make ePub authoring easier. Some of its disadvantages include the following:

• Lack of ePub 3 support
• Cannot drag and drop assets
• Conversion of internal and inline html into comments - that are not being read onto the device
• All assets - including web pages, styles are segregated in their own folder instead of being in the OEBPS folder directly [are folders necessary for web pages and styles?]
• Sigil adds "junk code" that would treat internal CSS stylesheets as a comment, and treating inline styles as sigil-named ("sgc-x") styles making it difficult to distinguish one style from another.

I personally don't like the Calibre software for the following reasons:

• Lack of ePub 3 support
• Calibre-generated code - Addition of calibre-added styles on top of existing ones in the CSS files, and a "calibre" tag in the opf file, which is not present in publisher company ePubs.
• Terrible conversion from pdf/mobi to ePub - lack of a nav toc
• Cover images get stretched to the size of the viewport (which is OK for tablets, but not for monitors). - undesirable
• Naming convention: *-split-xxx.html - difficulty in organization - may create too much chapters

I have included various images from publisher-made ePubs that are clean and that comply with the standards.

Thanks for your help.

[Jellby]

Originally Posted by icsorea

All assets - including web pages, styles are segregated in their own folder instead of being in the OEBPS folder directly

Why is this a problem? The internal folder structure of the ePub does not affect the least to the final result. I create my ePubs manually, and I have different folders for each kind of file too.

I personally don't like the Calibre software for the following reasons:

Calibre is just an ebook management (library) program that happens to have some conversion capabilities, don't expect it to be an ePub editor/creator, because it's not.

Cover images get stretched to the size of the viewport (which is OK for tablets, but not for monitors).

It's not OK for tablets either, unless the cover has the same aspect as the screen (minus margins) in whatever orientation you are using... and in that case it's OK for monitors too. Stretching without keeping aspect ratio is almost never OK.

[DaleDe]

You might want to read the article in our wiki called, strangely enough, Book authoring software. There is a good list in the article.

Dale

[mmat1]

Originally Posted by icsorea

Thanks for your help.

What's your question /request ?

[icsorea]

Originally Posted by Jellby

Why is this a problem? The internal folder structure of the ePub does not affect the least to the final result. I create my ePubs manually, and I have different folders for each kind of file too.

Note how the publisher organizes their files vs my own organization. My boss ~specifically~ wants all assets to be top-level. His reason for such standards is making the authoring process easier if I were to link various images. Usually, publishers would not put an 'up one level' semantic (.. in HTML) on their web pages to ease managing assets. I would understand if there is a separate folder for images, scripts, etc but are separate folders really necessary for stylesheets and web pages?

Originally Posted by Jellby

Calibre is just an ebook management (library) program that happens to have some conversion capabilities, don't expect it to be an ePub editor/creator, because it's not.

I knew from the start that Calibre was just an eBook converter. I don't know why my boss recommended me to use this software as an authoring tool.

I will edit my original post, hopefully to better reflect the question at hand. Thank you for your ideas.

[DiapDealer]

Note how the publisher organizes their files vs my own organization. My boss ~specifically~ wants all assets to be top-level. His reason for such standards is making the authoring process easier if I were to link various images. Usually, publishers would not put an 'up one level' semantic (.. in HTML) on their web pages to ease managing assets. I would understand if there is a separate folder for images, scripts, etc but are separate folders really necessary for stylesheets and web pages?

I guess I just don't understand how having assets at the same level (top or otherwise) would have any bearing on the ease/difficulty of the authoring process. Especially since almost any authoring software in existence is going to invisibly manage those levels for you. If you want/need that kind of control over the ePub's architecture, then manually constructing them would seem to make the most sense.

In order for any authoring software to make ePub construction "easier" (and by easier, I mean creating/managing links and handling all the recursive renaming/relinking when files get renamed, inserted, deleted... TOC building—generally the things that make authoring software attractive in the first place), the first thing it's probably going to need to do is to take absolute control over the internal structure... it wouldn't be able to do all the things that are so "handy" (in a programmatic manner) otherwise.

As to why Sigil needs to put each type of asset into its own folder; I say why not? It complies with spec and doesn't make creating/editing ePubs with Sigil any more or less difficult. One of the main reasons for using ePub authoring software in the first place is because you don't want to concern yourself with the internal, structural, nitty-gritty details, right?

I'm not certain why you're under the impression that major publishers have some sort archetypal ePub structure, anyway. In my experience, I get wildly varying internal structures in ePubs purchased from major publishers. Many of them varying wildly within the same publisher. Anything from a perfectly flat structure, to Sigil's subfolder approach. And more and more lately... an actual Sigil-built ePub.

Want control over structure?... build by hand.
Want to use authoring software?... forget about structure.

As far as lack of ePub3 support... join the crowd. Spec-compliant ePub3 authoring software is going to be just about as rare as devices that actually support spec-compliant v3 ePubs.

[JSWolf]

As for ePub 3, if you make an eBook ePub 3 compliant, nobody would be able to read it. There's nothing out there to read ePub 3.

[DaleDe]

Originally Posted by JSWolf

As for ePub 3, if you make an eBook ePub 3 compliant, nobody would be able to read it. There's nothing out there to read ePub 3.

There are some readers that support aspects of ePub 3 so to say there is nothing out there is flat wrong. The ePub 3 standards committee even has a reference design available for developers. Like ePub 2 not all implementations support all features of the specification. AZARDI does support most of ePub 3 and the same company that makes it also sells publication tools for ePub 3. For a list of tools that claim ePub 3 support see our wiki.

Dale

[JSWolf]

Originally Posted by DaleDe

There are some readers that support aspects of ePub 3 so to say there is nothing out there is flat wrong. The ePub 3 standards committee even has a reference design available for developers. Like ePub 2 not all implementations support all features of the specification. AZARDI does support most of ePub 3 and the same company that makes it also sells publication tools for ePub 3. For a list of tools that claim ePub 3 support see our wiki.

Dale

But, there is no standalone reader that supports ePub 3. Nor are there any apps that do for phones/tablets. Plus, ePub 3 eBooks won't sell. If the OP Makes an eBook ePub 3 compliant, hardly anybody could read it.

[DaleDe]

Originally Posted by JSWolf

But, there is no standalone reader that supports ePub 3. Nor are there any apps that do for phones/tablets. Plus, ePub 3 eBooks won't sell. If the OP Makes an eBook ePub 3 compliant, hardly anybody could read it.

Generally iBooks is considered a ePub 3 reader so I can't agree. KF8 also claims to be ePub 3. Of course there are no users that use and iPad or a Kindle.

Dale