Order of entries in table of contents must match spine ordering #888
Assignees
Labels
spec: EPUB 3.2
Impacting the support of EPUB 3.2
status: has PR
The issue is being processed in a pull request
Milestone
Comments
mattgarrish
added
spec: EPUB 3.2
rdeltour
added a commit
that referenced
this issue
Mar 12, 2019
New Message:
- `NAV_011` (`ERROR`) is reported when the links in `toc` and `page-list`
`nav` (in the Navigation Document) do not follow the reading order
(i.e. spine order + order of IDs in the Content Documents).
Checking logic for `NAV_011`:
1. collect the nav links as references in `XRefChecker`
2. check the reading order consistency in `XRefChecker.checkReferences`
(ran after all documents have been parsed and validated)
Internal changes:
- In the `PathUtil` utilities:
- rename the `removeAnchor` method to `removeFragment`
- add a new `getFragment` method
- In the `OPFItem` class:
- for spine items, record their position in the spine
- add a new public `getSpinePosition()` getter
- In the `XRefChecker` class:
- add a new `getResource(path)` public method to get an `OPFItem`
for a given path.
- add a new `getAnchorPosition(id)` method to the internal `Resource`
class.
- some registered references are duplicates of already-registered
references, with a specific reference type (e.g. a Nav Doc link is
registered both as a HYPERLINK and as a NAV_TOC_LINK): these
subtypes are now checked in separate private methods, to keep the
main `checkReference(Reference)` method pristine.
- add a new `checkReadingOrder(Queue, int, int)` private method which
processes a queue of references (along with the last known spine
position and fragment position) and check they are in reading order
- add new tests for the Navigation Document reading order check
- fix existing tests
Fix #888
rdeltour
added
status: has PR
rdeltour
added a commit
that referenced
this issue
Mar 12, 2019
New Message:
- `NAV_011` (`ERROR`) is reported when the links in `toc` and `page-list`
`nav` (in the Navigation Document) do not follow the reading order
(i.e. spine order + order of IDs in the Content Documents).
Checking logic for `NAV_011`:
1. collect the nav links as references in `XRefChecker`
2. check the reading order consistency in `XRefChecker.checkReferences`
(ran after all documents have been parsed and validated)
Internal changes:
- In the `PathUtil` utilities:
- rename the `removeAnchor` method to `removeFragment`
- add a new `getFragment` method
- In the `OPFItem` class:
- for spine items, record their position in the spine
- add a new public `getSpinePosition()` getter
- In the `XRefChecker` class:
- add a new `getResource(path)` public method to get an `OPFItem`
for a given path.
- add a new `getAnchorPosition(id)` method to the internal `Resource`
class.
- some registered references are duplicates of already-registered
references, with a specific reference type (e.g. a Nav Doc link is
registered both as a HYPERLINK and as a NAV_TOC_LINK): these
subtypes are now checked in separate private methods, to keep the
main `checkReference(Reference)` method pristine.
- add a new `checkReadingOrder(Queue, int, int)` private method which
processes a queue of references (along with the last known spine
position and fragment position) and check they are in reading order
- add new tests for the Navigation Document reading order check
- fix existing tests
Fix #888
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This may already be checked, but there was a simplification of the toc nav prose in 3.2 to make clear that the entries in the table of contents must be ordered to match the order in which content documents occur in the spine and any entries with fragment identifiers must be ordered to match the document order of the IDs within the content document.
Reference: https://w3c.github.io/publ-epub-revision/epub32/spec/epub-packages.html#sec-nav-toc
The text was updated successfully, but these errors were encountered: