Open seventyiris83 opened 1 month ago
Hi.
Yes, I will try to fix the actual resampling quality but note one thing.
The "lite" article viewer is technically VERY VERY limited in what it can do and what it can show. It is really really really rather text-based UI component and showing pictures, styling etc. is basic, very basic.
Well, I kind of have this:
So the thing is how precisely we want the "article height (or width??) limit" work. Do we want to avoid horizontal scrollbars at all cost? Do we even want to limit height of pictures? Or do we want to limit width of pictures?
* and at the same the the component does not support "max-height" or "max-width", it can only leave pictures as they are or you can set fixed dimensions via "CSS"
how did the previous behavior in no web engine version where pictures seemingly retained their "max" quality but still respected the height limit work? or am i mistaken and the quality was indeed altered to fit the limit?
in my mind images and attachements, granted they being high quality to begin with, always looked "max" quality in the article viewer and never had their quality decreased, only the size of images beyond the height limit you set was decreased to respect the limit, but still looked just as sharp
So the thing is how precisely we want the "article height (or width??) limit" work. Do we want to avoid horizontal scrollbars at all cost? Do we even want to limit height of pictures? Or do we want to limit width of pictures?
the height limit setting always respects the aspect ratio of images, isn't the limit limiting both height and width at the same time even if it's labeled as height limit only? i quite liked how it was before wrapping was introduced. i think we would indeed want to avoid horizontal scrollbars, i had and still have the height limit set to 350px for that exact reason, coupled with adjusting the size of the article viewer to tightly fit that limit results in me not seeing any horizontal bars in articles with images and attachements.
i would first have to know what exactly the no web engine behavior was, but i would suggest keeping the height limit setting as is, but:
The "lite" article viewer is technically VERY VERY limited in what it can do and what it can show. It is really really really rather text-based UI component and showing pictures, styling etc. is basic, very basic. it can only leave pictures as they are or you can set fixed dimensions via "CSS"
would that be possible? a hybrid between previous and current behaviors depending on if a height limit is set or not
you can download some previous versions and check with git where/when changes were made
i will try to simplify the overall workflow, but honestly the lite viewer is quite on its limits
So the thing is how precisely we want the "article height (or width??) limit" work. Do we want to avoid horizontal scrollbars at all cost? Do we even want to limit height of pictures? Or do we want to limit width of pictures?
i think this depends on what type of layout you have set. if you have the article viewer set horizontally, you'd want to limit the height, and if set vertically, width
maybe being able to select limiting either the height or width in the form of a dropdown menu? that would be another ticket though and a FR
you can download some previous versions and check with git where/when changes were made
i could be wrong here but i think this is where the change from previous behavior to current happened: https://github.com/martinrotter/rssguard/commit/b8f2295bc973269541b83aaa672bbd6552e72b83
overall i think dynamic wrapping should be left for the web engine version if it means keeping the original quality of images in lite version viewer. i think the previous behavior was better and would rather manually adjust the height limit of images manually when i change the article viewer window size instead of wrapping doing it for me at the cost of image quality
Brief description of the issue
when a height limit is applied to images in "Feeds & Articles -> Articles -> Limit height of all pictures", the image and attachement quality (not size) is directly tied to the size of the article previewer windowm which is unexpected behavior
when the article viewer window size is increased to the max, the image quality will be the highest it can be at the set height limit, and the more you decrease the article viewer size, the lower the quality of attachements and images get
here are comparison screenshots:
as highlighted in the first screenshot, when the article viewer window size is increased to the max, the quality of the images included in articles is also at max
in the second and third screenshots is the reason for this ticket, the quality of the images is decreased as the size of the article viewer window is decreased
it seems the wrapping logic is applied to the images even if they aren't being wrapped
it would be very nice if the previous behaviour (pre introduction of wrapping for lite version) could be re-instated when applying a height limit to images in articles (disabling wrapping), so it's always the original quality of the image being displayed with the image size capped to what the height limit is set to, regardless of the size of the article viewer window
How to reproduce the bug?
What was the expected result?
i was expecting the image/attachement quality to be at maximum regardless of the size of the article viewer window size
What actually happened?
the quality of the images/attachements are dependant on the article viewer window size
Debug log
N/A
Operating system and version