Meeting minutes
Horizontal Reviews
wendyreid: We did some preliminary stuff, and have started the i18n review, that is underway
… leave a11y, security and privacy, and TAG review
… AvneeshSingh has volunteered for a11y
… toshiakikoike has volunteered for TAG
… that leaves security and privacy
… each review comes with a questionnaire we just need to update it for the current core specs
… it does not include annotations
ivan: Maybe. in i18n they have said they want a new one
… so for that I copied it and reviewed, then added some intro text about new things/changes
… it is a question of whether the target groups will accept this approach
wendyreid: In that case, they have changed the process. They didn't have the self questionnaire
ivan: They did
wendyreid: Yes, but it just needs to be updated
ivan: They are also looking for an overview/explainer to describe the spec
… we have an overview with 3.3, which I have updated (PR coming)
… That is a good reference if they ask for it
AvneeshSingh: Timeline? When is CR?
ivan: This is a vicious circle. We can go to CR when reviews are done
… Unless things change with today's discussion
<sueneu> +1 Avneesh
AvneeshSingh: Can we pick a date?
ivan: I would say June 1
duga: I volunteer to have one assigned to me
gautierchomel: I will do one
wendyreid: Security or privacy?
gautierchomel: I will take privacy
wendyreid: Ok, great, that is all we needed
ivan: Please reach out to me and wendyreid for details
Supporting multi-granularity highlighting - w3c/epub-specs#2917
wendyreid: There has been of a lot of discussion on the issue
… does anyone have a summary?
Hadrien: I can, first some news
… audible allowing basically media overlays
… we are very focused on trade
… but specialty libraries are largely adopting epub
… even in the more classic retail apps we are seeing this more
… we haven't really looked at this the right way until now
… we need to allow users to puck granularity
… it would be great for users to control this
… so e.g. sentence plus word
… or maybe just sentence because word is distracting
… it is possible now with TTS but not media overlays
… we don't need much for that feature
… we have all the tools we need from a techincal level (epub:type, etc)
… what we don't have is the epub:types
… we don't need word, most of the discussion has been over bikeshedding names
… What I care about is number of options.
… We want to limit the number for reading systems, and P, sentence and word are most used in TTS
… At the end of the day the user can't determine what is in the SMIL, so if these are not used perfectly it doesn't matter to the user
… they will just get whatever 3 things the author chose to mark uo
… so we can either bike shed forever, or pick three suboptimal terms
GeorgeK: We need a requirement to turn off the highlighting, as it can trigger epilepsy
… that has been implemented in several RSes, but we need to note that
<Hadrien> +1 to what GeorgeK said, the ability to turn off or customize highlighting is key
wendyreid: we should also discuss, we are pushing away from epub:type, and this leans into it
Hadrien: Do we have anything else for SMIL?
ivan: Now that we are xhtml only it isn't much of a problem
… epub:type is here to stay
AvneeshSingh: FYI GeorgeK and I have proposed a topic in the June DAISY roundtable
… what we are hearing from specialist libraries is diverse
… some are saying media overlays are too expensive
… others think having so many levels is hard
… many are just going to AI to generate the overlay content
… so we thought it would be a good to discuss at the roundtable
CharlesL: On the bike shedding topic, we can just small/med/large it
Hadrien: Yeah, we can call it something general. We just need to call it something. It has to make sense for the UI
… I don't really care, I just want it to be usable
… for production, we are seeing tools that do this automatically
… there are whole communities around it, so cost isn't really a problem
… I don't think the TTS issue is valid
… even the best models need to be online and paid
… There are some that can be used on device, but they are limited
… so if you don't pre-generate you will be stuck with what is on device
… I don't think this is one or the other
… Audible is doing the alignment early
wendyreid: Both things are true about TTS
… some people are currently using computer generated audio in audiobooks
… mostly for front matter
… for audible, it is some sort if internal alignment, not media overlays
… you need to do a lot of smart things to align the text and audio
… on to CharlesL, I like small/.medium/large
… I wonder if the RS should be allowed to combine and group?
… e.g. line-by-line that can't be embedded in the epub as it depends on viewport etc
… so I am not sure about embedding, but could go either way
GeorgeK: Do we have an example we can show at the Oslo event [DAISY roundtable]
Hadrien: Yes, we will have something that works in thorium mobile for Oslo
… the problem is no files
… in the issue we have tools authors saying they will do it, regardless of what we decide
… they would prefer to have us define it, but they will do their own thing if they need to
… but we can certainly demo this
… I know at least one retailer that really wants to do this with media overlays
… so an audiobook and ebook could be bundled and synced
… I can't name or give timelines, but there is interest
… (this is a platform)
… we have people chiming in to say "no, we can't do it on device"
… so for now it needs to be authored
… not a very big additoon to the spec
duga: this is a lot of markup authors will have to do
… its a lot of tagging
… aren't there accessibility issues on readaloud when
… there is a lot of arbitrary markup around words and sentences?
… are there other issues that might come up with searching, for instance
<Zakim> wendyreid, you wanted to react to duga
duga: when you start tagging every word in a book, problems may arise
wendyreid: yes, there are potential problems
… a lot of those engines are doing better, sometimes screen readers have issues with a lot of spans
… like too much pausing, but that is also smoothing out since there is a lot of that on the web
… so this comes down to robust testing
… If it is too bad you might want to have multiple versions
… it is a valid concern but it is going away
shiestyle: If we add this to epub, publishers or authors can specify this level of granularity
… but I don't understand why they would
… if RSes can allow you to select, that is fine, but I don't see why pubs need this
Hadrien: You are assuming this happens at prod time but it often happens later
… eg at a specialist library
… you are both assuming this happens at prod time, which is wrong
… to duga, this is already being done
<Hadrien> w3c/
Hadrien: I agree that divs and spans is not ideal
… I have suggested something for discussion at another time that would avoid the tag soup
… to shiestyle, this can't be done only by the RS, this has to be done beforehand
… probably by specialist libraries
CharlesL: This reminds me of another reader that uses difference colors for highlighting, which changes as you read along
… initially they did it with char by char, and it made screen readers stutter
… so they did something to fix it
<Zakim> wendyreid, you wanted to ask about whether we need flags to RS to determine what levels are available
wendyreid: Traditionally media overlay is just play/pause
… this has a lot of other options
… how do we signal the different levels of granularity being there? I assume we don't want to force parsing of SMIL to figure out what is available
Hadrien: We don't want 2 affordance for TTS and media overlay
… so just "give me audio". For this we will do our best to give what the user wants for both kinds
… if the info is missing there isn't much we can do, but I think that is ok
… It is better to treat this as a pref for audio, instead of explaining what media overlay is
wendyreid: That makes sense
… especially if you bought the book
duga: I am have already ignored the marker you put in for granular media overlays because I know you did it wrogn
… I do not believe publishers are going to change this for every book
… the only way to be sure about this is to parse the SMIL
wendyreid: vibe check
… I like s/m/l, or some other similar name. But yes to 3 tiers
Hadrien: We just need 2 new ones
… the third isn't needed for processing
ivan: Don't you need zero?
Hadrien: <par> with nothing is zero
<sueneu> +1 to s/m/l or just s/l
wendyreid: with MO people mark up every word? Is that required or just what people do?
… can someone now pick a different base unit? e.g. sentence
Hadrien: We don't know right now
… books targeting kids use word, adults use sentence
… if you use more types with a container you are giving an intent
DaleRogers: From a text based Eng point of view, how does this relate to other langs, e.g. Japanese?
Hadrien: That is where word gets fuzzy, but we don't care since it isn't named
… sentence is a little fuzzy but not too bad
ivan: This is why the proposal to ignore linguistic notions has been made
<wendyreid> unit/segment/section?
CharlesL: I am struggling to understand why we don't need 3? Don't we need them all? Is small default?
Hadrien: It is not word, it is just the smallest, and you know that because it is contained by the other types
CharlesL: Does that help with tag soup?
Hadrien: No, you still need it, just no epub:type for small
… I don't care about the name
wendyreid: We are at time, maybe discuss in the issue
… and we can finalize next time
ivan: Maybe vote now on direction
wendyreid: sorry, at time!