Created attachment 184636 [details] Sample slide (PPTX) This sample slide has three images that are clipped (against a shape). When opened in Impress all three appear horizontally compressed. This may or may not be related to bug#147704 FILEOPEN PPTX: image appears vertically compressed (by a factor of two) bug#138455 - FILEOPEN DOCX OLE objects replacement image horizontally shrunk Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 5b3fd1af1247d4096451e5a768c3438fbccec2b2 CPU threads: 8; OS: Linux 6.0; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US and all the way back to LibreOffice 7.1 LibreOffice 7.0 does *not* exhibit this horizontal crush, but also do not do the clipping against a shape. I guess this speaks to an implementation error in the clipping functionality.
Created attachment 184639 [details] Visual comparison Impress (left) vs PowerPoint (right)
Confirmed using LO 7.6.0.0.alpha0+ (d993327eab0a2c9c8820c6528075b01de68b0ec6) / Ubuntu. The mentioned change comes from bug 140714 's fix, as found by reverse bibisecting it.
https://gerrit.libreoffice.org/c/core/+/155717
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/6c06c8a2be3d8cbbcb8ab1aaaeb04db95114dfcb tdf#153008: srcRect may have some members negative It will be available in 24.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.
Thanks, Mike and Gerald. Verified with Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 6c06c8a2be3d8cbbcb8ab1aaaeb04db95114dfcb CPU threads: 16; OS: Linux 6.2; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded Was bad in (for comparison) Version: 7.5.3.2 (X86_64) / LibreOffice Community Build ID: 9f56dff12ba03b9acd7730a5a481eea045e468f3 CPU threads: 16; OS: Linux 6.2; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-7-6": https://git.libreoffice.org/core/commit/dd1f530bf7ab50f7b45bea5413c2328c7ecc5ed6 tdf#153008: srcRect may have some members negative It will be available in 7.6.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.
*** Bug 156663 has been marked as a duplicate of this bug. ***
I also have this problem as I reported under bug#134210 Comment 3 of 2020-09-03 22:52:43 UTC. Now running Version: 7.5.3.2 (X86_64) / LibreOffice Community Build ID: 9f56dff12ba03b9acd7730a5a481eea045e468f3 CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: en-GB (en_GB); UI: en-GB Calc: threaded Will try daily build when I get chance
Created attachment 189099 [details] My Sample PPTX file with problem Apart from 3 original slides ith problem, also 2 slides with shape moved to centre of slide (also have problem), and a couple with just the base images (no crop or shape)
Created attachment 189100 [details] PDF of My Sample produced from Powerpoint Viewer, showing what I expect
I have now tried with daily build (downloaded 2023-08-19 17:32 UK time), still have problem - I have uploaded my sample PPTX file, also a PDF produced via PowerPoint Viewer to show what I expect. Info re daily build: Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 34d32740d89876c3d4fd2743a07d6e2578601683 CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: en-GB (en_GB); UI: en-GB Calc: threaded
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/367ba88092fbc0ba06a7f77157cd012ff0fe3caf Related: tdf#153008 bump XFillBmpPosOffsetXItem to sal_Int32 It will be available in 24.8.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.
Attila Szűcs committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/c30c1d12f283e75fdcc5bb508a79a9d33a431d28 tdf#153008 svx: impl crop for stretched bitmap fill It will be available in 24.8.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 Commit Notification from comment #13) > Attila Szűcs committed a patch related to this issue. > It has been pushed to "master": > > https://git.libreoffice.org/core/commit/ > c30c1d12f283e75fdcc5bb508a79a9d33a431d28 > > tdf#153008 svx: impl crop for stretched bitmap fill > > It will be available in 24.8.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. This patch even makes the original report to be displayed incorrectly...
Created attachment 196248 [details] Original sample file in LibreOffice 25.2 master vs PP 2016
I don't know why but c30c1d12f283e75fdcc5bb508a79a9d33a431d28 was supposed to fix 95165 and not this issue. This issue was already fixed by 6c06c8a2be3d8cbbcb8ab1aaaeb04db95114dfcb. I don't know why this issue was mentioned in c30c1d12f283e75fdcc5bb508a79a9d33a431d28 but it broke the original report as mentioned before. I'm going to revert it for now, considering tdf#161724 and its duplicated. For further discussion, please use bug 95165. I uploaded attachment 196251 [details] with different images
Revert: https://gerrit.libreoffice.org/c/core/+/172913
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.
Reopening due to revert.
(In reply to Gabor Kelemen (allotropia) from comment #19) > Reopening due to revert. Err... but IIRC, the fix was in comment 4?
Yes, as the original reporter this was happily resolved for me - until the 2024-06-06 commit which came out of the blue a year later. So I would indeed close this as VERIFIED FIXED - latest after a test with the original test case.
(In reply to Gabor Kelemen (allotropia) from comment #19) > Reopening due to revert. 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.
(In reply to Gerald Pfeifer from comment #21) > Yes, as the original reporter this was happily resolved for me - until > the 2024-06-06 commit which came out of the blue a year later. Attila's commit from 2024-06-06 was supposed to fix Jeremy's case in attachment 189099 [details]. It's unfortunate the change caused the original sample to regress.
Sorry for the regression, I really worked only on the 2. bug of this 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...