[upstream] "the document contains more rows than supported in the selected format."

[Chris B]

Obtained result:

When saving a Calc spreadsheet in Excel format, the message

"Warning saving the document xxx:"
"the document contains more rows than supported in the selected format."
"Additional rows were not saved"

appears.

However, the document only has 1100-or-so rows.

Expected result: no error message

- A similar bug has been reported upstream https://bugs.freedesktop.org/show_bug.cgi?id=50471 but not actioned.
- There is an older bug https://issues.apache.org/ooo/show_bug.cgi?id=106083 reported against Openoffice.org which states this issue is caused by sheets that have undefined Print Ranges, which are not truncated properly by the Excel export filter.
- I confirmed that the error message does not show if the print ranges are manually sized to the area of active cells.
- It appears that the issue returned in 3.5.3 having previously been fixed.

Can this bug be reported upstream by Ubuntu, as this report may carry more weight than the single report on the freedesktop.org site?

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: libreoffice-calc 1:3.5.3-0ubuntu1
ProcVersionSignature: Ubuntu 3.2.0-25.40-generic-pae 3.2.18
Uname: Linux 3.2.0-25-generic-pae i686
ApportVersion: 2.0.1-0ubuntu9
Architecture: i386
Date: Mon Jun 11 12:20:09 2012
InstallationMedia: Ubuntu 10.04 LTS "Lucid Lynx" - Release i386 (20100429)
SourcePackage: libreoffice
UpgradeStatus: Upgraded to precise on 2012-02-22 (109 days ago)

[Alain-desgeorge (alain-desgeorge)]

Created attachment 62233
a sample ods sheet 481 rows

Problem description:
when saving a spreadsheet in ods format, then in xls format, to distribute, I get the message saying:
"Warnig saving the document xxx:"
"the document contains more rows than supported in the selected format."
"Additional rows were not saved"
which is not true, both files have the same number of rows 481.

If I re-open the xls file, make a change and save, I get no warning.
both files saved as csv and compared are identical.
Steps to reproduce:
1. open myfile.ods
2. make a change, save as ods
3. save as xls Excel 97

Current behavior:
Warning
Expected behavior:
Warning only if this is true ;-)
Platform (if different from the browser):

Browser: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20100101 Firefox/12.0

[Alain-desgeorge (alain-desgeorge)]

Created attachment 62233
a sample ods sheet 481 rows

Problem description:
when saving a spreadsheet in ods format, then in xls format, to distribute, I get the message saying:
"Warnig saving the document xxx:"
"the document contains more rows than supported in the selected format."
"Additional rows were not saved"
which is not true, both files have the same number of rows 481.

If I re-open the xls file, make a change and save, I get no warning.
both files saved as csv and compared are identical.
Steps to reproduce:
1. open myfile.ods
2. make a change, save as ods
3. save as xls Excel 97

Current behavior:
Warning
Expected behavior:
Warning only if this is true ;-)
Platform (if different from the browser):

Browser: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20100101 Firefox/12.0

[Björn Michaelsen (bjoern-michaelsen)]

confirmed by dupe/downstream bug

[Björn Michaelsen (bjoern-michaelsen)]

Is this a regression? Did this work in 3.4/3.3?

[Eike Rathke (erack)]

The attached file has all cells of columns C to IN explicitly formatted with white background down to row 1048576. Binary xls 97 file format supports only 64k rows, so the message is correct.

[Eike Rathke (erack)]

Thinking this over, the expected behavior might be that extraneous attributed-only rows are ignored in this case. Import of xls 97 already handles that by expanding the attributed range. Actually LibO 3.4 treated this differently and did not show the message on export.

[Markus Mohrhard (moggi)]

(In reply to comment #4)
> Thinking this over, the expected behavior might be that extraneous
> attributed-only rows are ignored in this case. Import of xls 97 already handles
> that by expanding the attributed range. Actually LibO 3.4 treated this
> differently and did not show the message on export.

I had to change the export of attribute only rows because without the row height information which are part of the attributes we misplace cell anchored objects.

[Eike Rathke (erack)]

(In reply to comment #5)

Well, yes, but it should work to export the full range that is supported by the target format and truncate the extraneous rows that are only attributed. Or am I missing something?

[Markus Mohrhard (moggi)]

That sounds sane.

[Björn Michaelsen (bjoern-michaelsen)]

confirmed by dupe/downstream bug

[Björn Michaelsen (bjoern-michaelsen)]

Is this a regression? Did this work in 3.4/3.3?

[Chris B (billington-chris)]

On further experimentation I found that restricting the print area does NOT remove the error message.

However, in the document used for testing, a template file prepared as follows gives the error, tested with Libreoffice 3.5.4_2 from PPA and 3.5.3:

- new document
- fill column A with data using fill/increment for a hundred or so rows.
- Select column header and give all cells borders (which extend the to the rows limit), or perform other formatting to the entire column, such as background fill
- save as .xls format

Result: unsupported rows

If the cell formatting is restricted to the active area, the error message does not show.

It appears that the range of formatted cells is not truncated by the Excel export filter, giving rise to an error for the formatting over 64k rows.

Unfortunately this technique of cell formatting is in common use by spreadsheet users to avoid selecting a specific area in their document.

[Eike Rathke (erack)]

The attached file has all cells of columns C to IN explicitly formatted with white background down to row 1048576. Binary xls 97 file format supports only 64k rows, so the message is correct.

[Eike Rathke (erack)]

Thinking this over, the expected behavior might be that extraneous attributed-only rows are ignored in this case. Import of xls 97 already handles that by expanding the attributed range. Actually LibO 3.4 treated this differently and did not show the message on export.

[Markus Mohrhard (moggi)]

(In reply to comment #4)
> Thinking this over, the expected behavior might be that extraneous
> attributed-only rows are ignored in this case. Import of xls 97 already handles
> that by expanding the attributed range. Actually LibO 3.4 treated this
> differently and did not show the message on export.

I had to change the export of attribute only rows because without the row height information which are part of the attributes we misplace cell anchored objects.

[Eike Rathke (erack)]

(In reply to comment #5)

Well, yes, but it should work to export the full range that is supported by the target format and truncate the extraneous rows that are only attributed. Or am I missing something?

[Markus Mohrhard (moggi)]

That sounds sane.

[Jmadero-dev (jmadero-dev)]

Looks like this was confirmed but never taken up by anyone - moving to NEW.

[Jmadero-dev (jmadero-dev)]

Looks like this was confirmed but never taken up by anyone - moving to NEW.

[Marcus Tomlinson (marcustomlinson)]

This release of Ubuntu is no longer receiving maintenance updates. If this is still an issue on a maintained version of Ubuntu please let us know.

[Marcus Tomlinson (marcustomlinson)]

Synchronising bug status with upstream.