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 378560 - gnumeric->xls->gnumeric roundtrip issues
gnumeric->xls->gnumeric roundtrip issues
Status: RESOLVED FIXED
Product: Gnumeric
Classification: Applications
Component: import/export MS Excel (tm)
git master
Other All
: Normal normal
: ---
Assigned To: Jody Goldberg
Jody Goldberg
Depends on:
Blocks:
 
 
Reported: 2006-11-23 18:10 UTC by Morten Welinder
Modified: 2006-11-25 02:58 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Morten Welinder 2006-11-23 18:10:19 UTC 
gunzip < ../samples/regress.gnumeric >old
../src/ssconvert ../samples/regress.gnumeric regress.xls
../src/ssconvert regress.xls regress2.gnumeric
gunzip < regress2.gnumeric >new
diff -u old new | less

Near the bottom we see this hunk.  The rounding is probably not important,
but how did "HardSize" show up?

@@ -872,13 +783,13 @@
         </gnm:StyleRegion>
       </gnm:Styles>
       <gnm:Cols DefaultSizePts="48">
-        <gnm:ColInfo No="0" Unit="65.25" HardSize="1"/>
-        <gnm:ColInfo No="1" Unit="66.75"/>
-        <gnm:ColInfo No="2" Unit="35.25"/>
-        <gnm:ColInfo No="3" Unit="261"/>
-        <gnm:ColInfo No="4" Unit="61.5"/>
-        <gnm:ColInfo No="5" Unit="56.25"/>
-        <gnm:ColInfo No="6" Unit="79.5"/>
+        <gnm:ColInfo No="0" Unit="65.26" HardSize="1"/>
+        <gnm:ColInfo No="1" Unit="66.76" HardSize="1"/>
+        <gnm:ColInfo No="2" Unit="35.26" HardSize="1"/>
+        <gnm:ColInfo No="3" Unit="261" HardSize="1"/>
+        <gnm:ColInfo No="4" Unit="61.5" HardSize="1"/>
+        <gnm:ColInfo No="5" Unit="56.26" HardSize="1"/>
+        <gnm:ColInfo No="6" Unit="79.5" HardSize="1"/>
       </gnm:Cols>
       <gnm:Rows DefaultSizePts="12.8">
         <gnm:RowInfo No="0" Unit="12.75" Count="2"/>
Comment 1 Jody Goldberg 2006-11-25 02:58:46 UTC 
This problem stemmed from apparent limitations in the xls format.
The docs did not list any flags that would represent 'hard_size' so I assumed that if there was a COLINFO record it must mean that the size was explicitly set.  That ignored bestFit columns that were autosized to something non-standard.

Reading the OfficeOpen docs and a closer look at the xls suggested that there were two undocumented flags.

1.7.5 has a patch to handle these for xls and xlsx.