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

Bug #1011564 reported by Chris B on 2012-06-11
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
LibreOffice
Confirmed
Wishlist
libreoffice (Ubuntu)
Wishlist
Unassigned

Bug Description

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)

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

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

confirmed by dupe/downstream bug

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

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.

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.

(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.

(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?

That sounds sane.

Chris B (billington-chris) wrote :

confirmed by dupe/downstream bug

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

summary: - "the document contains more rows than supported in the selected format."
+ [upstream] "the document contains more rows than supported in the
+ selected format."
Changed in libreoffice (Ubuntu):
status: New → Confirmed
Chris B (billington-chris) wrote :

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.

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.

Changed in df-libreoffice:
importance: Unknown → Medium
status: Unknown → Invalid

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.

(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.

Changed in libreoffice (Ubuntu):
importance: Undecided → Wishlist

(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?

That sounds sane.

Changed in df-libreoffice:
importance: Medium → Wishlist
status: Invalid → Confirmed

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

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

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.

Changed in libreoffice (Ubuntu):
status: Confirmed → Incomplete
Changed in df-libreoffice:
importance: Wishlist → Unknown
status: Confirmed → Unknown
Changed in df-libreoffice:
importance: Unknown → Wishlist
status: Unknown → Confirmed

Synchronising bug status with upstream.

Changed in libreoffice (Ubuntu):
status: Incomplete → Confirmed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.