Hi, today, I noticed a regression of Calc, that I'm using a lot: With Calc 5.0.6.8, it was possible to select a couple of cells and copy them to the clipboard. Pasting that in another app (e.g. Gimp) was possible, since LO copied an image to the clipboard. With Calc 6.2.2.2 from openSUSE Tumbleweed, it only copies some html artefacts. The former behavior is preferred here, as I use it to paste parts of a sheet into mails, that appear with all formatting to the receiver. The html pastes isn't an adequate replacement. At least, LO should optionally provide those images..
Hello Hans-Peter, Thank you for reporting the bug. Unfortunately I can't reproduce in Version: 6.3.0.0.alpha0+ Build ID: 98630a0bd49bd80652145a21e4e0d0ded792b36b CPU threads: 4; OS: Linux 4.4; UI render: default; VCL: gtk3; TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2019-05-04_04:44:35 Locale: en-US (tr_TR.UTF-8); UI-Language: en-US Calc: threaded Could you please try to reproduce it with a master build from https://www.libreoffice.org/download/appimage/ ? You can install it alongside the standard version. I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the master build You can always visit our QA channel #libreoffice-qa@freenode if you need help with bugs https://irc.documentfoundation.org/?settings=#libreoffice-qa
Hi Usama, thanks for testing. AppImages are really cool. I did, what you asked for. The described behaviour happens with this AppImage as well: Version: 6.2.3.2 Build-ID: aecc05fe267cc68dde00352a451aa867b3b546ac CPU-Threads: 8; BS: Linux 5.1; UI-Render: Standard; VCL: kde5; Gebietsschema: de-DE (de_DE.UTF-8); UI-Sprache: de-DE Calc: CL and differs from this version: Testing with: Version: 6.3.0.0.alpha1+ Build ID: b26b6cab5d8147d35f76a21c333719c80840d08d CPU threads: 8; OS: Linux 5.1; UI render: default; VCL: kde5; TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2019-05-20_23:15:15 Locale: de-DE (de_DE.UTF-8); UI-Language: en-US Calc: CL Gimp cannot find anything to paste in the clipboard with the former, but pastes the selection as image with the latter just fine. So, this is an issue with 6.2.3.2, that was solved with 6.3.0.0. Unfortunately, this testing revealed another difference in behavior, with kmail, that I'm describing here for completeness: kmail still prefers to paste the html clip with 6.3.0.0, which is a regression in kmail (KF5) as well. Pasting with <Shift> keeps the table structure at least, but omits the html borders. Not sure, if LO delivers the table borders in the html clip, which would be the ideal solution, since I've pasted images, because it preserves the look of the selection, including borders, fonts, sizes... With an improved paste as html table format, that should include the borders at least, we would be on par with Windows (Office -> Outlook) in this regard.
(In reply to Hans-Peter Jansen from comment #2) > Unfortunately, this testing revealed another difference in behavior, with > kmail, that I'm describing here for completeness: > > kmail still prefers to paste the html clip with 6.3.0.0, which is a > regression in kmail (KF5) as well. Pasting with <Shift> keeps the table > structure at least, but omits the html borders. Not sure, if LO delivers the > table borders in the html clip, which would be the ideal solution, since > I've pasted images, because it preserves the look of the selection, > including borders, fonts, sizes... > > With an improved paste as html table format, that should include the borders > at least, we would be on par with Windows (Office -> Outlook) in this regard. Hans-Peter: can you be clear what it is you are describing here? Is there an issue with LibreOffice? Or only with kmail? If there is an issue with LibreOffice, please describe the current behaviour and expected behaviour in a clear, separated way.
Hi Buovjaga, concerning this issue: > So, this is an issue with 6.2.3.2, that was solved with 6.3.0.0. Further investigation revealed, that 6.3.0.0 is a model student in this regard. Make a Calc selection. Examine the available formats: $ xclip -selection clipboard -t TARGETS -o text/html application/x-qt-image text/plain UTF8_STRING STRING TEXT application/x-libreoffice-clipboard-uuid image/png image/bmp image/bw image/cur image/icns image/ico image/jp2 image/jpeg image/jpg image/pbm BITMAP image/pcx image/pgm image/pic image/ppm PIXMAP image/rgb image/rgba image/sgi image/tga image/tif image/tiff image/wbmp image/webp image/xbm image/xpm TARGETS MULTIPLE TIMESTAMP SAVE_TARGETS Save html selection: $ xclip -selection clipboard -t text/html -o > test.html Save png selection: $ xclip -selection clipboard -t image/png -o > test.png Checking test.{html,png}. All is well. 6.2.3.2 isn't that perfect: Make a Calc selection. What's available? $ xclip -selection clipboard -t TARGETS -o text/html text/plain UTF8_STRING STRING TEXT application/x-libreoffice-clipboard-uuid TARGETS MULTIPLE TIMESTAMP SAVE_TARGETS Compare to 6.3.0.0. As said in the report, it's missing any images and much more from the available formats of 6.3.0.0. All tests were done with the upstream AppImages (documented in https://bugs.documentfoundation.org/show_bug.cgi?id=125053#c2), as well as the openSUSE Tumbleweed provided build: Version: 6.2.3.2 Build-ID: 20(Build:2) CPU-Threads: 8; BS: Linux 5.1; UI-Render: Standard; VCL: kde5; Gebietsschema: de-DE (de_DE.UTF-8); UI-Sprache: de-DE Calc: threaded with similar results. Should I close this bug, or is there any possibility, that somebody wants to fix this misbehaviour in the 6.2 series (which would be great)?
Ok, then let's close as WFM. 6.2.4 is out already. If 6.2.4 does not have the fix, you might do this: https://wiki.documentfoundation.org/QA/Bibisect#Finding_a_fix For the repo you would use bibisect-linux-64-6.3 from https://wiki.documentfoundation.org/QA/Bibisect/Linux#Versions