Created attachment 167585 [details] Test ODS file Steps to Reproduce: 1. Open the attached ODS file; Select range A1:B18, ctrl+C. 2. Ctrl+Shift+V to Draw as GDI foramt. Current Result: Pasted GDI format gets cell styles reverted back to the default built-in cell styles in Calc. Expected Result: The styles as shown in the ODS file should be used. Those styles were edited with some customs attributes. Version: 7.1.0.0.beta1+ Build ID: f3e7e5a6aa4d3eafb584f5d22c1a31bb0a3dd496 CPU threads: 4; OS: Linux 5.9; UI render: default; VCL: gtk3 Locale: zh-CN (zh_CN.UTF-8); UI: zh-CN Calc: threaded See also bug 138505 which may be related.
Works OK in 2020-11-22 12:52:30 +0100 02195a17e88f668fce79937719215c6f5c318245 So it may be broken after the libreoffice-7-1 branch-off point.
Not reproduced in Version: 7.2.0.0.alpha0+ Build ID: f981f756e1509ac0a39cd618316cfe3befd5923a CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded nor in Version: 7.1.0.0.beta1+ Build ID: f3e7e5a6aa4d3eafb584f5d22c1a31bb0a3dd496 CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
I now realized and confirm that this bug appear only if I enable experimental feature.
Well, I am confused... Seems also not related to Experimental feature -- may be related to an additional template path... NEEDINFO from myself until I do more testing....
The expected behavior should be that the pasted image keeps the style as in Calc, i.e. consistent font size for western and Asian text, black text and white background, right? If I'm understanding that correctly, then I can reproduce with an old version of master (2020-11-12, pre 7-1 branching), regardless of experimental feature being on or off: Version: 7.1.0.0.alpha1+ (x64) Build ID: 693553210828538680408832157faad9654758c8 CPU threads: 2; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win Locale: zh-CN (zh_CN); UI: en-US Calc: threaded For me, the pasted GDI format image always reverts to the default style, with colored background and text, Chinese text smaller than English text for Heading and Heading 1, etc. Exeperimental feature turned on or off give the same result.
Created attachment 167603 [details] Comparison of Expected and Current Result PDF
Already broken in: 2019-11-13 16:51:24 +0100 9bc848cf0d301aa57eabcffa101a1cf87bad6470 Set to NEW per comment 5.
Hello Kevin, Ming, I'm confused at this point. Do you both reproduce what it shown in the comparison image ?
(In reply to Xisco Faulí from comment #8) > Hello Kevin, Ming, > I'm confused at this point. Do you both reproduce what it shown in the > comparison image ? Yes, actually, I can always reproduce the "current result" on the right in Kevin's PDF, when paste as GDI. Not only in master, but also in 6.4.7: Version: 6.4.7.2 (x64) Build ID: 639b8ac485750d5696d7590a72ef1b496725cfb5 CPU threads: 2; OS: Windows 10.0 Build 18363; UI render: default; VCL: win; Locale: zh-CN (zh_CN); UI-Language: en-US Calc: threaded I get the "expected result" on the left when paste as BMP.
Did a little more testing. Pasting as "LibreOffice 6.4 Spreadsheet" also gives wrong result. I was thinking of maybe the difference is having CJK enabled (Tools > Options > Language Settings > Languages > "Asian" checkbox), but it seems I can not turn it off for my 6.4.7 on Windows. If I uncheck the box and restart LO, it will be checked again. But Xisco maybe you can try reproducing with it turned on?
Below are some sal_warnings appeared at the paste stage: warn:legacy.osl:1176726:1176726:svx/source/svdraw/svdmrkv1.cxx:310: SdrMarkView::UndirtyMrkPnt(): Selected points on an object that is not a PolyObj! warn:legacy.osl:1176726:1176726:svx/source/dialog/rulritem.cxx:677: Wrong MemberId warn:legacy.tools:1176726:1176726:sfx2/source/control/statcach.cxx:398: setting state of dirty message warn:vcl.gdi:1176726:1176726:vcl/headless/svpgdi.cxx:133: unsupported SvpSalGraphics::blendAlphaBitmap case warn:sd.core:1176726:1176726:sd/source/core/PageListWatcher.cxx:95: ImpPageListWatcher::GetSdPage(PageKind::Standard): page number 1 >= 1 Already reproduced in Version: 6.3.2.0.0+ Build ID: 55dbf08740ffefd6dd08d4bcea0638a15117dc65 > I was thinking of maybe the difference is having CJK enabled No, changing UI language to English (United States) does not help, and neither changing the locale settings. I tried with bibisect-linux-64-6.3 repo which does not have any other language enabled.
I can now confirm the regression as well. Good in 5.2.7: Version: 5.2.7.2 (x64) Build ID: 2b7f1e640c46ceb28adf43ee075a6e8b8439ed10 CPU Threads: 2; OS Version: Windows 6.19; UI Render: default; Locale: zh-CN (zh_CN); Calc: group Bad in 6.2.8: Version: 6.2.8.2 (x64) Build ID: f82ddfca21ebc1e222a662a32b25c0c9d20169ee CPU threads: 2; OS: Windows 10.0; UI render: default; VCL: win; Locale: zh-CN (zh_CN); UI-Language: en-US Calc: threaded
(In reply to Kevin Suo from comment #11) > > I was thinking of maybe the difference is having CJK enabled > No, changing UI language to English (United States) does not help, and > neither changing the locale settings. I tried with bibisect-linux-64-6.3 > repo which does not have any other language enabled. FWIW, what I talked about (CJK support in formatting and styles) is not the same thing as the UI language. I can enable CJK (and CTL) support even in English UI.
It is the same when paste to a new Calc document. As I said, the test document has modified built-in styles applied to the cells, and in a new Calc document, the built-in styles are still with default formats, so when pasting, the application does not update the styles in target. While I strongly support the current behaviour when pasting in a new spreadsheet file, I do suggest to following the modified source style formats when pasting as GDI image file. So this seems to be an enhancement request. Xisco Faulí: I think you should 100% reproduce this. If not, there must be some steps not correct. @Ming Hua: You stated it is good in 5.2.7, could you try to see if the styles are updated when paste in a new spreadsheet? Or is it because 5.2.7 does not have some of the built-in styles thus treated them as direct formatting？
Created attachment 167616 [details] Screenshot of the result when pasted to a new spreadsheet (In reply to Kevin Suo from comment #14) > @Ming Hua: You stated it is good in 5.2.7, could you try to see if the > styles are updated when paste in a new spreadsheet? Or is it because 5.2.7 > does not have some of the built-in styles thus treated them as direct > formatting？ An empty new spreadsheet in 5.2.7 only has four built-in styles: Heading, Heading1, Result, and Result2. So when pasted to a new spreadsheet (using just Ctrl+C and Ctrl+V), the result is... interesting. Screenshot attached. It seems "Heading" and "Result", which are built-in styles, reverted to pre-modified setting. The other styles kept the customized setting. I also double-checked the result of pasting as GDI into Draw. There everything kept the customized setting. So in 5.2.7 I'm getting different result when pasting into Calc vs. pasting as GDI into Draw.
Clearly a bug to me. Pasting content does not respect the actual cell style, if existing. Happens for Calc object and for GDI. We changed the cell styles and prior this version you just don't have good/bad/error etc. For testing purpose I'd add another cell style "Foo" - this is taken as defined into the target.
Dear Kevin Suo, 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