But that means you enabled stretching and made the stretch factor very enthusiastic. Why should any single image be excluded from such a setting?

Yes it will scale it up, but at least maintain the aspect ratio. I guess i could attack it from another angle. As to why though, it is the logo, it's like a coat of arms or a flag, it must be protected from sabotage or desecration ;)

the other not too intrusive way, would be to simply

  if self.image_file == "resources/koreader.png" then
      G_reader_settings:makeFalse("screensaver_stretch_images")
  end

but then that would mean people would lose their stretch preferences every time we land in fallback, otherwise a much more complex operation is needed. remembering what was what and whatnot.

Overnotreallyaproblemsolving and overengineering...
Anyway, don't solve a local problem by messing with, creating and restoring, a global setting.

How would you feel being at Stade de France, world cup final, France and Germany are even and there is 1 minute left on the clock, suddenly a penalty kick is awarded to France, the germans are about to lose, everyone in the grandstands stands up to chant and support the lucky shooter, suddenly someone starts waving a flag, and every one starts going, mmm wtf is that? This particular flag is your usual three stripe design but suddenly the white takes up half the area and both blue and read are just 1/4 each. Madness.

I could just do this, right? now it won't scale up and no need to bother remembering anything, huh

scale_factor = (self.image_file == "resources/koreader.png") and 1 or (G_reader_settings:isFalse("screensaver_stretch_images") and 0 or nil),

How would you feel

I would have a laugh and my day made :) No need to release a bazooka to remove that flag, that nobody will see as they are watching the game and have setup some images so no fallback image is ever seen.

I could just do this, right?

Of course. You could even have it clearer by doing it when you decide the image, and storing the scale_factor to use as self.scale_factor and use it later in the widget setup. That way, all the logic is local to a few lines around where the image is decided.

How would you feel being at Stade de France, world cup final, France and Germany are even and there is 1 minute left on the clock, suddenly a penalty kick is awarded to France, the germans are about to lose, everyone in the grandstands stands up to chant and support the lucky shooter, suddenly someone starts waving a flag, and every one starts going, mmm wtf is that? This particular flag is your usual three stripe design but suddenly the white takes up half the area and both blue and read are just 1/4 each. Madness.

That roughly describes why I personally would have never added that setting, but the fact remains that people who enable that setting want to see that.

There's no problem to solve here.

I prefer stretching the book covers because the pillar boxing looks far worse to me. That said, I absolutely don’t want to stretch the fallback—it goes against a user’s expectations and looks ridiculous. While I agree that it’s rarely seen, the point is that if someone does encounter it, it should appear in its full glory, not in some distorted form.

It’s not really a problem per se; it’s about attention to detail. ;)

I don't see how it's attention to detail to ignore the user's choice.

There seems to be an actual bug here, however. The image is 600×600, but by the time it reaches the function enforcing the maximum ratio deviation it already seems to be registering as fullscreen, meaning that it'll be stretched, even though the ratio should be 1 rather than 0.75. So it's not actually the case that you set it to 15% or more.

@poire-z @NiLuJe The problem is resolved when doing this, but I assume simply removing that would have rather horrible consequences. You then need to set the stretch limit to a value higher than 33.33…% (while the UI apparently doesn't even allow a value higher than 25%) to see the effect in the OP, which is what I had assumed to be the case there.

diff --git a/frontend/ui/widget/imagewidget.lua b/frontend/ui/widget/imagewidget.lua
index b32284597..d9b76eee5 100644
--- a/frontend/ui/widget/imagewidget.lua
+++ b/frontend/ui/widget/imagewidget.lua
@@ -140,10 +140,10 @@ function ImageWidget:_loadfile()
         -- and use them in cache hash, when self.scale_factor is nil, when we are sure
         -- we don't need to keep aspect ratio.
         local width, height
-        if self.scale_factor == nil then
-            width = self.width
-            height = self.height
-        end
+        -- if self.scale_factor == nil then
+        --     width = self.width
+        --     height = self.height
+        -- end
         local hash = "image|"..self.file.."|"..tostring(width).."|"..tostring(height).."|"..(self.alpha and "alpha" or "flat")
         -- Do the scaling for DPI here, so it can be cached and not re-done
         -- each time in _render() (but not if scale_factor, to avoid double scaling)

After a quick reading (can't do more), I can't understand what you say the bug is.
Is it really not what is written on the tin?:

If the docs or the steps are not natural, it may be because ImageWidget had been evolving as we needed stuff, so it may not all be logical, but I guess it works fine with all the many use cases we modified it for.

self.width and self.height are identical to the screen size. Passing those values in to the image in advance means it's prestretched.

Bug or no bug. Nobody is intentionally setting their book covers to stretch with the expectation of getting a K and an O that look like they are being swallowed up by a black hole. I maintain that users who get to see this logo, should not be subjected to that monstrosity.

If you set the value to 34% that's exactly what you're asking for, otherwise you wouldn't set it to 34%. Our opinion on the result is of no import. The bug is that you set it to stretch up to a maximum of some value far below that and you got 33.3%. Which is actually not even attainable through the UI, since it apparently enforces a limit of 25%.

I have reached the same conclusion as @Frenzie, that means we are both right. Me in thinking that the "monstrosity" is unacceptable and you in pointing out that there is in fact a bug and it shouldn't happen in the first place (although you are wrong in thinking that it is acceptable to stretch a logo like that ;) alas)

for ANY file we provide with any stretching value (even 1%), the same occurs, the resolution of the file is set to that of the device, effectively, pre-stretching (or shrinking) before getting on to the stretching part. And at the user chosen stretching we should skip it given the 33.3% vs 25% max we have set.

I'm a bit rusty re: this codepath, but isn't the obvious solution to stop passing width & height when stretching is enabled?

Nothing is "passed". This is just what happens.

Unless you mean to the ImageWidget, but it couldn't scale if it didn't know the desired dimensions.

But I guess I'm trying to say I only want to tear that all out and burn it for good measure.

it shouldn't happen in the first place (although you are wrong in thinking that it is acceptable to stretch a logo like that ;)

Basically, don't tempt me.

Unless you mean to the ImageWidget, but it couldn't scale if it didn't know the desired dimensions.

In fact it doesn't work period without a width and height.

Unless you mean to the ImageWidget, but it couldn't scale if it didn't know the desired dimensions.

In fact it doesn't work period without a width and height.

Oh, right, duh'.

TL;DR: Stretching is inherently broken?

Well, it didn't used to be. :-) I'll try to look at the history later, maybe it'll simply stand out.

Edit: probably https://github.com/koreader/koreader/commits/master/frontend/ui/widget/imagewidget.lua

Define your timeframe, if i remember correctly, this has been the case for a while now. I think might predate me even.

The timeframe is 2022.01 to present.

Neither the screensaver nor the ImageWidget code seems to have been changed in a way that should matter.

This works, but I'm not sure if it makes sense.

diff --git a/frontend/ui/widget/imagewidget.lua b/frontend/ui/widget/imagewidget.lua
index b32284597..4cb51e860 100644
--- a/frontend/ui/widget/imagewidget.lua
+++ b/frontend/ui/widget/imagewidget.lua
@@ -140,7 +140,7 @@ function ImageWidget:_loadfile()
         -- and use them in cache hash, when self.scale_factor is nil, when we are sure
         -- we don't need to keep aspect ratio.
         local width, height
-        if self.scale_factor == nil then
+        if self.scale_factor == nil and self.stretch_limit_percentage == nil then
             width = self.width
             height = self.height
         end

would still stretch under "Full stretch" though

Don't click on full stretch then.

Screensaver related: change koreader’s language to anything other than English, go to edit sleep screen message, the whole text there is not translated ever.

It works fine in those languages into which it's been fully translated, including German, Greek, Galician, Hebrew, Hungarian, Italian, Korean, Polish, and a few more. Many others haven't been updated yet with the recent addition of %B at the bottom.

Edit: also see over on https://hosted.weblate.org/projects/koreader/koreader/

It wasn't a random change, you know why i added it, i just didn't want to open another PR just with that. I also see you didn't see reason ;) stretching logos is bad.