Your comments
I'll try to reproduce the problem on my side, thanks.
1200px is the width under which Ubooquity will not go when resizing images. If the image is already smaller, nothing happens.
For most comics, resizing to an even smaller width would not be really usefull as they quickly become to small to read.
This limit only exists because mobile device browsers lie about the real width of the window.
Did one of you already have a problem with the resolution of the image sent by Ubooquity ? (e.g. a blurry image)
I am not talking about the size of the image relative to the screen size (like when you want your image to take the full width of the screen even if the original image is smaller), this displayed size will be configurable in the reader (someday) with settings like "fit to width", "fit to height" or "100%".
For most comics, resizing to an even smaller width would not be really usefull as they quickly become to small to read.
This limit only exists because mobile device browsers lie about the real width of the window.
Did one of you already have a problem with the resolution of the image sent by Ubooquity ? (e.g. a blurry image)
I am not talking about the size of the image relative to the screen size (like when you want your image to take the full width of the screen even if the original image is smaller), this displayed size will be configurable in the reader (someday) with settings like "fit to width", "fit to height" or "100%".
I have found java library to read DJVU files. I'll try to use it in Ubooquity (so far I am optimistic).
True. That's because a lot of devices lie about their resolution. For instance an iPad will declare a width of 900px while its true width is 1536px. An image resized to 900px is ugly on such a screen. I chose 1200px as the minimum width to prevent resizing to too small a width.
In fact the operating system is not involved in the sorting (the program is running in the Java virtual machine, so almost everything is OS independant). Everything is done by the internal database (H2).
The filename sort is a lexicographic one (the comparison is done between strings of characters, not numbers), so "100" coming before "11" is the expected result.
The easiest way to fix your problem (easiest for me at least ;)) would be to name your files using zeros in front of the issue number (it is a good practice anyway).
Luckily there is an application for that: ZenCBR.
The filename sort is a lexicographic one (the comparison is done between strings of characters, not numbers), so "100" coming before "11" is the expected result.
The easiest way to fix your problem (easiest for me at least ;)) would be to name your files using zeros in front of the issue number (it is a good practice anyway).
Luckily there is an application for that: ZenCBR.
Regarding the HTML templates, the problem is not really the use of a template engine, as some very simple ones are available (I'm thinking Mustache for instance), but rather the way the HTML is currently generated: heavily coupled with the code.
Customer support service by UserEcho
Each comic book is identified by an ID number in the database. This ID is also used to name the thumbnails files. Looks like the IDs in the database and the ones in the thumbnails cache folder are no longer in sync.
I'm afraid your only solution is a full rescan of your collection. :/