You're welcome. :)

The ComicRack format is the only one that is commonly used for comics.

Using an external file would amount to create a format specific to Ubooquity. I prefer to stick to standards (or de facto standards) when they exist.

As for the options to choose which fields to display, it'll come "naturally" when Ubooquity starts using templates for all the pages generation.

Don't know if and when I'll do it though.

Why not just use :

https://fonts.googleapis.com/css?family=Oswald:400,700,300

in your font CSS file ?

(the fact that your are using a reverse proxy has no impact on this, fonts will be served using the URL you specified in your custom css file regardless)

The problem does not exist for fonts taken from the "fonts" folder of Ubooquity since they are referenced using relative paths (so they are automatically served through a "https" URL when a certificate is used).

I don't know exactly why you have this problem, but the symptoms you describe remind me of a HTTP Pipelining issue that some users (including me) have encountered when using Ubooquity with an iOS Browser.

I'am currently trying to replace the internal HTTP server used by Ubooquity (NanoHTTPD) with Jetty, a more robust alternative, to try to solve this issue. But there is still work to do (meaning I don't know yet when it'll be ready) and I have no idea if it will change something to your situation.

The online reader store the page of the book (PDF or other) you are reading in a cookie, so that you can resume later, starting from the same page.

That's what I call "bookmarks" in Ubooquity.

Is it not working for you ?

According to the error message you posted, the problem happens even before Ubooquity tries to start.

Perhaps some user permissions changed on your system.

Java (which in turns run Ubooquity) is not supposed to require root permission to run. So I guess that your problem is a symptom of some Linux user or group permissions modification.

But I'm not an expert on that matter, perhaps some other users with more practice will be able to provide more help.

No, sorry.

From a technical point of view it doesn't make sense to use an extension for another.

Last time I checked (one or two years ago), there was no usable Java libraries that allowed 7-zip file extraction.

Some progress seems to have been made since then, I'll take a look at the available libraries and add 7-zip support if they work well enough.

By the way, the correct extension for 7-zip compressed files is "cb7", not "cbr". "cbr" is for RAR compressed files.

The old PDF rendering library I am using (JPedal free) seems to be broken by recent Java versions.

I am working on replacing it.