Chapter marks not showing with nested chapters

[hyurte]

On PW4 I find epubs (epub2) with nested table of content entries like

(Begin table of contents)

Part One ........................ 1

Chapter 1 .............. 2

Section A ...... 3
Section B ...... 4

Chapter 2 .............. 5

Part Two ........................ 6

Chapter 3 .............. 7

Part Three ...................... 8

(End table of contents)

don't have the expected number of chapter marks appear in the status bar. In the example above I would expect 8 chapter marks (3 for the Parts (with Part One starting after some front matter), 3 for the Chapters, 2 for the Sections) but only 5 appear:

• Section A
• Section B
• Chapter 2
• Chapter 3
• Part Three

Have I missed a setting in KOReader?--please tell me what and don't read anymore since you understand the situation. Is this a known imperfection that no one else is worried about? Is this something people haven't queried before?

Perhaps my googlefu is weak but I never found anything similar. I ended up reading threads up to ten years old about chapters but they seemed to be things like people not having chapter marks with the cause being the book lacking a table of contents.

The particular file structure of the epub (single html with all TOC entries pointing to tags in that file; one html file per Part, Chapter and Section) is irrelevant. The only difference is, in the absence of styling rules to the contary, the automatic presence of a page break for a new html file.

The rule KOReader appears to be following is:

• draw a tree diagram based on the table of contents/navMap
• only draw chapter marks in the status bar for leaf nodes

This has the related effect that the counters for pages left in chapter and time to read chapter become useless. While reading the front matter they will be measuring to Section A, ignoring any and all other pages found at the start of Part One and Chapter 1. With fiction books being told it is dozens of pages to the next chapter when really it is counting to the first section break in the next chapter and the next chapter is 1 page away might help my bedtime as I'll put the book down. Not a big problem but a surprise in such a well crafted program.

This problem occurs with epubs with tables of content generated by the TOC tools in Sigil and Calibre as well as in books supplied with TOC by the publisher so it's not some problem I have invented by messing with TOC myself hence I wonder if I have missed a setting as asked above.

[NiLuJe]

An actual example to test would be helpful?

If you're *only* talking about tick marks, and not the actual ToC display, then, yeah, there are some weird and old opinionated decisions done about which depth levels get honored.

I don't recall the details OTOH, but I know @poire-z has mentioned it before on GH.

[NiLuJe]

@poire-z dug up the actual thing I was vaguely remembering: https://github.com/koreader/koreader...ment-698508393

[hyurte]

Thank you for the link. I shall attempt to call the marks ticks in future.

Attached is a tidier version of the example file I played around with. There are 11 entries in the TOC across heading levels 1 - 4.

Almost every section in the file has 60 single line paragraphs so you'd hope for ticks evenly spaced along the progress bar. However, as you can see in the attached image there are only 5 irregularly spaced ticks. (Since taking the photo I changed the stylesheet to put page breaks ahead of most headings but that doesn't change much.)

Towards the start of the epub there are two short use cases described where not having a tick becomes a hindrance. (Text books with chapters and sections; fiction anthologies with stories divided into chapters.)

However, I also discovered a few minutes ago that the absence of the tick is related to navigation to next/prev chapters. Multi swipe gestures in this epub only travel to the navPoints which have ticks associated with them.

[NiLuJe]

Many thanks for the testcase!

I'll try to look into it this WE. (The current idea being to simply flatten the tick list and keep all of 'em for stuff like that, which indeed includes some other things, as you've noticed with chapter navigation gestures).

[NiLuJe]

@hyurte: If you have a chance to test it, https://github.com/koreader/koreader/pull/6716 should help .

[hyurte]

We have many words where I come from for someone who wouldn't take the time to look at a solution to a question they asked.

I can now happily report I have documents with progress bars full of stupidly many ticks. Some are so dense that the next chapter is the on the same page. What madman publishes books like this?

I am astounded at how quickly you implemented a solution. I thought it was a small thing and hadn't expected anyone to address it so soon. Thank you for volunteering your time and skill.

[NiLuJe]

@hyurte: Eh, the subject had come up a few times over the years, and @poire-z's comments and your report just gave me the necessary push to do something about it ;p.

Thanks for the feedback .

EDIT: You'll probably notice in the screenshot I attached to the PR that my own progress bars have all been switched to "thin" ticks (that's in the status bar settings). Might be something you'll want to do, too, given the density of ticks in your usual content .