Proposed changes to EPUB 3.3 and EPUB RS 3.3 to support Webtoons #2602
Conversation
epub33/core/index.html
Outdated
|
|
||
| <p>The <code>rendition:flow</code> property specifies the [=EPUB creator=] preference for how | ||
| [=reading systems=] should handle content overflow. </p> | ||
| <div class="proposed correction" id="change_2"> |
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
Thanks for catching this!
There was a problem hiding this comment.
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
|
I have nothing against this proposed change. But for the record, please reference #2412. |
|
I presume we all agree that this is a class-3 level change. If so, we should label it accordingly. |
|
Most of my comments are on the EPUB 3.3 core.
|
|
@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:
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...) |
|
@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. |
* main: Create readme.md for the image directory (#2603) adding principles section addressing Matt's feedback adding success criteria to sections
|
@wareid I have replaces the SVG files, have also modified the references from the I have also modified the preview references in the PR description above to refer to this version. |
|
Shouldn't we enclose the new diagram in an |
|
Just a quick overview of the changes I have made following comments:
Is it still preferred that we reorder the sections to:
I can make this change today. |
|
I feel that the current PR only addresses one of the two main concerns that were initially discussed in #2412: the scope of
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. 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". I'm a bit worried that we're rushing into this without seeing the full picture. |
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.
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? |
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. |
|
I think it all boils down to what we're trying to achieve here:
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 The same result would be better achieved with a different approach in my opinion:
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:
|
|
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. |
|
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:
If we're only interested in Webtoons in EPUB, I think that an MVP should cover the two following principles:
I know that there is always a pushback towards images in spine but:
For the property that would trigger continuous scrolling:
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
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. |
|
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). |
|
@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. 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. 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. 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). |
@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:
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. |
If you consider the current proposal in light of these two requirements:
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: |
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. |
|
@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. |
@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 "text-first" and "image-first" ebooks, ok. We just need to do it right, not creating a work-around. |
|
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.
The more I think about this, the more I'm convinced that this should be a new value for We currently have two values in the spec:
Neither of these two values and definitions are a good fit for continuously scrolled comics (yeah, replacing "Webtoons" is hard):
In this current PR, we're trying to twist With a new value we could make things much clearer:
This would become a new optional property. The direction would influence:
This would also be another optional property. It would be applied to <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. |
|
@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. @iherman please correct if my recognition for the new charter is wrong. |
|
@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. |
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. |
I wanted to address this point separately. I think that it's misleading to say that this PR is about improving the consistency of We could talk about properties that would be good candidates for deprecation (I would put |
|
Hey everyone 🙂 |
|
As a follow-up to this discussion, I've written a short proposal: https://gist.github.com/HadrienGardeur/273a9d195f4a938880aa0bf8d2fc5dd9 Happy to discuss it here or in a future call. |
|
Sorry, I kind of dropped the ball on this discussion. I think there are
some reasonable concerns about this change being allowed by the current
charter, since it will change the rendering behavior of fixed layout
content (fit-all becomes fit-width).I won't be able to review the specific
proposal before I leave town, so it will be July at the earliest. But
broader than that is how we make substantive changes to EPUB - the current
model seems untenable. I would suggest we take a proposal (Hadrien's or
some variant) to the CG and publish a note there. We need to make it as
backwards compatible as possible, so EPUBs would still be valid and then we
can point implementers at that. Then we can take some time and figure out
how to either add features without rechartering, or consider a recharter.
…On Thu, Jun 6, 2024 at 4:43 PM Hadrien Gardeur ***@***.***> wrote:
As a follow-up to this discussion, I've written a short proposal:
https://gist.github.com/HadrienGardeur/273a9d195f4a938880aa0bf8d2fc5dd9
Happy to discuss it here or in a future call.
—
Reply to this email directly, view it on GitHub
<#2602 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA246ZHOKS5GTSIV2EJDFJTZGDXZXAVCNFSM6AAAAABBNKWEVOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNJTGU3TMNRQGA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
That's the approach that I've followed with my proposal. Worst case scenario, if reading systems do not support the new properties that I'm proposing, they'll most likely handle these files like a reflowable EPUB. Ideally, this would have to be tested across a range of reading systems, but at least we're not changing anything about the behaviour of reflowable/FXL publications. |
|
Additional note to this discussion - I think if we accept rendtion:flow scrolled-continuous for webtoons content then we will also need to add rendering instructions for such content. Currently we essentially strongly suggest (SHOULD) fit-all for fixed layout, but this content would want to be displayed as fit-width. That is, instead of fitting as much of the content as possible in the viewport, Reading Systems SHOULD fit the width of the content to the width of the viewport. |
This is something that I mention in the introduction of my proposal, but I fully agree that we'll need additional rendering instructions:
If we look af
|
|
Just a pointer that this was discussed during TPAC. Meeting notes: https://www.w3.org/2024/09/23-pmwg-minutes.html#t02 |
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:
Preview | Diff