Enhance the title in the "current position" Locator returned by the navigator

[llemeurfr]

The title is currently the title of the publication.

It should be the title of the current spine item (https://github.com/readium/architecture/tree/master/locators).

[HadrienGardeur]

Just adding my 2 cents: I'm not a fan of displaying a title when reading. I'm fine seeing it when I tap in the middle of a page on mobile, but otherwise I find this more annoying than useful.

For a desktop app, there should always by a full screen mode that doesn't display a title IMO.

[llemeurfr]

Better, this title should be related to the ToC if it exists. The issue being that a spine item may correspond to N entries in the ToC, of different levels (e.g. chapter, sub-section ...) and a spine item may not have any corresponding entry in the ToC. Also, many books have to title on their spine items.

@HadrienGardeur in the case of our end user app Thorium, the title of the current location is displayed at the will of the user, so no issue there.

[JayPanoz]

Not sure those cases are covered in

The issue being that a spine item may correspond to N entries in the ToC, of different levels (e.g. chapter, sub-section ...) and a spine item may not have any corresponding entry in the ToC. Also, many books have to title on their spine items.

So, to be on the safe side, taking the liberty to list re books whose several spine items can be a fragment of a chapter because…

• at some point the RMSDK didn’t support more than 250 or 300 KB per file so Gutenberg ebooks for instance, have their chapters arbitrarily fragmented after an amount of characters I believe;
• or you have an image with a portrait aspect-ratio and it was a lot easier at some point to put it into its own XHTML file and continue the current chapter in another file;
• or the heading is its own page and it was a lot easier at some point to put it into its own XHTML file etc. (see above);
• probably other stuff as people can get very creative when they encounter an issue and they have to find a solution.

[danielweck]

The current implementation populates locator.title by extracting DOM head > title from the referenced HTML document (by the way, not necessarily spine/reading order, but also ancillary resources).
Could you please suggest an alternative technique?
(the ReadiumWebPubManifest link title is generally not available, and mapping the TOC links seems like a lot of responsibility for the navigator component?)

[JayPanoz]

Personally I don’t, as I know how difficult that can become once you account for the corner and edge cases.

All I can say is that DOM’s <title> is probably what a lot of authors would expect, with a fallback on OPF’s <dc:title>. This at least has been consistent will all the discussions I could have in an e-production context.

But then, I don’t have any clue what would generally be expected i.e. outside of this e-production context.