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 643771 - Data Interchange Format DIF Export Does not Conform to Specification
Data Interchange Format DIF Export Does not Conform to Specification
Status: RESOLVED FIXED
Product: Gnumeric
Classification: Applications
Component: import/export other
1.10.x
Other Linux
: Normal normal
: ---
Assigned To: Morten Welinder
Jody Goldberg
Depends on:
Blocks:
 
 
Reported: 2011-03-03 11:40 UTC by J.H.M. Dassen (Ray)
Modified: 2011-03-03 15:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Proposed patch (885 bytes, patch)
2011-03-03 11:42 UTC, J.H.M. Dassen (Ray)
none Details | Review

Description J.H.M. Dassen (Ray) 2011-03-03 11:40:44 UTC
[Originally reported as http://bugs.debian.org/616152]

Date: Wed, 02 Mar 2011 16:09:09 -0500                                           
From: Stanley Pinchak <stanley.pinchak@gmail.com>                               
Subject: Bug#616152: gnumeric: Data Interchange Format DIF Export Does not      
        Conform to Specification

Package: gnumeric
Version: 1.10.13-1
Severity: normal
Tags: upstream

Gnumeric does not export Data Interchange Format files in a standard
compliant manner. There are two ways in which it is non-compliant.

First, the values stored in the header records for VECTORS (think
columns) and TUPLES (think rows) are swapped. This makes programs which
conform to the specification fail, or issue a warning when an N x M
array of data is specified in the header, but the following Data record
structure is actually an M x N array (The data in the gnumeric
spreadsheet is M x N on screen).

Second, Gnumeric includes an extra blank row in exported DIF files.
According to the specification, BOT records are used to indicate the
beginning of a table (think a row). Insted of terminating the last row
of data with the EOD data record, gnumeric inserts a BOT followed
immediately by an EOD. This again plays havoc with standard conforming
programs. It essentially turns an M x N array into an M+1 x N array.

Below is an example gnumeric output next to expected output for
1 x 4 array

gnumeric:     expected:

TABLE         TABLE
0,1           0,1
"GNUMERIC"    "GNUMERIC"
VECTORS       VECTORS
0,1           0,4
""            ""
TUPLES        TUPLES
0,4           0,1
""            ""
DATA          DATA
0,0           0,0
""            ""
-1,0          -1,0
BOT           BOT
0,3.4         0,3.4
V             V
0,4           0,4
V             V
1,0           1,0
"red"         "red"
0,1           0,1
TRUE          TRUE
-1,0          -1,0
BOT           EOD
-1,0            
EOD           


More info on the DIF specification can be found:
http://www.fileformat.info/format/dif/egff.htm
http://en.wikipedia.org/wiki/Data_Interchange_Format

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (901, 'unstable'), (550, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.37-2-686 (SMP w/1 CPU core)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages gnumeric depends on:
ii  debconf [de 1.5.38                       Debian configuration management sy
ii  gconf2      2.28.1-6                     GNOME configuration database syste
ii  gnumeric-co 1.10.13-1                    spreadsheet application for GNOME 
ii  gsfonts     1:8.11+urwcyr1.0.7~pre44-4.2 Fonts for the Ghostscript interpre
ii  libatk1.0-0 1.30.0-1                     The ATK accessibility toolkit
ii  libc6       2.11.2-11                    Embedded GNU C Library: Shared lib
ii  libcairo2   1.10.2-2                     The Cairo 2D vector graphics libra
ii  libglib2.0- 2.28.1-1+b1                  The GLib library of C routines
ii  libgoffice- 0.8.13-1                     Document centric objects library -
ii  libgsf-1-11 1.14.19-3                    Structured File Library - runtime 
ii  libgtk2.0-0 2.20.1-2                     The GTK+ graphical user interface 
ii  libpango1.0 1.28.3-1+squeeze1            Layout and rendering of internatio
ii  libxml2     2.7.8.dfsg-2                 GNOME XML library
ii  procps      1:3.2.8-10                   /proc file system utilities
ii  zlib1g      1:1.2.3.4.dfsg-3             compression library - runtime

Versions of packages gnumeric recommends:
ii  evince                        2.30.3-3   Document (PostScript, PDF) viewer
ii  lp-solve                      5.5.0.13-7 Solve (mixed integer) linear progr

Versions of packages gnumeric suggests:
pn  epiphany-browser       <none>            (no description available)
pn  gnumeric-doc           <none>            (no description available)
pn  gnumeric-plugins-extra <none>            (no description available)
ii  ttf-liberation         1.06.0.20100721-1 Fonts with the same metrics as Tim
ii  ttf-mscorefonts-instal 3.3               Installer for Microsoft TrueType c

-- debconf information:
* gnumeric/existing-process: true
  gnumeric/existing-process-title:
Comment 1 J.H.M. Dassen (Ray) 2011-03-03 11:42:08 UTC
Created attachment 182334 [details] [review]
Proposed patch

Here is a proposed patch to dif.c to fix the issues addressed above.
Recent Excel versions no longer output the extraneous BOT prior the
the EOD.  I suggest that this non-conforming record be dropped for
compatibility with the original VisiCalc and DIF Clearinghouse
standard.  However, Excel does still swap the VECTORS and TUPLES
header records, but is agnostic when importing, looking at the actual
data representation.  Openoffice outputs standard conforming DIF
files, I have not see any bug reports about incompatibility with the
MS mangled DIF coming from their camp.

Thanks,

Stanley Pinchak
Comment 2 Morten Welinder 2011-03-03 13:38:10 UTC
Wow.

I think the last time this exporter received any attention was when
the Queen of Hearts was just a little girl.
Comment 3 Morten Welinder 2011-03-03 15:47:02 UTC
This problem has been fixed in our software repository. The fix will go into the next software release. Thank you for your bug report.