FYI: tracking of "web readers", support for zipped and exploded EPUBs, RWPM etc.

[danielweck]

Hello, I updated the "registry" documented here:

edrlab/publications#2

Direct link to "Readium Playground":

edrlab/publications#2 (comment)

(scroll all the way down to see the successful Go streamer RWPM, and the failing TS/JS streamer RWPM)

[danielweck]

I believe the Readium Playground web reader currently fails to support RWPM from the original TS/JS streamer because of "positions list"? (not sure)

https://playground.readium.org/read?book=https://streamer.edrlab.org/pub/aHR0cHM6Ly9yYXcuZ2l0aGFjay5jb20vZWRybGFiL3B1YmxpY2F0aW9ucy9tYWluL3Rob3JpdW0zLWRvY3VtZW50YXRpb24vc291cmNlcy9lbi5lcHVi/manifest.json

( https://raw.githack.com/edrlab/publications/main/thorium3-documentation/sources/en.epub )

Working examples:

https://vivliostyle.github.io/vivliostyle.js/viewer/vivliostyle-viewer.html#b=https://streamer.edrlab.org/pub/aHR0cHM6Ly9yYXcuZ2l0aGFjay5jb20vZWRybGFiL3B1YmxpY2F0aW9ucy9tYWluL3Rob3JpdW0zLWRvY3VtZW50YXRpb24vc291cmNlcy9lbi5lcHVi/manifest.json

https://nypl-web-reader.vercel.app/html/url/https:%2F%2Fstreamer.edrlab.org%2Fpub%2FaHR0cHM6Ly9yYXcuZ2l0aGFjay5jb20vZWRybGFiL3B1YmxpY2F0aW9ucy9tYWluL3Rob3JpdW0zLWRvY3VtZW50YXRpb24vc291cmNlcy9lbi5lcHVi%2Fmanifest.json

[JayPanoz]

@danielweck Thanks! Will take a look later this week since there’s something else I have to check for the positions list. 🙏

[danielweck]

If indeed the absence of "positions list" in the RWPM JSON generated by the old JS/TS streamer is what is causing the web reader to crash, then is this intentional design, or just an oversight? I am trying to understand if the Readium specification requires this feature:

https://readium.org/architecture/models/locators/positions/

[JayPanoz]

is this intentional design, or just an oversight?

That would be an oversight as it was initially working w/o it. I’m consequently labelling this issue as a bug and will fix this issue ASAP.

[chocolatkey]

For the purposes of the ts-toolkit, I have been assuming that it always exists because I've always been working with the go-toolkit's output. Because the position list for reflowable is calculated based on the file size of the resources, which is not present in the manifest, it is "required" in order for the navigator implementation in the ts-toolkit to work properly at the moment. We could alter that if necessary

[JayPanoz]

So yeah the unhandled Promise rejection seems to be here in ts-toolkit.

Would you like to migrate the issue to ts-toolkit? Or should we wait Wednesday’s call to discuss this?