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: Mangaka/Illustrator/Artist (manga specific) #7

Closed ocgineer closed 1 year ago

ocgineer commented 2 years ago

Where does this comes from?

Me and Kavita's Discord

What is the rationale for adding support for this element?

A specific element for Manga artists as all the current specific Comic elements do not really match a mangaka. Usually the mangaka is responsible for everything all the other roles describe (or have assistance but they are never mentioned). So manga has only 'story by' and 'art by' (adaption or duo writer/illustrator) or 'story and art by' single creator for both story and art.

gotson commented 2 years ago

I don't see why you can't just fill the existing fields, ie Writer + Penciller ?

shimizurei commented 2 years ago

A manga-ka isn't just a penciller. They are usually the writer, penciller, inker, colorist (for full-color manga or color pages), letterer, and cover artist. I like that these these fields exist, especially for manga anthologies that actually have a specific cover artist, but that's a lot of copypasting (when it comes to manga).

gotson commented 2 years ago

This is a data model, the point of it is to exchange data, not to make it easier for manual edition. Adding a field that is already covered by others only for the sake of convenience does not really bring much to the table.

Note also that mangaka does not always encompass all of the roles, many manga have a different writer and artist, which would render the use of this aggregated field useless.

lordwelch commented 2 years ago

I think the GCD has a decent idea of crediting them for all roles that they took part in. As in both cases (GCD and ComicInfo) this is meant to be a machine readable metadata, I think the application should determine what to display and the data format should stick to a specified terminology.

ocgineer commented 2 years ago

Note also that mangaka does not always encompass all of the roles, many manga have a different writer and artist, which would render the use of this aggregated field useless.

This is true, as I mentioned they have assistants with the drawing that does the coloring or odd drawing jobs. But the issue, for me at least, was that on the cover only the main mangaka (and writer) is noted, and nothing further in credits. I do not know anything about American Comics regarding all these roles, but in general Manga has two roles, story and art.

When I started trying to use ComicInfo for my Manga I ran into this and got confused on what to use, as penciller is something I've never even heard of. If there is no 'main' artist role and you want keep Penciller for that, the documentation of the spec should indicate that this is a main artist field so that programs reading the metadata know what to at least display (in the case of Manga).

gotson commented 2 years ago

Penciller means drawing with pencils, Inker means going over those drawing with ink, and then erasing the pencil. That's how all publications are done, manga or comics or others.

it's quite common in manga for the assistants to do the inking though, so even though there is only story and art credited in a manga, there is actually an inking process done sometimes by assistants not credited. What it means also is that art = penciller + inker.

the documentation of the spec should indicate that this is a main artist field so that programs reading the metadata know what to at least display (in the case of Manga).

The format doesn't care how the data is consumed, the format is a mean for machine readable data exchange.

The problem i see here is that you are manually editing files, without knowing what those fields mean. Ideally the files should be filled by a program (be it a manga tagger or whatever really) that would do this job for you to figure out what to fill, for example in the case of manga to fill both penciller and inker.

gotson commented 1 year ago

Closing this as there is no real, clear requirement.