Description: SVG image pasted with RTF paste looks off Steps to Reproduce: 1. Open the attached file 2. CTRL+A 3. CTRL+X 4. CTRL+SHIFT+V RTF paste Actual Results: Low quality image. Not surprising.. as kind of a known flaw (see bmp/gdi paste). However it looks it is taking a different route (from bmp/gdi). So this implementation likely a taking a different route. So more 'additional' reminder to check.. Expected Results: A high res clear image Reproducible: Always User Profile Reset: No Additional Info: Version: 7.2.0.0.alpha0+ (x64) Build ID: 315c7570c4a72f4c834086082825533b1e50d1bf CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL
Created attachment 168346 [details] Example file
I confirm it with Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 949658028e722e5d2657b503eb20e16e41dbd8cf CPU threads: 4; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL
This is interesting, because the results are different in Linux with GTK3 VCL plugin, and with gen VCL plugin. With gtk3 the image looks inverted, and with gen the colors are fine, but the quality is bad (it's probably bad in the other case, too). It also isn't an RTF paste bug, after exporting to RTF and reloading the document, the image exhibits the same quality loss. When using RTF export/import, the issue started in 4.1.0.4, and could be bibisected to the following range for when the inverted image started, using bibisect-41max: https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=5bdba378d6fc9f18f618967ec37d07efed2afee4..f47c3906ee0fc35f4b219fb24a0e270956821369 Suspecting the following commit (uneducated guess): https://cgit.freedesktop.org/libreoffice/core/commit/?id=4fa8df7320f6bdc8333f5936537d2ed93e8892ce author Armin Le Grand <alg@apache.org> 2012-06-11 08:38:23 +0000 committer Caolán McNamara <caolanm@redhat.com> 2013-04-14 21:33:59 +0100 "Resolves: #i119735# missing css.svg.SVGWriter when using GraphicProvider" Before that, the quality loss started with the following commit, same as in bug 138653: https://cgit.freedesktop.org/libreoffice/core/commit/?id=a1a0830d1ac3ffabbe35bd8a0264b64f1f7a9d67 author Armin Le Grand <alg@apache.org> 2012-05-30 13:44:19 +0000 committer Caolán McNamara <caolanm@redhat.com> 2013-03-16 01:57:53 +0000 "Resolves: #i119601# support for transparency in PNG export dialog" Much later, the commit that fixed the inverted color with both VCL plugins was the following (though the background color is slightly different), bibisected using bibisect-linux-64-6.0: https://cgit.freedesktop.org/libreoffice/core/commit/?id=ebc11ae0b132eefd3b1b1a837a8d0ad3ba73b460 author Thorsten Behrens <Thorsten.Behrens@CIB.de> 2017-08-21 22:44:30 +0200 committer Thorsten Behrens <Thorsten.Behrens@CIB.de> 2017-08-22 12:28:57 +0200 "emfplus: cut over to new EMF+ renderer" Then the following commit brought back the inverted colors with gtk3 VCL plugin, in the same version/repo: https://cgit.freedesktop.org/libreoffice/core/commit/?id=3cb59bff332b02f607d15b5ed41b4438e8102980 author Caolán McNamara <caolanm@redhat.com> 2017-09-04 13:34:09 +0100 committer Caolán McNamara <caolanm@redhat.com> 2017-09-04 17:22:27 +0200 "Resolves: tdf#111483 1 bit bitmaps with non-standard black/white indexes"
Dear Telesto, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Still present in Version: 7.6.0.2 (X86_64) / LibreOffice Community Build ID: 41d6f628ba3f046f16b5fa9fa8db8d4c2ab3b582 CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL threaded Caolán, perhaps you can have a look at it, thank you.
Same black instead of transparency issue in recent trunk build. Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 31fb3045dabdb27d913712f3abcade315e3ea9bd CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Properties show the image is pasted as WMF. Which makes me think bug 126876 comment 4 is the same issue.