Skip to content

Instantly share code, notes, and snippets.

@HadrienGardeur
Last active June 20, 2024 08:07
Show Gist options
  • Save HadrienGardeur/273a9d195f4a938880aa0bf8d2fc5dd9 to your computer and use it in GitHub Desktop.
Save HadrienGardeur/273a9d195f4a938880aa0bf8d2fc5dd9 to your computer and use it in GitHub Desktop.
Continuously scrolled comics in EPUB

Continuously scrolled comics in EPUB

  • Last update: June 20, 2024
  • Author: Hadrien Gardeur

Continuously scrolled comics are often referred to as "Webtoons", due to the popularity of the Webtoon platform owned by Naver in South Korea. Since this is a trademarked term, we'll refer to these publications as "continuously scrolled comics" throughout this document instead.

1. Introduction

  • Continuously scrolled comics are distributed using a format that's similar to TV shows, where the story is broken down into seasons and episodes.
  • Each episode is presented as a single scroll, broken down into "tiles" where each tile is a bitmap image.
  • They're primarily read on smartphones, where reading applications display these tiles by filling the entire width of the viewport and lay them without any visible gap between them.
  • On larger devices, these tiles may be centered in the viewport using a maximum width instead of filling the viewport.
  • Most of them are read by continuously scrolling from the top to the bottom, which means that subsequent tiles are displayed below the current one.
  • That said, there are a number of comics that are also read using scrolling in another direction: left to right, right to left or bottom to top. This scrolling direction can affect how reading applications fill the viewport and lay subsequent tiles.
  • There's usually a discontinuity in the reading experience when navigating between episodes, which is important to convey in a packaged format which could contain multiple episodes or even entire seasons.

2. Proposal

2.1. A new value for rendition:layout

The EPUB specification defines rendition:layout as a mean of indicating whether a publications is reflowable or pre-paginated using two different values:

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).

With reflowable publications, the text and layout is entirely controlled by the end user.

While the specification allows EPUB creators to express their preference for pagination or scrolling using rendition:flow, this is poorly supported in reading systems and feels at odds with the freedom offered by reflowable publications.

With pre-paginated publications, users have less control on the overall reading experience. Each "page" is displayed by fitting both dimensions in the viewport, in some cases side by side with another page (this is called a "spread").

Pre-paginated publications are usually displayed strictly using pagination, although a few reading systems also offer the ability to scroll pages or spreads.

With this document, I would like to propose the addition of a third value for rendition:layout:

scrolled
The content is presented using a single continuous scroll, without any visible gap between between spine items.

The presence of this property will trigger the behaviour described in the introduction of this document:

  • Each spine items fills the entire width or height of the viewport, based on the scrolling direction of the publication.
  • Overflowing content is scrollable on a single axis.
  • Subsequent resources in the spine are laid out without any visible gap between them.

2.2. Scroll direction

This proposal also introduces a new property to offer additional control over the scroll direction of the entire publication: rendition:scroll-direction.

This cannot be overriden at a spine level, to avoid inconsistencies in the overall user experience.

EPUB creators must use one of the following values with the rendition:scroll-direction property:

btt
Bottom to top scrolling direction.
ltr
Left to right scrolling direction.
rtl
Right to left scrolling direction.
ttb
Top to bottom scrolling direction. Default value.

Example 1: A scrolled publication read from left to right

<meta property="rendition:layout">scrolled</meta>
<meta property="rendition:scroll-direction">ltr</meta>

When a reading system renders a scrolled publication, the scroll direction defines where subsequent spine items are placed:

  • below the current spine item by default or for ttb
  • above the current spine item for btt
  • on the right of the current spine item for ltr
  • or on the left of the current spine item for rtl

This can also affect how the viewport is filled. On smaller devices, the reading system will:

  • fill the entire width of the viewport by default or for btt and ttb
  • or fill the entire height of the viewport for ltr and rtl

2.3. Bitmaps in spine

Images in spine have been a contentious point of discussion in the past. They're technically allowed by the specification through the use of SVG in the spine, but bitmaps cannot be referenced without a fallback or an XHTML/SVG container.

There's usually a heavy dose of hypocrisy whenever this topic is raised, always circling back to the idea that the XHTML/SVG container is necessary in order to ensure their accessibility.

In practice, this means that there are millions of EPUB publications where the primary resources are bitmaps referenced from an XHTML. Sometimes, things get even more convoluted with an XHTML document that contains an <svg> element which only references a bitmap.

Despite the use of XHTML, none of these publications are accessible. Even if their creators wanted to make these publications accessible, there are currently no documented means of doing so.

I will address this requirement in a separate proposal, but in the meantime, I feel that we need to move beyond this hypocrisy.

The EPUB specification allows EPUB creators to use bitmaps in spine as long as they provide a fallback to an XHTML or SVG document.

Example 2: Bitmap with a fallback

<manifest>
  <item id="tile1" 
        href="1.jpeg" 
        media-type="image/jpeg" 
        fallback="unsupported-feature"/>
  <item id="unsupported-feature" 
        href="unsupported-feature.html" 
        media-type="text/html"/>
</manifest>

This proposal recommends using this fallback mechanism for the time being, in the hope that a future Working Group will revisit that decision and finally allow bitmaps in spine.

2.4. Spine overrides

In order to override the default behaviour of displaying spine items in a single continuous scroll, this proposal also introduces a new property that EPUB creators may use locally on spine itemref elements:

rendition:break-scroll-before
Specifies that the current spine item should break the current continuous scroll and start a new one.

Example 3: Spine item breaking the continuous scroll

<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 property is primarily meant for EPUB publications that contain multiple episodes of a series, in order to provide a break between episodes.

2.5. Additional metadata

Instead of documenting new metadata for continuously scrolled publication, this proposal recommends using the following properties from schema.org :

Appendix A - Examples

For the sake of making these examples more readable, I've ommitted the fallbacks currently required by the EPUB specification.

Examples 4: A scrolled publication that contains a single episode.

<metadata>
  <dc:title>A cute Maine Coon appears</dc:title>
  <dc:language>en</dc:language>
  <meta property="schema:CreativeWorkSeries">The Cat Collector</meta>
  <meta property="schema:CreativeWorkSeason" id="season-1">Season 1</meta>
  <meta property="schema:episodeNumber" refines="season-1">1</meta>
  <meta property="rendition:layout">scrolled</meta>
</metadata>

<manifest>
  <item id="tile1" href="1.jpeg" media-type="image/jpeg"/>
  <item id="tile2" href="2.jpeg" media-type="image/jpeg"/>
  <item id="tile3" href="3.jpeg" media-type="image/jpeg"/>
</manifest>

<spine>
  <itemref idref="tile1"/>
  <itemref idref="tile2"/>
  <itemref idref="tile3"/>
</spine>

Examples 5: A scrolled publication that contains an entire season.

<metadata>
  <dc:title>The Cat Collector</dc:title>
  <dc:language>en</dc:language>
  <meta property="schema:CreativeWorkSeason" id="season-1">Season 1</meta>
  <meta property="schema:numberOfEpisodes" refines="season-1">2</meta>
  <meta property="schema:episodeNumber" refines="season-1">1</meta>
  <meta property="schema:episodeNumber" refines="season-1">2</meta>
  <meta property="rendition:layout">scrolled</meta>
</metadata>

<manifest>
  <item id="episode1-tile1" href="1.jpeg" media-type="image/jpeg"/>
  <item id="episode1-tile2" href="2.jpeg" media-type="image/jpeg"/>
  <item id="episode1-tile3" href="3.jpeg" media-type="image/jpeg"/>
  <item id="episode2-tile1" href="4.jpeg" media-type="image/jpeg"/>
  <item id="episode2-tile2" href="5.jpeg" media-type="image/jpeg"/>
</manifest>

<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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment