- From: Lars Wallin <lars@colibrio.com>
- Date: Mon, 18 Apr 2022 19:25:34 +0200
- To: Leonard Rosenthol <lrosenth@adobe.com>
- Cc: "Reid, Wendy" <wendy.reid@rakuten.com>, public-epub-wg@w3.org, W3C Publishing Community Group <public-publishingcg@w3.org>
- Message-ID: <CAN9weQweMSCUMJN1vDmDkChn8s-LBNKaceu83ST+Z+hvS13vYQ@mail.gmail.com>
Indeed, it can get trickier with some types of content. To get round this we use a fixed value for non-textual elements such as replaced HTML elements etc. I was just thinking, EPUB publications could expose some sort "processing instruction" based on a new set of content categorizations? Example: A "EPUB Comic" could presents three resolutions for locator creation; Table of Contents, Page list, Panel (using a publication defined CSS selector perhaps?) and words. This would also make it possible for the publication to expose metadata about the "duration" of the content using the above mentioned units of measure. 50 pages, 250 panels, 7000 words etc. Just thinking out loud here š On Mon, 18 Apr 2022, 19:08 Leonard Rosenthol, <lrosenth@adobe.com> wrote: > Lars ā I can see what working in a text-only work (e.g., simple books), > but in a more significant work with images, equations, etc., you would have > to (I would expect) download all that material and have it go through the > layout engine to understand where it falls on a āvirtual pageā. No? > > > > Leonard > > > > *From: *Lars Wallin <lars@colibrio.com> > *Date: *Monday, April 18, 2022 at 12:59 PM > *To: *Leonard Rosenthol <lrosenth@adobe.com> > *Cc: *Reid, Wendy <wendy.reid@rakuten.com>, public-epub-wg@w3.org < > public-epub-wg@w3.org>, W3C Publishing Community Group < > public-publishingcg@w3.org> > *Subject: *Re: [A11Y] Question from the Locators TF > > Hi Leonard and all, > > > > Because of the nature of the OCF (and of the zip format) it is possible to > stream down only the various document metadata and XHTML markup to use as > basis for the creation of locators. We offer this at present as one method > for creating locators with various resolution (characters, words, sentances > and pages etc). > > > > These are then exposed as EPUBCFIs, and as they are deterministic they are > cacheable and shareable across users and systems. > > > > This has worked well in all instances so far, regardless of device class > and network since gzipped markup, with few exceptions, is very slim. > > > > Cheers, > > Lars > > > > On Mon, 18 Apr 2022, 15:13 Leonard Rosenthol, <lrosenth@adobe.com> wrote: > > One other consideration is that if the locators list is generated by the > client, that means that the EPUB would need to transmitted **in its > entirely** to the client before the locators could be produced. That > would seem to be a significant design limitation when considering random > access to large content potentially on slower connections. > > > > Leonard > > > > *From: *Reid, Wendy <wendy.reid@rakuten.com> > *Date: *Thursday, April 14, 2022 at 5:18 PM > *To: *public-epub-wg@w3.org <public-epub-wg@w3.org>, W3C Publishing > Community Group <public-publishingcg@w3.org> > *Subject: *[A11Y] Question from the Locators TF > > Hi all, > > > > The Locators TF is working on an interoperable method for generating page > locators across reading systems and books. Just to give an idea of what > weāre considering, we have developed a skeleton for an algorithm that could > parse an EPUB file and generate ālocatorsā at defined intervals. > > > > One of the questions we are tackling now is where the locators live after > generation. In practice, reading systems do not typically write to the EPUB > file, meaning that if the locators are generated upon loading, they would > potentially live in a āvirtualā space accessible to the reading system. > This virtual locator list would be usable by the reading system for things > like search or navigate to page but would not appear in text or in the DOM. > > > > This is the question we need help with. Our understanding is that locators > need to be accessible to assistive technology, though the user may turn > them on or off, which means we need to explore how locators need to be > changed to accommodate this. Any advice you can provide on: > > - the use cases of page numbers with AT, > - what use cases need to be supported, > - are there other ways page numbers/locators need to be exposed to the > user or AT > > > > Please let us know if there are any questions, or if this is best > discussed on an upcoming call, our next one is April 29th at 10AM ET. > > > > Thanks, > > Wendy > > Co-chair, EPUB3 WG > >
Received on Monday, 18 April 2022 21:32:46 UTC