Add the ability to use decimals (xx.yy) on Volume tag

Question

Add the ability to use decimals (xx.yy) on Volume tag

Opened this issue a year ago · 4 comments

Where does this comes from?

Discussion started on MangaManager and Kavita support channels

What is the rationale for adding support for this element?

I have some series (mainly manga) that release booklets or additional content bundled with limited editions of a given volume. These are commonly referenced as VolNumber.5 as they are intended to be read after said volume.

Adding decimals to the volume tag would allow reader and organizing software to display these between vol n and vol n+1

Is the element already handled by any application or tool?

Not that I'm aware of

Answer 1 · 2024-02-11T15:35:30.000Z

I think this would be an easy thing to accommodate. I saw discussion of it within Komga's discord as well. Kavita already has support out of the box if this is implemented.

Answer 2 · 2024-02-12T07:50:34.000Z

Philosophically I wonder if the simplest solution would be to make Volumes strings to accommodate anything. It's kind of strange that they're the only element of the publishing hierarchy that is not a string.: Publisher -> Imprint -> Series -> Volume -> Issue The biggest disadvantage is that you might lose the ease of assuming you can do purely numerical sorting in applications instead of alphanumeric. However the mission of the Anansi project to remain backwards compatible may not accommodate strings. Or floats. If ComicRack or related software read an xxx.yyy volume would it be guaranteed to fail semi gracefully by casting it to an int floor?

…

On Sun, Feb 11, 2024 at 7:35 AM Joe Milazzo ***@***.***> wrote: I think this would be an easy thing to accommodate. I saw discussion of it within Komga's discord as well. Kavita already has support out of the box if this is implemented. — Reply to this email directly, view it on GitHub <#55 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACAKRXMVCNDRUSPZ6CWP4LYTDQM5AVCNFSM6AAAAABDDTY65CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZXG44DONBXG4> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

Answer 3 · 2024-02-12T12:12:09.000Z

I would be fine having it be a string and just staying on the spec it should be a number.

I can't think of a situation where a volume number could be something other than a number.

Making a string would align better with the rest of the spec.

Answer 4 · 2024-02-14T00:58:34.000Z

With CT it has never been possible to save a non-int value from the GUI. If the CLI was used it would have passed through whatever text was there until 2021 then it enforced it to be an int in all cases by stripping out non-number characters.