About navpoints and their ids

[roger64]

Hi

Sometimes we have to rebuild the toc.ncx file and replace the existing one. The Calibre editor does it very well.

I remarked that all the newly created navpoints ids coming from the Calibre editor use uuids, instead of a "natural" incremental value (like text1, text2, etc.).

I would have better limit the use of uuid exclusively to the book identifier because it's a very unfriendly qualifier and not for such common things like navpoints ids. However, when I looked how to replace these uuids with incremental values, I realized that it seemed a complicated thing to do, either using CSS or worse even regexes, which may explain Kovid Goyal's choice.

Has somebody found a simple way to insert incremental values in EPUB (for navpoints ids or for some other use?). If I use Sigil 6.2 to rebuild the toc.ncx file, I will obtain incremental values for navpoints ids (navpoint-1; etc.) so there should be a way?

[Divingduck]

Guess, you like to use it for generating chapter numbers in a toc, there is an other way you can go with the editor:
Generate your Toc with the toc generator and then mark all entries, make a right click and do a bulk rename of all selected items.

[roger64]

@Divingduck

Thanks for your input but I refered about the toc.ncx file and its navpoints ids.

Calibre use uuid for them and Sigil use incremental values (like 'navpoint-1', 'navpoint-2', etc.). In fact, if you open one EPUB with Sigil and type Ctrl-T, it will rewrite your toc.ncx file and make use of these incremental values.

I was just saying that the incremental values (à la Sigil) seem to be more handy than cumbersome uuid. Both are unique identifiers, at least for the file. I wish I could obtain the same result directly with Calibre.

[DiapDealer]

This is strictly an aesthetic wish, correct? I mean ... once those IDs are created (and are unique), you need not fiddle, adjust--or even look at--them again. I understand wanting simpler, more easily modified code, but this seems to me to be a situation where it just doesn't have any bearing on anything (other than not liking how it looks). The fact is, navpoint ids never need to be adjusted, tweaked, or are even used by any other markup in the ebook. They just need to be unique. They could only be considered "cumbersome" if you actually needed to do anything with them (other than make sure they're there).

If it's that important to you have more aesthetically pleasing navpoint IDs, why not just capture the PlayOrder numeric attribute in a regex search that will allow you to replace the uuid with a simpler, custom ID of your choice based on the incrementing PlayOrder digit(s) you captured?

[Divingduck]

As well a good hint to use the playorder digits.

[roger64]

Hi

Of course it's a wish and a personal taste.

Thanks anyway for the playorder tip. I will nevertheless follow on using Ctrl-T with Sigil to make these cumbersome uuids disappear (one for the book id is enough for me).

[DiapDealer]

Originally Posted by roger64

I will nevertheless follow on using Ctrl-T with Sigil to make these cumbersome uuids disappear (one for the book id is enough for me).

I still believe cumbersome is not an accurate word in this regard.
"Lengthy-string-you-don't-like-looking-at-very-much" ... sure.

[roger64]

Originally Posted by DiapDealer

I still believe cumbersome is not an accurate word in this regard.
"Lengthy-string-you-don't-like-looking-at-very-much" ... sure.

OK. When I find thirty of them in a row, my head spins... (it's fragile)

Regarding the play-order attribute, I read in the specs:

NCX documents that do not contain a DOCTYPE may omit the playOrder attribute.

which seems to apply to the EPUB done with Calibre, but it's probably safer to keep them.

Let me remark also that the navpoint id must be a unique identifier. If I select only the play-order number to replace them (i.e. a plain number with single or double digits), it seems very probable that this number will NOT be an unique identifier suitable for this purpose. If I name them, 'text1', ou 'navpoint-1' (the Sigil way), this risk disappear.

[DiapDealer]

Originally Posted by roger64

Let me remark also that the navpoint id must be a unique identifier. If I select only the play-order number to replace them (i.e. a plain number with single or double digits), it seems very probable that this number will NOT be an unique identifier suitable for this purpose. If I name them, 'text1', ou 'navpoint-1' (the Sigil way), this risk disappear.

I never suggested using the play order number alone. But that number should be unique (if the playorder exists in the ncx). If it wasn't, adding 'text' or 'navpoint-' in front of it wouldn't help make it so.

Play orders don't have to be consecutive, but they can't repeat if present. So if they ARE present in your epubs, it should be trivial to create your "prettier" (and still unique) navpoint id from them using regex search and replace.

[roger64]

Thanks.

Nota: I finally found how to objectively qualify uuids for navpoint ids. They are not "cumbersome", it's just an "overkill".

[DiapDealer]

Originally Posted by roger64

Nota: I finally found how to objectively qualify uuids for navpoint ids. They are not "cumbersome", it's just an "overkill".

I have no semantic objections to "overkill."

[eschwartz]

Might this have anything to do with your aesthetic objection?

https://github.com/kovidgoyal/calibr...6ac2e67bb5aabe

[roger64]

indeed!!

God has long ears. Let Him be blessed!