Created attachment 57779 [details] Test.xls - Please open the attached xls - Note that yellow background and the black grid go down to row 104 - Save the spreadsheet as xls or xlsx - Close the spreadsheet - Open the saved copy of the spreadsheet - Note that the yellow background and the black grid go down only to row 5 now, which are filled rows (Since I do not remember such bugs in earlier versions I think it is a regression introduced in LibreOffice 3.5.0.)
I see the effect with attached document and with "LibreOffice 3.5.1.1 German UI/Locale [Build-ID: 45a2874-aa8c38d-dff3b9c-def3dbd-62463c8] on German WIN7 Home Premium (64bit) , but I can't reproduce the problem with self created documents. There is a difference between my own test documents and reporter's: in my documents with <control+end> I reach the end of area with cells with background (B18, last cell with "real" contents is B8). In reporter's sample with <control+end> I reach D5, what is last cell with "real" contents, not D104 (end of range with background) With reporter's sample the loss of background is reproducible with all versions I tested back until 3.3.0 portable; I believe it has started with 3.3.0beta. OOo 3.1.1 and OOo 3.3 correctly export background for all cells. Might be related to "Bug 39068 - PRINTING only first area with color formatted cells (background, border), same with PDFEXPORT" @OfficeUser: I need some additional information: a) How has your document been created b) can co contribute a document.ods created with 3.5.0 from the scratch demonstrating the problem? Can you find out difference between your test document and my one from test kit?
Created attachment 57793 [details] Test kit With these documents effect is not reproducible
@Rainer: I have created and attached a new "test.ods" using LibreOfice 3.5.0 rc3 (=final). Export and import as xls(x) reveals the bug.
Created attachment 57832 [details] test.ods
I am able to reproduce the problem with "LibreOffice 3.5.1.1 German UI/Locale [Build-ID: 45a2874-aa8c38d-dff3b9c-def3dbd-62463c8] on German WIN7 Home Premium (64bit). 1. Start LibO from WIN Start Center, open new CALC document from LibO Atart Center 2. type a "x" to A1 after you clicked cell 3. Typ a "y" to B2 after you clicked cell 4. Type a "z" to C3 after you clicked cell 5. Click A1, select with pushed left mouse button A1:C126 6. Click the 'Borders' icon in 'Formatting' Toolbar, then bottom right "all borders" icon > Borders appear for selected A1:C126 7. Click 'Format Cells' icon in 'Formatting' Toolbar > Dialog appears 8. Card 'Background', select "Yellow" > All cells will get yellow background 9. For test <control+end> > cell cursor goes to C3, what indicates that reporter's problem will be reproducible 10. save as test.ods 11. save as test.xls and close 12. reopen test.xls Expected: borders and yellow background A1:C126 Actual: borders and yellow background A1:C3 That will also work using Menu 'Format -> Cells' I sometimes also had the expected result (visible in step 9), may be with a very little difference in the proceeding before. The different result is predictable, scrolling in step 5 will be much slower. But I was not able to find out what different proceeding makes the difference. I also see the effect with LibO 3.4.5 and LibO 3.3.0 Works fine with OOo 3.3, in step 9 cell cursor only reaches C3. but all background will be saved in XLS. @Kohei: Please set Status to ASSIGNED and add yourself to "Assigned To" if you accept this Bug
I'll take that one. Looks like another place where we call ScDocument::ShrinkToUsedArea. Maybe we should provide a method that respects formatting but provides the same semantics.
So after a lot of digging I finally found the problem. This bug is related to to the fix of https://issues.apache.org/ooo/show_bug.cgi?id=30830 Right now this is by design and I have no perfect solution for this. We might increase the 84 to something bigger and/or move the excel export to another method that does not have this limitation. @Kohei: Do you have a preference here? The problematic line is in attarray.cxx:1794
Fixed by implementing a own method for the xls/xlsx export.
Markus Mohrhard committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=5d123a0b0e827aba59ddb50ef1b961a529a34a15 export all style information to xls/xlsx, fdo#46738
Markus Mohrhard committed a patch related to this issue. It has been pushed to "libreoffice-3-5": http://cgit.freedesktop.org/libreoffice/core/commit/?id=6c6a4ed070acc0b106e951864fa5d20927f5c1e0&g=libreoffice-3-5 export all style information to xls/xlsx, fdo#46738 It will be available in LibreOffice 3.5.3.
Petr Mladek committed a patch related to this issue. It has been pushed to "libreoffice-3-5-5": http://cgit.freedesktop.org/libreoffice/core/commit/?id=6a6cee1af26e68c7a5479f2eff5a33d483ff54ed&g=libreoffice-3-5-5 Revert "export all style information to xls/xlsx, fdo#46738" It will be available already in LibreOffice 3.5.5.
I'm sorry but I have to reopen this issue. We had to revert it because it showed a major preformance regression in some cases. The patch is correct but our export code is so horribly broken that we needed to decide which is more serious and the performance problem was worse. I'll check for a solution but might take till 3-7 or later because it may require a serious rework of our cell export.
Petr Mladek committed a patch related to this issue. It has been pushed to "libreoffice-3-5": http://cgit.freedesktop.org/libreoffice/core/commit/?id=e5f690b3711b61c05671d46d19439dd1100f4bff&g=libreoffice-3-5 Revert "export all style information to xls/xlsx, fdo#46738" It will be available in LibreOffice 3.5.6.
Will not be fixed anytime soon. Requires a large refactoring and I'm not sure if I have the time for it.
Markus Mohrhard committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=9e9e53a2d961d489440f4addc25af90d3a6b793b Revert "export all style information to xls/xlsx, fdo#46738"
Markus Mohrhard committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=6c8ec4ad8e816157799cd164d9f9a837efa0f9a7 Revert "Revert "export all style information to xls/xlsx, fdo#46738""
Because this bug isn't assigned to anyone - moving back to NEW.
Could repro with saving attachment 57832 [details] to xls and xlsx. Win 7 Pro 64-bit Version: 5.0.0.0.alpha0+ (x64) Build ID: 211c12b9c64facd1c12f637a5229bd6a6feb032a TinderBox: Win-x86_64@42, Branch:master, Time: 2015-04-18_01:51:17 Locale: fi_FI
I can confirm this. This is really annoying and makes it unusable for me, at least for xlsx format.
With the ODS file format, for example, this issue does not exit. Sorry for my ignorance, but can the ODS code part act as reference for the XLS/XLSX related implementation?
Migrating Whiteboard tags to Keywords: (preBibisect) [NinjaEdit]
Created attachment 125626 [details] Screenshot On Libreoffice 5.1.3.2, exporting to xls or xlsx is working correctly On Libreoffice 5.1.3.2, exporting to xls or xlsx is working correctly. I tested it on Ubuntu 16.04
Well, I still repro on Windows with attachment 57832 [details], with xls and xlsx formats. Win 7 Pro 64-bit Version: 5.3.0.0.alpha0+ (x64) Build ID: f536a83d51443d19dba58157cea28fb67a090e02 CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; TinderBox: Win-x86_64@62-TDF, Branch:MASTER, Time: 2016-06-13_01:19:21 Locale: fi-FI (fi_FI)
Created attachment 126527 [details] test.ods exported to xlsx format by MS Excel 2010
I created new review which partially resolve that issue, without hitting performance: https://gerrit.libreoffice.org/#/c/29899/
Bartosz Kosiorek committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=5239cefff56875c7bb45c046977f1724aace0cfb tdf#46738 Fix exporting .xlsx of coloured empty cells It will be available in 5.3.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.
Eike Rathke committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=00afb44987ccd10bce740aef53861ec53c75c95f tdf#104434 tdf#104451 Revert "tdf#46738 Fix exporting .xlsx of coloured em"... It will be available in 5.4.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.
That change caused too many other problems. Back to NEW.
Eike Rathke committed a patch related to this issue. It has been pushed to "libreoffice-5-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=50d746b78f5600a94830143b1bd5facab4d60c25&h=libreoffice-5-3 tdf#104434 tdf#104451 Revert "tdf#46738 Fix exporting .xlsx of coloured em"... It will be available in 5.3.0.1. 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.
Removing preBibisect, regression if it's inherited from OOo
** Please read this message in its entirety before responding ** 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 http://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://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Still reproducible with Version: 6.1.0.0.alpha0+ Build ID: adc6ba2ad502f095dde8f36242fda9aaa6c276fd CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk3; Locale: de-DE (de_DE.UTF-8); Calc: group Build from today
This too was recently worked around in this commit for bug #41425 : https://cgit.freedesktop.org/libreoffice/core/commit/?id=99b9ea63bfc9a5fe63a0cd7b30b66ce2c1bde08e So validation and cell formatting is now saved for the first 1000 empty rows after the last one with actual cell content. Of course this is a temporary measure, so let's keep this one open for a proper solution for arbitrarily placed cell formatting.
*** Bug 120012 has been marked as a duplicate of this bug. ***
Confirmed, same behaviour during opening XLS/XSLX sheet with background. Version: 7.2.5.2 / LibreOffice Community Build ID: 499f9727c189e6ef3471021d6132d4c694f357e5 CPU threads: 48; OS: Linux 5.11; UI render: default; VCL: gtk3 Locale: cs-CZ (cs_CZ.UTF-8); UI: cs-CZ Calc: threaded
Created attachment 187680 [details] sample ODS to test loss beyond row with data + 1000 rows (In reply to Gabor Kelemen (allotropia) from comment #33) > This too was recently worked around in this commit for bug #41425 : > https://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=99b9ea63bfc9a5fe63a0cd7b30b66ce2c1bde08e > > So validation and cell formatting is now saved for the first 1000 empty rows > after the last one with actual cell content. > Of course this is a temporary measure, so let's keep this one open for a > proper solution for arbitrarily placed cell formatting. Confirmed that there is still formatting loss beyond 1000 rows after data. Steps to reproduce: 1. Open this sample ODS, see that cells are formatted up to row 1140 2. Save as XLSX 3. Reload 4. Observe lost formatting at the end of the range Reproduced in recent master build: Version: 7.6.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: a5c1c674e031087ef0516cebac049341dcdd2fcf CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded