Meeting minutes
Wendy Reid: Welcome
… today is mostly annotations, ISO, digital comics, plus extra time at the end
… tomorrow we start with BG meeting (no conflict with PMWG), then we take over. Japanese publishing guidelines, html in epub, pub manifest, bugs, buffer for run over
… [see calendar for times]
… This year is a little different, there are breakouts at the end of meetings and before some
… please follow the code of conduct, etc, etc
Update on Annotations
<Wendy Reid> See presentation slides
Laurent Le Meur: [sharing some slides]
… starting with testimony about annotations requesting import/export
… So there are people actually asking for this
… so far there are a limited number of interested parties
… [see slides for list]
… where we are - use cases and requirements are done
… we are actively working on what goes in an annotation
… coming up we will look at selectors, JSON, etc
… Then we have to decide what to do about sync/API
… then it is on to implementations
Github Document: EPUB Annotations Use Cases and Requirements
Laurent Le Meur: [Looking over the doc at github] We now have a shortlist of requirements. Not all requirements will make this version, and perhaps never will. [reviewing the list of requirements]
… This list includes a list of selectors. It also covers import/export and embedding, as well as version resilience. Questions?
George Kerscher: Do we have creator info?
Laurent Le Meur: yes. And also what software created it
Wendy Reid: We also need to consider privacy and security
Laurent Le Meur: More questions? If not, here is the spec I just wrote up: https://
… also some things that don’t exist in the data model. So we can go over what the subset is. We start with the annotation object, with a target and body. W3C has 0 or more, but we only need at
… most one, so we will have 0 or 1 instead. And we only support embedded, not linked. We still need to look at audio/video, it may not be embeddable. Target must have a source URL and selector.
… W3C also has multiple motivations, we will have only 1. They also have multiple creators, we will have only 1, more on that later. We will also restrict the additional properties and their
… values. The document in github covers this in more detail.
George Kerscher: So an annotation will have 2 states, private and local, and one that is sharable, right?
Laurent Le Meur: Sharing is a user action. I don’t think we would restrict that. Why would we want to do that?
George Kerscher: I may only want to share a subset of annotations
Laurent Le Meur: so perhaps filtering would help?
George Kerscher: Well I want to set the sharable state when I create the annotation
Laurent Le Meur: so the user is always in charge
George Kerscher: If I want to make some annotation for a class, some private, some public. I don’t want to tag each one at time of export. So you set that when you create the annotation
Laurent Le Meur: There may be conflicts with the sync of the device
Hadrien Gardeur: I feel we are confusing the data with the protocol. Privacy is only at the protocol level. Since we are undecided on that I think it is too early to work on this. Scope is already
… ambitious, I think we need to restrain ourselves to the non-protocol level
???: we have a section on sharing and comments, so does that imply that requirement should be tied to the protocol?
Laurent Le Meur: Yes, and we need to keep manual sync separate from auto sync. [Now reviewing properties from w3c model, with a list of what we will keep] [shows clean and small json with this data].
… Target has a meta property that doesn’t exist in w3c model. We can annotate any item, it doesn’t need to be in the spine. For body we are limiting to textual, but may need to revisit. [shows
… body example] So if we can agree on target and body we are basically half way. On to annotation set - we are adding a few things. I propose adding DC properties to the About object, which can
… be used to identify the book. It is really all we have to work with.
Hadrien Gardeur: We have discussed this before. Even before CFI we had epub linking. It was hard and we never managed to do it. EPUB identifiers are just sad. This is only really useful if you don’t
… have the book. I have zero trust that this will find the right book. I think we should focus on making the annotation useful without the book. I think that is the direction we should go -
… this is context to make the annotation useful by itself. We should keep this list short, but focus on the useful parts
George Kerscher: I heard citations would be supported. This DC info would help with that. We talk about books, but journals are heavily annotated. Need to keep those in mind.
Marisa DeMeglio: I saw there was a highlight property. Will that be compatible with CSS highlights?
Laurent Le Meur: I don’t think these values work with CSS highlights
Marisa DeMeglio: CSS highlights are still pretty restricted, but you can do a lot
Laurent Le Meur: But if we have a device not based on CSS, or perhaps on audio, etc, I still want this to work
Marisa DeMeglio: So the non web based reader would probably only support a few things, a non-display device might discard it. [lists the things supported by CSS highlights] I was just curious if this had come up
Laurent Le Meur: For example, color could support every color, but in fact reading systems only really support a handful. We have limited them to a set of specific named colors (see spec). And then leave it to RS to decide which color to use
Wendy Reid: Yes, even in a reader the specific color may change based on theme
Hadrien Gardeur: I have looked at a bunch of readers [gives breakdown by reader] Most have just 4 or maybe 5. Only yellow seems to be universally used.
Wendy Reid: On styles, I have never seen strikethrough. But it brings up the use for copyediting, lie work substitution
Laurent Le Meur: I am sure it will be used by publishers, maybe at last round of review. So not for pro copy editors, but I don’t think we need to go to far
George Kerscher: I have heard the term red line used, does that have specific meaning?
Wendy Reid: Yeah, especially in legal documents. Used to amend contracts, etc
… then it is on to implementations
<Laurent Le Meur> https://
Wendy Reid: we still have some time, do we want to dive into nitty gritty details?
Laurent Le Meur: There is a section we didn't discuss
Magnus Rudolfsen: We have a reading system used for students, they used colors for hightlight. Is there anything in the spec to correlate color and meaning?
Wendy Reid: I think keyword may come in here. maybe tags is better? Color is a way people annotate, but with only 4 colors maybe tags would allow for more customization
… I wonder if we should think about tags and keywords together
Laurent Le Meur: We went back and forth on the name. They are related
Hadrien Gardeur: But this is different, we Magnus is asking for a color means a specific thing, vs color and tags can be combined
Magnus Rudolfsen: So colors have specific meanings for the students
Laurent Le Meur: this is more like a config setting in the RS, connecting a color and a tag
… so we have to decide if thus is in the model or just up to RS
Seth Delackner: So we need to make it easy to connect these things, but the data would just know the color
Wendy Reid: A lot of this will come down to what the RS wants to do and allow for
… I can imagine in a group context, I may use colors and tags, I can share with other people so they understand what the notes are about.
… So we should break visual display and meaning apart
Magnus Rudolfsen: You may also want to filter by type
Wendy Reid: any other thoughts?
Laurent Le Meur: I have some sections on filtering, as well as multiple selectors
… selectors should include a precise one, but also one that will survive mutation
… We also looked at extensions
… Also discussed putting this file in METAINF (for embedded annotations)
… This has implications for signing EPUBs, but no one does that
… There is also a section on the order of importing. Basically a recommendation to not bother with automatic detection
… And also a recommendation on what to do if the RS does not support a color
… It would be could to have people review these
… Questions?
George Kerscher: Media is supported, can audio and video be annotated?
Laurent Le Meur: it is in the requirements, but I think v1 should start with text.
… We might allow full image in v1, but segments of images, videos, etc, most RSes won't be able to do that. So we should push that to v2
… The evolution there will be with selectors. That is all that needs to change to support that
… the issue isn't how to specify, but support for it
Wendy Reid: Currently we just have textual, not audio and image?
Laurent Le Meur: yes, the big issue is how to embed
Wendy Reid: A lot of annotation is currently done via images, anything with a stylus does that
… so we probably need a way to embed this in annotations
… it may be hand drawn text, images, etc
Laurent Le Meur: there are two issues, one is export file format, and how do we put that in an epub
Brady Duga: Question about the stylus drawing, we never quite knew how to attach to the text in a way that was meaningful. If the content split or was adjusted, it was lost
… attachment was a challenge
Wendy Reid: We would drop a selector in that position. If you drew a circle, we couldn't show the annotation, but just drop an icon to show the original image
… so still selector based to the first point
… so the problem isn't really solved
Hadrien Gardeur: it is very device dependent
… It is more like a bookmark, it is not as specific as textual. But this is now growing
… So worth investigating
Laurent Le Meur: Also commenting in other languages is important. We can support plan text and markdown. Do we need html to support ruby for annotations in Japanese? I have heard that this is uncommon in comments
… which would be great since not everyone supports html in comments
… and markdown works for basic styling
Murata Makoto: if you want to publish annotations, then ruby would be required
… so this is out of scope at the moment?
Laurent Le Meur: there was a case of an author wanting to publish a book with their annotations
Murata Makoto: sometimes the annotations are more important
Wendy Reid: In terms of publishing with annotations, wouldn't these be embedded in the content? This is part of the book
Seth Delackner: So if a famous author is editing their own book, annotates it, then send it on to the publisher the natural way is annotations in the epub
… so are we creating a world where there is a separate system to make these annotations?
Shinya Takami: Actually image based characters are more important than ruby
… but I am not sure about the publishing the annotations case
George Kerscher: Annotations point in to the book, footnotes point out. Second if we are not using html and someone inserts an image, is it just a jpeg with no alt text, etc?
Laurent Le Meur: So for image annotations? For body we could easily add alt text as plain text in the json
… with the body as an object, we can add any property
Wendy Reid: Thank you for the update
ISO and Liaising with ISO/IEC JTC1/SC34
Wendy Reid: Two things to discuss, first is ISO port of epub 3.3 to ISO
… By which I mean the full family of specs
… we agree it should be done, but timing has been an issue, due to some EU complications
… we now have some info about that. There remain some unknowns, the short description is the EU a11y act caused a letter to go out about publishing standards, specifically EPUB.
… This is all good, and it means the EU will adopt EPUB.
… the problem is kicking off ISO process may cause problems with that adoption. We have some questions - what exactly is the problem? Just starting it? voting? etc
… And does this apply to everything or just a11y spec?
… we are still trying to figure out who is talking to each other at ISO and w3c
Cristina Mussinelli: This all sounds accurate
… The committee needs to wait if there is an ISO spec in process
… Second, the commission will accept the w3c standard
… So I am glad the commission has contacted w3c so we can better understand the timeline
Murata Makoto: We also have Yong-Sang from JTC7 SC34
… Perhaps he can comment
Yong-sang Cho: I have only heard about this from you (makoto)
Murata Makoto: Can you give our position?
Yong-sang Cho: EPUB a11y is important to ISO, as members can adopt 3.3 as a national standard
… This is why we really want these in ISO, so we can adopt these important specs
<Ivan Herman> See presentation slides
Murata Makoto: I have been a member of SC34 and w3c and epub for decades
… I will be chair of SC34 shortly
… I have a new company working on bringing LCP to Japan
… LCP is not w3c rec, it was created by IDPF and Readium. It is now part of SC34
… There are a lot of committees, including one on AI. ISO is the right place to discuss things that matter to a number of countries.
… We are currently looking at scrolling comics, EPUB, LCP
… there are a number of groups under SC 34
… [see presentation for list]
… we have some specs on EPUB3 preservation
… AHG1 is for scrollable comics, but it does not make specs
… it could create terms of reference that could make a spec, but it is hard (multiple countries have to agree and nominate 5 experts)
… This is recreated yearly (it is an ad hoc group, so not permanent)
… Currently there is no proper relationship between this group and SC34. I would like to present documents from AHG1
… I am looking into filing documents for this now
… The current specs at ISO are very old
… I have not been able to update these
… we also have epub 3.0.1, these are also very old, but are listed as current
… same applies to epub a11y
… Now to summarize normal vs. fast track process
… Normal has lots of specific rules that have to be followed (e.g. May is not really used)
… PAS or fast track is used for moving things standardized elsewhere
<Cristina Mussinelli> it is worth to highlight that the EAA has a global impact as all international organizations willing to sell in Europe should comply with the EAA requirements and standards
Wendy Reid: Question - does this mean we don't have to do editorial work to change language?
Murata Makoto: correct. I don't know where that idea came from. There is a cover page that will be handled by ISO, other minor things
Laurent Le Meur: So pagination since it is PDF there will be some changes, that is ok?
Murata Makoto: Proposal - SC34 should withdraw the old specs
… This is really bad, these should not be the current version
… I strongly advise that EPUB 3.3 and a11y 1.1 be submitted with NO changes
… Since I will be chair, I hope we can establish a better relationship
Wendy Reid: Thank you, this is good to hear. We were worried about making the changes, so that makes this a lot easier
… the existing relationship was with publishing @ w3c, so I would like to understand if that still includes us since we are under that
… I am very interested in the scrolled comics work
Avneesh Singh: we are aware of the ISO process and the requirements
… We are currently wrapped up in the political issues. Not everyone is in the same loop
… There are discussions with EU, and with ISO, and with w3c and ISO and these are all different conversations
… I am concerned that we are having all these discussions without a proper strategy in place
… I am tired of the adhoc relationship, we need a proper strategy
Murata Makoto: In the context of wcag I have had a lot of problems with the EU.
… Many japanese changes have been rejected
… my opinion is that a special relationship with w3c and EU is a problem
Cristina Mussinelli: This is really a national issue, but it is also a business issue. There is a BG that needs to be involved
Wendy Reid: One challenge has been that we don't have all the information
… I did know not that the commission and w3c had been talking
… and that the commission and w3c have been talking
… this is a big deal, but we really need to know who has been talking
… and it is very odd that people are talking and not including the chairs
… so I think we can move ahead with liaison with sc34 for now
… and try to figure out the rest
Matt Garrish: We really need to get to a place where these can be kept in sync
… I was editing the metadata for conservation document, and I had to keep saying what was different between these specs
… the current space is simply not sustainable
Cristina Mussinelli: When we presented to the commission it was as w3c
… we have had a problem with people contacting w3c and not getting a response
… this is an opportunity we don't want to miss
Wendy Reid: Pedantic question - we have epub 3.3. and a11y 1.1, but we are working on 3.4 and 1.2. If we publish one version, can we leave 3.3 with the EU? Or can we not publish anything?
Murata Makoto: The fast track process is quick
Laurent Le Meur: How many countries have to say yes?
Murata Makoto: I don't know. But many will just say yes, because they lose voting writes if they fail to vote
Ivan Herman: Murata Makoto, as far as I know, we have to go through an editorial process, right?
… that process means going between the two formats is a lot of work
Murata Makoto: I strongly believe that is incorrect
Ivan Herman: WCAG had to go through this painful process, why are we different?
Murata Makoto: I reviewed the wcag ISO with w3c and the only difference is the cover sheet and index
Yong-sang Cho: JWG7 would like to take the responsibility for the editorial changes. We would like to pursue with just adding the cover page, but if there is a different position, then JWG7 would like to take the entire conversion effort
… Just format work
… Without changing the requirements from the original spec
Ivan Herman: Thank you, it will be an enormous help
… I don't know who to contact for a once and for all final statement on what we need to do
… we keep hearing different things
… who at ISO has the official role to make such an official statement?
… if it is just the cover page, then this radically changes the situation
… Then the 3.4 question becomes more interesting
… but where should we go for a proper answer?
Murata Makoto: Since I will be chair I should set up a meeting with ISO Geneva and this group
… how does that sound
Yong-sang Cho: we have 2 very strong options - [talk to the technical program manager and also makoto can talk o the editorial team at Geneva
Cristina Mussinelli: The EU will not publish an official standard, they will adopt the W3C version
Ivan Herman: The message I have from the EU is don't publish an ISO standard. So my question is can we work in parallel? Can we leave the w3c spec alone, and start working on ISO, but not publish until the EU is ready?
… if we do this with 3.4 since it is a good 1.5 years out
Cristina Mussinelli: we should organize a meeting with the commission to answer that
Cristina Mussinelli: I think it is important understanding if the spec is alignment with the commission
Avneesh Singh: Fast-track will start after 3.4 after it is done. I don't understand how we could start it now?
… it has to be rec track first
<Ivan Herman> avneesh: epub 3.4 /a11 1.2 are rec-track
Avneesh Singh: I would like to get to an arrangement where EU isn't lagging behind
Murata Makoto: I have a fundamental concern that giving EU special status is unfair to other countries
… I respect the work done, but it doesn't mean the EU can decline what other countries do
Ivan Herman: I am not sure what is a problem, re Avneesh Singh
Shinya Takami: How long does it take
Murata Makoto: 8 months plus bit, so say 1 year
… if we want to delay we can request that
Shinya Takami: Can we stop publishing?
Murata Makoto: you can always withdraw at any time before publishing, even if all countries have voted yes
Shinya Takami: so it is canceled?
Wendy Reid: Yes, but we could restart
Cristina Mussinelli: I don't think EU will stop. The question is an international one, so we can sell everywhere
… I am not so sure that everyone in Japan agrees. This needs to be a business decision
Wendy Reid: let us drop the international issue. This is about logistics. We don't have all the info yet, so we need to figure that out first
Yong-sang Cho: I am curious about the EU standard you are referring to? What standard do you mean?
Cristina Mussinelli: There is not standard for ebooks, they will adopt a technical spec
Yong-sang Cho: Usually the ISO standard is auto (maybe) adopted by EU
… We should make epub a living standard
George Kerscher: I love that, it sounds great. I want to move things forward in parallel and avoid the sequential nature
… I don't like having to get it locked down, then sent to ISO, then having issues that can't be resolved
… getting things to move forward smoothly would be grat
Murata Makoto: when epub 3 was submitted there were a lot of requests for changes that I resisted
Avneesh Singh: We need a proper relationship with ISO, figuring that out will solve these issues
… To ivan it was about 3.4 going to ISO
Ivan Herman: I misunderstood
Wendy Reid: I have reached out to see who I should talk to, apparently it is Rigo. We need to figure out the parameters on all 3 sides. Would be great to have all 3 in a room
… we do not want to favor one group over another
Murata Makoto: Do you feel comfortable with an official relationship between us and SC34?
Wendy Reid: No problem, sounds good
George Kerscher: I hope the ISO publication is something that is not in PDF would be important to me
Ivan Herman: Two things. One is I hope we are talking about the 3 rec track docs, and not unbundling
… second, to broaden what George_ said, my understanding is that what is published in w3c and iso the two texts should be identical
… I know it is hard to get ISO docs into the public as html. I don't hold my breath though. W3C will still publish as html and make it available, so I don't really care
Wendy Reid: What do we have to do to get the relationship done?
Murata Makoto: We just have to file a form. We just need to find someone to sign it
Daihei Shiohama: What are the next steps on the international relations side?
Wendy Reid: Next step is to find out who is talking to who. Then maybe schedule a meeting where we can all meet
… For instance, understanding timelines would be very helpful
Daihei Shiohama: From the global publishing side, the reason we need to take into account EU is the eaa has already been enacted
… those a11y requirements affect the entire global community
… The global system is interconnected, we have to give due consideration to all members, including the EU
… The reason we must take into account the situation regarding EU accessibility is that the EAA has already been enacted
as a binding regulation, and its accessibility requirements affect not only Europe but the global publishing industry as
a whole. Similarly, in the United States, the ADA is in effect, and Japan and other countries each have their own local
accessibility laws. Since the international eBook ecosystem is interconnected, we cannot disregard the specific
circumstances of each region. In my view, it is both natural and necessary to give due consideration to the established
EU context, as it cannot be ignored
Wendy Reid: That is what has made this so difficult
… we understand the importance of all sides here.
Brady Duga: Love having this conversation over and over again, I want to have this joint meeting, I would like to see that the EU has been saying "don't go to ISO until..." we need to know the "until"
… it doesn't have to be an exact date, but we need to know a date
George Kerscher: The tricky thing is getting someone to speak with any authority
<Seth Delackner> Regarding the discussion around whether we are required to apply the editorial grammar rules when using PAS:
<Seth Delackner> In ISO/IEC Directives, Part 1 – Consolidated JTC 1 Supplement 2023
<Seth Delackner> https://
<Seth Delackner> "F.3.4.2 PAS Submission”
<Seth Delackner> Paragraph 5:
<Seth Delackner> The format and content of the submitted specification are not required to comply with the
<Seth Delackner> ISO/IEC Directives Part 2.
Seth Delackner: I have no context for a lot of this, but I did some research on fast track process
… [see link]
… basically contents does not have to be updated
Ivan Herman: The problem is, that used to be the case for sure. The info I got 2 years ago is that ISO changed this
… so we have to check that that is still the official statement
Murata Makoto: Lots of things happened to normal process, but not to fast track
Update on Digital Comics
Shinya Takami: We'll start the afternoon session, update on digital comics, Hadrien has a presentation
Hadrien Gardeur: Tried to summarize where we are right now, afternoon sessions will be related to comics
… not necessarily have the discussions now, but set the table for those later discussions
Hadrien Gardeur: if I had to summarize why we're doing this at all, EPUB is also for comics, not great for comics
… it shapes a lot of the current work
… when we look at adoption of EPUB for comics, it varies by country
… in Japan, it's an interchange format, you get what you need and discard the rest
… in Europe and the US, it's different, ebookstores use EPUB as is for comics
… not just interchange, but also display
… what we've also seen, many of those stores also accept PDF
… specialized stores, ones that specialize in comics, many don't use EPUB at all, some may ingest it
… in South Korea, they pushed for a TTA standard (local), for continuously scrolled comics, they consciously chose not to use EPUB
… EPUB is not the default standard for comics
… it's used, but there is no single place where it's the standard, it always lives alongside other formats
… example of new comics store, SweetShop, they sell PDF
… other one, Panels, more EU, they'll be using CBZ/PDF
… speciality stores not using EPUB
… and why are people not using EPUB?
… it's a number of things, in some cases, people think PDF is good enough
… it has native support
… there has been a community standard, CBZ, which has been out for a long time
… good enough for people for a long time
… those have played a role in EPUB adoption
… EPUB makes it hard to work with images, we can talk about this in the afternoon
… we don't provide clear industry guidelines
… different places have different ways to use EPUB, EBPAJ, more like a template
… no guideline to "properly" do comics in EPUB
… this seems more necessary for comics vs other publications
… neither PDF or CBZ can support continuously scrolled comics
… places where EPUB is better, other formats don't have spread control
… spreads are under and over specified
… last area we are better, metadata and semantics
… we have useful, specialized metadata
… even EPUB basic metadata, but we don't have the full metadata for comics yet
… we have semantics from DPUB ARIA, etc.
… need more added for comics
… where we are now with EPUB 3.4
… images in spine, contentious topic, but ask questions for our discussion later
… we have AVIF and WEBP support, modern image format support
… moving in the right direction
… we agreed on "roll" as a layout value
… we haven't agreed on how to deal with those documents, what is in the spine
… we have open issues on spreads, there are a few things that need to be addressed
… comics specific metadata
… semantics, need more discussion
… some progress, lots to discuss
… let's talk about images in spine, primary need is to identify an image for a specific page
… what we need is an ability to say "where is the image"
… might be less contentious than images in spine
… images in spine currently possible with fallback
… usage today, we know in Japan do images in spine without fallback, there are also publishers using images in spine with fallback
… it's not new, people use it today
… questions we need to ask, should we allow them
Hadrien Gardeur: Can we allow them? Do we do it for roll documents, pre-paginated, if we do it, how far
… if we don't allow them, how can we make things easier?
… we need to test things out in several different ways, if it was clearer where to find the images, maybe that would be better
… we know there is usage of fallbacks, it is in use in Japan, EU
… there are many that use it right now
… we might need to use a new property, or lean into what people are doing
… roll documents, we're blocked a bit by images in spine, we either say we do images in spine, or fallback
… everything else would be a missed opportunity
… if we force HTML in the spine, it's complicated for the sake of being complicated
… expectation gap between what producers are doing and EPUB
… expectation on the market that first page is displayed on its own, regardless of spread info
… but we don't say anything about it in the spec, we should align with expectations
… what does it mean when we have page-spread-*, the spec says it is meaningful, production differs
… some people always include it
… it means they want control, but there is a mismatch
… I don't think it is a bigthing to solve but should be
… how much control do we want to give over spreads?
… values are overused or problematic
… for semantics, we inherit many values from AHL WG, mostly to describe contents of a page, but not used much outside
… there is a need for panel by panel, Amazon asked content producers to provide, but they need to use specialized software, there is interest in panel by panel
… shame people don't use EPUB
… we also have the ability to indicate volume and chapter
… in Japan chapters are sold, but elsewhere it's volumes containing chapters, but we can leverage that
… we need new things for continuous scrolled comics, we have seasons, episodes, issues
… it could be relevant in a variety of markets
… metadata, we need additional metadata, similar to document divisions
… to say an EPUB is a volume of multiple chapters
… question of EPUB or ONIX
… we've had people ask for this, need series, story arc
… just wanted to set the table for other discussions
Ivan Herman: General question, before we dive into the technical discussion, lets say we solve all these issues, has the boat sailed on adoption?
… would we change the picture you painted at the beginning, whereby most people don't use EPUB
Hadrien Gardeur: Good question, for paginated comics, we may have missed the boat, but for continuous scrolled comics, things are behind closed doors, there's no cross-platform standard
… I could be wrong about paginated comics, but things can changed
Ivan Herman: To be more specific, we have the W3C process, if we do all the changes in some way or other, will we even have enough meaningful implementations to pass CR transition?
Hadrien Gardeur: Images in spine, we probably would, many of those reading systems don't consume EPUB
Ivan Herman: If I wanted to be a purist, it would be irrelevant to transition
Hadrien Gardeur: I'd need to look into it, it's supported in some reading systems, two might be possible
… for roll, that's new, we'd need new implementations
… for spreads, its aligning with what people already do
… semantics, what do we expect RSs to do with this?
… seasons or episodes may offer breaks in the scroll, but its an unknown
… metadata, depends on our expectations for RSs
Ivan Herman: What we used in 3.3 for metadata, there would be at least 2 systems that make a valid use of the metadata, how they use or display the content is not in our control, but if its useful to have it
Hadrien Gardeur: The state of EPUB metadata is complex, there's cases where ONIX is preferred, the main use is sideloading, if we target that, we could have implementations, but it would be doable
Shinya Takami: If they are optional features, they don't need to meet the criteria?
Brady Duga: I want to disagree with Ivan about implementations, a reading system is more than a device, if a reading system can accept features and eventually display them, that's an implementation
Ivan Herman: I don't think we disagree
Brady Duga: My question then, some of these things, finding the images in the HTML, these feel like heuristics
… I don't know if these belong in the spec, or a separate document, if you want to do this optimized image thing, look here
… does this need to be in the main spec
Hadrien Gardeur: I think that's a good question, we may need a best practice document for comics, I agree, some of this is heuristics
… I agree that not everything should end up in the spec
… it could be in a complementary documents, recommended semantics and metadata
… less fragmentation
… even in single markets we have fragmentation
Toshiaki Koike: Question, implementation for images in spine, if Voyager's and Kadokawa's reading systems implemented, would it satisfy W3C's standard?
Hadrien Gardeur: These are already implemented?
Shinya Takami: I think they are, if both of us have these features
Ivan Herman: I don't know the internals, if they are independently developed, they meet the requirements
Hadrien Gardeur: And it works in Thorium as well
Wendy Reid: Had this discussion with EPUB 3.3
Wendy Reid: There's the W3C implementation bar: 2 independent impl of a standard
Wendy Reid: We also have discussion with 3.3, we agreed that, 2 was not quite enough for publishing.
Wendy Reid: Because of the huge diversity of reading systems and reading platforms
Wendy Reid: It's great to have 2, but 2 is not enough to reflect that feature being well-supported
Wendy Reid: If we have 2-3, it means we cleared W3C bar, but on the way to our own declaration of well-supported
Wendy Reid: I think us meeting the W3C standard is relatively simple
Wendy Reid: it's more whether publishing industry supports that we need to worry about
Hadrien Gardeur: I might be wrong, I think we'll have more than 2 for AVIF, it's more than that for images in spine, quite a bit more, spreads and so on
… there's always a risk when we introduce new things what the support is
Shinya Takami: Any questions before we get deeper into this?
Images in spine
<Shinya Takami> https://
Shinya Takami: The first topic is images in spine
Hadrien Gardeur: I think this has been contentious, we've discussed for a long time, it came up when we first discussed FXL
… we know that images in spine are used, we also know that people have issues with them, mainly for accessibility, I kind of feel that we're stuck in the same discussion loop
… we have the same arguments for or against
… we never manage to move forward
… we're stuck as a result with the status quo, my questions I hope can move us towards a solution for this
… we have some options within the spec, other options might require changes to the spec
… we should avoid the status quo, I don't think it's good to have a difference between the spec and the industry
Brady Duga: So you often point out that there aren't really accessible comics, or they are hard to do
… I agree for comics, it doesn't make sense for XHTML, but for FXL we do have accessible content
… in that perspective, it is an accessibility issue for FXL, this subset of content is huge, comics is a big industry
… for children's books, it's good that that content is accessible today
… people are making use of these features
… it's not fair to disregard the accessibility aspect
… but if we do something for comics, that is weird, but we have rolled content, not sure if we should forget about HTML in this respect either
… the other question, you listed two options, image in spine or image in spine with fallback HTML
… would HTML in spine be illegal for roll comics?
Hadrien Gardeur: Not saying it should be illegal, it would be disappointing to those producing that content
… we shouldn't force people to put images in spine, but shouldn't force HTML either
… would negatively impact adoption
Laurent Le Meur: In every specification, certain things are triggered by certain metadata, roll comics are triggered by specific metadata
… we could say accessibility of scrolled comics is different, if we say we want to do the same for paginated comics, or do something different
… we could extend the time of solving the accessibility problem
… we don't have that content on the market, we don't know what an accessible comic needs to look like
… more research needs to be done
Hadrien Gardeur: There is a difference between partially accessible comics vs fully accessible comics, we don't know what makes a fully accessible comic
Laurent Le Meur: Just adding HTML to comics doesn't make it accessible
Romain Deltour: I have a simple question, does it have to be EPUB
… images in spine, it creates hurdles in interoperability, could it be a separate standard, a profile, something that is different?
… another question about CBZ, basically a list of images in a zip, could be we somehow have a hybrid CBZepub?
… could an epub be a CBZ or vice versa
Hadrien Gardeur: First question is good, we see some places saying EPUB is not the solution. But one option to discuss, do we do something more like web publications, SK is doing JSON with metadata and some controls
… it goes to Ivan's question, has the boat sailed
… but for some markets, EPUB is huge, like Japan, we can't pretend people don't use it
… for CBZ, the order of images matter, the .epub may not be recognized by CBZ readers
… you could name images in a way that works for CBZ
… you could make something that works for both
… or a packaged web publication that could also be an EPUB at the same time
… maybe a little too creative there
Wendy Reid: I think I share Romain's question, does this have to be EPUB?
Wendy Reid: One of the underlying parts of this discussion is, philosophically, what we think EPUB is?
Wendy Reid: Do we think that, as the group that maintains EPUB, who do we serve and who do we follow?
Wendy Reid: We try to strike balance between what industry wants and what readers need
Wendy Reid: And lately also government regulations
Wendy Reid: On the surface, about images in spine, questions what do we want EPUB to be
Wendy Reid: Many of us fought for EPUB to be the accessible standard, accessible by default.
Wendy Reid: Images in spine is where we need to make decision, in order of priority, where do we put things?
Wendy Reid: Does accessibility trump everything?
Wendy Reid: Disappointing that some markets didn't choose EPUB as the standard, for variety of reasons
Wendy Reid: But companies releasing apps with PDF or CBZ are not thinking about accessibility
Wendy Reid: in their application or business model
Wendy Reid: That's a choice that they made in their business
Wendy Reid: But do we want to make that choice for EPUB
Wendy Reid: We know there are many inaccessible EPUBs out there, because businesses made that decision. But for EPUB, you have to make a *choice* to make inaccessible. We give all the tools, they choose not use.
Wendy Reid: But here we would give them a tool to make inaccessible content.
Wendy Reid: Make that possible.
Elika Etemad: What are the implementation challenges with having images in spine vs in HTML
Hadrien Gardeur: Apps that implement this, they don't use webviews, they use platform APIs, with HTML they need to find ways to render those images, if its SVG they need to rasterize the images
… not saying they should do that, but that is what they do
Elika Etemad: Is there or has their been an effort to create a profile for HTML that prioritizes images?
Hadrien Gardeur: Japan has it, it's not used by everyone even in Japan, it's something you know if you're in industry, but it has no official status
… the closest would be the EBPAJ profile
Elika Etemad: Would it make sense to standardize on that?
Hadrien Gardeur: Possibly, it falls on the line of having an alternate profile or best practices document
Elika Etemad: The HTML file would need to conform in a spec, it would validate, for reading systems would know to parse as an image, but we have the additional structure, the framework for creating accessible content is still there
Hadrien Gardeur: The reality would be it might be fragmented, but would move people in the right direction possibly
Ivan Herman: To put things in perspective, the approach Romain suggested is how we published the audiobook standard
… it follows the rules of Publication Manifest, it's an analogy
… a very different point, at some point in your slides, image in the spine fallback to HTML as a solution, there were two other approaches discussed, one was suggested by Matt
… referring to the fact you could put the alt into the package, it's legal in the spec,
… other possibility was to include the accessibility info in the image itself through metadata
Hadrien Gardeur: The first is to use meta:refines, refine the image using it's id to provide description
… one way to do it
… those have been discussed before
Gregorio Pellegrino: We can have images in spine with fallbacks, I suggest we leave the spec as is, we advise on how to make comics
Romain Deltour: For the sake of completeness, in one of the slides you mention was the objective was to link a page to an image, maybe it's also possible to use the nav doc, may also be used to link the pages to the document
… not sure if that works, maybe worth looking into
Seth Delackner: I have missed some of the previous meetings, we've heard a lot from reading systems people, I never hear from publishers
… I want to know what the issues are with tooling to add the necessary accessibility info to documents
… it can't just be there's no interest
… there must be challenges
… is there a gap in the EPUB production process that blocks this being possible
Hadrien Gardeur: A page in a comic can have a lot of information, you'd need to describe each panel, and even within panels
… comics are visual by nature, for screen readers, you'd need to produce text in the right order
… almost a transformation of the content, like a novelization
… there's a huge complexity in how to produce the thing
… do you need to get the author involved, are you following the author's intent?
… lots of open questions and cost associated
… if the resulting text is just a huge block of text, it's not functional either, it would need to be a full HTML document with everything you'd need
Hadrien Gardeur: Some of it is cost, some of it is technical, there's needs beyond just screenreader users
… one panel at a time plus text to speech, not only do you need equivalent text for a given fragment, then we have tactile images
… we can do some of that today, we can't do what say EAA expects
Ivan Herman: I want to come back to what Gregorio said, and the spec of today allows what you need as allowing an HTML file as fallback, I may have misunderstood the second part, this may only be valid for roll comics
… I would be uneasy to add something to the spec for just one type of content
<Elika Etemad> +1 Ivan Herman
Ivan Herman: it relates to what Hadrien said, falling back to an HTML file, seems to be only a rudimentary way to handle accessibility for an image
… not sure we can handle it today
<Romain Deltour> +1
Gregorio Pellegrino: Ivan Herman, my proposal was not to allow this way only for roll content, since it's already allowed for any content in the spine
… my proposal was to have guidelines for producing comics
<Ivan Herman> +1
Elika Etemad: I wanted to scope the question down to sighted users who need accessibility support?
… to make that work, you need to have a format to support that additional content, you need a reader to support that, and you need tools to produce that content
… does any of that exist?
Laurent Le Meur: No
Elika Etemad: If we want EPUB to be able to do this, is images in spine getting us closer or further to that?
Hadrien Gardeur: We're years away from being able to do what you describe, its too early to say, I don't think it would be a step in the wrong direction to add images in spine
… if we really want to achieve comics accessibility we can say its someone else's problem, or we can work towards it
Wendy Reid: Discussed in fixed layout accessibility task force about that. How do we make this possible?
Wendy Reid: We have some proposals, to solve what Elika described
Wendy Reid: Discussing side-by-side content
Wendy Reid: parallel content that's related to each other
Wendy Reid: I don't think we're as far away from this as we think we are
Wendy Reid: There are reading systems already that do side-by-side content (forgot name)
Wendy Reid: One that allows fixed layout and relayout together
Wendy Reid: A lot of it, unfortunately, it's about tooling.
Wendy Reid: Lack of will to make this happen
Wendy Reid: Especially nowadays, with AI, offers us a lot of ways to automate this that previously would have been fully manual
Wendy Reid: Only a few years ago, alt text for comics would have been fully manual, now can automate much of it
Wendy Reid: Image detection of panels
Wendy Reid: Etc.
Wendy Reid: I'm reluctant to say that it's not possible. It's increasingly possible.
Wendy Reid: Alternate format providers are already doing this work, just mainstream publishers are not
Wendy Reid: So I'm reluctant to give in on this.
Wendy Reid: We have the technology. Some of the tools already exist.
Wendy Reid: A lot more publishers can do in content development that they're not doing.
Wendy Reid: And more on reading system side that could make it possible
Wendy Reid: I've seen scrolled fixed layout content in EPUB readers. It's not impossible.
Wendy Reid: Doesn't mean we should make provisions in the spec to sacrifice our principles
Shinya Takami: We have 10 minutes left, we want to conclude this topic in TPAC, maybe gpellegrino's proposal, using the spec as is
… we will not make consensus to make images in spine without fallbacks
… should we vote on this?
Hadrien Gardeur: I think some people don't like image in spine with HTML fallback but its the current spec, having a best practice document that describes how to do this, that is doable
… it solves what I was mentioning, that helps to drive things toward clearer guidance
[Seth asks question about tooling and alternate text in Japanese]
Seth Delackner: Can someone from the Japanese publishing community share why they don't produce accessible content, is it tooling or something else?
Toshiaki Koike: When preparing alt text for manga, just the speech bubble text is not sufficient, but people make prepare the description of the story, we can't prepare that content without the author
… it's difficult to prepare that content
ここには日本の出版社の人がいると思うので、聞きたい。漫画はなぜアクセシビリティをサポートしないのか。どういう理由があるのか？
Ito-san: Japanese publishers don't have the right to produce that type of content, only authors can
Shinya Takami: I'll explain this a bit more tomorrow, manga content is generally out of scope
漫画のアクセシビリティというのは、何を情報として含めるのかが難しい。ただセリフをテキストに変えさえすれば、漫画のコマに含まれている情報を正確に伝えることができたというのかというと、そうではないとも思っていまる。
Hadrien Gardeur: Just wanted to reply to Wendy's comment, and it leads into the next discussion
… there's a number of documents that can't be made fully accessible, we have children's books, textbooks, comics, the solutions for all those can be slightly different
… there's options for magazines, newspapers, there's content out there where you can view articles
… we don't have a way to support those in EPUB
… I've talked to many people, but they are missing the format, they don't know how to distribute it
… I don't think comics fall into that, comics is a lot about storytelling, comics have more in comics with media overlays or SMIL than textbooks or newspapers
… there's AI solutions out there, but they haven't been tested, and they don't have a way to represent that
… there's prototypes, but it's still early
… we don't have an easy way out of the hole we've dug ourselves into, is it now or in the future? Up to us
Ivan Herman: The way I read the standard now, for each image you'd have an HTML fallback, ideally one HTML with the alt text, making the publisher's lives easier, but you can't refer to a fragment in a fallback
… if this is our solution, we force the author to produce one HTML per image
Tomikura-san: What accessibility features do people want?
Hadrien Gardeur: We hear from people that there is interest, people want access to what their friends are reading
… also with EAA, in theory, most books on the market will be natively accessible, orgs will re-orient to focus on different types of content, usually education or comics
… orgs want to produce the content
… maybe publishers won't do it, but alternate format providers will
… with Marrakesh treaty, people can do this, we might be in a world where speciality providers can do this work
… it doesn't put burden on publishers, but it does create challenges for the providers
Process Discussion
Brent Zundel: I'm from the AB and I'm here to help!
Brent Zundel: Feel free to contact me outside this meeting also.
Brent Zundel: Scope of what we're looking for feedback on.
Brent Zundel: Chartering a group - how did that go? Was it straightforward?
Brent Zundel: What about publishing?
Brent Zundel: What problems block you from moving along REC track?
Brent Zundel: Are there things in Process to make easier?
Brent Zundel: Have you ever dealt with formal objection? Suggestions for improvement?
Ivan Herman: My experience as Team Contact, most complicated for each group is handling horizontal reviews.
Ivan Herman: It's very difficult to know when to start a horizontal review, and how.
Ivan Herman: When you start, you get avalanche of questions which are not always relevant to the WG you're in
Ivan Herman: Each WG has different requirements. EPUB vs Verifiable Credentials, for example.
Ivan Herman: So faced with HUGE questionnaires, requires a lot of work to say whether relevant or not.
Ivan Herman: Tendency of requiring a lot of work up front is becoming worse and worse.
Ivan Herman: TAG asks more things than it used to, etc. keeps getting complicated.
Ivan Herman: I consider horizontal review to be essential, but this process needs review.
Ivan Herman: So far glad I didn't have to handle formal objections or IPR issues
Wendy Reid: I think we're an awkward group to ask, as Ivan has spared us from difficulties because he is able to answer the questions
Wendy Reid: Also lucky not to face FOs etc.
Wendy Reid: Most of the truly thorny things we've dealt with in the Process have been things related to publication, knowing that we're doing right steps at right times
Wendy Reid: Candidate Amendments for RECs etc.
Wendy Reid: The thing we were trying to do was very simple, just needed to make some corrections.
Wendy Reid: We spent weeks just figuring out exactly what we're supposed to do.
Wendy Reid: Once we did it, it was fine, but ... debating level 2 vs level 3 change, etc.
Wendy Reid: We debated a lot of it, and it took longer than it should have for some necessary corrections.
Wendy Reid: Clarify to spec.
Wendy Reid: Falling into process quicksand where a lot of pathways, hard to tell when criteria apply and when they don't, to what degree, etc.
Brent Zundel: Good feedback. Even knowing that ability to navigate helped by having a good Team Contact.
Elika Etemad: I've been on the other side of formal objections, one of the challenges is finding information on it, the council page is not the easiest to find or navigate
… we should have a website with the information, easy to find
… probably true of many things, where the process is not an issue but finding the necessary information is challenging
… for most cases people shouldn't need to read the process doc, there are some exceptions, the amendment process is complicated and needs to be made more easy to understand
… it's not supposed to be that complicated, even if it has complications to it
Brent Zundel: We found it easier to do an 1.1 vs an amendment
Elika Etemad: The amendment was more for corrections
Ivan Herman: Brent said what I wanted to say, the amendments process was difficult, and a tooling issue, so it was easier to go through the rec process
… it's difficult to markup the changes, it was challenging, in other cases tooling like ReSpec is helpful
Brent Zundel: Would also like to hear from editors.
Laurent Le Meur: The burden is to use ReSpec, but it's a good tool, so no real burden.
Elika Etemad: I'm in a Bikeshed group, and same, it's easy.
Ivan Herman: We have had, still have, problems with Invited Expert restrictions. We've had people whom we couldn't get ans an IE, or only with an enormous fight, because person happened to work for company which recently left W3C.
… that created a lot of problems for us, because that person was indispensable to the WG. Similar case now also.
… So issues around IE position, which is related to the whole Membership discussion at W3C that regularly comes up.
… It's a problem for WGs in general. Maybe Wgs lack enough people, and any obstacle that makes it difficult to get people who do the work is a problem.
… This WG is in the same position.
Elika Etemad: There are two reasons the restrictions exist, one is business reasons, the other is IPR, trying to solve this problem would require considering both
Brent Zundel: will have breakout on Wednesday to discuss this, and AB-led Member Meeting which everyone is welcome to join.
… We want to hear from you, so don't hesitate to reach out.
Image in Spine (cont.)
<Shinya Takami> https://
Elika Etemad: Did we conclude on the images-in-spine issue? Should there be a resolution?
Ivan Herman: Agree that having a resolution is what we need
… but I wonder whether we can make the formal references to fallbacks a bit more flexible than they are today, to make it easier to collect all the hypertext into one file instead of one per image for 200 images
… Might require adjusting how fallback is identified in the package document
… Maybe an additional entry which would allow referencing a fragment in the fallback file
… Because right now we don't have that
Hadrien Gardeur: So, saying you'd have a single HTML with all the text, and you'd have the fallback point to a fragmentID
Ivan Herman: Yes
Hadrien Gardeur: If we do that, that opens a lot of other questions
Brady Duga: That fundamentally changes fallbacks and the spine and how this works.
… Maybe a great change, but much bigger change.
… Fallback in the spine is meant to be, this is the content document you can use instead of this other document.
… You can just swap the files out
… But we don't have fragments of documents in the spine. In fact we have specific restriction on re-using a document in the spine.
… Avoids complications with navigation and paging etc.
… So this is a giant can of worms.
… If we do fallbacks, we should do fallbacks as we do now
Ivan Herman: Ok, but we have a problem.
… image in the spine with HTML fallback is technically true, but very impractical
Hadrien Gardeur: Yes, it is impractical
Wendy Reid: I would agree it was impractical if 1) it wasn't already how things happen and 2) if person who is making epub had to hand-write every HTML document
… but this is automated. It's not difficult to produce the files.
… The tooling is already there to do it, workflow is there to do it.
… If there was a size concern here (and the size here comes from the images, realistically speaking), maybe
… It does seem a bit silly to have 100 HTML files that aren't used, but in terms of effort it's not a big deal.
Hadrien Gardeur: My suggestion comes from pragmatic viewpoint which is what's out there
… I see 2 things
… Images in spine with HTML fallback, and HTML with image fallback.
… We should recognize these as valid ways to deal with this problem.
… not have it be word-of-mouth
… So we need to acknowledge what's out there.
… Secondly, one of those two should be how we recommend authoring content.
… "this is the way you should do it"
… Not necessarily in the spec, but that could cover other comic-related issues
… We can also recommend other things like metadata, semantics etc
… With that approach, we won't break anything, won't ask anything new, would just say "this is what is used, and this is what should be used"
Romain Deltour: If we knew how well fallbacks are supported in reading systems
… we do have some tests for manifest fallbacks
… but those are about one single document having a fallback
… but I wonder if someone has tested when all the documents have fallbacks, how does that work, how to transition from one document to another
… whether this is sufficiently tested to be a viable solution
Gregorio Pellegrino: I think the time is not right for thinking about solutions for comics etc. So opening the possibility to just images in spine maybe problematic. So suggest we continue as we have now, postponing the discussion, and we can open a task force thinking about a11y and comics
Gregorio Pellegrino: Maybe inside the a11y task force we already have
Gregorio Pellegrino: but I wouldn't take it up right now
Ivan Herman: I agree
Ivan Herman: Laurent Le Meur, is it possible for you to take a typical example which has fallbacks with HTML and has a relatively large number of images, and turn it into a test case for our test suite?
Laurent Le Meur: Yes
Ivan Herman: It would be a valuable addition to our test suite. Romain is right, we have a basic test, but we don't have a good stress test.
Ivan Herman: With that, I think repeating what Elika said, I think we should have a vote and have a resolution on what we put for advice for this type of documents
Laurent Le Meur: I totally agree, and disagree with Gregorio
Laurent Le Meur: We don't validate 3.4 today. So we have time to make a pre-recommendation, and ask reading systems to support what's in the spec
<Gregorio Pellegrino> +1 to Laurent Le Meur
Laurent Le Meur: We can easily make the evolution to support fallbacks if we know this is the right direction.
Laurent Le Meur: So let's make a pre-recommendation that is a resolution of this
Laurent Le Meur: And then when we make 3.4 we will be ready, and reading systems will be ready
ACTION: LaurentLM to add a images-with-fallbacks stress test to test suite
Wendy Reid: Something to consider is images with XHTML fallbacks, those happen to have alt text which is great, how do I signal to reading system that I want the fallback instead of the images?
… Most reading systems don't open the OPF file to see what's there.
… Maybe we now need to make fallbacks more obvious to users?
Laurent Le Meur: There's a simple way. If there is a version of a comic with some accessibility description, then the publisher should put it as the first choice. Image as a fallback.
Laurent Le Meur: Favorite of the publisher should be first.
Hadrien Gardeur: That doesn't work. Many have put HTML first and images as fallback because it works in more systems, e.g. Apple Books can't work with images in spine.
… So I don't think HTML in spine signals an intent from the producer
… It has more to do with the state of the industry than anything else
… There's no easy way to signal this preference.
… We have a problem in general with fallback. We use spine to convey information instead of using manifest.
… If we go in that direction, we're uncover a number of problems with how we do information in spine
Brady Duga: Would go a step farther and say, if you have an accessible HTML document, you've made an accessible comic, don't put an image in the spine
… Might not work in some crummy reader, they should update.
<Hadrien Gardeur> +1 for what brady just said
Brady Duga: You spent a lot of effort making that.
… So should only do this for comics that are otherwise inaccessible.
… If there is useful HTML accessibility info, put it in the spine, don't put images there.
… Similarly, for childrens books. Put the HTML in the spine. And that can be covered in the note.
Wendy Reid: So maybe better resolution is, we're keeping the spec as-is, but we are in agreement that comics deserves better guidance, so we want to write that guidance.
Hadrien Gardeur: And want to acknowledge what has been done for last 10 years, in millions of files.
Elika Etemad: Brady covered what I wanted to say, if we are writing best practices, if you do it clearly enough, but if its clear enough readers that use images can extract them, enabling that functionality
… while making the content more accessible for readers with better capabilities
PROPOSED: Write a best practices document for comics content as a separate working group note. No change to the specification for images in spine.
<Elika Etemad> +1
<Hadrien Gardeur> +1
<Brady Duga> +1
<Shinya Takami> +1
<Ivan Herman> +1
<Wendy Reid> +1
<Romain Deltour> +1
<Ivan Wong> +1
<Toshiaki Koike> +1
<Gregorio Pellegrino> +1
<Masakazu Kitahara> +1
<Laurent Le Meur> +1
RESOLUTION: Write a best practices document for comics content as a separate working group note. No change to the specification for images in spine.
Ivan Herman: Should I close the issue? discussion?
Hadrien Gardeur: Connected to this resolution is roll documents.
… I was blocked for this PR because unsure about direction
… But we need to decide more wrt roll documents
… We had some remaining complexity with how to describe them in the specification, that is resolved with this, we can have an example with image with HTML fallback
… We can get rid of many complexities.
Ivan Herman: I will mark the issue as needing to be closed, and chairs can figure it out
[discussion of what to discuss]
FXL Changes and Digital Comics
First page
<Romain Deltour> w3c/
Hadrien Gardeur: What we see in the market, you have 2 types of fixed layout
… One that indicates position for each resource
… and one that doesn't indicate for anything
… partial info is quite rare
… Authors typically assume that if no positions are given, the first will be on its own, and the rest is two by two
… It is an unwritten expectation that almost everyone creating FXL documents has, but we don't say anything in the spec
Elika Etemad: So you're proposing to specify that.
Hadrien Gardeur: Yes, let's add this concept into our spec
Wendy Reid: That would be in reading systems, not core?
Hadrien Gardeur: Core has quite a bit of language about that
Wendy Reid: But expectation would be in reading system
Hadrien Gardeur: We'd have to change language in core. Because currently implied that if you don't put any information, then it means spread is not relevant, which is not what market is expecting.
… some language in Core is confusing, so we have to change language there and also add more to reading system
Gregorio Pellegrino: Considering e.g. PDFs and ??, agree that the first page should be displayed as a single page if no other info.
… But are we allowing user to change it?
… Sometimes it's wrong e.g. for PDFs, there's an option for users to change the default.
Hadrien Gardeur: I think it's a good idea for reading system to decide to use spreads or not.
… depending on orientation of device, often switch whether spread or not. E.g. portrait mode have no spreads, landscape mode use spreads.
… possible user might want no spreads in either, some reading systems allow some don't
… different from having option for first page on its own
… I don't think we need an option for an offset, but good thing to have whether you want spreads or not, but is that something our spec covers?
Laurent Le Meur: no it's a reading system choice
Gregorio Pellegrino: I agree, maybe something to suggest somewhere. But two options. One is whether spreads preferred or not. Other option is whether ifrst page is cover or not.
Hadrien Gardeur: Linear no, wouldn't necessarily see it
Elika Etemad: Not familiar with this format, each resource would say if its on the left or right?
Hadrien Gardeur: Yes, the spec says if you say nothing, it doesn't matter, and if you say, there is a spread, both are not true
… what we see if people not declaring it, or always declaring it
PROPOSED: Adapt spec language in Core and Reading Systems to say that if no information about placement in spreads, the first resource should be a page on its own.
Hadrien Gardeur: We're talking about the spine override in this case.
<Elika Etemad> +1
<Brady Duga> +1
<Seth Delackner> +1
<Ivan Herman> +1
<Wendy Reid> +1
<Shinya Takami> +1
<John Roque> +1
<Ivan Wong> +1
<Laurent Le Meur> +1
<Hadrien Gardeur> +1
<Masakazu Kitahara> 0
<Romain Deltour> +1
<Toshiaki Koike> +1
<Gregorio Pellegrino> +1
RESOLUTION: Adapt spec language in Core and Reading Systems to say that if no information about placement in spreads, the first resource should be a page on its own.
Ivan Herman: Who will adapt the spec language?
ACTION: Hadrien to create PR to adapt the spec language for making first page on its own in spreads
Hadrien Gardeur: Also want to remove language that says that, if there is spread placement information, it means that there should be spreads
Hadrien Gardeur: [quotes spec]
Hadrien Gardeur: Says presence of page spread info means it's a "true spread"
Laurent Le Meur: Says it should not be should without a spread layout -- and this is false.
https://
Brady Duga: When I joined my last team, that is how they implemented their reader, and everyone hated it and they gots a lot of complaints.
… They were following the spec, and we had to tell them to ignore the spec.
<Hadrien Gardeur> https://
PROPOSED: Remove text saying that presence of spread information implies that the pages SHOULD be laid out as a spread, making either presentation equally acceptable.
PROPOSED: Remove text saying that presence of spread information implies that the pages SHOULD be laid out as a spread, making either presentation equally acceptable. See https://
<Elika Etemad> +1
<Brady Duga> +1
<Wendy Reid> +1
<Ivan Herman> +1
<Gregorio Pellegrino> 0
<Shinya Takami> +1
<Toshiaki Koike> +1
<Masakazu Kitahara> +1
<Romain Deltour> 0
RESOLUTION: Remove text saying that presence of spread information implies that the pages SHOULD be laid out as a spread, clarify that either presentation equally acceptable. https://
<Laurent Le Meur> 0 (ok for the direction, but the paragraph needs a bit more modifications)
Ivan Herman: Laurent Le Meur, for the PR that you will do, can you add a test for the test suite?
Wendy Reid: We can modify existing spread tests
Ivan Herman: Anyway think about the test suite.
Hadrien Gardeur: I'll ping you when I make the PR.
Orientation - w3c/epub-specs#2751
Hadrien Gardeur: Seems like a lot of people oppose this property, and not many support it.
Ivan Herman: So remove or deprecate?
Hadrien Gardeur: Probably deprecate
Ivan Herman: I have seen one book that used it, a French book on Egyptian temple which has photos and videos and probably handcrafted.
Gregorio Pellegrino: This is a WCAG violation, blocking re-orientation of the content.
… but also some authoring tools like Pub?? which use this value a lot because they tend to add their content at full-screen on the device
… and to have it full-screen on the device you have to block the orientation
Hadrien Gardeur: FXL you always contain both dimensions in the viewport. So if you want to use the full extent of the screen, force landscape, but only true for some screens and some documents
Brady Duga: and only if you have control over spreads, which we just decided you don't
Brady Duga: If the user decides they want to have two spreads in landscape, then all of a sudden you've lost the control.
Hadrien Gardeur: Still the spread property where you can say both.
… what we voted on is that if you put one resource on left one o right, it's not forcing spread. But you could use spread:both, or on a spine override, to do this
… Because you can still do both, you're not blocking anything else.
Hadrien Gardeur: I would be in favor of deprecating this and changing the reading system behavior, because this is actively harmful for a lot of people. Not just a11y.
Are we proposing: Deprecate rendition-orientation in Core, and also update Reading Systems to ignore it.
<Hadrien Gardeur> https://
PROPOSED: Deprecate rendition-orientation in Core, and also update Reading Systems to ignore it.
Brady Duga: Should we deprecate rendition-orientation or just the non-auto value?
Elika Etemad: If auto is the only non-deprecated value, then that's equivalent to deprecating the whole thing, so just deprecate the whole thing.
Brady Duga: Want to be clear what reading systems need to do.
Wendy Reid: We just say treat them all like auto.
PROPOSED: Deprecate rendition-orientation in Core, and also update Reading Systems to ignore it.
<Elika Etemad> +1
<Ivan Herman> +1
<Hadrien Gardeur> +1
<Wendy Reid> +1
<Shinya Takami> 0
<Toshiaki Koike> +1
<Gregorio Pellegrino> +1
<Laurent Le Meur> +1
<Romain Deltour> +1
<Masakazu Kitahara> +1
0
RESOLUTION: Deprecate rendition-orientation in Core, and also update Reading Systems to ignore it.
<Ivan Herman> Move to https://
Ivan Herman: Deprecation means that we have to move that property into the unsupported section.
… but yeah, let's leave it to Matt to figure out the editing.
Shinya Takami: How about epub-check?
Laurent Le Meur: epub-check checks the structure
Hadrien Gardeur: Shouldn't affect epub-check.
Elika Etemad: You can issue a warning.
Ivan Herman: Might need to raise an issue to the epub-check repo.
<Romain Deltour> +1 on creating an issue please
Hadrien Gardeur: Have to be careful about warnings, some people treat them as not warnings.
ACTION: Ivan to create issue against epub-check wrt removing rendition-orientation
Ivan Herman: Don't forget to update the changelog
Deprecating flow as metadata - w3c/epub-specs#2754
Hadrien Gardeur: I also opened similar issues wrt `flow` which is really under-used, and another about layout overrides and spreads.
… These are more contentious.
… Flow much less interest in it
… aside from Shinya Takami
… I'm not sure what you are using it for is a problem?
… But when we go back to this, flow would probably be my next target. Because I don't really understand why an author should say whether content is paginated or scrolled.
… Goes against principle of EPUB.
Wendy Reid: Wrt flow, was a way to declare scrolled comics in the before times. So when we add roll, we can say this thing does that better.
Hadrien Gardeur: Yeah, we should do those together. But I think it's harmful otherwise.
Shinya Takami: But for now we need to keep scrolled-continuous, because we use this feature for contents.
Hadrien Gardeur: So we would acknowledge its previous usage, and treat is as equivalent of 'layout: roll'
Shinya Takami: Ok, we're out of time, so let's wrap up.
closing
wendyreid reviews the agenda for tomorrow