Read Series and Page information from ComicInfo.xml within CBA archives

[C0rn3j]

This is a repost of my comment in the same issue on Mihon's side - mihonapp/mihon#100

---

The reader needs to deal with metadata fields from all CBAs, otherwise it will possibly have bad metadata for both the Series and the Chapter Pages.
Imagine a Series with the following:

• One CBA having Fantasy, Horror genre
• Second CBA having Action, Horror genre
• After the user sets up the Series in the reader, a third CBA releases with Action, Horror, Thriller

The desired result in the main Series entry is to have the Genres Action, Fantasy, Horror, Thriller, as the CBAs themselves contain all of those when combined.

Your suggestion only enables these scenarios, each with multiple drawbacks:

• Users need to select one CBA at random and manually extract and copy the XML out into the Series folder themselves
  • The tags will be incomplete
• Users need to be provided with an additional already-created-merged XML, outside of the CBA, and they need to copy it themselves into the Series folder
  • Every content update of the Series needs to have the new XML copied
  • This puts a burden on the CBA maintainer to accommodate readers that are not capable of parsing the metadata
• CBAs have to carry such merged XML
  • Every content update of the Series needs to have the new XML copied
  • CBAs no longer have the correct metadata for its actual chapter contents
  • This requires convincing people to break the ComicInfo.xml standard, and keeping the XML up to date in the CBAs

The reader already goes through all the CBAs, specifically to save a ComicInfo.xml file into the archive, if it isn't already present.

The reader needs to read it too if it is present, merge what makes sense merging and informing the user if there are any irregularities, such as having One Piece for a Series name in one CBA and Naruto in another.

---

My use case is creating an archive to distribute for local sources.

I can't possibly expect all the users to:

• Dig through the archives
• Extract files
• Create a folder structure
• (On every content update!) To make sure the entry is overall tagged at all and properly, manually merge tags from the separate ComicInfo.xml files OR get an extra loose merged ComicInfo.xml created by me, that I now have to maintain.
• Put the files in their specific places

Having the reader parse ComicInfo.xml would also allow easy importing of CBA's from within the app, as the reader would now be able to determine where the CBAs should go, without requiring the user to create folder structures and place files in specific places.
Simply placing them in local without a Series folder would be enabled too, the reader could just automatically process any loose files.

---

Additionally, with the current system of NOT reading the metadata, I can't simply define a FrontCover and have the reader pick it up, it will just pick whatever is Alphabetical first in the Series.

I can't have the reader show the current cover of the Chapter I am reading as the Series cover.
I can't browse the chapter covers by tapping on the cover and sliding from left to right.
Similarly, no BackCover or InnerCover tags are used.

Reading the ComicInfo.xml from the archives enables solving all of these problems and making using local sources so much more user friendly.

[null2264]

Yokai already read information from CBZ/CBR archives for Chapters (for Title and Number). I'll consider the XML merging for stuff like Tags/Genres.

For Cover, I'd have to wait for upstream, there's no support for multiple cover since it's a pretty niche feature, most sources only provide 1 cover, so that'd probably require ext-lib changes.

[C0rn3j]

I'll consider the XML merging for stuff like Tags/Genres

Awesome! I would most welcome if it the reader also set the Series name, author, summary, and whatever else goes in the Series display window, and generated its own Series XML* from it, as to not have to provide people with multiple XMLs.

That is my biggest pain point and is what got me into reporting this.

* Though I presume this is unnecessary as the reader can just save the info in its own DB?