Inappropriate "rendition:flow" usage for vertical scrolling manga (Webtoon)

[shiestyle]

Apple Books provides a producing guideline for EPUB based vertical scrolling manga (Webtoon) which requires "rendition:flow" property in OPF file.
<meta property="rendition:flow">scrolled-continuous</meta>

But EPUB specs (ex: EPUB Reading Systems 3.3) says, "rendition:flow" property should not be used for fixed layout (pre-paginated).
Reading systems MUST ignore the rendition:flow property and its overrides when processing [pre-paginated spine items](https://www.w3.org/TR/epub-33/#def-layout-pre-paginated) [[epub-33](https://www.w3.org/TR/epub-rs-33/#bib-epub-33)].

Unfortunately, current EPUB spec, even 3.3, doesn't provide appropriate way to indicate Webtoon style and KADOKAWA and some Webtoon providers in Japan embeds custom meta data for Webtoon in our EPUB files. (ttb: Top to Bottom)
<meta name=“scroll-direction” content=“ttb”/>

Although I explained this situation, Amazon Kindle will also plan to require "rendition:flow" property for Webtoon in their guideline.

I don't want to give a big impact for EPUB 3.3 recommendation process and I don't want to add some new normative feature for Webtoon but I wish that we will get some reasonable solution for EPUB based Webtoon contents.

It's good for us to use common custom meta data for Webtoon like “scroll-direction” but "rendition:flow" in "pre-paginated" content will indicate Webtoon in EPUB spec officially, may be another option, I think.

[murata2makoto]

Do Apple and Amazon handle such vertically-scrollable comics as reflowable publications? If so, they are consistent.

What do Korean publishers do for vertically-scrollable comics?

[shiestyle]

@murata2makoto If they require Webtoon as reflowable, it's more critical problem :)

EPUB based Webtoon will be generated as fixed layout because comics are usually generated as fixed layout.
Some major Webtoon publishers don't use EPUB but many publishers in Japan generate EPUBs and we want to generate Webtoon contents as EPUB, too.

[iherman]

I don't want to give a big impact for EPUB 3.3 recommendation process and I don't want to add some new normative feature for Webtoon but I wish that we will get some reasonable solution for EPUB based Webtoon contents.

It's good for us to use common custom meta data for Webtoon like “scroll-direction” but "rendition:flow" in "pre-paginated" content will indicate Webtoon in EPUB spec officially, may be another option, I think.

(Just reaction on the process like issue here.) This change, if adopted by the WG, would "only" mean an additional normative feature to the specification (either by adopting the Apple approach or by introducing a tailor-made value to rendition:flow) and, as far as I can see, it would not affect the rest of the specification, the tests that have been already created, current implementation results, etc. It is an incremental change. Which means that it is still time to add this to the spec provided that, by the end of the year, we can:

• republish the CR as a new snapshot asap (if we know what goes in the spec that is an admin issue of 1-2 weeks)
• add new tests for the feature (this is easy)
• demonstrate implementation of the feature by at least two RS-s and, hopefully, by also having publishers intending to use this feature. While showing usage may be easy through the Japanese publishers' community, for example, having reading systems who would implement it by the end of the year may be a challenge.

I would think we should discuss this at the F2F and, for the discussion, we should put the process issues aside.

[mattgarrish]

The rendition:flow property has always been a bit of a mess. It was supposed to only be about overflow handling of reflowable content, but then got document transitions layered into it for scrolling, even though the transition part could be useful for fixed layouts as demonstrated here.

The original idea was that flow would only have the values paginated, scrolled, and auto. If we'd stuck with that, "ttb" could probably be specified as a value of page-progression-direction.

[murata2makoto]

@murata2makoto If they require Webtoon as reflowable, it's more critical problem :)
EPUB based Webtoon will be generated as fixed layout because comics are usually generated as fixed layout.

Will Amazon and Apple buy this argument and give up their current plan?

[iherman]

The issue was discussed in a meeting on 2022-09-13

List of resolutions:

• Resolution No. 1: Add a note to the specification identifying rendition:flow scrolled continuous as a possible option for webtoons in EPUB, it is being incubated and requesting feedback.

View the transcript

4. Inappropriate "rendition:flow" usage for vertical scrolling manga (Webtoon) (issue epub-specs#2412)

See github issue epub-specs#2412.

Wendy Reid: .

Wendy Reid: Webtoons.

Shinya Takami (高見真也): From last year or so, in Japan, webtoons gaining popularity.
… publishers creating webtoons for their content.
… current specifications lacking identifiers for their content. Apple has guidelines for producing EPUBs, and extended guidelines..
… includes a property to identify a webtoon. Reading systems must ignore the flow property if fixed layout. Webtoons consist of fixed layout..
… amazon will follow the stated behavior for producing guidelines..
… webtoon services have not used EPUBS. In Japan we have various formats, and want to use EPUB 3 format also..
… Want to discuss a reasonable solution for Webtoos for identification..
… One option is to use a custom property identification in OPF file. Meta-name property..
… legacy format for epub3, so not good style..
… another option current mistaken behavior by apple / amazon - could change epub3 spec to turn behavior optional..
… fixed-layout could be identified. want to discuss for reasonable solution..

Wendy Reid: two options:.
… add a new metadata property for webtoons specifically.
… or we remove the fixed-layout caveat on rendition:flow from the specification, and let that exist for any type of content..

Brady Duga: we could wait for after 3.3, because of where we at in the specification, but that leaves the meaning unknown..

Ivan Herman: First, put on my w3c hat - small change, does not affect existing tests, September we still have the time to make the change, provided we have additional tests and client support. (This is from an administrative point of view).
… however, concern over rushing into something. There is a question that would come up later towards the end of the working group: how do we imagine and plan for changes after the WG is finalized?.
… the current approach is that after this working group we create a maintenance WG. Has the right to add new features (need testing, etc), but does not mean we have to go through 2yrs work to add the feature..

David Hall: other working groups have followed this possibility. It's up to us to say how self disciplined we are. rendition can envisage doing it this way. we would have more experience and more thorough.
… have to be careful not to rush into stuff..

Wendy Reid: Also understand Brady's concern. It feels wrong, wish we had known about this earlier as a use case..
… the way we have looked at rendition:flow is under specified. we do know there are reading systems out there that have a reading mode of vertical scroll..
… The spec is fairly vague and may be in our favor in this instance. the reading system should present the content from one continuous flow from spine item to spine item..

Brady Duga: I don't know what this actually means.

Wendy Reid: I think that making this change - we're also removing an inconstancy - don't see why we don't need to have that..
… feels removing the don't do this is an ok change to make. Because we are still in the CR period, we will remove anything that is not implemented..
… it also addresses a need in the community that if we don't address it, community may do it a different way, and then we don't have a way.

Brady Duga: would rather have a non-standard spec in an epub for now. If we don't define a rendering model, define how it actually behaves, then it's not really a standard. Next year we sit down, and open up a client and we then try and copy the behavior..
… This was a mistake early on as following client reader implementation. What does it mean? Do I display it as they are? what if we have variable size pages? fit to width? etc..
… need a rendering model to be proposed, and we want to understand - what does this mean when applied to fixed layout, what are all the use cases. We would end up with a Wild West..

Shinya Takami (高見真也): The first I proposed is to add a custom meta-data. We should do one common metadata. Discuss with various companies to use the metadata commonly. it's not option. Another proposal is to add to the specification..
… Is description ok? This is an other option..

Wendy Reid: See Definition of rendition:flow.

Wendy Reid: we do have different rendition flow examples. maybe we should bring over to RS. We should provide some guidance as to what this looks like for fixed layout..
… This isn't a perfect description of how this renders. We have made decisions before to not be super descriptive. we can put a bit of effort into how this would render and look..
… don't think this is a huge change to make. If we add a custom metadata field, this won't make it into the specification either..

Dave Cramer: Want to offer some cautionary advice: Share's Brady's concern around rendering. We have faced challenges around fixed layout properties and what they mean. Don't want future groups to have the same issue. We want interoperability - be clear of our expectations around reading systems..

Gregorio Pellegrino: Try to understand - what if we say in the Japan market they can use the metadata to express as a webtoon. why in the standard do we not define at the moment. this is a way that is currently used in Japan..

Ivan Herman: This comes back to what I said - this is between reading systems and publishers, that for me is what incubation is all about. people may enumerate a few times to settle down, and in a year in combination with the WG, we can say there is an agreed upon behavior..
… we could add into the standard, and then from that point on, can expect reading systems to follow. need to let the incubation phase run it's course.
… we have a bunch of things in the EPUB standard which were put into the specification at some point with the hope it will be implemented by everyone, and may pay the price at the end because we don't have implementations..
… would be worried about the same kind of effect that would have..

Shinya Takami (高見真也): Apparently the first market that would generate to generate EPUB format webtoons, we need some kind of solution..

Wendy Reid: Hit a bit of an impasse. A third proposal:.
… document the incubation period - don't change the spec as it is currently written. however, can we add an editorial note to the rendition flow section regarding the use-case. we think it can be used for this purpose. If you want to fit this use case we recommend you do it this way..
… want to see how this gets implemented - provides a location for feedback, and can look at reasons for..
… Want to document because it seems to fit, but also agree we don't want to rush it..
… want to encourage people in a direction, and give guidance..

Ivan Herman: Incubation matters in the field with implementations..
… believe proposal is doable..

Brady Duga: feel we need more in the field implementations - is this an at-risk feature?.

Ivan Herman: This is a good point and a risk point..

Brady Duga: It might move, right?.

Wendy Reid: proposal statement:.
… "Proposed: Add a note to the specification identifying rendition:flow scrolled continuous as a possible option for webtoons in EPUB, it is being incubated and requesting feedback".

Ivan Herman: +1.

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

Brady Duga: +1.

Brady Duga: Fine, not sure if there is another way..

Toshiaki Koike: +1.

Murata Makoto: +1.

Gregorio Pellegrino: +1.

Symon Flaming: +1.

David Hall: +1.

Masakazu Kitahara: +1.

John Roque: +1.

Wendy Reid: +1.

Resolution #1: Add a note to the specification identifying rendition:flow scrolled continuous as a possible option for webtoons in EPUB, it is being incubated and requesting feedback.

David Hall: Being new to the group and working on the reading experience, we'd have a vested interest in implementing the right thing.
…what does that look like? Joining discussions? Providing feedback.

Ivan Herman: Goal is to find consensus amongst the participants.
… the proposal can be rejected still, but otherwise it must be acted on.
… longer term, a standard becomes a standard when it has more than 2 implementations.
… there will be ongoing discussions about the spec even after publication.

Brady Duga: That's a good question because we haven't done this for EPUB within the W3C.
… you'll go and incubate, you might discover you need more information, you would report back on your findings.
… do you need to bring it to the CG or WG?.

Ivan Herman: WG.

Brady Duga: There's more of a discussion.

Ivan Herman: We've added the directional features for title for instance.

[mattgarrish]

@iherman do you want to add this note? I probably have too many questions. (What guidance on producing webtoons should this point to, if any? Is feedback going to be to this issue or should there be a proposal issue documenting the feature more fully?)

[iherman]

I will try to come up with something...

[iherman]

see #2441

[shiestyle]

After discussion at TPAC2022, Japanese ebook industry use rendition:flow-scrolled-continuous for Webtoon style comics by EPUB format and there are no bad influence.

Recently I explained the current situation to Google Japan and recommended to use rendition:flow for Webtoons, too.

At TPAC2023, So we want to discuss again to change spec so that rendition:flow-scrolled-continuous with pre-paginated will be granted to use and will indicate Webtoon style comics as a class-3 change.

[HadrienGardeur]

Based on our experience implementing support for Webtoons, they tend to be implemented by reading systems in a very different way from EPUB FXL:

• in a Web reader, Webtoons are usually implemented using multiple image tiles in a canvas element (vs multiple iframe elements for EPUB FXL)
• in native apps, Webtoons are usually implemented using native API for manipulating bitmap images (vs multiple webviews or a single webview with multiple iframe elements for EPUB FXL)

To fully support Webtoon, we would therefore need:

• direct access to bitmap files rather than their HTML containers (useless in the context of canvas or native API)
• and I don't believe that the current rendition:flow-scrolled-continuous is a good fit to express how these publications should be presented either

[shiestyle]

@HadrienGardeur Thanks but it's not only the approach for Webtoons but for all of Manga contents, at least in Japan.
That is, many of reading systems in Japan will not render XHTML but images directly for Manga contents.

The current EPUB specs may not be the best format for Manga contents but it is used widely as a standerdized distribution format and it's a good way rahter than providing set of images with dedicated metadata for each service.

For accessibility reasons, we cannot provide direct access to bitmap images in EPUB without fallbacks.
We don't want to discuss what is the best format for Manga but how to improve EPUB spec for distribution of Webtoons contents and I'll show you that rendition:flow-scrolled-continuous is implemented by some reading systems for this use case at TPAC 2023's session.

[bduga]

I am not sure what the best way to specify this content is, I have seen multiple different approaches now and they all seem to have some issues. I agree with @HadrienGardeur that rendition:flow-scrolled-continuous is not a good fit, and in fact is a misuse of this metadata property. That field does not apply to a publication as a whole, it is simply a top level default setting and is therefore not useful when specifying how a book should be rendered in its entirety. I am looking forward to further discussions at TPAC.

[shiestyle]

@bduga rendition:flow-scrolled-continuous is specified as a metadata in OPF and I'm not sure the difference between a top level default and specifying in its entirety.

We understand it is a misuse but it has not been used for FXL and there is a potential to use without bad effect.

Let's discuss more at TPAC.

[HadrienGardeur]

We don't want to discuss what is the best format for Manga but how to improve EPUB spec for distribution of Webtoons contents and I'll show you that rendition:flow-scrolled-continuous is implemented by some reading systems for this use case at TPAC 2023's session.

This goes beyond what's the "best format".

With a manga, while using the XHTML resources and rendering them in iframes/webviews is sub-optimal, you still get the expected user experience with single or dual page spreads.

That's not the case here with Webtoons: if the images cannot be extracted from the OPF/XHTML and rendered with the expected layout (a single "scroll"), the experience will be broken and your content won't be readable.

[davemanhall]

I wonder if it would be useful to consider web-toons format separate from specifying how the reader should optimally present fixed layout content.
<meta property="rendition:layout">pre-paginated</meta> <meta property="rendition:flow">scrolled-continuous</meta>
You could imagine this in conjunction within rendition:spread-landscape to hint to the reader that the content is best suited in landscape orientation, 2-up, with vertical scrolling between spreads.

As I read the rendition:spread property it is for declaring to the reading system how to layout the content.

So what I see us trying to find is an appropriate way to specify the per document navigation mode for a fixed layout book (scrolling, or paginated). Perhaps adding a declaration of how rendition:flow should be treated in fixed layout documents (rather than modifying how it behaves for reflowable layout) may be a path forward?