EPUB 3 Working Group Telco — Minutes

Date: 2021-06-24

See also the Agenda and the IRC Log

Attendees

Present: Wendy Reid, Matt Garrish, Masakazu Kitahara, Toshiaki Koike, Matthew Chan, Brady Duga, Ben Schroeter, Shinya Takami (高見真也)

Regrets: Dave Cramer, Ivan Herman

Guests:

Chair: Wendy Reid

Scribe(s): Matthew Chan

Content:

1. Refine the requirements on how RS must process the container structure

See github issue #1687, #1681, #1686.

Wendy Reid: per discussion last week, mgarrish made us a test epub for this
… we’ve put it through various RS, Apple, Thorium, Colibrio, Kobo Desktop, Kobo iOS, ADE, more…
… aside from Apple and ADE, the test epub has worked
… it seems like most RS are flexible in their sourcing, but with our two fail cases, there is some variability in implementation

Brady Duga: and most of this was done via sideloading, and publisher pipelines are often different
… if publisher sent apple a book, we might have gotten a different result

Matt Garrish: we still have the problem that the spec doesn’t say anything about this. There is no authoring requirement for where to put your content (other that below the root). And for RS there is no requirement for how to unpack, etc.
… it seems like it should be common sense. But beyond what we’ve already said, not sure what we should do. Maybe note it as a potential issue?

Wendy Reid: it probably doesn’t hurt to refine language, but at this point creating a firm requirement would impact some existing RS implementations
… and it might make authors uncomfortable
… do we note that there is some confusion as to implementation, but clarify that we aren’t going to enforce anything?

Matt Garrish: easiest solution is probably an authoring requirement. Esp. because most authors have probably never tried to do anything like the test epub
… so say authors should put their content under the package document

Brady Duga: this has been an issue forever, and the only time we noticed was with multiple renditions, which hasn’t been implemented really. So is a 3rd solution to just leave it?
… if some publisher creates an epub that just doesn’t work on Apple, maybe that can just be between that specific publisher and Apple…

Matt Garrish: this whole thing really only came up because of that root-relative thing, so on that issue maybe we just say not to use those

Wendy Reid: right, so we advise not to use root-relative, and we can’t say specifically how RS will behave if you do it

Matt Garrish: can we resolve just to use something similar to the note we were going to have for multiple renditions?

Proposed resolution: Provide a note in the core spec that this is a known issue, include non-normative advice about what to do, close issue 1687 (Wendy Reid)

Brady Duga: +1

Wendy Reid: +1

Matthew Chan: +1

Matt Garrish: +1

Masakazu Kitahara: +1

Ben Schroeter: +1

Toshiaki Koike: +1

Shinya Takami (高見真也): +1

Resolution #1: Provide a note in the core spec that this is a known issue, include non-normative advice about what to do, close issue 1687

Wendy Reid: the other two related issues first are root relative paths valid? is this now moot?

Matt Garrish: i think we are on safer ground to just disallow those, especially because in the past epubcheck has had those come up as an error
… it may work on some RS, but that’s fine

Proposed resolution: Declare root relative paths not recommend (should not be used), close 1681 (Wendy Reid)

Wendy Reid: +1

Matthew Chan: +1

Matt Garrish: +1

Toshiaki Koike: +1

Masakazu Kitahara: +1

Ben Schroeter: +1

Brady Duga: +1

Resolution #2: Declare root relative paths not recommend (should not be used), close 1681

Wendy Reid: the second one: what should RS do when manifest item has duplicate entries?
… this is worth testing (and should be easy enough to test)

Matt Garrish: i think the issue with this was that if there were multiple copies of the same item in manifest, then RS might not know which manifest item to go to when one copy is referenced

2. Text-To-Speech

See github issue #1715, #1717.

Wendy Reid: last week we discussed what to do with PLS and SSML in the spec. We aren’t getting rid of them, but are separating them into their own separate document.
… the issues were just doing this

Matt Garrish: yes, we pulled them out, and added a little intro type prose
… we talked about what to name these documents in one of the issues
… but like we said last time, these parts just felt a little underspecified (and still do)

Wendy Reid: I started doing a little bit of research into what RS might have implemented TTS, this is ongoing

Matt Garrish: DAISY has some readers that can do TTS, but even when it comes to PLS they don’t implement it exactly as per spec
… about naming, we were going for something that tied it to our spec, but also gave it a 1.0 version number

Ben Schroeter: VitalSource has TTS, but not sure if they use SSML and PLS

Brady Duga: same with us, but we just use OS level TTS functionality

3. The EPUB 3.1 spec should address common reader styling scenarios

See github issue #671.

Wendy Reid: i was looking through the issue list and we’ve only got a few issues still open
… and most are still recent
… this one we might be able to close after some brief discussion?
… someone asked if spec could address common “reader styling scenarios”
… so, if you have a library of ebooks, how to ensure consistency across that library
… it’s an interesting problem, but probably out of scope for the epub spec

4. TF updates

Wendy Reid: starting with locators. We’ve finalized the use-cases for epub. The basic problem we’re trying to solve is the matter of locating pages across epub RSes.
… e.g. being able to cite from a specific spot in a given epub
… this is as opposed to creating annotations on a specific word in an epub
… TF is working on document to discuss the problem, and proposed solution
… specifically, creating “blocks” of a standard size, and a tool that authors can use to chunk up a book
… please comment on our write-up once it is ready
… the big question is about how this proposal plays with non-latin languages, or languages with very complex writing modes
… i.e. internationalization issue
… a11y FXL TF is progressing on best practices document. We’re also working on a sample book demoing proposed solution for epubs that can switch modes - i.e. FXL book that could switch to be read as reflow book
… we’re also just working on examples of our best practice recommendations, and then compilations of those examples that we can share
… we’re also coming up with ideas for how to do certain content types (esp. comics, manga) in a more accessible way

Ben Schroeter: i shared a session of AHG where a method was discussed for describing very graphically intense works
… it seemed to me that this was probably a better way of creating an accessible reading experience, vs metadata based techniques

Matt Garrish: for naming, let’s try to put the word techniques into the title of the document. Not that we have to decide that today. Just flagging.

Wendy Reid: yes, we’ve tried to be mindful of scope in our document

5. Resolutions