Behaviour of "Fit image height to window" image resizing/fit setting in "Long Strip" mode :maybe:

Joined
Apr 19, 2018
Messages
1
When thinking about how the "Fit image height to window (if possible)" "Image fit" setting relates to the "Long strip" "Reader mode", it probably seems redundant, right? "Long strip" mode implies vertical scrolling, yet what is there to compare image height to if we don't care about the window height?

The way it behaves in "Long strip" mode is no different to how the "Fit image width to container" setting behaves in "Long strip" (as far as I can tell). Compare that to "Normal" "Reader mode" and it's a loss of a good feature. It should retain the same functionality in "Long strip" mode as it does with "Normal" "Reader mode", just without the vertical bounds checks! Specifically, that leaves the ((ImageHeight < WindowHeight)==true) behaviour where resizing doesn't need to occur, and how it affects images with horizontal orientation (i.e. "landscape mode") that exceed the the window width. I'll explain further below.

Just to recap how the different "Image fit" settings (appear to) function when "Reader mode" is set to "Normal":-

[ul][/ul]"Fit image width to container" : Resize image if its horizontal resolution exceeds the generated 'container' width for the window (the chapter/page 'toggle panel' fits this same width). The user will have to vertically scroll if the vertical length of the page 'body' (holding the 'top navbar' + 'toggle' panel + 'image') exceeds the window height.

[ul][/ul]"Fit image width to window (if possible)" : Same as above, except the check is done against the width of a region that's slightly smaller than the page 'body' and browser window. Vertical scroll behaviour same as before.

[ul][/ul]"Fit image height to window (if possible)" : Same as above, except it's checking against the height of the region within the page 'body'. In much the same way as before, the user will have to horizontally scroll if the horizontal image resolution exceeds the width of that a selected region.

As mentioned at the start, in "Long strip" mode we don't need checks against vertical bounds for resizing - those vertical checks are redundant as scrolling vertically is an explicit feature of "long strip" mode. The only time resizing on height should occur will be the direct result of resizing width whilst maintaining the image's aspect ratio.

How should those 3 "Image fit" functions behave in "long strip" mode then?

"Fit image width to container" : Resizing based on container width only. Should be no different to before, appears to function correctly already.

"Fit image width to window (if possible)" : Again, should be no different to before, and currently seems to function correctly too.

"Fit image height to window (if possible)" : The vertical scrolling that this mode previously aimed to prevent is now the main feature of "Long strip". What to do then? Ignoring vertical resizing and going back to "Reader mode" set to "Normal", we should still find horizontally scrolling is required if the image width exceeds that region within of the page. However, that isn't the case - this mode appears to function no different to "Fit image width to container". The end result is that there is no way to completely avoid the resizing of some large horizontally-oriented images when in "Long strip" mode (or where the browser window is used on monitors rotated 90 degrees), no matter what "Image fit" setting is chosen.

This doesn't seem to be a problem with mobile devices, as I believe images are resized locally, so zooming with touch allows the scaling to adjust dynamically. The high frequency detail within the image that was seemingly lost when downsampling to a lower resolution area can be displayed fast and easily with a quick zoom. Zooming in with browsers on desktops often messes up website layouts though, mangadex included.

The best choice would be to preserve the original behaviour of "Fit image height to window" in "Normal mode", just without vertical resizing. Effectively it will become a no resizing mode, which in itself is probably desired by some (kissmanga folks, dynasty-scans, etc).
 
Custom title
Staff
Developer
Joined
Jan 19, 2018
Messages
2,463
Well this word salad was a bit of a challenge to parse but

There's going to be an explicit no resize mode in the new reader
 
Instrumentality Instigator
Staff
Super Moderator
Joined
Jan 29, 2018
Messages
1,343
I uh, I don't really understand this myself so I'm going to err on the side of caution and put this down as a Maybe. Teasday is currently developing a reader that may meet your standards.
 

Users who are viewing this thread

Top