Description: ------------ I've got a code that requires outputting many strings in the custom input encoding. Unfortunatelly the module returns broken XLS files. For the test script some strings are broken (random characters). I think that there is an error in the function _storeSharedStringsTable(). Test script: --------------- $xls = new Spreadsheet_Excel_Writer(); $xls->setVersion(8); $xls->setCountry(48); $xls_s = $xls->addWorksheet("test"); $xls_s->setInputEncoding('ISO-8859-2'); for($i=0;$i<500;$i++) { $str="aceąćę".$i; $xls_s->writeString($i,0,$str); } $xls->send('test.xls'); $xls->close(); Expected result: ---------------- 500 lines: "aceąćę".$i; (0<=i<500) Actual result: -------------- 400 lines: "aceąćę".$i; (0<=i<=400) then garbage

Doing a bit of debugging (with my absencde of knowledge of the Excel file format), I narrowed the bug down to _storeSharedStringsTable() as pointed before. It seems that you get an error after the first time you "cross the CONTINUE boundary". That is, the bug occurs after the first string that does not pass this test: // We can write the string if it doesn't cross a CONTINUE boundary if ($block_length < $continue_limit) { /* snip */ } Hope it will help...

I ported the ommitted aligment marked by TODO: Unicode data should only be split on char (2 byte) from http://search.cpan.org/src/JMCNAMARA/Spreadsheet-WriteExcel-2.16/lib/Spreadsheet/WriteExcel/Workbook.pm to _calculateSharedStringsSizes and _storeSharedStringsTable and that seems to do the trick.

Sorry, that was premature. Still croaking on longer outputs :-(

I've also enountered this bug and this is what I've found: - The bug happens when you use setInputEncoding to set the input encoding (obviously in a BIFF8 file). As far as I can tell this is because it only stores strings as UTF-16LE if you set the input encoding. - This being the case, it doesn't matter what characters (unicode/ascii) you input, it's simply the fact that they are being converted to, and stored as, UTF-16LE. - Also, when I tested it, there seemed to be magic numbers of characters that let you store as many lines as you liked (I think 20, 25, possibly 50-something..) - I also tracked down the TODO parts in calculateSharedStringsSizes and _storeSharedStringsTable and ported the missing bits from the PERL script. As Mr Burckhardt states, these made no difference whatsoever. To conclude, Spreadsheet_Excel_Writer can't currently store lots of unicode strings in an Excel sheet :(

Thank you for taking the time to report a problem with the package. Unfortunately you are not using a current version of the package -- the problem might already be fixed. Please download a new version from http://pear.php.net/packages.php If you are able to reproduce the bug with one of the latest versions, please change the package version on this bug report to the version you tested and change the status back to "Open". Again, thank you for your continued support of PEAR.

Thank you for taking the time to report a problem with the package. Unfortunately you are not using a current version of the package -- the problem might already be fixed. Please download a new version from http://pear.php.net/packages.php If you are able to reproduce the bug with one of the latest versions, please change the package version on this bug report to the version you tested and change the status back to "Open". Again, thank you for your continued support of PEAR.

Thank you for taking the time to report a problem with the package. Unfortunately you are not using a current version of the package -- the problem might already be fixed. Please download a new version from http://pear.php.net/packages.php If you are able to reproduce the bug with one of the latest versions, please change the package version on this bug report to the version you tested and change the status back to "Open". Again, thank you for your continued support of PEAR.