If you replace:

with

things will work. Check out the documentation on normalizeSheet. Short version is that staroffice compresses tables, and it takes a long time to decompress them, so rather than doing it fully for you, you have to specify how much to decompress. The main symptom of not decompressing, or 'normalizing', the sheet is that funny things happen to blank cells, especially multiple blank cells in a row. The key is to normalize as small an area as possible, because it really will take a long time to normalize a large area. Try to know the row and column # beforehand, if possible.

Hope that helps,
Matt

celebrated too early--the code fragment that first normalizes and then gettabletexts fails:

I don't know what to say...I have your sample code exactly as you posted before:

and it works perfectly for me. I have your original line commented out, and I get the same results as you had, and then I replace it with the two lines about normsheet and everything works. Did you try the simple test case again, with the new code? Or are you trying in your full ods2csv script? Try the test case again, I bet it will work, and the problem is elsewhere in the script. And don't worry, this package is a bit confusing to use at first, just like anything that's powerful...it will take a bit of time to figure out what makes it tick. And sometimes, there are bugs :)

-Matt

p.s. the above hack is only a workaround if you are writing to cells. If you are reading cells, there's more places in Text.pm that use the expression:

All these places would need looking at, but the right thing is to figure out the real problem and let the appropriate module author know...I'll do that if nobody else does in the next few days. Info from matt on his twig version would help a lot.

The bug is pinpointed in XPath.pm 2.017, so Text.pm should not be patched and the XML::Twig version (3.22 or later) doesn't matter .

The fix will be done in the next O::O release. However, in the meantime, the existing XPath.pm should be manually replaced by a provisional one, which is now available at
http://jean.marie.gouarne.online.fr/tech/oodoc/XPath.pm

Don't worry about this Twig_pm.slow heading comment; it doesn't indicate the real Twig.pm version number.
Look at the $VERSION variable in the BEGIN block (near the line #90) in Twig.pm

Note that you could not run OpenOffice::OODoc 2.026 without XML::Twig 3.22 or later.

OpenOffice::OODoc 2.028 has been posted today.
This release fixes a bug affecting some table-related access methods (previously reported in this forum).
In addition, the OpenOffice::OODoc::Text manual section has been updated in order to describe the text box related methods (available but not documented in 2.027).

I hope this forum is the right place for the following. I got to know OODoc only two days ago and I'm unfamiliar with it's developing community etc. And I apologize in advance for my bad english as I'm not a native speaker.

I spent part of my weekend examining the sourcecode of OpenOffice::OODoc::Text to understand, how it works and why I experianced the mentioned problems. Just in case anyone is interested in the solution, I post it here:

My problem was this: I use the function getTableText() to 'export' Data from all the tables in a spreadsheet to csv files. I don't know in advance how many tables the sheet contains nore the names and the size of them. This is how I read the content from all the tables and store it in a hash-array-structure:

Now, as I didn't knew, OODoc by default normalizes only 32 rows and 26 cols ( cf. options 'max_cols' and 'max_rows'). This caused the errors in my csv files because my tables contain up to 2100 rows and could contain even more in future. So I first changed the option 'max_rows' to 65536. This produced correct csv files - after several cups of coffee though! So I thought of first counting the rows of the sheet and then call getTableText with the parameters 'width' and 'length' to make OODoc normalize only the given size. But this is not possible as the sheet is already normalized when I count the rows (or in other words: to count the rows, the table has to be normalized first).

So I decided to patch OODoc::Text, telling it to stop normalization as soon as it finds a row with the ROW_REPEAT_ATTRIBUTE (table:number-rows-repeated in the XML-File) equal or greater than the remaining number of rows to normalize (i.e. the number of allready processed rows subtracted from paramter 'length' or the option 'max_rows' and decreased by 2), assuming that this indicates the empty rows until the end of the sheet. As I found in the XML-Code of the Sheet, OpenOffice leaves the last row as separate row with no repeate attribute. This is why I dereased the value by 2.

No I can change the option 'max_rows' to 65536 (and 'max_cols' to 256) to be sure, every table will be normalized properly irrespective of it's size and in a reasonable time. It only may cause problems if the row number 65536 (i.e. the last row!) is not empty or if there are repeated non-empty rows until the end of the sheet.

These are the changes I made on OpenOffice::OODoc::Text:

Changing line 2350 to:

Changing line 2359 to:

Inserting a new line after line 2349 with:

Inserting a new line after line 2339 with:

That's all. Will this affect the module's functions in any way? I can't imagine. Perhaps it is even a suggestion for the developpers of OODoc. I'm not sure but I think csv-export of spreadsheets could be a common task for OODoc.

I know getTable($tablename, $height, $width) - but what if I don't know height and width (as I described yesterday...)??

And getTableSize: the problem is not, to "get" the empty rows (getTableText truncates empty rows at the end anyway), but the normalization takes much time if you normalize 65536 rows.

Btw. I found that my solution from yesterday does not work properly. It was a little bit rash, to post it, sorry. But I already have a new one ;-) I don't like to patch modules either, but I don't know an other solution. So now I made the following with O::O::Text: After line 2316 I insert:

After line 2339 (now 2355) I insert:

I Change line 2359 (now 2382) to:

Assuming that the global option 'truncate_empty_cells' set to '1'. This takes time as well, but not as much as normalizing the whole table. And in respect to yesterday's solution it works ;-)