Closed domkm closed 1 month ago
Also, what should hrefs look like for direct audio files (not zip/exploded archive)? For example, if I create a an audiobook from a local URL file:///path/to/publication/book-title.mp3
, I assumed the href
s would be "book-title.mp3"
but instead I'm seeing "publication.mp3"
.
Thanks for spotting that @domkm, it was an oversight.
For example, if I create a an audiobook from a local URL file:///path/to/publication/book-title.mp3, I assumed the hrefs would be "book-title.mp3" but instead I'm seeing "publication.mp3".
Locators should not break if you rename the file or use it on another device. This is why they need to be stable.
In the case of ZIP archives it's easy, because the entry paths are always relative to the archive root. For standalone files we can't use the file name as the user might change it. I went with publication.<format extension>
as this is what is used when packaging a file with the Readium LCP server (a PDF file is embedded in a ZIP archive at publication.pdf
).
It is not super critical though, with standalone files there's no need to disambiguate between entries in a locator, so the href
is not really needed.
Describe the bug
The documentation says Locator href format for files is changing: "
/dir/my chapter.html
becomes the relative URL pathdir/my%20chapter.html
". However, when I load an audiobook from a local directory URL where the files within the directory are MP3s using 3.0.0 alpha, I see locators that appear to be a combination of the old format and new format. Specifically, they are now percent encoded but the leading slash is still present.How to reproduce?
Readium version
develop (3.0.0)
OS version
iOS 17.5
Testing device
Mac (built for iPad)
Environment
Additional context
No response