DiViNa Lacks the Capability To Attribute Contributors at a Chapter Level

[basicallykirito]

The need to attribute and differentiate contributors for each chapter of a series is paramount for manga distribution on the web. It is standard practice that series are scanned, translated, proofread, edited, redrawn, and more by several groups over the course of its publication, or even within a single chapter. Most manga publishers, readers, and data formats expect the presence of at least a translation/scanlation group attribute, though it's common for groups to add a page at the end of their chapter releases with more precise attribution that could be included in a chapter-level contributor scheme. If examples are necessary, I can provide them.

[chocolatkey]

In the context of fan translation of manga (or other comics), each chapter is released separately, and may be translated by a different team/group. If you are using the WebPub format in this setting, I think it would be more appropriate to have one WebPub manifest per chapter, instead of trying to bundle many chapters into a single manifest. That way you can have per-chapter contributors and any other fields that are specific to the chapter, including the relevant images. The list of chapters itself would then be in an OPDS feed or similar. It's also easier to only update the feed when a new chapter comes out.
Examples would be useful.

[basicallykirito]

@chocolatkey Do you have an example of releasing manga chapters as individual WebPub manifests as opposed to being grouped as a single web publication? I considered this initially, but to my eyes it did not appear as if OPDS (1.x or 2.0) or WebPub lent itself to being used this way. As for examples of group attribution importance in common use:

• Mihon, formerly known as Tachiyomi, is the most popular open source manga reading application. It includes group information in its data model and displays it prominently. Most (formerly official, now unofficial) sources implement this, with some sources and forks even implementing user experience and accessibility features based on it (filtering groups with low quality releases or otherwise difficult to read translations).

• MangaDex is a very popular manga distribution service for both unofficial and official publishers, with group attribution similarly being shown in clear view for users. The official MangaDex test manga offers a great example of group attribution.

• Cubari is the closest alternative to DiViNa/WebPub as a web-native manga manifest that became popular during uptime issues MangaDex experienced some years ago. Cubari allows groups and publishers to release GitHub-hosted manifests that can point to images hosted on standard services such as Imgur for consumption with a compliant reader, the most common being their own. Their manifest is sparse and includes little more than a name, description, and table of contents pointing towards chapter data, but even so group information is important enough to keep.

• For examples of richer contributor attribution often being desired by publishers lacking machine-readable ways to distribute such information, here are several instances from series currently on the front page of MangaDex:
  https://mangadex.org/chapter/68d38c14-9504-46f3-a1af-ed54f69ad9a4/1
  https://mangadex.org/chapter/f0858047-9efe-4e5e-a1d4-f4f3d521b98b/3
  https://mangadex.org/chapter/55bcc8d3-4530-49b2-bfba-d01577a88113/2
  https://mangadex.org/chapter/cbf12cd4-2e03-4b81-a7fb-e82f75c2f0a5/9

• An example of multiple groups releasing the same chapter:
  https://mangadex.org/chapter/1ab38d10-5a67-42e2-80c9-4c5e99e79345/59
  https://mangadex.org/chapter/9aa661b1-03a0-42f0-8f4e-206676db9578/59

More examples can be provided from more readers, services, and groups if necessary.

[HadrienGardeur]

You probably missed the following PR which adds chapter level metadata: #121

Once you offer that level of granularity, it's easy enough to add the proper contributor type as well.

[chocolatkey]

@HadrienGardeur thanks for pointing to that PR.
@basicallykirito I am a bit surprised that you don't think WP manifest/Divina lends itself well to individual chapters (or volumes), that's exactly how I've been using it for years in commercial projects, such as for J-Novel Club, and my personal reader (deprecated).
Here is a super simple example of a manifest generated using the CLI from a .cbz file of a chapter:

{
  "@context": "https://readium.org/webpub-manifest/context.jsonld",
  "metadata": {
    "conformsTo": "https://readium.org/webpub-manifest/profiles/divina",
    "https://github.com/readium/go-toolkit/releases": "v0.11.0",
    "title": "a_test_file.cbz"
  },
  "readingOrder": [
    {
      "href": "001.jpg",
      "rel": "cover",
      "type": "image/jpeg"
    },
    {
      "href": "002.jpg",
      "type": "image/jpeg"
    },
    {
      "href": "003.jpg",
      "type": "image/jpeg"
    },
    {
      "href": "004.jpg",
      "type": "image/jpeg"
    },
    {
      "href": "005.jpg",
      "type": "image/jpeg"
    },
    {
      "href": "006.jpg",
      "type": "image/jpeg"
    },
    {
      "href": "007.jpg",
      "type": "image/jpeg"
    }
  ]
}

It would be simple to add contributors etc. to this manifest for a chapter. You can also check out more examples of manifests in the playground, or pass your own CBZ or EPUB to our test server instance to see how they turn into WebPubs by base64url-encoding the URL and adding it in the path like this: https://publication-server.readium.org/aHR0cHM6Ly9wdWItNGVjOWIyZjkzZjY0NDA4MDhiODYwMThlM2VjMDNjY2IucjIuZGV2L3B1YmxpY2F0aW9ucy9mZW5yaXItYzEuY2J6/manifest.json

With regards to the services you mentioned, especially the example Cubari JSON file you linked that is intended to load an entire series into the reader, my personal opinion is that this is not the right way to use the WP manifest format. The format is meant to be used mostly at an individual publication level. This means a single chapter, or a single volume, or in some cases like what @HadrienGardeur has been adding more and more support for, bundles of chapters (e.g. webtoon seasons). I think it is unwieldy to keep adding more and more images/chapters to the same manifest, as I think is aptly shown by the 2.5MB size of the Cubari manifest you linked. And every time you want to update any metadata, the whole file must be updated. If, in a hypothetical scenario, I was reimplementing the Cubari format, I would have the initial "repository JSON" be something like an OPDS 2.0 feed with publications or other custom JSON format, and each chapter be an individual WP manifest linked from this base file.
Of course you can use the spec however you want though. Maybe if you can elaborate on your use-case/idea, I can understand a bit better how you're intending to implement this.

[HadrienGardeur]

If, in a hypothetical scenario, I was reimplementing the Cubari format, I would have the initial "repository JSON" be something like an OPDS 2.0 feed with publications or other custom JSON format, and each chapter be an individual WP manifest linked from this base file.

+1 on that suggestion from @chocolatkey

OPDS 2.0 has pagination specifically to avoid ending up with a large feed, plus it would allow both streaming (as illustrated in @chocolatkey example) and downloads, which feels more flexible.

Compared to some of the examples that you linked @basicallykirito, RWPM/Divina and OPDS 2.0 can also express more metadata, place images in a spread (left, right, center) and can support scrolled comics in addition to paginated ones.

[basicallykirito]

You probably missed the following PR which adds chapter level metadata: #121

I had! Thank you for the notice, I'm not quite sure how I managed to miss it.

I am a bit surprised that you don't think WP manifest/Divina lends itself well to individual chapters (or volumes)

With the sole exception of your repository, I failed to find any substantial project managing to use WebPub for manga. Similarly, the OPDS 2.0 ecosystem seems fairly scarce, so unfortunately most of my opinions of WP and DiViNa are of the quality of the libraries which implement it and the letter of the specification itself. Coming from OPDS 1.x, manga support with per-chapter publications left much to be desired.

With regards to the services you mentioned, especially the example Cubari JSON file you linked that is intended to load an entire series into the reader, my personal opinion is that this is not the right way to use the WP manifest format.

I wholeheartedly agree. Cubari cannot scale, and I would be thrilled to be able to recommend OPDS 2.0 paired with DVN instead. As long as an equivalent or superior publishing and reading experience can be matched within this newer standard, I think most would be willing and able to switch.

Maybe if you can elaborate on your use-case/idea, I can understand a bit better how you're intending to implement this.

I hope I sounds as optimistic as I intend to, but my use is simply having a functional and standard means of publishing and distributing manga on the web. As you have seen yourself, Cubari is a poor choice but the one many are stuck with. OPDS 1.x even with the page streaming extension is a clunky experience at best. As for ideas, I believe as long as DiViNa can fully encompass the features of Cubari, it would be be able to gain the attention of many existing groups. I'll experiment with per-chapter manifests further and see if I can get it working well.

[HadrienGardeur]

With the sole exception of your repository, I failed to find any substantial project managing to use WebPub for manga.

This will hopefully change with the addition of manga support in the various Readium toolkits and Thorium Reader products.

It's also worth pointing out that South Korea has adopted Divina as a national standard (TTA) for continuously scrolled comics (webtoons) and will be used by a national archive in the future.

Similarly, the OPDS 2.0 ecosystem seems fairly scarce, so unfortunately most of my opinions of WP and DiViNa are of the quality of the libraries which implement it and the letter of the specification itself.

OPDS 2.0 is mostly used by public libraries at this point, in countries such as: Spain, Belgium, Switzerland, Portugal, Finland, Canada…

A few million ebooks/audiobooks are borrowed every year with it, I wouldn't call it scarce but hopefully it'll get more adoption from other communities in the future.

OPDS 1.x even with the page streaming extension is a clunky experience at best.

OPDS-PSE has the benefit of being very compact (a single templated link) but it lacks per image positioning in the spread which is IMO quite important.

It also forces a convention for the URL serving each page, which doesn't exist with RWPM/Divina where you can point wherever you want.

RWPM/Divina is well suited both for streaming comics (through OPDS 2.0 or a single manifest) and serving them in a package (in a ZIP). It could provide a unified experience and format, regardless of the way content is consumed.