Detect current child chapter

[yelyzaveta-kartseva]

Hey! Some of my epubs have chapters of different levels. Also app should show book contents with all chapters listed. So on book opening I fetch contents using
publication.tableOfContents()
draw tree of contents and for each Link (vReadiumShared.Link) using publication.locate(link) I generate object of Locator (for user to be able to tap and go there). The problem is I need to mark inside view of contents which chapter user is reading right now, but current locator does not show inside which child chapter user is. Like it shows (using href and title) that I'm under chapter1 (level 1), but even though I'm under chapter1.1 (level 2) href still leading me to it's parent -> chapter1 (level 1).
How using current locator updates know inside which child chapter user is?

[yelyzaveta-kartseva]

Also, why converting ReadiumShared.Link to Locator I do not get position, but when I'm receiving current locator for that exact place in book I actually received position (locator.locations.position). I need at least position to show user that this chapter is under that "page" (which is actually a position) at contents view.

[yelyzaveta-kartseva]

For example I have chapter with level 1 and it's href is "OEBPS/Text/Section0005.xhtml". It has several children (subchapters with level 2) and while converting them (to my in-app object and also extracting Locator out of ReadiumShared.Link) I get locators with right href (example: "OEBPS/Text/Section0005.xhtml#sigil_toc_id_2") and also each of converted locators have it's own title, which corresponds to subchapter title.
But when I'm even move using child chapter locator, inside delegate method func navigator(_ navigator: Navigator, locationDidChange locator: Locator) I get locator with href and title that point me not to sub chapter (chapter of level 2, which I'm reading) but to it's parent chapter of level 1.

▿ {"href":"OEBPS/Text/Section0005.xhtml","locations":{"position":15,"progression":0.1276595744680851,"totalProgression":0.049469964664310952},"title":"Передмова","type":"application/xhtml+xml"}
  ▿ href : OEBPS/Text/Section0005.xhtml
    ▿ relative : OEBPS/Text/Section0005.xhtml
      ▿ url : OEBPS/Text/Section0005.xhtml
        ▿ _url : <_SwiftURL: 0x6000022275c0>
  ▿ mediaType : MediaType
    - type : "application"
    - subtype : "xhtml+xml"
    - parameters : 0 elements
  ▿ title : Optional<String>
    - some : "Передмова"
  ▿ locations : Locations
    - fragments : 0 elements
    ▿ progression : Optional<Double>
      - some : 0.1276595744680851
    ▿ totalProgression : Optional<Double>
      - some : 0.04946996466431095
    ▿ position : Optional<Int>
      - some : 15
    ▿ otherLocationsJSON : JSONDictionary
      - json : 0 elements
  ▿ text : Text
    - after : nil
    - before : nil
    - highlight : nil

[yelyzaveta-kartseva]

For some books I even get situation with chapters (even root ones with level 1) when ReadiumShared.Link href is different (I mean even relative url) from locator object href I get when reading even though I'm on that exact place in the book (navigate with chapter of level 1 locator, get current locator update, that update href is completely different from chapter href)

[mickael-menu]

Thanks for reporting this issue. Unfortunately, Readium does not currently support detecting which table of contents item is currently visible to the reader. This is a known limitation that we are aware of.

We are planning to implement this functionality as part of a new "Timeline API". However, we don't have an estimated timeline for when this will be available yet.

Regarding the issue you mentioned with locate(Link) not returning a position in the Locator, this is intentional. To provide accurate positions for table of contents items that use HTML fragment identifiers, we would need to parse and open all the HTML files in the publication to resolve where those IDs are located within each file. This would need to happen when generating the table of contents, which would significantly slow down the process and increase resource usage. This is something we specifically want to avoid. We might be able to work around this limitation in the future Timeline API, but we're not certain yet how we'll approach it.

[yelyzaveta-kartseva]

Thanks for your reply! Looking forward for new Timeline API