In earlier posts I have mentioned problems that my Kobo Touch reader is having with an ebook that works perfectly on my Sony T2. The html and CSS in this file validate to W3C standards, and the ePub validates with ePubCheck and FlightCrew.

I have tested all the fonts on the Kobo to see whether they show italics and whether the links work. The test file has some footnotes; link numbers in the text take one to a collection of footnotes in a different file, and this collection has a link back to the original text.

The results are below:

Kobo Touch Font Tests - Font size set to 10

Document Default
This is set to sans-serif in the CSS of the test ebook, but shows as a serif font.
Links: Work
Endnote links: Work going. From Endnotes return to page before the footnote source.
Italics: Work

Amasis
Links: Work
Endnote links: Work going. From Endnotes return to page before the footnote source.
Italics: Work

Avenir
Links: Go to two pages before target
Endnote links: Work going. From Endnotes return to page before the footnote source.
Italics: Show as bolded text, not italic

Caecilia
Links: Work
Endnote links: Work going. From Endnotes return to page before the footnote source.
Italics: Work

Georgia
Links: Go to one page before target
Endnote links: Go to one page before target, return to two pages before target
Italics: Work

Gil Sans
Links: Work
Endnote links: Work going, return one page before target
Italics: show as bolded text, not italic

Kobo Nickel
Links: Work
Endnote links: Work going, return several pages before target
Italics: show as bolded text, not italic

Malabar
Links: Go to one page before target
Endnote links: Work going, return one page before target
Italics: Work

Gothic MB101
This is a sans font, and is noticeably bigger than the other fonts
Links: Go to one page before target
Endnote links: Work going, return one page before target
Italics: Work, but font size noticeably smaller than normal font

OpenDyslexic
Links: Go to one page before target
Endnote links: Work going, return one page before target
Italics: Work

Some of the italic/not italic problems are no doubt the fault of the way the that type face is designed, or implemented in the Kobo, but I am sure that the link and footnote problems are the fault of the Kobo designers. Let me repeat and emphasise that the links work perfectly well when the same ebook is read on my Sony.

It will be interesting to see how Kobo customer service responds. That's my next stop.

That is an interesting set of results. The missing italics is a long term issue. I have no idea why Kobo haven't fixed it.

Two thoughts:

- What were the margin settings on the device when you did this? There is a bug in the current firmware that if the margin settings are not the minimum, when a book is reopened, it goes to a page or two earlier than when it was closed. I could see this affecting link navigation as well, but I'm not sure. This should be consistent across the fonts, but, there may be something else going on.

- For the page numbers, did you have the page numbers displayed in the margins? What I am wondering is if the navigation was going to the first screen for a page number.

I initially set the margin as far to the left as it would go, then clicked the + icon twice, and left it there while testing each of the margins. For some of them I noticed that the margin had reset itself about a quarter over from the left, but didn't do anything about that. It didn't seem to make any difference with the links, but I didn't test it. In fact I remember now that in one of the testing sessions not only did the indicator on the line move over but the margins of the ebook became very wide. I just set the margin back to +2 and started over.

The page numbers are not visible on the ebook right side margin as they are in ADE. There is a message at the bottom of the screen (taking up valuable reading space) saying PG 3 OF 13. Is this the page number you mean? Is there a way of turning this off?

I initially set the margin as far to the left as it would go, then clicked the + icon twice, and left it there while testing each of the margins. For some of them I noticed that the margin had reset itself about a quarter over from the left, but didn't do anything about that. It didn't seem to make any difference with the links, but I didn't test it. In fact I remember now that in one of the testing sessions not only did the indicator on the line move over but the margins of the ebook became very wide. I just set the margin back to +2 and started over.

I can see why you did it that way and as a programmer, I love seeing a tester who makes their tests consistent

The margins are sort of interesting. Up until FW2.3.1, if they were set in the ePub, the Kobo devices did not override them. Which I thought was good. In FW2.3.1, the margins are additive. What you set on the device is added to whatever is in the book.

Was your testing with only one book? A reason for the changes you saw is that the device stores the settings for each book if you make changes. It also save these settings as the defaults to use for any new books.

Quote:

The page numbers are not visible on the ebook right side margin as they are in ADE. There is a message at the bottom of the screen (taking up valuable reading space) saying PG 3 OF 13. Is this the page number you mean? Is there a way of turning this off?

I was talking about the ADE style page numbers. There is an option to display them. When the menu is open a the bottom of the screen, select the spanner icon and then "Reading Settings". The option is on page two.

The bottom page number can't be turned off. If it could, it would be very popular, though I don't know if I would.

Was your testing with only one book? A reason for the changes you saw is that the device stores the settings for each book if you make changes. It also save these settings as the defaults to use for any new books.

I didn't know that! I think that's stupid! If I've made changes to a book as I'm developing it I want the new settings to be in force, not what I've just corrected. And I certainly don't want the settings for the poetry book I'm working on now to be the settings for the novel I might do next.

I've had endless trouble with authors for whom I've developed mobi ebooks. Unless they do as I ask them and remove all traces of the previous version the new version won't overwrite the previous version. So they don't see the changes or correction I've made. If I understand you correctly I'm likely to have the same problem with Kobo owners.

I didn't know that! I think that's stupid! If I've made changes to a book as I'm developing it I want the new settings to be in force, not what I've just corrected. And I certainly don't want the settings for the poetry book I'm working on now to be the settings for the novel I might do next.

It is a little different, but I don't completely disagree with it. I like that I save the settings for each book. And I like I can change the default settings. But, the latter is done in a not that obvious way. I would like a way to deliberately save default settings and then reload these when I want to.

Quote:

I've had endless trouble with authors for whom I've developed mobi ebooks. Unless they do as I ask them and remove all traces of the previous version the new version won't overwrite the previous version. So they don't see the changes or correction I've made. If I understand you correctly I'm likely to have the same problem with Kobo owners.

As a software developer, I completely understand the problem. And that's why I might seem a little pedantic in my statements above.

For the Kobo owners, telling them to delete the book using the device should be enough. This will remove the book and details from the database. When they load it again, it uses their current default settings. If they are a calibre user, they can delete it from the device using calibre and send it again. If they just send it, then the device might delete it when it processes new books after disconnection. It checks the file size, and if this is different that what it has recorded, it removes the book.

With that comment, something you might be interested in is the annotations. Any annotations made on the device to an ePub are stored in a file. These are under "Digital Editions\Annotations". Look for a file with the extension "annot" and the same directory and file names as the epub. You can copy these between the Kobo devices as long as all the names are kept the same. That way someone can make annotations while reading the book, and you can see them. You can also use it with ADE on the PC, but that is a little trickier.

It seems from your description (I don't have a kobo device) that one of the footnote links issues is that the link could be too small. A single "1" on a small screen (especially with small font) would be hard for the device to detect a touch.

Why not make the hyperlink a little larger - include more of the surrounding text. Unless there are two adjacent links that should not be a problem.

e.g.
instead of:
<p>This is a test link[<a href="..." id="link1">1</a>]</p>
you could use:
<p>This is a test link<a href="..." id="link1">[1]</a></p>
or even:
<p>This is a test <a href="..." id="link1">link[1]</a></p>

The only downside I could see is that link[1] would all be formatted as a link (ie. blue, underlined). I personally don't like links formatted like that - I remove all formatting and assume that the reader will intuit that it's a link based on it's content - but that's me. If you want just the numeral formatted that could easily be fixed with css and a span:

a {color:inherit;text-decoration:none;}
a span {color:blue; text-decoration:underline}

As an habitual Sony reader I am accustomed to using a stylus when I need to, and I used a stylus on all the tests I did just so I could exclude that variant. Actually, I don't need to use a stylus on my Sony, but can always get the footnote links to work - they go to the endnote when I touch the link, and go back to the right place when I touch the link in the endnote file.

For what it is worth here is the CSS I use - learned from one of weatherwax's ebooks.

<span class="fn" id="F1"><a href="Endmatter.html#N1">[1]</a></span>

<p id="N1"><a href="#F1">[1]</a> Endnote text goes here</p>

a.footnote {font-size: small; vertical-align: text-top;}

The numbers are of course changed for the individual endnotes.

A few days ago I sent a slightly changed version of my post #31 to Kobo Customer Assistance, and tonight I got a reply to the effect that the post had been sent up to the tier 2 team.

A stylus - how novel! Lol
Well, now I'm intrigued. Please share their response when you get it. I did notice that your CSS references "a.footnote" but the class calls for "fn". Also it appears you have all the footnotes in a separate file (Endnotes.html). If you want the back link to work you need to put the filename in front of "#F1". I assumed you were just giving an example, but you might check that.

I have a question of my own. When you create your link is there a specific reason for the span tags around the <a></a>?

I usually try and absolutely minimize the number of tags and would have just put the class and id within the link:
<a class="footnote" id="F1" href="...">...</a>

I have indeed put the filename in front of the #F1, just as I've changed the number as more endnotes were added. As I've mentioned in earlier posts the test file I used works perfectly well on my Sony. The questions I'm asking are about designing for the Kobo, not about html or ePub.

As far as the link I have seen them done this way many times. That's how I do them. And I'm not aware of a reason to put a span around them - that's why I was asking. You never know what Feature will be added to these readers...
I would just use:

I have indeed put the filename in front of the #F1, just as I've changed the number as more endnotes were added. As I've mentioned in earlier posts the test file I used works perfectly well on my Sony. The questions I'm asking are about designing for the Kobo, not about html or ePub.

It turns out that in iOS, even if you delete a book entirely from within Kobo, if you then re-add the same book without explicitly killing Kobo in the task switcher, you'll find yourself looking at the old copy of the book. This fooled me into thinking that the bug was fixed, when in fact I was actually looking at a newer copy where I had worked around the bug.

So if you want compatibility with Kobo for iOS, do not under any circumstances set the left and right margins on the body tag to zero.