Generating guided navigation documents can be long

[qnga]

Based on Mickaël's experience with content iterators, parsing HTML documents can be a bit long. Parsing the whole publication before starting to read it aloud seems prohibitive with huge books such as the Code du travail.

I can think of two approaches, none of which being either trivial or ideal:

• Caching the documents and maybe even generating them ahead of time. Is that an issue with LCP publications ?
• Starting to read content before the whole publication is ready, typically after the first resource has been parsed. In my first experiments of a read aloud navigator based on guided navigation documents, I expose to the caller a tree representing the whole publication and offer the ability to navigate to any point of this tree. If the whole tree is not guaranteed to be available, getting the children of a node has to become an asynchronous operation which makes it a bit tricky to use in my view. An alternative would be to limit this navigation in the tree feature to the current resource only.

[danielweck]

FWIW, Thorium (Desktop) builds the utterance structure lazily / just-in-time when a HTML resource is rendered (DOM available in the webview) and when the user requests TTS play or when the speech moves forward automatically onto the next document in the reading order. There is no eager / ahead-of-time parsing, and there is no caching. In fact, whenever the user modifies the skippability or sentence detection (fragmentation) preference, the utterance structure is rebuilt from scratch before TTS resumes. This definitely introduces a delay on slow hardware, but it's an acceptable tradeoff given the benefits in other stages of the user experience.