So, I tried implementing this. Not as easy as it sounds.

Well, for Android it was, the following line did the trick:

<meta name="mobile-web-app-capable" content="yes">

But for iOS, it's not that simple (as usual). Although there is a configuration that do launch the web browser in fullscreen mode:

<meta name="apple-mobile-web-app-capable" content="yes">

as soon as you click a link you are redirected to Safari.

I tried to change programmatically the location of the page each time a link is clicked (to stay in fullscreen mode), but it broke some parts of Ubooquity.

Bottom line: you'll have fullscreen on Android in the next release but not on iOS.

I quickly tested your server from my PC and my phone.

The PC is accessing the net through a 1Mbps ADSL connection. Page loading was quite fast (both thumbnails and comic pages), never more than a few seconds.

Then I tried on my phone (LG Nexus 4) using 3G. Pages were loaded even faster (which is logical, the 3G I get is usually faster than my land line).

That means I still don't have any idea why you have this slowness problem, unfortunately. :(

If I improve and extend customization possibilities someday (not at the top of the list yet), I'll probably use HTML templating for all pages (using something like mustache).

This would allow total control over all pages type.

Well for starter, except in a few unfortunate cases (when PDF comics are not simple images), the current way of reading PDF comics is working quite well. Given the little time I have to work on Ubooquity, I have to choose between having one feature working for 100% of cases, or two features working for 90% of the cases.

It's common in software development to choose the second option, as you can easily spend insane amount of time trying to make your software work in every situation.

The second, and perhaps more valid reason, is that I'm not sure that PDF.js will allow me to control content streaming page by page, meaning the full document would be downloaded in the end (provided you don't stop reading) whereas the current reader only downloads what's needed when you display a page.

I have yet to start working with PDF.js and understand how streaming would work exactly. So this is not a definitive no, but for now I plan to stay with the current comic reader.

The only other idea I have would be directory permission. Is the working directory of Ubooquity writable ? It needs to be as Ubooquity creates a few files.

This scenario is not consistent with what you described as Ubooquity seemed to work at some point, but you never know...

Ok, I understand better.

Had I to rewrite Ubooquity from scratch today, I would probably remove the distinction between comics and ebooks.

Ubooquity was first designed for comics only, the support for ebooks being added later. This resulted in different ways of storing metadata, and a kind of artificial distinction between both types (the PDF format being an exception, but it was painful to manage).

So unless I write a version 2.0 from scratch someday (not likely but not completely impossible either), I will probably keep things the way they are, sorry.

Why not.

Send me the URL, login and password at: tom at vaemendis dot net.