comicinfo
comicinfo copied to clipboard
anansi-project
Add a reading direction to ComicInfo
Where does this comes from?
Hello,
Currently, the Manga element has the value Yes and YesAndRightToLeft.
I suggest adding a new element to replace the option "YesAndRightToLeft" (credit to @ajslater).
ReadingDirection that will have as options LeftToRight, RightToLeft, TopToBottom, BottomToTop.
Also with a True/False or Yes/No attribute for Continuous. To provide information to any reader how should the content be displayed.
What is the rationale for adding support for this element?
Help any kind of reader what should be the default way to read the comic/manga. Will be especially useful for Webtoon that usually are TopToBottom and Continuous.
Is the element already handled by any application or tool?
No response
IMHO an element specifically for ReadingDirection with four states would be best for informing software how to present the comic. LeftToRight, RightToLeft, TopToBottom, BottomToTop. The Manga tag is partially overloaded for some of this already, but the Manga: "No" or "Yes" states by themselves don't really tell the presentation software anything useful.
An alternative might be two boolean elements. ReadingOrientation and ReadingDirection.
Software doesn't care if the origin of the publication was Marvel, Shueisha, or Tumblr, just how it should be read
I'm for ReadingDirection that makes total sense and in this case we can deprecate the YesAndRighToLeft for manga.
Sent from Nine
From: AJ Slater @.***> Sent: Monday, April 10, 2023 17:59 To: anansi-project/comicinfo Cc: Antoine Aflalo; Author Subject: Re: [anansi-project/comicinfo] Update Manga element to add Webtoon (Issue #40)
IMHO an element specifically for ReadingDirection with four states would be best for this and would inform software how to present the comic. LeftToRight, RightToLeft, TopToBottom, BottomToTop. The Manga tag is partially overloaded for part of this already, but the Manga: "No" or "Yes" states by themselves doesn't really tell the presentation software anything useful. An alternative might be two boolean elements. ReadingOrientation and ReadingDirection. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>
Given this is an Enum value, adding new values could be a breaking change, which we don't want to introduce.
To be honest I prefer the solution of @ajslater. I'll rephrase my request.
Adding a new object for reading direction make more sense.
IMHO an element specifically for ReadingDirection with four states would be best for informing software how to present the comic.
LeftToRight,RightToLeft,TopToBottom,BottomToTop.
The limitation with that is that it doesn't define how the pages should flow. For instance you can't differentiate top to bottom page by page, and top to bottom continuous (webtoon).
I agree that using a new field would be beneficial, since the current Manga field is botched.
I'm curious if there are actual scenarios for non-continious top-down.
Would it always be continuous?
Sent from Nine
From: Gauthier @.***> Sent: Friday, April 14, 2023 21:46 To: anansi-project/comicinfo Cc: Antoine Aflalo; Author Subject: Re: [anansi-project/comicinfo] Update Manga element to add Webtoon (Issue #40)
IMHO an element specifically for ReadingDirection with four states would be best for informing software how to present the comic. LeftToRight, RightToLeft, TopToBottom, BottomToTop.
The limitation with that is that it doesn't define how the pages should flow. For instance you can't differentiate top to bottom page by page, and top to bottom continuous (webtoon). I agree that using a new field would be beneficial, since the current Manga field is botched. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>
Assuming that all top to bottom publications need to be read in a continuous way would limit the data model. There might also be some publications in LTR or RTL direction that are made to be read in a continuous manner.
In the end the consuming application will try its best to map the metadata to its actual capabilities.
That make sense. Then in that case having a boolean attribute saying if it should be continuous would work for the reading direction.
Sent from Nine
From: Gauthier @.***> Sent: Saturday, April 15, 2023 01:02 To: anansi-project/comicinfo Cc: Antoine Aflalo; Author Subject: Re: [anansi-project/comicinfo] Update Manga element to add Webtoon (Issue #40)
Assuming that all top to bottom publications need to be read in a continuous way would limit the data model. There might also be some publications in LTR or RTL direction that are made to be read in a continuous manner. In the end the consuming application will try its best to map the metadata to its actual capabilities. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>
I've just noticed that the Readium WebPub (related to OPDS-2.0) spec's metadata schema has something similar to my proposal:
https://github.com/readium/webpub-manifest/blob/master/schema/metadata.schema.json#L107
"readingProgression": {
"type": "string",
"enum": [
"rtl",
"ltr",
"ttb",
"btt",
"auto"
],
"default": "auto"
},
I suppose i like ReadingDirection better, but maybe their abbreviated enums have merit? 'auto' seems a bit odd to me. I think i'd consider that case the same as the attribute being omitted.
i would not cater for whether it's paged or continuous though. I'm quite happy with the proposed change in the first post, we could have a complex type holding both values of reading direction and continuous scrolling preference.
@ajslater i don't think abbreviated enums bring a lot. It leaves a lot to interpretation, i would much prefer full values for clarity's sake. rtl and ltr may be easy to understand, but i don't think ttb and btt would be. auto probably means the client should handle it with its default reading settings, but in that case an absence of value is probably more explicit.
@Belphemur would you be able to send a PR that would solve this, do you think?
I've just bumped into https://readium.org/webpub-manifest/modules/presentation.html which may be of interest. Haven't had time to read in full yet though.
Yeah they farm out 'continuous' to the presentation extension schema. I've not thought deeply about what they consider part of the presentation schema and what they consider core metadata. There's probably a good argument that reading direction ('progression') is a presentation detail.
I've been implementing OPDS 2.0 for Codex recently on a lark, and I have to say I'm impressed. The OPDS 1.x schema shows its age, but the 2.0 draft spec, imho, is very well thought out. I may be slightly biased because it's pretty close to the Codex API, it seems to be a case of convergent evolution. I feel like I could replace the Codex API with OPDS 2.0 with only minor extensions.
OPDS 2.0 is missing a page by page API, like OPDS 1.2 has, but explicitly has facility for templated links in their search specification (which is not OpenSearch):
{
"rel": "search",
"href": "search{?query}",
"type": "application/opds+json",
"templated": true
}
They also have a specific “image” type link section, but using that for pages feels too comic specific for this publication schema.
A templated schema for pages would be fine. But also, I don’t think book pagination is as open ended as search and therefore might not require a template. A specific ‘give me a page’ schema with optional legal min and max values and the likely mime-type of the returned page might even be better.
Woops. The latter half of that post is off topic. I'm actually in a separate discussion with gotson talking about comic server page streaming, OPDS 2.0 and synchronization.
@Belphemur im currently developing a cbz archive editor. There its possible to define your own fields which should be included in metadata. In addition you can specify how the value is handled. Meaning, you can set possible values for a certain key. This way, you are totally flexible regarding the potential data and values within the comicinfo.xml
