GNOME Bugzilla – Bug 668936
Problem with text in/out
Last modified: 2012-01-30 15:26:38 UTC
I have seen a real problem in loading some .xlsx from Excel 2007 or creating in gNumerics and saving as such the reloading. A simple test. Enter "abc" in 1,1 and "xyz" in in 1,2. Save as an Excel .xlsx file. Quit and load from the file. "xyz" is nada, zip lost in the ether. This first was noted on trying to import a ,xlsx dump from MS-Access 2007 of a table. Ouch.
Seems to work for me. When you say "in 1,1" I assume you mean cell A1. And "1,2" is cell A2. Right? If you have an xlsx file you are not seeing loaded right, it would be helpful if you could attach it.
Created attachment 206354 [details] MS Office 2007, Export from MS-Access to MS-Excel Displays correctly in MS-Excel, but in gNumerics Colum B is empty.
My Bad. A1, B1 for the easy sample to create. A1 = "abc" B1 = "xyz" Save as .xlsx, MS-Excel 2007. probably 2010 too. close sheet reload and no data in column B ---- In the attachment, 3 columns are used. Column A and C are numeric values, column B is text. If needed, I can save and send some screen shots. System: WinXP SP3, Core2Duo E-8200, 4GB DDR3, NVidia GEForce 9400, MS Office 2007, MS Acess source database is in Office 2000 format
Which exact version of Gnumeric are you using?
version 1.10.16
I cannot replicate this with a Gnumeric generated file. I can replicate the problem with the file you provided and I get the following warnings in the console: Unexpected element 'is' in state : worksheet -> sheetData -> row -> c and many repetitions of this warning. Please do not reset the importance of this bug. "critical" or "blocker" does not mean "it happened to me". Since this is a problem in a single plugin supporting a relatively new format and it is easy to work around it using xls or odf format, this is clearly not a "blocker" or "critical".
The element in question is (according to ECMA-376 3rd edition): 18.3.1.53 is (Rich Text Inline) This element allows for strings to be expressed directly in the cell definition instead of implementing the shared string table.
Created attachment 206382 [details] from gNumerics, Excel says it has errors
After stating file has "unreadable content" and letting Excel repair, the following info is displayed in a dialog: Removed Part: /xl/styles.xml part with XML error. (Styles) Load error. Line 26, column 25. Repaired Records: Cell information from /xl/worksheets/sheet2.xml part Repaired Records: Cell information from /xl/worksheets/sheet3.xml part While an individual might use .xls, this might not be acceptable in a group environment where .xlsx format is the accepted norm.
The problem with not loading the inline specified text has been fixed in the development version. The fix will be available in the next major software release (1.11.2 or later). Thank you for your bug report. This bug remains open for the issues mentioned in Comment 8 and comment 9. (This seems familiar so perhaps this has in fact already been fixed.)
Created attachment 206386 [details] file from comment #8 resaved by Gnuemric 1.11.2 (current git) I have taken your file from comment #8 and resaved it with Gnumeric 1.11.2. I would greatly appreciate it if you would try it with your Excel and let us know whether you still see those errors.
Tried and no errors noted. If desires and a windows version of 1.11.2 is available, I can try some more back and forth today.
We don't have any compiled windows versions after 1.10.16. I believe nobody (who knows how to compile it for or on Windows) evver comiled 1.10.17 and made it available. The development series 1.11.x depends on GTK3 and I am not sure that that is even available yet for Windows. It would be great if you could provide a file similar to the one of comment #2, but with some text formatting to part of each entry in column B, ie. 4th to 7th character in bold or blue or so. I am pretty sure that the issues mentioned in Comment 8 and comment 9 have in fact been fixed since you did not see a problem with my file of comment #11 and my memory tells me that I had addressed that problem a few months back.
Created attachment 206391 [details] for test only, purely from MS-Excel. mixed format,etc. text Even changed a font for a single letter in a cell. Has bold,italic,underline,double-underline, mixed borders and background on one cell. View in Excel if you can. Then see how it plays with gNumerics. There are lots of folks that need this here in Mexico in Windows. I'll be testing things on XP Pro SP3 and Win7 Pro or Ultimate, 64 bit, SP1
Thanks for the file! Based on your description, Gnumeric 1.11.2 does not open this file correctly. I guess I should be able to find a Windows machine at work tomorrow and get a screenshot of how it should look like. I would have expected warnings in the console but we seem to have none. Once I have the screenshot I will likely open a new bug report. PS: We spell the name of this spreadsheet application: "Gnumeric"
Hmm, the strings in the file of comment #14 are not stored as in line strings but as references to the shared strings table. So those strings should not be lost when opened in 1.10.16.
Created attachment 206435 [details] see comment I can open text-to-test_mixed_formating.xlsx (comment 14) in GNumerics 1.10.16 w/o missing info. The same held true for a couple of other tests with plain text. I also loaded several other MS-Access exports in .xlsx without problems. The EstadosRep.xlsx is always missing display of any data in column B. So I using MS-Excel, checked the format of the entries, it like othe MS-Access exports was set to "General" so set the column to "Text" and saved as the attached file here. It loads OK into GNumerics 1.10.16 now. Which may help or just deepen the mysteries. There are some aspects here which may be induced by MS in their export or not. Also found that a simple test trying to repeat the first GNumerics created .xlsx did not have the problem. Although the first one still does. I'm hoping with this include you may be able to see some differences between the 2 EstadosRep exports.
Created attachment 206436 [details] first Gnumeric out .xlsx where problem also noted Sorry for the misspelling and capitalization of GNumeric so often. Try to do better now. This was my first example, previously only described in this report.
Opening the file of comment #18 in Gnumeric 1.11.2 shows only one cell with abc on Sheet1. This matches the true file content: <sheetData> <row r="1" spans="1:1"> <c r="A1" s="0" t="str"> <v>abc</v> </c> </row> </sheetData> Was there supposed to be an xyz on that sheet?
Yes, when it was originally being saved, there was visbly in B1 the entry "xyz" ... and it went into the ether!
That would suggest a save problem as opposed to a load problem.
I filed bug #669038. I suspect that this problem is caused by an incomplete editing as described in bug #669038.
More than that me thinks. The reason being that the simple example abc,xyz originated in GNumeric. The others originated in MS-Access 2007 or MS-Excel 2007. I noticed it first with the MS-Access output from a table dump to .xlsx. Either way appears to bite. I tried to recreate the abc, xyz without success. Gotta run to the day and night job (programmer's life). I'll stay tuned though.
The MS-Access 2007 or MS-Excel generated files were incorrectly loaded. That has been fixed. Gnumeric does not generate the xml elements implemented in that problem, so I really believe that the issue with the simple Gnumeric file may be as described in Bug #669038. Unless somebody can replicate the problem of the simple file while making sure that all cells where completely entered, I don't think we can address this further.
Time permitting later today or tomorrow, I'll try some more. Reply then affirmative or not.