Juan Carlos Corona Romero
Juan Carlos Corona Romero
Alright, my thinking is now I'm moving towards your suggestion @llemeurfr
Still would like to draft up a design for a convenient API though, and IMO It's easier with normalization of the data.
@HadrienGardeur I have actually. I'll go back and iterate my thoughts on that approach too.
Man! I was looking for something like `und` Thanks for the analysis, everyone! 👍
Another idea is that it takes the href without fragments.. somehow.. it's ambiguous... The resulting collection would look like this: ```json "toc": [ { "href": "appendix.xhtml", "title": "Appendix", "children": [...
Also as of the moment, I am unable to see the relationship to this and `loi`, `lot`, etc. I don't have concrete examples that use these listings in the EPUBs...
> Personally I prefer solution 1, and it's already exposed like that on mobile since it's part of the EPUB extension of RWPM. However, `epub:type` is ignored in the parsing....
I [found the overlap](https://observablehq.com/@jccr/iana-rels-and-epub-types) between EPUB and IANA link relations: - appendix - chapter - glossary - help - index
Seeing as this list is small.. is it practical to have a map at all? I say let's require a URL for all values, including `http://www.idpf.org/2007/ops#cover`, `http://www.idpf.org/2007/ops#appendix `, `http://www.idpf.org/2007/ops#chapter`, `http://www.idpf.org/2007/ops#glossary`,...
This sounds pretty bad.. I have a Nexus 7 Gen 2. @jdempcy Do you think I could reproduce this by pointing it to a cloud reader instance on the Chrome...