Thanks. And the problem is the same on both device ?

Could you open this page in the browser you use to read comics and paste the information you got here ?

It's not planned as ebooks and comics are processed quite differently by Ubooquity. So I'd rather not mix the two (the only exception being PDF files, but even there, two different rendering engines are used depending on the section you put your files into).
The workaround is to share your epub comics in the book section.

The comics cover size setting does not have anything to do with the size of the page in the online reader. So I'm surprized modifying on has an impact on the other.

Would you be able to attach a screenshot or two of your problem ? (on which reading device do you have the problem ?)

For now the page is reduced to the width of your screen, but there are no advanced options yet. It's on the todo list.

That's strange. Are other Ubboquity files and folders present in your home directory as well ? (cache, logs, preferences.xml...)
If so, this means you have started Ubooquity directly from your home directory (Ubooquity creates files and folders it needs in the "working directory", meaning the directory you are in when you launch it).
If not, there is something I missed.

Hi,

the server needs to be restarted for the new theme to appear in the dropdown menu.
You still have only the default theme after restarting ?

I never tried, but since Ubooquity interactions with the underlying operating system are quite standard, I don't see why you couldn't.

The problem with resizing images upon extraction is that the resulting cached comic will specific to a screen size. Size which can easily change when resizing the browser window for instance.
And since I have to do the resizing on the fly, I might as well do the transcoding since resizing the image requires transcoding it anyway.
Or I could decide that a width of 1200 or 1500px for a comic image is goos enough for everybody (the Apple way of doing things ;)) and do the resizing/transcoding as soon as I extract the image.
Not my favorite solution but it might be the most efficient one in the end.

The problem is, if I allow usage of native commands to do the extraction, the extraction/resizing phase will have to be done in two passes. More complexity, more concurrency problems, more possibility for failures.
Nothing impossible but longer to implement.

As for serving the original file, it has already been requested for WebP files (somewhere in this forum) and declined as I don't think of WebP as a viable format (at least until it gets support outside of Google products).
Although the performance increase is a much better reason for doing it, it would still be difficult as it would require Ubooquity to know the type of each image in the comic archive when it generates the HTML for the online reader and the OPDS XML (the type is explicitely defined in the OPDS link).
I don't know how to do that efficiently yet.
Still not easy but I have a few ideas...