Your comments

Don't bother, I managed to reproduce the problem (don't know would I couldn't 7 months ago...).


I'll fix it.

In the meantime, if you want to fix the current version of Ubooquity, download this file, open Ubooquity.jar with any zip file tool and replace "comicreader.css" (in the "comicreader" folder inside the jar file) by the one you downloaded.

And let me know if it worked for you.


As for the zoom option, for now you can choose "original" for the size displayed in the comic reader and zoom it in/out using the built-in zoom of your browser (ctrl + mouse wheel).

This is obviously a bug.

Already signaled:

http://ubooquity.userecho.com/topics/281-when-using-original-the-top-part-of-the-page-gets-cut-off/


I haven't been able to reproduce it on my side. Until I do, I won't be able to investigate it.

So any additional information you might provide is welcome (OS, browser, ideally send me a comic with this problem...).

There is no filtering feature yet (only searching and basic sorting options).

I might add them in the future, but I have no immediate plan for that.


If you need advanced collection management for your documents, you should take a look at Calibre.

Not yet, but I can add it.


Though I'd be curious to know why you'd want to see ISBN in details of booked accessed through Ubooquity (nothing wrong with that, just curious).

After a bit of thinking, I'll use the filename for comic listing, even if a title is present in the metadata. Metadata title will still be displayed in the details (where it won't have any impact on any kind of sorting).


So I'll decline your suggestion Madrox, since my modification will fix the problem it would have solved.

Added to the backlog.

Don't expect it soon though, the backlog is already quite crowded. ;)

I now read the alternate series and alternate number fields from the metadata file, and I will display the alternate number when the main one is empty.


As for the sorting, I started working on a "meta key" that would have sorted books by series/volume/number. Then I realized that the resulting order would be the same as sorting by file path 99,9% of the time.

So I'll stick to sorting by file path unless there is a really compelling reason to do otherwise.


(and the number type is fixed)