After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 668936 - Problem with text in/out
Problem with text in/out
Status: RESOLVED FIXED
Product: Gnumeric
Classification: Applications
Component: import/export MS Excel (tm)
1.10.x
Other Windows
: Normal normal
: ---
Assigned To: Jody Goldberg
Jody Goldberg
Depends on:
Blocks:
 
 
Reported: 2012-01-29 00:11 UTC by Rick
Modified: 2012-01-30 15:26 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
MS Office 2007, Export from MS-Access to MS-Excel (8.19 KB, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet)
2012-01-29 14:34 UTC, Rick
Details
from gNumerics, Excel says it has errors (3.81 KB, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet)
2012-01-29 22:21 UTC, Rick
Details
file from comment #8 resaved by Gnuemric 1.11.2 (current git) (4.99 KB, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet)
2012-01-29 23:00 UTC, Andreas J. Guelzow
Details
for test only, purely from MS-Excel. mixed format,etc. text (7.87 KB, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet)
2012-01-30 04:28 UTC, Rick
Details
see comment (11.67 KB, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet)
2012-01-30 14:37 UTC, Rick
Details
first Gnumeric out .xlsx where problem also noted (3.86 KB, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet)
2012-01-30 14:40 UTC, Rick
Details

Description Rick 2012-01-29 00:11:49 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.
Comment 1 Morten Welinder 2012-01-29 02:21:29 UTC
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.
Comment 2 Rick 2012-01-29 14:34:03 UTC
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.
Comment 3 Rick 2012-01-29 14:42:46 UTC
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
Comment 4 Andreas J. Guelzow 2012-01-29 16:14:02 UTC
Which exact version of Gnumeric are you using?
Comment 5 Rick 2012-01-29 16:19:41 UTC
version 1.10.16
Comment 6 Andreas J. Guelzow 2012-01-29 21:54:26 UTC
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".
Comment 7 Andreas J. Guelzow 2012-01-29 22:02:21 UTC
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.
Comment 8 Rick 2012-01-29 22:21:30 UTC
Created attachment 206382 [details]
from gNumerics, Excel says it has errors
Comment 9 Rick 2012-01-29 22:27:09 UTC
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.
Comment 10 Andreas J. Guelzow 2012-01-29 22:57:04 UTC
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.)
Comment 11 Andreas J. Guelzow 2012-01-29 23:00:02 UTC
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.
Comment 12 Rick 2012-01-29 23:16:37 UTC
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.
Comment 13 Andreas J. Guelzow 2012-01-30 03:28:14 UTC
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.
Comment 14 Rick 2012-01-30 04:28:29 UTC
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
Comment 15 Andreas J. Guelzow 2012-01-30 04:57:47 UTC
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"
Comment 16 Andreas J. Guelzow 2012-01-30 07:55:39 UTC
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.
Comment 17 Rick 2012-01-30 14:37:44 UTC
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.
Comment 18 Rick 2012-01-30 14:40:56 UTC
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.
Comment 19 Andreas J. Guelzow 2012-01-30 14:58:02 UTC
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?
Comment 20 Rick 2012-01-30 15:02:57 UTC
Yes, when it was originally being saved, there was visbly in B1 the entry "xyz" ... and it went into the ether!
Comment 21 Morten Welinder 2012-01-30 15:06:47 UTC
That would suggest a save problem as opposed to a load problem.
Comment 22 Andreas J. Guelzow 2012-01-30 15:11:15 UTC
I filed bug #669038. I suspect that this problem is caused by an incomplete editing as described in bug #669038.
Comment 23 Rick 2012-01-30 15:14:29 UTC
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.
Comment 24 Andreas J. Guelzow 2012-01-30 15:23:10 UTC
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.
Comment 25 Rick 2012-01-30 15:26:38 UTC
Time permitting later today or tomorrow, I'll try some more.  Reply then affirmative or not.