Monday, April 26, 2010

The new “Add Semantics” menu

After the iPad came out, everyone (myself included) wanted to know how well it would handle epub. As it turns out, not great. No embedded font support? Bad Apple, bad!

Anyway, the iBooks application for reading epub books on the iPad comes with this large shelf view where all the books display their covers. Shiiiiny. But as a content producer, you have to explicitly tell the iPad which image in the epub archive is the cover.

There was an interesting discussion about this on MobileRead. The idea to take away is that you need a special meta tag in the metadata section of your OPF file. Something like this:

<meta name="cover" content="coverID" />

The “coverID” needs to be the ID of the cover image in the manifest section.

Until now, you had to save your epub with Sigil, extract the epub, edit the OPF, add this meta tag and then zip everything up properly (mimetype file first with no compression etc.). Oh and you could never open that epub again with Sigil since it would remove that special meta tag.

A horrible PITA, wasn’t it?

Well that’s fixed now. The next version of Sigil will have a right-click context menu for images with which you’ll be able to mark an image as a cover. Done. Sigil does everything else required for you.

Along with this “Add Semantics” menu come new entries for the HTML resources. For those, you can now add the <guide> element semantic information. So if you mark one HTML file as, say, a “Title Page”, Sigil will add this information to the <guide> element in the OPF.

Naturally, this feature would be useless if Sigil wouldn’t preserve all of this information after opening an epub that already has it. So it does that now too: all information from the <guide> element is now preserved, including custom values for the “title” attribute (even though you can’t see that value in Sigil, it’s stored). The special meta tag identifying the cover image is read and that information is preserved, too.

Being smart about it

Sigil always does its best to help you out. Well, it at least tries :).

I’ve added heuristics to Sigil that will mark the appropriate image as the cover if you don’t do it yourself. If the first HTML file in the reading order is “very small” and has only one image in it[1], that image will be selected as the cover.

So if you follow best practices, Sigil helps you out. Still, mark it by hand if you can. You will always know better than the machine.

Things to note…

While the OPF spec technically does allow you to, for instance, specify several HTML files as the title page in the <guide> element (for God knows what reason…), Sigil stops you from doing this. It allows you to set only one instance of one <reference> type per book. So if one file is set as the title page, setting another file as the title will unmark the last one.

The exception are loaded epub files. If your loaded file specifies several HTML files as, for instance, the preface, then all of those are still marked as such in Sigil after they’re loaded. While I personally think you should never use more than one reference type instance per book[2], if you did this to one of your books before opening it in Sigil, that information will remain. Sigil won’t step on your toes here.

Finally, here are two images showing off the new menu. The file loaded is Three Men in a Boat. If you don’t want to wait for the next release[3], you can build from repo source and start using this right now.


[1] Sigil looks for a normal <img> tag or an SVG <image> one.

[2] It’s a terrible idea, and it would probably wreak havoc on unsuspecting Reading Systems. The spec actually doesn’t explicitly allow it, it just doesn’t talk about this possibility at all. I’m still not convinced that the spec writers didn’t just forget to forbid this behavior.

So Sigil won’t let you do this.

[3] Which will be RC1. No more betas! :)

Tuesday, April 20, 2010

QtWebKit 2.0 AKA pigs flying

So by now, you should know that QtWebKit is slow. Damn slow. If you don’t, refresh your memory.

If you're performing an editing operation in Sigil, and the UI blocks for 10+ seconds, it’s QtWebKit. If you’re loading a large HTML file into the Book View and everything grinds to a halt for 30+ seconds, yeah, that’s still QtWebKit. I’m not saying all the code I write is perfect (far from it), but QtWebKit has a special place in my heart of hatred.

Back in that loading performance post I linked, I talked about how it takes 75 seconds to load Three Men in a Boat in Sigil 0.1.9. Some of the Linux users may have been confused by that, since on comparable hardware, it would load much faster on a Linux machine.

And it’s true. Sigil performs about an order of magnitude faster on Linux than on Windows. Why is that?

Well it’s because while Qt is thoroughly tested on Windows, it’s certainly much less tested than on Linux. Qt developers are Linux users, and a lot of them are KDE developers as well. So the machines they use don’t run Windows. It’s a lot like the Sigil UI being fine-tuned for Windows, since I use it and develop on it almost exclusively.

So when there’s a performance regression in Qt on Windows, there’s a fair chance someone at Nokia will miss it. And they did.

The test case I attached to the bug report loads in 55 seconds on Windows and 6 seconds on Linux. Bear in mind the same test case renders instantaneously in Firefox, and probably also in Safari (although I haven’t tested it) which uses vanilla WebKit. Horrible, I know. They’re finally coming around to fixing that, since the bug is now included as one of the “release critical” bugs for QtWebKit 2.0 (which is now officially a separately released project from Qt). That means they’ll kill it before the next release, which should be sometime in May (Qt 4.7 a couple of months after that).

Here’s to pigs flying.

…and another thing

Remember the font variants issue preventing official font embedding support in Sigil? The QtWebKit bug causing the underlying problem has been tracked for the last eight fifteen months on their various trackers, and I’ve been told just a few days ago that it’s “not considered critical to the release” of QtWebKit 2.0… which probably means it won’t be fixed for at least another six months.

I ♥ Nokia.