Description: When save ODS to XLSX, the shading of comment boxes lose shading. Makes it impossible to read the comment when I hover over the cell (and comment is displayed. Steps to Reproduce: 1. Capture data in cells 2. Add comment to a cell 3. Save to XLSX 4. Open XLSX in MS Excel: no background in comment, text blurs into normal background text Actual Results: As described Expected Results: Background colour of comment should be saved in Excel file Reproducible: Always User Profile Reset: No Additional Info: [Information automatically included from LibreOffice] Locale: en-US Module: SpreadsheetDocument [Information guessed from browser] OS: Linux (All) OS is 64bit: yes User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0
Note: when I save to XLS there is no problem
Same problem if save ODS to XLSX using Calc v5.4
I can reproduce that the comment in the exported xlsx file has no background color instead of the default yellow. If you click into the comment to edit it, the yellow background occurs. LibO 6.0.0.1 (x64) Build-ID: d2bec56d7865f05a1003dc88449f2b0fdd85309a CPU-Threads: 8; BS: Windows 10.0; UI-Render: Standard Opened in MSO Excel 2013. When opened the xlsx file in LibO 6.0 again, the comment looks right. Creating a spreadsheet with a comment in LibO 3.3.0 and exporting to xlsx results in a more weird presentation (also without a comment background color), see screenshot.
Created attachment 138892 [details] Comment exported from LO 3.3.0 to xlsx (displayed in MSO Excel 2013)
Created attachment 138990 [details] Example .xlsx file created by MS Office 2013, with colour comments
It seems that after changing shape type from type="#_x005F_x0000_t202" to type="#_x0000_t202" , everything is displayed correctly. I will prepare patch which fix that issue
It seems that shape type must be defined: For example: <v:shapetype id="shapetype_202" coordsize="21600,21600" o:spt="202" path="m,l,21600l21600,21600l21600,xe"> <v:stroke joinstyle="miter"/> <v:path gradientshapeok="t" o:connecttype="rect"/> </v:shapetype> And correct type of shape needs to be used: <v:shape id="shape_0" fillcolor="#ff99cc" stroked="t" type="#shapetype_202" In this case after providing: type="#shapetype_202" (which type was defined before) colours are imported correctly by MS Excel 2013
Review which fix this issue: https://gerrit.libreoffice.org/#/c/47821/
Bartosz Kosiorek committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=ea7274259a211170ee9f5a8714a2f9acd8bed6d8 tdf#114842 Fix comment shape export for Calc It will be available in 6.1.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
As a side note: it looks odd that in the Excel generated attachment the shapetype ID is "_x0000_t202", which means the ID starts with a hex null character (which _x0000_ should decode to if not escaped as _x005F_x0000_). See ECMA-376-1:2016 page 3736, 22.4.2.4 bstr (Basic String) for reference. Question remains if the treatment of writing _x005F_x0000_ vs reading _x0000_ (and apparently not decoding as otherwise we would not write _x005F_x0000_) is actually correct. I have doubts.
Hello Eike. How to apply your comments? What I should investigate to fix that naming convention? Is there a risk that patch will not work correctly in specific conditions?
I have no idea. I don't know why Excel writes that as unescaped "_x0000_t202" and what implication it has if we write it as escaped "_x005F_x0000_t202" instead. What happens if that is read with Excel and then saved again? Is the escapement preserved? Or removed? Or...? Also, I guess that when LO reads the "_x0000_t202" the encoded _x0000_ is not decoded (which might lead to even more problems if it was because many places don't consider embedded nil characters). So this may be a special case where the _x0000_ should not be escaped.
Hey! i am having an issues on Xbox One S error code 0x80072ee7 when we are going to open then this types of error generated. https://www.msofficetechnicalsupportnumbers.com/blog/tag/fix-xbox-one-s-error-code-0x80072ee7/ I also try on this link for getting solution but not get any proper solution.
This bug is really difficult to remove. The answers provided here are very helpful. To solve further problems visit https://www.lenovosupportphonenumber.com/blog/fix-lenovo-error-code-0x80070057/