[feature-request] Panel View (Region Magnification)

[Hamitamaru]

I've noticed that sometimes the manga sent to my kindle are not using the correct reading order for Kindle's "Virtual Panel" feature (ref: https://kindlegen.s3.amazonaws.com/AmazonKindlePublishingGuidelines.pdf)

It seems that you can't get the right LR or RL value from the different sources.

Instead would it be possible to leverage something like https://github.com/Ajira-FR/comics-splitter to get the bounding box co-ordinates for a panel and then set that up as for "Panel View (Region Magnification)" feature (ref: https://kindlegen.s3.amazonaws.com/AmazonKindlePublishingGuidelines.pdf)

[Hamitamaru]

You may also want to consider using this : https://github.com/mozillamonks/comicstrip/blob/master/comicstrip#L64

Though that is vended using AGPL license so maybe use it as a library, or fork it change as needed and and use the fork as a library and you should be good according to this (though I do not have a legal degree and cannot claim this as legal advice <____<) :

https://softwareengineering.stackexchange.com/questions/107883/agpl-what-you-can-do-and-what-you-cant

[aplanas]

For the reading order (RL, LR) this information is extracted from the source:

https://github.com/aplanas/kmanga/blob/master/scraper/scraper/spiders/mangareader.py#L120

and when it is not provided, RL is taken as default:

https://github.com/aplanas/kmanga/blob/master/scraper/scraper/spiders/batoto.py#L154

So I do not think that comic-spliter that help here, even I will see if I can understand the algorithm and port it to kmanga

Kmanga used to deliver comics with virtual panel, but the update to 5.8.5 firmware, somehow, disabled this feature for manga:

https://github.com/aplanas/kmanga/commit/72319b9e1a8ec33ac50f368b5c324fa403d6c0e3#diff-d2c75a26973a1888f241125717b166cf

I can revisit this, indeed

[Hamitamaru]

Since not all metadata that can control the ebook reading experience can be reliably collected from the image/chapter sources. Would it be possible to add subscription level metadata overrides. So when someone goes to a subscribed series page in kmanga they can add override values for reading_direction (and in future other data that can impact reading experience) that are used when generating the ebook file?

[aplanas]

I was thinking about this. For one side can be useful for multiple other stuff, like when the user want to join multiple chapters into one, or adapt the mobi to the size of the type of user's kindle. But for other this will invalidate the cache that is in place.

For this specific issue, another option is have a mechanism that is not user-dependent, but attached to the manga model. Basically the admin can fix this for some manga (maybe providing some input from users). The tricky part is how to not overwrite this once the spider update the manga information.

[Hamitamaru]

Hmm i see: https://github.com/aplanas/kmanga/blob/e8794979dd814a09e52fbf1c5d19a79c055d844d/mobi/cache.py#L258

I didn't know that you had this cache in place, makes sense when a new chapter is released and 1000 people are subscribed to that series you can go through generation once and serve the same file to all 1000 subscribers.

Knowing this you definitely don't want to generate subscription specific ebook files. Though instead of the Admin having to take in user suggestions and potentially being the bottleneck (and what does Admin do when one user wants configuration A and one user wants configuration B) why not go with a voter system where people suggest values for options (they vote from the series subscription page) and the most popular one wins out automatically?