Closed majora2007 closed 1 year ago
CRW handles this with the format
field. Specials, One-shot, Annual are examples of some of the values for format.
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" />
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.
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.
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
orOne-Shot
would work well.
Since format
already contains One-Shot
, I think a Boolean would be the best route otherwise you risk data redundancy.
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.
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:
Series
field should be the same`)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.
ComicVine is inconsistent see one example here https://github.com/comictagger/comictagger/issues/176#issuecomment-907965050
But usually they set everything into separate series.
Special
tag was present, we could use Number
to provide ordering in the consumer application
- 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 useNumber
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?
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.
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 ?
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.
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.
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
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.