Created attachment 194876 [details] Sample slide (PPTX) This is a regression in Version: 24.8.0.0.beta1+ (X86_64) / LibreOffice Community Build ID: 0f06d45cd69b17583ca5e601ecb8fb3342f37501 CPU threads: 12; OS: Linux 6.9; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US and Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 151d997365f7bf271d63af535d29a9c3439c6d46 CPU threads: 12; OS: Linux 6.9; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Still fine: Version: 24.2.4.0.0+ (X86_64) / LibreOffice Community Build ID: 2dd760424554d597eb93fb6bc96ffddc9c5f1b18 CPU threads: 12; OS: Linux 6.9; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US (Personal note: bsc#1170874 has the full document.)
Created attachment 194877 [details] Visual comparison: PowerPoint (top) - Impress (bottom)
Confirm Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 151d997365f7bf271d63af535d29a9c3439c6d46 CPU threads: 8; OS: macOS 14.3; UI render: Skia/Raster; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded
Regression is from the following commit, bibisected using repo bibisect-win64-24.8. Adding CC: to Attila Szűcs. https://git.libreoffice.org/core/+/c30c1d12f283e75fdcc5bb508a79a9d33a431d28%5E! Author: Attila Szűcs <attila.szucs@collabora.com> AuthorDate: Mon Jun 3 22:08:42 2024 +0200 Commit: Caolán McNamara <caolan.mcnamara@collabora.com> CommitDate: Thu Jun 6 10:03:14 2024 +0200 tdf#153008 svx: impl crop for stretched bitmap fill
Adding Caolán, as committer of the patch identified to trigger the regression.
@Miklos, I thought you might be interested in this issue
Created attachment 196230 [details] Sample document with right and wrong behaviour It seems if the same Offset (left, right, top and bottom ) is set, then it works correctly. Otherwise it fails
*** Bug 162213 has been marked as a duplicate of this bug. ***
Created attachment 196234 [details] Sample document with right and wrong behaviour
When all offsets values are the same then getStretch() returns false. So when it's true, then the calculation is done incorrectly in drawinglayer/source/attribute/sdrfillgraphicattribute.cxx.My feeling is that https://git.libreoffice.org/core/+/c30c1d12f283e75fdcc5bb508a79a9d33a431d28%5E%21 is not completed and works in the attachment from bug 153008 but not with other cases
(In reply to Xisco Faulí from comment #6) > It seems if the same Offset (left, right, top and bottom ) is set, then it > works correctly. Otherwise it fails Maybe then it would make sense to restrict the new behavior to just this case for now? Unless somebody has the time to debug & fix the root cause. Thanks.
*** Bug 162145 has been marked as a duplicate of this bug. ***
Reverting it for now: https://gerrit.libreoffice.org/c/core/+/172913 See my comment in https://bugs.documentfoundation.org/show_bug.cgi?id=153008#c16
attachment 184636 [details] from bug 153008 is another document affected. I've also created attachment 196251 [details] from bug 95165 with 10 different images where the issue is affected in some of them
Xisco Fauli committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/295e1039649de030babf3ac9235cc80f9b9ca33c tdf#161724: Revert "tdf#153008 svx: impl crop for stretched bitmap fill" It will be available in 25.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Thank you, Xisco! Nice to see this regression addressed. One question: Do we have testcases that'll trigger were anyone to revert the revert (i.e., reapply the original patch)? Having a safety net to catch this regression automatically would be great.
Xisco Fauli committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/8ffcd108d6eb233130e7c740bea235b923a4883f tdf#161724: svx_unit: Add unittest It will be available in 25.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Gerald Pfeifer from comment #15) > Thank you, Xisco! Nice to see this regression addressed. > > > One question: Do we have testcases that'll trigger were anyone to > revert the revert (i.e., reapply the original patch)? > > Having a safety net to catch this regression automatically would be > great. See comment 16 ;-)
Xisco Fauli committed a patch related to this issue. It has been pushed to "libreoffice-24-8-1": https://git.libreoffice.org/core/commit/f8d50a8fa556c5bfb0d638117b8b0deafd433af5 tdf#161724: Revert "tdf#153008 svx: impl crop for stretched bitmap fill" It will be available in 24.8.1. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Xisco Fauli committed a patch related to this issue. It has been pushed to "libreoffice-24-8": https://git.libreoffice.org/core/commit/8fdb6449f9f991ae1eae4a5742081986014de7cd tdf#161724: Revert "tdf#153008 svx: impl crop for stretched bitmap fill" It will be available in 24.8.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Verified as fixed for example with today's daily build Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: e0a5b29f653a314727e23489a3e98daff8386ff6 CPU threads: 12; OS: Linux 6.10; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Thank you for tackling this, Xisco!
I write it here too Sorry for the regression, I really worked only on the 2. bug of that ticket... and that bug should be a separate bug from the 1. one.. i debugged what happening and it seems a bit worse i thought... the good vs bad xml: bad: <p:pic> <p:blipFill rotWithShape="1"> <a:srcRect l="44198" r="1196" b="-1"/> <a:stretch/> good: <p:sp> <p:spPr> <a:blipFill> <a:srcRect/> <a:stretch> <a:fillRect l="20048" t="23753" r="-40072" b="-2983"/> </a:stretch> This is the 2 very different case: <a:srcRect ..> <a:fillRect ..> And they both sent into PROP_GraphicCrop!! (it is not my patch it was like this from long ago) .. althought they are different kind of crops.. and i did not seen any property around it that would tell where it came from. In my patch, i implemented a missing crop like calculation ... but unfortunatelly it now executed on <a:srcRect ..> case as well, where it should not. So i think to fix it.. a) the 2 different crop like things should be separated.. they should be stored in 2 different property.. or b) at least, it would be good to have an additional property that show which crop is stored in PROP_GraphicCrop.. so i could choose to do my calculation or not...