Improved comics reader

Hi! First of all, great application. I'm pleased to see that you intend to focus on perfecting the content delivery system rather than adding a bunch of unnecessary features. The comics reader is the best and simplest such utility that I've found.

Question regarding this particular feature: Do your plans for improving the comics reader include server-side image resizing, or is the "fit" function done by the client? I think the former would be a great way to improve loading speeds. If the admin panel had the option to specify a maximum size to send to the client, and could resize and cache the images in advance, it could result in a lot less data transferred and a much quicker, smoother experience.

Also, it would be really slick if a few pages could be preloaded to the client; two or three pages would be enough to eliminate the waiting for page loads entirely.

In fact the comic reader already reduces the image (and a little bit too aggressivly at the moment, due to a bug). The reading device sends the size of the screen and the server resizes the image before sending it over the network. The bug I was talking about limits the width of the page to 1200 pixels, but it will be fixed in 1.6.0.

As for the preloading, it is already done as well (only one page), although it is not working for all devices (for instance it doesn't work on iPad).

So the features are there but they need refining/fixing.
Next version will also contain a simplified screen for advanced preferences (simpler mostly for me) that will allow me to expose settings that I wouldn't have not exposed before for fear of overcomplexifying the interface.

That's understandable; it's always a good move to keep the interface relatively simple. I feel like "Advanced" tabs are always allowed to be more complex, though. ;-)

About the preloading: I think the first time I used the comic reader remotely (i.e., from outside my home LAN), I must have been experiencing some other performance issues. When I tried it again yesterday, flipping through a comic with very large images was quite fast and pleasant. So I have no problem there after all; very well done!

The resizing is not something I've noticed. In a maximized Firefox window (GNOME 2 on RHEL6) on a 1680x1050 screen, images were still taking up the entire width of the window. I'll check it out on my tablet later (generic Android with a Retina display) and see what happens there.

In any case, I think the fit options and the upcoming advanced settings sound like exactly what I'm looking for. I'll be looking forward to seeing those. Thanks for all of your time and effort, and keep up the great work!

Just tried opening a comic on my tablet in the default Android browser*, and got the same results as with FF. Image width is definitely not being limited. With the tablet in landscape (width of 2048), the width was fit to the screen. In portrait mode (1536, I think), I had to scroll horizontally. Chrome for Android also didn't hit the 1200px bug, but it did shrink to fit the screen width in both landscape and portrait. Does this bug only come up in certain situations?

I can post screenshots if you'd like to see anything.

* The default browser also has some issues with button placement on the Download/Read screen. It seems that the click regions are centered as they should be, but the pop-up menu is not. Not sure if that's something you can fix in layout or just a problem with the browser. Chrome didn't have that problem and displayed it just like the desktop version of Chrome.

Regarding performances, the current version has a bug heavily impacting reading performances when a scan is in progress. Perhaps that's why you experienced a problem.

I'll look closer at the code in charge of resizing the pages. You use Ubooquity 1.5.0, right ?

Regarding the button placement issue, I can't test it myself as the default Android browser does not exist anymore on devices running on recent Android versions (the official browser is now Chrome).
It could probably be fixed by generating better HTML/CSS than what I currently do, but if it only affects the default Android browser, I'd rather focus on other features.

Yes, that could have been why I saw the performance hit. I thought my initial scan was finished at the time, but I could be wrong.

Yes, I'm using 1.5.0. Thanks for checking on it.

Oh, I didn't realize the standard browser wasn't available. It's still on my tablets as well as my S4. No problem, I'll just use Chrome instead; just wanted to point it out.

Thanks for all your efforts! I've been enjoying the software immensely despite any bugs.

Hello, this comment also pertains to the comic reader. When the nav. interface comes up I am not able to exit it to go back to reading the comic. I am obviously doing something wrong yes? Could you point out how I can exit nav. mode and go back to reading mode? Thank you by the way, great app I just donated.

Cheers,
Timothy

Hello,
To hide the navigation you have to either:

• press "Enter", if you have a keyboard
• tap/click in the center/bottom area (the empty one)

Let me know if you still can't exit the navigation interface, as this might be a bug.

Thanks for your donation. :)

Fit to window would be a much appreciate feature.  I have giant screens all around (2560x1440) on desktop and phone, and I'm still sometimes too small or too big.

I don't know if server side image scaling is short term interesting though.

The current 1.7 version will not resize images to less than 1200 pixels wide. It does detect resolutions, but the minimum resolution it will stream a page to a client through the web interface is 1200 pixels.

True. That's because a lot of devices lie about their resolution. For instance an iPad will declare a width of 900px while its true width is 1536px. An image resized to 900px is ugly on such a screen. I chose 1200px as the minimum width to prevent resizing to too small a width.

Could that variable be exposed through the GUI?

If there has to be a minimum resolution set server-side, I agree that it should be adjustable. But I think it would be far more useful to adjust it client-side, to be as flexible for different viewer sizes as possible. I wonder, if it's just a matter of a value the browser is reporting, a quick-and-dirty addition might be doable with some basic PHP/CSS. Tom, any thoughts on that?

If you are using the browser viewer then JavaScript can detect the browser window size with:

var w = window.innerWidth, h = window.innerHeight;

I use this on a site I'm coding. You can even bind it to fire whenever the size is adjusted, like when the screen goes from potrait to landscape with jQuery:

$(window).resize(function() { $("#displaypage").width(window.innerWidth);
});

Thanks, that's good info. I was thinking along the lines of adding a small menu somewhere that would allow you to manually choose the size and override whatever resolution is reported. But it's been a long time since I dabbled in web design, so that'll be a great place to start. :-)

1200px is the width under which Ubooquity will not go when resizing images. If the image is already smaller, nothing happens.
For most comics, resizing to an even smaller width would not be really usefull as they quickly become to small to read.
This limit only exists because mobile device browsers lie about the real width of the window.

Did one of you already have a problem with the resolution of the image sent by Ubooquity ? (e.g. a blurry image)
I am not talking about the size of the image relative to the screen size (like when you want your image to take the full width of the screen even if the original image is smaller), this displayed size will be configurable in the reader (someday) with settings like "fit to width", "fit to height" or "100%".