Created attachment 189054 [details] Sample slide (PPTX) 1. Open sample presentation/slide 2. Observe how the arrow in the background image vertically fits in between the two horizontal yellow lines when in edit mode. (This is also how PowerPoint renders it.) 3. Enter presentation mode. 4. Note how the arrow now has shifted down. Versions of LibreOffice prior to 7.6 did not render the background properly in edit mode to begin with, though at least edit mode and presentation mode were consistent. Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 91358f11ee7e87c8c8290b9507f64d8f90aac3ea CPU threads: 8; OS: Linux 6.4; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US
Created attachment 189055 [details] How it looks incorrectly in presentation mode - the arrow should be between the yellow lines
The image renders at the correct position in Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 953e586dbce1c3195ecb07b2491b6e1a20a2cd7f CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: de-DE (en_US); UI: en-US Calc: CL threaded
And is OK too in Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 91358f11ee7e87c8c8290b9507f64d8f90aac3ea CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded and OK with disabled Skia: Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 91358f11ee7e87c8c8290b9507f64d8f90aac3ea CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: default; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded Linux specific?
Repro in current master: Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 34d32740d89876c3d4fd2743a07d6e2578601683 CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: hu-HU (hu_HU.UTF-8); UI: en-US Calc: threaded
(In reply to Gabor Kelemen (allotropia) from comment #4) > Repro in current master: > : > ... Linux 5.4 ... Thank you, Gabor and Regina! I'm glad this bug wasn't just in my had. :-) Is this really Linux- specific, since you reproduced it on Linux, Gabor? Or is it possible - and sorry for even considering this option! - you did not try in presentation mode, just edit mode (where it looks alright), Regina?
Created attachment 189080 [details] Screenshot on Windows 10 (In reply to Gerald Pfeifer from comment #5) > Or is it possible > - and sorry for even considering this option! - you did not try in > presentation mode, just edit mode (where it looks alright), Regina? Attached is a screenshot made during slideshow. The source pptx file has a negative top and bottom offset of -9% in the UI. That corresponds to <a:fillRect t=-9000 b-9000> in markup in file. Might it be that this is handled different by gtk3 on Linux than by the renderers on Windows?
Bibisected in 7.6 to: https://git.libreoffice.org/core/+/a41dbf0bd726613204d975fb4fc5e50c23d61410 author Tibor Nagy <nagy.tibor2@nisz.hu> Wed Mar 08 16:26:10 2023 +0100 committer László Németh <nemeth@numbertext.org> Mon Mar 27 08:32:50 2023 +0000 tree d72fcae7802892414bb95f2a96777f765c650041 parent 31690100461d42fd93b9a1a6546b1e17a8d31720 [diff] tdf#153466 PPTX import: fix "Custom position/size" background image Adding CC to: Tibor Nagy Althogh this maybe something deeper, I see it bad under Linux, but good under Windows.
(In reply to Regina Henschel from comment #6) > Might it be that this is handled different by gtk3 on Linux than by the > renderers on Windows? It is bad under Linux with GTK and gen backends, but NOT with qt5.
Correction: it WAS good with qt5 at the above bibisected commit. Short time later it also broke, with: https://git.libreoffice.org/core/+/14fe410e0ab90e95141613b77de48063f518d9bb author Khaled Hosny <khaled@libreoffice.org> Sat Jul 08 22:42:12 2023 +0300 committer Michael Weghorn <m.weghorn@posteo.de> Mon Jul 10 07:37:25 2023 +0200 tdf#151273, tdf#151925: Don’t use QFont text layout by default Adding CC to: Khaled Hosny
I don’t see how my change has any relation to the bug here, it simply prevents people from shooting themselves in the foot using broken font backend (also the qt5 backend is not supposed to be used for anything, though people do use it, you should be testing kf5/kf6 plugins).
Sarper Akdemir committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/84055d875ead6d7862cd8ddc5697a280240411fe tdf#156830: fix faulty transformation order in cairo canvas for patterns 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.
Happy to confirm this has been addressed in my original test environment with Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 877014b0b7050ba3fce1c0126279125640117313 CPU threads: 12; OS: Linux 6.6; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Xisco, do you think this can be test cased? Would be great to help avoid such regressions...
Sarper Akdemir committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/3add4092d29b9b03c00dfa24caa917a3fc84540b tdf#156830: fix faulty transformation order in cairo canvas for patterns It will be available in 24.2.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 159622 has been marked as a duplicate of this bug. ***
Sarper, thanks for the fix! Any reason this wasn't cherrypicked to 7.6?
(In reply to Stéphane Guillou (stragu) from comment #15) > Sarper, thanks for the fix! > Any reason this wasn't cherrypicked to 7.6? Done -> https://gerrit.libreoffice.org/c/core/+/163972
(In reply to Stéphane Guillou (stragu) from comment #15) > Sarper, thanks for the fix! > Any reason this wasn't cherrypicked to 7.6? Not really Stéphane, just forgot to do that :) (In reply to Xisco Faulí from comment #16) > Done -> https://gerrit.libreoffice.org/c/core/+/163972 Thanks Xisco!
Thank you both!
Sarper Akdemir committed a patch related to this issue. It has been pushed to "libreoffice-7-6": https://git.libreoffice.org/core/commit/a2c0ab909195c803401cc710985f19723680e0eb tdf#156830: fix faulty transformation order in cairo canvas for patterns It will be available in 7.6.6. 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.