Proposed changes to EPUB 3.3 and EPUB RS 3.3 to support Webtoons

[wareid]

As outlined in https://github.com/w3c/epub-specs/wiki/Webtoons-in-EPUB-3.3

Updated both the core 3.3 document and reading systems document to reflect what the change would look like if we adopted the proposed changes to formally support webtoons.

Tried to do the proper del/ins formatting for changes, so please let me know if there are any issues!

Preview Links for both:

• For EPUB 3.3:
  • Preview
  • Diff
• For EPUB 3.3 Reading Systems:
  • Preview
  • Diff

---

Preview | Diff

[mattgarrish]

This id should be "change_3". There are already two corrections annotated in the document, so the id conflict seems to be causing some really weird behaviour (I'm getting changes appearing in the annotation box).

[wareid]

Thanks for catching this!

[mattgarrish]

Well, I didn't get it quite right... :(

There were actually three existing corrections. One issue I had to add two corrections for as it affected two different areas of the spec. It needs to be change_4

[murata2makoto]

I have nothing against this proposed change. But for the record, please reference #2412.

[iherman]

I presume we all agree that this is a class-3 level change. If so, we should label it accordingly.

[iherman]

Most of my comments are on the EPUB 3.3 core.

• I wonder whether the order of the (new) sections is o.k. Now it says:

  • 8.2 Fixed Layouts
  • 8.3 Layout rendering control
  • 8.4 Reflowable Layouts
    wouldn't it be more logical to switch the order of 8.3 and 8.4? (Same comment for the RS)

• Is the sentence:

  Note that if this value is applied to an EPUB with a pre-paginated layout, it will render the same as if paginated was applied.

  meant to be an editorial note, or part of the definition? If the latter, then "it will" should probably say "it SHOULD". If the former, it should be marked up as such. (Same remark for the similar remark in §8.3.1).

• I believe it should be made clearer and very explicit how the different rendition:flow properties and the layout choice between pre-paginated or reflowable are combined. At least for me, it is not very clear in my mind. Maybe we have to duplicate the figures 6-9 to show how the values affect the final layout in the case FXL as well. In particular, showing an example of a webtoon-like rendering may be really important.

  (As a reminder, the sources of the figures are on google Doc. I am happy to create the new figures if I know exactly what I have to draw...)

• An additional remark to the previous point: the captions of figures 6-9 should make it clear that the figures are meant for reflowable documents.

• The introduction of §8.4 refers to "properties", but the section introduces now only one property. (I am not sure why this change did not appear on the github reviewing part, I would have made a proposed change right away…)

• In both documents there should be an item in the change log. There are already two changes in the Core spec; for the RS spec, this is the first significant change, so a new change section should also be added.

[iherman]

@wareid, you were a bit faster than I to create new example figures. I have also made new figures (inspired by yours). Mine might be a little bit better, because they rely on the same "image" of an FXL as the examples in §8.2.23, i.e., it is more consistent visually with those. "My" versions are on Google doc:

• example_rendering_FXL_paginated_multiple_spine
• example_rendering_FXL_scrolled_doc (identical to the previous, but in a separate file)
• example_rendering_FXL_scrolled_continuous

I am happy to make the necessary adjustment to add these to the document if you agree using those. (If so, do you prefer I do a separate PR on top of this branch, or should I edit this branch directly? The former is more "proper", but requires more admin steps...)

[wareid]

@iherman Yours are much better and feel free to just add them to this PR, since it's just swapping images, I am happy to write different alt text.

[iherman]

@wareid I have replaces the SVG files, have also modified the references from the index.html file to use the right dimensions, and also updated the image descriptions.

I have also modified the preview references in the PR description above to refer to this version.

[iherman]

Shouldn't we enclose the new diagram in an <ins> tag? Those diagrams are added in the PR, so they should be referred to as such...

[wareid]

Just a quick overview of the changes I have made following comments:

• added <ins> to the new diagrams
• changed "properties" to "property" in the reflowable sections
• updated changelogs with changes, but used a placeholder date as we don't have a date to use

Is it still preferred that we reorder the sections to:

• Fixed layouts
• Reflowable layouts
• Layout-independent controls

I can make this change today.

[HadrienGardeur]

I feel that the current PR only addresses one of the two main concerns that were initially discussed in #2412: the scope of rendition:flow (reflowable only in the current spec, extended to FXL in this PR).

rendition:flow remains a preference and not something that the RS or the user are forced to follow. That's perfectly fine for reflowable publications, but it would very much break the reading experience in the case of a Webtoon:

• a Webtoon episode with tall images would be almost unreadable if paginated, with a small strip of content displayed on each page
• while a Webtoon episode where content is broken down in many smaller images would provide an equally broken reading experience when paginated, making things difficult for the reader to understand what's going on

Few EPUB RS currently support the ability to scroll through an entire FXL publication and that's for good reasons as it's a real technical challenge.
We would end up with a very broken experience for readers using these RS.

Another area of concern would be Webtoon episodes vs seasons.

While Webtoon distribution is mostly handled behind closed doors to platforms using proprietary formats, if we want to distribute Webtoons in most of the current ebook/audiobook platform out there (I saw a recent announcement that PRH is going to distribute Webtoons across all of its sales channels worldwide), we'll definitely need the ability to distribute an entire season as a packaged format, and not just individual episodes.

In order to support full seasons in EPUB, we would also need the ability to indicate when a break should happen and images/resources are no longer part of the same "scroll".
This would be like mixing up scrolled-continuous and scrolled-doc, which the spec doesn't seem quite capable of handling either.

I'm a bit worried that we're rushing into this without seeing the full picture.

[bduga]

rendition:flow remains a preference and not something that the RS or the user are forced to follow. That's perfectly fine for reflowable publications, but it would very much break the reading experience in the case of a Webtoon:

• a Webtoon episode with tall images would be almost unreadable if paginated, with a small strip of content displayed on each page
• while a Webtoon episode where content is broken down in many smaller images would provide an equally broken reading experience when paginated, making things difficult for the reader to understand what's going on

I am not sure that is a huge problem. Some RSes won't support this content (many? most?), but changing how we signal it won't change that. It does mean that a user might be able to switch to a bad way of viewing the content (assuming the RS allows it), but so long as the RS defaults to flow-continuous that seems reasonable.

Another area of concern would be Webtoon episodes vs seasons.

This is trickier, but I haven't seen any content that bundles episodes like this into a single season epub. Is this a format we will need to support? Does anyone know if this PRH content mentioned above is using season epubs?

[shiestyle]

Few EPUB RS currently support the ability to scroll through an entire FXL publication and that's for good reasons as it's a real technical challenge. We would end up with a very broken experience for readers using these RS.

At least in Japan, such EPUB reading systems which support this behavior are increasing and maybe over 50% of market share of RS in Japan supports this behavior including Apple and Amazon.

This change will not force other RS to support this and we publishers will not provide contents ebook stores which are not ready for this behavior.

I want to discuss the appropriate style for EPUB based Manga contents including Webtoons (I plan to propose a breakout session at TPAC2024) but we want to improve the situation that already popular style for Webtoons in Japan violates the current EPUB spec for RS by this PR.

[HadrienGardeur]

I think it all boils down to what we're trying to achieve here:

• Are we working on Webtoons in EPUB as an interchange/delivery format?
• Or are we working on Webtoons in EPUB as an end-user format?

In Japan, EPUB is mostly used as an interchange format with multiple layers of extensions built on top of it. Many vendors end up distributing a JSON manifest to their Web reader or native apps, with straight up references to images (and dropping XHTML in the process). Some platforms even have their own packaged format with a bunch of custom XML or JSON documents.

If the intended goal is to provide an interchange format for Webtoons as EPUB, then why should we extend rendition:flow at all? It's a property meant to express a preference to a RS, not to deliver critical information in an interchange/delively flow.
This will be mostly sniffed out by vendors to trigger a special mode where images are extracted from the spine and rendered in a special Webtoon display mode.

The same result would be better achieved with a different approach in my opinion:

• a new metadata property could be introduced to identify that an EPUB is a Webtoon (no interference with existing metadata properties currently in use by RS)
• images could be directly referenced in the spine with a fallback on an XHTML equivalent (easier extraction of images for vendors who use their own format or RS with a specific mode, while we would still guarantee minimal support and accessibility using the XHTML fallback)
• and I'm not even sure that Webtoons in EPUB should be considered FXL, since FXL is mostly focused on pre-paginated content (each page being an XHTML or SVG resource) while Webtoons do not have pages by definition and use multiple resources to craft a single view

For Webtoons in EPUB as an end-user format, all these points remain true but we could also introduce the ability to indicate a break at a spine-level, to allow content creators to include several episodes or a whole season in an EPUB.

Would these proposals make things any worse for RS who do not support that Webtoon property? I don't think so. The worst case scenario would remain what I've described above but this time with:

• an easy way to detect these publications and display an error message if you don't support them
• a much easier way to support them, since creating a scrolled view with multiple images is infinitely easier than a scrolled view over multiple webviews
• and without introducing rendition:flow on FXL, something that no one really asked for outside of the Webtoon use-case

[bduga]

Non-technical comment - the term Webtoon is trademarked in multiple jurisdictions, so we should avoid using it generically. I have seen the term Webcomic used to sometimes refer to similarly formatted content, but it can also be used to generally mean comics on the web. We should probably decide on proper naming before we make these spec changes.

[HadrienGardeur]

Non-technical comment - the term Webtoon is trademarked in multiple jurisdictions, so we should avoid using it generically. I have seen the term Webcomic used to sometimes refer to similarly formatted content, but it can also be used to generally mean comics on the web. We should probably decide on proper naming before we make these spec changes.

Some people in France use the word "bande défilée" which is an elegant way of describing this type of publication.

Unfortunately, I don't think that someone came up with an English equivalent yet.

[HadrienGardeur]

To avoid hitting the same roadblock every month, we really need to continue this discussion in between calls.

Two takeaways for me from our last call:

• among participants quite few of us agreed that using the CG to incubate this project might be a better idea (@gregoriopellegrino and @avneeshsingh both said something along those lines) and that we would need a better representation of the Webtoon (I'm still using Webtoon for the lack of a better term) community, including from Korea, China and Europe (@bduga and @iherman) to work on a real specification
• we've had a lot of back and forth whether this proposed change should be considered purely in the context of Webtoons in EPUB or if it's actually useful for a larger number of publications and by the end of the last call, the consensus was that this is only relevant if we want to support Webtoons in EPUB

If we're only interested in Webtoons in EPUB, I think that an MVP should cover the two following principles:

• it should be very easy to extract a list of images from an OPF
• and we need a new property that identifies that this is a special type of publication where continuous scrolling is very much required

I know that there is always a pushback towards images in spine but:

• they're allowed as long as an XHTML/SVG fallback is also included
• for the interchange requirements which are at the core of the Japanese market, it's better to get a list of images from the OPF directly rather than having to crawl all XHTML/SVG documents to extract bitmaps
• while continuous scrolling on FXL can be difficult to implement and prone to performance issues, creating a continuous scrolling view with bitmaps using <canvas> (Web) or native platform API should be a lot easier and compatible with what dedicated manga/Webtoon viewers actually do

For the property that would trigger continuous scrolling:

• we need to indicate that this is very much needed to display such publications properly, it's not a simple hint
• this property should not impact the way current reflowable and FXL publications are presented

I remain hesitant towards adding that feature in EPUB though, since we can expect that in many reading apps this won't be supported and will result in a degraded reading experience with a small image strip in the middle of the screen.

An early proposal from Kadokawa also included a scrolled-direction property, which is something that @llemeurfr also mentioned in an email on February 2nd:

interpreting "rendition:scrolled-continuous" in the full-image field as an implicit vertical scroll is a short-sighted view. Webtoons are a huge market and B2B transfers must be addressed by our industry, but what about horizontal scroll?

Finally, knowing the height/width of each image would facilitate the ability to optimize the reading experience. Some dedicated formats include this information right away, which is optimal in a streaming environment where pre-fetching images can be costly.

[iherman]

A purely administrative reaction on the comment of @HadrienGardeur (with my W3C hat on): allowing image files in the spine would represent a “class 4” change on the specification. However, this WG is not chartered to do such change, and the EPUB specification, when published, disallowed such changes without going back to the classical WD->CR->PR->REC route. I.e., this could only be done by a (re)charter of the WG (or the creation of a new one).

[shiestyle]

@HadrienGardeur Thank you for your comments and I agree with your proposal to continue this discussion in between calls.

First of all, including this PR, we will not want to define the format for Webtoons.
And we will not try to unify Webtoons format into EPUB.

Under the current EPUB spec, EPUB based Webtoons files are legal (whether or not it would be appropriate for Webtoons) but behavior of some reading systems at least in Japan is illegal.
We want to improve this inconsistent situation and deregulation of using 'rendition:flow' for fixed layout by reading systems will solve this and it also makes EPUB specs consistent. If you don't accept the change indicates the format for Webtoons, we can delete 'Webtoons' words from this change. Does it make sense?

Historically speaking, when Apple started to use 'rendition:flow' for Webtoons, I pointed it as illegal but Japanese major eBook distributor and also Amazon followed this. Although we KADOKAWA proposed to use a special meta data 'scrolled-direction', Apple and Amazon's market share would give reasonable influence to follow by other publishers and service providers. We are talking about the standardized method of 'identification' for Webtoons in EPUB files, not about how to design Webtoons comics by EPUB format. So I want to separate the topics of the two.

It's too late to define a new 'identification' spec in Japan because it's difficult to change Apple and Amazon's mind for us and the Japanese Webtoons market is growing rapidly. So I think it's reasonable that we improve the inconsistent situation.
That's why I said that it's not a technical issue but a business issue at the call. Could you understand the background of this PR?

I also think the current EPUB files for Manga including Webtoons have some potential to improve (although images in spine have not been accepted for accessibility reasons but the current SVG tagged images used in Japan are not appropriate any more).
Anyway, thinking of such Manga format is out of scope for this WG and I will plan to hold a breakout session for this topic at this year's TPAC, so let's discuss there and I'm glad if you can show the situation in Europe.

[HadrienGardeur]

A purely administrative reaction on the comment of @HadrienGardeur (with my W3C hat on): allowing image files in the spine would represent a “class 4” change on the specification

@iherman I wasn't suggesting that we should allow images in spine, I was simply pointing out that it's already possible to do so as long as you also include a fallback to an XHTML/SVG resource. This would work fine for the Webtoon use case discussed here:

• reading applications and/or distributors capable of detecting the new Webtoon property would extract the list of images that way
• while everyone else would either display those images (if they're capable of doing so) or fallback to the XHTML resource

I've seen this used in the context of BD in Europe, where a number of publishers design their EPUB files that way to facilitate support in specialized reading apps for BD.

[HadrienGardeur]

For the property that would trigger continuous scrolling:

• we need to indicate that this is very much needed to display such publications properly, it's not a simple hint
• this property should not impact the way current reflowable and FXL publications are presented

If you consider the current proposal in light of these two requirements:

• rendition:flow is a hint in its current form: The rendition:flow property specifies the EPUB creator preference for how reading systems should handle content overflow.
• it impacts every FXL publication potentially
• and introduces values that are not needed in the context of Webtoon as EPUB: paginated (as opposed to the pre-paginated nature of FXL), scrolled-doc and auto

For a minimal support, a simple boolean value would actually work best and if we want to cover an extensive set of continuously scrolling comics as suggested by @llemeurfr we need the ability to express the forced scrolling direction: ttb, btt, rtl and ltr.

[llemeurfr]

Historically speaking, when Apple started to use 'rendition:flow' for Webtoons, I pointed it as illegal but Japanese major eBook distributor and also Amazon followed this.

Apple, Amazon and other made a choice that is not conform with the EPUB spec and causes issues described in previous comments; they didn't dare contacting the W3C WG dedicated to the maintenance of EPUB. This was a mistake on their part; they could have avoided this and because they are W3C members, they should have avoided this. We are the EPUB maintainers: it would be abnormal to make EPUB officially flawed just because they are big companies.

We are asked a way to integrate "scrolled visual narratives" (aka webtoons) in EPUB for B2B exchange (with no impact on existing reading systems if they open such EPUB). We can expect that when this WG has standardized a way to do that, distributors and specialized reading systems will update their practice. If they don't, it means that they are not interested in an open standard. And therefore we don't need to discuss this topic.

[shiestyle]

@llemeurfr EPUB specs have not provided a specific way for Webtoons, that's our fault.

The market doesn't want a kind of content specification for Webtoons because ordered images would be enough for Webtoons, but at least in Japan, we need a standardized approach for providing Webtoons by EPUB container.

I think that not only defining a spec nobody use yet but integrating widely used practices would be a part of 'maintenance'.

Anyway, whether or not Apple and Amazon are big companies, the current EPUB specs have some inconsistency on 'rendition:flow' in fact. We should fix it.

[llemeurfr]

EPUB specs have not provided a specific way for Webtoons, that's our fault.

@shiestyle, here I must disagree. EPUB is a "text-first" format. Everything has been designed to handle semi-structured text, enriched with other media like images or videos. We already know that the processing of comics, bande dessinée and manga is suboptimal in EPUB, but it is by design. The original IDPF members had no charter to design an "image-first" format. If it were the case, I'm sure that they would have created another format for that.

There are distributors and booksellers who want to use a unique format for both "test-first" and "image-first" ebooks, ok. We just need to do it right, not creating a work-around.

[HadrienGardeur]

Going back to the list of requirements that I identified in #2602 (comment), here are some additional thoughts on how we could add proper support for Webtoons in EPUB.

we need a new property that identifies that this is a special type of publication where continuous scrolling is very much required

The more I think about this, the more I'm convinced that this should be a new value for rendition:layout.

We currently have two values in the spec:

reflowable
The content is not pre-paginated (i.e., reading systems apply dynamic pagination when rendering). Default value.

pre-paginated
The content is pre-paginated (i.e., reading systems produce exactly one page per spine itemref when rendering).

Neither of these two values and definitions are a good fit for continuously scrolled comics (yeah, replacing "Webtoons" is hard):

• pre-paginated content implies that:
  1. each resource is a page
  2. and that each of these pages is fully contained/visible in the viewport
• Spreads and spread placement are an additional twist to their presentation, but things remain fully compatible with these two principles.
• While reflowable pretty much means: do whatever you prefer. In the end, it doesn't matter if the author provides hints for flow and orientation (they're barely supported anyway), the user will always decide what's best for them.

In this current PR, we're trying to twist rendition:layout="pre-paginated" and rendition:flow="scrolled-continuous" to do things that they were not designed for.

With a new value we could make things much clearer:

• each resource is a tile rather than a page
• by default, each tile is meant to fill the viewport width (on smaller screens at least) as opposed to pre-paginated where the viewport would contain it entirely
• the rest of the tile can be viewed by scrolling the viewport down vertically
• subsequent tiles are positioned below the first one, with no visible gap between them
• positioning tiles that have a different width would be an interesting discussion (should we center everything?) and might require to know the width of each image prior to drawing them

An early proposal from Kadokawa also included a scrolled-direction property, which is something that @llemeurfr also mentioned

This would become a new optional property. The direction would influence:

• how the viewport is filled (width vs height)
• how the subsequent tiles are placed (bottom, top, left or right)

we could also introduce the ability to indicate a break at a spine-level, to allow content creators to include several episodes or a whole season in an EPUB

This would also be another optional property. It would be applied to <itemref> either as a way to indicate a break after or before the current item (my preference goes for "before" but I don't mind too much).

<spine>
  <itemref idref="episode1-tile1"/>
  <itemref idref="episode1-tile2"/>
  <itemref idref="episode1-tile3"/>
  <itemref idref="episode2-tile1" properties="rendition:break-scroll-before"/>
  <itemref idref="episode2-tile2"/>
</spine>

This would allow a publication to contain multiple episodes or even multiple seasons together.

[shiestyle]

@HadrienGardeur If we add a new property, we need a new charter for the next version of EPUB.

It's out of scope for Publishing Maintenance WG now and here is not a good place to discuss it.
We should discuss whether or not to improve the inconsistency on 'rendition:flow'.

@iherman please correct if my recognition for the new charter is wrong.

[HadrienGardeur]

@shiestyle I believe that you're right in your interpretation of the current charter.

But IMO, rather than adopting a bad solution that we can sneak through the back door of the current charter, we should instead design a real solution for these publication types.

I decided to describe this alternate proposal a bit more to provide a contrast to the current hack being considered, but I'm fully aware that it would require an updated charter to go through.

Quite a few of us expressed their preference for using the Publishing CG to incubate this project, which would also allow experts in this field to participate directly to this effort without being full W3C members. I believe that this is the right path to follow.

[iherman]

@HadrienGardeur If we add a new property, we need a new charter for the next version of EPUB.

It's out of scope for Publishing Maintenance WG now and here is not a good place to discuss it. We should discuss whether or not to improve the inconsistency on 'rendition:flow'.

@iherman please correct if my recognition for the new charter is wrong.

No, you are right. Adding a new normative property is very clearly a new feature which we are not chartered to do.

We should, however, put this question aside and try to find a consensus on the best way to go. If we need a new charter that allows us to do such a change, then we can go through that. It may be as simple as removing that item from the 'out of scope' section, and replace it with some general statements that we would have to come up with providing some reasonable "fences" to make it clear that this is something the WG does not plan to do easily.

Let us find a good consensus first.

[HadrienGardeur]

We should discuss whether or not to improve the inconsistency on 'rendition:flow'.

I wanted to address this point separately.

I think that it's misleading to say that this PR is about improving the consistency of rendition:flow and/or allowing continuously scrolled FXL publications. The only reason why this PR exists is because there's an interest in distributing continuously scrolled comics as EPUB. No one has ever expressed an interest in extending rendition:flow otherwise.

We could talk about properties that would be good candidates for deprecation (I would put rendition:flow in that list), but we've shied away from this approach so far.

[larscwallin]

Hey everyone 🙂
We are working on features that are very much adjacent to this, namely spread-center and scrolled-continuous.