Quote:
Originally Posted by PeTrDu
@roger64:
Well, after checking the epub,
the only thing that I see it disappears it's the last <nav> section and its because it has the "hidden" attribute:
Code:
<nav ... hidden="" ...>
...
</nav>
That hides it in any webbrowser, and also in Sigil preview and book view (but not in code view, of course).
LibreOffice doesn't hide it, probably to be able to edit it.
I can remove the hidden="" part, but I think it's better not to do it. If you hide something with attributes or with css styles it's for some reason, isn't it?
The links works OK with any web-browser, but in LibreOffice, with the Ctrl+click to a link, some links works, other doesn't... I suppose it's a weird LibreOffice bug when it loads html files.
In the end, I'm afraid there's nothing much I can do about it.
I'm sorry about that.
On the other hand, with the test I found out a bug: the font files weren't properly linked, it will be fixed next version.
|
Thanks for your findings.
Good to know it's a LO bug. I did not try the links on a web browser. I tried also a commercial book where only the return links were working in the odt file. For information, there is a very fine plugin in Sigil,
FootnoteLinker, which has been conceived precisely to reestablish quickly broken links on an ePub. I used it once for a book with one thousand links...
The hidden=" " attribute in the nav file is produced by the new
Access-Aide Accessibility helper plugin. This "landmarks" part of the nav is to be machine readable only. Don't bother with this, it can be reestablished later very easily on the new ePub if need be.
I found that some books use a double chapter title, I mean two successive h1 (which I don't like but I can't help). This is translated by two <h1> tags with a pagebreak between (which is a normal "clean" behaviour). It's not that easy to batch glue them together. Any advice?
Edit: after further testing, this is to confirm that the major question is that LO converts this amazingly precise file to odt in a somewhat shaky way. And this part (html>odt) is 100% out of control of the plugin. To say it clearly, I was wrong to draw hasty conclusions about this plugin from the look of the odt file.