anansi-project / comicinfo

ComicInfo.xml's new home
https://anansi-project.github.io/docs/category/comicinfo
MIT License
136 stars 8 forks source link

New Element: Special #14

Closed majora2007 closed 1 year ago

majora2007 commented 2 years ago

Where does this comes from?

Raised by me

What is the rationale for adding support for this element?

Some items in comics and manga are in a series, but not a volume or issue itself, but something that falls under a special. In comics, that might be an Annual, in manga, Artworks, etc.

Currently, Kavita, does filename parsing to handle this situation, but there are many cases out there and offering a way to the user to mark, this is a special, would greatly benefit consuming applications. This allows for such designation to be portable between consuming applications that support specials.

Is the element already handled by any application or tool?

This would have to be updated manually by the end user.

Example

image Shijou Saikyou no Deshi Kenichi Plus - An extra chapter of random stuff that doesn't fall into it's own series.

I do not think a set of enums should be used as there are many cases. Giving the flexibility of a free form string that denotes the title or type would allow most flexibility and just being present and not empty would imply said item is a Special.

SenorSmartyPants commented 2 years ago

CRW handles this with the format field. Specials, One-shot, Annual are examples of some of the values for format.

therobbiedavis commented 2 years ago

format could be a valid field for consuming apps to read (thought very cluttered and has some redundant data). It looks like majority of the enums would be handled as a special, therefore the consuming apps could just read the field, and if not null it could just mark as a special.

If this field does not work, I would propose just a simple boolean similar to Black and White <xs:element minOccurs="0" maxOccurs="1" default="Unknown" name="BlackAndWhite" type="YesNo" />

lordwelch commented 2 years ago

ComicTagger has support for the format field as well and it looks like it took it's list of arbitrary strings from ComicRack. It does have an option for special, but there is no limit on what you can type in.

majora2007 commented 2 years ago

The only problem I see with format is it's too flexible. From ComicTagger, I see NSFW as an option, which implies people might be using this for tagging. I also see Web Comic, TPB, etc, where those aren't necessarily specials, they are formats or types of the reading material.

I don't think format is the best use case for this. I do think either a simple boolean to denote the item is a special or a tag that allows the user to put Artbook or One-Shot would work well.

therobbiedavis commented 2 years ago

I don't think format is the best use case for this. I do think either a simple boolean to denote the item is a special or a tag that allows the user to put Artbook or One-Shot would work well.

Since format already contains One-Shot, I think a Boolean would be the best route otherwise you risk data redundancy.

lordwelch commented 2 years ago

So format in general is just very undefined, and after looking at the options that it supplies as suggestions it is really more of just a generic tag that only lets you have one item, for example the format has Scanlation as an option but it also has Special but, there is no way to specify if there is a Scanlation of a Special which would be valid situation.

So format probably won't be a good fit and if we want to change format to be more defined that might be better to move to another issue.

In the 2.1 draft tags were added intended to be a comma separated list e.g. scanlation,special or type:special,scanlation. Would this work better? As adding a new element that is as loosely defined is this makes it hard to use correctly (potential ending up with many option and looking a lot like format), and adding a special boolean isn't any more defined. Another option is to have tags refer to content tags (characters, themes, archetypes) and create another element of comma separated strings that separates out, for lack of a better term, format tags, so that information about the release can be recorded.

gotson commented 2 years ago

I would like to ask a few more questions on the intent of the field, more than its representation. What's the intended treatment of specials in consuming applications ?

From what i understand reading the discussions above:

I think in CV the specials or annuals would be part of a specific Volume, which is something that could work here. You could use Volume="Special" to denote specials.

lordwelch commented 2 years ago

ComicVine is inconsistent see one example here https://github.com/comictagger/comictagger/issues/176#issuecomment-907965050

But usually they set everything into separate series.

majora2007 commented 2 years ago
  1. Specials are part of the same Series. They can be things like One-offs or Artbooks of sketches, even small stories that might constitute extras.
  2. Most of the time, I would say no. Sometimes, a special might be a Prelude to the Series itself. Other times, like I mentioned, it is just art or interviews that you would like to keep with the series, but don't have a place in the natural reading order.
  3. No, Specials do not have any sort of order. In Kavita, I let users use special keyword in the filename to order them as specials. Ideally, if the Special tag was present, we could use Number to provide ordering in the consumer application
gotson commented 2 years ago
  1. No, Specials do not have any sort of order. In Kavita, I let users use special keyword in the filename to order them as specials. Ideally, if the Special tag was present, we could use Number to provide ordering in the consumer application

I think using the number makes sense. If a special has to be read between book 5 and 6, the special should have a number like 5.5.

What do you think about using Volume="Special" to denote specials then? It seems to echo to the file naming convention you are already using, no?

majora2007 commented 2 years ago

I think using Number is a great idea. Usually if a special needs to be read, users will name it Chapter 5.5 so it orders correctly.

My understanding was that Volume is a number, so I don't think that is the best solution, as it would be a breaking change. Specials in Kavita are denoted by SP01, SP02 due to the fact that SP isn't used in scene naming.

gotson commented 2 years ago

My understanding was that Volume is a number

You are right, my bad 🤦🏻 So Volume is out of the question then.


Trying to abstract from the form, and thinking about the meaning, i'm wondering what kind of cases we could have for specials that wouldn't fit with a single boolean value.

If the only expected treatment from specials is to separate them from the others, then a boolean works fine. Would there be any other kind of treatments we would expect for those specials ?

I'm thinking you could probably have different types of specials, and maybe you would like to know about that. For example you mentioned artbooks, there's probably regular side stories too. Would having the type of special of any interest to consuming applications ?

majora2007 commented 2 years ago

I think having some type is of marginal benefit. Just having the ability to show that it is a special and grouped with the series is very powerful already.

From my perspective, if this is done, then I would use number and title for order and display purposes.

majora2007 commented 1 year ago

I'm circling back to inform that Kavita has gone the route of having certain Format tags map to treating the underlying issue as a Special.

https://wiki.kavitareader.com/en/guides/managing-your-files/comics

I think this is flexible enough, so I'm going to close my original ask.