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.