Indexes without page numbers?

[SigilBear]

Consider the following example from an index from a book in the public domain:

State Trees, 354-7; of, Idaho, 354-5; Illinois, 355

If I turned this book into a reflowable epub, then the page numbers wouldn't make sense. So how do most epub authors handle this kind of situation?

Since epubs are searchable, I've thought of just creating a static index (i.e. no links) that lists key words that readers can then search for. (However, it wouldn't work for the example I posted above, which would have to be customized somehow.)

Have you ever seen such an index in an epub?

[PeterT]

Why not have State Trees be a clickable link to the start of text on page 354 (or in fact the first applicable item) and the same for of, Idaho etc.

[SigilBear]

That's what I was thinking; make an index that consists primarily of plain text (not hyperlinked), but link things that are harder to search for, like "state tree."

For example, if "Charles Murphy" is indexed to three separate pages and "John Ledyard" is indexed to two pages, then the index might look like this:

Ledyard, John
Murphy, Charles

...letting readers know these subjects exist. They could then do a simple search to find all occurrences of those names.

[GeoffR]

EPUBs can have page numbers in the form of a <pageList> section in the ncx that maps page numbers to html locations. Not all ereaders support it, but there is no harm in including it.

Then you can use a belt and braces approach and also link the page number in the index to the page location in the html with a normal hyperlink, so those ereaders that don't use the pageList can still use the hyperlinks.

[Doitsu]

Originally Posted by GeoffR

EPUBs can have page numbers in the form of a <pageList> section in the ncx that maps page numbers to html locations. Not all ereaders support it, but there is no harm in including it.

@SigilBear:

Shameless plug: I created a simple Sigil plugin for generating pageList sections and Sigil has a built-in index generator (Tools > Index > Index Generator).

However, AFAIK, I don't know of any epub2 app that actually displays pageList page numbers. (ADE displays page numbers, but they need to be defined as page maps, and if you include a page map the book will no longer pass epubcheck.)

If you decide to embed page number targets, you might want to convert your epub2 book to an epub3 book, because then at least iBooks and Azardi users will be able to enable the display of printed page numbers.

If you decide to convert your epub2 book to an epub3 with the Sigil epub3 output plugin, remember to update the NCX TOC via Tools > Epub3 Tools > Generate NCX from Nav once you've finalized the book.

[Tex2002ans]

Originally Posted by SigilBear

That's what I was thinking; make an index that consists primarily of plain text (not hyperlinked), but link things that are harder to search for, like "state tree."

I would say most publishers lately have been removing the Index completely, some leave the plain text Index in the ebook (that is what I tend to prefer), and others might hyperlink all the "page numbers" in them.

I can't say I've seen one that mixes up plain text + hyperlinked words though.

Originally Posted by SigilBear

Consider the following example from an index from a book in the public domain:

State Trees, 354-7; of, Idaho, 354-5; Illinois, 355

If I turned this book into a reflowable epub, then the page numbers wouldn't make sense. So how do most epub authors handle this kind of situation?

IF you wanted to do a hyperlinked Index, the typical code looks like this:

You insert a link where the page break occurs (Page 354+355):

Spoiler:

<h2><a href="#page354">Chapter IX</h2>

[...]

<p>Whereas, the members of Ellen Wright Camp, Franklin County Chapter, Daughters of Pioneers, by resolution, <a href="#page355">have asked that the White Pine be designated as the state tree of the State of Idaho.</p>

Then in the Index you would have to create all the links back:

Spoiler:

State Trees, <a href="../Text/Chapter09.xhtml#page354">354</a>-<a href="../Text/Chapter09.xhtml#page357">7</a>; of, Idaho, <a href="../Text/Chapter09.xhtml#page354">354</a>-<a href="../Text/Chapter09.xhtml#page355">5</a>; Illinois, <a href="../Text/Chapter09.xhtml#page355">355</a>

Side Note: In this specific case, it would be even more of a giant pain in the ass to generate + check links for the condensed form of numbers: 354-7 = 357.

Originally Posted by SigilBear

Since epubs are searchable, I've thought of just creating a static index (i.e. no links) that lists key words that readers can then search for. (However, it wouldn't work for the example I posted above, which would have to be customized somehow.)

Have you ever seen such an index in an epub?

Last time Indexes were brought up was in this topic, "Real Page Numbers for Reflowable Kindles":

https://www.mobileread.com/forums/sh...d.php?t=279004

We went into very in-depth discussion on "Page Numbers" in ebooks (and how meaningful they are), how to do Indexes, Indexes compared to search, etc. etc.

[SigilBear]

Originally Posted by Doitsu

@SigilBear:

Shameless plug: I created a simple Sigil plugin for generating pageList sections and Sigil has a built-in index generator (Tools > Index > Index Generator).

Thanks, I'll check it out.

Af for Epub2 and Epub3, those are just different versions, right? My understanding is that it all began with Epub2 (or something even more primitive), but people are now creating Epub3 files.

Anyway, I've been saving all my projects as Epub3.

[SigilBear]

Originally Posted by Tex2002ans

I would say most publishers lately have been removing the Index completely, some leave the plain text Index in the ebook (that is what I tend to prefer), and others might hyperlink all the "page numbers" in them.

That's good to know.

I think even an index without links would be helpful, just to give people a quick look at the various things discussed in the book.

In fact, I've thought about creating several separate static indexes, arranged by topic. For example, there could be an index to people's names, another index to place names, etc.

[JSWolf]

An index without links isn't useful. If you are creating an index, add in the links.

[Jellby]

If the book has chapters/sections, you could use them instead of page numbers (still the links should point to the right place in the text, not just to the beginning of the chapter). If there are several occurrences in the same chapter, you add letters, like 1-a, 1-b, 1-c, etc. Or you could simply use some dingbat or bullet as a placeholder for the link.

A note of caution, when an index in paper says 354-7, it could be that a single passage that spans the 4 pages refers to the term, or it could be that there are at least 4 different independent occurrences of the term that happen to be in pages 354, 355, 356, 357. The former case would need a single link, the latter four links. Even worse, a single page number could actually hold several independent occurrences of the term, which would require several links... So, if you don't want to keep the page numbers, you'd have to practically redo the whole index.

[Toxaris]

Originally Posted by SigilBear

Thanks, I'll check it out.

Af for Epub2 and Epub3, those are just different versions, right? My understanding is that it all began with Epub2 (or something even more primitive), but people are now creating Epub3 files.

Anyway, I've been saving all my projects as Epub3.

Version 2 was the version that really gained momentum as e-book format. Version 3 is an evolved version, but it has been received with mixed feelings to say the least. It has some good parts and some bad parts. Especially the whole part with regards to Javascript and for some the audio/video part was unnecessary and will not work anyway on a e-ink reader. Some real gripes with version 2 were not addressed at all and stuff that almost nobody needed (I am looking at Apple here) got in.
All in all, ePUB3 did not take off as planned. Mainly because the support is lacking and it is only backwards compatible to a certain point. The reading application that support ePUB3 can read ePUB2, but not the other way round. So, a kind of mixed form has been created which has parts of 2 and parts of 3 and somewhat works. It is not ideal at all.

The most common approach nowadays is that if you need features in ePUB3, use ePUB3. Otherwise use version 2.

One additional thing, how is version two 'primitive'?

[IronChaim]

The lastest version of EPUB (3.1) has an optional spec (http://www.idpf.org/epub/idx/) that might help with your idea. But, a reading agent has to support it (which they're not required) - and sometimes readers already have a 'search' function built in (so slightly duplicating the effort).

To your original issue:

If I turned this book into a reflowable epub, then the page numbers wouldn't make sense. So how do most epub authors handle this kind of situation?

I don't recall if there's any "official" position on how to do this since, as you mention, the text is reflowwable and the idea of a 'page' falls apart. Amazon has their own schema on how to determine page numbers for reflowable content (I think it's based on amount of characters? No clue really). Other readers show a page number, but that's just based on the current font and screen size (so it'd dynamic and will change user to user).

Another quirky way I saw was an EPUB that used the Header/Footer support for EPUB to identify what amount content corresponded to the physical page of that book. Seems like a lot of work, and you still need a reading system that will pickup that info and display it - but again that's a page on the physical book. A user opening the same EPUB in a different reader that doesn't use that same technique, may see completely different page numbers (so any citation/location is kind of moot).

IMHO: This seems like a lot of work to apply a 'fixed' page number to something that's meant to be not-fixed. If you're really need some absolute definition of 'physical' location, just keep to a Fixed-Layout EPUB3 instead.

[fbrzvnrnd]

Hi, I usually create Indexes like the one I attach (a screenshot from "Syria Calling" ePub). I think this is a good way to allow reader to follow link inside the ebook and have a way to differentiate the multiple instances of a word inside a single chapter.

[SigilBear]

Originally Posted by Toxaris

One additional thing, how is version two 'primitive'?

I was working through a series of InDesign tutorials @ Lynda.com, and, as I recall, their instructions were to generally ignore 2.0 and save as 3.0 instead.

[Tex2002ans]

Originally Posted by SigilBear

In fact, I've thought about creating several separate static indexes, arranged by topic. For example, there could be an index to people's names, another index to place names, etc.

All depends on the book, and the Index you have to work with. (Designing good Indexes are a whole other beast.)

For the most part, I would just keep the Index the way it is... it would save you the most headaches and wouldn't do any harm.

Doing a simple change like going from paragraph form -> indented form is an easy change (and I would recommend for readability):

Spoiler:

Spear, depicted on State seal of, California, 247; Idaho, 192; North Dakota, 238; South Carolina, 211, 249; Virginia, 217, 247, 248

to:

Spoiler:

- Spear, depicted on State seal of
--- California, 247
--- Idaho, 192
--- North Dakota, 238
--- South Carolina, 211, 249
--- Virginia, 217, 247, 248

The paragraph form is harder to read and doesn't make much sense in an ebook... the paragraph form was really chosen only to save paper.

But going from a single Index into multiple is most likely going to be a much more extensive + harder change. What about author names that were only mentioned because of a book that was referenced? Do you split states into their own Index too? What if the state occurs as a subentry?

A lot of this stuff really just has to be decided ahead of time by the indexer before they begin indexing. Changing the organization in such a major way, while having the greatest of intentions, might make the Index as a whole worse than before.

Originally Posted by Jellby

A note of caution, when an index in paper says 354-7, it could be that a single passage that spans the 4 pages refers to the term, or it could be that there are at least 4 different independent occurrences of the term that happen to be in pages 354, 355, 356, 357. The former case would need a single link, the latter four links. Even worse, a single page number could actually hold several independent occurrences of the term, which would require several links... So, if you don't want to keep the page numbers, you'd have to practically redo the whole index.

Yep... and there is no way of knowing without reading the material itself multiple times over. And not every occurrence of the term deserves an Index entry (see the discussion in "Real Page Numbers" thread on Search/Concordance =/= Index).

A single page number is deceptive and can quickly bloat itself to many minutes of work... multiply that by thousands of entries, and digitizing an Index properly in this way quickly expands to WEEKS/MONTHS of work.

Originally Posted by Toxaris

The reading application that support ePUB3 can read ePUB2, but not the other way round. So, a kind of mixed form has been created which has parts of 2 and parts of 3 and somewhat works. It is not ideal at all.

The most common approach nowadays is that if you need features in ePUB3, use ePUB3. Otherwise use version 2.

Yep, and I would parrot a lot of what Hitch always says... "There are still millions of older devices out there that aren't going anywhere any time soon."

Originally Posted by IronChaim

The lastest version of EPUB (3.1) has an optional spec (http://www.idpf.org/epub/idx/) that might help with your idea. But, a reading agent has to support it (which they're not required) - and sometimes readers already have a 'search' function built in (so slightly duplicating the effort).

Back in 2013, Infogrid Pacific (the company behind AZARDI) wrote this blog post about the EPUB3 Index spec:

http://www.infogridpacific.com/blog/...ndex-spec.html

I tend to agree with the assessment... it is an unmaintainable disaster. (And on top of that, nothing supports it, nor do I suspect anything ever will.)

Originally Posted by SigilBear

I was working through a series of InDesign tutorials @ Lynda.com, and, as I recall, their instructions were to generally ignore 2.0 and save as 3.0 instead.

Adobe + many of those InDesign people tend to lean towards iBooks only... and/or making things look ok on the surface (I was absolutely horrified when I saw the code in the Fixed Layout EPUBs out of InDesign, and a nice chunk of my conversions are cleaning up InDesign cruft).

With your books you want to reach the widest possible audience, not locking yourself to a small subset of the market. And you want the books to look good on all devices (and have proper fallbacks), not just look good on iBooks and look like ass on everything else.