Newb is editing ToC code - Is filepos important in the href attribute?

[jg56]

Hi all,

Although I’ve never dealt with the internals of an eBook or Calibre, I’m helping a friend (who considers me more technically competent) to edit a Table-of-Contents that was missing a section.

Tools:Table of Contents:Edit Table of Contents was simple to use - just created a new entry and pointed it to the destination.

But there already was some sort of alternate ToC at the end of the e-book. I duplicated a block of ToC code (which pointed to a different section) and edited it as seemed appropriate. It apparently works but is missing one thing: filepos

source:
<a href="index_split_001.html#filepos1010”><span class="bold"> …
or
<a href="index_split_003.html#filepos6701”><span class="bold"> …

my edit:
<a href="index_split_002.html#"><span class="bold">

Seems to work, but is that numerical filepos important? Where can I find that position number for index_split_002.html? Or is that number just a comment, or redundant?

Thank you.

[pdurrant]

it's a reference to a position marked in the file. The 'filepos1010' is arbitrary - there's a matching destination in the file.

If your toc entries only need to point to the start of html files, then no # reference is needed.

[theducks]

if you remove filepos, remove the #
it is part of the link/anchor
Without the #filepos12345, it is just Top-o-File

[phossler]

But there already was some sort of alternate ToC at the end of the e-book.

I've found that if an ebook has been Calibre-converted (esp multiple times), there's often multiple TOCs are the end since there's a default conversion option to add a TOC at the end

I just delete them all the TOC HTMLs in the editor and add my own TOC using the editor Insert TOC based on Hx tags

[jg56]

Thanks to everyone for the details of the href/#anchor (and re-assurances).

The (single) end-of-book ToC was rather complex and dense with code (I did not try the beautifier). Replacing it is certainly a thought. If I recall correctly when briefly toying with with Calibre's ToC generation, the result was a sparse, clean HTML page using li tags or maybe li class=.

Must confess my ignorance to the community. I had no idea e-books were commonly HTML-based. Just never thought about what was under the hood. Also have to admit the last time I made a web-page it was by hand and pre-CSS...

I think I'm going to try to find the time to get to know Calibre better. (Hope this forum wouldn't mind another question or two in future.)

[JSWolf]

Originally Posted by phossler

I've found that if an ebook has been Calibre-converted (esp multiple times), there's often multiple TOCs are the end since there's a default conversion option to add a TOC at the end

I just delete them all the TOC HTMLs in the editor and add my own TOC using the editor Insert TOC based on Hx tags

Why would anyone convert an eBook multiple times? That's just silly.

[phossler]

Originally Posted by JSWolf

Why would anyone convert an eBook multiple times? That's just silly.

Agree

But, there's a lot of PD books out there that have been run through Calibre multiple times over the years (I'm assuming by multiple people) to convert MOBI to EPUB to MOBI and EPUB and AZW3, etc., most probably in bulk

You can usually spot such books by how many TOC's there are at the end, by classes that start with .caliber....., and by how complicated/redundant the style sheets are

[theducks]

Originally Posted by phossler

Agree

But, there's a lot of PD books out there that have been run through Calibre multiple times over the years (I'm assuming by multiple people) to convert MOBI to EPUB to MOBI and EPUB and AZW3, etc., most probably in bulk

You can usually spot such books by how many TOC's there are at the end, by classes that start with .caliber....., and by how complicated/redundant the style sheets are

If the TOC was properly marked (semantics), it would have been replaced.
GIGO
[rant]
It astounds me, the number of coding flaws (and errors) in ebooks purported to have been professionally done. This includes BPH's.

I don't count messy code, as long as it is valid. I don't grade grammar.
I do count inconsistent style (CSS) usage (different chapters use different style names/values for the same type of content
[/rant]

[JSWolf]

Most BPH's eBooks are coded using code like

<p class="CT" id="c01"><b>1</b></p>

Hardly any are coded using header tags for chapter headers.

[theducks]

Originally Posted by JSWolf

Most BPH's eBooks are coded using code like

<p class="CT" id="c01"><b>1</b></p>

Hardly any are coded using header tags for chapter headers.

But that is easy to adjust(if desired) with Diaps toolbox or a simple REGEX.
There is no need, if the NCX is correct. The HTML TOC is created from that.

I am talking about code that either fails to validate or does not work as the code implies.