KindleGen and XHTML/CSS2

[pdurrant]

Originally Posted by pdurrant

The only consistent font size option is to use <big> and <small> tag directly in the XHTML.

I have now found that one of the reasons I'm having such trouble with font size is that Amazon have messed up the Mobipocket rendering engine!

Kindlegen converts CSS font sizing into the <font> tag with the size attribute. It correctly converts things like percentages to relative sizes , e.g. +2. Unfortunately, the Kindle rendering engine incorrectly renders these relative sizes, always rendering them relative to the base font size chosen by the user, not the current font size of the text.

Mobipocket Reader does render them correctly.

Oh dear. And Kindle for Mac and Kindle for PC also render them 'correctly', just not the same as an actual Kindle! The Kindle Previewer does render them like a Kindle.

Bloody Amazon! It's impossible to make books in Kindle format that look right on Kindle for Mac and Kindle for Pc and on actual Kindles! I haven't had a chance yet to test Kindle for iPod/iPhone. I wonder which code base that was taken from. Bah!

[ATDrake]

Kindle Previewer does have iPhone simulation mode. While it's obviously not the same as the real thing, it does seem somewhat better at doing its job than the other Amazon-provided tools. At least, it mimics my K2's display with reasonable accuracy on the stuff I've tried.

But this, really, is why I personally prefer ePub as a format overall despite a lot of people claiming that Mobi's just as good. At least when something goes wrong, I have the luxury of being able to think it's probably some error in 1) my file formatting or 2) the reader's rendering, or perhaps some combination of both, rather than having to wonder if it's 3) the officially-supplied assembly tools being wrong and bad.

Incidentally, now that you've written the bloat-stripper to go along with mobiunpack, do you think it might be too much trouble to tweak either to optionally output a copy of the original source files that Amazon now insists the Kindlegenerated output includes?

I admit to a certain morbid curiosity regarding the occasional text whose formatting was so messed-up that I wondered how on earth they'd managed to acheive that effect, and it would be kind of nice to be able to possibly indulge it on future such examples that might come up, assuming they'll have been made with Amazon's tools.

[pdurrant]

Originally Posted by ATDrake

Incidentally, now that you've written the bloat-stripper to go along with mobiunpack, do you think it might be too much trouble to tweak either to optionally output a copy of the original source files that Amazon now insists the Kindlegenerated output includes?

That's a fairly easy tweak....


Ok, it seems there's a mysterious 16 byte header in front of the zip file. I'm going to strip that and just output the zip file, printing the sixteen bytes as hexadecimal to the standard output.

[pdurrant]

Originally Posted by pdurrant

Ok, it seems there's a mysterious 16 byte header in front of the zip file. I'm going to strip that and just output the zip file, printing the sixteen bytes as hexadecimal to the standard output.

Now uploaded at https://www.mobileread.com/forums/showthread.php?t=96903

I'd be interested to hear (in that thread) how you get on with it.

[ATDrake]

Thanks! Appreciate very much that you took the time to modify your script.

It'll probably be a while before a new enough "published" freebie shows up in the Amazon store that I can try it on (though maybe some of those recent "Free with Bonus Content" promo editions might qualify).

But in the meantime I think I'll make some sacrificial conversions with Kindlegen 1.1 build 99 and see how they stack up both size-wise etc. against files generated with build 98 and Kindlegen 1.0 (which I've still got installed) when I've got a free moment, and report in the other thread.

One potential vague upside I can see to the bloat now being enforced default is the possibility of taking future Kindlegenerated Mobi files from elsewhere with annoying problems, and being able to lay hands on the actual source to see where things originally went wrong, instead of having to unpack the Mobi to html and poke around and guess.

[pdurrant]

Originally Posted by pdurrant

Well, this works really well on the Kindle, and on the Kindle Previewer. Hanging Indents don't seem to work at all on Kindle for Mac. Sigh...

Further investigation, after realising the Kindle for Mac and Kindle for PC have been created from the old Mobipocket Reader for Windows code, shows that they do support hanging indents, but not when specified in ems!

Hanging Indents are only supported for pixels, points and percentage. And the support for percentage is new in K4Mac/K4PC - the last Mobipocket Reader for Windows did not do a hanging indent with w negative percentage.

This is good news and bad news.

It's good news in that at least hanging indents can be done. It's bad news in that they can't be specified in a way that will scale with the text.

It also shows that the Kindle firmware isn't based on the old Mobipocket software at all. As far as I can see, they must have written the Kindle code from scratch, based on a specification derived from the Mobipocket software in some way. And they did it better in some areas (negative indents) and worse in others (relative font sizes, poetry alignment).

So to make a kindle ebook that makes use of indents, hanging indents and font sizes, it's going to be necessary to severaly restrict what's used just to make sure it renders correctly on all the Kindle renderers from Amazon that are out there. Let alone trying to make the source work with ePub as well.

I am beginning to think that it might be best to have a base source text of XHTML that's marked up with semantic styles, and then have some scripts that hack that into source suitable for Kindle and for ePub. But I'd really hoped to be able to avoid that — I'd rather hoped Kindlegen was going to do the hard work for me. Not so, I think.

[Oldpilot]

A great discussion; I'm glad I found it.

I have regularly used hanging/negative indentation for bibliographies. I use .3in indent and hanging indent.

Are you aware of Amazon's guide to the Kindle?

http://g-ecx.images-amazon.com/image...Guidelines.pdf

[pdurrant]

Originally Posted by Oldpilot

A great discussion; I'm glad I found it.

I have regularly used hanging/negative indentation for bibliographies. I use .3in indent and hanging indent.

Are you aware of Amazon's guide to the Kindle?

http://g-ecx.images-amazon.com/image...Guidelines.pdf

Oh yes. Note on Page 7 the item about paragraph formatting doesn't say that if you use negative indents with ems then they won't work on Kindle for Mac or Kindle for PC.

It also has nothing to say about font sizes.

Amazon's Kindle formatting guidelines are quite poor in terms of precise detail. If you just want paragraphs of plain text they're fine.

I think it's the inconsistency between the different Kindle platforms that upsets me most.

[ATDrake]

Originally Posted by pdurrant

I am beginning to think that it might be best to have a base source text of XHTML that's marked up with semantic styles, and then have some scripts that hack that into source suitable for Kindle and for ePub.

You don't need scripts if your XHTML is well-formed. Just write a couple of XSL stylesheets to output whatever you need. Yay for XML and transforms!

But yeah, it's really irritating that one has to not only jump through hoops to get a decent display, but that the hoop-jumping is also kind of wasted because you're not even going to benefit from consistent display across the group of problem devices.

[pdurrant]

Originally Posted by ATDrake

You don't need scripts if your XHTML is well-formed. Just write a couple of XSL stylesheets to output whatever you need. Yay for XML and transforms!

But yeah, it's really irritating that one has to not only jump through hoops to get a decent display, but that the hoop-jumping is also kind of wasted because you're not even going to benefit from consistent display across the group of problem devices.

You're right. I haven't done anything with XSL yet, so that hadn't occurred to me. I shall have to look into it. I certainly intend to always have valid XHTML, whatever else I have to get up to.

Thanks!

[pdurrant]

Originally Posted by pdurrant

You're right. I haven't done anything with XSL yet, so that hadn't occurred to me. I shall have to look into it. I certainly intend to always have valid XHTML, whatever else I have to get up to.

Thanks!

And having very briefly started looking at XSLT, it seems that there are now tools for Mac OS X that will allow me to integrate XLST with an Applescript, which combined with Kindlegen should allow me to set up a work flow where I have a single XHTML/CSS source in an ePub-like structure, I drag&drop the folder onto my AppleScript, and customised Kindle and ePub format ebooks get created with no further user interaction. I could even produce ePubs customised for the different rendering abilities of ADE and iBooks.

It'll be quite a lot of work, but I think it might be worth it. Wow.

[ATDrake]

Myself, I'd go even further and switch over to having XML as my sources. Why settle for doing <span class="dialogue" xml:lang="fr"> when you can do a simple <fr-dlg> or you can go straight to:

<recipe>
<title>Boiled Water in a Pan</title>
<ingredient qty="2" measure="L">water</ingredient>
<instructions>
<step no="1">Don't set the stove on fire while turning it on.</step>
</instructions>
</recipe>

instead of having to muddle around with classing divs and spans and other elements just so that you can target a few things with CSS?

The great thing about XML is that you can keep the content you're working on nice and cleanly semantic, and separate out dealing with the messy display quirks for the final output version.

You've probably already come across all this, but just in case:

Late Night Software has a bunch of free AppleScript Scripting additions for XML and XSLT, and the Smile people have an XMLLib one, along with some other possibly useful stuff.

Todd Ditchendorf's also written up a bunch of useful tools that integrate with Safari and are mostly BSD licensed on Google Code. Good for testing things.

Some of them are kind of hidden away on his website due to some sort of reorg or something, so: AquaXSL, AquaPath, XSLPalette.

And I've generally found Marc Liyanage's TestXSLT useful for doing just what is says on the box. Helps one get the hang of things.

[pdurrant]

Originally Posted by ATDrake

Myself, I'd go even further and switch over to having XML as my sources. Why settle for doing <span class="dialogue" xml:lang="fr"> when you can do a simple <fr-dlg>

Also a good point. And I'm pretty sure that are some existing xml encoding standards for books. I'll have to go and look them up - it would be best to use (a subset) of a standard rather than rolling my own.

Hmm.... I may be some time.....

[pdurrant]

Originally Posted by pdurrant

Also a good point. And I'm pretty sure that are some existing xml encoding standards for books. I'll have to go and look them up - it would be best to use (a subset) of a standard rather than rolling my own.

Hmm.... I may be some time.....

Ah — DocBook was the standard I was thinking of. Since there are already XLST documents for DocBook to XHTML out there, it makes even more sense to go with DocBook and tweak some existing XSLT documents, rather than trying to write it all myself.

I should even be able to come up with an XSLT to convert to XPressTags and Indesign tagged Text, if I can't find any out there already.

[ATDrake]

For XML-based book standards, Text Encoding Initiative's working on it. Also DocBook, which I see you've found while I was previewing my post. Several tools available for generating HTML/ePubs from both, too.

On Google Code there's epub-tools from ThreePress, who've a nice ePub blog here. They love to show off nifty proposed stuff that will presumably be available in future versions of ePub. Their toolset includes the python-based tei2epub and docbook2epub, and some Java-based stuff.

There's also tei2html which is a work in progress, but is also the project of a fellow MR member.

Hope this helps.