User tests: Successful: Unsuccessful:
If you for example create thumbnails from a JPG and use the method SCALE_FIT
the "new" areas will be black.
After this fix, they will be white.
Test: take an image (JPG) with a 1:2 ratio (e.g. 200x400px) and the following code:
$jimage = new JImage($path_to_file);
$jimage->createThumbs(array(200 . 'x' . 200, JImage::SCALE_FIT);
Before patch => the area around the images are black
After patch => the area around the images are white
Status | New | ⇒ | Pending |
Labels |
Added:
?
|
But doesn't thus change the existing behaviour in a way that breaks
backwards compatibility. Thumbnails created before this are black and after
are white.
On 6 Sep 2015 10:28 pm, "chmst" notifications@github.com wrote:
@test https://github.com/test - works as described
—
Reply to this email directly or view it on GitHub
#7830 (comment).
Hello,
that depends, every bugfix changes a behavior. When I have an image which I scale with "max fit", I do not expect black areas.
The handling itself is a bit strange here, because it adds a (pseudo) transparency to every image, which has no transparency.
But in general I would say: yes it changes a behavior, but only because the current result is not the expected result (= bugfix)
@bembelimen in theory you can try add some option for set the background color, with default is "black"...
This will keep old behavior and still allow to change the color
in theory
Hello Fedik,
I thought that, too, but if you use a no-transparency images (like JPG) Joomla! defines "black" as value (hardcode), (see the the line I changed). I didn't find a way to change that with a parameter or a image setting.
A change in behaviour is not acceptable because it breaks BC.Only when fixing bugs a possible change would be acceptable. It doesn't qualify as a break in BC anymore in those cases.This does mean that the finding is agreed upon as a bug and the fix agreed upon to be the right thing to do.The bugfix only corrects the code to do the right thing. It depends on the nature of the bug whether the fix includes code to deal with the erroneous objects created by the bug. It is common to provide migration instructions for existing environment.
To me that leaves these questions:
Category | ⇒ | Libraries |
Status | Pending | ⇒ | Needs Review |
Moving to Needs Review
so a PLT Member can take the decision. Thanks.
Hello,
I would like to bring this topic up since we're at the same point in our development and being able to pass a parameter and / or at least have it default to white would be a big help. I can see that "me" saying "white" and the next person saying "green" could lead to an avoidable debate.
Any chance a refactoring towards using parameters could be accepted?
Status | Needs Review | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2016-05-07 11:58:09 |
Closed_By | ⇒ | roland-d |
So we should not change the hard-coded color value however there is a new PR #10268 that adds parameters to JImage that can be used to specify which fill color to use. That would resolve this issue as well.
Thank you all for contributing. I am closing this in favor of #10268, please test the issue so it can get merged.
@test - works as described