Publishing Working Group Telco — Minutes

Date: 2019-03-25

See also the Agenda and the IRC Log


Present: Ivan Herman, George Kerscher, Tzviya Siegman, Wendy Reid, Dave Cramer, Nick Ruffilo, Laurent Le Meur, Avneesh Singh, Jun Gamou, Marisa DeMeglio, Teenya Franklin, Ric Wright, Franco Alvarado, Luc Audrain, Matt Garrish, Charles LaPierre, Mateus Teixeira, Benjamin Young, Bill Kasdorf, Brady Duga, David Stroup

Regrets: Garth Conboy, Joshua Pyle, Geoff Jukes, Romain Deltour


Chair: Tzviya Siegman

Scribe(s): Nick Ruffilo


Tzviya Siegman: Lets get going. First - minutes from last week. Wendy ran a very efficient meeting. Minutes approved.

Tzviya Siegman:

Resolution #1: minutes of last week approved

1. Implementations and UCR

Tzviya Siegman: We had a discussion about use cases - Franco and I had a prep session to talk about what we are looking for. Last time we went a bit off the rails. What we’re looking for here is not for implementors to tell us specifics, but we’re looking for a…

Tzviya Siegman:

Tzviya Siegman: discussion about the UCR. We need some discussion about what happens when a user encounters a scenario in a specific implementation. Franco will now go into a bit more detail.
… we have a few implementors, but anyone can speak. We’re talking about implementations and user scenarios.

1.1. UC #86

Ivan Herman: ->

Franco Alvarado: Lets start with #86 - I think as Tzviya said, Josh and I will be adding to the items in the UCR, but we want input from user agents. It can be email or opening issues in github.

Tzviya Siegman: “Mr. Oayia, a classroom teacher, says, “turn to page 137 of your textbook.” Regardless of layout and font size, students reading digital editions need to find the same location in the textbook as one another and as students reading the print edition.”

Franco Alvarado: This is about page numbers and how they are displayed/located.
… we need a rough description of how a user agent should handle this.

Laurent Le Meur: The readium implementation we’re doing is: If there is a page list inside the epub (or web publications). Page list is a list of references of inner locations in a book. If there is such a list, specifically entered by the publisher, we use it to create a goto feature.
… if there is none, we make some approximations. Each segment of 1024 character is considered a pseudopage. So if someone says “goto page X” we give them the responding segment. It’s a fallback of the explicit pagelist.

Ric Wright: 1024, known as the RIC_WRIGHT_ADOBE_CONSTANT

Laurent Le Meur: As far as presentation. With readium it’s moved to the json implementation.

Charles: I was wondering about that. What if there is no page list, but there are page markers inside the chapters. But they didn’t set up a page list. Does that ever occur?

Laurent Le Meur: The pages noted inside the document are not taken into account - at least not in the readium implementation.

Tzviya Siegman: the google play group and Jeff from Kobo are not here to offer comments/feedback today.

Ivan Herman: Question - Laurent, what we have today in the draft, as information, does it allow you to reproduce what we need?

Laurent Le Meur: With the HTML representation of the TOC - if there is a pagelist in HTML that can be added. But I fear there is none in the specification.

Laurent Le Meur: 3.6 in the draft covers pagelist in fact

Tzviya Siegman: note

Ivan Herman: We did have something about a pagelist. But we need to flag this.

Luc Audrain: To answer Charles - there is a need to have some markup in the content where the page breaks in the existing paper. If there is no page list, whatever the implementation and language is used, it means there is some burden and calculations that needs to be used by the reading system. It’s probably too expensive…
… there should be a list of pages somewhere in the publication. This pagelist, in the language used to express it, will be used by the user agent. So it places some burden on the authors doing the web publication, but in terms of accessibility, diversity, support, it works for ebooks and paper.

Avneesh Singh: Right now the w3c rec says to put the page-list in the publication. This is what is there. How the UI should do it - a goto page functionality works. Another way is to have a widget that has a list of page - so you have a TOC which is a hierarchy, but you could have a list of pages or targets and let the user go there…

Wendy Reid: +1 Avneesh

Avneesh Singh: if there is no page list, and there are only page breaks - what should we do? My experience and why epub has multiple content documents is to reduce the load on a reading system to read one-page-at-a-time. If there are only page breaks, the whole reading system would need to parse the whole document - so having a page-list is the most practical.

Ivan Herman:

Ivan Herman: There is a page-list as an answer to Laurent. Small note to Matt - the text does not explicitly say that the page-list should use the same format as the TOC.

Tzviya Siegman: One issue that has not come up in this discussion - for people using page numbering with read-aloud technologies, people have expressed interest in the ability to turn page announcements on and off.
… I did not hear discussions of that, and it’s important to note.

Luc Audrain: +1 to Nick

Rick: I’m concerned about telling publishers how the workflow needs to be, but the page-list seems a good idea. If we can’t find the pagelist, we don’t really scan, so we just basically use the 1024 and create a synthetic page list.

Bill Kasdorf: +1 to it being a best practice

George Kerscher: A couple items. Page break always occurs at the top of the page, otherwise you’re effectively taken to the next page. Most people think of normal numbers (numerals) but you could have roman numeral appendixes, or GL123, etc…
… so it’s not always numbers, it may need to be a text string to pattern match against. The page-list in the TOC could specify if it’s a 1, IV, or GL20, you could see that and be taken directly to that spot. Those seem to be the types of things that work. Goto page is terrific feature to have…
… that gives you 2 ways. Either through the pagelist, but it takes you to the same spot.

Laurent Le Meur: see

Tzviya Siegman: We’re trying to talk about implementations, not best practices. We need to talk about the user experience. We will need people to open issues and tell us issues. If someone wants to log an issue from the discussion…

Charles LaPierre: role="doc-pagebreak"

Charles: Since we have the dpub-aria role doc-pagebreak, would we want to do some best practices on escapability - so that can be user preference turned on/off?

Tzviya Siegman: I imagine, but that’s not the topic

Avneesh Singh: I can open an issue describing the behavior…

Tzviya Siegman: we’re trying to keep “implement as you wish” from being too vague so they know how to do this…

Dave Cramer: Things like this that involve navigation, we want to be clear about our expectations. This helps the reading system, and interoperability. If you ask a user agent to navigate to 137 - do they need to repaginate so that the marker is at the top of the viewport?

Laurent Le Meur: about UX/UI related to page break, see

Tzviya Siegman: We have implementors in the real world who have done this - so we need to be explicit about what we mean about “go to a page.” We have experience, but when we talk to people who work on browsers, they don’t know what we mean. So instead of saying “use this in the real world” we have detail.

Bill Kasdorf: This is a print-equivalent page-break, not a dynamic page-break.

Ivan Herman: Suptopic: UC 98

Ivan Herman: ->

Franco Alvarado: “UC 98: When reading a book in the sun, Mia adjusts the background color to allow for a stronger contrast so that she can see the text.”

Franco Alvarado: OK - the next use case. #98. Questions around this - how would you access a UI like this. What would the user-agent do with this.

Ivan Herman: +1 to dauwhe

Dave Cramer: This appears to be a pure Web question. This applies to any text on any screen anywhere. Is there something we need to do differently that what is happening on the web now?

Ivan Herman: Is it happening?

Brady Duga: Yes… It is a little different for publications because you tend to read them for a longer amount of time. Yes it is a real problem for the web - but you’re must more likely to stare at the same publication for 30 minutes, but not a web page…
… there are questions as to how do you control the contrast of a web page. These are hard things to do in CSS.

Wendy Reid: Piggybacking on what Brady said - the way reading systems do it is awkward CSS overrides. If a default text color has an opacity on it, even if you swap the contrast, the opacity or background color can often fall apart. As Brady often mentioned, I’ve seen good extensions, but nothing native.
… It would be an interesting problem to tackle.

Bill Kasdorf: contrast is also a fundamental accessibility issue

Ric Wright: +1 tzviya

Wendy Reid: +1

Tzviya Siegman: I’d like to avoid a publications only solution. There is nothing about this unique to publications. There is a need and much more of an explanation for publishing… We need to do a good job of explaining how it relates to CSS…

Ivan Herman: q_

Dave Cramer: The CSS working group has been talking about this thing, I think. I also think this is an area where we start talking about the underlying OS. There are high-contrast modes and other items where the OS overrides things. I’ll try to dig up some of the recent CSS work, but it’s something people are conscious of.

Brady Duga: I agree with what’s been said. The only political bargaining chip is to mention dark-mode (because it means better battery life). We want to look at it for the web in general, but we want to interact with a systems dark-mode. It might spur more action.

Tzviya Siegman: Accessibility is becoming a bit more exciting too, so that bargaining chip exists too..
… in terms of writing this up in the use case document, the implementation for this is that we implement it the way it’s implemented on the web, but we need to write up something that can be brought up to the CSS group. So what happens builds on what is happening for the rest of the web.

Dave Cramer:

1.2. UC 40

Franco Alvarado: “UC 40: Moby Dick contains 136 chapters. Each chapter is a separate HTML document, with a logical order for reading them. It should be possible for the publication to inform the user agent that the proper order for consumption of the HTML documents is sequentially, starting by the first chapter.”

Ivan Herman: ->

Franco Alvarado: UC #40 - (pasted above) So - discussion about reading order.

Tzviya Siegman: You allow your files to fall how they may and users randomly access content? (sarcasm)
… does anyone have comments on how the reading order is implemented?

Laurent Le Meur: As a RS, we display the first, and we have a way for a person to go from one screen to the next. When the user reaches the end of the read-order-item, then we use the next action to go to the start of the next resource.

Laurent Le Meur: and that works. Continuous scrolling works a bit more difficulty, but it works.

George Kerscher: What I have - we have the reading order so the reading system should seamlessly present one chunk then another. It’s difficult to get to the next one. Without a reading order you have to go back to the TOC then to the next one. Some have a hotkey, some don’t…
… it should be easy for the user to get to the next sequential item.

Tzviya Siegman: I do not want to put negative examples in, but they are good.

Dave Cramer: George raises a good question - would we want an implementation (or would it satisfy the spec) if the user has to go back to the TOC to navigate to the next.

Ivan Herman: Good question, but if we do not talk about the kind of reading system we have talked about so far - but some of the examples on the Web we have talked about very nice examples with service workers, then they may not have the seamless switch from one chapter to another. This is not an unrealistic implementation…
… it may already exist, and it’s not ideal, and it’s not advisable, but in some cases this is what will happen.

Tzviya Siegman: Franco - from your perspective we need to document, and note why this is not ideal…

Marisa DeMeglio: One thing this use case makes me think of is searching text. The RS is in one file, and it wants to search the entire book. And it shows off why this is important.

Bill Kasdort: I wanted to point out that lots of reference publications are never consumed sequentially

Tzviya Siegman: Consumed sequentially, maybe not, but displayed sequentially, yes.

Tzviya Siegman: So then we have a question of - do we have content only accessible through a TOC, does it load sequentially, etc…

George Kerscher: I don’t understand what we want to say. Is this an implementation suggestion? Here’s the minimum? Different approaches?

Tzviya Siegman: Yes, exactly

2. TOC in Manifest issue

Tzviya Siegman:

Tzviya Siegman: I think we may actually be able to close this with Wendy’s help. We have #376.
… there are numerous comments on this. I put a proposal as the last comment. Based on discussions and with many of the people of how TOCs exist in audiobooks. Wendy - anything to add?

Wendy Reid: That’s it…

Proposed resolution: Restricted HTML as described in current draft is the TOC as encoded in Manifest (Tzviya Siegman)

Tzviya Siegman: the discussion is mostly about how the TOC is noted in the manifest. This is about whether - how the algorithm works in the manifest…

Ivan Herman: I will try - (typing)

Proposed resolution: the TOC is encoded using the restricted HTML as defined in the WPUB spec, and that is the only way it can be done (Ivan Herman)

Brady Duga: +1

Ivan Herman: +

Ivan Herman: +1

Tzviya Siegman: +1

Ric Wright: +1

Wendy Reid: +1

Nick Ruffilo: +1

Tim Cole: +1

Benjamin Young: +1

Bill Kasdorf: +1

Laurent Le Meur: 0

Luc Audrain: +1

Dave Cramer: +1

Mateus Teixeira: +1

Tzviya Siegman: Resolved!

Resolution #2: the TOC is encoded using the restricted HTML as defined in the WPUB spec, and that is the only way it can be done

Ivan Herman: (Issue can be closed)

Ivan Herman: There was another issue related to this -

Tzviya Siegman: Thank you for reminding me. Matt and I discussed. Do you recall?

Tzviya Siegman:

Tzviya Siegman: Issue 378

Tzviya Siegman: The last comment - how many possible ways do we want the TOC to account for. I apologize, I didn’t add this to the agenda so people may need time to think.

Ivan Herman: I plead guilty - I was the one who raised this issue, but looking at all the discussion, I am perfectly fine closing the issue with “no further action” and my question should be deemed as - unnecessary

Benjamin Young: my question is about document structure - generally related to the TOC and processing and where those should live. The answer could be “turn in next week.” Is the core piece - the manifest thing - is the data model, and how do you get the spec?
… how do you end up with the data model?

Tzviya Siegman: We’re going to talk about the overall document structure next week. As for this - lets bring it back to github and discuss when Matt has a microphone.

Dave Cramer: This seems like the classic issue where we’re not going to know what needs to happen until we try a bunch of stuff and things go wrong. It’s hard to imagine a bunch of theoretical TOCs.

Ivan Herman: That’ll take a bit of time. The other way around would be to close this to give us piece of mind, and if we hit problems later, take it as we come…

Dave Cramer: this is why we have CR and implementation experience.

Matt Garrish: What we have right now mimics closely what we have in epub. Do we need to expand it more? It has worked well so far. Maybe we can live with it - it’s something we need actual implementation data on…
… it’s probably something we can close off until we have something specific to deal with or let it go dormant.

Tzviya Siegman: I have anecdotal evidence that people want more, but i can put that in the issue.

3. Tzviya

Tzviya Siegman: Before we get to the F2F agenda, i want to share some information. Many know this - I am expecting due at the end of July. You have 2 chairs to help while I’m gone. I don’t have specific dates for returning.

Laurent Le Meur: Congrats!

Luc Audrain: congrats

Bill Kasdorf: congratulations, Tzviya!

Avneesh Singh: Congratulationns

David Stroup: Congrats!

Ivan Herman: photos! photos!

4. F2F agenda

Tzviya Siegman:

Tzviya Siegman: Moving on to F2F agenda. One thing we didn’t ask originally is dietary restrictions. If you haven’t done that, please do add. We have not had many requests for specific sessions.
… We are looking forwards to seeing everyone. We’ll fill up the 2 days of discussion. Feel free to ask any questions. We’ll be in the Google office in Cambridge and are hoping to hear from you. Just add it into the document.

Luc Audrain: Do we figure out a moment with the PBG chairs about priorities?

Tzviya Siegman: you mean a session with the PBG chairs?

Tzviya Siegman: Great topic.

Avneesh Singh: What about the timeline, it’ll also change the agenda. We should start our milestones from there.

Tzviya Siegman: Good idea…

Ivan Herman: Beyond the timeline, what happens when we are a CR - what becomes implementation or not. There is a whole collection of issues about how we organize the CR phase which is never too early to think about.
… the other is - we should have a horizontal reviews and what we do about them.

Tzviya Siegman: we already have enough topics for the 2 days but we’re open to other topics

Ivan Herman: The question to discuss is ‘what profile do we want to talk about next’ so we know who to bring into the group…
… I’d like to make sure wpub is prepared beyond audiobooks

Tzviya Siegman: Tuesday has been shifted to 8-4 - so that people can take the accella (trian) back

5. Resolutions