Remove multiple renditions from EPUB 3.3

[dauwhe]

Should we stop pretending that multiple renditions are an actual part of EPUB as implemented in reading systems in 2020?

1. I'm aware of no implementations in widely-used reading systems.

2. The very concept adds confusion to the spec. We constantly use phrases like "Each Package represents one Rendition of an EPUB Publication."

3. I fear that multiple renditions support a "separate but equal" model of accessibility.

4. Multiple renditions add a massive amount of complexity to EPUB. Rendition selection as well as rendition mapping are not simple ideas.

5. Standard web practice has moved away from using different documents for different users (remember mobile versions of websites)? Semantic HTML and media queries can meet most use cases for customization.

6. Business support is minimal. Even if we like to theorize about bundling English, French, and Japanese versions of Moby-Dick in a single EPUB, that's generally not how content is created, distributed, and sold.

I would propose we remove mentions of multiple renditions from the core EPUB specs. This would not affect existing documents, because reading systems were only ever obligated to present the default rendition.

[wareid]

I think this issue calls for this: https://gph.is/2JcZDRt

(GIF alt: Scene from Highlander, "There can only be one!")

[GarthConboy]

+1 For all the (well stated) reasons mentioned by Dave.

[mattgarrish]

It's one of the last painful legacies to be done with.

We've tried to make this work by first disallowing anything but EPUBs in the OCF and then coming up with rendition selection. It was an interesting concept, but I agree there's no evidence it's going anywhere.

[TzviyaSiegman]

Big +1. Dave articulated the reasons really well.

[shiestyle]

+1 to Dave.

We should make it simple for the first W3C EPUB spec as possible as we can and let's improve after.

[dauwhe]

My concern is that I hear rumors that the forthcoming Euro Accessibility regulations say something about requiring "Multiple renditions" but I have no idea if they mean this particular feature. As I've said, I see this as an obstacle to accessibility in many ways.

[murata2makoto]

@dauwhe

Although I agree to drop this paperware, I would like to make comments on some of your reasons.

I fear that multiple renditions support a "separate but equal" model of accessibility.

I do not understand what is wrong. It is very often impossible to make a single content readable for everybody.

Standard web practice has moved away from using different documents for different users (remember mobile versions of websites)? Semantic HTML and media queries can meet most use cases for customization.

Although I strongly support the use of new technologies for making a single content accessible for many people, I do not believe that most use cases are met now.

[babatakao]

Our product "cho-textbook", an e-textbook reader, uses EPUB multiple-rendition feature: the first rendition is fixed-layout and the second one is reflowable.

I don't think the feature is need to be supported by all RS, but hope be maintained as an optional feature.

[murata2makoto]

Having heard that BPS uses multiple renditions in its product, I now think that we should not drop this feature from EPUB 3.3.

[avneeshsingh]

Alternate rendition is a requirement in European accessibility directive, pointer at 1.
There is a possibility to request EU for adding some clarifications to it, but it is too early to make the aggressive decision of dropping multiple renditions straight away.
We have just started work on finding gap areas with EU accessibility directive, and influencing EU for clarifications or dropping such a requirement would be a long process.
Further to it, I do not think that we can compare EPUB 3 publications with responsive design of websites. e.g. We have just touched the tip of iceberg for accessibility of fixed layouts. It is too aggressive to think at this point of time that one EPUB 3 publications can meet all the needs of visual appeal as well as accessibility.
In fact we had worked on a version of Readium 1 in past, in a project for UNICEF, that uses multiple renditions for addressing needs of different disabilities.

https://eur-lex.europa.eu/eli/dir/2019/882/oj?eliuri=eli:dir:2019:882:oj

(iv)
Allowing alternative renditions of the content and its interoperability with a variety of assistive technologies, in such a way that it is perceivable, understandable, operable and robust;

[iherman]

@avneeshsingh very interesting.

However, looking at the EU directive on E-books, there is no explicit reference the EPUB multiple rendition feature; the term is very generic. I could argue that the CSS media queries and similar features provide the technical approach to implement what the EU directive requires.

I have no opinion at this point whether we should keep multiple rendition or not. However, making a very explicit link between the EU directive and the EPUB Multiple rendition feature would affect the conformance criteria for RS-s at least when it comes to European market. Indeed, at this point, the RS document says, in §7.2.3:

A Reading System MUST consider the first rootfile element within the rootfiles element to represent the Default Rendition for the contained EPUB Publication. Reading Systems are REQUIRED to present the Default Rendition, but MAY present other Renditions in the container.

if such a strong linkage is made then the last MAY would become a MUST for the European market. Is that correct, or do I misinterpret the effects of the EU directives?

[avneeshsingh]

@iherman , EU directive provides functional requirements, so it will not have specific EPUB specific or PDF specific terms.
From a functionality point of view, the clarification that we need to have from EU is if alternate renditions has to be in the same package or is it possible to have renditions in different packages i.e. can alternate EPUB file be considered as alternate renditions.

The threat here is that if EPUB 3 and EPUB Accessibility fail to meet these functional requirements, then it will come in the way of EPUB accessibility becoming a technical specification under European accessibility act. This is why I am not willing to drop this feature until we have the clarifications from EU experts.

[mickael-menu]

Wouldn't it make more sense to address the accessibility needs by having alternates at the resource level, instead of the whole rendition? This would require a way to specify alternate resource for manifest items, similar to how the Readium Web Publication is handling it in Link.alternate:

https://github.com/readium/webpub-manifest/blob/691cd00a4ab438dbb32671da8e215f19f8d8cb32/schema/link.schema.json#L73-L78

Unless the rendition would need to change in a way that produce very different spines.

[mattgarrish]

Maybe I've misunderstood, but the proposal was only to remove mention of multiple renditions, not forbid them (it's too late and technically problematic to do that). I think that's a good thing as far as getting to recommendation

I think we can simplify the specification without outright banning more than one rendition of the content. We still need to account for the fact that you can list more than one rendition in the rootfiles, after all.

I'd leave the restriction to EPUB 3s in place and merge most of the publication and "rendition" requirements so we only talk about an epub publication as a single work. We can then add a note that although it's possible to reference more than one package document, at this time there isn't broad support for a method.

If we need to talk about "renditions", we can leave that for the multiple renditions specification to detail that there is a default and possible alternatives.

[mattgarrish]

I do not understand what is wrong. It is very often impossible to make a single content readable for everybody.

It's not a strong argument against them, true, as conforming alternate versions are an accepted part of WCAG. A serialization may be the only truly accessible version of some graphic works.

The problem is the lack of support. You can't claim a conforming alternate version if there is no, or virtually no, real-world support for accessing it. As things currently stand, you have to bundle the versions separately. I believe we mention this problem in the techniques.

[GeorgeKerscher]

Having heard that BPS uses multiple renditions in its product, I now think that we should not drop this feature from EPUB 3.3.

Did we hear if there is any content that uses this technique? I mean there may be a reading system out there, but is there the content?

[babatakao]

Having heard that BPS uses multiple renditions in its product, I now think that we should not drop this feature from EPUB 3.3.
Did we hear if there is any content that uses this technique? I mean there may be a reading system out there, but is there the content?

Yes, two publishers in Japan have released digital textbooks optimized for our (BPS) cho-textbook viewer, and the textbooks are used by thousands of elementary schools. Most of them uses multiple-rendition feature. For example: https://digi-keirin.com/dtext/jsugaku.html

In the early 2021, one more publisher also planning to release digital textbooks with the feature.

Right now these digital-textbooks are published dedicated for cho-textbook viewer in fact (so you cannot get raw EPUB file). However, since the contents are valid EPUB, the publishers might publish them for other RS to handle accessibility needs.

[HadrienGardeur]

Wouldn't it make more sense to address the accessibility needs by having alternates at the resource level, instead of the whole rendition? This would require a way to specify alternate resource for manifest items, similar to how the Readium Web Publication is handling it in Link.alternate:

https://github.com/readium/webpub-manifest/blob/691cd00a4ab438dbb32671da8e215f19f8d8cb32/schema/link.schema.json#L73-L78

Unless the rendition would need to change in a way that produce very different spines.

I also feel that the approach taken in EPUB (where we take multiple publications and put them in the same package) is the wrong one. It introduces a lot of complexity, for example how do we handle metadata? Should we combine the metadata of multiple OPF files?

Using alternate resources is IMO more aligned with the Web, where one can for instance indicate that the same resource is available in another language.
I agree that in general, we should attempt to create resources that are universally accessible, but when that's not possible an alternate resource would work better than a different publication/rendition.

[murata2makoto]

@mickael-menu @HadrienGardeur

I disagree. Consider two resources A and B as well as their alternatives A' and B'. How do you specify the combination of A and B' is not acceptable?

Multiple renditions are used by BPS and others. Our charter prohibits deletion of used features from EPUB 3.

[iherman]

Multiple renditions are used by BPS and others. Our charter prohibits deletion of used features from EPUB 3.

My interpretation of the discussion and a possible way forward:

1. simplify the specification by talking about a single rendition (and not even use that world) although allowing, technically, to have several renditions defined within the EPUB document
2. produce a separate WG Note that gives more details about what multiple rendition means and how it can be implemented.

Ie, if we do that, I think we are fine as far as the charter goes.

[HadrienGardeur]

Multiple renditions are used by BPS and others. Our charter prohibits deletion of used features from EPUB 3.

We need to be flexible about this IMO. In the past, we've been in a similar situation where a given feature is only in use in a few publications (for example internal CFIs).
We absolutely need to be able to deprecate such features, we can't be forced to support something because it's used in one or two publications.

In the current situation, I completely agree with @iherman. This would make multiple renditions out of scope of the core publication, yet they would remain allowed thanks to a separate note.

[murata2makoto]

@HadrienGardeur

We need to be flexible about this IMO.

This is what we did about EPUB 3.1, which is a miserable failure.

@iherman

I do not want to change anything because I am worried about potential side-effects, which destroy existing EPUB publications or reading systems. EPUB 3.3 already looks away different from EPUB 3.2. I think that we are doing a risky business.

[iherman]

I do not want to change anything because I am worried about potential side-effects, which destroy existing EPUB publications or reading systems. EPUB 3.3 already looks away different from EPUB 3.2. I think that we are doing a risky business.

I understand the worry, and I agree that we have to proceed with care. However, what I describe in #1436 (comment) (and indeed the original 'experiment' of @mattgarrish) is purely editorial. It should not affect any deployed document or reading system.

"Purely editorial" may sound like not important. I think it is. I find the version proposed in this PR way more readable because it puts aside (ie, into a separate document) an obscure formulation using the term rendition, which is, though indeed used out there, is ignored by a vast majority of users (content providers, RS developers, etc).

[murata2makoto]

@iherman

"Purely editorial" may sound like not important. I think it is.

I agree that it might introduce significant advantages. But I continue to think that it is risky.

I already pointed out that one sentence in the proposed rewrite is not totally correct. @mattgarrish appears to think that it is OK, since a separate spec (Note for Multiple Renditions) can address the incorrectness. Pretending multiple renditions do not exist in EPUB 3.2 is not a good idea, IMHO.

[avneeshsingh]

The resource level alternate content will not address the accessibility needs. It looks that we are thinking only from perspective of some disabilities like blindness, where you provide reflowable resource as an alternative of fixed layout content.
We also need to consider requirements of other disabilities. For example if we want to provide an simplified language alternate for people with cognitive disabilities, then we will make the resources/XHTML pages shorter so that there is limited content on each page. Or if we are providing content with embedded sign language video for the text, for a hearing impaired, then also we prefer to keep limited content on each XHTML page. Therefore the spine of alternate content will not match the primary spine.
We should not make a quick decision for multiple rendition, I also think that this revision of EPUB is not for making big changes. I am happy with Matt's suggestion to place multiple rendition in a note, and we can revisit it in next EPUB revision.

[iherman]

The issue was discussed in a meeting on 2020-12-04)

• no resolutions were taken

View the transcript

2. Removing multiple rendition from core spec

See github issue #1436.

See github pull request #1438.

Wendy Reid: multiple rendition is not widely implemented, and people have mentioned that references to it complicate understanding of the core spec
… we can remove references to it from the core spec, and have it live as a satellite document outside the spec

Dave Cramer: I think of multiple rendition as an extension of epub only. The way we've had to write the spec because of this remote possibility has degraded the readability of the spec
… and multiple renditions have always been optional
… therefore multiple renditions should be epub adjacent, but not a core aspect

Ivan Herman: Referring everyone to the discussion in the PR
… some Japanese RS and content does use it
… Matt's PR: Took the core spec and removed references to multiple rendition from the text. Not removing the technical possibility of having multiple renditions.
… it may not have been clear from the PR that the intention was to have guidance about multiple renditions exist in a separate document
… we are not removing anything that was previously possible under the spec, just editing the spec to make it more readable

Garth Conboy: i support getting language about multiple renditions out of the core spec, while still allowing the possibility of multiple renditions

Gregorio Pellegrino: from an a11y point of view and a EU a11y act point of view, multiple renditions could be a way to meet requirements. Therefore multiple renditions make take on a greater importance in future.

George Kerscher: I do a11y test for RS and I can see testing multiple renditions being a nightmare
… could we somehow indicate to ebook buyers that an alternative reflow version of a given fxl ebook is available, and meet the EU a11y requirement that way?

Dave Cramer: we don't want to deprecate anything
… also what is in the core spec about multiple rendition right now, alone, is not sufficient to implement multiple renditions
… because the spec is silent on rendition selection
… moving all the language about multiple rendition into a satellite wouldn't negatively impact compatibility with EU a11y
… having a satellite spec might even draw more attention multiple renditions (people who are interested in using it can just go to that separate document)

Avneesh Singh: I've definitely seen multiple rendition in action. e.g. with Readium
… re. the EU a11y act, the act doesn't require guidance about multiple renditions to be in any specific document
… we would be okay even if the EU mandates multiple renditions

Hadrien Gardeur: although multiple renditions have been supported by Readium for a long time, we haven't actively worked on it for a long time. Its more a proof of concept
… since it seems like the only thing we have at our disposal to address the EU directive is multiple renditions, we've been focusing on it. But it might not be the only way. Maybe there is another way to address the requirements of the EU directive
… maybe there could be a less involved, more streamlined way to meet the EU directive requirements

Tzviya Siegman: +1 to looking for better solution than MR for EUAA

Wendy Reid: +1

Dave Cramer: See reference of a standalone IDPF document

Zheng Xu (徐征): as long as we don't have a new OPF or anything that require us to implement a new parser, RS implementers should be satisfied
… nor would publishers want to implement new packages that may or may not be backwards compatible

Garth Conboy: for right now we can go with Matt's PR, and 6 months form now, if the EU directive requires us to bring it back in, then we can consider that step

Ivan Herman: I propose not to come to any resolution at this point. We should wait until next week where the Japanese contingent will be in attendance, esp. as a lot of the comments on the issue were regarding Japanese RS, content

Avneesh Singh: +1 to Ivan, we need to listen to Japanese community

Garth Conboy: maybe we can come to an interim resolution now, and then revisit it next week with our Japanese members

Avneesh Singh: agree that we can still alter course after we receive more clarification about how the EU directive impacts us
… in June 2021

Proposed resolution: Close issue #1436 and merge PR #1438 to remove mentions of multiple renditions in the core specification (Wendy Reid)

Tzviya Siegman: Tzviya: One of the goals of this group is to make FXL accessible, in which case we won't need Multiple Renditions for a11y

Garth Conboy: +1

Tzviya Siegman: +1

Zheng Xu (徐征): +1

Matthew Chan: +1

George Kerscher: +1

Charles LaPierre: +1

Brady Duga: +1

Wendy Reid: +1

Ivan Herman: +1

Avneesh Singh: +1 in principles, but better to do editorial improvements

Juliette McShane: +1

Hadrien Gardeur: +1

Wendy Reid: we're just collecting votes in the record this week
… we're not resolving this week. We'll wait for additional discussion next week with our Japanese members.

---

[iherman]

The issue was discussed in a meeting on 2020-12-11)

List of resolutions:

• Resolution No. 1: Remove mentions of multiple renditions from the core and reading systems documents, close issue Remove multiple renditions from EPUB 3.3 #1436 and merge PR Rewrite renditions to publications #1438.
• Resolution No. 2: Publish Multiple Renditions as a Working Group Note.
• Resolution No. 3: Publish Overview as a Working Group Note.

View the transcript

Content:

• TOC

---

Matthew Chan: Topic 1: Multiple Renditions.

See github issue #1436.

See github pull request #1438.

Wendy Reid: this is continuing the discussion from last week.
… the suggestion is to remove references to multiple renditions from the main document of the spec.

Dave Cramer: the possibility of multiple renditions has always been in epub.
… but has not achieve a lot of uptake.
… i'm not aware of any major RS that supports it.
… with those references in the spec, the precision of the language required becomes cumbersome.
… it also gives casual readers of the spec the impression that multiple renditions is more prevalent than it is.
… Matt G's idea is to have those references to multiple rendition moved from where they currently are (scattered throughout the spec) into a satellite document.
… Matt G has already started this process of editorializing the spec.
… the satellite would be a WG note, and not a Rec track document.

Garth Conboy: there is at least one RS that supports it, so it makes sense to still keep multiple rendition functionality in the spec.
… that's why I am in favor of Matt G's direction.

Shinya Takami (高見真也): multiple renditions are currently used in Japan, mostly for educational purposes.
… but I agree with moving the multiple rendition specific portion of the spec to a separate document as long as this means that multiple renditions are not deprecated.

Dave Cramer: Readium also had some support for multiple renditions.
… at the time Microsoft was working on epub support in Edge.
… as part of that process, they found some oddball things in the spec that they found confusing.
… if another browser were to ask for advice on supporting epub today, I would recommend that they not support multiple renditions.

Marisa DeMeglio: wish we could go back to 2008 and reverse the decision to support multiple renditions.
… support is kind of mess right now.

Brady Duga: the first thing that we tell you about epub in the spec is something about multiple renditions, I can see how that is confusing.

Garth Conboy: +1.

Proposed resolution: Remove mentions of multiple renditions from the core and reading systems documents, close issue #1436 and merge PR #1438. (Wendy Reid)

Shinya Takami (高見真也): +1.

Marisa DeMeglio: +2.

Toshiaki Koike: +1.

Garth Conboy: +1.

Brady Duga: +1.

Masakazu Kitahara: +1.

Resolution #1: Remove mentions of multiple renditions from the core and reading systems documents, close issue #1436 and merge PR #1438.

Wendy Reid: to keep all the documents together, Ivan has proposed that we publish the multiple renditions piece as a note.

Dave Cramer: here is a link to the old IDPF version.

Dave Cramer: See Old IDPF Version of the multiple rendition spec.

Proposed resolution: Publish Multiple Renditions as a Working Group Note. (Wendy Reid)

Garth Conboy: +1.

Matthew Chan: +1.

Wendy Reid: +1.

Marisa DeMeglio: +1.

Brady Duga: +1.

Ben Schroeter: +1.

Shinya Takami (高見真也): +1.

Masakazu Kitahara: +1.

Resolution #2: Publish Multiple Renditions as a Working Group Note.

Wendy Reid: one of the other documents we have to publish is the overview note that ties everything together.

Wendy Reid: See Draft Overview.

Proposed resolution: Publish Overview as a Working Group Note. (Wendy Reid)

Wendy Reid: +1.

Brady Duga: +1.

Toshiaki Koike: +1.

Shinya Takami (高見真也): +1.

Wendy Reid: this is the overview document that is the introduction to the spec.

Masakazu Kitahara: +1.

Matthew Chan: +1.

Garth Conboy: +1.

Resolution #3: Publish Overview as a Working Group Note.