Applying multiple classes to an element

[Hatgirl]

I am attempting to create a mobi format ebook by using kindlegen to convert an epub. I've managed to figure out the solution to most of the problems I've encountered, like preventing the cover appearing twice and adding guide items, but one problem has me stumped: it seems I can't apply multiple classes to an element.

So let's say this is an excerpt from my css file

p.italic {
    font-style: italic; 
}

p.bold {
    font-weight: bold;
}

And this is excerpt from the code in my xhtml file

<p>Oh, do you know the muffin man,</p>
<p class="italic">The muffin man, the muffin man,</p>
<p class="bold">Do you know the muffin man,</p>
<p class="italic bold">Who lives in Drury Lane?</p>

My epub looks like this:

Oh, do you know the muffin man,
The muffin man, the muffin man,
Do you know the muffin man,
Who lives in Drury Lane?

But when I convert that epub to a mobi, it looks like this!

Oh, do you know the muffin man,
The muffin man, the muffin man,
Do you know the muffin man,
Who lives in Drury Lane?

Aaaaarrrgghh! Can I seriously not apply multiple classes to an element?! Damn you, Amazon, I don't want to be spending my time dealing with this idiocy. Epub Rules, Mobi Drools!

There are obvious work arounds for this (just create a unique class like p.ihatemobi {font-style: italic; font-weight: bold;} ) but I'm hoping I'm wrong and you'll point out some comma or semi-colon I've missed out that will allow multiple classes

[ATDrake]

No, multiple classes do not work via KindleGen (unless this is one of the bugfixes for 1.2), and as you've noticed, it also completely ignores the first class used, which I think technically it should try to render under CSS fallback rules.

You also can't do descendant selectors, even the generic catchall type supported by CSS1, so if you want to style, say, all list items within a div of a certain class type (or even any div in general), you're going to have to mark up all those <li> or at least their containing <ol>/<ul> separately with target classes unless you're willing to have the style you want apply to everything within the parent <div> to save effort.

Those are just two of the many ways in which KindleGen in particular and the Mobi format in general are made of fail, lose, and frustration. I say this from bitter personal experience.

Hope this helps!

[Hatgirl]

Originally Posted by ATDrake

No, multiple classes do not work via KindleGen (unless this is one of the bugfixes for 1.2), and as you've noticed, it also completely ignores the first class used, which I think technically it should try to render under CSS fallback rules.

Gah. I was afraid of that. So, is this a problem with Mobi or Kindlegen? If it's just a problem with Kindlegen, is there another epub->mobi tool out there I can use?

I know I could use Calibre to convert, but given that I have handcoded my precious epub, I want a bit more control over the behind-the-scenes code than Calibre will allow

[ATDrake]

It's a problem with KindleGen*. If you were to do your .ihatemobi class, it would work perfectly well as things can be styled multiple ways at once. You just can't have multiple separate class instructions for styling them so, at least not all on the same tag.

The only Mobi conversion tools that I'm aware of are

• KindleGen (including the Kindle Previewer variant)
• Mobipocket Creator (with all the limitations of KindleGen and more!)
• Calibre
• Mobi2Mobi (does not handle Unicode, your book will have to be in Windows-1252 encoding and use escaped entities for any special characters)
• the Perl Ebook-Tools package (front-end wrapper for mobigen/kindlegen and other command-line converters)
• Stanza (pitifully bad as a simple e-book reader, consensus seem to be that its conversion produces crap)

Unfortunately, I guess you have a choice between ceding control to Calibre, or cluttering up your source to compensate for KindleGen†.

* Now, if you were to try and indent a right-hand margin and failed, that would be totally Mobi's fault…

† Don't forget that newer versions of KindleGen add bloat in the form of the complete source files to your Mobi and you should use Kindlestrip to fix that.

On the other hand, at least people would be able to admire your handcoding work?

[Jellby]

I believe Calibre does some "CSS flattening" step in conversions, maybe you can convert your ePUB to ePUB (or something else) with Calibre, making sure the CSS is processed and flattened, and then convert to mobi with KindleGen or whatever.

I know I could use Calibre to convert, but given that I have handcoded my precious epub, I want a bit more control over the behind-the-scenes code than Calibre will allow

But I'm sure Calibre allows more control than KindleGen...

[Hatgirl]

Originally Posted by Jellby

I believe Calibre does some "CSS flattening" step in conversions, maybe you can convert your ePUB to ePUB (or something else) with Calibre, making sure the CSS is processed and flattened, and then convert to mobi with KindleGen or whatever.

But I'm sure Calibre allows more control than KindleGen...

When I crack open the new epub Calibre produces from my epub, it has been altered rather radically internally, so that makes me wary of using Calibre for the mobi processing (not that I'm dissing Calibre. Love the thing for organising my collection, it's just not my cup of tea for converting).


I think I'll just have to make fat classes when I code my epubs. That will actually also solve the same problem I was having with the nasy, cheap, spare Binatone LCD eReader I have that runs FBReader. *sigh* Oh well, at least I've identified the problem, that's half the battle

[DiapDealer]

No, multiple classes do not work via KindleGen (unless this is one of the bugfixes for 1.2)

No, it's not addressed in 1.2. But thankfully, this thread has allowed me to at least identify the wall that I've been pounding my head against for so long.

Now me and my sore head can take a new tack.

[susan_cassidy]

Why don't you try changing that line to use a single bold, italic class (both attributes), and see if that converts?

[Hatgirl]

Originally Posted by susan_cassidy

Why don't you try changing that line to use a single bold, italic class (both attributes), and see if that converts?

Oh, it does (see the .ihatemobi class I mention in my first post). It's a legitimate workaround. But we shouldn't have to be finding workarounds, we should just be able to write code that complies with the W3C specs and have it bloody work

[DaleDe]

Originally Posted by Hatgirl

Oh, it does (see the .ihatemobi class I mention in my first post). It's a legitimate workaround. But we shouldn't have to be finding workarounds, we should just be able to write code that complies with the W3C specs and have it bloody work

that will never happen. W3C is for a web browser, not an eBook reader. It would be more reasonable to ask for something that complies with ePUB spec which would have been ok for this problem. Amazon seems to be actively changing Kindlegen to be better at doing ePUB conversions so at some point they may fix this particular problem but so long as they hang on to Mobi/AZW format there will be some things that will never work.

Dale

[Jellby]

Originally Posted by Hatgirl

It's a legitimate workaround. But we shouldn't have to be finding workarounds, we should just be able to write code that complies with the W3C specs and have it bloody work

Since mobi does not understand CSS at all, whatever you do with CSS must be converted into mobi-speak, and if it doesn't it's entirely the converter's fault, and a different converter might work differently.

If you don't like Calibre output (which I understand), maybe you can find something else that just processes the CSS and "flattens" it. It's quite likely there are other legitimate CSS construct (selectors, precedence...) that confuse KindleGen, and flattening the CSS would be a desirable pre-convert step.

[Hatgirl]

What makes me so cross is that Amazon insist in selling in mobi format. OK, fine. Their choice. But they specifically state that Kindlegen can "convert HTML, XHTML, XML (OPF/IDPF format), or ePub source into a Kindle Book."

The specs for HTML, ePub and the rest are available to them. The details of how mobi works are not available to us. The onus is on the people who insist on the black box format to make sure their conversion program can actually handle the input they claim it can, or to at the very least to describe what can't be converted. We, the users, shouldn't be forced to jam combination after combination through their meatgrinder to find out what does and doesn't work

It's... it's... it's... it's just bloody rude, is what it is.