23:51:25 <RRSAgent> RRSAgent has joined #epub
23:51:25 <RRSAgent> logging to https://www.w3.org/2021/06/24-epub-irc
23:51:27 <Zakim> RRSAgent, make logs Public
23:51:28 <Zakim> please title this meeting ("meeting: ..."), wendyreid
23:51:44 <wendyreid> meeting: EPUB WG Telco June 24, 2021
23:51:51 <wendyreid> date: 06-24-2021
23:51:54 <wendyreid> chair: wendyreid
23:51:57 <wendyreid> present+
23:58:58 <MattChan> MattChan has joined #epub
23:59:03 <mgarrish> mgarrish has joined #epub
23:59:47 <MasakazuKitahara> MasakazuKitahara has joined #epub
23:59:55 <MasakazuKitahara> present+
00:00:22 <toshiakikoike> toshiakikoike has joined #epub
00:00:33 <toshiakikoike> present+
00:00:35 <MattChan> present+
00:00:58 <shiestyle> shiestyle has joined #epub
00:01:22 <duga> duga has joined #epub
00:02:32 <duga> present+
00:04:25 <MattChan> scribe+
00:04:46 <MattChan> TOPIC: Refine the requirements on how RS must process the container structure
00:04:48 <BenSchroeter> BenSchroeter has joined #epub
00:04:48 <wendyreid> https://github.com/w3c/epub-specs/issues/1687
00:04:57 <BenSchroeter> present+
00:05:09 <MattChan> wendyreid: per discussion last week, mgarrish made us a test epub for this
00:05:30 <shiestyle> shiestyle has joined #epub
00:05:38 <MattChan> ... we've put it through various RS, Apple, Thorium, Colibrio, Kobo Desktop, Kobo iOS, ADE, more...
00:05:55 <MattChan> ... aside from Apple and ADE, the test epub has worked
00:06:28 <duga> q+
00:06:28 <MattChan> ... it seems like most RS are flexible in their sourcing, but with our two fail cases, there is some variability in implementation
00:06:37 <wendyreid> ack duga
00:06:53 <MattChan> duga: and most of this was done via sideloading, and publisher pipelines are often different
00:07:06 <MattChan> ... if publisher sent apple a book, we might have gotten a different result
00:07:08 <mgarrish> q+
00:07:11 <wendyreid> ack mgarrish
00:08:07 <MattChan> mgarrish: 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.
00:08:36 <MattChan> ... 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?
00:09:10 <MattChan> wendyreid: it probably doesn't hurt to refine language, but at this point creating a firm requirement would impact some existing RS implementations
00:09:25 <MattChan> ... and it might make authors uncomfortable
00:09:30 <duga> q+
00:09:41 <MattChan> ... do we note that there is some confusion as to implementation, but clarify that we aren't going to enforce anything?
00:10:00 <shiestyle> shiestyle has joined #epub
00:10:08 <MattChan> mgarrish: easiest solution is probably an authoring requirement. Esp. because most authors have probably never tried to do anything like the test epub
00:10:27 <wendyreid> ack duga
00:10:27 <MattChan> ... so say authors should put their content under the package document
00:11:00 <MattChan> 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?
00:11:23 <MattChan> ... if some publisher creates an epub that just doesn't work on Apple, maybe that can just be between that specific publisher and Apple...
00:11:44 <shiestyle> present+
00:11:58 <MattChan> mgarrish: this whole thing really only came up because of that root-relative thing, so on that note maybe we just say not to use those
00:12:37 <MattChan> s/on that note/on that issue
00:13:37 <MattChan> wendyreid: right, so we advise not to use root-relative, and we can't say specifically how RS will behave if you do it
00:14:03 <MattChan> mgarrish: can we resolve just to use something similar to the note we were going to have for multiple renditions?
00:14:51 <wendyreid> Proposed: Provide a note in the core spec that this is a known issue, include non-normative advice about what to do, close issue 1687
00:14:54 <duga> +1
00:14:55 <wendyreid> +1
00:14:57 <MattChan> +1
00:14:57 <mgarrish> +1
00:14:58 <MasakazuKitahara> +1
00:15:00 <BenSchroeter> +1
00:15:02 <toshiakikoike> +1
00:15:03 <shiestyle> +1
00:15:09 <wendyreid> RESOLVED: Provide a note in the core spec that this is a known issue, include non-normative advice about what to do, close issue 1687
00:16:11 <MattChan> wendyreid: the other two related issues first are root relative paths valid? is this now moot?
00:16:31 <wendyreid> https://github.com/w3c/epub-specs/issues/1681
00:17:01 <MattChan> mgarrish: 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
00:17:37 <MattChan> ... it may work on some RS, but that's fine
00:19:27 <wendyreid> Proposed: Declare root relative paths not recommend (should not be used), close 1681
00:19:31 <wendyreid> +1
00:19:32 <MattChan> +1
00:19:34 <mgarrish> +1
00:19:35 <toshiakikoike> +1
00:19:36 <MasakazuKitahara> +1
00:19:38 <BenSchroeter> +1
00:19:42 <duga> +1
00:19:44 <wendyreid> RESOLVED: Declare root relative paths not recommend (should not be used), close 1681
00:20:04 <wendyreid> https://github.com/w3c/epub-specs/issues/1686
00:20:23 <MattChan> wendyreid: the second one: what should RS do with manifest item has duplicate entries?
00:21:13 <MattChan> s/with manifest item/when manifest
00:21:56 <MattChan> wendyreid: this is worth testing (and should be easy enough to test)
00:23:09 <MattChan> mgarrish: 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
00:23:26 <wendyreid> https://github.com/w3c/epub-specs/issues/1715
00:23:32 <wendyreid> https://github.com/w3c/epub-specs/issues/1717
00:23:41 <MattChan> TOPIC: TTS
00:24:15 <MattChan> wendyreid: 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.
00:24:35 <MattChan> ... the issues were just doing this
00:25:01 <MattChan> mgarrish: yes, we pulled them out, and added a little intro type prose
00:25:22 <MattChan> ... we talked about what to name these documents in one of the issues
00:25:47 <MattChan> ... but like we said last time, these parts just felt a little underspecified (and still do)
00:26:21 <MattChan> wendyreid: I started doing a little bit of research into what RS might have implemented TTS, this is ongoing
00:27:15 <MattChan> mgarrish: DAISY has some readers that can do TTS, but even when it comes to PLS they don't implement it exactly as per spec
00:27:49 <MattChan> ... about naming, we were going for something that tied it to our respec, but also gave it a 1.0 version number
00:27:59 <MattChan> s/respec/spec
00:28:26 <MattChan> BenSchroeter: VitalSource has TTS, but not sure if they use SSML and PLS
00:28:45 <MattChan> duga: same with us, but we just use OS level TTS functionality
00:29:47 <MattChan> wendyreid: i was looking through the issue list and we've only got a few issues still open
00:29:51 <MattChan> ... and most are still recent
00:30:04 <wendyreid> https://github.com/w3c/epub-specs/issues/671
00:30:20 <MattChan> wendyreid: this one we might be able to close after some brief discussion?
00:31:00 <MattChan> ... someone asked if spec could address common "reader styling scenarios"
00:31:51 <MattChan> ... so, if you have a library of ebooks, how to ensure consistency across that library
00:32:09 <MattChan> ... it's an interesting problem, but probably out of scope for the epub spec
00:32:46 <MattChan> TOPIC: TF updates
00:33:20 <MattChan> wendyreid: 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.
00:33:41 <MattChan> ... e.g. being able to cite from a specific spot in a given epub
00:34:02 <MattChan> ... this is as opposed to creating annotations on a specific word in an epub
00:34:27 <MattChan> ... TF is working on document to discuss the problem, and proposed solution
00:34:56 <MattChan> ... specifically, creating "blocks" of a standard size, and a tool that authors can use to chunk up a book
00:35:17 <MattChan> ... please comment on our write-up once it is ready
00:35:54 <MattChan> ... the big question is about how this proposal plays with non-latin languages, or languages with very complex writing modes
00:36:04 <MattChan> ... i.e. internationalization issue
00:36:56 <MattChan> ... 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
00:37:20 <MattChan> ... we're also just working on examples of our best practice recommendations, and then compilations of those examples that we can share
00:37:51 <MattChan> ... we're also coming up with ideas for how to do certain content types (esp. comics, manga) in a more accessible way
00:38:06 <mgarrish> q+
00:38:52 <MattChan> BenSchroeter: i shared a session of AHG where a method was discussed for describing very graphically intense works
00:39:18 <wendyreid> ack mgarrish
00:39:27 <MattChan> ... it seemed to me that this was probably a better way of creating an accessible reading experience, vs metadata based techniques
00:40:23 <MattChan> mgarrish: 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.
00:41:20 <MattChan> wendyreid: yes, we've tried to be mindful of scope in our document
00:41:33 <MattChan> TOPIC: AOB?
05:44:25 <Zakim> Zakim has left #epub
05:50:47 <Karen> Karen has joined #epub