Well, once again on the Readium side we've already implemented a manifest as a "better OPF" and this has been a very successful strategy so far. The community likes it so much that people who were originally opposed to this approach are now backporting manifest support to Readium-1, while other apps (EPUB.js for instance) are adopting the manifest as a key component of their design. Having everything in the manifest has helped us with several optimizations as well, such as preloading assets in cache or pre-rendering adjacent resources. This results in a better user experience overall. We couldn't do that nearly as fast if we had to figure out adjacent resources by parsing the current resource first (to search for prev/next links). We haven't worked much on FXL yet, but for spreads having everything in a single manifest will be an absolutely must have, I don't see how it could work well otherwise (or how you could provide FXL and spread specific properties in HTML). I'm more open to the idea of the table of contents not being in the manifest (it's less important to have it immediately and easily), but having the reading order in there is IMO a must have. Hadrien
Received on Saturday, 10 February 2018 12:20:41 UTC