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)

I started working on the OPDS sorting issue again and realized the problem was completely on client side: issues are already sorted by filename, regardless of the displayed title.

I did a few tests with Chnuky Reader (iOS), and the entries are "re-sorted" by title (alphabetical order). Hence the issue.

A test with other OPDS clients did not show the same issue as they did not reordered entries on the fly.

Best solution: fix Chunky.

Workaround: Using filename as title instead of the "title" fields from the comics metadata.

I don't know yet what I'll do. I don't like working around problems that do not come from Ubooquity, but stop using metadata title in OPDS (and library pages) might have other benefits anyway.

Let me all know what you think.

The "-headless" parameter is supposed to prevent errors like the one you posted.

Are you saying you have this error even with the "-headless" parameter ? If so, could you post your command line ?

As for the themes, did you copy your uncompressed theme in the theme directory, selected it in the settings and restarted Ubooquity ?

What's wrong with the solution provided by Frozen Trout (which I have been using too) ?

I wish I could give one ! :)

But I don't have much control over the time I can put into Ubooquity, so I'll stay with "When it's done".

The good news is that I have finished two big tasks that took waaay more time than anticipated:

- migration to Jetty instead of NanoHTTPD to server pages

- rewrite of the admin UI (both desktop and web versions)

Other features I want to include in 2.0.0 should take less time.

PDF has been a painful topic since the beginning.

There is no "perfect" free library to render PDF in Java yet (although PdfBox is making progress).

So what I'll do in a future version is to allow users to plug external PDF renderers (MuPDF, Poppler...) to Ubooquity.

This should solve all the most of the PDF relarted problems as they are usuallly more efficient than PdfBox.

In the meantime, the only workaround (which might not work in all cases) is to try to allocate more memory to Ubooquity (see the FAQ).

Ubooquity 1.9 and 1.10 do not use the same version of PdfBox (the lib used for PDF rendering), that's probably the cause of your problem.

Unfortunately, your covers are "broken" by the most recent version of PdfBox, which fixes a lot of problems for other PDF files. So I can't go back to the older version.

If you can provide me with a example of "broken" file, I'll take a look at what happens, in case there some fix I can apply (though its quite unlikely).

I'll continue to update PdfBox when I release versions of Ubooquity, so your problem might go away as PdfBox evolves (the project seems quite active).

I also plan to allow plugging external PDF renderers to Ubooquity (e.g. MuPdf, Poppler...) so that people can choose the one that suit their needs.

No, it's not expected (at least if I understood correctly the Logback documentation).

But I retested the whole procedure and got the same behavior that you had.

So I don't know exactly why the file needs to be in the working directory, but I'll update the Ubooquity documentation accordingly.

Thanks for the info.

By the way, the doc has been put on Github, so the new link to the procedure is:

https://vaemendis.github.io/ubooquity-doc/pages/tutorials/log-customization.html