-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a reading direction to ComicInfo #40
Comments
IMHO an element specifically for ReadingDirection with four states would be best for informing software how to present the comic. 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. Adding a new object for reading direction make more sense. |
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 |
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 |
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. @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. |
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 |
Where does this comes from?
Hello,
Currently, the Manga element has the value
Yes
andYesAndRightToLeft
.I suggest adding a new element to replace the option "YesAndRightToLeft" (credit to @ajslater).
ReadingDirection
that will have as optionsLeftToRight
,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
andContinuous
.Is the element already handled by any application or tool?
No response
The text was updated successfully, but these errors were encountered: