FB2 output has been improved. It no longer generated very invalid markup. The
output generator still isn’t where I want it to be though. The changes are
mostly cleanup and fix long standing issues with the output. One major change
is I reverted having
<h1> tags work as section and title markers. I don’t
like having this hard coded into the generator.
As far as I can tell FB2 does not support a true table of contents (TOC). What
seems to happen is reader software will dynamically generate the TOC based on
the appearance of
<section><title><p>text</p></title> within th e text. If
I’m wrong about this and FB2 really does support an external TOC I would love
to know. The
<h1> differentiation causes the files to have these sections. I
do not like how this is hard coded and dependent on this single tag. Especially
since calibre’s conversion process allows for an XPath expression to be
specified to generate TOC point.
I would love to use the TOC sent to the FB2 output generator but this does not
seem to be feasible. The problem with the TOC that is sent to the FB2 output
generator is how it corresponds to locations in the document. The OEB TOC
points are text which may or my not appear in the text and an anchor id. The
anchor id is a set point in the document. FB2 section titles are part of the
text itself. I cannot use the text from the OEB TOC because it may or may not
actually appear in the text. This also prevents me from determining what the
text in the document is supposed to be associated with the TOC point. The
anchor id points to an anchor in the document but often that point is something
<a id="blah" />. In this case there is no text associated with the
anchor in the document. While I can assume the text following is part of the
title I have no fool proof way to determine where it stops.
At this point the only TOC associated with the FB2 output is the inline TOC that can be optionally generated.
Support for two new readers has been added. Ganaxa’s GeR2 and Nokia’s 770 internet tablet. The N770 should have been support a long time ago and I apologize for how long this request has been unfulfilled. I put it at the bottom of my todo list and at some point it simply fell off and I forgot about it.
The GeR2 reader was a bit of a challenge to get supported. This reader and some models of the Cybook Gen 3 have the same vendor, product and revision (BCD) ids. On Windows and OS X this is not an issue because once the ids are matched further matches are done based on the plug and play (PNP) strings. However, on Linux only the ids are matched.
To solve this problem, matching on Linux needed some further checks. Kovid added support for libusb-1 which provides the vendor and product strings. He also added a call back that can be implemented in the device interface to implement platform and device specific checks. We did run into a few problems. The first was an easy to solve 32 vs 64 bit issue with the Python to C interface Kovid wrote for libusb-1. Once that was sorted out we ran into a larger problem. libusb-1 on Ubuntu by default is denied access to the vendor and product strings.
libusb-1, after appearing in only run release (0.6.27), has been dropped. Kovid has now written a custom device scanner for Linux that will parser the devices in /sys/bus/usb to determine if a reader is connected. libusb-1 is supposed to be an easy to use library capable of providing this functionality but unfortunately this turned out not to be the case. The custom scanner works and allowed me to implement differentiation between the GeR2 and the Cybook Gen 3 so both readers can be properly supported without conflict and with the correct device interface being used.